Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #19527 > unrolled thread
| Started by | Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> |
|---|---|
| First post | 2013-02-07 22:51 +0100 |
| Last post | 2013-02-10 00:06 -0500 |
| Articles | 20 on this page of 144 — 25 participants |
Back to article view | Back to comp.lang.forth
3D-graphics calculations using integers? Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-02-07 22:51 +0100
Re: 3D-graphics calculations using integers? "Paul E. Bennett" <Paul_E.Bennett@topmail.co.uk> - 2013-02-07 22:08 +0000
Re: 3D-graphics calculations using integers? AKE <assadebrahim2000@gmail.com> - 2013-02-07 14:32 -0800
Re: 3D-graphics calculations using integers? Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-02-07 23:40 +0100
Re: 3D-graphics calculations using integers? AKE <assadebrahim2000@gmail.com> - 2013-02-07 17:06 -0800
Re: 3D-graphics calculations using integers? AKE <assadebrahim2000@gmail.com> - 2013-02-07 17:07 -0800
Re: 3D-graphics calculations using integers? Pablo Hugo Reda <pabloreda@gmail.com> - 2013-02-07 14:36 -0800
Re: 3D-graphics calculations using integers? Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-02-07 23:46 +0100
Re: 3D-graphics calculations using integers? "Elizabeth D. Rather" <erather@forth.com> - 2013-02-07 16:38 -1000
Re: 3D-graphics calculations using integers? Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-02-08 10:22 +0100
Re: 3D-graphics calculations using integers? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-02-08 10:26 +0000
Re: 3D-graphics calculations using integers? "Elizabeth D. Rather" <erather@forth.com> - 2013-02-07 12:50 -1000
Re: 3D-graphics calculations using integers? Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-02-08 00:15 +0100
Re: 3D-graphics calculations using integers? kenney@cix.compulink.co.uk - 2013-02-08 14:51 -0600
Re: 3D-graphics calculations using integers? Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-02-08 22:02 +0100
Re: 3D-graphics calculations using integers? rickman <gnuarm@gmail.com> - 2013-02-07 18:21 -0500
Re: 3D-graphics calculations using integers? Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-02-08 00:30 +0100
Re: 3D-graphics calculations using integers? Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-02-08 00:39 +0100
Re: 3D-graphics calculations using integers? rickman <gnuarm@gmail.com> - 2013-02-07 18:51 -0500
Re: 3D-graphics calculations using integers? Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-02-08 12:28 +0100
Re: 3D-graphics calculations using integers? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-02-08 12:25 +0000
Re: 3D-graphics calculations using integers? Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-02-08 22:04 +0100
Re: 3D-graphics calculations using integers? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-02-09 15:27 +0000
Re: 3D-graphics calculations using integers? Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-02-09 16:36 +0100
Re: 3D-graphics calculations using integers? Mark Wills <forthfreak@gmail.com> - 2013-02-08 05:01 -0800
Re: 3D-graphics calculations using integers? Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-02-08 21:58 +0100
Re: 3D-graphics calculations using integers? Roberto Waltman <usenet@rwaltman.com> - 2013-02-08 10:08 -0500
Re: 3D-graphics calculations using integers? Roberto Waltman <usenet@rwaltman.com> - 2013-02-08 10:11 -0500
Re: 3D-graphics calculations using integers? Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-02-08 22:05 +0100
Re: 3D-graphics calculations using integers? Pablo Hugo Reda <pabloreda@gmail.com> - 2013-02-08 08:29 -0800
Re: 3D-graphics calculations using integers? Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-02-08 18:48 +0100
Re: 3D-graphics calculations using integers? rickman <gnuarm@gmail.com> - 2013-02-08 17:20 -0500
Re: 3D-graphics calculations using integers? Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-02-08 23:32 +0100
Re: 3D-graphics calculations using integers? rickman <gnuarm@gmail.com> - 2013-02-09 23:57 -0500
Re: 3D-graphics calculations using integers? "Elizabeth D. Rather" <erather@forth.com> - 2013-02-08 15:02 -1000
Re: 3D-graphics calculations using integers? Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-02-09 02:24 +0100
Re: 3D-graphics calculations using integers? "Elizabeth D. Rather" <erather@forth.com> - 2013-02-08 15:58 -1000
Re: 3D-graphics calculations using integers? Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-02-09 16:43 +0100
Re: 3D-graphics calculations using integers? "Elizabeth D. Rather" <erather@forth.com> - 2013-02-09 10:03 -1000
Re: 3D-graphics calculations using integers? "Ed" <invalid@nospam.com> - 2013-02-10 11:35 +1100
Re: 3D-graphics calculations using integers? humptydumpty <ouatubi@gmail.com> - 2013-02-08 23:48 -0800
Re: 3D-graphics calculations using integers? Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-02-09 16:37 +0100
OT: ANS Forth Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-02-09 17:27 +0100
Re: OT: ANS Forth "Elizabeth D. Rather" <erather@forth.com> - 2013-02-09 10:06 -1000
Re: OT: ANS Forth Paul Rubin <no.email@nospam.invalid> - 2013-02-09 12:26 -0800
Re: OT: ANS Forth Elizabeth D Rather <erather@forth.com> - 2013-02-09 14:38 -1000
Re: OT: ANS Forth "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2013-02-22 12:52 -0500
Re: OT: ANS Forth "Elizabeth D. Rather" <erather@forth.com> - 2013-02-22 09:25 -1000
Re: OT: ANS Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-02-10 08:15 -0600
Re: OT: ANS Forth Paul Rubin <no.email@nospam.invalid> - 2013-02-10 23:34 -0800
Re: OT: ANS Forth Josh Grams <josh@qualdan.com> - 2013-02-11 22:14 +0000
Re: OT: ANS Forth "Elizabeth D. Rather" <erather@forth.com> - 2013-02-11 13:34 -1000
Re: OT: ANS Forth "Ed" <invalid@nospam.com> - 2013-02-11 11:52 +1100
Re: OT: ANS Forth Paul Rubin <no.email@nospam.invalid> - 2013-02-10 17:11 -0800
Re: OT: ANS Forth "Elizabeth D. Rather" <erather@forth.com> - 2013-02-10 22:06 -1000
Re: OT: ANS Forth "Charles Childers" <crc@retroforth.org> - 2013-02-11 17:17 -0500
Re: OT: ANS Forth "Ed" <invalid@nospam.com> - 2013-02-13 11:42 +1100
Re: OT: ANS Forth "Elizabeth D. Rather" <erather@forth.com> - 2013-02-12 16:07 -1000
Re: OT: ANS Forth "Ed" <invalid@nospam.com> - 2013-02-15 09:42 +1100
Re: OT: ANS Forth Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-02-15 00:16 +0100
Re: OT: ANS Forth "Ed" <invalid@nospam.com> - 2013-02-17 16:05 +1100
Re: OT: ANS Forth Howerd <howerdo@yahoo.co.uk> - 2013-02-17 04:16 -0800
Re: OT: ANS Forth albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-02-17 13:12 +0000
Re: OT: ANS Forth Howerd <howerdo@yahoo.co.uk> - 2013-02-17 09:15 -0800
Re: OT: ANS Forth Brad Eckert <hwfwguy@gmail.com> - 2013-02-19 09:35 -0800
Re: OT: ANS Forth Andy Valencia <user@vsta.org> - 2013-02-19 19:25 +0000
Re: OT: ANS Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-02-19 15:35 -0600
Re: OT: ANS Forth Paul Rubin <no.email@nospam.invalid> - 2013-02-21 00:37 -0800
Re: OT: ANS Forth "Elizabeth D. Rather" <erather@forth.com> - 2013-02-20 23:07 -1000
Re: OT: ANS Forth Paul Rubin <no.email@nospam.invalid> - 2013-02-21 01:38 -0800
Re: OT: ANS Forth "Elizabeth D. Rather" <erather@forth.com> - 2013-02-21 08:50 -1000
Re: OT: ANS Forth Paul Rubin <no.email@nospam.invalid> - 2013-02-23 15:44 -0800
Re: OT: ANS Forth albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-02-24 03:41 +0000
Re: OT: ANS Forth Paul Rubin <no.email@nospam.invalid> - 2013-02-23 20:00 -0800
Re: OT: ANS Forth stephenXXX@mpeforth.com (Stephen Pelc) - 2013-02-24 13:49 +0000
Re: OT: ANS Forth albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-02-24 15:04 +0000
Re: OT: ANS Forth Paul Rubin <no.email@nospam.invalid> - 2013-02-24 14:52 -0800
Re: OT: ANS Forth albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-02-24 23:51 +0000
Re: OT: ANS Forth Paul Rubin <no.email@nospam.invalid> - 2013-02-24 16:23 -0800
Re: OT: ANS Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-02-21 03:55 -0600
Re: OT: ANS Forth "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2013-02-22 13:01 -0500
Re: OT: ANS Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-02-22 12:26 -0600
Re: OT: ANS Forth Andy Valencia <user@vsta.org> - 2013-02-19 21:54 +0000
Re: OT: ANS Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-02-19 18:21 -0600
Re: OT: ANS Forth Brad Eckert <hwfwguy@gmail.com> - 2013-02-20 08:45 -0800
Re: OT: ANS Forth Paul Rubin <no.email@nospam.invalid> - 2013-02-20 11:01 -0800
Re: OT: ANS Forth "Elizabeth D. Rather" <erather@forth.com> - 2013-02-20 11:25 -1000
Re: OT: ANS Forth Paul Rubin <no.email@nospam.invalid> - 2013-02-21 00:22 -0800
Re: OT: ANS Forth "Elizabeth D. Rather" <erather@forth.com> - 2013-02-20 22:50 -1000
Re: OT: ANS Forth Paul Rubin <no.email@nospam.invalid> - 2013-02-21 01:08 -0800
Re: OT: ANS Forth albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-02-21 12:42 +0000
Re: OT: ANS Forth Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-21 13:50 +0100
Re: OT: ANS Forth Paul Rubin <no.email@nospam.invalid> - 2013-02-21 09:36 -0800
Re: OT: ANS Forth Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-22 01:32 +0100
Re: OT: ANS Forth Paul Rubin <no.email@nospam.invalid> - 2013-02-23 00:50 -0800
Re: OT: ANS Forth Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-24 03:03 +0100
Re: OT: ANS Forth Brad Eckert <hwfwguy@gmail.com> - 2013-02-21 09:12 -0800
Re: OT: ANS Forth Paul Rubin <no.email@nospam.invalid> - 2013-02-23 00:38 -0800
Re: OT: ANS Forth "Elizabeth D. Rather" <erather@forth.com> - 2013-02-21 09:01 -1000
Re: OT: ANS Forth mhx@iae.nl (Marcel Hendrix) - 2013-02-22 00:05 +0200
Re: OT: ANS Forth Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-21 13:24 +0100
Re: OT: ANS Forth Paul Rubin <no.email@nospam.invalid> - 2013-02-21 09:33 -0800
Re: OT: ANS Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-02-21 13:04 -0600
Re: OT: ANS Forth Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-22 01:41 +0100
Re: OT: ANS Forth Paul Rubin <no.email@nospam.invalid> - 2013-02-23 00:31 -0800
Re: OT: ANS Forth "Paul E. Bennett" <Paul_E.Bennett@topmail.co.uk> - 2013-02-23 09:15 +0000
Re: OT: ANS Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-02-23 04:33 -0600
Re: OT: ANS Forth albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-02-23 13:49 +0000
Re: OT: ANS Forth Roberto Waltman <usenet@rwaltman.com> - 2013-02-23 13:35 -0500
Re: OT: ANS Forth Roberto Waltman <usenet@rwaltman.com> - 2013-02-23 13:46 -0500
Re: OT: ANS Forth Paul Rubin <no.email@nospam.invalid> - 2013-02-23 15:26 -0800
Re: OT: ANS Forth Roberto Waltman <usenet@rwaltman.com> - 2013-02-24 09:41 -0500
Re: OT: ANS Forth "Elizabeth D. Rather" <erather@forth.com> - 2013-02-21 09:09 -1000
Re: OT: ANS Forth Paul Rubin <no.email@nospam.invalid> - 2013-02-23 00:37 -0800
Re: OT: ANS Forth albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-02-23 13:57 +0000
Re: OT: ANS Forth "Elizabeth D. Rather" <erather@forth.com> - 2013-02-23 08:47 -1000
Re: OT: ANS Forth Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-22 01:27 +0100
Re: OT: ANS Forth Paul Rubin <no.email@nospam.invalid> - 2013-02-23 00:16 -0800
Re: OT: ANS Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-02-23 04:36 -0600
Re: OT: ANS Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-02-23 16:52 +0000
Re: OT: ANS Forth Paul Rubin <no.email@nospam.invalid> - 2013-02-23 12:39 -0800
Re: OT: ANS Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-02-25 16:27 +0000
Re: OT: ANS Forth "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2013-02-23 18:08 -0500
Re: OT: ANS Forth Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-24 02:20 +0100
Re: OT: ANS Forth Paul Rubin <no.email@nospam.invalid> - 2013-02-24 20:16 -0800
Re: OT: ANS Forth Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-25 16:04 +0100
Re: OT: ANS Forth albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-02-25 17:12 +0000
Re: OT: ANS Forth Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-25 20:44 +0100
Re: OT: ANS Forth Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-25 16:45 +0100
Re: OT: ANS Forth Andy Valencia <user@vsta.org> - 2013-02-24 02:09 +0000
Re: OT: ANS Forth Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-24 04:03 +0100
Re: OT: ANS Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-02-25 17:58 +0000
Re: OT: ANS Forth Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-25 20:57 +0100
Re: OT: ANS Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-03-02 16:43 +0000
Re: OT: ANS Forth Bernd Paysan <bernd.paysan@gmx.de> - 2013-03-02 18:14 +0100
Re: OT: ANS Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-03-03 13:56 +0000
Re: OT: ANS Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-02-24 03:45 -0600
Re: OT: ANS Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-02-13 04:12 -0600
Re: OT: ANS Forth stephenXXX@mpeforth.com (Stephen Pelc) - 2013-02-13 12:24 +0000
Re: OT: ANS Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-02-11 14:41 +0000
Re: OT: ANS Forth Andy Valencia <user@vsta.org> - 2013-02-11 19:44 +0000
Re: OT: ANS Forth albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-02-11 21:14 +0000
Re: 3D-graphics calculations using integers? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-02-09 18:14 -0600
Re: 3D-graphics calculations using integers? rickman <gnuarm@gmail.com> - 2013-02-10 00:06 -0500
Page 6 of 8 — ← Prev page 1 2 3 4 5 [6] 7 8 Next page →
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2013-02-21 13:24 +0100 |
| Subject | Re: OT: ANS Forth |
| Message-ID | <kg53mm$bf5$1@online.de> |
| In reply to | #19849 |
Brad Eckert wrote: > On Tuesday, February 19, 2013 2:54:54 PM UTC-7, Andy Valencia wrote: >> gcc, cross compilers, static analysis, gdb and slave-target gdb. >> > The last time I explained Forth to a hardware SOC designer, he asked me > about breakpoints. I told him there are no breakpoints. You debug the > system in situ, with the whole thing running. That threw him for a loop, > because breakpoints and single stepping were all he knew. For that reason, the b16 debugger got breakpoint and single stepping (one breakpoint is actually enough). And memory inspection. That's the thing I use. Others might actually use the breakpoint and single stepping, but then, I didn't test that enough to be sure all bugs are out ;-). We also have a single stepping debugger in Gforth, which didn't work for a release or two, which we didn't notice at all. Single step debugging is a waste of time. > You can add instrumentation to C code, but it's not part of C and you have > to do it yourself. The main problem with instrumentation to C code is that it takes so long to recompile. > Otherwise, you have to do the usual "kill the patient > and do an autopsy" breakpoint-based debugging. The C IDEs are getting > better, but C projects are still painful to watch. When we started Gforth, I had used GDB to debug the C side. It turned out to be completely impossible to use it. So what I added next is generated instrumentation code (we don't actually write the engine in C, we write it in "vmgen", a language that is translated to C and contains C snippets). Then debugging became possible. Actually, a hardware SoC designer should know the advantage of just recording the values of interest, and looking at them afterwards, as that's how you debug Verilog or VHDL. Yes, they have single-step breakpoint debuggers as well, but nobody uses them. -- 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 | 2013-02-21 09:33 -0800 |
| Subject | Re: OT: ANS Forth |
| Message-ID | <7xa9qx4lmi.fsf@ruckus.brouhaha.com> |
| In reply to | #19872 |
Bernd Paysan <bernd.paysan@gmx.de> writes: > The main problem with instrumentation to C code is that it takes so long to > recompile. Suspend disbelief and imagine that the recompilation time is zero. Unfortunately the problem you're debugging only shows up when the program has been running for at least 5 minutes and maybe you have had to enter some input or muck with the hardware manually during the 5 minutes. So you instrument some value X, recompile instantly, run 5 minutes and see that the traced X now makes you want to know the value of Y. You instrument Y, recompile, repeat for Z, etc. It seems a lot easier to set a breakpoint when the problem happens and then interactively probe around the image. I would have thought this interactivity was in the Forth spirit. There's still some part of the picture that I'm missing.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2013-02-21 13:04 -0600 |
| Subject | Re: OT: ANS Forth |
| Message-ID | <BIOdneMR_PUj8rvMnZ2dnUVZ_tOdnZ2d@supernews.com> |
| In reply to | #19881 |
Paul Rubin <no.email@nospam.invalid> wrote: > Bernd Paysan <bernd.paysan@gmx.de> writes: >> The main problem with instrumentation to C code is that it takes so >> long to recompile. > > Suspend disbelief and imagine that the recompilation time is zero. > Unfortunately the problem you're debugging only shows up when the > program has been running for at least 5 minutes and maybe you have had > to enter some input or muck with the hardware manually during the 5 > minutes. So you instrument some value X, recompile instantly, run 5 > minutes and see that the traced X now makes you want to know the value > of Y. You instrument Y, recompile, repeat for Z, etc. It seems a lot > easier to set a breakpoint when the problem happens and then > interactively probe around the image. No chance. Think about the application area. Much of Forth's history and present use is in robotics. You have a robot arm. Each axis has a PID task running. These tasks either hold the axis steady, or if a control task tells it to move, moves it. Consider, just for a moment, what happens if you stop PID tasks to single-step through some code or inspect a value. If you need to know the value of Y you can just look at it; if it's changing rapidly you need a trace. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2013-02-22 01:41 +0100 |
| Subject | Re: OT: ANS Forth |
| Message-ID | <kg6eqv$9f1$1@online.de> |
| In reply to | #19885 |
Andrew Haley wrote: > No chance. Think about the application area. Much of Forth's history > and present use is in robotics. Good example. > You have a robot arm. Each axis has a PID task running. These tasks > either hold the axis steady, or if a control task tells it to move, > moves it. Consider, just for a moment, what happens if you stop PID > tasks to single-step through some code or inspect a value. > > If you need to know the value of Y you can just look at it; if it's > changing rapidly you need a trace. And what's worse: If the robot goes wild, you instantly push the red button, before it damages something. This one powers the robot off (including controllers). If you didn't trace before, you have nothing. -- 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 | 2013-02-23 00:31 -0800 |
| Subject | Re: OT: ANS Forth |
| Message-ID | <7xehg7ph2g.fsf@ruckus.brouhaha.com> |
| In reply to | #19885 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes: > You have a robot arm. Each axis has a PID task running. These tasks > either hold the axis steady, or if a control task tells it to move, > moves it. Consider, just for a moment, what happens if you stop PID > tasks to single-step through some code or inspect a value. Disclosure: I've never worked on hard-real-time stuff, so maybe my picture of this kind of coding is unrealistic. But I'd imagine using some combination of: 1) stopping the arm when it misbehaves, so that debugger inspection happens with the arm not moving, and/or 2) using a simulator instead of the actual robot mechanism for debugging the control software, to the extent possible, 3) modelling the entire system in something like Matlab before even messing with the physical robot or with fixed-point Forth code. That gives you something to compare your Forth program's behavior against. > If you need to know the value of Y you can just look at it; if it's > changing rapidly you need a trace. OK, you've got a trace: you've recorded all the sensor readings and motor signals while the arm was running, including when it started misbehaving after some particular motions. Your Forth algorithm's output are reasonably close to the more precise Matlab output over most of the test, but they go seriously wrong at a particular place. So now you've got a misbehaving, serial numerical algorithm to debug, completely separated from the realtime aspect. It is crunching a bunch of numbers and going wrong someplace. Unless the calculation was horribly complex, I'd tend to approach that sort of problem by single stepping the program and observing the intermediate results until I saw something go wrong. Another place where I find single stepping incredibly useful is in just understanding what a big unfamiliar piece of code is doing. E.g. the program is building a certain output and I can see where the result becomes available, and I have to add a feature somewhere before that. How did the output get to be what it is? I send in some input, and start single stepping, observing, interacting, exploring. The old Lisp Machine environments were fantastically good at this sort of thing, one reason I regret never having used them. It sounds very much in the spirit of Forth as well, so I'm really surprised that the Forthers here aren't embracing it.
[toc] | [prev] | [next] | [standalone]
| From | "Paul E. Bennett" <Paul_E.Bennett@topmail.co.uk> |
|---|---|
| Date | 2013-02-23 09:15 +0000 |
| Subject | Re: OT: ANS Forth |
| Message-ID | <aorfprFmep5U1@mid.individual.net> |
| In reply to | #19935 |
Paul Rubin wrote: > Disclosure: I've never worked on hard-real-time stuff, so maybe my > picture of this kind of coding is unrealistic. But I'd imagine using > some combination of: From one who has then... > 1) stopping the arm when it misbehaves, so that debugger inspection > happens with the arm not moving, and/or > > 2) using a simulator instead of the actual robot mechanism for debugging > the control software, to the extent possible, In a robotic application it is usual to have fully resolved all the motion issues before one lets the control system loose on the mechanical bit. This is usually done with an appropriate level of bench testing. So your number 2 option is often the more likely during development. However, if you notice problems after the control system and arm are coupled you take a trace of all the possible data you can grab and return to the simulator to try and re-produce it there. Of course, not all hard real-time issues are to do with robotics. Sensing activities for which one needs to raise alarms in order to preserve life are extremely hard real-time issues. Getting a very time dependent series of readings from sensors and ensuring that all values are within the right zone at the right timing is an extremely vexing task and only running code at full speed and tracing the data streams will do (experience from a medical device project). > 3) modelling the entire system in something like Matlab before even > messing with the physical robot or with fixed-point Forth code. That > gives you something to compare your Forth program's behavior against. Yes. I quite often use a simple spreadsheet for such tasks as well. >> If you need to know the value of Y you can just look at it; if it's >> changing rapidly you need a trace. > > OK, you've got a trace: you've recorded all the sensor readings and > motor signals while the arm was running, including when it started > misbehaving after some particular motions. Your Forth algorithm's > output are reasonably close to the more precise Matlab output over most > of the test, but they go seriously wrong at a particular place. So now > you've got a misbehaving, serial numerical algorithm to debug, > completely separated from the realtime aspect. It is crunching a bunch > of numbers and going wrong someplace. You can "chunk-run" the code by inserting a ".S KEY DROP" sequence into suitable places in the code. This allows most of the code to run at full speed but gives you points at which you have a bunch of stacked data values available to examine before you step on for the next chunk. Even with the code running the real machine this sort of thing still assists in finding the reasons for weird motions (even if they are actually mechanical in nature). > Unless the calculation was horribly complex, I'd tend to approach that > sort of problem by single stepping the program and observing the > intermediate results until I saw something go wrong. The most complex calculations are always reducible to a series of smaller and much simpler ones. Those issues are the ones to be rid of before attaching to the machine. Hence the bench-test and simulator run requirements. > Another place where I find single stepping incredibly useful is in just > understanding what a big unfamiliar piece of code is doing. E.g. the > program is building a certain output and I can see where the result > becomes available, and I have to add a feature somewhere before that. > How did the output get to be what it is? I send in some input, > and start single stepping, observing, interacting, exploring. If this is from the perspective of having code and no source, then I will agree that single stepping the machine can help but it can also hinder in so many ways, especially with interrupts coming in that need quick responses. > The old Lisp Machine environments were fantastically good at this sort > of thing, one reason I regret never having used them. It sounds very > much in the spirit of Forth as well, so I'm really surprised that the > Forthers here aren't embracing it. We have our ways. -- ******************************************************************** 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 | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2013-02-23 04:33 -0600 |
| Subject | Re: OT: ANS Forth |
| Message-ID | <XrWdnWVc28qTBrXMnZ2dnUVZ_sSdnZ2d@supernews.com> |
| In reply to | #19935 |
Paul Rubin <no.email@nospam.invalid> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >> You have a robot arm. Each axis has a PID task running. These tasks >> either hold the axis steady, or if a control task tells it to move, >> moves it. Consider, just for a moment, what happens if you stop PID >> tasks to single-step through some code or inspect a value. > > Disclosure: I've never worked on hard-real-time stuff, so maybe my > picture of this kind of coding is unrealistic. But I'd imagine using > some combination of: > > 1) stopping the arm when it misbehaves, so that debugger inspection > happens with the arm not moving, and/or You can't really just "stop" the arm: it requires an active servo to hold it in place. > 2) using a simulator instead of the actual robot mechanism for debugging > the control software, to the extent possible, > > 3) modelling the entire system in something like Matlab before even > messing with the physical robot or with fixed-point Forth code. That > gives you something to compare your Forth program's behavior against. I have very little confidence in such simulation: the right way, for me, has always been to test and develop on real hardware, for obvious reasons. Sure, if the system you're controlling is very unusual or expensive, you might have to simulate it, but you are going to need the best interactive tools when integrating the system. Unforthly programming practice often involves simulations because it's too hard to debug on the real system. >> If you need to know the value of Y you can just look at it; if it's >> changing rapidly you need a trace. > > OK, you've got a trace: you've recorded all the sensor readings and > motor signals while the arm was running, including when it started > misbehaving after some particular motions. Your Forth algorithm's > output are reasonably close to the more precise Matlab output over > most of the test, but they go seriously wrong at a particular place. > So now you've got a misbehaving, serial numerical algorithm to > debug, completely separated from the realtime aspect. It is > crunching a bunch of numbers and going wrong someplace. > > Unless the calculation was horribly complex, I'd tend to approach that > sort of problem by single stepping the program and observing the > intermediate results until I saw something go wrong. Sure, but that's the *easiest* kind of proble to debug. The hard thing to debug is complex interactions in real time. > Another place where I find single stepping incredibly useful is in > just understanding what a big unfamiliar piece of code is doing. > E.g. the program is building a certain output and I can see where > the result becomes available, and I have to add a feature somewhere > before that. How did the output get to be what it is? I send in > some input, and start single stepping, observing, interacting, > exploring. > > The old Lisp Machine environments were fantastically good at this > sort of thing, one reason I regret never having used them. It > sounds very much in the spirit of Forth as well, so I'm really > surprised that the Forthers here aren't embracing it. There's nothing wrong with stopping a system and stepping it. You can do that with Forth, of course, but it's not the default way to interact with a system. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2013-02-23 13:49 +0000 |
| Subject | Re: OT: ANS Forth |
| Message-ID | <5128c903$0$6089$e4fe514c@dreader36.news.xs4all.nl> |
| In reply to | #19935 |
In article <7xehg7ph2g.fsf@ruckus.brouhaha.com>, Paul Rubin <no.email@nospam.invalid> wrote: >Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >> You have a robot arm. Each axis has a PID task running. These tasks >> either hold the axis steady, or if a control task tells it to move, >> moves it. Consider, just for a moment, what happens if you stop PID >> tasks to single-step through some code or inspect a value. > >Disclosure: I've never worked on hard-real-time stuff, so maybe my >picture of this kind of coding is unrealistic. But I'd imagine using >some combination of: > >1) stopping the arm when it misbehaves, so that debugger inspection >happens with the arm not moving, and/or Your lack of experience shows. My most time demanding real time bug involved the control of a carriage with a mirror for Paranal ESO space observatory. The bug was that while moving at 1 mm/second, the carriage suddenly started moving at top speed, running into the cables a few meters along the test rail. So much for stopping movement, at the moment it misbehaves. > >2) using a simulator instead of the actual robot mechanism for debugging >the control software, to the extent possible, > >3) modelling the entire system in something like Matlab before even >messing with the physical robot or with fixed-point Forth code. That >gives you something to compare your Forth program's behavior against. This was done, and as you guessed, it moved correctly with 1 mm/sec until ... > >> If you need to know the value of Y you can just look at it; if it's >> changing rapidly you need a trace. > >OK, you've got a trace: you've recorded all the sensor readings and >motor signals while the arm was running, including when it started >misbehaving after some particular motions. Your Forth algorithm's >output are reasonably close to the more precise Matlab output over most >of the test, but they go seriously wrong at a particular place. So now >you've got a misbehaving, serial numerical algorithm to debug, >completely separated from the realtime aspect. It is crunching a bunch >of numbers and going wrong someplace. This is not typical where real time errors are in. You can waste a terrible amount of time along that road. Groetjes Albert -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | Roberto Waltman <usenet@rwaltman.com> |
|---|---|
| Date | 2013-02-23 13:35 -0500 |
| Subject | Re: OT: ANS Forth |
| Message-ID | <it2ii8po4rgms0nbqtpaioofipu65cqr6j@4ax.com> |
| In reply to | #19935 |
Paul Rubin wrote: >... >The old Lisp Machine environments were fantastically good at this sort >of thing, one reason I regret never having used them. You stil got a chance: http://www.heeltoe.com/retro/mit/mit_cadr_lmss.html -- Roberto Waltman [ Please reply to the group, return address is invalid ]
[toc] | [prev] | [next] | [standalone]
| From | Roberto Waltman <usenet@rwaltman.com> |
|---|---|
| Date | 2013-02-23 13:46 -0500 |
| Subject | Re: OT: ANS Forth |
| Message-ID | <ki3ii8thihq0rncbcgslecnoeh6nmp40r3@4ax.com> |
| In reply to | #19953 |
n.com> wrote: >Paul Rubin wrote: >>... >>The old Lisp Machine environments were fantastically good at this sort >>of thing, one reason I regret never having used them. > >You stil got a chance: >http://www.heeltoe.com/retro/mit/mit_cadr_lmss.html Sorry, wrong link. http://www.unlambda.com/cadr/index.html -- Roberto Waltman [ Please reply to the group, return address is invalid ]
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2013-02-23 15:26 -0800 |
| Subject | Re: OT: ANS Forth |
| Message-ID | <7xsj4md33r.fsf@ruckus.brouhaha.com> |
| In reply to | #19954 |
Roberto Waltman <usenet@rwaltman.com> writes: > Sorry, wrong link. > http://www.unlambda.com/cadr/index.html Yeah, I know about that and want to try it out sometime. It looks difficult to get running though, and even with it working, using those systems required a lot of knowledge. Unfortunately the whole approach is obsolete by now, to the point that spending a lot of time getting familiar with it doesn't seem worthwhile. Do you know if anyone actually ran the CADR emulator for reasonably practical computing purposes on any regular basis? I do know that multiple people used emulated PDP-10's routinely.
[toc] | [prev] | [next] | [standalone]
| From | Roberto Waltman <usenet@rwaltman.com> |
|---|---|
| Date | 2013-02-24 09:41 -0500 |
| Subject | Re: OT: ANS Forth |
| Message-ID | <g89ki8l8jct65aelu04cstdpfavbc4mpsk@4ax.com> |
| In reply to | #19967 |
Paul Rubin wrote: >Do you know if anyone actually ran the CADR emulator for reasonably >practical computing purposes on any regular basis? I do know that >multiple people used emulated PDP-10's routinely. PDP-10's, PDP-11's, IBM-360/370's, VAX/VMS and Alphas. But no, never saw a reference to emulated LISP machines in actual use. -- Roberto Waltman [ Please reply to the group, return address is invalid ]
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2013-02-21 09:09 -1000 |
| Subject | Re: OT: ANS Forth |
| Message-ID | <0YqdnYHD84Zh7bvMnZ2dnUVZ_s6dnZ2d@supernews.com> |
| In reply to | #19881 |
On 2/21/13 7:33 AM, Paul Rubin wrote: > Bernd Paysan <bernd.paysan@gmx.de> writes: >> The main problem with instrumentation to C code is that it takes so long to >> recompile. > > Suspend disbelief and imagine that the recompilation time is zero. > Unfortunately the problem you're debugging only shows up when the > program has been running for at least 5 minutes and maybe you have had > to enter some input or muck with the hardware manually during the 5 > minutes. So you instrument some value X, recompile instantly, run 5 > minutes and see that the traced X now makes you want to know the value > of Y. You instrument Y, recompile, repeat for Z, etc. It seems a lot > easier to set a breakpoint when the problem happens and then > interactively probe around the image. I would have thought this > interactivity was in the Forth spirit. There's still some part of the > picture that I'm missing. > It's certainly easy to make a breakpoint in Forth if you want to. Just put QUIT at the point where you want to stop (or that plus some displays, or something). It's also easy to instrument variables of interest. It doesn't require any kind of external debugger. And having stopped, you can examine your environment, etc. How much of the context you save & restore is up to you. But my point is that if you do this, you would then proceed to continue testing by typing words, rather than single-stepping instructions. And there's no external program involved. 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 | 2013-02-23 00:37 -0800 |
| Subject | Re: OT: ANS Forth |
| Message-ID | <7xa9qvpgsp.fsf@ruckus.brouhaha.com> |
| In reply to | #19886 |
"Elizabeth D. Rather" <erather@forth.com> writes: > It's certainly easy to make a breakpoint in Forth if you want to. Just > put QUIT at the point where you want to stop (or that plus some > displays, or something). Yes, I had a discussion with Bernd about that a while back, and he supplied a nice recipe, now called ???. > you would then proceed to continue testing by typing > words, rather than single-stepping instructions. And there's no > external program involved. But it sounds like I'd basically be typing in the contents of the calling word, devoting attention to advancing one word at a time and possibly making errors, instead of just hitting the return key repeatedly.while watching the program's progress. It sounds less attractive.
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2013-02-23 13:57 +0000 |
| Subject | Re: OT: ANS Forth |
| Message-ID | <5128cab3$0$6089$e4fe514c@dreader36.news.xs4all.nl> |
| In reply to | #19936 |
In article <7xa9qvpgsp.fsf@ruckus.brouhaha.com>, Paul Rubin <no.email@nospam.invalid> wrote: >"Elizabeth D. Rather" <erather@forth.com> writes: >> It's certainly easy to make a breakpoint in Forth if you want to. Just >> put QUIT at the point where you want to stop (or that plus some >> displays, or something). > >Yes, I had a discussion with Bernd about that a while back, and he >supplied a nice recipe, now called ???. > >> you would then proceed to continue testing by typing >> words, rather than single-stepping instructions. And there's no >> external program involved. > >But it sounds like I'd basically be typing in the contents of the >calling word, devoting attention to advancing one word at a time and >possibly making errors, instead of just hitting the return key >repeatedly.while watching the program's progress. It sounds less >attractive. Well, let's see. Why not make a word for that. A bit system dependant, but this is the idea: :I single-step BEGIN R> $@ >R EXECUTE KEY &Q = UNTIL ; 'single-step alias ss :I is like : but ensures that this code is inlined (to not sidetrack the issue). (You can make it more advanced by allowing a "step into" on some other key.) Groetjes Albert -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2013-02-23 08:47 -1000 |
| Subject | Re: OT: ANS Forth |
| Message-ID | <Jrmdne9Zf8Mzk7TMnZ2dnUVZ_h-dnZ2d@supernews.com> |
| In reply to | #19936 |
On 2/22/13 10:37 PM, Paul Rubin wrote: > "Elizabeth D. Rather" <erather@forth.com> writes: >> It's certainly easy to make a breakpoint in Forth if you want to. Just >> put QUIT at the point where you want to stop (or that plus some >> displays, or something). > > Yes, I had a discussion with Bernd about that a while back, and he > supplied a nice recipe, now called ???. > >> you would then proceed to continue testing by typing >> words, rather than single-stepping instructions. And there's no >> external program involved. > > But it sounds like I'd basically be typing in the contents of the > calling word, devoting attention to advancing one word at a time and > possibly making errors, instead of just hitting the return key > repeatedly.while watching the program's progress. It sounds less > attractive. Not really. The thing is, you can look at the code and tell where the trouble spots are likely to be. Remember, these words are (should be) really short. You don't need to worry about DUP and SWAP doing the wrong thing, you concentrate on setting up the stack and calling the word most likely to return the wrong answer. In other words, rather than a mechanical exercise in linear stepping, the system facilitates the use of your intelligence and understanding of the program to home in on the bug. 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 | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2013-02-22 01:27 +0100 |
| Subject | Re: OT: ANS Forth |
| Message-ID | <kg6e1k$91u$1@online.de> |
| In reply to | #19881 |
Paul Rubin wrote: > Bernd Paysan <bernd.paysan@gmx.de> writes: >> The main problem with instrumentation to C code is that it takes so long >> to recompile. > > Suspend disbelief and imagine that the recompilation time is zero. > Unfortunately the problem you're debugging only shows up when the > program has been running for at least 5 minutes and maybe you have had > to enter some input or muck with the hardware manually during the 5 > minutes. Yeah, you can always put up a straw man. Reality is that the recompilation time of a C program is 5 minutes, and the bug shows up almost instantly. That's 99% of the cases. Reality is that recompilation in the C world takes longer than getting to the bug. In the Forth world, it's the other way round. Yeah, you should automate your test cases that trigger the bug, too. In any case, if anything takes longer than 3 seconds, your flow is broken. Your mind wanders off, you play a round of Facebook game in between before the compilation finishs (when it takes 5 minutes) or whatever. Forth style debugging is intense work, you don't get any such breaks in the middle of coding. You do your breaks between coding rounds. http://xkcd.com/303/ These are definitely *not* two Forth programmers at work. The net2o tests I'm running are written in such a way that they finish in the order of 3 seconds (with lower bandwidth, I just transmit less data). That's on purpose. > So you instrument some value X, recompile instantly, run 5 > minutes and see that the traced X now makes you want to know the value > of Y. You instrument Y, recompile, repeat for Z, etc. It seems a lot > easier to set a breakpoint when the problem happens and then > interactively probe around the image. You don't even know before "when the problem happens". It might happen at run 300 of a particular function, and you better save important information *before* it goes wrong. A typical bug situation is that a variable is set to a wrong value, and you don't know how it got there and why it was miscalculated. So what you need to do is to observe what's written into the variable. After you found out who's the culprit, you can investigate what's going wrong with the calculation there. The tool I'm using for that is usually Gforth's ~~, it just prints out what's on the stack, and where in the sourcecode this print is located. We have now this ??? breakpoint (which opens up an interactive command line when encountered), but I've still not used it, apart from testing it. > I would have thought this > interactivity was in the Forth spirit. There's still some part of the > picture that I'm missing. Yes, definitely. Recompile instantly is part of the interactivity. It's not always entering things on the command line, though that certainly is also part of the debugging cycle, especially the early part - when you write a new word, you test it that way. It's not difficult to get a single function to work, the stuff that requires more analysis is when serveral things need to play together nicely. Sometimes they don't, most times they do. That's when the C guys already went home, and then we have all those crappy software which just works most of the time, and "did you try to turn it off and on again" fixes the problem. -- 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 | 2013-02-23 00:16 -0800 |
| Subject | Re: OT: ANS Forth |
| Message-ID | <7xip5jphqn.fsf@ruckus.brouhaha.com> |
| In reply to | #19894 |
Bernd Paysan <bernd.paysan@gmx.de> writes: > Yeah, you can always put up a straw man. Reality is that the recompilation > time of a C program is 5 minutes, The 1980's called and they want their VAX back ;-). Today's computers are a lot faster and compiling is quick unless the program is huge. Some advice if you haven't done this yet: buy an SSD for your computer. It changes the whole computing experience drastically and for the better. > and the bug shows up almost instantly. Welcome to the world of intermittent bugs, or bugs that are triggered by the program interacting with slow external systems that you don't control. > Yeah, you should automate your test cases that trigger the bug, too. That's real nice, except it means you have to simulate the weird external systems, including their undocumented bugs that are causing your own program to fail. In reality there's not time in the project schedule for that even if you can figure out how to make the simulation accurate enough. You instead have to keep running actual tests that involve pressing a lot of buttons on the external device, and those are time-consuming. Sometimes they also use up consumable materials that could in principle be expensive, so that by itself is a reason to not want to run the tests too many times. The thing I worked on recently consume materials itself, though they were cheap enough that the expenditures on them wasn't a significant concern. > A typical bug situation is that a variable is set to a wrong value, and you > don't know how it got there and why it was miscalculated. So what you need > to do is to observe what's written into the variable. After you found out > who's the culprit, you can investigate what's going wrong with the > calculation there. > > The tool I'm using for that is usually Gforth's ~~, it just prints out > what's on the stack, and where in the sourcecode this print is located. You might have to run that ~~ millions of times before the variable is set to the wrong value. Do you do something to locate the change afterwards? With gdb I'd just say "watch <variable>" and gdb stops the program when the variable changes. It either sets a hardware watchpoint (if one is available), or single steps the program until it sees the change.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2013-02-23 04:36 -0600 |
| Subject | Re: OT: ANS Forth |
| Message-ID | <XrWdnWRc28peBrXMnZ2dnUVZ_sSdnZ2d@supernews.com> |
| In reply to | #19934 |
Paul Rubin <no.email@nospam.invalid> wrote: > With gdb I'd just say "watch <variable>" and gdb stops the program when > the variable changes. It either sets a hardware watchpoint (if one is > available), or single steps the program until it sees the change. For goodness' sake, this is Forth! Just think for a moment about how easy it is to create watchpoints. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2013-02-23 16:52 +0000 |
| Subject | Re: OT: ANS Forth |
| Message-ID | <2013Feb23.175250@mips.complang.tuwien.ac.at> |
| In reply to | #19934 |
Paul Rubin <no.email@nospam.invalid> writes:
>Bernd Paysan <bernd.paysan@gmx.de> writes:
>> Yeah, you can always put up a straw man. Reality is that the recompilation
>> time of a C program is 5 minutes,
>
>The 1980's called and they want their VAX back ;-). Today's computers
>are a lot faster and compiling is quick unless the program is huge.
Somehow compilation never really gets faster. In the early 90s
building Gforth took a few minutes, and now, 20 years later, it still
does. Is Gforth huge? Not compared to most other programs. Ok, if
you change some piece of C code, you don't spend the same time as when
building from scratch, but it's still often not that much less.
Anyway, even for programs that compile very fast, the C way takes more
steps and is therefore less convenient.
>Some advice if you haven't done this yet: buy an SSD for your computer.
>It changes the whole computing experience drastically and for the
>better.
Maybe if you have an OS that does not know how to cache files in RAM.
>> and the bug shows up almost instantly.
>
>Welcome to the world of intermittent bugs, or bugs that are triggered by
>the program interacting with slow external systems that you don't control.
That's certainly where a debugger like gdb shines. At least if your
goal is wasting time.
>> The tool I'm using for that is usually Gforth's ~~, it just prints out
>> what's on the stack, and where in the sourcecode this print is located.
>
>You might have to run that ~~ millions of times before the variable
>is set to the wrong value. Do you do something to locate the change
>afterwards?
I typically use Emacs' regexp search to scan through the trace,
typically starting from the end; other tools are also possible.
>With gdb I'd just say "watch <variable>" and gdb stops the program when
>the variable changes.
And then I have to search for the next change of that variable, and
the next, until I find the one that's wrong. A big waste of time if
the decisive change is after 1000 changes. People don't use printf
debugging in C because they don't know gdb, but because they know it.
~~ is just a more convenient variant of printf debugging.
>It either sets a hardware watchpoint (if one is
>available), or single steps the program until it sees the change.
And dog-slow if single-stepping is needed. Not really a good idea for
your program that takes 5 minutes to reach the interesting place when
running at full speed.
- 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 2013: http://www.euroforth.org/ef13/
[toc] | [prev] | [next] | [standalone]
Page 6 of 8 — ← Prev page 1 2 3 4 5 [6] 7 8 Next page →
Back to top | Article view | comp.lang.forth
csiph-web