Hi,
atatched is a preliminary patch for
CharacterProperties issues we have with xsmiles 0.5.It
also lets me build kaffe on linux i386 with jit3,
enable-debug and xdebug that passes all make check
tests. Please give it a try and tell me if it breaks
something for you.
have fun,
dalibor topic
__
CVSROOT:/cvs/kaffe
Module name:kaffe
Changes by: dalibor 02/04/25 18:07:00
Modified files:
. : ChangeLog
Log message:
documentation updates and a bugfix in java.util.zip.ZipFile
___
kaffe mailing list
[EMAIL PRO
CVSROOT:/cvs/kaffe
Module name:kaffe
Changes by: dalibor 02/04/25 18:05:10
Modified files:
. : WHATSNEW
Log message:
updated kjc entry.
___
kaffe mailing list
[EMAIL PROTECTED]
http://kaffe.org/cgi-bin/mailman/l
CVSROOT:/cvs/kaffe
Module name:kaffe
Changes by: dalibor 02/04/25 18:05:47
Modified files:
FAQ: FAQ.classlibrary-compile
Log message:
updated compiler information
___
kaffe mailing list
[EMAIL PROTECTED]
http://k
CVSROOT:/cvs/kaffe
Module name:kaffe
Changes by: dalibor 02/04/25 18:04:51
Modified files:
libraries/javalib/java/util/zip: ZipFile.java
Log message:
throw NullPointerException if ZipEntry parameter is null.
___
kaffe mailin
Timothy Stack writes:
> The problem is that kaffe uses the stack to keep track of locks/unlocks,
> so something like:
>
> synchronized( lock )
> {
> synchronized( lock )
> {
> }
> }
>
> will break because the top of the stack doesn't change between the first
> and second lock.
> Hi Tim,
>
> --- Timothy Stack <[EMAIL PROTECTED]> wrote:
> > it seems silly to not just go all the way. Also, it
> > wouldn't fix any
> > problems the stack approach has with optimizations
> > (delayed pop and
> > so on).
>
> could you elaborate a little on those problems?
google for "godmar
Hi Tim,
--- Timothy Stack <[EMAIL PROTECTED]> wrote:
> it seems silly to not just go all the way. Also, it
> wouldn't fix any
> problems the stack approach has with optimizations
> (delayed pop and
> so on).
could you elaborate a little on those problems?
thanks,
dalibor topic
__
> > will break because the top of the stack doesn't change between the first
> > and second lock. Therefore, the first unlock will completely free the
> > lock since the vm can't tell the difference between the two. So, other
> > than pushing something on the stack on every synchronized, i don't
hi,
> Hi,
>
> I have possible bug report with threading and nested locks.
its definitely a bug.
> When two threads are nested on the same lock and one (or both) of
> them sleeps inside the nest, an IllegalMonitorStateException will be
> thrown. The lock in question is allocated as a fast l
>
> Also, is there a good reason why we don't allow zero-length mallocs?
>
Yes. Because they're usually indicative of some bogosity or
some condition that should be flagged or handled somehow else,
or even worse bugs.
This assertion (size!=0) has already detected numerous such cases.
Hi,
I have possible bug report with threading and nested locks.
When two threads are nested on the same lock and one (or both) of
them sleeps inside the nest, an IllegalMonitorStateException will be
thrown. The lock in question is allocated as a fast lock, however,
when the sleep method is ca
> But, i also tried it in janosvm's newer jar file code, but
> it doesn't like the format of the file, the size of the central
> directory didn't match the number of entries. This may or may not be a
> problem for kaffe as well. What did you use to make the jar file?
ops, ignore this, i made a
hi,
> Hi Dalibor,
> Am sending a test program that results in the same assertion problem.
> The test program takes a jar file location, reads contents from each file in
> the jar and prints the same to standard output. It uses ZipFile and ZipEntry
> classes present in java.util.zip.* pkg.
>
> A
--- Dalibor Topic <[EMAIL PROTECTED]> wrote:
> Hi Patrick
>
> On Wednesday, 24. April 2002 07:50, Patrick Tullmann
> wrote:
> > If anyone's interested in doing more comprehensive
> regression testing
> > of Kaffe, I've attached a script which will
> configure, compile, build
> > Klasses, install
Hi Dalibor,
Am sending a test program that results in the same assertion problem.
The test program takes a jar file location, reads contents from each file in
the jar and prints the same to standard output. It uses ZipFile and ZipEntry
classes present in java.util.zip.* pkg.
Attachments :
Test.ja
On Wed, 24 Apr 2002, Patrick Tullmann wrote:
> This is a new one to me... what os/hardware are you running on? Ah,
> maybe you're using a more recent gcc?
[jsantala@yavin jsantala]$ uname -a
Linux yavin.tml.hut.fi 2.4.18 #2 Wed Apr 10 13:57:52 EEST 2002 i686
unknown
[jsantala@yavin jsantala]$
On Wed, 24 Apr 2002, Timothy Stack wrote:
> The last sentence is the important part, basically, if you don't care
> about not getting any of the samples taken between the start of main() and
> the initialization of xprof, its no big deal. Actually, i would imagine
> the data is still available in
18 matches
Mail list logo
