Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #396684 > unrolled thread
| Started by | DFS <nospam@dfs.com> |
|---|---|
| First post | 2026-02-19 16:55 -0500 |
| Last post | 2026-03-16 09:04 +0100 |
| Articles | 20 on this page of 218 — 21 participants |
Back to article view | Back to comp.lang.c
Sort of trivial code challenge - may be interesting to you anyway DFS <nospam@dfs.com> - 2026-02-19 16:55 -0500
Re: Sort of trivial code challenge - may be interesting to you anyway jayjwa <jayjwa@atr2.ath.cx.invalid> - 2026-02-25 15:56 -0500
Re: Sort of trivial code challenge - may be interesting to you anyway DFS <nospam@dfs.com> - 2026-02-26 10:05 -0500
Re: Sort of trivial code challenge - may be interesting to you anyway jayjwa <jayjwa@atr2.ath.cx.invalid> - 2026-02-26 13:20 -0500
Re: Sort of trivial code challenge - may be interesting to you anyway Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2026-02-26 17:06 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2026-02-26 17:27 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway DFS <nospam@dfs.com> - 2026-02-26 14:31 -0500
Re: Sort of trivial code challenge - may be interesting to you anyway jayjwa <jayjwa@atr2.ath.cx.invalid> - 2026-02-26 13:33 -0500
Re: Sort of trivial code challenge - may be interesting to you anyway Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2026-02-26 18:49 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2026-02-26 18:55 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2026-02-26 19:17 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2026-02-26 19:34 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2026-02-26 20:01 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway DFS <nospam@dfs.com> - 2026-03-06 10:36 -0500
Re: Sort of trivial code challenge - may be interesting to you anyway Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2026-03-06 17:38 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2026-03-06 17:48 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway Bart <bc@freeuk.com> - 2026-02-27 00:12 +0000
[OT] Bart's scripting language solution (was Re: Sort of trivial code challenge - may be interesting to you anyway) Janis Papanagnou <janis_papanagnou@hotmail.com> - 2026-03-06 06:37 +0100
Re: [OT] Bart's scripting language solution (was Re: Sort of trivial code challenge - may be interesting to you anyway) Bart <bc@freeuk.com> - 2026-03-06 15:48 +0000
Re: [OT] Bart's scripting language solution (was Re: Sort of trivial code challenge - may be interesting to you anyway) Janis Papanagnou <janis_papanagnou@hotmail.com> - 2026-03-06 18:17 +0100
Re: [OT] Bart's scripting language solution (was Re: Sort of trivial code challenge - may be interesting to you anyway) Bart <bc@freeuk.com> - 2026-03-06 21:46 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-02 00:44 -0800
Re: Sort of trivial code challenge - may be interesting to you anyway Michael S <already5chosen@yahoo.com> - 2026-03-02 11:07 +0200
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-02 06:35 -0800
Re: Sort of trivial code challenge - may be interesting to you anyway Bart <bc@freeuk.com> - 2026-03-02 17:50 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-02 21:15 -0800
Re: Sort of trivial code challenge - may be interesting to you anyway Bart <bc@freeuk.com> - 2026-03-03 20:48 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-03-03 22:47 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway David Brown <david.brown@hesbynett.no> - 2026-03-04 08:48 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-03-04 01:07 -0800
Re: Sort of trivial code challenge - may be interesting to you anyway Michael S <already5chosen@yahoo.com> - 2026-03-04 12:09 +0200
Re: Sort of trivial code challenge - may be interesting to you anyway Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-03-04 11:19 -0800
Re: Sort of trivial code challenge - may be interesting to you anyway David Brown <david.brown@hesbynett.no> - 2026-03-04 12:58 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway Bonita Montero <Bonita.Montero@gmail.com> - 2026-03-11 11:31 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway Bart <bc@freeuk.com> - 2026-03-04 13:20 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway DFS <nospam@dfs.com> - 2026-03-04 08:30 -0500
Re: Sort of trivial code challenge - may be interesting to you anyway Bart <bc@freeuk.com> - 2026-03-04 14:36 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway DFS <nospam@dfs.com> - 2026-03-04 10:02 -0500
Re: Sort of trivial code challenge - may be interesting to you anyway Michael S <already5chosen@yahoo.com> - 2026-03-04 19:27 +0200
Re: Sort of trivial code challenge - may be interesting to you anyway DFS <nospam@dfs.com> - 2026-03-05 13:49 -0500
Re: Sort of trivial code challenge - may be interesting to you anyway Michael S <already5chosen@yahoo.com> - 2026-03-05 21:02 +0200
Re: Sort of trivial code challenge - may be interesting to you anyway Bart <bc@freeuk.com> - 2026-03-05 20:39 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway DFS <nospam@dfs.com> - 2026-03-05 19:24 -0500
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-05 13:54 -0800
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-12 05:50 -0700
Re: Sort of trivial code challenge - may be interesting to you anyway Bart <bc@freeuk.com> - 2026-03-13 11:58 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway Bart <bc@freeuk.com> - 2026-03-13 23:00 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-15 15:54 -0700
Re: Sort of trivial code challenge - may be interesting to you anyway Bart <bc@freeuk.com> - 2026-03-15 23:42 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-04-06 12:02 -0700
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-15 15:43 -0700
Re: Sort of trivial code challenge - may be interesting to you anyway DFS <nospam@dfs.com> - 2026-03-02 17:40 -0500
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-02 21:09 -0800
Re: Sort of trivial code challenge - may be interesting to you anyway DFS <nospam@dfs.com> - 2026-03-03 08:23 -0500
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-03 06:20 -0800
Re: Sort of trivial code challenge - may be interesting to you anyway Michael S <already5chosen@yahoo.com> - 2026-03-03 23:56 +0200
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-03 15:51 -0800
Re: Sort of trivial code challenge - may be interesting to you anyway Michael S <already5chosen@yahoo.com> - 2026-03-04 11:45 +0200
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-04 07:01 -0800
Re: Sort of trivial code challenge - may be interesting to you anyway Bonita Montero <Bonita.Montero@gmail.com> - 2026-03-11 11:37 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway DFS <nospam@dfs.com> - 2026-03-04 08:29 -0500
Re: Sort of trivial code challenge - may be interesting to you anyway Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-03-04 16:02 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-04 08:09 -0800
Re: Sort of trivial code challenge - may be interesting to you anyway DFS <nospam@dfs.com> - 2026-03-06 10:34 -0500
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-06 08:46 -0800
Re: Sort of trivial code challenge - may be interesting to you anyway Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-03-04 11:25 -0800
Re: Sort of trivial code challenge - may be interesting to you anyway DFS <nospam@dfs.com> - 2026-03-05 13:46 -0500
Re: Sort of trivial code challenge - may be interesting to you anyway David Brown <david.brown@hesbynett.no> - 2026-03-05 21:34 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2026-03-05 19:09 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2026-03-05 21:12 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-05 14:12 -0800
Re: Sort of trivial code challenge - may be interesting to you anyway Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2026-03-05 22:24 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway Michael S <already5chosen@yahoo.com> - 2026-03-06 01:00 +0200
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-05 15:08 -0800
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-05 15:05 -0800
Re: Sort of trivial code challenge - may be interesting to you anyway Janis Papanagnou <janis_papanagnou@hotmail.com> - 2026-03-06 00:18 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway Michael S <already5chosen@yahoo.com> - 2026-03-07 22:04 +0200
Re: Sort of trivial code challenge - may be interesting to you anyway Janis Papanagnou <janis_papanagnou@hotmail.com> - 2026-03-08 00:26 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway Michael S <already5chosen@yahoo.com> - 2026-03-08 02:45 +0200
Re: Sort of trivial code challenge - may be interesting to you anyway Janis Papanagnou <janis_papanagnou@hotmail.com> - 2026-03-08 17:05 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-11 07:57 -0700
Re: Sort of trivial code challenge - may be interesting to you anyway Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2026-03-06 00:12 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2026-03-06 00:14 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-05 20:31 -0800
Re: Sort of trivial code challenge - may be interesting to you anyway Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2026-03-06 13:51 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-06 08:53 -0800
Re: Sort of trivial code challenge - may be interesting to you anyway DFS <nospam@dfs.com> - 2026-03-06 19:36 -0500
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-06 18:14 -0800
Re: Sort of trivial code challenge - may be interesting to you anyway Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2026-03-07 18:21 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-07 11:55 -0800
Re: Sort of trivial code challenge - may be interesting to you anyway Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2026-03-07 20:10 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-11 10:44 -0700
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-07 12:02 -0800
Re: Sort of trivial code challenge - may be interesting to you anyway Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2026-03-07 20:14 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-11 10:53 -0700
Re: Sort of trivial code challenge - may be interesting to you anyway DFS <nospam@dfs.com> - 2026-03-07 16:58 -0500
Re: Sort of trivial code challenge - may be interesting to you anyway Michael S <already5chosen@yahoo.com> - 2026-03-08 00:35 +0200
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-11 08:23 -0700
Re: Sort of trivial code challenge - may be interesting to you anyway Janis Papanagnou <janis_papanagnou@hotmail.com> - 2026-03-08 00:40 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway DFS <nospam@dfs.com> - 2026-03-08 10:42 -0400
Re: Sort of trivial code challenge - may be interesting to you anyway Bart <bc@freeuk.com> - 2026-03-08 15:18 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway DFS <nospam@dfs.com> - 2026-03-08 12:21 -0400
Re: Sort of trivial code challenge - may be interesting to you anyway Bart <bc@freeuk.com> - 2026-03-08 19:29 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway DFS <nospam@dfs.com> - 2026-03-09 21:20 -0400
Re: Sort of trivial code challenge - may be interesting to you anyway scott@slp53.sl.home (Scott Lurndal) - 2026-03-10 14:43 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway Michael S <already5chosen@yahoo.com> - 2026-03-10 18:08 +0200
Re: Sort of trivial code challenge - may be interesting to you anyway Giovanni <lsodgf0@home.net.it> - 2026-03-10 17:18 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway scott@slp53.sl.home (Scott Lurndal) - 2026-03-10 16:32 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-03-10 15:25 -0700
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-11 07:07 -0700
Re: Sort of trivial code challenge - may be interesting to you anyway Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-03-11 13:49 -0700
Re: Sort of trivial code challenge - may be interesting to you anyway Bart <bc@freeuk.com> - 2026-03-10 20:24 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-03-10 15:29 -0700
Re: Sort of trivial code challenge - may be interesting to you anyway Bart <bc@freeuk.com> - 2026-03-11 00:29 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway scott@slp53.sl.home (Scott Lurndal) - 2026-03-11 00:33 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway Bart <bc@freeuk.com> - 2026-03-11 11:04 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway antispam@fricas.org (Waldek Hebisch) - 2026-03-10 20:18 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-12 05:37 -0700
Re: Sort of trivial code challenge - may be interesting to you anyway Janis Papanagnou <janis_papanagnou@hotmail.com> - 2026-03-08 17:57 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-03-08 13:19 -0700
Re: Sort of trivial code challenge - may be interesting to you anyway Bart <bc@freeuk.com> - 2026-03-09 01:12 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway scott@slp53.sl.home (Scott Lurndal) - 2026-03-08 21:42 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-03-08 15:58 -0700
Re: Sort of trivial code challenge - may be interesting to you anyway David Brown <david.brown@hesbynett.no> - 2026-03-09 08:09 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway Janis Papanagnou <janis_papanagnou@hotmail.com> - 2026-03-09 08:53 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-03-09 15:25 -0700
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-11 14:40 -0700
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-12 05:55 -0700
Re: Sort of trivial code challenge - may be interesting to you anyway Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2026-03-08 16:00 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-11 12:44 -0700
Re: Sort of trivial code challenge - may be interesting to you anyway Janis Papanagnou <janis_papanagnou@hotmail.com> - 2026-03-08 17:36 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-03-08 13:27 -0700
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-11 06:33 -0700
Re: Sort of trivial code challenge - may be interesting to you anyway David Brown <david.brown@hesbynett.no> - 2026-03-08 12:22 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-11 06:27 -0700
Re: Sort of trivial code challenge - may be interesting to you anyway Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-03-07 16:43 -0800
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-11 07:29 -0700
Re: Sort of trivial code challenge - may be interesting to you anyway Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-03-11 14:22 -0700
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-04-25 10:07 -0700
Re: Sort of trivial code challenge - may be interesting to you anyway Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-25 15:54 -0700
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-04-30 03:13 -0700
Re: Sort of trivial code challenge - may be interesting to you anyway Bart <bc@freeuk.com> - 2026-03-06 16:02 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway DFS <nospam@dfs.com> - 2026-03-06 12:11 -0500
Re: Sort of trivial code challenge - may be interesting to you anyway DFS <nospam@dfs.com> - 2026-03-06 13:01 -0500
Re: Sort of trivial code challenge - may be interesting to you anyway DFS <nospam@dfs.com> - 2026-03-06 13:28 -0500
Re: Sort of trivial code challenge - may be interesting to you anyway Bart <bc@freeuk.com> - 2026-03-06 21:53 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway DFS <nospam@dfs.com> - 2026-03-06 22:14 -0500
Re: Sort of trivial code challenge - may be interesting to you anyway Janis Papanagnou <janis_papanagnou@hotmail.com> - 2026-03-07 07:33 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway DFS <nospam@dfs.com> - 2026-03-07 10:24 -0500
Re: Sort of trivial code challenge - may be interesting to you anyway Janis Papanagnou <janis_papanagnou@hotmail.com> - 2026-03-07 19:16 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway DFS <nospam@dfs.com> - 2026-03-07 14:18 -0500
Re: Sort of trivial code challenge - may be interesting to you anyway Janis Papanagnou <janis_papanagnou@hotmail.com> - 2026-03-08 00:47 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway DFS <nospam@dfs.com> - 2026-03-09 22:18 -0400
Re: Sort of trivial code challenge - may be interesting to you anyway Richard Harnden <richard.nospam@gmail.invalid> - 2026-03-10 10:14 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway Richard Harnden <richard.nospam@gmail.invalid> - 2026-03-11 11:40 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway Bart <bc@freeuk.com> - 2026-03-07 13:33 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway Richard Harnden <richard.nospam@gmail.invalid> - 2026-03-07 14:53 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway Bart <bc@freeuk.com> - 2026-03-07 15:44 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway Michael S <already5chosen@yahoo.com> - 2026-03-07 19:53 +0200
Re: Sort of trivial code challenge - may be interesting to you anyway DFS <nospam@dfs.com> - 2026-03-07 10:22 -0500
Re: Sort of trivial code challenge - may be interesting to you anyway Bonita Montero <Bonita.Montero@gmail.com> - 2026-03-11 11:40 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway DFS <nospam@dfs.com> - 2026-03-11 11:00 -0400
Re: Sort of trivial code challenge - may be interesting to you anyway wij <wyniijj5@gmail.com> - 2026-03-12 00:00 +0800
Re: Sort of trivial code challenge - may be interesting to you anyway Bonita Montero <Bonita.Montero@gmail.com> - 2026-03-11 18:03 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway scott@slp53.sl.home (Scott Lurndal) - 2026-03-11 17:52 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway wij <wyniijj5@gmail.com> - 2026-03-12 23:14 +0800
Re: Sort of trivial code challenge - may be interesting to you anyway Bonita Montero <Bonita.Montero@gmail.com> - 2026-03-12 16:23 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-03-12 16:11 -0700
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-05 14:04 -0800
Re: Sort of trivial code challenge - may be interesting to you anyway Bonita Montero <Bonita.Montero@gmail.com> - 2026-03-11 11:36 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway Bonita Montero <Bonita.Montero@gmail.com> - 2026-03-11 11:35 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2026-03-03 15:40 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-03 16:23 -0800
Re: Sort of trivial code challenge - may be interesting to you anyway Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2026-03-04 15:31 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-04 09:38 -0800
Re: Sort of trivial code challenge - may be interesting to you anyway Bonita Montero <Bonita.Montero@gmail.com> - 2026-03-03 16:39 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway DFS <nospam@dfs.com> - 2026-03-03 12:00 -0500
Re: Sort of trivial code challenge - may be interesting to you anyway Bonita Montero <Bonita.Montero@gmail.com> - 2026-03-04 11:44 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway DFS <nospam@dfs.com> - 2026-03-04 17:44 -0500
Re: Sort of trivial code challenge - may be interesting to you anyway Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-03-04 15:13 -0800
Re: Sort of trivial code challenge - may be interesting to you anyway DFS <nospam@dfs.com> - 2026-03-04 21:07 -0500
Re: Sort of trivial code challenge - may be interesting to you anyway scott@slp53.sl.home (Scott Lurndal) - 2026-03-04 23:37 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway Bonita Montero <Bonita.Montero@gmail.com> - 2026-03-05 07:32 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway Bonita Montero <Bonita.Montero@gmail.com> - 2026-03-05 08:23 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway DFS <nospam@dfs.com> - 2026-03-05 02:24 -0500
Re: Sort of trivial code challenge - may be interesting to you anyway Bonita Montero <Bonita.Montero@gmail.com> - 2026-03-05 08:46 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway Bonita Montero <Bonita.Montero@gmail.com> - 2026-03-05 09:52 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway tTh <tth@none.invalid> - 2026-03-05 10:49 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway Bonita Montero <Bonita.Montero@gmail.com> - 2026-03-05 11:03 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway gazelle@shell.xmission.com (Kenny McCormack) - 2026-03-05 15:22 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway DFS <nospam@dfs.com> - 2026-03-05 05:06 -0500
Re: Sort of trivial code challenge - may be interesting to you anyway Bonita Montero <Bonita.Montero@gmail.com> - 2026-03-05 11:13 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway DFS <nospam@dfs.com> - 2026-03-05 14:11 -0500
Re: Sort of trivial code challenge - may be interesting to you anyway Bonita Montero <Bonita.Montero@gmail.com> - 2026-03-06 03:35 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway scott@slp53.sl.home (Scott Lurndal) - 2026-03-05 14:49 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway Janis Papanagnou <janis_papanagnou@hotmail.com> - 2026-03-05 19:27 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway Bonita Montero <Bonita.Montero@gmail.com> - 2026-03-05 19:46 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway tTh <tth@none.invalid> - 2026-03-05 20:50 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway Michael S <already5chosen@yahoo.com> - 2026-03-05 22:34 +0200
Re: Sort of trivial code challenge - may be interesting to you anyway Bonita Montero <Bonita.Montero@gmail.com> - 2026-03-06 07:48 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway Michael S <already5chosen@yahoo.com> - 2026-03-06 11:49 +0200
Re: Sort of trivial code challenge - may be interesting to you anyway Bonita Montero <Bonita.Montero@gmail.com> - 2026-03-06 13:41 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway Michael S <already5chosen@yahoo.com> - 2026-03-06 15:33 +0200
Re: Sort of trivial code challenge - may be interesting to you anyway Bonita Montero <Bonita.Montero@gmail.com> - 2026-03-06 14:42 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-05 13:49 -0800
Re: Sort of trivial code challenge - may be interesting to you anyway scott@slp53.sl.home (Scott Lurndal) - 2026-03-06 02:17 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-05 20:06 -0800
Re: Sort of trivial code challenge - may be interesting to you anyway scott@slp53.sl.home (Scott Lurndal) - 2026-03-06 14:58 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway Michael S <already5chosen@yahoo.com> - 2026-03-06 17:13 +0200
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-06 08:37 -0800
Re: Sort of trivial code challenge - may be interesting to you anyway scott@slp53.sl.home (Scott Lurndal) - 2026-03-03 17:29 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway Bonita Montero <Bonita.Montero@gmail.com> - 2026-03-03 19:20 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-03 16:26 -0800
Re: Sort of trivial code challenge - may be interesting to you anyway Bonita Montero <Bonita.Montero@gmail.com> - 2026-03-04 05:27 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway Opus <ifonly@youknew.org> - 2026-03-04 22:42 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway peter <peter.noreply@tin.it> - 2026-03-14 10:42 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-15 15:09 -0700
Re: Sort of trivial code challenge - may be interesting to you anyway Bonita Montero <Bonita.Montero@gmail.com> - 2026-03-16 09:04 +0100
Page 2 of 11 — ← Prev page 1 [2] 3 4 … 11 Next page →
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-03-06 21:46 +0000 |
| Subject | Re: [OT] Bart's scripting language solution (was Re: Sort of trivial code challenge - may be interesting to you anyway) |
| Message-ID | <10ofi0i$11e47$1@dont-email.me> |
| In reply to | #396830 |
On 06/03/2026 17:17, Janis Papanagnou wrote: > On 06.03.26 16:48, Bart wrote: >> On 06/03/2026 05:37, Janis Papanagnou wrote: >>> On 27.02.26 01:12, Bart wrote: >>>> [...] >>>> I used my scripting language to come up with the solution below for >>>> when there is a single N input, as that looked more challenging. >>>> >>>> It took 20 minutes to get output corresponding more or less to your >>>> examples. (While columns are lined up, they don't exactly match in >>>> white space esp. at the start of each line; see example after the >>>> code.) >>>> >>>> Once the algorithm is done, rewriting to any other language, >>>> including C, would be trivial. >>> >>> Just one question about your algorithm; why this line...? >>> >>> for c in 1..cols when i<=n do >>> >>> Assuming that 'when' works like 'while', it seems to me that >>> >>> while i<=n do >>> >>> should suffice. - No? >> >> 'when' is a per-iteration guard. It skips only that iteration when >> false, unlike 'for-while' in Algol68 which terminates the loop. > > Ah, okay, I see. A condition for exceptional cases during the loop. > > My question on the algorithm still remains; can't that for/when loop > be replaced by the simpler while condition? - It appears to me that > the simpler 'while' condition is sufficient here to express what's > algorithmically needed. Well, I tried it and it still works, so you're right. But it's not intuitive to me: we're iterating over a square matrix, so a nested loop over rows and cols is the obvious way to do it (I was also doing it under a time constraint). The 'when' condition is to suppress output for the last column here, where N is 23, and the matrix is 5 x 5 elements: 1 6 11 16 21 2 7 12 17 22 3 8 13 18 23 4 9 14 19 5 10 15 20
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-03-02 00:44 -0800 |
| Message-ID | <86v7feei2e.fsf@linuxsc.com> |
| In reply to | #396684 |
DFS <nospam@dfs.com> writes: > Challenge is to output sequential numbers by column then row: > > 1 6 11 16 21 > 2 7 12 17 22 > 3 8 13 18 23 > 4 9 14 19 24 > 5 10 15 20 25 [...] > Simple enough. But the following 2 requirements take it from trivial > to less trivial! > > -------------------------------------------------------------------- > 1) must be able to cut the output off at any arbitrary value > lower than rows x columns > -------------------------------------------------------------------- [...] > -------------------------------------------------------------------- > 2) if you don't specify rows and columns, your solution must try > to calculate them to form a square (same # of rows and columns) > that includes only 1 to N. > > If rows=columns can't be calculated, return message 'not possible' > -------------------------------------------------------------------- A straightfoward exercise. Here is a counter challenge to make things more interesting: as above, but don't use nested loops (or goto's, etc).
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-03-02 11:07 +0200 |
| Message-ID | <20260302110720.00007698@yahoo.com> |
| In reply to | #396724 |
On Mon, 02 Mar 2026 00:44:57 -0800 Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > DFS <nospam@dfs.com> writes: > > > Challenge is to output sequential numbers by column then row: > > > > 1 6 11 16 21 > > 2 7 12 17 22 > > 3 8 13 18 23 > > 4 9 14 19 24 > > 5 10 15 20 25 > > [...] > > > Simple enough. But the following 2 requirements take it from > > trivial to less trivial! > > > > -------------------------------------------------------------------- > > 1) must be able to cut the output off at any arbitrary value > > lower than rows x columns > > -------------------------------------------------------------------- > > > > [...] > > > -------------------------------------------------------------------- > > 2) if you don't specify rows and columns, your solution must try > > to calculate them to form a square (same # of rows and columns) > > that includes only 1 to N. > > > > If rows=columns can't be calculated, return message 'not > > possible' > > -------------------------------------------------------------------- > > > > A straightfoward exercise. Here is a counter challenge to make > things more interesting: as above, but don't use nested loops > (or goto's, etc). Does 'etc' include function calls? I guess that the answer is 'yes', but would like it confirmed. Another counter challenge could have been to commpletely avoid loops/goto. But given the hint above it would not be interesting.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-03-02 06:35 -0800 |
| Message-ID | <86qzq2e1u3.fsf@linuxsc.com> |
| In reply to | #396725 |
Michael S <already5chosen@yahoo.com> writes: > On Mon, 02 Mar 2026 00:44:57 -0800 > Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > >> DFS <nospam@dfs.com> writes: >> >>> Challenge is to output sequential numbers by column then row: >>> >>> 1 6 11 16 21 >>> 2 7 12 17 22 >>> 3 8 13 18 23 >>> 4 9 14 19 24 >>> 5 10 15 20 25 >> >> [...] >> >>> Simple enough. But the following 2 requirements take it from >>> trivial to less trivial! >>> >>> -------------------------------------------------------------------- >>> 1) must be able to cut the output off at any arbitrary value >>> lower than rows x columns >>> -------------------------------------------------------------------- >> >> [...] >> >>> -------------------------------------------------------------------- >>> 2) if you don't specify rows and columns, your solution must try >>> to calculate them to form a square (same # of rows and columns) >>> that includes only 1 to N. >>> >>> If rows=columns can't be calculated, return message 'not >>> possible' >>> -------------------------------------------------------------------- >> >> A straightfoward exercise. Here is a counter challenge to make >> things more interesting: as above, but don't use nested loops >> (or goto's, etc). > > Does 'etc' include function calls? > I guess that the answer is 'yes', but would like it confirmed. I don't think of function calls as being in the same category as control flow statements. I guess the point of your question is one loop could be in a function called from within another loop. The "don't use nested loops" is meant to include dynamic nesting as well as static nesting. In other words one loop running, by any means, during the time another loop is in progress, is disallowed. So a call to a function where the call is inside a loop, and where the called function effects a loop in some way, is not allowed any more than 'for(...) for(...)' would be. Is that specific and well-defined enough to answer your question? There is no prohibition against function calls per se; the relevant condition is about loops, including simulated loops that don't use for() or while() or do/while(). > Another counter challenge could have been to commpletely avoid > loops/goto. But given the hint above it would not be interesting. I am confident it wouldn't be challenging for someone with your level of experience, but it could be interesting for some other folks. The version of this program that I wrote has no for()'s, while()'s, do/while()'s, or switch() statements, and also has no nested loops, and I found it more interesting to write that version than one where for() or while() were used. I think that would make a nice second-level challenge. For a third challenge, write a version that doesn't use for(), while(), do/while(), goto, and also does not have recursive function calls.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-03-02 17:50 +0000 |
| Message-ID | <10o4ilk$1bo87$1@dont-email.me> |
| In reply to | #396728 |
On 02/03/2026 14:35, Tim Rentsch wrote: > Michael S <already5chosen@yahoo.com> writes: > >> On Mon, 02 Mar 2026 00:44:57 -0800 >> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: >> >>> DFS <nospam@dfs.com> writes: >>> >>>> Challenge is to output sequential numbers by column then row: >>>> >>>> 1 6 11 16 21 >>>> 2 7 12 17 22 >>>> 3 8 13 18 23 >>>> 4 9 14 19 24 >>>> 5 10 15 20 25 >>> >>> [...] >>> >>>> Simple enough. But the following 2 requirements take it from >>>> trivial to less trivial! >>>> >>>> -------------------------------------------------------------------- >>>> 1) must be able to cut the output off at any arbitrary value >>>> lower than rows x columns >>>> -------------------------------------------------------------------- >>> >>> [...] >>> >>>> -------------------------------------------------------------------- >>>> 2) if you don't specify rows and columns, your solution must try >>>> to calculate them to form a square (same # of rows and columns) >>>> that includes only 1 to N. >>>> >>>> If rows=columns can't be calculated, return message 'not >>>> possible' >>>> -------------------------------------------------------------------- >>> >>> A straightfoward exercise. Here is a counter challenge to make >>> things more interesting: as above, but don't use nested loops >>> (or goto's, etc). >> >> Does 'etc' include function calls? >> I guess that the answer is 'yes', but would like it confirmed. > > I don't think of function calls as being in the same category > as control flow statements. I guess the point of your question > is one loop could be in a function called from within another > loop. The "don't use nested loops" is meant to include dynamic > nesting as well as static nesting. In other words one loop > running, by any means, during the time another loop is in > progress, is disallowed. So a call to a function where the call > is inside a loop, and where the called function effects a loop > in some way, is not allowed any more than 'for(...) for(...)' > would be. Is that specific and well-defined enough to answer > your question? There is no prohibition against function calls > per se; the relevant condition is about loops, including > simulated loops that don't use for() or while() or do/while(). > >> Another counter challenge could have been to commpletely avoid >> loops/goto. But given the hint above it would not be interesting. > > I am confident it wouldn't be challenging for someone with your > level of experience, but it could be interesting for some other > folks. > The version of this program that I wrote has no for()'s, > while()'s, do/while()'s, or switch() statements, and also has > no nested loops, Doesn't the prior condition preclude that? Since if there are zero loops, it's hard to make them nested! >and also does not have recursive > function calls. Is that a hint that the loop-less version you had in mind used recursion instead?
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-03-02 21:15 -0800 |
| Message-ID | <86ikbdebo8.fsf@linuxsc.com> |
| In reply to | #396729 |
Bart <bc@freeuk.com> writes: > On 02/03/2026 14:35, Tim Rentsch wrote: > >> Michael S <already5chosen@yahoo.com> writes: >> >>> On Mon, 02 Mar 2026 00:44:57 -0800 >>> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: >>> >>>> DFS <nospam@dfs.com> writes: >>>> >>>>> Challenge is to output sequential numbers by column then row: >>>>> >>>>> 1 6 11 16 21 >>>>> 2 7 12 17 22 >>>>> 3 8 13 18 23 >>>>> 4 9 14 19 24 >>>>> 5 10 15 20 25 >>>> >>>> [...] >>>> >>>>> Simple enough. But the following 2 requirements take it from >>>>> trivial to less trivial! >>>>> >>>>> -------------------------------------------------------------------- >>>>> 1) must be able to cut the output off at any arbitrary value >>>>> lower than rows x columns >>>>> -------------------------------------------------------------------- >>>> >>>> [...] >>>> >>>>> -------------------------------------------------------------------- >>>>> 2) if you don't specify rows and columns, your solution must try >>>>> to calculate them to form a square (same # of rows and columns) >>>>> that includes only 1 to N. >>>>> >>>>> If rows=columns can't be calculated, return message 'not >>>>> possible' >>>>> -------------------------------------------------------------------- >>>> >>>> A straightfoward exercise. Here is a counter challenge to make >>>> things more interesting: as above, but don't use nested loops >>>> (or goto's, etc). >>> >>> Does 'etc' include function calls? >>> I guess that the answer is 'yes', but would like it confirmed. >> >> I don't think of function calls as being in the same category >> as control flow statements. I guess the point of your question >> is one loop could be in a function called from within another >> loop. The "don't use nested loops" is meant to include dynamic >> nesting as well as static nesting. In other words one loop >> running, by any means, during the time another loop is in >> progress, is disallowed. So a call to a function where the call >> is inside a loop, and where the called function effects a loop >> in some way, is not allowed any more than 'for(...) for(...)' >> would be. Is that specific and well-defined enough to answer >> your question? There is no prohibition against function calls >> per se; the relevant condition is about loops, including >> simulated loops that don't use for() or while() or do/while(). >> >>> Another counter challenge could have been to commpletely avoid >>> loops/goto. But given the hint above it would not be interesting. >> >> I am confident it wouldn't be challenging for someone with your >> level of experience, but it could be interesting for some other >> folks. >> >> The version of this program that I wrote has no for()'s, >> while()'s, do/while()'s, or switch() statements, and also has >> no nested loops, > > Doesn't the prior condition preclude that? Since if there are zero > loops, it's hard to make them nested! I see no reason to answer your questions since you seem to have no interest in writing C code.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-03-03 20:48 +0000 |
| Message-ID | <10o7he5$2cb17$1@dont-email.me> |
| In reply to | #396734 |
On 03/03/2026 05:15, Tim Rentsch wrote: > Bart <bc@freeuk.com> writes: > >> On 02/03/2026 14:35, Tim Rentsch wrote: >> >>> Michael S <already5chosen@yahoo.com> writes: >>> >>>> On Mon, 02 Mar 2026 00:44:57 -0800 >>>> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: >>>> >>>>> DFS <nospam@dfs.com> writes: >>>>> >>>>>> Challenge is to output sequential numbers by column then row: >>>>>> >>>>>> 1 6 11 16 21 >>>>>> 2 7 12 17 22 >>>>>> 3 8 13 18 23 >>>>>> 4 9 14 19 24 >>>>>> 5 10 15 20 25 >>>>> >>>>> [...] >>>>> >>>>>> Simple enough. But the following 2 requirements take it from >>>>>> trivial to less trivial! >>>>>> >>>>>> -------------------------------------------------------------------- >>>>>> 1) must be able to cut the output off at any arbitrary value >>>>>> lower than rows x columns >>>>>> -------------------------------------------------------------------- >>>>> >>>>> [...] >>>>> >>>>>> -------------------------------------------------------------------- >>>>>> 2) if you don't specify rows and columns, your solution must try >>>>>> to calculate them to form a square (same # of rows and columns) >>>>>> that includes only 1 to N. >>>>>> >>>>>> If rows=columns can't be calculated, return message 'not >>>>>> possible' >>>>>> -------------------------------------------------------------------- >>>>> >>>>> A straightfoward exercise. Here is a counter challenge to make >>>>> things more interesting: as above, but don't use nested loops >>>>> (or goto's, etc). >>>> >>>> Does 'etc' include function calls? >>>> I guess that the answer is 'yes', but would like it confirmed. >>> >>> I don't think of function calls as being in the same category >>> as control flow statements. I guess the point of your question >>> is one loop could be in a function called from within another >>> loop. The "don't use nested loops" is meant to include dynamic >>> nesting as well as static nesting. In other words one loop >>> running, by any means, during the time another loop is in >>> progress, is disallowed. So a call to a function where the call >>> is inside a loop, and where the called function effects a loop >>> in some way, is not allowed any more than 'for(...) for(...)' >>> would be. Is that specific and well-defined enough to answer >>> your question? There is no prohibition against function calls >>> per se; the relevant condition is about loops, including >>> simulated loops that don't use for() or while() or do/while(). >>> >>>> Another counter challenge could have been to commpletely avoid >>>> loops/goto. But given the hint above it would not be interesting. >>> >>> I am confident it wouldn't be challenging for someone with your >>> level of experience, but it could be interesting for some other >>> folks. >>> >>> The version of this program that I wrote has no for()'s, >>> while()'s, do/while()'s, or switch() statements, and also has >>> no nested loops, >> >> Doesn't the prior condition preclude that? Since if there are zero >> loops, it's hard to make them nested! > > I see no reason to answer your questions since you seem to have > no interest in writing C code. This kind of challenge can be done in any language. My algorithm can be trivially converted to C if needed; it is clear enough. Anwway, when I submitted my version, the last post in the thread was by the OP, and it contained some Python code. So likely some here might also be prototyping in a soft language first.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-03-03 22:47 +0100 |
| Message-ID | <10o7ku0$1effk$1@dont-email.me> |
| In reply to | #396742 |
On 2026-03-03 21:48, Bart wrote:
> On 03/03/2026 05:15, Tim Rentsch wrote:
>> [...]
>
> This kind of challenge can be done in any language. My algorithm
> can be trivially converted to C if needed; it is clear enough.
Sure. But let's have a closer look...
It's debatable whether the algorithm is the challenge or whether
writing actual "C" code is the challenge, say, because "C" may
be so convoluted or just inappropriate for such tasks that it's
difficult to solve such challenges with the "C" language. - But
obviously this challenge is not challenging the "C" language in
any way; it's an ordinary ("C", or other) programming task.[*]
So I basically agree with you.[**]
Though, with the subsequent refinements, to abstain from certain
types of language constructs, i.e. programming with one arm tied
behind your back, the question is not as clearly to answer; it's
just easier to compare the various variants and code evolutions
if you have a common language base (and here in CLC that's "C").
Janis
> [...]
[*] A task that other folks might have solved by using existing
tools instead of explicit and longish error-prone programming.
[**] Not everyone here might appreciate code in other languages
as you know.[***]
[***] Though I, personally, would be interested to see other
languages' solutions *if* you could do such things easier with
some specific other language; this would then has a drift to a
comparison of "C" design with other languages' designs, which
I'd then perceive as an interesting topical question.[****]
[****] But for *that* your language would not qualify because,
as you said, it can be "trivially converted to C".
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-03-04 08:48 +0100 |
| Message-ID | <10o8o59$2nju7$1@dont-email.me> |
| In reply to | #396743 |
On 03/03/2026 22:47, Janis Papanagnou wrote:
> On 2026-03-03 21:48, Bart wrote:
>> On 03/03/2026 05:15, Tim Rentsch wrote:
>>> [...]
>>
>> This kind of challenge can be done in any language. My algorithm
>> can be trivially converted to C if needed; it is clear enough.
>
> Sure. But let's have a closer look...
>
> It's debatable whether the algorithm is the challenge or whether
> writing actual "C" code is the challenge, say, because "C" may
> be so convoluted or just inappropriate for such tasks that it's
> difficult to solve such challenges with the "C" language. - But
> obviously this challenge is not challenging the "C" language in
> any way; it's an ordinary ("C", or other) programming task.[*]
> So I basically agree with you.[**]
>
> Though, with the subsequent refinements, to abstain from certain
> types of language constructs, i.e. programming with one arm tied
> behind your back, the question is not as clearly to answer; it's
> just easier to compare the various variants and code evolutions
> if you have a common language base (and here in CLC that's "C").
>
The original challenge is a C coding challenge, because it is posted in
a C language group. But it seems entirely reasonable to code it first
in a different language to get a feel for it, and see what the output
is. After all, if you were to ask regulars in this group to write code
for this task without any restrictions on the language, a fair
proportion would reach for languages other than C (I'd expect mostly
Python, but some C++ and some other languages).
As for the later challenges, these are not C programming challenges.
There are just a set of arbitrary silly limitations. A C coding
challenge asks for C code, and any restrictions should come from the C
world. For example, you could ban the use of dynamic memory because
some C programming environments ban that. You could ban recursive
functions, because some C programming environments ban that. Ban "for"
and "while", and you are not programming in C. If people find that sort
of thing fun, that's fine - but don't expect anyone else to be impressed
by it.
In light of this, Tim's reply to Bart is not only childish, petty and
unhelpful, but it was also hypocritical. He is no longer talking about
programming in C himself.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-03-04 01:07 -0800 |
| Message-ID | <87wlzsj73t.fsf@example.invalid> |
| In reply to | #396749 |
David Brown <david.brown@hesbynett.no> writes:
> On 03/03/2026 22:47, Janis Papanagnou wrote:
>> On 2026-03-03 21:48, Bart wrote:
>>> On 03/03/2026 05:15, Tim Rentsch wrote:
>>>> [...]
>>>
>>> This kind of challenge can be done in any language. My algorithm
>>> can be trivially converted to C if needed; it is clear enough.
>> Sure. But let's have a closer look...
>> It's debatable whether the algorithm is the challenge or whether
>> writing actual "C" code is the challenge, say, because "C" may
>> be so convoluted or just inappropriate for such tasks that it's
>> difficult to solve such challenges with the "C" language. - But
>> obviously this challenge is not challenging the "C" language in
>> any way; it's an ordinary ("C", or other) programming task.[*]
>> So I basically agree with you.[**]
>> Though, with the subsequent refinements, to abstain from certain
>> types of language constructs, i.e. programming with one arm tied
>> behind your back, the question is not as clearly to answer; it's
>> just easier to compare the various variants and code evolutions
>> if you have a common language base (and here in CLC that's "C").
>
> The original challenge is a C coding challenge, because it is posted
> in a C language group. But it seems entirely reasonable to code it
> first in a different language to get a feel for it, and see what the
> output is. After all, if you were to ask regulars in this group to
> write code for this task without any restrictions on the language, a
> fair proportion would reach for languages other than C (I'd expect
> mostly Python, but some C++ and some other languages).
>
> As for the later challenges, these are not C programming
> challenges. There are just a set of arbitrary silly limitations. A C
> coding challenge asks for C code, and any restrictions should come
> from the C world. For example, you could ban the use of dynamic
> memory because some C programming environments ban that. You could
> ban recursive functions, because some C programming environments ban
> that. Ban "for" and "while", and you are not programming in C. If
> people find that sort of thing fun, that's fine - but don't expect
> anyone else to be impressed by it.
>
> In light of this, Tim's reply to Bart is not only childish, petty and
> unhelpful, but it was also hypocritical. He is no longer talking
> about programming in C himself.
I disagree. Banning "for" and "while" is an arbitrary restriction,
but a C program with no "for" or "while" is still a C program.
If you're not interested in such a challenge, perhaps because
you think the restriction is silly, that's fine, but this is still
comp.lang.c. Showing how to accomplish something in C without "for"
and "while" may or may not be of interest to you, but it's topical.
Posting a solution in C++ or some other language, with or without
"for" and "while", would be inappropriate. (Starting with some
other language, treating it as pseudo-code, and then translating
the solution to C might be appropriate, but I don't think anyone
here has done that.)
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-03-04 12:09 +0200 |
| Message-ID | <20260304120922.00003310@yahoo.com> |
| In reply to | #396750 |
On Wed, 04 Mar 2026 01:07:18 -0800
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> David Brown <david.brown@hesbynett.no> writes:
> > On 03/03/2026 22:47, Janis Papanagnou wrote:
> >> On 2026-03-03 21:48, Bart wrote:
> >>> On 03/03/2026 05:15, Tim Rentsch wrote:
> >>>> [...]
> >>>
> >>> This kind of challenge can be done in any language. My algorithm
> >>> can be trivially converted to C if needed; it is clear enough.
> >> Sure. But let's have a closer look...
> >> It's debatable whether the algorithm is the challenge or whether
> >> writing actual "C" code is the challenge, say, because "C" may
> >> be so convoluted or just inappropriate for such tasks that it's
> >> difficult to solve such challenges with the "C" language. - But
> >> obviously this challenge is not challenging the "C" language in
> >> any way; it's an ordinary ("C", or other) programming task.[*]
> >> So I basically agree with you.[**]
> >> Though, with the subsequent refinements, to abstain from certain
> >> types of language constructs, i.e. programming with one arm tied
> >> behind your back, the question is not as clearly to answer; it's
> >> just easier to compare the various variants and code evolutions
> >> if you have a common language base (and here in CLC that's "C").
> >
> > The original challenge is a C coding challenge, because it is posted
> > in a C language group. But it seems entirely reasonable to code it
> > first in a different language to get a feel for it, and see what the
> > output is. After all, if you were to ask regulars in this group to
> > write code for this task without any restrictions on the language, a
> > fair proportion would reach for languages other than C (I'd expect
> > mostly Python, but some C++ and some other languages).
> >
> > As for the later challenges, these are not C programming
> > challenges. There are just a set of arbitrary silly limitations. A
> > C coding challenge asks for C code, and any restrictions should come
> > from the C world. For example, you could ban the use of dynamic
> > memory because some C programming environments ban that. You could
> > ban recursive functions, because some C programming environments ban
> > that. Ban "for" and "while", and you are not programming in C. If
> > people find that sort of thing fun, that's fine - but don't expect
> > anyone else to be impressed by it.
> >
> > In light of this, Tim's reply to Bart is not only childish, petty
> > and unhelpful, but it was also hypocritical. He is no longer
> > talking about programming in C himself.
>
> I disagree. Banning "for" and "while" is an arbitrary restriction,
> but a C program with no "for" or "while" is still a C program.
>
> If you're not interested in such a challenge, perhaps because
> you think the restriction is silly, that's fine, but this is still
> comp.lang.c. Showing how to accomplish something in C without "for"
> and "while" may or may not be of interest to you, but it's topical.
> Posting a solution in C++ or some other language, with or without
> "for" and "while", would be inappropriate.
Actually, I would not mind demonstration of how it can be done in C++
if it presents a novel way of implementing control flow that is not
available in C. Some jucy trick with lambdas or co-routines. May be,
even with templates, but I don't believe that templates could be of
help.
Thinking few seconds about it, even in "old" C++ there is one control
flow tool that is up to the task. I didn't figure it out immediatly
beacuse I happen to hate this construct.
Of course, Bonita's attempt was nothing of that sort. It was yet
another boring demonstration of inferiority of C++ iostream formatted
output.
Other than that it was written in C subset of C++.
> (Starting with some
> other language, treating it as pseudo-code, and then translating
> the solution to C might be appropriate, but I don't think anyone
> here has done that.)
>
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-03-04 11:19 -0800 |
| Message-ID | <87seafjtbs.fsf@example.invalid> |
| In reply to | #396752 |
Michael S <already5chosen@yahoo.com> writes:
[...]
> Actually, I would not mind demonstration of how it can be done in C++
[...]
Of course I have no problem with that. If you want comp.lang.c++, you
know where to find it.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-03-04 12:58 +0100 |
| Message-ID | <10o96po$2sa9l$1@dont-email.me> |
| In reply to | #396750 |
On 04/03/2026 10:07, Keith Thompson wrote: > David Brown <david.brown@hesbynett.no> writes: <snip> >> >> As for the later challenges, these are not C programming >> challenges. There are just a set of arbitrary silly limitations. A C >> coding challenge asks for C code, and any restrictions should come >> from the C world. For example, you could ban the use of dynamic >> memory because some C programming environments ban that. You could >> ban recursive functions, because some C programming environments ban >> that. Ban "for" and "while", and you are not programming in C. If >> people find that sort of thing fun, that's fine - but don't expect >> anyone else to be impressed by it. > > I disagree. Banning "for" and "while" is an arbitrary restriction, > but a C program with no "for" or "while" is still a C program. > > If you're not interested in such a challenge, perhaps because > you think the restriction is silly, that's fine, but this is still > comp.lang.c. Showing how to accomplish something in C without "for" > and "while" may or may not be of interest to you, but it's topical. > Posting a solution in C++ or some other language, with or without > "for" and "while", would be inappropriate. (Starting with some > other language, treating it as pseudo-code, and then translating > the solution to C might be appropriate, but I don't think anyone > here has done that.) > I have no problem with the thread here in comp.lang.c, and no problem with people being interested in the challenge. But I don't think it is reasonable to call it "writing C code". I would not like to draw a line and declare that omitting this or that particular feature means the code no longer resembles code written in normal C. However, remove enough features and it becomes clear - once people are using "longjmp" instead of basic C control flow statements, it's not C any more even if a C compiler can handle it. I do agree that posting code in other languages is normally off-topic for the group - though sometimes it makes sense for comparison to C.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2026-03-11 11:31 +0100 |
| Message-ID | <10org9h$10om3$1@raubtier-asyl.eternal-september.org> |
| In reply to | #396754 |
Am 04.03.2026 um 12:58 schrieb David Brown:
> I do agree that posting code in other languages is normally off-topic
> for the group - though sometimes it makes sense for comparison to C.
A comparison with a language derived from C is half on-topic.
I think my style is pure beauty:
#include <iostream>
#include <sstream>
#include <iomanip>
#include <optional>
#include <algorithm>
using namespace std;
static optional<size_t> parse( const char *str );
int main( int argc, char **argv )
{
if( argc < 3 )
return EXIT_FAILURE;
optional<size_t>
pRows = parse( argv[1] ),
pCols = parse( argv[2] );
if( !pRows || !pCols )
return EXIT_FAILURE;
size_t rows = *pRows, cols = *pCols;
optional<size_t> pClip( rows * cols );
if( argc >= 4 && !(pClip = parse( argv[3] )) )
return EXIT_FAILURE;
size_t clip = min( *pClip, rows * cols );
streamsize width = (ostringstream() << clip).str().length();
for( size_t row = 0; row < min( rows, clip ); ++row )
{
bool head = true;
for( size_t value = row; value < clip; value += rows, head = false )
cout << " "sv.substr( head, !head ) << right << setw( width ) <<
value + 1;
cout << endl;
}
}
static optional<size_t> parse( const char *str )
{
istringstream iss( str );
size_t ret;
iss >> ret;
if( !iss || !iss.eof() )
return nullopt;
return ret;
}
I think C-code is somewhat longer with the same error handling features.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-03-04 13:20 +0000 |
| Message-ID | <10o9bj2$2tpgn$1@dont-email.me> |
| In reply to | #396743 |
On 03/03/2026 21:47, Janis Papanagnou wrote:
> On 2026-03-03 21:48, Bart wrote:
>> On 03/03/2026 05:15, Tim Rentsch wrote:
>>> [...]
>>
>> This kind of challenge can be done in any language. My algorithm
>> can be trivially converted to C if needed; it is clear enough.
>
> Sure. But let's have a closer look...
>
> It's debatable whether the algorithm is the challenge or whether
> writing actual "C" code is the challenge, say, because "C" may
> be so convoluted or just inappropriate for such tasks that it's
> difficult to solve such challenges with the "C" language. - But
> obviously this challenge is not challenging the "C" language in
> any way; it's an ordinary ("C", or other) programming task.[*]
> So I basically agree with you.[**]
>
> Though, with the subsequent refinements, to abstain from certain
> types of language constructs, i.e. programming with one arm tied
> behind your back, the question is not as clearly to answer; it's
> just easier to compare the various variants and code evolutions
> if you have a common language base (and here in CLC that's "C").
>
> Janis
>
>> [...]
>
> [*] A task that other folks might have solved by using existing
> tools instead of explicit and longish error-prone programming.
>
> [**] Not everyone here might appreciate code in other languages
> as you know.[***]
>
> [***] Though I, personally, would be interested to see other
> languages' solutions *if* you could do such things easier with
> some specific other language; this would then has a drift to a
> comparison of "C" design with other languages' designs, which
> I'd then perceive as an interesting topical question.[****]
The other, possibly 'easier' language doesn't have to use a clever
approach. In fact, too clever and it becomes harder to write, understand
or port.
The softer language in this case didn't need these distractions needed by C:
* #include lines
* Variable declarations /and/ types
* Semicolons
* Long-winded for-loop headers
* Various extra parentheses around conditions and so on
* Even needing to create a 'main' routine
* And, being run from source, no compile/link step for each
edit-run cycle
These would all impact productivity and be a distraction.
Once the program /is/ working, then the above is less of an imposition,
since you only need to worry about all that once.
> [****] But for *that* your language would not qualify because,
> as you said, it can be "trivially converted to C".
Let's say 'mechanically'. There's one detail with the dynamic width of
each column which I'm not sure about, but I will start now:
Ok, 8-9 minutes later, I got the C version shown below. I'm a poor
typist and all that extra punctiation is troublesome. The width thing
was easier than I expected.
-------------------------------------
#include <stdio.h>
#include <string.h>
int getrows(int n) {
int m=1, s=1;
while (s<n) {++m; s=m*m;}
return m;
}
void solve(int n) {
int rows, cols, size, i, width;
char str[16];
rows=cols=getrows(n);
size=rows*cols;
printf("input = %d\n", n);
if ((size-n)>=rows) {
printf("not possible to output 1-%d where rows=columns\n", n);
return;
}
width=sprintf(str,"%d", n);
for (int r=1; r<=rows; ++r) {
i=r;
for (int c=1; c<=cols; ++c) {
printf(" %*d", width, i);
i+=rows;
}
puts("");
}
puts("");
}
int main() {
for (int n=1; n<=27; ++n)
solve(n);
}
[toc] | [prev] | [next] | [standalone]
| From | DFS <nospam@dfs.com> |
|---|---|
| Date | 2026-03-04 08:30 -0500 |
| Message-ID | <10o9c5p$2ul3p$2@dont-email.me> |
| In reply to | #396742 |
On 3/3/2026 3:48 PM, Bart wrote: > On 03/03/2026 05:15, Tim Rentsch wrote: >> I see no reason to answer your questions since you seem to have >> no interest in writing C code. > > This kind of challenge can be done in any language. My algorithm can be > trivially converted to C if needed; it is clear enough. > > Anwway, when I submitted my version, the last post in the thread was by > the OP, and it contained some Python code. So likely some here might > also be prototyping in a soft language first. I never posted any python code in this thread.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-03-04 14:36 +0000 |
| Message-ID | <10o9g1b$303he$1@dont-email.me> |
| In reply to | #396757 |
On 04/03/2026 13:30, DFS wrote: > On 3/3/2026 3:48 PM, Bart wrote: >> On 03/03/2026 05:15, Tim Rentsch wrote: > > >>> I see no reason to answer your questions since you seem to have >> no >>> interest in writing C code. >> >> This kind of challenge can be done in any language. My algorithm can >> be trivially converted to C if needed; it is clear enough. >> >> Anwway, when I submitted my version, the last post in the thread was >> by the OP, and it contained some Python code. So likely some here >> might also be prototyping in a soft language first. > > > I never posted any python code in this thread. I was refering to this: On 26/02/2026 19:31, DFS wrote: > incredible. > > I spent at least 20 minutes just trying to make nested loops work: > > for i in range(rows): > for j in range(cols): > > I was trapped in my mind by the idea the code had to start like that, > with consecutive loops statements.
[toc] | [prev] | [next] | [standalone]
| From | DFS <nospam@dfs.com> |
|---|---|
| Date | 2026-03-04 10:02 -0500 |
| Message-ID | <10o9hh8$3077t$2@dont-email.me> |
| In reply to | #396758 |
On 3/4/2026 9:36 AM, Bart wrote: > On 04/03/2026 13:30, DFS wrote: >> On 3/3/2026 3:48 PM, Bart wrote: >>> On 03/03/2026 05:15, Tim Rentsch wrote: >> >> >>>> I see no reason to answer your questions since you seem to have >> >>>> no interest in writing C code. >>> >>> This kind of challenge can be done in any language. My algorithm can >>> be trivially converted to C if needed; it is clear enough. >>> >>> Anwway, when I submitted my version, the last post in the thread was >>> by the OP, and it contained some Python code. So likely some here >>> might also be prototyping in a soft language first. >> >> >> I never posted any python code in this thread. > > I was refering to this: > > On 26/02/2026 19:31, DFS wrote: > > > incredible. > > > > I spent at least 20 minutes just trying to make nested loops work: > > > > for i in range(rows): > > for j in range(cols): > > > > I was trapped in my mind by the idea the code had to start like that, > > with consecutive loops statements. OK, sorry. But that wasn't the last post in the thread before you submitted yours. That was 3 posts prior. I did write this 'challenge' in python first, so I could print various lists in alphabetical order by column then row. To my eye, printing sequential numbers or names by column-row looks better than by row-column.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-03-04 19:27 +0200 |
| Message-ID | <20260304192711.00003795@yahoo.com> |
| In reply to | #396760 |
On Wed, 4 Mar 2026 10:02:02 -0500 DFS <nospam@dfs.com> wrote: > > To my eye, printing sequential numbers or names by column-row looks > better than by row-column. > Were you programming in Fortran in your youth?
[toc] | [prev] | [next] | [standalone]
| From | DFS <nospam@dfs.com> |
|---|---|
| Date | 2026-03-05 13:49 -0500 |
| Message-ID | <10ocj7i$1ke5$2@dont-email.me> |
| In reply to | #396764 |
On 3/4/2026 12:27 PM, Michael S wrote:
> On Wed, 4 Mar 2026 10:02:02 -0500
> DFS <nospam@dfs.com> wrote:
>
>>
>> To my eye, printing sequential numbers or names by column-row looks
>> better than by row-column.
>>
>
> Were you programming in Fortran in your youth?
Nah. Never looked at it.
Is column-row output an option in Fortran?
I programmed internal business software my entire IT career.
Lotus-1-2-3 macros
dBase, clipper and Paradox (DOS)
ObjectPAL (an offshoot of Delphi used in Borland Paradox for Windows
desktop database)
small amts of Rexx and perl and Java
T-SQL and Oracle PL/SQL
tons of VB and VBA
hobby coding
PowerBuilder
first C program May 2014
first Python early 2016
I like C for raw performance and strictness of code.
I like python for ease of use and productivity.
Where else but Python can you get meaningful Usenet stats in 22 lines?
-------------------------------------------------------
import sys as y,nntplib as t
s='news server'
g='comp.lang.c'
n=t.NNTP(s,119,'usr','pw')
r,a,b,e,gn=n.group(g)
def printStat(st,hd,rg):
r,d=n.xhdr(st,'%s-%s'%rg)
p=[]
for i in range(len(d)):
v=d[i][1]
if st=='Subject': v=v[4:] if v[:3]=='Re:' else v
p.append(v)
x=[(i,p.count(i)) for i in set(p)]
x.sort(key=lambda s:(-s[1],s[0].lower()))
print('Posts %s %s'%(len(set(p)),hd))
for v in x: print(' %s %s'%(v[1],v[0]))
print()
print("Last " + y.argv[1] + " Posts")
m=(int(e)-int(y.argv[1])+1,int(e))
printStat("From","Posters",m)
printStat("Subject","Subjects",m)
n.quit()
-------------------------------------------------------
$ python program.py N
(ignore the nntp deprecation warning - someone at Python thinks Usenet
is dead. Long live Usenet.)
[toc] | [prev] | [next] | [standalone]
Page 2 of 11 — ← Prev page 1 [2] 3 4 … 11 Next page →
Back to top | Article view | comp.lang.c
csiph-web