search for: bytewise

I tried to use the current cvs version of ogg123 with oss output and the ogg just sounds like static. I wanted to document it on the list in case anyone else is having the problem. I can make ogg123 write wav files fine. Also Vakor does not have any trouble playing oggs with ogg123, so I am not certain what the problem is. I have tried compiling all of ogg vorbis (ao,ogg,vorbis,vorbis-tools)

...t.h> #include "audio_out.h" /* --- Function Tables --- */ @@ -267,4 +268,14 @@ free(options); options = rest; } +} + +/* Helper function lifted from lib/vorbisfile.c */ +int ao_is_big_endian() { + uint_16 pattern = 0xbabe; + unsigned char *bytewise = (unsigned char *)&pattern; + if (bytewise[0] == 0xba) return 1; + + assert(bytewise[0] == 0xbe); + return 0; } 1.1.4.1 +2 -0 vorbis/vorbis-tools/libao/audio_out.h Index: audio_out.h =================================================================== RCS file: /usr/local/cvsroot/vor...

...h an ObjectCache). I thought I'd save some time by using getLazyBitcodeModule, since the IR isn't actually needed right away, but this only reduced the parsing time (ie the time of the actual getLazyBitcodeModule() call) to 45ms, which I thought was surprising. I also tested computing the bytewise-xor of the bitcode file to make sure that it was fully read into memory, which took about 5ms, so the majority of the time does seem to be spent parsing. Then I switched back to ParseBitcodeFile, but now I added the "-strip-debug" flag to my opt invocation, which reduced the bitcode file...

...chrooted environments. It is possible to mount /proc into the chroot but this > seems to be missing from many setups. The code in LLVM that uses /proc/self/exe > returns an empty string on error which confuses clang. There is no empty string for me, and the returned string is a real object (bytewise identical to the real thing) : $ cd <into a dynamic view> $ cp /bin/ls . $ ls -l /proc/self/exe lrwxrwxrwx 1 ggreif ocs 0 Jul 13 21:27 /proc/self/exe -> /bin/ls $ ./ls -l /proc/self/exe lrwxrwxrwx 1 ggreif ocs 0 Jul 13 21:27 /proc/self/exe -> /vol/ocs_userviews25_13/ggreif-hc_stm-OCSnb...

...I thought I'd save > some time by using getLazyBitcodeModule, since the IR isn't actually needed > right away, but this only reduced the parsing time (ie the time of the > actual getLazyBitcodeModule() call) to 45ms, which I thought was > surprising. I also tested computing the bytewise-xor of the bitcode file > to make sure that it was fully read into memory, which took about 5ms, so > the majority of the time does seem to be spent parsing. > > Then I switched back to ParseBitcodeFile, but now I added the > "-strip-debug" flag to my opt invocation, which...

...ascii (a_body) my $a_body; open F,$f_in; while (<F>) { chomp; # remove trailing lf s/\#.*$//g; # remove comments s/\s//g; # remove all whitespace $a_body .= $_.'&' if length > 0; } close F; $a_body .='gnkey=0b82'; # add an extra byte to make the body even (bytewise) $a_body .= "\0" if ((length($a_body) % 2) ne 0); # add an extra word ( = two bytes) to make the body even (wordwise) $a_body .= "\0\0" if ((length($a_body) % 4) ne 0); # generate a d_length (length of the complete message, counting words, in dec) # ( header is always 8 words...

...It is possible to mount /proc into the chroot but this >> seems to be missing from many setups. The code in LLVM that uses /proc/self/exe >> returns an empty string on error which confuses clang. > > There is no empty string for me, and the returned string is a real object > (bytewise identical to the real thing) : > > $ cd <into a dynamic view> > $ cp /bin/ls . > $ ls -l /proc/self/exe > lrwxrwxrwx 1 ggreif ocs 0 Jul 13 21:27 /proc/self/exe -> /bin/ls > $ ./ls -l /proc/self/exe > lrwxrwxrwx 1 ggreif ocs 0 Jul 13 21:27 /proc/self/exe -> /vol/ocs...

...ave some time by using getLazyBitcodeModule, since the IR isn't >>> actually needed right away, but this only reduced the parsing time (ie the >>> time of the actual getLazyBitcodeModule() call) to 45ms, which I thought >>> was surprising. I also tested computing the bytewise-xor of the bitcode >>> file to make sure that it was fully read into memory, which took about 5ms, >>> so the majority of the time does seem to be spent parsing. >>> >>> Then I switched back to ParseBitcodeFile, but now I added the >>> "-strip-debug...

...o the chroot > but this > >> seems to be missing from many setups. The code in LLVM that uses > /proc/self/exe > >> returns an empty string on error which confuses clang. > > > > There is no empty string for me, and the returned string is a real object > > (bytewise identical to the real thing) : > > > > $ cd <into a dynamic view> > > $ cp /bin/ls . > > $ ls -l /proc/self/exe > > lrwxrwxrwx 1 ggreif ocs 0 Jul 13 21:27 /proc/self/exe -> /bin/ls > > $ ./ls -l /proc/self/exe > > lrwxrwxrwx 1 ggreif ocs 0 Jul 13 2...

On 13.07.2012, at 09:46, Gabor Greif <gabor.greif at alcatel-lucent.com> wrote: > Hi all, > > I am in charge of the controlled introduction of clang into > our builds at my workplace. Since all our tools must run from > a ClearCase view for automatic dependency tracking, we have been > biten by a Linux bug, and readlink("/proc/self/exe", ...) gives >

...h runs with >> SLES 11? >> > > Short answer - copy the LVs and guest config from one server to the other. > > Longer answer : > Create each LV on the new server, copy the contents across from the old > one. If the LV is identical in size then you can probably just do a bytewise > copy of the LV. Alternatively, you can mount the LV on the DomU and copy all > the files across using your favourite tool. > > My personal preference is : > mount LV on /mnt on each Dom0 > rsync -avH --numeric-ids /mnt/ root@the_new_server.yourdomain:/mnt/ > scp /etc/xen/gues...

Hello, i was getting into problems when booting a GRUB bootdisk with memdisk. I get the menu of GRUB, but when i change something to boot (e.g. Redhat installation tool) System freezes after uncompressing kernel. I used either syslinux version of Boot Scriptor and latest standalone version from kernel.org. I hope you are able to give me a clue what is wrong. Thanks in advance. Christian

...>> seems to be missing from many setups. The code in LLVM that uses > /proc/self/exe > >> returns an empty string on error which confuses clang. > > > > There is no empty string for me, and the returned string is a real > object > > (bytewise identical to the real thing) : > > > > $ cd <into a dynamic view> > > $ cp /bin/ls . > > $ ls -l /proc/self/exe > > lrwxrwxrwx 1 ggreif ocs 0 Jul 13 21:27 /proc/self/exe -> /bin/ls > > $ ./ls -l /proc/self/exe > > lrwxrw...

...dless Range worker: user/group switching for after_fork hooks Fix autoload of Etc in Worker for Ruby 1.9 bin/unicorn: allow RACK_ENV to be passed from parent tests for RACK_ENV preservation http: allow headers/trailers to be written byte-wise http: extra test for bytewise chunked bodies tee_input: do not clobber trailer buffer on partial uploads test_exec: ensure master is killed after test Util::tmpio returns a TmpIO that responds to #size TODO: remove user-switching bit, done unicorn 0.94.0 Wayne Larsen (1): bin/unicorn: set EN...

Hi all, I am in charge of the controlled introduction of clang into our builds at my workplace. Since all our tools must run from a ClearCase view for automatic dependency tracking, we have been biten by a Linux bug, and readlink("/proc/self/exe", ...) gives nonsensical results. So we need to introduce a configure option for disallowing this method of executable discovery (the other one

...numbers report expertise in compiler internals and in the C standard. MAIN QUESTION RESPONSES ----------------------- ###[1/15] How predictable are reads from padding bytes? **If you zero all bytes of a struct and then write some of its members, do reads of the padding return zero? (e.g. for a bytewise CAS or hash of the struct, or to know that no security-relevant data has leaked into them.)** It remains unclear what behaviour compilers currently provide (or should provide) for this. We see four main alternatives: a) Structure copies might copy padding, but structure member writes never touch...

...ls and in the C standard. > > > MAIN QUESTION RESPONSES > ----------------------- > > ###[1/15] How predictable are reads from padding bytes? > > **If you zero all bytes of a struct and then write some of its > members, do reads of the padding return zero? (e.g. for a bytewise > CAS or hash of the struct, or to know that no security-relevant data > has leaked into them.)** > > It remains unclear what behaviour compilers currently provide (or > should provide) for this. We see four main alternatives: > > a) Structure copies might copy padding, but s...

...TION RESPONSES > >> ----------------------- > >> > >> ###[1/15] How predictable are reads from padding bytes? > >> > >> **If you zero all bytes of a struct and then write some of its > >> members, do reads of the padding return zero? (e.g. for a bytewise > >> CAS or hash of the struct, or to know that no security-relevant data > >> has leaked into them.)** > >> > >> It remains unclear what behaviour compilers currently provide (or > >> should provide) for this. We see four main alternatives: > >&gt...

...; >> >> MAIN QUESTION RESPONSES >> ----------------------- >> >> ###[1/15] How predictable are reads from padding bytes? >> >> **If you zero all bytes of a struct and then write some of its >> members, do reads of the padding return zero? (e.g. for a bytewise >> CAS or hash of the struct, or to know that no security-relevant data >> has leaked into them.)** >> >> It remains unclear what behaviour compilers currently provide (or >> should provide) for this. We see four main alternatives: >> >> a) Structure copie...