Thanks, Michael and Simon. My main concern was to discover
where we are at. It will be great if this can be resolved for 2.8
Cheers
John.
John Maindonald email: [EMAIL PROTECTED]
phone : +61 2 (6125)3473 fax : +61 2(6125)5549
Centre for Mathematics & Its Applications, Room 1194,
John Dedman Mathematical Sciences Building (Building 27)
Australian National University, Canberra ACT 0200.
On 25/09/2008, at 12:13 AM, Michael Lawrence wrote:
On Wed, Sep 24, 2008 at 6:53 AM, Simon Urbanek
<[EMAIL PROTECTED]>wrote:
On Sep 24, 2008, at 7:12 , John Maindonald wrote:
I've had a brief exchange of emails, to which Simon is privy, with
Michael
Lawrence.
"From what I've heard, people who compile the entire toolchain,
i.e. do
not use Simon's GTK+, cairo, etc binaries, do not have a problem
with
cairoDevice on the Mac. ... In the past, the seg faults were
occuring in the
font handling code, whenever rotated text was drawn. Of course,
this is
probably just a sign of memory corruption elsewhere, but my guess
is that's
related to the Pango/Cairo interaction."
Has anyone had success going this route (compiling the entire
toolchain)?
If one does go this route, how should it be done? Install
MacPorts and
follow the instructions on the MacPorts web page? I found detailed
instructions on a web page that is designed to make it possible to
reproduce
a problem with fonts:
http://trac.macports.org/ticket/15626
I have script that can build RGtk2 quite nicely in a separate
framework. I
plan to make this the default binary for R 2.8, but for
compatibility's sake
we cannot switch for 2.7. I can make the binary and/or the script
available
for those interested. (It started as way to test the bleeding edge
of the
native Gtk for OS X, but tests on ggobi show that it's not quite
there yet -
but that's another story).
Cheers,
Simon
PS: I don't quite agree with Michael's analysis since cairoDevices
blows up
even before any drawing is done, it has nothing to do with rotated
text:
Well there are different bugs on different systems, I guess. This
one seems
seems easier to understand. Somehow the Cairo context doesn't have a
surface. I will try to find a Mac at my work today or tomorrow and
take a
look at this. Question: is this using the Quartz backend of GDK or the
stable X11 one?
#0 _cairo_surface_show_page (surface=0x0) at
../../../cairo-1.4.14/src/cairo-surface.c:1541
#1 0x0116c66a in cairo_show_page (cr=0xe02800) at
../../../cairo-1.4.14/src/cairo.c:2139
#2 0x011694bf in initDevice (dd=0x668c20) at cairoDevice.c:114
#3 0x0116960f in Cairo_NewPage (gc=0xbfffeb1c, dd=0x61f860) at
cairoDevice.c:660
#4 0x0038e16a in Rf_GNewPlot (recording=TRUE) at
../../../../R-2.7-branch/src/main/graphics.c:1809
(gdb) p cd
$2 = (CairoDesc *) 0x61cc70
(gdb) p *cd
$3 = {
window = 0x32ac020,
drawing = 0x17fb050,
pixmap = 0x32af080,
cr = 0xe02800,
surface = 0x0,
By the way, having a NULL surface here is normal if the drawing is
on-screen. I let GDK handle the surface in that case.
filename = 0x0,
width = 525,
height = 525,
event = 0x0,
locator = 0x0
}
On 23/09/2008, at 11:32 PM, Simon Urbanek wrote:
On Sep 23, 2008, at 0:20 , John Maindonald wrote:
Has anyone been able to get packages that rely on Gtk2 to run under
Leopard?
Yes, I see no problem with Gtk2.
I have experimented with the playwith package, as depending on a
small
number of packages additional to Gtk2. I can pretty
consistently generate
a bus error by attaching playwith, then printing a lattice
object. Note
that I have not run any functions from the playwith package.
The same may happen if I attach all the packages on which playwith
depends (but not playwith itself), but the bus error does not
appear with
the same consistency.
The problem appears to be in Michael's carioDevice, it crashes
because
its cairo context is NULL. I suspect it may not have a good error
handling.
I'm not sure what causes the problem, you may try to contact
Michael.
Neither the built-in R cairo device nor the Cairo package have
any problems,
so I don't think it's a problem on the cairo side...
Cheers,
Simon
Here is a transcript on a session:
[Previously saved workspace restored]
options(STERM='iESS', editor='emacsclient')
library(lattice)
library(playwith)
Loading required package: latticeExtra
Loading required package: RColorBrewer
Loading required package: grid
Loading required package: gWidgets
Loading required package: gWidgetsRGtk2
Loading required package: RGtk2
Loading required package: cairoDevice
sessionInfo()
R version 2.7.2 (2008-08-25)
i386-apple-darwin8.11.1
locale:
C
attached base packages:
[1] grid stats graphics grDevices utils datasets
methods
[8] base
other attached packages:
[1] playwith_0.9-11 cairoDevice_2.8 gWidgetsRGtk2_0.0-36
[4] RGtk2_2.12.5-3 gWidgets_0.0-28 latticeExtra_0.5-1
[7] RColorBrewer_1.0-2 lattice_0.17-13
loaded via a namespace (and not attached):
[1] gridBase_0.4-3 tools_2.7.2
Warning message:
'DESCRIPTION' file has 'Encoding' field and re-encoding is not
possible
gph <- xyplot(weight ~ height, data=women)
print(gph)
*** caught bus error ***
address 0xa8, cause 'non-existent physical address'
Traceback:
1: .Call(L_newpage)
2: grid.newpage()
3: printFunction(x, ...)
4: print.trellis(gph)
5: print(gph)
Possible actions:
1: abort (with core dump, if enabled)
2: normal R exit
3: exit R without saving workspace
4: exit R saving workspace
Selection: 1
aborting ...
Process R bus error at Tue Sep 23 14:01:23 2008
John Maindonald email: [EMAIL PROTECTED]
phone : +61 2 (6125)3473 fax : +61 2(6125)5549
Centre for Mathematics & Its Applications, Room 1194,
John Dedman Mathematical Sciences Building (Building 27)
Australian National University, Canberra ACT 0200.
_______________________________________________
R-SIG-Mac mailing list
[email protected]
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
_______________________________________________
R-SIG-Mac mailing list
[email protected]
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
[[alternative HTML version deleted]]
_______________________________________________
R-SIG-Mac mailing list
[email protected]
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
_______________________________________________
R-SIG-Mac mailing list
[email protected]
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
