On Mon, 2/20/17, Martin Maechler <maech...@stat.math.ethz.ch> wrote:
Subject: Re: [Rd] another fix for R crashes under enable-strict-barrier, lto,
trunk@72156
To: "Hin-Tak Leung" <ht...@users.sourceforge.net>
Cc: r-devel@r-project.org, "bonsai list"
<outmodedbonsai-annou...@li
I haven' t touched R for some 18 months, and so I have no idea if this is a
recent problems or not; but it certainly did not segfault two years ago.
Since it has been crashing (segfault) under 'make check-all' for over a month,
I reckon I'll have to look at it myself, to have it fixed.
I have
geDevice has been failing check for 6 weeks now with --enable-strict-barrier ,
bisected to:
r69049 | murrell | 2015-08-14 00:03:12 +0100 (Fri, 14 Aug 2015) | 2 lines
first hack at adding grid display list to recorded plot
--
On Sat, May 16, 2015 2:33 PM BST Marc Schwartz wrote:
On May 16, 2015, at 6:11 AM, Hin-Tak Leung ht...@users.sourceforge.net
wrote:
--
On Sat, May 16, 2015 8:04 AM BST Uwe Ligges wrote:
Not sure why this goes to R-devel
is an
R-devel issue.
On 16.05.2015 07:22, Hin-Tak Leung wrote:
'make check-all' for current R has been showing this error in the middle
for a few months now - any thought on fixing this? I think cmprsk
should be either included in the recommended bundle, or
the survival vignette to not depend
'make check-all' for current R has been showing this error in the middle
for a few months now - any thought on fixing this? I think cmprsk
should be either included in the recommended bundle, or
the survival vignette to not depend on it. Having 'make check-all' showing
glaring ERROR's for a few
.
On Wed, 21/1/15, Hin-Tak Leung ht...@users.sourceforge.net wrote:
R.framework-Versions-Resources-library-grDevices-libs-cairo_20150120.tgz
in
http://sourceforge.net/projects/outmodedbonsai/files/R/
are dropped in replacement to the cairo.so's in the official
R
R.framework-Versions-Resources-library-grDevices-libs-cairo_20150120.tgz in
http://sourceforge.net/projects/outmodedbonsai/files/R/
are dropped in replacement to the cairo.so's in the official R binaries
(2.15.3, 3.0.3, 3.1.2).
updated to cairo-1.12.18 and freetype-2.5.4. The official R
is that GCC version 4.9 did
make some changes to enhance link-time optimization [5], and probably
something isn't compatible.
Right. Just before Christmas, Hin-Tak Leung reported build failure with
LTO:
https://stat.ethz.ch/pipermail/r-devel/2014-December/070286.html
https://stat.ethz.ch
is for passing make check, when you finish make.
--
On Thu, Jan 8, 2015 6:14 PM GMT Avraham Adler wrote:
On Thu, Jan 8, 2015 at 10:48 AM, Hin-Tak Leung
ht...@users.sourceforge.net wrote:
The r.dll crash is easy - you need to be using gcc-ar for ar, and gcc-ranlib
for ranlib
R fails to build with visibility on and gcc 4.9's link time optimzation, because
of its practice of building part of it as archive first. Specifically
it builds some bundled libraries as archive first, the symbols of which
are then entirely invisible in gcc 4.9.
The Matrix package also does this
My main dev machine died a well-deserved death a few weeks ago after six
and a half years of faithful service, and refused to be re-animated. A
substantial
part of setting up its replacement is re-running a lot of R vignettes (mostly
for timing to establish new performance baselines) - and also
At least as far as I am concerned, I'll remove dependency on hexbin, if it
comes to that.
The dependency is only used in some vignettes, and quite non-essential, and
perhaps,
undesirable, in fact.
On Fri, 8/8/14, Uwe Ligges uwe.lig...@r-project.org
Since R 3.0.3 is just around the corner and the problem is still there, here is
a repost from around the new year.
Hin-Tak Leung wrote:
Just before the holiday, I asked the freetype developers what is the context
of these two comments about freetype in the code of R's grDevices:
=== R/src
Hin-Tak Leung wrote:
...
Somewhat related, I have finally gotten round to make two small bundles,
which replace the small cairo.dll/cairo.so' in the official
windows or Mac R binaries, to fix quite a few problems with them,
the first of which was reported almost a year ago. Just move the two
Just before the holiday, I asked the freetype developers what is the context
of these two comments about freetype in the code of R's grDevices:
=== R/src/library/grDevices/src/cairo/cairoFns.c around line 720 =
/* some FreeType versions have broken index support,
--
On Fri, Dec 13, 2013 16:29 GMT David Winsemius wrote:
On Dec 11, 2013, at 7:30 PM, Hin-Tak Leung wrote:
Here is a rather long discussion etc about freetype 2.5.2, problem with the
survival package, and build R 2.15.x with gcc 4.8.x. Please feel free to
skip
,
...)
7: summary.data.frame(support)
...
r62430 needs a bit of adapting to apply to R 2.15.x , but you get the idea.
I hope this info is useful to somebody else who is still using R 2.15.x , no
doubt for very good reasons.
Hin-Tak Leung wrote:
The freetype people
upgrade of mono 3.2 5. It is, as usual, slightly adapted to
run Illumina GenomeStudio and ...-like workloads on Linux and Mac OS X better.
Hin-Tak Leung wrote:
The most up-to-date version of freetype (2.5.0.1) have problems with at least
two of the system fonts shipped with Mac OS X. So the p1
with a system font, and cairo and R etc.
Unix users should just upgrade. I'll get round to build R 2.15.3 (or 2.15.x) for
windows and Mac OS X at some stage, but if somebody want to beat me to it,
please feel free to do so.
Hin-Tak Leung wrote:
Freetype 2.4.12 was released in early May. Just
a listing of versions.
http://sourceforge.net/projects/outmodedbonsai/files/R/
Unix users should just upgrade. I'll get round to build R 2.15.3 (or 2.15.x)
for windows and Mac OS X at some stage, but if somebody want to beat me to it,
please feel free to do so.
--- On Tue, 2/4/13, Hin-Tak Leung ht
--- On Mon, 1/4/13, Hin-Tak Leung ht...@users.sourceforge.net wrote:
--- On Sat, 30/3/13, Hin-Tak Leung
ht...@users.sourceforge.net
wrote:
... was committed to freetype in January and will form
the
next release (2.4.12).
It is perhaps worth repeating the quote: 'The official
R
--- On Sat, 30/3/13, Hin-Tak Leung ht...@users.sourceforge.net wrote:
... was committed to freetype in January and will form the
next release (2.4.12).
It is perhaps worth repeating the quote: 'The official R binaries for windows
... are compiled against static libraries of cairo 1.10.2
:
Huh?
This is utterly incomprehensible without reading the redhat
bugzilla, and even after reading, I'm not sure what the
issue is. Something with bold Chinese fonts in X11, but
maybe also affecting Latin fonts, ?
Please explain yourself.
-pd
On Mar 30, 2013, at 09:25 , Hin-Tak
... was committed to freetype in January and will form the next release
(2.4.12).
--
On Sat, Mar 30, 2013 18:54 GMT Simon Urbanek wrote:
On Mar 30, 2013, at 9:24 AM, Hin-Tak Leung wrote:
Perhaps that's too much details. There is (will be) a new freetype because
--- On Sat, 16/3/13, Hin-Tak Leung ht...@users.sourceforge.net wrote:
Network access is *not* a given, nor
is the privilege of installing arbitrary uncertified and
non-essential tools - whatever the meaning of
uncertified and non-essential are, those being defined,
as is design goal, etc
--- On Sat, 16/3/13, peter dalgaard pda...@gmail.com wrote:
On Mar 16, 2013, at 02:50 , Hin-Tak Leung wrote:
I'll quantify the first part - R is perhaps the only
public software project hosted on a subversion repository
for which the result of 'svn export ...' does not build. Not
only
The decision to actively discourage non-subsersion usage of snapshot build is
already made (r62183). So I am just here to register a differing opinion.
- it is not about subversion vs other-version-control-tools. There are two
parts of R's dev build process which requires an active network
in that direction.
--- On Fri, 15/3/13, Hin-Tak Leung hintak_le...@yahoo.co.uk wrote:
The decision to actively discourage
non-subsersion usage of snapshot build is already made
(r62183). So I am just here to register a differing
opinion.
- it is not about subversion vs other-version-control
|| R.version$`svn rev` 57849)
+if(getRversion() 2.15.0)
export(.M.classEnv)
## substitute for using cbind() / rbind()
--- On Fri, 15/2/13, Hin-Tak Leung ht...@users.sourceforge.net wrote:
FWIW, extracting snapshot source
elsewhere outside svn, run tools/rsync-recommended then
just
Somebody else had written separately about this before, and so have I a couple
of months ago. I assumed this will be fixed before the next R. Since R 3.0 is
supposedly only 6 weeks away, even if it is fixed now it doesn't leave much
room for testing.
Anyway neither Matrix 1.0-11 (current)
--- On Fri, 15/2/13, Simon Urbanek simon.urba...@r-project.org wrote:
On Feb 15, 2013, at 9:11 AM, Hin-Tak
Leung wrote:
Somebody else had written separately about this before,
and so have I a couple of months ago. I assumed this will be
fixed before the next R. Since R 3.0 is supposedly
for me there.
I don't know why it is degenerating into another distraction about some
people's egos.
--- On Fri, 15/2/13, Simon Urbanek simon.urba...@r-project.org wrote:
On Feb 15, 2013, at 11:36 AM, Hin-Tak
Leung wrote:
--- On Fri, 15/2/13, Simon Urbanek simon.urba...@r-project.org
wrote
--- On Fri, 15/2/13, Simon Urbanek simon.urba...@r-project.org wrote:
On Feb 15, 2013, at 1:55 PM, Hin-Tak Leung wrote:
Look. I don't see this as my problem - as far as I am
concerned, I have donated my time - and over and over - to
testing pre-released code. I am not using pre-released
FWIW, extracting snapshot source elsewhere outside svn, run
tools/rsync-recommended then just plain ./configure make doesn't work
either. Nothing to do with building inside checkout nor extra configure options.
This is fedora 18, x86_64.
--- On Fri, 15/2/13, Hin-Tak Leung ht
Affecting cairo 1.11.2+ and most versions of freetype.
https://bugzilla.redhat.com/show_bug.cgi?id=891457
The initial problem was seen with R Sweave, but eventually traced back to cairo
then onto freetype (comment 10, 13 and comment 33).
Leading up to the whole thing was a new vignette I was
--- On Fri, 14/12/12, Uwe Ligges lig...@statistik.tu-dortmund.de wrote:
On 14.12.2012 04:15, Hin-Tak Leung wrote:
--- On Sun, 9/12/12, Dirk Eddelbuettel e...@debian.org
wrote:
snipped
Do you REALLY think svn would not know about
missing
files? There does not
seem to be a limit
--- On Sun, 9/12/12, Dirk Eddelbuettel e...@debian.org wrote:
snipped
Do you REALLY think svn would not know about missing
files? There does not
seem to be a limit on the disdain for svn among git users.
Fascinating.
FWIW, as one of the linux kernel maintainers, I don't apologize for being
--- On Mon, 10/12/12, Martin Maechler maech...@stat.math.ethz.ch wrote:
--- On Sun, 9/12/12, Dirk
Eddelbuettel e...@debian.org
wrote:
On 9 December 2012 at 18:17, Hin-Tak Leung wrote:
| Noticed a problem for a while - tests/testit.Rd,
tests/ver20.Rd are removed on make clean
--- On Mon, 10/12/12, Martin Maechler maech...@stat.math.ethz.ch wrote:
Hin-Tak Leung
ht...@users.sourceforge.net
on Mon, 10 Dec
2012 09:23:14 + writes:
--- On Mon, 10/12/12, Martin Maechler
maech...@stat.math.ethz.ch
wrote:
[.]
That said ..a small bug
Noticed a problem for a while - tests/testit.Rd, tests/ver20.Rd are removed on
make clean unintentionally.
This seems to come from a change in tests/Makefile.in, which adds the line:
-@rm -f *.tar.gz *.Rd back in May 2012.
---
commit c4d70254e7b7f9d7ed17faecfb3097195d852ddc
Author:
--- On Sun, 9/12/12, Dirk Eddelbuettel e...@debian.org wrote:
On 9 December 2012 at 18:17, Hin-Tak Leung wrote:
| Noticed a problem for a while - tests/testit.Rd,
tests/ver20.Rd are removed on make clean unintentionally.
|
| This seems to come from a change in tests/Makefile.in,
which adds
Hi,
src/unix/Rscript.c on R trunk stopped building with a compiler error of
unknown not defined/declared on line 160-ish, where R_SVN_REVISION is , on my
system.
I see trunk r60972, trunk r60975 changes R_SVN_REVISION to a number - if it can
be found, from being a string.
The thing is, I
--- On Thu, 21/6/12, Hin-Tak Leung ht...@users.sourceforge.net wrote:
Hi,
Since upgraded to R 2.15, I have a problem with duplicate S4
class name no longer works (the reason for having duplicate
S4 class names is just software forks - they are largely
identical but don't have
Hi,
Since upgraded to R 2.15, I have a problem with duplicate S4 class name no
longer works (the reason for having duplicate S4 class names is just software
forks - they are largely identical but don't have an inheritence relationship,
and will never have such).
This is happening with
.
Original Message
Subject: Mac OS X builds of CelQuantileNorm, vcftools/samtools/tabix, and
snpStats
Date: Wed, 14 Mar 2012 02:59:42 + (GMT)
From: Hin-Tak Leung ht...@users.sourceforge.net
Reply-To: ht...@users.sourceforge.net
To: bonsai list outmodedbonsai-annou...@lists.sourceforge.net
Just a couple of small bug-lets/stuffs in Sweave:
- It stripes off the two lines starting with @ (this is a verbatim section
showing plink's start-up message):
===
@--@
| PLINK! |
Hi,
just saw require vignettes to declare their encoding (trunk@57560). Having
played with non-ascii vignettes (well, a lot of Chinese...) on-and-off for
almost two weeks, I noticed it was a bit odd that a *commented*
\usepackage[utf8]{inputenc} had any effort at all on R's Sweave behavior -
FWIW, this is the final outcome: Chinese, Tibetan, Arabic, Liangshan Yi
(basically Chinese + 3 other languages used in Nw and Sw china). Arabic is
interesting, it using a right-to-left layout - and it works in R graphics.
without declaring noae, so that's my preferred choice
at the moment, although I have got both of them working, for doing Chinese in a
LaTeX document.
I think some of these information should go into the man page of cairo_pdf()...
--- On Fri, 28/10/11, Hin-Tak Leung hintak_le...@yahoo.co.uk wrote
--- On Mon, 31/10/11, Simon Urbanek simon.urba...@r-project.org wrote:
On Oct 31, 2011, at 5:56 PM, Hin-Tak Leung wrote:
I am still doing some cosmetic things (adding
annotations with some of the really minority languages in
Sichuan), but here are a few misc tips and quirks so far
--- On Mon, 31/10/11, Simon Urbanek simon.urba...@r-project.org wrote:
Well, I don't see how most of the above is in any way
relevant. What PDF gets generated really depends on the
cairo version you are using, not on R. Only most recent
versions of Cairo (1.10.x) switched the format to
Chinese, I am doing Tibetan and Arabic as well - needed/wanted
those two for Sichuan (south-western China) and Ningxia (northern western, just
south of Mongolia).
--- On Sun, 23/10/11, Hin-Tak Leung ht...@users.sourceforge.net wrote:
--- On Sat, 22/10/11, Prof Brian
Ripley rip...@stats.ox.ac.uk
--- On Sat, 22/10/11, Prof Brian Ripley rip...@stats.ox.ac.uk wrote:
On Sat, 22 Oct 2011, Duncan Murdoch
wrote:
On 11-10-21 8:57 PM, Hin-Tak Leung wrote:
I have had some fun in the last few days trying to
put together an annotated map of China with R and some
public GIS data:
http
I have had some fun in the last few days trying to put together an annotated
map of China with R and some public GIS data:
http://sourceforge.net/projects/outmodedbonsai/files/snpMatrix%20next/1.17.7.11/China_Choropleth_Maps.pdf/download
It is done, and rather nice... there are a few issues:
-
and due in less than 10 days..), but harmless enough to go into
trunk and 2.14.1?
--- On Sat, 22/10/11, Hin-Tak Leung ht...@users.sourceforge.net wrote:
I have had some fun in the last few
days trying to put together an annotated map of China with R
and some public GIS data:
http
--- On Sat, 15/10/11, Hin-Tak Leung ht...@users.sourceforge.net wrote:
Found the simpliest way of seeing I
bug I encountered doing R CMD check --use-gct: Just launch
R (with --vanilla), and do this:
?gctorture
# this work
gctorture()
?gctorture
Error in gzfile(file, rb) :
can
-Tak Leung wrote:
Found the simpliest way of seeing I bug I encountered
doing R CMD check --use-gct: Just launch R (with
--vanilla), and do this:
?gctorture
# this work
gctorture()
?gctorture
Error in gzfile(file, rb) :
can only weakly reference/finalize reference
objects
These are small enough problems with R devel branch yesterday I thought I'll
just post here and hope somebody will fix them soon (or may have already been
fixed today), rather than filing at the bugzilla.
- R CMD check --use-valgrind --use-gct mypackage gives:
--
This is somewhat a summary/continuation of an R bug report:
(https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=14645)
Illumina's cluster definition files (*.egt) are one of the proprietary and
undocumented file formats used by their GenomeStudio line of products for
genomic studies.
snpMatrix
at that
point.
luke
On Fri, 8 Apr 2011, Hin-Tak Leung wrote:
--- On Fri, 8/4/11, peter dalgaard pda...@gmail.com
wrote:
On Apr 7, 2011, at 23:57 , Hin-Tak Leung
wrote:
Oh, I am tracking both R and Matrix
via git-svn and
retrieves all revisions to all branches daily
--- On Fri, 8/4/11, peter dalgaard pda...@gmail.com wrote:
On Apr 7, 2011, at 23:57 , Hin-Tak Leung wrote:
Oh, I am tracking both R and Matrix via git-svn and
retrieves all revisions to all branches daily (or at least,
regularly). I.e. R svn head. 2.13.0 only forked off
recently
Douglas Bates wrote:
I isolated the problem and tested then committed a fix. I am going to
ask Martin to upload the new release as I have gotten out of sync with
some of his recent changes and he will, I hope, reconcile the branches
and trunk. If you need the fixed version immediately, say for
Martin Maechler wrote:
Martin Maechler maech...@stat.math.ethz.ch
on Thu, 7 Apr 2011 12:24:32 +0200 writes:
HL == Hin-Tak Leung ht...@users.sourceforge.net
on Thu, 7 Apr 2011 07:51:44 +0100 writes:
HL Douglas Bates wrote:
I isolated the problem and tested then committed
--- On Thu, 7/4/11, Martin Maechler maech...@stat.math.ethz.ch wrote:
??? But the prerelease version of R-2.13.0
*contains* already
Matrix_0.999375-49 the one you claim has the bug.
[[and you still haven't told use the exact R version you
were using]]
Oh, I am tracking both R and
Hin-Tak Leung wrote:
Martin Maechler wrote:
Martin Maechler maech...@stat.math.ethz.ch
on Thu, 7 Apr 2011 12:24:32 +0200 writes:
HL == Hin-Tak Leung ht...@users.sourceforge.net
on Thu, 7 Apr 2011 07:51:44 +0100 writes:
HL Douglas Bates wrote:
I isolated the problem
I have somehow managed to made a source tar ball which R CMD check accepts
but R CMD INSTALL rejects with:
--
Warning in untar2(tarfile, files, list, exdir) :
checksum error for entry 'pax_global_header'
Error in untar2(tarfile, files, list, exdir) : unsupported entry type ‘g’
repost from the subscribed address...
--- On Fri, 1/4/11, Hin-Tak Leung ht...@users.sourceforge.net wrote:
--- On Wed, 30/3/11, Douglas Bates
ba...@stat.wisc.edu
wrote:
I isolated the problem and tested then committed a
fix. I
am going to
ask Martin to upload the new release as I
, 2011, at 10:19 AM, Hin-Tak Leung wrote:
I have somehow managed to made a source tar ball which
R CMD check accepts but R CMD INSTALL rejects with:
--
Warning in untar2(tarfile, files, list, exdir) :
checksum error for entry 'pax_global_header'
Error in untar2(tarfile
compilation flag
-DTESTING_WRITE_BARRIER? I think that run-time error message can only
be thrown under those circumstances (not that it isn't an error, it's
just not checked for in other circumstances).
On Sat, Mar 26, 2011 at 5:21 PM, Hin-Tak Leung hintak_le...@yahoo.co.uk
Current core/Recommended Matrix package (0.999375-48) has been segfaulting
against R 2.13-alpha/2.14-trunk for the last week or so (since R-2.13 was
branched, when I started trying) when run with R CMD check --use-gct:
--
pkgname - Matrix
source(file.path(R.home(share), R,
--- On Tue, 8/2/11, luke-tier...@uiowa.edu luke-tier...@uiowa.edu wrote:
From: luke-tier...@uiowa.edu luke-tier...@uiowa.edu
Subject: Re: [Rd] bug in codetools/R CMD check?
To: Hin-Tak Leung ht...@users.sourceforge.net
Cc: david.clay...@cimr.cam.ac.uk, r-devel@r-project.org
Date: Tuesday, 8
--- On Tue, 8/2/11, Prof Brian Ripley rip...@stats.ox.ac.uk wrote:
From: Prof Brian Ripley rip...@stats.ox.ac.uk
Subject: Re: [Rd] bug in codetools/R CMD check?
To: Hin-Tak Leung ht...@users.sourceforge.net
Cc: luke-tier...@uiowa.edu, david.clay...@cimr.cam.ac.uk,
r-devel@r-project.org
not be used
tdt.snp: local variable ‘nr.snps’ assigned but may not be used
-
which is more like expected check warnings.
Care to comment?
Hin-Tak Leung
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--- On Thu, 3/9/09, Vinh Nguyen vinhdi...@gmail.com wrote:
hi hin-tak,
i'm trying to build r packages for windows on a
mac/linux. i guess
this used to possible and supported, but is no longer
supported. i
ran into this post of yours,
--- On Thu, 3/9/09, Vinh Nguyen vinhdi...@gmail.com wrote:
hmmmtried building R-2.8.0 on my
mac, didn't work. i think it got
the very end before failing:
i386-mingw32-windres --preprocessor=i386-mingw32-gcc -E
-xc
-DRC_INVOKED -I
/Users/vinh/Downloads/Rwin/R-2.8.0/include -I
-i
--- On Thu, 30/7/09, Martin Maechler maech...@stat.math.ethz.ch wrote:
I'm not sure this addresses all the problems that your
patch
tried to fix,
but in any case, your patch re-installing the --vanilla
behavior
unconditionally (without the .libPaths()[1] detection) was
not
suffificient.
--- On Thu, 30/7/09, Martin Maechler maech...@stat.math.ethz.ch wrote:
HL == Hin-Tak
Leung hintak_le...@yahoo.co.uk
on Thu, 30 Jul
2009 08:59:01 + (GMT) writes:
HL --- On Thu, 30/7/09, Martin Maechler
maech...@stat.math.ethz.ch
wrote:
I'm not sure this addresses all
This is the change I suggested earlier - it should just disable more of
user/site customization during package installation/removal, and getting more
of R 2.8-like behavior back. Attached and inlined below.
Against svn r48897 (svn HEAD AFAIK).
--
--- On Fri, 17/7/09, Martin Maechler maech...@stat.math.ethz.ch wrote:
HL == Hin-Tak Leung ht...@users.sourceforge.net
on Mon, 6 Jul 2009 15:23:07 -0700 (PDT) writes:
HL I finally got round to look at a
little problem I have - most of the time when I use R I
would be using
--- On Fri, 17/7/09, Martin Maechler maech...@stat.math.ethz.ch wrote:
R 2.9.x uses R code instead of the previous perl code for
INSTALL. That's the explanation for the difference.
I agree that it would be quite useful if they supported features
as you mention, and we (R-core) will be
Hi,
(I am not longer on R-devel - please CC:)
Just when Fedora 11 is shipping a gcc 4.4 based cross-compiler - the last major
distro to ship a cross-compiler, but the first to ship a gcc 4.4- one.(both
Suse Debian has been so so for a while, and I expect Ubuntu as well), and the
mingw
I finally got round to look at a little problem I have - most of the time when
I use R I would be using snpMatrix (now part of bioconductor, I wrote a
substantial part of), so I had $HOME/.Rprofile to save some typing. Upgrading,
switching versions used to work fine with R 2.8 then it broke
That being documented behavior, I still find the documented behavior
somewhat inconvenient: the fact that some code I interactively tested
does not run in the same way in batch mode.
My own solution involves running a separate semi-permanent Xvfb process
and let R CMD BATCH uses the virtual X
Prof Brian Ripley wrote:
On Sat, 16 Feb 2008, Hin-Tak Leung wrote:
Hi,
Just for interest, may I ask which platform are you referring to?
You are on a commercial unix platform such as solaris, right?
amd64 Linux -- a bit of tracing shows that to be from a jpackage-d
version of the Sun
Hi,
Just for interest, may I ask which platform are you referring to?
You are on a commercial unix platform such as solaris, right?
Older JDK/JRE on unices uses motif as the the AWT peer implementation.
The motif toolkit libraries are always found on commercial unices, but
for the same reason,
Alessandra Iacobucci wrote:
On Feb 4, 2008, at 7:22 PM, Hin-Tak Leung wrote:
You will get yelled at by others for posting a question as a bug...
(sigh). See FAQ.
I am a non-member so my message should normally pass through a moderator.
Your understanding is again wrong - AFAIK, R-devel
You will get yelled at by others for posting a question as a bug...
(sigh). See FAQ.
That said, your understanding of the output of system.time() is wrong.
The value you are after is simply user+system. %CPU is essentially
user+system/elapsed. It is elapsed which is dependent on system
load, not
My first thought was that you must be using Xinerama or TwinView -
and you did mention Xinerama in your r-help message but not
in your bug report - this detail is important.
That said, I don't know enough about X11 to say anything - well, maybe
I do, but you'll have to show your xorg.conf , and
Prof Brian Ripley wrote:
On Mon, 28 Jan 2008, Hin-Tak Leung wrote:
Prof Brian Ripley wrote:
On Fri, 25 Jan 2008, Michael Braun wrote:
Thanks for everyone's help. Unfortunately, still no success. So I
took the alternate route suggested in section A.3.1.5 of R-admin,
and just created
Peter Dalgaard wrote:
[EMAIL PROTECTED] wrote:
In R version 2.6.1 (2007-11-26)
and R version 2.6.1 Patched (2008-01-19 r44061)
on openSUSE 10.2 (X86-64)
gctorture()
proc.time()
Error: protect(): protection stack overflow
The problem with this is that then
R CMD check
Hmm, you need to read R-exts throughoutly. There are tonnes of
information in there, and a few chapters devoted to the topics you are
after.
As for actual examples - the known GUIs - Rgnome on unix (which AFAIK is
no longer maintained but still useful as an example, I guess), Rgui on
windows,
I believe STRING_ELT() works even when pat is R_NilValue, so
the first line does the right thing even if the first element does not
exist. I think this is intentional and not a bug.
Other more knowledgeable people please correct me if I am wrong.
[EMAIL PROTECTED] wrote:
In character.c within
Rather off topic, while acrobat reader is Adobe and authoritative,
there are a lot of other 3rd-party pdf viewers around. xpdf
(http://www.foolabs.com/xpdf/download.html) provides text search
functionally and mostly just a single binary so it shouldn't require
sysadmin installation or assistance
You are missing some extern C declarations? R needs C linkage style.
Basically a lot of:
extern C {
}
around your c++ code.
Matt Calder wrote:
Hi,
I am having trouble with some code that I am dyn.loading. I am
writing an interface to ARPACK. I compile my interface (dssimp.cc), and
Hmm, I don't think you need a whole Makefile - while it is a
bit complicated to set locations, etc, essentially if your C code
needs an extra DLL (well, you'll have to bundle it with your package,
etc because the otherwise link-loader won't find it), it is mostly
just in Makevars.win
Simon Urbanek wrote:
snipped
If I were an Apple user (which I am not), there is a chance that I
might have my own gcc/gfortran in /usr/local and I surely do not want
R to temper with them. If you need runtime libgfortran support, you
should just bundle gfortran.so and gcc.so if necesary
Simon Urbanek wrote:
On Dec 19, 2007, at 12:49 PM, Hin-Tak Leung wrote:
Simon Urbanek wrote:
snipped
If I were an Apple user (which I am not), there is a chance that I
might have my own gcc/gfortran in /usr/local and I surely do not
want R to temper with them. If you need runtime
Simon Urbanek wrote:
snipped
Because it *is* the gcc files? (Note the /local in the paths.) Full R
comes with GNU Fortran 4.2.1, because Apple doesn't offer any Fortran
compiler and most other Fortran compiler binaries for Mac OS X out on
the web are not really working well. It installs in
Out of interest, why (the hell!) would the R installer trying to
temper with gcc's files? It looks like it is either trying to rename
or delete them.
R needs gfortran's runtime library, and tries to detect for its
presence, that's fair enough... modifying, no. Is the failure
because the R
1 - 100 of 253 matches
Mail list logo
