Long INCLUDE_MARKER paths confuses ktrans.exe (old versions only?)

[JeremyZoss]

Running ktransw.py automatically embeds header files into the karel source file, along with an "INCLUDE_MARKER", referencing the original include line. This Include Marker includes the full path to the include file. For long paths, this seems to exceed a maximum line length for ktrans.exe, which causes a compile error.

Here's a sample INCLUDE_MARKER line from fanuc_driver_exp/ros_traj.kl:

ROUTINE ap_proc_dsb(p_taskid: INTEGER):BOOLEAN FROM klutils-- INCLUDE_MARKER 164:D:\\Projects\\Overhead\\Fanuc mini-cell\\rossum\\src\\fanuc_driver_exp\\ros_traj.kl:2

And the resulting ktrans build error:

1566 sum\\src\\fanuc_driver_exp\\ros_traj.kl:2
   ^ ERROR
"BEGIN" expected.

I'm using /ver V7.30-1, to target the appropriate controller version. When I run with a current version (V8.30-1), there are no errors.

Feel free to close this issue as "WONTFIX". I just wanted to highlight a potential bug, even if it is for a fairly old controller version.

[gavanderhoorn]

I'm trying to replicate this, but I'm running into other errors trying to build fanuc_driver_exp with V7.30 (mostly STRINGs that are too long). Are you disabling builds of KUnit or have you modified any of the manifests?

[JeremyZoss]

Since I was interested in exploring what your build chain did under the hood, I ran things manually, using only ktransw and gpp. I explicitly built each source file, adding in include directories as needed. I only built the minimum set of required source files, which does not include KUnit.

I did need to make slight tweaks to ros_traj to work around a V7.30 limitation: no FLG[] support in Karel. Instead, I mapped a couple of DI/O to rack 34 (flag) and changed the karel FLG[] references to DIN or DOUT as appropriate. Other than that, no further tweaks were required to the source files.

[gavanderhoorn]

Reproduced it.

Interesting. This seems to be related to an overall (so both in Karel itself, but also in ktrans) string length limit of 128 instead of 254.

I've not done any work with system versions older than V7.70 so far with either rossum or ktransw, so had not run into this.

Thanks for reporting. I'll probably try and see whether I can add some work-around.

[gavanderhoorn]

I did need to make slight tweaks to ros_traj to work around a V7.30 limitation: no FLG[] support in Karel. Instead, I mapped a couple of DI/O to rack 34 (flag) and changed the karel FLG[] references to DIN or DOUT as appropriate

hm. I've used fanuc_driver under V6.40 and older systems, and I don't remember running into problems with FLG[] there.

I'll see if I can find that cell again.

---

Edit: at least according to system.ev it appears you're right: no FLG definition until V7.40. I'll see how I worked around that on 6.40 tomorrow.

[JeremyZoss]

Fanuc manuals agree. Karel Reference manual for V7.40 lists FLG under Language Elements: Predefined Identifiers. It's not found in V7.30 or V6.40.

[gavanderhoorn]

I've looked into this and it's not completely clear to me whether we can actually implement anything that would really resolve this - instead of working around it, as it seems this is a limitation of ktrans.exe for those older versions of system runtimes.

What should improve the situation already is if I'd introduce a newline between the %INCLUDE .. statement and the comment with the include marker.

(Really) long paths would still trigger the error, but for moderate length paths it could be enough.

[JeremyZoss]

I haven't dug into ktransw enough to know how you're using this include marker. Another potential solution would be to use relative paths for the file reference. That might be more independent of where the "workspace" is located on the PC's filesystem.

Alternatively, you could just list the filename itself (no path) as the INCLUDE marker. Karel files should have unique filenames, so the path is not strictly required. This might require some subdirectory-scanning to locate the true absolute path, depending on how you're using this include marker.

A 3rd solution would be to add a flag to prevent writing of INCLUDE_MARKER to the file. It appears as though this is a nicety added by gpp to facilitate consistent line numbering. In my experience, the line numbers of error messages generated from ktransw-processed code are not helpful anyway, since they reference lines in the include-expanded file (not the original source file). Removing these markers may not significantly affect the code output for many cases.

[gavanderhoorn]

A 3rd solution would be to add a flag to prevent writing of INCLUDE_MARKER to the file. It appears as though this is a nicety added by gpp to facilitate consistent line numbering. In my experience, the line numbers of error messages generated from ktransw-processed code are not helpful anyway, since they reference lines in the include-expanded file (not the original source file). Removing these markers may not significantly affect the code output for many cases.

this -- renumbering error output based on the markers -- is exactly what they are for :) I just haven't had a chance to implement the renumbering in ktransw.

That's the reason why I'd like to keep them around.

[gavanderhoorn]

Btw: even with error line renumbering the binaries will still show the line numbers of the flattened source. That would seem to be an unfortunate limitation of ktrans / the Karel runtime system.

See also #13.

No longer necessarily true.