ANN: Typed Clojure 1.0.17: Enhanced destructuring error messages

Hi, Typed Clojure has long struggled with incomprehensible error messages--today I merged an enhancement which should serve as a template to turn this around. Typed Clojure 1.0.17 <https://github.com/typedclojure/typedclojure/blob/main/typed/clj.checker/README.md#releases-and-depende

Re: Clojure Spec and Human Readable Error Messages

David, I've published code204/spec-forms 0.1.0-alpha2 to Clojars. It works fine for simple specs (meaning I haven't tried it on anything crazy yet) and can be used with phrase as well. It's only about 50 lines, so I tried to cover everything in the README: https://github.com/code204/spec-forms#spe

Re: Clojure Spec and Human Readable Error Messages

Many thanks John. I'll check out phrase. If you do get something working I'd love to see it as your approach seems the simplest to me. cheers Dave On Monday, February 3, 2020 at 10:27:08 PM UTC, John Shaffer wrote: > > The phrase library can create human-readable error m

Re: Clojure Spec and Human Readable Error Messages

The phrase library can create human-readable error messages: https://github.com/alexanderkiel/phrase I've been working on something for a more natural (to me) approach, with the ability to define error messages in-line with the predicate. E.g., (s/defop max-length [n] (sf/validator #

Clojure Spec and Human Readable Error Messages

Hi All. I've just come back to Clojure (after being away for a few years) and I'm incredibly impressed with how things have moved on. I particuarly like Clojure Spec but I'm struggling to understand how I can convert coercion erros to a human friendly for for end users to understand on a websit

Re: Calling explain on a merge'd spec outputs duplicate error messages

I think it's finding the problems through the multiple merged map paths but would be reasonable to de-dupe these if they're identical. Feel free to file a jira for it. On Saturday, September 1, 2018 at 10:19:49 AM UTC-5, Lucas Groenendaal wrote: > > Just started learning about spec and am going

Calling explain on a merge'd spec outputs duplicate error messages

Just started learning about spec and am going through the guide: https://clojure.org/guides/spec (so I'm using clojure 1.9.0 and have required clojure.spec.alpha). They introduced the merge macro with this example: (s/def :animal/kind string?) (s/def :animal/says string?) (s/def :animal/common (

Customizing error messages reported by spec.explain

programmers) to invest in reading and understanding spec error messages as you will be seeing them more, at least from macro failures. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups

Customizing error messages reported by spec.explain

Greetings! Can someone please tell me if the error messages reported by spec.explain can be customized ? I'm trying to use spec for data validation and would like to generate human readable errors. Thanks! -- You received this message because you are subscribed to the Google Groups &qu

[ANN] Onyx 0.9.6: Static Analysis and Elm-grade Error Messages

I'm happy to announce the release of Onyx version 0.9.6. This release of Onyx ships our new static analyzer module, which is in turn bundled with a renderer to deliver significantly better error messages than we were able to show in previous releases. Read about it in our blog post below!

Re: A call for an idiomatic rendering of Clojure EDN in info/error messages

Only if _everybody_ signs up to it otherwise I think your second example is open to misinterpretation given that some libraries would generate that for the number 2 and others for a string with the number 2 in it. > On 14 Nov 2015, at 00:01, Alan Thompson wrote: > > I would that the existing f

Re: A call for an idiomatic rendering of Clojure EDN in info/error messages

+1 for | -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email

Re: A call for an idiomatic rendering of Clojure EDN in info/error messages

I would that the existing format of pr-str would work, no?. I often structure Exception error strings like: foo-service: bad value=2 foo-service: bad value="2" Does that not keep it unambiguous? Alan On Fri, Nov 13, 2015 at 10:59 AM, Colin Yates wrote: > Hi Ben, > > I’m pretty sure we are all

Re: A call for an idiomatic rendering of Clojure EDN in info/error messages

Hi Ben, I’m pretty sure we are all on the same page that rendering a string with a single character of 2 is “2”. Regarding not needing a delimiter: if everybody everywhere signed up to this then yes, I agree - no delimiter is necessary. Until that becomes true then I still think a delimiter is

Re: A call for an idiomatic rendering of Clojure EDN in info/error messages

On Fri, Nov 13, 2015 at 5:47 AM, Colin Yates wrote: > Really, I don’t mind - I would just like consistency :-) > > One argument for the right delimiter of some sort is that it is > unambiguous and therefore nobody can misinterpret it. If you were > unfamiliar with a validation library and it repo

Re: A call for an idiomatic rendering of Clojure EDN in info/error messages

+1 for no special markup, +1 for backquotes, -1 for underscore, -1 for pipe char. On Fri, Nov 13, 2015 at 7:18 PM, Colin Yates wrote: > This. Confusing for the rubyists but hey :-). > > On 13 Nov 2015, at 17:13, Yuri Govorushchenko > wrote: > > I recall Google uses vertical bars in ObjC comment

Re: A call for an idiomatic rendering of Clojure EDN in info/error messages

This. Confusing for the rubyists but hey :-). > On 13 Nov 2015, at 17:13, Yuri Govorushchenko wrote: > > I recall Google uses vertical bars in ObjC comments for similar purposes, as > stated in their style guide: > > Use vertical bars to quote variable names and symbols in comments rather than

Re: A call for an idiomatic rendering of Clojure EDN in info/error messages

I recall Google uses vertical bars in ObjC comments for similar purposes, as stated in their style guide: Use vertical bars to quote variable names and symbols in comments rather than quotes or naming the symbol inline. This helps eliminate ambiguity, especially when the symbol is a common word

Re: A call for an idiomatic rendering of Clojure EDN in info/error messages

As a newbie, a red warning flag pops up when I see a back tick. :-) -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with y

Re: A call for an idiomatic rendering of Clojure EDN in info/error messages

+1 for backquotes, as I understand then without needing to think about it because of markdown. (I use them in docstrings and commit messages and error messages, too.) On Nov 13, 2015 10:26 AM, "Steve Miner" wrote: > For what it’s worth, I like to use matching `backquotes` as

Re: A call for an idiomatic rendering of Clojure EDN in info/error messages

For what it’s worth, I like to use matching `backquotes` as a meta-syntax. (defn expected [exp was] (format "Expected `%s` but was `%s`" (pr-str exp) (pr-str was))) (println (expected 2 "2")) ;=> Expected `2` but was `"2"` > On Nov 13, 2015, at 6:55 AM, Colin Yates wrote: > > Hi all, > >

Re: A call for an idiomatic rendering of Clojure EDN in info/error messages

That is too close to a literal set or literal map for my tastes… > On 13 Nov 2015, at 14:30, Gary Trakhman wrote: > > A pair of curly brackets with a single value isn't part of the grammar > either, and I think reads better than _ > > On Nov 13, 2015 8:47 AM, "Colin Yates"

Re: A call for an idiomatic rendering of Clojure EDN in info/error messages

A pair of curly brackets with a single value isn't part of the grammar either, and I think reads better than _ On Nov 13, 2015 8:47 AM, "Colin Yates" wrote: > Really, I don’t mind - I would just like consistency :-) > > One argument for the right delimiter of some sort is that it is > unambiguous

Re: A call for an idiomatic rendering of Clojure EDN in info/error messages

Really, I don’t mind - I would just like consistency :-) One argument for the right delimiter of some sort is that it is unambiguous and therefore nobody can misinterpret it. If you were unfamiliar with a validation library and it reported [:a :b :c must be “2”] you _could_ interpret that as ei

Re: A call for an idiomatic rendering of Clojure EDN in info/error messages

Hi Colin, Why not just "2"? On Fri, Nov 13, 2015 at 1:55 PM, Colin Yates wrote: > Hi all, > > Can we, the community agree a consistent way of rendering Clojure EDN when > we report it in info or error. For example, given the EDN "2" (i.e. a > string containing a single character 2) I have seen

A call for an idiomatic rendering of Clojure EDN in info/error messages

Hi all, Can we, the community agree a consistent way of rendering Clojure EDN when we report it in info or error. For example, given the EDN "2" (i.e. a string containing a single character 2) I have seen various libraries render it as: - 2 - "2" - ["2"] - [2] - (2) - '"2"' I would like

Re: [ANN]: Matcha, a library for composable test assertions with human readable error messages

ent about this new package, and a desire to help it get even better! -James On Monday, May 25, 2015 at 3:27:13 PM UTC-5, tcrayford wrote: > > Matcha lets you write flexible, composable test assertions with human > friendly error messages. It's modeled after the excellent Java Ha

Re: [ANN]: Matcha, a library for composable test assertions with human readable error messages

Oh, sorry, here is my actual test: (m/is (m/has-entry-that :status (m/= 200)) (http/get "http://localhost:12081/idp/status";)) -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that po

Re: [ANN]: Matcha, a library for composable test assertions with human readable error messages

t;,\\n \\\"time\\\" : \\\"2015-05-26T21:36:11Z\\\",\\n \\\"loadAverage\\\" : 1.82666015625,\\n \\\"heap\\\" : {\\n \\\"committed\\\" : 476053504,\\n\\\"max\\\" : 3817865216,\\n \\\"used\\\" : 277027488\\n },\\n \\\&qu

[ANN]: Matcha, a library for composable test assertions with human readable error messages

Matcha lets you write flexible, composable test assertions with human friendly error messages. It's modeled after the excellent Java Hamcrest library. As a quick example, you might build up a matcher that says "this map has 5 elements, and the :foo key must be greater than 1

Re: One more for the "crappy error messages" file.

On Monday, December 8, 2014 1:29:51 AM UTC-5, Mikera wrote: > > How are you getting that error? Are you sure you aren't just passing a nil > parameter by accident? For example, I get the same error when I pass nil to > the "clojure.java.io/reader" function. > > Clojure usually throws file not fou

Re: One more for the "crappy error messages" file.

How are you getting that error? Are you sure you aren't just passing a nil parameter by accident? For example, I get the same error when I pass nil to the "clojure.java.io/reader" function. Clojure usually throws file not found exceptions where appropriate, e.g. (use 'clojure.java.io) (reader

One more for the "crappy error messages" file.

IllegalArgumentException No implementation of method: :make-reader of protocol: #'clojure.java.io/IOFactory found for class: nil clojure.core/-cache-protocol-fn (core_deftype.clj:541) This, apparently, is clojure.java.io's way of saying "file not found". :) If there's a list somewhere of speci

Re: Useless Java error messages

On Tuesday, September 2, 2014 5:13:49 PM UTC-7, Beau Fabry wrote: > > apologies, not a leiningen plugin. https://github.com/AvisoNovate/pretty > Thank you. This looks most interesting. I was able to find clj-pretty-error on Clojars; github is https://github.com/liquidz/clj-pretty-error, but it

Re: Useless Java error messages

apologies, not a leiningen plugin. https://github.com/AvisoNovate/pretty On Wednesday, September 3, 2014 2:17:21 AM UTC+10, John Gabriele wrote: > > On Monday, September 1, 2014 7:24:54 PM UTC-4, Beau Fabry wrote: >> >> The pretty-errors leiningen plugin might be worth a look >> >> > Hm... I don't

Re: Useless Java error messages

On Monday, September 1, 2014 7:24:54 PM UTC-4, Beau Fabry wrote: > > The pretty-errors leiningen plugin might be worth a look > > Hm... I don't see that particular plug-in in the [main lein plug-in list](https://github.com/technomancy/leiningen/wiki/Plugins). Do you mean [clj-stacktrace](https://

Re: Useless Java error messages

> . leaves me clueless as to where the error occurred. > > Is there hope for native Clojure debugging anytime soon as this is the > kind of thing which can easily drive a non-Java user like me to > distraction? I noticed the Elixir community had the same problem with > Er

Re: Useless Java error messages

The pretty-errors leiningen plugin might be worth a look On Tuesday, September 2, 2014 7:58:31 AM UTC+10, g vim wrote: > > On 01/09/2014 17:50, Luc Prefontaine wrote: > > Where do you see a Java error here ? > > > > I see the Clojure implementation > > reporting that you are > > trying to app

Re: Useless Java error messages

Ah ! Emacs, an old friend that I should eventually revisit after 30 years... Long time no see :) Luc P. > On 01/09/2014 17:50, Luc Prefontaine wrote: > > Where do you see a Java error here ? > > > > I see the Clojure implementation > > reporting that you are > > trying to apply a numeric operator

Re: Useless Java error messages

On 01/09/2014 17:50, Luc Prefontaine wrote: Where do you see a Java error here ? I see the Clojure implementation reporting that you are trying to apply a numeric operator to a null/nil value :) I agree the JVM stack traces are not nice and polluted by all the frames which may/may not be releva

Re: Useless Java error messages

where the error occurred. > > Is there hope for native Clojure debugging anytime soon as this is the > kind of thing which can easily drive a non-Java user like me to > distraction? I noticed the Elixir community had the same problem with > Erlang's cryptic error messages and pr

Re: What people want from Clojure error messages

Brian Marick writes: > I've also noticed that the messages that come from botched > macroexpansions are often not useful in that they contain no clues > about the original source, and sometimes not even a useful reference > to the original namespace. If these are macros that are under your contr

Re: What people want from Clojure error messages

I've also noticed that the messages that come from botched macroexpansions are often not useful in that they contain no clues about the original source, and sometimes not even a useful reference to the original namespace. I have a similar problem in Midje. When a macroexpansion blows up, I catch

Re: What people want from Clojure error messages

A typo in an identifier should not lead to the following. Although I understand that `lein repl` trims stack traces, that should be the default, rather than having every substantial user-facing program trim `clojure.lang.Compiler` (etc.) messages for the sake of its users. > Exception in threa

Re: What people want from Clojure error messages

On Friday, January 25, 2013 6:27:48 AM UTC+11, Michael Klishin wrote: [..] > Because poor error messages primarily trip newcomers to the language, > I am a bit surprised to see this issue discussed on the closed > mailing list said beginners cannot join [quickly or at all]. > >

Re: What people want from Clojure error messages

/quil/quil/commit/d0312f0f119db066a8d613dec8803571b92bea39 -- That's all I got for now, other stuff from my aforementioned gist do not apply to this subject, although I believe it's idiomatic clojure coding which leads to such cryptic error messages and hard to track down bu

Re: What people want from Clojure error messages

between pieces of code, is just a fact of life when programming in dynamic languages. Finally, what's a good language, error-info wise? Can't recall one. On Thursday, January 24, 2013 8:27:48 PM UTC+1, Michael Klishin wrote: > > There is a discussion about Clojure error messages

Re: What people want from Clojure error messages

On Jan 24, 2013, at 11:27, Michael Klishin wrote: > So, if you have something specific to say on the topic, say it here. Well, these comments more general in nature; hope that's OK... I find Clojure's default error messages to be noisy, ugly, and hard to decipher. What I'

Re: What people want from Clojure error messages

ike that. On Thu, Jan 24, 2013 at 8:27 PM, Michael Klishin < michael.s.klis...@gmail.com> wrote: > There is a discussion about Clojure error messages and how > specifically they can be improved on clojure-dev: > https://groups.google.com/forum/?fromgroups=#!topic/clojure-dev/9zj

Re: Compiler error messages

On Mon, Jun 18, 2012 at 11:44 AM, Brandon Bickford wrote: > I was wondering if anyone was working on improving compiler error messages? > For instance in a case just now when I used an undeclared variable "host" I > received an opaque hundred line traceback.  I think it

Re: ClojureScript error messages

Not yet. I'll have to take care of that. On Mon, Mar 19, 2012 at 5:48 PM, David Nolen wrote: > On Mon, Mar 19, 2012 at 1:36 PM, Aaron wrote: > >> I pushed the patch to my fork on github in this commit: >> https://github.com/aaronc/clojurescript/commit/3193ed6e27061765782da32d36a63b0f7630f5e9 >

Re: ClojureScript error messages

On Mon, Mar 19, 2012 at 1:36 PM, Aaron wrote: > I pushed the patch to my fork on github in this commit: > https://github.com/aaronc/clojurescript/commit/3193ed6e27061765782da32d36a63b0f7630f5e9 > > Should I submit a pull request? Clojure doesn't take pull requests. Have you sent in your CA? If

Re: ClojureScript error messages

I pushed the patch to my fork on github in this commit: https://github.com/aaronc/clojurescript/commit/3193ed6e27061765782da32d36a63b0f7630f5e9 Should I submit a pull request? -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, se

Re: ClojureScript error messages

On Fri, Mar 16, 2012 at 6:11 PM, Aaron wrote: > Is there any reason why ClojureScript does not return a source file and > line number when there are reader errors? All I get is a long stack trace > that only has line numbers for the clojure/clojurescript code that threw - > not very helpful. > >

ClojureScript error messages

Is there any reason why ClojureScript does not return a source file and line number when there are reader errors? All I get is a long stack trace that only has line numbers for the clojure/clojurescript code that threw - not very helpful. Looking at the source for cljs.compiler/compile-file* a

Re: better error messages > smaller stack traces

rote: > 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 follow

Re: better error messages > smaller stack traces

On 2 March 2011 09:32, Alan wrote: > '(apply + 1 1) would be how you create a list of those symbols. > ('apply + 1 1) says "call the function 'apply with the arguments of + > 1 and 1". Note that this will still break at runtime because Integers are not seqable. :-) You probably want either (appl

Re: better error messages > smaller stack traces

Thanks! On Mar 2, 5:19 am, Ken Wesson wrote: > On Wed, Mar 2, 2011 at 3:32 AM, Alan wrote: > > '(apply + 1 1) would be how you create a list of those symbols. > > Or (list 'apply '+ 1 1) or `(apply + 1 1), both of which allow you to > put something variable in there, like (list 'apply '+ 1 x) or

Re: better error messages > smaller stack traces

On Wed, Mar 2, 2011 at 3:32 AM, Alan wrote: > '(apply + 1 1) would be how you create a list of those symbols. Or (list 'apply '+ 1 1) or `(apply + 1 1), both of which allow you to put something variable in there, like (list 'apply '+ 1 x) or `(apply + 1 ~x). -- You received this message because

Re: better error messages > smaller stack traces

'(apply + 1 1) would be how you create a list of those symbols. ('apply + 1 1) says "call the function 'apply with the arguments of + 1 and 1". On Mar 1, 8:37 pm, Mark wrote: > I found the problem: > ('apply + 1 1) > > I understand why this won't work if I tried to eval the list, but I > don't un

Re: better error messages > smaller stack traces

I found the problem: ('apply + 1 1) I understand why this won't work if I tried to eval the list, but I don't understand why I can't create a list of these symbols. On Feb 28, 9:06 am, Brian Marick wrote: > On Feb 27, 2011, at 2:33 PM, Mark wrote: > > > With a fresh brain (and a fresh cup of cof

Re: better error messages > smaller stack traces

On Feb 27, 2011, at 2:33 PM, Mark wrote: > With a fresh brain (and a fresh cup of coffee), I realized this > message is probably caused (somehow) by my misuse of the midje > library. No doubt it does fancy macro stuff under-the-hood. Indeed it does. > One could certainly argue that the > macro

Re: better error messages > smaller stack traces

With a fresh brain (and a fresh cup of coffee), I realized this message is probably caused (somehow) by my misuse of the midje library. No doubt it does fancy macro stuff under-the-hood. At the core of this problem is that I'm a naive client of this macro library and by an innocent misuse, I am s

Re: better error messages > smaller stack traces

On 27 February 2011 20:50, Mark wrote: > I wrote that up quickly without thinking much about it.  Yes, the > invocation is definitely a macro and not a function.  Still, I think > it would be helpful to see the symbol's value and, if possible, the > macro's arity. Is calling symbols as a function

Re: better error messages > smaller stack traces

I wrote that up quickly without thinking much about it. Yes, the invocation is definitely a macro and not a function. Still, I think it would be helpful to see the symbol's value and, if possible, the macro's arity. On Feb 27, 1:13 pm, Ken Wesson wrote: > On Sun, Feb 27, 2011 at 2:10 PM, Ken We

Re: better error messages > smaller stack traces

On Sun, Feb 27, 2011 at 2:10 PM, Ken Wesson wrote: > On Sat, Feb 26, 2011 at 8:14 PM, Mark wrote: >> I get this: >> #> of args (3) passed to: Symbol (C:\Users\addma03\workspace\test\src\main >> \clojure:1)> >> >> A few suggestions: >> 1)  An improved line number >> 2) I'd like to see the value of

Re: better error messages > smaller stack traces

On Sat, Feb 26, 2011 at 8:14 PM, Mark wrote: > I get this: > # of args (3) passed to: Symbol (C:\Users\addma03\workspace\test\src\main > \clojure:1)> > > A few suggestions: > 1)  An improved line number > 2) I'd like to see the value of the Symbol > 3) I'd like to see the three args applies to the

Re: better error messages > smaller stack traces

I get this: # A few suggestions: 1) An improved line number 2) I'd like to see the value of the Symbol 3) I'd like to see the three args applies to the symbol and, if the symbol resolves to a function, I'd like to see the arity of the function. Something like: Wrong number of args (3) passed to

Re: better error messages > smaller stack traces

> Here's one: > > user=> {:a 1 :b} > # > > Instead how about a parse error exception that specifically says > something like, "Map literal requires an even number of forms." > > Thanks, > Jeff Fixed in master today: http://dev.clojure.org/jira/browse/CLJ-742 Thanks! Stu -- You received this

Re: better error messages > smaller stack traces

On Tue, Feb 08, 2011 at 09:01:38AM -0500, 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]. Here's another error message that really threw me off for a while. I

Re: better error messages > smaller stack traces

Hello. There is an interesting model about error reporting: Clang, one of C-family languages compiler which uses LLVM. For example, if you mistake names, Clang searches similar names which really exist in current environment. And then Clang illustrates line, column and actual code. If you want to

Re: better error messages > smaller stack traces

On Mon, Feb 14, 2011 at 5:48 AM, Timo Mihaljov wrote: > On Tue, Feb 08, 2011 at 09:01:38AM -0500, 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]. > > Here's

Re: better error messages > smaller stack traces

On Tue, Feb 08, 2011 at 09:01:38AM -0500, 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]. Here's a misleading lack of an error message: (defn foo [x]

Re: better error messages > smaller stack traces

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

Re: better error messages > smaller stack traces

+1 for the assertion macro suggestions (custom messages). On the topic of stack traces: it's high time Clojure stopped generating shit like java.lang.RuntimeException: java.lang.RuntimeException: java.lang.IllegalArgumentException: Don't know how to create ISeq from: java.lang.Integer (NO_SOURCE_

Re: better error messages > smaller stack traces

On 10 February 2011 21:33, Fogus wrote: > Additionally, I've always hoped for separate > PreConditionAssertionError and PostConditionAssertionError types, but > keep forgetting to discuss it. A while ago Stuart Sierra wrote about using typed assertions in unit testing. One of his points was to gi

Re: better error messages > smaller stack traces

; > > > On 10 February 2011 17:05, Jeff Rose wrote: > >> Sorry for the reply spam, but I've just remembered another error > >> reporting issue: pre and post conditions.  They are a great feature > >> and I'd like to use them more often, but the error message

Re: better error messages > smaller stack traces

> (defn f [x] {:pre [^{:msg "..."} (some-fancy-validation x)]} ..) That idea (or some variation) is actually kinda nice. Additionally, I've always hoped for separate PreConditionAssertionError and PostConditionAssertionError types, but keep forgetting to discuss it. -- You received this message

Re: better error messages > smaller stack traces

just remembered another error >> reporting issue: pre and post conditions. They are a great feature >> and I'd like to use them more often, but the error messages they >> produce are virtually useless in comparison to just writing your own >> check with a custom excep

Re: better error messages > smaller stack traces

On 10 February 2011 17:05, Jeff Rose wrote: > Sorry for the reply spam, but I've just remembered another error > reporting issue: pre and post conditions.  They are a great feature > and I'd like to use them more often, but the error messages they > produce are virtually us

Re: better error messages > smaller stack traces

> reporting issue: pre and post conditions.  They are a great feature > and I'd like to use them more often, but the error messages they > produce are virtually useless in comparison to just writing your own > check with a custom exception.  How about having optional error &

Re: better error messages > smaller stack traces

Sorry for the reply spam, but I've just remembered another error reporting issue: pre and post conditions. They are a great feature and I'd like to use them more often, but the error messages they produce are virtually useless in comparison to just writing your own check with a custom

Re: better error messages > smaller stack traces

ead (LispReader.java:145) clojure.lang.Compiler.load (Compiler.java:5854) nil user=> On Feb 8, 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

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

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

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 program

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 inter

Re: better error messages > smaller stack traces

s.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 tea

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

Re: Better documentation and error messages are needed for the ns macro

On Fri, Nov 13, 2009 at 1:23 PM, Chouser wrote: > On Wed, Nov 11, 2009 at 4:24 PM, John Harrop wrote: > > One question: how would Java class imports be dealt with? I think it > should > > be unified: > > (ns foo > > (uses java.io :only [File FileInputStream] :as io)) > > I think this is a bad

Re: Better documentation and error messages are needed for the ns macro

On Wed, Nov 11, 2009 at 4:24 PM, John Harrop wrote: > One question: how would Java class imports be dealt with? I think it should > be unified: > (ns foo >   (uses java.io :only [File FileInputStream] :as io)) I think this is a bad idea. Java (or other host) classes are not Clojure functions, no

Re: Better documentation and error messages are needed for the ns macro

With clojure-in-clojure on the horizon (if not around the corner) I wonder if an imports clause would be appropriate, and solve some of the complexities of discerning between clojure and java/clr/javascript/objectivec/(go?) (ns foo (uses clojure.contrib.repl-utils) (imports java.util [List M

Re: Better documentation and error messages are needed for the ns macro

I like almost all of this a lot. My only disagreement is on prefix lists ... I wouldn't want to lose them, and in fact would prefer to see them extended to recursive prefix lists (trees). -Jason On Nov 11, 10:12 am, "Stephen C. Gilardi" wrote: > On Nov 10, 2009, at 9:08 PM, John Harrop wrote: >

Re: Better documentation and error messages are needed for the ns macro

On Wed, Nov 11, 2009 at 3:54 PM, Laurent PETIT wrote: > 2009/11/11 Andrew Boekhoff : > >> > (:uses [clojure.core :exclude [read]) > >> > [clojure.contrib.graph] > >> > [clojure.contrib.fcase] > >> > [clojure.contrib.stream-utils :as su] > >> > [clojure.contrib.def

Re: Better documentation and error messages are needed for the ns macro

2009/11/11 Andrew Boekhoff : >> >  (:uses [clojure.core :exclude [read]) >> >         [clojure.contrib.graph] >> >         [clojure.contrib.fcase] >> >         [clojure.contrib.stream-utils :as su] >> >         [clojure.contrib.def :refer-all true] >> >         [clojure.contrib.except :refer-all tr

Re: Better documentation and error messages are needed for the ns macro

Hi! On Wed, Nov 11, 2009 at 7:12 PM, Stephen C. Gilardi wrote: > Here are some of the ideas I've liked best for how to do it. I like where this is heading. > - don't "refer" any names from the target namespace into the current > namespace by default YES! >  - support ":only []", ":rename {}",

Re: Better documentation and error messages are needed for the ns macro

On Wed, Nov 11, 2009 at 1:12 PM, Stephen C. Gilardi wrote: > > Here are some of the ideas I've liked best for how to do it. Thanks for pulling this together. I like the whole direction you're going here. > - require that each "libspec" (reference to a lib) be a vector, disallowing > naked symbo

Re: Better documentation and error messages are needed for the ns macro

> > (:uses [clojure.core :exclude [read]) > > [clojure.contrib.graph] > > [clojure.contrib.fcase] > > [clojure.contrib.stream-utils :as su] > > [clojure.contrib.def :refer-all true] > > [clojure.contrib.except :refer-all true] > > [clojure.contrib.se

Re: Better documentation and error messages are needed for the ns macro

On Wed, Nov 11, 2009 at 1:12 PM, Stephen C. Gilardi wrote: > Before: > > (:refer-clojure :exclude [read]) > (:require (clojure.contrib [graph :as graph] [fcase :as fcase]) >[clojure.contrib.stream-utils :as su]) > (:use [clojure.contrib def except server-socket] >clojure.con

Re: Better documentation and error messages are needed for the ns macro

On Nov 10, 2009, at 9:08 PM, John Harrop wrote: (ns foo.bar.baz (:use [clojure.contrib.core :only (seqable?)])) (and thus violates the usual clojure rule of using vectors rather than lists for groupings that are not invocations -- that is, function calls, macro calls, or special form cal

  1   2   >