Whenever I try to compile code including “Tailored Room Description”, I get a compiler error. I have updated all the extensions, (I think), and downloaded the lasted version of Inform. Here is what I am trying to run:
Include Tailored Room Description by Emily Short.
Room 1 is a room.
That’s it. When I run it I get “Translating the Source - Failed” with error number 10. I’m running Inform for Windows v.6M62, with Tailored Room Description v12 and Room Description Control v12.
I have also tried running the examples given in the included extension documentation and get the same error.
I’m sure that I am doing something stupid but can’t figure out what. Any help would be greatly appreciated. Thank you.
Sorry, I should have included the console output from the compiler fail:
C:\Program Files (x86)\Inform 7\Compilers\ni
-internal “C:\Program Files (x86)\Inform 7\Internal” -project “C:\Users\mom\Documents\Inform\Projects\Sample.inform” -format=ulx
Inform 7 build 6M62 has started.
I’ve now read your source text, which is 13 words long.
I’ve also read Standard Rules by Graham Nelson, which is 42655 words long.
I’ve also read English Language by Graham Nelson, which is 2297 words long.
I’ve also read Tailored Room Description by Emily Short, which is 4815 words long.
I’ve also read Room Description Control by Emily Short, which is 1861 words long.
I’ve also read Complex Listing by Emily Short, which is 3410 words long.
I’ve also read Plurality by Emily Short, which is 2271 words long.
Compiler finished with code 10
When I tried some samples included Far Away by Jon Ingold, the compiler also coughed up a hairball, so I’m apparently an idiot.
Many of the extensions in the Public Library site do not work with 6M62.
You’ll have to look in github.com/i7/extensions , although I don’t know that Tailored Room Description has been updated.
The compiler should not be crashing that way, in any case. But I’m not sure I have the energy to install all the mismatching extensions just to reproduce the crash… sorry.
thank you for the help. So it’s not me making an obvious and stupid mistake? Then I can look through the extension code and see what more I can figure out.
I need to sit down with the new version and my extensions and bring a bunch of stuff up to compatibility. This will not happen for a few days, but I’m aware it’s an issue. (Sorry – I just haven’t had the bandwidth to take care of it yet.)
Last night I happened to be surfing over to the Csound site. (Music/audio freeware, nothing to do with IF.) Among the things they note is that Csound is backward-compatible. Code written for Csound in 1986 will still compile in 2016, and should still produce the same audio output. And Csound code written today should still compile and run perfectly in 2036. Numerous features are now deprecated, but they are never removed from the code base.
To be sure, the Csound community is somewhat larger than the Inform 7 community, which translates to more people working on code development and testing. But what’s really at issue is not the size of the community, it’s the design philosophy itself.
I’m not in a position to understand or critique why Graham has made the decisions he has made about this – I can only comment on the results. The failure of extensions to work under a new release is directly attributable to the design philosophy that underlies I7.
Csound doesn’t expose access to an intermediary language. In other words, I7 first compiles to I6 and then compiles the generated I6 into a Z-code or Glulx story file. At this point the language is stable enough that almost all incompatibilities are caused by extensions including their own I6 code that’s incompatible with how I7 generates its own I6 code. If Csound would first compile into C and also let you write pure C code wherever you want, I can guarantee that they wouldn’t promise full backwards compatibility.
If I7 adapted the view that both the I7 layer and the I6 layer must be 100% backwards compatible from now on, it would practically mean no more releases, ever. It would be impossible change anything with the language if the I7–>I6 compilation step couldn’t be changed.
Does anyone want to jump in and assert that compiling old TADS game code with a newer TADS release does not cause game behavior changes? Or similarly for Hugo, or Adrift, or any other IF system?
I’m going to bet the answer is no.
(By newer release, I mean an update of the part of the system that includes the parser and world model. For Inform 6, that was the library rather the I6 compiler, although the two were updated in parallel anyhow.)
EDIT-ADD: I suppose I’d better state my point clearly: the kind of backwards compatibility you want, Jim, is impossible in a real-world IF design system. It’s nice that you want it, because it’s good to want things, but you’re not going to get it.
Components of the system may work that way. We’ve improved the I6 compiler quite a lot while maintaining backwards compatibility. Same for the Glk API and the Glulx VM. I’ve been careful about those. But the parser and world model cannot be run like that.
Not necessarily - at least one outright bug has been identified already. The failure of a number of extensions to work under a new release also has to do with unexpected bugs. In fact, a lot of the difficulties that I’m reading about has a lot more to do with bugs - I hardly ever see anyone complaining about a feature having been deprecated, because there’s usually a good reason for it to go and there’s a replacement now that makes it better.
Case in point, I guess, “Custom Default Messages” or whatever it was called. It was rendered obsolete, so a number of extensions that used it are obsolete as well, but we got the Response system, which works heaps better.
I’m all for backward compatability - boy, am I ever - but in this particular case it strikes me that I7 is still growing, still developing, still finding better ways to do stuff. And there’s still a fair amount of it that, as I understand, runs purely on legacy and is messy and people don’t really want to try untangling… but they will, at some point, and it’ll cause some more deprecations and changes, but it will amount to a sturdier I7, I’m sure.
As a programmer for 15 years, I rarely saw a software package of any kind that was truly 100% backwards compatible. And while we certainly aimed to design systems that way, in the normal course of events, someone would request something that would cause us to break stuff. A lot of times, too I think you can write code to keep it all nice in the little black box without changing it’s interface but the result is code bloat. Of course, all the above is qualified by the fact that I’m used to traditional languages and very boring applications. It’s also been awhile since I’ve coded professionally.
Four others have already replied to this post, so I kind if feel a bit group-thinkish by writing these words. But after reading the last line, I was sorta expecting a final paragraph explaining WHY the design philosophy that underlies I7 would result in less backward compatibilility.
