Any chance of getting this on Windows?
Edit: My bad, I thought this was native code, rather than using Ruby. Guess it pays to RTFM.
If you try it, let me know how it goes. I don’t know any reason it wouldn’t work on Windows – I used File and Pathname join methods throughout, and TTY::Which, which it uses to find executables, is supposed to work on Windows – but I haven’t tried it on anything but Linux.
I failed my saving throw against adding more features. I just pushed a new version.
You can now specify a plain .ni file with compile instead of a project name. In this case, it’ll create a temporary project to compile it and leave the resulting .ulx or .z8 file (if compilation was successful) in the current directory.
There’s a new subcommand, smoketest whose --ext flag you pass an extension filename. It’ll create a temporary project with a storyfile that includes that extension and try to compile it. You’ll either see error messages or the successful compilation output (nothing is saved).
And I fixed a bug: it wasn’t considering extensions when compilation was checking whether auto.inf was up-to-date. Now if story.ni or any extension in the extension project dir has a modification time after auto.inf, it’ll compile. It’s still insensitive to potential changes to the external or internal extension dirs; use the --force flag to compensate as needed.
Another new version pushed.
“smoketest” was renamed just “test”.
If it’s configured, it’ll use a hacked version of @zarf’s i7tohtml.py to pretty print the Inform 7 source code for the story file and Extensions as available through the Project Index. Installing and configuring is a little cumbersome, but is explained in the INSTALL doc.
There’s now a “clean” subcommand to clean up a project’s build and index dirs.
I just pushed version 0.1.6. One big new feature:
You can run setup without an existing Inform 7 installation with:
$ inf7 setup --download
For everyone, this obviates specifying the --internal, --docs, and --resources flags; it downloads an archive and creates/configures them appropriately. If you’re on Linux, it further downloads the CLI package and uses its binaries; you wouldn’t need anything else. Mac and Windows users are on their own to supply ni, inform6, and cBlorb, but at least they don’t have to look up where their Internal, Documentation, and Resources directories are.
Once you get inf7 itself installed (which I need to make easier), there’s now a very easy route to a working Inform 7 development environment for Linux users.
Small changes (including from 0.1.5; I haven’t been posting about every update):
- several improvements to Inform 7 pretty-printing
- it no longer transforms the extension pages in the external dir’s Documentation/Extensions: it just uses its own, which now have Javascript to copy examples to the clipboard
- references to e.g., “next chapter”, “chapter on Activities”, “the chapter on Actions” in documentation are now links (unlike the original)
1 Like
New version, 0.2.0, with several nifty things:
It used to be when you navigated from a Project Index into the docs you lost the navbar. Now the navbar is maintained appropriately and you can get back to the project.
If you configure “browser”, “zterp”, and “gterp” to appropriate executables, when you compile a program then, on failure, it’ll automatically launch the browser with problems.html; on success, it’ll launch the appropriate interpreter. There’s also a play subcommand that will invoke gterp or zterp; mostly of interest to test they’re configured properly.
You’ll be using an independent editor, of course, and dropping to the command-line to compile, but otherwise this offers a similar edit-compile-run/check things in the Project Index/docs development cycle that IDE users get, and access to all the same information barring the skein.
More improvements to Inform 7 pretty-printing and there’s now a ‘pp’ subcommand that will output pretty-printed source code as plain text (and though tables look good in its output, their presence makes the output unusable as source code itself because currently tabs are destroyed) or html (but this is probably less useful because it depends on inf7 css).
Compiling a project no longer checks source code and output modification times – it always tries to compile. It checks only the project’s own extensions to consider reformatting their HTML. By default it skips them if modification time says they don’t need it; --force makes it rewrite all of them. If you want to rewrite the HTML for the External and Internal directories, use the new census subcommand. As with compile, it skips things whose modification times indicate they’re up to date unless you use --force.
The new update subcommand freshly copies the extensions from your .config/inf7/extensions directory to a given project.
The set and settings subcommands can be used without a project. With --init, set lets you update .config/inf/inf7.yml.
I’ve re-styled the Project Index somewhat. Some of the results are better than others; this will need more work.
This will probably be the last update for a while. As the original README noted, the code needs refactoring. I now have a better idea of what I want it to be and want to re-organize some fundamental things.
2 Likes
Just pushed 0.2.1. Changes:
- back-ported the script that generates the the Standard Rules web page; now that’s the same version of the SR inf7 users get (but with local links to documentation)
- pp --html now produces a standalone web page with its CSS in the head and no external dependencies
- setup --download now updates Quixe and Parchment (in external)
- added ‘Definitions’ to the navbar with content per the IDEs
- revised HTML formatting of source; line-numbers via CSS now, so copy-pasting code would work (where tabs aren’t relevant, at least)
- much improved re-styling of the Project Index, all the ugliest bits of previous re-styling fixed
- no longer defaults to $HOME/Inform for your external dir; if none is specified it uses a temp dir every time
- various bugfixes
1 Like
Ruby’s throwing an error when I run inf7 setup: Paste.ee - View paste mwRzX
I’m using Arch Linux, for reference, with Ruby 3.0.0.
Looks like 0.2.1 blew up unless one specified i7tohtml in the setup line (and it’s supposed to be optional).
I just pushed 0.2.2 to fix it. Assuming you didn’t change anything under $HOME/config/inf7/, or aren’t attached to whatever changes you made, please try just:
git pull
rm -rf ~/.config/inf7
rebuild the gem, re-install it, and run your setup again.
That bug was fixed, but now there’s an issue with Ruby attempting to read a Python file during install and compilation.
It works if you run the commands in a Python virtual environment with i7tohtml, so it’s usable – but definitely a bug.
Yeah, that’s pretty awful. Thanks for reporting. Obviously, I did my testing with i7tohtml configured. I suppose I could define it as a requirement and “fix” the bugs! (Not serious.)
Invoking a separate process and introducing a dependency on another language was never ideal. I had imagined I’d just translate the relevant bits from i7tohtml.py, which seemed easy enough… but pygments for ruby just invokes a separate Python process anyway so there didn’t seem to be much advantage. I have a half-written lexer for Rouge, a ruby-native syntax highlighter… but I’ve been focusing on the extension directory testing feature in recent development.
I’ll look into ensuring i7tohtml is really optional this weekend. It’ll probably be easy to fix. If it’s harder than I think (which it might be – the extension-parsing code in the release branch is kind of ugly – the worst of that is cleaned up in dev) I’ll push a doc change noting that i7tohtml is functionally a requirement for now (as a work-around, not a fix).
I haven’t heard back from Verte, but I think this problem really was fixed by my update. The final installation step is placing a script somewhere in your PATH; in describing above how to pull an update and re-run the setup, I failed to mention that one would need to replace the script, too; following those directions as written, they would have still been running the old version.
(Smoother installation and better write-up thereof is coming eventually. I’ve been spending my hacking time using inf7, finally really learning to code in Inform 7 instead of just hacking I7-adjacent projects.)
2 Likes
Any chance this could support .i7xp projects as well as .inform projects?
As far as I understand it, the main difference is that Foo.i7xp/Source/extension.i7x is the source of truth for the extension rather than Foo.materials/Extensions/<author>/Foo.i7x. So at test time, Inf7 would need to copy the former to the latter.
1 Like
Hmmm. It is both the case that:
- I had heard of “extension project” and wondered what it meant and I futzed with the IDE briefly and thought I learned the answer, but it seems like I was entirely wrong
- I’ve been thinking a bunch about how much I’d like actual package management, and a build system that facilitated automated testing
So thanks for the suggestion; I’ll put extension projects on the list.
What I said above is still true: I’ve been using inf7 and hacking I7 code with most of my hacking time.
There has been inf7 development going on, but I’m in the middle of something big and hairy: I wrote my own ruby-native lexer/syntax highlighter with rouge so I could avoid the dependency on the external i7tohtml.py script. And it mostly works, but chasing down the bugs has been hard.
2 Likes
Is it possible to use this with the Flatpak version of the IDE? I believe I found the equivalent of the Internal directory (under /var/lib/flatpak/app/com.inform7.IDE/current/active/files/share/inform7-ide), but I can’t seem to find the Documentation or Resources directories.
Well, it doesn’t work with v10. And I’m not sure anyone other than me ever used it at all. If you’re using 6M62 you could use inf7 setup --download and you wouldn’t need previously existing Documentation or Resources directories.
I don’t know anything about flatpak but I’d presume it must have the Documentation and Resources directories. Try
find /var -type d -name Documentation
find didn’t turn up anything. Which does seem odd, seeing as the flatpak is capable of displaying the documentation.
setup --download works in principle, but a couple of the URLs give 404 now. I opened a pull request with updated URLs.
After that, I found I had to specify --external "$HOME/Inform" as part of the setup invocation, or else I ran into a null string error:
$ inf7 setup --author "Daniel Smith" --download
Importing docs........................................
Writing docs........................................
Created /tmp/d20221204-10006-sw3zzq/d20221204-10006-sw3zzq.inform
/home/rdnlsmith/.local/share/inf7/bin/ni --noprogress --internal /home/rdnlsmith/.local/share/inf7/Internal --external --census
/usr/lib/ruby/3.0.0/open3.rb:221:in `spawn': no implicit conversion of nil into String (TypeError)
from /usr/lib/ruby/3.0.0/open3.rb:221:in `popen_run'
from /usr/lib/ruby/3.0.0/open3.rb:102:in `popen3'
from /usr/lib/ruby/3.0.0/open3.rb:289:in `capture3'
from /home/rdnlsmith/.gems/gems/inf7-0.2.2/lib/inf7/project.rb:157:in `census'
from /home/rdnlsmith/.gems/gems/inf7-0.2.2/lib/inf7/project.rb:86:in `block in census'
from /usr/lib/ruby/3.0.0/tmpdir.rb:96:in `mktmpdir'
from /home/rdnlsmith/.gems/gems/inf7-0.2.2/lib/inf7/project.rb:84:in `census'
from /home/rdnlsmith/.gems/gems/inf7-0.2.2/lib/inf7/conf.rb:139:in `create'
from /home/rdnlsmith/.gems/gems/inf7-0.2.2/bin/inf7:84:in `opt_setup'
from /home/rdnlsmith/.gems/gems/inf7-0.2.2/bin/inf7:44:in `initialize'
from /home/rdnlsmith/.gems/gems/inf7-0.2.2/bin/inf7:317:in `new'
from /home/rdnlsmith/.gems/gems/inf7-0.2.2/bin/inf7:317:in `<main>'
I’d be willing to look into that further, but I don’t have time at the moment.
Do you happen to have a rough idea of what would have to change for it to be compatible with v10? I’d be interested in contributing on this, although I can’t promise more than an hour or two in a typical week.
Ah, yeah, not surprising that some of the links are now broken.
Instead of looking for Documentation and Resources try looking for Rdoc1.html (one of the files that should be in Documentation) and the doc_images directory (a directory that should be under Resources that I think is the only subdir inf7 cares about).
My development version had already diverged a lot from the release version even before v10, most notably 'cause I had gotten around to doing syntax highlighting by lexing within Ruby instead of depending on i7tohtml.
Doing an update to the existing release version to make it compile with v10 instead of 9.3/6M62 wouldn’t be too much work, I’m pretty sure. When v10 came out, I quickly put in an ugly hack to be able to compile either 10.1 or 6M62 for my own use. My aspiration, though, is to provide a decent way to choose among any of 9.1/6L02, 9.2/6L38, 9.3 or 10.1.
But saying “compile with v10” instead of “support v10” above was a very deliberate choice. A huge amount of the value that inf7 offers over, say, the cheesy Perl interface, was that it built a usable version of the Project Index which was appropriately cross-linked with both the docs and syntax-highlighted copies of the source and extensions. And pretty much all of that is massively broken by mostly small, but consequential differences in details. (Also, I now have a completely different way to build the docs, coded in a very ugly fashion, but producing better results: v10 documentation. )
I began writing inf7 when I was still an Inform 7 newbie and just guessing at what I wanted. The documentation processor, smoke tester, and compilation helper/project manager actually began life as separate programs. The whole thing grew by accretion as I thought about new things I wanted and has reached the point of being difficult to modify 'cause even I don’t understand parts anymore. It’s in kind of desperate need of a redesign now that I’m no longer such a newbie and v10 is here.
So I may modify the existing release version to update the dead links and handle v10, but I’m probably not going to sink a lot of time into maintaining this version. And my list of I7-related projects is long, and I’m afraid a redesigned inf7 isn’t near the top of it. 
whoops, v10 doesn’t even have a cap-R Resources directory. doc_images is under resources/Imagery.
I see, fair enough. I’ll probably tinker with it in my own fork then, at least enough for my own purposes; I’ll try not to bug you about any issues I run into, but if you’d like I could let you know if I end up doing anything particularly interesting.