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?
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ā¦
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.
Good to know! Just an unexpected coincidence! Thanks for the advice.
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