Re: [Ikvm-developers] eclipse with ngen

[Jeroen F. <je...@su...>]

Hi,



Thanks for the files. I'll have a look at them when I get back from travelling.



The workspace issue also happened when I worked on Eclipse, but I never spent much time on it, since it sort of worked and I only wanted to use for it demoing :-)



Most ikvmc crashes nowadays are from "doing something wrong", but it shouldn't crash. It should give a (hopefully helpful) error message.



Thanks,

Jeroen



________________________________
From: Sazaai Aries [ml....@li...]
Sent: Sunday, July 17, 2011 7:56 AM
To: Jeroen Frijters; ikv...@li...
Subject: RE: [Ikvm-developers] eclipse with ngen

Hi,

forcing ikvm to run in 32-bit mode worked to bring it up in dynamic mode, thanks.
That still had the workspace problem though; it seems to just go straight into the last workspace loaded, without asking (despite the setting).

Your code still works for the most part, I just needed to make minor modifications to get it to work on indigo (preliminary results attached as response1.txt)
With that, it does manage to build everything, and eclipse starts up with ~ the same behavior as in dynamic mode (again, no workspace prompt),
but starts up a good bit faster and has a much smaller memory footprint.
I did find it rather odd/concerning that there were a number of unresolved 'required' bundles, seems a bit odd that bundles would be included with missing dependencies.
For now, I just had it skip references to those dependencies, it still seems to start up fine, so I suppose I didn't try to use anything that needs those bundles.
I am quite happy to see eclipse still mostly works on ikvm, so thanks for the help there :)
Any ideas on the workspace bit?

I attached a number of ikvmc call chains (the org.* attachments) that result in the InvalidOperationException on the last call to ikvmc.  I was probably doing something wrong there anyway, but, they do cause that exception for me (running it on eclipse indigo's sdk<http://ftp.halifax.rwth-aachen.de/eclipse//eclipse/downloads/drops/R-3.7-201106131736/eclipse-SDK-3.7-win32.zip>).  Ah, they do expect eclipse-clr and its dependencies to be present, rebuilt with the current version of ikvm.  In case it matters, I am running it on windows 7, 64-bit.


________________________________
From: je...@su...
To: ml....@li...; ikv...@li...
Subject: RE: [Ikvm-developers] eclipse with ngen
Date: Sat, 16 Jul 2011 23:22:29 +0000

Hi,

The BadImageFormatException means that you run ikvm.exe in 64 bit mode, but try to load a 32 bit native dll. You'll need to run "corflags /32bit+ ikvm.exe" to force it to run in 32 bit mode.

The InvalidOperationException is a bug in ikvmc. What version of ikvmc did you use? Can you please provide me with the steps to reproduce it?

When you statically compile and a static dependency is not found, it can never be resolved at runtime.

I've attached the code I used to produce the ikvmc response files, but that was 2009, so it probably needs some work with recent Eclipse versions. I haven't looked at recent versions myself.

Regards,
Jeroen

________________________________
From: Sazaai Aries [ml....@li...]
Sent: Sunday, July 17, 2011 12:56 AM
To: ikv...@li...
Subject: [Ikvm-developers] eclipse with ngen

Hi,

The eclipse with ngen<http://weblog.ikvm.net/PermaLink.aspx?guid=1aecaf4e-24c0-4f96-861b-f3b4473c7525> post got me interested in trying it with the most recent versions of eclipse and ikvm.

I also tried running it in dynamic mode (both indigo and ganymede), but the articles I read about it had broken links.
Running eclipse with –vm ikvm\bin\ikvm.exe gives me this exception (if I have ikvm-native.dll, otherwise it complains about ikvm-native missing):
cli.System.BadImageFormatException: An attempt was made to load a program with an incorrect format. (Exception from HRESULT: 0x8007000B)
at cli.IKVM.Runtime.JniHelper.ikvm_LoadLibrary(Unknown Source)
at cli.IKVM.Runtime.JniHelper.LoadLibrary(Unknown Source)
at IKVM.NativeCode.java.lang.ClassLoader+NativeLibrary.doLoad(Unknown Source)
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1788)
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1684)
at java.lang.Runtime.load0(Runtime.java:788)
at java.lang.Runtime.load(Runtime.java:775)
at org.eclipse.equinox.launcher.JNIBridge.loadLibrary(JNIBridge.java:49)
at org.eclipse.equinox.launcher.JNIBridge.showSplash(JNIBridge.java:76)
at org.eclipse.equinox.launcher.Main.handleSplash(Main.java:1844)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:503)
at org.eclipse.equinox.launcher.Main.run(Main.java:1237)
at org.eclipse.equinox.launcher.Main.main(Main.java:1212)

I tried hacking eclipse-clr up to start up indigo, which to an extent did work, but it seems to have problems with workspaces – it won’t prompt for the workspace on startup (even though the setting is enabled for it to do so), and trying to switch workspaces brings up an error (saying that eclipse.vm wasn’t set).

Modifying eclipse-clr’s call to the launcher to include –install –data <workspace path> at least gets it to load the specified workspace, but it would still be nice to get the system to prompt for it as normal.

Now, ultimately I’d like to ikvmc everything; what would be the best way to generate a script to build everything so it works with eclipse-clr’s means of loading bundles (or modified as necessary)?
I tried generating my own based on the bundle & package dependency graph, but I end up with exceptions on some of them when ikvmc’ing each bundle individually it:
System.InvalidOperationException: Operation is not valid due to the current state of the object.
at IKVM.Internal.ClassLoaderWrapper.IssueMessage(Message msgId, String[] values)
at IKVM.Internal.ClassLoaderWrapper.LoadClassNoThrow(ClassLoaderWrapper classLoader, String name)
at IKVM.Internal.ClassLoaderWrapper.SigDecoderWrapper(Int32& index, String sig, Boolean nothrow)
at IKVM.Internal.CompiledAccessStubFieldWrapper.TryGet(TypeWrapper wrapper, PropertyInfo property, FieldWrapper& accessStub)
at IKVM.Internal.CompiledTypeWrapper.LazyPublishFields()
at IKVM.Internal.TypeWrapper.GetFields()
at IKVM.Internal.TypeWrapper.GetFieldWrapper(String fieldName, String fieldSig)
at IKVM.Internal.ClassFile.ConstantPoolItemFieldref.Link(TypeWrapper thisType)
at IKVM.Internal.ClassFile.Link(TypeWrapper thisType)
at IKVM.Internal.DynamicTypeWrapper.JavaTypeImpl.Finish()
at IKVM.Internal.AotTypeWrapper.Finish()
at IKVM.Internal.DynamicTypeWrapper.JavaTypeImpl.Finish()
at IKVM.Internal.AotTypeWrapper.Finish()
at IKVM.Internal.CompilerClassLoader.Compile()
at IKVM.Internal.CompilerClassLoader.Compile(String runtimeAssembly, List`1 optionsList)
at IkvmcCompiler.Main(String[] args)

and having ikvmc load the parameters out of the file complains about missing references, so I’m probably doing something wrong there.

If I try running it anyway (hoping the dynamic loader would fill in for the gaps), eclipse quits with the attached log.

Has anyone else tried and/or succeeded in getting this to work with indigo?