Open volodya-lombrozo opened 1 month ago
@volodya-lombrozo thanks for the report, here is a feedback:
I would recommend including expected versus actual results when executing the command, to identify where the discrepancy lies.
Please fix the bug report in order it to get resolved faster.
Analyzed with gpt-4
@yegor256 @maxonfjvipon Please, take a look. This problem happens rather often and it influences xmir-to-phi
transformation.
Examples:
@maxonfjvipon please, help us here
@volodya-lombrozo @yegor256 in the provided log processed XMIR is printed and it has 379 nested tuple
objects. I think it's too much for us:
(Stars on line 314, ends on line 690)
I see two scenarios:
tuple
we're using some mysterious atom which accepts unlimited amount of parameters. We'll use the atom only for jeo, opeo. So instead of:
tuple
tuple
tuple
tuple
tuple
...
tuple
tuple.empty
1
2
...
300
301
302
303
we'll get:
array
1
2
3
4
...
302
303
Since here we use EO and XMIR as IR - we don't need to run it, which means we can do it. The code's much more readable, does not contain so many nested object and should not cause unpredictable troubles related to large nesting.
WDYT?
@maxonfjvipon To be honest, I like the both suggestions. However, adding "mysterious" atoms might cause some problems in the future as well. I would suggest to try the first point first, then if we don't find anything satisfiable (or it will take significant time,) we can just go by the second path. What do you think? The first option seems a bit faster to solve. And I don't think we will have many of such long methods with ~> 300 instructions.
@maxonfjvipon Friendly reminder
@volodya-lombrozo here I found the info that such behaviour is related to insufficient stack size (which is 256M now). Also we can try to optimize XSLs so they use tail recursion instead of head one. So try to increase stack size for now via command line argument, it should help for now, and I'll check what I can do with tail recursion
@maxonfjvipon Thanks. I will try to increase stack size for now.
I am facing a problem with printing PHI expressions. I encountered the following exception when I ran
eo-maven-plugin:0.39.0:xmir-to-phi
:As you can see, the
set-locators.xsl
transformation uses too many nested function calls. This problem usually happens on Windows OS, and it's flaky. I have attached the full log below.build.log