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

[Per Bothner]

Post by Peter
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.

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

No.

Post by Peter
(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.

[Peter]

Hello Per!

Thanks for the answers ;)

Post by Per Bothner

Post by Peter
(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

[Per Bothner]

Post by Peter
Hello Per!
Thanks for the answers ;)

Post by Per Bothner

Post by Peter
(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.

Post by Peter
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.

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

The latter.

[Helmut Eller]

Post by Peter
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