When R is compiled with cairo, running something like "example(getGraphicsEvent())" results in an error stating "this graphics device does not support event handling". The patch to src/modules/X11/devX11.c will correct this. Additional information on this bug can be found at http://bugs.r-project.org/bugzilla3/show_bug.cgi?id=14364 When R is compiled with atlas support, a typo in the value passwd to --with-lapack prevent it from linking against lapack, and libRlapack.so does not get installed so linear algebra functions will fail since lapack.so will not be able to load the shared object libRlapack.so Added file(s): - files/patch-src__modules__X11__devX11.c Port maintainer (bf@FreeBSD.org) is cc'd. Generated with FreeBSD Port Tools 0.99 How-To-Repeat: For the cairo issue, run example(getGraphicsEvent); in an R session For the atlas issue, invert a matrix: solve(matrix(1:4, nrow=2, ncol=2))
Responsible Changed From-To: freebsd-ports-bugs->bf Over to maintainer (via the GNATS Auto Assign Tool)
> When R is compiled with cairo, running something like "example(getGraphicsEvent())" results > in an error stating "this graphics device does not support event handling". The patch to > src/modules/X11/devX11.c will correct this. Additional information on this bug can be found at > http://bugs.r-project.org/bugzilla3/show_bug.cgi?id=14364 There doesn't seem to be a consensus upstream about the nature of the problem, and whether this is the proper fix, which is why it was not included in recent releases. I will look into this. > > When R is compiled with atlas support, a typo in the value passwd to --with-lapack prevent it from > linking against lapack, and libRlapack.so does not get installed so linear algebra functions will > fail since lapack.so will not be able to load the shared object libRlapack.so > This is not a typo: libalapack.so is the math/atlas lapack library that should be used in lieu of the bundled libRlapack.so when WITH_ATLAS is selected. The patch instructs R to use a mixture of libraries from math/lapack and math/atlas, and this is wrong. If the submitter wants to use alternative blas and lapack libraries (other than math/atlas) instead of the bundled blas and lapack, he can set WITHOUT_ATLAS, BLAS, and LAPACK to appropriate values in his build environment or an included Makefile. If there is a problem with R when the non-default option WITH_ATLAS is selected, I suspect it is due to some problems with math/atlas that I have yet to correct after recently succeeding Maho as maintainer of the atlas ports, but this needs investigation. I will also look into this. > Added file(s): > - files/patch-src__modules__X11__devX11.c > > Port maintainer (bf@FreeBSD.org) is cc'd. > > Generated with FreeBSD Port Tools 0.99 > How-To-Repeat: > > For the cairo issue, run > example(getGraphicsEvent); in an R session > > For the atlas issue, invert a matrix: > solve(matrix(1:4, nrow=2, ncol=2))
I looked at the first issue, and, as the upstream developers said when they refused to accept the patch, this code is not expected to work with the cairo device, which does not generate or handle events: "the problem was that the code did not check that the device was capable of generating events, so it would wait forever for something that wouldn't happen..." which is why the check that bars the use of the cairo device with this code was introduced. So it would not be a good idea to introduce this patch (which the submitter acknowledged was incomplete, anyway). You can however switch devices, and then use example(getGraphicsEvent... In the new version of R which will be coming out near the end of the month, this area has been substantially reworked, with many fixes and extensions for the cairo and other graphics devices. With regard to the second issue, the failure in your example was, as I expected, due to the long-standing problem with the construction of the atlas shared libraries, which lack some tags to assist the loader. I have prepared an atlas update which fixes this and some other problems, and I am waiting for feedback from some testers. I will probably be able to commit that update soon. b.
bf 2011-09-24 18:36:59 UTC FreeBSD ports repository Modified files: math/atlas Makefile distinfo pkg-descr pkg-plist math/atlas/files patch-CONFIG+src+SpewMakeInc.c patch-CONFIG+src+backend+archinfo_freebsd.c Added files: math/atlas/files patch-CONFIG+src+backend+archinfo_x86.c patch-makes+Make.sysinfo tuning-message Removed files: math/atlas/files Makefile.test alpha-patch patch-CONFIG+src+atlcomp.txt thread-patch Log: Update to 3.8.4 before the 3.10 release; clean up (substantially reduce build times, introduce options, drop unneeded dependencies, and make linking with ATLAS shared libraries easier) Thanks to maho and A. Shterenlikht for review and testing, and to mm, T. Ludwig, skreuzer, and E. Lemos de Sa for reminders or related submissions PR: 117923, 139169, 155650, 159876 Revision Changes Path 1.64 +198 -210 ports/math/atlas/Makefile 1.15 +2 -2 ports/math/atlas/distinfo 1.4 +0 -35 ports/math/atlas/files/Makefile.test (dead) 1.2 +0 -9 ports/math/atlas/files/alpha-patch (dead) 1.2 +52 -7 ports/math/atlas/files/patch-CONFIG+src+SpewMakeInc.c 1.4 +0 -124 ports/math/atlas/files/patch-CONFIG+src+atlcomp.txt (dead) 1.2 +88 -26 ports/math/atlas/files/patch-CONFIG+src+backend+archinfo_freebsd.c 1.3 +14 -0 ports/math/atlas/files/patch-CONFIG+src+backend+archinfo_x86.c (new) 1.1 +11 -0 ports/math/atlas/files/patch-makes+Make.sysinfo (new) 1.5 +0 -12 ports/math/atlas/files/thread-patch (dead) 1.1 +35 -0 ports/math/atlas/files/tuning-message (new) 1.7 +17 -21 ports/math/atlas/pkg-descr 1.11 +24 -48 ports/math/atlas/pkg-plist _______________________________________________ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org"
State Changed From-To: open->closed The ATLAS problem should now be fixed after the update of math/atlas.