* C++ is not accepted for SRC block evaluation
@ 2018-05-26 12:15 Van L
2018-05-26 14:50 ` John Kitchin
0 siblings, 1 reply; 9+ messages in thread
From: Van L @ 2018-05-26 12:15 UTC (permalink / raw)
To: emacs-orgmode
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++.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: C++ is not accepted for SRC block evaluation
2018-05-26 12:15 C++ is not accepted for SRC block evaluation Van L
@ 2018-05-26 14:50 ` John Kitchin
2018-05-27 2:50 ` Van L
0 siblings, 1 reply; 9+ messages in thread
From: John Kitchin @ 2018-05-26 14:50 UTC (permalink / raw)
To: Van L; +Cc: org-mode-email
[-- 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 --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: C++ is not accepted for SRC block evaluation
2018-05-26 14:50 ` John Kitchin
@ 2018-05-27 2:50 ` Van L
2018-05-27 20:24 ` Nicolas Goaziou
0 siblings, 1 reply; 9+ messages in thread
From: Van L @ 2018-05-27 2:50 UTC (permalink / raw)
To: John Kitchin; +Cc: org-mode-email
> 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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: C++ is not accepted for SRC block evaluation
2018-05-27 2:50 ` Van L
@ 2018-05-27 20:24 ` Nicolas Goaziou
2018-05-27 20:48 ` Aaron Ecay
0 siblings, 1 reply; 9+ messages in thread
From: Nicolas Goaziou @ 2018-05-27 20:24 UTC (permalink / raw)
To: Van L; +Cc: org-mode-email, John Kitchin
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: C++ is not accepted for SRC block evaluation
2018-05-27 20:24 ` Nicolas Goaziou
@ 2018-05-27 20:48 ` Aaron Ecay
2018-05-27 21:09 ` Nicolas Goaziou
0 siblings, 1 reply; 9+ messages in thread
From: Aaron Ecay @ 2018-05-27 20:48 UTC (permalink / raw)
To: Nicolas Goaziou, Van L; +Cc: org-mode-email, John Kitchin
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: C++ is not accepted for SRC block evaluation
2018-05-27 20:48 ` Aaron Ecay
@ 2018-05-27 21:09 ` Nicolas Goaziou
2018-05-28 15:57 ` Aaron Ecay
0 siblings, 1 reply; 9+ messages in thread
From: Nicolas Goaziou @ 2018-05-27 21:09 UTC (permalink / raw)
To: Van L; +Cc: org-mode-email, John Kitchin
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?
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: C++ is not accepted for SRC block evaluation
2018-05-27 21:09 ` Nicolas Goaziou
@ 2018-05-28 15:57 ` Aaron Ecay
2018-05-30 11:11 ` Nicolas Goaziou
0 siblings, 1 reply; 9+ messages in thread
From: Aaron Ecay @ 2018-05-28 15:57 UTC (permalink / raw)
To: Nicolas Goaziou, Van L; +Cc: org-mode-email, John Kitchin
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: C++ is not accepted for SRC block evaluation
2018-05-28 15:57 ` Aaron Ecay
@ 2018-05-30 11:11 ` Nicolas Goaziou
2018-05-30 16:35 ` Berry, Charles
0 siblings, 1 reply; 9+ messages in thread
From: Nicolas Goaziou @ 2018-05-30 11:11 UTC (permalink / raw)
To: Van L; +Cc: org-mode-email, John Kitchin
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: C++ is not accepted for SRC block evaluation
2018-05-30 11:11 ` Nicolas Goaziou
@ 2018-05-30 16:35 ` Berry, Charles
0 siblings, 0 replies; 9+ messages in thread
From: Berry, Charles @ 2018-05-30 16:35 UTC (permalink / raw)
To: Nicolas Goaziou; +Cc: Van L, org-mode-email, John Kitchin
> 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
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2018-05-30 16:35 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-05-26 12:15 C++ is not accepted for SRC block evaluation Van L
2018-05-26 14:50 ` John Kitchin
2018-05-27 2:50 ` Van L
2018-05-27 20:24 ` Nicolas Goaziou
2018-05-27 20:48 ` Aaron Ecay
2018-05-27 21:09 ` Nicolas Goaziou
2018-05-28 15:57 ` Aaron Ecay
2018-05-30 11:11 ` Nicolas Goaziou
2018-05-30 16:35 ` Berry, Charles
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).