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 4 of 20 — ← Prev page 1 2 3 [4] 5 6 … 20 Next page →
| From | dfs <nospam@dfs.com> |
|---|---|
| Date | 2020-12-06 13:03 -0500 |
| Message-ID | <O19zH.388181$gR8.279304@fx45.iad> |
| In reply to | #156992 |
On 12/06/2020 12:51 PM, Ben Bacarisse wrote:
> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> Prompted by some recent discussion regarding 'goto' statements and
>> state machines, I would like to propose a programming exercise.
>> (It is perhaps a bit too large to be called an exercise, but not so
>> difficult that it deserves the label of challenge. On the other
>> hand there are some constraints so maybe challenge is apropos. In
>> any case somewhere in between those two bounds.)
>>
>> Short problem statement: a C program to remove comments from C
>> source input.
>
> Apologies for non-C code but I could not resist...
>
> In all the goto/no goto discussion it's easy to lose track of the fact
> the C does not necessarily have the best primitives for constructing
> this sort of program. I don't mean things like, say, complex regular
> expressions, or built-in grammar parsing (al la Perl6). I mean basic
> language constructs.
>
> Here is a solution in Haskell. It is deliberately not very "Haskelly"
> because I want to keep the code really simple for programmers unfamiliar
> with the language.
>
> main = do input <- getContents
> putStr (stripComments (logicalLines input))
>
> stripComments [] = []
> stripComments ('/' : '/' : rest) = stripComments (dropWhile (/= '\n') rest)
> stripComments ('/' : '*' : rest) = ' ' : stripComments (nestedComment rest)
> stripComments (c : rest) = c : if c == '\'' || c == '"'
> then skipQuote c rest
> else stripComments rest
>
> nestedComment ('*' : '/' : rest) = rest
> nestedComment (c : rest) = nestedComment rest
> nestedComment [] = error "Unterminated comment"
>
> skipQuote q ('\\' : c : rest) = '\\' : c : skipQuote q rest
> skipQuote q (c : rest) = c : if c == q
> then stripComments rest
> else skipQuote q rest
> skipQuote q [] = error "Unterminated literal"
>
> logicalLines ('\\' : '\n' : rest) = logicalLines rest
> logicalLines (c : rest) = c : logicalLines rest
> logicalLines [] = []
>
> (Notes: string are lists and : is the list "cons" operation. [] is the
> empty list. Function application is by juxtaposition: f x and is the
> highest priority operator. Functions are defined by cases that are
> written using simple pattern matching. For example, stripComments [] =
> [] means return nothing when passed nothing.)
>
> Obviously for some there will be a high language barrier, but I think
> it's worth having a go at following what's happening.
>
> Haskell has two big advantages for this exercise: pattern matched cases
> and lazy evaluation. The case-by-case definition lets you say, very
> clearly, how to handle each situation, and the lazy evaluation means you
> can chain function calls to make processing pipelines like this:
>
> putStr (strip (logicalLines input))
>
> This means output the string of characters that result from stripping
> comments from the logical lines, but at no time is the whole input in
> memory. Characters are fetched as needed to satisfy each function call.
>
> Originally, I just wrote stripComments, but when I decided to include
> logical line processing (C's \<newline> "continuation" mechanism) it was
> trivial to put it in. If I want to do trigraphs, that, too, would be a
> simple addition to the pipeline. (There is even an operator to make
> this simpler, but I did not want to add too many peculiar symbols.)
>
> I am now tempted to try to write a C version that preserves as much of
> what I see as the clarity and simplicity of this solution. I am not as
> hopeful as I'd like to be about that!
Thanks for that Haskell lesson!
I'm working on a C program that lists .csv files, then imports and
summarizes them, lets you search for values in fields, etc. How well
does Haskell lend itself to that kind of thing?
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2020-12-06 23:53 +0000 |
| Message-ID | <87pn3mpk3x.fsf@bsb.me.uk> |
| In reply to | #156993 |
dfs <nospam@dfs.com> writes: > I'm working on a C program that lists .csv files, then imports and > summarizes them, lets you search for values in fields, etc. How well > does Haskell lend itself to that kind of thing? Not sure how to answer that sort of question and it's going to lead to more off-topic discussion. There is comp.lang.haskell. It's a bit quiet, but maybe it could be revived by a question just like this one! -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2020-12-06 19:53 +0000 |
| Message-ID | <8FazH.330868$lp01.5631@fx08.ams4> |
| In reply to | #156992 |
> Here is a solution in Haskell. It is deliberately not very "Haskelly"
> because I want to keep the code really simple for programmers unfamiliar
> with the language.
>
> main = do input <- getContents
> putStr (stripComments (logicalLines input))
>
> stripComments [] = []
> stripComments ('/' : '/' : rest) = stripComments (dropWhile (/= '\n') rest)
> stripComments ('/' : '*' : rest) = ' ' : stripComments (nestedComment rest)
> stripComments (c : rest) = c : if c == '\'' || c == '"'
> then skipQuote c rest
> else stripComments rest
>
> nestedComment ('*' : '/' : rest) = rest
> nestedComment (c : rest) = nestedComment rest
> nestedComment [] = error "Unterminated comment"
>
> skipQuote q ('\\' : c : rest) = '\\' : c : skipQuote q rest
> skipQuote q (c : rest) = c : if c == q
> then stripComments rest
> else skipQuote q rest
> skipQuote q [] = error "Unterminated literal"
>
> logicalLines ('\\' : '\n' : rest) = logicalLines rest
> logicalLines (c : rest) = c : logicalLines rest
> logicalLines [] = []
>
> (Notes: string are lists and : is the list "cons" operation. [] is the
> empty list. Function application is by juxtaposition: f x and is the
> highest priority operator. Functions are defined by cases that are
> written using simple pattern matching. For example, stripComments [] =
> [] means return nothing when passed nothing.)
>
> Obviously for some there will be a high language barrier, but I think
> it's worth having a go at following what's happening.
I followed it enough to try and recreate the approach in my script language.
However the first real input I gave it, I got a stack overflow after 500
lines.
----------------------------------
https://github.com/sal55/langs/blob/master/comments.q
(Not lazily evaluated. tail/drop are like the Haskell versions. Tested -
after I increased the stack size - on a 900-line module, which appeared
to have the comments elided, and which compiled. But the executable
showed some differences from the original.
But I don't know well your version would have worked as I can't test it.
I haven't bothered with C's intra-token line continuation, as it's rare
a program actually makes use of it.)
----------------------------------
>
> Haskell has two big advantages for this exercise: pattern matched cases
> and lazy evaluation. The case-by-case definition lets you say, very
> clearly, how to handle each situation, and the lazy evaluation means you
> can chain function calls to make processing pipelines like this:
>
> putStr (strip (logicalLines input))
>
> This means output the string of characters that result from stripping
> comments from the logical lines, but at no time is the whole input in
> memory. Characters are fetched as needed to satisfy each function call.
It also encourages recursive algorithms which as I found can cause problems.
The pattern matching is rather nice. But if it it doesn't work, I'd
imagine it's harder to debug.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2020-12-06 23:38 +0000 |
| Message-ID | <87v9depks0.fsf@bsb.me.uk> |
| In reply to | #156994 |
Bart <bc@freeuk.com> writes: <cut> >> Haskell has two big advantages for this exercise: pattern matched cases >> and lazy evaluation. The case-by-case definition lets you say, very >> clearly, how to handle each situation, and the lazy evaluation means you >> can chain function calls to make processing pipelines like this: >> >> putStr (strip (logicalLines input)) >> >> This means output the string of characters that result from stripping >> comments from the logical lines, but at no time is the whole input in >> memory. Characters are fetched as needed to satisfy each function call. > > It also encourages recursive algorithms which as I found can cause > problems. That's a bit muddled. You reported a stack overflow with a small input. Recursive /algorithms/ don't cause such problems, language implementations do. > The pattern matching is rather nice. But if it it doesn't work, I'd > imagine it's harder to debug. Harder than what? I haven't seen an example posted so far that I'd rather debug than this one. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2020-12-07 00:17 +0000 |
| Message-ID | <BwezH.167646$Cu1.29609@fx27.ams4> |
| In reply to | #157000 |
On 06/12/2020 23:38, Ben Bacarisse wrote: > Bart <bc@freeuk.com> writes: > <cut> >>> Haskell has two big advantages for this exercise: pattern matched cases >>> and lazy evaluation. The case-by-case definition lets you say, very >>> clearly, how to handle each situation, and the lazy evaluation means you >>> can chain function calls to make processing pipelines like this: >>> >>> putStr (strip (logicalLines input)) >>> >>> This means output the string of characters that result from stripping >>> comments from the logical lines, but at no time is the whole input in >>> memory. Characters are fetched as needed to satisfy each function call. >> >> It also encourages recursive algorithms which as I found can cause >> problems. > > That's a bit muddled. You reported a stack overflow with a small input. > Recursive /algorithms/ don't cause such problems, language > implementations do. You need an implementation to run the code. My version of your algorithm appears to use a maximum call depth (counting only calls to stripcomments, skipquote, nestedcomment) equal to the number of generated characters in the output. With the default stack size of my language, which suffices for most things including running the non-recursive version on inputs up to 8MB, it could only run this on inputs of 15KB (output of 7KB as it collapses some comments to a space). Practicality matters! >> The pattern matching is rather nice. But if it it doesn't work, I'd >> imagine it's harder to debug. > > Harder than what? I haven't seen an example posted so far that I'd > rather debug than this one. I wouldn't know where to put my print statements. I find recursive code difficult anyway.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2020-12-07 02:09 +0000 |
| Message-ID | <878saapdsi.fsf@bsb.me.uk> |
| In reply to | #157003 |
Bart <bc@freeuk.com> writes: > On 06/12/2020 23:38, Ben Bacarisse wrote: >> Bart <bc@freeuk.com> writes: >> <cut> >>>> Haskell has two big advantages for this exercise: pattern matched cases >>>> and lazy evaluation. The case-by-case definition lets you say, very >>>> clearly, how to handle each situation, and the lazy evaluation means you >>>> can chain function calls to make processing pipelines like this: >>>> >>>> putStr (strip (logicalLines input)) >>>> >>>> This means output the string of characters that result from stripping >>>> comments from the logical lines, but at no time is the whole input in >>>> memory. Characters are fetched as needed to satisfy each function call. >>> >>> It also encourages recursive algorithms which as I found can cause >>> problems. >> >> That's a bit muddled. You reported a stack overflow with a small input. >> Recursive /algorithms/ don't cause such problems, language >> implementations do. > > You need an implementation to run the code. Yes. Yours appears to be unsuitable. That's not a criticism -- it's not designed for this sort of code. Haskell implementations are (or should be). > My version of your algorithm appears to use a maximum call depth > (counting only calls to stripcomments, skipquote, nestedcomment) equal > to the number of generated characters in the output. It's almost certainly not the same algorithm since your language is probably not lazy. There's a grey area about what makes two bits of code be "the same algorithm" so this is probably a rabbit hole we don't need to go down. > With the default stack size of my language, which suffices for most > things including running the non-recursive version on inputs up to > 8MB, it could only run this on inputs of 15KB (output of 7KB as it > collapses some comments to a space). > > Practicality matters! Yes. Apparently you should not write the sort of code you wrote in your language (at least as it is currently implemented). -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2020-12-07 01:03 -0800 |
| Message-ID | <86v9dehts2.fsf@linuxsc.com> |
| In reply to | #156992 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> Prompted by some recent discussion regarding 'goto' statements and
>> state machines, I would like to propose a programming exercise.
>> (It is perhaps a bit too large to be called an exercise, but not so
>> difficult that it deserves the label of challenge. On the other
>> hand there are some constraints so maybe challenge is apropos. In
>> any case somewhere in between those two bounds.)
>>
>> Short problem statement: a C program to remove comments from C
>> source input.
>
> Apologies for non-C code but I could not resist...
>
> In all the goto/no goto discussion its easy to lose track of the fact
> the C does not necessarily have the best primitives for constructing
> this sort of program. I don't mean things like, say, complex regular
> expressions, or built-in grammar parsing (al la Perl6). I mean basic
> language constructs.
>
> Here is a solution in Haskell. It is deliberately not very
> "Haskelly" because I want to keep the code really simple for
> programmers unfamiliar with the language.
>
> main = do input <- getContents
> putStr (stripComments (logicalLines input))
>
> stripComments [] = []
> stripComments ('/' : '/' : rest) = stripComments (dropWhile (/= '\n') rest)
> stripComments ('/' : '*' : rest) = ' ' : stripComments (nestedComment rest)
> stripComments (c : rest) = c : if c == '\'' || c == '"'
> then skipQuote c rest
> else stripComments rest
>
> nestedComment ('*' : '/' : rest) = rest
> nestedComment (c : rest) = nestedComment rest
> nestedComment [] = error "Unterminated comment"
>
> skipQuote q ('\\' : c : rest) = '\\' : c : skipQuote q rest
> skipQuote q (c : rest) = c : if c == q
> then stripComments rest
> else skipQuote q rest
> skipQuote q [] = error "Unterminated literal"
>
> logicalLines ('\\' : '\n' : rest) = logicalLines rest
> logicalLines (c : rest) = c : logicalLines rest
> logicalLines [] = []
>
> [..some explanation of Haskell language..]
It's a nice program, but it doesn't quite do what was asked for.
The problem statement says to remove comments. This program does
remove comments, but it also takes out line splices to replace
multiple physical lines with their corresponding logical line.
Line continuation sequences outside of comments should be
preserved in the output.
> Haskell has two big advantages for this exercise: pattern matched
> cases and lazy evaluation. [..explanation..]
Also one not mentioned: 'input <- getContents'. An analogous
functionality in C would read the contents of a file into a
character array, which would make the C program easier.
> Originally, I just wrote stripComments, but when I decided to
> include logical line processing (C's \<newline> "continuation"
> mechanism) it was trivial to put it in. [...]
Line continuation sequences have to be processed if the original
problem statement is to be met. What was done here, with the
function 'logicalLines', is easy, but it changes the problem
being solved.
> I am now tempted to try to write a C version that preserves as much
> of what I see as the clarity and simplicity of this solution. I am
> not as hopeful as I'd like to be about that!
I am a fan of Haskell as you know, and I enjoyed reading your
program here. However, what I think would be more in keeping
with the spirit of the requested problem is to write in Haskell
something that is more like what might be done in a C program.
Output might be done functionally, producing a list as a result,
but input should be one character at a time, like what would
happen in a normal C program running a state machine. Doing that
would make the program more accessible to those people who are
experienced C programmers but lack experience in Haskell or
functional programming. That strikes me as a better fit for a
comp.lang.c posting.
Of course, independent of that, I also would like to see your try
at a C program as the problem was originally asked. So I hope we
will see one or both of those suggestions from you sometime soon.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2020-12-07 12:05 +0000 |
| Message-ID | <87360hq0si.fsf@bsb.me.uk> |
| In reply to | #157014 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes: > It's a nice program, but it doesn't quite do what was asked for. > The problem statement says to remove comments. This program does > remove comments, but it also takes out line splices to replace > multiple physical lines with their corresponding logical line. > Line continuation sequences outside of comments should be > preserved in the output. Ah, I didn't see that in the specification. Given the phases described in the standard, I implemented what I guessed was the expected behaviour. > Ben Bacarisse <ben.usenet@bsb.me.uk> writes: <cut> >> Haskell has two big advantages for this exercise: pattern matched >> cases and lazy evaluation. [..explanation..] > > Also one not mentioned: 'input <- getContents'. An analogous > functionality in C would read the contents of a file into a > character array, which would make the C program easier. I don't think it's analogous at all! 'input' <- getContents does no IO. Input is fetched only as needed to perform computations on 'input' and processed data will be considered garbage. > Of course, independent of that, I also would like to see your try > at a C program as the problem was originally asked. So I hope we > will see one or both of those suggestions from you sometime soon. Preserving uncommented line continuations makes the problem seem a little contrived to me. I'm not tempted to have a go. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2020-12-07 12:25 +0000 |
| Message-ID | <1bpzH.151400$zz79.48736@fx17.ams4> |
| In reply to | #157020 |
On 07/12/2020 12:05, Ben Bacarisse wrote:
> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> It's a nice program, but it doesn't quite do what was asked for.
>> The problem statement says to remove comments. This program does
>> remove comments, but it also takes out line splices to replace
>> multiple physical lines with their corresponding logical line.
>> Line continuation sequences outside of comments should be
>> preserved in the output.
>
> Ah, I didn't see that in the specification. Given the phases described
> in the standard, I implemented what I guessed was the expected
> behaviour.
>
>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> <cut>
>>> Haskell has two big advantages for this exercise: pattern matched
>>> cases and lazy evaluation. [..explanation..]
>>
>> Also one not mentioned: 'input <- getContents'. An analogous
>> functionality in C would read the contents of a file into a
>> character array, which would make the C program easier.
>
> I don't think it's analogous at all! 'input' <- getContents does no IO.
> Input is fetched only as needed to perform computations on 'input' and
> processed data will be considered garbage.
>
>> Of course, independent of that, I also would like to see your try
>> at a C program as the problem was originally asked. So I hope we
>> will see one or both of those suggestions from you sometime soon.
>
> Preserving uncommented line continuations makes the problem seem a
> little contrived to me. I'm not tempted to have a go.
>
The approach I used was to turn everything normally part of a comment,
into a space, except for new lines inside /*...*/ comments (which I
implemented as being un-nested; your program seems to assume that they
nest).
That should mean the output being the same size as the input.
It doesn't touch \ line continuations, other than '// abc \' comments
needing to continue to a subsequent line. Here the \ is turned into a
space too, with the rest of the comment.
It doesn't deal with \ line continuation inside //:
... /\
/ comment
And it assumes single-character 'x' constants (otherwise it would have
to treat them like strings in case comment delimiters are inside).
The spec did say to make your own decisions on corner cases.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2020-12-07 13:33 +0000 |
| Message-ID | <87mtypoi5i.fsf@bsb.me.uk> |
| In reply to | #157021 |
Bart <bc@freeuk.com> writes: > The approach I used was to turn everything normally part of a comment, > into a space, except for new lines inside /*...*/ comments (which I > implemented as being un-nested; your program seems to assume that they > nest). No, it does what C expects (unless I've got bugs in there I've not spotted). > It doesn't touch \ line continuations, other than '// abc \' comments > needing to continue to a subsequent line. Here the \ is turned into a > space too, with the rest of the comment. > > It doesn't deal with \ line continuation inside //: > > ... /\ > / comment There are other issues with them as well of course. Dealing with them whilst leaving them in (when uncommented) seems unnatural to me given then description of the compiler's phases in the standard. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2020-12-07 14:18 +0000 |
| Message-ID | <jRqzH.118721$7b79.17144@fx25.ams4> |
| In reply to | #157028 |
On 07/12/2020 13:33, Ben Bacarisse wrote: > Bart <bc@freeuk.com> writes: > >> The approach I used was to turn everything normally part of a comment, >> into a space, except for new lines inside /*...*/ comments (which I >> implemented as being un-nested; your program seems to assume that they >> nest). > > No, it does what C expects (unless I've got bugs in there I've not > spotted). Well, you did call the function nestedComment! > >> It doesn't touch \ line continuations, other than '// abc \' comments >> needing to continue to a subsequent line. Here the \ is turned into a >> space too, with the rest of the comment. >> >> It doesn't deal with \ line continuation inside //: >> >> ... /\ >> / comment > > There are other issues with them as well of course. Dealing with them > whilst leaving them in (when uncommented) seems unnatural to me given > then description of the compiler's phases in the standard. > If you mean needing to deal with /\/ (with a line break after \) in order to recognise the // comment, but leaving ma\in unchanged, that does seem at odds with how C is normally processed. But this is isn't normal processing, it's removing comments while preserving as much as possible of non-comments. So I think it is reasonable. (Except I don't personally agree with splitting tokens across lines, so will not implement it. Anyone who splits "//" across two, or possibly N lines, should be fired. It's not even a feature that would allow arbitrary insertion of \<newline> anywhere (eg. inside string literals, or just before an existing \<newline>) so I can't see the point. I guess it was a side-effect of some early implementation, that for some reason has been perpetuated.)
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2020-12-07 14:31 +0000 |
| Message-ID | <b1rzH.469867$LMma.174988@fx47.ams4> |
| In reply to | #157031 |
On 07/12/2020 14:18, Bart wrote: > (Except I don't personally agree with splitting tokens across lines, so > will not implement it. Anyone who splits "//" across two, or possibly N > lines, should be fired. > > It's not even a feature that would allow arbitrary insertion of > \<newline> anywhere (eg. inside string literals, or just before an > existing \<newline>) so I can't see the point. I keep forgetting that \ would be followed by <newline>, so maybe it /is/ possible to allow it everywhere, even put every character of a source file on its own line. I still think it is not necessary to allow tokens to be split across lines. Actually it's funny that C allows so much freedom with \ given that, unlike many languages, C hardly ever needs to use \ to continue code into a following line. (I think only for macro bodies; the //abc\ case is a misfeature.)
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2020-12-07 12:58 -0500 |
| Message-ID | <N2uzH.111846$ZbR7.30044@fx01.iad> |
| In reply to | #157032 |
On 12/7/20 9:31 AM, Bart wrote: > On 07/12/2020 14:18, Bart wrote: > >> (Except I don't personally agree with splitting tokens across lines, >> so will not implement it. Anyone who splits "//" across two, or >> possibly N lines, should be fired. >> >> It's not even a feature that would allow arbitrary insertion of >> \<newline> anywhere (eg. inside string literals, or just before an >> existing \<newline>) so I can't see the point. > > I keep forgetting that \ would be followed by <newline>, so maybe it > /is/ possible to allow it everywhere, even put every character of a > source file on its own line. > > I still think it is not necessary to allow tokens to be split across lines. > > Actually it's funny that C allows so much freedom with \ given that, > unlike many languages, C hardly ever needs to use \ to continue code > into a following line. (I think only for macro bodies; the //abc\ case > is a misfeature.) I think it came about as C was (is?) a common 'output' language for many code generators, and coupled with fixed 80 column screens, having a fixed output width of the code was important, so being able to just split the code anywhere was useful. Combined with the simplistic multi-phase processing, it wasn't that hard to do, so it became the 'standard', and thus was put into the Standard.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2020-12-08 23:03 -0800 |
| Message-ID | <86czzj7979.fsf@linuxsc.com> |
| In reply to | #157042 |
Richard Damon <Richard@Damon-Family.org> writes: > On 12/7/20 9:31 AM, Bart wrote: > >> On 07/12/2020 14:18, Bart wrote: >> >>> (Except I don't personally agree with splitting tokens across lines, >>> so will not implement it. Anyone who splits "//" across two, or >>> possibly N lines, should be fired. >>> >>> It's not even a feature that would allow arbitrary insertion of >>> \<newline> anywhere (eg. inside string literals, or just before an >>> existing \<newline>) so I can't see the point. >> >> I keep forgetting that \ would be followed by <newline>, so maybe it >> /is/ possible to allow it everywhere, even put every character of a >> source file on its own line. >> >> I still think it is not necessary to allow tokens to be split across lines. >> >> Actually it's funny that C allows so much freedom with \ given that, >> unlike many languages, C hardly ever needs to use \ to continue code >> into a following line. (I think only for macro bodies; the //abc\ case >> is a misfeature.) > > I think it came about as C was (is?) a common 'output' language for many > code generators, and coupled with fixed 80 column screens, having a > fixed output width of the code was important, so being able to just > split the code anywhere was useful. I expect it came about in the very early days of C when the C preprocessor was a completely separate program and knew nothing of C syntax, in which case having it be completely independent of the language syntax is about the only thing that makes sense.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2020-12-07 07:12 -0800 |
| Message-ID | <49e0ff82-165a-47ed-b117-3115808750ean@googlegroups.com> |
| In reply to | #157031 |
On Monday, 7 December 2020 at 14:19:14 UTC, Bart wrote: > On 07/12/2020 13:33, Ben Bacarisse wrote: > > Bart <b...@freeuk.com> writes: > > > >> The approach I used was to turn everything normally part of a comment, > >> into a space, except for new lines inside /*...*/ comments (which I > >> implemented as being un-nested; your program seems to assume that they > >> nest). > > > > No, it does what C expects (unless I've got bugs in there I've not > > spotted). > Well, you did call the function nestedComment! > > > >> It doesn't touch \ line continuations, other than '// abc \' comments > >> needing to continue to a subsequent line. Here the \ is turned into a > >> space too, with the rest of the comment. > >> > >> It doesn't deal with \ line continuation inside //: > >> > >> ... /\ > >> / comment > > > > There are other issues with them as well of course. Dealing with them > > whilst leaving them in (when uncommented) seems unnatural to me given > > then description of the compiler's phases in the standard. > > > If you mean needing to deal with /\/ (with a line break after \) in > order to recognise the // comment, but leaving ma\in unchanged, that > does seem at odds with how C is normally processed. > > But this is isn't normal processing, it's removing comments while > preserving as much as possible of non-comments. > > So I think it is reasonable. > > (Except I don't personally agree with splitting tokens across lines, so > will not implement it. Anyone who splits "//" across two, or possibly N > lines, should be fired. > > It's not even a feature that would allow arbitrary insertion of > \<newline> anywhere (eg. inside string literals, or just before an > existing \<newline>) so I can't see the point. > > I guess it was a side-effect of some early implementation, that for some > reason has been perpetuated.) > Yes don't think anyone ever sat down and said "shall we allow comment delimiter tokens to be split across logical line continuations ?". Rather it was decided that logical line continuation would be a low-level, first pass operation. This has the effect of creating a difficult special case for programs which strip comments but preserve line continuation tokens. One option is to simply ignore the split token case. But this means shipping a deliberate bug, and something which could potentially be exploited. That might or might not matter, it depends who is using the program. It's unlikely that a non-malicious human user would split a comment token. On the other hand, if code has been put through a fairly primitive "max line length" automatic filter, there might be a few odd non-contrived cases.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2020-12-07 21:55 +0000 |
| Message-ID | <87blf5nuvn.fsf@bsb.me.uk> |
| In reply to | #157031 |
Bart <bc@freeuk.com> writes: > On 07/12/2020 13:33, Ben Bacarisse wrote: >> Bart <bc@freeuk.com> writes: >> >>> The approach I used was to turn everything normally part of a comment, >>> into a space, except for new lines inside /*...*/ comments (which I >>> implemented as being un-nested; your program seems to assume that they >>> nest). >> >> No, it does what C expects (unless I've got bugs in there I've not >> spotted). > > Well, you did call the function nestedComment! Yes, that's a bad name. The "nested" had nothing to do with the comments nesting (I just meant "inside") but it gives the wrong impression altogether. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2020-12-08 22:59 -0800 |
| Message-ID | <86h7ov79dm.fsf@linuxsc.com> |
| In reply to | #157031 |
Bart <bc@freeuk.com> writes: > On 07/12/2020 13:33, Ben Bacarisse wrote: > >> Bart <bc@freeuk.com> writes: [...] >>> It doesn't deal with \ line continuation inside //: >>> >>> ... /\ >>> / comment >> >> There are other issues with them as well of course. Dealing with them >> while leaving them in (when uncommented) seems unnatural to me given >> then description of the compiler's phases in the standard. > > If you mean needing to deal with /\/ (with a line break after \) in > order to recognise the // comment, but leaving ma\in unchanged, that > does seem at odds with how C is normally processed. > > But this is isn't normal processing, it's removing comments while > preserving as much as possible of non-comments. Yes, that description matches the behavior intended.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2020-12-08 22:55 -0800 |
| Message-ID | <86lfe779k6.fsf@linuxsc.com> |
| In reply to | #157021 |
Bart <bc@freeuk.com> writes: [...] > The spec did say to make your own decisions on corner cases. Corner cases are meant to be only for input that the C standard specifies as undefined behavior.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2020-12-09 07:45 -0500 |
| Message-ID | <lF3AH.20085$hz6.8960@fx39.iad> |
| In reply to | #157119 |
On 12/9/20 1:55 AM, Tim Rentsch wrote: > Bart <bc@freeuk.com> writes: > > [...] > >> The spec did say to make your own decisions on corner cases. > > Corner cases are meant to be only for input that the C > standard specifies as undefined behavior. > or implementation defined or unspecified behavior, like the \<space><newline> case.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2020-12-24 11:26 -0800 |
| Message-ID | <865z4ryphr.fsf@linuxsc.com> |
| In reply to | #157149 |
Richard Damon <Richard@Damon-Family.org> writes: > On 12/9/20 1:55 AM, Tim Rentsch wrote: > >> Bart <bc@freeuk.com> writes: >> >> [...] >> >>> The spec did say to make your own decisions on corner cases. >> >> Corner cases are meant to be only for input that the C >> standard specifies as undefined behavior. > > or implementation defined or unspecified behavior, like the > \<space><newline> case. No, I meant what I said. Furthermore any compiler that accepts \<space><newline> as a line continuation is not conforming, as I have explained else-thread.
[toc] | [prev] | [next] | [standalone]
Page 4 of 20 — ← Prev page 1 2 3 [4] 5 6 … 20 Next page →
Back to top | Article view | comp.lang.c
csiph-web