Yesterday I wrote and submitted to CRAN a package `run`, which implements
the ideas discussed in this thread. Given a package tarball
foo_0.1.0.tar.gz, users will be able to run
Rscript -e "run::run('foo_0.1.0.tar.gz')"
which will pull all the dependencies of package `foo`, lookup a function
`mai
Sounds interesting. Do you have it on GitHub or similar?
Rainer
> On 8 Feb 2019, at 09:09, David Lindelof wrote:
>
> Yesterday I wrote and submitted to CRAN a package `run`, which implements
> the ideas discussed in this thread. Given a package tarball
> foo_0.1.0.tar.gz, users will be able to
Sure, you can find it here:
https://github.com/dlindelof/run
On Fri, Feb 8, 2019 at 9:41 AM Rainer M Krug wrote:
> Sounds interesting. Do you have it on GitHub or similar?
>
> Rainer
>
> On 8 Feb 2019, at 09:09, David Lindelof wrote:
>
> Yesterday I wrote and submitted to CRAN a package `run`
I can reproduce this behavior on my Windows 10 system in RGui (cp1252):
when I paste the Unicode infinity symbol into the console, it is treated
as number 8. This is caused by Windows "best fit" default behavior in
conversion of unicode characters to characters in the current native
encoding: a
Fortune nomination...
> On 8 Feb 2019, at 13:07 , Tomas Kalibera wrote:
>
> This is caused by Windows "best fit" default behavior in conversion of
> unicode characters to characters in the current native encoding: at some
> point in the past, 8 has been chosen as a good fit for infinity in Win
It may be worth noting that both Avraham and I are members of the
histoRicalg project
(https://gitlab.com/nashjc/histoRicalg) that has some modest funding
from R-Consortium.
The type of concern this nlminb thread raises is why the project was
proposed. That is,
older codes that may predate IEEE ar
Tomas,
> In my scenario, the conversion is invoked by RGui before returning the
input to the main R loop, even before the input gets to the parser. In
principle, we could change this particular conversion in RGui to avoid the
substitution.
Not sure whether I am missing something here, but I used
I can reproduce with read.table(encoding="UTF-8") in RGui on Windows 10,
reading a file containing the two UTF-8 characters. The table is read
correctly into R as documented (both characters are represented in UTF-8
and marked as such), but, the conversion of Infinity to 8 and of Zhe to
happ
On 08/02/2019 11:12 a.m., Daniel Possenriede wrote:
Tomas,
In my scenario, the conversion is invoked by RGui before returning the
input to the main R loop, even before the input gets to the parser. In
principle, we could change this particular conversion in RGui to avoid the
substitution.
Not
Bumping this thread in the hope to catch the attention from R core.
As I try to argue in my original post, given the existing internal
structure of connections, I don't think it's too hard to add protection
against the use of corrupted R connection.
Writing to corrupted connection is a mistake th
I'm not sure whether GCC is in Rtools or not.
I will check on Monday.
However, that's not the main point.
In Rtools, there's nothing like the following:
R CMD Rpkg2exe -o my_r_application.exe my_r_package
or
R CMD Rpkg2exe -o my_r_application.exe my_r_package_0.1.0.tar.gz
Which would convert a
11 matches
Mail list logo
