@macca, so after some wandering through alternatives... I'm thinking I leave the doc generator as is (no constants, structs) unless we detect {Spin2_Doc_CON} as the initial line in a CON section; then all constants and structs from that section are documented. This way, one can mark as many or as few sections as needed, no matter where they are in the source file.
How does this sound in terms of simplicity and opt-in behavior?
I'm using Google's agent AI thingy called Antigravity with some success to develop Spin2 code. the desktop interface is essentially VSCode (but pointed at different extension site). I wanted to have syntax highlighting and all the other features of this Spin2 VSCode extension ... which took a bit of hunting to get the .visx direct from the vscode extension server and manually load it into Antigravity. If anyone else is headed this direction, here is the url to get the .visx directly: https://marketplace.visualstudio.com/_apis/public/gallery/publishers/IronSheepProductionsLLC/vsextensions/spin2/2.10.6/vspackage
@refaQtor said:
I'm using Google's agent AI thingy called Antigravity with some success to develop Spin2 code. the desktop interface is essentially VSCode (but pointed at different extension site). I wanted to have syntax highlighting and all the other features of this Spin2 VSCode extension ...
IT's fun to hear that you got that working.
You might also want to look at P2 Knowledge base MCP. I think Antigravity supports MCPs, so this would give your agent P2 Architecture understanding and a full Spin2/Pasm2 language reference.
I did get that plugged in following the same directions that you have for Claude/Cursor... as a config entry under "mcpServers": {} I generally use Claude Opus 4.6 (thinking) beneath Antigravity.
and I've been using it to build test harness with pnut-term-ts . I have too many tests to fit into one executable (I tried), so now I have separate binary for the 3-tier (HUB/PSRAM/uSDcard -thanks to you) string-interning b-tree database in paged memory, the AST parser, the Eval and Compile stages, the XBYTE Tail-Call Optimized Lisp engine (on, so far, only one COG - ~430 SKIPF packed PASM instructions), the !UNHOLY! 4-color Garbage Collector that binds it all together concurrently from a TASK on a separate COG, the Lisp REPL, 9P host filesystem access, the Octoserialports (again, thank you), the prolog/datalog inference engine... ALL of that as my foundation to, finally, support smooth logical configuration of Smart Pins! This is my fourth go at it all, in as many months - have implemented all the systems functionally, though feebly, and learned a lot. GO TIME, THIS TIME! working on proving the GC now.
and that takes lots of builds of separate binaries... to speed that up, I kick off parallel builds of ALL the tests (I still have a few Ryzen cores left over) after the source folder is copied as many times to work in... HUGE TIMESAVER, though I still doing the P2 tests serially. maybe I'll get around to parallelizing that, too. I've got a half-dozen or so P2 EDGE 32MB modules on my bench here.
so, yeah, now I'll head over and bump up your Patreon support!. you've made some great tools and foundational libraries that we can count on.
I've just released v2.11.0 of our spin2 extension.
Users of VSCode get automatic updates, so you all have these updates already!
Here are highlights of what's new:
v2.11.0
Added
Add PNut v54 STRUCT bitfield support: named bitfields on BYTE/WORD/LONG struct members (STRUCT pin_t(LONG flags.input[0].drive[3..2].value[31..24])) and nameless sole-member structs (STRUCT io_t(LONG.ready[0].counter[31..8])).
Add diagnostic warning when STRUCT bitfield syntax is used without the {Spin2_v54} directive to declare intent.
Add error diagnostics for invalid bitfield declarations: bit number exceeds member-type boundary, lower > upper in range form, bitfields on STRUCT-typed members, and nameless members declared with a count or alongside other members.
Changed
Extend the Spin2 formatter to canonicalize [upper .. lower] bitfield ranges to [upper..lower] (no inner spaces) in STRUCT declarations and their continuation lines.
This code formatting is, of course, a high-risk activity, since it is a whitespace-indented language. To mitigate this risk, along with the formatter, I developed a deep regression test system (currently 1900+ tests). This is documented in Formatter Regression Testing. Basically, no matter the elastic tabs or spaces layout chosen, the binary must compile identically after formatting; likewise, formatting the file a 2nd time must produce no further changes.
Special Note: It just makes sense to be careful. Since this is our first release, despite all of the testing I've done, please protect your work on critical projects. Save the binary from your compile, format the file then recompile, if the .bin files are identical then the formatter is working well for your project. If you find any file that fails this test, please let me know immediately, and I'll get fixes in place as soon as we can reproduce the failure.
I've also provided a User Guide for this formatter.
Latest Tool Versions:
pnut-ts v1.54.0
pnut-term-ts v0.9.24
SPECIAL NOTE: We found issues running pnut-ts and pnut-term-ts (and the other compilers/tools as well), and we reported them in our last release announcement. If you haven't updated your user tasks .json file yet, please do so.
NOTE: Please make sure you have pnut-term-ts v0.9.23 or later installed per our installation instructions so that pnut-term-ts is correctly found. Also, verify that VSCode found it by checking the Spin2-specific settings.
Comments
@macca, so after some wandering through alternatives... I'm thinking I leave the doc generator as is (no constants, structs) unless we detect {Spin2_Doc_CON} as the initial line in a CON section; then all constants and structs from that section are documented. This way, one can mark as many or as few sections as needed, no matter where they are in the source file.
How does this sound in terms of simplicity and opt-in behavior?
I'm using Google's agent AI thingy called Antigravity with some success to develop Spin2 code. the desktop interface is essentially VSCode (but pointed at different extension site). I wanted to have syntax highlighting and all the other features of this Spin2 VSCode extension ... which took a bit of hunting to get the .visx direct from the vscode extension server and manually load it into Antigravity. If anyone else is headed this direction, here is the url to get the .visx directly: https://marketplace.visualstudio.com/_apis/public/gallery/publishers/IronSheepProductionsLLC/vsextensions/spin2/2.10.6/vspackage
IT's fun to hear that you got that working.
You might also want to look at P2 Knowledge base MCP. I think Antigravity supports MCPs, so this would give your agent P2 Architecture understanding and a full Spin2/Pasm2 language reference.
I did get that plugged in following the same directions that you have for Claude/Cursor... as a config entry under "mcpServers": {} I generally use Claude Opus 4.6 (thinking) beneath Antigravity.
and I've been using it to build test harness with pnut-term-ts . I have too many tests to fit into one executable (I tried), so now I have separate binary for the 3-tier (HUB/PSRAM/uSDcard -thanks to you) string-interning b-tree database in paged memory, the AST parser, the Eval and Compile stages, the XBYTE Tail-Call Optimized Lisp engine (on, so far, only one COG - ~430 SKIPF packed PASM instructions), the !UNHOLY! 4-color Garbage Collector that binds it all together concurrently from a TASK on a separate COG, the Lisp REPL, 9P host filesystem access, the Octoserialports (again, thank you), the prolog/datalog inference engine... ALL of that as my foundation to, finally, support smooth logical configuration of Smart Pins!
This is my fourth go at it all, in as many months - have implemented all the systems functionally, though feebly, and learned a lot. GO TIME, THIS TIME! working on proving the GC now.
and that takes lots of builds of separate binaries... to speed that up, I kick off parallel builds of ALL the tests (I still have a few Ryzen cores left over) after the source folder is copied as many times to work in... HUGE TIMESAVER, though I still doing the P2 tests serially. maybe I'll get around to parallelizing that, too. I've got a half-dozen or so P2 EDGE 32MB modules on my bench here.
so, yeah, now I'll head over and bump up your Patreon support!. you've made some great tools and foundational libraries that we can count on.
NEWS
I've just released v2.11.0 of our spin2 extension.
Users of VSCode get automatic updates, so you all have these updates already!
Here are highlights of what's new:
This code formatting is, of course, a high-risk activity, since it is a whitespace-indented language. To mitigate this risk, along with the formatter, I developed a deep regression test system (currently 1900+ tests). This is documented in Formatter Regression Testing. Basically, no matter the elastic tabs or spaces layout chosen, the binary must compile identically after formatting; likewise, formatting the file a 2nd time must produce no further changes.
Special Note: It just makes sense to be careful. Since this is our first release, despite all of the testing I've done, please protect your work on critical projects. Save the binary from your compile, format the file then recompile, if the .bin files are identical then the formatter is working well for your project. If you find any file that fails this test, please let me know immediately, and I'll get fixes in place as soon as we can reproduce the failure.
I've also provided a User Guide for this formatter.
Latest Tool Versions:
SPECIAL NOTE: We found issues running pnut-ts and pnut-term-ts (and the other compilers/tools as well), and we reported them in our last release announcement. If you haven't updated your user tasks .json file yet, please do so.
NOTE: Please make sure you have pnut-term-ts v0.9.23 or later installed per our installation instructions so that pnut-term-ts is correctly found. Also, verify that VSCode found it by checking the Spin2-specific settings.
New documents have been added to describe all of our features better. Start with this index VSCode Environment - Reading List
If you see any issues with these new features, please let us know by filing new issues at our code repo. (or email me directly.)
Upcoming: See follow-on work reported in Change Log. Of course, if you find issues between now and then, I'll try to get to fixing them, too!