similar to: problems with truncate() with files > 2Gb under Windows (possibly (PR#7879)

__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

Full_Name: John Brzustowski Version: R-devel-trunk, R-2.4.0 OS: linux Submission from: (NULL) (206.248.132.197) DESCRIPTION seek() on files larger than 2 gigabytes fails for large values of "where" on i386 linux 2.6.13 (and presumably other 32-bit unix-like platforms). e.g.: > f<-file("3gigabytefile.dat", "rb") > seek(f, 3e9, "start",

Tony Plate wrote: > 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

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

Dear LLVM developers, My name is Ben Niu and I am a Ph.D. student at Lehigh University. I compiled the MUSL C library using Clang 3.3, and dumped the generated LLVM IR files. I found that the MUSL-defined FILE struct (aliasing __FILE_s) struct __FILE_s { unsigned flags; unsigned char *rpos, *rend; int (*close)(FILE *); unsigned char *wend, *wpos; unsigned char *mustbezero_1;

On Tue, Sep 10, 2013 at 7:13 PM, Ben Niu <niuben003 at gmail.com> wrote: > Dear LLVM developers, > > My name is Ben Niu and I am a Ph.D. student at Lehigh University. I > compiled the MUSL C library using Clang 3.3, and dumped the generated LLVM > IR files. I found that the MUSL-defined FILE struct (aliasing __FILE_s) > > struct __FILE_s { > unsigned flags; >

I'm using seekable_stream_decoder, And., this is my write_callback. I'm not getting the required output. The PCM i get is not the proper music. Am I doing something wrong here? FLAC__StreamDecoderWriteStatus AFLACStreamPlayer::StreamWriteCb ( const FLAC__SeekableStreamDecoder *decoder, const FLAC__Frame *frame, const FLAC__int32 * const buffer[], void *client_data) { int Channels,

I can't be totally sure what 'short' is on your platform, but if it's (probably) 16-bits, it looks like you're treating the samples in buffer[] as packed 16 bit numbers. but all samples in buffer[] are 32-bit signed integers in host order, regardless of the bits-per-sample of the frame. so to get them down to shorts (assuming they'll fit), do like: FLAC__int32 *

I apologize for posting on this question again, but unfortunately, I don't have and can't get access to MASS for at least three weeks. I have found some code on the web however which implements the prediction error algorithm in cv.glm. http://www.bioconductor.org/workshops/NGFN03/modelsel-exercise.pdf Now I've tried to adapt it to my purposes, but since I'm not deeply familiar

This post is NOT a question, but an answer. For readers please disregard all earlier posts by myself about this question. I'm posting for two reasons. First to say thanks, especially to Dimitris, for suggesting the use of errorest in the ipred library. Second, so that the solution to this problem is in the archives in case it gets asked again. If one wants to run a k-fold cross-validation

Removed buffer size increase. Only tells the filesize to Windows now. On 26.9.2014 14:08, Erik de Castro Lopo wrote: > Martijn van Beurden wrote: > >> Can you please wrap the setvbuf in _WIN32 IFDEFs too? Currently >> memory usage of FLAC decoding is about 1MB, so this patch is >> increasing memory usage tenfold, also for platforms that do not >> need this. It is a

Hello I have same problem like that one from month or two ago: UD Agent refuses to run giving "invalid picture" error. I have applied patch (posted recently by Gerard Patel) to Wine-20010305 but nothing happend - same error. Then I gave a try to Wine-20010418 - unpatched/patched(manually) - same story. If someone has any ideas I would be very grateful. For those who want to or can help:

The previous patch was bugged. The output file wasn't truncated to correct size and was a bit off from rounding the WAVE/AIFF header to smallest sector size. And RAW output didn't benefit from the change. And the existing functions didn't need changes as outputfilename was already known. Attached is a fixed and improved version. -------------- next part -------------- diff --git

http://bugzilla.mindrot.org/show_bug.cgi?id=615 ------- Additional Comments From dtucker at zip.com.au 2003-09-06 12:51 ------- Created an attachment (id=387) --> (http://bugzilla.mindrot.org/attachment.cgi?id=387&action=view) Move libgen test after dirname test Looked at this again, I think the reason it's not working is libgen has already been detected before the dirname test,

Bottom Line Up Front: How does one reshape genetic data from long to wide? I currently have a lot of data. About 180 individuals (some probands/patients, some parents, rare siblings) and SNP data from 6000 loci on each. The standard formats seem to be something along the lines of Famid, pid, fatid, motid, affected, sex, locus1Allele1, locus1Allele2, locus2Allele1, locus2Allele2, etc In other

Hi, just to give you a quick "success" note: current portable CVS snapshot builds mostly fine on SCO3. The only remaining problem is truncate() in sftp-server.c - SCO3 can replace ftruncate() with chsize() (detected by configure and works), but has no truncate() equivalent. Run-time testing tomorrow, but I do not expect nasty surprises. gert -- USENET is *not* the non-clickable

I'm considering commiting something like this. -------------------------------- --- configure.ac.old 2005-02-24 19:47:25.361190001 -0800 +++ configure.ac 2005-02-25 12:33:35.341390018 -0800 @@ -374,23 +374,7 @@ ;; # SCO UNIX and OEM versions of SCO UNIX *-*-sco3.2v4*) - CPPFLAGS="$CPPFLAGS -Dftruncate=chsize" [snip next 16 deleted lines] + AC_MSG_ERROR("This Platform

Thank you for the feedback. This is cross-compiling for mingw-w64-x86_64 using gcc-5.3.0 and mingw-w64-4.0.4 on GNU/Linux. Upon attempting to compile now, a large number of errors occur in flac/decode.c which I have placed at the end of this email. They are eased by adding this to decode.c: #if _WIN32 #include <windows.h> #include <shlobj.h> #endif ...among the headers. Then, this

Hello, Upon compiling the flac tree today, after many successful compilations over the last few weeks, a new error is appearing before compilation bails out. This is a cross-compilation using gcc-5.3.0 running on GNU/Linux, with the objects being built for a mingw-w64-x86_64 host. Among other things, the compiler is looking for windows_unicode_filenames.h but it isn't there. Also, I'm

Greetings one and all; I'm not subscribed to this list so I'm first sending this message to verify that mails from me make it through, and then later I'll send the juicy messages with patches. Also, the address I'm using is IPv6-only and doesn't often work, so drop me from any replies and I'll catch the archives, or drop only the hostname part to get an IPv4 address that