OT: Node-Cobol
msrobots
Posts: 3,709
Basically something for @heater. to try out.
The Web editor I made with him already supports COBOL syntax...
https://github.com/IonicaBizau/node-cobol
is a node wrapper for GnuCobol.
can look like this:
Sadly I do not do Linux and GitHub and all that modern stuff. Still using paper-tapes sometimes...
Gnu-Cobol is interesting by itself, since it compiles COBOL to C (or C++) code. So it COULD run on a Propeller, but it needs way more file system support as PropGCC is offering now. The main problem is that you can not statically link the resulting C files. GnuCobol needs dynamic linking.
So sadly no COBOL on the P1 yet, but maybe on the P2?
Anyways, just stumbled over node-cobol.
Mike
The Web editor I made with him already supports COBOL syntax...
https://github.com/IonicaBizau/node-cobol
is a node wrapper for GnuCobol.
can look like this:
// Dependencies
var Cobol = require("cobol");
// Execute some COBOL snippets
Cobol(function () { /*
IDENTIFICATION DIVISION.
PROGRAM-ID. HELLO.
ENVIRONMENT DIVISION.
DATA DIVISION.
PROCEDURE DIVISION.
PROGRAM-BEGIN.
DISPLAY "Hello world".
PROGRAM-DONE.
STOP RUN.
*/ }, function (err, data) {
console.log(err || data);
});
// => "Hello World"
Sadly I do not do Linux and GitHub and all that modern stuff. Still using paper-tapes sometimes...
Gnu-Cobol is interesting by itself, since it compiles COBOL to C (or C++) code. So it COULD run on a Propeller, but it needs way more file system support as PropGCC is offering now. The main problem is that you can not statically link the resulting C files. GnuCobol needs dynamic linking.
So sadly no COBOL on the P1 yet, but maybe on the P2?
Anyways, just stumbled over node-cobol.
Mike
Comments
Pah! You had it easy! When I started out in computing we still recorded bits individually on backing store using a pin hammer and pine needle on a wax cylinder. Cor, those were the days.
I think porting GnuCobol to the Propeller is an ideal pasttime for all those retired and nearly retired programmers of that era. Then Parallax will be in a position to expand their educational pursuits to include history.
I do not want to get into that 4 yorkshiremen thing of Monty Phyton.
So I do not argue with you about how hard it is to move a COURSOR around each day...
Actually it is just about PropGcc to support dynamic linking. This support is there in gcc but not used on the P1 version. Made no sense there without standardized file system support for SD cards or so.
But since the P2 is now (hopefully) getting solid form PropGcc development will start again. And as of now there are not 25 to 125 different boards out there to support because they where already there.
We have none currently for the P2. And no Chip layout either to produce one.
So just by documenting some standards for supported file systems for overlays or dynamic linked libraries for the new PropGcc compiler to actually USE that feature of gcc & friends it might be possible to get this done.
It is not about COBOL but about dynamic linking supported by the compiler. It is all in there in the Gnu Compiler Suite. And having 16 COGS I might really like to load some overlay to start some COG and then throw that overlay away and use the RAM for better stuff, until I need to restart that COG again, if even needed.
Sure I can write that by myself, and did on P1. But how cool it would be if PropGcc could do that for you, standardized and reusable?
And to go back to COBOL again, them SCREEN SECTIONS are still the best way to define a textual interface. Forget scanf and printf. And that is possible with a propeller, almost.
And to teach history might be quite needed. COBOL is not dead at all. Insurances, Banks, Stock Market, Military, Post Offices, Phone Companies, most of the mainframes in use, still run COBOL.
Sometimes programs developed 50 years ago and since then maintained, moved to other machines/compilers/places but still work. Millions of man hours in there.
You do not really believe that that printer printing your AT&T bill is run by a windows or Linux box programmed in C or/Basic/Perl/put whatever language you want?
But, like me, them COBOL Programmers are dying. Because of age, mostly.
At any day COBOL programs still do have 10 to 15 times more transactions as google has search requests.
This will be a serious problem in a couple of years.
Mike
That is admirable and sensible approach to development tools. I think the overlay technique is best considered for the Propeller due to it's multicore architecture and fully ram based processor core. Load POST and BIST when needed as overlay. An SD card gives good flexibilty, large storage and the ability to be read and written not just on a MCU based development board, but in a more heavy duty general purpose PC type machine, with SD card readers costing a couple of quid these days.
Yes, you've identified the lack of a legacy support requirement for the Propeller 2 in terms of board range.
Actually it is a quit nice implementation inside of JavaScript/node.
And since the COBOL source is in there you can now write self modifying COBOL code. How cool is that, hey?
I am really sad about the opinion of a lot of people about COBOL. As if it is a disease. Some Bartender at Olive Garden or so: Ah, you are programming COBOL, why do you not wear a suit and a tie? Never did that. Not needed. You need to be able to scan large files. COBOL is very alike the English language, lots of long words to type. But it is also almost self documenting because the source is - more or less - plain English.
COBOL invented a lot of things now used in 'modern' languages, like structured access to data-items. That is the basic way in COBOL to set up any variables. Then the beauty of output variable definitions. You just define your var as having - say leading zeros or spaces or '*', decimal comma and point at every 3 digits or any other stuff you like. Move your working var into the output var and conversion done.
Not thousands of sprinkled printf statements to format but screen sections or working storage items. And just in one place not all over the code. Easier to maintain.
Or take that include/library thing. COBOL does that different. There is a standard mechanism called CopyBooks. Works for all implementations of COBOL since decades. You can refer to a file and some lines of code in there by name AND rename data items to fit your needs. Sort of a include with followed search and replace. Very useful, if you get used to it. Sort of like macros in assembler help you to code.
In opposite to SPIN where you can have multiple var, dat and code sections, COBOL is very strict in how things are arranged in source. But that makes it damned easy to understand any COBOL program. Whatever you are looking for has to be in a specific section and the order of the sections is defined. A folding editor helps there a lot.
You know @heater. you complained about me putting everything of editor17 in one file. I did this because of the spinneret just having 4 sockets and getting chocked by the browser requesting 10 files at the almost same time. So I had to.
And - honestly - it was still below 12.000 lines or so, right? COBOL programs are often way longer. Or them CopyBooks.
Afraid of big source files?
Visual Studio starts chocking above 50.000 lines in a file. It really slows down then.
I do not care if the source is in different files or different areas of one file. Does not matter.
Enjoy!
Mike
Hmmm... self modifying COBOL...
"use strict"; const cobol = require("cobol"); class Cobol { program (name) { return ` IDENTIFICATION DIVISION. PROGRAM-ID. HELLO. ENVIRONMENT DIVISION. DATA DIVISION. PROCEDURE DIVISION. PROGRAM-BEGIN. DISPLAY "Hello ${name}". PROGRAM-DONE. STOP RUN. `; } run(arg) { const func = new Function(`return function () { /*${this.program(arg)}*/ };`)(); cobol(func, function (err, data) { console.log(err || data); }); } } const cob = new Cobol; cob.run("Albert"); cob.run("John"); cob.run("Fred");Well, that's JS modified COBOL but I'm sure we could arrange some COBOL to COBOL meta hacking here.I'll leave further comment on COBOL for node until I have played with it a bit more.
I actually don't have an issue with all code being in one huge file as a matter of principal and I did understand your reasons putting Editor 17 in one huge file.
What do I care where or how my code is stored as long as it nicely organized and I can find and get to what I want quickly and easily. Of course if you have an IDE that makes all that easy and fast you start to not care where the actual code is.
On the other hand organizing code into files has huge benefits:
1) For those of us hacking around in VIM it makes life much easier
2) Composability. Splitting code into multiple files by functionality makes it easy to swap parts in in and out as required.
5) Reuse. Often something you write is usable in many projects. Having those reusable parts in separate files makes it possible.
4) Source code management. When you are using git or some SCM system having a change history where the changes relate to particlar files is nice. If you have more than one developer git can can easily handle merging changes from all of them into a single file but it's a bit of handful to manage.
5) Isolation. Those odd global variables in a module are no longer global to the program. Which is nice.
Anyway. You need not have kept all that code in one huge file to satisfy the needs of the spinneret. All you had to do was concatenate all the modules into a single file before you load and run it. Then for optimization you could minimize it (strip out all white space) and compress it with zip.
Take a look at my current JS experiment here: http://xn--2-umb.net/ That uses over 3MB of Javascript! I have a bunch of libraries in there what with 3d graphics, a terminal emulator etc. All that JS and libraries is minified and compressed into a single "bundle" file of 278 KB http://xn--2-umb.net/assets/bundle.js. One can also add images and CSS etc to such a bundle to make for a single fetch over one socket connection.
Source code for that is here https://bitbucket.org/zicog/propanel/src/8a666e901c02762040401f8f257849dc0a8d4c6d/?at=master If you want to see how the webpack tool creates such bundles.
But I am pretty much slammed with work, taking care of a dement mother and trying to buy a house at the same time.
And multiplexing those three tasks leaves me no propeller time. I barely have the time to follow the forum.
I usually use Visual Studio as IDE. Got used to it over the decades. There is now some sort of VS community edition out there, for free, which is delivered in source form and supposed to be able to be compiled under Linux? Never tried that, since I have a full Version at work, reachable via Remote Desktop.
But even Editor17 itself was able to edit Editor17.htm. What I did on my server was to allow PUT requests to save a file. Standard http command alike GET. It is to replace a resource, not to retrieve it.
Visual Studio has a nice feature called 'go to definition' and another one called 'find all references to this whatever'. You can jump quit fast thru your code, following calls or so. It does not matter in what file of your project(s). So I usually also avoid large files for the reasons you mentioned.
Enjoy!
Mike