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 2 of 10 — ← Prev page 1 [2] 3 4 … 10 Next page →
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2025-10-26 17:03 +0000 |
| Message-ID | <10dlk9s$4rtu$2@dont-email.me> |
| In reply to | #394742 |
On 26/10/2025 16:07, Scott Lurndal wrote: > bart <bc@freeuk.com> writes: >> On 26/10/2025 11:26, bart wrote: >>> On 26/10/2025 06:25, Janis Papanagnou wrote: > >> >> So the following are after a restart of my PC: >> >> Build CDECL under WSL (files were extracted before the restart): >> 60/56 seconds instead 35/49 seconds for configure/make >> >> My demo above running both compiler and interpreter from source: >> 0.31 seconds instead of 0.21 seconds >> >> New test of gcc compiling hello.c: >> 1 second, settling down to 0.23 seconds on subsequent builds > > Get back to us when your "build + compiler" system will successfully > build all the software that currently builds with autoconf, make and gcc. So you are telling me it is IMPOSSIBLE to build a product with the specification of CDECL, entirely in portable C? You HAVE to use all those extra utilities, macro languages and what-not? Obviously, 'all the software' that currently builds with those tools will have been designed and developed *with* those tools; they will be essential dependencies.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2025-10-26 16:04 +0000 |
| Message-ID | <gErLQ.764129$80J6.497205@fx12.iad> |
| In reply to | #394736 |
bart <bc@freeuk.com> writes: >On 26/10/2025 06:25, Janis Papanagnou wrote: > >However the A68G configure script is 11000 lines; the CDECL one 31600 lines. > >(I wonder why the latter needs 20000 more lines? I guess nobody is >curious - or they simply don't care.) You should be able to figure that out yourself. You may actually learn something useful along the way. Start with reading the autoconf documentation, fully, until you understand the goals and the mechanisms used to meet those goals. www.gnu.org/software/autoconf/manual/autoconf.html
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2025-10-26 16:58 +0000 |
| Message-ID | <10dljv9$4rtu$1@dont-email.me> |
| In reply to | #394741 |
On 26/10/2025 16:04, Scott Lurndal wrote: > bart <bc@freeuk.com> writes: >> On 26/10/2025 06:25, Janis Papanagnou wrote: > >> >> However the A68G configure script is 11000 lines; the CDECL one 31600 lines. >> >> (I wonder why the latter needs 20000 more lines? I guess nobody is >> curious - or they simply don't care.) > > You should be able to figure that out yourself. You may actually > learn something useful along the way. So you don't know. What special requirements does CDECL have (which has a task that is at least a magnitude simpler than A68G's), that requires those 20,000 extra lines? > Start with reading the autoconf documentation, fully, until you > understand the goals and the mechanisms used to meet those goals. > > www.gnu.org/software/autoconf/manual/autoconf.html Whatever the goals are, if they are even needed, the execution is poor. That is even acknowledged in your link: "(Before each check, they print a one-line message stating what they are checking for, so the user doesn’t get too bored while waiting for the script to finish.)" That document is a classic example of making a fantastically complicated mountain out of a molehill.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <643-408-1753@kylheku.com> |
|---|---|
| Date | 2025-10-26 17:27 +0000 |
| Message-ID | <20251026101622.519@kylheku.com> |
| In reply to | #394743 |
On 2025-10-26, bart <bc@freeuk.com> wrote: > On 26/10/2025 16:04, Scott Lurndal wrote: >> bart <bc@freeuk.com> writes: >>> On 26/10/2025 06:25, Janis Papanagnou wrote: >> >>> >>> However the A68G configure script is 11000 lines; the CDECL one 31600 lines. >>> >>> (I wonder why the latter needs 20000 more lines? I guess nobody is >>> curious - or they simply don't care.) >> >> You should be able to figure that out yourself. You may actually >> learn something useful along the way. > > > So you don't know. > > What special requirements does CDECL have (which has a task that is at > least a magnitude simpler than A68G's), that requires those 20,000 extra > lines? I can't imagine why anyone would write cdecl (if it is written in C) such that it's anything but a maximally conforming ISO C program, which can be built like this: make cdecl without any Makefile present, in a directory in which there is just one file: cdecl.c. An empty ./configure script can be provided so that downstream package maintainers are less confused by the simplicity: #!/bin/sh echo cdecl succesfully configured; run make There may be additional material for testing, of course. >> www.gnu.org/software/autoconf/manual/autoconf.html > Whatever the goals are, if they are even needed, the execution is poor. > That is even acknowledged in your link: > > "(Before each check, they print a one-line message stating what they are > checking for, so the user doesn’t get too bored while waiting for the > script to finish.)" > > That document is a classic example of making a fantastically complicated > mountain out of a molehill. It's a pile of crap developed by (and for) imbeciles, which made a certain small amount of sense 30+ years ago when the Unix landscape was a much more fragmented mess than it is now. When you write a file called Makefile.am, it's like taping a piece of paper to your ass saying "kick me with an ugly mountain of technical debt which doesn't contribute a fucking thing to my actual application logic". -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2025-10-26 22:49 +0200 |
| Message-ID | <20251026224926.00000313@yahoo.com> |
| In reply to | #394745 |
On Sun, 26 Oct 2025 17:27:06 -0000 (UTC) Kaz Kylheku <643-408-1753@kylheku.com> wrote: > On 2025-10-26, bart <bc@freeuk.com> wrote: > > On 26/10/2025 16:04, Scott Lurndal wrote: > >> bart <bc@freeuk.com> writes: > >>> On 26/10/2025 06:25, Janis Papanagnou wrote: > >> > >>> > >>> However the A68G configure script is 11000 lines; the CDECL one > >>> 31600 lines. > >>> > >>> (I wonder why the latter needs 20000 more lines? I guess nobody is > >>> curious - or they simply don't care.) > >> > >> You should be able to figure that out yourself. You may actually > >> learn something useful along the way. > > > > > > So you don't know. > > > > What special requirements does CDECL have (which has a task that is > > at least a magnitude simpler than A68G's), that requires those > > 20,000 extra lines? > > I can't imagine why anyone would write cdecl (if it is written in C) > such that it's anything but a maximally conforming ISO C program, > which can be built like this: > > make cdecl > > without any Makefile present, in a directory in which there is just > one file: cdecl.c. > > An empty ./configure script can be provided so that downstream package > maintainers are less confused by the simplicity: > > #!/bin/sh > echo cdecl succesfully configured; run make > > There may be additional material for testing, of course. > > >> www.gnu.org/software/autoconf/manual/autoconf.html > > Whatever the goals are, if they are even needed, the execution is > > poor. That is even acknowledged in your link: > > > > "(Before each check, they print a one-line message stating what > > they are checking for, so the user doesn’t get too bored while > > waiting for the script to finish.)" > > > > That document is a classic example of making a fantastically > > complicated mountain out of a molehill. > > It's a pile of crap developed by (and for) imbeciles, which made a > certain small amount of sense 30+ years ago when the Unix landscape > was a much more fragmented mess than it is now. > > When you write a file called Makefile.am, it's like taping a piece > of paper to your ass saying "kick me with an ugly mountain of > technical debt which doesn't contribute a fucking thing to my actual > application logic". >
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2025-10-26 23:07 +0200 |
| Message-ID | <20251026230711.00002e4f@yahoo.com> |
| In reply to | #394745 |
On Sun, 26 Oct 2025 17:27:06 -0000 (UTC) Kaz Kylheku <643-408-1753@kylheku.com> wrote: > On 2025-10-26, bart <bc@freeuk.com> wrote: > > On 26/10/2025 16:04, Scott Lurndal wrote: > >> bart <bc@freeuk.com> writes: > >>> On 26/10/2025 06:25, Janis Papanagnou wrote: > >> > >>> > >>> However the A68G configure script is 11000 lines; the CDECL one > >>> 31600 lines. > >>> > >>> (I wonder why the latter needs 20000 more lines? I guess nobody is > >>> curious - or they simply don't care.) > >> > >> You should be able to figure that out yourself. You may actually > >> learn something useful along the way. > > > > > > So you don't know. > > > > What special requirements does CDECL have (which has a task that is > > at least a magnitude simpler than A68G's), that requires those > > 20,000 extra lines? > > I can't imagine why anyone would write cdecl (if it is written in C) > such that it's anything but a maximally conforming ISO C program, > which can be built like this: > > make cdecl > > without any Makefile present, in a directory in which there is just > one file: cdecl.c. > You are exaggerating. There is nothing wrong with multiple files and small nice manually written Makefile. Esp. if you expect from [small percentage of] your users to not just compile your code, but to make modifications. Who knows, may be even to contribute changes to project. > An empty ./configure script can be provided so that downstream package > maintainers are less confused by the simplicity: > > #!/bin/sh > echo cdecl succesfully configured; run make > > There may be additional material for testing, of course. > > >> www.gnu.org/software/autoconf/manual/autoconf.html > > Whatever the goals are, if they are even needed, the execution is > > poor. That is even acknowledged in your link: > > > > "(Before each check, they print a one-line message stating what > > they are checking for, so the user doesn’t get too bored while > > waiting for the script to finish.)" > > > > That document is a classic example of making a fantastically > > complicated mountain out of a molehill. > > It's a pile of crap developed by (and for) imbeciles, which made a > certain small amount of sense 30+ years ago when the Unix landscape > was a much more fragmented mess than it is now. > 30 years ago things already were not THAT bad. 32-33 years ago - may be. I remember Sun workstation with no C90 compiler in 1993. Even if sub-C90 compilers were still around 30 years ago then the correct behavior on part of devs should have been to help to these compilers and to their vendors to die ASAP instead of helping them to continue making life of poor programmers miserable. In that regard autotools resemble Postel's principle - the most harmful idea that ever happened to networking and one of the more harmful for computing at large.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <643-408-1753@kylheku.com> |
|---|---|
| Date | 2025-10-28 18:01 +0000 |
| Message-ID | <20251028105127.473@kylheku.com> |
| In reply to | #394748 |
On 2025-10-26, Michael S <already5chosen@yahoo.com> wrote: >> I can't imagine why anyone would write cdecl (if it is written in C) >> such that it's anything but a maximally conforming ISO C program, >> which can be built like this: >> >> make cdecl >> >> without any Makefile present, in a directory in which there is just >> one file: cdecl.c. >> > > You are exaggerating. > There is nothing wrong with multiple files and small nice manually Yes, I'm exaggerating; of course I can imagine using more than one file for cdecl. I would say that if you need two files to write cdecl, and one of them is not an accurate grammar file for a parser generator (needing to be a spearate file due to being in that notation), which handles things int (*p)(int (*q)(void * const x)), you've massively fucked it up. > In that regard autotools resemble Postel's principle - the most harmful Postel's principle is awful, requiring paragraphs of apologetic defense to explain what Postel really meant and how it made sense in his context, so that it wasn't actually idiotic. Programs should be conservative in what they generate, and loudly reject any input that is out of spec. Programs that accept crap are good for business, because naive customers just see that those programs "work" with some input that other programs "don't handle". They are harmful to the ecosystem, creating a race for the bottom competition in which specs fall by the wayside while programs struggle to handle buggy inputs, and nobody knows what is correct any more. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2025-10-29 20:33 +0000 |
| Message-ID | <10dttm1$3o2sg$1@paganini.bofh.team> |
| In reply to | #394743 |
bart <bc@freeuk.com> wrote:
> On 26/10/2025 16:04, Scott Lurndal wrote:
>> bart <bc@freeuk.com> writes:
>>> On 26/10/2025 06:25, Janis Papanagnou wrote:
>>
>>>
>>> However the A68G configure script is 11000 lines; the CDECL one 31600 lines.
>>>
>>> (I wonder why the latter needs 20000 more lines? I guess nobody is
>>> curious - or they simply don't care.)
>>
>> You should be able to figure that out yourself. You may actually
>> learn something useful along the way.
>
>
> So you don't know.
>
> What special requirements does CDECL have (which has a task that is at
> least a magnitude simpler than A68G's), that requires those 20,000 extra
> lines?
I did not look deeply, but cdecl is using automake and related
tools. IIUC you can have small real source, and depend on
autools to provide tests. This is likely to bring tons of
irrelevant tests into configure. Or you can specify precisely
which tests are needed. In the second case you need to
write more code, but generated configure is smaller.
My working hypotesis is that cdecl is relatively simple program,
so autotools defaults lead to working build. And nobody was
motiveted enough to select what is needed, so configure
contains a lot of code which is useful sometimes, but probably
not for cdel.
BTW: In one "my" project there is hand-written configure.ac
which is select tests that are actually needed for the
project. Automake in _not_ used. Generated configure
has 8564 lines. But the project has rather complex
requirements and autotools defaults are unlikely to
work, so one really have to explicitly handle various
details.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2025-10-29 23:29 +0000 |
| Message-ID | <10du816$39jdl$2@dont-email.me> |
| In reply to | #394941 |
On 29/10/2025 20:33, Waldek Hebisch wrote: > bart <bc@freeuk.com> wrote: >> On 26/10/2025 16:04, Scott Lurndal wrote: >>> bart <bc@freeuk.com> writes: >>>> On 26/10/2025 06:25, Janis Papanagnou wrote: >>> >>>> >>>> However the A68G configure script is 11000 lines; the CDECL one 31600 lines. >>>> >>>> (I wonder why the latter needs 20000 more lines? I guess nobody is >>>> curious - or they simply don't care.) >>> >>> You should be able to figure that out yourself. You may actually >>> learn something useful along the way. >> >> >> So you don't know. >> >> What special requirements does CDECL have (which has a task that is at >> least a magnitude simpler than A68G's), that requires those 20,000 extra >> lines? > > I did not look deeply, but cdecl is using automake and related > tools. IIUC you can have small real source, and depend on > autools to provide tests. This is likely to bring tons of > irrelevant tests into configure. Or you can specify precisely > which tests are needed. In the second case you need to > write more code, but generated configure is smaller. > > My working hypotesis is that cdecl is relatively simple program, > so autotools defaults lead to working build. And nobody was > motiveted enough to select what is needed, so configure > contains a lot of code which is useful sometimes, but probably > not for cdel. > > BTW: In one "my" project there is hand-written configure.ac > which is select tests that are actually needed for the > project. Automake in _not_ used. Generated configure > has 8564 lines. But the project has rather complex > requirements and autotools defaults are unlikely to > work, so one really have to explicitly handle various > details. > I have a project coming up next month: a subset of my C compiler, which is not written in C, being ported to actual C. What I'm thinking of doing is taking part of that project, and creating a standalone program that does the 'explain' part of cdecl, and only for C, not C++. This would not worth doing by itself. Then I can make that available to see how it looks and how it builds. But I do not expect it to need anything other than a C compiler, and it should work on any OS (it needs only a keyboard and a display).
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-10-26 16:07 -0700 |
| Message-ID | <87ikg1z2hq.fsf@example.invalid> |
| In reply to | #394736 |
bart <bc@freeuk.com> writes:
[...]
> However the A68G configure script is 11000 lines; the CDECL one 31600 lines.
>
> (I wonder why the latter needs 20000 more lines? I guess nobody is
> curious - or they simply don't care. OK, let's make 100,000 and see if
> anyone complains! Is it possible this is some elaborate joke on the
> part of auto-conf to discover just how trusting and tolerant people
> can be?)
Yes, that's pretty much it. Most of us really don't care why
one configure script is longer than another. I've run both, and
they work. I went off and did other things while they were running,
so I didn't even notice how long they took. (It was a few seconds
for each.)
On the other hand, you apparently do care about all this -- but
you've done nothing useful to learn about it. You merely complain
incessantly *for years* to people who are not in a position to do
anything about it. And when we point you to forums where you could
ask about it, or even make some useful contribution, you ignore us.
What most of the people you're talking to have in common is that
we know the C language and are interested in discussing it.
We aren't GNU autotools maintainers. We didn't write cdecl
(all I did was announce a new version written by someone else).
I've never written anything that uses GNU autotools. I don't know
what you're expecting to accomplish here.
Do you disagree with any of the above?
--
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-27 03:08 +0100 |
| Message-ID | <10dmk77$egg1$1@dont-email.me> |
| In reply to | #394736 |
On 26.10.2025 12:26, bart wrote: > On 26/10/2025 06:25, Janis Papanagnou wrote: >> (This reply is not meant for bart, but rather for all interested >> folks who should not get repelled by his FUD posts.) >> >> On 25.10.2025 00:18, bart wrote: >>> [...] >>> >>> (I remember trying to build A68G, an interpreter, on Windows, and the >>> 'configure' step was a major obstacle. But I was willing to isolate the >>> 12 C source files involved, then it was built in one second. >>> >>> I did of course try building it in Linux too, and it took about 5 >>> minutes that I recall, using a spinnning hard drive, mostly spent >>> running through that configure script. >> >> (I don't know what system or system configuration the poster runs. >> I'm well aware that if you are using the Windows platform you may >> suffer from many things; but the platform choice is your decision! >> But maybe he's just misremembering; and nonetheless spreading FUD.) >> >> I've a quite old (~16+ years old) Linux system that was back these >> days when I bought it already at the _very low performance range_. >> With this old system the ./configure needs less than 10 seconds, >> and the build process with make about _half a minute_ for the whole >> a68g Genie system. - The whole procedure, from software download, >> extraction, configure/make, and start an Algol application, needs >> one minute! (Make that two minutes if you are typing v_e_r_y slowly >> or have a slow download link. Or just put the necessary commands in >> a shell file; just did that and it needed (including the download) >> less than 45 seconds, and ready to run.) > > > The 5 minutes I quoted may have been for CPython. It would be for some > Linux running under VirtualBox on a 2010 cheapest-in-the-shop PC. > > If I try A68G now, under WSL, using a 2021 second-cheapest PC but with > SSD, I get: > > ./configure 20 seconds > make 90 seconds Have you examined what WSL and Windows is adding to your numbers? (As I've noted several times already I'd not be surprised if your platform contributes to your disappointment here.) And you've seen my numbers. (Older PC, no SSDs, etc. - but Unix.) (But I also don't think that SSDs would here any significant impact have. - But, yes, I know you're counting "quality" in microseconds (while completely ignoring other more important factors), so it may be important for you; I acknowledge that.) > > Trying CDECL again (I've done it several times after deleting the folder): > > ./configure 35 seconds > make 49 seconds > > However the A68G configure script is 11000 lines; the CDECL one 31600 > lines. > > (I wonder why the latter needs 20000 more lines? I guess nobody is > curious - or they simply don't care. OK, let's make 100,000 and see if > anyone complains! Is it possible this is some elaborate joke on the part > of auto-conf to discover just how trusting and tolerant people can be?) Frankly, I don't know what features 'cdecl' actually all supports. And, honestly, I understand that you want _for a simple task_ no overhead in any case. From the posts here I've got the impression that 'cdecl' might do a bit more than you expect; no? To judge any misuse of resources or any unjustified complexity we'd need to know the intention of the tools, its feature coverage, and platforms supported. If there's something to enhance there's luckily options you have, issue bug/feature requests, or (in case of open source), you could change the things that you think are "obviously wrong". > > > Anyway, I then tried this new 3.10 A68G on the Fannkuch(9) benchmark: > > a68g fann.a68 5 seconds > ./fann 3+3 seconds (via a68g --compile -O3 fann.a68) > > I then tried it under my scripting language (not statically typed): > > qq fann 0.4 seconds (qq built with my non-optimising compiler) Your 'qq' is an Algol 68 implementation? (If not then you're comparing apples to oranges!) > > 'qq' takes about 0.1 seconds to build - under Windows which is > considered slow for development. So, 1000 times faster to build, and it > runs this program at least, 10 times faster, despite being dynamically > typed. > > This is the vast difference between my world and yours. If 'qq' is some language unrelated to Algol 68 this difference tells nothing. (So please clarify. - Or else stop vacuous comparisons.) > >>The whole procedure, from software download, >> extraction, configure/make, and start an Algol application, needs >> one minute! > > Only one minute; impressive! Is that meant ironic/sarcastic? - Remember I was replying to your FUD and misinformation post that purported that the Genie compile process would have required five minutes! > How about this: > > c:\qx>tm mm -r \mx\mm -r qq hello > Hello World > TM: 0.21 (This doesn't tell me anything. But most likely it's anyway irrelevant on the Algol 68 topic - or rather non-topic - that you've made up.) > > This runs my systems language /from source code/, whch then runs my > interpreter /from source code/ (ie. compiles into memory and runs > immediately) then runs that test program. > > In 1/5th of a second (or 1/300th of a minute). This is equivalent to > first compiling gcc from source (and all those extra utilities you seem > to need) before using it/them to build a68g. I guess that would take a > bit more than a minute. So you're again advertising your personal language and tools. - I'm not interested in non-standard language (or Windows-) tools, as you've been told so many times (also by others). The tools I'm using for my personal purposes, and those that I had been using for professional purposes, all served the necessary requirements. Your's don't. Janis
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2025-10-27 12:50 +0000 |
| Message-ID | <10dnprf$qmrg$1@dont-email.me> |
| In reply to | #394761 |
On 27/10/2025 02:08, Janis Papanagnou wrote:
> On 26.10.2025 12:26, bart wrote:
>> The 5 minutes I quoted may have been for CPython. It would be for some
>> Linux running under VirtualBox on a 2010 cheapest-in-the-shop PC.
>>
>> If I try A68G now, under WSL, using a 2021 second-cheapest PC but with
>> SSD, I get:
>>
>> ./configure 20 seconds
>> make 90 seconds
>
> Have you examined what WSL and Windows is adding to your numbers?
It could well be that Windows' file system is less efficient than pure
Linux (and WSL has to presumably work on top of that). But, that is my
platform.
If I try a pure Linux system (RPi4 with solid-state storage, which
normally runs at 1/3 the speed of my PC), then I get:
./configure 16.5 seconds
make 137 seconds
There are a few extra checks made in WSL configure, but not many (195
logged lines vs 187).
> (As I've noted several times already I'd not be surprised if your
> platform contributes to your disappointment here.)
>
> And you've seen my numbers. (Older PC, no SSDs, etc. - but Unix.)
Yes, but: the development and build procedures HAVE BEEN BUILT AROUND UNIX.
So they are utterly dependent on them. So much so that it is pretty much
impossible to build this stuff on any non-UNIX environment, unless that
environment is emulated. That is what happens with WSL, MSYS2, CYGWIN.
>> Anyway, I then tried this new 3.10 A68G on the Fannkuch(9) benchmark:
>>
>> a68g fann.a68 5 seconds
>> ./fann 3+3 seconds (via a68g --compile -O3 fann.a68)
>>
>> I then tried it under my scripting language (not statically typed):
>>
>> qq fann 0.4 seconds (qq built with my non-optimising compiler)
>
> Your 'qq' is an Algol 68 implementation?
> (If not then you're comparing apples to oranges!)
You've never, ever seen benchmarks comparing one language implementation
with another?
'qq' implements a pure interpreter for a dynamically typed language.
Algol68 is statically typed, which ought to give it the edge. It can be
interpreted (the 5s figure) or compiled to native code (the 3s figure,
and it takes 3s to compile this 60-line program), which here makes
little difference.
So for all that trouble, A68G's performance is indifferent. If you don't
care for my language, then here some other timings:
A68G -O3/comp 6 seconds (3s to compile + 3s runtime)
A68G 5
CPython 3.14: 1.2
Lua 5.4 0.65
qq 0.4
(qq/opt 0.3 Optimised via C transpilation and gcc-O2)
PyPy 3.8: 0.2
LuaJIT: 0.12
The 0.2/0.12 timings are from JIT-accelerated versions.
>>
>> 'qq' takes about 0.1 seconds to build - under Windows which is
>> considered slow for development. So, 1000 times faster to build, and it
>> runs this program at least, 10 times faster, despite being dynamically
>> typed.
>>
>> This is the vast difference between my world and yours.
>
> If 'qq' is some language unrelated to Algol 68 this difference tells
> nothing. (So please clarify. - Or else stop vacuous comparisons.)
The task here is evaluating 'fannkuch(9)', using the same algorithm in
each case.
A68G is poor on this benchmark. Other interpreted solutions are faster.
It is disappointing after taking all that effort to build.
> So you're again advertising your personal language and tools. - I'm not
> interested in non-standard language (or Windows-) tools, as you've been
> told so many times (also by others).
Here's an example not related to my stuff:
c:\cx>tim tcc lua.c
Time: 0.120
This builds the Lua intepreter in 1/8th of a second. Now, Tiny C
generally produces indifferent code (ie. slow). Still, I get this result
from my benchmark:
Lua 5.4 0.65 (lua.exe built using Tiny C)
It's still at least FIVE TIMES FASTER than A68G!
> The tools I'm using for my personal purposes, and those that I had been
> using for professional purposes, all served the necessary requirements.
> Your's don't.
I'm just showing just how astonishingly fast modern hardware can be.
Like at least a thousand times faster than a 1970s mainframe, and yet
people are still waiting on compilers!
But if you're happy with the performance of your tools, then that's fine.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2025-10-27 12:58 +0000 |
| Message-ID | <10dnq9e$qmrg$2@dont-email.me> |
| In reply to | #394784 |
On 27/10/2025 12:50, bart wrote:
> Lua 5.4 0.65
> Here's an example not related to my stuff:
>
> c:\cx>tim tcc lua.c
> Time: 0.120
>
> This builds the Lua intepreter in 1/8th of a second. Now, Tiny C
> generally produces indifferent code (ie. slow). Still, I get this result
> from my benchmark:
>
> Lua 5.4 0.65 (lua.exe built using Tiny C)
>
> It's still at least FIVE TIMES FASTER than A68G!
Oops! I forgot to update the timing after copying that line. The proper
figure should be:
Lua 5.4 1.5 seconds
So, sorry it's only 3 times as fast as A68G! And only twice as fast as
compiled A68G code, if you forget about the latter's compilation time.
Here, also, you can build the Lua interpreter from source each time
(adding 0.12 seconds), and it would *still* be faster than A68G.
Not impressed? I thought not.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2025-10-27 14:45 +0100 |
| Message-ID | <10dnt18$rnfr$1@dont-email.me> |
| In reply to | #394785 |
On 27.10.2025 13:58, bart wrote: > On 27/10/2025 12:50, bart wrote: > >> Lua 5.4 0.65 > >> Here's an example not related to my stuff: >> >> c:\cx>tim tcc lua.c >> Time: 0.120 >> >> This builds the Lua intepreter in 1/8th of a second. Now, Tiny C >> generally produces indifferent code (ie. slow). Still, I get this >> result from my benchmark: >> >> Lua 5.4 0.65 (lua.exe built using Tiny C) >> >> It's still at least FIVE TIMES FASTER than A68G! > > Oops! I forgot to update the timing after copying that line. The proper > figure should be: > > Lua 5.4 1.5 seconds > And what have you gained or lost in practice by this 0.85 seconds delta? (Clearly, you're wasting your time on marginalities! And thereby completely missing or ignoring the more important factors.) > > So, sorry it's only 3 times as fast as A68G! And only twice as fast as > compiled A68G code, if you forget about the latter's compilation time. > > Here, also, you can build the Lua interpreter from source each time > (adding 0.12 seconds), and it would *still* be faster than A68G. Lua is not Algol 68. (Again comparing apples to oranges! Or just another try of a red herring.) > > Not impressed? I thought not. I'm sure non-dimensionally thinking folks may be impressed. Janis
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2025-10-27 14:48 +0100 |
| Message-ID | <10dnt83$rnfr$2@dont-email.me> |
| In reply to | #394789 |
On 27.10.2025 14:45, Janis Papanagnou wrote: > On 27.10.2025 13:58, bart wrote: > [...] >> >> Not impressed? I thought not. > > I'm sure non-dimensionally thinking folks may be impressed. Should have been: I'm sure one-dimensionally thinking folks may be impressed. > > Janis >
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2025-10-27 15:23 +0000 |
| Message-ID | <10do2ok$u17l$2@dont-email.me> |
| In reply to | #394789 |
On 27/10/2025 13:45, Janis Papanagnou wrote: > On 27.10.2025 13:58, bart wrote: >> On 27/10/2025 12:50, bart wrote: >> >>> Lua 5.4 0.65 >> >>> Here's an example not related to my stuff: >>> >>> c:\cx>tim tcc lua.c >>> Time: 0.120 >>> >>> This builds the Lua intepreter in 1/8th of a second. Now, Tiny C >>> generally produces indifferent code (ie. slow). Still, I get this >>> result from my benchmark: >>> >>> Lua 5.4 0.65 (lua.exe built using Tiny C) >>> >>> It's still at least FIVE TIMES FASTER than A68G! >> >> Oops! I forgot to update the timing after copying that line. The proper >> figure should be: >> >> Lua 5.4 1.5 seconds >> > > And what have you gained or lost in practice by this 0.85 seconds > delta? > (Clearly, you're wasting your time on marginalities! And thereby > completely missing or ignoring the more important factors.) You're subtracting 0.65 from 1.5 instead of dividing it? That's unusual, but OK, let's go with that! 0.65 seconds represents the result of using gcc-O2, and 1.5 from using tcc. So you're saying there's little significant difference between them regarding the performance of the generated code. That's good to know.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2025-10-27 22:39 +0200 |
| Message-ID | <20251027223947.00002c37@yahoo.com> |
| In reply to | #394789 |
On Mon, 27 Oct 2025 14:45:11 +0100 Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote: > > Lua is not Algol 68. > Correct. Lua is a useful programming language. Algol 68 is a great source of inspiration for designers of programming languages. Useful programming language it is not.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2025-10-28 03:00 +0100 |
| Message-ID | <10dp84j$1g1ap$1@dont-email.me> |
| In reply to | #394820 |
On 27.10.2025 21:39, Michael S wrote: >> >> Lua is not Algol 68. > > Correct. > Lua is a useful programming language. (I have no stakes here. Never used it.) > Algol 68 is a great source of inspiration for designers of > programming languages. Obviously. > Useful programming language it is not. I have to read that as valuation of its usefulness for you. (Otherwise, if you're speaking generally, you'd be just wrong.) Janis
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2025-10-28 15:59 +0100 |
| Message-ID | <10dqloj$23lhj$1@dont-email.me> |
| In reply to | #394847 |
On 28/10/2025 03:00, Janis Papanagnou wrote: > On 27.10.2025 21:39, Michael S wrote: >>> >>> Lua is not Algol 68. >> >> Correct. >> Lua is a useful programming language. > > (I have no stakes here. Never used it.) > It's usefulness is demonstrated by its widespread use. It is mostly used as a scripting or automation language integrated in other software, rather than as a stand-alone language. It is particularly popular in the gaming industry. >> Algol 68 is a great source of inspiration for designers of >> programming languages. > > Obviously. > >> Useful programming language it is not. > > I have to read that as valuation of its usefulness for you. > (Otherwise, if you're speaking generally, you'd be just wrong.) > The uselessness of Algol 68 as a programming language in the modern world is demonstrated by the almost total non-existence of serious tools and, more importantly, real-world code in the language. It certainly /was/ a useful programming language, long ago, but it has not been seriously used outside of historical hobby interest for half a century. And unlike other ancient languages (like Cobol or Fortran) there is no code of relevance today written in the language. Original Algol was mostly used in research, while Algol 68 was mostly not used at all. As C.A.R. Hoare said, "As a tool for the reliable creation of sophisticated programs, the language was a failure". I'm sure there are /some/ people who have or will write real code in Algol 68 in modern times (the folks behind the new gcc Algol 68 front-end want to be able to write code in the language), but it is very much a niche language.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2025-10-28 16:05 +0000 |
| Message-ID | <vR5MQ.1323001$Jgh9.392698@fx15.iad> |
| In reply to | #394885 |
David Brown <david.brown@hesbynett.no> writes: >On 28/10/2025 03:00, Janis Papanagnou wrote: >> On 27.10.2025 21:39, Michael S wrote: >>>> >>>> Lua is not Algol 68. >>> >>> Correct. >>> Lua is a useful programming language. >> >> (I have no stakes here. Never used it.) >> > >It's usefulness is demonstrated by its widespread use. It is mostly >used as a scripting or automation language integrated in other software, >rather than as a stand-alone language. It is particularly popular in >the gaming industry. > >>> Algol 68 is a great source of inspiration for designers of >>> programming languages. >> >> Obviously. >> >>> Useful programming language it is not. >> >> I have to read that as valuation of its usefulness for you. >> (Otherwise, if you're speaking generally, you'd be just wrong.) >> > >The uselessness of Algol 68 as a programming language in the modern >world is demonstrated by the almost total non-existence of serious tools >and, more importantly, real-world code in the language. It certainly >/was/ a useful programming language, long ago, but it has not been >seriously used outside of historical hobby interest for half a century. >And unlike other ancient languages (like Cobol or Fortran) there is no >code of relevance today written in the language. Original Algol was >mostly used in research, while Algol 68 was mostly not used at all. As >C.A.R. Hoare said, "As a tool for the reliable creation of sophisticated >programs, the language was a failure". There is still one computer system that uses Algol as both the system programming language, and for applications. Unisys Clearpath (descendents of the Burroughs B6500).
[toc] | [prev] | [next] | [standalone]
Page 2 of 10 — ← Prev page 1 [2] 3 4 … 10 Next page →
Back to top | Article view | comp.lang.c
csiph-web