Re: [O] babel: ob-C with Visual C++ and compilation-mode
Ernesto Durante stobos...@gmail.com writes: Eric Schulte schulte.e...@gmail.com writes: Ernesto Durante stobos...@gmail.com writes: Perhaps a new header argument should be added for C-Family languages which will inhibit this main wrapping behavior? -- Eric Hi Eric, According to me, we can already inhibit the wrapping with the following header :main no. Maybe, it should be the default behavior ? Oh, great. I don't think we should change the default. It is easy to customize the value of this header argument, and the default should be targeted at ease of use for first timers, which I believe means doing something useful even for code blocks without an explicit main. Best, Eric Best Ernesto -- Eric Schulte https://cs.unm.edu/~eschulte PGP: 0x614CA05D (see https://u.fsf.org/yw)
Re: [O] babel: ob-C with Visual C++ and compilation-mode
Le 24/08/2014 14:57, Ernesto Durante a écrit : I have worked with VTK (the visualization toolkit). It is like babel and allows differents block to be chained and evaluated on demand. Very interesting software. Thanks for sharing. In VTK, such a chain is called a pipeline. Clearly the main challenge of VTK is to ensure that the data flowing between algorithms are compatible. VTK relies heavily on the type of data. How in Babel can we associate a type to a data ? to a column of a table ? to a list ? Without such a information, how can babel infer the type ? You may want to read this small tutorial: http://orgmode.org/worg/org-contrib/babel/examples/data-collection-analysis.html It describes a Babel pipeline with tables in the middle.
Re: [O] babel: ob-C with Visual C++ and compilation-mode
Thierry Banel tbanelweb...@free.fr writes: Le 20/08/2014 22:40, Ernesto Durante a écrit : as the source org file is not guarantied to be in utf-8. You may want to give it a try an provide a patch for that. 3 files are involved: - lisp/ob-C.el (you know this one) - testing/lisp/test-ob-C.el (to launch unit tests) - testing/examples/ob-C-test.org (the unit tests themselves) - worg/org-contrib/babel/languages/ob-doc-C.org (the 4th of the 3 files). Have fun Thierry Hi Thierry, Again I really appreciate your help. As you pointed out unicode is the solution but we have to pay attention the source file be itself encoded in unicode. I have worked with VTK (the visualization toolkit). It is like babel and allows differents block to be chained and evaluated on demand. In VTK, such a chain is called a pipeline. Clearly the main challenge of VTK is to ensure that the data flowing between algorithms are compatible. VTK relies heavily on the type of data. How in Babel can we associate a type to a data ? to a column of a table ? to a list ? Without such a information, how can babel infer the type ? Best Ernesto
Re: [O] babel: ob-C with Visual C++ and compilation-mode
Eric Schulte schulte.e...@gmail.com writes: Ernesto Durante stobos...@gmail.com writes: Perhaps a new header argument should be added for C-Family languages which will inhibit this main wrapping behavior? -- Eric Hi Eric, According to me, we can already inhibit the wrapping with the following header :main no. Maybe, it should be the default behavior ? Best Ernesto
Re: [O] babel: ob-C with Visual C++ and compilation-mode
Eric Schulte schulte.e...@gmail.com writes: Hi Ernesto, This looks like a good change and I'd like to apply it. Could you re-submit this commit after doing the following. 1. ensure no lines go beyond 80 characters in length 2. remove all lines which include only closing parens (such lines are generally considered bad lisp style) 3. commit to your local git repository with git commit 4. format the patch with git format-patch Thanks, Eric Hi Eric, First, SORRY I didn't see you replay to my email (I am new to GNUS). Second, I would like to thank you for this great environment which is Babel: original and and extremly powerful. Finally, I will follow your instruction and re-submit soon. Best Ernesto
Re: [O] babel: ob-C with Visual C++ and compilation-mode
Le 20/08/2014 22:40, Ernesto Durante a crit: Another question if you allow me ? Looking at code in Ob-C you transform a table/list variable in a C array of char*. Should it not be std::wstring ? some unicode string ? Best Ernesto Absolutely! Unicode is the way to go. Of course, this should be handled carefully, as the source org file is not guarantied to be in utf-8. You may want to give it a try an provide a patch for that. 3 files are involved: - lisp/ob-C.el (you know this one) - testing/lisp/test-ob-C.el (to launch unit tests) - testing/examples/ob-C-test.org (the unit tests themselves) - worg/org-contrib/babel/languages/ob-doc-C.org (the 4th of the 3 files). Have fun Thierry
Re: [O] babel: ob-C with Visual C++ and compilation-mode
Hi Ernesto, This looks like a good change and I'd like to apply it. Could you re-submit this commit after doing the following. 1. ensure no lines go beyond 80 characters in length 2. remove all lines which include only closing parens (such lines are generally considered bad lisp style) 3. commit to your local git repository with git commit 4. format the patch with git format-patch Thanks, Eric Ernesto Durante stobos...@gmail.com writes: Hi, I am using ob-C with gcc and Microsoft Visual C++. These two compilers have two different behaviours for outputting errors. Gcc uses the standard error output and Visual C++ uses the regular output. Under Windows, errors are not displayed because of the way org-babel-eval is coded. To work on both platforms, the standard output must be concatenated with the standard error. I modified the org-babel-eval in the following way. diff --git a/lisp/ob-eval.el b/lisp/ob-eval.el index 057590f..1a93460 100644 --- a/lisp/ob-eval.el +++ b/lisp/ob-eval.el @@ -53,12 +53,20 @@ STDERR with `org-babel-eval-error-notify'. (setq exit-code (org-babel--shell-command-on-region (point-min) (point-max) cmd err-buff)) - (if (or (not (numberp exit-code)) ( exit-code 0)) - (progn - (with-current-buffer err-buff - (org-babel-eval-error-notify exit-code (buffer-string))) - nil) - (buffer-string) + (let ((temp-buffer-str (buffer-string))) ;;temp-buffer-str holds standard output + body + (if (or (not (numberp exit-code)) ( exit-code 0)) + (progn + (with-current-buffer err-buff + (org-babel-eval-error-notify exit-code (format %s%s temp-buffer-str (buffer-string))) + ) + (save-excursion + (when (get-buffer org-babel-error-buffer-name) + (with-current-buffer org-babel-error-buffer-name + (compilation-mode) + (read-only-mode 0) + ))) + nil) + temp-buffer-str) One suggestion. It will be nice to put the error buffer in compilation-mode, this way errors are highlighted and we can jump directly into the source code. I modified org-babel-eval to launch the compilation mode in case of errors. I also removed the read-only attribute, else the buffer content of org-babel-error-buffer-name cannot be erased. Clearly, it's not a good patch because org-babel-eval seems to be a core function in babel. Maybe for ob-C, this function should be replaced by a new function. Thanks to everyone for orgmode and babel to exist. Best Ernesto -- Eric Schulte https://cs.unm.edu/~eschulte PGP: 0x614CA05D (see https://u.fsf.org/yw)
Re: [O] babel: ob-C with Visual C++ and compilation-mode
Ernesto Durante stobos...@gmail.com writes:
Thierry Banel tbanelweb...@free.fr writes:
I have identified a minor bug. When a source code block has the mode
cpp, we cannot expand the code or more precisely the code is not
expanded in the correct way because the following function is missing
(defun org-babel-expand-body:cpp (body params)
Execute BODY according to PARAMS.This function calls
`org-babel-expand-body:C++'.
(org-babel-expand-body:C++ body params))
Thanks for reporting this ! You may consider submitting a patch for this
bug. The comment Execute BODY ... should be changed to Expand BODY
Ok I will change the comment
I'd be happy to commit this patch after you make this change and
re-format with git format-patch. Also, please consider filling out
the FSF copyright assignment paperwork, so that we may accept larger
patches from you in the future.
Thanks for you contributions!
Eric
Best
Ernesto
You are very welcome
Thierry
Thank you Thierry for your answer and all the details. I really want to be a
contributor
and help ob-C to improve (as well as can do a modest lisper).
I tried to find a way to master Cx11 and babel is helping me a lot.
I think babel can really accelerate learning and dissimation of C++.
In this perspective, I have another very simple idea that I want to share
with you. I find C++ too noisy. In the following piece of code
I really find the presence of the main call and the return statement really
annoying and useless.
#+begin_src C++ :includes '(iostream cassert) :results silent
template typename T1, typename T2
auto compose(T1 t1, T2 t2) - decltype(t1 + t2) { return t1+t2; }
int main() {
auto d=compose(std::string(ola),std::string(ciao)); //d's type is
std::string
auto i=compose(4,2);
assert(d== std::string(olaciao) i==6);
return 0
}
#+end_src
We can remove it by letting ob-C do the work by modifying the function
org-babel-C-ensure-main-wrap. Now the code looks (according to me) easier to
read
#+begin_src C++ :includes '(iostream cassert) :results silent
template typename T1, typename T2
auto compose(T1 t1, T2 t2) - decltype(t1 + t2) { return t1+t2; }
template
int compose(int t1,int t2) { return t1+t2; }
main
auto d=compose(std::string(ola),std::string(ciao)); //d's type is
std::string
auto i=compose(4,2);
assert(d== std::string(olaciao) i==6);
#+end_src
What do you think ?
Best
Ernesto
--
Eric Schulte
https://cs.unm.edu/~eschulte
PGP: 0x614CA05D (see https://u.fsf.org/yw)
Re: [O] babel: ob-C with Visual C++ and compilation-mode
Ernesto Durante stobos...@gmail.com writes: Thierry Banel tbanelweb...@free.fr writes: Le 15/08/2014 19:22, Ernesto Durante a écrit : True. And to achieve that the :includes header tag was added: #+BEGIN_SRC C++ :includes stdio.h (Because otherwise a #include statement would end up in the main() function) For me this is already a questionable distortion of C++. The Emacs C++-mode does no attempt at hiding parts of a C++ file. It just display the file as it is, and that is good. Yes, you are right. This is far too complex for me. I will just write down the main() function rather than learning this extension. But of course, I am just one user among others. You are another user and you feel the need for this extension, and this should be taken into account. Try the extension for yourself, then share it, and see if others like it. Yes, you are right. Perhaps a new header argument should be added for C-Family languages which will inhibit this main wrapping behavior? -- Eric -- Eric Schulte https://cs.unm.edu/~eschulte PGP: 0x614CA05D (see https://u.fsf.org/yw)
Re: [O] babel: ob-C with Visual C++ and compilation-mode
Thierry Banel tbanelweb...@free.fr writes:
You are trying to create a C++ project bigger than a few lines, in Org-mode.
This is very close to the idea of literate programming from Donal Knuth.
You may find inspiration here:
http://orgmode.org/worg/org-contrib/babel/intro.html#literate-programming
There is an example of a hello world shell project split over three source
blocks.
Here it is translated from Shell to C++ (try it, it works):
#+name: hello-world-prefix
#+begin_src C++ :exports none
printf (/---\\\n);
#+end_src
#+name: hello-world-postfix
#+begin_src C++ :exports none
printf (\\---/\n);
#+end_src
#+name: hello-world-main-begin
#+begin_src C++ :exports none
#include stdio.h
int main()
{
#+end_src
#+name: hello-world-main-end
#+begin_src C++ :exports none
return 0;
}
#+end_src
#+name: hello-world
#+begin_src C++ :tangle hello :exports none :noweb yes :results output
hello-world-main-begin
hello-world-prefix
printf (| hello world |\n);
hello-world-postfix
hello-world-main-end
#+end_src
#+RESULTS: hello-world
: /---\
: | hello world |
: \---/
Really interesting. We can take some blocks and combine them inside
a source block. Thanks for this information.
Another question if you allow me ?
Looking at code in Ob-C you transform a table/list variable in a C array
of char*. Should it not be std::wstring ? some unicode string ?
Best Ernesto
Re: [O] babel: ob-C with Visual C++ and compilation-mode
Thierry Banel tbanelweb...@free.fr writes: Le 15/08/2014 19:22, Ernesto Durante a écrit : True. And to achieve that the :includes header tag was added: #+BEGIN_SRC C++ :includes stdio.h (Because otherwise a #include statement would end up in the main() function) For me this is already a questionable distortion of C++. The Emacs C++-mode does no attempt at hiding parts of a C++ file. It just display the file as it is, and that is good. Yes, you are right. This is far too complex for me. I will just write down the main() function rather than learning this extension. But of course, I am just one user among others. You are another user and you feel the need for this extension, and this should be taken into account. Try the extension for yourself, then share it, and see if others like it. Yes, you are right. I think the problem we are trying to integrate C++/C like Lisp,Python,Haskell or programming languages which can rely on a session to share their content. In a way, the idea of Babel originated from such a session oriented languages. C++ is very different. We cannot inject codes through a online session. It's really a non sense. C++ is constructed around the idea of a project (or a Makefile). A typical C++ project holds header files + source files + a main file. As you have pointed out, the current C++ mode, is very specialized for dealing with a main file. It's right name should be something like :mainC++ . So how to deal with a C++ project ? I enjoy programming in Qt and I have been trying to integrate into Babel, a Qmake project. I finally end up by creating three specialized C++ mode: qheader, qsource and qmain. It was frustating because I couldn't reuse the standard C++ mode and in some way the core API in ob-C. It's my personal conclusion that orgmode gives a new light on C++/Qmake project by making it more accessible more easy to grasp. Does it make sense to you ? Thanks for all the ideas you submitted. Please stay involved. Thierry Thank you. Best Ernesto
Re: [O] babel: ob-C with Visual C++ and compilation-mode
Le 18/08/2014 13:19, Ernesto Durante a
écrit :
I think the problem we are trying to integrate C++/C like
Lisp,Python,Haskell or programming languages which can rely on a session
to share their content. In a way, the idea of Babel originated from such
a session oriented languages.
C++ is very different. We cannot inject codes through a online session.
It's really a non sense. C++ is constructed around the idea of a project
(or a Makefile). A typical C++ project holds header files + source files +
a main file.
As you have pointed out, the current C++ mode, is very specialized for
dealing with a main file. It's right name should be something
like :mainC++ .
So how to deal with a C++ project ?
I enjoy programming in Qt and I have been trying to integrate into Babel, a Qmake
project. I finally end up by creating three specialized C++ mode:
qheader, qsource and qmain. It was frustating because I couldn't reuse the
standard C++ mode and in some way the core API in ob-C.
It's my personal conclusion that orgmode gives a new light on C++/Qmake
project by making it more accessible more easy to grasp.
Does it make sense to you ?
You are trying to create a C++ project bigger than a few lines, in
Org-mode.
This is very close to the idea of "literate programming" from Donal
Knuth.
You may find inspiration here:
http://orgmode.org/worg/org-contrib/babel/intro.html#literate-programming
There is an example of a "hello world" shell project split over
three source blocks.
Here it is translated from Shell to C++ (try it, it works):
#+name: hello-world-prefix
#+begin_src C++ :exports none
printf
("/---\\\n");
#+end_src
#+name: hello-world-postfix
#+begin_src C++ :exports none
printf
("\\---/\n");
#+end_src
#+name: hello-world-main-begin
#+begin_src C++ :exports none
#include stdio.h
int main()
{
#+end_src
#+name: hello-world-main-end
#+begin_src C++ :exports none
return 0;
}
#+end_src
#+name: hello-world
#+begin_src C++ :tangle hello :exports none :noweb yes :results
output
hello-world-main-begin
hello-world-prefix
printf ("| hello
world |\n");
hello-world-postfix
hello-world-main-end
#+end_src
#+RESULTS: hello-world
: /---\
: | hello world |
: \---/
Re: [O] babel: ob-C with Visual C++ and compilation-mode
Le 15/08/2014 19:22, Ernesto Durante a écrit : I agree with you. Creating a new syntax is not a good idea. However, in some way, ob-C has created a new syntax implicitly by instantiating a new main in absence of such a function in the source block. True. And to achieve that the :includes header tag was added: #+BEGIN_SRC C++ :includes stdio.h (Because otherwise a #include statement would end up in the main() function) For me this is already a questionable distortion of C++. The Emacs C++-mode does no attempt at hiding parts of a C++ file. It just display the file as it is, and that is good. So why not to extend this idea by allowing a user defined function to parse the source block. The default function is clearly org-babel-C-ensure-main-wrap. We could create a new header :wrap which replaces :main and holds the user defined function. It can take three values nil, org-babel-C-ensure-main-wrap(default), or user-defined-function. So, in this way user-defined-function holds my own syntax for my future presentation. What do you think ? This is far too complex for me. I will just write down the main() function rather than learning this extension. But of course, I am just one user among others. You are another user and you feel the need for this extension, and this should be taken into account. Try the extension for yourself, then share it, and see if others like it. Thanks for all the ideas you submitted. Please stay involved. Thierry
Re: [O] babel: ob-C with Visual C++ and compilation-mode
Well... In this example, we go down from 9 lines to 7 lines. Ok fair. But the price is a new syntax to learn: main Is it wise to add an org-mode specific syntax to C++ (which already has a lot) ? Being noisy is a weakness of C++. I think it is not the responsibility of org-mode to fix that. Now, org-mode is already able to process main()-less blocks in simple cases. #+BEGIN_SRC C++ printf(hello\n); #+END_SRC If we can find a way to extend this feature to more cases, without needing a long documentation, then, sure, it would be a nice improvement. I agree with you. Creating a new syntax is not a good idea. However, in some way, ob-C has created a new syntax implicitly by instantiating a new main in absence of such a function in the source block. So why not to extend this idea by allowing a user defined function to parse the source block. The default function is clearly org-babel-C-ensure-main-wrap. We could create a new header :wrap which replaces :main and holds the user defined function. It can take three values nil, org-babel-C-ensure-main-wrap(default), or user-defined-function. So, in this way user-defined-function holds my own syntax for my future presentation. What do you think ? Best Ernesto
Re: [O] babel: ob-C with Visual C++ and compilation-mode
Le 13/08/2014 22:58, Ernesto Durante a écrit :
Thank you Thierry for your answer and all the details. I really want to be a
contributor
and help ob-C to improve (as well as can do a modest lisper).
Any help is welcome !
I tried to find a way to master Cx11 and babel is helping me a lot.
I think babel can really accelerate learning and dissimation of C++.
In this perspective, I have another very simple idea that I want to share
with you. I find C++ too noisy.
Yes, indeed.
In the following piece of code
I really find the presence of the main call and the return statement really
annoying and useless.
#+begin_src C++ :includes '(iostream cassert) :results silent
template typename T1, typename T2
auto compose(T1 t1, T2 t2) - decltype(t1 + t2) { return t1+t2; }
int main() {
auto d=compose(std::string(ola),std::string(ciao)); //d's type is
std::string
auto i=compose(4,2);
assert(d== std::string(olaciao) i==6);
return 0
}
#+end_src
We can remove it by letting ob-C do the work by modifying the function
org-babel-C-ensure-main-wrap. Now the code looks (according to me) easier to
read
#+begin_src C++ :includes '(iostream cassert) :results silent
template typename T1, typename T2
auto compose(T1 t1, T2 t2) - decltype(t1 + t2) { return t1+t2; }
template
int compose(int t1,int t2) { return t1+t2; }
main
auto d=compose(std::string(ola),std::string(ciao)); //d's type is
std::string
auto i=compose(4,2);
assert(d== std::string(olaciao) i==6);
#+end_src
What do you think ?
Well... In this example, we go down from 9 lines to 7 lines. Ok fair.
But the price is a new syntax to learn:
main
Is it wise to add an org-mode specific syntax to C++ (which already has
a lot) ?
Being noisy is a weakness of C++.
I think it is not the responsibility of org-mode to fix that.
Now, org-mode is already able to process main()-less blocks in simple cases.
#+BEGIN_SRC C++
printf(hello\n);
#+END_SRC
If we can find a way to extend this feature to more cases,
without needing a long documentation,
then, sure, it would be a nice improvement.
Regards
Thierry
Re: [O] babel: ob-C with Visual C++ and compilation-mode
Thierry Banel tbanelweb...@free.fr writes:
I have identified a minor bug. When a source code block has the mode
cpp, we cannot expand the code or more precisely the code is not
expanded in the correct way because the following function is missing
(defun org-babel-expand-body:cpp (body params)
Execute BODY according to PARAMS.This function calls
`org-babel-expand-body:C++'.
(org-babel-expand-body:C++ body params))
Thanks for reporting this ! You may consider submitting a patch for this
bug. The comment Execute BODY ... should be changed to Expand BODY
Ok I will change the comment
Best
Ernesto
You are very welcome
Thierry
Thank you Thierry for your answer and all the details. I really want to be a
contributor
and help ob-C to improve (as well as can do a modest lisper).
I tried to find a way to master Cx11 and babel is helping me a lot.
I think babel can really accelerate learning and dissimation of C++.
In this perspective, I have another very simple idea that I want to share
with you. I find C++ too noisy. In the following piece of code
I really find the presence of the main call and the return statement really
annoying and useless.
#+begin_src C++ :includes '(iostream cassert) :results silent
template typename T1, typename T2
auto compose(T1 t1, T2 t2) - decltype(t1 + t2) { return t1+t2; }
int main() {
auto d=compose(std::string(ola),std::string(ciao)); //d's type is
std::string
auto i=compose(4,2);
assert(d== std::string(olaciao) i==6);
return 0
}
#+end_src
We can remove it by letting ob-C do the work by modifying the function
org-babel-C-ensure-main-wrap. Now the code looks (according to me) easier to
read
#+begin_src C++ :includes '(iostream cassert) :results silent
template typename T1, typename T2
auto compose(T1 t1, T2 t2) - decltype(t1 + t2) { return t1+t2; }
template
int compose(int t1,int t2) { return t1+t2; }
main
auto d=compose(std::string(ola),std::string(ciao)); //d's type is
std::string
auto i=compose(4,2);
assert(d== std::string(olaciao) i==6);
#+end_src
What do you think ?
Best
Ernesto
Re: [O] babel: ob-C with Visual C++ and compilation-mode
Thierry Banel tbanelweb...@free.fr writes: Le 04/08/2014 18:16, Ernesto Durante a écrit : One suggestion. It will be nice to put the error buffer in compilation-mode, this way errors are highlighted and we can jump directly into the source code. I modified org-babel-eval to launch the compilation mode in case of errors. I also removed the read-only attribute, else the buffer content of org-babel-error-buffer-name cannot be erased. The compilation mode is a very good idea ! I tried it. Clearly, it's not a good patch because org-babel-eval seems to be a core function in babel. Maybe for ob-C, this function should be replaced by a new function. It works well for C++, D, Dot It fails for Perl, R, Elisp But when it fails, it does not do any harm: the behavior is as before. So... I vote for your patch. Hi Thierry, Thanks you but I don't know who is responsible to apply the patch. As you are a contributor and author of ob-C, maybe you know how to proceed. I have identified a minor bug. When a source code block has the mode cpp, we cannot expand the code or more precisely the code is not expanded in the correct way because the following function is missing (defun org-babel-expand-body:cpp (body params) Execute BODY according to PARAMS.This function calls `org-babel-expand-body:C++'. (org-babel-expand-body:C++ body params)) Best Ernesto
Re: [O] babel: ob-C with Visual C++ and compilation-mode
Le 12/08/2014 16:24, Ernesto Durante a écrit : Hi Thierry, Thanks you but I don't know who is responsible to apply the patch. I have been in touch with Eric Schulte and Bastien Guerry who are both maintainers. Probably Eric is the right person, as he is very involved in all Babel subjects. I am not aware of any criteria for accepting a contribution. Contributions are always welcome. Sending them to the mailing list (as you did) is the best way to discuss them. As you are a contributor and author of ob-C, maybe you know how to proceed. You may want to read this page: http://orgmode.org/worg/org-contribute.html Your patch seems to change less than 15 lines. If this is confirmed, then your proposal falls in the tiny change category. Tiny changes do not need the assignment contract with the FSF. However you may want to sign the assignment with the FSF anyway if you intend to contribute more. (The Free Software Foundation holds the copyright for Gnu Emacs, Org-mode being part of Emacs). I signed the assignment. It took several weeks. It covers any future contribution I may submit. Technically, the best way to submit your patch is to generate a file with the git format-patch command, then send it to the mailing list. Obviously you are familiar with Git. Otherwise, read the explanations in the aforementioned page. You will need to pay attention to the commit message you will write, in order to be consistent with all other commit messages. I have identified a minor bug. When a source code block has the mode cpp, we cannot expand the code or more precisely the code is not expanded in the correct way because the following function is missing (defun org-babel-expand-body:cpp (body params) Execute BODY according to PARAMS.This function calls `org-babel-expand-body:C++'. (org-babel-expand-body:C++ body params)) Thanks for reporting this ! You may consider submitting a patch for this bug. The comment Execute BODY ... should be changed to Expand BODY Best Ernesto You are very welcome Thierry
Re: [O] babel: ob-C with Visual C++ and compilation-mode
Le 04/08/2014 18:16, Ernesto Durante a écrit : One suggestion. It will be nice to put the error buffer in compilation-mode, this way errors are highlighted and we can jump directly into the source code. I modified org-babel-eval to launch the compilation mode in case of errors. I also removed the read-only attribute, else the buffer content of org-babel-error-buffer-name cannot be erased. The compilation mode is a very good idea ! I tried it. Clearly, it's not a good patch because org-babel-eval seems to be a core function in babel. Maybe for ob-C, this function should be replaced by a new function. It works well for C++, D, Dot It fails for Perl, R, Elisp But when it fails, it does not do any harm: the behavior is as before. So... I vote for your patch. Thanks to everyone for orgmode and babel to exist. Best Ernesto
[O] babel: ob-C with Visual C++ and compilation-mode
Hi, I am using ob-C with gcc and Microsoft Visual C++. These two compilers have two different behaviours for outputting errors. Gcc uses the standard error output and Visual C++ uses the regular output. Under Windows, errors are not displayed because of the way org-babel-eval is coded. To work on both platforms, the standard output must be concatenated with the standard error. I modified the org-babel-eval in the following way. diff --git a/lisp/ob-eval.el b/lisp/ob-eval.el index 057590f..1a93460 100644 --- a/lisp/ob-eval.el +++ b/lisp/ob-eval.el @@ -53,12 +53,20 @@ STDERR with `org-babel-eval-error-notify'. (setq exit-code (org-babel--shell-command-on-region (point-min) (point-max) cmd err-buff)) - (if (or (not (numberp exit-code)) ( exit-code 0)) - (progn - (with-current-buffer err-buff - (org-babel-eval-error-notify exit-code (buffer-string))) - nil) - (buffer-string) + (let ((temp-buffer-str (buffer-string))) ;;temp-buffer-str holds standard output + body + (if (or (not (numberp exit-code)) ( exit-code 0)) + (progn + (with-current-buffer err-buff + (org-babel-eval-error-notify exit-code (format %s%s temp-buffer-str (buffer-string))) + ) + (save-excursion + (when (get-buffer org-babel-error-buffer-name) + (with-current-buffer org-babel-error-buffer-name + (compilation-mode) + (read-only-mode 0) + ))) + nil) + temp-buffer-str) One suggestion. It will be nice to put the error buffer in compilation-mode, this way errors are highlighted and we can jump directly into the source code. I modified org-babel-eval to launch the compilation mode in case of errors. I also removed the read-only attribute, else the buffer content of org-babel-error-buffer-name cannot be erased. Clearly, it's not a good patch because org-babel-eval seems to be a core function in babel. Maybe for ob-C, this function should be replaced by a new function. Thanks to everyone for orgmode and babel to exist. Best Ernesto
