TwinBasic

[WaynePhillipsEA]

The "single file concept" can later be quite handy, when it comes to the "publishing" of small or midsized Demos...
(only one file to upload to GitHub or Bitbucket, or to "drag into an Email").

In that regard...
Currently there are two files to "manage" a project:
- ProjectName.code-workspace
- ProjectName.twinproj

The *.code-workspace (as a file-ending) is already associated with (VS)Code.exe (containing setting-defs in JSON-format).
Whereas the *.twinproj is not associated with any executable currently...

So, why not ship your VSCode-plugin-binaries with an additional little "TwinStarter.exe",
which after installing the plugin is then already "registered" for the *.twinproj File-endings...

The TwinStarter.exe will then get the chance, to "do a few things with the passed project-file" internally, as e.g.:
- dynamically creating a *.code-workspace-file with the same ProjectName (in case there currently is none in the same folder)
- for that, one could parse out a "leading JSON-header" (instead of the current "binary one")
- and that header should be compatible with the JSON-format which is expected in a "normal *.code-workspace-file"
- to be able to ensure the content of a potentially missing *.code-workspace-file,
- which after that dynamic creation could then be used to start VSCode (indirectly) in turn ...
- simply by calling ShellExecuteW with the *.code-workspace-filepath

So, this new "JSON-header" (instead of the binary header+footer in *.twinproject files),
basically contains the normal JSON-fields which are expected in a *.code-workspace-file,
but also a few "additional JSON-nodes" (as e.g. references to additional "normal *.bas and *.cls files) -
but of course also the informations which formerly sat in the binary header and footer of a *.twinproject.

Ensuring "plain text" in files which contain code - also agrees better with later Repo-Uploads
(to not confuse any "diff-processings" between file-versions).

To conclude - I guess what I was trying to say is - please "empower" the *.twinproject files, making them more universal in:
- not requiring a workspace-file (because the new TwinStarter.exe can ensure that dynamically)
- only containing PlainText in the end (a leading JSON-header instead of the current binary ones)
- codewise keeping their current ability to directly host module- and class-sections as a single-file code-container
- whilst also offering the ability, to act more like a *.vbp (only containing relative references to *.bas and *.cls code-files)

Olaf

Hey Olaf,

Thanks for your thoughts. Ironically, in the early alpha builds we had a single file solution, which was a single code-workspace file that had the project file embedded into a configuration setting BLOB as base64 data (in the JSON file). It worked well for small project files, but it soon became apparent that the code-workspace file wasn't designed to handle large binary data, so we separated out the project file to improve the performance.

I do like your idea, but the problem with using a temporary code-workspace file is that there is potentially no chance to save/propagate changes in the temporary code-workspace file back to the proposed dual-format file. To explain... When VS code informs extensions to cleanup and shutdown, the extensions have very tight restrictions on what they can do, and the time they get to do it in. During testing I noted VSCode extensions get roughly 1 second each to shutdown (sometimes less), and then... poof the extension process is destroyed abruptly -- if you try to save something at that point, you most certainly would end up causing corruption if there's even a small delay. Even executables that are started from the Node.js environment, such as the twinBASIC compiler get terminated abruptly alongside the extension host.

Now it may be that we can come up with a reasonable solution to the above problem, but I'm not convinced it's possible to make it 100% reliable, and that concerns me.

Ideally we'd provide the code-workspace file itself to VSCode via a virtual file system, so that we then get proper control of reading and writing the file. But unfortunately, I had already tried that method early on in development, and VSCode just didn't allow it.

A solution might be to just make the code-workspace file optional, and have a default one created on-demand if you open the twinproj file in VSCode. That way, you can distribute just the twinproj file for simplicity.

The file format for the twinproj file is binary because we allow binary files in the virtual file system, and formats like JSON are not great for binary data. The reason for allowing binary files is because you'll be able to put files (e.g. graphics) into the Resources folder soon, and they will be pushed directly into the built EXE/DLL resources at link time. For source control concerns, we will be offering git integration that works off the virtual file system in-memory, and so the actual binary file format that the project file is stored in won't matter.