sablevm-developer

[Sablevm-developer] Short release status - almost there...

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

Hi!

So what has been done and how it looks now? FYI:

1. Chris used benchmarks to assure there's no functional regressions
in staging, as compared to 1.0.9.
2. Updated http://devel.sablevm.org/docs/INSTALL.txt document, which
serves as both: release notes and installation instruction, and put it
into sablevm/staging as INSTALL-DEVEL text file (made it included in
the "dist" tarball - should be removed on migration to trunk!).
3. Fixed make dist for sablevm (and Mark helped w/ classpath's dist)
3. Merged SableVM/staging into bugfree and did all the steps for it as
http://devel.sablevm.org/wiki/ReleaseProcess describes.
4. Couldn't do changes to our classpath repo so requested David or
Etienne to do them (and to make the 1.1.0 release tags).

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

Re: [Sablevm-developer] Short release status - almost there...

[Chris P. <chr...@ma...>]

Grzegorz B. Prokopski wrote:

> Hi!
> 
> So what has been done and how it looks now? FYI:
> 
> 1. Chris used benchmarks to assure there's no functional regressions
> in staging, as compared to 1.0.9.

I checked the SPECjvm98, JOlden, and JGF single- and multi-threaded 
suites, on i686, with gcc-2.95.4 for 1.0.9 and gcc-3.3.2 for 
staging-r1575, with the switch-debug and inlined interpreters only, and 
the "correctness" is only against the stdout/stderr of a single trial 
run.  We still need to work on a multiple-architecture regression suite 
that actually tests all the compilation modes if we want to be really 
sure in the future.  But at least there don't appear to be any 
fundamental regressions.

> 2. Updated http://devel.sablevm.org/docs/INSTALL.txt document, which
> serves as both: release notes and installation instruction, and put it
> into sablevm/staging as INSTALL-DEVEL text file (made it included in
> the "dist" tarball - should be removed on migration to trunk!).

Seems like common practice would be to put a single INSTALL file in the 
top level of sablevm.

Other than that it's all great!

Cheers,
Chris

Re: [Sablevm-developer] Short release status - almost there...

[Etienne G. <gag...@uq...>]

Chris Pickett wrote:
>> 2. Updated http://devel.sablevm.org/docs/INSTALL.txt document, which
>> serves as both: release notes and installation instruction, and put it
>> into sablevm/staging as INSTALL-DEVEL text file (made it included in
>> the "dist" tarball - should be removed on migration to trunk!).
> 
> 
> Seems like common practice would be to put a single INSTALL file in the 
> top level of sablevm.

I agree with the INSTALL file.

Another thing:  I do really think that "./configure ; make ; make install"
should work out-of-the-box for sablevm-x.y.z.tar.gz and for
sablevm-classpath-x.y.z.tar.gz.  Currently, it is broken for
sablevm-classpath (as you need to pass specific configure options to get
a sablevm usable build).  Assume that the typical user WILL NOT read the
README file nor the INSTALL files and will simply go ahead and type the
standard commands above.  [Alternatively, you could make sure that
"./configure" fails for sablevm-classpath, and issues a message inviting
the user to read the README and INSTALL files...]

The worst situation is if a user does the standard commands, gets no build
error message, yet gets "could not start vm" when trying to run HelloWorld.

What do you think?

Etienne

-- 
Etienne M. Gagnon, Ph.D.             http://www.info.uqam.ca/~egagnon/
SableVM:                                       http://www.sablevm.org/
SableCC:                                       http://www.sablecc.org/

Re: [Sablevm-developer] Short release status - almost there...

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

W li=B6cie z nie, 15-02-2004, godz. 09:41, Etienne Gagnon pisze:=20
> Chris Pickett wrote:
> >> 2. Updated http://devel.sablevm.org/docs/INSTALL.txt document, which
> >> serves as both: release notes and installation instruction, and put =
it
> >> into sablevm/staging as INSTALL-DEVEL text file (made it included in
> >> the "dist" tarball - should be removed on migration to trunk!).
> >=20
> >=20
> > Seems like common practice would be to put a single INSTALL file in t=
he=20
> > top level of sablevm.
>=20
> I agree with the INSTALL file.

Well, I could simply rip-off the upper part of the file, which says
things about "build" and "build-many" scripts, downloading 3 tarballs,
etc. In general all that seems rather outdated. The question is
whether we want to keep any of this stuff? There's no build script in
staging's sablevm.

If you don't mind - then I'll go and put current build instructions
there instead. And split news into NEWS. This should probably be done
before tagging 1.1.0 in bugfree.

> Another thing:  I do really think that "./configure ; make ; make insta=
ll"
> should work out-of-the-box for sablevm-x.y.z.tar.gz and for
> sablevm-classpath-x.y.z.tar.gz.  Currently, it is broken for
> sablevm-classpath (as you need to pass specific configure options to ge=
t
> a sablevm usable build).  Assume that the typical user WILL NOT read th=
e
> README file nor the INSTALL files and will simply go ahead and type the
> standard commands above.  [Alternatively, you could make sure that
> "./configure" fails for sablevm-classpath, and issues a message invitin=
g
> the user to read the README and INSTALL files...]

I agree. Any takers? That should be just some playing w/ configure's
defaults, so that --prefix was enough to set --libdir and --datadir
properly to sablevm's needs. (though I don't see it as 1.1.0
showstopper).

> The worst situation is if a user does the standard commands, gets no bu=
ild
> error message, yet gets "could not start vm" when trying to run HelloWo=
rld.
>=20
> What do you think?

This will be our first (and most used) FAQ entry. *g*
(and there's more than one answer to that too)

Cheers,

					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

Re: [Sablevm-developer] Short release status - almost there...

[Chris P. <chr...@ma...>]

Etienne Gagnon wrote:
> Chris Pickett wrote:
> 
>>> 2. Updated http://devel.sablevm.org/docs/INSTALL.txt document, which
>>> serves as both: release notes and installation instruction, and put it
>>> into sablevm/staging as INSTALL-DEVEL text file (made it included in
>>> the "dist" tarball - should be removed on migration to trunk!).
>>
>>
>>
>> Seems like common practice would be to put a single INSTALL file in 
>> the top level of sablevm.
> 
> 
> I agree with the INSTALL file.
> 
> Another thing:  I do really think that "./configure ; make ; make install"
> should work out-of-the-box for sablevm-x.y.z.tar.gz and for
> sablevm-classpath-x.y.z.tar.gz.  Currently, it is broken for
> sablevm-classpath (as you need to pass specific configure options to get
> a sablevm usable build).  Assume that the typical user WILL NOT read the
> README file nor the INSTALL files and will simply go ahead and type the
> standard commands above.  [Alternatively, you could make sure that
> "./configure" fails for sablevm-classpath, and issues a message inviting
> the user to read the README and INSTALL files...]
> 
> The worst situation is if a user does the standard commands, gets no build
> error message, yet gets "could not start vm" when trying to run HelloWorld.
> 
> What do you think?

I think adjusting classpath's configure.ac to recognize our options as 
defaults should not be too hard (including --enable-gtk-peer=no as default).

On the other hand, it is also not too hard to include David's 
build_sablevm-classpath script.

Cheers,
Chris

Re: [Sablevm-developer] Short release status - almost there...

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

W li=B6cie z nie, 15-02-2004, godz. 12:58, Chris Pickett pisze:=20
> Etienne Gagnon wrote:
> > Another thing:  I do really think that "./configure ; make ; make ins=
tall"
> > should work out-of-the-box for sablevm-x.y.z.tar.gz and for
> > sablevm-classpath-x.y.z.tar.gz.  Currently, it is broken for
> > sablevm-classpath (as you need to pass specific configure options to =
get
> > a sablevm usable build).  Assume that the typical user WILL NOT read =
the
> > README file nor the INSTALL files and will simply go ahead and type t=
he
> > standard commands above.  [Alternatively, you could make sure that
> > "./configure" fails for sablevm-classpath, and issues a message invit=
ing
> > the user to read the README and INSTALL files...]
> >=20
> > The worst situation is if a user does the standard commands, gets no =
build
> > error message, yet gets "could not start vm" when trying to run Hello=
World.
> >=20
> > What do you think?
>=20
> I think adjusting classpath's configure.ac to recognize our options as=20
> defaults should not be too hard (including --enable-gtk-peer=3Dno as de=
fault).

No GTK? Why?! IMO this one surely should be "yes" by default.

OTOH I'd love to have some not-too-big AWT app with which I could
test this feature (not gnome-java). Any suggestions?

> On the other hand, it is also not too hard to include David's=20
> build_sablevm-classpath script.

I think adjusting configure would be better percieved by the users, as
./configure [ --prefix=3D... ]; make ; make install
is what works for 90% of the free software.

					GBP

--=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

Re: [Sablevm-developer] Short release status - almost there...

[Chris P. <chr...@ma...>]

Grzegorz B. Prokopski wrote:

> W li=B6cie z nie, 15-02-2004, godz. 12:58, Chris Pickett pisze:=20
>=20
>>Etienne Gagnon wrote:
>>
>>>Another thing:  I do really think that "./configure ; make ; make inst=
all"
>>>should work out-of-the-box for sablevm-x.y.z.tar.gz and for
>>>sablevm-classpath-x.y.z.tar.gz.  Currently, it is broken for
>>>sablevm-classpath (as you need to pass specific configure options to g=
et
>>>a sablevm usable build).  Assume that the typical user WILL NOT read t=
he
>>>README file nor the INSTALL files and will simply go ahead and type th=
e
>>>standard commands above.  [Alternatively, you could make sure that
>>>"./configure" fails for sablevm-classpath, and issues a message inviti=
ng
>>>the user to read the README and INSTALL files...]
>>>
>>>The worst situation is if a user does the standard commands, gets no b=
uild
>>>error message, yet gets "could not start vm" when trying to run HelloW=
orld.
>>>
>>>What do you think?
>>
>>I think adjusting classpath's configure.ac to recognize our options as =

>>defaults should not be too hard (including --enable-gtk-peer=3Dno as de=
fault).
>=20
>=20
> No GTK? Why?! IMO this one surely should be "yes" by default.

I don't know, I was thinking that a minimal barrier to success was good. =

  It's just one more dependency to take care of.  It's really fine=20
either way.

> OTOH I'd love to have some not-too-big AWT app with which I could
> test this feature (not gnome-java). Any suggestions?

You might find something here:

http://www.epcc.ed.ac.uk/javagrande/links.html


>>On the other hand, it is also not too hard to include David's=20
>>build_sablevm-classpath script.
>=20
>=20
> I think adjusting configure would be better percieved by the users, as
> ./configure [ --prefix=3D... ]; make ; make install
> is what works for 90% of the free software.

okay :)  The only reason I made the comment was because I thought it=20
might make it easier to merge classpath updates from upstream.  But I=20
agree:  ./configure [ --prefix=3D... ]; make ; make install is best for=20
the end user.  It also tends to indicate a well-maintained piece of=20
software.

Chris