These are chat archives for ceylon/ceylon-ide-eclipse

5th
Dec 2016
Gavin King
@gavinking
Dec 05 2016 17:48
@davidfestal I can’t currently build the Eclipse plugin
I think this is the problem:
    [exec] /Users/gavin/ceylon-ide-eclipse/plugins/com.redhat.ceylon.eclipse.ui/source/com/redhat/ceylon/eclipse/core/launch/CeylonAwareLaunchConfiguration.ceylon:211: error: method or attribute is not defined: 'loadedModules' in type 'CeylonClasspathTool' might be misspelled (did you mean 'loadModule'?)
     [exec]                                 => super.loadedModules.values();
     [exec]                                          ^
David Festal
@davidfestal
Dec 05 2016 17:56
Ah, something might have changed in the CeylonClasspathTool
it's building here, but I've not pulled today
I'll pull asap to test again
Gavin King
@gavinking
Dec 05 2016 17:58
ok, thanks
David Festal
@davidfestal
Dec 05 2016 17:59
you're welcome
by the way, I'm working on ceylon/ceylon-ide-eclipse#1858
I can already debug the Eclipse plugin itself with full ceylon debugging support, and debug hover in the Ceylon code of the IDE :-)
Gavin King
@gavinking
Dec 05 2016 18:00
ok, great
that will be an improvement
now if only we had that in IntelliJ...
David Festal
@davidfestal
Dec 05 2016 18:01
sure, but that will be available also for remote java applications, and even I assume for Java projects calling ceylon code
Gavin King
@gavinking
Dec 05 2016 18:02
ok great
David Festal
@davidfestal
Dec 05 2016 21:54
I confirm that I was was using a protected method of CeylonClasspathTool that has disappeared recently
I'll look into it tomorrow to replace it
by another equivalent call
Gavin King
@gavinking
Dec 05 2016 21:57
Ok good
David Festal
@davidfestal
Dec 05 2016 21:58
instead of using the CeylonClasspathTool, I can probably scan the ceylon classpath container of the ceylon projects to arrive at the same result.
I'll test tomorrow
bye !
and... finally full debugging support in remote Java application is less easy as it seemed, because it requires starting an agent in a remote VM, and that requires tools.jar
Tako Schotanus
@quintesse
Dec 05 2016 22:00
@davidfestal Take a look at the recent changes to CeylonClassPathTool, I think @FroMage did some work exactly in factoring out things having to do with class path scanning or something like it. CHeck it out, it might be what you're looking for.
David Festal
@davidfestal
Dec 05 2016 22:00
I've checked it out already, and confirmed that what I was using disappeared
but I might be able to find another way, to do without it
Tako Schotanus
@quintesse
Dec 05 2016 22:01
but are you sure it wasn't factored out into a different, re-usable, class?
David Festal
@davidfestal
Dec 05 2016 22:01
well, not simply afaik
no for my specific need
but I might be wrong
I'll continue tomorrow
Tako Schotanus
@quintesse
Dec 05 2016 22:02
which method was it that you were using?
David Festal
@davidfestal
Dec 05 2016 22:02
I wasn't using a method. I was using the loadedModules protected field
which was not very nice I admit :-/
Tako Schotanus
@quintesse
Dec 05 2016 22:03
Sure, but that's now changed to loader.visitModules(new ModuleGraph.Visitor() { ... } ) AFAIK
David Festal
@davidfestal
Dec 05 2016 22:04
yes, I saw
Tako Schotanus
@quintesse
Dec 05 2016 22:05
So it seems that @FroMage took out the code that would initialize that protected field and turned it into a dedicated class
David Festal
@davidfestal
Dec 05 2016 22:05
Ah, you mean I could simply use my own visitor on the loader protected class
OK, I understand
Tako Schotanus
@quintesse
Dec 05 2016 22:05
Yes, or perhaps instantiate your own version of that laoder
It seems to need only a RepositoryManager (which you surely have) and a ModuleLoadingTool. And the latter it seems to use only for a couple of fields
David Festal
@davidfestal
Dec 05 2016 22:08
yes, so I can directly use the CeylonClasspathTool in fact. Just use it differently.
I'm trying now
Tako Schotanus
@quintesse
Dec 05 2016 22:09
YEah, although that dependency on the ModuleLoadingTool is a bit of a nuisance. Without that you'd have no dependency on any tool which would have been nicer
David Festal
@davidfestal
Dec 05 2016 22:11
well, we also depend on the CeylonBootsrapTool
Tako Schotanus
@quintesse
Dec 05 2016 22:12
I mean just in this particular case. You're creating a CeylonClasspathTool for no good reason really
David Festal
@davidfestal
Dec 05 2016 22:13
well, this allows using a tool that I know does the same thing as the corresponding command line
Tako Schotanus
@quintesse
Dec 05 2016 22:13
It should probably be possible to use the ModuleLoader directly
Yeah, I understand
Still, it's a bit of a hack
David Festal
@davidfestal
Dec 05 2016 22:14
yeah,
Tako Schotanus
@quintesse
Dec 05 2016 22:14
Would be nicer if we'd allow you to do it without that
Anyway, I just wanted to point out that code to you because I thought it would help :)
David Festal
@davidfestal
Dec 05 2016 22:15
or simply provide a way to retrieve a result from the CeylonClasspathTool
Sure, Thanks it helped :-)
I had not realized I could simply call a visitor after the run()
Tako Schotanus
@quintesse
Dec 05 2016 22:18
Couldn't you do it without calling run()?
David Festal
@davidfestal
Dec 05 2016 22:19
well, run() calls resolve after initializing some stuff afaiu
Tako Schotanus
@quintesse
Dec 05 2016 22:20
yes, seems so, but it looks very simple, just:
loadModule(null, "com.redhat.ceylon.java.main", Versions.CEYLON_VERSION_NUMBER);
loadModule(null, moduleName, version); // Your module here
loader.resolve();
It would avoid printing something out to stdout which you probably don't need :)
David Festal
@davidfestal
Dec 05 2016 22:22
that' right
I'll finish that tomorrow. Bye ! and Thanks for your help @quintesse !