Dashes do not help. No viable alternative at input `eo:0.46.0:phi-to-xmir` #3547

volodya-lombrozo · 2024-11-25T09:54:53Z

The issue is similar to this one: #3535 (comment)

In this case I added dashes to bytes, just to try, but the build failed.

How to reproduce:

I disassemble java bytecode by using jeo-maven-plugin:disassemble into xmir
Convert this xmir to phi by using eo-maven-plugin:0.43.0:xmir-to-phi
Convert the phi back to xmir by using eo-maven-plugin:0.43.0:phi-to-xmir

On the (3) step I get the exception:

org/eolang/hone/App.phi:
        [101:31] no viable alternative at input 'j$org↦⟦j$eolang↦⟦j$hone↦⟦j$App↦⟦version↦Φ.jeo.int(α0↦Φ.org.eolang.bytes(α0↦⟦Δ⤍00-00-00-00-00-00-00-34⟧)),access↦Φ.jeo.int(α0↦Φ.org.eolang.bytes(α0↦⟦Δ⤍00-00-00-00-00-00-00-21⟧)),supername↦Φ.jeo.string(α0↦Φ.org.eolang.bytes(α0↦⟦Δ⤍6A-61-76-61-2F-6C-61-6E-67-2F-4F-62-6A-65-63-74⟧)),interfaces↦Φ.org.eolang.seq0,j$Φ↦Φ.jeo.field(α0↦ξ.access-Φ,α1↦ξ.descriptor-Φ,α2↦ξ.signature-Φ,α3↦ξ.value-Φ,α4↦ξ.annotations-Φ),j$object@init@-%28%29V↦⟦access↦Φ.jeo.int(α0↦Φ.org.eolang.bytes(α0↦⟦Δ⤍00-00-00-00-00-00-00-01⟧)),descriptor↦Φ.jeo.string(α0↦Φ.org.eolang.bytes(α0↦⟦Δ⤍28-29-56⟧)),signature↦Φ.jeo.string(α0↦Φ.org.eolang.bytes),exceptions↦Φ.org.eolang.seq0,maxs↦⟦stack↦Φ.jeo.int(α0↦Φ.org.eolang.bytes(α0↦⟦Δ⤍00-00-00-00-00-00-00-01⟧)),locals↦Φ.jeo.int(α0↦Φ.org.eolang.bytes(α0↦⟦Δ⤍00-00-00-00-00-00-00-01⟧))⟧,method-params↦Φ.jeo.params,annotations↦Φ.org.eolang.seq0,φ↦Φ.org.eolang.seq3(α0↦ξ.aload-238,α1↦ξ.invokespecial-23A,α2↦ξ.return-23C),trycatchblocks-object@init@↦Φ.org.eolang.seq0,local-variable-table↦Φ.org.eolang.seq0,aload-238↦Φ.jeo.opcode(α0↦Φ.jeo.int(α0↦Φ.org.eolang.bytes(α0↦⟦Δ⤍00-00-00-00-00-00-00-19⟧)),α1↦Φ.jeo.int(α0↦Φ.org.eolang.bytes(α0↦⟦Δ⤍00-00-00-00-00-00-00-00⟧))),invokespecial-23A↦Φ.jeo.opcode(α0↦Φ.jeo.int(α0↦Φ.org.eolang.bytes(α0↦⟦Δ⤍00-00-00-00-00-00-00-B7⟧)),α1↦Φ.jeo.string(α0↦Φ.org.eolang.bytes(α0↦⟦Δ⤍6A-61-76-61-2F-6C-61-6E-67-2F-4F-62-6A-65-63-74⟧)),α2↦Φ.jeo.string(α0↦Φ.org.eolang.bytes(α0↦⟦Δ⤍3C-69-6E-69-74-3E⟧)),α3↦Φ.jeo.string(α0↦Φ.org.eolang.bytes(α0↦⟦Δ⤍28-29-56⟧)),α4↦Φ.jeo.bool(α0↦Φ.org.eolang.bytes(α0↦⟦Δ⤍0': "EOF"
        [11:13] mismatched input ',' expecting {')', '.'}: "EOF"

Expected behaviour: all the transformation work without errors. Moreover, xmir-to-phi and phi-to-xmir shouldn't alter the original xmir.

These files might be helpful:
App.phi.txt
App.xmir.disassemble.txt
App.xmir.unphi.txt

The text was updated successfully, but these errors were encountered:

volodya-lombrozo · 2024-11-25T09:55:11Z

@yegor256 @maxonfjvipon Could you have a look, please?

maxonfjvipon · 2024-11-25T10:28:50Z

@volodya-lombrozo the problem in all the places with jeo.bool:

<o base="jeo.bool"><!-- false -->
   <o base="org.eolang.bytes">00</o>
</o>

Extra dash is required:

<o base="jeo.bool"><!-- false -->
   <o base="org.eolang.bytes">00-</o>
</o>

volodya-lombrozo · 2024-11-25T11:24:37Z

Blocked by #3546

yegor256 · 2024-12-06T03:04:47Z

@volodya-lombrozo still a bug?

volodya-lombrozo · 2024-12-06T07:26:52Z

@yegor256 This one is solved, thank you.

volodya-lombrozo · 2024-12-06T07:51:33Z

@yegor256 No, it's still here. I'm getting the following:

org/eolang/hone/App.xmir:
	[56:17] no viable alternative at input 'j$org↦⟦j$eolang↦⟦j$hone↦⟦j$App↦Φ.jeo.class(α0↦ξ.version,α1↦ξ.access,α2↦ξ.supername,α3↦ξ.interfaces,α4↦ξ.j$Φ,α5↦ξ.j$object@init@-%28%29V,α6↦ξ.j$main-%28%5BLjava%2Flang%2FString%3B%29V,α7↦ξ.annotations,α8↦ξ.attributes),version↦Φ.jeo.int(α0↦Φ.org.eolang.bytes(α0↦⟦Δ⤍00-00-00-00-00-00-00-34⟧)),access↦Φ.jeo.int(α0↦Φ.org.eolang.bytes(α0↦⟦Δ⤍00-00-00-00-00-00-00-21⟧)),supername↦"java/lang/Object",interfaces↦Φ.jeo.seq.of0,j$Φ↦Φ.jeo.field(α0↦ξ.access-Φ,α1↦ξ.descriptor-Φ,α2↦ξ.signature-Φ,α3↦ξ.value-Φ,α4↦ξ.annotations-Φ),access-Φ↦Φ.jeo.int(α0↦Φ.org.eolang.bytes(α0↦⟦Δ⤍00-00-00-00-00-00-00-1A⟧)),descriptor-Φ↦"Ljava/lang/String;",signature-Φ↦"",value-Φ↦"We have the field with the unicode character '\u03A6'",annotations-Φ↦Φ.jeo.seq.of0,j$object@init@-%28%29V↦Φ.jeo.method(α0↦ξ.access,α1↦ξ.descriptor,α2↦ξ.signature,α3↦ξ.exceptions,α4↦Φ.jeo.maxs(α0↦ξ.stack,α1↦ξ.locals),α5↦ξ.method-params,α6↦ξ.annotations,α7↦φ': "EOF"
	[16:11] mismatched input ',' expecting {'(', ')', '.', ','}: "EOF"

During eo:0.46.0:phi-to-xmir

App.phi.txt
App.xmir.disassemble.txt
App.xmir.unphi.txt

Full log:
build.log

volodya-lombrozo · 2024-12-06T07:53:02Z

@maxonfjvipon Could you help with it, please? It's kinda urgent and blocks the development.

yegor256 · 2024-12-06T10:47:50Z

@maxonfjvipon the end of the input looks weird: α4↦Φ.jeo.bool(α0↦Φ.org.eolang.bytes(α0↦⟦Δ⤍0

maxonfjvipon · 2024-12-06T12:51:01Z

@yegor256 @volodya-lombrozo the problem in phi is here:

j$object@init@-%28%29V ↦ Φ.jeo.method(
  ...,
  α7 ↦ φ ↦ Φ.jeo.seq.of3(...)
)

This is illegal: α7 ↦ φ ↦ Φ.jeo.seq.of3 because of two arrows.
Here's the part of XMIR after dissasembling that causes the error:

<o base="jeo.method" name="j$object@init@-%28%29V">
  ...
  <o base="jeo.seq.of0" name="annotations"/>
  <o base="jeo.seq.of3" name="@">
     ...
  </o>
</o>

Here we have @base and @name for annotations and @.

But after optimizations and especially vars-float-up.xsl we get this:

<o base="jeo.method" name="j$object@init@-%28%29V">
   <o base="annotations" ref=""/>
   <o base="jeo.seq.of3" name="@">
      ...
   </o>
</o>
<o base="jeo.seq.of0" name="annotations"/>
<o base="jeo.seq.of3" name="@">
   ...
</o>

Here annotations element was moved to the same level as j$object@init@-%28%29V and used by ref. Meanwhile @ was just duplicated without any changes.

I'm not sure but I think the problem is in the vars-float-up.xsl. Maybe it began work wrong after removing abstract attribute

maxonfjvipon · 2024-12-06T13:02:36Z

@volodya-lombrozo when I printer your dissasembled XMIR to EO I got this:

jeo.method > j$object@init@-%28%29V
  ...
  jeo.seq.of0 > exceptions
  jeo.seq.of0 > annotations
  jeo.seq.of3 > @
    jeo.opcode.aload
      jeo.int
        00-00-00-00-00-00-00-19
      jeo.int
        00-00-00-00-00-00-00-00
    jeo.opcode.return
      jeo.int
        00-00-00-00-00-00-00-B1
  jeo.seq.of0 > local-variable-table

Are you sure it's OK to have @ object in such place, I mean "inside" or "deeper" than jeo.method application

maxonfjvipon · 2024-12-06T13:10:57Z

@yegor256 @volodya-lombrozo actually yes, our vars-float-up.xsl can't work with @ if it's not on the top level:

[] > object
  y > outer
    x > method
      5 > @

After vars-float-up.xsl we get:

<objects>
  <o line="2" name="object" pos="0">
     <o base="y" line="3" name="outer" pos="2">
        <o base="method" cut="1" line="4" ref="4"/>
     </o>
     <o base="x" line="4" name="method" pos="4">
        <o base="number" line="5" name="@" pos="6">40-14-00-00-00-00-00-00</o>
     </o>
     <o base="number" line="5" name="@" pos="6">40-14-00-00-00-00-00-00</o>
  </o>
</objects>

or in EO:

[] > object
  y method > outer
  x > method
    5 > @
  5 > @

@yegor256 is it a bug or feature? Because there's a special condition @name!='@' for such case in vars-float-up.xsl:

<xsl:template match="o[@name and @name!='@' and ancestor::o[1][not(eo:abstract(.))]]">

maxonfjvipon · 2024-12-06T13:15:16Z

@yegor256 If I remove the condition I get:

<objects>
  <o line="2" name="object" pos="0">
     <o base="y" line="3" name="outer" pos="2">
        <o base="method" cut="1" line="4" ref="4"/>
     </o>
     <o base="x" line="4" name="method" pos="4">
        <o base="@" cut="0" line="5" ref="5"/>
     </o>
     <o base="number" line="5" name="@" pos="6">40-14-00-00-00-00-00-00</o>
  </o>
</objects>

or in EO:

[] > object
  y method > outer
  x @ > method
  5 > @

WDYT?

volodya-lombrozo · 2024-12-06T13:18:08Z

@volodya-lombrozo when I printer your dissasembled XMIR to EO I got this:
jeo.method > j$object@init@-%28%29V
  ...
  jeo.seq.of0 > exceptions
  jeo.seq.of0 > annotations
  jeo.seq.of3 > @
    jeo.opcode.aload
      jeo.int
        00-00-00-00-00-00-00-19
      jeo.int
        00-00-00-00-00-00-00-00
    jeo.opcode.return
      jeo.int
        00-00-00-00-00-00-00-B1
  jeo.seq.of0 > local-variable-table
Are you sure it's OK to have @ object in such place, I mean "inside" or "deeper" than jeo.method application

@maxonfjvipon I can rename @ to something other like body, but I have two questions related to it:

Will it solve this problem?
Won't it create some other problems on your side?

volodya-lombrozo · 2024-12-06T13:19:11Z

@maxonfjvipon I used @ with abstract objects. I removed abstract objects, but forgot about @.

maxonfjvipon · 2024-12-06T13:20:52Z

@volodya-lombrozo yes, it should solve the problem, because of this. I'm not sure for now is it a bug or feature

maxonfjvipon · 2024-12-06T13:22:28Z

@maxonfjvipon I used @ with abstract objects. I removed abstract objects, but forgot about @.

@volodya-lombrozo actually without abstract but with @ it's a way different XMIR now, so yes, I believe just renaming should solve the problem

volodya-lombrozo · 2024-12-06T14:27:09Z

@maxonfjvipon Ok, this problem is gone. Now I just have a broken xmir after the unroll phase. For example, after the disassemble goal I have the following supername:

<o base="org.eolang.string" name="supername"><!-- "java/lang/Object" -->
    <o base="org.eolang.bytes">6A-61-76-61-2F-6C-61-6E-67-2F-4F-62-6A-65-63-74</o>
</o>

After phi/unphi/unroll I have the following:

<o base="string" line="33" name="supername" pos="0"/>

It's the first thing I've found. Most probably there many more inconsistencies. There are files that can help you:
App.xmir.disassemble.txt
App.phi.txt
App.xmir.unphi.txt
App.xmir.unroll.txt

This issue is still a blocker.

yegor256 · 2024-12-06T14:37:01Z

@maxonfjvipon this looks like a bug to me, but I can't understand the reason behind it... let's assume it's a typo.

maxonfjvipon · 2024-12-06T14:40:28Z

@yegor256 maybe it was, this xsl was made by you in 2020

maxonfjvipon · 2024-12-06T16:03:07Z

@volodya-lombrozo it seems your vars-float-down.xsl works incorrectly, try this one: vars-float-down.xsl.txt

I tested it on this XMIR:

<program>
   <objects>
      <o name="j$App">
         <o base=".supername">
            <o base="$"/>
         </o>
         <o base=".access">
            <o base="$"/>
         </o>
         <o base=".inte">
            <o base="$"/>
         </o>
      </o>
      <o base=".of0" name="interfaces">
         <o base=".seq">
            <o base=".jeo">
               <o base="Q"/>
            </o>
         </o>
      </o>
      <o base="org.eolang.string" name="supername">
         <o base="org.eolang.bytes">6A-61-76-61-2F-6C-61-6E-67-2F-4F-62-6A-65-63-74</o>
      </o>
      <o base=".int" name="access">
         <o base=".jeo">
            <o base="Q"/>
         </o>
         <o as="0" base=".bytes">
            <o base=".eolang">
               <o base=".org">
                  <o base="Q"/>
               </o>
            </o>00-00-00-00-00-00-00-21</o>
      </o>
   </objects>
</program>

and after unroll I got:

<program>
  <objects>
    <o abstract="" line="2" name="j$App" pos="0">
       <o base="string" line="14" name="supername" pos="0">6A-61-76-61-2F-6C-61-6E-67-2F-4F-62-6A-65-63-74</o>
       <o base="jeo.int" line="17" name="access" pos="0">
          <o as="0" base="bytes" line="18" pos="2">00-00-00-00-00-00-00-21</o>
       </o>
       <o base="jeo.seq.of0" line="12" name="interfaces" pos="0"/>
    </o>
  </objects>
</program>

volodya-lombrozo · 2024-12-09T07:45:53Z

@maxonfjvipon This helps with supername indeed, but there are still bugs, for example, take a look on jeo.annotation-property, before:

<o base="jeo.annotation-property">
	<o base="org.eolang.string">
		<!-- "PLAIN" -->
		<o base="org.eolang.bytes">50-4C-41-49-4E</o>
	</o>
	<o base="org.eolang.string">
		<!-- "value" -->
		<o base="org.eolang.bytes">76-61-6C-75-65</o>
	</o>
	<o base="org.eolang.string">
		<!-- "some&#45;parameter" -->
		<o base="org.eolang.bytes">73-6F-6D-65-2D-70-61-72-61-6D-65-74-65-72</o>
	</o>
</o>

After:

<o as="2" base="jeo.annotation-property" line="539" pos="2">
	<o as="0" base="string" line="540" pos="4">50-4C-41-49-4E</o>
	<o as="1" base="string" line="541" pos="4">76-61-6C-75-65</o>
	<o as="2" base="string" line="542" pos="4">73-6F-6D-65-2D-70-61-72-61-6D-65-74-65-72</o>
</o>

App.xmir.disassemble.txt
App.phi.txt
App.xmir.unphi.txt
App.xmir.unroll.txt

Please, test the entire file instead of some excerpts.

maxonfjvipon · 2024-12-09T09:13:13Z

@volodya-lombrozo I don't see any problems here. What's wrong?

volodya-lombrozo · 2024-12-09T09:30:23Z

@maxonfjvipon we lost org.eolang.bytes at least. Please, compare xmir files for more info

maxonfjvipon · 2024-12-09T09:33:40Z

@volodya-lombrozo but this is how unroll is supposed to work. It removes org.eolang.bytes purposely. It was your desire to have such format of XMIR after unrolling so it's convenient for you to map it back to byte code

volodya-lombrozo · 2024-12-09T09:52:37Z

@maxonfjvipon It has never been "my desirer". The unroll phase is created only because eo-maven-plugin doesn't have any formal and stable documentation or at least description of the XMIR which jeo-maven-plugin can rely on.
As for unroll itself, its purpose to produce the XMIR in the format produced by jeo-maven-plugin after the disassemble phase.

Again, I did:

I disassemble java bytecode by using jeo-maven-plugin:disassemble into xmir == X
Convert this xmir to phi by using eo-maven-plugin:0.46.0:xmir-to-phi
Convert the phi back to xmir by using eo-maven-plugin:0.46.0:phi-to-xmir
Uroll changes jeo-maven-plugin:unroll == Y

I get, X != Y. Please, fix this equation. It blocks the development for a few days already.

maxonfjvipon · 2024-12-09T11:57:52Z

@volodya-lombrozo try to add 2 more xsl transformations to your unrolling train: /org/eolang/parser/add-default-package.xsl and /org/eolang/parser/explicit-data.xsl after remove-cuts.xsl so your unrolling train is:

new TrFast(
    new TrJoined<Shift>(
        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/add-cuts.xsl"
        ).back(),
        new TrDefault<Shift>(
            new StEndless(
                new StClasspath(
                    "/org/eolang/parser/vars-float-down.xsl"
                )
            )
        ),
        new TrClasspath<Shift>(
            "/org/eolang/parser/remove-cuts.xsl",
            "/org/eolang/parser/add-default-package.xsl",       // <---- here
            "/org/eolang/parser/explicit-data.xsl"              // <---- and here
        ).back()
    ),
    CanonicalXmir.class,
    5
)

volodya-lombrozo · 2024-12-09T11:59:52Z

@volodya-lombrozo now the problem only with unroll goal which is part of jeo. Inside eo-maven-plugin phi and unphi work as expected

@maxonfjvipon We created the unroll phase to address obvious problems in the eo repository. I have already mentioned them here. Moving this issue to jeo will hide these problems again, leaving the eo repository undocumented and unusable for other plugins. And of course, if we move this issue, developers of eo will think that everything is ok. But it is not.

The proper solution would be to remove unroll phase from jeo. Wait until eo repository will standardise and document XMIR format and then implement proper transformation in jeo. But how long time will it take? I guess, a lot.

volodya-lombrozo · 2024-12-09T12:16:06Z

@volodya-lombrozo try to add 2 more xsl transformations to your unrolling train: /org/eolang/parser/add-default-package.xsl and /org/eolang/parser/explicit-data.xsl after remove-cuts.xsl so your unrolling train is:

new TrFast(
    new TrJoined<Shift>(
        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/add-cuts.xsl"
        ).back(),
        new TrDefault<Shift>(
            new StEndless(
                new StClasspath(
                    "/org/eolang/parser/vars-float-down.xsl"
                )
            )
        ),
        new TrClasspath<Shift>(
            "/org/eolang/parser/remove-cuts.xsl",
            "/org/eolang/parser/add-default-package.xsl",       // <---- here
            "/org/eolang/parser/explicit-data.xsl"              // <---- and here
        ).back()
    ),
    CanonicalXmir.class,
    5
)

@maxonfjvipon I've tried this transformations and got another error:

Before:

 <o base="jeo.method" name="j$object@init@-%28%29V">
   <o base="jeo.int" name="access"><!-- 1 -->
     <o base="org.eolang.bytes">00-00-00-00-00-00-00-01</o>
   </o>
...
</o>

After:

<o base="jeo.method" line="67" name="j$object@init@-%28%29V" pos="0">
  <o base="jeo.int" line="30" name="access" pos="0">
    <o as="0" base="org.eolang.bytes" line="31" pos="2">00-00-00-00-00-00-00-21</o>
  </o>
...
</o>

App.xmir.disassemble.txt
App.phi.txt
App.xmir.unphi.txt
App.xmir.unroll.txt

maxonfjvipon · 2024-12-09T12:30:30Z

@volodya-lombrozo you have two (maybe more) objects with name access in your XMIR after disassembling. Maybe you should implement this first? It'll allow you to catch such errors after disassembling. Previously such catchers were part of phi mojo. Now they were moved to lints repo.

volodya-lombrozo · 2024-12-09T12:39:47Z

@maxonfjvipon I've already done it in the same PR.

Moreover, I can't just implement this issue without upgrading eo. And I can't upgrade eo because of this.

volodya-lombrozo · 2024-12-09T12:44:00Z

@maxonfjvipon What exactly should I do to avoid this issue?

maxonfjvipon · 2024-12-09T12:46:03Z

@volodya-lombrozo get rid of duplication of @name attribute in the scope of current abstract object
Now you have something similar to this:

[] > app
  ...
  5 > access
  ...
  10 > access

maxonfjvipon · 2024-12-09T12:50:48Z

@maxonfjvipon I've already done it in objectionary/jeo-maven-plugin#942.

@volodya-lombrozo it seems you've done it wrong because no error is caught

volodya-lombrozo · 2024-12-09T12:54:22Z

@maxonfjvipon I've already done it in objectionary/jeo-maven-plugin#942.

@volodya-lombrozo it seems you've done it wrong because no error is caught

@maxonfjvipon Or it's one more bug in the eo or jcabi.xml.

volodya-lombrozo · 2024-12-09T13:02:49Z

@volodya-lombrozo get rid of duplication of @name attribute in the scope of current abstract object Now you have something similar to this:
[] > app
  ...
  5 > access
  ...
  10 > access

@maxonfjvipon I don't have abstract objects. From the description of the PR I send you many times already:

Upgrade eo version up to 0.46.0. Additionally, in this PR I removed abstract objects.

maxonfjvipon · 2024-12-09T13:05:53Z

@maxonfjvipon Or it's one more bug in the eo or jcabi.xml.

@volodya-lombrozo StrictXML just checks if your XML corresponds to the XSD scheme. You need to use Program object from objectionary/lints repo and check if there're some defects

volodya-lombrozo · 2024-12-09T13:12:41Z

@maxonfjvipon Or it's one more bug in the eo or jcabi.xml.

@volodya-lombrozo StrictXML just checks if your XML corresponds to the XSD scheme. You need to use Program object from objectionary/lints repo and check if there're some defects

@maxonfjvipon I'll try

volodya-lombrozo · 2024-12-09T13:25:06Z

@maxonfjvipon I've tried the approach you suggested, here is what I get:

Caused by: java.lang.IllegalArgumentException: There is something wrong with the XMIR, found '/program/metas/meta[not(@line) or @line='']':
<?xml version="1.0" encoding="UTF-8"?>
<program xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         dob="2024-12-09T16:16:40"
         ms="0"
         name="j$Parameter"
         revision="b82384c"
         time="2024-12-09T13:17:18.655536Z"
         version="1.0-SNAPSHOT"
         xsi:noNamespaceSchemaLocation="https://www.eolang.org/xsd/XMIR-0.46.0.xsd">
   <listing>// class version 52.0 (52)
// access flags 0x2601
public abstract @interface org/eolang/hone/param/Parameter implements java/lang/annotation/Annotation {

  // compiled from: Parameter.java

  @Ljava/lang/annotation/Retention;(value=Ljava/lang/annotation/RetentionPolicy;.RUNTIME)

  @Ljava/lang/annotation/Target;(value={Ljava/lang/annotation/ElementType;.TYPE})

  // access flags 0x401
  public abstract value()Ljava/lang/String;
}
</listing>
   <license>The MIT License (MIT)

Copyright (c) 2016-2024 Objectionary.com

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included
in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.</license>
   <metas>
      <meta>
         <head>package</head>
         <tail>j$org.j$eolang.j$hone.j$param</tail>
         <part>j$org.j$eolang.j$hone.j$param</part>
      </meta>
      <meta>
         <head>alias</head>
         <tail>jeo.seq.of2</tail>
         <part>jeo.seq.of2</part>
      </meta>
      <meta>
         <head>alias</head>
         <tail>jeo.seq.of0</tail>
         <part>jeo.seq.of0</part>
      </meta>
      <meta>
         <head>alias</head>
         <tail>jeo.seq.of1</tail>
         <part>jeo.seq.of1</part>
      </meta>
      <meta>
         <head>alias</head>
         <tail>jeo.method</tail>
         <part>jeo.method</part>
      </meta>
      <meta>
         <head>alias</head>
         <tail>jeo.params</tail>
         <part>jeo.params</part>
      </meta>
      <meta>
         <head>alias</head>
         <tail>jeo.int</tail>
         <part>jeo.int</part>
      </meta>
      <meta>
         <head>alias</head>
         <tail>jeo.annotation-property</tail>
         <part>jeo.annotation-property</part>
      </meta>
      <meta>
         <head>alias</head>
         <tail>jeo.bool</tail>
         <part>jeo.bool</part>
      </meta>
      <meta>
         <head>alias</head>
         <tail>jeo.class</tail>
         <part>jeo.class</part>
      </meta>
      <meta>
         <head>alias</head>
         <tail>jeo.annotation</tail>
         <part>jeo.annotation</part>
      </meta>
      <meta>
         <head>alias</head>
         <tail>jeo.maxs</tail>
         <part>jeo.maxs</part>
      </meta>
   </metas>
   <objects>
      <o base="jeo.class" name="j$Parameter">
         <o base="jeo.int" name="version"><!-- 52 -->
            <o base="org.eolang.bytes">00-00-00-00-00-00-00-34</o>
         </o>
         <o base="jeo.int" name="access"><!-- 9729 -->
            <o base="org.eolang.bytes">00-00-00-00-00-00-26-01</o>
         </o>
         <o base="org.eolang.string" name="supername"><!-- "java/lang/Object" -->
            <o base="org.eolang.bytes">6A-61-76-61-2F-6C-61-6E-67-2F-4F-62-6A-65-63-74</o>
         </o>
         <o base="jeo.seq.of1" name="interfaces">
            <o base="org.eolang.string"><!-- "java/lang/annotation/Annotation" -->
               <o base="org.eolang.bytes">6A-61-76-61-2F-6C-61-6E-67-2F-61-6E-6E-6F-74-61-74-69-6F-6E-2F-41-6E-6E-6F-74-61-74-69-6F-6E</o>
            </o>
         </o>
         <o base="jeo.method" name="j$value-%28%29Ljava%2Flang%2FString%3B">
            <o base="jeo.int" name="access"><!-- 1025 -->
               <o base="org.eolang.bytes">00-00-00-00-00-00-04-01</o>
            </o>
            <o base="org.eolang.string" name="descriptor"><!-- "()Ljava/lang/String;" -->
               <o base="org.eolang.bytes">28-29-4C-6A-61-76-61-2F-6C-61-6E-67-2F-53-74-72-69-6E-67-3B</o>
            </o>
            <o base="org.eolang.string" name="signature"><!-- "" -->
               <o base="org.eolang.bytes">--</o>
            </o>
            <o base="jeo.seq.of0" name="exceptions"/>
            <o base="jeo.maxs">
               <o base="jeo.int" name="stack"><!-- 0 -->
                  <o base="org.eolang.bytes">00-00-00-00-00-00-00-00</o>
               </o>
               <o base="jeo.int" name="locals"><!-- 0 -->
                  <o base="org.eolang.bytes">00-00-00-00-00-00-00-00</o>
               </o>
            </o>
            <o base="jeo.params" name="method-params"/>
            <o base="jeo.seq.of0" name="annotations"/>
            <o base="jeo.seq.of0" name="body"/>
            <o base="jeo.seq.of0" name="trycatchblocks-value"/>
            <o base="jeo.seq.of0" name="local-variable-table"/>
         </o>
         <o base="jeo.seq.of2" name="annotations">
            <o base="jeo.annotation"
               name="annotation-1073483870-Ljava%2Flang%2Fannotation%2FRetention%3B">
               <o base="org.eolang.string"><!-- "Ljava/lang/annotation/Retention;" -->
                  <o base="org.eolang.bytes">4C-6A-61-76-61-2F-6C-61-6E-67-2F-61-6E-6E-6F-74-61-74-69-6F-6E-2F-52-65-74-65-6E-74-69-6F-6E-3B</o>
               </o>
               <o base="jeo.bool"><!-- true -->
                  <o base="org.eolang.bytes">01-</o>
               </o>
               <o base="jeo.annotation-property">
                  <o base="org.eolang.string"><!-- "ENUM" -->
                     <o base="org.eolang.bytes">45-4E-55-4D</o>
                  </o>
                  <o base="org.eolang.string"><!-- "value" -->
                     <o base="org.eolang.bytes">76-61-6C-75-65</o>
                  </o>
                  <o base="org.eolang.string"><!-- "Ljava/lang/annotation/RetentionPolicy;" -->
                     <o base="org.eolang.bytes">4C-6A-61-76-61-2F-6C-61-6E-67-2F-61-6E-6E-6F-74-61-74-69-6F-6E-2F-52-65-74-65-6E-74-69-6F-6E-50-6F-6C-69-63-79-3B</o>
                  </o>
                  <o base="org.eolang.string"><!-- "RUNTIME" -->
                     <o base="org.eolang.bytes">52-55-4E-54-49-4D-45</o>
                  </o>
               </o>
            </o>
            <o base="jeo.annotation"
               name="annotation-1585082451-Ljava%2Flang%2Fannotation%2FTarget%3B">
               <o base="org.eolang.string"><!-- "Ljava/lang/annotation/Target;" -->
                  <o base="org.eolang.bytes">4C-6A-61-76-61-2F-6C-61-6E-67-2F-61-6E-6E-6F-74-61-74-69-6F-6E-2F-54-61-72-67-65-74-3B</o>
               </o>
               <o base="jeo.bool"><!-- true -->
                  <o base="org.eolang.bytes">01-</o>
               </o>
               <o base="jeo.annotation-property">
                  <o base="org.eolang.string"><!-- "ARRAY" -->
                     <o base="org.eolang.bytes">41-52-52-41-59</o>
                  </o>
                  <o base="org.eolang.string"><!-- "value" -->
                     <o base="org.eolang.bytes">76-61-6C-75-65</o>
                  </o>
                  <o base="jeo.annotation-property">
                     <o base="org.eolang.string"><!-- "ENUM" -->
                        <o base="org.eolang.bytes">45-4E-55-4D</o>
                     </o>
                     <o base="org.eolang.string"><!-- "" -->
                        <o base="org.eolang.bytes">--</o>
                     </o>
                     <o base="org.eolang.string"><!-- "Ljava/lang/annotation/ElementType;" -->
                        <o base="org.eolang.bytes">4C-6A-61-76-61-2F-6C-61-6E-67-2F-61-6E-6E-6F-74-61-74-69-6F-6E-2F-45-6C-65-6D-65-6E-74-54-79-70-65-3B</o>
                     </o>
                     <o base="org.eolang.string"><!-- "TYPE" -->
                        <o base="org.eolang.bytes">54-59-50-45</o>
                     </o>
                  </o>
               </o>
            </o>
         </o>
         <o base="jeo.seq.of0" name="attributes"/>
      </o>
   </objects>
</program>

    at org.eolang.lints.LintByXsl.sanitized (LintByXsl.java:137)
    at org.eolang.lints.LintByXsl.defects (LintByXsl.java:98)
    at org.eolang.lints.LintByXsl.defects (LintByXsl.java:45)
    at org.eolang.lints.Program.defects (Program.java:87)
    at org.eolang.jeo.representation.VerifiedEo.asXml (VerifiedEo.java:68)
    at org.eolang.jeo.representation.MeasuredEo.asXml (MeasuredEo.java:58)
    at org.eolang.jeo.representation.BytecodeRepresentation.toEO (BytecodeRepresentation.java:117)
    at org.eolang.jeo.Disassembling.transform (Disassembling.java:86)
    at org.eolang.jeo.Caching.tryTransform (Caching.java:93)
    at org.eolang.jeo.Caching.transform (Caching.java:63)
    at org.eolang.jeo.Logging.transform (Logging.java:83)
    at org.eolang.jeo.Disassembler.disassemble (Disassembler.java:113)
    at org.eolang.jeo.ParallelTranslator.translate (ParallelTranslator.java:70)
    at java.util.stream.ReferencePipeline$3$1.accept (ReferencePipeline.java:197)
    at java.util.ArrayList$ArrayListSpliterator.forEachRemaining (ArrayList.java:1708)
    at java.util.stream.AbstractPipeline.copyInto (AbstractPipeline.java:509)
    at java.util.stream.ForEachOps$ForEachTask.compute (ForEachOps.java:291)
    at java.util.concurrent.CountedCompleter.exec (CountedCompleter.java:754)
    at java.util.concurrent.ForkJoinTask.doExec (ForkJoinTask.java:387)
    at java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec (ForkJoinPool.java:1312)
    at java.util.concurrent.ForkJoinPool.scan (ForkJoinPool.java:1843)
    at java.util.concurrent.ForkJoinPool.runWorker (ForkJoinPool.java:1808)
    at java.util.concurrent.ForkJoinWorkerThread.run (ForkJoinWorkerThread.java:188)

I have no idea what I should fix to make it work. The error message is unreadable.
Please fix it or tell me what I should change to make this validation pass. It is still blocking progress.

maxonfjvipon · 2024-12-09T13:28:37Z

@volodya-lombrozo check this:

found '/program/metas/meta[not(@line) or @line='']'

volodya-lombrozo · 2024-12-09T13:29:41Z

@maxonfjvipon What does it mean?

yegor256 · 2024-12-09T13:39:01Z

@volodya-lombrozo @maxonfjvipon it's better to split larger problems into individual independent bug reports. Keeping long conversation like this makes it harder to navigate and trace.

volodya-lombrozo · 2024-12-09T13:46:25Z

@volodya-lombrozo @maxonfjvipon it's better to split larger problems into individual independent bug reports. Keeping long conversation like this makes it harder to navigate and trace.

@yegor256 I would like to do it; however, the recent policy forbids me from doing so.

yegor256 · 2024-12-09T14:03:33Z

@volodya-lombrozo the policy discourages you to submit tickets that don't lead to code changes, but not to NOT submit any bug reports. Keeping such a long discussion is one ticket is counter productive. Try to move in smaller steps forward: try one change, see the problem, report it, get a fix, close the ticket, report a new problem, and so on. If you (and all others) would be paid for each accepted bug report, you would follow this strategy automatically :)

maxonfjvipon · 2024-12-09T14:04:09Z

@maxonfjvipon I don't have abstract objects. From the description of objectionary/jeo-maven-plugin#942 I send you many times already:

@volodya-lombrozo if you take a look at phi expression that you get after phi:

{
  ⟦
    j$org ↦ ⟦
      j$eolang ↦ ⟦
        j$hone ↦ ⟦
          j$App ↦ Φ.jeo.class(
            α1 ↦ ξ.access,
            ...
          ),
          access ↦ Φ.jeo.int(
            α0 ↦ Φ.org.eolang.bytes(
              α0 ↦ ⟦ Δ ⤍ 00-00-00-00-00-00-00-21 ⟧
            )
          ),
          ...
          access ↦ Φ.jeo.int(
            α0 ↦ Φ.org.eolang.bytes(
              α0 ↦ ⟦ Δ ⤍ 00-00-00-00-00-00-00-01 ⟧
            )
          )
          ...
          λ ⤍ Package
        ⟧,
        λ ⤍ Package
      ⟧,
      λ ⤍ Package
    ⟧
  ⟧
}

Your j$App is not abstract, but package is an abstract object, so your access objects are kind of global variables in scope of abstract org.eolang.hone object. So just get rid of names duplication and it'll work

volodya-lombrozo · 2024-12-09T14:11:50Z

@maxonfjvipon I don't have abstract objects. From the description of objectionary/jeo-maven-plugin#942 I send you many times already:

@volodya-lombrozo if you take a look at phi expression that you get after phi:
{
  ⟦
    j$org ↦ ⟦
      j$eolang ↦ ⟦
        j$hone ↦ ⟦
          j$App ↦ Φ.jeo.class(
            α1 ↦ ξ.access,
            ...
          ),
          access ↦ Φ.jeo.int(
            α0 ↦ Φ.org.eolang.bytes(
              α0 ↦ ⟦ Δ ⤍ 00-00-00-00-00-00-00-21 ⟧
            )
          ),
          ...
          access ↦ Φ.jeo.int(
            α0 ↦ Φ.org.eolang.bytes(
              α0 ↦ ⟦ Δ ⤍ 00-00-00-00-00-00-00-01 ⟧
            )
          )
          ...
          λ ⤍ Package
        ⟧,
        λ ⤍ Package
      ⟧,
      λ ⤍ Package
    ⟧
  ⟧
}
Your j$App is not abstract, but package is an abstract object, so your access objects are kind of global variables in scope of abstract org.eolang.hone object. So just get rid of names duplication and it'll work

@maxonfjvipon Ok, I will try to do it

volodya-lombrozo · 2024-12-09T14:46:59Z

@volodya-lombrozo the policy discourages you to submit tickets that don't lead to code changes, but not to NOT submit any bug reports.

@yegor256 It's hard to draw a clear line between "tickets that don't lead to code changes" and any other tickets. This border doesn't exist, actually.

Keeping such a long discussion is one ticket is counter productive

But safe. I don't loose points. So, for me, personally, it's productive.

Try to move in smaller steps forward: try one change, see the problem, report it, get a fix, close the ticket, report a new problem, and so on.

I liked it actually and use this in other repositories! I used to enjoy it here as well.

If you (and all others) would be paid for each accepted bug report, you would follow this strategy automatically :)

I tend to disagree here. It has become risky to create new tickets. Someone like me can easily lose more points for reporting 'wrong' bugs than for creating 'good' ones. For example, let's imagine I receive 10 points for a 'good' issue but lose 10 points for a 'wrong' one. I end up with zero. So, what is the point of creating issues then?

Moreover, it's only you who decides whether to add code changes or not. Personally, I believe it's a fair and right way to go. However, there isn't any formal process or review I can rely on — just your personal decision, which nobody can predict.

As a result, it's easier, more profitable, and safer for me to avoid creating new issues.

yegor256 · 2024-12-09T15:06:18Z

As a result, it's easier, more profitable, and safer for me to avoid creating new issues.

@volodya-lombrozo this wouldn't work if programmers would be paid only for accepted bug reports and merged pull requests :)

volodya-lombrozo · 2024-12-10T07:39:21Z

@maxonfjvipon I've added random numbers to each name in the xmir, but still get the same error:

Caused by: org.apache.maven.plugin.PluginExecutionException: Execution bytecode-to-xmir of goal org.eolang:jeo-maven-plugin:1.0-SNAPSHOT:disassemble failed: java.lang.IllegalArgumentException: There is something wrong with the XMIR, found '/program/metas/meta[not(@line) or @line='']':
<?xml version="1.0" encoding="UTF-8"?>
<program xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         dob="2024-12-10T10:34:09"
         ms="0"
         name="j$Parameter"
         revision="86f03be"
         time="2024-12-10T07:34:27.909958Z"
         version="1.0-SNAPSHOT"
         xsi:noNamespaceSchemaLocation="https://www.eolang.org/xsd/XMIR-0.46.0.xsd">
   <listing>// class version 52.0 (52)
// access flags 0x2601
public abstract @interface org/eolang/hone/param/Parameter implements java/lang/annotation/Annotation {

  // compiled from: Parameter.java

  @Ljava/lang/annotation/Retention;(value=Ljava/lang/annotation/RetentionPolicy;.RUNTIME)

  @Ljava/lang/annotation/Target;(value={Ljava/lang/annotation/ElementType;.TYPE})

  // access flags 0x401
  public abstract value()Ljava/lang/String;
}
</listing>
   <license>The MIT License (MIT)

Copyright (c) 2016-2024 Objectionary.com

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included
in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.</license>
   <metas>
      <meta>
         <head>package</head>
         <tail>j$org.j$eolang.j$hone.j$param</tail>
         <part>j$org.j$eolang.j$hone.j$param</part>
      </meta>
      <meta>
         <head>alias</head>
         <tail>jeo.seq.of2</tail>
         <part>jeo.seq.of2</part>
      </meta>
      <meta>
         <head>alias</head>
         <tail>jeo.seq.of0</tail>
         <part>jeo.seq.of0</part>
      </meta>
      <meta>
         <head>alias</head>
         <tail>jeo.seq.of1</tail>
         <part>jeo.seq.of1</part>
      </meta>
      <meta>
         <head>alias</head>
         <tail>jeo.method</tail>
         <part>jeo.method</part>
      </meta>
      <meta>
         <head>alias</head>
         <tail>jeo.params</tail>
         <part>jeo.params</part>
      </meta>
      <meta>
         <head>alias</head>
         <tail>jeo.int</tail>
         <part>jeo.int</part>
      </meta>
      <meta>
         <head>alias</head>
         <tail>jeo.annotation-property</tail>
         <part>jeo.annotation-property</part>
      </meta>
      <meta>
         <head>alias</head>
         <tail>jeo.bool</tail>
         <part>jeo.bool</part>
      </meta>
      <meta>
         <head>alias</head>
         <tail>jeo.class</tail>
         <part>jeo.class</part>
      </meta>
      <meta>
         <head>alias</head>
         <tail>jeo.annotation</tail>
         <part>jeo.annotation</part>
      </meta>
      <meta>
         <head>alias</head>
         <tail>jeo.maxs</tail>
         <part>jeo.maxs</part>
      </meta>
   </metas>
   <objects>
      <o base="jeo.class" name="j$Parameter-1151987802">
         <o base="jeo.int" name="version-384281494-258684867"><!-- 52 -->
            <o base="org.eolang.bytes">00-00-00-00-00-00-00-34</o>
         </o>
         <o base="jeo.int" name="access-384281494-1213734771"><!-- 9729 -->
            <o base="org.eolang.bytes">00-00-00-00-00-00-26-01</o>
         </o>
         <o base="org.eolang.string" name="supername-384281494"><!-- "java/lang/Object" -->
            <o base="org.eolang.bytes">6A-61-76-61-2F-6C-61-6E-67-2F-4F-62-6A-65-63-74</o>
         </o>
         <o base="jeo.seq.of1" name="interfaces-384281494-2070841150">
            <o base="org.eolang.string"><!-- "java/lang/annotation/Annotation" -->
               <o base="org.eolang.bytes">6A-61-76-61-2F-6C-61-6E-67-2F-61-6E-6E-6F-74-61-74-69-6F-6E-2F-41-6E-6E-6F-74-61-74-69-6F-6E</o>
            </o>
         </o>
         <o base="jeo.method"
            name="j$value-%28%29Ljava%2Flang%2FString%3B-1524873271">
            <o base="jeo.int" name="access-370606691-345433748"><!-- 1025 -->
               <o base="org.eolang.bytes">00-00-00-00-00-00-04-01</o>
            </o>
            <o base="org.eolang.string" name="descriptor-370606691"><!-- "()Ljava/lang/String;" -->
               <o base="org.eolang.bytes">28-29-4C-6A-61-76-61-2F-6C-61-6E-67-2F-53-74-72-69-6E-67-3B</o>
            </o>
            <o base="org.eolang.string" name="signature-370606691"><!-- "" -->
               <o base="org.eolang.bytes">--</o>
            </o>
            <o base="jeo.seq.of0" name="exceptions-370606691-395917296"/>
            <o base="jeo.maxs">
               <o base="jeo.int" name="stack-1447194124-1862724769"><!-- 0 -->
                  <o base="org.eolang.bytes">00-00-00-00-00-00-00-00</o>
               </o>
               <o base="jeo.int" name="locals-1447194124-2104385215"><!-- 0 -->
                  <o base="org.eolang.bytes">00-00-00-00-00-00-00-00</o>
               </o>
            </o>
            <o base="jeo.params" name="method-params-2124135980"/>
            <o base="jeo.seq.of0" name="annotations-1542565947"/>
            <o base="jeo.seq.of0" name="body-1893882340"/>
            <o base="jeo.seq.of0" name="trycatchblocks-value-1105726702"/>
            <o base="jeo.seq.of0" name="local-variable-table-29384195"/>
         </o>
         <o base="jeo.seq.of2" name="annotations-1955924670">
            <o base="jeo.annotation"
               name="annotation-1738567596-Ljava%2Flang%2Fannotation%2FRetention%3B-1164370441">
               <o base="org.eolang.string"><!-- "Ljava/lang/annotation/Retention;" -->
                  <o base="org.eolang.bytes">4C-6A-61-76-61-2F-6C-61-6E-67-2F-61-6E-6E-6F-74-61-74-69-6F-6E-2F-52-65-74-65-6E-74-69-6F-6E-3B</o>
               </o>
               <o base="jeo.bool"><!-- true -->
                  <o base="org.eolang.bytes">01-</o>
               </o>
               <o base="jeo.annotation-property">
                  <o base="org.eolang.string"><!-- "ENUM" -->
                     <o base="org.eolang.bytes">45-4E-55-4D</o>
                  </o>
                  <o base="org.eolang.string"><!-- "value" -->
                     <o base="org.eolang.bytes">76-61-6C-75-65</o>
                  </o>
                  <o base="org.eolang.string"><!-- "Ljava/lang/annotation/RetentionPolicy;" -->
                     <o base="org.eolang.bytes">4C-6A-61-76-61-2F-6C-61-6E-67-2F-61-6E-6E-6F-74-61-74-69-6F-6E-2F-52-65-74-65-6E-74-69-6F-6E-50-6F-6C-69-63-79-3B</o>
                  </o>
                  <o base="org.eolang.string"><!-- "RUNTIME" -->
                     <o base="org.eolang.bytes">52-55-4E-54-49-4D-45</o>
                  </o>
               </o>
            </o>
            <o base="jeo.annotation"
               name="annotation-128680975-Ljava%2Flang%2Fannotation%2FTarget%3B-350346556">
               <o base="org.eolang.string"><!-- "Ljava/lang/annotation/Target;" -->
                  <o base="org.eolang.bytes">4C-6A-61-76-61-2F-6C-61-6E-67-2F-61-6E-6E-6F-74-61-74-69-6F-6E-2F-54-61-72-67-65-74-3B</o>
               </o>
               <o base="jeo.bool"><!-- true -->
                  <o base="org.eolang.bytes">01-</o>
               </o>
               <o base="jeo.annotation-property">
                  <o base="org.eolang.string"><!-- "ARRAY" -->
                     <o base="org.eolang.bytes">41-52-52-41-59</o>
                  </o>
                  <o base="org.eolang.string"><!-- "value" -->
                     <o base="org.eolang.bytes">76-61-6C-75-65</o>
                  </o>
                  <o base="jeo.annotation-property">
                     <o base="org.eolang.string"><!-- "ENUM" -->
                        <o base="org.eolang.bytes">45-4E-55-4D</o>
                     </o>
                     <o base="org.eolang.string"><!-- "" -->
                        <o base="org.eolang.bytes">--</o>
                     </o>
                     <o base="org.eolang.string"><!-- "Ljava/lang/annotation/ElementType;" -->
                        <o base="org.eolang.bytes">4C-6A-61-76-61-2F-6C-61-6E-67-2F-61-6E-6E-6F-74-61-74-69-6F-6E-2F-45-6C-65-6D-65-6E-74-54-79-70-65-3B</o>
                     </o>
                     <o base="org.eolang.string"><!-- "TYPE" -->
                        <o base="org.eolang.bytes">54-59-50-45</o>
                     </o>
                  </o>
               </o>
            </o>
         </o>
         <o base="jeo.seq.of0" name="attributes-745504428"/>
      </o>
   </objects>
</program>

Thus, it doesn't help at all. Please, fix the bug. It blocks the progress.

yegor256 · 2024-12-10T08:12:40Z

@volodya-lombrozo it's a bug in lints: objectionary/lints#122 Let me fix it and release new version

volodya-lombrozo · 2024-12-10T08:34:40Z

@volodya-lombrozo it's a bug in lints: objectionary/lints#122 Let me fix it and release new version

@yegor256 Thank you! Waiting for it.

yegor256 · 2024-12-10T08:39:24Z

@volodya-lombrozo try to use lints 0.0.22, it will not raise this exception

volodya-lombrozo · 2024-12-10T09:34:25Z

@yegor256 Indeed, I don't get this error anymore. However, I get this:

Caused by: java.lang.IllegalStateException: EO is incorrect: [[broken-alias ERROR]:0 The first part of the alias is invalid: "jeo.seq.of2", [broken-alias ERROR]:0 The first part of the alias is invalid: "jeo.seq.of0", [broken-alias ERROR]:0 The first part of the alias is invalid: "jeo.seq.of1", [broken-alias ERROR]:0 The first part of the alias is invalid: "jeo.method", [broken-alias ERROR]:0 The first part of the alias is invalid: "jeo.params", [broken-alias ERROR]:0 The first part of the alias is invalid: "jeo.int", [broken-alias ERROR]:0 The first part of the alias is invalid: "jeo.annotation-property", [broken-alias ERROR]:0 The first part of the alias is invalid: "jeo.bool", [broken-alias ERROR]:0 The first part of the alias is invalid: "jeo.class", [broken-alias ERROR]:0 The first part of the alias is invalid: "jeo.annotation", [broken-alias ERROR]:0 The first part of the alias is invalid: "jeo.maxs", [mandatory-version WARNING]:0 The +version meta is mandatory, but is absent, [incorrect-package WARNING]:0 The format of the +package meta is wrong: "j$org.j$eolang.j$hone.j$param", [unsorted-metas WARNING]:0 The "alias jeo.seq.of2" meta is out of order, [unsorted-metas WARNING]:0 The "alias jeo.seq.of0" meta is out of order, [unsorted-metas WARNING]:0 The "alias jeo.seq.of1" meta is out of order, [unsorted-metas WARNING]:0 The "alias jeo.method" meta is out of order, [unsorted-metas WARNING]:0 The "alias jeo.params" meta is out of order, [unsorted-metas WARNING]:0 The "alias jeo.int" meta is out of order, [unsorted-metas WARNING]:0 The "alias jeo.annotation-property" meta is out of order, [unsorted-metas WARNING]:0 The "alias jeo.bool" meta is out of order, [unsorted-metas WARNING]:0 The "alias jeo.class" meta is out of order, [unsorted-metas WARNING]:0 The "alias jeo.annotation" meta is out of order, [unsorted-metas WARNING]:0 The "alias jeo.maxs" meta is out of order, [mandatory-home WARNING]:0 The +home meta is mandatory, but is absent]
    at org.eolang.jeo.representation.VerifiedEo.asXml (VerifiedEo.java:71)
    at org.eolang.jeo.representation.MeasuredEo.asXml (MeasuredEo.java:58)
    at org.eolang.jeo.representation.BytecodeRepresentation.toEO (BytecodeRepresentation.java:117)
    at org.eolang.jeo.Disassembling.transform (Disassembling.java:86)
    at org.eolang.jeo.Caching.tryTransform (Caching.java:93)
    at org.eolang.jeo.Caching.transform (Caching.java:63)
    at org.eolang.jeo.Logging.transform (Logging.java:83)
    at org.eolang.jeo.Disassembler.disassemble (Disassembler.java:113)
    at org.eolang.jeo.ParallelTranslator.translate (ParallelTranslator.java:70)
    at java.util.stream.ReferencePipeline$3$1.accept (ReferencePipeline.java:197)
    at java.util.ArrayList$ArrayListSpliterator.forEachRemaining (ArrayList.java:1708)
    at java.util.stream.AbstractPipeline.copyInto (AbstractPipeline.java:509)
    at java.util.stream.ForEachOps$ForEachTask.compute (ForEachOps.java:291)
    at java.util.concurrent.CountedCompleter.exec (CountedCompleter.java:754)
    at java.util.concurrent.ForkJoinTask.doExec (ForkJoinTask.java:387)
    at java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec (ForkJoinPool.java:1312)
    at java.util.concurrent.ForkJoinPool.scan (ForkJoinPool.java:1843)
    at java.util.concurrent.ForkJoinPool.runWorker (ForkJoinPool.java:1808)
    at java.util.concurrent.ForkJoinWorkerThread.run (ForkJoinWorkerThread.java:188)

Why aliases are broken? Seems, it's one more bug in lints. Could you fix it please? It blocks the progress.

yegor256 · 2024-12-10T09:46:51Z

@volodya-lombrozo please, submit a new ticket for every new problem.

volodya-lombrozo closed this as completed Dec 6, 2024

volodya-lombrozo reopened this Dec 6, 2024

volodya-lombrozo changed the title ~~Dashes do not help. No viable alternative at input eo:0.43.0:xmir-to-phi~~ Dashes do not help. No viable alternative at input eo:0.46.0:phi-to-xmir Dec 6, 2024

volodya-lombrozo added the bug label Dec 6, 2024

volodya-lombrozo mentioned this issue Dec 6, 2024

feat(#939): Upgrade eo up to the 0.49.4 version objectionary/jeo-maven-plugin#942

Merged

yegor256 closed this as completed Dec 10, 2024

volodya-lombrozo mentioned this issue Dec 10, 2024

The first part of the alias is invalid jeo.seq.of2 objectionary/lints#127

Closed

Dashes do not help. No viable alternative at input eo:0.46.0:phi-to-xmir #3547

Dashes do not help. No viable alternative at input eo:0.46.0:phi-to-xmir #3547

Comments

volodya-lombrozo commented Nov 25, 2024

volodya-lombrozo commented Nov 25, 2024

maxonfjvipon commented Nov 25, 2024

volodya-lombrozo commented Nov 25, 2024

yegor256 commented Dec 6, 2024

volodya-lombrozo commented Dec 6, 2024

volodya-lombrozo commented Dec 6, 2024

volodya-lombrozo commented Dec 6, 2024

yegor256 commented Dec 6, 2024

maxonfjvipon commented Dec 6, 2024 • edited Loading

maxonfjvipon commented Dec 6, 2024 • edited Loading

maxonfjvipon commented Dec 6, 2024

maxonfjvipon commented Dec 6, 2024

volodya-lombrozo commented Dec 6, 2024

volodya-lombrozo commented Dec 6, 2024

maxonfjvipon commented Dec 6, 2024

maxonfjvipon commented Dec 6, 2024

volodya-lombrozo commented Dec 6, 2024 • edited Loading

yegor256 commented Dec 6, 2024

maxonfjvipon commented Dec 6, 2024 • edited Loading

maxonfjvipon commented Dec 6, 2024 • edited Loading

volodya-lombrozo commented Dec 9, 2024

maxonfjvipon commented Dec 9, 2024

volodya-lombrozo commented Dec 9, 2024

maxonfjvipon commented Dec 9, 2024 • edited Loading

volodya-lombrozo commented Dec 9, 2024

maxonfjvipon commented Dec 9, 2024 • edited Loading

volodya-lombrozo commented Dec 9, 2024

volodya-lombrozo commented Dec 9, 2024

maxonfjvipon commented Dec 9, 2024

volodya-lombrozo commented Dec 9, 2024

volodya-lombrozo commented Dec 9, 2024

maxonfjvipon commented Dec 9, 2024 • edited Loading

maxonfjvipon commented Dec 9, 2024

volodya-lombrozo commented Dec 9, 2024

volodya-lombrozo commented Dec 9, 2024

maxonfjvipon commented Dec 9, 2024 • edited Loading

volodya-lombrozo commented Dec 9, 2024

volodya-lombrozo commented Dec 9, 2024 • edited Loading

maxonfjvipon commented Dec 9, 2024 • edited Loading

volodya-lombrozo commented Dec 9, 2024

yegor256 commented Dec 9, 2024

volodya-lombrozo commented Dec 9, 2024

yegor256 commented Dec 9, 2024

maxonfjvipon commented Dec 9, 2024 • edited Loading

volodya-lombrozo commented Dec 9, 2024 • edited Loading

volodya-lombrozo commented Dec 9, 2024 • edited Loading

yegor256 commented Dec 9, 2024

volodya-lombrozo commented Dec 10, 2024

yegor256 commented Dec 10, 2024

volodya-lombrozo commented Dec 10, 2024

yegor256 commented Dec 10, 2024

volodya-lombrozo commented Dec 10, 2024 • edited Loading

yegor256 commented Dec 10, 2024

Dashes do not help. No viable alternative at input `eo:0.46.0:phi-to-xmir` #3547

Dashes do not help. No viable alternative at input `eo:0.46.0:phi-to-xmir` #3547

maxonfjvipon commented Dec 6, 2024 •

edited

Loading

maxonfjvipon commented Dec 6, 2024 •

edited

Loading

volodya-lombrozo commented Dec 6, 2024 •

edited

Loading

maxonfjvipon commented Dec 6, 2024 •

edited

Loading

maxonfjvipon commented Dec 6, 2024 •

edited

Loading

maxonfjvipon commented Dec 9, 2024 •

edited

Loading

maxonfjvipon commented Dec 9, 2024 •

edited

Loading

maxonfjvipon commented Dec 9, 2024 •

edited

Loading

maxonfjvipon commented Dec 9, 2024 •

edited

Loading

volodya-lombrozo commented Dec 9, 2024 •

edited

Loading

maxonfjvipon commented Dec 9, 2024 •

edited

Loading

maxonfjvipon commented Dec 9, 2024 •

edited

Loading

volodya-lombrozo commented Dec 9, 2024 •

edited

Loading

volodya-lombrozo commented Dec 9, 2024 •

edited

Loading

volodya-lombrozo commented Dec 10, 2024 •

edited

Loading