Genuine relative paths with R

classic Classic list List threaded Threaded
52 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: Genuine relative paths with R

Duncan Murdoch-2
On 10/10/2018 7:11 PM, Olivier GIVAUDAN wrote:
> It is not wrong to claim that R currently doesn't have a function
> returning the path of the R file where this same function was invoked.

But it does.  I didn't realize that's what you were asking for.  This
has nothing to do with your subject line.

If you source a file from somewhere, then each of the functions it
creates is marked with its source location.  So you can put this in a file:

foo <- function () 1

filename <- normalizePath(getSrcFilename(foo, full.names=TRUE))

(You need the normalizePath() call because all that will be saved is the
path that was used.  If it was a relative path, that's what you get
before you normalize it.  You don't really need the foo function; you
could put an anonymous function into the getSrcFilename call.  It's just
usually easier to include a function that already exists.)

When you source() that file, filename will get the name of the file it
came from.

This is a lot like __FILE__ in C.  One difference is that it is usually
turned off when the function is being loaded into a package, but you can
optionally turn it on.

You can also find out what line foo starts on, using

fooline <- getSrcLocation(foo)

This is a lot like __LINE__ in C.

Duncan Murdoch


>
> 'getwd()' is indeed not equivalent to VBA
> 'Application.ThisWorkbook.Path' or C macro '__FILE__' or SAS
> %sysget(SAS_EXECFILENAME), etc.
> ------------------------------------------------------------------------
> *De :* Duncan Murdoch <[hidden email]>
> *Envoyé :* mercredi 10 octobre 2018 22:59
> *À :* Olivier GIVAUDAN; Jeff Newmiller
> *Cc :* [hidden email]
> *Objet :* Re: [R] Genuine relative paths with R
> On 10/10/2018 6:52 PM, Olivier GIVAUDAN wrote:
>>>  Again, you seem to think making a package is a big deal.
>>
>> Perhaps not a big deal (I believe you, I didn't write an R package yet),
>> but not as straightforward as having a function within an R file
>> returning its own path.
>>
>>> But you're free to decide not to do it:  just please don't repeat
>> falseclaims about R (like the ones about paths that started this long
>> thread).
>>
>> Which false claims?
>
> "But I am really wondering why R doesn't have (please tell me if I'm
> wrong) this basic feature as many other languages have it (batch, shell,
> C, LaTeX, SAS with macro-variables, etc.)?"
>
> Duncan Murdoch
>
>> ------------------------------------------------------------------------
>> *De :* Duncan Murdoch <[hidden email]>
>> *Envoyé :* mercredi 10 octobre 2018 22:31
>> *À :* Olivier GIVAUDAN; Jeff Newmiller
>> *Cc :* [hidden email]
>> *Objet :* Re: [R] Genuine relative paths with R
>> On 10/10/2018 6:17 PM, Olivier GIVAUDAN wrote:
>>>> Nothing says a package has to go on CRAN.  You can distribute
>>> themprivately to a small audience.
>>>
>>> Yes, I agree in theory. But this solution still violates my own
>>> proportionality principle.
>>
>> Again, you seem to think making a package is a big deal.  Maybe that was
>> true 10 years ago (though I wrote and tested a package in a 45 minute
>> presentation at UseR 2008), but now it's very easy.
>>
>> But you're free to decide not to do it:  just please don't repeat false
>> claims about R (like the ones about paths that started this long thread).
>>
>>>
>>>> If you know as much about R as the people who wrote it
>>>
>>> I didn't claim that (that's was a quite general / theoretical statement,
>>> not necessarily and only applicable to R).
>>
>> I didn't say you made that claim.  I was answering your question about
>> why inventing your own way is not a good idea.  It might be a good idea,
>> if you know the system very, very well.  Otherwise, it's probably better
>> to work the standard way.
>>
>> Duncan Murdoch
>>
>>>
>>>> For example, you might thinkthat all front ends set the working
>>> directory to the directory of theprogram they are running, because the
>>> ones you've tried do it that way. But they don't.
>>>
>>> It runs that way at least on Windows with RStudio and R GUI and I know
>>> the recipients of my R code work on Windows with at least one of these 2
>>> GUIs. So the workaround I finally found satisfies my current needs
>>> ------------------------------------------------------------------------
>>> *De :* Duncan Murdoch <[hidden email]>
>>> *Envoyé :* mercredi 10 octobre 2018 22:07
>>> *À :* Olivier GIVAUDAN; Jeff Newmiller
>>> *Cc :* [hidden email]
>>> *Objet :* Re: [R] Genuine relative paths with R
>>> On 10/10/2018 5:45 PM, Olivier GIVAUDAN wrote:
>>>> I'm not sure I'm "inventing my own way" of distributing R code... And I
>>>> distribute it to a very limited audience.
>>>
>>> Nothing says a package has to go on CRAN.  You can distribute them
>>> privately to a small audience.
>>>
>>>> Anyway, why not "inventing a new way" if it's more efficient than the
>>>> standard one (I'm talking now in theory)?
>>>
>>> If you know as much about R as the people who wrote it, then you can
>>> almost certainly invent better ways to do many of the things it does.  R
>>> Core was constrained by trying to maintain back compatibility, and that
>>> means some of their solutions aren't perfect.
>>>
>>> But if you don't know it that well, chances are you'll make mistakes
>>> when you invent your own way of doing it.  For example, you might think
>>> that all front ends set the working directory to the directory of the
>>> program they are running, because the ones you've tried do it that way.
>>> But they don't.
>>>
>>> Duncan Murdoch
>>>
>>>> ------------------------------------------------------------------------
>>>> *De :* Duncan Murdoch <[hidden email]>
>>>> *Envoyé :* mercredi 10 octobre 2018 21:39
>>>> *À :* Olivier GIVAUDAN; Jeff Newmiller
>>>> *Cc :* [hidden email]
>>>> *Objet :* Re: [R] Genuine relative paths with R
>>>> On 10/10/2018 5:31 PM, Olivier GIVAUDAN wrote:
>>>>> I do not want to use the terminal, just double clicks (i.e. the
>>>>> simplest, automatic, non-manual way, without having to write a line /
>>>>> command).
>>>>> Therefore everything should happen outside any terminal. The user won't
>>>>> use a terminal.
>>>>>
>>>>> I don't have a Mac and I'm not familiar with this OS, sorry.
>>>>> But I'm really surprised the click method gives different results than
>>>>> on Linux and Windows.
>>>>> I know the click method worked both on Linux (Ubuntu latest version) and
>>>>> Windows (10).
>>>>>
>>>>> Yes, I executed my file from a terminal and got obviously the same
>>>>> result as you (that's reassuring).
>>>>>
>>>>> Come on guys, creating a package... It's like using a hammer to kill a
>>>>> fly...
>>>>
>>>> It's a simple operation to create a package in RStudio.  Not quite a
>>>> single click, but just a few.
>>>>
>>>> In plain R, it's just a little more work using package.skeleton().
>>>>
>>>> Really, if you are distributing R code, you should do it in the standard
>>>> way, not invent your own.
>>>>
>>>> Duncan Murdoch
>>>>
>>>>> ------------------------------------------------------------------------
>>>>> *De :* Duncan Murdoch <[hidden email]>
>>>>> *Envoyé :* mercredi 10 octobre 2018 20:54
>>>>> *À :* Olivier GIVAUDAN; Jeff Newmiller
>>>>> *Cc :* [hidden email]
>>>>> *Objet :* Re: [R] Genuine relative paths with R
>>>>> On 10/10/2018 4:42 PM, Olivier GIVAUDAN wrote:
>>>>>> Why are you not simply double-clicking on 'TestPWD' and choosing to
>>>>>> execute the file (don't add anything)?
>>>>>> Are you executing the file from a terminal?
>>>>>
>>>>> Yes, I was executing the file from my terminal.  Otherwise I really have
>>>>> no idea what the "current directory" is in the Finder.   (I'm on a Mac.
>>>>> I just tried the click method; it printed my home directory, not the
>>>>> directory of the script.)
>>>>>
>>>>> I don't know the name of your visual front end, but you are displaying
>>>>> the working directory that it sets when you click on TestPWD.  That will
>>>>> be different from the working directory that your user sees in the Terminal.
>>>>>
>>>>> You can see what I saw if you run TestPWD from the Terminal.  It will
>>>>> print the current working directory, not the one where TestPWD happens
>>>>> to live.
>>>>>
>>>>> If you want to do the same sort of thing in R, you could set up a script
>>>>> that calls R, and execute that in the way you executed TestPWD.  But in
>>>>> another message you said you aren't allowed to do that, so I think your
>>>>> best solution is the one offered by Bill Dunlap:  organize your files as
>>>>> an R package.  If you name your package "Olivier", then you can find all
>>>>> the files in it under the directory returned by
>>>>>
>>>>>     system.file(".", package = "Olivier")
>>>>>
>>>>> The package system is designed for R code, but you can put arbitrary
>>>>> files into a package:  just store them under the "inst" directory in
>>>>> your source.  When the package is installed, those files will be moved
>>>>> up one level, i.e.
>>>>>
>>>>> Olivier/inst/foo
>>>>>
>>>>> will become
>>>>>
>>>>>     system.file("foo", package = "Olivier")
>>>>>
>>>>> Duncan Murdoch
>>>>
>>>
>>
>

______________________________________________
[hidden email] mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
Reply | Threaded
Open this post in threaded view
|

Re: Genuine relative paths with R

Olivier GIVAUDAN
In reply to this post by R help mailing list-2
Yes, I am aware that both '__FILE__' and 'SAS_EXECFILENAME' are macro variables. I don't know how the VBA 'Application.ThisWorkbook.Path' VBA or PHP '__DIR__' (or '__FILE__') work.

And yes, indeed, until now I didn't even realise that this simple find-and-replace solution of "mine" is actually the basic job of a preprocessor when it expands macro variables, thank you!

A macro language in R, yes, I think it would be useful, at least for this function. If nothing simpler is available, of course...
________________________________
De : Peter Claussen <[hidden email]>
Envoy� : mercredi 10 octobre 2018 23:29
� : Olivier GIVAUDAN
Cc : Duncan Murdoch; Jeff Newmiller; [hidden email]
Objet : Re: [R] Genuine relative paths with R

If I�m following all this correctly, it seems your criticism is that R doesn�t provide a run-time function that is equivalent to a compile-time macro. You do realize that __FILE__ is not part of the C programming language - it�s a predefined variable recognized by the cpp - the C preprocessor program. Similarly, SAS_EXECFILENAME is a predefined variable that can be recognized by the SAS macro processor, but has no meaning in the SAS language itself.

So, to go back to your original post:
1.  Either create a variable "ScriptPath" in the first lines of each of my R scripts and run a batch (or shell, etc.) to replace every single occurrence of "ScriptPath <-" by "ScriptPath <- [Absolute path of the R script]" in all the R scripts located in the folder (and possibly subfolders) of the batch file.

This is what a macro processor does. Are you asking for a macro language in R?

Cheers

On Oct 10, 2018, at 6:11 PM, Olivier GIVAUDAN <[hidden email]<mailto:[hidden email]>> wrote:

It is not wrong to claim that R currently doesn't have a function returning the path of the R file where this same function was invoked.

'getwd()' is indeed not equivalent to VBA 'Application.ThisWorkbook.Path' or C macro '__FILE__' or SAS %sysget(SAS_EXECFILENAME), etc.


        [[alternative HTML version deleted]]


______________________________________________
[hidden email] mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
Reply | Threaded
Open this post in threaded view
|

Re: Genuine relative paths with R

Olivier GIVAUDAN
In reply to this post by Duncan Murdoch-2
I think Gabor (at least) already suggested this solution. But the problem is: how do you source this file containing this 'foo' function without writing its absolute path?

It's a kind of initialisation issue.

> a function returning the path of the R file where this same function was invoked.
>> I didn't realize that's what you were asking for. This has nothing to do with your subject line.

It's just a trick to work with relative paths without having to write any hardcoded (by definition) absolute path beforehand.
________________________________
De : Duncan Murdoch <[hidden email]>
Envoy� : mercredi 10 octobre 2018 23:51
� : Olivier GIVAUDAN; Jeff Newmiller
Cc : [hidden email]
Objet : Re: [R] Genuine relative paths with R

On 10/10/2018 7:11 PM, Olivier GIVAUDAN wrote:
> It is not wrong to claim that R currently doesn't have a function
> returning the path of the R file where this same function was invoked.

But it does.  I didn't realize that's what you were asking for.  This
has nothing to do with your subject line.

If you source a file from somewhere, then each of the functions it
creates is marked with its source location.  So you can put this in a file:

foo <- function () 1

filename <- normalizePath(getSrcFilename(foo, full.names=TRUE))

(You need the normalizePath() call because all that will be saved is the
path that was used.  If it was a relative path, that's what you get
before you normalize it.  You don't really need the foo function; you
could put an anonymous function into the getSrcFilename call.  It's just
usually easier to include a function that already exists.)

When you source() that file, filename will get the name of the file it
came from.

This is a lot like __FILE__ in C.  One difference is that it is usually
turned off when the function is being loaded into a package, but you can
optionally turn it on.

You can also find out what line foo starts on, using

fooline <- getSrcLocation(foo)

This is a lot like __LINE__ in C.

Duncan Murdoch


>
> 'getwd()' is indeed not equivalent to VBA
> 'Application.ThisWorkbook.Path' or C macro '__FILE__' or SAS
> %sysget(SAS_EXECFILENAME), etc.
> ------------------------------------------------------------------------
> *De :* Duncan Murdoch <[hidden email]>
> *Envoy� :* mercredi 10 octobre 2018 22:59
> *� :* Olivier GIVAUDAN; Jeff Newmiller
> *Cc :* [hidden email]
> *Objet :* Re: [R] Genuine relative paths with R
> On 10/10/2018 6:52 PM, Olivier GIVAUDAN wrote:
>>>  Again, you seem to think making a package is a big deal.
>>
>> Perhaps not a big deal (I believe you, I didn't write an R package yet),
>> but not as straightforward as having a function within an R file
>> returning its own path.
>>
>>> But you're free to decide not to do it:  just please don't repeat
>> falseclaims about R (like the ones about paths that started this long
>> thread).
>>
>> Which false claims?
>
> "But I am really wondering why R doesn't have (please tell me if I'm
> wrong) this basic feature as many other languages have it (batch, shell,
> C, LaTeX, SAS with macro-variables, etc.)?"
>
> Duncan Murdoch
>
>> ------------------------------------------------------------------------
>> *De :* Duncan Murdoch <[hidden email]>
>> *Envoy� :* mercredi 10 octobre 2018 22:31
>> *� :* Olivier GIVAUDAN; Jeff Newmiller
>> *Cc :* [hidden email]
>> *Objet :* Re: [R] Genuine relative paths with R
>> On 10/10/2018 6:17 PM, Olivier GIVAUDAN wrote:
>>>> Nothing says a package has to go on CRAN.  You can distribute
>>> themprivately to a small audience.
>>>
>>> Yes, I agree in theory. But this solution still violates my own
>>> proportionality principle.
>>
>> Again, you seem to think making a package is a big deal.  Maybe that was
>> true 10 years ago (though I wrote and tested a package in a 45 minute
>> presentation at UseR 2008), but now it's very easy.
>>
>> But you're free to decide not to do it:  just please don't repeat false
>> claims about R (like the ones about paths that started this long thread).
>>
>>>
>>>> If you know as much about R as the people who wrote it
>>>
>>> I didn't claim that (that's was a quite general / theoretical statement,
>>> not necessarily and only applicable to R).
>>
>> I didn't say you made that claim.  I was answering your question about
>> why inventing your own way is not a good idea.  It might be a good idea,
>> if you know the system very, very well.  Otherwise, it's probably better
>> to work the standard way.
>>
>> Duncan Murdoch
>>
>>>
>>>> For example, you might thinkthat all front ends set the working
>>> directory to the directory of theprogram they are running, because the
>>> ones you've tried do it that way. But they don't.
>>>

>>> GUIs. So the workaround I finally found satisfies my current needs
>>> ------------------------------------------------------------------------
>>> *De :* Duncan Murdoch <[hidden email]>
>>> *Envoy� :* mercredi 10 octobre 2018 22:07
>>> *� :* Olivier GIVAUDAN; Jeff Newmiller
>>> *Cc :* [hidden email]
>>> *Objet :* Re: [R] Genuine relative paths with R
>>> On 10/10/2018 5:45 PM, Olivier GIVAUDAN wrote:
>>>> I'm not sure I'm "inventing my own way" of distributing R code... And I
>>>> distribute it to a very limited audience.
>>>
>>> Nothing says a package has to go on CRAN.  You can distribute them
>>> privately to a small audience.
>>>
>>>> Anyway, why not "inventing a new way" if it's more efficient than the
>>>> standard one (I'm talking now in theory)?
>>>
>>> If you know as much about R as the people who wrote it, then you can
>>> almost certainly invent better ways to do many of the things it does.  R
>>> Core was constrained by trying to maintain back compatibility, and that
>>> means some of their solutions aren't perfect.
>>>
>>> But if you don't know it that well, chances are you'll make mistakes
>>> when you invent your own way of doing it.  For example, you might think
>>> that all front ends set the working directory to the directory of the
>>> program they are running, because the ones you've tried do it that way.
>>> But they don't.
>>>
>>> Duncan Murdoch
>>>
>>>> ------------------------------------------------------------------------
>>>> *De :* Duncan Murdoch <[hidden email]>
>>>> *Envoy� :* mercredi 10 octobre 2018 21:39
>>>> *� :* Olivier GIVAUDAN; Jeff Newmiller
>>>> *Cc :* [hidden email]
>>>> *Objet :* Re: [R] Genuine relative paths with R
>>>> On 10/10/2018 5:31 PM, Olivier GIVAUDAN wrote:
>>>>> I do not want to use the terminal, just double clicks (i.e. the
>>>>> simplest, automatic, non-manual way, without having to write a line /
>>>>> command).
>>>>> Therefore everything should happen outside any terminal. The user won't
>>>>> use a terminal.
>>>>>
>>>>> I don't have a Mac and I'm not familiar with this OS, sorry.
>>>>> But I'm really surprised the click method gives different results than

>>>>> I know the click method worked both on Linux (Ubuntu latest version) and

>>>>>
>>>>> Yes, I executed my file from a terminal and got obviously the same
>>>>> result as you (that's reassuring).
>>>>>
>>>>> Come on guys, creating a package... It's like using a hammer to kill a
>>>>> fly...
>>>>
>>>> It's a simple operation to create a package in RStudio.  Not quite a
>>>> single click, but just a few.
>>>>
>>>> In plain R, it's just a little more work using package.skeleton().
>>>>
>>>> Really, if you are distributing R code, you should do it in the standard
>>>> way, not invent your own.
>>>>
>>>> Duncan Murdoch
>>>>
>>>>> ------------------------------------------------------------------------
>>>>> *De :* Duncan Murdoch <[hidden email]>
>>>>> *Envoy� :* mercredi 10 octobre 2018 20:54
>>>>> *� :* Olivier GIVAUDAN; Jeff Newmiller
>>>>> *Cc :* [hidden email]
>>>>> *Objet :* Re: [R] Genuine relative paths with R
>>>>> On 10/10/2018 4:42 PM, Olivier GIVAUDAN wrote:
>>>>>> Why are you not simply double-clicking on 'TestPWD' and choosing to
>>>>>> execute the file (don't add anything)?
>>>>>> Are you executing the file from a terminal?
>>>>>
>>>>> Yes, I was executing the file from my terminal.  Otherwise I really have
>>>>> no idea what the "current directory" is in the Finder.   (I'm on a Mac.
>>>>> I just tried the click method; it printed my home directory, not the
>>>>> directory of the script.)
>>>>>
>>>>> I don't know the name of your visual front end, but you are displaying
>>>>> the working directory that it sets when you click on TestPWD.  That will
>>>>> be different from the working directory that your user sees in the Terminal.
>>>>>
>>>>> You can see what I saw if you run TestPWD from the Terminal.  It will
>>>>> print the current working directory, not the one where TestPWD happens
>>>>> to live.
>>>>>
>>>>> If you want to do the same sort of thing in R, you could set up a script
>>>>> that calls R, and execute that in the way you executed TestPWD.  But in
>>>>> another message you said you aren't allowed to do that, so I think your
>>>>> best solution is the one offered by Bill Dunlap:  organize your files as
>>>>> an R package.  If you name your package "Olivier", then you can find all
>>>>> the files in it under the directory returned by
>>>>>
>>>>>     system.file(".", package = "Olivier")
>>>>>
>>>>> The package system is designed for R code, but you can put arbitrary
>>>>> files into a package:  just store them under the "inst" directory in
>>>>> your source.  When the package is installed, those files will be moved
>>>>> up one level, i.e.
>>>>>
>>>>> Olivier/inst/foo
>>>>>
>>>>> will become
>>>>>
>>>>>     system.file("foo", package = "Olivier")
>>>>>
>>>>> Duncan Murdoch
>>>>
>>>
>>
>

        [[alternative HTML version deleted]]


______________________________________________
[hidden email] mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
Reply | Threaded
Open this post in threaded view
|

Re: Genuine relative paths with R

Fritsch, Katharina (NNL)
In reply to this post by Olivier GIVAUDAN
Hiya,
I have lost track of half the discussion so forgive me if that suggestion has been made before, but would it be suitable to wrap your code in a shiny app and disseminate it this way?
Kind regards,
Katharina.

--

Dr Katharina Fritsch B.Sc. M.Sc. MRSC
Chemical Modeller, Chemical and Process Modelling


E.
[hidden email]
T.
+44 (0)1925 289387
@uknnl

National Nuclear Laboratory Limited, 5th Floor, Chadwick House,
Birchwood Park, Warrington, WA3 6AE, UK

www.nnl.co.uk

-----Original Message-----
From: R-help [mailto:[hidden email]] On Behalf Of Olivier GIVAUDAN
Sent: 11 October 2018 00:54
To: Peter Claussen
Cc: [hidden email]
Subject: Re: [R] Genuine relative paths with R

Yes, I am aware that both '__FILE__' and 'SAS_EXECFILENAME' are macro variables. I don't know how the VBA 'Application.ThisWorkbook.Path' VBA or PHP '__DIR__' (or '__FILE__') work.

And yes, indeed, until now I didn't even realise that this simple find-and-replace solution of "mine" is actually the basic job of a preprocessor when it expands macro variables, thank you!

A macro language in R, yes, I think it would be useful, at least for this function. If nothing simpler is available, of course...
________________________________
De : Peter Claussen <[hidden email]> Envoy  : mercredi 10 octobre 2018 23:29   : Olivier GIVAUDAN Cc : Duncan Murdoch; Jeff Newmiller; [hidden email] Objet : Re: [R] Genuine relative paths with R

If I m following all this correctly, it seems your criticism is that R doesn t provide a run-time function that is equivalent to a compile-time macro. You do realize that __FILE__ is not part of the C programming language - it s a predefined variable recognized by the cpp - the C preprocessor program. Similarly, SAS_EXECFILENAME is a predefined variable that can be recognized by the SAS macro processor, but has no meaning in the SAS language itself.

So, to go back to your original post:
1.  Either create a variable "ScriptPath" in the first lines of each of my R scripts and run a batch (or shell, etc.) to replace every single occurrence of "ScriptPath <-" by "ScriptPath <- [Absolute path of the R script]" in all the R scripts located in the folder (and possibly subfolders) of the batch file.

This is what a macro processor does. Are you asking for a macro language in R?

Cheers

On Oct 10, 2018, at 6:11 PM, Olivier GIVAUDAN <[hidden email]<mailto:[hidden email]>> wrote:

It is not wrong to claim that R currently doesn't have a function returning the path of the R file where this same function was invoked.

'getwd()' is indeed not equivalent to VBA 'Application.ThisWorkbook.Path' or C macro '__FILE__' or SAS %sysget(SAS_EXECFILENAME), etc.


        [[alternative HTML version deleted]]


This e-mail is from National Nuclear Laboratory Limited ("NNL"). This e-mail and any attachments are intended for the addressee and may also be legally privileged. If you are not the intended recipient please do not print, re-transmit, store or act in reliance on it or any attachments. Instead, please e-mail it back to the sender and then immediately permanently delete it.

National Nuclear Laboratory Limited (Company number 3857752) Registered in England and Wales. Registered office: Chadwick House, Warrington Road, Birchwood Park, Warrington, WA3 6AE.
______________________________________________
[hidden email] mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
Reply | Threaded
Open this post in threaded view
|

Re: Genuine relative paths with R

Duncan Murdoch-2
In reply to this post by Olivier GIVAUDAN
On 10/10/2018 8:08 PM, Olivier GIVAUDAN wrote:
> I think Gabor (at least) already suggested this solution. But the
> problem is: how do you source this file containing this 'foo' function
> without writing its absolute path?

You only need its relative path to source it.

Duncan Murdoch

>
> It's a kind of initialisation issue.
>
>  > a function returning the path of the R file where this same function
> was invoked.
>  >> I didn't realize that's what you were asking for. This has nothing
> to do with your subject line.
>
> It's just a trick to work with relative paths without having to write
> any hardcoded (by definition) absolute path beforehand.
> ------------------------------------------------------------------------
> *De :* Duncan Murdoch <[hidden email]>
> *Envoyé :* mercredi 10 octobre 2018 23:51
> *À :* Olivier GIVAUDAN; Jeff Newmiller
> *Cc :* [hidden email]
> *Objet :* Re: [R] Genuine relative paths with R
> On 10/10/2018 7:11 PM, Olivier GIVAUDAN wrote:
>> It is not wrong to claim that R currently doesn't have a function
>> returning the path of the R file where this same function was invoked.
>
> But it does.  I didn't realize that's what you were asking for.  This
> has nothing to do with your subject line.
>
> If you source a file from somewhere, then each of the functions it
> creates is marked with its source location.  So you can put this in a file:
>
> foo <- function () 1
>
> filename <- normalizePath(getSrcFilename(foo, full.names=TRUE))
>
> (You need the normalizePath() call because all that will be saved is the
> path that was used.  If it was a relative path, that's what you get
> before you normalize it.  You don't really need the foo function; you
> could put an anonymous function into the getSrcFilename call.  It's just
> usually easier to include a function that already exists.)
>
> When you source() that file, filename will get the name of the file it
> came from.
>
> This is a lot like __FILE__ in C.  One difference is that it is usually
> turned off when the function is being loaded into a package, but you can
> optionally turn it on.
>
> You can also find out what line foo starts on, using
>
> fooline <- getSrcLocation(foo)
>
> This is a lot like __LINE__ in C.
>
> Duncan Murdoch
>
>
>>
>> 'getwd()' is indeed not equivalent to VBA
>> 'Application.ThisWorkbook.Path' or C macro '__FILE__' or SAS
>> %sysget(SAS_EXECFILENAME), etc.
>> ------------------------------------------------------------------------
>> *De :* Duncan Murdoch <[hidden email]>
>> *Envoyé :* mercredi 10 octobre 2018 22:59
>> *À :* Olivier GIVAUDAN; Jeff Newmiller
>> *Cc :* [hidden email]
>> *Objet :* Re: [R] Genuine relative paths with R
>> On 10/10/2018 6:52 PM, Olivier GIVAUDAN wrote:
>>>>  Again, you seem to think making a package is a big deal.
>>>
>>> Perhaps not a big deal (I believe you, I didn't write an R package yet),
>>> but not as straightforward as having a function within an R file
>>> returning its own path.
>>>
>>>> But you're free to decide not to do it:  just please don't repeat
>>> falseclaims about R (like the ones about paths that started this long
>>> thread).
>>>
>>> Which false claims?
>>
>> "But I am really wondering why R doesn't have (please tell me if I'm
>> wrong) this basic feature as many other languages have it (batch, shell,
>> C, LaTeX, SAS with macro-variables, etc.)?"
>>
>> Duncan Murdoch
>>
>>> ------------------------------------------------------------------------
>>> *De :* Duncan Murdoch <[hidden email]>
>>> *Envoyé :* mercredi 10 octobre 2018 22:31
>>> *À :* Olivier GIVAUDAN; Jeff Newmiller
>>> *Cc :* [hidden email]
>>> *Objet :* Re: [R] Genuine relative paths with R
>>> On 10/10/2018 6:17 PM, Olivier GIVAUDAN wrote:
>>>>> Nothing says a package has to go on CRAN.  You can distribute
>>>> themprivately to a small audience.
>>>>
>>>> Yes, I agree in theory. But this solution still violates my own
>>>> proportionality principle.
>>>
>>> Again, you seem to think making a package is a big deal.  Maybe that was
>>> true 10 years ago (though I wrote and tested a package in a 45 minute
>>> presentation at UseR 2008), but now it's very easy.
>>>
>>> But you're free to decide not to do it:  just please don't repeat false
>>> claims about R (like the ones about paths that started this long thread).
>>>
>>>>
>>>>> If you know as much about R as the people who wrote it
>>>>
>>>> I didn't claim that (that's was a quite general / theoretical statement,
>>>> not necessarily and only applicable to R).
>>>
>>> I didn't say you made that claim.  I was answering your question about
>>> why inventing your own way is not a good idea.  It might be a good idea,
>>> if you know the system very, very well.  Otherwise, it's probably better
>>> to work the standard way.
>>>
>>> Duncan Murdoch
>>>
>>>>
>>>>> For example, you might thinkthat all front ends set the working
>>>> directory to the directory of theprogram they are running, because the
>>>> ones you've tried do it that way. But they don't.
>>>>
>>>> It runs that way at least on Windows with RStudio and R GUI and I know
>>>> the recipients of my R code work on Windows with at least one of these 2
>>>> GUIs. So the workaround I finally found satisfies my current needs
>>>> ------------------------------------------------------------------------
>>>> *De :* Duncan Murdoch <[hidden email]>
>>>> *Envoyé :* mercredi 10 octobre 2018 22:07
>>>> *À :* Olivier GIVAUDAN; Jeff Newmiller
>>>> *Cc :* [hidden email]
>>>> *Objet :* Re: [R] Genuine relative paths with R
>>>> On 10/10/2018 5:45 PM, Olivier GIVAUDAN wrote:
>>>>> I'm not sure I'm "inventing my own way" of distributing R code... And I
>>>>> distribute it to a very limited audience.
>>>>
>>>> Nothing says a package has to go on CRAN.  You can distribute them
>>>> privately to a small audience.
>>>>
>>>>> Anyway, why not "inventing a new way" if it's more efficient than the
>>>>> standard one (I'm talking now in theory)?
>>>>
>>>> If you know as much about R as the people who wrote it, then you can
>>>> almost certainly invent better ways to do many of the things it does.  R
>>>> Core was constrained by trying to maintain back compatibility, and that
>>>> means some of their solutions aren't perfect.
>>>>
>>>> But if you don't know it that well, chances are you'll make mistakes
>>>> when you invent your own way of doing it.  For example, you might think
>>>> that all front ends set the working directory to the directory of the
>>>> program they are running, because the ones you've tried do it that way.
>>>> But they don't.
>>>>
>>>> Duncan Murdoch
>>>>
>>>>> ------------------------------------------------------------------------
>>>>> *De :* Duncan Murdoch <[hidden email]>
>>>>> *Envoyé :* mercredi 10 octobre 2018 21:39
>>>>> *À :* Olivier GIVAUDAN; Jeff Newmiller
>>>>> *Cc :* [hidden email]
>>>>> *Objet :* Re: [R] Genuine relative paths with R
>>>>> On 10/10/2018 5:31 PM, Olivier GIVAUDAN wrote:
>>>>>> I do not want to use the terminal, just double clicks (i.e. the
>>>>>> simplest, automatic, non-manual way, without having to write a line /
>>>>>> command).
>>>>>> Therefore everything should happen outside any terminal. The user won't
>>>>>> use a terminal.
>>>>>>
>>>>>> I don't have a Mac and I'm not familiar with this OS, sorry.
>>>>>> But I'm really surprised the click method gives different results than
>>>>>> on Linux and Windows.
>>>>>> I know the click method worked both on Linux (Ubuntu latest version) and
>>>>>> Windows (10).
>>>>>>
>>>>>> Yes, I executed my file from a terminal and got obviously the same
>>>>>> result as you (that's reassuring).
>>>>>>
>>>>>> Come on guys, creating a package... It's like using a hammer to kill a
>>>>>> fly...
>>>>>
>>>>> It's a simple operation to create a package in RStudio.  Not quite a
>>>>> single click, but just a few.
>>>>>
>>>>> In plain R, it's just a little more work using package.skeleton().
>>>>>
>>>>> Really, if you are distributing R code, you should do it in the standard
>>>>> way, not invent your own.
>>>>>
>>>>> Duncan Murdoch
>>>>>
>>>>>> ------------------------------------------------------------------------
>>>>>> *De :* Duncan Murdoch <[hidden email]>
>>>>>> *Envoyé :* mercredi 10 octobre 2018 20:54
>>>>>> *À :* Olivier GIVAUDAN; Jeff Newmiller
>>>>>> *Cc :* [hidden email]
>>>>>> *Objet :* Re: [R] Genuine relative paths with R
>>>>>> On 10/10/2018 4:42 PM, Olivier GIVAUDAN wrote:
>>>>>>> Why are you not simply double-clicking on 'TestPWD' and choosing to
>>>>>>> execute the file (don't add anything)?
>>>>>>> Are you executing the file from a terminal?
>>>>>>
>>>>>> Yes, I was executing the file from my terminal.  Otherwise I really have
>>>>>> no idea what the "current directory" is in the Finder.   (I'm on a Mac.
>>>>>> I just tried the click method; it printed my home directory, not the
>>>>>> directory of the script.)
>>>>>>
>>>>>> I don't know the name of your visual front end, but you are displaying
>>>>>> the working directory that it sets when you click on TestPWD.  That will
>>>>>> be different from the working directory that your user sees in the Terminal.
>>>>>>
>>>>>> You can see what I saw if you run TestPWD from the Terminal.  It will
>>>>>> print the current working directory, not the one where TestPWD happens
>>>>>> to live.
>>>>>>
>>>>>> If you want to do the same sort of thing in R, you could set up a script
>>>>>> that calls R, and execute that in the way you executed TestPWD.  But in
>>>>>> another message you said you aren't allowed to do that, so I think your
>>>>>> best solution is the one offered by Bill Dunlap:  organize your files as
>>>>>> an R package.  If you name your package "Olivier", then you can find all
>>>>>> the files in it under the directory returned by
>>>>>>
>>>>>>     system.file(".", package = "Olivier")
>>>>>>
>>>>>> The package system is designed for R code, but you can put arbitrary
>>>>>> files into a package:  just store them under the "inst" directory in
>>>>>> your source.  When the package is installed, those files will be moved
>>>>>> up one level, i.e.
>>>>>>
>>>>>> Olivier/inst/foo
>>>>>>
>>>>>> will become
>>>>>>
>>>>>>     system.file("foo", package = "Olivier")
>>>>>>
>>>>>> Duncan Murdoch
>>>>>
>>>>
>>>
>>
>

______________________________________________
[hidden email] mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
Reply | Threaded
Open this post in threaded view
|

Re: Genuine relative paths with R

Michael Friendly
In reply to this post by Olivier GIVAUDAN
Olivier:

Readers of R-Help generally are patient and try to be helpful. Numerous
solutions to your initial query were proposed, but for some reason you
either reject them or take the discussion down some different rabbit
hole of claims about R vs. other software environments, to which kind
people reply and you then rebut. ENOUGH ALREADY.  This thread has been
going on for nearly a week. Choose something that
works for you, have a cup of tea, go for a run, get a life.
Please do not bother to reply.

-Michael

On 10/10/2018 8:08 PM, Olivier GIVAUDAN wrote:

> I think Gabor (at least) already suggested this solution. But the problem is: how do you source this file containing this 'foo' function without writing its absolute path?
>
> It's a kind of initialisation issue.
>
>> a function returning the path of the R file where this same function was invoked.
>>> I didn't realize that's what you were asking for. This has nothing to do with your subject line.
>
> It's just a trick to work with relative paths without having to write any hardcoded (by definition) absolute path beforehand.
> ________________________________
> De : Duncan Murdoch <[hidden email]>
> Envoy� : mercredi 10 octobre 2018 23:51
> � : Olivier GIVAUDAN; Jeff Newmiller
> Cc : [hidden email]
> Objet : Re: [R] Genuine relative paths with R
>
> On 10/10/2018 7:11 PM, Olivier GIVAUDAN wrote:
>> It is not wrong to claim that R currently doesn't have a function
>> returning the path of the R file where this same function was invoked.
>
> But it does.  I didn't realize that's what you were asking for.  This
> has nothing to do with your subject line.
>
> If you source a file from somewhere, then each of the functions it
> creates is marked with its source location.  So you can put this in a file:
>
> foo <- function () 1
>
> filename <- normalizePath(getSrcFilename(foo, full.names=TRUE))
>
> (You need the normalizePath() call because all that will be saved is the
> path that was used.  If it was a relative path, that's what you get
> before you normalize it.  You don't really need the foo function; you
> could put an anonymous function into the getSrcFilename call.  It's just
> usually easier to include a function that already exists.)
>
> When you source() that file, filename will get the name of the file it
> came from.
>
> This is a lot like __FILE__ in C.  One difference is that it is usually
> turned off when the function is being loaded into a package, but you can
> optionally turn it on.
>
> You can also find out what line foo starts on, using
>
> fooline <- getSrcLocation(foo)
>
> This is a lot like __LINE__ in C.
>
> Duncan Murdoch
>
>
>>
>> 'getwd()' is indeed not equivalent to VBA
>> 'Application.ThisWorkbook.Path' or C macro '__FILE__' or SAS
>> %sysget(SAS_EXECFILENAME), etc.
>> ------------------------------------------------------------------------
>> *De :* Duncan Murdoch <[hidden email]>
>> *Envoy� :* mercredi 10 octobre 2018 22:59
>> *� :* Olivier GIVAUDAN; Jeff Newmiller
>> *Cc :* [hidden email]
>> *Objet :* Re: [R] Genuine relative paths with R
>> On 10/10/2018 6:52 PM, Olivier GIVAUDAN wrote:
>>>>   Again, you seem to think making a package is a big deal.
>>>
>>> Perhaps not a big deal (I believe you, I didn't write an R package yet),
>>> but not as straightforward as having a function within an R file
>>> returning its own path.
>>>
>>>> But you're free to decide not to do it:  just please don't repeat
>>> falseclaims about R (like the ones about paths that started this long
>>> thread).
>>>
>>> Which false claims?
>>
>> "But I am really wondering why R doesn't have (please tell me if I'm
>> wrong) this basic feature as many other languages have it (batch, shell,
>> C, LaTeX, SAS with macro-variables, etc.)?"
>>
>> Duncan Murdoch
>>
>>> ------------------------------------------------------------------------
>>> *De :* Duncan Murdoch <[hidden email]>
>>> *Envoy� :* mercredi 10 octobre 2018 22:31
>>> *� :* Olivier GIVAUDAN; Jeff Newmiller
>>> *Cc :* [hidden email]
>>> *Objet :* Re: [R] Genuine relative paths with R
>>> On 10/10/2018 6:17 PM, Olivier GIVAUDAN wrote:
>>>>> Nothing says a package has to go on CRAN.  You can distribute
>>>> themprivately to a small audience.
>>>>
>>>> Yes, I agree in theory. But this solution still violates my own
>>>> proportionality principle.
>>>
>>> Again, you seem to think making a package is a big deal.  Maybe that was
>>> true 10 years ago (though I wrote and tested a package in a 45 minute
>>> presentation at UseR 2008), but now it's very easy.
>>>
>>> But you're free to decide not to do it:  just please don't repeat false
>>> claims about R (like the ones about paths that started this long thread).
>>>
>>>>
>>>>> If you know as much about R as the people who wrote it
>>>>
>>>> I didn't claim that (that's was a quite general / theoretical statement,
>>>> not necessarily and only applicable to R).
>>>
>>> I didn't say you made that claim.  I was answering your question about
>>> why inventing your own way is not a good idea.  It might be a good idea,
>>> if you know the system very, very well.  Otherwise, it's probably better
>>> to work the standard way.
>>>
>>> Duncan Murdoch
>>>
>>>>
>>>>> For example, you might thinkthat all front ends set the working
>>>> directory to the directory of theprogram they are running, because the
>>>> ones you've tried do it that way. But they don't.
>>>>
>
>
>>>> GUIs. So the workaround I finally found satisfies my current needs
>>>> ------------------------------------------------------------------------
>>>> *De :* Duncan Murdoch <[hidden email]>
>>>> *Envoy� :* mercredi 10 octobre 2018 22:07
>>>> *� :* Olivier GIVAUDAN; Jeff Newmiller
>>>> *Cc :* [hidden email]
>>>> *Objet :* Re: [R] Genuine relative paths with R
>>>> On 10/10/2018 5:45 PM, Olivier GIVAUDAN wrote:
>>>>> I'm not sure I'm "inventing my own way" of distributing R code... And I
>>>>> distribute it to a very limited audience.
>>>>
>>>> Nothing says a package has to go on CRAN.  You can distribute them
>>>> privately to a small audience.
>>>>
>>>>> Anyway, why not "inventing a new way" if it's more efficient than the
>>>>> standard one (I'm talking now in theory)?
>>>>
>>>> If you know as much about R as the people who wrote it, then you can
>>>> almost certainly invent better ways to do many of the things it does.  R
>>>> Core was constrained by trying to maintain back compatibility, and that
>>>> means some of their solutions aren't perfect.
>>>>
>>>> But if you don't know it that well, chances are you'll make mistakes
>>>> when you invent your own way of doing it.  For example, you might think
>>>> that all front ends set the working directory to the directory of the
>>>> program they are running, because the ones you've tried do it that way.
>>>> But they don't.
>>>>
>>>> Duncan Murdoch
>>>>
>>>>> ------------------------------------------------------------------------
>>>>> *De :* Duncan Murdoch <[hidden email]>
>>>>> *Envoy� :* mercredi 10 octobre 2018 21:39
>>>>> *� :* Olivier GIVAUDAN; Jeff Newmiller
>>>>> *Cc :* [hidden email]
>>>>> *Objet :* Re: [R] Genuine relative paths with R
>>>>> On 10/10/2018 5:31 PM, Olivier GIVAUDAN wrote:
>>>>>> I do not want to use the terminal, just double clicks (i.e. the
>>>>>> simplest, automatic, non-manual way, without having to write a line /
>>>>>> command).
>>>>>> Therefore everything should happen outside any terminal. The user won't
>>>>>> use a terminal.
>>>>>>
>>>>>> I don't have a Mac and I'm not familiar with this OS, sorry.
>>>>>> But I'm really surprised the click method gives different results than
>
>>>>>> I know the click method worked both on Linux (Ubuntu latest version) and
>
>>>>>>
>>>>>> Yes, I executed my file from a terminal and got obviously the same
>>>>>> result as you (that's reassuring).
>>>>>>
>>>>>> Come on guys, creating a package... It's like using a hammer to kill a
>>>>>> fly...
>>>>>
>>>>> It's a simple operation to create a package in RStudio.  Not quite a
>>>>> single click, but just a few.
>>>>>
>>>>> In plain R, it's just a little more work using package.skeleton().
>>>>>
>>>>> Really, if you are distributing R code, you should do it in the standard
>>>>> way, not invent your own.
>>>>>
>>>>> Duncan Murdoch
>>>>>
>>>>>> ------------------------------------------------------------------------
>>>>>> *De :* Duncan Murdoch <[hidden email]>
>>>>>> *Envoy� :* mercredi 10 octobre 2018 20:54
>>>>>> *� :* Olivier GIVAUDAN; Jeff Newmiller
>>>>>> *Cc :* [hidden email]
>>>>>> *Objet :* Re: [R] Genuine relative paths with R
>>>>>> On 10/10/2018 4:42 PM, Olivier GIVAUDAN wrote:
>>>>>>> Why are you not simply double-clicking on 'TestPWD' and choosing to
>>>>>>> execute the file (don't add anything)?
>>>>>>> Are you executing the file from a terminal?
>>>>>>
>>>>>> Yes, I was executing the file from my terminal.  Otherwise I really have
>>>>>> no idea what the "current directory" is in the Finder.   (I'm on a Mac.
>>>>>> I just tried the click method; it printed my home directory, not the
>>>>>> directory of the script.)
>>>>>>
>>>>>> I don't know the name of your visual front end, but you are displaying
>>>>>> the working directory that it sets when you click on TestPWD.  That will
>>>>>> be different from the working directory that your user sees in the Terminal.
>>>>>>
>>>>>> You can see what I saw if you run TestPWD from the Terminal.  It will
>>>>>> print the current working directory, not the one where TestPWD happens
>>>>>> to live.
>>>>>>
>>>>>> If you want to do the same sort of thing in R, you could set up a script
>>>>>> that calls R, and execute that in the way you executed TestPWD.  But in
>>>>>> another message you said you aren't allowed to do that, so I think your
>>>>>> best solution is the one offered by Bill Dunlap:  organize your files as
>>>>>> an R package.  If you name your package "Olivier", then you can find all
>>>>>> the files in it under the directory returned by
>>>>>>
>>>>>>      system.file(".", package = "Olivier")
>>>>>>
>>>>>> The package system is designed for R code, but you can put arbitrary
>>>>>> files into a package:  just store them under the "inst" directory in
>>>>>> your source.  When the package is installed, those files will be moved
>>>>>> up one level, i.e.
>>>>>>
>>>>>> Olivier/inst/foo
>>>>>>
>>>>>> will become
>>>>>>
>>>>>>      system.file("foo", package = "Olivier")
>>>>>>
>>>>>> Duncan Murdoch
>>>>>
>>>>
>>>
>>
>
>
> [[alternative HTML version deleted]]
>
>
>

______________________________________________
[hidden email] mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
Reply | Threaded
Open this post in threaded view
|

Re: Genuine relative paths with R

Olivier GIVAUDAN
In reply to this post by Fritsch, Katharina (NNL)
Hi Katharina,

Apologies for the late reply.

Thank you for your proposal which was not made yet.

That's actually a Shiny app which I am working on. The problem is that the data are confidential: except when I share the R codes and data (via a marvelous secured SharePoint system...), the data should stay local.

When looking at [1], it seems inevitable that the data are published to a third-party server, which I want to avoid.

But I will look into it more closely, esp. whether it is possible to segregate the sharing of R codes / Shiny app (to the server, no problem) and data (only local).

Best regards,

Olivier

​[1] https://shiny.rstudio.com/articles/deployment-local.html
________________________________
De : Fritsch, Katharina (NNL) <[hidden email]>
Envoyé : jeudi 11 octobre 2018 08:22
À : Olivier GIVAUDAN; Peter Claussen
Cc : [hidden email]
Objet : RE: [R] Genuine relative paths with R

Hiya,
I have lost track of half the discussion so forgive me if that suggestion has been made before, but would it be suitable to wrap your code in a shiny app and disseminate it this way?
Kind regards,
Katharina.

--

Dr Katharina Fritsch B.Sc. M.Sc. MRSC
Chemical Modeller, Chemical and Process Modelling


E.
[hidden email]
T.
+44 (0)1925 289387
@uknnl

National Nuclear Laboratory Limited, 5th Floor, Chadwick House,
Birchwood Park, Warrington, WA3 6AE, UK

www.nnl.co.uk<http://www.nnl.co.uk>

-----Original Message-----
From: R-help [mailto:[hidden email]] On Behalf Of Olivier GIVAUDAN
Sent: 11 October 2018 00:54
To: Peter Claussen
Cc: [hidden email]
Subject: Re: [R] Genuine relative paths with R

Yes, I am aware that both '__FILE__' and 'SAS_EXECFILENAME' are macro variables. I don't know how the VBA 'Application.ThisWorkbook.Path' VBA or PHP '__DIR__' (or '__FILE__') work.

And yes, indeed, until now I didn't even realise that this simple find-and-replace solution of "mine" is actually the basic job of a preprocessor when it expands macro variables, thank you!

A macro language in R, yes, I think it would be useful, at least for this function. If nothing simpler is available, of course...
________________________________
De : Peter Claussen <[hidden email]> Envoy  : mercredi 10 octobre 2018 23:29   : Olivier GIVAUDAN Cc : Duncan Murdoch; Jeff Newmiller; [hidden email] Objet : Re: [R] Genuine relative paths with R

If I m following all this correctly, it seems your criticism is that R doesn t provide a run-time function that is equivalent to a compile-time macro. You do realize that __FILE__ is not part of the C programming language - it s a predefined variable recognized by the cpp - the C preprocessor program. Similarly, SAS_EXECFILENAME is a predefined variable that can be recognized by the SAS macro processor, but has no meaning in the SAS language itself.

So, to go back to your original post:
1.  Either create a variable "ScriptPath" in the first lines of each of my R scripts and run a batch (or shell, etc.) to replace every single occurrence of "ScriptPath <-" by "ScriptPath <- [Absolute path of the R script]" in all the R scripts located in the folder (and possibly subfolders) of the batch file.

This is what a macro processor does. Are you asking for a macro language in R?

Cheers

On Oct 10, 2018, at 6:11 PM, Olivier GIVAUDAN <[hidden email]<mailto:[hidden email]>> wrote:

It is not wrong to claim that R currently doesn't have a function returning the path of the R file where this same function was invoked.

'getwd()' is indeed not equivalent to VBA 'Application.ThisWorkbook.Path' or C macro '__FILE__' or SAS %sysget(SAS_EXECFILENAME), etc.


        [[alternative HTML version deleted]]


This e-mail is from National Nuclear Laboratory Limited ("NNL"). This e-mail and any attachments are intended for the addressee and may also be legally privileged. If you are not the intended recipient please do not print, re-transmit, store or act in reliance on it or any attachments. Instead, please e-mail it back to the sender and then immediately permanently delete it.

National Nuclear Laboratory Limited (Company number 3857752) Registered in England and Wales. Registered office: Chadwick House, Warrington Road, Birchwood Park, Warrington, WA3 6AE.

        [[alternative HTML version deleted]]

______________________________________________
[hidden email] mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
Reply | Threaded
Open this post in threaded view
|

Re: Genuine relative paths with R

Olivier GIVAUDAN
In reply to this post by Duncan Murdoch-2
OK, but the usual question remains: how to set the working directory automatically / dynamically?
________________________________
De : Duncan Murdoch <[hidden email]>
Envoy� : jeudi 11 octobre 2018 09:27
� : Olivier GIVAUDAN; Jeff Newmiller
Cc : [hidden email]
Objet : Re: [R] Genuine relative paths with R

On 10/10/2018 8:08 PM, Olivier GIVAUDAN wrote:
> I think Gabor (at least) already suggested this solution. But the
> problem is: how do you source this file containing this 'foo' function
> without writing its absolute path?

You only need its relative path to source it.

Duncan Murdoch

>
> It's a kind of initialisation issue.
>
>  > a function returning the path of the R file where this same function
> was invoked.
>  >> I didn't realize that's what you were asking for. This has nothing
> to do with your subject line.
>
> It's just a trick to work with relative paths without having to write
> any hardcoded (by definition) absolute path beforehand.
> ------------------------------------------------------------------------
> *De :* Duncan Murdoch <[hidden email]>
> *Envoy� :* mercredi 10 octobre 2018 23:51
> *� :* Olivier GIVAUDAN; Jeff Newmiller
> *Cc :* [hidden email]
> *Objet :* Re: [R] Genuine relative paths with R
> On 10/10/2018 7:11 PM, Olivier GIVAUDAN wrote:
>> It is not wrong to claim that R currently doesn't have a function
>> returning the path of the R file where this same function was invoked.
>
> But it does.  I didn't realize that's what you were asking for.  This
> has nothing to do with your subject line.
>
> If you source a file from somewhere, then each of the functions it
> creates is marked with its source location.  So you can put this in a file:
>
> foo <- function () 1
>
> filename <- normalizePath(getSrcFilename(foo, full.names=TRUE))
>
> (You need the normalizePath() call because all that will be saved is the
> path that was used.  If it was a relative path, that's what you get
> before you normalize it.  You don't really need the foo function; you
> could put an anonymous function into the getSrcFilename call.  It's just
> usually easier to include a function that already exists.)
>
> When you source() that file, filename will get the name of the file it
> came from.
>
> This is a lot like __FILE__ in C.  One difference is that it is usually
> turned off when the function is being loaded into a package, but you can
> optionally turn it on.
>
> You can also find out what line foo starts on, using
>
> fooline <- getSrcLocation(foo)
>
> This is a lot like __LINE__ in C.
>
> Duncan Murdoch
>
>
>>
>> 'getwd()' is indeed not equivalent to VBA
>> 'Application.ThisWorkbook.Path' or C macro '__FILE__' or SAS
>> %sysget(SAS_EXECFILENAME), etc.
>> ------------------------------------------------------------------------
>> *De :* Duncan Murdoch <[hidden email]>
>> *Envoy� :* mercredi 10 octobre 2018 22:59
>> *� :* Olivier GIVAUDAN; Jeff Newmiller
>> *Cc :* [hidden email]
>> *Objet :* Re: [R] Genuine relative paths with R
>> On 10/10/2018 6:52 PM, Olivier GIVAUDAN wrote:
>>>>  Again, you seem to think making a package is a big deal.
>>>
>>> Perhaps not a big deal (I believe you, I didn't write an R package yet),
>>> but not as straightforward as having a function within an R file
>>> returning its own path.
>>>
>>>> But you're free to decide not to do it:  just please don't repeat
>>> falseclaims about R (like the ones about paths that started this long
>>> thread).
>>>
>>> Which false claims?
>>
>> "But I am really wondering why R doesn't have (please tell me if I'm
>> wrong) this basic feature as many other languages have it (batch, shell,
>> C, LaTeX, SAS with macro-variables, etc.)?"
>>
>> Duncan Murdoch
>>
>>> ------------------------------------------------------------------------
>>> *De :* Duncan Murdoch <[hidden email]>
>>> *Envoy� :* mercredi 10 octobre 2018 22:31
>>> *� :* Olivier GIVAUDAN; Jeff Newmiller
>>> *Cc :* [hidden email]
>>> *Objet :* Re: [R] Genuine relative paths with R
>>> On 10/10/2018 6:17 PM, Olivier GIVAUDAN wrote:
>>>>> Nothing says a package has to go on CRAN.  You can distribute
>>>> themprivately to a small audience.
>>>>
>>>> Yes, I agree in theory. But this solution still violates my own
>>>> proportionality principle.
>>>
>>> Again, you seem to think making a package is a big deal.  Maybe that was
>>> true 10 years ago (though I wrote and tested a package in a 45 minute
>>> presentation at UseR 2008), but now it's very easy.
>>>
>>> But you're free to decide not to do it:  just please don't repeat false
>>> claims about R (like the ones about paths that started this long thread).
>>>
>>>>
>>>>> If you know as much about R as the people who wrote it
>>>>
>>>> I didn't claim that (that's was a quite general / theoretical statement,
>>>> not necessarily and only applicable to R).
>>>
>>> I didn't say you made that claim.  I was answering your question about
>>> why inventing your own way is not a good idea.  It might be a good idea,
>>> if you know the system very, very well.  Otherwise, it's probably better
>>> to work the standard way.
>>>
>>> Duncan Murdoch
>>>
>>>>
>>>>> For example, you might thinkthat all front ends set the working
>>>> directory to the directory of theprogram they are running, because the
>>>> ones you've tried do it that way. But they don't.
>>>>

 2

>>>> GUIs. So the workaround I finally found satisfies my current needs
>>>> ------------------------------------------------------------------------
>>>> *De :* Duncan Murdoch <[hidden email]>
>>>> *Envoy� :* mercredi 10 octobre 2018 22:07
>>>> *� :* Olivier GIVAUDAN; Jeff Newmiller
>>>> *Cc :* [hidden email]
>>>> *Objet :* Re: [R] Genuine relative paths with R
>>>> On 10/10/2018 5:45 PM, Olivier GIVAUDAN wrote:
>>>>> I'm not sure I'm "inventing my own way" of distributing R code... And I
>>>>> distribute it to a very limited audience.
>>>>
>>>> Nothing says a package has to go on CRAN.  You can distribute them
>>>> privately to a small audience.
>>>>
>>>>> Anyway, why not "inventing a new way" if it's more efficient than the
>>>>> standard one (I'm talking now in theory)?
>>>>
>>>> If you know as much about R as the people who wrote it, then you can
>>>> almost certainly invent better ways to do many of the things it does.  R
>>>> Core was constrained by trying to maintain back compatibility, and that
>>>> means some of their solutions aren't perfect.
>>>>
>>>> But if you don't know it that well, chances are you'll make mistakes
>>>> when you invent your own way of doing it.  For example, you might think
>>>> that all front ends set the working directory to the directory of the
>>>> program they are running, because the ones you've tried do it that way.
>>>> But they don't.
>>>>
>>>> Duncan Murdoch
>>>>
>>>>> ------------------------------------------------------------------------
>>>>> *De :* Duncan Murdoch <[hidden email]>
>>>>> *Envoy� :* mercredi 10 octobre 2018 21:39
>>>>> *� :* Olivier GIVAUDAN; Jeff Newmiller
>>>>> *Cc :* [hidden email]
>>>>> *Objet :* Re: [R] Genuine relative paths with R
>>>>> On 10/10/2018 5:31 PM, Olivier GIVAUDAN wrote:
>>>>>> I do not want to use the terminal, just double clicks (i.e. the
>>>>>> simplest, automatic, non-manual way, without having to write a line /
>>>>>> command).
>>>>>> Therefore everything should happen outside any terminal. The user won't
>>>>>> use a terminal.
>>>>>>
>>>>>> I don't have a Mac and I'm not familiar with this OS, sorry.
>>>>>> But I'm really surprised the click method gives different results than

>>>>>> I know the click method worked both on Linux (Ubuntu latest version) and

>>>>>>
>>>>>> Yes, I executed my file from a terminal and got obviously the same
>>>>>> result as you (that's reassuring).
>>>>>>
>>>>>> Come on guys, creating a package... It's like using a hammer to kill a
>>>>>> fly...
>>>>>
>>>>> It's a simple operation to create a package in RStudio.  Not quite a
>>>>> single click, but just a few.
>>>>>
>>>>> In plain R, it's just a little more work using package.skeleton().
>>>>>
>>>>> Really, if you are distributing R code, you should do it in the standard
>>>>> way, not invent your own.
>>>>>
>>>>> Duncan Murdoch
>>>>>
>>>>>> ------------------------------------------------------------------------
>>>>>> *De :* Duncan Murdoch <[hidden email]>
>>>>>> *Envoy� :* mercredi 10 octobre 2018 20:54
>>>>>> *� :* Olivier GIVAUDAN; Jeff Newmiller
>>>>>> *Cc :* [hidden email]
>>>>>> *Objet :* Re: [R] Genuine relative paths with R
>>>>>> On 10/10/2018 4:42 PM, Olivier GIVAUDAN wrote:
>>>>>>> Why are you not simply double-clicking on 'TestPWD' and choosing to
>>>>>>> execute the file (don't add anything)?
>>>>>>> Are you executing the file from a terminal?
>>>>>>
>>>>>> Yes, I was executing the file from my terminal.  Otherwise I really have
>>>>>> no idea what the "current directory" is in the Finder.   (I'm on a Mac.
>>>>>> I just tried the click method; it printed my home directory, not the
>>>>>> directory of the script.)
>>>>>>
>>>>>> I don't know the name of your visual front end, but you are displaying
>>>>>> the working directory that it sets when you click on TestPWD.  That will
>>>>>> be different from the working directory that your user sees in the Terminal.
>>>>>>
>>>>>> You can see what I saw if you run TestPWD from the Terminal.  It will
>>>>>> print the current working directory, not the one where TestPWD happens
>>>>>> to live.
>>>>>>
>>>>>> If you want to do the same sort of thing in R, you could set up a script
>>>>>> that calls R, and execute that in the way you executed TestPWD.  But in
>>>>>> another message you said you aren't allowed to do that, so I think your
>>>>>> best solution is the one offered by Bill Dunlap:  organize your files as
>>>>>> an R package.  If you name your package "Olivier", then you can find all
>>>>>> the files in it under the directory returned by
>>>>>>
>>>>>>     system.file(".", package = "Olivier")
>>>>>>
>>>>>> The package system is designed for R code, but you can put arbitrary
>>>>>> files into a package:  just store them under the "inst" directory in
>>>>>> your source.  When the package is installed, those files will be moved
>>>>>> up one level, i.e.
>>>>>>
>>>>>> Olivier/inst/foo
>>>>>>
>>>>>> will become
>>>>>>
>>>>>>     system.file("foo", package = "Olivier")
>>>>>>
>>>>>> Duncan Murdoch
>>>>>
>>>>
>>>
>>
>

        [[alternative HTML version deleted]]


______________________________________________
[hidden email] mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
Reply | Threaded
Open this post in threaded view
|

Re: Genuine relative paths with R

Olivier GIVAUDAN
In reply to this post by Michael Friendly
Hi Michael,

Apologies for the late reply.

I am very grateful to all the R users who generously spent time on my problem and suggested operational solutions.

It seems you didn't follow carefully this thread (which I can understand of course) as 2 operational solutions were already suggested and successfully implemented from my side.

So, to summarise:


  1.  The most universal (i.e. it works on Windows and Linux, grateful if someone on Mac could check) solution, when working with the graphical shell system of an OS, is to create a Rproject file at the root of the project and open it with RStudio: the working directory will be automatically set to the location where this Rproject file is;
  2.  Only on Windows (at first sight): Create an empty .RData (with a proper basename) at the root of the project and open it (it should be by default associated to / opened by the default R GUI): the working directory will be automatically set to the location where this instrumental / dummy RData file is.

I didn't invest more time to look more thoroughly into the other solution suggested by Peter Claussen on macro language.

Again thanks to all of you and special thanks to Jeff Newmiller for his patience and for having shared this "trick" with .RData file.

Best regards,

Olivier
________________________________
De : Michael Friendly <[hidden email]>
Envoyé : jeudi 11 octobre 2018 13:08
À : Olivier GIVAUDAN; Duncan Murdoch; Jeff Newmiller
Cc : [hidden email]
Objet : Re: Genuine relative paths with R

Olivier:

Readers of R-Help generally are patient and try to be helpful. Numerous
solutions to your initial query were proposed, but for some reason you
either reject them or take the discussion down some different rabbit
hole of claims about R vs. other software environments, to which kind
people reply and you then rebut. ENOUGH ALREADY.  This thread has been
going on for nearly a week. Choose something that
works for you, have a cup of tea, go for a run, get a life.
Please do not bother to reply.

-Michael

On 10/10/2018 8:08 PM, Olivier GIVAUDAN wrote:

> I think Gabor (at least) already suggested this solution. But the problem is: how do you source this file containing this 'foo' function without writing its absolute path?
>
> It's a kind of initialisation issue.
>
>> a function returning the path of the R file where this same function was invoked.
>>> I didn't realize that's what you were asking for. This has nothing to do with your subject line.
>
> It's just a trick to work with relative paths without having to write any hardcoded (by definition) absolute path beforehand.
> ________________________________
> De : Duncan Murdoch <[hidden email]>
> Envoy� : mercredi 10 octobre 2018 23:51
> � : Olivier GIVAUDAN; Jeff Newmiller
> Cc : [hidden email]
> Objet : Re: [R] Genuine relative paths with R
>
> On 10/10/2018 7:11 PM, Olivier GIVAUDAN wrote:
>> It is not wrong to claim that R currently doesn't have a function
>> returning the path of the R file where this same function was invoked.
>
> But it does.  I didn't realize that's what you were asking for.  This
> has nothing to do with your subject line.
>
> If you source a file from somewhere, then each of the functions it
> creates is marked with its source location.  So you can put this in a file:
>
> foo <- function () 1
>
> filename <- normalizePath(getSrcFilename(foo, full.names=TRUE))
>
> (You need the normalizePath() call because all that will be saved is the
> path that was used.  If it was a relative path, that's what you get
> before you normalize it.  You don't really need the foo function; you
> could put an anonymous function into the getSrcFilename call.  It's just
> usually easier to include a function that already exists.)
>
> When you source() that file, filename will get the name of the file it
> came from.
>
> This is a lot like __FILE__ in C.  One difference is that it is usually
> turned off when the function is being loaded into a package, but you can
> optionally turn it on.
>
> You can also find out what line foo starts on, using
>
> fooline <- getSrcLocation(foo)
>
> This is a lot like __LINE__ in C.
>
> Duncan Murdoch
>
>
>>
>> 'getwd()' is indeed not equivalent to VBA
>> 'Application.ThisWorkbook.Path' or C macro '__FILE__' or SAS
>> %sysget(SAS_EXECFILENAME), etc.
>> ------------------------------------------------------------------------
>> *De :* Duncan Murdoch <[hidden email]>
>> *Envoy� :* mercredi 10 octobre 2018 22:59
>> *� :* Olivier GIVAUDAN; Jeff Newmiller
>> *Cc :* [hidden email]
>> *Objet :* Re: [R] Genuine relative paths with R
>> On 10/10/2018 6:52 PM, Olivier GIVAUDAN wrote:
>>>>   Again, you seem to think making a package is a big deal.
>>>
>>> Perhaps not a big deal (I believe you, I didn't write an R package yet),
>>> but not as straightforward as having a function within an R file
>>> returning its own path.
>>>
>>>> But you're free to decide not to do it:  just please don't repeat
>>> falseclaims about R (like the ones about paths that started this long
>>> thread).
>>>
>>> Which false claims?
>>
>> "But I am really wondering why R doesn't have (please tell me if I'm
>> wrong) this basic feature as many other languages have it (batch, shell,
>> C, LaTeX, SAS with macro-variables, etc.)?"
>>
>> Duncan Murdoch
>>
>>> ------------------------------------------------------------------------
>>> *De :* Duncan Murdoch <[hidden email]>
>>> *Envoy� :* mercredi 10 octobre 2018 22:31
>>> *� :* Olivier GIVAUDAN; Jeff Newmiller
>>> *Cc :* [hidden email]
>>> *Objet :* Re: [R] Genuine relative paths with R
>>> On 10/10/2018 6:17 PM, Olivier GIVAUDAN wrote:
>>>>> Nothing says a package has to go on CRAN.  You can distribute
>>>> themprivately to a small audience.
>>>>
>>>> Yes, I agree in theory. But this solution still violates my own
>>>> proportionality principle.
>>>
>>> Again, you seem to think making a package is a big deal.  Maybe that was
>>> true 10 years ago (though I wrote and tested a package in a 45 minute
>>> presentation at UseR 2008), but now it's very easy.
>>>
>>> But you're free to decide not to do it:  just please don't repeat false
>>> claims about R (like the ones about paths that started this long thread).
>>>
>>>>
>>>>> If you know as much about R as the people who wrote it
>>>>
>>>> I didn't claim that (that's was a quite general / theoretical statement,
>>>> not necessarily and only applicable to R).
>>>
>>> I didn't say you made that claim.  I was answering your question about
>>> why inventing your own way is not a good idea.  It might be a good idea,
>>> if you know the system very, very well.  Otherwise, it's probably better
>>> to work the standard way.
>>>
>>> Duncan Murdoch
>>>
>>>>
>>>>> For example, you might thinkthat all front ends set the working
>>>> directory to the directory of theprogram they are running, because the
>>>> ones you've tried do it that way. But they don't.
>>>>
>
>
>>>> GUIs. So the workaround I finally found satisfies my current needs
>>>> ------------------------------------------------------------------------
>>>> *De :* Duncan Murdoch <[hidden email]>
>>>> *Envoy� :* mercredi 10 octobre 2018 22:07
>>>> *� :* Olivier GIVAUDAN; Jeff Newmiller
>>>> *Cc :* [hidden email]
>>>> *Objet :* Re: [R] Genuine relative paths with R
>>>> On 10/10/2018 5:45 PM, Olivier GIVAUDAN wrote:
>>>>> I'm not sure I'm "inventing my own way" of distributing R code... And I
>>>>> distribute it to a very limited audience.
>>>>
>>>> Nothing says a package has to go on CRAN.  You can distribute them
>>>> privately to a small audience.
>>>>
>>>>> Anyway, why not "inventing a new way" if it's more efficient than the
>>>>> standard one (I'm talking now in theory)?
>>>>
>>>> If you know as much about R as the people who wrote it, then you can
>>>> almost certainly invent better ways to do many of the things it does.  R
>>>> Core was constrained by trying to maintain back compatibility, and that
>>>> means some of their solutions aren't perfect.
>>>>
>>>> But if you don't know it that well, chances are you'll make mistakes
>>>> when you invent your own way of doing it.  For example, you might think
>>>> that all front ends set the working directory to the directory of the
>>>> program they are running, because the ones you've tried do it that way.
>>>> But they don't.
>>>>
>>>> Duncan Murdoch
>>>>
>>>>> ------------------------------------------------------------------------
>>>>> *De :* Duncan Murdoch <[hidden email]>
>>>>> *Envoy� :* mercredi 10 octobre 2018 21:39
>>>>> *� :* Olivier GIVAUDAN; Jeff Newmiller
>>>>> *Cc :* [hidden email]
>>>>> *Objet :* Re: [R] Genuine relative paths with R
>>>>> On 10/10/2018 5:31 PM, Olivier GIVAUDAN wrote:
>>>>>> I do not want to use the terminal, just double clicks (i.e. the
>>>>>> simplest, automatic, non-manual way, without having to write a line /
>>>>>> command).
>>>>>> Therefore everything should happen outside any terminal. The user won't
>>>>>> use a terminal.
>>>>>>
>>>>>> I don't have a Mac and I'm not familiar with this OS, sorry.
>>>>>> But I'm really surprised the click method gives different results than
>
>>>>>> I know the click method worked both on Linux (Ubuntu latest version) and
>
>>>>>>
>>>>>> Yes, I executed my file from a terminal and got obviously the same
>>>>>> result as you (that's reassuring).
>>>>>>
>>>>>> Come on guys, creating a package... It's like using a hammer to kill a
>>>>>> fly...
>>>>>
>>>>> It's a simple operation to create a package in RStudio.  Not quite a
>>>>> single click, but just a few.
>>>>>
>>>>> In plain R, it's just a little more work using package.skeleton().
>>>>>
>>>>> Really, if you are distributing R code, you should do it in the standard
>>>>> way, not invent your own.
>>>>>
>>>>> Duncan Murdoch
>>>>>
>>>>>> ------------------------------------------------------------------------
>>>>>> *De :* Duncan Murdoch <[hidden email]>
>>>>>> *Envoy� :* mercredi 10 octobre 2018 20:54
>>>>>> *� :* Olivier GIVAUDAN; Jeff Newmiller
>>>>>> *Cc :* [hidden email]
>>>>>> *Objet :* Re: [R] Genuine relative paths with R
>>>>>> On 10/10/2018 4:42 PM, Olivier GIVAUDAN wrote:
>>>>>>> Why are you not simply double-clicking on 'TestPWD' and choosing to
>>>>>>> execute the file (don't add anything)?
>>>>>>> Are you executing the file from a terminal?
>>>>>>
>>>>>> Yes, I was executing the file from my terminal.  Otherwise I really have
>>>>>> no idea what the "current directory" is in the Finder.   (I'm on a Mac.
>>>>>> I just tried the click method; it printed my home directory, not the
>>>>>> directory of the script.)
>>>>>>
>>>>>> I don't know the name of your visual front end, but you are displaying
>>>>>> the working directory that it sets when you click on TestPWD.  That will
>>>>>> be different from the working directory that your user sees in the Terminal.
>>>>>>
>>>>>> You can see what I saw if you run TestPWD from the Terminal.  It will
>>>>>> print the current working directory, not the one where TestPWD happens
>>>>>> to live.
>>>>>>
>>>>>> If you want to do the same sort of thing in R, you could set up a script
>>>>>> that calls R, and execute that in the way you executed TestPWD.  But in
>>>>>> another message you said you aren't allowed to do that, so I think your
>>>>>> best solution is the one offered by Bill Dunlap:  organize your files as
>>>>>> an R package.  If you name your package "Olivier", then you can find all
>>>>>> the files in it under the directory returned by
>>>>>>
>>>>>>      system.file(".", package = "Olivier")
>>>>>>
>>>>>> The package system is designed for R code, but you can put arbitrary
>>>>>> files into a package:  just store them under the "inst" directory in
>>>>>> your source.  When the package is installed, those files will be moved
>>>>>> up one level, i.e.
>>>>>>
>>>>>> Olivier/inst/foo
>>>>>>
>>>>>> will become
>>>>>>
>>>>>>      system.file("foo", package = "Olivier")
>>>>>>
>>>>>> Duncan Murdoch
>>>>>
>>>>
>>>
>>
>
>
>        [[alternative HTML version deleted]]
>
>
>


        [[alternative HTML version deleted]]

______________________________________________
[hidden email] mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
Reply | Threaded
Open this post in threaded view
|

Re: Genuine relative paths with R

Olivier GIVAUDAN
Sorry, I forgot:

The only regret I have is the title of this thread which is somehow misleading: a more correct one would be "How to set automatically / dynamically the working directory in R?"
________________________________
De : Olivier GIVAUDAN <[hidden email]>
Envoyé : vendredi 19 octobre 2018 05:46
À : Michael Friendly; Duncan Murdoch; Jeff Newmiller
Cc : [hidden email]
Objet : RE: Genuine relative paths with R

Hi Michael,

Apologies for the late reply.

I am very grateful to all the R users who generously spent time on my problem and suggested operational solutions.

It seems you didn't follow carefully this thread (which I can understand of course) as 2 operational solutions were already suggested and successfully implemented from my side.

So, to summarise:


  1.  The most universal (i.e. it works on Windows and Linux, grateful if someone on Mac could check) solution, when working with the graphical shell system of an OS, is to create a Rproject file at the root of the project and open it with RStudio: the working directory will be automatically set to the location where this Rproject file is;
  2.  Only on Windows (at first sight): Create an empty .RData (with a proper basename) at the root of the project and open it (it should be by default associated to / opened by the default R GUI): the working directory will be automatically set to the location where this instrumental / dummy RData file is.

I didn't invest more time to look more thoroughly into the other solution suggested by Peter Claussen on macro language.

Again thanks to all of you and special thanks to Jeff Newmiller for his patience and for having shared this "trick" with .RData file.

Best regards,

Olivier
________________________________
De : Michael Friendly <[hidden email]>
Envoyé : jeudi 11 octobre 2018 13:08
À : Olivier GIVAUDAN; Duncan Murdoch; Jeff Newmiller
Cc : [hidden email]
Objet : Re: Genuine relative paths with R

Olivier:

Readers of R-Help generally are patient and try to be helpful. Numerous
solutions to your initial query were proposed, but for some reason you
either reject them or take the discussion down some different rabbit
hole of claims about R vs. other software environments, to which kind
people reply and you then rebut. ENOUGH ALREADY.  This thread has been
going on for nearly a week. Choose something that
works for you, have a cup of tea, go for a run, get a life.
Please do not bother to reply.

-Michael

On 10/10/2018 8:08 PM, Olivier GIVAUDAN wrote:

> I think Gabor (at least) already suggested this solution. But the problem is: how do you source this file containing this 'foo' function without writing its absolute path?
>
> It's a kind of initialisation issue.
>
>> a function returning the path of the R file where this same function was invoked.
>>> I didn't realize that's what you were asking for. This has nothing to do with your subject line.
>
> It's just a trick to work with relative paths without having to write any hardcoded (by definition) absolute path beforehand.
> ________________________________
> De : Duncan Murdoch <[hidden email]>
> Envoy� : mercredi 10 octobre 2018 23:51
> � : Olivier GIVAUDAN; Jeff Newmiller
> Cc : [hidden email]
> Objet : Re: [R] Genuine relative paths with R
>
> On 10/10/2018 7:11 PM, Olivier GIVAUDAN wrote:
>> It is not wrong to claim that R currently doesn't have a function
>> returning the path of the R file where this same function was invoked.
>
> But it does.  I didn't realize that's what you were asking for.  This
> has nothing to do with your subject line.
>
> If you source a file from somewhere, then each of the functions it
> creates is marked with its source location.  So you can put this in a file:
>
> foo <- function () 1
>
> filename <- normalizePath(getSrcFilename(foo, full.names=TRUE))
>
> (You need the normalizePath() call because all that will be saved is the
> path that was used.  If it was a relative path, that's what you get
> before you normalize it.  You don't really need the foo function; you
> could put an anonymous function into the getSrcFilename call.  It's just
> usually easier to include a function that already exists.)
>
> When you source() that file, filename will get the name of the file it
> came from.
>
> This is a lot like __FILE__ in C.  One difference is that it is usually
> turned off when the function is being loaded into a package, but you can
> optionally turn it on.
>
> You can also find out what line foo starts on, using
>
> fooline <- getSrcLocation(foo)
>
> This is a lot like __LINE__ in C.
>
> Duncan Murdoch
>
>
>>
>> 'getwd()' is indeed not equivalent to VBA
>> 'Application.ThisWorkbook.Path' or C macro '__FILE__' or SAS
>> %sysget(SAS_EXECFILENAME), etc.
>> ------------------------------------------------------------------------
>> *De :* Duncan Murdoch <[hidden email]>
>> *Envoy� :* mercredi 10 octobre 2018 22:59
>> *� :* Olivier GIVAUDAN; Jeff Newmiller
>> *Cc :* [hidden email]
>> *Objet :* Re: [R] Genuine relative paths with R
>> On 10/10/2018 6:52 PM, Olivier GIVAUDAN wrote:
>>>>   Again, you seem to think making a package is a big deal.
>>>
>>> Perhaps not a big deal (I believe you, I didn't write an R package yet),
>>> but not as straightforward as having a function within an R file
>>> returning its own path.
>>>
>>>> But you're free to decide not to do it:  just please don't repeat
>>> falseclaims about R (like the ones about paths that started this long
>>> thread).
>>>
>>> Which false claims?
>>
>> "But I am really wondering why R doesn't have (please tell me if I'm
>> wrong) this basic feature as many other languages have it (batch, shell,
>> C, LaTeX, SAS with macro-variables, etc.)?"
>>
>> Duncan Murdoch
>>
>>> ------------------------------------------------------------------------
>>> *De :* Duncan Murdoch <[hidden email]>
>>> *Envoy� :* mercredi 10 octobre 2018 22:31
>>> *� :* Olivier GIVAUDAN; Jeff Newmiller
>>> *Cc :* [hidden email]
>>> *Objet :* Re: [R] Genuine relative paths with R
>>> On 10/10/2018 6:17 PM, Olivier GIVAUDAN wrote:
>>>>> Nothing says a package has to go on CRAN.  You can distribute
>>>> themprivately to a small audience.
>>>>
>>>> Yes, I agree in theory. But this solution still violates my own
>>>> proportionality principle.
>>>
>>> Again, you seem to think making a package is a big deal.  Maybe that was
>>> true 10 years ago (though I wrote and tested a package in a 45 minute
>>> presentation at UseR 2008), but now it's very easy.
>>>
>>> But you're free to decide not to do it:  just please don't repeat false
>>> claims about R (like the ones about paths that started this long thread).
>>>
>>>>
>>>>> If you know as much about R as the people who wrote it
>>>>
>>>> I didn't claim that (that's was a quite general / theoretical statement,
>>>> not necessarily and only applicable to R).
>>>
>>> I didn't say you made that claim.  I was answering your question about
>>> why inventing your own way is not a good idea.  It might be a good idea,
>>> if you know the system very, very well.  Otherwise, it's probably better
>>> to work the standard way.
>>>
>>> Duncan Murdoch
>>>
>>>>
>>>>> For example, you might thinkthat all front ends set the working
>>>> directory to the directory of theprogram they are running, because the
>>>> ones you've tried do it that way. But they don't.
>>>>
>
>
>>>> GUIs. So the workaround I finally found satisfies my current needs
>>>> ------------------------------------------------------------------------
>>>> *De :* Duncan Murdoch <[hidden email]>
>>>> *Envoy� :* mercredi 10 octobre 2018 22:07
>>>> *� :* Olivier GIVAUDAN; Jeff Newmiller
>>>> *Cc :* [hidden email]
>>>> *Objet :* Re: [R] Genuine relative paths with R
>>>> On 10/10/2018 5:45 PM, Olivier GIVAUDAN wrote:
>>>>> I'm not sure I'm "inventing my own way" of distributing R code... And I
>>>>> distribute it to a very limited audience.
>>>>
>>>> Nothing says a package has to go on CRAN.  You can distribute them
>>>> privately to a small audience.
>>>>
>>>>> Anyway, why not "inventing a new way" if it's more efficient than the
>>>>> standard one (I'm talking now in theory)?
>>>>
>>>> If you know as much about R as the people who wrote it, then you can
>>>> almost certainly invent better ways to do many of the things it does.  R
>>>> Core was constrained by trying to maintain back compatibility, and that
>>>> means some of their solutions aren't perfect.
>>>>
>>>> But if you don't know it that well, chances are you'll make mistakes
>>>> when you invent your own way of doing it.  For example, you might think
>>>> that all front ends set the working directory to the directory of the
>>>> program they are running, because the ones you've tried do it that way.
>>>> But they don't.
>>>>
>>>> Duncan Murdoch
>>>>
>>>>> ------------------------------------------------------------------------
>>>>> *De :* Duncan Murdoch <[hidden email]>
>>>>> *Envoy� :* mercredi 10 octobre 2018 21:39
>>>>> *� :* Olivier GIVAUDAN; Jeff Newmiller
>>>>> *Cc :* [hidden email]
>>>>> *Objet :* Re: [R] Genuine relative paths with R
>>>>> On 10/10/2018 5:31 PM, Olivier GIVAUDAN wrote:
>>>>>> I do not want to use the terminal, just double clicks (i.e. the
>>>>>> simplest, automatic, non-manual way, without having to write a line /
>>>>>> command).
>>>>>> Therefore everything should happen outside any terminal. The user won't
>>>>>> use a terminal.
>>>>>>
>>>>>> I don't have a Mac and I'm not familiar with this OS, sorry.
>>>>>> But I'm really surprised the click method gives different results than
>
>>>>>> I know the click method worked both on Linux (Ubuntu latest version) and
>
>>>>>>
>>>>>> Yes, I executed my file from a terminal and got obviously the same
>>>>>> result as you (that's reassuring).
>>>>>>
>>>>>> Come on guys, creating a package... It's like using a hammer to kill a
>>>>>> fly...
>>>>>
>>>>> It's a simple operation to create a package in RStudio.  Not quite a
>>>>> single click, but just a few.
>>>>>
>>>>> In plain R, it's just a little more work using package.skeleton().
>>>>>
>>>>> Really, if you are distributing R code, you should do it in the standard
>>>>> way, not invent your own.
>>>>>
>>>>> Duncan Murdoch
>>>>>
>>>>>> ------------------------------------------------------------------------
>>>>>> *De :* Duncan Murdoch <[hidden email]>
>>>>>> *Envoy� :* mercredi 10 octobre 2018 20:54
>>>>>> *� :* Olivier GIVAUDAN; Jeff Newmiller
>>>>>> *Cc :* [hidden email]
>>>>>> *Objet :* Re: [R] Genuine relative paths with R
>>>>>> On 10/10/2018 4:42 PM, Olivier GIVAUDAN wrote:
>>>>>>> Why are you not simply double-clicking on 'TestPWD' and choosing to
>>>>>>> execute the file (don't add anything)?
>>>>>>> Are you executing the file from a terminal?
>>>>>>
>>>>>> Yes, I was executing the file from my terminal.  Otherwise I really have
>>>>>> no idea what the "current directory" is in the Finder.   (I'm on a Mac.
>>>>>> I just tried the click method; it printed my home directory, not the
>>>>>> directory of the script.)
>>>>>>
>>>>>> I don't know the name of your visual front end, but you are displaying
>>>>>> the working directory that it sets when you click on TestPWD.  That will
>>>>>> be different from the working directory that your user sees in the Terminal.
>>>>>>
>>>>>> You can see what I saw if you run TestPWD from the Terminal.  It will
>>>>>> print the current working directory, not the one where TestPWD happens
>>>>>> to live.
>>>>>>
>>>>>> If you want to do the same sort of thing in R, you could set up a script
>>>>>> that calls R, and execute that in the way you executed TestPWD.  But in
>>>>>> another message you said you aren't allowed to do that, so I think your
>>>>>> best solution is the one offered by Bill Dunlap:  organize your files as
>>>>>> an R package.  If you name your package "Olivier", then you can find all
>>>>>> the files in it under the directory returned by
>>>>>>
>>>>>>      system.file(".", package = "Olivier")
>>>>>>
>>>>>> The package system is designed for R code, but you can put arbitrary
>>>>>> files into a package:  just store them under the "inst" directory in
>>>>>> your source.  When the package is installed, those files will be moved
>>>>>> up one level, i.e.
>>>>>>
>>>>>> Olivier/inst/foo
>>>>>>
>>>>>> will become
>>>>>>
>>>>>>      system.file("foo", package = "Olivier")
>>>>>>
>>>>>> Duncan Murdoch
>>>>>
>>>>
>>>
>>
>
>
>        [[alternative HTML version deleted]]
>
>
>


        [[alternative HTML version deleted]]

______________________________________________
[hidden email] mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
Reply | Threaded
Open this post in threaded view
|

Re: Genuine relative paths with R

Fritsch, Katharina (NNL)
In reply to this post by Olivier GIVAUDAN
Hello Olivier,
You can definitely use Shiny Server to share data and apps on a server you (or the people who asked you to share the data) own and which is only accessible from specified networks. I’ve personally contributed R code to exactly such a project that involved confidential data.
Kind regards,
Katharina.

--

Dr Katharina Fritsch B.Sc. M.Sc. MRSC
Chemical Modeller, Chemical and Process Modelling


E.
[hidden email]
T.
+44 (0)1925 289387
@uknnl

National Nuclear Laboratory Limited, 5th Floor, Chadwick House,
Birchwood Park, Warrington, WA3 6AE, UK

www.nnl.co.uk

From: Olivier GIVAUDAN [mailto:[hidden email]]
Sent: 19 October 2018 06:26
To: Fritsch, Katharina (NNL); Peter Claussen
Cc: [hidden email]
Subject: RE: [R] Genuine relative paths with R

Hi Katharina,

Apologies for the late reply.

Thank you for your proposal which was not made yet.

That's actually a Shiny app which I am working on. The problem is that the data are confidential: except when I share the R codes and data (via a marvelous secured SharePoint system...), the data should stay local.

When looking at [1], it seems inevitable that the data are published to a third-party server, which I want to avoid.

But I will look into it more closely, esp. whether it is possible to segregate the sharing of R codes / Shiny app (to the server, no problem) and data (only local).

Best regards,

Olivier

​[1] BLOCKEDshiny[.]rstudio[.]com/articles/deployment-local[.]htmlBLOCKED
________________________________________
De : Fritsch, Katharina (NNL) <[hidden email]>
Envoyé : jeudi 11 octobre 2018 08:22
À : Olivier GIVAUDAN; Peter Claussen
Cc : [hidden email]
Objet : RE: [R] Genuine relative paths with R

Hiya,
I have lost track of half the discussion so forgive me if that suggestion has been made before, but would it be suitable to wrap your code in a shiny app and disseminate it this way?
Kind regards,
Katharina.

--

Dr Katharina Fritsch B.Sc. M.Sc. MRSC
Chemical Modeller, Chemical and Process Modelling


E.
[hidden email]
T.
+44 (0)1925 289387
@uknnl

National Nuclear Laboratory Limited, 5th Floor, Chadwick House,
Birchwood Park, Warrington, WA3 6AE, UK

BLOCKEDnnl[.]co[.]ukBLOCKED

-----Original Message-----
From: R-help [mailto:[hidden email]] On Behalf Of Olivier GIVAUDAN
Sent: 11 October 2018 00:54
To: Peter Claussen
Cc: [hidden email]
Subject: Re: [R] Genuine relative paths with R

Yes, I am aware that both '__FILE__' and 'SAS_EXECFILENAME' are macro variables. I don't know how the VBA 'Application.ThisWorkbook.Path' VBA or PHP '__DIR__' (or '__FILE__') work.

And yes, indeed, until now I didn't even realise that this simple find-and-replace solution of "mine" is actually the basic job of a preprocessor when it expands macro variables, thank you!

A macro language in R, yes, I think it would be useful, at least for this function. If nothing simpler is available, of course...
________________________________
De : Peter Claussen <[hidden email]> Envoy  : mercredi 10 octobre 2018 23:29   : Olivier GIVAUDAN Cc : Duncan Murdoch; Jeff Newmiller; [hidden email] Objet : Re: [R] Genuine relative paths with R

If I m following all this correctly, it seems your criticism is that R doesn t provide a run-time function that is equivalent to a compile-time macro. You do realize that __FILE__ is not part of the C programming language - it s a predefined variable recognized by the cpp - the C preprocessor program. Similarly, SAS_EXECFILENAME is a predefined variable that can be recognized by the SAS macro processor, but has no meaning in the SAS language itself.

So, to go back to your original post:
1.  Either create a variable "ScriptPath" in the first lines of each of my R scripts and run a batch (or shell, etc.) to replace every single occurrence of "ScriptPath <-" by "ScriptPath <- [Absolute path of the R script]" in all the R scripts located in the folder (and possibly subfolders) of the batch file.

This is what a macro processor does. Are you asking for a macro language in R?

Cheers

On Oct 10, 2018, at 6:11 PM, Olivier GIVAUDAN <[hidden email]<mailto:[hidden email]>> wrote:

It is not wrong to claim that R currently doesn't have a function returning the path of the R file where this same function was invoked.

'getwd()' is indeed not equivalent to VBA 'Application.ThisWorkbook.Path' or C macro '__FILE__' or SAS %sysget(SAS_EXECFILENAME), etc.


        [[alternative HTML version deleted]]


This e-mail is from National Nuclear Laboratory Limited ("NNL"). This e-mail and any attachments are intended for the addressee and may also be legally privileged. If you are not the intended recipient please do not print, re-transmit, store or act in reliance on it or any attachments. Instead, please e-mail it back to the sender and then immediately permanently delete it.

National Nuclear Laboratory Limited (Company number 3857752) Registered in England and Wales. Registered office: Chadwick House, Warrington Road, Birchwood Park, Warrington, WA3 6AE.

*****************************************************************************
This message was received by the Cloud Security Email Gateway

and was checked for Viruses and SPAM by the Cloud Security Email Management Service.
Please forward any suspicious or unwanted emails to "Spam Helpdesk"
*****************************************************************************

This e-mail is from National Nuclear Laboratory Limited ("NNL"). This e-mail and any attachments are intended for the addressee and may also be legally privileged. If you are not the intended recipient please do not print, re-transmit, store or act in reliance on it or any attachments. Instead, please e-mail it back to the sender and then immediately permanently delete it.

National Nuclear Laboratory Limited (Company number 3857752) Registered in England and Wales. Registered office: Chadwick House, Warrington Road, Birchwood Park, Warrington, WA3 6AE.
______________________________________________
[hidden email] mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
Reply | Threaded
Open this post in threaded view
|

Re: Genuine relative paths with R

Olivier GIVAUDAN
Hello Katharina,

Indeed, I forgot this solution to have your own server, probably because in my organisation this is not an option, yet.​

I'm pushing for that in our organisation for months now but there is quite some resistance and heavy processes around that, and ultimately I'm not deciding on that unfortunately...​

That would be for me the ideal solution.​

Best regards,​

Olivier
________________________________
De : Fritsch, Katharina (NNL) <[hidden email]>
Envoyé : vendredi 19 octobre 2018 08:08
À : Olivier GIVAUDAN
Cc : [hidden email]
Objet : RE: [R] Genuine relative paths with R

Hello Olivier,
You can definitely use Shiny Server to share data and apps on a server you (or the people who asked you to share the data) own and which is only accessible from specified networks. I’ve personally contributed R code to exactly such a project that involved confidential data.
Kind regards,
Katharina.

--

Dr Katharina Fritsch B.Sc. M.Sc. MRSC
Chemical Modeller, Chemical and Process Modelling


E.
[hidden email]
T.
+44 (0)1925 289387
@uknnl

National Nuclear Laboratory Limited, 5th Floor, Chadwick House,
Birchwood Park, Warrington, WA3 6AE, UK

www.nnl.co.uk<http://www.nnl.co.uk>

From: Olivier GIVAUDAN [mailto:[hidden email]]
Sent: 19 October 2018 06:26
To: Fritsch, Katharina (NNL); Peter Claussen
Cc: [hidden email]
Subject: RE: [R] Genuine relative paths with R

Hi Katharina,

Apologies for the late reply.

Thank you for your proposal which was not made yet.

That's actually a Shiny app which I am working on. The problem is that the data are confidential: except when I share the R codes and data (via a marvelous secured SharePoint system...), the data should stay local.

When looking at [1], it seems inevitable that the data are published to a third-party server, which I want to avoid.

But I will look into it more closely, esp. whether it is possible to segregate the sharing of R codes / Shiny app (to the server, no problem) and data (only local).

Best regards,

Olivier

​[1] BLOCKEDshiny[.]rstudio[.]com/articles/deployment-local[.]htmlBLOCKED
________________________________________
De : Fritsch, Katharina (NNL) <[hidden email]>
Envoyé : jeudi 11 octobre 2018 08:22
À : Olivier GIVAUDAN; Peter Claussen
Cc : [hidden email]
Objet : RE: [R] Genuine relative paths with R

Hiya,
I have lost track of half the discussion so forgive me if that suggestion has been made before, but would it be suitable to wrap your code in a shiny app and disseminate it this way?
Kind regards,
Katharina.

--

Dr Katharina Fritsch B.Sc. M.Sc. MRSC
Chemical Modeller, Chemical and Process Modelling


E.
[hidden email]
T.
+44 (0)1925 289387
@uknnl

National Nuclear Laboratory Limited, 5th Floor, Chadwick House,
Birchwood Park, Warrington, WA3 6AE, UK

BLOCKEDnnl[.]co[.]ukBLOCKED

-----Original Message-----
From: R-help [mailto:[hidden email]] On Behalf Of Olivier GIVAUDAN
Sent: 11 October 2018 00:54
To: Peter Claussen
Cc: [hidden email]
Subject: Re: [R] Genuine relative paths with R

Yes, I am aware that both '__FILE__' and 'SAS_EXECFILENAME' are macro variables. I don't know how the VBA 'Application.ThisWorkbook.Path' VBA or PHP '__DIR__' (or '__FILE__') work.

And yes, indeed, until now I didn't even realise that this simple find-and-replace solution of "mine" is actually the basic job of a preprocessor when it expands macro variables, thank you!

A macro language in R, yes, I think it would be useful, at least for this function. If nothing simpler is available, of course...
________________________________
De : Peter Claussen <[hidden email]> Envoy  : mercredi 10 octobre 2018 23:29   : Olivier GIVAUDAN Cc : Duncan Murdoch; Jeff Newmiller; [hidden email] Objet : Re: [R] Genuine relative paths with R

If I m following all this correctly, it seems your criticism is that R doesn t provide a run-time function that is equivalent to a compile-time macro. You do realize that __FILE__ is not part of the C programming language - it s a predefined variable recognized by the cpp - the C preprocessor program. Similarly, SAS_EXECFILENAME is a predefined variable that can be recognized by the SAS macro processor, but has no meaning in the SAS language itself.

So, to go back to your original post:
1.  Either create a variable "ScriptPath" in the first lines of each of my R scripts and run a batch (or shell, etc.) to replace every single occurrence of "ScriptPath <-" by "ScriptPath <- [Absolute path of the R script]" in all the R scripts located in the folder (and possibly subfolders) of the batch file.

This is what a macro processor does. Are you asking for a macro language in R?

Cheers

On Oct 10, 2018, at 6:11 PM, Olivier GIVAUDAN <[hidden email]<mailto:[hidden email]>> wrote:

It is not wrong to claim that R currently doesn't have a function returning the path of the R file where this same function was invoked.

'getwd()' is indeed not equivalent to VBA 'Application.ThisWorkbook.Path' or C macro '__FILE__' or SAS %sysget(SAS_EXECFILENAME), etc.


        [[alternative HTML version deleted]]


This e-mail is from National Nuclear Laboratory Limited ("NNL"). This e-mail and any attachments are intended for the addressee and may also be legally privileged. If you are not the intended recipient please do not print, re-transmit, store or act in reliance on it or any attachments. Instead, please e-mail it back to the sender and then immediately permanently delete it.

National Nuclear Laboratory Limited (Company number 3857752) Registered in England and Wales. Registered office: Chadwick House, Warrington Road, Birchwood Park, Warrington, WA3 6AE.

*****************************************************************************
This message was received by the Cloud Security Email Gateway

and was checked for Viruses and SPAM by the Cloud Security Email Management Service.
Please forward any suspicious or unwanted emails to "Spam Helpdesk"
*****************************************************************************

This e-mail is from National Nuclear Laboratory Limited ("NNL"). This e-mail and any attachments are intended for the addressee and may also be legally privileged. If you are not the intended recipient please do not print, re-transmit, store or act in reliance on it or any attachments. Instead, please e-mail it back to the sender and then immediately permanently delete it.

National Nuclear Laboratory Limited (Company number 3857752) Registered in England and Wales. Registered office: Chadwick House, Warrington Road, Birchwood Park, Warrington, WA3 6AE.

        [[alternative HTML version deleted]]

______________________________________________
[hidden email] mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
123