Hyperlink Interface -- Wrong Kind of Value

I started using the “Hyperlink Interface” extension just to see what it does. What it currently does is fail upon compile, with the error: “You wrote ‘carry out the direction hyperlinking activity’, but ‘direction hyperlinking’ has the wrong kind of value: an activity on objects rather than an activity.”

Verbally I think I understand what’s trying to tell me but it’s not clear what to do to fix it. I can certainly ram through the manual and try to figure it out but I’m hoping someone else has run into this and can short-circuit my path.

(Incidentally, for the InformDev team is it a requirement that extensions must at least be able to compile prior to inclusion in the repo? I’m just getting into extensions and this is the first one I’ve tried so now I’m nervous I’m going to be spending time wading through someone else’s bugs. I’m sure I’ll have enough of my own. :slight_smile: )

I was able to solve the immediate problem by commenting out the word “something”:

Direction hyperlinking [something] is an activity.

But at that point I get another error, something to do with printing parser errors. This topic has been poked at in this forum, but I don’t remember offhand how to fix the problem.

This extension antedates the most recent Inform build, and that is the most likely source of the problem. As to whether anyone goes through all of the published extensions before a release in order to figure out whether they’re compatible with a new build – it is very unlikely.

Does anyone even run a new extension when an author submits it? I don’t know. It would be nice to think that that minimal step, at least, is being taken.

The existence of moldy extensions is a weakness of Inform’s open-community model of development. If the IF programming community were 50 times larger, there would probably be volunteers tackling jobs of this sort. You can contact Leonardo and ask him to update the extension, or you can figure out how to edit it so that it works.

Yeah, I found a few things I tried would lead to even more errors.

Actually I thought the examples in the extensions could be used as unit tests. If you write a script that runs all examples in all extensions (or the documentation) for each build, you should be able to catch these things immediately. That way the documentation can serve as its own test.

Yeah, I’ll just figure it out myself. It’ll probably be good experience.

Extensions are checked to see whether they compile before they are posted to the site. Possibly other checks are done as well; I’ve been asked to provide code examples, for instance, and Mark frequently fixes typos in my documentation.

But, like Jim, I don’t think anyone downloads and recompiles all of the extensions for each new build. It would be a nice community service if anyone wanted to provide it. But since the last thing most of us need in our life is more soul-crushingly repetitive busy work, I wouldn’t hold my breath…

On the other hand, there might be some out there who would find it interesting to create a script that could automatically extract the code examples from the extension files and batch them through the compiler. There would be some minor difficulties in that enterprises, I think, but it ought to be doable.


Inform is now, it seems, requiring that variables be defined before use at a level of indentation less than or equal to the point where they’re being used. Thus the extension needs four lines added to the top of the run the hyperlinks routine code:

To run the hyperlinks routine: let mychar be 1; let object-number be a number; let direction-number be a number; let scenery-number be a number; let topic-number be a number;You also need to change two usages of the word “increment” to “increase”, as “increment X by 1” is no longer allowed.

If you do all of that, the extension appears to work as expected. At least, it compiles, and the rather odd-looking but useful prompt appears and functions.

Yeah, that’s what I was talking about regarding unit tests above. (Technically they’d be integration tests.) I’m somewhat surprised that at least some mechanism isn’t in place to do this already given that Inform has opted for an extension based mechanism. Are we sure something like this isn’t already in place, at least to some extent? If it isn’t, I’d be happy to throw something together in Ruby or Python. (I could do Perl but I’d prefer not.)

UPDATE: Thanks, Jim. Just saw your code fix. I’ll give it a shot.

From inform7.com/contribute/extensions/:

And later,

Cool – if it’s done. So a script does exist. I would make this part of the integration of the build process. I assume InformDev is following a relatively standard continuous integration build process? If so, any build tool worth it’s salt could run these tests and even automatically send out email notifications to the relevant parties.

The problem of course is when the person so contacted doesn’t want to fix their extension or can’t be reached. I presume then InformDev must fix the extension themselves? Or is that just left up to the first person who wanders into the problem.

The InformDev process is a bit opaque to me at the moment.

Yes, the Contribute page has long said that. Unfortunately, it doesn’t seem to actually happen. I have authored a number of extensions (the first in 2007 or so, I think), and many of them have been rendered unable to compile by one build or another. But I have never, ever received an email alerting me to that fact. Also, just as important as emailing the author, would be flagging the extension’s blurb on the site to indicate to potential users that it is currently broken. That does not happen either.

I have always assumed that this reference to the script was more of a “we hope to have this functionality by the time it matters” kind of thing.


When I was running the extension library, I did have a script that would run the extension examples and tell me if compilation failed. (Checking to see whether they did what the author intended is another question, and I didn’t always have a way to check that, since it required a second file containing intended output. We did this with all the built-in extensions, but not with external ones.) If I found something, I would either make a minor tweak myself and alert the author that this had been done, or I would email the author. I was also marking up the website to indicate which extensions had been successfully run against which builds.

So it did happen at one time. These days, I know that the extension team (well, mostly Mark Musante) does test every new incoming extension and bounce those that don’t meet certain standards; he’s actually more rigorous about this than I was.

To the best of my knowledge, however, the verification of extensions against new builds has gone by the wayside. I don’t know whether this is down to a lack of tools or simply to the fact that it would be a fair amount of work to do – much larger now that the selection of extensions has grown so much.

In that case, it might be useful to put a note beside each extension giving the last build of Inform the extension is guaranteed to work in.

This is no longer something I control. There are some people who volunteered last year-ish to do an overhaul on the extensions page, which might well include things like this as well as user feedback; I don’t know whether that is coming to anything.

If people are interested in volunteering their services in some respect (and I don’t know enough about the current situation to know whether those services will be useful), the thing to do is to ping the I7 extensions email address and see what response comes back.

Mark has caught more than one dumb thing I nearly published, so I can attest to his diligence as far as manually reading an extension before posting. But I’m not surprised he doesn’t do regression tests for the reasons Em said. (Em, if you have a fancy tool, can you just give it to Mark?)

As for the error itself, the syntax changed to be “activity on numbers” or “activity on colors” or whatever. The “something” is still needed unless the activity is ‘on nothing’.

I believe the perl script I had was passed on with everything else. What I dont know is whether there are reasons why that script is no longer adequate to the task.

Is the script part of a repository? Do you use Git, SVN, Mercurial? If so, we can presumably just grab it and update it ourselves. Personally I’d recommend making this script part of the build process, whether that be continuous integration or whatever you do. I can’t imagine why there would be a lack of desire to make sure all builds still work with extensions. This really is a build process function and not relegated to “maintainers.” I’m starting to get the picture that there is either a very closed development process or it’s not one that’s backed up by a lot of effective build processes of this sort. Given the fact that the IDE, the compiler, and the extensions are separate moving parts, a centralized build process seems almost a necessity. Probably a topic for a different thread, though.

No, there is not a general repository to which the public has access.

I don’t intend to join in a general discussion on the development process. It is indeed not as open as many people would prefer, but it’s how Graham is willing to do this project, and he is the only one in a position to change how development is done. His discussion of this point can be found here:

inform7.com/learn/documents/Janu … cument.txt (under “2b”).

I am sorry this is frustrating to many people, but I don’t run the builds, can’t change the process, and have no insights on the project that I haven’t already shared many times over the years. There are lots of threads on this both here and at rec.arts.int-fiction if you’re interested, but I doubt I could say anything new at this point that would be helpful to anyone.

What I can offer is the occasional suggestion about how to accomplish something specific given the project structure that does exist. In this case, I think the best bet is to contact the extensions maintainers.

You know, communication is also a big time-sink: if the extension maintainers are expected to email all authors when a new build breaks something–recent builds have been very destructive of old code!–well, with more than 200 extensions, that is now a mammoth task. Add to that responsibility the expectation that some seem to have that maintainers should themselves fix extensions if the authors don’t step up to the plate to do so, and–well, that’s a lot to ask an unpaid guy to do in his spare time just for love of the I7 user community. (Thanks again to Mark, Emily, and others for present and past contributions!)

User commenting, as Emily mentioned, has been discussed for the official I7 extension site; this would help immensely with the problem of alerting unsuspecting users to an extension’s compatibility limitations (the major problem I see with the site at present; it’s just too easy for a user to download an extension, try to use it, and find themselves wondering if the extension’s failure to function is their fault, Inform’s fault, or the extension author’s fault.)

Maybe what’s really needed to deal with the problem of broken code that stays broken is a way for users, rather than maintainers, to more easily branch extensions and post the fixes publicly. That way, if Mortimer Q. Procrastinate doesn’t update his extension before I need to use it, I can make the required changes to get it working and post it for others to use. Maybe the IFWiki would be an appropriate place for this kind of activity; in any case, it wouldn’t require much development to get it going.


Which is when developers usually turn to automation. :slight_smile: This is easily solvable given that the extensions mostly have examples that can serve as executable tests. Why not use that? That’s a great feature of Inform, as far as I’m concerned.

I still think a better way is to use the script that allegedly exists, make it part of the build process, and then you know right away if things don’t work with the new build. This is build automation — Development 101. Presumably the main development team knows the changes that are likely to have broken the extension so they could be in a great position to make the required change. Make that a known condition of submitting an extension to the site: i.e., “Your extension may be updated in terms of implementation when code changes to Inform break the logic of your extension. However, nothing will be done to change the intent of your extension.” If you run the build a week before release (for a “beta bake” or equivalent), that gives the authors of extensions a week to respond with updated extensions. If they don’t respond, the InformDev team makes the necessary implementation changes, which should be relatively small for any given release.

Again, this is all Development 101 so I don’t mean to sound like I’m insulting anyone’s intelligence. But this problem is easily solvable. Development teams do this all the time – even on closed development projects.

You must be responding to someone else’s post :wink:. Automation is non-controversial. I was talking about email communication, and none of the extensions have an email field to automate.

Leveraging the extension examples would definitely be a good way to test new builds of Inform. If the extension examples had been used to automatically test the 6Exx build of Inform, for example, the bugs that made it necessary to release 6Fxx immediately afterward would have been caught. But that’s a different issue from actually fixing the extensions, which I’m still not willing to volunteer anyone else’s labor to do. :wink:

I think you’re overly sanguine about the ease of fixing up other people’s extensions, as well as the havoc that a new build can wreak. As just one example, I spent hours fixing just a couple of my extensions due to a simple syntax deprecation in a recent build; this revealed a number of other bugs and…well, it just ballooned into a lot of pretty tiresome work. And there are more than 200 extensions in the library.

What you’re saying is not something anyone here would argue with on the merits, nor do our intelligences have any difficulty grasping it. The problem is that you’re talking about ideal solutions, whereas other folks are taking the whole sociology into account: the development process as it stands, the history of the extension librarian’s duties, and so on. Personally, I’m also doing things like putting myself in the shoes of the guy who signed up to be the extension library maintainer, with my main task being to test and post author’s extensions to the website. Now someone comes along and says that the I should actually maintain not just the library but also everyone’s individual extensions. I think that I might resent that a little…

Anyway, to be honest I think you’re expending energy in the wrong way. As Emily also suggested, you will have more impact if you contact the extension library maintainers and volunteer your services helping out with some aspect of this. Or write to Graham and offer to run the next build on all the extension examples before release and log bug reports as needed.

Personally, I don’t have time to do either of those things, nor would I feel qualified to try to fix everyone’s extensions (Jesse McGrew’s being a good case in point). But I would have time to contribute once in a while to a crowdsourced effort at maintaining abandoned extensions such as the one I suggested in my previous post (which is why I suggested it).


Build process planning would have suggested that this was needed. But, yeah, if that’s not there then currently you couldn’t automate that part.

Agreed. But presumably InformDev kinda thought this problem through when they decided to make Inform an extension-based tool. There are active communities out there – like Eclipse or Firefox – that use plugs-ins and extensions regularly and could be used as a model for how extension maintenance and update is done. These are problems that have already been solved by groups very similar to Inform’s apparent development model. And those are, for the most part, acting with volunteer communities.

Did the “number of other bugs” have anything to do with the syntax deprecation? If not, then that’s a different issue. Existing bugs are not what we’re talking about here. We’re talking about extensions that break solely because of a change to a build. Quality control of the sort you may be referring to is not going to be handled by a build process. That’s up to the person writing the code in the first place.

Fair enough. Although the impression I got from Emily is that the development process was the way it was and there wasn’t a lot of room for input, since she indicated this seemed to be a frustration point for various people. So I’m not sure what the “right way” is to expend energy since it seems like someone new here has to learn all this by asking questions here and getting information piece-meal. I do allow that I might have missed some page or some information, like that little section that Emily referred to. Likewise, if the development process has been a source of frustration and has been discussed before, I’m not sure how someone new is supposed to find that information to know what the right way to expend energy is. I see a lot of references to Graham but when I search, I don’t see that he posts much and so it seems the lead developer may not be participating in these discussions much.

Anyway, I agree. This isn’t the thread to discuss this. I’m not sure where the appropriate place is – but that’s another discussion. :slight_smile: