`inspect` command, new feature

[yegor256]

When I start eoc inspect it should load all .class files into the VM and then give me an interactive interface, for example:

$ eoc inspect
Loaded 56 objects
Ready to traverse the Universe
@ Φ ⟦org⟧
_

Current position in the tree is printed with the @ prefix.

Then, I type in:

@ Φ ⟦org⟧
.org

@ Φ.org ⟦bytes⟧
.eolang

@ Φ.org ⟦number bytes go malloc ... +15⟧
.bytes

@ Φ.org.bytes ⟦data and or xor div plus minus ... +7⟧
ls
.data ↦ ∅
.and ↦ ⟦ λ, b ⟧
.or ↦ ⟦ λ, b ⟧
...

@ Φ.org.bytes ⟦data and or xor div plus minus ... +7⟧
cp Φ.bar
Copied @ Φ.org.bytes to @ Φ.bar

@ Φ.bar ⟦data and or xor div plus minus ... +7⟧
ls
.data ↦ ∅
.and ↦ ⟦ λ b ⟧
.or ↦ ⟦ λ b ⟧

@ Φ.bar ⟦data and or xor div plus minus ... +7⟧
.data

@ Φ.bar.data ∅
form

@ Φ.bar.data ⟦⟧
put 04-05-96-92-2F-E3

@ Φ.bar.data ⟦Δ⟧
run
04-05-96-92-2F-E3

There are four possible commands:

• .. - jump to the upper object in the tree
• add foo (or +foo) - add new attribute foo to the current object
• rm foo (or -foo) - delete foo attribute from the current object
• go foo (or .foo) - jump to the object attached to the foo attribute
• to Φ.bar - attach Φ.bar to the current object
• form - create an empty formation and attach to the current object
• put 75-E4-3F - attach data to the Δ asset of the current object
• cp Φ.bar - make a copy of the current object and attach it to Φ.bar
• dd foo Φ.bar - dispatch foo and attach the result to Φ.bar
• ls - print all attributes of the current object
• dataize (or run) - dataize current objects and print result

[yegor256]

@maxonfjvipon @volodya-lombrozo what do you think?

[volodya-lombrozo]

@yegor256

1. Do you want to add the inspect command? Or it exists already?
2. Which problem would you like to solve by this command?
3. Why do we need such interaction?

[yegor256]

@volodya-lombrozo we don't have it now, it's a proposal. This is supposed to be a debugging tool. When a program doesn't run, we may want to inspect why this happens. Traversing a tree of objects may help.

[volodya-lombrozo]

@yegor256 It's unclear which .class files you're referring to here. Can you please explain a real use case, please? Is this feature for eo programs only?

btw, I've heard that debugging is not a good practice.

[maxonfjvipon]

btw, I've heard that debugging is not a good practice.

@volodya-lombrozo you're right, it's not, but EO is overdeclarative and overlazy, sometimes it's unreal to understand in what exact place we have an error, even with a lot of unit tests. Also I think the presence of such debugging tool is a natural stage of language development. So in general, I like the idea

[ErnestMatskevich]

I have a question regarding the necessity of loading .class files into the JVM in all cases for the inspect command.

In my opinion, for the majority of commands (e.g., go, ls, add, rm, etc.), it is possible to avoid loading .class files into the JVM. These commands only work with information about the structure of objects (names, attributes, methods), which can be obtained from a pre-built data structure, such as an object tree.

I propose considering the following approach:

1. For commands that do not require code execution (e.g., navigation, adding/removing attributes, displaying information), analyze a pre-prepared object tree.
2. For commands related to code execution (e.g., dataize and dd), load .class files into the JVM only when necessary.

Additionally, I am considering the possibility of using XMIR instead of analyzing .class files to build the object tree. XMIR seems to be a more convenient format for this task because:

• It already contains all the necessary information about objects in a readable XML format.
• It is part of the EO ecosystem and aligns with the project's principles.
• It simplifies the process of analyzing and creating a data structure for the inspect command.

If this approach is acceptable, using XMIR will significantly simplify the implementation of most commands while reserving the loading of .class files into the JVM only for cases where it is truly necessary.

@yegor256 what are your thoughts on this approach? Are there any objections or additional recommendations?

[yegor256]

@ErnestMatskevich the inspector should study the tree that exist in memory, not in classpath. In other words, when you need to do ls (list all attributes of an object), you don't use Reflection API. Instead, you call obj.getAttributes() (or something similar).

First, we need to load all classes into memory. Then, you get the root object. Then, you ask root object: .getAttributes(). It calculates an answer and returns it to you. Then, you show it to us.

Neither XMIR nor class information can help in this case.

[ErnestMatskevich]

@yegor256, I want to clarify a technical details.
From what I understand about the current architecture:

When executing the dataize command, classes are loaded into JVM by running eoc.jar, which contains:

• Compiled program classes
• The complete EO runtime

To implement inspect, I need to:

1. Add new inspection functionality to this .jar
2. Provide access to in-memory objects through runtime API (e.g. Phi.getAttributes())

Is my understanding correct that:

• All classes are already loaded into JVM when starting eoc.jar
• I should extend the existing .jar by adding interactive inspection classes
• No separate loading of .class files is needed beyond the main .jar?

[yegor256]

@ErnestMatskevich maybe it's better to leave the .jar with EO* classes untouched. Instead, create an additional JAR, with a new Inspect class inside, with the static main() method. The JavaScript eoc inspect command should start Java with two jars in classpath and run Inspect.main() as a background process:

java -cp eo.jar:inspect.jar org.eolang.eoc.Inspect --port 8080 &

This Inspect.main() function should start a webserver and open TCP port 8080 (for example). Then, JS part will start sending HTTP requests to this server, asking to run all the commands that the user sends from the command line. All responses will come back to JS in JSON or XML format and will be printed to the console.

p.s. I suggest using the Takes framework for the webserver.

[ErnestMatskevich]

@yegor256 could you please help me understand how to organise good architecture. I need to create .java file to run Takes server and need inspect.js file to run inspect command. Where should I place it? Is is good practice to create folder inspect inside src folder and placed all files in this folder? Also I tryed to make different files for different options, like inspect_ls.js for ls and etc. Is it also OK or better to put all code in single inspect.js file?

And as I understand I can add Takes dependices in mvnw/pom.xml. Am I right or I should add Takes in some different way?

By waiting stable version I used eoc 0.28.0 as installed module to make dataization of EO program and wrote inspect implementation in new project and now trying to migrate files in source code of eoc.

Also when I create inspect.jar file where it is better to place it? I placed it in .eoc folder to easy load all .jar files in JVM from .eoc folder. In new version I see 2 .jar files after dataization: eoc.jar and original-eoc.jar. In 0.28.0 version was only eoc.jar file. Should I ignore original-eoc.jar file and continue to work with eoc.jar file and load it in JVM with my inspect.jar?

[yegor256]

@ErnestMatskevich please, read this article: https://www.yegor256.com/2024/12/15/open-source-beginner-advice.html (pay attention to the "Don't Ask Questions" part).