public inbox for java@gcc.gnu.org
 help / color / mirror / Atom feed
* Re: Integrating Win32 changes
  2000-04-01  0:00       ` Tom Tromey
@ 2000-04-01  0:00         ` Jon Beniston
  0 siblings, 0 replies; 19+ messages in thread
From: Jon Beniston @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Tom Tromey; +Cc: Tom Tromey, Per Bothner, java-discuss

> 
> BTW another prerequisite for getting your Windows changes into libgcj
> is dealing with the paperwork (copyright assignment, etc).  You might
> want to start this sooner rather than later.
> 

I did this some time ago. Thanks for the T-Shirt by the way!

Jon.

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Integrating Win32 changes
  2000-04-01  0:00   ` Jon Beniston
@ 2000-04-01  0:00     ` Jeff Sturm
  2000-04-01  0:00       ` Per Bothner
  0 siblings, 1 reply; 19+ messages in thread
From: Jeff Sturm @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Jon Beniston; +Cc: java-discuss

Jon Beniston wrote:
> > "#ifdef WIN32" would probably be better unless the code really depends
> > on Mingw32.  That'll benefit those who may be compiling with Cygwin or
> > U/WIN, or other GCC-on-Windows environments.
> 
> I think its best not to mix treat ming and cygwin the same. With cygwin you
> can
> use many of the posix type functions, but you cant with ming. IMHO, building
> for cygwin would link to natFileDescriptorPosix.cc whereas a Ming build
> would map to natFileDescriptorWin32.cc, for example.

Perhaps.  As Per said, we may end up with three implementations of
natFileDescriptor, for Posix, Win32 and stdio.  That should cover most
platforms.  Many will have two or more choices.  So it could become a
configurable option, with configure automatically picking the best
overall choice for a given platform.

But now we're talking about different things... the WIN32 macro
shouldn't be needed in FileDescriptor.

--
Jeff Sturm
jsturm@sigma6.com

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Integrating Win32 changes
  2000-04-01  0:00 ` Per Bothner
  2000-04-01  0:00   ` Tom Tromey
@ 2000-04-01  0:00   ` Jeff Sturm
  2000-04-01  0:00     ` Per Bothner
  1 sibling, 1 reply; 19+ messages in thread
From: Jeff Sturm @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Per Bothner; +Cc: Jon Beniston, java-discuss

Per Bothner wrote:
> The specific issue about Win32 FileDescriptor are not specified using
> an int.  I would do:

Oh, it's an `int' all right:

CommonFunctions.h: HFILE STDCALL OpenFile(...)
Base.h: typedef int HFILE;

That might change with Win64, I don't know... we don't have to worry
about that for quite a while yet ;)

> -  // System's notion of file descriptor.
> +  // System's notion of file descriptor (use one or both):
>    private int fd;
> +  private gnu.gcj.RawData handle;
> 
> and you can hang your windows-specific data structures off `handle'.

Yuck.  Then we need extra code to allocate unique fd's, make it
thread-safe, etc.  I'd prefer to just cast HFILE to/from int, which is a
safe thing to do on any Win32 platform currently in use.

> To initialize in, out and err, we should perhaps do:
> 
>   public static final FileDescriptor in;
>   public static final FileDescriptor out;
>   public static final FileDescriptor err;
> 
>   private static native init();
>   static { init(); }
> 
> and have java::io::FileDescriptor::init() actually
> allocate in, out, and err.

Yes, I like that.

-- 
Jeff Sturm
jsturm@sigma6.com

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Integrating Win32 changes
  2000-04-01  0:00   ` Tom Tromey
@ 2000-04-01  0:00     ` Jon Beniston
  2000-04-01  0:00       ` Tom Tromey
  0 siblings, 1 reply; 19+ messages in thread
From: Jon Beniston @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Tom Tromey, Per Bothner; +Cc: java-discuss

> 
> Per> To initialize in, out and err, we should perhaps do:
> Per>   public static final FileDescriptor in;
> Per>   public static final FileDescriptor out;
> Per>   public static final FileDescriptor err;
> Per>   private static native init();
> Per>   static { init(); }
> Per> and have java::io::FileDescriptor::init() actually
> Per> allocate in, out, and err.
> 
> I like this too.
> 

I'd be happy with that. I'll implement it in my code... 

Jon Beniston.

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Integrating Win32 changes
  2000-04-01  0:00 ` Per Bothner
@ 2000-04-01  0:00   ` Tom Tromey
  2000-04-01  0:00     ` Jon Beniston
  2000-04-01  0:00   ` Jeff Sturm
  1 sibling, 1 reply; 19+ messages in thread
From: Tom Tromey @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Per Bothner; +Cc: Jon Beniston, java-discuss

Per> -  // System's notion of file descriptor.
Per> +  // System's notion of file descriptor (use one or both):
Per>    private int fd;
Per> +  private gnu.gcj.RawData handle;

I think this is the right thing to do.  The current approach was taken
simply because we hadn't invented RawData when FileDescriptor was
written.

We should also delete the "POSIXy" comment in FileDescriptor.java.

Per> To initialize in, out and err, we should perhaps do:
Per>   public static final FileDescriptor in;
Per>   public static final FileDescriptor out;
Per>   public static final FileDescriptor err;
Per>   private static native init();
Per>   static { init(); }
Per> and have java::io::FileDescriptor::init() actually
Per> allocate in, out, and err.

I like this too.

Tom

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Integrating Win32 changes
  2000-04-01  0:00     ` Jeff Sturm
@ 2000-04-01  0:00       ` Tom Tromey
  0 siblings, 0 replies; 19+ messages in thread
From: Tom Tromey @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Jeff Sturm; +Cc: Per Bothner, java-discuss

>>>>> "Jeff" == Jeff Sturm <jsturm@sigma6.com> writes:

Jeff> One could argue that WIN32 is a "feature" too, meaning the Win32
Jeff> API is available.

I see Windows as a family of features.  I don't think we need to have
a new macro for each member of the family, until we get to the point
where we need to conditionally compile depending on the target family
member (e.g., some API implemented on NT but not on WinCE).

Jeff> #if defined(WIN32) && !defined(__CYGWIN32__)
Jeff> ...
Jeff> #endif

This is a bit gross.  We could just introduce our own "Windows family"
macro and set it from configure.in as appropriate.

Tom

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Integrating Win32 changes
  2000-04-01  0:00     ` Jeff Sturm
@ 2000-04-01  0:00       ` Per Bothner
  0 siblings, 0 replies; 19+ messages in thread
From: Per Bothner @ 2000-04-01  0:00 UTC (permalink / raw)
  To: java-discuss

Jeff Sturm <jsturm@sigma6.com> writes:

> Perhaps.  As Per said, we may end up with three implementations of
> natFileDescriptor, for Posix, Win32 and stdio.

Four.  We already have natFileDescriptorEcos.cc (as well as
natFileDescriptorPosix.cc).
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Integrating Win32 changes
  2000-04-01  0:00 ` Jeff Sturm
  2000-04-01  0:00   ` Jon Beniston
@ 2000-04-01  0:00   ` Per Bothner
  2000-04-01  0:00     ` Jeff Sturm
  1 sibling, 1 reply; 19+ messages in thread
From: Per Bothner @ 2000-04-01  0:00 UTC (permalink / raw)
  To: java-discuss

Jeff Sturm <jsturm@sigma6.com> writes:

> "#ifdef WIN32" would probably be better unless the code really depends
> on Mingw32.  That'll benefit those who may be compiling with Cygwin or
> U/WIN, or other GCC-on-Windows environments.

Remember that as a general rule we want to avoid conditional
compilation using conditionals that test for specific hosts.  Instead,
we want to use conditionals that test for specific *features*.  For
example, when it comes to FileDescriptor, we don't want to test for
WIN32 or Mingw32, but for something more specific that identifies the
API.  After all, you might want to use Posix-style I/O on WIN32 (e.g.
if you're running CygWin32), so #ifdef WIN32 would do the wrong thing.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Integrating Win32 changes
  2000-04-01  0:00   ` Per Bothner
@ 2000-04-01  0:00     ` Jeff Sturm
  2000-04-01  0:00       ` Tom Tromey
  0 siblings, 1 reply; 19+ messages in thread
From: Jeff Sturm @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Per Bothner; +Cc: java-discuss

Per Bothner wrote:
> > "#ifdef WIN32" would probably be better unless the code really depends
> > on Mingw32.  That'll benefit those who may be compiling with Cygwin or
> > U/WIN, or other GCC-on-Windows environments.
> 
> Remember that as a general rule we want to avoid conditional
> compilation using conditionals that test for specific hosts.  Instead,
> we want to use conditionals that test for specific *features*.  For
> example, when it comes to FileDescriptor, we don't want to test for
> WIN32 or Mingw32, but for something more specific that identifies the
> API.  After all, you might want to use Posix-style I/O on WIN32 (e.g.
> if you're running CygWin32), so #ifdef WIN32 would do the wrong thing.

One could argue that WIN32 is a "feature" too, meaning the Win32 API is
available.  In the case of Cygwin you have a choice.  In the case of
Interix (for example), WIN32 should _not_ be defined since Win32 is not
accessible (though it runs on NT).

Some time ago on the Cygwin mailing list it was debated that WIN32
should be dropped from the predefines, since the Cygwin environment
masquerades as POSIX, and configure scripts sometimes get confused.  The
project leaders decided that it makes sense to define both WIN32 and
__CYGWIN32__ to indicate that both API's are available.  I understand
their point, although it leads to a lot of pecularities like:

#if defined(WIN32) && !defined(__CYGWIN32__)
...
#endif

(Those running Linux should be happy they only have glibc issues to
worry about.)

-- 
Jeff Sturm
jsturm@sigma6.com

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Integrating Win32 changes
  2000-04-01  0:00 ` Jeff Sturm
@ 2000-04-01  0:00   ` Jon Beniston
  2000-04-01  0:00     ` Jeff Sturm
  2000-04-01  0:00   ` Per Bothner
  1 sibling, 1 reply; 19+ messages in thread
From: Jon Beniston @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Jeff Sturm; +Cc: java-discuss

> Jon Beniston wrote:
> > First up, you can't do new FileDescriptor(0) for setting up the standard
i/o
> > streams (as is done in java/io/FileDescriptor), should I have a new file
> > Win32FileDescriptor.java or would it be best to implement a native
function
> > such as FileDescriptor::getStdHandle(int) for all ports.
>
> My impression is that FileDescriptor.java is portable enough, except for
> the in/out/err initializers.  A new native method should be OK, though
> the name "getStdHandle" sounds too Windows-ish for my taste...
>
> > Also, for native files where just a few changes are needed, such as
> > prims.cc, I'm putting #ifdef __MINGW32__ around the platform specific
code.
> > Is that cool? Where a lot of changes have to be made I'm implementing
them
> > in a new file.
>
> "#ifdef WIN32" would probably be better unless the code really depends
> on Mingw32.  That'll benefit those who may be compiling with Cygwin or
> U/WIN, or other GCC-on-Windows environments.

I think its best not to mix treat ming and cygwin the same. With cygwin you
can
use many of the posix type functions, but you cant with ming. IMHO, building
for cygwin would link to natFileDescriptorPosix.cc whereas a Ming build
would map to natFileDescriptorWin32.cc, for example.


^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Integrating Win32 changes
  2000-04-01  0:00 Integrating Win32 changes Jon Beniston
  2000-04-01  0:00 ` Per Bothner
@ 2000-04-01  0:00 ` Jeff Sturm
  2000-04-01  0:00   ` Jon Beniston
  2000-04-01  0:00   ` Per Bothner
  2000-04-01  0:00 ` Tom Tromey
  2 siblings, 2 replies; 19+ messages in thread
From: Jeff Sturm @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Jon Beniston; +Cc: java-discuss

Jon Beniston wrote:
> First up, you can't do new FileDescriptor(0) for setting up the standard i/o
> streams (as is done in java/io/FileDescriptor), should I have a new file
> Win32FileDescriptor.java or would it be best to implement a native function
> such as FileDescriptor::getStdHandle(int) for all ports.

My impression is that FileDescriptor.java is portable enough, except for
the in/out/err initializers.  A new native method should be OK, though
the name "getStdHandle" sounds too Windows-ish for my taste...

> Also, for native files where just a few changes are needed, such as
> prims.cc, I'm putting #ifdef __MINGW32__ around the platform specific code.
> Is that cool? Where a lot of changes have to be made I'm implementing them
> in a new file.

"#ifdef WIN32" would probably be better unless the code really depends
on Mingw32.  That'll benefit those who may be compiling with Cygwin or
U/WIN, or other GCC-on-Windows environments.

-- 
Jeff Sturm
jsturm@sigma6.com

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Integrating Win32 changes
@ 2000-04-01  0:00 Jon Beniston
  2000-04-01  0:00 ` Per Bothner
                   ` (2 more replies)
  0 siblings, 3 replies; 19+ messages in thread
From: Jon Beniston @ 2000-04-01  0:00 UTC (permalink / raw)
  To: java-discuss

Hi all,

I've a couple of questions on what you think the best way of integrating
changes needed for the Win32 port.

First up, you can't do new FileDescriptor(0) for setting up the standard i/o
streams (as is done in java/io/FileDescriptor), should I have a new file
Win32FileDescriptor.java or would it be best to implement a native function
such as FileDescriptor::getStdHandle(int) for all ports.

Also, for native files where just a few changes are needed, such as
prims.cc, I'm putting #ifdef __MINGW32__ around the platform specific code.
Is that cool? Where a lot of changes have to be made I'm implementing them
in a new file.

Cheers,
Jon Beniston.


^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Integrating Win32 changes
  2000-04-01  0:00 Integrating Win32 changes Jon Beniston
@ 2000-04-01  0:00 ` Per Bothner
  2000-04-01  0:00   ` Tom Tromey
  2000-04-01  0:00   ` Jeff Sturm
  2000-04-01  0:00 ` Jeff Sturm
  2000-04-01  0:00 ` Tom Tromey
  2 siblings, 2 replies; 19+ messages in thread
From: Per Bothner @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Jon Beniston; +Cc: java-discuss

"Jon Beniston" <jb7216@bristol.ac.uk> writes:

> First up, you can't do new FileDescriptor(0) for setting up the standard i/o
> streams (as is done in java/io/FileDescriptor), should I have a new file
> Win32FileDescriptor.java or would it be best to implement a native function
> such as FileDescriptor::getStdHandle(int) for all ports.

There ware various alternative solutions to these kinds of problem:
(1) Make FileDescriptor be an abstract call, with (for example)
Win32FileDescriptor as a sub-class.  The Java API doesn't allow that.
(2) Peer classes.  Define FileDescriptorPeer an as abstract class,
and then sub-classes such as Win32FileDescriptorPeer.  This is the
solution used by AWT.  The disadvantage is extra overhead, because
each call to a FileDescriptor must then make a virtual call
to a FileDescriptorPeer.
(3) Conditional compilation or separate implementation files.
That is what we currently do any, and seems best.

I suggest keeping FileDescriptor.java, but adding natFileDescriptorWin32.cc,
like we already have natFileDescriptorEcos.cc and natFileDescriptorPosix.cc.
You need to hack configure.in the select the correct value of FILE_DESCRIPTOR.
(That means you probably need CygWin32 to *build* libgcj - but you don't
necessarily need it to *run* libgcj.)

The specific issue about Win32 FileDescriptor are not specified using
an int.  I would do:

-  // System's notion of file descriptor.
+  // System's notion of file descriptor (use one or both):
   private int fd;
+  private gnu.gcj.RawData handle;

and you can hang your windows-specific data structures off `handle'.

To initialize in, out and err, we should perhaps do:

  public static final FileDescriptor in;
  public static final FileDescriptor out;
  public static final FileDescriptor err;

  private static native init();
  static { init(); }

and have java::io::FileDescriptor::init() actually
allocate in, out, and err.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Integrating Win32 changes
  2000-04-01  0:00     ` Per Bothner
@ 2000-04-01  0:00       ` Jeff Sturm
  2000-04-01  0:00         ` Tom Tromey
  0 siblings, 1 reply; 19+ messages in thread
From: Jeff Sturm @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Per Bothner; +Cc: java-discuss

Per Bothner wrote:
> > Yuck.  Then we need extra code to allocate unique fd's, make it
> > thread-safe, etc.  I'd prefer to just cast HFILE to/from int, which is a
> > safe thing to do on any Win32 platform currently in use.
> 
> I think you misunderstand.  If the "handle" you want to use is an int,
> just use that.  If the "handle" is a pointer, then using an int field
> is bad.  That is what the RawData feature is for. I don't see anything
> that would require us to allocate unique fd's or whatever.

I first thought you meant to create a mapping from fd to handle.  You
mean have both:

int fd;
RawData handle;

then ignore `handle' for POSIX targets, and ignore `fd' for Win32
targets?  I suppose you could do that, but why?  Win32 file "handles"
are _not_ pointers.  They are opaque 32-bit values, similar to POSIX
file descriptors.

> For example, I think it would make sense to implement a
> natFileDescriptorStdio.cc.   That would be more portable
> than natFileDescriptorPosix.cc (though less efficient).
> natFileDescriptorStdio would need to store the (FILE*) in a
> RawData handle rather than an int fd.

Yes, in that case RawData makes sense.

-- 
Jeff Sturm
jsturm@sigma6.com

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Integrating Win32 changes
  2000-04-01  0:00     ` Jon Beniston
@ 2000-04-01  0:00       ` Tom Tromey
  2000-04-01  0:00         ` Jon Beniston
  0 siblings, 1 reply; 19+ messages in thread
From: Tom Tromey @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Jon Beniston; +Cc: Tom Tromey, Per Bothner, java-discuss

>>>>> "Jon" == Jon Beniston <gizz_butt@hotmail.com> writes:

Jon> I'd be happy with that. I'll implement it in my code... 

BTW another prerequisite for getting your Windows changes into libgcj
is dealing with the paperwork (copyright assignment, etc).  You might
want to start this sooner rather than later.

Tom

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Integrating Win32 changes
  2000-04-01  0:00   ` Jeff Sturm
@ 2000-04-01  0:00     ` Per Bothner
  2000-04-01  0:00       ` Jeff Sturm
  0 siblings, 1 reply; 19+ messages in thread
From: Per Bothner @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Jeff Sturm; +Cc: java-discuss

Jeff Sturm <jsturm@sigma6.com> writes:

> Yuck.  Then we need extra code to allocate unique fd's, make it
> thread-safe, etc.  I'd prefer to just cast HFILE to/from int, which is a
> safe thing to do on any Win32 platform currently in use.

I think you misunderstand.  If the "handle" you want to use is an int,
just use that.  If the "handle" is a pointer, then using an int field
is bad.  That is what the RawData feature is for. I don't see anything
that would require us to allocate unique fd's or whatever.

For example, I think it would make sense to implement a
natFileDescriptorStdio.cc.   That would be more portable
than natFileDescriptorPosix.cc (though less efficient).
natFileDescriptorStdio would need to store the (FILE*) in a
RawData handle rather than an int fd.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Integrating Win32 changes
  2000-04-01  0:00         ` Tom Tromey
@ 2000-04-01  0:00           ` Per Bothner
  0 siblings, 0 replies; 19+ messages in thread
From: Per Bothner @ 2000-04-01  0:00 UTC (permalink / raw)
  To: java-discuss

Tom Tromey <tromey@cygnus.com> writes:

> No, he means just have "RawData handle", but store an int value in it
> (directly) in the cases where it makes sense (POSIX, Windows).

No, Jeff is right;  I did propose having two fields, an int and
a RawData.  I also consider what you're proposing:  A single
RawData field, and then cast to/from int on Posix/Windows systems.
That would be more efficient, but it may be uglier and in theory
less portable.  I.e. there may be architectures where you can't
safely convert an int to a (void*) and back again.  (However, if
we have natFileDescriptorStdio, such platforms could use that.)

I guess I would have a slight preference for using a single field
rather than two.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Integrating Win32 changes
  2000-04-01  0:00 Integrating Win32 changes Jon Beniston
  2000-04-01  0:00 ` Per Bothner
  2000-04-01  0:00 ` Jeff Sturm
@ 2000-04-01  0:00 ` Tom Tromey
  2 siblings, 0 replies; 19+ messages in thread
From: Tom Tromey @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Jon Beniston; +Cc: java-discuss

>>>>> "Jon" == Jon Beniston <jb7216@bristol.ac.uk> writes:

Jon> Also, for native files where just a few changes are needed, such
Jon> as prims.cc, I'm putting #ifdef __MINGW32__ around the platform
Jon> specific code.  Is that cool? Where a lot of changes have to be
Jon> made I'm implementing them in a new file.

It really depends.

In some situations it might be better to rename files and have
completely new implementations for new OS "flavor" ports (eg, Windows
-vs - POSIX) just like we do for natFileDescriptor.

This is particularly desirable when the code in question already has a
lot of preprocessor stuff in it -- at some point splitting it up is
just cleaner.

Tom

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Integrating Win32 changes
  2000-04-01  0:00       ` Jeff Sturm
@ 2000-04-01  0:00         ` Tom Tromey
  2000-04-01  0:00           ` Per Bothner
  0 siblings, 1 reply; 19+ messages in thread
From: Tom Tromey @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Jeff Sturm; +Cc: Per Bothner, java-discuss

>>>>> "Jeff" == Jeff Sturm <jsturm@sigma6.com> writes:

Jeff> I first thought you meant to create a mapping from fd to handle.
Jeff> You mean have both:
Jeff> int fd;
Jeff> RawData handle;
Jeff> then ignore `handle' for POSIX targets, and ignore `fd' for
Jeff> Win32 targets?

No, he means just have "RawData handle", but store an int value in it
(directly) in the cases where it makes sense (POSIX, Windows).

RawData is special.  A RawData field in an object is not scanned by
the collector.  We can put an int or a native pointer in it, according
to our preference.

Tom

^ permalink raw reply	[flat|nested] 19+ messages in thread

end of thread, other threads:[~2000-04-01  0:00 UTC | newest]

Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-04-01  0:00 Integrating Win32 changes Jon Beniston
2000-04-01  0:00 ` Per Bothner
2000-04-01  0:00   ` Tom Tromey
2000-04-01  0:00     ` Jon Beniston
2000-04-01  0:00       ` Tom Tromey
2000-04-01  0:00         ` Jon Beniston
2000-04-01  0:00   ` Jeff Sturm
2000-04-01  0:00     ` Per Bothner
2000-04-01  0:00       ` Jeff Sturm
2000-04-01  0:00         ` Tom Tromey
2000-04-01  0:00           ` Per Bothner
2000-04-01  0:00 ` Jeff Sturm
2000-04-01  0:00   ` Jon Beniston
2000-04-01  0:00     ` Jeff Sturm
2000-04-01  0:00       ` Per Bothner
2000-04-01  0:00   ` Per Bothner
2000-04-01  0:00     ` Jeff Sturm
2000-04-01  0:00       ` Tom Tromey
2000-04-01  0:00 ` Tom Tromey

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).