My guess is the "uses crt" is not needed for linux. If you still need your code to run under turbo pascal then put an IFDEF around it. You also shouldn't need the --automake when compiling...

On Sat, Jan 24, 2009 at 11:05 AM, Alexey Kotlyarov koterpillar@gmail.comwrote:

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.

Version info and such: $ gpc --version gpc 20070904, based on gcc-4.1.3 20080420 (prerelease) (Ubuntu 2.1-4.1.2-22ubuntu1) Copyright (C) 2006 Free Software Foundation, Inc. $ uname -a Linux flower2 2.6.27-11-generic #1 SMP Fri Jan 23 13:58:13 UTC 2009 x86_64 GNU/Linux

Any ideas of how to fix this?

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

There's a lot of historical-baggage connected with the crt unit, especially the notorious Runtime error 200 issue. For details see: http://en.wikipedia.org/wiki/Turbo_Pascal Thank Heaven for open-source systems...

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