--
On Mon, 2/20/17, Martin Maechler wrote:
Subject: Re: [Rd] another fix for R crashes under enable-strict-barrier, lto,
trunk@72156
To: "Hin-Tak Leung"
Cc: r-devel@r-project.org, "bonsai list"
Date: Monday, February 20, 2017, 9:56 AM
>>>>>
Hi
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 b
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 o
--
On Sat, May 16, 2015 2:33 PM BST Marc Schwartz wrote:
>
>> On May 16, 2015, at 6:11 AM, Hin-Tak Leung
>> wrote:
>>
>>
>>
>> --
>> On Sat, May 16, 2015 8:04 AM BST Uwe Ligges wrote:
>&
nd that's 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 recom
'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 mon
are still for
R 2.x.
----
On Wed, 21/1/15, Hin-Tak Leung 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.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 binaries'
fix 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
> wrote:
>>
>> The r.dll crash is easy - you need to be using gcc-ar for ar, and gcc-
-fopenmp -L.
>> -lgfortran -lRblas -L../../bin/x64 -lRzlib -lRgraphapp -lRiconv
>> -lcomctl32 -lversion
>> collect2.exe: error: ld returned 5 exit status
>> Makefile:150: recipe for target 'R.dll' failed
>> make[3]: *** [R.dll] Error 1
>> Makefile:179: re
nux, that covers all the major platforms. For
10% speed
gain, I'll let somebody else worry about machines that are not MS windows, not
mac OS X
nor linux.
------------
On Mon, 15/12/14, Hin-Tak Leung wrote:
R fails to build with visibility on
and gcc 4.9&#
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 a
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
cl
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 wrote:
Subject: Looking
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:
===
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,
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 th
--
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
FUN = summary, maxsum = maxsum, digits = 12,
...)
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.
utine 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 &q
with a system font, fontconfig
has problem 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:
F
has 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
--- On Mon, 1/4/13, Hin-Tak Leung wrote:
> --- On Sat, 30/3/13, Hin-Tak Leung
>
> wrote:
>
> > "... was committed to freetype in January and will form
> the
> > next release (2.4.12)".
>
> It is perhaps worth repeating the quote: 'The of
--- On Sat, 30/3/13, Hin-Tak Leung 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 ... a
"... 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
te:
> 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.
>
>
The problem was first seen with R/Sweave (#c0) then reproduced directly with
cairo (#c10) and was eventually traced to freetype. The 5-part bug fix:
610ee58e07090ead529849b2a454bb6c503b4995
da11e5e7647b668dee46fd0418ea5ecbc33ae3b2
e1a2ac1900f2f16ec48fb4840a6b7965a8373c2b
869fb8c49ddf292d6daf482617
--- On Sat, 16/3/13, Hin-Tak Leung 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 bein
mall committee.
It is a very common scenario, e.g. banks & telecom, some part of
public/government service and health care. This does not seem to sink in
without repeating.
--- On Sat, 16/3/13, Hin-Tak Leung wrote:
> I'll quantify the first part - R is
> perhaps the only public s
--- On Sat, 16/3/13, peter dalgaard 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 n
ly try to go in that direction.
--- On Fri, 15/3/13, Hin-Tak Leung 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-v
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 conne
"writeMM"
)
-if(getRversion() < "2.15.0" || 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 wrote:
> FWIW, extracting s
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 F
--- On Fri, 15/2/13, Simon Urbanek 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 p
n't upgrade. No loss 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 wrote:
> On Feb 15, 2013, at 11:36 AM, Hin-Tak
> Leung wrote:
>
> > --- On Fri, 15/2/13, Simon Urbanek
&
--- On Fri, 15/2/13, Simon Urbanek 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 supposedl
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) nor
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 writ
--- On Fri, 14/12/12, Uwe Ligges wrote:
> On 14.12.2012 04:15, Hin-Tak Leung wrote:
> > --- On Sun, 9/12/12, Dirk Eddelbuettel
> wrote:
> >
> >
> >> Do you REALLY think svn would not know about
> missing
> >> files? There does not
> >&g
--- On Sun, 9/12/12, Dirk Eddelbuettel wrote:
> 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
familiar with git.
--- On Mon, 10/12/12, Martin Maechler wrote:
> >>>>> Hin-Tak Leung
>
> >>>>> on Mon, 10 Dec
> 2012 09:23:14 + writes:
>
> > --- On Mon, 10/12/12, Martin Maechler
>
> wrote:
> [.]
>
>
--- On Mon, 10/12/12, Martin Maechler wrote:
> > --- On Sun, 9/12/12, Dirk
> Eddelbuettel
> 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 Sun, 9/12/12, Dirk Eddelbuettel 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/Make
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:
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 tr
--- On Thu, 21/6/12, Hin-Tak Leung 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 an inheri
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 "librar
some.
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
Reply-To: ht...@users.sourceforge.net
To: bonsai list
CelQantileNorm, vcftools/samtools/tabix are bult for Mac OS X. Thes
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! |v0.99p
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.
http://sourceforge.net/projects/outmodedbonsai/files/snpMatrix%20next/1.19
--- On Mon, 31/10/11, Simon Urbanek 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 PDF-1.5
> and added format res
--- On Mon, 31/10/11, Simon Urbanek 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:
&g
r Lemberg's CJK (the
LaTeX package) can work 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()...
---
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 wrote:
> --- On Sat, 22/10/11, Prof Brian
> Ripley
> wrote:
>
> > On Sat, 22 Oct 2011, Dunc
--- On Sat, 22/10/11, Prof Brian Ripley 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
> pu
included in R 2.14 (already in
code freeze 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 wrote:
> I have had some fun in the last few
> days trying to put together an annotated map of China with R
> and som
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:
-
--- On Sat, 15/10/11, Simon Urbanek wrote:
> Thanks, now fixed. It affected almost
> all connections.
> Simon
Many thanks. Hopefully having gctorture() working would help - am having heap
corruption problems and valgrind aborts :-).
> On Oct 15, 2011, at 2:32 PM, Hin-Tak
--- On Sat, 15/10/11, Hin-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
> Erro
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
# this does not
It seems th
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 " gives:
--
Error in g
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
a breakpoint in memory.c:CHK on the
> line that signals
> > the error gives a stack trace of the C calls involved,
> and in this
> > case the culprit was pretty easy to find at that
> point.
> >
> > luke
> >
> > On Fri, 8 Apr 2011, Hin-Tak Leung wrote:
&
--- On Fri, 8/4/11, peter dalgaard 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 of
Hin-Tak Leung wrote:
Martin Maechler wrote:
Martin Maechler
on Thu, 7 Apr 2011 12:24:32 +0200 writes:
"HL" == Hin-Tak Leung
on Thu, 7 Apr 2011 07:51:44 +0100 writes:
HL> Douglas Bates wrote:
>>> I isolated the problem and tested then committed a fix.
--- On Thu, 7/4/11, Martin Maechler 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 Matrix via git-svn and re
Martin Maechler wrote:
Martin Maechler
on Thu, 7 Apr 2011 12:24:32 +0200 writes:
"HL" == Hin-Tak Leung
on Thu, 7 Apr 2011 07:51:44 +0100 writes:
HL> Douglas Bates wrote:
>>> I isolated the problem and tested then committed a fix. I am
>>>
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
t
pax in several places. So git-archive's
documentation (and its '--format=tar' option) is misleading; although even GNU
fileutils says the ungzip'ed bundle is "posix tar". Go figure...
OTOH, "R CMD check" extracts the content (and does an install) and &#x
rious things) works and R CMD INSTALL itself
does not.
OTOH, should this be reported to the GIT people?
>
>
> On Apr 1, 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 &qu
repost from the subscribed address...
--- On Fri, 1/4/11, Hin-Tak Leung wrote:
> --- On Wed, 30/3/11, 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 h
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 ‘
R with
> --enable-strict-barrier or set the C 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).
&
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, Prof Brian Ripley wrote:
> From: Prof Brian Ripley
> Subject: Re: [Rd] bug in codetools/R CMD check?
> To: "Hin-Tak Leung"
> Cc: luke-tier...@uiowa.edu, david.clay...@cimr.cam.ac.uk,
> r-devel@r-project.org
> Date: Tuesday, 8 February, 2011, 17:
--- On Tue, 8/2/11, luke-tier...@uiowa.edu wrote:
> From: luke-tier...@uiowa.edu
> Subject: Re: [Rd] bug in codetools/R CMD check?
> To: "Hin-Tak Leung"
> Cc: david.clay...@cimr.cam.ac.uk, r-devel@r-project.org
> Date: Tuesday, 8 February, 2011, 15:34
> Thank
nish’ assigned but may not be used
read.HapMap.data: local variable ‘strand’ assigned but may not be used
tdt.snp: local variable ‘nc.snps’ assigned but may not be used
tdt.snp: local variable ‘nr.snps’ assigned but may not be used
-
which is more like expected check warnings.
Care to
--- On Thu, 3/9/09, Vinh Nguyen 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
> methods_res
--- On Thu, 3/9/09, Vinh Nguyen 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,
> https://stat.ethz.ch/pipermail/r-devel/2009-July/053971.html,
>
--- On Thu, 30/7/09, Martin Maechler wrote:
> >>>>> "HL" == Hin-Tak
> Leung
> >>>>> on Thu, 30 Jul
> 2009 08:59:01 + (GMT) writes:
>
> HL> --- On Thu, 30/7/09, Martin Maechler
>
> wrote:
> >
--- On Thu, 30/7/09, Martin Maechler 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.
But I think .libPa
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 wrote:
> >>>>> "HL" == Hin-Tak Leung
> >>>>> 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
--- On Fri, 17/7/09, Martin Maechler 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 very willing to accept
>
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 wit
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 peopl
snpMatrix (http://bioconductor.org/packages/2.2/bioc/html/snpMatrix.html)
is now part of Bioconductor. I use the mingw cross compiler to make the
window releases so I made the effort to build the cross-compiler as an
rpm for x86_64 fedora 8/9. It might be also useful to other R-developers,
or some
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 serv
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 tha
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, no
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 understan
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 po
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
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 a symbolic link from libRblas.so to
>> .../libmkl_gf_lp64.so. I
Peter Dalgaard wrote:
> CapCity wrote:
>> We recently developed an R program as part of an application. We'd like to
>> distribute this, but not allow access to the R source code. Is this
>> possible?
>>
>>
> Not in any obvious way, and I don't think anyone around here would
> volunteer to help
This part "-lmkl_gf_lp64.so -lmkl_gnu_thread.so -lmkl_core.so"
looks wrong - it should be "-lmkl_gf_lp64 -lmkl_gnu_thread -lmkl_core"
without the ".so" part.
I don't know how BLAS_LIBS does it, but when I was linking against
mkl 9, all I did which different from the usual build (diff from the
two
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 th
1 - 100 of 310 matches
Mail list logo
