Re: [Orgmode] Error when running org-babel-execute-buffer -- Wrong type argument: consp, nil

[Eric Schulte]

Thanks for the suggestion Nick,

I've moved the macro definition up towards the top of ob.el, and for
good measure I am now autoloading it.  After this change I am able to
call both ob-execute-subtree and ob-execute-buffer without error on the
following simple Org-mode file

* top
** first
#+begin_src emacs-lisp
  (+ 1 1 1 1 1)
#+end_src

** second
#+begin_src emacs-lisp
  (message "even more")
#+end_src

Could you and/or Konrad let me know if this now works on your systems,
and if not could you send me an example file that exercises the error?

Thanks -- Eric

Nick Dokos <address@hidden> writes:

> Eric Schulte <address@hidden> wrote:
>
>> Thanks for doing most of the debugging on this.
>> 
>> After much banging of my head, I stumbled onto this very nice page of
>> common problems with compiled Macros in Emacs Lisp [1], it looks like
>> this sort of thing has happened before. :)
>> 
>> I realized I was guilty of one of the macro sins specified above, and
>> after rectifying that design flaw I believe (at least for my simple test
>> case) this error should be fixed.  Please let me know if you continue to
>> run into this problem with the byte-compiled version of this macro.
>>
>> ...
>> 
>> Footnotes: 
>> [1]
>> http://www.gnu.org/s/emacs/manual/html_node/elisp/Problems-with-Macros.html
>> 
>
> After Konrad reported that this doesn't fix it, I tried it too with his
> simple org file and got the same error [fn:1].
>
> So after trying the usual debugging tricks and coming up empty, I took a
> look at the ob.elc file and the problem was obvious: the macro was not
> expanded during compilation.  I'm not sure how exactly we get to the
> ``consp nil'' error that way, but I'm pretty sure that the solution is
> to change the order of the macro and the function that uses it in ob.el,
> so the definition precedes the use.
>
> Cheers,
> Nick
>
> PS. I can now go to bed in peace...
>
> Footnotes:
> [fn:1] OT to the above: I had to name the session , otherwise python would 
> report
>
> ,----
> | Traceback (most recent call last):
> |   File "<stdin>", line 5, in <module>
> |   File "<stdin>", line 3, in main
> | NameError: global name 'days' is not defined
> `----
>
> Here for reference is my modification to Konrad's original example:
>
> * Vacation days
> #+begin_src python :session foo :results silent
>   days = 32+2+9
> #+end_src
>
> ** Vacation <2010-10-28 Thu>-<2010-10-29 Fri>
> #+begin_src python :session foo :results silent
>   days -= 2
> #+end_src
>
> ** Remaining days
> #+begin_src python :session foo :results value
>   days
> #+end_src
>
> #+results:
> : 41