With Inform updates in the past, I’ve been relatively lucky in that they have yet to utterly break my projects. Sure there were some things that I would have to update and perhaps some extensions that needed fixing, but for the most part they’ve been worth the effort.
I recently installed 6M62, and there were a few things that needed fixing, mostly due to sloppy coding, like sentences ending in a colon now triggering an error.
But my biggest problem now, the inform 7 compiler is crashing. In the I7 console, I’m getting:
> C:\Program Files (x86)\Inform 7\Compilers\ni \
> -rng -internal "C:\Program Files (x86)\Inform 7\Internal" -project "C:\Users\Lautz\Dropbox\Interactive Fiction\WIPs\BeeHive\inform7-hornetsnest\BeeHive.inform" -format=ulx
> Inform 7 build 6M62 has started.
> I've now read your source text, which is 16489 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 Small Kindnesses by Aaron Reed, which is 1801 words long.
> Compiler finished with code 10
When I run it from the command line, I get an unhandled exception in NI.exe…looking in the Event Viewer at the entry generated I see this:
To late to diagnose or try to see if it’s reported already. Project is a large project, so have not tried to break it down yet…not sure I really want to…may just drop back a version.
As an observer I’ve seen many people express a preference for sticking to the version they were using before, at least until their project is finished. This seems to happen every time there’s a new release. Curiously, every release I remember of I7 has been accompanied by these problems, which follow this pattern: they’re not easy to replicate, and they don’t happen to everyone (or the testing team would have found them), but they’re disastrous for those to whom it happens.
Also, zarf said something very telling in response to Draconis’ problems about Scroll Thief (which we all know to be a massive and most impressive piece of I7 programming:
Both of the problems you describe are changes to the parser internals; they may not count as bugs. (…) You may have to find new ways of doing things.
If this is the sort of assistance you’re likely to receive when porting to the new version of I7, I’m not sure you’ll WANT to change versions just yet. Might as well finish your project in the version you know works.
I saw zarf’s reply. As a software developer I can appreciate his comment as there is actually some truth to it, however it’s always good to be conscious of your users and try not to introduce breaking changes unless there is a good reason. The crash I’m getting I’m chalking up to a bug, I’m just not that interested in tracking down the cause at this time. So I think I will drop back to the prior working version.
I’m a glutton for punishement though, so if a new release comes out, I’ll install it and try it out, as I always like new shiny things.
As a non-software developer who nevertheless knows that things don’t keep still and moving forward necessitates changes, I also appreciate it. I’m just not sure how useful or encouraging his comment was, though decidedly accurate.
Of course, what with all these issues, I’m sure a bug-fix release won’t be long in coming. That one will probably work like a charm.
I know you don’t really want to look into this much further, and I appreciate it, but I keep thinking about it. Stupid question - did you try commenting out the Aaron Reed extension? I wouldn’t be surprised that a number of extensions got broken.
Small Kindnesses does work in 6M62, though Remembering doesn’t (I have a version I’m working on updating for that though it still runs into the topic-breaking bug). I do like some features of the new version but the crashes are a bit too frequent; I’ll probably update once the next bug-fix release comes out.
EDIT: I have Disambiguation Control working now also and it can work around most of the changes; if Graham just fixes this [any] problem I’ll be happy.
So I did some more testing and narrowed it down to this. In the code I was using Small Kindnesses by Aaron Reed, but I didn’t want to use the chapter in there on showing valid directions after going nowhere. So to remove that section only I used code like the following:
Chapter - No valid directions showing (in place of Chapter - Show valid directions after going nowhere in Small Kindnesses by Aaron Reed)
I left my new chapter empty and that had always removed that section from the extension.
If I put any code in my new chapter section it would work fine, if I immediately follow it with another Chapter designation, it crashes.
Works fine: Chapter - No valid directions showing (in place of Chapter - Show valid directions after going nowhere in Small Kindnesses by Aaron Reed)
some test pseudo code
Crashes:
Chapter - No valid directions showing (in place of Chapter - Show valid directions after going nowhere in Small Kindnesses by Aaron Reed)
Chapter - My test chapter
I’ve yet to sit down and verify that this is a global problem, with any extension or if it’s specific to Aaron Reeds, but this seems like a bug as I used to be able to do this.
What I want to know is, if you upgrade to a new version of Inform, and you still want to be able to use an older version at times, can you easily do that, or is the new version apt to mess up your ability to use the old one?
There are ways to set it up so there aren’t many technical problems. The big difficulty there is with non-built-in extensions, since they get put in the same place by default. If a new version of an extension is incompatible with an old version of Inform it’s annoying to keep both of them installed.
I had it install to a different program folder, did a git branch afterward, and switch between the “master” and “6m62” branches whenever I want to use that set of projects and extensions.
I downloaded it the first chance I got and had hurrible issues. I loved that I got my jump-arrows back on Mac, but I couldn’t get anything to run. I thought at first it was an extension problem but the game would still not compile after a period of time like there was a memory leak. I had mute compiler crashes like you describe, where there’s no error at all…it just halts. One of my friends had the hypothesis that parenthetical braces in extension sections was responsible and made his extensions work by painfully removing them.
You know, lines like:
Section 4 (Not for use with Locksmith by Emily Short)
Seems like something was done that broke some section handling code, as I’ve seen other similar issues other than @Hanon and mine. My issue was easy enough to work around once I discovered what it was.
I’m actually still using Inform 6G60. When I upgraded to 6L02 a while back, it broke my WiP quite unpleasantly. Stuff that was working before wouldn’t work any longer and I had to spend a heck of a lot of time messing around with my code to get it up and running again, and then even when I’d done that I’d find something else had broke that was working before. I reached the stage where every time I changed something, I’d have to go and change loads of other things before it would compile. After much frustration, I retreated back to 6G60 and - lo and behold! - everything worked fine.
From what I’ve seen of the new features added in subsequent releases, none of it is really stuff I need anyway, so until such time as I literally can’t write my game the way I want to with 6G60, I’m sticking with it.
I agree with @DavidW … 6g60 does what I want. I spent too much time trying to get my IFComp 2015 game to work with 6L* because I figured it was time, or something. It got in the way of creativity.
I don’t need the new features either–and with each new release I see why people who learned Inform 6 still stick with it.
I notice that someone asked on the Intfiction forum as to why the design of Inform 7 leads to such backwards compatibility issues and no one bothered to respond to him. Which was quite telling.
Now I’m no programmer myself and I don’t claim to understand the inner workings of Inform to any great degree, but it seems to me that backwards compatibility should be a very high priority, especially from one release to the next. No one expects everything to work flawlessly all the time, and over the space of many years it’s inevitable that some things will have to be done differently if the program is to evolve, but it seems unfortunate that simply moving from one release to the next breaks so many things.
After struggling to get to the stage with 6G60 where I feel like I know what I’m doing, having to re-learn it all for the next release fills me with a sense of dread. Having to re-learn it all every time an update rolls around makes me reluctant to even download the update.
In short: I feel backwards compatibility should be given a much higher priority than it is.
And there were a few replies that he got that were useful, like Juhana’s.
And personally I didn’t really get the connection between design choices and breaking backwards compatability, mostly because I don’t see what those choices are.
I remember when a bunch of phrases were deprecated - there was a transitional period where both would work, which seems sensible. It didn’t break projects, it just warned them to start switching over to a different way of doing things.
Having said all that… backwards compatability should always be a concern, and your points as a user are darned good ones. What actually bothers me is the attitude of some people: “Yes, things are different. Things always change. Oh, it broke your code? Learn the new one.”
It was actually Spoff’s post I was referring to which was the last one in that thread, specifically:
“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.”
That raises a valid point which I don’t think was properly addressed (or even answered as it is, after all, the last post in the thread). Maybe there’s a very good reason why new releases of Inform break so many things, but like I said above I personally find it pretty disheartening to have to re-learn how to do things each time a new release rolls around.