Re: [Rd] Standard method for S4 object

[Thibaut Jombart]

Oleg Sklyar wrote:
> similar. S3 gives more freedom in assigning new attributes, but this 
> freedom also means that one has little control over the structure of an 
> object making it, for example, more difficult to use with C/C++ code. 
> Are there any specific benefits in not using S4 and slots (apart from 
> some known performance issues)?
>   
One could say there are, but not enough to make S3 prevail over S4. I am 
not sure performance issues matter that much, but debugging functions 
seems much easier to me with S3 methods. Plus, documenting objects and 
accessing documentation can be a pain with S4 (see my previous post 
about using example() 
[http://tolstoy.newcastle.edu.au/R/e3/devel/07/12/0801.html] ... still 
no answer).

Best,

Thibaut.


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

Re: [Rd] New version of X11, png and jpeg

[Prof Brian Ripley]

Revision r44621 supports (in a limited way) cairo 1.0 and hence I believe 
vanilla FC5 -- I found what purports to be a vanilla FC5 box and it works 
quite well there.

Two people have reported that the svg(), cairo-pdf() and cairo-ps() 
devices produce blank (but not empty) files.  I was able to confirm that 
on Debian etch (cairo 1.2.4).  They do work on cairo 1.4.14 (F8) and 
better on a 1.5.10 snapshot.

We've got a working version on Mac OS X, but you need to install cairo.

Finally, the quality of the fonts you see will depend on what fonts you 
have installed: if you only have X11 bitmapped fonts, that is what you 
will get (and I am getting on our minimally configured Debian etch 
machine).  Our Fedora installations are mainly using the URW Type 1 fonts 
in the urw-fonts RPM.  One of the alternatives is RH's liberation fonts 
(https://www.redhat.com/promo/fonts/).

On Mon, 25 Feb 2008, Prof Brian Ripley wrote:

> That call is from Cairo 1.2, so looks like our test FC5 box had a later 
> version of the cairo libraries than the one pkg-config reported.
>
> You should be able to build with --without-cairo until such a time as we can 
> add a suitable configure test.
>
> Thank you for the report.
>
> On Mon, 25 Feb 2008, Roger Peng wrote:
>
>> (Apologies, I meant to 'Reply to all' the first time but forgot).
>> 
>> I built r44608 of R-devel with (I think) cairo support.   At least,
>> that's what the configure script told me.  In addition,
>> 'capabilities("cairo")' is TRUE.  Calling X11(type = "Cairo") gives me
>> the error:
>> 
>> Error in X11() : X11 module cannot be loaded
>> In addition: Warning message:
>> In X11() :
>> unable to load shared library
>> '/home/rpeng/install/R-devel/lib64/R/modules//R_X11.so':
>> /home/rpeng/install/R-devel/lib64/R/modules//R_X11.so: undefined
>> symbol: cairo_image_surface_get_data
>> 
>> 
>> I figured I must be missing a library somewhere, but I'm not sure how
>> to track down which one.  Any thoughts here?
>> 
>> I'm on a FC5 system with:
>> 
>> cairo-devel-1.0.4-1
>> cairo-1.0.4-1
>> cairo-1.0.4-1
>> 
>> and
>> 
>> pango-1.12.4-4
>> pango-devel-1.12.4-4
>> pango-1.12.4-4
>> 
>> Also, I have
>> 
>> [EMAIL PROTECTED] R-source]$ pkg-config --modversion pango
>> 1.12.4
>> [EMAIL PROTECTED] R-source]$ pkg-config --modversion cairo
>> 1.0.4
>> 
>> -roger
>> 
>> On Mon, Feb 25, 2008 at 11:56 AM, Prof Brian Ripley
>> <[EMAIL PROTECTED]> wrote:
>>> R-devel has new versions of the X11(), png() and jpeg() devices on
>>>  Unix-alikes.  The intention is that these are used identically to the
>>>  previous versions (which remain available) but will produce 
>>> higher-quality
>>>  output with more features.
>>>
>>>  Pros:
>>>
>>>  Antialiasing of text and lines (can be turned off) but no blurring of
>>>  fills.
>>>
>>>  Buffering of the X11 display and fast repainting from a backing image.
>>>  (The intention is to emulate the timer-based buffering of the windows()
>>>  device in due course, but not for 2.7.0.)
>>>
>>>  Ability to use translucent colours, including backgrounds, and produce
>>>  partially transparent PNG files.
>>>
>>>  Scalable text, including to sizes like 4.5 pt. This allows more accurate
>>>  sizing on non-standard screen sizes (e.g. my home machine has a 90dpi
>>>  1650x1024 display whereas standard X11 fonts are set up for 75 or 100
>>>  dpi).
>>>
>>>  Full support for UTF-8, so on systems with suitable fonts you can plot in
>>>  many languages on a single figure (and this will work even in non-UTF-8
>>>  locales).  The output should be locale-independent (unlike the current
>>>  devices where even English text is rendered slightly differently in
>>>  Latin-1 and UTF-8 locales).
>>>
>>>  A utility function savePlot() to make a PNG/JPEG/TIFF copy of the current
>>>  plot.
>>>
>>>  The new png() and jpeg() devices do not require an X server to be 
>>> running.
>>>
>>>  Cons:
>>>
>>>  Needs more software installed - cairo, pango and support packages (which
>>>  on all the systems we have looked at are pulled in by the packages 
>>> checked
>>>  for).  You will see something like
>>>
>>>Additional capabilities:   PNG, JPEG, iconv, MBCS, NLS, cairo
>>>^
>>>  if configure finds the software we are looking for.
>>>
>>>  Slower under some circumstances (although on the test systems much faster
>>>  than packages Cairo and cairoDevice).  This will be particularly true for
>>>  X11() with a slow connection between the machine running R and the X
>>>  server.
>>>
>>>  The additional software might not work correctly.
>>> 
>>>
>>>  The new versions are not currently the default, but can be made so by
>>>  setting X11.options(type="Cairo"), e.g. as a load hook for package
>>>  grDevices.  I am using
>>>
>>>  setHook(packageEvent("grDevices", "onLoad"),
>>>  function(...) {
>>>  grDevices::ps.options(horizontal=FALSE)
>>>  if(getRversion() >= '2.7.0') grDevices::X11.options(type="

Re: [Rd] New version of X11, png and jpeg

[Roger D. Peng]

Thanks, running r44621 works well (on my FC5 box) and I can make various plots 
(I just did some limited testing).

When I run the 'TestChars()' example in 'points' I get many warnings of the 
form:

1: In plot.xy(xy.coords(x, y), type = type, ...) :
   pch value '128' is invalid in this locale
2: In plot.xy(xy.coords(x, y), type = type, ...) :
   pch value '129' is invalid in this locale
3: In plot.xy(xy.coords(x, y), type = type, ...) :
   pch value '130' is invalid in this locale

The warnings go until

49: In plot.xy(xy.coords(x, y), type = type, ...) :
   pch value '176' is invalid in this locale
50: In plot.xy(xy.coords(x, y), type = type, ...) :
   pch value '177' is invalid in this locale

after which I think the warnings are not saved.  Given the note in 'points' I 
sense this is expected?

TestChars(sign = -1) and TestChars(font = 5) do not give any warnings but some 
odd looking characters do appear on the device.

Here is my sessionInfo:

 > sessionInfo()
R version 2.7.0 Under development (unstable) (--)
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=en_US.UTF-8;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

other attached packages:
[1] lattice_0.17-6 RColorBrewer_1.0-2 cacher_0.1-1

loaded via a namespace (and not attached):
[1] digest_0.3.1 grid_2.7.0   tools_2.7.0


-roger

Prof Brian Ripley wrote:
> Revision r44621 supports (in a limited way) cairo 1.0 and hence I believe 
> vanilla FC5 -- I found what purports to be a vanilla FC5 box and it works 
> quite well there.
> 
> Two people have reported that the svg(), cairo-pdf() and cairo-ps() 
> devices produce blank (but not empty) files.  I was able to confirm that 
> on Debian etch (cairo 1.2.4).  They do work on cairo 1.4.14 (F8) and 
> better on a 1.5.10 snapshot.
> 
> We've got a working version on Mac OS X, but you need to install cairo.
> 
> Finally, the quality of the fonts you see will depend on what fonts you 
> have installed: if you only have X11 bitmapped fonts, that is what you 
> will get (and I am getting on our minimally configured Debian etch 
> machine).  Our Fedora installations are mainly using the URW Type 1 fonts 
> in the urw-fonts RPM.  One of the alternatives is RH's liberation fonts 
> (https://www.redhat.com/promo/fonts/).
> 
> On Mon, 25 Feb 2008, Prof Brian Ripley wrote:
> 
>> That call is from Cairo 1.2, so looks like our test FC5 box had a later 
>> version of the cairo libraries than the one pkg-config reported.
>>
>> You should be able to build with --without-cairo until such a time as we can 
>> add a suitable configure test.
>>
>> Thank you for the report.
>>
>> On Mon, 25 Feb 2008, Roger Peng wrote:
>>
>>> (Apologies, I meant to 'Reply to all' the first time but forgot).
>>>
>>> I built r44608 of R-devel with (I think) cairo support.   At least,
>>> that's what the configure script told me.  In addition,
>>> 'capabilities("cairo")' is TRUE.  Calling X11(type = "Cairo") gives me
>>> the error:
>>>
>>> Error in X11() : X11 module cannot be loaded
>>> In addition: Warning message:
>>> In X11() :
>>> unable to load shared library
>>> '/home/rpeng/install/R-devel/lib64/R/modules//R_X11.so':
>>> /home/rpeng/install/R-devel/lib64/R/modules//R_X11.so: undefined
>>> symbol: cairo_image_surface_get_data
>>>
>>>
>>> I figured I must be missing a library somewhere, but I'm not sure how
>>> to track down which one.  Any thoughts here?
>>>
>>> I'm on a FC5 system with:
>>>
>>> cairo-devel-1.0.4-1
>>> cairo-1.0.4-1
>>> cairo-1.0.4-1
>>>
>>> and
>>>
>>> pango-1.12.4-4
>>> pango-devel-1.12.4-4
>>> pango-1.12.4-4
>>>
>>> Also, I have
>>>
>>> [EMAIL PROTECTED] R-source]$ pkg-config --modversion pango
>>> 1.12.4
>>> [EMAIL PROTECTED] R-source]$ pkg-config --modversion cairo
>>> 1.0.4
>>>
>>> -roger
>>>
>>> On Mon, Feb 25, 2008 at 11:56 AM, Prof Brian Ripley
>>> <[EMAIL PROTECTED]> wrote:
 R-devel has new versions of the X11(), png() and jpeg() devices on
  Unix-alikes.  The intention is that these are used identically to the
  previous versions (which remain available) but will produce 
 higher-quality
  output with more features.

  Pros:

  Antialiasing of text and lines (can be turned off) but no blurring of
  fills.

  Buffering of the X11 display and fast repainting from a backing image.
  (The intention is to emulate the timer-based buffering of the windows()
  device in due course, but not for 2.7.0.)

  Ability to use translucent colours, including backgrounds, and produce
  partially transparent PNG files.

  Scalable text, including to sizes like 4.5 pt. This allows more accurate
  sizing on non-standard screen sizes (e.g. my home machine has a 90dpi
  1650x1024 display whereas st

Re: [Rd] New version of X11, png and jpeg

[Prof Brian Ripley]

On Tue, 26 Feb 2008, Roger D. Peng wrote:

> Thanks, running r44621 works well (on my FC5 box) and I can make various 
> plots (I just did some limited testing).
>
> When I run the 'TestChars()' example in 'points' I get many warnings of the 
> form:
>
> 1: In plot.xy(xy.coords(x, y), type = type, ...) :
>  pch value '128' is invalid in this locale
> 2: In plot.xy(xy.coords(x, y), type = type, ...) :
>  pch value '129' is invalid in this locale
> 3: In plot.xy(xy.coords(x, y), type = type, ...) :
>  pch value '130' is invalid in this locale
>
> The warnings go until
>
> 49: In plot.xy(xy.coords(x, y), type = type, ...) :
>  pch value '176' is invalid in this locale
> 50: In plot.xy(xy.coords(x, y), type = type, ...) :
>  pch value '177' is invalid in this locale
>
> after which I think the warnings are not saved.  Given the note in 'points' I 
> sense this is expected?

In a UTF_8 locale, yes.  Not in a, say, Latin-1 locale.

> TestChars(sign = -1) and TestChars(font = 5) do not give any warnings but 
> some odd looking characters do appear on the device.
>
> Here is my sessionInfo:
>
>> sessionInfo()
> R version 2.7.0 Under development (unstable) (--)
> 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=en_US.UTF-8;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
>
> other attached packages:
> [1] lattice_0.17-6 RColorBrewer_1.0-2 cacher_0.1-1
>
> loaded via a namespace (and not attached):
> [1] digest_0.3.1 grid_2.7.0   tools_2.7.0
>
>
> -roger
>
> Prof Brian Ripley wrote:
>> Revision r44621 supports (in a limited way) cairo 1.0 and hence I believe 
>> vanilla FC5 -- I found what purports to be a vanilla FC5 box and it works 
>> quite well there.
>> 
>> Two people have reported that the svg(), cairo-pdf() and cairo-ps() devices 
>> produce blank (but not empty) files.  I was able to confirm that on Debian 
>> etch (cairo 1.2.4).  They do work on cairo 1.4.14 (F8) and better on a 
>> 1.5.10 snapshot.
>> 
>> We've got a working version on Mac OS X, but you need to install cairo.
>> 
>> Finally, the quality of the fonts you see will depend on what fonts you 
>> have installed: if you only have X11 bitmapped fonts, that is what you will 
>> get (and I am getting on our minimally configured Debian etch machine). 
>> Our Fedora installations are mainly using the URW Type 1 fonts in the 
>> urw-fonts RPM.  One of the alternatives is RH's liberation fonts 
>> (https://www.redhat.com/promo/fonts/).
>> 
>> On Mon, 25 Feb 2008, Prof Brian Ripley wrote:
>> 
>>> That call is from Cairo 1.2, so looks like our test FC5 box had a later 
>>> version of the cairo libraries than the one pkg-config reported.
>>> 
>>> You should be able to build with --without-cairo until such a time as we 
>>> can add a suitable configure test.
>>> 
>>> Thank you for the report.
>>> 
>>> On Mon, 25 Feb 2008, Roger Peng wrote:
>>> 
 (Apologies, I meant to 'Reply to all' the first time but forgot).
 
 I built r44608 of R-devel with (I think) cairo support.   At least,
 that's what the configure script told me.  In addition,
 'capabilities("cairo")' is TRUE.  Calling X11(type = "Cairo") gives me
 the error:
 
 Error in X11() : X11 module cannot be loaded
 In addition: Warning message:
 In X11() :
 unable to load shared library
 '/home/rpeng/install/R-devel/lib64/R/modules//R_X11.so':
 /home/rpeng/install/R-devel/lib64/R/modules//R_X11.so: undefined
 symbol: cairo_image_surface_get_data
 
 
 I figured I must be missing a library somewhere, but I'm not sure how
 to track down which one.  Any thoughts here?
 
 I'm on a FC5 system with:
 
 cairo-devel-1.0.4-1
 cairo-1.0.4-1
 cairo-1.0.4-1
 
 and
 
 pango-1.12.4-4
 pango-devel-1.12.4-4
 pango-1.12.4-4
 
 Also, I have
 
 [EMAIL PROTECTED] R-source]$ pkg-config --modversion pango
 1.12.4
 [EMAIL PROTECTED] R-source]$ pkg-config --modversion cairo
 1.0.4
 
 -roger
 
 On Mon, Feb 25, 2008 at 11:56 AM, Prof Brian Ripley
 <[EMAIL PROTECTED]> wrote:
> R-devel has new versions of the X11(), png() and jpeg() devices on
>  Unix-alikes.  The intention is that these are used identically to the
>  previous versions (which remain available) but will produce 
> higher-quality
>  output with more features.
>
>  Pros:
>
>  Antialiasing of text and lines (can be turned off) but no blurring of
>  fills.
>
>  Buffering of the X11 display and fast repainting from a backing image.
>  (The intention is to emulate the timer-based buffering of the windows()
>  device in due course, but not for 2.7.0.)
>
>  Ability to use translucent colour

Re: [Rd] New version of X11, png and jpeg

[Michael Lawrence]

On Tue, Feb 26, 2008 at 1:00 AM, Prof Brian Ripley <[EMAIL PROTECTED]>
wrote:

> Michael,
>
> > Would it be at all feasible to make the cairo backend available on
> > all platforms and have it provide a public API through which an
> > arbitrary cairo context could be passed as the drawing target?
>
> Offering an API is something I have considered for the TODO for 2.8.0.
> However, we are at the stage of finding out how widely this can be got to
> work and how well it works.
>

This is reasonable.


>
> Simon and I are working on MacOS X, and should have this working via a
> static cairo build (without pango) shortly.


Great.


>  I don't think cairo on
> Windows works well enough: e.g. your Cairo() device has more than half the
> glyphs missing in the symbol font.
>

There are certainly issues. Hopefully most of those will be ironed out as
more win32 programs rely on Cairo (e.g. Firefox 3.0).



>
> Brian
>
>
> On Mon, 25 Feb 2008, Michael Lawrence wrote:
>
> > On Mon, Feb 25, 2008 at 10:56 AM, Prof Brian Ripley <
> [EMAIL PROTECTED]>
> > wrote:
> >
> >> R-devel has new versions of the X11(), png() and jpeg() devices on
> >> Unix-alikes.  The intention is that these are used identically to the
> >> previous versions (which remain available) but will produce
> higher-quality
> >> output with more features.
> >>
> >> Pros:
> >>
> >> Antialiasing of text and lines (can be turned off) but no blurring of
> >> fills.
> >>
> >> Buffering of the X11 display and fast repainting from a backing image.
> >> (The intention is to emulate the timer-based buffering of the windows()
> >> device in due course, but not for 2.7.0.)
> >>
> >> Ability to use translucent colours, including backgrounds, and produce
> >> partially transparent PNG files.
> >>
> >> Scalable text, including to sizes like 4.5 pt. This allows more
> accurate
> >> sizing on non-standard screen sizes (e.g. my home machine has a 90dpi
> >> 1650x1024 display whereas standard X11 fonts are set up for 75 or 100
> >> dpi).
> >>
> >> Full support for UTF-8, so on systems with suitable fonts you can plot
> in
> >> many languages on a single figure (and this will work even in non-UTF-8
> >> locales).  The output should be locale-independent (unlike the current
> >> devices where even English text is rendered slightly differently in
> >> Latin-1 and UTF-8 locales).
> >>
> >> A utility function savePlot() to make a PNG/JPEG/TIFF copy of the
> current
> >> plot.
> >>
> >> The new png() and jpeg() devices do not require an X server to be
> running.
> >>
> >> Cons:
> >>
> >> Needs more software installed - cairo, pango and support packages
> >
> >
> > Would it be at all feasible to make the cairo backend available on all
> > platforms and have it provide a public API through which an arbitrary
> cairo
> > context could be passed as the drawing target? That would allow e.g.
> > cairoDevice to be a much simpler module that draws the cairo context to
> a
> > GTK+ window and manages the window and events. In that case, it would
> need
> > to be renamed to 'gtkDevice2' or something.
> >
> > Michael
> >
> > (which
> >> on all the systems we have looked at are pulled in by the packages
> checked
> >> for).  You will see something like
> >>
> >>   Additional capabilities:   PNG, JPEG, iconv, MBCS, NLS, cairo
> >>   ^
> >> if configure finds the software we are looking for.
> >>
> >> Slower under some circumstances (although on the test systems much
> faster
> >> than packages Cairo and cairoDevice).  This will be particularly true
> for
> >> X11() with a slow connection between the machine running R and the X
> >> server.
> >>
> >> The additional software might not work correctly.
> >>
> >>
> >> The new versions are not currently the default, but can be made so by
> >> setting X11.options(type="Cairo"), e.g. as a load hook for package
> >> grDevices.  I am using
> >>
> >> setHook(packageEvent("grDevices", "onLoad"),
> >> function(...) {
> >> grDevices::ps.options(horizontal=FALSE)
> >> if(getRversion() >= '2.7.0') grDevices::X11.options
> (type="Cairo")
> >> })
> >>
> >>
> >> Please try these out and let us know how you get on.  As a check, try
> the
> >> TestChars() examples in ?points - on one Solaris 10 system a few of the
> >> symbol font characters were incorrect.  It worked on an FC5 system with
> >>
> >> auk% pkg-config --modversion pango
> >> 1.12.4
> >> auk% pkg-config --modversion cairo
> >> 1.0.4
> >>
> >> so the versions required are not all recent.
> >>
> >> Although these devices would in principle work on Mac OS X, neither
> cairo
> >> nor pango is readily available.  We are working on other versions for
> >> Mac OS (X11 based on cairo/freetype, png/jpeg based on Quartz).
> >>
> >> There are also new svg() and tiff() devices.
> >>
> >> --
> >> Brian D. Ripley,  [EMAIL PROTECTED]
> >> Professor of Applied Statistics,  
> >> http://www.stats.ox.ac.uk/~ripley/

Re: [Rd] New version of X11, png and jpeg

[Michael Lawrence]

On Tue, Feb 26, 2008 at 8:18 AM, Prof Brian Ripley <[EMAIL PROTECTED]>
wrote:

> Revision r44621 supports (in a limited way) cairo 1.0 and hence I believe
> vanilla FC5 -- I found what purports to be a vanilla FC5 box and it works
> quite well there.
>
> Two people have reported that the svg(), cairo-pdf() and cairo-ps()
> devices produce blank (but not empty) files.  I was able to confirm that
> on Debian etch (cairo 1.2.4).  They do work on cairo 1.4.14 (F8) and
> better on a 1.5.10 snapshot.
>

My intuition is that there is a missing call to cairo_show_page(). I believe
this became unnecessary in the 1.4.x series. This should probably be called
any time there is new page (after the first) and when the device is closed.


> We've got a working version on Mac OS X, but you need to install cairo.
>
> Finally, the quality of the fonts you see will depend on what fonts you
> have installed: if you only have X11 bitmapped fonts, that is what you
> will get (and I am getting on our minimally configured Debian etch
> machine).  Our Fedora installations are mainly using the URW Type 1 fonts
> in the urw-fonts RPM.  One of the alternatives is RH's liberation fonts
> (https://www.redhat.com/promo/fonts/).
>
> On Mon, 25 Feb 2008, Prof Brian Ripley wrote:
>
> > That call is from Cairo 1.2, so looks like our test FC5 box had a later
> > version of the cairo libraries than the one pkg-config reported.
> >
> > You should be able to build with --without-cairo until such a time as we
> can
> > add a suitable configure test.
> >
> > Thank you for the report.
> >
> > On Mon, 25 Feb 2008, Roger Peng wrote:
> >
> >> (Apologies, I meant to 'Reply to all' the first time but forgot).
> >>
> >> I built r44608 of R-devel with (I think) cairo support.   At least,
> >> that's what the configure script told me.  In addition,
> >> 'capabilities("cairo")' is TRUE.  Calling X11(type = "Cairo") gives me
> >> the error:
> >>
> >> Error in X11() : X11 module cannot be loaded
> >> In addition: Warning message:
> >> In X11() :
> >> unable to load shared library
> >> '/home/rpeng/install/R-devel/lib64/R/modules//R_X11.so':
> >> /home/rpeng/install/R-devel/lib64/R/modules//R_X11.so: undefined
> >> symbol: cairo_image_surface_get_data
> >>
> >>
> >> I figured I must be missing a library somewhere, but I'm not sure how
> >> to track down which one.  Any thoughts here?
> >>
> >> I'm on a FC5 system with:
> >>
> >> cairo-devel-1.0.4-1
> >> cairo-1.0.4-1
> >> cairo-1.0.4-1
> >>
> >> and
> >>
> >> pango-1.12.4-4
> >> pango-devel-1.12.4-4
> >> pango-1.12.4-4
> >>
> >> Also, I have
> >>
> >> [EMAIL PROTECTED] R-source]$ pkg-config --modversion pango
> >> 1.12.4
> >> [EMAIL PROTECTED] R-source]$ pkg-config --modversion cairo
> >> 1.0.4
> >>
> >> -roger
> >>
> >> On Mon, Feb 25, 2008 at 11:56 AM, Prof Brian Ripley
> >> <[EMAIL PROTECTED]> wrote:
> >>> R-devel has new versions of the X11(), png() and jpeg() devices on
> >>>  Unix-alikes.  The intention is that these are used identically to the
> >>>  previous versions (which remain available) but will produce
> >>> higher-quality
> >>>  output with more features.
> >>>
> >>>  Pros:
> >>>
> >>>  Antialiasing of text and lines (can be turned off) but no blurring of
> >>>  fills.
> >>>
> >>>  Buffering of the X11 display and fast repainting from a backing
> image.
> >>>  (The intention is to emulate the timer-based buffering of the
> windows()
> >>>  device in due course, but not for 2.7.0.)
> >>>
> >>>  Ability to use translucent colours, including backgrounds, and
> produce
> >>>  partially transparent PNG files.
> >>>
> >>>  Scalable text, including to sizes like 4.5 pt. This allows more
> accurate
> >>>  sizing on non-standard screen sizes (e.g. my home machine has a 90dpi
> >>>  1650x1024 display whereas standard X11 fonts are set up for 75 or 100
> >>>  dpi).
> >>>
> >>>  Full support for UTF-8, so on systems with suitable fonts you can
> plot in
> >>>  many languages on a single figure (and this will work even in
> non-UTF-8
> >>>  locales).  The output should be locale-independent (unlike the
> current
> >>>  devices where even English text is rendered slightly differently in
> >>>  Latin-1 and UTF-8 locales).
> >>>
> >>>  A utility function savePlot() to make a PNG/JPEG/TIFF copy of the
> current
> >>>  plot.
> >>>
> >>>  The new png() and jpeg() devices do not require an X server to be
> >>> running.
> >>>
> >>>  Cons:
> >>>
> >>>  Needs more software installed - cairo, pango and support packages
> (which
> >>>  on all the systems we have looked at are pulled in by the packages
> >>> checked
> >>>  for).  You will see something like
> >>>
> >>>Additional capabilities:   PNG, JPEG, iconv, MBCS, NLS, cairo
> >>>^
> >>>  if configure finds the software we are looking for.
> >>>
> >>>  Slower under some circumstances (although on the test systems much
> faster
> >>>  than packages Cairo and cairoDevice).  This will be particularly t

Re: [Rd] New version of X11, png and jpeg

[Prof Brian Ripley]

On Tue, 26 Feb 2008, Michael Lawrence wrote:

> On Tue, Feb 26, 2008 at 8:18 AM, Prof Brian Ripley <[EMAIL PROTECTED]>
> wrote:
>
>> Revision r44621 supports (in a limited way) cairo 1.0 and hence I believe
>> vanilla FC5 -- I found what purports to be a vanilla FC5 box and it works
>> quite well there.
>>
>> Two people have reported that the svg(), cairo-pdf() and cairo-ps()
>> devices produce blank (but not empty) files.  I was able to confirm that
>> on Debian etch (cairo 1.2.4).  They do work on cairo 1.4.14 (F8) and
>> better on a 1.5.10 snapshot.
>>
>
> My intuition is that there is a missing call to cairo_show_page(). I believe
> this became unnecessary in the 1.4.x series. This should probably be called
> any time there is new page (after the first) and when the device is closed.

Yes, you are quite right (and of course the 1.5.x docs I was reading 
didn't say it was needed).  Unfortunately, that only defers the problems 
as fonts are not handled correctly in 1.2.x, at least on my test machine.

-- 
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] r44608 fails make check-all in scatter.smooth example

[Martin Maechler]

> "BDR" == Prof Brian Ripley <[EMAIL PROTECTED]>
> on Mon, 25 Feb 2008 19:10:07 + (GMT) writes:

BDR> The cause is this:
BDR> r44607 | maechler | 2008-02-25 14:01:52 + (Mon, 25 Feb 2008) | 2 
lines

BDR> add Fortran type declarations in two cases, mainly for didactical 
reasons

BDR> The two declarations have been interchanged.  Fixed in 44609, I hope.


Thank you, Brian.

Indeed, I'm sorry for that, and I am wondering how I could
overlook the problem when I 'make check'ed it *before*
committing

Martin

BDR> On Mon, 25 Feb 2008, Gavin Simpson wrote:

>> Dear List,
>> 
>> Having had my appetite sufficiently whetted by Prof. Ripley's email
>> about the new graphics capabilities in Unixes, I wanted to try them out.
>> I updated to svn r44608, configured with the following options:
>> 
>> R is now configured for x86_64-unknown-linux-gnu
>> 
>> Source directory:  ..
>> Installation directory:/usr/local
>> 
>> C compiler:gcc  -O3 -g -std=gnu99 -pipe -Wall 
-fexceptions -fstack-protector -m64 -march=opteron -mtune=opteron
>> Fortran 77 compiler:   gfortran  -O3 -g -pipe -Wall -fexceptions 
-fstack-protector -m64 -march=opteron -mtune=opteron
>> 
>> C++ compiler:  g++  -O3 -g -pipe -Wall -fexceptions 
-fstack-protector -m64 -march=opteron -mtune=opteron
>> Fortran 90/95 compiler:gfortran -O3 -g -pipe -Wall -fexceptions 
-fstack-protector -m64 -march=opteron -mtune=opteron
>> Obj-C compiler:gcc -g -O2
>> 
>> Interfaces supported:  X11, tcltk
>> External libraries:readline
>> Additional capabilities:   PNG, JPEG, iconv, MBCS, NLS, cairo
>> Options enabled:   shared BLAS, R profiling, Java
>> 
>> Recommended packages:  yes
>> 
>> R compiled OK, but make check-all fails running the scatter.smooth 
example:
>> 
>> running code in 'stats-Ex.R' ...make[4]: *** [stats-Ex.Rout] Error 1
>> make[4]: Leaving directory `/home/gavin/R/devel/build/tests/Examples'
>> make[3]: *** [test-Examples-Base] Error 2
>> make[3]: Leaving directory `/home/gavin/R/devel/build/tests/Examples'
>> make[2]: *** [test-Examples] Error 2
>> make[2]: Leaving directory `/home/gavin/R/devel/build/tests'
>> make[1]: *** [test-all-basics] Error 1
>> make[1]: Leaving directory `/home/gavin/R/devel/build/tests'
>> make: *** [check-all] Error 2
>> 
>> And the Rout file contains this at the failure:
>> 
>> $ tail -n 20 tests/Examples/stats-Ex.Rout.fail
>>> 
>>> cleanEx(); nameEx("scatter.smooth")
>>> ### * scatter.smooth
>>> 
>>> flush(stderr()); flush(stdout())
>>> 
>>> ### Name: scatter.smooth
>>> ### Title: Scatter Plot with Smooth Curve Fitted by Loess
>>> ### Aliases: scatter.smooth loess.smooth
>>> ### Keywords: smooth
>>> 
>>> ### ** Examples
>>> 
>>> require(graphics)
>>> 
>>> with(cars, scatter.smooth(speed, dist))
>> Error in .Fortran(R_lowesw, as.double(fitted.residuals), as.integer(N),  
:
>> Incorrect number of arguments (4), expecting 7 for lowesw
>> Calls: with ... scatter.smooth -> loess.smooth -> simpleLoess -> .Fortran
>> Execution halted
>> 
>> This is on Fedora 8.
>> 
>> Plots on the new X11() device look very nice though!
>> 
>> Cheers,
>> 
>> G
>> --
>> %~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%
>> Dr. Gavin Simpson [t] +44 (0)20 7679 0522
>> ECRC, UCL Geography,  [f] +44 (0)20 7679 0565
>> Pearson Building, [e] gavin.simpsonATNOSPAMucl.ac.uk
>> Gower Street, London  [w] http://www.ucl.ac.uk/~ucfagls/
>> UK. WC1E 6BT. [w] http://www.freshwaters.org.uk
>> %~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%
>> 
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>> 

BDR> -- 
BDR> Brian D. Ripley,  [EMAIL PROTECTED]
BDR> Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
BDR> University of Oxford, Tel:  +44 1865 272861 (self)
BDR> 1 South Parks Road, +44 1865 272866 (PA)
BDR> Oxford OX1 3TG, UKFax:  +44 1865 272595

BDR> __
BDR> R-devel@r-project.org mailing list
BDR> 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] Aliasing a function

[hadley wickham]

Thanks Tony (and others), for getting me started.  I eventually ended up with:

TopLevel$build_accessor <- function(., extra_args = c()) {
  layer <- if (.$class() %in% c("geom","stat", "position")) c(
list(mapping=NULL,data=NULL),
compact(list(
  geom = if (exists("default_geom", .)) .$default_geom()$objname,
  stat = if (exists("default_stat", .)) .$default_stat()$objname,
  position = if (exists("default_pos", .)) .$default_pos()$objname
))
  )
  params <- .$params()
  params <- params[names(params) != "..."]
  args <- c(layer, params)

  body <- ps(
.$myName(), "$", "new(",
if (length(args) > 0) ps(names(args),"=", names(args), collase =", "),
if (length(extra_args) > 0) ps(names(extra_args),"=", extra_args,
collase =", "),
"...",
")"
  )
  f <- function() {}
  formals(f) <- as.pairlist(c(args, alist(... =)))
  body(f) <- parse(text = body)
  environment(f) <- globalenv()
  f
}

-- obviously there are far more ggplot details in there than I had
first anticipated.

Hadley

On Mon, Feb 25, 2008 at 12:24 AM, Tony Plate <[EMAIL PROTECTED]> wrote:
> Maybe something like this? (though it seems like it might be more
>  straightforward to do this sort of thing by text-processing a source
>  file then source'ing it in R).
>
>   > f <- function(a, b, c) c(a=a,b=b,c=c)
>   > attr(f, "source") <- NULL
>   > f
>  function (a, b, c)
>
> c(a = a, b = b, c = c)
>   > g1 <- f
>   > ff <- formals(f)
>   > argtrans <- c(a="d", b="e", c="f")
>   > names(ff) <- argtrans
>   > g2 <- as.function(c(ff, as.call(c(list(as.name("f")),
>  lapply(argtrans, as.name)
>   > g2
>  function (d, e, f)
>  f(a = d, b = e, c = f)
>   > f(1,2,3)
>  a b c
>  1 2 3
>   > g1(a=1,b=2,c=3)
>  a b c
>  1 2 3
>   > g2(d=1,e=2,f=3)
>  a b c
>  1 2 3
>   >
>
>  -- Tony Plate
>
>
>
>
>  hadley wickham wrote:
>  > On Sat, Feb 23, 2008 at 5:52 PM, Gabor Grothendieck
>  > <[EMAIL PROTECTED]> wrote:
>  >
>  >> I assume he wants to be able to change the
>  >>  formals although its confusing since the example
>  >>  uses the same formals in both cases.
>  >>
>  >
>  > Yes, that was an important point that I forgot to mention!  Thanks for
>  > the pointer to formals but it doesn't work in this case:
>  >
>  > function (a = 1, b = 2, c = 3)
>  > g(...)
>  >
>  >> f(c=5)
>  >>
>  > Error in f(c = 5) : '...' used in an incorrect context
>  >
>  > Hadley
>  >
>  >
>  >
>
>



-- 
http://had.co.nz/

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

[Rd] error loading library

[Vadim Organovich]

Hi,

I am debugging intermittent crashes of R that seem to happen when multiple R 
sessions nearly summaltaneously load same dll-based library.

I have R and my libraries installed on a network drive (everything is Windows). 
The drive is visible from a farm of servers. I have an R script, foo.R, that 
just loads a dll-based library (to be precise it loads a library that requires 
a dll-based library). When I start R (via Rscript --vanilla foo.R) from all of 
the farm computers summaltaneously some of the sessions often crash. It doesn't 
seem to be specific to the library, I was able to reproduce this with the gbm 
library as well as with my own library. It feels that the longer it takes to 
load the library the higher the probability of the crash.

foo.R :
library(vmisc)

The most informative error message I've got so far looks like this, here vmisc 
dll is the required library that dynamically loads a dll.

Loading required package: vmiscdll
Error in file(file, "r") : unable to open connection
In addition: Warning message:
In file(file, "r") :
  cannot open file 'q:/R/vogranovich/library/vmisc/R/vmisc', reason 'Permission 
denied'
Error : unable to load R code in package 'vmisc'
Error: package/namespace load failed for 'vmisc'
Execution halted
Exit Code 1 - Process forcefully killed by the TestMaster
In stand alone sessions, interactive or not, everything loads fine.

Does loading a library place some sort of a lock?

I would appreciate any help with this matter.

Regards,
Vadim

[[alternative HTML version deleted]]

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

Re: [Rd] error loading library

[Oleg Sklyar]

Could it be connected with the fact that each R session creates an 
Rtmp directory in tmp (at least on UNIX-alike) and that if started 
simultaneously on machines with the same time stamp they might want to 
use a directory with the same ? It still does not explain the 
behaviour much as, first, loading a package (with a shared object and 
external dependencies) does not seem to cause creation of any files 
there, and, second, I have never experienced such problems of our Linux 
farm although there were situations where I launched about a hundred of 
R session on a farm at the same time. Maybe the external library itself 
uses this temp space and locks it?

Oleg

Vadim Organovich wrote:
> Hi,
> 
> I am debugging intermittent crashes of R that seem to happen when multiple R 
> sessions nearly summaltaneously load same dll-based library.
> 
> I have R and my libraries installed on a network drive (everything is 
> Windows). The drive is visible from a farm of servers. I have an R script, 
> foo.R, that just loads a dll-based library (to be precise it loads a library 
> that requires a dll-based library). When I start R (via Rscript --vanilla 
> foo.R) from all of the farm computers summaltaneously some of the sessions 
> often crash. It doesn't seem to be specific to the library, I was able to 
> reproduce this with the gbm library as well as with my own library. It feels 
> that the longer it takes to load the library the higher the probability of 
> the crash.
> 
> foo.R :
> library(vmisc)
> 
> The most informative error message I've got so far looks like this, here 
> vmisc dll is the required library that dynamically loads a dll.
> 
> Loading required package: vmiscdll
> Error in file(file, "r") : unable to open connection
> In addition: Warning message:
> In file(file, "r") :
>   cannot open file 'q:/R/vogranovich/library/vmisc/R/vmisc', reason 
> 'Permission denied'
> Error : unable to load R code in package 'vmisc'
> Error: package/namespace load failed for 'vmisc'
> Execution halted
> Exit Code 1 - Process forcefully killed by the TestMaster
> In stand alone sessions, interactive or not, everything loads fine.
> 
> Does loading a library place some sort of a lock?
> 
> I would appreciate any help with this matter.
> 
> Regards,
> Vadim
> 
>   [[alternative HTML version deleted]]
> 
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

-- 
Dr Oleg Sklyar * EBI-EMBL, Cambridge CB10 1SD, UK * +44-1223-494466

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

[Rd] tiny typo (sort of) in plot.c

[Ben Bolker]

The warning in "identify" when no point is close enough
to the clicked point is

./src/main/plot.c:3190: REprintf(_("warning: no point with 
%.2f inches\n"), tol);

   that should probably be "within" ...

   Ben Bolker

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

[Rd] d_fontdb.d, g_her_glyph.d

[Matthias Kohl]

Dear Developers,

I'm updating my R installation via svn (currently: Revision 44626). For 
some time now (sorry don't know the exact revision number) make for R 
devel yields the following error

make[4]: *** Keine Regel vorhanden, um das Target 
»../../../src/include/R_ext/GraphicsBase.h«,
  benötigt von »g_fontdb.o«, zu erstellen.  Schluss.

(translation: no rule to make target ... needed from ...)

The file "g_fontdb.d" (and also g_her_glyph.d) has the last line
../../../src/include/R_ext/GraphicsBase.h

Is this line obligate due to 1) in
https://svn.r-project.org/R-dev-web/trunk/270update.txt
?

At least, if I remove this last line in these two files make runs 
without an error.
Is there another explanation for this error?

Thanks for your help!
Matthias

#
My configure output is:
R is now configured for i686-pc-linux-gnu

  Source directory:  .
  Installation directory:/usr/local

  C compiler:gcc -std=gnu99  -g -O2
  Fortran 77 compiler:   g77  -g -O2

  C++ compiler:  g++  -g -O2
  Fortran 90/95 compiler:g77 -g -O2
  Obj-C compiler:

  Interfaces supported:  X11, tcltk
  External libraries:readline
  Additional capabilities:   PNG, JPEG, iconv, MBCS, NLS, cairo
  Options enabled:   shared BLAS, R profiling, Java

  Recommended packages:  yes

#
my system is: (sessionInfo from R version 2.6.2 Patched (2008-02-10 r44423))
i686-pc-linux-gnu

locale:
LC_CTYPE=de_DE.UTF-8;LC_NUMERIC=C;LC_TIME=de_DE.UTF-8;LC_COLLATE=de_DE.UTF-8;LC_MONETARY=de_DE.UTF-8;LC_MESSAGES=de_DE.UTF-8;LC_PAPER=de_DE.UTF-8;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=de_DE.UTF-8;LC_IDENTIFICATION=C

-- 
Dr. Matthias Kohl
www.stamats.de

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

[Rd] Unix-like touch to update modification timestamp of file?

[Henrik Bengtsson]

Hi,

is it possible to update the modification time stamp of a file using R
(on file systems supporting it)?  It is sufficient to update the
modification time to the current time.  The best I can do for now is:

touchFile <- function(pathname, ...) {
  if (!file.exists(pathname))
stop("No such file: ", pathname);

  info <- file.info(pathname);
  if (info$isdir)
stop("Cannot change the timestamp of a directory: ", pathname);

  oldTimestamp <- info$mtime;

  con <- NULL;
  on.exit({
if (!is.null(con))
  close(con);
  });

  # Zero-sized files have to be treated specially
  if (info$size == 0) {
con <- file(pathname, open="w");
  } else {
con <- file(pathname, open="r+b");
seek(con=con, where=0, origin="start", rw="read");
bfr <- readBin(con=con, what="raw", n=1);
seek(con=con, where=0, origin="start", rw="write");
writeBin(con=con, bfr);
  }

  invisible(oldTimestamp);
} # touchFile()


# 1. Create a file
pathname <- tempfile()
cat(file=pathname, "Hello world!")
md5a <- digest::digest(pathname, file=TRUE);

# 2. Current time stamp
print(file.info(pathname)$mtime)
## [1] "2008-02-26 21:41:23 Pacific Standard Time"

# 3. Update time stamp
Sys.sleep(1.2);
touchFile(pathname)
print(file.info(pathname)$mtime)
## [1] "2008-02-26 21:41:24 Pacific Standard Time"

# 4. Verify that the contents did not change
md5b <- digest::digest(pathname, file=TRUE);
stopifnot(identical(md5a, md5b))

/Henrik

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

[Rd] Warnings generated by log2()/log10() are really large/takes a long time to display

[Henrik Bengtsson]

x <- rnorm(1e6);

y <- log(x);  # or logb(x) or log1p(x)
w <- warnings();
print(object.size(w));
## [1] 480
str(w);
 $ NaNs produced: language log(x)
 - attr(*, "dots")= list()
 - attr(*, "class")= chr "warnings"

y <- log2(x);  # or log10(x)
w <- warnings();
print(object.size(w));
## [1] 8000536
str(w);
## List of 1
##  $ NaNs produced: language log(c(2.12082478659910,
1.40263187453398, 1.574125429
## 83486, -0.816399069824751,  0.215940065840533, 1.20975177084379,
-0.340287874362
## 813, 0.117151537611550,  ...
##  - attr(*, "dots")= list()
##  - attr(*, "class")= chr "warnings"

Note also how long it takes to display and str() the warning.

I have observed this on R v2.6.2 and R v2.7.0 (2008-02-11 r44432) on
both WinXP and Linux.

/Henrik

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

Re: [Rd] d_fontdb.d, g_her_glyph.d

[Matthias Kohl]

now, it works ...
Thanks!

Prof Brian Ripley wrote:
> On Wed, 27 Feb 2008, Matthias Kohl wrote:
>
>> Dear Developers,
>>
>> I'm updating my R installation via svn (currently: Revision 44626). For
>> some time now (sorry don't know the exact revision number) make for R
>> devel yields the following error
>
> You need to start a clean build: you are updating from a rather old one.
> Try something like
>
> make distclean
> ./configure
> make
>
> In some cases (and this was one) if you update every day it may work, 
> but in a few cases you will need to rebuild from scratch after a change.
>
>>
>> make[4]: *** Keine Regel vorhanden, um das Target
>> »../../../src/include/R_ext/GraphicsBase.h«,
>>  benötigt von »g_fontdb.o«, zu erstellen.  Schluss.
>>
>> (translation: no rule to make target ... needed from ...)
>>
>> The file "g_fontdb.d" (and also g_her_glyph.d) has the last line
>> ../../../src/include/R_ext/GraphicsBase.h
>>
>> Is this line obligate due to 1) in
>> https://svn.r-project.org/R-dev-web/trunk/270update.txt
>> ?
>>
>> At least, if I remove this last line in these two files make runs
>> without an error.
>> Is there another explanation for this error?
>>
>> Thanks for your help!
>> Matthias
>>
>> #
>> My configure output is:
>> R is now configured for i686-pc-linux-gnu
>>
>>  Source directory:  .
>>  Installation directory:/usr/local
>>
>>  C compiler:gcc -std=gnu99  -g -O2
>>  Fortran 77 compiler:   g77  -g -O2
>>
>>  C++ compiler:  g++  -g -O2
>>  Fortran 90/95 compiler:g77 -g -O2
>>  Obj-C compiler:
>>
>>  Interfaces supported:  X11, tcltk
>>  External libraries:readline
>>  Additional capabilities:   PNG, JPEG, iconv, MBCS, NLS, cairo
>>  Options enabled:   shared BLAS, R profiling, Java
>>
>>  Recommended packages:  yes
>>
>> #
>> my system is: (sessionInfo from R version 2.6.2 Patched (2008-02-10 
>> r44423))
>> i686-pc-linux-gnu
>>
>> locale:
>> LC_CTYPE=de_DE.UTF-8;LC_NUMERIC=C;LC_TIME=de_DE.UTF-8;LC_COLLATE=de_DE.UTF-8;LC_MONETARY=de_DE.UTF-8;LC_MESSAGES=de_DE.UTF-8;LC_PAPER=de_DE.UTF-8;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=de_DE.UTF-8;LC_IDENTIFICATION=C
>>  
>>
>>
>> -- 
>> Dr. Matthias Kohl
>> www.stamats.de
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>

-- 
Dr. Matthias Kohl
www.stamats.de

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

Re: [Rd] d_fontdb.d, g_her_glyph.d

[Prof Brian Ripley]

On Wed, 27 Feb 2008, Matthias Kohl wrote:


Dear Developers,

I'm updating my R installation via svn (currently: Revision 44626). For
some time now (sorry don't know the exact revision number) make for R
devel yields the following error


You need to start a clean build: you are updating from a rather old one.
Try something like

make distclean
./configure
make

In some cases (and this was one) if you update every day it may work, but 
in a few cases you will need to rebuild from scratch after a change.




make[4]: *** Keine Regel vorhanden, um das Target
»../../../src/include/R_ext/GraphicsBase.h«,
 benötigt von »g_fontdb.o«, zu erstellen.  Schluss.

(translation: no rule to make target ... needed from ...)

The file "g_fontdb.d" (and also g_her_glyph.d) has the last line
../../../src/include/R_ext/GraphicsBase.h

Is this line obligate due to 1) in
https://svn.r-project.org/R-dev-web/trunk/270update.txt
?

At least, if I remove this last line in these two files make runs
without an error.
Is there another explanation for this error?

Thanks for your help!
Matthias

#
My configure output is:
R is now configured for i686-pc-linux-gnu

 Source directory:  .
 Installation directory:/usr/local

 C compiler:gcc -std=gnu99  -g -O2
 Fortran 77 compiler:   g77  -g -O2

 C++ compiler:  g++  -g -O2
 Fortran 90/95 compiler:g77 -g -O2
 Obj-C compiler:

 Interfaces supported:  X11, tcltk
 External libraries:readline
 Additional capabilities:   PNG, JPEG, iconv, MBCS, NLS, cairo
 Options enabled:   shared BLAS, R profiling, Java

 Recommended packages:  yes

#
my system is: (sessionInfo from R version 2.6.2 Patched (2008-02-10 r44423))
i686-pc-linux-gnu

locale:
LC_CTYPE=de_DE.UTF-8;LC_NUMERIC=C;LC_TIME=de_DE.UTF-8;LC_COLLATE=de_DE.UTF-8;LC_MONETARY=de_DE.UTF-8;LC_MESSAGES=de_DE.UTF-8;LC_PAPER=de_DE.UTF-8;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=de_DE.UTF-8;LC_IDENTIFICATION=C

--
Dr. Matthias Kohl
www.stamats.de

__
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