Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #401667 > unrolled thread
| Started by | fir <profesor.fir@gmail.com> |
|---|---|
| First post | 2026-09-06 15:45 +0200 |
| Last post | 2026-10-05 04:32 +0200 |
| Articles | 20 on this page of 496 — 24 participants |
Back to article view | Back to comp.lang.c
Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-06 15:45 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-06 15:52 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-06 16:52 +0100
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-06 21:41 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-07 09:37 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-07 11:35 +0100
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-07 13:15 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-07 13:55 +0100
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-07 15:24 +0200
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-07 15:33 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-07 16:34 +0100
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-08 00:50 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-08 00:35 +0100
Re: Official list of top C annoyances Lane W <cactus_DAC@yahoo.com> - 2026-09-07 17:43 -0600
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-07 16:52 -0700
Re: Official list of top C annoyances Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-09-09 15:24 +0800
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-09 10:18 +0200
Re: Official list of top C annoyances Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-09-09 20:16 +0800
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-09 14:31 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-09 14:37 +0200
Re: Official list of top C annoyances Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-09-09 21:37 +0800
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-18 09:38 +0200
Re: Official list of top C annoyances Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-09-18 17:42 +0800
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-08 03:11 +0200
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-08 16:40 +0000
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-08 20:08 +0100
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-09 09:35 +0200
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-09 10:18 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-09 12:32 +0100
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-09 14:30 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-09 15:09 +0100
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-09 16:58 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-09 18:34 +0100
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-09 18:37 +0000
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-09 20:12 +0100
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-09 22:11 +0200
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-09 21:15 +0000
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-09 23:37 +0200
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-09 21:39 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-09 21:39 +0100
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-10 09:07 +0200
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-09 14:41 -0700
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-09 23:31 +0100
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-09 15:10 +0000
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-08 09:25 +0200
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-09 09:59 +0200
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-09 10:35 +0200
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-09 11:35 +0200
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-09 14:43 +0200
Re: Official list of top C annoyances "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-09-10 14:08 -0700
Re: Official list of top C annoyances "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-09-10 14:14 -0700
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-11 09:16 +0200
Re: Official list of top C annoyances Kaz Kylheku <046-301-5902@kylheku.com> - 2026-09-14 19:14 +0000
Re: Official list of top C annoyances Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-09-18 08:29 -0700
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-09 02:45 -0700
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-09 15:07 +0200
Re: Official list of top C annoyances Lane W <cactus_DAC@yahoo.com> - 2026-09-09 07:14 -0600
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-09 15:31 +0200
Re: Official list of top C annoyances Lane W <cactus_DAC@yahoo.com> - 2026-09-09 07:41 -0600
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-09 15:58 +0200
Re: Official list of top C annoyances Lane W <cactus_DAC@yahoo.com> - 2026-09-09 08:05 -0600
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-09 16:13 +0200
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-09 16:29 -0700
Re: Official list of top C annoyances "Johann \"Myrkraverk\" Oskarsson" <johann@myrkraverk.invalid> - 2026-09-18 10:23 +0800
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-09 16:10 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-09 16:19 +0200
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-09 17:02 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-09 15:11 +0100
Re: Official list of top C annoyances Lane W <cactus_DAC@yahoo.com> - 2026-09-09 08:25 -0600
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-09 15:53 +0100
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-09 17:42 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-09 17:53 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-09 18:03 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-09 18:19 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-09 18:49 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-09 19:16 +0200
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-09 15:48 +0000
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-09 18:38 +0100
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-10 09:11 +0200
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-09 15:04 +0000
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-09 17:12 +0200
Re: Official list of top C annoyances "Johann \"Myrkraverk\" Oskarsson" <johann@myrkraverk.invalid> - 2026-09-09 23:59 +0800
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-09 15:30 -0700
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-10 06:50 +0200
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-09 15:13 -0700
Re: Official list of top C annoyances Richard Harnden <richard.nospam@gmail.invalid> - 2026-09-09 15:16 +0100
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-09 15:43 -0700
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-10 07:16 +0200
Re: Official list of top C annoyances antispam@fricas.org (Waldek Hebisch) - 2026-09-08 00:02 +0000
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-08 12:47 +0100
Re: Official list of top C annoyances antispam@fricas.org (Waldek Hebisch) - 2026-09-09 01:59 +0000
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-09 10:26 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-09 19:12 +0100
Re: Official list of top C annoyances tTh <tth@none.invalid> - 2026-09-09 21:01 +0200
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-09 21:45 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-09 21:18 +0100
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-10 09:32 +0200
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-09 23:26 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-09 23:30 +0100
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-10 08:45 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-10 13:09 +0100
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-10 14:37 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-10 15:11 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-10 15:16 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-10 15:28 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-10 14:33 +0100
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-10 15:51 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-10 16:03 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-10 15:27 +0100
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-10 16:45 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-10 16:59 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-10 16:57 +0100
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-10 18:18 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-11 01:04 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-10 16:47 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-10 16:54 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-10 17:06 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-10 17:15 +0200
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-10 18:10 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-10 18:21 +0200
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-10 18:45 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-10 18:56 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-10 19:01 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-10 19:20 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-10 20:19 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-10 20:25 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-10 19:17 +0200
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-11 09:21 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-11 12:46 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-11 14:13 +0200
Re: Official list of top C annoyances Richard Harnden <richard.nospam@gmail.invalid> - 2026-09-11 13:41 +0100
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-11 14:55 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-11 15:01 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-11 15:04 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-11 15:08 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-11 15:13 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-11 15:17 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-10 21:02 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-10 21:59 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-10 16:41 +0200
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-10 09:48 +0200
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-11 00:06 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-10 23:48 +0100
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-10 15:52 -0700
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-11 00:48 +0100
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-10 17:11 -0700
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-12 08:01 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-12 08:20 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-12 09:09 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-12 12:35 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-12 12:40 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-12 11:55 +0100
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-12 14:37 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-12 14:49 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-12 15:00 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-12 14:24 +0100
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-12 15:44 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-12 15:53 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-12 16:05 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-12 16:16 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-12 17:20 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-12 17:08 +0100
Re: Official list of top C annoyances Lane W <cactus_DAC@yahoo.com> - 2026-09-12 10:53 -0600
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-12 19:23 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-12 18:58 +0100
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-12 20:35 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-12 20:46 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-12 20:49 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-12 22:16 +0100
Re: Official list of top C annoyances Lane W <cactus_DAC@yahoo.com> - 2026-09-12 15:40 -0600
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-13 10:15 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-13 10:27 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-13 10:39 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-13 10:30 +0100
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-13 11:47 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-13 11:53 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-13 11:26 +0100
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-13 12:37 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-13 12:47 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-13 12:55 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-13 13:11 +0200
Re: Official list of top C annoyances Lane W <cactus_DAC@yahoo.com> - 2026-09-13 05:29 -0600
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-13 13:43 +0200
Re: Official list of top C annoyances "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-09-13 14:00 -0700
Re: Official list of top C annoyances Ike Naar <ike@sdf.org> - 2026-09-13 10:53 +0000
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-13 13:46 +0100
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-13 15:21 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-13 15:31 +0100
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-13 16:34 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-13 16:58 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-13 18:01 +0100
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-13 21:14 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-13 17:17 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-13 17:23 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-13 17:27 +0200
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-13 17:06 -0700
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-14 15:01 +0000
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-14 18:11 +0200
Re: Official list of top C annoyances tTh <tth@none.invalid> - 2026-09-14 20:21 +0200
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-14 22:54 +0200
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-14 23:56 +0200
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-15 09:07 +0200
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-15 09:41 +0200
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-15 10:22 +0200
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-15 11:51 +0200
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-15 12:53 +0200
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-18 09:10 +0200
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-18 11:37 +0200
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-19 09:03 +0200
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-19 13:01 +0200
Re: Official list of top C annoyances Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-05 01:57 +0000
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-14 18:54 +0000
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-14 22:55 +0200
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-14 21:03 +0000
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-15 00:33 +0200
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-13 10:50 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-13 12:32 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-12 20:15 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-12 19:34 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-12 19:39 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-12 15:23 +0200
Re: Official list of top C annoyances Lane W <cactus_DAC@yahoo.com> - 2026-09-12 07:45 -0600
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-11 00:37 +0100
Re: Official list of top C annoyances antispam@fricas.org (Waldek Hebisch) - 2026-09-13 18:55 +0000
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-14 01:44 +0100
Re: Official list of top C annoyances antispam@fricas.org (Waldek Hebisch) - 2026-09-14 07:41 +0000
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-14 14:01 +0100
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-14 14:09 +0100
Re: Official list of top C annoyances antispam@fricas.org (Waldek Hebisch) - 2026-09-15 02:42 +0000
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-14 23:41 +0100
Re: Official list of top C annoyances antispam@fricas.org (Waldek Hebisch) - 2026-09-15 01:48 +0000
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-15 07:39 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-15 11:28 +0100
Re: Official list of top C annoyances antispam@fricas.org (Waldek Hebisch) - 2026-09-15 14:54 +0000
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-15 21:56 +0100
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-15 21:34 +0000
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-16 00:36 +0100
Re: Official list of top C annoyances antispam@fricas.org (Waldek Hebisch) - 2026-09-16 02:21 +0000
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-16 09:08 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-16 11:21 +0100
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-16 13:47 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-16 15:20 +0100
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-16 17:53 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-17 00:36 +0100
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-16 16:59 -0700
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-17 01:49 +0100
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-16 19:43 -0700
Re: Official list of top C annoyances tTh <tth@none.invalid> - 2026-09-17 09:24 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-17 11:29 +0100
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-17 15:06 -0700
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-18 02:04 +0100
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-17 18:19 -0700
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-18 11:27 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-18 11:21 +0100
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-18 13:17 +0200
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-18 15:44 +0000
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-19 09:16 +0200
Re: Official list of top C annoyances cross@spitfire.i.gajendra.net (Dan Cross) - 2026-09-18 12:55 +0000
Re: Official list of top C annoyances Michael S <already5chosen@yahoo.com> - 2026-09-18 17:53 +0300
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-18 15:47 +0000
Re: Official list of top C annoyances Michael S <already5chosen@yahoo.com> - 2026-09-19 21:22 +0300
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-20 15:58 +0000
Re: Official list of top C annoyances Michael S <already5chosen@yahoo.com> - 2026-09-21 21:06 +0300
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-22 15:04 +0000
Re: Official list of top C annoyances Michael S <already5chosen@yahoo.com> - 2026-09-22 21:07 +0300
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-18 15:41 +0000
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-18 11:34 -0700
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-17 12:52 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-17 13:15 +0100
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-17 15:16 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-17 15:25 +0100
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-17 17:05 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-17 16:46 +0100
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-17 20:22 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-17 20:19 +0100
Re: Official list of top C annoyances tTh <tth@none.invalid> - 2026-09-17 21:55 +0200
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-17 23:47 +0000
Re: Official list of top C annoyances tTh <tth@none.invalid> - 2026-09-17 21:31 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-17 20:54 +0100
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-17 15:44 -0700
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-17 23:48 +0000
Re: Official list of top C annoyances "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> - 2026-09-18 00:04 +0000
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-18 01:34 +0100
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-17 17:50 -0700
Re: Official list of top C annoyances Michael S <already5chosen@yahoo.com> - 2026-09-18 17:45 +0300
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-18 15:28 +0000
Re: Official list of top C annoyances Michael S <already5chosen@yahoo.com> - 2026-09-18 18:34 +0300
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-18 18:08 +0200
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-18 11:26 -0700
Re: Official list of top C annoyances gazelle@shell.xmission.com (Kenny McCormack) - 2026-09-18 20:39 +0000
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-19 13:10 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-19 13:20 +0100
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-19 17:30 +0200
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-19 09:38 +0200
Re: Official list of top C annoyances Michael S <already5chosen@yahoo.com> - 2026-09-19 21:00 +0300
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-20 10:17 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-20 11:29 +0100
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-20 12:52 +0100
Re: Official list of top C annoyances antispam@fricas.org (Waldek Hebisch) - 2026-10-06 01:06 +0000
Re: Official list of top C annoyances "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-09-20 15:58 -0700
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-20 15:55 +0000
Re: Official list of top C annoyances Michael S <already5chosen@yahoo.com> - 2026-09-21 20:41 +0300
Re: Official list of top C annoyances Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-09-22 01:53 +0800
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-22 11:28 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-22 11:34 +0100
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-22 15:00 +0000
Re: Official list of top C annoyances Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2026-09-22 14:22 +0000
Re: Official list of top C annoyances Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2026-09-22 15:04 +0000
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-22 16:38 +0000
Re: Official list of top C annoyances Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-30 02:28 +0000
Re: Official list of top C annoyances antispam@fricas.org (Waldek Hebisch) - 2026-10-06 01:29 +0000
Re: Official list of top C annoyances Michael S <already5chosen@yahoo.com> - 2026-09-19 22:01 +0300
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-18 20:28 +0000
Re: Official list of top C annoyances "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> - 2026-09-18 05:42 +0000
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-18 08:08 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-18 10:23 +0100
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-18 15:24 +0000
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-18 16:31 +0100
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-18 11:29 -0700
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-18 20:14 +0100
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-18 12:42 -0700
Re: Official list of top C annoyances Jim Jackson <jj@franjam.org.uk> - 2026-09-19 13:39 +0000
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-19 16:24 +0100
Re: Official list of top C annoyances "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> - 2026-09-19 00:19 +0000
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-19 02:06 +0100
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-18 20:20 -0700
Re: Official list of top C annoyances "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> - 2026-09-19 03:26 +0000
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-19 09:56 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-19 11:08 +0100
Re: Official list of top C annoyances tTh <tth@none.invalid> - 2026-09-19 13:25 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-19 10:45 +0100
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-19 15:09 +0000
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-19 16:17 +0100
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-19 09:45 +0200
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-18 13:11 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-18 14:03 +0100
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-18 17:24 +0200
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-18 11:06 -0700
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-18 20:07 +0100
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-18 12:26 -0700
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-18 22:57 +0100
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-19 17:27 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-19 20:09 +0100
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-20 12:31 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-20 12:42 +0100
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-20 15:08 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-20 14:22 +0100
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-20 14:54 +0100
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-20 23:24 +0200
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-21 15:06 +0000
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-21 16:36 +0100
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-21 17:45 +0200
Re: Official list of top C annoyances Michael S <already5chosen@yahoo.com> - 2026-09-21 20:54 +0300
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-22 15:02 +0000
Re: Official list of top C annoyances Michael S <already5chosen@yahoo.com> - 2026-09-22 21:02 +0300
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-20 15:58 +0200
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-20 15:19 -0700
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-20 23:49 +0100
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-20 16:17 -0700
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-20 15:49 +0000
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-20 15:18 -0700
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-20 15:41 +0000
Re: Official list of top C annoyances tTh <tth@none.invalid> - 2026-09-17 21:53 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-17 21:05 +0100
Re: Official list of top C annoyances antispam@fricas.org (Waldek Hebisch) - 2026-09-17 14:38 +0000
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-17 17:15 +0200
Re: Official list of top C annoyances antispam@fricas.org (Waldek Hebisch) - 2026-09-17 16:33 +0000
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-17 20:26 +0200
Re: Official list of top C annoyances "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-09-17 13:26 -0700
Re: Official list of top C annoyances "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-09-17 13:25 -0700
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-17 12:36 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-17 13:03 +0100
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-17 14:51 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-17 14:32 +0100
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-17 15:17 -0700
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-17 15:24 -0700
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-18 09:06 +0200
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-18 02:08 -0700
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-18 11:01 +0100
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-18 03:05 -0700
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-18 11:13 +0100
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-16 17:33 +0000
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-16 19:19 +0100
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-16 18:34 +0000
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-16 20:21 +0100
Re: Official list of top C annoyances antispam@fricas.org (Waldek Hebisch) - 2026-09-16 13:16 +0000
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-16 15:26 +0100
Re: Official list of top C annoyances antispam@fricas.org (Waldek Hebisch) - 2026-09-16 15:58 +0000
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-16 19:13 +0100
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-16 18:30 +0000
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-16 20:30 +0100
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-16 21:16 +0100
Re: Official list of top C annoyances antispam@fricas.org (Waldek Hebisch) - 2026-09-17 02:56 +0000
Re: Official list of top C annoyances Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-30 02:32 +0000
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-29 19:58 -0700
Re: Official list of top C annoyances Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-05 02:15 +0000
Re: Official list of top C annoyances Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-29 03:22 +0000
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-14 09:49 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-14 11:27 +0100
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-14 16:03 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-14 16:15 +0200
Re: Official list of top C annoyances Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-22 23:27 +0000
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-23 01:01 +0100
Re: Official list of top C annoyances Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-23 23:38 +0000
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-24 02:00 +0100
Re: Official list of top C annoyances Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-24 02:41 +0000
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-23 20:23 -0700
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-24 11:27 +0100
Re: Official list of top C annoyances Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-24 23:54 +0000
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-25 01:23 +0100
Re: Official list of top C annoyances Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-25 03:47 +0000
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-25 11:38 +0100
Re: Official list of top C annoyances Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-26 02:49 +0000
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-26 11:44 +0100
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-26 14:03 +0100
Re: Official list of top C annoyances Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-28 00:05 +0000
Re: Official list of top C annoyances Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-29 00:56 +0000
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-29 14:27 +0100
Re: Official list of top C annoyances Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-30 02:02 +0000
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-30 11:18 +0100
Re: Official list of top C annoyances cross@spitfire.i.gajendra.net (Dan Cross) - 2026-09-30 13:37 +0000
Re: Official list of top C annoyances Michael S <already5chosen@yahoo.com> - 2026-09-30 17:17 +0300
Re: Official list of top C annoyances cross@spitfire.i.gajendra.net (Dan Cross) - 2026-09-30 14:39 +0000
Re: Official list of top C annoyances Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-30 22:39 +0000
Re: Official list of top C annoyances "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-01 15:23 -0700
Re: Official list of top C annoyances Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-02 02:38 +0000
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-10-02 09:17 +0200
Re: Official list of top C annoyances Michael S <already5chosen@yahoo.com> - 2026-09-25 12:17 +0300
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-25 11:31 +0100
Re: Official list of top C annoyances Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-26 02:34 +0000
Re: Official list of top C annoyances antispam@fricas.org (Waldek Hebisch) - 2026-09-24 08:50 +0000
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-24 11:31 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-24 11:29 +0100
Re: Official list of top C annoyances antispam@fricas.org (Waldek Hebisch) - 2026-09-25 21:09 +0000
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-26 11:59 +0100
Re: Official list of top C annoyances antispam@fricas.org (Waldek Hebisch) - 2026-09-29 04:06 +0000
Re: Official list of top C annoyances Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-29 04:47 +0000
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-29 23:49 +0100
Re: Official list of top C annoyances antispam@fricas.org (Waldek Hebisch) - 2026-09-30 12:19 +0000
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-09 10:13 +0200
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-09 10:38 +0200
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-09 11:40 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-09 12:05 +0200
Re: Official list of top C annoyances Richard Harnden <richard.nospam@gmail.invalid> - 2026-09-09 15:23 +0100
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-09 23:07 +0200
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-09 15:52 -0700
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-10 01:00 +0200
Re: Official list of top C annoyances "Johann \"Myrkraverk\" Oskarsson" <johann@myrkraverk.invalid> - 2026-09-18 10:17 +0800
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-18 09:29 +0200
Re: Official list of top C annoyances Jim Jackson <jj@franjam.org.uk> - 2026-09-19 13:46 +0000
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-25 09:15 +0200
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-10 06:16 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-10 14:38 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-10 18:35 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-10 18:36 +0200
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-10 10:11 +0200
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-11 00:48 +0200
Re: Official list of top C annoyances Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-29 03:18 +0000
Re: Official list of top C annoyances Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-09-18 12:58 -0700
Re: Official list of top C annoyances Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-22 23:21 +0000
Re: Official list of top C annoyances "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-09-08 12:47 -0700
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-07 15:20 +0200
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-07 09:53 +0200
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-07 23:59 +0200
Re: Official list of top C annoyances Lane W <cactus_DAC@yahoo.com> - 2026-09-07 16:04 -0600
Re: Official list of top C annoyances "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-09-07 04:06 -0700
Re: Official list of top C annoyances Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-09-07 20:05 +0800
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-07 15:32 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-08 12:59 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-08 13:09 +0200
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-08 14:15 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-08 14:35 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-08 14:49 +0200
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-08 16:05 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-08 16:18 +0200
Re: Official list of top C annoyances Lane W <cactus_DAC@yahoo.com> - 2026-09-08 09:45 -0600
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-08 20:41 +0200
Re: Official list of top C annoyances "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-09-08 12:39 -0700
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-08 15:55 -0700
Re: Official list of top C annoyances Lane W <cactus_DAC@yahoo.com> - 2026-09-08 18:02 -0600
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-08 17:39 -0700
Re: Official list of top C annoyances Lane W <cactus_DAC@yahoo.com> - 2026-09-08 18:47 -0600
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-08 18:19 -0700
Re: Official list of top C annoyances Lane W <cactus_DAC@yahoo.com> - 2026-09-08 19:24 -0600
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-08 19:26 -0700
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-09 03:25 +0200
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-09 09:13 +0200
Re: Official list of top C annoyances Lane W <cactus_DAC@yahoo.com> - 2026-09-09 07:38 -0600
Re: Official list of top C annoyances "Johann \"Myrkraverk\" Oskarsson" <johann@myrkraverk.invalid> - 2026-09-09 22:16 +0800
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-09 09:02 +0200
Re: Official list of top C annoyances Jan van den Broek <balglaas@dds.nl> - 2026-09-09 12:50 +0000
And then we reached C# (was Re: Official list of top C annoyances) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-09 08:51 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-08 14:54 +0100
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-08 16:10 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-25 14:22 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-10-05 04:32 +0200
Page 12 of 25 — ← Prev page 1 … 10 11 [12] 13 14 … 25 Next page →
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2026-09-12 15:23 +0200 |
| Message-ID | <1183jp6$3p7du$1@dont-email.me> |
| In reply to | #401986 |
bart pisze: > * Multiple function return values: (a, b) := f(x) i asked ai which languages get tis in which year and it says (note ai may be not fully reliable, but it may be treated as some date whose are not know if fully reliable but worth maybe lookin at ) Język Od kiedy mniej więcej Przykład CLU 1975 x, y := foo() Perl 1987 ($x, $y) = foo() Python 1991 x, y = foo() Lua 1993 x, y = foo() Ruby 1995 x, y = foo() Go 2009/2010 x, y := foo() Swift 2014 (x, y) = foo() JavaScript 2015 (ES6) [x, y] = foo() C# 2017 (C# 7) var (x, y) = foo() Rust 2015 dla destructuring let; 2022 dla assignment let (x, y) = foo() as i said back then i was starting lerning c afair 25 years ago maybe even exactly, - it was i remember like in a week thet was after WTC attack (so 25 years aggo exactly) - maybe 25 years form now maybe more on this story - in Toruń (whwre i was studying physics back then ) there was a chep books bookstore and i bought some old cheap book on "turbo c 2.0" (by bielinki?) i dont remember but has it still on my bookshelf - i literally was traveling in bus from toruń to my city when the radio in that bus give the news of WTC co its easy to memorize i alos remember i was not studying this book in toruń (i got no pc on my last place i rented i turuń (before we , me and my friend piotr, got some but we anly played adom on linuc there) so its sure i not learned it before wtc and i remember i was learning it quite afterwards this book was totally obsolete in 2001 but i find it very interesting as it covered C which before i got no idea on (only nknewed asembler, creepy basics and turbo pascel 7.0 or something) so when i was learnig c in this late 2001 thru 2002 and 2003 it was my begining (fortunate to remember in some way 2001 first year of knowing c and so on) so as to this above list I presently FOR MYSELF discovered that s should have it (returning 2 values ) was as i remember in 2003 (and i remember people back then didnt considered it as obvious) its maybe suprising perl and python had it so early but its also suprising javascript had it so late
[toc] | [prev] | [next] | [standalone]
| From | Lane W <cactus_DAC@yahoo.com> |
|---|---|
| Date | 2026-09-12 07:45 -0600 |
| Message-ID | <1183l1a$3pnnf$1@dont-email.me> |
| In reply to | #401986 |
bart wrote:
> On 12/09/2026 07:01, Janis Papanagnou wrote:
>>> bart <bc@freeuk.com> writes:
>>>
>>>> When you have to implement this stuff then you can't be sloppy.
>>
>> You demonstrated you can be extremely sloppy in your thinking and
>> in your argumentation! That doesn't mean that you wouldn't be able
>> to "write programs" ("this stuff"), for sure. - Another example of
>> sloppy thinking and argumentation.
>>
>>> Perhaps you're just jealous
>>
>> Your mindset is so primitive, naive, and erroneous; unprecedentedly
>> given your stubbornness. Your persistent habit of making guesses,
>> completely missing the point, topics, and characters, had regularly
>> been shown to be widely erroneous. - I see you can't just stop your
>> ineffective tries. It won't lead you anywhere.
>>
>>> that my scheme isn't available in your favourite language.
>>
>> I have no "favourite language". (In a couple languages there's some
>> concepts that I'd like to be more widely spread. - Not sure you're
>> capable of understanding that and notice the blatant difference!)
>>
>> And you should meanwhile know that meaningless home-brewed languages
>> are neither of general interest nor of mine; but you seem to have a
>> persisting mental hindrance to understand what is easy understandable
>> by others. - Just to be clear; I don't know that "my scheme" you're
>> talking about is because I'm not interested in your posts about your
>> personal tools.
>
> Then you are blinkered. You should be able to evaluate and appreciate
> useful and innovate ideas by yourself, without relying on widespread
> adoption to tell you if they are good or bad.
Oh no, Janis is a punch card kid. He has to conform or else the
university will dock his punch card time.
> If, tomorrow, a major mainstream language introduced a module scheme
> just like mine, would you still hate it and think it useless, or would
> you suddenly change your mind?!
>
> Obviously not, because you are bigoted.
>
>
>> (I also suggest to become a bit more honest about your "achievement"
>> with creating your tool unless it gets some minimum general relevance
>> beyond your micro-ecosystem. - Why don't you advertise and offer your
>> tools at any more appropriate place if you think they're so important,
>> innovative, or generally useful?!)
> I might have done that 35 years ago or more.
>
> For example, at one time my small company produced business computers.
> We designed everything about them (my job was taking care of the
> motherboard). We did the PCB layout, manufactured the actual PCBs, and
> populated the PCBS by hand, all in the UK (my boss owned two other small
> companies that took care of that).
>
> We even produced our own OS for it (via a 3rd associated company)!.
>
> Today's landscape is utterly different. Can you imagine one company in
> the UK producing dozens of computers per week compared with current
> mass-production in the far east that produces millions?
Not to mention, Janis is showing his small-mindedness (perhaps a total
lack of MBA) that lower prices create greater demand. In Janis' world,
increasing the prices at your company leads to greater lurve and
happiness with no repercussions whatsoever. It's all about price for
Janis, not price * units sold. He had to spend all his time at
university waiting for the punch card system and found no time for
economics electives.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-09-11 00:37 +0100 |
| Message-ID | <117vevp$2eaof$1@dont-email.me> |
| In reply to | #401872 |
On 10/09/2026 08:48, David Brown wrote:
> On 10/09/2026 00:30, bart wrote:
>> On 09/09/2026 22:26, Janis Papanagnou wrote:
>>> On 2026-09-09 20:12, bart wrote:
>>>> On 09/09/2026 02:59, Waldek Hebisch wrote:
>>>>> [...]
>>>>
>>>> Some even specify individual names to be imported from a module.
>>>> What a complete waste of time!
>>>
>>> I fear you're just exposing your very limited perception and experience
>>> here. (And en passant probably also the mindset of a technocratic paper
>>> pusher than a software designer.)
>>>
>>> Myself I'm favoring _to be able_ to import only what I need and not the
>>> whole bunch of existing things of a module (with all potential implicit
>>> and explicit consequences).
>> Why? What is the advantage of so much micromanagement?
>>
> Consider modules in Python, since that is a language with "real" modules
> and with which many people are familiar.
>
> # foobar.py
> def foo() : return "foo"
> def bar() : return "bar"
>
>
> Another file user.py wants to use "foo" from "foobar.py". They can do
> so in three main ways :
>
> 1. Specific inclusion
>
> from foobar import foo
> x = foo()
>
>
> 2. Global namespace inclusion
>
> from foobar import *
> x = foo()
>
>
> 3. Module namespace inclusion
>
> import foobar
> x = foobar.foo()
>
>
> Each type of import has its own advantages and disadvantages.
>
> Type 1 would need micro-management if you want a lot of symbols from a
> module. But if you only need a small number, it can keep things neat -
> you only see what you actually want to use.
Python doesn't have export attributes. That means that every top- or
module-level identifier can be imported into another module.
In mine, entities have to be explicitly exported to be visible outside.
That means importing everything that a module exports is fine; that's
the idea!
> And if the imported module
> only really exports a single name (like "my_class.py" exporting
> "My_Class"), it's a neat solution that avoids later code clutter from
> having to specify the module name.
I allow that anyway. Unless two modules export the same name then the
compiler complains. However a local name can silently shadow an imported
name, but that's how scopes work in general.
> Type 2 lets you immediately use all the identifiers from the module, but
> causes a lot of problems if things change in the future. Maybe your own
> code has a function "fluff", and a later version of "foobar.py" also
> adds a function "fluff". That is not going to be good.
>
> Type 3 lets you conveniently import all the exported symbols from the
> module, but you need to specify the namespace when using them.
>
>
> As I see it, Janis favours that kind of flexibility for modules (though
> of course the details may differ for different languages).
>
>
> You seem to be favouring just type 2 - or even a "from * import *"
> solution.
Mine actually can be a little more sophisticated. Say for example you
have a mini-library of three modules, and the whole exports several
functions from across those modules.
In Python you'd have to import all three modules: you'd need to now the
internal structure, which in future can change.
With mine, you just import the lead module of the three. If
qualification is needed, then you use the name of the lead module; the
internal structure is opaque.
It is also possible to encapsulate a bunch of functions and stuff which
is only available via a namespace.
> That might be convenient for a personal language where you
> are the only one ever writing the code - you know there are no
> collisions, because you wrote everything. For anyone else, working
> outside a bubble, it is unscalable.
>
As I explained in a post a little while ago, my module scheme is mainly
intended to manage the modules of a single program intended for
whole-program compilation. That includes self-contain mini-libraries
which are statically compiled into the app.
For external libraries, there is a separate approach called the 'FFI'.
There, typically, I would need to create bindings. For my SDL3 example,
that would define 1200 functions, plus 3000 more named constants,
macros, enumerations, structs and types.
This is not part of the module scheme, other than the bindings for
imported FFI functions being with a container module that will re-export
them for use with the rest of the application. That container module
will wrap them in an optional namespace.
Here it would obviously be ludicrous to micro-manage large, unwieldy
subsets of those 4000 names. A program would just do:
module sdl # sdl.m contains the 4000 lines which is condensed
# form of the 86 SDL3 headers
Then all 4000 names will be available. The same as in C, except that I
can shadow them if needed.
I can call SDL3 functions like this:
sql_quit()
This is SDL_Quit in C, but my language allows any case. Or I can apply
the qualifier:
sdl.sql_quit()
But this is obviously a bit silly; SDL names already have a special prefix.
That 'module sdl' line BTW exists in one place in the program. The 4K
sdl.m module is compiled once no matter how many modules in all.
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2026-09-13 18:55 +0000 |
| Message-ID | <1186rjq$1373h$1@paganini.bofh.team> |
| In reply to | #401829 |
bart <bc@freeuk.com> wrote:
> On 09/09/2026 02:59, Waldek Hebisch wrote:
>> bart <bc@freeuk.com> wrote:
>>> On 08/09/2026 01:02, Waldek Hebisch wrote:
>>>> bart <bc@freeuk.com> wrote:
>>>>> On 07/09/2026 14:33, David Brown wrote:
>>>>>> On 07/09/2026 14:55, bart wrote:
>>>>>
>>>>>>> A typical module scheme works like this:
>>>>>>>
>>>>>>> * You have, say, a project of 100 modules
>>>>>>> * Each module selectively exports some entities
>>>>>>> * Each module selectively imports some subset of the other 99 modules
>>>>>>>
>>>>>>
>>>>>> OK so far.
>>>>>>
>>>>>>> The result is that each module starts with some rag-tag collection of
>>>>>>> 'import' statements, each different from any other module, and needing
>>>>>>> a lot of maintenance.
>>>>>>
>>>>>> No. People who write /structured/ code do not do "rag-tag".
>>>>>>
>>>>>> When a project is of a size where it is inconvenient to keep track of
>>>>>> all the separate "import" (or "#include", or whatever) statements, you
>>>>>> use a hierarchy. Instead of importing "dns", "udp", "http", etc.,
>>>>>> modules, you import "network". The common "network" module pulls in the
>>>>>> sub-modules. You probably also organise things in directories and sub-
>>>>>> directories, matching the module layout. It is /structured/.
>>>>>
>>>>> But it's a pattern I've seen a lot. In C also, as collections of
>>>>> #includes; this example is from Lua, a project of only 35 modules, and
>>>>> from one of its .c files:
>>>>>
>>>>> #include "lprefix.h"
>>>>>
>>>>> #include <float.h>
>>>>> #include <limits.h>
>>>>> #include <math.h>
>>>>> #include <stdlib.h>
>>>>>
>>>>> #include "lua.h"
>>>>>
>>>>> #include "lcode.h"
>>>>> #include "ldebug.h"
>>>>> #include "ldo.h"
>>>>> #include "lgc.h"
>>>>> #include "llex.h"
>>>>> #include "lmem.h"
>>>>> #include "lobject.h"
>>>>> #include "lopcodes.h"
>>>>> #include "lparser.h"
>>>>> #include "lstring.h"
>>>>> #include "ltable.h"
>>>>> #include "lvm.h"
>>>>>
>>>>> Every file has a different set. In all, there are 28K lines of C code
>>>>> among the .c files, and there are 466 #include lines. That is similar to
>>>>> the maintenance nightmare where each file imports a particular set of
>>>>> modules.
>>>>
>>>> The organization looks sensible to me.
>>>
>>> Not to me. This project uses these 35 files:
>>>
>>> lapi.c lauxlib.c lbaselib.c lcode.c lcorolib.c lctype.c ldblib.c
>>> ldebug.c ldo.c ldump.c lfunc.c lgc.c linit.c liolib.c llex.c
>>> lmathlib.c lmem.c loadlib.c lobject.c lopcodes.c loslib.c lparser.c
>>> lstate.c lstring.c lstrlib.c ltable.c ltablib.c ltests.c ltm.c lua.c
>>> lundump.c lutf8lib.c lvm.c lzio.c onelua.c
>>>
>>> (A build will use 34 of them, depending whether it is EXE or DLL.)
>>>
>>> With a module scheme, there should be no need for any additional info at
>>> all. But my point was, with how such schemes typically work, you still
>>> have lots of mixed sets of 'import' statements at the start of each file.
>>>
>>>
>>>> Given that #include lines
>>>> are less than 2% of total and are likely to change very infrequently
>>>> I see no maintennce problem.
>>>
>>> You can't quantify it like that. In any case, they will only change
>>> infrequently once you've finished development!
>>
>> If a program is "finished" it will not change at all. During
>> normal developement I need to add #include lines, but once
>> added they tend to stay. Sometimes I realize that given
>> include is not needed or I decide to rename a file. Normal
>> code is different, first version may have bugs which need
>> fixing, I may realize that different structure is better, so
>> there is lot of changes. Relatively to that I perceive changes
>> to #include lines to be very infrequent.
>>
>>> I found it annoying enough, and taking up enough time to devise a new
>>> way of doing modules. And it is utter bliss.
>>
>> I agree that maintaing info that you do not value may be annoying.
>> But if you are used to maintaing C code bases, than maintaining
>> #include lines does not take much time.
>
> People around here always seems to be making excuses for C!
>
> I find that adding include files, creating headers, maintaining forward
> declarations etc to be a complete PITA.
Apparenty you ignored first part above. So, let me expand this.
I see value in specifying interfaces. For me it is important
design information. It takes some time to get it right. Not
time to code or type. It takes time to find good design.
Writing declarations is small part of it. In my use typical import
statement imports several declarations so is even smaller issue.
I mentioned non-C project where I have about 1200 modules. There
are 1115 import statements. Note that some uses imply/are equivalent
to import, for example there is inheritance of interfaces (given
interface exports everything that its parents export plus usually some
additional things), there is probably about 5 thousends of instances
of inheritance. Alternatives would involve duplicating some thousends
of declarations (probably around 10-15 thousends). The system
has about 150000 LOC (215000 wc lines). Compared to total import
statements and inheritance specifications are small part. And they
are relatively trivial: cases where code compiled but import or
inheritance statements were wrong wre quite rare and they mainly
were cases of missing export or not needed import. Later re-design
may change interfaces, but I mean correctness with respect to design
at time where code was compiled. OTOH normal executable code may
compile fine but behaves completely wrong, so requires more work,
I do not think that C can do what this system is doing. But extrapolating,
design in C of similar spirt would probably need say 5000 #include
lines, some hairy macros and 200000-300000 LOC. And executable part
would be much more tricky to get right.
To put this in a bit different way, I probably can enter 1000 lines
daily. If there is enough regularities than I can use tools like
cut-and-paste, global replacement and similar to reduce amount of
typing and to generate say 2000 lines in a day. But when I need
to write executable code, than in happy cases _maybe_ I can
generate 500 lines a day. And usually much less than this.
In case of C I can cut-and-paste between prototypes and function
header, so aount of work needed to maintain declaration in
include file is much smaller than for typical code line. If
I need to change say type in declaration I do this via global
search and replace going over all sources, so extra work needed
is proportional to size of prototypes, which is small percentage
of total sources. And such changes are essentially design changes,
so need some thought before I make them.
So, I think that your problem is mostly psychological: you consider
export/import info as unimportant and it is painful to you to do
work that you consider useless. I consider maintaining export/import
info as important and can do this with resonable efficiency.
>>> Still, modern languages tend to have a module scheme, suggesting the
>>> 'flexible' C approach (I'd use the term 'prehistoric') wasn't quite enough.
>>
>> I used or at least looked at several languages with module systems
>> or things intended to perform similar duty. You approach seem to
>> be unique, all other require explicit import or equivalent at least
>> in some (rather frequent) cases. Some languages do not support
>> re-export, in such case you can rightfully complain. The ones with
>> re-export allow forming common interface module do that number
>> of import statements is minimised. But this is developers choice
>> and apparently most prefer to import only needed things, even
>> though it requires more import statements.
>
> Some even specify individual names to be imported from a module. What a
> complete waste of time!
If I need 1 or 2 names from a module, then it makes sense to specify
them explicitely. This is important information if you want to change
design. I certainly do not want to _always_ specify individual names
and system that I use do not require this.
> It's bad enough listing the modules themselves, of which there may a
> dozen or two, but there could be hundreds of imported functions.
>
> A module scheme should mean less work not more.
OK. But I look at total work. Old systems like FORTRAN (when
it was all caps) made things "easy" by providing default type
for variables based on first letter. Later systems tended to
be more strict requireing explicit declarations. Modern
tendecly is to use type inference, either full as in ML and
followers, or partial like C or C++ 'auto'. Mismatched
declarations may cause troubles like crashes or wrong output
that take work to fix. Compared to that mismatches in explicit
declarations are trivial to fix. So one adds some extra work
to write and maintain declarations for benefit of better error
detection and reduction of total work. Type inference means
almost no reduction in ability to detect errors and some reduction
of work in maintaining declarations. At least in case of C and
C++ type inference optional: you can still give explicit types.
At least your description of of your module system suggest that
it is more like FORTRAN than modern type interface. That is
you hardcode some resonable use case. But if it does not match
user needs, then either program will not build or there will
be chance of build errors. Maybe you worked out good rules,
we do not know. But there is a different aspect: local declarations
are pretty frequent and can be result of macro expansion. So
'auto' has measurable impact on ease of coding. '#include'
lines are much less frequent, so possible saving is much smaller.
Given small possible gain old principle "do not fix what is not
broken" applies. As I wrote, there are things that should
be improved and many languages other than C have their own
module system. But requrement for explicit imports is very
common.
>> Module system has other advantages over C. First, in C sane
>> developers use headers in consistent way, but language
>> does not enforce it. Typical module system enforces
>> consistency. Second, module interfaces can be parsed once,
>> avoiding problem of repeated re-parsing of C headers.
>
> According to David Brown and Scott Lurndal, that is a non-problem!
>
> And according to DB, reducing a large, complex mass of header files (of
> external library) into one compact file 95% smaller, would be a waste of
> time.
If they want, they can write what they think about this issue.
Here I am stating my opinion in context of what you wrote.
One problem with C headers is that a single macro can choose
a differenet branch in a header, so you either need some sophisticated
system of dealing with conditionals or you need to re-parse
whenever any macro is defined differently than during previous
parse. Also, when we have system that works but burns more CPU
cycles than desirable, then throwing enough CPU power may be
best practical solution. That does not stop me for looking for
more CPU-efficient solutions.
>> Third, modules resolve name clashes: the "same" name in
>> two different modules is disambiguated by its source module.
>> Fourth, given a main module compiler can track its imports
>> and build the program without need for separate Makefile.
>
> I tried a scheme in C once. That is, a scheme where you submitted only
> the main.c file to the compiler, then it discovered the rest.
>
> It worked well, but required programs to be written in a certain way.
> For example, each module file.c required a matching file.h header.
Yes, C includes are not real module system, so one needs extra
conventions.
> In the main module, you only included the .h files needed by this
> module. It would then add those .c files, and applied the process
> recursively.
>
> However all the projects I wanted to build weren't structured like this.
Yes.
>> There are different styles. Ada, Modula 2 and Extended Pascal
>> use separate interface modules. In typical practice they are
>> stored in separate files so this looks similar to C practice
>> of having .c and .h files. Other languages like UCSD/Turbo
>> Pascal have modules with separate iterface and implementation
>> parts, but both parts are considered a single module. In
>> practice with such languages whole module is kept in a single
>> file, so number of separate files is smaller. But you still
>> have separate declarations in interface part and definitions
>> in implementation part. Wirth Oberon (or at least some variant
>> of it) uses different apprach, IIRC exported functions are
>> marked putting asterisk before function name. That means less
>> code to write, but to see what is exported you need a separate
>> tool.
>
> With separate interface files, who writes the interface: is it the
> programmer who has to duplicate what is in the implementation? (In which
> case, what checks are made that it matches?)
In system that I use it is the programmer. System checks that
declaration match. In case of systems allowing overloading
there is possiblity that interface file contains one declaration,
while module body declares different function of the same name.
That alone is legal. But if function declared in interface has
no corresponding implementation, then sooner or later this will
be detected. One possibilty is that compilation of module may
signal error due to unimplemented export. Another posibility is
that attempt to use such unimplemented function will cause
runtime error. The second may be nicer during developement,
when interface is defined first and implemented in incremental
way, as it allows testing what is implemented. The first one
is better when you wnat to compile final program.
> Or is it automatic?
>
> My first attempts at (modern) modules tried to do the latter, but it was
> hard. For example, compile module A.m and it generates A.exp which is
> the interface that can be used elsewhere via 'import A'.
>
> But suppose A and B import each other; which is compiled first?
This I resolve with what you would call "whole program compilation".
First pass tries to recognize types. Second pass collects info
about exported functions. I use this in context of explicit interface
parts, but in fact compiler parses everthing and extracts some
information from implementation part. So in principle I could
extract interace based on some markers. After the second pass there
is normal compilation where imports use info colleded in the second
pass. This in not particularly fast, for 150000 LOC I need 3.5s
to extract the interface info. Still, it is small part of the
whole compilation which needs about 300s CPU time (about 38s
real time when using 20 cores). Note: those 3.5s by necessity is
using single core, so I care more about it than about other part
that can be speeded up by using more cores.
For languages without overloading one could use multipass approach:
in first pass collect info about identifiers exported from given
module and list of modules that it imports. In the second pass
compiler would found out which module is responsible for defining
each imported identifier. After that one can do compilation as
in case of explicit interfaces. That is compiler can find out
modules which define each identifier needed by the interface.
If there is cycle between interfaces, that can be detected and
reported (it is an error in typical implementation of explicit
interfaces). Otherwise compiler could find an order such that
each interface depend only on interfaces compiled earlier. After
that one can compile implementations in any order.
IIUC Oberon still _allows_ explicit interface files. So one
could use explicit interfaces to break cycles. That is compiler
would first compile interface part of A, after that modules using A,
and finally implementation part of A.
> This is an advantage of a manually written interface, in that cyclic
> imports become easier, and you don't need a heirarchical structure.
>
>>
>> IIUC modules with separate iterface and implementation were
>> advocated together with database-like storage of source code.
>
> I now work with whole program compilers. There, a discrete interface
> file doesn't make sense and is not needed between the modules of the
> same program.
Well, I want well specified interfaces between parts of the program.
With this it is much easier to decide which module is wrong (does not
comply with its interface) and consequently to fix bugs. Also
I have modules which can use use one of several other modules.
That is module M can use function from A, B, C, ... and it should
work correctly which each one. As long as A, B, C, ... have the
same interface I can test that M works with say A and the A, B, C, ...
in fact implement the same interface and after that expect that
M will also work with B or C. Without well specified interfaces
that would be much harder (or impossible).
In different context, one may have collection of modules such that
some subsets form programs. That is particularly relevant for
microcontrollers, where target is too small to include all available
modules. Also, different microcontrollers may need different
(alternative) hardware specific modules. In such situation you
do not want to leak hardware specific details to general modules.
And in general, you want to limit what is pulled in only to stuff
that is actually needed.
> But they still exist at the boundaries of the program: when the program
> imports an external library, or my program is a library that exports
> functions. In that case, they are only partly automated.
>
>
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-09-14 01:44 +0100 |
| Message-ID | <1187g0t$13f0g$1@dont-email.me> |
| In reply to | #402044 |
On 13/09/2026 19:55, Waldek Hebisch wrote: > bart <bc@freeuk.com> wrote: >> On 09/09/2026 02:59, Waldek Hebisch wrote: >> I find that adding include files, creating headers, maintaining forward >> declarations etc to be a complete PITA. > > Apparenty you ignored first part above. So, let me expand this. > I see value in specifying interfaces. For me it is important > design information. It takes some time to get it right. Not > time to code or type. It takes time to find good design. > Writing declarations is small part of it. Sure. But interfaces to what? To some sort of library? And it isn't really much to do with modules. C libraries have interfaces, usually as headers, but it doesn't have modules. A more typical problem is organising the functions, variables, types, enums and tables of an application into multiple modules: what goes where; what needs to be shared. Once you have your N modules, then that's the list the language's module scheme uses to build your app. A formal interface would be used for external libraries, or for internal libraries where a group of modules form a private sub-program. > In my use typical import > statement imports several declarations so is even smaller issue. > I mentioned non-C project where I have about 1200 modules. There > are 1115 import statements. Note that some uses imply/are equivalent > to import, for example there is inheritance of interfaces (given > interface exports everything that its parents export plus usually some > additional things), there is probably about 5 thousends of instances > of inheritance. Alternatives would involve duplicating some thousends > of declarations (probably around 10-15 thousends). The system > has about 150000 LOC (215000 wc lines). If you have 215Kloc and 1200 modules, then you have other challenges than a module scheme. (That's some 0.18Kloc/module on average, while my stuff might be more like 1Kloc, and used to be nearer 2Kloc.) But I'm surprised you only have about one import statement per file: is it the same project-wide interface file, or is each much more specific? > Compared to total import > statements and inheritance specifications are small part. And they > are relatively trivial: cases where code compiled but import or > inheritance statements were wrong wre quite rare and they mainly > were cases of missing export or not needed import. Later re-design > may change interfaces, but I mean correctness with respect to design > at time where code was compiled. OTOH normal executable code may > compile fine but behaves completely wrong, so requires more work, > > I do not think that C can do what this system is doing. But extrapolating, > design in C of similar spirt would probably need say 5000 #include > lines, some hairy macros and 200000-300000 LOC. And executable part > would be much more tricky to get right. I'm now curious as to what weird things you're doing. Is this other language/scheme one like C++, or something that you have devised? > So, I think that your problem is mostly psychological: you consider > export/import info as unimportant and it is painful to you to do > work that you consider useless. I consider maintaining export/import > info as important and can do this with resonable efficiency. As I suggested above, perhaps 'import/export' are too-strong terms for talking about sharing between friendly modules of the same subprogram. (A 'subprogram' is my language is one building block down from 'program', which equates to a single EXE or DLL binary. 'Module' is just below that and that corresponds to one source file.) Meanwhile interfaces between programs (ie. between EXE/DLL files) is something that doesn't come up often for me; it is a different subject, and something I would also apply automatic methods to as much as possible. It is FFI more than modules. >>>> Still, modern languages tend to have a module scheme, suggesting the >>>> 'flexible' C approach (I'd use the term 'prehistoric') wasn't quite enough. >>> >>> I used or at least looked at several languages with module systems >>> or things intended to perform similar duty. You approach seem to >>> be unique, all other require explicit import or equivalent at least >>> in some (rather frequent) cases. Some languages do not support >>> re-export, in such case you can rightfully complain. The ones with >>> re-export allow forming common interface module do that number >>> of import statements is minimised. But this is developers choice >>> and apparently most prefer to import only needed things, even >>> though it requires more import statements. >> >> Some even specify individual names to be imported from a module. What a >> complete waste of time! > > If I need 1 or 2 names from a module, then it makes sense to specify > them explicitely. I don't see why. Unless you mean it is more important to exclude the names you haven't listed? Support a library or module M exports functions A - F. You'd write: import M then later you can write M.A() to M.F() without doing anything else. Suppose you only need function D. In that case you just call M.D(); nothing is forcing you to call M.E() too! If this is about not having to include those functions in the binary, then that would be something for the language to deal with: it knows which functions have called, and knows those are the ones to import. > Mismatched > declarations may cause troubles like crashes or wrong output > that take work to fix. Compared to that mismatches in explicit > declarations are trivial to fix. So one adds some extra work > to write and maintain declarations for benefit of better error > detection and reduction of total work. What benefits are these? All I can see are loads of annoying errors because you've forgotten to declare entities. > Type inference means > almost no reduction in ability to detect errors and some reduction > of work in maintaining declarations. At least in case of C and > C++ type inference optional: you can still give explicit types. > At least your description of of your module system suggest that > it is more like FORTRAN than modern type interface. Type inference and modules are different things. Modules manage visibility named entities including types across source files. With my whole-program scheme, there will never be type mismatches across the sources files of a particular program. That can only happen when interface/API info and implementation or binary are separate. (Type inference is minimal, nothing like H-M. In any case my Modules work the same way across two languages, one fully typed and static, the other dynamically typed.) >>> Module system has other advantages over C. First, in C sane >>> developers use headers in consistent way, but language >>> does not enforce it. Typical module system enforces >>> consistency. Second, module interfaces can be parsed once, >>> avoiding problem of repeated re-parsing of C headers. >> >> According to David Brown and Scott Lurndal, that is a non-problem! >> >> And according to DB, reducing a large, complex mass of header files (of >> external library) into one compact file 95% smaller, would be a waste of >> time. > > If they want, they can write what they think about this issue. They're users who are proficient in their tools. Nothing ever seem to be a problem - that superfast hardware and dozens of parallel cores can't fix! I've learnt from experience that even a build time of minutes (where the result might be a mere 1MB binary) doesn't faze them. Oh, it's a 'one-off', or they are not curious as to why a simple task isn't faster. Basically they are not interested in any merits of my solutions. > Here I am stating my opinion in context of what you wrote. > One problem with C headers is that a single macro can choose > a differenet branch in a header, so you either need some sophisticated > system of dealing with conditionals or you need to re-parse > whenever any macro is defined differently than during previous All the problems with C headers would be a big subject by itself! >> With separate interface files, who writes the interface: is it the >> programmer who has to duplicate what is in the implementation? (In which >> case, what checks are made that it matches?) > > In system that I use it is the programmer. System checks that > declaration match. C uses the 'linkage' system for functions and variables. It uses text replication to share entities such as types, structs, enumerations and macros. How do other language's modules cope with the latter? (I only know about Python. My languages of course handle all those too.) >> My first attempts at (modern) modules tried to do the latter, but it was >> hard. For example, compile module A.m and it generates A.exp which is >> the interface that can be used elsewhere via 'import A'. >> >> But suppose A and B import each other; which is compiled first? > > This I resolve with what you would call "whole program compilation". > First pass tries to recognize types. Second pass collects info > about exported functions. I use this in context of explicit interface > parts, but in fact compiler parses everthing and extracts some > information from implementation part. So in principle I could > extract interace based on some markers. After the second pass there > is normal compilation where imports use info colleded in the second > pass. This in not particularly fast, for 150000 LOC I need 3.5s > to extract the interface info. Still, it is small part of the > whole compilation which needs about 300s CPU time (about 38s > real time when using 20 cores). This is that 215Kloc project? 300s (approx time for single core) is pretty slow for that. What is the problem here; the language being hard to process? (As you know my stuff works perhaps 3 magnitudes faster, assuming your machine is faster. Although I am currently investigating why my C compiler takes 0.12 seconds to process some 0.5M lines of SDL3 headers when TCC takes only 0.05 seconds. I'm just curious. An odd fact I discovered today: if SDL3 headers (86 files/82Kloc) are preprocessed, the result is only 4000 lines and 27K tokens, even though 550K lines are processed according to my compiler (but maybe that's why it's slow). This output is not enough to use as a new compact header; it will need #defines etc that have been stripped. But it shows the core of the API is quite small. I will investigate further.) >> I now work with whole program compilers. There, a discrete interface >> file doesn't make sense and is not needed between the modules of the >> same program. > > Well, I want well specified interfaces between parts of the program. > With this it is much easier to decide which module is wrong (does not > comply with its interface) and consequently to fix bugs. As I said, many of my modules are friendly. I don't care about formal interfaces. When I do, a module or several can form their own more private group. This makes coding much, much simpler. > Also > I have modules which can use use one of several other modules. > That is module M can use function from A, B, C, ... and it should > work correctly which each one. As long as A, B, C, ... have the > same interface I can test that M works with say A and the A, B, C, ... > in fact implement the same interface and after that expect that > M will also work with B or C. Without well specified interfaces > that would be much harder (or impossible). When happens when A gets too big and you want to split it into A1 and A2; will it need a new formal interface between them? > In different context, one may have collection of modules such that > some subsets form programs. That is particularly relevant for > microcontrollers, where target is too small to include all available > modules. Also, different microcontrollers may need different > (alternative) hardware specific modules. In such situation you > do not want to leak hardware specific details to general modules. > And in general, you want to limit what is pulled in only to stuff > that is actually needed. I work with a 64-bit supercomputer with huge amounts of memory. (In other words, the second-cheapest PC in the shop.) Still, last year I adapted my systems language to work with an emulated Z80 system, and the module scheme still worked! Yes, the memory is more limited, you just have less stuff in the modules. The scheme allows for some flexibility.
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2026-09-14 07:41 +0000 |
| Message-ID | <11888ed$1aofv$1@paganini.bofh.team> |
| In reply to | #402049 |
bart <bc@freeuk.com> wrote:
> On 13/09/2026 19:55, Waldek Hebisch wrote:
>> bart <bc@freeuk.com> wrote:
>>> On 09/09/2026 02:59, Waldek Hebisch wrote:
>
>>> I find that adding include files, creating headers, maintaining forward
>>> declarations etc to be a complete PITA.
>>
>> Apparenty you ignored first part above. So, let me expand this.
>> I see value in specifying interfaces. For me it is important
>> design information. It takes some time to get it right. Not
>> time to code or type. It takes time to find good design.
>> Writing declarations is small part of it.
>
> Sure. But interfaces to what? To some sort of library?
>
> And it isn't really much to do with modules. C libraries have
> interfaces, usually as headers, but it doesn't have modules.
If you want popular comparisons look at Modula 2 or Turbo Pascal.
Each module has interface part and implementation part. Form
outside you can only see what is in the interface part. In
particular to compile any module using A you only need interface
part of A. You can compile implementation of A later, or even
change implementataion of A _after_ you compiled users.
> A more typical problem is organising the functions, variables, types,
> enums and tables of an application into multiple modules: what goes
> where; what needs to be shared.
You may view interface as information about what needs to be shared,
but IMO there is more to this. In badly designed program a lot
must be shared. In well designed program and assuming that problem
domain is suitable for modularization sharing is quite limited.
And frequently is is possible to replace implementation part by
quite a different thing without affectiong correctness of the
program.
To make a concrete example, I needed simple varianat of regular
expressions. In principle I could call existing library via FFI, but
that had its own problems. Since the core algorithm is quite simple
I decided to roll my own. I ended with collection of 4 modules.
One module implements a single node of automation, second one
implements matching algorithm and build automation (that is graph
of nodes) from other data. Third module provides a higher level
abstractions, representing patterns build from simpler automatons
via boolean operations. Fourth module contains a parser which
converts textual patterns to internal representation, using
operations provided by earlier modules. Together this is 452
wc lines. One may be tempted to do this a single module, but
I think that what I did have better structure: first module
essentially defines data struture (or maybe I should say data
type) and in principle this could be part of the second module.
But having module means that some things are hidden and some
are exported in nicer form. So I do not consider having this
as a separtate module as a big deal, but I think that overall
thanks to this code is a little nicer. Second module implements
core algorithm. IMO is is nice that this code is not mixed
with other parts and also it is potentially reusable in the
future. Third module implements feature that I needed, it
is something that AFAIK is not supported by standard libraries
so I would need it even if I decided to scrap the first two
modules and replace them by FFI calls to some standard library.
The actual syntax of supported patterns is confined to the
fourth module. If I needed different syntax (possibly with
different featurs set) I can provide an alternative parser
module. As you later write those are "friendly" modules
designed to work together. But each of them have reasonably
well specified responsibilities. And since responsiblity
of each module is rather narrow, each of them is simple,
almost trivial. Functionality provided by this collection
of 4 modules is not very impressive, but less trivial than
each of the involved modules.
> Once you have your N modules, then that's the list the language's module
> scheme uses to build your app.
>
> A formal interface would be used for external libraries, or for internal
> libraries where a group of modules form a private sub-program.
>
>
>> In my use typical import
>> statement imports several declarations so is even smaller issue.
>> I mentioned non-C project where I have about 1200 modules. There
>> are 1115 import statements. Note that some uses imply/are equivalent
>> to import, for example there is inheritance of interfaces (given
>> interface exports everything that its parents export plus usually some
>> additional things), there is probably about 5 thousends of instances
>> of inheritance. Alternatives would involve duplicating some thousends
>> of declarations (probably around 10-15 thousends). The system
>> has about 150000 LOC (215000 wc lines).
>
> If you have 215Kloc and 1200 modules, then you have other challenges
> than a module scheme. (That's some 0.18Kloc/module on average, while my
> stuff might be more like 1Kloc, and used to be nearer 2Kloc.)
Actually, having a lot of small modules makes things easy. I have
a few larger modules (one is about 3.5K wc lines and it is possible
that some are larger than that), that are harder. Actually, the
problem are interactions in bigger modules. If I could neatly
separate parts of big module I would probably split it.
> But I'm surprised you only have about one import statement per file: is
> it the same project-wide interface file, or is each much more specific?
As I wrote, there is inheritance which is used much more frequently
than import. And import means that all functions from imported
module may be used without qualification. That is if module A
exports function f, than after importing A I can just write 'f()'
to call 'f' (assuming it needs no arguments). In any place (without
need for import statement) I can use qualified name, that is
write 'f()$A' to call 'f' from module 'A'. There are about 8000
of such qualified calls.
Also, about 160 modules are purely interface, it makes no sense to
import them and they do not import anything. They are only used
with inheritance. About 90 are mostly interface, they provide
functions accesible via inheritance and normally are not imported.
about 400 modules work as abstract data types, that is they provide
functions to create and access various data structures.
>> Compared to total import
>> statements and inheritance specifications are small part. And they
>> are relatively trivial: cases where code compiled but import or
>> inheritance statements were wrong wre quite rare and they mainly
>> were cases of missing export or not needed import. Later re-design
>> may change interfaces, but I mean correctness with respect to design
>> at time where code was compiled. OTOH normal executable code may
>> compile fine but behaves completely wrong, so requires more work,
>>
>> I do not think that C can do what this system is doing. But extrapolating,
>> design in C of similar spirt would probably need say 5000 #include
>> lines, some hairy macros and 200000-300000 LOC. And executable part
>> would be much more tricky to get right.
>
> I'm now curious as to what weird things you're doing. Is this other
> language/scheme one like C++, or something that you have devised?
That scheme shares some similarity to C++, but there are differences.
One thing is that at least nominaly there is very strong separation
between modules. Namely data related to a module is invisible
outside, all you can do is to call functions provided by the module.
You may guess that if that was completely true at implementation
level, then performance would be rather poor needing a lot of
function call. So there is a compromise, performance critical
functions (like array indexing) are inlined between modules.
In few rare cases one module uses low level tricks to directly
access data of other module. But in vast majority of cases the
isolation is respected. There are performance traps, but with
care performance can be quite good.
This scheme was invented by other folks in period between 1975-1985.
I have added some changes and improvements, but essential features
are preserved.
Anyway, there is string type checking and isolation between modules,
for me it makes developement much easier. There is garbage collection.
There is code reuse via inheritance and via generic coding (the
same code can work with different data types). To get similar
effects in C one would have to either use macros (to generate
variants of "the same" code for different types) or call functions
via dispatch tables. That would need extra code and would result
in weaker type checking. The code intesively uses operator and
function overloading, it would be more bulky and harder to read
without that. C++ could do some things that I need, but it seems
that it also lacks some features and AFAICS in current form could
not serve as a replacement.
>> So, I think that your problem is mostly psychological: you consider
>> export/import info as unimportant and it is painful to you to do
>> work that you consider useless. I consider maintaining export/import
>> info as important and can do this with resonable efficiency.
>
> As I suggested above, perhaps 'import/export' are too-strong terms for
> talking about sharing between friendly modules of the same subprogram.
As I wrote I have very strong isolation between modules, even if
they are designed to work together. And normally I aim at clearly
divided responsibilities. So IMO 'import/export' correspond with
my reality.
> (A 'subprogram' is my language is one building block down from
> 'program', which equates to a single EXE or DLL binary. 'Module' is just
> below that and that corresponds to one source file.)
>
> Meanwhile interfaces between programs (ie. between EXE/DLL files) is
> something that doesn't come up often for me; it is a different subject,
> and something I would also apply automatic methods to as much as
> possible. It is FFI more than modules.
>
>
>>>>> Still, modern languages tend to have a module scheme, suggesting the
>>>>> 'flexible' C approach (I'd use the term 'prehistoric') wasn't quite enough.
>>>>
>>>> I used or at least looked at several languages with module systems
>>>> or things intended to perform similar duty. You approach seem to
>>>> be unique, all other require explicit import or equivalent at least
>>>> in some (rather frequent) cases. Some languages do not support
>>>> re-export, in such case you can rightfully complain. The ones with
>>>> re-export allow forming common interface module do that number
>>>> of import statements is minimised. But this is developers choice
>>>> and apparently most prefer to import only needed things, even
>>>> though it requires more import statements.
>>>
>>> Some even specify individual names to be imported from a module. What a
>>> complete waste of time!
>>
>> If I need 1 or 2 names from a module, then it makes sense to specify
>> them explicitely.
>
> I don't see why. Unless you mean it is more important to exclude the
> names you haven't listed?
>
> Support a library or module M exports functions A - F. You'd write:
>
> import M
>
> then later you can write M.A() to M.F() without doing anything else.
As I wrote I can use equvalent of M.A() without import. And I find
this preferable when I need only 1 or 2 functions from a module.
> Suppose you only need function D. In that case you just call M.D();
> nothing is forcing you to call M.E() too!
In my case import means that functions are available without
qualification, so plain E() may call function from imported module.
And I have function overloading and partial type inference. In
effect, it is not entirely trivial to decide which function is
actually called when you write E(). Most functions either needs
arguments or produces values (or both), so calling wrong functions
almost surely is not a big problem, that is either overloading
machinery would choose the correct one, or call to wrong one will
result in type error. But still, I think that is better to limit
possible confusion and import as little as possible.
> If this is about not having to include those functions in the binary,
> then that would be something for the language to deal with: it knows
> which functions have called, and knows those are the ones to import.
No, that is purely compile time thing, that is controling what
may be called by limiting visibility.
>> Mismatched
>> declarations may cause troubles like crashes or wrong output
>> that take work to fix. Compared to that mismatches in explicit
>> declarations are trivial to fix. So one adds some extra work
>> to write and maintain declarations for benefit of better error
>> detection and reduction of total work.
>
> What benefits are these? All I can see are loads of annoying errors
> because you've forgotten to declare entities.
I remember maybe one or two cases when wrong function was called
and that passed type checking. Without control of visibility
such cases would be much more frequent. Note: without overloading
such cases would normally be detected as mismatched definitions,
unless somebody adds extra rules that say last import wins.
But for me overloading and type interface are large benefits
and comparably need to control visiblity is modest cost.
More generally, I also worked with dynamic languages where one
simply calls a function and types of arguments are only checked
on use. IME code in such languages needs a lot of testing, much
more than with type checking. That is without type checking
it is too easy to ship code which calls a function with argument
of wrong type. Clearly to check types compiler must know them.
And absent total type reconstrution (like in ML), one needs to
declare types of arguments and return type of functions.
So I hope that is part is clear.
You may doubt necessity of having duplicate declaration in the
module interface. In principle compiler could do all needed
checks having only single declaration. But compilers that I
use need declaration in interface part. And when reading code I
actually prefer to have both declarations. Namely, when looking
at interactions between modules I look at interface parts and
want to see relevant declarations there. When working on inner
part of module I want relevant info there. For example, I disliked
standard Pascal rule that forward declaration contained all
info, but corresponding defintion contained just function name
skipping arguments types and names. For me extra effort during
reading, due to extral lookup for missing info meant more work
compared to cut-and-paste needed to duplicate function header.
>> Type inference means
>> almost no reduction in ability to detect errors and some reduction
>> of work in maintaining declarations. At least in case of C and
>> C++ type inference optional: you can still give explicit types.
>> At least your description of of your module system suggest that
>> it is more like FORTRAN than modern type interface.
>
> Type inference and modules are different things. Modules manage
> visibility named entities including types across source files.
Sure. I mentioned type inference to illustrate that approach may
change and if compiler can infer needed information, then languages
may depend on this saving programmer work. But gross rules like
firt letter rule of old FORTRAN (or implicit int from traditional
C) are unsatisfactory. And when talking about modules your
rule "all modules are visible" looks more like old gross rules and
unlike inference process.
> With my whole-program scheme, there will never be type mismatches across
> the sources files of a particular program. That can only happen when
> interface/API info and implementation or binary are separate.
AFAICS there is possibilty of calling wrong function (if there are
2 functions having the same name and argument types). And with
type inference there is even some possibility of getting wrong
type: compiler calls function giving wrong result type and then
passes this type to a different function. Of course, since you
have function declarations compiler can ensure that passed type is
appropriate for called function. But that still leaves some
possiblity of calling wrong function, especially if programmer
uses only a handful of types and reuses function names.
> (Type inference is minimal, nothing like H-M. In any case my Modules
> work the same way across two languages, one fully typed and static, the
> other dynamically typed.)
>
>
>>>> Module system has other advantages over C. First, in C sane
>>>> developers use headers in consistent way, but language
>>>> does not enforce it. Typical module system enforces
>>>> consistency. Second, module interfaces can be parsed once,
>>>> avoiding problem of repeated re-parsing of C headers.
>>>
>>> According to David Brown and Scott Lurndal, that is a non-problem!
>>>
>>> And according to DB, reducing a large, complex mass of header files (of
>>> external library) into one compact file 95% smaller, would be a waste of
>>> time.
>>
>> If they want, they can write what they think about this issue.
>
> They're users who are proficient in their tools. Nothing ever seem to be
> a problem - that superfast hardware and dozens of parallel cores can't
> fix! I've learnt from experience that even a build time of minutes
> (where the result might be a mere 1MB binary) doesn't faze them.
>
> Oh, it's a 'one-off', or they are not curious as to why a simple task
> isn't faster.
>
> Basically they are not interested in any merits of my solutions.
>
>> Here I am stating my opinion in context of what you wrote.
>> One problem with C headers is that a single macro can choose
>> a differenet branch in a header, so you either need some sophisticated
>> system of dealing with conditionals or you need to re-parse
>> whenever any macro is defined differently than during previous
>
> All the problems with C headers would be a big subject by itself!
>
>>> With separate interface files, who writes the interface: is it the
>>> programmer who has to duplicate what is in the implementation? (In which
>>> case, what checks are made that it matches?)
>>
>> In system that I use it is the programmer. System checks that
>> declaration match.
>
> C uses the 'linkage' system for functions and variables. It uses text
> replication to share entities such as types, structs, enumerations and
> macros. How do other language's modules cope with the latter?
Typical approach is to have compiled version of interface. That
requires some method to write such info to files. IIUC GNU C
precompiled headers use (or used) crude but simple method: they
just dumpled memory area containing intenal compiler representation
of the header. This is simple and fast, but any tiny mismatch could
lead to error, so this mechanizm has serious limitations and is
unsuitable for use with modules. GNU Pascal walked internal tree
of nodes, keeping visted nodes in a hash table to make sure that
needed node is stored exactly one. During storing each node was
assigned integer identifier and all pointers were repleaced by
identifiers (numbers) of taget node. Reading worked in reverse:
it re-build nodes in memory, replacing numeric indentifiers by
pointers.
The system I mentioned above writes interface information in textual
form, but it is easier to parse and more explicit than source code.
> (I only know about Python. My languages of course handle all those too.)
>
>
>>> My first attempts at (modern) modules tried to do the latter, but it was
>>> hard. For example, compile module A.m and it generates A.exp which is
>>> the interface that can be used elsewhere via 'import A'.
>>>
>>> But suppose A and B import each other; which is compiled first?
>>
>> This I resolve with what you would call "whole program compilation".
>> First pass tries to recognize types. Second pass collects info
>> about exported functions. I use this in context of explicit interface
>> parts, but in fact compiler parses everthing and extracts some
>> information from implementation part. So in principle I could
>> extract interace based on some markers. After the second pass there
>> is normal compilation where imports use info colleded in the second
>> pass. This in not particularly fast, for 150000 LOC I need 3.5s
>> to extract the interface info. Still, it is small part of the
>> whole compilation which needs about 300s CPU time (about 38s
>> real time when using 20 cores).
>
> This is that 215Kloc project? 300s (approx time for single core) is
> pretty slow for that. What is the problem here; the language being hard
> to process?
There are some challenges, that like type inference and function
overloading. Actually, handling of types is pretty complex.
Types have parameters and various things, like which functions
are really exported depends on parameters. So to decide if a
call is legal compiler may be forced to do rather complex reasoning.
But AFAICS the main trouble is simple-minded apprach to compilation.
Namely to allow overloading compiler in sequence tries all visible
functions with given name. For each possiblity it tries to compile
argument getting right types. This process is recursive. In
effect, a subexpression of a complex expression may be compiled
multiple times (exponentially many in size of the whole expression).
Usually expressions are resonably small and good possibility is
found relatively early. But 5 seconds for a single line is
possible. In addition compiler uses linear search in symbol table.
This is caused by complexity of maintaining symbol table in other
forms: during recursive search things get inserted in rather irregular
way and removal depends on linear structure. Actually, I added
a hash table that handles most searches, but some searches really
need linear search and they take most time.
Getting rid of recursion and implied by this multiple re-compilation
probably would give 3-5 times faster compilation (and hopefully
would eliminate really bad cases). If things could be simplified
so that hash table is enough, that probably would double speed.
Once that is handled other things would requre attention. But
it does not make much sense to fight for small speedups in other
places when biggest issues (that is recursive compilation and
linear search are unresolved). And that require substantial
rework. Even after rework compiler is unlikly to be as fast as
yours. Namely overloading and type inference means to at any
compilation step there may be multiple possiblities. I do not
know how many, but 2-3 are likely per average call site and
in more compilcated expressions this may compound, maybe to
tens, maybe to thousends. So to find correct types compiler
will have to do more work than compiler without such a
feature. As I wrote, I do not know how much, but 3 times
more work is probably too optimistic, someting between 10 and
20 is more liekely and really hope that worse cases are rare
so that they do not affect average too much.
Also, compiler is using higher level data structures that
has its own costs. Parsing this 215K wc lines takes 1 second,
while it should be possible to do this in 0.1 second. But
again, before other issues are handled relative gain from
faster parser is too small to bother (I may speed up parser
if I need to reorganize it to implement some extra feature).
BTW: It is hard to compare compile speed in longer time because
machines got faster. But when I started my work build needed
something like 2.5 hours, so now is way faster. Some speedup
comes from Makefile-s (skipping useless recompilation). Most
from faster computers. But factor between 2 and 3 probably is
due to may work.
> (As you know my stuff works perhaps 3 magnitudes faster, assuming your
> machine is faster.
>
> Although I am currently investigating why my C compiler takes 0.12
> seconds to process some 0.5M lines of SDL3 headers when TCC takes only
> 0.05 seconds. I'm just curious.
>
> An odd fact I discovered today: if SDL3 headers (86 files/82Kloc) are
> preprocessed, the result is only 4000 lines and 27K tokens, even though
> 550K lines are processed according to my compiler (but maybe that's why
> it's slow).
When I need to look at preprocessed files I frequently see a lot of
blank lines, so I am not surprised that headers get smaller. At first
glance 4000 lines after preprocessing looks too small, but maybe it
is real.
> This output is not enough to use as a new compact header; it will need
> #defines etc that have been stripped. But it shows the core of the API
> is quite small. I will investigate further.)
At some time I did a little work on Mac OS API. There was about
220 tousends symbols, of which something like 200 tousends where
various magic constants. So, maybe bulk od SDL3 headers is due
to defiend constants?
>>> I now work with whole program compilers. There, a discrete interface
>>> file doesn't make sense and is not needed between the modules of the
>>> same program.
>>
>> Well, I want well specified interfaces between parts of the program.
>> With this it is much easier to decide which module is wrong (does not
>> comply with its interface) and consequently to fix bugs.
>
> As I said, many of my modules are friendly. I don't care about formal
> interfaces. When I do, a module or several can form their own more
> private group.
>
> This makes coding much, much simpler.
It seems that our coding style and methodology differ. I find it
simpler with specified interfaces. OK, I do varios small or ad
hoc things and in such case I do not bother much with interfaces.
But if code is intended to live longer and fit into something
bigger, then I care much about interfaces. And IMO in longer
term that is easier.
>> Also
>> I have modules which can use use one of several other modules.
>> That is module M can use function from A, B, C, ... and it should
>> work correctly which each one. As long as A, B, C, ... have the
>> same interface I can test that M works with say A and the A, B, C, ...
>> in fact implement the same interface and after that expect that
>> M will also work with B or C. Without well specified interfaces
>> that would be much harder (or impossible).
>
> When happens when A gets too big and you want to split it into A1 and
> A2; will it need a new formal interface between them?
Yes. Let me add that that I am not too worried by biggish piece
of code. Say, I would probably keep 20000 lines in a single file
if I could not find reasonably natural way to split it into pieces.
OTOH, if there is natural division into parts which are 100 lines
each, then I probably would split it into such small parts.
Let me add, that in C if file gets really too big, but there is
no natural split into modules, then I may accept a multi-file
module. But this is not an option if a language implementation
assumes that file=module.
>> In different context, one may have collection of modules such that
>> some subsets form programs. That is particularly relevant for
>> microcontrollers, where target is too small to include all available
>> modules. Also, different microcontrollers may need different
>> (alternative) hardware specific modules. In such situation you
>> do not want to leak hardware specific details to general modules.
>> And in general, you want to limit what is pulled in only to stuff
>> that is actually needed.
>
> I work with a 64-bit supercomputer with huge amounts of memory. (In
> other words, the second-cheapest PC in the shop.)
Me too. But I work with a few architectures: x86_64, aarch64 and
riscv64. The only realy fast and big is a PC, but the other are
useful too. Actually, few days ago I worked on code generators
for a different compiler than discussed above, targeting aarch64
and riscv64.
> Still, last year I adapted my systems language to work with an emulated
> Z80 system, and the module scheme still worked!
>
> Yes, the memory is more limited, you just have less stuff in the
> modules. The scheme allows for some flexibility.
I am not trying to have native compiler for such machines. Rather,
for microcontrollers I use cross compilers. Certainly, I could have
some fun trying to create native compiler for such machine, but
I have enough fun with what I am doing and I am trying to avoid
starting too many projects that I will not be able to finish due
to lack of time.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-09-14 14:01 +0100 |
| Message-ID | <1188r7k$1hk4o$1@dont-email.me> |
| In reply to | #402050 |
On 14/09/2026 08:41, Waldek Hebisch wrote:
> bart <bc@freeuk.com> wrote:
>> A more typical problem is organising the functions, variables, types,
>> enums and tables of an application into multiple modules: what goes
>> where; what needs to be shared.
>
> You may view interface as information about what needs to be shared,
> but IMO there is more to this. In badly designed program a lot
> must be shared. In well designed program and assuming that problem
> domain is suitable for modularization sharing is quite limited.
> And frequently is is possible to replace implementation part by
> quite a different thing without affectiong correctness of the
> program.
>
> To make a concrete example, I needed simple varianat of regular
> expressions. In principle I could call existing library via FFI, but
> that had its own problems. Since the core algorithm is quite simple
> I decided to roll my own. I ended with collection of 4 modules.
> One module implements a single node of automation, second one
> implements matching algorithm and build automation (that is graph
> of nodes) from other data. Third module provides a higher level
> abstractions, representing patterns build from simpler automatons
> via boolean operations. Fourth module contains a parser which
> converts textual patterns to internal representation, using
> operations provided by earlier modules. Together this is 452
> wc lines. One may be tempted to do this a single module, but
> I think that what I did have better structure: first module
> essentially defines data struture (or maybe I should say data
> type) and in principle this could be part of the second module.
> But having module means that some things are hidden and some
> are exported in nicer form. So I do not consider having this
> as a separtate module as a big deal, but I think that overall
> thanks to this code is a little nicer. Second module implements
> core algorithm. IMO is is nice that this code is not mixed
> with other parts and also it is potentially reusable in the
> future. Third module implements feature that I needed, it
> is something that AFAIK is not supported by standard libraries
> so I would need it even if I decided to scrap the first two
> modules and replace them by FFI calls to some standard library.
> The actual syntax of supported patterns is confined to the
> fourth module. If I needed different syntax (possibly with
> different featurs set) I can provide an alternative parser
> module. As you later write those are "friendly" modules
> designed to work together. But each of them have reasonably
> well specified responsibilities. And since responsiblity
> of each module is rather narrow, each of them is simple,
> almost trivial. Functionality provided by this collection
> of 4 modules is not very impressive, but less trivial than
> each of the involved modules.
So let's say I implement this as four modules node.m, match.m,
patterns.m, parser.m.
Since they are really one unit, then anything that needs to be shared
between them is marked 'global' to export, but see below.
How they are imported depends on how they are to be used. They could be
casually added to the modules of my application. Then I add these lines
to its project info:
module node
module match
module patterns
module parser
I can access its exported names directly without a qualifier as F(), or
I can use mode.F(), parser.F() etc depending on where it lives.
This forms part of my app and will be compiled as part of the
whole-program build.
However this is too casual: there is no real connection between it my
and my own app. I can also see names shared across the four modules
which are meant to be private (and it can access names in /my/ app!).
So probably this would be made into its own subprogram. It will need its
own module info, either added to one designated module, or more usually
in a dedicated lead module, say called rex.m, which contains those same
lines:
module node
module match
module patterns
module parser
A further change is that those 'global' attributes need to be changed to
'export' to make them visible outside.
Now, in my app, I add this one line to the project info:
import rex
I can now still call F(), or qualify it as rex.F(); I no longer need to
know where F exists. (However, exported names must be unique; I can't
use both node.F() and match.F().)
'rex' and its modules can no longer see my apps global names. Its source
files however will still be compiled into my app.
So that's two approaches to such a library that my scheme allows for.
There is a third one: to put the library into its own DLL.
The start point is the second approach, with rex.m and the four modules.
But now I build it as a separate binary like this:
mm -dll rex # creates rex.dll
In my app, it now needs separate declarations which look like this:
importdll rex =
... FFI declarations for rex's exports
end
This is not project info and can located anywhere. The declarations can
be created in several ways:
* Manually, but then they must keep track of any changes in the library
* If rex was a C library, I can use a tool to do most of the work of
creating this import block from a C header.
* If written in my language, then 'mm -dll rex' will also write a
suitable import module containing that 'importdll' block, either called
rex_lib.m or rex.q depending on which of my two languages was
configured. Then in my app's project info I can write one of:
module rex_lib # (using rex.m would overwrite the rex.m original)
module rex
That exported function can still called as F(), or as rex_lib.F() or
rex.F().
I still build my app as 'mm app'; it will automatically pull in rex.dll.
What it doesn't do at the minute is write docs: collate doc-info from
the exported module and write into a file to act as documentation.
I used to have support for such doc-strings but dropped it due to lack
of use.
To summarise using this example 4-module library:
(1) Add 4 'module' directives to my own app
(2) Put them into rex.m then add 'module rex' to my app
(3) Put them into rex.m, build as DLL, then add 'module rex/rex_lib'
to my app
This last will probably most appeal to you and corresponds most closely
to your discrete interfaces. However it is more chaotic since it needs a
separate set of declarations from from the definitions in the 4 modules.
(May respond to other points in your post later.)
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-09-14 14:09 +0100 |
| Message-ID | <1188rm4$1hr44$1@dont-email.me> |
| In reply to | #402054 |
On 14/09/2026 14:01, bart wrote:
> To summarise using this example 4-module library:
>
> (1) Add 4 'module' directives to my own app
>
> (2) Put them into rex.m then add 'module rex' to my app
Sorry, that would be 'import rex' now.
>
> (3) Put them into rex.m, build as DLL, then add 'module rex/rex_lib'
> to my app
And that module contains 'importdll rex`, yet a further level in my
module scheme.
There used to be a 4th experimental option which was this:
importd rex
This would directly use rex.dll, which needed to have embedded within it
(accessed via an exported function or variable) all the declarations and
other info required to make make use of it.
However, this would be of most use with other people's DLLs, but
obviously nobody is going to add such info, even if they could agree the
format.
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2026-09-15 02:42 +0000 |
| Message-ID | <118abbd$1jj7c$1@paganini.bofh.team> |
| In reply to | #402054 |
bart <bc@freeuk.com> wrote:
> On 14/09/2026 08:41, Waldek Hebisch wrote:
>> bart <bc@freeuk.com> wrote:
>
>>> A more typical problem is organising the functions, variables, types,
>>> enums and tables of an application into multiple modules: what goes
>>> where; what needs to be shared.
>>
>> You may view interface as information about what needs to be shared,
>> but IMO there is more to this. In badly designed program a lot
>> must be shared. In well designed program and assuming that problem
>> domain is suitable for modularization sharing is quite limited.
>> And frequently is is possible to replace implementation part by
>> quite a different thing without affectiong correctness of the
>> program.
>>
>> To make a concrete example, I needed simple varianat of regular
>> expressions. In principle I could call existing library via FFI, but
>> that had its own problems. Since the core algorithm is quite simple
>> I decided to roll my own. I ended with collection of 4 modules.
>> One module implements a single node of automation, second one
>> implements matching algorithm and build automation (that is graph
>> of nodes) from other data. Third module provides a higher level
>> abstractions, representing patterns build from simpler automatons
>> via boolean operations. Fourth module contains a parser which
>> converts textual patterns to internal representation, using
>> operations provided by earlier modules. Together this is 452
>> wc lines. One may be tempted to do this a single module, but
>> I think that what I did have better structure: first module
>> essentially defines data struture (or maybe I should say data
>> type) and in principle this could be part of the second module.
>> But having module means that some things are hidden and some
>> are exported in nicer form. So I do not consider having this
>> as a separtate module as a big deal, but I think that overall
>> thanks to this code is a little nicer. Second module implements
>> core algorithm. IMO is is nice that this code is not mixed
>> with other parts and also it is potentially reusable in the
>> future. Third module implements feature that I needed, it
>> is something that AFAIK is not supported by standard libraries
>> so I would need it even if I decided to scrap the first two
>> modules and replace them by FFI calls to some standard library.
>> The actual syntax of supported patterns is confined to the
>> fourth module. If I needed different syntax (possibly with
>> different featurs set) I can provide an alternative parser
>> module. As you later write those are "friendly" modules
>> designed to work together. But each of them have reasonably
>> well specified responsibilities. And since responsiblity
>> of each module is rather narrow, each of them is simple,
>> almost trivial. Functionality provided by this collection
>> of 4 modules is not very impressive, but less trivial than
>> each of the involved modules.
>
> So let's say I implement this as four modules node.m, match.m,
> patterns.m, parser.m.
>
> Since they are really one unit, then anything that needs to be shared
> between them is marked 'global' to export, but see below.
>
> How they are imported depends on how they are to be used. They could be
> casually added to the modules of my application. Then I add these lines
> to its project info:
>
> module node
> module match
> module patterns
> module parser
>
> I can access its exported names directly without a qualifier as F(), or
> I can use mode.F(), parser.F() etc depending on where it lives.
>
> This forms part of my app and will be compiled as part of the
> whole-program build.
>
> However this is too casual: there is no real connection between it my
> and my own app. I can also see names shared across the four modules
> which are meant to be private (and it can access names in /my/ app!).
>
> So probably this would be made into its own subprogram. It will need its
> own module info, either added to one designated module, or more usually
> in a dedicated lead module, say called rex.m, which contains those same
> lines:
>
> module node
> module match
> module patterns
> module parser
>
> A further change is that those 'global' attributes need to be changed to
> 'export' to make them visible outside.
>
> Now, in my app, I add this one line to the project info:
>
> import rex
>
> I can now still call F(), or qualify it as rex.F(); I no longer need to
> know where F exists. (However, exported names must be unique; I can't
> use both node.F() and match.F().)
>
> 'rex' and its modules can no longer see my apps global names. Its source
> files however will still be compiled into my app.
This case look similar to the following Turbo/GNU Pascal code:
unit rex;
interface
uses node, match, patterns, parser;
end
Namely, since node, match, patterns, parser are imported in the
interface part of the module all identifiers from them are exported
from rex. I am writing this from memory, so the exact syntax may
be slightly different, possibly one needs to add some extra keywords.
The first case have some similarity to having someting like:
unit globals;
interface
uses ..., node, match, patterns, parser, ...;
end
that is creating a module that import all what is needed by the application.
One difference is that in Turbo Pascal you would have to add
uses globals;
to each source file. Other difference is that modules see only things
imported via 'uses'. And IIRC such global module defeats use of
qualified name to distinguish finctions. That is qualified name
would be globals.f. To use 'node.f' you need to directly import node.
> So that's two approaches to such a library that my scheme allows for.
> There is a third one: to put the library into its own DLL.
>
> The start point is the second approach, with rex.m and the four modules.
> But now I build it as a separate binary like this:
>
> mm -dll rex # creates rex.dll
>
> In my app, it now needs separate declarations which look like this:
>
> importdll rex =
> ... FFI declarations for rex's exports
> end
>
> This is not project info and can located anywhere. The declarations can
> be created in several ways:
>
> * Manually, but then they must keep track of any changes in the library
>
> * If rex was a C library, I can use a tool to do most of the work of
> creating this import block from a C header.
>
> * If written in my language, then 'mm -dll rex' will also write a
> suitable import module containing that 'importdll' block, either called
> rex_lib.m or rex.q depending on which of my two languages was
> configured. Then in my app's project info I can write one of:
>
> module rex_lib # (using rex.m would overwrite the rex.m original)
> module rex
>
> That exported function can still called as F(), or as rex_lib.F() or
> rex.F().
>
> I still build my app as 'mm app'; it will automatically pull in rex.dll.
Turbo Pascal was before era of shared libraries and insisted that
main program is in Turbo Pascal, so you could not use it to create
libraries usable from other languages. With GNU Pascal one could
just pass an option to create shared library and it create one. With
proper extras (like C header files) the library was usable from
any language. But really nice use from Pascal required some extra
effort. Namely interface parts of modules provided declarations,
but one had to add a special token so that compiler knew that
implementation was in the library. But once creator of the library
did its work it was transparent for the users, they just added
appropriate 'uses' statement and compiler took care of the rest.
That is normal module was compile and linked. Module from static
library was statically linked. When module was in shared library
the library was dynamically linked.
There is one extra issue related to shared libraries, that is
visibility. Quite typical case is that some symbols are
"global" inside the shared library but should be invisible outside.
GNU C has an attribute to control that. The same attibute could
be used from GNU Pascal. IIUC your/Microsoft dll-something
stuff serves similar purpose.
> What it doesn't do at the minute is write docs: collate doc-info from
> the exported module and write into a file to act as documentation.
>
> I used to have support for such doc-strings but dropped it due to lack
> of use.
>
>
> To summarise using this example 4-module library:
>
> (1) Add 4 'module' directives to my own app
>
> (2) Put them into rex.m then add 'module rex' to my app
>
> (3) Put them into rex.m, build as DLL, then add 'module rex/rex_lib'
> to my app
>
> This last will probably most appeal to you and corresponds most closely
> to your discrete interfaces. However it is more chaotic since it needs a
> separate set of declarations from from the definitions in the 4 modules.
Actually in my case modules are dynamically loadable, so in a sense
closest analogy would be to have 4 DLL-s. And one way of compiling
for Windows would give you 4 real DLL-s. But PE headres are rather
large, so this is rather bloated way. Different way uses different
format which is much more space efficient.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-09-14 23:41 +0100 |
| Message-ID | <1189t61$1v7ec$1@dont-email.me> |
| In reply to | #402050 |
On 14/09/2026 08:41, Waldek Hebisch wrote:
> bart <bc@freeuk.com> wrote:
> As I wrote, there is inheritance which is used much more frequently
> than import. And import means that all functions from imported
> module may be used without qualification. That is if module A
> exports function f, than after importing A I can just write 'f()'
> to call 'f' (assuming it needs no arguments).
....> As I wrote I can use equvalent of M.A() without import.
Do you mean that you can call imported function A() without importing
its owner module M()?
Above (in the example that uses A.f() instead of M.A()) you suggest the
module name must be explicitly exported.
Otherwise there must be some other approach for the compiler to know
what imports are to be done. (I think some schemes are file-based: eg.
all source files in the current directory are assumed to be project
modules.)
> In my case import means that functions are available without
> qualification, so plain E() may call function from imported module.
> And I have function overloading and partial type inference. In
> effect, it is not entirely trivial to decide which function is
> actually called when you write E(). Most functions either needs
> arguments or produces values (or both), so calling wrong functions
> almost surely is not a big problem, that is either overloading
> machinery would choose the correct one, or call to wrong one will
> result in type error. But still, I think that is better to limit
> possible confusion and import as little as possible.
My language only allows one top-level name E in scope at any one
location. If two imported modules both export E, then the compiler will
complain; they need to be disambiguated.
There is also shadowing, so here it is possible to mistakenly call a
local function that happens to have the same name and signature.
But such problems are well-known when you have nested scopes, and you
see them in other languages too.
> More generally, I also worked with dynamic languages where one
> simply calls a function and types of arguments are only checked
> on use. IME code in such languages needs a lot of testing, much
> more than with type checking. That is without type checking
> it is too easy to ship code which calls a function with argument
> of wrong type. Clearly to check types compiler must know them.
> And absent total type reconstrution (like in ML), one needs to
> declare types of arguments and return type of functions.
> So I hope that is part is clear.
I have a lot of experience of dynamic languages that ran at customer
sites. Such language errors were extremely rare.
It's not that I did extensive testing, but with normal development over
a longish time-frame (eg. 1-2 years), you will uncover a lot of bugs!
> You may doubt necessity of having duplicate declaration in the
> module interface. In principle compiler could do all needed
> checks having only single declaration. But compilers that I
> use need declaration in interface part. And when reading code I
> actually prefer to have both declarations. Namely, when looking
> at interactions between modules I look at interface parts and
> want to see relevant declarations there.
The duplicate declarations are necessary in some situations. For example
you don't have the implementation source code, but that info is
necessary to be able to use those exports in your program.
However, they could be automatically generated by whoever /does/ have
the source code, by a compiler option.
> When working on inner
> part of module I want relevant info there. For example, I disliked
> standard Pascal rule that forward declaration contained all
> info, but corresponding defintion contained just function name
> skipping arguments types and names. For me extra effort during
> reading, due to extral lookup for missing info meant more work
> compared to cut-and-paste needed to duplicate function header.
I don't remember that in Pascal. However I remember similar schemes from
my own early languages. Functions were routinely declared in advance,
whether necessary or not (I didn't want to worry about definition order).
But the declaration contained only the parameter types, and the
definition contained only the parameter names! I recently rediscovered
this fact and wondered how I tolerated it.
>>> Type inference means
>>> almost no reduction in ability to detect errors and some reduction
>>> of work in maintaining declarations. At least in case of C and
>>> C++ type inference optional: you can still give explicit types.
>>> At least your description of of your module system suggest that
>>> it is more like FORTRAN than modern type interface.
>>
>> Type inference and modules are different things. Modules manage
>> visibility named entities including types across source files.
>
> Sure. I mentioned type inference to illustrate that approach may
> change and if compiler can infer needed information, then languages
> may depend on this saving programmer work. But gross rules like
> firt letter rule of old FORTRAN (or implicit int from traditional
> C) are unsatisfactory. And when talking about modules your
> rule "all modules are visible" looks more like old gross rules and
> unlike inference process.
Well, all functions and other top-level names are visible everywhere
inside one module. That is not usually considered a problem.
Since you mentioned big modules, I will say that in my old stuff, one
module had 7K lines (an interpreter core), and another nearly 6K (a
one-pass bytecode compiler), although bloated by inline assembly.
This is basically taking such a module and splitting it up into N
chunks. Entities used in more than one chunk need to be shared.
>> C uses the 'linkage' system for functions and variables. It uses text
>> replication to share entities such as types, structs, enumerations and
>> macros. How do other language's modules cope with the latter?
>
> Typical approach is to have compiled version of interface. That
> requires some method to write such info to files. IIUC GNU C
> precompiled headers use (or used) crude but simple method: they
> just dumpled memory area containing intenal compiler representation
> of the header. This is simple and fast, but any tiny mismatch could
> lead to error, so this mechanizm has serious limitations and is
> unsuitable for use with modules. GNU Pascal walked internal tree
> of nodes, keeping visted nodes in a hash table to make sure that
> needed node is stored exactly one. During storing each node was
> assigned integer identifier and all pointers were repleaced by
> identifiers (numbers) of taget node. Reading worked in reverse:
> it re-build nodes in memory, replacing numeric indentifiers by
> pointers.
>
> The system I mentioned above writes interface information in textual
> form, but it is easier to parse and more explicit than source code.
I was asking more about managing the names of variables, types etc
across modules. In C that is very crude, and it can be unintuitive.
As I do it, all of these named, top-level entities:
functions
variables
named constants
enumerations
user-defined types and records
macros
are handled in the same way: stick 'global' or 'export' in front of the
definitions, and it makes the names visible outside the module.
I was asking if the same applied to other languages.
>> This is that 215Kloc project? 300s (approx time for single core) is
>> pretty slow for that. What is the problem here; the language being hard
>> to process?
> In addition compiler uses linear search in symbol table.
Actually I use linear searching extensively too. Except in the global
symbol table which is a hash-table. So lexical lookups use that, but
resolving a generic identifier into a special one uses linear methods.
Generally it is still very fast because the lists are short. But some
programs could cause it trouble.
> Getting rid of recursion and implied by this multiple re-compilation
> probably would give 3-5 times faster compilation (and hopefully
> would eliminate really bad cases). If things could be simplified
> so that hash table is enough, that probably would double speed.
> Once that is handled other things would requre attention. But
> it does not make much sense to fight for small speedups in other
> places when biggest issues (that is recursive compilation and
> linear search are unresolved). And that require substantial
> rework. Even after rework compiler is unlikly to be as fast as
> yours. Namely overloading and type inference
So, is type inference (eg. Hindley-Milner) inherently slow?
> Also, compiler is using higher level data structures that
> has its own costs. Parsing this 215K wc lines takes 1 second,
> while it should be possible to do this in 0.1 second. But
> again, before other issues are handled relative gain from
> faster parser is too small to bother (I may speed up parser
> if I need to reorganize it to implement some extra feature).
>
> BTW: It is hard to compare compile speed in longer time because
> machines got faster. But when I started my work build needed
> something like 2.5 hours,
I would never have tolerated that. I considered it part of my job to
make sure my tools stayed productive whatever the hardware.
> When I need to look at preprocessed files I frequently see a lot of
> blank lines, so I am not surprised that headers get smaller. At first
> glance 4000 lines after preprocessing looks too small, but maybe it
> is real.
I can tell you that 1/3 of my processing type is to do with comments.
(After stripping them it took 2/3 as long.) So I might look at how
efficiently that is done, for a start. But there is a lot of mystery still.
>> This output is not enough to use as a new compact header; it will need
>> #defines etc that have been stripped. But it shows the core of the API
>> is quite small. I will investigate further.)
>
> At some time I did a little work on Mac OS API. There was about
> 220 tousends symbols, of which something like 200 tousends where
> various magic constants. So, maybe bulk od SDL3 headers is due
> to defiend constants?
From the end result (via a tool to convert to my bindings), there are
about 500 #defines and 1100 enum names. But probably there are lots of
duplicates in the headers, some may be in 'dead' blocks. And some
headers are processed more than once.
It's messy, but it seems a big downside of C's 'module' scheme!
And of course, all the work has to be repeated for each file that
includes SDK.h.
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2026-09-15 01:48 +0000 |
| Message-ID | <118a84o$1jddh$1@paganini.bofh.team> |
| In reply to | #402084 |
bart <bc@freeuk.com> wrote:
> On 14/09/2026 08:41, Waldek Hebisch wrote:
>> bart <bc@freeuk.com> wrote:
>
>> As I wrote, there is inheritance which is used much more frequently
>> than import. And import means that all functions from imported
>> module may be used without qualification. That is if module A
>> exports function f, than after importing A I can just write 'f()'
>> to call 'f' (assuming it needs no arguments).
> ....> As I wrote I can use equvalent of M.A() without import.
>
> Do you mean that you can call imported function A() without importing
> its owner module M()?
Yes, but only using quailfied name, in your notation A.A()
> Above (in the example that uses A.f() instead of M.A()) you suggest the
> module name must be explicitly exported.
Anything not exported is invisible from outside of given module.
So you need to export a name to use it from outside.
> Otherwise there must be some other approach for the compiler to know
> what imports are to be done. (I think some schemes are file-based: eg.
> all source files in the current directory are assumed to be project
> modules.)
Compiler has info about exported things from all "standard" modules
(that is distributed with the compiler), this info is collected at
system build time. If you compile a new nonstandard module it is
then usable for import in given invocation of the compiler. You
can also tell the compiler about previously compiled modules.
So at any given time compiler has list of modules it considers valid.
Beside module name it also contains information where to find
compiled code of the module.
>> In my case import means that functions are available without
>> qualification, so plain E() may call function from imported module.
>> And I have function overloading and partial type inference. In
>> effect, it is not entirely trivial to decide which function is
>> actually called when you write E(). Most functions either needs
>> arguments or produces values (or both), so calling wrong functions
>> almost surely is not a big problem, that is either overloading
>> machinery would choose the correct one, or call to wrong one will
>> result in type error. But still, I think that is better to limit
>> possible confusion and import as little as possible.
>
> My language only allows one top-level name E in scope at any one
> location. If two imported modules both export E, then the compiler will
> complain; they need to be disambiguated.
OK.
> There is also shadowing, so here it is possible to mistakenly call a
> local function that happens to have the same name and signature.
>
> But such problems are well-known when you have nested scopes, and you
> see them in other languages too.
>
>
>> More generally, I also worked with dynamic languages where one
>> simply calls a function and types of arguments are only checked
>> on use. IME code in such languages needs a lot of testing, much
>> more than with type checking. That is without type checking
>> it is too easy to ship code which calls a function with argument
>> of wrong type. Clearly to check types compiler must know them.
>> And absent total type reconstrution (like in ML), one needs to
>> declare types of arguments and return type of functions.
>> So I hope that is part is clear.
>
> I have a lot of experience of dynamic languages that ran at customer
> sites. Such language errors were extremely rare.
>
> It's not that I did extensive testing, but with normal development over
> a longish time-frame (eg. 1-2 years), you will uncover a lot of bugs!
I would say that normally it is rare to discover such bugs. Simply
your program happily runs for 20 years and then you suddenly discover
that some strange but valid input causes a crash.
Also, I found it pretty common to have functions that are never
called, which if called would crash. Since functions are never
called you can not discover errors in them by testing.
Why do I say this:
1) when attemptin to modify old code I frequently see things which
look strange. In many cases deeper egzamination shows that
code is wrong.
2) I also run a compiler which is doing deeper analysis and it
reported several problems with old code.
IIUC in commercial settings in the past there were tendency to
disregard such problem ("if customer can not see a problem, then
software is good enough").
>> You may doubt necessity of having duplicate declaration in the
>> module interface. In principle compiler could do all needed
>> checks having only single declaration. But compilers that I
>> use need declaration in interface part. And when reading code I
>> actually prefer to have both declarations. Namely, when looking
>> at interactions between modules I look at interface parts and
>> want to see relevant declarations there.
>
> The duplicate declarations are necessary in some situations. For example
> you don't have the implementation source code, but that info is
> necessary to be able to use those exports in your program.
>
> However, they could be automatically generated by whoever /does/ have
> the source code, by a compiler option.
Well, compiler must know what is exported. Usual way to provide
this information is via duplicate declarations.
>> When working on inner
>> part of module I want relevant info there. For example, I disliked
>> standard Pascal rule that forward declaration contained all
>> info, but corresponding defintion contained just function name
>> skipping arguments types and names. For me extra effort during
>> reading, due to extral lookup for missing info meant more work
>> compared to cut-and-paste needed to duplicate function header.
>
> I don't remember that in Pascal. However I remember similar schemes from
> my own early languages. Functions were routinely declared in advance,
> whether necessary or not (I didn't want to worry about definition order).
>
> But the declaration contained only the parameter types, and the
> definition contained only the parameter names! I recently rediscovered
> this fact and wondered how I tolerated it.
>
>
>>>> Type inference means
>>>> almost no reduction in ability to detect errors and some reduction
>>>> of work in maintaining declarations. At least in case of C and
>>>> C++ type inference optional: you can still give explicit types.
>>>> At least your description of of your module system suggest that
>>>> it is more like FORTRAN than modern type interface.
>>>
>>> Type inference and modules are different things. Modules manage
>>> visibility named entities including types across source files.
>>
>> Sure. I mentioned type inference to illustrate that approach may
>> change and if compiler can infer needed information, then languages
>> may depend on this saving programmer work. But gross rules like
>> firt letter rule of old FORTRAN (or implicit int from traditional
>> C) are unsatisfactory. And when talking about modules your
>> rule "all modules are visible" looks more like old gross rules and
>> unlike inference process.
>
> Well, all functions and other top-level names are visible everywhere
> inside one module. That is not usually considered a problem.
If top-level internal names are visible everywhere inside one
module, that is OK. With imported names it is borderline.
That is module A may export 100 functions of which 10 are needed
inside function f and not needed outside. 100 functions pollute
name space. Selecively importing 10 requires some work and still
makes then visible in places where they are not needed. In such
case best solution is import at function level, that is imported
names are only visible within function f.
> Since you mentioned big modules, I will say that in my old stuff, one
> module had 7K lines (an interpreter core), and another nearly 6K (a
> one-pass bytecode compiler), although bloated by inline assembly.
>
> This is basically taking such a module and splitting it up into N
> chunks. Entities used in more than one chunk need to be shared.
>
>>> C uses the 'linkage' system for functions and variables. It uses text
>>> replication to share entities such as types, structs, enumerations and
>>> macros. How do other language's modules cope with the latter?
>>
>> Typical approach is to have compiled version of interface. That
>> requires some method to write such info to files. IIUC GNU C
>> precompiled headers use (or used) crude but simple method: they
>> just dumpled memory area containing intenal compiler representation
>> of the header. This is simple and fast, but any tiny mismatch could
>> lead to error, so this mechanizm has serious limitations and is
>> unsuitable for use with modules. GNU Pascal walked internal tree
>> of nodes, keeping visted nodes in a hash table to make sure that
>> needed node is stored exactly one. During storing each node was
>> assigned integer identifier and all pointers were repleaced by
>> identifiers (numbers) of taget node. Reading worked in reverse:
>> it re-build nodes in memory, replacing numeric indentifiers by
>> pointers.
>>
>> The system I mentioned above writes interface information in textual
>> form, but it is easier to parse and more explicit than source code.
>
> I was asking more about managing the names of variables, types etc
> across modules. In C that is very crude, and it can be unintuitive.
>
> As I do it, all of these named, top-level entities:
>
> functions
> variables
> named constants
> enumerations
> user-defined types and records
> macros
>
> are handled in the same way: stick 'global' or 'export' in front of the
> definitions, and it makes the names visible outside the module.
At source code level typical practice is to have module interface,
everthing declated there is exported. At implementation level
this can be handled by setting a flag, (say 'export') for things in
the interface, and no export for implementation part.
Extended Pascal has rather over-engineered system: module may have
multiple interfaces. Everthing declared in module interface part
may be exported, but to really export it you need to declare a
interface and list all names exported by this interface. This has
some advantages, for example you can export a function without
exporting type of return value or types of arguments. But
implementation is complex and in use it is tedious to provide
list of exported names. And in practice module frequently have
only a single interface, so declaration(s) of interfaces add
unnecessary clutter. GNU Pascal made it a bit simpler, instead
of providing list of names you could write keyward 'all' meaning
list of all things defined in the interface, or 'all' with exclusions.
> I was asking if the same applied to other languages.
>
>
>>> This is that 215Kloc project? 300s (approx time for single core) is
>>> pretty slow for that. What is the problem here; the language being hard
>>> to process?
>
>> In addition compiler uses linear search in symbol table.
>
> Actually I use linear searching extensively too. Except in the global
> symbol table which is a hash-table. So lexical lookups use that, but
> resolving a generic identifier into a special one uses linear methods.
>
> Generally it is still very fast because the lists are short. But some
> programs could cause it trouble.
Typically lists are short, except when they are not. Due to inheritance
a single import can pull hundreds of names. And I mentioned that
modules may have parameters which are again modules. Corresponding
interface is automatically imported. So, even though number of
explicit import lines is relatively small, compiler actually pulls
a lot of stuff into symbol table. Also, beside imports also some
compiler internal stuff goes into symbol table. So, length of list
easily goes into low thousends. And compiler makes a lot of searches.
I profiled several compiler runs and typically 45-50% of time goes
into linear search and other 5% goes into hash table access (which
handles majority of cases, but not all). So I _know_ that linear
search take time. Note: I also know that there is huge number
of seaches. Compiler that uses seaches more sparingly could be
much faster (and my improvement eliminated some searches, but
I reached point where deeper change is needed).
>> Getting rid of recursion and implied by this multiple re-compilation
>> probably would give 3-5 times faster compilation (and hopefully
>> would eliminate really bad cases). If things could be simplified
>> so that hash table is enough, that probably would double speed.
>> Once that is handled other things would requre attention. But
>> it does not make much sense to fight for small speedups in other
>> places when biggest issues (that is recursive compilation and
>> linear search are unresolved). And that require substantial
>> rework. Even after rework compiler is unlikly to be as fast as
>> yours. Namely overloading and type inference
>
> So, is type inference (eg. Hindley-Milner) inherently slow?
Hindley-Milner is different story. There are hostile programs
where it can take long time, but in practice it seem to be
reasonably fast. But above main issue is overloading. Consider
simple C expression like:
a = f(1, 2, 3);
In C you will have 1 or 0 symbol table entries for f. If there
is 1 entry, than you check that argument types match and return
type is appriate for assingment to a. Otherwise yoy report error.
Now, let us switch to C++. You may have say 10 symbol table entries
for f and you essentially need to check them all to decide that
any is applicable. And look at more complicated case:
a = f(g(), h(i(), j(k(), l())));
If you have 10 possiblities for f, 10 for g, etc, then naive seach
may have to go trough million combinations to find the right one.
There are smarter approaches than naive recursive search, but
if you have say 10 possibilites on average, than 10 times slowdown
at this stage looks unavoidable. Actually, for single call
average number of possibilites seem to be smaller, but even with
smarter approach it grows for more complicated expressions.
And smarter approach requires more complicated data structures,
so there will be some overhead.
In the sytem I mentioned type inference is in the style of C and C++
'auto' which AFAICS can be pretty cheap for C, basically you take
return type of f as type of a. But type inference means that simple
pruning like only looking at f which have right return type does not
work.
>> Also, compiler is using higher level data structures that
>> has its own costs. Parsing this 215K wc lines takes 1 second,
>> while it should be possible to do this in 0.1 second. But
>> again, before other issues are handled relative gain from
>> faster parser is too small to bother (I may speed up parser
>> if I need to reorganize it to implement some extra feature).
>>
>> BTW: It is hard to compare compile speed in longer time because
>> machines got faster. But when I started my work build needed
>> something like 2.5 hours,
>
> I would never have tolerated that. I considered it part of my job to
> make sure my tools stayed productive whatever the hardware.
I spent nontrivial effort on making compiler faster. But in slightly
different spirit I can say that need for build is not that frequent.
Namely, typical module can be recompiled independently from other
modules and tested. So full build is only needed to initally create
binary and to verify absence of weird interations not cought by
earlier testing. And for creating binaries I developed a process
that used machine independent result of compilation only doing
machine dependent part. Of course, you still needed to run full
build first to build machine independent part. But other folks
could use the result which allowed them faster creation of binaries.
At some stages I used multiple machines, when one machine was
doing build I was doing something else on other machine.
So, I worked on making compiler faster and I developed workarounds
that make slow speed tolarable.
Let me mention that one of speed improvements is quite recent.
I spent semething like 2-3 days to shorten real time of parallel
build from about 60s to 45s (that involves more than compilation,
so is longer than just compile time). Comparing the two things
it seems that I will need about 5000 builds to recover time
that I spent on speeding up the build. Given that I am doing
some hundreds of builds per year, it will take several years
to recover the time. There are other folks doing build and
they will benefit too (but probably less than myself because
with smaller number of cores gain is smaller). But AFAICS in
commercial setting I could not justify time spend on speeding
up build: "present value" of differce between effort and
gain is negative.
>> When I need to look at preprocessed files I frequently see a lot of
>> blank lines, so I am not surprised that headers get smaller. At first
>> glance 4000 lines after preprocessing looks too small, but maybe it
>> is real.
>
> I can tell you that 1/3 of my processing type is to do with comments.
> (After stripping them it took 2/3 as long.) So I might look at how
> efficiently that is done, for a start. But there is a lot of mystery still.
I see.
>>> This output is not enough to use as a new compact header; it will need
>>> #defines etc that have been stripped. But it shows the core of the API
>>> is quite small. I will investigate further.)
>>
>> At some time I did a little work on Mac OS API. There was about
>> 220 tousends symbols, of which something like 200 tousends where
>> various magic constants. So, maybe bulk od SDL3 headers is due
>> to defiend constants?
>
> From the end result (via a tool to convert to my bindings), there are
> about 500 #defines and 1100 enum names. But probably there are lots of
> duplicates in the headers, some may be in 'dead' blocks. And some
> headers are processed more than once.
>
> It's messy, but it seems a big downside of C's 'module' scheme!
>
> And of course, all the work has to be repeated for each file that
> includes SDK.h.
>
>
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-09-15 07:39 +0200 |
| Message-ID | <118almf$15iga$3@dont-email.me> |
| In reply to | #402085 |
I enjoy your extensive posts about modularization and about
your practical reports in the area; very interesting. Thanks.
On 2026-09-15 03:48, Waldek Hebisch wrote:
> bart <bc@freeuk.com> wrote:
[...]
>> I have a lot of experience of dynamic languages that ran at customer
>> sites. Such language errors were extremely rare.
>>
>> It's not that I did extensive testing, but with normal development over
>> a longish time-frame (eg. 1-2 years), you will uncover a lot of bugs!
>
> I would say that normally it is rare to discover such bugs. Simply
> your program happily runs for 20 years and then you suddenly discover
> that some strange but valid input causes a crash.
(I know stories about proud folks who claim to have produced
"error-free" software - because they were just not testing! ;-)
> [...]
>
> IIUC in commercial settings in the past there were tendency to
> disregard such problem ("if customer can not see a problem, then
> software is good enough").
I hope not! Or, to put it in another way; my experience from
"commercial settings" is that if they are doing professional
software development and project management then they have
installed various means of QA. - All the commercial companies
I had worked in - with the exception of a small startup with
only few members in the development area - had such extensive
QA means installed, typically we had also own QA departments.
> [...]
>
>
> At some stages I used multiple machines, when one machine was
> doing build I was doing something else on other machine.
When doing a lot of simulation back then we took advantage of
the distributed workstations. Our processes polled the state
(the actual load) of the various systems, and processes were
spread to run on machines that had free capacities. (The only
"problem" was that there were many in our department who did
such runtime-demanding simulations, but in the end it overall
payed; there's always a few systems being more or less idle.
And the "management effort" was negligible [on Unix].)
> [...]
>
> [...] But AFAICS in
> commercial setting I could not justify time spend on speeding
> up build: "present value" of differce between effort and
> gain is negative.
I'd say this very much depends on the project, and IT management.
While it may be hard to estimate the gains - and the accumulated
losses if you're not optimizing your processes! - we continuously
worked on optimizations. It also motivates the developers; while
the systems grew and got more complex the performance did not (not
necessarily) decrease, but rather got often even better over time.
Janis
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-09-15 11:28 +0100 |
| Message-ID | <118b6k8$2bl0q$1@dont-email.me> |
| In reply to | #402085 |
On 15/09/2026 02:48, Waldek Hebisch wrote: > bart <bc@freeuk.com> wrote: >> I have a lot of experience of dynamic languages that ran at customer >> sites. Such language errors were extremely rare. >> >> It's not that I did extensive testing, but with normal development over >> a longish time-frame (eg. 1-2 years), you will uncover a lot of bugs! > > I would say that normally it is rare to discover such bugs. Simply > your program happily runs for 20 years and then you suddenly discover > that some strange but valid input causes a crash. Errors in a dynamic program would be trapped and reported, rather than cause a crash (unless it was a deeper within the implementation). Then that dynamic module would terminate, but the app was still running and the user could do something else. More common were bugs in the main native code app, and with that in mind, we had an auto-save feature to recover the user's data if those caused a crash, but they may have lost some minutes' work. (Funnily enough, one of my scripting language apps, which was a custom POS system, ran daily for at least 23 years, in an environment with frequent power cuts).) > Let me mention that one of speed improvements is quite recent. > I spent semething like 2-3 days to shorten real time of parallel > build from about 60s to 45s (that involves more than compilation, > so is longer than just compile time). Comparing the two things > it seems that I will need about 5000 builds to recover time > that I spent on speeding up the build. Given that I am doing > some hundreds of builds per year, Per year? I could easily do hundreds of builds per day! Essentially my builds are instant, certainly for my projects of up to 50Kloc where they finish within 0.1s. This is important for whole-program compilation where you can't choose to compile just one modified module. I think for me the costs of those language features - overloading functions and type inference, and what sounds like some kind of inheritance - would be just too high. I wouldn't have them, or would make compromises, or see if I could devise my own solutions. It sounds like you inherited your language.
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2026-09-15 14:54 +0000 |
| Message-ID | <118bm6n$1lt6m$1@paganini.bofh.team> |
| In reply to | #402094 |
bart <bc@freeuk.com> wrote:
> On 15/09/2026 02:48, Waldek Hebisch wrote:
>> bart <bc@freeuk.com> wrote:
>
>>> I have a lot of experience of dynamic languages that ran at customer
>>> sites. Such language errors were extremely rare.
>>>
>>> It's not that I did extensive testing, but with normal development over
>>> a longish time-frame (eg. 1-2 years), you will uncover a lot of bugs!
>>
>> I would say that normally it is rare to discover such bugs. Simply
>> your program happily runs for 20 years and then you suddenly discover
>> that some strange but valid input causes a crash.
>
> Errors in a dynamic program would be trapped and reported, rather than
> cause a crash (unless it was a deeper within the implementation).
>
> Then that dynamic module would terminate, but the app was still running
> and the user could do something else.
By crash I mean that program can not succesfully finish requested
work. It is nice to avoid losing user data, but from user point
of view there is still a crash.
> More common were bugs in the main native code app, and with that in
> mind, we had an auto-save feature to recover the user's data if those
> caused a crash, but they may have lost some minutes' work.
>
> (Funnily enough, one of my scripting language apps, which was a custom
> POS system, ran daily for at least 23 years, in an environment with
> frequent power cuts).)
>
>
>> Let me mention that one of speed improvements is quite recent.
>> I spent semething like 2-3 days to shorten real time of parallel
>> build from about 60s to 45s (that involves more than compilation,
>> so is longer than just compile time). Comparing the two things
>> it seems that I will need about 5000 builds to recover time
>> that I spent on speeding up the build. Given that I am doing
>> some hundreds of builds per year,
>
> Per year? I could easily do hundreds of builds per day!
>
> Essentially my builds are instant, certainly for my projects of up to
> 50Kloc where they finish within 0.1s. This is important for
> whole-program compilation where you can't choose to compile just one
> modified module.
As I wrote, code is incrementally tested. Frequently new code
is interactively tested outside of any module (that is pretty
fast), when it works I change it into a module which is separately
compiled. Only when new module or change to existing one passes
test I do full build.
Technically, with 45s per build I could do few hundreds build a
day. But it is much more efficient to operate as above.
In the past I was teaching programming in Turbo Pascal. I remember
student pressing "compile" key after typing a few characters.
This made some sense, compilation was essentially immediate and
gave feedback, that is presence or absence of syntax errors. But
I can enter somewhat bigger piece of code without making syntax
error (I make a lot of silly errors, but not so much as to compile
every few characters). And incremental compilation is reasonably
fast. Also syntax error are much faster than succesful compilation.
> I think for me the costs of those language features - overloading
> functions and type inference, and what sounds like some kind of
> inheritance - would be just too high. I wouldn't have them, or would
> make compromises, or see if I could devise my own solutions.
Faster compiler probably would speed up my work by few percent. Main
gain probably would be that I could use slower computer. OTOH
I would guesstimate that language features increase productivity
by 50% or more.
> It sounds like you inherited your language.
Yes.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-09-15 21:56 +0100 |
| Message-ID | <118cbd4$2q1i7$1@dont-email.me> |
| In reply to | #402098 |
On 15/09/2026 15:54, Waldek Hebisch wrote: > bart <bc@freeuk.com> wrote: > Technically, with 45s per build I could do few hundreds build a > day. It would take up half your day! But it is much more efficient to operate as above. > > In the past I was teaching programming in Turbo Pascal. I remember > student pressing "compile" key after typing a few characters. > This made some sense, compilation was essentially immediate and > gave feedback, that is presence or absence of syntax errors. But > I can enter somewhat bigger piece of code without making syntax > error (I make a lot of silly errors, but not so much as to compile > every few characters). And incremental compilation is reasonably > fast. Also syntax error are much faster than succesful compilation. Smart editors will now do doing parsing etc to give instant feedback and to automate code layout. A different parser from that of a compiler, to cope with incomplete code fragments. (I don't use a smart editor...) >> I think for me the costs of those language features - overloading >> functions and type inference, and what sounds like some kind of >> inheritance - would be just too high. I wouldn't have them, or would >> make compromises, or see if I could devise my own solutions. > > Faster compiler probably would speed up my work by few percent. Main > gain probably would be that I could use slower computer. OTOH > I would guesstimate that language features increase productivity > by 50% or more. So you've adapted to what you have and learned how to work effectively with it. But suppose, somehow, a full build of your whole application could be done in zero time or near enough. You wouldn't need parallel processing. You wouldn't have to bother with incremental compilation. You wouldn't have to set up isolated tests in order to have smaller, faster-to-build programs. Your way of working would change. This is pretty much how it works with dynamic languages that are run from source. And some are using JIT methods on static languages (although tricky language features could still affect the front-end compiler). I think that is generally considered to be a productive approach.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-09-15 21:34 +0000 |
| Message-ID | <_RiqS.2$GI1.0@fx01.iad> |
| In reply to | #402104 |
bart <bc@freeuk.com> writes: >On 15/09/2026 15:54, Waldek Hebisch wrote: >> bart <bc@freeuk.com> wrote: >But suppose, somehow, a full build of your whole application could be >done in zero time or near enough. Figure out how to build linux (a C application) in zero time and get back to us.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-09-16 00:36 +0100 |
| Message-ID | <118ckqn$2t37a$1@dont-email.me> |
| In reply to | #402105 |
On 15/09/2026 22:34, Scott Lurndal wrote: > bart <bc@freeuk.com> writes: >> On 15/09/2026 15:54, Waldek Hebisch wrote: >>> bart <bc@freeuk.com> wrote: > >> But suppose, somehow, a full build of your whole application could be >> done in zero time or near enough. > > > Figure out how to build linux (a C application) in zero time and get back to us. > WH's application is some 200K lines; something of that size would be feasible. Here for example is SQLite3 run from source: c:\cx>cc -i sql Compiling sql.c to sql.(int) SQLite version 3.25.3/MCC 2018-11-05 20:37:38 Enter ".help" for usage hints. Connected to a transient in-memory database. Use ".open FILENAME" to reopen on a persistent database. sqlite> With -i (interpret) it takes 0.15 seconds to get from source to here. With -r (compile to native) it takes 0.25 seconds. This is a 250Kloc C program on a slow machine. However my remark was hypothetical: how would development habits change if that was the case?
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2026-09-16 02:21 +0000 |
| Message-ID | <118cufj$1tacb$1@paganini.bofh.team> |
| In reply to | #402104 |
bart <bc@freeuk.com> wrote:
> On 15/09/2026 15:54, Waldek Hebisch wrote:
>> bart <bc@freeuk.com> wrote:
>
>> Technically, with 45s per build I could do few hundreds build a
>> day.
>
> It would take up half your day!
One could do something useful during build. Or simply check for
Usenet news.
>>> I think for me the costs of those language features - overloading
>>> functions and type inference, and what sounds like some kind of
>>> inheritance - would be just too high. I wouldn't have them, or would
>>> make compromises, or see if I could devise my own solutions.
>>
>> Faster compiler probably would speed up my work by few percent. Main
>> gain probably would be that I could use slower computer. OTOH
>> I would guesstimate that language features increase productivity
>> by 50% or more.
>
> So you've adapted to what you have and learned how to work effectively
> with it.
>
> But suppose, somehow, a full build of your whole application could be
> done in zero time or near enough.
>
> You wouldn't need parallel processing. You wouldn't have to bother with
> incremental compilation. You wouldn't have to set up isolated tests in
> order to have smaller, faster-to-build programs.
>
> Your way of working would change.
Probably not that much. Normally at any given time I work on a single
module or a few. For me it is convenient to have all working files
in a single directory. I do not want to clutter this directory with
other files. So if system did not support incremental compilation
I would probably need to emulate it so that compiling a single file
would pick other sources from system directory.
Also, you samewhat ignore testing. Significant point with incremental
compilation is that my test state (date held in variables, helper
functions) survive compilation of modified file, so I can immediately
go back to testing.
One more thing: there are also C sources in the system (about 50000
lines). Currently C compilation is fast enough (and in paralle build
partially overlaps with other things), but even if other code compiled
in zero time, there still would be time taken by C compilation.
> This is pretty much how it works with dynamic languages that are run
> from source. And some are using JIT methods on static languages
> (although tricky language features could still affect the front-end
> compiler).
My developement work mostly is like in dynamic language. Some
modules need several seconds to compile, but most compile in a
fraction of second. I see that compilation is not instanteous,
but with exception of few offenders it is fast enough.
> I think that is generally considered to be a productive approach.
Sure. AFAICS I have most benefits of working with dynamic
language. Main difference is compile time type checking, which
for me is a benefit (but many folks in dynamic camp dislike it).
Also, I get adequate speed at runtime, unlike some systems that
relay on interpretation. And runtime speed matters for developement,
as some test cases need long time (image waiting 30 minutes to
see effect of a bug).
BTW. I also work with a different system, which is capable of compiling
about 100000 (maybe more, there are include files and and it requires
some effort to determine what exactly is compiled) lines per second in
fastest mode. This does not change much how I work. Actually, one
difference is that the second system is capable of compiling each
function separately and I sometimes take advantage of this. Maybe
bigger difference is that normally the second system compiles to memory.
One can dump memory and reload later, but one can not do independent
compilation in this way. So for smaller files I just keep them
in source form, they are freashly compiled for each run. There is
a different mode, which compiles to assembler which is assembled and
linked in almost conventional way, but it is slower (closer to 30000
lines per second). For this system build of core system takes about
15 seconds (nontrivial part of which is indexing documentation). Note:
this is serial build on a single core. There is also an extention
providing image manipulation. This uses C file having few hundred
lines, this file takes another 15 seconds to compile using GCC. But
it is worth the time, GCC nicely vectorises the code considerably
speeding up graphic operations.
BTW2: I have pretty fast Modula-2 to C convertor. Theoretically
I could couple it with Tiny C to get pretty fast Modula-2
compiler. But in practice, for my use most of the time GCC is
fast enough.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-09-16 09:08 +0200 |
| Message-ID | <118df8i$33686$1@dont-email.me> |
| In reply to | #402104 |
On 15/09/2026 22:56, bart wrote: > So you've adapted to what you have and learned how to work effectively > with it. > You are forever trying to claim that this is somehow a bad thing. Most of us regulars here in comp.lang.c are not omnipotent, nor do we have unlimited time. We prefer to spend our time and effort on particular focused tasks - usually the tasks we get paid to do, or alternatively the tasks we enjoy doing. We cannot do /everything/ - there is not the time. I'm sure most of us, deep down, know that we could write a better C compiler than gcc or clang, and design a better language than C. But we don't have the time or inclination. We don't have the need. The tools that exist already do the job we need. We find convenient ways to make the whole process more efficient, and get on with the programming we actually want to do. (And we don't have to look far to find these methods - millions of developers use build systems and decent editors. We are not teenagers with a ZX Spectrum in our bedrooms, we are professionals who use professional tools.) What do you really want people here to do? Should we intentionally make our lives difficult by doing serial clean rebuilds all the time, and use MS Notepad as an editor, just so that we too can feel the pain and suffering you feel? Should we stop all our work, give up our jobs, and write our own C compilers? Should we spend have our life whining and moaning in Usenet groups and other online forums about how terrible C is and how bad compilers are, complaining to people who have no influence over any of it and can work fine with the language and tools? Or do you want us to bow down to you and exclaim our undying admiration for your language and compilers? I presume you are not interested in hearing that we too would be happy if compilers were faster, or that we too think that C has quirks, oddities, and aspects that we would prefer were different - if so, you'd have switched the broken record a couple of decades ago. So what would actually make you /happy/ here, and would let you change the subject?
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-09-16 11:21 +0100 |
| Message-ID | <118dqj9$39ode$1@dont-email.me> |
| In reply to | #402115 |
On 16/09/2026 08:08, David Brown wrote: > On 15/09/2026 22:56, bart wrote: > >> So you've adapted to what you have and learned how to work effectively >> with it. >> > > You are forever trying to claim that this is somehow a bad thing. > > Most of us regulars here in comp.lang.c are not omnipotent, nor do we > have unlimited time. We prefer to spend our time and effort on > particular focused tasks - usually the tasks we get paid to do, or > alternatively the tasks we enjoy doing. > > We cannot do /everything/ - there is not the time. I'm sure most of us, > deep down, know that we could write a better C compiler than gcc or > clang, and design a better language than C. > > But we don't have the time or inclination. We don't have the need. The > tools that exist already do the job we need. We find convenient ways to > make the whole process more efficient, and get on with the programming > we actually want to do. (And we don't have to look far to find these > methods - millions of developers use build systems and decent editors. > We are not teenagers with a ZX Spectrum in our bedrooms, we are > professionals who use professional tools.) > > What do you really want people here to do? Should we intentionally make > our lives difficult by doing serial clean rebuilds all the time, and use > MS Notepad as an editor, just so that we too can feel the pain and > suffering you feel? Should we stop all our work, give up our jobs, and > write our own C compilers? Should we spend have our life whining and > moaning in Usenet groups and other online forums about how terrible C is > and how bad compilers are, complaining to people who have no influence > over any of it and can work fine with the language and tools? > > Or do you want us to bow down to you and exclaim our undying admiration > for your language and compilers? No. But you don't need actively dislike them either or be so patronising about them. My language is probably the nearest to C in this class and level of language, while also being very different in look and feel. It would be foolish to just dismiss it. > > I presume you are not interested in hearing that we too would be happy > if compilers were faster, or that we too think that C has quirks, > oddities, and aspects that we would prefer were different - if so, you'd > have switched the broken record a couple of decades ago. > > So what would actually make you /happy/ here, and would let you change > the subject? What I would like is for somebody to actually admit that there might be a problem instead of just brushing it under the carpet. What I would like is to know that there is somebody out there who is keeping on top of inefficiencies and checking that a simple task doesn't take an inordinate and disproportionate amount of resources to do. I'm not saying that /you/ should do it or most who post here. You are just the users who have to work with what's available, eg. by applying more hardware resources and more ingenuity. Even WH has said they have worked at improving the throughput of their tools (although that was not for C). The recent example of those SDL3 headers is a good one. Even without needing to change the C language, or have super-fast compilers for it, those headers are grossly inefficient. That is something that could be partly be tackled by the people who distribute the header files, but more could also be done by those who create the tools. For example: * There are 86 files/82K lines of headers, counted statically, but nearly 500 dynamic #includes are done, scanning or skipping over half a million lines of declarations * Yet they contain only about 4000 lines of actual information necessary to compile a program that uses that library. This is 1% of the lines that are scanned. * For a start, half the source is comments. Why are comments even needed for a header meant to be consumed by machine? There are surely separate docs! If they are for the SDL3 developers, then somebody using the library *is not the developer*! * There are thousands of /static/ conditional blocks (and a lot more encountered dynamically) all testing the same invariants over and over again. For example, once it is established that the compiler is not __MSCVER__, you don't need to test that (and to skip over blocks only relevant to that platform) 100 more times. So this could be done by recognising that a compact, streamlined API, dedicated to a particular platform (and maybe compiler) would be far better. But because that would mean many versions (more than the number of DLLs/.sos for different targets for example), this sounds like a compiler task. Most compilers already have an -E option to generate preprocessed source code. What is needed is say a -H option which does not discard information that a compiler still needs, if using an AOT-preprocessed header. Mostly this will be #defines. So it would not be too difficult. (Just tricky as SDL3 uses lots of #undefines too.) Maybe you don't think this is interesting or relevant or you think it is a waste of time. But if someone decided to add this to your favourite compiler I bet you would use it! In this case, it would reduce header code that needs to be processed /per module/, by some 99%, not 95%. Note that this is the same sort of principle as gcc's precompiled headers. But that doesn't simplify the headers at all; just pre-tokenises or something. The 3.6MB of SDL3 headers turn into one giant 30MB file. My approach would reduce them to one file of perhaps 0.2MB.
[toc] | [prev] | [next] | [standalone]
Page 12 of 25 — ← Prev page 1 … 10 11 [12] 13 14 … 25 Next page →
Back to top | Article view | comp.lang.c
csiph-web