Using Eclipse plugin for CAL with Eclipse 3.6 (Helios) issue (Console is not working well)

[Karel Gardas]

Hello,

I'm trying to get into the Cal and testing various of provided
features. One important is Cal support provided by Eclipse while using
Cal Eclipse plugin. The problem I'm facing is that invocation of
functions inside the console is not working at all. I mean if the
function is well defined and it should invoke well the console just
prints stack trace of following exception. The same invocation in ICE
works well of course. The most simple way how to duplicate this is for
example invoke `absInt 10' inside Cal.Core.Prelude module. The output
(at least here) is as follows:

Cal.Core.Prelude> absInt 10
Running: absInt 10
Error while executing.
org.openquark.cal.runtime.CALExecutorException$InternalException:
Unable to create instance of Cal.Core.Prelude.io_target_0_0
Caused by: java.lang.ClassCastException:
org.openquark.cal_Cal_Core_Prelude.Id cannot be cast to
org.openquark.cal.internal.runtime.lecc.RTValue, Detail:
org.openquark.cal_Cal_Core_Prelude.Id cannot be cast to
org.openquark.cal.internal.runtime.lecc.RTValue

at
org.openquark.cal.internal.machine.lecc.Executor.exec(Executor.java:
160)
at org.openquark.cal.ConsoleRunner.runTarget(ConsoleRunner.java:217)
at org.openquark.cal.ConsoleRunner.runExpression(ConsoleRunner.java:
152)
at
org.openquark.cal.eclipse.ui.console.CALConsole.handleRequest_enteredText(CALConsole.java:
420)
at org.openquark.cal.eclipse.ui.console.CALConsole.access
$300(CALConsole.java:69)
at org.openquark.cal.eclipse.ui.console.CALConsole
$InputReadJob.run(CALConsole.java:274)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
Caused by: java.lang.ClassCastException:
org.openquark.cal_Cal_Core_Prelude.Id cannot be cast to
org.openquark.cal.internal.runtime.lecc.RTValue
at
org.openquark.cal.internal.machine.lecc.CALClassLoader.getStartPointInstance(CALClassLoader.java:
861)
at
org.openquark.cal.internal.machine.lecc.Executor.getInstanceOfGeneratedClass(Executor.java:
373)
at
org.openquark.cal.internal.machine.lecc.Executor.makeStartPointInstance(Executor.java:
260)
at
org.openquark.cal.internal.machine.lecc.Executor.exec(Executor.java:
158)
... 6 more
Internal runtime error.
Unable to create instance of Cal.Core.Prelude.io_target_0_0
Caused by: java.lang.ClassCastException:
org.openquark.cal_Cal_Core_Prelude.Id cannot be cast to
org.openquark.cal.internal.runtime.lecc.RTValue, Detail:
org.openquark.cal_Cal_Core_Prelude.Id cannot be cast to
org.openquark.cal.internal.runtime.lecc.RTValue

Cal.Core.Prelude>

is there any hint how to proceed in this case?

Thanks!
Karel

[Luke]

This is a definite bug.

We use the Eclipse plug-in every day here, but it turns out that none
of us use this built-in CAL shell - we all create one or more
launchable ICE sessions separately (using the ICE class in the Quark
Binaries project we have in the Eclipse workspace, rather than this
version that comes out of the plug-in package).

Consequently none of us had noticed what I can only imagine is a
regression here (and we don't have any testers checking the Eclipse
plug-in, we just use it as developers!).

Per my general comments on your other post, it's quite possible that
some assumption about classpath/classloading has been invalidated by a
change in the Eclipse plug-in system delivered over the last few
releases. We used Eclipse Europa for years, then made a few changes
to keep the bulk of the plug-in working properly through Galileo and
onward... but as I say nobody has been using the internal CAL Console
feature.

I'll add an issue on the git project for this. We're probably not
going to be able to get to fix this right away as we're all in the
middle of a push at the moment. If you know the Eclipse plug-in
system, perhaps you will be able to glean clue. Otherwise we can look
at it when we get our collective heads back above water!

[Tom Davies]

I had a look at this and found in
org.openquark.cal.eclipse.core.CALModelManager.java:

// TODO - can't currently make this work in runtime Eclipse
// setting to false results in CAL Console finding the wrong
version of Prelude.id.
// setting to true results in builder not being able to find
log4j classes.
USE_PLATFORM_PLUGIN_LOADER_AS_PARENT_LOADER = !runtimeEclipse;

Changing the above to
USE_PLATFORM_PLUGIN_LOADER_AS_PARENT_LOADER = runtimeEclipse;
certainly fixes the Console problem (and seems like the correct
classloader to use), but I'm not sure how to reproduce the log4j issue
mentioned in the comment.

Any ideas on exactly what "builder" is?

[Luke]

I think "builder" is the term for the thing that executes the compiler
on modified code, either automatically (when CAL module source is
detected as having been modified) or when directed to do so manually.

I'll ping the original developer and see if he can provide a bit more
colour.

[Edward]

Ok, I've been pinged. :)

Terminology:
- runtime Eclipse - this is Eclipse launched from Eclipse
- used by developers of CAL Eclipse plugins
- vs. standalone Eclipse -- Eclipse launched from command line
- builder - as surmised, this is the Eclipse project builder

This part of the code is trying to get foreign function resolution to
work.
I'm not sure, but I think we had some foreign functions wrapping log4j
stuff from the .jar.
In this case classloading the log4j classes is a bit odd: CAL includes
the log4j .jar, Eclipse is running CAL, and Eclipse-CAL integration
somehow has to put the .jar on the classpath in addition (evidently)
to the Eclipse classes.

I don't know if it's still the case, but when this code was written
the classloaders for the runtime and standalone Eclipse cases were
different (and really complicated), and so apparently were their
visibility rules.
In the runtime case the CAL builder wasn't able to find the log4j
classes, but there wasn't any problem in the standalone case.

So a <possible> source of regression is updates to the Eclipse
classloaders.

[Tom Davies]

Thanks Edward.

Classloading in OSGi is always great fun ;-)

My further experiments don't find any classloading differences between
running eclipse via an 'Eclipse Application' Run Configuration and via
the command line, so it looks as though Helios has made this more
consistent.

That is, System.getProperty("osgi.bundles") has a "reference:" prefix
in both cases, and the behaviour of the code below is the same in both
cases.

So I think that we can get rid of the whole
USE_PLATFORM_PLUGIN_LOADER_AS_PARENT_LOADER mechanism, and always
return MachineType.class.getClassLoader() from getParentLoader().

If there's another test I should be doing to check foreign functions
work, please let me know.

Tom

module Foo;

import Cal.Core.Prelude using
typeClass = Inputable, Outputable;
typeConstructor = String;
;

data foreign unsafe import jvm "org.apache.log4j.Logger"
public Logger deriving Inputable, Outputable;

foreign unsafe import jvm "static method
org.apache.log4j.Logger.getLogger"
public get :: String -> Logger;

gets this in the CAL Console:

Cal.Core.Prelude>:sm Foo
Foo>get "X"
Running: get "X"
Output:
org.apache.log4j.Logger@15404c6