Here's something that could be clearer (it wasn't obvious to me that something
like addition would cause a null pointer exception):
user=> (+ 1 nil)
java.lang.NullPointerException (NO_SOURCE_FILE:0)
Sam
---
http://sam.aaron.name
On 8 Feb 2011, at 14:01, Stuart Halloway wrote:
> This conversat
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
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
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
'(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
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
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
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
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
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
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
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
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
> 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
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
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
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
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]
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
On Feb 8, 3:01 pm, Stuart Halloway wrote:
> This conversation began on Twitter [1] but I want to continue it on the
> ma
+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_
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
Thanks Hubert, this is exactly what I'm talking about. D. Werner's
recommendation to use a function call for the validation is a good
point, but having a human readable message like this would be the most
clear.
Cheers,
Jeff
On Feb 10, 9:23 pm, Hubert Iwaniuk wrote:
> Hi,
>
> Jeff correct me if
> (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
Hi,
Jeff correct me if I'm wrong but I think you are after something along the
following lines.
Instead:
(defn f [x] {:pre [(some-fancy-validation x)]} ..)
To have something like this:
(defn f [x] {:pre [^{:msg "here goes description of what has not been valid"}
(some-fancy-validation x)]} ..)
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 useless in comparison to j
> 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
> messages for the condit
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 exception.
Here's an error I just got that could be improved upon. It shows an
error in a file core.clj, but my current project uses many libraries
and there are multiple files named core.clj. How about putting the
full path to the file somewhere so we can jump straight to it?
Thanks,
Jeff
---
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
>> 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
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
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
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
33 matches
Mail list logo
