C++ is not accepted for SRC block evaluation

C++ is not accepted for SRC block evaluation

[Van L]

Hello.

The `m-x customize’ path to `org-babel-load-languages’ or the following method won’t accept C++.

#+BEGIN_SRC elisp :results none
  (org-babel-do-load-languages
   'org-babel-load-languages
   '((C++ . t)))
#+END_SRC

The messages buffer has the following.

   executing Elisp code block...
   org-babel-do-load-languages: Cannot open load file: No such file or directory, ob-C++

M-x org-version
Org mode version 9.1.9

M-x emacs-version
GNU Emacs 26.1
rc1

Section 14.7 Languages in the Org Mode working with source code infopages lists C++.

Re: C++ is not accepted for SRC block evaluation

[John Kitchin]

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

It should be (C . t)

it looks like ob-C also handles C++.

John

-----------------------------------
Professor John Kitchin
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
@johnkitchin
http://kitchingroup.cheme.cmu.edu


On Sat, May 26, 2018 at 5:15 AM, Van L <van@scratch.space> wrote:

> Hello.
>
> The `m-x customize’ path to `org-babel-load-languages’ or the following
> method won’t accept C++.
>
> #+BEGIN_SRC elisp :results none
>   (org-babel-do-load-languages
>    'org-babel-load-languages
>    '((C++ . t)))
> #+END_SRC
>
> The messages buffer has the following.
>
>    executing Elisp code block...
>    org-babel-do-load-languages: Cannot open load file: No such file or
> directory, ob-C++
>
> M-x org-version
> Org mode version 9.1.9
>
> M-x emacs-version
> GNU Emacs 26.1
> rc1
>
> Section 14.7 Languages in the Org Mode working with source code infopages
> lists C++.
>

[-- Attachment #2: Type: text/html, Size: 2852 bytes --]

Re: C++ is not accepted for SRC block evaluation

[Van L]

> John Kitchin writes:
> 
> It should be (C . t)
> 
> it looks like ob-C also handles C++.

> Section 14.7 Languages in the Org Mode working with source code infopages lists C++.

Thanks.

How about the following to update the documentation:

#+BEGIN_EXAMPLE
  diff --git a/doc/misc/org.texi b/doc/misc/org.texi
  index cf1c037..7b00f0a 100644
  --- a/doc/misc/org.texi
  +++ b/doc/misc/org.texi
  @@ -15522,7 +15522,8 @@ Languages
   @multitable @columnfractions 0.25 0.25 0.25 0.25
   @headitem @b{Language} @tab @b{Identifier} @tab @b{Language} @tab @b{Identifier}
   @item Asymptote @tab asymptote @tab Awk @tab awk
  -@item C @tab C @tab C++ @tab C++
  +@c @item C @tab C @tab C++ @tab C++
  +@item C++ @tab C @tab C @tab C
   @item Clojure @tab clojure @tab CSS @tab css
   @item D @tab d @tab ditaa @tab ditaa
   @item Graphviz @tab dot @tab Emacs Calc @tab calc
#+END_EXAMPLE

Combining C/C++ to C in one field frees up a slot for Texinfo, texi.

Re: C++ is not accepted for SRC block evaluation

[Nicolas Goaziou]

Hello,

Van L <van@scratch.space> writes:

>> John Kitchin writes:
>> 
>> It should be (C . t)
>> 
>> it looks like ob-C also handles C++.
>
> How about the following to update the documentation:
>
> #+BEGIN_EXAMPLE
>   diff --git a/doc/misc/org.texi b/doc/misc/org.texi
>   index cf1c037..7b00f0a 100644
>   --- a/doc/misc/org.texi
>   +++ b/doc/misc/org.texi
>   @@ -15522,7 +15522,8 @@ Languages
>    @multitable @columnfractions 0.25 0.25 0.25 0.25
>    @headitem @b{Language} @tab @b{Identifier} @tab @b{Language} @tab @b{Identifier}
>    @item Asymptote @tab asymptote @tab Awk @tab awk
>   -@item C @tab C @tab C++ @tab C++
>   +@c @item C @tab C @tab C++ @tab C++
>   +@item C++ @tab C @tab C @tab C
>    @item Clojure @tab clojure @tab CSS @tab css
>    @item D @tab d @tab ditaa @tab ditaa
>    @item Graphviz @tab dot @tab Emacs Calc @tab calc
> #+END_EXAMPLE

No, that's not correct. It should be (C++ . t), but "ob-C.el" should
provide "ob-C++" feature, too.

I pushed a fix along those lines in master.

Thank you.

Regards,

-- 
Nicolas Goaziou

Re: C++ is not accepted for SRC block evaluation

[Aaron Ecay]

Hi Nicolas,

2018ko maiatzak 27an, Nicolas Goaziou-ek idatzi zuen:

[...]

> No, that's not correct. It should be (C++ . t), but "ob-C.el" should
> provide "ob-C++" feature, too.

Is this right?  Even if the feature is provide-d by the file, the require
in org-babel-do-load-languages will not find it (because the file name
does not match).  C++ is not a valid choice for the variable AFAICT.  The
customize interface makes that clear by not offering it as an option, but
if the variable is customized outside of customize (so to speak...) chaos
reigns...

-- 
Aaron Ecay

Re: C++ is not accepted for SRC block evaluation

[Nicolas Goaziou]

Aaron Ecay <aaronecay@gmail.com> writes:

> Is this right?  Even if the feature is provide-d by the file, the require
> in org-babel-do-load-languages will not find it (because the file name
> does not match).  C++ is not a valid choice for the variable AFAICT.  The
> customize interface makes that clear by not offering it as an option, but
> if the variable is customized outside of customize (so to speak...) chaos
> reigns...

You are right, the change is not sufficient, although it doesn't make
things worse. We could modify `org-babel-load-languages' defcustom and
add lines:

   (const :tag "C++" C)
   (const :tag "D" C)

which would do the job from Customize, but not for a user changing the
variable outside it, as you point out.

We probably need to implement a mapping between languages symbols and
files and use it in `org-babel-do-load-languages'. The implicit mapping
it uses currently has shortcomings.

We could also leave it like this (even with my patch reverted), and
document it somehow. Maybe a third column per language in (info "(org)
Languages") to hold the file name.

WDYT?

Re: C++ is not accepted for SRC block evaluation

[Aaron Ecay]

Hi Nicolas,

2018ko maiatzak 27an, Nicolas Goaziou-ek idatzi zuen:

[...]

> 
> We probably need to implement a mapping between languages symbols and
> files and use it in `org-babel-do-load-languages'. The implicit mapping
> it uses currently has shortcomings.
> 
> We could also leave it like this (even with my patch reverted), and
> document it somehow. Maybe a third column per language in (info "(org)
> Languages") to hold the file name.
> 
> WDYT?

Improved documentation is never a bad thing.  OTOH, I personally would
not spend time on implementing the mapping you propose.
org-babel-do-load-languages is IMO a relic.  I think that all babel
languages should be autoloaded, just like normal lisp libraries are.

If I had to sketch a design for this, it would be a macro like:

(org-babel-define-language R
  :evaluate org-babel-R-evaluate
  :session org-babel-R-creaete-session
  :language-name "R"              ;; Both these Could be optional, with the
  :language-mode R-mode           ;; default calculated from the language name
  ...)

This macro would expand to:

(add-to-list org-src-lang-modes ...)
(add-to-list org-babel-tangle-lang-exts ...)
;; Possibly some others ...
(add-to-list org-babel-languages-alist
             '(R . (evaluate . org-babel-R-evaluate)
                   (session . org-babel-R-create-session)
                   ...))

The intent of the last one would be to get rid of all the
(fboundp (intern (concat "org-babel-thingy:" language))) stuff.

The org-babel-define-language call(s) in each ob-foo.el file would be
marked as autoloads, so that the relevant alists would all be fully
populated on emacs startup.  org-babel-(do-)load-languages would
disappear.

Iʼve held back on implementing this (among other reasons) because it
would be a big disruption to the babel ecosystem.  For all the languages
in core and contrib it would be manageable, but there are third-party
libraries that would have to be transitioned as well, plus the growing
pains of user config files, etc.  It would not be a small project.

(OTOH, I see other benefits as well.  In the longer term, it would be
nice to solve the longstanding problems with e.g. the python backend
by communicating with a jupyter kernel, rather than trying to drive a
python repl attached to a pipe.  A more manageable API for babel
languages than (fboundp (intern "magic-name")) would probably make it
easier to implement this.)

...in any case, the mapping that you propose is not an unreasonable idea in
the abstract.  But the problem only arises (AFAIK) for the C++/D languages,
and itʼs been with us for a long time.  My own opinion is that we can just
document and live with the situation until something much better comes
along.  But I also donʼt want to stop you from implementing a small and
reasonable fix if you are motivated to do so. :)

-- 
Aaron Ecay

Re: C++ is not accepted for SRC block evaluation

[Nicolas Goaziou]

Hello,

Aaron Ecay <aaronecay@gmail.com> writes:

> Improved documentation is never a bad thing.  OTOH, I personally would
> not spend time on implementing the mapping you propose.

I simply added a footnote about C++ and D languages.

> org-babel-do-load-languages is IMO a relic.  I think that all babel
> languages should be autoloaded, just like normal lisp libraries are.

But we still need a mechanism to selectively allow evaluation of some
source blocks based on their language. I guess some users expect to have
this.

Otherwise, it sounds good.

> If I had to sketch a design for this, it would be a macro like:
>
> (org-babel-define-language R
>   :evaluate org-babel-R-evaluate
>   :session org-babel-R-creaete-session
>   :language-name "R"              ;; Both these Could be optional, with the
>   :language-mode R-mode           ;; default calculated from the language name
>   ...)
>
> This macro would expand to:
>
> (add-to-list org-src-lang-modes ...)
> (add-to-list org-babel-tangle-lang-exts ...)
> ;; Possibly some others ...
> (add-to-list org-babel-languages-alist
>              '(R . (evaluate . org-babel-R-evaluate)
>                    (session . org-babel-R-create-session)
>                    ...))

On the implementation side of things, I suggest to stay away from macros
whenever possible. It would make sense, however, to define a language as
a defstruct, much like we do for export back-ends.

In any case, I like this idea.

> Iʼve held back on implementing this (among other reasons) because it
> would be a big disruption to the babel ecosystem.  For all the languages
> in core and contrib it would be manageable, but there are third-party
> libraries that would have to be transitioned as well, plus the growing
> pains of user config files, etc.  It would not be a small project.

This change would entail a new major release, indeed. I think it is
largely worth the incompatible changes it would introduce. BTW, we could
still support old variables and functions. E.g., if language Foo is not
defined as a proper defstruct, look for the old system to load it and
send a deprecation warning about it.

Regards,

-- 
Nicolas Goaziou

Re: C++ is not accepted for SRC block evaluation

[Berry, Charles]

> On May 30, 2018, at 4:11 AM, Nicolas Goaziou <mail@nicolasgoaziou.fr> wrote:
> 
> Hello,
> 
> Aaron Ecay <aaronecay@gmail.com> writes:
> 
>> Improved documentation is never a bad thing.  OTOH, I personally would
>> not spend time on implementing the mapping you propose.
> 
> I simply added a footnote about C++ and D languages.
> 
>> org-babel-do-load-languages is IMO a relic.  I think that all babel
>> languages should be autoloaded, just like normal lisp libraries are.
> 
> But we still need a mechanism to selectively allow evaluation of some
> source blocks based on their language. I guess some users expect to have
> this.
> 
> Otherwise, it sounds good.
> 
>> If I had to sketch a design for this, it would be a macro like:
>> 

It would be nice to have a concurrent update to template.el for this scheme.

https://code.orgmode.org/bzg/worg/raw/master/org-contrib/babel/ob-template.el

Chuck