-
Notifications
You must be signed in to change notification settings - Fork 127
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Integration Test Failure: phi/unphi
alters xmir
file
#3373
Comments
phi/unphi
alters xmir
file
@yegor256 @maxonfjvipon Could you take a look, please? |
@volodya-lombrozo as a general rule, don't use |
@volodya-lombrozo the XMIR in "was" section we get after parsing step. It's raw and not ready for any manipulations, including converting to phi. It does not have object FQNs starting with bytecode -> (disassemble) Here you can try to compare XMIRs after |
If it is so, it means, that
bytecode -> (disassemble) xmir -> (optimize) phi -> unphi -> xmir (assemble) -> bytecode. What do you mean by "include optimize step explicitly to your pipeline"? And why should I disable |
@maxonfjvipon I can try to generate "optimised" |
Now your pipeline is: bytecode -> (disassemble) xmir ->>> (optimize + to-phi) phi -> unphi ->>> xmir (assemble) -> bytecode. Triple arrows
The suggested pipeline: bytecode -> (disassemble) xmir -> (optimize) xmir ->>> (no optimize) phi -> unphi ->>> xmir (assemble) -> bytecode. Here you explicitly calls Then you can compare XMIR (1) and XMIR (2). They should be the same and you test should work |
You just need to call "optimize" goal of |
@maxonfjvipon Why do I need to compare this Ok, let me explain the problem one more time: The
That's it. If I apply any optimisation (at any point), this I'm looking for a way to make I see only two paths for now:
|
@volodya-lombrozo |
@volodya-lombrozo let's stop using
Here, This will make your output very close to the output of |
@yegor256 Sure. At least it's a good first step. Thank you. As soon, as I implement this, I will send you updated files. <o base="seq" name="@">
</o> vs. <o base=".seq" name="@">
</o> It would be great to understand the semantic difference between both of them |
@volodya-lombrozo first of all, as Yegor said above there is no such object Globally, There are 2 different notations for dispatching, which are used in EO:
In XMIR it may look like: <o base="org.eolang.seq"/>
// OR
<o base="Q.org.eolang.seq"/>
// OR
<o base="Q"/>
<o base=".org" method=""/>
<o base=".eolang" method=""/>
<o base=".seq" method=""/>
// OR
<o base="$"/>
<o base=".instructions" method=""/> At the level of XMIR such notation is not canonical and during
It works the same as direct notation but it looks like the sequence of applications. At the level of EO every object that is used as method ENDS with dot. In XMIR it look like: <o base=".seq">
<o base=".eolang">
<o base=".org">
<o base="Q"/>
</o>
</o>
</o>
// OR
<o base=".seq">
<o base=".eolang">
<o base="org"/>
</o>
</o>
// OR
<o base=".instructions">
<o base="$"/>
</o> Here all objects that are used as methods STARTS with dot. |
@volodya-lombrozo So this it how JEO should print in order to not get into a trouble: <o base=".seq48">
<o base=".eolang">
<o base=".org">
<o base="Q"/>
</o>
</o>
<o base="opcode" line="1913064591"/>
<o base="opcode" line="1913064591"/>
<o base="opcode" line="1913064591"/>
<o base="opcode" line="1913064591"/>
...
</o> |
@yegor256 @maxonfjvipon Now Exception trace[INFO] --- eo:0.39.0:phi-to-xmir (phi-to-xmir) @ phi-unphi-it ---
[INFO] 45 attributes loaded from 39 stream(s) in 6ms, 45 saved, 456 ignored: ["Archiver-Version", "Automatic-Module-Name", "Bnd-LastModified", "Build-Jdk", "Build-Jdk-Spec", "Built-By", "Bundle-ContactAddress", "Bundle-Description", "Bundle-DocURL", "Bundle-License", "Bundle-ManifestVersion", "Bundle-Name", "Bundle-RequiredExecutionEnvironment", "Bundle-SymbolicName", "Bundle-Vendor", "Bundle-Version", "Created-By", "EO-Dob", "EO-Revision", "EO-Version", "Export-Package", "Extension-Name", "Implementation-Build", "Implementation-Title", "Implementation-URL", "Implementation-Vendor", "Implementation-Vendor-Id", "Implementation-Version", "Import-Package", "Include-Resource", "JCabi-Build", "JCabi-Date", "JCabi-Version", "Main-Class", "Manifest-Version", "Multi-Release", "Originally-Created-By", "Project-Name", "Require-Capability", "Specification-Title", "Specification-Vendor", "Specification-Version", "Tool", "X-Compile-Source-JDK", "X-Compile-Target-JDK"]
[INFO] Parsed to xmir: /Users/lombrozo/Workspace/EOlang/jeo-maven-plugin/target/it/phi-unphi/target/generated-sources/eo-phi/org/eolang/hone/App.phi -> /Users/lombrozo/Workspace/EOlang/jeo-maven-plugin/target/it/phi-unphi/target/generated-sources/eo-unphi/org/eolang/hone/App.xmir
[INFO] Parsed 1 phi files to xmir
[ERROR] 1 files with parsing errors were found: [org/eolang/hone/App.phi]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 7.689 s
[INFO] Finished at: 2024-09-17T13:36:02+03:00
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.eolang:eo-maven-plugin:0.39.0:phi-to-xmir (phi-to-xmir) on project phi-unphi-it: 'org.eolang.maven.UnphiMojo@521c67f0' execution failed: java.lang.IllegalStateException: 1 files with parsing errors were found: [org/eolang/hone/App.phi] -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.eolang:eo-maven-plugin:0.39.0:phi-to-xmir (phi-to-xmir) on project phi-unphi-it: 'org.eolang.maven.UnphiMojo@521c67f0' execution failed
at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2 (MojoExecutor.java:333)
at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute (MojoExecutor.java:316)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:212)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:174)
at org.apache.maven.lifecycle.internal.MojoExecutor.access$000 (MojoExecutor.java:75)
at org.apache.maven.lifecycle.internal.MojoExecutor$1.run (MojoExecutor.java:162)
at org.apache.maven.plugin.DefaultMojosExecutionStrategy.execute (DefaultMojosExecutionStrategy.java:39)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:159)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:105)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:73)
at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:53)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:118)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:261)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:173)
at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:101)
at org.apache.maven.cli.MavenCli.execute (MavenCli.java:904)
at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:281)
at org.apache.maven.cli.MavenCli.main (MavenCli.java:204)
at jdk.internal.reflect.DirectMethodHandleAccessor.invoke (DirectMethodHandleAccessor.java:103)
at java.lang.reflect.Method.invoke (Method.java:580)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:255)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:201)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:361)
at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:314)
Caused by: org.apache.maven.plugin.MojoFailureException: 'org.eolang.maven.UnphiMojo@521c67f0' execution failed
at org.eolang.maven.SafeMojo.exitError (SafeMojo.java:391)
at org.eolang.maven.SafeMojo.execute (SafeMojo.java:292)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo (DefaultBuildPluginManager.java:126)
at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2 (MojoExecutor.java:328)
at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute (MojoExecutor.java:316)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:212)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:174)
at org.apache.maven.lifecycle.internal.MojoExecutor.access$000 (MojoExecutor.java:75)
at org.apache.maven.lifecycle.internal.MojoExecutor$1.run (MojoExecutor.java:162)
at org.apache.maven.plugin.DefaultMojosExecutionStrategy.execute (DefaultMojosExecutionStrategy.java:39)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:159)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:105)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:73)
at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:53)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:118)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:261)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:173)
at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:101)
at org.apache.maven.cli.MavenCli.execute (MavenCli.java:904)
at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:281)
at org.apache.maven.cli.MavenCli.main (MavenCli.java:204)
at jdk.internal.reflect.DirectMethodHandleAccessor.invoke (DirectMethodHandleAccessor.java:103)
at java.lang.reflect.Method.invoke (Method.java:580)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:255)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:201)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:361)
at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:314)
Caused by: java.util.concurrent.ExecutionException: java.lang.IllegalStateException: 1 files with parsing errors were found: [org/eolang/hone/App.phi]
at java.util.concurrent.FutureTask.report (FutureTask.java:122)
at java.util.concurrent.FutureTask.get (FutureTask.java:205)
at org.eolang.maven.SafeMojo.execWithTimeout (SafeMojo.java:340)
at org.eolang.maven.SafeMojo.execute (SafeMojo.java:274)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo (DefaultBuildPluginManager.java:126)
at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2 (MojoExecutor.java:328)
at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute (MojoExecutor.java:316)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:212)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:174)
at org.apache.maven.lifecycle.internal.MojoExecutor.access$000 (MojoExecutor.java:75)
at org.apache.maven.lifecycle.internal.MojoExecutor$1.run (MojoExecutor.java:162)
at org.apache.maven.plugin.DefaultMojosExecutionStrategy.execute (DefaultMojosExecutionStrategy.java:39)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:159)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:105)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:73)
at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:53)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:118)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:261)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:173)
at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:101)
at org.apache.maven.cli.MavenCli.execute (MavenCli.java:904)
at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:281)
at org.apache.maven.cli.MavenCli.main (MavenCli.java:204)
at jdk.internal.reflect.DirectMethodHandleAccessor.invoke (DirectMethodHandleAccessor.java:103)
at java.lang.reflect.Method.invoke (Method.java:580)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:255)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:201)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:361)
at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:314)
Caused by: java.lang.IllegalStateException: 1 files with parsing errors were found: [org/eolang/hone/App.phi]
at org.eolang.maven.UnphiMojo.exec (UnphiMojo.java:147)
at org.eolang.maven.SafeMojo.lambda$execWithTimeout$4 (SafeMojo.java:337)
at java.util.concurrent.FutureTask.run (FutureTask.java:317)
at java.util.concurrent.ThreadPoolExecutor.runWorker (ThreadPoolExecutor.java:1144)
at java.util.concurrent.ThreadPoolExecutor$Worker.run (ThreadPoolExecutor.java:642)
at java.lang.Thread.run (Thread.java:1583) As you can see, the exception message is still rather cryptic. I didn't grasp the idea about the problem. However the problem is still on Updated files for each transformation stage: App.phi.txt Hope, it will help. |
@maxonfjvipon Could you send the example of |
@volodya-lombrozo here it is: <o base="Q.org.eolang.seq48">
<o base="Q.org.eolang.jeo.opcode" line="1913064591"/>
<o base="Q.org.eolang.jeo.opcode" line="1913064591"/>
<o base="Q.org.eolang.jeo.opcode" line="1913064591"/>
<o base="Q.org.eolang.jeo.opcode" line="1913064591"/>
...
</o> |
@maxonfjvipon I should add |
@volodya-lombrozo let's just add |
@maxonfjvipon All of the rest is ok? |
@volodya-lombrozo I think so |
@maxonfjvipon I've tried to add I attach generated files by Please, let me know if they are suitable for you. |
@volodya-lombrozo I took your Is it enough for you? Please let me know if there's something wrong |
@maxonfjvipon I will take a closer look later. However, even for now I see, that resulting
|
@volodya-lombrozo how about this? |
@maxonfjvipon Again, we have such an excerpt from the <o base="org.eolang.seq6" line="77" name="@" pos="4">
<o as="0" base="org.eolang.jeo.label" line="82" pos="6">
<o as="0" base="bytes" data="bytes" line="83" pos="8">32 35 36 62 30 35 61 31 2D 32 30 30 39 2D 34 34 61 39 2D 39 39 64 39 2D 64 63 61 30 66 61 33 39 39 33 62 39</o>
</o>
<o as="1" base="aload-1" line="85" pos="6"/>
<o as="2" base="invokespecial-2" line="87" pos="6"/>
<o as="3" base="return-3" line="89" pos="6"/>
<o as="4" base="org.eolang.jeo.label" line="94" pos="6">
<o as="0" base="bytes" data="bytes" line="95" pos="8">38 66 65 30 31 66 35 61 2D 65 34 65 61 2D 34 66 36 34 2D 62 39 31 34 2D 37 37 31 65 31 61 64 37 35 38 38 37</o>
</o>
</o> As you can see, we have the |
@volodya-lombrozo FYI, in your "golden" file |
@maxonfjvipon Thank you! You helped me to find the bug. Fixed it: |
@volodya-lombrozo in your example you have <o base="org.eolang.jeo.int" name="access" data="bytes" line="1656645624">00 00 00 00 00 00 00 03</o> After <o base="org.eolang.jeo.int" line="33" name="access" pos="4">
<o as="0" base="bytes" data="bytes" line="34" pos="6">00 00 00 00 00 00 00 04</o>
</o> Is it ok for you or I need to convert it back too? |
@maxonfjvipon It would be super-cool. By doing this you would be able to move forward much faster with other issues and optimizations. I wouldn't block you in this case. Otherwise you will need to wait when I finish with |
@volodya-lombrozo how about this one: What else am I missing? |
@volodya-lombrozo so how it should work:
new TrJoined<>(
new TrClasspath<>(
"/org/eolang/parser/wrap-method-calls.xsl"
).back(),
new TrDefault<>(
new StEndless(
new StClasspath(
"/org/eolang/parser/roll-bases.xsl"
)
)
),
new TrClasspath<>(
"/org/eolang/parser/add-refs.xsl",
"/org/eolang/parser/vars-float-down.xsl",
"/org/eolang/parser/roll-data.xsl"
).back()
) All the transformations are: After applying such pipeline to your example I got the XMIR from the comment above |
@maxonfjvipon I tested the solution you suggested. And it doesn't work. The reason is the following: Before any transformations we have the following opcode: <o base="org.eolang.jeo.opcode" line="999" name="return-C">
<o base="org.eolang.jeo.int" line="2123473584">
<o base="bytes" data="bytes">00 00 00 00 00 00 00 B1</o>
</o>
</o> After <o base="org.eolang.jeo.opcode"
data="bytes"
line="156"
name="return-C"
pos="4">00 00 00 00 00 00 00 B1</o> Which is wrong, of course. As usual, apply all the files generated. Hope, they will help: |
@volodya-lombrozo please replace |
@maxonfjvipon Seems, it fixed the problem with data values. Thank you. However, we have the following problem now: Before the unrolling <program dob="2024-07-29T12:22:21"
ms="206"
name="App"
revision="2fa8c4c"
time="2024-09-24T09:28:46.824585Z"
version="0.39.0">
...
</program> After the unrolling: <program dob="2024-07-29T12:22:21"
ms="743"
name="name"
revision="2fa8c4c"
time="2024-09-24T09:28:49.036703Z"
version="0.39.0">
...
</program> As you can see, the attribute |
@volodya-lombrozo this name is taken from the name of the Are you sure you save the |
@maxonfjvipon All files have either |
@volodya-lombrozo check this one, I think |
@maxonfjvipon I see. Yes, it seems so. Please, read this ticket #3380 This is the bug in |
@maxonfjvipon I continue encounter problems with "unroll" transformation. Before unrolling: <o base="org.eolang.seq1" line="25475240" name="exceptions">
<o base="org.eolang.jeo.string" line="685670964">
<o base="bytes" data="bytes">6A 61 76 61 2F 6C 61 6E 67 2F 45 78 63 65 70 74 69 6F 6E</o>
</o>
</o> After unrolling: <o base="org.eolang.jeo.string"
line="62"
name="signature"
pos="18">
<o base="bytes" data="bytes" line="63" pos="6"/></o>
<o base="org.eolang.seq1" line="64" name="exceptions" pos="14">
<o base="bytes" data="bytes">6A 61 76 61 2F 6C 61 6E 67 2F 45 78 63 65 70 74 69 6F 6E
</o>
</o> Full files: |
@volodya-lombrozo can you please send me your XMIR after |
@maxonfjvipon I didn't applied |
@volodya-lombrozo yes, because it tries to convert "canonical" XMIR (which you get after phi, unphi) to XMIR ready to be converted to bytecode |
@volodya-lombrozo can we close this one? |
@maxonfjvipon Yes, sure. Thank you for the support. |
I run the following integration test:
bytecode -> (disassemble)
xmir
->phi
->unphi
->xmir
(assemble) -> bytecode.And this test fails because
phi/unphi
alter the originalxmir
file.Steps to reproduce:
App.xmir
fromApp.class
file (jeo:disassemble
):App.xmir.disassemble.txt
eo:0.39.0:xmir-to-phi
to generateApp.phi
:App.phi.txt
eo:0.39.0:phi-to-xmir
to generateApp.xmir
(and it is generated):App.xmir.unphi.txt
Expected behaviour:
App.xmir.disassemble.txt
andApp.xmir.unphi.txt
files should be the same. In other words,phi/unphi
does nothave to change the original
xmir
file.Actual behaviour:
App.xmir.disassemble.txt
andApp.xmir.unphi.txt
files are different.phi/unphi
significantly changes the originalxmir
.Details:
Was:
Became:
App.phi.txt
App.xmir.disassemble.txt
App.xmir.unphi.txt
The text was updated successfully, but these errors were encountered: