Some parts of API undocumented - ok to use?

[mkcms]

For my Emacs client, I recently started implementing documentation-on-hover for ASM opcodes. I found the API that the browser version uses to fetch that documentation by tracing the requests in my browser.

The /asm/<instructionSet>/<opcode> API looks public and simple, but I couldn't find any documentation in docs/API.md for it. Can you confirm if it is ok to use? Can you document it?

Also, I have a question for the examples API (/source/builtin/*): do you plan on making that part of the main API anytime soon?

[mattgodbolt]

Hi! The api/asm should be good to use! We should update the docs (we'd welcome a PR from you if you are close by to do it!)

The source stuff is not under API as really it wasn't planned on being part of the api; but we can move it. and it hasn't changed in literally years. what do you use under that route, just for my edification?

[mkcms]

The api/asm should be good to use! We should update the docs

Great, I opened #6339

The source stuff is not under API as really it wasn't planned on being part of the api; but we can move it

So can I use it as is, or should I wait until it is moved to the /api prefix?

what do you use under that route, just for my edification?

I want to use the list of examples (/source/builtin/list), and to fetch specific examples (/source/builtin/load/<lang>/<file>)

[mattgodbolt]

I think it's safe to use them now. They've been there for ... 12 years ... and we haven't moved them yet (!) so...they're probably OK. I can't promise they will stay forever though.

[mkcms]

Ok then, thanks for clarifying that.

[junlarsen]

For what it's worth, the code to generate the data that's served under the asm/<insn>/<opcode> endpoint is available to run for yourself in https://github.com/compiler-explorer/compiler-explorer/tree/main/etc/scripts/docenizers if you'd like to avoid the network request

[mkcms]

Thanks for the link, but I don't want my users to to run anything other than elisp code. I guess I could generate the data and store it in the repo, but I don't want such maintenance burden.