Computercraft support/version?

[m1cr0man]

Hi there! Big fan of this plugin, I've been writing a heap of software for OC in Typescript now. The debugger support is amazing.

I was looking into how hard it would be to support this on Computercraft, given that OC hasn't been updated recently, and I would like to write Typescript for both. I forked your opc-types repo and generated some CC d.ts files, which seem to be working for generating CC-compatible Lua. However, I cannot figure out how tsdbg works. It needs to be converted to use websockets instead of raw sockets, which I can do, but I couldn't figure out what the integration point is with OC that allows tsdbg to actually pause execution? There is no threads library in CC, but I figured it could be emulated with some coroutines and the parallel library.

I was hoping you could explain what changes would be necessary? I can do the work myself, and additionally I would PR them back to this repo so that the extension supports both mods, if you're interested.

[Exeteres]

Thanks for the issue, I am glad that you are interested in this project!

A few words about CC. When I first saw OC, CC was thought to be outdated, so I didn't pay much attention to it. However, I don't mind if this project also gets CC support. I don't think that we can update the names of the extension and these repositories, but we can update the description and tags to indicate that this project also supports CC.

So there are some notes about debugger:

• The current implementation of tsdbg is pretty awful, at least because it is tied to OpenOS. Even within the OC this is not acceptable due to the existence of other operating systems. I think that it is necessary to divide the debugger into several modules - to take out the general logic code and separately the implementation of transport, code execution, and so on, depending on the environment.
• Regarding threads, it is desirable that they represent coroutines. I found it easier to bind debugger threads to OpenOS threads, but that was a mistake. I hope that working with coroutines does not differ in various Lua environments, so there will be no problems with this.
• About code execution and breakpoints. As you may have noticed, there is no support for breakpoints yet. In OC, for security reasons, there are no necessary functions in debug library. I don’t have time to deal with CC, so I’ll ask directly, are there any such restrictions in CC? I know how to stop the execution of the code at a certain place and collect the values of the variables mentioned in the code, and most likely this way of debugging will be preferable, since it will work in all environments. The main disadvantage is that you cannot apply breakpoints without restarting the program.

To summarize, we have a lot to rewrite and there is a lot of opportunities to add new features. But unfortunately I don't have much time to implement all of this. If you will manage to add CC support, I'll try to take the time to review and accept the changes.

[m1cr0man]

Thanks for the detailed reply :)

A few words about CC. When I first saw OC, CC was thought to be outdated, so I didn't pay much attention to it. However, I don't mind if this project also gets CC support. I don't think that we can update the names of the extension and these repositories, but we can update the description and tags to indicate that this project also supports CC.

I too thought CC was outdated/abandoned for a while, hence why I ended up using OC and this lib in the first place, however now the opposite seems to be true. Updating docs should be sufficient if this repo/extension supports both mods.

Regarding threads, it is desirable that they represent coroutines

Ok that's good to hear. Breaking up tsdbg would probably be the best way to do this, I don't think it would be sensible for me to shoehorn in CC support in its current state.

The debug library in CC:T appears to be fully functional, although I am asking on Discord for confirmation. This will be the most difficult part for me. Truth be told, I never used the debug library on its own, and I have not written any extensions for VS Code to date, so I have a lot to learn there, but it should be interesting. I saw a discussion about faking preemption in CC coroutines using the debug library which makes it sound like pausing is not a problem, which should allow for a full debugger implementation.

[Exeteres]

Since CC has full support for the debug library, we should definitely take advantage of this. In OC, you can also unlock this library if you patch some files and in emulators like OCEmu it can be done relatively easily. Thus, we have two environments in which we can get a fully functional debugger: CC and patched OC. But we also need to maintain compatibility with the third environment - unpatched OC, and get the most out of what we can do with the locked debug library. That is why I say that the debugger should be modular.

If you have any ideas or suggestions about this, I will be glad to hear them. As I said, I don’t have time to do it myself, but I will try to help as much as I can.