Re: [O] Tangling takes long - profiling and calling R
Aaron Ecay aarone...@gmail.com writes:
Could you take a look at
http://mid.gmane.org/87fvg07vzi.fsf@Rainer.invalid, specifically the
paragraph beginning “That looks like a bug”?
This should be fixed in 188bae903feb942355dae6878951e9f13211e1d0. Thank
you for the notice.
I don’t want to argue the semantics excessively, but “deprecated” should
mean that users:
1) actually change their behavior when creating new documents, or at
least
2) are aware that the old behavior is in danger of disappearing.
A footnote in the manual and a comment in the elisp file don’t really
achieve this, as evidenced by the periodic discussions of this point that
we have.
This is why I suggest to also announce the deprecation in ORG-NEWS, then
effectively remove it in the next release.
Additionally, last year Eric commented that the deprecation was
“premature” http://article.gmane.org/gmane.emacs.orgmode/87739. This
arguably means (among other things) that more effort to publicize it and
work on its replacement is needed, something that has not really
happened.
Let's move forward and discuss about what is needed then.
Neither syntax is necessary, by this metric. We could just make do with
local arguments, not needing properties at all.
IOW, this doesn’t distinguish between these two approaches.
You may be misunderstanding me. I don't want to distinguish between
these approaches. Both are certainly fine, but two of them in one too
many. This is just confusing and more difficult to maintain.
I suggest to remove the old dynamic setting and improve the new
lexical one, if needed.
The dynamic vs. lexical metaphor is not very helpful either.
It doesn't matter. Let's call one the old setting and the other the
recent setting. Or tag them A and B.
There has been no justification for the new property system proposed
other than questions of taste such as the above, and efficiency. The
efficiency considerations could be solved in several ways. One obvious
one would be to use a single call to org-entry-properties rather than N
calls to org-entry-get. I feel like a broken record saying this, but it
was a solution I suggested already, in the last thread
http://mid.gmane.org/87r3zlrcnt@gmail.com. Another, more
ambitious, solution would be to use the parser cache for
org-entry-{properties,get}. There was a patch for this
http://article.gmane.org/gmane.emacs.orgmode/89326, which never landed
for a variety of reasons.
I don't think efficiency is a matter here. `org-entry-get' is reasonably
fast nowadays (since properties drawers change), even using inheritance.
Regards,
Re: [O] Tangling takes long - profiling and calling R
Hello, Aaron Ecay aarone...@gmail.com writes: There is also a semantic difference in the two approaches as to whether a remote invocation of a babel block (via e.g. #+call) uses the properties from the block’s document position, or from the call’s. Before deprecating the feature, the bugs should be fixed (if they are really bugs), and the semantic differences explicated better. I'm all ears to bug reports. However, the point is not about deprecating the feature. It /is/ marked as deprecated already, and has been so during the last two years. Keeping both is just confusing and not necessary, since you can override properties locally, with appropriate arguments. I suggest to remove the old dynamic setting and improve the new lexical one, if needed. Of course, it can wait Org 8.4, but it should be signaled during Org 8.3 release already. Regards, -- Nicolas Goaziou
Re: [O] Tangling takes long - profiling and calling R
Nicolas Goaziou m...@nicolasgoaziou.fr writes: Hello, Aaron Ecay aarone...@gmail.com writes: There is also a semantic difference in the two approaches as to whether a remote invocation of a babel block (via e.g. #+call) uses the properties from the block’s document position, or from the call’s. Before deprecating the feature, the bugs should be fixed (if they are really bugs), and the semantic differences explicated better. I'm all ears to bug reports. However, the point is not about deprecating the feature. It /is/ marked as deprecated already, and has been so during the last two years. Keeping both is just confusing and not necessary, since you can override properties locally, with appropriate arguments. I suggest to remove the old dynamic setting and improve the new lexical one, if needed. Of course, it can wait Org 8.4, but it should be signaled during Org 8.3 release already. What I am missing in the new syntax is the possibility to *change* the value of one header argument or to *remove* one. There is , | :header-args: tangle testfile.R ` Which sets the property header-args, there is , | :header-args+: noweb yes ` which adds to header-args, what is missing is , | :header-args-: noweb ` which would remove the noweb yes from the header arguments and possibly , | :header-args-+: noweb exec ` which would *replace* the noweb yes with noweb exec, so it is effectively identical to , | :header-args-: noweb | :header-args+: noweb exec ` I know this might be difficult as header-args is simply a string, but I think when these additions would be there, the old syntax could be translated into the new syntax. Cheers, Rainer Regards, -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug PGP: 0x0F52F982 signature.asc Description: PGP signature
Re: [O] Tangling takes long - profiling and calling R
Hi Rainer, 2015ko uztailak 2an, Rainer M Krug-ek idatzi zuen: What I am missing in the new syntax is the possibility to *change* the value of one header argument or to *remove* one. There is , | :header-args: tangle testfile.R ` (Nit: I think all your examples are missing an additional colon before the header arg name, so the above should be “:header-args: :tangle testfile.R”) Which sets the property header-args, there is , | :header-args+: noweb yes ` which adds to header-args, what is missing is , | :header-args-: noweb ` which would remove the noweb yes from the header arguments This is not possible with the old syntax either, though: * One :PROPERTIES: :noweb: yes :END: ** Two :PROPERTIES: ??? :END: #+begin_src emacs-lisp ... #+end_src There’s nothing you can put in the ?s at heading Two to get rid of the noweb property inherited from One. (Unless you have something in mind which I’m not thinking of.) and possibly , | :header-args-+: noweb exec ` which would *replace* the noweb yes with noweb exec, so it is effectively identical to , | :header-args-: noweb | :header-args+: noweb exec ` OTOH this is a real difference. It corresponds in the old system to * One :PROPERTIES: :noweb: yes :END: ** Two :PROPERTIES: :noweb: exec :END: #+begin_src emacs-lisp ... ;; noweb=exec #+end_src ** Three #+begin_src emacs-lisp ... ;; noweb=yes #+end_src I know this might be difficult as header-args is simply a string, This is precisely the issue: this would require extending properties to allow them to be used/interpreted as string-plists, instead of merely strings as they presently are. It would necessitate changing or adding lots of functions related to the property API. Then you have header args like “:results” which can take multiple words. Do we want to support something like the following (from the old system), which would require even more changes on top of properties-as-plist-strings in the new one: * One :PROPERTIES: :results: output :END: ** Two :PROPERTIES: :results+: table :END: #+begin_src emacs-lisp ... ;; results = output table #+end_src ** Three :PROPERTIES: :results+: list :END: #+begin_src emacs-lisp ... ;; results = output list #+end_src (AFAIK even whether property+ prepends or appends to the property value as a string is not defined, which is already a potential issue though not one that crops up for babel which is order-insensitive.) Aaron PS I am aware that all the examples I quoted are uninteresting in the context of a single source block, which could just use header arguments. Consider a large library of babel organized, taking the last example I constructed, like: * Blocks with interesting output ** Blocks which output interesting tables a dozen blocks ** Blocks which output interesting lists another dozen PPS Under either system there’s the issue of the :post header arg, which composes in a non-concatenative way. You might have: * Things which should be wrapped in delimiters :PROPERTIES: :post: wrap-delims(*this*) :END: ** Things which should be in red text :PROPERTIES: :post: make-red(*this*) :END: #+begin_src emacs-lisp ;; produce a result which should be delimited and red #+end_src The result we want is for :post to read wrap-delims(make-red(*this*)) or make-red(wrap-delims(*this*)), depending on our opinion of red delimiters. But post is very brittle in any case, so this problem isn’t very important. -- Aaron Ecay
Re: [O] Tangling takes long - profiling and calling R
Hi Nicolas,
2015ko uztailak 2an, Nicolas Goaziou-ek idatzi zuen:
Hello,
Aaron Ecay aarone...@gmail.com writes:
There is also a semantic difference in the two approaches as to whether
a remote invocation of a babel block (via e.g. #+call) uses the
properties from the block’s document position, or from the call’s.
Before deprecating the feature, the bugs should be fixed (if they are
really bugs), and the semantic differences explicated better.
I'm all ears to bug reports.
Could you take a look at
http://mid.gmane.org/87fvg07vzi.fsf@Rainer.invalid, specifically the
paragraph beginning “That looks like a bug”?
However, the point is not about deprecating the feature. It /is/ marked
as deprecated already, and has been so during the last two years.
I don’t want to argue the semantics excessively, but “deprecated” should
mean that users:
1) actually change their behavior when creating new documents, or at
least
2) are aware that the old behavior is in danger of disappearing.
A footnote in the manual and a comment in the elisp file don’t really
achieve this, as evidenced by the periodic discussions of this point that
we have. Additionally, last year Eric commented that the deprecation was
“premature” http://article.gmane.org/gmane.emacs.orgmode/87739. This
arguably means (among other things) that more effort to publicize it and
work on its replacement is needed, something that has not really happened.
(Unless you count repetitive and inconclusive ML threads as a publicity
campaign.)
The inclusion of the warning in org-lint is a concrete step forward.
Keeping both is just confusing and not necessary, since you can override
properties locally, with appropriate arguments.
Neither syntax is necessary, by this metric. We could just make do with
local arguments, not needing properties at all.
IOW, this doesn’t distinguish between these two approaches.
I suggest to remove the old dynamic setting and improve the new
lexical one, if needed.
The dynamic vs. lexical metaphor is not very helpful either. I myself
invoked it, with opposite polarity, in the last thread. Achim and I had
a long discussion, without reaching any conclusion. That discussion
starts here http://mid.gmane.org/87r3zlrcnt@gmail.com. It might
be good if you read that whole thread (which is the same one that I have
already linked several times).
There has been no justification for the new property system proposed
other than questions of taste such as the above, and efficiency. The
efficiency considerations could be solved in several ways. One obvious
one would be to use a single call to org-entry-properties rather than N
calls to org-entry-get. I feel like a broken record saying this, but it
was a solution I suggested already, in the last thread
http://mid.gmane.org/87r3zlrcnt@gmail.com. Another, more
ambitious, solution would be to use the parser cache for
org-entry-{properties,get}. There was a patch for this
http://article.gmane.org/gmane.emacs.orgmode/89326, which never landed
for a variety of reasons.
There are differences in the expressivity of the two systems – such as
the (AFAICS new) one pointed out by Rainer in this thread – which have
not been explained or justified. I hope that these can be addressed,
and alternatives considered if necessary, before the change is imposed
on org users.
--
Aaron Ecay
Re: [O] Tangling takes long - profiling and calling R
Envoyé de mon iPhone Le 2 juil. 2015 à 13:51, Nicolas Goaziou m...@nicolasgoaziou.fr a écrit : Hello, Aaron Ecay aarone...@gmail.com writes: There is also a semantic difference in the two approaches as to whether a remote invocation of a babel block (via e.g. #+call) uses the properties from the block’s document position, or from the call’s. Before deprecating the feature, the bugs should be fixed (if they are really bugs), and the semantic differences explicated better. I'm all ears to bug reports. However, the point is not about deprecating the feature. It /is/ marked as deprecated already, and has been so during the last two years. Keeping both is just confusing and not necessary, since you can override properties locally, with appropriate arguments. I suggest to remove the old dynamic setting and improve the new lexical one, if needed. Of course, it can wait Org 8.4, but it should be signaled during Org 8.3 release already. Just out of interest - could you give me a short explanation or a link to where it is discussed why this change was made? Thanks, Rainer Regards, -- Nicolas Goaziou
Re: [O] Tangling takes long - profiling and calling R
Aaron Ecay aarone...@gmail.com writes: which adds to header-args, what is missing is , | :header-args-: noweb ` which would remove the noweb yes from the header arguments This is not possible with the old syntax either, though: * One :PROPERTIES: :noweb: yes :END: ** Two :PROPERTIES: ??? :END: #+begin_src emacs-lisp ... #+end_src There’s nothing you can put in the ?s at heading Two to get rid of the noweb property inherited from One. (Unless you have something in mind which I’m not thinking of.) Quickly, just on that particular point: what you'd put there would be the toggle of the property (here :noweb: no), but that's of course sort of limited to boolean values which have an explicit no (or nil) value; so I admit I just cover this particular exemple. Best regards, Seb -- Sebastien Vauban
Re: [O] Tangling takes long - profiling and calling R
Envoyé de mon iPhone Le 2 juil. 2015 à 18:35, Aaron Ecay aarone...@gmail.com a écrit : Hi Rainer, 2015ko uztailak 2an, Rainer M Krug-ek idatzi zuen: What I am missing in the new syntax is the possibility to *change* the value of one header argument or to *remove* one. There is , | :header-args: tangle testfile.R ` (Nit: I think all your examples are missing an additional colon before the header arg name, so the above should be “:header-args: :tangle testfile.R”) You are right - I always make this error. Which sets the property header-args, there is , | :header-args+: noweb yes ` which adds to header-args, what is missing is , | :header-args-: noweb ` which would remove the noweb yes from the header arguments This is not possible with the old syntax either, though: * One :PROPERTIES: :noweb: yes :END: ** Two :PROPERTIES: ??? :END: #+begin_src emacs-lisp ... #+end_src There’s nothing you can put in the ?s at heading Two to get rid of the noweb property inherited from One. (Unless you have something in mind which I’m not thinking of.) No - not possible with the old syntax, but I was already missing it there. And it would make sense to have it. But one was at least able to set the header argument to the default value. and possibly , | :header-args-+: noweb exec ` which would *replace* the noweb yes with noweb exec, so it is effectively identical to , | :header-args-: noweb | :header-args+: noweb exec ` OTOH this is a real difference. It corresponds in the old system to * One :PROPERTIES: :noweb: yes :END: ** Two :PROPERTIES: :noweb: exec :END: #+begin_src emacs-lisp ... ;; noweb=exec #+end_src ** Three #+begin_src emacs-lisp ... ;; noweb=yes #+end_src I know this might be difficult as header-args is simply a string, This is precisely the issue: this would require extending properties to allow them to be used/interpreted as string-plists, instead of merely strings as they presently are. It would necessitate changing or adding lots of functions related to the property API. Then you have header args like “:results” which can take multiple words. Do we want to support something like the following (from the old system), which would require even more changes on top of properties-as-plist-strings in the new one: * One :PROPERTIES: :results: output :END: ** Two :PROPERTIES: :results+: table :END: #+begin_src emacs-lisp ... ;; results = output table #+end_src ** Three :PROPERTIES: :results+: list :END: #+begin_src emacs-lisp ... ;; results = output list #+end_src (AFAIK even whether property+ prepends or appends to the property value as a string is not defined, which is already a potential issue though not one that crops up for babel which is order-insensitive.) Cheers, Rainer Aaron PS I am aware that all the examples I quoted are uninteresting in the context of a single source block, which could just use header arguments. Consider a large library of babel organized, taking the last example I constructed, like: * Blocks with interesting output ** Blocks which output interesting tables a dozen blocks ** Blocks which output interesting lists another dozen PPS Under either system there’s the issue of the :post header arg, which composes in a non-concatenative way. You might have: * Things which should be wrapped in delimiters :PROPERTIES: :post: wrap-delims(*this*) :END: ** Things which should be in red text :PROPERTIES: :post: make-red(*this*) :END: #+begin_src emacs-lisp ;; produce a result which should be delimited and red #+end_src The result we want is for :post to read wrap-delims(make-red(*this*)) or make-red(wrap-delims(*this*)), depending on our opinion of red delimiters. But post is very brittle in any case, so this problem isn’t very important. -- Aaron Ecay
Re: [O] Tangling takes long - profiling and calling R
Envoyé de mon iPhone Le 2 juil. 2015 à 20:21, Sebastien Vauban sva-n...@mygooglest.com a écrit : Aaron Ecay aarone...@gmail.com writes: which adds to header-args, what is missing is , | :header-args-: noweb ` which would remove the noweb yes from the header arguments This is not possible with the old syntax either, though: * One :PROPERTIES: :noweb: yes :END: ** Two :PROPERTIES: ??? :END: #+begin_src emacs-lisp ... #+end_src There’s nothing you can put in the ?s at heading Two to get rid of the noweb property inherited from One. (Unless you have something in mind which I’m not thinking of.) Quickly, just on that particular point: what you'd put there would be the toggle of the property (here :noweb: no), but that's of course sort of limited to boolean values which have an explicit no (or nil) value; so I admit I just cover this particular exemple. But this was possible with the old syntax, but not with the new one - right? Best regards, Seb -- Sebastien Vauban
Re: [O] Tangling takes long - profiling and calling R
Hello all, 2015ko ekainak 16an, Rainer M Krug-ek idatzi zuen: I don't think that it is that easy, as the new syntax is not equivalent to the old syntax. One example; defining one tangle target for the mother tree, and others for the child trees. This is by no means trivial (or even possible) with the new syntax, while it would be possible with the old syntax (if I remember correctly). The last thread we had about this http://mid.gmane.org/87sijpr9nj@gmail.com, we discussed some of the differences. Achim believed that some of them were due to bugs in the property API, but these have not been fixed (AFAIK). There is also a semantic difference in the two approaches as to whether a remote invocation of a babel block (via e.g. #+call) uses the properties from the block’s document position, or from the call’s. Before deprecating the feature, the bugs should be fixed (if they are really bugs), and the semantic differences explicated better. -- Aaron Ecay
Re: [O] Tangling takes long - profiling and calling R
Nicolas Goaziou m...@nicolasgoaziou.fr writes: Rainer M Krug rai...@krugs.de writes: I would not remove it as even I have some org files using them - shame on me. To be clear, are we talking of constructs such as: --8---cut here---start-8--- ** Subtree :PROPERTIES: :tangle: no :END: --8---cut here---end---8--- ? We can check for that in Org Lint and warn the user. But what about making it user configurable? a variable ~org-babel-tangle-use-deprecated-header-args~ which if set to non-nil would enable this additional code, if nil it would be skipped? The default should be set to ~t~ to be backward compatible. This looks like backward-compatibility hell to me. If we make it conditional the feature is no longer deprecated, is it? I understand your point, and I'm enclined to agree with you (for a long-term sanity and stability of the mode we all cherish) -- even if I dunno yet if I still use such (Well, if this is the above structure, then, yes, I use it a lot as well...). The more general question is: how many years do we need to wait before removing a deprecated (i.e., marked as such) feature? Your suggestion with Org-lint, or even writing a function that would convert from the old to the new syntax, makes a shorter period acceptable IMO. Best regards, Seb -- Sebastien Vauban
Re: [O] Tangling takes long - profiling and calling R
Hello, Sebastien Vauban sva-news-D0wtAvR13HarG/idocf...@public.gmane.org writes: To be clear, are we talking of constructs such as: ** Subtree :PROPERTIES: :tangle: no :END: ? Yes, we are. Your suggestion with Org-lint, or even writing a function that would convert from the old to the new syntax, makes a shorter period acceptable IMO. What about the following check, which could be integrated in Org Lint: (defun check-deprecated-babel-properties () (interactive) (let ((deprecated-babel-properties (mapcar (lambda (arg) (symbol-name (car arg))) org-babel-common-header-args-w-values))) (org-element-map (org-element-parse-buffer 'element) 'node-property (lambda (p) (let ((key (org-element-property :key p))) (when (member-ignore-case key deprecated-babel-properties) (error Deprecated Babel property \%s\ at line %d. Use :header-args: instead key (save-excursion (goto-char (org-element-property :begin p)) (org-current-line) Regards, -- Nicolas Goaziou
Re: [O] Tangling takes long - profiling and calling R
Envoyé de mon iPhone Le 16 juin 2015 à 14:45, Sebastien Vauban sva-n...@mygooglest.com a écrit : Nicolas Goaziou m...@nicolasgoaziou.fr writes: Rainer M Krug rai...@krugs.de writes: I would not remove it as even I have some org files using them - shame on me. To be clear, are we talking of constructs such as: --8---cut here---start-8--- ** Subtree :PROPERTIES: :tangle: no :END: --8---cut here---end---8--- ? We can check for that in Org Lint and warn the user. But what about making it user configurable? a variable ~org-babel-tangle-use-deprecated-header-args~ which if set to non-nil would enable this additional code, if nil it would be skipped? The default should be set to ~t~ to be backward compatible. This looks like backward-compatibility hell to me. If we make it conditional the feature is no longer deprecated, is it? I understand your point, and I'm enclined to agree with you (for a long-term sanity and stability of the mode we all cherish) -- even if I dunno yet if I still use such (Well, if this is the above structure, then, yes, I use it a lot as well...). The more general question is: how many years do we need to wait before removing a deprecated (i.e., marked as such) feature? Your suggestion with Org-lint, or even writing a function that would convert from the old to the new syntax, makes a shorter period acceptable IMO. I don't think that it is that easy, as the new syntax is not equivalent to the old syntax. One example; defining one tangle target for the mother tree, and others for the child trees. This is by no means trivial (or even possible) with the new syntax, while it would be possible with the old syntax (if I remember correctly). So for backward compatibility, the support should stay, but one had to enable it explicitly. Cheers, Rainer Best regards, Seb -- Sebastien Vauban
Re: [O] Tangling takes long - profiling and calling R
Envoyé de mon iPhone Le 16 juin 2015 à 13:46, Nicolas Goaziou m...@nicolasgoaziou.fr a écrit : Rainer M Krug rai...@krugs.de writes: I would not remove it as even I have some org files using them - shame on me. We can check for that in Org Lint and warn the user. That would be a really good idea! But what about making it user configurable? a variable ~org-babel-tangle-use-deprecated-header-args~ which if set to non-nil would enable this additional code, if nil it would be skipped? The default should be set to ~t~ to be backward compatible. This looks like backward-compatibility hell to me. If we make it conditional the feature is no longer deprecated, is it? The more general question is: how many years do we need to wait before removing a deprecated (i.e., marked as such) feature? Before deleting it, one should get a warning that a certain feature is deprecated. At the moment, it is only mentioned in the help (as far as I am aware). Regards,
Re: [O] Tangling takes long - profiling and calling R
Rainer M Krug r.m.k...@gmail.com writes: We can check for that in Org Lint and warn the user. That would be a really good idea! Done. Before deleting it, one should get a warning that a certain feature is deprecated. At the moment, it is only mentioned in the help (as far as I am aware). It has been mentioned in the manual for the last two years. See footnote in (info (org)Header arguments in Org mode properties). Regards,
Re: [O] Tangling takes long - profiling and calling R
Charles C. Berry ccbe...@ucsd.edu writes: On Mon, 15 Jun 2015, Rainer M Krug wrote: Hi I have a relatively large file with about 200 =source blocks (R) to be tangled to get an R package. But the tangling takes about 20 seconds. Profiling the tangling showed that the call to ~mapcar~ in ~org-babel-params-from-properties~ takes about 40% of the execution time (see profiler excerpt below). Is there anything one can do to make this faster? In addition to this, I observed there is some interaction with ESS when tangling, which in my understanding is not necessary. I get messages like , | ... | Wrote /Users/rainerkrug/Documents/Projects/EnergyBalance/.Rbuildignore | Wrote /Users/rainerkrug/Documents/Projects/EnergyBalance/tests/wpLELTest.R | You are developing: (EnergyBalance) | Wrote /Users/rainerkrug/Documents/Projects/EnergyBalance/R/plotwpLELFitListParDistr.R | You are developing: (EnergyBalance) | ... ` where the messages You are developing: (EnergyBalance) come from ESS. Is this to be expected that R is called for some blocks, but not for others, when tangling? The major mode is invoked when tangling, if possible. This enables comments to be rendered. See the docstring for `org-babel-spec-to-string'. HTH, Yes - thanks, Rainer Chuck -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug PGP: 0x0F52F982 signature.asc Description: PGP signature
Re: [O] Tangling takes long - profiling and calling R
Nicolas Goaziou m...@nicolasgoaziou.fr writes: Hello, Rainer M Krug rai...@krugs.de writes: I have a relatively large file with about 200 =source blocks (R) to be tangled to get an R package. But the tangling takes about 20 seconds. Profiling the tangling showed that the call to ~mapcar~ in ~org-babel-params-from-properties~ takes about 40% of the execution time (see profiler excerpt below). Is there anything one can do to make this faster? In this function, there is ;; DEPRECATED header arguments specified as separate property at ;; point of definition (let (val sym) (org-babel-parse-multiple-vars (delq nil (mapcar (lambda (header-arg) (and (setq val (org-entry-get (point) header-arg t)) (cons (intern (concat : header-arg)) (org-babel-read val (mapcar #'symbol-name (mapcar #'car (org-babel-combine-header-arg-lists org-babel-common-header-args-w-values (progn (setq sym (intern (concat org-babel-header-args: lang))) (and (boundp sym) (eval sym)) While the 3 `mapcar' calls could be turned into a single one, I wonder if this snippet could be removed altogether instead. It has been deprecated for 2 years already. WDYT? I would not remove it as even I have some org files using them - shame on me. But what about making it user configurable? a variable ~org-babel-tangle-use-deprecated-header-args~ which if set to non-nil would enable this additional code, if nil it would be skipped? The default should be set to ~t~ to be backward compatible. Cheers, Rainer Regards, -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug PGP: 0x0F52F982 signature.asc Description: PGP signature
Re: [O] Tangling takes long - profiling and calling R
Rainer M Krug rai...@krugs.de writes: I would not remove it as even I have some org files using them - shame on me. We can check for that in Org Lint and warn the user. But what about making it user configurable? a variable ~org-babel-tangle-use-deprecated-header-args~ which if set to non-nil would enable this additional code, if nil it would be skipped? The default should be set to ~t~ to be backward compatible. This looks like backward-compatibility hell to me. If we make it conditional the feature is no longer deprecated, is it? The more general question is: how many years do we need to wait before removing a deprecated (i.e., marked as such) feature? Regards,
Re: [O] Tangling takes long - profiling and calling R
On Mon, 15 Jun 2015, Rainer M Krug wrote: Hi I have a relatively large file with about 200 =source blocks (R) to be tangled to get an R package. But the tangling takes about 20 seconds. Profiling the tangling showed that the call to ~mapcar~ in ~org-babel-params-from-properties~ takes about 40% of the execution time (see profiler excerpt below). Is there anything one can do to make this faster? In addition to this, I observed there is some interaction with ESS when tangling, which in my understanding is not necessary. I get messages like , | ... | Wrote /Users/rainerkrug/Documents/Projects/EnergyBalance/.Rbuildignore | Wrote /Users/rainerkrug/Documents/Projects/EnergyBalance/tests/wpLELTest.R | You are developing: (EnergyBalance) | Wrote /Users/rainerkrug/Documents/Projects/EnergyBalance/R/plotwpLELFitListParDistr.R | You are developing: (EnergyBalance) | ... ` where the messages You are developing: (EnergyBalance) come from ESS. Is this to be expected that R is called for some blocks, but not for others, when tangling? The major mode is invoked when tangling, if possible. This enables comments to be rendered. See the docstring for `org-babel-spec-to-string'. HTH, Chuck
Re: [O] Tangling takes long - profiling and calling R
Hello, Rainer M Krug rai...@krugs.de writes: I have a relatively large file with about 200 =source blocks (R) to be tangled to get an R package. But the tangling takes about 20 seconds. Profiling the tangling showed that the call to ~mapcar~ in ~org-babel-params-from-properties~ takes about 40% of the execution time (see profiler excerpt below). Is there anything one can do to make this faster? In this function, there is ;; DEPRECATED header arguments specified as separate property at ;; point of definition (let (val sym) (org-babel-parse-multiple-vars (delq nil (mapcar (lambda (header-arg) (and (setq val (org-entry-get (point) header-arg t)) (cons (intern (concat : header-arg)) (org-babel-read val (mapcar #'symbol-name (mapcar #'car (org-babel-combine-header-arg-lists org-babel-common-header-args-w-values (progn (setq sym (intern (concat org-babel-header-args: lang))) (and (boundp sym) (eval sym)) While the 3 `mapcar' calls could be turned into a single one, I wonder if this snippet could be removed altogether instead. It has been deprecated for 2 years already. WDYT? Regards, -- Nicolas Goaziou
[O] Tangling takes long - profiling and calling R
Hi I have a relatively large file with about 200 =source blocks (R) to be tangled to get an R package. But the tangling takes about 20 seconds. Profiling the tangling showed that the call to ~mapcar~ in ~org-babel-params-from-properties~ takes about 40% of the execution time (see profiler excerpt below). Is there anything one can do to make this faster? In addition to this, I observed there is some interaction with ESS when tangling, which in my understanding is not necessary. I get messages like , | ... | Wrote /Users/rainerkrug/Documents/Projects/EnergyBalance/.Rbuildignore | Wrote /Users/rainerkrug/Documents/Projects/EnergyBalance/tests/wpLELTest.R | You are developing: (EnergyBalance) | Wrote /Users/rainerkrug/Documents/Projects/EnergyBalance/R/plotwpLELFitListParDistr.R | You are developing: (EnergyBalance) | ... ` where the messages You are developing: (EnergyBalance) come from ESS. Is this to be expected that R is called for some blocks, but not for others, when tangling? Version info: , | Org-mode version 8.3beta (release_8.3beta-1209-gc532ff @ /Users/rainerkrug/.emacs.d/org-mode/lisp/) | GNU Emacs 24.5.1 (x86_64-apple-darwin14.3.0, Carbon Version 157 AppKit 1347.57) of 2015-04-13 on Rainers-MacBook-Pro.local ` Cheers, Rainer , | - time-execute4950 84% | - call-interactively4950 84% | - org-babel-tangle 4828 82% |- org-babel-tangle-collect-blocks 2728 46% | - org-babel-tangle-single-block 1363 23% | - org-babel-get-src-block-info 1304 22% | - org-babel-parse-src-block-match 1210 20% |### - org-babel-params-from-properties1193 20% | + mapcar 1144 19% | + org-entry-get33 0% | + org-babel-parse-header-arguments 12 0% | + org-babel-combine-header-arg-lists4 0% |+ org-babel-parse-header-arguments 3 0% |+ apply 2 0% | generate-new-buffer1 0% |+ org-unescape-code-in-string1 0% | byte-code 1 0% | + org-babel-generate-file-param 86 1% | + org-babel-process-params2 0% | org-babel-where-is-src-block-head 1 0% | + org-store-link 36 0% |line-number-at-pos 17 0% | + byte-code2 0% |generate-new-buffer 1 0% | - org-babel-get-src-block-info 1334 22% | - org-babel-parse-src-block-match 1235 21% | - org-babel-params-from-properties 1212 20% |+ mapcar 1163 19% |+ org-entry-get 30 0% |+ org-babel-parse-header-arguments 12 0% |+ org-babel-combine-header-arg-lists 7 0% | + org-babel-parse-header-arguments7 0% | + apply 4 0% | + org-unescape-code-in-string 2 0% | generate-new-buffer 1 0% | + org-babel-generate-file-param 89 1% |org-babel-where-is-src-block-head2 0% | + org-in-commented-heading-p8 0% | + org-babel-active-location-p 4 0% | + byte-code 2 0% |+ mapc2098 35% |+ run-hooks 1 0% | + smex 122 2% | + ... 912 15% | + flyspell-post-command-hook4 0% | + redisplay_internal (C function) 3 0% | + timer-event-handler 3 0% ` -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT),
