Re: [Rd] Printing chinese characters (UTF-8) on R 3.5.2 -windows 10
On Fri, Sep 13, 2019 at 11:53 AM Tomas Kalibera
wrote:
> On 9/13/19 11:37 AM, IAGO GINÉ VÁZQUEZ wrote:
> > But if I type
> > >"會"
> > the output is
> > [1] "會"
> > so seemingly it can be represented. Or, am I wrong?
>
> In RGui you can print the string, because RGui is a Windows Unicode
> application (uses UTF16-LE and bypasses the C runtime for strings). But
> it is just the gui, R itself (and hence also packages) use the current
> native encoding as defined by the C runtime. RGui will make sure R gets
> the string in UTF-8, but as soon as you do anything even slightly
> non-trivial, which includes formatting, the string will be converted to
> the current native encoding. Some R functions allow you to do certain
> things in UTF-8 without conversion to native encoding, you'd have to
> read very carefully the documentation for each function - but for
> practical use, you either need to live with the misinterpretation of
> some characters, or use Windows in the locale where your characters can
> be represented (e.g. Chinese locale when working with Chinese strings),
> or use Linux/maOS. On Linux/macOS the current native encoding can be
> UTF-8, so there is no problem. On Windows, with the current toolchain
> based on mingw, this is not possible.
>
mingw-w64 is capable of processing utf-8 (it can process bytes after all).
Can you explain what you mean here? Would any other compiler on Windows not
suffer from this problem?
>
>
> Best
> Tomas
>
> >
> > Best
> > Iago
> >
> > *De:* Tomas Kalibera
> > *Enviat el:* divendres, 13 de setembre de 2019 11:24
> > *Per a:* IAGO GINÉ VÁZQUEZ ; r-devel@r-project.org
> >
> > *Tema:* Re: [Rd] Printing chinese characters (UTF-8) on R 3.5.2
> > -windows 10
> > On 9/13/19 11:01 AM, IAGO GINÉ VÁZQUEZ wrote:
> > > I have a chinese character on a data frame, but the output of
> > printing it is its UTF-8 code. Concretely, the character is 會 and the
> > code is U+6703. Following the code I arrive to the instruction
> > >
> > >> base::format.default("會")
> > > which prints
> > >
> > > [1] ""
> > >
> > > I do not know which is the extent of this behaviour either if it
> > follows on most recent versions of R.
> > >
> > > Is it expected?
> >
> > If you are running this on Windows in an encoding where the character
> > cannot be represented (e.g. non-Chinese locale), then yes, this is
> > expected behavior.
> >
> > On Unix systems where R can run in UTF-8 encoding (Linux, macOS), the
> > character will be formatted/displayed properly.
> >
> > Best
> > Tomas
> >
> > >
> > > Thank you!
> > >
> > > Iago
> > >
> > >[[alternative HTML version deleted]]
> > >
> > > __
> > > R-devel@r-project.org mailing list
> > > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
> >
>
>
> [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Printing chinese characters (UTF-8) on R 3.5.2 -windows 10
On Fri, Sep 13, 2019 at 1:46 PM Tomas Kalibera
wrote:
> On 9/13/19 1:33 PM, Ray Donnelly wrote:
>
> On Fri, Sep 13, 2019 at 11:53 AM Tomas Kalibera
> wrote:
>
>> On 9/13/19 11:37 AM, IAGO GINÉ VÁZQUEZ wrote:
>> > But if I type
>> > >"會"
>> > the output is
>> > [1] "會"
>> > so seemingly it can be represented. Or, am I wrong?
>>
>> In RGui you can print the string, because RGui is a Windows Unicode
>> application (uses UTF16-LE and bypasses the C runtime for strings). But
>> it is just the gui, R itself (and hence also packages) use the current
>> native encoding as defined by the C runtime. RGui will make sure R gets
>> the string in UTF-8, but as soon as you do anything even slightly
>> non-trivial, which includes formatting, the string will be converted to
>> the current native encoding. Some R functions allow you to do certain
>> things in UTF-8 without conversion to native encoding, you'd have to
>> read very carefully the documentation for each function - but for
>> practical use, you either need to live with the misinterpretation of
>> some characters, or use Windows in the locale where your characters can
>> be represented (e.g. Chinese locale when working with Chinese strings),
>> or use Linux/maOS. On Linux/macOS the current native encoding can be
>> UTF-8, so there is no problem. On Windows, with the current toolchain
>> based on mingw, this is not possible.
>>
>
> mingw-w64 is capable of processing utf-8 (it can process bytes after all).
> Can you explain what you mean here? Would any other compiler on Windows not
> suffer from this problem?
>
> The problem is using UTF-8 as the current locale as understood by the C
> runtime/C library. By default mingw uses msvcrt, which does not allow UTF-8
> as current locale (via setlocale()). Now mingw also allows to build with
> UCRT (recently), and I hope one day we will be able to use it, but it is
> not yet the default, msys2 does not use it yet for its mingw_ packages and
> we need also the external packages . Note that R (CRAN, and also BIOC)
> provide binary versions of all packages for Windows, they need to build
> them and they need all library dependencies. All of those would have to be
> rebuilt with UCRT, which will be a huge task. Fixing R on its own to
> support UTF-8 natively on Windows when the C runtime allows it won't be
> hard, because R already can do it on Unix, but the problem is all the
> dependencies.
>
Thanks. We build R for the Anaconda Distribution and are considering our
options around our Windows compilers, including the UCRT (and clang,
possibly from MSYS2, possibly from conda-forge, or a hybrid of some sort if
necessary).
> Tomas
>
>
>
>
>
>>
>>
>> Best
>> Tomas
>>
>> >
>> > Best
>> > Iago
>> >
>> > *De:* Tomas Kalibera
>> > *Enviat el:* divendres, 13 de setembre de 2019 11:24
>> > *Per a:* IAGO GINÉ VÁZQUEZ ; r-devel@r-project.org
>> >
>> > *Tema:* Re: [Rd] Printing chinese characters (UTF-8) on R 3.5.2
>> > -windows 10
>> > On 9/13/19 11:01 AM, IAGO GINÉ VÁZQUEZ wrote:
>> > > I have a chinese character on a data frame, but the output of
>> > printing it is its UTF-8 code. Concretely, the character is 會 and the
>> > code is U+6703. Following the code I arrive to the instruction
>> > >
>> > >> base::format.default("會")
>> > > which prints
>> > >
>> > > [1] ""
>> > >
>> > > I do not know which is the extent of this behaviour either if it
>> > follows on most recent versions of R.
>> > >
>> > > Is it expected?
>> >
>> > If you are running this on Windows in an encoding where the character
>> > cannot be represented (e.g. non-Chinese locale), then yes, this is
>> > expected behavior.
>> >
>> > On Unix systems where R can run in UTF-8 encoding (Linux, macOS), the
>> > character will be formatted/displayed properly.
>> >
>> > Best
>> > Tomas
>> >
>> > >
>> > > Thank you!
>> > >
>> > > Iago
>> > >
>> > >[[alternative HTML version deleted]]
>> > >
>> > > __
>> > > R-devel@r-project.org mailing list
>> > > https://stat.ethz.ch/mailman/listinfo/r-devel
>> >
>> >
>>
>>
>> [[alternative HTML version deleted]]
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>
>
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Optimization bug when byte compiling with gcc 5.3.0 on windows
Hi, Apologies for breaking the threading on this, I've only just signed up to the list and the last email was from September 2015. I've started to look into building R for Windows using MSYS2 as both the build environment and tools + libraries provider (where possible). I've managed to get the testsuite to pass on a recent MSYS2 MinGW-w64 x86-64 GCC: gcc.exe (Rev1, Built by MSYS2 project) 5.3.1 20160228 I've attached two patches that I needed, described below. I hope this is the appropriate place and way to suggest patches. Comments for improvements are very welcome. 0005-Win32-Extend-sqrt-NA_real_-hack-to-all-GCC-versions.patch Removes the __GNUC__ <= 4 for Windows ISNAN R_sqrt hack and doesn't replace it with any version check since I don't see any reason to second-guess when it might be fixed. When it is fixed in MinGW-w64 we can just remove the hack and be happy (I would hope to be able to get round to this in the next few months). 0006-Win32-GCC-5.3-Fix-ISNAN-int-emits-UD2-insn.patch The reason that boxplot.stats() was crashing was because when isnan() is called with an int it emits a UD2 instruction to force a crash, so let us just cast the input value to a double to prevent that. The code for this can be seen here: https://github.com/Alexpux/mingw-w64/blob/master/mingw-w64-headers/crt/math.h#L612-L622 -- Best regards, Ray Donnelly, Continuum Analytics Inc. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Optimization bug when byte compiling with gcc 5.3.0 on windows
On Mon, Apr 4, 2016 at 12:29 PM, Duncan Murdoch wrote: > On 03/04/2016 9:44 PM, Ray Donnelly wrote: > >> Hi, >> >> Apologies for breaking the threading on this, I've only just signed up to >> the list and the last email was from September 2015. >> >> I've started to look into building R for Windows using MSYS2 as both the >> build environment and tools + libraries provider (where possible). I've >> managed to get the testsuite to pass on a recent MSYS2 MinGW-w64 x86-64 >> GCC: >> gcc.exe (Rev1, Built by MSYS2 project) 5.3.1 20160228 >> >> I've attached two patches that I needed, described below. I hope this is >> the appropriate place and way to suggest patches. Comments for >> improvements >> are very welcome. >> > > There were no patches attached, just the link to the mingw-w64 project on > Github. > Ah, that's strange, they must have got stripped. > > Generally the way to produce patches for R is to use svn diff on a checked > out working copy of the trunk. On Windows, Tortoisesvn makes this really > simple. Then the patch will include information about the revision it's > based on. You then upload it to bugs.r-project.org, along with a > description of the problem it solves, and mark it as a bug fix or > enhancement request. Ok, I had used diffutils' diff -urN on the 3.2.4-revised release to generate them. > > >> 0005-Win32-Extend-sqrt-NA_real_-hack-to-all-GCC-versions.patch >> Removes the __GNUC__ <= 4 for Windows ISNAN R_sqrt hack and doesn't >> replace >> it with any version check since I don't see any reason to second-guess >> when >> it might be fixed. When it is fixed in MinGW-w64 we can just remove the >> hack and be happy (I would hope to be able to get round to this in the >> next >> few months). >> > > I can see increasing the version limit when we commit to gcc 5.x, but I > think the point of the test is to remind users of new versions to remind > the developers that they have a bug. If we work around it forever, it will > never get fixed. OK. Am I right in thinking that many GNU/Linux distributions already build R with GCC > 4? The bug here lies with MinGW-w64 and not with GCC. > > >> 0006-Win32-GCC-5.3-Fix-ISNAN-int-emits-UD2-insn.patch >> The reason that boxplot.stats() was crashing was because when isnan() is >> called with an int it emits a UD2 instruction to force a crash, so let us >> just cast the input value to a double to prevent that. The code for this >> can be seen here: >> >> https://github.com/Alexpux/mingw-w64/blob/master/mingw-w64-headers/crt/math.h#L612-L622 >> > > This one I can't guess at without seeing the patch. > Both patches modified the exact same lines in eval.c, so I will need to regenerate it if we are dropping the first patch (and also generate it with svn diff), but I may as well inline it since it's so simple: --- src/main/eval.c2016-04-03 19:46:51.025442100 +0100 +++ src/main/eval.c.new2016-04-03 19:46:48.279325900 +0100 @@ -3624,7 +3624,7 @@ toolchain or in our expectations, but these defines attempt to work around this. */ #if (defined(_WIN32) || defined(_WIN64)) && defined(__GNUC__) -# define R_sqrt(x) (ISNAN(x) ? x : sqrt(x)) +# define R_sqrt(x) (ISNAN((double)x) ? x : sqrt(x)) #else # define R_sqrt sqrt #endif But, we should fix this in MinGW-w64. It's returning a different +/-NaN from the input NaN in contrast to all the other platforms that R runs on, as far as I can gather. In that case, I've proposed a patch to address this issue and if and when this makes it into a release I will send another patch to R's Bugzilla to avoid this hack altogether if using that release or a later version, and otherwise to use a combination of the two patches I supplied earlier. > Duncan Murdoch > > > >> -- >> >> Best regards, >> >> Ray Donnelly, >> >> Continuum Analytics Inc. >> __ >> R-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> >> > [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Optimization bug when byte compiling with gcc 5.3.0 on windows
On Mon, Apr 4, 2016 at 7:39 PM, Jeroen Ooms wrote: > On Sun, Apr 3, 2016 at 6:44 PM, Ray Donnelly > wrote: > > I've started to look into building R for Windows using MSYS2 as both the > > build environment and tools + libraries provider (where possible). > > Thanks for your reply, and for the patches. > No problem. > Last time I had a look at this (a few months ago) another problem was > that mingw-w64 v4 was giving different numeric output for some of the > tests in r-base. If I recall correctly, some eigen vectors had their > direction flipped (negative values became positive and vice versa). > Did you notice anything of this kind when running 'make check' and > 'make check recommended' ? It is important to us that numeric results > are reproducible between versions of R. > I have not seen make check fail with any reports of eigenvector flip. [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Two minor build system patches.
Hi all,
I ran into a few problems building R 3.3.1 and came up wth the
attached patches (fingers crossed they don't get stripped, I've also
sent this email to Jeroen since that worked last time). Would it be
possible to review and merge them if they are OK?
The first one uses AC_SEARCH_LIBS instead of AC_CHECK_LIB, looking for
ncursesw before ncurses since ncurses is usually build with wide
character support in which case non-w prefixed libraries are not
created. ArchLinux (and Conda) then make fake ld linker libraries for
the non-w prefixed ones.
The second patch fixes a typo where CPPFLAGS is misspelt as CPPLAGS
which causes them to be forgotten about in the middle of configure.
Best regards,
Ray.
From 8a101b4c3a78555b416ef70753517638829ee6b5 Mon Sep 17 00:00:00 2001
From: Ray Donnelly
Date: Tue, 21 Jun 2016 14:22:30 +0100
Subject: [PATCH 1/2] Use AC_SEARCH_LIBS to search for ncursesw then ncurses
---
configure| 62 ++--
configure.ac | 2 +-
2 files changed, 40 insertions(+), 24 deletions(-)
diff --git a/configure b/configure
index 00e091d..8187f09 100755
--- a/configure
+++ b/configure
@@ -22737,42 +22737,59 @@ fi
if test "${use_readline}" = no; then
## only need ncurses if libreadline is not statically linked against it
unset ac_cv_lib_readline_rl_callback_read_char
-{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for main in -lncurses" >&5
-$as_echo_n "checking for main in -lncurses... " >&6; }
-if ${ac_cv_lib_ncurses_main+:} false; then :
+{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for library containing initscr" >&5
+$as_echo_n "checking for library containing initscr... " >&6; }
+if ${ac_cv_search_initscr+:} false; then :
$as_echo_n "(cached) " >&6
else
- ac_check_lib_save_LIBS=$LIBS
-LIBS="-lncurses $LIBS"
+ ac_func_search_save_LIBS=$LIBS
cat confdefs.h - <<_ACEOF >conftest.$ac_ext
/* end confdefs.h. */
-
+/* Override any GCC internal prototype to avoid an error.
+ Use char because int might match the return type of a GCC
+ builtin and then its argument prototype would still apply. */
+#ifdef __cplusplus
+extern "C"
+#endif
+char initscr ();
int
main ()
{
-return main ();
+return initscr ();
;
return 0;
}
_ACEOF
-if ac_fn_c_try_link "$LINENO"; then :
- ac_cv_lib_ncurses_main=yes
-else
- ac_cv_lib_ncurses_main=no
+for ac_lib in '' ncursesw curses; do
+ if test -z "$ac_lib"; then
+ac_res="none required"
+ else
+ac_res=-l$ac_lib
+LIBS="-l$ac_lib $ac_func_search_save_LIBS"
+ fi
+ if ac_fn_c_try_link "$LINENO"; then :
+ ac_cv_search_initscr=$ac_res
fi
rm -f core conftest.err conftest.$ac_objext \
-conftest$ac_exeext conftest.$ac_ext
-LIBS=$ac_check_lib_save_LIBS
+conftest$ac_exeext
+ if ${ac_cv_search_initscr+:} false; then :
+ break
fi
-{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_ncurses_main" >&5
-$as_echo "$ac_cv_lib_ncurses_main" >&6; }
-if test "x$ac_cv_lib_ncurses_main" = xyes; then :
- cat >>confdefs.h <<_ACEOF
-#define HAVE_LIBNCURSES 1
-_ACEOF
+done
+if ${ac_cv_search_initscr+:} false; then :
- LIBS="-lncurses $LIBS"
+else
+ ac_cv_search_initscr=no
+fi
+rm conftest.$ac_ext
+LIBS=$ac_func_search_save_LIBS
+fi
+{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_search_initscr" >&5
+$as_echo "$ac_cv_search_initscr" >&6; }
+ac_res=$ac_cv_search_initscr
+if test "$ac_res" != no; then :
+ test "$ac_res" = "none required" || LIBS="$ac_res $LIBS"
else
{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for main in -ltermcap" >&5
@@ -25063,7 +25080,7 @@ _ACEOF
# flags.
r_save_CFLAGS=$CFLAGS
CFLAGS="$CFLAGS $r_verb"
-(eval echo $as_me:25066: \"$ac_link\") >&5
+(eval echo $as_me:25083: \"$ac_link\") >&5
r_c_v_output=`eval $ac_link 5>&1 2>&1 | grep -v 'Driving:'`
echo "$r_c_v_output" >&5
CFLAGS=$r_save_CFLAGS
@@ -25138,7 +25155,7 @@ _ACEOF
# flags.
r_save_CFLAGS=$CFLAGS
CFLAGS="$CFLAGS $r_cv_prog_c_v"
-(eval echo $as_me:25141: \"$ac_link\") >&5
+(eval echo $as_me:25158: \"$ac_link\") >&5
r_c_v_output=`eval $ac_link 5>&1 2>&1 | grep -v 'Driving:'`
echo "$r_c_v_output" >&5
CFLAGS=$r_save_CFLAGS
@@ -41669,7 +41686,6 @@ fi
{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $MKDIR_P" >&5
$as_echo "$MKDIR_P" >&6; }
-
mkdir_p="$MKDIR_P"
case $mkdir_p in
[\\/$]* | ?:[\\/]*) ;;
diff --git a/configure.ac b/configure.a
Re: [Rd] Two minor build system patches.
On Mon, Jun 27, 2016 at 12:07 PM, Duncan Murdoch wrote: > On 27/06/2016 6:58 AM, Ray Donnelly wrote: >> >> Hi all, >> >> I ran into a few problems building R 3.3.1 and came up wth the >> attached patches (fingers crossed they don't get stripped, I've also >> sent this email to Jeroen since that worked last time). Would it be >> possible to review and merge them if they are OK? >> >> The first one uses AC_SEARCH_LIBS instead of AC_CHECK_LIB, looking for >> ncursesw before ncurses since ncurses is usually build with wide >> character support in which case non-w prefixed libraries are not >> created. ArchLinux (and Conda) then make fake ld linker libraries for >> the non-w prefixed ones. >> >> The second patch fixes a typo where CPPFLAGS is misspelt as CPPLAGS >> which causes them to be forgotten about in the middle of configure. >> >> > > Your patches were attached. I'll apply the second one, but I'll leave the > first one for someone who knows the issues. Thanks Duncan. > > Duncan Murdoch > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Debugging tools and practices in Windows?
On Thu, Feb 23, 2017 at 7:49 PM, Tomas Kalibera wrote: > The R for Windows FAQ suggests "make DEBUG=T" and has some more hints > https://cran.r-project.org/bin/windows/base/rw-FAQ.html > > Tomas > > > > On 02/23/2017 08:10 PM, Javier Luraschi wrote: > >> Right, I'm talking about C code. >> >> Do you remember if you had to set specific CFLAGS or other settings to get >> gdb working? I wasn't able to get gdb() working with the standard build >> settings. >> >> Otherwise, Rprintf() would work for sure. >> >> Thank you! >> >> >> >> On Thu, Feb 23, 2017 at 10:55 AM, Duncan Murdoch < >> murdoch.dun...@gmail.com> >> wrote: >> >> On 23/02/2017 1:36 PM, Javier Luraschi wrote: >>> >>> Hello r-devel, could someone share the tools and practices they use to debug the core R sources in Windows? For instance, I would like to set a breakpoint in `gl_loadhistory` and troubleshoot from there. You're talking about debugging the C code rather than the R code, I >>> think. >>> >>> These days I mostly avoid debugging in Windows, but when I have to do it, >>> I use gdb. There used to be a front end for it (Insight) that worked in >>> Windows, but I don't think it works with our current gdb build. Google >> >> names lots of other front ends, but I haven't tried any of them in >>> Windows. >>> >>> I feel Qt Creator provides a good enough UI for debugging things on Windows (it allows you to debug externally-built executables). > The other choice is the old fashioned method: add lots of Rprintf() >>> statements to the source and recompile. >>> >>> Duncan Murdoch >>> >>> >>> [[alternative HTML version deleted]] >> >> __ >> 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 > [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Seeking advice regarding compilation of large libraries using RTools (Windows)
On Mon, Mar 6, 2017 at 8:21 PM, Richard Beare
wrote:
> Yep - simpleITK is available at github.com/SimpleITK/SimpleITK. There's
> also github.com/SimpleITK/SimpleITKRInstaller - a devtools based installer
> for mac and linux.
>
> CMake has a range of build environments. I experimented with MSYS2 and
> mingw makefiles, but had trouble with incompatibilities in the path
> required by CMake and those options - from memory the sh in RTools/bin
> caused problems. Although it sounds like you are saying it is necessary to
> install the MSYS2 system as well.
>
MSYS2 has two variants (3 distinctly named packages) of CMake:
mingw-w64-{i686,x86_64}-cmake and cmake. Which of these (if any) did you
use? I cannot state without experimenting which should be used, but the
mingw-w64 prefixed ones are usually the ones you want to generate native
code.
>
> The unix makefile option for CMake appears to work well until the linking
> stage. Ninja has problems at a similar stage.
>
> I'll steer clear of dll's, as you suggest. I'm checking those links for
> compiler/links flags to see if we're missing anything
>
I would be happy to see if I can get it to compile in the Anaconda
Distribution too. Here we prefer DLLs. The gnu ld linker on Windows is very
slow and doesn't seem to scale too well. I do not expect cross-compiling
would make it much faster. The clang linker (ldd) is nearly viable on
Windows and apparently much faster. I'm not sure if this near-viability is
in relation to using it in msvc mode, gcc mode or both (or even whether it
implements frontends for both).
> Thanks
>
>
>
> On Mon, Mar 6, 2017 at 9:51 PM, Jeroen Ooms wrote:
>
> > On Mon, Mar 6, 2017 at 6:33 AM, Richard Beare
> > wrote:
> > > I am working on the SimpleITK package for R. This is an enormous
> package
> > > that is largely automatically generated via a set of swig/json/lua
> magic,
> > > and is working well under linux and osx.
> >
> > Is it available somewhere so we can try it?
> >
> >
> > > However we're having a lot of trouble with the Windows side. In fact,
> we
> > are struggling to get the base libraries to build using the RTools 3.4
> > toolchain, even before the worrying about the R-specific parts.
> >
> > What build environment do you use? The version of gcc with Rtools
> > should be ok, but the Rtools build utilities in the "bin" folder (in
> > particular 'make') are old and a frequent source of problems. However
> > for building external libs you can use other tools, for example those
> > from msys2. Just make sure you use gcc/g++ from Rtools.
>
>
> >
> > > The current issue is very long time (possibly infinite) linking of
> dlls,
> > or
> > > test executables. I've tried using a FAT32 file system for the build,
> as
> > > suggested by some old bug reports, but still have the issue.
> >
> > On Windows you can avoid the run-time dll mess by building static libs
> > of external libraries. See rwinlib for examples:
> > https://github.com/rwinlib
> >
> >
> > > Any suggestions on where to turn next? Are cross compilers the next
> step?
> >
> > Try building with msys2, but make sure to use gcc/g++ from Rtools by
> > setting the `CC` and `CXX` variables in the configure script. Cross
> > compiling will make things even more complicated because binaries
> > might not be compatible if your cross compiler has a different version
> > of gcc or has been configured for another exception model (seh/drawf).
> >
>
> [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Hyperbolic tangent different results on Windows and Mac
On Mon, Mar 27, 2017 at 12:33 PM, Jeroen Ooms wrote:
> For future reference:
> https://sourceforge.net/p/mingw-w64/mailman/message/35747206/
>
> On Wed, Mar 22, 2017 at 2:12 PM, Jeroen Ooms wrote:
> > This looks like a bug in mingw-w64 CRT. The problem can be produced
> > with C++ without R:
> >
> > #include
> > #include
> > #include
> >
> > int main(){
> > std::cout << std::fixed;
> > std::complex z(356, 0);
> > std::cout << "tanh" << z << " = " << std::tanh(z)
> > << " (tanh(356) = " << std::tanh(356) << ")\n";
> > }
> >
> > On OS-X we get:
> >
> > tanh(356.00,0.00) = (1.00,-0.00) (tanh(356) = 1.00)
> >
> > But on Windows we get:
> >
> > tanh(356.00,0.00) = (nan,0.00) (tanh(356) = 1.00)
> >
> > I was also able to reproduce the problem with gcc 6.3 in msys2 so it
> > has not been fixed upstream. You should file a bug report for
> > mingw-w64.
> >
> > FWIF, we have run into NaN edge-case bugs before with mingw-w64.
> >
> > - https://sourceforge.net/p/mingw-w64/mingw-w64/ci/
> 6617ebd5fc6b790c80071d5b1d950e737fc670e1/
> > - https://github.com/wch/r-source/commit/e9aaf8fdeddf27c2a9078cd214a414
> 75c8ff6f40
> >
> > I am cc'ing Ray Donnelly who is an expert on mingw-w64.
>
Thanks for reporting this Jeroen. Hopefully Doug will take a look sometime
soon.
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
