search for: hackeri

Hi all, especially David Yeo and JonY, I've started moving compiler specific CPP hacker into a separate file at include/share/compat.h. Eventually I hope to be able to move all of the require CPP hackery for $random_compiler into this file and have any C file which needs any compiler specific tweak to include this new compatibilty header. My belief is that one this CPP hackery is all in one

On 2/4/2012 13:20, Erik de Castro Lopo wrote: > Hi all, especially David Yeo and JonY, > > I've started moving compiler specific CPP hacker into a separate file > at include/share/compat.h. > > Eventually I hope to be able to move all of the require CPP hackery > for $random_compiler into this file and have any C file which needs > any compiler specific tweak to

On Sun, Feb 5, 2012 at 1:30 AM, <flac-dev-request at xiph.org> wrote: > Send flac-dev mailing list submissions to > flac-dev at xiph.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.xiph.org/mailman/listinfo/flac-dev > or, via email, send a message with subject or body 'help' to > flac-dev-request at xiph.org

Dave Yeo wrote: > Another try Actually there are still some issues with this patch, mainly around your changes to incluce/FLAC/ordinals.h. This file is a public header file and hence, your changes: diff --git a/include/FLAC/ordinals.h b/include/FLAC/ordinals.h index 80d055b..dc2dafc 100644 --- a/include/FLAC/ordinals.h +++ b/include/FLAC/ordinals.h @@ -32,10 +32,18 @@

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02/08/12 01:32 am, Erik de Castro Lopo wrote: > Dave Yeo wrote: > >> Another try > > Actually there are still some issues with this patch, mainly > around your changes to incluce/FLAC/ordinals.h. This file is a > public header file and hence, your changes: Sorry about that, forgot that it is a public header. [...] >

On 02/07/12 12:03 am, Erik de Castro Lopo wrote: > Dave Yeo wrote: > >> This commit will break OS/2's EMX 0.9d library (GCC 2.8.1) which has been >> been replaced by klibc. Considering the age of EMX and lack of testing >> and that klibc contains so many improvements I think this is exceptable. > > Sorry Dave, I can't do that. Or rather sorry, the patch

JonY wrote: > Looks like there are some missed defines in the test_libFLAC++. Attached > patch fixes that. Good one. Thanks. > Also, wsock32 usage is deprecated, on Win7, wsock32 forwards everything > to ws2_32, suggest changing to -lwsock32 to -lws2_32 in configure.ac. > Additionally, using -lwsock32 on Cygwin is wrong. Fix in config.txt. For that I think I'd prefer to

>> Dave Yeo wrote: >>> Yes that makes sense. Requiring a C99 compliant compiler seems quite > reasonable. >> Well I'm actually going to be even more reasonable than that. The only > bits of C99 that flac will really require is header file >> with C99 standard width integers (int8_t, uint8_t, int16_t etc). Erik > > I would recommend including with the

>I probably shouldn''t have been operating machinery yesterday. >The crash is probably because I committed the e820 memory rearranging >stuff into the wrong branch, but something may have broken us from >tip/master as well. >   J Kernel was already broken at 2/28/09 --- On Sat, 2/28/09, Marc - A. Dahlhaus <mad@wol.de> wrote: From: Marc - A. Dahlhaus

This commit will break OS/2's EMX 0.9d library (GCC 2.8.1) which has been been replaced by klibc. Considering the age of EMX and lack of testing and that klibc contains so many improvements I think this is exceptable. --- include/FLAC/ordinals.h | 17 +++++++++-------- src/flac/main.c | 2 +- src/libFLAC/metadata_iterators.c | 2 +-

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 09.02.2012 21:41, Ben Allison wrote: >>> Dave Yeo wrote: >>>> Yes that makes sense. Requiring a C99 compliant compiler >>>> seems quite >> reasonable. >>> Well I'm actually going to be even more reasonable than that. >>> The only >> bits of C99 that flac will really require is

> Dave Yeo wrote: >> Yes that makes sense. Requiring a C99 compliant compiler seems quite reasonable. > Well I'm actually going to be even more reasonable than that. The only bits of C99 that flac will really require is header file > with C99 standard width integers (int8_t, uint8_t, int16_t etc). Erik I would recommend including with the distribution a file for windows

Hokay. It appears that enumdrivers / getdriver in rpcclient is broken, and won't be fixed soon. I'd fix it meself, but hey, I'm too busy clearing skyscrapers in a single bound and moving faster than a speeding bullet. Or maybe I looked at the cvs once and got REALLY scared. Unfortunately, I can't wait, so I've come up with a nasty hack to help us with querying samba for the

JonY wrote: > On 3/17/2013 23:01, LRN wrote: > >> All those ifdefs will at least be confined rather than spread out > >> through the code. > > I did it plibc-style: > > > > in compat.h: > > #if defined(_WIN32) > > #define FOPEN grabbag__fopen_utf8_wrapper > > #else > > #define FOPEN fopen > > #endif > > > > in

Anybody knows the reason for the following code (you can see it in flac/decode.c, flac/encode.c, libFLAC/fixed.c and libFLAC/stream_decoder.c) ? #if defined _MSC_VER || defined __MINGW32__ /* with MSVC you have to spoon feed it the casting */ residual_bits_per_sample[0] = (FLAC__float)((total_error_0 > 0) ? log(M_LN2 * (FLAC__double)(FLAC__int64)total_error_0 /

I recently subscribed to the LLVM and Clang developer mailing lists, and earlier today read a message requesting advice on "Contributing to LLVM Projects". I'm hoping to eventually get involved as well, but with my situation being very different to that described in the referenced thread I got the idea of solliciting advice seperately. If this is not the right place to ask, though,

Hello, I just wrote instructions for building Xen 4.2 from sources on various RPM-based Linux distributions. The guide is available here: http://wiki.xen.org/wiki/Xen_4.2_Build_From_Source_On_RHEL_CentOS_Fedora I was able to successfully build Xen 4.2.0-rc2 on the following Linux distros: - CentOS 5.8 x64 - CentOS 6.3 x64 - Fedora 17 x64 RHEL5/CentOS5 requires some hackery to get

Hello, I just wrote instructions for building Xen 4.2 from sources on various RPM-based Linux distributions. The guide is available here: http://wiki.xen.org/wiki/Xen_4.2_Build_From_Source_On_RHEL_CentOS_Fedora I was able to successfully build Xen 4.2.0-rc2 on the following Linux distros: - CentOS 5.8 x64 - CentOS 6.3 x64 - Fedora 17 x64 RHEL5/CentOS5 requires some hackery to get

Unfortunately, LNT still uses the Makefiles underneath, and the Makefiles support a few users who use the more advanced hackery they support. We should keep it for the time being. - Daniel On Nov 14, 2012, at 13:30, Sean Silva <silvas at purdue.edu> wrote: > The top of the file says that it is deprecated in favor of LNT. Is > this document still needed? It makes mention of

Hello, I've been tracking down a regression in fbo-generatemipmap-formats with ARB_depth_texture on nouveau (nv50 and nvc0 are affected) since http://cgit.freedesktop.org/mesa/mesa/commit/?id=0a1479c829ed34a65e60c6619a8164e1b079aaee FTR, the test I'm running is: bin/fbo-generatemipmap-formats GL_ARB_depth_texture -fbo -auto Looking at the displayed output (without -fbo -auto), it looks