On Tue, Sep 2, 2014 at 11:01 AM, David Wagle <david.wa...@gmail.com> wrote:
> It sounds like perhaps the issue is code blocks with a long run-time that > may or may not fail or hang in some way? > > If that's the case, the solution is probably simply breaking up your code > blocks into smaller bits of code so that you more easily follow what's > happening. > > If the code is emacs-lisp, it's easy enough to put (message ...) calls > entering and leaving the code blocks. > The defadvice idea is great; I will try it and report back. As for breaking up my code blocks... I wish I could, but some of my SQL queries are just very long running. We have a lot of data. I want to look into indexing and other SQL optimizations -- but I need something in my org-mode to at least show me which blocks are the long-running ones, so I can know where to start! Someone else mentioned that the message about "Wrote <sql input file>" could be suppressed; just don't forget that we users need _something_ to help debug our babel code. If one of my sql queries goes wrong, I get something like this in the messages buffer: executing Sql code block (machines-by-week)... mysql ... -N < "c:/tmp/babel-26204dNc/sql-in-26204uKN" > "c:/tmp/babel-26204dNc/sql-out-262047UT" Wrote c:/tmp/babel-26204dNc/ob-input-26204IfZ Babel evaluation exited with code 1 so in this case it'd be OK if the "Wrote <file>" went away, because the entire mysql command is still there, so I can find that temp file (which babel doesn't clean up, btw, and in my case that's a good thing!) and trace it back to which code block it came from. But it would be way better if mysql-mode would actually show the sql error! -- Gary
