Re: [Rd] confusion about evaluation.
On Sun, 20 Jul 2008, James Bullard wrote:
Hi All, I am confused about the following code. I thought that the problem
stemmed from lazy evaluation and the fact that 'i' is never evaluated within
the first lapply. However, I am then confused as to why it gets bound to the
final element of the lapply.
Correct. 'i' in the environments is a promise, and it gets the value at
the time the promise is evaluated from the environment in which the
promise is created. Since you don't evaluate it until after the lapply,
the environment in which the promise is evaluated has the final value at
that time. BTW, the following variant
x - vector(list, 4)
for(i in 1:3) x[[i]] - function() i^2
sapply(1:3, function(i) x[[i]]())
works the same way.
Lazy evaluation works somewhat differently in R and in S -- I've never
seen a comprehensive discussion as to why (nor exactly how it works in
either system, although there is a lot about promises in the 'R Internals'
manual).
The environments of the returned functions are
indeed different in both cases and each environment has a local binding for
'i' it just happens to be 3 -- which I will say is wrong, but I await
reeducation.
I looked for documentation concerning this, but I wasn't able to find
anything -- I imagine that this must be documented somewhere as it appears
like a reasonable thing to do. Thank you as always for any insight. -- jim
## doesn't do what I think it should
x - lapply(1:3, function(i) {
function() { i^2 }
})
sapply(1:3, function(i) x[[i]]())
[1] 9 9 9
## does what I expect
x - lapply(1:3, function(i) {
print(i)
function() { i^2 }
})
[1] 1
[1] 2
[1] 3
sapply(1:3, function(i) x[[i]]())
[1] 1 4 9
sessionInfo()
R version 2.7.1 Patched (2008-07-20 r46088)
i386-apple-darwin9.4.0
locale:
en_US.UTF-8/en_US.UTF-8/C/C/en_US.UTF-8/en_US.UTF-8
attached base packages:
[1] stats graphics grDevices utils datasets methods base
__
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] License Conflict?
GaGr == Gabor Grothendieck [EMAIL PROTECTED] on Sun, 20 Jul 2008 19:51:50 -0400 writes: GaGr Is this a true problem? No; as Oholoh mentions there are only two files which mention the artistic licence, namely src/main/apse.[ch] and these two contain Copyright (C) by Jarkko Hietaniemi, 1998,1999,2000,2001,2002,2003,2006. All Rights Reserved. This program is free software; you can redistribute it and/or modify it under the terms of either: a) the GNU Library General Public License as published by the Free Software Foundation; either version 2, or (at your option) any later version, or b) the Artistic License which comes with Perl source code. so they are exactly from the group mentioned below as the code in question may be available under multiple licenses Thank you, Gabor, for asking. Martin Maechler ETH Zurich and R Core Team GaGr Artistic License may conflict GaGr with GPL The source code for R contains references to GaGr both the GNU General Public License 2.0 (GPL) and to GaGr the Artistic License. These two licenses include some GaGr contradictory restrictions. GaGr The Ohloh source code parser is exhaustive, and can GaGr reveal licensing requirements which the developers GaGr themselves may have overlooked or forgotten. GaGr This message is merely a warning. There may not GaGr actually be any conflict, because the two licenses may GaGr not apply to the exact same sections of code or the GaGr code in question may be available under multiple GaGr licenses. You should review the license requirements GaGr for this project carefully, especially if you are GaGr using this code for commercial purposes. GaGr The GNU Project maintains a guide to GPL compatibility GaGr at their web site. GaGr Above is at this page: GaGr http://www.ohloh.net/projects/3926/factoids/632981 GaGr __ GaGr R-devel@r-project.org mailing list GaGr 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] License Conflict?
On Mon, 21 Jul 2008, Martin Maechler wrote: GaGr == Gabor Grothendieck [EMAIL PROTECTED] on Sun, 20 Jul 2008 19:51:50 -0400 writes: GaGr Is this a true problem? No; as Oholoh mentions there are only two files which mention the artistic licence, namely src/main/apse.[ch] Apart from the licences themselves in share/licenses! There is a potential issue with packages that use an Artistic licence (the quoter seems ignorant of the fact that there are more than one), but that applies to any package license other than GPL2 and is the responsibility of the package owner to check. Also, some files in share/perl are 'under the same terms as Perl itself', that is Artistic or GPL. and these two contain Copyright (C) by Jarkko Hietaniemi, 1998,1999,2000,2001,2002,2003,2006. All Rights Reserved. This program is free software; you can redistribute it and/or modify it under the terms of either: a) the GNU Library General Public License as published by the Free Software Foundation; either version 2, or (at your option) any later version, or b) the Artistic License which comes with Perl source code. so they are exactly from the group mentioned below as the code in question may be available under multiple licenses Thank you, Gabor, for asking. Martin Maechler ETH Zurich and R Core Team GaGr Artistic License may conflict GaGr with GPL The source code for R contains references to GaGr both the GNU General Public License 2.0 (GPL) and to GaGr the Artistic License. These two licenses include some GaGr contradictory restrictions. GaGr The Ohloh source code parser is exhaustive, and can GaGr reveal licensing requirements which the developers GaGr themselves may have overlooked or forgotten. GaGr This message is merely a warning. There may not GaGr actually be any conflict, because the two licenses may GaGr not apply to the exact same sections of code or the GaGr code in question may be available under multiple GaGr licenses. You should review the license requirements GaGr for this project carefully, especially if you are GaGr using this code for commercial purposes. GaGr The GNU Project maintains a guide to GPL compatibility GaGr at their web site. GaGr Above is at this page: GaGr http://www.ohloh.net/projects/3926/factoids/632981 GaGr __ GaGr R-devel@r-project.org mailing list GaGr https://stat.ethz.ch/mailman/listinfo/r-devel __ 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] garbage collection, preserved variables, and different outcome depending on --verbose or not
I just tried with R-devel (2.8.0 Under development (unstable)
(2008-07-20 r46088),
the problem does not appear with that version.
Thanks,
L.
2008/7/20 Laurent Gautier [EMAIL PROTECTED]:
2008/7/20 Duncan Murdoch [EMAIL PROTECTED]:
On 20/07/2008 10:02 AM, Laurent Gautier wrote:
I tripped on that while crafting the example.
The problem still exists when moving the releases in the middle,
and removing the last release.
I also see that the C code contains old/irrelevant comments at the top
of the function
lostobject. Sorry about that, the bug I am chasing is elusive...
I can't spot any problems in the new version of your code, but I can't
reproduce the problem, either. So it appears to be system specific -- I was
using the identical revision as you, but on Windows, not
x86_64-unknown-linux-gnu. What exact Linux is that?
Ubuntu (hardy heron).
gcc is 4.2.3
The R source was built with make clean; ./configure --enable-R-shlib
before running make; make install
Can others using that system (or similar ones) reproduce it?
Duncan Murdoch
#include R.h
#include Rdefines.h
SEXP createObject(void)
{
SEXP x_R;
int len_x = 100;
PROTECT(x_R = allocVector(REALSXP, len_x));
Rprintf(Created 'x' at %p\n, x_R);
Rprintf( (mode is %i, length is %i)\n, TYPEOF(x_R), LENGTH(x_R));
Rprintf( (first element is %d)\n, REAL(x_R)[0]);
R_PreserveObject(x_R);
UNPROTECT(1);
return x_R;
}
void printObject(SEXP sexp)
{
Rprintf(object at %p\n, sexp);
Rprintf( (mode is %i, length is %i, named is %i)\n,
TYPEOF(sexp), LENGTH(sexp), NAMED(sexp));
}
SEXP lostobject(SEXP n_R)
{
/*
* This function will:
* 1- create a numerical vector x and preserve it
* 2- make call list(x)
* 3- return x to R
*/
SEXP x_R;
int i;
int n = INTEGER(n_R)[0];
/* Create a numerical vector x_R */
for (i=0; in; i++) {
x_R = createObject();
printObject(x_R);
R_ReleaseObject(x_R);
R_gc();
}
x_R = createObject();
printObject(x_R);
R_gc();
Rprintf(Returning 'x' at %p\n, x_R);
Rprintf( (first element is %d)\n, REAL(x_R)[0]);
return x_R;
}
2008/7/20 Duncan Murdoch [EMAIL PROTECTED]:
On 20/07/2008 9:01 AM, Laurent Gautier wrote:
Dear list,
While trying to identify the root of a problem I am having with
garbage collected variables,
I have come across the following oddity: depending on whether --verbose
is
set
or not, I obtain different results.
You are working with variables without protecting them, so you just get
lucky whenever the code works.
More below...
I have made a small standalone example to demonstrate it.
The example is very artificial, but I had a hard time reproducing
reliably the problem.
So when I do: (the content of test.R is at the end of this email)
R --no-save test.R
[The two last lines of the output are:]
x[1:3]
[1] 0 0 0
while with
R --verbose --no-save test.R
[The two last lines of the output are:]
x[1:3]
[1] 3.733188e-317 3.137345e-317 3.137345e-317
The C code is compiled with:
R CMD SHLIB test_lostobject.c
sessionInfo()
R version 2.7.1 Patched (2008-07-19 r46081)
x86_64-unknown-linux-gnu
locale:
LC_CTYPE=en_US.UTF-8;LC_NUMERIC=C;LC_TIME=en_US.UTF-8;LC_COLLATE=en_US.UTF-8;LC_MONETARY=C;LC_MESSAGES=en_US.UTF-8;LC_PAPER=en_US.UTF-8;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=en_US.UTF-8;LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
### -- file test.R
dyn.load(test_lostobject.so)
x = .Call(lostobject, as.integer(5))
x[1:3]
### ---
###--- file lostobject.c
#include R.h
#include Rdefines.h
SEXP createObject(void)
{
SEXP x_R;
int len_x = 100;
PROTECT(x_R = allocVector(REALSXP, len_x));
Rprintf(Created 'x' at %p\n, x_R);
Rprintf( (mode is %i, length is %i)\n, TYPEOF(x_R), LENGTH(x_R));
Rprintf( (first element is %d)\n, REAL(x_R)[0]);
R_PreserveObject(x_R);
UNPROTECT(1);
return x_R;
}
void printObject(SEXP sexp)
{
Rprintf(object at %p\n, sexp);
Rprintf( (mode is %i, length is %i, named is %i)\n,
TYPEOF(sexp), LENGTH(sexp), NAMED(sexp));
}
SEXP lostobject(SEXP n_R)
{
/*
* This function will:
* 1- create a numerical vector x and preserve it
* 2- make call list(x)
* 3- return x to R
*/
SEXP x_R;
int i;
int n = INTEGER(n_R)[0];
/* Create a numerical vector x_R */
for (i=0; in; i++) {
x_R = createObject();
R_ReleaseObject(x_R);
At this point, the variable is unprotected, i.e. you have declared that
its
memory is free for the taking. You should not try to do anything with
it.
printObject calls several functions, and one of those may have
overwritten
the memory. It's not surprising that different flags (--verbose or not)
result in different behaviour.
printObject(x_R);
R_gc();
}
x_R = createObject();
printObject(x_R);
R_gc();
R_ReleaseObject(x_R);
Same
Re: [Rd] Clash between 'Cairo' and 'EBImage' packages on Windows
EBImage is dynamically linked against GTK, which includes cairo
libraries, so those are installed along with GTK. Cairo seems to be
statically linking to libcairo.dll.a. I would assume that if it is
linked statically it should not get confused with a shared library
present elsewhere in the path, but it looks like it does. I have no
solution for that because unlike Cairo I cannot not statically link
EBImage to GTK as it is not one library that I need, but a bunch of
those.
On Linux you won't get this problem as it uses the same centrally
installed Cairo library.
In a way it would be better, if Cairo relied on the gladewin32.sf.net
which normally provides GTK (and thus cairo libraries) for Windows and
linked dynamically, but probably to simplify user installations the
developers wanted to avoid this.
There is not much I can do now about this, but I will follow the thread
if anybody comes up with an idea to change the code if possible
Dr Oleg Sklyar
Technology Group
Man Investments Ltd
+44 (0)20 7144 3803
[EMAIL PROTECTED]
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Henrik Bengtsson
Sent: 19 July 2008 19:26
To: R-devel
Subject: [Rd] Clash between 'Cairo' and 'EBImage' packages on Windows
Hi,
on Windows XP Pro with R version 2.7.1 Patched (2008-06-27
r46012) the 'Cairo' and the 'EBImage' packages does not play
well together.
Loading EBImage before Cairo cause the following to happen:
# Rterm --vanilla
library(EBImage);
library(Cairo)
Error in inDL(x, as.logical(local), as.logical(now), ...) :
unable to load shared library
'C:/PROGRA~1/R/R-2.7.1pat/library/Cairo/libs/Cai
ro.dll':
LoadLibrary failure: The specified procedure could not be found.
Error : .onLoad failed in 'loadNamespace' for 'Cairo'
Error: package/namespace load failed for 'Cairo'
with a dialog titled 'Rterm.exe - Entry Point Not Found'
saying 'The procedure entry point cairo_pdf_surface_create
could not be located in the dynamic link library libcairo-2.dll'.
Loading the packages in the reverse order works, but the
Rterm seems unstable, e.g. calling q() immediately after will
exit the R session without questions:
# Rterm --vanilla
library(Cairo)
library(EBImage)
q()
[Immediately back to the command line].
I cannot reproduce the problem on R v2.7.1 on Ubuntu Hardy.
sessionInfo()
R version 2.7.1 Patched (2008-06-27 r46012)
i386-pc-mingw32
locale:
LC_COLLATE=English_United States.1252;LC_CTYPE=English_United
States.1252;LC_MON ETARY=English_United
States.1252;LC_NUMERIC=C;LC_TIME=English_United States.1252
attached base packages:
[1] stats graphics grDevices utils datasets methods base
other attached packages:
[1] EBImage_2.4.0 Cairo_1.4-2
Cheers
Henrik
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
**
The contents of this email are for the named addressee(s...{{dropped:22}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Clash between 'Cairo' and 'EBImage' packages on Windows
On Mon, 21 Jul 2008, Sklyar, Oleg (London) wrote:
EBImage is dynamically linked against GTK, which includes cairo
libraries, so those are installed along with GTK. Cairo seems to be
statically linking to libcairo.dll.a. I would assume that if it is
That is an import library, so it is actually linked to libcairo-2.dll,
which it ships.
linked statically it should not get confused with a shared library
present elsewhere in the path, but it looks like it does. I have no
solution for that because unlike Cairo I cannot not statically link
EBImage to GTK as it is not one library that I need, but a bunch of
those.
On Linux you won't get this problem as it uses the same centrally
installed Cairo library.
In a way it would be better, if Cairo relied on the gladewin32.sf.net
which normally provides GTK (and thus cairo libraries) for Windows and
linked dynamically, but probably to simplify user installations the
developers wanted to avoid this.
It _is_ using dynamic loading, or there would be no conflict. From the
names, it looks very like that it is using a DLL from gladewin32.
The real issue looks rather like a versioning problem, that the cairo
libraries installed as part of GTK and used by EBImage are way too old
(cairo_pdf_surface_create was added at cairo 1.2, and cairo is at 1.6.4).
So updating to the current GTK distribution may be all that is needed (and
Henrik could also try replacing your GTK's libcairo-2.dll by that
distributed with Cairo).
There is not much I can do now about this, but I will follow the thread
if anybody comes up with an idea to change the code if possible
The Cairo package (which ships DLLs) could rename them, as R itself does
where it builds its own versions. Or it could link statically (if that
works, which it does not for e.g. package XML).
I don't really understand why this was posted to R-devel: it is not an R
issue.
Dr Oleg Sklyar
Technology Group
Man Investments Ltd
+44 (0)20 7144 3803
[EMAIL PROTECTED]
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Henrik Bengtsson
Sent: 19 July 2008 19:26
To: R-devel
Subject: [Rd] Clash between 'Cairo' and 'EBImage' packages on Windows
Hi,
on Windows XP Pro with R version 2.7.1 Patched (2008-06-27
r46012) the 'Cairo' and the 'EBImage' packages does not play
well together.
Loading EBImage before Cairo cause the following to happen:
# Rterm --vanilla
library(EBImage);
library(Cairo)
Error in inDL(x, as.logical(local), as.logical(now), ...) :
unable to load shared library
'C:/PROGRA~1/R/R-2.7.1pat/library/Cairo/libs/Cai
ro.dll':
LoadLibrary failure: The specified procedure could not be found.
Error : .onLoad failed in 'loadNamespace' for 'Cairo'
Error: package/namespace load failed for 'Cairo'
with a dialog titled 'Rterm.exe - Entry Point Not Found'
saying 'The procedure entry point cairo_pdf_surface_create
could not be located in the dynamic link library libcairo-2.dll'.
Loading the packages in the reverse order works, but the
Rterm seems unstable, e.g. calling q() immediately after will
exit the R session without questions:
# Rterm --vanilla
library(Cairo)
library(EBImage)
q()
[Immediately back to the command line].
I cannot reproduce the problem on R v2.7.1 on Ubuntu Hardy.
sessionInfo()
R version 2.7.1 Patched (2008-06-27 r46012)
i386-pc-mingw32
locale:
LC_COLLATE=English_United States.1252;LC_CTYPE=English_United
States.1252;LC_MON ETARY=English_United
States.1252;LC_NUMERIC=C;LC_TIME=English_United States.1252
attached base packages:
[1] stats graphics grDevices utils datasets methods base
other attached packages:
[1] EBImage_2.4.0 Cairo_1.4-2
Cheers
Henrik
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
**
The contents of this email are for the named addressee(s...{{dropped:22}}
__
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] Clash between 'Cairo' and 'EBImage' packages on Windows
Thanks fot the response. I will try to recompile EBImage with the newest
GTK and would advise Henrik to update the GTK to the latest one as it
should be backward compatible.
As for where it is posted, it is not a BioC only issue either and too
technical for R-help, so I would rather support Henrik on posting it
here. But please take my apollogies if it is not too appropriate to have
it on R-devel.
Best,
Oleg
Dr Oleg Sklyar
Technology Group
Man Investments Ltd
+44 (0)20 7144 3803
[EMAIL PROTECTED]
-Original Message-
From: Prof Brian Ripley [mailto:[EMAIL PROTECTED]
Sent: 21 July 2008 11:29
To: Sklyar, Oleg (London)
Cc: Henrik Bengtsson; R-devel
Subject: Re: [Rd] Clash between 'Cairo' and 'EBImage'
packages on Windows
On Mon, 21 Jul 2008, Sklyar, Oleg (London) wrote:
EBImage is dynamically linked against GTK, which includes cairo
libraries, so those are installed along with GTK. Cairo seems to be
statically linking to libcairo.dll.a. I would assume that if it is
That is an import library, so it is actually linked to
libcairo-2.dll, which it ships.
linked statically it should not get confused with a shared library
present elsewhere in the path, but it looks like it does. I have no
solution for that because unlike Cairo I cannot not statically link
EBImage to GTK as it is not one library that I need, but a bunch of
those.
On Linux you won't get this problem as it uses the same centrally
installed Cairo library.
In a way it would be better, if Cairo relied on the
gladewin32.sf.net
which normally provides GTK (and thus cairo libraries) for
Windows and
linked dynamically, but probably to simplify user installations the
developers wanted to avoid this.
It _is_ using dynamic loading, or there would be no conflict.
From the names, it looks very like that it is using a DLL
from gladewin32.
The real issue looks rather like a versioning problem, that
the cairo libraries installed as part of GTK and used by
EBImage are way too old (cairo_pdf_surface_create was added
at cairo 1.2, and cairo is at 1.6.4).
So updating to the current GTK distribution may be all that
is needed (and Henrik could also try replacing your GTK's
libcairo-2.dll by that distributed with Cairo).
There is not much I can do now about this, but I will follow the
thread if anybody comes up with an idea to change the code
if possible
The Cairo package (which ships DLLs) could rename them, as R
itself does where it builds its own versions. Or it could
link statically (if that works, which it does not for e.g.
package XML).
I don't really understand why this was posted to R-devel: it
is not an R issue.
Dr Oleg Sklyar
Technology Group
Man Investments Ltd
+44 (0)20 7144 3803
[EMAIL PROTECTED]
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Henrik
Bengtsson
Sent: 19 July 2008 19:26
To: R-devel
Subject: [Rd] Clash between 'Cairo' and 'EBImage' packages
on Windows
Hi,
on Windows XP Pro with R version 2.7.1 Patched (2008-06-27
r46012) the 'Cairo' and the 'EBImage' packages does not play
well together.
Loading EBImage before Cairo cause the following to happen:
# Rterm --vanilla
library(EBImage);
library(Cairo)
Error in inDL(x, as.logical(local), as.logical(now), ...) :
unable to load shared library
'C:/PROGRA~1/R/R-2.7.1pat/library/Cairo/libs/Cai
ro.dll':
LoadLibrary failure: The specified procedure could not be found.
Error : .onLoad failed in 'loadNamespace' for 'Cairo'
Error: package/namespace load failed for 'Cairo'
with a dialog titled 'Rterm.exe - Entry Point Not Found'
saying 'The procedure entry point cairo_pdf_surface_create
could not be located in the dynamic link library libcairo-2.dll'.
Loading the packages in the reverse order works, but the
Rterm seems unstable, e.g. calling q() immediately after will
exit the R session without questions:
# Rterm --vanilla
library(Cairo)
library(EBImage)
q()
[Immediately back to the command line].
I cannot reproduce the problem on R v2.7.1 on Ubuntu Hardy.
sessionInfo()
R version 2.7.1 Patched (2008-06-27 r46012)
i386-pc-mingw32
locale:
LC_COLLATE=English_United States.1252;LC_CTYPE=English_United
States.1252;LC_MON ETARY=English_United
States.1252;LC_NUMERIC=C;LC_TIME=English_United States.1252
attached base packages:
[1] stats graphics grDevices utils datasets
methods base
other attached packages:
[1] EBImage_2.4.0 Cairo_1.4-2
Cheers
Henrik
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
**
The contents of this email are for the named
addressee(s...{{dropped:22}}
__
Re: [Rd] Snow or alternative MPI packages on Windows
On Thu, 17 Jul 2008, Jay Emerson wrote: Giuseppe, I've been able to use NetWorkSpaces on all platforms, and have used snow under Linux. It's possible to use snow under windows, but you'll need to build the binary yourself I think. As an aside, I think this makes it impossible to write a CRAN-friendly package that Requires: or Suggests: snow, because it will fail the windows check. It would be great if we could get around this some way, but I know this topic has been covered before (the subtle nature of Suggests: in particular, and what it really means). I would like to add SNOW support to two of my own packages, bcp and bigmemory. Hopefully Windows binaries for snow will become available before long now that snow works on Windows with at least socket and MPI back ends. The current version of snow also supports NWS as a communication back end, thanks to code contributed by the NWS folks. Best, luke SNOW and NWS are similarly easy to use, at least at the superficial level which has been my experience. With NWS, you need both the package (nws, available on CRAN), and a NWS server (open-source, available on sourceforge). But REvolution has a Windows installer available, and are working to make the whole process easier on the end user/developer on all platforms. I started a rough page to help in the interim, and will update it as thing change to assist the end user/developer: http://www.stat.yale.edu/~jay/nws/ Jay original message below Guys, I'm running R on both Windows Linux. I'm looking at a number of packages for parallel execution. It seems that the most used packages are snow and Rmpi. snow seems more user friendly, but it doesn't run on windows. I see from searching the mailing list that I'm not the first one to try it on Windows. There was a message that kind of shed some hope on the subject, but nothing else. Rmpi works well on windows (with DeinoMPI) but it's kind of low level, so before I embark in writing code similar to snow to have some high level constructs I though I'd ask here about other peoples experiences... Is anyone around here doing parallel R on Windows? If so could you share your experience? // Giuseppe -- Luke Tierney Chair, Statistics and Actuarial Science Ralph E. Wareham Professor of Mathematical Sciences University of Iowa Phone: 319-335-3386 Department of Statistics andFax: 319-335-3017 Actuarial Science 241 Schaeffer Hall email: [EMAIL PROTECTED] Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Clash between 'Cairo' and 'EBImage' packages on Windows
Brian,
thanks for the analysis.
On Jul 21, 2008, at 6:29 , Prof Brian Ripley wrote:
On Mon, 21 Jul 2008, Sklyar, Oleg (London) wrote:
EBImage is dynamically linked against GTK, which includes cairo
libraries, so those are installed along with GTK. Cairo seems to be
statically linking to libcairo.dll.a. I would assume that if it is
That is an import library, so it is actually linked to
libcairo-2.dll, which it ships.
linked statically it should not get confused with a shared library
present elsewhere in the path, but it looks like it does. I have no
solution for that because unlike Cairo I cannot not statically link
EBImage to GTK as it is not one library that I need, but a bunch of
those.
On Linux you won't get this problem as it uses the same centrally
installed Cairo library.
In a way it would be better, if Cairo relied on the gladewin32.sf.net
which normally provides GTK (and thus cairo libraries) for Windows
and
linked dynamically, but probably to simplify user installations the
developers wanted to avoid this.
It _is_ using dynamic loading, or there would be no conflict. From
the names, it looks very like that it is using a DLL from gladewin32.
The real issue looks rather like a versioning problem, that the
cairo libraries installed as part of GTK and used by EBImage are way
too old (cairo_pdf_surface_create was added at cairo 1.2, and cairo
is at 1.6.4). So updating to the current GTK distribution may be all
that is needed (and Henrik could also try replacing your GTK's
libcairo-2.dll by that distributed with Cairo).
For compatibility sake I have updated the libcairo binary to 1.6.4
(based on GTK+ build), so if EBImage gets updated all should be well.
There is not much I can do now about this, but I will follow the
thread
if anybody comes up with an idea to change the code if possible
The Cairo package (which ships DLLs) could rename them, as R itself
does where it builds its own versions. Or it could link statically
(if that works, which it does not for e.g. package XML).
I'd rather not maintain my own build of libcairo for Windows since I
don't use it. I may consider renaming the DLL, but given that I'm not
building it from sources I'm not sure whether there is a trivial way
to do that.
Best,
Simon
I don't really understand why this was posted to R-devel: it is not
an R issue.
Dr Oleg Sklyar
Technology Group
Man Investments Ltd
+44 (0)20 7144 3803
[EMAIL PROTECTED]
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Henrik Bengtsson
Sent: 19 July 2008 19:26
To: R-devel
Subject: [Rd] Clash between 'Cairo' and 'EBImage' packages on
Windows
Hi,
on Windows XP Pro with R version 2.7.1 Patched (2008-06-27
r46012) the 'Cairo' and the 'EBImage' packages does not play
well together.
Loading EBImage before Cairo cause the following to happen:
# Rterm --vanilla
library(EBImage);
library(Cairo)
Error in inDL(x, as.logical(local), as.logical(now), ...) :
unable to load shared library
'C:/PROGRA~1/R/R-2.7.1pat/library/Cairo/libs/Cai
ro.dll':
LoadLibrary failure: The specified procedure could not be found.
Error : .onLoad failed in 'loadNamespace' for 'Cairo'
Error: package/namespace load failed for 'Cairo'
with a dialog titled 'Rterm.exe - Entry Point Not Found'
saying 'The procedure entry point cairo_pdf_surface_create
could not be located in the dynamic link library libcairo-2.dll'.
Loading the packages in the reverse order works, but the
Rterm seems unstable, e.g. calling q() immediately after will
exit the R session without questions:
# Rterm --vanilla
library(Cairo)
library(EBImage)
q()
[Immediately back to the command line].
I cannot reproduce the problem on R v2.7.1 on Ubuntu Hardy.
sessionInfo()
R version 2.7.1 Patched (2008-06-27 r46012)
i386-pc-mingw32
locale:
LC_COLLATE=English_United States.1252;LC_CTYPE=English_United
States.1252;LC_MON ETARY=English_United
States.1252;LC_NUMERIC=C;LC_TIME=English_United States.1252
attached base packages:
[1] stats graphics grDevices utils datasets methods base
other attached packages:
[1] EBImage_2.4.0 Cairo_1.4-2
Cheers
Henrik
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
**
The contents of this email are for the named addressee(s...
{{dropped:22}}
__
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
