Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #88990 > unrolled thread
| Started by | Philipp Klaus Krause <pkk@spth.de> |
|---|---|
| First post | 2016-06-13 01:15 +0200 |
| Last post | 2016-08-14 01:32 -0400 |
| Articles | 20 on this page of 382 — 26 participants |
Back to article view | Back to comp.lang.c
Small Device C Compiler 3.6.0 released Philipp Klaus Krause <pkk@spth.de> - 2016-06-13 01:15 +0200
Re: Small Device C Compiler 3.6.0 released David Brown <david.brown@hesbynett.no> - 2016-06-13 08:47 +0200
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-13 02:07 -0700
Re: Small Device C Compiler 3.6.0 released David Brown <david.brown@hesbynett.no> - 2016-06-13 13:48 +0200
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-13 10:15 +0100
Re: Small Device C Compiler 3.6.0 released David Brown <david.brown@hesbynett.no> - 2016-06-13 13:54 +0200
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-13 13:30 +0100
Re: Small Device C Compiler 3.6.0 released David Brown <david.brown@hesbynett.no> - 2016-06-13 15:26 +0200
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-13 17:48 +0100
Re: Small Device C Compiler 3.6.0 released supercat@casperkitty.com - 2016-06-13 10:05 -0700
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-13 20:03 +0100
Re: Small Device C Compiler 3.6.0 released supercat@casperkitty.com - 2016-06-13 14:06 -0700
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-13 22:21 +0100
Re: Small Device C Compiler 3.6.0 released Philipp Klaus Krause <pkk@spth.de> - 2016-06-13 22:59 +0200
Re: Small Device C Compiler 3.6.0 released Keith Thompson <kst-u@mib.org> - 2016-06-13 11:19 -0700
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-13 21:32 +0100
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-13 19:32 +0100
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-13 20:28 +0100
Re: Small Device C Compiler 3.6.0 released Keith Thompson <kst-u@mib.org> - 2016-06-13 12:45 -0700
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-13 21:29 +0100
Re: Small Device C Compiler 3.6.0 released Keith Thompson <kst-u@mib.org> - 2016-06-13 15:03 -0700
Re: Small Device C Compiler 3.6.0 released raltbos@xs4all.nl (Richard Bos) - 2016-06-15 19:11 +0000
Re: Small Device C Compiler 3.6.0 released Les Cargill <lcargill99@comcast.com> - 2016-06-15 16:14 -0500
Re: Small Device C Compiler 3.6.0 released raltbos@xs4all.nl (Richard Bos) - 2016-06-18 20:04 +0000
Re: Small Device C Compiler 3.6.0 released Les Cargill <lcargill99@comcast.com> - 2016-06-18 16:47 -0500
Re: Small Device C Compiler 3.6.0 released raltbos@xs4all.nl (Richard Bos) - 2016-06-23 20:26 +0000
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-13 21:30 +0100
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-13 21:54 +0100
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-13 23:33 +0100
Re: Small Device C Compiler 3.6.0 released "James R. Kuyper" <jameskuyper@verizon.net> - 2016-06-13 18:51 -0400
Re: Small Device C Compiler 3.6.0 released Keith Thompson <kst-u@mib.org> - 2016-06-13 16:35 -0700
Re: Small Device C Compiler 3.6.0 released raltbos@xs4all.nl (Richard Bos) - 2016-06-14 08:38 +0000
Re: Small Device C Compiler 3.6.0 released Tim Rentsch <txr@alumni.caltech.edu> - 2016-06-15 16:42 -0700
Re: Small Device C Compiler 3.6.0 released supercat@casperkitty.com - 2016-06-15 17:05 -0700
Re: Small Device C Compiler 3.6.0 released Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-19 09:49 -0700
Re: Small Device C Compiler 3.6.0 released supercat@casperkitty.com - 2016-07-19 15:14 -0700
Re: Small Device C Compiler 3.6.0 released Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-21 09:20 -0700
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-14 10:31 +0100
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-14 11:20 +0100
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-14 13:38 +0100
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-14 15:21 +0100
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-14 15:44 +0100
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-14 16:15 +0100
Re: Small Device C Compiler 3.6.0 released Richard Heathfield <rjh@cpax.org.uk> - 2016-06-14 16:32 +0100
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-14 22:09 +0100
Re: Small Device C Compiler 3.6.0 released Keith Thompson <kst-u@mib.org> - 2016-06-14 14:48 -0700
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-14 23:05 +0100
Re: Small Device C Compiler 3.6.0 released supercat@casperkitty.com - 2016-06-14 15:12 -0700
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-14 23:16 -0700
Re: Small Device C Compiler 3.6.0 released Richard Heathfield <rjh@cpax.org.uk> - 2016-06-15 07:45 +0100
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-15 03:02 -0700
Re: Small Device C Compiler 3.6.0 released Richard Heathfield <rjh@cpax.org.uk> - 2016-06-15 11:39 +0100
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-15 13:04 +0100
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-15 09:33 -0700
Re: Small Device C Compiler 3.6.0 released Keith Thompson <kst-u@mib.org> - 2016-06-15 11:35 -0700
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-15 21:27 +0100
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-15 13:41 -0700
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-16 00:48 +0100
Re: Small Device C Compiler 3.6.0 released Keith Thompson <kst-u@mib.org> - 2016-06-15 14:24 -0700
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-16 01:08 -0700
Re: Small Device C Compiler 3.6.0 released Keith Thompson <kst-u@mib.org> - 2016-06-16 08:52 -0700
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-16 09:06 -0700
Re: Small Device C Compiler 3.6.0 released David Brown <david.brown@hesbynett.no> - 2016-06-17 10:12 +0200
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-17 01:31 -0700
Re: Small Device C Compiler 3.6.0 released David Brown <david.brown@hesbynett.no> - 2016-06-17 11:03 +0200
Re: Small Device C Compiler 3.6.0 released Keith Thompson <kst-u@mib.org> - 2016-06-17 08:42 -0700
Kiki's killfile (Was: Small Device C Compiler 3.6.0 released) gazelle@shell.xmission.com (Kenny McCormack) - 2016-06-16 17:03 +0000
Re: Small Device C Compiler 3.6.0 released raltbos@xs4all.nl (Richard Bos) - 2016-06-18 20:16 +0000
Re: Small Device C Compiler 3.6.0 released Les Cargill <lcargill99@comcast.com> - 2016-06-18 16:49 -0500
Re: Small Device C Compiler 3.6.0 released David Brown <david.brown@hesbynett.no> - 2016-06-15 23:42 +0200
Re: Small Device C Compiler 3.6.0 released Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-06-15 17:35 -0400
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-16 01:19 -0700
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-16 15:12 +0100
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-16 08:21 -0700
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-16 23:10 +0100
Re: Small Device C Compiler 3.6.0 released luser droog <luser.droog@gmail.com> - 2016-06-16 16:54 -0700
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-16 19:10 -0700
Re: Small Device C Compiler 3.6.0 released Gareth Owen <gwowen@gmail.com> - 2016-06-17 06:00 +0100
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-17 01:09 -0700
Re: Small Device C Compiler 3.6.0 released Martin Shobe <mashobe9@gmail.com> - 2016-06-17 07:13 -0500
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-17 05:29 -0700
Re: Small Device C Compiler 3.6.0 released Martin Shobe <mashobe9@gmail.com> - 2016-06-17 08:12 -0500
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-17 06:18 -0700
Re: Small Device C Compiler 3.6.0 released Martin Shobe <mashobe9@gmail.com> - 2016-06-17 21:57 -0500
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-17 20:54 -0700
Re: Small Device C Compiler 3.6.0 released luser droog <luser.droog@gmail.com> - 2016-06-17 23:21 -0700
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-18 05:18 -0700
Re: Small Device C Compiler 3.6.0 released raltbos@xs4all.nl (Richard Bos) - 2016-06-18 20:19 +0000
Re: Small Device C Compiler 3.6.0 released Martin Shobe <mashobe9@gmail.com> - 2016-06-18 12:40 -0500
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-18 16:37 -0700
Re: Small Device C Compiler 3.6.0 released Martin Shobe <mashobe9@gmail.com> - 2016-06-18 22:08 -0500
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-18 21:02 -0700
Re: Small Device C Compiler 3.6.0 released Martin Shobe <mashobe9@gmail.com> - 2016-06-19 00:17 -0500
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-18 22:33 -0700
Re: Small Device C Compiler 3.6.0 released Martin Shobe <mashobe9@gmail.com> - 2016-06-19 12:07 -0500
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-19 10:38 -0700
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-19 21:07 +0100
Re: Small Device C Compiler 3.6.0 released supercat@casperkitty.com - 2016-06-19 13:36 -0700
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-19 13:50 -0700
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-19 22:42 +0100
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-19 23:16 +0100
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-20 00:12 +0100
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-19 16:35 -0700
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-20 01:33 +0100
Re: Small Device C Compiler 3.6.0 released supercat@casperkitty.com - 2016-06-20 08:09 -0700
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-20 16:57 +0100
Re: Small Device C Compiler 3.6.0 released supercat@casperkitty.com - 2016-06-20 14:23 -0700
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-19 15:56 -0700
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-20 01:24 +0100
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-19 17:51 -0700
Re: Small Device C Compiler 3.6.0 released Richard Heathfield <rjh@cpax.org.uk> - 2016-06-20 02:33 +0100
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-20 01:40 -0700
Re: Small Device C Compiler 3.6.0 released Richard Heathfield <rjh@cpax.org.uk> - 2016-06-20 10:10 +0100
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-20 02:22 -0700
Re: Small Device C Compiler 3.6.0 released Richard Heathfield <rjh@cpax.org.uk> - 2016-06-20 10:51 +0100
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-20 03:12 -0700
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-20 11:32 +0100
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-20 03:59 -0700
Re: Small Device C Compiler 3.6.0 released Richard Heathfield <rjh@cpax.org.uk> - 2016-06-20 12:19 +0100
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-20 04:40 -0700
Re: Small Device C Compiler 3.6.0 released Richard Heathfield <rjh@cpax.org.uk> - 2016-06-20 13:05 +0100
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-20 05:32 -0700
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-20 15:53 +0100
Re: Small Device C Compiler 3.6.0 released Richard Heathfield <rjh@cpax.org.uk> - 2016-06-20 16:22 +0100
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-20 17:13 +0100
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-20 10:11 -0700
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-20 21:39 +0100
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-20 19:10 -0700
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-22 01:14 +0100
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-21 17:27 -0700
Re: Small Device C Compiler 3.6.0 released supercat@casperkitty.com - 2016-06-22 08:24 -0700
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-22 20:00 +0100
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-22 23:23 -0700
Re: Small Device C Compiler 3.6.0 released Keith Thompson <kst-u@mib.org> - 2016-06-23 08:15 -0700
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-23 20:48 +0100
Re: Small Device C Compiler 3.6.0 released Richard Heathfield <rjh@cpax.org.uk> - 2016-06-20 23:48 +0100
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-20 19:02 -0700
Re: Small Device C Compiler 3.6.0 released Richard Heathfield <rjh@cpax.org.uk> - 2016-06-21 03:45 +0100
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-20 20:27 -0700
Re: Small Device C Compiler 3.6.0 released David Brown <david.brown@hesbynett.no> - 2016-06-21 10:03 +0200
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-21 02:44 -0700
Re: Small Device C Compiler 3.6.0 released David Brown <david.brown@hesbynett.no> - 2016-06-21 12:51 +0200
Re: Small Device C Compiler 3.6.0 released Les Cargill <lcargill99@comcast.com> - 2016-06-21 10:14 -0500
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-21 16:44 +0100
Re: Small Device C Compiler 3.6.0 released David Brown <david.brown@hesbynett.no> - 2016-06-21 19:50 +0200
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-21 16:33 +0100
Re: Small Device C Compiler 3.6.0 released Keith Thompson <kst-u@mib.org> - 2016-06-21 10:54 -0700
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-21 20:02 +0100
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-21 21:13 +0100
Re: Small Device C Compiler 3.6.0 released Keith Thompson <kst-u@mib.org> - 2016-06-21 13:45 -0700
Re: Small Device C Compiler 3.6.0 released luser droog <luser.droog@gmail.com> - 2016-06-20 10:00 -0700
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-20 22:07 +0100
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-20 19:08 -0700
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-22 01:15 +0100
Re: Small Device C Compiler 3.6.0 released raltbos@xs4all.nl (Richard Bos) - 2016-06-20 12:38 +0000
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-20 15:48 +0100
Re: Small Device C Compiler 3.6.0 released Martin Shobe <mashobe9@gmail.com> - 2016-06-20 23:17 -0500
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-20 21:43 -0700
Re: Small Device C Compiler 3.6.0 released Martin Shobe <mashobe9@gmail.com> - 2016-06-21 06:36 -0500
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-04 10:52 -0700
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-04 16:03 -0700
Re: Small Device C Compiler 3.6.0 released Martin Shobe <mashobe9@gmail.com> - 2016-07-04 22:28 -0500
Re: Small Device C Compiler 3.6.0 released Gareth Owen <gwowen@gmail.com> - 2016-07-05 07:11 +0100
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-05 02:06 -0700
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-06 15:12 +0100
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-06 08:29 -0700
Re: Small Device C Compiler 3.6.0 released Martin Shobe <mashobe9@gmail.com> - 2016-07-04 13:54 -0500
Re: Small Device C Compiler 3.6.0 released Rosario19 <Ros@invalid.invalid> - 2016-07-04 07:18 +0200
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-04 01:58 -0700
Re: Small Device C Compiler 3.6.0 released Rosario19 <Ros@invalid.invalid> - 2016-07-16 19:37 +0200
Re: Small Device C Compiler 3.6.0 released "D. Aaron Sawyer" <aaron@110.net> - 2016-07-16 15:58 -0300
Re: Small Device C Compiler 3.6.0 released Ike Naar <ike@iceland.freeshell.org> - 2016-07-16 19:25 +0000
Re: Small Device C Compiler 3.6.0 released Martin Shobe <mashobe9@gmail.com> - 2016-07-04 12:10 -0500
Re: Small Device C Compiler 3.6.0 released Richard Damon <Richard@Damon-Family.org> - 2016-06-18 10:35 -0400
Re: Small Device C Compiler 3.6.0 released Martin Shobe <mashobe9@gmail.com> - 2016-06-18 12:48 -0500
Re: Small Device C Compiler 3.6.0 released Richard Damon <Richard@Damon-Family.org> - 2016-06-18 23:11 -0400
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-18 21:06 -0700
Re: Small Device C Compiler 3.6.0 released Richard Damon <Richard@Damon-Family.org> - 2016-06-19 08:23 -0400
Re: Small Device C Compiler 3.6.0 released Robert Wessel <robertwessel2@yahoo.com> - 2016-06-18 14:30 -0500
Re: Small Device C Compiler 3.6.0 released Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-06-17 09:43 -0400
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-17 14:55 +0100
Re: Small Device C Compiler 3.6.0 released David Brown <david.brown@hesbynett.no> - 2016-06-17 16:29 +0200
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-17 15:42 +0100
Re: Small Device C Compiler 3.6.0 released raltbos@xs4all.nl (Richard Bos) - 2016-06-18 20:23 +0000
Re: Small Device C Compiler 3.6.0 released Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-06-17 10:36 -0400
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-17 15:53 +0100
Re: Small Device C Compiler 3.6.0 released Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-06-17 11:40 -0400
Re: Small Device C Compiler 3.6.0 released supercat@casperkitty.com - 2016-06-17 09:30 -0700
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-17 17:41 +0100
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-17 08:11 -0700
Re: Small Device C Compiler 3.6.0 released Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-06-17 11:59 -0400
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-17 09:52 -0700
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-17 18:24 +0100
Re: Small Device C Compiler 3.6.0 released Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-06-17 14:33 -0400
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-17 12:57 -0700
Re: Small Device C Compiler 3.6.0 released Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-06-17 16:12 -0400
Re: Small Device C Compiler 3.6.0 released Ian Collins <ian-news@hotmail.com> - 2016-06-18 09:16 +1200
Re: Small Device C Compiler 3.6.0 released Richard Heathfield <rjh@cpax.org.uk> - 2016-06-17 14:16 +0100
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-17 06:32 -0700
Re: Small Device C Compiler 3.6.0 released Richard Heathfield <rjh@cpax.org.uk> - 2016-06-17 15:02 +0100
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-17 07:45 -0700
Re: Small Device C Compiler 3.6.0 released Richard Heathfield <rjh@cpax.org.uk> - 2016-06-17 18:34 +0100
Re: Small Device C Compiler 3.6.0 released Gareth Owen <gwowen@gmail.com> - 2016-06-18 18:06 +0100
Re: Small Device C Compiler 3.6.0 released Gareth Owen <gwowen@gmail.com> - 2016-06-18 12:06 +0100
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-17 21:49 +0100
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-17 15:35 -0700
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-18 02:18 +0100
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-17 19:00 -0700
Re: Small Device C Compiler 3.6.0 released Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-06-17 22:36 -0400
Re: Small Device C Compiler 3.6.0 released raltbos@xs4all.nl (Richard Bos) - 2016-06-18 20:28 +0000
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-19 03:00 +0100
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-19 03:31 +0100
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-18 20:00 -0700
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-19 15:34 +0100
Re: Small Device C Compiler 3.6.0 released David Brown <david.brown@hesbynett.no> - 2016-06-17 10:20 +0200
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-17 02:13 -0700
Re: Small Device C Compiler 3.6.0 released David Brown <david.brown@hesbynett.no> - 2016-06-17 11:44 +0200
Re: Small Device C Compiler 3.6.0 released Richard Heathfield <rjh@cpax.org.uk> - 2016-06-17 10:47 +0100
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-17 03:41 -0700
Re: Small Device C Compiler 3.6.0 released Richard Heathfield <rjh@cpax.org.uk> - 2016-06-17 11:49 +0100
Re: Small Device C Compiler 3.6.0 released raltbos@xs4all.nl (Richard Bos) - 2016-06-18 10:52 +0000
Re: Small Device C Compiler 3.6.0 released David Brown <david.brown@hesbynett.no> - 2016-06-17 13:18 +0200
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-14 23:59 +0100
Re: Small Device C Compiler 3.6.0 released David Brown <david.brown@hesbynett.no> - 2016-06-15 10:20 +0200
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-15 10:30 +0100
Re: Small Device C Compiler 3.6.0 released David Brown <david.brown@hesbynett.no> - 2016-06-15 12:55 +0200
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-15 12:39 +0100
Re: Small Device C Compiler 3.6.0 released David Brown <david.brown@hesbynett.no> - 2016-06-15 14:11 +0200
Re: Small Device C Compiler 3.6.0 released Keith Thompson <kst-u@mib.org> - 2016-06-15 09:44 -0700
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-15 18:38 +0100
Re: Small Device C Compiler 3.6.0 released Keith Thompson <kst-u@mib.org> - 2016-06-15 11:46 -0700
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-15 20:07 +0100
Re: Small Device C Compiler 3.6.0 released Keith Thompson <kst-u@mib.org> - 2016-06-15 12:23 -0700
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-15 20:43 +0100
Re: Small Device C Compiler 3.6.0 released Keith Thompson <kst-u@mib.org> - 2016-06-15 13:38 -0700
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-15 21:59 +0100
Re: Small Device C Compiler 3.6.0 released Keith Thompson <kst-u@mib.org> - 2016-06-15 14:42 -0700
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-15 23:28 +0100
Re: Small Device C Compiler 3.6.0 released supercat@casperkitty.com - 2016-06-15 15:35 -0700
Re: Small Device C Compiler 3.6.0 released Keith Thompson <kst-u@mib.org> - 2016-06-15 16:48 -0700
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-16 01:11 +0100
Re: Small Device C Compiler 3.6.0 released Keith Thompson <kst-u@mib.org> - 2016-06-15 18:01 -0700
Re: Small Device C Compiler 3.6.0 released supercat@casperkitty.com - 2016-06-15 18:44 -0700
Re: Small Device C Compiler 3.6.0 released Keith Thompson <kst-u@mib.org> - 2016-06-15 19:42 -0700
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-16 13:06 +0100
Re: Small Device C Compiler 3.6.0 released David Brown <david.brown@hesbynett.no> - 2016-06-16 15:06 +0200
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-16 14:40 +0100
Re: Small Device C Compiler 3.6.0 released Keith Thompson <kst-u@mib.org> - 2016-06-16 09:09 -0700
Re: Small Device C Compiler 3.6.0 released Reinhardt Behm <rbehm@hushmail.com> - 2016-06-17 20:51 +0800
Re: Small Device C Compiler 3.6.0 released David Brown <david.brown@hesbynett.no> - 2016-06-17 10:32 +0200
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-17 11:00 +0100
Re: Small Device C Compiler 3.6.0 released David Brown <david.brown@hesbynett.no> - 2016-06-17 12:59 +0200
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-17 12:34 +0100
Re: Small Device C Compiler 3.6.0 released David Brown <david.brown@hesbynett.no> - 2016-06-17 13:56 +0200
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-17 13:15 +0100
Re: Small Device C Compiler 3.6.0 released David Brown <david.brown@hesbynett.no> - 2016-06-17 14:33 +0200
Re: Small Device C Compiler 3.6.0 released Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-06-17 08:47 -0400
Re: Small Device C Compiler 3.6.0 released Keith Thompson <kst-u@mib.org> - 2016-06-17 11:51 -0700
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-17 20:39 +0100
Re: Small Device C Compiler 3.6.0 released Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-06-17 16:36 -0400
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-17 21:54 +0100
Re: Small Device C Compiler 3.6.0 released Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-06-17 17:05 -0400
Re: Small Device C Compiler 3.6.0 released Keith Thompson <kst-u@mib.org> - 2016-06-17 16:05 -0700
Re: Small Device C Compiler 3.6.0 released raltbos@xs4all.nl (Richard Bos) - 2016-06-18 20:34 +0000
Re: Small Device C Compiler 3.6.0 released Reinhardt Behm <rbehm@hushmail.com> - 2016-06-17 20:43 +0800
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-17 06:15 -0700
Re: Small Device C Compiler 3.6.0 released David Brown <david.brown@hesbynett.no> - 2016-06-17 15:47 +0200
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-17 07:51 -0700
Re: Small Device C Compiler 3.6.0 released Keith Thompson <kst-u@mib.org> - 2016-06-17 11:52 -0700
Re: Small Device C Compiler 3.6.0 released Richard Heathfield <rjh@cpax.org.uk> - 2016-06-17 14:57 +0100
Re: Small Device C Compiler 3.6.0 released raltbos@xs4all.nl (Richard Bos) - 2016-06-18 20:37 +0000
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-18 16:48 -0700
Re: Small Device C Compiler 3.6.0 released Richard Heathfield <rjh@cpax.org.uk> - 2016-06-19 00:50 +0100
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-18 17:30 -0700
Re: Small Device C Compiler 3.6.0 released Les Cargill <lcargill99@comcast.com> - 2016-06-19 06:35 -0500
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-19 01:29 +0100
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-18 17:43 -0700
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-19 02:00 +0100
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-18 18:45 -0700
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-19 17:14 +0100
Re: Small Device C Compiler 3.6.0 released Keith Thompson <kst-u@mib.org> - 2016-06-19 15:17 -0700
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-17 14:52 +0100
Re: Small Device C Compiler 3.6.0 released Keith Thompson <kst-u@mib.org> - 2016-06-17 12:32 -0700
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-17 20:55 +0100
Re: Small Device C Compiler 3.6.0 released Keith Thompson <kst-u@mib.org> - 2016-06-17 16:09 -0700
Re: Small Device C Compiler 3.6.0 released supercat@casperkitty.com - 2016-06-17 16:19 -0700
Re: Small Device C Compiler 3.6.0 released Keith Thompson <kst-u@mib.org> - 2016-06-17 16:48 -0700
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-18 01:01 +0100
Re: Small Device C Compiler 3.6.0 released supercat@casperkitty.com - 2016-06-17 17:38 -0700
Re: Small Device C Compiler 3.6.0 released Keith Thompson <kst-u@mib.org> - 2016-06-17 21:55 -0700
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-18 10:56 +0100
Re: Small Device C Compiler 3.6.0 released supercat@casperkitty.com - 2016-06-18 06:36 -0700
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-18 16:43 +0100
Re: Small Device C Compiler 3.6.0 released supercat@casperkitty.com - 2016-06-18 09:13 -0700
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-18 18:49 +0100
Re: Small Device C Compiler 3.6.0 released supercat@casperkitty.com - 2016-06-18 11:46 -0700
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-18 21:03 +0100
Re: Small Device C Compiler 3.6.0 released Keith Thompson <kst-u@mib.org> - 2016-06-18 13:30 -0700
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-18 11:17 +0100
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-18 01:18 +0100
Re: Small Device C Compiler 3.6.0 released Keith Thompson <kst-u@mib.org> - 2016-06-17 17:53 -0700
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-17 18:20 -0700
Re: Small Device C Compiler 3.6.0 released Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-06-17 21:37 -0400
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-18 10:30 +0100
Re: Small Device C Compiler 3.6.0 released Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-06-18 07:52 -0400
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-18 13:59 +0100
Re: Small Device C Compiler 3.6.0 released Keith Thompson <kst-u@mib.org> - 2016-06-17 22:01 -0700
Re: Small Device C Compiler 3.6.0 released gazelle@shell.xmission.com (Kenny McCormack) - 2016-06-18 10:02 +0000
Re: Small Device C Compiler 3.6.0 released Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-06-17 21:10 -0400
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-16 06:45 -0700
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-16 15:00 +0100
Re: Small Device C Compiler 3.6.0 released Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-06-16 10:35 -0400
Re: Small Device C Compiler 3.6.0 released Keith Thompson <kst-u@mib.org> - 2016-06-16 09:07 -0700
Re: Small Device C Compiler 3.6.0 released Ike Naar <ike@iceland.freeshell.org> - 2016-06-16 15:32 +0000
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-16 17:03 +0100
Re: Small Device C Compiler 3.6.0 released Ike Naar <ike@iceland.freeshell.org> - 2016-06-16 22:26 +0000
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-16 23:44 +0100
Re: Small Device C Compiler 3.6.0 released luser droog <luser.droog@gmail.com> - 2016-06-16 16:56 -0700
Re: Small Device C Compiler 3.6.0 released Gareth Owen <gwowen@gmail.com> - 2016-06-18 12:03 +0100
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-18 13:43 +0100
Re: Small Device C Compiler 3.6.0 released Keith Thompson <kst-u@mib.org> - 2016-06-16 16:35 -0700
Re: Small Device C Compiler 3.6.0 released Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-06-16 20:57 -0400
Re: Small Device C Compiler 3.6.0 released James Kuyper <jameskuyper@verizon.net> - 2016-06-16 21:12 -0400
Re: Small Device C Compiler 3.6.0 released Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-06-16 22:31 -0400
Re: Small Device C Compiler 3.6.0 released Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-06-16 22:32 -0400
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-16 19:59 -0700
Re: Small Device C Compiler 3.6.0 released supercat@casperkitty.com - 2016-06-17 03:11 -0700
Re: Small Device C Compiler 3.6.0 released James Kuyper <jameskuyper@verizon.net> - 2016-06-17 09:11 -0400
Re: Small Device C Compiler 3.6.0 released supercat@casperkitty.com - 2016-06-15 12:20 -0700
Re: Small Device C Compiler 3.6.0 released Keith Thompson <kst-u@mib.org> - 2016-06-15 12:40 -0700
Re: Small Device C Compiler 3.6.0 released Keith Thompson <kst-u@mib.org> - 2016-06-15 09:24 -0700
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-15 18:16 +0100
Re: Small Device C Compiler 3.6.0 released supercat@casperkitty.com - 2016-06-15 11:15 -0700
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-15 20:09 +0100
Re: Small Device C Compiler 3.6.0 released Keith Thompson <kst-u@mib.org> - 2016-06-15 11:32 -0700
Re: Small Device C Compiler 3.6.0 released supercat@casperkitty.com - 2016-06-15 12:01 -0700
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-15 20:15 +0100
Re: Small Device C Compiler 3.6.0 released raltbos@xs4all.nl (Richard Bos) - 2016-06-15 19:15 +0000
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-15 03:12 -0700
Re: Small Device C Compiler 3.6.0 released David Brown <david.brown@hesbynett.no> - 2016-06-15 13:03 +0200
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-15 04:22 -0700
Re: Small Device C Compiler 3.6.0 released David Brown <david.brown@hesbynett.no> - 2016-06-15 14:20 +0200
Re: Small Device C Compiler 3.6.0 released raltbos@xs4all.nl (Richard Bos) - 2016-06-15 19:33 +0000
Re: Small Device C Compiler 3.6.0 released Gareth Owen <gwowen@gmail.com> - 2016-06-18 12:00 +0100
Re: Small Device C Compiler 3.6.0 released raltbos@xs4all.nl (Richard Bos) - 2016-06-18 20:39 +0000
Re: Small Device C Compiler 3.6.0 released Keith Thompson <kst-u@mib.org> - 2016-06-15 09:52 -0700
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-13 14:38 -0700
Re: Small Device C Compiler 3.6.0 released supercat@casperkitty.com - 2016-06-13 15:09 -0700
Re: Small Device C Compiler 3.6.0 released David Brown <david.brown@hesbynett.no> - 2016-06-14 09:51 +0200
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-13 23:19 +0100
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-13 23:46 +0100
Re: Small Device C Compiler 3.6.0 released "James R. Kuyper" <jameskuyper@verizon.net> - 2016-06-13 19:04 -0400
Re: Small Device C Compiler 3.6.0 released "James R. Kuyper" <jameskuyper@verizon.net> - 2016-06-13 20:04 -0400
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-14 10:59 +0100
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-14 00:23 +0100
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-14 11:17 +0100
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-14 02:08 -0700
Re: Small Device C Compiler 3.6.0 released Keith Thompson <kst-u@mib.org> - 2016-06-14 08:37 -0700
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-14 08:56 -0700
Re: Small Device C Compiler 3.6.0 released Keith Thompson <kst-u@mib.org> - 2016-06-14 09:14 -0700
Re: Small Device C Compiler 3.6.0 released Keith Thompson <kst-u@mib.org> - 2016-06-18 11:47 -0700
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-14 10:59 +0100
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-14 12:54 +0100
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-14 05:38 -0700
Re: Small Device C Compiler 3.6.0 released Philipp Klaus Krause <pkk@spth.de> - 2016-06-13 22:56 +0200
Re: Small Device C Compiler 3.6.0 released Philipp Klaus Krause <pkk@spth.de> - 2016-06-15 10:09 +0200
Re: Small Device C Compiler 3.6.0 released Tim Rentsch <txr@alumni.caltech.edu> - 2016-06-15 15:09 -0700
Re: Small Device C Compiler 3.6.0 released Philipp Klaus Krause <pkk@spth.de> - 2016-06-16 14:39 +0200
Re: Small Device C Compiler 3.6.0 released David Brown <david.brown@hesbynett.no> - 2016-06-16 15:11 +0200
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-16 14:28 +0100
Re: Small Device C Compiler 3.6.0 released Philipp Klaus Krause <pkk@spth.de> - 2016-06-16 21:25 +0200
Re: Small Device C Compiler 3.6.0 released supercat@casperkitty.com - 2016-06-16 12:40 -0700
Re: Small Device C Compiler 3.6.0 released Philipp Klaus Krause <pkk@spth.de> - 2016-06-16 22:00 +0200
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-16 21:14 +0100
Re: Small Device C Compiler 3.6.0 released supercat@casperkitty.com - 2016-06-16 14:08 -0700
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-16 22:30 +0100
Re: Small Device C Compiler 3.6.0 released Philipp Klaus Krause <pkk@spth.de> - 2016-06-17 13:31 +0200
Re: Small Device C Compiler 3.6.0 released Philipp Klaus Krause <pkk@spth.de> - 2016-06-17 13:28 +0200
Re: Small Device C Compiler 3.6.0 released Tim Rentsch <txr@alumni.caltech.edu> - 2016-06-16 21:38 -0700
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-17 10:53 +0100
Re: Small Device C Compiler 3.6.0 released supercat@casperkitty.com - 2016-06-18 08:39 -0700
Re: Small Device C Compiler 3.6.0 released bitrex <bitrex@de.lete.earthlink.net> - 2016-08-14 01:32 -0400
Page 8 of 20 — ← Prev page 1 … 6 7 [8] 9 10 … 20 Next page →
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-06-21 02:44 -0700 |
| Message-ID | <0ba761a3-29f4-4060-9048-c132226a5853@googlegroups.com> |
| In reply to | #89694 |
On Tuesday, June 21, 2016 at 9:04:03 AM UTC+1, David Brown wrote:
> On 21/06/16 05:27, Malcolm McLean wrote:
> > On Tuesday, June 21, 2016 at 3:45:26 AM UTC+1, Richard Heathfield wrote:
> >> On 21/06/16 03:02, Malcolm McLean wrote:
> >>
> >>> The so-called Malcolm call-tree is the structure of a structured
> >>> program. A tree, with cycles for recursion.
> >>
> >> If it has cycles, it's not a tree. If it's not a tree /anyway/, you
> >> might as well leave functions where they are instead of duplicating them
> >> all over the place:
> >>
> >> A
> >> |\
> >> B C
> >> |/
> >> D
> >>
> >> instead of
> >>
> >> A
> >> |\
> >> B C
> >> | \
> >> D D
> >>
> > Yes, it's not a huge point.
>
> It is /exactly/ the point. The former is a graph (a directed graph),
> the later is a tree made by replicating nodes on the graph. The graph
> is a better model for all but the simplest of programs, precisely
> because it avoids duplication, and because it is a more general
> structure. In particular, it also supports conditionals in a practical
> way (as Richard showed), as well as loops /and/ recursion. Recursion
> leads to cycles in the directed graph, which spoils some analytical
> properties - but it allows other sorts of analysis (such as proof by
> induction).
>
> The tree only really makes sense if, in the words of the great Jerry
> Stuckle, the biggest program you write is "Hello, world".
>
> > Sometimes the former graph makes more sense.
>
> The former graph almost always makes more sense.
>
> >
> > Not if D takes a function pointer, however. If D takes
> > a function pointer which is E in B a F in C, the second graph
> > looks like
> >
> > A
> > | \
> > B C
> > | \
> > D D
> > | \
> > E F
> >
> > and we know that F is only called once, and always from C.
>
> Function pointers /always/ make it harder to follow the call structure
> of a program. It makes sense to avoid them, or at least limit them or
> constrain them in some way (such as C++ virtual functions) if you want
> to generate call graphs or do other analysis on your code.
>
The property that all D nodes are the same breaks if D takes and calls
a function pointer. So yes, they complicate things. The tree makes
that obvious.
>
> And yes, sometimes it would make sense to duplicate the node D in a case
> like this (the alternative is both E and F coming out of D):
>
> A
> |\
> B C
> |/
> D
> |\
> E F
>
> But such situations are the exception, not the common case.
>
With that graph, E is reachable from C.
It's not "wrong", it's showing a structure which exists, but it's not
keeping all properties we might desire.
>
> >
> > We can't ban both loops and recursion, unfortunately. We have
> > to accept the problem somewhere.
>
> Loops and recursions are not "problems" - if they don't fit well with
> your particular ideas of program structure or models, then it is your
> ideas and models that are the problem. Without loops and recursion (or
> some equivalent constructs), you can't do anything worthwhile in your
> programming. Your insistence that everything should look like a tree
> without cycles (and all fitting on one page, according to your earlier
> posts) is an artificial and unrealistic constraint. Yes, it is easier
> to analyse a nice clean tree - but it does not match reality. It's like
> the physicist who wants to make milk production more efficient, and
> starts off with "consider a spherical cow...".
>
No, you can't abolish the halting problem simply by structuring your
program.
But we can show that a structured program must return if it has no
loops or recursive calls. If it has no recursive calls, we can show that
it must return if we can show that all the loop conditions must terminate.
So the code
for(i=0;i<N;i++)
abswer += x[i];
must terminate if we can show that i and N are no corrupted and i cannot
wrap before it reaches N.
The code
while(ptr)
{
answer += ptr->x;
ptr = ptr->next;
}
will be in an infinite loop is ptr is a circular list.
If the list is passed, we can prove this function terminates, but only
by stepping up a level, and proving that the list cannot contain a cycle.
>
> Trees are great for climbing - but useless as models of call behaviour
> and structure in programs.
>
We can also prune any if branches that we can prove are not taken.
Typically that situation arises when a constant is passed to a
subroutine. Programmers seldom write redundant ifs, so by looking
at functions in isolation, you can't get this simplification and optimisation.
Now in reality, recursion in C programs is rare, and complex loop conditions
are also pretty rare.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-06-21 12:51 +0200 |
| Message-ID | <nkb67r$86t$1@dont-email.me> |
| In reply to | #89695 |
On 21/06/16 11:44, Malcolm McLean wrote:
> On Tuesday, June 21, 2016 at 9:04:03 AM UTC+1, David Brown wrote:
>> On 21/06/16 05:27, Malcolm McLean wrote:
>>> On Tuesday, June 21, 2016 at 3:45:26 AM UTC+1, Richard Heathfield wrote:
>>>> On 21/06/16 03:02, Malcolm McLean wrote:
>>>>
>>>>> The so-called Malcolm call-tree is the structure of a structured
>>>>> program. A tree, with cycles for recursion.
>>>>
>>>> If it has cycles, it's not a tree. If it's not a tree /anyway/, you
>>>> might as well leave functions where they are instead of duplicating them
>>>> all over the place:
>>>>
>>>> A
>>>> |\
>>>> B C
>>>> |/
>>>> D
>>>>
>>>> instead of
>>>>
>>>> A
>>>> |\
>>>> B C
>>>> | \
>>>> D D
>>>>
>>> Yes, it's not a huge point.
>>
>> It is /exactly/ the point. The former is a graph (a directed graph),
>> the later is a tree made by replicating nodes on the graph. The graph
>> is a better model for all but the simplest of programs, precisely
>> because it avoids duplication, and because it is a more general
>> structure. In particular, it also supports conditionals in a practical
>> way (as Richard showed), as well as loops /and/ recursion. Recursion
>> leads to cycles in the directed graph, which spoils some analytical
>> properties - but it allows other sorts of analysis (such as proof by
>> induction).
>>
>> The tree only really makes sense if, in the words of the great Jerry
>> Stuckle, the biggest program you write is "Hello, world".
>>
>>> Sometimes the former graph makes more sense.
>>
>> The former graph almost always makes more sense.
>>
>>>
>>> Not if D takes a function pointer, however. If D takes
>>> a function pointer which is E in B a F in C, the second graph
>>> looks like
>>>
>>> A
>>> | \
>>> B C
>>> | \
>>> D D
>>> | \
>>> E F
>>>
>>> and we know that F is only called once, and always from C.
>>
>> Function pointers /always/ make it harder to follow the call structure
>> of a program. It makes sense to avoid them, or at least limit them or
>> constrain them in some way (such as C++ virtual functions) if you want
>> to generate call graphs or do other analysis on your code.
>>
> The property that all D nodes are the same breaks if D takes and calls
> a function pointer. So yes, they complicate things. The tree makes
> that obvious.
In this particular rare situation where you /know/ that B calls D in a
way that causes it to call E but not F, and that C calls D in a way that
causes it to call F but not E, /then/ the tree makes things obvious.
But it is a highly unusual situation. In virtually all cases,
duplicating D just makes things confusing rather than helping.
>>
>> And yes, sometimes it would make sense to duplicate the node D in a case
>> like this (the alternative is both E and F coming out of D):
>>
>> A
>> |\
>> B C
>> |/
>> D
>> |\
>> E F
>>
>> But such situations are the exception, not the common case.
>>
> With that graph, E is reachable from C.
> It's not "wrong", it's showing a structure which exists, but it's not
> keeping all properties we might desire.
Here in the real world, with actual programs designed to solve real
problems, conditionals of some sort are common practice. Whether this
is done by function pointers or an "if" statement, you are going to get
functions that sometimes call one function, sometimes call another. If
that breaks "properties we might desire", then your desires are unrealistic.
>>
>>>
>>> We can't ban both loops and recursion, unfortunately. We have
>>> to accept the problem somewhere.
>>
>> Loops and recursions are not "problems" - if they don't fit well with
>> your particular ideas of program structure or models, then it is your
>> ideas and models that are the problem. Without loops and recursion (or
>> some equivalent constructs), you can't do anything worthwhile in your
>> programming. Your insistence that everything should look like a tree
>> without cycles (and all fitting on one page, according to your earlier
>> posts) is an artificial and unrealistic constraint. Yes, it is easier
>> to analyse a nice clean tree - but it does not match reality. It's like
>> the physicist who wants to make milk production more efficient, and
>> starts off with "consider a spherical cow...".
>>
> No, you can't abolish the halting problem simply by structuring your
> program.
Who is concerned with the halting problem? That has nothing to do with
the discussion here.
> But we can show that a structured program must return if it has no
> loops or recursive calls. If it has no recursive calls, we can show that
> it must return if we can show that all the loop conditions must terminate.
If you want to prove that a function terminates within a finite time,
you have to prove that all its parts terminate in a finite time. Loops
and recursions are normal parts of that - and you need to prove that
these terminate.
Structure and structured programming has nothing to do with this, other
than to say it is easier to reason about a program's termination if the
code is well structured. But there is nothing about structured
programming that means that a function will definitely terminate (most
of the code I write is quite structured, and most of it never
terminates). And unstructured programs can also terminate, and it can
often be just as easy to prove that they terminate.
>
> So the code
>
> for(i=0;i<N;i++)
> abswer += x[i];
>
> must terminate if we can show that i and N are no corrupted and i cannot
> wrap before it reaches N.
Yes - but that is not because the code is structured, and certainly not
because you can turn it into a tree.
The code:
for (int i = 0; i < N; i++) {
answer += x[i];
if (answer > 1000) return;
}
is unstructured (by most definitions), because of the extra "return" in
the middle. Yet it will terminate at least as often as your structured
code, and it is just as easy to see or prove.
>
> The code
>
> while(ptr)
> {
> answer += ptr->x;
> ptr = ptr->next;
> }
>
> will be in an infinite loop is ptr is a circular list.
True (apart from the typos).
>
> If the list is passed, we can prove this function terminates, but only
> by stepping up a level, and proving that the list cannot contain a cycle.
All this has nothing to do with structured or unstructured programming,
or trees or graphs. Determining if a program terminates or not is
completely unrelated.
What will be your next argument? That all data structures can be
represented as structs or arrays because that gives you nice properties
such as guaranteed no memory leaks? Let's just ignore those messy
programs with "pointers", because they break the "desired properties" of
the structures - and anyway, just like loops and recursion, people don't
really use them.
>>
>> Trees are great for climbing - but useless as models of call behaviour
>> and structure in programs.
>>
> We can also prune any if branches that we can prove are not taken.
> Typically that situation arises when a constant is passed to a
> subroutine. Programmers seldom write redundant ifs, so by looking
> at functions in isolation, you can't get this simplification and optimisation.
>
> Now in reality, recursion in C programs is rare, and complex loop conditions
> are also pretty rare.
>
>
[toc] | [prev] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2016-06-21 10:14 -0500 |
| Message-ID | <nkblco$t42$1@dont-email.me> |
| In reply to | #89694 |
David Brown wrote: > On 21/06/16 05:27, Malcolm McLean wrote: <snip> > > Function pointers /always/ make it harder to follow the call > structure of a program. Not in the real world. Tables relying on function pointers will frequently make things easier to understand. In order to scale programs past a certain size, it becomes necessary to "go meta" and indirection is just how that's done, unless you want to resort to C++ style templates or some other analogous mechanism. I predict that 20 years from now, all the "meta" that's currently in style will be gone and largely unmourned, and that 'C' code with function pointers will still be with us. IMO, *the* technology for the management of complexity is still the finite state machine. That's closer to being "function pointer-ey" than it is "call tree-ey". The problem with any discipline that requires a certain academic footing to approach ( and it's arguable whether CS is even one of those even if I think it is[1] ) is that the class bell has to ring some time and things you learn that aren't there because they're fit to print but rather print to fit poison us against things which may be more appropriate. [1] there are legions of people writing software that don't really need to be all that conversant with say, Turing nor Godel or even von Neumann. > It makes sense to avoid them, or at least limit them or constrain > them in some way (such as C++ virtual functions) if you want to > generate call graphs or do other analysis on your code. > Call trees are an attempt to make something that is dynamic static. <snip> > > Trees are great for climbing - but useless as models of call > behaviour and structure in programs. > > +1 -- Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-06-21 16:44 +0100 |
| Message-ID | <87poramtrq.fsf@bsb.me.uk> |
| In reply to | #89694 |
David Brown <david.brown@hesbynett.no> writes: <snip> > Trees are great for climbing - but useless as models of call behaviour > and structure in programs. That's a very odd remark! It may be that the context makes it reasonable but I could see how (so, forgive me, I cut the context). The stack of function call activations can be modelled as a linked list but if instead of unlinking on pop you leave the node in place and when you push a call you make a sibling to all existing calls the result is a tree. It's the trace of all the pushing a popping over time. For ordinary function calls, a tree is the natural model of the dynamic call structure. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-06-21 19:50 +0200 |
| Message-ID | <nkbuon$1hs$1@dont-email.me> |
| In reply to | #89710 |
On 21/06/16 17:44, Ben Bacarisse wrote: > David Brown <david.brown@hesbynett.no> writes: > <snip> >> Trees are great for climbing - but useless as models of call behaviour >> and structure in programs. > > That's a very odd remark! It may be that the context makes it > reasonable but I could see how (so, forgive me, I cut the context). > > The stack of function call activations can be modelled as a linked list > but if instead of unlinking on pop you leave the node in place and when > you push a call you make a sibling to all existing calls the result is a > tree. It's the trace of all the pushing a popping over time. For > ordinary function calls, a tree is the natural model of the dynamic call > structure. > Yes, of course trees are a fine model for the dynamic call behaviour when code is running (unless you have a language supporting coroutines). It is for the static structure that you need a graph rather than a tree. (I'm off on holiday for a bit, so I am unlikely to reply for a while.)
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-06-21 16:33 +0100 |
| Message-ID | <87vb12mu99.fsf@bsb.me.uk> |
| In reply to | #89682 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: <snip> > What's the point in structured programming? > The so-called Malcolm call-tree is the structure of a structured > program. A tree, with cycles for recursion. > The entire paradigm is designed to force the program into this > pattern. No it isn't. Nothing I've read the almost 40 years I've been reading about structured programming uses your specific tree (the one you've made up to exclude recursion and calls to function though data values) to define what makes a program strucured. In fact, both are common techniques in structured programming. You've produced no references to support the idea that this specific tree is used to define the structure of structured programs, and there is ample evidence to the contrary. What's more, even your basic tenet is denied in the classic "Structured Programming" text. When discussing the advantages offered by SIMLUA the author highlights the fact that block activations (roughly the result of your inlining process that makes a tree) are no longer nested. Whilst the procedure calls and returns are nested, you can no longer model the data as nested blocks and your inlining process would fail. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-06-21 10:54 -0700 |
| Message-ID | <lnporaqvf3.fsf@kst-u.example.com> |
| In reply to | #89709 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
[...]
> What's more, even your basic tenet is denied in the classic "Structured
> Programming" text. When discussing the advantages offered by SIMLUA the
> author highlights the fact that block activations (roughly the result of
> your inlining process that makes a tree) are no longer nested. Whilst
> the procedure calls and returns are nested, you can no longer model the
> data as nested blocks and your inlining process would fail.
Just for the sake of anyone doing web searches, it's SIMULA. (SIMLUA, a
hybrid of SIMULA and Lua, might be an intereseting language, though.)
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-06-21 20:02 +0100 |
| Message-ID | <87k2himklg.fsf@bsb.me.uk> |
| In reply to | #89715 |
Keith Thompson <kst-u@mib.org> writes: > Ben Bacarisse <ben.usenet@bsb.me.uk> writes: > [...] >> What's more, even your basic tenet is denied in the classic "Structured >> Programming" text. When discussing the advantages offered by SIMLUA the >> author highlights the fact that block activations (roughly the result of >> your inlining process that makes a tree) are no longer nested. Whilst >> the procedure calls and returns are nested, you can no longer model the >> data as nested blocks and your inlining process would fail. > > Just for the sake of anyone doing web searches, it's SIMULA. (SIMLUA, a > hybrid of SIMULA and Lua, might be an intereseting language, though.) Thanks. (It's getting worse -- it took nearly a minute for me to see the difference between the two even when side by side like that.) -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-06-21 21:13 +0100 |
| Message-ID | <nkc75s$32i$1@dont-email.me> |
| In reply to | #89720 |
On 21/06/2016 20:02, Ben Bacarisse wrote: > Keith Thompson <kst-u@mib.org> writes: > >> Ben Bacarisse <ben.usenet@bsb.me.uk> writes: >> [...] >>> What's more, even your basic tenet is denied in the classic "Structured >>> Programming" text. When discussing the advantages offered by SIMLUA the >>> author highlights the fact that block activations (roughly the result of >>> your inlining process that makes a tree) are no longer nested. Whilst >>> the procedure calls and returns are nested, you can no longer model the >>> data as nested blocks and your inlining process would fail. >> >> Just for the sake of anyone doing web searches, it's SIMULA. (SIMLUA, a >> hybrid of SIMULA and Lua, might be an intereseting language, though.) > > Thanks. (It's getting worse -- it took nearly a minute for me to see > the difference between the two even when side by side like that.) > (Me too...) -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-06-21 13:45 -0700 |
| Message-ID | <lneg7qqnjb.fsf@kst-u.example.com> |
| In reply to | #89734 |
BartC <bc@freeuk.com> writes:
> On 21/06/2016 20:02, Ben Bacarisse wrote:
>> Keith Thompson <kst-u@mib.org> writes:
>>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>> [...]
>>>> What's more, even your basic tenet is denied in the classic "Structured
>>>> Programming" text. When discussing the advantages offered by SIMLUA the
>>>> author highlights the fact that block activations (roughly the result of
>>>> your inlining process that makes a tree) are no longer nested. Whilst
>>>> the procedure calls and returns are nested, you can no longer model the
>>>> data as nested blocks and your inlining process would fail.
>>>
>>> Just for the sake of anyone doing web searches, it's SIMULA. (SIMLUA, a
>>> hybrid of SIMULA and Lua, might be an intereseting language, though.)
>>
>> Thanks. (It's getting worse -- it took nearly a minute for me to see
>> the difference between the two even when side by side like that.)
>>
>
> (Me too...)
And I meant "interesting", not "intereseting". Naturally, it took two
followups before I noticed that typo.
Muphry's Law (sic) strikes again.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | luser droog <luser.droog@gmail.com> |
|---|---|
| Date | 2016-06-20 10:00 -0700 |
| Message-ID | <9510258e-e09e-41ba-aa7d-65ecd9c5906d@googlegroups.com> |
| In reply to | #89644 |
On Monday, June 20, 2016 at 5:12:58 AM UTC-5, Malcolm McLean wrote: > On Monday, June 20, 2016 at 10:51:15 AM UTC+1, Richard Heathfield wrote: > > On 20/06/16 10:22, Malcolm McLean wrote: > > > > But it doesn't. No, Malcolm, it really doesn't. A recursive function is > > just a function. Getting the hang of them is a bit weird at first, but > > once you've got past that stage (which should happen quite early on in > > one's programming experience) they are an extraordinarily useful tool > > and one that makes many programs much simpler to encode with a sensible, > > manageable structure. Can they be abused? Hell yes. So can anything. > > But, used sensibly, they are a blessing and a boon. > > > A recursive function is not just another subroutine call. > It has properties which are fundamentally different. > > > > I wonder what MumbleCo would have made of that... being forced to > > simulate loops with recursion AND simulate recursion with loops! :-) > > > You can ban either loops or recursion, but not both. This is true, but we're on the wrong borderline. According to the Bohm-Jacopini theorem, https://en.wikipedia.org/wiki/Structured_program_theorem you need sequencing, selection (if), and iteration (either recursion or loops). If you remove one of those pieces you lose the power of the Turing Machine. Can't program anything anymore, structured or otherwise.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-06-20 22:07 +0100 |
| Message-ID | <874m8no9gt.fsf@bsb.me.uk> |
| In reply to | #89644 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Monday, June 20, 2016 at 10:51:15 AM UTC+1, Richard Heathfield wrote: >> On 20/06/16 10:22, Malcolm McLean wrote: >> >> But it doesn't. No, Malcolm, it really doesn't. A recursive function is >> just a function. Getting the hang of them is a bit weird at first, but >> once you've got past that stage (which should happen quite early on in >> one's programming experience) they are an extraordinarily useful tool >> and one that makes many programs much simpler to encode with a sensible, >> manageable structure. Can they be abused? Hell yes. So can anything. >> But, used sensibly, they are a blessing and a boon. >> > A recursive function is not just another subroutine call. > It has properties which are fundamentally different. That's true but largely beside the point because the point you are making is not about recursive *function* but recursive *programs*. You can't always tell, just be by looking at it, if a function is going to be involved in a recursive call (f calls g calls h call f) and that's a problem because some programming languages allow functions to be written so that they are not re-entrant. The classic example being 'own' variables in Algol 60. This is a telling point. If you read the classic "Structured Programming" book (citation from me elsewhere in this thread) you will see this problem mentioned by Dijksata. But he does not blame recursion for being unstructured but 'own' declarations for interfering with the structure of recursion. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-06-20 19:08 -0700 |
| Message-ID | <fac4ad0c-d099-487f-8ee5-d369a872f915@googlegroups.com> |
| In reply to | #89672 |
On Monday, June 20, 2016 at 10:07:37 PM UTC+1, Ben Bacarisse wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > > > On Monday, June 20, 2016 at 10:51:15 AM UTC+1, Richard Heathfield wrote: > >> On 20/06/16 10:22, Malcolm McLean wrote: > >> > >> But it doesn't. No, Malcolm, it really doesn't. A recursive function is > >> just a function. Getting the hang of them is a bit weird at first, but > >> once you've got past that stage (which should happen quite early on in > >> one's programming experience) they are an extraordinarily useful tool > >> and one that makes many programs much simpler to encode with a sensible, > >> manageable structure. Can they be abused? Hell yes. So can anything. > >> But, used sensibly, they are a blessing and a boon. > >> > > A recursive function is not just another subroutine call. > > It has properties which are fundamentally different. > > That's true but largely beside the point because the point you are > making is not about recursive *function* but recursive *programs*. You > can't always tell, just be by looking at it, if a function is going to > be involved in a recursive call (f calls g calls h call f) and that's a > problem because some programming languages allow functions to be written > so that they are not re-entrant. The classic example being 'own' > variables in Algol 60. > > This is a telling point. If you read the classic "Structured > Programming" book (citation from me elsewhere in this thread) you will > see this problem mentioned by Dijksata. But he does not blame recursion > for being unstructured but 'own' declarations for interfering with the > structure of recursion. > Nothing I am saying is new. I didn't invent structured programming.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-06-22 01:15 +0100 |
| Message-ID | <87oa6ukrih.fsf@bsb.me.uk> |
| In reply to | #89683 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Monday, June 20, 2016 at 10:07:37 PM UTC+1, Ben Bacarisse wrote: >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: <snip> >> > A recursive function is not just another subroutine call. >> > It has properties which are fundamentally different. >> >> That's true but largely beside the point because the point you are >> making is not about recursive *function* but recursive *programs*. You >> can't always tell, just be by looking at it, if a function is going to >> be involved in a recursive call (f calls g calls h call f) and that's a >> problem because some programming languages allow functions to be written >> so that they are not re-entrant. The classic example being 'own' >> variables in Algol 60. >> >> This is a telling point. If you read the classic "Structured >> Programming" book (citation from me elsewhere in this thread) you will >> see this problem mentioned by Dijksata. But he does not blame recursion >> for being unstructured but 'own' declarations for interfering with the >> structure of recursion. >> > Nothing I am saying is new. Yet you can't cite anyone who's said these things before: that recursion is antithetical to structured programming; that using function pointers (as data) are also; and that a call graph with a special rule for recursion and no rule at all for unnamed functions is used to justify the first two. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2016-06-20 12:38 +0000 |
| Message-ID | <5767e37f.9813515@news.xs4all.nl> |
| In reply to | #89642 |
Malcolm McLean <malcolm.mclean5@btinternet.com> wrote: > On Monday, June 20, 2016 at 10:11:12 AM UTC+1, Richard Heathfield wrote: > > Why does a program have to be balanced in order to be structured? > > > A degnerate tree loses most of the desirable characteristics of a > balanced tree. You know, there is a whole forest of trees between the extremes of "balanced" and "degenerate". In the case of program structure, neither extreme is ideal. You're not implementing a binary search over code lines, after all. Richard
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-06-20 15:48 +0100 |
| Message-ID | <87eg7rq5kv.fsf@bsb.me.uk> |
| In reply to | #89636 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Monday, June 20, 2016 at 1:24:31 AM UTC+1, Ben Bacarisse wrote: >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >> >> > Simply take some C source without gotos, breaks, continues or >> > switches, and indent it in the conventional way. >> > Now inline all the function calls manually. Forget static variables >> > for the moment and function pointers and recursion. >> > >> > Now you have "the tree". >> >> No I don't. I get a tree if I follow a set of rules that constructs it. >> For example, my best guess for your rule is that as you inline a >> function you create a new node and add an edge from the node >> representing the (inlined) calling function to the new node. >> >> But this rule will give you tree even for a recursive program so let me >> know if this is not how your tree is constructed. You have not yet provided the rules to build the tree from whatever process you want to employ. I tried to guess the construction from what you have said, but the resulting tree would have no cycles. Can you give the rules please? Are they really complicated? I want it to 100% clear that recursion is treated as a special case by your construction. Please don't just repeat a process the produces an expanded program text. Your claim was about trees and, specifically, cycles in them so I need the rules about how the tree is built as the program text is gradually expanded step by step. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Martin Shobe <mashobe9@gmail.com> |
|---|---|
| Date | 2016-06-20 23:17 -0500 |
| Message-ID | <nkaf4q$6e0$1@dont-email.me> |
| In reply to | #89620 |
On 6/19/2016 12:38 PM, Malcolm McLean wrote: > On Sunday, June 19, 2016 at 6:08:13 PM UTC+1, Martin Shobe wrote: >> On 6/19/2016 12:33 AM, Malcolm McLean wrote: >>> On Sunday, June 19, 2016 at 6:17:58 AM UTC+1, Martin Shobe wrote: >>>> >>>> Nesting requires that one is, in some sense, inside the other. Blocks >>>> that are reachable would include such blocks, but would also include >>>> blocks that aren't inside, e.g. calling an external function. >>>> >>> So inline the external function. >>> Now it's nested. >> >> The fact that some other code is nested doesn't make the current code >> nested. >> >>>> That would obviously depend on what you changed it too. However, it's >>>> all irrelevant to showing how the tree follows from single entry/exit. >> >>> It seems you're not going to get it. >> >> It also seems you aren't going to supply any evidence to support your >> claim. The below certainly doesn't qualify. >> >>> If we have a single point of entry and a single point of exit, >>> we create an interval or space or step or "block" to whatever >>> you want to think of it as. >>> So anything that happens between the point of entry and the >>> point of exit is "inside", everything that doesn't is "outside". >>> But since you have only one point of entry and one point of exit, >>> there can't be a second interval in which an event is inside >>> that "overlaps". We have an event that is inside block A, and >>> also inside block B, so either block A is inside block B, >>> or block B is inside block A. >>> So there must be nesting. It's enforced by the single entry >>> single exit requirement. >> >> Of course this forms a tree. However, it's not the tree you want since >> this tree is also formed when recursion is used. >> > Try drawing the trees for a recursive and non-recursive structured > program using the rules outlined (each function has one point > of entry and one point of exit). > That should reveal the issue. > You get a tree either way. Is that the issue? Martin Shobe
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-06-20 21:43 -0700 |
| Message-ID | <bae6dc9d-3808-4af6-9863-db1411d1bbe4@googlegroups.com> |
| In reply to | #89688 |
On Tuesday, June 21, 2016 at 5:17:39 AM UTC+1, Martin Shobe wrote: > > > Try drawing the trees for a recursive and non-recursive structured > > program using the rules outlined (each function has one point > > of entry and one point of exit). > > That should reveal the issue. > > > > You get a tree either way. Is that the issue? > It depends exactly how you draw it. The tree is the tree of block nesting. Each block has one point of entry and of exit. So if it contains another block, there must be strict nesting. Blocks cannot overlap. But can it contain itself? What rules do you need to preserve the "one point of entry and of exit" property, and the tree property?
[toc] | [prev] | [next] | [standalone]
| From | Martin Shobe <mashobe9@gmail.com> |
|---|---|
| Date | 2016-06-21 06:36 -0500 |
| Message-ID | <nkb8ra$gkg$1@dont-email.me> |
| In reply to | #89690 |
On 6/20/2016 11:43 PM, Malcolm McLean wrote: > On Tuesday, June 21, 2016 at 5:17:39 AM UTC+1, Martin Shobe wrote: >> >>> Try drawing the trees for a recursive and non-recursive structured >>> program using the rules outlined (each function has one point >>> of entry and one point of exit). >>> That should reveal the issue. >>> >> >> You get a tree either way. Is that the issue? >> > It depends exactly how you draw it. > > The tree is the tree of block nesting. If it's a tree of block nesting, you get a tree with or without recursion. In fact, you get a tree here as long as blocks don't partially overlap, even if those blocks have more than one entry/exit. > Each block has one point > of entry and of exit. So if it contains another block, there must > be strict nesting. Blocks cannot overlap. > But can it contain itself? No. > What rules do you need to preserve the "one point of entry and > of exit" property, and the tree property? The simplest would probably be, "Blocks shall only have one point of entry and of exit." and "Blocks shall not partially overlap." Martin Shobe
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-07-04 10:52 -0700 |
| Message-ID | <72933000-a72d-4089-933d-90ff1d2d3b53@googlegroups.com> |
| In reply to | #89603 |
On Monday, July 4, 2016 at 6:10:35 PM UTC+1, Martin Shobe wrote: > > This discussion is about structured programming. In particular this > question is about the claim that the limitations on the internal > structure of blocks follow from single entry/exit. A claim that Malcolm > made and then appeared to be contradicting. > A block has a single point of entry and of exit. So if you have a program which consists of two blocks they can concatenate, or nest, but they cannot overlap. However internally the blocks need not be structured. A structured program places the additional requirement that blocks consist solely of blocks and selections (if), loops (backwards jumps controlled by an if), and recursive calls.
[toc] | [prev] | [next] | [standalone]
Page 8 of 20 — ← Prev page 1 … 6 7 [8] 9 10 … 20 Next page →
Back to top | Article view | comp.lang.c
csiph-web