sablevm-developer — SableVM developer mailing list

Re: [Sablevm-developer] Config File Parsing (Done)

[Etienne M. G. <eg...@j-...>]

Brent Fulgham wrote:
> Thanks for your comments.  I have checked in an update that (a) moves
> much of the file reading code into our own "getLine" function that
> should be somewhat functionally equivalent to the GNU version, and
> (b) removes the debugging output for the optional config files.

Thanks.

> By the way, should the configuration default to "/usr/etc"?  That
> doesn't seem standard, at least for Linux systems.

No.  If I understand well, it is assumed that when somebody downloads a
source package, he will want to install it in the /usr/local directory,
because the package is obviously not part of the "distribution" (or it
would have already been available as a binary package in /usr).

When you build a local package, you do not want it to interfere with
"official" packages.  For this reason,

./configure
make install

puts everything under /usr/local.

Now, when you build a binary package, for inclusion in an official
distribution, you simply use some configure options to put files in the
right directory, according to the policy of your distribution.

./configure --prefix=/ --sysconfdir=/etc ...

I haven't built any binary package for a distribution, yet (except for a
Debian kernel package), so I do not know how people usually go about it,
but I am pretty sure that they do something similar.  Maybe you know
more than me about that;-)

> 
> I tried out your test cases, and I'm happy to report that the code
> does read and store your 3095-byte test string.  Unfortunately, it
> seems to cause a segfault later on when the JVM attempts to stat that
> non-existent directory...

Have you tested giving sablevm an appropriate boot-class-path and
boot-library-path?

It works for me, without segfaulting...

> Well, I don't seem to be able to manipulate the bugs in the database,
> so I can't "close" anything.  However, I'm not sure if you want
> to handle all such activities yourself.

OK.  So, you'll get admin privilege.  I do really want sablevm
developers to be able to "close" (and manage) the bugs.

I'll let you close the bugs, testing your new privileges:-)

Etienne
-- 
----------------------------------------------------------------------
Etienne M. Gagnon, M.Sc.                     e-mail: eg...@j-...
Author of SableCC:                 http://www.sable.mcgill.ca/sablecc/
and SableVM:                                   http://www.sablevm.org/
----------------------------------------------------------------------

RE: [Sablevm-developer] Config File Parsing (Done)

[Brent F. <bre...@xp...>]

> > I have tested it with a file of 18 options, but there may be some
> > nastiness I've missed.  Let's all test it out... :-)
> 
> I have made a few nasty tests, an submitted 2 bug reports. (Finally
> testing this SF feature;-).
> 

Etienne, 

Thanks for your comments.  I have checked in an update that (a) moves
much of the file reading code into our own "getLine" function that
should be somewhat functionally equivalent to the GNU version, and
(b) removes the debugging output for the optional config files.

By the way, should the configuration default to "/usr/etc"?  That 
doesn't seem standard, at least for Linux systems.

I tried out your test cases, and I'm happy to report that the code
does read and store your 3095-byte test string.  Unfortunately, it
seems to cause a segfault later on when the JVM attempts to stat that
non-existent directory...

Thanks,

-Brent

> Tell me if you need more than "technician" privilege to bugs.
> 

Well, I don't seem to be able to manipulate the bugs in the database,
so I can't "close" anything.  However, I'm not sure if you want
to handle all such activities yourself.

Thanks,

-Brent

[Sablevm-developer] I think I know where the problem is...

[Etienne M. G. <eg...@j-...>]

Hi Brent.

You set up your main loop:

while ((start = fgets (start, MAXPATHLENGTH, file)))
...

It does not do what you meant.

fgets is a pain to work with, but it is feasible;  when you use it, you
have a few things to consider:

in [ s = fgets(...,MAX,...) ]

(1) if s == NULL: we have reached EOF
(2) while (s != NULL) && (strlen(s) == MAX - 1) && (s[MAX-2] != '\n')
     accumulate the option text!
(3) else s is a single line (or the tail of)

I suggest that you first accumulate the complete line (with a function).

Why not define a getline() function (using fgets)?  Do NOT read/copy the
definition of the libc library, as it might conflict with SableVM's
copyright notice.  [Unless you build a separate library for it, based on
glibc].

Also, you had an extra "len" variable declaration that was probably in
the way...

Etienne
-- 
----------------------------------------------------------------------
Etienne M. Gagnon, M.Sc.                     e-mail: eg...@j-...
Author of SableCC:                 http://www.sable.mcgill.ca/sablecc/
and SableVM:                                   http://www.sablevm.org/
----------------------------------------------------------------------

Re: [Sablevm-developer] Config File Parsing (Done)

[Etienne M. G. <eg...@j-...>]

Brent Fulgham wrote:
> Yes!  That's why I use strnlen/strncpy everywhere.  But you are
> quite correct.  I've modified the code to have no limits on the
> size of the array or the length of the strings.

Good!

> I have tested it with a file of 18 options, but there may be some
> nastiness I've missed.  Let's all test it out... :-)

I have made a few nasty tests, an submitted 2 bug reports. (Finally
testing this SF feature;-).

> Ack.  I did think about this, but I read in the GNU C Library manual
> that getline is recommended since it is safer, because it does a
> realloc on the string buffer if it's not long enough.  However, it's
> not portable so I've reworked the code to use "fgets", which should
> be ANSI compliant according to my "System V" programming guide.
> Please let me know if this still causes trouble.

The man pages are quite correct, as far as I've experienced so far.

> Done!

Thanks!

Tell me if you need more than "technician" privilege to bugs.

Etienne
-- 
----------------------------------------------------------------------
Etienne M. Gagnon, M.Sc.                     e-mail: eg...@j-...
Author of SableCC:                 http://www.sable.mcgill.ca/sablecc/
and SableVM:                                   http://www.sablevm.org/
----------------------------------------------------------------------

Re: [Sablevm-developer] Config File Parsing (Done)

[Brent F. <bfu...@de...>]

On Sat, Dec 09, 2000 at 12:42:16AM -0500, Etienne M. Gagnon wrote:
> Hi Brent!
> 
> Sorry for taking some time to reply.  I was partly in bed, fighting a
> popular Winter virus:-(  [By the way, it is quite cold here these days:
> the maximum today was -15 celcius!]
> 

Brrr!  I hate to be cruel, but here in Ventura California the low has
been about 45 F (evening), and around 65 F (Daylight).  (I'm wearing
shorts right now.)

> Thanks a lot for your contribution.  I have looked at it quickly, and it
> seems mostly good.
> 
Great!

> By the way, I forgot to tell you:  to indent your code, simply type
> 'make indent' in the root directory, and it will indent all your code
> according to the GNU standard.  On Debian, make sure to 'apt-get install
> indent' first.
> 

Already had it, but I have never worked it into the build system like
this before.  What a great idea!  My indent settings are different from
your in my editor, so it's nice to be able to get things in synch.

> There are a few points, though [I know, I am very picky;-)]:
> 1- You use hard coded array lenghts, this can cause all sorts of
> problems.  (Ever heard about buffer overflow exploits?)

Yes!  That's why I use strnlen/strncpy everywhere.  But you are
quite correct.  I've modified the code to have no limits on the
size of the array or the length of the strings.

I have tested it with a file of 18 options, but there may be some
nastiness I've missed.  Let's all test it out... :-)

> 2- You are using a non ISO/POSIX function `getline'.  I have fixed
> configure.in so that this breaks the build, which is a good thing, if we
> want SableVM to remain portable.
> 

Ack.  I did think about this, but I read in the GNU C Library manual
that getline is recommended since it is safer, because it does a 
realloc on the string buffer if it's not long enough.  However, it's
not portable so I've reworked the code to use "fgets", which should
be ANSI compliant according to my "System V" programming guide.
Please let me know if this still causes trouble.

> 
> So, if you could help me fixing these two things, it would be great. 
> [No more MAXPATHLENGTH, or 12 (!!!) constants], and replace the call to
> getline() by something equivalent that only uses ISO/POSIX library
> calls.  [Preference going to pure ISO library].
> 
Done!

-Brent

Re: [Sablevm-developer] Config File Parsing (Done)

[Etienne M. G. <eg...@j-...>]

Hi again.

> 2- You are using a non ISO/POSIX function `getline'.  I have fixed
> configure.in so that this breaks the build, which is a good thing, if we
> want SableVM to remain portable.

In fact, for the error to show, you need to do the following:
 $ cvs update
 $ export CFLAGS='-Werror -O0 -ggdb'
 $ autoreconf
 $ make clean
 $ make

I always keep the CFLAGS set as shown above during development: you get
a nicer debugger behavior, and you don't forget any warning;-)  I
usually use DDD  (apt-get install ddd).  Quite nice; allows you to
browse your data structures.

Etienne
-- 
----------------------------------------------------------------------
Etienne M. Gagnon, M.Sc.                     e-mail: eg...@j-...
Author of SableCC:                 http://www.sable.mcgill.ca/sablecc/
and SableVM:                                   http://www.sablevm.org/
----------------------------------------------------------------------

Re: [Sablevm-developer] Config File Parsing (Done)

[Etienne M. G. <eg...@j-...>]

Hi Brent!

Sorry for taking some time to reply.  I was partly in bed, fighting a
popular Winter virus:-(  [By the way, it is quite cold here these days:
the maximum today was -15 celcius!]

Thanks a lot for your contribution.  I have looked at it quickly, and it
seems mostly good.

By the way, I forgot to tell you:  to indent your code, simply type
'make indent' in the root directory, and it will indent all your code
according to the GNU standard.  On Debian, make sure to 'apt-get install
indent' first.

There are a few points, though [I know, I am very picky;-)]:
1- You use hard coded array lenghts, this can cause all sorts of
problems.  (Ever heard about buffer overflow exploits?)
2- You are using a non ISO/POSIX function `getline'.  I have fixed
configure.in so that this breaks the build, which is a good thing, if we
want SableVM to remain portable.


So, if you could help me fixing these two things, it would be great. 
[No more MAXPATHLENGTH, or 12 (!!!) constants], and replace the call to
getline() by something equivalent that only uses ISO/POSIX library
calls.  [Preference going to pure ISO library].

I have, here, "The Annotated ANSI C Standard" ISBN 0-07-881952 which
contains the ANSI/ISO 9899-1990 standard text and annotations.  You can
through the annotations out of the window, but the standard text is a
wonderful source of information for writing portable code.  But be
warned, it is a little dry to read (it seems written by lawyers).  You
might get away with simpler texts, but you should definitely have some
reference book for writing portable code.  In last resort, 'man 3
functionname' also contains a "CONFORMING TO" section.  Try 'man 3
getc'.

OK.  Thanks a lot.

Etienne

cvs Brent Fulgham wrote:
> 
> I've committed changes that implement a configuration file
> parsing system.  It starts at the SYSCONFDIR (which is set
> by autoconf), then checks the user's $HOME directory, and
> finally it evaluates the command-line parameters.
> 
> The parameters observed the following rules of precedence:
> 
> 1.  Command-line parameters trump everything.
> 2.  $HOME directory configuration parameters are second highest.
> 3.  SYSCONFDIR config parametres have lowest priority.
> 
> I've tested it on my system, so I'm pretty sure it doesn't
> break anything.  But of course, please let me know if you
> discover otherwise! ;-)
> 
> Thanks,
> 
> -Brent
> _______________________________________________
> Sablevm-developer mailing list
> Sab...@li...
> http://lists.sourceforge.net/mailman/listinfo/sablevm-developer

-- 
----------------------------------------------------------------------
Etienne M. Gagnon, M.Sc.                     e-mail: eg...@j-...
Author of SableCC:                 http://www.sable.mcgill.ca/sablecc/
and SableVM:                                   http://www.sablevm.org/
----------------------------------------------------------------------

[Sablevm-developer] Config File Parsing (Done)

[Brent F. <bfu...@de...>]

I've committed changes that implement a configuration file
parsing system.  It starts at the SYSCONFDIR (which is set
by autoconf), then checks the user's $HOME directory, and
finally it evaluates the command-line parameters.

The parameters observed the following rules of precedence:

1.  Command-line parameters trump everything.
2.  $HOME directory configuration parameters are second highest.
3.  SYSCONFDIR config parametres have lowest priority.

I've tested it on my system, so I'm pretty sure it doesn't
break anything.  But of course, please let me know if you
discover otherwise! ;-)

Thanks,

-Brent

Re: [Sablevm-developer] Re: Config File Parsing

[Etienne M. G. <eg...@j-...>]

Brent Fulgham wrote:
> Great!  I'll try to check something in tomorrow or so.

Super!  

Have you made a 'cvs update' lately?  I have finally resolved the
problem I was having to cleanly define PKGDATADIR and SYSCONFDIR in
configure.in.  I also made minor modifications in sablevm.c which may
affect you.  

> (And my JNI book finally arrived...)

Lots of interesting reading ahead!

Thanks!

Etienne
-- 
----------------------------------------------------------------------
Etienne M. Gagnon, M.Sc.                     e-mail: eg...@j-...
Author of SableCC:                 http://www.sable.mcgill.ca/sablecc/
and SableVM:                                   http://www.sablevm.org/
----------------------------------------------------------------------

RE: [Sablevm-developer] Re: Config File Parsing

[Brent F. <bre...@xp...>]

> If you put everything in back-precdence order in the agrv-style array,
> then everything should work fine.
> 
> Popt is very handy there; it assures us that we get the latest
> definition for each one.  I like popt; does it show?
> 
> :o)
> 

Great!  I'll try to check something in tomorrow or so.

(And my JNI book finally arrived...)

-Brent

Re: [Sablevm-developer] Re: Config File Parsing

[Etienne M. G. <eg...@j-...>]

Brent Fulgham wrote:
> If so, I think I'll have to take a pass through the
> files first, tossing out duplicates per the above rules
> of precedence.
> 
> What do you think?


If you put everything in back-precdence order in the agrv-style array,
then everything should work fine.

Popt is very handy there; it assures us that we get the latest
definition for each one.  I like popt; does it show?

:o)

Etienne
-- 
----------------------------------------------------------------------
Etienne M. Gagnon, M.Sc.                     e-mail: eg...@j-...
Author of SableCC:                 http://www.sable.mcgill.ca/sablecc/
and SableVM:                                   http://www.sablevm.org/
----------------------------------------------------------------------

RE: [Sablevm-developer] Re: Config File Parsing

[Brent F. <bre...@xp...>]

> A very simple program could read options from a configuration
> file, strip leading/trailing space characters (at the line 
> beginning/end, and around the first "=" character) then add
> a "--" prefix, then store the result in an array of strings,
> then simply add to this array the strings of argv[].  As 
> usual, empty lines (after stripping) and comment lines
> (starting with #) would be ignored.  Line continuation 
> support would be nice to have, too;-)
> 
I've got this pretty much coded up.  One thing I'm curious
about is this:

Let's say I have a master config file in e.g., /etc/sablevmrc:

boot-class-path = /usr/share/sable/classes
boot-library-path = /usr/lib/sable

And I have my own config file in $HOME/.sablevmrc:

boot-class-path = /usr/src/sablepath/classes
boot-library-path = /usr/src/sablepath/lib

And I write my command line:

#>sablevm --boot-class-path=/usr/src/sable2/classes -- HelloWorld

I believe that the command line should take precedence over
the $HOME sable config file, and the $HOME config file over
the system config file.

If so, I think I'll have to take a pass through the
files first, tossing out duplicates per the above rules
of precedence.

What do you think?

-Brent

Re: [Sablevm-developer] Re: Config File Parsing

[Etienne M. G. <eg...@j-...>]

"Etienne M. Gagnon" wrote:
> ....  You can assume that there is a SYSCONFDIR
> (#defined in config.h) that will contain this path (typically:
> "/usr/local/etc").

This is now done.  Simply type "cvs update" in your root sablevm
directory.

> realloc won't work for argv.

So what you must do is:

...
  char **all_opts;
...
  all_opts = malloc (sizeof (char *) * (argc + config_opts_count));
...

then, 

...
  context =
    poptGetContext ("sablevm", argc + config_opts_count, 
                    (const char **) all_opts, options, 0);
...

-- 
----------------------------------------------------------------------
Etienne M. Gagnon, M.Sc.                     e-mail: eg...@j-...
Author of SableCC:                 http://www.sable.mcgill.ca/sablecc/
and SableVM:                                   http://www.sablevm.org/
----------------------------------------------------------------------

Re: [Sablevm-developer] Re: Config File Parsing

[Etienne M. G. <eg...@j-...>]

Brent Fulgham wrote:
> I've got a stupid C question:
> 
> Is it possible to modify the char* vector "argv" passed from
> the command line?

No.  You have to allocate a new array.

> Based on our earlier e-mail, I would anticipate the following:
> 
> 1.  User starts sablevm with one or two command line options.
> 2.  SableVM opens and parses the /etc/sablevm file.  (This works)

The location of this file should be chosen by "configure".  The
existence of this file is optional.

We should also consider allowing for user specific configuration file
(typically in $HOME/.sablevm), but this can wait until the system-wide
one works.

I am taking care of that.  You can assume that there is a SYSCONFDIR
(#defined in config.h) that will contain this path (typically:
"/usr/local/etc").

> 3.  SableVM must then insert options from the /etc/sablevm file
>     into the argv that gets passed to the "popt" library for
>     parsing.

No.  You simply create an array big enough to contain all options.

> 
> How does this work?  I tried a realloc on the argv vector, but
> that caused a segfault.

realloc won't work for argv.

Etienne
-- 
----------------------------------------------------------------------
Etienne M. Gagnon, M.Sc.                     e-mail: eg...@j-...
Author of SableCC:                 http://www.sable.mcgill.ca/sablecc/
and SableVM:                                   http://www.sablevm.org/
----------------------------------------------------------------------

RE: [Sablevm-developer] Re: Config File Parsing

[Brent F. <bre...@xp...>]

I've got a stupid C question:

Is it possible to modify the char* vector "argv" passed from
the command line?

Based on our earlier e-mail, I would anticipate the following:

1.  User starts sablevm with one or two command line options.
2.  SableVM opens and parses the /etc/sablevm file.  (This works)
3.  SableVM must then insert options from the /etc/sablevm file
    into the argv that gets passed to the "popt" library for
    parsing.

How does this work?  I tried a realloc on the argv vector, but
that caused a segfault.

In fact, more generally, how do you do something like this:

int main()
{
	char* args[3] = { "--foo", "--bar", "--baz" };
	int argc = 3;

	do_something(&argc, args);
}

void do_something(int* argc, char** argv)
{
	/* Add some new fields */
	char* data = realloc(*args, 1000);
	/* I think this actually just macs args[0] = a buffer of
	   size 1000.  It doesn't grow the whole block. */

	data[4] = "--more_stuff";
	/* I think this 
	...
}

The problem I'm having is with conceptualizing pointer-to-pointer
versus array-of-pointers.  How can I achieve the desired behavior
of basically "growing" an array of pointers?

I know how I would achieve this under C++, but I'm unclear as to
the proper behavior under C.

Any help *greatly* appreciated.

Thanks,

-Brent

Re: [Sablevm-developer] Re: Config File Parsing

[Etienne M. G. <eg...@j-...>]

I forgot something: I am already using popt.  I now remember that it can
parse arbitrary strings in argv[] style arrays.

A very simple program could read options from a configuration file,
strip leading/trailing space characters (at the line beginning/end, and
around the first "=" character) then add a "--" prefix, then store the
result in an array of strings, then simply add to this array the strings
of argv[].  As usual, empty lines (after stripping) and comment lines
(starting with #) would be ignored.  Line continuation support would be
nice to have, too;-)

i.e.:

file content
------------
# comment
  boot-class-path = /usr/share/sablepath/classes
  boot-library-path \
    = /usr/share/sablepath/lib
...

converted into:

"--boot-class-path=/usr/share/sablepath/classes"
"--boot-library-path=/usr/share/sablepath/lib"


The nice thing, with this approach, is that we would automatically get
popt's error messages for invalid options (and optinally option
aliasing, too!)

This would probably be the best solution, as it fits nicely with the
current command line parsing code.

Etienne

Brent Fulgham wrote:
> 
> Have a look at "dot.conf", http://www.azzit.de/dotconf.  I think
> it might do what we need.  It's also LGPL'd.
> 
> It doesn't appear to be packaged for Debian yet, so I'll take care
> of that (after checking with others to see if it's in the works.)
> 
> -Brent
> _______________________________________________
> Sablevm-developer mailing list
> Sab...@li...
> http://lists.sourceforge.net/mailman/listinfo/sablevm-developer

-- 
----------------------------------------------------------------------
Etienne M. Gagnon, M.Sc.                     e-mail: eg...@j-...
Author of SableCC:                 http://www.sable.mcgill.ca/sablecc/
and SableVM:                                   http://www.sablevm.org/
----------------------------------------------------------------------

Re: [Sablevm-developer] Re: Config File Parsing

[Brent F. <bfu...@de...>]

Have a look at "dot.conf", http://www.azzit.de/dotconf.  I think
it might do what we need.  It's also LGPL'd.

It doesn't appear to be packaged for Debian yet, so I'll take care
of that (after checking with others to see if it's in the works.)

-Brent

Re: [Sablevm-developer] Re: Compile issue

[Etienne M. G. <eg...@j-...>]

"Etienne M. Gagnon" wrote:
> SableVM has the following "hard" dependencies:
> 1- ANSI C compiler & library
> 2- POSIX library

In fact, there are some pretty fancy (and I would say: ugly) other small
system specific dependencies, like memory consistency models (i.e. how
the caches behave on multi-processor systems), alignment rules (some
systems require special allignment for long/doubles, I have learned
lately on the SableVM user mailing list), and atomic compare-and-swap
operation (which must be written as inlined assembly).

I hate having to deal with some of these issues, but they are essential
for a conforming vm. (#!@(*&%^@!#$*@#%!!!)
-- 
----------------------------------------------------------------------
Etienne M. Gagnon, M.Sc.                     e-mail: eg...@j-...
Author of SableCC:                 http://www.sable.mcgill.ca/sablecc/
and SableVM:                                   http://www.sablevm.org/
----------------------------------------------------------------------

Re: [Sablevm-developer] Re: Compile issue

[Etienne M. G. <eg...@j-...>]

Brent Fulgham wrote:
> > Would you like to work on the application class loader?
> >
> Yes!  Can you point me towards any references on how it should work?
> For example, I could possibly look at Kaffe's or Japhar's implementation
> for hints since their licenses are GPL/LGPL.  Or are we approaching it in a
> different fashion?  I don't know much about the innards of Kaffe.

I do not know how they do it; but I know how I'd like it done;-)

See below.

> 
> Sounds good to me.  Is it a goal to have SableVM compile under, for
> example, Windows using Borland or Microsoft's compiler?  The VM code
> looks like it makes use of some GNU C extensions.

SableVM has the following "hard" dependencies:
1- ANSI C compiler & library
2- POSIX library

The current dependency on GNU C's labels as values will be optional,
hopefully selected automagically through some configure magic.  Did you
receive my request mail, on the SableVM-"USER" mailing-list?
(http://www.geocrawler.com/archives/3/4430/2000/11/0/4750188/)


> > Hmmmm, why not in "/etc" (this path would be a compile time constant, as
> > I already do with the license files).  I would very much like sablevm to
> > use configuration files, instead of environment variables, to find its
> > default boot paths.  Much cleaner.
> 
> Yes.  And easy to do.  We would want to retain the command-line parsing
> to allow user-override.  So we just add some code to parse a simple
> configuration file of "tag = value" pairs:
> 
> boot-class-path = /usr/lib/sablepath/classes
> boot-library-path = /usr/lib/sablepath
> class-path = /usr/share/java
> 
> What do you think?  I could code this up relatively quickly.  But
> the class-loader will take more time while I research how it should
> work.

I think there already exist some libraries for parsing such
configuration files.  Let me check the Debian archive for some license
compatible one (something like LGPL or public domain).

As for the class loader stuff, you will probably need to work in close
collaboration with me on this one, as it involves the VM.

How about fixing the parsing stuff first?  ;-)

I'll tell you as soon as (or if) I find a library.

Etienne
-- 
----------------------------------------------------------------------
Etienne M. Gagnon, M.Sc.                     e-mail: eg...@j-...
Author of SableCC:                 http://www.sable.mcgill.ca/sablecc/
and SableVM:                                   http://www.sablevm.org/
----------------------------------------------------------------------

Re: [Sablevm-developer] Re: Compile issue

[Brent F. <bfu...@de...>]

On Sun, Dec 03, 2000 at 04:23:56PM -0500, Etienne M. Gagnon wrote:
> Hi Brent.
> 
> Brent Fulgham wrote:
> > Ack!  So I have.  Attaching now.
> 
> The patch looks OK.  (It's definitely not what I would keep in the final
> optimized version of SableVM, but it looks operational).
> 
> Now, we have the choice of either using it, or fixing --class-path using
> an application class loader (which is the right way to implement the
> whole thing).
> 

I think we should probably just leave the patch out of sablevm and move
directly to the class-loader.  The reason I say this is that unless we
want the ability to have multiple possible paths to the "base-classes"
and "base-libraries", there's not need for the performance hit of all
that copying and string manipulation.

> Would you like to work on the application class loader?
> 
Yes!  Can you point me towards any references on how it should work?
For example, I could possibly look at Kaffe's or Japhar's implementation
for hints since their licenses are GPL/LGPL.  Or are we approaching it in a
different fashion?  I don't know much about the innards of Kaffe.

> I would still consider your patch, in the short term, as it can be
> convenient for testing.
> 
> What do you think?
>
As I mentioned, it might be better to leave it out since it will encourage
me to actually implement the class loader ;-)  For now, it is convenient
enough for testing to just put the classes into base-class-path.

> > Right -- I don't think this patch handles all such cases properly,
> > since it adds an extra '/' to the patch.  This is, of course,
> > easy to fix.  Although in practice I think the use of
> > "[...]sablepath/classes//" just happens to work on most systems.
> 
> In fact, if we really want to be system independent, we need to use
> system properties for this.  All this is best done in Java, using an
> application class loader.
>

Sounds good to me.  Is it a goal to have SableVM compile under, for
example, Windows using Borland or Microsoft's compiler?  The VM code
looks like it makes use of some GNU C extensions.

> > Right -- with compile-time option so we don't always have to
> > pass it as a boot parameter.  Then --class-path would direct the
> > loader to our standard set of paths for classes.
> 
> Hmmmm, why not in "/etc" (this path would be a compile time constant, as
> I already do with the license files).  I would very much like sablevm to
> use configuration files, instead of environment variables, to find its
> default boot paths.  Much cleaner.
> 

Yes.  And easy to do.  We would want to retain the command-line parsing
to allow user-override.  So we just add some code to parse a simple
configuration file of "tag = value" pairs:

boot-class-path = /usr/lib/sablepath/classes
boot-library-path = /usr/lib/sablepath
class-path = /usr/share/java

What do you think?  I could code this up relatively quickly.  But
the class-loader will take more time while I research how it should
work.

-Brent

Re: [Sablevm-developer] locks

[Etienne M. G. <eg...@j-...>]

John Leuner wrote:
> Have you implemented object locks in SableVM yet? I have had a quick look
> at the source and didn't find anything there.

Not yet.  I have spent too much time writing about SableVM (tech report
& Ph.D. proposal & presentation slides), and participating to seminars. 
Before I go forward with it, I want to get single threading in a much
better state.  I think that getting exceptions to work, and cleaning the
memory management code has higher priority.

Do you want to help with implementing locks?  I can give you a few
pointers (in addition to my tech report).

Etienne 
-- 
----------------------------------------------------------------------
Etienne M. Gagnon, M.Sc.                     e-mail: eg...@j-...
Author of SableCC:                 http://www.sable.mcgill.ca/sablecc/
and SableVM:                                   http://www.sablevm.org/
----------------------------------------------------------------------

Re: [Sablevm-developer] Re: Compile issue

[Etienne M. G. <eg...@j-...>]

Hi Brent.

Brent Fulgham wrote:
> Ack!  So I have.  Attaching now.

The patch looks OK.  (It's definitely not what I would keep in the final
optimized version of SableVM, but it looks operational).

Now, we have the choice of either using it, or fixing --class-path using
an application class loader (which is the right way to implement the
whole thing).

Would you like to work on the application class loader?

I would still consider your patch, in the short term, as it can be
convenient for testing.

What do you think?

> Right -- I don't think this patch handles all such cases properly,
> since it adds an extra '/' to the patch.  This is, of course,
> easy to fix.  Although in practice I think the use of
> "[...]sablepath/classes//" just happens to work on most systems.

In fact, if we really want to be system independent, we need to use
system properties for this.  All this is best done in Java, using an
application class loader.

> Right -- with compile-time option so we don't always have to
> pass it as a boot parameter.  Then --class-path would direct the
> loader to our standard set of paths for classes.

Hmmmm, why not in "/etc" (this path would be a compile time constant, as
I already do with the license files).  I would very much like sablevm to
use configuration files, instead of environment variables, to find its
default boot paths.  Much cleaner.

Etienne
-- 
----------------------------------------------------------------------
Etienne M. Gagnon, M.Sc.                     e-mail: eg...@j-...
Author of SableCC:                 http://www.sable.mcgill.ca/sablecc/
and SableVM:                                   http://www.sablevm.org/
----------------------------------------------------------------------

[Sablevm-developer] locks

[John L. <je...@pi...>]

Hello Etienne

Have you implemented object locks in SableVM yet? I have had a quick look
at the source and didn't find anything there.

John Leuner

Re: [Sablevm-developer] Re: Compile issue

[Brent F. <bfu...@de...>]

On Sun, Dec 03, 2000 at 10:27:05AM -0500, Etienne M. Gagnon wrote:
> Hi Brent,
> 
> I am continuing this thread on the SableVM-Developer list.
> 
> Brent Fulgham wrote:
> > I've attached a diff for your review.  I wouldn't dare apply this to
> > the archive until you look at it.  It's probably pretty inefficient --
> > I think with some thought we could probably get rid of some copying.
> 
> I think you actually forgot to attach the diff (it happens to me often
> too, to forget attachments;-).
> 

Ack!  So I have.  Attaching now.

> If we implement this for --boot-class-path, we must also implement it
> for --boot-library-path.  We should also take care of adding a trailing
> "/" when necessary, e.g.:
> 
> (All of these should be valid)
> 
>  --boot-class-path=/usr/lib/sablepath/classes/:./  
>  --boot-class-path=/usr/lib/sablepath/classes:./  
>  --boot-class-path=/usr/lib/sablepath/classes/:.  
>  --boot-class-path=/usr/lib/sablepath/classes:.  
> 

Right -- I don't think this patch handles all such cases properly,
since it adds an extra '/' to the patch.  This is, of course,
easy to fix.  Although in practice I think the use of 
"[...]sablepath/classes//" just happens to work on most systems.

> If we want to accept "relative" paths (like "."), we should first
> convert them into absolute paths.  I do really dislike the JDK's
> vulnerability in this regard (as using a file dialog can change the
> current work directory and cause all sorts of problems).
> 
Okay.

> I don't know if it is a good thing, or not, to accept all of these
> things in the boot class path (see discussion below).  It might be
> sufficient to simply accept a single absolute path.
> 
Right -- with compile-time option so we don't always have to
pass it as a boot parameter.  Then --class-path would direct the
loader to our standard set of paths for classes.

(snipping rest of discussion, since I have nothing to add)

Thanks,

-Brent

[Sablevm-developer] Re: Compile issue

[Etienne M. G. <eg...@j-...>]

Hi Brent,

I am continuing this thread on the SableVM-Developer list.

Brent Fulgham wrote:
> I've attached a diff for your review.  I wouldn't dare apply this to
> the archive until you look at it.  It's probably pretty inefficient --
> I think with some thought we could probably get rid of some copying.

I think you actually forgot to attach the diff (it happens to me often
too, to forget attachments;-).

> At any rate, my idea was to allow --boot-class-path to accept things
> of the form:
> 
> --boot-class-path=/usr/lib/sablepath/classes:.
> 
> (just like regular ":"-delimited path lists).
> 
> To get this to work, I had to make a few changes, but I think the
> scope of the modifications is relatively small.

If we implement this for --boot-class-path, we must also implement it
for --boot-library-path.  We should also take care of adding a trailing
"/" when necessary, e.g.:

(All of these should be valid)

 --boot-class-path=/usr/lib/sablepath/classes/:./  
 --boot-class-path=/usr/lib/sablepath/classes:./  
 --boot-class-path=/usr/lib/sablepath/classes/:.  
 --boot-class-path=/usr/lib/sablepath/classes:.  

If we want to accept "relative" paths (like "."), we should first
convert them into absolute paths.  I do really dislike the JDK's
vulnerability in this regard (as using a file dialog can change the
current work directory and cause all sorts of problems).

I don't know if it is a good thing, or not, to accept all of these
things in the boot class path (see discussion below).  It might be
sufficient to simply accept a single absolute path.

> One thing I'm not sure of is if "class-path" should be the path
> to the main class archive, the classes I intend to run, or some
> combination.  And how about --boot-class-path?  It seems that the
> class you pass on the command-line must be in the --boot-class-path
> path as well.
> 
> Why do we need two class-paths?

OK.  Let me start by saying that the current implementation of sablevm.c
is wrong.  It shouldn't instantiate the HelloWorld class.  It should,
instead, instantiate a special application class which will use a class
loader to load the HelloWorld class.

By using a class loader, it can retrieve this class from within a .jar
file, or any other location.  The code to do so will be written in Java
(relief for the vm writer;-).

The idea of having 2 kinds of class path is that:
boot-class-path:  This is the path to the standard libraries.
class-path:  This is the path to the user's classes.

Now, it might be interesting, eventually, to allow some boot classes to
be packaged into .jar files, but as I do not want to write .jar reading
code in C, some base classes have to be available directly on the file
system.  If we want to use both, we have to play a few tricks in the vm
to record specially that all these classes are in the same "runtime
package".  So, I would delay the implementation of this to later, when
we know that the normal class-path does implement runtime packages
correctly.

Etienne
-- 
----------------------------------------------------------------------
Etienne M. Gagnon, M.Sc.                     e-mail: eg...@j-...
Author of SableCC:                 http://www.sable.mcgill.ca/sablecc/
and SableVM:                                   http://www.sablevm.org/
----------------------------------------------------------------------