Accordnig to both ISO standards, readln(f) should be equivalent to get(f), when eoln(f) is true. In GPC the former seems to be implemented as lazy I/O, while the latter does not.
Here is an example (enter three lines of text to test it).
---------------------------- program echo3lines(input,output);
procedure copyline; begin while not eoln do begin output^:=input^; get(input); put(output) end end;
begin write('Enter the first line: '); copyline; readln; writeln; write('Enter the second line: '); copyline; get(input); writeln; write('Enter the last line: '); copyline; readln; writeln end. ----------------------------------------
Is this a bug or a feature?
Emil Jerabek
Emil Jerabek wrote:
Accordnig to both ISO standards, readln(f) should be equivalent to get(f), when eoln(f) is true. In GPC the former seems to be implemented as lazy I/O, while the latter does not.
Is this a bug or a feature?
I think a bug (emil2.pas). Fix attached. Thanks for the report.
Frank
Hello pascal programmers, this is interesting for me, it solves some problems I have.
I have unzipped gpc.fiff-emil2.gz but I don't know how to apply the patch.
Here is my compiler output :
================================================ bash-2.04$ cd Pascal/ bash-2.04$ ./echo3lines.out Enter the first line: first line first line Enter the second line: second line second line Enter the last line: bash-2.04$ gpc -v Reading specs from /usr/local/lib/gcc-lib/i386--freebsd4.2/2.8.1/specs gpc version 19990118, based on gcc-2.8.1 bash-2.04$ gpc echo3lines.pas -o echo3lines.out bash-2.04$ Dec 29 12:13:48 earth login: ROOT LOGIN (root) ON ttyv1
GNU Pascal version 2.8.1 (i386--freebsd4.2) compiled by GNU C version 2.8.1.
==========================================================
Please help me to apply this patch under FreeBSD
Yours Sincerely
Morten Gulbrandsen
Emil Jerabek wrote:
Accordnig to both ISO standards, readln(f) should be equivalent to get(f), when eoln(f) is true. In GPC the former seems to be implemented as lazy I/O, while the latter does not.
Here is an example (enter three lines of text to test it).
program echo3lines(input,output);
procedure copyline; begin while not eoln do begin output^:=input^; get(input); put(output) end end;
begin write('Enter the first line: '); copyline; readln; writeln; write('Enter the second line: '); copyline; get(input); writeln; write('Enter the last line: '); copyline; readln; writeln end.
Is this a bug or a feature?
Emil Jerabek
Morten Gulbrandsen wrote:
Hello pascal programmers, this is interesting for me, it solves some problems I have.
I have unzipped gpc.fiff-emil2.gz but I don't know how to apply the patch.
You probably need GNU patch (since I made a unidiff; maybe other diffs understand it too, but I'm not sure).
Then go into the .../p directory and do `patch -p1 < gpc.diff-emil2' (options for GNU patch, if you're trying another diff, options might vary, or you might have to go one directory above).
Frank
Frank Heckenbach wrote:
Morten Gulbrandsen wrote:
Hello pascal programmers, this is interesting for me, it solves some problems I have.
I have unzipped gpc.fiff-emil2.gz but I don't know how to apply the patch.
You probably need GNU patch (since I made a unidiff; maybe other diffs understand it too, but I'm not sure).
Then go into the .../p directory and do `patch -p1 < gpc.diff-emil2' (options for GNU patch, if you're trying another diff, options might vary, or you might have to go one directory above).
Frank
-- Frank Heckenbach, frank@g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html
Thank you, I tried.
su-2.04# pwd /usr/ports/lang/gpc/work/gpc/p su-2.04# ls -l gpc.diff-emil2 -rwxr-xr-x 1 root wheel 10485 Dec 30 19:36 gpc.diff-emil2 su-2.04# su-2.04# patch -p1 < gpc.diff-emil2 Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |diff -p -r -U3 -N -X /home/gpc/p/script/gpcdiff.exclude orig/p/doc/en/todo.texi p/doc/en/todo.texi |--- orig/p/doc/en/todo.texi Thu Dec 20 21:07:45 2001 |+++ p/doc/en/todo.texi Fri Dec 28 05:49:06 2001 -------------------------- File to patch:
what do I type now ?
I went one directory above : su-2.04# pwd /usr/ports/lang/gpc/work/gpc su-2.04# patch -p1 < gpc.diff-emil2 Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |diff -p -r -U3 -N -X /home/gpc/p/script/gpcdiff.exclude orig/p/doc/en/todo.texi p/doc/en/todo.texi |--- orig/p/doc/en/todo.texi Thu Dec 20 21:07:45 2001 |+++ p/doc/en/todo.texi Fri Dec 28 05:49:06 2001 -------------------------- File to patch:
Still don't know what to type ? I need some help with this, recently I tried to experiment with something I didn't understand, and my xserver crashed.
I prefer to type what I do understand. Do you think the file to patch: is gpc.diff-emil2 ?
If you say so I will try. What kind of version for GNU Patch do you have ? Do I have to compile, ./configure, make or install after patching ?
Thanks for your kind reply
Yours Sincerely
Morten Gulbrandsen
Morten Gulbrandsen wrote:
Frank Heckenbach wrote:
Morten Gulbrandsen wrote:
Hello pascal programmers, this is interesting for me, it solves some problems I have.
I have unzipped gpc.fiff-emil2.gz but I don't know how to apply the patch.
You probably need GNU patch (since I made a unidiff; maybe other diffs understand it too, but I'm not sure).
Then go into the .../p directory and do `patch -p1 < gpc.diff-emil2' (options for GNU patch, if you're trying another diff, options might vary, or you might have to go one directory above).
Frank
-- Frank Heckenbach, frank@g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html
Thank you, I tried.
su-2.04# pwd /usr/ports/lang/gpc/work/gpc/p
Just to be sure: This is the directory where, e.g., gpc.c and subdirectories like doc and rts are?
Hmm... Looks like a unified diff to me... The text leading up to this was:
|diff -p -r -U3 -N -X /home/gpc/p/script/gpcdiff.exclude orig/p/doc/en/todo.texi p/doc/en/todo.texi |--- orig/p/doc/en/todo.texi Thu Dec 20 21:07:45 2001 |+++ p/doc/en/todo.texi Fri Dec 28 05:49:06 2001
File to patch:
what do I type now ?
You could enter doc/en/todo.texi. But if this file exists, patch should have found it by itself (I don't know what's wrong then), and if it doesn't, you're in the wrong directory, anyway.
BTW, you did this in the source directory, not in the build directory (with the object files), didn't you?
Oh, I see in your other mail:
gpc version 19990118, based on gcc-2.8.1
This is a rather old version. Of course, the patch won't apply against that version. You need the current GPC sources first.
What kind of version for GNU Patch do you have ?
I have 2.5.4 here.
Do I have to compile, ./configure, make or install after patching ?
I general, all of them. In this particular case, a new ./configure is not required. Just make and install.
Frank
Hello Gnu Pascal programmers,
are some of you also using freeBSD ?
I found no binary for FreeBSD on your homepage, However I found this gpc-2.0_1 A free 32-bit Pascal compiler Long description | Sources | Main Web Site Maintained by: antonz@library.ntu-kpi.kiev.ua Requires: autoconf213-2.13.000227, gcc-2.8.1, gettext-0.10.35, gmake-3.79.1, m4-1.4_1
under http://www.freebsd.org/ports/lang.html
And this is prepared for freeBSD,
gpc version 19990118, is my version, and I downloaded ist quite recently, So I have no reason to believe that my version is newer than the FreeBSD prepared port ?
I use to download my freeBSD ports from http://www.freebsd.org/ports/lang.html.
My problem is comparing gpc version 19990118 with gpc-2.0_1. Let me guess ?
Is 19990118 similar to year = 1999 and version 0118 = 1.1_8 after disregarding the Most Significant Bit ? And can I compare gpc-2.0_1 as the current release and my 1.1_8 as not quite up to date ?
And you have a GPC for FreeBSD maintainer in kiev ? If antonz is reading this, please tell me the outcome of your gpc -v ?
Please give me a feedback on this, so that I can solve my eoln problem. My patch simply won't apply. And I run FreeBSD.
under this url ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/current/binary/
I would have expected to find some binary for FreeBSD, Or at least a README.FreeBSD
Yours Sincerely
Morten Gulbrandsen
Frank Heckenbach wrote:
Morten Gulbrandsen wrote:
Frank Heckenbach wrote:
Morten Gulbrandsen wrote:
Hello pascal programmers, this is interesting for me, it solves some problems I have.
I have unzipped gpc.fiff-emil2.gz but I don't know how to apply the patch.
You probably need GNU patch (since I made a unidiff; maybe other diffs understand it too, but I'm not sure).
Then go into the .../p directory and do `patch -p1 < gpc.diff-emil2' (options for GNU patch, if you're trying another diff, options might vary, or you might have to go one directory above).
Frank
-- Frank Heckenbach, frank@g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html
Thank you, I tried.
su-2.04# pwd /usr/ports/lang/gpc/work/gpc/p
Just to be sure: This is the directory where, e.g., gpc.c and subdirectories like doc and rts are?
Hmm... Looks like a unified diff to me... The text leading up to this was:
|diff -p -r -U3 -N -X /home/gpc/p/script/gpcdiff.exclude orig/p/doc/en/todo.texi p/doc/en/todo.texi |--- orig/p/doc/en/todo.texi Thu Dec 20 21:07:45 2001 |+++ p/doc/en/todo.texi Fri Dec 28 05:49:06 2001
File to patch:
what do I type now ?
You could enter doc/en/todo.texi. But if this file exists, patch should have found it by itself (I don't know what's wrong then), and if it doesn't, you're in the wrong directory, anyway.
BTW, you did this in the source directory, not in the build directory (with the object files), didn't you?
Oh, I see in your other mail:
gpc version 19990118, based on gcc-2.8.1
This is a rather old version. Of course, the patch won't apply against that version. You need the current GPC sources first.
What kind of version for GNU Patch do you have ?
I have 2.5.4 here.
Do I have to compile, ./configure, make or install after patching ?
I general, all of them. In this particular case, a new ./configure is not required. Just make and install.
Frank
-- Frank Heckenbach, frank@g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html
Morten Gulbrandsen wrote:
I found no binary for FreeBSD on your homepage, However I found this gpc-2.0_1 A free 32-bit Pascal compiler Long description | Sources | Main Web Site Maintained by: antonz@library.ntu-kpi.kiev.ua Requires: autoconf213-2.13.000227, gcc-2.8.1, gettext-0.10.35, gmake-3.79.1, m4-1.4_1
under http://www.freebsd.org/ports/lang.html
And this is prepared for freeBSD,
gpc version 19990118, is my version, and I downloaded ist quite recently, So I have no reason to believe that my version is newer than the FreeBSD prepared port ?
Probably not. However, you can find the current sources as a tar.gz archive and on the CVS server. If you want to follow the latest changes (such as the patches occasionally posted here), you will need the most current sources. Alternatively you can wait for the next release which will incorporate these changes. Our sources are currently updated once in a few weeks. When FreeBSD ports are updated, I don't know.
My problem is comparing gpc version 19990118 with gpc-2.0_1. Let me guess ?
Is 19990118 similar to year = 1999 and version 0118 = 1.1_8 after disregarding the Most Significant Bit ?
Much simpler: 1999-01-18 = 18 Jan 1999.
And can I compare gpc-2.0_1 as the current release and my 1.1_8 as not quite up to date ?
I don't know who made up the version 2.0_1. Perhaps a numbering used by the FreeBSD ports. 2.0 was the last "official" GPC release (many years ago, 1996 or so). 2.1 will be the next one, coming soon. In the meantime, we just use dates.
under this url ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/current/binary/
I would have expected to find some binary for FreeBSD,
After the release of 2.1, we'll try to get binaries there for as many systems as possible.
Or at least a README.FreeBSD
Why? AFAIK, there's nothing special WRT FreeBSD, compared to other Un*x systems. Compiling from the sources should work just the same.
Frank
Morten Gulbrandsen wrote:
I found no binary for FreeBSD on your homepage, However I found this gpc-2.0_1 A free 32-bit Pascal compiler Long description | Sources | Main Web Site Maintained by: antonz@library.ntu-kpi.kiev.ua Requires: autoconf213-2.13.000227, gcc-2.8.1, gettext-0.10.35, gmake-3.79.1, m4-1.4_1
Probably not. However, you can find the current sources as a tar.gz archive and on the CVS server.
I can probably make binary snapshots from CVS once in every two weeks without problems, if the build process works usually.
next release which will incorporate these changes. Our sources are currently updated once in a few weeks. When FreeBSD ports are updated, I don't know.
That depends on
1) the maintainer (the one who sends requests to the FreeBSD committers) 2) the backlog of the committers themselves.
2) is a serious problem, and they often have a backlog of several weeks afaik. The same applies to Debian. The time between submitting and actuallisation can be quite long afaik. (FPC experience, not GPC) SUSE is quite fast OTOH.
I don't know who made up the version 2.0_1. Perhaps a numbering used by the FreeBSD ports. 2.0 was the last "official" GPC release (many years ago, 1996 or so). 2.1 will be the next one, coming soon. In the meantime, we just use dates.
Often FreeBSD adds some digits to signal the revision of the port. This because the port can apply patches to fix FreeBSD specific problems (both functional and with building)
So if 2.1 is the GPC release 2.1p1 signals revision 1 of the port (port-makefile +patches), p2 the second etc.
After the release of 2.1, we'll try to get binaries there for as many systems as possible.
Or at least a README.FreeBSD
Why? AFAIK, there's nothing special WRT FreeBSD, compared to other Un*x systems. Compiling from the sources should work just the same.
FreeBSD is the system that most closely resembles Linux. If something works on Linux, and is not based largely on specific kernel revisions, it should be able to work in native mode too.
I had some problems with the terminal driver though. (accessing "special" display functions not defined by vt<xxx>)
Thank you for this reply,
I now wish that the maintainer of the FreeBSD port could comment this, so that one unambiguous FreeBSD port could be created and distributet.
If Mr. or Ms. "antonz@library.ntu-kpi.kiev.ua" is not on this mailing list, I think someone should inform him or her.
I choose FreeBSD because no other operating system so easy can install new compilers. Linux has the problem, that Red Hat, SuSE, debian and "you name it" requires knowledge about configuring the operating system. So that it is difficult to create one universal Linux port running everywhere. rpm -i compilerxyz.rpm is by far the best solution I know, but still the linux distributors has minor changes. I feel. But I never attempted to install gpc on any linux.
Yours Sincerely
Morten Gulbrandsen
Marco van de Voort wrote:
Morten Gulbrandsen wrote:
I found no binary for FreeBSD on your homepage, However I found this gpc-2.0_1 A free 32-bit Pascal compiler Long description | Sources | Main Web Site Maintained by: antonz@library.ntu-kpi.kiev.ua Requires: autoconf213-2.13.000227, gcc-2.8.1, gettext-0.10.35, gmake-3.79.1, m4-1.4_1
Probably not. However, you can find the current sources as a tar.gz archive and on the CVS server.
I can probably make binary snapshots from CVS once in every two weeks without problems, if the build process works usually.
I think CVS as Concurrent Version System is too complicated for me. I prefer not to install or use CVS. But thanks anyway :-)
next release which will incorporate these changes. Our sources are currently updated once in a few weeks. When FreeBSD ports are updated, I don't know.
That depends on
the maintainer (the one who sends requests to the FreeBSD committers)
the backlog of the committers themselves.
is a serious problem, and they often have a backlog of several weeks afaik.
The same applies to Debian. The time between submitting and actuallisation can be quite long afaik. (FPC experience, not GPC) SUSE is quite fast OTOH.
Interesting !
I don't know who made up the version 2.0_1.
Maintained by: antonz@library.ntu-kpi.kiev.ua
Perhaps a numbering used by the FreeBSD ports. 2.0 was the last "official" GPC release (many years ago, 1996 or so). 2.1 will be the next one, coming soon. In the meantime, we just use dates.
Often FreeBSD adds some digits to signal the revision of the port. This because the port can apply patches to fix FreeBSD specific problems (both functional and with building)
So if 2.1 is the GPC release 2.1p1 signals revision 1 of the port (port-makefile +patches), p2 the second etc.
After the release of 2.1, we'll try to get binaries there for as many systems as possible.
Or at least a README.FreeBSD
Why? AFAIK, there's nothing special WRT FreeBSD, compared to other Un*x systems. Compiling from the sources should work just the same.
OK.
FreeBSD is the system that most closely resembles Linux. If something works on Linux, and is not based largely on specific kernel revisions, it should be able to work in native mode too.
I had some problems with the terminal driver though. (accessing "special" display functions not defined by vt<xxx>)
If there are major problems with gpc under FreeBSD I think we should discuss it. This "display function" was no problem for me, could you describe it further, then I'll investigate it.
Yours Sincerely
Morten Gulbrandsen
Thank you for this reply,
I'm interested in FreeBSD, mainly with FPC, but I keep an eye on (L)GPL'ed GPC sources too.
I now wish that the maintainer of the FreeBSD port could comment this, so that one unambiguous FreeBSD port could be created and distributet.
I don't maintain the port. I simply have a snapshot machine running for FPC, and a fat pipe, and could make weekly or two weekly binary GPC snapshots from CVS if the buildprocess is not too complicated.
This is merely meant as convenience for FreeBSD GPC users, not as a sign that I want to take over the FreeBSD GPC port.
So that it is difficult to create one universal Linux port running everywhere.
I don't have problem so much, since FPC links the default runtime statically. So only more complex programs are dynamic.
FreeBSD is the system that most closely resembles Linux. If something works on Linux, and is not based largely on specific kernel revisions, it should be able to work in native mode too.
I had some problems with the terminal driver though. (accessing "special" display functions not defined by vt<xxx>)
If there are major problems with gpc under FreeBSD I think we should discuss it.
This was more a FreeBSD issue than a GPC issue. The FPC ide behaved odd on FreeBSD, it turned out that the cursor_normal, cursor_visible and cursor_invisible termcap entries seem to be empty.
Since ncurses also seems to use those (for curs_set) I'm wondering how to control the cursor shape if I'm running on the console. consio.h contains a call to switch between block or normal cursor only, and fbio.h only is valid for framebuffer devices.
But I'm a bit new to ncurses (made only commandline programs before). so it could be something I overlooked.
Marco van de Voort wrote:
So that it is difficult to create one universal Linux port running everywhere.
I don't have problem so much, since FPC links the default runtime statically.
So does GPC by default. But GPC itself is dynamically linked by default (though it's easy to build a static one, just add `-static' to CFLAGS when building), and there might be problems because of the differing directory structure between Linux distributions.
This was more a FreeBSD issue than a GPC issue. The FPC ide behaved odd on FreeBSD, it turned out that the cursor_normal, cursor_visible and cursor_invisible termcap entries seem to be empty.
Since ncurses also seems to use those (for curs_set) I'm wondering how to control the cursor shape if I'm running on the console. consio.h contains a call to switch between block or normal cursor only, and fbio.h only is valid for framebuffer devices.
But I'm a bit new to ncurses (made only commandline programs before). so it could be something I overlooked.
(Rather OT, but ...)
Yes, usually the terminfo entries should be set (I don't know if ncurses ever uses termcap; terminfo is the newer concept). Linux didn't support escape sequences to set the cursor shape until kernel 2.2 (see /usr/src/linux/Documentation/VGA-softcursor.txt), and after 2.2 came out, I added them to the Linux terminfo, so curs_set now works there. Don't know if FreeBSD supports those sequences.
I don't think ncurses supports calling special functions to set the cursor shape, and there's another problem with those: They won't work across telnet/ssh etc. (because they would go to the remote system where they'd at best fail, rather than to the local system where the terminal is).
Frank
Marco van de Voort wrote:
This was more a FreeBSD issue than a GPC issue. The FPC ide behaved odd on FreeBSD, it turned out that the cursor_normal, cursor_visible and cursor_invisible termcap entries seem to be empty.
Since ncurses also seems to use those (for curs_set) I'm wondering how to control the cursor shape if I'm running on the console. consio.h contains a call to switch between block or normal cursor only, and fbio.h only is valid for framebuffer devices.
But I'm a bit new to ncurses (made only commandline programs before). so it could be something I overlooked.
(Rather OT, but ...)
Not really. Maybe there is something in the GPC code base that has the same problems ;-)
Yes, usually the terminfo entries should be set (I don't know if ncurses ever uses termcap; terminfo is the newer concept).
My fault, terminfo it is. Confused them after reading too many manpages in quick succession.
Linux didn't support escape sequences to set the cursor shape until kernel 2.2 (see /usr/src/linux/Documentation/VGA-softcursor.txt), and after 2.2 came out, I added them to the Linux terminfo, so curs_set now works there. Don't know if FreeBSD supports those sequences.
No it doesn't. Those sequences all over the screen were the reason I found out about this problem :-)
I tried to find IOCTLs that do the same thing, but they only seem to exist for the framebuffer modi, not for plain text.
I don't think ncurses supports calling special functions to set the cursor shape, and there's another problem with those: They won't work across telnet/ssh etc. (because they would go to the remote system where they'd at best fail, rather than to the local system where the terminal is).
That wouldn't be a problem. The curs_set function returns -1 when not supported. So it could return a valid value on the console and -1 over telnet.
But thanks for the Linux links. I now know that that cursor stuff is not usually implemented, while I got the feeling of the man page for curs_set that it was normal.
I already posted to some FreeBSD groups, if I find out something interesting, I'll drop a note.
P.s. I also had some strange problems with writing to the last character on the screen. I found an old PR for that, that seems to imply that it is a known bug since 1999 (sigh)
Marco van de Voort wrote:
(Rather OT, but ...)
Not really. Maybe there is something in the GPC code base that has the same problems ;-)
Our CRT unit has a few non-portable routines (which don't even have a curses interface), but AFAIK all of them are known and documented in the unit. In particular, they are Sound/NoSound, TextMode, GetShiftState. The former is quite unimportant IMHO (only there for BP compatibility), so is the second mostly (most people set their text mode via SVGATextMode or run in a GUI window, and don't want their usual programs to mess with the size.
So the only thing I really miss is GetShiftState which we do via ioctl on Linux and other means on DJGPP and MS-Windows. I wish there were escape sequences for it ... perhaps someone will implement them in the future ... ;-)
I don't think ncurses supports calling special functions to set the cursor shape, and there's another problem with those: They won't work across telnet/ssh etc. (because they would go to the remote system where they'd at best fail, rather than to the local system where the terminal is).
That wouldn't be a problem. The curs_set function returns -1 when not supported. So it could return a valid value on the console and -1 over telnet.
In theory perhaps. In practice I guess most programmers would just test it on their local system and not bother to check the return value ...
But thanks for the Linux links. I now know that that cursor stuff is not usually implemented, while I got the feeling of the man page for curs_set that it was normal.
If it documents an error code for "not supported", apparently it isn't supported everywhere. ;-)
P.s. I also had some strange problems with writing to the last character on the screen. I found an old PR for that, that seems to imply that it is a known bug since 1999 (sigh)
The issue in general is known for a long time, but most terminals have solutions for it (including the Linux console and xterms, so I've never had a problem with it; actually I'd be surprised if FreeBSD had a problem with it). What's PR, BTW?
Frank
Marco van de Voort wrote:
(Rather OT, but ...)
Not really. Maybe there is something in the GPC code base that has the same problems ;-)
Our CRT unit has a few non-portable routines (which don't even have a curses interface), but AFAIK all of them are known and documented in the unit. In particular, they are Sound/NoSound, TextMode, GetShiftState. The former is quite unimportant IMHO (only there for BP compatibility), so is the second mostly (most people set their text mode via SVGATextMode or run in a GUI window, and don't want their usual programs to mess with the size.
Pretty much the same here. The IDE implements some extra things to obtain a better look and feel, with a default for other cases (telnet/xterm).
Things like working alt-keys (kind of X mode, requires ctrl-alt to switch terms), the cursor stuff.
So the only thing I really miss is GetShiftState which we do via ioctl on Linux and other means on DJGPP and MS-Windows. I wish there were escape sequences for it ... perhaps someone will implement them in the future ... ;-)
I still have to do the keyboard. I did video first because that way I could visually check the working of the IDE better.
First tests indicate that I can get raw scan codes on FreeBSD via ioctl, but don't like that approach. (renders the keyboard unusuable if your handler hangs, and/or the exit is not graceful)
I don't think ncurses supports calling special functions to set the cursor shape, and there's another problem with those: They won't work across telnet/ssh etc. (because they would go to the remote system where they'd at best fail, rather than to the local system where the terminal is).
That wouldn't be a problem. The curs_set function returns -1 when not supported. So it could return a valid value on the console and -1 over telnet.
In theory perhaps. In practice I guess most programmers would just test it on their local system and not bother to check the return value ...
The IDE is an end user app, and I would fix that :_)
P.s. I also had some strange problems with writing to the last character on the screen. I found an old PR for that, that seems to imply that it is a known bug since 1999 (sigh)
The issue in general is known for a long time, but most terminals have solutions for it (including the Linux console and xterms, so I've never had a problem with it; actually I'd be surprised if FreeBSD had a problem with it). What's PR, BTW?
PR (IIRC patch-request) is a kind of bug submission to the FreeBSD core.
The odd part is that all code works fine on telnet/linux/in xterm, and only fails on FreeBSD console.
Marco van de Voort wrote:
Pretty much the same here. The IDE implements some extra things to obtain a better look and feel, with a default for other cases (telnet/xterm).
Things like working alt-keys (kind of X mode, requires ctrl-alt to switch terms),
That's one thing I would certainly *not* do in a normal app. It's the user's choice what Alt-Fn should do. The default (unfortunately) is to chvt, but it's easy to change it (and I did so on my system). So the apps should (and mine do) handle Alt-Fn normally (perhaps providing an alternative, like I do with Alt-n) and not mess the keyboard mode.
First tests indicate that I can get raw scan codes on FreeBSD via ioctl, but don't like that approach. (renders the keyboard unusuable if your handler hangs, and/or the exit is not graceful)
And, worst of all, destroys the user's key mapping. I wouldn't use any program which does this.
The odd part is that all code works fine on telnet/linux/in xterm, and only fails on FreeBSD console.
I guess it's a FreeBSD console problem then. (Do I get the price for the most clever answer of the year? ;-)
Frank
-
Emil Jerabek -
Frank Heckenbach -
marcov＠stack.nl -
morten.gulbrandsen＠t-online.de