search for: bytesex

...ould compile on every plateform that has a jdk and libSpeex (or was it speexLib ?). I used the jdk1.4 and Windows but a friend of mine got it to work under FreeBSD and jdk1.3 without any modifications (That i'm aware of at least). It still has a few flaws i could fix (if i was not so lazy). 1/bytesex First It will probably have endianess problem, java is big endian by the spec, while the host machine i've considered is little endian (x86). So everything that is received from java is converted to little endian. As far as i understand speex (not much) it expects to receive byte (floats?) in...

...As followup to the Linux-Kongress tutorials I''ve started to polish my tiny domain installer scripts a bit and ended up creating a new package containing a number of shell scripts for domU installations. The name is "domi" and you can grab a copy here: tarball: http://dl.bytesex.org/cvs-snapshots/ suse rpm: ftp://ftp.suse.com/pub/people/kraxel/10.0-i386/i586/ Tested on: suse 10.0 + xen unstable. Distros it can install: suse, fedora, debian, gentoo. enjoy, Gerd _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com htt...

Sorry, to interrupt the license flame war... I downloaded the source from CVS as of 11am this morning and there are a couple of issues that I ran into: 1) I built the package and then in the examples dir I executed the following commands: # cdparanoia -B 1-1 # ./encoder-example < track01.cdda.wav > test.vor # ./decoder-example < test.vor > out.wav The rip and the encode both work

Hi, Updated to current bk today, and my machine stopped booting ... I''ve tracked it down to the apic changes from end of last week. cset 1.1307 boots fine, 1.1308 doesn''t. Diff of the boot messages is below. Full logs are also attached. Gerd --- log-1.1307 2005-04-21 14:40:57.372885027 +0200 +++ log-1.1308 2005-04-21 14:38:52.236553392 +0200 @@ -7,7 +7,7 @@

Hi, I''m trying to add PAE support to xen at the moment, and have some trouble with compiling the code at the moment. gcc complains about "initializer element is not computable at load time". The only explanation I have for that at the moment is that gcc has problems to deal with u64 (i.e. unsigned long long) calculations at compile time. Can anyone confirm or deny this?

Hi, In many places xen uses "unsigned long" instead of the l*_pgentry_t types to pass around page table entries. Here is a patch which fixes this in a number of places (mostly in shadow mode code). Thats what I''ve trapped in so far, maybe more of these patches follow. Fixing this is needed for adding PAE support to xen. In PAE paging mode the page table entries are 64 bit