Omitting try/catch blocks from tangled R code?

Omitting try/catch blocks from tangled R code?

[John Hendy]

Greetings,


I don't usually tangle, but am creating a code file to go along with a
presentation I'm giving this weekend so that attendees can try things
out afterward by cloning my github repo where all the data and
necessary files are stored.

In my presentation (Beamer), I create plots via the R pdf() device,
and noticed that all of the tangled code where plots are generated
contains the following:

pdf(file="file.pdf"); tryCatch({

  code block contents here

},error=function(e){plot(x=-1:1, y=-1:1, type='n', xlab='', ylab='',
axes=FALSE); text(x=0, y=0, labels=e$message, col='red');
paste('ERROR', e$message, sep=' : ')}); dev.off()

Is there a way to omit this?

I'm guessing this is here to create a blank plot with the error as the
output when something goes awry?

I checked around variable completions of org-babel-tangle-* and
searched google for terms like "org babel tangle try catch" but am not
finding anything that looks like what I need.


Thanks,
John

[BABEL] BUG Re: Omitting try/catch blocks from tangled R code?

[Rainer M Krug]

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



On 02/07/14, 07:18 , John Hendy wrote:
> Greetings,
> 
> 
> I don't usually tangle, but am creating a code file to go along with a
> presentation I'm giving this weekend so that attendees can try things
> out afterward by cloning my github repo where all the data and
> necessary files are stored.
> 
> In my presentation (Beamer), I create plots via the R pdf() device,
> and noticed that all of the tangled code where plots are generated
> contains the following:
> 
> pdf(file="file.pdf"); tryCatch({
> 
>   code block contents here
> 
> },error=function(e){plot(x=-1:1, y=-1:1, type='n', xlab='', ylab='',
> axes=FALSE); text(x=0, y=0, labels=e$message, col='red');
> paste('ERROR', e$message, sep=' : ')}); dev.off()
> 
> Is there a way to omit this?

This is a bug which must have been introduced some time ago - in the
stock version of emacs (Org-mode version 7.9.3f
(release_7.9.3f-17-g7524ef @
/usr/local/Cellar/emacs/24.3/share/emacs/24.3/lisp/org/)) it does not
tangle the enclosing commands to create graphics, but in 8.2 it does (I
don't have an older version at hand to go further back).

> 
> I'm guessing this is here to create a blank plot with the error as the
> output when something goes awry?

Yes.

> 
> I checked around variable completions of org-babel-tangle-* and
> searched google for terms like "org babel tangle try catch" but am not
> finding anything that looks like what I need.

There is nothing, as it should not be tangled. The enclosing commands
concern the export, but not tangling,

I agree that the :result graphics header argument caused commands should
not be in the tangled file.

Another question is about the :epilogue and :prologue which I think
should be present (haven't checked if they are...).

Cheers,

Rainer


> 
> 
> Thanks,
> John
> 

-- 
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:      Rainer@krugs.de

Skype:      RMkrug


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 560 bytes --]

Re: [BABEL] BUG Re: Omitting try/catch blocks from tangled R code?

[Eric Schulte]

Rainer M Krug <Rainer@krugs.de> writes:

> On 02/07/14, 07:18 , John Hendy wrote:
>> Greetings,
>> 
>> 
>> I don't usually tangle, but am creating a code file to go along with a
>> presentation I'm giving this weekend so that attendees can try things
>> out afterward by cloning my github repo where all the data and
>> necessary files are stored.
>> 
>> In my presentation (Beamer), I create plots via the R pdf() device,
>> and noticed that all of the tangled code where plots are generated
>> contains the following:
>> 
>> pdf(file="file.pdf"); tryCatch({
>> 
>>   code block contents here
>> 
>> },error=function(e){plot(x=-1:1, y=-1:1, type='n', xlab='', ylab='',
>> axes=FALSE); text(x=0, y=0, labels=e$message, col='red');
>> paste('ERROR', e$message, sep=' : ')}); dev.off()
>> 
>> Is there a way to omit this?
>
> This is a bug which must have been introduced some time ago - in the
> stock version of emacs (Org-mode version 7.9.3f
> (release_7.9.3f-17-g7524ef @
> /usr/local/Cellar/emacs/24.3/share/emacs/24.3/lisp/org/)) it does not
> tangle the enclosing commands to create graphics, but in 8.2 it does (I
> don't have an older version at hand to go further back).
>

I believe this was introduced by your commit eaa3a761d.  Reversion of
which with the following should provide a temporary workaround.

  git revert eaa3a761d

Perhaps the try/catch code should be moved from org-babel-expand-body:R
to org-babel-execute:R.  Alternately, the code should stay as is and you
should use the no-expand header argument during tangling.

I'm not sure which makes the most sense, but I'd lean towards the
former.

Best,

>
>> 
>> I'm guessing this is here to create a blank plot with the error as the
>> output when something goes awry?
>
> Yes.
>
>> 
>> I checked around variable completions of org-babel-tangle-* and
>> searched google for terms like "org babel tangle try catch" but am not
>> finding anything that looks like what I need.
>
> There is nothing, as it should not be tangled. The enclosing commands
> concern the export, but not tangling,
>
> I agree that the :result graphics header argument caused commands should
> not be in the tangled file.
>
> Another question is about the :epilogue and :prologue which I think
> should be present (haven't checked if they are...).
>
> Cheers,
>
> Rainer
>
>
>> 
>> 
>> Thanks,
>> John
>> 

-- 
Eric Schulte
https://cs.unm.edu/~eschulte
PGP: 0x614CA05D

Re: [BABEL] BUG Re: Omitting try/catch blocks from tangled R code?

[Rainer M Krug]

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



On 02/07/14, 17:47 , Eric Schulte wrote:
> Rainer M Krug <Rainer@krugs.de> writes:
> 
>> On 02/07/14, 07:18 , John Hendy wrote:
>>> Greetings,
>>>
>>>
>>> I don't usually tangle, but am creating a code file to go along with a
>>> presentation I'm giving this weekend so that attendees can try things
>>> out afterward by cloning my github repo where all the data and
>>> necessary files are stored.
>>>
>>> In my presentation (Beamer), I create plots via the R pdf() device,
>>> and noticed that all of the tangled code where plots are generated
>>> contains the following:
>>>
>>> pdf(file="file.pdf"); tryCatch({
>>>
>>>   code block contents here
>>>
>>> },error=function(e){plot(x=-1:1, y=-1:1, type='n', xlab='', ylab='',
>>> axes=FALSE); text(x=0, y=0, labels=e$message, col='red');
>>> paste('ERROR', e$message, sep=' : ')}); dev.off()
>>>
>>> Is there a way to omit this?
>>
>> This is a bug which must have been introduced some time ago - in the
>> stock version of emacs (Org-mode version 7.9.3f
>> (release_7.9.3f-17-g7524ef @
>> /usr/local/Cellar/emacs/24.3/share/emacs/24.3/lisp/org/)) it does not
>> tangle the enclosing commands to create graphics, but in 8.2 it does (I
>> don't have an older version at hand to go further back).
>>
> 
> I believe this was introduced by your commit eaa3a761d.  Reversion of
> which with the following should provide a temporary workaround.

I checked it with version 8.2, which was, as far as I remember, before
my change of the R code to include the error handling, and the pdf(...)
... dev.off() was in the tangled file as well - so the behaviour must
have been introduced earlier. The only change I did was to change the R
code, so no change in the behavior if it is tangled or not.

I will look at it again on Monday to go back through the released
versions to narrow down where this had changed.


> 
>   git revert eaa3a761d

I don't think that this actually changes much - only that the enclosing
code will become pdf(...) THE CODE dev.off()

Cheers,

Rainer

> 
> Perhaps the try/catch code should be moved from org-babel-expand-body:R
> to org-babel-execute:R.  Alternately, the code should stay as is and you
> should use the no-expand header argument during tangling.
> 
> I'm not sure which makes the most sense, but I'd lean towards the
> former.
> 
> Best,
> 
>>
>>>
>>> I'm guessing this is here to create a blank plot with the error as the
>>> output when something goes awry?
>>
>> Yes.
>>
>>>
>>> I checked around variable completions of org-babel-tangle-* and
>>> searched google for terms like "org babel tangle try catch" but am not
>>> finding anything that looks like what I need.
>>
>> There is nothing, as it should not be tangled. The enclosing commands
>> concern the export, but not tangling,
>>
>> I agree that the :result graphics header argument caused commands should
>> not be in the tangled file.
>>
>> Another question is about the :epilogue and :prologue which I think
>> should be present (haven't checked if they are...).
>>
>> Cheers,
>>
>> Rainer
>>
>>
>>>
>>>
>>> Thanks,
>>> John
>>>
> 

-- 
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:      Rainer@krugs.de

Skype:      RMkrug


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 560 bytes --]

Re: [BABEL] BUG Re: Omitting try/catch blocks from tangled R code?

[John Hendy]

On Fri, Feb 7, 2014 at 1:22 PM, Rainer M Krug <Rainer@krugs.de> wrote:
>
>
>
> On 02/07/14, 17:47 , Eric Schulte wrote:
> > Rainer M Krug <Rainer@krugs.de> writes:
> >
> >> On 02/07/14, 07:18 , John Hendy wrote:
> >>> Greetings,
> >>>
> >>>
> >>> I don't usually tangle, but am creating a code file to go along with a
> >>> presentation I'm giving this weekend so that attendees can try things
> >>> out afterward by cloning my github repo where all the data and
> >>> necessary files are stored.
> >>>
> >>> In my presentation (Beamer), I create plots via the R pdf() device,
> >>> and noticed that all of the tangled code where plots are generated
> >>> contains the following:
> >>>
> >>> pdf(file="file.pdf"); tryCatch({
> >>>
> >>>   code block contents here
> >>>
> >>> },error=function(e){plot(x=-1:1, y=-1:1, type='n', xlab='', ylab='',
> >>> axes=FALSE); text(x=0, y=0, labels=e$message, col='red');
> >>> paste('ERROR', e$message, sep=' : ')}); dev.off()
> >>>
> >>> Is there a way to omit this?
> >>
> >> This is a bug which must have been introduced some time ago - in the
> >> stock version of emacs (Org-mode version 7.9.3f
> >> (release_7.9.3f-17-g7524ef @
> >> /usr/local/Cellar/emacs/24.3/share/emacs/24.3/lisp/org/)) it does not
> >> tangle the enclosing commands to create graphics, but in 8.2 it does (I
> >> don't have an older version at hand to go further back).
> >>
> >
> > I believe this was introduced by your commit eaa3a761d.  Reversion of
> > which with the following should provide a temporary workaround.
>
> I checked it with version 8.2, which was, as far as I remember, before
> my change of the R code to include the error handling, and the pdf(...)
> ... dev.off() was in the tangled file as well - so the behaviour must
> have been introduced earlier. The only change I did was to change the R
> code, so no change in the behavior if it is tangled or not.
>
> I will look at it again on Monday to go back through the released
> versions to narrow down where this had changed.
>
>

Just following up on this to see if the current behavior is desired or
if, indeed, something should/could change.

Thanks!
John

> >
> >   git revert eaa3a761d
>
> I don't think that this actually changes much - only that the enclosing
> code will become pdf(...) THE CODE dev.off()
>
> Cheers,
>
> Rainer
>
> >
> > Perhaps the try/catch code should be moved from org-babel-expand-body:R
> > to org-babel-execute:R.  Alternately, the code should stay as is and you
> > should use the no-expand header argument during tangling.
> >
> > I'm not sure which makes the most sense, but I'd lean towards the
> > former.
> >
> > Best,
> >
> >>
> >>>
> >>> I'm guessing this is here to create a blank plot with the error as the
> >>> output when something goes awry?
> >>
> >> Yes.
> >>
> >>>
> >>> I checked around variable completions of org-babel-tangle-* and
> >>> searched google for terms like "org babel tangle try catch" but am not
> >>> finding anything that looks like what I need.
> >>
> >> There is nothing, as it should not be tangled. The enclosing commands
> >> concern the export, but not tangling,
> >>
> >> I agree that the :result graphics header argument caused commands should
> >> not be in the tangled file.
> >>
> >> Another question is about the :epilogue and :prologue which I think
> >> should be present (haven't checked if they are...).
> >>
> >> Cheers,
> >>
> >> Rainer
> >>
> >>
> >>>
> >>>
> >>> Thanks,
> >>> John
> >>>
> >
>
> --
> 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:      Rainer@krugs.de
>
> Skype:      RMkrug
>

Re: [BABEL] BUG Re: Omitting try/catch blocks from tangled R code?

[Eric Schulte]

John Hendy <jw.hendy@gmail.com> writes:

> On Fri, Feb 7, 2014 at 1:22 PM, Rainer M Krug <Rainer@krugs.de> wrote:
>>
>>
>>
>> On 02/07/14, 17:47 , Eric Schulte wrote:
>> > Rainer M Krug <Rainer@krugs.de> writes:
>> >
>> >> On 02/07/14, 07:18 , John Hendy wrote:
>> >>> Greetings,
>> >>>
>> >>>
>> >>> I don't usually tangle, but am creating a code file to go along with a
>> >>> presentation I'm giving this weekend so that attendees can try things
>> >>> out afterward by cloning my github repo where all the data and
>> >>> necessary files are stored.
>> >>>
>> >>> In my presentation (Beamer), I create plots via the R pdf() device,
>> >>> and noticed that all of the tangled code where plots are generated
>> >>> contains the following:
>> >>>
>> >>> pdf(file="file.pdf"); tryCatch({
>> >>>
>> >>>   code block contents here
>> >>>
>> >>> },error=function(e){plot(x=-1:1, y=-1:1, type='n', xlab='', ylab='',
>> >>> axes=FALSE); text(x=0, y=0, labels=e$message, col='red');
>> >>> paste('ERROR', e$message, sep=' : ')}); dev.off()
>> >>>
>> >>> Is there a way to omit this?
>> >>
>> >> This is a bug which must have been introduced some time ago - in the
>> >> stock version of emacs (Org-mode version 7.9.3f
>> >> (release_7.9.3f-17-g7524ef @
>> >> /usr/local/Cellar/emacs/24.3/share/emacs/24.3/lisp/org/)) it does not
>> >> tangle the enclosing commands to create graphics, but in 8.2 it does (I
>> >> don't have an older version at hand to go further back).
>> >>
>> >
>> > I believe this was introduced by your commit eaa3a761d.  Reversion of
>> > which with the following should provide a temporary workaround.
>>

I take this back, the behavior is unrelated to Rainer's commit adding
try/catch blocks to R graphics creation logic.

In fact I don't believe this is a bug, rather the default behavior is to
expand code block bodies on tangling.  This behavior may be changed by
using the :no-expand header argument which will inhibit code block body
expansion during tangling.

Best,

-- 
Eric Schulte
https://cs.unm.edu/~eschulte
PGP: 0x614CA05D

Re: [BABEL] BUG Re: Omitting try/catch blocks from tangled R code?

[John Hendy]

On Mon, Mar 17, 2014 at 10:00 AM, Eric Schulte <schulte.eric@gmail.com> wrote:
> John Hendy <jw.hendy@gmail.com> writes:
>
>> On Fri, Feb 7, 2014 at 1:22 PM, Rainer M Krug <Rainer@krugs.de> wrote:
>>>
>>>
>>>
>>> On 02/07/14, 17:47 , Eric Schulte wrote:
>>> > Rainer M Krug <Rainer@krugs.de> writes:
>>> >
>>> >> On 02/07/14, 07:18 , John Hendy wrote:
>>> >>> Greetings,
>>> >>>
>>> >>>
>>> >>> I don't usually tangle, but am creating a code file to go along with a
>>> >>> presentation I'm giving this weekend so that attendees can try things
>>> >>> out afterward by cloning my github repo where all the data and
>>> >>> necessary files are stored.
>>> >>>
>>> >>> In my presentation (Beamer), I create plots via the R pdf() device,
>>> >>> and noticed that all of the tangled code where plots are generated
>>> >>> contains the following:
>>> >>>
>>> >>> pdf(file="file.pdf"); tryCatch({
>>> >>>
>>> >>>   code block contents here
>>> >>>
>>> >>> },error=function(e){plot(x=-1:1, y=-1:1, type='n', xlab='', ylab='',
>>> >>> axes=FALSE); text(x=0, y=0, labels=e$message, col='red');
>>> >>> paste('ERROR', e$message, sep=' : ')}); dev.off()
>>> >>>
>>> >>> Is there a way to omit this?
>>> >>
>>> >> This is a bug which must have been introduced some time ago - in the
>>> >> stock version of emacs (Org-mode version 7.9.3f
>>> >> (release_7.9.3f-17-g7524ef @
>>> >> /usr/local/Cellar/emacs/24.3/share/emacs/24.3/lisp/org/)) it does not
>>> >> tangle the enclosing commands to create graphics, but in 8.2 it does (I
>>> >> don't have an older version at hand to go further back).
>>> >>
>>> >
>>> > I believe this was introduced by your commit eaa3a761d.  Reversion of
>>> > which with the following should provide a temporary workaround.
>>>
>
> I take this back, the behavior is unrelated to Rainer's commit adding
> try/catch blocks to R graphics creation logic.
>
> In fact I don't believe this is a bug, rather the default behavior is to
> expand code block bodies on tangling.  This behavior may be changed by
> using the :no-expand header argument which will inhibit code block body
> expansion during tangling.
>

Got it, and thanks for the new variable tip!

Out of curiosity, is there a consensus that this is the preferred
behavior for tangling by default? I'm guessing at some point it was
decided that the need was preferred to have these bits inserted
before/after code blocks, but just trying to confirm this. It seems
odd to me, at least given R's behavior, that someone would prefer
these bits to show up in the tangled file since they appeared to serve
the purpose of having Org not fail during export vs. benefitting the
code in any way (if I wasn't running code through R, I'd just get the
errors directly).


John

> Best,
>
> --
> Eric Schulte
> https://cs.unm.edu/~eschulte
> PGP: 0x614CA05D

Re: [BABEL] BUG Re: Omitting try/catch blocks from tangled R code?

[Eric Schulte]

John Hendy <jw.hendy@gmail.com> writes:

> On Mon, Mar 17, 2014 at 10:00 AM, Eric Schulte <schulte.eric@gmail.com> wrote:
>> John Hendy <jw.hendy@gmail.com> writes:
>>
>>> On Fri, Feb 7, 2014 at 1:22 PM, Rainer M Krug <Rainer@krugs.de> wrote:
>>>>
>>>>
>>>>
>>>> On 02/07/14, 17:47 , Eric Schulte wrote:
>>>> > Rainer M Krug <Rainer@krugs.de> writes:
>>>> >
>>>> >> On 02/07/14, 07:18 , John Hendy wrote:
>>>> >>> Greetings,
>>>> >>>
>>>> >>>
>>>> >>> I don't usually tangle, but am creating a code file to go along with a
>>>> >>> presentation I'm giving this weekend so that attendees can try things
>>>> >>> out afterward by cloning my github repo where all the data and
>>>> >>> necessary files are stored.
>>>> >>>
>>>> >>> In my presentation (Beamer), I create plots via the R pdf() device,
>>>> >>> and noticed that all of the tangled code where plots are generated
>>>> >>> contains the following:
>>>> >>>
>>>> >>> pdf(file="file.pdf"); tryCatch({
>>>> >>>
>>>> >>>   code block contents here
>>>> >>>
>>>> >>> },error=function(e){plot(x=-1:1, y=-1:1, type='n', xlab='', ylab='',
>>>> >>> axes=FALSE); text(x=0, y=0, labels=e$message, col='red');
>>>> >>> paste('ERROR', e$message, sep=' : ')}); dev.off()
>>>> >>>
>>>> >>> Is there a way to omit this?
>>>> >>
>>>> >> This is a bug which must have been introduced some time ago - in the
>>>> >> stock version of emacs (Org-mode version 7.9.3f
>>>> >> (release_7.9.3f-17-g7524ef @
>>>> >> /usr/local/Cellar/emacs/24.3/share/emacs/24.3/lisp/org/)) it does not
>>>> >> tangle the enclosing commands to create graphics, but in 8.2 it does (I
>>>> >> don't have an older version at hand to go further back).
>>>> >>
>>>> >
>>>> > I believe this was introduced by your commit eaa3a761d.  Reversion of
>>>> > which with the following should provide a temporary workaround.
>>>>
>>
>> I take this back, the behavior is unrelated to Rainer's commit adding
>> try/catch blocks to R graphics creation logic.
>>
>> In fact I don't believe this is a bug, rather the default behavior is to
>> expand code block bodies on tangling.  This behavior may be changed by
>> using the :no-expand header argument which will inhibit code block body
>> expansion during tangling.
>>
>
> Got it, and thanks for the new variable tip!
>
> Out of curiosity, is there a consensus that this is the preferred
> behavior for tangling by default?

There may have been a consensus in a single thread motivated by a single
use case, which should not necessarily be a global consensus.

> I'm guessing at some point it was decided that the need was preferred
> to have these bits inserted before/after code blocks, but just trying
> to confirm this. It seems odd to me, at least given R's behavior, that
> someone would prefer these bits to show up in the tangled file since
> they appeared to serve the purpose of having Org not fail during
> export vs. benefitting the code in any way (if I wasn't running code
> through R, I'd just get the errors directly).
>

I'd be happy to add :no-expand to the default R header arguments.  Or
even to change this behavior globally, if the current behavior is
universally surprising.

Best,

>
>
> John
>
>> Best,
>>
>> --
>> Eric Schulte
>> https://cs.unm.edu/~eschulte
>> PGP: 0x614CA05D

-- 
Eric Schulte
https://cs.unm.edu/~eschulte
PGP: 0x614CA05D

Re: [BABEL] BUG Re: Omitting try/catch blocks from tangled R code?

[Rainer M Krug]

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

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

> John Hendy <jw.hendy@gmail.com> writes:
>
>> On Mon, Mar 17, 2014 at 10:00 AM, Eric Schulte <schulte.eric@gmail.com> wrote:
>>> John Hendy <jw.hendy@gmail.com> writes:
>>>
>>>> On Fri, Feb 7, 2014 at 1:22 PM, Rainer M Krug <Rainer@krugs.de> wrote:
>>>>>
>>>>>
>>>>>
>>>>> On 02/07/14, 17:47 , Eric Schulte wrote:
>>>>> > Rainer M Krug <Rainer@krugs.de> writes:
>>>>> >
>>>>> >> On 02/07/14, 07:18 , John Hendy wrote:
>>>>> >>> Greetings,
>>>>> >>>
>>>>> >>>
>>>>> >>> I don't usually tangle, but am creating a code file to go along with a
>>>>> >>> presentation I'm giving this weekend so that attendees can try things
>>>>> >>> out afterward by cloning my github repo where all the data and
>>>>> >>> necessary files are stored.
>>>>> >>>
>>>>> >>> In my presentation (Beamer), I create plots via the R pdf() device,
>>>>> >>> and noticed that all of the tangled code where plots are generated
>>>>> >>> contains the following:
>>>>> >>>
>>>>> >>> pdf(file="file.pdf"); tryCatch({
>>>>> >>>
>>>>> >>>   code block contents here
>>>>> >>>
>>>>> >>> },error=function(e){plot(x=-1:1, y=-1:1, type='n', xlab='', ylab='',
>>>>> >>> axes=FALSE); text(x=0, y=0, labels=e$message, col='red');
>>>>> >>> paste('ERROR', e$message, sep=' : ')}); dev.off()
>>>>> >>>
>>>>> >>> Is there a way to omit this?
>>>>> >>
>>>>> >> This is a bug which must have been introduced some time ago - in the
>>>>> >> stock version of emacs (Org-mode version 7.9.3f
>>>>> >> (release_7.9.3f-17-g7524ef @
>>>>> >> /usr/local/Cellar/emacs/24.3/share/emacs/24.3/lisp/org/)) it does not
>>>>> >> tangle the enclosing commands to create graphics, but in 8.2 it does (I
>>>>> >> don't have an older version at hand to go further back).
>>>>> >>
>>>>> >
>>>>> > I believe this was introduced by your commit eaa3a761d.  Reversion of
>>>>> > which with the following should provide a temporary workaround.
>>>>>
>>>
>>> I take this back, the behavior is unrelated to Rainer's commit adding
>>> try/catch blocks to R graphics creation logic.
>>>
>>> In fact I don't believe this is a bug, rather the default behavior is to
>>> expand code block bodies on tangling.  This behavior may be changed by
>>> using the :no-expand header argument which will inhibit code block body
>>> expansion during tangling.
>>>
>>
>> Got it, and thanks for the new variable tip!
>>
>> Out of curiosity, is there a consensus that this is the preferred
>> behavior for tangling by default?
>
> There may have been a consensus in a single thread motivated by a single
> use case, which should not necessarily be a global consensus.
>
>> I'm guessing at some point it was decided that the need was preferred
>> to have these bits inserted before/after code blocks, but just trying
>> to confirm this. It seems odd to me, at least given R's behavior, that
>> someone would prefer these bits to show up in the tangled file since
>> they appeared to serve the purpose of having Org not fail during
>> export vs. benefitting the code in any way (if I wasn't running code
>> through R, I'd just get the errors directly).
>>
>
> I'd be happy to add :no-expand to the default R header arguments.  Or
> even to change this behavior globally, if the current behavior is
> universally surprising.

I think the default behavior should be reverted, as tangling and
exporting are two different things. When I tangle, I want to see the
code blocks as they are in the org document (with possible variables and
expansions) but not to create files where I do not put it explicitly
into a code block. These wrappers have nothing to do with the code, and
are only there for the exported engine. So I would either revert to the
original behavior, or, introduce a new header argument,
e.g. :include-wrappers, which would, if set to t, include the export
wrappers in the tangled file. This might be useful for debugging
exporting of code block results, but not for general tangling.
 
Cheers,

Rainer

>
> Best,
>
>>
>>
>> John
>>
>>> Best,
>>>
>>> --
>>> Eric Schulte
>>> https://cs.unm.edu/~eschulte
>>> PGP: 0x614CA05D

-- 
Rainer M. Krug

email: RMKrug<at>gmail<dot>com

[-- Attachment #2: Type: application/pgp-signature, Size: 494 bytes --]

Re: [BABEL] BUG Re: Omitting try/catch blocks from tangled R code?

[John Hendy]

On Tue, Mar 18, 2014 at 3:44 AM, Rainer M Krug <Rainer@krugs.de> wrote:
> Eric Schulte <schulte.eric@gmail.com> writes:
>
>> John Hendy <jw.hendy@gmail.com> writes:
>>
>>> On Mon, Mar 17, 2014 at 10:00 AM, Eric Schulte <schulte.eric@gmail.com> wrote:
>>>> John Hendy <jw.hendy@gmail.com> writes:
>>> Out of curiosity, is there a consensus that this is the preferred
>>> behavior for tangling by default?
>>
>> There may have been a consensus in a single thread motivated by a single
>> use case, which should not necessarily be a global consensus.
>>
>>> I'm guessing at some point it was decided that the need was preferred
>>> to have these bits inserted before/after code blocks, but just trying
>>> to confirm this. It seems odd to me, at least given R's behavior, that
>>> someone would prefer these bits to show up in the tangled file since
>>> they appeared to serve the purpose of having Org not fail during
>>> export vs. benefitting the code in any way (if I wasn't running code
>>> through R, I'd just get the errors directly).
>>>
>>
>> I'd be happy to add :no-expand to the default R header arguments.  Or
>> even to change this behavior globally, if the current behavior is
>> universally surprising.
>
> I think the default behavior should be reverted, as tangling and
> exporting are two different things. When I tangle, I want to see the
> code blocks as they are in the org document (with possible variables and
> expansions) but not to create files where I do not put it explicitly
> into a code block. These wrappers have nothing to do with the code, and
> are only there for the exported engine. So I would either revert to the
> original behavior, or, introduce a new header argument,
> e.g. :include-wrappers, which would, if set to t, include the export
> wrappers in the tangled file. This might be useful for debugging
> exporting of code block results, but not for general tangling.

Thanks for chiming in. This was my gut reaction to the default
behavior. I guess we're still only a sample size of 2, but
intuitively, I would think that tangling would be a separate beast in
most cases from exporting. Just to have it on the record, if I tangle,
it's usually to take the code I've used in something like a Beamer
presentation or document and combine it into a single .R file so
someone can run it without needing Org-mode.

Re. the :include-wrappers argument, it sounds like :no-expand already
exists for this purpose... I'd just suggest (especially with your
second opinion) that it be the default value vs. having to manually
set it.


Best regards,
John

>
> Cheers,
>
> Rainer
>
>>
>> Best,
>>
>>>
>>>
>>> John
>>>
>>>> Best,
>>>>
>>>> --
>>>> Eric Schulte
>>>> https://cs.unm.edu/~eschulte
>>>> PGP: 0x614CA05D
>
> --
> Rainer M. Krug
>
> email: RMKrug<at>gmail<dot>com

Re: [BABEL] BUG Re: Omitting try/catch blocks from tangled R code?

[Charles Berry]

John Hendy <jw.hendy <at> gmail.com> writes:

[deleted]
> >
> > I think the default behavior should be reverted, as tangling and
> > exporting are two different things. When I tangle, I want to see the
> > code blocks as they are in the org document (with possible variables and
> > expansions) but not to create files where I do not put it explicitly
> > into a code block. These wrappers have nothing to do with the code, and
> > are only there for the exported engine. So I would either revert to the
> > original behavior, or, introduce a new header argument,
> > e.g. :include-wrappers, which would, if set to t, include the export
> > wrappers in the tangled file. This might be useful for debugging
> > exporting of code block results, but not for general tangling.
> 
> Thanks for chiming in. This was my gut reaction to the default
> behavior. I guess we're still only a sample size of 2, but
> intuitively, I would think that tangling would be a separate beast in
> most cases from exporting. Just to have it on the record, if I tangle,
> it's usually to take the code I've used in something like a Beamer
> presentation or document and combine it into a single .R file so
> someone can run it without needing Org-mode.

]deleted]

Sorry to be late to add my $0.02...

I never want the try/catch wrappers.

But noweb is indispensable.

I use noweb a lot to organize and collect blocks. In some cases, I export
them and in others I just tangle them.

I hope that the revised code will allow me to turn off try/catch wrapping
and still be able to use noweb when tangling or exporting.

Best,

Chuck

Re: [BABEL] BUG Re: Omitting try/catch blocks from tangled R code?

[Eric Schulte]

Charles Berry <ccberry@ucsd.edu> writes:

> John Hendy <jw.hendy <at> gmail.com> writes:
>
> [deleted]
>> >
>> > I think the default behavior should be reverted, as tangling and
>> > exporting are two different things. When I tangle, I want to see the
>> > code blocks as they are in the org document (with possible variables and
>> > expansions) but not to create files where I do not put it explicitly
>> > into a code block. These wrappers have nothing to do with the code, and
>> > are only there for the exported engine. So I would either revert to the
>> > original behavior, or, introduce a new header argument,
>> > e.g. :include-wrappers, which would, if set to t, include the export
>> > wrappers in the tangled file. This might be useful for debugging
>> > exporting of code block results, but not for general tangling.
>> 
>> Thanks for chiming in. This was my gut reaction to the default
>> behavior. I guess we're still only a sample size of 2, but
>> intuitively, I would think that tangling would be a separate beast in
>> most cases from exporting. Just to have it on the record, if I tangle,
>> it's usually to take the code I've used in something like a Beamer
>> presentation or document and combine it into a single .R file so
>> someone can run it without needing Org-mode.
>
> [deleted]
>
> Sorry to be late to add my $0.02...
>
> I never want the try/catch wrappers.
>
> But noweb is indispensable.
>
> I use noweb a lot to organize and collect blocks. In some cases, I export
> them and in others I just tangle them.
>
> I hope that the revised code will allow me to turn off try/catch wrapping
> and still be able to use noweb when tangling or exporting.
>

In addition to noweb, there are cases where variable expansion is useful
in tangled code.

The simplest option is to move things like try/catch blocks out of the
code block expansion function, and into the execution function.  Then if
other language present similar constructs (which we want to add to
execution by default but never want to tangle), we can think about
abstracting this out into some new level of code block expansion.

Thoughts?

>
> Best,
>
> Chuck
>
>

-- 
Eric Schulte
https://cs.unm.edu/~eschulte
PGP: 0x614CA05D

Re: [BABEL] BUG Re: Omitting try/catch blocks from tangled R code?

[Rainer M Krug]

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

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

> Charles Berry <ccberry@ucsd.edu> writes:
>
>> John Hendy <jw.hendy <at> gmail.com> writes:
>>
>> [deleted]
>>> >
>>> > I think the default behavior should be reverted, as tangling and
>>> > exporting are two different things. When I tangle, I want to see the
>>> > code blocks as they are in the org document (with possible variables and
>>> > expansions) but not to create files where I do not put it explicitly
>>> > into a code block. These wrappers have nothing to do with the code, and
>>> > are only there for the exported engine. So I would either revert to the
>>> > original behavior, or, introduce a new header argument,
>>> > e.g. :include-wrappers, which would, if set to t, include the export
>>> > wrappers in the tangled file. This might be useful for debugging
>>> > exporting of code block results, but not for general tangling.
>>> 
>>> Thanks for chiming in. This was my gut reaction to the default
>>> behavior. I guess we're still only a sample size of 2, but
>>> intuitively, I would think that tangling would be a separate beast in
>>> most cases from exporting. Just to have it on the record, if I tangle,
>>> it's usually to take the code I've used in something like a Beamer
>>> presentation or document and combine it into a single .R file so
>>> someone can run it without needing Org-mode.
>>
>> [deleted]
>>
>> Sorry to be late to add my $0.02...
>>
>> I never want the try/catch wrappers.
>>
>> But noweb is indispensable.
>>
>> I use noweb a lot to organize and collect blocks. In some cases, I export
>> them and in others I just tangle them.
>>
>> I hope that the revised code will allow me to turn off try/catch wrapping
>> and still be able to use noweb when tangling or exporting.
>>
>
> In addition to noweb, there are cases where variable expansion is useful
> in tangled code.
>
> The simplest option is to move things like try/catch blocks out of the
> code block expansion function, and into the execution function.  Then if
> other language present similar constructs (which we want to add to
> execution by default but never want to tangle), we can think about
> abstracting this out into some new level of code block expansion.
>
> Thoughts?

Makes perfect sense to me, and would definitely be the better place to
add them.

If one wants enclosing code in the tangling, there is always
the :epilogue and :prologue header arguments, and the try/catch should
be considered as internal to the execution.

Rainer

>
>>
>> Best,
>>
>> Chuck
>>
>>

-- 
Rainer M. Krug
email: Rainer<at>krugs<dot>de
PGP: 0x0F52F982

[-- Attachment #2: Type: application/pgp-signature, Size: 494 bytes --]

Re: [BABEL] BUG Re: Omitting try/catch blocks from tangled R code?

[Eric Schulte]

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

Rainer M Krug <Rainer@krugs.de> writes:

> Eric Schulte <schulte.eric@gmail.com> writes:
>
>> Charles Berry <ccberry@ucsd.edu> writes:
>>
>>> John Hendy <jw.hendy <at> gmail.com> writes:
>>>
>>> [deleted]
>>>> >
>>>> > I think the default behavior should be reverted, as tangling and
>>>> > exporting are two different things. When I tangle, I want to see the
>>>> > code blocks as they are in the org document (with possible variables and
>>>> > expansions) but not to create files where I do not put it explicitly
>>>> > into a code block. These wrappers have nothing to do with the code, and
>>>> > are only there for the exported engine. So I would either revert to the
>>>> > original behavior, or, introduce a new header argument,
>>>> > e.g. :include-wrappers, which would, if set to t, include the export
>>>> > wrappers in the tangled file. This might be useful for debugging
>>>> > exporting of code block results, but not for general tangling.
>>>> 
>>>> Thanks for chiming in. This was my gut reaction to the default
>>>> behavior. I guess we're still only a sample size of 2, but
>>>> intuitively, I would think that tangling would be a separate beast in
>>>> most cases from exporting. Just to have it on the record, if I tangle,
>>>> it's usually to take the code I've used in something like a Beamer
>>>> presentation or document and combine it into a single .R file so
>>>> someone can run it without needing Org-mode.
>>>
>>> [deleted]
>>>
>>> Sorry to be late to add my $0.02...
>>>
>>> I never want the try/catch wrappers.
>>>
>>> But noweb is indispensable.
>>>
>>> I use noweb a lot to organize and collect blocks. In some cases, I export
>>> them and in others I just tangle them.
>>>
>>> I hope that the revised code will allow me to turn off try/catch wrapping
>>> and still be able to use noweb when tangling or exporting.
>>>
>>
>> In addition to noweb, there are cases where variable expansion is useful
>> in tangled code.
>>
>> The simplest option is to move things like try/catch blocks out of the
>> code block expansion function, and into the execution function.  Then if
>> other language present similar constructs (which we want to add to
>> execution by default but never want to tangle), we can think about
>> abstracting this out into some new level of code block expansion.
>>
>> Thoughts?
>
> Makes perfect sense to me, and would definitely be the better place to
> add them.
>
> If one wants enclosing code in the tangling, there is always
> the :epilogue and :prologue header arguments, and the try/catch should
> be considered as internal to the execution.
>

Great, how's this patch work?  If it looks good I'll apply it.

Thanks,


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-only-wrap-R-code-graphics-file-on-execution.patch --]
[-- Type: text/x-diff, Size: 2774 bytes --]

From 838f26c35867e7af0dc46698db41d4df13dfb890 Mon Sep 17 00:00:00 2001
From: Eric Schulte <schulte.eric@gmail.com>
Date: Sun, 23 Mar 2014 20:01:37 -0600
Subject: [PATCH] only wrap R code graphics-file on execution

  Move this out of the expand-body function so that it is *never*
  applied to tangled code.
---
 lisp/ob-R.el | 39 ++++++++++++++++++++-------------------
 1 file changed, 20 insertions(+), 19 deletions(-)

diff --git a/lisp/ob-R.el b/lisp/ob-R.el
index 62aa7f2..bf7029c 100644
--- a/lisp/ob-R.el
+++ b/lisp/ob-R.el
@@ -97,24 +97,15 @@ this variable.")
   "Expand BODY according to PARAMS, return the expanded body."
   (let ((graphics-file
 	 (or graphics-file (org-babel-R-graphical-output-file params))))
-    (mapconcat
-     #'identity
-     (let ((inside
-            (append
-             (when (cdr (assoc :prologue params))
-               (list (cdr (assoc :prologue params))))
-             (org-babel-variable-assignments:R params)
-             (list body)
-             (when (cdr (assoc :epilogue params))
-               (list (cdr (assoc :epilogue params)))))))
-       (if graphics-file
-           (append
-            (list (org-babel-R-construct-graphics-device-call
-                   graphics-file params))
-            inside
-            (list "},error=function(e){plot(x=-1:1, y=-1:1, type='n', xlab='', ylab='', axes=FALSE); text(x=0, y=0, labels=e$message, col='red'); paste('ERROR', e$message, sep=' : ')}); dev.off()"))
-         inside))
-     "\n")))
+    (mapconcat #'identity
+	       (append
+		(when (cdr (assoc :prologue params))
+		  (list (cdr (assoc :prologue params))))
+		(org-babel-variable-assignments:R params)
+		(list body)
+		(when (cdr (assoc :epilogue params))
+		  (list (cdr (assoc :epilogue params)))))
+	       "\n")))
 
 (defun org-babel-execute:R (body params)
   "Execute a block of R code.
@@ -127,7 +118,17 @@ This function is called by `org-babel-execute-src-block'."
 	   (colnames-p (cdr (assoc :colnames params)))
 	   (rownames-p (cdr (assoc :rownames params)))
 	   (graphics-file (org-babel-R-graphical-output-file params))
-	   (full-body (org-babel-expand-body:R body params graphics-file))
+	   (full-body
+	    (let ((inside (org-babel-expand-body:R body params graphics-file)))
+	      (mapconcat #'identity
+			 (if graphics-file
+			     (append
+			      (list (org-babel-R-construct-graphics-device-call
+				     graphics-file params))
+			      inside
+			      (list "},error=function(e){plot(x=-1:1, y=-1:1, type='n', xlab='', ylab='', axes=FALSE); text(x=0, y=0, labels=e$message, col='red'); paste('ERROR', e$message, sep=' : ')}); dev.off()"))
+			   inside)
+			 "\n")))
 	   (result
 	    (org-babel-R-evaluate
 	     session full-body result-type result-params
-- 
1.9.0


[-- Attachment #3: Type: text/plain, Size: 63 bytes --]


-- 
Eric Schulte
https://cs.unm.edu/~eschulte
PGP: 0x614CA05D

Re: [BABEL] BUG Re: Omitting try/catch blocks from tangled R code?

[Rainer M Krug]

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


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

> Rainer M Krug <Rainer@krugs.de> writes:
>
>> Eric Schulte <schulte.eric@gmail.com> writes:
>>
>>> Charles Berry <ccberry@ucsd.edu> writes:
>>>
>>>> John Hendy <jw.hendy <at> gmail.com> writes:
>>>>
>>>> [deleted]
>>>>> >
>>>>> > I think the default behavior should be reverted, as tangling and
>>>>> > exporting are two different things. When I tangle, I want to see the
>>>>> > code blocks as they are in the org document (with possible variables and
>>>>> > expansions) but not to create files where I do not put it explicitly
>>>>> > into a code block. These wrappers have nothing to do with the code, and
>>>>> > are only there for the exported engine. So I would either revert to the
>>>>> > original behavior, or, introduce a new header argument,
>>>>> > e.g. :include-wrappers, which would, if set to t, include the export
>>>>> > wrappers in the tangled file. This might be useful for debugging
>>>>> > exporting of code block results, but not for general tangling.
>>>>> 
>>>>> Thanks for chiming in. This was my gut reaction to the default
>>>>> behavior. I guess we're still only a sample size of 2, but
>>>>> intuitively, I would think that tangling would be a separate beast in
>>>>> most cases from exporting. Just to have it on the record, if I tangle,
>>>>> it's usually to take the code I've used in something like a Beamer
>>>>> presentation or document and combine it into a single .R file so
>>>>> someone can run it without needing Org-mode.
>>>>
>>>> [deleted]
>>>>
>>>> Sorry to be late to add my $0.02...
>>>>
>>>> I never want the try/catch wrappers.
>>>>
>>>> But noweb is indispensable.
>>>>
>>>> I use noweb a lot to organize and collect blocks. In some cases, I export
>>>> them and in others I just tangle them.
>>>>
>>>> I hope that the revised code will allow me to turn off try/catch wrapping
>>>> and still be able to use noweb when tangling or exporting.
>>>>
>>>
>>> In addition to noweb, there are cases where variable expansion is useful
>>> in tangled code.
>>>
>>> The simplest option is to move things like try/catch blocks out of the
>>> code block expansion function, and into the execution function.  Then if
>>> other language present similar constructs (which we want to add to
>>> execution by default but never want to tangle), we can think about
>>> abstracting this out into some new level of code block expansion.
>>>
>>> Thoughts?
>>
>> Makes perfect sense to me, and would definitely be the better place to
>> add them.
>>
>> If one wants enclosing code in the tangling, there is always
>> the :epilogue and :prologue header arguments, and the try/catch should
>> be considered as internal to the execution.
>>
>
> Great, how's this patch work?  If it looks good I'll apply it.

Git still puzzles me a lot... If you tell me how I can apply this patch
(from emacs?) I will try it out.

Thanks,

Rainer

>
> Thanks,

-- 
Rainer M. Krug
email: Rainer<at>krugs<dot>de
PGP: 0x0F52F982

[-- Attachment #2: Type: application/pgp-signature, Size: 494 bytes --]

Re: [BABEL] BUG Re: Omitting try/catch blocks from tangled R code?

[Eric Schulte]

Rainer M Krug <Rainer@krugs.de> writes:

> Eric Schulte <schulte.eric@gmail.com> writes:
>
>> Rainer M Krug <Rainer@krugs.de> writes:
>>
>>> Eric Schulte <schulte.eric@gmail.com> writes:
>>>
>>>> Charles Berry <ccberry@ucsd.edu> writes:
>>>>
>>>>> John Hendy <jw.hendy <at> gmail.com> writes:
>>>>>
>>>>> [deleted]
>>>>>> >
>>>>>> > I think the default behavior should be reverted, as tangling and
>>>>>> > exporting are two different things. When I tangle, I want to see the
>>>>>> > code blocks as they are in the org document (with possible variables and
>>>>>> > expansions) but not to create files where I do not put it explicitly
>>>>>> > into a code block. These wrappers have nothing to do with the code, and
>>>>>> > are only there for the exported engine. So I would either revert to the
>>>>>> > original behavior, or, introduce a new header argument,
>>>>>> > e.g. :include-wrappers, which would, if set to t, include the export
>>>>>> > wrappers in the tangled file. This might be useful for debugging
>>>>>> > exporting of code block results, but not for general tangling.
>>>>>> 
>>>>>> Thanks for chiming in. This was my gut reaction to the default
>>>>>> behavior. I guess we're still only a sample size of 2, but
>>>>>> intuitively, I would think that tangling would be a separate beast in
>>>>>> most cases from exporting. Just to have it on the record, if I tangle,
>>>>>> it's usually to take the code I've used in something like a Beamer
>>>>>> presentation or document and combine it into a single .R file so
>>>>>> someone can run it without needing Org-mode.
>>>>>
>>>>> [deleted]
>>>>>
>>>>> Sorry to be late to add my $0.02...
>>>>>
>>>>> I never want the try/catch wrappers.
>>>>>
>>>>> But noweb is indispensable.
>>>>>
>>>>> I use noweb a lot to organize and collect blocks. In some cases, I export
>>>>> them and in others I just tangle them.
>>>>>
>>>>> I hope that the revised code will allow me to turn off try/catch wrapping
>>>>> and still be able to use noweb when tangling or exporting.
>>>>>
>>>>
>>>> In addition to noweb, there are cases where variable expansion is useful
>>>> in tangled code.
>>>>
>>>> The simplest option is to move things like try/catch blocks out of the
>>>> code block expansion function, and into the execution function.  Then if
>>>> other language present similar constructs (which we want to add to
>>>> execution by default but never want to tangle), we can think about
>>>> abstracting this out into some new level of code block expansion.
>>>>
>>>> Thoughts?
>>>
>>> Makes perfect sense to me, and would definitely be the better place to
>>> add them.
>>>
>>> If one wants enclosing code in the tangling, there is always
>>> the :epilogue and :prologue header arguments, and the try/catch should
>>> be considered as internal to the execution.
>>>
>>
>> Great, how's this patch work?  If it looks good I'll apply it.
>
> Git still puzzles me a lot... If you tell me how I can apply this patch
> (from emacs?) I will try it out.
>

Here are some instructions from the command line.

1. write the patch out to a file on disk, say /tmp/0001-etc...patch

2. cd into the org-mode directory

3. make sure you're up to date with the latest

     git pull

4. apply the patch

     git am /tmp/0001-etc...patch

and that should do it.

Best,

>
> Thanks,
>
> Rainer
>
>>
>> Thanks,

-- 
Eric Schulte
https://cs.unm.edu/~eschulte
PGP: 0x614CA05D

Re: [BABEL] BUG Re: Omitting try/catch blocks from tangled R code?

[Rainer M Krug]

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

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

> Rainer M Krug <Rainer@krugs.de> writes:
>
>> Eric Schulte <schulte.eric@gmail.com> writes:
>>
>>> Rainer M Krug <Rainer@krugs.de> writes:
>>>
>>>> Eric Schulte <schulte.eric@gmail.com> writes:
>>>>
>>>>> Charles Berry <ccberry@ucsd.edu> writes:
>>>>>
>>>>>> John Hendy <jw.hendy <at> gmail.com> writes:
>>>>>>
>>>>>> [deleted]
>>>>>>> >
>>>>>>> > I think the default behavior should be reverted, as tangling and
>>>>>>> > exporting are two different things. When I tangle, I want to see the
>>>>>>> > code blocks as they are in the org document (with possible variables and
>>>>>>> > expansions) but not to create files where I do not put it explicitly
>>>>>>> > into a code block. These wrappers have nothing to do with the code, and
>>>>>>> > are only there for the exported engine. So I would either revert to the
>>>>>>> > original behavior, or, introduce a new header argument,
>>>>>>> > e.g. :include-wrappers, which would, if set to t, include the export
>>>>>>> > wrappers in the tangled file. This might be useful for debugging
>>>>>>> > exporting of code block results, but not for general tangling.
>>>>>>> 
>>>>>>> Thanks for chiming in. This was my gut reaction to the default
>>>>>>> behavior. I guess we're still only a sample size of 2, but
>>>>>>> intuitively, I would think that tangling would be a separate beast in
>>>>>>> most cases from exporting. Just to have it on the record, if I tangle,
>>>>>>> it's usually to take the code I've used in something like a Beamer
>>>>>>> presentation or document and combine it into a single .R file so
>>>>>>> someone can run it without needing Org-mode.
>>>>>>
>>>>>> [deleted]
>>>>>>
>>>>>> Sorry to be late to add my $0.02...
>>>>>>
>>>>>> I never want the try/catch wrappers.
>>>>>>
>>>>>> But noweb is indispensable.
>>>>>>
>>>>>> I use noweb a lot to organize and collect blocks. In some cases, I export
>>>>>> them and in others I just tangle them.
>>>>>>
>>>>>> I hope that the revised code will allow me to turn off try/catch wrapping
>>>>>> and still be able to use noweb when tangling or exporting.
>>>>>>
>>>>>
>>>>> In addition to noweb, there are cases where variable expansion is useful
>>>>> in tangled code.
>>>>>
>>>>> The simplest option is to move things like try/catch blocks out of the
>>>>> code block expansion function, and into the execution function.  Then if
>>>>> other language present similar constructs (which we want to add to
>>>>> execution by default but never want to tangle), we can think about
>>>>> abstracting this out into some new level of code block expansion.
>>>>>
>>>>> Thoughts?
>>>>
>>>> Makes perfect sense to me, and would definitely be the better place to
>>>> add them.
>>>>
>>>> If one wants enclosing code in the tangling, there is always
>>>> the :epilogue and :prologue header arguments, and the try/catch should
>>>> be considered as internal to the execution.
>>>>
>>>
>>> Great, how's this patch work?  If it looks good I'll apply it.
>>
>> Git still puzzles me a lot... If you tell me how I can apply this patch
>> (from emacs?) I will try it out.
>>
>
> Here are some instructions from the command line.
>
> 1. write the patch out to a file on disk, say /tmp/0001-etc...patch
>
> 2. cd into the org-mode directory
>
> 3. make sure you're up to date with the latest
>
>      git pull
>
> 4. apply the patch
>
>      git am /tmp/0001-etc...patch
>
> and that should do it.

OK - managed to apply the patch.

Using 

Org-mode version 8.2.5h (release_8.2.5h-846-geb806d @ /Users/rainerkrug/.emacs.d/org-mode/lisp/)

updated this morning, I get the following error:

,----
| Debugger entered--Lisp error: (wrong-type-argument sequencep 67)
|   mapconcat(identity "COLUMNS <- read.table(\"/var/folders/50/wcr5bjwn75q595n6x82gxj280000gn/T/babel-21363l1U/R-import-21363S9b\",\n                      header=TRUE,\n                      row.names=1,\n                      sep=\"\\t\",\n                      as.is=TRUE)\nCOLS_TO_EVAL <- read.table(\"/var/folders/50/wcr5bjwn75q595n6x82gxj280000gn/T/babel-21363l1U/R-import-21363fHi\",\n                      header=TRUE,\n                      row.names=1,\n                      sep=\"\\t\",\n                      as.is=TRUE)\nALLSPECIES <- read.table(\"/var/folders/50/wcr5bjwn75q595n6x82gxj280000gn/T/babel-21363l1U/R-import-21363sRo\",\n                      header=TRUE,\n                      row.names=1,\n                      sep=\"\\t\",\n                      as.is=TRUE)\nSPECIES <- read.table(\"/var/folders/50/wcr5bjwn75q595n6x82gxj280000gn/T/babel-21363l1U/R-import-213635bu\",\n                      header=TRUE,\n                      row.names=1,\n                      sep=\"\\t\",\n                      as.is=TRUE)\nYEARS <- read.table(\"/var/folders/50/wcr5bjwn75q595n6x82gxj280000gn/T/babel-21363l1U/R-import-21363Gm0\",\n                      header=TRUE,\n                      row.names=1,\n                      sep=\"\\t\",\n                      as.is=TRUE)\nPRESENT <- 2008\nMINEFFORT <- 3\nPROPTRAIN <- 0.6\nRNGSEED <- 13\nRNGKIND <- \"Mersenne-Twister\"\nRNGNORMALKIND <- \"Inversion\"\nREFGRID <- \"./refGrid_8km.rds\"\nIFN <- \"./__BOX__/IFN/DB_IFN/rds/tabplot.rds\"\nIFNCOUNT <- \"./__BOX__/IFN/DB_IFN/rdsRasterized/tabplot.count.8km.rds\"\nIFNMEAN <- \"./__BOX__/IFN/DB_IFN/rdsRasterized/tabplot.mean.8km.rds\"\nIFNPRES <- \"./__BOX__/IFN/DB_IFN/rdsRasterized/tabplot.pres.8km.rds\"\nIFNSD <- \"./__BOX__/IFN/DB_IFN/rdsRasterized/tabplot.sd.8km.rds\"\nIFNTABTREE <- \"./__BOX__/IFN/DB_IFN/rds/tabtree.rds\"\ndata.sources <- list.files(\"./data\", pattern=\"*.rda$\", full.names=TRUE)\nR.sources <- list.files(\"./R\", pattern=\"*.R$\", full.names=TRUE)\ncat(\"Loading Data\\n\")\nas.vector( sapply( data.sources, load) )\ncat(\"\\nSourcing R files\\n\")\nsapply( R.sources, source)" "\n")
|   org-babel-execute:R("data.sources <- list.files(\"./data\", pattern=\"*.rda$\", full.names=TRUE)\nR.sources <- list.files(\"./R\", pattern=\"*.R$\", full.names=TRUE)\ncat(\"Loading Data\\n\")\nas.vector( sapply( data.sources, load) )\ncat(\"\\nSourcing R files\\n\")\nsapply( R.sources, source)" ((:comments . "link") (:shebang . "") (:cache . "no") (:padline . "yes") (:noweb . "no") (:tangle . "yes") (:exports . "both") (:results . "replace output") (:var COLUMNS ("annee" "Year of simulation") ("ipoints_Qdiv" "Point Number (also refer to number of the climatic input file)") ("iespece" "species number (4==>Beech; 3:Oak)") ("scenario" "Type of forest management (no matter)") ("climat" "Type of climate (no matter)") ("RUsolinit" "Soil water Holding Capacity of the point (mm)") ("PByC" "gross photosynthesis (yearly, gC/m²/year)") ("PNyC" "Net photosynthesis, (PByC - leaf Respiration) (gC/m²/year)") ("NPPyC" "Net primary productivity, (gC/m²/year)") ("ETRy" "Evapotranspiration of stand (mm/year)") ("age_peup" "Age at the end of the revolution") ("RVy" "total respiration of living tissue") ("DBBVy" "aboveground annualm growth (gC/m²/year)") ("RMTVy" "maintenance respiration of stems (gC/m²/year)") ("RMBRy" "maintenance respiration of branches (gC/m²/year)") ("Rtoty" "total heterotrophic respiration (gC/m²/year) (SOIL)") ("levelstress_2" "indices of water stress based on stomatal conductance") ("Ta" "Annual Temperature (°C) (do not use problem)") ("PRI" "Rain (mm) (do not use problem)") ("LMAX" "Leaf Area Index") ("RVCy" "Growth respiration of living tissue") ("RVMy" "Maintenance respiration of all living tissue") ("DBSSy" "annual storage growth (gc/m²/year)") ("DBRFy" "annual fine roots growth (gC/m²/year)") ("LambX" "X co,ordinates in Lamberts Zone II (EPSG 27572)") ("LambY" "Y co,ordinates in Lamberts Zone II (EPSG 27572)") ("Altitude" "Elevation(m)") ("coupebb" "exported biomass through cutting (gC/m²)") ("bbois" "wood biomass of the stand (gC/m²)")) (:var COLS_TO_EVAL ("NPPyC" "FALSE") ("DBBVy" "TRUE") ("DBRFy" "FALSE") ("DBSSy" "FALSE") ("levelstress_2" "TRUE")) (:var ALLSPECIES ("Quercus robur" 1 "quercus_robur" "") ("Quercus peatrea" 2 "quercus_peatrea" "") ("Quercus pubescens" 3 "quercus_pubescens" "") ("Fagus sylvatica" 4 "fagus_sylvatica" "") ("Carpinus betulus" 5 "carpinus_betulus" "") ("Other broadleaf species" 6 "other_broadleaf_species" "") ("Picae abies" 7 "picae_abies" "") ("Abies alba" 8 "abies_alba" "") ("Pinus maritima" 9 "pinus_maritima" "") ("Pinus sylvestris" 10 "pinus_sylvestris" "") ("pseudotsuga meniezi" 11 "pseudotsuga_meniezi" "") ("Other coniferous species" 12 "other_coniferous_species" "")) (:var SPECIES ("Fagus sylvatica" "fagus" 4 "fagus_sylvatica" "red") ("Quercus robur" "quercus" 3 "quercus_robur" "green")) (:var YEARS (1990) (2000)) (:var PRESENT . 2008) (:var MINEFFORT . 3) (:var PROPTRAIN . 0.6) (:var RNGSEED . 13) (:var RNGKIND . "Mersenne-Twister") (:var RNGNORMALKIND . "Inversion") (:var REFGRID . "./refGrid_8km.rds") (:var IFN . "./__BOX__/IFN/DB_IFN/rds/tabplot.rds") (:var IFNCOUNT . "./__BOX__/IFN/DB_IFN/rdsRasterized/tabplot.count.8km.rds") (:var IFNMEAN . "./__BOX__/IFN/DB_IFN/rdsRasterized/tabplot.mean.8km.rds") (:var IFNPRES . "./__BOX__/IFN/DB_IFN/rdsRasterized/tabplot.pres.8km.rds") (:var IFNSD . "./__BOX__/IFN/DB_IFN/rdsRasterized/tabplot.sd.8km.rds") (:var IFNTABTREE . "./__BOX__/IFN/DB_IFN/rds/tabtree.rds") (:hlines . "no") (:colnames . "yes") (:mkdirp . "yes") (:no-expand . "TRUE") (:rownames . "yes") (:session . "*R_MOBILIS*") (:tangle-mode . 292) (:result-type . output) (:result-params "output" "replace") (:rowname-names (COLUMNS "annee" "ipoints_Qdiv" "iespece" "scenario" "climat" "RUsolinit" "PByC" "PNyC" "NPPyC" "ETRy" "age_peup" "RVy" "DBBVy" "RMTVy" "RMBRy" "Rtoty" "levelstress_2" "Ta" "PRI" "LMAX" "RVCy" "RVMy" "DBSSy" "DBRFy" "LambX" "LambY" "Altitude" "coupebb" "bbois") (COLS_TO_EVAL 1 2 3 4 5) (ALLSPECIES 1 2 3 4 5 6 7 8 9 10 11 12) (SPECIES "fagus" "quercus") (YEARS 1 2)) (:colname-names (COLUMNS "" "name" "description") (COLS_TO_EVAL "" "name" "usable") (ALLSPECIES "" "fullName" "iespece" "IFNName" "color") (SPECIES "" "fullName" "shortName" "iespece" "IFNName" "color") (YEARS "" "year"))))
|   org-babel-execute-src-block(nil)
|   org-babel-execute-buffer(nil)
|   org-babel-execute-subtree(nil)
|   call-interactively(org-babel-execute-subtree nil nil)
`----

Cheers,

Rainer

>
> Best,
>
>>
>> Thanks,
>>
>> Rainer
>>
>>>
>>> Thanks,

-- 
Rainer M. Krug
email: Rainer<at>krugs<dot>de
PGP: 0x0F52F982

[-- Attachment #2: Type: application/pgp-signature, Size: 494 bytes --]

Re: [BABEL] BUG Re: Omitting try/catch blocks from tangled R code?

[Eric Schulte]

Rainer M Krug <Rainer@krugs.de> writes:

> Eric Schulte <schulte.eric@gmail.com> writes:
>
>> Rainer M Krug <Rainer@krugs.de> writes:
>>
>>> Eric Schulte <schulte.eric@gmail.com> writes:
>>>
>>>> Rainer M Krug <Rainer@krugs.de> writes:
>>>>
>>>>> Eric Schulte <schulte.eric@gmail.com> writes:
>>>>>
>>>>>> Charles Berry <ccberry@ucsd.edu> writes:
>>>>>>
>>>>>>> John Hendy <jw.hendy <at> gmail.com> writes:
>>>>>>>
>>>>>>> [deleted]
>>>>>>>> >
>>>>>>>> > I think the default behavior should be reverted, as tangling and
>>>>>>>> > exporting are two different things. When I tangle, I want to see the
>>>>>>>> > code blocks as they are in the org document (with possible variables and
>>>>>>>> > expansions) but not to create files where I do not put it explicitly
>>>>>>>> > into a code block. These wrappers have nothing to do with the code, and
>>>>>>>> > are only there for the exported engine. So I would either revert to the
>>>>>>>> > original behavior, or, introduce a new header argument,
>>>>>>>> > e.g. :include-wrappers, which would, if set to t, include the export
>>>>>>>> > wrappers in the tangled file. This might be useful for debugging
>>>>>>>> > exporting of code block results, but not for general tangling.
>>>>>>>> 
>>>>>>>> Thanks for chiming in. This was my gut reaction to the default
>>>>>>>> behavior. I guess we're still only a sample size of 2, but
>>>>>>>> intuitively, I would think that tangling would be a separate beast in
>>>>>>>> most cases from exporting. Just to have it on the record, if I tangle,
>>>>>>>> it's usually to take the code I've used in something like a Beamer
>>>>>>>> presentation or document and combine it into a single .R file so
>>>>>>>> someone can run it without needing Org-mode.
>>>>>>>
>>>>>>> [deleted]
>>>>>>>
>>>>>>> Sorry to be late to add my $0.02...
>>>>>>>
>>>>>>> I never want the try/catch wrappers.
>>>>>>>
>>>>>>> But noweb is indispensable.
>>>>>>>
>>>>>>> I use noweb a lot to organize and collect blocks. In some cases, I export
>>>>>>> them and in others I just tangle them.
>>>>>>>
>>>>>>> I hope that the revised code will allow me to turn off try/catch wrapping
>>>>>>> and still be able to use noweb when tangling or exporting.
>>>>>>>
>>>>>>
>>>>>> In addition to noweb, there are cases where variable expansion is useful
>>>>>> in tangled code.
>>>>>>
>>>>>> The simplest option is to move things like try/catch blocks out of the
>>>>>> code block expansion function, and into the execution function.  Then if
>>>>>> other language present similar constructs (which we want to add to
>>>>>> execution by default but never want to tangle), we can think about
>>>>>> abstracting this out into some new level of code block expansion.
>>>>>>
>>>>>> Thoughts?
>>>>>
>>>>> Makes perfect sense to me, and would definitely be the better place to
>>>>> add them.
>>>>>
>>>>> If one wants enclosing code in the tangling, there is always
>>>>> the :epilogue and :prologue header arguments, and the try/catch should
>>>>> be considered as internal to the execution.
>>>>>
>>>>
>>>> Great, how's this patch work?  If it looks good I'll apply it.
>>>
>>> Git still puzzles me a lot... If you tell me how I can apply this patch
>>> (from emacs?) I will try it out.
>>>
>>
>> Here are some instructions from the command line.
>>
>> 1. write the patch out to a file on disk, say /tmp/0001-etc...patch
>>
>> 2. cd into the org-mode directory
>>
>> 3. make sure you're up to date with the latest
>>
>>      git pull
>>
>> 4. apply the patch
>>
>>      git am /tmp/0001-etc...patch
>>
>> and that should do it.
>
> OK - managed to apply the patch.
>
> Using 
>
> Org-mode version 8.2.5h (release_8.2.5h-846-geb806d @ /Users/rainerkrug/.emacs.d/org-mode/lisp/)
>
> updated this morning, I get the following error:
>

Could you provide a minimal example file generating this error?

Thanks,

>
> ,----
> | Debugger entered--Lisp error: (wrong-type-argument sequencep 67)
> |   mapconcat(identity "COLUMNS <-
> | read.table(\"/var/folders/50/wcr5bjwn75q595n6x82gxj280000gn/T/babel-21363l1U/R-import-21363S9b\",\n
> | header=TRUE,\n row.names=1,\n sep=\"\\t\",\n
> | as.is=TRUE)\nCOLS_TO_EVAL <-
> | read.table(\"/var/folders/50/wcr5bjwn75q595n6x82gxj280000gn/T/babel-21363l1U/R-import-21363fHi\",\n
> | header=TRUE,\n row.names=1,\n sep=\"\\t\",\n as.is=TRUE)\nALLSPECIES
> | <-
> | read.table(\"/var/folders/50/wcr5bjwn75q595n6x82gxj280000gn/T/babel-21363l1U/R-import-21363sRo\",\n
> | header=TRUE,\n row.names=1,\n sep=\"\\t\",\n as.is=TRUE)\nSPECIES <-
> | read.table(\"/var/folders/50/wcr5bjwn75q595n6x82gxj280000gn/T/babel-21363l1U/R-import-213635bu\",\n
> | header=TRUE,\n row.names=1,\n sep=\"\\t\",\n as.is=TRUE)\nYEARS <-
> | read.table(\"/var/folders/50/wcr5bjwn75q595n6x82gxj280000gn/T/babel-21363l1U/R-import-21363Gm0\",\n
> | header=TRUE,\n row.names=1,\n sep=\"\\t\",\n as.is=TRUE)\nPRESENT <-
> | 2008\nMINEFFORT <- 3\nPROPTRAIN <- 0.6\nRNGSEED <- 13\nRNGKIND <-
> | \"Mersenne-Twister\"\nRNGNORMALKIND <- \"Inversion\"\nREFGRID <-
> | \"./refGrid_8km.rds\"\nIFN <-
> | \"./__BOX__/IFN/DB_IFN/rds/tabplot.rds\"\nIFNCOUNT <-
> | \"./__BOX__/IFN/DB_IFN/rdsRasterized/tabplot.count.8km.rds\"\nIFNMEAN
> | <-
> | \"./__BOX__/IFN/DB_IFN/rdsRasterized/tabplot.mean.8km.rds\"\nIFNPRES
> | <-
> | \"./__BOX__/IFN/DB_IFN/rdsRasterized/tabplot.pres.8km.rds\"\nIFNSD
> | <-
> | \"./__BOX__/IFN/DB_IFN/rdsRasterized/tabplot.sd.8km.rds\"\nIFNTABTREE
> | <- \"./__BOX__/IFN/DB_IFN/rds/tabtree.rds\"\ndata.sources <-
> | list.files(\"./data\", pattern=\"*.rda$\",
> | full.names=TRUE)\nR.sources <- list.files(\"./R\", pattern=\"*.R$\",
> | full.names=TRUE)\ncat(\"Loading Data\\n\")\nas.vector( sapply(
> | data.sources, load) )\ncat(\"\\nSourcing R files\\n\")\nsapply(
> | R.sources, source)" "\n")
> |   org-babel-execute:R("data.sources <- list.files(\"./data\",
> | pattern=\"*.rda$\", full.names=TRUE)\nR.sources <-
> | list.files(\"./R\", pattern=\"*.R$\",
> | full.names=TRUE)\ncat(\"Loading Data\\n\")\nas.vector( sapply(
> | data.sources, load) )\ncat(\"\\nSourcing R files\\n\")\nsapply(
> | R.sources, source)" ((:comments . "link") (:shebang . "") (:cache
> | . "no") (:padline . "yes") (:noweb . "no") (:tangle . "yes")
> | (:exports . "both") (:results . "replace output") (:var COLUMNS
> | ("annee" "Year of simulation") ("ipoints_Qdiv" "Point Number (also
> | refer to number of the climatic input file)") ("iespece" "species
> | number (4==>Beech; 3:Oak)") ("scenario" "Type of forest management
> | (no matter)") ("climat" "Type of climate (no matter)") ("RUsolinit"
> | "Soil water Holding Capacity of the point (mm)") ("PByC" "gross
> | photosynthesis (yearly, gC/m²/year)") ("PNyC" "Net photosynthesis,
> | (PByC - leaf Respiration) (gC/m²/year)") ("NPPyC" "Net primary
> | productivity, (gC/m²/year)") ("ETRy" "Evapotranspiration of stand
> | (mm/year)") ("age_peup" "Age at the end of the revolution") ("RVy"
> | "total respiration of living tissue") ("DBBVy" "aboveground annualm
> | growth (gC/m²/year)") ("RMTVy" "maintenance respiration of stems
> | (gC/m²/year)") ("RMBRy" "maintenance respiration of branches
> | (gC/m²/year)") ("Rtoty" "total heterotrophic respiration
> | (gC/m²/year) (SOIL)") ("levelstress_2" "indices of water stress
> | based on stomatal conductance") ("Ta" "Annual Temperature (°C) (do
> | not use problem)") ("PRI" "Rain (mm) (do not use problem)") ("LMAX"
> | "Leaf Area Index") ("RVCy" "Growth respiration of living tissue")
> | ("RVMy" "Maintenance respiration of all living tissue") ("DBSSy"
> | "annual storage growth (gc/m²/year)") ("DBRFy" "annual fine roots
> | growth (gC/m²/year)") ("LambX" "X co,ordinates in Lamberts Zone II
> | (EPSG 27572)") ("LambY" "Y co,ordinates in Lamberts Zone II (EPSG
> | 27572)") ("Altitude" "Elevation(m)") ("coupebb" "exported biomass
> | through cutting (gC/m²)") ("bbois" "wood biomass of the stand
> | (gC/m²)")) (:var COLS_TO_EVAL ("NPPyC" "FALSE") ("DBBVy" "TRUE")
> | ("DBRFy" "FALSE") ("DBSSy" "FALSE") ("levelstress_2" "TRUE")) (:var
> | ALLSPECIES ("Quercus robur" 1 "quercus_robur" "") ("Quercus peatrea"
> | 2 "quercus_peatrea" "") ("Quercus pubescens" 3 "quercus_pubescens"
> | "") ("Fagus sylvatica" 4 "fagus_sylvatica" "") ("Carpinus betulus" 5
> | "carpinus_betulus" "") ("Other broadleaf species" 6
> | "other_broadleaf_species" "") ("Picae abies" 7 "picae_abies" "")
> | ("Abies alba" 8 "abies_alba" "") ("Pinus maritima" 9
> | "pinus_maritima" "") ("Pinus sylvestris" 10 "pinus_sylvestris" "")
> | ("pseudotsuga meniezi" 11 "pseudotsuga_meniezi" "") ("Other
> | coniferous species" 12 "other_coniferous_species" "")) (:var SPECIES
> | ("Fagus sylvatica" "fagus" 4 "fagus_sylvatica" "red") ("Quercus
> | robur" "quercus" 3 "quercus_robur" "green")) (:var YEARS (1990)
> | (2000)) (:var PRESENT . 2008) (:var MINEFFORT . 3) (:var PROPTRAIN
> | . 0.6) (:var RNGSEED . 13) (:var RNGKIND . "Mersenne-Twister") (:var
> | RNGNORMALKIND . "Inversion") (:var REFGRID . "./refGrid_8km.rds")
> | (:var IFN . "./__BOX__/IFN/DB_IFN/rds/tabplot.rds") (:var IFNCOUNT
> | . "./__BOX__/IFN/DB_IFN/rdsRasterized/tabplot.count.8km.rds") (:var
> | IFNMEAN . "./__BOX__/IFN/DB_IFN/rdsRasterized/tabplot.mean.8km.rds")
> | (:var IFNPRES
> | . "./__BOX__/IFN/DB_IFN/rdsRasterized/tabplot.pres.8km.rds") (:var
> | IFNSD . "./__BOX__/IFN/DB_IFN/rdsRasterized/tabplot.sd.8km.rds")
> | (:var IFNTABTREE . "./__BOX__/IFN/DB_IFN/rds/tabtree.rds") (:hlines
> | . "no") (:colnames . "yes") (:mkdirp . "yes") (:no-expand . "TRUE")
> | (:rownames . "yes") (:session . "*R_MOBILIS*") (:tangle-mode . 292)
> | (:result-type . output) (:result-params "output" "replace")
> | (:rowname-names (COLUMNS "annee" "ipoints_Qdiv" "iespece" "scenario"
> | "climat" "RUsolinit" "PByC" "PNyC" "NPPyC" "ETRy" "age_peup" "RVy"
> | "DBBVy" "RMTVy" "RMBRy" "Rtoty" "levelstress_2" "Ta" "PRI" "LMAX"
> | "RVCy" "RVMy" "DBSSy" "DBRFy" "LambX" "LambY" "Altitude" "coupebb"
> | "bbois") (COLS_TO_EVAL 1 2 3 4 5) (ALLSPECIES 1 2 3 4 5 6 7 8 9 10
> | 11 12) (SPECIES "fagus" "quercus") (YEARS 1 2)) (:colname-names
> | (COLUMNS "" "name" "description") (COLS_TO_EVAL "" "name" "usable")
> | (ALLSPECIES "" "fullName" "iespece" "IFNName" "color") (SPECIES ""
> | "fullName" "shortName" "iespece" "IFNName" "color") (YEARS ""
> | "year"))))
> |   org-babel-execute-src-block(nil)
> |   org-babel-execute-buffer(nil)
> |   org-babel-execute-subtree(nil)
> |   call-interactively(org-babel-execute-subtree nil nil)
> `----
>
> Cheers,
>
> Rainer
>
>>
>> Best,
>>
p>>>
>>> Thanks,
>>>
>>> Rainer
>>>
>>>>
>>>> Thanks,

-- 
Eric Schulte
https://cs.unm.edu/~eschulte
PGP: 0x614CA05D

Re: [BABEL] BUG Re: Omitting try/catch blocks from tangled R code?

[Rainer M Krug]

[-- Attachment #1: Type: application/pgp-encrypted, Size: 11 bytes --]

[-- Attachment #2: Type: application/octet-stream, Size: 6556 bytes --]

-----BEGIN PGP MESSAGE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)

hQEMA25suqefOpI3AQf+OJYsSx8O1Ju7WIrg+MDTSEJ3Jy3JQ2DP/KJuC2EaD2qO
ZeHnLQque6lqYXbpyTghr8bEWHEiaiMuJWEBIwAhByhUSi9Dr8K/O0X2gMhhAUkZ
moYpDJbgc+rE534ExS97bEZy1uq0oLpWPxZE3i+FMFMlfk4pBohvkHHEc4CFwTqG
7WHMKLCDJSB5tESqj9/IwM4YhIviP1DSw3smkPcIndBqGUpo1MD3jzqMhYU9o6sk
rYzpiki/xAa7G2v4WMqxJqorlOzteIChnd4bisI3ehP+SKq/1WS4RS2hDsbNCz7/
yUA0sqD4TAT7u9PbV2VubZkvi6i61md4aVz589nNANLsAQnMq7DOEQ+SXsJNr0PX
a3YXCbMGOhkBNrAwEJsJkQYRBs33atlsS4GO3vq7o/sRBEUDzbO/K+738sHchpw1
Nnaeq1pACVkeO/d6Yhlr3mE1CW94M25O7uCUJWbbLBSs9/QgzdO9egNqWkGI68QI
kuHvwFY1qufpltn+yFCmpng9z/KIvuZdLtxIsSwVFiMHejA3QbhzJ0zv6W95Qu1d
EYWAc4SzT+6/70O1xTKi9UQJ/cnUEyRKFdFooSkZJHH3PCtRAzuVpP/9Sa4PJ50m
hh51IsMC+Bg0NfqdhpBfS4784wVPaZhUOHtsY5zR6g1dmAFT7qSEzqSAExfc3u5W
/xmYL0upjcBsvoaGVzTf3hWTZoS4I4dnIG8/41nuLyprA4TshZqi1zaUIyvKhskG
yoavz6nocNVMNgNUeZi7M4ZogCF/3LjGKzgWbdynpABjlJCqZuK6VUSfGWwf6KDC
ybOLp9nyeYWp8qta8WgKMUHOdRQMNjU0LV0ciUZWU2sYw0WdxkxVrI5DE4XjuPqK
iSQtrcm3BQq3r3AYqZGZ9Z9Bro6BZri2q4OZ0WD+ZTuuRz+xPDxqX7gWN03rTE9g
dr6fPQRdEMJ/W+FGB8nnRk4HqpDHm/BPjqvj/fNqZX4ZuO3Jyxz5a3I8hp28dgov
gWKtbzaYygTnYlCeG1D5gffICdvIRi6aWhDcqc2UCF7RF+bLpEkaCRW3w1rpLFlU
jYABCiOHp3IuZJtFrKWOdI4yg3JfrKnGjIzMl9+JKW3W7RxjNgtw6tPTh00ztMId
rBv9k+eGuP0GyWV/Aiav+LAN4O5zfAfqnADC4g3kEXnjiYhH20d+iD31yfOYnBf7
l7SXMDjureMryR4VTzFhYHunQ1YM9hic0j+F/0kgKuQvg3AS9W/s7Heda9J/g9Sq
DKDtVMDFKA6VEfaTx/KLoNAyibSx9wnA/KstoNiiSU47rK4NmATQ8k9+hxBSL9+T
MsLGNuckMaVEbic5Xy7j8vPmz+u/qVi78ESzc7TUgszpCP7mPiPjmUTXLp2Yb96a
JdmmlJE9VmW50mMc/7qp2fj6lGZu1C+cjMTJ8EUc5s0pA8q/6MNLk0OHQ546xEuc
R34rC/gA8IDksMnY/RwzmMyBb8MvQQ+Ui1G1gL8CGHCoOIczV9JYbuD1EBnBOPXU
yiQp92B0QiWzcX5t1KcnwkFikT9fR7KNqY3jYU2eCFfPUeKkBttNHQ759UrNdbTq
/Io8UMczs524TzM+/sCGjTez69uVvx1USjqSKZkrK8wiuLy1baHFiKesIQoTeXGm
iiv+Et0t/w/91g/CjDlTM2Q1WVk7JgRWfS/WYsHfu37YfobawiN84NRlQgodqYU6
yQ41SLU0OGLzlEfPeOeNeCANSW1inj9NqU5eR6uwUB86mLeCPVxm8TIue8/dvmF3
tTihFNqmhxSDXGuml0vEBLeHoPqRzX1oUgYOoikLv2tVaprZmbMFhwpkTFCLqNkn
iFdRwR/I5mX7jAupHmYhwTF5qcyaBKSY506dGAfpAJoQOSxsHJ2ksX8gFlBornvb
kf1c4ntGpW3YvV64874AXGwVljCWp0CNipx1+DrWFgr40I1p0lSCzNQew4CiDyex
AMgC5aIC+qKkGNpsTSBM5y/wGBA0e9tlzo3HrlwsgQ5M50HQIuueTaaFXZdNMyya
Xecy8UIyOauIa/Mmh8YQw4lnNn69Q5pdwxDCuvSMUQNZD2zvNHgHATIm6F2+/UQ+
v5PpQzi85iYsADxtFX9VyUiQ4Ct3eqgeuxupPNFOecXu5CSuLUGL2352lvbpNAWo
WqhceZtv8BKO9EmXoEjpXe1pF3SSoOlOXv77q3wKJ1+XOGNyt7oOCLt5fAOtHSvU
E5QmN3k2RTzzCcxbiOzq1SoK3uyfLlq2nLR7IW2o2hESTTt0x9IBkpl3ds7yCl0l
tRe1ogC3OssHmt+UEycLV601EZpE5Z95nJVUXjHdITbwBEkrwlqn7/FJUo4fJJIR
MunKALw6aicTrZGnyj1mABlnbEqMUXVCuZ5ZocGJtqEksBQ/bJ/6oTzHlRL8Tc/9
GS7cyMCq6Doh8hUezHVYO2my0Fd2Hn5crdNpbPA+WqtUWWiJUbPFe1WtF1AuXG8W
CveKvgr8Y8D6so0IDGCtwo810md/et3cnCobjDYmGE6/p+SV4cNnZgrwUhhRI2Fd
zf+Mqh6qELzX3aazz+ap46adm7ZAWOZcKoxAio9SLZPc0q4FYAQJp3hZWhRhuqAt
SD+KeFD7scy+hfoY330eDcAmnHqDa7sdUGCQZdjMLyNwYxeZExH6TL7wRpL4/HAY
QF2Zq4X5n2R6aoAqN4gxtLfoXZrnceQRHk5hq2WxKbZ+eV5gyDJCXL2tPsd0yhFT
q+cbeAioE0MhmEaq9LllmmkE0SXxdHiRKZ5hvHJJJIXI+f2iRRYgarWn37twQFyV
6hqd4j5y2ZpGwxa0Ken+UZ0ip+uAkxwKcqu6mZ/LImAnuFRi001+g8zWqWqllg3b
00S7JMD3P4b4ZuJtWi3UBVzdJ/L63jFiBVo60Z18v4H/xbHI4VZjadT1xVCJu+UK
vkgPSpp6Rvyq65qRVd/zZu2nuBx5zfaKh/LgzRmffnSoiMm0rUFQKU21zJvm32xO
zJnmWus8TQ5G3a5MFc5Dquaq2jPL7OUOtpXkkFp5qhsZDjRkxuIZqgXnUX6KE7g8
jEDGvPEAJvs0vi5c09IorrUz8Enb3Yf7sn/BPEIbsToFWeJzfUlT0OVuD9pnliO6
N/ZRuXUEpiUT7n+ySjynAoV2LJeATAGXcD69BEeFx+ab+e2beIeO/jy+G+WaTRef
H1xa+oVjepsGgkMz78ktzvJi2MCtk7lK59+qbmW0hIx4sokhcHfCcTcS72qSIiDx
GB/Ftv+AB1GRXbvIavKNAUZWVQyO1QcdPN+z8ALLPCPxBQX4f06yC+mP67X/J+Pp
rKTVU3ph7myf93bQ3tB2eqfqKoKDGqKed6QXS0vW26iqrCUrXw7KkB+jg4dxc5KJ
9YVeUleimy7MtLytOMHFXMfkcuoi0kZ6i5qyfIbkhBl5/SYhRIVSvRLkc1wkODfU
9sYOL6qCE130FtmwaBJ0nT5fin6V/DptZNCGAA6Zeq65MS354Dc/IaqeIbc0c/Yv
MUlcd2RJPXDcLs92W5cFHBZdr80vcg68oQE18mJU19UMM53RJwOUandgdncZJjV/
IFtd+mz3VyDFu24DuyuuWYOmI/ELmWJL3Ul+TawH11ixcQsQOMM0fGrEkkVtsJk2
ukqqjkhUA2ZXlj2crUfcGSWDN1o65PDmYqAiXYLzq3TF6/fRT8z2okbq9fJo38GW
ASwRKcBVyV1LS+f8u1YDTS9f6O1oBdrM3kFRBTs/jbelEYnQaiqg1LQInsjHmIn8
Ek7ltjqa27DN4m81YzPpcGfHd6pL9KNr/1Dclq+2HUDKMubwWThIOMGHEtdA2nM1
z9wDc2kc5FSlOPmNyd/rVC9I3Qvr2PFw5cPQRDg6aRtqIdVjTrmiFH4OUEU8WF48
TQJLZi3QVIENPO9ADur3BuYqJ/Plwpv2PkvGEWfA+h511oHIcppxbQ5IYIbSvLVJ
cHclhH4lxi4LZMHF7UzXWsc0bvVczlCd8xyco0qxF/H3C6VMJ6zDL082eg/nuTTg
dUk0rhqo7KdbI0N2IBD8Qp+syxCk73NOi2bsuRjKWrLUcfIS88SORfDfMq2ywn5c
poI/OlcD0P7oVURGzSGqsicIy0n9JFaFZcgz0Jvlq6GZ687SH13s7ZEN+E+OJINZ
UhDhO+lop08dVg9V30J9px/aTWzLtPc/w4JGn1fU89xJnfQb51yFdW19oUZmKsu8
IsrLfQeaOahiud3Zffdo3JuVd1P/efLHEnNx5s8JECzsUtT+h5lO09ezCunXuQ5B
GN6Kz9RpQAJZax/csxsphr+DTSdD4X1Nbpd6LZkTg7mJOkeelyNt2OjuYOuu00oh
4fK6xU4OA9jkA5oK681U3UQpzC3zwBiBNFcpf7Fuk8v/oT6OGwm2yzjpjfikGsI2
HBgaViRrRdPuHSj1bpgZnszlctpvkxA59E2gRvp/5O7E1QVhOgj8NKvwslWceNRA
nPHnudJFgSYS7Ovcgaw4hu6Waqpj/oxw2m6U6eaU3vKEZNsEo8VMyYMsyp6vS1M9
VQF/3pIz2T6r3FZC1ZfDMNAwWD5uFPulOPXhOK/vx5xp3As+0AGHss6xRke+2Agq
5L08s+5Us9Bv6nwejIlNjsDGiRcXFXZTfWZVS0ekeYiHmaRMWYWkBogp7DeiQm6D
k6XuVdvG3qFVSS5mu6SPlnHZuHbzP7JY4r/0A9aNTTevW+eeDUilPPu5C7oZdOeP
5i9BMPJSxNrRHU56xxHa7Ky5WrDarUMRknq76wSpOZtizfBRaYbD6sKA3wh9z9c0
wNDBQlMqeoqdlzPwY/GfYS1+dGaniBd5Xe0HXIvFM9Ef/5FCa5Kv3h2J0TqudaKb
HuD4hTdCh3StCc2ejArqPhr+SMbEosiUsNwgub/ydOMmdHJ3Tu+Q8UGuQoILv0TE
HcC4T7Z5PnI7WGqJHFbiROb1rSeg03GYoH3I5Ykbt9flV7sKUO9za73lH9etOuWJ
BUwzFpHRMZUSdIwnxm65SvDGrtdRwCFszt/iDTqoJwPbjYD63yL1mdftCSenOjK0
evfnKgojIqhb4jxGzkFuuwMPz4n1cRR+RThGQeI+PqoHVYqVGrWNK1ONMgagsO9l
Msbtta7cmjojWjZ0JEl4y0HFmODv++N9r7Va4W7SeyNRG+rcadVfwsAYnFntm4TZ
IGDvaUrnl1FvI7e3gHb37JJ3TGO5an6gQWY4AJpJ3wr8it9xPYnh/bneK9knEs4V
NepAwKBA2H5YdfLQPUTH8TXR7oAGUvTB4sD0CEEQZtAej8uv52N5JL3Wm8YtrXKE
Ay9Dv5exJm7CiLiAp/P2I71P8dVa/CVX2zojAWuqET3n2JGaewONWPW5senNaKie
qU2H7VmpiZi6OTRM16qnEkN35ST5NLpU2xGFgqrfQjGT5IAcLWbQGbgsf61dp6IW
TogSpsNeU4hokcDE/cs2Zu0DLxcUPqEG96Z4XrRXxGYw0PP2Z8eHmNAgOhEx6oze
SHlsFMbO1B8709PGVcCS9m7dVfQnYfxHG4DWwWzwOECliEq4SPKed5CC+Nt8yU/g
/nF/bit3aKAL/f36C2zfifbjUemCed52TYxgZ4cAE+fC8z63d4uf6ERx7S7k4V7q
750GQ16CkT3bCstX5JfkoRoLUFnaiPBN26vh8gI1B4TqvvJKiFVP+jiaietradaM
ew0WsDOwXPzG7pYiEihBXf5nEZ4C3cjCZxV2Nlp/LDTk6/R1VH3dBp3P5j9BdHhm
kSJfeB0if7aKVF1Ee/3REwy2lCU785CUiTzX+lL0MyTt7XIve29tPvnl1xwC6Irg
nsDMNln+3WuqjOMltJrOK4Eg3B7AZiD39zYc5pdfTLuoRDLa8G6CKz7t5/qDiLGD
eR3nsighrduDCieOkmO0yQkMeIULqqDqMkeiPQw5KmrRN4a2SN8DX2005QQrVLt1
qU0lGCwXtmIEaTHYHIhB1+RMvnybW0AqEMNERTJ8jBCQ2dT0pXoTlHlpo0uCfIeG
Fo8qa7Mb5whA+1/vQxwonOOtYew/5YZFWLtOV4JrIk3bF3V+6fFmXAY/Ulau59Ut
rjC2CwVOd3IHxos5fnsCPxJfMjB8eSeXOkRF1tkKyh8VHockk+HcyOJKwsmTqpAg
uKRB05AbxsyvxZFGN8yS4+1UoFrNC857IJcxekdY5ZMEfN+wFCWc/deYMk8AB9te
HvOhiuDsOycCOqO1nykLaNeHhvUQtPKOFLBQ4GTKijSE8XJYFhaj6G8LcUIH6DO6
frJaIbuKsYFN0RRig3v1NxU21KGBzL8QYw1607A7m0L5XY2TLXsUL25MPpNLuM8k
MpmfZnQfv9RqNDgjNT3A
=2F+T
-----END PGP MESSAGE-----

Re: [BABEL] BUG Re: Omitting try/catch blocks from tangled R code?

[Rainer M Krug]

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

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

> Rainer M Krug <Rainer@krugs.de> writes:
>
>> Eric Schulte <schulte.eric@gmail.com> writes:
>>
>>> Rainer M Krug <Rainer@krugs.de> writes:
>>>
>>>> Eric Schulte <schulte.eric@gmail.com> writes:
>>>>
>>>>> Rainer M Krug <Rainer@krugs.de> writes:
>>>>>
>>>>>> Eric Schulte <schulte.eric@gmail.com> writes:
>>>>>>
>>>>>>> Charles Berry <ccberry@ucsd.edu> writes:
>>>>>>>
>>>>>>>> John Hendy <jw.hendy <at> gmail.com> writes:
>>>>>>>>
>>>>>>>> [deleted]
>>>>>>>>> >
>>>>>>>>> > I think the default behavior should be reverted, as tangling and
>>>>>>>>> > exporting are two different things. When I tangle, I want to see the
>>>>>>>>> > code blocks as they are in the org document (with possible variables and
>>>>>>>>> > expansions) but not to create files where I do not put it explicitly
>>>>>>>>> > into a code block. These wrappers have nothing to do with the code, and
>>>>>>>>> > are only there for the exported engine. So I would either revert to the
>>>>>>>>> > original behavior, or, introduce a new header argument,
>>>>>>>>> > e.g. :include-wrappers, which would, if set to t, include the export
>>>>>>>>> > wrappers in the tangled file. This might be useful for debugging
>>>>>>>>> > exporting of code block results, but not for general tangling.
>>>>>>>>> 
>>>>>>>>> Thanks for chiming in. This was my gut reaction to the default
>>>>>>>>> behavior. I guess we're still only a sample size of 2, but
>>>>>>>>> intuitively, I would think that tangling would be a separate beast in
>>>>>>>>> most cases from exporting. Just to have it on the record, if I tangle,
>>>>>>>>> it's usually to take the code I've used in something like a Beamer
>>>>>>>>> presentation or document and combine it into a single .R file so
>>>>>>>>> someone can run it without needing Org-mode.
>>>>>>>>
>>>>>>>> [deleted]
>>>>>>>>
>>>>>>>> Sorry to be late to add my $0.02...
>>>>>>>>
>>>>>>>> I never want the try/catch wrappers.
>>>>>>>>
>>>>>>>> But noweb is indispensable.
>>>>>>>>
>>>>>>>> I use noweb a lot to organize and collect blocks. In some cases, I export
>>>>>>>> them and in others I just tangle them.
>>>>>>>>
>>>>>>>> I hope that the revised code will allow me to turn off try/catch wrapping
>>>>>>>> and still be able to use noweb when tangling or exporting.
>>>>>>>>
>>>>>>>
>>>>>>> In addition to noweb, there are cases where variable expansion is useful
>>>>>>> in tangled code.
>>>>>>>
>>>>>>> The simplest option is to move things like try/catch blocks out of the
>>>>>>> code block expansion function, and into the execution function.  Then if
>>>>>>> other language present similar constructs (which we want to add to
>>>>>>> execution by default but never want to tangle), we can think about
>>>>>>> abstracting this out into some new level of code block expansion.
>>>>>>>
>>>>>>> Thoughts?
>>>>>>
>>>>>> Makes perfect sense to me, and would definitely be the better place to
>>>>>> add them.
>>>>>>
>>>>>> If one wants enclosing code in the tangling, there is always
>>>>>> the :epilogue and :prologue header arguments, and the try/catch should
>>>>>> be considered as internal to the execution.
>>>>>>
>>>>>
>>>>> Great, how's this patch work?  If it looks good I'll apply it.
>>>>
>>>> Git still puzzles me a lot... If you tell me how I can apply this patch
>>>> (from emacs?) I will try it out.
>>>>
>>>
>>> Here are some instructions from the command line.
>>>
>>> 1. write the patch out to a file on disk, say /tmp/0001-etc...patch
>>>
>>> 2. cd into the org-mode directory
>>>
>>> 3. make sure you're up to date with the latest
>>>
>>>      git pull
>>>
>>> 4. apply the patch
>>>
>>>      git am /tmp/0001-etc...patch
>>>
>>> and that should do it.
>>
>> OK - managed to apply the patch.
>>
>> Using 
>>
>> Org-mode version 8.2.5h (release_8.2.5h-846-geb806d @ /Users/rainerkrug/.emacs.d/org-mode/lisp/)
>>
>> updated this morning, I get the following error:
>>
>
> Could you provide a minimal example file generating this error?

Apologies - I am still struggling with encryption......

So here is my example:

--8<---------------cut here---------------start------------->8---
#+TITLE: single_to_multi
#+DATE: <2013-10-15 Tue>
#+AUTHOR: Rainer M. Krug
#+EMAIL: Rainer@krugs.de

≈* Load R packages and data
#+BEGIN_SRC R
cat("Loading Data\n")
#+END_SRC
--8<---------------cut here---------------end--------------->8---

I am using only org loaded and R enabled.

C-c C-c on the block produces the error

emacs version: 
GNU Emacs 24.3.1 (x86_64-apple-darwin13.0.0, Carbon Version 1.6.0
AppKit 1265) of 2014-02-13 on Rainers-MacBook-Pro-2.local

org version:
Org-mode version 8.2.5h (release_8.2.5h-837-gb296cc @
/Users/rainerkrug/.emacs.d/org-mode/lisp/)

Cheers,

Rainer

>
> Thanks,
>
>>
>> ,----
>> | Debugger entered--Lisp error: (wrong-type-argument sequencep 67)
>> |   mapconcat(identity "COLUMNS <-
>> | read.table(\"/var/folders/50/wcr5bjwn75q595n6x82gxj280000gn/T/babel-21363l1U/R-import-21363S9b\",\n
>> | header=TRUE,\n row.names=1,\n sep=\"\\t\",\n
>> | as.is=TRUE)\nCOLS_TO_EVAL <-
>> | read.table(\"/var/folders/50/wcr5bjwn75q595n6x82gxj280000gn/T/babel-21363l1U/R-import-21363fHi\",\n
>> | header=TRUE,\n row.names=1,\n sep=\"\\t\",\n as.is=TRUE)\nALLSPECIES
>> | <-
>> | read.table(\"/var/folders/50/wcr5bjwn75q595n6x82gxj280000gn/T/babel-21363l1U/R-import-21363sRo\",\n
>> | header=TRUE,\n row.names=1,\n sep=\"\\t\",\n as.is=TRUE)\nSPECIES <-
>> | read.table(\"/var/folders/50/wcr5bjwn75q595n6x82gxj280000gn/T/babel-21363l1U/R-import-213635bu\",\n
>> | header=TRUE,\n row.names=1,\n sep=\"\\t\",\n as.is=TRUE)\nYEARS <-
>> | read.table(\"/var/folders/50/wcr5bjwn75q595n6x82gxj280000gn/T/babel-21363l1U/R-import-21363Gm0\",\n
>> | header=TRUE,\n row.names=1,\n sep=\"\\t\",\n as.is=TRUE)\nPRESENT <-
>> | 2008\nMINEFFORT <- 3\nPROPTRAIN <- 0.6\nRNGSEED <- 13\nRNGKIND <-
>> | \"Mersenne-Twister\"\nRNGNORMALKIND <- \"Inversion\"\nREFGRID <-
>> | \"./refGrid_8km.rds\"\nIFN <-
>> | \"./__BOX__/IFN/DB_IFN/rds/tabplot.rds\"\nIFNCOUNT <-
>> | \"./__BOX__/IFN/DB_IFN/rdsRasterized/tabplot.count.8km.rds\"\nIFNMEAN
>> | <-
>> | \"./__BOX__/IFN/DB_IFN/rdsRasterized/tabplot.mean.8km.rds\"\nIFNPRES
>> | <-
>> | \"./__BOX__/IFN/DB_IFN/rdsRasterized/tabplot.pres.8km.rds\"\nIFNSD
>> | <-
>> | \"./__BOX__/IFN/DB_IFN/rdsRasterized/tabplot.sd.8km.rds\"\nIFNTABTREE
>> | <- \"./__BOX__/IFN/DB_IFN/rds/tabtree.rds\"\ndata.sources <-
>> | list.files(\"./data\", pattern=\"*.rda$\",
>> | full.names=TRUE)\nR.sources <- list.files(\"./R\", pattern=\"*.R$\",
>> | full.names=TRUE)\ncat(\"Loading Data\\n\")\nas.vector( sapply(
>> | data.sources, load) )\ncat(\"\\nSourcing R files\\n\")\nsapply(
>> | R.sources, source)" "\n")
>> |   org-babel-execute:R("data.sources <- list.files(\"./data\",
>> | pattern=\"*.rda$\", full.names=TRUE)\nR.sources <-
>> | list.files(\"./R\", pattern=\"*.R$\",
>> | full.names=TRUE)\ncat(\"Loading Data\\n\")\nas.vector( sapply(
>> | data.sources, load) )\ncat(\"\\nSourcing R files\\n\")\nsapply(
>> | R.sources, source)" ((:comments . "link") (:shebang . "") (:cache
>> | . "no") (:padline . "yes") (:noweb . "no") (:tangle . "yes")
>> | (:exports . "both") (:results . "replace output") (:var COLUMNS
>> | ("annee" "Year of simulation") ("ipoints_Qdiv" "Point Number (also
>> | refer to number of the climatic input file)") ("iespece" "species
>> | number (4==>Beech; 3:Oak)") ("scenario" "Type of forest management
>> | (no matter)") ("climat" "Type of climate (no matter)") ("RUsolinit"
>> | "Soil water Holding Capacity of the point (mm)") ("PByC" "gross
>> | photosynthesis (yearly, gC/m²/year)") ("PNyC" "Net photosynthesis,
>> | (PByC - leaf Respiration) (gC/m²/year)") ("NPPyC" "Net primary
>> | productivity, (gC/m²/year)") ("ETRy" "Evapotranspiration of stand
>> | (mm/year)") ("age_peup" "Age at the end of the revolution") ("RVy"
>> | "total respiration of living tissue") ("DBBVy" "aboveground annualm
>> | growth (gC/m²/year)") ("RMTVy" "maintenance respiration of stems
>> | (gC/m²/year)") ("RMBRy" "maintenance respiration of branches
>> | (gC/m²/year)") ("Rtoty" "total heterotrophic respiration
>> | (gC/m²/year) (SOIL)") ("levelstress_2" "indices of water stress
>> | based on stomatal conductance") ("Ta" "Annual Temperature (°C) (do
>> | not use problem)") ("PRI" "Rain (mm) (do not use problem)") ("LMAX"
>> | "Leaf Area Index") ("RVCy" "Growth respiration of living tissue")
>> | ("RVMy" "Maintenance respiration of all living tissue") ("DBSSy"
>> | "annual storage growth (gc/m²/year)") ("DBRFy" "annual fine roots
>> | growth (gC/m²/year)") ("LambX" "X co,ordinates in Lamberts Zone II
>> | (EPSG 27572)") ("LambY" "Y co,ordinates in Lamberts Zone II (EPSG
>> | 27572)") ("Altitude" "Elevation(m)") ("coupebb" "exported biomass
>> | through cutting (gC/m²)") ("bbois" "wood biomass of the stand
>> | (gC/m²)")) (:var COLS_TO_EVAL ("NPPyC" "FALSE") ("DBBVy" "TRUE")
>> | ("DBRFy" "FALSE") ("DBSSy" "FALSE") ("levelstress_2" "TRUE")) (:var
>> | ALLSPECIES ("Quercus robur" 1 "quercus_robur" "") ("Quercus peatrea"
>> | 2 "quercus_peatrea" "") ("Quercus pubescens" 3 "quercus_pubescens"
>> | "") ("Fagus sylvatica" 4 "fagus_sylvatica" "") ("Carpinus betulus" 5
>> | "carpinus_betulus" "") ("Other broadleaf species" 6
>> | "other_broadleaf_species" "") ("Picae abies" 7 "picae_abies" "")
>> | ("Abies alba" 8 "abies_alba" "") ("Pinus maritima" 9
>> | "pinus_maritima" "") ("Pinus sylvestris" 10 "pinus_sylvestris" "")
>> | ("pseudotsuga meniezi" 11 "pseudotsuga_meniezi" "") ("Other
>> | coniferous species" 12 "other_coniferous_species" "")) (:var SPECIES
>> | ("Fagus sylvatica" "fagus" 4 "fagus_sylvatica" "red") ("Quercus
>> | robur" "quercus" 3 "quercus_robur" "green")) (:var YEARS (1990)
>> | (2000)) (:var PRESENT . 2008) (:var MINEFFORT . 3) (:var PROPTRAIN
>> | . 0.6) (:var RNGSEED . 13) (:var RNGKIND . "Mersenne-Twister") (:var
>> | RNGNORMALKIND . "Inversion") (:var REFGRID . "./refGrid_8km.rds")
>> | (:var IFN . "./__BOX__/IFN/DB_IFN/rds/tabplot.rds") (:var IFNCOUNT
>> | . "./__BOX__/IFN/DB_IFN/rdsRasterized/tabplot.count.8km.rds") (:var
>> | IFNMEAN . "./__BOX__/IFN/DB_IFN/rdsRasterized/tabplot.mean.8km.rds")
>> | (:var IFNPRES
>> | . "./__BOX__/IFN/DB_IFN/rdsRasterized/tabplot.pres.8km.rds") (:var
>> | IFNSD . "./__BOX__/IFN/DB_IFN/rdsRasterized/tabplot.sd.8km.rds")
>> | (:var IFNTABTREE . "./__BOX__/IFN/DB_IFN/rds/tabtree.rds") (:hlines
>> | . "no") (:colnames . "yes") (:mkdirp . "yes") (:no-expand . "TRUE")
>> | (:rownames . "yes") (:session . "*R_MOBILIS*") (:tangle-mode . 292)
>> | (:result-type . output) (:result-params "output" "replace")
>> | (:rowname-names (COLUMNS "annee" "ipoints_Qdiv" "iespece" "scenario"
>> | "climat" "RUsolinit" "PByC" "PNyC" "NPPyC" "ETRy" "age_peup" "RVy"
>> | "DBBVy" "RMTVy" "RMBRy" "Rtoty" "levelstress_2" "Ta" "PRI" "LMAX"
>> | "RVCy" "RVMy" "DBSSy" "DBRFy" "LambX" "LambY" "Altitude" "coupebb"
>> | "bbois") (COLS_TO_EVAL 1 2 3 4 5) (ALLSPECIES 1 2 3 4 5 6 7 8 9 10
>> | 11 12) (SPECIES "fagus" "quercus") (YEARS 1 2)) (:colname-names
>> | (COLUMNS "" "name" "description") (COLS_TO_EVAL "" "name" "usable")
>> | (ALLSPECIES "" "fullName" "iespece" "IFNName" "color") (SPECIES ""
>> | "fullName" "shortName" "iespece" "IFNName" "color") (YEARS ""
>> | "year"))))
>> |   org-babel-execute-src-block(nil)
>> |   org-babel-execute-buffer(nil)
>> |   org-babel-execute-subtree(nil)
>> |   call-interactively(org-babel-execute-subtree nil nil)
>> `----
>>
>> Cheers,
>>
>> Rainer
>>
>>>
>>> Best,
>>>
> p>>>
>>>> Thanks,
>>>>
>>>> Rainer
>>>>
>>>>>
>>>>> Thanks,

-- 
Rainer M. Krug
email: Rainer<at>krugs<dot>de
PGP: 0x0F52F982

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 4474 bytes --]

Re: [BABEL] BUG Re: Omitting try/catch blocks from tangled R code?

[Eric Schulte]

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

>
> Apologies - I am still struggling with encryption......
>
> So here is my example:
>
> --8<---------------cut here---------------start------------->8---
> #+TITLE: single_to_multi
> #+DATE: <2013-10-15 Tue>
> #+AUTHOR: Rainer M. Krug
> #+EMAIL: Rainer@krugs.de
>
> ≈* Load R packages and data
> #+BEGIN_SRC R
> cat("Loading Data\n")
> #+END_SRC
> --8<---------------cut here---------------end--------------->8---
>
> I am using only org loaded and R enabled.
>
> C-c C-c on the block produces the error
>
> emacs version: 
> GNU Emacs 24.3.1 (x86_64-apple-darwin13.0.0, Carbon Version 1.6.0
> AppKit 1265) of 2014-02-13 on Rainers-MacBook-Pro-2.local
>
> org version:
> Org-mode version 8.2.5h (release_8.2.5h-837-gb296cc @
> /Users/rainerkrug/.emacs.d/org-mode/lisp/)
>

Thanks, a fixed version of the patch is attached.  If this works please
let me know and I'll apply.

Best,


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-only-wrap-R-code-graphics-file-on-execution.patch --]
[-- Type: text/x-diff, Size: 2788 bytes --]

From d67248db79faf19e1bdcac0230c37670b6115bdd Mon Sep 17 00:00:00 2001
From: Eric Schulte <schulte.eric@gmail.com>
Date: Sun, 23 Mar 2014 20:01:37 -0600
Subject: [PATCH] only wrap R code graphics-file on execution

  Move this out of the expand-body function so that it is *never*
  applied to tangled code.
---
 lisp/ob-R.el | 40 +++++++++++++++++++++-------------------
 1 file changed, 21 insertions(+), 19 deletions(-)

diff --git a/lisp/ob-R.el b/lisp/ob-R.el
index 62aa7f2..780d99f 100644
--- a/lisp/ob-R.el
+++ b/lisp/ob-R.el
@@ -97,24 +97,15 @@ this variable.")
   "Expand BODY according to PARAMS, return the expanded body."
   (let ((graphics-file
 	 (or graphics-file (org-babel-R-graphical-output-file params))))
-    (mapconcat
-     #'identity
-     (let ((inside
-            (append
-             (when (cdr (assoc :prologue params))
-               (list (cdr (assoc :prologue params))))
-             (org-babel-variable-assignments:R params)
-             (list body)
-             (when (cdr (assoc :epilogue params))
-               (list (cdr (assoc :epilogue params)))))))
-       (if graphics-file
-           (append
-            (list (org-babel-R-construct-graphics-device-call
-                   graphics-file params))
-            inside
-            (list "},error=function(e){plot(x=-1:1, y=-1:1, type='n', xlab='', ylab='', axes=FALSE); text(x=0, y=0, labels=e$message, col='red'); paste('ERROR', e$message, sep=' : ')}); dev.off()"))
-         inside))
-     "\n")))
+    (mapconcat #'identity
+	       (append
+		(when (cdr (assoc :prologue params))
+		  (list (cdr (assoc :prologue params))))
+		(org-babel-variable-assignments:R params)
+		(list body)
+		(when (cdr (assoc :epilogue params))
+		  (list (cdr (assoc :epilogue params)))))
+	       "\n")))
 
 (defun org-babel-execute:R (body params)
   "Execute a block of R code.
@@ -127,7 +118,18 @@ This function is called by `org-babel-execute-src-block'."
 	   (colnames-p (cdr (assoc :colnames params)))
 	   (rownames-p (cdr (assoc :rownames params)))
 	   (graphics-file (org-babel-R-graphical-output-file params))
-	   (full-body (org-babel-expand-body:R body params graphics-file))
+	   (full-body
+	    (let ((inside
+		   (list (org-babel-expand-body:R body params graphics-file))))
+	      (mapconcat #'identity
+			 (if graphics-file
+			     (append
+			      (list (org-babel-R-construct-graphics-device-call
+				     graphics-file params))
+			      inside
+			      (list "},error=function(e){plot(x=-1:1, y=-1:1, type='n', xlab='', ylab='', axes=FALSE); text(x=0, y=0, labels=e$message, col='red'); paste('ERROR', e$message, sep=' : ')}); dev.off()"))
+			   inside)
+			 "\n")))
 	   (result
 	    (org-babel-R-evaluate
 	     session full-body result-type result-params
-- 
1.9.1


[-- Attachment #3: Type: text/plain, Size: 63 bytes --]


-- 
Eric Schulte
https://cs.unm.edu/~eschulte
PGP: 0x614CA05D

Re: [BABEL] BUG Re: Omitting try/catch blocks from tangled R code?

[Rainer M Krug]

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

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

>>
>> Apologies - I am still struggling with encryption......
>>
>> So here is my example:
>>
>> --8<---------------cut here---------------start------------->8---
>> #+TITLE: single_to_multi
>> #+DATE: <2013-10-15 Tue>
>> #+AUTHOR: Rainer M. Krug
>> #+EMAIL: Rainer@krugs.de
>>
>> ≈* Load R packages and data
>> #+BEGIN_SRC R
>> cat("Loading Data\n")
>> #+END_SRC
>> --8<---------------cut here---------------end--------------->8---
>>
>> I am using only org loaded and R enabled.
>>
>> C-c C-c on the block produces the error
>>
>> emacs version: 
>> GNU Emacs 24.3.1 (x86_64-apple-darwin13.0.0, Carbon Version 1.6.0
>> AppKit 1265) of 2014-02-13 on Rainers-MacBook-Pro-2.local
>>
>> org version:
>> Org-mode version 8.2.5h (release_8.2.5h-837-gb296cc @
>> /Users/rainerkrug/.emacs.d/org-mode/lisp/)
>>
>
> Thanks, a fixed version of the patch is attached.  If this works please
> let me know and I'll apply.

Still the same error:

,----
| Debugger entered--Lisp error: (wrong-type-argument sequencep 99)
|   Mapconcat(identity "cat(\"YEAR\")" "\n")
|   Org-babel-execute:R("cat(\"YEAR\")" ((:comments . "") (:shebang . "") (:cache . "no") (:padline . "") (:noweb . "no") (:tangle . "no") (:exports . "code") (:results . "replace output") (:session . "none") (:hlines . "no") (:result-type . output) (:result-params "output" "replace") (:rowname-names) (:colname-names)))
|   org-babel-execute-src-block(nil)
|   org-babel-execute-src-block-maybe()
|   org-babel-execute-maybe()
|   org-babel-execute-safely-maybe()
|   run-hook-with-args-until-success(org-babel-execute-safely-maybe)
|   org-ctrl-c-ctrl-c(nil)
|   call-interactively(org-ctrl-c-ctrl-c nil nil)
`----

Cheers,

Rainer


>
> Best,
>
>
> From d67248db79faf19e1bdcac0230c37670b6115bdd Mon Sep 17 00:00:00 2001
> From: Eric Schulte <schulte.eric@gmail.com>
> Date: Sun, 23 Mar 2014 20:01:37 -0600
> Subject: [PATCH] only wrap R code graphics-file on execution
>
>   Move this out of the expand-body function so that it is *never*
>   applied to tangled code.
> ---
>  lisp/ob-R.el | 40 +++++++++++++++++++++-------------------
>  1 file changed, 21 insertions(+), 19 deletions(-)
>
> diff --git a/lisp/ob-R.el b/lisp/ob-R.el
> index 62aa7f2..780d99f 100644
> --- a/lisp/ob-R.el
> +++ b/lisp/ob-R.el
> @@ -97,24 +97,15 @@ this variable.")
>    "Expand BODY according to PARAMS, return the expanded body."
>    (let ((graphics-file
>  	 (or graphics-file (org-babel-R-graphical-output-file params))))
> -    (mapconcat
> -     #'identity
> -     (let ((inside
> -            (append
> -             (when (cdr (assoc :prologue params))
> -               (list (cdr (assoc :prologue params))))
> -             (org-babel-variable-assignments:R params)
> -             (list body)
> -             (when (cdr (assoc :epilogue params))
> -               (list (cdr (assoc :epilogue params)))))))
> -       (if graphics-file
> -           (append
> -            (list (org-babel-R-construct-graphics-device-call
> -                   graphics-file params))
> -            inside
> -            (list "},error=function(e){plot(x=-1:1, y=-1:1, type='n', xlab='', ylab='', axes=FALSE); text(x=0, y=0, labels=e$message, col='red'); paste('ERROR', e$message, sep=' : ')}); dev.off()"))
> -         inside))
> -     "\n")))
> +    (mapconcat #'identity
> +	       (append
> +		(when (cdr (assoc :prologue params))
> +		  (list (cdr (assoc :prologue params))))
> +		(org-babel-variable-assignments:R params)
> +		(list body)
> +		(when (cdr (assoc :epilogue params))
> +		  (list (cdr (assoc :epilogue params)))))
> +	       "\n")))
>  
>  (defun org-babel-execute:R (body params)
>    "Execute a block of R code.
> @@ -127,7 +118,18 @@ This function is called by `org-babel-execute-src-block'."
>  	   (colnames-p (cdr (assoc :colnames params)))
>  	   (rownames-p (cdr (assoc :rownames params)))
>  	   (graphics-file (org-babel-R-graphical-output-file params))
> -	   (full-body (org-babel-expand-body:R body params graphics-file))
> +	   (full-body
> +	    (let ((inside
> +		   (list (org-babel-expand-body:R body params graphics-file))))
> +	      (mapconcat #'identity
> +			 (if graphics-file
> +			     (append
> +			      (list (org-babel-R-construct-graphics-device-call
> +				     graphics-file params))
> +			      inside
> +			      (list "},error=function(e){plot(x=-1:1, y=-1:1, type='n', xlab='', ylab='', axes=FALSE); text(x=0, y=0, labels=e$message, col='red'); paste('ERROR', e$message, sep=' : ')}); dev.off()"))
> +			   inside)
> +			 "\n")))
>  	   (result
>  	    (org-babel-R-evaluate
>  	     session full-body result-type result-params
> -- 
> 1.9.1

-- 
Rainer M. Krug
email: Rainer<at>krugs<dot>de
PGP: 0x0F52F982

[-- Attachment #2: Type: application/pgp-signature, Size: 494 bytes --]

Re: [BABEL] BUG Re: Omitting try/catch blocks from tangled R code?

[Eric Schulte]

Rainer M Krug <Rainer@krugs.de> writes:

> Eric Schulte <schulte.eric@gmail.com> writes:
>
>>>
>>> Apologies - I am still struggling with encryption......
>>>
>>> So here is my example:
>>>
>>> --8<---------------cut here---------------start------------->8---
>>> #+TITLE: single_to_multi
>>> #+DATE: <2013-10-15 Tue>
>>> #+AUTHOR: Rainer M. Krug
>>> #+EMAIL: Rainer@krugs.de
>>>
>>> ≈* Load R packages and data
>>> #+BEGIN_SRC R
>>> cat("Loading Data\n")
>>> #+END_SRC
>>> --8<---------------cut here---------------end--------------->8---
>>>
>>> I am using only org loaded and R enabled.
>>>
>>> C-c C-c on the block produces the error
>>>
>>> emacs version: 
>>> GNU Emacs 24.3.1 (x86_64-apple-darwin13.0.0, Carbon Version 1.6.0
>>> AppKit 1265) of 2014-02-13 on Rainers-MacBook-Pro-2.local
>>>
>>> org version:
>>> Org-mode version 8.2.5h (release_8.2.5h-837-gb296cc @
>>> /Users/rainerkrug/.emacs.d/org-mode/lisp/)
>>>
>>
>> Thanks, a fixed version of the patch is attached.  If this works please
>> let me know and I'll apply.
>
> Still the same error:
>

Your previous example works as expected for me with the latest patch.

    * Load R packages and data

    #+BEGIN_SRC R :results output
    cat("Loading Data\n")
    #+END_SRC

    #+RESULTS:
    : Loading Data

Please double check that you applied the patch and reloaded Org-mode,
and if the bug persists provide another minimal example.

Thanks,

>
> ,----
> | Debugger entered--Lisp error: (wrong-type-argument sequencep 99)
> |   Mapconcat(identity "cat(\"YEAR\")" "\n")
> |   Org-babel-execute:R("cat(\"YEAR\")" ((:comments . "") (:shebang
> | . "") (:cache . "no") (:padline . "") (:noweb . "no") (:tangle
> | . "no") (:exports . "code") (:results . "replace output") (:session
> | . "none") (:hlines . "no") (:result-type . output) (:result-params
> | "output" "replace") (:rowname-names) (:colname-names)))
> |   org-babel-execute-src-block(nil)
> |   org-babel-execute-src-block-maybe()
> |   org-babel-execute-maybe()
> |   org-babel-execute-safely-maybe()
> |   run-hook-with-args-until-success(org-babel-execute-safely-maybe)
> |   org-ctrl-c-ctrl-c(nil)
> |   call-interactively(org-ctrl-c-ctrl-c nil nil)
> `----
>
> Cheers,
>
> Rainer
>
>
>>
>> Best,
>>
>>
>> From d67248db79faf19e1bdcac0230c37670b6115bdd Mon Sep 17 00:00:00 2001
>> From: Eric Schulte <schulte.eric@gmail.com>
>> Date: Sun, 23 Mar 2014 20:01:37 -0600
>> Subject: [PATCH] only wrap R code graphics-file on execution
>>
>>   Move this out of the expand-body function so that it is *never*
>>   applied to tangled code.
>> ---
>>  lisp/ob-R.el | 40 +++++++++++++++++++++-------------------
>>  1 file changed, 21 insertions(+), 19 deletions(-)
>>
>> diff --git a/lisp/ob-R.el b/lisp/ob-R.el
>> index 62aa7f2..780d99f 100644
>> --- a/lisp/ob-R.el
>> +++ b/lisp/ob-R.el
>> @@ -97,24 +97,15 @@ this variable.")
>>    "Expand BODY according to PARAMS, return the expanded body."
>>    (let ((graphics-file
>>  	 (or graphics-file (org-babel-R-graphical-output-file params))))
>> -    (mapconcat
>> -     #'identity
>> -     (let ((inside
>> -            (append
>> -             (when (cdr (assoc :prologue params))
>> -               (list (cdr (assoc :prologue params))))
>> -             (org-babel-variable-assignments:R params)
>> -             (list body)
>> -             (when (cdr (assoc :epilogue params))
>> -               (list (cdr (assoc :epilogue params)))))))
>> -       (if graphics-file
>> -           (append
>> -            (list (org-babel-R-construct-graphics-device-call
>> -                   graphics-file params))
>> -            inside
>> -            (list "},error=function(e){plot(x=-1:1, y=-1:1, type='n', xlab='', ylab='', axes=FALSE); text(x=0, y=0, labels=e$message, col='red'); paste('ERROR', e$message, sep=' : ')}); dev.off()"))
>> -         inside))
>> -     "\n")))
>> +    (mapconcat #'identity
>> +	       (append
>> +		(when (cdr (assoc :prologue params))
>> +		  (list (cdr (assoc :prologue params))))
>> +		(org-babel-variable-assignments:R params)
>> +		(list body)
>> +		(when (cdr (assoc :epilogue params))
>> +		  (list (cdr (assoc :epilogue params)))))
>> +	       "\n")))
>>  
>>  (defun org-babel-execute:R (body params)
>>    "Execute a block of R code.
>> @@ -127,7 +118,18 @@ This function is called by `org-babel-execute-src-block'."
>>  	   (colnames-p (cdr (assoc :colnames params)))
>>  	   (rownames-p (cdr (assoc :rownames params)))
>>  	   (graphics-file (org-babel-R-graphical-output-file params))
>> -	   (full-body (org-babel-expand-body:R body params graphics-file))
>> +	   (full-body
>> +	    (let ((inside
>> +		   (list (org-babel-expand-body:R body params graphics-file))))
>> +	      (mapconcat #'identity
>> +			 (if graphics-file
>> +			     (append
>> +			      (list (org-babel-R-construct-graphics-device-call
>> +				     graphics-file params))
>> +			      inside
>> +			      (list "},error=function(e){plot(x=-1:1, y=-1:1, type='n', xlab='', ylab='', axes=FALSE); text(x=0, y=0, labels=e$message, col='red'); paste('ERROR', e$message, sep=' : ')}); dev.off()"))
>> +			   inside)
>> +			 "\n")))
>>  	   (result
>>  	    (org-babel-R-evaluate
>>  	     session full-body result-type result-params
>> -- 
>> 1.9.1

-- 
Eric Schulte
https://cs.unm.edu/~eschulte
PGP: 0x614CA05D

Re: [BABEL] BUG Re: Omitting try/catch blocks from tangled R code?

[Rainer M Krug]

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

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

> Rainer M Krug <Rainer@krugs.de> writes:
>
>> Eric Schulte <schulte.eric@gmail.com> writes:
>>
>>>>
>>>> Apologies - I am still struggling with encryption......
>>>>
>>>> So here is my example:
>>>>
>>>> --8<---------------cut here---------------start------------->8---
>>>> #+TITLE: single_to_multi
>>>> #+DATE: <2013-10-15 Tue>
>>>> #+AUTHOR: Rainer M. Krug
>>>> #+EMAIL: Rainer@krugs.de
>>>>
>>>> ≈* Load R packages and data
>>>> #+BEGIN_SRC R
>>>> cat("Loading Data\n")
>>>> #+END_SRC
>>>> --8<---------------cut here---------------end--------------->8---
>>>>
>>>> I am using only org loaded and R enabled.
>>>>
>>>> C-c C-c on the block produces the error
>>>>
>>>> emacs version: 
>>>> GNU Emacs 24.3.1 (x86_64-apple-darwin13.0.0, Carbon Version 1.6.0
>>>> AppKit 1265) of 2014-02-13 on Rainers-MacBook-Pro-2.local
>>>>
>>>> org version:
>>>> Org-mode version 8.2.5h (release_8.2.5h-837-gb296cc @
>>>> /Users/rainerkrug/.emacs.d/org-mode/lisp/)
>>>>
>>>
>>> Thanks, a fixed version of the patch is attached.  If this works please
>>> let me know and I'll apply.
>>
>> Still the same error:
>>
>
> Your previous example works as expected for me with the latest patch.
>
>     * Load R packages and data
>
>     #+BEGIN_SRC R :results output
>     cat("Loading Data\n")
>     #+END_SRC
>
>     #+RESULTS:
>     : Loading Data
>
> Please double check that you applied the patch and reloaded Org-mode,
> and if the bug persists provide another minimal example.

Sorry - no idea what went wrong, but I assumed I applied the old
patch.

I applied the patch and it is working.

Cheers,

Rainer

>
> Thanks,
>
>>
>> ,----
>> | Debugger entered--Lisp error: (wrong-type-argument sequencep 99)
>> |   Mapconcat(identity "cat(\"YEAR\")" "\n")
>> |   Org-babel-execute:R("cat(\"YEAR\")" ((:comments . "") (:shebang
>> | . "") (:cache . "no") (:padline . "") (:noweb . "no") (:tangle
>> | . "no") (:exports . "code") (:results . "replace output") (:session
>> | . "none") (:hlines . "no") (:result-type . output) (:result-params
>> | "output" "replace") (:rowname-names) (:colname-names)))
>> |   org-babel-execute-src-block(nil)
>> |   org-babel-execute-src-block-maybe()
>> |   org-babel-execute-maybe()
>> |   org-babel-execute-safely-maybe()
>> |   run-hook-with-args-until-success(org-babel-execute-safely-maybe)
>> |   org-ctrl-c-ctrl-c(nil)
>> |   call-interactively(org-ctrl-c-ctrl-c nil nil)
>> `----
>>
>> Cheers,
>>
>> Rainer
>>
>>
>>>
>>> Best,
>>>
>>>
>>> From d67248db79faf19e1bdcac0230c37670b6115bdd Mon Sep 17 00:00:00 2001
>>> From: Eric Schulte <schulte.eric@gmail.com>
>>> Date: Sun, 23 Mar 2014 20:01:37 -0600
>>> Subject: [PATCH] only wrap R code graphics-file on execution
>>>
>>>   Move this out of the expand-body function so that it is *never*
>>>   applied to tangled code.
>>> ---
>>>  lisp/ob-R.el | 40 +++++++++++++++++++++-------------------
>>>  1 file changed, 21 insertions(+), 19 deletions(-)
>>>
>>> diff --git a/lisp/ob-R.el b/lisp/ob-R.el
>>> index 62aa7f2..780d99f 100644
>>> --- a/lisp/ob-R.el
>>> +++ b/lisp/ob-R.el
>>> @@ -97,24 +97,15 @@ this variable.")
>>>    "Expand BODY according to PARAMS, return the expanded body."
>>>    (let ((graphics-file
>>>  	 (or graphics-file (org-babel-R-graphical-output-file params))))
>>> -    (mapconcat
>>> -     #'identity
>>> -     (let ((inside
>>> -            (append
>>> -             (when (cdr (assoc :prologue params))
>>> -               (list (cdr (assoc :prologue params))))
>>> -             (org-babel-variable-assignments:R params)
>>> -             (list body)
>>> -             (when (cdr (assoc :epilogue params))
>>> -               (list (cdr (assoc :epilogue params)))))))
>>> -       (if graphics-file
>>> -           (append
>>> -            (list (org-babel-R-construct-graphics-device-call
>>> -                   graphics-file params))
>>> -            inside
>>> -            (list "},error=function(e){plot(x=-1:1, y=-1:1, type='n', xlab='', ylab='', axes=FALSE); text(x=0, y=0, labels=e$message, col='red'); paste('ERROR', e$message, sep=' : ')}); dev.off()"))
>>> -         inside))
>>> -     "\n")))
>>> +    (mapconcat #'identity
>>> +	       (append
>>> +		(when (cdr (assoc :prologue params))
>>> +		  (list (cdr (assoc :prologue params))))
>>> +		(org-babel-variable-assignments:R params)
>>> +		(list body)
>>> +		(when (cdr (assoc :epilogue params))
>>> +		  (list (cdr (assoc :epilogue params)))))
>>> +	       "\n")))
>>>  
>>>  (defun org-babel-execute:R (body params)
>>>    "Execute a block of R code.
>>> @@ -127,7 +118,18 @@ This function is called by `org-babel-execute-src-block'."
>>>  	   (colnames-p (cdr (assoc :colnames params)))
>>>  	   (rownames-p (cdr (assoc :rownames params)))
>>>  	   (graphics-file (org-babel-R-graphical-output-file params))
>>> -	   (full-body (org-babel-expand-body:R body params graphics-file))
>>> +	   (full-body
>>> +	    (let ((inside
>>> +		   (list (org-babel-expand-body:R body params graphics-file))))
>>> +	      (mapconcat #'identity
>>> +			 (if graphics-file
>>> +			     (append
>>> +			      (list (org-babel-R-construct-graphics-device-call
>>> +				     graphics-file params))
>>> +			      inside
>>> +			      (list "},error=function(e){plot(x=-1:1, y=-1:1, type='n', xlab='', ylab='', axes=FALSE); text(x=0, y=0, labels=e$message, col='red'); paste('ERROR', e$message, sep=' : ')}); dev.off()"))
>>> +			   inside)
>>> +			 "\n")))
>>>  	   (result
>>>  	    (org-babel-R-evaluate
>>>  	     session full-body result-type result-params
>>> -- 
>>> 1.9.1

-- 
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:      Rainer@krugs.de

Skype:      RMkrug

PGP: 0x0F52F982

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 4474 bytes --]

Re: [BABEL] BUG Re: Omitting try/catch blocks from tangled R code?

[Eric Schulte]

>
> I applied the patch and it is working.
>

Great, I've just pushed it up.

Best,

-- 
Eric Schulte
https://cs.unm.edu/~eschulte
PGP: 0x614CA05D