Elements command line not cooperating with me

bugs://77952 got closed with status fixed.

Finally got a chance to look at this, it worked! Wondering if I did something wrong however, I am using a decompiler to review the output from the compiler and I saw this:

package test;

public final class Test
{
  private String $p_testing;
  
  private void settesting(String value)
  {
    self.$p_testing = value;
  }
  
  private String gettesting()
  {
    return self.$p_testing;
  }
  
  Test()
  {
    String str;
    self.settesting(str = "foo");
  }
}

Everything looks as expected except for the ā€œselfā€ keyword. Is that not translated to this usually? Is this an artifiact of the decompiler?

:+1:

Hard to say without (a) having your original code and (b) knowing the detailed insides of the decompiler you used and how it works. Youā€™d think a Java decompiler would emit ā€œthisā€, yes, since ā€œselfā€ (and ā€œthisā€, for that matter) is really a language syntax keyword, not a name that would get encoded into the final .jar, iā€™d expect

Itā€™s the same code I posted originally for context.

ah, ok. curious. what do you use to decompile the .jar? i assume the code works fine?

Havenā€™t run the code yet, just inspecting. I was using this:
http://jd.benow.ca/

Been working on getting mono to place nice with Bazel, making good
progress, soon I can run elementsCC.exe as I need.

ok. iā€™d say letā€™s not worry about it unless it doesnā€™t work as expected? i could escalate this for the compiler team to have a look at, but they got stuff to do as well. so unless thereā€™s an actual problemā€¦ :wink:

Yeah the ā€œself.ā€ reference is due to the local implicit ā€œthisā€ parameter being called ā€œselfā€ (this so the debugger can recognize it), it will show as self. in some decompilers, this is normal.

1 Like

Good to know! Just an unexpected coincidence! Thanks for the advice.

1 Like

So Iā€™ve almost got this working, I am getting a strange error message from elements right now:

Value cannot be null.
Parameter name: path1

I notice this happens when I give a reference to bazelā€™s internal rt.jar as a --ref. If I give it an absolute path to my OS JDK this actually works fine, but it breaks the sandbox. I am using this sandboxed command being generated by bazel:

(cd /private/var/tmp/_bazel_perezd/811f60be6a1051cf49585ebc378f1218/execroot/blockparty && \
  exec env - \
    MONO_LOG_LEVEL=debug \
    MONO_PATH=external/elements:external/elements/References/Echoes \
  external/mono/mono/bin/mono external/elements/ElementsCC.exe -d '--out=bazel-out/local-fastbuild/bin/devtools/bazel/rules/elements/examples' '--assembly=vote.blockparty.testing' '--ref=external/local_jdk/jre/lib/rt.jar' '-t=library' '-m=cooper' devtools/bazel/rules/elements/examples/Test.swift devtools/bazel/rules/elements/examples/Other.swift)

Hereā€™s the full debug log from mono if it helps:

Also, I can confirm that the rt.jar file is present at the path I am referencing.

Any additional thoughts on this? Let me know what else I could provide to help debug this!

EDIT: I am pretty sure that path to rt.jar is a symlink if that is interesting information.

Thanks, logged as bugs://78152

bugs://78152 got closed with status fixed.

Does this mean thereā€™s a build that I can test to see if this works now?

itā€™ll be in next fridays beta. but i an shoot you a build earlier if you like. whatā€™s your account name on RemObjects.com?

should be perezd, thanks! (donā€™t have access to betas, yet, still
evaluating).

Any idea what happened there? Was it the symlink?

no basically it was using the project filename to find a relative reference, but the project didnā€™t exist for this commandline. bug in the code.

iā€™ve uploaded a new build to your personal downloads folder.

Hey there, not seeing anything here:
https://secure.remobjects.com/portal/downloads/beta.aspx

Also nothing here:
https://secure.remobjects.com/portal/downloads

https://secure.remobjects.com/portal/downloads/personal should have it.

1 Like