search for: hackili

Hi, What exactly is the reason why libFlac and/or the FLAC command-line en/decoder currently doesn't support 32bit integer samples? The comment in "FLAC/format.h" -> of FLAC__REFERENCE_CODEC_MAX_BITS_PER_SAMPLE notes that the FLAC format supports 32bit, but the reference en/decoders currently do not. Does this mean that libFlac or just the commandline tool is limited to 24

On 05.09.2006, at 22:51, Josh Coalson wrote: > --- taktik <taktik@renoise.com> wrote: >> What exactly is the reason why libFlac and/or the FLAC command-line >> en/decoder currently doesn't support 32bit integer samples? >> >> The comment in "FLAC/format.h" -> of >> FLAC__REFERENCE_CODEC_MAX_BITS_PER_SAMPLE notes that >> the FLAC format

Great stuff; thanks both! I'm also looking to turn my MCJIT conversion spike into our main use case. The only thing I'm missing is the ability to get a post-linked copy of the generated assembly. In JIT I used JITEventListener's NotifyFunctionEmitted and used a MCDisassembler to disassemble the stream (with my own custom annotators), and redirected the output to the relevant place

Hi Matt, Philip, You could get the data you want by recording the addresses returned by the allocateCodeSection and allocateDataSection methods on your RTDyldMemoryManager, then disassembling those sections after you've called resolveRelocations. That's a little unsatisfying though. For one thing, unless you very carefully maintain the association with the original object via

This affects the XMMS plugin. configure.in has this test: AC_CHECK_TYPES(socklen_t, [], []) And src/plugin_xmms/http.c is the only consumer: #ifndef HAVE_SOCKLEN_T typedef unsigned int socklen_t; #endif Together this looks bogus to me. The configure check looks for socklen_t in the default headers. If it isn't found there, socklen_t will be typedef'ed. However, at least on

Hi Jim, Thanks for a very quick reply! That indeed does the trick! Presumably the default has changed in 3.5 to be a "generic" CPU instead of the native one? If that's the case I wonder why: especially when JITting it really only makes sense to target the actual CPU - unless I'm missing something? :) Thanks again, Matt On Wed, Sep 17, 2014 at 2:16 PM, Jim Grosbach

Please CC as I''m not subscribed to valgrind-developers. Under Xen the toolstack is responsible for managing the domains in the system, e.g. creating, destroying, and otherwise manipulating them. To do this it uses a number of ioctls on the /proc/xen/privcmd device. Most of these (the MMAPBATCH ones) simply set things up such that a subsequenct mmap call will map the desired guest

Hi Gael, I tried converting to your approach but I had some issues making sure that all symbols accessed by the jit modules have entries in the dynamic symbol table. To be specific, my current approach is to use MCJIT (using an objectcache) to JIT the runtime module and then let MCJIT handle linking any references from the jit'd modules; I just experimented with what I think you're doing,