Making it easier to build and debug on VS Code.

[ciscoheat]

To make it easier to debug and build in VS Code. Makes it possible to debug just by pressing F5, and build with gradle using Ctrl+Shift+B.

[mbrowne]

What was the concern again about merging this one? I thought the issue was not wanting to prioritize VS Code in the readme as if it were the primary IDE to be supported. But simply including these files to make it easier for those who are already using VS Code doesn't preclude the usage of other IDEs or potentially adding other integration files for other IDEs in the future.

[jcoplien]

Remember that the goal of the trygve project was to explore what a DCI virtual machine should look like, as well as to do a bit of language exploration. The program is good enough (I build things thoroughly and with care) that you may be deceived into believing that it is a production environment. It is a throwaway research environment whose interface is good enough to be quite usable to explore ideas. My design goals with this project, as with most things I build, emphasize minimalism and portability. That’s why it is written in Java: there certainly is no other excuse to use such an impoverished and messed-up platform for research. Such minimalism includes being agnostic about things like local platform add-ons such as VS Code, or a database manager, or maybe even a web interface. The latter inevitably entails getting into platform-specific APIs, particularly for the browser flavor of the month, and security concerns. This delta, and other changes that were discussed in the same ilk, solve a different problem. I know it is small, but it is an exception. What is the use case for dealing with VS Code-specific inputs in a non-VS code environment? How does one portably detect whether VS code is present? The broader vision of including VS code was at a scope that replaced the current text editor with the native VS code editor. I could maybe see the case for convenience and productivity, but suspect that the benefit would be small. No one even ever tried to make the case that having a nice interface would expand the experimental population or encourage more aggressive exploration of ideas, and I seriously doubt that they could have made that case had they tried. Further, these bells and whistles don’t support the primary charter, which is research into the virtual machine (and, to some degree, feasibility of implementing a clean DCI type model in a Neanderthal language). It weakens the conceptual integrity of the whole. I went the full measure of installing VS Code on my Mac to try out such changes. and I’ll tell you, I wouldn’t wish that on anyone. It’s probably a couple hundred megabytes of disk space that touches far too much native stuff. I *still* haven’t figured out how safely to undo the mess. Most importantly, doing such things properly is a lot more work than meets the eye. The current editor and interface are fairly tightly integrated for highlighting text on incremental search. The debugger is extremely integrated with highlighting (at a finer granularity than source lines) on breakpoints and stepping, or of visualizing which lines have breakpoints associated with them (as in the existing version). To accommodate wishes such as, for example, being able to use the VS Code editor or window manager begs a design with more explicit separation of concerns. For example, the architecture currently has no API for a given window of a given screen that says, in a general way, highlight the text in line L of this window between columns I1 and I2 to platform-independent color C. One could create such an API as a proxy or bridge to any one of a number of concrete objects of platform-specific classes that would be built at run time according to the environment. That requires a different architecture. Going beyond minimalism always opens a can of worms. Should the design be flexible enough to support the X protocol and not just the native Window stuff that Oracle supports? Should it support dumb terminals (this has usually been a requirement of past such projects I have done)? Should it also support right-to-left natural languages like Hebrew? Should it allow end-user parameterization of fonts and font sizes? Should it be UNICODE-friendly? There are a million users (and programmers) with a million feature ideas. We want carefully to consider what value we want to generated and head in that direction. VS Code compatibility didn’t cut it. And pulling in this and that from different vendors messes up one’s release train, becasse you need a new release any time any of the components changes. It was bad enough when the JVM needed to be upgraded (in spite of the fact that I chose Java because it was a stable, portable API unlike, say, Swift, which wasn’t even stable as a language) or antlr (yes, they re-did the syntax of grammar files): I don’t need more of these. I don’t remember if it was this change or another one in the same batch but when I tested it, it simply didn’t work (or introduced another bug or something). No tests accompanied the change. To put it simply, the quality was low. I appreciated the enthusiasm on the part of the contributor but I felt that it was a solo effort that had not been properly socialized with the user community (or with me as “Product Owner”), that had no support from user community demand, and that was much less important to the project scope and charter than these proposals were. I wanted to stop the creeping featurism before it became a cancer. If someone wants to build research branches to explore, for example, assign-once semantics, or JVM bytecode generation (exploring integration with non-DCI libraries), I think that would be great. They can build a community around those — or try. If someone wants to take a copy of the code base in the direction of a production environment more focused on programmer convenience and productivity, folks are more than welcome to do that do, as long as the effort credits the original. As it stands, trygve on GitHub is a nice, minimalist, research base. (Even as a minimalist thing, I’d guess that it’s still 60,000 lines of code.) Nothing would please me more than to see an increasingly production-centric version — but that is a different product, with a different architecture, and much different engineering.

…

On Feb 13, 2024, at 04:26, Matt Browne ***@***.***> wrote: What was the concern again about merging this one? I thought the issue was not wanting to prioritize VS Code in the readme as if it were the primary IDE to be supported. But simply including these files to make it easier for those who are already using VS Code doesn't preclude the usage of other IDEs or potentially adding other integration files for other IDEs in the future. — Reply to this email directly, view it on GitHub <#126 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABXABKVWF5ZRGC6S6FG2CDDYTLMOPAVCNFSM6AAAAAAQVX557GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNBQGM3DKMBZGI>. You are receiving this because you are subscribed to this thread.

[mbrowne]

Hi Cope, thanks for the explanation. I realize that this is a research language not meant for production. I just want to make sure we're talking about the same thing...I looked at this PR, and literally all it does is give you this task menu (which can be activated with default VS Code keyboard shortcuts)—mainly useful for those who already happen to be using VS Code.

There is no need to detect if VS Code is present; if it's not being used, then the entire .vscode folder will simply be ignored. And I think this could potentially be useful for a large number of users—almost all the frontend web developers I know use VS Code now as their preferred IDE, and a lot of backend devs use it too. I would say though that it would mainly be useful to those who are interested in building the entire trygve project from source and perhaps tinkering with the source. For just running trygve code, I would agree that the built-in GUI is sufficient for research purposes.

So in summary, I understand what you're saying about their not being some huge advantage to including this PR, but I don't really follow what you're saying about the downsides. There seems to be little downside in including a feature that will be useful for some, and for the everyone else they will simply be unaware that it's there and it won't affect them at all.