willett wrote:
Apologies for duplication, but you replied to subsequent messages and a copied part of this one, so I'm guessing you didn't see the questions below.
I did, but I was busy with other work, so I didn't replly yet.
CBoolean for "bool" in ncurses.h (assuming typedef unsigned int
bool) CBoolean for an "int" which contains only TRUE or FALSE Did I understand you to say I should use CBoolean in both the above cases?
I'm afraid not. `CBoolean' is guaranteed compatible to `_Bool' in GNU C (which is defined as `bool' in `stdbool.h'). ncurses seems to use `bool' as one alternative.
For `[unsigned] int' C Booleans, I just noticed we don't have a compatible Boolean type (so thanks for pointing me to it, even if unintentionally ;-). WordBool used to be one, but since the changes of last year (CInteger etc.) it's no more compatible. I'm adding CWordBool for this purpose now. (If you want to have it now, try the appended patch. You'll have to force rebuilding the RTS, or just rebuild GPC completely, after applying it.) If you don't want to depend on CWordBool, I'm afraid you'll have to use an integer type (CInteger or CCardinal) for now.
To create the ncurses.h file, I have to run ./configure within the ncurses source directory. I could run this several times for different hosts, to find what the range of types are. Right? Could you suggest a couple of different hosts to try out? Say, the most common? or perhaps, the most different? or better, how do I read the configuration file directly? I see that "configure" is a readable text file, but I can't find a list of alternative "bool" (for example) definitions in that configuration file.
I'm not sure of a straightforward way. You may want to ask on the ncurses list, though. But even if you knew all possible settings, the problem still remains to get the one for each current target.
In fact, I can't figure out what my own host (Mac OSX) is called, when I try
./configure host=powerpc-apple-darwin
I get an "unknown host" message. Any suggestions?
./configure without an argument should assume the current system and output its denoter in the first few lines.
When you said:
BTW (unrelated), I'd suggest to rename the package to `gpc-ncurses-...' or `ncurses-gpc-...', to avoid confusion with an ncurses library package.
Did you mean to name the interface file, e.g. ncurses.pas -> gpc-ncurses.pas
I meant only the archive. For the unit name, ncurses is fine with me.
or the unit, e.g. unit ncurses; -> unit gpc-ncurses;
(If the latter, wouldn't gpc_ncurses be a more standard Pascal name than gpc-ncurses?)
A minus sign in an identifier wouldn't even be allowed. ;-)
To do more things like reading the ncurses.h headers and then automatically configuring ncurses.pas types to be consistent, that's a bit beyond me. Beyond, both in that I wouldn't know how to and that I don't have time to learn how to and test all these. I wouldn't want to write c wrappers, a lot of work and then we're stuck with double calls. What I'm thinking now is to use all your MedCard, CBoolean, etc types, and put in the documentation warnings about what types of hosts would need edits before use. and/or how to check ncurses.h and hand-modify ncurses.pas.
Does this approach and the above modifications seem reasonable?
I personally don't really like units the user has to edit before using. (And we all know how well documentation is usually read.) I still think C wrappers are the least trouble in the long run. The extra call overhead for (some of the) terminal routines doesn't seem very critical.
An alternative would be a script that checks ncurses.h and does the changes automatically (only for the known problematic cases, so it would be far less difficult than a general header translator). But IMHO C wrappers are still easier (to write and to use).
(Panel is said to be buggy)
Not AFAIK. I'm using it extensively in an application (via CRT), and except for a bug in PDCurses when resizing the terminal, I'm not aware of any particular problems. BTW, I think panel is the most useful ncurses add-on; others such as menu can be rewritten in Pascal as is discussed here, while emulating panels requires at least somewhat low-level curses access.
Frank