Environment Introspection

Environment Introspection

[Peter]

Hello ;)

Is there a way to enumerate all loaded modules / libraries /
environments? For things like finding out what I can "import"? I've seen
gnu.mapping.Environment, is there a global list of existing Environments
anywhere? (This is for implementing a swank server for multiple Schemes,
to make them work with SLIME).

Thanks for any help!

Greetings, 
Peter

Re: Environment Introspection

[Per Bothner]

On 09/17/2017 01:56 PM, Peter wrote:
> Is there a way to enumerate all loaded modules / libraries /
> environments? For things like finding out what I can "import"?

Not easily.  You can import just about any class in the CLASSPATH,
and I don't know of any direct way on the Java platform to enumerate all
the classes in the CLASSPATH.

It is possible to use the Java Debug Interface to return a list
of all loaded types (com.sun.jdi.VirtualMacine#loadedTypes).

It is possible to for each element in the CLASSPATH:
(1) if the element is a .jar you find the set of entries in the jar.
(2) if the element is a directory you find the .class files in
sub-directories.
(3) If the element is an ArrayClassLoader (used for Kawa dynamic classes),
search available classes
(4) otherwise skip the classloaader element.

This is a non-trivial job, of course.  It may be needed for tab-completion
but useful tab-completion should be possible without it.

> I've seen gnu.mapping.Environment, is there a global list of existing
> Environments anywhere?

No.

> (This is for implementing a swank server for multiple Schemes,
> to make them work with SLIME).

I think supporting the Language Server Protocol is most promising path for
IDE support (including on Emacs), but it's great if you can make Swank/Slime useful.

-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/

Re: Environment Introspection

[Peter]

Hello Per!

Thanks for the answers ;)

>> (This is for implementing a swank server for multiple Schemes,
>> to make them work with SLIME).
> I think supporting the Language Server Protocol is most promising path for
> IDE support (including on Emacs), but it's great if you can make Swank/Slime useful.

I haven't looked into it closely yet, but is there an Emacs frontend
that supports unified debugging and inspection? That's the reason I'm
interested in SLIME at all, compared to geiser. I don't just want an
interface to the existing repl, I want actual debugging, inspection and
tracing support ;) Things are working ok so far, I'll just see how far I
get ;)

Relatedly, is there any secial support in kawa for stack traces, or
would I just use normal java introspection?

Thanks for the help!

Greetings,
Peter

Re: Environment Introspection

[Per Bothner]

On 09/17/2017 10:42 PM, Peter wrote:
> Hello Per!
> 
> Thanks for the answers ;)
> 
>>> (This is for implementing a swank server for multiple Schemes,
>>> to make them work with SLIME).
>> I think supporting the Language Server Protocol is most promising path for
>> IDE support (including on Emacs), but it's great if you can make Swank/Slime useful.
> 
> I haven't looked into it closely yet, but is there an Emacs frontend
> that supports unified debugging and inspection? That's the reason I'm
> interested in SLIME at all, compared to geiser. I don't just want an
> interface to the existing repl, I want actual debugging, inspection and
> tracing support ;)

As far as I can tell, the Language Server Protocol does not support debugging.
It handles things like code completion, cross-references, error messages, etc.
I'm guessing LSP-based IDE handle debugging some other wise - if they handle
debugging at all.

> Things are working ok so far, I'll just see how far I
> get ;)

Once you have something useful, I'd like to see a "how-to" style writeup.
> 
> Relatedly, is there any secial support in kawa for stack traces, or
> would I just use normal java introspection?

The latter.


-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/

Re: Environment Introspection

[Helmut Eller]

On Mon, Sep 18 2017, Peter wrote:

> I want actual debugging,

When I tried to implement debugging for SLIME, I found Kawa quite
frustrating and eventually gave up for the following reasons:

Debugging, the way SLIME does it, is difficult/impossible because Kawa
uses JVM exceptions for most error handling.  While Kawa has now
`with-exception-handler', few people use it and certainly no Java
libraries use it.

The Kawa code base also has the idiom try {...} catch (Throwable x) in a
number of places, with defeats tricks based on
com.sun.jdi.request.ExceptionRequest.notifyUncaught.

Another problem with Kawa are the unstable/non-existing/constantly
changing APIs to Kawa internals.

I would suggest that you work as closely as you can with Per, so that he
is aware of the issues and doesn't (unintentionally) break your work.
For that reason, it makes a lot of sense to use LSP.  LSP may not have a
"standard" API for debugging, but I think it's fairly easy to add
extensions to LSP for whatever you like.  I would also expect that
writing an Emacs front-end for LSP is easy/fun in comparison to digging
around in Kawa internals.  So let Per do the hard work on the Kawa side
to make a good LSP server and spend your time in on the Emacs side :-).

Helmut