similar to: (PR#11281) Bug in R 2.7 for over long lines

>>>>> "BDR" == Prof Brian Ripley <ripley at stats.ox.ac.uk> >>>>> on Tue, 13 May 2008 07:32:43 +0100 (BST) writes: BDR> This example does not crash in R 2.7.0, R-patched nor BDR> R-devel (r45677) for me (x86_64 F8 Linux.) It also BDR> does not crash with the CRAN build of R 2.7.0 on BDR> Windows XP. Neither does it

You will see the current code is different, and your 'fix' is not needed nor applies in R-devel. You failed to provide an example to reproduce the alleged bug, but the issue does seem to be using lines beyond the documented line length. So it would have only affected people who did that .... And generating a new report (PR#11438) was distinctly unfriendly. If after studing the R FAQ

OK, I am just sending it here too as it looks like r-devel at r-project.org is not the right place: =EF=BB=BFOn Fri, 2008-04-25 at 08:48 +0200, Soeren Sonnenburg wrote: > While trying to fix swig & R2.7 I actually discovered that there is a > bug in R 2.7 causing a crash (so R & swig might actually work): >=20 > the bug is in ./src/main/gram.c line 3038: >=20 >

While trying to fix swig & R2.7 I actually discovered that there is a bug in R 2.7 causing a crash (so R & swig might actually work): the bug is in ./src/main/gram.c line 3038: } else { /* over-long line */ fixthis --> char *LongLine = (char *) malloc(nc); if(!LongLine) error(_("unable to allocate space for source line %d"),

On Sat, 2008-04-26 at 09:38 +0200, Peter Dalgaard wrote: > bugreports at nn7.de wrote: > > OK, I am just sending it here too as it looks like r-devel at r-project.org > > is not the right place: > > > I think it was seen there too, just that noone got around to reply. In > R-bugs, there's a filing system so that it won't be completely forgotten... Looks like

Dear all, I was trying to use the R swig wrapper with R 2.7 and shogun ( http://www.shogun-toolbox.org ) but it fails completely, as in doesn't even compile and even after patching then though compiling - crashes... So I asked on swig-users/swig-devel CC'ing the potential R maintainer but I never received a reply. I now wonder if anyone here could help or would be willing to maintain

Hi, From R 2.6, I would like to update to R2.7. I would like to have some tips on the recommended method of installing the latest versions of an entire list of packages in R2.7 - i.e. all the packages that I have presently installed in R2.6. I am hoping that there is an easier method than fetching the packages individually as I did, to begin with, for R2.6. Additionally, I would like to install

bugreports at nn7.de wrote: > OK, I am just sending it here too as it looks like r-devel at r-project.or= g > is not the right place: > =20 I think it was seen there too, just that noone got around to reply. In=20 R-bugs, there's a filing system so that it won't be completely forgotten.= =2E. However, your mail seems to have gotten encoded in quoted-printable, you = might want

On Mon, 2008-05-12 at 11:10 +0200, maechler at stat.math.ethz.ch wrote: > Hi Soeren, > >>>>> "SS" == Soeren Sonnenburg <bugreports at nn7.de> > >>>>> on Sat, 10 May 2008 05:32:14 +0000 writes: > > SS> On Sat, 2008-04-26 at 09:38 +0200, Peter Dalgaard wrote: > >> bugreports at nn7.de wrote: > OK, I am just

Small addition again: This error shows up in the log while removing snapshots WITHOUT rendering the Vms unresponsive — Jun 01 01:33:45 mc-dc3ham-compute-02-live.mc.mcon.net libvirtd[1657]: Timed out during operation: cannot acquire state change lock Jun 01 01:33:45 mc-dc3ham-compute-02-live.mc.mcon.net vdsm[6839]: vdsm vm.Vm ERROR vmId=`56848f4a-cd73-4eda-bf79-7eb80ae569a9`::Error getting block

Hello Soeren. I've started to look at this issue and I'd agree that at first glance it looks like a libvirt issue. The 'cannot acquire state change lock' messages suggest a locking bug or severe contention at least. To help me better understand the problem I have a few questions about your setup. >From your earlier report it appears that you have 15 VMs running on the

Hi, I would send those, but unfortunately we did not think about the journals getting deleted after a reboot. I just made the journals persistent on the servers, we are trying to trigger the error again last time we only got half way through the VM’s when removing the snapshots so we have a good chance that it comes up again. Also the libvirt logs to the journal not to libvirtd.log, i would

Hi Adam, Hi Eric, We had this issue again a few minutes ago. One machine went down exactly the same way as described, the machine had only one snapshot and it was the only snapshot that was removed, before that in the same scriptrun we deleted the snapshots of 15 other Vms, some without, some with 1 and some with several snapshots. Can i provide anything from the logs that helps ? Regards

Hello everybody, I've been using asterisk 1.2 for quite a long time now, but I thought it's time to try a newer version of asterisk. So I downloaded 1.8.5, extracted the tar, ran configure, make, make install ... Everything looks fine (no obvious compile/link errors). But as soon as I start asterisk, it dies with a segfault. I executed asterisk within strace and last action before the

all/any coerce their arguments to logical (if possible). I've added a warning in R-devel if coercion is from something other than integer. This arose because it is easy to make a slip and write all(X) > 0 rather than all(X > 0): thanks to Bill Dunlap for bringing that to my attention. However, it has been useful in detecting quite a few other things: - indices which had been made

These are some points stimulated by reading about C history (and related in their implementation). 1) On some platforms > as.integer("0xA") [1] 10 but not all (not on Solaris nor Windows). We do not define what is allowed, and rely on the OS's implementation of strtod (yes, not strtol). It seems that glibc does allow hex: C99 mandates it but C89 seems not to allow it. I

We say in ?points that 'pch' (among others) can be set to NA for omitting a point. While this works in cases where there's at least one point left to draw, it fails in a simple case like this : > plot(1, pch = NA) Error in plot.xy(xy.coords(x, y), type = type, pch = pch, col = col, bg = bg, : invalid plotting symbol Both in R-patched or R-devel. A simple workaround {hinting

This only happens if 'file' is a text connection, and is the expected behaviour in that case: you cannot capture an incomplete line to a text connection. There seems no reason to break the documented behaviour in other cases to change something that you consider to a bug when file=NULL and the user does not produce complete output. It would be possible to make use of isIncomplete()

R 1.4.0 ?stars has scale: logical flag: if `TRUE', the columns of the data matrix are scaled independently so that the maximum value in each column is 1 and the minimum is 0. If `FALSE', the presumption is that the data have been scaled by some other algorithm to the range [0,1]. but the code has if (scale) { x <- sweep(x, 2,

Version: platform = sparc-sun-solaris2.6 arch = sparc os = solaris2.6 system = sparc, solaris2.6 status = status.rev = 0 major = 0 minor = 64.2 year = 1999 month = July day = 3 language = R -- It is unclear to me that the handling of NAs is desirable, and it has problems with names: > z <- c(T,T,NA,F,T) > names(z) <- letters[1:5] > which(z) Error: names attribute