Don't know if you want to put this based on a 514 branch or something,
for full support. Here's the bulk of the work done for the builtins
though.
- gradient()
- animate(space) // weird form
- rgb(space) // weird form
- rgb2num()
- filter(type="bloom")
- load_resource()
- splicetext()
- list.Splice()
- time2text()
- world.timezone
- client.timezone
- ||=
- &&=
- world.movement_mode + enums
- := walrus/assign-into/expression assign
- world.map_cpu
- particles/
- generator/
- embedded winget syntax // don't think we need to add anything
- mouse actions // don't think we need to add anything
note: uncovered http://www.byond.com/forum/post/2652280
Tested the produced executable:
This requires an update to
https://github.com/willox/auxtools/releases/tag/debug-v1.0.0.
Basically, this'll let me add new debug console commands without having
to touch SpacemanDMM. I'm gonna be adding some as I push my way through
some DM bytecode related stuff so this'll save me a bunch of effort.
There's no new functionality here, it's still only `#help` and `#dis`.
The DLL is starting to get a bit big (it's still much smaller than a
tiny example implementing maptick which for some reason comes out at
2.5MB) so I'll try to get them smaller before making any new releases.
This fulfils some auxtool debugger requests you had.
1) All connection modes except for `BACKGROUND` wait for the DAP client
to be configured before continuing.
2) stddef.dm contents are sent to the debug client
3) disassemble eval command works (with the added benefit of being able
to disassemble procs that aren't currently running)
The updated auxtools also does some other stuff you wanted:
1) src/usr moved to arguments
2) your PR https://github.com/willox/auxtools/pull/11
3) arguments with no formal parameter in a proc that is being debugged
should show up
This adds support for a debug server written in auxtools (currently
located at https://github.com/willox/auxtools).
The dependency is similar to extools, where SpacemanDMM's
`auxtools_types.rs` has to be up-to-date with the `server_types.rs`
file located in whichever version of debug server is used. In the
future this could change to be some shared dependency, or maybe the
debug server could just be moved into SpacemanDMM.
There's a bunch of repeated code in `mod.rs` where there's match
statements where one branch is for the extools client and one branch is
for auxtools client. It's a bit iffy, but they all have minor
differences and wouldn't be super easy to merge.
I accidentally ran a `cargo fmt` on the files I was working with at
some point, so there's a few formatting changes about. I don't think
it's too much to read over.
I haven't edited any documentation yet, so here's how it works:
In your DM project:
```dm
// Currently needed for auxtools' error reporting. TG code already has this defined.
/proc/stack_trace(msg)
CRASH(msg)
/proc/enable_debugging(mode, port)
CRASH("auxtools not loaded")
/world/New()
var/debug_server = world.GetConfig("env", "AUXTOOLS_DEBUG_DLL")
if (debug_server)
call(debug_server, "auxtools_init")()
enable_debugging()
. = ..()
/world/Del()
var/debug_server = world.GetConfig("env", "AUXTOOLS_DEBUG_DLL")
if (debug_server)
call(debug_server, "auxtools_shutdown")()
. = ..()
```
In your project's SpacemanDMM.toml
```toml
[debugger]
engine = "auxtools"
```
The extension doesn't have a way to override the DLL being used (and I
don't think it should), so if you're testing stuff I suggest you set
the env vars to something like below and use the attach mode:
```
AUXTOOLS_DEBUG_DLL=path_to_your_build
AUXTOOLS_DEBUG_MODE=BLOCK
```
