Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #97546 > unrolled thread
| Started by | fir <profesor.fir@gmail.com> |
|---|---|
| First post | 2016-11-26 12:49 -0800 |
| Last post | 2016-12-01 12:33 +0800 |
| Articles | 20 on this page of 567 — 30 participants |
Back to article view | Back to comp.lang.c
absence of max fir <profesor.fir@gmail.com> - 2016-11-26 12:49 -0800
absence of max "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-26 15:34 -0800
Re: absence of max BartC <bc@freeuk.com> - 2016-11-27 00:21 +0000
Re: absence of max "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-27 04:25 -0800
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-11-27 13:54 +0100
Re: absence of max BartC <bc@freeuk.com> - 2016-11-27 13:54 +0000
Re: absence of max supercat@casperkitty.com - 2016-11-27 07:33 -0800
Re: absence of max Melzzzzz <mel@zzzzz.com> - 2016-11-27 14:06 +0100
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-11-27 17:47 +0100
Re: absence of max "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-28 07:13 -0800
Re: absence of max BartC <bc@freeuk.com> - 2016-11-28 15:35 +0000
Re: absence of max "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-28 07:48 -0800
Re: absence of max "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-28 07:53 -0800
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-29 00:14 +0000
Re: absence of max BartC <bc@freeuk.com> - 2016-11-29 00:36 +0000
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-29 02:03 +0000
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-11-28 23:23 -0800
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-11-28 21:05 -0800
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-11-28 16:53 +0100
Re: absence of max "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-28 08:07 -0800
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-11-29 10:37 +0100
Re: absence of max supercat@casperkitty.com - 2016-11-28 08:26 -0800
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-11-29 10:42 +0100
Re: absence of max supercat@casperkitty.com - 2016-11-28 08:16 -0800
Re: absence of max "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-28 09:31 -0800
Re: absence of max supercat@casperkitty.com - 2016-11-28 10:38 -0800
Re: absence of max "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-28 10:59 -0800
Re: absence of max supercat@casperkitty.com - 2016-11-28 12:09 -0800
Re: absence of max "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-28 12:46 -0800
Re: absence of max supercat@casperkitty.com - 2016-11-28 13:05 -0800
Re: absence of max "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-28 13:50 -0800
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-11-29 10:52 +0100
Re: absence of max "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-29 05:44 -0800
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-11-29 15:12 +0100
Re: absence of max "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-29 06:54 -0800
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-11-30 10:37 +0100
Re: absence of max "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-30 03:07 -0800
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-11-30 13:28 +0100
Re: absence of max "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-30 05:12 -0800
Re: absence of max BartC <bc@freeuk.com> - 2016-11-28 18:57 +0000
Re: absence of max supercat@casperkitty.com - 2016-11-28 11:33 -0800
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-11-28 20:09 +0000
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-11-29 10:55 +0100
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-11-29 10:06 +0000
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-11-29 11:18 +0100
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-11-29 10:28 +0000
Re: absence of max BartC <bc@freeuk.com> - 2016-11-29 10:49 +0000
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-11-29 10:51 +0000
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-29 11:40 +0000
Re: absence of max BartC <bc@freeuk.com> - 2016-11-29 12:17 +0000
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-11-29 15:18 +0000
Re: absence of max Gareth Owen <gwowen@gmail.com> - 2016-11-29 18:30 +0000
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-11-29 18:49 +0000
Re: absence of max "James R. Kuyper" <jameskuyper@verizon.net> - 2016-11-29 14:09 -0500
Re: absence of max supercat@casperkitty.com - 2016-11-29 10:56 -0800
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-11-29 11:29 -0800
Re: absence of max BartC <bc@freeuk.com> - 2016-11-29 20:27 +0000
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-11-29 20:31 +0000
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-11-30 10:45 +0100
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-11-29 12:54 -0800
Re: absence of max "James R. Kuyper" <jameskuyper@verizon.net> - 2016-11-29 16:21 -0500
Re: absence of max BartC <bc@freeuk.com> - 2016-11-29 21:47 +0000
Re: absence of max BartC <bc@freeuk.com> - 2016-11-29 21:30 +0000
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-11-29 14:12 -0800
Re: absence of max BartC <bc@freeuk.com> - 2016-11-29 22:27 +0000
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-11-29 22:33 +0000
Re: absence of max jameskuyper@verizon.net - 2016-11-29 14:52 -0800
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-11-29 15:43 -0800
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-29 23:51 +0000
Re: absence of max BartC <bc@freeuk.com> - 2016-11-30 00:51 +0000
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-30 02:08 +0000
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-11-29 18:10 -0800
Re: absence of max "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-28 12:29 -0800
Re: absence of max BartC <bc@freeuk.com> - 2016-11-28 21:30 +0000
Re: absence of max "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-28 13:47 -0800
Re: absence of max supercat@casperkitty.com - 2016-11-28 14:59 -0800
Re: absence of max "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-28 15:13 -0800
Re: absence of max BartC <bc@freeuk.com> - 2016-11-29 00:12 +0000
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-29 01:11 +0000
Re: absence of max "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-28 18:01 -0800
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-29 02:19 +0000
Re: absence of max supercat@casperkitty.com - 2016-11-29 13:26 -0800
Re: absence of max "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-29 17:09 -0800
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-29 00:01 +0000
Re: absence of max BartC <bc@freeuk.com> - 2016-11-29 00:29 +0000
Re: absence of max supercat@casperkitty.com - 2016-11-28 17:02 -0800
Re: absence of max BartC <bc@freeuk.com> - 2016-11-29 01:21 +0000
Re: absence of max supercat@casperkitty.com - 2016-11-28 17:53 -0800
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-11-28 23:11 -0800
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-29 02:12 +0000
Re: absence of max BartC <bc@freeuk.com> - 2016-11-29 11:17 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-11-29 09:46 -0500
Re: absence of max BartC <bc@freeuk.com> - 2016-11-29 15:45 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-11-29 17:04 -0500
Re: absence of max supercat@casperkitty.com - 2016-11-29 07:21 -0800
Re: absence of max BartC <bc@freeuk.com> - 2016-11-29 15:50 +0000
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-30 00:19 +0000
Re: absence of max BartC <bc@freeuk.com> - 2016-11-30 00:43 +0000
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-30 01:51 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-11-29 22:26 -0500
Re: absence of max BartC <bc@freeuk.com> - 2016-11-30 11:25 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-11-30 09:07 -0500
Re: absence of max BartC <bc@freeuk.com> - 2016-11-30 14:22 +0000
Re: absence of max supercat@casperkitty.com - 2016-11-30 09:03 -0800
Re: absence of max BartC <bc@freeuk.com> - 2016-11-30 23:38 +0000
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-11-30 15:49 -0800
Re: absence of max BartC <bc@freeuk.com> - 2016-12-01 00:10 +0000
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-11-30 17:22 -0800
Re: absence of max BartC <bc@freeuk.com> - 2016-12-01 01:40 +0000
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-11-30 18:03 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-11-30 17:25 -0500
Re: absence of max BartC <bc@freeuk.com> - 2016-11-30 23:29 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-11-30 23:55 -0500
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-01 10:05 +0100
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-01 11:20 +0000
Re: absence of max BartC <bc@freeuk.com> - 2016-12-01 11:41 +0000
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-01 13:48 +0100
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-12-01 10:43 -0800
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-01 21:23 +0000
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-12-01 14:41 -0800
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-02 09:39 +0100
Re: absence of max BartC <bc@freeuk.com> - 2016-12-01 11:35 +0000
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-01 14:51 +0100
Re: absence of max BartC <bc@freeuk.com> - 2016-12-01 15:05 +0000
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-12-01 10:49 -0800
Re: absence of max BartC <bc@freeuk.com> - 2016-12-01 20:48 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-01 16:51 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-01 01:18 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-11-30 23:57 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-01 11:38 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-01 13:28 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-02 00:06 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-01 20:02 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-02 02:22 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-01 21:42 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-03 01:56 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-02 21:25 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-03 02:33 +0000
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-03 15:20 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-03 15:40 -0500
Re: absence of max Ian Collins <ian-news@hotmail.com> - 2016-12-02 21:57 +1300
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-02 10:46 -0500
Re: absence of max asetofsymbols@gmail.com - 2016-11-30 06:36 -0800
Re: absence of max BartC <bc@freeuk.com> - 2016-11-30 16:41 +0000
Re: absence of max Ian Collins <ian-news@hotmail.com> - 2016-11-30 20:50 +1300
Re: absence of max BartC <bc@freeuk.com> - 2016-11-30 11:11 +0000
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-30 12:00 +0000
Re: absence of max James Kuyper <jameskuyper@verizon.net> - 2016-11-30 11:32 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-30 19:25 +0000
Re: absence of max BartC <bc@freeuk.com> - 2016-11-30 20:45 +0000
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-11-30 12:52 -0800
Re: absence of max supercat@casperkitty.com - 2016-11-30 14:17 -0800
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-01 10:14 +0100
Re: absence of max supercat@casperkitty.com - 2016-12-01 07:37 -0800
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-01 17:05 +0100
Re: absence of max supercat@casperkitty.com - 2016-12-01 10:06 -0800
Re: absence of max James Kuyper <jameskuyper@verizon.net> - 2016-12-01 13:53 -0500
Re: absence of max supercat@casperkitty.com - 2016-12-01 12:22 -0800
Re: absence of max jameskuyper@verizon.net - 2016-12-01 19:02 -0800
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-02 10:05 +0100
Re: absence of max "James R. Kuyper" <jameskuyper@verizon.net> - 2016-12-02 11:01 -0500
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-02 17:28 +0100
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-01 21:13 +0000
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-12-01 10:53 -0800
Re: absence of max supercat@casperkitty.com - 2016-12-01 11:51 -0800
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-12-01 12:52 -0800
Re: absence of max supercat@casperkitty.com - 2016-12-01 14:28 -0800
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-12-01 14:48 -0800
Re: absence of max supercat@casperkitty.com - 2016-12-01 15:00 -0800
Re: absence of max jameskuyper@verizon.net - 2016-12-01 19:28 -0800
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-02 10:30 +0000
Re: absence of max supercat@casperkitty.com - 2016-12-02 07:24 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-02 10:50 -0500
Re: absence of max supercat@casperkitty.com - 2016-12-02 09:39 -0800
Re: absence of max jameskuyper@verizon.net - 2016-12-02 10:17 -0800
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-12-02 11:46 -0800
Re: absence of max "James R. Kuyper" <jameskuyper@verizon.net> - 2016-12-02 15:02 -0500
Re: absence of max supercat@casperkitty.com - 2016-12-02 11:58 -0800
Re: absence of max jameskuyper@verizon.net - 2016-12-02 13:25 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-02 15:31 -0500
Re: absence of max supercat@casperkitty.com - 2016-12-02 13:34 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-02 19:32 -0500
Re: absence of max BartC <bc@freeuk.com> - 2016-12-03 01:11 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-02 20:48 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-03 02:11 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-02 21:27 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-03 02:50 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-02 22:45 -0500
Re: absence of max BartC <bc@freeuk.com> - 2016-12-03 11:07 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-03 15:46 -0500
Re: absence of max jameskuyper@verizon.net - 2016-12-03 13:46 -0800
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-03 23:29 +0000
Re: absence of max "James R. Kuyper" <jameskuyper@verizon.net> - 2016-12-03 18:42 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-03 23:59 +0000
Re: absence of max Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-10 08:31 -0800
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-12-10 13:51 -0800
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-10 22:08 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-03 20:19 -0500
Re: absence of max BartC <bc@freeuk.com> - 2016-12-04 01:28 +0000
Re: absence of max Ian Collins <ian-news@hotmail.com> - 2016-12-04 14:34 +1300
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-05 00:02 +0000
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-05 10:34 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-05 08:38 -0500
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-05 15:52 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-05 16:03 -0500
Re: absence of max jameskuyper@verizon.net - 2016-12-03 19:19 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-04 11:26 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-03 11:33 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-03 15:48 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-04 00:59 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-03 20:23 -0500
Re: absence of max "James R. Kuyper" <jameskuyper@verizon.net> - 2016-12-03 10:32 -0500
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-03 17:15 +0100
Re: absence of max jameskuyper@verizon.net - 2016-12-03 08:33 -0800
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-12-03 11:08 -0800
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-03 21:31 +0000
Re: absence of max supercat@casperkitty.com - 2016-12-04 08:40 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-04 19:39 -0500
Re: absence of max supercat@casperkitty.com - 2016-12-05 07:15 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-05 16:09 -0500
Re: absence of max supercat@casperkitty.com - 2016-12-05 13:38 -0800
Re: absence of max jameskuyper@verizon.net - 2016-12-05 14:12 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-05 22:21 -0500
Re: absence of max jameskuyper@verizon.net - 2016-12-05 22:05 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-06 10:46 -0500
Re: absence of max jameskuyper@verizon.net - 2016-12-06 09:45 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-06 13:25 -0500
Re: absence of max jameskuyper@verizon.net - 2016-12-06 10:33 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-06 16:25 -0500
Re: absence of max jameskuyper@verizon.net - 2016-12-06 15:10 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-06 20:48 -0500
Re: absence of max jameskuyper@verizon.net - 2016-12-07 14:43 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-08 09:26 -0500
Re: absence of max jameskuyper@verizon.net - 2016-12-08 11:32 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-08 21:56 -0500
Re: absence of max jameskuyper@verizon.net - 2016-12-08 20:28 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 10:10 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-08 21:17 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-08 22:01 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-09 20:00 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 22:51 -0500
Re: absence of max cross@spitfire.i.gajendra.net (Dan Cross) - 2016-12-10 04:44 +0000
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-05 22:49 +0000
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-12-05 15:24 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-05 22:25 -0500
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-05 22:24 -0500
Re: absence of max jameskuyper@verizon.net - 2016-12-05 22:47 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-06 10:51 -0500
Re: absence of max jameskuyper@verizon.net - 2016-12-06 10:25 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-06 16:26 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-07 02:09 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-07 09:30 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-08 01:44 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-08 09:29 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-08 21:54 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-08 22:05 -0500
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-09 11:39 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 10:16 -0500
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-09 16:45 +0100
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-09 21:07 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 22:58 -0500
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-10 17:49 +0100
Re: absence of max "James R. Kuyper" <jameskuyper@verizon.net> - 2016-12-09 16:46 -0500
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 22:56 -0500
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-10 14:04 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-10 08:45 -0500
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-10 14:54 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-11 15:40 -0500
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-11 23:13 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-11 17:59 -0500
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-12 18:13 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-16 16:02 -0500
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-16 22:47 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-16 22:38 -0500
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-17 14:43 +0100
Re: absence of max BartC <bc@freeuk.com> - 2016-12-17 13:52 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-17 10:00 -0500
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-17 09:58 -0500
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-17 16:39 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-17 22:48 -0500
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-18 16:51 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-19 11:54 -0500
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-19 21:24 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-19 17:38 -0500
Re: absence of max Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-19 15:11 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-19 19:12 -0500
Re: absence of max Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-19 17:23 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-19 21:41 -0500
Re: absence of max supercat@casperkitty.com - 2016-12-17 09:23 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-17 22:49 -0500
Re: absence of max supercat@casperkitty.com - 2016-12-18 08:26 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-19 11:56 -0500
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-19 19:19 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-19 17:40 -0500
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-10 18:03 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-11 15:44 -0500
Re: absence of max Robert Wessel <robertwessel2@yahoo.com> - 2016-12-10 01:19 -0600
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-09 21:52 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 23:02 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-10 12:59 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-11 15:52 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-12 03:18 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-11 22:29 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-12 04:12 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-12 09:44 -0500
Re: absence of max supercat@casperkitty.com - 2016-12-06 06:10 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-06 10:58 -0500
Re: absence of max supercat@casperkitty.com - 2016-12-06 10:21 -0800
Re: absence of max supercat@casperkitty.com - 2016-12-06 10:25 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-06 16:28 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-07 02:48 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-07 09:34 -0500
Re: absence of max supercat@casperkitty.com - 2016-12-07 06:58 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-07 15:15 -0500
Re: absence of max supercat@casperkitty.com - 2016-12-07 12:30 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-07 16:25 -0500
Re: absence of max supercat@casperkitty.com - 2016-12-07 13:46 -0800
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-12-07 13:53 -0800
Re: absence of max supercat@casperkitty.com - 2016-12-07 14:03 -0800
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-12-07 14:50 -0800
Re: absence of max Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-10 07:46 -0800
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-12-10 13:44 -0800
Re: absence of max Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-14 22:12 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-07 17:00 -0500
Re: absence of max supercat@casperkitty.com - 2016-12-07 14:08 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-07 17:28 -0500
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-07 17:29 -0500
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-12-07 14:49 -0800
Re: absence of max supercat@casperkitty.com - 2016-12-07 16:24 -0800
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-12-07 17:04 -0800
Re: absence of max Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-10 07:29 -0800
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-12-10 13:37 -0800
Re: absence of max me <crisdunbar@gmail.com> - 2016-12-07 14:25 -0800
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-08 02:19 +0000
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-08 02:07 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-08 09:36 -0500
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-08 16:22 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-08 10:52 -0500
Re: absence of max supercat@casperkitty.com - 2016-12-08 08:11 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-08 22:08 -0500
Re: absence of max jameskuyper@verizon.net - 2016-12-08 12:50 -0800
Re: absence of max Ian Collins <ian-news@hotmail.com> - 2016-12-09 10:14 +1300
Re: absence of max Melzzzzz <mel@zzzzz.com> - 2016-12-08 22:17 +0100
Re: absence of max Ian Collins <ian-news@hotmail.com> - 2016-12-09 10:21 +1300
Re: absence of max Melzzzzz <mel@zzzzz.com> - 2016-12-08 22:24 +0100
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-09 13:06 +0100
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-09 21:15 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 23:05 -0500
Re: absence of max Robert Wessel <robertwessel2@yahoo.com> - 2016-12-10 03:22 -0600
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-10 15:12 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-11 15:57 -0500
Re: absence of max Robert Wessel <robertwessel2@yahoo.com> - 2016-12-12 00:13 -0600
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-12 09:48 -0500
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-10 14:11 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-11 15:59 -0500
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-11 23:18 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-11 17:59 -0500
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-12 18:18 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-16 16:04 -0500
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-16 22:48 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-16 22:39 -0500
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-17 14:45 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-17 10:01 -0500
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-12-17 11:27 -0800
People who confuse and jumble up the difference between past, present, and future (Was: absence of max) gazelle@shell.xmission.com (Kenny McCormack) - 2016-12-17 20:07 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 10:17 -0500
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-08 22:17 -0500
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-08 22:15 -0500
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-12-09 08:40 +0000
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-09 13:19 +0100
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-12-09 12:29 +0000
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-09 14:34 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 10:24 -0500
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-09 16:58 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 23:09 -0500
Re: absence of max Ian Collins <ian-news@hotmail.com> - 2016-12-11 20:56 +1300
Re: absence of max "James R. Kuyper" <jameskuyper@verizon.net> - 2016-12-09 16:52 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-09 13:35 +0000
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-12-09 13:42 +0000
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-09 13:54 +0000
Re: absence of max Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-10 07:54 -0800
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-12-11 16:14 +0000
Re: absence of max Gareth Owen <gwowen@gmail.com> - 2016-12-11 18:11 +0000
Re: absence of max Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-14 21:08 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 10:25 -0500
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 10:18 -0500
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-12-09 15:55 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 23:11 -0500
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 10:21 -0500
Re: absence of max Robert Wessel <robertwessel2@yahoo.com> - 2016-12-10 01:48 -0600
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-09 13:02 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 10:39 -0500
Re: absence of max cross@spitfire.i.gajendra.net (Dan Cross) - 2016-12-10 04:37 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-10 00:13 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-08 22:22 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-08 22:19 -0500
Re: absence of max jameskuyper@verizon.net - 2016-12-07 19:40 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-08 09:38 -0500
Re: absence of max supercat@casperkitty.com - 2016-12-08 07:52 -0800
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-08 19:37 +0000
Re: absence of max supercat@casperkitty.com - 2016-12-08 14:46 -0800
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-12-08 15:46 -0800
Re: absence of max Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-13 13:04 -0800
Re: absence of max supercat@casperkitty.com - 2016-12-13 13:38 -0800
Re: absence of max Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-13 14:07 -0800
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-12-13 22:51 +0000
Re: absence of max supercat@casperkitty.com - 2016-12-14 08:17 -0800
Re: absence of max Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-14 11:49 -0800
Re: absence of max supercat@casperkitty.com - 2016-12-14 16:53 -0800
Re: absence of max Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-15 05:14 -0800
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-15 15:02 +0100
Re: absence of max supercat@casperkitty.com - 2016-12-15 08:54 -0800
Re: absence of max raltbos@xs4all.nl (Richard Bos) - 2016-12-15 19:55 +0000
Re: absence of max Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-15 13:48 -0800
Re: absence of max supercat@casperkitty.com - 2016-12-15 14:20 -0800
Re: absence of max Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-15 15:32 -0800
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-15 23:44 +0100
Re: absence of max Gareth Owen <gwowen@gmail.com> - 2016-12-16 07:00 +0000
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-12-16 08:21 +0000
Re: absence of max Gareth Owen <gwowen@gmail.com> - 2016-12-16 21:10 +0000
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-12-16 13:24 -0800
Re: absence of max "D. Aaron Sawyer" <aaron@110.net> - 2016-12-16 18:51 -0400
Re: absence of max raltbos@xs4all.nl (Richard Bos) - 2016-12-20 09:03 +0000
Re: absence of max Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-20 02:21 -0800
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-14 19:05 +0100
Re: absence of max Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-14 22:46 -0800
Re: absence of max supercat@casperkitty.com - 2016-12-08 15:58 -0800
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-09 00:18 +0000
Re: absence of max supercat@casperkitty.com - 2016-12-09 07:25 -0800
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-12-09 11:29 -0800
Re: absence of max Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-10 09:07 -0800
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-12-10 14:20 -0800
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-09 21:31 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 23:15 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-10 12:15 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-11 16:04 -0500
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-08 22:27 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-09 22:11 +0000
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-12-09 15:45 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 23:21 -0500
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 23:19 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-10 12:11 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-11 16:04 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-12 03:15 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-11 22:31 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-12 04:14 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-12 09:50 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-12 23:18 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-16 16:05 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-17 02:58 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-16 22:40 -0500
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-12 18:20 +0100
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-12-12 17:29 +0000
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-12 18:53 +0100
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-12-12 17:58 +0000
Re: absence of max cross@spitfire.i.gajendra.net (Dan Cross) - 2016-12-12 19:11 +0000
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-13 10:31 +0100
Re: absence of max Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-12 15:38 -0800
Re: absence of max raltbos@xs4all.nl (Richard Bos) - 2016-12-15 12:08 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-16 16:06 -0500
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-16 22:49 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-16 22:44 -0500
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-17 14:47 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-17 10:04 -0500
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-17 16:45 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-17 22:51 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-17 13:52 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-17 22:51 -0500
Re: absence of max Parity Error <kgf@quiscurat.net> - 2016-12-18 09:17 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-08 22:23 -0500
Re: absence of max jameskuyper@verizon.net - 2016-12-08 12:23 -0800
Re: absence of max Gareth Owen <gwowen@gmail.com> - 2016-12-08 20:45 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-08 22:32 -0500
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-12-09 08:42 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 10:40 -0500
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-12-09 16:10 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 23:33 -0500
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-12-11 15:02 +0000
Re: absence of max "James R. Kuyper" <jameskuyper@verizon.net> - 2016-12-11 13:01 -0500
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-11 16:11 -0500
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-12-11 23:11 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-11 18:59 -0500
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-12-12 00:09 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-11 20:56 -0500
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-12-12 08:04 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-12 09:50 -0500
Re: absence of max jameskuyper@verizon.net - 2016-12-11 16:18 -0800
Re: absence of max "James R. Kuyper" <jameskuyper@verizon.net> - 2016-12-11 19:38 -0500
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-11 21:04 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-12 03:35 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-12 09:52 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-12 23:22 +0000
Re: absence of max Ian Collins <ian-news@hotmail.com> - 2016-12-12 17:35 +1300
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-12 09:54 -0500
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-12-12 08:17 +0000
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-12 13:01 +0000
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-12-12 13:16 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-12 10:05 -0500
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-12-12 15:21 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-16 16:09 -0500
Re: absence of max jameskuyper@verizon.net - 2016-12-12 13:12 -0800
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-12 03:01 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-11 22:03 -0500
Re: absence of max "James R. Kuyper" <jameskuyper@verizon.net> - 2016-12-12 12:58 -0500
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-16 16:11 -0500
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-16 22:53 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-16 22:46 -0500
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-17 14:49 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-17 10:07 -0500
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-17 16:47 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-17 22:53 -0500
Re: absence of max Parity Error <kgf@quiscurat.net> - 2016-12-18 09:11 +0000
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-12 18:32 +0100
Re: absence of max "James R. Kuyper" <jameskuyper@verizon.net> - 2016-12-12 13:26 -0500
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-12 19:39 +0100
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-12-12 11:31 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-11 16:07 -0500
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-12-11 23:10 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-11 19:01 -0500
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-12-12 00:11 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-11 21:06 -0500
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-12-12 08:19 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-12 10:07 -0500
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-12-12 15:22 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-16 16:13 -0500
Re: absence of max BartC <bc@freeuk.com> - 2016-12-12 15:38 +0000
Re: absence of max jameskuyper@verizon.net - 2016-12-02 08:54 -0800
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-02 17:20 +0000
Re: absence of max supercat@casperkitty.com - 2016-12-02 07:35 -0800
Re: absence of max jameskuyper@verizon.net - 2016-12-02 09:52 -0800
Re: absence of max supercat@casperkitty.com - 2016-12-02 10:44 -0800
Re: absence of max James Kuyper <jameskuyper@verizon.net> - 2016-11-30 16:52 -0500
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-11-30 08:31 -0800
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-11-28 23:15 -0800
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-11-29 10:49 +0100
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-11-27 17:35 +0100
Re: absence of max supercat@casperkitty.com - 2016-11-27 09:39 -0800
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-11-27 20:35 +0100
Re: absence of max BartC <bc@freeuk.com> - 2016-11-27 20:10 +0000
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-11-27 22:07 +0100
Re: absence of max BartC <bc@freeuk.com> - 2016-11-27 22:55 +0000
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-11-28 12:46 +0100
Re: absence of max BartC <bc@freeuk.com> - 2016-11-28 13:16 +0000
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-11-28 14:52 +0100
Re: absence of max jadill33@gmail.com - 2016-11-28 09:41 -0800
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-11-29 11:04 +0100
Re: absence of max BartC <bc@freeuk.com> - 2016-11-27 18:02 +0000
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-11-27 20:52 +0100
Re: absence of max BartC <bc@freeuk.com> - 2016-11-27 20:31 +0000
Re: absence of max BartC <bc@freeuk.com> - 2016-11-27 22:09 +0000
Re: absence of max supercat@casperkitty.com - 2016-11-27 14:14 -0800
Re: absence of max BartC <bc@freeuk.com> - 2016-11-27 23:02 +0000
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-11-27 23:26 +0000
Re: absence of max BartC <bc@freeuk.com> - 2016-11-27 23:43 +0000
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-11-27 23:46 +0000
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-11-28 12:56 +0100
Re: absence of max jameskuyper@verizon.net - 2016-11-27 16:21 -0800
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-11-28 10:10 -0800
Re: absence of max Tim Prince <tprince@computer.org> - 2016-11-27 07:40 -0500
absence of max asetofsymbols@gmail.com - 2016-11-27 08:46 -0800
Re: absence of max fir <profesor.fir@gmail.com> - 2016-11-27 09:18 -0800
Re: absence of max asetofsymbols@gmail.com - 2016-11-27 09:22 -0800
Re: absence of max fir <profesor.fir@gmail.com> - 2016-11-27 09:27 -0800
Re: absence of max BartC <bc@freeuk.com> - 2016-11-27 17:33 +0000
Re: absence of max Gareth Owen <gwowen@gmail.com> - 2016-11-27 17:51 +0000
Re: absence of max Ken Brody <kenbrody@spamcop.net> - 2016-11-30 13:15 -0500
Re: absence of max "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-12-01 12:33 +0800
Page 21 of 29 — ← Prev page 1 … 19 20 [21] 22 23 … 29 Next page →
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-12-08 14:46 -0800 |
| Message-ID | <55af72f5-4abd-4ded-b88a-3a05a6f77675@googlegroups.com> |
| In reply to | #98422 |
On Thursday, December 8, 2016 at 4:25:08 PM UTC-6, Ben Bacarisse wrote: > > True. But until compilers supported prototypes that would often be just as > > true when a function definition was visible as when it wasn't. There may > > have been some compilers in the mid-1980s which would keep track of function > > parameter types and use them to adjust arguments, but that was not a > > commonplace situation, > > I am surprised you even consider it a possibility. For one thing it > goes against the explicit wording of the only language standard around > at the time (K&R) but, worse, it would produce very fragile code. Just > taking a function out into a separate translation unit and placing a > corresponding declaration into a suitable header file would change the > semantics of some (but all) calls to it. I have seen a variety of compilers over the years--some good, some bad, and have come to the conclusion that it would be far more useful to have a standard describe things compilers should do *when practical*, and require that compilers document and provide macros to test for cases where they can't behave in the preferred fashion, than to have a standard which eschews optional features in favor of saying that the only programmers should expect are those which are mandatory in all implementations. There are many embedded applications which don't need recursion and don't need ten-digit floating-point support, and I see no reason why it shouldn't be possible to have the Standard describe the behavior of low-end platforms which can't support all applications but could support many applications usefully. A floating-point type with about 9.5 digits of accuracy (32-bit mantissa) would on many platforms be a lot cheaper than one with 10, but the Standard wouldn't consider such a thing acceptable as a "double". If an application could get by with slightly looser precision, which would be more useful--a conforming compiler upon which floating-point math is twice as slow, or a compiler which doesn't conform to the Standard but does math twice as fast (bearing in mind that applications which absolutely need 10-digit precision could #if-test DBL_DIG and invoke #error if it's doesn't meet requirements).
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-12-08 15:46 -0800 |
| Message-ID | <lneg1iyofn.fsf@kst-u.example.com> |
| In reply to | #98429 |
supercat@casperkitty.com writes:
> On Thursday, December 8, 2016 at 4:25:08 PM UTC-6, Ben Bacarisse wrote:
>> supercat@casperkitty.com writes:
>> > True. But until compilers supported prototypes that would often be
>> > just as true when a function definition was visible as when it
>> > wasn't. There may have been some compilers in the mid-1980s which
>> > would keep track of function parameter types and use them to adjust
>> > arguments, but that was not a commonplace situation,
>>
>> I am surprised you even consider it a possibility. For one thing it
>> goes against the explicit wording of the only language standard around
>> at the time (K&R) but, worse, it would produce very fragile code. Just
>> taking a function out into a separate translation unit and placing a
>> corresponding declaration into a suitable header file would change the
>> semantics of some (but all) calls to it.
>
> I have seen a variety of compilers over the years--some good, some bad,
> and have come to the conclusion that it would be far more useful to have
> a standard describe things compilers should do *when practical*, and
> require that compilers document and provide macros to test for cases where
> they can't behave in the preferred fashion, than to have a standard which
> eschews optional features in favor of saying that the only programmers
> should expect are those which are mandatory in all implementations.
>
> There are many embedded applications which don't need recursion and don't
> need ten-digit floating-point support, and I see no reason why it shouldn't
> be possible to have the Standard describe the behavior of low-end platforms
> which can't support all applications but could support many applications
> usefully. A floating-point type with about 9.5 digits of accuracy (32-bit
> mantissa) would on many platforms be a lot cheaper than one with 10, but
> the Standard wouldn't consider such a thing acceptable as a "double". If
> an application could get by with slightly looser precision, which would be
> more useful--a conforming compiler upon which floating-point math is twice
> as slow, or a compiler which doesn't conform to the Standard but does math
> twice as fast (bearing in mind that applications which absolutely need
> 10-digit precision could #if-test DBL_DIG and invoke #error if it's doesn't
> meet requirements).
Are you under the impression that those two long paragraphs are in any
way responsive to what Ben wrote?
The topic under discussion was one very specific thing: whether pre-ANSI
C compilers might pass arguments differently depending on whether or not
the function's definition is visible. (As far as I can tell, the answer
is most likely no.)
What does telling us, yet again, how you think the Standard should be
written have to do with a discussion of the behavior of pre-Standard
compilers?
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2016-12-13 13:04 -0800 |
| Message-ID | <kfnwpf3ilr2.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #98429 |
supercat@casperkitty.com writes: > On Thursday, December 8, 2016 at 4:25:08 PM UTC-6, Ben Bacarisse wrote: >>> True. But until compilers supported prototypes that would often be just as >>> true when a function definition was visible as when it wasn't. There may >>> have been some compilers in the mid-1980s which would keep track of function >>> parameter types and use them to adjust arguments, but that was not a >>> commonplace situation, >> >> I am surprised you even consider it a possibility. For one thing it >> goes against the explicit wording of the only language standard around >> at the time (K&R) but, worse, it would produce very fragile code. Just >> taking a function out into a separate translation unit and placing a >> corresponding declaration into a suitable header file would change the >> semantics of some (but all) calls to it. > > I have seen a variety of compilers over the years--some good, some bad, > and have come to the conclusion that it would be far more useful to have > a standard describe things compilers should do *when practical*, and > require that compilers document and provide macros to test for cases where > they can't behave in the preferred fashion, than to have a standard which > eschews optional features in favor of saying that the only programmers > should expect are those which are mandatory in all implementations. Yes, it's because of such beliefs that standards are needed.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-12-13 13:38 -0800 |
| Message-ID | <c5a7f1b2-d8ce-438b-b8a7-225bbbc46cf5@googlegroups.com> |
| In reply to | #99259 |
On Tuesday, December 13, 2016 at 3:04:40 PM UTC-6, Tim Rentsch wrote: > supercat writes: > > I have seen a variety of compilers over the years--some good, some bad, > > and have come to the conclusion that it would be far more useful to have > > a standard describe things compilers should do *when practical*, and > > require that compilers document and provide macros to test for cases where > > they can't behave in the preferred fashion, than to have a standard which > > eschews optional features in favor of saying that the only programmers > > should expect are those which are mandatory in all implementations. > > Yes, it's because of such beliefs that standards are needed. The normal usage of such phraseology would be to suggest that standards are needed to rein in people like myself with such beliefs, but I'm not sure what you're really trying to say? Do you think that all C implementations should aspire to the same set of features regardless of their target platform or intended purpose, and that programmers who want any kind of portability should only be allowed to use features which are present on even the most obscure platforms? Many standards for things like TCP/IP use the word SHOULD a lot, because there are some features which many or most implementations will be able to provide quite cheaply, but which some implementations (especially on smaller microcontrollers) might not be able to support. The authors' willingness to use SHOULD in TCP/IP standards makes it possible for implementations that can make use of such features to benefit from them, without excessively increasing the system requirements for a minimal TCP/IP implementation.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-12-13 14:07 -0800 |
| Message-ID | <1d7ab1d2-5104-40e4-9bf4-d03ce7fa7653@googlegroups.com> |
| In reply to | #99268 |
On Tuesday, December 13, 2016 at 9:38:41 PM UTC, supe...@casperkitty.com wrote: > > The normal usage of such phraseology would be to suggest that standards > are needed to rein in people like myself with such beliefs, but I'm not > sure what you're really trying to say? Do you think that all C > implementations should aspire to the same set of features regardless of > their target platform or intended purpose, and that programmers who want > any kind of portability should only be allowed to use features which are > present on even the most obscure platforms? > My namesake, Malcom (sic) McLean, revolutionised international shipping by introducing the standard container. Everything had to fit in his containers. If it was too small, you added packing, if it was too large, you had to disassemble it and use two containers. The containers weren't ideal for almost any load - if you got an order for, say, a ten thousand TV sets, it would be unlikely they would precisely pack a whole number of containers. But the economics of shipping were such that standardisation had a huge impact. Hence the growth of China. Now the question is whether standardisation of processors to 64 bits would have an analogous impact on programming. I just don't know the answer. I suspect that the answer is yes.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-12-13 22:51 +0000 |
| Message-ID | <o2ptv2$p0f$1@dont-email.me> |
| In reply to | #99276 |
On 13/12/16 22:07, Malcolm McLean wrote: > My namesake, Malcom (sic) McLean, revolutionised international shipping > by introducing the standard container. Everything had to fit in his > containers. If it was too small, you added packing, if it was too > large, you had to disassemble it and use two containers. No doubt he was known to his friends as Procrustes. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-12-14 08:17 -0800 |
| Message-ID | <7e441935-86ab-4dff-a34a-9e2d09ab0add@googlegroups.com> |
| In reply to | #99276 |
On Tuesday, December 13, 2016 at 4:07:07 PM UTC-6, Malcolm McLean wrote:
> On Tuesday, December 13, 2016 at 9:38:41 PM UTC, supercat wrote:
> >
> > The normal usage of such phraseology would be to suggest that standards
> > are needed to rein in people like myself with such beliefs, but I'm not
> > sure what you're really trying to say? Do you think that all C
> > implementations should aspire to the same set of features regardless of
> > their target platform or intended purpose, and that programmers who want
> > any kind of portability should only be allowed to use features which are
> > present on even the most obscure platforms?
> >
> My namesake, Malcom (sic) McLean, revolutionised international shipping
> by introducing the standard container. Everything had to fit in his
> containers. If it was too small, you added packing, if it was too
> large, you had to disassemble it and use two containers. The containers
> weren't ideal for almost any load - if you got an order for, say,
> a ten thousand TV sets, it would be unlikely they would precisely pack
> a whole number of containers. But the economics of shipping were such
> that standardisation had a huge impact. Hence the growth of China.
>
> Now the question is whether standardisation of processors to 64 bits
> would have an analogous impact on programming. I just don't know the
> answer. I suspect that the answer is yes.
You're describing a philosophy more akin to Java than C. A Java
implementation which is given the code:
long foo(short a, short b, short c, long d) { return (a+b)*c+d; }
must evaluate it the same way whether it's running on a 16-bit (or even 8-
bit CPU) or a 64-bit CPU. The value (a+b) must be evaluated using 32-bit
math an all machines (even 16-bit or 8-bit ones), and lower 32 bits of the
multiply result must be sign-extended before adding d (even on 64-bit
processors).
Modern C philosophy would be more akin to saying that a shipping company
can use whatever kinds of containers it wants, properly-designed shipments
should be prepared for whatever the shipping company chooses to use, and
even if a company's equipment includes well-known support features that
would allow products to be packed more efficiently, customers would not
be entitled to expect the company to use them nor even document their
failure to do so.
What I'd like to see would be akin to a standard means via which companies
can report what forms of containers they can handle. Most companies would
then seek to support containers that were popular with customers, while
customers would seek to use containers that were widely supported. The
marketplace would likely settle on a few containers that would be used for
most purposes, but the most popular set of containers could evolve to fit
changing market needs.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-12-14 11:49 -0800 |
| Message-ID | <45ec41a7-e6cb-420f-b801-1cec50068694@googlegroups.com> |
| In reply to | #99349 |
On Wednesday, December 14, 2016 at 4:17:54 PM UTC, supe...@casperkitty.com wrote:
>
> You're describing a philosophy more akin to Java than C. A Java
> implementation which is given the code:
>
> long foo(short a, short b, short c, long d) { return (a+b)*c+d; }
>
> must evaluate it the same way whether it's running on a 16-bit (or even 8-
> bit CPU) or a 64-bit CPU. The value (a+b) must be evaluated using 32-bit
> math an all machines (even 16-bit or 8-bit ones), and lower 32 bits of the
> multiply result must be sign-extended before adding d (even on 64-bit
> processors).
>
There's some truth in that.
But personally I'd get rid of all the integer types except
signed 64 bit and all real types except 64 bit IEEE 754. And
insist on UTF-8 for strings. So you don't have the problem of
needing to mask for short integer calculations.
>
> Modern C philosophy would be more akin to saying that a shipping company
> can use whatever kinds of containers it wants, properly-designed shipments
> should be prepared for whatever the shipping company chooses to use, and
> even if a company's equipment includes well-known support features that
> would allow products to be packed more efficiently, customers would not
> be entitled to expect the company to use them nor even document their
> failure to do so.
>
A port has a grain elevator that handles cargoes of loose grain.
So of course you can ship loose grain to that port, assuming you've
got a ship suitably set up. But you can't change destination mid
voyage to another port, unless it has a similar grain elevator,
and whilst they'll give you a few months' notice before taking
the grain elevator away, you can't expect the port authorities to
guarantee to continue to keep that elevator in operation,
regardless of the economics.
>
> What I'd like to see would be akin to a standard means via which companies
> can report what forms of containers they can handle. Most companies would
> then seek to support containers that were popular with customers, while
> customers would seek to use containers that were widely supported. The
> marketplace would likely settle on a few containers that would be used for
> most purposes, but the most popular set of containers could evolve to fit
> changing market needs.
>
And to some extent that works. IEEE 754 is pretty much established,
for example. But it's an expensive process.
Really we need another Malcom (sic) McLean to step in and devise a
data container that can handle everything, and that handles almost
everything reasonably well. Then any compliant machine can talk to
any other, and the compliant machines multiply as the standard takes
off. After all, data is easier to package than physical goods, in
many ways.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-12-14 16:53 -0800 |
| Message-ID | <6725a1fb-8a66-4812-b19f-b8ca9cf15e0f@googlegroups.com> |
| In reply to | #99385 |
On Wednesday, December 14, 2016 at 1:49:40 PM UTC-6, Malcolm McLean wrote:
> On Wednesday, December 14, 2016 at 4:17:54 PM UTC, supercat wrote:
> > You're describing a philosophy more akin to Java than C. A Java
> > implementation which is given the code:
> >
> > long foo(short a, short b, short c, long d) { return (a+b)*c+d; }
> >
> > must evaluate it the same way whether it's running on a 16-bit (or even 8-
> > bit CPU) or a 64-bit CPU. The value (a+b) must be evaluated using 32-bit
> > math an all machines (even 16-bit or 8-bit ones), and lower 32 bits of the
> > multiply result must be sign-extended before adding d (even on 64-bit
> > processors).
> >
> There's some truth in that.
> But personally I'd get rid of all the integer types except
> signed 64 bit and all real types except 64 bit IEEE 754. And
> insist on UTF-8 for strings. So you don't have the problem of
> needing to mask for short integer calculations.
If compatibility with existing C programs and implementations weren't
required, using only only double and a wrapping signed 64-bit integer
type for intermediate computations might be reasonable, though vectorized
computations could benefit from using 32-bit floating-point types as
well. Using a 64-bit type for intermediate computations probably wouldn't
hurt performance too much on smaller processors since the "as-if" rule
would allow compilers to perform computations using smaller types in most
cases.
Having more variable-storage types available, however, would be useful
for many applications; if programmers could specify what aspects of
behavior and representation they did and did not care about [e.g. big-
endian, little-endian, or native-endian; fixed clipping, flexible but
deterministic clipping, or non-deterministic clipping, etc.]
> > Modern C philosophy would be more akin to saying that a shipping company
> > can use whatever kinds of containers it wants, properly-designed shipments
> > should be prepared for whatever the shipping company chooses to use, and
> > even if a company's equipment includes well-known support features that
> > would allow products to be packed more efficiently, customers would not
> > be entitled to expect the company to use them nor even document their
> > failure to do so.
> >
> A port has a grain elevator that handles cargoes of loose grain.
> So of course you can ship loose grain to that port, assuming you've
> got a ship suitably set up. But you can't change destination mid
> voyage to another port, unless it has a similar grain elevator,
> and whilst they'll give you a few months' notice before taking
> the grain elevator away, you can't expect the port authorities to
> guarantee to continue to keep that elevator in operation,
> regardless of the economics.
If many customers will need to ship bulk liquids or fine-grained aggregates,
should someone designing a port be more interested in whether the standards
require that ports be equipped to handle such things, or in whether customers
are going to want them? Should customers refrain from taking advantage of
efficient ways of handling bulk liquid/aggregate even if their preferred
ports use them and other ports could do so cheaply?
Having a standards body recommend that ports and ships that who wish to
support bulk loading should use certain kinds of pipe fittings when practical
would avoid situations where 90% of ports support bulk loading from some kind
of ship, but they all use incompatible fittings so most bulk-transport ships
could only service a minority of ports.
> > What I'd like to see would be akin to a standard means via which companies
> > can report what forms of containers they can handle. Most companies would
> > then seek to support containers that were popular with customers, while
> > customers would seek to use containers that were widely supported. The
> > marketplace would likely settle on a few containers that would be used for
> > most purposes, but the most popular set of containers could evolve to fit
> > changing market needs.
> >
> And to some extent that works. IEEE 754 is pretty much established,
> for example. But it's an expensive process.
IEEE-754 places a huge number of requirements on an implementation. I was
thinking of much simpler requirements, e.g. what if anything can be
guaranteed about the behaviors of relational comparisons between unrelated
pointers, shifts by unmasked amounts, integer overflows, and various other
things where simple compilers for many platforms would have to go out of
their way *not* to--at worst--select in Unspecified fashion from among a
small number of possible behaviors [e.g. there are some platforms where the
cheapest way to evaluate p1>p2 in cases where the Standard would mandate its
precise behavior, might yield meaningless results in cases where the Standard
would impose no requirements; on the vast majority of those, however, the
cheapest way would always either yield 0 with no side-effects or yield 1 with
no side-effects].
> Really we need another Malcom (sic) McLean to step in and devise a
> data container that can handle everything, and that handles almost
> everything reasonably well. Then any compliant machine can talk to
> any other, and the compliant machines multiply as the standard takes
> off. After all, data is easier to package than physical goods, in
> many ways.
No, that's not what's needed. Different systems have different abilities,
and different applications have different requirements. What's needed is
a way of matching up application requirements with platform abilities.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-12-15 05:14 -0800 |
| Message-ID | <793ae474-b7f2-4c93-9d78-e0ddd01460e4@googlegroups.com> |
| In reply to | #99430 |
On Thursday, December 15, 2016 at 12:54:03 AM UTC, supe...@casperkitty.com wrote: > > If compatibility with existing C programs and implementations weren't > required, using only only double and a wrapping signed 64-bit integer > type for intermediate computations might be reasonable, though vectorized > computations could benefit from using 32-bit floating-point types as > well. Using a 64-bit type for intermediate computations probably wouldn't > hurt performance too much on smaller processors since the "as-if" rule > would allow compilers to perform computations using smaller types in most > cases. > If #define float double breaks a C program, it can't have been all that well-written. Similarly if int is expanded to 64 bits. But ther 64 bit idea is that, like Malcom McLean's containers, they aren't always full. It's unlikely that your order will exactly fill a whole number of containers. So the last container contains padding. That's an inefficiency but it doesn't matter too much, because it's cheaper to ship a bit of padding than to demand special handling equipment. However there is the issue that smaller processors just have 8 bit registers. I don't know enough about the economics to know if you could replace with a mass-produced 64 bit version and save on the fact that, since everyone uses the same processor, the production runs are much longer. I suspect not, or it would have been done. > > Having more variable-storage types available, however, would be useful > for many applications; if programmers could specify what aspects of > behavior and representation they did and did not care about [e.g. big- > endian, little-endian, or native-endian; fixed clipping, flexible but > deterministic clipping, or non-deterministic clipping, etc.] > The idea of B64 (a vapourware language) is that you have "bit buffers". Named variables are always 64 bits, but will often be a boolean with 63 bits of padding. The boolean can then be placed in the bit buffer at any offset. Functions operate on bit buffers. > > If many customers will need to ship bulk liquids or fine-grained > aggregates, should someone designing a port be more interested > in whether the standards require that ports be equipped to handle > such things, or in whether customers are going to want them? > Should customers refrain from taking advantage of > efficient ways of handling bulk liquid/aggregate even if their > preferred ports use them and other ports could do so cheaply? > > Having a standards body recommend that ports and ships that > who wish to support bulk loading should use certain kinds of > pipe fittings when practical would avoid situations where 90% > of ports support bulk loading from some kind of ship, but they > all use incompatible fittings so most bulk-transport ships > could only service a minority of ports. > Ideally, any ship can unload any cargo, at any port. Which containerisation almost achieves. In fact oil is not containerised and there are other exceptions. But mostly goods go through the container system. You can get little local advantages by not using containers, but they are cancelled out by the efficiency of the overall system. > > > Really we need another Malcom (sic) McLean to step in and devise a > > data container that can handle everything, and that handles almost > > everything reasonably well. Then any compliant machine can talk to > > any other, and the compliant machines multiply as the standard takes > > off. After all, data is easier to package than physical goods, in > > many ways. > > No, that's not what's needed. Different systems have different > abilities, and different applications have different requirements. > What's needed is a way of matching up application requirements with > platform abilities. > If we know that a = b * c always means a 64 bit, signed integer calculation, we know that as long as b and c represent something the calculation can never overflow, and we know that if the code works on our Cray it will also work on our micro-controller. As in elephant, so in E. coli. So the routine is tested, it's ready to go. The only question is whether performing a 64 bit multiply with the microcontroller's 8 bit registers will kill performance. Sometimes it will, so you'll have to buy a better one and that will add a few cents to the product's manufacturing costs. But my MiniBasic found a niche in micro controllers. It's interpreted and not written to be very efficient. Plenty of micro-controller people have cycles to spare.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-12-15 15:02 +0100 |
| Message-ID | <o2u7me$17s$1@dont-email.me> |
| In reply to | #99492 |
On 15/12/16 14:14, Malcolm McLean wrote: > On Thursday, December 15, 2016 at 12:54:03 AM UTC, supe...@casperkitty.com wrote: >> >> If compatibility with existing C programs and implementations weren't >> required, using only only double and a wrapping signed 64-bit integer >> type for intermediate computations might be reasonable, though vectorized >> computations could benefit from using 32-bit floating-point types as >> well. Using a 64-bit type for intermediate computations probably wouldn't >> hurt performance too much on smaller processors since the "as-if" rule >> would allow compilers to perform computations using smaller types in most >> cases. >> > If #define float double breaks a C program, it can't have been all that > well-written. Similarly if int is expanded to 64 bits. Both would break the C programs I write. On a recent program I use single precision floating point in a motor controller. The processor has hardware support for 32-bit floating point operations, but not 64-bit operations. If I had used double, it would take too long and the motor would not work. What you do not understand, Malcolm, is that there are many aspects to correct behaviour. For some programs, getting the answer at the correct time is critical - any answer that comes after the deadline is wrong. And for almost everything I write, if I could not conveniently work with 8-bit, 16-bit and 32-bit precisely sized types, I could not write the program. Making "int" 64-bit would break it all (unless there were extended integer types to allow the intXX_t types - in which case it would simply make the system run needlessly slowly). > But ther 64 bit idea is that, like Malcom McLean's containers, they > aren't always full. It's unlikely that your order will exactly fill > a whole number of containers. So the last container contains padding. > That's an inefficiency but it doesn't matter too much, because > it's cheaper to ship a bit of padding than to demand special handling > equipment. Your 64-bit idea is more akin to making shipping containers that are almost always less than half full, making every ship close to 50% inefficient, just because you /occasionally/ want to ship something that is slightly more than one container in size but not more than two containers in size. And you want to do this despite the current existence of double-sized containers that can be used when needed. It is a /crazy/ idea, IMHO. > However there is the issue that smaller processors just have 8 bit > registers. I don't know enough about the economics to know if you > could replace with a mass-produced 64 bit version and save on the > fact that, since everyone uses the same processor, the production > runs are much longer. I suspect not, or it would have been done. You clearly know very little about the economics of small processors, medium processors, or big processors. 64-bit ints would be appallingly inefficient on 32-bit microcontrollers, never mind 16-bit and 8-bit devices. And more to the point for your little niche world of 64-bit processors (and it /is/ a niche world when you count devices), using 64-bit integers and 64-bit doubles instead of appropriate sizes would drop the efficiency of data caches by a factor of 2 to 8, leading to a marked fall in performance. Graphics, vector processing, SIMD, OpenCL, etc., would be even worse hit. Of course, you could argue that you only mean "int" should be 64, and that other smaller types can be used for storing arrays of data, RGBA pixels, etc. But then you immediately lose any possible benefit that standardising on a single size might have, rendering the whole concept pointless. What are you left with? Making "int" 64-bit because you don't know when to use size_t and feel that "long long int" takes too long to write? <snip more of the same>
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-12-15 08:54 -0800 |
| Message-ID | <9d2e9803-2631-4912-9cca-b616100448d9@googlegroups.com> |
| In reply to | #99494 |
On Thursday, December 15, 2016 at 8:02:19 AM UTC-6, David Brown wrote:
> And for almost everything I write, if I could not conveniently work with
> 8-bit, 16-bit and 32-bit precisely sized types, I could not write the
> program. Making "int" 64-bit would break it all (unless there were
> extended integer types to allow the intXX_t types - in which case it
> would simply make the system run needlessly slowly).
Specifying that intermediate computations yield the same result as if they
were evaluated with a 64-bit type that obeys the laws of modular arithmetic
on overflow would not affect the performance of much code; given something
like:
uint8_t x; // Assume value assigned somehow
int16_t y,z; // Likewise
int16_t w=x*y+z;
a compiler could easily recognize that an 8x16->16 multiply would be
sufficient. If the latter statement had been:
int32_t w=x*y+z;
a compiler would recognize that the result of the multiply needed to be
kept as 24 bits, and likewise the addition. If the programmer didn't want
the compiler to spend effort going beyond 16-bit math, the code could be
written:
int32_t w=(int16_t)(x*y+z);
Given a construct like:
int8_t q = (b1*b2*b3*b4*b5*b6*b7*b8) >> b9;
A compiler might generate needlessly-slow code if b9 never exceeds 8 but the
compiler doesn't know that, but again the situation could be resolved by
adding a cast:
int8_t q = (uint16_t)(b1*b2*b3*b4*b5*b6*b7*b8) >> b9;
I'd suggest that having programmers cast the operands of a right-shift,
divide, or remainder operators in cases where the maximum size isn't needed
would be better than having the evaluation of such expressions depend upon
the target system.
> Your 64-bit idea is more akin to making shipping containers that are
> almost always less than half full, making every ship close to 50%
> inefficient, just because you /occasionally/ want to ship something that
> is slightly more than one container in size but not more than two
> containers in size. And you want to do this despite the current
> existence of double-sized containers that can be used when needed.
On many platforms, using extended-precision types for intermediate floating-
point computations would be more efficient than using the IEEE-754 formats.
When performing computations, having the mantissa be a power-of-two size
(32 or 64 bits) is more helpful than having the overall value be packed into
a power-of-two size. Further, when evaluating an expression like x-y+z,
where all values have the same exponent, converting the temporary result
x-y to an IEEE float or double may on some systems take more time than all
other parts of the calculation *combined*; using a larger intermediate type
would eliminate the need for that step.
> You clearly know very little about the economics of small processors,
> medium processors, or big processors. 64-bit ints would be appallingly
> inefficient on 32-bit microcontrollers, never mind 16-bit and 8-bit
> devices. And more to the point for your little niche world of 64-bit
> processors (and it /is/ a niche world when you count devices), using
> 64-bit integers and 64-bit doubles instead of appropriate sizes would
> drop the efficiency of data caches by a factor of 2 to 8, leading to a
> marked fall in performance. Graphics, vector processing, SIMD, OpenCL,
> etc., would be even worse hit.
Even on 16-bit processors, floating-point math with the IEEE-754 80-bit
extended type can sometimes be more efficient than 32-bit float, and much
more efficient than 64-bit double. A "long float" could be more efficient
yet.
IMHO, it's too bad C specifies that "double" must offer at least 10 decimal
digits, since on many micros a value with a 32-bit mantissa would be the
optimal type for computation.
> Of course, you could argue that you only mean "int" should be 64, and
> that other smaller types can be used for storing arrays of data, RGBA
> pixels, etc. But then you immediately lose any possible benefit that
> standardising on a single size might have, rendering the whole concept
> pointless.
Having intermediate computations performed with uniform types would offer
some semantic advantages versus the current status quo. What I would have
liked to have seen, btw, would have been four standard floating-points,
with semantics that "double" would always promote to "long double" [which
or may not be bigger] and "float" will always promote to "long float" [whose
size and precision may be anywhere between "float" and "long double"]. That
would have mapped well to just about every hardware platform, while allowing
much better defined semantics than what presently exists.
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2016-12-15 19:55 +0000 |
| Message-ID | <5852f323.2827468@news.xs4all.nl> |
| In reply to | #99494 |
David Brown <david.brown@hesbynett.no> wrote: > On 15/12/16 14:14, Malcolm McLean wrote: > > But ther 64 bit idea is that, like Malcom McLean's containers, they > > aren't always full. It's unlikely that your order will exactly fill > > a whole number of containers. So the last container contains padding. > > That's an inefficiency but it doesn't matter too much, because > > it's cheaper to ship a bit of padding than to demand special handling > > equipment. > > Your 64-bit idea is more akin to making shipping containers that are > almost always less than half full, making every ship close to 50% > inefficient, just because you /occasionally/ want to ship something that > is slightly more than one container in size but not more than two > containers in size. And you want to do this despite the current > existence of double-sized containers that can be used when needed. > > It is a /crazy/ idea, IMHO. Not just crazy, it displays a fundamental misunderstanding of the scales involved. Shipping containers work because what's shipped in them is usually so small compared to the containers that it's essentially fungible. You can fill one with half crates of books and half pallets of four televisions each, and it'll transport them just as happily as if the other half of the shipment of tellies wasn't in another container on a completely different corner of the deck. If Malcolm can build a computer that works so that an int doesn't care how many bits of a value are in it and how many bits are in the next one, and also doesn't care how many of its bits belong to another value, and yet still work perfectly well at doing integer computations, _then_ he may have the CPU equivalent of a shipping container. Also, there were standardised and semi-standardised containers well before Mr. MacLean's. What made his ones succesful is not the standardisation /per se/, but the timing: they were introduced just as the post-WWII boom needed them. Good luck getting that to work for microprocessors. Richard
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-12-15 13:48 -0800 |
| Message-ID | <56ae96bb-1046-47b9-ba02-1b54e06d6add@googlegroups.com> |
| In reply to | #99555 |
On Thursday, December 15, 2016 at 7:55:50 PM UTC, Richard Bos wrote: > > Not just crazy, it displays a fundamental misunderstanding of the scales > involved. Shipping containers work because what's shipped in them is > usually so small compared to the containers that it's essentially > fungible. You can fill one with half crates of books and half pallets of > four televisions each, and it'll transport them just as happily as if > the other half of the shipment of tellies wasn't in another container on > a completely different corner of the deck. > If Malcolm can build a computer that works so that an int doesn't care > how many bits of a value are in it and how many bits are in the next > one, and also doesn't care how many of its bits belong to another value, > and yet still work perfectly well at doing integer computations, _then_ > he may have the CPU equivalent of a shipping container. > > Also, there were standardised and semi-standardised containers well > before Mr. MacLean's. What made his ones succesful is not the > standardisation /per se/, but the timing: they were introduced just as > the post-WWII boom needed them. Good luck getting that to work for > microprocessors. > A brick in a London house costs abut 121 pounds. A small processor costs about a pound. So if you embedded a processor in every brick of a London house, you'd effectively leave the price of the house unaltered. That's the new reality. Processing is very cheap, and most processors spend most of their time doing nothing, or grossly underworked (currently mine is acting as a typewriter. The 6502 chip in my Beeb did that job very adequately). Latency matters, but memory and processing is essentially free. Naturally it takes time to adjust. It's still often not possible to access processing on demand, it's still sometimes more important to save a few cents per unit by specifying a processor which is only just capable of the task than it is to save hundreds of dollars per day in programming time, we've still often got to support legacy code which demands that integers be of a certain width rather than wide enough. But why do programming projects fail? Not normally because of micro-efficiency issues. It's rarely the case that buying a faster computer will rescue a troubled software project. I'd suggest they tend to fail because the links between the components become too complex. And integers are not physical goods. 64 bits will hold any integer that represents anything in the real world, or almost - cryptography is a special case because the object is to hide what the data represents, and someone will doubtless come up with a figure for atoms in the Milky Way or something that goes over 2^64. But apart from those, 64 bits is enough. Our containers hold anything anyone could want to put into them.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-12-15 14:20 -0800 |
| Message-ID | <f4ee2d75-75a1-455c-bdf3-af397247f570@googlegroups.com> |
| In reply to | #99573 |
On Thursday, December 15, 2016 at 3:48:19 PM UTC-6, Malcolm McLean wrote: > A brick in a London house costs abut 121 pounds. A small processor > costs about a pound. So if you embedded a processor in every brick > of a London house, you'd effectively leave the price of the house > unaltered. Right, but what of processors that are embedded in goods that cost less than a pound each? Reductions in the cost of processors don't boost the minimum level of processor that is worth implementing so much as they increase the number of places where low-end processors can be put.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-12-15 15:32 -0800 |
| Message-ID | <b9fe6acb-89eb-4e23-9e4f-c00851fe4be9@googlegroups.com> |
| In reply to | #99578 |
On Thursday, December 15, 2016 at 10:20:15 PM UTC, supe...@casperkitty.com wrote: > On Thursday, December 15, 2016 at 3:48:19 PM UTC-6, Malcolm McLean wrote: > > A brick in a London house costs abut 121 pounds. A small processor > > costs about a pound. So if you embedded a processor in every brick > > of a London house, you'd effectively leave the price of the house > > unaltered. > > Right, but what of processors that are embedded in goods that cost > less than a pound each? Reductions in the cost of processors don't > boost the minimum level of processor that is worth implementing so > much as they increase the number of places where low-end processors > can be put. > There's something in that. Once you get the standards right, the cost of the components goes nearly to zero. The industrial revolution entered its modern phase with Babbage's difference engine. The machine itself was a failure, industry just couldn't manufacture the components to the tolerances required. But in the process Babbage created standards for various components. Once any screw can fit any nut, that releases something. It sounds like a small improvement from having screw /nut pairs, in fact it wasn't. Similarly, we will eventually move to a world where any processor can fit with any other. But it has to be done in the right way. Processors are not screws or nuts and bolts. The number of designs might actually go up instead of down, but they'll all have a compatibility. And they'll be as cheap as chips to make. A possible model is the EVA standard for credit / debit cards. These plastic cards have to be made for a few dollars at most, and you need millions of them - practically every European adult has at least one. Every card has to fit every reader. And whilst the chip itself isn't very powerful, it can cause massively powerful calculations to be executed, because it has access to the transaction clearing system network.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-12-15 23:44 +0100 |
| Message-ID | <o2v69h$mca$1@dont-email.me> |
| In reply to | #99573 |
On 15/12/16 22:48, Malcolm McLean wrote: > On Thursday, December 15, 2016 at 7:55:50 PM UTC, Richard Bos wrote: >> >> Not just crazy, it displays a fundamental misunderstanding of the scales >> involved. Shipping containers work because what's shipped in them is >> usually so small compared to the containers that it's essentially >> fungible. You can fill one with half crates of books and half pallets of >> four televisions each, and it'll transport them just as happily as if >> the other half of the shipment of tellies wasn't in another container on >> a completely different corner of the deck. >> If Malcolm can build a computer that works so that an int doesn't care >> how many bits of a value are in it and how many bits are in the next >> one, and also doesn't care how many of its bits belong to another value, >> and yet still work perfectly well at doing integer computations, _then_ >> he may have the CPU equivalent of a shipping container. >> >> Also, there were standardised and semi-standardised containers well >> before Mr. MacLean's. What made his ones succesful is not the >> standardisation /per se/, but the timing: they were introduced just as >> the post-WWII boom needed them. Good luck getting that to work for >> microprocessors. >> > A brick in a London house costs abut 121 pounds. A small processor > costs about a pound. So if you embedded a processor in every brick > of a London house, you'd effectively leave the price of the house > unaltered. That is about as smart as saying that since a key component in every processor is silicon, which you can find on the beach - therefore building a computer is much the same as building a kid's sandcastle. You don't understand the economics here. You don't understand electronics, including the design, manufacturing, sales, etc. You don't understand microcontrollers. You don't understand what is done with electronics, or what is done with microcontrollers. You don't understand the requirements or the possibilities. Please simply accept that, and move on - you are just embarrassing yourself by parading your ignorance here. I knew (on Usenet) an engineer whose job was finding ways to reduce the cost of electronics cards for a particular company. If he found a way to remove a single tiny "chicken feed" component on the board, costing less than a tenth of a cent each, he had justified his salary for a year. That is an extreme example, of course - but there are many, many reasons why what you say is almost completely wrong for anything bigger than a small hobby project. > > That's the new reality. Processing is very cheap, and most processors > spend most of their time doing nothing, or grossly underworked > (currently mine is acting as a typewriter. The 6502 chip in my > Beeb did that job very adequately). Latency matters, but memory > and processing is essentially free. >
[toc] | [prev] | [next] | [standalone]
| From | Gareth Owen <gwowen@gmail.com> |
|---|---|
| Date | 2016-12-16 07:00 +0000 |
| Message-ID | <87k2b0jr4a.fsf@gmail.com> |
| In reply to | #99580 |
David Brown <david.brown@hesbynett.no> writes: > You don't understand the economics here. You don't understand > electronics, including the design, manufacturing, sales, etc. You > don't understand microcontrollers. You don't understand what is done > with electronics, or what is done with microcontrollers. You don't > understand the requirements or the possibilities. Yup. That's Malcolm's defining characteristic. That and an unshakeable belief in his own correctness.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-12-16 08:21 +0000 |
| Message-ID | <o3083u$6tf$1@dont-email.me> |
| In reply to | #99601 |
On 16/12/16 07:00, Gareth Owen wrote: > David Brown <david.brown@hesbynett.no> writes: > >> You don't understand the economics here. You don't understand >> electronics, including the design, manufacturing, sales, etc. You >> don't understand microcontrollers. You don't understand what is done >> with electronics, or what is done with microcontrollers. You don't >> understand the requirements or the possibilities. > > Yup. That's Malcolm's defining characteristic. > That and an unshakeable belief in his own correctness. His /two/ defining characteristics are: a failure to understand the requirements or the possibilities, an unshakeable belief in his own correctness, and an almost fanatical devotion to the Pope. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Gareth Owen <gwowen@gmail.com> |
|---|---|
| Date | 2016-12-16 21:10 +0000 |
| Message-ID | <877f6zfumt.fsf@gmail.com> |
| In reply to | #99603 |
Richard Heathfield <rjh@cpax.org.uk> writes: > On 16/12/16 07:00, Gareth Owen wrote: >> David Brown <david.brown@hesbynett.no> writes: >> >>> You don't understand the economics here. You don't understand >>> electronics, including the design, manufacturing, sales, etc. You >>> don't understand microcontrollers. You don't understand what is done >>> with electronics, or what is done with microcontrollers. You don't >>> understand the requirements or the possibilities. >> >> Yup. That's Malcolm's defining characteristic. >> That and an unshakeable belief in his own correctness. > > His /two/ defining characteristics are: a failure to understand the > requirements or the possibilities, an unshakeable belief in his own > correctness, and an almost fanatical devotion to the Pope. No ... wait. *Among* his defining characteristics are a failure to understand the requirements or the possibilities, an unshakeable belief in his own correctness, an almost fanatical devotion to the Pope, fear, surprise and ruthless efficiency. ... I'm sorry, I'll come in again.
[toc] | [prev] | [next] | [standalone]
Page 21 of 29 — ← Prev page 1 … 19 20 [21] 22 23 … 29 Next page →
Back to top | Article view | comp.lang.c
csiph-web