Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #170696 > unrolled thread
| Started by | fir <profesor.fir@gmail.com> |
|---|---|
| First post | 2023-07-12 07:18 -0700 |
| Last post | 2023-07-23 03:32 -0700 |
| Articles | 20 on this page of 968 — 32 participants |
Back to article view | Back to comp.lang.c
you think rust may outthrone c? fir <profesor.fir@gmail.com> - 2023-07-12 07:18 -0700
Re: you think rust may outthrone c? Blue-Maned_Hawk <bluemanedhawk@gmail.com> - 2023-07-13 01:37 -0400
Re: you think rust may outthrone c? jak <nospam@please.ty> - 2023-07-13 10:16 +0200
Re: you think rust may outthrone c? fir <profesor.fir@gmail.com> - 2023-07-13 04:27 -0700
Re: you think rust may outthrone c? fir <profesor.fir@gmail.com> - 2023-07-13 05:01 -0700
Re: you think rust may outthrone c? rek2 hispagatos <rek2@hispagatos.org.invalid> - 2023-07-13 14:10 +0000
Re: you think rust may outthrone c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-07-13 17:51 +0000
Re: you think rust may outthrone c? kalevi@kolttonen.fi (Kalevi Kolttonen) - 2023-07-13 18:56 +0000
Re: you think rust may outthrone c? scott@slp53.sl.home (Scott Lurndal) - 2023-07-13 19:39 +0000
Re: you think rust may outthrone c? kalevi@kolttonen.fi (Kalevi Kolttonen) - 2023-07-13 20:30 +0000
Re: you think rust may outthrone c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-07-13 22:29 +0000
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-07-14 00:19 +0100
Re: you think rust may outthrone c? kalevi@kolttonen.fi (Kalevi Kolttonen) - 2023-07-14 06:43 +0000
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-07-14 11:47 +0100
Re: you think rust may outthrone c? kalevi@kolttonen.fi (Kalevi Kolttonen) - 2023-07-14 11:04 +0000
Re: you think rust may outthrone c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-07-14 21:01 +0000
Re: you think rust may outthrone c? kalevi@kolttonen.fi (Kalevi Kolttonen) - 2023-07-14 21:21 +0000
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-14 13:52 +0200
Re: you think rust may outthrone c? kalevi@kolttonen.fi (Kalevi Kolttonen) - 2023-07-14 12:08 +0000
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-14 17:10 +0200
Re: you think rust may outthrone c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-07-14 21:32 +0000
Re: you think rust may outthrone c? kalevi@kolttonen.fi (Kalevi Kolttonen) - 2023-07-14 22:04 +0000
Re: you think rust may outthrone c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-07-14 21:02 +0000
Re: you think rust may outthrone c? kalevi@kolttonen.fi (Kalevi Kolttonen) - 2023-07-14 21:35 +0000
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-15 14:30 +0200
Re: you think rust may outthrone c? scott@slp53.sl.home (Scott Lurndal) - 2023-07-15 16:36 +0000
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-07-15 15:49 -0700
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-07-15 16:02 -0700
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-16 01:18 +0200
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-07-15 16:25 -0700
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-16 11:07 +0200
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-07-16 05:42 -0700
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-16 16:17 +0200
Re: you think rust may outthrone c? fir <profesor.fir@gmail.com> - 2023-07-16 07:44 -0700
Re: you think rust may outthrone c? fir <profesor.fir@gmail.com> - 2023-07-16 09:57 -0700
Re: you think rust may outthrone c? fir <profesor.fir@gmail.com> - 2023-07-16 10:34 -0700
Re: you think rust may outthrone c? fir <profesor.fir@gmail.com> - 2023-07-16 10:41 -0700
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-07-16 20:55 +0100
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-07-17 01:54 +0100
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-07-17 02:43 +0100
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-07-17 03:16 -0700
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-17 14:54 +0200
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-07-17 07:08 -0700
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-17 16:43 +0200
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-07-17 17:19 +0100
Re: you think rust may outthrone c? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-07-21 00:05 -0700
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-07-21 16:52 +0100
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-07-17 17:21 +0100
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-07-17 09:44 -0700
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-17 21:24 +0200
Re: you think rust may outthrone c? scott@slp53.sl.home (Scott Lurndal) - 2023-07-17 15:10 +0000
Re: you think rust may outthrone c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-07-17 18:46 +0000
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-17 21:27 +0200
Re: you think rust may outthrone c? jak <nospam@please.ty> - 2023-07-20 20:40 +0200
Re: you think rust may outthrone c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-07-20 19:27 +0000
Re: you think rust may outthrone c? jak <nospam@please.ty> - 2023-07-20 22:16 +0200
Re: you think rust may outthrone c? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-07-20 19:17 -0700
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-07-17 16:15 +0100
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-07-17 09:17 -0700
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-17 21:41 +0200
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-07-17 23:02 +0100
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-17 08:22 +0200
Re: you think rust may outthrone c? fir <profesor.fir@gmail.com> - 2023-07-17 15:01 -0700
Re: you think rust may outthrone c? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-07-17 15:01 -0700
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-18 09:26 +0200
Re: you think rust may outthrone c? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-07-18 00:33 -0700
Re: you think rust may outthrone c? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-07-18 00:35 -0700
Re: you think rust may outthrone c? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-07-18 00:37 -0700
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-07-18 13:05 +0100
Re: you think rust may outthrone c? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-07-19 17:56 -0700
Re: you think rust may outthrone c? fir <profesor.fir@gmail.com> - 2023-07-18 09:13 -0700
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-07-18 12:18 +0100
Re: you think rust may outthrone c? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-07-18 01:24 -0700
Re: you think rust may outthrone c? fir <profesor.fir@gmail.com> - 2023-07-17 15:06 -0700
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-07-17 23:11 +0100
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-07-17 15:30 -0700
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-07-18 00:07 +0100
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-07-18 01:28 +0100
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-07-18 02:20 +0100
Re: you think rust may outthrone c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-07-18 02:12 +0000
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-07-18 03:25 +0100
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-18 09:55 +0200
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-07-18 12:29 +0100
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-07-19 02:29 +0100
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-19 09:16 +0200
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-07-19 12:38 +0100
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-19 14:24 +0200
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-07-19 14:12 +0100
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-19 16:33 +0200
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-07-19 16:37 +0100
Re: you think rust may outthrone c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-07-19 16:55 +0000
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-07-19 19:44 +0100
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-07-18 12:06 +0100
Re: you think rust may outthrone c? Ike Naar <ike@sdf.org> - 2023-07-18 12:16 +0000
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-07-18 14:09 +0100
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-18 16:36 +0200
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-07-18 17:59 +0100
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-19 09:45 +0200
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-07-19 03:31 +0100
Re: you think rust may outthrone c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-07-19 06:01 +0000
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-07-19 01:19 -0700
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-07-19 03:02 -0700
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-07-19 04:30 -0700
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-19 15:28 +0200
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-07-19 15:12 -0700
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-07-19 15:23 -0700
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-20 10:44 +0200
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-07-20 15:37 -0700
Re: you think rust may outthrone c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-07-19 23:01 +0000
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-07-19 16:43 -0700
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-20 10:41 +0200
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-07-21 00:24 +0100
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-07-20 16:58 -0700
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-07-20 17:30 -0700
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-07-20 17:50 -0700
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-07-20 22:46 -0700
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-21 09:57 +0200
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-07-21 02:24 -0700
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-21 13:33 +0200
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-07-21 02:01 +0100
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-07-20 18:28 -0700
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-07-21 11:21 +0100
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-07-21 03:44 -0700
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-07-21 12:17 +0100
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-21 15:05 +0200
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-07-21 14:42 +0100
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-21 16:22 +0200
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-07-21 16:40 +0100
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-21 18:56 +0200
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-07-21 20:26 +0100
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-07-21 21:06 +0100
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-22 18:34 +0200
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-07-22 20:09 +0100
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-07-21 14:34 -0700
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-07-21 23:03 +0100
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-07-21 15:30 -0700
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-07-21 21:49 -0700
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-07-22 11:41 +0100
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-07-22 04:15 -0700
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-07-22 15:51 -0700
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-22 19:05 +0200
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-07-23 00:22 +0100
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-07-22 16:38 -0700
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-07-23 01:15 +0100
Re: you think rust may outthrone c? scott@slp53.sl.home (Scott Lurndal) - 2023-07-23 13:45 +0000
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-07-23 15:06 +0100
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-23 17:54 +0200
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-07-23 17:56 +0100
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-07-23 11:03 -0700
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-23 20:15 +0200
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-07-23 20:18 +0100
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-24 09:50 +0200
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-07-24 10:58 +0100
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-07-24 06:02 -0700
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-07-24 14:08 +0100
Re: you think rust may outthrone c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-07-24 18:42 +0000
Re: you think rust may outthrone c? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-08-05 10:22 -0700
Re: you think rust may outthrone c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-05 18:02 +0000
Re: you think rust may outthrone c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-05 18:32 +0000
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-05 20:00 +0100
Re: you think rust may outthrone c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-06 01:42 +0000
Re: you think rust may outthrone c? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-08-14 04:54 -0700
Re: you think rust may outthrone c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-14 18:22 +0000
Re: you think rust may outthrone c? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-07-25 19:44 -0700
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-07-25 21:09 -0700
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-07-26 00:21 -0700
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-07-26 11:17 +0100
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-07-26 03:31 -0700
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-07-26 16:52 -0700
Re: you think rust may outthrone c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-07-27 00:47 +0000
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-07-26 21:19 +0100
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-07-26 20:21 -0700
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-07-26 21:49 -0700
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-07-27 02:04 -0700
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-07-27 02:42 -0700
Re: you think rust may outthrone c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-07-27 17:36 +0000
Re: you think rust may outthrone c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-07-27 05:50 +0000
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-07-27 20:03 +0100
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-07-26 11:04 +0100
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-07-26 03:34 -0700
Re: you think rust may outthrone c? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-08-12 10:57 -0700
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-12 16:37 -0700
Re: you think rust may outthrone c? Spiros Bousbouras <spibou@gmail.com> - 2023-08-13 08:16 +0000
Re: you think rust may outthrone c? scott@slp53.sl.home (Scott Lurndal) - 2023-08-13 15:48 +0000
Re: you think rust may outthrone c? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-08-15 13:05 -0700
Re: you think rust may outthrone c? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-08-15 14:20 -0700
Re: you think rust may outthrone c? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-07-25 20:08 -0700
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-24 20:19 +0200
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-21 14:52 +0200
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-07-21 16:14 +0100
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-07-21 12:52 -0700
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-22 18:29 +0200
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-07-22 21:56 +0100
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-07-22 16:11 -0700
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-07-23 00:45 +0100
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-23 17:24 +0200
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-07-23 17:28 +0100
Re: you think rust may outthrone c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-07-23 16:45 +0000
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-24 10:04 +0200
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-24 07:43 +0200
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-07-23 22:10 +0100
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-07-23 14:51 -0700
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-07-23 23:12 +0100
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-07-23 15:19 -0700
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-24 20:25 +0200
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-07-24 17:22 +0100
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-07-24 09:52 -0700
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-07-25 02:52 +0100
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-24 17:37 +0200
Re: you think rust may outthrone c? scott@slp53.sl.home (Scott Lurndal) - 2023-07-24 16:19 +0000
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-24 20:34 +0200
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-07-25 02:42 +0100
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-25 10:36 +0200
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-07-25 16:41 +0100
Re: you think rust may outthrone c? scott@slp53.sl.home (Scott Lurndal) - 2023-07-25 16:22 +0000
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-07-25 17:40 +0100
Re: you think rust may outthrone c? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-07-26 02:40 -0700
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-07-26 11:30 +0100
Re: you think rust may outthrone c? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-07-26 06:41 -0700
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-07-27 01:06 +0100
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-07-27 01:55 +0100
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-07-26 18:03 -0700
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-07-27 03:17 +0100
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-07-27 11:50 +0100
Re: you think rust may outthrone c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-07-27 02:50 +0000
Overflow and undefined behaviour (WAS: you think rust may outthrone c?) Spiros Bousbouras <spibou@gmail.com> - 2023-07-25 16:43 +0000
Re: Overflow and undefined behaviour (WAS: you think rust may outthrone c?) Bonita Montero <Bonita.Montero@gmail.com> - 2023-07-25 19:15 +0200
Re: Overflow and undefined behaviour (WAS: you think rust may outthrone c?) Bart <bc@freeuk.com> - 2023-07-25 18:43 +0100
Re: Overflow and undefined behaviour Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-07-25 15:03 -0700
Re: Overflow and undefined behaviour Spiros Bousbouras <spibou@gmail.com> - 2023-07-26 04:10 +0000
Re: Overflow and undefined behaviour Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-07-25 21:51 -0700
Re: Overflow and undefined behaviour Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-07-26 22:07 +0100
Re: Overflow and undefined behaviour Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-07-26 21:55 +0100
Re: Overflow and undefined behaviour Bart <bc@freeuk.com> - 2023-07-26 22:26 +0100
Re: Overflow and undefined behaviour Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-07-26 17:26 -0700
Re: Overflow and undefined behaviour Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-07-27 01:38 +0100
Re: Overflow and undefined behaviour Phil Carmody <pc+usenet@asdf.org> - 2023-08-13 14:53 +0300
Re: Overflow and undefined behaviour Bart <bc@freeuk.com> - 2023-08-13 13:07 +0100
What's wrong? The phrasing, that's what! (Was: Overflow and undefined behaviour) gazelle@shell.xmission.com (Kenny McCormack) - 2023-08-13 13:16 +0000
Re: Overflow and undefined behaviour Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-13 16:25 +0100
Re: Overflow and undefined behaviour Phil Carmody <pc+usenet@asdf.org> - 2023-08-14 12:10 +0300
Re: Overflow and undefined behaviour Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-08-14 04:33 -0700
Re: Overflow and undefined behaviour Phil Carmody <pc+usenet@asdf.org> - 2023-08-14 14:56 +0300
Re: you think rust may outthrone c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-07-25 17:34 +0000
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-25 20:55 +0200
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-07-28 02:46 +0100
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-07-25 15:53 -0700
Re: you think rust may outthrone c? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-07-24 22:33 -0700
Re: you think rust may outthrone c? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-07-24 09:45 -0700
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-07-24 14:29 -0700
Re: you think rust may outthrone c? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-07-26 07:03 -0700
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-07-26 07:41 -0700
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-07-26 16:01 +0100
Re: you think rust may outthrone c? scott@slp53.sl.home (Scott Lurndal) - 2023-07-26 15:21 +0000
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-07-26 19:13 +0100
Re: you think rust may outthrone c? scott@slp53.sl.home (Scott Lurndal) - 2023-07-26 18:41 +0000
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-07-26 22:07 +0100
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-27 13:34 +0200
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-07-27 05:15 -0700
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-27 15:14 +0200
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-07-27 06:31 -0700
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-27 16:17 +0200
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-07-27 07:53 -0700
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-07-27 20:45 +0100
Re: you think rust may outthrone c? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-08-04 00:21 -0700
Re: you think rust may outthrone c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-04 18:29 +0000
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-04 11:35 -0700
Re: you think rust may outthrone c? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-08-05 06:09 -0700
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-07-27 14:30 +0100
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-27 16:48 +0200
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-07-27 17:18 +0100
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-07-27 09:45 -0700
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-07-27 19:18 +0100
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-08-01 18:10 +0200
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-08-01 15:00 +0200
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-01 15:41 +0100
Re: you think rust may outthrone c? scott@slp53.sl.home (Scott Lurndal) - 2023-08-01 16:16 +0000
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-01 17:50 +0100
Re: you think rust may outthrone c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-01 17:04 +0000
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-01 18:25 +0100
Re: you think rust may outthrone c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-01 18:26 +0000
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-08-01 19:18 +0200
Re: you think rust may outthrone c? scott@slp53.sl.home (Scott Lurndal) - 2023-08-01 17:41 +0000
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-01 21:01 +0100
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-02 03:41 -0700
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-02 12:09 +0100
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-02 05:01 -0700
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-02 17:04 +0100
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-02 09:10 -0700
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-08-02 23:48 +0200
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-02 15:25 -0700
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-08-03 11:42 +0200
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-04 02:15 -0700
Re: you think rust may outthrone c? Spiros Bousbouras <spibou@gmail.com> - 2023-08-04 14:20 +0000
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-08-04 17:12 +0200
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-04 08:20 -0700
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-08-04 18:04 +0200
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-04 09:17 -0700
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-08-05 13:39 +0200
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-05 05:08 -0700
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-08-08 17:18 +0200
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-08 16:35 +0100
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-08 09:04 -0700
Re: you think rust may outthrone c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-08 16:41 +0000
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-08-08 18:46 +0200
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-08 10:04 -0700
Re: you think rust may outthrone c? scott@slp53.sl.home (Scott Lurndal) - 2023-08-08 17:53 +0000
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-08-09 10:41 +0200
Re: you think rust may outthrone c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-08 18:55 +0000
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-08-09 00:26 +0200
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-08 16:51 -0700
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-08 20:23 -0700
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-08-09 13:42 +0200
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-09 05:32 -0700
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-08-15 13:00 +0200
Re: you think rust may outthrone c? Michael S <already5chosen@yahoo.com> - 2023-08-09 05:35 -0700
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-09 05:48 -0700
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-09 14:17 +0100
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-08-15 13:06 +0200
Re: you think rust may outthrone c? scott@slp53.sl.home (Scott Lurndal) - 2023-08-09 13:44 +0000
Re: you think rust may outthrone c? doctor@doctor.nl2k.ab.ca (The Doctor) - 2023-08-09 14:00 +0000
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-09 15:09 +0100
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-09 07:15 -0700
Re: you think rust may outthrone c? scott@slp53.sl.home (Scott Lurndal) - 2023-08-09 15:48 +0000
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-09 08:54 -0700
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-09 15:18 +0100
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-09 16:01 +0100
Re: you think rust may outthrone c? scott@slp53.sl.home (Scott Lurndal) - 2023-08-09 15:50 +0000
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-09 17:51 +0100
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-09 21:51 +0100
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-08-15 13:16 +0200
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-09 09:18 -0700
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-10 00:05 +0100
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-08 19:10 +0100
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-08 16:24 -0700
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-08-09 14:24 +0200
Re: you think rust may outthrone c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-09 17:18 +0000
Re: you think rust may outthrone c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-09 17:38 +0000
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-08-15 13:35 +0200
Re: you think rust may outthrone c? Phil Carmody <pc+usenet@asdf.org> - 2023-08-15 17:51 +0300
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-08-15 17:18 +0200
Re: you think rust may outthrone c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-15 16:01 +0000
Re: you think rust may outthrone c? Phil Carmody <pc+usenet@asdf.org> - 2023-08-15 23:11 +0300
Re: you think rust may outthrone c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-15 15:48 +0000
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-08-02 23:40 +0200
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-08-02 17:58 +0200
Re: you think rust may outthrone c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-02 19:07 +0000
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-02 22:13 +0100
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-03 02:07 +0100
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-03 02:34 +0100
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-03 11:39 +0100
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-03 15:10 +0100
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-03 17:37 +0100
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-03 18:56 +0100
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-05 23:11 +0100
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-06 00:21 +0100
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-06 00:54 +0100
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-06 11:18 +0100
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-06 17:06 +0100
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-06 17:22 +0100
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-06 14:40 -0700
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-06 23:04 +0100
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-06 15:19 -0700
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-06 23:33 +0100
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-06 17:20 -0700
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-07 01:52 +0100
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-06 18:12 -0700
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-07 10:35 +0100
Re: you think rust may outthrone c? Richard Damon <Richard@Damon-Family.org> - 2023-08-07 07:41 -0400
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-07 04:53 -0700
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-07 14:15 +0100
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-07 16:13 +0100
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-07 08:40 -0700
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-07 17:05 +0100
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-07 09:43 -0700
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-08 00:51 +0100
Making accountants cross (wa Re: you think rust may outthrone c?) Vir Campestris <vir.campestris@invalid.invalid> - 2023-08-10 15:38 +0100
Re: Making accountants cross (wa Re: you think rust may outthrone c?) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-10 16:26 +0100
Re: Making accountants cross (wa Re: you think rust may outthrone c?) Bart <bc@freeuk.com> - 2023-08-10 16:35 +0100
Re: Making accountants cross (wa Re: you think rust may outthrone c?) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-10 16:31 +0000
Re: Making accountants cross (wa Re: you think rust may outthrone c?) Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2023-08-10 16:59 +0000
Re: Making accountants cross (wa Re: you think rust may outthrone c?) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-08-10 11:13 -0700
Re: Making accountants cross (wa Re: you think rust may outthrone c?) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-10 18:26 +0000
Re: Making accountants cross (wa Re: you think rust may outthrone c?) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-08-10 11:30 -0700
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-08-08 17:39 +0200
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-07 18:35 +0100
Re: you think rust may outthrone c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-07 21:51 +0000
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-07 23:53 +0100
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-08 01:28 +0100
Re: you think rust may outthrone c? Richard Damon <Richard@Damon-Family.org> - 2023-08-07 22:21 -0400
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-08 12:05 +0100
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-08 04:13 -0700
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-08 15:04 -0700
Re: you think rust may outthrone c? Richard Damon <Richard@Damon-Family.org> - 2023-08-08 08:22 -0400
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-08 15:16 +0100
Re: you think rust may outthrone c? Michael S <already5chosen@yahoo.com> - 2023-08-08 09:15 -0700
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-08 18:33 +0100
Re: you think rust may outthrone c? Richard Damon <Richard@Damon-Family.org> - 2023-08-08 21:58 -0400
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-09 11:05 +0100
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-09 11:53 +0100
Re: you think rust may outthrone c? Michael S <already5chosen@yahoo.com> - 2023-08-09 05:10 -0700
Re: you think rust may *DE*throne c? scott@slp53.sl.home (Scott Lurndal) - 2023-08-08 13:57 +0000
Re: you think rust may outthrone c? Michael S <already5chosen@yahoo.com> - 2023-08-08 08:55 -0700
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-08 18:23 +0100
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-08 15:28 -0700
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-07 15:17 -0700
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-08 01:08 +0100
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-07 18:31 -0700
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-08 00:43 +0100
Re: you think rust may outthrone c? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-08-08 06:20 -0700
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-08 15:56 +0100
Re: you think rust may outthrone c? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-08-08 08:35 -0700
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-09 02:44 +0100
Re: you think rust may outthrone c? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-08-09 05:53 -0700
Re: you think rust may outthrone c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-07 16:20 +0000
Re: you think rust may outthrone c? James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-08-07 13:10 -0400
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-07 10:24 -0700
Re: you think rust may outthrone c? Richard Damon <Richard@Damon-Family.org> - 2023-08-07 22:46 -0400
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-07 14:52 -0700
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-08 01:01 +0100
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-07 17:59 -0700
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-08 11:34 +0100
Re: you think rust may outthrone c? Richard Damon <Richard@Damon-Family.org> - 2023-08-08 08:34 -0400
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-08 14:51 -0700
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-08 23:19 +0100
Re: you think rust may outthrone c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-08 22:58 +0000
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-09 00:33 +0100
Re: you think rust may outthrone c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-08 23:50 +0000
Re: you think rust may outthrone c? Michael S <already5chosen@yahoo.com> - 2023-08-09 04:07 -0700
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-03 14:08 -0700
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-03 17:09 +0100
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-02 18:39 -0700
Re: you think rust may outthrone c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-03 02:12 +0000
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-02 20:08 -0700
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-08-03 23:42 +0200
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-03 15:44 -0700
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-08-04 07:44 +0200
Re: you think rust may outthrone c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-04 07:14 +0000
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-08-04 17:14 +0200
Re: you think rust may outthrone c? scott@slp53.sl.home (Scott Lurndal) - 2023-08-04 13:56 +0000
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-04 15:25 +0100
Re: you think rust may outthrone c? Richard Damon <Richard@Damon-Family.org> - 2023-08-04 17:05 -0400
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-04 22:32 +0100
Re: you think rust may outthrone c? Richard Damon <Richard@Damon-Family.org> - 2023-08-04 17:46 -0400
Re: you think rust may outthrone c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-04 21:47 +0000
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-05 00:43 +0100
Re: you think rust may outthrone c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-05 00:15 +0000
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-05 01:33 +0100
Re: you think rust may outthrone c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-05 02:11 +0000
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-05 11:00 +0100
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-08-06 16:50 +0200
Re: you think rust may outthrone c? Richard Damon <Richard@Damon-Family.org> - 2023-08-06 18:40 -0400
Re: you think rust may outthrone c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-07 00:31 +0000
Re: you think rust may outthrone c? Richard Damon <Richard@Damon-Family.org> - 2023-08-04 22:44 -0400
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-05 10:46 +0100
Re: you think rust may outthrone c? Richard Damon <Richard@Damon-Family.org> - 2023-08-06 07:53 -0400
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-08-07 11:53 +0200
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-08-06 16:43 +0200
Re: you think rust may outthrone c? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-08-04 19:50 -0700
Re: you think rust may outthrone c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-05 02:58 +0000
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-05 14:17 +0100
Re: you think rust may outthrone c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-05 17:38 +0000
Re: you think rust may outthrone c? Richard Damon <Richard@Damon-Family.org> - 2023-08-06 07:56 -0400
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-06 13:38 +0100
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-08-07 14:12 +0200
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-07 16:03 +0100
Re: you think rust may outthrone c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-07 16:24 +0000
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-07 17:54 +0100
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-08-07 14:16 +0200
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-07 05:45 -0700
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-07 22:17 +0100
Re: you think rust may outthrone c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-07 22:19 +0000
Re: you think rust may outthrone c? Richard Damon <Richard@Damon-Family.org> - 2023-08-07 22:40 -0400
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-08-08 18:07 +0200
Re: you think rust may outthrone c? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-08-08 05:53 -0700
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-08 15:31 +0100
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-08-08 18:17 +0200
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-08 09:31 -0700
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-08-09 22:27 +0200
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-09 18:49 -0700
Re: you think rust may outthrone c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-08 16:39 +0000
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-04 00:37 +0100
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-04 18:07 +0100
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-04 10:32 -0700
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-04 19:36 +0100
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-04 11:53 -0700
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-08-08 12:57 +0200
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-08-08 12:32 +0200
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-08 03:59 -0700
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-08 12:19 +0100
Re: you think rust may outthrone c? Richard Damon <Richard@Damon-Family.org> - 2023-08-08 08:40 -0400
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-08-08 12:17 +0200
Re: you think rust may outthrone c? Vir Campestris <vir.campestris@invalid.invalid> - 2023-08-04 18:00 +0100
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-04 19:25 +0100
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-08-08 13:11 +0200
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-08 04:22 -0700
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-08-08 14:45 +0200
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-08 06:02 -0700
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-08 15:39 +0100
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-08 08:36 -0700
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-09 02:15 +0100
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-08 12:36 +0100
Re: you think rust may *DE*throne c? scott@slp53.sl.home (Scott Lurndal) - 2023-08-08 14:05 +0000
Re: you think rust may *DE*throne c? Bart <bc@freeuk.com> - 2023-08-08 15:31 +0100
Re: you think rust may *DE*throne c? scott@slp53.sl.home (Scott Lurndal) - 2023-08-08 14:34 +0000
Re: you think rust may *DE*throne c? Bart <bc@freeuk.com> - 2023-08-08 16:11 +0100
Re: you think rust may *DE*throne c? scott@slp53.sl.home (Scott Lurndal) - 2023-08-08 15:49 +0000
Re: you think rust may *DE*throne c? Bart <bc@freeuk.com> - 2023-08-08 21:05 +0100
Re: you think rust may *DE*throne c? Michael S <already5chosen@yahoo.com> - 2023-08-08 09:02 -0700
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-08-08 16:27 +0200
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-08 16:09 +0100
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-08 16:42 +0100
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-08-08 18:38 +0200
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-08 09:47 -0700
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-08 19:14 +0100
Re: you think rust may outthrone c? Michael S <already5chosen@yahoo.com> - 2023-08-08 10:04 -0700
Re: you think rust may *DE*throne c? scott@slp53.sl.home (Scott Lurndal) - 2023-08-08 17:32 +0000
Re: you think rust may *DE*throne c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-08 10:47 -0700
Re: you think rust may *DE*throne c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-09 03:04 +0100
Re: you think rust may *DE*throne c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-08 19:44 -0700
Re: you think rust may *DE*throne c? Bart <bc@freeuk.com> - 2023-08-09 11:22 +0100
Re: you think rust may *DE*throne c? Richard Harnden <richard.nospam@gmail.com> - 2023-08-09 11:36 +0100
Re: you think rust may *DE*throne c? Bart <bc@freeuk.com> - 2023-08-09 11:58 +0100
Re: you think rust may *DE*throne c? Richard Harnden <richard.nospam@gmail.com> - 2023-08-09 14:29 +0100
Re: you think rust may *DE*throne c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-09 16:02 +0000
Re: you think rust may *DE*throne c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-09 14:17 -0700
Re: you think rust may *DE*throne c? Dan Purgert <dan@djph.net> - 2023-08-09 11:05 +0000
Re: you think rust may *DE*throne c? Bart <bc@freeuk.com> - 2023-08-09 13:32 +0100
Re: you think rust may *DE*throne c? Richard Harnden <richard.nospam@gmail.com> - 2023-08-09 14:32 +0100
Re: you think rust may *DE*throne c? Bart <bc@freeuk.com> - 2023-08-09 15:07 +0100
Re: you think rust may *DE*throne c? Richard Harnden <richard.nospam@gmail.com> - 2023-08-09 15:48 +0100
Re: you think rust may *DE*throne c? Bart <bc@freeuk.com> - 2023-08-09 16:08 +0100
Re: you think rust may *DE*throne c? scott@slp53.sl.home (Scott Lurndal) - 2023-08-09 15:52 +0000
Re: you think rust may *DE*throne c? Bart <bc@freeuk.com> - 2023-08-09 18:09 +0100
Re: you think rust may *DE*throne c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-09 16:34 +0000
Re: you think rust may *DE*throne c? David Brown <david.brown@hesbynett.no> - 2023-08-12 10:36 +0200
Re: you think rust may *DE*throne c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-12 02:58 -0700
Re: you think rust may *DE*throne c? David Brown <david.brown@hesbynett.no> - 2023-08-13 08:18 +0200
Re: you think rust may *DE*throne c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-13 07:07 +0000
Re: you think rust may *DE*throne c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-13 07:34 +0000
Re: you think rust may *DE*throne c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-13 08:24 +0000
Re: you think rust may *DE*throne c? David Brown <david.brown@hesbynett.no> - 2023-08-15 14:10 +0200
Re: you think rust may *DE*throne c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-13 00:18 -0700
Re: you think rust may *DE*throne c? Spiros Bousbouras <spibou@gmail.com> - 2023-08-13 08:08 +0000
Re: you think rust may *DE*throne c? Michael S <already5chosen@yahoo.com> - 2023-08-13 03:44 -0700
Re: you think rust may *DE*throne c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-13 06:16 -0700
Re: you think rust may *DE*throne c? scott@slp53.sl.home (Scott Lurndal) - 2023-08-13 15:53 +0000
Re: you think rust may *DE*throne c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-13 08:58 -0700
Re: you think rust may *DE*throne c? Bart <bc@freeuk.com> - 2023-08-13 17:36 +0100
Re: you think rust may *DE*throne c? Michael S <already5chosen@yahoo.com> - 2023-08-13 03:38 -0700
Re: you think rust may *DE*throne c? Bart <bc@freeuk.com> - 2023-08-12 12:12 +0100
Re: you think rust may *DE*throne c? David Brown <david.brown@hesbynett.no> - 2023-08-13 09:30 +0200
Re: you think rust may *DE*throne c? scott@slp53.sl.home (Scott Lurndal) - 2023-08-13 16:02 +0000
Re: you think rust may *DE*throne c? Bart <bc@freeuk.com> - 2023-08-13 17:48 +0100
Re: you think rust may *DE*throne c? Bart <bc@freeuk.com> - 2023-08-13 18:53 +0100
Re: you think rust may *DE*throne c? scott@slp53.sl.home (Scott Lurndal) - 2023-08-13 20:41 +0000
Re: you think rust may *DE*throne c? scott@slp53.sl.home (Scott Lurndal) - 2023-08-13 20:40 +0000
Re: you think rust may *DE*throne c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-14 04:28 +0000
Re: you think rust may *DE*throne c? scott@slp53.sl.home (Scott Lurndal) - 2023-08-14 15:52 +0000
Re: you think rust may *DE*throne c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-14 16:06 +0000
Re: you think rust may *DE*throne c? David Brown <david.brown@hesbynett.no> - 2023-08-15 14:19 +0200
Re: you think rust may *DE*throne c? scott@slp53.sl.home (Scott Lurndal) - 2023-08-15 14:33 +0000
Re: you think rust may *DE*throne c? David Brown <david.brown@hesbynett.no> - 2023-08-15 17:24 +0200
Re: you think rust may *DE*throne c? scott@slp53.sl.home (Scott Lurndal) - 2023-08-15 15:58 +0000
Re: you think rust may *DE*throne c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-15 15:58 +0000
Re: you think rust may *DE*throne c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-15 15:27 +0000
Re: you think rust may *DE*throne c? David Brown <david.brown@hesbynett.no> - 2023-08-11 08:43 +0200
Re: you think rust may *DE*throne c? Bart <bc@freeuk.com> - 2023-08-11 11:17 +0100
Re: you think rust may *DE*throne c? kalevi@kolttonen.fi (Kalevi Kolttonen) - 2023-08-11 10:50 +0000
Re: you think rust may *DE*throne c? Bart <bc@freeuk.com> - 2023-08-11 13:09 +0100
Re: you think rust may *DE*throne c? scott@slp53.sl.home (Scott Lurndal) - 2023-08-11 13:32 +0000
Re: you think rust may *DE*throne c? Michael S <already5chosen@yahoo.com> - 2023-08-11 07:33 -0700
Re: you think rust may *DE*throne c? scott@slp53.sl.home (Scott Lurndal) - 2023-08-11 15:38 +0000
Re: you think rust may *DE*throne c? kalevi@kolttonen.fi (Kalevi Kolttonen) - 2023-08-11 16:45 +0000
Re: you think rust may *DE*throne c? fir <profesor.fir@gmail.com> - 2023-08-11 10:20 -0700
Re: you think rust may *DE*throne c? Bart <bc@freeuk.com> - 2023-08-11 18:35 +0100
Re: you think rust may *DE*throne c? kalevi@kolttonen.fi (Kalevi Kolttonen) - 2023-08-11 20:33 +0000
Re: you think rust may *DE*throne c? Bart <bc@freeuk.com> - 2023-08-11 22:09 +0100
Re: you think rust may *DE*throne c? Richard Harnden <richard.nospam@gmail.com> - 2023-08-11 22:59 +0100
Re: you think rust may *DE*throne c? kalevi@kolttonen.fi (Kalevi Kolttonen) - 2023-08-11 23:25 +0000
Re: you think rust may *DE*throne c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-12 00:26 +0000
Re: you think rust may *DE*throne c? David Brown <david.brown@hesbynett.no> - 2023-08-15 14:24 +0200
Re: you think rust may *DE*throne c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-11 21:30 +0000
Re: you think rust may *DE*throne c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-11 13:44 -0700
Re: you think rust may *DE*throne c? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-08-11 14:55 -0700
Re: you think rust may *DE*throne c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-11 21:38 +0000
Re: you think rust may *DE*throne c? Bart <bc@freeuk.com> - 2023-08-11 22:46 +0100
Re: you think rust may *DE*throne c? David Brown <david.brown@hesbynett.no> - 2023-08-15 14:32 +0200
Re: you think rust may *DE*throne c? Bart <bc@freeuk.com> - 2023-08-12 12:07 +0100
Re: you think rust may *DE*throne c? Bart <bc@freeuk.com> - 2023-08-11 15:34 +0100
Re: you think rust may *DE*throne c? scott@slp53.sl.home (Scott Lurndal) - 2023-08-11 15:39 +0000
Re: you think rust may *DE*throne c? Bart <bc@freeuk.com> - 2023-08-11 17:26 +0100
Re: you think rust may *DE*throne c? scott@slp53.sl.home (Scott Lurndal) - 2023-08-11 16:53 +0000
Re: you think rust may *DE*throne c? Bart <bc@freeuk.com> - 2023-08-11 18:15 +0100
Re: you think rust may *DE*throne c? Bart <bc@freeuk.com> - 2023-08-11 18:46 +0100
Re: you think rust may *DE*throne c? David Brown <david.brown@hesbynett.no> - 2023-08-15 14:35 +0200
Re: you think rust may *DE*throne c? Richard Harnden <richard.nospam@gmail.com> - 2023-08-11 19:43 +0100
Re: you think rust may *DE*throne c? David Brown <david.brown@hesbynett.no> - 2023-08-13 09:34 +0200
Re: you think rust may *DE*throne c? scott@slp53.sl.home (Scott Lurndal) - 2023-08-13 16:02 +0000
Re: you think rust may *DE*throne c? Bart <bc@freeuk.com> - 2023-08-13 17:38 +0100
Re: you think rust may *DE*throne c? David Brown <david.brown@hesbynett.no> - 2023-08-15 14:37 +0200
Re: you think rust may *DE*throne c? scott@slp53.sl.home (Scott Lurndal) - 2023-08-15 14:34 +0000
Re: you think rust may *DE*throne c? Bart <bc@freeuk.com> - 2023-08-15 16:17 +0100
Re: you think rust may *DE*throne c? David Brown <david.brown@hesbynett.no> - 2023-08-15 17:25 +0200
Re: you think rust may *DE*throne c? scott@slp53.sl.home (Scott Lurndal) - 2023-08-15 16:00 +0000
Re: you think rust may *DE*throne c? Ike Naar <ike@sdf.org> - 2023-08-11 10:05 +0000
Re: you think rust may *DE*throne c? Bart <bc@freeuk.com> - 2023-08-11 11:48 +0100
Re: you think rust may *DE*throne c? Dan Purgert <dan@djph.net> - 2023-08-09 15:06 +0000
Re: you think rust may *DE*throne c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-09 16:16 +0000
Re: you think rust may *DE*throne c? David Brown <david.brown@hesbynett.no> - 2023-08-10 09:38 +0200
Re: you think rust may *DE*throne c? Bart <bc@freeuk.com> - 2023-08-10 10:51 +0100
Re: you think rust may *DE*throne c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-09 15:57 +0000
Re: you think rust may *DE*throne c? David Brown <david.brown@hesbynett.no> - 2023-08-10 00:15 +0200
Re: you think rust may *DE*throne c? Bart <bc@freeuk.com> - 2023-08-10 00:22 +0100
Re: you think rust may *DE*throne c? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-08-09 17:02 -0700
Re: you think rust may *DE*throne c? scott@slp53.sl.home (Scott Lurndal) - 2023-08-10 14:27 +0000
Re: you think rust may *DE*throne c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-10 00:01 +0100
Re: you think rust may *DE*throne c? Bart <bc@freeuk.com> - 2023-08-10 00:39 +0100
Re: you think rust may *DE*throne c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-09 17:08 -0700
Re: you think rust may *DE*throne c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-10 00:21 +0000
Re: you think rust may *DE*throne c? Bart <bc@freeuk.com> - 2023-08-10 02:18 +0100
Re: you think rust may *DE*throne c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-10 02:28 +0000
Re: you think rust may *DE*throne c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-09 22:42 -0700
Re: you think rust may *DE*throne c? scott@slp53.sl.home (Scott Lurndal) - 2023-08-10 14:23 +0000
Re: you think rust may *DE*throne c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-09 19:10 -0700
Re: you think rust may *DE*throne c? scott@slp53.sl.home (Scott Lurndal) - 2023-08-10 14:24 +0000
Re: you think rust may *DE*throne c? scott@slp53.sl.home (Scott Lurndal) - 2023-08-10 14:21 +0000
Re: you think rust may *DE*throne c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-10 03:16 +0100
Re: you think rust may *DE*throne c? scott@slp53.sl.home (Scott Lurndal) - 2023-08-10 14:25 +0000
Re: you think rust may *DE*throne c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-10 16:18 +0100
Re: you think rust may *DE*throne c? scott@slp53.sl.home (Scott Lurndal) - 2023-08-10 15:53 +0000
Re: you think rust may *DE*throne c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-10 16:15 +0000
Re: you think rust may *DE*throne c? scott@slp53.sl.home (Scott Lurndal) - 2023-08-10 16:59 +0000
Re: you think rust may *DE*throne c? Michael S <already5chosen@yahoo.com> - 2023-08-10 10:12 -0700
Re: you think rust may *DE*throne c? Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2023-08-10 17:16 +0000
Re: you think rust may *DE*throne c? Michael S <already5chosen@yahoo.com> - 2023-08-10 10:27 -0700
Re: you think rust may *DE*throne c? scott@slp53.sl.home (Scott Lurndal) - 2023-08-10 17:54 +0000
Re: you think rust may *DE*throne c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-10 18:18 +0000
Re: you think rust may *DE*throne c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-10 18:16 +0000
Re: you think rust may *DE*throne c? fir <profesor.fir@gmail.com> - 2023-08-10 14:44 -0700
Re: you think rust may *DE*throne c? fir <profesor.fir@gmail.com> - 2023-08-10 14:56 -0700
Re: you think rust may *DE*throne c? Bart <bc@freeuk.com> - 2023-08-10 23:17 +0100
Re: you think rust may *DE*throne c? fir <profesor.fir@gmail.com> - 2023-08-10 16:06 -0700
Re: you think rust may *DE*throne c? fir <profesor.fir@gmail.com> - 2023-08-10 16:20 -0700
Re: you think rust may *DE*throne c? fir <profesor.fir@gmail.com> - 2023-08-10 16:38 -0700
Re: you think rust may *DE*throne c? fir <profesor.fir@gmail.com> - 2023-08-10 16:58 -0700
Re: you think rust may *DE*throne c? fir <profesor.fir@gmail.com> - 2023-08-10 18:43 -0700
Re: you think rust may *DE*throne c? Bart <bc@freeuk.com> - 2023-08-11 01:30 +0100
Re: you think rust may *DE*throne c? fir <profesor.fir@gmail.com> - 2023-08-10 17:58 -0700
Re: you think rust may *DE*throne c? fir <profesor.fir@gmail.com> - 2023-08-11 07:03 -0700
Re: you think rust may *DE*throne c? fir <profesor.fir@gmail.com> - 2023-08-11 07:28 -0700
Re: you think rust may *DE*throne c? fir <profesor.fir@gmail.com> - 2023-08-11 07:47 -0700
Re: you think rust may *DE*throne c? fir <profesor.fir@gmail.com> - 2023-08-11 08:06 -0700
Re: you think rust may *DE*throne c? Bart <bc@freeuk.com> - 2023-08-11 16:13 +0100
Re: you think rust may *DE*throne c? fir <profesor.fir@gmail.com> - 2023-08-11 08:28 -0700
Re: you think rust may *DE*throne c? fir <profesor.fir@gmail.com> - 2023-08-11 08:37 -0700
Re: you think rust may *DE*throne c? fir <profesor.fir@gmail.com> - 2023-08-11 08:46 -0700
Re: you think rust may *DE*throne c? fir <profesor.fir@gmail.com> - 2023-08-11 08:58 -0700
Re: you think rust may *DE*throne c? fir <profesor.fir@gmail.com> - 2023-08-11 09:52 -0700
Re: you think rust may *DE*throne c? fir <profesor.fir@gmail.com> - 2023-08-10 18:21 -0700
Re: you think rust may *DE*throne c? Bart <bc@freeuk.com> - 2023-08-10 23:09 +0100
Re: you think rust may *DE*throne c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-11 01:14 +0000
Re: you think rust may *DE*throne c? Spiros Bousbouras <spibou@gmail.com> - 2023-08-11 05:42 +0000
Re: you think rust may *DE*throne c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-11 06:07 +0000
Re: you think rust may *DE*throne c? scott@slp53.sl.home (Scott Lurndal) - 2023-08-11 13:30 +0000
Re: you think rust may *DE*throne c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-11 19:41 +0000
Re: you think rust may *DE*throne c? fir <profesor.fir@gmail.com> - 2023-08-12 08:21 -0700
Re: you think rust may *DE*throne c? fir <profesor.fir@gmail.com> - 2023-08-12 11:14 -0700
Re: you think rust may *DE*throne c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-10 17:39 +0100
Re: you think rust may *DE*throne c? Michael S <already5chosen@yahoo.com> - 2023-08-10 09:40 -0700
Re: you think rust may *DE*throne c? Bart <bc@freeuk.com> - 2023-08-10 17:48 +0100
Re: you think rust may *DE*throne c? David Brown <david.brown@hesbynett.no> - 2023-08-15 14:45 +0200
Re: you think rust may *DE*throne c? Bart <bc@freeuk.com> - 2023-08-15 13:52 +0100
Re: you think rust may *DE*throne c? scott@slp53.sl.home (Scott Lurndal) - 2023-08-15 14:40 +0000
Re: you think rust may *DE*throne c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-15 06:26 -0700
Re: you think rust may *DE*throne c? David Brown <david.brown@hesbynett.no> - 2023-08-15 15:43 +0200
Re: you think rust may *DE*throne c? fir <profesor.fir@gmail.com> - 2023-08-16 10:09 -0700
Re: you think rust may *DE*throne c? fir <profesor.fir@gmail.com> - 2023-08-18 07:36 -0700
Re: you think rust may *DE*throne c? Bart <bc@freeuk.com> - 2023-08-10 16:33 +0100
Re: you think rust may *DE*throne c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-10 16:57 +0000
Re: you think rust may *DE*throne c? Michael S <already5chosen@yahoo.com> - 2023-08-10 01:10 -0700
Re: you think rust may *DE*throne c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-10 16:08 +0100
Re: you think rust may *DE*throne c? Michael S <already5chosen@yahoo.com> - 2023-08-10 09:49 -0700
Re: you think rust may *DE*throne c? Bart <bc@freeuk.com> - 2023-08-10 18:08 +0100
Re: you think rust may *DE*throne c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-10 21:04 +0100
Re: you think rust may *DE*throne c? scott@slp53.sl.home (Scott Lurndal) - 2023-08-10 20:56 +0000
Re: you think rust may *DE*throne c? scott@slp53.sl.home (Scott Lurndal) - 2023-08-10 14:20 +0000
Re: you think rust may *DE*throne c? Michael S <already5chosen@yahoo.com> - 2023-08-08 10:53 -0700
Re: you think rust may *DE*throne c? scott@slp53.sl.home (Scott Lurndal) - 2023-08-08 18:30 +0000
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-08-09 23:14 +0200
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-08 19:07 +0100
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-08 15:46 -0700
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-09 00:15 +0100
Re: you think rust may outthrone c? scott@slp53.sl.home (Scott Lurndal) - 2023-08-08 23:54 +0000
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-08 17:52 -0700
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-09 02:22 +0100
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-08 19:01 -0700
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-08 16:57 -0700
Re: you think rust may *DE*throne c? scott@slp53.sl.home (Scott Lurndal) - 2023-08-08 14:03 +0000
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-07-27 13:13 -0700
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-07-28 23:35 +0100
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-07-28 19:21 -0700
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-07-29 21:15 +0100
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-07-29 14:45 -0700
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-07-29 00:05 -0700
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-07-29 11:19 +0100
Re: you think rust may outthrone c? scott@slp53.sl.home (Scott Lurndal) - 2023-07-29 13:47 +0000
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-07-29 15:10 +0100
Re: you think rust may outthrone c? scott@slp53.sl.home (Scott Lurndal) - 2023-07-29 16:00 +0000
Re: you think rust may outthrone c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-07-29 15:30 +0000
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-07-29 14:22 -0700
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-07-29 14:49 -0700
Re: you think rust may outthrone c? scott@slp53.sl.home (Scott Lurndal) - 2023-07-27 14:07 +0000
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-07-27 16:03 +0100
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-08-01 19:43 +0200
Re: you think rust may outthrone c? scott@slp53.sl.home (Scott Lurndal) - 2023-08-01 18:37 +0000
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-01 22:16 +0100
Re: you think rust may outthrone c? scott@slp53.sl.home (Scott Lurndal) - 2023-08-01 21:53 +0000
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-01 23:28 +0100
Re: you think rust may outthrone c? scott@slp53.sl.home (Scott Lurndal) - 2023-08-02 01:54 +0000
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-02 11:14 +0100
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-08-02 18:23 +0200
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-02 19:02 +0100
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-08-03 11:28 +0200
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-03 11:53 +0100
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-03 11:54 +0100
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-08-02 18:12 +0200
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-01 14:45 -0700
Re: you think rust may outthrone c? scott@slp53.sl.home (Scott Lurndal) - 2023-07-26 15:02 +0000
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-07-26 17:08 -0700
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-07-21 12:38 -0700
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-07-21 12:29 -0700
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-21 09:46 +0200
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-07-21 02:29 -0700
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-22 21:04 +0200
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-07-19 14:38 +0100
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-07-19 07:00 -0700
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-07-19 17:31 +0100
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-07-19 14:54 -0700
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-20 10:55 +0200
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-07-21 03:07 +0100
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-07-19 12:07 +0100
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-07-19 15:15 +0100
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-07-19 17:08 +0100
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-07-19 17:30 +0100
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-19 19:22 +0200
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-07-19 20:28 +0100
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-19 16:27 +0200
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-07-19 17:06 +0100
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-19 20:39 +0200
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-07-19 20:21 +0100
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-07-19 15:42 -0700
Re: you think rust may outthrone c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-07-19 23:31 +0000
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-07-19 18:53 -0700
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-07-20 01:46 -0700
Re: you think rust may outthrone c? Spiros Bousbouras <spibou@gmail.com> - 2023-07-20 09:51 +0000
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-07-20 03:36 -0700
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-07-20 12:13 +0100
Re: you think rust may outthrone c? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-07-20 13:06 -0700
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-20 11:28 +0200
Re: you think rust may outthrone c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-07-20 16:44 +0000
Re: you think rust may outthrone c? James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-07-21 01:22 -0400
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-07-21 02:03 -0700
Re: you think rust may outthrone c? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-07-22 15:37 -0700
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-07-20 02:08 +0100
Re: you think rust may outthrone c? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-07-22 15:43 -0700
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-20 11:07 +0200
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-07-21 02:49 +0100
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-21 10:17 +0200
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-07-21 16:30 +0100
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-07-21 12:54 -0700
Re: you think rust may outthrone c? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-07-22 15:56 -0700
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-07-19 17:22 +0100
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-19 21:01 +0200
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-07-19 20:46 +0100
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-07-19 20:47 +0100
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-07-19 21:49 +0100
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-20 11:42 +0200
Re: you think rust may outthrone c? "minf...@arcor.de" <minforth@arcor.de> - 2023-07-20 05:39 -0700
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-20 14:55 +0200
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-07-20 15:03 +0100
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-20 18:22 +0200
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-07-20 15:54 -0700
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-21 10:18 +0200
Re: you think rust may outthrone c? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-07-20 13:04 -0700
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-21 10:20 +0200
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-07-20 20:51 +0100
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-20 11:38 +0200
Re: you think rust may outthrone c? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-07-20 13:03 -0700
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-21 10:24 +0200
Re: you think rust may outthrone c? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-07-21 13:03 -0700
Re: you think rust may outthrone c? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-07-23 16:17 -0700
Re: you think rust may outthrone c? scott@slp53.sl.home (Scott Lurndal) - 2023-07-21 14:35 +0000
Re: you think rust may outthrone c? scott@slp53.sl.home (Scott Lurndal) - 2023-07-18 14:34 +0000
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-07-18 08:04 -0700
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-07-17 21:27 -0700
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-07-18 12:10 +0100
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-18 16:43 +0200
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-07-18 14:59 +0100
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-07-17 17:44 -0700
Re: you think rust may outthrone c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-07-18 00:14 +0000
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-18 10:13 +0200
Re: you think rust may outthrone c? fir <profesor.fir@gmail.com> - 2023-07-17 16:10 -0700
Re: you think rust may outthrone c? fir <profesor.fir@gmail.com> - 2023-07-17 16:13 -0700
Re: you think rust may outthrone c? fir <profesor.fir@gmail.com> - 2023-07-17 16:16 -0700
Re: you think rust may outthrone c? fir <profesor.fir@gmail.com> - 2023-07-17 16:29 -0700
Yeah, C is harder than many programming languages. Your point? (Was: you think rust may outthrone c?) gazelle@shell.xmission.com (Kenny McCormack) - 2023-07-14 11:24 +0000
Re: Yeah, C is harder than many programming languages. Your point? kalevi@kolttonen.fi (Kalevi Kolttonen) - 2023-07-14 11:30 +0000
Re: Yeah, C is harder than many programming languages. Your point? fir <profesor.fir@gmail.com> - 2023-07-14 05:20 -0700
Re: Yeah, C is harder than many programming languages. Your point? kalevi@kolttonen.fi (Kalevi Kolttonen) - 2023-07-14 12:29 +0000
Re: Yeah, C is harder than many programming languages. Your point? fir <profesor.fir@gmail.com> - 2023-07-14 05:46 -0700
Re: Yeah, C is harder than many programming languages. Your point? kalevi@kolttonen.fi (Kalevi Kolttonen) - 2023-07-14 13:01 +0000
Re: Yeah, C is harder than many programming languages. Your point? fir <profesor.fir@gmail.com> - 2023-07-14 06:07 -0700
Re: Yeah, C is harder than many programming languages. Your point? kalevi@kolttonen.fi (Kalevi Kolttonen) - 2023-07-14 13:26 +0000
Why not? (Was: Yeah, C is harder than many programming languages. Your point?) gazelle@shell.xmission.com (Kenny McCormack) - 2023-07-14 13:32 +0000
Re: Why not? kalevi@kolttonen.fi (Kalevi Kolttonen) - 2023-07-14 13:43 +0000
Re: Why not? (killfiles) gazelle@shell.xmission.com (Kenny McCormack) - 2023-07-14 14:10 +0000
Re: Why not? (killfiles) kalevi@kolttonen.fi (Kalevi Kolttonen) - 2023-07-14 14:28 +0000
Re: Why not? (killfiles) gazelle@shell.xmission.com (Kenny McCormack) - 2023-07-14 18:46 +0000
Re: Yeah, C is harder than many programming languages. Your point? fir <profesor.fir@gmail.com> - 2023-07-14 06:52 -0700
Re: Yeah, C is harder than many programming languages. Your point? fir <profesor.fir@gmail.com> - 2023-07-15 02:21 -0700
Re: Yeah, C is harder than many programming languages. Your point? James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-07-14 09:14 -0400
Posting for our own amusement (Was: Yeah, C is harder than many programming languages. Your point?) gazelle@shell.xmission.com (Kenny McCormack) - 2023-07-14 13:29 +0000
Re: Posting for our own amusement (Was: Yeah, C is harder than many programming languages. Your point?) "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2023-07-14 07:26 -0700
Re: Posting for our own amusement (Was: Yeah, C is harder than many programming languages. Your point?) gazelle@shell.xmission.com (Kenny McCormack) - 2023-07-14 14:39 +0000
Re: Posting for our own amusement (Was: Yeah, C is harder than many programming languages. Your point?) David Brown <david.brown@hesbynett.no> - 2023-07-14 17:30 +0200
Re: Posting for our own amusement (Was: Yeah, C is harder than many programming languages. Your point?) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-07-14 20:53 +0000
Re: Yeah, C is harder than many programming languages. Your point? fir <profesor.fir@gmail.com> - 2023-07-14 06:30 -0700
Re: Yeah, C is harder than many programming languages. Your point? kalevi@kolttonen.fi (Kalevi Kolttonen) - 2023-07-14 13:30 +0000
Re: Yeah, C is harder than many programming languages. Your point? gazelle@shell.xmission.com (Kenny McCormack) - 2023-07-14 12:29 +0000
Re: Yeah, C is harder than many programming languages. Your point? kalevi@kolttonen.fi (Kalevi Kolttonen) - 2023-07-14 12:46 +0000
Re: Yeah, C is harder than many programming languages. Your point? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-07-14 20:46 +0000
Re: Yeah, C is harder than many programming languages. Your point? kalevi@kolttonen.fi (Kalevi Kolttonen) - 2023-07-14 21:49 +0000
Re: you think rust may outthrone c? Po Lu <luangruo@yahoo.com> - 2023-07-14 20:52 +0800
Re: you think rust may outthrone c? kalevi@kolttonen.fi (Kalevi Kolttonen) - 2023-07-14 13:16 +0000
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-14 17:34 +0200
Re: you think rust may outthrone c? kalevi@kolttonen.fi (Kalevi Kolttonen) - 2023-07-14 16:20 +0000
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-14 19:11 +0200
Re: you think rust may outthrone c? kalevi@kolttonen.fi (Kalevi Kolttonen) - 2023-07-14 17:26 +0000
Re: you think rust may outthrone c? Paul N <gw7rib@aol.com> - 2023-07-15 04:42 -0700
Re: you think rust may outthrone c? kalevi@kolttonen.fi (Kalevi Kolttonen) - 2023-07-15 12:29 +0000
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-15 18:40 +0200
Re: you think rust may outthrone c? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-07-20 19:05 -0700
Re: you think rust may outthrone c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-07-14 21:25 +0000
Re: you think rust may outthrone c? kalevi@kolttonen.fi (Kalevi Kolttonen) - 2023-07-14 22:30 +0000
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-07-14 15:48 -0700
Re: you think rust may outthrone c? kalevi@kolttonen.fi (Kalevi Kolttonen) - 2023-07-14 22:56 +0000
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-15 14:41 +0200
Re: you think rust may outthrone c? kalevi@kolttonen.fi (Kalevi Kolttonen) - 2023-07-15 12:55 +0000
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-15 18:46 +0200
Re: you think rust may outthrone c? kalevi@kolttonen.fi (Kalevi Kolttonen) - 2023-07-15 17:28 +0000
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-15 20:20 +0200
Re: you think rust may outthrone c? kalevi@kolttonen.fi (Kalevi Kolttonen) - 2023-07-15 18:42 +0000
Re: you think rust may outthrone c? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-07-22 06:46 -0700
Re: you think rust may outthrone c? Po Lu <luangruo@yahoo.com> - 2023-07-15 14:12 +0800
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-07-15 01:05 -0700
Re: you think rust may outthrone c? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-07-20 18:54 -0700
Re: you think rust may outthrone c? kalevi@kolttonen.fi (Kalevi Kolttonen) - 2023-07-15 08:59 +0000
Re: you think rust may outthrone c? James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-07-17 02:26 -0400
Re: you think rust may outthrone c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-07-14 20:43 +0000
Re: you think rust may outthrone c? kalevi@kolttonen.fi (Kalevi Kolttonen) - 2023-07-14 21:58 +0000
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-14 09:32 +0200
Re: you think rust may outthrone c? kalevi@kolttonen.fi (Kalevi Kolttonen) - 2023-07-14 07:58 +0000
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-14 12:56 +0200
OT Re: you think rust may outthrone c? jak <nospam@please.ty> - 2023-07-14 10:20 +0200
Re: you think rust may outthrone c? Po Lu <luangruo@yahoo.com> - 2023-07-14 20:48 +0800
Re: you think rust may outthrone c? Anton Shepelev <anton.txt@g{oogle}mail.com> - 2023-07-17 18:33 +0300
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-07-17 20:47 +0100
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-07-17 21:14 +0100
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-07-17 21:47 +0100
Re: you think rust may outthrone c? Bonita Montero <Bonita.Montero@gmail.com> - 2023-07-17 18:26 +0200
Re: you think rust may outthrone c? kalevi@kolttonen.fi (Kalevi Kolttonen) - 2023-07-17 17:00 +0000
Re: you think rust may outthrone c? Bonita Montero <Bonita.Montero@gmail.com> - 2023-07-17 20:03 +0200
Re: you think rust may outthrone c? kalevi@kolttonen.fi (Kalevi Kolttonen) - 2023-07-17 20:28 +0000
Re: you think rust may outthrone c? Bonita Montero <Bonita.Montero@gmail.com> - 2023-07-19 18:06 +0200
Re: you think rust may outthrone c? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-07-17 11:42 -0700
Re: you think rust may outthrone c? kalevi@kolttonen.fi (Kalevi Kolttonen) - 2023-07-17 19:18 +0000
Re: you think rust may outthrone c? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-07-17 12:20 -0700
Re: you think rust may outthrone c? kalevi@kolttonen.fi (Kalevi Kolttonen) - 2023-07-17 20:26 +0000
Re: you think rust may outthrone c? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-07-18 01:06 -0700
Re: you think rust may outthrone c? Blue-Maned_Hawk <bluemanedhawk@gmail.com> - 2023-07-18 06:37 -0400
Re: you think rust may outthrone c? Bonita Montero <Bonita.Montero@gmail.com> - 2023-07-19 18:07 +0200
Re: you think rust may outthrone c? fir <profesor.fir@gmail.com> - 2023-07-19 09:17 -0700
Re: you think rust may outthrone c? Bonita Montero <Bonita.Montero@gmail.com> - 2023-07-20 11:06 +0200
Re: you think rust may outthrone c? Blue-Maned_Hawk <bluemanedhawk@gmail.com> - 2023-07-19 19:16 -0400
Re: you think rust may outthrone c? Bonita Montero <Bonita.Montero@gmail.com> - 2023-07-20 11:07 +0200
Re: you think rust may outthrone c? Blue-Maned_Hawk <bluemanedhawk@gmail.com> - 2023-07-20 08:49 -0400
Re: you think rust may outthrone c? Bonita Montero <Bonita.Montero@gmail.com> - 2023-07-20 16:25 +0200
Re: you think rust may outthrone c? Bonita Montero <Bonita.Montero@gmail.com> - 2023-07-20 19:48 +0200
Re: you think rust may outthrone c? Blue-Maned_Hawk <bluemanedhawk@gmail.com> - 2023-07-21 02:06 -0400
Re: you think rust may outthrone c? Bonita Montero <Bonita.Montero@gmail.com> - 2023-07-21 09:32 +0200
Re: you think rust may outthrone c? fir <profesor.fir@gmail.com> - 2023-07-21 06:06 -0700
Re: you think rust may outthrone c? fir <profesor.fir@gmail.com> - 2023-07-21 06:13 -0700
Re: you think rust may outthrone c? Bonita Montero <Bonita.Montero@gmail.com> - 2023-07-22 14:57 +0200
Re: you think rust may outthrone c? fir <profesor.fir@gmail.com> - 2023-07-22 07:10 -0700
Re: you think rust may outthrone c? Bonita Montero <Bonita.Montero@gmail.com> - 2023-07-22 16:29 +0200
Re: you think rust may outthrone c? fir <profesor.fir@gmail.com> - 2023-07-22 07:33 -0700
Re: you think rust may outthrone c? Bonita Montero <Bonita.Montero@gmail.com> - 2023-07-22 16:35 +0200
Re: you think rust may outthrone c? Blue-Maned_Hawk <bluemanedhawk@gmail.com> - 2023-07-22 01:30 -0400
Re: you think rust may outthrone c? Bonita Montero <Bonita.Montero@gmail.com> - 2023-07-22 15:00 +0200
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-07-22 14:53 +0100
Re: you think rust may outthrone c? fir <profesor.fir@gmail.com> - 2023-07-22 07:22 -0700
Re: you think rust may outthrone c? Bonita Montero <Bonita.Montero@gmail.com> - 2023-07-22 16:32 +0200
Re: you think rust may outthrone c? fir <profesor.fir@gmail.com> - 2023-07-22 07:42 -0700
Re: you think rust may outthrone c? Bonita Montero <Bonita.Montero@gmail.com> - 2023-07-22 17:01 +0200
Re: you think rust may outthrone c? jak <nospam@please.ty> - 2023-07-22 17:45 +0200
Re: you think rust may outthrone c? Bonita Montero <Bonita.Montero@gmail.com> - 2023-07-22 18:22 +0200
Re: you think rust may outthrone c? jak <nospam@please.ty> - 2023-07-22 19:00 +0200
Re: you think rust may outthrone c? Bonita Montero <Bonita.Montero@gmail.com> - 2023-07-22 19:06 +0200
Re: you think rust may outthrone c? jak <nospam@please.ty> - 2023-07-22 19:34 +0200
Re: you think rust may outthrone c? fir <profesor.fir@gmail.com> - 2023-07-22 14:15 -0700
Re: you think rust may outthrone c? fir <profesor.fir@gmail.com> - 2023-07-22 14:20 -0700
Re: you think rust may outthrone c? fir <profesor.fir@gmail.com> - 2023-07-22 14:25 -0700
Re: you think rust may outthrone c? fir <profesor.fir@gmail.com> - 2023-07-22 14:33 -0700
Re: you think rust may outthrone c? fir <profesor.fir@gmail.com> - 2023-07-23 03:23 -0700
Re: you think rust may outthrone c? Bonita Montero <Bonita.Montero@gmail.com> - 2023-07-23 03:28 +0200
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-07-22 16:48 +0100
Re: you think rust may outthrone c? Bonita Montero <Bonita.Montero@gmail.com> - 2023-07-22 18:24 +0200
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-07-22 19:02 +0100
Re: you think rust may outthrone c? Bonita Montero <Bonita.Montero@gmail.com> - 2023-07-22 20:06 +0200
Re: you think rust may outthrone c? fir <profesor.fir@gmail.com> - 2023-07-22 14:07 -0700
Re: you think rust may outthrone c? Bonita Montero <Bonita.Montero@gmail.com> - 2023-07-23 03:29 +0200
Re: you think rust may outthrone c? fir <profesor.fir@gmail.com> - 2023-07-23 00:52 -0700
Re: you think rust may outthrone c? fir <profesor.fir@gmail.com> - 2023-07-23 02:03 -0700
Re: you think rust may outthrone c? fir <profesor.fir@gmail.com> - 2023-07-23 02:18 -0700
Re: you think rust may outthrone c? Bonita Montero <Bonita.Montero@gmail.com> - 2023-07-23 13:44 +0200
Re: you think rust may outthrone c? Bonita Montero <Bonita.Montero@gmail.com> - 2023-07-23 13:43 +0200
Re: you think rust may outthrone c? fir <profesor.fir@gmail.com> - 2023-07-23 05:03 -0700
Re: you think rust may outthrone c? fir <profesor.fir@gmail.com> - 2023-07-23 05:07 -0700
Re: you think rust may outthrone c? fir <profesor.fir@gmail.com> - 2023-07-23 05:14 -0700
Re: you think rust may outthrone c? fir <profesor.fir@gmail.com> - 2023-07-23 05:54 -0700
Re: you think rust may outthrone c? fir <profesor.fir@gmail.com> - 2023-07-23 05:31 -0700
Re: you think rust may outthrone c? fir <profesor.fir@gmail.com> - 2023-07-23 05:42 -0700
Re: you think rust may outthrone c? Bonita Montero <Bonita.Montero@gmail.com> - 2023-07-23 15:16 +0200
Re: you think rust may outthrone c? fir <profesor.fir@gmail.com> - 2023-07-23 06:39 -0700
Re: you think rust may outthrone c? Bonita Montero <Bonita.Montero@gmail.com> - 2023-07-23 15:49 +0200
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-07-23 14:56 +0100
Re: you think rust may outthrone c? Bonita Montero <Bonita.Montero@gmail.com> - 2023-07-23 16:11 +0200
Re: you think rust may outthrone c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-07-23 14:34 +0000
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-23 18:43 +0200
Re: you think rust may outthrone c? fir <profesor.fir@gmail.com> - 2023-07-22 07:19 -0700
Re: you think rust may outthrone c? Bonita Montero <Bonita.Montero@gmail.com> - 2023-07-22 16:34 +0200
Re: you think rust may outthrone c? fir <profesor.fir@gmail.com> - 2023-07-22 07:48 -0700
Re: you think rust may outthrone c? fir <profesor.fir@gmail.com> - 2023-07-22 07:58 -0700
Re: you think rust may outthrone c? fir <profesor.fir@gmail.com> - 2023-07-22 08:00 -0700
Re: you think rust may outthrone c? Bonita Montero <Bonita.Montero@gmail.com> - 2023-07-22 17:01 +0200
Re: you think rust may outthrone c? fir <profesor.fir@gmail.com> - 2023-07-22 08:09 -0700
Re: you think rust may outthrone c? Bonita Montero <Bonita.Montero@gmail.com> - 2023-07-22 16:59 +0200
Re: you think rust may outthrone c? fir <profesor.fir@gmail.com> - 2023-07-22 08:02 -0700
Re: you think rust may outthrone c? Bonita Montero <Bonita.Montero@gmail.com> - 2023-07-22 17:07 +0200
Re: you think rust may outthrone c? fir <profesor.fir@gmail.com> - 2023-07-22 08:18 -0700
Re: you think rust may outthrone c? Bonita Montero <Bonita.Montero@gmail.com> - 2023-07-22 17:42 +0200
Re: you think rust may outthrone c? fir <profesor.fir@gmail.com> - 2023-07-22 08:51 -0700
Re: you think rust may outthrone c? Bonita Montero <Bonita.Montero@gmail.com> - 2023-07-22 18:26 +0200
Re: you think rust may outthrone c? fir <profesor.fir@gmail.com> - 2023-07-22 08:42 -0700
Re: you think rust may outthrone c? fir <profesor.fir@gmail.com> - 2023-07-22 09:20 -0700
Re: you think rust may outthrone c? Bonita Montero <Bonita.Montero@gmail.com> - 2023-07-22 18:27 +0200
Re: you think rust may outthrone c? fir <profesor.fir@gmail.com> - 2023-07-22 14:06 -0700
Re: you think rust may outthrone c? Bonita Montero <Bonita.Montero@gmail.com> - 2023-07-23 03:30 +0200
Re: you think rust may outthrone c? fir <profesor.fir@gmail.com> - 2023-07-23 00:58 -0700
Re: you think rust may outthrone c? fir <profesor.fir@gmail.com> - 2023-07-23 01:06 -0700
Re: you think rust may outthrone c? Bonita Montero <Bonita.Montero@gmail.com> - 2023-07-23 15:16 +0200
Re: you think rust may outthrone c? fir <profesor.fir@gmail.com> - 2023-07-23 06:40 -0700
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-07-22 08:49 -0700
Re: you think rust may outthrone c? fir <profesor.fir@gmail.com> - 2023-07-22 08:57 -0700
Re: you think rust may outthrone c? fir <profesor.fir@gmail.com> - 2023-07-22 09:01 -0700
Re: you think rust may outthrone c? Bonita Montero <Bonita.Montero@gmail.com> - 2023-07-22 18:30 +0200
Re: you think rust may outthrone c? fir <profesor.fir@gmail.com> - 2023-07-23 03:32 -0700
Page 16 of 49 — ← Prev page 1 … 14 15 [16] 17 18 … 49 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-08-08 17:18 +0200 |
| Message-ID | <uatmcb$3eti9$1@dont-email.me> |
| In reply to | #171679 |
On 05/08/2023 14:08, Malcolm McLean wrote: > On Saturday, 5 August 2023 at 12:40:10 UTC+1, David Brown wrote: >> On 04/08/2023 18:17, Malcolm McLean wrote: >>> On Friday, 4 August 2023 at 17:05:05 UTC+1, David Brown wrote: >>>> On 04/08/2023 17:20, Malcolm McLean wrote: >>>>> On Friday, 4 August 2023 at 16:12:39 UTC+1, David Brown wrote: >>>>>> On 04/08/2023 16:20, Spiros Bousbouras wrote: >>>>>>> On Thu, 3 Aug 2023 11:42:36 +0200 >>>>>>> David Brown <david...@hesbynett.no> wrote: >>>>>>>> When I >>>>>>>> am looking for software, if I find a possible option and see it is >>>>>>>> written in ANSI C90, I assume it is some ancient and outdated tool. It >>>>>>>> /might/ still be useful, but I start with a big negative bias. >>>>>>> >>>>>>> That's a strange attitude. If it is written in "old" C then likely it >>>>>>> was written a long time ago but it certainly doesn't follow that it is >>>>>>> outdated. >>>>>> True, of course. For some things, old software is just as good as new >>>>>> software - if the task hasn't changed, the software does not need to >>>>>> change. But for other kinds of software you want to be sure that it is >>>>>> relatively modern, or at least well maintained. That might be for >>>>>> supporting newer formats (in the case of a "resource compiler"), or >>>>>> perhaps it is software for which security is a concern. The software >>>>>> might also be written for older and weaker compilers - using "tricks" >>>>>> that were popular before, but are undefined behaviour in C and can fail >>>>>> with modern compilers. Being in an ancient C dialect does not guarantee >>>>>> that it is outdated, but it is a pointer in that direction. >>>>>> >>>>>> I would also have no interest in a "resource compiler" that generated C >>>>>> files that did not use <stdint.h> or <stdbool.h> types when appropriate, >>>>>> but perpetuated the inconvenience of home-made types. >>>>>> >>>>> It doesn't output homemade types like "u8" for a char. But it doesn't use >>>>> <stdint.h> or <stdbool.h> types either. It outputs the basic C types. >>>> That would be useless. Few people doing embedded work have any interest >>>> in something that turns resources (such as files to be embedded) into >>>> arrays of "short" or "unsigned long". Use "int16_t", "uint32_t", or >>>> whatever matches the resource type. >>>> >>>> This can be done in a dozen lines of Python scripting, and I get exactly >>>> what I need. I do so regularly for embedded bitmaps, or static files >>>> for an embedded webserver, and that kind of thing. >>>> >>> Yes, pretty much every C programmer has written a scratch program >>> to read in a binary and output C source. I can't find a tool that allows you >>> to get away from that, except the Baby X resource compiler. Whether that >>> is bad thing, meaning there's no demand for such a tool, or a good thing, >>> meaning it has a niche no-one else has thought of, I don't know. >> I think most cases need nothing more than converting a single file into >> a const array of uint8_t (or unsigned char if you prefer). Anything >> other than that, and I would not expect a pre-written tool to support >> what you want because you are likely to have particular needs at the >> time. When I have embedded fonts, image sequences, directory >> structures, etc., they have always been targeting a particular format >> for the application - general purpose or third-party conversion tools >> would be of no use at all. >> > This is the problem of course. The Baby X API expects data in a certain format. > So all the API functions which operate on images take a 32 bit RGBA buffer > as an "unsigned char *", and the dimensions as two ints. But another API might > use an opaque "IMAGE" structure. Or another system might have 16 bit r5g5b5a1 > images. It would make a lot of sense to have a program that took data in common standardised uncompressed forms (like .wav, .bmp) and generated data in whatever format suits Baby X. > Of course I could put in a flexible format specifier. But it would rapidly turn into > a scripting laugage in its onw right. In which case you might as well use Python. Indeed. You program already looks like that. >> >> Some graphics libraries come with "resource compilers" generating >> results in the format needed for the library. So if your "Baby X" has >> its own graphics format (or audio format), then a "resource compiler" >> turning standard formats into this internal format would make sense. >> But I fail to see how useful it would be for those not using "Baby X". >> > Reality is that the resouce compiler is more popular than Baby X. But > exactly how people are using it, I don't know >> >> I also can't imagine why anyone would want to put strings in an xml file >> instead of just putting them in the source code directly - it gives you >> no advantages. (If it organised strings and formats for >> internationalisation and translation, that would be a different matter.) >> > There is an "international" tag so you can do this > <international name = "hello"> > <string language = "english">Hello</string> > <string language = "french">Bonjour</string> > <utf8 language = "chinese"> [utf8 here] </utf8> > </international> > > Then it creates a C-callable function which is passed the languafe and returns > thr right string. > That's a horrendous interface for everyone involved. It is hideous for the programmer writing the XML (like all XML is). It is terrible for the translators, who want to work with strings in the common language (usually English) and their own language. It is horrible to use in the application code. It would be a mess to maintain in source code repositories. Seriously, I'm not sure how you could make it worse. Perhaps you could insist that the translation strings are all held in a MS Excel format spreadsheet? Did you even think about how people were supposed to use it, or how international programs are developed? I appreciate what you are trying to do with the tool, I just don't think you have considered what might be the best way for people to use it.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-08-08 16:35 +0100 |
| Message-ID | <uatnc5$3f2cj$1@dont-email.me> |
| In reply to | #171841 |
On 08/08/2023 16:18, David Brown wrote: > On 05/08/2023 14:08, Malcolm McLean wrote: >> Then it creates a C-callable function which is passed the languafe and >> returns >> thr right string. > > That's a horrendous interface for everyone involved. It is hideous for > the programmer writing the XML (like all XML is). It is terrible for > the translators, who want to work with strings in the common language > (usually English) and their own language. It is horrible to use in the > application code. It would be a mess to maintain in source code > repositories. > > Seriously, I'm not sure how you could make it worse. Perhaps you could > insist that the translation strings are all held in a MS Excel format > spreadsheet? > > Did you even think about how people were supposed to use it, or how > international programs are developed? > > > I appreciate what you are trying to do with the tool, I just don't think > you have considered what might be the best way for people to use it. I didn't understand all the purposes of the tool (I'm not going to use Baby X). It just looked like something that takes a media file and turns it into a block of C code suitable for embedding. When I tested it, it turned out I needed an XML file (as you say, truly horrible to work with). I had to use the example provided and tweak it. A simpler interface is just to accept the name of one media file, and turn that into a .c file (with the same name!). Any resizing options etc can be provided on the command line. Or that can be done via an alternate front-end module built into its own executable, keeping the Baby X functionality separate.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2023-08-08 09:04 -0700 |
| Message-ID | <a33ce226-3826-4b0c-97fc-585105018304n@googlegroups.com> |
| In reply to | #171841 |
On Tuesday, 8 August 2023 at 16:18:49 UTC+1, David Brown wrote: > On 05/08/2023 14:08, Malcolm McLean wrote: > > > This is the problem of course. The Baby X API expects data in a certain format. > > So all the API functions which operate on images take a 32 bit RGBA buffer > > as an "unsigned char *", and the dimensions as two ints. But another API might > > use an opaque "IMAGE" structure. Or another system might have 16 bit r5g5b5a1 > > images. > > It would make a lot of sense to have a program that took data in common > standardised uncompressed forms (like .wav, .bmp) and generated data in > whatever format suits Baby X. > "Data" means, "that which is given". People programming applications are given resources in many formats. They might steal a PNG from the web, get a JPEG commissioned from a paid artist, knock up their own SVG. Now of course it's possible to convert all these into a common format like PNG which is powerful enough to hold all thse formats without loss. But you've lost the link with the original data. So when the artist comes back with a second version of the JPEG, you've got to run ImageMagick again. And I don't have ImageMagick installed on the Mac I'm writing this on (there's a program called sips which does similar things). A resouce pipeline with lots of stages, each one requiring a separate third party program, is quite fragile. It works for as long as your Linux machine is all set up with the dependencies, which will be the case for the duration of the project. But if you archive it, and dust it off years later, will things still be intact? And will you know which are the intermediate files, and which are the original data? > > > Of course I could put in a flexible format specifier. But it would rapidly turn into > > a scripting laugage in its onw right. In which case you might as well use Python. > > Indeed. You program already looks like that. > No it doesn't. There's a very simple xml list of resources, and one or two attributes to control the output. It's nothing like a script. However to be fair I do suggest diving into the source if you want to customise it. The users will be C programmers, after all. > > > > There is an "international" tag so you can do this > > <international name = "hello"> > > <string language = "english">Hello</string> > > <string language = "french">Bonjour</string> > > <utf8 language = "chinese"> [utf8 here] </utf8> > > </international> > > > > Then it creates a C-callable function which is passed the languafe and returns > > thr right string. > > > > That's a horrendous interface for everyone involved. It is hideous for > the programmer writing the XML (like all XML is). It is terrible for > the translators, who want to work with strings in the common language > (usually English) and their own language. It is horrible to use in the > application code. It would be a mess to maintain in source code > repositories. > > Seriously, I'm not sure how you could make it worse. Perhaps you could > insist that the translation strings are all held in a MS Excel format > spreadsheet? > > Did you even think about how people were supposed to use it, or how > international programs are developed? > You might be right about that. We considered internationalisation at work (we make tools for artists), but the customers said they were happy with English, and it was such a bag of worms that we rejected the idea. So I've no experience. Part of the reason for discussing it here is that other people might have such experience. You can't really support Unicode but not support internationalisation, however. > > I appreciate what you are trying to do with the tool, I just don't think > you have considered what might be the best way for people to use it. > It's a resource compiler for Baby X. There's no good way of getting images and fonts into Baby X programs, other than using the resource compiler. Just as there's no good way of getting images and fonts into Windows programs without using the Windows resource compiler. But because the Baby X resource compiler produces C source instead of a binary blob, you don't have to use it with Baby X. But I'm not deliberately targetting non-Baby X users with v1.2, though the <utf16> tag is maybe a concession to non-Baby X use (Baby X uses UTF-8 throughout). As you have pointed out, there are a whole host of issues to consider before doing this properly. So it's something for a future version, not v1.2.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-08-08 16:41 +0000 |
| Message-ID | <20230808093957.910@kylheku.com> |
| In reply to | #171853 |
On 2023-08-08, Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote: > "Data" means, "that which is given". People programming applications are given Or, well, "those which are given", if we are going to be pedantic. "Datum" is that which is given. :)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-08-08 18:46 +0200 |
| Message-ID | <uatrg9$3fncp$1@dont-email.me> |
| In reply to | #171853 |
On 08/08/2023 18:04, Malcolm McLean wrote: > On Tuesday, 8 August 2023 at 16:18:49 UTC+1, David Brown wrote: >> On 05/08/2023 14:08, Malcolm McLean wrote: >> >>> This is the problem of course. The Baby X API expects data in a certain format. >>> So all the API functions which operate on images take a 32 bit RGBA buffer >>> as an "unsigned char *", and the dimensions as two ints. But another API might >>> use an opaque "IMAGE" structure. Or another system might have 16 bit r5g5b5a1 >>> images. >> >> It would make a lot of sense to have a program that took data in common >> standardised uncompressed forms (like .wav, .bmp) and generated data in >> whatever format suits Baby X. >> > "Data" means, "that which is given". People programming applications are given > resources in many formats. They might steal a PNG from the web, get a JPEG > commissioned from a paid artist, knock up their own SVG. > Now of course it's possible to convert all these into a common format like PNG > which is powerful enough to hold all thse formats without loss. But you've lost > the link with the original data. So when the artist comes back with a second > version of the JPEG, you've got to run ImageMagick again. And I don't have > ImageMagick installed on the Mac I'm writing this on (there's a program called > sips which does similar things). > A resouce pipeline with lots of stages, each one requiring a separate third party > program, is quite fragile. It works for as long as your Linux machine is all set up > with the dependencies, which will be the case for the duration of the project. > But if you archive it, and dust it off years later, will things still be intact? And > will you know which are the intermediate files, and which are the original data? It looks like there is someone else in this group who could benefit from understanding "make" and/or other build tools. And if you can't use a Mac for development, scrap the expensive toy and install a usable system. (Of course, you /can/ use a Mac for development - you just need to know how to use your tools.) >> >>> Of course I could put in a flexible format specifier. But it would rapidly turn into >>> a scripting laugage in its onw right. In which case you might as well use Python. >> >> Indeed. You program already looks like that. >> > No it doesn't. There's a very simple xml list of resources, and one or two attributes > to control the output. It's nothing like a script. However to be fair I do suggest diving > into the source if you want to customise it. The users will be C programmers, after > all. >>> >>> There is an "international" tag so you can do this >>> <international name = "hello"> >>> <string language = "english">Hello</string> >>> <string language = "french">Bonjour</string> >>> <utf8 language = "chinese"> [utf8 here] </utf8> >>> </international> >>> >>> Then it creates a C-callable function which is passed the languafe and returns >>> thr right string. >>> >> >> That's a horrendous interface for everyone involved. It is hideous for >> the programmer writing the XML (like all XML is). It is terrible for >> the translators, who want to work with strings in the common language >> (usually English) and their own language. It is horrible to use in the >> application code. It would be a mess to maintain in source code >> repositories. >> >> Seriously, I'm not sure how you could make it worse. Perhaps you could >> insist that the translation strings are all held in a MS Excel format >> spreadsheet? >> >> Did you even think about how people were supposed to use it, or how >> international programs are developed? >> > You might be right about that. We considered internationalisation at > work (we make tools for artists), but the customers said they were > happy with English, and it was such a bag of worms that we rejected > the idea. So I've no experience. Part of the reason for discussing it here > is that other people might have such experience. Just think about it a little. You know a language or two other than English - put yourself in the position of a translator who does not understand C and is not a programmer. Would you want to face that XML crap? > You can't really support Unicode but not support internationalisation, > however. Of course you can. It is only the opposite that will cause you difficulties.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2023-08-08 10:04 -0700 |
| Message-ID | <2eb60e6c-5f68-40fb-afef-c41ca8bb3683n@googlegroups.com> |
| In reply to | #171862 |
On Tuesday, 8 August 2023 at 17:46:15 UTC+1, David Brown wrote: > On 08/08/2023 18:04, Malcolm McLean wrote: > > On Tuesday, 8 August 2023 at 16:18:49 UTC+1, David Brown wrote: > >> On 05/08/2023 14:08, Malcolm McLean wrote: > >> > >>> This is the problem of course. The Baby X API expects data in a certain format. > >>> So all the API functions which operate on images take a 32 bit RGBA buffer > >>> as an "unsigned char *", and the dimensions as two ints. But another API might > >>> use an opaque "IMAGE" structure. Or another system might have 16 bit r5g5b5a1 > >>> images. > >> > >> It would make a lot of sense to have a program that took data in common > >> standardised uncompressed forms (like .wav, .bmp) and generated data in > >> whatever format suits Baby X. > >> > > "Data" means, "that which is given". People programming applications are given > > resources in many formats. They might steal a PNG from the web, get a JPEG > > commissioned from a paid artist, knock up their own SVG. > > Now of course it's possible to convert all these into a common format like PNG > > which is powerful enough to hold all thse formats without loss. But you've lost > > the link with the original data. So when the artist comes back with a second > > version of the JPEG, you've got to run ImageMagick again. And I don't have > > ImageMagick installed on the Mac I'm writing this on (there's a program called > > sips which does similar things). > > A resouce pipeline with lots of stages, each one requiring a separate third party > > program, is quite fragile. It works for as long as your Linux machine is all set up > > with the dependencies, which will be the case for the duration of the project. > > But if you archive it, and dust it off years later, will things still be intact? And > > will you know which are the intermediate files, and which are the original data? > It looks like there is someone else in this group who could benefit from > understanding "make" and/or other build tools. And if you can't use a > Mac for development, scrap the expensive toy and install a usable > system. (Of course, you /can/ use a Mac for development - you just need > to know how to use your tools.) > Bart's right about make. If it actually worked properly we wouldn't need CMake. But it's unmaintainable. We produce graphical tools, so we have plenty of resources that need to be embedded in the programs.. But we don't have a pipeline set up with make dependencies. You could fiddle with such a system until it worked. But it would fall over at the slightest stress. > >> > >>> Of course I could put in a flexible format specifier. But it would rapidly turn into > >>> a scripting laugage in its onw right. In which case you might as well use Python. > >> > >> Indeed. You program already looks like that. > >> > > No it doesn't. There's a very simple xml list of resources, and one or two attributes > > to control the output. It's nothing like a script. However to be fair I do suggest diving > > into the source if you want to customise it. The users will be C programmers, after > > all. > >>> > >>> There is an "international" tag so you can do this > >>> <international name = "hello"> > >>> <string language = "english">Hello</string> > >>> <string language = "french">Bonjour</string> > >>> <utf8 language = "chinese"> [utf8 here] </utf8> > >>> </international> > >>> > >>> Then it creates a C-callable function which is passed the languafe and returns > >>> thr right string. > >>> > >> > >> That's a horrendous interface for everyone involved. It is hideous for > >> the programmer writing the XML (like all XML is). It is terrible for > >> the translators, who want to work with strings in the common language > >> (usually English) and their own language. It is horrible to use in the > >> application code. It would be a mess to maintain in source code > >> repositories. > >> > >> Seriously, I'm not sure how you could make it worse. Perhaps you could > >> insist that the translation strings are all held in a MS Excel format > >> spreadsheet? > >> > >> Did you even think about how people were supposed to use it, or how > >> international programs are developed? > >> > > You might be right about that. We considered internationalisation at > > work (we make tools for artists), but the customers said they were > > happy with English, and it was such a bag of worms that we rejected > > the idea. So I've no experience. Part of the reason for discussing it here > > is that other people might have such experience. > Just think about it a little. You know a language or two other than > English - put yourself in the position of a translator who does not > understand C and is not a programmer. Would you want to face that XML crap? > > You can't really support Unicode but not support internationalisation, > > however. > Of course you can. It is only the opposite that will cause you > difficulties. > Baby X is mainly for small hobby type programs. It's easier to use than the raw X11 interface, and it's far lighter weight than Qt or GTK. It also ports to Windows. So most of the users will be bedroom programmers who will set up the internationalisation strings themselves, rather than employing professional translators. As I said, if as a side effect the Baby X resource compiler is useful to non-Baby X porgrammers, then that's great. But the focus is on having a good tool which will help unleash the potential of Baby X. But for version 1.3 I could well shift focus to meeting the needs of non- Baby X programmers. I know that more people download the resource compiler than download Baby X, which suggest that there is a need there. And whilst there are competitors to Baby X, there isn't a close competitor to the resource compiler which I have seen.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2023-08-08 17:53 +0000 |
| Message-ID | <fivAM.481172$SuUf.145293@fx14.iad> |
| In reply to | #171864 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: >On Tuesday, 8 August 2023 at 17:46:15 UTC+1, David Brown wrote: >> On 08/08/2023 18:04, Malcolm McLean wrote: >> > On Tuesday, 8 August 2023 at 16:18:49 UTC+1, David Brown wrote: >> >> On 05/08/2023 14:08, Malcolm McLean wrote: >> >> >> >>> This is the problem of course. The Baby X API expects data in a certain format. >> >>> So all the API functions which operate on images take a 32 bit RGBA buffer >> >>> as an "unsigned char *", and the dimensions as two ints. But another API might >> >>> use an opaque "IMAGE" structure. Or another system might have 16 bit r5g5b5a1 >> >>> images. >> >> >> >> It would make a lot of sense to have a program that took data in common >> >> standardised uncompressed forms (like .wav, .bmp) and generated data in >> >> whatever format suits Baby X. >> >> >> > "Data" means, "that which is given". People programming applications are given >> > resources in many formats. They might steal a PNG from the web, get a JPEG >> > commissioned from a paid artist, knock up their own SVG. >> > Now of course it's possible to convert all these into a common format like PNG >> > which is powerful enough to hold all thse formats without loss. But you've lost >> > the link with the original data. So when the artist comes back with a second >> > version of the JPEG, you've got to run ImageMagick again. And I don't have >> > ImageMagick installed on the Mac I'm writing this on (there's a program called >> > sips which does similar things). >> > A resouce pipeline with lots of stages, each one requiring a separate third party >> > program, is quite fragile. It works for as long as your Linux machine is all set up >> > with the dependencies, which will be the case for the duration of the project. >> > But if you archive it, and dust it off years later, will things still be intact? And >> > will you know which are the intermediate files, and which are the original data? >> It looks like there is someone else in this group who could benefit from >> understanding "make" and/or other build tools. And if you can't use a >> Mac for development, scrap the expensive toy and install a usable >> system. (Of course, you /can/ use a Mac for development - you just need >> to know how to use your tools.) >> >Bart's right about make. If it actually worked properly we wouldn't need CMake. >But it's unmaintainable. To you, perhaps. Probably because you don't understand it. The linux kernel is but one large application that uses make, and it works well, and is quite maintainable. Far more so that CMake which still suffers from portability issues (i.e. it's not always available). > We produce graphical tools, so we have plenty of >resources that need to be embedded in the programs.. But we don't have a >pipeline set up with make dependencies. You could fiddle with such a system until >it worked. But it would fall over at the slightest stress. That's not been my experience with make (several operating systems, hypervisors, SoC simulators, large internal webservers, certification authority production certificate generation systems (Verisign) et. alia.). Properly designed makefiles are a joy to work with.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-08-09 10:41 +0200 |
| Message-ID | <uavjga$3s9cs$1@dont-email.me> |
| In reply to | #171872 |
On 08/08/2023 19:53, Scott Lurndal wrote: > Properly designed makefiles are a joy > to work with. > They are a joy to work with, yes. But they can be less joyful to write sometimes, and debugging is rarely easy. However, you rarely have to write them in practice - usually for a new project, I take an existing makefile (or set of makefiles) and change details such as project name, compiler, flags, etc., and we are off. I am not sure if I have started a new makefile from scratch since my first one many decades ago!
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-08-08 18:55 +0000 |
| Message-ID | <20230808112450.213@kylheku.com> |
| In reply to | #171864 |
On 2023-08-08, Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote: > Bart's right about make. If it actually worked properly we wouldn't > need CMake. But, firstly, CMake doesn't do away with make; it generates Makefiles! Make implementations like GNU Make are of a lot better quality and better at doing what they are designed to than CMake is at doing its job. It's a poor design with a poor input language. That doesn't mean you can easily replace what it does with Make; that's not the argument. But you definitely should replace what it does with something else. Frankly, I'd rather separately maintain a .BAT file and a .sh file to build some C or C++ code on Windows and Unix, as a sequence of boiler-plate compiler commands, than use CMake.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-08-09 00:26 +0200 |
| Message-ID | <uaufeh$3iq7v$1@dont-email.me> |
| In reply to | #171864 |
On 08/08/2023 19:04, Malcolm McLean wrote:
> On Tuesday, 8 August 2023 at 17:46:15 UTC+1, David Brown wrote:
>> On 08/08/2023 18:04, Malcolm McLean wrote:
>>> On Tuesday, 8 August 2023 at 16:18:49 UTC+1, David Brown wrote:
>>>> On 05/08/2023 14:08, Malcolm McLean wrote:
>>>>
>>>>> This is the problem of course. The Baby X API expects data in a certain format.
>>>>> So all the API functions which operate on images take a 32 bit RGBA buffer
>>>>> as an "unsigned char *", and the dimensions as two ints. But another API might
>>>>> use an opaque "IMAGE" structure. Or another system might have 16 bit r5g5b5a1
>>>>> images.
>>>>
>>>> It would make a lot of sense to have a program that took data in common
>>>> standardised uncompressed forms (like .wav, .bmp) and generated data in
>>>> whatever format suits Baby X.
>>>>
>>> "Data" means, "that which is given". People programming applications are given
>>> resources in many formats. They might steal a PNG from the web, get a JPEG
>>> commissioned from a paid artist, knock up their own SVG.
>>> Now of course it's possible to convert all these into a common format like PNG
>>> which is powerful enough to hold all thse formats without loss. But you've lost
>>> the link with the original data. So when the artist comes back with a second
>>> version of the JPEG, you've got to run ImageMagick again. And I don't have
>>> ImageMagick installed on the Mac I'm writing this on (there's a program called
>>> sips which does similar things).
>>> A resouce pipeline with lots of stages, each one requiring a separate third party
>>> program, is quite fragile. It works for as long as your Linux machine is all set up
>>> with the dependencies, which will be the case for the duration of the project.
>>> But if you archive it, and dust it off years later, will things still be intact? And
>>> will you know which are the intermediate files, and which are the original data?
>> It looks like there is someone else in this group who could benefit from
>> understanding "make" and/or other build tools. And if you can't use a
>> Mac for development, scrap the expensive toy and install a usable
>> system. (Of course, you /can/ use a Mac for development - you just need
>> to know how to use your tools.)
>>
> Bart's right about make. If it actually worked properly we wouldn't need CMake.
"make" works perfectly well for its purpose. CMake is a different tool,
doing a different job. In fact, CMake generates makefiles for use by
"make" (as well as project files for MSVC, and other types of build
system). CMake is a higher level tool. ("make" can, in combination
with compilers like gcc, do a fair amount of higher level work as well,
such as tracking dependencies and files automatically.)
One thing that "make" is particularly good at is chains of processes.
It is straightforward to say that "picture.o" is compiled from
"picture.c" which is resource-compiled from "picture.bmp" which is
converted from "picture.jpg". I sometimes have that kind of thing in
makefiles for building documentation, where the graphics files I want to
add to my LaTeX documents might need conversions or manipulations from
the originals.
> But it's unmaintainable.
Not for people who are familiar with it.
Certainly complicated makefiles are harder to deal with than simple
ones. It's a powerful tool with many features, and takes time and
effort to learn. But complicated ones can reduce maintenance - my
makefiles do not need modification as files are added or removed from a
project, or dependencies on headers change - it is all handled
automatically.
> We produce graphical tools, so we have plenty of
> resources that need to be embedded in the programs.. But we don't have a
> pipeline set up with make dependencies. You could fiddle with such a system until
> it worked. But it would fall over at the slightest stress.
No, you are simply wrong here. The fact that you are unqualified to
develop advanced makefiles, and unfamiliar with the tool's capabilities,
does not make it fragile.
>>> You might be right about that. We considered internationalisation at
>>> work (we make tools for artists), but the customers said they were
>>> happy with English, and it was such a bag of worms that we rejected
>>> the idea. So I've no experience. Part of the reason for discussing it here
>>> is that other people might have such experience.
>> Just think about it a little. You know a language or two other than
>> English - put yourself in the position of a translator who does not
>> understand C and is not a programmer. Would you want to face that XML crap?
>>> You can't really support Unicode but not support internationalisation,
>>> however.
>> Of course you can. It is only the opposite that will cause you
>> difficulties.
>>
> Baby X is mainly for small hobby type programs. It's easier to use than
> the raw X11 interface, and it's far lighter weight than Qt or GTK. It also
> ports to Windows. So most of the users will be bedroom programmers
> who will set up the internationalisation strings themselves, rather than
> employing professional translators.
That is a hopeless attitude to take. You are simply guaranteeing that
people will not use it for internationalisation - or that they will hate
the tool when they try to use it. Targeting hobby users is not an
excuse for bad design. I would suggest you remove all traces of
internationalisation until you have found a way to make it work. (And
drop the XML format while you are at it - a simple one line, one command
text format would be vastly easier for everyone.)
> As I said, if as a side effect the Baby X resource compiler is useful to
> non-Baby X porgrammers, then that's great. But the focus is on having
> a good tool which will help unleash the potential of Baby X.
>
> But for version 1.3 I could well shift focus to meeting the needs of non-
> Baby X programmers. I know that more people download the resource
> compiler than download Baby X, which suggest that there is a need there.
>
> And whilst there are competitors to Baby X, there isn't a close competitor
> to the resource compiler which I have seen.
>
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-08-08 16:51 -0700 |
| Message-ID | <87ttt9ozys.fsf@nosuchdomain.example.com> |
| In reply to | #171884 |
David Brown <david.brown@hesbynett.no> writes:
[...]
> That is a hopeless attitude to take. You are simply guaranteeing that
> people will not use it for internationalisation - or that they will
> hate the tool when they try to use it. Targeting hobby users is not
> an excuse for bad design. I would suggest you remove all traces of
> internationalisation until you have found a way to make it work. (And
> drop the XML format while you are at it - a simple one line, one
> command text format would be vastly easier for everyone.)
[...]
If you're going to do internationalization, I suggest using some
standard format to store the messages.
GNU gettext uses a plain-text ".po" format.
There's also an ISO standard format called XLIFF which is, for
better or worse, XML-based.
https://en.wikipedia.org/wiki/XLIFF
XLIFF is probably used widely enough that there are tools that let
users treat the XML files as opaque binaries.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2023-08-08 20:23 -0700 |
| Message-ID | <169226c1-5531-4ea1-856b-f46ad0aeaf43n@googlegroups.com> |
| In reply to | #171884 |
On Tuesday, 8 August 2023 at 23:26:47 UTC+1, David Brown wrote:
> On 08/08/2023 19:04, Malcolm McLean wrote:
> > On Tuesday, 8 August 2023 at 17:46:15 UTC+1, David Brown wrote:
> >> On 08/08/2023 18:04, Malcolm McLean wrote:
> >>> On Tuesday, 8 August 2023 at 16:18:49 UTC+1, David Brown wrote:
> >>>> On 05/08/2023 14:08, Malcolm McLean wrote:
> >>>>
> >>>>> This is the problem of course. The Baby X API expects data in a certain format.
> >>>>> So all the API functions which operate on images take a 32 bit RGBA buffer
> >>>>> as an "unsigned char *", and the dimensions as two ints. But another API might
> >>>>> use an opaque "IMAGE" structure. Or another system might have 16 bit r5g5b5a1
> >>>>> images.
> >>>>
> >>>> It would make a lot of sense to have a program that took data in common
> >>>> standardised uncompressed forms (like .wav, .bmp) and generated data in
> >>>> whatever format suits Baby X.
> >>>>
> >>> "Data" means, "that which is given". People programming applications are given
> >>> resources in many formats. They might steal a PNG from the web, get a JPEG
> >>> commissioned from a paid artist, knock up their own SVG.
> >>> Now of course it's possible to convert all these into a common format like PNG
> >>> which is powerful enough to hold all thse formats without loss. But you've lost
> >>> the link with the original data. So when the artist comes back with a second
> >>> version of the JPEG, you've got to run ImageMagick again. And I don't have
> >>> ImageMagick installed on the Mac I'm writing this on (there's a program called
> >>> sips which does similar things).
> >>> A resouce pipeline with lots of stages, each one requiring a separate third party
> >>> program, is quite fragile. It works for as long as your Linux machine is all set up
> >>> with the dependencies, which will be the case for the duration of the project.
> >>> But if you archive it, and dust it off years later, will things still be intact? And
> >>> will you know which are the intermediate files, and which are the original data?
> >> It looks like there is someone else in this group who could benefit from
> >> understanding "make" and/or other build tools. And if you can't use a
> >> Mac for development, scrap the expensive toy and install a usable
> >> system. (Of course, you /can/ use a Mac for development - you just need
> >> to know how to use your tools.)
> >>
> > Bart's right about make. If it actually worked properly we wouldn't need CMake.
> "make" works perfectly well for its purpose. CMake is a different tool,
> doing a different job. In fact, CMake generates makefiles for use by
> "make" (as well as project files for MSVC, and other types of build
> system). CMake is a higher level tool. ("make" can, in combination
> with compilers like gcc, do a fair amount of higher level work as well,
> such as tracking dependencies and files automatically.)
>
CMake is an alternative to make. It can generate make files, in fact that's the
default. Which means that if you ship a project with a CMake script, you
wouldn't normally provide a make file. CMake found a niche largely because
make files are too difficult to use. The other reason is that the big IDEs
rejected makefiles as their format for describing how to build projects.
>
> One thing that "make" is particularly good at is chains of processes.
> It is straightforward to say that "picture.o" is compiled from
> "picture.c" which is resource-compiled from "picture.bmp" which is
> converted from "picture.jpg". I sometimes have that kind of thing in
> makefiles for building documentation, where the graphics files I want to
> add to my LaTeX documents might need conversions or manipulations from
> the originals.
>
> > But it's unmaintainable.
>
> Not for people who are familiar with it.
>
Many programmers might start a new project only once every two years. And
it might not be their job to write the makefile. So they are not going to be very
familiar with make. Maintainable software needs to be maintainable by people
who don't have a deep familarity with it. I can debug Cmake scripts despite
not really knowing the CMake language, because it's close enough to a normal
procedural programming language for someone who can program but doesn't
know CMake specifically to follow along.
>
> Certainly complicated makefiles are harder to deal with than simple
> ones. It's a powerful tool with many features, and takes time and
> effort to learn. But complicated ones can reduce maintenance - my
> makefiles do not need modification as files are added or removed from a
> project, or dependencies on headers change - it is all handled
> automatically.
>
> > Baby X is mainly for small hobby type programs. It's easier to use than
> > the raw X11 interface, and it's far lighter weight than Qt or GTK. It also
> > ports to Windows. So most of the users will be bedroom programmers
> > who will set up the internationalisation strings themselves, rather than
> > employing professional translators.
> That is a hopeless attitude to take. You are simply guaranteeing that
> people will not use it for internationalisation - or that they will hate
> the tool when they try to use it. Targeting hobby users is not an
> excuse for bad design. I would suggest you remove all traces of
> internationalisation until you have found a way to make it work. (And
> drop the XML format while you are at it - a simple one line, one command
> text format would be vastly easier for everyone.)
>
It works. The question is whether it's a good approach to the problem.
As I said, the user of Baby X will be mostly hobby programmers. So the
emphasis is on making things easy to use. Adding alternative translations
under an <international> tag is easy to do.
However I fully accept that there might be a far better approach. Keith
Thompson has made some constructive suggestions.
XML has some advantages over an ad-hoc line-based format. The parser needs
work as it's currently too basic. But XML should be familiar to most programmers.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-08-09 13:42 +0200 |
| Message-ID | <uavu3s$3tr9o$1@dont-email.me> |
| In reply to | #171908 |
On 09/08/2023 05:23, Malcolm McLean wrote:
> On Tuesday, 8 August 2023 at 23:26:47 UTC+1, David Brown wrote:
>> On 08/08/2023 19:04, Malcolm McLean wrote:
>>> On Tuesday, 8 August 2023 at 17:46:15 UTC+1, David Brown wrote:
>>>> On 08/08/2023 18:04, Malcolm McLean wrote:
>>>>> On Tuesday, 8 August 2023 at 16:18:49 UTC+1, David Brown wrote:
>>>>>> On 05/08/2023 14:08, Malcolm McLean wrote:
>>>>>>
>>>>>>> This is the problem of course. The Baby X API expects data in a certain format.
>>>>>>> So all the API functions which operate on images take a 32 bit RGBA buffer
>>>>>>> as an "unsigned char *", and the dimensions as two ints. But another API might
>>>>>>> use an opaque "IMAGE" structure. Or another system might have 16 bit r5g5b5a1
>>>>>>> images.
>>>>>>
>>>>>> It would make a lot of sense to have a program that took data in common
>>>>>> standardised uncompressed forms (like .wav, .bmp) and generated data in
>>>>>> whatever format suits Baby X.
>>>>>>
>>>>> "Data" means, "that which is given". People programming applications are given
>>>>> resources in many formats. They might steal a PNG from the web, get a JPEG
>>>>> commissioned from a paid artist, knock up their own SVG.
>>>>> Now of course it's possible to convert all these into a common format like PNG
>>>>> which is powerful enough to hold all thse formats without loss. But you've lost
>>>>> the link with the original data. So when the artist comes back with a second
>>>>> version of the JPEG, you've got to run ImageMagick again. And I don't have
>>>>> ImageMagick installed on the Mac I'm writing this on (there's a program called
>>>>> sips which does similar things).
>>>>> A resouce pipeline with lots of stages, each one requiring a separate third party
>>>>> program, is quite fragile. It works for as long as your Linux machine is all set up
>>>>> with the dependencies, which will be the case for the duration of the project.
>>>>> But if you archive it, and dust it off years later, will things still be intact? And
>>>>> will you know which are the intermediate files, and which are the original data?
>>>> It looks like there is someone else in this group who could benefit from
>>>> understanding "make" and/or other build tools. And if you can't use a
>>>> Mac for development, scrap the expensive toy and install a usable
>>>> system. (Of course, you /can/ use a Mac for development - you just need
>>>> to know how to use your tools.)
>>>>
>>> Bart's right about make. If it actually worked properly we wouldn't need CMake.
>> "make" works perfectly well for its purpose. CMake is a different tool,
>> doing a different job. In fact, CMake generates makefiles for use by
>> "make" (as well as project files for MSVC, and other types of build
>> system). CMake is a higher level tool. ("make" can, in combination
>> with compilers like gcc, do a fair amount of higher level work as well,
>> such as tracking dependencies and files automatically.)
>>
> CMake is an alternative to make.
It is a "meta-build" tool, aimed at a higher level than make, and which
generates scripts or control files for various uses - makefiles, MSVC
project files, and others. For some kinds of project, that might be a
good choice - sometimes it makes sense to separate the tasks of
calculating dependencies and settings, and actually controlling the
build. But since on many platforms CMake depends on make, it is not an
alternative. And CMake is not flexible enough for many uses - when I
have looked at it, it was not remotely flexible enough to do the kinds
of things I do with make. Many people use CMake, so it must have
merits, but it is not a replacement for make.
> It can generate make files, in fact that's the
> default. Which means that if you ship a project with a CMake script, you
> wouldn't normally provide a make file. CMake found a niche largely because
> make files are too difficult to use. The other reason is that the big IDEs
> rejected makefiles as their format for describing how to build projects.
Every IDE of any quality can handle projects that are built using
external makefiles. An IDE that won't run "make" at the press of a
hotkey is as useful as an IDE that can't handle ASCII format test files.
But if you have an external manually written makefile, that is not
project management - so usually you also then have to make an IDE
project to describe the source files, include search paths, pre-defined
macros, etc. That can be a duplicate of work (though good makefiles
find the source files and dependencies mostly automatically), and
duplication can lead to mistakes.
The norm AFIK for build systems controlled by IDEs is make - they
generate makefiles automatically based on your project settings, dialog
boxes for choosing compiler flags, etc. Such systems can work
reasonably well, though a well-made manual makefile is often much better
at calculating dependency information for large projects.
Some IDEs may generate CMake files, then run CMake, then make - I have
(unsurprisingly) not used all IDEs.
CMake, as far as I understand it, is popular when you want a project to
build on Linux with gcc and Windows with MSVC - that is its niche.
>>
>> One thing that "make" is particularly good at is chains of processes.
>> It is straightforward to say that "picture.o" is compiled from
>> "picture.c" which is resource-compiled from "picture.bmp" which is
>> converted from "picture.jpg". I sometimes have that kind of thing in
>> makefiles for building documentation, where the graphics files I want to
>> add to my LaTeX documents might need conversions or manipulations from
>> the originals.
>>
>>> But it's unmaintainable.
>>
>> Not for people who are familiar with it.
>>
> Many programmers might start a new project only once every two years. And
> it might not be their job to write the makefile. So they are not going to be very
> familiar with make. Maintainable software needs to be maintainable by people
> who don't have a deep familarity with it. I can debug Cmake scripts despite
> not really knowing the CMake language, because it's close enough to a normal
> procedural programming language for someone who can program but doesn't
> know CMake specifically to follow along.
People need to know how to use their tools. Within any development
group, you need people who can handle the different parts of the
development process. Sometimes people can do it all, sometimes there
are specialists in the group. So someone might be an expert at git,
someone at make, different programmers can handle different languages,
and others are good at design, documentation, testing, and all the other
aspects of software development. Anyone who thinks that "understands C"
is the be-all and end-all of making and maintaining a software project
in C is doomed to failure.
So if you are part of a development team, and your team is rejecting
"make" on the basis of "it's too hard to understand", your development
team is in a /lot/ of trouble. New management - or at least training
for the management - should be number one priority until the job is run
by people that understand about using the best tools for the job, and
training people in the jobs that need done. (Of course, if CMake really
is a better choice for your project, that's fine - make is not the only
tool in the box.)
>>
>> Certainly complicated makefiles are harder to deal with than simple
>> ones. It's a powerful tool with many features, and takes time and
>> effort to learn. But complicated ones can reduce maintenance - my
>> makefiles do not need modification as files are added or removed from a
>> project, or dependencies on headers change - it is all handled
>> automatically.
>>
>>> Baby X is mainly for small hobby type programs. It's easier to use than
>>> the raw X11 interface, and it's far lighter weight than Qt or GTK. It also
>>> ports to Windows. So most of the users will be bedroom programmers
>>> who will set up the internationalisation strings themselves, rather than
>>> employing professional translators.
>> That is a hopeless attitude to take. You are simply guaranteeing that
>> people will not use it for internationalisation - or that they will hate
>> the tool when they try to use it. Targeting hobby users is not an
>> excuse for bad design. I would suggest you remove all traces of
>> internationalisation until you have found a way to make it work. (And
>> drop the XML format while you are at it - a simple one line, one command
>> text format would be vastly easier for everyone.)
>>
> It works.
Your evidence for that is ... what? You need users and feedback to
establish that. And maybe your XML is turning away potential users - it
would turn me away, certainly.
> The question is whether it's a good approach to the problem.
Indeed. (My criticism here is intended as constructive, to suggest
better choices.)
> As I said, the user of Baby X will be mostly hobby programmers.
If your description of it is accurate, why are you limiting it like
that? Many professional developers would like better simple
cross-platform gui tools and toolkits. And if it is not better than
existing options, why bother with it at all? The only time it makes
sense to target hobby users alone is if the existing alternatives are
hugely complex, or hugely expensive, and that is not the case here.
Professionals also like "easy to use".
> So the
> emphasis is on making things easy to use. Adding alternative translations
> under an <international> tag is easy to do.
>
No, the translation system is /not/ easy to use, and horrendous to maintain.
Look, imagine a developer wanted French and German translations. It's
just a single programmer, but he has a couple of friends who speak those
languages. With your solution, these two friends are mixing and editing
the same file, at the same time, while the programmer is simultaneously
modifying the file for other purposes. It is absolute madness. Do you
not understand that the French translations need to go in one file, and
the German translations need to go in a different file, and there is
/no/ circumstances in which it is a good idea to mix them all together
in one horrible XML file?
Anyone trying to use your tool for something more than a "Hello world"
program will write their own pre-processor to generate your XML file!
> However I fully accept that there might be a far better approach. Keith
> Thompson has made some constructive suggestions.
>
Yes - when standard formats and tools exist, use them.
> XML has some advantages over an ad-hoc line-based format. The parser needs
> work as it's currently too basic. But XML should be familiar to most programmers.
>
XML is familiar as a concept of hatred by most programmers - something
forced upon them by clueless management and marketing people who think
it is a great buzzword. Almost nobody chooses XML voluntarily.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2023-08-09 05:32 -0700 |
| Message-ID | <8cbfec99-99db-4b7f-aed4-a5f2dc6f89ben@googlegroups.com> |
| In reply to | #171926 |
On Wednesday, 9 August 2023 at 12:43:06 UTC+1, David Brown wrote: > On 09/08/2023 05:23, Malcolm McLean wrote: > > > CMake is an alternative to make. > It is a "meta-build" tool, aimed at a higher level than make, and which > generates scripts or control files for various uses - makefiles, MSVC > project files, and others. For some kinds of project, that might be a > good choice - sometimes it makes sense to separate the tasks of > calculating dependencies and settings, and actually controlling the > build. But since on many platforms CMake depends on make, it is not an > alternative. And CMake is not flexible enough for many uses - when I > have looked at it, it was not remotely flexible enough to do the kinds > of things I do with make. Many people use CMake, so it must have > merits, but it is not a replacement for make. > CMake has a "generator", which is their word for target output format. So you can use it to generate Xcode or Visual Studio files, or make files. The two big advantages are that you don't have to ship an Xcode or Visual Studio project file. CMake generates it for your client. And the Cmkae scripts are easier to read and maintain than makefiles. > > It can generate make files, in fact that's the > > default. Which means that if you ship a project with a CMake script, you > > wouldn't normally provide a make file. CMake found a niche largely because > > make files are too difficult to use. The other reason is that the big IDEs > > rejected makefiles as their format for describing how to build projects. > Every IDE of any quality can handle projects that are built using > external makefiles. An IDE that won't run "make" at the press of a > hotkey is as useful as an IDE that can't handle ASCII format test files. > > But if you have an external manually written makefile, that is not > project management - so usually you also then have to make an IDE > project to describe the source files, include search paths, pre-defined > macros, etc. That can be a duplicate of work (though good makefiles > find the source files and dependencies mostly automatically), and > duplication can lead to mistakes. > My point is that when the first IDEs came out, they could have said "the project description file will be a makefile, maybe with added comments to represent information needed by the iDE but not by the compiler". They opted not to do this. > > The norm AFIK for build systems controlled by IDEs is make - they > generate makefiles automatically based on your project settings, dialog > boxes for choosing compiler flags, etc. Such systems can work > reasonably well, though a well-made manual makefile is often much better > at calculating dependency information for large projects. > There's a big difference between automatic scripts and ones written by humans. If something goes wrong with the automatic script, whilst a human programmer might have to look at it, basically the problem is almost certainly in the program which generated the script. So it doesn't matter too much if the script is unreadable. As long as the generating program is well-structured and debuggable. > > Some IDEs may generate CMake files, then run CMake, then make - I have > (unsurprisingly) not used all IDEs. > > CMake, as far as I understand it, is popular when you want a project to > build on Linux with gcc and Windows with MSVC - that is its niche. > Which is exactly Baby X. > > So if you are part of a development team, and your team is rejecting > "make" on the basis of "it's too hard to understand", your development > team is in a /lot/ of trouble. New management - or at least training > for the management - should be number one priority until the job is run > by people that understand about using the best tools for the job, and > training people in the jobs that need done. (Of course, if CMake really > is a better choice for your project, that's fine - make is not the only > tool in the box.) > I don't think you understand how you come over sometimes. No one at work wants to use make for managing resources. You don't know better than we do how to set up our development process. > > > It works. > Your evidence for that is ... what? You need users and feedback to > establish that. And maybe your XML is turning away potential users - it > would turn me away, certainly. > I've written a test program which internationises a string. So the system works from a narrow technical point of view. The question is about the softer considerations of what people actually want to use. > > The question is whether it's a good approach to the problem. > Indeed. (My criticism here is intended as constructive, to suggest > better choices.) > > As I said, the user of Baby X will be mostly hobby programmers. > If your description of it is accurate, why are you limiting it like > that? Many professional developers would like better simple > cross-platform gui tools and toolkits. And if it is not better than > existing options, why bother with it at all? The only time it makes > sense to target hobby users alone is if the existing alternatives are > hugely complex, or hugely expensive, and that is not the case here. > Professionals also like "easy to use". > We use Qt for one of our products. Not one that I work on personally. But one of the developers told me that he had had a 12 hour build. Of course the Qt product is super polished, and he is being paid for those twelve hours. So it's worth it for us. But for hobby programming it's probably not. Baby X will build in a few seconds. > > So the > > emphasis is on making things easy to use. Adding alternative translations > > under an <international> tag is easy to do. > > > No, the translation system is /not/ easy to use, and horrendous to maintain. > > Look, imagine a developer wanted French and German translations. It's > just a single programmer, but he has a couple of friends who speak those > languages. With your solution, these two friends are mixing and editing > the same file, at the same time, while the programmer is simultaneously > modifying the file for other purposes. It is absolute madness. Do you > not understand that the French translations need to go in one file, and > the German translations need to go in a different file, and there is > /no/ circumstances in which it is a good idea to mix them all together > in one horrible XML file? > Yes but think of someone who lives inFrance, and speaks French as his native language and English as a second language, but no others. He'll like the idea that he can toggle his Baby X program between English and French. But he can't afford to send off the strings to a professional translator to get in other languages. For him, the system as it stands is ideal (I think, I'm open to suggestions). > > Anyone trying to use your tool for something more than a "Hello world" > program will write their own pre-processor to generate your XML file! > That would be a disaster and destroy the main point of the resource compiler. However no such program can support every type of processing you might need. It can resize images, but not do gamma correction, for example. > > > However I fully accept that there might be a far better approach. Keith > > Thompson has made some constructive suggestions. > > > Yes - when standard formats and tools exist, use them. > > XML has some advantages over an ad-hoc line-based format. The parser needs > > work as it's currently too basic. But XML should be familiar to most programmers. > > > XML is familiar as a concept of hatred by most programmers - something > forced upon them by clueless management and marketing people who think > it is a great buzzword. Almost nobody chooses XML voluntarily. > Ah, so you are a Bart. But XML rather than C is the target of ire. In my view, XML is ideal for a resource compiler script format.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-08-15 13:00 +0200 |
| Message-ID | <ubflst$2ptu0$1@dont-email.me> |
| In reply to | #171930 |
On 09/08/2023 14:32, Malcolm McLean wrote: > On Wednesday, 9 August 2023 at 12:43:06 UTC+1, David Brown wrote: >> On 09/08/2023 05:23, Malcolm McLean wrote: >> >>> CMake is an alternative to make. >> It is a "meta-build" tool, aimed at a higher level than make, and which >> generates scripts or control files for various uses - makefiles, MSVC >> project files, and others. For some kinds of project, that might be a >> good choice - sometimes it makes sense to separate the tasks of >> calculating dependencies and settings, and actually controlling the >> build. But since on many platforms CMake depends on make, it is not an >> alternative. And CMake is not flexible enough for many uses - when I >> have looked at it, it was not remotely flexible enough to do the kinds >> of things I do with make. Many people use CMake, so it must have >> merits, but it is not a replacement for make. >> > CMake has a "generator", which is their word for target output format. > So you can use it to generate Xcode or Visual Studio files, or make files. > The two big advantages are that you don't have to ship an Xcode or > Visual Studio project file. CMake generates it for your client. And the > Cmkae scripts are easier to read and maintain than makefiles. It is inaccurate to say "CMake /has/ a generator" - it is better to say it /is/ a generator. Apart from that, you have basically repeated what I wrote. >>> It can generate make files, in fact that's the >>> default. Which means that if you ship a project with a CMake script, you >>> wouldn't normally provide a make file. CMake found a niche largely because >>> make files are too difficult to use. The other reason is that the big IDEs >>> rejected makefiles as their format for describing how to build projects. >> Every IDE of any quality can handle projects that are built using >> external makefiles. An IDE that won't run "make" at the press of a >> hotkey is as useful as an IDE that can't handle ASCII format test files. >> >> But if you have an external manually written makefile, that is not >> project management - so usually you also then have to make an IDE >> project to describe the source files, include search paths, pre-defined >> macros, etc. That can be a duplicate of work (though good makefiles >> find the source files and dependencies mostly automatically), and >> duplication can lead to mistakes. >> > My point is that when the first IDEs came out, they could have said "the project > description file will be a makefile, maybe with added comments to represent > information needed by the iDE but not by the compiler". They opted not to > do this. IDE's need all kinds of things in the project management that are irrelevant to the build process, and therefore unsuitable for storing in a makefile. And makefiles can have all sorts of things that are difficult for something like an IDE to interpret - they are far too flexible. So "project description files" are IDE-specific, and IDE's could not possibly use makefiles for the purpose. CMake files are less flexible than makefiles, but are equally unsuitable for IDE project management. >> >> The norm AFIK for build systems controlled by IDEs is make - they >> generate makefiles automatically based on your project settings, dialog >> boxes for choosing compiler flags, etc. Such systems can work >> reasonably well, though a well-made manual makefile is often much better >> at calculating dependency information for large projects. >> > There's a big difference between automatic scripts and ones written by humans. > If something goes wrong with the automatic script, whilst a human programmer > might have to look at it, basically the problem is almost certainly in the program > which generated the script. So it doesn't matter too much if the script is > unreadable. As long as the generating program is well-structured and > debuggable. That's all true, but I don't see the relevance. >> >> Some IDEs may generate CMake files, then run CMake, then make - I have >> (unsurprisingly) not used all IDEs. >> >> CMake, as far as I understand it, is popular when you want a project to >> build on Linux with gcc and Windows with MSVC - that is its niche. >> > Which is exactly Baby X. CMake may be the best choice here - I don't contend that. The point of disagreement is the myth that make is claimed to be so hard to use that it must be avoided. >> >> So if you are part of a development team, and your team is rejecting >> "make" on the basis of "it's too hard to understand", your development >> team is in a /lot/ of trouble. New management - or at least training >> for the management - should be number one priority until the job is run >> by people that understand about using the best tools for the job, and >> training people in the jobs that need done. (Of course, if CMake really >> is a better choice for your project, that's fine - make is not the only >> tool in the box.) >> > I don't think you understand how you come over sometimes. > No one at work wants to use make for managing resources. You don't know > better than we do how to set up our development process. Read again what I wrote. If CMake is the right tool for your group, great. But if something else is the right tool - make or anything else - and your team is avoiding it because no one knows how to work it, then you have a /big/ problem. Project management involves investing in tool training and tool purchase (though in this case, the cost price is zero), balanced against the usefulness of the tool, how much time it saves in the future, how much easier it makes the work for the development team, and - perhaps most importantly - how it affects quality and reduces the risk of mistakes. I am not saying that "make" is the best build tool for your needs, because I don't know your needs - but I /am/ saying that if your team is not using the best build tool merely "because it is hard", you development processes and management need a good shake-up. (I have looked at CMake for our development uses - it is not suitable and can't do the job.) >> >>> It works. >> Your evidence for that is ... what? You need users and feedback to >> establish that. And maybe your XML is turning away potential users - it >> would turn me away, certainly. >> > I've written a test program which internationises a string. So the system works > from a narrow technical point of view. The question is about the softer > considerations of what people actually want to use. Yes. >>> The question is whether it's a good approach to the problem. >> Indeed. (My criticism here is intended as constructive, to suggest >> better choices.) >>> As I said, the user of Baby X will be mostly hobby programmers. >> If your description of it is accurate, why are you limiting it like >> that? Many professional developers would like better simple >> cross-platform gui tools and toolkits. And if it is not better than >> existing options, why bother with it at all? The only time it makes >> sense to target hobby users alone is if the existing alternatives are >> hugely complex, or hugely expensive, and that is not the case here. >> Professionals also like "easy to use". >> > We use Qt for one of our products. Not one that I work on personally. > But one of the developers told me that he had had a 12 hour build. > Of course the Qt product is super polished, and he is being paid for > those twelve hours. So it's worth it for us. But for hobby programming > it's probably not. Baby X will build in a few seconds. Qt is /big/. A 12 hour build sounds excessive (or perhaps you need new build servers), but long build times are not uncommon for large Qt projects. Presumably for this product, you are using a lot of Qt features, and need that toolkit. But for many professional projects, you don't need much - if Baby X has all that's needed, and is easy to use, then I would expect professional developers would pick it over Qt when a lighter toolkit is sufficient. >>> So the >>> emphasis is on making things easy to use. Adding alternative translations >>> under an <international> tag is easy to do. >>> >> No, the translation system is /not/ easy to use, and horrendous to maintain. >> >> Look, imagine a developer wanted French and German translations. It's >> just a single programmer, but he has a couple of friends who speak those >> languages. With your solution, these two friends are mixing and editing >> the same file, at the same time, while the programmer is simultaneously >> modifying the file for other purposes. It is absolute madness. Do you >> not understand that the French translations need to go in one file, and >> the German translations need to go in a different file, and there is >> /no/ circumstances in which it is a good idea to mix them all together >> in one horrible XML file? >> > Yes but think of someone who lives inFrance, and speaks French as his native > language and English as a second language, but no others. He'll like the idea > that he can toggle his Baby X program between English and French. But he > can't afford to send off the strings to a professional translator to get in > other languages. For him, the system as it stands is ideal (I think, I'm open > to suggestions). No, for him the system is hopeless. Completely hopeless. Compare this to a program using standard gettext() libraries and locale files. The enthusiastic French user who wants a French translation of your program can use the /binary/ of your program. He/she does not have to learn about building from scratch, or programming in C, or writing XML files, or mixing in French strings along with German strings and twenty other languages in a huge clump. He/she fires up poedit (familiar to many who have done software translation work), and has a useable interface for translating the strings from English to French. Then he/she can use your program in French. And they can send you the French translation to include for others - all without ever even knowing what programming language you are using. >> >> Anyone trying to use your tool for something more than a "Hello world" >> program will write their own pre-processor to generate your XML file! >> > That would be a disaster and destroy the main point of the resource compiler. But it is what would happen. > However no such program can support every type of processing you might need. Your resource compiler hasn't a hope in hell of supporting all the file types people might want. Their own pre-processor, however, /would/ support the file types /they/ want - such as converting whatever graphics format they actually use into whatever graphics format your program supports. > It can resize images, but not do gamma correction, for example. >> >>> However I fully accept that there might be a far better approach. Keith >>> Thompson has made some constructive suggestions. >>> >> Yes - when standard formats and tools exist, use them. >>> XML has some advantages over an ad-hoc line-based format. The parser needs >>> work as it's currently too basic. But XML should be familiar to most programmers. >>> >> XML is familiar as a concept of hatred by most programmers - something >> forced upon them by clueless management and marketing people who think >> it is a great buzzword. Almost nobody chooses XML voluntarily. >> > Ah, so you are a Bart. But XML rather than C is the target of ire. > In my view, XML is ideal for a resource compiler script format. XML is a massively verbose format. It can be okay as a machine-written format - it is popular for things like word processor document formats. It is also not a bad choice for very structured and hierarchical configuration files, such as those used by Apache. But for something like this, it is just horrible - everything is duplicated, the text is cramped (spaces in the wrong place cause trouble), you don't have comments, and lists, tuples, and fixed-format structures are excessively unpleasant to write. The actual information you want to read and write is smothered by the XML tags. Writing such XML files is a big effort, and highly error-prone. It's not even easy to parse in software (especially when you insist on using an unsuitable language for the task). You are entitled to your opinion, of course, but I would struggle to find a less pleasant (in /my/ view) format for the task.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2023-08-09 05:35 -0700 |
| Message-ID | <ee707a61-59a5-4f74-b443-341defe630fdn@googlegroups.com> |
| In reply to | #171926 |
On Wednesday, August 9, 2023 at 2:43:06 PM UTC+3, David Brown wrote:
> On 09/08/2023 05:23, Malcolm McLean wrote:
> > On Tuesday, 8 August 2023 at 23:26:47 UTC+1, David Brown wrote:
> >> On 08/08/2023 19:04, Malcolm McLean wrote:
> >>> On Tuesday, 8 August 2023 at 17:46:15 UTC+1, David Brown wrote:
> >>>> On 08/08/2023 18:04, Malcolm McLean wrote:
> >>>>> On Tuesday, 8 August 2023 at 16:18:49 UTC+1, David Brown wrote:
> >>>>>> On 05/08/2023 14:08, Malcolm McLean wrote:
> >>>>>>
> >>>>>>> This is the problem of course. The Baby X API expects data in a certain format.
> >>>>>>> So all the API functions which operate on images take a 32 bit RGBA buffer
> >>>>>>> as an "unsigned char *", and the dimensions as two ints. But another API might
> >>>>>>> use an opaque "IMAGE" structure. Or another system might have 16 bit r5g5b5a1
> >>>>>>> images.
> >>>>>>
> >>>>>> It would make a lot of sense to have a program that took data in common
> >>>>>> standardised uncompressed forms (like .wav, .bmp) and generated data in
> >>>>>> whatever format suits Baby X.
> >>>>>>
> >>>>> "Data" means, "that which is given". People programming applications are given
> >>>>> resources in many formats. They might steal a PNG from the web, get a JPEG
> >>>>> commissioned from a paid artist, knock up their own SVG.
> >>>>> Now of course it's possible to convert all these into a common format like PNG
> >>>>> which is powerful enough to hold all thse formats without loss. But you've lost
> >>>>> the link with the original data. So when the artist comes back with a second
> >>>>> version of the JPEG, you've got to run ImageMagick again. And I don't have
> >>>>> ImageMagick installed on the Mac I'm writing this on (there's a program called
> >>>>> sips which does similar things).
> >>>>> A resouce pipeline with lots of stages, each one requiring a separate third party
> >>>>> program, is quite fragile. It works for as long as your Linux machine is all set up
> >>>>> with the dependencies, which will be the case for the duration of the project.
> >>>>> But if you archive it, and dust it off years later, will things still be intact? And
> >>>>> will you know which are the intermediate files, and which are the original data?
> >>>> It looks like there is someone else in this group who could benefit from
> >>>> understanding "make" and/or other build tools. And if you can't use a
> >>>> Mac for development, scrap the expensive toy and install a usable
> >>>> system. (Of course, you /can/ use a Mac for development - you just need
> >>>> to know how to use your tools.)
> >>>>
> >>> Bart's right about make. If it actually worked properly we wouldn't need CMake.
> >> "make" works perfectly well for its purpose. CMake is a different tool,
> >> doing a different job. In fact, CMake generates makefiles for use by
> >> "make" (as well as project files for MSVC, and other types of build
> >> system). CMake is a higher level tool. ("make" can, in combination
> >> with compilers like gcc, do a fair amount of higher level work as well,
> >> such as tracking dependencies and files automatically.)
> >>
> > CMake is an alternative to make.
> It is a "meta-build" tool, aimed at a higher level than make, and which
> generates scripts or control files for various uses - makefiles, MSVC
> project files, and others. For some kinds of project, that might be a
> good choice - sometimes it makes sense to separate the tasks of
> calculating dependencies and settings, and actually controlling the
> build. But since on many platforms CMake depends on make, it is not an
> alternative. And CMake is not flexible enough for many uses - when I
> have looked at it, it was not remotely flexible enough to do the kinds
> of things I do with make. Many people use CMake, so it must have
> merits, but it is not a replacement for make.
> > It can generate make files, in fact that's the
> > default. Which means that if you ship a project with a CMake script, you
> > wouldn't normally provide a make file. CMake found a niche largely because
> > make files are too difficult to use. The other reason is that the big IDEs
> > rejected makefiles as their format for describing how to build projects.
> Every IDE of any quality can handle projects that are built using
> external makefiles. An IDE that won't run "make" at the press of a
> hotkey is as useful as an IDE that can't handle ASCII format test files.
>
> But if you have an external manually written makefile, that is not
> project management - so usually you also then have to make an IDE
> project to describe the source files, include search paths, pre-defined
> macros, etc. That can be a duplicate of work (though good makefiles
> find the source files and dependencies mostly automatically), and
> duplication can lead to mistakes.
>
No, simply no.
Good makefile finds "other" dependencies mostly automatically, but
makes no attempts to figure out source files.
> The norm AFIK for build systems controlled by IDEs is make - they
> generate makefiles automatically based on your project settings, dialog
> boxes for choosing compiler flags, etc. Such systems can work
> reasonably well, though a well-made manual makefile is often much better
> at calculating dependency information for large projects.
>
> Some IDEs may generate CMake files, then run CMake, then make - I have
> (unsurprisingly) not used all IDEs.
>
> CMake, as far as I understand it, is popular when you want a project to
> build on Linux with gcc and Windows with MSVC - that is its niche.
> >>
> >> One thing that "make" is particularly good at is chains of processes.
> >> It is straightforward to say that "picture.o" is compiled from
> >> "picture.c" which is resource-compiled from "picture.bmp" which is
> >> converted from "picture.jpg". I sometimes have that kind of thing in
> >> makefiles for building documentation, where the graphics files I want to
> >> add to my LaTeX documents might need conversions or manipulations from
> >> the originals.
> >>
> >>> But it's unmaintainable.
> >>
> >> Not for people who are familiar with it.
> >>
> > Many programmers might start a new project only once every two years. And
> > it might not be their job to write the makefile. So they are not going to be very
> > familiar with make. Maintainable software needs to be maintainable by people
> > who don't have a deep familarity with it. I can debug Cmake scripts despite
> > not really knowing the CMake language, because it's close enough to a normal
> > procedural programming language for someone who can program but doesn't
> > know CMake specifically to follow along.
> People need to know how to use their tools. Within any development
> group, you need people who can handle the different parts of the
> development process. Sometimes people can do it all, sometimes there
> are specialists in the group. So someone might be an expert at git,
> someone at make, different programmers can handle different languages,
> and others are good at design, documentation, testing, and all the other
> aspects of software development. Anyone who thinks that "understands C"
> is the be-all and end-all of making and maintaining a software project
> in C is doomed to failure.
>
> So if you are part of a development team, and your team is rejecting
> "make" on the basis of "it's too hard to understand", your development
> team is in a /lot/ of trouble. New management - or at least training
> for the management - should be number one priority until the job is run
> by people that understand about using the best tools for the job, and
> training people in the jobs that need done. (Of course, if CMake really
> is a better choice for your project, that's fine - make is not the only
> tool in the box.)
> >>
> >> Certainly complicated makefiles are harder to deal with than simple
> >> ones. It's a powerful tool with many features, and takes time and
> >> effort to learn. But complicated ones can reduce maintenance - my
> >> makefiles do not need modification as files are added or removed from a
> >> project, or dependencies on headers change - it is all handled
> >> automatically.
> >>
> >>> Baby X is mainly for small hobby type programs. It's easier to use than
> >>> the raw X11 interface, and it's far lighter weight than Qt or GTK. It also
> >>> ports to Windows. So most of the users will be bedroom programmers
> >>> who will set up the internationalisation strings themselves, rather than
> >>> employing professional translators.
> >> That is a hopeless attitude to take. You are simply guaranteeing that
> >> people will not use it for internationalisation - or that they will hate
> >> the tool when they try to use it. Targeting hobby users is not an
> >> excuse for bad design. I would suggest you remove all traces of
> >> internationalisation until you have found a way to make it work. (And
> >> drop the XML format while you are at it - a simple one line, one command
> >> text format would be vastly easier for everyone.)
> >>
> > It works.
> Your evidence for that is ... what? You need users and feedback to
> establish that. And maybe your XML is turning away potential users - it
> would turn me away, certainly.
> > The question is whether it's a good approach to the problem.
> Indeed. (My criticism here is intended as constructive, to suggest
> better choices.)
> > As I said, the user of Baby X will be mostly hobby programmers.
> If your description of it is accurate, why are you limiting it like
> that? Many professional developers would like better simple
> cross-platform gui tools and toolkits. And if it is not better than
> existing options, why bother with it at all? The only time it makes
> sense to target hobby users alone is if the existing alternatives are
> hugely complex, or hugely expensive, and that is not the case here.
> Professionals also like "easy to use".
> > So the
> > emphasis is on making things easy to use. Adding alternative translations
> > under an <international> tag is easy to do.
> >
> No, the translation system is /not/ easy to use, and horrendous to maintain.
>
> Look, imagine a developer wanted French and German translations. It's
> just a single programmer, but he has a couple of friends who speak those
> languages. With your solution, these two friends are mixing and editing
> the same file, at the same time, while the programmer is simultaneously
> modifying the file for other purposes. It is absolute madness. Do you
> not understand that the French translations need to go in one file, and
> the German translations need to go in a different file, and there is
> /no/ circumstances in which it is a good idea to mix them all together
> in one horrible XML file?
>
> Anyone trying to use your tool for something more than a "Hello world"
> program will write their own pre-processor to generate your XML file!
> > However I fully accept that there might be a far better approach. Keith
> > Thompson has made some constructive suggestions.
> >
> Yes - when standard formats and tools exist, use them.
> > XML has some advantages over an ad-hoc line-based format. The parser needs
> > work as it's currently too basic. But XML should be familiar to most programmers.
> >
> XML is familiar as a concept of hatred by most programmers - something
> forced upon them by clueless management and marketing people who think
> it is a great buzzword. Almost nobody chooses XML voluntarily.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2023-08-09 05:48 -0700 |
| Message-ID | <361b8ac9-65ff-4c03-a9d1-675b8f2ffd54n@googlegroups.com> |
| In reply to | #171931 |
On Wednesday, 9 August 2023 at 13:35:18 UTC+1, Michael S wrote: > On Wednesday, August 9, 2023 at 2:43:06 PM UTC+3, David Brown wrote: > > > > But if you have an external manually written makefile, that is not > > project management - so usually you also then have to make an IDE > > project to describe the source files, include search paths, pre-defined > > macros, etc. That can be a duplicate of work (though good makefiles > > find the source files and dependencies mostly automatically), and > > duplication can lead to mistakes. > > > No, simply no. > Good makefile finds "other" dependencies mostly automatically, but > makes no attempts to figure out source files. > A major motivation was to avoid unnecessary compilations by only compiling source which had changed. That's still maybe relevant for massive projects. But I rebuilt the Baby X resource compiler from scratch, and counted. "One, two, three .." and it was done. For a program of that size, this is no longer an issue.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-08-09 14:17 +0100 |
| Message-ID | <ub03m0$3v2kj$1@dont-email.me> |
| In reply to | #171932 |
On 09/08/2023 13:48, Malcolm McLean wrote:
> On Wednesday, 9 August 2023 at 13:35:18 UTC+1, Michael S wrote:
>> On Wednesday, August 9, 2023 at 2:43:06 PM UTC+3, David Brown wrote:
>>>
>>> But if you have an external manually written makefile, that is not
>>> project management - so usually you also then have to make an IDE
>>> project to describe the source files, include search paths, pre-defined
>>> macros, etc. That can be a duplicate of work (though good makefiles
>>> find the source files and dependencies mostly automatically), and
>>> duplication can lead to mistakes.
>>>
>> No, simply no.
>> Good makefile finds "other" dependencies mostly automatically, but
>> makes no attempts to figure out source files.
>>
> A major motivation was to avoid unnecessary compilations by only
compiling
> source which had changed. That's still maybe relevant for massive
projects.
> But I rebuilt the Baby X resource compiler from scratch, and counted.
> "One, two, three .." and it was done. For a program of that size,
this is no longer
> an issue.
You have a faster machine than I do.
Building your BBX project with gcc 13.2 on Windows takes 11 seconds for
-O0, and 37 seconds for -O3.
My bcc takes just over a second.
(BTW there's an annoying bug in gcc. I put all the files in an @ file,
so it includes lines like this:
freetype\ttapi.c
as is normal for paths on Windows. But gcc ignores the backslash. I have
to write it as /.)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-08-15 13:06 +0200 |
| Message-ID | <ubfm77$2ptu0$2@dont-email.me> |
| In reply to | #171931 |
On 09/08/2023 14:35, Michael S wrote: > On Wednesday, August 9, 2023 at 2:43:06 PM UTC+3, David Brown wrote: >> But if you have an external manually written makefile, that is not >> project management - so usually you also then have to make an IDE >> project to describe the source files, include search paths, pre-defined >> macros, etc. That can be a duplicate of work (though good makefiles >> find the source files and dependencies mostly automatically), and >> duplication can lead to mistakes. >> > > No, simply no. > Good makefile finds "other" dependencies mostly automatically, but > makes no attempts to figure out source files. > My makefiles do. Obviously this is in combination with an appropriate layout of the files. Basically, all my source files will be in my project's "source" directory and subdirectories thereof, and nothing else is there. So finding all the source files is just a recursive wildcard operation. Any time I add or remove files to the project, the build is adjusted automatically. It is all incredibly easy to use, and very hard to get wrong. (Writing the makefile originally took some time.) Of course, if you have a different way of organising your source files, you may not have appropriate rules that can be put in your makefile to let make find them automatically.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2023-08-09 13:44 +0000 |
| Message-ID | <_KMAM.556452$AsA.220926@fx18.iad> |
| In reply to | #171908 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>On Tuesday, 8 August 2023 at 23:26:47 UTC+1, David Brown wrote:
>> On 08/08/2023 19:04, Malcolm McLean wrote:
>> > On Tuesday, 8 August 2023 at 17:46:15 UTC+1, David Brown wrote:
>> >> On 08/08/2023 18:04, Malcolm McLean wrote:
>> >>> On Tuesday, 8 August 2023 at 16:18:49 UTC+1, David Brown wrote:
>> >>>> On 05/08/2023 14:08, Malcolm McLean wrote:
>> >>>>
>> >>>>> This is the problem of course. The Baby X API expects data in a certain format.
>> >>>>> So all the API functions which operate on images take a 32 bit RGBA buffer
>> >>>>> as an "unsigned char *", and the dimensions as two ints. But another API might
>> >>>>> use an opaque "IMAGE" structure. Or another system might have 16 bit r5g5b5a1
>> >>>>> images.
>> >>>>
>> >>>> It would make a lot of sense to have a program that took data in common
>> >>>> standardised uncompressed forms (like .wav, .bmp) and generated data in
>> >>>> whatever format suits Baby X.
>> >>>>
>> >>> "Data" means, "that which is given". People programming applications are given
>> >>> resources in many formats. They might steal a PNG from the web, get a JPEG
>> >>> commissioned from a paid artist, knock up their own SVG.
>> >>> Now of course it's possible to convert all these into a common format like PNG
>> >>> which is powerful enough to hold all thse formats without loss. But you've lost
>> >>> the link with the original data. So when the artist comes back with a second
>> >>> version of the JPEG, you've got to run ImageMagick again. And I don't have
>> >>> ImageMagick installed on the Mac I'm writing this on (there's a program called
>> >>> sips which does similar things).
>> >>> A resouce pipeline with lots of stages, each one requiring a separate third party
>> >>> program, is quite fragile. It works for as long as your Linux machine is all set up
>> >>> with the dependencies, which will be the case for the duration of the project.
>> >>> But if you archive it, and dust it off years later, will things still be intact? And
>> >>> will you know which are the intermediate files, and which are the original data?
>> >> It looks like there is someone else in this group who could benefit from
>> >> understanding "make" and/or other build tools. And if you can't use a
>> >> Mac for development, scrap the expensive toy and install a usable
>> >> system. (Of course, you /can/ use a Mac for development - you just need
>> >> to know how to use your tools.)
>> >>
>> > Bart's right about make. If it actually worked properly we wouldn't need CMake.
>> "make" works perfectly well for its purpose. CMake is a different tool,
>> doing a different job. In fact, CMake generates makefiles for use by
>> "make" (as well as project files for MSVC, and other types of build
>> system). CMake is a higher level tool. ("make" can, in combination
>> with compilers like gcc, do a fair amount of higher level work as well,
>> such as tracking dependencies and files automatically.)
>>
>CMake is an alternative to make.
In the same sense that 'imake' was an alternative to 'make'. They both
are pre-processors that generate makefiles.
>
>XML has some advantages over an ad-hoc line-based format.
Having used 'ant' (a java make analog) a couple decades ago, the only advantages of XML
are machine readability. There's no human advantage.
[toc] | [prev] | [next] | [standalone]
Page 16 of 49 — ← Prev page 1 … 14 15 [16] 17 18 … 49 Next page →
Back to top | Article view | comp.lang.c
csiph-web