I7 Development -- Related to Inform 7 Bug Fixing Comments

Authoring Inform 7
1

Having been a developer for more years than I care to count and having worked in the game industry for most of those years, I’ve grown used to looking at how development teams work by how they respond to and fix issues. So a few quotes on recent fixes in Inform (based on comments made for the fixes):

Seriously? This is design criteria for Inform?

Again: really? We’d rather continue to live with something that’s less effective simply because we already have been living with it? In reality, what this means is that you keep living with it and keep developing on top of it, making it that much harder to change later. (Of course, you probably won’t change it – you’ll just “live with it.”)

Nice. I take it this means “The fix that I believe may be correct may now be done, but it’s pretty fiddly, assuming it works.”

Ah. So if you work with a mechanic (turn count) that Inform makes manifestly part of the game, you “deserve what you get”? Interesting. Even if this is inherently true, it’s not necessarily helpful from a developer.

Another great statement about the internals of Inform. (There are actually quite a few comments throughout the Resolved tickets that indicate wording similar in intent to the above, although not quite so boldly stated.)

This was in reference to a series of changes made wherein it was necessary to “modify all of the SR’s ‘deciding whether all includes’ rules.” What this says is: “I’m not sure it was wise – but I did it anyway.” Interesting. That’s exactly how you build foundational issues into your codebase. Yet in another ticket we see this comment:

So: what’s the criteria for saying “I believe this is correct so I won’t change it” versus “I believe this is correct but I changed it anyway?”

There is a perfect example of the danger of letting too many bugs pile up. Stuff starts to get “fixed” as a result of other stuff but you’re not quite sure why or when. There are multiple cases of comments like this in the bug database, where it seems something was somehow fixed (maybe) based on some other work that (might) have been done.

I just thought this was interesting mainly because I like development archaeology: learning about a project by digging through what it leaves behind. These insights, if such they can be called, explain so much to me about Inform, from a development perspective – not a user perspective. (I say that just so the apologists can save their posts telling me “Inform is free” and “I should just be grateful.”) Now to be sure, I’m cherry picking and there are many good instances of comments that explain what is being done and why. But, as anyone who is concerned about development knows, you look for the little tidbits that explain why there might be systemic issues or where a system is hanging onto its past, sometimes to the exclusion of its future.

2

I bet I’ll be the only one who likes this topic, but this was a bit informative.
However, in order to judge how the development on I7 is going, we need to know two things:
First of all, we need to know what issues that these comments relate to - the contexts for the quotes.
Second of all, we need to know the ratio of good fix comments to bad fix comments.

Also, note that gallows humour isn’t uncommon for programmers, because bugs aren’t meant to occur in the first place, so you can only try to fix them to the best of your knowledge, and pray that it won’t surprise you again, but sure enough, there will always be bugs somewhere. Bugs are like an assault on the confidence you have in your abilities, and humour does go a long way to deal with that.

…but yeah, this shed some light on things, however misleading it might be. All I can judge things by myself, is that Zarf seems to be a serious and dedicated man of steel.

3

Thanks. I just comment on and confirm I7 bugs, though – I don’t fix 'em.

I’ve been watching Graham’s bug-fix trail for the past several weeks. (inform7.com/mantis/my_view_page.php, if you’re not familiar with the bug tracker site.) Naturally I’m happy that bugs are getting fixed. I think I’ll leave the subject at that.

4

hey, bukaeya, you could lend a hand to perl development, another language with scary internals to handle the difficult to handle grammar and semantics

it’s scary and there’s no way around it. Things can start out simple and pure, like Scheme, and then escalate into a beast like Common Lisp. that’s life…

that said, what really matters is that all the scary bits are really hidden from the user of the tool. I7 is a godsend in that regard

5

Wrote this before some of the other replies came in, but I guess I’ll post it anyway:

I think discussions about Inform’s development process are important to have, but I notice that a lot of them don’t go anywhere productive. So let me try to aim this thread for a different outcome. (Also, since a lot of this draws on my opinion, and I have some association with the bug tracker, let me be clear I’m just posting as me, and don’t claim to present what anyone else there thinks.)

First, I can sympathize with your frustrations with the I7 development process, as there have definitely been times where I felt I could be helpful were it not for certain process barriers. Or, more to the point of your post, there have been a number of bugs whose resolution I’ve been unsatisfied with, and that I would be willing to work on better patches for if I could. (So far, I’ve just gotten slightly more pestery.)

The most obvious counterpoint to saying so here is, as you know, that a lot of these things are Graham’s calls, and he doesn’t frequent the forum. However, I’m not convinced that nothing can be done from the outside. Let me cherry-pick a few quotes from your cherry-picks:

Here’s a great example. The bug in question is 592, which deals with an unfortunate limitation of the parser. The nice thing about the parser is that it’s almost entirely end-user replaceable (Ron Newcomb’s I7 translation being the most prominent example), and the parts that aren’t (being compiler-generated) have a documented interface. Further, I wrote a parser and disambiguation framework for i7grip that does not exhibit the bug in question. One of my someday projects was going to be to tidy this up for general consumption and splice it into the template layer. My time is split several ways right now, but with someone else to help, I think we could make Alternative Parser.i7x happen. If such an extension were to be widely adopted, I believe it would make a much more compelling argument than any direct objections to the bug resolution or its rationale.

Likewise here. You and I disagree with Graham. But there’s nothing stopping us from distributing a fix. In fact, per an idea of Andreas’s, there is now this extension, which would have a good home for such a patch. If people use the extension, that tells in favor of adopting its tweaks more than counter-comments from a vocal few would.

I would say that the ``horrid’’ refers to the source text not meaning what an English speaker would read it as meaning, which looks to be a consequent of the Inform 7 grammar—Graham is calling it a gotcha, not a bug. The useful thing here, I think, is for us non-Grahams to be an extra set of eyes. As far as I can tell, he was going by the spec in the code, which, in my reading, contradicts WI. So there really is a bug, and the horrid bit can be gotten rid of. Hence my resubmission of the report with clarification.

And let me take another that I was particularly disappointed about, 905. I have a strong opinion that Inform should have a common, conservative policy for resolving ambiguities. Graham, however, has been tackling ambiguity issues piecemeal. I can understand this in the short-term; from reading inweb and digging around ni in a debugger, I must concede that any systematic fix would entail some major design changes and a big internal shakeup. But the concern you voice about cases ``where a system is hanging onto its past, sometimes to the exclusion of its future’’ still applies here. And at first glance, it doesn’t seem like much can be done from the outside where there’s no source access.

Nonetheless, it is possible to at least offer a contribution. If there’s to be a significant redesign, it might as well be piloted in a different ``branch’'. For this purpose, I’m trying out a particular reconception of the source-text parser as part of a smaller, code-highlighting project. Whether or not my code will ever make it into I7, I don’t know. But it will serve a useful purpose (since I would really like highlighting and context-sensitive autocompletion for my editor), and I hope it will be nice for Graham to have the option on the table.

I guess, to sum up, my point is that, while making these observations and talking to Graham is certainly useful, there are additional avenues for change that the community could take better advantage of, and I would love for one of these conversations to help bring that about, instead of going nowhere as they often seem to.

Edit to add: Completely forgot my shout-out to the people who have worked on the built-in extensions, another way that outside contribution has successfully shaped Inform. Though I’m probably not informed enough to list everyone’s names, I know that Erik Temple, Dannii Willis, and Daniel Stelzer have done such coding recently.

6

Actually I will add to this:

The most brittle parts of the parser – the ones that inspire comments in the vein of “I’m afraid to touch this” – are code that has come down from the I6 era. The I7 core parser has barely changed since I6, except that callout hooks have been installed so that I7 activities and rulebooks can influence the course of things.

Ron Newcomb’s replacement is a big step towards improvements there. But if you don’t like that – grab github.com/DavidGriffith/inform6lib and have at it. The I6 parser is still under development. The source is up there. I’m sure David Griffith (frotz) would be happy for the help. Fixes can likely be adopted by I7. And if not, then I6 game authors can still use them.

7

Actually, to know how development is going, you only need to know one thing: Graham has historically waited until the end of a development cycle to fix all of the bugs. Granted, he may have changed how he does things, which is something I have no insight into, but if he’s following past history, the next release is on its way out.

As a retired software developer, I can attest to people having many different ways of doing things; all of which have their good and bad points. I personally prefer to fix things first and then develop on a clean field, with more of an idea where the pain points are, but that’s simply my preference.

8

There are definitely things in Inform that could be improved, and as eu has said, there are ways to suggest improvements practically by writing extensions. One thing I’ve worked on recently is an alternative to the start up rules: github.com/i7/extensions/blob/m … 0Rules.i7x

But I think we need a place for raising these ideas. The uservoice site feels more like a place for feature ‘wishes’, rather than code proposals that are hard to disagree with.