Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #394664 > unrolled thread
| Started by | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| First post | 2025-10-22 14:39 -0700 |
| Last post | 2025-10-27 11:51 -0700 |
| Articles | 20 on this page of 196 — 19 participants |
Back to article view | Back to comp.lang.c
New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-22 14:39 -0700
Re: New and improved version of cdecl Thiago Adams <thiago.adams@gmail.com> - 2025-10-22 22:19 -0300
Re: New and improved version of cdecl Ben Bacarisse <ben@bsb.me.uk> - 2025-10-23 02:42 +0100
Re: New and improved version of cdecl Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-23 03:04 +0000
Re: New and improved version of cdecl Ben Bacarisse <ben@bsb.me.uk> - 2025-10-23 15:05 +0100
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-23 11:36 +0100
Re: New and improved version of cdecl Thiago Adams <thiago.adams@gmail.com> - 2025-10-23 07:59 -0300
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-23 16:04 -0700
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-24 01:44 +0100
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-23 19:00 -0700
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-24 14:27 +0100
Re: New and improved version of cdecl David Brown <david.brown@hesbynett.no> - 2025-10-24 19:35 +0200
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-24 19:50 +0100
Re: New and improved version of cdecl scott@slp53.sl.home (Scott Lurndal) - 2025-10-24 18:59 +0000
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-24 13:20 -0700
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-24 23:18 +0100
Re: New and improved version of cdecl Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-26 07:25 +0100
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-26 11:26 +0000
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-26 13:26 +0000
Re: New and improved version of cdecl scott@slp53.sl.home (Scott Lurndal) - 2025-10-26 16:07 +0000
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-26 17:03 +0000
Re: New and improved version of cdecl scott@slp53.sl.home (Scott Lurndal) - 2025-10-26 16:04 +0000
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-26 16:58 +0000
Re: New and improved version of cdecl Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-26 17:27 +0000
Re: New and improved version of cdecl Michael S <already5chosen@yahoo.com> - 2025-10-26 22:49 +0200
Re: New and improved version of cdecl Michael S <already5chosen@yahoo.com> - 2025-10-26 23:07 +0200
Re: New and improved version of cdecl Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-28 18:01 +0000
Re: New and improved version of cdecl antispam@fricas.org (Waldek Hebisch) - 2025-10-29 20:33 +0000
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-29 23:29 +0000
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-26 16:07 -0700
Re: New and improved version of cdecl Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-27 03:08 +0100
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-27 12:50 +0000
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-27 12:58 +0000
Re: New and improved version of cdecl Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-27 14:45 +0100
Re: New and improved version of cdecl Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-27 14:48 +0100
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-27 15:23 +0000
Re: New and improved version of cdecl Michael S <already5chosen@yahoo.com> - 2025-10-27 22:39 +0200
Re: New and improved version of cdecl Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-28 03:00 +0100
Re: New and improved version of cdecl David Brown <david.brown@hesbynett.no> - 2025-10-28 15:59 +0100
Re: New and improved version of cdecl scott@slp53.sl.home (Scott Lurndal) - 2025-10-28 16:05 +0000
Re: New and improved version of cdecl Michael S <already5chosen@yahoo.com> - 2025-10-28 20:00 +0200
Re: New and improved version of cdecl scott@slp53.sl.home (Scott Lurndal) - 2025-10-28 18:28 +0000
Re: New and improved version of cdecl Michael S <already5chosen@yahoo.com> - 2025-10-28 20:49 +0200
Re: New and improved version of cdecl Ben Bacarisse <ben@bsb.me.uk> - 2025-10-29 21:30 +0000
Re: New and improved version of cdecl Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-28 20:32 +0100
Re: New and improved version of cdecl Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-28 20:14 +0100
Re: New and improved version of cdecl David Brown <david.brown@hesbynett.no> - 2025-10-29 16:36 +0100
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-29 17:24 +0000
Re: New and improved version of cdecl Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-27 14:39 +0100
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-27 15:11 +0000
Re: New and improved version of cdecl Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-28 03:35 +0100
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-28 11:16 +0000
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-28 14:59 -0700
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-28 23:14 +0000
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-28 18:48 -0700
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-29 19:24 +0000
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-29 15:10 -0700
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-29 23:19 +0000
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-29 18:03 -0700
Re: New and improved version of cdecl David Brown <david.brown@hesbynett.no> - 2025-10-30 09:02 +0100
Re: New and improved version of cdecl Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-29 08:06 +0100
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-29 11:20 +0000
Re: New and improved version of cdecl David Brown <david.brown@hesbynett.no> - 2025-10-29 17:12 +0100
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-29 21:21 +0000
Re: New and improved version of cdecl David Brown <david.brown@hesbynett.no> - 2025-10-30 00:04 +0100
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-29 16:47 -0700
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-30 00:36 +0000
Re: New and improved version of cdecl antispam@fricas.org (Waldek Hebisch) - 2025-10-30 03:37 +0000
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-29 21:24 -0700
Re: New and improved version of cdecl vallor <vallor@vallor.earth> - 2025-10-30 04:52 +0000
Re: New and improved version of cdecl vallor <vallor@vallor.earth> - 2025-10-30 05:38 +0000
Re: New and improved version of cdecl Richard Heathfield <rjh@cpax.org.uk> - 2025-10-30 07:45 +0000
Re: New and improved version of cdecl Michael S <already5chosen@yahoo.com> - 2025-10-30 16:41 +0200
Re: New and improved version of cdecl richard@cogsci.ed.ac.uk (Richard Tobin) - 2025-10-30 16:26 +0000
Re: New and improved version of cdecl scott@slp53.sl.home (Scott Lurndal) - 2025-10-30 17:30 +0000
Re: New and improved version of cdecl richard@cogsci.ed.ac.uk (Richard Tobin) - 2025-10-30 18:29 +0000
Re: New and improved version of cdecl scott@slp53.sl.home (Scott Lurndal) - 2025-10-30 18:37 +0000
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-30 13:21 -0700
Re: New and improved version of cdecl Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-31 07:44 +0100
Re: New and improved version of cdecl Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-31 07:49 +0100
Re: New and improved version of cdecl David Brown <david.brown@hesbynett.no> - 2025-10-30 12:50 +0100
Re: New and improved version of cdecl antispam@fricas.org (Waldek Hebisch) - 2025-10-31 00:27 +0000
Re: New and improved version of cdecl "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-10-30 17:35 -0700
Re: New and improved version of cdecl scott@slp53.sl.home (Scott Lurndal) - 2025-10-30 14:13 +0000
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-30 14:32 +0000
Re: New and improved version of cdecl scott@slp53.sl.home (Scott Lurndal) - 2025-10-30 16:22 +0000
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-30 17:40 +0000
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-31 12:39 +0000
Re: New and improved version of cdecl scott@slp53.sl.home (Scott Lurndal) - 2025-10-31 13:57 +0000
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-31 14:55 +0000
Re: New and improved version of cdecl scott@slp53.sl.home (Scott Lurndal) - 2025-10-31 17:18 +0000
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-31 17:52 +0000
Re: New and improved version of cdecl tTh <tth@none.invalid> - 2025-10-30 05:00 +0100
Re: New and improved version of cdecl David Brown <david.brown@hesbynett.no> - 2025-10-30 11:15 +0100
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-30 12:07 +0000
Re: New and improved version of cdecl David Brown <david.brown@hesbynett.no> - 2025-10-30 16:04 +0100
Re: New and improved version of cdecl Michael S <already5chosen@yahoo.com> - 2025-10-30 18:30 +0200
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-30 17:49 +0000
Re: New and improved version of cdecl Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-30 18:59 +0000
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-30 23:23 +0000
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-30 16:44 -0700
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-31 00:15 +0000
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-30 18:16 -0700
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-31 01:36 +0000
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-30 19:13 -0700
Re: New and improved version of cdecl scott@slp53.sl.home (Scott Lurndal) - 2025-10-31 13:43 +0000
Re: New and improved version of cdecl David Brown <david.brown@hesbynett.no> - 2025-10-31 13:10 +0100
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-31 16:34 +0000
Re: New and improved version of cdecl David Brown <david.brown@hesbynett.no> - 2025-10-30 23:01 +0100
Re: New and improved version of cdecl Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-31 00:28 +0000
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-31 01:22 +0000
Re: New and improved version of cdecl tTh <tth@none.invalid> - 2025-10-31 10:29 +0100
Re: New and improved version of cdecl Michael S <already5chosen@yahoo.com> - 2025-10-31 13:15 +0200
Re: New and improved version of cdecl antispam@fricas.org (Waldek Hebisch) - 2025-10-31 21:39 +0000
Re: New and improved version of cdecl richard@cogsci.ed.ac.uk (Richard Tobin) - 2025-10-31 11:43 +0000
Re: New and improved version of cdecl Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-31 22:47 +0000
Re: New and improved version of cdecl David Brown <david.brown@hesbynett.no> - 2025-10-31 13:16 +0100
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-31 23:40 +0000
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-31 17:14 -0700
Re: New and improved version of cdecl Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-31 09:31 +0100
Re: New and improved version of cdecl antispam@fricas.org (Waldek Hebisch) - 2025-10-30 23:11 +0000
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-30 23:49 +0000
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-31 02:14 +0000
Re: New and improved version of cdecl antispam@fricas.org (Waldek Hebisch) - 2025-10-31 22:01 +0000
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-11-01 11:57 +0000
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-11-01 14:56 +0000
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-30 13:37 -0700
Re: New and improved version of cdecl David Brown <david.brown@hesbynett.no> - 2025-10-30 23:37 +0100
Re: New and improved version of cdecl tTh <tth@none.invalid> - 2025-10-31 11:52 +0100
Re: New and improved version of cdecl scott@slp53.sl.home (Scott Lurndal) - 2025-10-31 13:48 +0000
Re: New and improved version of cdecl vallor <vallor@vallor.earth> - 2025-10-29 23:11 +0000
Re: New and improved version of cdecl Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-29 06:57 +0100
Re: New and improved version of cdecl Michael S <already5chosen@yahoo.com> - 2025-10-29 14:17 +0200
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-29 14:40 +0000
Re: New and improved version of cdecl tTh <tth@none.invalid> - 2025-10-29 16:09 +0100
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-29 16:47 +0000
Re: New and improved version of cdecl antispam@fricas.org (Waldek Hebisch) - 2025-10-30 05:11 +0000
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-30 12:56 +0000
Re: New and improved version of cdecl James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-10-28 17:34 -0400
Re: New and improved version of cdecl antispam@fricas.org (Waldek Hebisch) - 2025-10-31 04:37 +0000
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-27 13:31 -0700
Re: New and improved version of cdecl Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-27 20:52 +0000
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-27 17:30 -0700
Re: New and improved version of cdecl "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-10-27 19:11 -0700
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-27 19:59 -0700
Re: New and improved version of cdecl "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-10-27 23:45 -0700
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-28 10:27 +0000
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-28 01:22 +0000
Re: New and improved version of cdecl Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-28 17:03 +0000
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-28 22:26 +0000
Re: New and improved version of cdecl Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-29 00:04 +0000
Re: New and improved version of cdecl Michael S <already5chosen@yahoo.com> - 2025-10-26 13:15 +0200
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-26 14:56 -0700
Re: New and improved version of cdecl Michael S <already5chosen@yahoo.com> - 2025-10-27 00:34 +0200
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-26 15:45 -0700
Re: New and improved version of cdecl Michael S <already5chosen@yahoo.com> - 2025-10-27 01:12 +0200
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-26 16:15 -0700
Re: New and improved version of cdecl Michael S <already5chosen@yahoo.com> - 2025-10-28 14:56 +0200
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-28 13:18 +0000
Re: New and improved version of cdecl scott@slp53.sl.home (Scott Lurndal) - 2025-10-28 15:03 +0000
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-28 16:16 +0000
Re: New and improved version of cdecl David Brown <david.brown@hesbynett.no> - 2025-10-25 13:04 +0200
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-25 13:51 +0100
Re: New and improved version of cdecl David Brown <david.brown@hesbynett.no> - 2025-10-25 17:18 +0200
Re: New and improved version of cdecl Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-26 07:44 +0100
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-26 15:12 +0000
Re: New and improved version of cdecl David Brown <david.brown@hesbynett.no> - 2025-10-27 10:44 +0100
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-27 11:22 +0000
Re: New and improved version of cdecl David Brown <david.brown@hesbynett.no> - 2025-10-27 17:35 +0100
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-27 17:44 +0000
Re: New and improved version of cdecl Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-28 04:10 +0100
Re: New and improved version of cdecl "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-10-27 23:47 -0700
Re: New and improved version of cdecl antispam@fricas.org (Waldek Hebisch) - 2025-10-27 22:33 +0000
Re: New and improved version of cdecl Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-28 04:23 +0100
Re: New and improved version of cdecl David Brown <david.brown@hesbynett.no> - 2025-10-28 16:20 +0100
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-27 13:48 -0700
Re: New and improved version of cdecl Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-28 04:41 +0100
Re: New and improved version of cdecl James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-10-25 11:40 -0400
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-25 16:48 +0100
Re: New and improved version of cdecl David Brown <david.brown@hesbynett.no> - 2025-10-25 19:14 +0200
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-25 15:14 -0700
Re: New and improved version of cdecl Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-26 08:07 +0100
Re: New and improved version of cdecl Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-24 21:36 +0200
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-24 13:07 -0700
Re: New and improved version of cdecl David Brown <david.brown@hesbynett.no> - 2025-10-25 13:15 +0200
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-24 13:01 -0700
Re: New and improved version of cdecl "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-10-24 15:01 -0700
Re: New and improved version of cdecl Andrey Tarasevich <noone@noone.net> - 2025-10-26 12:09 -0700
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-26 15:36 -0700
Re: New and improved version of cdecl "Paul J. Lucas" <paul@lucasmail.org> - 2025-12-09 07:31 -0800
Re: New and improved version of cdecl Kaz Kylheku <046-301-5902@kylheku.com> - 2025-12-09 20:38 +0000
Re: New and improved version of cdecl "Paul J. Lucas" <paul@lucasmail.org> - 2025-12-09 16:46 -0800
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-12-09 17:51 -0800
Re: New and improved version of cdecl "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-10-26 14:44 -0700
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-26 15:38 -0700
Re: New and improved version of cdecl "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-10-27 11:51 -0700
Page 4 of 10 — ← Prev page 1 2 3 [4] 5 6 … 10 Next page →
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2025-10-29 08:06 +0100 |
| Message-ID | <10dsedv$2nn36$1@dont-email.me> |
| In reply to | #394923 |
On 29.10.2025 00:14, bart wrote: > On 28/10/2025 21:59, Keith Thompson wrote: >> [...] > > He (I assume) always dismisses every single one of my arguments out of > hand: No, I'm trying to speak about various things; basically my focus is the facts. Not the persons involved. But there's persons with specific mindsets (like you) that provoke reactions; on flaws in your logic, misrepresentations, limited perspectives, etc. > > Build speed is never a problem - ever. Like here. You're making things up. - For example I clearly said; "Speed is a topic". But since you're so pathologically focused on that factor that you miss the important projects' contexts. So I then even quoted that (in case you missed it): Speed is not an end in itself. It must be valued in comparison with all the other often more relevant factors (that you seem to completely miss, even when explained to you). > The speed of any language implemention is never a concern either. Nonsense. > [...] > > When I gave the example of my language that was 1000 times faster to > build than A68G, and which ran that test 10 times faster than A68G, that > apparently doesn't count; he doesn't care; or I'm changing the goalposts. Exactly. Or comparing apples and oranges. - Sadly you do all that regularly. > [...] > > On the face of it, it is uncontroversial: they do allow rapid > development and instant feedback, as one of their several pros. Yet, JP > feels the need to be contrary: > >>I can't tell about the "many" that you have in mind, and about their > mindset; I'm sure you either can't tell. > > And now you have joined in, to back him up! Bart, you should take Keith's words meant benevolent; all he's trying was you not always assuming that we want to hurt you if we criticize any misconceptions in your thinking or considering a topic only from one isolate perspective. If you continue to assume that the "worst" was meant, and only against you, you won't get anywhere. Keith has explained in his posts exactly what was said and meant, and made your discussion maneuvers explicit. (I would have been happier if you, Bart, would have noticed yourself what was obvious to Keith.) > [...] >> [...] >> >> You misunderstood what Janis wrote. > > I understand what he's trying to do. He despises me; he thinks the Obviously you don't understand, and certainly also don't know what I think; if you would understand it you wouldn't have written this nonsense. > projects I work on are worthless. Actually, as far as I saw your projects, methods, and targets, yes; they are completely worthless _for me_. (Mind the emphasis.) I also doubt that they are of worth in typical professional contexts; since they seem to lack some basic properties needed in professional contexts. - But that is your problem, not mine. (I just don't care.) > [...] Meanwhile he's a 'professional', as stated many times. Oh, my perception is that the regulars here are *all* professionals! And (typically) even to a high degree. - That's, I think, one reason why you sometimes (often?) get headwind from the audience. What I'm regularly trying to tell you is that your project setups and results might only rarely serve the requirements in professional _projects_ as you find them in _professional software companies_. You cannot seem to accept that. Personally I'm not working anymore professionally. (I mentioned that occasionally.) But I've still the expertise from my professional work and education, and I share my experiences to those who are interested. You, personally, are of no interest to me; your presumptions are thus wrong. (I'm interested in CS and IT topics.) Janis > [...]
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2025-10-29 11:20 +0000 |
| Message-ID | <10dstaf$2rv4e$1@dont-email.me> |
| In reply to | #394931 |
On 29/10/2025 07:06, Janis Papanagnou wrote: > On 29.10.2025 00:14, bart wrote: >> On 28/10/2025 21:59, Keith Thompson wrote: >>> [...] >> >> He (I assume) always dismisses every single one of my arguments out of >> hand: > > No, I'm trying to speak about various things; basically my focus > is the facts. Not the persons involved. But there's persons with > specific mindsets (like you) that provoke reactions; on flaws in > your logic, misrepresentations, limited perspectives, etc. > >> >> Build speed is never a problem - ever. > > Like here. You're making things up. - For example I clearly said; > "Speed is a topic". But since you're so pathologically focused on > that factor that you miss the important projects' contexts. So I > then even quoted that (in case you missed it): > Speed is not an end in itself. It must be valued in comparison > with all the other often more relevant factors (that you seem to > completely miss, even when explained to you). > >> The speed of any language implemention is never a concern either. > > Nonsense. > >> [...] >> >> When I gave the example of my language that was 1000 times faster to >> build than A68G, and which ran that test 10 times faster than A68G, that >> apparently doesn't count; he doesn't care; or I'm changing the goalposts. > > Exactly. Or comparing apples and oranges. - Sadly you do all that > regularly. > >> [...] >> >> On the face of it, it is uncontroversial: they do allow rapid >> development and instant feedback, as one of their several pros. Yet, JP >> feels the need to be contrary: >> >>> I can't tell about the "many" that you have in mind, and about their >> mindset; I'm sure you either can't tell. >> >> And now you have joined in, to back him up! > > Bart, you should take Keith's words meant benevolent; all he's trying > was you not always assuming that we want to hurt you if we criticize > any misconceptions in your thinking or considering a topic only from > one isolate perspective. If you continue to assume that the "worst" > was meant, and only against you, you won't get anywhere. > > Keith has explained in his posts exactly what was said and meant, and > made your discussion maneuvers explicit. (I would have been happier > if you, Bart, would have noticed yourself what was obvious to Keith.) > >> [...] >>> [...] >>> >>> You misunderstood what Janis wrote. >> >> I understand what he's trying to do. He despises me; he thinks the > > Obviously you don't understand, and certainly also don't know what > I think; if you would understand it you wouldn't have written this > nonsense. > >> projects I work on are worthless. > > Actually, as far as I saw your projects, methods, and targets, yes; > they are completely worthless _for me_. (Mind the emphasis.) > > I also doubt that they are of worth in typical professional contexts; > since they seem to lack some basic properties needed in professional > contexts. - But that is your problem, not mine. (I just don't care.) > >> [...] Meanwhile he's a 'professional', as stated many times. > > Oh, my perception is that the regulars here are *all* professionals! > And (typically) even to a high degree. - That's, I think, one reason > why you sometimes (often?) get headwind from the audience. > > What I'm regularly trying to tell you is that your project setups > and results might only rarely serve the requirements in professional > _projects_ as you find them in _professional software companies_. Everyone these days can do their own development on their own projects. The standards do not need to be that high, the scale need not be that huge. Yet the off-the-shelf tools available are still slow and cumbersome. > You cannot seem to accept that. > > Personally I'm not working anymore professionally. (I mentioned that > occasionally.) But I've still the expertise from my professional work > and education, and I share my experiences to those who are interested. > > You, personally, are of no interest to me; your presumptions are thus > wrong. (I'm interested in CS and IT topics.) I'm interested in developing small, human-scale and *personal* projects around compilers, assemblers, linkers, interpreters and emulators. I also devise my own languages. That they were small, simple, fast, and self-contained with no dependencies (a necessity when I started out) was incidental. But those aspects are now deliberately cultivated as a stand against big, slow, complex tools and complex ecosystems. I also (I seem to be unique in this regard) understand the vast difference between building a WIP project from source during development, which may be done 100s of times a day, and an enduser building a finished product from source code, just once. And yet, most source projects that you build from source are just a dump of the developer's source tree. No effort is put into making it streamlined with few points of failure. So I am looking at that. And also at the problems of working with large libraries. I posted elsewhere about this: so WHY isn't the provided API for a library supplied as one compact monolithic header instead of dozens or hundreds or several headers? Why possible benefit is that to the /user/ of the library? In short, I'm doing at lot of experimental work in finding tidy, efficient solutions to building personal software, ones that are mainly OS-agnostic too. Meanwhile everybody else is striving to do that exact opposite! And in this newsgroup, continously shout down my work and my views.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2025-10-29 17:12 +0100 |
| Message-ID | <10dteds$30cp7$2@dont-email.me> |
| In reply to | #394923 |
On 29/10/2025 00:14, bart wrote: > On 28/10/2025 21:59, Keith Thompson wrote: >> bart <bc@freeuk.com> writes: >>> On 28/10/2025 02:35, Janis Papanagnou wrote: >>>> On 27.10.2025 16:11, bart wrote: >> [...] >>>>> If speed wasn't an issue then we'd all be using easy dynamic languages >>>> Huh? - Certainly not. >>> >>> *I* would! That's why I made my scripting languages as fast and >>> capable as possible, so they could be used for more tasks. >>> >>> However, if I dare to suggest that even one other person in the world >>> might also have the same desire, you'd say that I can't possibly know >>> that. >>> >>> And yet here you are: you say 'certainly not'. Obviously *you* know >>> everyone else's mindset! >> >> I'll give this one more try. >> >> This kind of thing makes it difficult to communicate with you. > > You're talking to the wrong guy. It's JP who's difficult to talk to. > > He (I assume) always dismisses every single one of my arguments out of > hand: > > Build speed is never a problem - ever. The speed of any language > implemention is never a concern either. > Bart, I think this all comes down to some basic logic that you get wrong regularly : The opposite of "X is always true" is /not/ "X is always false" or that "(not X) is always true". It is that "X is /sometimes/ false", or that "(not X) is /sometimes/ true". You get this wrong repeatedly when you and I are in disagreement, and I see it again and again with other people - such as with both Janis and Keith. No one, in any of the posts I have read in c.l.c. in countless years, has ever claimed that "build speed is /never/ a problem". People have regularly said that it /often/ is not a problem, or it is not a problem in their own work, or that slow compile times can often be dealt with in various ways so that it is not a problem. People don't disagree that build speed can be an issue - they disagree with your claims that it is /always/ an issue (except when using /your/ tools, or perhaps tcc). When Janis disagrees with you, he is not trashing /everything/ you say, he is disagreeing with /some/ of what you say. No one disagrees that /some/ people would change to using dynamic scripting languages if they had no runtime speed penalty compared to compiled languages - but probably everyone would disagree with a claim that /all/ programmers would change. And no one here thinks that either you or anyone has a reasonable basis for judging how many that "some" would be. So please, stop making this kind of mistake. I am confident that you understand the logic here. But you regularly write as though you do not, setting up nonsensical straw man arguments as a result. And then you make claims about what other people think or said based on this. Yes, it is very much /you/ who is difficult to communicate with. And you should not be surprised if Keith agrees with you sometimes - like I do, like Janis does, and like most people here do, he judges your points as best he can and agrees with some and disagrees with others. These discussions are not black-or-white, all-or-nothing affairs. If you like to hear positive feedback and agreement on your comments (and who doesn't like that?), you need to pay attention to what people write and notice when people agree with you rather than focusing only on when they disagree. Cut the paranoia, drop the straw men and exaggerations, argue you case logically, listen to the replies and feedback you get, and the whole discussion will be a lot more enjoyable and productive.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2025-10-29 21:21 +0000 |
| Message-ID | <10du0gt$37r02$1@dont-email.me> |
| In reply to | #394937 |
On 29/10/2025 16:12, David Brown wrote: > On 29/10/2025 00:14, bart wrote: >> On 28/10/2025 21:59, Keith Thompson wrote: >>> bart <bc@freeuk.com> writes: >>>> On 28/10/2025 02:35, Janis Papanagnou wrote: >>>>> On 27.10.2025 16:11, bart wrote: >>> [...] >>>>>> If speed wasn't an issue then we'd all be using easy dynamic >>>>>> languages >>>>> Huh? - Certainly not. >>>> >>>> *I* would! That's why I made my scripting languages as fast and >>>> capable as possible, so they could be used for more tasks. >>>> >>>> However, if I dare to suggest that even one other person in the world >>>> might also have the same desire, you'd say that I can't possibly know >>>> that. >>>> >>>> And yet here you are: you say 'certainly not'. Obviously *you* know >>>> everyone else's mindset! >>> >>> I'll give this one more try. >>> >>> This kind of thing makes it difficult to communicate with you. >> >> You're talking to the wrong guy. It's JP who's difficult to talk to. >> >> He (I assume) always dismisses every single one of my arguments out of >> hand: >> >> Build speed is never a problem - ever. The speed of any language >> implemention is never a concern either. >> > > Bart, I think this all comes down to some basic logic that you get wrong > regularly : > > The opposite of "X is always true" is /not/ "X is always false" or that > "(not X) is always true". It is that "X is /sometimes/ false", or that > "(not X) is /sometimes/ true". > > You get this wrong repeatedly when you and I are in disagreement, and I > see it again and again with other people - such as with both Janis and > Keith. > > No one, in any of the posts I have read in c.l.c. in countless years, > has ever claimed that "build speed is /never/ a problem". People have > regularly said that it /often/ is not a problem, or it is not a problem > in their own work, or that slow compile times can often be dealt with in > various ways so that it is not a problem. People don't disagree that > build speed can be an issue - they disagree with your claims that it > is /always/ an issue (except when using /your/ tools, or perhaps tcc). It was certainly an issue here: the 'make' part of building CDECL and A68G, I considered slow for the scale of the task given that the apps are 68 and 78Kloc (static total of .c and .h files). A68G I know takes 90 seconds to build (since I've just tried it again; it took long enough that I had an ice-cream while waiting, so that's something). That's under 1Kloc per second; not great. But at least all the optimising would have produced a super-fast executable? Well, that's disappointing too; no-one can say that A68G is fast. I said that my equivalent product was 1000 times faster to build (don't forget the configure nonsense) and it ran 10 times faster on the same test. That is a quite remarkable difference. VERY remarkable. Only some of it is due to my product being smaller (but it's not 1000 times smaller!). This was stated to demonstrate how different my world was. My view is that there is something very wrong with the build systems everyone here uses. But I can understand that no one wants to admit that they're that bad. You find ways around it, you get inured to it, but you just have to use much more powerful machines than mine, but I would go round the bend if I had to work with something so unresponsive.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2025-10-30 00:04 +0100 |
| Message-ID | <10du6ic$39mk9$1@dont-email.me> |
| In reply to | #394942 |
On 29/10/2025 22:21, bart wrote: > On 29/10/2025 16:12, David Brown wrote: >> On 29/10/2025 00:14, bart wrote: >>> On 28/10/2025 21:59, Keith Thompson wrote: >>>> bart <bc@freeuk.com> writes: >>>>> On 28/10/2025 02:35, Janis Papanagnou wrote: >>>>>> On 27.10.2025 16:11, bart wrote: >>>> [...] >>>>>>> If speed wasn't an issue then we'd all be using easy dynamic >>>>>>> languages >>>>>> Huh? - Certainly not. >>>>> >>>>> *I* would! That's why I made my scripting languages as fast and >>>>> capable as possible, so they could be used for more tasks. >>>>> >>>>> However, if I dare to suggest that even one other person in the world >>>>> might also have the same desire, you'd say that I can't possibly know >>>>> that. >>>>> >>>>> And yet here you are: you say 'certainly not'. Obviously *you* know >>>>> everyone else's mindset! >>>> >>>> I'll give this one more try. >>>> >>>> This kind of thing makes it difficult to communicate with you. >>> >>> You're talking to the wrong guy. It's JP who's difficult to talk to. >>> >>> He (I assume) always dismisses every single one of my arguments out >>> of hand: >>> >>> Build speed is never a problem - ever. The speed of any language >>> implemention is never a concern either. >>> >> >> Bart, I think this all comes down to some basic logic that you get >> wrong regularly : >> >> The opposite of "X is always true" is /not/ "X is always false" or >> that "(not X) is always true". It is that "X is /sometimes/ false", >> or that "(not X) is /sometimes/ true". >> >> You get this wrong repeatedly when you and I are in disagreement, and >> I see it again and again with other people - such as with both Janis >> and Keith. >> Bart, did you understand what I wrote here? Do you agree with it - or at least accept how your posts can be interpreted this way? If you can't change the way you express yourself, these threads will always end with you repeating wild exaggerations and generalisations on your favourite rants, no matter what the original topic, and you'll again get frustrated because you feel "everyone is against you". We get more than enough of that with Olcott - I know you can do better. >> No one, in any of the posts I have read in c.l.c. in countless years, >> has ever claimed that "build speed is /never/ a problem". People have >> regularly said that it /often/ is not a problem, or it is not a >> problem in their own work, or that slow compile times can often be >> dealt with in various ways so that it is not a problem. People don't >> disagree that build speed can be an issue - they disagree with your >> claims that it is /always/ an issue (except when using /your/ tools, >> or perhaps tcc). > > It was certainly an issue here: the 'make' part of building CDECL and > A68G, I considered slow for the scale of the task given that the apps > are 68 and 78Kloc (static total of .c and .h files). > I have no interest in A68G. I have no stake in cdecl or knowledge (or particular interest) in how it was written, and how appropriate the number of lines of code are for the task in hand. I am confident it could have been written in a different way with less code - but not at all confident that doing so would be in any way better for the author of the program. I am also confident that you know far too little about what the program can do, or why it was written the way it was, to judge whether it has a "reasonable" number of lines of code, or not. However, it's easy to look at the facts. The "src" directory from the github clone has about 50,000 lines of code in .c files, and 18,000 lines of code in .h files. The total is therefore about 68 kloc of source. This does not at all mean that compilation processes exactly 68 thousand lines of code - it will be significantly more than that as headers are included by multiple files, and lots of other headers from the C standard library and other libraries are included. Let's guess 100 kloc. The build process takes 8 seconds on my decade-old machine, much of which is something other than running the compiler. (Don't ask me what it is doing - I did not write this software, design its build process, or determine how the program is structured and how it is generated by yacc or related tools. This is not my area of expertise.) If for some strange reason I choose to run "make" rather than "make -j", thus wasting much of my computer's power, it takes 16 seconds. Some of these non-compilation steps do not appear to be able to run in parallel, and a couple of the compilations (like "parser.c", which appears to be from a parser generator rather than specifically written) are large and take a couple of seconds to compile. My guess is that the actual compilations are perhaps 4 seconds. Overall, I make it 25 kloc per second. While I don't think that is a particularly relevant measure of anything useful, it does show that either you are measuring the wrong thing, using a wildly inappropriate or limited build environment, or are unaware of how to use your computer to build code. (And my computer cpu was about 30% busy doing other productive tasks, such as playing a game, while I was doing those builds.) So, you are exaggerating, mismeasuring or misusing your system to get build times that are well over an order of magnitude worse than expected. This follows your well-established practice. And you claim your own tools would be 1000 times faster. Maybe they would be. Certainly there have been tools in the past that are much smaller and faster than modern tools, and were useful at the time. Modern tools do so much more, however. A tool that doesn't do the job needed is of no use for a given task, even if it could handle other tasks quickly. But the crux of the matter, and I can't stress this enough as it never seems to get through to you, is that fast enough is fast enough. No one cares how long cdecl takes to build. Almost everyone who wants it will download a binary file - "apt-get install cdecl", or similar. The only people who bother to compile it are those who want the cutting edge version. And even if it takes a minute or two to build, so what? It does not matter. If it took an hour, that would be annoying if you wanted to run it /now/, but even then if it were a useful tool (to the user in question), all you need to do is start it running and then let it churn away in the background. Computers are really good at doing that kind of stuff, and don't get bored easily. Building is a one-time task. (If the edit-build-test cycle for the developers took an hour, that would be a totally different matter.) Of course everyone agrees that smaller and faster is better, all things being equal - but all things are usually /not/ equal, and once something is fast enough to be acceptable, making it faster is not a priority. You can view all this as "bad" if you want. But since the size of the source code for cdecl, the time it takes to build, the use of autotools, the out-the-box Windows experience, and the length of configure script have absolutely /zero/ influence on whether or not I would use cdecl, or how useful I would find it, why should I care about those things? I don't think they are relevant to the vast majority of other potential cdecl users either, and thus do not have to care for their experiences either.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-10-29 16:47 -0700 |
| Message-ID | <877bwdgtim.fsf@example.invalid> |
| In reply to | #394947 |
David Brown <david.brown@hesbynett.no> writes:
[...]
> But the crux of the matter, and I can't stress this enough as it never
> seems to get through to you, is that fast enough is fast enough. No
> one cares how long cdecl takes to build.
[...]
Since the most recent argument here has been about the interpretation
of an absolute statement, I think I should point out that your last
statement above is not literally true. *Some* people do care how
long cdecl takes to build. Most of us, I think, don't particularly
care as long as it's no more than a few minutes.
I understand what you meant, but in a discussion about hyberbolic
statements being taken literally, I suggest it's good to be
painfully precise.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2025-10-30 00:36 +0000 |
| Message-ID | <10dubtm$3bcua$1@dont-email.me> |
| In reply to | #394947 |
On 29/10/2025 23:04, David Brown wrote: > On 29/10/2025 22:21, bart wrote: >> It was certainly an issue here: the 'make' part of building CDECL and >> A68G, I considered slow for the scale of the task given that the apps >> are 68 and 78Kloc (static total of .c and .h files). >> > > I have no interest in A68G. I have no stake in cdecl or knowledge (or > particular interest) in how it was written, and how appropriate the > number of lines of code are for the task in hand. I am confident it > could have been written in a different way with less code - but not at > all confident that doing so would be in any way better for the author of > the program. I am also confident that you know far too little about > what the program can do, or why it was written the way it was, to judge > whether it has a "reasonable" number of lines of code, or not. > > However, it's easy to look at the facts. The "src" directory from the > github clone has about 50,000 lines of code in .c files, and 18,000 > lines of code in .h files. The total is therefore about 68 kloc of > source. This does not at all mean that compilation processes exactly 68 > thousand lines of code - it will be significantly more than that as > headers are included by multiple files, and lots of other headers from > the C standard library and other libraries are included. Let's guess > 100 kloc. Yes, that's why I said the 'static' line counts are 68 and 78K. Maybe the slowdown is due to some large headers that lie outside the problem (not the standard headers), but so what? (That would be a shortcoming of the C language.) The A68G sources also contain lots of upper-case content, so perhaps macro expansion is going on too. The bottom line is this is an 80Kloc app that takes that long to buidld. > > The build process takes 8 seconds on my decade-old machine, much of > which is something other than running the compiler. (Don't ask me what > it is doing - I did not write this software, design its build process, > or determine how the program is structured and how it is generated by > yacc or related tools. This is not my area of expertise.) If for some > strange reason I choose to run "make" rather than "make -j", thus > wasting much of my computer's power, it takes 16 seconds. Some of these > non-compilation steps do not appear to be able to run in parallel, and a > couple of the compilations (like "parser.c", which appears to be from a > parser generator rather than specifically written) are large and take a > couple of seconds to compile. My guess is that the actual compilations > are perhaps 4 seconds. Overall, I make it 25 kloc per second. While I > don't think that is a particularly relevant measure of anything useful, > it does show that either you are measuring the wrong thing, using a > wildly inappropriate or limited build environment, or are unaware of how > to use your computer to build code. Tell me then how I should do it to get single-figure build times for a fresh build. But whatever it is, why doesn't it just do that anyway?! > (And my computer cpu was about 30% > busy doing other productive tasks, such as playing a game, while I was > doing those builds.) > > > So, you are exaggerating, mismeasuring or misusing your system to get > build times that are well over an order of magnitude worse than > expected. This follows your well-established practice. So, what exactly did I do wrong here (for A68G): root@DESKTOP-11:/mnt/c/a68g/algol68g-3.10.5# time make >output real 1m32.205s user 0m40.813s sys 0m7.269s This 90 seconds is the actual time I had to hang about waiting. I'd be interested in how I managed to manipulate those figures! BTW 68Kloc would be CDECL; and 78Kloc is A68G. The CDECL timings are: root@DESKTOP-11:/mnt/c/Users/44775/Downloads/cdecl-18.5# time make >output <warnings> real 0m49.512s user 0m19.033s sys 0m3.911s On the RPi4 (usually 1/3 the speed of my PC), the make-time for A68G was 137 seconds (using SD storage; the PC uses SSD), so perhaps 40 seconds on the PC, suggesting that the underlying Windows file system may be slowing things down, but I don't know. However the same PC, under actual Windows, manages this: c:\qx>tim mm qq Compiling qq.m to qq.exe (500KB but half is data; A68G is 1MB?) Time: 0.084 And this: c:\cx>tim tcc lua.c (250-400KB) Time: 0.124 > And you claim your own tools would be 1000 times faster. In this case, yes. The figure is more typically around 100 if the other compiler is optimising, however that would be representations of the same program. A68G is somewhat bigger than my product. > Maybe they > would be. Certainly there have been tools in the past that are much > smaller and faster than modern tools, and were useful at the time. > Modern tools do so much more, however. A tool that doesn't do the job > needed is of no use for a given task, even if it could handle other > tasks quickly. It ran my test program; that's what counts! > > But the crux of the matter, and I can't stress this enough as it never > seems to get through to you, is that fast enough is fast enough. No one > cares how long cdecl takes to build. I don't care either; I just wanted to try it. But I pick up things that nobody else seems to: this particular build was unusually slow; why was that? Perhaps there's a bottleneck in the process that needs to be fixed, or a bug, that would give benefits when it does matter. (An article posted in Reddit detailed how a small change in how Clang worked made a 5-7% difference in build times for large projects. You'd probably dismiss it as irrelevant, but lots of such improvements build up. At least it is good that some people are looking at such aspects. https://cppalliance.org/mizvekov,/clang/2025/10/20/Making-Clang-AST-Leaner-Faster.html) > Of course everyone agrees that smaller and faster is better, all things > being equal - but all things are usually /not/ equal, and once something > is fast enough to be acceptable, making it faster is not a priority. My compilers have already reached that threshold (most stuff builds in the time it takes to take my finger off the Enter button). But most mainstream compilers are a LONG way off.
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2025-10-30 03:37 +0000 |
| Message-ID | <10dumia$3uier$1@paganini.bofh.team> |
| In reply to | #394952 |
bart <bc@freeuk.com> wrote:
> On 29/10/2025 23:04, David Brown wrote:
>> On 29/10/2025 22:21, bart wrote:
>
>>> It was certainly an issue here: the 'make' part of building CDECL and
>>> A68G, I considered slow for the scale of the task given that the apps
>>> are 68 and 78Kloc (static total of .c and .h files).
>>>
>>
>> I have no interest in A68G. I have no stake in cdecl or knowledge (or
>> particular interest) in how it was written, and how appropriate the
>> number of lines of code are for the task in hand. I am confident it
>> could have been written in a different way with less code - but not at
>> all confident that doing so would be in any way better for the author of
>> the program. I am also confident that you know far too little about
>> what the program can do, or why it was written the way it was, to judge
>> whether it has a "reasonable" number of lines of code, or not.
>>
>> However, it's easy to look at the facts. The "src" directory from the
>> github clone has about 50,000 lines of code in .c files, and 18,000
>> lines of code in .h files. The total is therefore about 68 kloc of
>> source. This does not at all mean that compilation processes exactly 68
>> thousand lines of code - it will be significantly more than that as
>> headers are included by multiple files, and lots of other headers from
>> the C standard library and other libraries are included. Let's guess
>> 100 kloc.
>
> Yes, that's why I said the 'static' line counts are 68 and 78K. Maybe
> the slowdown is due to some large headers that lie outside the problem
> (not the standard headers), but so what? (That would be a shortcoming of
> the C language.)
>
> The A68G sources also contain lots of upper-case content, so perhaps
> macro expansion is going on too.
>
> The bottom line is this is an 80Kloc app that takes that long to buidld.
>
>>
>> The build process takes 8 seconds on my decade-old machine, much of
>> which is something other than running the compiler. (Don't ask me what
>> it is doing - I did not write this software, design its build process,
>> or determine how the program is structured and how it is generated by
>> yacc or related tools. This is not my area of expertise.) If for some
>> strange reason I choose to run "make" rather than "make -j", thus
>> wasting much of my computer's power, it takes 16 seconds. Some of these
>> non-compilation steps do not appear to be able to run in parallel, and a
>> couple of the compilations (like "parser.c", which appears to be from a
>> parser generator rather than specifically written) are large and take a
>> couple of seconds to compile. My guess is that the actual compilations
>> are perhaps 4 seconds. Overall, I make it 25 kloc per second. While I
>> don't think that is a particularly relevant measure of anything useful,
>> it does show that either you are measuring the wrong thing, using a
>> wildly inappropriate or limited build environment, or are unaware of how
>> to use your computer to build code.
>
> Tell me then how I should do it to get single-figure build times for a
> fresh build. But whatever it is, why doesn't it just do that anyway?!
>
>> (And my computer cpu was about 30%
>> busy doing other productive tasks, such as playing a game, while I was
>> doing those builds.)
>>
>>
>> So, you are exaggerating, mismeasuring or misusing your system to get
>> build times that are well over an order of magnitude worse than
>> expected. This follows your well-established practice.
>
> So, what exactly did I do wrong here (for A68G):
>
> root@DESKTOP-11:/mnt/c/a68g/algol68g-3.10.5# time make >output
> real 1m32.205s
> user 0m40.813s
> sys 0m7.269s
>
> This 90 seconds is the actual time I had to hang about waiting. I'd be
> interested in how I managed to manipulate those figures!
>
> BTW 68Kloc would be CDECL; and 78Kloc is A68G. The CDECL timings are:
>
> root@DESKTOP-11:/mnt/c/Users/44775/Downloads/cdecl-18.5# time make
>>output
> <warnings>
> real 0m49.512s
> user 0m19.033s
> sys 0m3.911s
Those numbers indicate that there is something wrong with your
machine. Sum of second and third line above give CPU time.
Real time is twice as large, so something is slowing down things.
One possible trouble is having too small RAM, then OS is swaping
data to/from disc. Some programs do a lot of random I/O, that
can be slow on spinning disc, but SSD-s usually are much
faster at random I/O.
Assuming that you have enough RAM you should try at least using
'make -j 3', that is allow make to use up to 3 jobs. I wrote
at least, because AFAIK cheapest PC CPU-s of reasonable age
have at least 2 cores, so to fully utilize the machine you
need at least 2 jobs. 3 is better, because some jobs may wait
for I/O.
FYI, reasonably typical report for normal make (without -j
option) on my machine is:
real 0m4.981s
user 0m3.712s
sys 0m0.963s
that is real time is bigger than CPU time, but the difference is
reasonably small. On bigger project using 'make -j 20' I get
results like:
real 1m1.840s
user 6m5.335s
sys 0m34.691s
In the second case some steps are serial and use only one core,
but on average parallel build is much faster. Both cases are
full build, using NVE (which has much higher troughput than
SATA SSD).
> On the RPi4 (usually 1/3 the speed of my PC), the make-time for A68G was
> 137 seconds (using SD storage; the PC uses SSD),
AFAIK RPi4 is quad core machine, if yours has enough RAM you could
try 'make -j 5'.
> so perhaps 40 seconds
> on the PC, suggesting that the underlying Windows file system may be
> slowing things down, but I don't know.
As I wrote, something is wrong. Build should be mostly CPU time,
so it should be almost twice as fast compared to real time that
you gave.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-10-29 21:24 -0700 |
| Message-ID | <87zf995859.fsf@example.invalid> |
| In reply to | #394954 |
antispam@fricas.org (Waldek Hebisch) writes:
[...]
> Assuming that you have enough RAM you should try at least using
> 'make -j 3', that is allow make to use up to 3 jobs. I wrote
> at least, because AFAIK cheapest PC CPU-s of reasonable age
> have at least 2 cores, so to fully utilize the machine you
> need at least 2 jobs. 3 is better, because some jobs may wait
> for I/O.
I haven't been using make's "-j" option for most of my builds.
I'm going to start doing so now (updating my wrapper script).
I initially tried replacing "make" by "make -j", with no numeric
argument. The result was that my system nearly froze (the load
average went up to nearly 200). It even invoked the infamous OOM
killer. "make -j" tells make to use as many parallel processes
as possible.
"make -j $(nproc)" is much better. The "nproc" command reports the
number of available processing units. Experiments with a fairly
large build show that arguments to "-j" larger than $(nproc) do
not speed things up (on a fairly old machine with nproc=4). I had
speculated that "make -n 5" might be worthwhile of some processes
were I/O-bound, but that doesn't appear to be the case.
This applies to GNU make. There are other "make" implementations
which may or may not have a similar feature.
[...]
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | vallor <vallor@vallor.earth> |
|---|---|
| Date | 2025-10-30 04:52 +0000 |
| Message-ID | <10duqv2$3enm6$1@dont-email.me> |
| In reply to | #394956 |
At Wed, 29 Oct 2025 21:24:34 -0700, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: > antispam@fricas.org (Waldek Hebisch) writes: > [...] > > Assuming that you have enough RAM you should try at least using > > 'make -j 3', that is allow make to use up to 3 jobs. I wrote > > at least, because AFAIK cheapest PC CPU-s of reasonable age > > have at least 2 cores, so to fully utilize the machine you > > need at least 2 jobs. 3 is better, because some jobs may wait > > for I/O. > > I haven't been using make's "-j" option for most of my builds. > I'm going to start doing so now (updating my wrapper script). > > I initially tried replacing "make" by "make -j", with no numeric > argument. The result was that my system nearly froze (the load > average went up to nearly 200). It even invoked the infamous OOM > killer. "make -j" tells make to use as many parallel processes > as possible. > > "make -j $(nproc)" is much better. The "nproc" command reports the > number of available processing units. Experiments with a fairly > large build show that arguments to "-j" larger than $(nproc) do > not speed things up (on a fairly old machine with nproc=4). I had > speculated that "make -n 5" might be worthwhile of some processes > were I/O-bound, but that doesn't appear to be the case. > > This applies to GNU make. There are other "make" implementations > which may or may not have a similar feature. > > [...] I cloned the cdecl archive to ramdisk and timed the installation commands: $ time -p ./bootstrap [...] real 6.13 user 4.59 sys 0.54 $ time -p ./configure [...] real 11.94 user 5.24 sys 6.13 $ time -p make -j$(nproc) [...] real 3.57 user 11.01 sys 2.74 $ time -p sudo make install [...] real 0.35 user 0.00 sys 0.01 On this system: $ nproc 64 $ grep 'model name' /proc/cpuinfo | uniq model name : AMD Ryzen Threadripper 3970X 32-Core Processor This workstation is a few years old, but I don't see any need to replace it at this point. The numbers above will hopefully give naysayers of autoconf and make pause for thought... -- -v System76 Thelio Mega v1.1 x86_64 NVIDIA RTX 3090Ti 24G OS: Linux 6.17.6 D: Mint 22.2 DE: Xfce 4.18 NVIDIA: 580.95.05 Mem: 258G "It's deja vu all over again."
[toc] | [prev] | [next] | [standalone]
| From | vallor <vallor@vallor.earth> |
|---|---|
| Date | 2025-10-30 05:38 +0000 |
| Message-ID | <10dutk9$3enm6$2@dont-email.me> |
| In reply to | #394957 |
At Thu, 30 Oct 2025 04:52:50 +0000, vallor <vallor@vallor.earth> wrote: > $ grep 'model name' /proc/cpuinfo | uniq > model name : AMD Ryzen Threadripper 3970X 32-Core Processor That was on Linux. Now in a virt running Cygwin on Windows 11 Pro for Workstations...C drive image is on my NAS, connected with 10G-base-T. nproc is 4. CYGWIN_NT-10.0-26100 w11 3.6.5-1.x86_64 2025-10-09 17:21 UTC x86_64 Cygwin $ time -p ./bootstrap [...] real 14.29 user 6.55 sys 3.39 $ time -p ./configure [...] real 106.75 user 38.89 sys 46.26 $ time -p make -j$(nproc) [...] real 31.40 user 50.76 sys 15.83 $ time -p make install [...] real 3.28 user 1.24 sys 1.52 So configure took 1:47. Also, that's a bit misleading, because I had to run ./configure multiple times, and use the cygwin package manager to install dependencies: flex, bison, and libreadline-dev. I could have run it on a RAMdisk, but wasn't worth my time to figure out how to set one up in Windows...which probably would have taken more than 107 seconds to do anyway. Seems like ./configure could be made faster, though, but one only runs it occasionally... -- -v System76 Thelio Mega v1.1 x86_64 NVIDIA RTX 3090Ti 24G OS: Linux 6.17.6 D: Mint 22.2 DE: Xfce 4.18 NVIDIA: 580.95.05 Mem: 258G "Honey, PLEASE don't pick up the PH$@#*&$^(#@&$^%(*NO CARRIER"
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2025-10-30 07:45 +0000 |
| Message-ID | <10dv52b$3gq3j$1@dont-email.me> |
| In reply to | #394956 |
On 30/10/2025 04:24, Keith Thompson wrote: > I haven't been using make's "-j" option for most of my builds. > I'm going to start doing so now (updating my wrapper script). Well, let's see, on approximately 10,000 lines of code: $ make clean $time make real 0m2.391s user 0m2.076s sys 0m0.286s $ make clean $time make -j $(nproc) real 0m0.041s user 0m0.021s sys 0m0.029s That's a reduction in wall clock time of 4 minutes per MLOC to 4 *seconds* per MLOC. I can't deny I'm impressed. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2025-10-30 16:41 +0200 |
| Message-ID | <20251030164149.00003840@yahoo.com> |
| In reply to | #394960 |
On Thu, 30 Oct 2025 07:45:15 +0000 Richard Heathfield <rjh@cpax.org.uk> wrote: > On 30/10/2025 04:24, Keith Thompson wrote: > > I haven't been using make's "-j" option for most of my builds. > > I'm going to start doing so now (updating my wrapper script). > > Well, let's see, on approximately 10,000 lines of code: > > $ make clean > $time make > > real 0m2.391s > user 0m2.076s > sys 0m0.286s > > $ make clean > $time make -j $(nproc) > > real 0m0.041s > user 0m0.021s > sys 0m0.029s > > That's a reduction in wall clock time of 4 minutes per MLOC to 4 > *seconds* per MLOC. I can't deny I'm impressed. > Something wrong here. Most likely you compared "cold" build vs "hot" build. Or your 'make clean' failed to clean majority of objects.
[toc] | [prev] | [next] | [standalone]
| From | richard@cogsci.ed.ac.uk (Richard Tobin) |
|---|---|
| Date | 2025-10-30 16:26 +0000 |
| Message-ID | <10e03jt$19ka6$1@artemis.inf.ed.ac.uk> |
| In reply to | #394960 |
In article <10dv52b$3gq3j$1@dont-email.me>, Richard Heathfield <rjh@cpax.org.uk> wrote: >$time make -j $(nproc) Eww. How does make distinguish between j with an argument and j with no argument and a target? $ make -j a make: *** No rule to make target 'a'. Stop. $ make -j 3 make: *** No targets specified and no makefile found. Stop. $ make 3 cc 3.c -o 3 That's a really bad idea. -- Richard
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2025-10-30 17:30 +0000 |
| Message-ID | <jhNMQ.1338175$Jgh9.1030888@fx15.iad> |
| In reply to | #394972 |
richard@cogsci.ed.ac.uk (Richard Tobin) writes: >In article <10dv52b$3gq3j$1@dont-email.me>, >Richard Heathfield <rjh@cpax.org.uk> wrote: > >>$time make -j $(nproc) > >Eww. How does make distinguish between j with an argument and >j with no argument and a target? $ man 3 getopt Standard unix semantics since, well, forever. 'j' with no argument is an error. $ man 1 make https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/V1_chap12.html
[toc] | [prev] | [next] | [standalone]
| From | richard@cogsci.ed.ac.uk (Richard Tobin) |
|---|---|
| Date | 2025-10-30 18:29 +0000 |
| Message-ID | <10e0aq5$19ork$1@artemis.inf.ed.ac.uk> |
| In reply to | #394974 |
In article <jhNMQ.1338175$Jgh9.1030888@fx15.iad>, Scott Lurndal <slp53@pacbell.net> wrote: >>Eww. How does make distinguish between j with an argument and >>j with no argument and a target? >$ man 3 getopt > >Standard unix semantics since, well, forever. 'j' with >no argument is an error. The upstream articles refer to Gnu make, which evidently does not conform to that. -- Richard
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2025-10-30 18:37 +0000 |
| Message-ID | <HfOMQ.933568$p8E9.323302@fx18.iad> |
| In reply to | #394977 |
richard@cogsci.ed.ac.uk (Richard Tobin) writes: >In article <jhNMQ.1338175$Jgh9.1030888@fx15.iad>, >Scott Lurndal <slp53@pacbell.net> wrote: > >>>Eww. How does make distinguish between j with an argument and >>>j with no argument and a target? > >>$ man 3 getopt >> >>Standard unix semantics since, well, forever. 'j' with >>no argument is an error. > >The upstream articles refer to Gnu make, which evidently does not >conform to that. Yes, unfortunately the GNU people totally screwed up the pption rules. Particuarly with word options rather than simple single letters. If a utility requires more than 52 options, it should be split into multiple utilities. Then there are the application programmers with a windows backround who never learned the rules.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-10-30 13:21 -0700 |
| Message-ID | <87v7jw5eek.fsf@example.invalid> |
| In reply to | #394972 |
richard@cogsci.ed.ac.uk (Richard Tobin) writes:
> In article <10dv52b$3gq3j$1@dont-email.me>,
> Richard Heathfield <rjh@cpax.org.uk> wrote:
>
>>$time make -j $(nproc)
>
> Eww. How does make distinguish between j with an argument and
> j with no argument and a target?
>
> $ make -j a
> make: *** No rule to make target 'a'. Stop.
> $ make -j 3
> make: *** No targets specified and no makefile found. Stop.
> $ make 3
> cc 3.c -o 3
>
> That's a really bad idea.
Meh.
The data structure that defines the '-j' option in the GNU make
source is:
static struct command_switch switches[] =
{
// ...
{ 'j', positive_int, &arg_job_slots, 1, 1, 0, 0, &inf_jobs, &default_job_slots,
"jobs", 0 },
//...
};
Yes, it's odd that "-j" may or may not be followed by an argument.
The way it works is that if the following argument exists and is
(a string representing) a positive integer, it's taken as "-j N",
otherwise it's taken as just "-j".
A make argument that's not an option is called a "target"; for
example in "make -j 4 foo", "foo" is the target. A target whose name
is a positive integer is rare enough that the potential ambiguity
is almost never an issue. If it is, you can use the long form:
"make --jobs" or "make --jobs=N".
I think it would have been cleaner if the argument to "-j" had
been mandatory, with an argument of "0", "-1", or "max" having
some special meaning. But changing it could break existing scripts
that invoke "make -j" (though as I've written elsethread, "make -j"
can cause problems).
It would also have been nice if the "make -j $(nproc)" functionality
had been built into make.
The existing behavior is a bit messy, but it works, and I've never
run into any actual problems with the way the options are parsed.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2025-10-31 07:44 +0100 |
| Message-ID | <10e1lst$92jg$1@dont-email.me> |
| In reply to | #394980 |
On 30.10.2025 21:21, Keith Thompson wrote:
> [...]
>
> The data structure that defines the '-j' option in the GNU make
> source is:
>
> static struct command_switch switches[] =
> {
> // ...
> { 'j', positive_int, &arg_job_slots, 1, 1, 0, 0, &inf_jobs, &default_job_slots,
> "jobs", 0 },
> //...
> };
>
> Yes, it's odd that "-j" may or may not be followed by an argument.
> The way it works is that if the following argument exists and is
> (a string representing) a positive integer, it's taken as "-j N",
> otherwise it's taken as just "-j".
Incidentally in some recent (<2 years past) "C" program I needed
a lot of options to control the software. When I looked into the
man pages of getopt(3) in my GNU/Linux environment I noticed the
"optional optarg" capability of this 'getopt' version and I used
it deliberately for good reasons. - The opt-string specification
for this feature was done with a double-colon, as defined in
"s::d:f:r:g::u:a::m::kt::lqj::p::nci:o:"
for the program syntax
[-s[wxh]] [-d density] [-f pattern] [-r seed] [-g[ngen]] [-u rule]
[-a[gen]] [-m[rate]] [-k|-t[sec]|-l|-q] [-j[n]] [-p[symbol]|-n|-c]
[-i infile] [-o outfile]
The disambiguation with program arguments or other options was done
by writing _no space_ between the option letter and the optional
option-argument. So you could write, e.g., -j, or -j1, but not -j 1
(for those options that could have optional arguments).
I cannot tell, though, whether GNU make did use this getopt feature
similarly (or whether it had coded some ad hoc heuristic parsing).
>
> A make argument that's not an option is called a "target"; for
> example in "make -j 4 foo", "foo" is the target. A target whose name
> is a positive integer is rare enough that the potential ambiguity
> is almost never an issue. If it is, you can use the long form:
> "make --jobs" or "make --jobs=N".
>
> I think it would have been cleaner if the argument to "-j" had
> been mandatory, with an argument of "0", "-1", or "max" having
> some special meaning. But changing it could break existing scripts
> that invoke "make -j" (though as I've written elsethread, "make -j"
> can cause problems).
I agree with having an explicit option argument would be clearer.
In my case above (and I don't know about the 'make' case discussed
in this thread) the -j had another semantics than -j0 (or such); I
needed both possibilities. So the option would have been (for me)
to add another (unrelated) option name from the very few remaining
letters and the choice would then have been arbitrary/non-mnemonic.
(For reasons I also didn't want to introduce long option names.)
>
> It would also have been nice if the "make -j $(nproc)" functionality
> had been built into make.
Yes. - This is actually how I'd have (with GNU 'getopt') designed it;
make (one instance), make -j (use max. available), make -j N (use N).
(Personally I dislike using the "C" programming pattern '-1' on the
user interface level to indicate "maximum" or some such.)
> The existing behavior is a bit messy, but it works, and I've never
> run into any actual problems with the way the options are parsed.
(I've never had any speed issues with make, so I've never used -j;
despite it comes "for free". - But I've also no 64 kernel CPUs or
MLOC-sized projects at home.)
Janis
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2025-10-31 07:49 +0100 |
| Message-ID | <10e1m5l$92jg$2@dont-email.me> |
| In reply to | #394998 |
On 31.10.2025 07:44, Janis Papanagnou wrote: > > (I've never had any speed issues with make, so I've never used -j; > despite it comes "for free". - But I've also no 64 kernel CPUs or > MLOC-sized projects at home.) Oops! - s/kernel/core/ > Janis >
[toc] | [prev] | [next] | [standalone]
Page 4 of 10 — ← Prev page 1 2 3 [4] 5 6 … 10 Next page →
Back to top | Article view | comp.lang.c
csiph-web