Dear Sirs,
Following program (implementing sieve of Eratosthenes) doesn't work as expected: after adding [i] to SET it doesn't appear to be in it!!!
This is for i in [32..63,96..127,160..191,224-255]. Numbers 95 and 195 _couldn't_be_removed_ from SET sieve.
gpc --version
2.95.3 20010315 (release)
uname -a
OSF1 domac.alu.hr V4.0b 564 alpha
--marvin01.pas--------------------------------------------------------------
PROGRAM sieveprogram(input,output); {Sieve of Eratosthenes for finding prime numbers}
CONST maxN = 255; VAR i,j,k: CARDINAL; sieve: SET OF Byte;
BEGIN FOR i:= 1 TO maxN DO {initialize sieve} BEGIN sieve := sieve + [i]; IF (NOT (i IN sieve)) THEN writeln('Error: ', i, ' not in SET after adding!'); END;
FOR i:= 2 TO maxN DO BEGIN IF (i IN sieve) THEN FOR k := i+1 TO maxN DO IF ((k MOD i = 0) AND (k IN sieve)) THEN BEGIN sieve := sieve - [k]; IF (k IN sieve) THEN writeln('Error: ', k, ' in SET after deletion!'); END END;
FOR i:= 2 TO maxN DO IF (i IN sieve) THEN BEGIN writeln('Checking if really prime: ', i); FOR j:= 2 TO i-1 DO IF (i MOD j = 0) THEN writeln('Error: ', i,' % ', j, ' = 0.'); END
END.
--------------------------------------------------------------------------
Program compiles with warnings:
gpc marvin01.pas
marvin01.pas: In main program: marvin01.pas:12: warning: constructing limited integer set `0..511' marvin01.pas:23: warning: constructing limited integer set `0..511'
-------------------------------------------------------------------------- Program output (unexpected errors): --------------------------------------------------------------------------
./a.out
Error: 32 not in SET after adding! Error: 33 not in SET after adding! . . . Error: 63 not in SET after adding! Error: 96 not in SET after adding! Error: 97 not in SET after adding! Error: 98 not in SET after adding! . . . Error: 127 not in SET after adding! Error: 160 not in SET after adding! Error: 161 not in SET after adding! Error: 162 not in SET after adding! . . . Error: 191 not in SET after adding! Error: 224 not in SET after adding! Error: 225 not in SET after adding! Error: 226 not in SET after adding! . . . Error: 255 not in SET after adding! Error: 159 in SET after deletion! Error: 95 in SET after deletion! Error: 95 in SET after deletion! Checking: 2 Checking: 3 Checking: 5 Checking: 7 Checking: 11 Checking: 13 Checking: 17 Checking: 19 Checking: 23 Checking: 29 Checking: 31 Checking: 67 Checking: 71 Checking: 73 Checking: 79 Checking: 83 Checking: 89 Checking: 95 Error: 95 % 5 = 0. Error: 95 % 19 = 0. Checking: 131 Checking: 137 Checking: 139 Checking: 149 Checking: 151 Checking: 157 Checking: 159 Error: 159 % 3 = 0. Error: 159 % 53 = 0. Checking: 193 Checking: 197 Checking: 199 Checking: 211 Checking: 223
------------------------------------------------------------------------- Thank you for reading this far.
Best regards, Marvin
-- This message has been made up using recycled ideas and language constructs. No plant or animal has been injured in process of making this message.
On 5 Nov 2001, at 16:56, Mirsad Todorovac wrote:
Following program (implementing sieve of Eratosthenes) doesn't work as expected: after adding [i] to SET it doesn't appear to be in it!!!
Your program works as expected on GPC version 20010604 (i486-pc- mingw32msvc). I receive only:
Checking if really prime: 2 Checking if really prime: 3 [...] Checking if really prime: 241 Checking if really prime: 251
gpc --version
2.95.3 20010315 (release)
Unfortunately, "gpc --version" prints the version of GCC that GPC was built with and not the version of GPC itself. Try:
gpc -v
...to get the version of GPC, e.g.:
gpc version 20010604, based on 2.95.3 20010315 (release)
-- Dave
J. David Bryan wrote:
gpc --version
2.95.3 20010315 (release)
Unfortunately, "gpc --version" prints the version of GCC that GPC was built with and not the version of GPC itself.
I'll fix that (but, of course, this won't help here since it only applies to GPC versions from now on).
Frank
On Mon, 5 Nov 2001, J. David Bryan wrote:
Thank you for your message, Dave,
Following program (implementing sieve of Eratosthenes) doesn't work as expected: after adding [i] to SET it doesn't appear to be in it!!!
Your program works as expected on GPC version 20010604 (i486-pc- mingw32msvc). I receive only:
Checking if really prime: 2 Checking if really prime: 3 [...] Checking if really prime: 241 Checking if really prime: 251
I'm relieved somewhat (at least the program is good).
gpc -v
...to get the version of GPC, e.g.:
gpc version 20010604, based on 2.95.3 20010315 (release)
I've got:
gpc -v
Reading specs from /usr/local/lib/gcc-lib/alpha-dec-osf4.0b/2.95.3/specs gpc version 20010516, based on 2.95.3 20010315 (release)
Maybe it has something to do with the fact that I run GPC on Alpha 64-bit processor? I mean it worked OK for i in [0..31,64..95,128..159,192..223].
While for i in [32..63, 96..127, 160..191, 224-255] it was buggy.
This could have been caused by the fact that SET is represented by a 64-bit bit-field, and upper 32 bits of each bit field are treated wrong way (I don't think I miscompiled the compiler itself, since most of the tests in the testsuite passed ...)?????
Does my thinking make any sense to you?
Regards, Mirsad
-- This message has been made up using recycled ideas and language constructs. No plant or animal has been injured in process of making this message.
On 6 Nov 2001, at 12:50, Mirsad Todorovac wrote:
Thank you for your message, Dave,
You're welcome (no need to copy me separately, as I read the list :-).
gpc version 20010516, based on 2.95.3 20010315 (release)
Maybe it has something to do with the fact that I run GPC on Alpha 64-bit processor?
Perhaps. First, though, I would upgrade to the latest GPC release (20010924), as this may have been a bug that has now been fixed.
This could have been caused by the fact that SET is represented by a 64-bit bit-field, and upper 32 bits of each bit field are treated wrong way...
Yes, that is very possible. If upgrading to the latest version of GPC does not help, I would recommend creating a very small test program that initializes the set with only 0..63. Compile with "gpc -S" and examine the resulting assembler code to see if you can spot the error and report your results back to the list.
Does my thinking make any sense to you?
Yes it does. Unfortunately, I do not use any 64-bit machines, so I cannot test this problem (nor do I understand DEC Alpha assembler). Therefore, unless Frank Heckenbach has a 64-bit system available, we need you to help us determine what the problem is.
-- Dave
On Tue, 6 Nov 2001, J. David Bryan wrote:
David, Mr. Frank Heckenbach,
Maybe it has something to do with the fact that I run GPC on Alpha 64-bit processor?
Perhaps. First, though, I would upgrade to the latest GPC release (20010924), as this may have been a bug that has now been fixed.
I took some effort to investigate on this: I've rebuilt GPC, both on Ultra1/Solaris7 and Alpha/DU4.0b:
% gpc -v Reading specs from /usr/local/lib/gcc-lib/alpha-dec-osf4.0b/2.95.2/specs gpc version 20010924, based on 2.95.2 19991024 (release)
Both are 64 bit processors (but I'm not sure whether gcc on Solaris was built to be true 64-bit compiler!) - and on Solaris prime numbers with sieve of Erastothenes test passed!!! (While on DEC Alpha/osf4.0b (patched) it still miserably fails).
This could have been caused by the fact that SET is represented by a 64-bit bit-field, and upper 32 bits of each bit field are treated wrong way...
Yes, that is very possible. If upgrading to the latest version of GPC does not help, I would recommend creating a very small test program that initializes the set with only 0..63. Compile with "gpc -S" and examine the resulting assembler code to see if you can spot the error and report your results back to the list.
OK, I tried isolate bug by minimizing the example (even switching from automatic set construction to ``Include'' didn't make it work!):
--- marvin00.pas: ------------------------------------------------------- PROGRAM settest00(input,output); {Test of SET construction; known to fail on alpha-dec-osf4.0b?!?}
CONST maxN = 255; VAR a_set: SET OF 0..maxN;
BEGIN {a_set := a_set + [33];} Include (a_set, 33); {neither works!}
IF (NOT(33 IN a_set)) THEN writeln('Failed: 33 NOT IN SET after putting it IN!') ELSE writeln('OK');
END. --------------------------------------------------------------------------
You will probably guess that even this simple example on my Alpha fails.
Does my thinking make any sense to you?
Yes it does. Unfortunately, I do not use any 64-bit machines, so I cannot test this problem (nor do I understand DEC Alpha assembler). Therefore, unless Frank Heckenbach has a 64-bit system available, we need you to help us determine what the problem is.
Unfortunatelly, I'm not an expert on DEC alpha assembler either, yet I will give the marvin00.s here just in case somebody reading the list *is*, later on ... Anyway, by surface analisys of the listing it seemed to me that it will not show much, since it just calls _p_set_include and _p_set_in (these are as I suspect probably in RTL library?) ...
Anyway - if I could be of more help (even including giving you access to our Alpha machine) - I'm very interrested in this SET feature in PASCAL, I think it's a great thing!!!
Also, if that may help, I've defined -DEGCS95 while compiling (I think that last time it did not compile without defining no -DEGCS....). Then again, I've used the same -DEGCS95 on Solaris and it works ...
Regards to all, Mirsad
--- marvin00.s:----------------------------------------------------------- .verstamp 3 11 .set noreorder .set volatile .set noat .arch ev4 .file 1 "marvin00.pas" .lcomm A_set,32 .rdata .quad 0 $LC0: .ascii "Failed: 33 NOT IN SET after putting it IN!\0" $LC1: .ascii "OK\0" .text .align 5 .globl pascal_main_program .ent pascal_main_program pascal_main_program: .frame $15,32,$26,0 .mask 0x4008000,-16 ldgp $29,0($27) $pascal_main_program..ng: lda $30,-32($30) stq $26,16($30) stq $15,24($30) mov $30,$15 .prologue 1 lda $16,A_set mov $31,$17 lda $18,255 lda $19,33 jsr $26,_p_set_include ldgp $29,0($26) lda $16,A_set mov $31,$17 lda $18,255 lda $19,33 jsr $26,_p_set_in ldgp $29,0($26) mov $0,$1 bne $1,$L3 lda $1,22 stq $1,0($30) lda $16,_p_stdout lda $17,384 lda $18,2 lda $19,17 lda $20,$LC0 lda $21,42 jsr $26,_p_write ldgp $29,0($26) lda $1,_p_InOutRes ldl $2,0($1) beq $2,$L4 jsr $26,_p_check_inoutres ldgp $29,0($26) $L4: br $31,$L5 $L3: lda $1,22 stq $1,0($30) lda $16,_p_stdout lda $17,384 lda $18,2 lda $19,17 lda $20,$LC1 lda $21,2 jsr $26,_p_write ldgp $29,0($26) lda $1,_p_InOutRes ldl $2,0($1) beq $2,$L5 jsr $26,_p_check_inoutres ldgp $29,0($26) $L6: $L5: $L2: mov $15,$30 ldq $26,16($30) ldq $15,24($30) lda $30,32($30) ret $31,($26),1 .end pascal_main_program .data ctor_run_condition_0.4: .byte 1 .text .align 5 .globl init_pascal_main_program .ent init_pascal_main_program init_pascal_main_program: .frame $15,16,$26,0 .mask 0x4008000,-16 ldgp $29,0($27) $init_pascal_main_program..ng: lda $30,-16($30) stq $26,0($30) stq $15,8($30) mov $30,$15 .prologue 1 lda $2,ctor_run_condition_0.4 ldq_u $1,0($2) extbl $1,$2,$3 and $3,0xff,$1 beq $1,$L8 lda $1,ctor_run_condition_0.4 mov $31,$2 ldq_u $3,0($1) mov $1,$4 mskbl $3,$4,$3 insbl $2,$4,$2 bis $2,$3,$2 stq_u $2,0($1) lda $16,fini_pascal_main_program jsr $26,_p_atexit ldgp $29,0($26) $L8: $L7: mov $15,$30 ldq $26,0($30) ldq $15,8($30) lda $30,16($30) ret $31,($26),1 .end init_pascal_main_program .align 5 .globl fini_pascal_main_program .ent fini_pascal_main_program fini_pascal_main_program: .frame $15,16,$26,0 .mask 0x4008000,-16 $fini_pascal_main_program..ng: lda $30,-16($30) stq $26,0($30) stq $15,8($30) mov $30,$15 .prologue 0 $L9: mov $15,$30 ldq $26,0($30) ldq $15,8($30) lda $30,16($30) ret $31,($26),1 .end fini_pascal_main_program .align 5 .globl main .ent main main: .frame $15,48,$26,0 .mask 0x4008000,-48 ldgp $29,0($27) $main..ng: lda $30,-48($30) stq $26,0($30) stq $15,8($30) mov $30,$15 .prologue 1 mov $16,$1 stq $17,24($15) stq $18,32($15) stl $1,16($15) ldl $1,16($15) mov $1,$16 ldq $17,24($15) ldq $18,32($15) jsr $26,_p_initialize ldgp $29,0($26) jsr $26,init_pascal_main_program ldgp $29,0($26) jsr $26,pascal_main_program ldgp $29,0($26) jsr $26,_p_finalize ldgp $29,0($26) mov $31,$0 br $31,$L10 $L10: mov $15,$30 ldq $26,0($30) ldq $15,8($30) lda $30,48($30) ret $31,($26),1 .end main ------------------------------------------------------------------------ -- This message has been made up using recycled ideas and language constructs. No plant or animal has been injured in process of making this message.
Mirsad Todorovac wrote:
I took some effort to investigate on this: I've rebuilt GPC, both on Ultra1/Solaris7 and Alpha/DU4.0b:
Both are 64 bit processors (but I'm not sure whether gcc on Solaris was built to be true 64-bit compiler!) -
If you want to know, you can output `SizeOf (Pointer)', `SizeOf (Integer)' and `SizeOf (MedInt)' (or in C: `sizeof (void *)', `sizeof (int)' and `sizeof (long)').
and on Solaris prime numbers with sieve of Erastothenes test passed!!! (While on DEC Alpha/osf4.0b (patched) it still miserably fails).
OK, I tried isolate bug by minimizing the example (even switching from automatic set construction to ``Include'' didn't make it work!):
[...]
You will probably guess that even this simple example on my Alpha fails.
Thanks. I'm putting your programs in the test suite (mirsad[12].pas).
Does my thinking make any sense to you?
Yes it does. Unfortunately, I do not use any 64-bit machines, so I cannot test this problem (nor do I understand DEC Alpha assembler). Therefore, unless Frank Heckenbach has a 64-bit system available, we need you to help us determine what the problem is.
Unfortunatelly, I'm not an expert on DEC alpha assembler either, yet I will give the marvin00.s here just in case somebody reading the list *is*, later on ...
Not me (though it doesn't look quite as strange to me as AIX assembler, so maybe if I take some time, I could make some sense out of it ...).
Anyway, by surface analisys of the listing it seemed to me that it will not show much, since it just calls _p_set_include and _p_set_in (these are as I suspect probably in RTL library?) ...
Yes, more precisely in p/rts/sets.pas
Anyway - if I could be of more help (even including giving you access to our Alpha machine) -
Indeed, it would be very helpful if you could give me an account and somme disk space. I have a few ideas what could be wrong, and it's probably easier if I can test them on the actual machine, than each time asking you to do it and send me the results ...
It might be related to endianness, and at the moment I'm quite confident that it will be rather easy to fix.
I'm very interrested in this SET feature in PASCAL, I think it's a great thing!!!
BTW, I've just fixed a few other bugs with sets, so you should wait for the next release, anyway, before using them seriously.
Also, if that may help, I've defined -DEGCS95 while compiling (I think that last time it did not compile without defining no -DEGCS....). Then again, I've used the same -DEGCS95 on Solaris and it works ...
Usually configure will detect the version automatically and write it into gcc-version.h, so one doesn't have to give any of these flags manually. However, there was a bug in it when using non-GNU grep. It was fixed before 20010924, but after 20010315.
Frank
On Fri, 9 Nov 2001, Frank Heckenbach wrote:
Both are 64 bit processors (but I'm not sure whether gcc on Solaris was built to be true 64-bit compiler!) -
If you want to know, you can output `SizeOf (Pointer)', `SizeOf (Integer)' and `SizeOf (MedInt)' (or in C: `sizeof (void *)', `sizeof (int)' and `sizeof (long)').
OK, here are the results:
Alpha Sparc Sizeof(Pointer) 8 4 Sizeof(Integer) 4 4 Sizeof(MedInt) 8 4
Thanks. I'm putting your programs in the test suite (mirsad[12].pas).
That's great! I thought of making some more thorough verifications of proper working of SETs, yet I wonder how much time is acceptable for a single test to last?
[...]
Anyway, by surface analisys of the listing it seemed to me that it will not show much, since it just calls _p_set_include and _p_set_in (these are as I suspect probably in RTL library?) ...
Yes, more precisely in p/rts/sets.pas
Insightful remark :-) ... Though on one glance I've no idea what might went wrong ...
Anyway - if I could be of more help (even including giving you access to our Alpha machine) -
Indeed, it would be very helpful if you could give me an account and somme disk space. I have a few ideas what could be wrong, and it's probably easier if I can test them on the actual machine, than each time asking you to do it and send me the results ...
It might be related to endianness, and at the moment I'm quite confident that it will be rather easy to fix.
OK. Whould 2GB be enough disk space (I don't think I can provide more at the moment, but you will not have quotas - so help yourself).
I'm very interrested in this SET feature in PASCAL, I think it's a great thing!!!
BTW, I've just fixed a few other bugs with sets, so you should wait for the next release, anyway, before using them seriously.
I'm hoping to chase out most possible bugs from SETs with my extensive tests, which would test if SETs really behave on system as we take for granted.
Also, if that may help, I've defined -DEGCS95 while compiling (I think that last time it did not compile without defining no -DEGCS....). Then again, I've used the same -DEGCS95 on Solaris and it works ...
Usually configure will detect the version automatically and write it into gcc-version.h, so one doesn't have to give any of these flags manually. However, there was a bug in it when using non-GNU grep. It was fixed before 20010924, but after 20010315.
OK. Taken for notice. I remember having problems with May verison of GPC and EGCS defines. Right now I've noticed that GPC doesn't compile well when -DEGCS97 is set on Solaris (with 20010924 version). I had to recompile everything from scratch with -DEGCS97, since I was not sure which moules should be recompiled and which not (young Zaphod plays it safe - they say :-) ) ...
Mirsad
-- This message has been made up using recycled ideas and language constructs. No plant or animal has been injured in process of making this message.
Mirsad Todorovac wrote:
OK, here are the results:
Alpha SparcSizeof(Pointer) 8 4 Sizeof(Integer) 4 4 Sizeof(MedInt) 8 4
So the Sparc compiler is 32 bit, and the problem is likely to be 64 bit specific (and I have reason to assume, also dependent on the endianness).
Thanks. I'm putting your programs in the test suite (mirsad[12].pas).
That's great! I thought of making some more thorough verifications of proper working of SETs, yet I wonder how much time is acceptable for a single test to last?
You mean run time in the test suite? Well, as much as is necessary ... I've written some tests that run quite for a while. But, of course, the shorter the better (i.e., the prime number sieve is quite a bit of overhead for a test of sets, but on a range of up to 255, it's short enough to be unnoticeable; but if for some reason you'd do it with a larger range, a simpler test algorithm would be preferable). But if the time is spent testing many different situations where problems might occur, it's certainly worth it.
Anyway - if I could be of more help (even including giving you access to our Alpha machine) -
Indeed, it would be very helpful if you could give me an account and somme disk space. I have a few ideas what could be wrong, and it's probably easier if I can test them on the actual machine, than each time asking you to do it and send me the results ...
It might be related to endianness, and at the moment I'm quite confident that it will be rather easy to fix.
OK. Whould 2GB be enough disk space (I don't think I can provide more at the moment, but you will not have quotas - so help yourself).
That's far more than enough. Usually, GCC/GPC builds, including source, take around 150 MB (very roughly, don't remember exactly). On a 64 bit platform, the objects and executables might be somewhat larger, but certainly far below a GB.
The account you gave me is working for me, and I think I'll test (and hopefully fix) GPC on it next week.
Also, if that may help, I've defined -DEGCS95 while compiling (I think that last time it did not compile without defining no -DEGCS....). Then again, I've used the same -DEGCS95 on Solaris and it works ...
Usually configure will detect the version automatically and write it into gcc-version.h, so one doesn't have to give any of these flags manually. However, there was a bug in it when using non-GNU grep. It was fixed before 20010924, but after 20010315.
OK. Taken for notice. I remember having problems with May verison of GPC and EGCS defines.
Yes. The date is was fixed was 20010713.
Right now I've noticed that GPC doesn't compile well when -DEGCS97 is set on Solaris (with 20010924 version). I had to recompile everything from scratch with -DEGCS97,
With or without? AFAIK, EGCS97 should never be defined -- this port is still unfinished (and probably never will be finished since when Peter works on it again, he'll go directly for 3.0 I suppose).
Frank
On Fri, 9 Nov 2001, Frank Heckenbach wrote:
So the Sparc compiler is 32 bit, and the problem is likely to be 64 bit specific (and I have reason to assume, also dependent on the endianness).
I guess so. I've tried to "see through" the code in p/rts/sets.pas, but it's not that obvious what could be the problem ...
That's great! I thought of making some more thorough verifications of proper working of SETs, yet I wonder how much time is acceptable for a single test to last?
You mean run time in the test suite? Well, as much as is necessary ... I've written some tests that run quite for a while. But, of course, the shorter the better (i.e., the prime number sieve is quite a bit of overhead for a test of sets, but on a range of up to 255, it's short enough to be unnoticeable; but if for some reason you'd do it with a larger range, a simpler test algorithm would be preferable). But if the time is spent testing many different situations where problems might occur, it's certainly worth it.
I understand. Do you think tests mirsad0[2345].pas I've attached in previous email to the list are acceptable?
That's far more than enough. Usually, GCC/GPC builds, including source, take around 150 MB (very roughly, don't remember exactly). On a 64 bit platform, the objects and executables might be somewhat larger, but certainly far below a GB.
The account you gave me is working for me, and I think I'll test (and hopefully fix) GPC on it next week.
I'm glad to be of help, for such a great project. However, other idea came to me the other moment when I've been looking at *i18n* efforts of KDE desktop team on Linux: have you ever considered translating manuals to languages other than German and English, such as Croatian?
[...]
Right now I've noticed that GPC doesn't compile well when -DEGCS97 is set on Solaris (with 20010924 version). I had to recompile everything from scratch with -DEGCS97,
With or without? AFAIK, EGCS97 should never be defined -- this port is still unfinished (and probably never will be finished since when Peter works on it again, he'll go directly for 3.0 I suppose).
It failed *with* -DEGCS97 defined (I naively tried to specify the highest EGCS define as the best). It reported a bunch of not declared identifiers, declared after #ifndef EGCS97 in gpc-tree.h:216 ... After moment of confusion I've switched to -DEGCS95 and recompiled from scratch (partial recompile with changed defines was too risky).
It's a great thing if it now works automagically!
mirsad
-- This message has been made up using recycled ideas and language constructs. No plant or animal has been injured in process of making this message.
Mirsad Todorovac wrote:
I understand. Do you think tests mirsad0[2345].pas I've attached in previous email to the list are acceptable?
Certainly. They take about 5 seconds in total (including compilation) on my machine. That's a little above average, but still way below critical.
That's far more than enough. Usually, GCC/GPC builds, including source, take around 150 MB (very roughly, don't remember exactly). On a 64 bit platform, the objects and executables might be somewhat larger, but certainly far below a GB.
The account you gave me is working for me, and I think I'll test (and hopefully fix) GPC on it next week.
I'm glad to be of help, for such a great project. However, other idea came to me the other moment when I've been looking at *i18n* efforts of KDE desktop team on Linux: have you ever considered translating manuals to languages other than German and English, such as Croatian?
Not really. Even the German translation has not proceeded very far yet. But it's just a matter of people how want to do it. If you and/or other Croatian speakers would like to start a translation, we can certainly give you technical advice when needed, set up a directory structure to put it in, etc.
It failed *with* -DEGCS97 defined (I naively tried to specify the highest EGCS define as the best). It reported a bunch of not declared identifiers, declared after #ifndef EGCS97 in gpc-tree.h:216 ... After moment of confusion I've switched to -DEGCS95 and recompiled from scratch (partial recompile with changed defines was too risky).
It's a great thing if it now works automagically!
(It should have worked automatically all the time. It was just a temporary bug that prevented it.)
Last message was intended for the gpc@gnu.de list, yet "reply" in PINE sets automatically to the sender and I forgot to switch :-( ...
I'm replying to the list.
Frank
Frank Heckenbach wrote:
... snip ...
Last message was intended for the gpc@gnu.de list, yet "reply" in PINE sets automatically to the sender and I forgot to switch :-( ...
I'm replying to the list.
Can't you make the list software insert a 'Reply-to:' header on distribution?
-
CBFalconer -
Frank Heckenbach -
J. David Bryan -
Mirsad Todorovac