I've put a copy of the GPC home page on a new web server: http://www2.gnu-pascal.de
It is also available on the usual URLs (http://www.gnu-pascal.de etc.), but due to DNS caching it may take a few days until your machine will recognize the change.
The mailing list archives are not there yet, and the downloads are missing. Only the latest alpha is there. If some of the contributors would like to put some files there, please PM me at frank@g-n-u.de (either send the files directly, even if large, or a URL where I can get them).
Frank
GPC Pascal programmers:
I have gotten a complete ncurses interface working for GNU Pascal. I have tested it on MaxOSX (using unix prompt), although more testing is needed. This is the UNIX terminal ncurses, no graphics.
The interface file (ncurses.pas), one-page documentation (ncurses.txt) and a few test files (*.pas) are attached as a gzip tar file (16k). Any testing or suggestions are welcome.
After testing, and after I get at least one more library confirmed (menu), I would like to submit this as a candidate to include in the GPC Pascal package.
Sincerely,
willett kempton Visible Software
willett wrote:
GPC Pascal programmers:
I have gotten a complete ncurses interface working for GNU Pascal. I have tested it on MaxOSX (using unix prompt), although more testing is needed. This is the UNIX terminal ncurses, no graphics.
The interface file (ncurses.pas), one-page documentation (ncurses.txt) and a few test files (*.pas) are attached as a gzip tar file (16k). Any testing or suggestions are welcome.
Sorry, but I see a number of type problems here (typical for direct C interfaces):
: - many int32 apparently should be ShortInt (int16), not fully investigated
C interfaces in GPC should always use the types provided for C compatibility. As ncurses doesn't use fixed-size types, int32 is probably not right here.
E.g., ncurses.h on my system contains:
typedef unsigned long chtype;
This would be translated to `MedCard' (see manual). On some systems, this is in fact 32 bits, but on others it's 64 bit, so it would break there.
However, I see that on some targets ncurses uses `unsigned int' for chtype (see its configure script) which would be `CCardinal', which further complicates the issue.
Direct linking to a C interface in a portable way is tricky sometimes. A safe way is writing C wrappers (some more overhead) or a fully automatic header translator (quite hard), otherwise you'll have to figure out a way to deal with it. (For specific cases such as this, you could check the installed ncurses.h and adjust according to it.)
: IntBool = MedBool; { was int in c (signed 32 bit integer), used only as a boolean }
BTW, if it's `int' in C, it should be `CBoolean'. `MedBool' corresponds to `[unsigned] long'.
Such problems are hard to detect tested on just one system as many wrong types happen to match anyway.
: tacs_map = ARRAY [char] OF chtype; { 128-byte, re-settable array, initially char->chtype }
In Pascal, this is no 128 byte array. Char has a range of 256 values (currently), and chtype is at least 32 bits. So the array has 256 elements and at least 1024 bytes.
BTW (unrelated), I'd suggest to rename the package to `gpc-ncurses-...' or `ncurses-gpc-...', to avoid confusion with an ncurses library package.
Frank
Frank Heckenbach wrote (quoted message below).
Frank, thanks very much for all your advice. I'm trying to get up to speed here.
Ok, I'm now using MedCard for chtype in ncurses.h (assuming typedef unsigned long chtype) CBoolean for "bool" in ncurses.h (assuming typedef unsigned int bool) CBoolean for an "int" which contains only TRUE or FALSE CInteger for an "int" used as an integer (on older gpc I use "integer") tacs now uses index of char128 = #0 .. #127
The c translation types are very useful! Thanks. Did I understand you to say I should use CBoolean in both the above cases?
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.
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?
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
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?)
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?
Rick Engebretson wrote:
There are many C libraries that use ncurses. Menu, panel, CDK to name a few.
But all the added C constructs can be done better through Pascal. Instead of working to access these ncurses derivatives, perhaps object pascal and ncurses is enough.
Rick, thanks for trying to save me some time. I'm thinking I'd like to use menu, which is already documented and tested, rather than writing my own. So I might do that interface. The others I would definately leave. (Panel is said to be buggy) Or were you volunteering to write a Pascal version of menu?
Willett Kempton
On 25 Apr 2005, at 10:21, Frank Heckenbach wrote:
willett wrote:
GPC Pascal programmers:
I have gotten a complete ncurses interface working for GNU Pascal. I have tested it on MaxOSX (using unix prompt), although more testing is needed. This is the UNIX terminal ncurses, no graphics.
The interface file (ncurses.pas), one-page documentation (ncurses.txt) and a few test files (*.pas) are attached as a gzip tar file (16k). Any testing or suggestions are welcome.
Sorry, but I see a number of type problems here (typical for direct C interfaces):
: - many int32 apparently should be ShortInt (int16), not fully investigated
C interfaces in GPC should always use the types provided for C compatibility. As ncurses doesn't use fixed-size types, int32 is probably not right here.
E.g., ncurses.h on my system contains:
typedef unsigned long chtype;
This would be translated to `MedCard' (see manual). On some systems, this is in fact 32 bits, but on others it's 64 bit, so it would break there.
However, I see that on some targets ncurses uses `unsigned int' for chtype (see its configure script) which would be `CCardinal', which further complicates the issue.
Direct linking to a C interface in a portable way is tricky sometimes. A safe way is writing C wrappers (some more overhead) or a fully automatic header translator (quite hard), otherwise you'll have to figure out a way to deal with it. (For specific cases such as this, you could check the installed ncurses.h and adjust according to it.)
: IntBool = MedBool; { was int in c (signed 32 bit integer), used only as a boolean }
BTW, if it's `int' in C, it should be `CBoolean'. `MedBool' corresponds to `[unsigned] long'.
Such problems are hard to detect tested on just one system as many wrong types happen to match anyway.
: tacs_map = ARRAY [char] OF chtype; { 128-byte, re-settable array, initially char->chtype }
In Pascal, this is no 128 byte array. Char has a range of 256 values (currently), and chtype is at least 32 bits. So the array has 256 elements and at least 1024 bytes.
BTW (unrelated), I'd suggest to rename the package to `gpc-ncurses-...' or `ncurses-gpc-...', to avoid confusion with an ncurses library package.
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
willett wrote:
Rick Engebretson wrote:
There are many C libraries that use ncurses. Menu, panel, CDK to name a few.
But all the added C constructs can be done better through Pascal. Instead of working to access these ncurses derivatives, perhaps object pascal and ncurses is enough.
Rick, thanks for trying to save me some time. I'm thinking I'd like to use menu, which is already documented and tested, rather than writing my own. So I might do that interface. The others I would definately leave. (Panel is said to be buggy) Or were you volunteering to write a Pascal version of menu?
Willett Kempton
I'm approaching it differently. Among the many gains with Object Pascal are encapsulation, polymorphism, dynamic variables, etc. So how the menu or panel C functions manage ncurses doesn't concern me. A menu or panel is an ObjectWindow (the type I'm trying to use) like any other window. Same with a button. With Pascal, these objects can be created and managed with ease. If someone chooses to develop an object inheritance scheme with virtual methods, fine. But then you need extensive documentation and have TurboVision or worse (Java). I seek simplicity.
Obviously, there is a lot of prior GUI effort to consider. Tk and its object variant incrTcl are nice.
Again, a menu, panel or button is just a window. And you can already program windows with ncurses. I am only suggesting that you limit your use of C code. Let Pascal do most of the work.
I learned a long time ago ( pushing the fiber-optic supernetwork ) never to try please programmers.
Rick,
Sure, Pascal menuing would be preferable to calling c's menu. I'm working on making ncurses function across more of the gnu/gpc platforms. ("More" but I probably won't be able to make it autoconfigure across all.) I have our specific application (Dr. Pascal) as my primary goal, so I'm not going to put effort into writing a library for menu use.
I would guess that I and other gpc programmers would find it valuable to have a general-purpose menuing function that could both call ncurses and do menuing on a "terminal", and with the same library calls, do platform-appropriate menuing on macintosh OSX or windows. Writing such a library, I think, would be a substantial task and definately is beyond my time and ability.
- Willett
On 2 May 2005, at 9:25 AM, Rick Engebretson wrote:
willett wrote:
Rick Engebretson wrote:
There are many C libraries that use ncurses. Menu, panel, CDK to name a few.
But all the added C constructs can be done better through Pascal. Instead of working to access these ncurses derivatives, perhaps object pascal and ncurses is enough.
Rick, thanks for trying to save me some time. I'm thinking I'd like to use menu, which is already documented and tested, rather than writing my own. So I might do that interface. The others I would definately leave. (Panel is said to be buggy) Or were you volunteering to write a Pascal version of menu?
Willett Kempton
I'm approaching it differently. Among the many gains with Object Pascal are encapsulation, polymorphism, dynamic variables, etc. So how the menu or panel C functions manage ncurses doesn't concern me. A menu or panel is an ObjectWindow (the type I'm trying to use) like any other window. Same with a button. With Pascal, these objects can be created and managed with ease. If someone chooses to develop an object inheritance scheme with virtual methods, fine. But then you need extensive documentation and have TurboVision or worse (Java). I seek simplicity.
Obviously, there is a lot of prior GUI effort to consider. Tk and its object variant incrTcl are nice.
Again, a menu, panel or button is just a window. And you can already program windows with ncurses. I am only suggesting that you limit your use of C code. Let Pascal do most of the work.
I learned a long time ago ( pushing the fiber-optic supernetwork ) never to try please programmers.
Willett Kempton wrote:
Rick,
Sure, Pascal menuing would be preferable to calling c's menu. I'm working on making ncurses function across more of the gnu/gpc platforms. ("More" but I probably won't be able to make it autoconfigure across all.) I have our specific application (Dr. Pascal) as my primary goal, so I'm not going to put effort into writing a library for menu use.
I would guess that I and other gpc programmers would find it valuable to have a general-purpose menuing function that could both call ncurses and do menuing on a "terminal", and with the same library calls, do platform-appropriate menuing on macintosh OSX or windows. Writing such a library, I think, would be a substantial task and definately is beyond my time and ability.
- Willett
I'm not even close to the pascal programmer Prof. Olowofoyeku is.
The software label key functions are a ready made ncurses menu. The Prof. knows pascal pchars ( ncurses labels and text ) as well as anybody. He is also into Delphi (object pascal). His assistance to you would be of far greater value than mine.
For pop-up menus I'll offer a kludge soon. Perhaps we can get the mouse working for GPC, too. (FPC doesn't have it :-)
Rick Engebretson wrote:
If someone chooses to develop an object inheritance scheme with virtual methods, fine. But then you need extensive documentation and have TurboVision or worse (Java). I seek simplicity.
You don't need it. GPC's (i.e., mostly TP's) objects can do (single) inheritance and virtual methods just fine. Of course, TV also uses it, but if you prefer a simpler class hierarchie (as I do, too), it's also possible with this model. (I'll publish mine sometime, but I have to do some cleaning-up first, and currently I have more urgent things to do ...)
Frank
Frank Heckenbach wrote:
Rick Engebretson wrote:
If someone chooses to develop an object inheritance scheme with virtual methods, fine. But then you need extensive documentation and have TurboVision or worse (Java). I seek simplicity.
You don't need it. GPC's (i.e., mostly TP's) objects can do (single) inheritance and virtual methods just fine. Of course, TV also uses it, but if you prefer a simpler class hierarchie (as I do, too), it's also possible with this model. (I'll publish mine sometime, but I have to do some cleaning-up first, and currently I have more urgent things to do ...)
Frank
I'm just glad you're OK.
Rick.
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 intbool) 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
Frank wrote:
I'm not sure of a straightforward way. You may want to ask on the ncurses list, though.
Of course. There would have to be an ncurses list! An alternative to endless experimentation and fruitless document searching.
How do I access said ncurses list?
Willett Kempton
willett wrote:
Frank wrote:
I'm not sure of a straightforward way. You may want to ask on the ncurses list, though.
Of course. There would have to be an ncurses list! An alternative to endless experimentation and fruitless document searching.
How do I access said ncurses list?
Willett Kempton
Here;
http://lists.gnu.org/mailman/listinfo/bug-ncurses
Please consider that Thomas Dickey, while extremely helpful, is the maintainer of a core program. It is up to you to learn a lot before asking questions.
Frank suggested that I try to figure out configuration for ncurses, so that if it were distributed it should work on all/most targets.
I'm making (modest) progress. (p.s. Also I have the ncurses mouse routines working, cool.)
On 5 May 2005, at 21:16, Frank Heckenbach wrote:
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? ....
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.
I find there are only five values put in. One, @cf_cv_type_of_bool@, seems to be taken care of by the gpc type CBoolean. Unless I'm missing something, I don't need to do anything about that.
A second, @cf_cv_typeof_chtype@ is for the type of chtype. Is there any way to compute this in the compiler and have a type?
Same question for widec_shift and shift_limit.
If at least one of these is "no", then the configuration approach would be needed. This could be done with reference to the file created when './configure' is run on ncurses.h.in, which gives the above values.
Any thoughts welcome, on the question of how to make my Pascal interface for ncurses most portable across gpc implementations.
More specifics below.
Willett Kempton
---------------------------------------------------------------
To make the ncurses Pascal interface portable, the following substitutions are needed:
Most important: @cf_cv_typeof_chtype@ @cf_cv_type_of_bool@
For A_ATTRIBUTES, etc @cf_cv_widec_shift@ (how unsafe to assume 8?) @cf_cv_shift_limit@ @cf_cv_1UL@
Where are they? All cf_cv_ types are in config.cache after configure run on ncurses source They are also all generated by running the "configure" file on the ncurses source
...
Example values (fixed font lines up)
system typeof_chtype pas widec_shift shift_limit 1UL -------------------- ------------------- ------- ----------- ----------- --- powerpc-apple-darwin unsigned long chtype; MedCard 8 32 1UL
willett wrote:
(p.s. Also I have the ncurses mouse routines working, cool.)
Again, congratulations. That is cool.
For the rest, I think you are wasting your time. Just put your ncurses unit up for grabs somewhere. Compiling it in makes no sense.
Rick.
Clarification:
The only thing I was asking about "compiling in" was additional types to make it easier to write c interfaces that work across all platforms. Frank has given us "CBoolean" and "CInteger" which make it MUCH easier to interface to c cross- platform. Thanks, Frank! I was asking whether similar predefined types could be predefined for the other entities that vary across platforms, or at least some of them. The most important being chtype, fundamental to ncurses.
Willett
On 23 May 2005, at 09:25, Rick Engebretson wrote:
Again, congratulations. That is cool.
For the rest, I think you are wasting your time. Just put your ncurses unit up for grabs somewhere. Compiling it in makes no sense.
Rick.
willett wrote:
Clarification:
The only thing I was asking about "compiling in" was additional types to make it easier to write c interfaces that work across all platforms. Frank has given us "CBoolean" and "CInteger" which make it MUCH easier to interface to c cross- platform. Thanks, Frank! I was asking whether similar predefined types could be predefined for the other entities that vary across platforms, or at least some of them. The most important being chtype, fundamental to ncurses.
Willett
On 23 May 2005, at 09:25, Rick Engebretson wrote:
Again, congratulations. That is cool.
For the rest, I think you are wasting your time. Just put your ncurses unit up for grabs somewhere. Compiling it in makes no sense.
Rick.
This is where CBFalconer should advise. He emphasizes "standards," and they are needed here. The CString was in MS:QuickPascal, 1990.
But other types are now all over the map. NCurses and TCL had problems going from 8bit to 16bit characters. FPC and GPC differ. Network sockets and character device drivers are still 8bit.
willett wrote:
I find there are only five values put in. One, @cf_cv_type_of_bool@, seems to be taken care of by the gpc type CBoolean. Unless I'm missing something, I don't need to do anything about that.
I don't think so. At a quick glance, there seem to be cases where it's set to `int' (i.e., `CInteger'). But I really can't do all the checking -- as I said, I don't think it's really the best way to go, so I won't do the work, sorry.
A second, @cf_cv_typeof_chtype@ is for the type of chtype. Is there any way to compute this in the compiler and have a type?
No, the compiler doesn't know what ncurses' configure script does, that's basically the problem. (And the basic difference compared to `int' etc. -- those are predefined by the C compiler, and thus provided by the backend, so GPC can access them directly.)
Unless you get the results from its output (i.e., ncurses.h) in some way or another, I guess you have to understand the configure script yourself (and I never said this was easy ...).
The only thing I was asking about "compiling in" was additional types to make it easier to write c interfaces that work across all platforms. Frank has given us "CBoolean" and "CInteger" which make it MUCH easier to interface to c cross- platform. Thanks, Frank!
BTW, no false credits please. GPC has always had C compatible types (originally `Integer' = `int'), being GCC based. The change to `CInteger' last year originated from a discussion by Waldek Hebisch, Scott Moore and others. I only did the boring part of it.
Frank
willett wrote:
GPC Pascal programmers:
I have gotten a complete ncurses interface working for GNU Pascal. I have tested it on MaxOSX (using unix prompt), although more testing is needed. This is the UNIX terminal ncurses, no graphics.
The interface file (ncurses.pas), one-page documentation (ncurses.txt) and a few test files (*.pas) are attached as a gzip tar file (16k). Any testing or suggestions are welcome.
After testing, and after I get at least one more library confirmed (menu), I would like to submit this as a candidate to include in the GPC Pascal package.
Sincerely,
willett kempton Visible Software
Congratulations ! :)
I would like to see this evolve. I am not at all familiar with MacOSX. I am quite familiar with Linux.
Time is scarce for me, presently. But I would like to learn much more about MacOSX. Thanks for sharing the news of your success.
Sincerely, Rick.
willett wrote:
GPC Pascal programmers:
I have gotten a complete ncurses interface working for GNU Pascal. I have tested it on MaxOSX (using unix prompt), although more testing is needed. This is the UNIX terminal ncurses, no graphics.
The interface file (ncurses.pas), one-page documentation (ncurses.txt) and a few test files (*.pas) are attached as a gzip tar file (16k). Any testing or suggestions are welcome.
After testing, and after I get at least one more library confirmed (menu), I would like to submit this as a candidate to include in the GPC Pascal package.
Sincerely,
willett kempton Visible Software
There are many C libraries that use ncurses. Menu, panel, CDK to name a few.
But all the added C constructs can be done better through Pascal. Instead of working to access these ncurses derivatives, perhaps object pascal and ncurses is enough.
Ncurses provides the screen access. Object Pascal provides the constructs. This is a natural programming language heirarchy.
-
Frank Heckenbach -
Rick Engebretson -
willett -
Willett Kempton