Re: [Rd] compile fails with x86_64-alpine-linux-uclibc-gcc
On Mon, Aug 13, 2012 at 10:49:26AM -0400, Simon Urbanek wrote:
> I suspect that your runtime/libc is defining fgetc as a macro which breaks
> any code that uses it as an identifier. Ideally, your runtime should be fixed
> to use a proper function, but you could probably work around it with
> something like
>
> static char * fix_fgets(char *s, int n, FILE *stream) { return fgets(s, n,
> stream); }
> #undef fgets
> static char * fgets(char *s, int n, FILE *stream) { return fix_fgets(s, n,
> stream); }
>
> Cheers,
> Simon
like this? :http://bpaste.net/show/40047/
if so, then i get this err msg:
connections.c:385:15: error: static declaration of 'fgets' follows non-static
declaration
/usr/include/stdio.h:544:14: note: previous declaration of 'fgets' was here
connections.c: In function 'Rconn_fgetc':
connections.c:3192:11: error: expected identifier before '(' token
connections.c:3194:15: error: expected identifier before '(' token
and here is how it's declared in stdio.h on my system:
/* Get a newline-terminated string of finite length from STREAM.
This function is a possible cancellation point and therefore not
marked with __THROW. */
extern char *fgets (char *__restrict __s, int __n, FILE *__restrict __stream)
__wur;
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] compile fails with x86_64-alpine-linux-uclibc-gcc
On Aug 13, 2012, at 20:22 , nobody wrote:
> On Mon, Aug 13, 2012 at 10:49:26AM -0400, Simon Urbanek wrote:
>> I suspect that your runtime/libc is defining fgetc as a macro which breaks
>> any code that uses it as an identifier. Ideally, your runtime should be
>> fixed to use a proper function, but you could probably work around it with
>> something like
>>
>> static char * fix_fgets(char *s, int n, FILE *stream) { return fgets(s, n,
>> stream); }
>> #undef fgets
>> static char * fgets(char *s, int n, FILE *stream) { return fix_fgets(s, n,
>> stream); }
>>
>> Cheers,
>> Simon
>
> like this? :http://bpaste.net/show/40047/
> if so, then i get this err msg:
> connections.c:385:15: error: static declaration of 'fgets' follows non-static
> declaration
> /usr/include/stdio.h:544:14: note: previous declaration of 'fgets' was here
> connections.c: In function 'Rconn_fgetc':
> connections.c:3192:11: error: expected identifier before '(' token
> connections.c:3194:15: error: expected identifier before '(' token
>
> and here is how it's declared in stdio.h on my system:
>
> /* Get a newline-terminated string of finite length from STREAM.
>
> This function is a possible cancellation point and therefore not
> marked with __THROW. */
> extern char *fgets (char *__restrict __s, int __n, FILE *__restrict __stream)
> __wur;
Perhaps I'm confused, but how did either of you expect to fix a problem with
fgetc by modifying fgets???
--
Peter Dalgaard, Professor
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Email: pd@cbs.dk Priv: pda...@gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] compile fails with x86_64-alpine-linux-uclibc-gcc
Ouch - typo, misread ...
Sent from my iPhone
On Aug 14, 2012, at 7:48 AM, peter dalgaard wrote:
>
> On Aug 13, 2012, at 20:22 , nobody wrote:
>
>> On Mon, Aug 13, 2012 at 10:49:26AM -0400, Simon Urbanek wrote:
>>> I suspect that your runtime/libc is defining fgetc as a macro which breaks
>>> any code that uses it as an identifier. Ideally, your runtime should be
>>> fixed to use a proper function, but you could probably work around it with
>>> something like
>>>
>>> static char * fix_fgets(char *s, int n, FILE *stream) { return fgets(s, n,
>>> stream); }
>>> #undef fgets
>>> static char * fgets(char *s, int n, FILE *stream) { return fix_fgets(s, n,
>>> stream); }
>>>
>>> Cheers,
>>> Simon
>>
>> like this? :http://bpaste.net/show/40047/
>> if so, then i get this err msg:
>> connections.c:385:15: error: static declaration of 'fgets' follows
>> non-static declaration
>> /usr/include/stdio.h:544:14: note: previous declaration of 'fgets' was here
>> connections.c: In function 'Rconn_fgetc':
>> connections.c:3192:11: error: expected identifier before '(' token
>> connections.c:3194:15: error: expected identifier before '(' token
>>
>> and here is how it's declared in stdio.h on my system:
>>
>> /* Get a newline-terminated string of finite length from STREAM.
>>
>> This function is a possible cancellation point and therefore not
>> marked with __THROW. */
>> extern char *fgets (char *__restrict __s, int __n, FILE *__restrict __stream)
>>__wur;
>
>
> Perhaps I'm confused, but how did either of you expect to fix a problem with
> fgetc by modifying fgets???
>
> --
> Peter Dalgaard, Professor
> Center for Statistics, Copenhagen Business School
> Solbjerg Plads 3, 2000 Frederiksberg, Denmark
> Phone: (+45)38153501
> Email: pd@cbs.dk Priv: pda...@gmail.com
>
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] compile fails with x86_64-alpine-linux-uclibc-gcc
On Tue, Aug 14, 2012 at 01:48:44PM +0200, peter dalgaard wrote: > > Perhaps I'm confused, but how did either of you expect to fix a problem with > fgetc by modifying fgets??? > > -- > Peter Dalgaard, Professor > Center for Statistics, Copenhagen Business School > Solbjerg Plads 3, 2000 Frederiksberg, Denmark > Phone: (+45)38153501 > Email: pd@cbs.dk Priv: pda...@gmail.com i'm not well versed in C. do know how to fix this? or, as i gather, this is not something trivial and it has to be fixed uclibc upstream? __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] compile fails with x86_64-alpine-linux-uclibc-gcc
On Aug 14, 2012, at 10:19 AM, nobody wrote:
> On Tue, Aug 14, 2012 at 01:48:44PM +0200, peter dalgaard wrote:
>>
>> Perhaps I'm confused, but how did either of you expect to fix a problem with
>> fgetc by modifying fgets???
>>
>> --
>> Peter Dalgaard, Professor
>> Center for Statistics, Copenhagen Business School
>> Solbjerg Plads 3, 2000 Frederiksberg, Denmark
>> Phone: (+45)38153501
>> Email: pd@cbs.dk Priv: pda...@gmail.com
>
> i'm not well versed in C. do know how to fix this? or, as i gather, this
> is not something trivial and it has to be fixed uclibc upstream?
>
What Peter is saying that my fix was useless because I was talking about fgetc
but fixed fgets: P
So the fix attempt should have been
static int fix_fgetc(FILE *stream) { return fgetc(stream); }
#undef fgetc
static int fgetc(FILE *stream) { return fix_fgetc(stream); }
It should still be fixed upstream because I don't think POSIX allows fgetc to
be a macro.
Cheers,
Simon
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] as.numeric and as.character with locale using comma as separator
Dear all,
summary:
My LC_NUMERIC is changed from C to de_DE by library (qtbase).
[which shouldn't happen according to the warning when setting it back
manually].
I posted an issue at their github repository, but maybe the behaviour is
a bit more of general interest.
However, if LC_NUMERIC is changed, as.character () uses the decimal
separator that belongs to LC_NUMERIC (and not options ()$OutDec as I
supposed).
as.double () (= as.numeric ()) doesn't, though.
That causes trouble with constructs like
as.numeric (as.character (x))
long version:
as.character seems to take into account my locale (de_DE) which uses
comma as decimal separator:
> x <- rnorm (3)
> x
[1] -0,004238328 -0,919358537 -1,654543297
> as.character(x)
[1] "-0,00423832753479965" "-0,919358536523751" "-1,65454329680873"
whereas as.numeric () doesn't:
> as.numeric (as.character(x))
[1] NA NA NA
Warnmeldung:
NAs durch Umwandlung erzeugt
> as.numeric (gsub (",", ".", as.character(x)))
[1] -0,004238328 -0,919358537 -1,654543297
I did not see any mention in the help of as.numeric nor as.character of
this.
Note also the output of example (as.character):
> example (as.character)
as.chr> form <- y ~ a + b + c
as.chr> as.character(form) ## length 3
[1] "~" "y" "a + b + c"
as.chr> deparse(form) ## like the input
[1] "y ~ a + b + c"
as.chr> a0 <- 11/999 # has a repeating decimal representation
as.chr> (a1 <- as.character(a0))
[1] "0,011011011011011"
as.chr> format(a0, digits=16) # shows one more digit
[1] "0,01101101101101101"
as.chr> a2 <- as.numeric(a1)
as.chr> a2 - a0 # normally around -1e-17
[1] NA
as.chr> as.character(a2) # normally different from a1
[1] NA
as.chr> print(c(a0, a2), digits = 16)
[1] 0,01101101101101101 NA
Warnmeldung:
In eval(expr, envir, enclos) : NAs durch Umwandlung erzeugt
*session info*
> sessionInfo ()
R version 2.15.1 (2012-06-22)
Platform: x86_64-pc-linux-gnu (64-bit)
locale:
[1] de_DE.UTF-8
attached base packages:
[1] splines stats graphics grDevices utils datasets methods
[8] base
other attached packages:
[1] Hmisc_3.9-3 survival_2.36-14 plumbr_0.6.6 cranvas_0.8
[5] maps_2.2-6 scales_0.2.1 qtpaint_0.9.0qtbase_1.0.5
[9] idendro_1.0
loaded via a namespace (and not attached):
[1] cluster_1.14.2 colorspace_1.1-1 dichromat_1.2-4
[4] grid_2.15.1labeling_0.1 lattice_0.20-6
[7] munsell_0.3objectProperties_0.6.5 objectSignals_0.10.2
[10] plyr_1.7.1 RColorBrewer_1.0-5 SearchTrees_0.5.1
[13] stringr_0.6tools_2.15.1 tourr_0.5.2
Note that
> options ()$OutDec
[1] "."
In fresh R sessions I have
locale:
[1] LC_CTYPE=de_DE.UTF-8 LC_NUMERIC=C
[3] LC_TIME=de_DE.UTF-8LC_COLLATE=de_DE.UTF-8
[5] LC_MONETARY=de_DE.UTF-8LC_MESSAGES=de_DE.UTF-8
[7] LC_PAPER=C LC_NAME=C
[9] LC_ADDRESS=C LC_TELEPHONE=C
[11] LC_MEASUREMENT=de_DE.UTF-8 LC_IDENTIFICATION=C
It seems qtbase is the culprit:
> x
[1] -0.2290188 -0.1884703 0.2507179
> library (qtbase)
> x
[1] -0,2290188 -0,1884703 0,2507179
After setting the numeric locale back to C:
> Sys.setlocale ("LC_NUMERIC", "C")
[1] "C"
Warnmeldung:
In Sys.setlocale("LC_NUMERIC", "C") :
das Setzen von 'LC_NUMERIC' kann bewirken, dass R sich komisch benimmt
as.numeric (as.character (x)) works as supposed (also output has decimal
points again)
Best,
Claudia
--
Claudia Beleites
Spectroscopy/Imaging
Institute of Photonic Technology
Albert-Einstein-Str. 9
07745 Jena
Germany
email: claudia.belei...@ipht-jena.de
phone: +49 3641 206-133
fax: +49 2641 206-399
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] chown, chgrp?
Hi all, Is there an R wrapper for chown/chgrp (a la Sys.chmod)? I couldn't find one with a few minutes of searching, but it seems like a curious omission. Thanks, Hadley -- Assistant Professor Department of Statistics / Rice University http://had.co.nz/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] compile fails with x86_64-alpine-linux-uclibc-gcc
On Tue, Aug 14, 2012 at 10:32:22AM -0400, Simon Urbanek wrote:
>
> On Aug 14, 2012, at 10:19 AM, nobody wrote:
>
> > On Tue, Aug 14, 2012 at 01:48:44PM +0200, peter dalgaard wrote:
> >>
> >> Perhaps I'm confused, but how did either of you expect to fix a problem
> >> with fgetc by modifying fgets???
> >>
> >> --
> >> Peter Dalgaard, Professor
> >> Center for Statistics, Copenhagen Business School
> >> Solbjerg Plads 3, 2000 Frederiksberg, Denmark
> >> Phone: (+45)38153501
> >> Email: pd@cbs.dk Priv: pda...@gmail.com
> >
> > i'm not well versed in C. do know how to fix this? or, as i gather, this
> > is not something trivial and it has to be fixed uclibc upstream?
> >
>
> What Peter is saying that my fix was useless because I was talking about
> fgetc but fixed fgets: P
> So the fix attempt should have been
>
> static int fix_fgetc(FILE *stream) { return fgetc(stream); }
> #undef fgetc
> static int fgetc(FILE *stream) { return fix_fgetc(stream); }
>
> It should still be fixed upstream because I don't think POSIX allows fgetc to
> be a macro.
>
> Cheers,
> Simon
thanks, 's:^static:extern:' and it works, well sort of. now compilation
gets stuck (waited 3 hours) here:
make[6]: Entering directory
`/dev/shm/portage/dev-lang/R-2.15.1/work/R-2.15.1/src/library/tools/src'
mkdir -p -- ../../../../library/tools/libs
make[6]: Leaving directory
`/dev/shm/portage/dev-lang/R-2.15.1/work/R-2.15.1/src/library/tools/src'
make[5]: Leaving directory
`/dev/shm/portage/dev-lang/R-2.15.1/work/R-2.15.1/src/library/tools/src'
make[4]: Leaving directory
`/dev/shm/portage/dev-lang/R-2.15.1/work/R-2.15.1/src/library/tools'
it's apparently running:
/dev/shm/portage/dev-lang/R-2.15.1/work/R-2.15.1/bin/exec/R --vinalla --slave
with 100% cpu usage! i don't what it's doing to be honest :) any idea?
p.s.: i'm attaching the patch to this for the curious, hope it helps.
--- src/main/connections.c.orig 2012-08-14 11:47:47.105203896 -0400
+++ src/main/connections.c 2012-08-14 11:50:49.103928599 -0400
@@ -378,6 +378,16 @@
return res;
}
+#ifdef __UCLIBC__
+ extern int fix_fgetc(FILE *stream) {
+ return fgetc(stream);
+ }
+ #undef fgetc
+ extern int fgetc(FILE *stream) {
+ return fix_fgetc(stream);
+ }
+#endif
+
int dummy_fgetc(Rconnection con)
{
int c;
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
