Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #146566 > unrolled thread
| Started by | DFS <nospam@dfs.com> |
|---|---|
| First post | 2019-10-04 13:00 -0400 |
| Last post | 2019-10-15 11:19 -0700 |
| Articles | 20 on this page of 483 — 31 participants |
Back to article view | Back to comp.lang.c
Sort char array DFS <nospam@dfs.com> - 2019-10-04 13:00 -0400
Re: Sort char array scott@slp53.sl.home (Scott Lurndal) - 2019-10-04 17:06 +0000
Re: Sort char array Anton Shepelev <anton.txt@gmail.com> - 2019-10-04 21:55 +0300
Re: Sort char array DFS <nospam@dfs.com> - 2019-10-04 19:24 -0400
Re: Sort char array Anton Shepelev <anton.txt@gmail.com> - 2019-10-05 13:08 +0300
Re: Sort char array Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-04 21:06 +0100
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-05 01:21 +0100
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-05 01:23 +0100
Re: Sort char array DFS <nospam@dfs.com> - 2019-10-04 20:49 -0400
Re: Sort char array DFS <nospam@dfs.com> - 2019-10-04 20:45 -0400
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-05 13:14 +0100
Re: Sort char array Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-05 14:35 +0100
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-05 17:12 +0100
Re: Sort char array luser droog <luser.droog@gmail.com> - 2019-10-05 09:26 -0700
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-05 17:51 +0100
Re: Sort char array chad <cdalten@gmail.com> - 2019-10-15 09:00 -0700
Re: Sort char array Anton Shepelev <anton.txt@g{oogle}mail.com> - 2019-10-15 19:29 +0300
Re: Sort char array Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-05 18:13 +0100
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-05 21:09 +0100
Re: Sort char array Keith Thompson <kst-u@mib.org> - 2019-10-05 13:22 -0700
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-05 21:45 +0100
Re: Sort char array Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-06 00:17 +0100
Re: Sort char array Anton Shepelev <anton.txt@gmail.com> - 2019-10-06 16:32 +0300
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-06 15:54 +0100
Re: Sort char array Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-10-06 08:07 -0700
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-06 17:39 +0100
Re: Sort char array Keith Thompson <kst-u@mib.org> - 2019-10-06 12:52 -0700
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-06 21:26 +0100
Re: Sort char array Anton Shepelev <anton.txt@gmail.com> - 2019-10-07 01:37 +0300
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-07 01:10 +0100
Re: Sort char array Keith Thompson <kst-u@mib.org> - 2019-10-06 17:32 -0700
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-07 02:02 +0100
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-07 09:41 +0200
Re: Sort char array mark.bluemel@gmail.com - 2019-10-07 00:39 -0700
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-07 10:59 +0100
Re: Sort char array Anton Shepelev <anton.txt@g{oogle}mail.com> - 2019-10-07 13:19 +0300
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-07 12:42 +0100
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-07 13:57 +0200
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-07 15:01 +0100
Re: Sort char array Anton Shepelev <anton.txt@g{oogle}mail.com> - 2019-10-07 17:42 +0300
Re: Sort char array Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-07 17:20 +0100
Re: Sort char array Anton Shepelev <anton.txt@g{oogle}mail.com> - 2019-10-07 19:33 +0300
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-07 18:22 +0100
Re: Sort char array Anton Shepelev <anton.txt@gmail.com> - 2019-10-08 02:27 +0300
Re: Sort char array Keith Thompson <kst-u@mib.org> - 2019-10-07 17:02 -0700
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-08 08:53 +0200
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-08 12:28 +0100
Re: Sort char array Keith Thompson <kst-u@mib.org> - 2019-10-08 11:47 -0700
Re: Sort char array Anton Shepelev <anton.txt@gmail.com> - 2019-10-09 02:02 +0300
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-09 00:50 +0100
Re: Sort char array Anton Shepelev <anton.txt@gmail.com> - 2019-10-10 03:03 +0300
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-10 01:51 +0100
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-10 10:31 +0200
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-10 11:57 +0100
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-10 14:24 +0200
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-10 14:41 +0100
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-10 16:17 +0200
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-10 18:09 +0100
Re: Sort char array scott@slp53.sl.home (Scott Lurndal) - 2019-10-10 17:38 +0000
Re: Sort char array already5chosen@yahoo.com - 2019-10-10 01:37 -0700
Re: Sort char array Keith Thompson <kst-u@mib.org> - 2019-10-10 11:05 -0700
Re: Sort char array Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2019-10-10 14:33 -0400
Re: Sort char array Keith Thompson <kst-u@mib.org> - 2019-10-10 12:20 -0700
Re: Sort char array Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2019-10-10 16:00 -0400
Re: Sort char array Anton Shepelev <anton.txt@gmail.com> - 2019-10-10 23:43 +0300
Re: Sort char array Keith Thompson <kst-u@mib.org> - 2019-10-10 14:12 -0700
Re: Sort char array Anton Shepelev <anton.txt@gmail.com> - 2019-10-11 01:04 +0300
Re: Sort char array scott@slp53.sl.home (Scott Lurndal) - 2019-10-10 22:17 +0000
Re: Sort char array Keith Thompson <kst-u@mib.org> - 2019-10-10 15:24 -0700
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-10 12:57 +0100
Re: Sort char array Anton Shepelev <anton.txt@gmail.com> - 2019-10-11 00:53 +0300
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-11 00:50 +0100
Re: Sort char array Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2019-10-12 03:42 +0800
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-11 22:16 +0100
Re: Sort char array raltbos@xs4all.nl (Richard Bos) - 2019-10-14 16:08 +0000
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-14 19:20 +0100
Re: Sort char array Ian Collins <ian-news@hotmail.com> - 2019-10-15 07:40 +1300
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-14 20:24 +0100
Re: Sort char array Ian Collins <ian-news@hotmail.com> - 2019-10-15 08:33 +1300
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-14 20:52 +0100
Re: Sort char array Keith Thompson <kst-u@mib.org> - 2019-10-14 16:18 -0700
Re: Sort char array scott@slp53.sl.home (Scott Lurndal) - 2019-10-14 23:42 +0000
Re: Sort char array Ian Collins <ian-news@hotmail.com> - 2019-10-15 16:40 +1300
Re: Sort char array chad <cdalten@gmail.com> - 2019-10-15 05:10 -0700
Re: Sort char array Keith Thompson <kst-u@mib.org> - 2019-10-14 12:00 -0700
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-09 12:33 +0200
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-09 14:22 +0100
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-09 15:35 +0200
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-09 16:15 +0100
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-09 20:24 +0200
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-09 20:42 +0100
Re: Sort char array already5chosen@yahoo.com - 2019-10-09 10:40 -0700
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-09 20:31 +0200
Re: Sort char array Keith Thompson <kst-u@mib.org> - 2019-10-09 12:02 -0700
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-09 22:21 +0200
Re: Sort char array scott@slp53.sl.home (Scott Lurndal) - 2019-10-09 21:31 +0000
Re: Sort char array Keith Thompson <kst-u@mib.org> - 2019-10-09 15:35 -0700
Re: Sort char array Anton Shepelev <anton.txt@gmail.com> - 2019-10-10 00:32 +0300
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-10 10:40 +0200
Re: Sort char array Keith Thompson <kst-u@mib.org> - 2019-10-10 10:42 -0700
Re: Sort char array already5chosen@yahoo.com - 2019-10-10 15:58 -0700
Re: Sort char array Anton Shepelev <anton.txt@gmail.com> - 2019-10-13 21:37 +0300
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-13 19:56 +0100
Re: Sort char array Anton Shepelev <anton.txt@gmail.com> - 2019-10-14 00:56 +0300
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-14 11:04 +0100
Re: Sort char array Anton Shepelev <anton.txt@g{oogle}mail.com> - 2019-10-14 13:33 +0300
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-18 10:57 +0100
Re: Sort char array mark.bluemel@gmail.com - 2019-10-18 05:56 -0700
Re: Sort char array Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-10-18 06:10 -0700
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-18 15:24 +0200
Re: Sort char array Richard Damon <Richard@Damon-Family.org> - 2019-10-18 09:41 -0400
Re: Sort char array Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-10-18 07:20 -0700
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-18 15:29 +0100
Re: Sort char array Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-10-19 06:04 -0700
Re: Sort char array scott@slp53.sl.home (Scott Lurndal) - 2019-10-18 13:36 +0000
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-18 15:17 +0100
Re: Sort char array Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-18 16:44 +0100
Re: Sort char array Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-10-18 08:49 -0700
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-18 17:56 +0200
Re: Sort char array Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-10-18 09:03 -0700
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-18 19:14 +0200
Re: Sort char array Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-18 23:45 +0100
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-18 23:06 +0100
Re: Sort char array Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-18 23:45 +0100
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-19 00:49 +0100
Re: Sort char array Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-19 01:19 +0100
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-19 11:16 +0100
Re: Sort char array Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-10-19 03:56 -0700
Re: Sort char array Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-19 13:29 +0100
Re: Sort char array Richard Damon <Richard@Damon-Family.org> - 2019-10-19 08:44 -0400
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-19 14:05 +0100
Re: Sort char array Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-10-19 07:35 -0700
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-19 18:01 +0100
Re: Sort char array Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-19 20:14 +0100
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-19 23:12 +0100
Re: Sort char array Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-20 00:45 +0100
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-20 10:24 +0100
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-20 14:39 +0200
Re: Sort char array Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-10-20 06:11 -0700
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-20 15:36 +0200
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-20 14:36 +0100
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-20 16:47 +0200
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-20 19:16 +0100
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-20 21:37 +0200
Re: Sort char array Richard Damon <Richard@Damon-Family.org> - 2019-10-20 09:54 -0400
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-19 13:24 +0200
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-19 13:40 +0100
Re: Sort char array Keith Thompson <kst-u@mib.org> - 2019-10-19 13:13 -0700
Re: Sort char array already5chosen@yahoo.com - 2019-10-19 13:57 -0700
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-20 15:04 +0200
Re: Sort char array Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-10-20 06:21 -0700
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-20 15:40 +0200
Re: Sort char array Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-10-20 07:29 -0700
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-20 16:49 +0200
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-20 15:10 +0100
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-20 21:26 +0200
Re: Sort char array Melzzzzz <Melzzzzz@zzzzz.com> - 2019-10-20 19:56 +0000
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-20 23:06 +0200
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-20 23:08 +0100
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-21 00:25 +0200
Re: Sort char array Melzzzzz <Melzzzzz@zzzzz.com> - 2019-10-20 22:33 +0000
Re: Sort char array Melzzzzz <Melzzzzz@zzzzz.com> - 2019-10-20 22:57 +0000
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-21 00:14 +0100
Re: Sort char array Melzzzzz <Melzzzzz@zzzzz.com> - 2019-10-20 23:48 +0000
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-21 11:20 +0100
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-21 12:36 +0100
Re: Sort char array Melzzzzz <Melzzzzz@zzzzz.com> - 2019-10-20 22:48 +0000
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-21 01:20 +0200
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-22 18:00 +0200
Re: Sort char array Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-10-22 10:51 -0700
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-22 19:19 +0100
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-20 21:27 +0100
Re: Sort char array Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-10-20 14:46 -0700
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-20 23:34 +0100
Re: Sort char array Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-18 16:35 +0100
Re: Sort char array Melzzzzz <Melzzzzz@zzzzz.com> - 2019-10-18 17:01 +0000
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-18 19:15 +0200
Re: Sort char array Melzzzzz <Melzzzzz@zzzzz.com> - 2019-10-18 19:01 +0000
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-20 13:14 +0200
Re: Sort char array Melzzzzz <Melzzzzz@zzzzz.com> - 2019-10-20 11:25 +0000
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-20 15:07 +0200
Re: Sort char array Melzzzzz <Melzzzzz@zzzzz.com> - 2019-10-18 16:58 +0000
Re: Sort char array Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-10-14 08:06 -0700
Re: Sort char array Anton Shepelev <anton.txt@g{oogle}mail.com> - 2019-10-14 19:55 +0300
Re: Sort char array Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-15 03:24 +0100
Re: Sort char array Anton Shepelev <anton.txt@g{oogle}mail.com> - 2019-10-15 12:39 +0300
Re: Sort char array already5chosen@yahoo.com - 2019-10-15 04:03 -0700
Re: Sort char array Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-15 14:30 +0100
Re: Sort char array Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-10-18 05:59 -0700
Re: Sort char array Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-19 00:31 +0100
Re: Sort char array Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-10-23 04:46 -0700
Re: Sort char array already5chosen@yahoo.com - 2019-10-14 12:06 -0700
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-11 10:30 +0200
Re: Sort char array Keith Thompson <kst-u@mib.org> - 2019-10-11 02:26 -0700
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-11 12:41 +0200
Re: Sort char array Keith Thompson <kst-u@mib.org> - 2019-10-11 11:34 -0700
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-12 12:06 +0200
Re: Sort char array Keith Thompson <kst-u@mib.org> - 2019-10-12 11:55 -0700
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-13 13:23 +0200
Re: Sort char array Keith Thompson <kst-u@mib.org> - 2019-10-13 13:30 -0700
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-14 16:13 +0200
Re: Sort char array Anton Shepelev <anton.txt@gmail.com> - 2019-10-11 02:00 +0300
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-11 10:33 +0200
Re: Sort char array Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-10-10 01:01 -0700
Re: Sort char array Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-10 11:19 +0100
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-10 12:18 +0100
Re: Sort char array Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-10 16:15 +0100
Re: Sort char array scott@slp53.sl.home (Scott Lurndal) - 2019-10-10 15:32 +0000
Re: Sort char array Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-10 21:03 +0100
Re: Sort char array scott@slp53.sl.home (Scott Lurndal) - 2019-10-10 20:36 +0000
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-10 17:16 +0100
Re: Sort char array Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-11 03:25 +0100
Re: Sort char array David Kleinecke <dkleinecke@gmail.com> - 2019-10-10 22:36 -0700
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-11 12:10 +0100
Re: Sort char array Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-12 00:26 +0100
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-12 00:44 +0100
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-12 12:18 +0200
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-12 12:42 +0100
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-12 15:00 +0200
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-12 15:29 +0100
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-12 19:13 +0200
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-12 19:04 +0100
Re: Sort char array Richard Damon <Richard@Damon-Family.org> - 2019-10-12 20:13 -0400
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-13 01:36 +0100
Re: Sort char array Richard Damon <Richard@Damon-Family.org> - 2019-10-12 22:52 -0400
Re: Sort char array Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-10-12 23:06 -0700
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-13 10:25 +0100
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-13 16:42 +0200
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-13 18:03 +0100
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-13 19:50 +0200
Re: Sort char array already5chosen@yahoo.com - 2019-10-14 12:27 -0700
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-15 10:26 +0200
Re: Sort char array Ike Naar <ike@sdf.lonestar.org> - 2019-10-14 21:02 +0000
Re: Sort char array Anton Shepelev <anton.txt@gmail.com> - 2019-10-14 01:39 +0300
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-14 01:51 +0100
Re: Sort char array Anton Shepelev <anton.txt@g{oogle}mail.com> - 2019-10-14 12:16 +0300
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-14 10:45 +0100
Re: Sort char array Anton Shepelev <anton.txt@g{oogle}mail.com> - 2019-10-14 13:16 +0300
Re: Sort char array Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-10-14 03:34 -0700
Lack of language I/O support (was Re: Sort char array, many posts ago) mark.bluemel@gmail.com - 2019-10-14 03:54 -0700
Re: Lack of language I/O support (was Re: Sort char array, many posts ago) scott@slp53.sl.home (Scott Lurndal) - 2019-10-14 13:36 +0000
Re: Lack of language I/O support (was Re: Sort char array, many posts ago) Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2019-10-14 09:49 -0400
Re: Lack of language I/O support (was Re: Sort char array, many posts ago) mark.bluemel@gmail.com - 2019-10-14 07:15 -0700
Re: Lack of language I/O support (was Re: Sort char array, many posts ago) scott@slp53.sl.home (Scott Lurndal) - 2019-10-14 14:55 +0000
Re: Lack of language I/O support (was Re: Sort char array, many posts ago) mark.bluemel@gmail.com - 2019-10-14 08:10 -0700
Re: Lack of language I/O support (was Re: Sort char array, many posts ago) scott@slp53.sl.home (Scott Lurndal) - 2019-10-14 16:21 +0000
Re: Lack of language I/O support (was Re: Sort char array, many posts ago) Siri Cruise <chine.bleu@yahoo.com> - 2019-10-14 09:25 -0700
Re: Sort char array Anton Shepelev <anton.txt@g{oogle}mail.com> - 2019-10-14 14:57 +0300
Re: Sort char array Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-10-14 08:24 -0700
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-14 16:40 +0100
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-14 16:17 +0200
Re: Sort char array Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-14 23:45 +0100
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-15 00:03 +0100
Re: Sort char array Thiago Adams <thiago.adams@gmail.com> - 2019-10-14 05:30 -0700
Re: Sort char array Anton Shepelev <anton.txt@g{oogle}mail.com> - 2019-10-14 16:05 +0300
Re: Sort char array Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-10-14 07:55 -0700
Re: Sort char array Thiago Adams <thiago.adams@gmail.com> - 2019-10-14 10:58 -0700
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-14 14:36 +0100
Re: Sort char array Thiago Adams <thiago.adams@gmail.com> - 2019-10-14 11:03 -0700
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-14 19:28 +0100
Re: Sort char array Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-10-14 08:17 -0700
Re: Sort char array Anton Shepelev <anton.txt@gmail.com> - 2019-10-15 00:26 +0300
Re: Sort char array Anton Shepelev <anton.txt@g{oogle}mail.com> - 2019-10-15 11:55 +0300
Re: Sort char array Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-10-16 04:24 -0700
Re: Sort char array Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-10-16 07:19 -0700
Re: Sort char array Anton Shepelev <anton.txt@g{oogle}mail.com> - 2019-10-16 18:17 +0300
Re: Sort char array Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-10-17 05:43 -0700
Re: Sort char array Anton Shepelev <anton.txt@g{oogle}mail.com> - 2019-10-17 18:01 +0300
Re: Sort char array Anton Shepelev <anton.txt@gmail.com> - 2019-10-19 00:39 +0300
Re: Sort char array Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-10-19 06:00 -0700
Re: Sort char array Anton Shepelev <anton.txt@g{oogle}mail.com> - 2019-11-08 18:38 +0300
Re: Sort char array Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-11-08 22:03 -0800
Re: Sort char array Richard Damon <Richard@Damon-Family.org> - 2019-10-12 18:49 -0400
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-13 00:25 +0100
Re: Sort char array Richard Damon <Richard@Damon-Family.org> - 2019-10-12 23:44 -0400
Re: Sort char array Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-12 13:45 +0100
Re: Sort char array James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-10-13 19:05 -0400
Re: Sort char array Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-10-12 13:16 -0700
Re: Sort char array Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-13 00:12 +0100
Re: Sort char array Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-10-13 14:18 -0700
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-13 23:10 +0100
Re: Sort char array Richard Damon <Richard@Damon-Family.org> - 2019-10-14 23:52 -0400
Re: Sort char array James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-10-15 11:48 -0400
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-15 18:14 +0100
Re: Sort char array Anton Shepelev <anton.txt@g{oogle}mail.com> - 2019-10-15 20:31 +0300
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-15 20:11 +0100
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-15 20:34 +0100
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-15 22:05 +0200
Re: Sort char array already5chosen@yahoo.com - 2019-10-15 13:27 -0700
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-16 10:11 +0100
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-16 12:42 +0200
Re: Sort char array already5chosen@yahoo.com - 2019-10-16 04:02 -0700
Re: Sort char array Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-10-17 05:51 -0700
Re: Sort char array Richard Damon <Richard@Damon-Family.org> - 2019-10-18 10:18 -0400
Re: Sort char array Keith Thompson <kst-u@mib.org> - 2019-10-18 12:05 -0700
Re: Sort char array Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-10-23 05:42 -0700
Re: Sort char array Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-10-23 05:02 -0700
Re: Sort char array raltbos@xs4all.nl (Richard Bos) - 2019-10-14 15:32 +0000
Re: Sort char array Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-10-14 08:57 -0700
Re: Sort char array Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-10-14 10:13 -0700
Re: Sort char array Anton Shepelev <anton.txt@gmail.com> - 2019-10-14 23:59 +0300
Re: Sort char array Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-10-17 06:08 -0700
Re: Sort char array already5chosen@yahoo.com - 2019-10-10 01:20 -0700
Re: Sort char array James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-10-10 20:15 -0400
Re: Sort char array already5chosen@yahoo.com - 2019-10-11 04:00 -0700
Re: Sort char array Richard Damon <Richard@Damon-Family.org> - 2019-10-11 07:53 -0400
Re: Sort char array James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-10-11 11:20 -0400
Re: Sort char array Keith Thompson <kst-u@mib.org> - 2019-10-11 11:16 -0700
Re: Sort char array James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-10-11 14:43 -0400
Re: Sort char array Keith Thompson <kst-u@mib.org> - 2019-10-11 11:51 -0700
Re: Sort char array raltbos@xs4all.nl (Richard Bos) - 2019-10-12 07:46 +0000
Re: Sort char array Richard Damon <Richard@Damon-Family.org> - 2019-10-12 09:49 -0400
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-12 12:29 +0200
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-12 12:20 +0100
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-12 13:38 +0200
Re: Sort char array Keith Thompson <kst-u@mib.org> - 2019-10-12 12:17 -0700
Re: Sort char array Richard Damon <Richard@Damon-Family.org> - 2019-10-12 20:20 -0400
Re: Sort char array Keith Thompson <kst-u@mib.org> - 2019-10-12 20:39 -0700
Re: Sort char array Anton Shepelev <anton.txt@gmail.com> - 2019-10-13 21:32 +0300
Re: Sort char array Richard Damon <Richard@Damon-Family.org> - 2019-10-14 07:38 -0400
Re: Sort char array Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-10-14 08:13 -0700
Re: Sort char array Richard Damon <Richard@Damon-Family.org> - 2019-10-15 07:45 -0400
Re: Sort char array chad <cdalten@gmail.com> - 2019-10-15 05:12 -0700
Re: Sort char array Keith Thompson <kst-u@mib.org> - 2019-10-15 13:04 -0700
Re: Sort char array Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-10-17 10:14 -0700
Re: Sort char array James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-10-15 12:24 -0400
Re: Sort char array Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-10-16 04:12 -0700
Re: Sort char array Keith Thompson <kst-u@mib.org> - 2019-10-16 14:21 -0700
Re: Sort char array James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-10-16 19:12 -0400
Re: Sort char array Keith Thompson <kst-u@mib.org> - 2019-10-16 16:33 -0700
Re: Sort char array James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-10-16 19:48 -0400
Re: Sort char array Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-10-18 06:57 -0700
Re: Sort char array Anton Shepelev <anton.txt@gmail.com> - 2019-10-13 21:22 +0300
Re: Sort char array Anton Shepelev <anton.txt@gmail.com> - 2019-10-11 01:02 +0300
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-07 17:01 +0200
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-07 12:24 +0200
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-07 12:18 +0100
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-07 14:11 +0200
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-07 15:22 +0100
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-07 17:17 +0200
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-07 20:52 +0100
Re: Sort char array Anton Shepelev <anton.txt@gmail.com> - 2019-10-08 00:45 +0300
Re: Sort char array already5chosen@yahoo.com - 2019-10-07 15:57 -0700
Re: Sort char array Anton Shepelev <anton.txt@gmail.com> - 2019-10-08 02:32 +0300
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-08 10:06 +0200
Re: Sort char array already5chosen@yahoo.com - 2019-10-08 03:21 -0700
Re: Sort char array Anton Shepelev <anton.txt@gmail.com> - 2019-10-09 00:34 +0300
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-08 11:23 +0200
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-08 09:59 +0200
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-08 11:39 +0100
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-08 14:05 +0200
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-08 15:06 +0100
Re: Sort char array scott@slp53.sl.home (Scott Lurndal) - 2019-10-08 14:38 +0000
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-08 17:34 +0200
Re: Sort char array scott@slp53.sl.home (Scott Lurndal) - 2019-10-08 16:38 +0000
Re: Sort char array Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-10-08 07:55 -0700
Re: Sort char array Anton Shepelev <anton.txt@g{oogle}mail.com> - 2019-10-08 18:31 +0300
Re: Sort char array scott@slp53.sl.home (Scott Lurndal) - 2019-10-08 16:39 +0000
Re: Sort char array Anton Shepelev <anton.txt@g{oogle}mail.com> - 2019-10-08 19:57 +0300
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-08 18:09 +0100
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-08 22:16 +0200
Re: Sort char array Anton Shepelev <anton.txt@gmail.com> - 2019-10-08 23:58 +0300
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-08 22:19 +0100
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-08 17:39 +0200
Re: Sort char array Anton Shepelev <anton.txt@gmail.com> - 2019-10-09 00:12 +0300
Re: Sort char array already5chosen@yahoo.com - 2019-10-09 09:48 -0700
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-09 19:49 +0100
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-08 17:29 +0200
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-08 17:56 +0100
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-08 22:25 +0200
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-09 00:02 +0100
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-09 13:41 +0200
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-09 14:03 +0100
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-09 15:53 +0200
Re: Sort char array scott@slp53.sl.home (Scott Lurndal) - 2019-10-09 14:39 +0000
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-09 15:58 +0100
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-10 22:43 +0100
Re: Sort char array Anton Shepelev <anton.txt@gmail.com> - 2019-10-11 01:45 +0300
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-11 01:00 +0100
Re: Sort char array Richard Damon <Richard@Damon-Family.org> - 2019-10-12 12:01 -0400
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-12 20:35 +0100
Re: Sort char array Anton Shepelev <anton.txt@gmail.com> - 2019-10-13 21:17 +0300
Re: Sort char array Richard Damon <Richard@Damon-Family.org> - 2019-10-14 07:45 -0400
Re: Sort char array Anton Shepelev <anton.txt@g{oogle}mail.com> - 2019-10-14 14:53 +0300
Re: Sort char array Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-10-09 02:02 -0700
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-09 10:36 +0100
Re: Sort char array Keith Thompson <kst-u@mib.org> - 2019-10-07 09:05 -0700
Re: Sort char array Keith Thompson <kst-u@mib.org> - 2019-10-07 08:59 -0700
Re: Sort char array Keith Thompson <kst-u@mib.org> - 2019-10-07 09:00 -0700
Re: Sort char array Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-07 17:02 +0100
Re: Sort char array Richard Damon <Richard@Damon-Family.org> - 2019-10-06 19:57 -0400
Re: Sort char array Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-10-09 06:38 -0700
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-05 17:14 +0100
Re: Sort char array DFS <nospam@dfs.com> - 2019-10-05 13:06 -0400
Re: Sort char array already5chosen@yahoo.com - 2019-10-06 02:24 -0700
Re: Sort char array already5chosen@yahoo.com - 2019-10-06 05:13 -0700
Re: Sort char array Anton Shepelev <anton.txt@gmail.com> - 2019-10-06 16:04 +0300
Re: Sort char array already5chosen@yahoo.com - 2019-10-06 07:13 -0700
Re: Sort char array DFS <nospam@dfs.com> - 2019-10-06 18:23 -0400
Re: Sort char array Anton Shepelev <anton.txt@gmail.com> - 2019-10-06 15:41 +0300
Re: Sort char array Keith Thompson <kst-u@mib.org> - 2019-10-06 12:46 -0700
Re: Sort char array Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2019-10-07 04:00 +0800
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-07 09:46 +0200
Re: Sort char array DFS <nospam@dfs.com> - 2019-10-07 22:49 -0400
Re: Sort char array Anton Shepelev <anton.txt@g{oogle}mail.com> - 2019-10-08 12:24 +0300
Re: Sort char array DFS <nospam@dfs.com> - 2019-10-08 09:28 -0400
Re: Sort char array Anton Shepelev <anton.txt@gmail.com> - 2019-10-08 23:49 +0300
Re: Sort char array DFS <nospam@dfs.com> - 2019-10-08 18:18 -0400
Re: Sort char array already5chosen@yahoo.com - 2019-10-08 03:34 -0700
Re: Sort char array Anton Shepelev <anton.txt@g{oogle}mail.com> - 2019-10-08 14:36 +0300
Re: Sort char array Anton Shepelev <anton.txt@g{oogle}mail.com> - 2019-10-08 15:34 +0300
Re: Sort char array already5chosen@yahoo.com - 2019-10-08 05:54 -0700
Re: Sort char array Anton Shepelev <anton.txt@g{oogle}mail.com> - 2019-10-08 16:01 +0300
Re: Sort char array already5chosen@yahoo.com - 2019-10-08 06:31 -0700
Re: Sort char array Anton Shepelev <anton.txt@gmail.com> - 2019-10-09 00:30 +0300
Re: Sort char array already5chosen@yahoo.com - 2019-10-09 10:14 -0700
Re: Sort char array already5chosen@yahoo.com - 2019-10-08 06:26 -0700
Re: Sort char array Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-05 02:46 +0100
Re: Sort char array DFS <nospam@dfs.com> - 2019-10-05 00:19 -0400
Re: Sort char array Barry Schwarz <schwarzb@dqel.com> - 2019-10-04 22:26 -0700
Re: OT Re: Sort char array Barry Schwarz <schwarzb@delq.com> - 2019-10-05 06:33 -0700
Re: Sort char array Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-05 16:46 +0200
Re: Sort char array "Oliver S." <Follow.Me@gmx.net> - 2019-10-05 16:54 +0200
Re: Sort char array "Oliver S." <Follow.Me@gmx.net> - 2019-10-05 17:14 +0200
Re: Sort char array DFS <nospam@dfs.com> - 2019-10-05 11:34 -0400
Re: Sort char array Mateusz Viste <mateusz@wont.tell> - 2019-10-05 15:43 +0000
Re: Sort char array Richard Damon <Richard@Damon-Family.org> - 2019-10-05 17:29 -0400
Re: Sort char array already5chosen@yahoo.com - 2019-10-06 02:14 -0700
Re: Sort char array Mateusz Viste <mateusz@wont.tell> - 2019-10-06 09:58 +0000
Re: Sort char array already5chosen@yahoo.com - 2019-10-06 03:11 -0700
Re: Sort char array already5chosen@yahoo.com - 2019-10-06 03:35 -0700
Re: Sort char array Anton Shepelev <anton.txt@gmail.com> - 2019-10-06 15:57 +0300
Re: Sort char array Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-06 16:12 +0100
Re: Sort char array Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-10-09 02:06 -0700
Re: Sort char array Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-10-07 07:28 -0700
Re: Sort char array Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-07 17:51 +0100
Re: Sort char array Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2019-10-08 18:31 +0800
Re: Sort char array already5chosen@yahoo.com - 2019-10-08 03:59 -0700
Re: Sort char array Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-10-09 02:14 -0700
Re: Sort char array Anton Shepelev <anton.txt@g{oogle}mail.com> - 2019-10-08 14:34 +0300
Re: Sort char array Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2019-10-08 22:41 +0800
Re: Sort char array already5chosen@yahoo.com - 2019-10-06 02:03 -0700
Re: Sort char array Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-06 13:25 +0200
Re: Sort char array Anton Shepelev <anton.txt@gmail.com> - 2019-10-06 15:45 +0300
Re: Sort char array Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-06 14:59 +0200
Re: Sort char array Anton Shepelev <anton.txt@gmail.com> - 2019-10-06 16:11 +0300
Re: Sort char array Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-06 15:15 +0200
Re: Sort char array Anton Shepelev <anton.txt@gmail.com> - 2019-10-06 16:20 +0300
Re: Sort char array Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-06 15:35 +0200
Re: Sort char array Richard Damon <Richard@Damon-Family.org> - 2019-10-06 13:04 -0400
Re: Sort char array already5chosen@yahoo.com - 2019-10-06 08:44 -0700
Re: Sort char array Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-06 18:01 +0200
Re: Sort char array already5chosen@yahoo.com - 2019-10-06 09:42 -0700
Re: Sort char array Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-06 19:21 +0200
Re: Sort char array Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-06 21:51 +0100
Re: Sort char array Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-07 04:41 +0200
Re: Sort char array Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-07 16:45 +0100
Re: Sort char array Anton Shepelev <anton.txt@g{oogle}mail.com> - 2019-10-07 19:11 +0300
Re: Sort char array Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-07 21:10 +0100
Re: Sort char array Anton Shepelev <anton.txt@gmail.com> - 2019-10-08 00:43 +0300
Re: Sort char array James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-10-07 15:51 -0400
Re: Sort char array Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-10-09 01:48 -0700
Re: Sort char array James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-10-07 00:42 -0400
Re: Sort char array John Bode <jfbode1029@gmail.com> - 2019-10-07 16:05 -0700
Re: Sort char array DFS <nospam@dfs.com> - 2019-10-07 20:06 -0400
Re: Sort char array John Bode <jfbode1029@gmail.com> - 2019-10-08 08:34 -0700
Re: Sort char array Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-08 01:09 +0100
Re: Sort char array DFS <nospam@dfs.com> - 2019-10-07 20:12 -0400
Re: Sort char array Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-08 01:44 +0100
Re: Sort char array DFS <nospam@dfs.com> - 2019-10-07 22:02 -0400
Re: Sort char array Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-08 03:24 +0100
Re: Sort char array Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-09 01:42 +0100
Re: Sort char array John Bode <jfbode1029@gmail.com> - 2019-10-09 11:14 -0700
Re: Sort char array Anton Shepelev <anton.txt@gmail.com> - 2019-10-10 00:52 +0300
Re: Sort char array John Bode <jfbode1029@gmail.com> - 2019-10-08 08:20 -0700
Re: Sort char array Anton Shepelev <anton.txt@gmail.com> - 2019-10-09 00:20 +0300
Re: Sort char array James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-10-08 18:48 -0400
Re: Sort char array Anton Shepelev <anton.txt@gmail.com> - 2019-10-09 02:07 +0300
Re: Sort char array Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-10-09 02:29 -0700
Re: Sort char array Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-10-09 09:43 -0700
Re: Sort char array already5chosen@yahoo.com - 2019-10-09 09:37 -0700
Re: Sort char array Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-10-09 02:22 -0700
Re: Sort char array already5chosen@yahoo.com - 2019-10-15 11:19 -0700
Page 18 of 25 — ← Prev page 1 … 16 17 [18] 19 20 … 25 Next page →
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-10-07 20:52 +0100 |
| Message-ID | <vIMmF.1152836$HWr.797087@fx36.am4> |
| In reply to | #146691 |
On 07/10/2019 16:17, David Brown wrote: > On 07/10/2019 16:22, Bart wrote: >> I have an Rpi4. Tcc runs at about 300Klps on that. I think the RPi1 is >> about 1/4 the speed, which means tcc would compile C at some 70,000 >> lines per second, which is still considerably faster than gcc on my PC! > > Nobody /cares/ if you can do 300 Klps compilation - especially not for > compiling /your/ code. It is a meaningless figure. What people - > normal programmers, that is - care about in compiler speed is that their > build process is fast enough with /their/ compiler, compiling /their/ > code with /their/ choice of options. Sorry, didn't you make the point the RPi1 was too slow for compilation (if not, then what is the problem with it?)? Then when someone suggests using a compiler that is 1-2 magnitudes faster, you dismiss it out of hand! I've just tried to compile cc32.c on the RPi1 (a 35 Kloc file). tcc took 1.5 seconds (so 23,000 lines per second) gcc -O3 took 500 seconds (so 70 lines per second). The difference? The gcc-O3-compiled version ran twice as fast, but took over 300 times longer to compile. gcc -O0 took 75 seconds, 50 times as long as tcc, and gave a program 30% faster than one compiled with tcc. IMV this makes tcc a perfect C compiler for something like the RPi1. Since it runs a full Linux OS, why do you also need a massive PC sitting next to it? A 1000-line program, took 0.16 seconds with tcc, 3.3 seconds with gcc-O0, and 18 seconds with gcc-O3. I know which one I would choose to use most of the time. And which one would be the more practical back-end of a fast compiler than generates verified C code.
[toc] | [prev] | [next] | [standalone]
| From | Anton Shepelev <anton.txt@gmail.com> |
|---|---|
| Date | 2019-10-08 00:45 +0300 |
| Message-ID | <20191008004557.a4b85262fd94c11a4d50fca3@gmail.com> |
| In reply to | #146706 |
Bart: > A 1000-line program, took 0.16 seconds with tcc, 3.3 > seconds with gcc-O0, and 18 seconds with gcc-O3. > > I know which one I would choose to use most of the time. > And which one would be the more practical back-end of a > fast compiler than generates verified C code. If you need both high performace and quick compilation, use tcc for development and gcc -O3 for release. -- () ascii ribbon campaign -- against html e-mail /\ http://preview.tinyurl.com/qcy6mjc [archived]
[toc] | [prev] | [next] | [standalone]
| From | already5chosen@yahoo.com |
|---|---|
| Date | 2019-10-07 15:57 -0700 |
| Message-ID | <c135f254-6833-44d0-91d7-a3503efa565b@googlegroups.com> |
| In reply to | #146710 |
On Tuesday, October 8, 2019 at 12:46:05 AM UTC+3, Anton Shepelev wrote: > Bart: > > > A 1000-line program, took 0.16 seconds with tcc, 3.3 > > seconds with gcc-O0, and 18 seconds with gcc-O3. > > > > I know which one I would choose to use most of the time. > > And which one would be the more practical back-end of a > > fast compiler than generates verified C code. > > If you need both high performace and quick compilation, use > tcc for development and gcc -O3 for release. > > -- > () ascii ribbon campaign -- against html e-mail > /\ http://preview.tinyurl.com/qcy6mjc [archived] Your confidence in quality of 'gcc -O3' code generation shows that you rarely bother to compare speed of its results against other popular compilers or even against 'gcc -O2' and 'gcc -O1'.
[toc] | [prev] | [next] | [standalone]
| From | Anton Shepelev <anton.txt@gmail.com> |
|---|---|
| Date | 2019-10-08 02:32 +0300 |
| Message-ID | <20191008023245.1ed212222ba82a5cb3de920c@gmail.com> |
| In reply to | #146712 |
already5chosen: > Your confidence in quality of 'gcc -O3' code generation > shows that you rarely bother to compare speed of its > results against other popular compilers or even against > 'gcc -O2' and 'gcc -O1'. I have compared it with -O2 and -O1, and saw a significant improvement for my single-threaded pixel-perfect scaler for DOSBox with aspect-ratio approximation. I have not tested the efficiency of machine code generated by other compilers. -- () ascii ribbon campaign -- against html e-mail /\ http://preview.tinyurl.com/qcy6mjc [archived]
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-10-08 10:06 +0200 |
| Message-ID | <qnhg1q$tu2$1@dont-email.me> |
| In reply to | #146715 |
On 08/10/2019 01:32, Anton Shepelev wrote: > already5chosen: > >> Your confidence in quality of 'gcc -O3' code generation >> shows that you rarely bother to compare speed of its >> results against other popular compilers or even against >> 'gcc -O2' and 'gcc -O1'. > > I have compared it with -O2 and -O1, and saw a significant > improvement for my single-threaded pixel-perfect scaler for > DOSBox with aspect-ratio approximation. I have not tested > the efficiency of machine code generated by other compilers. > Results for gcc -O3 vary significantly. For some code, it can give significantly faster results than -O2. For a lot of code, however, there is only minor improvement, and for some code it runs slower. gcc -O2 is usually the best choice when you want "give me close to the fastest generated code without too much extra effort on my part". gcc -O1 is for "give me reasonably efficient object code, fairly quickly, and without too much re-arrangement because I want to do some debugging or admire the generated assembly". (And the default, gcc -O0, is for "I don't know how to use my tools".) If you want faster results than gcc -O2, you will want to try a range of flags. Things like "-mmarch=native" (for x86) can make a big difference. You might want to use pragmas or attributes to compile different parts of the code with different flags, or to make a point of using vectors or alignment specifiers in the code to improve vectorisation. It is not often that simply changing -O2 to -O3 gives a solid speed-up, but it happens.
[toc] | [prev] | [next] | [standalone]
| From | already5chosen@yahoo.com |
|---|---|
| Date | 2019-10-08 03:21 -0700 |
| Message-ID | <576bab9f-9b10-4c34-b4b4-2618b72ba17b@googlegroups.com> |
| In reply to | #146715 |
On Tuesday, October 8, 2019 at 2:32:53 AM UTC+3, Anton Shepelev wrote: > already5chosen: > > > Your confidence in quality of 'gcc -O3' code generation > > shows that you rarely bother to compare speed of its > > results against other popular compilers or even against > > 'gcc -O2' and 'gcc -O1'. > > I have compared it with -O2 and -O1, and saw a significant > improvement for my single-threaded pixel-perfect scaler for > DOSBox with aspect-ratio approximation. I have not tested > the efficiency of machine code generated by other compilers. > > -- > () ascii ribbon campaign -- against html e-mail > /\ http://preview.tinyurl.com/qcy6mjc [archived] I suppose, your scaler spends most of the runtime within simple vectorizable loops or, at very least, loops that can profit from compiler-level unrolling. 'gcc -O3' is indeed much better than 'gcc -O2' in such cases. However if the computations are floating-point than -O3 rarely gains much without -ffast-math or similar flag that relaxes 'C' rules for FP semantics (-fassociative-math component of fast-math appears to be the most important). However an absolute majority of world's 'C' code is not vectorizable and does not improve much from compiler-level loop unrolling (when it matters and critical people tends to unroll at source level.
[toc] | [prev] | [next] | [standalone]
| From | Anton Shepelev <anton.txt@gmail.com> |
|---|---|
| Date | 2019-10-09 00:34 +0300 |
| Message-ID | <20191009003447.d756f59134a1258d46158770@gmail.com> |
| In reply to | #146732 |
already5chosen to Anton Shepelev: > > I have compared it with -O2 and -O1, and saw a > > significant improvement for my single-threaded pixel- > > perfect scaler for DOSBox with aspect-ratio > > approximation. I have not tested the efficiency of > > machine code generated by other compilers. > > I suppose, your scaler spends most of the runtime within > simple vectorizable loops or, at very least, loops that > can profit from compiler-level unrolling. I should think so, yes, but unrolling a loop with a variable upper bound (that depends on the x and y scales) is not outright trivial. > 'gcc -O3' is indeed much better than 'gcc -O2' in such > cases. However if the computations are floating-point > than -O3 rarely gains much without -ffast-math or similar > flag that relaxes 'C' rules for FP semantics > (-fassociative-math component of fast-math appears to be > the most important). > > However an absolute majority of world's 'C' code is not > vectorizable and does not improve much from compiler-level > loop unrolling (when it matters and critical people tends > to unroll at source level. Thanks for the information. -- () ascii ribbon campaign -- against html e-mail /\ http://preview.tinyurl.com/qcy6mjc [archived]
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-10-08 11:23 +0200 |
| Message-ID | <qnhkhm$nja$1@dont-email.me> |
| In reply to | #146710 |
On 07/10/2019 23:45, Anton Shepelev wrote: > Bart: > >> A 1000-line program, took 0.16 seconds with tcc, 3.3 >> seconds with gcc-O0, and 18 seconds with gcc-O3. >> >> I know which one I would choose to use most of the time. >> And which one would be the more practical back-end of a >> fast compiler than generates verified C code. > > If you need both high performace and quick compilation, use > tcc for development and gcc -O3 for release. > I would say the opposite. Use gcc for your development. The main purpose of development is to write correct code, and for that you want the best tools for spotting problems and helping you track them down. You want a tool with lots of warnings, and debugging aids like sanitizers. The only purpose (other than fun and education) for something like tcc is when you really need a C compiler, and have to run it on a weak host like an RPi1. So you might use it if you have to do "./configure && make && make install" for some code on an RPi. But that is for code that you have finished developing and debugging.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-10-08 09:59 +0200 |
| Message-ID | <qnhfki$lp8$1@dont-email.me> |
| In reply to | #146706 |
On 07/10/2019 21:52, Bart wrote: > On 07/10/2019 16:17, David Brown wrote: >> On 07/10/2019 16:22, Bart wrote: > >>> I have an Rpi4. Tcc runs at about 300Klps on that. I think the RPi1 is >>> about 1/4 the speed, which means tcc would compile C at some 70,000 >>> lines per second, which is still considerably faster than gcc on my PC! >> >> Nobody /cares/ if you can do 300 Klps compilation - especially not for >> compiling /your/ code. It is a meaningless figure. What people - >> normal programmers, that is - care about in compiler speed is that their >> build process is fast enough with /their/ compiler, compiling /their/ >> code with /their/ choice of options. > > Sorry, didn't you make the point the RPi1 was too slow for compilation > (if not, then what is the problem with it?)? The RPi1 is too slow for a lot of uses - the RPi3 was a big step up in real processor speed, and in memory, making it much more useful for interactive work. If you have tried to run a desktop and development environment on a RPi1, it is simply too much for it - regardless of the compiler or the sizes of your code. But on an RPi3 you can run a reasonable, if limited, development system. > > Then when someone suggests using a compiler that is 1-2 magnitudes > faster, you dismiss it out of hand! If your compiler can't do the job I need, I don't care if it is instantaneous - it won't work. And for compilers that can do the job, if a compile time is under a couple of seconds, it is fast enough for the time not to be an issue. And fast enough is fast enough - 2 seconds, or 2 milliseconds, does not matter. What /does/ matter, and where a gcc-based development is several orders of magnitude faster than a tcc-based or bcc-based development, is when the static error checking identifies problems at compile time rather than leaving them for testing (or years or months later, during porting to a different target). > > I've just tried to compile cc32.c on the RPi1 (a 35 Kloc file). > > tcc took 1.5 seconds (so 23,000 lines per second) > > gcc -O3 took 500 seconds (so 70 lines per second). So what? No one writes 35 Kloc C files. No one - except you - compiles code generated by your tools. So no one - except you - cares how long that takes. (And few people use gcc -O3, since it is well known, and documented, that it takes a lot longer to compile than -O2, produces larger files, and only sometimes runs faster.) > > The difference? The gcc-O3-compiled version ran twice as fast, but took > over 300 times longer to compile. Many people aim to run their programs, rather than endlessly fiddle with them. The balance /should/ be heavily towards faster run times despite slower compile times. Otherwise, why are you using a compiled language in the first place, rather than a higher level interpreted (or byte-compiled) language? > > gcc -O0 took 75 seconds, 50 times as long as tcc, and gave a program 30% > faster than one compiled with tcc. > > IMV this makes tcc a perfect C compiler for something like the RPi1. That is like talking about the best surround sound movie system to install on your bike - it is a daft concept in the first place. If you are desperate to run a C compiler on a RPi1, then I agree tcc could be a better choice than gcc. But a far, far better idea is not to use your RPi1 for C development. > Since it runs a full Linux OS, why do you also need a massive PC sitting > next to it? > > > A 1000-line program, took 0.16 seconds with tcc, 3.3 seconds with > gcc-O0, and 18 seconds with gcc-O3. > > I know which one I would choose to use most of the time. And which one > would be the more practical back-end of a fast compiler than generates > verified C code. > "Verified C code" ? Verified by whom, or what? Someone who is totally determined to ignore the rules of C? If the end result is good enough for your uses, that's fine - you are the only user. And if you'd rather do other things than get the code right, that's also fine. But don't pretend it is "verified C code".
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-10-08 11:39 +0100 |
| Message-ID | <IHZmF.1040013$WI2.990512@fx34.am4> |
| In reply to | #146726 |
On 08/10/2019 08:59, David Brown wrote:
> On 07/10/2019 21:52, Bart wrote:
>> Sorry, didn't you make the point the RPi1 was too slow for compilation
>> (if not, then what is the problem with it?)?
>
> The RPi1 is too slow for a lot of uses - the RPi3 was a big step up in
> real processor speed, and in memory, making it much more useful for
> interactive work. If you have tried to run a desktop and development
> environment on a RPi1, it is simply too much for it - regardless of the
> compiler or the sizes of your code. But on an RPi3 you can run a
> reasonable, if limited, development system.
Yet 28 million Raspberry Pis have been sold, of which 1 million are the
Rpi 4 (don't how many were Rpi 1s).
Not all users will also have had a desktop PC, running a gcc
cross-compiler for ARM32 (and specifically for the variety and version
of Linux running on their Pi) and with the means to instantly download
the result to the Pi board.
And if they did know how to do all that, and had the funds to support
it, many would not have bothered with the Raspberry Pi.
>> Then when someone suggests using a compiler that is 1-2 magnitudes
>> faster, you dismiss it out of hand!
>
> If your compiler can't do the job I need, I don't care if it is
> instantaneous - it won't work.
Oh, I see the problem now - you think I'm talking about my (Bart's) C
compiler. No, I mean Tiny C.
And for compilers that can do the job,
> if a compile time is under a couple of seconds, it is fast enough for
> the time not to be an issue. And fast enough is fast enough - 2
> seconds, or 2 milliseconds, does not matter. What /does/ matter, and
> where a gcc-based development is several orders of magnitude faster than
> a tcc-based or bcc-based development, is when the static error checking
> identifies problems at compile time rather than leaving them for testing
> (or years or months later, during porting to a different target).
Fine, then they run gcc periodically (during lunch-break) to identify
such problems. But not all users will be professionals with paying
customers where bugs surfacing at the customer site are undesirable.
Some may be hobbyists doing it for fun. When you got your first machine
that could compile C, did you also buy a business computer to compile
your programs with?
>> tcc took 1.5 seconds (so 23,000 lines per second)
>>
>> gcc -O3 took 500 seconds (so 70 lines per second).
>
> So what? No one writes 35 Kloc C files.
How do you know that? The amalgamated sqlite3.c is 220,000 lines. People
running languages with a C back-end might also generate such files.
A smaller 6000-file program took 13 seconds with gcc-O0, and 100 seconds
optimised. Six 1000-line programs would take 20 seconds unoptimised.
With tcc it's fractions of a second.
No one - except you - compiles
> code generated by your tools. So no one - except you - cares how long
> that takes.
EVERYONE cares how long it takes, unless it's so fast that you don't
even notice.
(And few people use gcc -O3, since it is well known, and
> documented, that it takes a lot longer to compile than -O2, produces
> larger files, and only sometimes runs faster.)
You can make the same comparison between tcc and gcc -O0! On that
6000-line program:
tcc 0.4 seconds 1 x
gcc -O0 12.8 32 x
gcc -O1 28.0 70 x
gcc -O2 50.0 125 x
gcc -O0 90.0 225 x
(However for this bignum demo, which is 64-bit code, tcc runs poorly,
being 4x as slow as gcc-O0 and 6x as slow as gcc-O3. On the bigger 35K
project, a compiler, tcc was only 2x as slow as gcc-O3, but was 500
times faster to compile.)
>>
>> The difference? The gcc-O3-compiled version ran twice as fast, but took
>> over 300 times longer to compile.
>
> Many people aim to run their programs, rather than endlessly fiddle with
> them.
Many people are developing and debugging their programs, so the
edit-compile-run cycle should be as fast as possible. If they want a
fast production program, then they can put it through gcc, when it's
finished and they only need to do it once.
(This is one benefit of the C back-end to my language. On compiler
projects, it can make them 50% faster, but it takes 80 times longer to
build.)
> The balance /should/ be heavily towards faster run times despite
> slower compile times.
Rubbish.
Otherwise, why are you using a compiled language
> in the first place, rather than a higher level interpreted (or
> byte-compiled) language?
During development, when you will mainly be testing with small inputs
and small runtimes, the speed of the program is of less importance.
>> IMV this makes tcc a perfect C compiler for something like the RPi1.
>
> That is like talking about the best surround sound movie system to
> install on your bike - it is a daft concept in the first place.
Rubbish. Even the RPi1 is a supercomputer compared to what we were all
using in the 80s and even the 90s. You're looking at the effect of
vastly bloated and inefficient software.
> If you are desperate to run a C compiler on a RPi1, then I agree tcc
> could be a better choice than gcc. But a far, far better idea is not to
> use your RPi1 for C development.
Certainly it would be a poor choice for your heavyweight tools.
>> I know which one I would choose to use most of the time. And which one
>> would be the more practical back-end of a fast compiler than generates
>> verified C code.
>
> "Verified C code" ? Verified by whom, or what? Someone who is totally
> determined to ignore the rules of C?
You did notice that I mentioned 'back-end'? So the C is generated
programmatically.
If there is something wrong with the output of c compiler, such that it
generates compile/assemble/link/load errors in the generated C or ASM or
OBJ or EXE, then that signifies a bug in the compiler.
Normal programming errors will already be picked up the by the original
language compiler.
> If the end result is good enough for your uses, that's fine - you are
> the only user.
Of tcc? No I'm not.
> But don't pretend it is "verified C code".
That's your opinion. For me, if it passes with how I invoke gcc, then
the C is adequate, even if it doesn't meet your standards (which would
require that I do nothing else except refine the generated C, and forget
what it is I'm trying to do in the first place, which is to temporarily
port my software to a target I don't yet support directly, or make it a
bit faster).
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-10-08 14:05 +0200 |
| Message-ID | <qnhu2c$q5u$1@dont-email.me> |
| In reply to | #146735 |
On 08/10/2019 12:39, Bart wrote: > On 08/10/2019 08:59, David Brown wrote: >> On 07/10/2019 21:52, Bart wrote: > >>> Sorry, didn't you make the point the RPi1 was too slow for compilation >>> (if not, then what is the problem with it?)? >> >> The RPi1 is too slow for a lot of uses - the RPi3 was a big step up in >> real processor speed, and in memory, making it much more useful for >> interactive work. If you have tried to run a desktop and development >> environment on a RPi1, it is simply too much for it - regardless of the >> compiler or the sizes of your code. But on an RPi3 you can run a >> reasonable, if limited, development system. > > Yet 28 million Raspberry Pis have been sold, of which 1 million are the > Rpi 4 (don't how many were Rpi 1s). RPi1's are great devices. But they are painful if you try to run a desktop on them, and not good as development platforms. Most people don't do heavy work on them - they are fine, for example, for python coding. By the time you get to RPi3, it is perfectly good for a desktop - you can run an IDE, or a browser, without feeling it to be too slow. > > Not all users will also have had a desktop PC, running a gcc > cross-compiler for ARM32 (and specifically for the variety and version > of Linux running on their Pi) and with the means to instantly download > the result to the Pi board. > > And if they did know how to do all that, and had the funds to support > it, many would not have bothered with the Raspberry Pi. The primary uses of RPi's is for fun and learning. In both cases, you put up with slower or more limited systems, and you are also working with much smaller programs. The typical program developed using a Pi is a few hundred lines of Python or Lua - not many thousands of lines of C. > >>> Then when someone suggests using a compiler that is 1-2 magnitudes >>> faster, you dismiss it out of hand! >> >> If your compiler can't do the job I need, I don't care if it is >> instantaneous - it won't work. > > Oh, I see the problem now - you think I'm talking about my (Bart's) C > compiler. No, I mean Tiny C. I thought you were talking about both. I was. I appreciate that tcc has more features than bcc (that is not a criticism of bcc - your compiler only needs the features /you/ use). Neither has the features I need in a C compiler for my usual work. Without support for the targets I use, both are useless - no matter how fast they might be. Next time I need to work on a C program on a PC, I will give tcc a try to see how it would differ from gcc. > > And for compilers that can do the job, >> if a compile time is under a couple of seconds, it is fast enough for >> the time not to be an issue. And fast enough is fast enough - 2 >> seconds, or 2 milliseconds, does not matter. What /does/ matter, and >> where a gcc-based development is several orders of magnitude faster than >> a tcc-based or bcc-based development, is when the static error checking >> identifies problems at compile time rather than leaving them for testing >> (or years or months later, during porting to a different target). > > Fine, then they run gcc periodically (during lunch-break) to identify > such problems. But not all users will be professionals with paying > customers where bugs surfacing at the customer site are undesirable. Are you suggesting that non-professionals /like/ bugs to surface at customer (or user) sites? Are you suggesting that amateurs or hobby users would prefer to find their bugs later, while running their programs, rather than earlier on? Certainly hobby users are going to be more accepting of bugs in their own code, found while using their code. And they are going to be unwilling to pay many thousands for top-range static error checking tools, or to have formal code reviews, or even to write decent documentation. But I can't believe that anyone would /rather/ find their bugs later than earlier. I also think that even hobby programmers spend more than one or two seconds on their lunch break. > > Some may be hobbyists doing it for fun. When you got your first machine > that could compile C, did you also buy a business computer to compile > your programs with? > My first C compiler was for a ZX Spectrum, /long/ ago. I bought C for the computer, not the computer for C. But as usual you are /wildly/ exaggerating the question of compiler speed. I have never heard anyone - except you - view the speed of gcc as a hinder to using it for C. For C++, yes - but that is a different situation where you might be compiling millions of lines of complex template headers (and the solution there is C++ modules to avoid re-compilation, not faster compilation). >>> tcc took 1.5 seconds (so 23,000 lines per second) >>> >>> gcc -O3 took 500 seconds (so 70 lines per second). >> >> So what? No one writes 35 Kloc C files. > > How do you know that? The amalgamated sqlite3.c is 220,000 lines. People > running languages with a C back-end might also generate such files. The amalgamated sqlite3.c file is not a C file that anyone wrote. It is an /amalgamation/ of C files. It is not something you compile often during development - when working on a project like that, you write and compile the individual files. Just for fun, I tried it - yes, it is quite time-consuming. "gcc -O3" on sqlite3.c took 21 seconds on my system for its first compile, while tcc took 0.1 seconds. If I had a project using sqlite, and was not using the library versions (highly unlikely), and was not using a build system like make that avoids unnecessary re-compiles (even less likely), then that is slow enough to be annoying. So - since I know about build tools - I'd use ccache. Compilation is now 25 milliseconds - about four times as fast as tcc. Compilation time with gcc, for C code, is rarely a problem. And if it is, there are ways to deal with it - without having to use weaker compilers. > > A smaller 6000-file program took 13 seconds with gcc-O0, and 100 seconds > optimised. Six 1000-line programs would take 20 seconds unoptimised. Either you have a pathologically difficult compile, or a painfully slow computer. > With tcc it's fractions of a second. > <snip the rest>
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-10-08 15:06 +0100 |
| Message-ID | <LJ0nF.748902$bS1.411269@fx13.am4> |
| In reply to | #146740 |
On 08/10/2019 13:05, David Brown wrote:
> On 08/10/2019 12:39, Bart wrote:
> The primary uses of RPi's is for fun and learning. In both cases, you
> put up with slower or more limited systems, and you are also working
> with much smaller programs. The typical program developed using a Pi is
> a few hundred lines of Python or Lua - not many thousands of lines of C.
I don't know what people do with them. But that they come with 1-4GB RAM
suggests they might be using or developing some programs that need 1-4GB
RAM. Those are not necessarily small.
Since they are full Linux systems, they will want to install/build
anything that comes with a regular Linux system. I do know that many
like to push their systems, languages and compilers to the limits.
> Are you suggesting that non-professionals /like/ bugs to surface at
> customer (or user) sites?
Non-professionals won't have paying customers.
Are you suggesting that amateurs or hobby
> users would prefer to find their bugs later, while running their
> programs, rather than earlier on?
There are many other ways of finding/avoiding bugs. One way is not to
use C at all as it has too many opportunity for errors. Can your C
compiler detect these three errors:
for (i=0; i<=N ; ++j)
f(i);
g(i);
In my syntax it would be (using 1-based indexing):
for i to N do
f(i)
od
g(i)
so either you can't make the same errors, or it would be more obvious
(eg. writing N+1).
> But as usual you are /wildly/ exaggerating the question of compiler
> speed. I have never heard anyone - except you - view the speed of gcc
> as a hinder to using it for C.
So why did anyone even bother creating something like Tiny C? (I used to
think it was a toy compiler, until I tried it.)
>> How do you know that? The amalgamated sqlite3.c is 220,000 lines. People
>> running languages with a C back-end might also generate such files.
> Just for fun, I tried it - yes, it is quite time-consuming. "gcc -O3"
> on sqlite3.c took 21 seconds on my system for its first compile, while
> tcc took 0.1 seconds.
Your machine is about 3 times the speed of mine then. (That would make
the compiler for my main language, when I've finished removing that
time-consuming intermediate ASM stage, run at over 1 million lines per
second on your computer.)
If I had a project using sqlite, and was not
> using the library versions (highly unlikely), and was not using a build
> system like make that avoids unnecessary re-compiles (even less likely),
> then that is slow enough to be annoying. So - since I know about build
> tools - I'd use ccache. Compilation is now 25 milliseconds - about four
> times as fast as tcc.
Four times as fast as tcc at, what - compiling this source file or not
compiling it? Because my car is always going to be faster than yours on
any round trip - if I can find a way of not doing the journey!
But it does sound like you've found the perfect solution for RPi1
systems - just use ccache, and it will be 4 times as fast as tcc.
Or is it not that simple ...
BTW it sounds like gcc compile times /are/ a problem, if approaches like
precompiled headers, conditional make files and 'ccache' need to be
employed.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2019-10-08 14:38 +0000 |
| Message-ID | <1c1nF.137420$zU2.32028@fx01.iad> |
| In reply to | #146747 |
Bart <bc@freeuk.com> writes: >On 08/10/2019 13:05, David Brown wrote: >> On 08/10/2019 12:39, Bart wrote: > >> The primary uses of RPi's is for fun and learning. In both cases, you >> put up with slower or more limited systems, and you are also working >> with much smaller programs. The typical program developed using a Pi is >> a few hundred lines of Python or Lua - not many thousands of lines of C. > >I don't know what people do with them. But that they come with 1-4GB RAM >suggests they might be using or developing some programs that need 1-4GB >RAM. Those are not necessarily small. Large numbers of them are never used for programming, but rather as IOT devices. Probably the vast majority of them. > >Since they are full Linux systems, they will want to install/build >anything that comes with a regular Linux system. I do know that many >like to push their systems, languages and compilers to the limits. Unlikely. It's far more likely that the most minimum linux installation is used (uboot + kernel + busybox) on the vast majority of raspberry pi boards. > >BTW it sounds like gcc compile times /are/ a problem, if approaches like >precompiled headers, conditional make files and 'ccache' need to be >employed. What leads you to believe that any of those things _need_ to be employed?
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-10-08 17:34 +0200 |
| Message-ID | <qnia9a$6po$1@dont-email.me> |
| In reply to | #146748 |
On 08/10/2019 16:38, Scott Lurndal wrote: > Bart <bc@freeuk.com> writes: >> On 08/10/2019 13:05, David Brown wrote: >>> On 08/10/2019 12:39, Bart wrote: >> >>> The primary uses of RPi's is for fun and learning. In both cases, you >>> put up with slower or more limited systems, and you are also working >>> with much smaller programs. The typical program developed using a Pi is >>> a few hundred lines of Python or Lua - not many thousands of lines of C. >> >> I don't know what people do with them. But that they come with 1-4GB RAM >> suggests they might be using or developing some programs that need 1-4GB >> RAM. Those are not necessarily small. > > Large numbers of them are never used for programming, but rather as > IOT devices. Probably the vast majority of them. > Actually, I would expect the vast majority of them never got used beyond opening the package and saying "cool!", then the whole thing stopping up as the owner discovers he/she needs an SD-card, a USB power supply, an HDMI cable, downloading the software and getting it onto the SD-card, reading about it on web pages, etc. After that, "IOT" would be a top usage - as would doing little Python scripts to make the LED's blink and perhaps work one of the "hats". (We use them in test benches and device programming systems, but I don't expect such uses to be a major percentage of the Pi's made. RPi 3 and 4 are much more flexible - we use them for "info screens" and the like.) >> >> Since they are full Linux systems, they will want to install/build >> anything that comes with a regular Linux system. I do know that many >> like to push their systems, languages and compilers to the limits. > > Unlikely. It's far more likely that the most minimum linux > installation is used (uboot + kernel + busybox) on the vast majority of > raspberry pi boards. > > >> >> BTW it sounds like gcc compile times /are/ a problem, if approaches like >> precompiled headers, conditional make files and 'ccache' need to be >> employed. > > What leads you to believe that any of those things _need_ to be employed? >
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2019-10-08 16:38 +0000 |
| Message-ID | <TX2nF.37217$MT2.17592@fx18.iad> |
| In reply to | #146755 |
David Brown <david.brown@hesbynett.no> writes: >On 08/10/2019 16:38, Scott Lurndal wrote: >> Bart <bc@freeuk.com> writes: >>> On 08/10/2019 13:05, David Brown wrote: >>>> On 08/10/2019 12:39, Bart wrote: >>> >>>> The primary uses of RPi's is for fun and learning. In both cases, you >>>> put up with slower or more limited systems, and you are also working >>>> with much smaller programs. The typical program developed using a Pi is >>>> a few hundred lines of Python or Lua - not many thousands of lines of C. >>> >>> I don't know what people do with them. But that they come with 1-4GB RAM >>> suggests they might be using or developing some programs that need 1-4GB >>> RAM. Those are not necessarily small. >> >> Large numbers of them are never used for programming, but rather as >> IOT devices. Probably the vast majority of them. >> > >Actually, I would expect the vast majority of them never got used beyond >opening the package and saying "cool!", then the whole thing stopping up >as the owner discovers he/she needs an SD-card, a USB power supply, an >HDMI cable, downloading the software and getting it onto the SD-card, >reading about it on web pages, etc. > >After that, "IOT" would be a top usage - as would doing little Python >scripts to make the LED's blink and perhaps work one of the "hats". Indeed. A friend has recently recommended this <https://pi-hole.net/>
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2019-10-08 07:55 -0700 |
| Message-ID | <1578fab0-3cdd-46fd-8a53-884a739c12e6@googlegroups.com> |
| In reply to | #146747 |
On Tuesday, 8 October 2019 15:06:45 UTC+1, Bart wrote: > > BTW it sounds like gcc compile times /are/ a problem, if approaches like > precompiled headers, conditional make files and 'ccache' need to be > employed. > That is a very good point. If you are using stratagems to reduce the amount of compilation you actually do, to mask the fact that the compiler is slow, then that's one more thing to go wrong. The cost is disguised because when the build system is set up it will work. However eventually something will often break, and then the costs are incurred.
[toc] | [prev] | [next] | [standalone]
| From | Anton Shepelev <anton.txt@g{oogle}mail.com> |
|---|---|
| Date | 2019-10-08 18:31 +0300 |
| Message-ID | <20191008183103.18dbc2a70c5b81aa53d60273@g{oogle}mail.com> |
| In reply to | #146750 |
Malcolm McLean to Bart: >>BTW it sounds like gcc compile times /are/ a problem, if >>approaches like precompiled headers, conditional make >>files and 'ccache' need to be employed. > >That is a very good point. If you are using stratagems to >reduce the amount of compilation you actually do, to mask >the fact that the compiler is slow, then that's one more >thing to go wrong. The cost is disguised because when the >build system is set up it will work. However eventually >something will often break, and then the costs are >incurred. `make' is supposed to optimise build by compiling only updated files, but that often fails to help. When compiling DOSBox with my pixel-perfect scaler, a change in the scaling algorithm entails a make running about 30 seconds on my PC with gcc -O2. -- () ascii ribbon campaign - against html e-mail /\ http://preview.tinyurl.com/qcy6mjc [archived]
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2019-10-08 16:39 +0000 |
| Message-ID | <lZ2nF.37218$MT2.17771@fx18.iad> |
| In reply to | #146753 |
Anton Shepelev <anton.txt@g{oogle}mail.com> writes:
>Malcolm McLean to Bart:
>
>>>BTW it sounds like gcc compile times /are/ a problem, if
>>>approaches like precompiled headers, conditional make
>>>files and 'ccache' need to be employed.
>>
>>That is a very good point. If you are using stratagems to
>>reduce the amount of compilation you actually do, to mask
>>the fact that the compiler is slow, then that's one more
>>thing to go wrong. The cost is disguised because when the
>>build system is set up it will work. However eventually
>>something will often break, and then the costs are
>>incurred.
>
>`make' is supposed to optimise build by compiling only
>updated files, but that often fails to help.
Especially for Bart, who believes that the entire source
must always be in a single file and is proud to have 35kloc
source files. *shudder*
[toc] | [prev] | [next] | [standalone]
| From | Anton Shepelev <anton.txt@g{oogle}mail.com> |
|---|---|
| Date | 2019-10-08 19:57 +0300 |
| Message-ID | <20191008195726.24e99eee46e813fa93cdf182@g{oogle}mail.com> |
| In reply to | #146761 |
Scott Lurndal: >Especially for Bart, who believes that the entire source >must always be in a single file and is proud to have 35kloc >source files. *shudder* Come on, those files are intermediate generate code, not intended for the eyes of mortals. -- () ascii ribbon campaign - against html e-mail /\ http://preview.tinyurl.com/qcy6mjc [archived]
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-10-08 18:09 +0100 |
| Message-ID | <Dp3nF.688744$665.267367@fx28.am4> |
| In reply to | #146761 |
On 08/10/2019 17:39, Scott Lurndal wrote:
> Anton Shepelev <anton.txt@g{oogle}mail.com> writes:
>> Malcolm McLean to Bart:
>>
>>>> BTW it sounds like gcc compile times /are/ a problem, if
>>>> approaches like precompiled headers, conditional make
>>>> files and 'ccache' need to be employed.
>>>
>>> That is a very good point. If you are using stratagems to
>>> reduce the amount of compilation you actually do, to mask
>>> the fact that the compiler is slow, then that's one more
>>> thing to go wrong. The cost is disguised because when the
>>> build system is set up it will work. However eventually
>>> something will often break, and then the costs are
>>> incurred.
>>
>> `make' is supposed to optimise build by compiling only
>> updated files, but that often fails to help.
>
> Especially for Bart, who believes that the entire source
> must always be in a single file and is proud to have 35kloc
> source files. *shudder*
>
Then you misunderstood.
This is an intermediate representation, and is no more an issue being in
one file than a binary executable.
That particular project comprises 73 source, support and bundled C
header files.
The 35Kloc C rendering is one file for convenience.
If you want to see those 73 files of the true sources, then one
combination (here for Windows target) is here:
https://github.com/sal55/qx/blob/master/cc.ma2
Naturally, bundled into one file for convenience. If you wanted to
compile these true sources, this is the file I'd send you. No zips or
.gz2 or anything, nor make files; you can compile this actual file.
[toc] | [prev] | [next] | [standalone]
Page 18 of 25 — ← Prev page 1 … 16 17 [18] 19 20 … 25 Next page →
Back to top | Article view | comp.lang.c
csiph-web