Is anyone interested in getting the 'trunk' version moved out as GnuCOBOL 4.0 and stop working on the 3.x version?
Many features have been lying in 'trunk' for several years now.
There is no planning being done for what is needed in 4.0 before it can be release (even though I have asked several times).
There is no reason to keep working on 3.x when any work done there will need to be merged (carefully) back into trunk/4.0.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Many people are interested in getting the trunk version to be released (and many also want the 3.x to get to 3.2.0 release).
In both cases the "nightly builds" provide anyone with a tarball to test the not-released versions.
... and most changes from 3.x go into 4.x with a simple merge, too - backed up by the testsuite.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Woohoo. Go Simon go. And Arnold, and Ron, and Marco, and Edward, and Vincent, and Denis, and, ... missing so many well deserved names here.
Go team.
I've been saying this with a hopeful tone for too many years now, but more than 10 years after we added world class programmers like Ron Norman in the mix, and all the advances made by everyone else, we are getting a little closer to trunk being lead, and lead being trunk, and the one true GnuCOBOL stream. (I sure hope I didn't just jinx it again by typing it out loud)
And a possible one time big fat auto reformat pass via indent or similar, so we can have the machines do the consistent source formatting, and a start at a real Doxygen commenting pass, and, and. Some of the side issues that don't really have much to do with COBOL, but do have a bit to do with the style and flair of everything surrounding the project, without worrying about creating unnecessary work. Which, not to discount all the improvements in that area already,..., but there have been some things I've been waiting for that would just make merges harder for no reason.
Now I think we can start looking forward to merges being new feature related and not just source lines out of place from extra comments or tabs out of place.
GnuCOBOL for the win.
Thanks, Simon.
Have good everyone,
Blue
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
For those who may not have read the news, GNU turned 40! We're proud to be part of it.
GnuCOBOL 3.2 has been out for a few months now (see the NEWS file for all the details), so some people are asking: what comes next?
Due to some bugs found in 3.2, there will be a 3.3 release to fix them. In addition, 3.3 will get a bit of performance improvement (not as much as in 3.2, but still useful), probably mostly around comparing numeric fields of USAGE DISPLAY, mostly provided by @chaat, and comparing those and BCD fields to zero (this is done so often that an optimization is useful).
3.3 possibly gets some file RECORD and LINE SEQUENTIAL features which @clademann and Ron added to trunk years ago backported (mostly depending on the question how much work this is and if it is possible to do that without breaking any backward compatibility), namely the assigned names starting with a redirection/pipe or having special names to declare a portable way for (stdin/stdout/stderr) as seen in other compilers. Also. we may get a new feature: built-in COBOL profiling, if @lefessan and the OCamlPro team, who also contributed to 3.2, finish it by then.
Speaking of OCamlPro, you might want to check out their GnuCOBOL resources at https://get-superbol.com/gnucobol/ including online versions of the Programmer's Guide and the Manual.
In addition to COBOLworx, there are now two options for support contracts (USA and France) with companies that have shown by their actions that they care about GnuCOBOL and by their contributions that they also have the technical knowledge to provide new features and bug fixes for GnuCOBOL.
Back to the "self" part of GnuCOBOL's state - It is expected that 3.3 gets out within the next two months.
Before GnuCOBOL trunk 4.x gets my full attention (starting with incorporating changes from 3.1 to now) and a preview release, I'll be working on V-ISAM.
Most of the work was done by Ron years ago, but so far this wonderful piece of software has not been shared on the official project page. This is mostly about the version control system (CVS was used before, which can only be accessed as a dump) and keeping a reasonable change history there, as the features and bug fixes have been coded long ago and going public with them is long overdue.
V-ISAM will also be the default handler for GnuCOBOL 4+ as it is much faster and more stable than the BDB backend, and has compatibility with the other ISAM handlers, including the ability to read/write the same indexed-sequential files as Micro Focus.
I hope to finish this in 2023.
👍
4
Last edit: Simon Sobisch 2023-10-16
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Is anyone interested in getting the 'trunk' version moved out as GnuCOBOL 4.0 and stop working on the 3.x version?
Many features have been lying in 'trunk' for several years now.
There is no planning being done for what is needed in 4.0 before it can be release (even though I have asked several times).
There is no reason to keep working on 3.x when any work done there will need to be merged (carefully) back into trunk/4.0.
Many people are interested in getting the trunk version to be released (and many also want the 3.x to get to 3.2.0 release).
In both cases the "nightly builds" provide anyone with a tarball to test the not-released versions.
... and most changes from 3.x go into 4.x with a simple merge, too - backed up by the testsuite.
October 2020+2
Well met, good news
Short note, seeing as I'm not really up on all the many many things happening around here, at the moment.
Simon has tagged an alpha of 3.2 (GNU version of the term for alpha.gnu.org tarball releases)
https://sourceforge.net/p/gnucobol/discussion/cobol/thread/8bab9208ac/?limit=25#1e02
With a list of his work items at
https://sourceforge.net/p/gnucobol/discussion/cobol/thread/8bab9208ac/?limit=25#f405
Woohoo. Go Simon go. And Arnold, and Ron, and Marco, and Edward, and Vincent, and Denis, and, ... missing so many well deserved names here.
Go team.
I've been saying this with a hopeful tone for too many years now, but more than 10 years after we added world class programmers like Ron Norman in the mix, and all the advances made by everyone else, we are getting a little closer to trunk being lead, and lead being trunk, and the one true GnuCOBOL stream. (I sure hope I didn't just jinx it again by typing it out loud)
And a possible one time big fat auto reformat pass via
indentor similar, so we can have the machines do the consistent source formatting, and a start at a real Doxygen commenting pass, and, and. Some of the side issues that don't really have much to do with COBOL, but do have a bit to do with the style and flair of everything surrounding the project, without worrying about creating unnecessary work. Which, not to discount all the improvements in that area already,..., but there have been some things I've been waiting for that would just make merges harder for no reason.Now I think we can start looking forward to merges being new feature related and not just source lines out of place from extra comments or tabs out of place.
GnuCOBOL for the win.
Thanks, Simon.
Have good everyone,
Blue
For those who may not have read the news, GNU turned 40! We're proud to be part of it.
GnuCOBOL 3.2 has been out for a few months now (see the NEWS file for all the details), so some people are asking: what comes next?
Due to some bugs found in 3.2, there will be a 3.3 release to fix them. In addition, 3.3 will get a bit of performance improvement (not as much as in 3.2, but still useful), probably mostly around comparing numeric fields of
USAGE DISPLAY, mostly provided by @chaat, and comparing those and BCD fields to zero (this is done so often that an optimization is useful).3.3 possibly gets some file
RECORDandLINE SEQUENTIALfeatures which @clademann and Ron added to trunk years ago backported (mostly depending on the question how much work this is and if it is possible to do that without breaking any backward compatibility), namely the assigned names starting with a redirection/pipe or having special names to declare a portable way for (stdin/stdout/stderr) as seen in other compilers. Also. we may get a new feature: built-in COBOL profiling, if @lefessan and the OCamlPro team, who also contributed to 3.2, finish it by then.Speaking of OCamlPro, you might want to check out their GnuCOBOL resources at https://get-superbol.com/gnucobol/ including online versions of the Programmer's Guide and the Manual.
In addition to COBOLworx, there are now two options for support contracts (USA and France) with companies that have shown by their actions that they care about GnuCOBOL and by their contributions that they also have the technical knowledge to provide new features and bug fixes for GnuCOBOL.
Back to the "self" part of GnuCOBOL's state - It is expected that 3.3 gets out within the next two months.
Before GnuCOBOL trunk 4.x gets my full attention (starting with incorporating changes from 3.1 to now) and a preview release, I'll be working on V-ISAM.
Most of the work was done by Ron years ago, but so far this wonderful piece of software has not been shared on the official project page. This is mostly about the version control system (CVS was used before, which can only be accessed as a dump) and keeping a reasonable change history there, as the features and bug fixes have been coded long ago and going public with them is long overdue.
V-ISAM will also be the default handler for GnuCOBOL 4+ as it is much faster and more stable than the BDB backend, and has compatibility with the other ISAM handlers, including the ability to read/write the same indexed-sequential files as Micro Focus.
I hope to finish this in 2023.
Last edit: Simon Sobisch 2023-10-16
Do you think this is the right time for an update on the status of the project??