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 7 of 20 — ← Prev page 1 … 5 6 [7] 8 9 … 20 Next page →
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-06-20 13:05 +0100 |
| Message-ID | <nk8m5r$996$1@dont-email.me> |
| In reply to | #89648 |
On 20/06/16 12:40, Malcolm McLean wrote: > On Monday, June 20, 2016 at 12:19:36 PM UTC+1, Richard Heathfield wrote: >> On 20/06/16 11:12, Malcolm McLean wrote: >> >>> A recursive function is not just another subroutine call. >>> It has properties which are fundamentally different. >> >> Do please share what these fundamentally different properties are. >> > A tree with a cycle in it has different properties to a tree without. It's > no longer strictly a tree. You lost the tree when you allowed loops. > We can no longer traverse and enumerate nodes. Sure we can. We just have to mark as we go. > We no longer have a maximum depth. Trees don't have a maximum depth. > We no longer have a unique path from leaf to root and root to leaf. You lost that, too, with loops. > We can no longer eliminate sub-branches by replacing them with > leaf nodes which are equivalent. But that would in any case be a backward step, since it would involve functional *re*composition. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-06-20 05:32 -0700 |
| Message-ID | <8186ad7d-9e5b-40b7-8aae-f991bdd671e5@googlegroups.com> |
| In reply to | #89649 |
On Monday, June 20, 2016 at 1:05:25 PM UTC+1, Richard Heathfield wrote: > On 20/06/16 12:40, Malcolm McLean wrote: > > A tree with a cycle in it has different properties to a tree without. It's > > no longer strictly a tree. > > You lost the tree when you allowed loops. > Yes, ultimately loops and recursion can emulate each other, and so if you analyse the structure closely enough, you will find that they are equivalent. > > > We can no longer eliminate sub-branches by replacing them with > > leaf nodes which are equivalent. > > But that would in any case be a backward step, since it would involve > functional *re*composition. > Yes. Sometimes it's necessary to go backwards, and redo. You have an army, and you divide your men up into platoons of fifteen to thirty soldiers, three sections per platoon. You then decide that's not a good idea any more, and you want them in "teams" of exactly two men and "pods" of exactly five teams. So you give the order to reorganise. As they move about on the parade ground, they will go through a point where they are a disorganised rabble, and an enemy attack at exactly that moment would be fatal. But it will only last a minute or so. Then they will be reorganised.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-06-20 15:53 +0100 |
| Message-ID | <878txzq5d1.fsf@bsb.me.uk> |
| In reply to | #89649 |
Richard Heathfield <rjh@cpax.org.uk> writes: > On 20/06/16 12:40, Malcolm McLean wrote: >> On Monday, June 20, 2016 at 12:19:36 PM UTC+1, Richard Heathfield wrote: >>> On 20/06/16 11:12, Malcolm McLean wrote: >>> >>>> A recursive function is not just another subroutine call. >>>> It has properties which are fundamentally different. >>> >>> Do please share what these fundamentally different properties are. >>> >> A tree with a cycle in it has different properties to a tree without. It's >> no longer strictly a tree. > > You lost the tree when you allowed loops. How can you tell? Do you really think that Malcolm has given the construction with enough detail that you can argue about the result? If so, please explain the construction to me! <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-06-20 16:22 +0100 |
| Message-ID | <nk91oa$jt0$1@dont-email.me> |
| In reply to | #89655 |
On 20/06/16 15:53, Ben Bacarisse wrote:
> Richard Heathfield <rjh@cpax.org.uk> writes:
>
>> On 20/06/16 12:40, Malcolm McLean wrote:
>>> On Monday, June 20, 2016 at 12:19:36 PM UTC+1, Richard Heathfield wrote:
>>>> On 20/06/16 11:12, Malcolm McLean wrote:
>>>>
>>>>> A recursive function is not just another subroutine call.
>>>>> It has properties which are fundamentally different.
>>>>
>>>> Do please share what these fundamentally different properties are.
>>>>
>>> A tree with a cycle in it has different properties to a tree without. It's
>>> no longer strictly a tree.
>>
>> You lost the tree when you allowed loops.
>
> How can you tell? Do you really think that Malcolm has given the
> construction with enough detail that you can argue about the result? If
> so, please explain the construction to me!
I keep thinking I follow it, and he keeps surprising me, but this is
what I've got in my head thing:
To make the description as clear as possible, I'm going to refer to the
textual layout, assuming perfectly applied Allman style but with
one-space indents, like this:
main()
{
foo();
if(bar)
{
baz();
}
}
where every if() is always followed by braces. This is not an essential
component of the source, but I think it'll make it easier to talk about.
A 'node' is defined to be either a decision point or a function. Any
node can be a parent node. Any node except main can be a child node (so
main is the root node). To construct the tree, then, you start at main.
main's child nodes are at Indent Level 1, main itself being Level 0. In
the above example, main's children are foo() and if(). Add each of
main's child nodes to the tree:
main ---+-----+
| |
foo if
main is now done.
We now look at each identified but unprocessed child node in turn,
considering it in its new role as potential parent. Every time a new
child node is identified, it must be added to the list of identified but
unprocessed child nodes. (This is just a terrible way of saying "keep
building the tree recursively until you run out of program".)
For each node N at Indent Level L:
{
If N is a decision point (if/for/while/switch):
{
In the following block statement, each function
call or decision point at Indent Level L+1 is
considered a child of N. Add the node to N's
list of children, and mark it as unprocessed.
}
else if N is a function call to F():
{
make a note of where you've got to, and recurse
into F(), applying the same rules again. See
below for how to handle any calls to F() within
F().
}
Mark N as processed.
}
Note that, if F() is called many times, it will be processed many times,
as each invocation is considered a separate node.
Recursive F() needs to be handled as a special case because otherwise
our little tree-building parser will disappear up its own exhaust pipe
(we can't expect the tree-builder to establish the state of the base
case). The special-case fix could be as simple as a Boolean flag
(recursive yes/no) in the node's internal data structure, with the flag
printed on the output:
\
\
\
\
+----------------+
| F() |
| recursive? Yes |
+----------------+
I *think* that does it. You can replace my artificial "indent level"
measure with equivalent node-depth logic (to remove reliance on
pretty-printed source), and you can remove my "every control statement
is followed by a block statement" requirement by adding appropriate
processing of a single-statement control body.
Like I said, I'm /fairly/ sure that's how Malcolm sees it. What I'm not
at all sure of is what point he sees in insisting that it must be a tree.
--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-06-20 17:13 +0100 |
| Message-ID | <87shw7on3n.fsf@bsb.me.uk> |
| In reply to | #89657 |
Richard Heathfield <rjh@cpax.org.uk> writes:
> On 20/06/16 15:53, Ben Bacarisse wrote:
>> Richard Heathfield <rjh@cpax.org.uk> writes:
>>
>>> On 20/06/16 12:40, Malcolm McLean wrote:
>>>> On Monday, June 20, 2016 at 12:19:36 PM UTC+1, Richard Heathfield wrote:
>>>>> On 20/06/16 11:12, Malcolm McLean wrote:
>>>>>
>>>>>> A recursive function is not just another subroutine call.
>>>>>> It has properties which are fundamentally different.
>>>>>
>>>>> Do please share what these fundamentally different properties are.
>>>>>
>>>> A tree with a cycle in it has different properties to a tree without. It's
>>>> no longer strictly a tree.
>>>
>>> You lost the tree when you allowed loops.
>>
>> How can you tell? Do you really think that Malcolm has given the
>> construction with enough detail that you can argue about the result? If
>> so, please explain the construction to me!
>
> I keep thinking I follow it, and he keeps surprising me, but this is
> what I've got in my head thing:
>
> To make the description as clear as possible, I'm going to refer to
> the textual layout, assuming perfectly applied Allman style but with
> one-space indents, like this:
>
> main()
> {
> foo();
> if(bar)
> {
> baz();
> }
> }
>
> where every if() is always followed by braces. This is not an
> essential component of the source, but I think it'll make it easier to
> talk about.
>
> A 'node' is defined to be either a decision point or a function. Any
> node can be a parent node. Any node except main can be a child node
> (so main is the root node). To construct the tree, then, you start at
> main.
>
> main's child nodes are at Indent Level 1, main itself being Level
> 0. In the above example, main's children are foo() and if(). Add each
> of main's child nodes to the tree:
>
> main ---+-----+
> | |
> foo if
>
> main is now done.
>
> We now look at each identified but unprocessed child node in turn,
> considering it in its new role as potential parent. Every time a new
> child node is identified, it must be added to the list of identified
> but unprocessed child nodes. (This is just a terrible way of saying
> "keep building the tree recursively until you run out of program".)
It does not look recursive to me (other than in the trivial sense that
it could be written as a recursive function). If the construction were
depth-first I'd call it recursive but I think you are expanding the tree
breadth first.
> For each node N at Indent Level L:
> {
> If N is a decision point (if/for/while/switch):
> {
> In the following block statement, each function
> call or decision point at Indent Level L+1 is
> considered a child of N. Add the node to N's
> list of children, and mark it as unprocessed.
> }
> else if N is a function call to F():
> {
> make a note of where you've got to, and recurse
> into F(), applying the same rules again. See
> below for how to handle any calls to F() within
> F().
> }
> Mark N as processed.
> }
>
> Note that, if F() is called many times, it will be processed many
> times, as each invocation is considered a separate node.
>
> Recursive F() needs to be handled as a special case because otherwise
> our little tree-building parser will disappear up its own exhaust pipe
> (we can't expect the tree-builder to establish the state of the base
> case). The special-case fix could be as simple as a Boolean flag
> (recursive yes/no) in the node's internal data structure, with the
> flag printed on the output:
>
> \
> \
> \
> \
> +----------------+
> | F() |
> | recursive? Yes |
> +----------------+
>
> I *think* that does it. You can replace my artificial "indent level"
> measure with equivalent node-depth logic (to remove reliance on
> pretty-printed source), and you can remove my "every control statement
> is followed by a block statement" requirement by adding appropriate
> processing of a single-statement control body.
>
> Like I said, I'm /fairly/ sure that's how Malcolm sees it. What I'm
> not at all sure of is what point he sees in insisting that it must be
> a tree.
Considering only the parts that relate to function calls, that's what I
though too, except for the key part about recursive calls. You've had
to guess and I am sure you are wrong in that guess because your rule
does not make a cyclic graph.
My best guess so far is as above except that
(a) the recursive call is spotted and a new node is node generated.
Instead, the tree is made into a loop because he really wants a loop;
(b) calls that don't use the function name are just not handled making
such programs not Malcolm-structured programs.
Both of these are at odds with how the world sees structured
programming.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-06-20 10:11 -0700 |
| Message-ID | <29efc4b9-fffc-45de-aec4-ce131c12e9ab@googlegroups.com> |
| In reply to | #89657 |
On Monday, June 20, 2016 at 4:23:02 PM UTC+1, Richard Heathfield wrote:
>
> I keep thinking I follow it, and he keeps surprising me, but this is
> what I've got in my head thing:
>
> To make the description as clear as possible, I'm going to refer to the
> textual layout, assuming perfectly applied Allman style but with
> one-space indents, like this:
>
> main()
> {
> foo();
> if(bar)
> {
> baz();
> }
> }
>
> where every if() is always followed by braces. This is not an essential
> component of the source, but I think it'll make it easier to talk about.
>
> A 'node' is defined to be either a decision point or a function. Any
> node can be a parent node. Any node except main can be a child node (so
> main is the root node). To construct the tree, then, you start at main.
>
> main's child nodes are at Indent Level 1, main itself being Level 0. In
> the above example, main's children are foo() and if(). Add each of
> main's child nodes to the tree:
>
> main ---+-----+
> | |
> foo if
>
> main is now done.
>
> We now look at each identified but unprocessed child node in turn,
> considering it in its new role as potential parent. Every time a new
> child node is identified, it must be added to the list of identified but
> unprocessed child nodes. (This is just a terrible way of saying "keep
> building the tree recursively until you run out of program".)
>
> For each node N at Indent Level L:
> {
> If N is a decision point (if/for/while/switch):
> {
> In the following block statement, each function
> call or decision point at Indent Level L+1 is
> considered a child of N. Add the node to N's
> list of children, and mark it as unprocessed.
> }
> else if N is a function call to F():
> {
> make a note of where you've got to, and recurse
> into F(), applying the same rules again. See
> below for how to handle any calls to F() within
> F().
> }
> Mark N as processed.
> }
>
> Note that, if F() is called many times, it will be processed many times,
> as each invocation is considered a separate node.
>
> Recursive F() needs to be handled as a special case because otherwise
> our little tree-building parser will disappear up its own exhaust pipe
> (we can't expect the tree-builder to establish the state of the base
> case). The special-case fix could be as simple as a Boolean flag
> (recursive yes/no) in the node's internal data structure, with the flag
> printed on the output:
>
> \
> \
> \
> \
> +----------------+
> | F() |
> | recursive? Yes |
> +----------------+
>
> I *think* that does it. You can replace my artificial "indent level"
> measure with equivalent node-depth logic (to remove reliance on
> pretty-printed source), and you can remove my "every control statement
> is followed by a block statement" requirement by adding appropriate
> processing of a single-statement control body.
>
> Like I said, I'm /fairly/ sure that's how Malcolm sees it. What I'm not
> at all sure of is what point he sees in insisting that it must be a tree.
>
You've more or less got it.
If we write a leaf function in the structured programming way, it calls
no subroutines, and is a tree, with the blocks forming children
for lops and ifs. Conventionally we indent the source to make the tree
structure obvious.
If we write a non-leaf function, which calls a leaf subroutine, we
can convert it to a leaf function, by inlining the subroutine.
So we've got a tree of blocks.
If we've got a function that takes a function pointer as an argument,
and calls it, we can still convert the function to leaf by inlining the call,
if we can determine the value of the function pointer at compile time.
We can't do this if the function pointer is dynamically bound.
If we've got a function which calls itself, either directly or indirectly,
we can't convert the function to leaf.
If we can convert the entire program to leaf, we can run it on a system
that doesn't support subroutines.
But if we don't adhere to structure programming rules strictly, we
can still convert the program to leaf, but now it won't be a strict
tree of blocks. it will likely be close, however, with just a few jumps
into and out of what are C "blocks", code within curly braces, but
not structured programming block.
However all the code that we have expanded from the subroutines
must be a "block" in the structured programming sense. We can't have
jumps into the subroutine except from the point of call, we can't have
jumps out of it except to the point of return, which is one step
below the point of call.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-06-20 21:39 +0100 |
| Message-ID | <87a8ifoar2.fsf@bsb.me.uk> |
| In reply to | #89664 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Monday, June 20, 2016 at 4:23:02 PM UTC+1, Richard Heathfield wrote: <snip> >> Like I said, I'm /fairly/ sure that's how Malcolm sees it. <snip> > You've more or less got it. Except Richard's constructed trees do not have any cycles -- he leaves that part but vague because you have left it vague. I fear you are determined never to explain the tree construction for fear of being too clear. After all, it's not as if any of this is hard to understand, it's just unspecified. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-06-20 19:10 -0700 |
| Message-ID | <51b70d0a-647d-4ed5-a83c-74707ba91eba@googlegroups.com> |
| In reply to | #89671 |
On Monday, June 20, 2016 at 9:39:53 PM UTC+1, Ben Bacarisse wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > > Except Richard's constructed trees do not have any cycles -- he leaves > that part but vague because you have left it vague. I fear you are > determined never to explain the tree construction for fear of being too > clear. After all, it's not as if any of this is hard to understand, > it's just unspecified. > Yes, because recursion breaks the tree-like structure. It's no longer a tree. That's the whole point.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-06-22 01:14 +0100 |
| Message-ID | <87r3bqkrkv.fsf@bsb.me.uk> |
| In reply to | #89684 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Monday, June 20, 2016 at 9:39:53 PM UTC+1, Ben Bacarisse wrote: >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >> >> Except Richard's constructed trees do not have any cycles -- he leaves >> that part but vague because you have left it vague. I fear you are >> determined never to explain the tree construction for fear of being too >> clear. After all, it's not as if any of this is hard to understand, >> it's just unspecified. >> > Yes, because recursion breaks the tree-like structure. It breaks *a* tree-like structure that you've made up for the purpose. The dynamic call tree in a tree in all cases, and the static call graph has cycles in the case of recursion but that's not always a tree in its absence. (I'm at fault myself for writing the "here" because both of these standard constructs can be defined in slightly different ways.) > It's no longer a tree. > That's the whole point. I think everyone here knows this now. The whole point of your never to be clarified construction is to special-case the features you don't like. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-06-21 17:27 -0700 |
| Message-ID | <c9945646-d5d1-405a-b9a2-720418083cfb@googlegroups.com> |
| In reply to | #89743 |
On Wednesday, June 22, 2016 at 1:14:33 AM UTC+1, Ben Bacarisse wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > > > It's no longer a tree. > > That's the whole point. > > I think everyone here knows this now. The whole point of your never to > be clarified construction is to special-case the features you don't > like. > Trees are where it's at. Trees, trees. Trees are tractable, graphs are not. As a general rule, if you can get your data into a tree structure, you can deal with it. If you can't then there are likely to be all sorts of difficult problems cropping up. That applies to code as much as to data. The reason I dislike certain structures are that they break the tree. I didn't invent "the tree". The person who first represented a program using indents for nested blocks did that. And no, I don't know who it was. But it wasn't me, I can assure you of that. I am genuinely the inventor of bit-based programming. But I've been careful to keep my own ideas out of this discussion.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-06-22 08:24 -0700 |
| Message-ID | <db4f9ef1-ef77-4bb0-a0d8-fca1f1dc524e@googlegroups.com> |
| In reply to | #89747 |
On Tuesday, June 21, 2016 at 7:27:47 PM UTC-5, Malcolm McLean wrote: > Trees are where it's at. > Trees, trees. > > Trees are tractable, graphs are not. As a general rule, if you can > get your data into a tree structure, you can deal with it. If you can't > then there are likely to be all sorts of difficult problems > cropping up. > That applies to code as much as to data. Are you familiar with the term "DAG"? A DAG is a Directed Acyclic Graph, which has the property that edge is marked with a direction, and there will never be a path from any node to itself. Dags are sometimes harder to represent visually than trees, but can be represented with far less redundancy. I would suggest that dags should really be "where it's at" in many cases. Recursion won't work in a dag any better than it works in a tree, but in many cases where a program uses recursion removing a small number of edges would turn the graph into a DAG; the compiler can't omit the recursive calls, of course, but it can add code to save context before them and restore context afterward. Like trees, DAGs have the useful property that they can be organized into levels two ways: maximum distance from root, or maximum distance to leaf. If you've not looked at DAGs before, I highly recommend it.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-06-22 20:00 +0100 |
| Message-ID | <87twgljbga.fsf@bsb.me.uk> |
| In reply to | #89747 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Wednesday, June 22, 2016 at 1:14:33 AM UTC+1, Ben Bacarisse wrote: >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >> >> > It's no longer a tree. >> > That's the whole point. >> >> I think everyone here knows this now. The whole point of your never to >> be clarified construction is to special-case the features you don't >> like. >> > Trees are where it's at. Agreed. > Trees, trees. Agreed. Agreed. > Trees are tractable, graphs are not. Which is why I would not invent a rule to turn the simple dynamic call tree into a graph. <snip> > The reason I dislike certain structures are that they break the tree. You've done it again. They break *a* tree. They don't break the dynamic call tree. I have to conclude that you are doing this deliberately -- you can't be so unaware of your use of language. > I didn't invent "the tree". No, you invented "a tree" and, since you can't site any other uses of it in relation to structured programming, I will continue to say you did. And I'd still like to see you actually state the rules for constructing the Malcolm-call-tree, in part so I can see how you ban calling functions through pointer parameters (or, no doubt, other data). <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-06-22 23:23 -0700 |
| Message-ID | <43357a4a-c611-4176-8e7f-296d839b4948@googlegroups.com> |
| In reply to | #89759 |
On Wednesday, June 22, 2016 at 8:00:30 PM UTC+1, Ben Bacarisse wrote: > > And I'd still like to see you actually state the rules for constructing > the Malcolm-call-tree, in part so I can see how you ban calling > functions through pointer parameters (or, no doubt, other data). > It's very simple and natural. A function is a node, its subroutines are children, and each child appears as many times as it is called from separate places. It's not too important if you draw the tree as a DAG, because shared subroutines are identical, or if you merge identical children. Unless a child takes a function pointer as a parameter. Then its child becomes the function passed by indirection and its no longer true that identical children have the same children. (You might ask how a node can be "identical" to another node and have different children, the answer is that physically the nodes are the same machine instructions, so "identical" in that sense). However dynamic binding makes it difficult to draw the tree. You could work out all possible values of the pointer and draw separate children, but that gets less and less practical as dynamic binding becomes your structuring method of choice. And recursion either adds cycles to the tree, or in the case of recursion with the number of steps known at compile time adds a known but likely excessive number of identical child/grandchild steps, or in the case of the number of steps not being known at compile time, turns the tree into a dynamic structure that varies on each call. So recursion is not disastrous, especially if used lightly, but it's very much a special case. Trees are more tractable than graphs, even DAGs, that's the first reason for thinking of it as a tree rather than a DAG. The second is to accommodate function pointers. The third is for consistency with the structured programming model for programs without subroutines. The fourth is that we have a unique path from leaf back to parent. The fifth is that each branch becomes independent. The sixth is that subroutines used as structuring elements, and which appear once, are rather different from subroutines used for code reuse, which appear several times and are designed to be exposed in libraries, and the former is the main focus of interest here, mostly you'll just declare your library subroutines like printf to be "leaf". A subroutine in C is virtually constrained to be a block, unless you use special flow control routines like longjmp() or exit(), or unless it never returns. A block has a single point of entry and a single point of exit. However subroutines are not constrained to be written in the structured programming way, and quite often aren't, with the most common violation being multiple returns. Structured programming is robust. If a block is not internally structured, that doesn't render the blocks it contains non- structured, and it doesn't prevent it from being a component of a structured programming block. So a tree of subroutines rather than a tree of blocks makes sense. However if you inline all subroutines you are not really changing the structure of the program, in fact the tree becomes more obvious because its given by indentation (though you've got to have if nodes and loop nodes, which the subroutine tree ignores). In practical terms, people think in subroutines. A programmer can usually tell you which subroutines he wrote today and what they do, he's much less likely to be able to tell you which if blocks he wrote and what they do.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-06-23 08:15 -0700 |
| Message-ID | <lnwplgos1r.fsf@kst-u.example.com> |
| In reply to | #89760 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Wednesday, June 22, 2016 at 8:00:30 PM UTC+1, Ben Bacarisse wrote:
>> And I'd still like to see you actually state the rules for constructing
>> the Malcolm-call-tree, in part so I can see how you ban calling
>> functions through pointer parameters (or, no doubt, other data).
>>
> It's very simple and natural.
> A function is a node, its subroutines are children, and each child
> appears as many times as it is called from separate places.
Are you using the word "function" in the same way the C standard does?
Is "subroutine" synonymous with "function"? If so, why use two
different words? (If "subroutine" means something different than
"function", I have no further questions, because I'd have no further
interest in dragging out your definitions of standard terms.)
By "its subroutines", do you mean functions that are called from
original function?
[...]
--
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-23 20:48 +0100 |
| Message-ID | <87por7it4u.fsf@bsb.me.uk> |
| In reply to | #89760 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Wednesday, June 22, 2016 at 8:00:30 PM UTC+1, Ben Bacarisse wrote: >> >> And I'd still like to see you actually state the rules for constructing >> the Malcolm-call-tree, in part so I can see how you ban calling >> functions through pointer parameters (or, no doubt, other data). >> > It's very simple and natural. > A function is a node, its subroutines are children, and each child > appears as many times as it is called from separate places. > It's not too important if you draw the tree as a DAG, because > shared subroutines are identical, or if you merge identical children. Blimey! That's the call graph you rejected as not being the Malcolm-call-tree. You also insisted that nodes were function activations and not functions themselves. That was why why nodes representing the same function could *not* be merged. And this could be either a static or a dynamic construction -- I don't think you've made that clear (the old one was static being based on textual substitution). I don't think there is enough firm ground for meaningful discussion here. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-06-20 23:48 +0100 |
| Message-ID | <nk9rs9$pef$1@dont-email.me> |
| In reply to | #89664 |
On 20/06/16 18:11, Malcolm McLean wrote: > On Monday, June 20, 2016 at 4:23:02 PM UTC+1, Richard Heathfield wrote: >> <snip> >> Like I said, I'm /fairly/ sure that's how Malcolm sees it. What I'm not >> at all sure of is what point he sees in insisting that it must be a tree. >> > You've more or less got it. Great! I'm delighted to hear it. In which case, my reaction is that it's completely pointless. If I want to look at what functions a function calls, I can just look at the function. If I want to look at what functions are called inside a loop or an if, I can just look at the loop or the if. No, what I really, /really/ want from such a diagram is "from which places is this function called?", and that's just what your tree doesn't give me. Also, it doesn't handle recursion elegantly. I don't think it handles mutual recursion *at all*, and it would need to be modified to allow this. But, whatever its uses and practicalities (or otherwise), what I really don't see is why you think of this tree as being definitively 'structured'. Neither do I see why you need it to be a tree. <snip> -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-06-20 19:02 -0700 |
| Message-ID | <b810c036-f755-436b-a63d-647233d556a7@googlegroups.com> |
| In reply to | #89676 |
On Monday, June 20, 2016 at 11:48:49 PM UTC+1, Richard Heathfield wrote: > On 20/06/16 18:11, Malcolm McLean wrote: > > On Monday, June 20, 2016 at 4:23:02 PM UTC+1, Richard Heathfield wrote: > >> > <snip> > > >> Like I said, I'm /fairly/ sure that's how Malcolm sees it. What I'm not > >> at all sure of is what point he sees in insisting that it must be a tree. > >> > > You've more or less got it. > > Great! I'm delighted to hear it. In which case, my reaction is that it's > completely pointless. If I want to look at what functions a function > calls, I can just look at the function. If I want to look at what > functions are called inside a loop or an if, I can just look at the loop > or the if. No, what I really, /really/ want from such a diagram is "from > which places is this function called?", and that's just what your tree > doesn't give me. > 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. > > Also, it doesn't handle recursion elegantly. I don't think it handles > mutual recursion *at all*, and it would need to be modified to allow this. > > But, whatever its uses and practicalities (or otherwise), what I really > don't see is why you think of this tree as being definitively > 'structured'. Neither do I see why you need it to be a tree. > If we consider just a structured leaf subroutine, there are three main forms of notation for it. The first is using C-style curly brackets with nesting. The second is using strict indentation. The third is using a flow chart. The first two are also common notation for trees. The third isn't obviously tree-like, but is the same structure underneath. Why preserve the property that we can convert subroutines from leaf to non-leaf, whilst preserving the structure of the program? That's a rule. Non-recursive subroutine calls are just blocks, they're not considered special controls in their own right.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-06-21 03:45 +0100 |
| Message-ID | <nka9ns$rpm$1@dont-email.me> |
| In reply to | #89682 |
On 21/06/16 03:02, Malcolm McLean wrote:
> On Monday, June 20, 2016 at 11:48:49 PM UTC+1, Richard Heathfield wrote:
>> On 20/06/16 18:11, Malcolm McLean wrote:
>>> On Monday, June 20, 2016 at 4:23:02 PM UTC+1, Richard Heathfield wrote:
>>>>
>> <snip>
>>
>>>> Like I said, I'm /fairly/ sure that's how Malcolm sees it. What I'm not
>>>> at all sure of is what point he sees in insisting that it must be a tree.
>>>>
>>> You've more or less got it.
>>
>> Great! I'm delighted to hear it. In which case, my reaction is that it's
>> completely pointless. If I want to look at what functions a function
>> calls, I can just look at the function. If I want to look at what
>> functions are called inside a loop or an if, I can just look at the loop
>> or the if. No, what I really, /really/ want from such a diagram is "from
>> which places is this function called?", and that's just what your tree
>> doesn't give me.
>>
> What's the point in structured programming?
Simplifying the control flow.
> 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
> The entire paradigm is designed to force the program into this
> pattern.
That's the "MSP" paradigm, not the paradigm that everybody else thinks
of as structured programming.
Believe it or not, I more or less agree with more or less everything
you've said (except, of course, for the bits I don't agree with).
I generally prefer for functions to have one entry point and one exit
point. I prefer for control structures to have one entry point and one
exit point, too. Branches are fine:
|
IF cond
/ \
Y N
\ /
\/
common
and multi-way branches are fine:
|
SWITCH(value)
| | | | | | |
a b c d e f *
\ /
common
and these all sit very well with the idea of a directed acyclic graph,
but they don't work well as trees. Trees don't grow that way.
In 1997 I had the chance to play with the (extraordinarily expensive)
McCabe code complexity analysis toolkit, which could turn C code into
diagrams at the statement level. When I fed this toolkit some C sources
from my client du jour, they looked a bit of a mess but normally not too
bad.
When I fed my own programs to the same analyser, I was delighted to see
that almost without exception they /looked/ beautiful. The structure was
self-evident, and indeed almost crystalline. These were /structured/
programs.
But they were graphs, not trees.
<snip>
--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-06-20 20:27 -0700 |
| Message-ID | <699201cb-f47b-42cc-bdd4-7b2048689a8e@googlegroups.com> |
| In reply to | #89685 |
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. Sometimes the former graph 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. > > and these all sit very well with the idea of a directed acyclic graph, > but they don't work well as trees. Trees don't grow that way. > The tree is the tree of nested blocks. Blocks nest, that's the crucial point of structured programming. You can certainly see an if node as a flow graph if you want, a flowchart is one common representation. Or you can see it as the node of tree with two children, and the rule that on each visit you traverse one child, but never both. Loops ultimately introduce a cycle. Structured programming cannot solve the halting problem, it just keeps it under control. Most structured programs will terminate and we can easily show that all the loops must terminate. Others will never terminate and we can just as easily show that we have a while(true). Just a few have complex loops where it's hard to show if they terminate or not without dry-running the program. We can't ban both loops and recursion, unfortunately. We have to accept the problem somewhere. > > In 1997 I had the chance to play with the (extraordinarily expensive) > McCabe code complexity analysis toolkit, which could turn C code into > diagrams at the statement level. When I fed this toolkit some C sources > from my client du jour, they looked a bit of a mess but normally not too > bad. > > When I fed my own programs to the same analyser, I was delighted to see > that almost without exception they /looked/ beautiful. The structure was > self-evident, and indeed almost crystalline. These were /structured/ > programs. > > But they were graphs, not trees. > Trees, Richard trees. The world needs more trees. Graphs are ugly. Trees are nice.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-06-21 10:03 +0200 |
| Message-ID | <nkasda$a12$1@dont-email.me> |
| In reply to | #89686 |
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. 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. > > 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...". >> >> In 1997 I had the chance to play with the (extraordinarily expensive) >> McCabe code complexity analysis toolkit, which could turn C code into >> diagrams at the statement level. When I fed this toolkit some C sources >> from my client du jour, they looked a bit of a mess but normally not too >> bad. >> >> When I fed my own programs to the same analyser, I was delighted to see >> that almost without exception they /looked/ beautiful. The structure was >> self-evident, and indeed almost crystalline. These were /structured/ >> programs. >> >> But they were graphs, not trees. >> > Trees, Richard trees. > > The world needs more trees. Graphs are ugly. Trees are nice. > Trees are great for climbing - but useless as models of call behaviour and structure in programs.
[toc] | [prev] | [next] | [standalone]
Page 7 of 20 — ← Prev page 1 … 5 6 [7] 8 9 … 20 Next page →
Back to top | Article view | comp.lang.c
csiph-web