* A Lisp compiler?
@ 1999-02-01 8:23 ` Matthew X. Economou
1999-02-01 9:29 ` Ken Raeburn
1999-02-28 22:53 ` Matthew X. Economou
0 siblings, 2 replies; 264+ messages in thread
From: Matthew X. Economou @ 1999-02-01 8:23 UTC (permalink / raw)
To: egcs
Would there be any interest in work on a Lisp compiler and run-time
system? I've started to hack a parser together, and I have the
beginnings of a run-time sketched out. The more I examine the Lisp
specs and GCC's back end, the more I become convinced that a Lisp
front-end is possible. I'm aiming for conformance with ANSI Common
Lisp and possibly IEEE (R4RS) Scheme, including doo-dads like EVAL,
DEFMACRO, EXTEND-SYNTAX, and CALL/CC.
I just want to see if there'd be any interest in such a beast. If so,
I'll continue working on my parser and run-time.
--
"When I was a kid, I used to think that Dammit was God's last name, just like
Christ is Jesus' last name." - Kimberly Chapman in rec.humor.oracle.d
^ permalink raw reply [flat|nested] 264+ messages in thread
* Re: A Lisp compiler?
1999-02-01 8:23 ` A Lisp compiler? Matthew X. Economou
@ 1999-02-01 9:29 ` Ken Raeburn
1999-02-02 15:44 ` Matthew X. Economou
` (2 more replies)
1999-02-28 22:53 ` Matthew X. Economou
1 sibling, 3 replies; 264+ messages in thread
From: Ken Raeburn @ 1999-02-01 9:29 UTC (permalink / raw)
To: Matthew X. Economou; +Cc: egcs
Two thoughts:
1) Consider targeting languages that would be helpful to the GNU
project, like Emacs Lisp or (better, IMHO) Guile, which is Scheme
based.
2) Translating to C would likely be easier; do you gain much by
compiling directly? The generated C code can even be
platform-independent, meaning it could be shipped along with the
original lisp source for those who don't have the lisp compiler.
(E.g., in the Emacs or Guile distributions.)
I'd suggest guile over elisp because the lexical scoping plays more
nicely with such notions as multi-threaded programming. Seems to me
with multi-threaded lisp, either you have to have cooperative
threading and wind/unwind the local `let' bindings on each thread
switch (not consistent with using pre-emptive threading packages and
other languages), or each variable reference may have to walk a list
of bindings looking for the "most local" value for the variable. With
lexical scoping, a `let' binding translates to an automatic variable.
This also leaves more room for optimization when calling arbitrary
functions.
Also, Guile is intended to work as an extension language for multiple
programs (a la Tcl), so compiling it would (eventually, in theory)
help people maintaining or extending those programs. Though I don't
know of many programs using it *yet*, aside from gimp.
I believe there's already a Scheme->C translator available for Guile,
but I don't know the specifics. But if there is more to be gained by
translating directly to assembly, that you couldn't get translating to
C (or, say, GNU C with one or two new extensions), then go for it.
Certainly the debugging information would be more likely to reflect
the original code instead of the intermediate C code. But then you
want gdb support too. :-)
This is all just MHO; there are minds on this list more wise in the
Ways of Many Parentheses than mine.
Ken
^ permalink raw reply [flat|nested] 264+ messages in thread
* Re: A Lisp compiler?
1999-02-01 9:29 ` Ken Raeburn
@ 1999-02-02 15:44 ` Matthew X. Economou
[not found] ` < w4ou2x4jrke.fsf@nemesis.irtnog.org >
1999-02-28 22:53 ` Matthew X. Economou
1999-02-19 23:14 ` Matthias Hölzl
1999-02-28 22:53 ` Ken Raeburn
2 siblings, 2 replies; 264+ messages in thread
From: Matthew X. Economou @ 1999-02-02 15:44 UTC (permalink / raw)
To: egcs
>>>>> "KR" == Ken Raeburn <raeburn@cygnus.com> writes:
Thanks for the quick reply, Ken.
KR> Consider targeting languages that would be helpful to the GNU
KR> project, like Emacs Lisp or (better, IMHO) Guile, which is
KR> Scheme based.
I believe that Common Lisp is a little more featureful than Emacs
Lisp. Syntactically, the languages are identical, so building some
kind of library/package that implemented those special forms,
functions, and macros unique to Elisp is (famous last words) "fairly
trivial".
In which case, I'd argue it is better to have the more portable Common
Lisp environment with which to start.
(The same kind of argument goes for GUILE versus R4RS/R5RS Scheme.
It'd be preferable to have the standard (and very powerful) Scheme
environment to begin with, then build up the extension language from
there. Building an extension language out of some kind of base
language is something the Lisp language family is VERY good at.)
KR> Translating to C would likely be easier; do you gain much by
KR> compiling directly? The generated C code can even be
KR> platform-independent, meaning it could be shipped along with
KR> the original lisp source for those who don't have the lisp
KR> compiler. (E.g., in the Emacs or Guile distributions.)
You may very well be correct, here. In this case, GNU Common Lisp
already does translate to C. (GCL follows CLtL1 pretty closely. It
isn't quite ANSI-compliant, but it is pretty close. If you're
interested, compiling to C is described in Christian Queinnec's
excellent _Lisp in Small Pieces_, chapter 10.)
Personally, I think machine code generation would be a much cooler
hack, especially since the run-time environment must include
facilities for interpretation (aka EVAL).
KR> I'd suggest guile over elisp because the lexical scoping plays
KR> more nicely with such notions as multi-threaded programming.
KR> Seems to me with multi-threaded lisp, either you have to have
KR> cooperative threading and wind/unwind the local `let' bindings
KR> on each thread switch (not consistent with using pre-emptive
KR> threading packages and other languages), or each variable
KR> reference may have to walk a list of bindings looking for the
KR> "most local" value for the variable. With lexical scoping, a
KR> `let' binding translates to an automatic variable. This also
KR> leaves more room for optimization when calling arbitrary
KR> functions.
I didn't understand a word in this paragraph. Would you take a shot
at explaining this to me off-list?
KR> Also, Guile is intended to work as an extension language for
KR> multiple programs (a la Tcl), so compiling it would
KR> (eventually, in theory) help people maintaining or extending
KR> those programs.
No arguments here. Finding a portable way to interface C (or other
languages) to Lisp (and vice versa) would be a Good Thing, regardless
of the specific Lisp variant being compiled.
KR> But if there is more to be gained by translating directly to
KR> assembly, that you couldn't get translating to C (or, say, GNU
KR> C with one or two new extensions), then go for it.
Does hubris count? :)
KR> Certainly the debugging information would be more likely to
KR> reflect the original code instead of the intermediate C code.
KR> But then you want gdb support too. :-)
But of course! And exception handling, and run-time type information,
and... and... and...! ;)
KR> This is all just MHO; there are minds on this list more wise
KR> in the Ways of Many Parentheses than mine.
Me too. And goddess only knows if this "project" will survive the
month; at this point I'm too ignorant to just give up now. *wink*
Is there anyone else out there in EGCS-land with comments on yet
another GCC front-end (and run-time system), one that will handle
Common Lisp?
--
"BABYLON 5! A five-mile long cement mixer of truth, pouring out the
Concrete of Nice-Nice in a long, grey ribbon into the future, to form a
***SIDE WALK OF JUSTICE!!***"
- The Tick on Babylon 5
^ permalink raw reply [flat|nested] 264+ messages in thread
[parent not found: < w4ou2x4jrke.fsf@nemesis.irtnog.org >]
* [Meta] Re: A Lisp compiler?
[not found] ` < w4ou2x4jrke.fsf@nemesis.irtnog.org >
@ 1999-02-02 16:14 ` Paul Derbyshire
1999-02-28 22:53 ` Paul Derbyshire
0 siblings, 1 reply; 264+ messages in thread
From: Paul Derbyshire @ 1999-02-02 16:14 UTC (permalink / raw)
To: egcs
At 06:48 PM 2/2/99 -0500, you wrote:
> X-Face: meow meow meow meow meow meow meow meow meow meow meow meow meow
meow
meow meow meow meow meow meow meow meow meow meow meow meow meow meow
meow meow meow meow meow meow meow meow meow meow meow meow meow meow
Besides wasting bandwidth, what the devil does this accomplish?
> X-Attribution: XF
Oh God please tell me you don't use XF Mail.
They had that installed on the X workstations at university once.
Then one day someone used XF and at some point it hung... was kill()ed and
reran. Then it shortly hung the whole X client. Client was killed and
restarted and logged back onto server. XF was run again and after a while
it hung. Client was frozen again. The guy killed the client, tried to log
back on, and found that all 20 of the LANned X servers were now unreachable.
They should have used Red Hat.
And they should have used another mail client...
I still have no idea how an X client app could do something to bring down
the X server it was using and then bring down everything connected to that
X server. I can only guess that when one server hung it left all the others
blocking on access to a shared file system. The hosts were reachable again
not too long after; I guess the file server timed out the first hung X
server and the others got to resume using it. That still leaves me
wondering how the devil the first server went down...
--
.*. "Clouds are not spheres, mountains are not cones, coastlines are not
-() < circles, and bark is not smooth, nor does lightning travel in a
`*' straight line." -------------------------------------------------
-- B. Mandelbrot | http://surf.to/pgd.net
_____________________ ____|________ Paul Derbyshire pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|
^ permalink raw reply [flat|nested] 264+ messages in thread
* [Meta] Re: A Lisp compiler?
1999-02-02 16:14 ` [Meta] " Paul Derbyshire
@ 1999-02-28 22:53 ` Paul Derbyshire
0 siblings, 0 replies; 264+ messages in thread
From: Paul Derbyshire @ 1999-02-28 22:53 UTC (permalink / raw)
To: egcs
At 06:48 PM 2/2/99 -0500, you wrote:
> X-Face: meow meow meow meow meow meow meow meow meow meow meow meow meow
meow
meow meow meow meow meow meow meow meow meow meow meow meow meow meow
meow meow meow meow meow meow meow meow meow meow meow meow meow meow
Besides wasting bandwidth, what the devil does this accomplish?
> X-Attribution: XF
Oh God please tell me you don't use XF Mail.
They had that installed on the X workstations at university once.
Then one day someone used XF and at some point it hung... was kill()ed and
reran. Then it shortly hung the whole X client. Client was killed and
restarted and logged back onto server. XF was run again and after a while
it hung. Client was frozen again. The guy killed the client, tried to log
back on, and found that all 20 of the LANned X servers were now unreachable.
They should have used Red Hat.
And they should have used another mail client...
I still have no idea how an X client app could do something to bring down
the X server it was using and then bring down everything connected to that
X server. I can only guess that when one server hung it left all the others
blocking on access to a shared file system. The hosts were reachable again
not too long after; I guess the file server timed out the first hung X
server and the others got to resume using it. That still leaves me
wondering how the devil the first server went down...
--
.*. "Clouds are not spheres, mountains are not cones, coastlines are not
-() < circles, and bark is not smooth, nor does lightning travel in a
`*' straight line." -------------------------------------------------
-- B. Mandelbrot | http://surf.to/pgd.net
_____________________ ____|________ Paul Derbyshire pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|
^ permalink raw reply [flat|nested] 264+ messages in thread
* Re: A Lisp compiler?
1999-02-02 15:44 ` Matthew X. Economou
[not found] ` < w4ou2x4jrke.fsf@nemesis.irtnog.org >
@ 1999-02-28 22:53 ` Matthew X. Economou
1 sibling, 0 replies; 264+ messages in thread
From: Matthew X. Economou @ 1999-02-28 22:53 UTC (permalink / raw)
To: egcs
>>>>> "KR" == Ken Raeburn <raeburn@cygnus.com> writes:
Thanks for the quick reply, Ken.
KR> Consider targeting languages that would be helpful to the GNU
KR> project, like Emacs Lisp or (better, IMHO) Guile, which is
KR> Scheme based.
I believe that Common Lisp is a little more featureful than Emacs
Lisp. Syntactically, the languages are identical, so building some
kind of library/package that implemented those special forms,
functions, and macros unique to Elisp is (famous last words) "fairly
trivial".
In which case, I'd argue it is better to have the more portable Common
Lisp environment with which to start.
(The same kind of argument goes for GUILE versus R4RS/R5RS Scheme.
It'd be preferable to have the standard (and very powerful) Scheme
environment to begin with, then build up the extension language from
there. Building an extension language out of some kind of base
language is something the Lisp language family is VERY good at.)
KR> Translating to C would likely be easier; do you gain much by
KR> compiling directly? The generated C code can even be
KR> platform-independent, meaning it could be shipped along with
KR> the original lisp source for those who don't have the lisp
KR> compiler. (E.g., in the Emacs or Guile distributions.)
You may very well be correct, here. In this case, GNU Common Lisp
already does translate to C. (GCL follows CLtL1 pretty closely. It
isn't quite ANSI-compliant, but it is pretty close. If you're
interested, compiling to C is described in Christian Queinnec's
excellent _Lisp in Small Pieces_, chapter 10.)
Personally, I think machine code generation would be a much cooler
hack, especially since the run-time environment must include
facilities for interpretation (aka EVAL).
KR> I'd suggest guile over elisp because the lexical scoping plays
KR> more nicely with such notions as multi-threaded programming.
KR> Seems to me with multi-threaded lisp, either you have to have
KR> cooperative threading and wind/unwind the local `let' bindings
KR> on each thread switch (not consistent with using pre-emptive
KR> threading packages and other languages), or each variable
KR> reference may have to walk a list of bindings looking for the
KR> "most local" value for the variable. With lexical scoping, a
KR> `let' binding translates to an automatic variable. This also
KR> leaves more room for optimization when calling arbitrary
KR> functions.
I didn't understand a word in this paragraph. Would you take a shot
at explaining this to me off-list?
KR> Also, Guile is intended to work as an extension language for
KR> multiple programs (a la Tcl), so compiling it would
KR> (eventually, in theory) help people maintaining or extending
KR> those programs.
No arguments here. Finding a portable way to interface C (or other
languages) to Lisp (and vice versa) would be a Good Thing, regardless
of the specific Lisp variant being compiled.
KR> But if there is more to be gained by translating directly to
KR> assembly, that you couldn't get translating to C (or, say, GNU
KR> C with one or two new extensions), then go for it.
Does hubris count? :)
KR> Certainly the debugging information would be more likely to
KR> reflect the original code instead of the intermediate C code.
KR> But then you want gdb support too. :-)
But of course! And exception handling, and run-time type information,
and... and... and...! ;)
KR> This is all just MHO; there are minds on this list more wise
KR> in the Ways of Many Parentheses than mine.
Me too. And goddess only knows if this "project" will survive the
month; at this point I'm too ignorant to just give up now. *wink*
Is there anyone else out there in EGCS-land with comments on yet
another GCC front-end (and run-time system), one that will handle
Common Lisp?
--
"BABYLON 5! A five-mile long cement mixer of truth, pouring out the
Concrete of Nice-Nice in a long, grey ribbon into the future, to form a
***SIDE WALK OF JUSTICE!!***"
- The Tick on Babylon 5
^ permalink raw reply [flat|nested] 264+ messages in thread
* Re: A Lisp compiler?
1999-02-01 9:29 ` Ken Raeburn
1999-02-02 15:44 ` Matthew X. Economou
@ 1999-02-19 23:14 ` Matthias Hölzl
1999-02-28 22:53 ` Matthias Hölzl
1999-02-28 22:53 ` Ken Raeburn
2 siblings, 1 reply; 264+ messages in thread
From: Matthias Hölzl @ 1999-02-19 23:14 UTC (permalink / raw)
To: Ken Raeburn; +Cc: Matthew X. Economou, egcs
Ken Raeburn <raeburn@cygnus.com> writes:
> Two thoughts:
>
> 1) Consider targeting languages that would be helpful to the GNU
> project, like Emacs Lisp or (better, IMHO) Guile, which is Scheme
> based.
I am surely biased since I am one of the maintainers of d2c, but
another good choice would be the Dylan language. Dylan is
semantically very close to Common Lisp/CLOS, but written in algebraic
notation. Unlike CL which pretty much supposes some "image-based"
implementation if you want to support the whole language, Dylan was
designed to allow efficient batch compilation. This means that the
language is slightly less dynamic, but it is much better suited to
compile into stand-alone executables.
There is a free Dylan to C compiler available and actively maintained,
and a lot of libraries exist or are in development (see our site at
www.gwydiondylan.org). D2c supports a fairly good C-FFI and is
designed to allow for multiple back-ends, so it should not be too hard
to write an additional back-end that interfaces d2c to egcs.
If you want to write a Common Lisp front-end you should have a look at
the code available from www.cons.org; especially the CMUCL compiler is
a very well written piece of software and it is in the public domain,
so you might be able to reuse a lot of its code. I think that it
might be a good idea to use their ICR or maybe even the low level IR
as the starting point for a CL egcs front end.
If you want to write a Scheme front end you may want to look at the
bigloo Scheme to C compiler. It has a very clean internal structure,
some nice extension like a built in lexer/parser generator and its
author is generally very helpful.
> 2) Translating to C would likely be easier; do you gain much by
> compiling directly? The generated C code can even be
> platform-independent, meaning it could be shipped along with the
> original lisp source for those who don't have the lisp compiler.
> (E.g., in the Emacs or Guile distributions.)
For CL or Dylan compiling to C is an attractive solution for a batch
compiler. The main disadvantage seems to be the increased compilation
time. However, AFAIK, it is virtually impossible to compile Scheme to
C and still be fully conforming to R5RS since Scheme is "properly tail
recursive", which means that cycles of function calls like f -> g -> h
-> f are not allowed to consume stack space if all the calls are made
in tail position. E.g.
(define (f x) (g x 1))
(define (g x y) (if (= y 2) x (h 3)))
(define (h x) (f 42))
(f 0)
has to loop indefinitely without running out of space. All Scheme to
C compilers that I am familiar with only guarantee tail call
elimination on self tail calls. It seems that in order to provide
full tail recursion you'd have to compile the whole program into one
large C function and implement function calls via gotos (which makes
callbacks from external libraries very hard).
Regards,
Matthias
^ permalink raw reply [flat|nested] 264+ messages in thread
* Re: A Lisp compiler?
1999-02-19 23:14 ` Matthias Hölzl
@ 1999-02-28 22:53 ` Matthias Hölzl
0 siblings, 0 replies; 264+ messages in thread
From: Matthias Hölzl @ 1999-02-28 22:53 UTC (permalink / raw)
To: Ken Raeburn; +Cc: Matthew X. Economou, egcs
Ken Raeburn <raeburn@cygnus.com> writes:
> Two thoughts:
>
> 1) Consider targeting languages that would be helpful to the GNU
> project, like Emacs Lisp or (better, IMHO) Guile, which is Scheme
> based.
I am surely biased since I am one of the maintainers of d2c, but
another good choice would be the Dylan language. Dylan is
semantically very close to Common Lisp/CLOS, but written in algebraic
notation. Unlike CL which pretty much supposes some "image-based"
implementation if you want to support the whole language, Dylan was
designed to allow efficient batch compilation. This means that the
language is slightly less dynamic, but it is much better suited to
compile into stand-alone executables.
There is a free Dylan to C compiler available and actively maintained,
and a lot of libraries exist or are in development (see our site at
www.gwydiondylan.org). D2c supports a fairly good C-FFI and is
designed to allow for multiple back-ends, so it should not be too hard
to write an additional back-end that interfaces d2c to egcs.
If you want to write a Common Lisp front-end you should have a look at
the code available from www.cons.org; especially the CMUCL compiler is
a very well written piece of software and it is in the public domain,
so you might be able to reuse a lot of its code. I think that it
might be a good idea to use their ICR or maybe even the low level IR
as the starting point for a CL egcs front end.
If you want to write a Scheme front end you may want to look at the
bigloo Scheme to C compiler. It has a very clean internal structure,
some nice extension like a built in lexer/parser generator and its
author is generally very helpful.
> 2) Translating to C would likely be easier; do you gain much by
> compiling directly? The generated C code can even be
> platform-independent, meaning it could be shipped along with the
> original lisp source for those who don't have the lisp compiler.
> (E.g., in the Emacs or Guile distributions.)
For CL or Dylan compiling to C is an attractive solution for a batch
compiler. The main disadvantage seems to be the increased compilation
time. However, AFAIK, it is virtually impossible to compile Scheme to
C and still be fully conforming to R5RS since Scheme is "properly tail
recursive", which means that cycles of function calls like f -> g -> h
-> f are not allowed to consume stack space if all the calls are made
in tail position. E.g.
(define (f x) (g x 1))
(define (g x y) (if (= y 2) x (h 3)))
(define (h x) (f 42))
(f 0)
has to loop indefinitely without running out of space. All Scheme to
C compilers that I am familiar with only guarantee tail call
elimination on self tail calls. It seems that in order to provide
full tail recursion you'd have to compile the whole program into one
large C function and implement function calls via gotos (which makes
callbacks from external libraries very hard).
Regards,
Matthias
^ permalink raw reply [flat|nested] 264+ messages in thread
* Re: A Lisp compiler?
1999-02-01 9:29 ` Ken Raeburn
1999-02-02 15:44 ` Matthew X. Economou
1999-02-19 23:14 ` Matthias Hölzl
@ 1999-02-28 22:53 ` Ken Raeburn
2 siblings, 0 replies; 264+ messages in thread
From: Ken Raeburn @ 1999-02-28 22:53 UTC (permalink / raw)
To: Matthew X. Economou; +Cc: egcs
Two thoughts:
1) Consider targeting languages that would be helpful to the GNU
project, like Emacs Lisp or (better, IMHO) Guile, which is Scheme
based.
2) Translating to C would likely be easier; do you gain much by
compiling directly? The generated C code can even be
platform-independent, meaning it could be shipped along with the
original lisp source for those who don't have the lisp compiler.
(E.g., in the Emacs or Guile distributions.)
I'd suggest guile over elisp because the lexical scoping plays more
nicely with such notions as multi-threaded programming. Seems to me
with multi-threaded lisp, either you have to have cooperative
threading and wind/unwind the local `let' bindings on each thread
switch (not consistent with using pre-emptive threading packages and
other languages), or each variable reference may have to walk a list
of bindings looking for the "most local" value for the variable. With
lexical scoping, a `let' binding translates to an automatic variable.
This also leaves more room for optimization when calling arbitrary
functions.
Also, Guile is intended to work as an extension language for multiple
programs (a la Tcl), so compiling it would (eventually, in theory)
help people maintaining or extending those programs. Though I don't
know of many programs using it *yet*, aside from gimp.
I believe there's already a Scheme->C translator available for Guile,
but I don't know the specifics. But if there is more to be gained by
translating directly to assembly, that you couldn't get translating to
C (or, say, GNU C with one or two new extensions), then go for it.
Certainly the debugging information would be more likely to reflect
the original code instead of the intermediate C code. But then you
want gdb support too. :-)
This is all just MHO; there are minds on this list more wise in the
Ways of Many Parentheses than mine.
Ken
^ permalink raw reply [flat|nested] 264+ messages in thread
* A Lisp compiler?
1999-02-01 8:23 ` A Lisp compiler? Matthew X. Economou
1999-02-01 9:29 ` Ken Raeburn
@ 1999-02-28 22:53 ` Matthew X. Economou
1 sibling, 0 replies; 264+ messages in thread
From: Matthew X. Economou @ 1999-02-28 22:53 UTC (permalink / raw)
To: egcs
Would there be any interest in work on a Lisp compiler and run-time
system? I've started to hack a parser together, and I have the
beginnings of a run-time sketched out. The more I examine the Lisp
specs and GCC's back end, the more I become convinced that a Lisp
front-end is possible. I'm aiming for conformance with ANSI Common
Lisp and possibly IEEE (R4RS) Scheme, including doo-dads like EVAL,
DEFMACRO, EXTEND-SYNTAX, and CALL/CC.
I just want to see if there'd be any interest in such a beast. If so,
I'll continue working on my parser and run-time.
--
"When I was a kid, I used to think that Dammit was God's last name, just like
Christ is Jesus' last name." - Kimberly Chapman in rec.humor.oracle.d
^ permalink raw reply [flat|nested] 264+ messages in thread
* Confirmed template parsing bug: bug in error message generation.
@ 1999-02-27 21:39 ` Paul Derbyshire
1999-02-28 22:53 ` Paul Derbyshire
1999-03-01 0:02 ` Alexandre Oliva
0 siblings, 2 replies; 264+ messages in thread
From: Paul Derbyshire @ 1999-02-27 21:39 UTC (permalink / raw)
To: egcs, egcs-bugs
At 07:07 PM 2/27/99 PST, I wrote:
> So there are only two possibilities:
> 1. A Mandelbug that causes the compiler to barf on legitimate
> template instance names under unspecified and complex
> circumstances. Or,
> 2. A bug that causes it to output a bogus parse error message instead
> of a real undeclared name error message under unspecified and
> complex conditions.
> Either of these is a parser bug, one in parsing itself and one in the >
generating of the correct error message for an error.
Well, I checked and it seems in my original code, I forgot to import
math_traits from a namespace. So there are actually 2 errors, which was the
cause of the confusion:
Error #1, in my code, missing using declaration causing math_traits
to not be in scope, setting me up to be dinged by:
Error #2, in egcs, wrong error message is output. Further testing
reveals that
extern foo<int> baz;
and the like will produce bogus parse errors instead of
the correct error, which is that the name 'foo' is
undeclared.
(Copy the above line and paste it into a blank text docuemnt and save as
foo.cc, and type gcc foo.cc -W -Wall -Werror -O1. You get
foo.cc:1: syntax error before ';'
and the correct error is
foo.cc:1: 'foo' undeclared
foo.cc:1: (Each undeclared identifier is reported only once etc. etc.
--
.*. "Clouds are not spheres, mountains are not cones, coastlines are not
-() < circles, and bark is not smooth, nor does lightning travel in a
`*' straight line." -------------------------------------------------
-- B. Mandelbrot | http://surf.to/pgd.net
_____________________ ____|________ Paul Derbyshire pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|
^ permalink raw reply [flat|nested] 264+ messages in thread
* Confirmed template parsing bug: bug in error message generation.
1999-02-27 21:39 ` Confirmed template parsing bug: bug in error message generation Paul Derbyshire
@ 1999-02-28 22:53 ` Paul Derbyshire
1999-03-01 0:02 ` Alexandre Oliva
1 sibling, 0 replies; 264+ messages in thread
From: Paul Derbyshire @ 1999-02-28 22:53 UTC (permalink / raw)
To: egcs, egcs-bugs
At 07:07 PM 2/27/99 PST, I wrote:
> So there are only two possibilities:
> 1. A Mandelbug that causes the compiler to barf on legitimate
> template instance names under unspecified and complex
> circumstances. Or,
> 2. A bug that causes it to output a bogus parse error message instead
> of a real undeclared name error message under unspecified and
> complex conditions.
> Either of these is a parser bug, one in parsing itself and one in the >
generating of the correct error message for an error.
Well, I checked and it seems in my original code, I forgot to import
math_traits from a namespace. So there are actually 2 errors, which was the
cause of the confusion:
Error #1, in my code, missing using declaration causing math_traits
to not be in scope, setting me up to be dinged by:
Error #2, in egcs, wrong error message is output. Further testing
reveals that
extern foo<int> baz;
and the like will produce bogus parse errors instead of
the correct error, which is that the name 'foo' is
undeclared.
(Copy the above line and paste it into a blank text docuemnt and save as
foo.cc, and type gcc foo.cc -W -Wall -Werror -O1. You get
foo.cc:1: syntax error before ';'
and the correct error is
foo.cc:1: 'foo' undeclared
foo.cc:1: (Each undeclared identifier is reported only once etc. etc.
--
.*. "Clouds are not spheres, mountains are not cones, coastlines are not
-() < circles, and bark is not smooth, nor does lightning travel in a
`*' straight line." -------------------------------------------------
-- B. Mandelbrot | http://surf.to/pgd.net
_____________________ ____|________ Paul Derbyshire pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|
^ permalink raw reply [flat|nested] 264+ messages in thread
* Re: Confirmed template parsing bug: bug in error message generation.
1999-02-27 21:39 ` Confirmed template parsing bug: bug in error message generation Paul Derbyshire
1999-02-28 22:53 ` Paul Derbyshire
@ 1999-03-01 0:02 ` Alexandre Oliva
[not found] ` < oriuclljxv.fsf@araguaia.dcc.unicamp.br >
1999-03-31 23:46 ` Alexandre Oliva
1 sibling, 2 replies; 264+ messages in thread
From: Alexandre Oliva @ 1999-03-01 0:02 UTC (permalink / raw)
To: Paul Derbyshire; +Cc: egcs, egcs-bugs
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 748 bytes --]
On Feb 28, 1999, Paul Derbyshire <pderbysh@usa.net> wrote:
> Well, I checked and it seems in my original code, I forgot to import
> math_traits from a namespace. So there are actually 2 errors,
Then please post a bug report as recommended in
http://egcs.cygnus.com/faq.html#bugreport , i.e., containing a single
code snippet that demonstrates the problem and a description of the
host in which you have observed the problem, otherwise lots of people
may have to spend time re-creating the code snippet you already have.
Thanks
--
Alexandre Oliva http://www.dcc.unicamp.br/~oliva aoliva@{acm.org,computer.org}
oliva@{dcc.unicamp.br,gnu.org,egcs.cygnus.com,samba.org}
Instituto de Computação, Universidade Estadual de Campinas, SP, Brasil
^ permalink raw reply [flat|nested] 264+ messages in thread
[parent not found: < oriuclljxv.fsf@araguaia.dcc.unicamp.br >]
* Re: Confirmed template parsing bug: bug in error message generation.
[not found] ` < oriuclljxv.fsf@araguaia.dcc.unicamp.br >
@ 1999-03-02 8:43 ` Paul Derbyshire
[not found] ` < 3.0.6.32.19990302114234.0086bd80@pop.globalserve.net >
` (2 more replies)
0 siblings, 3 replies; 264+ messages in thread
From: Paul Derbyshire @ 1999-03-02 8:43 UTC (permalink / raw)
To: egcs, egcs-bugs
At 04:59 AM 3/1/99 -0300, you wrote:
>Then please post a bug report...
I already did!
>...containing a single code snippet that demonstrates the problem...
"extern foo<int> bar;"
Parse error, but line is well-formed; should be undeclared identifier
"foo". Caused a 4 hour work stoppage here with people trying to track down
obscure aspects of the standard regarding templates thinking they made a
subtly ill-formed template declaration, and then throwing "typename"
qualifiers around at random half-heartedly, before suspecting it might be a
compiler bug, all of it triggered by a simple use of a symbol not imported
from its namespace. :-)
>...and a description of the host in which you have observed the
>problem...
x86-MSDOS. Which anyone who has read the original stuff will know. Not that
there is a snowball's chance in hell that the target has any influence
whatsoever on the *parser* :-)
>otherwise lots of people may have to spend time re-creating the code
>snippet you already have.
Why you believe this is beyond me, since the code snippet (above) was in
the very post you quoted IIRC, and the target, even if relevant for parser
issues, has been referred to be my in the past also.
Copied to egcs-bugs.
--
.*. "Clouds are not spheres, mountains are not cones, coastlines are not
-() < circles, and bark is not smooth, nor does lightning travel in a
`*' straight line." -------------------------------------------------
-- B. Mandelbrot | http://surf.to/pgd.net
_____________________ ____|________ Paul Derbyshire pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|
^ permalink raw reply [flat|nested] 264+ messages in thread
[parent not found: < 3.0.6.32.19990302114234.0086bd80@pop.globalserve.net >]
* Re: Confirmed template parsing bug: bug in error message generation.
[not found] ` < 3.0.6.32.19990302114234.0086bd80@pop.globalserve.net >
@ 1999-03-02 9:26 ` Robert Lipe
1999-03-31 23:46 ` Robert Lipe
0 siblings, 1 reply; 264+ messages in thread
From: Robert Lipe @ 1999-03-02 9:26 UTC (permalink / raw)
To: Paul Derbyshire; +Cc: egcs, egcs-bugs
> >...containing a single code snippet that demonstrates the problem...
> "extern foo<int> bar;"
>
> Parse error, but line is well-formed; should be undeclared identifier
I cannot confirm or deny of the line is well formed, but the
(EDGFE-based) UW C++ compiler generates what looks like a more helpful
error message.
$ CC /tmp/p.cc
"/tmp/p.cc", line 1: error: foo is not a class template
extern foo<int> bar;
^
^ permalink raw reply [flat|nested] 264+ messages in thread
* Re: Confirmed template parsing bug: bug in error message generation.
1999-03-02 9:26 ` Robert Lipe
@ 1999-03-31 23:46 ` Robert Lipe
0 siblings, 0 replies; 264+ messages in thread
From: Robert Lipe @ 1999-03-31 23:46 UTC (permalink / raw)
To: Paul Derbyshire; +Cc: egcs, egcs-bugs
> >...containing a single code snippet that demonstrates the problem...
> "extern foo<int> bar;"
>
> Parse error, but line is well-formed; should be undeclared identifier
I cannot confirm or deny of the line is well formed, but the
(EDGFE-based) UW C++ compiler generates what looks like a more helpful
error message.
$ CC /tmp/p.cc
"/tmp/p.cc", line 1: error: foo is not a class template
extern foo<int> bar;
^
^ permalink raw reply [flat|nested] 264+ messages in thread
* Re: Confirmed template parsing bug: bug in error message generation.
1999-03-02 8:43 ` Paul Derbyshire
[not found] ` < 3.0.6.32.19990302114234.0086bd80@pop.globalserve.net >
@ 1999-03-02 22:22 ` Alexandre Oliva
1999-03-31 23:46 ` Alexandre Oliva
1999-03-31 23:46 ` Paul Derbyshire
2 siblings, 1 reply; 264+ messages in thread
From: Alexandre Oliva @ 1999-03-02 22:22 UTC (permalink / raw)
To: Paul Derbyshire; +Cc: egcs, egcs-bugs
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1665 bytes --]
On Mar 2, 1999, Paul Derbyshire <pderbysh@usa.net> wrote:
> At 04:59 AM 3/1/99 -0300, you wrote:
>> Then please post a bug report...
> I already did!
>> ...containing a single code snippet that demonstrates the problem...
> "extern foo<int> bar;"
> Parse error, but line is well-formed;
Without the quotes, I suppose :-)
And it is not well-formed if foo is not declared as a template yet,
but I agree that the message could be improved.
>> ...and a description of the host in which you have observed the
>> problem...
> x86-MSDOS. Which anyone who has read the original stuff will know.
Bug reports are usually kept by developers in mailboxes or such, and
it's very good to have all the needed information in a single
message, rather than having to collect it from dozens of different
messages. That's why I asked for a complete bug report.
> Not that there is a snowball's chance in hell that the target has
> any influence whatsoever on the *parser* :-)
Platform-dependent memory corruption can damage the symbol table,
which may lead to parse errors.
>> otherwise lots of people may have to spend time re-creating the code
>> snippet you already have.
> Why you believe this is beyond me, since the code snippet (above) was in
> the very post you quoted IIRC
Sorry, I did not understand that was the *whole* code snippet.
Thanks for re-posting it, anyway.
> Copied to egcs-bugs.
That's where bug reports belong; thanks :-)
--
Alexandre Oliva http://www.dcc.unicamp.br/~oliva aoliva@{acm.org,computer.org}
oliva@{dcc.unicamp.br,gnu.org,egcs.cygnus.com,samba.org}
Instituto de Computação, Universidade Estadual de Campinas, SP, Brasil
^ permalink raw reply [flat|nested] 264+ messages in thread
* Re: Confirmed template parsing bug: bug in error message generation.
1999-03-02 22:22 ` Alexandre Oliva
@ 1999-03-31 23:46 ` Alexandre Oliva
0 siblings, 0 replies; 264+ messages in thread
From: Alexandre Oliva @ 1999-03-31 23:46 UTC (permalink / raw)
To: Paul Derbyshire; +Cc: egcs, egcs-bugs
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1666 bytes --]
On Mar 2, 1999, Paul Derbyshire <pderbysh@usa.net> wrote:
> At 04:59 AM 3/1/99 -0300, you wrote:
>> Then please post a bug report...
> I already did!
>> ...containing a single code snippet that demonstrates the problem...
> "extern foo<int> bar;"
> Parse error, but line is well-formed;
Without the quotes, I suppose :-)
And it is not well-formed if foo is not declared as a template yet,
but I agree that the message could be improved.
>> ...and a description of the host in which you have observed the
>> problem...
> x86-MSDOS. Which anyone who has read the original stuff will know.
Bug reports are usually kept by developers in mailboxes or such, and
it's very good to have all the needed information in a single
message, rather than having to collect it from dozens of different
messages. That's why I asked for a complete bug report.
> Not that there is a snowball's chance in hell that the target has
> any influence whatsoever on the *parser* :-)
Platform-dependent memory corruption can damage the symbol table,
which may lead to parse errors.
>> otherwise lots of people may have to spend time re-creating the code
>> snippet you already have.
> Why you believe this is beyond me, since the code snippet (above) was in
> the very post you quoted IIRC
Sorry, I did not understand that was the *whole* code snippet.
Thanks for re-posting it, anyway.
> Copied to egcs-bugs.
That's where bug reports belong; thanks :-)
--
Alexandre Oliva http://www.dcc.unicamp.br/~oliva aoliva@{acm.org,computer.org}
oliva@{dcc.unicamp.br,gnu.org,egcs.cygnus.com,samba.org}
Instituto de Computação, Universidade Estadual de Campinas, SP, Brasil
^ permalink raw reply [flat|nested] 264+ messages in thread
* Re: Confirmed template parsing bug: bug in error message generation.
1999-03-02 8:43 ` Paul Derbyshire
[not found] ` < 3.0.6.32.19990302114234.0086bd80@pop.globalserve.net >
1999-03-02 22:22 ` Alexandre Oliva
@ 1999-03-31 23:46 ` Paul Derbyshire
2 siblings, 0 replies; 264+ messages in thread
From: Paul Derbyshire @ 1999-03-31 23:46 UTC (permalink / raw)
To: egcs, egcs-bugs
At 04:59 AM 3/1/99 -0300, you wrote:
>Then please post a bug report...
I already did!
>...containing a single code snippet that demonstrates the problem...
"extern foo<int> bar;"
Parse error, but line is well-formed; should be undeclared identifier
"foo". Caused a 4 hour work stoppage here with people trying to track down
obscure aspects of the standard regarding templates thinking they made a
subtly ill-formed template declaration, and then throwing "typename"
qualifiers around at random half-heartedly, before suspecting it might be a
compiler bug, all of it triggered by a simple use of a symbol not imported
from its namespace. :-)
>...and a description of the host in which you have observed the
>problem...
x86-MSDOS. Which anyone who has read the original stuff will know. Not that
there is a snowball's chance in hell that the target has any influence
whatsoever on the *parser* :-)
>otherwise lots of people may have to spend time re-creating the code
>snippet you already have.
Why you believe this is beyond me, since the code snippet (above) was in
the very post you quoted IIRC, and the target, even if relevant for parser
issues, has been referred to be my in the past also.
Copied to egcs-bugs.
--
.*. "Clouds are not spheres, mountains are not cones, coastlines are not
-() < circles, and bark is not smooth, nor does lightning travel in a
`*' straight line." -------------------------------------------------
-- B. Mandelbrot | http://surf.to/pgd.net
_____________________ ____|________ Paul Derbyshire pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|
^ permalink raw reply [flat|nested] 264+ messages in thread
* Re: Confirmed template parsing bug: bug in error message generation.
1999-03-01 0:02 ` Alexandre Oliva
[not found] ` < oriuclljxv.fsf@araguaia.dcc.unicamp.br >
@ 1999-03-31 23:46 ` Alexandre Oliva
1 sibling, 0 replies; 264+ messages in thread
From: Alexandre Oliva @ 1999-03-31 23:46 UTC (permalink / raw)
To: Paul Derbyshire; +Cc: egcs, egcs-bugs
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 749 bytes --]
On Feb 28, 1999, Paul Derbyshire <pderbysh@usa.net> wrote:
> Well, I checked and it seems in my original code, I forgot to import
> math_traits from a namespace. So there are actually 2 errors,
Then please post a bug report as recommended in
http://egcs.cygnus.com/faq.html#bugreport , i.e., containing a single
code snippet that demonstrates the problem and a description of the
host in which you have observed the problem, otherwise lots of people
may have to spend time re-creating the code snippet you already have.
Thanks
--
Alexandre Oliva http://www.dcc.unicamp.br/~oliva aoliva@{acm.org,computer.org}
oliva@{dcc.unicamp.br,gnu.org,egcs.cygnus.com,samba.org}
Instituto de Computação, Universidade Estadual de Campinas, SP, Brasil
^ permalink raw reply [flat|nested] 264+ messages in thread
* Possible egcs-1.1.2-pre2 configure problem on HP-UX 9.04
@ 1999-02-28 19:05 ` rodneybrown
1999-02-28 22:53 ` rodneybrown
` (2 more replies)
0 siblings, 3 replies; 264+ messages in thread
From: rodneybrown @ 1999-02-28 19:05 UTC (permalink / raw)
To: egcs
Configuring on HP-UX 9.04 gave a 'sh internal 2K buffer overflow' - the build
seems to be
running and pre1 worked ok. I tried changing the etc/configure to run using
#!/bin/ksh to
no avail. Nor did reducing the size of the cat <<EOF which seemed to match the
message.
Second output is from a captured run with -x turned on.
configure is stressing older shells & O/Ses - gdb-4.17 and gcc-2.8.1 won't host
on SCO-3.2.4 => COFF because of 4k limits in command line + environment passed
to subprocesses,
but I haven't seen this before on HP-UX.
../egcs-1.1.2-pre2/configure --with-gnu-as
Configuring for a hppa1.1-hp-hpux9.04 host.
Created "Makefile" in /user4/vsb/rdb/egcs-1.1.2-pre2.obj using "mh-frag"
Links are now set up to build a native compiler for hppa1.1-hp-hpux9.04
./../egcs-1.1.2-pre2/etc/configure: sh internal 2K buffer overflow
$ pre2/configure --with-gnu-as
Configuring for a hppa1.1-hp-hpux9.04 host.
..
+ test -f /usr/local/bin/scoinst
+ test -f /usr/local/bin/install
+ test -f /user/p.cocam/bin/ginstall
+ test -f /user/p.cocam/bin/scoinst
+ test -f /user/p.cocam/bin/install
IFS=
+ test = set
INSTALL=../pre2/etc/../install-sh -c
+ echo ../pre2/etc/../install-sh -c
+ test -z
INSTALL_PROGRAM=${INSTALL}
+ test -z
INSTALL_DATA=${INSTALL} -m 644
+ trap 1 2 15
+ cat
./pre2/etc/configure: sh internal 2K buffer overflow
+ cmp -s ../config.cache confcache
+ test -w ../config.cache
+ echo updating cache ../config.cache
+ cat confcache
+ rm -f confcache
+ trap rm -fr conftest* confdefs* core core.* *.core $ac_clean_files; exit 1 1 2
15
+ test xNONE = xNONE
prefix=/usr/local
+ test xNONE = xNONE
exec_prefix=${prefix}
+ test x../pre2/etc = x.
+ trap rm -f $CONFIG_STATUS conftest*; exit 1 1 2 15
+ cat
+ + sedtr -f\012 conftest.defs confdefs.h
..
^ permalink raw reply [flat|nested] 264+ messages in thread
* Possible egcs-1.1.2-pre2 configure problem on HP-UX 9.04
1999-02-28 19:05 ` Possible egcs-1.1.2-pre2 configure problem on HP-UX 9.04 rodneybrown
@ 1999-02-28 22:53 ` rodneybrown
1999-03-01 9:05 ` Alexandre Oliva
1999-03-01 9:18 ` Jeffrey A Law
2 siblings, 0 replies; 264+ messages in thread
From: rodneybrown @ 1999-02-28 22:53 UTC (permalink / raw)
To: egcs
Configuring on HP-UX 9.04 gave a 'sh internal 2K buffer overflow' - the build
seems to be
running and pre1 worked ok. I tried changing the etc/configure to run using
#!/bin/ksh to
no avail. Nor did reducing the size of the cat <<EOF which seemed to match the
message.
Second output is from a captured run with -x turned on.
configure is stressing older shells & O/Ses - gdb-4.17 and gcc-2.8.1 won't host
on SCO-3.2.4 => COFF because of 4k limits in command line + environment passed
to subprocesses,
but I haven't seen this before on HP-UX.
../egcs-1.1.2-pre2/configure --with-gnu-as
Configuring for a hppa1.1-hp-hpux9.04 host.
Created "Makefile" in /user4/vsb/rdb/egcs-1.1.2-pre2.obj using "mh-frag"
Links are now set up to build a native compiler for hppa1.1-hp-hpux9.04
./../egcs-1.1.2-pre2/etc/configure: sh internal 2K buffer overflow
$ pre2/configure --with-gnu-as
Configuring for a hppa1.1-hp-hpux9.04 host.
..
+ test -f /usr/local/bin/scoinst
+ test -f /usr/local/bin/install
+ test -f /user/p.cocam/bin/ginstall
+ test -f /user/p.cocam/bin/scoinst
+ test -f /user/p.cocam/bin/install
IFS=
+ test = set
INSTALL=../pre2/etc/../install-sh -c
+ echo ../pre2/etc/../install-sh -c
+ test -z
INSTALL_PROGRAM=${INSTALL}
+ test -z
INSTALL_DATA=${INSTALL} -m 644
+ trap 1 2 15
+ cat
./pre2/etc/configure: sh internal 2K buffer overflow
+ cmp -s ../config.cache confcache
+ test -w ../config.cache
+ echo updating cache ../config.cache
+ cat confcache
+ rm -f confcache
+ trap rm -fr conftest* confdefs* core core.* *.core $ac_clean_files; exit 1 1 2
15
+ test xNONE = xNONE
prefix=/usr/local
+ test xNONE = xNONE
exec_prefix=${prefix}
+ test x../pre2/etc = x.
+ trap rm -f $CONFIG_STATUS conftest*; exit 1 1 2 15
+ cat
+ + sedtr -f\012 conftest.defs confdefs.h
..
^ permalink raw reply [flat|nested] 264+ messages in thread
* Re: Possible egcs-1.1.2-pre2 configure problem on HP-UX 9.04
1999-02-28 19:05 ` Possible egcs-1.1.2-pre2 configure problem on HP-UX 9.04 rodneybrown
1999-02-28 22:53 ` rodneybrown
@ 1999-03-01 9:05 ` Alexandre Oliva
[not found] ` < orogmdf8jw.fsf@araguaia.dcc.unicamp.br >
1999-03-31 23:46 ` Alexandre Oliva
1999-03-01 9:18 ` Jeffrey A Law
2 siblings, 2 replies; 264+ messages in thread
From: Alexandre Oliva @ 1999-03-01 9:05 UTC (permalink / raw)
To: rodneybrown; +Cc: egcs
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 478 bytes --]
On Mar 1, 1999, rodneybrown@pmsc.com wrote:
> Configuring on HP-UX 9.04 gave a 'sh internal 2K buffer overflow' -
> the build seems to be running and pre1 worked ok. I tried changing
> the etc/configure to run using #!/bin/ksh to no avail.
Set CONFIG_SHELL
--
Alexandre Oliva http://www.dcc.unicamp.br/~oliva aoliva@{acm.org,computer.org}
oliva@{dcc.unicamp.br,gnu.org,egcs.cygnus.com,samba.org}
Instituto de Computação, Universidade Estadual de Campinas, SP, Brasil
^ permalink raw reply [flat|nested] 264+ messages in thread
[parent not found: < orogmdf8jw.fsf@araguaia.dcc.unicamp.br >]
* Re: Possible egcs-1.1.2-pre2 configure problem on HP-UX 9.04
[not found] ` < orogmdf8jw.fsf@araguaia.dcc.unicamp.br >
@ 1999-03-01 9:14 ` Franz Sirl
1999-03-01 9:32 ` Alexandre Oliva
1999-03-31 23:46 ` Franz Sirl
0 siblings, 2 replies; 264+ messages in thread
From: Franz Sirl @ 1999-03-01 9:14 UTC (permalink / raw)
To: Alexandre Oliva; +Cc: rodneybrown, egcs
At 18:01 01.03.99 , Alexandre Oliva wrote:
>On Mar 1, 1999, rodneybrown@pmsc.com wrote:
>
>> Configuring on HP-UX 9.04 gave a 'sh internal 2K buffer overflow' -
>> the build seems to be running and pre1 worked ok. I tried changing
>> the etc/configure to run using #!/bin/ksh to no avail.
>
>Set CONFIG_SHELL
Hmm, will this still work as expected? In the diff from 1.1.1 to 1.1.2pre2
I noticed some entries like below in the texinfo subdir.
Franz.
Index: texinfo/lib/Makefile.in
--- texinfo/lib/Makefile.in 1998/04/02 03:45:22 1.4
+++ texinfo/lib/Makefile.in 1999/02/24 02:45:41 1.4.2.1
@@ -1,4 +1,4 @@
-# Makefile.in generated automatically by automake 1.2e from Makefile.am
+# Makefile.in generated automatically by automake 1.3 from Makefile.am
# Copyright (C) 1994, 1995, 1996, 1997, 1998 Free Software Foundation, Inc.
# This Makefile.in is free software; the Free Software Foundation
@@ -11,7 +11,7 @@
# PARTICULAR PURPOSE.
-SHELL = @SHELL@
+SHELL = /bin/sh
^ permalink raw reply [flat|nested] 264+ messages in thread
* Re: Possible egcs-1.1.2-pre2 configure problem on HP-UX 9.04
1999-03-01 9:14 ` Franz Sirl
@ 1999-03-01 9:32 ` Alexandre Oliva
1999-03-31 23:46 ` Alexandre Oliva
1999-03-31 23:46 ` Franz Sirl
1 sibling, 1 reply; 264+ messages in thread
From: Alexandre Oliva @ 1999-03-01 9:32 UTC (permalink / raw)
To: Franz Sirl; +Cc: rodneybrown, egcs
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1052 bytes --]
On Mar 1, 1999, Franz Sirl <Franz.Sirl-kernel@lauterbach.com> wrote:
> At 18:01 01.03.99 , Alexandre Oliva wrote:
>> On Mar 1, 1999, rodneybrown@pmsc.com wrote:
>>
>>> Configuring on HP-UX 9.04 gave a 'sh internal 2K buffer overflow' -
>>> the build seems to be running and pre1 worked ok. I tried changing
>>> the etc/configure to run using #!/bin/ksh to no avail.
>>
>> Set CONFIG_SHELL
> Hmm, will this still work as expected?
Yep, this is only for configure time.
> --- texinfo/lib/Makefile.in 1998/04/02 03:45:22 1.4
> +++ texinfo/lib/Makefile.in 1999/02/24 02:45:41 1.4.2.1
> -SHELL = @SHELL@
> +SHELL = /bin/sh
I don't think this would be a problem, but it's strange that automake
1.3 does not use @SHELL@ as defined by configure... Well, most
commands it runs are so simple that it shouldn't matter.
--
Alexandre Oliva http://www.dcc.unicamp.br/~oliva aoliva@{acm.org,computer.org}
oliva@{dcc.unicamp.br,gnu.org,egcs.cygnus.com,samba.org}
Instituto de Computação, Universidade Estadual de Campinas, SP, Brasil
^ permalink raw reply [flat|nested] 264+ messages in thread
* Re: Possible egcs-1.1.2-pre2 configure problem on HP-UX 9.04
1999-03-01 9:32 ` Alexandre Oliva
@ 1999-03-31 23:46 ` Alexandre Oliva
0 siblings, 0 replies; 264+ messages in thread
From: Alexandre Oliva @ 1999-03-31 23:46 UTC (permalink / raw)
To: Franz Sirl; +Cc: rodneybrown, egcs
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1053 bytes --]
On Mar 1, 1999, Franz Sirl <Franz.Sirl-kernel@lauterbach.com> wrote:
> At 18:01 01.03.99 , Alexandre Oliva wrote:
>> On Mar 1, 1999, rodneybrown@pmsc.com wrote:
>>
>>> Configuring on HP-UX 9.04 gave a 'sh internal 2K buffer overflow' -
>>> the build seems to be running and pre1 worked ok. I tried changing
>>> the etc/configure to run using #!/bin/ksh to no avail.
>>
>> Set CONFIG_SHELL
> Hmm, will this still work as expected?
Yep, this is only for configure time.
> --- texinfo/lib/Makefile.in 1998/04/02 03:45:22 1.4
> +++ texinfo/lib/Makefile.in 1999/02/24 02:45:41 1.4.2.1
> -SHELL = @SHELL@
> +SHELL = /bin/sh
I don't think this would be a problem, but it's strange that automake
1.3 does not use @SHELL@ as defined by configure... Well, most
commands it runs are so simple that it shouldn't matter.
--
Alexandre Oliva http://www.dcc.unicamp.br/~oliva aoliva@{acm.org,computer.org}
oliva@{dcc.unicamp.br,gnu.org,egcs.cygnus.com,samba.org}
Instituto de Computação, Universidade Estadual de Campinas, SP, Brasil
^ permalink raw reply [flat|nested] 264+ messages in thread
* Re: Possible egcs-1.1.2-pre2 configure problem on HP-UX 9.04
1999-03-01 9:14 ` Franz Sirl
1999-03-01 9:32 ` Alexandre Oliva
@ 1999-03-31 23:46 ` Franz Sirl
1 sibling, 0 replies; 264+ messages in thread
From: Franz Sirl @ 1999-03-31 23:46 UTC (permalink / raw)
To: Alexandre Oliva; +Cc: rodneybrown, egcs
At 18:01 01.03.99 , Alexandre Oliva wrote:
>On Mar 1, 1999, rodneybrown@pmsc.com wrote:
>
>> Configuring on HP-UX 9.04 gave a 'sh internal 2K buffer overflow' -
>> the build seems to be running and pre1 worked ok. I tried changing
>> the etc/configure to run using #!/bin/ksh to no avail.
>
>Set CONFIG_SHELL
Hmm, will this still work as expected? In the diff from 1.1.1 to 1.1.2pre2
I noticed some entries like below in the texinfo subdir.
Franz.
Index: texinfo/lib/Makefile.in
--- texinfo/lib/Makefile.in 1998/04/02 03:45:22 1.4
+++ texinfo/lib/Makefile.in 1999/02/24 02:45:41 1.4.2.1
@@ -1,4 +1,4 @@
-# Makefile.in generated automatically by automake 1.2e from Makefile.am
+# Makefile.in generated automatically by automake 1.3 from Makefile.am
# Copyright (C) 1994, 1995, 1996, 1997, 1998 Free Software Foundation, Inc.
# This Makefile.in is free software; the Free Software Foundation
@@ -11,7 +11,7 @@
# PARTICULAR PURPOSE.
-SHELL = @SHELL@
+SHELL = /bin/sh
^ permalink raw reply [flat|nested] 264+ messages in thread
* Re: Possible egcs-1.1.2-pre2 configure problem on HP-UX 9.04
1999-03-01 9:05 ` Alexandre Oliva
[not found] ` < orogmdf8jw.fsf@araguaia.dcc.unicamp.br >
@ 1999-03-31 23:46 ` Alexandre Oliva
1 sibling, 0 replies; 264+ messages in thread
From: Alexandre Oliva @ 1999-03-31 23:46 UTC (permalink / raw)
To: rodneybrown; +Cc: egcs
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 479 bytes --]
On Mar 1, 1999, rodneybrown@pmsc.com wrote:
> Configuring on HP-UX 9.04 gave a 'sh internal 2K buffer overflow' -
> the build seems to be running and pre1 worked ok. I tried changing
> the etc/configure to run using #!/bin/ksh to no avail.
Set CONFIG_SHELL
--
Alexandre Oliva http://www.dcc.unicamp.br/~oliva aoliva@{acm.org,computer.org}
oliva@{dcc.unicamp.br,gnu.org,egcs.cygnus.com,samba.org}
Instituto de Computação, Universidade Estadual de Campinas, SP, Brasil
^ permalink raw reply [flat|nested] 264+ messages in thread
* Re: Possible egcs-1.1.2-pre2 configure problem on HP-UX 9.04
1999-02-28 19:05 ` Possible egcs-1.1.2-pre2 configure problem on HP-UX 9.04 rodneybrown
1999-02-28 22:53 ` rodneybrown
1999-03-01 9:05 ` Alexandre Oliva
@ 1999-03-01 9:18 ` Jeffrey A Law
1999-03-31 23:46 ` Jeffrey A Law
2 siblings, 1 reply; 264+ messages in thread
From: Jeffrey A Law @ 1999-03-01 9:18 UTC (permalink / raw)
To: rodneybrown; +Cc: egcs
In message <9902289202.AA920257535@cc.pmsc.com>you write:
>
> Configuring on HP-UX 9.04 gave a 'sh internal 2K buffer overflow' -
> the build seems to be running and pre1 worked ok.
This is a bug in the hpux shell. It only effects building of the config.cache
file.
I believe if you set CONFIG_SHELL and/or SHELL in your environment will work
around this bug.
See the hpux entries at
http://egcs.cygnus.com/install/specific.html
jeff
^ permalink raw reply [flat|nested] 264+ messages in thread
[parent not found: <(EST)>]
* Occasional use of GNU ld problems
@ 1999-06-25 17:54 ` Brad Lucier
1999-06-29 2:06 ` Alexandre Oliva
1999-06-30 15:43 ` Brad Lucier
0 siblings, 2 replies; 264+ messages in thread
From: Brad Lucier @ 1999-06-25 17:54 UTC (permalink / raw)
To: egcs; +Cc: lucier
I'm trying to compile Cilk (a parallel language based on C from
theory.lcs.mit.edu), which requires GNU ld, which I usually don't use,
so I installed it in /opt/binutils-2.9.1 on my Solaris 2.5.1 box.
So now I want egcs to see it and I find the FAQ advice:
GCC can not find GNU as/GNU ld
To ensure that EGCS finds the GNU assembler (the GNU loader), which are
required by some configurations, you should configure these with the
same --prefix option as you used for EGCS. Then build & install GNU as
(GNU ld) and proceed with building EGCS.
Another alternative is to create links to GNU as and ld in any of the
directories printed by the command `gcc -print-search-dirs | grep
'^programs:''. The link to `ld' should be named `real-ld' if `ld'
already exists.
Pre-1.2 snapshots of egcs allow you to specify the full pathname
of the assembler and the linker to use. The configure flags are
`--with-as=/path/to/as' and `--with-ld=/path/to/ld'. EGCS will try to use
these pathnames before looking for `as' or `(real-)ld' in the standard
search dirs. If, at configure-time, the specified programs are found to
be GNU utilities, `--with-gnu-as' and `--with-gnu-ld' need not be used;
these flags will be auto-detected.
<end of faq advice>
Alternative 2 is a real pain (although I suppose I could write a script
to do), and I'm working on the first alternative now, which I don't
really want to do, because I'm going to be building a series of temporary
snapshots of egcs in a directory (binutils) that otherwise I don't want
to fool around with.
But first I tried adding the '-B /opt/binutils-2.9.1/bin' option to
LDFLAGS in the makefiles for Cilk, which seemed to allow egcs to see
GNU ld, but then I had to rerun configure for some reason, and configure
uses 'gcc -print-prog-name=ld' to find out which ld gcc uses, and the
-B option doesn't seem to affect which load program is printed:
bessel-125% gcc -B /opt/binutils-2.9.1/bin -print-prog-name=ld
/usr/ccs/bin/ld
So the configure for Cilk bombs and says I need to use GNU ld.
So, I really think there should be an easier way for egcs to use
the GNU linker for occasional packages that need it.
Brad Lucier lucier@math.purdue.edu
^ permalink raw reply [flat|nested] 264+ messages in thread
* Re: Occasional use of GNU ld problems
1999-06-25 17:54 ` Occasional use of GNU ld problems Brad Lucier
@ 1999-06-29 2:06 ` Alexandre Oliva
1999-06-29 2:20 ` Franz Sirl
1999-06-30 15:43 ` Alexandre Oliva
1999-06-30 15:43 ` Brad Lucier
1 sibling, 2 replies; 264+ messages in thread
From: Alexandre Oliva @ 1999-06-29 2:06 UTC (permalink / raw)
To: Brad Lucier; +Cc: egcs
On Jun 25, 1999, Brad Lucier <lucier@math.purdue.edu> wrote:
> But first I tried adding the '-B /opt/binutils-2.9.1/bin'
It should end with a slash, and I'm not sure a space after the `B' is
supported: -B/opt/binutils-2.9.1/bin/
--
Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il
{oliva,Alexandre.Oliva}@dcc.unicamp.br aoliva@{acm.org,computer.org}
oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org}
*** E-mail about software projects will be forwarded to mailing lists
^ permalink raw reply [flat|nested] 264+ messages in thread
* Re: Occasional use of GNU ld problems
1999-06-29 2:06 ` Alexandre Oliva
@ 1999-06-29 2:20 ` Franz Sirl
1999-06-30 15:43 ` Franz Sirl
1999-06-30 15:43 ` Alexandre Oliva
1 sibling, 1 reply; 264+ messages in thread
From: Franz Sirl @ 1999-06-29 2:20 UTC (permalink / raw)
To: Alexandre Oliva; +Cc: Brad Lucier, egcs
At 11:06 29.06.99 , Alexandre Oliva wrote:
>On Jun 25, 1999, Brad Lucier <lucier@math.purdue.edu> wrote:
>
> > But first I tried adding the '-B /opt/binutils-2.9.1/bin'
>
>It should end with a slash, and I'm not sure a space after the `B' is
>supported: -B/opt/binutils-2.9.1/bin/
JFYI, the space is supported. I use everyday, cause otherwise commandline
completion with TAB and using ~ as an abbreviation don't work.
Franz.
^ permalink raw reply [flat|nested] 264+ messages in thread
* Re: Occasional use of GNU ld problems
1999-06-29 2:20 ` Franz Sirl
@ 1999-06-30 15:43 ` Franz Sirl
0 siblings, 0 replies; 264+ messages in thread
From: Franz Sirl @ 1999-06-30 15:43 UTC (permalink / raw)
To: Alexandre Oliva; +Cc: Brad Lucier, egcs
At 11:06 29.06.99 , Alexandre Oliva wrote:
>On Jun 25, 1999, Brad Lucier <lucier@math.purdue.edu> wrote:
>
> > But first I tried adding the '-B /opt/binutils-2.9.1/bin'
>
>It should end with a slash, and I'm not sure a space after the `B' is
>supported: -B/opt/binutils-2.9.1/bin/
JFYI, the space is supported. I use everyday, cause otherwise commandline
completion with TAB and using ~ as an abbreviation don't work.
Franz.
^ permalink raw reply [flat|nested] 264+ messages in thread
* Re: Occasional use of GNU ld problems
1999-06-29 2:06 ` Alexandre Oliva
1999-06-29 2:20 ` Franz Sirl
@ 1999-06-30 15:43 ` Alexandre Oliva
1 sibling, 0 replies; 264+ messages in thread
From: Alexandre Oliva @ 1999-06-30 15:43 UTC (permalink / raw)
To: Brad Lucier; +Cc: egcs
On Jun 25, 1999, Brad Lucier <lucier@math.purdue.edu> wrote:
> But first I tried adding the '-B /opt/binutils-2.9.1/bin'
It should end with a slash, and I'm not sure a space after the `B' is
supported: -B/opt/binutils-2.9.1/bin/
--
Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il
{oliva,Alexandre.Oliva}@dcc.unicamp.br aoliva@{acm.org,computer.org}
oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org}
*** E-mail about software projects will be forwarded to mailing lists
^ permalink raw reply [flat|nested] 264+ messages in thread
* Occasional use of GNU ld problems
1999-06-25 17:54 ` Occasional use of GNU ld problems Brad Lucier
1999-06-29 2:06 ` Alexandre Oliva
@ 1999-06-30 15:43 ` Brad Lucier
1 sibling, 0 replies; 264+ messages in thread
From: Brad Lucier @ 1999-06-30 15:43 UTC (permalink / raw)
To: egcs; +Cc: lucier
I'm trying to compile Cilk (a parallel language based on C from
theory.lcs.mit.edu), which requires GNU ld, which I usually don't use,
so I installed it in /opt/binutils-2.9.1 on my Solaris 2.5.1 box.
So now I want egcs to see it and I find the FAQ advice:
GCC can not find GNU as/GNU ld
To ensure that EGCS finds the GNU assembler (the GNU loader), which are
required by some configurations, you should configure these with the
same --prefix option as you used for EGCS. Then build & install GNU as
(GNU ld) and proceed with building EGCS.
Another alternative is to create links to GNU as and ld in any of the
directories printed by the command `gcc -print-search-dirs | grep
'^programs:''. The link to `ld' should be named `real-ld' if `ld'
already exists.
Pre-1.2 snapshots of egcs allow you to specify the full pathname
of the assembler and the linker to use. The configure flags are
`--with-as=/path/to/as' and `--with-ld=/path/to/ld'. EGCS will try to use
these pathnames before looking for `as' or `(real-)ld' in the standard
search dirs. If, at configure-time, the specified programs are found to
be GNU utilities, `--with-gnu-as' and `--with-gnu-ld' need not be used;
these flags will be auto-detected.
<end of faq advice>
Alternative 2 is a real pain (although I suppose I could write a script
to do), and I'm working on the first alternative now, which I don't
really want to do, because I'm going to be building a series of temporary
snapshots of egcs in a directory (binutils) that otherwise I don't want
to fool around with.
But first I tried adding the '-B /opt/binutils-2.9.1/bin' option to
LDFLAGS in the makefiles for Cilk, which seemed to allow egcs to see
GNU ld, but then I had to rerun configure for some reason, and configure
uses 'gcc -print-prog-name=ld' to find out which ld gcc uses, and the
-B option doesn't seem to affect which load program is printed:
bessel-125% gcc -B /opt/binutils-2.9.1/bin -print-prog-name=ld
/usr/ccs/bin/ld
So the configure for Cilk bombs and says I need to use GNU ld.
So, I really think there should be an easier way for egcs to use
the GNU linker for occasional packages that need it.
Brad Lucier lucier@math.purdue.edu
^ permalink raw reply [flat|nested] 264+ messages in thread
[parent not found: <04:47:24>]
[parent not found: <08:25:39>]
[parent not found: <"Fri,>]
[parent not found: <25>]
[parent not found: <19990608202201.F17154@admin3.jump.net>]
* assemble_external on .class files
@ 1999-05-20 21:06 Mark Klein
1999-05-22 14:23 ` Jeffrey A Law
1999-05-31 21:36 ` Mark Klein
0 siblings, 2 replies; 264+ messages in thread
From: Mark Klein @ 1999-05-20 21:06 UTC (permalink / raw)
To: egcs; +Cc: java-discuss
I'm having a whale of a time trying to figure out a problem I'm
experiencing with gcj:
External procedure labels need to be .IMPORTED before they can
be used on my platform. Some of these are part of a dispatch table
created from classes such as java::lang::Object. My first attempt at
resolving this was to place an assemble_external() in layout_class(),
but that results in a lot of clutter with .IMPORT statements for a
whole bunch of things that really are not referenced. I suppose this
could be my brute force method, but I would prefer to only do the
.IMPORT for referenced methods/classes.
Here's HelloWorld's _vt_:
.IMPORT clone__Q34java4lang6Object,CODE
.IMPORT hashCode__Q34java4lang6Object,CODE
.align 4
HelloWorld virtual table
.word _CL_10HelloWorld
.word 0
.word P%java::lang::Object::finalize(void)
.word P%java::lang::Object::hashCode(void)
.word P%java::lang::Object::equals(java::lang::Object *)
.word P%java::lang::Object::toString(void)
.word P%java::lang::Object::clone(void)
Note that clone() and hashCode() have been imported. But finalize(),
equals() and tostring() have not. They are referenced in some fashion
in order to be in the virtual table when the rest of their brethren
are not. But, clone() and hashCode() must be referenced in some other
path in order to cause them to be imported.
I can't seem to figure out what that path is in order to make the same
changes for the other case. I also have not completed by gdb port, so
I am debugging this with the native (non-symbolic) debugger, which is
also probably leading to some of my confusion as I chase pointers in trees.
TIA,
M.
--
Mark Klein DIS International, Ltd.
http://www.dis.com 415-892-8400
PGP Public Key Available
^ permalink raw reply [flat|nested] 264+ messages in thread
* Re: assemble_external on .class files
1999-05-20 21:06 assemble_external on .class files Mark Klein
@ 1999-05-22 14:23 ` Jeffrey A Law
1999-05-22 15:28 ` Mark Klein
` (2 more replies)
1999-05-31 21:36 ` Mark Klein
1 sibling, 3 replies; 264+ messages in thread
From: Jeffrey A Law @ 1999-05-22 14:23 UTC (permalink / raw)
To: Mark Klein; +Cc: egcs, java-discuss
In message < 4.1.19990520204749.00c7fa90@garfield.dis.com >you write:
> External procedure labels need to be .IMPORTED before they can
> be used on my platform. Some of these are part of a dispatch table
> created from classes such as java::lang::Object. My first attempt at
> resolving this was to place an assemble_external() in layout_class(),
> but that results in a lot of clutter with .IMPORT statements for a
> whole bunch of things that really are not referenced. I suppose this
> could be my brute force method, but I would prefer to only do the
> .IMPORT for referenced methods/classes.
I wouldn't worry about the extra .IMPORTs. In fact, it's a little known
aspect of SOM that the assembler is responsible for _not_ adding an imported
symbol to the undefined symbols for a module if that symbol is not actually
referenced.
Jeff
^ permalink raw reply [flat|nested] 264+ messages in thread
* Re: assemble_external on .class files
1999-05-22 14:23 ` Jeffrey A Law
@ 1999-05-22 15:28 ` Mark Klein
1999-05-31 21:36 ` Mark Klein
1999-05-25 18:33 ` Mark Klein
1999-05-31 21:36 ` Jeffrey A Law
2 siblings, 1 reply; 264+ messages in thread
From: Mark Klein @ 1999-05-22 15:28 UTC (permalink / raw)
To: law; +Cc: egcs, java-discuss
At 03:19 PM 5/22/99 -0600, Jeffrey A Law wrote:
>I wouldn't worry about the extra .IMPORTs. In fact, it's a little known
>aspect of SOM that the assembler is responsible for _not_ adding an imported
>symbol to the undefined symbols for a module if that symbol is not actually
>referenced.
Thanks ... brute force method it is! Just when I was starting to see the
_trees_ through the forest. :-)
--
Mark Klein DIS International, Ltd.
http://www.dis.com 415-892-8400
PGP Public Key Available
^ permalink raw reply [flat|nested] 264+ messages in thread
* Re: assemble_external on .class files
1999-05-22 15:28 ` Mark Klein
@ 1999-05-31 21:36 ` Mark Klein
0 siblings, 0 replies; 264+ messages in thread
From: Mark Klein @ 1999-05-31 21:36 UTC (permalink / raw)
To: law; +Cc: egcs, java-discuss
At 03:19 PM 5/22/99 -0600, Jeffrey A Law wrote:
>I wouldn't worry about the extra .IMPORTs. In fact, it's a little known
>aspect of SOM that the assembler is responsible for _not_ adding an imported
>symbol to the undefined symbols for a module if that symbol is not actually
>referenced.
Thanks ... brute force method it is! Just when I was starting to see the
_trees_ through the forest. :-)
--
Mark Klein DIS International, Ltd.
http://www.dis.com 415-892-8400
PGP Public Key Available
^ permalink raw reply [flat|nested] 264+ messages in thread
* Re: assemble_external on .class files
1999-05-22 14:23 ` Jeffrey A Law
1999-05-22 15:28 ` Mark Klein
@ 1999-05-25 18:33 ` Mark Klein
1999-05-25 19:41 ` Jeffrey A Law
1999-05-31 21:36 ` Mark Klein
1999-05-31 21:36 ` Jeffrey A Law
2 siblings, 2 replies; 264+ messages in thread
From: Mark Klein @ 1999-05-25 18:33 UTC (permalink / raw)
To: Jeffrey A Law; +Cc: egcs, java-discuss
At 03:19 PM 5/22/99 -0600, Jeffrey A Law wrote:
> > My first attempt at
> > resolving this was to place an assemble_external() in
layout_class_method(),
> > but that results in a lot of clutter with .IMPORT statements for a
> > whole bunch of things that really are not referenced.
>I wouldn't worry about the extra .IMPORTs. In fact, it's a little known
>aspect of SOM that the assembler is responsible for _not_ adding an imported
>symbol to the undefined symbols for a module if that symbol is not actually
>referenced.
Turns out that this also isn't a complete solution, partially because
assemble_external is looking for DECL_EXTERNAL. The tree field used
for DECL_EXTERNAL is also used for METHOD_NATIVE for java. That also
explains why certain .IMPORTs were happening and others were not ...
only native methods were getting the .IMPORTs.
There may be another problem here in that DECL_EXTERNAL is explicitly
set in various places and could ultimately end up in a usage conflict
between it and the usage of METHOD_NATIVE elswhere in the code.
Suggestions?
M.
--
Mark Klein DIS International, Ltd.
http://www.dis.com 415-892-8400
PGP Public Key Available
^ permalink raw reply [flat|nested] 264+ messages in thread
* Re: assemble_external on .class files
1999-05-25 18:33 ` Mark Klein
@ 1999-05-25 19:41 ` Jeffrey A Law
1999-05-25 21:00 ` Per Bothner
1999-05-31 21:36 ` Jeffrey A Law
1999-05-31 21:36 ` Mark Klein
1 sibling, 2 replies; 264+ messages in thread
From: Jeffrey A Law @ 1999-05-25 19:41 UTC (permalink / raw)
To: Mark Klein; +Cc: egcs, java-discuss
In message < 4.1.19990525180956.00c96100@garfield.dis.com >you write:
> Turns out that this also isn't a complete solution, partially because
> assemble_external is looking for DECL_EXTERNAL. The tree field used
> for DECL_EXTERNAL is also used for METHOD_NATIVE for java. That also
> explains why certain .IMPORTs were happening and others were not ...
> only native methods were getting the .IMPORTs.
>
> There may be another problem here in that DECL_EXTERNAL is explicitly
> set in various places and could ultimately end up in a usage conflict
> between it and the usage of METHOD_NATIVE elswhere in the code.
>
> Suggestions?
Split up DECL_EXTERNAL and METHOD_NATIVE. It seems awful strange/wrong to
have them overloaded on the same bit. Can someone from the Java side
explain why they're using the same bit? Especially since DECL_EXTERNAL has
a well defined meaning already. It seems to me using a lang specific flag
would make a lot more sense for METHOD_NATIVE.
jeff
^ permalink raw reply [flat|nested] 264+ messages in thread
* Re: assemble_external on .class files
1999-05-25 19:41 ` Jeffrey A Law
@ 1999-05-25 21:00 ` Per Bothner
1999-05-25 21:50 ` Jeffrey A Law
1999-05-31 21:36 ` Per Bothner
1999-05-31 21:36 ` Jeffrey A Law
1 sibling, 2 replies; 264+ messages in thread
From: Per Bothner @ 1999-05-25 21:00 UTC (permalink / raw)
To: law; +Cc: Mark Klein, egcs, java-discuss
Jeffrey A Law <law@cygnus.com> writes:
> Split up DECL_EXTERNAL and METHOD_NATIVE. It seems awful strange/wrong to
> have them overloaded on the same bit. Can someone from the Java side
> explain why they're using the same bit? Especially since DECL_EXTERNAL has
> a well defined meaning already. It seems to me using a lang specific flag
> would make a lot more sense for METHOD_NATIVE.
Well, the logic was the assumption that they would always be the same.
In a Java class, we have three kinds of methods:
(1) Regular methods (static or instance), with method bodies in the class
body. These methods are neither native, nor external, since they are
declared in the current input (.java or .class) file.
(2) Native methods, which do not have bodies. These must be bound to some
methods defined in some extenal C++ file. Hence, they need to have
DECL_EXTERNAL set - as well as METHOD_NATIVE.
(3) Abstract methods - which have no bodies anywhere. If they are ever
referenced, it would be a compiler bug.
I skimmed the earlier messages in this thread, which may be why I still don't
understand why there would be any reason to split up the flags.
However, perhaps there should be a comment where METHOD_NATIVE is
defined. Something like the following may suffice:
/* Only native methods are external (and vice versa). */
or perhaps:
/* A method is external if and only if it is native. */
--
--Per Bothner
bothner@pacbell.net http://home.pacbell.net/bothner/
^ permalink raw reply [flat|nested] 264+ messages in thread
* Re: assemble_external on .class files
1999-05-25 21:00 ` Per Bothner
@ 1999-05-25 21:50 ` Jeffrey A Law
1999-05-25 22:19 ` Mark Klein
1999-05-31 21:36 ` Jeffrey A Law
1999-05-31 21:36 ` Per Bothner
1 sibling, 2 replies; 264+ messages in thread
From: Jeffrey A Law @ 1999-05-25 21:50 UTC (permalink / raw)
To: Per Bothner; +Cc: Mark Klein, egcs, java-discuss
In message < m2n1yseark.fsf@magnus.cygnus.com >you write:
> Well, the logic was the assumption that they would always be the same.
>
> In a Java class, we have three kinds of methods:
>
> (1) Regular methods (static or instance), with method bodies in the class
> body. These methods are neither native, nor external, since they are
> declared in the current input (.java or .class) file.
>
> (2) Native methods, which do not have bodies. These must be bound to some
> methods defined in some extenal C++ file. Hence, they need to have
> DECL_EXTERNAL set - as well as METHOD_NATIVE.
>
> (3) Abstract methods - which have no bodies anywhere. If they are ever
> referenced, it would be a compiler bug.
Thanks. Hmmm, this makes me think that we're find with having them overloaded
on the same bit. Mark, I think this is a red herring.
> However, perhaps there should be a comment where METHOD_NATIVE is
> defined. Something like the following may suffice:
> /* Only native methods are external (and vice versa). */
> or perhaps:
> /* A method is external if and only if it is native. */
Yea. It would help clarify things for the future.
Thanks again!
jeff
^ permalink raw reply [flat|nested] 264+ messages in thread
* Re: assemble_external on .class files
1999-05-25 21:50 ` Jeffrey A Law
@ 1999-05-25 22:19 ` Mark Klein
1999-05-25 22:24 ` Jeffrey A Law
` (2 more replies)
1999-05-31 21:36 ` Jeffrey A Law
1 sibling, 3 replies; 264+ messages in thread
From: Mark Klein @ 1999-05-25 22:19 UTC (permalink / raw)
To: law, Per Bothner; +Cc: egcs, java-discuss
At 10:44 PM 5/25/99 -0600, Jeffrey A Law wrote:
>Thanks. Hmmm, this makes me think that we're find with having them overloaded
>on the same bit. Mark, I think this is a red herring.
Could be, but then there's a problem with assemble_external vis the usage of
DECL_EXTERNAL for the vtable. Recall my earlier example, from
java::lang::Object:
Method name:"finalize" protected Signature: 4=()void
...
Method name:"hashCode" public native Signature: 11=()int
and the vtable:
__vt_10HelloWorld
.word _CL_10HelloWorld
.word 0
.word P%finalize__Q34java4lang6Object
.IMPORT hashCode__Q34java4lang6Object,CODE
.word P%hashCode__Q34java4lang6Object
.word P%equals__Q34java4lang6ObjectPQ34java4lang6Object
.word P%toString__Q34java4lang6Object
.IMPORT clone__Q34java4lang6Object,CODE
.word P%clone__Q34java4lang6Object
Note that in order to use the plabels, the symbols must first be imported on
PA-RISC. In this case, we have finalize, and it isn't native. However, in
order for assemble_external to emit the .IMPORT, DECL_EXTERNAL (among others)
must be true. But, hashCode is native and is imported, hence the .IMPORT.
Since this is in contradiction to usage in jc1 as explained by Per, I've
got a problem....
Jeff (or any other PA-RISC user) ... has anyone tried gcj/libjava on a HP9000?
Or is this a problem only on the HP3000?
G'night, y'all.
--
Mark Klein DIS International, Ltd.
http://www.dis.com 415-892-8400
PGP Public Key Available
^ permalink raw reply [flat|nested] 264+ messages in thread
* Re: assemble_external on .class files
1999-05-25 22:19 ` Mark Klein
@ 1999-05-25 22:24 ` Jeffrey A Law
1999-05-31 21:36 ` Jeffrey A Law
1999-05-25 22:49 ` Per Bothner
1999-05-31 21:36 ` Mark Klein
2 siblings, 1 reply; 264+ messages in thread
From: Jeffrey A Law @ 1999-05-25 22:24 UTC (permalink / raw)
To: Mark Klein; +Cc: Per Bothner, egcs, java-discuss
In message < 4.1.19990525220502.00ca56a0@garfield.dis.com >you write:
> Jeff (or any other PA-RISC user) ... has anyone tried gcj/libjava on a
> HP9000?
Nobody that I'm aware of. I talked to Anthony Green a week or two about
some of this stuff and it sounds like x86-linux & sparc-solaris are the
native platforms that should "just work" out of the box since that's what
the Java team is using/testing regularly. So it's not a huge suprise that
we've got a few issues to resolve on the PA (and likely other targets).
jeff
^ permalink raw reply [flat|nested] 264+ messages in thread
* Re: assemble_external on .class files
1999-05-25 22:24 ` Jeffrey A Law
@ 1999-05-31 21:36 ` Jeffrey A Law
0 siblings, 0 replies; 264+ messages in thread
From: Jeffrey A Law @ 1999-05-31 21:36 UTC (permalink / raw)
To: Mark Klein; +Cc: Per Bothner, egcs, java-discuss
In message < 4.1.19990525220502.00ca56a0@garfield.dis.com >you write:
> Jeff (or any other PA-RISC user) ... has anyone tried gcj/libjava on a
> HP9000?
Nobody that I'm aware of. I talked to Anthony Green a week or two about
some of this stuff and it sounds like x86-linux & sparc-solaris are the
native platforms that should "just work" out of the box since that's what
the Java team is using/testing regularly. So it's not a huge suprise that
we've got a few issues to resolve on the PA (and likely other targets).
jeff
^ permalink raw reply [flat|nested] 264+ messages in thread
* Re: assemble_external on .class files
1999-05-25 22:19 ` Mark Klein
1999-05-25 22:24 ` Jeffrey A Law
@ 1999-05-25 22:49 ` Per Bothner
1999-05-31 14:53 ` Mark Klein
1999-05-31 21:36 ` Per Bothner
1999-05-31 21:36 ` Mark Klein
2 siblings, 2 replies; 264+ messages in thread
From: Per Bothner @ 1999-05-25 22:49 UTC (permalink / raw)
To: Mark Klein; +Cc: egcs, java-discuss
Mark Klein <mklein@dis.com> writes:
> Could be, but then there's a problem with assemble_external vis the usage of
> DECL_EXTERNAL for the vtable. Recall my earlier example, from
> java::lang::Object:
Ah - that was in a message that had expired.
My logic only applies to entries in the "method table". It is
wrong for entries in the vtable. It is also wrong for calls
to static methods in other classes.
METHOD_NATIVE does need to be split from DECL_EXTERNAL.
There doesn't seem to be any available DECL_LANG_FLAGs,
but there are some TREE_LANG_FLAGSs available (in FUNCTION_DECLs).
That means that we need to set DECL_EXTERNAL separately.
I think it should be true for any methods that has METHOD_NATIVE,
*or* if is_compiled_class (DECL_CONTEXT (method_decl)) < 2.
--Per Bothner
bothner@pacbell.net http://home.pacbell.net/bothner/
^ permalink raw reply [flat|nested] 264+ messages in thread
* Re: assemble_external on .class files
1999-05-25 22:49 ` Per Bothner
@ 1999-05-31 14:53 ` Mark Klein
1999-05-31 21:36 ` Mark Klein
1999-05-31 21:36 ` Per Bothner
1 sibling, 1 reply; 264+ messages in thread
From: Mark Klein @ 1999-05-31 14:53 UTC (permalink / raw)
To: Per Bothner; +Cc: egcs, java-discuss
At 10:55 PM 5/25/99 -0700, Per Bothner wrote:
>METHOD_NATIVE does need to be split from DECL_EXTERNAL.
>There doesn't seem to be any available DECL_LANG_FLAGs,
>but there are some TREE_LANG_FLAGSs available (in FUNCTION_DECLs).
Grabbed TREE_LANG_FLAG_6.
>That means that we need to set DECL_EXTERNAL separately.
>I think it should be true for any methods that has METHOD_NATIVE,
>*or* if is_compiled_class (DECL_CONTEXT (method_decl)) < 2.
The latter doesn't appear to be complete either since there are
certain classes which are external (e.g. java.lang.Object) where
is_compiled_class (DECL_CONTEXT (method_decl)) is returning 2.
Regards,
M.
--
Mark Klein DIS International, Ltd.
http://www.dis.com 415-892-8400
PGP Public Key Available
^ permalink raw reply [flat|nested] 264+ messages in thread
* Re: assemble_external on .class files
1999-05-31 14:53 ` Mark Klein
@ 1999-05-31 21:36 ` Mark Klein
0 siblings, 0 replies; 264+ messages in thread
From: Mark Klein @ 1999-05-31 21:36 UTC (permalink / raw)
To: Per Bothner; +Cc: egcs, java-discuss
At 10:55 PM 5/25/99 -0700, Per Bothner wrote:
>METHOD_NATIVE does need to be split from DECL_EXTERNAL.
>There doesn't seem to be any available DECL_LANG_FLAGs,
>but there are some TREE_LANG_FLAGSs available (in FUNCTION_DECLs).
Grabbed TREE_LANG_FLAG_6.
>That means that we need to set DECL_EXTERNAL separately.
>I think it should be true for any methods that has METHOD_NATIVE,
>*or* if is_compiled_class (DECL_CONTEXT (method_decl)) < 2.
The latter doesn't appear to be complete either since there are
certain classes which are external (e.g. java.lang.Object) where
is_compiled_class (DECL_CONTEXT (method_decl)) is returning 2.
Regards,
M.
--
Mark Klein DIS International, Ltd.
http://www.dis.com 415-892-8400
PGP Public Key Available
^ permalink raw reply [flat|nested] 264+ messages in thread
* Re: assemble_external on .class files
1999-05-25 22:49 ` Per Bothner
1999-05-31 14:53 ` Mark Klein
@ 1999-05-31 21:36 ` Per Bothner
1 sibling, 0 replies; 264+ messages in thread
From: Per Bothner @ 1999-05-31 21:36 UTC (permalink / raw)
To: Mark Klein; +Cc: egcs, java-discuss
Mark Klein <mklein@dis.com> writes:
> Could be, but then there's a problem with assemble_external vis the usage of
> DECL_EXTERNAL for the vtable. Recall my earlier example, from
> java::lang::Object:
Ah - that was in a message that had expired.
My logic only applies to entries in the "method table". It is
wrong for entries in the vtable. It is also wrong for calls
to static methods in other classes.
METHOD_NATIVE does need to be split from DECL_EXTERNAL.
There doesn't seem to be any available DECL_LANG_FLAGs,
but there are some TREE_LANG_FLAGSs available (in FUNCTION_DECLs).
That means that we need to set DECL_EXTERNAL separately.
I think it should be true for any methods that has METHOD_NATIVE,
*or* if is_compiled_class (DECL_CONTEXT (method_decl)) < 2.
--Per Bothner
bothner@pacbell.net http://home.pacbell.net/bothner/
^ permalink raw reply [flat|nested] 264+ messages in thread
* Re: assemble_external on .class files
1999-05-25 22:19 ` Mark Klein
1999-05-25 22:24 ` Jeffrey A Law
1999-05-25 22:49 ` Per Bothner
@ 1999-05-31 21:36 ` Mark Klein
2 siblings, 0 replies; 264+ messages in thread
From: Mark Klein @ 1999-05-31 21:36 UTC (permalink / raw)
To: law, Per Bothner; +Cc: egcs, java-discuss
At 10:44 PM 5/25/99 -0600, Jeffrey A Law wrote:
>Thanks. Hmmm, this makes me think that we're find with having them overloaded
>on the same bit. Mark, I think this is a red herring.
Could be, but then there's a problem with assemble_external vis the usage of
DECL_EXTERNAL for the vtable. Recall my earlier example, from
java::lang::Object:
Method name:"finalize" protected Signature: 4=()void
...
Method name:"hashCode" public native Signature: 11=()int
and the vtable:
__vt_10HelloWorld
.word _CL_10HelloWorld
.word 0
.word P%finalize__Q34java4lang6Object
.IMPORT hashCode__Q34java4lang6Object,CODE
.word P%hashCode__Q34java4lang6Object
.word P%equals__Q34java4lang6ObjectPQ34java4lang6Object
.word P%toString__Q34java4lang6Object
.IMPORT clone__Q34java4lang6Object,CODE
.word P%clone__Q34java4lang6Object
Note that in order to use the plabels, the symbols must first be imported on
PA-RISC. In this case, we have finalize, and it isn't native. However, in
order for assemble_external to emit the .IMPORT, DECL_EXTERNAL (among others)
must be true. But, hashCode is native and is imported, hence the .IMPORT.
Since this is in contradiction to usage in jc1 as explained by Per, I've
got a problem....
Jeff (or any other PA-RISC user) ... has anyone tried gcj/libjava on a HP9000?
Or is this a problem only on the HP3000?
G'night, y'all.
--
Mark Klein DIS International, Ltd.
http://www.dis.com 415-892-8400
PGP Public Key Available
^ permalink raw reply [flat|nested] 264+ messages in thread
* Re: assemble_external on .class files
1999-05-25 21:50 ` Jeffrey A Law
1999-05-25 22:19 ` Mark Klein
@ 1999-05-31 21:36 ` Jeffrey A Law
1 sibling, 0 replies; 264+ messages in thread
From: Jeffrey A Law @ 1999-05-31 21:36 UTC (permalink / raw)
To: Per Bothner; +Cc: Mark Klein, egcs, java-discuss
In message < m2n1yseark.fsf@magnus.cygnus.com >you write:
> Well, the logic was the assumption that they would always be the same.
>
> In a Java class, we have three kinds of methods:
>
> (1) Regular methods (static or instance), with method bodies in the class
> body. These methods are neither native, nor external, since they are
> declared in the current input (.java or .class) file.
>
> (2) Native methods, which do not have bodies. These must be bound to some
> methods defined in some extenal C++ file. Hence, they need to have
> DECL_EXTERNAL set - as well as METHOD_NATIVE.
>
> (3) Abstract methods - which have no bodies anywhere. If they are ever
> referenced, it would be a compiler bug.
Thanks. Hmmm, this makes me think that we're find with having them overloaded
on the same bit. Mark, I think this is a red herring.
> However, perhaps there should be a comment where METHOD_NATIVE is
> defined. Something like the following may suffice:
> /* Only native methods are external (and vice versa). */
> or perhaps:
> /* A method is external if and only if it is native. */
Yea. It would help clarify things for the future.
Thanks again!
jeff
^ permalink raw reply [flat|nested] 264+ messages in thread
* Re: assemble_external on .class files
1999-05-25 21:00 ` Per Bothner
1999-05-25 21:50 ` Jeffrey A Law
@ 1999-05-31 21:36 ` Per Bothner
1 sibling, 0 replies; 264+ messages in thread
From: Per Bothner @ 1999-05-31 21:36 UTC (permalink / raw)
To: law; +Cc: Mark Klein, egcs, java-discuss
Jeffrey A Law <law@cygnus.com> writes:
> Split up DECL_EXTERNAL and METHOD_NATIVE. It seems awful strange/wrong to
> have them overloaded on the same bit. Can someone from the Java side
> explain why they're using the same bit? Especially since DECL_EXTERNAL has
> a well defined meaning already. It seems to me using a lang specific flag
> would make a lot more sense for METHOD_NATIVE.
Well, the logic was the assumption that they would always be the same.
In a Java class, we have three kinds of methods:
(1) Regular methods (static or instance), with method bodies in the class
body. These methods are neither native, nor external, since they are
declared in the current input (.java or .class) file.
(2) Native methods, which do not have bodies. These must be bound to some
methods defined in some extenal C++ file. Hence, they need to have
DECL_EXTERNAL set - as well as METHOD_NATIVE.
(3) Abstract methods - which have no bodies anywhere. If they are ever
referenced, it would be a compiler bug.
I skimmed the earlier messages in this thread, which may be why I still don't
understand why there would be any reason to split up the flags.
However, perhaps there should be a comment where METHOD_NATIVE is
defined. Something like the following may suffice:
/* Only native methods are external (and vice versa). */
or perhaps:
/* A method is external if and only if it is native. */
--
--Per Bothner
bothner@pacbell.net http://home.pacbell.net/bothner/
^ permalink raw reply [flat|nested] 264+ messages in thread
* Re: assemble_external on .class files
1999-05-25 19:41 ` Jeffrey A Law
1999-05-25 21:00 ` Per Bothner
@ 1999-05-31 21:36 ` Jeffrey A Law
1 sibling, 0 replies; 264+ messages in thread
From: Jeffrey A Law @ 1999-05-31 21:36 UTC (permalink / raw)
To: Mark Klein; +Cc: egcs, java-discuss
In message < 4.1.19990525180956.00c96100@garfield.dis.com >you write:
> Turns out that this also isn't a complete solution, partially because
> assemble_external is looking for DECL_EXTERNAL. The tree field used
> for DECL_EXTERNAL is also used for METHOD_NATIVE for java. That also
> explains why certain .IMPORTs were happening and others were not ...
> only native methods were getting the .IMPORTs.
>
> There may be another problem here in that DECL_EXTERNAL is explicitly
> set in various places and could ultimately end up in a usage conflict
> between it and the usage of METHOD_NATIVE elswhere in the code.
>
> Suggestions?
Split up DECL_EXTERNAL and METHOD_NATIVE. It seems awful strange/wrong to
have them overloaded on the same bit. Can someone from the Java side
explain why they're using the same bit? Especially since DECL_EXTERNAL has
a well defined meaning already. It seems to me using a lang specific flag
would make a lot more sense for METHOD_NATIVE.
jeff
^ permalink raw reply [flat|nested] 264+ messages in thread
* Re: assemble_external on .class files
1999-05-25 18:33 ` Mark Klein
1999-05-25 19:41 ` Jeffrey A Law
@ 1999-05-31 21:36 ` Mark Klein
1 sibling, 0 replies; 264+ messages in thread
From: Mark Klein @ 1999-05-31 21:36 UTC (permalink / raw)
To: Jeffrey A Law; +Cc: egcs, java-discuss
At 03:19 PM 5/22/99 -0600, Jeffrey A Law wrote:
> > My first attempt at
> > resolving this was to place an assemble_external() in
layout_class_method(),
> > but that results in a lot of clutter with .IMPORT statements for a
> > whole bunch of things that really are not referenced.
>I wouldn't worry about the extra .IMPORTs. In fact, it's a little known
>aspect of SOM that the assembler is responsible for _not_ adding an imported
>symbol to the undefined symbols for a module if that symbol is not actually
>referenced.
Turns out that this also isn't a complete solution, partially because
assemble_external is looking for DECL_EXTERNAL. The tree field used
for DECL_EXTERNAL is also used for METHOD_NATIVE for java. That also
explains why certain .IMPORTs were happening and others were not ...
only native methods were getting the .IMPORTs.
There may be another problem here in that DECL_EXTERNAL is explicitly
set in various places and could ultimately end up in a usage conflict
between it and the usage of METHOD_NATIVE elswhere in the code.
Suggestions?
M.
--
Mark Klein DIS International, Ltd.
http://www.dis.com 415-892-8400
PGP Public Key Available
^ permalink raw reply [flat|nested] 264+ messages in thread
* Re: assemble_external on .class files
1999-05-22 14:23 ` Jeffrey A Law
1999-05-22 15:28 ` Mark Klein
1999-05-25 18:33 ` Mark Klein
@ 1999-05-31 21:36 ` Jeffrey A Law
2 siblings, 0 replies; 264+ messages in thread
From: Jeffrey A Law @ 1999-05-31 21:36 UTC (permalink / raw)
To: Mark Klein; +Cc: egcs, java-discuss
In message < 4.1.19990520204749.00c7fa90@garfield.dis.com >you write:
> External procedure labels need to be .IMPORTED before they can
> be used on my platform. Some of these are part of a dispatch table
> created from classes such as java::lang::Object. My first attempt at
> resolving this was to place an assemble_external() in layout_class(),
> but that results in a lot of clutter with .IMPORT statements for a
> whole bunch of things that really are not referenced. I suppose this
> could be my brute force method, but I would prefer to only do the
> .IMPORT for referenced methods/classes.
I wouldn't worry about the extra .IMPORTs. In fact, it's a little known
aspect of SOM that the assembler is responsible for _not_ adding an imported
symbol to the undefined symbols for a module if that symbol is not actually
referenced.
Jeff
^ permalink raw reply [flat|nested] 264+ messages in thread
* assemble_external on .class files
1999-05-20 21:06 assemble_external on .class files Mark Klein
1999-05-22 14:23 ` Jeffrey A Law
@ 1999-05-31 21:36 ` Mark Klein
1 sibling, 0 replies; 264+ messages in thread
From: Mark Klein @ 1999-05-31 21:36 UTC (permalink / raw)
To: egcs; +Cc: java-discuss
I'm having a whale of a time trying to figure out a problem I'm
experiencing with gcj:
External procedure labels need to be .IMPORTED before they can
be used on my platform. Some of these are part of a dispatch table
created from classes such as java::lang::Object. My first attempt at
resolving this was to place an assemble_external() in layout_class(),
but that results in a lot of clutter with .IMPORT statements for a
whole bunch of things that really are not referenced. I suppose this
could be my brute force method, but I would prefer to only do the
.IMPORT for referenced methods/classes.
Here's HelloWorld's _vt_:
.IMPORT clone__Q34java4lang6Object,CODE
.IMPORT hashCode__Q34java4lang6Object,CODE
.align 4
HelloWorld virtual table
.word _CL_10HelloWorld
.word 0
.word P%java::lang::Object::finalize(void)
.word P%java::lang::Object::hashCode(void)
.word P%java::lang::Object::equals(java::lang::Object *)
.word P%java::lang::Object::toString(void)
.word P%java::lang::Object::clone(void)
Note that clone() and hashCode() have been imported. But finalize(),
equals() and tostring() have not. They are referenced in some fashion
in order to be in the virtual table when the rest of their brethren
are not. But, clone() and hashCode() must be referenced in some other
path in order to cause them to be imported.
I can't seem to figure out what that path is in order to make the same
changes for the other case. I also have not completed by gdb port, so
I am debugging this with the native (non-symbolic) debugger, which is
also probably leading to some of my confusion as I chase pointers in trees.
TIA,
M.
--
Mark Klein DIS International, Ltd.
http://www.dis.com 415-892-8400
PGP Public Key Available
^ permalink raw reply [flat|nested] 264+ messages in thread
* Bug in libm or libstdc++.
@ 1999-02-24 15:13 Paul Derbyshire
[not found] ` < 3.0.6.32.19990222090333.00847df0@pop.globalserve.net >
1999-02-28 22:53 ` Paul Derbyshire
0 siblings, 2 replies; 264+ messages in thread
From: Paul Derbyshire @ 1999-02-24 15:13 UTC (permalink / raw)
To: egcs, egcs-bugs
C:\PGD\C++\omega\ofc>gcc ntst.cc -o ntst.exe -Wall -lm -lstdcxx
c:/djgpp/tmp/cc5PNfut.o(.text+0x51):ntst.cc: undefined reference to
`atan(long double)'
c:/djgpp/tmp/cc5PNfut.o(.text+0xa8):ntst.cc: undefined reference to
`exp(long double)'
c:/djgpp/tmp/cc5PNfut.o(.text+0xef):ntst.cc: undefined reference to
`log(long double)'
c:/djgpp/tmp/cc5PNfut.o(.text+0x136):ntst.cc: undefined reference to
`log(long double)'
c:/djgpp/tmp/cc5PNfut.o(.text+0x17d):ntst.cc: undefined reference to
`sqrt(long double)'
What the hell?
Stroustrup 3rd Ed definitely informs me that long double overloads for
these and other functions are supposed to be in either libm or libstdc++.
Using egcs 1.1.1 and the libm and libstdc++ that came with it.
--
.*. "Clouds are not spheres, mountains are not cones, coastlines are not
-() < circles, and bark is not smooth, nor does lightning travel in a
`*' straight line." -------------------------------------------------
-- B. Mandelbrot | http://surf.to/pgd.net
_____________________ ____|________ Paul Derbyshire pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|
^ permalink raw reply [flat|nested] 264+ messages in thread
[parent not found: < 3.0.6.32.19990222090333.00847df0@pop.globalserve.net >]
* Re: Bug in libm or libstdc++.
[not found] ` < 3.0.6.32.19990222090333.00847df0@pop.globalserve.net >
@ 1999-02-24 15:34 ` Joe Buck
[not found] ` < 199902242332.PAA09334@atrus.synopsys.com >
1999-02-28 22:53 ` Joe Buck
1999-02-24 15:42 ` Bob McWhirter
1 sibling, 2 replies; 264+ messages in thread
From: Joe Buck @ 1999-02-24 15:34 UTC (permalink / raw)
To: Paul Derbyshire; +Cc: egcs, egcs-bugs
[ no "long double" overloads of math functions ]
> Stroustrup 3rd Ed definitely informs me that long double overloads for
> these and other functions are supposed to be in either libm or libstdc++.
You have already been informed that libstdc++ is not complete. Sorry.
^ permalink raw reply [flat|nested] 264+ messages in thread
[parent not found: < 199902242332.PAA09334@atrus.synopsys.com >]
* Re: Bug in libm or libstdc++.
[not found] ` < 199902242332.PAA09334@atrus.synopsys.com >
@ 1999-02-25 22:25 ` Paul Derbyshire
[not found] ` < 3.0.6.32.19990226012513.008e5450@pop.globalserve.net >
1999-02-28 22:53 ` Paul Derbyshire
0 siblings, 2 replies; 264+ messages in thread
From: Paul Derbyshire @ 1999-02-25 22:25 UTC (permalink / raw)
To: egcs
At 03:32 PM 2/24/99 PST, you wrote:
>You have already been informed that libstdc++ is not complete. Sorry.
The standard has been around in largely complete form for over a year, and
finalized for many months. I am curious as to what is the cause for all of
these omissions... I would love to help but I don't know the first thing
about implementing these mathematical functions.
In any case, to avoid any more unpleasant surprised I would like to see a
list of all the omissions in the current libstdc++ and other
non-conformances, and where possible ETAs for the missing components. It
would be a good idea to post a periodic libstdc++ progress report and calls
for volunteers to implement some of the stuff. I think that might attract
more developers to fixing up and finishing implementing the standard C++
library.
An area where I may be able to help is with the standard valarray and its
friends, once I get back a response regarding making the compiler eliminate
temporaries and excess copies in argument passing and return.
--
.*. "Clouds are not spheres, mountains are not cones, coastlines are not
-() < circles, and bark is not smooth, nor does lightning travel in a
`*' straight line." -------------------------------------------------
-- B. Mandelbrot | http://surf.to/pgd.net
_____________________ ____|________ Paul Derbyshire pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|
^ permalink raw reply [flat|nested] 264+ messages in thread
[parent not found: < 3.0.6.32.19990226012513.008e5450@pop.globalserve.net >]
* Re: Bug in libm or libstdc++.
[not found] ` < 3.0.6.32.19990226012513.008e5450@pop.globalserve.net >
@ 1999-02-26 10:38 ` Joe Buck
[not found] ` < 199902261836.KAA17757@atrus.synopsys.com >
1999-02-28 22:53 ` Joe Buck
0 siblings, 2 replies; 264+ messages in thread
From: Joe Buck @ 1999-02-26 10:38 UTC (permalink / raw)
To: Paul Derbyshire; +Cc: egcs
> At 03:32 PM 2/24/99 PST, you wrote:
> >You have already been informed that libstdc++ is not complete. Sorry.
>
> The standard has been around in largely complete form for over a year, and
> finalized for many months. I am curious as to what is the cause for all of
> these omissions...
Limited resources. Up to now most resources have been concentrated on
completing the compiler portion of the standard, and we are very close.
The only significant unimplemented feature is "export".
> In any case, to avoid any more unpleasant surprised I would like to see a
> list of all the omissions in the current libstdc++ and other
> non-conformances, and where possible ETAs for the missing components.
If you would like to volunteer to assemble such a list, and do most of
the research yourself, you might find that others are willing to help.
If you continue to demand that others do work, you will probably just
create more hostility.
As for ETAs, in the free software world the only answer you will get is
"when it's ready".
> It
> would be a good idea to post a periodic libstdc++ progress report and calls
> for volunteers to implement some of the stuff. I think that might attract
> more developers to fixing up and finishing implementing the standard C++
> library.
See http://sourceware.cygnus.com/libstdc++/
> An area where I may be able to help is with the standard valarray and its
> friends, once I get back a response regarding making the compiler eliminate
> temporaries and excess copies in argument passing and return.
Again, see above.
^ permalink raw reply [flat|nested] 264+ messages in thread
[parent not found: < 199902261836.KAA17757@atrus.synopsys.com >]
* Re: Bug in libm or libstdc++.
[not found] ` < 199902261836.KAA17757@atrus.synopsys.com >
@ 1999-02-26 22:21 ` Paul Derbyshire
[not found] ` < 3.0.6.32.19990227012120.0084e180@pop.globalserve.net >
1999-02-28 22:53 ` Paul Derbyshire
0 siblings, 2 replies; 264+ messages in thread
From: Paul Derbyshire @ 1999-02-26 22:21 UTC (permalink / raw)
To: egcs
At 10:36 AM 2/26/99 PST, you wrote:
>Limited resources. Up to now most resources have been concentrated on
>completing the compiler portion of the standard, and we are very close.
>The only significant unimplemented feature is "export".
My copy of Stroustrup makes no mention of "export", IIRC.
>If you would like to volunteer to assemble such a list...
Ack!
Well, for starters:
* <valarray> to be implemented
* <limits> to be implemented
* "void (*foo) (void) throw ();" causes a spurious error
* IIRC stringstreams and <sstream> were incomplete/missing
Anyone else who'se noticed an omission/incomplete thing/bug in C++ support
that isn't platform-dependent is welcome to add to the list.
>As for ETAs, in the free software world the only answer you will get is
>"when it's ready".
Or "when you do it yourself" right? <g>
I may be able to cobble together a draft of a working <valarray>. If I come
up with one amidst all the other work I'm doing on my own stuff, I'll be
sure to offer it here.
>See http://sourceware.cygnus.com/libstdc++/
OK
--
.*. "Clouds are not spheres, mountains are not cones, coastlines are not
-() < circles, and bark is not smooth, nor does lightning travel in a
`*' straight line." -------------------------------------------------
-- B. Mandelbrot | http://surf.to/pgd.net
_____________________ ____|________ Paul Derbyshire pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|
^ permalink raw reply [flat|nested] 264+ messages in thread
[parent not found: < 3.0.6.32.19990227012120.0084e180@pop.globalserve.net >]
* Re: Bug in libm or libstdc++.
[not found] ` < 3.0.6.32.19990227012120.0084e180@pop.globalserve.net >
@ 1999-02-27 9:40 ` Marc Espie
[not found] ` < 199902271740.SAA14323@quatramaran.ens.fr >
1999-02-28 22:53 ` Marc Espie
0 siblings, 2 replies; 264+ messages in thread
From: Marc Espie @ 1999-02-27 9:40 UTC (permalink / raw)
To: egcs
In article < 3.0.6.32.19990227012120.0084e180@pop.globalserve.net > you write:
>At 10:36 AM 2/26/99 PST, you wrote:
>>Limited resources. Up to now most resources have been concentrated on
>>completing the compiler portion of the standard, and we are very close.
>>The only significant unimplemented feature is "export".
>My copy of Stroustrup makes no mention of "export", IIRC.
Get a newer one, or better yet, get a clue.
I have the chance to read the egcs-ml thru an email to local news
gateway.
You know what ? You're the first individual to make my kill-file on this list.
^ permalink raw reply [flat|nested] 264+ messages in thread
[parent not found: < 199902271740.SAA14323@quatramaran.ens.fr >]
* Re: Bug in libm or libstdc++.
[not found] ` < 199902271740.SAA14323@quatramaran.ens.fr >
@ 1999-02-27 20:45 ` Paul Derbyshire
1999-02-28 22:53 ` Paul Derbyshire
1999-03-01 0:19 ` Alexandre Oliva
0 siblings, 2 replies; 264+ messages in thread
From: Paul Derbyshire @ 1999-02-27 20:45 UTC (permalink / raw)
To: egcs
At 06:40 PM 2/27/99 +0100, you wrote:
>Get a newer one, or better yet, get a clue.
1. I have THE 3RD EDITION, in other words THE MOST RECENT VERSION, as
I've mentioned a few times before.
2. There is no need to be insulting. We're all mature adults here...or
at least I thought we were...
--
.*. "Clouds are not spheres, mountains are not cones, coastlines are not
-() < circles, and bark is not smooth, nor does lightning travel in a
`*' straight line." -------------------------------------------------
-- B. Mandelbrot | http://surf.to/pgd.net
_____________________ ____|________ Paul Derbyshire pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|
^ permalink raw reply [flat|nested] 264+ messages in thread
* Re: Bug in libm or libstdc++.
1999-02-27 20:45 ` Paul Derbyshire
@ 1999-02-28 22:53 ` Paul Derbyshire
1999-03-01 0:19 ` Alexandre Oliva
1 sibling, 0 replies; 264+ messages in thread
From: Paul Derbyshire @ 1999-02-28 22:53 UTC (permalink / raw)
To: egcs
At 06:40 PM 2/27/99 +0100, you wrote:
>Get a newer one, or better yet, get a clue.
1. I have THE 3RD EDITION, in other words THE MOST RECENT VERSION, as
I've mentioned a few times before.
2. There is no need to be insulting. We're all mature adults here...or
at least I thought we were...
--
.*. "Clouds are not spheres, mountains are not cones, coastlines are not
-() < circles, and bark is not smooth, nor does lightning travel in a
`*' straight line." -------------------------------------------------
-- B. Mandelbrot | http://surf.to/pgd.net
_____________________ ____|________ Paul Derbyshire pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|
^ permalink raw reply [flat|nested] 264+ messages in thread
* Re: Bug in libm or libstdc++.
1999-02-27 20:45 ` Paul Derbyshire
1999-02-28 22:53 ` Paul Derbyshire
@ 1999-03-01 0:19 ` Alexandre Oliva
[not found] ` < ord82tlj4l.fsf@araguaia.dcc.unicamp.br >
1999-03-31 23:46 ` Alexandre Oliva
1 sibling, 2 replies; 264+ messages in thread
From: Alexandre Oliva @ 1999-03-01 0:19 UTC (permalink / raw)
To: Paul Derbyshire; +Cc: egcs
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 589 bytes --]
On Feb 28, 1999, Paul Derbyshire <pderbysh@usa.net> wrote:
> At 06:40 PM 2/27/99 +0100, you wrote:
>> Get a newer one, or better yet, get a clue.
> 1. I have THE 3RD EDITION, in other words THE MOST RECENT VERSION, as
> I've mentioned a few times before.
It is outdated anyway. It is not the ANSI C++ Standard, and egcs
targets the ANSI C++ Standard, not the ARM.
--
Alexandre Oliva http://www.dcc.unicamp.br/~oliva aoliva@{acm.org,computer.org}
oliva@{dcc.unicamp.br,gnu.org,egcs.cygnus.com,samba.org}
Instituto de Computação, Universidade Estadual de Campinas, SP, Brasil
^ permalink raw reply [flat|nested] 264+ messages in thread
[parent not found: < ord82tlj4l.fsf@araguaia.dcc.unicamp.br >]
* Re: Bug in libm or libstdc++.
[not found] ` < ord82tlj4l.fsf@araguaia.dcc.unicamp.br >
@ 1999-03-02 7:58 ` Paul Derbyshire
1999-03-02 23:08 ` Alexandre Oliva
1999-03-31 23:46 ` Paul Derbyshire
0 siblings, 2 replies; 264+ messages in thread
From: Paul Derbyshire @ 1999-03-02 7:58 UTC (permalink / raw)
To: egcs
At 05:16 AM 3/1/99 -0300, you wrote:
>> 1. I have THE 3RD EDITION, in other words THE MOST RECENT VERSION, as
>> I've mentioned a few times before.
>
>It is outdated anyway.
No it is not. It's the most recent version around, so it isn't possible for
it to be outdated, especially since if it were, this would be completely
unacceptable, as it would imply that there is no up-to-date reference, and
that of course just can't have been allowed.
>...egcs targets the ANSI C++ Standard, not the ARM.
What is "the ARM"?
(Note: Search engine results: 725,480 hits, of which none on the
first page are relevant. Search engines are simply not usable for
finding this stuff out! Unless you honestly expect me to read
through 72,548 pages and 725,480 URLs and descriptions before
asking any questions, which would be ludicruous.)
In any case, quit accusing me of ignorance of the C++ essentials and quit
accusing, of all people, Bjarne Stroustrup of same. BTW, this is veering
rapidly off-topic due to you.
--
.*. "Clouds are not spheres, mountains are not cones, coastlines are not
-() < circles, and bark is not smooth, nor does lightning travel in a
`*' straight line." -------------------------------------------------
-- B. Mandelbrot | http://surf.to/pgd.net
_____________________ ____|________ Paul Derbyshire pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|
^ permalink raw reply [flat|nested] 264+ messages in thread
* Re: Bug in libm or libstdc++.
1999-03-02 7:58 ` Paul Derbyshire
@ 1999-03-02 23:08 ` Alexandre Oliva
1999-03-31 23:46 ` Alexandre Oliva
1999-03-31 23:46 ` Paul Derbyshire
1 sibling, 1 reply; 264+ messages in thread
From: Alexandre Oliva @ 1999-03-02 23:08 UTC (permalink / raw)
To: Paul Derbyshire; +Cc: egcs
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 424 bytes --]
On Mar 2, 1999, Paul Derbyshire <pderbysh@usa.net> wrote:
>> ...egcs targets the ANSI C++ Standard, not the ARM.
> What is "the ARM"?
The ARM is Stroustrup's book. It is not the ANSI/ISO C++ Standard.
--
Alexandre Oliva http://www.dcc.unicamp.br/~oliva aoliva@{acm.org,computer.org}
oliva@{dcc.unicamp.br,gnu.org,egcs.cygnus.com,samba.org}
Instituto de Computação, Universidade Estadual de Campinas, SP, Brasil
^ permalink raw reply [flat|nested] 264+ messages in thread
* Re: Bug in libm or libstdc++.
1999-03-02 23:08 ` Alexandre Oliva
@ 1999-03-31 23:46 ` Alexandre Oliva
0 siblings, 0 replies; 264+ messages in thread
From: Alexandre Oliva @ 1999-03-31 23:46 UTC (permalink / raw)
To: Paul Derbyshire; +Cc: egcs
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 425 bytes --]
On Mar 2, 1999, Paul Derbyshire <pderbysh@usa.net> wrote:
>> ...egcs targets the ANSI C++ Standard, not the ARM.
> What is "the ARM"?
The ARM is Stroustrup's book. It is not the ANSI/ISO C++ Standard.
--
Alexandre Oliva http://www.dcc.unicamp.br/~oliva aoliva@{acm.org,computer.org}
oliva@{dcc.unicamp.br,gnu.org,egcs.cygnus.com,samba.org}
Instituto de Computação, Universidade Estadual de Campinas, SP, Brasil
^ permalink raw reply [flat|nested] 264+ messages in thread
* Re: Bug in libm or libstdc++.
1999-03-02 7:58 ` Paul Derbyshire
1999-03-02 23:08 ` Alexandre Oliva
@ 1999-03-31 23:46 ` Paul Derbyshire
1 sibling, 0 replies; 264+ messages in thread
From: Paul Derbyshire @ 1999-03-31 23:46 UTC (permalink / raw)
To: egcs
At 05:16 AM 3/1/99 -0300, you wrote:
>> 1. I have THE 3RD EDITION, in other words THE MOST RECENT VERSION, as
>> I've mentioned a few times before.
>
>It is outdated anyway.
No it is not. It's the most recent version around, so it isn't possible for
it to be outdated, especially since if it were, this would be completely
unacceptable, as it would imply that there is no up-to-date reference, and
that of course just can't have been allowed.
>...egcs targets the ANSI C++ Standard, not the ARM.
What is "the ARM"?
(Note: Search engine results: 725,480 hits, of which none on the
first page are relevant. Search engines are simply not usable for
finding this stuff out! Unless you honestly expect me to read
through 72,548 pages and 725,480 URLs and descriptions before
asking any questions, which would be ludicruous.)
In any case, quit accusing me of ignorance of the C++ essentials and quit
accusing, of all people, Bjarne Stroustrup of same. BTW, this is veering
rapidly off-topic due to you.
--
.*. "Clouds are not spheres, mountains are not cones, coastlines are not
-() < circles, and bark is not smooth, nor does lightning travel in a
`*' straight line." -------------------------------------------------
-- B. Mandelbrot | http://surf.to/pgd.net
_____________________ ____|________ Paul Derbyshire pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|
^ permalink raw reply [flat|nested] 264+ messages in thread
* Re: Bug in libm or libstdc++.
1999-03-01 0:19 ` Alexandre Oliva
[not found] ` < ord82tlj4l.fsf@araguaia.dcc.unicamp.br >
@ 1999-03-31 23:46 ` Alexandre Oliva
1 sibling, 0 replies; 264+ messages in thread
From: Alexandre Oliva @ 1999-03-31 23:46 UTC (permalink / raw)
To: Paul Derbyshire; +Cc: egcs
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 590 bytes --]
On Feb 28, 1999, Paul Derbyshire <pderbysh@usa.net> wrote:
> At 06:40 PM 2/27/99 +0100, you wrote:
>> Get a newer one, or better yet, get a clue.
> 1. I have THE 3RD EDITION, in other words THE MOST RECENT VERSION, as
> I've mentioned a few times before.
It is outdated anyway. It is not the ANSI C++ Standard, and egcs
targets the ANSI C++ Standard, not the ARM.
--
Alexandre Oliva http://www.dcc.unicamp.br/~oliva aoliva@{acm.org,computer.org}
oliva@{dcc.unicamp.br,gnu.org,egcs.cygnus.com,samba.org}
Instituto de Computação, Universidade Estadual de Campinas, SP, Brasil
^ permalink raw reply [flat|nested] 264+ messages in thread
* Re: Bug in libm or libstdc++.
1999-02-27 9:40 ` Marc Espie
[not found] ` < 199902271740.SAA14323@quatramaran.ens.fr >
@ 1999-02-28 22:53 ` Marc Espie
1 sibling, 0 replies; 264+ messages in thread
From: Marc Espie @ 1999-02-28 22:53 UTC (permalink / raw)
To: egcs
In article < 3.0.6.32.19990227012120.0084e180@pop.globalserve.net > you write:
>At 10:36 AM 2/26/99 PST, you wrote:
>>Limited resources. Up to now most resources have been concentrated on
>>completing the compiler portion of the standard, and we are very close.
>>The only significant unimplemented feature is "export".
>My copy of Stroustrup makes no mention of "export", IIRC.
Get a newer one, or better yet, get a clue.
I have the chance to read the egcs-ml thru an email to local news
gateway.
You know what ? You're the first individual to make my kill-file on this list.
^ permalink raw reply [flat|nested] 264+ messages in thread
* Re: Bug in libm or libstdc++.
1999-02-26 22:21 ` Paul Derbyshire
[not found] ` < 3.0.6.32.19990227012120.0084e180@pop.globalserve.net >
@ 1999-02-28 22:53 ` Paul Derbyshire
1 sibling, 0 replies; 264+ messages in thread
From: Paul Derbyshire @ 1999-02-28 22:53 UTC (permalink / raw)
To: egcs
At 10:36 AM 2/26/99 PST, you wrote:
>Limited resources. Up to now most resources have been concentrated on
>completing the compiler portion of the standard, and we are very close.
>The only significant unimplemented feature is "export".
My copy of Stroustrup makes no mention of "export", IIRC.
>If you would like to volunteer to assemble such a list...
Ack!
Well, for starters:
* <valarray> to be implemented
* <limits> to be implemented
* "void (*foo) (void) throw ();" causes a spurious error
* IIRC stringstreams and <sstream> were incomplete/missing
Anyone else who'se noticed an omission/incomplete thing/bug in C++ support
that isn't platform-dependent is welcome to add to the list.
>As for ETAs, in the free software world the only answer you will get is
>"when it's ready".
Or "when you do it yourself" right? <g>
I may be able to cobble together a draft of a working <valarray>. If I come
up with one amidst all the other work I'm doing on my own stuff, I'll be
sure to offer it here.
>See http://sourceware.cygnus.com/libstdc++/
OK
--
.*. "Clouds are not spheres, mountains are not cones, coastlines are not
-() < circles, and bark is not smooth, nor does lightning travel in a
`*' straight line." -------------------------------------------------
-- B. Mandelbrot | http://surf.to/pgd.net
_____________________ ____|________ Paul Derbyshire pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|
^ permalink raw reply [flat|nested] 264+ messages in thread
* Re: Bug in libm or libstdc++.
1999-02-26 10:38 ` Joe Buck
[not found] ` < 199902261836.KAA17757@atrus.synopsys.com >
@ 1999-02-28 22:53 ` Joe Buck
1 sibling, 0 replies; 264+ messages in thread
From: Joe Buck @ 1999-02-28 22:53 UTC (permalink / raw)
To: Paul Derbyshire; +Cc: egcs
> At 03:32 PM 2/24/99 PST, you wrote:
> >You have already been informed that libstdc++ is not complete. Sorry.
>
> The standard has been around in largely complete form for over a year, and
> finalized for many months. I am curious as to what is the cause for all of
> these omissions...
Limited resources. Up to now most resources have been concentrated on
completing the compiler portion of the standard, and we are very close.
The only significant unimplemented feature is "export".
> In any case, to avoid any more unpleasant surprised I would like to see a
> list of all the omissions in the current libstdc++ and other
> non-conformances, and where possible ETAs for the missing components.
If you would like to volunteer to assemble such a list, and do most of
the research yourself, you might find that others are willing to help.
If you continue to demand that others do work, you will probably just
create more hostility.
As for ETAs, in the free software world the only answer you will get is
"when it's ready".
> It
> would be a good idea to post a periodic libstdc++ progress report and calls
> for volunteers to implement some of the stuff. I think that might attract
> more developers to fixing up and finishing implementing the standard C++
> library.
See http://sourceware.cygnus.com/libstdc++/
> An area where I may be able to help is with the standard valarray and its
> friends, once I get back a response regarding making the compiler eliminate
> temporaries and excess copies in argument passing and return.
Again, see above.
^ permalink raw reply [flat|nested] 264+ messages in thread
* Re: Bug in libm or libstdc++.
1999-02-25 22:25 ` Paul Derbyshire
[not found] ` < 3.0.6.32.19990226012513.008e5450@pop.globalserve.net >
@ 1999-02-28 22:53 ` Paul Derbyshire
1 sibling, 0 replies; 264+ messages in thread
From: Paul Derbyshire @ 1999-02-28 22:53 UTC (permalink / raw)
To: egcs
At 03:32 PM 2/24/99 PST, you wrote:
>You have already been informed that libstdc++ is not complete. Sorry.
The standard has been around in largely complete form for over a year, and
finalized for many months. I am curious as to what is the cause for all of
these omissions... I would love to help but I don't know the first thing
about implementing these mathematical functions.
In any case, to avoid any more unpleasant surprised I would like to see a
list of all the omissions in the current libstdc++ and other
non-conformances, and where possible ETAs for the missing components. It
would be a good idea to post a periodic libstdc++ progress report and calls
for volunteers to implement some of the stuff. I think that might attract
more developers to fixing up and finishing implementing the standard C++
library.
An area where I may be able to help is with the standard valarray and its
friends, once I get back a response regarding making the compiler eliminate
temporaries and excess copies in argument passing and return.
--
.*. "Clouds are not spheres, mountains are not cones, coastlines are not
-() < circles, and bark is not smooth, nor does lightning travel in a
`*' straight line." -------------------------------------------------
-- B. Mandelbrot | http://surf.to/pgd.net
_____________________ ____|________ Paul Derbyshire pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|
^ permalink raw reply [flat|nested] 264+ messages in thread
* Re: Bug in libm or libstdc++.
1999-02-24 15:34 ` Joe Buck
[not found] ` < 199902242332.PAA09334@atrus.synopsys.com >
@ 1999-02-28 22:53 ` Joe Buck
1 sibling, 0 replies; 264+ messages in thread
From: Joe Buck @ 1999-02-28 22:53 UTC (permalink / raw)
To: Paul Derbyshire; +Cc: egcs, egcs-bugs
[ no "long double" overloads of math functions ]
> Stroustrup 3rd Ed definitely informs me that long double overloads for
> these and other functions are supposed to be in either libm or libstdc++.
You have already been informed that libstdc++ is not complete. Sorry.
^ permalink raw reply [flat|nested] 264+ messages in thread
* Re: Bug in libm or libstdc++.
[not found] ` < 3.0.6.32.19990222090333.00847df0@pop.globalserve.net >
1999-02-24 15:34 ` Joe Buck
@ 1999-02-24 15:42 ` Bob McWhirter
[not found] ` < Pine.LNX.3.96.990224183714.7438r-100000@exeter.exeter.org >
1999-02-28 22:53 ` Bob McWhirter
1 sibling, 2 replies; 264+ messages in thread
From: Bob McWhirter @ 1999-02-24 15:42 UTC (permalink / raw)
To: egcs
On Mon, 22 Feb 1999, Paul Derbyshire wrote:
> C:\PGD\C++\omega\ofc>gcc ntst.cc -o ntst.exe -Wall -lm -lstdcxx
> c:/djgpp/tmp/cc5PNfut.o(.text+0x51):ntst.cc: undefined reference to
> `atan(long double)'
[ snip ]
> What the hell?
Is that -really- necessary? Pipe down, already.
> Stroustrup 3rd Ed definitely informs me that long double overloads for
> these and other functions are supposed to be in either libm or libstdc++.
Uhhh... if you're referring to page 660 (section 22.3)
it most certainly does not make any such guarantee with
regards to -long double- datatypes.
> Using egcs 1.1.1 and the libm and libstdc++ that came with it.
at least on my box (sparc solaris), libm is vendor provided.
gnu/include/g++/cmath -does- make reference to the math
functions that use long doubles for arguments, but I don't
think any library on my box actually supports them.
Possibly there for platforms that do? There for platforms
that typedef a long double to be the same as a double?
(nm'ing vendor's libm and stdc++ does not reveal math
functions taking long doubles, but possibly some other
lib I'm ignoring? I did find math functions take
complex objects as arguments though.)
-Bob
^ permalink raw reply [flat|nested] 264+ messages in thread
[parent not found: < Pine.LNX.3.96.990224183714.7438r-100000@exeter.exeter.org >]
* Re: Bug in libm or libstdc++.
[not found] ` < Pine.LNX.3.96.990224183714.7438r-100000@exeter.exeter.org >
@ 1999-02-25 22:20 ` Paul Derbyshire
[not found] ` <199902261635.LAA23787@wagner.Princeton.EDU>
` (2 more replies)
0 siblings, 3 replies; 264+ messages in thread
From: Paul Derbyshire @ 1999-02-25 22:20 UTC (permalink / raw)
To: egcs, djgpp
> Uhhh... if you're referring to page 660 (section 22.3)
> it most certainly does not make any such guarantee with
> regards to -long double- datatypes.
S22.3, page 661: "double atan (double) ..... In addition, <cmath> and
<math.h> supply these functions for float and long double arguments."
You're wrong, I'm right. Long double versions of atan and friends ARE
demanded by the standard. I would like to see them very soon so that I may
use them (the long double versions anyways) when I want that bit of extra
precision.......
> at least on my box (sparc solaris), libm is vendor provided.
Not on an IBM PC clone, where it comes with the DJGPP/Cygwin/whatever
development environment you install. I installed the DJGPP/EGCS development
environment and got a broken libm.
> gnu/include/g++/cmath -does- make reference to the math
> functions that use long doubles for arguments, but I don't
> think any library on my box actually supports them.
Then those libraries are broken and not conformant. I suggest you complain
to the vendor. You may also want to ask the bookstore where you got your
copy of Stroustrup for an exchange or a refund; I sure would have if my
copy had turned out to have pp. 661-662 torn out or missing.
Anyways, since these are function overloads in C++, I would expect the long
double and float versions to be in libstdc++, not libm. And libstdc++ comes
with gcc/egcs rather than being vendor supplied, on all platforms. If the
egcs libstdc++ is lacking long double overloads for atan and the like, then
this is a bug in egcs.
--
.*. "Clouds are not spheres, mountains are not cones, coastlines are not
-() < circles, and bark is not smooth, nor does lightning travel in a
`*' straight line." -------------------------------------------------
-- B. Mandelbrot | http://surf.to/pgd.net
_____________________ ____|________ Paul Derbyshire pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|
^ permalink raw reply [flat|nested] 264+ messages in thread
[parent not found: <199902261635.LAA23787@wagner.Princeton.EDU>]
* Re: Bug in libm or libstdc++.
[not found] ` <199902261635.LAA23787@wagner.Princeton.EDU>
@ 1999-02-27 19:08 ` Paul Derbyshire
1999-02-28 22:53 ` Paul Derbyshire
1999-03-01 8:30 ` Joern Rennecke
0 siblings, 2 replies; 264+ messages in thread
From: Paul Derbyshire @ 1999-02-27 19:08 UTC (permalink / raw)
To: egcs
At 11:35 AM 2/26/99 -0500, you wrote:
[Long double overloads of libm functions in libstdc++]
>Then ... implement them.
I may be mathematically inclined but I have none of the
numerical-computation background necessary to know how to implement these
things in an optimized way. Best I could probably do is a slowly converging
Taylor series for these things. You ened a volunteer with a bit more
knowledge in techniques of rapid numerical computation of trig functions.
--
.*. "Clouds are not spheres, mountains are not cones, coastlines are not
-() < circles, and bark is not smooth, nor does lightning travel in a
`*' straight line." -------------------------------------------------
-- B. Mandelbrot | http://surf.to/pgd.net
_____________________ ____|________ Paul Derbyshire pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|
^ permalink raw reply [flat|nested] 264+ messages in thread
* Re: Bug in libm or libstdc++.
1999-02-27 19:08 ` Paul Derbyshire
@ 1999-02-28 22:53 ` Paul Derbyshire
1999-03-01 8:30 ` Joern Rennecke
1 sibling, 0 replies; 264+ messages in thread
From: Paul Derbyshire @ 1999-02-28 22:53 UTC (permalink / raw)
To: egcs
At 11:35 AM 2/26/99 -0500, you wrote:
[Long double overloads of libm functions in libstdc++]
>Then ... implement them.
I may be mathematically inclined but I have none of the
numerical-computation background necessary to know how to implement these
things in an optimized way. Best I could probably do is a slowly converging
Taylor series for these things. You ened a volunteer with a bit more
knowledge in techniques of rapid numerical computation of trig functions.
--
.*. "Clouds are not spheres, mountains are not cones, coastlines are not
-() < circles, and bark is not smooth, nor does lightning travel in a
`*' straight line." -------------------------------------------------
-- B. Mandelbrot | http://surf.to/pgd.net
_____________________ ____|________ Paul Derbyshire pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|
^ permalink raw reply [flat|nested] 264+ messages in thread
* Re: Bug in libm or libstdc++.
1999-02-27 19:08 ` Paul Derbyshire
1999-02-28 22:53 ` Paul Derbyshire
@ 1999-03-01 8:30 ` Joern Rennecke
[not found] ` < 199903011630.QAA00110@phal.cygnus.co.uk >
1999-03-31 23:46 ` Joern Rennecke
1 sibling, 2 replies; 264+ messages in thread
From: Joern Rennecke @ 1999-03-01 8:30 UTC (permalink / raw)
To: Paul Derbyshire; +Cc: egcs
> I may be mathematically inclined but I have none of the
> numerical-computation background necessary to know how to implement these
> things in an optimized way. Best I could probably do is a slowly converging
> Taylor series for these things. You ened a volunteer with a bit more
> knowledge in techniques of rapid numerical computation of trig functions.
When you want to use a Polynom approximation, you should rather use a
Tschebyscheff polynom. Look it up in a mathematical enceclopedia.
If you just want to get something working, you can skip the proofs and go
straight for the recipes ;-)
I happen to have written sqrt functions when I worked on an XFmode /
TFmode fp-bit.c . ( The project got stuck for lack of priority. )
I'll send it to you in private email.
^ permalink raw reply [flat|nested] 264+ messages in thread
[parent not found: < 199903011630.QAA00110@phal.cygnus.co.uk >]
* Re: Bug in libm or libstdc++.
[not found] ` < 199903011630.QAA00110@phal.cygnus.co.uk >
@ 1999-03-02 8:04 ` Paul Derbyshire
[not found] ` < 3.0.6.32.19990302110405.00945870@pop.globalserve.net >
1999-03-31 23:46 ` Paul Derbyshire
0 siblings, 2 replies; 264+ messages in thread
From: Paul Derbyshire @ 1999-03-02 8:04 UTC (permalink / raw)
To: egcs
At 04:30 PM 3/1/99 +0000, you wrote:
>When you want to use a Polynom approximation, you should rather use a
>Tschebyscheff polynom.
Perhaps.
>Look it up in a mathematical enceclopedia.
Impossible, since I don't have the URL for any, and a Web search turned up
dry. (Again.)
Of course, printed, expensive ones are not a viable alternative, since I
have insufficient funds, no access to any vendor of such a product, and
moreover no information about how I would locate such a vendor given that I
did have the access and the three-figure amount of spare cash. Also, egcs
is a free software product run on an open development model, and so it is
not possible for them to require/expect a contributor to obtain expensive
items in order to contribute, without thereby violating their own charter.
>If you just want to get something working, you can skip the proofs and go
>straight for the recipes ;-)
Of course.
>I happen to have written sqrt functions when I worked on an XFmode /
>TFmode fp-bit.c . ( The project got stuck for lack of priority. )
>I'll send it to you in private email.
A sqrt can be implemented quickly with Newton's method, converging in
O(log_2 # binary digits in mantissa) starting from a suitable guess. This
is O(log n)... I doubt it can be bettered.
It's the trig, exponentials, and especially the logarithms that are the
nontrivial ones. :-)
--
.*. "Clouds are not spheres, mountains are not cones, coastlines are not
-() < circles, and bark is not smooth, nor does lightning travel in a
`*' straight line." -------------------------------------------------
-- B. Mandelbrot | http://surf.to/pgd.net
_____________________ ____|________ Paul Derbyshire pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|
^ permalink raw reply [flat|nested] 264+ messages in thread
[parent not found: < 3.0.6.32.19990302110405.00945870@pop.globalserve.net >]
* Re: Bug in libm or libstdc++.
[not found] ` < 3.0.6.32.19990302110405.00945870@pop.globalserve.net >
@ 1999-03-02 8:38 ` Joern Rennecke
1999-03-31 23:46 ` Joern Rennecke
0 siblings, 1 reply; 264+ messages in thread
From: Joern Rennecke @ 1999-03-02 8:38 UTC (permalink / raw)
To: Paul Derbyshire; +Cc: egcs
> Impossible, since I don't have the URL for any, and a Web search turned up
> dry. (Again.)
> Of course, printed, expensive ones are not a viable alternative, since I
> have insufficient funds, no access to any vendor of such a product, and
> moreover no information about how I would locate such a vendor given that I
> did have the access and the three-figure amount of spare cash. Also, egcs
> is a free software product run on an open development model, and so it is
> not possible for them to require/expect a contributor to obtain expensive
> items in order to contribute, without thereby violating their own charter.
Oh, I bought one for a sum that, expresed in US dollars, would be one-figure.
But never mind, you can go to one of these old-fashioned places called
'public libraries' or 'university libraries'.
> A sqrt can be implemented quickly with Newton's method, converging in
> O(log_2 # binary digits in mantissa) starting from a suitable guess. This
> is O(log n)... I doubt it can be bettered.
You have to keep in mind that multiplication itself is O(n^1.6). Moreover,
XFmode and TFmode can be expressed in a small number of 32 / 64 bit values,
so you have a lot of discretization noise in the actual precision - runtime
function. And sqrt is supposed to be rounded EXACTLY for IEEE, i.e. for
round to nearest, you should return that floating point value that most
accurately describes the actual square root.
> It's the trig, exponentials, and especially the logarithms that are the
> nontrivial ones. :-)
For these functions, the rounding requirements ar a lot more relaxed.
^ permalink raw reply [flat|nested] 264+ messages in thread
* Re: Bug in libm or libstdc++.
1999-03-02 8:38 ` Joern Rennecke
@ 1999-03-31 23:46 ` Joern Rennecke
0 siblings, 0 replies; 264+ messages in thread
From: Joern Rennecke @ 1999-03-31 23:46 UTC (permalink / raw)
To: Paul Derbyshire; +Cc: egcs
> Impossible, since I don't have the URL for any, and a Web search turned up
> dry. (Again.)
> Of course, printed, expensive ones are not a viable alternative, since I
> have insufficient funds, no access to any vendor of such a product, and
> moreover no information about how I would locate such a vendor given that I
> did have the access and the three-figure amount of spare cash. Also, egcs
> is a free software product run on an open development model, and so it is
> not possible for them to require/expect a contributor to obtain expensive
> items in order to contribute, without thereby violating their own charter.
Oh, I bought one for a sum that, expresed in US dollars, would be one-figure.
But never mind, you can go to one of these old-fashioned places called
'public libraries' or 'university libraries'.
> A sqrt can be implemented quickly with Newton's method, converging in
> O(log_2 # binary digits in mantissa) starting from a suitable guess. This
> is O(log n)... I doubt it can be bettered.
You have to keep in mind that multiplication itself is O(n^1.6). Moreover,
XFmode and TFmode can be expressed in a small number of 32 / 64 bit values,
so you have a lot of discretization noise in the actual precision - runtime
function. And sqrt is supposed to be rounded EXACTLY for IEEE, i.e. for
round to nearest, you should return that floating point value that most
accurately describes the actual square root.
> It's the trig, exponentials, and especially the logarithms that are the
> nontrivial ones. :-)
For these functions, the rounding requirements ar a lot more relaxed.
^ permalink raw reply [flat|nested] 264+ messages in thread
* Re: Bug in libm or libstdc++.
1999-03-02 8:04 ` Paul Derbyshire
[not found] ` < 3.0.6.32.19990302110405.00945870@pop.globalserve.net >
@ 1999-03-31 23:46 ` Paul Derbyshire
1 sibling, 0 replies; 264+ messages in thread
From: Paul Derbyshire @ 1999-03-31 23:46 UTC (permalink / raw)
To: egcs
At 04:30 PM 3/1/99 +0000, you wrote:
>When you want to use a Polynom approximation, you should rather use a
>Tschebyscheff polynom.
Perhaps.
>Look it up in a mathematical enceclopedia.
Impossible, since I don't have the URL for any, and a Web search turned up
dry. (Again.)
Of course, printed, expensive ones are not a viable alternative, since I
have insufficient funds, no access to any vendor of such a product, and
moreover no information about how I would locate such a vendor given that I
did have the access and the three-figure amount of spare cash. Also, egcs
is a free software product run on an open development model, and so it is
not possible for them to require/expect a contributor to obtain expensive
items in order to contribute, without thereby violating their own charter.
>If you just want to get something working, you can skip the proofs and go
>straight for the recipes ;-)
Of course.
>I happen to have written sqrt functions when I worked on an XFmode /
>TFmode fp-bit.c . ( The project got stuck for lack of priority. )
>I'll send it to you in private email.
A sqrt can be implemented quickly with Newton's method, converging in
O(log_2 # binary digits in mantissa) starting from a suitable guess. This
is O(log n)... I doubt it can be bettered.
It's the trig, exponentials, and especially the logarithms that are the
nontrivial ones. :-)
--
.*. "Clouds are not spheres, mountains are not cones, coastlines are not
-() < circles, and bark is not smooth, nor does lightning travel in a
`*' straight line." -------------------------------------------------
-- B. Mandelbrot | http://surf.to/pgd.net
_____________________ ____|________ Paul Derbyshire pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|
^ permalink raw reply [flat|nested] 264+ messages in thread
* Re: Bug in libm or libstdc++.
1999-03-01 8:30 ` Joern Rennecke
[not found] ` < 199903011630.QAA00110@phal.cygnus.co.uk >
@ 1999-03-31 23:46 ` Joern Rennecke
1 sibling, 0 replies; 264+ messages in thread
From: Joern Rennecke @ 1999-03-31 23:46 UTC (permalink / raw)
To: Paul Derbyshire; +Cc: egcs
> I may be mathematically inclined but I have none of the
> numerical-computation background necessary to know how to implement these
> things in an optimized way. Best I could probably do is a slowly converging
> Taylor series for these things. You ened a volunteer with a bit more
> knowledge in techniques of rapid numerical computation of trig functions.
When you want to use a Polynom approximation, you should rather use a
Tschebyscheff polynom. Look it up in a mathematical enceclopedia.
If you just want to get something working, you can skip the proofs and go
straight for the recipes ;-)
I happen to have written sqrt functions when I worked on an XFmode /
TFmode fp-bit.c . ( The project got stuck for lack of priority. )
I'll send it to you in private email.
^ permalink raw reply [flat|nested] 264+ messages in thread
[parent not found: <Pine.SUN.3.91.990228142826.5950V-100000@is>]
* Re: Bug in libm or libstdc++.
[not found] ` <Pine.SUN.3.91.990228142826.5950V-100000@is>
@ 1999-02-28 4:57 ` Paul Derbyshire
1999-02-28 22:53 ` Paul Derbyshire
0 siblings, 1 reply; 264+ messages in thread
From: Paul Derbyshire @ 1999-02-28 4:57 UTC (permalink / raw)
To: egcs, djgpp
At 02:28 PM 2/28/99 +0200, you wrote:
>
>On Fri, 26 Feb 1999, Paul Derbyshire wrote:
>
>> You're wrong, I'm right. Long double versions of atan and friends ARE
>> demanded by the standard.
>Which standard is that?
The ISO C++ standard. The C++ compiling environment is what was under
discussion.
>libm.a which comes with DJGPP v2.02 is not a C++
>library, it's a C library, and AFAIK it conforms to current C
>standards.
Then it must be libstdc++ that is supposed to overload those functions for
floats and long doubles. As the subject says, the bug was in one of those
libraries, and your clarification has narrowed it down to libstdc++.
--
.*. "Clouds are not spheres, mountains are not cones, coastlines are not
-() < circles, and bark is not smooth, nor does lightning travel in a
`*' straight line." -------------------------------------------------
-- B. Mandelbrot | http://surf.to/pgd.net
_____________________ ____|________ Paul Derbyshire pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|
^ permalink raw reply [flat|nested] 264+ messages in thread
* Re: Bug in libm or libstdc++.
1999-02-28 4:57 ` Paul Derbyshire
@ 1999-02-28 22:53 ` Paul Derbyshire
0 siblings, 0 replies; 264+ messages in thread
From: Paul Derbyshire @ 1999-02-28 22:53 UTC (permalink / raw)
To: egcs, djgpp
At 02:28 PM 2/28/99 +0200, you wrote:
>
>On Fri, 26 Feb 1999, Paul Derbyshire wrote:
>
>> You're wrong, I'm right. Long double versions of atan and friends ARE
>> demanded by the standard.
>Which standard is that?
The ISO C++ standard. The C++ compiling environment is what was under
discussion.
>libm.a which comes with DJGPP v2.02 is not a C++
>library, it's a C library, and AFAIK it conforms to current C
>standards.
Then it must be libstdc++ that is supposed to overload those functions for
floats and long doubles. As the subject says, the bug was in one of those
libraries, and your clarification has narrowed it down to libstdc++.
--
.*. "Clouds are not spheres, mountains are not cones, coastlines are not
-() < circles, and bark is not smooth, nor does lightning travel in a
`*' straight line." -------------------------------------------------
-- B. Mandelbrot | http://surf.to/pgd.net
_____________________ ____|________ Paul Derbyshire pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|
^ permalink raw reply [flat|nested] 264+ messages in thread
* Re: Bug in libm or libstdc++.
1999-02-25 22:20 ` Paul Derbyshire
[not found] ` <199902261635.LAA23787@wagner.Princeton.EDU>
[not found] ` <Pine.SUN.3.91.990228142826.5950V-100000@is>
@ 1999-02-28 22:53 ` Paul Derbyshire
2 siblings, 0 replies; 264+ messages in thread
From: Paul Derbyshire @ 1999-02-28 22:53 UTC (permalink / raw)
To: egcs, djgpp
> Uhhh... if you're referring to page 660 (section 22.3)
> it most certainly does not make any such guarantee with
> regards to -long double- datatypes.
S22.3, page 661: "double atan (double) ..... In addition, <cmath> and
<math.h> supply these functions for float and long double arguments."
You're wrong, I'm right. Long double versions of atan and friends ARE
demanded by the standard. I would like to see them very soon so that I may
use them (the long double versions anyways) when I want that bit of extra
precision.......
> at least on my box (sparc solaris), libm is vendor provided.
Not on an IBM PC clone, where it comes with the DJGPP/Cygwin/whatever
development environment you install. I installed the DJGPP/EGCS development
environment and got a broken libm.
> gnu/include/g++/cmath -does- make reference to the math
> functions that use long doubles for arguments, but I don't
> think any library on my box actually supports them.
Then those libraries are broken and not conformant. I suggest you complain
to the vendor. You may also want to ask the bookstore where you got your
copy of Stroustrup for an exchange or a refund; I sure would have if my
copy had turned out to have pp. 661-662 torn out or missing.
Anyways, since these are function overloads in C++, I would expect the long
double and float versions to be in libstdc++, not libm. And libstdc++ comes
with gcc/egcs rather than being vendor supplied, on all platforms. If the
egcs libstdc++ is lacking long double overloads for atan and the like, then
this is a bug in egcs.
--
.*. "Clouds are not spheres, mountains are not cones, coastlines are not
-() < circles, and bark is not smooth, nor does lightning travel in a
`*' straight line." -------------------------------------------------
-- B. Mandelbrot | http://surf.to/pgd.net
_____________________ ____|________ Paul Derbyshire pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|
^ permalink raw reply [flat|nested] 264+ messages in thread
* Re: Bug in libm or libstdc++.
1999-02-24 15:42 ` Bob McWhirter
[not found] ` < Pine.LNX.3.96.990224183714.7438r-100000@exeter.exeter.org >
@ 1999-02-28 22:53 ` Bob McWhirter
1 sibling, 0 replies; 264+ messages in thread
From: Bob McWhirter @ 1999-02-28 22:53 UTC (permalink / raw)
To: egcs
On Mon, 22 Feb 1999, Paul Derbyshire wrote:
> C:\PGD\C++\omega\ofc>gcc ntst.cc -o ntst.exe -Wall -lm -lstdcxx
> c:/djgpp/tmp/cc5PNfut.o(.text+0x51):ntst.cc: undefined reference to
> `atan(long double)'
[ snip ]
> What the hell?
Is that -really- necessary? Pipe down, already.
> Stroustrup 3rd Ed definitely informs me that long double overloads for
> these and other functions are supposed to be in either libm or libstdc++.
Uhhh... if you're referring to page 660 (section 22.3)
it most certainly does not make any such guarantee with
regards to -long double- datatypes.
> Using egcs 1.1.1 and the libm and libstdc++ that came with it.
at least on my box (sparc solaris), libm is vendor provided.
gnu/include/g++/cmath -does- make reference to the math
functions that use long doubles for arguments, but I don't
think any library on my box actually supports them.
Possibly there for platforms that do? There for platforms
that typedef a long double to be the same as a double?
(nm'ing vendor's libm and stdc++ does not reveal math
functions taking long doubles, but possibly some other
lib I'm ignoring? I did find math functions take
complex objects as arguments though.)
-Bob
^ permalink raw reply [flat|nested] 264+ messages in thread
* Bug in libm or libstdc++.
1999-02-24 15:13 Bug in libm or libstdc++ Paul Derbyshire
[not found] ` < 3.0.6.32.19990222090333.00847df0@pop.globalserve.net >
@ 1999-02-28 22:53 ` Paul Derbyshire
1 sibling, 0 replies; 264+ messages in thread
From: Paul Derbyshire @ 1999-02-28 22:53 UTC (permalink / raw)
To: egcs, egcs-bugs
C:\PGD\C++\omega\ofc>gcc ntst.cc -o ntst.exe -Wall -lm -lstdcxx
c:/djgpp/tmp/cc5PNfut.o(.text+0x51):ntst.cc: undefined reference to
`atan(long double)'
c:/djgpp/tmp/cc5PNfut.o(.text+0xa8):ntst.cc: undefined reference to
`exp(long double)'
c:/djgpp/tmp/cc5PNfut.o(.text+0xef):ntst.cc: undefined reference to
`log(long double)'
c:/djgpp/tmp/cc5PNfut.o(.text+0x136):ntst.cc: undefined reference to
`log(long double)'
c:/djgpp/tmp/cc5PNfut.o(.text+0x17d):ntst.cc: undefined reference to
`sqrt(long double)'
What the hell?
Stroustrup 3rd Ed definitely informs me that long double overloads for
these and other functions are supposed to be in either libm or libstdc++.
Using egcs 1.1.1 and the libm and libstdc++ that came with it.
--
.*. "Clouds are not spheres, mountains are not cones, coastlines are not
-() < circles, and bark is not smooth, nor does lightning travel in a
`*' straight line." -------------------------------------------------
-- B. Mandelbrot | http://surf.to/pgd.net
_____________________ ____|________ Paul Derbyshire pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|
^ permalink raw reply [flat|nested] 264+ messages in thread
* [Meta] Enough of the "egcs.cygnus.com" already!
@ 1999-01-31 22:09 Paul Derbyshire
1999-01-31 22:14 ` CaT
` (4 more replies)
0 siblings, 5 replies; 264+ messages in thread
From: Paul Derbyshire @ 1999-01-31 22:09 UTC (permalink / raw)
To: egcs
Grr. I subscribe to the EGCS mailing list at egcs.cygnus.com and set a mail
filter to filter anything with a To: or Cc: containing
"egcs@egcs.cygnus.com" into an 'egcs' folder, figuring that it isn't likely
that anyone would BCc: to the list and confound the filter.
Trouble is, it seems you can post to the list using just "egcs@cygnus.com",
since I keep finding a shitload of egcs mail in my main Inbox with this on
the Cc: line!
Argh.
--
.*. "Clouds are not spheres, mountains are not cones, coastlines are not
-() < circles, and bark is not smooth, nor does lightning travel in a
`*' straight line." -------------------------------------------------
-- B. Mandelbrot | http://surf.to/pgd.net
_____________________ ____|________ Paul Derbyshire pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|
^ permalink raw reply [flat|nested] 264+ messages in thread
* Re: [Meta] Enough of the "egcs.cygnus.com" already!
1999-01-31 22:09 [Meta] Enough of the "egcs.cygnus.com" already! Paul Derbyshire
@ 1999-01-31 22:14 ` CaT
1999-01-31 22:24 ` Bob McWhirter
1999-01-31 23:12 ` Ken Raeburn
` (3 subsequent siblings)
4 siblings, 1 reply; 264+ messages in thread
From: CaT @ 1999-01-31 22:14 UTC (permalink / raw)
To: Paul Derbyshire; +Cc: egcs
Paul Derbyshire wrote the following:
>
> Grr. I subscribe to the EGCS mailing list at egcs.cygnus.com and set a mail
> filter to filter anything with a To: or Cc: containing
> "egcs@egcs.cygnus.com" into an 'egcs' folder, figuring that it isn't likely
> that anyone would BCc: to the list and confound the filter.
>
> Trouble is, it seems you can post to the list using just "egcs@cygnus.com",
> since I keep finding a shitload of egcs mail in my main Inbox with this on
> the Cc: line!
I filter on the From_ line like this:
/^From (egcs(-|-testresults-|-announce-)return-[0-9]+-cat\=zip\.com\.au\@egcs\.cygnus\.com|owner-egcs-bugs\@cygnus\.com)/
That catches all the egcs mail for me just fine (it's from a list perl script
I've written to postprocess my mailbox. don't ask why. :).
--
CaT (cat@zip.net.au) URL: http://www.zip.com.au/dev/null
There was farting in the air that night,
It lit so bright,
Fernando...
^ permalink raw reply [flat|nested] 264+ messages in thread
* Re: [Meta] Enough of the "egcs.cygnus.com" already!
1999-01-31 22:14 ` CaT
@ 1999-01-31 22:24 ` Bob McWhirter
1999-01-31 22:50 ` Paul Derbyshire
0 siblings, 1 reply; 264+ messages in thread
From: Bob McWhirter @ 1999-01-31 22:24 UTC (permalink / raw)
To: CaT; +Cc: Paul Derbyshire, egcs
> > Trouble is, it seems you can post to the list using just "egcs@cygnus.com",
> > since I keep finding a shitload of egcs mail in my main Inbox with this on
> > the Cc: line!
>
> I filter on the From_ line like this:
>
> /^From (egcs(-|-testresults-|-announce-)return-[0-9]+-cat\=zip\.com\.au\@egcs\.cygnus\.com|owner-egcs-bugs\@cygnus\.com)/
Pardon the 'me too!', but I've found this regexp (from .procmailrc)
to work rather well:
^Sender:.*owner-egcs
It's short, and seems to work regardless of the address used to
send to the list itself.
-Bob
^ permalink raw reply [flat|nested] 264+ messages in thread
* Re: [Meta] Enough of the "egcs.cygnus.com" already!
1999-01-31 22:24 ` Bob McWhirter
@ 1999-01-31 22:50 ` Paul Derbyshire
1999-02-01 2:01 ` Franz Sirl
0 siblings, 1 reply; 264+ messages in thread
From: Paul Derbyshire @ 1999-01-31 22:50 UTC (permalink / raw)
To: egcs
>Pardon the 'me too!', but I've found this regexp (from .procmailrc)
>to work rather well:
>
> ^Sender:.*owner-egcs
Mine doesn't come with a Sender: header...there's an X-Sender: header but
it's the message originator again and not owner-egcs.
--
.*. "Clouds are not spheres, mountains are not cones, coastlines are not
-() < circles, and bark is not smooth, nor does lightning travel in a
`*' straight line." -------------------------------------------------
-- B. Mandelbrot | http://surf.to/pgd.net
_____________________ ____|________ Paul Derbyshire pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|
^ permalink raw reply [flat|nested] 264+ messages in thread
* Re: [Meta] Enough of the "egcs.cygnus.com" already!
1999-01-31 22:50 ` Paul Derbyshire
@ 1999-02-01 2:01 ` Franz Sirl
[not found] ` < 4.1.19990201105045.054320e0@mail.lauterbach.com >
1999-02-28 22:53 ` Franz Sirl
0 siblings, 2 replies; 264+ messages in thread
From: Franz Sirl @ 1999-02-01 2:01 UTC (permalink / raw)
To: Paul Derbyshire; +Cc: egcs
At 07:50 01.02.99 , Paul Derbyshire wrote:
>>Pardon the 'me too!', but I've found this regexp (from .procmailrc)
>>to work rather well:
>>
>> ^Sender:.*owner-egcs
>
>Mine doesn't come with a Sender: header...there's an X-Sender: header but
>it's the message originator again and not owner-egcs.
Sure it has a Sender: header. Just enable the "BlahBlah" button of the
message in Eudora and you will see it.
So you can either filter on:
"Sender:" contains "owner-egcs"
or
"Delivered-To:" contains "egcs@egcs.cygnus.com"
in Eudora. You'll see that neither one one of these headers is
preconfigured in Eudora's header popup list, but you can simply overtype
one of the preconfigured headers.
Franz.
^ permalink raw reply [flat|nested] 264+ messages in thread
[parent not found: < 4.1.19990201105045.054320e0@mail.lauterbach.com >]
* Re: [Meta] Enough of the "egcs.cygnus.com" already!
[not found] ` < 4.1.19990201105045.054320e0@mail.lauterbach.com >
@ 1999-02-01 15:53 ` Paul Derbyshire
1999-02-28 22:53 ` Paul Derbyshire
1999-02-28 22:53 ` Rask Ingemann Lambertsen
0 siblings, 2 replies; 264+ messages in thread
From: Paul Derbyshire @ 1999-02-01 15:53 UTC (permalink / raw)
To: egcs
At 11:00 AM 2/1/99 +0100, you wrote:
>Sure it has a Sender: header. Just enable the "BlahBlah" button of the
>message in Eudora and you will see it.
I know about that button, dammit, and trust me it's not there. Neither is
the "From " header. I looked for both of those in the very message I'm
replying to, and saw neither. Tehre was an X-Sender: but there was no
mention of owner-egcs in it.
--
.*. "Clouds are not spheres, mountains are not cones, coastlines are not
-() < circles, and bark is not smooth, nor does lightning travel in a
`*' straight line." -------------------------------------------------
-- B. Mandelbrot | http://surf.to/pgd.net
_____________________ ____|________ Paul Derbyshire pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|
^ permalink raw reply [flat|nested] 264+ messages in thread
* Re: [Meta] Enough of the "egcs.cygnus.com" already!
1999-02-01 15:53 ` Paul Derbyshire
@ 1999-02-28 22:53 ` Paul Derbyshire
1999-02-28 22:53 ` Rask Ingemann Lambertsen
1 sibling, 0 replies; 264+ messages in thread
From: Paul Derbyshire @ 1999-02-28 22:53 UTC (permalink / raw)
To: egcs
At 11:00 AM 2/1/99 +0100, you wrote:
>Sure it has a Sender: header. Just enable the "BlahBlah" button of the
>message in Eudora and you will see it.
I know about that button, dammit, and trust me it's not there. Neither is
the "From " header. I looked for both of those in the very message I'm
replying to, and saw neither. Tehre was an X-Sender: but there was no
mention of owner-egcs in it.
--
.*. "Clouds are not spheres, mountains are not cones, coastlines are not
-() < circles, and bark is not smooth, nor does lightning travel in a
`*' straight line." -------------------------------------------------
-- B. Mandelbrot | http://surf.to/pgd.net
_____________________ ____|________ Paul Derbyshire pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|
^ permalink raw reply [flat|nested] 264+ messages in thread
* Re: [Meta] Enough of the "egcs.cygnus.com" already!
1999-02-01 15:53 ` Paul Derbyshire
1999-02-28 22:53 ` Paul Derbyshire
@ 1999-02-28 22:53 ` Rask Ingemann Lambertsen
1 sibling, 0 replies; 264+ messages in thread
From: Rask Ingemann Lambertsen @ 1999-02-28 22:53 UTC (permalink / raw)
To: EGCS mailing list
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1377 bytes --]
Den 02-Feb-99 00:52:33 skrev Paul Derbyshire følgende om "Re: [Meta] Enough of the "egcs.cygnus.com" already!":
> At 11:00 AM 2/1/99 +0100, you wrote:
>>Sure it has a Sender: header. Just enable the "BlahBlah" button of the
>>message in Eudora and you will see it.
> I know about that button, dammit, and trust me it's not there. Neither is
> the "From " header. I looked for both of those in the very message I'm
> replying to, and saw neither. Tehre was an X-Sender: but there was no
> mention of owner-egcs in it.
IIRC, RFC1123 requires Internet mail systems to preserve the envelope
sender address. This is what the "From " header is normally used for. Perhaps
there is a Return-Path: header instead?
Btw, my copies of the messages all have the Sender: header.
Regards,
/¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯T¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯\
| Rask Ingemann Lambertsen | E-mail: mailto:rask@kampsax.k-net.dk |
| Registered Phase5 developer | WWW: http://www.gbar.dtu.dk/~c948374/ |
| A4000, 775 kkeys/s (RC5-64) | "ThrustMe" on XPilot, ARCnet and IRC |
|To err is human. To forgive is beyond the scope of the Operating System.|
^ permalink raw reply [flat|nested] 264+ messages in thread
* Re: [Meta] Enough of the "egcs.cygnus.com" already!
1999-02-01 2:01 ` Franz Sirl
[not found] ` < 4.1.19990201105045.054320e0@mail.lauterbach.com >
@ 1999-02-28 22:53 ` Franz Sirl
1 sibling, 0 replies; 264+ messages in thread
From: Franz Sirl @ 1999-02-28 22:53 UTC (permalink / raw)
To: Paul Derbyshire; +Cc: egcs
At 07:50 01.02.99 , Paul Derbyshire wrote:
>>Pardon the 'me too!', but I've found this regexp (from .procmailrc)
>>to work rather well:
>>
>> ^Sender:.*owner-egcs
>
>Mine doesn't come with a Sender: header...there's an X-Sender: header but
>it's the message originator again and not owner-egcs.
Sure it has a Sender: header. Just enable the "BlahBlah" button of the
message in Eudora and you will see it.
So you can either filter on:
"Sender:" contains "owner-egcs"
or
"Delivered-To:" contains "egcs@egcs.cygnus.com"
in Eudora. You'll see that neither one one of these headers is
preconfigured in Eudora's header popup list, but you can simply overtype
one of the preconfigured headers.
Franz.
^ permalink raw reply [flat|nested] 264+ messages in thread
* Re: [Meta] Enough of the "egcs.cygnus.com" already!
1999-01-31 22:09 [Meta] Enough of the "egcs.cygnus.com" already! Paul Derbyshire
1999-01-31 22:14 ` CaT
@ 1999-01-31 23:12 ` Ken Raeburn
1999-02-01 7:13 ` Jeffrey A Law
` (2 subsequent siblings)
4 siblings, 0 replies; 264+ messages in thread
From: Ken Raeburn @ 1999-01-31 23:12 UTC (permalink / raw)
To: Paul Derbyshire; +Cc: egcs
Paul Derbyshire <pderbysh@usa.net> writes:
> Trouble is, it seems you can post to the list using just "egcs@cygnus.com",
It's not unheard of for a site to have a local alias that points to a
remote mailing list, especially if, say, a news/mail gateway is
situated at that machine (so that "posts" may automatically be routed
by email to that machine, where some spam filter might be installed),
or the machine used to host the list before it moved (so that people
may have the old address saved away somewhere, and old versions of the
software may refer to it in documentation). The latter is the case
here.
Getting annoyed at such sites isn't going to do you much good. Find
some way to match on the alternate addresses; they're usually few in
number.
Me, I look for something like
egcs@[-a-zA-Z0-9.]*cygnus.com
in the to or cc lines. (The long list of characters is to avoid
matching whitespace and thus span multiple addresses.) But I see the
incoming mail headers (at my site) currently also have:
Mailing-List: contact egcs-help@egcs.cygnus.com; run by ezmlm
Sender: owner-egcs@egcs.cygnus.com
Delivered-To: mailing list egcs@egcs.cygnus.com
that you could look for.
And the envelope-sender address (also known as a "From " header --
that's "from" with a trailing space and *NO* colon -- in the
UNIX/sendmail world) also indicates that it's from the egcs list, but
I don't know if your mailer will make that info available to you.
Ken
^ permalink raw reply [flat|nested] 264+ messages in thread
* Re: [Meta] Enough of the "egcs.cygnus.com" already!
1999-01-31 22:09 [Meta] Enough of the "egcs.cygnus.com" already! Paul Derbyshire
1999-01-31 22:14 ` CaT
1999-01-31 23:12 ` Ken Raeburn
@ 1999-02-01 7:13 ` Jeffrey A Law
1999-02-01 7:27 ` Alexandre Oliva
1999-02-28 22:53 ` Jeffrey A Law
[not found] ` <19990201200631.A227@tardis.ed.ac.uk>
1999-02-03 12:05 ` Rask Ingemann Lambertsen
4 siblings, 2 replies; 264+ messages in thread
From: Jeffrey A Law @ 1999-02-01 7:13 UTC (permalink / raw)
To: Paul Derbyshire; +Cc: egcs
In message <3.0.6.32.19990201010831.00880950@pop.netaddress.com>you write:
> Grr. I subscribe to the EGCS mailing list at egcs.cygnus.com and set a mail
> filter to filter anything with a To: or Cc: containing
> "egcs@egcs.cygnus.com" into an 'egcs' folder, figuring that it isn't likely
> that anyone would BCc: to the list and confound the filter.
>
> Trouble is, it seems you can post to the list using just "egcs@cygnus.com",
> since I keep finding a shitload of egcs mail in my main Inbox with this on
> the Cc: line!
The @cygnus.com relays are scheduled to go away on or around March 1, 1999.
jeff
^ permalink raw reply [flat|nested] 264+ messages in thread
* Re: [Meta] Enough of the "egcs.cygnus.com" already!
1999-02-01 7:13 ` Jeffrey A Law
@ 1999-02-01 7:27 ` Alexandre Oliva
[not found] ` < or4sp6b12f.fsf@araguaia.dcc.unicamp.br >
1999-02-28 22:53 ` Alexandre Oliva
1999-02-28 22:53 ` Jeffrey A Law
1 sibling, 2 replies; 264+ messages in thread
From: Alexandre Oliva @ 1999-02-01 7:27 UTC (permalink / raw)
To: law; +Cc: Paul Derbyshire, egcs
On Feb 1, 1999, Jeffrey A Law <law@upchuck.cygnus.com> wrote:
> The @cygnus.com relays are scheduled to go away on or around March 1, 1999.
What about the following error message, printed by egcs 1.1.1?
bug.c:3: Please submit a full bug report to `egcs-bugs@cygnus.com'.
--
Alexandre Oliva http://www.dcc.unicamp.br/~oliva aoliva@{acm.org}
oliva@{dcc.unicamp.br,gnu.org,egcs.cygnus.com,samba.org}
Universidade Estadual de Campinas, SP, Brasil
^ permalink raw reply [flat|nested] 264+ messages in thread
[parent not found: < or4sp6b12f.fsf@araguaia.dcc.unicamp.br >]
* Re: [Meta] Enough of the "egcs.cygnus.com" already!
[not found] ` < or4sp6b12f.fsf@araguaia.dcc.unicamp.br >
@ 1999-02-01 7:30 ` Jeffrey A Law
1999-02-01 7:35 ` Alexandre Oliva
` (2 more replies)
1999-02-13 10:47 ` Jeffrey A Law
1 sibling, 3 replies; 264+ messages in thread
From: Jeffrey A Law @ 1999-02-01 7:30 UTC (permalink / raw)
To: Alexandre Oliva; +Cc: Paul Derbyshire, egcs
In message < or4sp6b12f.fsf@araguaia.dcc.unicamp.br >you write:
> On Feb 1, 1999, Jeffrey A Law <law@upchuck.cygnus.com> wrote:
>
> > The @cygnus.com relays are scheduled to go away on or around March 1, 199
> 9.
>
> What about the following error message, printed by egcs 1.1.1?
>
> bug.c:3: Please submit a full bug report to `egcs-bugs@cygnus.com'.
Easily fixed ;-)
jeff
^ permalink raw reply [flat|nested] 264+ messages in thread
* Re: [Meta] Enough of the "egcs.cygnus.com" already!
1999-02-01 7:30 ` Jeffrey A Law
@ 1999-02-01 7:35 ` Alexandre Oliva
[not found] ` < or1zkab0ou.fsf@araguaia.dcc.unicamp.br >
1999-02-28 22:53 ` Alexandre Oliva
1999-02-01 7:59 ` Ken Raeburn
1999-02-28 22:53 ` Jeffrey A Law
2 siblings, 2 replies; 264+ messages in thread
From: Alexandre Oliva @ 1999-02-01 7:35 UTC (permalink / raw)
To: law; +Cc: Paul Derbyshire, egcs
On Feb 1, 1999, Jeffrey A Law <law@hurl.cygnus.com> wrote:
> In message < or4sp6b12f.fsf@araguaia.dcc.unicamp.br >you write:
>> On Feb 1, 1999, Jeffrey A Law <law@upchuck.cygnus.com> wrote:
>> > The @cygnus.com relays are scheduled to go away on or around March 1, 199
>> 9.
>> What about the following error message, printed by egcs 1.1.1?
>> bug.c:3: Please submit a full bug report to `egcs-bugs@cygnus.com'.
> Easily fixed ;-)
No, I mean, we must keep at least egcs-bugs@cygnus.com as a valid
address, otherwise people that don't know about the change won't be
able to submit bug reports against egcs 1.1.1, that will probably
still be floating around for a long time :-(
Either the relay or an automatic reply saying ``the new e-mail address
for reporting egcs bugs is egcs-bugs@egcs.cygnus.com, please submit
your report again, sorry for the inconvenience''.
--
Alexandre Oliva http://www.dcc.unicamp.br/~oliva aoliva@{acm.org}
oliva@{dcc.unicamp.br,gnu.org,egcs.cygnus.com,samba.org}
Universidade Estadual de Campinas, SP, Brasil
^ permalink raw reply [flat|nested] 264+ messages in thread
[parent not found: < or1zkab0ou.fsf@araguaia.dcc.unicamp.br >]
* Re: [Meta] Enough of the "egcs.cygnus.com" already!
[not found] ` < or1zkab0ou.fsf@araguaia.dcc.unicamp.br >
@ 1999-02-01 7:50 ` Jeffrey A Law
[not found] ` < 3391.917883892@hurl.cygnus.com >
1999-02-28 22:53 ` Jeffrey A Law
1999-02-01 15:58 ` Paul Derbyshire
1 sibling, 2 replies; 264+ messages in thread
From: Jeffrey A Law @ 1999-02-01 7:50 UTC (permalink / raw)
To: Alexandre Oliva; +Cc: Paul Derbyshire, egcs
In message < or1zkab0ou.fsf@araguaia.dcc.unicamp.br >you write:
> No, I mean, we must keep at least egcs-bugs@cygnus.com as a valid
> address, otherwise people that don't know about the change won't be
> able to submit bug reports against egcs 1.1.1, that will probably
> still be floating around for a long time :-(
>
> Either the relay or an automatic reply saying ``the new e-mail address
> for reporting egcs bugs is egcs-bugs@egcs.cygnus.com, please submit
> your report again, sorry for the inconvenience''.
We'll probably have an auto-reply for all the old addresses.
And we'll be changing the address in that message RSN.
jeff
^ permalink raw reply [flat|nested] 264+ messages in thread
[parent not found: < 3391.917883892@hurl.cygnus.com >]
* Re: [Meta] Enough of the "egcs.cygnus.com" already!
[not found] ` < 3391.917883892@hurl.cygnus.com >
@ 1999-02-01 8:23 ` Joe Buck
[not found] ` < 199902011621.IAA00385@atrus.synopsys.com >
` (2 more replies)
0 siblings, 3 replies; 264+ messages in thread
From: Joe Buck @ 1999-02-01 8:23 UTC (permalink / raw)
To: law; +Cc: oliva, pderbysh, egcs
> > Either the relay or an automatic reply saying ``the new e-mail address
> > for reporting egcs bugs is egcs-bugs@egcs.cygnus.com, please submit
> > your report again, sorry for the inconvenience''.
> We'll probably have an auto-reply for all the old addresses.
Which won't reach the people who spam-protect their email address
when mailing to large mailing lists (or just out of habit).
We probably should archive the old messages at least for some transition
period.
^ permalink raw reply [flat|nested] 264+ messages in thread
[parent not found: < 199902011621.IAA00385@atrus.synopsys.com >]
* Re: [Meta] Enough of the "egcs.cygnus.com" already!
[not found] ` < 199902011621.IAA00385@atrus.synopsys.com >
@ 1999-02-01 8:24 ` Jeffrey A Law
1999-02-28 22:53 ` Jeffrey A Law
1999-02-01 16:03 ` Paul Derbyshire
1 sibling, 1 reply; 264+ messages in thread
From: Jeffrey A Law @ 1999-02-01 8:24 UTC (permalink / raw)
To: Joe Buck; +Cc: oliva, pderbysh, egcs
In message < 199902011621.IAA00385@atrus.synopsys.com >you write:
>
> > > Either the relay or an automatic reply saying ``the new e-mail addres
> s
> > > for reporting egcs bugs is egcs-bugs@egcs.cygnus.com, please submit
> > > your report again, sorry for the inconvenience''.
> > We'll probably have an auto-reply for all the old addresses.
>
> Which won't reach the people who spam-protect their email address
> when mailing to large mailing lists (or just out of habit).
Yea, but we don't care about them. I'll mean someone (sysadmin) will get a
lost of bounced messages, but that's someone else's problem :-)
> We probably should archive the old messages at least for some transition
> period.
We'll continue to have all the messages in archive form.
jeff
^ permalink raw reply [flat|nested] 264+ messages in thread
* Re: [Meta] Enough of the "egcs.cygnus.com" already!
1999-02-01 8:24 ` Jeffrey A Law
@ 1999-02-28 22:53 ` Jeffrey A Law
0 siblings, 0 replies; 264+ messages in thread
From: Jeffrey A Law @ 1999-02-28 22:53 UTC (permalink / raw)
To: Joe Buck; +Cc: oliva, pderbysh, egcs
In message < 199902011621.IAA00385@atrus.synopsys.com >you write:
>
> > > Either the relay or an automatic reply saying ``the new e-mail addres
> s
> > > for reporting egcs bugs is egcs-bugs@egcs.cygnus.com, please submit
> > > your report again, sorry for the inconvenience''.
> > We'll probably have an auto-reply for all the old addresses.
>
> Which won't reach the people who spam-protect their email address
> when mailing to large mailing lists (or just out of habit).
Yea, but we don't care about them. I'll mean someone (sysadmin) will get a
lost of bounced messages, but that's someone else's problem :-)
> We probably should archive the old messages at least for some transition
> period.
We'll continue to have all the messages in archive form.
jeff
^ permalink raw reply [flat|nested] 264+ messages in thread
* Re: [Meta] Enough of the "egcs.cygnus.com" already!
[not found] ` < 199902011621.IAA00385@atrus.synopsys.com >
1999-02-01 8:24 ` Jeffrey A Law
@ 1999-02-01 16:03 ` Paul Derbyshire
1999-02-28 22:53 ` Paul Derbyshire
1 sibling, 1 reply; 264+ messages in thread
From: Paul Derbyshire @ 1999-02-01 16:03 UTC (permalink / raw)
To: egcs
>Which won't reach the people who spam-protect their email address
>when mailing to large mailing lists (or just out of habit).
If you munge your reply-to when sending to mailing lists you deserve what
you get -- or fail to get. Any decent mailing list will kick off anyone who
posts spam to the list or is suspected of harvesting on it.
--
.*. "Clouds are not spheres, mountains are not cones, coastlines are not
-() < circles, and bark is not smooth, nor does lightning travel in a
`*' straight line." -------------------------------------------------
-- B. Mandelbrot | http://surf.to/pgd.net
_____________________ ____|________ Paul Derbyshire pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|
^ permalink raw reply [flat|nested] 264+ messages in thread
* Re: [Meta] Enough of the "egcs.cygnus.com" already!
1999-02-01 16:03 ` Paul Derbyshire
@ 1999-02-28 22:53 ` Paul Derbyshire
0 siblings, 0 replies; 264+ messages in thread
From: Paul Derbyshire @ 1999-02-28 22:53 UTC (permalink / raw)
To: egcs
>Which won't reach the people who spam-protect their email address
>when mailing to large mailing lists (or just out of habit).
If you munge your reply-to when sending to mailing lists you deserve what
you get -- or fail to get. Any decent mailing list will kick off anyone who
posts spam to the list or is suspected of harvesting on it.
--
.*. "Clouds are not spheres, mountains are not cones, coastlines are not
-() < circles, and bark is not smooth, nor does lightning travel in a
`*' straight line." -------------------------------------------------
-- B. Mandelbrot | http://surf.to/pgd.net
_____________________ ____|________ Paul Derbyshire pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|
^ permalink raw reply [flat|nested] 264+ messages in thread
* Re: [Meta] Enough of the "egcs.cygnus.com" already!
1999-02-01 8:23 ` Joe Buck
[not found] ` < 199902011621.IAA00385@atrus.synopsys.com >
@ 1999-02-28 22:53 ` postmaster
1999-02-28 22:53 ` Joe Buck
2 siblings, 0 replies; 264+ messages in thread
From: postmaster @ 1999-02-28 22:53 UTC (permalink / raw)
To: EGCS mailing list
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 943 bytes --]
Den 01-Feb-99 17:21:45 skrev Joe Buck følgende om "Re: [Meta] Enough of the "egcs.cygnus.com" already!":
>> We'll probably have an auto-reply for all the old addresses.
> Which won't reach the people who spam-protect their email address
> when mailing to large mailing lists (or just out of habit).
It will if they do it properly. ;-)
Regards,
/¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯T¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯\
| Rask Ingemann Lambertsen | postmaster@rask.nospam.kampsax.k-net.dk |
| Registered Phase5 developer | WWW: http://www.gbar.dtu.dk/~c948374/ |
| A4000, 775 kkeys/s (RC5-64) | "ThrustMe" on XPilot and EFnet IRC |
| Do artificial plants need artificial water? |
^ permalink raw reply [flat|nested] 264+ messages in thread
* Re: [Meta] Enough of the "egcs.cygnus.com" already!
1999-02-01 8:23 ` Joe Buck
[not found] ` < 199902011621.IAA00385@atrus.synopsys.com >
1999-02-28 22:53 ` postmaster
@ 1999-02-28 22:53 ` Joe Buck
2 siblings, 0 replies; 264+ messages in thread
From: Joe Buck @ 1999-02-28 22:53 UTC (permalink / raw)
To: law; +Cc: oliva, pderbysh, egcs
> > Either the relay or an automatic reply saying ``the new e-mail address
> > for reporting egcs bugs is egcs-bugs@egcs.cygnus.com, please submit
> > your report again, sorry for the inconvenience''.
> We'll probably have an auto-reply for all the old addresses.
Which won't reach the people who spam-protect their email address
when mailing to large mailing lists (or just out of habit).
We probably should archive the old messages at least for some transition
period.
^ permalink raw reply [flat|nested] 264+ messages in thread
* Re: [Meta] Enough of the "egcs.cygnus.com" already!
1999-02-01 7:50 ` Jeffrey A Law
[not found] ` < 3391.917883892@hurl.cygnus.com >
@ 1999-02-28 22:53 ` Jeffrey A Law
1 sibling, 0 replies; 264+ messages in thread
From: Jeffrey A Law @ 1999-02-28 22:53 UTC (permalink / raw)
To: Alexandre Oliva; +Cc: Paul Derbyshire, egcs
In message < or1zkab0ou.fsf@araguaia.dcc.unicamp.br >you write:
> No, I mean, we must keep at least egcs-bugs@cygnus.com as a valid
> address, otherwise people that don't know about the change won't be
> able to submit bug reports against egcs 1.1.1, that will probably
> still be floating around for a long time :-(
>
> Either the relay or an automatic reply saying ``the new e-mail address
> for reporting egcs bugs is egcs-bugs@egcs.cygnus.com, please submit
> your report again, sorry for the inconvenience''.
We'll probably have an auto-reply for all the old addresses.
And we'll be changing the address in that message RSN.
jeff
^ permalink raw reply [flat|nested] 264+ messages in thread
* Re: [Meta] Enough of the "egcs.cygnus.com" already!
[not found] ` < or1zkab0ou.fsf@araguaia.dcc.unicamp.br >
1999-02-01 7:50 ` Jeffrey A Law
@ 1999-02-01 15:58 ` Paul Derbyshire
1999-02-28 22:53 ` Paul Derbyshire
1 sibling, 1 reply; 264+ messages in thread
From: Paul Derbyshire @ 1999-02-01 15:58 UTC (permalink / raw)
To: egcs
At 01:31 PM 2/1/99 -0200, you wrote:
>Either the relay or an automatic reply saying ``the new e-mail address
>for reporting egcs bugs is egcs-bugs@egcs.cygnus.com, please submit
>your report again, sorry for the inconvenience''.
MAKE THAT THING QUOTE BACK THE ORIGINAL MESSAGE!! I've seen a few systems
where outgoing mail is either not automatically saved or isn't even saved
at all, and people using such systems will experience "please submit your
report again" as meaning "Please struggle to remember all that you wrote
and then rewrite it slowly and painstakingly from scratch, and at the end,
remember to use the right address!". This is why mailer_daemon mail quotes
back the bounced message too.
Best would be to have it send the message described, quote the oiginal
below it, and have a Reply-To: of egcs-bugs@egcs.com. Then all the guy has
to do who sees it is
1. Note "hmm, the damned address changed." which is what you want to remind
them.
2. Hit "reply".
3. Edit away the notice and prefix symbols on the requoted message.
4. Send.
5. Use the new address now.
--
.*. "Clouds are not spheres, mountains are not cones, coastlines are not
-() < circles, and bark is not smooth, nor does lightning travel in a
`*' straight line." -------------------------------------------------
-- B. Mandelbrot | http://surf.to/pgd.net
_____________________ ____|________ Paul Derbyshire pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|
^ permalink raw reply [flat|nested] 264+ messages in thread
* Re: [Meta] Enough of the "egcs.cygnus.com" already!
1999-02-01 15:58 ` Paul Derbyshire
@ 1999-02-28 22:53 ` Paul Derbyshire
0 siblings, 0 replies; 264+ messages in thread
From: Paul Derbyshire @ 1999-02-28 22:53 UTC (permalink / raw)
To: egcs
At 01:31 PM 2/1/99 -0200, you wrote:
>Either the relay or an automatic reply saying ``the new e-mail address
>for reporting egcs bugs is egcs-bugs@egcs.cygnus.com, please submit
>your report again, sorry for the inconvenience''.
MAKE THAT THING QUOTE BACK THE ORIGINAL MESSAGE!! I've seen a few systems
where outgoing mail is either not automatically saved or isn't even saved
at all, and people using such systems will experience "please submit your
report again" as meaning "Please struggle to remember all that you wrote
and then rewrite it slowly and painstakingly from scratch, and at the end,
remember to use the right address!". This is why mailer_daemon mail quotes
back the bounced message too.
Best would be to have it send the message described, quote the oiginal
below it, and have a Reply-To: of egcs-bugs@egcs.com. Then all the guy has
to do who sees it is
1. Note "hmm, the damned address changed." which is what you want to remind
them.
2. Hit "reply".
3. Edit away the notice and prefix symbols on the requoted message.
4. Send.
5. Use the new address now.
--
.*. "Clouds are not spheres, mountains are not cones, coastlines are not
-() < circles, and bark is not smooth, nor does lightning travel in a
`*' straight line." -------------------------------------------------
-- B. Mandelbrot | http://surf.to/pgd.net
_____________________ ____|________ Paul Derbyshire pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|
^ permalink raw reply [flat|nested] 264+ messages in thread
* Re: [Meta] Enough of the "egcs.cygnus.com" already!
1999-02-01 7:35 ` Alexandre Oliva
[not found] ` < or1zkab0ou.fsf@araguaia.dcc.unicamp.br >
@ 1999-02-28 22:53 ` Alexandre Oliva
1 sibling, 0 replies; 264+ messages in thread
From: Alexandre Oliva @ 1999-02-28 22:53 UTC (permalink / raw)
To: law; +Cc: Paul Derbyshire, egcs
On Feb 1, 1999, Jeffrey A Law <law@hurl.cygnus.com> wrote:
> In message < or4sp6b12f.fsf@araguaia.dcc.unicamp.br >you write:
>> On Feb 1, 1999, Jeffrey A Law <law@upchuck.cygnus.com> wrote:
>> > The @cygnus.com relays are scheduled to go away on or around March 1, 199
>> 9.
>> What about the following error message, printed by egcs 1.1.1?
>> bug.c:3: Please submit a full bug report to `egcs-bugs@cygnus.com'.
> Easily fixed ;-)
No, I mean, we must keep at least egcs-bugs@cygnus.com as a valid
address, otherwise people that don't know about the change won't be
able to submit bug reports against egcs 1.1.1, that will probably
still be floating around for a long time :-(
Either the relay or an automatic reply saying ``the new e-mail address
for reporting egcs bugs is egcs-bugs@egcs.cygnus.com, please submit
your report again, sorry for the inconvenience''.
--
Alexandre Oliva http://www.dcc.unicamp.br/~oliva aoliva@{acm.org}
oliva@{dcc.unicamp.br,gnu.org,egcs.cygnus.com,samba.org}
Universidade Estadual de Campinas, SP, Brasil
^ permalink raw reply [flat|nested] 264+ messages in thread
* Re: [Meta] Enough of the "egcs.cygnus.com" already!
1999-02-01 7:30 ` Jeffrey A Law
1999-02-01 7:35 ` Alexandre Oliva
@ 1999-02-01 7:59 ` Ken Raeburn
1999-02-28 22:53 ` Ken Raeburn
1999-02-28 22:53 ` Jeffrey A Law
2 siblings, 1 reply; 264+ messages in thread
From: Ken Raeburn @ 1999-02-01 7:59 UTC (permalink / raw)
To: law; +Cc: Alexandre Oliva, Paul Derbyshire, egcs
Jeffrey A Law <law@hurl.cygnus.com> writes:
> > bug.c:3: Please submit a full bug report to `egcs-bugs@cygnus.com'.
> Easily fixed ;-)
Retroactively? Or do you expect people to update to a new egcs
release within the next 28 days? We need *something* at that address,
even if it's a vacation-like program telling people to use the new
address.
^ permalink raw reply [flat|nested] 264+ messages in thread
* Re: [Meta] Enough of the "egcs.cygnus.com" already!
1999-02-01 7:59 ` Ken Raeburn
@ 1999-02-28 22:53 ` Ken Raeburn
0 siblings, 0 replies; 264+ messages in thread
From: Ken Raeburn @ 1999-02-28 22:53 UTC (permalink / raw)
To: law; +Cc: Alexandre Oliva, Paul Derbyshire, egcs
Jeffrey A Law <law@hurl.cygnus.com> writes:
> > bug.c:3: Please submit a full bug report to `egcs-bugs@cygnus.com'.
> Easily fixed ;-)
Retroactively? Or do you expect people to update to a new egcs
release within the next 28 days? We need *something* at that address,
even if it's a vacation-like program telling people to use the new
address.
^ permalink raw reply [flat|nested] 264+ messages in thread
* Re: [Meta] Enough of the "egcs.cygnus.com" already!
1999-02-01 7:30 ` Jeffrey A Law
1999-02-01 7:35 ` Alexandre Oliva
1999-02-01 7:59 ` Ken Raeburn
@ 1999-02-28 22:53 ` Jeffrey A Law
2 siblings, 0 replies; 264+ messages in thread
From: Jeffrey A Law @ 1999-02-28 22:53 UTC (permalink / raw)
To: Alexandre Oliva; +Cc: Paul Derbyshire, egcs
In message < or4sp6b12f.fsf@araguaia.dcc.unicamp.br >you write:
> On Feb 1, 1999, Jeffrey A Law <law@upchuck.cygnus.com> wrote:
>
> > The @cygnus.com relays are scheduled to go away on or around March 1, 199
> 9.
>
> What about the following error message, printed by egcs 1.1.1?
>
> bug.c:3: Please submit a full bug report to `egcs-bugs@cygnus.com'.
Easily fixed ;-)
jeff
^ permalink raw reply [flat|nested] 264+ messages in thread
* Re: [Meta] Enough of the "egcs.cygnus.com" already!
[not found] ` < or4sp6b12f.fsf@araguaia.dcc.unicamp.br >
1999-02-01 7:30 ` Jeffrey A Law
@ 1999-02-13 10:47 ` Jeffrey A Law
1999-02-28 22:53 ` Jeffrey A Law
1 sibling, 1 reply; 264+ messages in thread
From: Jeffrey A Law @ 1999-02-13 10:47 UTC (permalink / raw)
To: Alexandre Oliva; +Cc: Paul Derbyshire, egcs
In message < or4sp6b12f.fsf@araguaia.dcc.unicamp.br >you write:
> On Feb 1, 1999, Jeffrey A Law <law@upchuck.cygnus.com> wrote:
>
> > The @cygnus.com relays are scheduled to go away on or around March 1, 199
> 9.
>
> What about the following error message, printed by egcs 1.1.1?
>
> bug.c:3: Please submit a full bug report to `egcs-bugs@cygnus.com'.
An FYI -- I fixed all the addresses about a week ago :-)
jeff
^ permalink raw reply [flat|nested] 264+ messages in thread
* Re: [Meta] Enough of the "egcs.cygnus.com" already!
1999-02-13 10:47 ` Jeffrey A Law
@ 1999-02-28 22:53 ` Jeffrey A Law
0 siblings, 0 replies; 264+ messages in thread
From: Jeffrey A Law @ 1999-02-28 22:53 UTC (permalink / raw)
To: Alexandre Oliva; +Cc: Paul Derbyshire, egcs
In message < or4sp6b12f.fsf@araguaia.dcc.unicamp.br >you write:
> On Feb 1, 1999, Jeffrey A Law <law@upchuck.cygnus.com> wrote:
>
> > The @cygnus.com relays are scheduled to go away on or around March 1, 199
> 9.
>
> What about the following error message, printed by egcs 1.1.1?
>
> bug.c:3: Please submit a full bug report to `egcs-bugs@cygnus.com'.
An FYI -- I fixed all the addresses about a week ago :-)
jeff
^ permalink raw reply [flat|nested] 264+ messages in thread
* Re: [Meta] Enough of the "egcs.cygnus.com" already!
1999-02-01 7:27 ` Alexandre Oliva
[not found] ` < or4sp6b12f.fsf@araguaia.dcc.unicamp.br >
@ 1999-02-28 22:53 ` Alexandre Oliva
1 sibling, 0 replies; 264+ messages in thread
From: Alexandre Oliva @ 1999-02-28 22:53 UTC (permalink / raw)
To: law; +Cc: Paul Derbyshire, egcs
On Feb 1, 1999, Jeffrey A Law <law@upchuck.cygnus.com> wrote:
> The @cygnus.com relays are scheduled to go away on or around March 1, 1999.
What about the following error message, printed by egcs 1.1.1?
bug.c:3: Please submit a full bug report to `egcs-bugs@cygnus.com'.
--
Alexandre Oliva http://www.dcc.unicamp.br/~oliva aoliva@{acm.org}
oliva@{dcc.unicamp.br,gnu.org,egcs.cygnus.com,samba.org}
Universidade Estadual de Campinas, SP, Brasil
^ permalink raw reply [flat|nested] 264+ messages in thread
* Re: [Meta] Enough of the "egcs.cygnus.com" already!
1999-02-01 7:13 ` Jeffrey A Law
1999-02-01 7:27 ` Alexandre Oliva
@ 1999-02-28 22:53 ` Jeffrey A Law
1 sibling, 0 replies; 264+ messages in thread
From: Jeffrey A Law @ 1999-02-28 22:53 UTC (permalink / raw)
To: Paul Derbyshire; +Cc: egcs
In message <3.0.6.32.19990201010831.00880950@pop.netaddress.com>you write:
> Grr. I subscribe to the EGCS mailing list at egcs.cygnus.com and set a mail
> filter to filter anything with a To: or Cc: containing
> "egcs@egcs.cygnus.com" into an 'egcs' folder, figuring that it isn't likely
> that anyone would BCc: to the list and confound the filter.
>
> Trouble is, it seems you can post to the list using just "egcs@cygnus.com",
> since I keep finding a shitload of egcs mail in my main Inbox with this on
> the Cc: line!
The @cygnus.com relays are scheduled to go away on or around March 1, 1999.
jeff
^ permalink raw reply [flat|nested] 264+ messages in thread
[parent not found: <19990201200631.A227@tardis.ed.ac.uk>]
* Re: [Meta] Enough of the "egcs.cygnus.com" already!
[not found] ` <19990201200631.A227@tardis.ed.ac.uk>
@ 1999-02-01 15:31 ` Paul Derbyshire
1999-02-28 22:53 ` Paul Derbyshire
0 siblings, 1 reply; 264+ messages in thread
From: Paul Derbyshire @ 1999-02-01 15:31 UTC (permalink / raw)
To: Mark Brown; +Cc: egcs
At 08:06 PM 2/1/99 +0000, you wrote:
> Sender: owner-egcs@egcs.cygnus.com
>
>which is guarenteed to be in any message sent through this list.
I don't get any Sender: headers in my incoming egcs mail, interestingly
enough.
--
.*. "Clouds are not spheres, mountains are not cones, coastlines are not
-() < circles, and bark is not smooth, nor does lightning travel in a
`*' straight line." -------------------------------------------------
-- B. Mandelbrot | http://surf.to/pgd.net
_____________________ ____|________ Paul Derbyshire pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|
^ permalink raw reply [flat|nested] 264+ messages in thread
* Re: [Meta] Enough of the "egcs.cygnus.com" already!
1999-02-01 15:31 ` Paul Derbyshire
@ 1999-02-28 22:53 ` Paul Derbyshire
0 siblings, 0 replies; 264+ messages in thread
From: Paul Derbyshire @ 1999-02-28 22:53 UTC (permalink / raw)
To: Mark Brown; +Cc: egcs
At 08:06 PM 2/1/99 +0000, you wrote:
> Sender: owner-egcs@egcs.cygnus.com
>
>which is guarenteed to be in any message sent through this list.
I don't get any Sender: headers in my incoming egcs mail, interestingly
enough.
--
.*. "Clouds are not spheres, mountains are not cones, coastlines are not
-() < circles, and bark is not smooth, nor does lightning travel in a
`*' straight line." -------------------------------------------------
-- B. Mandelbrot | http://surf.to/pgd.net
_____________________ ____|________ Paul Derbyshire pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|
^ permalink raw reply [flat|nested] 264+ messages in thread
* Re: [Meta] Enough of the "egcs.cygnus.com" already!
1999-01-31 22:09 [Meta] Enough of the "egcs.cygnus.com" already! Paul Derbyshire
` (3 preceding siblings ...)
[not found] ` <19990201200631.A227@tardis.ed.ac.uk>
@ 1999-02-03 12:05 ` Rask Ingemann Lambertsen
1999-02-28 22:53 ` Rask Ingemann Lambertsen
4 siblings, 1 reply; 264+ messages in thread
From: Rask Ingemann Lambertsen @ 1999-02-03 12:05 UTC (permalink / raw)
To: EGCS mailing list
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1769 bytes --]
Den 01-Feb-99 07:08:31 skrev Paul Derbyshire følgende om "[Meta] Enough of the "egcs.cygnus.com" already!":
> Grr. I subscribe to the EGCS mailing list at egcs.cygnus.com and set a mail
> filter to filter anything with a To: or Cc: containing
> "egcs@egcs.cygnus.com" into an 'egcs' folder, figuring that it isn't likely
> that anyone would BCc: to the list and confound the filter.
Mail sorting based on To:, Cc: or Bcc: headers hasn't ever worked, doesn't
work, and won't ever work. This doesn't seem to stop people from trying to do
so anyway. :-(
> Trouble is, it seems you can post to the list using just "egcs@cygnus.com",
> since I keep finding a shitload of egcs mail in my main Inbox with this on
> the Cc: line!
Good example of why it hasn't ever worked, doesn't work and won't ever work.
Searching for the
Delivered-To: mailing list egcs@egcs.cygnus.com
header does work. Always. Reliably.
Since it is quite normal for list subscribers of today not to know how
how do set up their mail readers, perhaps it should be mentioned somewhere
that this header appears in all egcs mailing list mail, so as to at least
provide the initial clue.
Regards,
/¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯T¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯\
| Rask Ingemann Lambertsen | E-mail: mailto:rask@kampsax.k-net.dk |
| Registered Phase5 developer | WWW: http://www.gbar.dtu.dk/~c948374/ |
| A4000, 775 kkeys/s (RC5-64) | "ThrustMe" on XPilot, ARCnet and IRC |
| Diplomacy is the art of saying "Nice doggie" till you can find a rock |
^ permalink raw reply [flat|nested] 264+ messages in thread
* Re: [Meta] Enough of the "egcs.cygnus.com" already!
1999-02-03 12:05 ` Rask Ingemann Lambertsen
@ 1999-02-28 22:53 ` Rask Ingemann Lambertsen
0 siblings, 0 replies; 264+ messages in thread
From: Rask Ingemann Lambertsen @ 1999-02-28 22:53 UTC (permalink / raw)
To: EGCS mailing list
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1770 bytes --]
Den 01-Feb-99 07:08:31 skrev Paul Derbyshire følgende om "[Meta] Enough of the "egcs.cygnus.com" already!":
> Grr. I subscribe to the EGCS mailing list at egcs.cygnus.com and set a mail
> filter to filter anything with a To: or Cc: containing
> "egcs@egcs.cygnus.com" into an 'egcs' folder, figuring that it isn't likely
> that anyone would BCc: to the list and confound the filter.
Mail sorting based on To:, Cc: or Bcc: headers hasn't ever worked, doesn't
work, and won't ever work. This doesn't seem to stop people from trying to do
so anyway. :-(
> Trouble is, it seems you can post to the list using just "egcs@cygnus.com",
> since I keep finding a shitload of egcs mail in my main Inbox with this on
> the Cc: line!
Good example of why it hasn't ever worked, doesn't work and won't ever work.
Searching for the
Delivered-To: mailing list egcs@egcs.cygnus.com
header does work. Always. Reliably.
Since it is quite normal for list subscribers of today not to know how
how do set up their mail readers, perhaps it should be mentioned somewhere
that this header appears in all egcs mailing list mail, so as to at least
provide the initial clue.
Regards,
/¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯T¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯\
| Rask Ingemann Lambertsen | E-mail: mailto:rask@kampsax.k-net.dk |
| Registered Phase5 developer | WWW: http://www.gbar.dtu.dk/~c948374/ |
| A4000, 775 kkeys/s (RC5-64) | "ThrustMe" on XPilot, ARCnet and IRC |
| Diplomacy is the art of saying "Nice doggie" till you can find a rock |
^ permalink raw reply [flat|nested] 264+ messages in thread
[parent not found: <Franz>]
[parent not found: <Ken>]
[parent not found: <Paul>]
[parent not found: <Brad>]
[parent not found: <Eli>]
[parent not found: <David>]
end of thread, other threads:[~2001-06-12 6:48 UTC | newest]
Thread overview: 264+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <Jeffrey>
[not found] ` <A>
[not found] ` <Law's>
[not found] ` <message>
[not found] ` <of>
[not found] ` <"Thu,>
[not found] ` <"Wed,>
[not found] ` <5>
[not found] ` <"Sun,>
[not found] ` <19>
[not found] ` <Fri,>
[not found] ` <"Mon,>
[not found] ` <01>
[not found] ` <Mar>
[not found] ` <99>
[not found] ` <Feb>
[not found] ` <1999>
[not found] ` <02:37:52>
[not found] ` <12:29:11>
[not found] ` <-0500>
1999-02-01 8:23 ` A Lisp compiler? Matthew X. Economou
1999-02-01 9:29 ` Ken Raeburn
1999-02-02 15:44 ` Matthew X. Economou
[not found] ` < w4ou2x4jrke.fsf@nemesis.irtnog.org >
1999-02-02 16:14 ` [Meta] " Paul Derbyshire
1999-02-28 22:53 ` Paul Derbyshire
1999-02-28 22:53 ` Matthew X. Economou
1999-02-19 23:14 ` Matthias Hölzl
1999-02-28 22:53 ` Matthias Hölzl
1999-02-28 22:53 ` Ken Raeburn
1999-02-28 22:53 ` Matthew X. Economou
1999-02-27 21:39 ` Confirmed template parsing bug: bug in error message generation Paul Derbyshire
1999-02-28 22:53 ` Paul Derbyshire
1999-03-01 0:02 ` Alexandre Oliva
[not found] ` < oriuclljxv.fsf@araguaia.dcc.unicamp.br >
1999-03-02 8:43 ` Paul Derbyshire
[not found] ` < 3.0.6.32.19990302114234.0086bd80@pop.globalserve.net >
1999-03-02 9:26 ` Robert Lipe
1999-03-31 23:46 ` Robert Lipe
1999-03-02 22:22 ` Alexandre Oliva
1999-03-31 23:46 ` Alexandre Oliva
1999-03-31 23:46 ` Paul Derbyshire
1999-03-31 23:46 ` Alexandre Oliva
1999-02-28 19:05 ` Possible egcs-1.1.2-pre2 configure problem on HP-UX 9.04 rodneybrown
1999-02-28 22:53 ` rodneybrown
1999-03-01 9:05 ` Alexandre Oliva
[not found] ` < orogmdf8jw.fsf@araguaia.dcc.unicamp.br >
1999-03-01 9:14 ` Franz Sirl
1999-03-01 9:32 ` Alexandre Oliva
1999-03-31 23:46 ` Alexandre Oliva
1999-03-31 23:46 ` Franz Sirl
1999-03-31 23:46 ` Alexandre Oliva
1999-03-01 9:18 ` Jeffrey A Law
1999-03-31 23:46 ` Jeffrey A Law
[not found] ` <(EST)>
1999-06-25 17:54 ` Occasional use of GNU ld problems Brad Lucier
1999-06-29 2:06 ` Alexandre Oliva
1999-06-29 2:20 ` Franz Sirl
1999-06-30 15:43 ` Franz Sirl
1999-06-30 15:43 ` Alexandre Oliva
1999-06-30 15:43 ` Brad Lucier
[not found] ` <04:47:24>
[not found] ` <-0800>
1999-02-12 3:00 ` C++ default copy ctor not optimal Sylvain Pion
[not found] ` < 19990212120037.C13091@rigel.inria.fr >
1999-02-12 4:46 ` Sylvain Pion
1999-02-28 22:53 ` Sylvain Pion
[not found] ` <19990212134607.F13091.cygnus.egcs@rigel.inria.fr>
1999-02-12 13:41 ` Jason Merrill
[not found] ` <3.0.6.32.19990212172607.00844860.cygnus.egcs@pop.netaddress.com>
1999-02-12 15:27 ` Jason Merrill
1999-02-28 22:53 ` Jason Merrill
[not found] ` < u9d83fl2q8.fsf@yorick.cygnus.com >
1999-02-12 14:26 ` Paul Derbyshire
1999-02-28 22:53 ` Paul Derbyshire
1999-02-14 10:57 ` Sylvain Pion
1999-02-14 21:01 ` Jason Merrill
[not found] ` < u9iud4jm52.fsf@yorick.cygnus.com >
1999-02-15 17:15 ` Richard Henderson
[not found] ` < 19990215171524.A19063@cygnus.com >
1999-02-15 20:14 ` Jeffrey A Law
[not found] ` < 14555.919137968@upchuck >
1999-02-15 21:39 ` Richard Henderson
[not found] ` < 19990215213927.A19254@cygnus.com >
1999-02-16 0:10 ` Sylvain Pion
1999-02-28 22:53 ` Sylvain Pion
1999-02-28 22:53 ` Richard Henderson
1999-02-28 22:53 ` Jeffrey A Law
1999-02-16 10:08 ` Joe Buck
[not found] ` < 199902161807.KAA19010@atrus.synopsys.com >
1999-02-16 10:18 ` Richard Henderson
[not found] ` < 19990216101811.A19900@cygnus.com >
1999-02-16 10:33 ` Sylvain Pion
1999-02-28 22:53 ` Sylvain Pion
1999-02-28 22:53 ` Richard Henderson
1999-02-28 22:53 ` Joe Buck
1999-02-28 22:53 ` Richard Henderson
1999-02-28 22:53 ` Jason Merrill
1999-02-28 22:53 ` Sylvain Pion
1999-02-28 22:53 ` Jason Merrill
1999-02-28 22:53 ` Sylvain Pion
[not found] ` <3.0.6.32.19990212180551.00841100.cygnus.egcs@pop.netaddress.com>
1999-02-12 15:29 ` Code gen question Jason Merrill
[not found] ` < u990e3kxq8.fsf@yorick.cygnus.com >
1999-02-12 17:34 ` Paul Derbyshire
[not found] ` < 3.0.6.32.19990212203311.0083e6d0@pop.netaddress.com >
1999-02-12 17:39 ` Jeffrey A Law
1999-02-28 22:53 ` Jeffrey A Law
1999-02-28 22:53 ` Paul Derbyshire
1999-02-28 22:53 ` Jason Merrill
1999-02-24 16:27 ` Question about compiler-supplied assignment and copy with egcs Mike Stump
[not found] ` < 199902250026.QAA04615@kankakee.wrs.com >
1999-02-25 22:31 ` Paul Derbyshire
1999-02-28 22:53 ` Paul Derbyshire
[not found] ` <3.0.6.32.19990226013110.0083c530.cygnus.egcs@pop.globalserve.net>
1999-02-25 22:45 ` Jason Merrill
[not found] ` < u91zjdirxx.fsf@yorick.cygnus.com >
1999-02-27 21:01 ` Paul Derbyshire
[not found] ` < 3.0.6.32.19990228000118.00923340@pop.globalserve.net >
1999-02-27 21:58 ` Question about compiler-supplied assignment and copy with Joe Buck
[not found] ` < 199902280557.VAA14849@atrus.synopsys.com >
1999-02-27 23:29 ` Paul Derbyshire
1999-02-28 22:53 ` Paul Derbyshire
1999-02-28 22:53 ` Joe Buck
1999-02-28 22:53 ` Question about compiler-supplied assignment and copy with egcs Paul Derbyshire
[not found] ` <3.0.6.32.19990228000118.00923340.cygnus.egcs@pop.globalserve.net>
1999-02-27 23:55 ` Jason Merrill
[not found] ` < u9yalj7yin.fsf@yorick.cygnus.com >
1999-02-28 1:10 ` Paul Derbyshire
1999-02-28 2:51 ` Tudor Hulubei
[not found] ` < 14041.8114.947193.298212@hal.ttlc.net >
1999-02-28 4:36 ` Paul Derbyshire
1999-02-28 22:53 ` Paul Derbyshire
1999-02-28 22:53 ` Tudor Hulubei
1999-02-28 22:53 ` Paul Derbyshire
1999-03-01 2:28 ` Gerald Pfeifer
1999-03-31 23:46 ` Gerald Pfeifer
1999-02-28 22:53 ` Jason Merrill
1999-02-28 22:53 ` Jason Merrill
1999-02-28 22:53 ` Mike Stump
2000-11-19 13:03 ` Removal of V2 code Mark Mitchell
2000-11-19 17:10 ` Geoff Keating
[not found] ` <Mark>
2000-11-19 17:24 ` Christopher Faylor
2000-11-19 17:56 ` Mark Mitchell
2000-11-19 20:24 ` Geoff Keating
2000-11-19 21:52 ` Mark Mitchell
2000-11-19 22:12 ` Geoff Keating
2000-11-19 22:33 ` Mark Mitchell
2000-11-20 1:07 ` Mark Mitchell
2000-11-20 2:11 ` Geoff Keating
2000-11-21 10:56 ` Mark Mitchell
2000-11-21 12:20 ` Benjamin Kosnik
2000-11-21 12:45 ` Mark Mitchell
2000-11-21 12:37 ` Geoff Keating
2000-11-21 12:47 ` Mark Mitchell
2000-11-20 2:54 ` Franz Sirl
2000-11-21 6:38 ` Franz Sirl
2000-11-21 7:26 ` Daniel Berlin
2000-11-20 0:41 ` Andrew Cagney
2000-11-20 0:55 ` Mark Mitchell
2000-11-20 3:32 ` Marc Espie
2000-11-20 5:53 ` Joseph S. Myers
2000-11-20 8:34 ` Mark Mitchell
[not found] ` <00112021562300.00259@hallo>
2000-11-20 14:58 ` Mark Mitchell
2000-11-21 14:14 ` Geoff Keating
2000-11-21 15:06 ` Mark Mitchell
2000-11-21 16:08 ` Tom Tromey
2000-11-21 17:21 ` 2.95.3 (was Re: Removal of V2 code) Joe Buck
2000-11-22 13:55 ` Tom Tromey
2000-11-21 21:41 ` Removal of V2 code Mark Mitchell
2000-11-21 20:00 ` SC confidentiality Geoff Keating
2000-11-21 21:57 ` Mark Mitchell
[not found] ` <08:25:39>
[not found] ` <-0700>
2001-05-09 9:58 ` Automake and friends and fastjar Mark Klein
2001-05-09 12:08 ` Tom Tromey
2001-05-09 12:15 ` Mark Klein
[not found] ` <"Fri,>
[not found] ` <11>
[not found] ` <Jun>
[not found] ` <2000>
[not found] ` <10:30:29>
[not found] ` <-0400>
2000-06-29 7:30 ` SSA implementation David Dolan
2000-06-29 11:59 ` Geoff Keating
2000-06-29 12:07 ` Errors from Gcc Matt Minnis
2000-06-29 13:43 ` Martin v. Loewis
2000-06-29 12:11 ` SSA implementation Mark Mitchell
2000-06-29 12:24 ` Gerald Pfeifer
2000-07-05 11:52 ` PowerPC code generation David J Schinsing
2000-07-05 12:15 ` David Young
2000-07-05 12:57 ` gcc and struct passing in function arguments? David Young
2000-07-05 13:09 ` Michael Meissner
2000-07-05 14:00 ` Joern Rennecke
2000-07-05 13:50 ` Alan Lehotsky
2000-07-05 13:26 ` PowerPC code generation Geoff Keating
2000-07-05 13:53 ` Franz Sirl
2000-07-05 14:20 ` Michael Meissner
2000-07-05 14:36 ` Geoff Keating
2000-07-05 19:54 ` David Edelsohn
[not found] ` <25>
[not found] ` <May>
[not found] ` <2001>
[not found] ` <10:06:51>
[not found] ` <+0300>
2001-06-07 18:27 ` Another RFC: regex in libiberty DJ Delorie
2001-06-07 18:31 ` Ian Lance Taylor
2001-06-07 18:33 ` DJ Delorie
2001-06-07 18:43 ` Ian Lance Taylor
2001-06-08 0:11 ` Eli Zaretskii
2001-06-08 9:18 ` Mark Mitchell
2001-06-08 9:59 ` Zack Weinberg
2001-06-08 10:05 ` H . J . Lu
2001-06-08 10:31 ` Eli Zaretskii
2001-06-08 10:39 ` H . J . Lu
2001-06-08 10:37 ` Eli Zaretskii
2001-06-11 22:50 ` Jim Blandy
2001-06-11 23:51 ` Randall R Schulz
2001-06-12 6:48 ` Jim Blandy
2001-06-09 13:34 ` Andrew Cagney
[not found] <19990608202201.F17154@admin3.jump.net>
[not found] ` <org142xios.fsf@saci.lsd.dcc.unicamp.br>
[not found] ` <3761d206.15532319@mailer.gwdg.de>
[not found] ` <oru2sg6sd1.fsf@saci.lsd.dcc.unicamp.br>
[not found] ` <3762cfb6.8581897@mailer.gwdg.de>
[not found] ` <oru2sf6hst.fsf@saci.lsd.dcc.unicamp.br>
1999-06-10 16:01 ` libs/csengine/basic/polyset.cpp:46: Internal compiler error 191 Philipp Thomas
1999-06-30 15:43 ` Philipp Thomas
[not found] ` <376b1082.25172596@mailer.gwdg.de>
1999-06-10 17:18 ` Alexandre Oliva
1999-06-10 17:50 ` Franz Sirl
1999-06-12 16:02 ` Alexandre Oliva
1999-06-15 4:11 ` Franz Sirl
1999-06-15 4:54 ` Alexandre Oliva
1999-06-30 15:43 ` Alexandre Oliva
1999-06-30 15:43 ` Franz Sirl
1999-06-30 15:43 ` Alexandre Oliva
1999-06-30 15:43 ` Franz Sirl
1999-06-30 15:43 ` Alexandre Oliva
1999-05-20 21:06 assemble_external on .class files Mark Klein
1999-05-22 14:23 ` Jeffrey A Law
1999-05-22 15:28 ` Mark Klein
1999-05-31 21:36 ` Mark Klein
1999-05-25 18:33 ` Mark Klein
1999-05-25 19:41 ` Jeffrey A Law
1999-05-25 21:00 ` Per Bothner
1999-05-25 21:50 ` Jeffrey A Law
1999-05-25 22:19 ` Mark Klein
1999-05-25 22:24 ` Jeffrey A Law
1999-05-31 21:36 ` Jeffrey A Law
1999-05-25 22:49 ` Per Bothner
1999-05-31 14:53 ` Mark Klein
1999-05-31 21:36 ` Mark Klein
1999-05-31 21:36 ` Per Bothner
1999-05-31 21:36 ` Mark Klein
1999-05-31 21:36 ` Jeffrey A Law
1999-05-31 21:36 ` Per Bothner
1999-05-31 21:36 ` Jeffrey A Law
1999-05-31 21:36 ` Mark Klein
1999-05-31 21:36 ` Jeffrey A Law
1999-05-31 21:36 ` Mark Klein
-- strict thread matches above, loose matches on Subject: below --
1999-02-24 15:13 Bug in libm or libstdc++ Paul Derbyshire
[not found] ` < 3.0.6.32.19990222090333.00847df0@pop.globalserve.net >
1999-02-24 15:34 ` Joe Buck
[not found] ` < 199902242332.PAA09334@atrus.synopsys.com >
1999-02-25 22:25 ` Paul Derbyshire
[not found] ` < 3.0.6.32.19990226012513.008e5450@pop.globalserve.net >
1999-02-26 10:38 ` Joe Buck
[not found] ` < 199902261836.KAA17757@atrus.synopsys.com >
1999-02-26 22:21 ` Paul Derbyshire
[not found] ` < 3.0.6.32.19990227012120.0084e180@pop.globalserve.net >
1999-02-27 9:40 ` Marc Espie
[not found] ` < 199902271740.SAA14323@quatramaran.ens.fr >
1999-02-27 20:45 ` Paul Derbyshire
1999-02-28 22:53 ` Paul Derbyshire
1999-03-01 0:19 ` Alexandre Oliva
[not found] ` < ord82tlj4l.fsf@araguaia.dcc.unicamp.br >
1999-03-02 7:58 ` Paul Derbyshire
1999-03-02 23:08 ` Alexandre Oliva
1999-03-31 23:46 ` Alexandre Oliva
1999-03-31 23:46 ` Paul Derbyshire
1999-03-31 23:46 ` Alexandre Oliva
1999-02-28 22:53 ` Marc Espie
1999-02-28 22:53 ` Paul Derbyshire
1999-02-28 22:53 ` Joe Buck
1999-02-28 22:53 ` Paul Derbyshire
1999-02-28 22:53 ` Joe Buck
1999-02-24 15:42 ` Bob McWhirter
[not found] ` < Pine.LNX.3.96.990224183714.7438r-100000@exeter.exeter.org >
1999-02-25 22:20 ` Paul Derbyshire
[not found] ` <199902261635.LAA23787@wagner.Princeton.EDU>
1999-02-27 19:08 ` Paul Derbyshire
1999-02-28 22:53 ` Paul Derbyshire
1999-03-01 8:30 ` Joern Rennecke
[not found] ` < 199903011630.QAA00110@phal.cygnus.co.uk >
1999-03-02 8:04 ` Paul Derbyshire
[not found] ` < 3.0.6.32.19990302110405.00945870@pop.globalserve.net >
1999-03-02 8:38 ` Joern Rennecke
1999-03-31 23:46 ` Joern Rennecke
1999-03-31 23:46 ` Paul Derbyshire
1999-03-31 23:46 ` Joern Rennecke
[not found] ` <Pine.SUN.3.91.990228142826.5950V-100000@is>
1999-02-28 4:57 ` Paul Derbyshire
1999-02-28 22:53 ` Paul Derbyshire
1999-02-28 22:53 ` Paul Derbyshire
1999-02-28 22:53 ` Bob McWhirter
1999-02-28 22:53 ` Paul Derbyshire
1999-01-31 22:09 [Meta] Enough of the "egcs.cygnus.com" already! Paul Derbyshire
1999-01-31 22:14 ` CaT
1999-01-31 22:24 ` Bob McWhirter
1999-01-31 22:50 ` Paul Derbyshire
1999-02-01 2:01 ` Franz Sirl
[not found] ` < 4.1.19990201105045.054320e0@mail.lauterbach.com >
1999-02-01 15:53 ` Paul Derbyshire
1999-02-28 22:53 ` Paul Derbyshire
1999-02-28 22:53 ` Rask Ingemann Lambertsen
1999-02-28 22:53 ` Franz Sirl
1999-01-31 23:12 ` Ken Raeburn
1999-02-01 7:13 ` Jeffrey A Law
1999-02-01 7:27 ` Alexandre Oliva
[not found] ` < or4sp6b12f.fsf@araguaia.dcc.unicamp.br >
1999-02-01 7:30 ` Jeffrey A Law
1999-02-01 7:35 ` Alexandre Oliva
[not found] ` < or1zkab0ou.fsf@araguaia.dcc.unicamp.br >
1999-02-01 7:50 ` Jeffrey A Law
[not found] ` < 3391.917883892@hurl.cygnus.com >
1999-02-01 8:23 ` Joe Buck
[not found] ` < 199902011621.IAA00385@atrus.synopsys.com >
1999-02-01 8:24 ` Jeffrey A Law
1999-02-28 22:53 ` Jeffrey A Law
1999-02-01 16:03 ` Paul Derbyshire
1999-02-28 22:53 ` Paul Derbyshire
1999-02-28 22:53 ` postmaster
1999-02-28 22:53 ` Joe Buck
1999-02-28 22:53 ` Jeffrey A Law
1999-02-01 15:58 ` Paul Derbyshire
1999-02-28 22:53 ` Paul Derbyshire
1999-02-28 22:53 ` Alexandre Oliva
1999-02-01 7:59 ` Ken Raeburn
1999-02-28 22:53 ` Ken Raeburn
1999-02-28 22:53 ` Jeffrey A Law
1999-02-13 10:47 ` Jeffrey A Law
1999-02-28 22:53 ` Jeffrey A Law
1999-02-28 22:53 ` Alexandre Oliva
1999-02-28 22:53 ` Jeffrey A Law
[not found] ` <19990201200631.A227@tardis.ed.ac.uk>
1999-02-01 15:31 ` Paul Derbyshire
1999-02-28 22:53 ` Paul Derbyshire
1999-02-03 12:05 ` Rask Ingemann Lambertsen
1999-02-28 22:53 ` Rask Ingemann Lambertsen
[not found] <Franz>
[not found] <Ken>
[not found] <Paul>
[not found] <Brad>
[not found] <Eli>
[not found] <David>
[not found] ` <J>
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).