Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #10575 > unrolled thread
| Started by | Helmar Wodtke <helmwo@gmail.com> |
|---|---|
| First post | 2012-03-27 07:26 -0700 |
| Last post | 2012-04-08 21:56 -0700 |
| Articles | 20 on this page of 205 — 28 participants |
Back to article view | Back to comp.lang.forth
How about helping optimization in language? Helmar Wodtke <helmwo@gmail.com> - 2012-03-27 07:26 -0700
Re: How about helping optimization in language? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-03-27 09:32 -0500
Re: How about helping optimization in language? Helmar Wodtke <helmwo@gmail.com> - 2012-03-27 08:12 -0700
Re: How about helping optimization in language? Coos Haak <chforth@hccnet.nl> - 2012-03-27 17:48 +0200
Re: How about helping optimization in language? Helmar Wodtke <helmwo@gmail.com> - 2012-03-27 09:04 -0700
Re: How about helping optimization in language? Bernd Paysan <bernd.paysan@gmx.de> - 2012-03-28 00:42 +0200
Re: How about helping optimization in language? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-03-27 11:34 -0500
Re: How about helping optimization in language? Helmar Wodtke <helmwo@gmail.com> - 2012-03-27 09:46 -0700
Re: How about helping optimization in language? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-03-27 12:27 -0500
Re: How about helping optimization in language? Helmar Wodtke <helmwo@gmail.com> - 2012-03-27 11:29 -0700
Re: How about helping optimization in language? "Elizabeth D. Rather" <erather@forth.com> - 2012-03-27 08:40 -1000
Re: How about helping optimization in language? John Passaniti <john.passaniti@gmail.com> - 2012-03-27 14:12 -0700
Re: How about helping optimization in language? "Elizabeth D. Rather" <erather@forth.com> - 2012-03-27 12:27 -1000
Re: How about helping optimization in language? Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-03-28 03:43 -0700
Re: How about helping optimization in language? Bernd Paysan <bernd.paysan@gmx.de> - 2012-03-28 00:41 +0200
Re: How about helping optimization in language? Paul Rubin <no.email@nospam.invalid> - 2012-03-28 00:12 -0700
Re: How about helping optimization in language? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-03-28 11:17 +0000
Re: How about helping optimization in language? Paul Rubin <no.email@nospam.invalid> - 2012-03-28 07:35 -0700
Re: How about helping optimization in language? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-03-28 16:31 +0000
Re: How about helping optimization in language? Bernd Paysan <bernd.paysan@gmx.de> - 2012-03-28 22:18 +0200
Re: How about helping optimization in language? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-03-28 12:07 -0500
Re: How about helping optimization in language? Paul Rubin <no.email@nospam.invalid> - 2012-04-01 22:48 -0700
Re: How about helping optimization in language? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-04-02 04:41 -0500
Re: How about helping optimization in language? Paul Rubin <no.email@nospam.invalid> - 2012-04-02 17:40 -0700
Re: How about helping optimization in language? "Elizabeth D. Rather" <erather@forth.com> - 2012-04-02 15:35 -1000
Re: How about helping optimization in language? Paul Rubin <no.email@nospam.invalid> - 2012-04-02 19:25 -0700
Re: How about helping optimization in language? "Elizabeth D. Rather" <erather@forth.com> - 2012-04-02 20:45 -1000
Re: How about helping optimization in language? Mark Wills <markrobertwills@yahoo.co.uk> - 2012-04-03 00:51 -0700
Re: How about helping optimization in language? "Elizabeth D. Rather" <erather@forth.com> - 2012-04-02 22:17 -1000
Re: How about helping optimization in language? Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-04-03 02:32 -0700
Re: How about helping optimization in language? mhx@iae.nl (Marcel Hendrix) - 2012-04-03 20:22 +0200
Re: How about helping optimization in language? Paul Rubin <no.email@nospam.invalid> - 2012-04-03 11:53 -0700
Re: How about helping optimization in language? "Elizabeth D. Rather" <erather@forth.com> - 2012-04-03 09:10 -1000
Re: How about helping optimization in language? Mark Wills <markrobertwills@yahoo.co.uk> - 2012-04-03 14:16 -0700
Re: How about helping optimization in language? mhx@iae.nl (Marcel Hendrix) - 2012-04-05 21:27 +0200
Re: How about helping optimization in language? Bernd Paysan <bernd.paysan@gmx.de> - 2012-04-03 22:27 +0200
Re: How about helping optimization in language? "Elizabeth D. Rather" <erather@forth.com> - 2012-04-03 10:45 -1000
Re: How about helping optimization in language? Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-04-04 10:34 +0000
Re: How about helping optimization in language? Mark Wills <markrobertwills@yahoo.co.uk> - 2012-04-03 00:43 -0700
Re: How about helping optimization in language? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-04-03 03:59 -0500
Re: How about helping optimization in language? Paul Rubin <no.email@nospam.invalid> - 2012-04-03 20:34 -0700
Re: How about helping optimization in language? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-04-04 05:32 -0500
Re: How about helping optimization in language? Paul Rubin <no.email@nospam.invalid> - 2012-04-07 22:15 -0700
Re: How about helping optimization in language? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-04-08 04:55 -0500
Re: How about helping optimization in language? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-04-08 15:51 +0000
Re: How about helping optimization in language? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-04-08 11:34 -0500
Re: How about helping optimization in language? Paul Rubin <no.email@nospam.invalid> - 2012-04-08 13:11 -0700
Re: How about helping optimization in language? Bernd Paysan <bernd.paysan@gmx.de> - 2012-04-08 23:40 +0200
Re: How about helping optimization in language? Paul Rubin <no.email@nospam.invalid> - 2012-04-08 15:14 -0700
Re: How about helping optimization in language? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-04-09 09:37 +0000
Re: How about helping optimization in language? Paul Rubin <no.email@nospam.invalid> - 2012-04-09 19:05 -0700
Re: How about helping optimization in language? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-04-10 10:32 +0000
Re: How about helping optimization in language? Bernd Paysan <bernd.paysan@gmx.de> - 2012-04-08 23:18 +0200
Re: How about helping optimization in language? Paul Rubin <no.email@nospam.invalid> - 2012-04-08 20:51 -0700
Re: How about helping optimization in language? "Elizabeth D. Rather" <erather@forth.com> - 2012-04-08 19:09 -1000
Re: How about helping optimization in language? Paul Rubin <no.email@nospam.invalid> - 2012-04-09 21:05 -0700
Re: How about helping optimization in language? "Elizabeth D. Rather" <erather@forth.com> - 2012-04-09 21:57 -1000
Re: How about helping optimization in language? Bernd Paysan <bernd.paysan@gmx.de> - 2012-04-09 17:42 +0200
Re: How about helping optimization in language? jacko <jackokring@gmail.com> - 2012-04-09 09:34 -0700
Re: How about helping optimization in language? Paul Rubin <no.email@nospam.invalid> - 2012-04-09 22:37 -0700
Re: How about helping optimization in language? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-04-10 09:39 +0000
Re: How about helping optimization in language? Paul Rubin <no.email@nospam.invalid> - 2012-04-10 03:12 -0700
Re: How about helping optimization in language? Bernd Paysan <bernd.paysan@gmx.de> - 2012-04-10 23:11 +0200
Re: How about helping optimization in language? Paul Rubin <no.email@nospam.invalid> - 2012-04-10 21:18 -0700
Re: How about helping optimization in language? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-04-11 10:00 +0000
Re: How about helping optimization in language? Bernd Paysan <bernd.paysan@gmx.de> - 2012-04-10 22:12 +0200
Re: How about helping optimization in language? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-04-10 16:24 -0500
Re: How about helping optimization in language? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-04-10 08:34 +0000
Re: How about helping optimization in language? John Passaniti <john.passaniti@gmail.com> - 2012-04-09 10:09 -0700
Re: How about helping optimization in language? Bernd Paysan <bernd.paysan@gmx.de> - 2012-04-09 21:21 +0200
Re: How about helping optimization in language? Paul Rubin <no.email@nospam.invalid> - 2012-04-09 19:02 -0700
Re: How about helping optimization in language? "Elizabeth D. Rather" <erather@forth.com> - 2012-04-09 16:44 -1000
Re: How about helping optimization in language? Paul Rubin <no.email@nospam.invalid> - 2012-04-09 20:00 -0700
Re: How about helping optimization in language? "Elizabeth D. Rather" <erather@forth.com> - 2012-04-09 17:27 -1000
Re: How about helping optimization in language? Paul Rubin <no.email@nospam.invalid> - 2012-04-09 20:49 -0700
Re: How about helping optimization in language? "Elizabeth D. Rather" <erather@forth.com> - 2012-04-09 18:12 -1000
Re: How about helping optimization in language? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-04-10 10:24 +0000
Re: How about helping optimization in language? Paul Rubin <no.email@nospam.invalid> - 2012-04-10 03:40 -0700
Re: How about helping optimization in language? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-04-10 04:39 -0500
Re: How about helping optimization in language? Paul Rubin <no.email@nospam.invalid> - 2012-04-10 03:05 -0700
Re: How about helping optimization in language? Coos Haak <chforth@hccnet.nl> - 2012-04-10 18:13 +0200
Re: How about helping optimization in language? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-04-10 12:02 -0500
Re: How about helping optimization in language? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-04-10 14:36 +0000
Re: How about helping optimization in language? Paul Rubin <no.email@nospam.invalid> - 2012-04-10 23:01 -0700
Re: How about helping optimization in language? Mark Wills <markrobertwills@yahoo.co.uk> - 2012-04-11 00:51 -0700
Re: How about helping optimization in language? "Elizabeth D. Rather" <erather@forth.com> - 2012-04-10 22:18 -1000
Re: How about helping optimization in language? Paul Rubin <no.email@nospam.invalid> - 2012-04-11 02:45 -0700
Re: How about helping optimization in language? "Paul E. Bennett" <Paul_E.Bennett@topmail.co.uk> - 2012-04-11 19:47 +0100
Complexity (was: How about helping optimization in language?) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-04-09 08:52 +0000
Re: Complexity (was: How about helping optimization in language?) Mark Wills <markrobertwills@yahoo.co.uk> - 2012-04-09 03:01 -0700
Re: Complexity Paul Rubin <no.email@nospam.invalid> - 2012-04-09 10:17 -0700
Re: Complexity "Elizabeth D. Rather" <erather@forth.com> - 2012-04-09 11:33 -1000
Re: Complexity "Elizabeth D. Rather" <erather@forth.com> - 2012-04-09 11:43 -1000
Re: Complexity (was: How about helping optimization in language?) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-04-10 07:31 +0000
Re: Complexity (was: How about helping optimization in language?) Bernd Paysan <bernd.paysan@gmx.de> - 2012-04-09 17:08 +0200
Re: Complexity "Elizabeth D. Rather" <erather@forth.com> - 2012-04-09 11:21 -1000
Re: Complexity Paul Rubin <no.email@nospam.invalid> - 2012-04-09 20:30 -0700
Re: Complexity "Elizabeth D. Rather" <erather@forth.com> - 2012-04-09 22:19 -1000
Re: Complexity Paul Rubin <no.email@nospam.invalid> - 2012-04-10 01:48 -0700
Re: Complexity Mark Wills <markrobertwills@yahoo.co.uk> - 2012-04-10 01:28 -0700
Re: Complexity "Elizabeth D. Rather" <erather@forth.com> - 2012-04-09 22:48 -1000
Re: Complexity Paul Rubin <no.email@nospam.invalid> - 2012-04-10 01:51 -0700
Re: Complexity Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-04-10 20:06 +0000
Re: How about helping optimization in language? stephenXXX@mpeforth.com (Stephen Pelc) - 2012-04-09 10:24 +0000
Re: How about helping optimization in language? Nomen Nescio <nobody@dizum.com> - 2012-04-09 16:18 +0200
Re: How about helping optimization in language? Mark Wills <markrobertwills@yahoo.co.uk> - 2012-04-09 07:23 -0700
Re: How about helping optimization in language? stephenXXX@mpeforth.com (Stephen Pelc) - 2012-04-09 15:27 +0000
Re: How about helping optimization in language? BruceMcF <agila61@netscape.net> - 2012-04-04 06:51 -0700
Re: How about helping optimization in language? stephenXXX@mpeforth.com (Stephen Pelc) - 2012-04-03 09:06 +0000
Re: How about helping optimization in language? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-04-03 16:13 +0000
Re: How about helping optimization in language? Paul Rubin <no.email@nospam.invalid> - 2012-04-03 12:43 -0700
Re: How about helping optimization in language? "Elizabeth D. Rather" <erather@forth.com> - 2012-04-03 10:16 -1000
Re: How about helping optimization in language? Paul Rubin <no.email@nospam.invalid> - 2012-04-03 13:41 -0700
Re: How about helping optimization in language? "Elizabeth D. Rather" <erather@forth.com> - 2012-04-03 11:01 -1000
Re: How about helping optimization in language? Paul Rubin <no.email@nospam.invalid> - 2012-04-03 22:42 -0700
Re: How about helping optimization in language? "Elizabeth D. Rather" <erather@forth.com> - 2012-04-03 21:11 -1000
Re: How about helping optimization in language? Paul Rubin <no.email@nospam.invalid> - 2012-04-04 01:02 -0700
Re: How about helping optimization in language? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-04-04 05:35 -0500
Re: How about helping optimization in language? Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-04-04 15:01 +0000
Re: How about helping optimization in language? Paul Rubin <no.email@nospam.invalid> - 2012-04-06 00:08 -0700
Re: How about helping optimization in language? Jan Coombs <jan_2011-02@murray-microft.co.uk> - 2012-04-06 12:05 +0100
Re: How about helping optimization in language? Alex McDonald <blog@rivadpm.com> - 2012-04-03 15:56 -0700
Re: How about helping optimization in language? Bernd Paysan <bernd.paysan@gmx.de> - 2012-04-03 22:06 +0200
Re: How about helping optimization in language? Paul Rubin <no.email@nospam.invalid> - 2012-04-03 13:22 -0700
Re: How about helping optimization in language? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-04-04 05:43 -0500
Re: How about helping optimization in language? Bernd Paysan <bernd.paysan@gmx.de> - 2012-04-04 23:15 +0200
Re: How about helping optimization in language? Paul Rubin <no.email@nospam.invalid> - 2012-04-04 19:02 -0700
Re: How about helping optimization in language? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-04-04 13:34 +0000
Re: How about helping optimization in language? stephenXXX@mpeforth.com (Stephen Pelc) - 2012-04-02 09:49 +0000
Re: How about helping optimization in language? Paul Rubin <no.email@nospam.invalid> - 2012-04-02 20:04 -0700
Re: How about helping optimization in language? stephenXXX@mpeforth.com (Stephen Pelc) - 2012-04-03 09:30 +0000
Re: How about helping optimization in language? Paul Rubin <no.email@nospam.invalid> - 2012-04-03 13:16 -0700
Re: How about helping optimization in language? Bernd Paysan <bernd.paysan@gmx.de> - 2012-04-03 22:45 +0200
Re: How about helping optimization in language? Paul Rubin <no.email@nospam.invalid> - 2012-04-03 23:26 -0700
Re: How about helping optimization in language? "Elizabeth D. Rather" <erather@forth.com> - 2012-04-03 21:29 -1000
Re: How about helping optimization in language? Paul Rubin <no.email@nospam.invalid> - 2012-04-04 02:32 -0700
Re: How about helping optimization in language? "Elizabeth D. Rather" <erather@forth.com> - 2012-04-04 07:30 -1000
Re: How about helping optimization in language? John Passaniti <john.passaniti@gmail.com> - 2012-04-04 08:51 -0700
Re: How about helping optimization in language? "Elizabeth D. Rather" <erather@forth.com> - 2012-04-04 10:31 -1000
Re: How about helping optimization in language? Paul Rubin <no.email@nospam.invalid> - 2012-04-07 21:20 -0700
Re: How about helping optimization in language? "Elizabeth D. Rather" <erather@forth.com> - 2012-04-07 19:18 -1000
Re: How about helping optimization in language? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-04-08 15:59 +0000
Re: How about helping optimization in language? Paul Rubin <no.email@nospam.invalid> - 2012-04-08 22:12 -0700
Re: How about helping optimization in language? "Elizabeth D. Rather" <erather@forth.com> - 2012-04-08 19:42 -1000
Re: How about helping optimization in language? Paul Rubin <no.email@nospam.invalid> - 2012-04-08 23:26 -0700
Re: How about helping optimization in language? "Elizabeth D. Rather" <erather@forth.com> - 2012-04-08 20:37 -1000
Re: How about helping optimization in language? Fritz Wuehler <fritz@spamexpire-201204.rodent.frell.theremailer.net> - 2012-04-09 23:33 +0200
Re: How about helping optimization in language? "Elizabeth D. Rather" <erather@forth.com> - 2012-04-09 11:52 -1000
Re: How about helping optimization in language? Paul Rubin <no.email@nospam.invalid> - 2012-04-09 18:42 -0700
Re: How about helping optimization in language? "Elizabeth D. Rather" <erather@forth.com> - 2012-04-09 15:57 -1000
Re: How about helping optimization in language? Paul Rubin <no.email@nospam.invalid> - 2012-04-09 19:08 -0700
Re: How about helping optimization in language? "Elizabeth D. Rather" <erather@forth.com> - 2012-04-09 16:29 -1000
Re: How about helping optimization in language? Paul Rubin <no.email@nospam.invalid> - 2012-04-09 19:53 -0700
Re: How about helping optimization in language? "Elizabeth D. Rather" <erather@forth.com> - 2012-04-09 17:05 -1000
Re: How about helping optimization in language? Paul Rubin <no.email@nospam.invalid> - 2012-04-09 20:15 -0700
Re: How about helping optimization in language? Bernd Paysan <bernd.paysan@gmx.de> - 2012-04-10 21:46 +0200
Re: How about helping optimization in language? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-04-10 10:42 +0000
Re: How about helping optimization in language? Paul Rubin <no.email@nospam.invalid> - 2012-04-11 21:26 -0700
Re: How about helping optimization in language? Mark Wills <markrobertwills@yahoo.co.uk> - 2012-04-12 00:24 -0700
Re: How about helping optimization in language? Paul Rubin <no.email@nospam.invalid> - 2012-04-12 01:55 -0700
Re: How about helping optimization in language? stephenXXX@mpeforth.com (Stephen Pelc) - 2012-04-03 22:06 +0000
Re: How about helping optimization in language? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-04-04 13:20 +0000
Re: How about helping optimization in language? stephenXXX@mpeforth.com (Stephen Pelc) - 2012-04-04 21:18 +0000
Re: How about helping optimization in language? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-04-05 15:36 +0000
Re: How about helping optimization in language? stephenXXX@mpeforth.com (Stephen Pelc) - 2012-04-05 18:32 +0000
Re: How about helping optimization in language? kenney@cix.compulink.co.uk - 2012-04-04 04:39 -0500
Re: How about helping optimization in language? Paul Rubin <no.email@nospam.invalid> - 2012-04-04 02:50 -0700
Re: How about helping optimization in language? BruceMcF <agila61@netscape.net> - 2012-04-03 18:07 -0700
Re: How about helping optimization in language? Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-04-05 11:10 +0000
Re: How about helping optimization in language? BruceMcF <agila61@netscape.net> - 2012-04-05 13:21 -0700
Re: How about helping optimization in language? Bernd Paysan <bernd.paysan@gmx.de> - 2012-04-05 23:26 +0200
Re: How about helping optimization in language? Mark Wills <markrobertwills@yahoo.co.uk> - 2012-04-05 14:49 -0700
Re: How about helping optimization in language? Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2012-04-06 08:58 +0100
Re: How about helping optimization in language? Bernd Paysan <bernd.paysan@gmx.de> - 2012-04-06 19:07 +0200
Re: How about helping optimization in language? Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2012-04-07 10:07 +0100
Re: How about helping optimization in language? Bernd Paysan <bernd.paysan@gmx.de> - 2012-04-07 21:18 +0200
Re: How about helping optimization in language? BruceMcF <agila61@netscape.net> - 2012-04-08 07:36 -0700
Re: How about helping optimization in language? jacko <jackokring@gmail.com> - 2012-04-08 07:56 -0700
Re: How about helping optimization in language? jacko <jackokring@gmail.com> - 2012-04-08 07:49 -0700
Re: How about helping optimization in language? Bernd Paysan <bernd.paysan@gmx.de> - 2012-03-28 22:06 +0200
Re: How about helping optimization in language? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-03-31 13:38 +0000
Re: How about helping optimization in language? Bernd Paysan <bernd.paysan@gmx.de> - 2012-04-02 02:10 +0200
Re: How about helping optimization in language? Paul Rubin <no.email@nospam.invalid> - 2012-04-01 22:32 -0700
Re: How about helping optimization in language? "A. K." <akk@nospam.org> - 2012-04-02 09:40 +0200
Re: How about helping optimization in language? "Elizabeth D. Rather" <erather@forth.com> - 2012-04-01 21:44 -1000
Re: How about helping optimization in language? Paul Rubin <no.email@nospam.invalid> - 2012-04-02 01:08 -0700
Re: How about helping optimization in language? "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-04-02 06:47 -0400
Re: How about helping optimization in language? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-04-02 14:38 +0000
Re: How about helping optimization in language? Elizabeth D Rather <erather@forth.com> - 2012-03-28 15:08 -1000
Re: How about helping optimization in language? Gary Bergstrom <g.bergstrom@ieee.org> - 2012-03-28 10:15 -0700
Re: How about helping optimization in language? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-03-28 12:00 -0500
Re: How about helping optimization in language? hwfwguy@gmail.com - 2012-03-29 08:52 -0700
Re: How about helping optimization in language? John Passaniti <john.passaniti@gmail.com> - 2012-03-29 09:33 -0700
Re: How about helping optimization in language? Helmar Wodtke <helmwo@gmail.com> - 2012-03-29 09:44 -0700
Re: How about helping optimization in language? hwfwguy@gmail.com - 2012-03-29 20:59 -0700
Re: How about helping optimization in language? jacko <jackokring@gmail.com> - 2012-03-30 06:09 -0700
Re: How about helping optimization in language? Helmar Wodtke <helmwo@gmail.com> - 2012-03-27 11:48 -0700
Re: How about helping optimization in language? "Elizabeth D. Rather" <erather@forth.com> - 2012-03-27 12:35 -1000
Re: How about helping optimization in language? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-03-28 03:02 -0500
Re: How about helping optimization in language? Helmar Wodtke <helmwo@gmail.com> - 2012-03-28 05:03 -0700
Re: How about helping optimization in language? BruceMcF <agila61@netscape.net> - 2012-03-28 20:17 -0700
Re: How about helping optimization in language? BruceMcF <agila61@netscape.net> - 2012-03-29 11:43 -0700
Re: How about helping optimization in language? Pablo Hugo Reda <pabloreda@gmail.com> - 2012-03-27 12:22 -0700
Re: How about helping optimization in language? Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-03-28 03:24 -0700
Re: How about helping optimization in language? jacko <jackokring@gmail.com> - 2012-04-08 21:56 -0700
Page 5 of 11 — ← Prev page 1 … 3 4 [5] 6 7 … 11 Next page →
| From | Coos Haak <chforth@hccnet.nl> |
|---|---|
| Date | 2012-04-10 18:13 +0200 |
| Message-ID | <1id7cgxwqo2um$.1i3zeismuc086$.dlg@40tude.net> |
| In reply to | #11099 |
Op Tue, 10 Apr 2012 03:05:56 -0700 schreef Paul Rubin: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >> I think that's what people have been saying is a problem. The point >> people have tried to make is that there is nothing funny going on >> with the types in >> >> 'A' 2 + > If I didn't have the word BETWEEN (as it is not standard), and had to check if a character was upper case, I would write 'A' 'Z' 1+ WITHIN ( char -- flag ) without ever looking back. > What about 'A' 2 * ? Could be used by someone using a 16 bit implementation (me?) and a lookup table. > > I would say there is something funny going on with the types and that an > alert is appropriate. How often does such a fragment occur anyway? > Writing a cast for it seems fine. Characters are a subtype of numbers, no cast necessary. -- Coos CHForth, 16 bit DOS applications http://home.hccnet.nl/j.j.haak/forth.html
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2012-04-10 12:02 -0500 |
| Message-ID | <MaKdnZOzpYkT-hnSnZ2dnUVZ_s2dnZ2d@supernews.com> |
| In reply to | #11099 |
Paul Rubin <no.email@nospam.invalid> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >> I think that's what people have been saying is a problem. The point >> people have tried to make is that there is nothing funny going on >> with the types in >> >> 'A' 2 + > > What about 'A' 2 * ? It doesn't make much sense. > I would say there is something funny going on with the types and > that an alert is appropriate. I don't think so: there is an error, but it has little to do with types. This is more akin to multiplying a mass by a velocity and expecting a momentum; the fact that both are floats doesn't tell you much. > How often does such a fragment occur anyway? Writing a cast for it > seems fine. Use of the passive voice noted. :-) Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2012-04-10 14:36 +0000 |
| Message-ID | <2012Apr10.163607@mips.complang.tuwien.ac.at> |
| In reply to | #11046 |
John Passaniti <john.passaniti@gmail.com> writes:
>Except in some insane case, this code is likely an error:
>
>: *pi 3.1415e0 f* ;
>2 *pi type
Depends on what is on the stacks when you start it.
Let's put something on the stacks first:
s" bla" drop 2e
Now run your "erroneous" code:
: *pi 3.1415e0 f* ;
2 *pi type
and I get the output:
bl
OTOH, if you meant your code to be run on an empty stack, let's see
what happens:
: *pi 3.1415e0 f* ; ok
2 *pi type
:2: Floating-point stack underflow
2 >>>*pi<<< type
Backtrace:
$7FFFF6A44330 f*
I don't see that compile-time type checking would provide any benefit.
>But that doesn't mean there isn't value in a tool that could
>look at code like this and report back to the programmer information
>they may have missed in testing.
Whatever the error is supposed to be in the code above, how could they
miss this in testing?
>There seems to be this worry that if we make the compiler smarter-- or
>if we provide tools that can analyze code, then lazy/bad/clueless
>programmers won't do testing. They'll just rely on the absence of
>warnings and errors as an indication of the quality of their code.
>Yep. But why are we worrying about this population? Let's instead
>worry about the good programmers who occasionally reveal their human
>side by making mistakes.
Maybe we should worry about programmers who reveal their human side by
being lazy and slacking on the tests when the compiler does such a
superb job; especially when they have deadlines looming and have
already spent considerable time figuring out what the compiler
complained about. Humans fall prey to risk compensation. You may
prefer to ignore them and worry about superhuman programmers, but not
everybody does.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2011: http://www.euroforth.org/ef11/
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2012-04-10 23:01 -0700 |
| Message-ID | <7xr4vu4xjd.fsf@ruckus.brouhaha.com> |
| In reply to | #11111 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: >>: *pi 3.1415e0 f* ; >>2 *pi type > I don't see that compile-time type checking would provide any benefit.... > Whatever the error is supposed to be in the code above, I think John imagined someone wanting to compute 2*3.1415=6.2830, but accidentally wroting "2 *pi type" instead of "2e *pi f.". With a unified int/float stack, that's multiplying an int by a float, and the compiler could flag the type error or do an automatic conversion. With separate int/float stacks, it means the surrounding word has a different stack effect than intended, and the stack comment will be wrong, another type error that the compiler could notice and flag. I wrote 2 instead of 2e many times when I first started using floats in Forth, so I'd consider that an easy error to make. > how could they miss this in testing? Even if they don't miss it in testing, they see the test fail and have to debug the error, which is time consuming compared to having the compiler just point at the problem. In subtler cases of course they can very well miss things in testing. > Maybe we should worry about programmers who reveal their human side by > being lazy and slacking on the tests when the compiler does such a > superb job; especially when they have deadlines looming and have > already spent considerable time figuring out what the compiler > complained about. Humans fall prey to risk compensation. You may > prefer to ignore them and worry about superhuman programmers, but not > everybody does. We could go further and worry about lazy programmers who rely on testing a necessarily infinitesimal sample of the possible input space, instead of mathematically proving that the program does the specified thing for the entire input space. Every Microsoft program is extensively tested before they ship it, yet we still see CERT notices about critical security bugs in them every day, because someone thought up a devious input that got past the tests. Conventional typechecking does of course prove theorems about the programs, though the theorems are usually rather weak. In reality, places like NASA and other safety-critical users use formal verification because they have to, and simply accept its enormous impact on their schedules and budgets, since it eliminates an epsilon of risk that can't be gotten rid of any other way. Other places based on implicit risk-benefit assessment use a combination of testing and (in some cases) some limited theorem-proving such as typechecking, to get the code reliable enough for their purposes. They accept some additional risk of bugs in exchange for getting development costs much smaller than NASA's, since (for their type of product) the consequence of a program bug is smaller than it is for NASA. Risk compensation like that is perfectly normal and accepted part of development. At issue is whether the benefit of typechecking outweighs its costs (programmer preference of course figuring into that calculation, since it will affect their methods etc). That it might do so shouldn't be treated as a silly proposition.
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markrobertwills@yahoo.co.uk> |
|---|---|
| Date | 2012-04-11 00:51 -0700 |
| Message-ID | <ba561f80-4dca-4b9d-90c6-75fe04712000@w17g2000yqe.googlegroups.com> |
| In reply to | #11137 |
On Apr 11, 7:01 am, Paul Rubin <no.em...@nospam.invalid> wrote: > an...@mips.complang.tuwien.ac.at (Anton Ertl) writes: > >>: *pi 3.1415e0 f* ; > >>2 *pi type > > I don't see that compile-time type checking would provide any benefit.... > > Whatever the error is supposed to be in the code above, > > I think John imagined someone wanting to compute 2*3.1415=6.2830, but > accidentally wroting "2 *pi type" instead of "2e *pi f.". With a > unified int/float stack, that's multiplying an int by a float, and the > compiler could flag the type error or do an automatic conversion. With > separate int/float stacks, it means the surrounding word has a different > stack effect than intended, and the stack comment will be wrong, another > type error that the compiler could notice and flag. I wrote 2 instead > of 2e many times when I first started using floats in Forth, so I'd > consider that an easy error to make. > > > how could they miss this in testing? > > Even if they don't miss it in testing, they see the test fail and have > to debug the error, which is time consuming compared to having the > compiler just point at the problem. In subtler cases of course they can > very well miss things in testing. > > > Maybe we should worry about programmers who reveal their human side by > > being lazy and slacking on the tests when the compiler does such a > > superb job; especially when they have deadlines looming and have > > already spent considerable time figuring out what the compiler > > complained about. Humans fall prey to risk compensation. You may > > prefer to ignore them and worry about superhuman programmers, but not > > everybody does. > > We could go further and worry about lazy programmers who rely on testing > a necessarily infinitesimal sample of the possible input space, instead > of mathematically proving that the program does the specified thing for > the entire input space. Every Microsoft program is extensively tested > before they ship it, yet we still see CERT notices about critical > security bugs in them every day, because someone thought up a devious > input that got past the tests. Conventional typechecking does of course > prove theorems about the programs, though the theorems are usually > rather weak. > > In reality, places like NASA and other safety-critical users use formal > verification because they have to, and simply accept its enormous impact > on their schedules and budgets, since it eliminates an epsilon of risk > that can't be gotten rid of any other way. Other places based on > implicit risk-benefit assessment use a combination of testing and (in > some cases) some limited theorem-proving such as typechecking, to get > the code reliable enough for their purposes. They accept some > additional risk of bugs in exchange for getting development costs much > smaller than NASA's, since (for their type of product) the consequence > of a program bug is smaller than it is for NASA. Risk compensation like > that is perfectly normal and accepted part of development. At issue is > whether the benefit of typechecking outweighs its costs (programmer > preference of course figuring into that calculation, since it will > affect their methods etc). That it might do so shouldn't be treated as > a silly proposition. Yet NASA, as a case in point, has a long history with Forth - a classic untyped language, not far above assembler ;-)
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2012-04-10 22:18 -1000 |
| Message-ID | <ktOdnWPavdbFoxjSnZ2dnUVZ_judnZ2d@supernews.com> |
| In reply to | #11138 |
On 4/10/12 9:51 PM, Mark Wills wrote: > On Apr 11, 7:01�am, Paul Rubin<no.em...@nospam.invalid> wrote: ... >> In reality, places like NASA and other safety-critical users use formal >> verification because they have to, and simply accept its enormous impact >> on their schedules and budgets, since it eliminates an epsilon of risk >> that can't be gotten rid of any other way. Other places based on >> implicit risk-benefit assessment use a combination of testing and (in >> some cases) some limited theorem-proving such as typechecking, to get >> the code reliable enough for their purposes. They accept some >> additional risk of bugs in exchange for getting development costs much >> smaller than NASA's, since (for their type of product) the consequence >> of a program bug is smaller than it is for NASA. Risk compensation like >> that is perfectly normal and accepted part of development. At issue is >> whether the benefit of typechecking outweighs its costs (programmer >> preference of course figuring into that calculation, since it will >> affect their methods etc). That it might do so shouldn't be treated as >> a silly proposition. > > Yet NASA, as a case in point, has a long history with Forth - a > classic untyped language, not far above assembler ;-) And it's flown in a number of satellites and spacecraft. Paul Bennett, who posts here from time to time, is in the business of safety-critical software, and wrote this paper on the subject in the late 90's: www.complang.tuwien.ac.at/anton/euroforth/ef98/bugleretal98.pdf Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2012-04-11 02:45 -0700 |
| Message-ID | <7xty0qsiu2.fsf@ruckus.brouhaha.com> |
| In reply to | #11139 |
"Elizabeth D. Rather" <erather@forth.com> writes: >> Yet NASA, as a case in point, has a long history with Forth - a > And it's flown in a number of satellites and spacecraft. Paul > Bennett,... Heh, yeah, I'd forgotten about NASA as a historically important Forth user. I wonder if they still do anything in Forth. I had been thinking of an article I saw a while back, about the Space Shuttle software, which is written in Ada and uses a lot of static analysis tools. Of course I'm aware of Paul Bennett and mentioned him further up in this thread, and was thinking of him a little when I wrote that post about NASA. He compares Forth to assembly language in terms of the inspection level needed, and and certifies Forth words with a manual, multi-person code review process that has to be done by experts. I guess it generates the confidence levels that he requires, and may have various flexibility or other advantages over machine verification. But I have to think that at least, running a program has to be more repeatable than any type of careful process involving humans.
[toc] | [prev] | [next] | [standalone]
| From | "Paul E. Bennett" <Paul_E.Bennett@topmail.co.uk> |
|---|---|
| Date | 2012-04-11 19:47 +0100 |
| Message-ID | <9um21bFbviU1@mid.individual.net> |
| In reply to | #11144 |
Paul Rubin wrote: > "Elizabeth D. Rather" <erather@forth.com> writes: >>> Yet NASA, as a case in point, has a long history with Forth - a >> And it's flown in a number of satellites and spacecraft. Paul >> Bennett,... > > Heh, yeah, I'd forgotten about NASA as a historically important Forth > user. I wonder if they still do anything in Forth. I had been thinking > of an article I saw a while back, about the Space Shuttle software, > which is written in Ada and uses a lot of static analysis tools. > > Of course I'm aware of Paul Bennett and mentioned him further up in this > thread, and was thinking of him a little when I wrote that post about > NASA. He compares Forth to assembly language in terms of the inspection > level needed, and and certifies Forth words with a manual, multi-person > code review process that has to be done by experts. I guess it > generates the confidence levels that he requires, and may have various > flexibility or other advantages over machine verification. But I have > to think that at least, running a program has to be more repeatable than > any type of careful process involving humans. Automated verification can only check against a set of rules that have to be codified to provide a yes/no type result. Great for some checking but still not as good as a well trained human eye. My checking process is applied on a word by word basis and uses the glossary definition (which is written and reviewed before the code portion) to check the code for layout against the coding standard in use, proper functioning as evidenced to Fagan Inspection, proper function when run, and proper behaviour in stressed circumstances. Any reasonable Forth programmer could be taught how to do this level of inspection and testing. Coupling the inspection and test regime to a decent versioning repository and change tracking system will assist in producing high quality, robust software. -- ******************************************************************** Paul E. Bennett...............<email://Paul_E.Bennett@topmail.co.uk> Forth based HIDECS Consultancy Mob: +44 (0)7811-639972 Tel: +44 (0)1235-510979 Going Forth Safely ..... EBA. www.electric-boat-association.org.uk.. ********************************************************************
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2012-04-09 08:52 +0000 |
| Subject | Complexity (was: How about helping optimization in language?) |
| Message-ID | <2012Apr9.105255@mips.complang.tuwien.ac.at> |
| In reply to | #11003 |
Bernd Paysan <bernd.paysan@gmx.de> writes:
>If you find that most Forth programs have been written by small teams or
>just one person: Don't look at the number of lines, look at the
>functionality achieved. It is not economic to deploy a huge team if you
>can do with a lot less people. So why would anybody do if he can solve
>the problem without?
That relates to the story posted a few days ago in another thread.
The author (Allen) thought that in the end the time for Forth had
passed (as I interpret it, for his (and Chuck Moore's) way of using
Forth), because it was not viable for teams.
Which leaves two questions:
* Are there problems that we cannot simplify enough to be attacked by
one person?
* Is there a way to make it viable for teams while still keeping most
of the strengths?
We work on Gforth as a team, but mostly by dividing it into subsystems
that are mostly worked on by just one person.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2011: http://www.euroforth.org/ef11/
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markrobertwills@yahoo.co.uk> |
|---|---|
| Date | 2012-04-09 03:01 -0700 |
| Subject | Re: Complexity (was: How about helping optimization in language?) |
| Message-ID | <8562dd4e-5a5e-463e-b2e0-ee2a44226bcc@y13g2000yqj.googlegroups.com> |
| In reply to | #11025 |
On Apr 9, 9:52 am, an...@mips.complang.tuwien.ac.at (Anton Ertl) wrote: > Bernd Paysan <bernd.pay...@gmx.de> writes: > >If you find that most Forth programs have been written by small teams or > >just one person: Don't look at the number of lines, look at the > >functionality achieved. It is not economic to deploy a huge team if you > >can do with a lot less people. So why would anybody do if he can solve > >the problem without? > > That relates to the story posted a few days ago in another thread. > The author (Allen) thought that in the end the time for Forth had > passed (as I interpret it, for his (and Chuck Moore's) way of using > Forth), because it was not viable for teams. > > Which leaves two questions: > > * Are there problems that we cannot simplify enough to be attacked by > one person? > > * Is there a way to make it viable for teams while still keeping most > of the strengths? > > We work on Gforth as a team, but mostly by dividing it into subsystems > that are mostly worked on by just one person. > > - anton > -- > M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html > comp.lang.forth FAQs:http://www.complang.tuwien.ac.at/forth/faq/toc.html > New standard:http://www.forth200x.org/forth200x.html > EuroForth 2011:http://www.euroforth.org/ef11/ I've been thinking about this, both in terms of teams working on the 'classic' style blocks based systems, and teams working with a modern file based system. Basically, I just can't see where the problem is in either approach. Let's take a team of programmers working on a file based system. In this scenario, the issues are *exactly* the same as a team working in just about any contemporary language you care to mention. All that is needed is some sort of check-in/check-out version control system, ala Source Safe which has been around for years. Basically, what I'm saying is: It's unfair to say that file based Forth isn't viable in a team scenario, since the issues are the same with any other language. So, what about a classic block based system? Well, I wasn't around in those days, but I imagine one scenario would be to have a bunch of low spec VAXes or whatever used as essentially dumb VT100 terminals, connected to a big VAX in the corner, running multiple terminal instances. The issue here could be that two engineers could potentially work on the same block at the same time. So, the last to commit wins. However, I still don't see this as a major problem. It would be no more complicated than redefining BLOCK to implement a lock- based system. I don't see that as complicated. A slightly more complex issue might be versioning. But even here, multiple block files can be kept, and when FLUSH executes to write a block back to the main block volume, it can first write the old block to a backup block volume. This could cascade across multiple volumes, allowing 3 or 4 verions of the same block to be kept. I can imagine the these problems would solved in about half an hour, by just re-defining a couple of words like EDIT, BLOCK and FLUSH. No $10,000 version control system (plus SQL server et al!) required. No. I just don't see where the big problem is.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2012-04-09 10:17 -0700 |
| Subject | Re: Complexity |
| Message-ID | <7xk41odduc.fsf@ruckus.brouhaha.com> |
| In reply to | #11029 |
Mark Wills <markrobertwills@yahoo.co.uk> writes: > Let's take a team of programmers working on a file based system. In > this scenario, the issues are *exactly* the same as a team working in > just about any contemporary language you care to mention. All that is > needed is some sort of check-in/check-out version control system, ala > Source Safe which has been around for years. You probably also want: 1. Bug tracking system 2. Build scripts (so you can go all the way from your source repo to a downloadable image for your embedded whatsit in one step) 3. Unit test framework 4. Integration test / CI framework 5. Dynamic test generators 6. static analysis tools 7. Documentation tools / tracker Fossil (fossil-scm.org) is a lightweight tool that might be enough for source control, bug tracking, and internal docs. I'm not sure what to suggest for the other stuff.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2012-04-09 11:33 -1000 |
| Subject | Re: Complexity |
| Message-ID | <TIOdnXq-oecMyB7SnZ2dnUVZ_uKdnZ2d@supernews.com> |
| In reply to | #11029 |
On 4/9/12 12:01 AM, Mark Wills wrote: > On Apr 9, 9:52 am, an...@mips.complang.tuwien.ac.at (Anton Ertl) > wrote: >> Bernd Paysan<bernd.pay...@gmx.de> writes: >>> If you find that most Forth programs have been written by small teams or >>> just one person: Don't look at the number of lines, look at the >>> functionality achieved. It is not economic to deploy a huge team if you >>> can do with a lot less people. So why would anybody do if he can solve >>> the problem without? >> >> That relates to the story posted a few days ago in another thread. >> The author (Allen) thought that in the end the time for Forth had >> passed (as I interpret it, for his (and Chuck Moore's) way of using >> Forth), because it was not viable for teams. >> >> Which leaves two questions: >> >> * Are there problems that we cannot simplify enough to be attacked by >> one person? >> >> * Is there a way to make it viable for teams while still keeping most >> of the strengths? >> >> We work on Gforth as a team, but mostly by dividing it into subsystems >> that are mostly worked on by just one person. >> >> - anton >> -- >> M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html >> comp.lang.forth FAQs:http://www.complang.tuwien.ac.at/forth/faq/toc.html >> New standard:http://www.forth200x.org/forth200x.html >> EuroForth 2011:http://www.euroforth.org/ef11/ > > I've been thinking about this, both in terms of teams working on the > 'classic' style blocks based systems, and teams working with a modern > file based system. > > Basically, I just can't see where the problem is in either approach. > > Let's take a team of programmers working on a file based system. In > this scenario, the issues are *exactly* the same as a team working in > just about any contemporary language you care to mention. All that is > needed is some sort of check-in/check-out version control system, ala > Source Safe which has been around for years. > > Basically, what I'm saying is: It's unfair to say that file based > Forth isn't viable in a team scenario, since the issues are the same > with any other language. Yep. > So, what about a classic block based system? Well, I wasn't around in > those days, but I imagine one scenario would be to have a bunch of low > spec VAXes or whatever used as essentially dumb VT100 terminals, > connected to a big VAX in the corner, running multiple terminal > instances. The issue here could be that two engineers could > potentially work on the same block at the same time. So, the last to > commit wins. However, I still don't see this as a major problem. It > would be no more complicated than redefining BLOCK to implement a lock- > based system. I don't see that as complicated. A slightly more complex > issue might be versioning. But even here, multiple block files can be > kept, and when FLUSH executes to write a block back to the main block > volume, it can first write the old block to a backup block volume. > This could cascade across multiple volumes, allowing 3 or 4 verions of > the same block to be kept. Well, VAXes are required, thank goodness! I have worked on, and managed, team projects on block-based Forths on PDP-11's, various microcontrollers (in the late 70's and early 80's each had its own "development system" hardware), and bunches of PCs. A central repository for blocks is helpful, but then you assign your team members their own range of blocks to work in. By adding a block OFFSET to raw block#s, you can create the illusion that you're working on the same block space as your colleague without actual interference. > I can imagine the these problems would solved in about half an hour, > by just re-defining a couple of words like EDIT, BLOCK and FLUSH. No > $10,000 version control system (plus SQL server et al!) required. We did, actually, develop our own integration utility (somewhat similar to Beyond Compare) that facilitated comparing pairs of blocks, highlighting the differences and allowing the user to select one or the other, or control the merging. It took longer than half an hour, but wasn't a huge project. It was helpful in many team projects. > No. I just don't see where the big problem is. None, providing you have good management and programmers with a professional attitude. If you don't have those things, your project is in trouble regardless of language. Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2012-04-09 11:43 -1000 |
| Subject | Re: Complexity |
| Message-ID | <aaWdnYxSM4CPxR7SnZ2dnUVZ_jqdnZ2d@supernews.com> |
| In reply to | #11059 |
On 4/9/12 11:33 AM, Elizabeth D. Rather wrote: ... > Well, VAXes are required, thank goodness! Oops! VAXes *aren't* required, thank goodness! Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2012-04-10 07:31 +0000 |
| Subject | Re: Complexity (was: How about helping optimization in language?) |
| Message-ID | <2012Apr10.093158@mips.complang.tuwien.ac.at> |
| In reply to | #11029 |
Mark Wills <markrobertwills@yahoo.co.uk> writes:
>I've been thinking about this, both in terms of teams working on the
>'classic' style blocks based systems, and teams working with a modern
>file based system.
Sorry for not clearly expressing myself. The issue I am talking about
is not how to deal with the source code.
The issue is the advantages you get from having the complete problem,
the complete current code for the program, as well as the complete
Forth system in your head. this allows you to find solutions that you
otherwise wouldn't have thought of.
As soon as things become so big that they don't fit in one head, you
lose some of that. The question is how you can keep most of the
advantages. A classic answer was to avoid letting things become that
big.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2011: http://www.euroforth.org/ef11/
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2012-04-09 17:08 +0200 |
| Subject | Re: Complexity (was: How about helping optimization in language?) |
| Message-ID | <jluu18$dhd$1@online.de> |
| In reply to | #11025 |
Anton Ertl wrote: > We work on Gforth as a team, but mostly by dividing it into subsystems > that are mostly worked on by just one person. But this is classical teamwork - dividing the job, and have one person working on one part of it. I don't care about what mismanagement thinks teamwork should look like. If the assertion is that Forth can't be used in a team of replacible idiots who all tread on their feets by working on the same problem at the same time, then yes, this is probably true. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2012-04-09 11:21 -1000 |
| Subject | Re: Complexity |
| Message-ID | <gfCdnQmI374gzx7SnZ2dnUVZ_sydnZ2d@supernews.com> |
| In reply to | #11025 |
On 4/8/12 10:52 PM, Anton Ertl wrote: > Bernd Paysan<bernd.paysan@gmx.de> writes: >> If you find that most Forth programs have been written by small teams or >> just one person: Don't look at the number of lines, look at the >> functionality achieved. It is not economic to deploy a huge team if you >> can do with a lot less people. So why would anybody do if he can solve >> the problem without? > > That relates to the story posted a few days ago in another thread. > The author (Allen) thought that in the end the time for Forth had > passed (as I interpret it, for his (and Chuck Moore's) way of using > Forth), because it was not viable for teams. > > Which leaves two questions: > > * Are there problems that we cannot simplify enough to be attacked by > one person? Yes, certainly. > * Is there a way to make it viable for teams while still keeping most > of the strengths? Yes, certainly. > We work on Gforth as a team, but mostly by dividing it into subsystems > that are mostly worked on by just one person. Exactly. All good project management works that way. There may be several layers before you get to one-programmer job assignments, but the basic process of analysis and factoring of the task is the same regardless of language. The only differences that characterize a Forth project are: a) At the "one programmer" level that programmer can do more, more quickly, using Forth. b) Because of a), it is much more important to establish clear interfaces between assigned modules, maintain good discipline as regards coding style and documentation, and maintain close communication between the team members. There have been a few well-publicized failures of Forth team projects. All of them that I know of have neglected b). Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2012-04-09 20:30 -0700 |
| Subject | Re: Complexity |
| Message-ID | <7x62d8w9ff.fsf@ruckus.brouhaha.com> |
| In reply to | #11025 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: > * Are there problems that we cannot simplify enough to be attacked by > one person? I'm used to that happening whenever there's a big system with a lot of change requests coming in. For example, I imagine CCS having to respond every time a tax code changes someplace, or some user has to deal with a new payroll service, or whatever. You end up using a bug tracker as a task queue, with individual programmers acting as "worker threads". > * Is there a way to make it viable for teams while still keeping most > of the strengths? One trendy thing I see in Python similar these days is extensive use of test automation. In some approaches you're supposed to write a test for every new feature before you even implement the feature. You run the whole test suite every time you change something. Whenever you fix a bug, you write a test and save it. The repeated testing catches all sorts of problems early. I'd think Forth needs this even more than Python does, but I don't hear about it much on this newsgroup.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2012-04-09 22:19 -1000 |
| Subject | Re: Complexity |
| Message-ID | <-IWdnRjXKa-bcB7SnZ2dnUVZ_oadnZ2d@supernews.com> |
| In reply to | #11083 |
On 4/9/12 5:30 PM, Paul Rubin wrote: > anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: >> * Are there problems that we cannot simplify enough to be attacked by >> one person? > > I'm used to that happening whenever there's a big system with a lot of > change requests coming in. For example, I imagine CCS having to respond > every time a tax code changes someplace, or some user has to deal with a > new payroll service, or whatever. You end up using a bug tracker as a > task queue, with individual programmers acting as "worker threads". > >> * Is there a way to make it viable for teams while still keeping most >> of the strengths? > > One trendy thing I see in Python similar these days is extensive use of > test automation. In some approaches you're supposed to write a test for > every new feature before you even implement the feature. You run the > whole test suite every time you change something. Whenever you fix a > bug, you write a test and save it. The repeated testing catches all > sorts of problems early. I'd think Forth needs this even more than > Python does, but I don't hear about it much on this newsgroup. Well, there are test suites that get discussed fairly often, such as the Hayes suite for ANS Forth compatibility, and its various extensions. You don't hear much about test suites for applications because a lot of the folks on c.l.f aren't using Forth professionally. Those of us who do find the basic interactiveness of Forth somewhat reduces the need for external tools, but many applications need (and get) custom test harnesses. These can be as simple as a sequence of test commands and data in a file that can be interpreted, or more elaborate. SwiftForth has a feature to facilitate testing which consists of the ability to record the command window in an editable text file, preserving the session for review or reuse. Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2012-04-10 01:48 -0700 |
| Subject | Re: Complexity |
| Message-ID | <7xiph8otut.fsf@ruckus.brouhaha.com> |
| In reply to | #11090 |
"Elizabeth D. Rather" <erather@forth.com> writes: > Those of us who do find the basic interactiveness of Forth somewhat > reduces the need for external tools, Python is interactive too but the testing tools really help. > but many applications need (and get) custom test harnesses. It's helpful to have a re-usable test system and a culture of using it. > SwiftForth has a feature to facilitate testing which consists of the > ability to record the command window in an editable text file, > preserving the session for review or reuse. That actually sounds helpful and I've wondered about something like it for Python. I haven't used Mathematica notebooks but it sounds like a similar idea. However, part of the idea of test automation is that you write tests for all your code, and the other developers write tests for their code, and every time you change anything you run ALL the tests, in case your change broke someone else's feature.
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markrobertwills@yahoo.co.uk> |
|---|---|
| Date | 2012-04-10 01:28 -0700 |
| Subject | Re: Complexity |
| Message-ID | <62119041-499e-434e-87f8-7c09075e8d6d@d17g2000vba.googlegroups.com> |
| In reply to | #11083 |
On Apr 10, 4:30 am, Paul Rubin <no.em...@nospam.invalid> wrote: > One trendy thing I see in Python similar these days is extensive use of > test automation. In some approaches you're supposed to write a test for > every new feature before you even implement the feature. You run the > whole test suite every time you change something. Whenever you fix a > bug, you write a test and save it. The repeated testing catches all > sorts of problems early. I'd think Forth needs this even more than > Python does, but I don't hear about it much on this newsgroup. I'd disagree, because FOrth is designed to be tested at the word level. You write a word, and then you test it. Then you move on. An experienced programmer will test the word against any funny edge cases. When he's happy, he can write a comment in the source code of the word: : SomeWord \ Tested - OK. M.Wills 12/04/10 ... ... ... ; Forth is about growing applications, and testing as you go. I used to work for a company where the C guys would code C all day (there was 5 or six of them) - so probably hundreds of lines of code a day, then compile the app overnight and run the unit tests overnight, then come in the next morning and set about re-writing the code that they wrote the day before. Bananas. Maybe Chuck is correct? Maybe it's all about large budgets, and "bums on seats"? *Bum means ass in British English, not a hobo!
[toc] | [prev] | [next] | [standalone]
Page 5 of 11 — ← Prev page 1 … 3 4 [5] 6 7 … 11 Next page →
Back to top | Article view | comp.lang.forth
csiph-web