sablevm-developer

[Sablevm-developer] Pushing newer SableVM to testing (current sarge version is broken)

[Grzegorz B. P. <ga...@de...>]

tags 215314 fixed
close 215314
tags 230770 pending
tags 230770 sarge
thanks

Spoiler: classpath from SVN went into testing thus broke old sablevm
Solution: letting unstable version go into testing

Months ago, when I created SableVM Debian packages I assumed that
sablevm package of version ex. 1.0.9 should use classpath from
range 1.0.9 <= X < 1.0.10. This would prevent migration to testing
of unmatching sablevm/classlib. However recently I uploaded SableVM
and its Classpath Debian pacakages in version like 1.0.9+svnXXXXXX
which is still less "<" than 1.0.10. Thus it went into testing
w/o me noticing.

Therefore the only solution is to let unstable version go into testing
which was planeed to happen in a few days anyway, after the version,
that is currently held in NEW queue (and requires ftpmasters
intervention) is let into unstable.

Please keep in mind, that current unstable version has some minor
problems, but they're still much, much smaller than not working,
old 1.0.9 version.

To solve the problem now - please pull SableVM packages from unstable.

HTH

				Grzegorz B. Prokopski

-- 
Grzegorz B. Prokopski <ga...@de...>
Debian GNU/Linux      http://www.debian.org
SableVM - LGPLed JVM  http://www.sablevm.org
Why SableVM ?!?       http://devel.sablevm.org/wiki/WhySableVM

[Sablevm-developer] Re: Pushing newer SableVM to testing (current sarge version is broken)

[James D. <jd...@ny...>]

On Mon, 2004-02-02 at 22:01, Grzegorz B. Prokopski wrote:
> tags 215314 fixed
> close 215314
> tags 230770 pending
> tags 230770 sarge
> thanks
> 
> Spoiler: classpath from SVN went into testing thus broke old sablevm
> Solution: letting unstable version go into testing
> 
> Months ago, when I created SableVM Debian packages I assumed that
> sablevm package of version ex. 1.0.9 should use classpath from
> range 1.0.9 <= X < 1.0.10. This would prevent migration to testing
> of unmatching sablevm/classlib. However recently I uploaded SableVM
> and its Classpath Debian pacakages in version like 1.0.9+svnXXXXXX
> which is still less "<" than 1.0.10. Thus it went into testing
> w/o me noticing.

Thanks for the reply.  If this is the umpteenth time you've made it, I
apologize... I haven't been following Free Java for very long.
> 
> Therefore the only solution is to let unstable version go into testing
> which was planeed to happen in a few days anyway, after the version,
> that is currently held in NEW queue (and requires ftpmasters
> intervention) is let into unstable.
> 
> Please keep in mind, that current unstable version has some minor
> problems, but they're still much, much smaller than not working,
> old 1.0.9 version.
> 
> To solve the problem now - please pull SableVM packages from unstable.

I am loath to pull from unstable, and I don't need a working SableVM for
some time, so I'll simply wait for the next version to migrate to
testing.  Thank you very much for your good work.  I'm looking forward
to trying to use SableVM to run my project (MegaMek) on Debian.

> 
> HTH
> 
> 				Grzegorz B. Prokopski
> 
> -- 
> Grzegorz B. Prokopski <ga...@de...>
> Debian GNU/Linux      http://www.debian.org
> SableVM - LGPLed JVM  http://www.sablevm.org
> Why SableVM ?!?       http://devel.sablevm.org/wiki/WhySableVM
> 

[Sablevm-developer] Re: Pushing newer SableVM to testing (current sarge version is broken)

[Grzegorz B. P. <ga...@de...>]

W liście z pon, 02-02-2004, godz. 23:06, James Damour pisze: 
> Thanks for the reply.  If this is the umpteenth time you've made it, I
> apologize... I haven't been following Free Java for very long.
nope, not at all. thanks for the bugreport. I didn't realize sablevm
in testing broke.

> I am loath to pull from unstable, and I don't need a working SableVM for
> some time, so I'll simply wait for the next version to migrate to
> testing.  Thank you very much for your good work.  I'm looking forward
> to trying to use SableVM to run my project (MegaMek) on Debian.
cd /tmp
wget http://gadek.debian.net/sablevm-unofficial/sablevm-alldebs.tgz
tar zxvf ./sablevm-alldebs.tgz
dpkg -i *.deb

I looked at update excuses and estimate it will take *at least* a week
for new version to get in testing. Even if I set priority "high"
- it has to be built on all arches first. And even if autobuilders
do their work right - there are still some problems ex. w/ jikes.
Ah, and ftpmasters still hold sablevm in NEW now...

So you'd better try the above debs ;-)

Cheers,

				Grzegorz B. Prokopski

-- 
Grzegorz B. Prokopski <ga...@de...>
Debian GNU/Linux      http://www.debian.org
SableVM - LGPLed JVM  http://www.sablevm.org
Why SableVM ?!?       http://devel.sablevm.org/wiki/WhySableVM

[Sablevm-developer] Bug#231366: Serialization in SableVM

[Grzegorz B. P. <ga...@de...>]

Package: sablevm:
Version: 1.0.9+svn20040120-2
Tags: pending, upstream
Submitter: James Damour <jd...@ny...>

W li=B6cie z czw, 05-02-2004, godz. 14:33, James Damour pisze:=20
> The serialization is a bit harder.  The last few lines of the verbose
> output (I *think* that these are the important ones) are:
> [verbose class: loading "java/io/ObjectOutputStream"]
> [verbose class: loading "java/io/ObjectOutput"]
> [verbose class: loading "java/io/ObjectStreamConstants"]
> [verbose class: loading "java/io/CharArrayWriter"]
> [verbose class: loading "java/io/StringWriter"]
> [verbose class: loading "java/io/ByteArrayInputStream"]
> [verbose class: loading "java/io/StreamTokenizer"]
> [verbose class: loading "java/io/PushbackReader"]
> [verbose class: loading "java/io/FilterReader"]
> [verbose class: loading "java/lang/Double"]
> [verbose class: loading "megamek/common/Terrain"]
> [verbose class: loading "megamek/common/Coords"]
> [verbose class: loading "megamek/common/Building"]
> [verbose class: loading "java/util/Vector$1"]
> [verbose class: loading "megamek/common/BoardEvent"]
> [verbose class: loading "java/util/EventObject"]
> [verbose class: loading "megamek/common/InfernoTracker"]
> [verbose class: loading "megamek/common/RoundUpdated"]
> [verbose class: loading "megamek/common/InfernoTracker$Inferno"]
> [verbose class: loading "gnu/java/io/ObjectIdentityWrapper"]
> [verbose class: loading "java/io/ObjectStreamClass"]
> [verbose class: creating "[Ljava/lang/reflect/Method;"]
> [verbose class: loading "java/io/ObjectStreamField"]
> [verbose class: creating "[Ljava/io/ObjectStreamField;"]
> [verbose class: loading "gnu/java/io/NullOutputStream"]
> [verbose class: loading "java/io/InterfaceComparator"]
> [verbose class: loading "java/io/MemberComparator"]
> [verbose class: creating "[Ljava/io/ObjectOutputStream;"]
> [verbose class: loading "java/lang/reflect/Proxy"]
> [verbose class: creating "[Ljava/lang/reflect/Proxy;"]
> [verbose class: loading "java/io/Externalizable"]
> [verbose class: creating "[Ljava/io/Externalizable;"]
> [verbose class: creating "[Ljava/io/Serializable;"]
> [verbose class: creating "[Ljava/lang/reflect/Field;"]
> [verbose class: loading "gnu/java/lang/reflect/TypeSignature"]
> [verbose class: loading "megamek/common/He"]
> [verbose class: loading "java/io/ObjectStreamException"]
> [verbose class: loading "java/io/IOException"]
> [verbose class: creating "[Ljava/lang/StackTraceElement;"]
> [verbose class: loading "java/lang/Throwable$StaticData"]
> java.lang.ClassNotFoundException: megamek.common.He
>    at gnu.java.lang.SystemClassLoader.findClass
> (SystemClassLoader.java:79)
>    at java.lang.ClassLoader.loadClass (ClassLoader.java:327)
>    at java.lang.ClassLoader.createArray (ClassLoader.java:369)
>    at java.lang.VirtualMachine.createArray (VirtualMachine.java:102)
>    at java.lang.reflect.Field.nativeGetType (Field.java)
>    at java.lang.reflect.Field.getType (Field.java:175)
>    at java.io.ObjectStreamClass.setFields (ObjectStreamClass.java:557)
>    at java.io.ObjectStreamClass.ObjectStreamClass
> (ObjectStreamClass.java:465)
>    at java.io.ObjectStreamClass.lookupForClassObject
> (ObjectStreamClass.java:99)   at java.io.ObjectOutputStream.writeObject
> (ObjectOutputStream.java:282)
>    at megamek.test.xml.TestBoardEncoder.main (TestBoardEncoder.java:80)
>    at java.lang.VirtualMachine.invokeMain (VirtualMachine.java)
>    at java.lang.VirtualMachine.main (VirtualMachine.java:88)
> [verbose gc: total gc time =3D 0 sec 0 usec]
>=20
> As you can see, the error comes when I attempt to write an object to th=
e
> ObjectOutputStream.  Several of the members of the object being
> serialized are found without trouble (the Terrain, Coords, Building, an=
d
> other members of megamek.common package), but it dies trying to find th=
e
> class for "megamek.common.He"; please note, there *IS* no
> "megamek.common.He".  There is a megamek.common.Hex, and the object
> being serialized contains an array of Hex, so I *think* that is what
> it's going for.  Is there some way that I can tell for certain?  Should
> I attempt to fire up gdb and step through the sablevm code?  Will that
> even work?  I figure that **this** is the bug that would be most
> interesting to you as a JVM developer.
>=20
> If you don't feel like debugging by remote, I'll be making a new
> snapshot release of my project this weekend, so you could consider
> downloading the project from http://sourceforge.net/projects/megamek an=
d
> running the tests for yourself.  Unlike the recommendations of the
> debian-java list, I include *both* source *and* compiled binaries
> (including third party libraries and a Class-Path entry in the
> MANIFEST), so you can use the code that I compiled.

I believe that serialization is at the moment broken w/ current SableVM
as the object serial no.s have been commented out. It was because of
Sun's javac handling of constans. But decision was made to move these
IDs back anyway. I would like to see it done soon. I'll do this change
in SableVM debian packages.

Not sure if there are any other problems w/ serialization which you
might expect. If it doesn't help - we should ask on GNU Classpath ML.

Or, in fact, you can ask for status of serialization support right now.

HTH

					Grzegorz B. Prokopski


--=20
Grzegorz B. Prokopski <ga...@de...>
Debian GNU/Linux      http://www.debian.org
SableVM - LGPLed JVM  http://www.sablevm.org
Why SableVM ?!?       http://devel.sablevm.org/wiki/WhySableVM

[Sablevm-developer] Bug#231365: undefined symbol: g_thread_init

[Grzegorz B. P. <ga...@de...>]

Package: sablevm
Version: 1.0.9+svn20040120-2
Tags: upstream, pending
Submitter: James Damour <jd...@ny...>

(submitting to BTS to keep track of this issue)

W li=B6cie z czw, 05-02-2004, godz. 14:33, James Damour pisze:=20
> On Tue, 2004-02-03 at 00:22, Grzegorz B. Prokopski wrote:
> > So you'd better try the above debs ;-)
>=20
> Thanks!  Using those, I got my simple "Hello World" program to run (as
> well as my most simplest of test programs).
Good!

> However, I'm having running
> my test programs that (a) use serialization, and (b) use a UI.  If you
> have the time, can you help me?
>=20
> The UI is probably the most simplest to debug.  When I run with the
> verbose flag, I get the following output (*much* truncated for clarity'=
s
> sake):
> [verbose class: loading "gnu/java/awt/peer/gtk/GtkMainThread"]
> [verbose class: loading "gnu/java/awt/peer/gtk/GtkGenericPeer"]
> sablevm: relocation error: /usr/lib/sablevm/classpath/libgtkpeer.so:
> undefined symbol: g_thread_init
>=20
> Either I need to run with a different threading model (please let me
> know how to do this), or the GTK peer library wasn't compiled with the
> correct threading model. =20

This bug was introduced in GNU Classpath CVS after last release of GNU CP
and was also fixed quite recently. Because we pull from GNU CP CVS,
you were biten by this bug.

And for the same reason next upload (today or tomorrow) should fix this
particular problem. Working on it. I hope you'll be able to get further.

HTH

				Grzegorz B. Prokopski

--=20
Grzegorz B. Prokopski <ga...@de...>
Debian GNU/Linux      http://www.debian.org
SableVM - LGPLed JVM  http://www.sablevm.org
Why SableVM ?!?       http://devel.sablevm.org/wiki/WhySableVM