Your best bet would probably be the Beta release of Inform App for Linux thread. But one can file bugs against the “Gnome Inform Application” component in the I7 bug tracker (account creation with Atlassian required).
I’m not sure whether a process is in place right now for @ptomato to get notified about it, but one can do it.
thanks for the info, i have created a bug report
when looking through the build log of inform i noticed this error when building kits "Build failed at ‘’/home/silver/aur-packages-git/inform-7-ide/src/inform/inter/Tangled/inter’ -architecture 16 -build-kit ‘inform7/Internal/Inter/BasicInformExtrasKit’, it doesn’t seem to cause the build to fail so i don’t know if this is important?(building on linux, in case that info is needed)
The build (that is, the compilation of Inform compiler) is a thing, but the compilation of a story file is the thing whose REALLY matters.
if the build is successfully (that is, there’s an up-to-date inform/Tangled/inform7 binary) try to compile some story file (the customary lab should suffice)
Best regards from Italy,
dott. Piergiorgio.
I think this issue may now be fixed.
So I was taking a shot at porting Mobile Doors by David Corbett. And it begins
Include (-
with mobile false
with mobile_door nothing nothing nothing nothing
with mobile_door_dir [ loc; loc = location;
if (loc == thedark) loc = real_location;
if (loc == (self.&mobile_door)-->0) return (self.&mobile_door)-->3; return (self.&mobile_door)-->2;
]
with mobile_door_to [ loc; loc = location;
if (loc == thedark) loc = real_location;
if (loc == (self.&mobile_door)-->0) return (self.&mobile_door)-->1; return (self.&mobile_door)-->0;
]
-) when defining a door.
of which v10 thinks:
→ Something went wrong late in compilation, when working through the
‘pipeline’ of code-generation steps. (This should not normally happen
unless your source text is making use of ‘(-’ and ‘-)’ and getting that
wrong, or unless you are experimenting with non-standard pipelines.) The
pipeline looks like so:
1. read
2. parse-insertions
3. resolve-conditional-compilation
4. compile-splats
5. load-binary-kits
6. make-synoptic-module
7. shorten-wiring
Problem: unable to find definitions for the following name(s): mobile,
mobile_door, mobile_door_dir, mobile_door_to
8. detect-indirect-calls
9. make-identifiers-unique
10. reconcile-verbs
11. eliminate-redundant-labels
12. eliminate-redundant-operations
13. optionally-generate text ->
14. generate
15. index
v10 still supports Include (- -) when defining a whatever; it’s still mentioned in WI and used in Rideable Vehicles.
Can anyone think of any way it might be persuaded to take this or a rewritten form of this?
Huh, interesting. Does it no longer support individual properties in I6?
This code is adding some extra properties to each door, without defining those properties beforehand. But that’s a standard practice in I6; on the Z-machine at least, defining a property beforehand makes it a “common property”, and there’s a very limited number of them available.
You could add:
Include (-
Property mobile;
Property mobile_door;
Property mobile_door_dir;
-).
This would make them all common properties. But if there’s any hope of still compiling to the Z-machine, I wouldn’t want to use up three precious common properties for this. (On Glulx I don’t think it matters.)
Thanks – that gets past the error I’d been seeing and brings us to…
→ An internal error has occurred: INVALID node type in Inter tree. The
current sentence is ‘if the player’s command includes “lie”’ (the Standard
Rules, line 2010); the error was detected at line 117 of
“inter/final-module/Chapter 2/Vanilla.w”. This should never happen, and I
am now halting in abject failure.
And so now I’ll report a bug…
On a related note—is there documentation anywhere for what subset of Inform 6 is now supported by the Inter translator? I’m simultaneously impressed by what it supports (Z-machine and Glulx assembly) and then by what it doesn’t (individual properties, apparently). And I can’t find this in the official documentation.
I’ve been noting things as I find them at I7-2102. And I7-2141 is on a related topic of a particular I6 inclusion/I7 invocation label not working together.
v10 has a more restrictive idea of what I6 reserved words are. A couple of extensions had to be modified because they used style as an I6 variable name, which I6 itself is fine with. But I’m not finding documentation anywhere obvious on what I6’s reserved words really are so I don’t know what other differences there are. Does anyone know where there’s a proper I6 reserved words list?
Other than those, I’m not sure anyone knows the answer: I don’t think Graham was adding restrictions on purpose.
Your Property statements alone compile if the rest of the extension is commented out. So something about this extension manages to confuse the parser, but I don’t think we can conclude that v10 doesn’t support individual properties.
The lexer tables in the I6 compiler are definitive.
Inform6/lexer.c at 193e0d9c3d788846c223a24762645a806d2d4dcb · DavidKinder/Inform6 · GitHub
Except not really, because most of those keyword groups are contextual. The opcode groups only apply when parsing an assembly language line. The directive_keywords and trace_keywords groups only apply inside relevant directives. misc_keywords is a mess.
I’d forgotten to mention one: I7 also doesn’t recognize the I6 built-in glk; its use will produce “unable to find definitions for the following name(s): glk”. (I’ve added it to I7-2102 now.)
I had looked at that but I would have naïvely thought it indicated that style was a reserved word, so I realized I didn’t know how to read it.
Having looked into reserved words in I6 further, I feel like I know less. This monstrosity compiles:
Global rfalse;
Global rtrue;
Global style;
Global font;
Global inversion;
Global spaces;
Global read;
Global restore;
Global return;
Global remove;
Global give;
[ Main default do else for if jump move objectloop switch until while
break continue print_ret quit new_line
win;
default = 1;
@setiosys 2 0; ! select Glk I/O system
win = glk($0023, 0, 0, 0, 3, 0); ! glk_window_open
glk($002F, win); ! glk_set_window
print default, "!^";
];
I have a guilty feeling that I come across as the moustache-twirling villain in this part of the thread, but perhaps I could just note that it’s not the intention for the I6-syntax-to-Inter part of the “building” module of “inter” to replicate the Inform 6 language in every detail. I6 is not quite as bad as Perl (about which it is famously said that “only Perl can parse Perl”), but still, it contains some real oddities. To replicate those would end up complicating the I7 compiler for no convincing gain.
In the end, dropping down into I6 to implement things is intended to be a last resort. A better goal is to make I7 more expressive so that people do not need it; I didn’t restrict the use of Include (- … -) to make an ideological point (it had to be restricted in order for the Inter transition to be possible) but, honestly, if a side-effect of these restrictions in 10.1 is that we end up with code more cleanly separating I7 and I6, that’s to my mind a good thing.
Anyway, these oddball I6 issues we’re seeing now mostly arise from old extensions which already needed a small amount of cleanup to work with 10.1, so that cleaning up their use of I6 syntax at the same time doesn’t seem unreasonable. Well - that’s what I think for now, anyway.
As Zed noted, the glk() built-in function is not supported, but there is now a better problem message to cover it than just reporting that no such function exists at linking time.
It’s true that at present we don’t support undeclared properties in I6 inclusions. Daniel’s right that this is potentially a compromise on the Z-machine, if it forces extensions to use up the limited supply of properties available. It might be possible to provide some slightly modified syntax to the Property declaration to declare a property, so that it does work in the world of Inter, but force it to be “individual” in I6 terms. I’m in two minds: depends how much people genuinely need this. In the end, the Z-machine hasn’t been the default target for Inform for quite a long time now, and any project needing multiple complicated extensions is probably going to be Glulx anyway. But do people disagree?
A Property propname individual; directive has been added to the I6 compiler in version 6.36 which does just that (predeclare a property without making it common), so perhaps it’s possible to adopt that syntax.
In the future I’ll be proposing to replace the flex system with Glulx malloc calls (perhaps with a limited compatibility layer for Zmachine, without multiple blocks though). If we could just target Glulx many things would be much simpler.
It would be interesting to think about what it would take to remove almost all uses of I6. Being able to define structs would probably be part of it. Lists that are closer to simple I6 arrays maybe?
I’d be much in favour of moving towards using Glulx malloc calls in place of the current flex code (on Glulx), yes. When this code was originated, it wasn’t quite safe to rely on Glulx memory allocation always being solidly implemented. But now I think it is, and the performance gains could be large.
Other way around:
Property individual propname;
But yes, I hope that helps.
My feeling as a software veteran is that that’s a better goal but we’ll never get there. Not unless we discard I6 entirely from the pipeline and use the C backend (or JS or whatever). And in that case we’ll need a way to drop down into C (JS, etc).
Two I6 parsers means ongoing pressure to converge them. Whether that means updating Inter’s I6 handling or deprecating parts of “classic” I6 will be a case-by-case decision.
I hope “classic” I6 will be maintained well into the future.
Ah! But now that Inform’s “Open Source”, who knows what could happen one wonderful day?
Also, to facilitate Inform reading your mind, maybe you should consider making your mind “Open Source” too?
So Inform can get at the internal workings?
I wouldn’t want Inform or pretty much anyone else reading my mind… 