Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #28006 > unrolled thread
| Started by | Mark Wills <markrobertwills@yahoo.co.uk> |
|---|---|
| First post | 2014-01-22 13:52 -0800 |
| Last post | 2014-01-26 01:59 +0100 |
| Articles | 20 on this page of 412 — 34 participants |
Back to article view | Back to comp.lang.forth
CASE mis-understanding? Mark Wills <markrobertwills@yahoo.co.uk> - 2014-01-22 13:52 -0800
Re: CASE mis-understanding? stephenXXX@mpeforth.com (Stephen Pelc) - 2014-01-22 21:57 +0000
Re: CASE mis-understanding? Mark Wills <markrobertwills@yahoo.co.uk> - 2014-01-22 14:10 -0800
Re: CASE mis-understanding? Mark Wills <markrobertwills@yahoo.co.uk> - 2014-01-22 14:11 -0800
Re: CASE mis-understanding? Coos Haak <chforth@hccnet.nl> - 2014-01-23 00:14 +0100
Re: CASE mis-understanding? "Elizabeth D. Rather" <erather@forth.com> - 2014-01-22 14:28 -1000
Re: CASE mis-understanding? "Ed" <invalid@invalid.com> - 2014-01-23 20:22 +1100
Re: CASE mis-understanding? Coos Haak <chforth@hccnet.nl> - 2014-01-23 12:34 +0100
Re: CASE mis-understanding? "Ed" <invalid@invalid.com> - 2014-01-25 22:44 +1100
Re: CASE mis-understanding? "Elizabeth D. Rather" <erather@forth.com> - 2014-01-25 08:49 -1000
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-01-25 19:40 -0800
Re: CASE mis-understanding? "Ed" <invalid@invalid.com> - 2014-01-26 23:01 +1100
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-23 03:43 -0600
Re: CASE mis-understanding? stephenXXX@mpeforth.com (Stephen Pelc) - 2014-01-23 10:10 +0000
Re: CASE mis-understanding? "gareth" <no.spam@thank.you.invalid> - 2014-01-23 10:31 +0000
Re: CASE mis-understanding? stephenXXX@mpeforth.com (Stephen Pelc) - 2014-01-23 11:35 +0000
Re: CASE mis-understanding? "gareth" <no.spam@thank.you.invalid> - 2014-01-23 13:27 +0000
Re: CASE mis-understanding? Mikael Nordman <oh2aun@gmail.com> - 2014-01-23 05:52 -0800
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-23 15:50 +0100
Re: CASE mis-understanding? Mark Wills <markrobertwills@yahoo.co.uk> - 2014-01-24 01:51 -0800
Re: CASE mis-understanding? Mark Wills <markrobertwills@yahoo.co.uk> - 2014-01-24 02:00 -0800
Re: CASE mis-understanding? Mark Wills <markrobertwills@yahoo.co.uk> - 2014-01-24 02:08 -0800
Re: CASE mis-understanding? Mark Wills <markrobertwills@yahoo.co.uk> - 2014-01-24 02:26 -0800
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-24 14:23 +0100
Re: CASE mis-understanding? Mark Wills <markrobertwills@yahoo.co.uk> - 2014-01-24 05:41 -0800
Re: CASE mis-understanding? "Ed" <invalid@invalid.com> - 2014-01-26 00:49 +1100
Re: CASE mis-understanding? Mikael Nordman <oh2aun@gmail.com> - 2014-01-26 03:01 -0800
Re: CASE mis-understanding? Mikael Nordman <oh2aun@gmail.com> - 2014-01-23 05:52 -0800
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-23 08:21 -0600
Re: CASE mis-understanding? BF <foxaudioresearch@gmail.com> - 2014-01-23 06:54 -0800
Re: CASE mis-understanding? "Alex McDonald" <blog@rivadpm.com> - 2014-01-23 16:00 +0000
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-01-23 20:21 -0800
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-01-23 20:33 -0800
Re: CASE mis-understanding? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-01-24 04:33 -0500
Re: CASE mis-understanding? "WJ" <w_a_x_man@yahoo.com> - 2014-03-10 23:14 +0000
Re: CASE mis-understanding? Ron Aaron <rambamist@gmail.com> - 2014-01-24 10:49 +0200
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-24 03:26 -0600
Re: CASE mis-understanding? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-01-24 04:25 -0500
Re: CASE mis-understanding? "Ed" <invalid@invalid.com> - 2014-01-27 22:09 +1100
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-01-28 22:38 -0800
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-01-23 03:22 -0800
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-23 06:52 -0600
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-23 16:03 +0100
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-23 10:14 -0600
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-23 17:42 +0000
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-01-23 10:42 -0800
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-24 15:01 +0100
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-23 17:21 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-23 12:16 -0600
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-24 09:25 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-24 07:16 -0600
Re: CASE mis-understanding? Mark Wills <markrobertwills@yahoo.co.uk> - 2014-01-24 05:43 -0800
Re: CASE mis-understanding? mhx@iae.nl - 2014-01-24 10:57 -0800
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-25 03:58 -0600
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-27 17:24 +0000
Re: CASE mis-understanding? stephenXXX@mpeforth.com (Stephen Pelc) - 2014-01-27 19:25 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-28 03:34 -0600
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-24 14:50 +0100
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-27 17:15 +0000
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-01-24 21:00 -0800
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-01-25 20:47 -0800
Re: CASE mis-understanding? "WJ" <w_a_x_man@yahoo.com> - 2014-03-10 23:36 +0000
Re: CASE mis-understanding? m.a.m.hendrix@tue.nl - 2014-01-24 00:44 -0800
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-24 09:20 +0000
Re: CASE mis-understanding? stephenXXX@mpeforth.com (Stephen Pelc) - 2014-01-23 10:02 +0000
Re: CASE mis-understanding? Elizabeth D Rather <erather@forth.com> - 2014-01-23 09:05 -1000
Re: CASE mis-understanding? "Ed" <invalid@invalid.com> - 2014-01-27 00:43 +1100
Re: CASE mis-understanding? stephenXXX@mpeforth.com (Stephen Pelc) - 2014-01-26 18:04 +0000
Re: CASE mis-understanding? mhx@iae.nl - 2014-01-26 11:27 -0800
Re: CASE mis-understanding? Coos Haak <chforth@hccnet.nl> - 2014-01-26 22:09 +0100
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-26 15:35 -0600
Re: CASE mis-understanding? "Ed" <invalid@invalid.com> - 2014-01-29 01:57 +1100
Re: CASE mis-understanding? mhx@iae.nl - 2014-01-28 13:46 -0800
Re: CASE mis-understanding? "Elizabeth D. Rather" <erather@forth.com> - 2014-01-28 12:12 -1000
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-30 17:19 +0000
Re: CASE mis-understanding? "Ed" <invalid@invalid.com> - 2014-02-01 00:40 +1100
Re: CASE mis-understanding? Mark Wills <markrobertwills@yahoo.co.uk> - 2014-01-31 06:33 -0800
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-31 12:13 -0600
Re: CASE mis-understanding? "Elizabeth D. Rather" <erather@forth.com> - 2014-01-31 08:36 -1000
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-02-01 00:06 -0800
Re: CASE mis-understanding? stephenXXX@mpeforth.com (Stephen Pelc) - 2014-01-31 15:34 +0000
Re: CASE mis-understanding? "Ed" <invalid@invalid.com> - 2014-02-03 16:18 +1100
Re: CASE mis-understanding? mhx@iae.nl - 2014-02-01 03:17 -0800
Re: CASE mis-understanding? "Alex McDonald" <blog@rivadpm.com> - 2014-02-02 13:10 +0000
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-02 16:06 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-02 10:43 -0600
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-02-02 18:39 +0100
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-03 14:18 +0000
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-02-02 18:49 -0800
Re: CASE mis-understanding? "Alex McDonald" <blog@rivadpm.com> - 2014-02-03 09:35 +0000
Re: CASE mis-understanding? Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2014-02-03 09:56 +0000
Re: CASE mis-understanding? m.a.m.hendrix@tue.nl - 2014-02-03 02:50 -0800
Re: CASE mis-understanding? Mark Wills <markrobertwills@yahoo.co.uk> - 2014-02-03 03:17 -0800
Re: CASE mis-understanding? "Alex McDonald" <blog@rivadpm.com> - 2014-02-03 14:31 +0000
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-02-03 19:17 -0800
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-02-04 12:23 +0000
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-02-03 19:26 -0800
Re: CASE mis-understanding? "Alex McDonald" <blog@rivadpm.com> - 2014-02-04 08:05 +0000
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-02-02 19:07 -0800
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-30 15:59 +0000
Re: CASE mis-understanding? Coos Haak <chforth@hccnet.nl> - 2014-01-31 02:34 +0100
Re: CASE mis-understanding? Coos Haak <chforth@hccnet.nl> - 2014-01-31 02:38 +0100
Re: CASE mis-understanding? "Elizabeth D. Rather" <erather@forth.com> - 2014-01-30 15:51 -1000
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-03 14:58 +0000
Re: CASE mis-understanding? mhx@iae.nl - 2014-02-03 12:06 -0800
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-09 15:04 +0000
Re: CASE mis-understanding? mhx@iae.nl - 2014-02-09 10:56 -0800
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-10 15:58 +0000
Re: CASE mis-understanding? mhx@iae.nl - 2014-02-10 12:06 -0800
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-11 11:22 +0000
Re: CASE mis-understanding? m.a.m.hendrix@tue.nl - 2014-02-11 05:23 -0800
Re: CASE mis-understanding? mhx@iae.nl - 2014-02-12 10:54 -0800
Re: CASE mis-understanding? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-02-10 18:12 -0500
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-10 05:13 -0600
Re: CASE mis-understanding? "Alex McDonald" <blog@rivadpm.com> - 2014-02-10 15:44 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-10 10:40 -0600
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-02-10 17:47 +0100
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-10 16:34 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-10 11:09 -0600
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-10 17:20 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-10 12:14 -0600
Re: CASE mis-understanding? stephenXXX@mpeforth.com (Stephen Pelc) - 2014-02-10 22:38 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-11 03:46 -0600
Re: CASE mis-understanding? stephenXXX@mpeforth.com (Stephen Pelc) - 2014-02-11 10:30 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-11 18:24 -0600
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-02-12 15:02 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-12 11:23 -0600
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-13 09:25 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-13 04:54 -0600
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-13 13:41 +0000
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-02-13 14:14 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-13 08:41 -0600
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-13 15:29 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-13 12:07 -0600
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-15 16:14 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-15 13:22 -0600
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-02-17 12:28 +0000
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-17 14:05 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-17 09:49 -0600
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-02-17 19:06 +0100
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-17 12:52 -0600
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-02-17 22:51 +0100
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-18 04:36 -0600
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-18 09:34 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-18 05:01 -0600
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-18 14:19 +0000
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-02-18 08:28 -0800
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-18 17:14 +0000
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-02-18 11:46 -0800
Re: CASE mis-understanding? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-02-18 18:20 -0500
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-02-19 17:10 +0100
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-02-19 23:17 -0800
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-20 09:55 -0600
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-02-21 20:15 +0100
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-22 12:08 +0000
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-02-22 14:45 -0800
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-02-23 02:29 +0100
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-02-22 21:29 -0800
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-02-23 22:33 +0100
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-02-23 22:13 -0800
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-24 17:30 +0000
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-02-24 14:38 -0800
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-26 12:59 +0000
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-02-26 20:12 -0800
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-27 04:54 -0600
Re: CASE mis-understanding? Lars Brinkhoff <lars.spam@nocrew.org> - 2014-02-27 12:56 +0100
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-27 06:30 -0600
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-02-27 05:29 -0800
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-02-27 15:48 +0000
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-02-27 08:13 -0800
Re: CASE mis-understanding? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-02-27 16:23 -0500
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-02-28 11:21 +0000
Re: CASE mis-understanding? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-02-28 16:20 -0500
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-03-01 01:51 +0000
Re: CASE mis-understanding? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-02-28 23:36 -0500
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-03-01 12:45 +0000
Re: CASE mis-understanding? Lars Brinkhoff <lars.spam@nocrew.org> - 2014-03-01 13:59 +0100
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-03-01 13:03 +0000
Re: CASE mis-understanding? "Alex McDonald" <blog@rivadpm.com> - 2014-03-01 07:53 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-27 10:12 -0600
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-02-27 08:46 -0800
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-27 10:56 -0600
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-02-27 10:08 -0800
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-02-27 11:01 -0800
Re: CASE mis-understanding? "Elizabeth D. Rather" <erather@forth.com> - 2014-02-27 08:12 -1000
Re: CASE mis-understanding? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-02-27 16:23 -0500
Re: CASE mis-understanding? Lars Brinkhoff <lars.spam@nocrew.org> - 2014-02-27 19:53 +0100
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-02-27 07:48 -0800
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-02-27 16:05 +0000
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-02-27 08:27 -0800
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-27 10:45 -0600
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-02-27 20:51 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-03-01 08:46 -0600
Re: CASE mis-understanding? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-03-01 16:53 -0500
Re: CASE mis-understanding? "Elizabeth D. Rather" <erather@forth.com> - 2014-03-01 15:06 -1000
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-03-04 01:50 +0100
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-03-03 17:18 -0800
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-03-04 02:51 +0100
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-03-04 03:20 -0600
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-03-04 19:12 -0800
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-03-05 03:51 -0600
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-03-04 10:11 +0000
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-03-05 14:09 +0100
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-03-01 11:20 -0800
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-03-01 15:43 -0600
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-03-01 22:16 -0800
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-03-02 04:56 -0600
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-03-02 14:07 +0000
Re: CASE mis-understanding? Mark Wills <markwills1970@gmail.com> - 2014-03-03 00:59 -0800
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-03-02 08:20 -0800
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-03-03 03:03 -0600
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-03-06 18:09 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-03-06 17:26 -0600
WITHIN (was: CASE mis-understanding?) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-03-07 12:51 +0000
Re: WITHIN Paul Rubin <no.email@nospam.invalid> - 2014-03-07 12:13 -0800
Re: WITHIN mhx@iae.nl - 2014-03-08 05:07 -0800
Re: WITHIN anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-03-08 15:43 +0000
Re: WITHIN mhx@iae.nl - 2014-03-08 08:23 -0800
Re: WITHIN anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-03-08 16:37 +0000
Re: WITHIN mhx@iae.nl - 2014-03-08 10:18 -0800
Re: WITHIN mhx@iae.nl - 2014-03-08 10:48 -0800
Re: WITHIN anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-03-08 16:02 +0000
Re: WITHIN Paul Rubin <no.email@nospam.invalid> - 2014-03-09 01:24 -0800
Re: WITHIN anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-03-09 18:16 +0000
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-03-06 21:46 -0800
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-03-07 09:22 +0000
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-03-07 12:28 +0000
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-03-07 19:36 +0000
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-03-06 18:25 +0000
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-03-06 23:52 -0800
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-03-07 10:15 +0000
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-03-07 08:38 -0800
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-03-07 09:36 -0800
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-03-02 20:16 -0800
Re: CASE mis-understanding? "Elizabeth D. Rather" <erather@forth.com> - 2014-02-27 08:18 -1000
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-03-07 13:21 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-03-07 08:26 -0600
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-27 10:37 -0600
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-03-01 11:31 -0800
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-03-07 13:18 +0000
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-03-07 11:17 -0800
Re: CASE mis-understanding? Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2014-03-09 20:49 +0000
Re: CASE mis-understanding? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-02-27 16:22 -0500
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-28 15:22 +0000
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-28 18:32 +0000
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-03-01 03:39 -0800
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-03-04 02:19 +0100
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-02-27 13:03 +0000
Re: CASE mis-understanding? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-02-24 01:25 -0500
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-24 03:36 -0600
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-02-24 02:04 -0800
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-03-04 01:15 +0100
Re: CASE mis-understanding? Julian Fondren <julian.fondren@gmail.com> - 2014-02-22 21:09 -0800
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-02-22 21:55 -0800
Re: CASE mis-understanding? Julian Fondren <julian.fondren@gmail.com> - 2014-02-23 00:47 -0800
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-02-23 01:45 -0800
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-20 17:07 +0000
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-02-20 16:03 -0800
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-21 04:11 -0600
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-02-21 10:59 +0000
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-02-21 03:26 -0800
Re: CASE mis-understanding? stephenXXX@mpeforth.com (Stephen Pelc) - 2014-02-21 10:34 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-21 05:49 -0600
Re: CASE mis-understanding? stephenXXX@mpeforth.com (Stephen Pelc) - 2014-02-22 13:52 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-22 09:13 -0600
Re: CASE mis-understanding? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-02-22 10:45 -0500
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-02-21 20:18 -0800
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-02-22 15:24 +0000
Re: CASE mis-understanding? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-02-22 10:37 -0500
Re: CASE mis-understanding? "WJ" <w_a_x_man@yahoo.com> - 2014-03-11 03:20 +0000
Re: CASE mis-understanding? "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-03-11 16:15 -0400
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-03-12 00:10 -0700
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-22 13:28 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-22 08:56 -0600
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-02-23 01:27 +0100
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-23 04:33 -0600
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-02-23 08:11 -0800
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-02-23 21:44 +0100
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-02-23 22:48 -0800
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-03-04 02:23 +0100
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-24 16:05 +0000
Re: CASE mis-understanding? Tristan Plumb <firth@trstn.net> - 2014-02-24 18:15 +0000
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-24 18:45 +0000
Re: CASE mis-understanding? Tristan Plumb <firth@trstn.net> - 2014-02-24 19:18 +0000
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-26 12:40 +0000
Re: CASE mis-understanding? Tristan Plumb <st@trstn.net> - 2014-02-26 15:27 +0000
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-03-04 01:31 +0100
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-03-04 16:30 +0000
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-03-05 11:48 +0000
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-02-22 18:28 -0800
Re: CASE mis-understanding? Gary Bergstrom <forthprgrmr@gmail.com> - 2014-02-24 08:39 -0800
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-02-24 21:29 -0800
Re: CASE mis-understanding? "WJ" <w_a_x_man@yahoo.com> - 2014-03-11 00:44 +0000
Re: CASE mis-understanding? "WJ" <w_a_x_man@yahoo.com> - 2014-03-11 00:45 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-23 04:35 -0600
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-18 12:31 -0600
Re: CASE mis-understanding? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-02-18 18:19 -0500
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-18 11:06 -0600
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-02-18 12:51 +0000
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-18 14:40 +0000
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-18 08:17 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-18 04:48 -0600
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-18 13:56 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-18 11:15 -0600
Re: CASE mis-understanding? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-02-18 18:24 -0500
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-19 03:46 -0600
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-21 15:52 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-22 09:10 -0600
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-02-18 13:09 +0000
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-18 15:03 +0000
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-02-13 15:53 -0800
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-02-14 00:39 +0100
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-14 06:38 -0600
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-15 15:37 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-15 13:33 -0600
Re: CASE mis-understanding? Roelf Toxopeus <rt4all@notthis.hetnet.nl> - 2014-02-11 10:50 +0100
Re: CASE mis-understanding? stephenXXX@mpeforth.com (Stephen Pelc) - 2014-02-11 10:57 +0000
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-02-11 02:35 -0800
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-11 11:47 +0000
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-11 13:08 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-11 18:42 -0600
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-12 10:54 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-12 05:31 -0600
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-12 15:52 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-12 10:41 -0600
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-13 09:27 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-13 04:49 -0600
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-13 13:54 +0000
Re: CASE mis-understanding? mhx@iae.nl - 2014-02-03 12:26 -0800
Re: CASE mis-understanding? "Ed" <invalid@invalid.com> - 2014-02-07 13:41 +1100
Re: CASE mis-understanding? m.a.m.hendrix@tue.nl - 2014-02-07 01:08 -0800
Re: CASE mis-understanding? "Ed" <invalid@invalid.com> - 2014-02-08 09:56 +1100
Re: CASE mis-understanding? "Alex McDonald" <blog@rivadpm.com> - 2014-02-07 12:15 +0000
Re: CASE mis-understanding? "Ed" <invalid@invalid.com> - 2014-02-01 00:39 +1100
Re: CASE mis-understanding? m.a.m.hendrix@tue.nl - 2014-01-31 07:29 -0800
Re: CASE mis-understanding? "Ed" <invalid@invalid.com> - 2014-02-04 23:45 +1100
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-31 16:31 +0000
Re: CASE mis-understanding? "Ed" <invalid@invalid.com> - 2014-02-03 12:35 +1100
Re: CASE mis-understanding? "Alex McDonald" <blog@rivadpm.com> - 2014-02-03 09:32 +0000
Re: CASE mis-understanding? "Ed" <invalid@invalid.com> - 2014-02-08 09:31 +1100
Re: CASE mis-understanding? "Alex McDonald" <blog@rivadpm.com> - 2014-02-08 11:22 +0000
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-03 13:54 +0000
Re: CASE mis-understanding? "Elizabeth D. Rather" <erather@forth.com> - 2014-01-31 08:40 -1000
Re: CASE mis-understanding? Mikael Nordman <oh2aun@gmail.com> - 2014-01-26 22:03 -0800
Re: CASE mis-understanding? julian.fondren@gmail.com - 2014-01-29 17:19 -0800
Re: CASE mis-understanding? Mikael Nordman <oh2aun@gmail.com> - 2014-01-30 11:15 -0800
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-27 13:57 +0000
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-01-28 14:01 +0000
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-01-28 14:49 +0000
Re: CASE mis-understanding? "Ed" <invalid@invalid.com> - 2014-01-29 10:07 +1100
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-01-28 21:54 -0800
Re: CASE mis-understanding? Stefan Mauerhofer <smauerhofer@androsoft.ch> - 2014-01-29 00:33 -0800
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-29 03:37 -0600
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-01-30 21:51 -0800
Re: CASE mis-understanding? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-01-31 18:44 -0500
Re: CASE mis-understanding? David Thompson <dave.thompson2@verizon.net> - 2014-02-09 00:34 -0500
Re: CASE mis-understanding? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-02-09 22:14 -0500
Re: CASE mis-understanding? "WJ" <w_a_x_man@yahoo.com> - 2014-03-11 01:25 +0000
Re: CASE mis-understanding? Julian Fondren <julian.fondren@gmail.com> - 2014-01-31 17:44 -0800
Re: CASE mis-understanding? "Elizabeth D. Rather" <erather@forth.com> - 2014-01-31 16:03 -1000
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-02-01 01:55 -0800
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-02-01 11:34 +0000
Re: CASE mis-understanding? "Elizabeth D. Rather" <erather@forth.com> - 2014-02-01 08:11 -1000
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-02-02 14:28 +0000
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-02-02 18:28 -0800
Re: CASE mis-understanding? "Ed" <invalid@invalid.com> - 2014-02-07 13:34 +1100
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-02-07 03:52 +0100
Re: CASE mis-understanding? "Ed" <invalid@invalid.com> - 2014-02-08 09:41 +1100
Re: CASE mis-understanding? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-02-07 18:33 -0500
Re: CASE mis-understanding? Coos Haak <chforth@hccnet.nl> - 2014-02-08 00:31 +0100
Re: CASE mis-understanding? "Alex McDonald" <blog@rivadpm.com> - 2014-02-08 11:21 +0000
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-02-08 15:03 +0100
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-02-08 19:58 -0800
Re: CASE mis-understanding? "Alex McDonald" <blog@rivadpm.com> - 2014-02-09 08:33 +0000
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-02-09 19:50 -0800
Re: CASE mis-understanding? "Alex McDonald" <blog@rivadpm.com> - 2014-02-10 08:42 +0000
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-02-13 16:32 -0800
Re: CASE mis-understanding? Coos Haak <chforth@hccnet.nl> - 2014-02-14 02:36 +0100
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-02-13 23:04 -0800
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-02-13 23:40 -0800
Re: CASE mis-understanding? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-02-14 04:37 -0500
Re: CASE mis-understanding? "Elizabeth D. Rather" <erather@forth.com> - 2014-02-14 09:42 -1000
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-02-15 16:52 -0800
Re: CASE mis-understanding? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-02-16 07:46 -0500
Re: CASE mis-understanding? "Elizabeth D. Rather" <erather@forth.com> - 2014-02-16 08:11 -1000
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-02-16 16:15 -0800
Re: CASE mis-understanding? Lars Brinkhoff <lars.spam@nocrew.org> - 2014-02-17 09:03 +0100
Re: CASE mis-understanding? "Elizabeth D. Rather" <erather@forth.com> - 2014-02-16 22:12 -1000
Re: CASE mis-understanding? m.a.m.hendrix@tue.nl - 2014-02-17 02:29 -0800
Re: CASE mis-understanding? Alex McDonald <blog@rivadpm.com> - 2014-02-17 04:27 -0800
Re: CASE mis-understanding? "Elizabeth D. Rather" <erather@forth.com> - 2014-02-17 09:36 -1000
Re: CASE mis-understanding? "Elizabeth D. Rather" <erather@forth.com> - 2014-02-17 09:22 -1000
Re: CASE mis-understanding? Alex McDonald <blog@rivadpm.com> - 2014-02-17 12:06 -0800
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-02-17 20:18 -0800
Re: CASE mis-understanding? "WJ" <w_a_x_man@yahoo.com> - 2014-03-11 01:48 +0000
Re: CASE mis-understanding? "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-03-11 16:10 -0400
Re: CASE mis-understanding? "Alex McDonald" <blog@rivadpm.com> - 2014-02-14 13:54 +0000
Re: CASE mis-understanding? "Elizabeth D. Rather" <erather@forth.com> - 2014-02-06 17:03 -1000
Re: CASE mis-understanding? "Ed" <invalid@invalid.com> - 2014-02-08 09:39 +1100
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-02-07 20:12 -0800
Re: CASE mis-understanding? "Alex McDonald" <blog@rivadpm.com> - 2014-02-09 21:33 +0000
Re: CASE mis-understanding? Mark Wills <markrobertwills@yahoo.co.uk> - 2014-01-24 02:38 -0800
Re: CASE mis-understanding? Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2014-01-24 16:17 +0000
Re: CASE mis-understanding? Mark Wills <markrobertwills@yahoo.co.uk> - 2014-01-24 08:54 -0800
Re: CASE mis-understanding? "Elizabeth D. Rather" <erather@forth.com> - 2014-01-24 09:25 -1000
Re: CASE mis-understanding? Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2014-01-24 20:34 +0000
Re: CASE mis-understanding? "Elizabeth D. Rather" <erather@forth.com> - 2014-01-24 11:13 -1000
Re: CASE mis-understanding? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-01-24 17:39 -0500
Re: CASE mis-understanding? Mark Wills <markrobertwills@yahoo.co.uk> - 2014-01-24 16:05 -0800
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-01-25 11:46 +0000
Re: CASE mis-understanding? Mark Wills <markrobertwills@yahoo.co.uk> - 2014-01-25 16:15 -0800
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-26 01:59 +0100
Page 16 of 21 — ← Prev page 1 … 14 15 [16] 17 18 … 21 Next page →
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-02-18 08:17 +0000 |
| Message-ID | <2014Feb18.091715@mips.complang.tuwien.ac.at> |
| In reply to | #28500 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>Here's another question, to help me to understand your position: is a
>>>"proper optimization" allowed to change the behaviour of a program
>>>that writes to memory addresses outside that data space which has been
>>>allocated for its use? I'm guessing that the answer will be "yes",
>>>because one of the things an optimizer can do is reuse memory
>>>addresses so that a use is found for an unused region.
>>
>> I don't follow your justification, but I tend to yes, because most
>> programmers don't do that intentinally, and because such behaviour
>> tends to be pretty fragile anyway, and will break on many changes, not
>> just turning on optimization; so if somebody does that intentionally,
>> their best course may be to change as little as possible anyway.
>>
>>>>>By "miscompile" I understood "generate code that does something
>>>>>different". But now I see that for you "miscompile" doesn't mean
>>>>>that. It seems to mean "doesn't do any optimization that would
>>>>>surprise me."
>>>>
>>>> "Miscompile" means "generate code that behaves different from what
>>>> the programmer intended" (while the compiler generates code as
>>>> intended without optimization).
>>>
>>>This is is hard for me to distinguish from "doesn't do any
>>>optimization that would surprise me."
>>
>> It's not about you or me, but about the programmer who wrote the code.
>
>What's the difference? We're both programmers who writew code.
We may be surprised by different things. But if we both write
if (x>x+1) ...
we both don't intend that to be compiled to nothing. Ok, maybe you
would not write it. But you don't need to think about whether it
would surprise me to recognize that compiling that to nothing is
miscompilation (defined by intent, not by surprise).
>But how is anyone to determine what is a correct optimization, except
>by asking you for your opinion in each case? You don't offer any
>specification for what you require. You just declare people who don't
>share your intuitive understanding of programming language semantics
>to be wrong.
Richard Stallman got it right (and he did not ask me for my opinion),
so if you want a specification, just look at what the versions of gcc
he maintained did, what behaviour could change when you turned on
optimizations there, and if it cannot change there, better don't
change it.
>>>What does intentionality have to do with any of this? The writer of a
>>>compiler cannot know what a programmer's intentions were, or what
>>>side-effects of an implementation a programmer might have decided to
>>>utilize. Or is a compiler writer expected to guess what a "reasonable
>>>programmer" might do?
>>
>> Yes, and be pretty conservative about it.
>
>But "pretty conservative" is not a specification. That's my core
>point. There is no way to turn what you suggest into a specification
>that can be implemented. Somehow the compiler author has to guess
>about the knowledge level of the programmer. It is an impossible
>task, because the beginner is surprised by pretty much everything that
>a compiler does. So, a compiler author would have to guess about the
>knowledge level of their target audience, and aim low.
As I wrote, it's not about surprise, but about intent. If somebody
writes a loop with a termination condition, the intent is not to
produce an endless loop; and if you are unsure about that, the "be
conservative" part should help you make the right decision.
If somebody writes
if (x>x+1) ...
the intent is not to be equivalent to an empty statement. And if you
are unsure about that, the "be conservative" part should help you make
the right decision.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2013: http://www.euroforth.org/ef13/
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-02-18 04:48 -0600 |
| Message-ID | <hO2dnSk5W8n4p57OnZ2dnUVZ_qSdnZ2d@supernews.com> |
| In reply to | #28513 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>>>> >>>>> "Miscompile" means "generate code that behaves different from what >>>>> the programmer intended" (while the compiler generates code as >>>>> intended without optimization). >>>> >>>>This is is hard for me to distinguish from "doesn't do any >>>>optimization that would surprise me." >>> >>> It's not about you or me, but about the programmer who wrote the code. >> >>What's the difference? We're both programmers who write code. > > We may be surprised by different things. But if we both write > > if (x>x+1) ... > > we both don't intend that to be compiled to nothing. Ok, maybe you > would not write it. I sure wouldn't. I'd write if (x == INT_MAX) assuming that's what this bit of write-only nonsense is supposed to test. > But you don't need to think about whether it would surprise me to > recognize that compiling that to nothing is miscompilation (defined > by intent, not by surprise). I'm not going to define miscompilation by intent, because that requires compiler authors to be psychic. It's nice to be able to produce warnings in such cases, but it's usually in complex expressions and particularly inside macros that such stuff comes up, and it's really hard to avoid false positives. And programmers really hate false positives. >>But how is anyone to determine what is a correct optimization, except >>by asking you for your opinion in each case? You don't offer any >>specification for what you require. You just declare people who don't >>share your intuitive understanding of programming language semantics >>to be wrong. > > Richard Stallman got it right (and he did not ask me for my opinion), > so if you want a specification, just look at what the versions of gcc > he maintained did, what behaviour could change when you turned on > optimizations there, and if it cannot change there, better don't > change it. :-) > If somebody writes > > if (x>x+1) ... > > the intent is not to be equivalent to an empty statement. You can't say that for certain. The condition may be deep inside some complex expression involving machine-dependent macros, and the programmer may indeed intend the statement to be elided in this case. The programmer may be far more spohisticated than you think. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-02-18 13:56 +0000 |
| Message-ID | <2014Feb18.145659@mips.complang.tuwien.ac.at> |
| In reply to | #28516 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>>>>
>>>>>> "Miscompile" means "generate code that behaves different from what
>>>>>> the programmer intended" (while the compiler generates code as
>>>>>> intended without optimization).
>>>>>
>>>>>This is is hard for me to distinguish from "doesn't do any
>>>>>optimization that would surprise me."
>>>>
>>>> It's not about you or me, but about the programmer who wrote the code.
>>>
>>>What's the difference? We're both programmers who write code.
>>
>> We may be surprised by different things. But if we both write
>>
>> if (x>x+1) ...
>>
>> we both don't intend that to be compiled to nothing. Ok, maybe you
>> would not write it.
>
>I sure wouldn't. I'd write
>
>if (x == INT_MAX)
>
>assuming that's what this bit of write-only nonsense is supposed to
>test.
Try again. Note that x is not necessarily an int, but some signed
integer type (depends on the platform, which). So, how would you
write that?
Actually, something along these lines is what I resorted to, but the
generated code is bigger and probably slower on most platforms.
>> But you don't need to think about whether it would surprise me to
>> recognize that compiling that to nothing is miscompilation (defined
>> by intent, not by surprise).
>
>I'm not going to define miscompilation by intent, because that
>requires compiler authors to be psychic.
It doesn't.
>It's nice to be able to produce warnings in such cases, but it's
>usually in complex expressions and particularly inside macros that
>such stuff comes up, and it's really hard to avoid false positives.
>And programmers really hate false positives.
Sure, but that has not stopped gcc from spewing out lots of warnings
about unused variables, uses of uninitialized data, etc. After
several miscompiling versions, it even started warning about stuff
like x>x+1. And for programmers who don't like the warnings, there
are several ways to get rid of the warnings. E.g., if I used "-ansi
-pedantic", I would not expect warnings about optimizations based on
ANSI-undefined behaviour.
>> If somebody writes
>>
>> if (x>x+1) ...
>>
>> the intent is not to be equivalent to an empty statement.
>
>You can't say that for certain. The condition may be deep inside some
>complex expression involving machine-dependent macros, and the
>programmer may indeed intend the statement to be elided in this case.
If the programmer writes
if (x>x+1) ...
there are no macros involved, and the expression is not complex,
either.
But ok, let's assume that the programmer actually wrote a complex
expression that somehow resolved to x>x+1. If the programmer expects
that to evaluate to false in every case, he would be relying on a
particular interpretation of undefined behaviour, too, something that
according to C standards bigots should be punished by erasing the hard
disk. So I don't see that such a programmer has a case.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2013: http://www.euroforth.org/ef13/
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-02-18 11:15 -0600 |
| Message-ID | <Uf2dnWMnAq-CCJ7OnZ2dnUVZ_jWdnZ2d@supernews.com> |
| In reply to | #28524 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>>>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>>>>>> >>>>>>> "Miscompile" means "generate code that behaves different from what >>>>>>> the programmer intended" (while the compiler generates code as >>>>>>> intended without optimization). >>>>>> >>>>>>This is is hard for me to distinguish from "doesn't do any >>>>>>optimization that would surprise me." >>>>> >>>>> It's not about you or me, but about the programmer who wrote the code. >>>> >>>>What's the difference? We're both programmers who write code. >>> >>> We may be surprised by different things. But if we both write >>> >>> if (x>x+1) ... >>> >>> we both don't intend that to be compiled to nothing. Ok, maybe you >>> would not write it. >> >>I sure wouldn't. I'd write >> >>if (x == INT_MAX) >> >>assuming that's what this bit of write-only nonsense is supposed to >>test. > > Try again. Note that x is not necessarily an int, but some signed > integer type (depends on the platform, which). So, how would you > write that? What type is it? >>> If somebody writes >>> >>> if (x>x+1) ... >>> >>> the intent is not to be equivalent to an empty statement. >> >>You can't say that for certain. The condition may be deep inside some >>complex expression involving machine-dependent macros, and the >>programmer may indeed intend the statement to be elided in this case. > > If the programmer writes > > if (x>x+1) ... > > there are no macros involved, and the expression is not complex, > either. The optimizer does not know what that programmer wrote: that's long since gone. Maybe the programmer wrote something much more complex. But it's far more likely that this is somewhere in a loop, and the knowledge that overflow is undefined, and therefore cannot happen, allows induction variable substitution. > But ok, let's assume that the programmer actually wrote a complex > expression that somehow resolved to x>x+1. If the programmer > expects that to evaluate to false in every case, he would be relying > on a particular interpretation of undefined behaviour, too, > something that according to C standards bigots should be punished by > erasing the hard disk. I don't think anyone has said that, any more than any bigot thinks that someone touching a 25kV overhead line should be punished by death: it's a consequence, not a punishment. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> |
|---|---|
| Date | 2014-02-18 18:24 -0500 |
| Message-ID | <op.xbh3airn5zc71u@localhost> |
| In reply to | #28533 |
On Tue, 18 Feb 2014 12:15:11 -0500, Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: > I don't think anyone has said that, any more than any bigot thinks > that someone touching a 25kV overhead line should be punished by > death: it's a consequence, not a punishment. > I wonder, how exactly did someone come about to touching the overhead line? You didn't specify why it was touched ... Was he/she/it being forced to touch, chose to touch with free will, or accidentally touched, e.g., falling, etc.? It's clear that some are a consequence, and at least one is punishment. I.e., the logic of the example is questionable at best due to undefined behaviors, specifically, why someone touched the overhead line. As such, you can't conclude it was willful, and therefore a consequence. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-02-19 03:46 -0600 |
| Message-ID | <f8WdnTI7hPsU4JnOnZ2dnUVZ_rWdnZ2d@supernews.com> |
| In reply to | #28547 |
Rod Pemberton <dont_use_email@xnohavenotit.cnm> wrote: > On Tue, 18 Feb 2014 12:15:11 -0500, Andrew Haley > <andrew29@littlepinkcloud.invalid> wrote: > >> I don't think anyone has said that, any more than any bigot thinks >> that someone touching a 25kV overhead line should be punished by >> death: it's a consequence, not a punishment. > > I wonder, how exactly did someone come about to touching the > overhead line? > > You didn't specify why it was touched ... > > Was he/she/it being forced to touch, chose to touch with free will, > or accidentally touched, e.g., falling, etc.? > > It's clear that some are a consequence, and at least one is punishment. > > I.e., the logic of the example is questionable at best due to undefined > behaviors, specifically, why someone touched the overhead line. As such, > you can't conclude it was willful, and therefore a consequence. It's a consequence, whether wilful or not; that's my point. Volts don't care. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-02-21 15:52 +0000 |
| Message-ID | <2014Feb21.165253@mips.complang.tuwien.ac.at> |
| In reply to | #28533 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>>> We may be surprised by different things. But if we both write
>>>>
>>>> if (x>x+1) ...
>>>>
>>>> we both don't intend that to be compiled to nothing. Ok, maybe you
>>>> would not write it.
>>>
>>>I sure wouldn't. I'd write
>>>
>>>if (x == INT_MAX)
>>>
>>>assuming that's what this bit of write-only nonsense is supposed to
>>>test.
>>
>> Try again. Note that x is not necessarily an int, but some signed
>> integer type (depends on the platform, which). So, how would you
>> write that?
>
>What type is it?
As I wrote: "some signed integer type (depends on the platform,
which)". Your code?
>>>> If somebody writes
>>>>
>>>> if (x>x+1) ...
>>>>
>>>> the intent is not to be equivalent to an empty statement.
>>>
>>>You can't say that for certain. The condition may be deep inside some
>>>complex expression involving machine-dependent macros, and the
>>>programmer may indeed intend the statement to be elided in this case.
>>
>> If the programmer writes
>>
>> if (x>x+1) ...
>>
>> there are no macros involved, and the expression is not complex,
>> either.
>
>The optimizer does not know what that programmer wrote: that's long
>since gone. Maybe the programmer wrote something much more complex.
He did not. Ok, so your compiler does not remember that, but that's
not the programmer's fault.
I asked for a concrete case of this code coming out of macro expansion
or the like, and the programmer intending the if statement to be
optimized away, but your side has not produced such a case. I am sure
you know the name of this kind of rethoric trick.
>But it's far more likely that this is somewhere in a loop, and the
>knowledge that overflow is undefined, and therefore cannot happen,
>allows induction variable substitution.
This code was not in a loop, and no induction variable was involved.
>> But ok, let's assume that the programmer actually wrote a complex
>> expression that somehow resolved to x>x+1. If the programmer
>> expects that to evaluate to false in every case, he would be relying
>> on a particular interpretation of undefined behaviour, too,
>> something that according to C standards bigots should be punished by
>> erasing the hard disk.
>
>I don't think anyone has said that
Googling a little produced:
http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html:
|Beyond that, any undefined behavior in C gives license to the
|implementation (the compiler and runtime) to produce code that formats
|your hard drive [...]
http://c2.com/cgi/wiki?UndefinedBehavior:
|"That means compilers may generate code to do whatever they like:
|reformat your disk, send suggestive email to your boss, fax source
|code to your competitors, whatever." -- Scott Meyers, "Effective C++"
>any more than any bigot thinks
>that someone touching a 25kV overhead line should be punished by
>death: it's a consequence, not a punishment.
Makes you wonder why 25kV lines are placed in a way that makes it
pretty difficult to touch it, especially by accident. Even if the
relevant standards allowed to have such lines unisolated in, say 2m
height on inner city streets, it would still be a good idea to place
them in a way that makes it difficult to touch it.
Likewise, even though the C standard allows the compilers to do all
kinds of nonsense, and it would hit practically every C program,
compilers should refrain from doing so.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2013: http://www.euroforth.org/ef13/
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-02-22 09:10 -0600 |
| Message-ID | <vMOdnbgrS4BgIJXOnZ2dnUVZ_jqdnZ2d@supernews.com> |
| In reply to | #28662 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>>>> We may be surprised by different things. But if we both write >>>>> >>>>> if (x>x+1) ... >>>>> >>>>> we both don't intend that to be compiled to nothing. Ok, maybe you >>>>> would not write it. >>>> >>>>I sure wouldn't. I'd write >>>> >>>>if (x == INT_MAX) >>>> >>>>assuming that's what this bit of write-only nonsense is supposed to >>>>test. >>> >>> Try again. Note that x is not necessarily an int, but some signed >>> integer type (depends on the platform, which). So, how would you >>> write that? >> >>What type is it? > > As I wrote: "some signed integer type (depends on the platform, > which)". Your code? I don't think it's possible to do that in C unless you know the type. Maybe someone can think of one. >>The optimizer does not know what that programmer wrote: that's long >>since gone. Maybe the programmer wrote something much more complex. > > He did not. Ok, so your compiler does not remember that, but that's > not the programmer's fault. Indeed not, but that's how it is. > I asked for a concrete case of this code coming out of macro > expansion or the like, and the programmer intending the if statement > to be optimized away, but your side has not produced such a case. I > am sure you know the name of this kind of rethoric trick. No I don't, and I don't know what a "rethoric trick" is, either. The point is that a pass of a compiler doesn't know the form of the source code. Having said that, I suppose it would be possible to add extra code to distinguish cases such as a simple "if (i<i+1)" from more complex cases involving loops, and maybe this would be useful. It might be useful to produce an error mesage at runtime, so the programmer could correct their code. >>But it's far more likely that this is somewhere in a loop, and the >>knowledge that overflow is undefined, and therefore cannot happen, >>allows induction variable substitution. > > This code was not in a loop, and no induction variable was involved. Well, yes, but I'm sure you can follow the reasoning. >>> But ok, let's assume that the programmer actually wrote a complex >>> expression that somehow resolved to x>x+1. If the programmer >>> expects that to evaluate to false in every case, he would be relying >>> on a particular interpretation of undefined behaviour, too, >>> something that according to C standards bigots should be punished by >>> erasing the hard disk. >> >>I don't think anyone has said that > > Googling a little produced: > > http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html: > |Beyond that, any undefined behavior in C gives license to the > |implementation (the compiler and runtime) to produce code that formats > |your hard drive [...] You're not paying attention to what was written: it's a consequence, not a punshment. > Likewise, even though the C standard allows the compilers to do all > kinds of nonsense, and it would hit practically every C program, > compilers should refrain from doing so. You still refuse steadfastly to come up with any workable set of rules that distinguish "sense" from "nonsense". The only way to do so is "Ask Anton for his opinion". This is pure Alice In Wonderland stuff, where every word means only what you say it means. I repeat: you have provided no-one with any way to distinguish correct compliation from what you call "miscompilation". You have provided nothing that a compiler writer could use. And finally: you're complaining about the wrong people. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2014-02-18 13:09 +0000 |
| Message-ID | <53035b98$1$25275$e4fe514c@dreader34.news.xs4all.nl> |
| In reply to | #28513 |
In article <2014Feb18.091715@mips.complang.tuwien.ac.at>,
<SNIP>
>
>As I wrote, it's not about surprise, but about intent. If somebody
>writes a loop with a termination condition, the intent is not to
>produce an endless loop; and if you are unsure about that, the "be
>conservative" part should help you make the right decision.
>
>If somebody writes
>
>if (x>x+1) ...
>
>the intent is not to be equivalent to an empty statement. And if you
>are unsure about that, the "be conservative" part should help you make
>the right decision.
Sorry but I do.
If I write
if ( {expr1} > {expr2} )
and the optimising, inlining compiler discovers that expr1 is x and expr2
is x+1 , I want it to remove the dead code.
Remember this "if" can be part of a maze of twisty little conditions
that I as a human can not find my way in. Or it could be part of code
generated by lex and yacc.
How is the compiler to decide that this code has been written and
inspected by a human, instead of being intermediate or generated?
If you want to do your trick, I insist that you use a detour via
unsigned ints, which at the same time waves a big red flag
that something fishy is going on.
>
>- anton
>--
>M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-02-18 15:03 +0000 |
| Message-ID | <2014Feb18.160305@mips.complang.tuwien.ac.at> |
| In reply to | #28521 |
albert@spenarnc.xs4all.nl (Albert van der Horst) writes:
>In article <2014Feb18.091715@mips.complang.tuwien.ac.at>,
><SNIP>
>>
>>As I wrote, it's not about surprise, but about intent. If somebody
>>writes a loop with a termination condition, the intent is not to
>>produce an endless loop; and if you are unsure about that, the "be
>>conservative" part should help you make the right decision.
>>
>>If somebody writes
>>
>>if (x>x+1) ...
>>
>>the intent is not to be equivalent to an empty statement. And if you
>>are unsure about that, the "be conservative" part should help you make
>>the right decision.
>
>Sorry but I do.
>
>If I write
>if ( {expr1} > {expr2} )
>
>and the optimising, inlining compiler discovers that expr1 is x and expr2
>is x+1 , I want it to remove the dead code.
Then use a language that guarantees that x>x+1 is false. There are
any number of languages where this happens to be the case, but C is
not one of them.
>Remember this "if" can be part of a maze of twisty little conditions
>that I as a human can not find my way in. Or it could be part of code
>generated by lex and yacc.
But it wasn't. It was written by a human as shown (actually it was
"x<x-1", but that makes no difference). If you have experienced cases
where this code came out of compicated macros or maze of twisty little
conditionals, please present the case.
>How is the compiler to decide that this code has been written and
>inspected by a human, instead of being intermediate or generated?
When in doubt, be conservative, i.e., don't "optimize" the code.
>If you want to do your trick, I insist that you use a detour via
>unsigned ints, which at the same time waves a big red flag
>that something fishy is going on.
Yes, somebody posted some code that casted between signed and unsigned
(so that the addition would be unsigned and the comparison signed),
and I tried that out, but there are versions of gcc that miscompile
that, too.
Probably that version of gcc is not standard-conforming,
but I doubt that they would fix that bug (if they actually did not
declare it as not a bug without properly reading the bug report, and
for that somebody would have to waste his time on a bug report first).
Or maybe the code I tried is not standard-conforming despite
assurances from the author; there are so many ways to be "undefined"
in C, and the program fragment had more than one token, so it's hard
to tell.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2013: http://www.euroforth.org/ef13/
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@yahoo.com |
|---|---|
| Date | 2014-02-13 15:53 -0800 |
| Message-ID | <f05459c9-f698-443a-8943-81c04d7b227a@googlegroups.com> |
| In reply to | #28385 |
On Thursday, February 13, 2014 8:29:03 AM UTC-7, Anton Ertl wrote:
> A more relevant case is reading uninitialized data. That may lead to
> one behaviour in one version of a Forth system and a different
> behaviour in the next version, even if the optimizations in these
> versions do not differ. Again, if a program intentionally relies on
> that, it is probably best of sticking with one version. For the
> system it's a good idea to initialize data (at least optionally), to
> allow to initialize it in several ways (to support the programmer to
> find the problem in testing), and ideally to have tools for finding
> the reads of uninitialized data.
Previously I made the argument that local variables should be standardized to initialize to some value (zero would be a reasonable choice) so that the program is guaranteed to do the same thing every time, and not vary from compile to compile. YOU argued against this, saying that it is faster to initialize them to whatever happens to be in memory, which is what your {: does. So I said that my language would initialize them to zero, and that your undefined initialization would be considered yet another blunder of Forth-200x. Now you seem to have changed your mind --- apparently Forth-200x is just whatever you say it is from day to day.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-02-14 00:39 +0100 |
| Message-ID | <ldjl3n$p1q$1@online.de> |
| In reply to | #28384 |
Andrew Haley wrote: > It means that no optimization that can possibly affect a program, > whether that program is well-defined or not, can ever be made. This > even includes optimizations whose only effect is to speed up a > program, because timing can affect the output of a badly-written > program. So no optimzation may ever be done. > > I think that this is a hopelessly idealistic (not to say naive) view. I think you don't understand your responsibility (with "you" I mean the GCC team): You define what the compiler's interpretation of the C semantics is. And then you have to stick to that definition, or, if you want to progress, use some version label. I've used Verilog compilers and interpreters, which always wanted a switch for the newer Verilog standards, *despite the fact* that these new standards didn't break old code. But it might, and so you have to say that you are using this version of the spec. You probably don't want too many of those switches, because it is a nightmare to test. Backward compatibility is a burden and it doesn't come for free. However, the GCC is the maintainer of a core infrastructure, and needs to understand that: Your product is used to compile 10s of thousands of other software. If you spend the effort not breaking 100s of them, it is time well spent. And you do: Almost every minor update of GCC breaks Gforth in one way or another, so at the moment you are doing a really bad job. Other software is not broken, but performance decreases significantly, e.g. the 4.8.x version has about 20% lower speed on Keccak or ed25519 (both crypto primitives). You have a wonderful situation for developing a compiler: You have a huge code base, and a significant amount of that is in-house. Run the entire RedHat build with the new version, and when it does compile all the old stuff without breaking programs or causing significant performance degradation on sensitive stuff, call it a release. You also need to understand that the semantics of a living language is usually defined by its usage, not by a formal spec or standard body. The semantics of C is far better defined than you think. BTW: Sometimes, GCC is just obnoxious. The man-page tells you that -fPIC and -fomit-frame-pointer should not be used together, because it is a bad idea to be unable to backtrace in a library. The reality is that GCC ignores -fomit-frame-pointer if you add -fPIC (which is not the same thing, and therefore IMHO a bug - you have to stick to what you document!). So even when you know what you are doing, you can't. E.g. in libgforth (the shared library version or inclusion into other programming languages), being able to backtrace C calls is just meaningless. You need to be able to backtrace Forth to get meaningful error messages. That's entirely up to me to make this happen, not up to GCC. So the result is that libgforth is considerably slowed down on x86 because someone thought he's more clever than the user. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-02-14 06:38 -0600 |
| Message-ID | <yuWdnQFeb4HVk2PPnZ2dnUVZ_sidnZ2d@supernews.com> |
| In reply to | #28393 |
Bernd Paysan <bernd.paysan@gmx.de> wrote: > Andrew Haley wrote: >> It means that no optimization that can possibly affect a program, >> whether that program is well-defined or not, can ever be made. This >> even includes optimizations whose only effect is to speed up a >> program, because timing can affect the output of a badly-written >> program. So no optimzation may ever be done. >> >> I think that this is a hopelessly idealistic (not to say naive) view. > > I think you don't understand your responsibility (with "you" I mean > the GCC team): You define what the compiler's interpretation of the > C semantics is. Sure, but C is not Java: what is not defined is undefined, because an implementation cannot control what an undefined program might do. So, if someone overflows an array bound or jumps to a wild address, something bad may happen. And any optimization on an undefined program might change harmless bad behaviour into harmful bad behaviour. There's no way to prevent it short of a secure virtual machine. That's just how it is. It's not specific to GCC or to any other compiler. > BTW: Sometimes, GCC is just obnoxious. The man-page tells you that > -fPIC and -fomit-frame-pointer should not be used together, because > it is a bad idea to be unable to backtrace in a library. The > reality is that GCC ignores -fomit-frame-pointer if you add -fPIC > (which is not the same thing, and therefore IMHO a bug - you have to > stick to what you document!). IMHO too. However, it might well be that the system ABI actually requires frame pointers in DSOs: I can think of reasons why it might. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-02-15 15:37 +0000 |
| Message-ID | <2014Feb15.163709@mips.complang.tuwien.ac.at> |
| In reply to | #28424 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Sure, but C is not Java: what is not defined is undefined, because an
>implementation cannot control what an undefined program might do. So,
>if someone overflows an array bound or jumps to a wild address,
>something bad may happen. And any optimization on an undefined
>program might change harmless bad behaviour into harmful bad
>behaviour. There's no way to prevent it short of a secure virtual
>machine.
The computation of an address that overflows array bounds is harmless
on mainstream machines. A read from such an address whose result is
ignored may have no effect or may produce an exception/signal. The
implementation can perfectly control that. If the implementor chooses
to delete a loop control condition based on such things, "optimizing"
a finite loop into an infinite loop (without giving a warning), it's
not because the implementation cannot control it, but because the
implementor chooses to do it that way. You don't need a secure
virtual machine to prevent that, just a different attitude towards
optimization.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2013: http://www.euroforth.org/ef13/
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-02-15 13:33 -0600 |
| Message-ID | <3-SdnbUAdIxpXWLPnZ2dnUVZ_vidnZ2d@supernews.com> |
| In reply to | #28453 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>Sure, but C is not Java: what is not defined is undefined, because an >>implementation cannot control what an undefined program might do. So, >>if someone overflows an array bound or jumps to a wild address, >>something bad may happen. And any optimization on an undefined >>program might change harmless bad behaviour into harmful bad >>behaviour. There's no way to prevent it short of a secure virtual >>machine. > > The computation of an address that overflows array bounds is harmless > on mainstream machines. A read from such an address whose result is > ignored may have no effect or may produce an exception/signal. The > implementation can perfectly control that. That's not true for writes, though. And that's the point: it's generally true that any optimization which changes behaviour in Java is a bug, because pretty much everything is well-defined. (This isn't true for concurency-related bugs such as data races, and a few other exceptions.) Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Roelf Toxopeus <rt4all@notthis.hetnet.nl> |
|---|---|
| Date | 2014-02-11 10:50 +0100 |
| Message-ID | <rt4all-3FA3D4.10502911022014@news.kpn.nl> |
| In reply to | #28304 |
In article <52f95386.555836101@news.demon.co.uk>, stephenXXX@mpeforth.com (Stephen Pelc) wrote: > On Mon, 10 Feb 2014 12:14:54 -0600, Andrew Haley > <andrew29@littlepinkcloud.invalid> wrote: > > >Anyway, this language "feature" means that VFX can't do tail call > >elimination, a very simple optimisation that was available way back > >in cmFORTH. This fact casts some doubt upon your performance > >comparison. I don't think that it's likely to be a huge difference, > >but it is likely to be significant. > > As Anton has pointed out, VFX *chooses* not to do tail call > elimination. We could do it, but the demand is not there. We have, > however, been thanked for not doing it as other traditional Forth > techniques such as return stack manipulation are simple to > implement in VFX. > > The only safe way to do tail call elimination is to have a switch to > disable it. > > I'm becoming less and less interested in the last few nanoseconds. > Reliability is good. Hi Stephen, I never ever had problems with tail elimination on 680X0 or PPC native Forth systems! Indeed they could be turned on and off, like it can be turned off in ColorForth. As for nanoseconds ( *), they didn't exist on 8 MHz 68000's ;-) Any optimisation was welcome, believe you me! Reliability? I would not call the systems used on above mentioned CPU's unreliable, moreover, they were very *predictable*. Which is what really counts IMHO. ( *) Just because we measure in nanoseconds and beyond on blindingly fast CPU's, it doesn't mean we can get 'sloppy' with optimisations and code design. An example is the machine I use now, where the vendor tends to put more and more in a late/dynamic binding spaghetti bowl of classes, resulting after 30 years in: Happy Birthday Sluggintosh! Best, Roelf
[toc] | [prev] | [next] | [standalone]
| From | stephenXXX@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2014-02-11 10:57 +0000 |
| Message-ID | <52fa0073.600104474@news.demon.co.uk> |
| In reply to | #28307 |
On Tue, 11 Feb 2014 10:50:29 +0100, Roelf Toxopeus <rt4all@notthis.hetnet.nl> wrote: >I never ever had problems with tail elimination on 680X0 or PPC native >Forth systems! Indeed they could be turned on and off, like it can be >turned off in ColorForth. The particular code that caused problems with tail-call elimination (TCE) was (from memory) Michael Gassanenko's backtracking system. Until I can convince myself that there is an algorithm to detect *all* dangerous return stack actions, any TCE setting in an MPE system will default to off. >As for nanoseconds ( *), they didn't exist on 8 MHz 68000's ;-) Any >optimisation was welcome, believe you me! I remember them well. >Reliability? I would not call the systems used on above mentioned CPU's >unreliable, moreover, they were very *predictable*. Which is what really >counts IMHO. In the main, it wasn't the CPU that was unreliable, but the software. >( *) >Just because we measure in nanoseconds and beyond on blindingly fast >CPU's, it doesn't mean we can get 'sloppy' with optimisations and code >design. Very true. But the main issue at the moment is time to delivery of software. Stephen -- Stephen Pelc, stephenXXX@mpeforth.com MicroProcessor Engineering Ltd - More Real, Less Time 133 Hill Lane, Southampton SO15 5AF, England tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691 web: http://www.mpeforth.com - free VFX Forth downloads
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-02-11 02:35 -0800 |
| Message-ID | <7x7g92djjd.fsf@ruckus.brouhaha.com> |
| In reply to | #28304 |
stephenXXX@mpeforth.com (Stephen Pelc) writes: > The only safe way to do tail call elimination is to have a switch to > disable it. > I'm becoming less and less interested in the last few nanoseconds. I thought TCE was mostly to prevent unbounded stack growth rather than save nanoseconds. Without it you can't write in a style that implements loops with recursion. I can understand that in Forth you might not often want to write in that style anyway.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-02-11 11:47 +0000 |
| Message-ID | <2014Feb11.124731@mips.complang.tuwien.ac.at> |
| In reply to | #28308 |
Paul Rubin <no.email@nospam.invalid> writes:
>stephenXXX@mpeforth.com (Stephen Pelc) writes:
>> The only safe way to do tail call elimination is to have a switch to
>> disable it.
>> I'm becoming less and less interested in the last few nanoseconds.
>
>I thought TCE was mostly to prevent unbounded stack growth rather than
>save nanoseconds.
That's if you guarantee tail call elimination, and is relevant for
languages where tail-recursion is preferred to loops. In Forth there
is no guaranteed tail-call elimination, and even if there was,
programmers would still prefer to write loops rather than tail
recursion. So in Forth the issue is just the speed.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2013: http://www.euroforth.org/ef13/
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-02-11 13:08 +0000 |
| Message-ID | <2014Feb11.140839@mips.complang.tuwien.ac.at> |
| In reply to | #28301 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
[Andrew Haley]
>>>>>As you can see, this ends with a call followed by a return.
>>>>
>>>> AFAIK that's intentional to support return address manipulation.
>>>
>>>Sure, but that behaviour isn't required by the Forth language,
>>
>> It is required by the Forth language as supported by VFX.
>
>I suppose so; but that is not *the* Forth language.
There is no "*the* Forth language".
>Anyway, this language "feature" means that VFX can't do tail call
>elimination, a very simple optimization that was available way back
>in cmFORTH. This fact casts some doubt upon your performance
>comparison.
I am awaiting your results produced by running the program on cmForth.
>> BTW, what may (or may not) make the IF-based variants look better than
>> the EXECUTE-based variant is that the words .LOWER etc. are inlined in
>> the IF-based variants, but not in the EXECUTE-based variant.
>
>Indeed, I have noticed that, but I think it's typical of what a
>compiler would do in real code.
In real code .LOWER will not be just an empty definition, and even the
few compilers that inline some definitions automatically my choose not
to inline .LOWER. I have more doubts about the results because .LOWER
etc. is empty than because of how VFX deals with tail calls. But
since there is no "typical" content for these kinds of definitions,
any such benchmark will have to live with such doubts.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2013: http://www.euroforth.org/ef13/
[toc] | [prev] | [next] | [standalone]
Page 16 of 21 — ← Prev page 1 … 14 15 [16] 17 18 … 21 Next page →
Back to top | Article view | comp.lang.forth
csiph-web