marinier
commented
2 weeks ago I'm not 100% sure, but I believe that SML.java is needed to handle callbacks, which at least when that was written could not be handled by SWIG. Projects can use the Java interface without using the debugger, and this may be required (e.g., if running on a machine with no graphics).
I suspect that the debugger API and debugger could be combined - it's good software engineering practice to separate interfaces and implementations, but realistically there will never be a different implementation. But I don't know if these need to be separated to support remote connections (that is, maybe the client side needs the API), but I doubt that is the case.
On Mon, Oct 28, 2024, 11:32 PM Nathan Glenn @.***> wrote:
The Soar repository contains three projects under /Java: SMLJava, DebuggerAPI, and Debugger. What does SMLJava do beyond what is already generated by SWIG from the SML classes? And what is in DebuggerAPI, which is used in Debugger? Is it used anywhere else? Can we combine them, or are clients using the DebuggerAPI jar separately?
None of these projects have readme files, and I'm considering moving the debugger into a separate repository to make it conceptually simpler to run normal Java builds of it (gradle/maven, new dependencies and dependency updates, unit tests, etc., similar to the update I made to VisualSoar).
— Reply to this email directly, view it on GitHub https://github.com/SoarGroup/Soar/issues/515, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAECTXGDYABUAHJKHXKLNJLZ536WLAVCNFSM6AAAAABQY4HL56VHI2DSMVQWIX3LMV43ASLTON2WKOZSGYZDAMBTGAZTONA . You are receiving this because you are subscribed to this thread.Message ID: @.***>
The Soar repository contains three projects under /Java: SMLJava, DebuggerAPI, and Debugger. What does SMLJava do beyond what is already generated by SWIG from the SML classes? And what is in DebuggerAPI, which is used in Debugger? Is it used anywhere else? Can we combine them, or are clients using the DebuggerAPI jar separately?
None of these projects have readme files, and I'm considering moving the debugger into a separate repository to make it conceptually simpler to run normal Java builds of it (gradle/maven, new dependencies and dependency updates, unit tests, etc., similar to the update I made to VisualSoar).