similar to: Seek() on windows - safe use cases?

Hi, Is there any way to load workspaces (e.g. stuff from save.image) from the command line? I'm on Linux, and would find this very helpful. I'm guessing this functionality can be duplicated with a skillful bash script to rename the particular file to .RData (and then back once R terminates), but I'm wondering if there's a better way. Zhou Fang

Hi, on WinXP Pro SP2 with NTFS, I noticed that file.info() under Rv2.2.1pat (2006-02-09) does not report the correct file size if the file is >= 2^31 bytes (2GB). Is this problem known? Is this related to the note in ?file.info: "Some (broken) systems allow files of more than 2Gb to be created but not accessed by the 'stat' system call. Such files will show up as non-readable

Hi all, Basically, I have data in the format of (up to 1 gig in size) text files containing stuff like: F34060F81000F28055F8A000F2E05EF8F000F34 (...) The data is basically strings denoting hex values (9 = 9, A = 10, B = 11, ...) organised in fixed, small blocks. What I want to do is to read in a specified segment of the string, break it up into blocks, and convert it into a vector of integers

Dear all, In R-devel (2011-09-23 r57050), I'm running into a serious problem with seek()ing on connections opened with gzfile(). A warning is generated and the file position does not seek to the requested location. It doesn't seem to occur all the time - I tried to create a small example file to illustrate it, but the problem didn't occur. However, it can be seen with a file I use for

Hi, Okay, I have a n x p matrix X, which I know is not full rank. In particular, there may be linear dependencies amongst the columns (but not that many). What is a fast way of finding a linearly independent subset of the columns of X that will span the column space of X, in R? If it helps, I have the QR decomposition of the original X 'for free'. I know that it's possible to do this

Okay, someone explain this behaviour to me: Browse[1]> replace(rep(0, 4000), temp1[12] , temp2[12])[3925] [1] 0.4462404 Browse[1]> temp1[12] [1] 3926 Browse[1]> temp2[12] [1] 0.4462404 Browse[1]> replace(rep(0, 4000), 3926 , temp2[12])[3925] [1] 0 For some reason, R seems to shift indices along when doing this replacement. Has anyone encountered this bug before? It seems to crop up

Hi, This is probably really obvious, by I can't seem to find anything on it. Is there a fast version of ave for when the data is already sorted in terms of the factor, or if the breaks are already known? Basically, I have: X = 0.1, 0.2, 0.32, 0.32, 0.4, 0.56, 0.56, 0.7... Y = 223, 434, 343, 544, 231.... etc of the same, admittedly large length. Now note that some of the values of X are

Hi, Possibly a dumb question, but I wonder if anyone can help me with this. What I want to do, essentially, is to loop over all ordered subsets of a given size of a certain set. Ultimately, the idea is to find the subset that maximises a certain value. The set in question is likely large (the subset size is likely small, though), so things like combn don't seem to be a good solution. The

__USE_LARGEFILE is a standard Unix way to allow > 2Gb files on 32-bit OSes by using f{seek,tell}o Take a look at the definition of f_tell: #if defined(HAVE_OFF_T) && defined(__USE_LARGEFILE) #define f_seek fseeko #define f_tell ftello #else #ifdef Win32 #define f_seek fseeko64 #define f_tell ftello64 #else #define f_seek fseek #define f_tell ftell #endif #endif Windows support for

tplate@blackmesacapital.com wrote: > I've noticed that seek(con, 0, "end", rw="r") on a file connection does > not always work correctly after a write (R 2.1.0 on Windows). > > [Is a call to fflush() needed inside file_seek() in main/connections.c?] If you have an idea where to fflush() precisely and your patch works, please tell it! I'll happily run

I've noticed that seek(con, 0, "end", rw="r") on a file connection does not always work correctly after a write (R 2.1.0 on Windows). [Is a call to fflush() needed inside file_seek() in main/connections.c?] Example (see the lines with the "***WRONG***" comment) > # seek(, rw="r") on a file does not always work correctly after a write > f

Hi, Should be a quickie: I want to make a datafile in R for plotting in gnuplot (which has friendlier 3D plotting options, as far as I can tell). So, I want to create a file with contents along the lines of #File begins 0 0 10 0 13 10 0.2 2 10 1 0 10.12 1 1 5 1 2 10 2 0 10 2 1 1 2 2 10 It's probably fairly easy to write the space-separated numbers with write.table, sink, or similar. But

Hello everyone! Can we add low-level seek functions into libFLAC? I'm using libFLAC in a program where file operations can't be completed synchronously from those user callback procedures that libFLAC calls when it needs to perform read, seek, etc. So I had to modify libFLAC in a way that it doesn't call any user callbacks while performing seeking. Although I added a dirty hack for

ligges@statistik.uni-dortmund.de wrote: > tplate@blackmesacapital.com wrote: > > >>I've noticed that seek(con, 0, "end", rw="r") on a file connection does >>not always work correctly after a write (R 2.1.0 on Windows). >> >>[Is a call to fflush() needed inside file_seek() in main/connections.c?] > > > > If you have an idea

Hi, I get an "internal error" when calling seek() twice on a gzfile connection. Create a gzip file: bigraw <- sample(charToRaw("abcdef"), 30000000, replace=TRUE) save(bigraw, file="bigraw.rda") Open it: con <- gzfile("bigraw.rda", "rb") Then: > seek(con, where=1) [1] 0 > seek(con, where=24980000) [1] 1

This thread reminded me of Ralph's LCA presentation entitled "Seeking is Hard". <http://xiph.org/~giles/> Not sure if it contains anything you don't already know, but worth a mention. - Josh On 2015-5-20 06:55 , Madison Link wrote: > Thanks. > > > > If decoding from the last packet on the previous page works, I may have > to do that. But I was

? Tue, 21 May 2024 11:29:33 +0200 Laurent Rhelp <laurentRHelp at free.fr> ?????: > pos <- seek(con_in,2,origin="start") > # We have to repeat the command to return the good amount of read > # bytes > print(paste0("pos is not equal to 2, pos = ",pos)) That's because seek() returns the previous position ("before any move", the one that the

Thanks for your reply. I am using JSpeex so it is not possible to use the libs you mention. I looked a little at the source in http://jspeex.sourceforge.net but cant see where the length can be stored. Unfortunately, that project does not seem to be maintained - no replies to queries posted on the forums. Does anyone know how to store the length of a JSpeex clip in the header? thanks, Anil ---

The original subject line is false. It *does* reposition, but `origin' was being ignored, so your request was to reposition to the beginning of the file, and that is what happened. This was already fixed in R-patched: from NEWS there: o seek() on file connections was ignoring the `origin' argument. It's always worth looking at the current patched version. On Tue, 29 Jan 2002

Full_Name: Dr. Alex Sheppard Version: 2.7.1 OS: Linux Debian Lenny Submission from: (NULL) (79.73.224.62) After scanning from an open (text) connection, then seeking, then scanning again, the second scan returns incorrect result. It looks like the first byte scanned was from the pre-seek file position, then it continues to read from the post-seek file position. To reproduce: #Put 3x3 matrix