Can't log into bug Jira

Authoring Inform 7
1

I found a bug between Inform 7 (working) and Inform 10 (not working to run the same file). It seems to hand up on Easy Doors by Hanon Ondricek. The error is shown below.

Problem. An internal error has occurred: inter error. The current sentence is ‘An easydoor is usually openable’ ; the error was detected at line 272 of “inter/building-module/Chapter 3/Produce.w”. This should never happen, and I am now halting in abject failure.

What has happened here is that one of the checks Inform carries out internally, to see if it is working properly, has failed. There must be a bug in this copy of Inform. It may be worth checking whether you have the current, up-to-date version. If so, please report this problem via Bugs | Inform 7.

As for fixing your source text to avoid this bug, the last thing you changed is probably the cause, if there is a simple cause. Your source text might in fact be wrong, and the problem might be occurring because Inform has failed to find a good way to say so. But even if your source text looks correct, there are probably rephrasings which would achieve the same effect.

When I try to report this to the Jira bug database, it does not send my email address for verification.
P.S. I have run Inform 10 successsfully on small items since download, but the first time I ran my larger file, using the Extension Open Doors, it popped out this error.

1 Like
2

I’ve heard lots of people complain about Jira, unfortunately – not sure if this is an issue or just the thing running slow.

I did just try compiling a game with Easy Doors (v 3.2) included and didn’t get this error, so I don’t think the extension is at fault – hopefully wiser heads might have some clue about what the issue might be.

2 Likes
3

I get the same error, which seems to be due to a line in that version of Easy Doors (3/160425), just before the cited “current sentence”, although I don’t know what the underlying cause is.

In fact, a similar error can be produced in Inform 10 without Easy Doors, just by this source:

The Lab is a room.

The widget is a thing in the lab.
The widget can be unopenable.

[this doesn't work, either:
The widget can be unopenable or openable.]

[whereas this works: 
The widget can be openable or unopenable.]

The momentary fix is to install the newest version of Easy Doors (3.2), which works, as Mike notes. The difference between the versions is that the line “An easydoor can be unopenable or openable.” was changed to “An easydoor can be openable or unopenable.”.

5 Likes
4

I see the updated version of Easy Doors in github, and I signed on. However, I don’t know how to download it into my Extensions on Inform. I go to Extensions->Public Library-> and click on the “Update 28 Extensions” button and nothing happens. Last time I installed Easy Doors I downloaded to my computer and moved it manually. I prefer that Inform does the download. What should I do?

5

I believe the Public Library has been nonfunctional for a while? Anyway I’d just download and move it manually, even if it is more of an annoyance.

1 Like
6

Yes, what Mike said.

The public library is connected to somewhere else (used to be Index of /pl/payloads, don’t know if that’s still the case), not to the Github repository.

You shouldn’t necessarily need to move the file manually, as in “finding out the correct folder” or something like that; you can download it using a browser and then install it from the IDE, which will move (well, copy) it for you.

On the extension’s github page, click on the “Raw” button, which will give you the raw extension text file: https://raw.githubusercontent.com/i7/extensions/10.1/Hanon%20Ondricek/Easy%20Doors-v3.i7x

Save that file with an .i7x ending to a location on your computer.

In the IDE, open the menu “File → Install Extension…” and choose the downloaded file. (That’s how it works in the Windows IDE, I hope it’s the same on Mac.)

1 Like
7

I did something similar and I think the updated version is now installed. It shows version 3.0xxx in the header.

8

I’m fairly sure it should show version 3.2, which is the current version; whereas 3.0.160425 is the old version with the bug which we wanted to avoid.

You might want to try out the examples which are included in the extension’s documentation, to see whether everything’s working.

9

Sorry. My fault. I forgot to “Include version 3.2 of Easy Doors by Hanon Ondricek” (without parens) in my story file. The installed extension does show version 3.2.

10

Well, now I still get the same error, but it is on one of my lines of code–code that worked before. Is this a problem with Inform 10?

11

Can you give a small example of code which results in the error, so we can try to track it down? Ideally, just the lines which include the extensions you are using, plus a room definition, and the minimal amount of code necessary to reproduce the problem.

1 Like
12

In my file I have:

Fence is a kind of door. Fence is closed. Fence is not openable. 
Fence is either opaque or transparent. It is transparent.
Description of the fence is "A rock wall at the base of vertical wrought iron bars. The wall is four feet high; the bars are another five feet above that, tipped by pointy barbs."
Understand "fence" or "rock wall" or "wall" or "bars" or "iron bars" as fence.

The error points to the second line: “It is transparent”. This was working fine with the old version of Easy Doors. Perhaps that extensions also uses ‘transparent’?

13

It seems to be a bug in Inform 10, unrelated to the extension. (Except that the previous version of the extension triggered this bug or a similar one, as we saw above.)

This minimal source, without the extension, also results in an internal error:

The Lab is a room.

A door is either opaque or transparent.

[this results in an error, too:]
[A door can be opaque.]

The error, just for reference, seems to be practically the same as the one in the first post:

“An internal error has occurred: inter error. The current sentence is ‘An object is usually improper-named’ ; the error was detected at line 272 of “inter/building-module/Chapter 3/Produce.w”. This should never happen, and I am now halting in abject failure.”

In contrast to that, the following, where we just switched the order of “transparent” and “opaque”, compiles:

The Lab is a room.

A door is either transparent or opaque.

[this compiles, too:]
[A door can be transparent.]

I don’t really know what’s going on there. It looks somehow as if the built-in “negatives” cause trouble: “A thing can be unopenable.” results in the internal error, whereas “A thing can be openable.” compiles.

So, one immediate fix would be to change the order in your source code:
Change “Fence is either opaque or transparent. It is transparent.” to
“A fence is either transparent or opaque. It is usually transparent.”

14

Do you really want fence to be a kind of door? It looks like you want the fence to be a specific object, in which case you should start by saying “Fence is a door.”

1 Like
15

It looks as if someone already reported the internal error, but without a code example to reproduce it, as far as I see.

I added the examples from above to the report at Jira issue I7-2284.

1 Like
16

StJohnLimbo,
Thanks. I will give this a try. I will respond whether it works or not. (I suspect that there may
be multiple lines in my code that can trigger this.)
-abc

“I fear for my country when I reflect that God is just.”
– T.E. Lawrence (Lawrence of Arabia)

| StJohnLimbo IFComp 2020 Participant
February 6 |

  • | - |

It seems to be a bug in Inform 10, unrelated to the extension. (Except that the previous version of the extension triggered this bug or a similar one, as we saw above.)

This minimal source, without the extension, also results in an internal error:

The Lab is a room.

A door is either opaque or transparent.

[this results in an error, too:]
[A door can be opaque.]

The error, just for reference, seems to be practically the same as the one in the first post:

“An internal error has occurred: inter error. The current sentence is ‘An object is usually improper-named’ ; the error was detected at line 272 of “inter/building-module/Chapter 3/Produce.w”. This should never happen, and I am now halting in abject failure.”

In contrast to that, the following, where we just switched the order of “transparent” and “opaque”, compiles:

The Lab is a room.

A door is either transparent or opaque.

[this compiles, too:]
[A door can be transparent.]

I don’t really know what’s going on there. It looks somehow as if the built-in “negatives” cause trouble: “A thing can be unopenable.” results in the internal error, whereas “A thing can be openable.” compiles.

So, one immediate fix would be to change the order in your source code:
Change “Fence is either opaque or transparent. It is transparent.” to
“A fence is either transparent or opaque. It is usually transparent.”

17

Andrew,
Yes, perhaps fence does not need to be a kind. I do need the fence in multiple adjoining (outside) rooms.
I will give that a try and let you know what happens.
Thanks.
-abc

“I fear for my country when I reflect that God is just.”
– T.E. Lawrence (Lawrence of Arabia)

18

StJohnLimbo,
Thank you very much.
-abc

“I fear for my country when I reflect that God is just.”
– T.E. Lawrence (Lawrence of Arabia)

19

If that’s the case, the best thing to do might be to make it a backdrop rather than mess about with multiple instances of a kind.

20

I tried a backdrop first, but I want the player to see through the fence into the areas beyond. I couldn’t get that effect with a backdrop–but then I am muddled when it comes to Inform.