search for: jhaberman

Are there any plans to add stack switching to LLVM? I've seen a few proposals for it floating around (some even implemented): http://ulir.ul.ie/handle/10344/2927 (implemented in: https://github.com/stedolan/llvm) https://code.google.com/p/llvm-stack-switch/ But I couldn't find any discussion of whether there was a plan to integrate one of these. Any plans to add this feature? Thanks,

What is the best way to add song metadata (artist, album, title, etc.) to flac files? I want to be able to define an arbitrary number of FIELD=value pairs. Earlier I heard someone mention using id3 tags. I tried this with the command-line "id3v2", and while it seemed to work I noticed that the resulting file no longer began with "fLaC", which violates the format

Thanks for the quick response on the C++ thing. It would also be nice if the host program could correctly write the STREAMINFO block in the stream encoder metadata callback without having to know the specifics of the header format (or worry about endianness). How exactly to achieve this might take some thought, but what about this idea: 1. The correct way to respond to the metadata callback:

Hello FLACers, I'm working on implementing FLAC support for Audacity, a cross-platform audio editor (audacity.sourceforge.net). We're experimenting with using FLAC as the internal data representation. Unfortunately, the FLAC headers cannot be used in C++ programs because of the use of 'private' and 'protected' as variable names in stream_decoder.h, stream_encoder.h, and

--- Joshua Haberman <jhaberman@ups.edu> wrote: > What is the best way to add song metadata (artist, album, title, > etc.) to > flac files? I want to be able to define an arbitrary number of > FIELD=value pairs. > > Earlier I heard someone mention using id3 tags. I tried this with > the > command-lin...

Hi Matt, thanks for the reply. * Matt Zimmerman (mdz@debian.org) wrote: > On Tue, Oct 30, 2001 at 11:39:11PM -0800, Joshua Haberman wrote: > > > So I was wondering if flac could be incorporated into the filesystem > > driver so that any file ending in .wav would be transparently encoded > > into flac. I don't know if this could be done at the vfs level so that >

* Matt Zimmerman (mdz@debian.org) wrote: > I agree with Josh (the other one) that abstraction libraries like > libaudiofile are a good way to make this a zero-maintenance feature. > Theoretically, support for new formats can be added to the library, and > all programs using that library will become instantly able to handle it. This is clearly the best solution. However, no abstraction

Have you considered trying to have FLAC become an official part of the Ogg project? Ogg has Vorbis but no lossless codec, and FLAC is already production quality. You've already written the code to wrap FLAC in an Ogg bitstream. Ogg Squish seems to be abandoned, and it would be a grand waste of effort to revive it when FLAC already works so well. The Ogg people would be much better off

Hello, I want to emit a structured log entry (in YAML) for every request that hits my Rails app. For example, an entry in this log would look something like: --- SYSTEM_TIME: 0.0166666666666667 USER_TIME: 0.0999999999999996 DB_TIME: 0.00247621536254883 REAL_TIME: 0.091976 STATUS_CODE: 500 SESSION_ID: 64ad46a8841c66bbf64e93335cedc50d REQUEST_ID: 32d6a42f-da58-43e2-ab27-09d3e2a775cb

I noticed that JITMemoryManager allocates its slabs as rwx. Isn't it a security problem to have memory mapped as both writable and executable? I think JITs often avoid this by mapping their memory as rw, then switching it to rx once the data has been written. I was facing a similar problem in a JIT of my own and was curious to see how LLVM addresses this issue. Thanks, Josh --------------

I am looking to losslessly archive a lot of music and share it over a network. The following stipulations lead me to an interesting conclusion: 1. Almost no programs can read or write flac files directly. 2. Almost all programs can read and write wav files directly. 3. The cost of encoding flac files is fairly low 4. The cost of decoding them is even lower 5. These files would be read much more