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 6 of 25 — ← Prev page 1 … 4 5 [6] 7 8 … 25 Next page →
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-09-10 13:09 +0100 |
| Message-ID | <117u6m6$1vh8g$1@dont-email.me> |
| In reply to | #401867 |
On 10/09/2026 07:45, Janis Papanagnou wrote:
> On 2026-09-10 00:30, bart wrote:
>> On 09/09/2026 22:26, Janis Papanagnou wrote:
>>> [...]
>>>
>>> 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?
>
> The advantages of _modularity_ are for example to structure entities
> that may be typically used together or to restrict yourself to the
> subset of what you actually need.
OK, that's modules. A module should already define the subset of its
entities that are exported.
> (Neither an "include all" nor an
> "include value_x_of_y" are usually sensible choices!) - You may want
> to inspect the various options you have in other languages (inspect,
> just for example, Java - beyond any personal liking of that language).
This is the language that looks like this:
public class HelloWorld {
public static void main(String[] args) {
System.out.println("Hello, World");
}
}
Whereas mine looks like so:
proc main =
println "Hello, World"
end
26 tokens versus 6 tokens. My comments are to do with minimising clutter
- and also maintenance - when using a modules scheme, so this is not a
good model!
>>
>> Is even the pain of having to do '#include <string.h>' not enough when
>> your code uses string functions, you would prefer to list them
>> individually too?!
>
> No. What makes you think so? (And it is also no "pain" for me, BTW.)
So you enjoy the dance of writing 'printf', 'strcmp' etc and having to
interrupt your train of thought, go to the top of the module to write
the necessary include, then get back to where you where?
> But if all I need from the string class is, say, strcmp() then it is
> completely sensible to be able to include just that.
And here you want to make it even worse, by needing to do that dance for
the dozens of individual functions you might need instead of just that
handful of headers.
With C, you do #include <GTK.h>, and you instantly have the names of
10,000 functions, types, variables, macros, and enums invading your
module scope, but that is apparently fine.
> If it turns out that I need more I can include the whole "tool-chest"
> (unless I get name clashes that a specific import would prevent).
I can understand this in Python, where there is no export control: every
top-level name in a module would be visible to the importer.
But usually module schemes include such control.
> Ideally you may control the import level (all, or selected items) to
> your needs.
This is the key thing. I've already seen that when using only modules to
control what is or isn't imported, it was an imposition to have to
specify the same thing in every module. So module A may import B, C, F,
while B imports A, C, F, H, while C includes ....
That resulted in what to me was an anti-pattern.
But, you want to make it even worse, but having possible a hundred
things you need to specify in EVERY MODULE.
And then one day, you decide to refactor a module into two modules, and
now each will need a different subset of that 100.
BTW what happens if you import a function which is not used; will the
language complain? If not, then what was the point of specifying imports
to that level of granularity?
> For example; my recent Algol 68 option parser defines the necessary
> types and the (exported) function to handle the options. (All other
> internally used functions are hidden.) Or my array shuffler function
> uses a swap operator, but since that is useful also generally I have
> it visible in the module for use. In an encryption module I have the
> functions to create the subkey-sequence, the encryption/decryption
> functions, data types resembling the entities you use with these
> functions (e.g. 64-bit and 56-bit integrals). - So these facilities
> provide all the _necessary_ in one module each. But there may also
> be tool-chests-like modules;
Does Algol68 have such a feature? Does it even have modules?!
> and in this case you may prefer to just
> pick the requested entities if the subset is small.
The tool-chest module will usually still be loaded or statically
compiled as a whole even if you only want part.
In that case, if you want to use a specific export from it, what is the
point, or benefit, of needing to explicitly name that export?
And why can't the 'picking' be inferred from the act of calling or using
that export?
(In the AS assembler, if you want to import function 'puts', say, then
you just use that name. If not defined in the file, it assumes it is
imported.
In my AA assembler, the name is written as 'puts*' to mark it as
imported. Assemblers like NASM or MASM however require all imported
symbols to be declared first. But, this is assembly, not a HLL!)
> - For example my
> ansi-controls module is a huge collection of functions; I'd like to
> just pick the 5 or 6 functions I'm needing (but with the language I'm
> using I can only pick an include file as a whole; unless I split the
> functions myself in sub-groups - good that we spoke about that; I'll
> probably do that to separate the colors at least - anyway there's a
> lot of entries that I'd prefer not to pollute my name space).
Are there not namespaces that will contain those imported names?
> Note also that languages may provide structuring means that allow an
> own level of modularization. Consider for example the object oriented
> languages where you collect things that belong together in classes.
>
> BTW, you may want to consider reading more about modularity; B. Meyer
> has an introductory small chapter about aspects in his "OO Software
> Development" book. (I'm sure there's plenty other resources.) You can
> also search the Web on principles and advantages including control of
> modularization.
I've worked with quite a few module schemes of my own so have a lot of
experience or what works and what doesn't. My current one is so far the
best for my purposes. If I want to add a simple library function, then I
might write it like this:
global func factorial(int n)int =
....
end
I write that in a source file called mylib.m say. To use it in my
application, I add this line to its lead module:
module mylib
And, that's it! All modules of my app can now call factorial(). They
don't even need to write mylib.factorial() unless there's a clash. And I
don't need to separately compile mylib.m - this is whole program
compilation, it's done automatically.
(There's bit more to it because I have a 2-level structure, but that's
pretty much it for the body of the app.)
I really doubt whether those links can improve matters. I want
modularisation without any of the headaches.
>
>> An enumeration set may have hundreds of names; do you have to list all
>> of them? That would be insane.
>
> Yes, that would be insane. - How do you manage it to breed such absurd
> ideas?!
An enumeration name is an identifier like any other, that could
conceivably 'pollute' your name space. So, if selective imports are
allowed, why wouldn't they apply here too?
>> You might as well put each entity into its own module, and have a
>> subset of 1000 modules to manage instead - in each of the 1000 functions.
>
> Why would you do that? I wouldn't. - You completely missed the point.
It would be just as stupid. (But I've seen projects like this, with
hundreds of source files, then you discover that the whole project is
only about 2Kloc!)
>
>>
>> You people seem to like making life difficult. Well, go ahead!
>
> Nonsense. - You seem to be stubbornly focused on some "idee fixe" you
> have, incapable of evading your own mental cage.
I don't like the idea of micromanaging imports an identifier at a time.
You've spent your whole post defending that, while also stressing it is
optional.
Well, I don't even want it as an option!
I'm against needing declarations at all, except the absolute minimum.
And selecting imports are declarations.
> But that's also not that "simple" or clear as you pretend. - Consider
> for example C++ with its stream output; would you really write as in
> this _simple_ example - there's yet more common things with streams,
> like standard-modifiers (e.g. std::oct, std:: setw()) that may often
> complicate the expression WRT legibility! - always 'std::' like
>
> std::cout << "hello world" << std::endl;
>
> or prefer an extensive all-is-the-least-"burden" directive
>
> using std;
>
> and for all the many output commands just the better legible
>
> cout << "hello world" << endl;
C++ is an even worse role model than Java. That cout example is only
marginally better than the version with std::. I like no-nonsense code
that looks like this:
println "hello world"
>
> The point is that you should have the possibility to modularize, and
> to control it.
The modularisation is there, but this isn't really controlling it. It's
not the like the name you are importing is Private; it will be Public or
Global.
You're just adding a pointless barrier to it in the importing module.
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2026-09-10 14:37 +0200 |
| Message-ID | <117u89j$202t7$1@dont-email.me> |
| In reply to | #401874 |
bart pisze:
> public class HelloWorld {
> public static void main(String[] args) {
> System.out.println("Hello, World");
> }
> }
>
> Whereas mine looks like so:
>
> proc main =
> println "Hello, World"
> end
in c it would be
main() printf("Hello, World");
if they would allow skkip {}
main() { printf("Hello, World"); }
in this short cases like it is in ifs
in my proto-extended-c i compile it is
main { printf "Hello, World" }
it is from this compiled example (this void i should remove some way
but it was under work and im not touching it recently)
void ProcessMouseMove mouse_x mouse_y { }
void OnResize { RunFrame }
void main
{
RegisterMouseMove &ProcessMouseMove
RegisterKeyDown &ProcessKeyDown
RegisterOnResize &OnResize
RegisterRunFrame &RunFrame
SetSleepValue 5, SetScaleOnResize 0, Set3dDrawingMode 1
SetupWindow4 " Example Green Fire App compiled by Furia \x00"
20 20 0.9 0.9 600
}
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2026-09-10 15:11 +0200 |
| Message-ID | <117ua9l$20r2m$1@dont-email.me> |
| In reply to | #401875 |
fir pisze:
> bart pisze:
>
>> public class HelloWorld {
>> public static void main(String[] args) {
>> System.out.println("Hello, World");
>> }
>> }
>>
>> Whereas mine looks like so:
>>
>> proc main =
>> println "Hello, World"
>> end
>
>
> in c it would be
>
> main() printf("Hello, World");
>
> if they would allow skkip {}
>
> main() { printf("Hello, World"); }
>
> in this short cases like it is in ifs
>
> in my proto-extended-c i compile it is
>
> main { printf "Hello, World" }
>
> it is from this compiled example (this void i should remove some way
> but it was under work and im not touching it recently)
>
> void ProcessMouseMove mouse_x mouse_y { }
>
>
> void OnResize { RunFrame }
> void main
> {
> RegisterMouseMove &ProcessMouseMove
> RegisterKeyDown &ProcessKeyDown
> RegisterOnResize &OnResize
> RegisterRunFrame &RunFrame
> SetSleepValue 5, SetScaleOnResize 0, Set3dDrawingMode 1
> SetupWindow4 " Example Green Fire App compiled by Furia \x00"
> 20 20 0.9 0.9 600
>
> }
>
>
>
this void is beoouse i must denote definition and yet has no idea
from this gemeral bara naked function all conventios im quite happy
gere function calls i name "logical lines" as compiler just breaks
lines on logical lines on newline or ","
so
void main
{
SetSleepValue 5
SetScaleOnResize 0
Set3dDrawingMode 1
SetupWindow4 " Example Green Fire App compiled by Furia \x00"
20 20 0.9 0.9 600
}
ise the same as
void main
{
SetSleepValue 5, SetScaleOnResize 0, Set3dDrawingMode 1,
SetupWindow4 " Example Green Fire App compiled by Furia \x00"
20 20 0.9 0.9 600
}
also blocks may be instead of form {a,b,c,d,e} be a,b,c,d,e;
so above may be
void main
SetSleepValue 5, SetScaleOnResize 0, Set3dDrawingMode 1,
SetupWindow4 " Example Green Fire App compiled by Furia \x00"
20 20 0.9 0.9 600 ;
as fay as i remember (im not sure right now if function ending sign i
chose as ";" "." ";." or smthe (possibly it need to be something like ;.
but it yet is not decided
there also may be optional :
void main: SetSleepValue 5, SetScaleOnResize 0, Set3dDrawingMode 1,
SetupWindow4 " Example Green Fire App compiled by Furia \x00"
20 20 0.9 0.9 600;
i emen is optional if after definition header there is newline
those things are somewhat clear (maybe this ending function if there is
no {} is not cleer but other seem clear
but many things are yet not resolved (like if statements or even im not
sure as to assigments, for loops -s till not chosen
but the bare naked form of function calls is imo impressive
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2026-09-10 15:16 +0200 |
| Message-ID | <117uaik$20ote$1@dont-email.me> |
| In reply to | #401877 |
fir pisze:
> fir pisze:
>> bart pisze:
>>
>>> public class HelloWorld {
>>> public static void main(String[] args) {
>>> System.out.println("Hello, World");
>>> }
>>> }
>>>
>>> Whereas mine looks like so:
>>>
>>> proc main =
>>> println "Hello, World"
>>> end
>>
>>
>> in c it would be
>>
>> main() printf("Hello, World");
>>
>> if they would allow skkip {}
>>
>> main() { printf("Hello, World"); }
>>
>> in this short cases like it is in ifs
>>
>> in my proto-extended-c i compile it is
>>
>> main { printf "Hello, World" }
>>
>> it is from this compiled example (this void i should remove some way
>> but it was under work and im not touching it recently)
>>
>> void ProcessMouseMove mouse_x mouse_y { }
>>
>>
>> void OnResize { RunFrame }
>> void main
>> {
>> RegisterMouseMove &ProcessMouseMove
>> RegisterKeyDown &ProcessKeyDown
>> RegisterOnResize &OnResize
>> RegisterRunFrame &RunFrame
>> SetSleepValue 5, SetScaleOnResize 0, Set3dDrawingMode 1
>> SetupWindow4 " Example Green Fire App compiled by Furia
>> \x00" 20 20 0.9 0.9 600
>>
>> }
>>
>>
>>
> this void is beoouse i must denote definition and yet has no idea
>
>
> from this gemeral bara naked function all conventios im quite happy
>
> gere function calls i name "logical lines" as compiler just breaks
> lines on logical lines on newline or ","
>
> so
>
> void main
> {
> SetSleepValue 5
> SetScaleOnResize 0
> Set3dDrawingMode 1
> SetupWindow4 " Example Green Fire App compiled by Furia \x00"
> 20 20 0.9 0.9 600
>
> }
>
> ise the same as
>
> void main
> {
> SetSleepValue 5, SetScaleOnResize 0, Set3dDrawingMode 1,
> SetupWindow4 " Example Green Fire App compiled by Furia \x00"
> 20 20 0.9 0.9 600
>
> }
> also blocks may be instead of form {a,b,c,d,e} be a,b,c,d,e;
>
> so above may be
>
> void main
> SetSleepValue 5, SetScaleOnResize 0, Set3dDrawingMode 1,
> SetupWindow4 " Example Green Fire App compiled by Furia \x00"
> 20 20 0.9 0.9 600 ;
>
>
> as fay as i remember (im not sure right now if function ending sign i
> chose as ";" "." ";." or smthe (possibly it need to be something like ;.
> but it yet is not decided
or maybe it was ";;" as an end - probably this should be just some
unicode sign as ending function definition denoter (even something like
small/medium rectangle ) but im trying to go as far in this syntax
thining and cleaning as far as i can go
>
> there also may be optional :
>
> void main: SetSleepValue 5, SetScaleOnResize 0, Set3dDrawingMode 1,
> SetupWindow4 " Example Green Fire App compiled by Furia \x00"
> 20 20 0.9 0.9 600;
>
> i emen is optional if after definition header there is newline
>
> those things are somewhat clear (maybe this ending function if there is
> no {} is not cleer but other seem clear
>
> but many things are yet not resolved (like if statements or even im not
> sure as to assigments, for loops -s till not chosen
>
>
> but the bare naked form of function calls is imo impressive
>
>
>
>
>
>
>
>
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2026-09-10 15:28 +0200 |
| Message-ID | <117ubaa$216kk$1@dont-email.me> |
| In reply to | #401878 |
fir pisze:
> fir pisze:
>> fir pisze:
>>> bart pisze:
>>>
>>>> public class HelloWorld {
>>>> public static void main(String[] args) {
>>>> System.out.println("Hello, World");
>>>> }
>>>> }
>>>>
>>>> Whereas mine looks like so:
>>>>
>>>> proc main =
>>>> println "Hello, World"
>>>> end
>>>
>>>
>>> in c it would be
>>>
>>> main() printf("Hello, World");
>>>
>>> if they would allow skkip {}
>>>
>>> main() { printf("Hello, World"); }
>>>
>>> in this short cases like it is in ifs
>>>
>>> in my proto-extended-c i compile it is
>>>
>>> main { printf "Hello, World" }
>>>
>>> it is from this compiled example (this void i should remove some way
>>> but it was under work and im not touching it recently)
>>>
>>> void ProcessMouseMove mouse_x mouse_y { }
>>>
>>>
>>> void OnResize { RunFrame }
>>> void main
>>> {
>>> RegisterMouseMove &ProcessMouseMove
>>> RegisterKeyDown &ProcessKeyDown
>>> RegisterOnResize &OnResize
>>> RegisterRunFrame &RunFrame
>>> SetSleepValue 5, SetScaleOnResize 0, Set3dDrawingMode 1
>>> SetupWindow4 " Example Green Fire App compiled by Furia
>>> \x00" 20 20 0.9 0.9 600
>>>
>>> }
>>>
>>>
>>>
>> this void is beoouse i must denote definition and yet has no idea
>>
>>
>> from this gemeral bara naked function all conventios im quite happy
>>
>> gere function calls i name "logical lines" as compiler just breaks
>> lines on logical lines on newline or ","
>>
>> so
>>
>> void main
>> {
>> SetSleepValue 5
>> SetScaleOnResize 0
>> Set3dDrawingMode 1
>> SetupWindow4 " Example Green Fire App compiled by Furia \x00"
>> 20 20 0.9 0.9 600
>>
>> }
>>
>> ise the same as
>>
>> void main
>> {
>> SetSleepValue 5, SetScaleOnResize 0, Set3dDrawingMode 1,
>> SetupWindow4 " Example Green Fire App compiled by Furia \x00"
>> 20 20 0.9 0.9 600
>>
>> }
>> also blocks may be instead of form {a,b,c,d,e} be a,b,c,d,e;
>>
>> so above may be
>>
>> void main
>> SetSleepValue 5, SetScaleOnResize 0, Set3dDrawingMode 1,
>> SetupWindow4 " Example Green Fire App compiled by Furia \x00"
>> 20 20 0.9 0.9 600 ;
>>
>>
>> as fay as i remember (im not sure right now if function ending sign i
>> chose as ";" "." ";." or smthe (possibly it need to be something like ;.
>> but it yet is not decided
>
>
> or maybe it was ";;" as an end - probably this should be just some
> unicode sign as ending function definition denoter (even something like
> small/medium rectangle ) but im trying to go as far in this syntax
> thining and cleaning as far as i can go
>
>
>>
>> there also may be optional :
>>
>> void main: SetSleepValue 5, SetScaleOnResize 0, Set3dDrawingMode 1,
>> SetupWindow4 " Example Green Fire App compiled by Furia \x00"
>> 20 20 0.9 0.9 600;
>>
>> i emen is optional if after definition header there is newline
>>
>> those things are somewhat clear (maybe this ending function if there
>> is no {} is not cleer but other seem clear
>>
>> but many things are yet not resolved (like if statements or even im
>> not sure as to assigments, for loops -s till not chosen
>>
>>
>> but the bare naked form of function calls is imo impressive
>>
>>
>>
>>
>>
as forr my assigment ideas the last one i remember was
_a 344
thsi is initialisation
a_ 3344
this is assigment (maybe some unicode coud be chosen instead)
_x you read "let x" so _x 6 is "let x 6"
x_ y+3 //x=y+3
but im not sure as to dis it looks quite dymanic but the problem is for
floats/chars etc
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-09-10 14:33 +0100 |
| Message-ID | <117ubie$21a6f$1@dont-email.me> |
| In reply to | #401875 |
On 10/09/2026 13:37, fir wrote:
> bart pisze:
>
>> public class HelloWorld {
>> public static void main(String[] args) {
>> System.out.println("Hello, World");
>> }
>> }
>>
>> Whereas mine looks like so:
>>
>> proc main =
>> println "Hello, World"
>> end
>
>
> in c it would be
>
> main() printf("Hello, World");
In C it would be:
#include <stdio.h>
int main(void) {
printf("Hello, World\n");
}
From C23, you can get rid of the 'void' (you can do that now, but it
has a different meaning).
>
> if they would allow skkip {}
>
> main() { printf("Hello, World"); }
>
> in this short cases like it is in ifs
>
> in my proto-extended-c i compile it is
>
> main { printf "Hello, World" }
>
> it is from this compiled example (this void i should remove some way
> but it was under work and im not touching it recently)
>
> void ProcessMouseMove mouse_x mouse_y { }
C generally has too much punctuation, but you can also have too little!
Your example doesn't specify parameter types for example. With those in
place, then you can have syntax that looks like:
A B C D E F {}
A is the return type (a user-defined type); B is the function name; D is
a parameter of type C; and F is a parameter of type F. There is little
structure.
Further, if this is a function all:
F G H I J
Then you don't know if this means F(G, H, I, J), or F (G, H(I), J) etc.
Some languages manage it but it needs very careful design and a set of
rules.
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2026-09-10 15:51 +0200 |
| Message-ID | <117uck7$21mg2$1@dont-email.me> |
| In reply to | #401880 |
bart pisze:
> On 10/09/2026 13:37, fir wrote:
>> bart pisze:
>>
>>> public class HelloWorld {
>>> public static void main(String[] args) {
>>> System.out.println("Hello, World");
>>> }
>>> }
>>>
>>> Whereas mine looks like so:
>>>
>>> proc main =
>>> println "Hello, World"
>>> end
>>
>>
>> in c it would be
>>
>> main() printf("Hello, World");
>
> In C it would be:
>
> #include <stdio.h>
>
> int main(void) {
> printf("Hello, World\n");
> }
>
> From C23, you can get rid of the 'void' (you can do that now, but it
> has a different meaning).
>
>
>>
>> if they would allow skkip {}
>>
>> main() { printf("Hello, World"); }
>>
>> in this short cases like it is in ifs
>>
>> in my proto-extended-c i compile it is
>>
>> main { printf "Hello, World" }
>>
>> it is from this compiled example (this void i should remove some way
>> but it was under work and im not touching it recently)
>>
>> void ProcessMouseMove mouse_x mouse_y { }
>
> C generally has too much punctuation, but you can also have too little!
>
> Your example doesn't specify parameter types for example. With those in
> place, then you can have syntax that looks like:
>
> A B C D E F {}
>
> A is the return type (a user-defined type); B is the function name; D is
> a parameter of type C; and F is a parameter of type F. There is little
> structure.
>
well im still working on that (now having longer break) and
yet i used only ints (so i quiess i should ay i work on new b not new c ;c)
but as far as i remember the above in my case would be
A B C D E F {}
A is a function name and B C D E F are ints (so you see its rather clear)
it would not compile in my compiler ("furia") as i need this first
keyword to denote global definitioons
BTW i compiled also such examples (it compilers and works afair but is
still undef construction so its under future changes)
def ProcessMouseMove mouse_x mouse_y.
def foo z1 z2 z3 z4:
printf " %d %d %d %d \x00" z1 z2 z3 z4.
def AddBackgrounColor zzz
x = rand2 1 2, background_color += x .
def goo z1 z2 z3 -> z4 z5 z6
{z4=z1+z2, z5=z2+z3, z6=z3+z1}
def doo
{a b c=goo 2 3 4, printf " a %d b %d c %d \x00" a b c }
it was before my later conclusions to not use = as assigment
and alos my recent ones (not yet tested) to use what i call "hypothesis"
as an if without any sign
def main
{
_x 3
x>2 print "x is above 2"
x>2 print "x is above 2"
x>2 { print "x is above 2" }
}
> Further, if this is a function all:
>
> F G H I J
>
> Then you don't know if this means F(G, H, I, J), or F (G, H(I), J) etc.
>
> Some languages manage it but it needs very careful design and a set of
> rules.
>
>
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2026-09-10 16:03 +0200 |
| Message-ID | <117udar$21uj4$1@dont-email.me> |
| In reply to | #401880 |
bart pisze: > Further, if this is a function all: > > F G H I J > > Then you don't know if this means F(G, H, I, J), or F (G, H(I), J) etc. this is not a problem in my bare-naked forms tuday as it would be F G (H I) J then you see F is function all that takes 3 args and H is a function call that takes one so this seem totally no problem, but types in headers what you mention earlier is a problem..but for now as i sait i only work on "new B" who knows mayne i should call this language as B i know there is a language b but maybe it is lowercase ba and i could use bigcase B ;c
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-09-10 15:27 +0100 |
| Message-ID | <117ueoe$22fm9$1@dont-email.me> |
| In reply to | #401882 |
On 10/09/2026 15:03, fir wrote:
> bart pisze:
>> Further, if this is a function all:
>>
>> F G H I J
>>
>> Then you don't know if this means F(G, H, I, J), or F (G, H(I), J) etc.
>
> this is not a problem in my bare-naked forms tuday as
>
> it would be
>
> F G (H I) J
>
> then you see F is function all that takes 3 args and H is a function
> call that takes one
That makes it too strict. C has variadic functions. Some languages have
optional arguments with default values. Some languages are dynamically
types so you don't know at compile-time (and the reader can't tell) how
many arguments F takes.
> so this seem totally no problem,
Try it with a real example, such as:
succeeded = tdefl_init pComp pPut_buf_func pPut_buf_user flags
== TDEFL_STATUS_OKAY ;
succeeded = succeeded && tdefl_compress_buffer pComp pBuf
buf_len TDEFL_FINISH == TDEFL_STATUS_DONE
These have had parentheses and commas removed. There is also this:
F G H I + J
Even if you know that F takes two arguments, and H takes one, which of
these is the intended meaning:
F(G, H(I) + J)
F(G, H(I)) + J
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2026-09-10 16:45 +0200 |
| Message-ID | <117ufr0$22qm7$2@dont-email.me> |
| In reply to | #401883 |
bart pisze: > On 10/09/2026 15:03, fir wrote: >> bart pisze: >>> Further, if this is a function all: >>> >>> F G H I J >>> >>> Then you don't know if this means F(G, H, I, J), or F (G, H(I), J) etc. >> >> this is not a problem in my bare-naked forms tuday as >> >> it would be >> >> F G (H I) J >> >> then you see F is function all that takes 3 args and H is a function >> call that takes one > > That makes it too strict. C has variadic functions. Some languages have > optional arguments with default values. Some languages are dynamically > types so you don't know at compile-time (and the reader can't tell) how > many arguments F takes. > >> so this seem totally no problem, > > Try it with a real example, such as: > > succeeded = tdefl_init pComp pPut_buf_func pPut_buf_user flags > == TDEFL_STATUS_OKAY ; > > succeeded = succeeded && tdefl_compress_buffer pComp pBuf > buf_len TDEFL_FINISH == TDEFL_STATUS_DONE > > These have had parentheses and commas removed. There is also this: > > F G H I + J > > Even if you know that F takes two arguments, and H takes one, which of > these is the intended meaning: > > F(G, H(I) + J) > F(G, H(I)) + J > i not quite understand yopu you simply has a b c d e f you know a is a function and rest is arguments it make no rpoblem with variadic a b (c d) e f hetre both a and c may be variadic, you may add extra arguments a b (c d 1 2) e f 3 4
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2026-09-10 16:59 +0200 |
| Message-ID | <117ugkf$236no$1@dont-email.me> |
| In reply to | #401885 |
fir pisze: > Try it with a real example, such as: > > succeeded = tdefl_init pComp pPut_buf_func pPut_buf_user flags > == TDEFL_STATUS_OKAY ; > > succeeded = succeeded && tdefl_compress_buffer pComp pBuf > buf_len TDEFL_FINISH == TDEFL_STATUS_DONE im not sure what you mean hera bove but with this e conventions im talkin abouts its succeeded = tdefl_init( pComp, pPut_buf_func, pPut_buf_user, flags== TDEFL_STATUS_OKAY) ; and succeeded = succeeded && tdefl_compress_buffer( pComp , pBuf, buf_len, TDEFL_FINISH == TDEFL_STATUS_DONE);
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-09-10 16:57 +0100 |
| Message-ID | <117uk0s$24k4m$1@dont-email.me> |
| In reply to | #401888 |
On 10/09/2026 15:59, fir wrote:
> fir pisze:
>> Try it with a real example, such as:
>>
>> succeeded = tdefl_init pComp pPut_buf_func pPut_buf_user
>> flags == TDEFL_STATUS_OKAY ;
>>
>> succeeded = succeeded && tdefl_compress_buffer pComp pBuf
>> buf_len TDEFL_FINISH == TDEFL_STATUS_DONE
>
>
> im not sure what you mean hera bove but with this e conventions im
> talkin abouts its
>
> succeeded = tdefl_init( pComp, pPut_buf_func, pPut_buf_user, flags==
> TDEFL_STATUS_OKAY) ;
Not bad, but this is the original:
succeeded = (tdefl_init(pComp, pPut_buf_func, pPut_buf_user, flags)
== TDEFL_STATUS_OKAY);
> and
>
> succeeded = succeeded && tdefl_compress_buffer( pComp , pBuf, buf_len,
> TDEFL_FINISH == TDEFL_STATUS_DONE);
And here's the original for this:
succeeded = succeeded && (tdefl_compress_buffer(pComp, pBuf,
buf_len, TDEFL_FINISH) == TDEFL_STATUS_DONE);
I think the parentheses and commas do a good job in removing ambiguity.
Although the originals probably had one pair of superfluous parentheses
each, as '=='s precedence is already higher than both = and &&.
But, what are you planning with general expressions: will you still have
operator precedences?
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2026-09-10 18:18 +0200 |
| Message-ID | <117ul8e$254i9$1@dont-email.me> |
| In reply to | #401891 |
bart pisze:
> On 10/09/2026 15:59, fir wrote:
>> fir pisze:
>>> Try it with a real example, such as:
>>>
>>> succeeded = tdefl_init pComp pPut_buf_func pPut_buf_user
>>> flags == TDEFL_STATUS_OKAY ;
>>>
>>> succeeded = succeeded && tdefl_compress_buffer pComp pBuf
>>> buf_len TDEFL_FINISH == TDEFL_STATUS_DONE
>>
>>
>> im not sure what you mean hera bove but with this e conventions im
>> talkin abouts its
>>
>> succeeded = tdefl_init( pComp, pPut_buf_func, pPut_buf_user,
>> flags== TDEFL_STATUS_OKAY) ;
>
> Not bad, but this is the original:
>
> succeeded = (tdefl_init(pComp, pPut_buf_func, pPut_buf_user, flags)
> == TDEFL_STATUS_OKAY);
>
thet would be
succeeded = (tdefl_init pComp pPut_buf_func pPut_buf_user flags ) ==
TDEFL_STATUS_OKAY
>
>
>> and
>>
>> succeeded = succeeded && tdefl_compress_buffer( pComp , pBuf,
>> buf_len, TDEFL_FINISH == TDEFL_STATUS_DONE);
> And here's the original for this:
>
> succeeded = succeeded && (tdefl_compress_buffer(pComp, pBuf,
> buf_len, TDEFL_FINISH) == TDEFL_STATUS_DONE);
>
>
> I think the parentheses and commas do a good job in removing ambiguity.
>
> Although the originals probably had one pair of superfluous parentheses
> each, as '=='s precedence is already higher than both = and &&.
>
> But, what are you planning with general expressions: will you still have
> operator precedences?
if the comma and parenthesis are not needed why use them
esp as a most amount of code is like
void RunFrame advance
{
Initialise,
ClearFrameData 0x444444
DrawLine3d 100.0 100.0 0.0 100.0 -100.0 0.0 0xffffff
DrawLine3d 100.0 -100.0 0.0 -100.0 -100.0 0.0 0xffffff
DrawLine3d -100.0 -100.0 0.0 -100.0 100.0 0.0 0xffffff
DrawLine3d -100.0 100.0 0.0 100.0 100.0 0.0 0xffffff
DrawDot3d 0.0 0.0 100.0 20.0 0x557788
DrawDot3d 0.0 0.0 150.0 30.0 0x557722
DrawDot3d 0.0 0.0 -100.0 10.0 0xaa7788
InitSomeJointsFigures
DrawCloud1, DrawCloud2,
DrawCloud11, DrawCloud12, UpdateDotsBag, DrawDotsBag
FillRectangle2 10 10 20 20 color
DrawSomeText2F 0xcccccc 0x666666 20 10 " %x \x00" 0xffffff
DrawSomeText2F 0xcccccc 0x666666 10 20 "hello, this is example
program compiled by fir's furia compiler \x00"
DeawLines
DrawTextByBalls "hello\x00" 0 0 0x999999
DrawCubesCubeGeo
BezierPatchTest
space_pressed? FireDotFromCameraCurrentColor 0.0 0.0 100000 20
a_pressed?! FireDotFromCameraCurrentColor 1.0 0.0 10000 20
f5_toggler? DrawManual
DrawFloor 20000 30 0x555555
DrawRawModel
}
i mean lot are "normal" simple calls and there is a lot of (,,,,);
to skip
as to operator precedence ofc its needed and as i said what i show
here is the part that is "resolved" but there are more complex
cases where it is not resolved yet
(for example for this many return values , operator form of functions
(as a would like to have "x foo y" where foo is a function and x y are
arguments, and those float char types, some constructions like loops
and so on
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2026-09-11 01:04 +0200 |
| Message-ID | <117vd1h$2dp5p$1@dont-email.me> |
| In reply to | #401893 |
fir pisze:
> bart pisze:
>> On 10/09/2026 15:59, fir wrote:
>>> fir pisze:
>>>> Try it with a real example, such as:
>>>>
>>>> succeeded = tdefl_init pComp pPut_buf_func pPut_buf_user
>>>> flags == TDEFL_STATUS_OKAY ;
>>>>
>>>> succeeded = succeeded && tdefl_compress_buffer pComp pBuf
>>>> buf_len TDEFL_FINISH == TDEFL_STATUS_DONE
>>>
>>>
>>> im not sure what you mean hera bove but with this e conventions im
>>> talkin abouts its
>>>
>>> succeeded = tdefl_init( pComp, pPut_buf_func, pPut_buf_user,
>>> flags== TDEFL_STATUS_OKAY) ;
>>
>> Not bad, but this is the original:
>>
>> succeeded = (tdefl_init(pComp, pPut_buf_func, pPut_buf_user, flags)
>> == TDEFL_STATUS_OKAY);
>>
>
> thet would be
>
> succeeded = (tdefl_init pComp pPut_buf_func pPut_buf_user flags ) ==
> TDEFL_STATUS_OKAY
>
>
> >
>>
>>> and
>>>
>>> succeeded = succeeded && tdefl_compress_buffer( pComp , pBuf,
>>> buf_len, TDEFL_FINISH == TDEFL_STATUS_DONE);
>> And here's the original for this:
>>
>> succeeded = succeeded && (tdefl_compress_buffer(pComp, pBuf,
>> buf_len, TDEFL_FINISH) == TDEFL_STATUS_DONE);
>>
>>
>> I think the parentheses and commas do a good job in removing ambiguity.
>>
>> Although the originals probably had one pair of superfluous
>> parentheses each, as '=='s precedence is already higher than both =
>> and &&.
>>
>> But, what are you planning with general expressions: will you still
>> have operator precedences?
>
>
> if the comma and parenthesis are not needed why use them
>
> esp as a most amount of code is like
>
> void RunFrame advance
> {
> Initialise,
> ClearFrameData 0x444444
> DrawLine3d 100.0 100.0 0.0 100.0 -100.0 0.0 0xffffff
> DrawLine3d 100.0 -100.0 0.0 -100.0 -100.0 0.0 0xffffff
> DrawLine3d -100.0 -100.0 0.0 -100.0 100.0 0.0 0xffffff
> DrawLine3d -100.0 100.0 0.0 100.0 100.0 0.0 0xffffff
> DrawDot3d 0.0 0.0 100.0 20.0 0x557788
> DrawDot3d 0.0 0.0 150.0 30.0 0x557722
> DrawDot3d 0.0 0.0 -100.0 10.0 0xaa7788
> InitSomeJointsFigures
> DrawCloud1, DrawCloud2,
> DrawCloud11, DrawCloud12, UpdateDotsBag, DrawDotsBag
>
> FillRectangle2 10 10 20 20 color
> DrawSomeText2F 0xcccccc 0x666666 20 10 " %x \x00" 0xffffff
> DrawSomeText2F 0xcccccc 0x666666 10 20 "hello, this is example
> program compiled by fir's furia compiler \x00"
>
> DeawLines
> DrawTextByBalls "hello\x00" 0 0 0x999999
> DrawCubesCubeGeo
>
> BezierPatchTest
>
> space_pressed? FireDotFromCameraCurrentColor 0.0 0.0 100000 20
> a_pressed?! FireDotFromCameraCurrentColor 1.0 0.0 10000 20
> f5_toggler? DrawManual
>
> DrawFloor 20000 30 0x555555
> DrawRawModel
>
> }
>
> i mean lot are "normal" simple calls and there is a lot of (,,,,);
> to skip
> as to operator precedence ofc its needed and as i said what i show
> here is the part that is "resolved" but there are more complex
> cases where it is not resolved yet
>
> (for example for this many return values , operator form of functions
> (as a would like to have "x foo y" where foo is a function and x y are
> arguments, and those float char types, some constructions like loops
> and so on
>
i consider yet such syntax
▫mandelbrot_calculate ﹉image_beg_x ﹉image_beg_y ﹉image_end_x
﹉image_end_y ﹉ox ﹉oy ﹉lx ‾max_iter
{
ly﹉ lx*frame_size_y/frame_size_x
dx﹉ lx/frame_size_x
dy﹉ lx/frame_size_x
ax﹉ ox-lx*.5+dx*.5
ay﹉ oy-ly*.5+dy*.5
j‾ image_beg_y..image_end_y { c_im﹉ ay+j*dy
i‾ image_beg_x..image_end_x { c_re﹉ ax+i*dx
n‾ mandelbrot_n c_re c_im max_iter, suma‾ suma+n,
OffscreenBufferSetValue i j n }}
}
ax﹉ mean "double ax ="
﹉image_beg_y means "﹉image_beg_y"
n‾ means "int n ="
and so on
so this will cover doubles and ints but no solutions for chars floats
schorts, defined types etc - so it may be a problem (alse those
typenames in heaer consumes types/chars
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2026-09-10 16:47 +0200 |
| Message-ID | <117ufta$22qm7$3@dont-email.me> |
| In reply to | #401883 |
bart pisze: > These have had parentheses and commas removed. There is also this: > > F G H I + J > > Even if you know that F takes two arguments, and H takes one, which of > these is the intended meaning: > > F(G, H(I) + J) > F(G, H(I)) + J F G H I + J this above s function f that takes 3 arguments G H and I+J
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2026-09-10 16:54 +0200 |
| Message-ID | <117ugbb$233gl$1@dont-email.me> |
| In reply to | #401886 |
fir pisze: > bart pisze: >> These have had parentheses and commas removed. There is also this: >> >> F G H I + J >> >> Even if you know that F takes two arguments, and H takes one, which of >> these is the intended meaning: >> >> F(G, H(I) + J) >> F(G, H(I)) + J > > > > F G H I + J > > this above s function f that takes 3 arguments G H and I+J > ypu got function arg arg arg arg arg (always..at least if the first one is function name, if it is something another maybe i will change it but as for now it seems its always a function, it cant be int as int would be _g (initialisation) or g_ (assigment) so d jkd d d lkjd djl is always faaaaa type (here it would not compile i guess) so if you got a s d (g d f b) j k it is faa(faaa)aa and so on
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2026-09-10 17:06 +0200 |
| Message-ID | <117uh1l$23cu7$1@dont-email.me> |
| In reply to | #401887 |
fir pisze: > fir pisze: >> bart pisze: >>> These have had parentheses and commas removed. There is also this: >>> >>> F G H I + J >>> >>> Even if you know that F takes two arguments, and H takes one, which >>> of these is the intended meaning: >>> >>> F(G, H(I) + J) >>> F(G, H(I)) + J >> >> >> >> F G H I + J >> >> this above s function f that takes 3 arguments G H and I+J >> > > ypu got > > function arg arg arg arg arg > > (always..at least if the first one is function name, if it is something > another maybe i will change it but as for now it seems its always a > function, it cant be int as int would be > > _g (initialisation) or g_ (assigment) > > so d jkd d d lkjd djl is always faaaaa type (here it would not compile i > guess) > > > so if you got a s d (g d f b) j k it is faa(faaa)aa and so on > > > > i got kinda more troubles with function returning more values than 1 (as i want to have it) now i consider _x_y foo 2 3 4 // (int x, int y) = foo(2,3,4) x_ _y foo 3 4 5 // (x, int y) = foo(2,3,4)
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2026-09-10 17:15 +0200 |
| Message-ID | <117uhhu$23jm4$1@dont-email.me> |
| In reply to | #401889 |
fir pisze: > fir pisze: >> fir pisze: >>> bart pisze: >>>> These have had parentheses and commas removed. There is also this: >>>> >>>> F G H I + J >>>> >>>> Even if you know that F takes two arguments, and H takes one, which >>>> of these is the intended meaning: >>>> >>>> F(G, H(I) + J) >>>> F(G, H(I)) + J >>> >>> >>> >>> F G H I + J >>> >>> this above s function f that takes 3 arguments G H and I+J >>> >> >> ypu got >> >> function arg arg arg arg arg >> >> (always..at least if the first one is function name, if it is >> something another maybe i will change it but as for now it seems its >> always a function, it cant be int as int would be >> >> _g (initialisation) or g_ (assigment) >> >> so d jkd d d lkjd djl is always faaaaa type (here it would not compile >> i guess) >> >> >> so if you got a s d (g d f b) j k it is faa(faaa)aa and so on >> >> >> >> > > > > i got kinda more troubles with function returning more values than 1 > (as i want to have it) > > now i consider > > _x_y foo 2 3 4 // (int x, int y) = foo(2,3,4) > > x_ _y foo 3 4 5 // (x, int y) = foo(2,3,4) > this above would need some decisions as the meaning of above would have different meaning if foo returns onlu 1 value like x_ _y f //sets x y if foo returns 2 values x_ _y f // may be x= (int y = f() ) if f returns one and it is a question what allow whad disallow and so on, but this pure naked normal form "d e r g :' is rather totally clear
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-09-10 18:10 +0200 |
| Message-ID | <117ukqj$24aa4$1@dont-email.me> |
| In reply to | #401890 |
On 10/09/2026 17:15, fir wrote: > fir pisze: >> i got kinda more troubles with function returning more values than 1 >> (as i want to have it) >> >> now i consider >> >> _x_y foo 2 3 4 // (int x, int y) = foo(2,3,4) >> >> x_ _y foo 3 4 5 // (x, int y) = foo(2,3,4) >> > > this above would need some decisions as the meaning of above would > have different meaning if foo returns onlu 1 value > > like > > x_ _y f //sets x y if foo returns 2 values > > x_ _y f // may be x= (int y = f() ) if f returns one and it is a > question what allow whad disallow and so on, > > but this pure naked normal form "d e r g :' is rather totally clear > > > This is all getting /very/ far from C. Might it be a good time to start a new thread in comp.lang.misc instead? If you are serious about making his own language in some way, then I am sure he would benefit from paying some attention to Bart's advice (I might not like his language, or have any use of it, but there's no doubt he has more experience than most in language design). And maybe in comp.lang.misc the thread will attract others that have interest in new languages, or advice based on different language experience.
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2026-09-10 18:21 +0200 |
| Message-ID | <117ule1$254i9$2@dont-email.me> |
| In reply to | #401892 |
David Brown pisze: > On 10/09/2026 17:15, fir wrote: >> fir pisze: > >>> i got kinda more troubles with function returning more values than 1 >>> (as i want to have it) >>> >>> now i consider >>> >>> _x_y foo 2 3 4 // (int x, int y) = foo(2,3,4) >>> >>> x_ _y foo 3 4 5 // (x, int y) = foo(2,3,4) >>> >> >> this above would need some decisions as the meaning of above would >> have different meaning if foo returns onlu 1 value >> >> like >> >> x_ _y f //sets x y if foo returns 2 values >> >> x_ _y f // may be x= (int y = f() ) if f returns one and it is a >> question what allow whad disallow and so on, >> >> but this pure naked normal form "d e r g :' is rather totally clear >> >> >> > > This is all getting /very/ far from C. Might it be a good time to start > a new thread in comp.lang.misc instead? > > If you are serious about making his own language in some way, then I am > sure he would benefit from paying some attention to Bart's advice (I > might not like his language, or have any use of it, but there's no doubt > he has more experience than most in language design). > > And maybe in comp.lang.misc the thread will attract others that have > interest in new languages, or advice based on different language > experience. > this is theoretical c imo - c has some set of ideas internally and is "made" from this ideas so exploring those ideas ic C imo but more theoretical i make some theory and some of it is more general (like say this last things that objects are indeed knots/webs, or code jumping problem)but its also a c if it uses c
[toc] | [prev] | [next] | [standalone]
Page 6 of 25 — ← Prev page 1 … 4 5 [6] 7 8 … 25 Next page →
Back to top | Article view | comp.lang.c
csiph-web