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) <Katharina.Fritsch at nnl.co.uk>
Envoy? : jeudi 11 octobre 2018 08:22
? : Olivier GIVAUDAN; Peter Claussen
Cc : r-help at r-project.org
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.
katharina.fritsch at nnl.co.uk
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:r-help-bounces at r-project.org] On Behalf Of Olivier
GIVAUDAN
Sent: 11 October 2018 00:54
To: Peter Claussen
Cc: r-help at r-project.org
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 <dakotajudo at mac.com> Envoy : mercredi 10 octobre
2018 23:29 : Olivier GIVAUDAN Cc : Duncan Murdoch; Jeff Newmiller; r-help at
r-project.org 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 <olivier_givaudan at
hotmail.com<mailto:olivier_givaudan at hotmail.com>> 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]]
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.
katharina.fritsch at nnl.co.uk
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:olivier_givaudan at hotmail.com]
Sent: 19 October 2018 06:26
To: Fritsch, Katharina (NNL); Peter Claussen
Cc: r-help at r-project.org
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) <Katharina.Fritsch at nnl.co.uk>
Envoy? : jeudi 11 octobre 2018 08:22
? : Olivier GIVAUDAN; Peter Claussen
Cc : r-help at r-project.org
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.
katharina.fritsch at nnl.co.uk
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:r-help-bounces at r-project.org] On Behalf Of Olivier
GIVAUDAN
Sent: 11 October 2018 00:54
To: Peter Claussen
Cc: r-help at r-project.org
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 <dakotajudo at mac.com> Envoy : mercredi 10 octobre
2018 23:29 : Olivier GIVAUDAN Cc : Duncan Murdoch; Jeff Newmiller; r-help at
r-project.org 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 <olivier_givaudan at
hotmail.com<mailto:olivier_givaudan at hotmail.com>> 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.
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) <Katharina.Fritsch at nnl.co.uk>
Envoy? : vendredi 19 octobre 2018 08:08
? : Olivier GIVAUDAN
Cc : r-help at r-project.org
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.
katharina.fritsch at nnl.co.uk
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:olivier_givaudan at hotmail.com]
Sent: 19 October 2018 06:26
To: Fritsch, Katharina (NNL); Peter Claussen
Cc: r-help at r-project.org
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) <Katharina.Fritsch at nnl.co.uk>
Envoy? : jeudi 11 octobre 2018 08:22
? : Olivier GIVAUDAN; Peter Claussen
Cc : r-help at r-project.org
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.
katharina.fritsch at nnl.co.uk
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:r-help-bounces at r-project.org] On Behalf Of Olivier
GIVAUDAN
Sent: 11 October 2018 00:54
To: Peter Claussen
Cc: r-help at r-project.org
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 <dakotajudo at mac.com> Envoy : mercredi 10 octobre
2018 23:29 : Olivier GIVAUDAN Cc : Duncan Murdoch; Jeff Newmiller; r-help at
r-project.org 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 <olivier_givaudan at
hotmail.com<mailto:olivier_givaudan at hotmail.com>> 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]]