1. Hangup
- Posted by "Wallace B. Riley" <wryly at MINDSPRING.COM>
Jun 16, 1998
-
Last edited Jun 17, 1998
Nice try, fellas, but it doesn't work. See my earlier message today about
unwarranted assumptions.
Bob Pilkington: My program has several infinite loops in it, put there on
purpose. They begin with 'while 1 do' and every loop has an 'exit' in it.
The hangup occurred before any of these could have been encountered.
You said the 'allow_break(1)' is the default. I inserted it as the third
line in the main routine, right after the line that identifies the routine
and a 'clear_screen' command. If it is the default, I could have cleared
the hangup with a 'Ctrl-C' from the keyboard, but I couldn't. (The hangup
came immediately after the first request for keyboard input. I suspect it
is something sneaky dreamed up by one of those treacherous 'get' statements.)
I already have 'include machine.e' in the program. I *do* read the manual
and I *did* see this specified.
Art Adamson: You said the correct 'include' file is 'file.e'. You cited
the 2.0 manual. You are assuming that I have Euphoria 2.0; I don't have
it. I have Windows 3.1. Rob Craigsaid I had to have Windows 95 before I
could get Eu 2.0. I'm not going to buy Windows 95 until I know what Windows
98 will require as a prerequisite.
Alan Tu: You made the same assumption as Art. Tsk tsk tsk.
Graeme: Your suggestion, to print something on the screen so that I can see
what's happening if anything, is a possibility. I haven't tried it yet, and
frankly I'm dubious, because of the location of the hangup. I suspect that
the program will never get to the special-print statement.
Thanks again, and no hard feelings.
Wally Riley
wryly at mindspring.com
2. Re: Hangup
At 10:03 PM 6/16/98 -0400, Wally wrote:
>Nice try, fellas, but it doesn't work. See my earlier message today about
>unwarranted assumptions.
>
>Bob Pilkington: My program has several infinite loops in it, put there on
>purpose. They begin with 'while 1 do' and every loop has an 'exit' in it.
>The hangup occurred before any of these could have been encountered.
>You said the 'allow_break(1)' is the default. I inserted it as the third
>line in the main routine, right after the line that identifies the routine
>and a 'clear_screen' command. If it is the default, I could have cleared
>the hangup with a 'Ctrl-C' from the keyboard, but I couldn't. (The hangup
>came immediately after the first request for keyboard input. I suspect it
>is something sneaky dreamed up by one of those treacherous 'get' statements.)
>Graeme: Your suggestion, to print something on the screen so that I can see
>what's happening if anything, is a possibility. I haven't tried it yet, and
>frankly I'm dubious, because of the location of the hangup. I suspect that
>the program will never get to the special-print statement.
I am assuming from this message that you still don't
know *exactly* where the problem is. This *has* to
be your first step. If you are suspicious of a particular
line put:
puts(1,"Before\n")
before the line and:
puts(1,"After\n")
After the line.
If you see "Before" but not "after" then your
program is hanging on that line. If you see
both massages (as I suspect) then you will
have to look elsewhere.
As somebody mentioned in one of the replys, CTRL-C
will only be caught when you are checking for keyboard
input. Which treacherous get statements are you talking
about? Where is the input coming from?
I suggest putting:
if get_key() then end if
inside all "while 1 do" loops to ensure
CTRL-C is caught.
Putting any kind of print to the screen inside
these loops will also tell you straight away
whether the program is actually hanging, or is
stuck in an infinate loop (you will get your
message printed repeatedly if it is stuck in a
loop).
HTH,
Graeme.
----------------------------------------------------
3. Re: Hangup
At 02:11 PM 6/17/98 +1000, you wrote:
>At 10:03 PM 6/16/98 -0400, Wally wrote:
>
>>Nice try, fellas, but it doesn't work. See my earlier message today about
>>unwarranted assumptions.
>>
>>Bob Pilkington: My program has several infinite loops in it, put there on
>>purpose. They begin with 'while 1 do' and every loop has an 'exit' in it.
>>The hangup occurred before any of these could have been encountered.
>
>>You said the 'allow_break(1)' is the default. I inserted it as the third
>>line in the main routine, right after the line that identifies the routine
>>and a 'clear_screen' command. If it is the default, I could have cleared
>>the hangup with a 'Ctrl-C' from the keyboard, but I couldn't. (The hangup
>>came immediately after the first request for keyboard input. I suspect it
>>is something sneaky dreamed up by one of those treacherous 'get' statements.)
>
>>Graeme: Your suggestion, to print something on the screen so that I can see
>>what's happening if anything, is a possibility. I haven't tried it yet, and
>>frankly I'm dubious, because of the location of the hangup. I suspect that
>>the program will never get to the special-print statement.
>
>I am assuming from this message that you still don't
>know *exactly* where the problem is. This *has* to
>be your first step. If you are suspicious of a particular
>line put:
>
> puts(1,"Before\n")
>
>before the line and:
>
> puts(1,"After\n")
>
>After the line.
>
>If you see "Before" but not "after" then your
>program is hanging on that line. If you see
>both massages (as I suspect) then you will
>have to look elsewhere.
>
>As somebody mentioned in one of the replys, CTRL-C
>will only be caught when you are checking for keyboard
>input. Which treacherous get statements are you talking
>about? Where is the input coming from?
>
>I suggest putting:
>
>if get_key() then end if
>
>inside all "while 1 do" loops to ensure
>CTRL-C is caught.
>
>Putting any kind of print to the screen inside
>these loops will also tell you straight away
>whether the program is actually hanging, or is
>stuck in an infinate loop (you will get your
>message printed repeatedly if it is stuck in a
>loop).
>
>HTH,
>
>Graeme.
Thanks again. I'll try your suggestions today.
Why is it that debugging solutions (software or hardware) are so opaque when
you first run into the problem, and so obvious after somebody suggests them?
I feel like the sweet young thing who took her car into the repair shop and
told the service manager, "It won't go." "What's the problem?" "I said, it
won't go." "Yes, but what exactly is the problem?" "It won't go."
Ar-r-r-r-r.
Wally Riley
wryly at mindspring.com
4. Re: Hangup
Wally,
You wrote about a hangup, probably caused by a nasty 'get' statement?
Apart from Graeme's solution, you could also try:
with trace
trace(1)
after the lines were you include.
Especially if the problem is in the very first part of the program, as yo=
u
suggest, you will be able to see in which line (or what line, sorry for m=
y
English) the problems begin. Also, you'll get a report indicating the
contents of each variable and the lines executed before the hangup.
That is to say; if you experience a hangup that is so nasty that you'll
have to restart, then the report will probably not be there.
Which brings me to another question: are you running Euphoria under DOS o=
r
Windoze? In Windoze, (certainly in Windows95, I'm not sure about 3.11) yo=
u
can press Ctrl-Alt-Del to finish a task. (Again, most of the times AFAIK)=
=2E
Maybe, after hanging, you can locate problems on your harddisk by
implementing SCANDISK, or if you haven't got that, CHKDSK.
If you still are experiencing problems, let's have a look at your program=
;
or is it a secret one?
Ad
P.S. Jiri, I hope your toothache and your bad temper will soon fade away.=
I
know you as an amaible person, so I hope to meet this person again soon o=
n
this listserv.
In the meantime, go play some tennis, or bridge, or look at a soccer game=
!
En Ralf, niet op reageren, denk aan Patrick Kluivert. (translated: Let it=
be).
piece men!
5. Re: Hangup
--=====================_898159664==_
Attached is the debugging/feedback include file I use. It's pretty basic,
but I've found it immensly usefull in zeroing in on a problem. I prefer
the error file method, as it lets my program run unhindered. I'll usually
saturate the suspect code with tag()s returning consecutive numbers(in
quotes) and check the error file after to see where it broke down. I'm
often suprised by where it stops.
Two functions are included: flag() and tag()
flag(s,o)
puts()'s the s as script and prints the o as a bracketed object to
flag.err, both in one line seperated by a " -- "
Used for feedback.
tag(s)
puts()'s s as script to flag.err
used mainly as a marker of progress
a typical flag.err might look like:
1
2
3
4
before
after
3
4
before
--=====================_898159664==_
