similar to: Antwort: Re: Crash with Unicode and sub (PR#14114)

Full_Name: George Russell Version: 2.10.0 OS: Windows XP Version 2002 SP 2 Submission from: (NULL) (217.111.3.131) The following typed into R --vanilla induces a crash: -- cut here -- gctorture() u <- intToUtf8(c(rep(1e3,1e2),32,c(rep(1e3,1e2)))) v <- rep(u,1e2) v <- sub(" ","",v) v %in% "" -- cut here -- sessionInfo() says: -- cut here -- R version

Dear Professor Ripley, a. I apologise for not including the file. I sent the E-Mail to=20 R-bugs at r-project.org with an attachment, but the attachment evidently got=20 lost. However the text of the file is as follows: --- CUT HERE ---- gctorture() characters <- intToUtf8(200:300) indices <- rep(sequence(5),10) substrings <- substring(characters,indices,indices + 5) factor(substrings)

Full_Name: George Russell Version: 2.10.0 OS: Windows XP Professional Version 2002 Service Pack 2 Submission from: (NULL) (217.111.3.131) Typing the following command into R --vanilla causes R to crash: k <- intToUtf8(rep(1e3,1e7)) This is the output of sessionInfo(): R version 2.10.0 (2009-10-26) i386-pc-mingw32 locale: [1] LC_COLLATE=German_Germany.1252 LC_CTYPE=German_Germany.1252

The new version of R-devel from yesterday morning seems to have fixed bug=20 14114! Thanks a lot for your help. Duncan Murdoch <murdoch at stats.uwo.ca> schrieb am 14.12.2009 13:34:35: > On 10/12/2009 4:20 AM, karl at huftis.org wrote: > > Full=5FName: Karl Ove Hufthammer > > Version: 2.10.0 > > OS: Windows XP > > Submission from: (NULL) (93.124.134.66) >

Hi there, any explanation for this? > intToUtf8(66) Error in intToUtf8(66) : argument 'x' must be an integer vector > intToUtf8(c(66,55)) Error in intToUtf8(c(66, 55)) : argument 'x' must be an integer vector > intToUtf8(c(66,55),multiple=TRUE) Error in intToUtf8(c(66, 55)) : argument 'x' must be an integer vector Errr... 66 and c(66,55) are as integer vectorish

Hello, at the moment I am doing quite a lot of regression, especially logistic regression, on 20000 or more records with 30 or more factors, using the "step" function to search for the model with the smallest AIC. This takes a lot of time on this 1.8 GHZ Pentium box. Memory does not seem to be such a big problem; not much swapping is going on and CPU usage is at or close to

Full_Name: George Russell Version: 2.10.0, 2.11.0 (2009-12-13 r50716) OS: Windows Submission from: (NULL) (217.111.3.131) R trace: -- cut here -- > v <- integer(0) > v[[1]] <- v > v [1] 20522144 > v <- numeric(0) > v[[1]] <- v > v [1] 4.254131e-314 > sessionInfo() R version 2.10.0 (2009-10-26) i386-pc-mingw32 locale: [1] LC_COLLATE=German_Germany.1252

Full_Name: George Russell Version: 2.10.0 and 2.11.0 Under development (unstable) (2010-02-08 r51108) OS: Windows Submission from: (NULL) (217.111.3.131) > c("a","b")[[c(TRUE,FALSE)]] Error in `[[.default`(factor(c("a", "b")), c(TRUE, FALSE)) : recursive indexing failed at level 1 I find this error message confusing, though after reading the HELP

Hi all, I have a problem with smbclient from the samba-client-3.0.14a-2 package supplied with Fedora Core 2. It hangs when listing any directory with over 36 items in it on one particular Windows XP Professional box I'm trying to back up. If I run smbclient -d 3, I get the following output over and over when listing the directory: received 36 entries (eos=0) received 36 entries (eos=0)

I was wondering why my CD ripping was producing short files from some tracks. A superficial examination of the code shows this piece of code in vorbis-tools/oggenc/encode.c: Line 120: /* Main encode loop - continue until end of file */ while(!eos) { [...] /* While we can get enough data from the library to analyse, one

Hi, I'm working on a new ogg file chopper (porting 'hogg chop' to C). These work pagewise, ie. they just copy the pages that are needed from the input to the output bitstream. I'm modifying the last page in the output bitstream so that it has the eos flag set. The last page is always one that has a granulepos set (that of the last packet finishing on that page). But let's say

On 25-Feb-08, at 3:42 PM, Conrad Parker wrote: > ok. If the correct behaviour should be to ignore the incomplete > packet, that should also be clarified in the spec. Fair enough. What if no packet ends on the eos page? What about additional pages after the eos page? > I'd find it useful if it was not considered a structural error, as it > allows us to very simply chop files

On 25-Feb-08, at 9:34 AM, xiphmont@xiph.org wrote: > I'd say both; libogg should ignore the incomplete packet or flag a > structural error, and the spec should be clarified. I guess libogg should return -1 if you try to ogg_stream_packetout() after the eos packet. The eos flag pretty clearly applies to the *page* not the packet, so I think how that gets translated into the

On 26/02/2008, Silvia Pfeiffer <silviapfeiffer1@gmail.com> wrote: > > Hmm, good point. Maybe it requires a MUST specification... But then, it > would not be conformant to have a partial packet on the last page.... I'd definitely prefer that the recommendation to not have an incomplete packet on a page marked eos is a SHOULD not a MUST, so that eos pages don't need to be

Full_Name: Johnny Accot Version: 1.5.1 OS: Linux Submission from: (NULL) (198.4.83.52) Hi. I'm having a problem with the binary read/write functions. I'm writing a device driver in R (why not?) and of course I have to send a couple commands to the device. Typically, I send one byte, receive one acknowledgement byte, send another byte, receive an ACK, and so on. At least this is what

On 2008-11-13, Conrad Parker <conrad at metadecks.org> wrote: > I'm wondering if the Dirac granulepos parsing in liboggz and display > in the oggz tools is currently correct, as I'd like to do a release of > these soon. I believe it is -- although if correct support in the rest of the liboggz tools is required, a little more work may need to happen. > Here's some

I have a technical question about the vorbis granule position, but I would like to put the question into context. When a ogg vorbis stream is ripped using wget, fetch, or streamripper under Linux or FreeBSD, the resulting file has problems both with granule position and with a missing EOS. I think I can figure out how to add an EOS, but is there a way to determine the granule position in a stream

Hello, *Background:* The RFC 5574 suggests the RTP payload format for the speex codec. The payload formation is straight forward; the encoded frames are to be concatenated one after another. Once we have appended desired number of frames, we have to pad the stream with 01111 sort of sequence to ensure that payload ends on a octet boundary. *Observation:* I am using the speex encoder at 2150 Kbps

I have recently been using writeChar and writeBin to write binary files. These functions makes it very easy to write OS-independent files, which I am very happy with. I have however found a few issues, best illustrated by a short example > con <- file("test", open = "wb") > writeChar(as.character(c("ab", "ab")), nchars = c(3), con = con,

2008/11/14 David Flynn <davidf+nntp at woaf.net>: > On 2008-11-13, Conrad Parker <conrad at metadecks.org> wrote: >> I'm wondering if the Dirac granulepos parsing in liboggz and display >> in the oggz tools is currently correct, as I'd like to do a release of >> these soon. > > I believe it is -- although if correct support in the rest of the >