On Sat, Jan 24, 2009 at 7:07 PM, Frank Heckenbach
<ih8mj@fjf.gnu.de> wrote:
Alexey Kotlyarov wrote:
> Being compiled version of GPC installed on Ubuntu, the following very
> simple program fails to produce any output:
>
> program testcrt;
> uses crt;
> begin
> writeln('OK');
> writeln(sqrt(-1)); { error }
> end.
>
> $ gpc --automake testcrt.pas -o testcrt
> $ ./testcrt
> ./testcrt: argument to `SqRt' is < 0 (error #708 at 40b6c6)
>
> Notice the absence of OK. Similarly, removing error line makes program
> produce no output. Removing 'uses crt;' restores normal behavior.
Yang Lao wrote:
> My guess is the "uses crt" is not needed for linux.
It's nothing to do with the operating system. It's about whether or
not you want to have a "CRT program" (see below).
> You also
> shouldn't need the --automake when compiling...
Well, yes, you should, if the program uses the CRT (or any other)
unit which must also be compiled. (Or alternatively, the GP
utility.)
Alexey Kotlyarov wrote:
> It's not needed for this program, but I do need it for compatibility
> reasons.
This doesn't make much sense to me. "WriteLn" is a standard Pascal
builtin, and AFAIK all compilers support it. Using CRT is not
required for it (in case that's what you mean with compatibility
reasons). Even plain old Turbo Pascal does so.
In fact, what Turbo/Borland Pascal's CRT unit does, and GPC's as
well since it's meant to be backward-compatible, is to redirect the
"Input/Output" Text files (which are used implicitly by
"ReadLn/WriteLn") from the standard input/output file desciriptors
to some other kind of I/O. In the case of BP this "other kind of
I/O" is BIOS calls and direct access to the text screen buffer, in
the case of GPC it's via a curses library (for Linux usually
ncurses).
So whether or not to use CRT is not dependent on whether you need to
use WriteLn or such (which is or was a somewhat common
misunderstanding among BP users). Instead, using CRT changes the way
WriteLn works. With CRT you have additional functions for cursor
positioning, text attributes (color etc.), reading single keys etc.
(That's why CRT is usually used for interactive text-mode programs,
in contrast to programs that basically run in batch-mode.) On the
other hand, you lose the ability to redirect input/output such as
"./testcrt > foo". (More precisely, in BP you won't get anything in
the output file, which in GPC you'll get output with
terminal-control escape sequences etc., which might actually be
useful in some special cases, but not like normal I/O redirection.)
FWIW, standard input/output is not disabled, just shadowed (both in
BP and GPC), so you can still get it by opening a text file to the
empty string as the filename, e.g.:
var MyOutput: Text;
Rewrite (MyOutput, '');
or even "Rewrite (Output, '')". This can be useful for programs
which can run both interactively and batch-mode.
Now for the original question. When the CRT unit finishes, it clears
up the screen and restores the old screen if possible (most X11
terminals support this, whereas on other terminaly, you might get a
black screen instead). So the "OK" shows shortly, but it's
immediately cleared. (In contrast, the error message is written to
standard error which is not redirected to CRT, that's why you see
it.)
What to do about it depends on what you really want to achieve
(which I can't tell from the small example, of course). If you want
to keep the last screen from CRT after terminating the program,
that's not directly possible with CRT (and even if it were, it
wouldn't be recommended, since X11 terminals are switched to an
"alternate mode" for CRT, and continuing in this mode for regular
I/O afterward has some strange effects).
You might want to catch runtime errors, display them to the user (or
not) via CRT (e.g., in one of my programs, I create a pop-up box
with the error message -- fortunately I haven't seen it for quite a
while ;-), and offer to quit afterwards, or just after some delay or
so. For such things, please see the "Trap" unit (trap.pas) which
also comes with GPC (read the comments in the unit). This solution
is not as trivial as you might like, but it has the advantage that
you can (somewhat) properly clean up after a runtime error, at least
"apologize" to the user and/or save important data ...
(I'm assuming an interactive program here. If that's not what you're
writing, you probably don't need CRT, see above.)
Frank
--
Frank Heckenbach, f.heckenbach@fh-soft.de, http://fjf.gnu.de/, 7977168E
GPC To-Do list, latest features, fixed bugs:
http://www.gnu-pascal.de/todo.html
GPC download signing key: ACB3 79B2 7EB2 B7A7 EFDE D101 CD02 4C9D 0FE0 E5E8