Recent changes to tickets

#7 factor out a function for argc, argc with xpl -m

2020-07-04T10:19:00.620000Z

:-)

Yes and no. As I was about to try and write up a minimal. I can't quite get the incantations that left the descriptors unset. All works as advertised.

I was early exploring, and using sed to rename function entries generated, and when trying to reproduce, it all just works, Daniel, no traceback.

prompt$ make tryargs
xpl -I -m args.xpl
XPL to C language translator -- version 0.6
12 cards containing 9 statements were compiled.
No errors were detected.
args
XPL command line arguments
0 
date: 120186 (year - 1900) * 1000 + day of year
time: 2053243 centiseconds since midnight
GnuCOBOL/XPL trial complete

args.xpl as

/* display CLI args */
args: procedure;
  output = 'XPL command line arguments';
  output = argc || ' ' || argv(0);
  declare i bit(16);
  do i = argc - 1 to 1 by -1;
    output = '    ' || argv(i);
  end;
  output = 'date: ' || date || ' (year - 1900) * 1000 + day of year';
  output = 'time: ' || time || ' centiseconds since midnight';
end args;
eof

You can close this, I think. I can't find screen history for a transcript, It was a nice traceback from the XPL runtime. I was changing generated sources of both xpl0006 and cobc to experiment, and will take blame for mixing something up. It might have been a top level sans procedure label. :-)

Turns out there is no need to tweal code gen, and everything just works with -m.

I'll continue to explore where XPL might meld with COBOL. Nice work.

Cheers,
Blue

factor out a function for argc, argc with xpl -m

2020-07-04T04:50:04.226000Z

Hello,

Recently interested in XPL, and nicely done. If you are still updating any of this Daniel... this is a feature request.

I'm demoing some ways of integrating your XPL with GnuCOBOL, which also compiles to C. It would be nice to have the argc, argv predefined XPL variable descriptors filled in via function call and not just when main is emiited (the normal no -m option adds the argc argv init with access to field names which gets hidden in the XPL -> C, GnuCOBOL -> C, C->ELF tool chain. GnuCOBOL CALL only exposes link symbols to functions, and the emitted code has uneasy acces to C variable names.

Not that modular xpl0006 code is meant to know about the CLI, but XPL code that compiles fine can abend with report at runtime. Nice, by the way, but if the XPL code happens to access argc or argv() xpl builtins the script has no presets. Either a function wrapper to init the descriptors or assume just the program name?

Not a biggy in terms of priority or need (but also not completely useless). Whims of trying out a 1972 COBOL based library with a CALL interface into XPL domain specific command interpreters.

Hercules MVS3.8 Tk4-, with ANS COBOL 1972 and XPL from SHARE sources compile fine in 2020 GnuCOBOL and thanks to your port, xpl0006, with nice interopt on the modern side.

Sample of some of the efforts at https://sourceforge.net/p/open-cobol/discussion/contrib/thread/dca517cdd9

Have good, make well,
Blue, btiffin@gnu.org

factor out a function for argc, argc with xpl -m

2020-07-04T04:50:04.226000Z

Ticket 7 has been modified: factor out a function for argc, argc with xpl -m
Edited By: Daniel Weaver (shoefoot)
Status updated: 'open' => 'wont-fix'
_milestone updated: '1.0' => '2.0'
Owner updated: None => 'shoefoot'

#5 Hex constants at the end of a C compatible string are ignored

2018-01-10T05:33:09.947000Z

labels: --> 0.5
status: open --> closed

#6 Do loop iteration variable set too early

2018-01-10T05:31:38.820000Z

labels: --> 0.5
status: open --> closed

Do loop iteration variable set too early

2017-12-25T00:49:56.152000Z

The DO loop iteration variable gets set too early. If the iteration variable is used in the limit expression or the step, the DO loop will execute the wrong number of times.
declare x fixed;
x = 20;
do x = 0 to x;
/ This should loop 21 times /
end;

Do loop iteration variable set too early

2017-12-25T00:49:56.152000Z

Ticket 6 has been modified: Do loop iteration variable set too early
Edited By: Daniel Weaver (shoefoot)
Status updated: u'open' => u'closed'

Hex constants at the end of a C compatible string are ignored

2017-12-17T12:02:38.629000Z

When using C compatable strings a hex constant will be ignored if used as the last character of a string.
declare foo character initial("(c)\x31\x32");
The length of string foo is one. It should be length two.

Hex constants at the end of a C compatible string are ignored

2017-12-17T12:02:38.629000Z

Ticket 5 has been modified: Hex constants at the end of a C compatible string are ignored
Edited By: Daniel Weaver (shoefoot)
Status updated: u'open' => u'closed'

#4 64-bit COREWORD()

2017-12-16T06:57:34.342000Z

labels: --> 0.4
status: open --> closed