Nabble - R devel

serialize() to via temporary file is heaps faster than doing it directly (on Windows)

2008-07-24T20:10:35Z

Hi,

FYI, I just notice that on Windows (but not Linux) it is orders of
magnitude (below it's 50x) faster to serialize() and object to a
temporary file and then read it back, than to serialize to an object
directly. This has for instance impact on how fast digest::digest()
can provide a checksum.

Example:
x <- 1:1e7;
t1 <- system.time(raw1 <- serialize(x, connection=NULL));
print(t1);
# user system elapsed
# 174.23 129.35 304.70 ## 5 minutes
t2 <- system.time(raw2 <- serialize2(x, connection=NULL));
print(t2);
# user system elapsed
# 2.19 0.18 5.72 ## 5 seconds
print(t1/t2);
# user system elapsed
# 79.55708 718.61111 53.26923
stopifnot(identical(raw1, raw2));

where serialize2() is serialize():ing to file and reading the results back:

serialize2 <- function(object, connection, ...) {
if (is.null(connection)) {
# It is faster to serialize to a temporary file and read it back
pathname <- tempfile();
con <- file(pathname, open="wb");
on.exit({
if (!is.null(con))
close(con);
if (file.exists(pathname))
file.remove(pathname);
});
base::serialize(object, connection=con, ...);
close(con);
con <- NULL;
fileSize <- file.info(pathname)$size;
readBin(pathname, what="raw", n=fileSize);
} else {
base::serialize(object, connection=connection, ...);
}
} # serialize2()

The above benchmarking was done in a fresh R v2.7.1 session on WinXP Pro:

> 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

When I do the same on a Linux machine there is no difference:

> sessionInfo()
R version 2.7.1 (2008-06-23)
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

Is there an obvious reason (and an obvious fix) for this?

Cheers

Henrik

______________________________________________
R-devel@... mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

How to loop through a set of data and to evaluate a function?

2008-07-24T07:39:07Z

Hi,
I will explain my problem :
I would like to loop through a set of data taking the set 100 points at a time. At each iteration I'd like to evaluate a function over this set. In each subsequent iteration i add the next point to my sub set and remove the oldest and evaluate the function again (something like a moving window).

Small example : this is my data:
1
2
3
..
10

with a moving window of 3 points, i would like to evaluate the following
f(1,2,3)
f(2,3,4)
f(3.4.5)
...
f(8,9,10)

Thank you!

Re: plot.dendrogram xlim/ylim

2008-07-24T00:49:39Z

>>>>> "FA" == Felix Andrews <felix@...>
>>>>> on Thu, 24 Jul 2008 13:16:22 +1000 writes:

FA> list(...), I would like to zoom in to the leaves of
FA> large trees in a dendrogram plot. The playwith package
FA> allows zooming by passing xlim and ylim arguments to the
FA> plot call (Hmisc does this too I think). But currently
FA> stats:::plot.dendrogram does not accept xlim or ylim. So
FA> I would like to enable that. In place of the existing
FA> code chunk:

>> xlim <- c(x1 - 1/2, x2 + 1/2)
>> ylim <- c(0, yTop)
>> if (horiz) {
>> xl <- xlim
>> xlim <- rev(ylim)
>> ylim <- xl
>> tmp <- xaxt
>> xaxt <- yaxt
>> yaxt <- tmp
>> }
>> plot(0, xlim = xlim, ylim = ylim, ......
>>
>> I propose something like:
>>
>> function(..., xlim, ylim)
>>
>> xlim0 <- c(x1 - 1/2, x2 + 1/2)
>> ylim0 <- c(0, yTop)
>> if (horiz) {
>> xl <- xlim0
>> xlim0 <- rev(ylim0)
>> ylim <- xl
>> tmp <- xaxt
>> xaxt <- yaxt
>> yaxt <- tmp
>> }
>> if (missing(xlim)) xlim <- xlim0
>> if (missing(ylim)) ylim <- ylim0
>> plot(0, xlim = xlim, ylim = ylim, ......

Thank you for the suggestion!
Yes, "something like" this will be part of R 2.8.0
(or 'R-devel' as from tomorrow).

Martin Maechler, ETH Zurich

>> --
>> Felix Andrews / 安福立
>> PhD candidate
>> Integrated Catchment Assessment and Management Centre
>> The Fenner School of Environment and Society
>> The Australian National University (Building 48A), ACT 0200
>> Beijing Bag, Locked Bag 40, Kingston ACT 2604
>> http://www.neurofractal.org/felix/
>> 3358 543D AAC6 22C2 D336 80D9 360B 72DD 3E4C F5D8

______________________________________________
R-devel@... mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [R] shQuote and cat

2008-07-24T00:38:25Z

Duncan Murdoch wrote:

> Vadim Organovich wrote:
>> It is precizely a shell command that I am trying to generate. To be
>> specific let's try to have R 'output' the following shell command:
>> 'echo "\"a\""'. This is is a valid command, at least in bash:
>> bash-3.2$ echo "\"a\""
>> "a"
>>
>> Now in R:
>>
>>> x <- 'echo "\"a\""'
>>> cat(x, '\n')
>>>
>> echo ""a""
>>
>>> cat(shQuote(x), '\n')
>>>
>> "echo \"\"a\"\""
>>
>> Whichever way you do it it is not right. Again I think cat('echo
>> "\"a\""') should be printing *echo "\"a\""* (asterics are not a part
>> of the output)
>>

try this:

(x = 'echo "\\"a\\""') # or x = 'echo \"\\\"a\\\"\"')
[1] "echo \"\\\"a\\\"\""

cat(x, "\n")
# echo "\"a\""

as desired. you need to backslash the backslash.

vQ

______________________________________________
R-devel@... mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

plot.dendrogram xlim/ylim

2008-07-23T20:16:22Z

list(...),

I would like to zoom in to the leaves of large trees in a dendrogram
plot. The playwith package allows zooming by passing xlim and ylim
arguments to the plot call (Hmisc does this too I think). But
currently stats:::plot.dendrogram does not accept xlim or ylim. So I
would like to enable that. In place of the existing code chunk:

xlim <- c(x1 - 1/2, x2 + 1/2)
ylim <- c(0, yTop)
if (horiz) {
xl <- xlim
xlim <- rev(ylim)
ylim <- xl
tmp <- xaxt
xaxt <- yaxt
yaxt <- tmp
}
plot(0, xlim = xlim, ylim = ylim, ......

I propose something like:

function(..., xlim, ylim)

xlim0 <- c(x1 - 1/2, x2 + 1/2)
ylim0 <- c(0, yTop)
if (horiz) {
xl <- xlim0
xlim0 <- rev(ylim0)
ylim <- xl
tmp <- xaxt
xaxt <- yaxt
yaxt <- tmp
}
if (missing(xlim)) xlim <- xlim0
if (missing(ylim)) ylim <- ylim0
plot(0, xlim = xlim, ylim = ylim, ......

Regards,
Felix

--
Felix Andrews / 安福立
PhD candidate
Integrated Catchment Assessment and Management Centre
The Fenner School of Environment and Society
The Australian National University (Building 48A), ACT 0200
Beijing Bag, Locked Bag 40, Kingston ACT 2604
http://www.neurofractal.org/felix/
3358 543D AAC6 22C2 D336 80D9 360B 72DD 3E4C F5D8

______________________________________________
R-devel@... mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [R] shQuote and cat

2008-07-23T18:08:58Z

On Jul 23, 2008, at 4:46 PM, Vadim Organovich wrote:

> It is precizely a shell command that I am trying to generate. To be
> specific let's try to have R 'output' the following shell command:
> 'echo "\"a\""'. This is is a valid command, at least in bash:
> bash-3.2$ echo "\"a\""
> "a"
>
> Now in R:
>> x <- 'echo "\"a\""'
>> cat(x, '\n')
> echo ""a""
>> cat(shQuote(x), '\n')
> "echo \"\"a\"\""
>
> Whichever way you do it it is not right.

Well, you input is not right ('\"' is parsed in R into '"') - you have
to escape the backslash that you want to keep and all is well:

> x <- 'echo "\\"a\\""'
> cat(x, '\n')
echo "\"a\""
> cat(shQuote(x), '\n')
'echo "\"a\""'
> system(paste("sh -c",shQuote(x,type="sh")))
"a"

Cheers,
Simon

> Again I think cat('echo "\"a\""') should be printing *echo "\"a\""*
> (asterics are not a part of the output)
>
> ________________________________________
> From: Duncan Murdoch [murdoch@...]
> Sent: Wednesday, July 23, 2008 2:38 PM
> To: Vadim Organovich
> Cc: r-devel@...
> Subject: Re: [Rd] [R] shQuote and cat
>
> On 7/23/2008 2:53 PM, Vadim Organovich wrote:
>> I feel like it now belongs to r-devel more than to r-help.
>>
>> My output was garbled because I sent the original message as HTML,
>> sorry about that.
>>
>> Your output, "\"\\"a\\"\"", is what I get too. That is
>>> cat(shQuote(shQuote(shQuote("a"))), '\n')
>> "\"\\"a\\"\""
>> , which I think should be "\"\\\"a\\\"\"".
>>
>> Actually, the R's output, "\"\\"a\\"\"", is not even a valid string
>> literal, that is
>>> x <- "\"\\"a\\"\""
>> fails.
>
> It's not intended to be a string literal in R, it's intended to be
> input
> to the Windows CMD shell. If you want a string literal in R, don't
> use
> cat(). cat() shows you the naked contents of the string without any
> quoting to make it a valid string literal.
>
>>
>>
>> Now, by cat() being the inverse of shQuote() I mean printing the
>> same literal as it goes into shQuote, quotes included:
>>> cat(shQuote("a"), '\n')
>> "a"
>>
>> whereas
>>> cat("a", '\n')
>> a ## no quotes
>>
>> If cat() is not the inverse of shQuote() in the above sense, what is?
>
> On Unix-like systems I think asking the shell to echo the output, i.e.
>
> system(paste("echo", shQuote(input)), intern=TRUE)
>
> is intended to reproduce the input. However, the Windows CMD shell is
> different. I don't know how to strip quotes off a string in it,
> e.g. I see
>
> C:\WINDOWS\system32 echo "a"
> "a"
>
> Nevertheless, the quotes *are* necessary when passing filenames to
> commands, and they'll typically be stripped off when doing that, e.g.
>
> echo hi >"a"
>
> will create a file named a, not named "a", and
>
> echo hi >"a b"
>
> will create a file with a space in the name.
>
> Duncan Murdoch
>
> Note: This email is for the confidential use of the named
> addressee(s) only and may contain proprietary, confidential or
> privileged information. If you are not the intended recipient, you
> are hereby notified that any review, dissemination or copying of
> this email is strictly prohibited, and to please notify the sender
> immediately and destroy this email and any attachments. Email
> transmission cannot be guaranteed to be secure or error-free. Jump
> Trading, therefore, does not make any guarantees as to the
> completeness or accuracy of this email or any attachments. This
> email is for informational purposes only and does not constitute a
> recommendation, offer, request or solicitation of any kind to buy,
> sell, subscribe, redeem or perform any type of transaction of a
> financial product.
>
> ______________________________________________
> R-devel@... mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>

______________________________________________
R-devel@... mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [R] shQuote and cat

2008-07-23T17:04:04Z

Vadim Organovich wrote:

> It is precizely a shell command that I am trying to generate. To be specific let's try to have R 'output' the following shell command: 'echo "\"a\""'. This is is a valid command, at least in bash:
> bash-3.2$ echo "\"a\""
> "a"
>
> Now in R:
>
>> x <- 'echo "\"a\""'
>> cat(x, '\n')
>>
> echo ""a""
>
>> cat(shQuote(x), '\n')
>>
> "echo \"\"a\"\""
>
> Whichever way you do it it is not right. Again I think cat('echo "\"a\""') should be printing *echo "\"a\""* (asterics are not a part of the output)
>

But you were running on Windows, so the default shell is CMD, not bash.
shQuote doesn't support bash specifically, but I imagine it uses the
same quoting rules as sh, so you should use shQuote('"a"', type="sh").
On my machine that gives '"a"', and echo '"a"' prints "a" as you wanted.

I don't think you want to quote the "echo" in the command, only the
string that you want it to print, i.e. for the full command you should use

> cat(paste("echo", shQuote('"a"', type="sh")))
echo '"a"'

Duncan Murdoch

> ________________________________________
> From: Duncan Murdoch [murdoch@...]
> Sent: Wednesday, July 23, 2008 2:38 PM
> To: Vadim Organovich
> Cc: r-devel@...
> Subject: Re: [Rd] [R] shQuote and cat
>
> On 7/23/2008 2:53 PM, Vadim Organovich wrote:
>
>> I feel like it now belongs to r-devel more than to r-help.
>>
>> My output was garbled because I sent the original message as HTML, sorry about that.
>>
>> Your output, "\"\\"a\\"\"", is what I get too. That is
>> > cat(shQuote(shQuote(shQuote("a"))), '\n')
>> "\"\\"a\\"\""
>> , which I think should be "\"\\\"a\\\"\"".
>>
>> Actually, the R's output, "\"\\"a\\"\"", is not even a valid string literal, that is
>>
>>> x <- "\"\\"a\\"\""
>>>
>> fails.
>>
>
> It's not intended to be a string literal in R, it's intended to be input
> to the Windows CMD shell. If you want a string literal in R, don't use
> cat(). cat() shows you the naked contents of the string without any
> quoting to make it a valid string literal.
>
>
>> Now, by cat() being the inverse of shQuote() I mean printing the same literal as it goes into shQuote, quotes included:
>>
>>> cat(shQuote("a"), '\n')
>>>
>> "a"
>>
>> whereas
>>
>>> cat("a", '\n')
>>>
>> a ## no quotes
>>
>> If cat() is not the inverse of shQuote() in the above sense, what is?
>>
>
> On Unix-like systems I think asking the shell to echo the output, i.e.
>
> system(paste("echo", shQuote(input)), intern=TRUE)
>
> is intended to reproduce the input. However, the Windows CMD shell is
> different. I don't know how to strip quotes off a string in it, e.g. I see
>
> C:\WINDOWS\system32 echo "a"
> "a"
>
> Nevertheless, the quotes *are* necessary when passing filenames to
> commands, and they'll typically be stripped off when doing that, e.g.
>
> echo hi >"a"
>
> will create a file named a, not named "a", and
>
> echo hi >"a b"
>
> will create a file with a space in the name.
>
> Duncan Murdoch
>
> Note: This email is for the confidential use of the named addressee(s) only and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you are hereby notified that any review, dissemination or copying of this email is strictly prohibited, and to please notify the sender immediately and destroy this email and any attachments. Email transmission cannot be guaranteed to be secure or error-free. Jump Trading, therefore, does not make any guarantees as to the completeness or accuracy of this email or any attachments. This email is for informational purposes only and does not constitute a recommendation, offer, request or solicitation of any kind to buy, sell, subscribe, redeem or perform any type of transaction of a financial product.
>
> ______________________________________________
> R-devel@... mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

______________________________________________
R-devel@... mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [R] shQuote and cat

2008-07-23T13:46:07Z

It is precizely a shell command that I am trying to generate. To be specific let's try to have R 'output' the following shell command: 'echo "\"a\""'. This is is a valid command, at least in bash:
bash-3.2$ echo "\"a\""
"a"

Now in R:
> x <- 'echo "\"a\""'
> cat(x, '\n')
echo ""a""
> cat(shQuote(x), '\n')
"echo \"\"a\"\""

Whichever way you do it it is not right. Again I think cat('echo "\"a\""') should be printing *echo "\"a\""* (asterics are not a part of the output)

________________________________________
From: Duncan Murdoch [murdoch@...]
Sent: Wednesday, July 23, 2008 2:38 PM
To: Vadim Organovich
Cc: r-devel@...
Subject: Re: [Rd] [R] shQuote and cat

On 7/23/2008 2:53 PM, Vadim Organovich wrote:

> I feel like it now belongs to r-devel more than to r-help.
>
> My output was garbled because I sent the original message as HTML, sorry about that.
>
> Your output, "\"\\"a\\"\"", is what I get too. That is
> > cat(shQuote(shQuote(shQuote("a"))), '\n')
> "\"\\"a\\"\""
> , which I think should be "\"\\\"a\\\"\"".
>
> Actually, the R's output, "\"\\"a\\"\"", is not even a valid string literal, that is
>> x <- "\"\\"a\\"\""
> fails.

It's not intended to be a string literal in R, it's intended to be input
to the Windows CMD shell. If you want a string literal in R, don't use
cat(). cat() shows you the naked contents of the string without any
quoting to make it a valid string literal.

>
>
> Now, by cat() being the inverse of shQuote() I mean printing the same literal as it goes into shQuote, quotes included:
>> cat(shQuote("a"), '\n')
> "a"
>
> whereas
>> cat("a", '\n')
> a ## no quotes
>
> If cat() is not the inverse of shQuote() in the above sense, what is?

On Unix-like systems I think asking the shell to echo the output, i.e.

system(paste("echo", shQuote(input)), intern=TRUE)

is intended to reproduce the input. However, the Windows CMD shell is
different. I don't know how to strip quotes off a string in it, e.g. I see

C:\WINDOWS\system32 echo "a"
"a"

Nevertheless, the quotes *are* necessary when passing filenames to
commands, and they'll typically be stripped off when doing that, e.g.

echo hi >"a"

will create a file named a, not named "a", and

echo hi >"a b"

will create a file with a space in the name.

Duncan Murdoch

Note: This email is for the confidential use of the named addressee(s) only and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you are hereby notified that any review, dissemination or copying of this email is strictly prohibited, and to please notify the sender immediately and destroy this email and any attachments. Email transmission cannot be guaranteed to be secure or error-free. Jump Trading, therefore, does not make any guarantees as to the completeness or accuracy of this email or any attachments. This email is for informational purposes only and does not constitute a recommendation, offer, request or solicitation of any kind to buy, sell, subscribe, redeem or perform any type of transaction of a financial product.

______________________________________________
R-devel@... mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [R] shQuote and cat

2008-07-23T12:38:21Z

On 7/23/2008 2:53 PM, Vadim Organovich wrote:

Re: [R] shQuote and cat

2008-07-23T11:53:04Z

I feel like it now belongs to r-devel more than to r-help.

My output was garbled because I sent the original message as HTML, sorry about that.

Your output, "\"\\"a\\"\"", is what I get too. That is
> cat(shQuote(shQuote(shQuote("a"))), '\n')
"\"\\"a\\"\""
, which I think should be "\"\\\"a\\\"\"".

Actually, the R's output, "\"\\"a\\"\"", is not even a valid string literal, that is
> x <- "\"\\"a\\"\""
fails.

Now, by cat() being the inverse of shQuote() I mean printing the same literal as it goes into shQuote, quotes included:
> cat(shQuote("a"), '\n')
"a"

whereas
> cat("a", '\n')
a ## no quotes

If cat() is not the inverse of shQuote() in the above sense, what is?

Thanks,
Vadim
________________________________________
From: Duncan Murdoch [murdoch@...]
Sent: Wednesday, July 23, 2008 1:10 PM
To: Vadim Organovich
Cc: r-help@...
Subject: Re: [R] shQuote and cat

On 7/23/2008 12:20 PM, Vadim Organovich wrote:
> Dear R-users,
>
> It is my understanding that cat(shQuote(a.string)) should print the origintal a.string. Is this right?

No, cat(a.string) should print the original a.string. shQuote(a.string)
adds quotes so that a.string can be used in the shell.

> I am not sure cat() correctly prints strings which are generated by triple-shQuote():
>
>> shQuote(shQuote("a"))
> [1] "\"\\\"a\\\"\""
>> cat(shQuote(shQuote(shQuote("a"))), '\n')
> "\"\\"a\\"\<file://\\"a\\"\>""

That's a very strange result. I tried the obsolete version of R that
you're using, and I didn't see it. I get this:

> cat(shQuote(shQuote(shQuote("a"))), '\n')
"\"\\"a\\"\""

Duncan Murdoch

> As you can see the latter string has fewer quoting '\' than the former.
> cat() of double shQuote works as expected:
>
>> shQuote("a")
> [1] "\"a\""
>> cat(shQuote(shQuote("a")), '\n')
> "\"a\""
>> version
> _
> platform i386-pc-mingw32
> arch i386
> os mingw32
> system i386, mingw32
> status
> major 2
> minor 6.1
> year 2007
> month 11
> day 26
> svn rev 43537
> language R
> version.string R version 2.6.1 (2007-11-26)
> Am I missing something?
>
> Thanks,
> Vadim
>
> ________________________________
> Note: This email is for the confidential use of the named addressee(s) only and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you are hereby notified that any review, dissemination or copying of this email is strictly prohibited, and to please notify the sender immediately and destroy this email and any attachments. Email transmission cannot be guaranteed to be secure or error-free. Jump Trading, therefore, does not make any guarantees as to the completeness or accuracy of this email or any attachments. This email is for informational purposes only and does not constitute a recommendation, offer, request or solicitation of any kind to buy, sell, subscribe, redeem or perform any type of transaction of a financial product.
>
> [[alternative HTML version deleted]]
>
> ______________________________________________
> R-help@... mailing list
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
> and provide commented, minimal, self-contained, reproducible code.

Note: This email is for the confidential use of the named addressee(s) only and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you are hereby notified that any review, dissemination or copying of this email is strictly prohibited, and to please notify the sender immediately and destroy this email and any attachments. Email transmission cannot be guaranteed to be secure or error-free. Jump Trading, therefore, does not make any guarantees as to the completeness or accuracy of this email or any attachments. This email is for informational purposes only and does not constitute a recommendation, offer, request or solicitation of any kind to buy, sell, subscribe, redeem or perform any type of transaction of a financial product.

______________________________________________
R-devel@... mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: Clash between 'Cairo' and 'EBImage' packages on Windows

2008-07-23T09:11:05Z

On Jul 23, 2008, at 11:47 , Uwe Ligges wrote:

>
>
> Simon Urbanek wrote:
>> On Jul 23, 2008, at 6:21 , Prof Brian Ripley wrote:
>>> I updated one of by Windows' boxes to GTK 2.12.9, and replaced the
>>> libcairo-2.dll in the Cairo binary distribution by that from GTK
>>> 2.12.9.
>>> At that point Cairo and EBImage worked together, in either order.
>>>
>>> I think Uwe may need to trigger a rebuild of his Cairo binary to
>>> pick up Simon's updated libcairo-2.dll -- the existing binary is
>>> not compatible with GTK 2.12.9.
>>>
>> I have released a new version of Cario on Monday just to trigger
>> this, so once CRAN is updated it should happen automatically.
>
> Sorry, I'm currently a bit short of time:
> - Should I install GTK 2.12.9 or does it work with older versions?
> - So do I understand alright that I do not need to trigger anything
> yet?
>

As far as I am concerned nothing needs to be done - Cairo package
pulls its own copy of libcairo-2 (1.6.4 which comes from GTK+) when
built and I have submitted a new version of Cairo to CRAN few days ago
so hopefully it will appear there sometime.
I don't know what EBImage needs, though...

Cheers,
Simon

>
>> Thanks,
>> Simon
>>> On Tue, 22 Jul 2008, Prof Brian Ripley wrote:
>>>
>>>> On Mon, 21 Jul 2008, Simon Urbanek wrote:
>>>>
>>>>> 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.
>>>>
>>>> EBImage relies on a user installation of GTK (AFAICS). Last
>>>> night I updated my GTK to 2.12.9 and used that's libcairo-2.dll
>>>> in Cairo. It all seemed to work.
>>>>
>>>>>>> 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.
>>>>
>>>> If you are not building it yourself, then the only way is to use
>>>> an editor on the DLL to change the embedded name. I wouldn't
>>>> suggest you do that (I had thought you were building it yourself).
>>>>
>>>>> 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
>>>>>>> osklyar@...
>>>>>>>> -----Original Message-----
>>>>>>>> From: r-devel-bounces@...
>>>>>>>> [mailto:r-devel-bounces@...] 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@... 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@... mailing list
>>>>>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>>>> --
>>>>>> Brian D. Ripley, ripley@...
>>>>>> 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, UK Fax: +44 1865 272595
>>>>>> ______________________________________________
>>>>>> R-devel@... mailing list
>>>>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>>> ______________________________________________
>>>>> R-devel@... mailing list
>>>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>>
>>>> --
>>>> Brian D. Ripley, ripley@...
>>>> 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, UK Fax: +44 1865 272595
>>>>
>>>> ______________________________________________
>>>> R-devel@... mailing list
>>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>>
>>>
>>> --
>>> Brian D. Ripley, ripley@...
>>> 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, UK Fax: +44 1865 272595
>>>
>>>
>
>

______________________________________________
R-devel@... mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: Clash between 'Cairo' and 'EBImage' packages on Windows

2008-07-23T08:47:51Z

Simon Urbanek wrote:

>
> On Jul 23, 2008, at 6:21 , Prof Brian Ripley wrote:
>
>> I updated one of by Windows' boxes to GTK 2.12.9, and replaced the
>> libcairo-2.dll in the Cairo binary distribution by that from GTK 2.12.9.
>> At that point Cairo and EBImage worked together, in either order.
>>
>> I think Uwe may need to trigger a rebuild of his Cairo binary to pick
>> up Simon's updated libcairo-2.dll -- the existing binary is not
>> compatible with GTK 2.12.9.
>>
>
> I have released a new version of Cario on Monday just to trigger this,
> so once CRAN is updated it should happen automatically.

Sorry, I'm currently a bit short of time:
- Should I install GTK 2.12.9 or does it work with older versions?
- So do I understand alright that I do not need to trigger anything yet?

Best,
Uwe

> Thanks,
> Simon
>
>
>> On Tue, 22 Jul 2008, Prof Brian Ripley wrote:
>>
>>> On Mon, 21 Jul 2008, Simon Urbanek wrote:
>>>
>>>> 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.
>>>
>>> EBImage relies on a user installation of GTK (AFAICS). Last night I
>>> updated my GTK to 2.12.9 and used that's libcairo-2.dll in Cairo. It
>>> all seemed to work.
>>>
>>>>>> 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.
>>>
>>> If you are not building it yourself, then the only way is to use an
>>> editor on the DLL to change the embedded name. I wouldn't suggest
>>> you do that (I had thought you were building it yourself).
>>>
>>>> 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
>>>>>> osklyar@...
>>>>>>> -----Original Message-----
>>>>>>> From: r-devel-bounces@...
>>>>>>> [mailto:r-devel-bounces@...] 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@... 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@... mailing list
>>>>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>>> --
>>>>> Brian D. Ripley, ripley@...
>>>>> 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, UK Fax: +44 1865 272595
>>>>> ______________________________________________
>>>>> R-devel@... mailing list
>>>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>> ______________________________________________
>>>> R-devel@... mailing list
>>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>
>>> --
>>> Brian D. Ripley, ripley@...
>>> 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, UK Fax: +44 1865 272595
>>>
>>> ______________________________________________
>>> R-devel@... mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>
>>
>> --
>> Brian D. Ripley, ripley@...
>> 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, UK Fax: +44 1865 272595
>>
>>
>

______________________________________________
R-devel@... mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: Clash between 'Cairo' and 'EBImage' packages on Windows

2008-07-23T06:05:13Z

On Jul 23, 2008, at 6:21 , Prof Brian Ripley wrote:

> I updated one of by Windows' boxes to GTK 2.12.9, and replaced the
> libcairo-2.dll in the Cairo binary distribution by that from GTK
> 2.12.9.
> At that point Cairo and EBImage worked together, in either order.
>
> I think Uwe may need to trigger a rebuild of his Cairo binary to
> pick up Simon's updated libcairo-2.dll -- the existing binary is not
> compatible with GTK 2.12.9.
>

I have released a new version of Cario on Monday just to trigger this,
so once CRAN is updated it should happen automatically.

Thanks,
Simon

> On Tue, 22 Jul 2008, Prof Brian Ripley wrote:
>
>> On Mon, 21 Jul 2008, Simon Urbanek wrote:
>>
>>> 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.
>>
>> EBImage relies on a user installation of GTK (AFAICS). Last night
>> I updated my GTK to 2.12.9 and used that's libcairo-2.dll in Cairo.
>> It all seemed to work.
>>
>>>>> 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.
>>
>> If you are not building it yourself, then the only way is to use an
>> editor on the DLL to change the embedded name. I wouldn't suggest
>> you do that (I had thought you were building it yourself).
>>
>>> 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
>>>>> osklyar@...
>>>>>> -----Original Message-----
>>>>>> From: r-devel-bounces@...
>>>>>> [mailto:r-devel-bounces@...] 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@... 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@... mailing list
>>>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>> --
>>>> Brian D. Ripley, ripley@...
>>>> 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, UK Fax: +44 1865 272595
>>>> ______________________________________________
>>>> R-devel@... mailing list
>>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>> ______________________________________________
>>> R-devel@... mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>> --
>> Brian D. Ripley, ripley@...
>> 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, UK Fax: +44 1865 272595
>>
>> ______________________________________________
>> R-devel@... mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>
> --
> Brian D. Ripley, ripley@...
> 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, UK Fax: +44 1865 272595
>
>

______________________________________________
R-devel@... mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel