Re: [Rd] Perhaps a stupid question about clipboards....
> "Byron" == Byron Ellis <[EMAIL PROTECTED]> > on Wed, 10 Jan 2007 21:25:45 -0800 writes: Byron> I have a stupid question. not stupid. Byron> Why is the clipboard accessed through file() and not, Byron> say, a clipboard() connection? Is there a good reason Byron> for this or is it simply historical? Why use a new function name for just one special case? Or do you ask because it would help *find* the feature? Martin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Perhaps a stupid question about clipboards....
On Wed, 10 Jan 2007, Byron Ellis wrote:
> I have a stupid question. Why is the clipboard accessed through file()
> and not, say, a clipboard() connection? Is there a good reason for
> this or is it simply historical?
You can in most uses replace file("clipboard") by "clipboard".
In fact internally file, clipboard and url connections are separate (and
show up so under showConnections), but all three can be accessed via
file().
--
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] Installation on CYGWIN Failed (PR#9442)
CYGWIN is not a supported system, so why have you filed a bug report on a
help request? This is a volunteer project, and we need users of minority
platforms to support the developers, not v.v.
You could have sought help on the R-devel list, and save the developers
needless work.
One reason it is not supported is that it does not have a standard dlopen,
and apparently (I am not sure what libtool did here) does not allow
unresolved symbols in modules as dlopen would.
The actual linker command that failed is missing in your output below.
It used to be possible to build the Windows port of R under Cygwin (and
may still be), but we gave up supporting that some years ago.
On Thu, 11 Jan 2007, [EMAIL PROTECTED] wrote:
> This is a multi-part message in MIME format.
>
> --Boundary_(ID_0J8TMtVXSg+LJn2Si9guUw)
> Content-type: text/plain; charset=us-ascii
> Content-transfer-encoding: 7BIT
>
> Hi,
>
>
>
> I tried to install R-2.4.1 on cygwin system. "./configure" succeeded, but
> make failed. Below, I provide the output from the process: error message,
> and info from configure output, in that order. I appreciate that someone can
> guide me (technically in-sophisticated) through this process.
>
>
>
> Again, thanks for your help.
>
>
>
> Michael Niu
>
>
>
> (1). Output from make
>
>
>
> make[3]: Entering directory `/R/R-2.4.1/src/extra/blas'
>
> make[4]: Entering directory `/R/R-2.4.1/src/extra/blas'
>
> g77 -D__NO_MATH_INLINES -fpic -g -O2 -c blas.f -o blas.o
>
> blas.f:0: warning: -fpic ignored for target (all code is position
> independent)
>
> g77 -D__NO_MATH_INLINES -fpic -g -O2 -c cmplxblas.f -o cmplxblas.o
>
> cmplxblas.f:0: warning: -fpic ignored for target (all code is position
> independent)
>
> gcc -std=gnu99 -shared -L/usr/local/lib -o libRblas.so blas.o cmplxblas.o
>
> blas.o: In function `dgbmv_':
>
> /R/R-2.4.1/src/extra/blas/blas.f:357: undefined reference to `_xerbla_'
>
> blas.o: In function `dgemm_':
>
> /R/R-2.4.1/src/extra/blas/blas.f:682: undefined reference to `_xerbla_'
>
> blas.o: In function `dgemv_':
>
> /R/R-2.4.1/src/extra/blas/blas.f:940: undefined reference to `_xerbla_'
>
> blas.o: In function `dger_':
>
> /R/R-2.4.1/src/extra/blas/blas.f:1171: undefined reference to `_xerbla_'
>
> blas.o: In function `dsbmv_':
>
> /R/R-2.4.1/src/extra/blas/blas.f:1800: undefined reference to `_xerbla_'
>
> blas.o:/R/R-2.4.1/src/extra/blas/blas.f:2183: more undefined references to
> `_xerbla_' follow
>
> cmplxblas.o: In function `zrotg_':
>
> /R/R-2.4.1/src/extra/blas/cmplxblas.f:5579: undefined reference to `_z_abs'
>
> /R/R-2.4.1/src/extra/blas/cmplxblas.f:5585: undefined reference to `_z_abs'
>
> /R/R-2.4.1/src/extra/blas/cmplxblas.f:5585: undefined reference to `_z_abs'
>
> /R/R-2.4.1/src/extra/blas/cmplxblas.f:5586: undefined reference to `_z_abs'
>
> /R/R-2.4.1/src/extra/blas/cmplxblas.f:5586: undefined reference to `_z_abs'
>
> cmplxblas.o:/R/R-2.4.1/src/extra/blas/cmplxblas.f:5588: more undefined
> references to `_z_abs' follow
>
> cmplxblas.o: In function `zsymm_':
>
> /R/R-2.4.1/src/extra/blas/cmplxblas.f:5778: undefined reference to
> `_xerbla_'
>
> cmplxblas.o: In function `zsyr2k_':
>
> /R/R-2.4.1/src/extra/blas/cmplxblas.f:6071: undefined reference to
> `_xerbla_'
>
> cmplxblas.o: In function `zsyrk_':
>
> /R/R-2.4.1/src/extra/blas/cmplxblas.f:6376: undefined reference to
> `_xerbla_'
>
> cmplxblas.o: In function `ztbmv_':
>
> /R/R-2.4.1/src/extra/blas/cmplxblas.f:6684: undefined reference to
> `_xerbla_'
>
> cmplxblas.o: In function `ztbsv_':
>
> /R/R-2.4.1/src/extra/blas/cmplxblas.f:7065: undefined reference to
> `_xerbla_'
>
> cmplxblas.o:/R/R-2.4.1/src/extra/blas/cmplxblas.f:7398: more undefined
> references to `_xerbla_' fol
>
> ow
>
> collect2: ld returned 1 exit status
>
> make[4]: *** [libRblas.so] Error 1
>
> make[4]: Leaving directory `/R/R-2.4.1/src/extra/blas'
>
> make[3]: *** [R] Error 2
>
> make[3]: Leaving directory `/R/R-2.4.1/src/extra/blas'
>
> make[2]: *** [R] Error 1
>
> make[2]: Leaving directory `/R/R-2.4.1/src/extra'
>
> make[1]: *** [R] Error 1
>
> make[1]: Leaving directory `/R/R-2.4.1/src'
>
> make: *** [R] Error 1
>
>
>
> (2). Output from configure
>
>
>
> uname -m = i686
>
> uname -r = 1.5.19(0.150/4/2)
>
> uname -s = CYGWIN_NT-5.1
>
> uname -v = 2006-01-20 13:28
>
>
>
> /usr/bin/uname -p = unknown
>
> /bin/uname -X = unknown
>
>
>
> /bin/arch = unknown
>
> /usr/bin/arch -k = unknown
>
> /usr/convex/getsysinfo = unknown
>
> hostinfo = unknown
>
> /bin/machine = unknown
>
> /usr/bin/oslevel = unknown
>
> /bin/universe = unknown
>
>
>
> PATH: .
>
> PATH: /usr/bin
>
> PATH: /usr/lib/lapack/
>
> PATH: /usr/X11R6
>
> PATH: /home/zniu/bin
>
> PATH: ${PATH}
>
> PATH: /.
>
> PATH: ${HOME}/bin
>
> PATH: x
>
> PATH: /cygwin/bin
>
>
>
> .
>
>
>
> configure: exit 0
>
>
>
> R is now configured for i686-pc-cygwin
>
>
>
> Source directory: .
>
> Installation directory:/usr/local
>
Re: [Rd] wine and build difference between R.2.4.0 and R 2.4.1 windows binaries?
Duncan Murdoch wrote: > On 1/10/2007 2:29 PM, Hin-Tak Leung wrote: >> Does anybody (most probably the core team) know if there is >> any difference in how the official 2.4.0 and 2.4.1 binaries are >> built? >> >> Problem is, 2.4.0 loads with the wine (I tried a few recent >> versions, and also used 2.3.x under wine from time to time), >> but 2.4.1 won't. > > Yes, there were changes to the MinGW run-time library between those two > releases. See http://www.murdoch-sutherland.com/Rtools/. > > If you can be more specific about the problem, it's possible the Wine or > MinGW people could fix it. With 2.4.1, "wine Rgui.exe" launches the main Rgui window, then crashes and dropped with debug traces without being able to get to the Rconsole tab. Logically it is a wine "bug", since the same binary runs under genuine windows, but it looks like it is due to change from mingw, so I guess I should involve both parties. BTW, I am also cross-compiling some R packages with the cross tools provided by Prof Ripley. Presumably it means that I need to hack away the bundled mingw stuff in the cross-tool and replaced them with the newer mingw libraries as well? (the whole thing with wine is so that I can cross-compile and test right away...) Hin-Tak __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] wine and build difference between R.2.4.0 and R 2.4.1 windows binaries?
On 1/11/2007 6:52 AM, Hin-Tak Leung wrote:
> Duncan Murdoch wrote:
>> On 1/10/2007 2:29 PM, Hin-Tak Leung wrote:
>>> Does anybody (most probably the core team) know if there is
>>> any difference in how the official 2.4.0 and 2.4.1 binaries are
>>> built?
>>>
>>> Problem is, 2.4.0 loads with the wine (I tried a few recent
>>> versions, and also used 2.3.x under wine from time to time),
>>> but 2.4.1 won't.
>> Yes, there were changes to the MinGW run-time library between those two
>> releases. See http://www.murdoch-sutherland.com/Rtools/.
>>
>> If you can be more specific about the problem, it's possible the Wine or
>> MinGW people could fix it.
>
> With 2.4.1, "wine Rgui.exe" launches the main Rgui window, then crashes
> and dropped with debug traces without being able to get to the
> Rconsole tab. Logically it is a wine "bug", since the same binary
> runs under genuine windows, but it looks like it is due to change
> from mingw, so I guess I should involve both parties.
I'd suggest trying a build with debug information ("make distclean; make
DEBUG=T"), so that the debug trace has symbol names and line information
in it. I could easily do such a build of R-patched or R-devel for you
if you want to try this.
>
> BTW, I am also cross-compiling some R packages with the cross tools
> provided by Prof Ripley. Presumably it means that I need to hack away
> the bundled mingw stuff in the cross-tool and replaced them with the
> newer mingw libraries as well? (the whole thing with wine is so that I
> can cross-compile and test right away...)
I've never used the cross-compiling tools, so I can't help you with this.
Duncan Murdoch
> Hin-Tak
>
> __
> 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] wine and build difference between R.2.4.0 and R 2.4.1 windows binaries?
On Thu, 11 Jan 2007, Hin-Tak Leung wrote: > Duncan Murdoch wrote: >> On 1/10/2007 2:29 PM, Hin-Tak Leung wrote: >>> Does anybody (most probably the core team) know if there is >>> any difference in how the official 2.4.0 and 2.4.1 binaries are >>> built? >>> >>> Problem is, 2.4.0 loads with the wine (I tried a few recent >>> versions, and also used 2.3.x under wine from time to time), >>> but 2.4.1 won't. >> >> Yes, there were changes to the MinGW run-time library between those two >> releases. See http://www.murdoch-sutherland.com/Rtools/. >> >> If you can be more specific about the problem, it's possible the Wine or >> MinGW people could fix it. > > With 2.4.1, "wine Rgui.exe" launches the main Rgui window, then crashes > and dropped with debug traces without being able to get to the > Rconsole tab. Logically it is a wine "bug", since the same binary > runs under genuine windows, but it looks like it is due to change > from mingw, so I guess I should involve both parties. > > BTW, I am also cross-compiling some R packages with the cross tools provided > by Prof Ripley. Presumably it means that I need to hack away > the bundled mingw stuff in the cross-tool and replaced them with the newer > mingw libraries as well? (the whole thing with wine is so that I can > cross-compile and test right away...) My belief is that the cross-tools I package build R 2.4.x but need updating for 2.5.0. As I use x86_64 cross tools for R-devel it does not affect me, but I will rebuild the tools on an i386 box in due course. -- 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
[Rd] Wishlist: Sweave: allow line breaks after forward slashes (PR#9443)
Full_Name: Arne Henningsen
Version: 2.4.0
OS: Linux
Submission from: (NULL) (134.245.140.242)
Sweave does not allow line breaks after forward slashes ("/"). This might lead
to a long "substring" of a command that cannot be wrapped. Hence, Sweave either
keeps this long "substring" in the current line and produces a too long line or
it moves the entire "substring" in the following line and leaves the current
line rather empty. This problem can be solved if Sweave is allowed to introduce
line breaks after forward slashes. (I guess that this problem can also be solved
if parse() adds a blank after a forward slash.)
Example:
The following expression cannot be wrapped by Sweave:
mean(myDataframe$myFirstVariable)/mean(myDataframe$mySecondVariable)
Thanks for the great software packages (R, Sweave, ...),
Arne
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Wishlist: Sweave: allow line breaks after forward slashes (PR#9443)
> On Thu, 11 Jan 2007 15:07:00 +0100 (CET),
> ahenningsen (a) wrote:
> Full_Name: Arne Henningsen
> Version: 2.4.0
> OS: Linux
> Submission from: (NULL) (134.245.140.242)
> Sweave does not allow line breaks after forward slashes ("/"). This might
lead
> to a long "substring" of a command that cannot be wrapped. Hence, Sweave
either
> keeps this long "substring" in the current line and produces a too long
line or
> it moves the entire "substring" in the following line and leaves the current
> line rather empty. This problem can be solved if Sweave is allowed to
introduce
> line breaks after forward slashes. (I guess that this problem can also be
solved
> if parse() adds a blank after a forward slash.)
> Example:
> The following expression cannot be wrapped by Sweave:
> mean(myDataframe$myFirstVariable)/mean(myDataframe$mySecondVariable)
In R 2.5.0 you can use Sweave option keep.source=TRUE to keep the
original formatting of source code, including all indentation and line
breaks -> does this solve your problem?
Best,
Fritz Leisch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] wine and build difference between R.2.4.0 and R 2.4.1 windows binaries?
Duncan Murdoch wrote:
> On 1/11/2007 6:52 AM, Hin-Tak Leung wrote:
>> Duncan Murdoch wrote:
>>> On 1/10/2007 2:29 PM, Hin-Tak Leung wrote:
Does anybody (most probably the core team) know if there is
any difference in how the official 2.4.0 and 2.4.1 binaries are
built?
Problem is, 2.4.0 loads with the wine (I tried a few recent
versions, and also used 2.3.x under wine from time to time),
but 2.4.1 won't.
>>> Yes, there were changes to the MinGW run-time library between those
>>> two releases. See http://www.murdoch-sutherland.com/Rtools/.
>>>
>>> If you can be more specific about the problem, it's possible the Wine
>>> or MinGW people could fix it.
>>
>> With 2.4.1, "wine Rgui.exe" launches the main Rgui window, then crashes
>> and dropped with debug traces without being able to get to the
>> Rconsole tab. Logically it is a wine "bug", since the same binary
>> runs under genuine windows, but it looks like it is due to change
>> from mingw, so I guess I should involve both parties.
>
> I'd suggest trying a build with debug information ("make distclean; make
> DEBUG=T"), so that the debug trace has symbol names and line information
> in it. I could easily do such a build of R-patched or R-devel for you
> if you want to try this.
Thanks for the offer; but I think wine should cope as anything runs
under windows should run, so I am inclined on playing with wine a bit to
see if I can get it to tell me a bit more about what it is not
happy about 2.4.1. wine just should not be sensitive to mingw versions.
Hin-Tak
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Wishlist: Sweave: allow line breaks after forward slashes (PR#9444)
> On Thu, 11 Jan 2007 15:07:00 +0100 (CET),
> ahenningsen (a) wrote:
> Full_Name: Arne Henningsen
> Version: 2.4.0
> OS: Linux
> Submission from: (NULL) (134.245.140.242)
> Sweave does not allow line breaks after forward slashes ("/"). This might
lead
> to a long "substring" of a command that cannot be wrapped. Hence, Sweave
either
> keeps this long "substring" in the current line and produces a too long
line or
> it moves the entire "substring" in the following line and leaves the current
> line rather empty. This problem can be solved if Sweave is allowed to
introduce
> line breaks after forward slashes. (I guess that this problem can also be
solved
> if parse() adds a blank after a forward slash.)
> Example:
> The following expression cannot be wrapped by Sweave:
> mean(myDataframe$myFirstVariable)/mean(myDataframe$mySecondVariable)
In R 2.5.0 you can use Sweave option keep.source=TRUE to keep the
original formatting of source code, including all indentation and line
breaks -> does this solve your problem?
Best,
Fritz Leisch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Wishlist: Sweave: allow line breaks after forward slashes (PR#9443)
On 1/11/2007 9:07 AM, [EMAIL PROTECTED] wrote:
> Full_Name: Arne Henningsen
> Version: 2.4.0
> OS: Linux
> Submission from: (NULL) (134.245.140.242)
>
>
> Sweave does not allow line breaks after forward slashes ("/"). This might lead
> to a long "substring" of a command that cannot be wrapped. Hence, Sweave
> either
> keeps this long "substring" in the current line and produces a too long line
> or
> it moves the entire "substring" in the following line and leaves the current
> line rather empty. This problem can be solved if Sweave is allowed to
> introduce
> line breaks after forward slashes. (I guess that this problem can also be
> solved
> if parse() adds a blank after a forward slash.)
>
> Example:
> The following expression cannot be wrapped by Sweave:
>
> mean(myDataframe$myFirstVariable)/mean(myDataframe$mySecondVariable)
It's actually deparse() that causes this, but the problem is already
solved in R-devel (to become R 2.5.0). If you don't like the formatting
that deparse() gives to one of your expressions, use the Sweave option
keep.source=TRUE, and your original formatting will be kept for that
chunk. Or globally retain your formatting via
\SweaveOpts{keep.source=TRUE} at the start of your file.
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Wishlist: Sweave: allow line breaks after forward slashes (PR#9445)
On 1/11/2007 9:07 AM, [EMAIL PROTECTED] wrote:
> Full_Name: Arne Henningsen
> Version: 2.4.0
> OS: Linux
> Submission from: (NULL) (134.245.140.242)
>
>
> Sweave does not allow line breaks after forward slashes ("/"). This might lead
> to a long "substring" of a command that cannot be wrapped. Hence, Sweave
> either
> keeps this long "substring" in the current line and produces a too long line
> or
> it moves the entire "substring" in the following line and leaves the current
> line rather empty. This problem can be solved if Sweave is allowed to
> introduce
> line breaks after forward slashes. (I guess that this problem can also be
> solved
> if parse() adds a blank after a forward slash.)
>
> Example:
> The following expression cannot be wrapped by Sweave:
>
> mean(myDataframe$myFirstVariable)/mean(myDataframe$mySecondVariable)
It's actually deparse() that causes this, but the problem is already
solved in R-devel (to become R 2.5.0). If you don't like the formatting
that deparse() gives to one of your expressions, use the Sweave option
keep.source=TRUE, and your original formatting will be kept for that
chunk. Or globally retain your formatting via
\SweaveOpts{keep.source=TRUE} at the start of your file.
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] cross tools (was Re: wine and build difference between R.2.4.0 and R 2.4.1 windows binaries?)
Prof Brian Ripley wrote: > On Thu, 11 Jan 2007, Hin-Tak Leung wrote: >> >> BTW, I am also cross-compiling some R packages with the cross tools >> provided by Prof Ripley. Presumably it means that I need to hack away >> the bundled mingw stuff in the cross-tool and replaced them with the >> newer mingw libraries as well? (the whole thing with wine is so that I >> can cross-compile and test right away...) > > My belief is that the cross-tools I package build R 2.4.x but need > updating for 2.5.0. > > As I use x86_64 cross tools for R-devel it does not affect me, but I > will rebuild the tools on an i386 box in due course. My main use of the cross-tool is to build the windows binary of a custom R package (rather than R itself) - so that I can distribute it (after testing on some windows machines which are not equiped with development tools), so it is more important that the cross tool generates binaries which are compatible with the latest official windows binary distribution, rather than being able to build the latest development source as a whole. FWIW, I use the i386 cross-tool provided on x86_64, and also build wine as 32-bit and runs windows R that way. I am not even sure if it is possible to dual-boot windows on opteron if I had wanted to. (a waste, in any case...). It might be worth building the cross tools as 32-bit on x86_64 just so that what you use is the same as what you give away :-)? (I only routinely build 3 packages as 32-bit rather than 64-bit on x86_64 - R for memory consumption, wine because it just isn't written for 64-bit, and ghostscript because a lot of font-rendering issues are 32-bit/64-bit sensitive). Hin-Tak __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Miniscule patch to internet.c
Looks like a benign copy-paste issue. This is in R_newurl, and I doubt
anyone would miss that one byte, though.
Index: src/modules/internet/internet.c
===
--- src/modules/internet/internet.c (revision 40446)
+++ src/modules/internet/internet.c (working copy)
@@ -167,7 +167,7 @@
new = (Rconnection) malloc(sizeof(struct Rconn));
if(!new) error(_("allocation of url connection failed"));
-new->class = (char *) malloc(strlen("file") + 1);
+new->class = (char *) malloc(strlen("url") + 1);
if(!new->class) {
free(new);
error(_("allocation of url connection failed"));
Jeff
--
http://biostat.mc.vanderbilt.edu/JeffreyHorner
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Perhaps a stupid question about clipboards....
On 1/11/07, Martin Maechler <[EMAIL PROTECTED]> wrote: > Byron> Why is the clipboard accessed through file() and not, > Byron> say, a clipboard() connection? Is there a good reason > Byron> for this or is it simply historical? > > Why use a new function name for just one special case? > Or do you ask because it would help *find* the feature? For the same reason that pipes have their own function? Additionally, some systems have named clipboards (e.g. OS X and IIRC X11, though that may require an extension of some sort) that you might want to access explicitly. Actually, ?clipboard turns up the right help page so if you didn't know that there wasn't such a function you'd end up at the right place (if perhaps a bit confused). As it happens, I use OS X so I had to use pipe() since there isn't built in functionality. :-) > > Martin > -- Byron Ellis ([EMAIL PROTECTED]) "Oook" -- The Librarian __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
