Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #380602 > unrolled thread
| Started by | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| First post | 2024-01-22 01:51 +0000 |
| Last post | 2024-01-25 15:02 +0100 |
| Articles | 20 on this page of 649 — 20 participants |
Back to article view | Back to comp.lang.c
iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-22 01:51 +0000
Re: iso646.h Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2024-01-22 02:00 +0000
Re: iso646.h James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-01-21 21:48 -0500
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-22 05:23 +0000
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-22 09:30 +0100
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-22 16:24 +0000
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-22 20:34 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-22 13:22 -0800
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-22 22:07 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-22 14:56 -0800
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-22 23:44 +0000
Re: iso646.h Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-23 00:10 +0000
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-22 20:34 +0000
Re: iso646.h Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-22 21:32 +0000
Re: iso646.h Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> - 2024-01-22 23:08 +0000
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-22 23:37 +0000
Re: iso646.h Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-23 00:12 +0000
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-23 06:54 +0100
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-24 06:05 +0000
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-24 09:34 +0100
Re: iso646.h Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-24 15:43 +0000
Re: iso646.h Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-01-22 20:23 -0800
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-23 06:47 +0100
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-23 21:50 +0000
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-24 08:59 +0100
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-23 09:24 +0100
Re: iso646.h Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-23 21:30 +0000
Re: iso646.h bart <bc@freeuk.com> - 2024-01-23 22:03 +0000
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-24 08:53 +0100
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-24 07:58 -0800
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-24 20:11 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-24 12:23 -0800
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-24 21:55 +0100
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-25 07:22 +0100
Re: iso646.h Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2024-01-24 20:25 +0000
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-25 00:17 +0000
Re: iso646.h Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2024-01-25 00:50 +0000
Re: iso646.h Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-25 01:23 +0000
Re: iso646.h "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-24 18:30 -0800
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-25 01:33 +0000
Re: iso646.h Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-24 21:20 +0000
Re: iso646.h Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-24 16:56 +0000
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-24 18:07 +0100
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-24 18:12 +0100
Re: iso646.h Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-24 21:08 +0000
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-24 10:03 +0100
Re: iso646.h bart <bc@freeuk.com> - 2024-01-23 11:54 +0000
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-23 16:32 +0000
Re: iso646.h Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2024-01-23 17:21 +0000
Re: iso646.h Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-23 21:49 +0000
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-23 21:52 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-23 14:51 -0800
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-23 23:33 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-23 16:16 -0800
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-24 00:39 +0000
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-24 11:53 +0000
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-24 09:15 +0100
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-24 09:02 +0100
C/CPP macro conventions (was Re: iso646.h) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-24 08:25 +0100
Re: C/CPP macro conventions (was Re: iso646.h) Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-24 08:25 +0000
Re: C/CPP macro conventions (was Re: iso646.h) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-24 10:09 +0100
Re: C/CPP macro conventions (was Re: iso646.h) David Brown <david.brown@hesbynett.no> - 2024-01-24 10:13 +0100
Re: C/CPP macro conventions (was Re: iso646.h) Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> - 2024-01-25 23:05 +0000
Re: iso646.h bart <bc@freeuk.com> - 2024-01-23 18:34 +0000
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-23 18:52 +0000
Re: iso646.h James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-01-23 14:23 -0500
Re: iso646.h kalevi@kolttonen.fi (Kalevi Kolttonen) - 2024-01-23 20:32 +0000
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-23 21:52 +0000
Re: iso646.h Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-23 22:09 +0000
Re: iso646.h kalevi@kolttonen.fi (Kalevi Kolttonen) - 2024-01-23 22:37 +0000
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-24 09:10 +0100
Re: iso646.h James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-01-24 12:24 -0500
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-24 18:38 +0100
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-24 18:42 +0100
Re: iso646.h kalevi@kolttonen.fi (Kalevi Kolttonen) - 2024-01-24 17:49 +0000
Re: iso646.h kalevi@kolttonen.fi (Kalevi Kolttonen) - 2024-01-24 18:40 +0000
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-24 20:15 +0000
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-24 22:01 +0100
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-24 11:52 -0800
Re: iso646.h kalevi@kolttonen.fi (Kalevi Kolttonen) - 2024-01-24 20:03 +0000
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-24 20:14 +0000
Re: iso646.h Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-24 21:11 +0000
Re: iso646.h James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-01-25 00:01 -0500
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-25 13:43 +0100
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-25 14:19 +0100
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-25 15:20 +0100
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-25 16:40 +0100
Re: iso646.h bart <bc@freeuk.com> - 2024-01-25 13:43 +0000
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-25 16:11 +0100
Re: iso646.h Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-02-03 11:35 -0800
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-24 09:09 +0100
Unix shell conditionals (was Re: iso646.h) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-24 08:38 +0100
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-23 21:28 +0000
Re: iso646.h Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-23 22:00 +0000
Re: iso646.h bart <bc@freeuk.com> - 2024-01-23 22:33 +0000
Re: iso646.h Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-23 23:46 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-23 14:49 -0800
Re: iso646.h James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-01-23 19:45 -0500
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-24 09:28 +0100
Python (Re: iso646.h) kalevi@kolttonen.fi (Kalevi Kolttonen) - 2024-01-23 19:32 +0000
Re: Python (Re: iso646.h) bart <bc@freeuk.com> - 2024-01-23 19:59 +0000
Re: Python (Re: iso646.h) kalevi@kolttonen.fi (Kalevi Kolttonen) - 2024-01-23 20:18 +0000
Re: Python (Re: iso646.h) Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2024-01-24 07:49 -0700
Re: Python (Re: iso646.h) kalevi@kolttonen.fi (Kalevi Kolttonen) - 2024-01-24 15:07 +0000
Re: Python (Re: iso646.h) cross@spitfire.i.gajendra.net (Dan Cross) - 2024-01-24 15:17 +0000
Re: Python (Re: iso646.h) bart <bc@freeuk.com> - 2024-01-24 15:46 +0000
Re: Python (Re: iso646.h) cross@spitfire.i.gajendra.net (Dan Cross) - 2024-01-24 16:27 +0000
Re: Python (Re: iso646.h) bart <bc@freeuk.com> - 2024-01-24 19:55 +0000
Re: Python (Re: iso646.h) cross@spitfire.i.gajendra.net (Dan Cross) - 2024-01-24 20:57 +0000
Re: Python (Re: iso646.h) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-24 20:17 +0000
Re: Python (Re: iso646.h) bart <bc@freeuk.com> - 2024-01-25 12:13 +0000
Re: Python (Re: iso646.h) kalevi@kolttonen.fi (Kalevi Kolttonen) - 2024-01-25 14:57 +0000
Re: Python (Re: iso646.h) David Brown <david.brown@hesbynett.no> - 2024-01-25 16:17 +0100
Re: Python (Re: iso646.h) bart <bc@freeuk.com> - 2024-01-25 15:52 +0000
Re: Python (Re: iso646.h) kalevi@kolttonen.fi (Kalevi Kolttonen) - 2024-01-25 16:14 +0000
Re: Python (Re: iso646.h) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-25 11:27 -0800
Re: Python (Re: iso646.h) Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-25 18:06 +0000
Re: Python (Re: iso646.h) bart <bc@freeuk.com> - 2024-01-25 19:35 +0000
Re: Python (Re: iso646.h) scott@slp53.sl.home (Scott Lurndal) - 2024-01-24 15:56 +0000
Re: Python (Re: iso646.h) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-23 12:09 -0800
Re: Python (Re: iso646.h) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-23 22:00 +0000
Re: Python (Re: iso646.h) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-01-27 22:12 +0000
Re: Python (Re: iso646.h) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-28 00:29 +0000
Re: Python (Re: iso646.h) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-23 21:55 +0000
Re: Python (Re: iso646.h) kalevi@kolttonen.fi (Kalevi Kolttonen) - 2024-01-23 22:47 +0000
Re: Python (Re: iso646.h) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-23 15:35 -0800
Re: Python (Re: iso646.h) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-24 00:41 +0000
Re: Python (Re: iso646.h) Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-24 03:13 +0000
Re: Python (Re: iso646.h) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-23 23:37 +0000
Re: Python (Re: iso646.h) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-01-26 05:48 -0800
Re: Python (Re: iso646.h) scott@slp53.sl.home (Scott Lurndal) - 2024-01-23 23:51 +0000
Re: Python (Re: iso646.h) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-23 16:35 -0800
Re: Python (Re: iso646.h) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-23 16:40 -0800
Re: Python (Re: iso646.h) bart <bc@freeuk.com> - 2024-01-24 00:06 +0000
Re: Python (Re: iso646.h) David Brown <david.brown@hesbynett.no> - 2024-01-24 12:37 +0100
Re: Python (Re: iso646.h) Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> - 2024-01-25 22:55 +0000
Re: Python (Re: iso646.h) cross@spitfire.i.gajendra.net (Dan Cross) - 2024-01-24 13:30 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-23 12:13 -0800
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-23 22:01 +0000
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-23 22:45 +0000
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-23 23:39 +0000
Re: iso646.h kalevi@kolttonen.fi (Kalevi Kolttonen) - 2024-01-23 22:54 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-23 15:10 -0800
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-23 23:40 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-23 16:27 -0800
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-24 00:47 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-23 17:32 -0800
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-24 02:42 +0000
Re: iso646.h James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-01-23 23:56 -0500
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-24 05:24 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-23 21:43 -0800
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-24 06:35 +0000
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-24 14:14 +0100
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-24 20:19 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-24 07:34 -0800
Re: iso646.h James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-01-23 23:26 -0500
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-23 20:53 -0800
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-24 09:41 +0100
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-24 08:15 -0800
Re: iso646.h Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-24 19:32 +0000
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-24 09:06 +0100
Re: iso646.h Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2024-01-24 14:17 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-24 08:30 -0800
Re: iso646.h Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-24 21:00 +0000
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-24 22:13 +0000
Re: COBOL (was Re: iso646.h) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-25 00:44 +0000
Re: COBOL (was Re: iso646.h) scott@slp53.sl.home (Scott Lurndal) - 2024-01-25 01:37 +0000
Re: COBOL (was Re: iso646.h) cross@spitfire.i.gajendra.net (Dan Cross) - 2024-01-25 02:20 +0000
Re: COBOL (was Re: iso646.h) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-24 18:23 -0800
Re: COBOL (was Re: iso646.h) bart <bc@freeuk.com> - 2024-01-25 11:58 +0000
Re: COBOL (was Re: iso646.h) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-25 02:49 +0000
Re: COBOL (was Re: iso646.h) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-24 19:09 -0800
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-24 17:44 +0100
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-24 17:27 +0000
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-24 20:21 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-24 12:26 -0800
Re: iso646.h Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2024-01-24 20:31 +0000
Re: COBOL (was Re: iso646.h) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-25 00:53 +0000
Re: COBOL (was Re: iso646.h) Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-25 01:24 +0000
Re: COBOL (was Re: iso646.h) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-24 18:21 -0800
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-24 22:09 +0000
Re: iso646.h Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-24 23:20 +0000
Re: iso646.h "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-24 15:56 -0800
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-24 12:20 +0000
Re: iso646.h bart <bc@freeuk.com> - 2024-01-24 13:00 +0000
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-24 14:22 +0100
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-24 14:54 +0100
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-24 08:27 -0800
Re: iso646.h Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-24 20:50 +0000
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-25 14:01 +0100
Re: iso646.h bart <bc@freeuk.com> - 2024-01-25 13:53 +0000
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-25 16:48 +0100
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-25 09:57 -0800
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-25 21:07 +0100
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-25 20:18 +0000
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-26 15:59 +0100
Re: Compose Key (was Re: iso646.h) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-26 21:22 +0000
Re: Compose Key (was Re: iso646.h) David Brown <david.brown@hesbynett.no> - 2024-01-27 16:17 +0100
Re: Compose Key (was Re: iso646.h) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-27 21:28 +0000
Re: Compose Key (was Re: iso646.h) Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> - 2024-01-27 22:38 +0000
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-25 20:08 +0000
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-25 20:30 +0000
Re: iso646.h Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-25 21:13 +0000
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-25 20:06 +0000
Re: iso646.h Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-25 21:04 +0000
Re: iso646.h bart <bc@freeuk.com> - 2024-01-25 21:16 +0000
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-25 22:01 +0000
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-26 02:11 +0100
Re: iso646.h Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-26 01:19 +0000
Operators (Algol 68) (was Re: iso646.h) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-26 02:08 +0100
Re: iso646.h bart <bc@freeuk.com> - 2024-01-25 00:52 +0000
Re: iso646.h "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-24 17:07 -0800
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-25 07:48 +0100
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-25 14:07 +0100
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-25 14:35 +0100
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-25 16:53 +0100
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-25 17:11 +0100
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-25 21:11 +0100
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-26 02:21 +0100
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-26 17:01 +0100
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-26 18:31 +0100
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-26 19:59 +0100
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-26 12:27 -0800
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-26 22:01 +0100
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-26 22:30 +0100
Re: iso646.h James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-01-26 20:22 -0500
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-27 16:43 +0100
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-28 20:14 +0100
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-29 14:09 +0100
Re: iso646.h James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-01-26 20:10 -0500
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-27 16:44 +0100
Re: Functional Programming (was Re: iso646.h) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-27 20:49 +0000
Re: Functional Programming (was Re: iso646.h) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-28 00:22 +0000
Re: Functional Programming (was Re: iso646.h) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-28 01:18 +0000
Re: Functional Programming (was Re: iso646.h) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-28 02:06 +0000
Re: Functional Programming (was Re: iso646.h) David Brown <david.brown@hesbynett.no> - 2024-01-28 12:35 +0100
Re: Functional Programming (was Re: iso646.h) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-28 20:40 +0000
Re: Functional Programming (was Re: iso646.h) David Brown <david.brown@hesbynett.no> - 2024-01-29 09:52 +0100
Re: Functional Programming (was Re: iso646.h) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-02 05:13 +0000
Re: Functional Programming (was Re: iso646.h) David Brown <david.brown@hesbynett.no> - 2024-02-02 09:21 +0100
Re: iso646.h James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-01-28 01:31 -0500
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-28 12:40 +0100
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-26 21:16 +0000
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-26 22:46 +0100
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-26 22:41 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-26 15:41 -0800
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-26 23:51 +0000
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-27 01:17 +0100
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-27 16:25 +0000
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-28 18:46 +0100
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-26 23:52 +0000
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-27 01:27 +0100
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-27 00:38 +0000
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-27 11:09 +0100
Re: Localization (was Re: iso646.h) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-27 20:58 +0000
Re: Localization (was Re: iso646.h) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-28 15:57 +0100
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-27 16:58 +0100
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-27 17:26 +0000
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-27 18:53 +0100
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-27 19:39 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-27 17:31 -0800
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-28 12:50 +0100
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-27 20:59 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-27 17:34 -0800
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-28 01:50 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-27 17:53 -0800
Re: iso646.h "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-27 18:47 -0800
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-28 12:53 +0100
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-28 20:43 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-28 14:49 -0800
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-29 00:03 +0000
Re: iso646.h bart <bc@freeuk.com> - 2024-01-29 01:24 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-28 17:48 -0800
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-29 02:17 +0000
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-29 17:06 +0100
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-29 17:05 +0100
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-29 23:56 +0000
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-29 13:35 +0100
Re: iso646.h bart <bc@freeuk.com> - 2024-01-29 16:23 +0000
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-29 18:40 +0100
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-27 16:33 -0800
Re: iso646.h bart <bc@freeuk.com> - 2024-01-27 00:42 +0000
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-27 03:16 +0000
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-27 17:24 +0000
Re: Java (was Re: iso646.h) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-27 21:04 +0000
[OT] Re: Java (was Re: iso646.h) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-28 17:42 +0100
Re: [OT] Re: Java (was Re: iso646.h) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-28 20:44 +0000
[OT] Usefulness of OO/C++/features (was Re: iso646.h) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-28 17:18 +0100
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-27 03:11 +0000
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-27 03:24 +0000
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-27 11:43 +0100
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-27 11:13 +0000
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-27 12:53 +0100
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-27 20:17 +0000
Re: iso646.h Richard Harnden <richard.nospam@gmail.invalid> - 2024-01-27 21:40 +0000
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-28 00:31 +0000
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-28 18:22 +0100
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-28 22:55 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-28 15:00 -0800
Re: iso646.h James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-01-29 12:09 -0500
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-29 19:33 +0100
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-29 12:48 -0800
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-29 23:51 +0000
Re: iso646.h James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-01-29 12:10 -0500
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-29 12:53 -0800
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-27 21:06 +0000
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-28 00:35 +0000
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-28 01:22 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-27 17:26 -0800
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-28 01:59 +0000
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-28 13:00 +0100
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-28 16:09 +0000
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-28 18:06 +0100
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-28 19:24 +0100
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-28 19:49 +0000
Re: Binary Pipelines (was Re: iso646.h) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-28 20:48 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-28 14:54 -0800
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-29 17:18 +0100
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-29 18:47 +0000
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-29 21:06 +0100
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-29 13:00 -0800
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-30 18:29 +0000
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-30 20:23 +0100
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-30 12:06 -0800
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-30 21:04 +0000
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-31 06:04 +0000
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-31 08:59 +0100
Re: iso646.h Michael S <already5chosen@yahoo.com> - 2024-01-31 12:53 +0200
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-31 14:21 +0100
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-31 14:02 +0100
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-31 14:05 +0100
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-31 14:35 +0100
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-02-01 11:30 +0100
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-01 18:35 +0100
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-02-01 22:41 +0100
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-02 01:59 +0100
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-29 23:55 +0000
Re: iso646.h Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-01-29 12:10 -0800
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-29 22:14 +0000
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-29 22:24 +0000
Re: iso646.h Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-01-29 23:27 -0800
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-30 09:13 +0000
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-30 14:03 +0100
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-30 15:49 +0000
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-30 16:06 +0000
Re: iso646.h Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2024-01-30 16:12 +0000
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-30 16:33 +0000
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-30 16:54 +0000
Re: iso646.h Richard Harnden <richard.nospam@gmail.invalid> - 2024-01-30 19:39 +0000
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-31 06:12 +0000
Re: iso646.h James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-01-31 01:39 -0500
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-31 15:20 +0000
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-31 14:47 +0100
Re: iso646.h Richard Harnden <richard.nospam@gmail.invalid> - 2024-01-31 19:43 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-31 12:14 -0800
Re: iso646.h Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-31 20:25 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-31 13:26 -0800
Re: iso646.h Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-01 01:23 +0000
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-02-01 01:34 +0000
Re: iso646.h Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-01 16:28 +0000
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-31 23:25 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-31 15:34 -0800
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-01 01:58 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-31 18:27 -0800
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-02-01 14:52 +0000
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-01 16:01 +0000
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-02 01:13 +0000
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-02-02 02:15 +0000
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-02 05:08 +0000
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-02-02 15:28 +0000
Re: iso646.h Richard Harnden <richard.nospam@gmail.invalid> - 2024-02-02 16:50 +0000
Re: iso646.h James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-02-01 00:52 -0500
Re: iso646.h James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-02-01 00:45 -0500
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-30 17:25 +0100
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-30 16:55 +0000
Creation era of stdin, stdout, stderr (was Re: iso646.h) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-30 19:06 +0100
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-30 20:29 +0100
Re: iso646.h bart <bc@freeuk.com> - 2024-01-30 20:24 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-30 12:55 -0800
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-30 21:42 +0000
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-31 06:10 +0000
Re: iso646.h dave_thompson_2@comcast.net - 2024-02-26 04:20 -0500
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-30 17:34 +0000
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-30 18:43 +0000
Re: iso646.h Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-30 20:54 +0000
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-31 06:07 +0000
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-31 14:45 +0100
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-31 15:20 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-31 08:38 -0800
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-31 19:05 +0100
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-02 00:08 +0000
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-02 02:10 +0100
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-02-02 02:12 +0000
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-02 03:42 +0100
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-02-02 03:47 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-01 20:02 -0800
Re: iso646.h dave_thompson_2@comcast.net - 2024-02-26 04:18 -0500
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-30 15:00 +0000
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-30 15:21 +0000
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-30 15:53 +0000
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-31 06:03 +0000
Re: iso646.h Michael S <already5chosen@yahoo.com> - 2024-01-31 15:28 +0200
Re: iso646.h bart <bc@freeuk.com> - 2024-01-30 15:30 +0000
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-30 15:54 +0000
Re: iso646.h bart <bc@freeuk.com> - 2024-01-30 16:10 +0000
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-30 17:49 +0100
Re: iso646.h bart <bc@freeuk.com> - 2024-01-30 18:22 +0000
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-30 18:44 +0000
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-30 20:46 +0100
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-31 12:22 +0100
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-31 14:58 +0100
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-31 15:39 +0100
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-30 18:39 +0000
Re: iso646.h Richard Harnden <richard.nospam@gmail.invalid> - 2024-01-30 19:45 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-30 11:59 -0800
Re: iso646.h James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-01-30 16:16 -0500
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-31 12:35 +0100
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-31 15:09 +0100
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-31 15:46 +0100
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-31 19:11 +0100
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-31 10:35 -0800
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-02-01 11:34 +0100
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-01 17:24 +0100
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-02-01 22:46 +0100
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-31 15:29 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-31 08:41 -0800
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-31 17:06 +0000
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-31 06:00 +0000
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-31 15:15 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-30 11:50 -0800
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-31 06:02 +0000
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-31 12:43 +0100
Re: iso646.h Michael S <already5chosen@yahoo.com> - 2024-01-31 13:58 +0200
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-31 13:35 +0100
Re: iso646.h Michael S <already5chosen@yahoo.com> - 2024-01-31 15:10 +0200
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-31 18:19 +0100
Re: iso646.h Michael S <already5chosen@yahoo.com> - 2024-01-31 19:53 +0200
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-01 23:49 +0000
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-31 15:17 +0000
Re: iso646.h James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-01-31 11:20 -0500
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-31 18:06 +0100
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-01 23:52 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-31 08:30 -0800
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-31 15:16 +0000
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-31 06:06 +0000
Re: iso646.h Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-01-30 23:18 -0800
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-31 08:36 +0000
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-31 15:21 +0100
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-31 15:22 +0000
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-31 19:15 +0100
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-31 16:25 +0100
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-31 15:58 +0000
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-31 17:17 +0100
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-31 17:05 +0000
Re: iso646.h Michael S <already5chosen@yahoo.com> - 2024-01-31 18:26 +0200
Re: iso646.h Michael S <already5chosen@yahoo.com> - 2024-01-31 18:27 +0200
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-31 19:01 +0100
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-31 19:24 +0100
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-02 02:18 +0100
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-31 19:20 +0100
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-02 02:48 +0100
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-02 07:16 +0000
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-02 13:17 +0100
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-31 16:04 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-31 08:33 -0800
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-31 23:48 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-31 16:49 -0800
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-01 01:10 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-31 17:36 -0800
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-01 02:23 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-31 18:30 -0800
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-02-01 00:49 +0000
Re: iso646.h Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-02-01 05:24 -0800
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-01 15:07 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-01 12:18 -0800
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-01 23:57 +0000
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-02 13:34 +0100
Re: iso646.h Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-02-03 11:27 -0800
Re: iso646.h Michael S <already5chosen@yahoo.com> - 2024-01-31 12:43 +0200
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-31 12:15 +0000
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-31 13:49 +0100
Re: iso646.h Michael S <already5chosen@yahoo.com> - 2024-01-31 17:03 +0200
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-31 15:49 +0000
Re: iso646.h Michael S <already5chosen@yahoo.com> - 2024-01-31 18:04 +0200
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-31 16:54 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-31 09:16 -0800
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-31 17:21 +0000
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-31 15:53 +0000
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-31 17:29 +0100
Re: iso646.h Michael S <already5chosen@yahoo.com> - 2024-01-31 19:36 +0200
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-31 19:47 +0100
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-31 15:25 +0000
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-31 16:33 +0100
Re: iso646.h Michael S <already5chosen@yahoo.com> - 2024-01-31 17:42 +0200
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-31 15:58 +0000
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-31 17:05 +0100
Re: iso646.h Michael S <already5chosen@yahoo.com> - 2024-01-31 18:18 +0200
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-31 17:47 +0100
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-31 17:20 +0000
[OT] Unix shells and POSIX shell (was Re: iso646.h) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-31 20:11 +0100
Re: [OT] Unix shells and POSIX shell (was Re: iso646.h) scott@slp53.sl.home (Scott Lurndal) - 2024-01-31 19:28 +0000
Re: [OT] Unix shells and POSIX shell (was Re: iso646.h) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-01 13:12 +0100
Re: [OT] Unix shells and POSIX shell (was Re: iso646.h) bart <bc@freeuk.com> - 2024-02-01 12:50 +0000
Re: [OT] Unix shells and POSIX shell (was Re: iso646.h) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-02 04:57 +0000
Re: [OT] Unix shells and POSIX shell (was Re: iso646.h) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-02 07:18 +0000
Re: [OT] Unix shells and POSIX shell (was Re: iso646.h) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-03 01:44 +0000
Re: [OT] Unix shells and POSIX shell (was Re: iso646.h) David Brown <david.brown@hesbynett.no> - 2024-02-02 09:34 +0100
Re: [OT] Unix shells and POSIX shell (was Re: iso646.h) bart <bc@freeuk.com> - 2024-02-02 10:57 +0000
Re: [OT] Unix shells and POSIX shell (was Re: iso646.h) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-03 01:43 +0000
Re: [OT] Unix shells and POSIX shell (was Re: iso646.h) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-03 12:47 -0800
Re: [OT] Unix shells and POSIX shell (was Re: iso646.h) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-04 22:36 +0000
Re: [OT] Unix shells and POSIX shell (was Re: iso646.h) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-04 15:26 -0800
Re: [OT] Unix shells and POSIX shell (was Re: iso646.h) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-05 01:49 +0000
Re: [OT] Unix shells and POSIX shell (was Re: iso646.h) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-04 18:08 -0800
Re: [OT] Unix shells and POSIX shell (was Re: iso646.h) scott@slp53.sl.home (Scott Lurndal) - 2024-02-01 15:04 +0000
Re: [OT] Unix shells and POSIX shell (was Re: iso646.h) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-01 16:16 +0100
Re: [OT] Unix shells and POSIX shell (was Re: iso646.h) cross@spitfire.i.gajendra.net (Dan Cross) - 2024-01-31 20:16 +0000
Re: [OT] Unix shells and POSIX shell (was Re: iso646.h) Michael S <already5chosen@yahoo.com> - 2024-01-31 22:22 +0200
Re: [OT] Unix shells and POSIX shell (was Re: iso646.h) scott@slp53.sl.home (Scott Lurndal) - 2024-01-31 20:50 +0000
Re: [OT] Unix shells and POSIX shell (was Re: iso646.h) Michael S <already5chosen@yahoo.com> - 2024-01-31 23:00 +0200
Re: [OT] Unix shells and POSIX shell (was Re: iso646.h) cross@spitfire.i.gajendra.net (Dan Cross) - 2024-01-31 21:20 +0000
Re: [OT] Unix shells and POSIX shell (was Re: iso646.h) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-01 13:27 +0100
Re: [OT] Unix shells and POSIX shell (was Re: iso646.h) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-01 13:16 +0100
Re: [OT] Unix shells and POSIX shell (was Re: iso646.h) cross@spitfire.i.gajendra.net (Dan Cross) - 2024-02-01 13:21 +0000
Re: [OT] Unix shells and POSIX shell (was Re: iso646.h) David Brown <david.brown@hesbynett.no> - 2024-02-01 11:45 +0100
Re: [OT] Unix shells and POSIX shell (was Re: iso646.h) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-01 13:03 +0100
Re: [OT] Unix shells and POSIX shell (was Re: iso646.h) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-02 04:58 +0000
Re: [OT] Unix shells and POSIX shell (was Re: iso646.h) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-02-01 05:22 -0800
[meta] Re: [OT] Unix shells and POSIX shell (was Re: iso646.h) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-01 15:38 +0100
Re: [OT] Unix shells and POSIX shell (was Re: iso646.h) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-02 05:00 +0000
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-31 19:22 +0100
Re: iso646.h Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-02-01 05:17 -0800
Re: Alternative Shells (was Re: iso646.h) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-02 05:04 +0000
Re: iso646.h Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-01-31 23:36 +0000
Re: iso646.h bart <bc@freeuk.com> - 2024-02-01 00:21 +0000
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-02-01 00:47 +0000
Re: iso646.h bart <bc@freeuk.com> - 2024-02-01 01:29 +0000
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-02-01 14:42 +0000
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-02-01 15:50 +0100
Re: iso646.h bart <bc@freeuk.com> - 2024-02-01 17:06 +0000
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-02-01 23:02 +0100
Re: iso646.h bart <bc@freeuk.com> - 2024-02-01 22:56 +0000
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-02 03:13 +0100
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-02-02 09:44 +0100
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-02 01:08 +0000
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-02-01 15:35 +0100
Re: iso646.h bart <bc@freeuk.com> - 2024-02-01 15:32 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-01 12:23 -0800
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-02 03:26 +0100
Re: iso646.h Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-02-02 23:41 +0000
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-01 01:53 +0000
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-02-01 14:45 +0000
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-01 14:57 +0000
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-01 16:47 +0100
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-02-01 16:22 +0000
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-02-01 15:55 +0100
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-01 15:41 +0000
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-01 17:15 +0100
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-02-01 19:36 +0000
Re: iso646.h Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-01 19:50 +0000
Re: iso646.h Richard Harnden <richard.nospam@gmail.invalid> - 2024-02-01 20:03 +0000
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-02-01 23:06 +0100
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-01 22:38 +0000
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-02-02 09:51 +0100
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-02 13:28 +0000
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-02-02 15:47 +0100
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-02 15:38 +0000
Re: iso646.h Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-02-02 23:38 +0000
Re: iso646.h Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-02 23:59 +0000
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-01 05:24 +0000
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-01 14:02 +0100
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-01 13:26 +0000
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-01 16:07 +0100
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-01 15:50 +0000
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-02-01 16:30 +0000
Re: iso646.h bart <bc@freeuk.com> - 2024-02-01 18:03 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-01 12:09 -0800
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-02-01 20:59 +0000
Re: iso646.h bart <bc@freeuk.com> - 2024-02-01 21:25 +0000
Re: iso646.h "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-01 13:34 -0800
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-02-01 22:25 +0000
Re: iso646.h "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-01 14:40 -0800
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-01 15:31 -0800
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-02-01 22:24 +0000
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-02 12:41 +0100
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-02 08:39 -0800
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-02 12:33 +0100
Re: iso646.h Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-02-02 21:40 +0000
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-03 05:14 +0000
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-02-01 16:48 +0100
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-01 16:19 +0000
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-02-01 14:53 +0000
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-28 18:02 +0100
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-24 19:33 +0000
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-24 19:45 +0000
Re: iso646.h kalevi@kolttonen.fi (Kalevi Kolttonen) - 2024-01-24 19:48 +0000
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-25 00:30 +0000
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-25 03:56 +0000
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-25 05:25 +0000
Re: iso646.h Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-25 07:02 +0000
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-25 14:46 +0100
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-25 14:29 +0100
Re: iso646.h kalevi@kolttonen.fi (Kalevi Kolttonen) - 2024-01-25 15:08 +0000
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-25 16:18 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-25 11:20 -0800
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-26 12:17 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-26 07:56 -0800
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-26 23:03 +0000
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-26 17:06 +0100
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-26 18:59 +0100
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-26 20:18 +0100
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-26 23:15 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-26 15:55 -0800
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-27 17:07 +0100
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-27 17:34 -0800
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-28 13:02 +0100
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-27 01:12 +0100
Re: iso646.h James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-01-26 20:43 -0500
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-27 11:21 +0100
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-27 03:05 +0000
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-27 11:34 +0100
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-27 11:02 +0000
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-27 12:36 +0100
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-29 18:32 +0000
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-29 19:48 +0100
Re: iso646.h Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-29 19:35 +0000
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-29 21:10 +0100
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-29 22:27 +0000
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-30 10:05 +0100
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-27 17:46 +0100
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-28 20:16 +0100
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-29 17:20 +0100
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-25 10:48 -0800
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-23 21:51 +0000
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-24 19:48 +0000
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-24 19:52 +0000
Re: iso646.h "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-24 13:00 -0800
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-25 00:26 +0000
Re: iso646.h Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-25 01:25 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-24 12:09 -0800
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-25 03:46 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-24 19:59 -0800
Re: iso646.h Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-25 05:39 +0000
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-25 09:55 +0000
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-25 15:19 +0100
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-25 07:26 -0800
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-26 17:12 +0100
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-25 16:22 +0000
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-25 15:02 +0100
Page 15 of 33 — ← Prev page 1 … 13 14 [15] 16 17 … 33 Next page →
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-01-27 16:33 -0800 |
| Message-ID | <87sf2i1els.fsf@nosuchdomain.example.com> |
| In reply to | #381029 |
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> On Sat, 27 Jan 2024 01:27:55 +0100, Janis Papanagnou wrote:
>
>> On 27.01.2024 00:52, Lawrence D'Oliveiro wrote:
>>
>>> On Fri, 26 Jan 2024 22:46:25 +0100, Janis Papanagnou wrote:
>>>
>>>> Also the stream hierarchy offers design and implementation paths that
>>>> you just don't have with printf().
>>>
>>> And that you don’t need, frankly.
>>
>> Don't be so fast with your judgment. Of course we use it to elegantly
>> and scaleably solve tasks in C++.
>
> But not localization, which is an important issue. printf-style formatting
> allows rearrangement of parts of a message to suit grammar purposes, C++-
> style output operators do not.
I'm reasonably sure you saw my previous followup, in which I pointed out
that (a) ISO C does not support reordering arguments to printf, and (b)
in any language, you can reorder arguments by building a string that you
then send to output.
C++ also lets you define output operators for any type, something that's
much more difficult with printf-style output.
[...]
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2024-01-27 00:42 +0000 |
| Message-ID | <up1jif$32uhj$1@dont-email.me> |
| In reply to | #381028 |
On 27/01/2024 00:27, Janis Papanagnou wrote: > Java ...C++ .. > But that's anyway all off-topic here. JP finally realises that, after 100 posts of ramblings about anything but C. From 'bart cc32n.c' thread: JP: >No, you are wrong, I'm not the owner of this piece of... code. >If someone makes a big heap of fecal in a public park, would >you think I'm the owner? I'd rather sue the one who did that; >because the park (or Usenet) is common property, and the heap >of fecal (or that code) is not. What a thoroughly unpleasant piece of work.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2024-01-27 03:16 +0000 |
| Message-ID | <up1shr$37v5a$3@dont-email.me> |
| In reply to | #381030 |
On 27/01/2024 00:42, bart wrote: > On 27/01/2024 00:27, Janis Papanagnou wrote: > >> Java ...C++ .. >> But that's anyway all off-topic here. > > JP finally realises that, after 100 posts of ramblings about anything > but C. > > > From 'bart cc32n.c' thread: > > JP: > >No, you are wrong, I'm not the owner of this piece of... code. > > >If someone makes a big heap of fecal in a public park, would > >you think I'm the owner? I'd rather sue the one who did that; > >because the park (or Usenet) is common property, and the heap > >of fecal (or that code) is not. > > What a thoroughly unpleasant piece of work. > Yes, it's not nice. It's hard to make software go viral and it isn't something I have achieved myself, despite quite a bit of trying. But the reason is not always that the code is inherently worthless. -- Check out Basic Algorithms and my other books: https://www.lulu.com/spotlight/bgy1mm
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2024-01-27 17:24 +0000 |
| Message-ID | <f%atN.183055$yEgf.134580@fx09.iad> |
| In reply to | #381028 |
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes: >On 27.01.2024 00:52, Lawrence D'Oliveiro wrote: >> On Fri, 26 Jan 2024 22:46:25 +0100, Janis Papanagnou wrote: >> >>> Also the stream hierarchy offers >>> design and implementation paths that you just don't have with printf(). >> >> And that you don’t need, frankly. > >Don't be so fast with your judgment. Of course we use it to elegantly >and scaleably solve tasks in C++. > >> Java manages just fine with printf-style formatting and “toString()” methods. > >I tried to explain in my other post that it's not just about a format >(or a string-sequencing member function). But I'm sure one must be >deeper in the topic or have experienced (besides any supposed issues) >the sophisticated possibilities that C++ offers to support good design. As someone who as programmed daily in C++ since 1989, usually in performance sensitive code, I've never found the C++ input and output operators useful. The run-time cost both in space and time is far more than the *printf formatting functions, and they're less flexible when the formatting changes based, e.g., on locale. > >Java (as a newer language) has also some advantages, but was in many >respects far behind C++ (IMO). Wow, that's a strong statement. What led you to hold that opinion? Java, as a language, was rather well designed. The run-time costs, however, precluded the use of Java in most of the projects that I've worked on since Java was introduced.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-01-27 21:04 +0000 |
| Subject | Re: Java (was Re: iso646.h) |
| Message-ID | <up3r4r$3hbk7$9@dont-email.me> |
| In reply to | #381057 |
On Sat, 27 Jan 2024 17:24:27 GMT, Scott Lurndal wrote: > Java, as a language, was rather well designed. It tried to be simpler than C++. If you compare the respective sizes of the core language manuals, you would have to agree it failed miserably. And the cost of that “simplicity” was the leaving out of useful features like operator overloads for user types, unsigned integers, typedefs and generics (later added back in a hacky way). Here’s a Java feature that might surprise some people: in C++, you use the word “new” to denote that a class instance is being allocated on the heap. A declaration without that word indicates that the instance is being allocated on the stack. In Java, as in Python, all class instances are allocated on the heap. Therefore the word “new” becomes superfluous. And so Python gets rid of it, reducing class instantiation to what looks like a function call on the class name. Yet Java keeps the requirement to say “new”. Why?
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2024-01-28 17:42 +0100 |
| Subject | [OT] Re: Java (was Re: iso646.h) |
| Message-ID | <up605m$ogg$1@dont-email.me> |
| In reply to | #381071 |
On 27.01.2024 22:04, Lawrence D'Oliveiro wrote: > [...] > In Java, as in Python, all class instances are allocated on the heap. > Therefore the word “new” becomes superfluous. And so Python gets rid of > it, reducing class instantiation to what looks like a function call on the > class name. > > Yet Java keeps the requirement to say “new”. Why? If the "Why?" refers to the word "keeps" then the answer seems obvious; compatibility, to not break existing code. If you're asking why "in the first place" they introduced it; I suppose to differentiate it from simple types, and to indicate that such objects are subject to the garbage collector (when getting unused). Maybe it's useful to know how Simula (first OO language, thus probably a paragon for other language designs) did it. Here you had simple types (integer, real, character, etc.), the special type 'text' (a string class but used also like a primitive one), and the complex class types. The latter had an own declaration syntax 'ref(class)name' and own ref-assignments ':-' as opposed to value-assignments ':=', own comparison operators, and they are subject to garbage collection. This appears to some degree to be similar to Java. But personally I don't mind the 'new' keyword in Java anyway. Languages shall make it possible to produce readable code; with Java I can do that (and probably even better than in C), so that is not what prevents me from choosing Java. Janis
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-01-28 20:44 +0000 |
| Subject | Re: [OT] Re: Java (was Re: iso646.h) |
| Message-ID | <up6ebt$2vq9$8@dont-email.me> |
| In reply to | #381126 |
On Sun, 28 Jan 2024 17:42:29 +0100, Janis Papanagnou wrote: > On 27.01.2024 22:04, Lawrence D'Oliveiro wrote: >> >> In Java, as in Python, all class instances are allocated on the heap. >> Therefore the word “new” becomes superfluous. And so Python gets rid of >> it, reducing class instantiation to what looks like a function call on >> the class name. >> >> Yet Java keeps the requirement to say “new”. Why? > > If the "Why?" refers to the word "keeps" then the answer seems obvious; > compatibility, to not break existing code. > If you're asking why "in the first place" they introduced it; I suppose > to differentiate it from simple types, and to indicate that such objects > are subject to the garbage collector (when getting unused). For simple types, you don’t need to use the type name at all, to create an instance of the type. So there would be no opportunity to use or not use the type name. Hence the question about “new” is irrelevant in this case.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2024-01-28 17:18 +0100 |
| Subject | [OT] Usefulness of OO/C++/features (was Re: iso646.h) |
| Message-ID | <up5up9$gsd$1@dont-email.me> |
| In reply to | #381057 |
On 27.01.2024 18:24, Scott Lurndal wrote: > Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes: > > As someone who as programmed daily in C++ since 1989, usually I started C++ around the same time, actually since C++'s beginning, so probably only few years earlier. But today I use C++ only in my private context since, professionally, I'm not programming any more. > in performance sensitive code, I've never found the C++ input > and output operators useful. I'm sure whether one finds a language (or features of a language) useful certainly depends on various factors; education, the area of work, the specific company (including its culture), and own personality (own experiences, and personal background, where from one comes). This is why I think it makes no sense to start a dispute here. Either you have experienced the advantages, or you haven't, or only partly. > The run-time cost both in space > and time is far more than the *printf formatting functions, > and they're less flexible when the formatting changes based, > e.g., on locale. Runtime costs and memory space considerations had been relevant in my DSP assembler deep-space-satellite-communication project (in the late 1980's). In my C++ projects it was irrelevant whether language feature A was 10% faster or slower compared to language feature B. There were other factors that influenced performance; like complexity of the algorithmic solutions. And there were other requirements that had precedence anyway; like robust and extensible designs. Amongst many other things. So all I can do, if you like - but I don't know whether it helps you, since your experiences and background certainly differs -, is to illustrate it with a small project where specifically the feature of discussion helped to a clear and extensible design, simply to use and integrate; a flexibility and robust solution. In C++ I implemented an Application Management Interface - that was already 30 years ago, before Java provided some library like that - that made it possible to control any object instance in a software component by (informally written) "interface.register(item)", and you could then interrogate or change state of such registered items asynchronously during runtime by exchanging the de-/linearized data through some text oriented IPC channel. There was no need to adjust application logic and no functional dependencies. It was transparent WRT the type of object (it could be, say, a primitive 'int' counter or a complex 'Car' object); items of any complexity and type could be controlled through any stream based communication interface. The only precondition was that the object class provides operators '<<' and '>>' for de-/serialization (and these operators were anyway defined in our contexts, for obvious reasons), and (IIRC) that it had the property "controllable" (an interface derivation). Thanks to OO principles and (beside other features) C++'s '<<' operator. (I don't want to imagine such functionality with printf and all it's impact to the rest of the program system.) > >> >> Java (as a newer language) has also some advantages, but was in many >> respects far behind C++ (IMO). > > Wow, that's a strong statement. What led you to hold that opinion? Experience with many programming languages (including Java), and a pair of open eyes, and an open mind. > > Java, as a language, was rather well designed. (It would have never occurred to me to to make such a statement.) > The run-time costs, > however, precluded the use of Java in most of the projects that I've > worked on since Java was introduced. This is just one observation. But, yes. Janis
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2024-01-27 03:11 +0000 |
| Message-ID | <up1s95$37v5a$2@dont-email.me> |
| In reply to | #381023 |
On 26/01/2024 23:52, Lawrence D'Oliveiro wrote: > On Fri, 26 Jan 2024 22:46:25 +0100, Janis Papanagnou wrote: > >> Also the stream hierarchy offers >> design and implementation paths that you just don't have with printf(). > > And that you don’t need, frankly. Java manages just fine with printf-style > formatting and “toString()” methods. > The problem is that the stream hierarchy both serialises (puts data into a form with no hierarchy which can be stored in raw memory or in backing store), and creates human readable output. Whilst to an extent you can do both at the same time, the goals are different. -- Check out Basic Algorithms and my other books: https://www.lulu.com/spotlight/bgy1mm
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2024-01-27 03:24 +0000 |
| Message-ID | <up1t0r$37v5a$4@dont-email.me> |
| In reply to | #381017 |
On 26/01/2024 21:46, Janis Papanagnou wrote: > On 26.01.2024 22:16, Lawrence D'Oliveiro wrote: >> On Thu, 25 Jan 2024 14:07:25 +0100, David Brown wrote: >> >>> "cout << one() << two() << three();" >> >> Those C++ operators for I/O are a brain-dead idea. C-style printf formats >> actually work better. > > Well, no. There's a reason for using operators. In OO design you define > classes, and you can define ostream operators << for your classes so > that you can use these like elementary types in an output stream. This > means you can output (and input) arbitrary complex classes. You'll also > get strong type-safety. And whatnot. Also the stream hierarchy offers > design and implementation paths that you just don't have with printf(). > > In case you haven't done OO design & programming there's unfortunately > not an easy way to explain or go into the necessary details here. I can > just suggest to get into that topic; it's worth, IMO. > > The printf() method is quite old; with simple types it's a more compact > form of formula. You have some cryptic characters that shorten the > format string (whereas with C++ manipulators and other features you'll > have more flexibility, extensibility, but pay that with a bulkier form). > It's hard to think of anything that can be passed to standard outut other than integers, floating point values, and strings. So you only need three atomic operations. You can then buld complex objects consisting of integers, floats and strings on top of those three basic operations. But the stream itself should be locked down and not open to derivation. -- Check out Basic Algorithms and my other books: https://www.lulu.com/spotlight/bgy1mm
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2024-01-27 11:43 +0100 |
| Message-ID | <up2mor$3bjgb$1@dont-email.me> |
| In reply to | #381037 |
On 27.01.2024 04:24, Malcolm McLean wrote: >> > It's hard to think of anything that can be passed to standard outut > other than integers, floating point values, and strings. So you only > need three atomic operations. > You can then buld complex objects consisting of integers, floats and > strings on top of those three basic operations. But the stream itself > should be locked down and not open to derivation. I'm not sure where you're coming from here, what you mean by "locked down", and why it would be a goal to reach. I used various ostreams (output, strings, etc.) to an advantage in designing flexible usable algorithms without duplicating code or anything. (I don't know where your view comes from, but maybe it helps to take an existing library based on OO design, maybe even STL (which has functional concepts as well) and inspect what can be done with stream (or other) hierarchies of types. - But maybe its just as I've written upthread; if you have not experienced that yourself it's probably hard to understand where and what the advantages are.) Janis
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2024-01-27 11:13 +0000 |
| Message-ID | <up2ogd$3bs86$1@dont-email.me> |
| In reply to | #381042 |
On 27/01/2024 10:43, Janis Papanagnou wrote: > On 27.01.2024 04:24, Malcolm McLean wrote: >>> >> It's hard to think of anything that can be passed to standard outut >> other than integers, floating point values, and strings. So you only >> need three atomic operations. >> You can then buld complex objects consisting of integers, floats and >> strings on top of those three basic operations. But the stream itself >> should be locked down and not open to derivation. > > I'm not sure where you're coming from here, what you mean by "locked > down", and why it would be a goal to reach. I used various ostreams > (output, strings, etc.) to an advantage in designing flexible usable > algorithms without duplicating code or anything. (I don't know where > your view comes from, but maybe it helps to take an existing library > based on OO design, maybe even STL (which has functional concepts as > well) and inspect what can be done with stream (or other) hierarchies > of types. - But maybe its just as I've written upthread; if you have > not experienced that yourself it's probably hard to understand where > and what the advantages are.) > > Janis > What I am saying is that standard output can take integers, floats and strings. So the stream should have some facilites for writing integers (leading zeros, signs, maybe commas separators for thousands), some for floats (rounding, precision, scientific notation etc), some for strings (not much you can do here other than just pass the raw characters). Now when we've got those facilites and we are happy with them, that's it. We don't allow further derivation of the stream to change the basic behaviour. Now people might say "booleans, you've forgotten booleans, surely when you pass booleans it should print "true" or "false". No. We'll handle that at a higher level and pass "true" and "false" as strings. The disadvantage is that you are locked into an integer/float/string paradigm. Amd it's not OO. But the advantage is that it will be stable. -- Check out Basic Algorithms and my other books: https://www.lulu.com/spotlight/bgy1mm
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2024-01-27 12:53 +0100 |
| Message-ID | <up2qse$3c81p$1@dont-email.me> |
| In reply to | #381044 |
On 27.01.2024 12:13, Malcolm McLean wrote: >> > What I am saying is that standard output can take integers, floats and > strings. Oh!? That doesn't match with any output model I have in mind. (It only matches if I'm coming from the printf() functionality as basis of all.) Standard output can take, technically, anything. We're passing binary and "text" across the standard channels (and may leave open whether an UTF-8 encoded text is to be considered "binary" in some context). On one abstraction level you can say I want to consider only non-binary readable output, but then it's all text (int and float and bool are just output with one of their textual standard representations). > So the stream should have some facilites for writing integers (leading > zeros, signs, maybe commas separators for thousands), some for floats > (rounding, precision, scientific notation etc), some for strings (not > much you can do here other than just pass the raw characters). From an OO perspective we may also say the type Integer, the type Float, etc. shall provide means to create a textual standard representation, with options to control the form of the standard representation. Is the form of the standard representation a property of the data type or of a [not really] "generic" procedure that has hard-coded support for just a hand full of predefined primitive types? > > Now when we've got those facilites and we are happy with them, that's > it. We don't allow further derivation of the stream to change the basic > behaviour. Now people might say "booleans, you've forgotten booleans, > surely when you pass booleans it should print "true" or "false". No. > We'll handle that at a higher level and pass "true" and "false" as strings. > > The disadvantage is that you are locked into an integer/float/string > paradigm. Amd it's not OO. But the advantage is that it will be stable. The OO methods are also stable, but they are also flexible. The concept makes it possible to extend it to any data type. (I've done that many times. And thinking about how that would have looked like with non-OO and only printf() methods is a horror. But, as said; it's probably necessary to experience that self if it's not understandable from the explanations alone.) Janis
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2024-01-27 20:17 +0000 |
| Message-ID | <up3ode$3h68j$1@dont-email.me> |
| In reply to | #381046 |
On 27/01/2024 11:53, Janis Papanagnou wrote: > On 27.01.2024 12:13, Malcolm McLean wrote: >>> >> What I am saying is that standard output can take integers, floats and >> strings. > > Oh!? That doesn't match with any output model I have in mind. (It only > matches if I'm coming from the printf() functionality as basis of all.) > Yes, exactly. Standard output is any sequence of ASCII characters. printf() is the main C interface to that, and supports integers, floats and strings, to a first approximation. > > Standard output can take, technically, anything. We're passing binary > and "text" across the standard channels (and may leave open whether an > UTF-8 encoded text is to be considered "binary" in some context). > > On one abstraction level you can say I want to consider only non-binary > readable output, but then it's all text (int and float and bool are just > output with one of their textual standard representations). > You can of course encode any data format as any other as long as you can write enough. But standard output can't take images or audio, for example. >> So the stream should have some facilites for writing integers (leading >> zeros, signs, maybe commas separators for thousands), some for floats >> (rounding, precision, scientific notation etc), some for strings (not >> much you can do here other than just pass the raw characters). > > From an OO perspective we may also say the type Integer, the type Float, > etc. shall provide means to create a textual standard representation, > with options to control the form of the standard representation. Is the > form of the standard representation a property of the data type or of a > [not really] "generic" procedure that has hard-coded support for just > a hand full of predefined primitive types? > >> >> Now when we've got those facilites and we are happy with them, that's >> it. We don't allow further derivation of the stream to change the basic >> behaviour. Now people might say "booleans, you've forgotten booleans, >> surely when you pass booleans it should print "true" or "false". No. >> We'll handle that at a higher level and pass "true" and "false" as strings. >> >> The disadvantage is that you are locked into an integer/float/string >> paradigm. Amd it's not OO. But the advantage is that it will be stable. > > The OO methods are also stable, but they are also flexible. The concept > makes it possible to extend it to any data type. (I've done that many > times. And thinking about how that would have looked like with non-OO > and only printf() methods is a horror. But, as said; it's probably > necessary to experience that self if it's not understandable from the > explanations alone.) > The OO method is to allow the stream to be extended. So, in one common system, we might have a "decimal" stream which takes floats and outputs in the format 123.456. Then we could derive a different type of stream from that which outputs floats as 1.23456e2. So x = 123.456 stream.write(x) would have different results depending on what stream we are passed. It's flexible but not very stable, and the 123.456 output has no special status. Nw it's not inherently, necessarily the case that the data you can pass to standard output is integers, floats and strings. You could devise a program which operates on different data entirely, like Huffman codes. But in practise the data will be build of those atoms, and so it makes sense for the interface to standard output to handle them, then be lokced down, so it can't be overidden and everything always works in the same way. -- Check out Basic Algorithms and my other books: https://www.lulu.com/spotlight/bgy1mm
[toc] | [prev] | [next] | [standalone]
| From | Richard Harnden <richard.nospam@gmail.invalid> |
|---|---|
| Date | 2024-01-27 21:40 +0000 |
| Message-ID | <up3t8f$3hqqb$1@dont-email.me> |
| In reply to | #381065 |
On 27/01/2024 20:17, Malcolm McLean wrote: > You can of course encode any data format as any other as long as you can > write enough. But standard output can't take images or audio, for example. What? stdout is perfectly happy with anything, eg: $ cat a.out | xxd | head -1 00000000: cffa edfe 0c00 0001 0000 0000 0200 0000 ................
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-01-28 00:31 +0000 |
| Message-ID | <up478e$3j7tk$3@dont-email.me> |
| In reply to | #381076 |
On Sat, 27 Jan 2024 21:40:31 +0000, Richard Harnden wrote: > $ cat a.out | xxd | head -1 00000000: cffa edfe 0c00 0001 0000 0000 0200 > 0000 ................ UUOC!
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2024-01-28 18:22 +0100 |
| Message-ID | <up62gn$15e5$1@dont-email.me> |
| In reply to | #381065 |
On 27.01.2024 21:17, Malcolm McLean wrote: > Standard output is any sequence of ASCII characters. Nonsense. > printf() is the > main C interface to that, and supports integers, floats and strings, to > a first approximation. It's not an approximation; printf() is _restricted_ to these types (and a few more variants of these few basic types, to be correct). In an OO context you would not unnecessarily restrict yourself. (Unless you don't know better.) > You can of course encode any data format as any other as long as you can > write enough. But standard output can't take images or audio, for example. Standard output is an I/O channel; I can send to it non-text data like the ones you mention. (Just imagine you couldn't send UTF-8 text data.) > The OO method is to allow the stream to be extended. So, in one common > system, we might have a "decimal" stream which takes floats and outputs in > the format 123.456. Then we could derive a different type of stream from > that which outputs floats as 1.23456e2. [...] Nonsense. - You seem to have never really learned or understood OO or what streams in C++ actually are. Janis > [...]
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2024-01-28 22:55 +0000 |
| Message-ID | <up6m08$49oq$1@dont-email.me> |
| In reply to | #381130 |
On 28/01/2024 17:22, Janis Papanagnou wrote: > On 27.01.2024 21:17, Malcolm McLean wrote: > >> Standard output is any sequence of ASCII characters. > > Nonsense. > >> printf() is the >> main C interface to that, and supports integers, floats and strings, to >> a first approximation. > > It's not an approximation; printf() is _restricted_ to these types (and > a few more variants of these few basic types, to be correct). > > In an OO context you would not unnecessarily restrict yourself. (Unless > you don't know better.) > >> You can of course encode any data format as any other as long as you can >> write enough. But standard output can't take images or audio, for example. > > Standard output is an I/O channel; I can send to it non-text data like > the ones you mention. (Just imagine you couldn't send UTF-8 text data.) > >> The OO method is to allow the stream to be extended. So, in one common >> system, we might have a "decimal" stream which takes floats and outputs in >> the format 123.456. Then we could derive a different type of stream from >> that which outputs floats as 1.23456e2. [...] > > Nonsense. - You seem to have never really learned or understood OO or > what streams in C++ actually are. > We're talking about the OO approach generally. Not C++. That is one approach. Our base stream takes floats and produces a stream of decimals in the format 123.456. We then decide that we don't like that and write a derived class which uses scientific notation, 1.23456e2. We can then toggle output between deciml and scientific mode by passing either a base or a derived stream to an output function. That one way of implementing OO streams and anyone with even a basic knowledge of OO should have recognised. -- Check out Basic Algorithms and my other books: https://www.lulu.com/spotlight/bgy1mm
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-01-28 15:00 -0800 |
| Message-ID | <87cytl6p20.fsf@nosuchdomain.example.com> |
| In reply to | #381130 |
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
> On 27.01.2024 21:17, Malcolm McLean wrote:
[...]
>> printf() is the
>> main C interface to that, and supports integers, floats and strings, to
>> a first approximation.
>
> It's not an approximation; printf() is _restricted_ to these types (and
> a few more variants of these few basic types, to be correct).
printf also supports pointer values with "%p". And it support single
characters, which are not strings.
strings of cousre absolutely do not have to be ASCII. Using printf to
print data with embedded null bytes is tricky -- but of course printf is
not the only interface. We can print arbitrary data with putchar,
fwrite, etc.
And in environments like POSIX that don't distinguish between text and
binary output streams, it can be perfectly sensible (though not 100%
portable) to send binary data to stdout.
[...]
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2024-01-29 12:09 -0500 |
| Message-ID | <up8m55$hsfc$1@dont-email.me> |
| In reply to | #381155 |
On 1/28/24 18:00, Keith Thompson wrote: ... > And in environments like POSIX that don't distinguish between text and > binary output streams, it can be perfectly sensible (though not 100% > portable) to send binary data to stdout. I'm sure you know about the following, but for Malcolm's benefit, I want to expand on that comment. In other environments, the fact that stdout is initially a text stream means that freopen() would have to be used to change it to a binary stream - but it is otherwise no more of a problem than in a POSIX environment.
[toc] | [prev] | [next] | [standalone]
Page 15 of 33 — ← Prev page 1 … 13 14 [15] 16 17 … 33 Next page →
Back to top | Article view | comp.lang.c
csiph-web