[Rd] gettext() and messages in 'pkg' domain
Hello, As I understand it, gettext() is designed to retrieve messages from 'R-pkg' domains. As such, it cannot retrieve some of the messages in the 'pkg' domains (those supposed to be accessed by C code only, I know), namely, all messages ending with space(s) or \n. This is clearly indicated in ?gettext (at least for trailing spaces): "For 'gettext', leading and trailing whitespace is ignored when looking for the translation." So, my questions: 1) Do I really need to write C code to retrieve all messages from 'pkg' domain? 2) Wouldn't it be useful to add an argument to gettext() (like trim = TRUE), or alternatively, to propose a Gettext() function in utils packages that allows retrieving those messages with trailing space(s) or \n in 'pkg' domain from R code? Best, Philippe Grosjean __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] gettext() and messages in 'pkg' domain
On Sun, 30 Dec 2007, Philippe Grosjean wrote: > Hello, > > As I understand it, gettext() is designed to retrieve messages from > 'R-pkg' domains. As such, it cannot retrieve some of the messages in the > 'pkg' domains (those supposed to be accessed by C code only, I know), > namely, all messages ending with space(s) or \n. This is clearly > indicated in ?gettext (at least for trailing spaces): > > "For 'gettext', leading and trailing whitespace is ignored when looking > for the translation." (\n _is_ whitespace). > So, my questions: > 1) Do I really need to write C code to retrieve all messages from 'pkg' > domain? Yes. > 2) Wouldn't it be useful to add an argument to gettext() (like trim = > TRUE), or alternatively, to propose a Gettext() function in utils > packages that allows retrieving those messages with trailing space(s) or > \n in 'pkg' domain from R code? Apparently only useful to you: it's certainly not useful for the internationalization of R itself, and I don't see why you can't organize the package so that the C-level messages don't have leading/trailing whitespace *if* you want to mix up domains. -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] gettext() and messages in 'pkg' domain
Prof Brian Ripley wrote: > On Sun, 30 Dec 2007, Philippe Grosjean wrote: > >> Hello, >> >> As I understand it, gettext() is designed to retrieve messages from >> 'R-pkg' domains. As such, it cannot retrieve some of the messages in the >> 'pkg' domains (those supposed to be accessed by C code only, I know), >> namely, all messages ending with space(s) or \n. This is clearly >> indicated in ?gettext (at least for trailing spaces): >> >> "For 'gettext', leading and trailing whitespace is ignored when looking >> for the translation." > > (\n _is_ whitespace). Yes, soory. >> So, my questions: >> 1) Do I really need to write C code to retrieve all messages from 'pkg' >> domain? > > Yes. > >> 2) Wouldn't it be useful to add an argument to gettext() (like trim = >> TRUE), or alternatively, to propose a Gettext() function in utils >> packages that allows retrieving those messages with trailing space(s) or >> \n in 'pkg' domain from R code? > > Apparently only useful to you: it's certainly not useful for the > internationalization of R itself, and I don't see why you can't organize > the package so that the C-level messages don't have leading/trailing > whitespace *if* you want to mix up domains. Messages are is someone else's package. So, I have no control on them! __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] large netCDF files under Windows.
The netcdf code is rather silly: it uses 64-bit versions of seek etc when building a DLL, not on Windows. I can rebuild it using 64-bit seek, but could you please send me (privately) a test case? On Sat, 29 Dec 2007, Thomas Lumley wrote: > > Has anyone successfully used R to access netCDF files larger than 2Gb > under Windows? > > With the version of the ncdf package that Brian Ripley provides for CRAN > extras I get an assertion failure with a 12Gb file, but not a 1Gb subset > of it. The same 12Gb file is ok with ncdf on Mac OS X (32bit R) and on > Linux(64bit R). > > >-thomas > > Thomas Lumley Assoc. Professor, Biostatistics > [EMAIL PROTECTED] University of Washington, Seattle > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] encoding question again
Brian,
On Dec 29, 2007, at 12:28 PM, Prof Brian Ripley wrote:
> On Sat, 29 Dec 2007, Simon Urbanek wrote:
>
>> Oops, this was supposed to be a private reply ;) - sorry about the
>> noise. The essence in English:
>> JGR uses all strings in UTF-8 encoding, but the system locale reports
>> CP1252 which impedes automatic conversions (because R doesn't know
>> that everything is UTF-8). Specific conversion via iconv works as
>> expected (see the example below).
>
> On Windows there are no UTF-8 locales, but you can probably get the
> same effect by marking the strings via Encoding(), as they will be
> converted to CP1252 (a Latin-1 superset) on output.
I was thinking about this before, but I don't have a good solution.
The problem is that there are many places that may be affected.
Especially all callbacks assume UTF-8 and since in R they are passed
as char * they cannot be flagged. It is unfortunate, because JGR
actually facilitates the use of UTF-8 nicely (e.g. you can create
Japanese annotated plots regardless of the Windows locale), but it
cannot pass that ability to R (except silently and sort of
incorrectly). It is, however, surprising how far you can get despite
this conflict (basically it works nicely as long as you don't talk to
the system). Once we force some conversion on callbacks, we lose that
advantage, so I'm still not sure what's the best solution. One semi-
fix would be to take care of the latin1 locales and perform all
conversions there, because they are so limited anyway, that users
working in latin1 locales don't expect anything fancy to work anyway :).
> A console that is running in a non-native encoding needs to convert
> everything going to and from R. We've experimented with running R in
> UTF-8 on Windows, but then you need to convert _everything_ coming
> in and going out and (and this is the killer) so would every package
> with C-level I/O. (Tcl/Tk and Perl have gone down that route, and
> to a large extent left their extensions behind.)
>
I agree. On the other hand, ideally there should be very little direct
I/O in packages and even if it doesn't work in UTF-8, it won't make it
unusable, just limited.
Most projects adopted UTF-8 or unicode as the native encoding. I think
we are on the right track (strings flagged with known encoding) and in
the end we may end up using let's say UTF-8 internally and convert
only for system calls.
We may also end up supporting a similar concept (string+encoding) on
the "edges" sooner or later: something like
WriteConsoleWithEncoding(...) which could flag if possible instead of
converting. Given that the embedding API needs some more
consolidation, it may be a good time to tackle this as well. I'm
hoping to do some cleanup and propose something as a part of the new
ObjC API for R 2.7 and Mac GUI 2.0, so any input is welcome.
Thanks,
Simon
>>
>> On Dec 29, 2007, at 11:11 AM, Simon Urbanek wrote:
>>
>>> Hallo Matthias,
>>>
>>> On Dec 27, 2007, at 3:52 PM, Matthias Wendel wrote:
>>>
Hi, simon,
i followed your advice by adding/changing the lines
abt = iconv(abt,"utf-8","latin1")
zz = file( paste("Itemtabelle/Itemtabelle", abt, ".html"), "wt",
encoding = "latin1")
but this yielded the same results.
>>>
>>> Ich habe endlich eine Windows-Maschine zum Testen und bei mir wird
>>> der
>>> Dateiname richtig angelegt ...
>>>
>>> Dennoch, anscheinend stimmt die locale nicht - denn JGR benutzt
>>> immer
>>> UTF-8, aber das System liefert CP1252. Deswegen scheint die
>>> automatische Konvertierung nicht zu funktionieren
>>> (file(...,encoding..)). Was allerding immer geht, ist die explizite
>>> Konvertierung:
>>>
>>> a=file("foo","wt")
>>> writeLines(iconv(..., "utf-8","latin1"),a)
>>> close(a)
>>>
>>> (FWIW: da die empfohlene Kodierung von Webseiten sowieso UTF-8 ist,
>>> braucht man es eigentlich nicht wirklich ... ;))
>>>
>>> charToRaw ist immer eine guter Test, weil UTF-8 fuer Umlaute meist
>>> 2-
>>> bytes bracht und latin1 nur eins.
>>>
>>> Viele Gruesse,
>>> Simon
>>>
>>>
-Ursprüngliche Nachricht-
Von: Simon Urbanek [mailto:[EMAIL PROTECTED]
Gesendet: Donnerstag, 27. Dezember 2007 21:40
An: Matthias Wendel
Cc: r-devel@r-project.org
Betreff: Re: [Rd] encoding question again
Matthias,
you get exactly what you specified - namely UTF-8. If you want your
html file to be latin1, then you have to say so:
zz = file( paste("Itemtabelle/Itemtabelle", abt, ".html"), "wt",
encoding = "latin1")
In addition, you're assuming that `abt' is in the correct encoding
to be understood by your OS. If it's not, you better convert it
into
one.
From your results it seems as if `abt' is also UTF-8 encoded. Since
you didn't tell us where you got that from, you should either fix
the source or use something like iconv(abt,"utf-8","latin1"):
(in UTF-
Re: [Rd] some questions about startup Rserve
On Dec 30, 2007, at 12:23 AM, 程晓明 wrote:
>I realize the communication between R and Java with Rserve in my
> dissertation, but i can not run the Rserve by double click of
> Rserve.exe,
Use
library(Rserve)
Rserve()
instead. You need to setup PATH correctly in order to run it manually
- please read the documentation it is explained there:
http://www.rforge.net/Rserve/doc.html
> and also i can't realize backstage running of Rserve by technique of
> Multi-thread in Java. Can anyone tell me why?
Windows doesn't have fork(), so you cannot have more than one session
in one Rserve in Windows. Use of a unix computer as a server is highly
recommended as that allows arbitrarily many connections in parallel
with almost zero startup overhead. On Windows you can still spawn
multiple Rserve instances in parallel, but make sure you're not trying
to connect to the same instance twice.
>So, before i run the Java, i must run the R manually, then input
> "Rserve()" or "system("Rserve")". This results in the incompactness
> of my
> software architecture.In order to solve this problem, i have tried
> many
> method.
Again - just read the documentation - all you need is correctly
installed R and R.dll on your PATH.
> For example, i tried to input "Rserve()" to the .Rprofile of R, but
> when i run the R, hundreds of processes were started, then my computer
> system was down. would anyone help me to solve this problem?
Cheers,
Simon
PS: Please use stats-rosuda-devel mailing list for questions on
Rserve, JGR, rJava etc.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Problem with dyn.load'ed code
All,
I am still having trouble dyn.load'ing some code into R. I have
isolated the problem, I wonder if someone could explain what I am
seeing.
I think the problem is that a symbol defined in my compiled code
clashes with one already defined in R. The result is that the function
in my code is not called. Here is an example
// lnktst.cc
extern "C"
{
void func(double *out1, double *out2);
void dnrm2_(double *out);
void dnrm3_(double *out);
}
void func(double *out1, double *out2)
{
dnrm2_(out1);
dnrm3_(out2);
}
void dnrm2_(double *out)
{
*out = 1234.5;
}
void dnrm3_(double *out)
{
*out = 6789.0;
}
// End of lnktst.cc
When I compile:
g++ -shared -static -o lnktst.so lnktst.cc
and then in R I call "func"
> dyn.load("lnktst.so")
> .C('func', double(1), double(1))
[[1]]
[1] 0
[[2]]
[1] 6789
So, as you can see, the function "dnrm2_" is not called whereas "dnrm3_"
is, even though both functions are identical in form. Now, I believe
dnrm2_ is a BLAS function, and so it is likely R already has a copy
floating around. However, it surprises me that the "-static" option does
not force the call in my code to "dnrm2_" to be linked to the function
defined in my code.
I have been writing C code for Splus for quite a while and don't recall
ever running across this issue. However, I am new to R, so I wonder, am
I missing something obvious?
I am running this on Ubuntu Linux, the output of uname -a is:
Linux calder-linux 2.6.22-14-generic #1 SMP Sun Oct 14 23:05:12 GMT 2007 i686
GNU/Linux
Thanks for any help,
Matt
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Problem with dyn.load'ed code
Matt,
On Dec 30, 2007, at 5:25 PM, Matt Calder wrote:
> I am still having trouble dyn.load'ing some code into R. I have
> isolated the problem, I wonder if someone could explain what I am
> seeing.
> I think the problem is that a symbol defined in my compiled code
> clashes with one already defined in R.
The result of redefining a symbol is very much system-dependent. For
example on Mac OS X it has no adverse effects (i.e your symbols are
always private unless linked against), because it uses a two-level
namespace, but on Linux (and most other unices) it does as the
namespace of an executable is shared among all modules (dynamic and
static).
> The result is that the function in my code is not called. Here is an
> example
>
> // lnktst.cc
> extern "C"
> {
> void func(double *out1, double *out2);
> void dnrm2_(double *out);
> void dnrm3_(double *out);
> }
>
> void func(double *out1, double *out2)
> {
> dnrm2_(out1);
> dnrm3_(out2);
> }
>
> void dnrm2_(double *out)
> {
> *out = 1234.5;
> }
>
> void dnrm3_(double *out)
> {
> *out = 6789.0;
> }
> // End of lnktst.cc
>
> When I compile:
>
> g++ -shared -static -o lnktst.so lnktst.cc
>
> and then in R I call "func"
>
>> dyn.load("lnktst.so")
>> .C('func', double(1), double(1))
> [[1]]
> [1] 0
>
> [[2]]
> [1] 6789
>
> So, as you can see, the function "dnrm2_" is not called whereas
> "dnrm3_" is, even though both functions are identical in form. Now,
> I believe dnrm2_ is a BLAS function, and so it is likely R already
> has a copy floating around.
Yes, indeed (it's a BLAS level 1 Fortran function, and usually to be
found in libRblas.so or the external BLAS implementation).
> However, it surprises me that the "-static" option does
> not force the call in my code to "dnrm2_" to be linked to the function
> defined in my code.
You are confusing the purpose of -static: it only ensures that static
libraries are used at link time where possible, it doesn't affect your
code in any way. What you really want is to use
static void dnrm2_(double *out);
in your code instead.
In general, it is a bad idea to use external symbols that clash with
other libraries (in particular widespread ones such as BLAS),
especially if your function doesn't perform the same operation. It is
a good idea to declare all functions that you use internally (i.e.
that should not be visible to R) as static. However, all this is true
for C programming in general, not just in conjunction with R.
Cheers,
Simon
> I have been writing C code for Splus for quite a while and don't
> recall
> ever running across this issue. However, I am new to R, so I wonder,
> am
> I missing something obvious?
> I am running this on Ubuntu Linux, the output of uname -a is:
>
> Linux calder-linux 2.6.22-14-generic #1 SMP Sun Oct 14 23:05:12 GMT
> 2007 i686 GNU/Linux
>
> Thanks for any help,
>
> Matt
>
> __
> 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] Problem with dyn.load'ed code
Simon,
Thanks for the reply. Indeed, declaring the function static fixes the
example. Unfortunately, the real problem that gave rise to the example
arises in a large Fortran library that is not under my control (ARPACK).
The author is providing BLAS and LAPACK functionality intentionally.
That may or may not be good practice, but it is a given in this case.
So, I have a set of Fortran code in which some BLAS functionality is
replicated. I am writing an interface to some of the functions in that
code (not to the BLAS part, that is used internally by ARPACK). I would
like it if that interface did not require alteration of the library
source code or build process (though it is open-source, so if need be I
can change it).
I still feel like the linker ought to be able to solve this problem for
me. My impression was that the static keyword passed to the linker
caused it to resolve all references at link time. So something like:
ld -o my_code_and_arpack.o -static my_code.o -larpack
would pull all the references from the two object files (my_code.o and
libarpack.a) and link them as needed, and unresolved references would
cause an error. I guess that impression is wrong, but how does one
accomplish the same thing?
Thanks for any help,
Matt
On Sun, 2007-12-30 at 20:21 -0500, Simon Urbanek wrote:
> Matt,
>
> On Dec 30, 2007, at 5:25 PM, Matt Calder wrote:
>
> > I am still having trouble dyn.load'ing some code into R. I have
> > isolated the problem, I wonder if someone could explain what I am
> > seeing.
> > I think the problem is that a symbol defined in my compiled code
> > clashes with one already defined in R.
>
> The result of redefining a symbol is very much system-dependent. For
> example on Mac OS X it has no adverse effects (i.e your symbols are
> always private unless linked against), because it uses a two-level
> namespace, but on Linux (and most other unices) it does as the
> namespace of an executable is shared among all modules (dynamic and
> static).
>
>
> > The result is that the function in my code is not called. Here is an
> > example
> >
> > // lnktst.cc
> > extern "C"
> > {
> > void func(double *out1, double *out2);
> > void dnrm2_(double *out);
> > void dnrm3_(double *out);
> > }
> >
> > void func(double *out1, double *out2)
> > {
> > dnrm2_(out1);
> > dnrm3_(out2);
> > }
> >
> > void dnrm2_(double *out)
> > {
> > *out = 1234.5;
> > }
> >
> > void dnrm3_(double *out)
> > {
> > *out = 6789.0;
> > }
> > // End of lnktst.cc
> >
> > When I compile:
> >
> > g++ -shared -static -o lnktst.so lnktst.cc
> >
> > and then in R I call "func"
> >
> >> dyn.load("lnktst.so")
> >> .C('func', double(1), double(1))
> > [[1]]
> > [1] 0
> >
> > [[2]]
> > [1] 6789
> >
> > So, as you can see, the function "dnrm2_" is not called whereas
> > "dnrm3_" is, even though both functions are identical in form. Now,
> > I believe dnrm2_ is a BLAS function, and so it is likely R already
> > has a copy floating around.
>
> Yes, indeed (it's a BLAS level 1 Fortran function, and usually to be
> found in libRblas.so or the external BLAS implementation).
>
>
> > However, it surprises me that the "-static" option does
> > not force the call in my code to "dnrm2_" to be linked to the function
> > defined in my code.
>
> You are confusing the purpose of -static: it only ensures that static
> libraries are used at link time where possible, it doesn't affect your
> code in any way. What you really want is to use
> static void dnrm2_(double *out);
> in your code instead.
>
> In general, it is a bad idea to use external symbols that clash with
> other libraries (in particular widespread ones such as BLAS),
> especially if your function doesn't perform the same operation. It is
> a good idea to declare all functions that you use internally (i.e.
> that should not be visible to R) as static. However, all this is true
> for C programming in general, not just in conjunction with R.
>
> Cheers,
> Simon
>
>
> > I have been writing C code for Splus for quite a while and don't
> > recall
> > ever running across this issue. However, I am new to R, so I wonder,
> > am
> > I missing something obvious?
> > I am running this on Ubuntu Linux, the output of uname -a is:
> >
> > Linux calder-linux 2.6.22-14-generic #1 SMP Sun Oct 14 23:05:12 GMT
> > 2007 i686 GNU/Linux
> >
> > Thanks for any help,
> >
> > Matt
> >
> > __
> > 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] as.Date.numeric origin default
R-devel, I would like to second Gabor Grothendieck's request from September ( http://www.nabble.com/as.Date.numeric-to12962733.html#a12962733 ) on adding a default value (1970-01-01) to the origin argument of as.Date.numeric. I realize there is good reason to allow for origin to be specified, but I don't see why it must be up to the user at each and every invocation if most (if not all) users will simply be using 1970-01-01. My first contact was building quantmod for CRAN - many more hidden errors occur as I test on R-devel. It just seems to me to be an easy compromise to what will undoubtedly cost many hours of debugging across all packages/users. Thank you for your consideration, Jeff Ryan __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
