Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #17381 > unrolled thread
| Started by | Chris Hinsley <chris.hinsley@gmail.com> |
|---|---|
| First post | 2012-11-19 16:03 +0000 |
| Last post | 2012-11-29 11:47 -0800 |
| Articles | 20 on this page of 180 — 34 participants |
Back to article view | Back to comp.lang.forth
why bother with standards ? Chris Hinsley <chris.hinsley@gmail.com> - 2012-11-19 16:03 +0000
Re: why bother with standards ? Chris Hinsley <chris.hinsley@gmail.com> - 2012-11-19 16:06 +0000
Re: why bother with standards ? daveyrotten <danw8804@gmail.com> - 2012-11-19 08:15 -0800
Re: why bother with standards ? rickman <gnuarm@gmail.com> - 2012-11-19 12:07 -0500
Re: why bother with standards ? Bernd Paysan <bernd.paysan@gmx.de> - 2012-11-20 02:27 +0100
Re: why bother with standards ? Winston19842005 <winston19842005@yahoo.com> - 2012-11-19 21:59 -0500
Re: why bother with standards ? Jason Damisch <jasondamisch@yahoo.com> - 2012-11-19 19:21 -0800
Re: why bother with standards ? Mark Wills <forthfreak@gmail.com> - 2012-11-20 01:33 -0800
Re: why bother with standards ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-11-20 05:09 -0600
Re: why bother with standards ? Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-11-20 18:48 -0800
Re: why bother with standards ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-11-20 09:49 +0000
Re: why bother with standards ? Pablo Hugo Reda <pabloreda@gmail.com> - 2012-11-19 10:59 -0800
Re: why bother with standards ? "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-11-19 19:06 -0500
Re: why bother with standards ? "Elizabeth D. Rather" <erather@forth.com> - 2012-11-19 14:25 -1000
Re: why bother with standards ? Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-11-19 20:29 -0800
Re: why bother with standards ? "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-11-20 05:42 -0500
Re: why bother with standards ? Chris Hinsley <chris.hinsley@gmail.com> - 2012-11-20 17:23 +0000
Re: why bother with standards ? "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-11-20 21:05 -0500
Re: why bother with standards ? Chris Hinsley <chris.hinsley@gmail.com> - 2012-11-21 14:24 +0000
Re: why bother with standards ? Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-11-20 18:24 -0800
Re: why bother with standards ? Alex McDonald <blog@rivadpm.com> - 2012-11-20 03:07 -0800
Re: why bother with standards ? Chris Hinsley <chris.hinsley@gmail.com> - 2012-11-20 17:35 +0000
Re: why bother with standards ? "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-11-20 21:02 -0500
Re: why bother with standards ? Alex McDonald <blog@rivadpm.com> - 2012-11-21 02:04 -0800
Re: why bother with standards ? Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-11-20 19:21 -0800
Re: why bother with standards ? Alex McDonald <blog@rivadpm.com> - 2012-11-21 01:34 -0800
Re: why bother with standards ? "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-11-21 04:51 -0500
Re: why bother with standards ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-11-21 04:43 -0600
Re: why bother with standards ? Fritz Wuehler <fritz@spamexpire-201211.rodent.frell.theremailer.net> - 2012-11-21 20:34 +0100
Re: why bother with standards ? Alex McDonald <blog@rivadpm.com> - 2012-11-21 12:04 -0800
Re: why bother with standards ? "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-11-22 21:19 -0500
Re: why bother with standards ? Mark Wills <forthfreak@gmail.com> - 2012-11-23 02:05 -0800
Re: why bother with standards ? Alex McDonald <blog@rivadpm.com> - 2012-11-23 03:05 -0800
Re: why bother with standards ? Mark Wills <forthfreak@gmail.com> - 2012-11-23 03:22 -0800
Re: why bother with standards ? visualforth@rocketmail.com - 2012-11-23 12:13 -0800
Re: why bother with standards ? Alex McDonald <blog@rivadpm.com> - 2012-11-23 12:24 -0800
Re: why bother with standards ? "Elizabeth D. Rather" <erather@forth.com> - 2012-11-23 10:43 -1000
Re: why bother with standards ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-11-23 15:10 -0600
Re: why bother with standards ? Paul Rubin <no.email@nospam.invalid> - 2012-11-23 13:40 -0800
Re: why bother with standards ? Alex McDonald <blog@rivadpm.com> - 2012-11-23 13:44 -0800
Re: why bother with standards ? Bernd Paysan <bernd.paysan@gmx.de> - 2012-11-24 01:29 +0100
Re: why bother with standards ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-11-24 04:54 -0600
Re: why bother with standards ? visualforth@rocketmail.com - 2012-11-24 16:56 -0800
Re: why bother with standards ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-11-25 04:16 -0600
Re: why bother with standards ? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2012-11-26 14:48 +0000
Re: why bother with standards ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-11-23 09:12 -0600
Re: why bother with standards ? Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-11-23 22:00 -0800
Re: why bother with standards ? Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-11-23 03:52 -0800
Re: why bother with standards ? Alex McDonald <blog@rivadpm.com> - 2012-11-23 07:34 -0800
Re: why bother with standards ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-11-23 09:57 -0600
Re: why bother with standards ? Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-11-23 20:09 -0800
Re: why bother with standards ? Alex McDonald <blog@rivadpm.com> - 2012-11-24 04:53 -0800
Re: why bother with standards ? Bernd Paysan <bernd.paysan@gmx.de> - 2012-11-24 14:32 +0100
Re: why bother with standards ? Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-11-24 21:01 -0800
Re: why bother with standards ? Alex McDonald <blog@rivadpm.com> - 2012-11-25 02:22 -0800
Re: why bother with standards ? Alex McDonald <blog@rivadpm.com> - 2012-11-25 02:27 -0800
Re: why bother with standards ? awegel@arcor.de (Alex Wegel) - 2012-11-23 19:12 +0100
Re: why bother with standards ? Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-11-23 22:39 -0800
Re: why bother with standards ? awegel@arcor.de (Alex Wegel) - 2012-11-24 16:54 +0100
Re: why bother with standards ? "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-11-25 05:09 -0500
Re: why bother with standards ? mhx@iae.nl (Marcel Hendrix) - 2012-11-25 13:33 +0200
Re: why bother with standards ? Alex McDonald <blog@rivadpm.com> - 2012-11-24 12:20 -0800
Re: why bother with standards ? Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-11-24 20:45 -0800
Re: why bother with standards ? Alex McDonald <blog@rivadpm.com> - 2012-11-25 02:21 -0800
Re: why bother with standards ? visualforth@rocketmail.com - 2012-11-21 14:38 -0800
Re: why bother with standards ? Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-11-21 18:17 -0800
Re: why bother with standards ? Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-11-23 04:26 -0800
Re: why bother with standards ? Ron Aaron <rambamist@gmail.com> - 2012-11-23 15:28 +0200
Re: why bother with standards ? awegel@arcor.de (Alex Wegel) - 2012-11-21 17:29 +0100
Re: why bother with standards ? Chris Hinsley <chris.hinsley@gmail.com> - 2012-11-20 17:21 +0000
Re: why bother with standards ? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2012-11-21 13:00 +0000
Re: why bother with standards ? Chris Hinsley <chris.hinsley@gmail.com> - 2012-11-21 14:31 +0000
Re: why bother with standards ? Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-11-21 17:41 -0800
Re: why bother with standards ? Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-11-21 20:33 -0800
Re: why bother with standards ? Mark Humphries <mwh@intranetsys.com> - 2012-11-22 10:00 -0800
Re: why bother with standards ? Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-11-22 17:16 -0800
Re: why bother with standards ? Chris Hinsley <chris.hinsley@gmail.com> - 2012-11-20 17:12 +0000
Re: why bother with standards ? Josh Grams <josh@qualdan.com> - 2012-11-20 17:30 +0000
Re: why bother with standards ? Chris Hinsley <chris.hinsley@gmail.com> - 2012-11-20 17:48 +0000
Re: why bother with standards ? Andy Valencia <vandys@vsta.org> - 2012-11-20 19:40 +0000
Re: why bother with standards ? Chris Hinsley <chris.hinsley@gmail.com> - 2012-11-20 19:50 +0000
Re: why bother with standards ? Alex McDonald <blog@rivadpm.com> - 2012-11-20 15:41 -0800
Re: why bother with standards ? Chris Hinsley <chris.hinsley@gmail.com> - 2012-11-21 14:43 +0000
Re: why bother with standards ? Alex McDonald <blog@rivadpm.com> - 2012-11-21 08:46 -0800
Re: why bother with standards ? Brad Eckert <hwfwguy@gmail.com> - 2012-11-20 14:09 -0800
Re: why bother with standards ? Paul Rubin <no.email@nospam.invalid> - 2012-11-24 10:41 -0800
Re: why bother with standards ? visualforth@rocketmail.com - 2012-11-24 11:37 -0800
Re: why bother with standards ? Paul Rubin <no.email@nospam.invalid> - 2012-11-24 22:32 -0800
Re: why bother with standards ? visualforth@rocketmail.com - 2012-11-25 07:54 -0800
Re: why bother with standards ? visualforth@rocketmail.com - 2012-11-25 17:02 -0800
Re: why bother with standards ? "Elizabeth D. Rather" <erather@forth.com> - 2012-11-25 16:20 -1000
Re: why bother with standards ? Paul Rubin <no.email@nospam.invalid> - 2012-11-25 19:44 -0800
Re: why bother with standards ? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2012-11-26 14:59 +0000
Re: why bother with standards ? visualforth@rocketmail.com - 2012-11-26 11:37 -0800
Re: why bother with standards ? Paul Rubin <no.email@nospam.invalid> - 2012-11-26 13:05 -0800
Re: why bother with standards ? visualforth@rocketmail.com - 2012-11-26 15:29 -0800
Re: why bother with standards ? Paul Rubin <no.email@nospam.invalid> - 2012-11-26 16:38 -0800
Re: why bother with standards ? visualforth@rocketmail.com - 2012-11-26 19:37 -0800
Re: why bother with standards ? Paul Rubin <no.email@nospam.invalid> - 2012-11-26 20:29 -0800
Re: why bother with standards ? visualforth@rocketmail.com - 2012-11-26 22:22 -0800
Re: why bother with standards ? Paul Rubin <no.email@nospam.invalid> - 2012-11-26 23:03 -0800
Re: why bother with standards ? visualforth@rocketmail.com - 2012-11-27 01:09 -0800
Re: why bother with standards ? Paul Rubin <no.email@nospam.invalid> - 2012-11-27 08:52 -0800
Re: why bother with standards ? visualforth@rocketmail.com - 2012-11-27 10:43 -0800
Re: why bother with standards ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-11-27 12:01 -0600
Re: why bother with standards ? Paul Rubin <no.email@nospam.invalid> - 2012-11-28 23:37 -0800
Re: why bother with standards ? Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-11-29 00:00 -0800
Re: why bother with standards ? "Elizabeth D. Rather" <erather@forth.com> - 2012-11-28 22:13 -1000
Re: why bother with standards ? Paul Rubin <no.email@nospam.invalid> - 2012-11-29 01:11 -0800
Re: why bother with standards ? Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2012-11-29 11:00 +0000
Re: why bother with standards ? Bernd Paysan <bernd.paysan@gmx.de> - 2012-11-29 18:58 +0100
Re: why bother with standards ? Paul Rubin <no.email@nospam.invalid> - 2012-11-29 12:51 -0800
Re: why bother with standards ? Bernd Paysan <bernd.paysan@gmx.de> - 2012-11-30 00:42 +0100
Re: why bother with standards ? Paul Rubin <no.email@nospam.invalid> - 2012-11-29 19:57 -0800
Re: why bother with standards ? Mark Wills <forthfreak@gmail.com> - 2012-11-30 02:22 -0800
Re: why bother with standards ? Bernd Paysan <bernd.paysan@gmx.de> - 2012-11-30 18:47 +0100
Re: why bother with standards ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-11-30 12:53 +0000
Re: why bother with standards ? Bernd Paysan <bernd.paysan@gmx.de> - 2012-11-30 18:33 +0100
Debuggers (Re: why bother with standards ?) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-11-29 13:44 +0000
Re: Debuggers (Re: why bother with standards ?) Paul Rubin <no.email@nospam.invalid> - 2012-11-29 09:36 -0800
Re: why bother with standards ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-11-29 06:01 -0600
Re: why bother with standards ? Paul Rubin <no.email@nospam.invalid> - 2012-11-29 10:00 -0800
Re: why bother with standards ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-11-29 12:22 -0600
Re: why bother with standards ? Paul Rubin <no.email@nospam.invalid> - 2012-11-29 10:38 -0800
Re: why bother with standards ? Coos Haak <chforth@hccnet.nl> - 2012-11-29 21:13 +0100
Re: why bother with standards ? "Elizabeth D. Rather" <erather@forth.com> - 2012-11-29 17:11 -1000
Re: why bother with standards ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-11-30 03:37 -0600
Re: why bother with standards ? Paul Rubin <no.email@nospam.invalid> - 2012-11-30 02:11 -0800
Re: why bother with standards ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-11-30 05:24 -0600
Re: why bother with standards ? Paul Rubin <no.email@nospam.invalid> - 2012-11-30 11:23 -0800
Re: why bother with standards ? the_gavino_himself <visphatesjava@gmail.com> - 2012-11-29 21:16 -0800
Re: why bother with standards ? "Elizabeth D. Rather" <erather@forth.com> - 2012-11-29 08:38 -1000
Re: why bother with standards ? stephenXXX@mpeforth.com (Stephen Pelc) - 2012-11-29 18:43 +0000
Re: why bother with standards ? stephenXXX@mpeforth.com (Stephen Pelc) - 2012-11-29 12:15 +0000
Re: why bother with standards ? Paul Rubin <no.email@nospam.invalid> - 2012-11-29 09:23 -0800
Re: why bother with standards ? stephenXXX@mpeforth.com (Stephen Pelc) - 2012-11-29 18:24 +0000
Re: why bother with standards ? Paul Rubin <no.email@nospam.invalid> - 2012-11-29 11:06 -0800
Re: why bother with standards ? "Elizabeth D. Rather" <erather@forth.com> - 2012-11-29 17:35 -1000
Re: why bother with standards ? Paul Rubin <no.email@nospam.invalid> - 2012-11-29 22:37 -0800
Re: why bother with standards ? "Elizabeth D. Rather" <erather@forth.com> - 2012-11-29 21:08 -1000
Re: why bother with standards ? Bernd Paysan <bernd.paysan@gmx.de> - 2012-11-30 17:41 +0100
Re: why bother with standards ? "Elizabeth D. Rather" <erather@forth.com> - 2012-11-30 08:43 -1000
Re: why bother with standards ? Mark Wills <forthfreak@gmail.com> - 2012-11-30 02:30 -0800
Re: why bother with standards ? stephenXXX@mpeforth.com (Stephen Pelc) - 2012-11-30 10:40 +0000
Re: why bother with standards ? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2012-11-30 14:03 +0000
Re: why bother with standards ? Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-11-30 14:06 -0800
Re: why bother with standards ? Alex McDonald <blog@rivadpm.com> - 2012-11-30 14:51 -0800
Re: why bother with standards ? Howerd <howerdo@yahoo.co.uk> - 2012-11-30 14:58 -0800
Re: why bother with standards ? Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-12-02 18:02 -0800
Re: why bother with standards ? Bernd Paysan <bernd.paysan@gmx.de> - 2012-12-03 16:34 +0100
Re: why bother with standards ? Coos Haak <chforth@hccnet.nl> - 2012-12-03 21:39 +0100
Re: why bother with standards ? Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-12-03 14:49 -0800
Re: why bother with standards ? Brad Eckert <hwfwguy@gmail.com> - 2012-12-05 09:24 -0800
Re: why bother with standards ? Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-12-05 11:26 -0800
Re: why bother with standards ? Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-12-05 11:39 -0800
Re: why bother with standards ? Alex McDonald <blog@rivadpm.com> - 2012-12-05 15:32 -0800
Re: why bother with standards ? "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-12-05 20:57 -0500
Re: why bother with standards ? Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-12-05 18:55 -0800
Re: why bother with standards ? Paul Rubin <no.email@nospam.invalid> - 2012-12-05 20:01 -0800
Re: why bother with standards ? "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-12-06 19:05 -0500
Re: why bother with standards ? Paul Rubin <no.email@nospam.invalid> - 2012-12-06 16:14 -0800
Re: why bother with standards ? Bill Marcum <bill@nowhere.invalid> - 2012-12-07 20:13 -0500
Re: why bother with standards ? Brad Eckert <hwfwguy@gmail.com> - 2012-12-03 14:29 -0800
Re: why bother with standards ? Mark Wills <forthfreak@gmail.com> - 2012-11-30 02:20 -0800
Re: why bother with standards ? Doug Hoffman <glidedog@gmail.com> - 2012-11-30 06:52 -0500
Re: why bother with standards ? Bernd Paysan <bernd.paysan@gmx.de> - 2012-11-29 19:12 +0100
Re: why bother with standards ? Paul Rubin <no.email@nospam.invalid> - 2012-11-29 14:55 -0800
Re: why bother with standards ? Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-11-26 22:01 -0800
Re: why bother with standards ? visualforth@rocketmail.com - 2012-11-27 01:44 -0800
Re: why bother with standards ? "Ed" <invalid@nospam.com> - 2012-11-21 12:40 +1100
Re: why bother with standards ? Chris Hinsley <chris.hinsley@gmail.com> - 2012-11-21 14:51 +0000
Re: why bother with standards ? visualforth@rocketmail.com - 2012-11-21 19:24 -0800
Re: why bother with standards ? visualforth@rocketmail.com - 2012-11-21 21:54 -0800
Re: why bother with standards ? The Beez <the.beez.speaks@gmail.com> - 2012-11-24 08:03 -0800
Re: why bother with standards ? "Ed" <invalid@nospam.com> - 2012-11-30 14:45 +1100
Re: why bother with standards ? stephenXXX@mpeforth.com (Stephen Pelc) - 2012-11-30 10:48 +0000
Re: why bother with standards ? "Ed" <invalid@nospam.com> - 2012-12-04 03:52 +1100
Re: why bother with standards ? The Beez <the.beez.speaks@gmail.com> - 2012-12-06 10:34 -0800
Re: why bother with standards ? The Beez <the.beez.speaks@gmail.com> - 2012-12-06 10:37 -0800
Re: why bother with standards ? the_gavino_himself <visphatesjava@gmail.com> - 2012-11-29 11:47 -0800
Page 6 of 9 — ← Prev page 1 2 3 4 5 [6] 7 8 9 Next page →
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2012-11-26 23:03 -0800 |
| Message-ID | <7xhaobo7d7.fsf@ruckus.brouhaha.com> |
| In reply to | #17592 |
visualforth@rocketmail.com writes: > Because people like to have something of their own, which works > standalone, not connected to a computer. In theory it's just a matter > of programming - if you are doing mental experiments. Eh? They want a board with a couple of blinky leds and pushbuttons, instead of something with a screen and keyboard and internet connection? I can understand if they want to use the a/d converters to control their fish tank, but for just learning to program, well, I still don't see the point, maybe I'm just missing something. > For beginners programming a PC or phone/tablet is much harder than > programming a microprocessor. Have you ever done programming on > Windows or Linux? Then compare it to programming a microcontroller! > That's quite a difference. I've done some Windows programming and I program Linux all day long, and I've done some embedded programming (though on bigger cpus than these little microcontrollers). Embedded is orders of magnitude harder in my opinion. When your program crashes you have no idea what happened, and in the bad cases you may have to mess around with hardware debuggers and oscilloscopes (something I don't know how to do). Plus on smaller systems you have to use languages (like Forth) with very few safety checks, causing more hazards. The rule of Forth is write very small words and test each one very thoroughly before going on to the next one. IMO that's partly because debugging is such a pain--e.g., chasing an error that's 5 levels deep in calls is a big hassle. If that happens in Lisp or Python, you get diagnostics saying exactly what happened, you can trap to a debugger, and in general you can fix any reproducible bug with very little fuss, and you can diagnose intermittent bugs if you catch them happening with enough tracing enabled (using machine resources that aren't available on microcontrollers). I spent basically the whole of Friday evening writing a morse code blinky program in gforth with the idea of porting it to 4e4th, that's at least 4 hours, plus some further tweaking around with it later. That was with the comparatively nice (pointer checking etc--I had several address errors that it caught for me immediately) gforth environment and Emacs Forth mode, and being able to code stuff with locals before refactoring to get rid of them. Maybe with more Forth experience I could have written it twice as fast, but then again, doing it with a tty emulator to a microcontroller Forth would have doubled the time again, so we're back at 4 hours. Perhaps with Swiftforth and its debugging tools it would be back down to 2 hours. In Python on a PC, it would be more like 15 minutes. Someday I'd like to watch an old-school Forth wizard program something on a traditional Forth system with a block editor, shadow screens, and that whole setup. Those systems were amazing for the capabilities they brought to tiny machines but obviously they had to cut a lot of corners, and the programmers must have had to adjust their methods to deal with that. > It's really quite a different experience using microcontrollers and do > some fancy stuff with it. There are thousands of young people > programming the Arduino without using Forth, and the Raspberry Pi is > sold by the tenthousands, see "10,000 educational single board > computers sold on the first day!" The Raspberry Pi is basically a shrunk-down desktop Linux computer and the favorite out-of-the-box languages for it appear to be Python and Javascript. Progamming it isn't much different than programming a PC. I'm not sure at all that anyone is programming the Arduino as their first exposure to programming, but maybe they are. > Power usage depends on the program running on the MSP. Hmm, ok, that's good to know. >> There is also an ultra low power low speed mode (some khz) that uses >> just a few microwatts and is good for a real time clock. > 4E4th doesn't use this ultra low power low speed mode. You mean the mode is only accessible with assembly code? See, we were just talking about how 4e4th needs an assembler ;-). I do want to use that mode. > Soldering this tiny little part is expensive, and the MSP430 runs > properly without any quartz. Why bother? It's a gift for people who > like to do this extra work. A real-time clock is a useful thing. Is the xtal really harder to solder than the SMT parts that are already on the board??? I'd think they could just put it on with the same machine that assembled the rest of the board. Jillions of one-dollar digital wristwatches have those xtals, they can't be that hard to assemble.
[toc] | [prev] | [next] | [standalone]
| From | visualforth@rocketmail.com |
|---|---|
| Date | 2012-11-27 01:09 -0800 |
| Message-ID | <36044f6c-3da1-4a03-aaa5-d2ab5b0d786c@googlegroups.com> |
| In reply to | #17593 |
On Tuesday, November 27, 2012 2:03:23 AM UTC-5, Paul Rubin wrote: > visualforth.com writes: >> Because people like to have something of their own, which works >> standalone, not connected to a computer. In theory it's just a matter >> of programming - if you are doing mental experiments. > Eh? They want a board with a couple of blinky leds and pushbuttons, instead of something with a screen and keyboard and internet connection? Yes, of course. Our customers are kids. If you look at all these webpages on the Internet, you will recognize that this is the truth. These kids get an exiting experience with C to switch one LED on! With Forth they can do more than that, look at http://www.youtube.com/watch?v=ATIKexOp4_A The program for this experiment is published at http://forum.43oh.com/topic/2102-police-lights-in-forth/ The code for a blinking LED only is shown here: http://forum.best-microcontroller-projects.com/viewtopic.php?f=23&t=2397 > I can understand if they want to use the a/d converters to control their fish tank, but for just learning to > program, well, I still don't see the point, maybe I'm just missing something. I am sure you are just missing a point: Learning by doing. That's the goal. And programming only for programming's sake doesn't make any sense. There must be results. There must be action. So they will use the onchip a/d converter to control their fish tank, and other fancy stuff. The LaunchPad may be used as a temperature logger, it only needs a little button cell. >> For beginners programming a PC or phone/tablet is much harder than >> programming a microprocessor. Have you ever done programming on >> Windows or Linux? Then compare it to programming a microcontroller! >> That's quite a difference. > I've done some Windows programming and I program Linux all day long, and I've done some embedded programming (though on bigger cpus than these little microcontrollers). Bigger cpus are not easy to program if you don't use Forth. With Forth even bigger cpus are not hard to program. But we have chosen the MSP430G2553, a tiny little microprocessor. It is complex enough to have a lot of learning possibilities and easy enough for beginners, using 4E4th. > Embedded is orders of magnitude harder in my opinion. When your program crashes you have no idea what happened, That's why we use 4E4th and the 4E4th-IDE for support. Program crashes are no problem. With typing a WIPE - or holding button S2 and the reset button at the same time - 4E4th works again, and with a new download you can start over again. Of course it makes sense to check for mistakes you may have made. You don't have to type your stuff again - everything is saved and editable. > and in the bad cases you may have to mess around with hardware debuggers and oscilloscopes (something I don't know how to do). I am working with microprocessors since 40 years now, having had a new project every three month for ten years - I never needed a hardware debugger or an In Circuit Emulator. But I am used to oscilloscopes. They help a lot. > Plus on smaller systems you have to use languages (like Forth) with very few safety checks, causing more hazards. That's excellent! Most people when starting programming for their first time have to learn to type the program in the right manner. Using examples or tutorials, they have to learn to type a program character by character just as it is written in the manual. That is the hard part of the start. When this is done, programming will be easier. Hazards help to learn to be careful. Only with careful programming you get good results. Did you never crash your PC when programming with Linux? > The rule of Forth is write very small words and test each one very thoroughly before going on to the next one. That's true! That's why our 4E4th-IDE supports thoroughly testing each word. When a definition is done, a click on the "Run!" button starts this word. That's the fastest kind of testing ever was. After a very short time, testing each word will become a habit, because it is so easy. Nobody has to type a word to do a test. > IMO that's partly because debugging is such a pain--e.g., chasing an error that's 5 levels deep in calls is a big hassle. Seems to be you know this problem. We know this problem, too. I remember back in the seventies, somebody from the University's Computer science department told me really proud that he just wrote 20kB of program - that was a huge program those days. I preferred not to ask how long he estimated testing and debugging will need. In those days I wrote all my programs in assembly language, using pencil and paper - and structured programming, checking each decision in each program word. I never had problems chasing an error that's 5 levels deep - each level was tested. And that what we will teach the kids. > If that happens in Lisp or Python, you get diagnostics saying exactly what happened, you can trap to a debugger, and in general you can fix any reproducible bug with very little fuss, and you can diagnose intermittent bugs if you catch them happening with enough tracing enabled (using machine resources that aren't available on microcontrollers). Do you think beginners are able to handle these diagnostic tools? How long did it take you to properly learn how it works and to use it? > I spent basically the whole of Friday evening writing a morse code blinky program in gforth with the idea of porting it to 4e4th, that's at least 4 hours, plus some further tweaking around with it later. Thanks for all your efforts! Seems to be morse code is en vogue. Dr. Ting and others wrote morse code programs, too. A morse code program comes with Forth Inc.'s MSP430 suite. And a morse code on 4E4th was presented at the SVFIG MSP430 day in July: "MSP430 Launchpad sends morse code with 4E4th" http://www.youtube.com/watch?v=ANZ_zruJ3_0 The 4E4th morse code is available from the Silicon Valley Forth Interest Group. > That was with the comparatively nice (pointer checking etc--I had several address errors that it caught for me immediately) gforth environment and Emacs Forth mode, and being able to code stuff with locals before refactoring to get rid of them. Maybe with more Forth experience I could have written it twice as fast, but then again, doing it with a tty emulator to a microcontroller Forth would have doubled the time again, so we're back at 4 hours. Perhaps with Swiftforth and its debugging tools it would be back down to 2 hours. In Python on a PC, it would be more like 15 minutes. I am sure programming a morse code on 4E4th will be faster than doing this with Python on a PC, but I am doubting that you can do this within 15 minutes. May be if you write it for one character only. The morse code program presented for the SVFIG has all standard morse code characters and a lot of extras. > Someday I'd like to watch an old-school Forth wizard program something on a traditional Forth system with a block editor, shadow screens, and that whole setup. Those systems were amazing for the capabilities they brought to tiny machines but obviously they had to cut a lot of corners, and the programmers must have had to adjust their methods to deal with that. I started with RSC-Forth having only one input line at a time. This was boring, so I wrote a block editor to make life easier, but I didn't use shadow screens. RSC-Forth had drivers for floppy disks, and I always was working directly in the system. In my experience that's the best way to do it and to get fastest results. >> It's really quite a different experience using microcontrollers and do >> some fancy stuff with it. There are thousands of young people >> programming the Arduino without using Forth, and the Raspberry Pi is >> sold by the tenthousands, see "10,000 educational single board >> computers sold on the first day!" > The Raspberry Pi is basically a shrunk-down desktop Linux computer and the favorite out-of-the-box languages for it appear to be Python and Javascript. Progamming it isn't much different than programming a PC. I'm not sure at all that anyone is programming the Arduino as their first exposure to programming, but maybe they are. 4E4th is good for a first exposure to programming! The Raspberry Pi was developed for education purposes. The Raspberry Pi is a big machine, that's why we are using the MSP430 LaunchPad. This one is much cheaper and much easier to use than the Raspberry Pi. We like to encourage young people to have excellent results on their experiments instead of disappointing them with things which don't work. The intended goal is to help young people to achieve self realization by doing great things. >>> There is also an ultra low power low speed mode (some khz) that uses >>> just a few microwatts and is good for a real time clock. >> 4E4th doesn't use this ultra low power low speed mode. > You mean the mode is only accessible with assembly code? See, we were just talking about how 4e4th needs an assembler ;-). I do want to use that mode. 4E4th doesn't use this ultra low power low speed mode, but 4E4th allows to start the ultra low power low speed mode using 4E4th words. So it may be used in 4E4th application programs. >> Soldering this tiny little part is expensive, and the MSP430 runs >> properly without any quartz. Why bother? It's a gift for people who >> like to do this extra work. > A real-time clock is a useful thing. Is the xtal really harder to solder than the SMT parts that are already on the board??? Do you know how SMD placing machines work? They put all parts in one stroke onto the board, like a stamping press. That won't work with the 32kHz crystal. > I'd think they could just put it on with the same machine that assembled the rest of the board. They can't ! > Jillions of one-dollar digital wristwatches have those xtals, they can't be that hard to assemble. Wrist watches are totally different than microcontroller PCBs. Manufacturing of wrist watches is specialized to manufacture wrist watches. But you can post this suggestion at http://e2e.ti.com/ May observation is that knowledge accumulated over the centuries is diminishing from the conscience of people and accumulating nearly only on computer memories. More and more programmers are coming directly from school or university, not having much experience of real life. They are used to produce wonderful pictures on computer screens but not caring about the experience of users who like to get a task done on a computer instead of waiting for animations to be downloaded. But the main thing is that these programmers have to be elite programmers because of the complexity of the products they are working on, and I am sure you are one of them. My observation is that the number of elite programmers doesn't grow – the crew of elite programmers moves forward with the advances of technologies - leaving the others behind. No one should be left behind. My goal is to give ordinary people the chance to do wonderful works of creation by themselves by offering a tool and a programming language which is reduced to a minimum of effort to use it. Forth is the programming language which is stripped off from all unnecessary attachment and distraction leaving pure logic to work with. Our 4E4th-IDE replicates that tradition, making real programming fun and easy. It was never more affordable and easier to start a programming education – self education or school education. This situation should be taken advantage of by delivering the right tools to enable programming education, discarding all unnecessary obstacles, to make it a newbees delight ...
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2012-11-27 08:52 -0800 |
| Message-ID | <7x38zvc7k4.fsf@ruckus.brouhaha.com> |
| In reply to | #17597 |
visualforth@rocketmail.com writes: > These kids get an exiting experience with C to switch one LED on! > > With Forth they can do more than that, look at http://www.youtube.com/watch?v=ATIKexOp4_A > The program for this experiment is published at http://forum.43oh.com/topic/2102-police-lights-in-forth/ > The code for a blinking LED only is shown here: http://forum.best-microcontroller-projects.com/viewtopic.php?f=23&t=2397 I wouldn't have thought of that as an exciting experience. It just seems like a simple exercise to get the board to do something. > I am sure you are just missing a point: Learning by doing. That's the > goal. And programming only for programming's sake doesn't make any > sense. There must be results. There must be action. So they will use > the onchip a/d converter to control their fish tank, and other fancy > stuff. The LaunchPad may be used as a temperature logger, it only > needs a little button cell. Well sure, some kinds of "results" involve hardware interfacing like that, others don't. Other types of results involve computing stuff, communications, games, etc. all of which are most easily done on PC's. > Bigger cpus are not easy to program if you don't use Forth. With Forth > even bigger cpus are not hard to program. I don't understand that at all; the biggest computer of them all is the human brain, and people have been programming those (admittedly unreliably...) for many 1000's of years--you just talk to the person ;-). Bigger computers are easier to program (except at the lowest level) than smaller ones, because there's higher-level languages, OS's to supply low level services so the programmer doesn't have to, enough machine resources that you can solve your problem straightforwardly instead of having to micro-optimize, etc. > But we have chosen the MSP430G2553, a tiny little microprocessor. It > is complex enough to have a lot of learning possibilities and easy > enough for beginners, using 4E4th. Yeah, I like it and think it's a great intro to the topic of embedded or low-level programming. I just think it's better to start from a higher level and work downward, rather than the other way around. >> Embedded is orders of magnitude harder in my opinion. When your >> program crashes you have no idea what happened, ... > That's why we use 4E4th and the 4E4th-IDE for support. Program crashes > are no problem. With typing a WIPE - or holding button S2 and the > reset button at the same time - 4E4th works again, and with a new > download you can start over again. I wasn't talking about restarting the crashed program. I mean, if your program crashes, how do you debug it? There are no error diagnostics like "subscript out of bounds at line 37". Your program just stops working. Even having to wipe stuff or press buttons and re-download is a nuisance compared to using a PC (just press F5 in the case of IDLE to re-launch the Python interpreter and send the program to it again). >> Plus on smaller systems you have to use languages (like Forth) with >> very few safety checks, causing more hazards. > Hazards help to learn to be careful. Only with careful programming you > get good results. The problem is having no way to tell what went wrong. > Did you never crash your PC when programming with Linux? I can't think of any times I ever crashed a PC due to a program bug under Linux. It's quite hard to do. Obviously the application can crash, but the OS keeps running, you can run the application under a debugger, etc. > That's true! That's why our 4E4th-IDE supports thoroughly testing each > word. When a definition is done, a click on the "Run!" button starts > this word. That's the fastest kind of testing ever was. After a very > short time, testing each word will become a habit, because it is so > easy. Nobody has to type a word to do a test. The issue is setting up the conditions for a test, and having to interrupt your train of thought to switch from coding to testing. I don't think it's good to write 20 pages of code without testing, but I'd like to be able to express an entire thought at a time, usually corresponding to more code than a typical one or two line Forth word. > 20kB of program - that was a huge program those days. I preferred not > to ask how long he estimated testing and debugging will need. If that was assembly language, then yeah, that sounds awful. HLL's are much easier to debug. >> If that happens in Lisp or Python, you get diagnostics saying exactly >> what happened, you can trap to a debugger > Do you think beginners are able to handle these diagnostic tools? How > long did it take you to properly learn how it works and to use it? The first thing you need is good error messages, i.e. "you tried to divide by zero in procedure foo at line 23; the stack trace is ..." saying what foo's other args were, and how the program got to there. I don't remember having too much trouble figuring out how to use debuggers either, and I never even used the fancy graphical ones (sort of a regret of mine). > Thanks for all your efforts! Seems to be morse code is en > vogue. Dr. Ting and others wrote morse code programs, too. Yeah, there are a lot of them, I figure it's the "hello world" of embedded Forth. > I am sure programming a morse code on 4E4th will be faster than doing > this with Python on a PC, but I am doubting that you can do this > within 15 minutes. May be if you write it for one character only. I just did it as an exercise, it was about 9.5 minutes from start to finish to write it in Python, though I cheated because I already had the Forth program I'd written earlier. I pasted a few lines from it (the table giving the morse alphabet) and re-implemented basically the same logic. So having the Forth code ahead of time probably saved me a few minutes. > The morse code program presented for the SVFIG has all standard morse > code characters and a lot of extras. Yeah, mine has the regular letters and digits and a few symbols, but adding more is trivial. > The Raspberry Pi was developed for education purposes... The intended > goal is to help young people to achieve self realization by doing > great things. Well I'd be interested to know what kinds of things they are doing and what kind of reception the Launchpad is getting with them. > 4E4th allows to start the ultra low power low speed mode using 4E4th > words. So it may be used in 4E4th application programs. Oh great, that helps. But the ultra low speed mode is just a few khz cpu clock, so I wonder if 4e4th is fast enough even for something simple like an RTC. Do you know if it can read the GPIO pins at that low speed and power level? My application is going to require listening for some pushbutton-like events for long periods while using very little power. > Do you know how SMD placing machines work? They put all parts in one > stroke onto the board, like a stamping press. That won't work with the > 32kHz crystal. Hm, there are also some through-hole parts on the board, but ok, I'll defer to your hardware knowledge about this. > But the main thing is that these programmers have to be elite > programmers because of the complexity of the products they are working > on, and I am sure you are one of them. My observation is that the > number of elite programmers doesn't grow – the crew of elite > programmers moves forward with the advances of technologies - leaving > the others behind. I don't think I'm an elite programmer, but I manage to keep doing useful things. Lots of other programmers who are even less elite than me are out there programming PHP and Javascript and so on. It doesn't take an elite programmer to write a Flash animation. It instead takes an existing environment that abstracts away the low level details that would overwhelm the non-elite programmer. > Forth is the programming language which is stripped off from all > unnecessary attachment and distraction leaving pure logic to work > with. Our 4E4th-IDE replicates that tradition, making real programming > fun and easy. At the beginner level I see Forth as great for explaining what a computer is doing at the lowest level (the language is pretty complex but most of the complexity can be ignored). At a much higher level there's languages like Javascript, which lets beginners write animations and games easily by keeping low level stuff out of sight. Even BASIC is much simpler than Forth at relatively trivial things: 10 INPUT "What is your name? ", A$ 20 PRINT "Hello ", A$, "!" I don't see much sense in attempting a continuous progression from low-level to high-level programming, if that's what you have in mind. They are separate areas of programming and trying to get them to meet in the middle takes a lot of experience and "eliteness". Anyway, I'm not trying to disrespect what you're doing--I still think it's great. I just think the most suitable target audience is probably people like me rather than newbies. ;-).
[toc] | [prev] | [next] | [standalone]
| From | visualforth@rocketmail.com |
|---|---|
| Date | 2012-11-27 10:43 -0800 |
| Message-ID | <bbb68fe4-d887-4be9-a57e-92d12bfc79e9@googlegroups.com> |
| In reply to | #17605 |
On Tuesday, November 27, 2012 11:52:18 AM UTC-5, Paul Rubin wrote: > Anyway, I'm not trying to disrespect what you're doing--I still think it's great. I just think the most suitable target audience is probably people like me rather than newbies. ;-). I appreciate that you still think it's great. Thanks for the detailed discussion about 4E4th. I know that the most suitable target audience is probably people like you. Having newbees as an audience is a challenging task. Newbees recognize very fast the advantages of Forth.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2012-11-27 12:01 -0600 |
| Message-ID | <jI6dnUeYXJCdnSjNnZ2dnUVZ8s2dnZ2d@supernews.com> |
| In reply to | #17593 |
Paul Rubin <no.email@nospam.invalid> wrote: > I've done some Windows programming and I program Linux all day long, > and I've done some embedded programming (though on bigger cpus than > these little microcontrollers). Me too, more or less, but I did a lot on those little microcontrollers too. > Embedded is orders of magnitude harder in my opinion. When your > program crashes you have no idea what happened, and in the bad cases > you may have to mess around with hardware debuggers and > oscilloscopes (something I don't know how to do). Plus on smaller > systems you have to use languages (like Forth) with very few safety > checks, causing more hazards. Embedded programming wasn't harder for me. Guess why? I had Forth! Extensibility (to add tracing easily) and interactivity make a huge difference. You certainly don't need hardware debuggers unless that's the only way to get your program into the device. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2012-11-28 23:37 -0800 |
| Message-ID | <7xk3t4zwoo.fsf@ruckus.brouhaha.com> |
| In reply to | #17611 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes: > Embedded programming wasn't harder for me. Guess why? I had Forth! > Extensibility (to add tracing easily) and interactivity make a huge > difference. You certainly don't need hardware debuggers unless that's > the only way to get your program into the device. I remember wanting a hardware debugger to deal with a problem of intermittent memory corruption (certain locations getting clobbered and we couldn't figure out why) and the CPU didn't have hardware watchpoints (that would have found the problem instantly). A software debugger with breakpoints would have helped, but we didn't have that either, so we ended up having to rebuild the software with tracing and reload/boot the box dozens of times in order to close in on the problem. I've also generally found source-level single step debuggers (gdb) invaluable even for just trying to understand code that works (as opposed to diagnosing buggy code). If I want to figure out what some chunk of obscure code is doing, it's far more enlightening to breakpoint at the beginning of it and step through it with gdb, than to try to grok its operation by pure eyeballing of the code. For reverse engineering (though I haven't done much of that) I'm sure it's an even bigger help. If the embedded target supports this stuff, then great, but otherwise it's a big slowdown not to have it.
[toc] | [prev] | [next] | [standalone]
| From | Hugh Aguilar <hughaguilar96@yahoo.com> |
|---|---|
| Date | 2012-11-29 00:00 -0800 |
| Message-ID | <732c5f96-9bae-45b1-a4c6-a2880b4dbca5@qi8g2000pbb.googlegroups.com> |
| In reply to | #17661 |
On Nov 29, 12:37 am, Paul Rubin <no.em...@nospam.invalid> wrote: > Andrew Haley <andre...@littlepinkcloud.invalid> writes: > > Embedded programming wasn't harder for me. Guess why? I had Forth! > > Extensibility (to add tracing easily) and interactivity make a huge > > difference. You certainly don't need hardware debuggers unless that's > > the only way to get your program into the device. > > I remember wanting a hardware debugger to deal with a problem of > intermittent memory corruption (certain locations getting clobbered and > we couldn't figure out why) and the CPU didn't have hardware watchpoints > (that would have found the problem instantly). A software debugger with > breakpoints would have helped, but we didn't have that either, so we > ended up having to rebuild the software with tracing and reload/boot the > box dozens of times in order to close in on the problem. > > I've also generally found source-level single step debuggers (gdb) > invaluable even for just trying to understand code that works (as > opposed to diagnosing buggy code). If I want to figure out what some > chunk of obscure code is doing, it's far more enlightening to breakpoint > at the beginning of it and step through it with gdb, than to try to grok > its operation by pure eyeballing of the code. For reverse engineering > (though I haven't done much of that) I'm sure it's an even bigger help. > > If the embedded target supports this stuff, then great, but otherwise > it's a big slowdown not to have it. Since you seem to like debuggers, here is a discussion of how to write one in Forth: https://groups.google.com/group/comp.lang.forth/browse_thread/thread/9a8a98a8b17ae2ff
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2012-11-28 22:13 -1000 |
| Message-ID | <R8GdnVgRO725hCrNnZ2dnUVZ_qCdnZ2d@supernews.com> |
| In reply to | #17661 |
On 11/28/12 9:37 PM, Paul Rubin wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >> Embedded programming wasn't harder for me. Guess why? I had Forth! >> Extensibility (to add tracing easily) and interactivity make a huge >> difference. You certainly don't need hardware debuggers unless that's >> the only way to get your program into the device. > > I remember wanting a hardware debugger to deal with a problem of > intermittent memory corruption (certain locations getting clobbered and > we couldn't figure out why) and the CPU didn't have hardware watchpoints > (that would have found the problem instantly). A software debugger with > breakpoints would have helped, but we didn't have that either, so we > ended up having to rebuild the software with tracing and reload/boot the > box dozens of times in order to close in on the problem. > > I've also generally found source-level single step debuggers (gdb) > invaluable even for just trying to understand code that works (as > opposed to diagnosing buggy code). If I want to figure out what some > chunk of obscure code is doing, it's far more enlightening to breakpoint > at the beginning of it and step through it with gdb, than to try to grok > its operation by pure eyeballing of the code. For reverse engineering > (though I haven't done much of that) I'm sure it's an even bigger help. > > If the embedded target supports this stuff, then great, but otherwise > it's a big slowdown not to have it. > Some Forths have stepping debuggers. SwiftForth does, and the Open Firmware Standard specified one, although the implementors at IBM and Apple didn't value it enough to include it. It's helpful when the coding style is long sequences of code, or when you're trying to debug a whole application as a unit. But Forth development isn't like that, so most Forth programmers prefer just relying on the interactive nature of the system, which turns out to be far more productive. In practice, a Forth programmer can debug stuff at a rate that astounds programmers more accustomed to formal tools than Forth-style interactive debugging. 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-11-29 01:11 -0800 |
| Message-ID | <7xk3t4lqnq.fsf@ruckus.brouhaha.com> |
| In reply to | #17663 |
"Elizabeth D. Rather" <erather@forth.com> writes: > Some Forths have stepping debuggers. SwiftForth does, Yeah, it seems like a good selling point for SwiftForth. I don't see big obstacles to writing one, and if gforth had a working one I'd surely use it. > It's helpful when the coding style is long sequences of code, or when > you're trying to debug a whole application as a unit. But Forth > development isn't like that, so most Forth programmers prefer just > relying on the interactive nature of the system, which turns out to be > far more productive. Forth's interactivity for examining a running system isn't especially better than gdb's as far as I've discovered so far. Forth is much better (faster) at letting you rebuild the whole app very quickly. Forth's interactive, one-word-at-a-time development style can support a fast, experimental approach to coding, but that's not relevant to programs that are already completely written. Imagine (per Gavino) that Firefox is written in Forth. Even if it's 5x smaller than the C++ implementation, it's still probably close to a million lines of Forth code. Imagine (hahaha) that this million lines of Forth code has zero bugs, but other than that, its documentation and cruft level is about what you're used to from real-world application developers who were working against deadlines and not particularly trying to win style prizes. You are tasked with adding some new feature to the existing code, e.g. to make the tabs change color on a particular HTML event, or something like that. Maybe by some grepping and searching, you can find a chunk of code that seems to have something to do with the tabs, but how does the program ever get there? And what exactly is it doing when it draws the tabs? Before you can start modifying the code, you have to understand it, and I've generally found that single stepping is very helpful for this. It's just not possible to study all the paths from the entry word, keeping dozens of levels of stack diagrams in your head.
[toc] | [prev] | [next] | [standalone]
| From | Gerry Jackson <gerry@jackson9000.fsnet.co.uk> |
|---|---|
| Date | 2012-11-29 11:00 +0000 |
| Message-ID | <k97f8k$jv9$1@dont-email.me> |
| In reply to | #17670 |
On 29/11/2012 09:11, Paul Rubin wrote: > "Elizabeth D. Rather" <erather@forth.com> writes: >> Some Forths have stepping debuggers. SwiftForth does, > > Yeah, it seems like a good selling point for SwiftForth. I don't see > big obstacles to writing one, and if gforth had a working one I'd surely > use it. > >> It's helpful when the coding style is long sequences of code, or when >> you're trying to debug a whole application as a unit. But Forth >> development isn't like that, so most Forth programmers prefer just >> relying on the interactive nature of the system, which turns out to be >> far more productive. > > Forth's interactivity for examining a running system isn't especially > better than gdb's as far as I've discovered so far. Forth is much > better (faster) at letting you rebuild the whole app very quickly. > Forth's interactive, one-word-at-a-time development style can support a > fast, experimental approach to coding, but that's not relevant to > programs that are already completely written. > > Imagine (per Gavino) that Firefox is written in Forth. Even if it's 5x > smaller than the C++ implementation, it's still probably close to a > million lines of Forth code. Imagine (hahaha) that this million lines > of Forth code has zero bugs, but other than that, its documentation and > cruft level is about what you're used to from real-world application > developers who were working against deadlines and not particularly > trying to win style prizes. You are tasked with adding some new feature > to the existing code, e.g. to make the tabs change color on a particular > HTML event, or something like that. > > Maybe by some grepping and searching, you can find a chunk of code that > seems to have something to do with the tabs, but how does the program > ever get there? And what exactly is it doing when it draws the tabs? > Before you can start modifying the code, you have to understand it, and > I've generally found that single stepping is very helpful for this. > It's just not possible to study all the paths from the entry word, > keeping dozens of levels of stack diagrams in your head. > Have a look at this discussion https://groups.google.com/forum/?hl=en&fromgroups=#!topic/comp.lang.forth/ppxmTUGG4Jc/overview In particular GForth's ~~ Dennis Ruffer's fence post or even my feeble contribution although I now use p instead of pause. -- Gerry
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2012-11-29 18:58 +0100 |
| Message-ID | <7019095.aZCWt8kFuE@sunwukong.fritz.box> |
| In reply to | #17670 |
Paul Rubin wrote:
> "Elizabeth D. Rather" <erather@forth.com> writes:
>> Some Forths have stepping debuggers. SwiftForth does,
>
> Yeah, it seems like a good selling point for SwiftForth. I don't see
> big obstacles to writing one, and if gforth had a working one I'd
> surely use it.
It has one, you need to start gforth-itc to use it (it's a lot easier to
single step through real indirect threaded code than through some
compiled code, and the performance overhead of gforth-itc should not
matter much if you use a single step debugger ;-).
> Forth's interactivity for examining a running system isn't especially
> better than gdb's as far as I've discovered so far.
Uh, then you don't use it right. I've been using gdb, and it is awful!
Yes, you can call functions. But that's about it. What you can't
easily do is to let these functions work together.
> Forth is much
> better (faster) at letting you rebuild the whole app very quickly.
> Forth's interactive, one-word-at-a-time development style can support
> a fast, experimental approach to coding, but that's not relevant to
> programs that are already completely written.
Well, there's usually no point to rewrite a completely written program
*unless* it's fundamentally broken, and you need to go back to the
drawing board. You might want to replace parts of Firefox, and then use
Forth to start there, as it has been done with the JavaScript engine.
> Imagine (per Gavino) that Firefox is written in Forth. Even if it's
> 5x smaller than the C++ implementation, it's still probably close to a
> million lines of Forth code.
Firefox is written by a rather big team, and despite the effort to
rewrite Mozilla from scratch, it has a huge legacy. Any particular
programmer has contributed only a few thousand lines of code. Big teams
generate big programs, not as necessary complexity, but as accidential.
You know why Apple chose KHTML over Gecko? Because KHTML was written by
a small team, and therefore they had a much smaller and cleaner code
base than Gecko. Now, with Apple and Google throwing their teams at
WebKit, it's bloatware all over again.
> Imagine (hahaha) that this million lines of Forth code has zero bugs,
Firefox, as currently implemented in C++, has a gazillion of bugs, so
why should the Forth version have zero?
> but other than that, its documentation
> and cruft level is about what you're used to from real-world
> application developers who were working against deadlines and not
> particularly
> trying to win style prizes. You are tasked with adding some new
> feature to the existing code, e.g. to make the tabs change color on a
> particular HTML event, or something like that.
A few lines of JavaScript would do that... if you could add that sort of
stuff right into Firefox. If you can't: Design mistake. You should be
able to do that.
> Maybe by some grepping and searching, you can find a chunk of code
> that seems to have something to do with the tabs, but how does the
> program
> ever get there? And what exactly is it doing when it draws the tabs?
> Before you can start modifying the code, you have to understand it,
> and I've generally found that single stepping is very helpful for
> this. It's just not possible to study all the paths from the entry
> word, keeping dozens of levels of stack diagrams in your head.
What you actually need to find how the code gets there is a backtrace -
in Gforth, you could easily create¹ a word that can be placed everywhere
and will print a backtrace, and then continue. I'm also not sure if
that is particularly helpful in this case. You probably have code that
parses HTML and creates a DOM, and code that draws the DOM, code that
manipulates the DOM and figures out what to redraw, and code that takes
events and feeds them into the system.
¹) Here it is:
: ~bt~ ( -- ) store-backtrace dobacktrace nothrow ;
Insert wherever you like, and you get a full backtrace when the code
gets there. Maybe you want a version where you also see what's on the
stack and where the source location is... (like ~~ does). Feel free to
experiment with that.
Another nice debugging aid discussed recently is a debug shell: You add
a ?? into a word where you want to do some interactive examinations:
: ?? ( -- )
create-input cr
BEGIN refill WHILE source nip WHILE
interpret prompt cr REPEAT THEN
0 pop-file drop ;
This is sort-of equivalent to a breakpoint in gdb.
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2012-11-29 12:51 -0800 |
| Message-ID | <7xk3t45e0k.fsf@ruckus.brouhaha.com> |
| In reply to | #17701 |
Bernd Paysan <bernd.paysan@gmx.de> writes: > It has one, you need to start gforth-itc to use it (it's a lot easier > to single step through real indirect threaded code I think I tried it when I first started with gforth and it didn't work, but I may have done something wrong, so will try again. > Uh, then you don't use it right. I've been using gdb, and it is > awful! Yes, you can call functions. But that's about it. What you > can't easily do is to let these functions work together. Not sure what you mean about functions working together. gdb has been scriptable with a built-in macro language since the beginning, and more recently it's been scriptable in Python. I've sometimes wished it could compile and inject new code straight into the target, but the macros are often almost as good. I know that it does inject a fixed code template to call functions in the target. If you pass a string arg to a target function, gdb will inject code that mallocs the string in the target, which is kind of cool. >> Forth is much better (faster) at letting you rebuild the whole app >> very quickly. > Well, there's usually no point to rewrite a completely written program By "rebuild" I just meant recompile, not rewrite :O. I'll certainly credit Forth compilers with being fast. >> You are tasked with adding some new feature to the existing code, >> e.g. to make the tabs change color on a particular HTML event, or >> something like that. > A few lines of JavaScript would do that... if you could add that sort of > stuff right into Firefox. If you can't: Design mistake. You should be > able to do that. Yeah, that stuff may be in XUL now. So, pick a different feature: there are tons of requests in the Firefox bug tracker that really do require adding to the C++ code. > : ~bt~ ( -- ) store-backtrace dobacktrace nothrow ; > Insert wherever you like, and you get a full backtrace when the code > gets there. I don't think it's in the interactive spirit, to have the program spew millions of backtraces for later analysis. > Another nice debugging aid discussed recently is a debug shell: Yes, this is more like it. I had forgotten that discussion but should save the code fragment. It would be nice to put it into gforth as a standard feature.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2012-11-30 00:42 +0100 |
| Message-ID | <2329321.cK4k5JQJd8@sunwukong.fritz.box> |
| In reply to | #17722 |
Paul Rubin wrote: > Bernd Paysan <bernd.paysan@gmx.de> writes: >> It has one, you need to start gforth-itc to use it (it's a lot easier >> to single step through real indirect threaded code > > I think I tried it when I first started with gforth and it didn't > work, but I may have done something wrong, so will try again. Quite likely you didn't use gforth-itc, or your version is broken again ;-). Can happen, we don't test that very often. >> Uh, then you don't use it right. I've been using gdb, and it is >> awful! Yes, you can call functions. But that's about it. What you >> can't easily do is to let these functions work together. > > Not sure what you mean about functions working together. gdb has been > scriptable with a built-in macro language since the beginning, and > more > recently it's been scriptable in Python. Python may work. The built-in macro language is IMHO too restricted to be useful. Well, I usually don't need GDB to debug my programs, so maybe it's just that I'm no GDB expert ;-). > I've sometimes wished it > could compile and inject new code straight into the target, but the > macros are > often almost as good. I know that it does inject a fixed code > template > to call functions in the target. If you pass a string arg to a target > function, gdb will inject code that mallocs the string in the target, > which is kind of cool. Really? I would probably do all that on the stack, and not inject any code. Why should I inject code to achieve that? > By "rebuild" I just meant recompile, not rewrite :O. I'll certainly > credit Forth compilers with being fast. Ok, but I think I wanted to reply to the part where you said that rewriting Firefox in Forth would give a one million lines program or so... >> : ~bt~ ( -- ) store-backtrace dobacktrace nothrow ; >> Insert wherever you like, and you get a full backtrace when the code >> gets there. > > I don't think it's in the interactive spirit, to have the program spew > millions of backtraces for later analysis. Then turn it into a one-time executed function. : once ( -- ) here cell+ >r ]] true if [[ r> ]] Literal off [[ ; immediate : ~1bt~ ( -- ) ]] once ~bt~ then [[ ; immediate >> Another nice debugging aid discussed recently is a debug shell: > > Yes, this is more like it. I had forgotten that discussion but should > save the code fragment. It would be nice to put it into gforth as a > standard feature. It's in my experimental branch. Any objections to the name '??'? I like the name, you put it everywhere in your source code where you have "serious questions" ;-). I add an automatic insertion of ~~, so you get the prompt with source position and stack picture. Maybe the variant WTF?? should print a backtrace first, too ;-). And !!FIXME!! should throw an error code. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2012-11-29 19:57 -0800 |
| Message-ID | <7xwqx3d9ow.fsf@ruckus.brouhaha.com> |
| In reply to | #17733 |
Bernd Paysan <bernd.paysan@gmx.de> writes:
>> to call functions in the target. If you pass a string arg to a target
>> function, gdb will inject code that mallocs the string in the target,
>> which is kind of cool.
>
> Really? I would probably do all that on the stack, and not inject any
> code. Why should I inject code to achieve that?
Your function has signature
: func ( addr u -- n ) ... ;
and you want to run it from the debugger with the string "here is a
string" as an argument. To do that you have to allocate space in the
target, copy the string there, get the address, and pass the address and
length to func. To allocate space in the target you have to call the
target's allocator (malloc in the case of C) in the target process. To
make that happen, you have to inject code into the target to make the call.
> Then turn it into a one-time executed function.
> : ~1bt~ ( -- ) ]] once ~bt~ then [[ ; immediate
OK, but the debug shell where this can be called interactively seems a
lot more useful.
>>> Another nice debugging aid discussed recently is a debug shell: ...
>> It would be nice to put it into gforth as a standard feature.
> It's in my experimental branch. Any objections to the name '??'?
Oh cool. The name is of course up to you, but my preference would be
for something more descriptive, maybe "dbg-shell" to go with the
existing "dbg". Short non-alphabetic names are better for operations
done very frequently, or (like ~~) that you can put in a lot of places
without cluttering up the screen too much.
> Maybe the variant WTF?? should print a backtrace first, too ;-). And
> !!FIXME!! should throw an error code.
I'm used to being able to type "bt" to see a backtrace.
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <forthfreak@gmail.com> |
|---|---|
| Date | 2012-11-30 02:22 -0800 |
| Message-ID | <ad1a6af0-c710-40cb-a948-6eb79dd41087@c14g2000vbd.googlegroups.com> |
| In reply to | #17733 |
On Nov 29, 11:42 pm, Bernd Paysan <bernd.pay...@gmx.de> wrote: > > Maybe the variant WTF?? should print a backtrace first, too ;-). And > !!FIXME!! should throw an error code. > Now I've gone and sprayed coffee all over my monitor. You owe me a new screen!
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2012-11-30 18:47 +0100 |
| Message-ID | <6487975.qMkb6FSIW3@sunwukong.fritz.box> |
| In reply to | #17759 |
Mark Wills wrote: > On Nov 29, 11:42 pm, Bernd Paysan <bernd.pay...@gmx.de> wrote: >> >> Maybe the variant WTF?? should print a backtrace first, too ;-). And >> !!FIXME!! should throw an error code. >> > Now I've gone and sprayed coffee all over my monitor. You owe me a new > screen! Debugging Forth should be fun ;-). And: Never use the Internet while drinking. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2012-11-30 12:53 +0000 |
| Message-ID | <2012Nov30.135320@mips.complang.tuwien.ac.at> |
| In reply to | #17733 |
Bernd Paysan <bernd.paysan@gmx.de> writes:
>It's in my experimental branch. Any objections to the name '??'?
'??' is a word in Gray (optional grammar construct). So it would be
cumbersome to use the debug shell in programs that use Gray.
- 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 2012: http://www.euroforth.org/ef12/
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2012-11-30 18:33 +0100 |
| Message-ID | <2443869.OkVd0aBU7d@sunwukong.fritz.box> |
| In reply to | #17767 |
Anton Ertl wrote:
> Bernd Paysan <bernd.paysan@gmx.de> writes:
>>It's in my experimental branch. Any objections to the name '??'?
>
> '??' is a word in Gray (optional grammar construct). So it would be
> cumbersome to use the debug shell in programs that use Gray.
Ok, I go for ???, as it is the common head-scratching idiom in chats.
We have smileys now ( {: and :} for locals, [: and ;] for quotations),
so the language is open to chat idioms. Full debug shell with backtrace
and stack dump is WTF??, the prompt then should probably be :-P instead
of the standard dbg> of the debug-shell. BT gives a conventional
stackdump (also interactive), ~~BT source position+stack dump+backtrace,
~~1BT only once. The debug shell and ~~ can be used separately.
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2012-11-29 13:44 +0000 |
| Subject | Debuggers (Re: why bother with standards ?) |
| Message-ID | <2012Nov29.144443@mips.complang.tuwien.ac.at> |
| In reply to | #17663 |
"Elizabeth D. Rather" <erather@forth.com> writes:
>Some Forths have stepping debuggers. SwiftForth does, and the Open
>Firmware Standard specified one, although the implementors at IBM and
>Apple didn't value it enough to include it.
>
>It's helpful when the coding style is long sequences of code, or when
>you're trying to debug a whole application as a unit.
Not in my experience (and I debug whole programs as a unit).
Forward-stepping debuggers seduce you to waste your time in parts of
the code that often are not buggy, in the hope that the next step will
show you the bug; it's somewhat like a slot machine, only with time
instead of money. Backward stepping and running debuggers, now that
might be useful. Until we have them, I am using tracers, and can then
go forward and backwards in the output.
- 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 2012: http://www.euroforth.org/ef12/
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2012-11-29 09:36 -0800 |
| Subject | Re: Debuggers (Re: why bother with standards ?) |
| Message-ID | <7xy5hke2fq.fsf@ruckus.brouhaha.com> |
| In reply to | #17690 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: > Not in my experience (and I debug whole programs as a unit). > Forward-stepping debuggers seduce you to waste your time in parts of > the code that often are not buggy, in the hope that the next step will > show you the bug; it's somewhat like a slot machine, only with time > instead of money. Conditional breakpoints help a lot. Find a way to detect that the bug has happened (e.g. some variable that is supposed to always be even becomes odd), set a conditional breakpoint in the relevant loop to trap to the debugger if the number is odd, stop at the breakpoint, figure out what other combination of values made an odd number get stored at that point, set more conditional breakpoints to see how those values happened, etc. > Backward stepping and running debuggers, now that might be useful. > Until we have them, I am using tracers, and can then go forward and > backwards in the output. I've never used a backward debugger but they do sound useful. They've existed for a long time and I don't know why they haven't caught on much.
[toc] | [prev] | [next] | [standalone]
Page 6 of 9 — ← Prev page 1 2 3 4 5 [6] 7 8 9 Next page →
Back to top | Article view | comp.lang.forth
csiph-web