[Rd] parallel and tempdir()
A forked process in mcparallel will wipe the (shared) tempdir when it
quits. I think this is almost always undesirable:
file.exists(tempdir())
parallel::mcparallel(q("no"))
file.exists(tempdir()) # false
file.create(tempfile()) # error
A simple solution might be to skip over R_CleanTempDir when
R_isForkedChild. Example patch: https://git.io/vDwyf
In addition, I would like to suggest to add an option to mcparallel to
set a custom tempdir in the fork to prevent potential conflicts. I
tried implementing this myself but found that setting R_TempDir is not
allowed by CMD check, and Sys_TempDir (which is what actually gets
wiped) is invisible behind attribute_hidden. So I suppose this may
only be done in base.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Pressing either Ctrl-\ of Ctrl-4 core dumps R
Thanks for these explanations - it all makes sense, that is, the default behavior for a process that does not capture SIGQUIT is to quit and perform a core dump (https://en.wikipedia.org/wiki/Unix_signal#SIGQUIT). Then the remaining question, as Luke says, is: should R handle this signal? For instance, in interactive mode, SIGQUIT could maybe bring up: Possible actions: 1: abort (with core dump, if enabled) 2: normal R exit 3: exit R without saving workspace 4: exit R saving workspace 5: ignore SIGQUIT (continue evaluation) Selection: giving the option to ignore a SIGQUIT send by mistake. Not sure how big of a problem this is (I'm surprise I never hit Ctrl+\ by mistake previously). Also, I'm sharing my notes about stty and SIGQUIT in case someone else finds them useful: My terminal (Linux / Ubuntu 16.04) settings are the same as Bill's (stty --all). Thus, pressing Ctrl+\ causes the terminal to signals SIGQUIT to the running process (= R). Since R does not handle / capture this specifically, this results in the process to quit and perform a core dump. Pressing Ctrl+\ is effectively the same a calling 'kill -s QUIT '. One can disable the QUIT signal send by the terminal by: $ stty quit '' such that one gets: $ stty --all speed 38400 baud; rows 33; columns 80; line = 0; intr = ^C; quit = ; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; discard = ^O; min = 1; time = 0; -parenb -parodd -cmspar cs8 -hupcl -cstopb cread -clocal -crtscts -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff -iuclc -ixany -imaxbel iutf8 opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke -flusho -extproc This will prevent QUIT to be signalled when pressing Ctrl+\ and thereby R (Python, ...) won't core dump. One can of course still use kill -s QUIT . To reset the above, either restart the terminal or use either of: $ stty quit ^\\## caret notation (espaced ^\) $ stty quit 0x1c ## hexadecimal notation $ stty quit 034## octal notation $ stty quit 28 ## decimal notation I still don't understand why the terminal treats keypress Ctrl+4 the same as Ctrl+\, but at least I'm not alone; https://catern.com/posts/terminal_quirks.html#fn.3. Thanks Henrik On Fri, Feb 10, 2017 at 11:00 AM, wrote: > So do a number of other interactive programs when working in a > terminal (e.g. python) since it looks like your terminal is configured > for those two actions to send the SIGQUIT signal. Whether R should > ignore that signal, under some circumstances at least, is another > question. > > Best, > > luke > > > On Fri, 10 Feb 2017, Henrik Bengtsson wrote: > >> When running R from the terminal on Linux (Ubuntu 16.04), it core >> dumps whenever / wherever I press Ctrl-4 or Ctrl-\. You get thrown >> back to the terminal with "Quit (core dump)" being the only message. >> Grepping the R source code, it doesn't look like that message is >> generated by R itself. Over on Twitter, it has been confirmed to also >> happen on macOS. >> >> $ R -d valgrind --vanilla --quiet >> ==979== Memcheck, a memory error detector >> ==979== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al. >> ==979== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info >> ==979== Command: /usr/lib/R/bin/exec/R --vanilla --quiet >> ==979== >>> >>> 1+2 >> >> [1] 3 >> >> # At next prompt I press Ctrl-\. The same happens also when done in >> the middle of an entry. >> >>> ==979== >> >> ==979== Process terminating with default action of signal 3 (SIGQUIT) >> ==979==at 0x576C9C3: __select_nocancel (syscall-template.S:84) >> ==979==by 0x502EABE: R_SelectEx (in /usr/lib/R/lib/libR.so) >> ==979==by 0x502EDDF: R_checkActivityEx (in /usr/lib/R/lib/libR.so) >> ==979==by 0x502F32B: ??? (in /usr/lib/R/lib/libR.so) >> ==979==by 0x4F6988B: Rf_ReplIteration (in /usr/lib/R/lib/libR.so) >> ==979==by 0x4F69CF0: ??? (in /usr/lib/R/lib/libR.so) >> ==979==by 0x4F69DA7: run_Rmainloop (in /usr/lib/R/lib/libR.so) >> ==979==by 0x4007CA: main (in /usr/lib/R/bin/exec/R) >> ==979== >> ==979== HEAP SUMMARY: >> ==979== in use at exit: 28,981,596 bytes in 13,313 blocks >> ==979== total heap usage: 27,002 allocs, 13,689 frees, 49,025,684 >> bytes allocated >> ==979== >> ==979== LEAK SUMMARY: >> ==979==definitely lost: 0 bytes in 0 blocks >> ==979==indirectly lost: 0 bytes in 0 blocks >> ==979== possibly lost: 0 bytes in 0 blocks >> ==979==still reachable: 28,981,596 bytes in 13,313 blocks >> ==979== suppressed: 0 bytes in 0 blocks >> ==979== Rerun with --leak-check=full to see details of leaked memory >> ==979== >> ==979== For counts of detected and suppressed errors, rerun with: -v >> ==979== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) >> Quit (core dumped)
Re: [Rd] Grapics Device Resolution Limits
Good day, > In general, the device-limits info is not on the help page because we do not > know it. It seems like it would be near-impossible to do in a cross-platform way. > Normally you will get warning(s) accompanying that Error ... > Warning: unable to allocate bitmap > Warning: opening device failed Yes, I saw those but omitted them from the question. > Note that there are at least 5 separate png() devices, so Linux was not using > the (default) device used on Windows. That explains it. > Try the other 2 types: the cairo devices do not use your graphics hardware > nor MicroSoft's GDI. Indeed, it works with the cairo backend. > ... one could well ask what you can usefully do with such an image. Unfortunately, some scientific journals have unrealistic figure requirements, e.g. http://www.jidonline.org/content/authorinfo#idp1498768 -- Dario Strbenac University of Sydney Camperdown NSW 2050 Australia __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Bug with zlib version checking for zlib >= 1.2.10, R version 3.3.2
Hi,
Posting here as bugzilla is closed to registration.
The zlib version checking code does not handle double digits for the
patch version in the semantic versioning scheme. Consequently, a
./configure fails when using a zlib version ≥ 1.5.10. I suggest
something like the following patch:
--- a/m4/R.m4
+++ b/m4/R.m4
@@ -3116,7 +3116,7 @@ int main() {
#ifdef ZLIB_VERSION
/* Work around Debian bug: it uses 1.2.3.4 even though there was no such
version on the master site zlib.net */
- exit(strncmp(ZLIB_VERSION, "1.2.5", 5) < 0);
+ exit(strncmp(ZLIB_VERSION, "1.2.5", 5) < 0 && (strlen(ZLIB_VERSION) < 6 ||
strncmp(ZLIB_VERSION, "1.2.10", 6) < 0));
#else
exit(1);
#endif
This could of course be improved to properly parse the string.
Cheers,
Justin
signature.asc
Description: PGP signature
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Bug with zlib version checking for zlib >= 1.2.10, R version 3.3.2
This has been fixed (https://cran.r-project.org/doc/manuals/r-devel/NEWS.html):
CHANGES IN R 3.3.2 patched:
INSTALLATION on a UNIX-ALIKE
* The configure check for the zlib version is now robust to versions
longer than 5 characters, including 1.2.10.
in SVN r71889 (2017-01-03):
https://github.com/wch/r-source/commit/a0fe05ce9d0937ad2334bb370785cb22c71e592b
/Henrik
On Sun, Feb 12, 2017 at 3:51 PM, Justin Bedő wrote:
>
> Hi,
>
> Posting here as bugzilla is closed to registration.
> The zlib version checking code does not handle double digits for the
> patch version in the semantic versioning scheme. Consequently, a
> ./configure fails when using a zlib version ≥ 1.5.10. I suggest
> something like the following patch:
>
> --- a/m4/R.m4
> +++ b/m4/R.m4
> @@ -3116,7 +3116,7 @@ int main() {
> #ifdef ZLIB_VERSION
> /* Work around Debian bug: it uses 1.2.3.4 even though there was no such
> version on the master site zlib.net */
> - exit(strncmp(ZLIB_VERSION, "1.2.5", 5) < 0);
> + exit(strncmp(ZLIB_VERSION, "1.2.5", 5) < 0 && (strlen(ZLIB_VERSION) < 6 ||
> strncmp(ZLIB_VERSION, "1.2.10", 6) < 0));
> #else
>exit(1);
> #endif
>
> This could of course be improved to properly parse the string.
>
> Cheers,
>
> Justin
>
> __
> 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
Re: [Rd] Bug with zlib version checking for zlib >= 1.2.10, R version 3.3.2
Henrik Bengtsson writes: > This has been fixed > (https://cran.r-project.org/doc/manuals/r-devel/NEWS.html): > > CHANGES IN R 3.3.2 patched: > > INSTALLATION on a UNIX-ALIKE > > * The configure check for the zlib version is now robust to versions > longer than 5 characters, including 1.2.10. > > in SVN r71889 (2017-01-03): > > https://github.com/wch/r-source/commit/a0fe05ce9d0937ad2334bb370785cb22c71e592b > > /Henrik Thanks, sorry I missed that. Justin signature.asc Description: PGP signature __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
