Andy Ball a écrit:

Hello Maurice,

ML> CRT in gpc is based on a curses library (ncurses or > PDcurses).

Can gpc's CRT be told to use NetBSD's curses library instead of ncurses or PDcurses? I can install ncurses as a package, but can't help feeling that I shouldn't have to.

Only Franck can tell. He wrote CRT

Maurice

Rick Engebretson wrote:

Andy Ball wrote:

...

Hello Maurice,

ML> CRT in gpc is based on a curses library (ncurses or > PDcurses).

Can gpc's CRT be told to use NetBSD's curses library instead of ncurses or PDcurses? I can install ncurses as a package, but can't help feeling that I shouldn't have to.

The ncurses people (Thomas Dickey now, also maintains xterm) have worked very hard to make ncurses compatible with terminals and curses programs going back to the ice age. Your curses should work.

Well that's backward-compatible. It's possible that CRT uses ncurses features that other curses don't have, and unfortunately I don't have another curses library handy to test (neither the time for it, really).

So, if you want, just try it, and report -- or preferably fix -- any problems you encounter. Most changes will probably affect crtc.h. You can try the crtdemo.pas program which demonstrates many CRT features, so if you get it all to work, that will be a good sign.

However, it's probably less work to just install ncurses. AFAIK, the ncurses people also care about keeping it portable, so while I haven't used it on NetBSD, I wouldn't expect serious problems.

To compile with curses, one must link with the library libcurses. In my older linux distros I think libcurses was merely a link to libncurses (but not anymore). So if gpc's CRT unit does not work with your curses, my guess is that its a linking issue with gpc, and not your curses. (I looked at the CRT unit files but didn't see the linker call.)

For linking, you can change the `{$L}' directive (crt.pas, line ~790). That's the trivial part. Other problems (compile-time and/or runtime) may follow, as I wrote above ...

That being said, the modern console is not your typical terminal, and the gpc CRT unit (and crtdemo with ncurses) goes far beyond putting characters on a screen. Ncurses also provides panels, forms, dialogs, mouse interaction, etc. It is a good program to have on your system.

Sure. :-)

And, BTW, if you're working under X11, you might also want to try PDCurses (aka XCurses) instead. You'll probably have to install it first as well. IME, many xterms and similar don't support function keys etc. very well, so XCurses is sometimes more comfortable. Since XCurses uses the generic X11 libraries in turn, I don't expect portability problems there, either. It can be installed parallel to a terminal curses installation as it calls its libraries and headers differently.

Frank

Rick Engebretson wrote:

On SuSE 8.1 (others mostly work too, RH9.0 not really) a high resolution framebuffer console driver (eg. 1024x768 pixels x16bpp) installs automatically with NVidiaTNT2 and MatroxG200 video cards. Both also get X11 installed. The Matrox card will install hardware accelerated OpenGL drivers from the distro, TNT2 drivers need to be downloaded. Thus, 3 different graphics interfaces are available.

What interests me is the framebuffer console. One can write directly to /dev/fb0 as user. This beats SVGAlib for graphics on the console.

Definitely (having changed to fb myself recently since my new graphics card doesn't provide a good high-resolution textmode anymore).

Further, the "stty" user command is available on SuSE. This can change the console (ncurses controls) size yet leave a lot of framebuffer real estate for pixel graphics. Your CRTunit detects this modified console size very nicely. Your CRTunit is very sophisticated. (re; the linux console (up to 128 of them) runs on high performance computers, not a 9600 baud serial line.)

Thanks, but this praise really goes to the ncurses people. I didn't have to do anything special about it.

The reason I'm plowing through C libraries is to mmap /dev/fb0.

You did see MMapHandle (low-level) and MemoryMap (higer-level) in the GPC module? :-)

This should allow serious graphics capability on the linux console.

It does. One of the first things I did after changing to fb was to write me a simple image viewer. Incidentally, it uses MemoryMap. It was nice to see that it could be done in less than 10 KB of source code (ok, it uses djpeg and ImageMagick's convert in a pipe ;-). It might not be portable yet, but it works for me. If anyone cares, it can be found at http://fjf.gnu.de/misc/fgv.pas.

OTOH, using a simple graphics library that supports fb should make the programs more portable. AFAIK, GRX supports an fb target. I'm going to try it when I get to it (at first quick attempt, it didn't work, but perhaps I just have to enable it in a build rather than svgalib or something) ...

The problem with mmap in existing pascals is they are incomplete. You can't do everything. So going directly to low level system calls seems easiest.

Which is basically what the above-mentioned routines do. (BTW, which other Pascals have mmap? I wasn't aware of any, so our routines are most likely not compatible either.)

Frank

Rick Engebretson wrote:

...

Definitely (having changed to fb myself recently since my new graphics card doesn't provide a good high-resolution textmode anymore).

Actually, the matrox card has a resolution set to (if I remember, early in the morning here) 1280x1024x16, with higher modes available!! And clear text!!

Text mode or graphics mode? In graphics mode, this is not surprising (even my rather cheap card can do 1600x1200x32). But since few people use text mode today, most current cards only support pathetic text modes. And to use graphics mode for Linux VC, you need fb.

A little note; I think your crtdemo does a SVGAtextmode switch. It might have cost a used PCparts guy a replacement monitor : -)

Really? I think it only uses rather simple modes. (And why would someone install SVGAtextmode, and disable the safety settings or provide wrong timing ranges, just to destroy their monitors, BTW? ;-)

But I think I can disable this part, since, as I wrote, probably few people are (able to) use SVGAtextmode for good modes today, unfortunately.

...

...

The reason I'm plowing through C libraries is to mmap /dev/fb0.

You did see MMapHandle (low-level) and MemoryMap (higer-level) in the GPC module? :-)

Yes I did. But I did not see the msync() call implemented. AFAIK this is how to assure writes from memory to file.

Yes, for files. For memory devices it's not necessary AFAIK. These and read-only files are all I've mapped so far, so I hadn't added it. If you need it, I can probably add it in the next release.

Frank

Rick Engebretson wrote:

Frank Heckenbach wrote:

...

Rick Engebretson wrote:

...

Actually, the matrox card has a resolution set to (if I remember, early in the morning here) 1280x1024x16, with higher modes available!! And clear text!!

Text mode or graphics mode? In graphics mode, this is not surprising (even my rather cheap card can do 1600x1200x32). But since few people use text mode today, most current cards only support pathetic text modes. And to use graphics mode for Linux VC, you need fb.

The fb console. So, yes, graphics mode. Still, that's a lot of data to map.

Well, almost 8 MB. For mmap it's not a problem. (It is a speed problem with fb console text, though, especially when scrolling. That's why I use 8 bpp for text, which is more than enough for curses/CRT anyway.)

...

...

Yes I did. But I did not see the msync() call implemented. AFAIK this is how to assure writes from memory to file.

Yes, for files. For memory devices it's not necessary AFAIK. These and read-only files are all I've mapped so far, so I hadn't added it. If you need it, I can probably add it in the next release.

Again, I'm very glad you're on to this. Do what you believe in. You have a fine group of coworkers.

So, do you need msync now or not? If so, please send me some demo/test programs.

And thanks for the exchange. I'll burden you when I have something more. (please, try iwidgets and consider their use for an IDE)

I hope you don't mean me personally. I prefer to use my text mode IDE (PENG) and don't plan to switch. ;-)

Frank

I'm trying to use ncurses and seem to be missing something dumb. I only want to use ncurses, not the CRT unit. My program is:

program testnc(input,output); begin writeln('begin test ncurses, before call to initscr');

initscr; writeln('after initscr'); endwin;

writeln('after endwin'); end.

When I compile the program, using:

gpc testnc.pas -lncurses -o testnc

I get compilation errors:

testnc.pas: In main program: testnc.pas:10: error: undeclared identifier `initscr' (first use in this routine) testnc.pas:12: error: undeclared identifier `endwin' (first use in this routine)

I tried uses GPC; (no change) and uses ncurses; (error: module/unit interface `ncurses' could not be imported)

What am I missing?

Willett Kempton

willett a écrit:

I'm trying to use ncurses and seem to be missing something dumb. I only want to use ncurses, not the CRT unit. My program is:

program testnc(input,output); begin writeln('begin test ncurses, before call to initscr');

initscr; writeln('after initscr'); endwin;

writeln('after endwin'); end.

When I compile the program, using:

 gpc testnc.pas -lncurses -o testnc

I get compilation errors:

testnc.pas: In main program: testnc.pas:10: error: undeclared identifier `initscr' (first use in this routine) testnc.pas:12: error: undeclared identifier `endwin' (first use in this routine)

I tried uses GPC; (no change) and uses ncurses; (error: module/unit interface `ncurses' could not be imported)

What am I missing?

You need to write a Pascal import unit for ncurses, which translates the C syntax declarations in ncurses.h to pascal equivalents. Something like

file ncurses.pas contains: -------------------------------------------------- unit ncurses;

interface

procedure initscr; external name 'initscr'; procedure endwin; external name 'endwin';

implementation {$L ncurses} {<- tell to load libncurses.a} end. -------------------------------------------------- if in ncurses.h they are declared as

void initscr (void); void endwin (void);

(in fact the declarations are more complex than that, and you have to find the Pascal equivalent)

and then add in your main program --------------------------------------- program testnc(input,output); uses ncurses; begin ... ---------------------------------------- and compile with

gpc --automake testnc.pas -o testnc

(you need to add -lncurses only if you do not have written the {$L ncurses} line as above)

For a very simple exercise you may include only the declarations you need in your main program, but for any serious work writing the unit with all declarations is the good choice, quite time consuming however ...

Maurice

willett wrote:

I'm looking for a very simple debugging info from a running gpc program. without getting into a debugger etc. I'm just using gp from command line.

By default, most errors get the uninformative message "Segmentation fault". I would think ther would be some compiler option for more information at time of program failure, for example, the procedure name in which the error occurred, a procedure traceback, and/or a line number at which the error occurred.

But I've searched through both the gpc and gcc manuals, and don't see this. Is it there and I'm missing it?

And, if anything like this is available, an improvement to the gpc manual would be to mention this as a simple option in:

3.2.3 How do I debug my Pascal programs?

On Mac OS X try the following:

• compile with debug information (pass -g) • start /Applications/Utilities/Console.app and open a CrashReporter log • you will get a backtrace with line numbers and procedure names.

Unfortunately, there is a bug in the gpc runtime for the last OS X release, so you will probably see something like

0 a.out 0x0000ab50 _p_FileHandle + 0x4 (files.pas:1033) 1 a.out 0x000047c4 _p_WriteErrorMessage + 0xb0 (error.pas:732) 2 a.out 0x00004aa0 _p__rts_Error_S22_Writestackdump + 0x2a0 (error.pas:754) 3 a.out 0x0000543c _p_EndRuntimeError + 0x38 (error.pas:844) 4 a.out 0x00005520 _p_RuntimeError + 0xbc (error.pas:853) 5 a.out 0x00003b64 _p_GetErrorMessage + 0 (error.pas:586)

I have to update the distribution.

Regards,

Adriaan van Os

Frank,

wow, thanks for this great description! It would be helpful to others, I'm sure, if you (or whoever maintains the GPC manual) just cut this out and pasted it into: 3.2.3 How do I debug my Pascal programs?

IMHO, I'm glad to have documentation that gives features that work imperfectly, especially when given with qualifications, as you do so carefully below... Willett Kempton

On 19 May 2005, at 5:42 PM, Frank Heckenbach wrote:

willett wrote:

...

I'm looking for a very simple debugging info from a running gpc program. without getting into a debugger etc. I'm just using gp from command line.

By default, most errors get the uninformative message "Segmentation fault". I would think ther would be some compiler option for more information at time of program failure, for example, the procedure name in which the error occurred, a procedure traceback, and/or a line number at which the error occurred.

For proper runtime errors, the option `--gpc-rts=-EFILENAME' or `--gpc-rts=-F42' will write a traceback to file FILENAME or file descriptor 42, resp. Using addr2line, the addresses can be translated into source file names and line numbers. The program gpc-run (comes with GPC) does this automatically (if everything works well -- AFAIK it's not well tested, mainly by myself, and only on Unix compatible systems). Just call:

gpc-run your-program your-arguments

However, for crashes such a segfaults, this method won't work as GPC doesn't get to printing error messages. You could try installing a signal handler in your program, like this:

program CrashHandlerDemo;

uses GPC;

procedure CrashHandler (Signal: CInteger); begin Discard (Signal); RuntimeError (267) end;

procedure Test; var p: ^Integer; begin p := nil; WriteLn (p^) end;

procedure Test1; begin Test end;

begin if not InstallSignalHandler (SigSegV, CrashHandler, False, False, Null, Null) then WriteLn (StdErr, 'could not install signal handler'); Test1 end.

But there are also caveats:

• A signal handler might have limited stack space which the backtrace printing routines might not like. On my system, it seems to work now (at least in this case, haven't tested these things much recently), but I remember problems earlier.

• I'm not sure how reliable backtracing from a signal handler is. In my test, only Test1, not Test, showed up in the backtrace.

• After a serious segfault, the program (I/O system, internal variables, ...) may be instable or inconsistent, and trying to print anything (including the backtrace) simply might not work anymore.

So, the best solution, of course, is to turn crashes into runtime errors as far as possible, by enabling checks such as range and object checking (on by default) and pointer checking (--pointer-checking), but for tricky crashes this won't help. So, in the end, using a debugger is sometimes probably the easiest way to locate a segfault.

Frank

-- Frank Heckenbach, frank@g-n-u.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