Basically I just need to know does the DISPLAY function use ncurses or
is it just ordinary c output to stdout?
Also what ever happened to cobcurses? Is that still around?
If DISPLAY does not use curses... what was cobcurses for?
Basically from what I understand it depends on the platform AND if you
have defined Screen Section and/or using other than the simple format
for DISPLAY, ie.,
DISPLAY fred at 0101 (or lin 1 col 1) etc is full screen handling but:
DISPLAY FRED is not.
DISPLAY fred at 0101 (or lin 1 col 1) etc is full screen handling but:
DISPLAY FRED is not.
Thanks. In either case, do they use NCurses or is it just standard stdout? Or is the first Curses and the other is stdout?
Also I think in your Applewood you use the first format a lot if I recall. For instance I havfe a larger font when I am in Terminal (or most things actually) than others. So that even when I use CTRL-ALT F2/etc to switch to a TERMINAL ONLY screen, I had to reduce the font because I got a warning that your screen would not display becuase you needed larger number of lines. When I reduced the font size, giving me more lines, Applewood worked just find.
I will look at the program guide for SS and RW like you suggested.. In the other post that I wrote, I would actually like to create a separate manual specifically geared at User Inferface. I believe TUI, GUI, SS, and STDOUT (and maybe RW) could all be in that manual.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
DISPLAY fred at 0101 (or lin 1 col 1) etc is full screen handling but:
DISPLAY FRED is not.
Thanks. In either case, do they use NCurses or is it just standard
stdout? Or is the first Curses and the other is stdout?
Also I think in your Applewood you use the first format a lot if I
recall. For instance I havfe a larger font when I am in Terminal (or
most things actually) than others. So that even when I use CTRL-ALT
F2/etc to switch to a TERMINAL ONLY screen, I had to reduce the font
because I got a warning that your screen would not display becuase you
needed larger number of lines. When I reduced the font size, giving me
more lines, Applewood worked just find.
I will look at the program guide for SS and RW like you suggested.. In
the other post that I wrote, I would actually like to create a
separate manual specifically geared at User Inferface. I believe TUI,
GUI, SS, and STDOUT (and maybe RW) could all be in that manual.
I suggest you pass these questions to @Simon who would know exactly what
is used as my knowledge is some what limited as I think curses used
relates to what is installed prior to building the compiler and that
depends on the platform - I only use Linux as for me the Windows
implementations are a bit of a gods dinner when I tried to play using
Windows.
I was going to try and build a windows system using Visual Studio but
when I suggested that I was warned off because of one or more issues but
that was some time ago so have given up on it.
One issue I do have is building any application even consisting of 1 or
2 program as static applications so I can just issue them as ready to
run programs and that seems to depend on what libraries are used i.e.,
available as static libs against dynamic and in some cases they do not
seem to be available i..,e take a look at the needed libs when building
the compiler and runtime etc.
There should be no need to having to supply the source code for a end
user and s/he having to install the compiler in order to run it / them.
Extra manuals - yes I agree, documents for these areas are really needed
but the problem I find even with a Programming Reference is the lack of
information from any of the compiler programmers about what exactly they
have implemented for any of the Cobol functions when adding new code
and I am left guessing as to what is and that is NOT the way to go !
Good luck with this.
I will issue a copy of the Programming Reference in the next few hours /
days but first release will be the existing PG as that as suggested is
really a PR and start to remove the example elements from it. If nothing
else will cut down on the number of pages needed.
There should be no need to having to supply the source code for a end
user and s/he having to install the compiler in order to run it / them.
I agree. There is probably some way to statically compiler all the libraries we need? That would be my preferred method.
In cases of someone that knows how to use whatever distro.. sure you can create Packages for the package manager in question, but you have to do that with each system... which is why people are starting to use things like AppImage because thats one format for all systems, and with Windows 10 and the WSL (Windows Subsystem for Linux) the appimage would work there just as well. In any case... an executable with everything you need, would be useful.
While this might be the case for GnuCOBOL itself, maybe its useful maybe not, but certainly for our compiled programs.
Extra manuals - yes I agree, documents for these areas are really needed
but the problem I find even with a Programming Reference is the lack of
information from any of the compiler programmers about what exactly they
have implemented for any of the Cobol functions when adding new code
and I am left guessing as to what is and that is NOT the way to go !
Alright this is going to take a team then. I do not know how the GCC works so I would have to interface a lot with the others. With a team, it can be done.
I will issue a copy of the Programming Reference in the next few hours /
days but first release will be the existing PG as that as suggested is
really a PR and start to remove the example elements from it. If nothing
else will cut down on the number of pages needed.
When those are removed can they be copied to a separate document so we still have them easily and can start to move to create these guides? A lot of that detail is excellent.. and frankly some of it is as I see it, GnuCOBOL Evangelism explaining why COBOL, why GnuCOBOL and so on.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I agree. There is probably some way to statically compiler all the
libraries we need? That would be my preferred method.
In cases of someone that knows how to use whatever distro.. sure you
can create Packages for the package manager in question, but you have
to do that with each system... which is why people are starting to use
things like AppImage because thats one format for all systems, and
with Windows 10 and the WSL (Windows Subsystem for Linux) the appimage
would work there just as well. In any case... an executable with
everything you need, would be useful.
While this might be the case for GnuCOBOL itself, maybe its useful
maybe not, but certainly for our compiled programs.
Alright this is going to take a team then. I do not know how the GCC
works so I would have to interface a lot with the others. With a team,
it can be done.
When those are removed can they be copied to a separate document so we
still have them easily and can start to move to create these guides? A
lot of that detail is excellent.. and frankly some of it is as I see
it, GnuCOBOL Evangelism explaining why COBOL, why GnuCOBOL and so on.
As I said I will copy over the current PG to a new PR as is.
Then over a few days/weeks remove the example stuff out of the PR
(Programmers Reference) hopefully leaving a Reference document.
As for the PG, I will leave that to another to change or replace for the
PG (Programmers Guide)
Basically I just need to know does the DISPLAY function use ncurses or is it just ordinary c output to stdout?
Also what ever happened to cobcurses? Is that still around?
If DISPLAY does not use curses... what was cobcurses for?
How much of Screen Section is implemented?
And report section?
On 10/10/2022 02:47, Aoirthoir An Broc wrote:
DISPLAY fred at 0101 (or lin 1 col 1) etc is full screen handling but:
DISPLAY FRED is not.
I, could be wrong here :(
See the prog guide.
Vince
Thanks. In either case, do they use NCurses or is it just standard stdout? Or is the first Curses and the other is stdout?
Also I think in your Applewood you use the first format a lot if I recall. For instance I havfe a larger font when I am in Terminal (or most things actually) than others. So that even when I use CTRL-ALT F2/etc to switch to a TERMINAL ONLY screen, I had to reduce the font because I got a warning that your screen would not display becuase you needed larger number of lines. When I reduced the font size, giving me more lines, Applewood worked just find.
I will look at the program guide for SS and RW like you suggested.. In the other post that I wrote, I would actually like to create a separate manual specifically geared at User Inferface. I believe TUI, GUI, SS, and STDOUT (and maybe RW) could all be in that manual.
On 10/10/2022 19:02, Aoirthoir An Broc wrote:
I was going to try and build a windows system using Visual Studio but
when I suggested that I was warned off because of one or more issues but
that was some time ago so have given up on it.
One issue I do have is building any application even consisting of 1 or
2 program as static applications so I can just issue them as ready to
run programs and that seems to depend on what libraries are used i.e.,
available as static libs against dynamic and in some cases they do not
seem to be available i..,e take a look at the needed libs when building
the compiler and runtime etc.
There should be no need to having to supply the source code for a end
user and s/he having to install the compiler in order to run it / them.
Extra manuals - yes I agree, documents for these areas are really needed
but the problem I find even with a Programming Reference is the lack of
information from any of the compiler programmers about what exactly they
have implemented for any of the Cobol functions when adding new code
and I am left guessing as to what is and that is NOT the way to go !
Good luck with this.
I will issue a copy of the Programming Reference in the next few hours /
days but first release will be the existing PG as that as suggested is
really a PR and start to remove the example elements from it. If nothing
else will cut down on the number of pages needed.
Vince
I agree. There is probably some way to statically compiler all the libraries we need? That would be my preferred method.
In cases of someone that knows how to use whatever distro.. sure you can create Packages for the package manager in question, but you have to do that with each system... which is why people are starting to use things like AppImage because thats one format for all systems, and with Windows 10 and the WSL (Windows Subsystem for Linux) the appimage would work there just as well. In any case... an executable with everything you need, would be useful.
While this might be the case for GnuCOBOL itself, maybe its useful maybe not, but certainly for our compiled programs.
Alright this is going to take a team then. I do not know how the GCC works so I would have to interface a lot with the others. With a team, it can be done.
When those are removed can they be copied to a separate document so we still have them easily and can start to move to create these guides? A lot of that detail is excellent.. and frankly some of it is as I see it, GnuCOBOL Evangelism explaining why COBOL, why GnuCOBOL and so on.
On 11/10/2022 19:18, Aoirthoir An Broc wrote:
As for the PG, I will leave that to another to change or replace for the
PG (Programmers Guide)
Vince