Thanks to Christian for reminding me that bugs should be reported. I tend to
collect
short notes about them (for later processing) before going on to hack around
them,
but this time I spent so much time with the latter that I forgot about the
former..
During the first days of trying to bang my head against a wall with FranTk
(*),
I encountered some nasty problems with INTERNAL ERRORs in Hugs (November
1999 InstallShield version on Win98). Unfortunately, I kept a snapshot of
the program
in question only for one of the two recorded cases (the non-recursive A),
but here are
my notes anyway, together with a stripped down version of the buggy program
for A:
-------------------------bug-notes-----------------
In both of the following cases there is a program error in the user
program that leads to a failed pattern match, but the attempt to produce
the error message fails, either because of an "Error in graph" [after an
mkL' (primNewRepeater_v2288], or because of a cyclic default_show
message.
A
Program error: {cursorModes'_v7934 instHas_Event_v4692 (BVar_BVar
(flip mapIOL
mkL' (primNewRepeater_v2288
INTERNAL ERROR: Error in graph
B
...
default_show (Make.Show (Show_default_show (Make.Show
(Show_default_show (Make.Show (Show_default_show (Make.Show
(Show_default_show (Make.Show (Show_default_sh ow (Make.Show
(Show_default_show (Make.Show (Show_default_show (Make.Show (Show_
...
------------------ a shortened bug.hs------------------
import FranTk
main = display $ bug
bug = withRootWindow [] $ do
v <- mkBVar True
nomatch [] v -- printer will try to print the BVar when the error occurs
nomatch (_:_) _ = error "just won't match"
-------------------and its output------------------------
Main> main
Program error: {nomatch [] (BVar_BVar (flip mapIOL (mkL'
(primNewRepeater_v2288
INTERNAL ERROR: Error in graph
---------------------------------------------------------
BTW, I seem to remember a discussion of cyclic shows on Hugs-bugs a while
ago,
but couldn't find the problem, which is obviously still with us, on the
known bugs list.
The two cases seemed to be related: my notes say that I removed the print
statements
in case B (they were intended for debugging purposes and the only sources of
show..),
and I got:
B2
Program error: {mvDisc instNum_v53 (Num_fromInt instNum_v35
100,[],CollectionBVar_CollectionBVar (liftL1_v2103 (primNewRepeater_v2288
INTERNAL ERROR: Error in graph
---------------------------------------------------------
Additional comments:
1. It would be nice if Hugs sessions could be recorded in a log-file (if
only for
the purpose of producing bug reports). Lacking scrollbars (under W98), I
wasn't able to see the text at the beginning of the cyvlic default_show
message.
Similarly, the Hugs banner with the version information disappears
immediately
above the various FranTk imports (the :version command should probably
record all the configuration information you would want to see in a bug
report?).
2. A cursory examination of the sources seemed to indicate that that the
error
message (though not the error) arises from the default case in the
builtin
printer function (in printer.c). This suggests that someone extended
internal
functionalities without extending the printer?
3. It doesn't seem to be a good idea to just give up completely after an
internal
error in the printer (although I can understand the motivation for the
decision
for aborting on internal errors in the general case - perhaps the
following
suggestions should be controlled by an option).
a) If the printer is used for the output of error messages, its output is
desperately
needed! I was lucky enough in that I was able to reconstruct the
offending calls
in my programs from the partial error messages, but in most (?)
cases, it would
be more useful to print the "Error in graph" as a replacement for the
buggy node
and to try and resume printing the rest of the error message. To see
the problem,
try switching the parameters of no_match in bug.hs above.
(would it be possible to include line number info in Program error
outputs?)
b) As Haskell and Hugs are being used more and more in connection with
external
code, not only the current Hugs operation needs to be shut down
gracefully in
case of an internal error! Library authors should have access to a
Haskell operation
(GHC/Hugs extensions) that allows to attach a finalizer to the
Haskell RTS.
In the present case, this would allow FranTk to try and shut down
the Tcl/Tk
windows whenever the normal Hugs operation is interrupted (CTRL-C,
internal
errors of non-fatal nature,..).
Oh, I forgot to warn you - this is a rather longish message;-)
Claus
(*) Now, of course, I know better, and can tell a wall to listen to a wire
attached to head bang events;-) but I'm still not happy about having to
juggle Fran-like concepts with no less than two IO monads (constructing
reactive behaviors in a monad.. :-(. But the end of February is near,
and
there was some talk about a rewrite due around this time, being more in
line with Fran ideas, right?
