Open nmusatti opened 4 years ago
Hi Nicola,
thanks for the issue! I am developing under Mac OS and Linux, and so that error did not occur on my systems.
However, thanks to your issue in the last days I:
FileUtils.readFileToString
and the problematic LF-based custom code in da139ecc4f12ac929d10e32d166da4a0e61898e8 with Files.readString
, which was introduced in Java 11. The new Files.readString
hopefully should solve the problem. I will check this weekend on a Windows system, if the problem is solved. A short note from your side would be helpful, if it works for your now.
Thanks, Ulrich
Hi Ulrich,
Thank you for addressing my issue so promptly. Unfortunately my problem is still there. However it appears to be easily fixable by modifying the NEWLINE
constant in io.proleap.cobol.preprocessor.CobolPreprocessor
from
final static String NEWLINE = "\n";
to
final static String NEWLINE = System.lineSeparator();
With this change all tests pass for me on both Windows and Linux.
Hi Nicola,
I tested mvn clean test
on Windows 10 and ran into problems due to charset windows-1252. Therefore in 522630f4a438fb7a49cedb647044573fbd6fc878 I changed default charset to UTF-8. After this change on my Win 10 machine with JDK 11 and Maven 3.6.3 the test suite passes a mvn clean test
with Tests run: 823, Failures: 0, Errors: 0, Skipped: 2
-> BUILD SUCCESS
. The test suite also passes when running it in Eclipse on Windows 10.
I also thought about switching NEWLINE from \n
to System.lineSeparator()
. However, this would introduce platform-dependent behavior of the preprocessor, when it creates preprocessed COBOL code for the parser.
If the problem persists on your machine, please let me know. The next step would then be to identify the difference between our machines. If you have other questions regarding the parser, also let me know!
Ulrich
Hi Ulrich, It's your call obviously, but I'm not convinced that having the intermediate source platform dependent would be that bad. I assume that your main use case is to translate COBOL in something altogether different, however Antlr's TokenRewriteStream makes it very convenient to implement preprocessors. I used Antlr to replace embedded SQL calls with a proprietary implementation. I was actually looking for ways to "modernize" that project when I stumbled upon this one. In similar cases not preserving platform line endings might make it awkward for downstream tools. That said it's not overly important for me as Linux is going to be our main deployment platform. As soon as I have a moment I'll try and check which of my Windows machine settings may affect line endings.
Nicola
I cloned this project on a PC running Windows 10 and proceded to execute
mvn package
withThe result was:
Looking into the first failure, i.e.
io.proleap.cobol.preprocessor.copy.cobolword.variable.CopyCblWrdTest
I noticed that the expected string contains CR-LF sequences as line endings, while the actual string only LF. This happens because, while preprocessing replaces line endings with the LF character,FileUtils.readFileToString()
does not and on Windows test resources contain Windows line endings.A simple way to make tests pass would be to replace calls to
readFileToString()
with something like:However I wonder if this is the correct approach or if it wouldn't be better to make the preprocessor itself more platform independent. I only just started looking into this project and I don't have a clear idea of how things work.
Would you be interested in a pull request tackling Windows support? I ask because this project appears to have been quiescent for the last year and a half.