Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #156943 > unrolled thread
| Started by | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| First post | 2020-12-05 08:25 -0800 |
| Last post | 2021-01-06 23:07 -0800 |
| Articles | 20 on this page of 399 — 24 participants |
Back to article view | Back to comp.lang.c
Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-05 08:25 -0800
Re: Programming exercise/challenge Sjouke Burry <burrynulnulfour@ppllaanneett.nnll> - 2020-12-05 17:33 +0100
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-06 11:58 -0800
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-30 09:40 -0800
Re: Programming exercise/challenge Bart <bc@freeuk.com> - 2020-12-30 18:20 +0000
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-31 01:04 -0800
Re: Programming exercise/challenge Anton Shepelev <anton.txt@gmail.com> - 2021-01-02 22:05 +0300
Re: Programming exercise/challenge Richard Damon <Richard@Damon-Family.org> - 2021-01-02 14:48 -0500
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-01-02 19:17 -0800
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-01-02 19:04 -0800
Re: Programming exercise/challenge Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-30 21:44 +0000
Re: Programming exercise/challenge Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-31 02:54 +0000
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-01-03 09:49 -0800
Re: Programming exercise/challenge Anton Shepelev <anton.txt@gmail.com> - 2021-01-04 00:15 +0300
Re: Programming exercise/challenge Kaz Kylheku <563-365-8930@kylheku.com> - 2021-01-03 21:57 +0000
Re: Programming exercise/challenge Bart <bc@freeuk.com> - 2021-01-03 23:00 +0000
Re: Programming exercise/challenge Kaz Kylheku <563-365-8930@kylheku.com> - 2021-01-04 00:00 +0000
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-01-04 20:04 -0800
Re: Programming exercise/challenge Kaz Kylheku <563-365-8930@kylheku.com> - 2021-01-05 07:15 +0000
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-01-07 22:30 -0800
Re: Programming exercise/challenge Kaz Kylheku <563-365-8930@kylheku.com> - 2021-01-04 18:42 +0000
Re: Programming exercise/challenge Kaz Kylheku <563-365-8930@kylheku.com> - 2021-01-04 21:23 +0000
Re: Programming exercise/challenge Kaz Kylheku <563-365-8930@kylheku.com> - 2021-01-04 23:41 +0000
Re: Programming exercise/challenge Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-05 16:39 +0000
Re: Programming exercise/challenge Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-05 16:58 +0000
Re: Programming exercise/challenge Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-05 17:08 +0000
Re: Programming exercise/challenge Bart <bc@freeuk.com> - 2020-12-05 17:11 +0000
Re: Programming exercise/challenge Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-05 17:24 +0000
Re: Programming exercise/challenge Bart <bc@freeuk.com> - 2020-12-05 17:52 +0000
Re: Programming exercise/challenge Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-05 18:30 +0000
Re: Programming exercise/challenge Bart <bc@freeuk.com> - 2020-12-05 19:56 +0000
Re: Programming exercise/challenge Bart <bc@freeuk.com> - 2020-12-06 14:51 +0000
Re: Programming exercise/challenge Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-05 17:49 +0000
Re: Programming exercise/challenge Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-05 18:34 +0000
Re: Programming exercise/challenge Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-05 19:40 +0100
Re: Programming exercise/challenge Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-05 18:47 +0000
Re: Programming exercise/challenge Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-05 23:19 +0000
Re: Programming exercise/challenge Bart <bc@freeuk.com> - 2020-12-05 23:56 +0000
Re: Programming exercise/challenge Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-08 02:26 +0000
Re: Programming exercise/challenge Anton Shepelev <anton.txt@gmail.com> - 2020-12-08 16:04 +0300
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-08 23:39 -0800
Re: Programming exercise/challenge Anton Shepelev <anton.txt@gmail.com> - 2020-12-12 23:34 +0300
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-12 19:28 -0800
Re: Programming exercise/challenge kegs@provalid.com (Kent Dickey) - 2020-12-29 10:34 -0600
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-29 20:05 -0800
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-06 06:03 -0800
Re: Programming exercise/challenge dfs <nospam@dfs.com> - 2020-12-05 13:58 -0500
Re: Programming exercise/challenge Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-12-05 21:37 +0000
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-06 06:13 -0800
Re: Programming exercise/challenge jacobnavia <jacob@jacob.remcomp.fr> - 2020-12-06 18:00 +0100
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-06 12:31 -0800
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-06 06:26 -0800
Re: Programming exercise/challenge jacobnavia <jacob@jacob.remcomp.fr> - 2020-12-05 23:32 +0100
Re: Programming exercise/challenge jacobnavia <jacob@jacob.remcomp.fr> - 2020-12-06 17:18 +0100
Re: Programming exercise/challenge jacobnavia <jacob@jacob.remcomp.fr> - 2020-12-06 17:51 +0100
Re: Programming exercise/challenge Bart <bc@freeuk.com> - 2020-12-06 22:27 +0000
Re: Programming exercise/challenge jacobnavia <jacob@jacob.remcomp.fr> - 2020-12-07 09:37 +0100
Re: Programming exercise/challenge Richard Damon <Richard@Damon-Family.org> - 2020-12-07 07:36 -0500
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-08 22:49 -0800
Re: Programming exercise/challenge Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-06 17:51 +0000
Re: Programming exercise/challenge dfs <nospam@dfs.com> - 2020-12-06 13:03 -0500
Re: Programming exercise/challenge Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-06 23:53 +0000
Re: Programming exercise/challenge Bart <bc@freeuk.com> - 2020-12-06 19:53 +0000
Re: Programming exercise/challenge Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-06 23:38 +0000
Re: Programming exercise/challenge Bart <bc@freeuk.com> - 2020-12-07 00:17 +0000
Re: Programming exercise/challenge Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-07 02:09 +0000
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-07 01:03 -0800
Re: Programming exercise/challenge Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-07 12:05 +0000
Re: Programming exercise/challenge Bart <bc@freeuk.com> - 2020-12-07 12:25 +0000
Re: Programming exercise/challenge Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-07 13:33 +0000
Re: Programming exercise/challenge Bart <bc@freeuk.com> - 2020-12-07 14:18 +0000
Re: Programming exercise/challenge Bart <bc@freeuk.com> - 2020-12-07 14:31 +0000
Re: Programming exercise/challenge Richard Damon <Richard@Damon-Family.org> - 2020-12-07 12:58 -0500
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-08 23:03 -0800
Re: Programming exercise/challenge Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-12-07 07:12 -0800
Re: Programming exercise/challenge Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-07 21:55 +0000
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-08 22:59 -0800
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-08 22:55 -0800
Re: Programming exercise/challenge Richard Damon <Richard@Damon-Family.org> - 2020-12-09 07:45 -0500
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-24 11:26 -0800
Re: Programming exercise/challenge Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-12-24 12:24 -0800
Re: Programming exercise/challenge Richard Damon <Richard@Damon-Family.org> - 2020-12-24 17:19 -0500
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-27 05:16 -0800
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-27 04:17 -0800
Re: Programming exercise/challenge Richard Damon <Richard@Damon-Family.org> - 2020-12-27 08:27 -0500
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-29 19:18 -0800
Re: Programming exercise/challenge Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-12-07 05:15 -0800
Re: Programming exercise/challenge Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-07 13:42 +0000
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-08 22:53 -0800
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-10 01:49 -0800
Re: Programming exercise/challenge Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-10 22:35 +0000
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-10 21:17 -0800
Re: Programming exercise/challenge Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-12 21:44 +0000
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-12 19:46 -0800
Re: Programming exercise/challenge Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-13 12:21 +0000
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-24 11:35 -0800
Re: Programming exercise/challenge Rosario19 <Ros@invalid.invalid> - 2020-12-31 00:46 +0100
Re: Programming exercise/challenge Rosario19 <Ros@invalid.invalid> - 2020-12-31 00:52 +0100
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-31 00:34 -0800
Re: Programming exercise/challenge Rosario19 <Ros@invalid.invalid> - 2021-01-01 08:23 +0100
Re: Programming exercise/challenge Rosario19 <Ros@invalid.invalid> - 2021-01-01 10:09 +0100
Re: Programming exercise/challenge Rosario19 <Ros@invalid.invalid> - 2021-01-01 11:38 +0100
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-01-01 08:24 -0800
Re: Programming exercise/challenge "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2020-12-07 07:03 -0800
Re: Programming exercise/challenge Anton Shepelev <anton.txt@gmail.com> - 2020-12-08 02:16 +0300
Re: Programming exercise/challenge Anton Shepelev <anton.txt@gmail.com> - 2020-12-09 02:39 +0300
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-08 23:18 -0800
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-08 23:17 -0800
Re: Programming exercise/challenge Anton Shepelev <anton.txt@gmail.com> - 2020-12-08 00:27 +0300
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-08 23:20 -0800
Re: Programming exercise/challenge luser droog <luser.droog@gmail.com> - 2020-12-07 13:44 -0800
Re: Programming exercise/challenge luser droog <luser.droog@gmail.com> - 2020-12-07 14:01 -0800
Re: Programming exercise/challenge Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-07 22:16 +0000
Re: Programming exercise/challenge luser droog <luser.droog@gmail.com> - 2020-12-07 15:10 -0800
Re: Programming exercise/challenge Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-08 01:07 +0000
Re: Programming exercise/challenge Bart <bc@freeuk.com> - 2020-12-08 00:34 +0000
Re: Programming exercise/challenge luser droog <luser.droog@gmail.com> - 2020-12-08 18:17 -0800
Re: Programming exercise/challenge luser droog <luser.droog@gmail.com> - 2020-12-09 00:56 -0800
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-09 02:30 -0800
Re: Programming exercise/challenge luser droog <luser.droog@gmail.com> - 2020-12-09 15:14 -0800
Re: Programming exercise/challenge luser droog <luser.droog@gmail.com> - 2020-12-09 15:44 -0800
Re: Programming exercise/challenge Anton Shepelev <anton.txt@gmail.com> - 2020-12-12 23:56 +0300
Re: Programming exercise/challenge luser droog <luser.droog@gmail.com> - 2020-12-12 13:29 -0800
Re: Programming exercise/challenge Anton Shepelev <anton.txt@gmail.com> - 2020-12-13 00:46 +0300
Re: Programming exercise/challenge luser droog <luser.droog@gmail.com> - 2020-12-12 13:59 -0800
Re: Programming exercise/challenge Anton Shepelev <anton.txt@gmail.com> - 2020-12-13 14:17 +0300
Re: Programming exercise/challenge luser droog <luser.droog@gmail.com> - 2020-12-13 12:58 -0800
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-13 20:57 -0800
Re: Programming exercise/challenge luser droog <luser.droog@gmail.com> - 2020-12-14 20:44 -0800
Re: Programming exercise/challenge luser droog <luser.droog@gmail.com> - 2020-12-23 11:15 -0800
Re: Programming exercise/challenge Anton Shepelev <anton.txt@gmail.com> - 2020-12-23 23:45 +0300
Re: Programming exercise/challenge luser droog <luser.droog@gmail.com> - 2020-12-23 21:36 -0800
Re: Programming exercise/challenge luser droog <luser.droog@gmail.com> - 2020-12-24 09:11 -0800
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-24 15:30 -0800
Re: Programming exercise/challenge luser droog <luser.droog@gmail.com> - 2020-12-24 23:18 -0800
Re: Programming exercise/challenge luser droog <luser.droog@gmail.com> - 2020-12-24 23:56 -0800
Re: Programming exercise/challenge luser droog <luser.droog@gmail.com> - 2020-12-28 12:01 -0800
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-29 19:31 -0800
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-24 14:47 -0800
Re: Programming exercise/challenge Anton Shepelev <anton.txt@gmail.com> - 2020-12-08 01:59 +0300
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-08 23:26 -0800
Re: Programming exercise/challenge Richard Damon <Richard@Damon-Family.org> - 2020-12-07 19:02 -0500
Re: Programming exercise/challenge Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-08 01:15 +0000
Re: Programming exercise/challenge Richard Damon <Richard@Damon-Family.org> - 2020-12-07 20:38 -0500
Re: Programming exercise/challenge Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-08 02:19 +0000
Re: Programming exercise/challenge Bart <bc@freeuk.com> - 2020-12-08 11:44 +0000
Re: Programming exercise/challenge Richard Damon <Richard@Damon-Family.org> - 2020-12-08 07:32 -0500
Re: Programming exercise/challenge Bart <bc@freeuk.com> - 2020-12-08 14:40 +0000
Re: Programming exercise/challenge "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2020-12-08 06:52 -0800
Re: Programming exercise/challenge Bart <bc@freeuk.com> - 2020-12-08 17:31 +0000
Re: Programming exercise/challenge Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-08 20:16 +0000
Re: Programming exercise/challenge Bart <bc@freeuk.com> - 2020-12-08 20:48 +0000
Re: Programming exercise/challenge Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-12-08 15:34 -0800
Re: Programming exercise/challenge Anton Shepelev <anton.txt@gmail.com> - 2020-12-09 02:54 +0300
Re: Programming exercise/challenge Anton Shepelev <anton.txt@gmail.com> - 2020-12-09 12:33 +0300
Re: Programming exercise/challenge Anton Shepelev <anton.txt@gmail.com> - 2020-12-09 12:43 +0300
Re: Programming exercise/challenge Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-12-09 01:52 -0800
Re: Programming exercise/challenge Anton Shepelev <anton.txt@gmail.com> - 2020-12-13 00:28 +0300
Re: Programming exercise/challenge Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-12 21:40 +0000
Re: Programming exercise/challenge Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-12-12 13:48 -0800
Re: Programming exercise/challenge Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-12-09 01:46 -0800
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-08 23:29 -0800
Re: Programming exercise/challenge Richard Damon <Richard@Damon-Family.org> - 2020-12-08 10:45 -0500
Re: Programming exercise/challenge Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-08 17:16 +0000
Re: Programming exercise/challenge "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2020-12-08 06:39 -0800
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-07 17:48 -0800
Re: Programming exercise/challenge Richard Damon <Richard@Damon-Family.org> - 2020-12-07 21:03 -0500
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-09 03:02 -0800
Re: Programming exercise/challenge Richard Damon <Richard@Damon-Family.org> - 2020-12-09 08:02 -0500
Re: Programming exercise/challenge Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-09 16:49 +0000
Re: Programming exercise/challenge Richard Damon <Richard@Damon-Family.org> - 2020-12-09 13:33 -0500
Re: Programming exercise/challenge Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-09 19:57 +0000
Re: Programming exercise/challenge Bart <bc@freeuk.com> - 2020-12-10 01:45 +0000
Re: Programming exercise/challenge Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2020-12-10 02:15 +0000
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-24 11:24 -0800
Re: Programming exercise/challenge Richard Damon <Richard@Damon-Family.org> - 2020-12-09 21:57 -0500
Re: Programming exercise/challenge Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-10 03:32 +0000
Re: Programming exercise/challenge Richard Damon <Richard@Damon-Family.org> - 2020-12-10 08:19 -0500
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-24 11:04 -0800
Re: Programming exercise/challenge Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-24 19:34 +0000
Re: Programming exercise/challenge Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-08 02:22 +0000
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-09 03:04 -0800
Re: Programming exercise/challenge Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-09 11:59 +0000
Re: Programming exercise/challenge Richard Damon <Richard@Damon-Family.org> - 2020-12-09 08:11 -0500
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-10 00:02 -0800
Re: Programming exercise/challenge Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-10 15:12 +0000
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-10 10:36 -0800
Re: Programming exercise/challenge Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-10 22:11 +0000
Re: Programming exercise/challenge Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-10 23:34 +0000
Re: Programming exercise/challenge "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2020-12-10 20:11 -0800
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-10 21:06 -0800
Re: Programming exercise/challenge Anton Shepelev <anton.txt@gmail.com> - 2020-12-09 03:03 +0300
Re: Programming exercise/challenge Richard Damon <Richard@Damon-Family.org> - 2020-12-08 21:21 -0500
Re: Programming exercise/challenge Anton Shepelev <anton.txt@gmail.com> - 2020-12-09 12:50 +0300
Re: Programming exercise/challenge Richard Damon <Richard@Damon-Family.org> - 2020-12-09 08:16 -0500
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-08 23:32 -0800
Re: Programming exercise/challenge Bart <bc@freeuk.com> - 2020-12-09 12:21 +0000
Re: Programming exercise/challenge Bart <bc@freeuk.com> - 2021-01-02 19:15 +0000
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-01-07 01:54 -0800
Re: Programming exercise/challenge Bart <bc@freeuk.com> - 2021-01-22 22:36 +0000
Re: Programming exercise/challenge Bart <bc@freeuk.com> - 2021-01-22 23:07 +0000
Re: Programming exercise/challenge Dave Dunfield <dave.dunfield@gmail.com> - 2021-01-22 20:27 -0800
Re: Programming exercise/challenge Bart <bc@freeuk.com> - 2021-01-23 13:05 +0000
Re: Programming exercise/challenge Dave Dunfield <dave.dunfield@gmail.com> - 2021-01-23 07:45 -0800
Re: Programming exercise/challenge Bart <bc@freeuk.com> - 2021-01-23 16:49 +0000
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-01-23 11:22 -0800
Re: Programming exercise/challenge Bart <bc@freeuk.com> - 2021-01-23 16:53 +0000
Re: Programming exercise/challenge Dave Dunfield <dave.dunfield@gmail.com> - 2021-01-23 09:55 -0800
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-01-23 21:35 -0800
Re: Programming exercise/challenge Bart <bc@freeuk.com> - 2021-01-24 18:17 +0000
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-01-27 07:57 -0800
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-01-23 11:28 -0800
Re: Programming exercise/challenge "jfbod...@gmail.com" <jfbode1029@gmail.com> - 2020-12-08 11:30 -0800
Re: Programming exercise/challenge Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-08 20:31 +0000
Re: Programming exercise/challenge jacobnavia <jacob@jacob.remcomp.fr> - 2020-12-08 22:17 +0100
Re: Programming exercise/challenge jacobnavia <jacob@jacob.remcomp.fr> - 2020-12-08 22:15 +0100
Re: Programming exercise/challenge "jfbod...@gmail.com" <jfbode1029@gmail.com> - 2020-12-08 13:28 -0800
Re: Programming exercise/challenge "jfbod...@gmail.com" <jfbode1029@gmail.com> - 2020-12-09 12:05 -0800
Re: Programming exercise/challenge Anton Shepelev <anton.txt@gmail.com> - 2020-12-13 00:04 +0300
Re: Programming exercise/challenge Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2020-12-08 21:38 +0000
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-09 03:25 -0800
Re: Programming exercise/challenge Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-09 01:00 +0000
Re: Programming exercise/challenge Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-09 03:09 +0000
Re: Programming exercise/challenge Anton Shepelev <anton.txt@gmail.com> - 2020-12-13 00:35 +0300
Re: Programming exercise/challenge Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-12 22:57 +0000
Re: Programming exercise/challenge Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-12 23:43 +0000
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-12 19:47 -0800
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-12 23:27 -0800
Re: Programming exercise/challenge Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-13 14:44 +0000
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-24 11:47 -0800
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-09 03:36 -0800
Re: Programming exercise/challenge Anton Shepelev <anton.txt@gmail.com> - 2020-12-09 14:51 +0300
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-09 11:35 -0800
Re: Programming exercise/challenge Anton Shepelev <anton.txt@gmail.com> - 2020-12-10 02:33 +0300
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-10 00:05 -0800
Re: Programming exercise/challenge Anton Shepelev <anton.txt@gmail.com> - 2020-12-10 14:59 +0300
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-10 20:32 -0800
Re: Programming exercise/challenge Anton Shepelev <anton.txt@gmail.com> - 2020-12-12 23:45 +0300
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-12 19:24 -0800
Re: Programming exercise/challenge Anton Shepelev <anton.txt@gmail.com> - 2020-12-13 00:17 +0300
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-12 19:23 -0800
Re: Programming exercise/challenge Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-09 19:31 +0000
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-09 12:01 -0800
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-09 12:25 -0800
Re: Programming exercise/challenge kegs@provalid.com (Kent Dickey) - 2020-12-23 01:00 -0600
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-24 14:34 -0800
Re: Programming exercise/challenge kegs@provalid.com (Kent Dickey) - 2020-12-26 23:03 -0600
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-27 06:29 -0800
Re: Programming exercise/challenge kegs@provalid.com (Kent Dickey) - 2020-12-28 11:52 -0600
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-29 00:38 -0800
Re: Programming exercise/challenge Anton Shepelev <anton.txt@gmail.com> - 2020-12-28 15:29 +0300
Re: Programming exercise/challenge kegs@provalid.com (Kent Dickey) - 2020-12-28 17:12 -0600
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-28 23:54 -0800
Re: Programming exercise/challenge kegs@provalid.com (Kent Dickey) - 2020-12-29 10:26 -0600
Re: Programming exercise/challenge kegs@provalid.com (Kent Dickey) - 2020-12-29 10:37 -0600
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-29 19:59 -0800
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-30 09:17 -0800
Re: Programming exercise/challenge Anton Shepelev <anton.txt@gmail.com> - 2020-12-31 16:54 +0300
Re: Programming exercise/challenge kegs@provalid.com (Kent Dickey) - 2020-12-31 09:16 -0600
Re: Programming exercise/challenge Bart <bc@freeuk.com> - 2020-12-31 15:56 +0000
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-01-07 02:41 -0800
Re: Programming exercise/challenge Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-12-31 13:01 -0800
Re: Programming exercise/challenge Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-12-31 14:15 -0800
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-01-01 08:03 -0800
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-01-01 07:42 -0800
Re: Programming exercise/challenge Anton Shepelev <anton.txt@gmail.com> - 2021-01-02 21:59 +0300
Re: Programming exercise/challenge Richard Damon <Richard@Damon-Family.org> - 2021-01-02 14:52 -0500
Re: Programming exercise/challenge Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2021-01-02 12:30 -0800
Re: Programming exercise/challenge James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-01-02 18:17 -0500
Re: Programming exercise/challenge Richard Damon <Richard@Damon-Family.org> - 2021-01-02 19:22 -0500
Re: Programming exercise/challenge Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-01-02 17:48 -0800
Re: Programming exercise/challenge James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-01-02 22:35 -0500
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-01-02 18:02 -0800
Re: Programming exercise/challenge Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-01-03 00:42 -0800
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-01-04 20:12 -0800
Re: Programming exercise/challenge Dave Dunfield <dave.dunfield@gmail.com> - 2021-01-04 07:04 -0800
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-01-04 20:22 -0800
Re: Programming exercise/challenge Dave Dunfield <dave.dunfield@gmail.com> - 2021-01-05 04:24 -0800
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-01-05 06:22 -0800
Re: Programming exercise/challenge Dave Dunfield <dave.dunfield@gmail.com> - 2021-01-05 08:55 -0800
Re: Programming exercise/challenge Anton Shepelev <anton.txt@gmail.com> - 2021-01-05 20:22 +0300
Re: Programming exercise/challenge Anton Shepelev <anton.txt@gmail.com> - 2021-01-05 20:27 +0300
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-01-05 14:20 -0800
Re: Programming exercise/challenge Kaz Kylheku <563-365-8930@kylheku.com> - 2021-01-05 17:23 +0000
Re: Programming exercise/challenge Dave Dunfield <dave.dunfield@gmail.com> - 2021-01-05 10:18 -0800
Re: Programming exercise/challenge Kaz Kylheku <563-365-8930@kylheku.com> - 2021-01-05 18:57 +0000
Re: Programming exercise/challenge Dave Dunfield <dave.dunfield@gmail.com> - 2021-01-05 12:58 -0800
Re: Programming exercise/challenge Richard Damon <Richard@Damon-Family.org> - 2021-01-05 17:31 -0500
Re: Programming exercise/challenge James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-01-05 17:50 -0500
Re: Programming exercise/challenge Dave Dunfield <dave.dunfield@gmail.com> - 2021-01-05 19:33 -0800
Re: Programming exercise/challenge Richard Damon <Richard@Damon-Family.org> - 2021-01-05 23:02 -0500
Re: Programming exercise/challenge Dave Dunfield <dave.dunfield@gmail.com> - 2021-01-05 21:00 -0800
Re: Programming exercise/challenge Richard Damon <Richard@Damon-Family.org> - 2021-01-06 07:42 -0500
Re: Programming exercise/challenge Dave Dunfield <dave.dunfield@gmail.com> - 2021-01-06 08:55 -0800
Re: Programming exercise/challenge Richard Damon <Richard@Damon-Family.org> - 2021-01-06 13:29 -0500
Re: Programming exercise/challenge Dave Dunfield <dave.dunfield@gmail.com> - 2021-01-06 14:09 -0800
Re: Programming exercise/challenge James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-01-06 22:11 -0500
Re: Programming exercise/challenge Dave Dunfield <dave.dunfield@gmail.com> - 2021-01-07 03:10 -0800
Re: Programming exercise/challenge Richard Damon <Richard@Damon-Family.org> - 2021-01-07 06:40 -0500
Re: Programming exercise/challenge Dave Dunfield <dave.dunfield@gmail.com> - 2021-01-09 06:27 -0800
Re: Programming exercise/challenge Dave Dunfield <dave.dunfield@gmail.com> - 2021-01-10 04:32 -0800
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-01-11 06:58 -0800
Re: Programming exercise/challenge Dave Dunfield <dave.dunfield@gmail.com> - 2021-01-11 14:40 -0800
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-01-15 09:46 -0800
Re: Programming exercise/challenge Dave Dunfield <dave.dunfield@gmail.com> - 2021-01-17 04:13 -0800
Re: Programming exercise/challenge Bart <bc@freeuk.com> - 2021-01-17 14:18 +0000
Re: Programming exercise/challenge Kaz Kylheku <563-365-8930@kylheku.com> - 2021-01-17 18:02 +0000
Re: Programming exercise/challenge Richard Damon <Richard@Damon-Family.org> - 2021-01-17 15:12 -0500
Re: Programming exercise/challenge Bart <bc@freeuk.com> - 2021-01-17 21:39 +0000
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-01-20 10:57 -0800
Re: Programming exercise/challenge Dave Dunfield <dave.dunfield@gmail.com> - 2021-01-21 11:37 -0800
Re: Programming exercise/challenge James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-01-22 00:30 -0500
Re: Programming exercise/challenge Dave Dunfield <dave.dunfield@gmail.com> - 2021-01-22 09:09 -0800
Re: Programming exercise/challenge James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-01-22 13:47 -0500
Re: Programming exercise/challenge Kaz Kylheku <563-365-8930@kylheku.com> - 2021-01-22 19:00 +0000
Re: Programming exercise/challenge Bart <bc@freeuk.com> - 2021-01-22 19:42 +0000
Re: Programming exercise/challenge Kaz Kylheku <563-365-8930@kylheku.com> - 2021-01-22 21:16 +0000
Re: Programming exercise/challenge James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-01-22 16:41 -0500
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-01-23 17:46 -0800
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-01-23 09:51 -0800
Re: Programming exercise/challenge Kaz Kylheku <563-365-8930@kylheku.com> - 2021-01-23 18:38 +0000
Re: Programming exercise/challenge Dave Dunfield <dave.dunfield@gmail.com> - 2021-01-23 04:52 -0800
Re: Programming exercise/challenge Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-01-23 15:45 +0000
Re: Programming exercise/challenge Dave Dunfield <dave.dunfield@gmail.com> - 2021-01-23 09:04 -0800
Re: Programming exercise/challenge Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-01-23 23:10 +0000
Re: Programming exercise/challenge Dave Dunfield <dave.dunfield@gmail.com> - 2021-01-23 15:39 -0800
Re: Programming exercise/challenge Kaz Kylheku <563-365-8930@kylheku.com> - 2021-01-23 15:59 +0000
Re: Programming exercise/challenge James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-01-25 11:40 -0500
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-01-23 09:47 -0800
Re: Programming exercise/challenge Kaz Kylheku <563-365-8930@kylheku.com> - 2021-01-23 18:32 +0000
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-01-23 17:26 -0800
Re: Programming exercise/challenge Bart <bc@freeuk.com> - 2021-01-24 01:55 +0000
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-01-27 08:40 -0800
Re: Programming exercise/challenge Dave Dunfield <dave.dunfield@gmail.com> - 2021-01-23 20:51 -0800
Re: Programming exercise/challenge Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-01-24 02:28 -0800
Re: Programming exercise/challenge Dave Dunfield <dave.dunfield@gmail.com> - 2021-01-24 03:49 -0800
Re: Programming exercise/challenge Anton Shepelev <anton.txt@gmail.com> - 2021-01-24 15:38 +0300
Re: Programming exercise/challenge Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-01-24 14:04 -0800
Re: Programming exercise/challenge Dave Dunfield <dave.dunfield@gmail.com> - 2021-01-25 07:26 -0800
Re: Programming exercise/challenge David Brown <david.brown@hesbynett.no> - 2021-01-25 16:58 +0100
Re: Programming exercise/challenge luser droog <luser.droog@gmail.com> - 2021-01-25 09:14 -0800
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-01-27 07:32 -0800
Re: Programming exercise/challenge Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-01-27 16:24 +0000
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-01-28 00:11 -0800
Re: Programming exercise/challenge Anton Shepelev <anton.txt@g{oogle}mail.com> - 2021-01-28 12:25 +0300
Re: Programming exercise/challenge James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-01-28 06:18 -0500
Re: Programming exercise/challenge Anton Shepelev <anton.txt@g{oogle}mail.com> - 2021-01-28 16:54 +0300
Re: Programming exercise/challenge James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-01-28 09:15 -0500
Re: Programming exercise/challenge Anton Shepelev <anton.txt@g{oogle}mail.com> - 2021-01-28 20:07 +0300
Re: Programming exercise/challenge James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-01-28 15:58 -0500
Re: Programming exercise/challenge Anton Shepelev <anton.txt@gmail.com> - 2021-01-29 00:07 +0300
Re: Programming exercise/challenge James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-01-28 16:17 -0500
Re: Programming exercise/challenge Anton Shepelev <anton.txt@gmail.com> - 2021-01-29 00:03 +0300
Re: Programming exercise/challenge Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2021-01-28 03:37 -0800
Re: Programming exercise/challenge Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-01-28 22:50 +0000
Re: Programming exercise/challenge Anton Shepelev <anton.txt@gmail.com> - 2021-01-30 23:14 +0300
Re: Programming exercise/challenge Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-01-30 20:49 +0000
Re: Programming exercise/challenge M Joshua Ryan <luser.droog@gmail.com> - 2021-01-28 00:05 -0600
Re: Programming exercise/challenge Dave Dunfield <dave.dunfield@gmail.com> - 2021-01-27 11:51 -0800
Re: Programming exercise/challenge Bart <bc@freeuk.com> - 2021-01-25 17:22 +0000
Re: Programming exercise/challenge Dave Dunfield <dave.dunfield@gmail.com> - 2021-01-25 12:21 -0800
Re: Programming exercise/challenge Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-01-25 14:27 -0800
Re: Programming exercise/challenge Dave Dunfield <dave.dunfield@gmail.com> - 2021-01-25 19:41 -0800
Re: Programming exercise/challenge Kaz Kylheku <563-365-8930@kylheku.com> - 2021-01-26 04:46 +0000
Re: Programming exercise/challenge Dave Dunfield <dave.dunfield@gmail.com> - 2021-01-26 06:30 -0800
Re: Programming exercise/challenge David Brown <david.brown@hesbynett.no> - 2021-01-26 15:46 +0100
Re: Programming exercise/challenge Dave Dunfield <dave.dunfield@gmail.com> - 2021-01-27 03:43 -0800
Re: Programming exercise/challenge David Brown <david.brown@hesbynett.no> - 2021-01-27 13:43 +0100
Re: Programming exercise/challenge Anton Shepelev <anton.txt@g{oogle}mail.com> - 2021-01-27 17:51 +0300
Re: Programming exercise/challenge James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-01-27 11:02 -0500
Re: Programming exercise/challenge David Brown <david.brown@hesbynett.no> - 2021-01-27 17:03 +0100
Re: Programming exercise/challenge Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2021-01-27 07:21 -0800
Re: Programming exercise/challenge David Brown <david.brown@hesbynett.no> - 2021-01-27 17:09 +0100
Re: Programming exercise/challenge Kaz Kylheku <563-365-8930@kylheku.com> - 2021-01-27 17:04 +0000
Re: Programming exercise/challenge David Brown <david.brown@hesbynett.no> - 2021-01-28 10:41 +0100
Re: Programming exercise/challenge Kaz Kylheku <563-365-8930@kylheku.com> - 2021-01-28 18:25 +0000
Re: Programming exercise/challenge David Brown <david.brown@hesbynett.no> - 2021-01-28 10:44 +0100
Re: Programming exercise/challenge Kaz Kylheku <563-365-8930@kylheku.com> - 2021-01-28 21:33 +0000
Re: Programming exercise/challenge David Brown <david.brown@hesbynett.no> - 2021-01-29 10:39 +0100
Re: Programming exercise/challenge James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-01-25 23:52 -0500
Re: Programming exercise/challenge Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-01-26 11:37 +0000
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-01-27 08:04 -0800
Re: Programming exercise/challenge Anton Shepelev <anton.txt@g{oogle}mail.com> - 2021-01-27 19:16 +0300
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-01-27 23:38 -0800
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-01-27 13:43 -0800
Re: Programming exercise/challenge Dave Dunfield <dave.dunfield@gmail.com> - 2021-01-28 03:16 -0800
Re: Programming exercise/challenge James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-01-28 06:42 -0500
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-01-28 13:01 -0800
Re: Programming exercise/challenge James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-01-06 13:35 -0500
Re: Programming exercise/challenge Kaz Kylheku <563-365-8930@kylheku.com> - 2021-01-06 19:27 +0000
Re: Programming exercise/challenge Kaz Kylheku <563-365-8930@kylheku.com> - 2021-01-06 21:25 +0000
Re: Programming exercise/challenge James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-01-06 00:37 -0500
Re: Programming exercise/challenge Dave Dunfield <dave.dunfield@gmail.com> - 2021-01-06 04:34 -0800
Re: Programming exercise/challenge James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-01-06 11:54 -0500
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-01-05 15:28 -0800
Re: Programming exercise/challenge James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-01-05 13:27 -0500
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-01-05 15:43 -0800
Re: Programming exercise/challenge Dave Dunfield <dave.dunfield@gmail.com> - 2021-01-05 20:10 -0800
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-01-06 23:07 -0800
Page 17 of 20 — ← Prev page 1 … 15 16 [17] 18 19 20 Next page →
| From | Kaz Kylheku <563-365-8930@kylheku.com> |
|---|---|
| Date | 2021-01-23 18:38 +0000 |
| Message-ID | <20210123103255.130@kylheku.com> |
| In reply to | #158582 |
On 2021-01-23, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > Kaz Kylheku <563-365-8930@kylheku.com> writes: > >> On 2021-01-22, Bart <bc@freeuk.com> wrote: >> >>> On 22/01/2021 19:00, Kaz Kylheku wrote: >>> >>>> <randomchars>\ >>>> <morerandomchars>\ >>>> <fewmorerandomchars> >>>> >>>> produce >>>> >>>> <randomchars><morerandomchars><fewmorerandomchars> >>>> >>>> The next translation phase can then be tested with cases that do not >>>> include line continuation; that matter is settled by a correctly working >>>> previous translation phase. >>> >>> This is what makes the challenge in the OP harder. >> >> No, it doesn't; you just read input from state machine which >> handles that requirement, and then the rest of the code is completely >> oblivious to any line continuation requirement. >> >>> \newline sequences need to be retained, depending on context which >>> normally a compiler will know nothing about at this stage. >> >> The requirement for retaining uncommented line continuations >> was something that was needed by Tim in the original situation where >> the original program was deployed; it's not coming from the C language. >> >> I found my program quite easy to modify to accomodate the requirement, >> even though it was based on abuse of goto, which supposedly makes >> maintenance harder. > > Note that there are still cases that your program gets wrong. That's entirely possible because I didn't do anything even remotely resembling writing a comprehensive test suite. In any case, that is neither here nor there because I made a program which translates your program (which I assume is the correct reference implementation) into the style of my program, so now I have that translated program. (That translation could also be incorrect, but the translating program has exactly one input test case to validate, which can be done by a detailed side-by-side comparison of the input and output program, rather than by testing the behavior of the output program.) -- TXR Programming Language: http://nongnu.org/txr
[toc] | [prev] | [next] | [standalone]
| From | Dave Dunfield <dave.dunfield@gmail.com> |
|---|---|
| Date | 2021-01-23 04:52 -0800 |
| Message-ID | <f8d552c4-06d5-4ea3-b751-c43b73835561n@googlegroups.com> |
| In reply to | #158559 |
I don't see much benefit to continuing grinding at this "discussion", so
I'm only going to comment on a couple fairly major points.
>> I know a LOT of people who couldn't tell you how the engine works in
>> their car. When your product is a compiler, they your "users" are
>> programmers.
>
>How backslash line continuations work in C is not "how the compiler
>works". It's an external requirement, visible to the program.
Not true! we've been specifically discussing [\\<newline>] and It's also been
pointed out by multiple people that they wouldn't manually code that way. -
You would only need to "know" this "feature" if you are writing code that
generates code .. which I've done a number of times and never had to "know"
this (obviously I didn't) .. in the event I had to generate an ESCAPE sequence
in that code, I just made sure it didn't cross another escape sequence (line
continuation).
>It's like whether the gas pedal is to the left or right of the brake.
Also not true! Where the pedals are is information pretty much required for
you to drive it. How "translation phases" work in a compiler would be much
more like (what are the strokes which occur in an internal combustion engine?
What do they do? Which way is the piston moving during each one? Which and
when do valves open during each stroke? etc.) I do know many people who drive
that probably don't know (or are even aware if) these details.
>I'm amazed anyone would think otherwise, let alone with decades of
>experience.
Just as I'm amazed by these "counter thoughts".
>Someone needed it because the feature was added in 1979, a decade before
>ANSI C. It was added in a goofy way, and imitated in incompatible ways
>by others, so the spec had to do something reasonable.
Exactly my point, except I would have said "wanted" instead of "needed".
What I'm suggesting might have been slightly "unreasonable" is to mandate
such behavior. It could easily have been stated as "may be", like multi
character constants - if you want to be truly portable you would avoid.
>The way backslash line continuations work in C is the simplest, most
>intuitive possible thing for the end user (programmer) to understand:
Still disagree.. that [\] means something determined by the very next thing
would be even easier to understand. That it does so only in "most but not
quite all" cases would be harder to (IMHO).
>This is a very simple encoding matter of the raw program text, having
>nothing to do with its token syntax.
>Just like, say, the division of the bytes in a TCP/IP stream into
>packets has nothing to do with that stream's content.
Clearly true for [\<newline>] but can you say the same for [\\] which in the
very special case or being followed by <newline> (or <end of line> if you wish
to think of it that way) means something different.
>The C program is made out of "packets" which are lines, and the
>backslash is the flag which indicates a "fragmented packet": one or more
>fragments follow and the last one is indicated by not having trailing
>backslash. The byte stream is understood after defragmentation.
On many systems, a source (text) file isn't actually packatized by lines (if
it were it would be done in blocks with a length). "Lines" in a source file
are just the occurrence of a <newline> character in the input stream.
[\<newline>] in C means to ignore the <newline> and keep going on the same
source line.
It's been said multiple times that giving [\<newline>] priority is done by
CPP which doesn't otherwise have to know about or scan for other escape
sequences. This is yet another fallacy, consider:
---------------------------------
#define This "That"
fputs("\"This\"", stdout);
---------------------------------
Do you think this can be correctly handled by CPP without knowing about
(and scanning for) the [\"] escape sequence? (Same for [\']).
BTW/FYI: I wrote my C compiler mid-80's. At that time I don't think there
was an ISO/ANSI standard for C. The reference I used was a book entitled
"The C Programming Language" by "Brian W, Kernighan and Dennis M, Ritchie"
that was Copyright 1978. I don't think it mentioned line splicing at all.
At first I didn't make a separate preprocessor, the compiler itself had
limited preprocessing capability:
#include
#define/#ifdef/#ifndef/#else/#endif (no parameters)
This was essentially the minimum I wanted to write the compiler itself.
In later years I added MCP yet this limited preprocessing capability
remains in the core compiler (none of the # lines get through MCP if it
is enabled).
It did not recognize or deal with [\<newline>].
Some years later I got the second edition of the same book (Copyright
1988, 1978). It's cover looks almost the same, but has a red "stamp" printed
on it which says "ANSI C". It does have a very small statement about line
splicing:
"Lines that end with the backslash character \ are folded by deleting the
backslash and the following newline character. This occurs before division
into tokens."
Obviously this could mean that [\<newline>] should have precedence, but I
wasn't really paying close attention at this point and because of the use of
[\], and MCP had to scan for [\] escapes anyway, I made it consistent with
other escapes, preserving ALL escapes as they were - I don't think this
was a terribly unreasonable thing to do (hence this whole discussion).
Regards,
Dave
Search "Dave's Old Computers" see my "personal" at bottom!
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2021-01-23 15:45 +0000 |
| Message-ID | <87y2gjzmgc.fsf@bsb.me.uk> |
| In reply to | #158570 |
Dave Dunfield <dave.dunfield@gmail.com> writes: > I don't see much benefit to continuing grinding at this "discussion", so > I'm only going to comment on a couple fairly major points. > >>> I know a LOT of people who couldn't tell you how the engine works in >>> their car. When your product is a compiler, they your "users" are >>> programmers. >> >>How backslash line continuations work in C is not "how the compiler >>works". It's an external requirement, visible to the program. > > Not true! we've been specifically discussing [\\<newline>] and It's also been > pointed out by multiple people that they wouldn't manually code that way. - You would manually code that way! Multi-line macros have to be written that way, and as you know, in those days there were file systems that enforced fixed-length "lines". >>The C program is made out of "packets" which are lines, and the >>backslash is the flag which indicates a "fragmented packet": one or more >>fragments follow and the last one is indicated by not having trailing >>backslash. The byte stream is understood after defragmentation. > > On many systems, a source (text) file isn't actually packatized by lines (if > it were it would be done in blocks with a length). "Lines" in a source file > are just the occurrence of a <newline> character in the input stream. The terminology is confusing here. C is designed to work on systems where what the standard calls "physical source lines" do not contain any line ending character. A C compiler could take input from punched cards with fixed-length physical lines perfectly well. The first translation phase maps the input into the source character set, introducing newline characters as required. > BTW/FYI: I wrote my C compiler mid-80's. At that time I don't think there > was an ISO/ANSI standard for C. The reference I used was a book entitled > "The C Programming Language" by "Brian W, Kernighan and Dennis M, Ritchie" > that was Copyright 1978. I don't think it mentioned line splicing at > all. It sort of does. The germ of the idea is there. In string literals (in K&R C) a \ followed by a newline is ignored, and a macro definition can be continued by writing \ at the end of a line. Obviously this is not a general mechanism, but given these two cases, the first standard made a reasonable choice when deciding to make the mechanism general. > At first I didn't make a separate preprocessor, the compiler itself had > limited preprocessing capability: > > #include > #define/#ifdef/#ifndef/#else/#endif (no parameters) > > This was essentially the minimum I wanted to write the compiler itself. > In later years I added MCP yet this limited preprocessing capability > remains in the core compiler (none of the # lines get through MCP if it > is enabled). > > It did not recognize or deal with [\<newline>]. Not even in string literals and macro definitions? > Some years later I got the second edition of the same book (Copyright > 1988, 1978). It's cover looks almost the same, but has a red "stamp" printed > on it which says "ANSI C". It does have a very small statement about line > splicing: > > "Lines that end with the backslash character \ are folded by deleting the > backslash and the following newline character. This occurs before division > into tokens." > > Obviously this could mean that [\<newline>] should have precedence, but I > wasn't really paying close attention at this point and because of the use of > [\], and MCP had to scan for [\] escapes anyway, I made it consistent with > other escapes, preserving ALL escapes as they were - I don't think this > was a terribly unreasonable thing to do (hence this whole discussion). It's not clear to me what your compiler would have done with char *s = "abc\ def"; either before or after ANSI C came out. Is this the string "abc\ndef"? -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Dave Dunfield <dave.dunfield@gmail.com> |
|---|---|
| Date | 2021-01-23 09:04 -0800 |
| Message-ID | <4c17e48e-e17b-4fc6-90e4-02182a38f0b8n@googlegroups.com> |
| In reply to | #158573 |
On Saturday, January 23, 2021 at 10:45:35 AM UTC-5, Ben Bacarisse wrote: > > Not true! we've been specifically discussing [\\<newline>] and It's also been > > pointed out by multiple people that they wouldn't manually code that way. - > You would manually code that way! Multi-line macros have to be written > that way, and as you know, in those days there were file systems that > enforced fixed-length "lines". I think you've missed something. To quote an earlier message of mine [text] shows text exactly as it would appear in C source. I can think of many cases where you would manually code [\<newline>], but when would you manually code: [\\<newline>] > > BTW/FYI: I wrote my C compiler mid-80's. At that time I don't think there > > was an ISO/ANSI standard for C. The reference I used was a book entitled > > "The C Programming Language" by "Brian W, Kernighan and Dennis M, Ritchie" > > that was Copyright 1978. I don't think it mentioned line splicing at > > all. > It sort of does. The germ of the idea is there. In string literals (in > K&R C) a \ followed by a newline is ignored, and a macro definition can > be continued by writing \ at the end of a line. I couldn't find it (book in front of me) - page number? (1978 1st edition) > > It did not recognize or deal with [\<newline>]. > Not even in string literals and macro definitions? The compiler supported [\<newline>] in string literals, but the limited initial built-in preprocessor did not. > It's not clear to me what your compiler would have done with > > char *s = "abc\ > def"; Treated same as: char *s = "abcdef"; [\<newline>] in strings were recognized, the discussion came from [\\<newline>] which my compiler treated as: 0x5C, 0x0A (ASCII character codes shown) - usually and error. Regards Dave Search "Dave's Old Computers" see my "personal" at bottom!
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2021-01-23 23:10 +0000 |
| Message-ID | <87mtwzz1up.fsf@bsb.me.uk> |
| In reply to | #158580 |
Dave Dunfield <dave.dunfield@gmail.com> writes: > On Saturday, January 23, 2021 at 10:45:35 AM UTC-5, Ben Bacarisse wrote: >> > Not true! we've been specifically discussing [\\<newline>] and It's also been >> > pointed out by multiple people that they wouldn't manually code that way. - >> You would manually code that way! Multi-line macros have to be written >> that way, and as you know, in those days there were file systems that >> enforced fixed-length "lines". > > I think you've missed something. To quote an earlier message of mine > [text] shows text exactly as it would appear in C source. I can think > of many cases where you would manually code [\<newline>], but when > would you manually code: [\\<newline>] Ah, I did not follow your notation. Now that I do, I'm not 100% sure I follow your argument. You were countering what I thought was an un-contentious claim from Kaz that programmers should know about line continuations -- it's part of the contact the compiler makes with the programmer. It seems that you are saying that a programmer does not need to know the exact details because the cases where the details really matter are never human-generated. It that the point you are making? >> > BTW/FYI: I wrote my C compiler mid-80's. At that time I don't think there >> > was an ISO/ANSI standard for C. The reference I used was a book entitled >> > "The C Programming Language" by "Brian W, Kernighan and Dennis M, Ritchie" >> > that was Copyright 1978. I don't think it mentioned line splicing at >> > all. >> It sort of does. The germ of the idea is there. In string literals (in >> K&R C) a \ followed by a newline is ignored, and a macro definition can >> be continued by writing \ at the end of a line. > > I couldn't find it (book in front of me) - page number? (1978 1st > edition) 181 and 207. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Dave Dunfield <dave.dunfield@gmail.com> |
|---|---|
| Date | 2021-01-23 15:39 -0800 |
| Message-ID | <338e14c8-f443-416c-bccb-aa60a78b124fn@googlegroups.com> |
| In reply to | #158589 |
On Saturday, January 23, 2021 at 6:10:33 PM UTC-5, Ben Bacarisse wrote: > Ah, I did not follow your notation. Now that I do, I'm not 100% sure I > follow your argument. You were countering what I thought was an > un-contentious claim from Kaz that programmers should know about line > continuations -- it's part of the contact the compiler makes with the > programmer. It seems that you are saying that a programmer does not > need to know the exact details because the cases where the details > really matter are never human-generated. It that the point you are > making? Exactly, it's not a big deal, but it COULD make a bounced double \ at the end of a line mean something different than a single \ intends and still compile "ok", like I just said, not a big deal - but I personally would prefer to have to work a bit to generate escape over lines that could be broken over [\\] not always meaning insert a '\'. It's just a matter of opinion. (and it was "fun" for a while seeing all the other opinions). > > I couldn't find it (book in front of me) - page number? (1978 1st > > edition) >181 and 207 (may not be exact quote because I accidentally deleted/retyped it :) THANKS! - that helps (have to admin - it's been many years since I looked at these books!) Dave Search "Dave's Old Computers" see my "personal" at bottom!
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <563-365-8930@kylheku.com> |
|---|---|
| Date | 2021-01-23 15:59 +0000 |
| Message-ID | <20210123065209.249@kylheku.com> |
| In reply to | #158570 |
On 2021-01-23, Dave Dunfield <dave.dunfield@gmail.com> wrote:
> I don't see much benefit to continuing grinding at this "discussion", so
> I'm only going to comment on a couple fairly major points.
>
>
>>> I know a LOT of people who couldn't tell you how the engine works in
>>> their car. When your product is a compiler, they your "users" are
>>> programmers.
>>
>>How backslash line continuations work in C is not "how the compiler
>>works". It's an external requirement, visible to the program.
>
> Not true! we've been specifically discussing [\\<newline>] and It's also been
> pointed out by multiple people that they wouldn't manually code that way. -
Every specification allows for combinations that woudn't be used.
ISO C 99 requires conforming implemenations to support at least 127
parameters in a function. Just because you "wouldn't code that way"
doesn't mean the minimum should be only 12.
> You would only need to "know" this "feature" if you are writing code that
> generates code .. which I've done a number of times and never had to "know"
> this (obviously I didn't) .. in the event I had to generate an ESCAPE sequence
> in that code, I just made sure it didn't cross another escape sequence (line
> continuation).
>
>>It's like whether the gas pedal is to the left or right of the brake.
>
> Also not true! Where the pedals are is information pretty much required for
> you to drive it.
Likewise, how line continuation works is required if you want to break
up long lines in a C program into shorter ones with backslashes.
> How "translation phases" work in a compiler would be much
> more like (what are the strokes which occur in an internal combustion engine?
Not at all; all aspects of the translation phases map to some
programmer-visible aspect of the language. That is true of nearly all
requirements given in ISO C.
> What do they do? Which way is the piston moving during each one? Which and
> when do valves open during each stroke? etc.) I do know many people who drive
> that probably don't know (or are even aware if) these details.
That's more like true implementation details, like "in what machine
register is this local variable, at this point in the code?"
That's something you won't find in the language specification.
>>I'm amazed anyone would think otherwise, let alone with decades of
>>experience.
>
> Just as I'm amazed by these "counter thoughts".
>
>
>>Someone needed it because the feature was added in 1979, a decade before
>>ANSI C. It was added in a goofy way, and imitated in incompatible ways
>>by others, so the spec had to do something reasonable.
>
> Exactly my point, except I would have said "wanted" instead of "needed".
Requirements come from either needs or wants.
You don't strictly need electricity or running water in your home; those
came about because of a want. All the material affordances you're
surrounded with can be identified as arising out of wants.
The developer of the C preprocessor could just have written #define
macros on a single line, no matter how long.
He wanted a way not to do that. The solution didn't specifically need to
be backslash continuations but due to the line-oriented nature of the
preprocessor, that's what it became.
Everyone understood those backslashes to be a preprocessor feature.
The feature observed only certain syntax: the backslashes could not
occur in the middle of preprocessor tokens like character constants,
bt they could occur in the middle of tokens that the preprocessor
did not analyze, like string literals.
The preprocessor cared about character literals because they are
a way of writing integers, and the language works with integers:
#if 'b' > 'a'
...
#endif
> What I'm suggesting might have been slightly "unreasonable" is to mandate
> such behavior. It could easily have been stated as "may be", like multi
> character constants - if you want to be truly portable you would avoid.
>
>>The way backslash line continuations work in C is the simplest, most
>>intuitive possible thing for the end user (programmer) to understand:
>
> Still disagree.. that [\] means something determined by the very next thing
> would be even easier to understand.
The continuation backslash is in fact absolutely determined by the next
thing, regardless of any context. If the characters backslash-newline
occur anywhere in the raw character stream, they are deleted.
Because of that, no other character's meaning is determined by
the next character. In any situation whatsoever, if the next character
is a backslash followed by a newline, that has to be deleted to find the
actual next character.
We have to accept a revised definition of "next character";
next logical character (translation stage 3) versus next physical
character (translation stages 1 and 2).
Other backslashes are not absolutely determined by the next thing,
even if we ignore the existence of line continuations:
// \
^ not an escape; not determined by next thing
"\\"
^ this one is determined by the previous thing
Rather what you would prefer, as I recall from other examples/discussion
is that in a combination of backslashes, that they should have the
same precedence, and left-to-right associativity, so that if
\\
n
occurs, it is treated as
((\\)
n)
and not
(\(\
)n)
That requires the continuation backslash to belong to the string literal
syntax, which requires history to have been otherwise: like that either
there is no preprocessor, or that the preprocessor ought to have
recognized string literal tokens, and implemented continuations inside
them.
Look, yes, a character-level macro preprocessor which does its own
lexical scanning and is mostly ignorant of the target language, which
again does lexical scanning, is not such a great idea in the first
place! Lisp shows us how we can have structural macros (that
are even aware of lexical scope, so that a local function can
shadow a local macro at a more outer nesting).
Such a textual preprocessor is like an error in the second decimal
place, if not the first.
The matter of how it treats a line continuation backslash is
a ninth decimal place matter; it's a minor discussion in the context of
a big mistake.
The ANSI C treatment of that backslash actually rescues it.
>>This is a very simple encoding matter of the raw program text, having
>>nothing to do with its token syntax.
>>Just like, say, the division of the bytes in a TCP/IP stream into
>>packets has nothing to do with that stream's content.
>
> Clearly true for [\<newline>] but can you say the same for [\\] which in the
> very special case or being followed by <newline> (or <end of line> if you wish
> to think of it that way) means something different.
>
>>The C program is made out of "packets" which are lines, and the
>>backslash is the flag which indicates a "fragmented packet": one or more
>>fragments follow and the last one is indicated by not having trailing
>>backslash. The byte stream is understood after defragmentation.
>
> It's been said multiple times that giving [\<newline>] priority is done by
> CPP which doesn't otherwise have to know about or scan for other escape
> sequences. This is yet another fallacy, consider:
It is in fact a historic fallacy, as I have shown. The 1979 cpp sources
show that it performs a lexical analysis of its input, and does not
recognize backslashes within tokens such as numbers and character
literals. However, that cpp doesn't lexically analyze every single C
token type; just the ones it is interested in for its own purposes.
So, in the 1979 cpp, the following ANSI C usage would not work:
#define NL '\\
\n'
Indeed the \\ will just code for a \, and then we have an unterminated
character literal.
The idea that the backslash continuation worked that way because
of the original C preprocessor is historic revisionism.
> ---------------------------------
> #define This "That"
> fputs("\"This\"", stdout);
> ---------------------------------
> Do you think this can be correctly handled by CPP without knowing about
> (and scanning for) the [\"] escape sequence? (Same for [\']).
>
>
> BTW/FYI: I wrote my C compiler mid-80's. At that time I don't think there
> was an ISO/ANSI standard for C.
At that time, it was in the draft stages, and it would have been wise to
observe it.
> "Lines that end with the backslash character \ are folded by deleting the
> backslash and the following newline character. This occurs before division
> into tokens."
See; Ritchie could have added a foonote here complaining about ANSI C
vandalism to his language, but he didn't do it.
"Some guy wrote a half-baked preprocessor for my language, which was
badly imitated in incompatible ways, and the end result is now that we
have these out-of-context backslashes before division into tokens."
There is no reason to write that for him in 2021.
Nobody even deals with C except people doing operating systems and
drivers, embedded work, low-level libraries, programming language
work (virtual machines, garbage collection, ...).
--
TXR Programming Language: http://nongnu.org/txr
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2021-01-25 11:40 -0500 |
| Message-ID | <rumsa9$boo$1@dont-email.me> |
| In reply to | #158570 |
On Saturday, January 23, 2021 at 7:52:34 AM UTC-5, dave.d...@gmail.com
wrote:
[missing attribution inserted - please remember to attribute quotes
properly]
> On 1/22/21 2:00 PM, Kaz Kylheku wrote:
> >How backslash line continuations work in C is not "how the compiler
> >works". It's an external requirement, visible to the program.
> Not true! we've been specifically discussing [\\<newline>] and It's
> also been pointed out by multiple people that they wouldn't manually
> code that way. - You would only need to "know" this "feature" if you
> are writing code that generates code .. which I've done a number of
> times and never had to "know" this (obviously I didn't) .. in the
> event I had to generate an ESCAPE sequence in that code, I just made
> sure it didn't cross another escape sequence (line continuation).
I think you're misunderstanding the distinction he's making. The
"external requirement" he's talking about refers to the fact that this
feature is mandated by the standard, and can be relied upon by the
programmer. Whether or not the feature is obscure doesn't change that fact.
Things that are truly internal to the compiler are not mandated by the
standard, and cannot be relied upon by the programmer. For example, one
such issue is where it stores the standard library header files (if it
even bothers storing them as files).
> >It's like whether the gas pedal is to the left or right of the brake.
> Also not true! Where the pedals are is information pretty much
> required for you to drive it. How "translation phases" work in a
> compiler would be much more like (what are the strokes which occur in
> an internal combustion engine? What do they do? Which way is the
> piston moving during each one? Which and when do valves open during
> each stroke? etc.) I do know many people who drive that probably
> don't know (or are even aware if) these details.
I don't think you fully understand the significance of translation
phases. They are not an obscure detail (though they can have obscure
consequences). They play a very important role in the description of the
language, determining many aspects of the language that you rely upon
every time you write some C code. You just aren't aware of the fact that
these are due to translation phases. For any set of translation phases
that must occur in a given order, there are programs whose
interpretation would change (usually by breaking) if that order were
changed in any fashion. Let me give you a few examples, considering all
possible pairs of consecutive translation phases:
The fact that translation phase 1 precedes translation phase 2 ensures
that, on platforms which don't support the backslash character, "??/"
can be used instead. If trigraphs were not recognized until after phase
2, line continuations would be impossible on such platforms. This is,
admittedly, somewhat obscure.
On implementations which use any method other than a single newline
character to identify the end of a line, that order also ensures that
line continuations are recognized as such. If line endings weren't
converted to "\n" until after phase 2, then, for instance, on systems
that mark the end of a line using "\r\n", the "\r" would prevent a
backslash from ever immediately preceding the "\n". On systems which use
"\n\r", the "\r" would always survive the line merger, often resulting
in a syntax error.
The fact that translation phase 2 precedes translation phase 3 is
basically the case under discussion. Because of that fact, you can split
long logical lines of source code pretty much wherever you want(except
in the middle of a trigraph), which is of considerable importance for
machine generated code. If the order were reversed, you would have to
split long logical lines between preprocessing tokens. If the order were
unspecified, defensive programming would still require you to split them
between preprocessing tokens.
The fact that translation phase 3 precedes translation phase 4 is
essential to making phase 4 meaningful. Phase 3 identifies preprocessing
tokens, which are what phase 4 works on. Phase 3 also removes comments;
without that removal, comments would qualify as syntax errors during
phase 4. They are not part of the "Lexical grammar" (Section A.1),
precisely because they're supposed be removed before phase 4 uses that
grammar to parse the code. If the order were reversed or unspecified, no
preprocessing directives or comments could be used.
The fact that translation phase 4 precedes phase 5 allows strings
created by the # operator to be properly converted from source character
set to the execution character set, with escape sequences properly
interpreted.
The fact that translation phase 5 precedes phase 6 ensures that "\0"
"12" is interpreted as equivalent to "\00012", and that "\U00A8" "4210"
Is interpreted as "\U000000A84210". If the order were reversed, those
would be interpreted as "\012" and "\U00A84210" (which would be an
invalid UCN), respectively. If the order were unspecified, you wouldn't
know which of the two interpretations would apply. To avoid ambiguity in
such contexts, you'd have to use 3 octal digits for an octal escape
sequence, and 8 hex digits for a universal character name.
The fact that translation phase 6 precedes phase 7 is essential to
making phase 6 meaningful. If the order were reversed, adjacent string
literals would always qualify as two consecutive primary-expressions
during translation phase 7, something that is always a syntax error,
before they get a chance to be merged together.
Phase 7 identifies function and object definitions, and references to
functions and objects declared in other translation units. Phase 8
resolves those references. If the order were reversed, there would be no
external references to be resolved, and no identifiers of things with
external linkage to resolve them to, and it would therefore be
impossible to link translation units - you'd have to put entire programs
into a single translation unit.
> >This is a very simple encoding matter of the raw program text, having
> >nothing to do with its token syntax.
> >Just like, say, the division of the bytes in a TCP/IP stream into
> >packets has nothing to do with that stream's content.
> Clearly true for [\<newline>] but can you say the same for [\\] which
in the
> very special case or being followed by <newline> (or <end of line> if
> you wish to think of it that way) means something different
It is not a special case. A line continuation can be split any
preprocessing token that is made up of two or more characters, not just
character constants and string literals. They can also split header
names, identifiers, pp-numbers, or multi-character punctuators such as
"<<=".
> >The C program is made out of "packets" which are lines, and the
> >backslash is the flag which indicates a "fragmented packet": one or more
> >fragments follow and the last one is indicated by not having trailing
> >backslash. The byte stream is understood after defragmentation.
> On many systems, a source (text) file isn't actually packatized by
> lines (if it were it would be done in blocks with a length).
On such systems, whatever implementation-specific method is used to
identify lines is translated, during translation phase 1, into a single
newline character in the appropriate location. The entire rest of the
description of the C language, including the part about line
continuations, is based upon expecting the phase 1 conversion to have
been done.
> It's been said multiple times that giving [\<newline>] priority is
> done by CPP which doesn't otherwise have to know about or scan for
> other escape sequences. This is yet another fallacy, consider:> ---------------------------------
> #define This "That"
> fputs("\"This\"", stdout);
> ---------------------------------
> Do you think this can be correctly handled by CPP without knowing
> about (and scanning for) the [\"] escape sequence? (Same for [\']).
No one has said that about CPP, which implements translation phases 1-4.
Phase 3 is the one where escape sequences must be recognized. What
people have said is that translation phase 2 can be implementation
without worrying about escape sequences. CPP might integrate phase 2
with phase 3, but that's not required. I've never attempted implementing
them, but I suspect that it's simpler to separate them, for precisely
the same reason that it's easier for a human to understand those phases
by thinking about them separately. Your confusions on this issue are an
example of why trying to think about them together makes things more
complicated.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2021-01-23 09:47 -0800 |
| Message-ID | <86mtwzmtp9.fsf@linuxsc.com> |
| In reply to | #158544 |
James Kuyper <jameskuyper@alumni.caltech.edu> writes: > On 1/21/21 2:37 PM, Dave Dunfield wrote: > [Missing attribution]: > >> On Wednesday, January 20, 2021 at 1:57:54 PM UTC-5, Tim Rentsch wrote: > > ... > >>> As the C standard is now, it does not give any special consideration >>> to <backslant><backslant><newline>. The two final characters are >>> treated as a line continuation sequence, removed in translation >>> phase three, and the resulting logical line is processed as usual. > > That should be translation phase 2. Right. To make matters worse, I was looking at the very page of the C standard while I was typing that message. The moral is, just don't post hastily, and always re-read to double check.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <563-365-8930@kylheku.com> |
|---|---|
| Date | 2021-01-23 18:32 +0000 |
| Message-ID | <20210123095807.699@kylheku.com> |
| In reply to | #158581 |
On 2021-01-23, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > James Kuyper <jameskuyper@alumni.caltech.edu> writes: > >> On 1/21/21 2:37 PM, Dave Dunfield wrote: >> [Missing attribution]: >> >>> On Wednesday, January 20, 2021 at 1:57:54 PM UTC-5, Tim Rentsch wrote: >> >> ... >> >>>> As the C standard is now, it does not give any special consideration >>>> to <backslant><backslant><newline>. The two final characters are >>>> treated as a line continuation sequence, removed in translation >>>> phase three, and the resulting logical line is processed as usual. >> >> That should be translation phase 2. > > Right. To make matters worse, I was looking at the very > page of the C standard while I was typing that message. > The moral is, just don't post hastily, and always re-read > to double check. That is simply not practical; there are things you have to know, and have to trust that you know them, otherwise you are descending down a deep rabbit hole of reading every time you want to say or write anything, leaving you severely hamstrung. When you trust that you know something, sometimes that trust is betrayed by the brain. Sometimes you forget things in such a way that you don't know you have forgotten, but instead "misremember". The confidence and trust is there (you feel just as sure as ever) but the underlying fact has become corrupted in some way. I trust that I know that \<NL> is removed in translation stage 2, so I would never look that up, like I wouldn't look up whether water is wet. However, that knowledge could somehow become corrupted so that years from now, I "misremember" it as translation stage 3. That's just how it is. Mistrusting everything you think you remember, and looking it up, is not a practical solution to the problem. Probably, the practical solution is to look up when making a use of what you think you know, in a situation where it matters. And, even then, trust the short-term memory, otherwise that rule implies OCD behavior. If you remember checking the stove within the last five minutes, and it was off, then it's off. -- TXR Programming Language: http://nongnu.org/txr
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2021-01-23 17:26 -0800 |
| Message-ID | <865z3nm8f9.fsf@linuxsc.com> |
| In reply to | #158524 |
Dave Dunfield <dave.dunfield@gmail.com> writes: [...] >>> [...] The idea that a language should be "worsened" to make it >>> easier for people to write code to generate it seems counter >>> productive. [...] > > By "worse" I meant "less intuitive" - I agree/know that the [\] > character serves two distinct purposes: 1) insert "special" > characters, and 2) avoid processing [<newline>] ... but both cases > are generally consistent with the notion "a special function defined > on the next character". Even if this notion is not stated in the > standard, I expect that many programmers would come to think of it > this way. [...] > > Hopefully my description just above describes better what I mean by > "worse". What I think you're saying is that how C works is not a good fit for your mental model. If that is what you are saying then I would say I understand what you mean. > How many people would like C less if they had to think about > generating very long lines in code containing escape sequences > .vs. how many people would like C more if the notion that [\] > affects the next character in their source was always true - I > think I've made my opinion excruciatingly clear :) but I can only > speak for myself! First I think that is a false dichotomy. If we are going to compare two sets of rules for how low-level lexing is done, only the rules should be given and compared. The description above muddles the question by bringing in motivations and abstract principles. Consequently the question is slanted. Second C has been around for more than 40 years, and there are at least tens of thousands, and probabably hundreds of thousands, of programmers who have learned C and have had no trouble adapting their understanding of how line continuations and string escapes work. AFAIAA there just hasn't been any significant controversy about how these work or whether other rules would be better. So I don't see any indication that there is any real support for your position. > [...] - YACPE: [...] I see that this program has problems but I don't know what advice to give you about how it might be changed. It may be helpful to consider the following cases (separated by ================ lines, with those lines being part of the input). ================ /\ \ \ / This is a comment "This is not a comment" ================ /\ \ \ * This is a comment */ "This is not a comment" ================ /\ \ \ 1 ================ (Resuming...) The output for this input should be (output text below) ================ "This is not a comment" ================ "This is not a comment" ================ /\ \ \ 1 ================ (End of example output) Note that there is a space at the end of the line just before the second "This is not a comment" line. Whatever else your program does, it should work on that example input. In my testing the first and third cases were wrong. Can you make all those example cases work (presumably along with whatever sort of regression tests you are doing)?
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-01-24 01:55 +0000 |
| Message-ID | <Fs4PH.220063$%m67.214207@fx02.ams4> |
| In reply to | #158591 |
On 24/01/2021 01:26, Tim Rentsch wrote: > Dave Dunfield <dave.dunfield@gmail.com> writes: >> How many people would like C less if they had to think about >> generating very long lines in code containing escape sequences >> .vs. how many people would like C more if the notion that [\] >> affects the next character in their source was always true - I >> think I've made my opinion excruciatingly clear :) but I can only >> speak for myself! > > First I think that is a false dichotomy. If we are going to > compare two sets of rules for how low-level lexing is done, > only the rules should be given and compared. The description > above muddles the question by bringing in motivations and > abstract principles. Consequently the question is slanted. > > Second C has been around for more than 40 years, and there are at > least tens of thousands, and probabably hundreds of thousands, of > programmers who have learned C and have had no trouble adapting > their understanding of how line continuations and string escapes > work. AFAIAA there just hasn't been any significant controversy > about how these work or whether other rules would be better. I wouldn't be that certain about the number of programmers who know how line continuations really work in C, which is rather different from other languages. They might use them in between tokens without realising they can go inside tokens too. And it is that that makes this exercise harder: if \newline cannot occur inside //comment or /*comment*/ or "string" or 'chars' then the logic is simpler. It also gives rise to certain quirks which is how some might learn the hard way about line continuation, for example about not be able to have // comments after \, and not being advisable to have them before \.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2021-01-27 08:40 -0800 |
| Message-ID | <86y2gejpt3.fsf@linuxsc.com> |
| In reply to | #158593 |
Bart <bc@freeuk.com> writes: > On 24/01/2021 01:26, Tim Rentsch wrote: > >> Dave Dunfield <dave.dunfield@gmail.com> writes: >> >>> How many people would like C less if they had to think about >>> generating very long lines in code containing escape sequences >>> .vs. how many people would like C more if the notion that [\] >>> affects the next character in their source was always true - I >>> think I've made my opinion excruciatingly clear :) but I can only >>> speak for myself! >> >> First I think that is a false dichotomy. If we are going to >> compare two sets of rules for how low-level lexing is done, >> only the rules should be given and compared. The description >> above muddles the question by bringing in motivations and >> abstract principles. Consequently the question is slanted. >> >> Second C has been around for more than 40 years, and there are at >> least tens of thousands, and probabably hundreds of thousands, of >> programmers who have learned C and have had no trouble adapting >> their understanding of how line continuations and string escapes >> work. AFAIAA there just hasn't been any significant controversy >> about how these work or whether other rules would be better. > > I wouldn't be that certain about the number of programmers who know > how line continuations really work in C, [...] The point is they don't have trouble learning how they work and adjusting their mental models accordingly. I have never met a C developer who had the slightest difficulty understanding the rules for line continuations once those rules have been explained to them.
[toc] | [prev] | [next] | [standalone]
| From | Dave Dunfield <dave.dunfield@gmail.com> |
|---|---|
| Date | 2021-01-23 20:51 -0800 |
| Message-ID | <5049cc01-a549-4022-8f4c-deda87ab20c9n@googlegroups.com> |
| In reply to | #158591 |
>What I think you're saying is that how C works is not a good fit
>for your mental model. If that is what you are saying then I
>would say I understand what you mean.
Yes, fair enough - Having years of experience with users of various levels,
My "mental model" is that details of design/implementation are best not
exposed to the user. That [\\] can mean something unexpected in certain
rare cases I "think" might be undesirable - but It's not a problem for me,
as I know how parsing and translation can work - I only even mentioned it
at first because it surprised me as I didn't "expect" it - I naturally
assumed that other designers of the language had not exposed it in the
same way that I did not.
>> How many people would like C less if they had to think about
>> generating very long lines in code containing escape sequences
>> .vs. how many people would like C more if the notion that [\]
>> affects the next character in their source was always true - I
>> think I've made my opinion excruciatingly clear :) but I can only
>> speak for myself!
>First I think that is a false dichotomy. If we are going to
>compare two sets of rules for how low-level lexing is done,
>only the rules should be given and compared. The description
>above muddles the question by bringing in motivations and
>abstract principles. Consequently the question is slanted.
Fair enough, but a lot of my experience is with not overly technical "users"
it's not unreasonable to think that they might not grasp specs that occur
because of technical details.
>Second C has been around for more than 40 years, and there are at
>least tens of thousands, and probabably hundreds of thousands, of
>programmers who have learned C and have had no trouble adapting
>their understanding of how line continuations and string escapes
>work.
And I'm one of them even though I can't say I "fully" understood how
line continuations work. I've been doing C since mid 80's (at least 35
years) ... I always though that like my implementation escape sequences
could not span line continuations and when I generated code, I made sure
they did't - never a problem as escape sequences work just fine if they
din't span a line continuation. (back to the "mandated" concern).
>AFAIAA there just hasn't been any significant controversy
>about how these work or whether other rules would be better. So
>I don't see any indication that there is any real support for
>your position.
Fair enough, as I have said over and over, this "concern" arose because
your challenge exposed it to me - I *personally* think it could have been
spec'ed better (not mandatory) - but that only a personal opinion. It's
been somewhat "fun" exploring the other opinions.
>I see that this program has problems but I don't know what advice
>to give you about how it might be changed. It may be helpful to
>consider the following cases (separated by ================
>lines, with those lines being part of the input).
>[...]
You code shows two slight problems with mine:
1) Newline at end of '//' comment is not reproduced.
2) Multiple newlines during possible comment lead-in are only
reproduced once.
Here is a "quick" fix for both issues. Note that I have NOT exhaustively
tested these:
Also note that 'Enl' is now a counter. I have made this an "unsigned short"
so excess of 65535 sequential [\<newline>] result in incorrect output (in
which case *IMHO* you get what you deserve). You could make it a 32 bit
value if you really think this is a concern.
I also have to confess that I have been writing/testing this program using
my own compiler - I just tested it with LCC(GCC) and it seems OK.
(and Month in opening comment fixed - hard to keep track of dates these days
during lockdown)
-----------------------------------
/*
* whole line comments could easily be absent and should not
* count against to 25 lime function body limit.
*
* Assumes a valid 'C' program as input, will not detect
* certain errors affecting comments, quotes or escapes.
*
* Dave Dunfield - Jan 2021
*/
#include <stdio.h>
unsigned short // at least 16 bits to insure '& 0xFF00' works
Cp, // Pending input character
C0, // Last character read
Enl; // EscapeNewLine seen
unsigned char
C1, // Previous character read
Imode; // Input mode
// Line continuation sequences occurring within comments are removed.
// But what about comments starting with [/\<newline>*] or [/<newline>/] ?
// I decided to remove them, but if you prefer those [\<newline>]s to
// remain, change all [/*1] in this file to [//1], and all [//2] to [/*2].
// You could also remove all references to [Enl].
// Read a single character, ignoring C sequence: \<nl>
// Added to simulates line splicing performed by "official" CPP.
unsigned rdchar1(void)
{
C1 = C0;
for(;;) {
if(C0 = Cp)
Cp = 0;
else
C0 = getc(stdin);
if(C0 != '\\') // Not an escape
return C0;
if((C0 = getc(stdin)) != '\n') { // Not Escaped Newline
Cp = C0;
return C0 = '\\'; }
/*1*/ ++Enl; // So we can re-insert it in output
//2*/ if(!Imode)
//2*/ fputs("\\\n", stdout);
}
}
// Read one character, excluding content of comments
unsigned char rdchar2(void)
{
for(;;) {
// Assumes 8-bit char set, not including 0 and EOF is >255
if(rdchar1() & 0xFF00)
return 0;
// changing this to multiple 'if's could eliminate the 'switch' line
switch(Imode) {
case '*' : // Inside '/*' comment
if((C1 == '*') && (C0 == '/')) { // Ending '/*'
Imode = Enl = 0;
C0=' '; } // Replace /*...*/ with single space
continue;
case '/' : // Inside '//' comment
if(C1 == '\n') {
Imode = Enl = 0;
break; }
continue;
case 0 : // No special mode
// could be considered as two lines in one, although it's a construct I
// sometimes use if a single 'switch' is the only thing within an 'if'
if(C1 == '/') switch(C0) {
case '*': // Starting '/*' comment
case '/': // Starting '//' comment
Imode = C0;
continue; } }
return C1; }
}
// Read characters, and hande '\\' escape sequences
// Also enter quote input mode if quote character is seen
void handle_esc(void)
{
switch(rdchar2()) {
case '\\': // Escape
putc(C1, stdout);
rdchar2();
case 0 : // EOF
return;
case '"':
case'\'':
if(Imode == C1)
Imode = 0;
else if(!Imode) {
Imode = C1; } }
}
int main(void)
{
rdchar2(); // First call to rdchar2 will return 0;
do {
handle_esc();
/*1*/ while(Enl) { // If '\\', '\n' was seen outside of comment, reinsert
/*1*/ fputs("\\\n", stdout);
/*1*/ --Enl; }
putc(C1, stdout);
} while(!(C0 & 0xFF00)); // Till EOF has been read
}
// Please do let me know of any other/continued problems you find.
// I'm kindof interested in making this work in the best possible way.
// If you want, I can probably easily modify it to output spaces
// instead of characters in comment (and preserve all [\<newline>]
// thereby making the output exactly the same size/shape as the original.
// I know this was mentioned in recent messages, please let me know if you
// would like me to look into this.
//Dave
//Search "Dave's Old Computers" see my "personal" at bottom!
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2021-01-24 02:28 -0800 |
| Message-ID | <87tur639y3.fsf@nosuchdomain.example.com> |
| In reply to | #158594 |
Dave Dunfield <dave.dunfield@gmail.com> writes:
>>What I think you're saying is that how C works is not a good fit
>>for your mental model. If that is what you are saying then I
>>would say I understand what you mean.
>
> Yes, fair enough -
[snip]
Dave, please don't remove attribution lines for quoted text.
The text above starting with "What I think" was written by Tim Rentsch.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Dave Dunfield <dave.dunfield@gmail.com> |
|---|---|
| Date | 2021-01-24 03:49 -0800 |
| Message-ID | <5c948a85-873e-49af-9df8-34a0a971c692n@googlegroups.com> |
| In reply to | #158597 |
On Sunday, January 24, 2021 at 5:29:04 AM UTC-5, Keith Thompson wrote: >Dave Dunfield writes: >>>What I think you're saying is that how C works is not a good fit >>>for your mental model. If that is what you are saying then I >>>would say I understand what you mean. >> >> Yes, fair enough - >[snip] > >Dave, please don't remove attribution lines for quoted text. > >The text above starting with "What I think" was written by Tim Rentsch. Apologies, will try to do better. FYI: Why? When responding with more than a line or two, I usually cut/paste the message from gg/CHROME into a text file which I edit with my own editor (also written in (early) 80's - know it very well :) I usually do this from the original posting which doesn't yet have the attribution. Do to lack of care/precision when cutting the response to insert my edited one, being the first thing, the attribution is often somewhat mangled, and I haven't been thinking it was important enough to recover because: - whomever's response I quoted likely knows who thay are. - anyone following the "discussion" would likely know the context of quotes. - anyone else would likely only care about "what" I am commenting on, not who it was originally said by (and if they did, they could look back a few messages and find it). I will attempt to do better. Dave Search "Dave's Old Computers" see my "personal" at bottom!
[toc] | [prev] | [next] | [standalone]
| From | Anton Shepelev <anton.txt@gmail.com> |
|---|---|
| Date | 2021-01-24 15:38 +0300 |
| Message-ID | <20210124153813.b33220a2a02feee33517bfe4@gmail.com> |
| In reply to | #158598 |
Dave Dunfield: > When responding with more than a line or two, I usually > cut/paste the message from gg/CHROME into a text file > which I edit with my own editor (also written in (early) > 80's - know it very well :) > > I usually do this from the original posting which doesn't > yet have the attribution. So do I, only the editor is not of my own crafting. I copy the attribution from the From: header, but e-mail and Usenet clients will do that automacially if you let them. They will also reformat and reflow quotations to a normal width. > Do to lack of care/precision when cutting the response to > insert my edited one, being the first thing, the > attribution is often somewhat mangled, and I haven't been > thinking it was important enough to recover because: > > -- whomever's response I quoted likely knows who thay are. > > -- anyone following the "discussion" would likely know the > context of quotes. > > -- anyone else would likely only care about "what" I am > commenting on, not who it was originally said by (and > if they did, they could look back a few messages and > find it). People may be following many newsgroups and participating in many tangled discussions with tens of participants. Attributions help to keep them (people and discussions) sane. Do not forget also about people who drop it to read a conversation and have none of the background required to keep track of who said what in their heads. Suppose you quoted my post where I mentioned I was working on a film- iversion algorithm. Whom shall a reader address with a question about the algorithm? He will have to unwind the stack of quotations back to the original message, which is shows lack of consideration on your part. I am of the opinion that both programs and prose should be written for the reader, with his convenience in mind. Last but not least, quoting a message without an attribution may be offensive to its author. -- () ascii ribbon campaign -- against html e-mail /\ http://preview.tinyurl.com/qcy6mjc [archived]
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2021-01-24 14:04 -0800 |
| Message-ID | <87pn1u2dqi.fsf@nosuchdomain.example.com> |
| In reply to | #158598 |
Dave Dunfield <dave.dunfield@gmail.com> writes:
> On Sunday, January 24, 2021 at 5:29:04 AM UTC-5, Keith Thompson wrote:
>>Dave Dunfield writes:
>>>>What I think you're saying is that how C works is not a good fit
>>>>for your mental model. If that is what you are saying then I
>>>>would say I understand what you mean.
>>>
>>> Yes, fair enough -
>>[snip]
>>
>>Dave, please don't remove attribution lines for quoted text.
>>
>>The text above starting with "What I think" was written by Tim Rentsch.
>
> Apologies, will try to do better.
>
> FYI: Why?
So that readers can easily tell who wrote what.
For example, I already mentioned that the text above starting with "What
I think" was written by Tim Rentsch. To find that out without an
attribution line, I'd have to jump to the parent article. I don't think
all newsreaders provide an easy way to do that. Mine does, but I don't
know of an easy way to jump back to the article I was reading.
> When responding with more than a line or two, I usually cut/paste the
> message from gg/CHROME into a text file which I edit with my own editor
> (also written in (early) 80's - know it very well :)
>
> I usually do this from the original posting which doesn't yet have the
> attribution. Do to lack of care/precision when cutting the response to
> insert my edited one, being the first thing, the attribution is often
> somewhat mangled, and I haven't been thinking it was important enough to
> recover because:
>
> - whomever's response I quoted likely knows who thay are.
> - anyone following the "discussion" would likely know the context of quotes.
> - anyone else would likely only care about "what" I am commenting on, not who
> it was originally said by (and if they did, they could look back a few
> messages and find it).
I read multiple newsgroups, and I can't necessarily keep all the
interactions in mind. I might come back to a discussion after
days or weeks -- or even years if I'm searching for old posts.
And as I said, looking back a few messages isn't necessarily trivial.
I can understand wanting to use your own editor. I suggest that you
use your newsreader's (or Google Groups') method to post a followup,
which should quote and attribute the entire parent article, and
then copy the following into your editor. You really don't need
to reconstruct the attribution lines yourself.
> I will attempt to do better.
Thanks, I appreciate it (and I'm sure others do as well).
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Dave Dunfield <dave.dunfield@gmail.com> |
|---|---|
| Date | 2021-01-25 07:26 -0800 |
| Message-ID | <9859d1d8-7bce-4c91-91b5-cfa6e7c0e732n@googlegroups.com> |
| In reply to | #158602 |
On Sunday, January 24, 2021 at 5:04:49 PM UTC-5, Keith Thompson wrote: '>>' lines from Dave Dunfields original message: >> FYI: Why? >So that readers can easily tell who wrote what. I think there was a misunderstanding in my response. The "FYI" means the "Why?" was a title for information I wanted to give you. It was NOT the question "Why shouldn't I trim attrition?" - I do get and understand why it could be annoying to some people. It was an answer to the implied question "Why was it trimmed in your reply?" (and not an excuse - just explaining why it happens sometimes). >I can understand wanting to use your own editor. I suggest that you >use your newsreader's (or Google Groups') method to post a followup, >which should quote and attribute the entire parent article, and >then copy the following into your editor. You really don't need >to reconstruct the attribution lines yourself. I've done this, but not really keen on starting a reply only to either: -Leave it open while I edit it "offline". or -Cancel it right away (and have to look up the message again to actually post the reply - which is what I do anyway.. just don't like the idea of starting something knowing I am going to cancel). So what I tend to do is grab the text from the original message which I use in my reply. This isn't as easy as you might think in gg/CHROME. (Note the problems described would also apply if I was trying to grab the generated reply text). I haven't found an easy way to save the content of a message as text. There is a "save" option if you right-click the message body, but that gets you "boatloads" of uneditable HTML. So I have to select then cut/paste the message text. To give you an idea, consider this message I'm replying to: as text, what I cut/pasted was: 2,788 characters and 70 lines. In contrast, "Save" from CHROME resulted in: "Programming exercise_challenge.html" 1,680,090 characters, 860 lines. I also get a "Programming exercise_challenge_files" sub-directory created which contains: 41 files, 1,190,852 bytes. Selecting the text to cut isn't easy either. As far as I can tell there is no "select all", so you have to select it by mouse. The obvious way would be to start selecting at the top of what you want and pull down to the bottom. But CHROME is excruciatingly slow forward scrolling when selecting, and sometimes you have to move the mouse back and forth at the bottom of the screen to keep it going. This can take "minutes" and you have to really pay attention. Starting at the bottom is much better, it reverse scrolls much faster (if you go too high it's way to fast) - and the last thing you want to do is overshoot far enough to make where you want to "start" below the bottom of the screen - either hold the button and wait a long time to get back there, or release the button and start all over... So, again due to lack of care and precision, I usually start at the bottom and select backward, stopping as close to "just before" what I wanted as I can - not thinking the Attrition was all that important, I often cut it off, so I just removed it. It's been many years since I've frequented newsgroups and at that time I had a good newsreader. It's not overly easy to get a good news-feed, and while looking I found that you can access many newsgroups with gg/CHROME which is the route I went to "check them out". If I keep at it I may pay for a news-feed again, or I may take the time to write a (hopefully simple) parser to turn the "boatloads" of HTML back into simple text to edit... haven't yet decided if it's worth staying. Sorry, getting quite far off "C", but this seems to be an important concern for some - I'll try to shut up now :) Dave Search "Dave's Old Computers" see my "personal" at bottom!
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2021-01-25 16:58 +0100 |
| Message-ID | <rumpr9$npd$1@dont-email.me> |
| In reply to | #158605 |
On 25/01/2021 16:26, Dave Dunfield wrote: > It's been many years since I've frequented newsgroups and at that time I had > a good newsreader. It's not overly easy to get a good news-feed, and while > looking I found that you can access many newsgroups with gg/CHROME which > is the route I went to "check them out". If I keep at it I may pay for a > news-feed again, or I may take the time to write a (hopefully simple) parser > to turn the "boatloads" of HTML back into simple text to edit... haven't yet > decided if it's worth staying. > news.eternal-september.org is a good, free Usenet server. They are always happy with donations, if you want to pay. (It sounds like you don't need recommendations for client software.)
[toc] | [prev] | [next] | [standalone]
Page 17 of 20 — ← Prev page 1 … 15 16 [17] 18 19 20 Next page →
Back to top | Article view | comp.lang.c
csiph-web