Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #379646 > unrolled thread
| Started by | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| First post | 2023-12-26 16:59 +0100 |
| Last post | 2024-01-08 22:20 -0800 |
| Articles | 20 on this page of 671 — 31 participants |
Back to article view | Back to comp.lang.c
Effect of CPP tags Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2023-12-26 16:59 +0100
Re: Effect of CPP tags Lowell Gilbert <lgusenet@be-well.ilk.org> - 2023-12-26 17:45 -0500
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2023-12-26 22:50 +0000
Re: Effect of CPP tags Spiros Bousbouras <spibou@gmail.com> - 2023-12-27 17:11 +0000
Re: Effect of CPP tags Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-12-31 14:45 -0800
Re: Effect of CPP tags Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2023-12-28 17:34 +0100
Re: Effect of CPP tags Lowell Gilbert <lgusenet@be-well.ilk.org> - 2023-12-28 14:11 -0500
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-12-28 13:13 -0800
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2023-12-28 21:47 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-12-28 15:12 -0800
Re: Effect of CPP tags Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-01-20 14:29 -0800
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-21 04:46 +0000
Re: Effect of CPP tags James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-01-21 10:56 -0500
Re: Effect of CPP tags James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-01-21 12:11 -0500
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-21 17:55 +0000
Re: Effect of CPP tags James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-01-21 21:57 -0500
Re: Effect of CPP tags Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-01-24 07:42 -0800
Re: Effect of CPP tags Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-01-31 12:43 -0800
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-31 13:41 -0800
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-02-01 09:19 +0100
Re: Effect of CPP tags Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-03-14 23:11 -0700
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-03-14 23:56 -0700
Re: Effect of CPP tags Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-03-14 23:12 -0700
Re: Effect of CPP tags Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-02-11 17:38 -0800
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2023-12-28 21:33 +0000
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2023-12-28 21:42 +0000
Re: Effect of CPP tags Lowell Gilbert <lgusenet@be-well.ilk.org> - 2023-12-28 18:04 -0500
Re: Effect of CPP tags Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2023-12-29 16:11 +0100
Re: Effect of CPP tags Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2023-12-29 16:04 +0100
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2023-12-29 17:51 +0000
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2023-12-28 21:22 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2023-12-29 15:52 +0000
Re: Effect of CPP tags Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2023-12-29 17:27 +0100
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-12-29 11:01 -0800
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2023-12-29 22:18 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2023-12-31 14:40 +0100
Re: Effect of CPP tags James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-12-31 12:43 -0500
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-01 12:57 +0100
Re: Effect of CPP tags Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-12-31 18:32 -0800
usleep (Was: Effect of CPP tags) gazelle@shell.xmission.com (Kenny McCormack) - 2023-12-29 18:10 +0000
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2023-12-29 02:35 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2023-12-29 13:31 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2023-12-29 15:58 +0100
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-12-29 10:33 -0800
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2023-12-29 20:23 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2023-12-29 22:40 +0000
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2023-12-30 01:28 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2023-12-30 01:58 +0000
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2023-12-31 01:36 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2023-12-31 02:06 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2023-12-31 18:33 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-01 13:09 +0100
Re: Effect of CPP tags BGB <cr88192@gmail.com> - 2024-01-03 00:20 -0600
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-01 12:49 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-02 09:11 +0100
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2023-12-31 21:41 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2023-12-31 16:25 +0100
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2023-12-31 15:45 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2023-12-31 18:40 +0000
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2023-12-31 18:44 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2023-12-31 19:37 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2023-12-31 22:00 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-12-31 16:03 -0800
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-01 02:58 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-12-31 19:18 -0800
Re: Effect of CPP tags Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-01 05:38 +0100
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-12-31 22:56 -0800
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-01 08:54 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2023-12-31 20:00 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-01 15:38 +0100
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2023-12-31 21:44 +0000
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-12-31 13:51 -0800
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-01 00:12 +0000
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-12-31 22:57 -0800
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-01 07:00 +0000
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-12-31 23:03 -0800
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-12-31 23:06 -0800
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-01 09:18 +0000
Re: Effect of CPP tags Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> - 2024-01-02 15:15 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-01 15:44 +0100
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-01 15:54 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-02 11:42 +0100
Re: Effect of CPP tags Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> - 2024-01-02 15:04 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-02 16:12 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-02 18:34 +0100
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-02 20:24 +0000
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-02 13:00 -0800
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-02 13:02 -0800
Re: Effect of CPP tags tTh <tth@none.invalid> - 2024-01-03 00:24 +0100
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-03 02:41 +0000
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-03 03:29 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-03 11:55 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-03 15:32 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-03 17:14 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-03 20:16 +0100
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-03 19:57 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-04 09:46 +0100
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-04 18:57 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-03 23:48 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-04 01:57 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-04 02:20 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-04 16:08 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-04 18:35 +0000
Re: Effect of CPP tags Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-04 20:55 +0100
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-04 20:17 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-04 15:22 -0800
Re: Effect of CPP tags Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-05 10:03 +0100
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-05 18:37 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-05 19:25 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-04 21:14 +0000
Re: Effect of CPP tags Jim Jackson <jj@franjam.org.uk> - 2024-01-04 22:07 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-04 22:48 +0000
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-04 23:14 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-04 23:48 +0000
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-04 23:25 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-05 01:53 +0000
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-05 04:53 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-05 15:05 +0100
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-05 07:58 -0800
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-05 17:34 +0100
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-05 18:42 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-06 08:39 +0100
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-18 19:15 +0000
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-18 13:21 -0800
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-19 10:06 +0100
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-05 16:29 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-05 18:44 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-05 19:33 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-05 20:06 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-05 14:50 -0800
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-06 01:09 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-05 17:55 -0800
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-07 01:00 +0000
Re: Effect of CPP tags Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-01-08 22:56 -0800
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-06 10:02 +0100
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-05 22:19 +0000
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-05 22:43 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-06 02:04 +0000
Re: Effect of CPP tags Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-01-05 23:02 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-06 01:45 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-05 18:17 -0800
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-06 10:09 +0100
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-06 10:27 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-06 15:23 +0100
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-06 13:40 -0800
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-07 00:09 +0000
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-07 00:16 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-06 16:40 -0800
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-07 00:58 +0000
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-07 03:30 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-07 15:48 +0100
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-07 15:34 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-08 13:50 +0100
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-08 15:53 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-08 20:50 +0100
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-09 01:05 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-09 08:30 +0100
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-09 11:11 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-09 15:56 +0100
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-09 17:46 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-09 19:56 +0100
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-09 20:52 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-09 13:15 -0800
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-09 21:33 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-09 21:55 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-09 22:22 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-10 09:37 +0100
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-10 12:12 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-10 14:17 +0100
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-10 14:31 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-10 16:51 +0100
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-10 18:57 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-10 20:55 +0100
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-10 20:49 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-11 11:26 +0100
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-10 19:19 -0800
Re: Effect of CPP tags tTh <tth@none.invalid> - 2024-01-11 00:30 +0100
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-11 01:14 +0000
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-10 19:25 -0800
Re: Effect of CPP tags Richard Harnden <richard.nospam@gmail.invalid> - 2024-01-11 17:56 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-11 18:31 +0000
Make (was: Re: Effect of CPP tags) vallor <vallor@cultnix.org> - 2024-01-15 21:01 +0000
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-11 02:29 +0000
Re: Effect of CPP tags tTh <tth@none.invalid> - 2024-01-10 17:46 +0100
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-10 14:51 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-10 17:58 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-10 19:16 +0000
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-10 19:30 -0800
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-10 20:27 +0100
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-09 14:22 -0800
Re: Effect of CPP tags James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-01-09 17:37 -0500
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-09 23:27 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-09 16:05 -0800
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-10 00:40 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-09 16:49 -0800
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-10 02:04 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-09 19:17 -0800
Re: Effect of CPP tags Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-01-14 09:26 -0800
Re: Effect of CPP tags James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-01-10 11:22 -0500
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-10 01:54 +0000
Re: Effect of CPP tags tTh <tth@none.invalid> - 2024-01-10 02:57 +0100
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-10 05:28 +0000
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-10 06:28 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-10 09:50 +0100
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-09 23:40 -0800
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-10 11:10 +0100
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-10 19:10 -0800
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-10 19:11 -0800
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-11 11:55 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-11 11:42 +0100
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-12 14:59 -0800
Re: Effect of CPP tags vallor <vallor@cultnix.org> - 2024-01-11 14:58 +0000
A good place to discuss Makefiles? (was Re: Effect of CPP tags) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-11 16:56 +0100
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-10 02:00 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-10 02:14 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-10 11:16 +0100
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-10 14:49 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-10 18:13 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-10 10:39 -0800
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-10 19:24 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-10 11:39 -0800
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-10 20:42 +0100
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-10 20:20 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-10 12:42 -0800
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-10 21:43 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-10 22:36 +0000
Re: Effect of CPP tags Paul <nospam@needed.invalid> - 2024-01-10 21:39 -0500
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-11 02:46 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-11 11:44 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-11 12:19 +0000
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-11 16:13 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-11 17:00 +0000
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-11 21:18 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-11 23:03 +0000
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-11 23:58 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-12 09:08 +0100
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-11 18:49 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-11 12:16 -0800
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-11 22:02 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-11 23:20 +0000
Re: Effect of CPP tags Anthony Cuozzo <anthony@cuozzo.us> - 2024-01-11 19:02 -0500
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-11 16:23 -0800
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-12 14:40 +0100
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-12 16:01 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-12 16:28 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-12 17:16 +0000
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-12 20:21 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-12 16:12 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-12 17:34 +0100
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-12 17:09 +0000
Re: Effect of CPP tags Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-12 19:02 +0100
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-12 21:01 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-12 13:07 -0800
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-12 21:51 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-13 00:13 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-12 16:47 -0800
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-13 01:12 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-12 17:40 -0800
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-13 15:07 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-13 16:02 +0000
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-13 04:17 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-13 12:03 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-13 13:42 -0800
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-13 22:39 +0000
Re: Effect of CPP tags tTh <tth@none.invalid> - 2024-01-14 00:02 +0100
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-14 14:33 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-13 15:26 -0800
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-14 00:36 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-14 16:20 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-15 13:19 +0100
Makefile as an implementation instance of a transformation process (was Re: Effect of CPP tags) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-15 15:46 +0100
Re: Makefile as an implementation instance of a transformation process (was Re: Effect of CPP tags) Richard Harnden <richard.nospam@gmail.invalid> - 2024-01-15 15:41 +0000
Re: Effect of CPP tags Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-01-14 09:54 -0800
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-14 18:17 +0000
Re: Effect of CPP tags Anthony Cuozzo <anthony@cuozzo.us> - 2024-01-14 13:44 -0500
Re: Effect of CPP tags Jim Jackson <jj@franjam.org.uk> - 2024-01-14 19:16 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-14 19:57 +0000
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-14 13:14 -0800
Re: Effect of CPP tags Gabriel Rolland <gabrielrolland@gmail.com> - 2024-01-15 09:51 +0100
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-15 11:39 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-15 13:57 +0100
Re: Effect of CPP tags Gabriel Rolland <gabrielrolland@gmail.com> - 2024-01-15 17:40 +0100
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-15 17:41 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-15 18:41 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-15 19:12 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-15 19:32 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-15 20:12 +0000
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-15 23:28 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-16 00:04 +0000
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-15 18:23 -0800
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-16 14:22 +0100
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-16 15:53 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-15 21:16 +0100
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-16 15:24 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-16 16:45 +0100
Switch fallthrough considered harmful? (was Re: Effect of CPP tags) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-17 06:01 +0100
Re: Switch fallthrough considered harmful? (was Re: Effect of CPP tags) David Brown <david.brown@hesbynett.no> - 2024-01-17 11:44 +0100
Re: Switch fallthrough considered harmful? (was Re: Effect of CPP tags) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-17 12:21 +0100
Re: Switch fallthrough considered harmful? (was Re: Effect of CPP tags) David Brown <david.brown@hesbynett.no> - 2024-01-17 14:10 +0100
Re: Switch fallthrough considered harmful? (was Re: Effect of CPP tags) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-17 19:35 +0100
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-15 13:48 +0100
Re: Effect of CPP tags Gabriel Rolland <gabrielrolland@gmail.com> - 2024-01-15 17:42 +0100
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-15 14:56 +0000
Re: Effect of CPP tags Gabriel Rolland <gabrielrolland@gmail.com> - 2024-01-15 17:43 +0100
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-15 13:10 +0100
Re: Effect of CPP tags James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-01-15 11:22 -0500
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-12 22:22 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-13 01:02 +0000
Re: Effect of CPP tags Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-13 06:54 +0100
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-13 14:08 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-14 01:13 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-15 12:57 +0100
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-15 12:45 +0100
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-15 14:11 -0800
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-16 19:44 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-16 20:09 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-16 21:06 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-17 12:41 +0100
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-12 17:40 +0000
Re: Effect of CPP tags Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-12 19:06 +0100
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-12 16:50 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-12 17:43 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-12 17:59 +0000
Re: Effect of CPP tags Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-12 19:10 +0100
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-12 18:53 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-12 19:18 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-12 20:16 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-12 22:18 +0000
Re: Effect of CPP tags Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-13 05:15 +0100
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-12 12:59 -0800
Re: Effect of CPP tags Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-13 04:36 +0100
Re: Effect of CPP tags Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-13 05:01 +0100
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-12 20:05 -0800
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-12 20:08 -0800
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-13 04:31 +0000
Re: Effect of CPP tags Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-13 07:13 +0100
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-12 19:15 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-12 20:14 +0000
Re: Effect of CPP tags Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-13 05:12 +0100
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-13 04:46 +0000
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-12 20:52 -0800
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-12 20:57 -0800
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-12 21:39 -0800
Re: Effect of CPP tags Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-01-14 09:22 -0800
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-14 18:10 +0000
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-14 13:11 -0800
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-14 14:58 -0800
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-15 01:05 +0000
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-14 20:44 -0800
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-14 20:39 -0800
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-14 21:47 -0800
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-14 22:37 -0800
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-15 14:20 +0100
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-15 12:21 -0800
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-15 00:52 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-12 12:09 -0800
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-12 22:16 +0000
Re: Effect of CPP tags Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2024-01-12 23:04 +0000
Re: Effect of CPP tags Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2024-01-12 23:30 +0000
Re: Effect of CPP tags tTh <tth@none.invalid> - 2024-01-13 00:16 +0100
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-17 11:16 +0000
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-17 18:47 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-17 19:42 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-17 22:18 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-17 23:48 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-17 16:23 -0800
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-18 00:25 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-18 00:47 +0000
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-18 04:30 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-18 10:26 +0000
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-18 19:40 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-18 20:21 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-19 11:07 +0100
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-19 11:17 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-19 12:41 +0100
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-19 13:18 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-19 15:42 +0100
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-19 15:03 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-19 18:12 +0100
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-19 18:28 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-19 18:43 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-19 19:48 +0100
Re: Effect of CPP tags Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-19 17:32 +0100
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-19 17:05 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-19 19:50 +0100
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-19 14:18 -0800
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-19 14:14 -0800
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-19 16:18 +0000
Re: Effect of CPP tags dave_thompson_2@comcast.net - 2024-02-26 04:17 -0500
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-02-26 15:56 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-18 15:16 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-18 21:47 +0100
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-18 23:46 +0000
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-18 23:29 +0000
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-18 13:23 -0800
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-21 00:40 +0000
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-12 12:42 -0800
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-12 21:31 +0000
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-12 15:04 -0800
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-14 12:18 +0000
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-15 00:34 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-15 02:14 +0000
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-15 07:07 +0000
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-14 23:36 -0800
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-15 07:40 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-15 17:04 +0100
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-15 17:29 +0100
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-15 12:27 -0800
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-15 23:24 +0000
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-15 18:18 -0800
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-16 14:38 +0100
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-16 16:55 -0800
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-16 17:08 -0800
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-17 02:21 +0000
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-18 21:34 -0800
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-16 18:35 -0800
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-17 03:03 +0000
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-16 19:59 -0800
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-17 13:28 +0100
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-17 12:55 -0800
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-16 14:24 +0100
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-16 20:02 -0800
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-16 11:54 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-16 14:42 +0100
Re: Effect of CPP tags Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-16 15:08 +0100
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-16 16:54 +0100
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-16 15:57 +0000
CPU's MAC instructions (was Re: Effect of CPP tags) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-17 06:25 +0100
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-16 18:52 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-15 14:15 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-15 14:35 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-15 15:44 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-15 17:35 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-15 18:55 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-15 19:19 +0000
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-15 12:31 -0800
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-16 01:21 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-16 11:30 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-16 15:06 +0100
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-16 17:04 -0800
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-17 13:43 +0100
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-17 13:00 -0800
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-18 13:00 +0100
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-18 13:28 -0800
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-18 21:58 -0800
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-18 21:55 -0800
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-18 22:02 -0800
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-16 15:55 +0000
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-16 18:39 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-17 00:11 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-17 16:11 +0000
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-18 21:42 -0800
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-18 21:44 -0800
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-15 12:28 -0800
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-15 16:39 +0100
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-15 16:23 +0100
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-15 17:30 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-15 21:25 +0100
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-15 20:41 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-16 15:08 +0100
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-16 16:02 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-16 19:03 +0100
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-16 18:45 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-16 23:00 +0100
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-16 22:10 +0000
Re: Effect of CPP tags Richard Harnden <richard.nospam@gmail.invalid> - 2024-01-16 22:18 +0000
NO vs. SE (was Re: Effect of CPP tags) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-17 07:11 +0100
Re: NO vs. SE (was Re: Effect of CPP tags) David Brown <david.brown@hesbynett.no> - 2024-01-17 14:17 +0100
Re: NO vs. SE (was Re: Effect of CPP tags) scott@slp53.sl.home (Scott Lurndal) - 2024-01-17 16:33 +0000
Re: NO vs. SE (was Re: Effect of CPP tags) David Brown <david.brown@hesbynett.no> - 2024-01-17 18:47 +0100
Re: NO vs. SE (was Re: Effect of CPP tags) scott@slp53.sl.home (Scott Lurndal) - 2024-01-17 18:04 +0000
Re: NO vs. SE (was Re: Effect of CPP tags) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-17 19:15 +0100
Re: NO vs. SE (was Re: Effect of CPP tags) om@iki.fi (Otto J. Makela) - 2024-01-18 17:22 +0200
Re: NO vs. SE (was Re: Effect of CPP tags) Phil Carmody <pc+usenet@asdf.org> - 2024-03-24 14:24 +0200
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-16 12:26 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-16 16:29 +0100
Interpreter Dispatch in C (was: Effect of CPP Tags) bart <bc@freeuk.com> - 2024-01-16 19:21 +0000
Re: Interpreter Dispatch in C David Brown <david.brown@hesbynett.no> - 2024-01-16 23:24 +0100
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-16 15:15 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-16 18:46 +0100
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-16 22:42 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-17 14:25 +0100
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-17 14:51 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-17 19:07 +0100
Optimization and inline assembly (was Re: Effect of CPP tags) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-17 07:07 +0100
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-14 18:58 -0800
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-14 19:01 -0800
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-12 09:52 +0100
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-11 09:41 -0800
Re: Effect of CPP tags Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-01-14 09:20 -0800
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-11 13:24 +0100
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-11 13:45 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-11 14:55 +0100
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-11 12:27 -0800
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-12 16:04 -0800
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-12 16:24 -0800
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-12 16:36 -0800
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-12 16:43 -0800
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-10 19:36 -0800
Re: Effect of CPP tags James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-01-09 20:05 -0500
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-12 15:54 -0800
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-10 01:32 +0000
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-12 15:45 -0800
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-10 19:33 -0800
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-12 15:48 -0800
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-12 15:49 -0800
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-09 22:12 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-10 11:23 +0100
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-10 19:23 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-10 20:46 +0100
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-10 08:21 +0100
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-09 19:20 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-09 20:01 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-09 13:12 -0800
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-09 21:37 +0000
Re: Effect of CPP tags Ike Naar <ike@sdf.org> - 2024-01-09 21:51 +0000
Re: Effect of CPP tags James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-01-09 16:42 -0500
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-09 12:04 -0800
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-09 18:12 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-09 12:11 -0800
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-09 21:51 +0000
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-09 01:50 +0000
Re: Effect of CPP tags Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-01-08 22:28 -0800
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-09 07:38 +0000
Re: Effect of CPP tags Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-07 02:12 +0100
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-07 01:45 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-07 01:47 +0000
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-07 02:16 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-06 17:15 -0800
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-07 02:25 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-06 19:28 -0800
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-07 15:26 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-07 15:51 -0800
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-08 01:32 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-07 20:35 -0800
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-08 13:28 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-08 10:25 -0800
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-08 18:55 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-08 19:01 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-08 11:22 -0800
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-08 11:21 -0800
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-08 16:00 +0100
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-08 18:02 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-08 10:39 -0800
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-08 21:36 +0100
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-08 10:32 -0800
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-08 21:41 +0100
Re: Effect of CPP tags Ike Naar <ike@sdf.org> - 2024-01-08 08:53 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-08 09:59 -0800
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-06 12:53 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-06 14:11 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-06 15:28 +0100
Re: Effect of CPP tags Richard Damon <richard@damon-family.org> - 2024-01-06 09:56 -0500
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-06 15:57 +0000
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-06 23:58 +0000
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-06 23:45 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-07 00:21 +0000
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-07 00:55 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-07 01:26 +0000
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-07 02:14 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-07 12:14 +0000
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-07 19:29 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-07 22:41 +0000
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-07 23:27 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-06 15:43 +0000
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-07 03:32 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-07 11:37 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-07 14:41 -0800
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-07 22:54 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-07 16:06 -0800
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-05 15:54 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-05 16:23 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-04 09:55 +0100
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-04 12:15 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-04 15:29 +0100
Re: Effect of CPP tags tTh <tth@none.invalid> - 2024-01-06 05:33 +0100
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-03 17:41 +0100
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-03 21:32 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-04 15:13 +0100
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-03 13:42 -0800
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-04 12:46 +0100
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-04 12:37 +0000
Re: Effect of CPP tags James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-01-04 12:51 -0500
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-04 18:21 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-04 10:43 -0800
Re: Effect of CPP tags James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-01-04 17:39 -0500
Re: Effect of CPP tags James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-01-04 12:33 -0500
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-04 10:36 -0800
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-04 21:59 +0100
Re: Effect of CPP tags Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> - 2024-01-02 15:10 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-02 16:38 +0000
Re: Effect of CPP tags Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-02 20:23 +0100
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-02 19:35 +0000
Re: Effect of CPP tags Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-02 20:54 +0100
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-03 20:28 +0100
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-01 21:45 +0000
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-01 23:08 +0000
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-02 18:16 +0000
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-02 19:05 +0000
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-02 21:45 +0000
Re: Effect of CPP tags Richard Damon <richard@damon-family.org> - 2023-12-29 11:58 -0500
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2023-12-29 17:44 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-12-29 10:54 -0800
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2023-12-29 20:19 +0000
Re: Effect of CPP tags Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> - 2023-12-30 06:51 +0000
Re: Effect of CPP tags BGB <cr88192@gmail.com> - 2023-12-30 16:16 -0600
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2023-12-30 23:21 +0000
Re: Effect of CPP tags BGB <cr88192@gmail.com> - 2023-12-30 19:14 -0600
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2023-12-31 01:34 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2023-12-31 02:18 +0000
Re: Effect of CPP tags BGB <cr88192@gmail.com> - 2023-12-30 23:46 -0600
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2023-12-31 15:26 +0000
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2023-12-31 17:26 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2023-12-31 19:23 +0000
Re: Effect of CPP tags Richard Damon <news.x.richarddamon@xoxy.net> - 2023-12-31 14:46 -0500
Re: Effect of CPP tags BGB <cr88192@gmail.com> - 2023-12-31 15:49 -0600
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2023-12-31 23:46 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-01 01:33 +0000
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-01 02:00 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-01 11:56 +0000
Re: Effect of CPP tags BGB <cr88192@gmail.com> - 2024-01-01 13:06 -0600
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-01 20:13 +0000
Re: Effect of CPP tags BGB <cr88192@gmail.com> - 2024-01-01 20:20 -0600
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-02 02:34 +0000
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-01 21:39 +0000
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-01 21:38 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-01 22:51 +0000
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-01 23:10 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-01 23:45 +0000
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-02 00:05 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-02 01:14 +0000
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-02 01:58 +0000
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-01 20:41 -0800
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-16 22:21 -0800
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-02 06:23 +0000
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-02 06:47 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-02 12:24 +0000
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-02 19:04 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-02 20:11 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-02 20:43 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-02 23:55 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-03 02:08 +0000
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-03 02:40 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-03 12:10 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-03 13:03 +0000
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-03 19:14 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-03 15:33 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-03 08:37 -0800
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-01 15:54 -0800
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-02 20:05 +0000
Re: Effect of CPP tags Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> - 2024-01-01 15:45 +0000
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-12-31 20:06 -0800
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-01 04:48 +0000
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-12-31 23:00 -0800
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-01 21:40 +0000
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-01 15:49 -0800
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-02 00:06 +0000
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-01 16:29 -0800
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-01 16:38 -0800
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-12-31 23:01 -0800
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2023-12-31 18:37 +0000
Re: Effect of CPP tags BGB <cr88192@gmail.com> - 2023-12-31 16:59 -0600
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2023-12-30 20:12 +0000
Re: Effect of CPP tags Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-12-31 16:07 -0800
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-12-31 16:36 -0800
Re: Effect of CPP tags Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-12-31 18:31 -0800
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-12-31 19:08 -0800
Re: Effect of CPP tags Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-01-21 12:36 -0800
Re: Effect of CPP tags Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-01 05:56 +0100
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-12-31 22:59 -0800
Re: Effect of CPP tags Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-01-08 22:20 -0800
Page 25 of 34 — ← Prev page 1 … 23 24 [25] 26 27 … 34 Next page →
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2024-01-16 22:42 +0000 |
| Message-ID | <uo70pi$1l15q$1@dont-email.me> |
| In reply to | #380258 |
On 16/01/2024 17:46, David Brown wrote:
> On 16/01/2024 16:15, bart wrote:
> void swap_lots(const uint32_t * restrict in, uint32_t * restrict out,
> uint32_t n) {
> while (n--) {
> *out++ = swapEndian32(*in++);
> *out++ = swapEndian32(*in++);
> *out++ = swapEndian32(*in++);
> *out++ = swapEndian32(*in++);
> }
> }
What's 'n' here? Are 4n bytes being transformed, or 16n?
>> My function would be this on x64 (although I don't support bswap):
>>
>> fun swapends64(u64 x)u64 = assem mov rax, [x]; bswap rax; end
>>
>
> And how efficient would your "swap_lots" function be?
How do you measure efficiency? This task seems memory-bound anyway.
Using exactly that function (I now support 'bswap'), I can process a
100M-element u64 array (0.8GB) in .35 seconds, or 2.3GB/second.
Using an inlining macro didn't make much difference.
I then tried adding 'byteswap' as an intrinsic operator within my
language. Then that 2.3GB/s became 3.4GB/s. I used a simple loop with no
unrolling.
I can't run your code directly, as a I don't have 'rev'. But adjusting
that swap function to instead apply '~', processing a 200M-element u32
array (also 0.8GB), took 0.22 seconds or 3.6GB/s. (This was doing n/4
iterations of your unrolled loop.)
But this is not really about inline assembly any more, but ways to make
best use of memory bandwidth.
(I have an advantage in working 64 bits at a time, but you'd think gcc
would be able to take care of that; wasn't that your point?)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-01-17 14:25 +0100 |
| Message-ID | <uo8kh2$20hg6$4@dont-email.me> |
| In reply to | #380283 |
On 16/01/2024 23:42, bart wrote:
> On 16/01/2024 17:46, David Brown wrote:
>> On 16/01/2024 16:15, bart wrote:
>
>> void swap_lots(const uint32_t * restrict in, uint32_t * restrict out,
>> uint32_t n) {
>> while (n--) {
>> *out++ = swapEndian32(*in++);
>> *out++ = swapEndian32(*in++);
>> *out++ = swapEndian32(*in++);
>> *out++ = swapEndian32(*in++);
>> }
>> }
>
> What's 'n' here? Are 4n bytes being transformed, or 16n?
In this case, 4n 32-bit words. It's just example code to demonstrate a
point, not to be a particularly useful function in reality.
>
>>> My function would be this on x64 (although I don't support bswap):
>>>
>>> fun swapends64(u64 x)u64 = assem mov rax, [x]; bswap rax; end
>>>
>>
>> And how efficient would your "swap_lots" function be?
>
> How do you measure efficiency? This task seems memory-bound anyway.
>
That will depend on the sizes, cache, etc., as well as the target. The
target I was using here is a Cortex M7 - with data in tightly-coupled
memory that runs at core speed, it would not be memory bound.
Efficiency is measured in clock cycles. (It can also be measured in
code size, but that's usually not as important. If it were, we would
not be doing manual loop unrolling here.)
> Using exactly that function (I now support 'bswap'), I can process a
> 100M-element u64 array (0.8GB) in .35 seconds, or 2.3GB/second.
>
On what target? Do you have an ARM Cortex-M microcontroller for testing
this?
Using a built-in bswap function kind of defeats the point of using
inline assembly. gcc has __builtin_bswap32 too, or it can be written
manually in C and optimised by the compiler to "rev" instructions. The
point is a demonstration of how gcc's inline assembly can work with the
optimiser for surrounding code, not how fast your PC can swap endianness!
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2024-01-17 14:51 +0000 |
| Message-ID | <uo8pi9$21ruo$1@dont-email.me> |
| In reply to | #380333 |
On 17/01/2024 13:25, David Brown wrote:
> On 16/01/2024 23:42, bart wrote:
>> On 16/01/2024 17:46, David Brown wrote:
>>> On 16/01/2024 16:15, bart wrote:
>>
>>> void swap_lots(const uint32_t * restrict in, uint32_t * restrict out,
>>> uint32_t n) {
>>> while (n--) {
>>> *out++ = swapEndian32(*in++);
>>> *out++ = swapEndian32(*in++);
>>> *out++ = swapEndian32(*in++);
>>> *out++ = swapEndian32(*in++);
>>> }
>>> }
>>
>> What's 'n' here? Are 4n bytes being transformed, or 16n?
>
> In this case, 4n 32-bit words. It's just example code to demonstrate a
> point, not to be a particularly useful function in reality.
>
>>
>>>> My function would be this on x64 (although I don't support bswap):
>>>>
>>>> fun swapends64(u64 x)u64 = assem mov rax, [x]; bswap rax; end
>>>>
>>>
>>> And how efficient would your "swap_lots" function be?
>>
>> How do you measure efficiency? This task seems memory-bound anyway.
>>
>
> That will depend on the sizes, cache, etc., as well as the target. The
> target I was using here is a Cortex M7 - with data in tightly-coupled
> memory that runs at core speed, it would not be memory bound.
>
> Efficiency is measured in clock cycles. (It can also be measured in
> code size, but that's usually not as important. If it were, we would
> not be doing manual loop unrolling here.)
>
>> Using exactly that function (I now support 'bswap'), I can process a
>> 100M-element u64 array (0.8GB) in .35 seconds, or 2.3GB/second.
>>
>
> On what target? Do you have an ARM Cortex-M microcontroller for testing
> this?
I have an RPi4 somewhere; I only know it has a 64-bit ARM chip. ARM
processor and architecture models are mystery to me. My tests were done
on some AMD Ryzen device, probably bottom of the range.
(x64 processors are a bit of a mystery too! I just have little interest
beyond whether it's x64 or ARM64; I don't come across anything else.)
> Using a built-in bswap function kind of defeats the point of using
> inline assembly.
I didn't support 'bswap' at all. I first has to add it to my assembler,
then roll that out to the backend of my compiler.
This was necessary both to be able to use it in inline assembler, and
for the compiler backend to be able to deal with that instruction,
whatever had generated it.
So I wanted to know whether building it to the language in would be
worth doing, performance-wise (probably not). Although there are other
advantages of having it as an operator, since it could be used in-place
as 'bswap:=A[i]', and here it would be able to choose 32- and 64-bit
variations.
But it also highlighted issues with my inline assembler within macros
used to emulate inline functions, such as this:
macro byteswap(x) = assem mov rax, [x] ...
'x' can only be a simple variable at the invocation, not an arbitrary
expression like 'A[i]'. This suggested an enhancement:
assem (expr) ...
which first evaluates the expression to a known register. (I could just
do 'expr; assem ...' which /probably/ does the same, but it's risky.)
So doing the exercise helped in determining what might be a suitable
compromise. Although it would need explicit forms for 32- vs 64-bit
operations.
('assem(expr) ...' is also partway to doing what gcc asm{} does in
creating an interface, but retaining the same syntax.)
> gcc has __builtin_bswap32 too, or it can be written
> manually in C and optimised by the compiler to "rev" instructions. The
> point is a demonstration of how gcc's inline assembly can work with the
> optimiser for surrounding code, not how fast your PC can swap endianness!
It showed that using an actual function call, and not unrolling loops,
wasn't that slow, not on my PC.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-01-17 19:07 +0100 |
| Message-ID | <uo950t$253hh$1@dont-email.me> |
| In reply to | #380337 |
On 17/01/2024 15:51, bart wrote:
> On 17/01/2024 13:25, David Brown wrote:
>> On 16/01/2024 23:42, bart wrote:
>>> On 16/01/2024 17:46, David Brown wrote:
>>>> On 16/01/2024 16:15, bart wrote:
>>>
>>>> void swap_lots(const uint32_t * restrict in, uint32_t * restrict
>>>> out, uint32_t n) {
>>>> while (n--) {
>>>> *out++ = swapEndian32(*in++);
>>>> *out++ = swapEndian32(*in++);
>>>> *out++ = swapEndian32(*in++);
>>>> *out++ = swapEndian32(*in++);
>>>> }
>>>> }
>>>
>>> What's 'n' here? Are 4n bytes being transformed, or 16n?
>>
>> In this case, 4n 32-bit words. It's just example code to demonstrate
>> a point, not to be a particularly useful function in reality.
>>
>>>
>>>>> My function would be this on x64 (although I don't support bswap):
>>>>>
>>>>> fun swapends64(u64 x)u64 = assem mov rax, [x]; bswap rax; end
>>>>>
>>>>
>>>> And how efficient would your "swap_lots" function be?
>>>
>>> How do you measure efficiency? This task seems memory-bound anyway.
>>>
>>
>> That will depend on the sizes, cache, etc., as well as the target.
>> The target I was using here is a Cortex M7 - with data in
>> tightly-coupled memory that runs at core speed, it would not be memory
>> bound.
>>
>> Efficiency is measured in clock cycles. (It can also be measured in
>> code size, but that's usually not as important. If it were, we would
>> not be doing manual loop unrolling here.)
>>
>>> Using exactly that function (I now support 'bswap'), I can process a
>>> 100M-element u64 array (0.8GB) in .35 seconds, or 2.3GB/second.
>>>
>>
>> On what target? Do you have an ARM Cortex-M microcontroller for
>> testing this?
>
> I have an RPi4 somewhere; I only know it has a 64-bit ARM chip. ARM
> processor and architecture models are mystery to me. My tests were done
> on some AMD Ryzen device, probably bottom of the range.
The ARM processors on a Pi are much more like a PC processor than an ARM
microcontroller (even though the M7 I use mostly is 600 MHz).
>
> (x64 processors are a bit of a mystery too! I just have little interest
> beyond whether it's x64 or ARM64; I don't come across anything else.)
>
>> Using a built-in bswap function kind of defeats the point of using
>> inline assembly.
>
> I didn't support 'bswap' at all. I first has to add it to my assembler,
> then roll that out to the backend of my compiler.
>
> This was necessary both to be able to use it in inline assembler, and
> for the compiler backend to be able to deal with that instruction,
> whatever had generated it.
>
> So I wanted to know whether building it to the language in would be
> worth doing, performance-wise (probably not). Although there are other
> advantages of having it as an operator, since it could be used in-place
> as 'bswap:=A[i]', and here it would be able to choose 32- and 64-bit
> variations.
>
> But it also highlighted issues with my inline assembler within macros
> used to emulate inline functions, such as this:
>
> macro byteswap(x) = assem mov rax, [x] ...
>
> 'x' can only be a simple variable at the invocation, not an arbitrary
> expression like 'A[i]'. This suggested an enhancement:
>
> assem (expr) ...
>
> which first evaluates the expression to a known register.
This sounds like you are taking inspiration from the discussion and
making your language support more of gcc's inline assembly features!
> (I could just
> do 'expr; assem ...' which /probably/ does the same, but it's risky.)
>
> So doing the exercise helped in determining what might be a suitable
> compromise. Although it would need explicit forms for 32- vs 64-bit
> operations.
>
> ('assem(expr) ...' is also partway to doing what gcc asm{} does in
> creating an interface, but retaining the same syntax.)
>
>> gcc has __builtin_bswap32 too, or it can be written manually in C
>> and optimised by the compiler to "rev" instructions. The point is a
>> demonstration of how gcc's inline assembly can work with the optimiser
>> for surrounding code, not how fast your PC can swap endianness!
>
> It showed that using an actual function call, and not unrolling loops,
> wasn't that slow, not on my PC.
>
It showed that - unsurprisingly - running this on a huge block of data
is determined by cache and memory speed. It probably doesn't make much
difference to your timings if "bswap" returned its argument untouched.
Thus you missed the point about optimising code. (You did, however,
show that optimising code is not always important - if the code itself
is not the bottleneck, optimising it won't help.)
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2024-01-17 07:07 +0100 |
| Subject | Optimization and inline assembly (was Re: Effect of CPP tags) |
| Message-ID | <uo7qro$1sj6e$1@dont-email.me> |
| In reply to | #380258 |
On 16.01.2024 18:46, David Brown wrote: > On 16/01/2024 16:15, bart wrote: >> >> The need for assembly usually trumps whatever minor optimisation my >> compiler might do. The good thing is that compilers do also major optimizations. (And the minor ones come for free.) But the most important insight is that tackling complexity algorithmically is what is most contributing for speed. (This may be different for folks fiddling only on assembler level, where _separate_ assembler projects serve better. It's IMO more sensible for time critical stuff to just use an assembler for such functions and embed them by a clean function interface in any HLL than to inline assembler code. YMMV.) > > Ah, there we differ. I use tools that do good optimisations. And > perhaps 70% of the use-cases of inline assembly will be lost if the tool > can't generate efficient code when there is inline assembly. Janis
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2024-01-14 18:58 -0800 |
| Message-ID | <uo26vq$lu60$6@dont-email.me> |
| In reply to | #380157 |
On 1/14/2024 4:34 PM, Kaz Kylheku wrote: > On 2024-01-14, bart <bc@freeuk.com> wrote: >> On 12/01/2024 21:31, Kaz Kylheku wrote: >>> On 2024-01-12, bart <bc@freeuk.com> wrote: >> >>>> I mainly remember the times when they do hang. >>> >>> DOS/Windows stuff hangs also: >>> >>> C:\Users\kazk>findstr foo >>> ... "hang" ... >>> >>> Even Microsoft clued in to the idea that a text filter shouldn't >>> spew extraneous diagnostics by default. >> >> If you type 'findstr' with no arguments, it reports an error. Maybe >> 'sort' was a better example to make your point. > > So does grep with no arguments? I don't see where that is going. >> >>>> But with 'as', it just sits there. I wonder what it's waiting for; for >>>> me to type in ASM code live from the terminal? (If 'as' is designed for >>>> piped-in input, tdm/gcc doesn't appear to use that feature as I remember >>>> it generating discrete, temporary .s files.) >>> >>> gcc -pipe works in pipe mode. >>> >>> The "as" command is intended for compiler use; not only is it not >>> an interactive assembler, it doesn't even have particularly good >>> diagnostics for batch use. You have to know what you're doing. >> >> You're sort of making excuses for it. > > I'm just stating what I have always believed the requirements to be. > > In Unixes and the GNU Project, there has not been a focus on assembly > language as a primary development language, with a great developer > experience. > > That's pretty much a fact. > > The amount of material written in .s or .S files is very small. > >> My 'aa' assembler was also >> designed mainly for machine-generated code, so it has very few frills. >> >> The syntax however is decent enough that I can use it for my inline >> assembler too. > > GCC has great inline assembly. > > You can reference C expressions, which > are evaluated to registers that the register allocator chooses, which > you can reference in your inline code in a symbolic way. > > You can also indicate that your code template has certain effects, > so that the compiler is informed. > > I had a nice experience many years ago when I wrapped the MIPS > "load-linked/store-conditional" primitives as separate inline code > macros. > > When I used these macros to write a synchronization primitive, GCC > optimized away an unnecessary instruction or two, due to the way they > integrated together. > GCC had a nasty bugger wrt trylock around 20 years ago. There is a thread over on comp.programming.threads that mentions it.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2024-01-14 19:01 -0800 |
| Message-ID | <uo2765$lu60$7@dont-email.me> |
| In reply to | #380157 |
On 1/14/2024 4:34 PM, Kaz Kylheku wrote: > On 2024-01-14, bart <bc@freeuk.com> wrote: >> On 12/01/2024 21:31, Kaz Kylheku wrote: >>> On 2024-01-12, bart <bc@freeuk.com> wrote: >> >>>> I mainly remember the times when they do hang. >>> >>> DOS/Windows stuff hangs also: >>> >>> C:\Users\kazk>findstr foo >>> ... "hang" ... >>> >>> Even Microsoft clued in to the idea that a text filter shouldn't >>> spew extraneous diagnostics by default. >> >> If you type 'findstr' with no arguments, it reports an error. Maybe >> 'sort' was a better example to make your point. > > So does grep with no arguments? I don't see where that is going. >> >>>> But with 'as', it just sits there. I wonder what it's waiting for; for >>>> me to type in ASM code live from the terminal? (If 'as' is designed for >>>> piped-in input, tdm/gcc doesn't appear to use that feature as I remember >>>> it generating discrete, temporary .s files.) >>> >>> gcc -pipe works in pipe mode. >>> >>> The "as" command is intended for compiler use; not only is it not >>> an interactive assembler, it doesn't even have particularly good >>> diagnostics for batch use. You have to know what you're doing. >> >> You're sort of making excuses for it. > > I'm just stating what I have always believed the requirements to be. > > In Unixes and the GNU Project, there has not been a focus on assembly > language as a primary development language, with a great developer > experience. > > That's pretty much a fact. > > The amount of material written in .s or .S files is very small. > >> My 'aa' assembler was also >> designed mainly for machine-generated code, so it has very few frills. >> >> The syntax however is decent enough that I can use it for my inline >> assembler too. > > GCC has great inline assembly. well, that is a point of contention with me. I just said f* the inline crap and created pure asm. > > You can reference C expressions, which > are evaluated to registers that the register allocator chooses, which > you can reference in your inline code in a symbolic way. > > You can also indicate that your code template has certain effects, > so that the compiler is informed. > > I had a nice experience many years ago when I wrapped the MIPS > "load-linked/store-conditional" primitives as separate inline code > macros. > > When I used these macros to write a synchronization primitive, GCC > optimized away an unnecessary instruction or two, due to the way they > integrated together. >
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-01-12 09:52 +0100 |
| Message-ID | <unqujq$3d8if$1@dont-email.me> |
| In reply to | #380043 |
On 11/01/2024 19:49, bart wrote: > > The name of the script would usually be specific to the project, for > example, 'makeccia' will run 'makeccia.bat'. The '-a' suffix refers to > the floppy A: drive, so it is a very old example. > To be clear here - I don't think anyone would greatly object if "make" required an explicit makefile name, rather than using a default filename. It is more convenient to type "make" than "make -f project.mak", but some people prefer to do exactly that, rather than using a default makefile. It is particularly convenient if you have several small projects in the same directory, and don't want to combine a single makefile. And of course if "make" had originally required an explicit filename, there are plenty of *nix idioms and tricks to simplify things - adding a shebang to a makefile to make it executable, shell aliases, bash scripts, etc. People always manage to make things work in a way that is convenient for them. But since "make" uses "makefile" by default, that's what most people use.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-01-11 09:41 -0800 |
| Message-ID | <871qanojhr.fsf@nosuchdomain.example.com> |
| In reply to | #380029 |
bart <bc@freeuk.com> writes:
[...]
> OK, so just like:
>
> mcc prog
>
> At least someone recognises the utility of doing that rather than the
> gcc palaver. They don't even need the extension!
>
> Yet when I build that convenience into the compiler, people come down
> on me like a ton of bricks.
>
> Talk about hypocrisy.
[...]
I haven't seen this "ton of bricks".
I don't think anyone has objected to the way your mcc works. If
"mcc prog" does what you want, that's fine. It's different from the way
gcc works, but nobody says that everything has to work the same way gcc
does.
If someone *describes* how gcc and make work, you take it as an
accusation, a condemnation of your own tools for being different.
Nobody is saying that.
I'll mention in passing that there are advantages to having
a compiler command refer to the name of the input (prog.c)
rather than the name of the output (prog or prog.exe), because
it lets the user take advantage of filename completion. "make"
is an exception to this, because there are good reasons for it to
refer to the output. Again, I'm not criticizing you for not doing
it that way, just letting you know about a possible rationale for
gcc's existing behavior.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2024-01-14 09:20 -0800 |
| Message-ID | <861qajn866.fsf@linuxsc.com> |
| In reply to | #380029 |
bart <bc@freeuk.com> writes: [...] > While 'make' conflates several kinds of processes: [...] make doesn't conflate these different applications, any more than 'cat' "conflates" different kinds of files. They simply are general tools with a broad range of applicability. The idea that the applications listed are in some way inherently different shows only the limitations of your thinking, not any essential truth about make.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-01-11 13:24 +0100 |
| Message-ID | <unomlo$3023v$1@dont-email.me> |
| In reply to | #380009 |
On 10/01/2024 21:20, bart wrote:
> On 10/01/2024 19:24, bart wrote:
>> On 10/01/2024 18:39, Keith Thompson wrote:
>>> bart <bc@freeuk.com> writes:
>>>> On 10/01/2024 14:49, Scott Lurndal wrote:
>>> [...]
>>>>> Yet, the entire application can be built with
>>>>> $ make
>>>>
>>>> I bet you can't. There's something missing. Unless the implicit file
>>>> that make uses happens to be in that '$' directory. Usually you have
>>>> to navigate to the project first.
>>>
>>> That '$' is a shell prompt, not a directory.
>>>
>>> Yes, you have to "cd" (like "chdir" on Windows) to the project directory
>>> before typing "make". You also have to make sure the computer is
>>> powered on, login, launch a shell, and maybe one or two other things
>>> before you get to that point.
>>
>> You're missing the point. SL is making a big deal about the fact that
>> you can type 'make' without providing any apparent input. But that
>> input is provided when you use 'cd' to get the relevant folder.
>>
>> Or do you think that the 'make' command provided will build that
>> specific project irrespective of the CWD?
>
> Let me put it another way; how does:
>
> $ make
>
> know it is to build that project, and not any other? The default input
> is presumably "./makefile", with the key bit being that ".".
Yes, that's the usual way for non-trivial uses. (For simple cases, the
build-it rules are good enough, given a target.) You can give make an
explicit makefile ("make -f proj.make") or it will try to find the
default one in the current directory. For gnu make (there are /many/
other "make" implementations), it will try "GNUmakefile", "makefile",
then "Makefile".
>
> So, when claiming that you only need to type one thing to start the
> process, it is disingenuous to leave out that part out.
No. Your makefile (or cmake files, or bake files, or whatever build
system you use) are part of your project - they are part of the source.
>
> After all, if you wanted to build project A, and, separately, project B,
> you can't do both of them like this:
>
> $ make
> $ make
I think most people here assume the reader is familiar with the very
basics of working a computer. But if you want it spelt out, you would
generally do :
$ cd ~/projects/project_a
$ make
$ cd ~/projects/project_b
$ make
Does that answer your question?
If the two projects are closely connected, you might have them organised
as sub-directories of "project". Then at the top-level, you could have
a makefile with:
all : project_a project_b
.PHONY : project_a project_b
project_a :
$(MAKE) -C project_a
project_b :
$(MAKE) -C project_b
Then you can build project_a by going to the project_a directory and
typing "make", or going to the top-level project directory and typing
"make project_a", or going to the top-level project directory and typing
"make" to build project_a and project_b, together. (This is often
particularly nice when using parallel make to make use of all the cores
in your expensive computer.)
>
> We've covered this before. While I quite like sensible defaults, where C
> compilers tend to be sticklers for dotting all the Is, 'make' goes a
> little too far the other way.
>
> Before typing 'make', you'd better be sure you're in the right place!
>
The same is true of getting undressed, and indeed most things in life.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2024-01-11 13:45 +0000 |
| Message-ID | <unorej$30k43$1@dont-email.me> |
| In reply to | #380032 |
On 11/01/2024 12:24, David Brown wrote: > On 10/01/2024 21:20, bart wrote: >> Before typing 'make', you'd better be sure you're in the right place! >> > > The same is true of getting undressed, and indeed most things in life. > You might remember a discussion last autumn about building Lua 5.4. There was a lot of confusion since the sources you got from googling 'github lua', and also I think from the releases from that github site, and sources obtained via 'lua.org', were different. The latter had an extra directory level compared with github, and two makefiles rather than one: c:\xxx\lua-5.4.6>dir makefile*/s Directory of c:\xxx\lua-5.4.6 02/05/2023 20:06 3,150 Makefile Directory of c:\xxx\lua-5.4.6\src 03/02/2023 10:43 7,685 Makefile Github had only the latter level. Since both have the same name and both can be invoked with: make it meant no error was reported (like: 'no such makefile'), it just went wrong. Here, having to specify the name of a file, /and/ ensuring those two input files weren't identically named, could have saved a lot trouble by detecting the discrepancy sooner.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-01-11 14:55 +0100 |
| Message-ID | <unos05$30pcg$1@dont-email.me> |
| In reply to | #380034 |
On 11/01/2024 14:45, bart wrote: > On 11/01/2024 12:24, David Brown wrote: >> On 10/01/2024 21:20, bart wrote: > >>> Before typing 'make', you'd better be sure you're in the right place! >>> >> >> The same is true of getting undressed, and indeed most things in life. >> > > > You might remember a discussion last autumn about building Lua 5.4. > I vaguely remember the discussion, but not the details (sorry). > There was a lot of confusion since the sources you got from googling > 'github lua', and also I think from the releases from that github site, > and sources obtained via 'lua.org', were different. > > The latter had an extra directory level compared with github, and two > makefiles rather than one: > > c:\xxx\lua-5.4.6>dir makefile*/s > Directory of c:\xxx\lua-5.4.6 > 02/05/2023 20:06 3,150 Makefile > > Directory of c:\xxx\lua-5.4.6\src > 03/02/2023 10:43 7,685 Makefile > > Github had only the latter level. > > Since both have the same name and both can be invoked with: > > make > > it meant no error was reported (like: 'no such makefile'), it just went > wrong. > > Here, having to specify the name of a file, /and/ ensuring those two > input files weren't identically named, could have saved a lot trouble by > detecting the discrepancy sooner. > I don't remember the details, so I am just guessing now - perhaps one was a developer version and the other a release version. Perhaps there was just a mistake. It is /very/ common to have makefiles in subdirectories - different parts of a project can be built with recursive make. (This can be done badly, as with many things, and can be the source of confusion, inefficiencies or problems if different sub-projects depend on each other.) But you should normally have a "parent" makefile or script in the outer directory, or at least clear build instructions.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2024-01-11 12:27 -0800 |
| Message-ID | <unpivv$34cp3$1@dont-email.me> |
| In reply to | #380032 |
On 1/11/2024 4:24 AM, David Brown wrote:
> On 10/01/2024 21:20, bart wrote:
>> On 10/01/2024 19:24, bart wrote:
>>> On 10/01/2024 18:39, Keith Thompson wrote:
>>>> bart <bc@freeuk.com> writes:
>>>>> On 10/01/2024 14:49, Scott Lurndal wrote:
>>>> [...]
>>>>>> Yet, the entire application can be built with
>>>>>> $ make
>>>>>
>>>>> I bet you can't. There's something missing. Unless the implicit file
>>>>> that make uses happens to be in that '$' directory. Usually you have
>>>>> to navigate to the project first.
>>>>
>>>> That '$' is a shell prompt, not a directory.
>>>>
>>>> Yes, you have to "cd" (like "chdir" on Windows) to the project
>>>> directory
>>>> before typing "make". You also have to make sure the computer is
>>>> powered on, login, launch a shell, and maybe one or two other things
>>>> before you get to that point.
>>>
>>> You're missing the point. SL is making a big deal about the fact that
>>> you can type 'make' without providing any apparent input. But that
>>> input is provided when you use 'cd' to get the relevant folder.
>>>
>>> Or do you think that the 'make' command provided will build that
>>> specific project irrespective of the CWD?
>>
>> Let me put it another way; how does:
>>
>> $ make
>>
>> know it is to build that project, and not any other? The default input
>> is presumably "./makefile", with the key bit being that ".".
>
> Yes, that's the usual way for non-trivial uses. (For simple cases, the
> build-it rules are good enough, given a target.) You can give make an
> explicit makefile ("make -f proj.make") or it will try to find the
> default one in the current directory. For gnu make (there are /many/
> other "make" implementations), it will try "GNUmakefile", "makefile",
> then "Makefile".
>
>>
>> So, when claiming that you only need to type one thing to start the
>> process, it is disingenuous to leave out that part out.
>
> No. Your makefile (or cmake files, or bake files, or whatever build
> system you use) are part of your project - they are part of the source.
>
>>
>> After all, if you wanted to build project A, and, separately, project
>> B, you can't do both of them like this:
>>
>> $ make
>> $ make
>
> I think most people here assume the reader is familiar with the very
> basics of working a computer. But if you want it spelt out, you would
> generally do :
>
> $ cd ~/projects/project_a
> $ make
> $ cd ~/projects/project_b
> $ make
>
> Does that answer your question?
Humm. I detect a little bit of OCD on Bart's side? Am I wrong?
>
> If the two projects are closely connected, you might have them organised
> as sub-directories of "project". Then at the top-level, you could have
> a makefile with:
>
>
> all : project_a project_b
> .PHONY : project_a project_b
>
> project_a :
> $(MAKE) -C project_a
>
> project_b :
> $(MAKE) -C project_b
>
>
> Then you can build project_a by going to the project_a directory and
> typing "make", or going to the top-level project directory and typing
> "make project_a", or going to the top-level project directory and typing
> "make" to build project_a and project_b, together. (This is often
> particularly nice when using parallel make to make use of all the cores
> in your expensive computer.)
>
>>
>> We've covered this before. While I quite like sensible defaults, where
>> C compilers tend to be sticklers for dotting all the Is, 'make' goes a
>> little too far the other way.
>>
>> Before typing 'make', you'd better be sure you're in the right place!
>>
>
> The same is true of getting undressed, and indeed most things in life.
>
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2024-01-12 16:04 -0800 |
| Message-ID | <unsk2f$3kmu8$5@dont-email.me> |
| In reply to | #380032 |
On 1/11/2024 4:24 AM, David Brown wrote:
> On 10/01/2024 21:20, bart wrote:
>> On 10/01/2024 19:24, bart wrote:
>>> On 10/01/2024 18:39, Keith Thompson wrote:
>>>> bart <bc@freeuk.com> writes:
>>>>> On 10/01/2024 14:49, Scott Lurndal wrote:
>>>> [...]
>>>>>> Yet, the entire application can be built with
>>>>>> $ make
>>>>>
>>>>> I bet you can't. There's something missing. Unless the implicit file
>>>>> that make uses happens to be in that '$' directory. Usually you have
>>>>> to navigate to the project first.
>>>>
>>>> That '$' is a shell prompt, not a directory.
>>>>
>>>> Yes, you have to "cd" (like "chdir" on Windows) to the project
>>>> directory
>>>> before typing "make". You also have to make sure the computer is
>>>> powered on, login, launch a shell, and maybe one or two other things
>>>> before you get to that point.
>>>
>>> You're missing the point. SL is making a big deal about the fact that
>>> you can type 'make' without providing any apparent input. But that
>>> input is provided when you use 'cd' to get the relevant folder.
>>>
>>> Or do you think that the 'make' command provided will build that
>>> specific project irrespective of the CWD?
>>
>> Let me put it another way; how does:
>>
>> $ make
>>
>> know it is to build that project, and not any other? The default input
>> is presumably "./makefile", with the key bit being that ".".
>
> Yes, that's the usual way for non-trivial uses. (For simple cases, the
> build-it rules are good enough, given a target.) You can give make an
> explicit makefile ("make -f proj.make") or it will try to find the
> default one in the current directory. For gnu make (there are /many/
> other "make" implementations), it will try "GNUmakefile", "makefile",
> then "Makefile".
>
>>
>> So, when claiming that you only need to type one thing to start the
>> process, it is disingenuous to leave out that part out.
>
> No. Your makefile (or cmake files, or bake files, or whatever build
> system you use) are part of your project - they are part of the source.
>
>>
>> After all, if you wanted to build project A, and, separately, project
>> B, you can't do both of them like this:
>>
>> $ make
>> $ make
>
> I think most people here assume the reader is familiar with the very
> basics of working a computer. But if you want it spelt out, you would
> generally do :
>
> $ cd ~/projects/project_a
> $ make
> $ cd ~/projects/project_b
> $ make
>
> Does that answer your question?
>
> If the two projects are closely connected, you might have them organised
> as sub-directories of "project". Then at the top-level, you could have
> a makefile with:
>
>
> all : project_a project_b
> .PHONY : project_a project_b
>
> project_a :
> $(MAKE) -C project_a
>
> project_b :
> $(MAKE) -C project_b
>
>
> Then you can build project_a by going to the project_a directory and
> typing "make", or going to the top-level project directory and typing
> "make project_a", or going to the top-level project directory and typing
> "make" to build project_a and project_b, together. (This is often
> particularly nice when using parallel make to make use of all the cores
> in your expensive computer.)
>
>>
>> We've covered this before. While I quite like sensible defaults, where
>> C compilers tend to be sticklers for dotting all the Is, 'make' goes a
>> little too far the other way.
>>
>> Before typing 'make', you'd better be sure you're in the right place!
>>
>
> The same is true of getting undressed, and indeed most things in life.
>
Comic relief. Bart vs the Makefile:
https://youtu.be/_-5QTdC7hOo
Just kidding around.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-01-12 16:24 -0800 |
| Message-ID | <874jfim664.fsf@nosuchdomain.example.com> |
| In reply to | #380103 |
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
[91 lines deleted]
>
> Comic relief. Bart vs the Makefile:
>
> https://youtu.be/_-5QTdC7hOo
>
> Just kidding around.
Chris, can you at least snip most of the quoted text when you post a
joke followup?
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2024-01-12 16:36 -0800 |
| Message-ID | <unsltt$3kmu8$6@dont-email.me> |
| In reply to | #380105 |
On 1/12/2024 4:24 PM, Keith Thompson wrote: > "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes: > [91 lines deleted] >> >> Comic relief. Bart vs the Makefile: >> >> https://youtu.be/_-5QTdC7hOo >> >> Just kidding around. > > Chris, can you at least snip most of the quoted text when you post a > joke followup? > Yeah. I see what you mean. Quote 100 lines to write one. Sorry, a bad habit indeed. To quote more than necessary. ;^o
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2024-01-12 16:43 -0800 |
| Message-ID | <unsmcd$3kmu8$7@dont-email.me> |
| In reply to | #380106 |
On 1/12/2024 4:36 PM, Chris M. Thomasson wrote: > On 1/12/2024 4:24 PM, Keith Thompson wrote: >> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes: [...] >> Chris, can you at least snip most of the quoted text when you post a >> joke followup? [...] > Yeah. I see what you mean. Quote 100 lines to write one. Sorry, a bad > habit indeed. To quote more than necessary. ;^o Sorry to Bart as well, it was just a joke.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2024-01-10 19:36 -0800 |
| Message-ID | <unnno1$2roro$6@dont-email.me> |
| In reply to | #379998 |
On 1/10/2024 10:13 AM, bart wrote:
> On 10/01/2024 14:49, Scott Lurndal wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>> On 10/01/2024 03:14, Bart wrote:
>>>> On 10/01/2024 02:00, Scott Lurndal wrote:
>>>>> Bart <bc@freeuk.cm> writes:
>>>>>> On 10/01/2024 00:05, Keith Thompson wrote:
>>>>>>> Bart <bc@freeuk.cm> writes:
>>>>>
>>>>>> An easy compiler is one where you just do:
>>>>>>
>>>>>> gcc prog
>>>>>>
>>>>>> and not, at the very least:
>>>>>>
>>>>>> gcc prog.c -prog.exe -std=c11 -pedantic-errors
>>>>>
>>>>>
>>>>> $ functions c
>>>>> function c
>>>>> {
>>>>> gcc -o "$1" -std=c11 -pedantic-errors "$1".c
>>>>> }
>>>>> $ cat a.c
>>>>> #include <stdio.h>
>>>>>
>>>>> int
>>>>> main(int argc, const char **argv, const char **envp)
>>>>> {
>>>>>
>>>>> printf("Hello World\n");
>>>>>
>>>>> return 0;
>>>>> }
>>>>> $ c a
>>>>> $ ./a
>>>>> Hello World
>>>>>
>>>>> Can't get any more concise than that.
>>>>
>>>> Great. Now tell the gcc people that's what it should do ANYWAY.
>>>
>>> But it is /not/ what gcc should do.
>>>
>>> You seem to be mixing up "what Bart wants" with "what countless other
>>> people want". Write your own tools to revolve around your own selfish
>>> needs if that's your preference, but don't expect everyone else to
>>> change their worlds to suit /you/.
>>>
>>>
>>> Scott wrote that as an example that might suit you.
>>
>>> I am confident that
>>> the compiler options he mostly uses are different from that - and that
>>> he uses a variety of different options and different times, and that
>>> they are different from the options /I/ use or anyone else uses.
>>
>> Indeed. I use a Makefile and the Makefile.defs include alone has 373
>> lines - something sure to piss Bart off. Of course, the project
>> has:
>>
>> SLOC Directory SLOC-by-Language (Sorted)
>> 7316068 include ansic=7274603,cpp=41465
>> 899374 tests
>> python=763294,ansic=82789,asm=34873,cpp=18013,sh=405
>> 885492 io cpp=603113,ansic=281285,python=466,sh=324,asm=304
>> 133342 processor cpp=131855,python=1487
>> 133153 3rd_party cpp=133033,sh=78,python=42
>> 26803 tools
>> python=17834,cpp=4300,sh=1903,ansic=1459,perl=1199,
>> ruby=108
>> 16754 gen ansic=16754
>> 10955 platform cpp=10955
>> 8392 common cpp=8392
>> 5290 bin cpp=5118,python=172
>> 2204 cpc cpp=2204
>> 1883 top_dir cpp=1883
>> 1430 noc cpp=1430
>> 560 shim cpp=560
>>
>> SLOC doesn't include whitespace or comments.
>>
>> That's about 10 million lines of code across several hundred source
>> and include files.
>>
>> Yet, the entire application can be built with
>>
>> $ make
>
> I bet you can't.
Hummm... Are you sure about that?
> There's something missing. Unless the implicit file
> that make uses happens to be in that '$' directory. Usually you have to
> navigate to the project first.
>
> So of the two parts a typical build needs: the program, script or
> process that is launched to do the work, and the input needed, one has
> already been provided.
>
> A more sensible way would be to require:
>
> make inputfile
>
> Then you could build stuff from anywhere.
>
> BTW well done for discovering that, if a build sequence requires
> multiple commands to be executed, you can put those into a 'script' that
> requires a single invocation.
>
> Just as long as you realise that this isn't doing away with those
> multiple steps, it's hiding them away not simplifying, and adding ONE
> MORE step to the process.
>
> The stuff I do is genuine simplification.
>
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2024-01-09 20:05 -0500 |
| Message-ID | <unkqgi$272d7$1@dont-email.me> |
| In reply to | #379968 |
Bart <bc@freeuk.cm> writes: > On 09/01/2024 22:37, James Kuyper wrote: >> The fact that you didn't get the required diagnostic message is because >> none of those programs conforms to any version of the C standard in it's >> default mode. Since you've made it clear that putting them into >> conforming mode is too complicated for you to understand, > > So why doesn't a /C/ compiler put itself into conforming mode? You didn't use any C compilers, at least, you didn't use them as C compilers. At least two of them (I don't know about tcc) can compile standard C, but only if you instruct them to do so. When you fail to tell them so, they are not standard C compilers, they are compilers for non-standard variants of C. > It seems THAT is too hard for it to understand! > > Seriously, why don't they do that? Because they don't want to. The language that they compile by default is a language that they like better than standard C. People like me who value standard conformance are sufficiently common that they provide options which enable standard conformance, but their target audience WANTS support for a C-like language that they like better than standard C, and that's what they provide. > Then lots of people who don't bother with those fiddly options don't > get the wrong impression about what C actually allows. Most people who don't bother checking out the available options are generally primarily interested in knowing what the compiler they are actually using allows - if they cared about standard conformance, they'd check whether the compiler claimed to be standard conforming, and would quickly notice that the compiler only makes such claims when invoked with particular options. People who don't bother making such checks, despite wanting standard conformance, quickly learn that they don't actually get it - except for you, of course. That's something you seem incapable of learning.
[toc] | [prev] | [next] | [standalone]
Page 25 of 34 — ← Prev page 1 … 23 24 [25] 26 27 … 34 Next page →
Back to top | Article view | comp.lang.c
csiph-web