search for: hackery

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 place, it will be far easier to modify and keep correct. So, I would be very greatful if David Yeo and JonY...

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 include this new compatibilty header. > > My belief is that one this CPP hackery is all in one place, it will > be far easier to modify and keep correct. > > So, I would be...

....org > > You can reach the person managing the list at > flac-dev-owner at xiph.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of flac-dev digest..." > > > Today's Topics: > > 1. Re: Moving CPP hackery (JonY) > 2. Re: Moving CPP hackery (Erik de Castro Lopo) > 3. Re: Meet the new maintainer (Erik de Castro Lopo) > 4. Re: Moving CPP hackery (JonY) > 5. Re: Moving CPP hackery (Erik de Castro Lopo) > > > -------------------------------------------------------------------...

...f unsigned char FLAC__uint8; rely on "config.h" which is only available when FLAC is compiled, not when this file is installed in /usr/include/FLAC or whereever. I'll accept the rest of the patch. For the problem of this file, I think the best solution is to just remove all the CPP hackery and assume that a C99 <stdint.h> is available. THis would then make it incumbent on any developer that includes (either directly or indirectly) include/FLAC/ordinals.h to include some version of <stdint.h> first, even if it is just a mininal one with typedefs for the minimal set of size...

......] > rely on "config.h" which is only available when FLAC is compiled, > not when this file is installed in /usr/include/FLAC or whereever. > > I'll accept the rest of the patch. For the problem of this file, I > think the best solution is to just remove all the CPP hackery and > assume that a C99 <stdint.h> is available. THis would then make it > incumbent on any developer that includes (either directly or > indirectly) include/FLAC/ordinals.h to include some version of > <stdint.h> first, even if it is just a mininal one with typedefs > fo...

...ry Dave, I can't do that. Or rather sorry, the patch doesn't apply. > Probably a line wrapping issue. Maybe you should try send it as an > attachment. > Another try Dave -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Remove-even-more-CPP-hackery.patch Type: application/x-patch Size: 4731 bytes Desc: not available Url : http://lists.xiph.org/pipermail/flac-dev/attachments/20120207/6e2d7707/attachment-0001.bin

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

...nd replace "fopen" with "FOPEN" everywhere else. > > Don't do that, it leaks into the system headers and breaks mingw if > FLAC_USE_FOPEN_UTF8 is defined. > > Call the wrappers directly instead of using a macro. +1 Yep, I prefer not to have too much #ifdef hackery. In my recent replacement of all the sprintf/_snprintf stuff, I relaced all the calls with a call to flac_snprintf() and localised #ifdef hackery to the implementation of that function.

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,

...ous 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 yajl/yajl-devel rebuilt there, so the tutorial url above contains easy instructions and the required patch to make yajl build OK on EL5. -- Pasi

...ous 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 yajl/yajl-devel rebuilt there, so the tutorial url above contains easy instructions and the required patch to make yajl build OK on EL5. -- Pasi

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 llvm-gcc as well... > > -- S...

...ach the ZS surface to a colour render target. */ static INLINE enum pipe_format nv50_blit_zeta_to_colour_format(enum pipe_format format) Getting rid of that conversion naturally breaks stuff... by also hacking up nv50_blit_select_mode, I can restore it to a very similar broken mode as without the hackery (adding further hackery to force it to use zsbuf instead of cbuf breaks everything, but I suspect even more hackery could be performed to make it work). Unfortunately I don't know enough about this storage type business, and what effect it has on things like render targets, esp if you're ly...