Re: [kaffe] Sound on XSCALE (no mixer supporting this type of line...)
Hi, the log output clearly states what's happening: libasound uses ptheads and is linked against version 2.3.2 of glibc. Presumably the version of glibc installed on your system is different, so some the linker was not able to resolve some of the symbols. In other words: you have to fix that version mismatch. Either use a version of libasound that is compiled for your version of glibc of install the version of glibc that the current libasound is linked against. Matthias asutosh gopinath wrote: Hi, I checked the config.log and it shows the following: configure:46526: checking for snd_ctl_open in -lasound configure:46556: arm-linux-gcc -o conftest -O0 -Wall -Wstrict-prototypes -fsigne d-char -I/opt/arm-linux/lib/include -DNDEBUG -L/opt/arm-linux/lib/lib conftest.c -lasound -L/opt/arm-linux/lib/ lib -lasound -lm -ldl -lpthread -L/opt/arm-linux /lib 5 conftest.c:194: warning: function declaration isn't a prototype conftest.c:197: warning: function declaration isn't a prototype /opt/arm-linux/lib/lib/libasound.so: undefined reference to `pthread_cond_ [EMAIL PROTECTED]' /opt/arm-linux/lib/lib/libasound.so: undefined reference to `pthread_cond_ [EMAIL PROTECTED]' /opt/arm-linux/lib/lib/libasound.so: undefined reference to `pthread_cond_ [EMAIL PROTECTED]' /opt/arm-linux/lib/lib/libasound.so: undefined reference to `pthread_cond_ [EMAIL PROTECTED]' collect2: ld returned 1 exit status configure:46562: $? = 1 configure: failed program was: | /* confdefs.h. */ I have no idea how to fix it. Regards Asutosh === - Original Message - From: Matthias Pfisterer [EMAIL PROTECTED] Date: Fri, 30 Jul 2004 15:43:31 +0200 To: asutosh gopinath [EMAIL PROTECTED] Subject: Re: [kaffe] Sound on XSCALE (no mixer supporting this type of line...) Hi, using ALSA 1.0.5 sould work. The libraries are searched for in the standard library paths (/usr/lib, /usr/local/lib, ... depending on your linker configuration). Please check the file config.log for the reason why exactly the test fails. Matthias asutosh gopinath wrote: Hi, Configure gives following output for ALSA ( I did not notice it before !) checking for ALSA CFLAGS... -I/usr/local/arm-linux/lib/include checking for ALSA LDFLAGS... -L/usr/local/arm-linux/lib/lib -lasound -lm -ldl - lpthread checking for libasound headers version = 1.0.1... found. checking for snd_ctl_open in -lasound... no Useable version of ALSA not found. Where ( path/to/alsa) is it trying to find the usable version? I have installed libasound2 (1.0.5-1) from debian.org From where can i get usable version of ALSA. Regards Asutosh -- Matthias Pfisterer [EMAIL PROTECTED] Reuchlinstrasse 28 phone ++49-711-62 87 12 D-70176 Stuttgart (in Deutschland 0711-62 87 12) GERMANY Work like you don't need the money. Love like you've never been hurt. Dance like nobody is watching. Java Sound Resources (examples, FAQ, applications): http://www.jsresources.org/ Tritonus, the open source implementation of the Java Sound API: http://www.tritonus.org/ -- ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Sound on XSCALE (no mixer supporting this type of line...)
Hi, - it may be a bug in your program. Either provide the source code of your test program, or check with AudioPlayer from the Java Sound Resources (URL below). - are you shure that the your installation is correct? How did you test it? Make sure there are Mixers at all. Run 'DumpJSInfo --mixers' (see http://www.jsresources.org/examples/DumpJSInfo.html). Matthias asutosh gopinath wrote: Hi, I have configured kaffe-1.1.4 using ALSA. when i try to run a sond application.. [EMAIL PROTECTED] bin# ./java MyAudio croak.wav java.lang.IllegalArgumentException: no mixer supporting this type of line: javax [EMAIL PROTECTED] javax.sound.sampled.Sour ceDataLine]formats: PCM_SIGNED, 1 channel(s), 16 bit samples, 2 byte frames, 8000.0 Hz, 8000.0 frame s/second, little endian minBufferSize=-1 maxBufferSize=-1 at javax.sound.sampled.AudioSystem.getLine (AudioSystem.java:415) at MyAudio.main (MyAudio.java:80) Why it is not finding the mixer! Asutosh -- Matthias Pfisterer [EMAIL PROTECTED] Reuchlinstrasse 28 phone ++49-711-62 87 12 D-70176 Stuttgart (in Deutschland 0711-62 87 12) GERMANY Work like you don't need the money. Love like you've never been hurt. Dance like nobody is watching. Java Sound Resources (examples, FAQ, applications): http://www.jsresources.org/ Tritonus, the open source implementation of the Java Sound API: http://www.tritonus.org/ -- ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Sound on XSCALE (no mixer supporting this type of line...)
Hi, using ALSA 1.0.5 sould work. The libraries are searched for in the standard library paths (/usr/lib, /usr/local/lib, ... depending on your linker configuration). Please check the file config.log for the reason why exactly the test fails. Matthias asutosh gopinath wrote: Hi, Configure gives following output for ALSA ( I did not notice it before !) checking for ALSA CFLAGS... -I/usr/local/arm-linux/lib/include checking for ALSA LDFLAGS... -L/usr/local/arm-linux/lib/lib -lasound -lm -ldl - lpthread checking for libasound headers version = 1.0.1... found. checking for snd_ctl_open in -lasound... no Useable version of ALSA not found. Where ( path/to/alsa) is it trying to find the usable version? I have installed libasound2 (1.0.5-1) from debian.org From where can i get usable version of ALSA. Regards Asutosh - Original Message - From: Matthias Pfisterer [EMAIL PROTECTED] Date: Fri, 30 Jul 2004 09:03:45 +0200 To: asutosh gopinath [EMAIL PROTECTED] Subject: Re: [kaffe] Sound on XSCALE (no mixer supporting this type of line...) Hi, - it may be a bug in your program. Either provide the source code of your test program, or check with AudioPlayer from the Java Sound Resources (URL below). - are you shure that the your installation is correct? How did you test it? Make sure there are Mixers at all. Run 'DumpJSInfo --mixers' (see http://www.jsresources.org/examples/DumpJSInfo.html). Matthias -- Matthias Pfisterer [EMAIL PROTECTED] Reuchlinstrasse 28 phone ++49-711-62 87 12 D-70176 Stuttgart (in Deutschland 0711-62 87 12) GERMANY Work like you don't need the money. Love like you've never been hurt. Dance like nobody is watching. Java Sound Resources (examples, FAQ, applications): http://www.jsresources.org/ Tritonus, the open source implementation of the Java Sound API: http://www.tritonus.org/ -- ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] kafffe and tomcat run ok on sh3 (superh)!
Dalibor Topic wrote: Kaffe 1.1.3 should be able to run tomcat 4 fine. Tomcat4 uses ant for compiling the JSP sources, so that a simple -Dbuild.properties=kjc will I think it's -Dbuild.compiler=kjc Matthias make it work with kjc. See http://www.jspwiki.org/Wiki.jsp?page=RunningTomcatOnKaffe for details. So, now that you've got tomcat3 running on kaffe 1.0.7, you could try getting 1.1.3 to run on superh-linux and tomcat4 on it. ;) -- Matthias Pfisterer Matthias [dot] Pfisterer [at] web [dot] de Reuchlinstrasse 28 phone ++49-711-62 87 12 D-70176 Stuttgart (in Deutschland 0711-62 87 12) GERMANY Work like you don't need the money. Love like you've never been hurt. Dance like nobody is watching. Java Sound Resources (examples, FAQ, applications): http://www.jsresources.org/ Tritonus, the open source implementation of the Java Sound API: http://www.tritonus.org/ -- ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] [Fwd: Re: kjc bug]
Hi,
I have verified that this bug is indeed fixed.
So I suggest to sync with the kjc CVS.
Thanks,
Matthias
Original Message
Subject: Re: kjc bug
Date: Fri, 30 Jan 2004 10:46:18 +0100
From: Martin Lackner [EMAIL PROTECTED]
To: Matthias Pfisterer [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]
References: [EMAIL PROTECTED]
Hi Matthias!
Now this bug is fixed in the current version of KJC in the CVS.
Regards,
Martin
Matthias Pfisterer wrote:
Hi,
I found a bug in kjc:
---
artemis:~/java/tmpkjavac -version
Version 2.1A released 11. February 2002
artemis:~/java/tmpkjavac Interface.java UsingClass.java
UsingClass.java:1: error:Unaccessible class
pack/Interface/InnerInterface can
not be imported [JLS 7.5.1]
---
I don't get an error on this with the compiler of the Sun JDK 1.4.2 and
1.5.0 and with jikes 1.18.
Matthias
package pack;
public interface Interface
{
static interface InnerInterface
{
}
}
import pack.Interface.InnerInterface;
public class UsingClass
{
}
--
Matthias Pfisterer Matthias [dot] Pfisterer [at] web [dot] de
Reuchlinstrasse 28 phone ++49-711-62 87 12
D-70176 Stuttgart (in Deutschland 0711-62 87 12)
GERMANY
Work like you don't need the money.
Love like you've never been hurt.
Dance like nobody is watching.
Java Sound Resources (examples, FAQ, applications):
http://www.jsresources.org/
Tritonus, the open source implementation of the Java Sound API:
http://www.tritonus.org/
--
___
kaffe mailing list
[EMAIL PROTECTED]
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Reminder - release this weekend
Hi, the build problem I reported a while ago is still reproducible with the latest CVS: Making all in libraries/javalib make[1]: Entering directory `/home/matthias/java/kaffe/libraries/javalib' rm -rf lib mkdir lib /bin/sh ./rebuildLib @essential.files Compiling classes from @essential.files using /home/matthias/java/kaffe/kaffe/kaffe/kaffe-bin -verbosegc -mx 256M at.dms.kjc.Main [ start compilation in verbose mode ] [ parsed gnu/classpath/Configuration.java in 483 ms ] GC: heap 5124K, total before 4782K, after 3607K (51604/39461 objs) 29.6% free, alloced 34839K (#106873), marked 615K, swept 1175K (#12143) 393 objs (9K) awaiting finalization ...and the computer hangs with 100 % CPU load. I'm willing to help to debug this, but don't know where to start. And a note to Talibor: Please do NOT sync with the Tritonus CVS. I started implementing new features that depend on generics. Taking over this code now would break the kaffe build. Matthias Jim Pick wrote: Hi, Just a reminder, I'm going to cut release 1.1.4 on Sunday, and we're currently in a feature freeze. If anybody has some spare time, please try compiling and testing CVS on your platform. In other news, Sun has a beta out of J2SE 1.5.0 out: http://java.sun.com/j2se/1.5.0/relnotes.html So we'll have lots of fun things to implement in the coming months and years. :-) Cheers, - Jim ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe -- Matthias Pfisterer Matthias [dot] Pfisterer [at] web [dot] de Reuchlinstrasse 28 phone ++49-711-62 87 12 D-70176 Stuttgart (in Deutschland 0711-62 87 12) GERMANY Work like you don't need the money. Love like you've never been hurt. Dance like nobody is watching. Java Sound Resources (examples, FAQ, applications): http://www.jsresources.org/ Tritonus, the open source implementation of the Java Sound API: http://www.tritonus.org/ -- ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [Fwd: Re: [kaffe] libtritonusalsa does not get installed]
Hi,
regarding the error below, I tried building kaffe (CVS of today) with
gcc 3.0.4 and encountered the same error:
---
make[1]: Entering directory `/home/matthias/java/kaffe/libraries/javalib'
rm -rf lib
mkdir lib
/bin/sh ./rebuildLib @essential.files
Compiling classes from @essential.files using
/home/matthias/java/kaffe/kaffe/kaffe/kaffe-bin -verbosegc -mx 256M
at.dms.kjc.Main
[ start compilation in verbose mode ]
[ parsed gnu/classpath/Configuration.java in 488 ms ]
./rebuildLib: line 58: 2632 Segmentation fault $JAVAC $VERBOSE
$JAVAC_FLAGS -d $LIBDIR $CPATH ${1+$@}
make[1]: *** [lib/stamp] Error 139
make[1]: Leaving directory `/home/matthias/java/kaffe/libraries/javalib'
make: *** [all-recursive] Error 1
---
Any more ideas I could try?
Matthias
Matthias Pfisterer wrote:
Resending because it didn't get through presumably because the attached
config.log was too big (300 K). If you need config.log, please tell me
and I'll send it directly.
Matthias
Original Message
Subject: Re: [kaffe] libtritonusalsa does not get installed
Date: Sun, 18 Jan 2004 22:33:52 +0100
From: Matthias Pfisterer [EMAIL PROTECTED]
To: Kaffe [EMAIL PROTECTED]
References: [EMAIL PROTECTED] [EMAIL PROTECTED]
[EMAIL PROTECTED] [EMAIL PROTECTED]
Dalibor Topic wrote:
Hallo Matthias,
Matthias Pfisterer wrote:
First the no target all in po that was reported recently. I edited
the top-level Makefile to remove po from SUBDIRS as suggested.
This should be fixed now [1]. Could you do a fresh check out from CVS
and retry?
Yes, I can confirm that it's fixed. Thanks. However, the problem below
remains.
Now I get the following:
--
Making all in libraries/javalib
make[1]: Entering directory
`/home/matthias/java/kaffe/libraries/javalib'
rm -rf lib
mkdir lib
/bin/sh ./rebuildLib @essential.files
Compiling classes from @essential.files using
/home/matthias/java/kaffe/kaffe/kaffe/kaffe-bin -verbosegc -mx 256M
at.dms.kjc.Main
[ start compilation in verbose mode ]
[ parsed gnu/classpath/Configuration.java in 486 ms ]
./rebuildLib: line 58: 15924 Segmentation fault $JAVAC $VERBOSE
$JAVAC_FLAGS -d $LIBDIR $CPATH ${1+$@}
make[1]: *** [lib/stamp] Error 139
make[1]: Leaving directory
`/home/matthias/java/kaffe/libraries/javalib'
make: *** [all-recursive] Error 1
--
This is for ./configure without opions. If I say './configure
--without-alsa', the following happens:
--
make[1]: Entering directory
`/home/matthias/java/kaffe/libraries/javalib'
rm -rf lib
mkdir lib
/bin/sh ./rebuildLib @essential.files
Compiling classes from @essential.files using
/home/matthias/java/kaffe/kaffe/kaffe/kaffe-bin -verbosegc -mx 256M
at.dms.kjc.Main
[ start compilation in verbose mode ]
[ parsed gnu/classpath/Configuration.java in 471 ms ]
--
...and it hangs, hogging the CPU. It is interruptible with ctrl-C.
Interesting bugs, definitely. I'd be more interested in the crash, atm.
Do the problems still occur with the current version from CVS HEAD? If
so, what's your cpu-os platform (or distribution, of you are using
linux), and which gcc are you using? Are there any interesting warnings
during compilation?
I investigated this further by trying old cvs versions. I can reproduce
the problem with versions of 12th, 13th and 15th (haven't tried in
between). With the version of 10th, the build runs smooth. With the
version of 11th, there is an unrelated error about TAudioInputStream
missing, but it seems to get beyond the point of the error. So
presumably, the problem was introducd between 11th and 12th. In each
case, I did a fresh checkout with
cvs -z3 -d :pserver:[EMAIL PROTECTED]:/cvs/kaffe co -D 2004-01-11
kaffe
(and the appropriate date, of course). Then I issued './configure' (no
params) and 'make'.
My system is Linux on a x86, distribution is Debian stable. The gcc
version is 2.95.4. Does it make sense to try with a different version of
gcc?
I haven't detected something obviously wrong during the build. I'm
attaching config.log (produced with the CVS of today (18th).
Matthias
--
Matthias Pfisterer mailto:[EMAIL PROTECTED]
Reuchlinstrasse 28 phone ++49-711-62 87 12
D-70176 Stuttgart (in Deutschland 0711-62 87 12)
GERMANY
Work like you don't need the money.
Love like you've never been hurt.
Dance like nobody is watching.
Java Sound Resources (examples, FAQ, applications):
http://www.jsresources.org/
Tritonus, the open source implementation of the Java Sound API:
http://www.tritonus.org/
--
___
kaffe mailing list
[EMAIL PROTECTED]
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[Fwd: Re: [kaffe] libtritonusalsa does not get installed]
Resending because it didn't get through presumably because the attached
config.log was too big (300 K). If you need config.log, please tell me
and I'll send it directly.
Matthias
Original Message
Subject: Re: [kaffe] libtritonusalsa does not get installed
Date: Sun, 18 Jan 2004 22:33:52 +0100
From: Matthias Pfisterer [EMAIL PROTECTED]
To: Kaffe [EMAIL PROTECTED]
References: [EMAIL PROTECTED] [EMAIL PROTECTED]
[EMAIL PROTECTED] [EMAIL PROTECTED]
Dalibor Topic wrote:
Hallo Matthias,
Matthias Pfisterer wrote:
First the no target all in po that was reported recently. I edited
the top-level Makefile to remove po from SUBDIRS as suggested.
This should be fixed now [1]. Could you do a fresh check out from CVS
and retry?
Yes, I can confirm that it's fixed. Thanks. However, the problem below
remains.
Now I get the following:
--
Making all in libraries/javalib
make[1]: Entering directory
`/home/matthias/java/kaffe/libraries/javalib'
rm -rf lib
mkdir lib
/bin/sh ./rebuildLib @essential.files
Compiling classes from @essential.files using
/home/matthias/java/kaffe/kaffe/kaffe/kaffe-bin -verbosegc -mx 256M
at.dms.kjc.Main
[ start compilation in verbose mode ]
[ parsed gnu/classpath/Configuration.java in 486 ms ]
./rebuildLib: line 58: 15924 Segmentation fault $JAVAC $VERBOSE
$JAVAC_FLAGS -d $LIBDIR $CPATH ${1+$@}
make[1]: *** [lib/stamp] Error 139
make[1]: Leaving directory `/home/matthias/java/kaffe/libraries/javalib'
make: *** [all-recursive] Error 1
--
This is for ./configure without opions. If I say './configure
--without-alsa', the following happens:
--
make[1]: Entering directory
`/home/matthias/java/kaffe/libraries/javalib'
rm -rf lib
mkdir lib
/bin/sh ./rebuildLib @essential.files
Compiling classes from @essential.files using
/home/matthias/java/kaffe/kaffe/kaffe/kaffe-bin -verbosegc -mx 256M
at.dms.kjc.Main
[ start compilation in verbose mode ]
[ parsed gnu/classpath/Configuration.java in 471 ms ]
--
...and it hangs, hogging the CPU. It is interruptible with ctrl-C.
Interesting bugs, definitely. I'd be more interested in the crash, atm.
Do the problems still occur with the current version from CVS HEAD? If
so, what's your cpu-os platform (or distribution, of you are using
linux), and which gcc are you using? Are there any interesting warnings
during compilation?
I investigated this further by trying old cvs versions. I can reproduce
the problem with versions of 12th, 13th and 15th (haven't tried in
between). With the version of 10th, the build runs smooth. With the
version of 11th, there is an unrelated error about TAudioInputStream
missing, but it seems to get beyond the point of the error. So
presumably, the problem was introducd between 11th and 12th. In each
case, I did a fresh checkout with
cvs -z3 -d :pserver:[EMAIL PROTECTED]:/cvs/kaffe co -D 2004-01-11
kaffe
(and the appropriate date, of course). Then I issued './configure' (no
params) and 'make'.
My system is Linux on a x86, distribution is Debian stable. The gcc
version is 2.95.4. Does it make sense to try with a different version of
gcc?
I haven't detected something obviously wrong during the build. I'm
attaching config.log (produced with the CVS of today (18th).
Matthias
--
Matthias Pfisterer mailto:[EMAIL PROTECTED]
Reuchlinstrasse 28 phone ++49-711-62 87 12
D-70176 Stuttgart (in Deutschland 0711-62 87 12)
GERMANY
Work like you don't need the money.
Love like you've never been hurt.
Dance like nobody is watching.
Java Sound Resources (examples, FAQ, applications):
http://www.jsresources.org/
Tritonus, the open source implementation of the Java Sound API:
http://www.tritonus.org/
--
___
kaffe mailing list
[EMAIL PROTECTED]
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] javac
Minh Nguyen wrote: Hi, Can someone show me the source code of parser and code generator for javac? Do they belong to the kernel or the java library? kaffe uses kjc as a compiler. See http://www.dms.at/kopi/index.html Matthias -- Matthias Pfisterer mailto:[EMAIL PROTECTED] Reuchlinstrasse 28 phone ++49-711-62 87 12 D-70176 Stuttgart (in Deutschland 0711-62 87 12) GERMANY Work like you don't need the money. Love like you've never been hurt. Dance like nobody is watching. Java Sound Resources (examples, FAQ, applications): http://www.jsresources.org/ Tritonus, the open source implementation of the Java Sound API: http://www.tritonus.org/ -- ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] generic collections
Dalibor Topic wrote: Hallo Matthias, Matthias Pfisterer wrote: Hi, I asked this before, but perhaps it was burried to deep into another mail: Sorry I didn't have time to reply earlier, I was buried in a maze of build system problems ;) Yea, I'm already wondering: are you working 24 hours a day for kaffe? how and when will kaffe handle the transition to a version of the collection framework that uses generics? I don't believe that there is much we can do before the JDK 1.5 API specs are really released. We can only guess what will be in the JDK 1.5 APIs at the time being [1]. Well, in general you're right. There is a early access version of the JDK 1.5.0 (from java.sun.com) without docs. In the case of generics, the list of affected classes in the collection and reflection APIs has long been published as part of the public review draft of JSR-14 (http://jcp.org/aboutJava/communityprocess/review/jsr014/index.html). The license allows internal review, but one could arguement that part of an internal review is to check how easy the specification can be implemented by doing some actual coding, as long as the result is not officially released. BTW, the first official beta of the JDK 1.5.0 is expected for end of february. I noticed that kjc can already handle generics. However, the propably bigger problem might be the collection framework. I don't know how well kjc supports generics in the form in which they are supposed to be used in JDK 1.5. I also don't know if there is any development on jikes to support new java language constructs from 1.5. As far as I know, there is some work going on in the gcj camp to support those features in the future. Yes, I just found a bug in kjc's generics support! On the other hand, it is basically working, while I had no success with gcj and jikes. So the first problem, once 1.5 is out, and it becomes clear what the specs demand, will be to make sure the build tools can cope with it. Then we can move on further to actually implement the spec ;) I agree that we have to make sure the tool chain supports generics. But we won't find out and improve the tools without playing with generics. The kjc bug mentioned above is an example of this: I wrote a simple list class to test the generics support and zong! encountered a bug. So I think we have to start implementing generics to get the tools right. Perhapt I would volunteer for the task of recoding the collection framework. That would be great! Check out the Classpath web pages for requirements, and get your paperwork done with the FSF to contribute the code to GNU Classpath. Then all free runtimes (not just kaffe) can profit from your work on reimplementing the collections framework. Ok, I'll do that. Matthias -- Matthias Pfisterer mailto:[EMAIL PROTECTED] Reuchlinstrasse 28 phone ++49-711-62 87 12 D-70176 Stuttgart (in Deutschland 0711-62 87 12) GERMANY Work like you don't need the money. Love like you've never been hurt. Dance like nobody is watching. Java Sound Resources (examples, FAQ, applications): http://www.jsresources.org/ Tritonus, the open source implementation of the Java Sound API: http://www.tritonus.org/ -- ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] libtritonusalsa does not get installed
Dalibor Topic wrote:
Hallo Matthias,
Matthias Pfisterer wrote:
Hi,
I noticed that with the CVS of kaffe (about 3 days old),
libtritonusalsa.so gets compiled and linked to
./libraries/extensions/sound/alsa/.libs/libtritonusalsa.so
but not installed under /usr/local/kaffe.
I did the usual configure - make - make install
libtritonusesd get installed as
/usr/local/kaffe/jre/lib/i386/libtritonusesd.so.
I would expect libtritonus alsa in the same directory, but it isn't.
So I guess this is a bug in the configure/build system. I'm not
exactly good with all this auto* stuff, so can of of the experts
please have a look at it?
Hm, that one sounds quite weird. Could you do a clean checkout from CVS,
and try the whole procedure again? I've only recently added some code
for detecting ALSA and ESounD from their respective CVS repositories, so
now ALSA support doesn't work on my pre 1.0 debian box.
I suspect I found the reason for this phenomenon: configure test if the
version of the ALSA headers is = 1.0.1. As I stil have 1.0.0rc2
installed, this test fails. The impression that libtritonusalsa gets
built, but not installed, may have come from the fact that binaries from
a previous build were laying around, but - obviously - no install action
was taken.
Then I thought I can do a quick hack and modified the version numbers in
/usr/include/alsa/version.h. Ok, now the headers are recognized, but
after a fresh checkout I hit other problems:
First the no target all in po that was reported recently. I edited the
top-level Makefile to remove po from SUBDIRS as suggested.
Now I get the following:
--
Making all in libraries/javalib
make[1]: Entering directory `/home/matthias/java/kaffe/libraries/javalib'
rm -rf lib
mkdir lib
/bin/sh ./rebuildLib @essential.files
Compiling classes from @essential.files using
/home/matthias/java/kaffe/kaffe/kaffe/kaffe-bin -verbosegc -mx 256M
at.dms.kjc.Main
[ start compilation in verbose mode ]
[ parsed gnu/classpath/Configuration.java in 486 ms ]
./rebuildLib: line 58: 15924 Segmentation fault $JAVAC $VERBOSE
$JAVAC_FLAGS -d $LIBDIR $CPATH ${1+$@}
make[1]: *** [lib/stamp] Error 139
make[1]: Leaving directory `/home/matthias/java/kaffe/libraries/javalib'
make: *** [all-recursive] Error 1
--
This is for ./configure without opions. If I say './configure
--without-alsa', the following happens:
--
make[1]: Entering directory `/home/matthias/java/kaffe/libraries/javalib'
rm -rf lib
mkdir lib
/bin/sh ./rebuildLib @essential.files
Compiling classes from @essential.files using
/home/matthias/java/kaffe/kaffe/kaffe/kaffe-bin -verbosegc -mx 256M
at.dms.kjc.Main
[ start compilation in verbose mode ]
[ parsed gnu/classpath/Configuration.java in 471 ms ]
--
...and it hangs, hogging the CPU. It is interruptible with ctrl-C.
Any ideas?
Matthias
--
Matthias Pfisterer mailto:[EMAIL PROTECTED]
Reuchlinstrasse 28 phone ++49-711-62 87 12
D-70176 Stuttgart (in Deutschland 0711-62 87 12)
GERMANY
Work like you don't need the money.
Love like you've never been hurt.
Dance like nobody is watching.
Java Sound Resources (examples, FAQ, applications):
http://www.jsresources.org/
Tritonus, the open source implementation of the Java Sound API:
http://www.tritonus.org/
--
___
kaffe mailing list
[EMAIL PROTECTED]
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] How to change the boot class path?
Thanks, this solution works. Matthias Ito Kazumitsu wrote: In message [kaffe] How to change the boot class path? on 04/01/15, Matthias Pfisterer [EMAIL PROTECTED] writes: for testing, I want to shadow a class in kaffe's rt.jar by a modified version of the same class. I routinly do this with the Sun JDK prepending a .jar file containing the modified version of the class with the -Xbootclasspath/p option. With older versions of kaffe it was possible to achieve the same effect by having a file ~/.kafferc with lines like: -- CLASSPATH=/home/matthias/java/tritonus/dist/tritonus_core.jar:$CLASSPATH -- This no longer seems to work. This is what I do. bash$ cat ~/.kafferc case $MYBOOTCLASSPATH in ) ;; *) BOOTCLASSPATH=$MYBOOTCLASSPATH:$BOOTCLASSPATH ;; esac When I want to use my own classes instead of those in rt.jar, I set the environment variable MYBOOTCLASSPATH. -- Matthias Pfisterer mailto:[EMAIL PROTECTED] Reuchlinstrasse 28 phone ++49-711-62 87 12 D-70176 Stuttgart (in Deutschland 0711-62 87 12) GERMANY Work like you don't need the money. Love like you've never been hurt. Dance like nobody is watching. Java Sound Resources (examples, FAQ, applications): http://www.jsresources.org/ Tritonus, the open source implementation of the Java Sound API: http://www.tritonus.org/ -- ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] libtritonusalsa does not get installed
Hi, I noticed that with the CVS of kaffe (about 3 days old), libtritonusalsa.so gets compiled and linked to ./libraries/extensions/sound/alsa/.libs/libtritonusalsa.so but not installed under /usr/local/kaffe. I did the usual configure - make - make install libtritonusesd get installed as /usr/local/kaffe/jre/lib/i386/libtritonusesd.so. I would expect libtritonus alsa in the same directory, but it isn't. So I guess this is a bug in the configure/build system. I'm not exactly good with all this auto* stuff, so can of of the experts please have a look at it? Thanks, Matthias -- Matthias Pfisterer mailto:[EMAIL PROTECTED] Reuchlinstrasse 28 phone ++49-711-62 87 12 D-70176 Stuttgart (in Deutschland 0711-62 87 12) GERMANY Work like you don't need the money. Love like you've never been hurt. Dance like nobody is watching. Java Sound Resources (examples, FAQ, applications): http://www.jsresources.org/ Tritonus, the open source implementation of the Java Sound API: http://www.tritonus.org/ -- ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Java Sound / ALSA code updated
Dalibor Topic wrote: Hallo Matthia, Matthias Pfisterer wrote: Hi, I updated the Tritonus (Java Sound API implementation) code in the upstream CVS to compile with the ALSA 1.0 API. I would suggest to take over these changes into kaffe. Wow, thanks a lot for the kind reminder! I really appreciate maintainers of the upstream projects we use the code from pointing us to new, mergeworthy features. Ok, so I'll keep this habit. By the way, are there any outstanding issues with respect to the Java Sound code from your perspective? Are there reports from users trying to use it in kaffe? I tried to do some tests, but didn't manage to build the latest kaffe cvs (well, messed up my system). And just another question: when/how will handle kaffe the transition to generics? I noticed that kjc can already handle this. But the bigger problem seems the adaption of the collection classes. One new interface in the 1.5 version of the Java Sound API needs MapString, Object. I want to make sure this is available in kaffe before I update my code. Matthias -- Matthias Pfisterer mailto:[EMAIL PROTECTED] Reuchlinstrasse 28 phone ++49-711-62 87 12 D-70176 Stuttgart (in Deutschland 0711-62 87 12) GERMANY Work like you don't need the money. Love like you've never been hurt. Dance like nobody is watching. Java Sound Resources (examples, FAQ, applications): http://www.jsresources.org/ Tritonus, the open source implementation of the Java Sound API: http://www.tritonus.org/ -- ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] Java Sound / ALSA code updated
Hi, I updated the Tritonus (Java Sound API implementation) code in the upstream CVS to compile with the ALSA 1.0 API. I would suggest to take over these changes into kaffe. Matthias -- Matthias Pfisterer mailto:[EMAIL PROTECTED] Reuchlinstrasse 28 phone ++49-711-62 87 12 D-70176 Stuttgart (in Deutschland 0711-62 87 12) GERMANY Work like you don't need the money. Love like you've never been hurt. Dance like nobody is watching. Java Sound Resources (examples, FAQ, applications): http://www.jsresources.org/ Tritonus, the open source implementation of the Java Sound API: http://www.tritonus.org/ -- ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] bug: java.awt.Component.getComponentOrientation() is missing
Hi,
subject say it all...
Here is an example program:
--(ComponentOrientationTest.java)--
import java.awt.Component;
import java.awt.ComponentOrientation;
import java.awt.Label;
public class ComponentOrientationTest
{
public static void main(String[] args)
{
Component c = new Label();
ComponentOrientation co = c.getComponentOrientation();
}
}
The error I get is:
/usr/local/kaffe/bin/javac ComponentOrientationTest.java
ComponentOrientationTest.java:10: error:Cannot find method
java.awt.Component.getComponentOrientation()
This error does not happen with javac of the Sun JDK 1.4.2.
Matthias
--
Matthias Pfisterer mailto:[EMAIL PROTECTED]
Reuchlinstrasse 28 phone ++49-711-62 87 12
D-70176 Stuttgart (in Deutschland 0711-62 87 12)
GERMANY
Work like you don't need the money.
Love like you've never been hurt.
Dance like nobody is watching.
Java Sound Resources (examples, FAQ, applications):
http://www.jsresources.org/
Tritonus, the open source implementation of the Java Sound API:
http://www.tritonus.org/
--
___
kaffe mailing list
[EMAIL PROTECTED]
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] bug: class java.awt.KeyboardFocusManager is missing
Matthias -- Matthias Pfisterer mailto:[EMAIL PROTECTED] Reuchlinstrasse 28 phone ++49-711-62 87 12 D-70176 Stuttgart (in Deutschland 0711-62 87 12) GERMANY Work like you don't need the money. Love like you've never been hurt. Dance like nobody is watching. Java Sound Resources (examples, FAQ, applications): http://www.jsresources.org/ Tritonus, the open source implementation of the Java Sound API: http://www.tritonus.org/ -- ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Kaffe 1.1.3 and ALSA 1.0.0rc2
Dalibor Topic wrote: Hi Jason, I've checked in a patch from Bero from ArkLinux to fix that after 1.1.3 was released. See http://www.kaffe.org/pipermail/kaffe/2003-December/044645.html for the patch. That's what I would suggest as a short-term solution, too. (I'm the upstream maintainer of the Java Sound API code). I just noticed this issue yesterday. In the following weeks, I'll adapt the code to ALSA 1.0. Matthias -- Matthias Pfisterer mailto:[EMAIL PROTECTED] Reuchlinstrasse 28 phone ++49-711-62 87 12 D-70176 Stuttgart (in Deutschland 0711-62 87 12) GERMANY Work like you don't need the money. Love like you've never been hurt. Dance like nobody is watching. Java Sound Resources (examples, FAQ, applications): http://www.jsresources.org/ Tritonus, the open source implementation of the Java Sound API: http://www.tritonus.org/ -- ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] kjc compiler bug?
Hi,
I found a language construct where the behaviour of kjc differs from the
behaviour of Sun's javac and jikes:
-- OuterSuper.java --
public class OuterSuper
extends Object
{
public OuterSuper(Object obj )
{
super();
}
public class InnerSuper
extends Object
{
}
}
-- OuterSub.java --
class OuterSub
extends OuterSuper
{
public OuterSub(Object obj )
{
super(obj);
}
protected class InnerSub
extends OuterSuper.InnerSuper
{
protected InnerSub()
{
OuterSub.this.super(); // --- the line for which an error
is reported
}
}
}
jikes -classpath /usr/local/j2sdk1.4.2/jre/lib/rt.jar OuterSub.java
OuterSuper.java
/usr/local/j2sdk1.4.2/bin/javac OuterSub.java OuterSuper.java
/usr/local/kaffe/bin/javac OuterSub.java OuterSuper.java
OuterSub.java:15: error:Invalid method name [JLS 15.12]
/usr/local/j2sdk1.4.2/bin/java -version
java version 1.4.2_02
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_02-b03)
Java HotSpot(TM) Client VM (build 1.4.2_02-b03, mixed mode)
jikes
Jikes Compiler
(C) Copyright IBM Corp. 1997, 2001.
- Licensed Materials - Program Property of IBM - All Rights Reserved.
[...]
Version 1.15 - 26 Sept 2001
Originally written by Philippe Charles and David Shields
of IBM Research, Jikes is now maintained and refined by the
Jikes Project at:
http://ibm.com/developerworks/opensource/jikes
Please consult this URL for more information and to learn
how to report problems.
/usr/local/kaffe/bin/javac -V
Version 2.1A released 11. February 2002
javac and jikes do not report an error, but kjc does. May it be that
this is a bug in kjc?
Please CC' me in replies, I'm not subscribed to the mailing list. Thanks
Matthias
--
Matthias Pfisterer mailto:[EMAIL PROTECTED]
Reuchlinstrasse 28 phone ++49-711-62 87 12
D-70176 Stuttgart (in Deutschland 0711-62 87 12)
GERMANY
Work like you don't need the money.
Love like you've never been hurt.
Dance like nobody is watching.
Java Sound Resources (examples, FAQ, applications):
http://www.jsresources.org/
Tritonus, the open source implementation of the Java Sound API:
http://www.tritonus.org/
--
___
kaffe mailing list
[EMAIL PROTECTED]
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] Re: [tritonus-user] Tritonus on kaffe
Matthias Pfisterer wrote: Dalibor Topic wrote: My other problem is that libtritonusalsa needs javah to run on some Alsa* inner classes. I can't seem to get the $-character properly quoted in the Makefile.am file, and I'm not even sure kaffe's javah properly supports them anyway. If the inner classes could be moved into proper classes of their own, that would let me add support for ALSA in a much easier fashion. Removing these inner classes is on the TODO list, too. I noticed that there is no real benefit from using inner classes. Data hiding has to be violated anyway. (For instance, m_lNativeHandle in AlsaPcm.HWParams has to be package visible instead of private.) So I agree to changing the inner classes. Please tell me if this is high priority. (And I think the bug in javah has to be fixed anyway.) I've fixed this now, too. You have to update the following directories: - src/lib/alsa - src/org/tritonus/lowlevel/alsa - src/org/tritonus/sampled/mixer/alsa As my system currently is only partly working, I wasn't able to check if Tritonus still runs with the changes. I was only able to compile and link. Maybe I forgot to change some method name, which will be detected at run-time. So if you get obscure problems, it may well be my fault. Matthias -- Matthias Pfisterer mailto:[EMAIL PROTECTED] Reuchlinstrasse 28 phone +49-711-62 87 12 D-70176 Stuttgart GERMANY Java Sound Examples: http://www.jsresources.org/examples/ Java Sound Programmer's FAQ: http://www.jsresources.org/faq/ Tritonus, the open source implementation of the Java Sound API: http://www.tritonus.org/ -- ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Re: [tritonus-user] Tritonus on kaffe
Dalibor Topic wrote: --- Stuart Ballard [EMAIL PROTECTED] wrote: Dalibor Topic wrote: My current code fits it into kaffe's auto* tools based build as en extension library, adds a configure option for the sound backend to use, compiles the java libraries, and links the C++ libraries accordingly. Ouch, a configure option for the sound backend? Isn't that going to make life hard on distributors like Debian, who don't force their users into a single sound system? Will they need to build multiple versions of Kaffe depending on which sound backend is desired? Wouldn't some way of doing it at runtime be preferable? Currently, I've only got esd to work, so there is not much choice anyway: esd, or no sound at all. ;) there are a few reasons why I think a sound backend option makes sense: a) native sound libraries are written in C++. We shouldn't require having a C++ compiler in order to build kaffe, as that would make porting to systems like minix even harder. So there should be a convenient way to tell the configure script that we don't want to bother with it. Should be solved now: no more C++. b) In order to compile kaffe with sound support, you need libesound and esd.h. Many linux distributions don't install libesound development files by default. I wouldn't want to force people to install a few sound RPMs just because they want to use kaffe for XML processing, for example. So the default option for sound in my patch is no. c) It mirrors the current situation with AWT backends. You can only have either Xlib, Qt or no awt at all at the same time. Changing that would require a significant rewrite of kaffe's java AWT libraries, I think. That would be good to have, though, as it would in theory allow us to run those nice 3rd party AWT implementations like PureJavaAWT. d) I'm not sure if it is possible to have several different MixerProviders in tritonus simultaneously. Matthias, do you know if that works? If so, then it shouldn't be hard to add other backends, i.e. ALSA by just adding its class file name to META-INF/services/javax.sound.sampled.spi.MixerProvider It would be pointless at the moment as the native libs for ALSA don't compile on kaffe, due to some problems with kaffeh (and me not being able to tell automake to quote $ in the Makefile.am). I'll better try to post some code tonight, so you guys have something to play with. I have to write up a massive ChangeLog entry first ... Hi, both compile-time and run-time switches do make sense and should be present. To start with the run-time ones: The configuration system of Java Sound works by scanning the class paths (boot, extension, user) for configuration files like META-INF/services/javax.sound.sampled.spi.MixerProvider. This is done using the method Classloader.findResources(String). Note that it's 'Resources', no 'Resource', so multiple entries can be found. For all configuration files found, the file is read. Classes mentioned in the configuration file are instantiated with Class.forName(). All classes of one type of configuration file form an ordered list of Service Providers of the respective type. This leads to the practice of packaging (for instance) a Mixer implementation together with a configuration file naming just this Service Provider. The resulting .jar file can just be added to or removed from the class path. This is why Tritonus routinely builds 10+ jar files: one for esd, one for ALSA, one for standard audio file readers and writers, one for the GSM codec, and so on. In theory, it is possible to have any number of service providers of the same type. For mixer providers, there is an obvious restriction: It can't work if multiple mixer implementations compete for exclusive hardware access. Compile-time configuration: this is useful for the reasons stated above: not forcing too much build dependencies. There should be either an option like --with-sound-backend=esd,also,... (multiple entries should be possible) or an automatic detection of available libraries that can be linked against. Distributions could be broken in packages as it is common for sound programs with different backends: vlc vlc-alsa vlc-arts vlc-esd xmms xmms-alsa ... ... where the vlc-* packages only contain the plug-ins (Java Sound speak: 'service providers'). Matthias -- Matthias Pfisterer mailto:[EMAIL PROTECTED] Reuchlinstrasse 28 phone +49-711-62 87 12 D-70176 Stuttgart GERMANY Java Sound Examples: http://www.jsresources.org/examples/ Java Sound Programmer's FAQ: http://www.jsresources.org/faq/ Tritonus, the open source implementation of the Java Sound API: http://www.tritonus.org/ -- ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] Re: [tritonus-user] Tritonus on kaffe
Dalibor Topic wrote: --- Matthias Pfisterer [EMAIL PROTECTED] wrote: It is no longer necessary to build a library in ../common/. I'm now linking the (single, small) object file to any library in the other directories. This is to simplify installation. You could turn the helper functions in common.c into static __inline__ functions in common.h. Then you would not have to link anything accross directories. Ok, but doesn't that mean that there will be one object code instance per source file instead of one per library? It won't matter for esd with now only two source files. But for ALSA with 20+ source files, it may make a noticable difference. The cooked_ioctl directory contains code to read CDs using the Linux cooked ioctl interface. As it is superseeded by the cdparanoia based implementation, it is no longer maintained. I keep it as an example of how to structure simple CDDA reading on other operating systems. Yeah, I'll leave mp3 out for all the good reasons. Jorbis might be interesting, but I haven't played extensively with it yet. I think having gorbis as the default Ogg provider, and Jorbis as second choice if the ogg tools don't work would be the way to go for kaffe, when I've merged in the basic functionality. Jogg/Jorbis are pure java, so they will work even if no additional native libraries are installed. There is already a Java Sound service provider (think of it as some sort of a wrapper layer) for Jorbis. It has a minor problem with thread safety, but I will fix this and include this, too. The reason for dealing with native stuff for ogg vorbis at all is that Jorbis only covers the decoder. For using an encoder, the C libraries are the only choice. So I think it's rather the Jorbis based service provider that should be the default and gsorbis the option. At least this seems appropriate when detecting the build configuration. If both are present, it can still be debated which implementation to choose at run-time (for decoding). The run-time configuration system of Java Sound is flexible enough to separate between decoding and encoding. (More details later) Matthias -- Matthias Pfisterer mailto:[EMAIL PROTECTED] Reuchlinstrasse 28 phone +49-711-62 87 12 D-70176 Stuttgart GERMANY Java Sound Examples: http://www.jsresources.org/examples/ Java Sound Programmer's FAQ: http://www.jsresources.org/faq/ Tritonus, the open source implementation of the Java Sound API: http://www.tritonus.org/ -- ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] Re: [tritonus-user] Tritonus on kaffe
Dalibor Topic wrote: Hallo Matthias, --- Matthias Pfisterer [EMAIL PROTECTED] wrote: My fix for this is to use libtool from current CVS and upgrade out build scripts to latest auto* tools. There are some issues in going that way, mainly increasing the bar for build system developers, and having to fix all the bugs in the build scripts exposed by the upgrade. Of course, if the libraries could be switched to plain old C, that would make my life much easier, I hope. What is the HandleFieldHandler class used for? I've switched back to C in the directories src/lib/esd, src/lib/alsa, src/lib/common and src/lib/cdparanoia. This should do it for the moment. Note that the inner class issue with the ALSA classes is still pending. It is no longer necessary to build a library in ../common/. I'm now linking the (single, small) object file to any library in the other directories. This is to simplify installation. The cooked_ioctl directory contains code to read CDs using the Linux cooked ioctl interface. As it is superseeded by the cdparanoia based implementation, it is no longer maintained. I keep it as an example of how to structure simple CDDA reading on other operating systems. gsvorbis contains an incomplete interface to the ogg vorbis encoder. It is not assumed to work. lame contains, well, an interface to LAME, an mp3 encoder. I suggest to leave it out. All open source implementations of mp3 encoders are illegal, as well as all open source implementations of mp3 decoders. We keep it because it is requested quite often and no open source developer or entity was sued so far. But I think it's best to not proliferate it further. ogg vorbis is a viable alternative gaining market share rapidly, and of better quality. The only drawback is that it is not yet integreted into Java Sound. And I've deleted the saint directory from the cvs, since it was all legacy. Ah, the HandleFieldHandler: all low level classes need to keep some handle to some native facility. For esd, it is the file descriptor of the socket connection to the esd server. For ALSA, it is some pointer of type snd_pcm_t* or snd_seq_t*. These handles are stored in instance variables of the JNI classes. Looking into the Java code, you will see members 'private long m_lNativeHandle' or similar. These are used by the native code to store the handles. They are long in Java, because in the future, the native word size or the size of pointers will become 64 bit. It is the code to access these Java fields from the native code that I have generalized in the former C++ class HandleFieldHandler. Now -- after the change to C -- there is a header file src/lib/common/HandleFieldHandler.h that contains C macros to do almost the same. MidiShare is a low-level MIDI API. In theory, it is quite portable. It evolved on Macintosh and has also versions for Windows and Linux. I was not very happy with it. The windows version only worked for 16bit Windows (including Win95, but not WinNT, Win2000, etc.). This is an old state, perhaps newer versions have evolved. But the main reason I didn't deal with it is that it is not comparative to ALSA's MIDI and sequencing facilities. Plus, I think, some personal taste on API design. You can get more information on MidiShare at http://www.grame.fr/MidiShare/ their web site mentions new versions for Win 200 OS X , so it might be worth a try. I'll see if I can get it to work. The Person that implemented the MidiShare support in Tritonus was Stephane Letz. I haven't heard from him for a while. However, he is still subscribed to the tritonus-devel list (note that I moved the discussion there). You can also contact him directly with letz [at] grame.fr Matthias -- Matthias Pfisterer mailto:[EMAIL PROTECTED] Reuchlinstrasse 28 phone +49-711-62 87 12 D-70176 Stuttgart GERMANY Java Sound Examples: http://www.jsresources.org/examples/ Java Sound Programmer's FAQ: http://www.jsresources.org/faq/ Tritonus, the open source implementation of the Java Sound API: http://www.tritonus.org/ -- ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
