emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] [babel] Export problem (Wrong type argument: consp, nil)


From: Sebastien Vauban
Subject: Re: [O] [babel] Export problem (Wrong type argument: consp, nil)
Date: Fri, 16 Sep 2011 11:57:31 +0200
User-agent: Gnus/5.110018 (No Gnus v0.18) Emacs/23.3 (windows-nt)

Hi Eric,

Eric Schulte wrote:
>> Question: Would it be possible to add the src-name in the error
>> message?
>
> Unfortunately the code block name is not known to the function (namely
> `org-babel-merge-params') which throws errors when variables are not
> assigned default values.  In fact this function may be called when there
> are no code blocks present.  I think that this is why you ran into
> problems trying to thread the code block info down into this error
> message.
>
> Another option may be to check when a code block is initially parsed to
> ensure that all variables are assigned default parameters.  If the
> checking is done initially then the code block name and position will be
> known and could be included into the error message.  There exists a
> function for checking code blocks (namely `org-babel-check-src-block'),
> I've added a TODO to this function to add a check that all variables are
> initialized.

OK. Thanks.

>> * 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 believe Martyn answered this question

Yes, he did. Thanks Martyn.

>> - I wonder why we need twice the =org-babel-next-src-block= call, and
>>   not only once in the =should-error= form.
>
> I only see a single call to org-babel-next-src-block in the above test.

OK, I misread `org-babel-next-src-block' and `org-babel-execute-src-block'. It
was late, I guess. Sorry for the noise.

> Thanks for working on this test, I look forward to adding it once it is
> completed.

With Martyn's patch, updated with the brand new source name figuring in the
error message, the completed version becomes:

* Code block with no default value for vars
  :PROPERTIES:
  :ID:       f2df5ba6-75fa-4e6b-8441-65ed84963627
  :END:

There is no default value assigned to =x= variable. This is not permitted
anymore.

#+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 an
  error."
  (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\" in block \"carre\" must be 
assigned a default value") err)))))
#+end_src

I'll send you a patch for this.

Best regards,
  Seb

-- 
Sebastien Vauban




reply via email to

[Prev in Thread] Current Thread [Next in Thread]