From: Martyn Jago <martyn.jago@btinternet.com>
To: emacs-orgmode@gnu.org
Subject: Re: [babel] Export problem (Wrong type argument: consp, nil)
Date: Wed, 14 Sep 2011 12:44:03 +0100 [thread overview]
Message-ID: <m2sjnzz6v0.fsf@btinternet.com> (raw)
In-Reply-To: 80y5xrld4x.fsf@somewhere.org
Hi Sebastien
"Sebastien Vauban"
<wxhgmqzgwmuf@spammotel.com> writes:
> Hi Eric,
>
> Eric Schulte wrote:
>> "Sebastien Vauban" <wxhgmqzgwmuf@spammotel.com> writes:
>>> If there is no value assigned to the code block...
>>> ... there is no an error when exporting:
>>>
>>> #+begin_src text
>>> Debugger entered--Lisp error: (wrong-type-argument consp nil)
>>> setcdr(nil "nil=x")
>>> #+end_src
>>
>> All variables must be given a default value, which is why it is an error
>> to write a code block like the following.
>>
>> #+source: circle(x)
>> #+begin_src python
>> return x*x
>> #+end_src
>>
>> I've just pushed up a change which provides a better error message in
>> this case.
>
> It works OK. Thanks a lot for that.
>
> Remark: This did correct a problem that I had with my local LOB, and which
> appeared a couple of months ago. I tried to find the post back, but I
> couldn't. At that time, you tried my example, but you couldn't reproduce it.
> Anyway, I now could check that it was because of this, now that the message is
> a lot clearer than "consp, nil".
>
> Question: Would it be possible to add the src-name in the error message? You
> know, in my LOB, I have so many times the same var name coming back again,
> that having the name of the source block would be of a great help. I tried
> looking into the code to see if I could do it myself, but I must admit it's
> still too hard for me. I have the impression many functions must be extended
> in order to pass the src-name down to where the error is thrown...
>
> Other thing, I tried to add a test for checking your fix never will be
> regressed. This is what I currently have:
>
> * Does not work
> :PROPERTIES:
> :ID: f2df5ba6-75fa-4e6b-8441-65ed84963627
> :END:
>
> If there is no value assigned to the code block, a proper error should be
> thrown.
>
> #+source: carre(x)
> #+begin_src python
> return x*x
> #+end_src
>
> * Test
>
> #+begin_src emacs-lisp
> (ert-deftest test-org-babel/no-defaut-value-for-var ()
> "Test that the absence of a default value for a variable does throw a proper
> error."
> (org-test-at-id "f2df5ba6-75fa-4e6b-8441-65ed84963627"
> (org-babel-next-src-block)
> (should-error (org-babel-execute-src-block))
> :type 'error))
> #+end_src
>
> Though, I have 2 questions:
>
> - How can I differentiate between the clean error (with a message) and the one
> which wasn't correctly trapped? Based on the first line of a backtrace
> (string comparison) or on the type of the error? In the latter case, how
> can I know what's the type of the current error thrown, and the one of the
> error before your fix?
I can help with the error question. You can test the specific error
message as follows:
--8<---------------cut here---------------start------------->8---
(ert-deftest test-org-babel/no-defaut-value-for-var ()
(org-test-at-id "f2df5ba6-75fa-4e6b-8441-65ed84963627"
(org-babel-next-src-block)
(let ((err
(should-error (org-babel-execute-src-block)
:type 'error)))
(should (equal '(error "variable \"x\" must be assigned a default value") err)))))
--8<---------------cut here---------------end--------------->8---
>
> - I wonder why we need twice the =org-babel-next-src-block= call, and not only
> once in the =should-error= form.
>
> Thanks.
>
> Best regards,
> Seb
Best, Martyn
next prev parent reply other threads:[~2011-09-14 11:44 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-08 15:15 [babel] Export problem (Wrong type argument: consp, nil) Sebastien Vauban
2011-09-08 17:33 ` Eric Schulte
2011-09-14 8:52 ` Sebastien Vauban
2011-09-14 11:44 ` Martyn Jago [this message]
2011-09-15 15:10 ` Eric Schulte
2011-09-16 9:57 ` Sebastien Vauban
2011-09-16 10:12 ` Sebastien Vauban
2011-09-16 15:25 ` Eric Schulte
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m2sjnzz6v0.fsf@btinternet.com \
--to=martyn.jago@btinternet.com \
--cc=emacs-orgmode@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).