Version Control and Workbench

[bukayeva]

So as people have pointed out to me, the TADS 3 site says the tool is a programmer’s power tool. As such, that means version control is presumably part of that. I realize there’s no built-in facility in the Workbench but I’m curious if anyone’s had luck with some workflow that involves Workbench and a VC tool. I’m using Git and when I define external tools that call Git, Workbench always tells me: “An error occurred launching the tool program.”

I can’t tell if that means Workbench’s own tool program or the program that my tool is attempting to call.

In some cases, making the call causes Workbench to freeze up and shut down.

At this point, I’m pretty much ready to just avoid the Workbench all together and do everything command line. But I just wanted to see if there were instances of success with incorporating version control into it.

[Jim_Aikin]

I just put my new source in a zip file every day, and drag-copy the zip file. I’m not a real programmer, you see, and have never used version control.

The thing I did want to point out, though – Workbench gives you Watch Expressions and Call Stack windows, automatic recording and playback of previous play-through scripts, and a few other niceties, such as auto-indenting and un-indenting of code. (If you forget a close parenthesis or close bracket, the indentation will be wrong, so you’ll get visual feedback.)

So even if you have to run version control externally rather than through Workbench, I feel it’s still a very useful program.

[bukayeva]

@Jim Aikin

I just put my new source in a zip file every day, and drag-copy the zip file. I’m not a real programmer, you see, and have never used version control.

Essentially right now I’m just heading out to the command line to do my Git stuff, which isn’t that bad. I do agree with your points about the syntax coloring as well as the visual cues that the Workbench provides. Workbench is a nice editor in a lot of ways. I’m not a big fan of the play-through scripts; it feels a little clunky to me. But I’ll fully admit that I’ve only looked at it a bit.

Come to think of it, what I’d really like to do is modify the Workbench so it has an embedded console. (Essentially just a window that has a running instance of your local shell.)

Even more alternative to that: one thing I’ve wished for with Inform 7 is that it adhered to a more plug-in based architecture. (Think Eclipse-like.) I’m finding I’d like that even more with TADS. Then someone could make a Git or Subversion plug-in that could be slotted in. Granted, though, that’s a lot of work.

[George]

@bukayeva

Come to think of it, what I’d really like to do is modify the Workbench so it has an embedded console. (Essentially just a window that has a running instance of your local shell.)

Even more alternative to that: one thing I’ve wished for with Inform 7 is that it adhered to a more plug-in based architecture. (Think Eclipse-like.) I’m finding I’d like that even more with TADS. Then someone could make a Git or Subversion plug-in that could be slotted in. Granted, though, that’s a lot of work.

I’d like a console too, and even more than that an embedded interpreter. Some kind of generalized external tool embed is definitely worth a feature request.

But on the particular subject of git, what exactly are you defining for your tool that gives you the error? I had never tried it before, but I just set up an external tool command for git commit and it worked perfectly.

It would be cool to be able to define a set of external tool commands and then trade that among users…maybe that’s already possible somehow? Worth a feature request if not.

edit: here, I screenshotted my tool window,

[Jim_Aikin]

@bukayeva

I’m not a big fan of the play-through scripts; it feels a little clunky to me. But I’ll fully admit that I’ve only looked at it a bit.

Once you’ve saved your source file, right-clicking a script and choosing Replay does the compilation automatically and then runs the previous session.

For more complex testing scenarios, I use an extension that I don’t believe has ever been uploaded to the archive. It lets you define I7-like “test me” commands to rerun individual command sequences. I use it a LOT. It was created by Ben Cressey and Eric Eve. If I have a spare minute, I’ll upload it this afternoon.

[bukayeva]

I got the Git stuff working, in terms of using it as an external tool. But when I try to assign command keys, I notice I have a series of Ext.Tools.User1 entries even though I only entered one user tool. I then saw the same thing when I added a second for Ext.Tools.User2. I have like ten entries for each.

Another concern I have is that I don’t like that I must have the Git output go to the debug log. Why would external tools automatically have their output go to a debug log? Especially tools that have nothing to do with debugging. That doesn’t make any sense. This is particularly annoying because I can’t clear the debug log, at least so far as I know. If I do a build or a clean, then the debug log clears. But if I do a series of git status, git add, and git commit then I have a huge log. Granted, it’s likely I would do a build before committing anything anyway but I’m thinking the command line is probably better for most of what I’m doing.

Lest it seem like I’m bitching a lot, I actually do like TADS 3 as a language. I think the T3 VM is spectacular. The Workbench sort of has that feel of old style development environment for Microsoft Visual C++. (Remember that thing? Before Visual Studio.) There’s just enough there that I sort of like it but my familiarity with more modern development systems (Komodo, Eclipse, IntelliJ, RubyMine, etc) keeps me from really liking it.

[George]

@bukayeva

I notice I have a series of Ext.Tools.User1 entries even though I only entered one user tool. […]

Another concern I have is that I don’t like that I must have the Git output go to the debug log.

You need to deselect the option that says “capture output to debug window”, and If you have multiple commands I think each need their own user ID.

[bukayeva]

@George

You need to deselect the option that says “capture output to debug window”, and If you have multiple commands I think each need their own user ID.

Yeah, but if I deselect that then I can’t see output anywhere. A console window pops up but disappears. At the very least for Git status, I’d want to see the output. But in general – even with add and commit – I won’t know if everything worked if I don’t see output somewhere.

As for the multiple commands, they do each have their own user ID, but I’m saying that I see about ten each of these:

Ext.Tools.User1
Ext.Tools.User2
Ext.Tools.User3

Meaning, I’ve got thirty entries that match the above “Ext.Tools.User” pattern: ten of User1, ten of User2, ten of User3.

Although, strangely enough, I just went back into Workbench and now my commands list looks like this:

Ext.Tools.User1
Ext.Tools.User1
Ext.Tools.User1
Ext.Tools.User2
Ext.Tools.User3

Why there are now three of User1 I don’t know. But at least it’s not ten of them. As far as the tools I have defined, I only have three:

Git Status (Ext.Tools.User1)
Git Add (Ext.Tools.User2)
Git Commit (Ext.Tools.User3)

It looks like any time I do anything with the External Tools, I get some extra lines in the “Show commands containing” list (under Environment → Keyboard). So what happens is sometimes your shortcut keys don’t get applied to the correct one. The list sometimes “auto cleans” itself (apparently) in which case you might lose the shortcut keys you established.

I don’t know how well this area of the Workbench has been vetted so possibly there are some bugs.

[mjroberts]

@bukayeva

Come to think of it, what I’d really like to do is modify the Workbench so it has an embedded console. (Essentially just a window that has a running instance of your local shell.)

That’s probably not too hard to add.

@bukayeva

Even more alternative to that: one thing I’ve wished for with Inform 7 is that it adhered to a more plug-in based architecture. (Think Eclipse-like.) I’m finding I’d like that even more with TADS. Then someone could make a Git or Subversion plug-in that could be slotted in. Granted, though, that’s a lot of work.

I’d be open to implementing something like that. I’m a fan of plug-in architectures in general - there’s already a plug-in system for text editor modes, which is how the auto-indenter packages work. If you want to look into spec’ing out what a tool plug-in framework would look like, we could see (a) how much work it would be, (b) how many tools it would enable, and (c) what kind of interest there would be in those tools. If it’s a lot of work and only a couple of tools that anyone’s interested in, it might turn out to make more sense to just add one-off support for those specific tools.

[mjroberts]

@bukayeva

Another concern I have is that I don’t like that I must have the Git output go to the debug log. Why would external tools automatically have their output go to a debug log?

Debug Log is probably a bit of a misnomer at this point, since it’s really just a generic tool output window. (The name carries over from the pre-Workbench days, when Workbench was solely a debugger and not an IDE, and that window really did just show debug status messages.)

So if you don’t want the output to go to the Debug/tool output window, where would like it to go?

[mjroberts]

@bukayeva

…but my familiarity with more modern development systems (Komodo, Eclipse, IntelliJ, RubyMine, etc) keeps me from really liking it [Workbench].

One thing I might suggest is that if you have a favorite IDE, you could look into what it would take to build a TADS plug-in for it. I’ve played with Eclipse a little, but not enough to have an opinion on whether it could be a superior replacement for Workbench, and I haven’t looked at any of the others. But given that some of those other IDEs have a lot more developer bandwidth behind them than Workbench does, I could imagine that one of them could eventually do a better job as a TADS IDE.

TADS has a portable C++ debugger API that could be used in such a plug-in (and Workbench uses it exclusively for all of its debugging operations), so the most TADS-specific thing that Workbench does could be replicated. The project-tree manager isn’t in any sort of pluggable form, but at some level that seems like basic IDE fare, so maybe it could be replicated with internal scripting in the IDE or something like that. Pretty much everything else Workbench does involves launching command-line tools and text editing and searching, which I assume would all have to be second-nature to anything calling itself an IDE.

I’m not saying I’m going to be able to implement a third-party IDE plug-in - I’m more suggesting that it would make a good separable project that someone else could take on in parallel.

[mjroberts]

@George

@bukayeva

I’d like a console too, and even more than that an embedded interpreter.

What do you mean by embedded interpreter? I mean, as opposed to the interpreter that’s integrated as it is. Do you just mean in terms of the terp window appearing within the MDI frame?

[George]

Yep, just within the window frame. Normally when I have more than one screen it doesn’t matter, but for example when I just have a laptop it’s more convenient if it’s in the frame.

[bukayeva]

@mjroberts

One thing I might suggest is that if you have a favorite IDE, you could look into what it would take to build a TADS plug-in for it. I’ve played with Eclipse a little, but not enough to have an opinion on whether it could be a superior replacement for Workbench, and I haven’t looked at any of the others.

I did find this: http://sourceforge.net/projects/tadsdev/. I haven’t had much time to look at it yet. I’ll keep looking into this.

[bukayeva]

@mjroberts

So if you don’t want the output to go to the Debug/tool output window, where would like it to go?

Having “tool output” from TADS makes sense as one form of output. Having “tool output” from an external tool (i.e., “different from TADS”) suggests perhaps a Console Output or something. Maybe? Although if there was an embedded console then this would become less of a concern, at least for me.

An embedded console would mean, for example, that I do my git commands right there in the console. The output would thus presumably be right there just as it would at the command line. So I don’t need a separate output window then.

I guess part of deciding whether or not different windows are needed is understanding the use case for external tools. What are the likely external tools that someone is going to use? A diff tool, perhaps? A version control tool, as I am. But what else? Personally I can’t think of much else at the moment I would want to use as an external tool.

[George]

I think you’d want some way to tie external tool commands to keyboard shortcuts in Workbench, even with an embedded console – being able to send external tool output to the embedded console would be neat.

[mjroberts]

@bukayeva

@mjroberts

So if you don’t want the output to go to the Debug/tool output window, where would like it to go?

Having “tool output” from TADS makes sense as one form of output. Having “tool output” from an external tool (i.e., “different from TADS”) suggests perhaps a Console Output or something.

Would it make more sense to have a single Tool/Console Output window, or to have a separate window for each external tool? So you’d have a “Git Output Window”, etc.

[mjroberts]

@George

I think you’d want some way to tie external tool commands to keyboard shortcuts in Workbench, even with an embedded console – being able to send external tool output to the embedded console would be neat.

Note that you can define keyboard shortcuts for external tools. Bring up the Tools > Options dialog, go to the Keyboard page, and type Ext.Tools.User in the “Show commands containing” box. The externals are named kind of opaquely - Ext.Tools.User1, Ext.Tools.User2, etc. But those IDs are actually just the defaults, and you can assign more meaningful names if you wish, using the External Tools page of the same dialog - look for the “Command ID” field. So you could rename the Git tool definition to Ext.Tools.Git, say.

[TheBloke]

I would say that moving to a separate IDE system - i.e. writing a TADS plugin for an existing IDE framework - would be of enormous, and far-reaching benefit.

Workbench is great, and indeed much better than I would have expected a supplied IDE for a niche language to be. Its existence and quality speak volumes for Michael’s dedication and abilities.

But I do feel that work on Workbench is ultimately misplaced. As already stated in this thread, dedicated IDE systems are maintained by teams of dozens or even hundreds, and because those teams are focused on nothing but IDE development, they are naturally able to provide a lot of features that wouldn’t be worth implementing for TADS with only Michael alone to work on it.

Any short-term effort put into developing a TADS plugin for an existing IDE would I believe show enormous long term benefits, because once done the IDE would gain significantly in features, and these would continue to be added to and improved upon over time with little or no further TADS-specific effort.

So I see clear general benefits of such a move. But there’s an even more compelling reason. By extending an existing IDE framework to support TADS, one could instantly - with little if any additional work - open up TADS development to non-Windows platforms.

The IDE that comes first to my mind is Eclipse. Eclipse is very well supported on both Mac OSX and Linux. And it is very extendable, with many niche languages choosing it as the base from which to add support for their specific environment.

I’ve only been investigating writing IF and TADS for a couple of weeks, but in that time I’ve lost count of the number of times I’ve read “TADS would be used much more if there was a Mac IDE”. I believe that’s true, and I also believe that TADS would really benefit from better developer support. It’s an incredible system, a wonderfully powerful language and library, and it really deserves to be used by a lot more people than it is. It dismays me to see on this forum for example, the disparity in number of posts between the Inform sub-forum, and this TADS one. Inform is great I’m sure, but so is TADS, and for many people/purposes, TADS would be a better choice than Inform. But it feels to me, coming in as an outsider, that its growth is presently somewhat stunted, and I think the platform support is definitely a big part of that. Above all, it makes me worry for the future - I worry that there might come a point where Michael loses interest in further developing it due to poor/declining usage. Or that he becomes unable to do so, in which case the smaller the community the less likely others will come forward to pick up the baton.

I talked of investment in an IDE plugin reaping long-term rewards through freeing up time for Michael to then work only on TADS improvements, not Workbench too. This is multiplied when one factors in the long-term benefits of an increased user-base triggered by better multi-platform support. With more users coming in, so there will be more games developed, more forum discussion and Q&A, a greater number of extensions developed, and hopefully more core source contributions to assist Michael.

So Michael, if you do find some time to look at Workbench, I’d put in a strong vote for you to consider not adding more features to it, but rather spending that time extending an existing multi-platform IDE to support TADS, with the aim of discontinuing Workbench once the other platform supports all that it does.

And I’d be glad to try and help if you do - I have some C++ and Java coding experience. I would love to offer to just start the project myself, but realistically I don’t feel confident in starting something like that from scratch, either in terms of ability or in terms of time. But if the project were started and someone could allocate me some sub-tasks, I would definitely put in some hours. And as a Mac user, I’m also well-placed to test multi-platform support. (Presently I use Workbench in a Windows virtual machine in VMWare Fusion - a workaround to the missing Mac support that I would recommend to any other Mac users too, until such time as a native IDE is available.)

Finally, as this is my first post, let me use the opportunity to say thank you Michael for building such a wonderful system - I’ve barely written anything in it yet, but have read a lot (and thanks also to Eric Eve for the documentation), and am blown away by how much you have created; either the language or the library on their own would be fantastic achievements, especially for a single developer: creating both - not to mention an IDE and an interpreter as well! - is simply staggering!

[bcressey]

@TheBloke

So I see clear general benefits of such a move. But there’s an even more compelling reason. By extending an existing IDE framework to support TADS, one could instantly - with little if any additional work - open up TADS development to non-Windows platforms.

The biggest obstacle to TADS development on non-Windows platforms is the myth that you need Workbench to do TADS development.

Posturing aside, I’ve thought about putting together an online IDE using a Cloud9 server modded to run the T3 build tools. Not sure what’s involved but on the surface it seems plausible.