[Rd] terminating R code evalutation asynchronously
Hi, I am new to this mailing list. Hence brief a introduction: I am working for Comerge, developing an online trading platform (interacting with brokers over the internet in realtime) which is mostly written in Pascal. We are using R-embedded to offer the user a way to implement strategies in R and test them. Currently we are facing the following problem: We need to implement an emergency exit procedure. The idea is that we send the process a signal (like Crtl-C) and do all the necessary cleanup after the signal has been caught. There are a number of constraints and wishes: 1. The signal handler should take only very little time. E.g. set a number of flags etc. and then return and leave the rest of the work to the main program. 2. The signal handler is asynchronous by nature. 3. We would like that this works even if the user is hanging in an infinite loop in the R code. E.g. we need to kill the current R code evaluation in the signal handler. 4. The main program needs to keep running to finish the cleanup. I found that the following function which seems to do the trick: jump_to_toplevel() however, I am unsure whether this is safe - e.g. is this function "thread safe" or do we risk that the application crashes when the signal handler is invoked? Is there another, safer way to terminate the current R execution? Furthermore this function seems to crash if the R engine is not currently inside a R_tryEval call. Thanks! Christian Ledergerber __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] sprintf limits output string length with no warning/error message
sprintf has a limit on the length of a string produced with a '%s'
specification:
nchar(sprintf('%1s', ''))
# 8191
nchar(sprintf('%*s', 1, ''))
# 8191
This is sort of documented in ?sprintf:
" There is a limit of 8192 bytes on elements of 'fmt' and also on
strings included by a '%s' conversion specification."
but it should be a good idea for sprintf to at least warn when the
output is shorter than specified.
vQ
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] incorrect output and segfaults from sprintf with %*d (PR#13667)
Full_Name: Wacek Kusnierczyk
Version: 2.10.0 r48365
OS: Ubuntu 8.04 Linux 32bit
Submission from: (NULL) (129.241.110.141)
sprintf has a documented limit on strings included in the output using the
format '%s'. It appears that there is a limit on the length of strings included
with, e.g., the format '%d' beyond which surprising things happen (output
modified for conciseness):
gregexpr('1', sprintf('%9000d', 1))
# [1] 9000 9801
gregexpr('1', sprintf('%9000d', 1))
# [1] 9000 9801 10602
gregexpr('1', sprintf('%9000d', 1))
# [1] 9000 9801 10602 11403
gregexpr('1', sprintf('%9000d', 1))
# [1] 9000 9801 10602 11403 12204
...
Note that not only more than one '1' is included in the output, but also that
the same functional expression (no side effects used beyond the interface) gives
different results on each execution. Analogous behaviour can be observed with
'%nd' where n > 8200.
The actual output above is consistent across separate sessions.
With sufficiently large field width values, R segfaults:
sprintf('%*d', 10^5, 1)
# *** caught segfault ***
# address 0xbfcfc000, cause 'memory not mapped'
# Segmentation fault
sessionInfo()
# R version 2.10.0 Under development (unstable) (2009-04-20 r48365)
# i686-pc-linux-gnu
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Sharing variables in seperate workspace
Philip writes:
> Hi all.
Hi Philip -- I think this thread
https://stat.ethz.ch/pipermail/r-devel/2009-March/052867.html
addresses your issue. Basically, create an environment or closure in
which you can modify variables.
HTH,
Martin
>
>
> I'm for the first time trying to make a library in R 2.8.1 on Ubuntu
> Linux. The library is very simple, R functions just need to share a
> variable (that is defined in the R code) and maybe functions and export
> functions for the user to .GlobalEnv. This variable should only be
> directly accessible from the global workspace (without change of
> environment) via a hereto dedicated function. It only consists of R
> code. I'm not sure if I should rather ask R-help. If so, just tell me.
>
> The package source is available at
> http://www.delff.dk/~philip/bdplot/
> the check output at
> http://www.delff.dk/~philip/bdplot.Rcheck/
>
> The package code was checked and stopped because of lack of examples.
> Until that, everything is OK.
>
>> ### ** Examples
>>
>> ~~ simple examples of the most important functions ~~
> Error: unexpected symbol in "~~ simple examples"
> Execution halted
>
> I would like to get the code issue solved before moving the
> documentation from the R scripts and have proceeded the to building and
> installation. These two last steps gave no warnings or errors.
>
> My problem is that I cannot change the mentioned variable (from now on
> called .FOO) that belongs to the namespace of the package. I think it is
> because .FOO variable in some locked state, maybe by default created as
> read-only. It is called .FOO because I use exportPattern("^[[:alpha:]]+")
> as NAMESPACE file. I don't import anything.
>
> I have a function (bar) that, like par does with .Pars from the graphics
> namespace, modifies the contents of a list. This function has in the
> bottom (when the function name is called without () from the R command
> line) a line
>
>
>
> This is like par() has the graphics namespace mentioned, and therefore,
> as I would expect. I can via this function read the contents of the
> variable just by print(.FOO). This cannot be done from .GlobalEnv which
> is as intended. The surprise is that I cannot write to it. If I do
>
> .FOO$x <<- "value"
> (names and values are arguments to the function, like with par().), I
> get the error:
>
> cannot change value of locked binding for '.FOO'
>
> The double arrow, I use because <- does not affect the contents of .FOO
> after the function has run. I don't know how I can use assign in this
> case. I don't know a name for my package's environment. I have tried
> with my package's name in both assign() and unlockBinding(), but my
> package's name is not recognized as an environment (neither beginning
> with a dot.). I also tryed unlockBinding() in the NAMESPACE file.
>
> I don't know if this is normal, but I get
>
> from print(parent.frame()) and things like
>
> from print(environment())
> This is surprising to me. I would expect
>
> from environment().
>
> How can I get to write to .FOO via bar()?
>
>
> Thank you very much
> Philip.
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
Martin Morgan
Computational Biology / Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N.
PO Box 19024 Seattle, WA 98109
Location: Arnold Building M1 B861
Phone: (206) 667-2793
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] print.closure at the R level
> "MM" == Martin Maechler
> on Mon, 20 Apr 2009 23:23:23 +0200 writes:
> "RF" == Romain Francois
> on Mon, 20 Apr 2009 22:42:22 +0200 writes:
RF> Hello,
RF> Sorry if I have waisted any time of people truing this
RF> patch.
MM> yes, you did waste (sic) but thank you for the
MM> code suggestions anyway.
RF> There was an issue with debugging (use of debug and
RF> browser that caused an infinite recursion). I think this
RF> is now fixed.
MM> [ actually I had found even simpler bugs in it, e.g.
MM> you accidentally called C-level "print.function()" on
MM> "language", some may have been fixed by your new patch
MM> too, but others are not {e.g., print() *must* return its
MM> argument !} ]
MM> However, I've already changed your old patch too much
MM> (notably by using *our* C coding standards) to want to
MM> look at your new patch in detail.
MM> If you want we can communicate off-list about this,
MM> tomorrow...
{and we did}
It turns out to be considerably more tricky than I had
anticipated...
Note that we also really want auto-printing and print()ing to be
equivalent,
and that is not even the case for .Primitives in current R :
> c
function (..., recursive = FALSE) .Primitive("c")
> print(c)
function (..., recursive = FALSE)
>
{for "obvious" reasons, but needing even more work ...}
Also, Romain was "right" insofar as he would have wanted to only
deal with closure, whereas of course Duncan was right that the
corresponding class is 'function' and that comprises other types
(in the 'typeof' sense).
[story to be continued ...]
Martin Maechler, ETH Zurich
RF> At the R level, I have now this :
>>> print.function
RF> function (x, useSource = TRUE, ...) {
RF> invisible(.Internal(print.function(x, useSource, ...)))
RF> }
RF> and the PrintValueRec dispatches like this at the C
RF> level:
RF> case LANGSXP: PrintLanguage(s, FALSE) ; break; case
RF> CLOSXP: { SEXP call; PROTECT( call =
RF> lang2(install("print.function"), s)); eval(call,env);
RF> UNPROTECT(1); break; }
RF> so that LANGSXP are printed using the PrintLanguage
RF> function and CLOSXP are printed using the R function
RF> print.function which in turns calls the PrintClosure
RF> function (unless it is masked in R)
RF> Romain
RF> Romain Francois wrote:
>>> Yesterday's patch did not print the attributes. This one
>>> seems fine:
>>>
>>> > f <- function(){} > attr( f, "yada" ) <- function( )
>>> "lobster bisk" > f function(){} attr(,"yada") function(
>>> ) "lobster bisk"
>>>
>>> Romain
>>>
>>> Romain Francois wrote:
Duncan Murdoch wrote:
> On 18/04/2009 10:12 AM, Romain Francois wrote:
>> Hello,
>>
>> Could the code that auto prints a function/closure be
>> extracted from print.c so that there would be a
>> print.closure function. I would like to be able to
>> mask a print.closure function so that I have a custom
>> auto-print. One reason for that is I plan to have
>> syntax highlighting within the R console.
>
> The class of a closure is "function", so you'd want
> the method to be print.function. Currently that
> doesn't work for auto printing, so your suggestion is
> still interesting. (I'm not sure why auto printing is
> special here...)
>
> Duncan Murdoch
The attached patch implements exposing the
print.function at the R level.
Romain
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
>>>
>>>
>>>
>>>
>>> __
>>> R-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
RF> -- Romain Francois Independent R Consultant +33(0) 6 28
RF> 91 30 30 http://romainfrancois.blog.free.fr
MM> __
MM> R-devel@r-project.org mailing list
MM> https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Sharing variables in seperate workspace
Hi Martin
Thank you very much. That solved my problem, and the package is now working!
Best regards. Philip.
Martin Morgan wrote:
> Philip writes:
>
>> Hi all.
>
> Hi Philip -- I think this thread
>
> https://stat.ethz.ch/pipermail/r-devel/2009-March/052867.html
>
> addresses your issue. Basically, create an environment or closure in
> which you can modify variables.
>
> HTH,
>
> Martin
>
>>
>> I'm for the first time trying to make a library in R 2.8.1 on Ubuntu
>> Linux. The library is very simple, R functions just need to share a
>> variable (that is defined in the R code) and maybe functions and export
>> functions for the user to .GlobalEnv. This variable should only be
>> directly accessible from the global workspace (without change of
>> environment) via a hereto dedicated function. It only consists of R
>> code. I'm not sure if I should rather ask R-help. If so, just tell me.
>>
>> The package source is available at
>> http://www.delff.dk/~philip/bdplot/
>> the check output at
>> http://www.delff.dk/~philip/bdplot.Rcheck/
>>
>> The package code was checked and stopped because of lack of examples.
>> Until that, everything is OK.
>>
>>> ### ** Examples
>>>
>>> ~~ simple examples of the most important functions ~~
>> Error: unexpected symbol in "~~ simple examples"
>> Execution halted
>>
>> I would like to get the code issue solved before moving the
>> documentation from the R scripts and have proceeded the to building and
>> installation. These two last steps gave no warnings or errors.
>>
>> My problem is that I cannot change the mentioned variable (from now on
>> called .FOO) that belongs to the namespace of the package. I think it is
>> because .FOO variable in some locked state, maybe by default created as
>> read-only. It is called .FOO because I use exportPattern("^[[:alpha:]]+")
>> as NAMESPACE file. I don't import anything.
>>
>> I have a function (bar) that, like par does with .Pars from the graphics
>> namespace, modifies the contents of a list. This function has in the
>> bottom (when the function name is called without () from the R command
>> line) a line
>>
>>
>>
>> This is like par() has the graphics namespace mentioned, and therefore,
>> as I would expect. I can via this function read the contents of the
>> variable just by print(.FOO). This cannot be done from .GlobalEnv which
>> is as intended. The surprise is that I cannot write to it. If I do
>>
>> .FOO$x <<- "value"
>> (names and values are arguments to the function, like with par().), I
>> get the error:
>>
>> cannot change value of locked binding for '.FOO'
>>
>> The double arrow, I use because <- does not affect the contents of .FOO
>> after the function has run. I don't know how I can use assign in this
>> case. I don't know a name for my package's environment. I have tried
>> with my package's name in both assign() and unlockBinding(), but my
>> package's name is not recognized as an environment (neither beginning
>> with a dot.). I also tryed unlockBinding() in the NAMESPACE file.
>>
>> I don't know if this is normal, but I get
>>
>> from print(parent.frame()) and things like
>>
>> from print(environment())
>> This is surprising to me. I would expect
>>
>> from environment().
>>
>> How can I get to write to .FOO via bar()?
>>
>>
>> Thank you very much
>> Philip.
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Patch for tk/GUI
On 15 Feb 2009, I uploaded a patch to tkGUI.r that allows Linux users to load/save their workspace history from the GUI. There was no response, so I presume I did not submit the code correctly. What is the correct mechanism for submitting a patch/new feature to R? -- View this message in context: http://www.nabble.com/Patch-for-tk-GUI-tp23165645p23165645.html Sent from the R devel mailing list archive at Nabble.com. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Patch for tk/GUI
jdeisenberg wrote: On 15 Feb 2009, I uploaded a patch to tkGUI.r that allows Linux users to load/save their workspace history from the GUI. There was no response, so I presume I did not submit the code correctly. What is the correct mechanism for submitting a patch/new feature to R? Well, it's still in my r-devel folder labeled "important". It is just that important things get run over by important things with deadlines. I'll get around to it eventually. -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - (p.dalga...@biostat.ku.dk) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R CMD check dislikes .git directories
This may be new to 2.9.0, but I'm not sure, since I no longer have the older version. I notice that R CMD check has no problem with .svn directories, but it dislikes .git directories. That seems a bit of a problem, for folks like me who sometimes use git. Perhaps this behaviour could be changed? Dan. -- View this message in context: http://www.nabble.com/R-CMD-check-dislikes-.git-directories-tp23166614p23166614.html Sent from the R devel mailing list archive at Nabble.com. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD check dislikes .git directories
On 21/04/2009 7:59 PM, Dan Kelley wrote: This may be new to 2.9.0, but I'm not sure, since I no longer have the older version. I notice that R CMD check has no problem with .svn directories, but it dislikes .git directories. That seems a bit of a problem, for folks like me who sometimes use git. Perhaps this behaviour could be changed? According to the R Extensions manual, it excludes dirs named CVS, .svn, .arch-ids, .bzr, and git. Is .git the right thing to exclude instead of git, or are both possible? The same section points out the workaround: use the .Rbuildignore file to say what isn't really part of your package. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD check dislikes .git directories
On 21/04/2009 8:10 PM, Duncan Murdoch wrote: On 21/04/2009 7:59 PM, Dan Kelley wrote: This may be new to 2.9.0, but I'm not sure, since I no longer have the older version. I notice that R CMD check has no problem with .svn directories, but it dislikes .git directories. That seems a bit of a problem, for folks like me who sometimes use git. Perhaps this behaviour could be changed? According to the R Extensions manual, it excludes dirs named CVS, .svn, .arch-ids, .bzr, and git. Is .git the right thing to exclude instead of git, or are both possible? Actually, that looks like a typo in the manual: the code excludes .git, not git. I'll fix the typo, but it means I don't know what error you're talking about. Could you post instructions for reproducing? Duncan Murdoch The same section points out the workaround: use the .Rbuildignore file to say what isn't really part of your package. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD check dislikes .git directories
I think what I'm pasting below will illustrate. (The git repo is behind a firewall, so I can't invite folks to download the repo to test locally. I could tar up the source and put it on a website if that would help.) * checking if this is a source package ... OK * checking for executable files ... WARNING Found the following executable file(s): .git/objects/01/9002df908b9c97f98e6ad3dd079bee436a2d66 .git/objects/08/ac4fdd57a77afe2f8071c2e697cbda02b276b7 .git/objects/13/49be3ed32dd801eacbdf1cc96a7577dcdfa2d7 .git/objects/14/45d1188fcd949bd77d5c1117906c7987fe15a7 .git/objects/18/756ad87b639ad2123a0ac78d04daa613d16966 On 2009-04-21, at 9:24 PM, Duncan Murdoch wrote: On 21/04/2009 8:10 PM, Duncan Murdoch wrote: On 21/04/2009 7:59 PM, Dan Kelley wrote: This may be new to 2.9.0, but I'm not sure, since I no longer have the older version. I notice that R CMD check has no problem with .svn directories, but it dislikes .git directories. That seems a bit of a problem, for folks like me who sometimes use git. Perhaps this behaviour could be changed? According to the R Extensions manual, it excludes dirs named CVS, .svn, .arch-ids, .bzr, and git. Is .git the right thing to exclude instead of git, or are both possible? Actually, that looks like a typo in the manual: the code excludes .git, not git. I'll fix the typo, but it means I don't know what error you're talking about. Could you post instructions for reproducing? Duncan Murdoch The same section points out the workaround: use the .Rbuildignore file to say what isn't really part of your package. Duncan Murdoch Dan Kelley, PhD Associate Professor and Graduate Coordinator Dept. Oceanography, Dalhousie University, Halifax NS B3H 4J1 kelley@gmail.com (1-minute path) or dan.kel...@dal.ca (2-hour path) Phone 902 494 1694; Fax 902 494 3877 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD check dislikes .git directories
On 21/04/2009 8:37 PM, Dan Kelley wrote: I think what I'm pasting below will illustrate. (The git repo is behind a firewall, so I can't invite folks to download the repo to test locally. I could tar up the source and put it on a website if that would help.) * checking if this is a source package ... OK * checking for executable files ... WARNING Found the following executable file(s): .git/objects/01/9002df908b9c97f98e6ad3dd079bee436a2d66 .git/objects/08/ac4fdd57a77afe2f8071c2e697cbda02b276b7 .git/objects/13/49be3ed32dd801eacbdf1cc96a7577dcdfa2d7 .git/objects/14/45d1188fcd949bd77d5c1117906c7987fe15a7 .git/objects/18/756ad87b639ad2123a0ac78d04daa613d16966 Okay, that helps. I don't think the problem is git versus svn, it's that you've got executable files in a directory where check shouldn't be looking. I don't think .Rbuildignore would help you. I'll pass this on as a bug... Duncan Murdoch On 2009-04-21, at 9:24 PM, Duncan Murdoch wrote: On 21/04/2009 8:10 PM, Duncan Murdoch wrote: On 21/04/2009 7:59 PM, Dan Kelley wrote: This may be new to 2.9.0, but I'm not sure, since I no longer have the older version. I notice that R CMD check has no problem with .svn directories, but it dislikes .git directories. That seems a bit of a problem, for folks like me who sometimes use git. Perhaps this behaviour could be changed? According to the R Extensions manual, it excludes dirs named CVS, .svn, .arch-ids, .bzr, and git. Is .git the right thing to exclude instead of git, or are both possible? Actually, that looks like a typo in the manual: the code excludes .git, not git. I'll fix the typo, but it means I don't know what error you're talking about. Could you post instructions for reproducing? Duncan Murdoch The same section points out the workaround: use the .Rbuildignore file to say what isn't really part of your package. Duncan Murdoch Dan Kelley, PhD Associate Professor and Graduate Coordinator Dept. Oceanography, Dalhousie University, Halifax NS B3H 4J1 kelley@gmail.com (1-minute path) or dan.kel...@dal.ca (2-hour path) Phone 902 494 1694; Fax 902 494 3877 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD check dislikes .git directories
> Okay, that helps. I don't think the problem is git versus svn, it's that > you've got executable files in a directory where check shouldn't be looking. > I don't think .Rbuildignore would help you. > > I'll pass this on as a bug... I've complained about this in the past, and I was told that "good practice" was to run R CMD check on the file created by R CMD build. Hadley -- http://had.co.nz/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD check dislikes .git directories
On 21/04/2009 9:32 PM, hadley wickham wrote: Okay, that helps. I don't think the problem is git versus svn, it's that you've got executable files in a directory where check shouldn't be looking. I don't think .Rbuildignore would help you. I'll pass this on as a bug... I've complained about this in the past, and I was told that "good practice" was to run R CMD check on the file created by R CMD build. That's true, and it would solve the problem, which may be why it hasn't been a high enough priority to fix. I won't fix it: check is written in Perl, and I don't know Perl well enough to want to mess with it. But maybe a second complaint about it will motivate someone who does know Perl to put together a fix. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] RFC: Ability to suppress 'locale' from sessionInfo
The printing of the locale information from sessionInfo is not very tidy. Using toLatex(sessionInfo) pretty much guarantees "badness" from breaking the margin boundary (though my version of TeX no longer reports such errors). A random example is here: http://cran.r-project.org/web/packages/Matrix/vignettes/Design-issues.pdf I find the locale information unnecessary and right now I hack this with si = sessionInfo() si$locale = "US" toLatex(si) I would like to be able to do something a bit cleaner, for example sessionInfo(locale=FALSE) For what it's worth, I don't think that early versions of sessionInfo printed information about the locale. Discussion welcome. Kevin Wright [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
