babel: ob-C with Visual C++ and compilation-mode

babel: ob-C with Visual C++ and compilation-mode

[Ernesto Durante]

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

Re: babel: ob-C with Visual C++ and compilation-mode

[Thierry Banel]

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
>
>

Re: babel: ob-C with Visual C++ and compilation-mode

[Ernesto Durante]

Thierry Banel <tbanelwebmin@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: babel: ob-C with Visual C++ and compilation-mode

[Thierry Banel]

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: babel: ob-C with Visual C++ and compilation-mode

[Ernesto Durante]

Thierry Banel <tbanelwebmin@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: babel: ob-C with Visual C++ and compilation-mode

[Thierry Banel]

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: babel: ob-C with Visual C++ and compilation-mode

[Ernesto Durante]

> 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: babel: ob-C with Visual C++ and compilation-mode

[Thierry Banel]

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: babel: ob-C with Visual C++ and compilation-mode

[Ernesto Durante]

Thierry Banel <tbanelwebmin@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: babel: ob-C with Visual C++ and compilation-mode

[Eric Schulte]

Ernesto Durante <stobossey@gmail.com> writes:

> Thierry Banel <tbanelwebmin@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: babel: ob-C with Visual C++ and compilation-mode

[Ernesto Durante]

Eric Schulte <schulte.eric@gmail.com> writes:

> Ernesto Durante <stobossey@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: babel: ob-C with Visual C++ and compilation-mode

[Eric Schulte]

Ernesto Durante <stobossey@gmail.com> writes:

> Eric Schulte <schulte.eric@gmail.com> writes:
>
>> Ernesto Durante <stobossey@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: babel: ob-C with Visual C++ and compilation-mode

[Thierry Banel]

[-- Attachment #1: Type: text/html, Size: 3755 bytes --]

Re: babel: ob-C with Visual C++ and compilation-mode

[Ernesto Durante]

Thierry Banel <tbanelwebmin@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: babel: ob-C with Visual C++ and compilation-mode

[Thierry Banel]

[-- Attachment #1: Type: text/html, Size: 1211 bytes --]

Re: babel: ob-C with Visual C++ and compilation-mode

[Ernesto Durante]

Thierry Banel <tbanelwebmin@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: babel: ob-C with Visual C++ and compilation-mode

[Thierry Banel]

[-- Attachment #1: Type: text/html, Size: 1469 bytes --]

Re: babel: ob-C with Visual C++ and compilation-mode

[Eric Schulte]

Ernesto Durante <stobossey@gmail.com> writes:

> Thierry Banel <tbanelwebmin@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: babel: ob-C with Visual C++ and compilation-mode

[Eric Schulte]

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 <stobossey@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: babel: ob-C with Visual C++ and compilation-mode

[Ernesto Durante]

Eric Schulte <schulte.eric@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: [PATCH] babel: ob-C with Visual C++ and compilation-mode

[Ernesto Durante]

[-- Attachment #1: Type: text/plain, Size: 412 bytes --]

Eric Schulte <schulte.eric@gmail.com> writes:

Hi Eric,

You will find in attachment three patches

+ First patch, modify org-babel-eval to load compilation-mode in case of errors 

+ Second patch, modify org-babel-eval to deal with Microsoft visual
C++ errors by concatenating the standard output with the standard error

+ Third patch, add to ob-C the missing function org-babel-expand-body:cpp

Best
Ernesto


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-org-babel-eval-compilation-mode-to-deal-with-errors-.patch --]
[-- Type: text/x-patch, Size: 886 bytes --]

From 3e4f163a2b357c58a52b7811539ff4032d432aaf Mon Sep 17 00:00:00 2001
From: Ernesto Durante <edurante@localhost.localdomain>
Date: Mon, 25 Aug 2014 17:27:24 +0200
Subject: [PATCH 1/3] org-babel-eval: compilation-mode to deal with errors in
 (C/C++/D)

---
 lisp/ob-eval.el | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/lisp/ob-eval.el b/lisp/ob-eval.el
index 057590f..9fbbb42 100644
--- a/lisp/ob-eval.el
+++ b/lisp/ob-eval.el
@@ -57,6 +57,12 @@ STDERR with `org-babel-eval-error-notify'."
 	  (progn
 	    (with-current-buffer err-buff
 	      (org-babel-eval-error-notify exit-code (buffer-string)))
+	    (save-excursion
+	      (when (get-buffer org-babel-error-buffer-name)
+		(with-current-buffer org-babel-error-buffer-name
+		  (compilation-mode)
+		  ;;compilation-mode enforces read-only
+		  (read-only-mode 0))))
 	    nil)
 	(buffer-string)))))
 
-- 
1.8.3.1


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: 0002-org-babel-eval-showing-Microsoft-Visual-C-errors.patch --]
[-- Type: text/x-patch, Size: 1702 bytes --]

From 9e306dbb39325998a5149840b229ffa802ec40e9 Mon Sep 17 00:00:00 2001
From: Ernesto Durante <edurante@localhost.localdomain>
Date: Mon, 25 Aug 2014 17:54:51 +0200
Subject: [PATCH 2/3] org-babel-eval: showing Microsoft Visual C++ errors

---
 lisp/ob-eval.el | 27 +++++++++++++++------------
 1 file changed, 15 insertions(+), 12 deletions(-)

diff --git a/lisp/ob-eval.el b/lisp/ob-eval.el
index 9fbbb42..0e69583 100644
--- a/lisp/ob-eval.el
+++ b/lisp/ob-eval.el
@@ -53,18 +53,21 @@ 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)))
-	    (save-excursion
-	      (when (get-buffer org-babel-error-buffer-name)
-		(with-current-buffer org-babel-error-buffer-name
-		  (compilation-mode)
-		  ;;compilation-mode enforces read-only
-		  (read-only-mode 0))))
-	    nil)
-	(buffer-string)))))
+      (let ((outb-str (buffer-string)))
+	;;outb-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
+					     (concat outb-str (buffer-string))))
+	      (save-excursion
+		(when (get-buffer org-babel-error-buffer-name)
+		  (with-current-buffer org-babel-error-buffer-name
+		    (compilation-mode)
+		    ;;compilation-mode enforces read-only
+		    (read-only-mode 0))))
+	      nil)
+	  outb-str)))))
 
 (defun org-babel-eval-read-file (file)
   "Return the contents of FILE as a string."
-- 
1.8.3.1


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #4: 0003-ob-C-fix-missing-function-org-babel-expand-body-cpp.patch --]
[-- Type: text/x-patch, Size: 893 bytes --]

From c93e02a52d57a5eeb7b9b8aba04c6764f8122d5c Mon Sep 17 00:00:00 2001
From: Ernesto Durante <edurante@localhost.localdomain>
Date: Mon, 25 Aug 2014 18:16:01 +0200
Subject: [PATCH 3/3] ob-C: fix missing function org-babel-expand-body:cpp

---
 lisp/ob-C.el | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/lisp/ob-C.el b/lisp/ob-C.el
index 2e146d4..076276e 100644
--- a/lisp/ob-C.el
+++ b/lisp/ob-C.el
@@ -82,6 +82,11 @@ is currently being evaluated.")
 This function calls `org-babel-execute:C++'."
   (org-babel-execute:C++ body params))
 
+(defun org-babel-expand-body:cpp (body params)
+  "Expand a block of C++ code with org-babel according to it's
+header arguments."
+  (org-babel-expand-body:C++ body params))
+
 (defun org-babel-execute:C++ (body params)
   "Execute a block of C++ code with org-babel.
 This function is called by `org-babel-execute-src-block'."
-- 
1.8.3.1


[-- Attachment #5: Type: text/plain, Size: 2688 bytes --]




> 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 <stobossey@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
>>

Re: [PATCH] babel: ob-C with Visual C++ and compilation-mode

[Eric Schulte]

Ernesto Durante <stobossey@gmail.com> writes:

> Eric Schulte <schulte.eric@gmail.com> writes:
>
> Hi Eric,
>
> You will find in attachment three patches
>

Hi Ernesto,

Thank you for sending these along, they look great.

>
> + First patch, modify org-babel-eval to load compilation-mode in case
>of errors
>

Applied.

>
> + Second patch, modify org-babel-eval to deal with Microsoft visual
> C++ errors by concatenating the standard output with the standard error
>

Not applied.  I believe that concatenating STDOUT to STDERR for *every*
language simply because Microsoft Visual Studio does not correctly use
STDERR is not the correct approach here.  Perhaps a more tailored
solution may be possible for this problem which will not have global
effects.

>
> + Third patch, add to ob-C the missing function
>org-babel-expand-body:cpp
>

Applied.

Thanks!
Eric

>
> Best
> Ernesto
>
> From 3e4f163a2b357c58a52b7811539ff4032d432aaf Mon Sep 17 00:00:00 2001
> From: Ernesto Durante <edurante@localhost.localdomain>
> Date: Mon, 25 Aug 2014 17:27:24 +0200
> Subject: [PATCH 1/3] org-babel-eval: compilation-mode to deal with errors in
>  (C/C++/D)
>
> ---
>  lisp/ob-eval.el | 6 ++++++
>  1 file changed, 6 insertions(+)
>
> diff --git a/lisp/ob-eval.el b/lisp/ob-eval.el
> index 057590f..9fbbb42 100644
> --- a/lisp/ob-eval.el
> +++ b/lisp/ob-eval.el
> @@ -57,6 +57,12 @@ STDERR with `org-babel-eval-error-notify'."
>  	  (progn
>  	    (with-current-buffer err-buff
>  	      (org-babel-eval-error-notify exit-code (buffer-string)))
> +	    (save-excursion
> +	      (when (get-buffer org-babel-error-buffer-name)
> +		(with-current-buffer org-babel-error-buffer-name
> +		  (compilation-mode)
> +		  ;;compilation-mode enforces read-only
> +		  (read-only-mode 0))))
>  	    nil)
>  	(buffer-string)))))
>  
> -- 
> 1.8.3.1
>
> From 9e306dbb39325998a5149840b229ffa802ec40e9 Mon Sep 17 00:00:00 2001
> From: Ernesto Durante <edurante@localhost.localdomain>
> Date: Mon, 25 Aug 2014 17:54:51 +0200
> Subject: [PATCH 2/3] org-babel-eval: showing Microsoft Visual C++ errors
>
> ---
>  lisp/ob-eval.el | 27 +++++++++++++++------------
>  1 file changed, 15 insertions(+), 12 deletions(-)
>
> diff --git a/lisp/ob-eval.el b/lisp/ob-eval.el
> index 9fbbb42..0e69583 100644
> --- a/lisp/ob-eval.el
> +++ b/lisp/ob-eval.el
> @@ -53,18 +53,21 @@ 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)))
> -	    (save-excursion
> -	      (when (get-buffer org-babel-error-buffer-name)
> -		(with-current-buffer org-babel-error-buffer-name
> -		  (compilation-mode)
> -		  ;;compilation-mode enforces read-only
> -		  (read-only-mode 0))))
> -	    nil)
> -	(buffer-string)))))
> +      (let ((outb-str (buffer-string)))
> +	;;outb-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
> +					     (concat outb-str (buffer-string))))
> +	      (save-excursion
> +		(when (get-buffer org-babel-error-buffer-name)
> +		  (with-current-buffer org-babel-error-buffer-name
> +		    (compilation-mode)
> +		    ;;compilation-mode enforces read-only
> +		    (read-only-mode 0))))
> +	      nil)
> +	  outb-str)))))
>  
>  (defun org-babel-eval-read-file (file)
>    "Return the contents of FILE as a string."
> -- 
> 1.8.3.1
>
> From c93e02a52d57a5eeb7b9b8aba04c6764f8122d5c Mon Sep 17 00:00:00 2001
> From: Ernesto Durante <edurante@localhost.localdomain>
> Date: Mon, 25 Aug 2014 18:16:01 +0200
> Subject: [PATCH 3/3] ob-C: fix missing function org-babel-expand-body:cpp
>
> ---
>  lisp/ob-C.el | 5 +++++
>  1 file changed, 5 insertions(+)
>
> diff --git a/lisp/ob-C.el b/lisp/ob-C.el
> index 2e146d4..076276e 100644
> --- a/lisp/ob-C.el
> +++ b/lisp/ob-C.el
> @@ -82,6 +82,11 @@ is currently being evaluated.")
>  This function calls `org-babel-execute:C++'."
>    (org-babel-execute:C++ body params))
>  
> +(defun org-babel-expand-body:cpp (body params)
> +  "Expand a block of C++ code with org-babel according to it's
> +header arguments."
> +  (org-babel-expand-body:C++ body params))
> +
>  (defun org-babel-execute:C++ (body params)
>    "Execute a block of C++ code with org-babel.
>  This function is called by `org-babel-execute-src-block'."

-- 
Eric Schulte
https://cs.unm.edu/~eschulte
PGP: 0x614CA05D (see https://u.fsf.org/yw)

Re: [PATCH] babel: ob-C with Visual C++ and compilation-mode

[Achim Gratz]

Eric Schulte writes:
> Ernesto Durante <stobossey@gmail.com> writes:
>> + First patch, modify org-babel-eval to load compilation-mode in case
>>of errors
>>
>
> Applied.

These are missing a proper changelog so Bastien will be less happy. 

>> org-babel-eval: compilation-mode to deal with errors in (C/C++/D)

Despite the title, the change is implemented for all Babel error
buffers.  I'm not sure that's the right thing to do, but I don't see
off-hand how to easily make this a per-language setting.

>> +		  (compilation-mode)

Setting a mode from within lisp is pretty heavy-handed.  Since we're
calling upon an existing buffer we should check if it's already in that
mode.

>> +		  ;;compilation-mode enforces read-only
>> +		  (read-only-mode 0))))

That doesn't work on Emacs < 24.3 and does a few other things that again
should not be done from Lisp.  I'll change this to just

 (setq buffer-read-only nil)

but compilation mode in an editable buffer is somewhat strange.  Instead
we should probably bind (inhibit-read-only t) around those places where
Babel wants to modify the buffer, but I'm not sure how to easily find
them all.

(Done in ec8f245.)


Regards
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds