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 32 of 34 — ← Prev page 1 … 30 31 [32] 33 34 Next page →
| From | BGB <cr88192@gmail.com> |
|---|---|
| Date | 2024-01-01 13:06 -0600 |
| Message-ID | <umv2fs$2a871$1@dont-email.me> |
| In reply to | #379746 |
On 1/1/2024 5:56 AM, Bart wrote:
> On 01/01/2024 02:00, Lawrence D'Oliveiro wrote:
>> On Mon, 1 Jan 2024 01:33:38 +0000, Bart wrote:
>>
>>> On 31/12/2023 23:46, Lawrence D'Oliveiro wrote:
>>>>
>>>> If you meant “you can’t build the simplest
>>>> program *on Windows* without involving half of Linux” ... well, that’s
>>>> just a reflection on the deficiencies of Windows. On Linux, you already
>>>> have the *whole* of Linux to start with.
>>>
>>> And developers feel it necessary to USE everything that it provides!
>>
>> It’s called “code reuse”. A well-designed package-management system just
>> makes it so much easier to do.
>>
>>> I've never managed to build the GMP library on Windows for example (it
>>> only comes as source code), because it requires that 30,000-line bash
>>> script which in turn needs sed and m4 and all the rest.
>>>
>>> Why? It's a numeric library. Why should it be dependent on OS?
>>
>> Those are just standard file-manipulation tools that any decent OS should
>> provide.
>
> What's that got to do with building able to build programs easily?
>
> I have an interpreter app 'qc' which is 37 modules and 39Kloc. It's not
> in C, and I usually build it on Windows like this:
>
> c:\qx>mm qc
>
> It takes 0.1 seconds. I don't support Linux directly, but I can port it
> by transpiling to C first, which takes 90ms:
>
> c:\qc>mc -c -linux qc
>
> Now I can build it under WSL:
>
> root@xxx:/mnt/c/qx# gcc qc.c -oqc -fno-builtin -lm -ldl
>
> And run it, but it needs the '-nosys' option as its std libraries make
> use of WinAPI:
>
> root@xxx:/mnt/c/qx# ./qc -nosys hello
> Hello, World! 1-Jan-2024 11:43:54
>
> Here is the demo program it runs:
>
> root@xxx:/mnt/c/qx# cat hello.q
> println "Hello, World!", $date, $time
>
> And these are the specs for those files:
>
> c:\qx>dir qc.c qc
> 01/01/2024 11:40 1,392,581 qc.c
> 01/01/2024 11:42 846,488 qc
>
> Quite a substantial program that can be built effortlessly on either
> Windows or Linux. Using Tiny C, it apparently compiles it in 75ms.
>
> Try the same exercise with any equivalentally-sized program originating
> on Linux. That is end, end up with only a C file (even multiple C files)
> that I can build with a bare compiler.
>
> That seems to be beyond most Linux developers.
>
For a lot of stuff, it is surprising what one can get done with a
one-liner shell script or batch file:
gcc -o prog_name sources... options...
Or:
cl /Feprog_name sources... options...
And, then 'make' is still plenty usable.
The more complex build systems often don't really help, they often make
the problem worse, and are needlessly overkill for most programs.
Also usually makes sense to be conservative for what one uses, trying to
avoid dependencies on things that aren't actually needed for a given
program (or may not be available on the various targets).
>>
>>> Or maybe Linux developers NEED all that hand-holding and have no idea
>>> how to build using a bare compiler.
>>
>> If only you could do that on Windows ... but no. Look at all the C
>> runtime
>> stuff needed just to build a simple “Hello World” program ... because
>> Windows automatically assumes that every program must have a GUI.
>
> It sounds like you've either never used Windows or had one bad
> experience, as this is incorrect.
>
> If I do this on Windows:
>
> mcc hello.c
>
> it produces a file hello.exe which is 2.5KB. (Tcc manages it in 2.0KB!)
>
> So what's the fuss?
>
Yeah, and if one does a console program, the code is basically identical
either way:
#include <stdio.h>
int main(int argc, char *argv[])
{
printf("Hello World\n");
return(0);
}
If building it from the command line with MSVC:
cl helloworld.c
Not a big issue...
GUI is a pain, but this is true regardless of OS.
Would be good though if there were a "good" portable way to do cross
platform GUI programs, but alas.
A common strategy is for a program does all the UI drawing itself, can
avoid need for platform-specific window-management code by using SDL or
similar.
Theoretically, GTK exists, but tends to be borderline unusable on
Windows (and then, it usually ends up needing to be built via Cygwin or
similar, which has the drawback that any GUI programs that use it will
also end up spawning a console window in the background).
One other drawback of GTK is that it doesn't really separate the API
from the implementation, so GTK only really exists as "the library" and
not as an API that may have multiple underlying implementations (which
would be the more preferable strategy IMO). But, at the same time, the
API design for GTK is not itself particularly friendly to this sort of
approach (it is better to have an API design where the libraries'
implementation details are almost entirely opaque to the client program;
which isn't really the case with GTK).
For programs that may use OpenGL, it ends up common to use OpenGL for
all the UI stuff as well.
Though, at this point, if one does make a cross-platform widget library,
also good if it can also play well with OpenGL (and would prefer if
OpenGL stays around, as Vulkan is not really a good "general purpose"
replacement IMHO).
For a lot of "general use" stuff (namely, for stuff that is not high-end
3D games), something like OpenGL 1.3 to 2.1 seems "nearly ideal" (GL3.x
deprecates a lot of stuff that is useful for these "lower end"
use-cases). In newer OpenGL versions, this variant was renamed to being
the "Compatibility Profile".
In my project's OpenGL implementation, it is mostly limited to 1.x style
functionality, as I have yet to implement a GLSL compiler (also the
hardware rasterizer module only does fixed function, so any shaders
would effectively end up being run on the CPU anyways). But, granted, I
was originally using software rasterization, so it isn't that much
different, apart from a question of how to compile GLSL in a way that
wont "totally suck" for performance.
One advantage also of GL1.x and fixed-function is that it is at least a
viable option to implement for targets which don't have a GPU.
Granted, one could argue that OpenGL is still a heavyweight option for
GUI if one doesn't need any fancy graphical features (and could have
just drawn the UI into a bitmap buffer).
Would be nice if the widget toolkit could work either way:
Using raw bitmap graphics if this is all that is needed;
Using OpenGL or a hybrid option if GL is in use.
Hybrid, eg: drawing into a bitmap and then using glDrawPixels or similar
to overlay the GUI widgets on top of the parts drawn via GL.
Maybe could also make sense to have a Unicode font expressed in SDF form
and similar (possibly with multiple mip levels to improve glyph quality).
...
>>
>>> Remember that end-users building
>>> such projects are only doing a one-time build to get a working binary.
>>
>> They find it easier to do “apt-get install”, or a GUI wrapper around
>> same,
>> like Synaptic.
>
> Windows applications have for long been a ready-to-run binary.
Yeah, and for the most part, pretty much any program compiled within the
past 25 years or so is going to work without issue using the original
binaries (much past this, the main problem cases being programs
targeting MS-DOS or Win16).
We don't need OS repos, because program installers can be casually
downloaded off the internet.
I guess, technically there is now the "Microsoft Store" (which is sort
of like "Google Play" on Android), but haven't really used it for much.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.cm> |
|---|---|
| Date | 2024-01-01 20:13 +0000 |
| Message-ID | <umv6ch$2aplh$1@dont-email.me> |
| In reply to | #379754 |
On 01/01/2024 19:06, BGB wrote:
> On 1/1/2024 5:56 AM, Bart wrote:
>> Quite a substantial program that can be built effortlessly on either
>> Windows or Linux. Using Tiny C, it apparently compiles it in 75ms.
>>
>> Try the same exercise with any equivalentally-sized program
>> originating on Linux. That is end, end up with only a C file (even
>> multiple C files) that I can build with a bare compiler.
>>
>> That seems to be beyond most Linux developers.
>>
>
> For a lot of stuff, it is surprising what one can get done with a
> one-liner shell script or batch file:
> gcc -o prog_name sources... options...
> Or:
> cl /Feprog_name sources... options...
>
The approaches I use are mainly:
1 Submit all the files, libraries and options on one line like
your example. Using up/down keys to recall commands.
2 Put the command line in (1) into a shell script
3 Put the same information, usually on multiple lines into an
'@' file, then build using 'gcc @file' for example.
The above are fine as instructions for someoneelse to do a one-off build
of your project. But what I normally use for development:
4 I use my 60KB console IDE and a project file descripting the modules
similar to the @ file. Now I can browse/edit/compile individual
files, and link and run the lot.
The problem with 1/2/3 when using a slow compiler like gcc is that you
have to compile everything. With (4) I can compile only what's relevant.
Since I will be very familiar with the project, I will know the main
dependencies and will know when I need to build everything.
> And, then 'make' is still plenty usable.
If you understand make, that's fine. I generally prefer my option (4),
which I've used, in various forms, for decades.
I wouldn't however inflict a makefile-based build on someone; I might
supply (3) and a one-line build instruction. Unless it's a generated C
then it will be one file anyway, or it might even be just *.c.
> The more complex build systems often don't really help, they often make
> the problem worse, and are needlessly overkill for most programs.
They very often don't work, especially outside their comfort zone of Linux.
> Yeah, and if one does a console program, the code is basically identical
> either way:
> #include <stdio.h>
> int main(int argc, char *argv[])
> {
> printf("Hello World\n");
> return(0);
> }
>
> If building it from the command line with MSVC:
> cl helloworld.c
>
> Not a big issue...
> GUI is a pain, but this is true regardless of OS.
>
>
> Would be good though if there were a "good" portable way to do cross
> platform GUI programs, but alas.
>
> A common strategy is for a program does all the UI drawing itself, can
> avoid need for platform-specific window-management code by using SDL or
> similar.
I've given up on GUI from a compiled language. I use it only from my
interpreted code using library that works on top of WinAPI. It was
supposed to be adaptable to X11, but I never got around to it, and that
looks as terrible as WinAPI anyway.
However SDL seems a reasonable compromise. It's a LOT smaller than GTK
(which is really a collection of libraries; I think it comprises 50
different DLLs). There are smaller ones around, but it general it's too
much of a pain. You're also never going to produce something as flashy
as even the tackiest Android app.
> One other drawback of GTK is that ...
... it's a monster.
(When I did try to test my compiler on it a few years ago - the API and
DLLs, not the source codes; the headers are complicated enough - I found
that one of its structs used bitfields, which are
implementation-dependent, in a public API.
That means the size of the struct, which is critical, depended on how
the compiler dealt with bitfields. I think it mainly works by luck since
most use gcc or compatible, that matches what was used to build the
library.)
> We don't need OS repos, because program installers can be casually
> downloaded off the internet.
>
> I guess, technically there is now the "Microsoft Store" (which is sort
> of like "Google Play" on Android), but haven't really used it for much.
Good luck in getting your app into one of those stores.
It's getting harder to provide binaries to Windows users, first because
your machine now needs to be unlocked to run arbitrary EXE files (even
MS apps like command.exe are otherwise banned!).
But also because a random EXE will tricker AV warnings or even
quarantine your program.
I don't know how programs such as C compilers that you download get
around such checks.
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@gmail.com> |
|---|---|
| Date | 2024-01-01 20:20 -0600 |
| Message-ID | <umvrsq$2db83$1@dont-email.me> |
| In reply to | #379755 |
On 1/1/2024 2:13 PM, Bart wrote:
> On 01/01/2024 19:06, BGB wrote:
>> On 1/1/2024 5:56 AM, Bart wrote:
>
>>> Quite a substantial program that can be built effortlessly on either
>>> Windows or Linux. Using Tiny C, it apparently compiles it in 75ms.
>>>
>>> Try the same exercise with any equivalentally-sized program
>>> originating on Linux. That is end, end up with only a C file (even
>>> multiple C files) that I can build with a bare compiler.
>>>
>>> That seems to be beyond most Linux developers.
>>>
>>
>> For a lot of stuff, it is surprising what one can get done with a
>> one-liner shell script or batch file:
>> gcc -o prog_name sources... options...
>> Or:
>> cl /Feprog_name sources... options...
>>
>
> The approaches I use are mainly:
>
> 1 Submit all the files, libraries and options on one line like
> your example. Using up/down keys to recall commands.
>
> 2 Put the command line in (1) into a shell script
>
> 3 Put the same information, usually on multiple lines into an
> '@' file, then build using 'gcc @file' for example.
>
> The above are fine as instructions for someoneelse to do a one-off build
> of your project. But what I normally use for development:
>
> 4 I use my 60KB console IDE and a project file descripting the modules
> similar to the @ file. Now I can browse/edit/compile individual
> files, and link and run the lot.
>
> The problem with 1/2/3 when using a slow compiler like gcc is that you
> have to compile everything. With (4) I can compile only what's relevant.
> Since I will be very familiar with the project, I will know the main
> dependencies and will know when I need to build everything.
>
One-liner shell-scripts make sense if the program is "small enough".
If one is pushing the limits of what is viable with a one-liner, mostly
better to move on to a Makefile or similar.
Though, admittedly, I do use GNU Make and similar on Windows rather than
MS's "nmake".
Though, just went and checked, was a pretty easy change to make BGBCC
able to build with 'nmake'.
But, for things like my BJX2 emulator, yeah, was generally building this
with "one liners".
Granted, the BJX2 emulator is basically a unity build, as in:
One top-level C file, that #include's everything else in the program.
Where, typically is is both faster and easier much of the time to
unity-build stuff rather than to have each file be its own translation
unit (in this case, all of the headers and similar only really need to
be processed once).
>
>> And, then 'make' is still plenty usable.
>
> If you understand make, that's fine. I generally prefer my option (4),
> which I've used, in various forms, for decades.
>
> I wouldn't however inflict a makefile-based build on someone; I might
> supply (3) and a one-line build instruction. Unless it's a generated C
> then it will be one file anyway, or it might even be just *.c.
>
Makefile's scale better than shell-scripts for this, and can be made
moderately portable and reusable by splitting the generic and
platform-specific parts into two different files, say:
Makefile.inc: includes the lists of source files and abstracted build
targets.
Makefile.sometarget: Defines parameters for the compiler and similar for
the target, uses "include Makefile.inc" or similar for the rest.
Say, for example:
Makefile.lnx: Makefile for Linux and similar;
Makefile.msvc: Makefile for Windows via MSVC;
Makefile.cyg: Makefile for Windows via Cygwin;
...
And, if the Makefile isn't some mountain of auto-generated crap, then
people can fix it (without too much effort) if something is broken.
>
>> The more complex build systems often don't really help, they often
>> make the problem worse, and are needlessly overkill for most programs.
>
> They very often don't work, especially outside their comfort zone of Linux.
>
Of these, CMake is at least competent at being cross-platform (much
better than autotools in this regard).
>> Yeah, and if one does a console program, the code is basically
>> identical either way:
>> #include <stdio.h>
>> int main(int argc, char *argv[])
>> {
>> printf("Hello World\n");
>> return(0);
>> }
>>
>> If building it from the command line with MSVC:
>> cl helloworld.c
>>
>> Not a big issue...
>
>
>
>> GUI is a pain, but this is true regardless of OS.
>>
>>
>> Would be good though if there were a "good" portable way to do cross
>> platform GUI programs, but alas.
>>
>> A common strategy is for a program does all the UI drawing itself, can
>> avoid need for platform-specific window-management code by using SDL
>> or similar.
>
> I've given up on GUI from a compiled language. I use it only from my
> interpreted code using library that works on top of WinAPI. It was
> supposed to be adaptable to X11, but I never got around to it, and that
> looks as terrible as WinAPI anyway.
>
> However SDL seems a reasonable compromise. It's a LOT smaller than GTK
> (which is really a collection of libraries; I think it comprises 50
> different DLLs). There are smaller ones around, but it general it's too
> much of a pain. You're also never going to produce something as flashy
> as even the tackiest Android app.
>
If drawing everything oneself, the difference between Win32/X11/SDL
becomes mostly a matter of glue code.
Big uphill battle though to make something that has anything near the
native UI aesthetic (well, assuming one bothers at all).
Or, if one does manage to copy the look, it may become very obvious if
the OS goes and tweaks the widget style, or if the user sets up a
customized theme or color scheme, and suddenly these programs no longer
match with the other "native" programs.
One does sort of end up in a world where most of the software does end
up with slightly different looking GUI widgets, and if one changes the
OS away from the default color scheme, all this becomes very obvious.
Goes and checks; interestingly it does appear that at least Firefox and
Thunderbird seem to respect changing the Windows color-scheme (well,
along with the stuff that is part of Windows itself). AFAIK, the Mozilla
software does its own widget drawing, implying there may be a way to
query the current UI colors?...
Much of the other software I am running, not so much...
Granted, at least, most programs make an effort to mimic the default
aesthetic (probably better I guess than having a world where every
program has its own unique aesthetic and color scheme...).
>
>> One other drawback of GTK is that ...
>
> ... it's a monster.
>
> (When I did try to test my compiler on it a few years ago - the API and
> DLLs, not the source codes; the headers are complicated enough - I found
> that one of its structs used bitfields, which are
> implementation-dependent, in a public API.
>
> That means the size of the struct, which is critical, depended on how
> the compiler dealt with bitfields. I think it mainly works by luck since
> most use gcc or compatible, that matches what was used to build the
> library.)
>
Partly related to my comments.
But, yeah, ideally one would have a widget toolkit where one doesn't
need to care which actual implementation is used (or how things might
work internally).
Also the GUI's widget toolkit shouldn't try to be a platform unto itself...
>> We don't need OS repos, because program installers can be casually
>> downloaded off the internet.
>>
>> I guess, technically there is now the "Microsoft Store" (which is sort
>> of like "Google Play" on Android), but haven't really used it for much.
>
> Good luck in getting your app into one of those stores.
>
> It's getting harder to provide binaries to Windows users, first because
> your machine now needs to be unlocked to run arbitrary EXE files (even
> MS apps like command.exe are otherwise banned!).
>
> But also because a random EXE will tricker AV warnings or even
> quarantine your program.
>
> I don't know how programs such as C compilers that you download get
> around such checks.
>
On my system, I am not seeing too many issues here.
Sometimes, if one downloads something, it is needed to confirm that one
does actually intend to run it.
Granted, I am running Win10 Pro, not sure what the situation looks like
on some other versions.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-01-02 02:34 +0000 |
| Message-ID | <umvsog$2dccr$1@dont-email.me> |
| In reply to | #379772 |
On Mon, 1 Jan 2024 20:20:08 -0600, BGB wrote: > And, if the Makefile isn't some mountain of auto-generated crap, then > people can fix it (without too much effort) if something is broken. Remember the GNU definition of “source code”: it is whatever the preferred format is for doing development on the project. If they won’t give you that, then the project isn’t “open source”. If the Makefile is indeed a “mountain of auto-generated crap”, then you shouldn’t be fiddling with it (if only for your own sanity): instead, find the source file(s) used to generate it, and fiddle them instead. > Of these, CMake is at least competent at being cross-platform (much > better than autotools in this regard). And CMake is a popular example of something that will indeed produce Makefiles (actually a whole swarm of them) that are collectively a “mountain of auto-generated crap”. And if you take the concept further, assuming that your Makefile- equivalent is always going to be auto-generated, then you can get rid of a lot of the niceties (and complications, and overhead) that aid manual writing of same. And the result would be something called “Ninja”.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-01-01 21:39 +0000 |
| Message-ID | <umvbe7$2b9bl$4@dont-email.me> |
| In reply to | #379754 |
On Mon, 1 Jan 2024 13:06:34 -0600, BGB wrote: > The more complex build systems often don't really help, they often make > the problem worse, and are needlessly overkill for most programs. Easy for the armchair programmer to say. All you have to do is look at the build scripts yourself, and show us how you can simplify them. Put your money where your mouth is, in effect.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-01-01 21:38 +0000 |
| Message-ID | <umvbc4$2b9bl$3@dont-email.me> |
| In reply to | #379746 |
On Mon, 1 Jan 2024 11:56:00 +0000, Bart wrote: > On 01/01/2024 02:00, Lawrence D'Oliveiro wrote: > >> Those are just standard file-manipulation tools that any decent OS >> should provide. > > What's that got to do with building able to build programs easily? You have effectively answered that question yourself. Why were you trying to build GNU GMP on Windows? Isn’t there something equally capable and yet more, shall we say, “native” to Windows, that you can build and use in a more “Windows-native” fashion? Obviously the answer is no. And why? Because the Windows environment is simply not conducive to the development of such software. Which is why the software that exists is primarily oriented towards Linux-compatible systems, and why you struggle to get it going on Windows.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.cm> |
|---|---|
| Date | 2024-01-01 22:51 +0000 |
| Message-ID | <umvfm8$2c0ho$1@dont-email.me> |
| In reply to | #379756 |
On 01/01/2024 21:38, Lawrence D'Oliveiro wrote: > On Mon, 1 Jan 2024 11:56:00 +0000, Bart wrote: > >> On 01/01/2024 02:00, Lawrence D'Oliveiro wrote: >> >>> Those are just standard file-manipulation tools that any decent OS >>> should provide. >> >> What's that got to do with building able to build programs easily? > > You have effectively answered that question yourself. Why were you trying > to build GNU GMP on Windows? Isn’t there something equally capable and yet > more, shall we say, “native” to Windows, that you can build and use in a > more “Windows-native” fashion? > > Obviously the answer is no. And why? Because the Windows environment is > simply not conducive to the development of such software. Why not? The software in question is a bunch of C files with a smattering of .s assembly files for a range of specific architectures. I will tell you one reason: whoever was in charge made the brain-dead decision to employ auto-config tools which are prone to generating ginormous, Linux-specific shell scripts of 10s of thousands of lines. There's no intrinsic reason why such software can't be built anywhere where a 32-bit 'int' type exists. (In the end I developed my own library. It consists of a .h file and a .c file, and can be built anywhere. It needs only a compiler.) > Which is why the > software that exists is primarily oriented towards Linux-compatible > systems, and why you struggle to get it going on Windows. Some kinds of program such as ones that only read or write consoles and files can be universally portable; or all they are C's file functions. But this particular one doesn't even have any I/O; it is a library! So it ought to be even more portable. I once took another program that only came packaged in a similar manner. I could built it under Linux using ./configure, a process which took 5 minutes. But there, I managed to extract the dozen or so C files that formed the main program. Compiling them to an executable on the same machine, under Windows, took about 1 second. So WTF was the point of the rest of it? Too many people, including you it seems, take too much at face value. You just don't ask enough questions.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-01-01 23:10 +0000 |
| Message-ID | <umvgod$2c2sp$3@dont-email.me> |
| In reply to | #379760 |
On Mon, 1 Jan 2024 22:51:52 +0000, Bart wrote: > On 01/01/2024 21:38, Lawrence D'Oliveiro wrote: > >> Obviously the answer is no. And why? Because the Windows environment is >> simply not conducive to the development of such software. > > Why not? You have the answer right in front of your nose: look at the source of the software itself and figure it out. > The software in question is a bunch of C files with a smattering of .s > assembly files for a range of specific architectures. If you can come up with a simpler build system, why not publish your version? And everybody else will adopt it because it will be so much simpler than the present arrangement.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.cm> |
|---|---|
| Date | 2024-01-01 23:45 +0000 |
| Message-ID | <umviqe$2ccb3$1@dont-email.me> |
| In reply to | #379762 |
On 01/01/2024 23:10, Lawrence D'Oliveiro wrote:
> On Mon, 1 Jan 2024 22:51:52 +0000, Bart wrote:
>
>> On 01/01/2024 21:38, Lawrence D'Oliveiro wrote:
>>
>>> Obviously the answer is no. And why? Because the Windows environment is
>>> simply not conducive to the development of such software.
>>
>> Why not?
>
> You have the answer right in front of your nose: look at the source of the
> software itself and figure it out.
So you don't know. You choose to believe that it HAS to be done that
way. I guess if that configure file was 300,000 lines instead of 30,000,
or even 3 million lines and ran for hours, you'd still go along with it?
I'm curious; at what point of ridiculousness would even you start to
question the disproportionality of the process?
>> The software in question is a bunch of C files with a smattering of .s
>> assembly files for a range of specific architectures.
>
> If you can come up with a simpler build system, why not publish your
> version? And everybody else will adopt it because it will be so much
> simpler than the present arrangement.
Sure. But the problem is extracting the requisite information, namely,
the names and locations of all the source files needed for my platform.
Plus I need the actual source files.
With over-elaborate build systems, the information is buried somewhere
inside makefiles. Often the makefiles don't even exist, they have to be
synthesised.
They also like to make some key part of the sources, say a 5-line
config.h file, be synthesised by the build process.
So they make it hard. Even if I can extract that information, that is no
good; it HAS to be done by the suppliers of the software, otherwise with
each new version I have to repeat the process.
========================
Here however is somewhere where I've done just that, although it is
trivial compared with most projects I've come across; the makefile
actually exists, and is only 200 lines. The motivation here was in
having some content to test my C compiler on.
The project is Lua 5.4. I use an @ file containing this list of modules:
lua.c
lapi.c
lcode.c
lctype.c
ldebug.c
ldo.c
ldump.c
lfunc.c
lgc.c
llex.c
lmem.c
lobject.c
lopcodes.c
lparser.c
lstate.c
lstring.c
ltable.c
ltm.c
lundump.c
lvm.c
lzio.c
lauxlib.c
lbaselib.c
lcorolib.c
ldblib.c
liolib.c
lmathlib.c
loadlib.c
loslib.c
lstrlib.c
ltablib.c
lutf8lib.c
linit.c
I compile the project using:
c:\luac>mcc @lua
Compiling 33 files to lua.exe
or using:
c:\luac>tcc @lua
or using:
c:\luac>gcc @lua -olua.exe
or even on Linux using:
root@xxx:/mnt/c/luac# gcc @luafiles -olua -lm
(The @ file name had to be changed as it clashes with the Linux executable.)
It's that simple. (This builds lua.exe; to build lua.dll needs one file
different in the list, and an extra option to the compiler.)
However you are supposed to use a makefile that looks like that below.
Which looks simpler?
(You might notice the makefile relies heavily on .o files. My C compiler
doesn't use .o files, and if it did, they'd be called .obj. Notice also
my list doesn't show .h files; they are not necessary.)
-----------------------------------------------
# Makefile for building Lua
# See ../doc/readme.html for installation and customization instructions.
# == CHANGE THE SETTINGS BELOW TO SUIT YOUR ENVIRONMENT
=======================
# Your platform. See PLATS for possible values.
PLAT= guess
CC= gcc -std=gnu99
CFLAGS= -O2 -Wall -Wextra -DLUA_COMPAT_5_3 $(SYSCFLAGS) $(MYCFLAGS)
LDFLAGS= $(SYSLDFLAGS) $(MYLDFLAGS)
LIBS= -lm $(SYSLIBS) $(MYLIBS)
AR= ar rcu
RANLIB= ranlib
RM= rm -f
UNAME= uname
SYSCFLAGS=
SYSLDFLAGS=
SYSLIBS=
MYCFLAGS=
MYLDFLAGS=
MYLIBS=
MYOBJS=
# Special flags for compiler modules; -Os reduces code size.
CMCFLAGS=
# == END OF USER SETTINGS -- NO NEED TO CHANGE ANYTHING BELOW THIS LINE
=======
PLATS= guess aix bsd c89 freebsd generic ios linux linux-readline macosx
mingw posix solaris
LUA_A= liblua.a
CORE_O= lapi.o lcode.o lctype.o ldebug.o ldo.o ldump.o lfunc.o lgc.o
llex.o lmem.o lobject.o lopcodes.o lparser.o lstate.o lstring.o ltable.o
ltm.o lundump.o lvm.o lzio.o
LIB_O= lauxlib.o lbaselib.o lcorolib.o ldblib.o liolib.o lmathlib.o
loadlib.o loslib.o lstrlib.o ltablib.o lutf8lib.o linit.o
BASE_O= $(CORE_O) $(LIB_O) $(MYOBJS)
LUA_T= lua
LUA_O= lua.o
LUAC_T= luac
LUAC_O= luac.o
ALL_O= $(BASE_O) $(LUA_O) $(LUAC_O)
ALL_T= $(LUA_A) $(LUA_T) $(LUAC_T)
ALL_A= $(LUA_A)
# Targets start here.
default: $(PLAT)
all: $(ALL_T)
o: $(ALL_O)
a: $(ALL_A)
$(LUA_A): $(BASE_O)
$(AR) $@ $(BASE_O)
$(RANLIB) $@
$(LUA_T): $(LUA_O) $(LUA_A)
$(CC) -o $@ $(LDFLAGS) $(LUA_O) $(LUA_A) $(LIBS)
$(LUAC_T): $(LUAC_O) $(LUA_A)
$(CC) -o $@ $(LDFLAGS) $(LUAC_O) $(LUA_A) $(LIBS)
test:
./$(LUA_T) -v
clean:
$(RM) $(ALL_T) $(ALL_O)
depend:
@$(CC) $(CFLAGS) -MM l*.c
echo:
@echo "PLAT= $(PLAT)"
@echo "CC= $(CC)"
@echo "CFLAGS= $(CFLAGS)"
@echo "LDFLAGS= $(LDFLAGS)"
@echo "LIBS= $(LIBS)"
@echo "AR= $(AR)"
@echo "RANLIB= $(RANLIB)"
@echo "RM= $(RM)"
@echo "UNAME= $(UNAME)"
# Convenience targets for popular platforms.
ALL= all
help:
@echo "Do 'make PLATFORM' where PLATFORM is one of these:"
@echo " $(PLATS)"
@echo "See doc/readme.html for complete instructions."
guess:
@echo Guessing `$(UNAME)`
@$(MAKE) `$(UNAME)`
AIX aix:
$(MAKE) $(ALL) CC="xlc" CFLAGS="-O2 -DLUA_USE_POSIX -DLUA_USE_DLOPEN"
SYSLIBS="-ldl" SYSLDFLAGS="-brtl -bexpall"
bsd:
$(MAKE) $(ALL) SYSCFLAGS="-DLUA_USE_POSIX -DLUA_USE_DLOPEN"
SYSLIBS="-Wl,-E"
c89:
$(MAKE) $(ALL) SYSCFLAGS="-DLUA_USE_C89" CC="gcc -std=c89"
@echo ''
@echo '*** C89 does not guarantee 64-bit integers for Lua.'
@echo '*** Make sure to compile all external Lua libraries'
@echo '*** with LUA_USE_C89 to ensure consistency'
@echo ''
FreeBSD NetBSD OpenBSD freebsd:
$(MAKE) $(ALL) SYSCFLAGS="-DLUA_USE_LINUX -DLUA_USE_READLINE
-I/usr/include/edit" SYSLIBS="-Wl,-E -ledit" CC="cc"
generic: $(ALL)
ios:
$(MAKE) $(ALL) SYSCFLAGS="-DLUA_USE_IOS"
Linux linux: linux-noreadline
linux-noreadline:
$(MAKE) $(ALL) SYSCFLAGS="-DLUA_USE_LINUX" SYSLIBS="-Wl,-E -ldl"
linux-readline:
$(MAKE) $(ALL) SYSCFLAGS="-DLUA_USE_LINUX -DLUA_USE_READLINE"
SYSLIBS="-Wl,-E -ldl -lreadline"
Darwin macos macosx:
$(MAKE) $(ALL) SYSCFLAGS="-DLUA_USE_MACOSX -DLUA_USE_READLINE"
SYSLIBS="-lreadline"
mingw:
$(MAKE) "LUA_A=lua54.dll" "LUA_T=lua.exe" \
"AR=$(CC) -shared -o" "RANLIB=strip --strip-unneeded" \
"SYSCFLAGS=-DLUA_BUILD_AS_DLL" "SYSLIBS=" "SYSLDFLAGS=-s" lua.exe
$(MAKE) "LUAC_T=luac.exe" luac.exe
posix:
$(MAKE) $(ALL) SYSCFLAGS="-DLUA_USE_POSIX"
SunOS solaris:
$(MAKE) $(ALL) SYSCFLAGS="-DLUA_USE_POSIX -DLUA_USE_DLOPEN
-D_REENTRANT" SYSLIBS="-ldl"
# Targets that do not create files (not all makes understand .PHONY).
.PHONY: all $(PLATS) help test clean default o a depend echo
# Compiler modules may use special flags.
llex.o:
$(CC) $(CFLAGS) $(CMCFLAGS) -c llex.c
lparser.o:
$(CC) $(CFLAGS) $(CMCFLAGS) -c lparser.c
lcode.o:
$(CC) $(CFLAGS) $(CMCFLAGS) -c lcode.c
# DO NOT DELETE
lapi.o: lapi.c lprefix.h lua.h luaconf.h lapi.h llimits.h lstate.h \
lobject.h ltm.h lzio.h lmem.h ldebug.h ldo.h lfunc.h lgc.h lstring.h \
ltable.h lundump.h lvm.h
lauxlib.o: lauxlib.c lprefix.h lua.h luaconf.h lauxlib.h
lbaselib.o: lbaselib.c lprefix.h lua.h luaconf.h lauxlib.h lualib.h
lcode.o: lcode.c lprefix.h lua.h luaconf.h lcode.h llex.h lobject.h \
llimits.h lzio.h lmem.h lopcodes.h lparser.h ldebug.h lstate.h ltm.h \
ldo.h lgc.h lstring.h ltable.h lvm.h
lcorolib.o: lcorolib.c lprefix.h lua.h luaconf.h lauxlib.h lualib.h
lctype.o: lctype.c lprefix.h lctype.h lua.h luaconf.h llimits.h
ldblib.o: ldblib.c lprefix.h lua.h luaconf.h lauxlib.h lualib.h
ldebug.o: ldebug.c lprefix.h lua.h luaconf.h lapi.h llimits.h lstate.h \
lobject.h ltm.h lzio.h lmem.h lcode.h llex.h lopcodes.h lparser.h \
ldebug.h ldo.h lfunc.h lstring.h lgc.h ltable.h lvm.h
ldo.o: ldo.c lprefix.h lua.h luaconf.h lapi.h llimits.h lstate.h \
lobject.h ltm.h lzio.h lmem.h ldebug.h ldo.h lfunc.h lgc.h lopcodes.h \
lparser.h lstring.h ltable.h lundump.h lvm.h
ldump.o: ldump.c lprefix.h lua.h luaconf.h lobject.h llimits.h lstate.h \
ltm.h lzio.h lmem.h lundump.h
lfunc.o: lfunc.c lprefix.h lua.h luaconf.h ldebug.h lstate.h lobject.h \
llimits.h ltm.h lzio.h lmem.h ldo.h lfunc.h lgc.h
lgc.o: lgc.c lprefix.h lua.h luaconf.h ldebug.h lstate.h lobject.h \
llimits.h ltm.h lzio.h lmem.h ldo.h lfunc.h lgc.h lstring.h ltable.h
linit.o: linit.c lprefix.h lua.h luaconf.h lualib.h lauxlib.h
liolib.o: liolib.c lprefix.h lua.h luaconf.h lauxlib.h lualib.h
llex.o: llex.c lprefix.h lua.h luaconf.h lctype.h llimits.h ldebug.h \
lstate.h lobject.h ltm.h lzio.h lmem.h ldo.h lgc.h llex.h lparser.h \
lstring.h ltable.h
lmathlib.o: lmathlib.c lprefix.h lua.h luaconf.h lauxlib.h lualib.h
lmem.o: lmem.c lprefix.h lua.h luaconf.h ldebug.h lstate.h lobject.h \
llimits.h ltm.h lzio.h lmem.h ldo.h lgc.h
loadlib.o: loadlib.c lprefix.h lua.h luaconf.h lauxlib.h lualib.h
lobject.o: lobject.c lprefix.h lua.h luaconf.h lctype.h llimits.h \
ldebug.h lstate.h lobject.h ltm.h lzio.h lmem.h ldo.h lstring.h lgc.h \
lvm.h
lopcodes.o: lopcodes.c lprefix.h lopcodes.h llimits.h lua.h luaconf.h
loslib.o: loslib.c lprefix.h lua.h luaconf.h lauxlib.h lualib.h
lparser.o: lparser.c lprefix.h lua.h luaconf.h lcode.h llex.h lobject.h \
llimits.h lzio.h lmem.h lopcodes.h lparser.h ldebug.h lstate.h ltm.h \
ldo.h lfunc.h lstring.h lgc.h ltable.h
lstate.o: lstate.c lprefix.h lua.h luaconf.h lapi.h llimits.h lstate.h \
lobject.h ltm.h lzio.h lmem.h ldebug.h ldo.h lfunc.h lgc.h llex.h \
lstring.h ltable.h
lstring.o: lstring.c lprefix.h lua.h luaconf.h ldebug.h lstate.h \
lobject.h llimits.h ltm.h lzio.h lmem.h ldo.h lstring.h lgc.h
lstrlib.o: lstrlib.c lprefix.h lua.h luaconf.h lauxlib.h lualib.h
ltable.o: ltable.c lprefix.h lua.h luaconf.h ldebug.h lstate.h lobject.h \
llimits.h ltm.h lzio.h lmem.h ldo.h lgc.h lstring.h ltable.h lvm.h
ltablib.o: ltablib.c lprefix.h lua.h luaconf.h lauxlib.h lualib.h
ltm.o: ltm.c lprefix.h lua.h luaconf.h ldebug.h lstate.h lobject.h \
llimits.h ltm.h lzio.h lmem.h ldo.h lgc.h lstring.h ltable.h lvm.h
lua.o: lua.c lprefix.h lua.h luaconf.h lauxlib.h lualib.h
luac.o: luac.c lprefix.h lua.h luaconf.h lauxlib.h ldebug.h lstate.h \
lobject.h llimits.h ltm.h lzio.h lmem.h lopcodes.h lopnames.h lundump.h
lundump.o: lundump.c lprefix.h lua.h luaconf.h ldebug.h lstate.h \
lobject.h llimits.h ltm.h lzio.h lmem.h ldo.h lfunc.h lstring.h lgc.h \
lundump.h
lutf8lib.o: lutf8lib.c lprefix.h lua.h luaconf.h lauxlib.h lualib.h
lvm.o: lvm.c lprefix.h lua.h luaconf.h ldebug.h lstate.h lobject.h \
llimits.h ltm.h lzio.h lmem.h ldo.h lfunc.h lgc.h lopcodes.h lstring.h \
ltable.h lvm.h ljumptab.h
lzio.o: lzio.c lprefix.h lua.h luaconf.h llimits.h lmem.h lstate.h \
lobject.h ltm.h lzio.h
# (end of Makefile)
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-01-02 00:05 +0000 |
| Message-ID | <umvk15$2cdin$1@dont-email.me> |
| In reply to | #379763 |
On Mon, 1 Jan 2024 23:45:18 +0000, Bart wrote: > On 01/01/2024 23:10, Lawrence D'Oliveiro wrote: > >> You have the answer right in front of your nose: look at the source of >> the software itself and figure it out. > > So you don't know. You choose to believe that it HAS to be done that > way. Out of curiosity, I *did* have a look at the build system for libgmp. The “configure” file is over 30,000 lines, but that is generated (via m4 macro expansion) from a much smaller (and easier to read) “configure.ac” of about 4,000 lines. And the contents of the latter file are quite interesting. First of all, it includes code for building on a whole lot of proprietary Unix systems with non-GCC compilers, some of which maybe don’t quite conform to official C/C++ standards. You would think all those systems are extinct now, but clearly there are users who still care about them. And that’s not counting the different ways GMP offers for you to build it. For example, do you want profiling? Omit procedure call frames? Static or shared library? Do you want to build the test programs? (Yes, the project includes its own test suite.) Do you want the test programs to use GNU readline to get their input? (Sounds like a handy option to me, at least you have the choice.) That is an amazingly long list of CPU architectures on which you can build it, all the way up to IBM mainframes. And it is in the nature of a library like this, doing CPU-intensive things, that it will need to take account of CPU-specific quirks in order to get maximum efficiency. Hence a whole load of special cases, particularly in code generation, for all these architectures. Look at the ABI options: maybe you want a 32-bit build (where the CPU supports it) rather than a 64-bit one; on some architectures, things get a bit more complicated than just those two options. And so on and so on. Feel free to tell us which parts of these you would get rid of, without antagonizing users who might depend on them.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.cm> |
|---|---|
| Date | 2024-01-02 01:14 +0000 |
| Message-ID | <umvo18$2cucc$1@dont-email.me> |
| In reply to | #379766 |
On 02/01/2024 00:05, Lawrence D'Oliveiro wrote: > On Mon, 1 Jan 2024 23:45:18 +0000, Bart wrote: > >> On 01/01/2024 23:10, Lawrence D'Oliveiro wrote: >> >>> You have the answer right in front of your nose: look at the source of >>> the software itself and figure it out. >> >> So you don't know. You choose to believe that it HAS to be done that >> way. > > Out of curiosity, I *did* have a look at the build system for libgmp. The > “configure” file is over 30,000 lines, but that is generated (via m4 macro > expansion) from a much smaller (and easier to read) “configure.ac” of > about 4,000 lines. And the contents of the latter file are quite > interesting. > > First of all, it includes code for building on a whole lot of proprietary > Unix systems with non-GCC compilers, some of which maybe don’t quite > conform to official C/C++ standards. You would think all those systems are > extinct now, but clearly there are users who still care about them. > > And that’s not counting the different ways GMP offers for you to build it. > For example, do you want profiling? Omit procedure call frames? Static or > shared library? Do you want to build the test programs? (Yes, the project > includes its own test suite.) Do you want the test programs to use GNU > readline to get their input? (Sounds like a handy option to me, at least > you have the choice.) > > That is an amazingly long list of CPU architectures on which you can build > it, all the way up to IBM mainframes. And it is in the nature of a library > like this, doing CPU-intensive things, that it will need to take account > of CPU-specific quirks in order to get maximum efficiency. Hence a whole > load of special cases, particularly in code generation, for all these > architectures. Yeah, that's usually the job of the compiler, the one that exists on my machine, and which knows how to generate code for it. > > Look at the ABI options: maybe you want a 32-bit build (where the CPU > supports it) rather than a 64-bit one; on some architectures, things get a > bit more complicated than just those two options. > > And so on and so on. Feel free to tell us which parts of these you would > get rid of, without antagonizing users who might depend on them. I would have no interest in building it, I wanted a ready-made DLL, for that little-known niche platform known as 'Windows'. However, there is no reliable repository of such libraries, so I can't use it as dependency. I could create my own, but it was a palaver, involving installing, at the time MSYS2. It took forever, but then it failed. So, yes, I want the set of files specific to my platform; I don't care about all the obscure ones it might support. This does not sound unreasonable: after all people commonly download binaries which are specific to a particular machine and processor. Those will have had some specific process applied to generate them. Why not a similar process for a source bundle which is one step away from a binary? I don't even care if all the source files I don't need are bundled. It's easy enough to tell the build process which version I need, if it can't work it out. (Earlier I gave an example of my 'QC' interpreter which can run on either OS. Actually that is a special version that is 100% HLL. The version I normally use is called 'QQ' and used ASM-accelerated elements, just like bits of GMP. That is specific to x64 and WinABI. It can't be transpiled to C. But if somebody really wants to run my interpreter and doesn't have Windows, they can still do so.)
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-01-02 01:58 +0000 |
| Message-ID | <umvqj8$2d5kt$1@dont-email.me> |
| In reply to | #379770 |
On Tue, 2 Jan 2024 01:14:16 +0000, Bart wrote: > I would have no interest in building it, I wanted a ready-made DLL, for > that little-known niche platform known as 'Windows'. That’s too bad. Not getting the service you paid for? Demand your money back! > However, there is no reliable repository of such libraries, so I can't > use it as dependency. Why is it nobody will provide you with one? Not even a multi-billion- dollar corporation with the resources of Microsoft can be bothered, it seems, for this not-at-all “little-known niche platform” you are so fond of. Why not? And after all the money you have paid them to get this wonderful Windows platform! It’s like you didn’t get your money’s worth! > So, yes, I want the set of files specific to my platform; I don't care > about all the obscure ones it might support. > > This does not sound unreasonable ... Fine. Do it yourself. And then you will discover whether that’s an “unreasonable” amount of work or not.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2024-01-01 20:41 -0800 |
| Message-ID | <un045t$2hv4r$1@dont-email.me> |
| In reply to | #379770 |
On 1/1/2024 5:14 PM, Bart wrote: > On 02/01/2024 00:05, Lawrence D'Oliveiro wrote: >> On Mon, 1 Jan 2024 23:45:18 +0000, Bart wrote: >> >>> On 01/01/2024 23:10, Lawrence D'Oliveiro wrote: >>> >>>> You have the answer right in front of your nose: look at the source of >>>> the software itself and figure it out. >>> >>> So you don't know. You choose to believe that it HAS to be done that >>> way. >> >> Out of curiosity, I *did* have a look at the build system for libgmp. The >> “configure” file is over 30,000 lines, but that is generated (via m4 >> macro >> expansion) from a much smaller (and easier to read) “configure.ac” of >> about 4,000 lines. And the contents of the latter file are quite >> interesting. >> >> First of all, it includes code for building on a whole lot of proprietary >> Unix systems with non-GCC compilers, some of which maybe don’t quite >> conform to official C/C++ standards. You would think all those systems >> are >> extinct now, but clearly there are users who still care about them. >> >> And that’s not counting the different ways GMP offers for you to build >> it. >> For example, do you want profiling? Omit procedure call frames? Static or >> shared library? Do you want to build the test programs? (Yes, the project >> includes its own test suite.) Do you want the test programs to use GNU >> readline to get their input? (Sounds like a handy option to me, at least >> you have the choice.) >> >> That is an amazingly long list of CPU architectures on which you can >> build >> it, all the way up to IBM mainframes. And it is in the nature of a >> library >> like this, doing CPU-intensive things, that it will need to take account >> of CPU-specific quirks in order to get maximum efficiency. Hence a whole >> load of special cases, particularly in code generation, for all these >> architectures. > > Yeah, that's usually the job of the compiler, the one that exists on my > machine, and which knows how to generate code for it. > > >> >> Look at the ABI options: maybe you want a 32-bit build (where the CPU >> supports it) rather than a 64-bit one; on some architectures, things >> get a >> bit more complicated than just those two options. >> >> And so on and so on. Feel free to tell us which parts of these you would >> get rid of, without antagonizing users who might depend on them. > > I would have no interest in building it, I wanted a ready-made DLL, for > that little-known niche platform known as 'Windows'. [...] Actually, you might like vcpkg. It builds everything from source code automatically and integrates into MSVC.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2024-01-16 22:21 -0800 |
| Message-ID | <uo7rlp$1sl5o$1@dont-email.me> |
| In reply to | #379770 |
On 1/1/2024 5:14 PM, Bart wrote: [...] If you have a recent version of MSVC installed, give vcpkg a go. It has a lot of packages that will be automagically build and integrated into MSVC: https://vcpkg.io/en/packages
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <433-929-6894@kylheku.com> |
|---|---|
| Date | 2024-01-02 06:23 +0000 |
| Message-ID | <20240101221808.152@kylheku.com> |
| In reply to | #379766 |
On 2024-01-02, Lawrence D'Oliveiro <ldo@nz.invalid> wrote: > On Mon, 1 Jan 2024 23:45:18 +0000, Bart wrote: > >> On 01/01/2024 23:10, Lawrence D'Oliveiro wrote: >> >>> You have the answer right in front of your nose: look at the source of >>> the software itself and figure it out. >> >> So you don't know. You choose to believe that it HAS to be done that >> way. > > Out of curiosity, I *did* have a look at the build system for libgmp. The > “configure” file is over 30,000 lines, but that is generated (via m4 macro > expansion) from a much smaller (and easier to read) “configure.ac” of > about 4,000 lines. And the contents of the latter file are quite > interesting. > > First of all, it includes code for building on a whole lot of proprietary > Unix systems with non-GCC compilers, some of which maybe don’t quite > conform to official C/C++ standards. You would think all those systems are > extinct now, but clearly there are users who still care about them. When people use Autoconf to configure their program for building, the generated script includes cruft for platforms on which they never tested the program, and never will, and on which it won't work for reasons not related to those tests. It is 30,000 lines of mostly garbage code, like "junk DNA" in a genetic code. > Look at the ABI options: maybe you want a 32-bit build (where the CPU > supports it) rather than a 64-bit one; on some architectures, things get a > bit more complicated than just those two options. These kinds of options can be passed in by CFLAGS, LDFLAGS and LDLIBS. Support those three variables, and that's it. Users who come up with some combination of code generation options that you've never tried, on a platform you don't have, are on their own. You can upstream a patch from them to get something working, but they have to test every subsequent release themselves. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-01-02 06:47 +0000 |
| Message-ID | <un0bid$2imhq$2@dont-email.me> |
| In reply to | #379775 |
On Tue, 2 Jan 2024 06:23:03 -0000 (UTC), Kaz Kylheku wrote: > On 2024-01-02, Lawrence D'Oliveiro <ldo@nz.invalid> wrote: > >> First of all, it includes code for building on a whole lot of >> proprietary Unix systems with non-GCC compilers, some of which maybe >> don’t quite conform to official C/C++ standards. > > When people use Autoconf to configure their program for building, the > generated script includes cruft for platforms on which they never tested > the program, and never will, and on which it won't work for reasons not > related to those tests. This is a GNU project, so you can be sure they have done pretty good testing on those platforms and those options. If they were no longer supported, they would have been dropped from the code. This isn’t like proprietary software, which tends to accumulate cruft that nobody dares touch because they no longer understand what it does. >> Look at the ABI options: maybe you want a 32-bit build (where the CPU >> supports it) rather than a 64-bit one; on some architectures, things >> get a bit more complicated than just those two options. > > These kinds of options can be passed in by CFLAGS, LDFLAGS and LDLIBS. > Support those three variables, and that's it. If you have a look, that’s what the script does. Only you just have to specify one option, and it generates the right value for *all* the relevant variables, instead of you having to specify them individually.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.cm> |
|---|---|
| Date | 2024-01-02 12:24 +0000 |
| Message-ID | <un0vad$2mb0b$1@dont-email.me> |
| In reply to | #379776 |
On 02/01/2024 06:47, Lawrence D'Oliveiro wrote:
> On Tue, 2 Jan 2024 06:23:03 -0000 (UTC), Kaz Kylheku wrote:
>
>> On 2024-01-02, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>
>>> First of all, it includes code for building on a whole lot of
>>> proprietary Unix systems with non-GCC compilers, some of which maybe
>>> don’t quite conform to official C/C++ standards.
>>
>> When people use Autoconf to configure their program for building, the
>> generated script includes cruft for platforms on which they never tested
>> the program, and never will, and on which it won't work for reasons not
>> related to those tests.
>
> This is a GNU project, so you can be sure they have done pretty good
> testing on those platforms and those options. If they were no longer
> supported, they would have been dropped from the code. This isn’t like
> proprietary software, which tends to accumulate cruft that nobody dares
> touch because they no longer understand what it does.
>
>>> Look at the ABI options: maybe you want a 32-bit build (where the CPU
>>> supports it) rather than a 64-bit one; on some architectures, things
>>> get a bit more complicated than just those two options.
>>
>> These kinds of options can be passed in by CFLAGS, LDFLAGS and LDLIBS.
>> Support those three variables, and that's it.
>
> If you have a look, that’s what the script does. Only you just have to
> specify one option, and it generates the right value for *all* the
> relevant variables, instead of you having to specify them individually.
You're going to defend this to the death aren't you? Be funny if at some
point some GMP II was produced whose main new benefit was a vastly
simplified build!
I tried to build gmp today using WSL. The process took just under five
minutes. However, where and what is the output? For all the verbosity,
that simple fact is omitted.
By doing searches, I found a bunch of libxxx.a files with today's date
in various locations.
So the outputs are archive files for gcc, I guess intended for static
linking. And full of code using SYS V ABI. But never mind that tiny detail.
The INSTALL file talks about reading detailed instructions in gmp_info,
but this file is gobbledygook. You need to view the instructions using a
program called 'info' - a Linux utility that doesn't exist on Windows.
So I need Linux even just to look at a bunch of instructions?
Anyway, now that some extra files are in place, I had a go trying to
compile some individual files. Here there is another suprise:
c:\gmp2>dir gmp-mparam.h
02/01/2024 11:56 <JUNCTION> gmp-mparam.h [...]
One of the header files it needs is this mysterious 'junction' file. I
can't even see inside it:
c:\gmp2>type gmp-mparam.h
The file cannot be accessed by the system.
WTH? I can do 'cat' in WSL and redirect it to a normal file, but this is
well weird.
The following are the checks reported by ./configure. I can report that
I have gcc installed (on this Linux system), and that it has 'string.h'.
Phew! God knows what would have happened if I'd attempted to build and
string.h was missing.
So, what does it do with that info? What actually happens if string
/was/ missing? What, God forbid, if 'gcc -E' was not supported?
And why aren't these checks everytime you build /any/ program?
Oh, and I apparently don't have Bison or Lex installed. Now /that/ was
worth checking.
What a total waste of time. Even if it was somehow justified, if I then
tried to build another app with its own configure script, it's going to
do all those same checks again, even though nothing as changed.
(If you try and argue that they /might/ have changed, well, they have
changed between running ./configure, and starting 'make'?)
GMP, when it's actually made available, is actually an incredibly fast
library. Some talented people went into creating it. I can't say the
same for those responsible for the build system who seem to have made it
as complicated and convoluted as they possibly can.
=============================================
checking build system type... zen-pc-linux-gnu
checking host system type... zen-pc-linux-gnu
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /usr/bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether to enable maintainer-specific portions of Makefiles... no
checking ABI=64
checking compiler gcc -O2 -pedantic -fomit-frame-pointer -m64 ... yes
checking compiler gcc -O2 -pedantic -fomit-frame-pointer -m64
-mtune=znver1... yes
checking compiler gcc -O2 -pedantic -fomit-frame-pointer -m64
-mtune=znver1 -march=znver1... yes
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether gcc understands -c and -o together... yes
checking for gcc option to accept ISO C99... none needed
checking how to run the C preprocessor... gcc -E
checking build system compiler gcc... yes
checking for build system preprocessor... gcc -E
checking for build system executable suffix...
checking whether build system compiler is ANSI... yes
checking for build system compiler math library... -lm
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
using ABI="64"
CC="gcc"
CFLAGS="-O2 -pedantic -fomit-frame-pointer -m64 -mtune=znver1
-march=znver1"
CPPFLAGS=""
MPN_PATH=" x86_64/zen x86_64 generic"
checking whether assembler supports --noexecstack option... yes
checking for ar... ar
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
checking the name lister (/usr/bin/nm -B) interface... BSD nm
checking how to print strings... printf
checking for a sed that does not truncate output... /usr/bin/sed
checking for fgrep... /usr/bin/grep -F
checking for ld used by gcc... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking whether ln -s works... yes
checking the maximum length of command line arguments... 1572864
checking how to convert zen-pc-linux-gnu file names to zen-pc-linux-gnu
format... func_convert_file_noop
checking how to convert zen-pc-linux-gnu file names to toolchain
format... func_convert_file_noop
checking for /usr/bin/ld option to reload object files... -r
checking for objdump... objdump
checking how to recognize dependent libraries... pass_all
checking for dlltool... dlltool
checking how to associate runtime and link libraries... printf %s\n
checking for archiver @FILE support... @
checking for strip... strip
checking for ranlib... ranlib
checking command to parse /usr/bin/nm -B output from gcc object... ok
checking for sysroot... no
checking for a working dd... /usr/bin/dd
checking how to truncate binary pipes... /usr/bin/dd bs=4096 count=1
checking for mt... mt
checking if mt is a manifest tool... no
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for dlfcn.h... yes
checking for objdir... .libs
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -fPIC -DPIC
checking if gcc PIC flag -fPIC -DPIC works... yes
checking if gcc static flag -static works... yes
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.o... (cached) yes
checking whether the gcc linker (/usr/bin/ld) supports shared
libraries... yes
checking whether -lc should be explicitly linked in... no
checking dynamic linker characteristics... GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
checking for ANSI C header files... (cached) yes
checking whether time.h and sys/time.h may both be included... yes
checking fcntl.h usability... yes
checking fcntl.h presence... yes
checking for fcntl.h... yes
checking float.h usability... yes
checking float.h presence... yes
checking for float.h... yes
checking invent.h usability... no
checking invent.h presence... no
checking for invent.h... no
checking langinfo.h usability... yes
checking langinfo.h presence... yes
checking for langinfo.h... yes
checking locale.h usability... yes
checking locale.h presence... yes
checking for locale.h... yes
checking nl_types.h usability... yes
checking nl_types.h presence... yes
checking for nl_types.h... yes
checking sys/attributes.h usability... no
checking sys/attributes.h presence... no
checking for sys/attributes.h... no
checking sys/iograph.h usability... no
checking sys/iograph.h presence... no
checking for sys/iograph.h... no
checking sys/mman.h usability... yes
checking sys/mman.h presence... yes
checking for sys/mman.h... yes
checking sys/param.h usability... yes
checking sys/param.h presence... yes
checking for sys/param.h... yes
checking sys/processor.h usability... no
checking sys/processor.h presence... no
checking for sys/processor.h... no
checking sys/pstat.h usability... no
checking sys/pstat.h presence... no
checking for sys/pstat.h... no
checking sys/sysinfo.h usability... yes
checking sys/sysinfo.h presence... yes
checking for sys/sysinfo.h... yes
checking sys/syssgi.h usability... no
checking sys/syssgi.h presence... no
checking for sys/syssgi.h... no
checking sys/systemcfg.h usability... no
checking sys/systemcfg.h presence... no
checking for sys/systemcfg.h... no
checking sys/time.h usability... yes
checking sys/time.h presence... yes
checking for sys/time.h... yes
checking sys/times.h usability... yes
checking sys/times.h presence... yes
checking for sys/times.h... yes
checking for sys/resource.h... yes
checking for sys/sysctl.h... yes
checking for machine/hal_sysinfo.h... no
checking whether fgetc is declared... yes
checking whether fscanf is declared... yes
checking whether optarg is declared... yes
checking whether ungetc is declared... yes
checking whether vfprintf is declared... yes
checking whether sys_errlist is declared... yes
checking whether sys_nerr is declared... yes
checking return type of signal handlers... void
checking for intmax_t... yes
checking for long double... yes
checking for long long... yes
checking for ptrdiff_t... yes
checking for quad_t... yes
checking for uint_least32_t... yes
checking for intptr_t... yes
checking for working volatile... yes
checking for C/C++ restrict keyword... __restrict
checking whether gcc __attribute__ ((const)) works... yes
checking whether gcc __attribute__ ((malloc)) works... yes
checking whether gcc __attribute__ ((mode (XX))) works... yes
checking whether gcc __attribute__ ((noreturn)) works... yes
checking whether gcc hidden aliases work... yes
checking for inline... inline
checking for cos in -lm... yes
checking for working alloca.h... yes
checking for alloca (via gmp-impl.h)... yes
checking how to allocate temporary memory... alloca
checking whether byte ordering is bigendian... no
checking format of `double' floating point... IEEE little endian
checking for alarm... yes
checking for attr_get... no
checking for clock... yes
checking for cputime... no
checking for getpagesize... yes
checking for getrusage... yes
checking for gettimeofday... yes
checking for getsysinfo... no
checking for localeconv... yes
checking for memset... yes
checking for mmap... yes
checking for mprotect... yes
checking for nl_langinfo... yes
checking for obstack_vprintf... yes
checking for popen... yes
checking for processor_info... no
checking for pstat_getprocessor... no
checking for raise... yes
checking for read_real_time... no
checking for sigaction... yes
checking for sigaltstack... yes
checking for sigstack... yes
checking for syssgi... no
checking for strchr... yes
checking for strerror... yes
checking for strnlen... yes
checking for strtol... yes
checking for strtoul... yes
checking for sysconf... yes
checking for sysctl... yes
checking for sysctlbyname... no
checking for times... yes
checking for library containing clock_gettime... none required
checking for vsnprintf... yes
checking whether vsnprintf works... yes
checking whether sscanf needs writable input... no
checking for struct pst_processor.psp_iticksperclktick... no
checking for suitable m4... m4
checking if m4wrap produces spurious output... no
checking how to switch to text section... .text
checking how to switch to data section... .data
checking for assembler label suffix... :
checking for assembler global directive... .globl
checking for assembler global directive attribute...
checking if globals are prefixed by underscore... no
checking how to switch to read-only data section... .section .rodata
checking for assembler .type directive... .type $1,@$2
checking for assembler .size directive... .size $1,$2
checking for assembler local label prefix... .L
checking for assembler byte directive... .byte
checking how to define a 32-bit word... .long
checking if .align assembly directive is logarithmic... no
checking if the .align directive accepts an 0x90 fill in .text... yes
checking if the assembler knows about the mulx instruction... yes
checking for assembler COFF type directives... no
checking size of void *... 8
checking size of unsigned short... 2
checking size of unsigned... 4
checking size of unsigned long... 8
checking size of mp_limb_t... 8
checking for stack_t... yes
checking for tputs in -lncurses... yes
checking for readline in -lreadline... yes
checking readline/readline.h usability... yes
checking readline/readline.h presence... yes
checking for readline/readline.h... yes
checking readline/history.h usability... yes
checking readline/history.h presence... yes
checking for readline/history.h... yes
checking readline detected... yes
checking for bison... no
checking for byacc... no
checking for flex... no
checking for lex... no
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-01-02 19:04 +0000 |
| Message-ID | <un1mnf$2q36g$2@dont-email.me> |
| In reply to | #379779 |
On Tue, 2 Jan 2024 12:24:45 +0000, Bart wrote: > You're going to defend this to the death aren't you? Be funny if at some > point some GMP II was produced whose main new benefit was a vastly > simplified build! Well, you can go back to dreaming if you wish. It’s not like this project was just created yesterday: if it was going to pay more serious attention to Microsoft Windows, it would have done so already. Clearly the need isn’t there. > By doing searches, I found a bunch of libxxx.a files with today's date > in various locations. I would say you forgot to do the “make install” bit. That would put the build products in some sensible place, like /usr/local. > So the outputs are archive files for gcc, I guess intended for static > linking. As I mentioned, the build script has options for both static and dynamic builds. Maybe you chose the wrong one. Tip: try “./configure --help” for a quick summary of the build options. > The INSTALL file talks about reading detailed instructions in gmp_info, > but this file is gobbledygook. You need to view the instructions using a > program called 'info' - a Linux utility that doesn't exist on Windows. Again, that’s the fault of Windows for being such a poverty-stricken OS. Remember, Windows is designed as a platform on which users will not do their own programming, but instead they will buy programs from software vendor organizations. All the tooling is centred around that, and is built on the assumption that Microsoft will provide the core development tools. > So I need Linux even just to look at a bunch of instructions? You need Linux to do any kind of serious open-source or cross-platform development work, yes. > What, God forbid, if 'gcc -E' was not supported? What, indeed. I _did_ mention, did I not, that this project has a lot of support for obsolete, proprietary Unix systems with their own peculiar quirks. Certainly enough users must still care about those for this support for them to be retained in the project. Yet there are not enough of these complaining Windows users (or should I say “sufferers”) for them to be catered to. > And why aren't these checks everytime you build /any/ program? Different projects have different requirements. GNU autoconf has a whole standard library of things to check for (and configure your build for), and you can add new ones by writing suitable m4 definitions. Here, you can read about it yourself: <https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.71/ autoconf.html>. > What a total waste of time. A good description of Microsoft Windows generally. That’s why those of us who want to be productive tend to avoid it. > GMP, when it's actually made available, is actually an incredibly fast > library. Some talented people went into creating it. I can't say the > same for those responsible for the build system who seem to have made it > as complicated and convoluted as they possibly can. You yourself said, it only took 5 minutes to build--on Linux. As the Dilbert cartoon goes: “Here’s a nickel, kid. Get yourself a *real* computer.”
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2024-01-02 20:11 +0000 |
| Message-ID | <P5_kN.132634$83n7.128785@fx18.iad> |
| In reply to | #379779 |
Bart <bc@freeuk.cm> writes: >On 02/01/2024 06:47, Lawrence D'Oliveiro wrote: >> On Tue, 2 Jan 2024 06:23:03 -0000 (UTC), Kaz Kylheku wrote: >> >>> On 2024-01-02, Lawrence D'Oliveiro <ldo@nz.invalid> wrote: >>> >>>> First of all, it includes code for building on a whole lot of >>>> proprietary Unix systems with non-GCC compilers, some of which maybe >>>> don’t quite conform to official C/C++ standards. >>> >>> When people use Autoconf to configure their program for building, the >>> generated script includes cruft for platforms on which they never tested >>> the program, and never will, and on which it won't work for reasons not >>> related to those tests. >> >> This is a GNU project, so you can be sure they have done pretty good >> testing on those platforms and those options. If they were no longer >> supported, they would have been dropped from the code. This isn’t like >> proprietary software, which tends to accumulate cruft that nobody dares >> touch because they no longer understand what it does. >> >>>> Look at the ABI options: maybe you want a 32-bit build (where the CPU >>>> supports it) rather than a 64-bit one; on some architectures, things >>>> get a bit more complicated than just those two options. >>> >>> These kinds of options can be passed in by CFLAGS, LDFLAGS and LDLIBS. >>> Support those three variables, and that's it. >> >> If you have a look, that’s what the script does. Only you just have to >> specify one option, and it generates the right value for *all* the >> relevant variables, instead of you having to specify them individually. > > >You're going to defend this to the death aren't you? Be funny if at some >point some GMP II was produced whose main new benefit was a vastly >simplified build! You still haven't provided a better system that accomplishes everthing the existing system does. Quit bitching about it and _do_ something about it. It's an open source system, you are free to contribute a new build system for it (which clearly needs to support all the capabilities of the existing system otherwise you'll never have your suggestions accepted). Don't, however, expect anyone to cater to you. > >I tried to build gmp today using WSL. The process took just under five >minutes. However, where and what is the output? For all the verbosity, >that simple fact is omitted. You presumably specified that on the ./configure with the --prefix option. Or did you forget to RTFM first?
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.cm> |
|---|---|
| Date | 2024-01-02 20:43 +0000 |
| Message-ID | <un1shc$2r3ab$1@dont-email.me> |
| In reply to | #379793 |
On 02/01/2024 20:11, Scott Lurndal wrote:
> Bart <bc@freeuk.cm> writes:
>> You're going to defend this to the death aren't you? Be funny if at some
>> point some GMP II was produced whose main new benefit was a vastly
>> simplified build!
>
> You still haven't provided a better system that accomplishes
> everthing the existing system does.
I need some basic information about what's what about in the 26MB of
content in 4000 files spread over 190 directories.
But it's clear that it's not interested in making things simple. (The
nearest they've come is with the 'mini-gmp' version. But since the
performance of that is on a par with my own library, I'll stick with
mine, which also has a higher spec.)
I have done this exercise with projects like LIBJPEG, LUA5.4 and
TCC0.9.27. Long ago I did it with SEED7.
Once I can extract the necessary info - IT ALWAYS COMES DOWN TO A LIST
OF FILES TO SUBMIT TO A COMPILER FGS - then I can whizz through it easily.
> Quit bitching about it and _do_ something about it.
Funnily enough, I did. I wrote my own library, which I know is always
available, and has some unique features, eg. it uses decimal, and has a
single integer/float type.
I once linked to a C port of it.
It's not fast, but it's mine and it's in my language. (It accounts for
12KB of my interpreter.)
> It's an open
> source system, you are free to contribute a new build system for
> it (which clearly needs to support all the capabilities of the
> existing system otherwise you'll never have your suggestions
> accepted).
>
> Don't, however, expect anyone to cater to you.
There must be one person on the planet who understands how to produce a
Windows DLL of this thing. And funnily enough, a single 64-bit DLL is
all any Windows user on the planet needs (that and either gmp.h or
language-neutral docs).
>>
>> I tried to build gmp today using WSL. The process took just under five
>> minutes. However, where and what is the output? For all the verbosity,
>> that simple fact is omitted.
>
> You presumably specified that on the ./configure with the --prefix
> option. Or did you forget to RTFM first?
I following these instructions:
--------------
Here are some brief instructions on how to install GMP. First you need to
compile. Since you're impatient, try this
./configure
make
make check <= VERY IMPORTANT!!
I did the first two line before looking for the binaries.
[toc] | [prev] | [next] | [standalone]
Page 32 of 34 — ← Prev page 1 … 30 31 [32] 33 34 Next page →
Back to top | Article view | comp.lang.c
csiph-web