Re: [open-cobol-list] X86_64 branch ?

[Patrick]

Hi Ron

It's nice to hear the vote of confidence for Roger's work.

I do want to mention that what I am suggesting is only to complement the main trunk and not to replace it. A simpler, developed-in-parallel, approachable compiler would also make an easier target for documentation writers who could then make it even more approachable.

Again the code base is quite small. I have version 1.1 printed actually.

-Patrick

 




On 24/02/14 02:39 PM, Ron Norman wrote:

A small comment on the 'code base'. If you are referring to the compiler itself.

In the recent work I did to add 'report writer' I did find that I had to read thru the code a fair bit and do some trial and error to understand how it all fits together.

I think a lot of this code is from Roger While. After investing some time to understand it all I would have to say that it is very well written.

But you can not just jump into it, you have to work with to see how it all fits together.

Having done that, I now understand it and I would not make many changes to the way the compiler code is organized.

On Mon, Feb 24, 2014 at 11:27 AM, Patrick <address@hidden> wrote:

I asked Joe's permission to respond to his email to the list as well. I think his perspectives will benefit all.

Hi Joe

Thanks for answering my post.

So maybe I shouldn't have framed this as mainframe vs desktop. There are many Unixes. A better way perhaps should have been Desktop vs other hardware.

About the standards thing... I have heard others say this too, so adding non standard stuff to the core would like spark a holy war.

My main concern with GNUcobol is that there are hardly any libraries and what's worse is that there are very limited mechanisms to even build a library. How likely is it that someone would be able to generate a new codebase that is deployed as a TUI and still charge decent money for it? My main focus is not supporting old code so that a company can limp along with it for a few more years, I love Cobol and I want to write new code. As-is, it is not presentable in my industry and is not financially viable for commercial work.

If anything that needs to be added, needs to be in the standard first then the project is going to be severely stunted, that is, "IF", the main mechanism that code sharing takes place is contributions to the core language itself.

Library code on the other hand can be used or not used and there is nothing to war over.

I have all sorts of half-baked ideas and I am throwing most of them in the garbage myself as I learn more but some may have value and I will post them in separate threads to keep this one tidy though.

I would also like to mention  that I can't even prototype a half-baked idea with the current codebase, it's overwhelming for me.

There are lots of features in the standard that are not implemented and we have also moved outside the standard before with the level 66 constant and we haven't yet talked about expanding test harnesses or debugging existing code.

If the codebase was easier to manage, more people could contribute and the project would be more a viable alternative to microfocus. The actual number of lines of code is not that much but it's scary to touch it when it's so cross architecture.

Finally, if no one is posting to the list, that doesn't mean that no one is gaining benefit from the project but if more people could contribute, we might have more posts and more ideas would emerge.

-Patrick





On 24/02/14 12:35 PM, Ron Norman wrote:

Hi Patrick,

I have done a small bit of work on OpenCOBOL (ISAM file support and recently REPORT WRITER) but due to my work I have access to half a dozen different versions of Unix systems so I can verify the code changes work on at least some different platforms. But I have no access to any mainframe systems.

I have training in compiler construction and worked on a commercial COBOL compiler in the past.

COBOL is very standards based so if/when adding feature FOO you need to make sure that FOO is part of the ANSI/CODASYL standard for COBOL.

If feature FOO is not a missing feature that is documented then I would think that it should not be added to OpenCOBOL/GNUcobol.

The very nice feature of COBOL is that it is standards based and as people move their COBOL applications from system to system they will continue to work.

Just my view of things...

On Mon, Feb 24, 2014 at 6:51 AM, Patrick <address@hidden> wrote:

Hi Everyone

Day and night, my time is not my own(awake 4.5 hours last night). I
can't promise to contribute anything to the project but I can say that I
really want to and I have been trying.

I have read/am reading, books on Ncurses, Bison/Flex, Autotools and now
DB. Little by little I am starting to understand how things work but I
may still have as much as a year more to go at this pace.

I thought I would post a proposal and check if some facts I am operating
on are correct.

My facts:

1)Open Cobol goes back to 2001 and tinycobol precedes this.

2)Brian Understands the codebase

3)Sergey is making commits now

4)Joe has a fileio commit waiting for approval

5)There is a person(s) in Japan working on the code now but they are not
putting their name on it

6)> 99% of the code has been written by Keisuke and Roger

Is it fair to say that everyone that has committed code to the project
has access to a mainframe?

Is it fair to say that in the 13+ years of development < 10 people have
contributed code?

I repair circuit boards for a living and service spectrometers. If I am
intimidated with a codebase, it could easily be because I don't have
enough programming experience but it seems to me that this codebase is
very difficult for people to contribute to. It seems to me that there is
a lot of platform correction code and most of us don't have access to
many of the platforms.

If I want to add feature FOO how do I ensure it will work on an
architecture I will never have access to?

What if we created a branch and simplified the codebase? I would be
willing to try this, although I may never get the time to finish.

The main codebase could continue, the mainframe guys could take code as
they see fit and the desktop people could work away. Sure the two could
get out of sequence but at the pace things are moving at right now,
would that really be such a big deal?

-Patrick





------------------------------------------------------------------------------
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and generate reports.
Network behavioral analysis & security monitoring. All-in-one tool.
http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
_______________________________________________
open-cobol-list mailing list
address@hidden
https://lists.sourceforge.net/lists/listinfo/open-cobol-list

--
Cheers

Ron Norman

--
Cheers

Ron Norman