@ptomato, perhaps it makes sense to start a new thread for beta testing feedback on the gtk3 version?
1 Like
Sooooo, Philip, you have convinced me to be more mad at you. 
Iām more than slightly annoyed that the gtk3 branch comes with NO INSTRUCTIONS on how to build it. Zed Lopez presented some perfectly reasonable instructions, but I have no idea how I would ever have figured that out. What packages to install is one thing (which should be in a README). But figuring out the existence of, or the invocation scheme for, the meson build system, when it isnāt even mentioned anywhere is completely impossible, and absolutely needs to be in a README.
Whatās irritated me most from Graham Nelson is specifically the failure to document the command-line invocation of ni. (The lack of a reference manual ā Writing With Inform isnāt a reference manual ā is also annoying. So is the lack of build instructions for Inform 6.)
This is a similar type of failure to document, only worse. I mean, how in hell would I know to type āpip install meson=0.55.0 ninjaā ?!?
This is the sort of thing where I update the README, HOWTO, or INSTALL file as I do development. If I donāt document as I go, I canāt remember how to build my own project a few weeks later, which is probably why my programming is always documented far better than some peopleās. But it really doesnāt do to have āguess how to build thisā as the only build instructions. It is maddening. āmakeā is standard enough to be manageable, but anything more complicated than that requires compilation instructions.
Iām trying Zedās instructions now. They should be in a README file on the gtk3 branch.
(BTW, it has to be āpip install meson==0.55.0 ninjaā ā double equals sign)
So the biggest thing you need to fix is that LD_LIBRARY_PATH issue; thatās a pain. You want to set an appropriate rpath during compilation and/or installation:
And itās running. Seems to be working. However, as soon as I attempted to open an extension, it crashed. And now it crashes every time I try to open everything, with this error:
(gnome-inform7:927173): GLib-GIO-ERROR **: 15:47:17.354: g_menu_item_set_detailed_action: Detailed action name 'app.open-recent(('file:///home/neroden/Inform/Extensions/Nathanael%20Nerode/Nathanael's%20Extension%20Style%20Guide.txt','inform7_extension'))' has invalid format: 70:expected ',' after first tuple element
Trace/breakpoint trap
Apparently it corrupted the file .share/recently-used.xbel, which I had to delete to get gnome-inform7 to load anything without crashing.
Given that editing extensions (and then testing them by running a test game which uses them) is my primary workflow, if you could get that working, I might actually use the IDE instead of sticking with the command-line process.
Also, it would be good to document things like the way the program pokes at .share/recently-used.xbel, since it took me quite a while to figure out what file I had to nuke to get it loading again.
Darn it. Thanks, fixed. In the original, the version numberās in a variable and I guess I got carried away deleting stuff from that line. 
This weekend Iāll check the package list to try to ensure thereās nothing superfluous and draft an INSTALL.md for the gtk3 branch to send to @ptomato in a pull request.
1 Like
Further investigation:
- click-copying examples from extension documentation does not work. Copy-pasting is not a substitute. Although copy-pasting does correctly remove the first leading tabs, it destroys the later tabs and turns them into spaces, which breaks programs using the colon-and-indentation style, which makes it fail to compile. This is a major piece of workflow when learning Inform, frankly one of the few advantages the IDE has over the command line, and should be fixed.
- the āup arrowā from an extensionās documentation leads to the top documentation page which links down to Writing With Inform/Inform Recipe Book, which doesnāt include the extensions lists; IMO, this is clearly incorrect, and it should go to the extensions list. Dunno whether this one is on you or Graham.
- the āi in a circleā from extension documentation leads to a malformed URI with too many slashes (āCould not locate real filename for URI inform:///Extensions/Extensions.html. There may be a bug in the HTML generated by Inform.ā)
- Worse, because āExtensionsā caches the most recent Extensions documentation you looked at, once you have looked at the documentation for one extension, you can never see the list of extensions or look at other extension documentation again ā since both āback to topā mechanisms are broken. This is severe.
- Source, Result, Index, Skein, Transcript, and Story seem to be working fine.
- One feature request. The fonts in Index, Documentation, Extensions, Results, and Transcript are miniscule. While I can enlarge Index/Documentation/Extensions/Results with Preferences, then it also enlarges the text in the editor, which is then too large. And it doesnāt enlarge the transcript text at all. Is there any way to make them all the same size as the text in the editor? Or, alternatively, to allow them to be adjusted separately? In addition, I can change the editor to white-on-black, but it doesnāt do the same for the Documentation, Extensions list, etc.
- Similarly, the Story shows up with text of non-adjustable font sizes; though this is less important, it would be extremely useful to be able to adjust them.
- In the Preferences window in the list of Extensions, they should be called āInform 7 Extensionsā, not āNatural Inform Extensionsā.
- The Public Library is more or less obsolete and authors should be discouraged from using it and pointed to the various git repositories, IMO.
- gnome-inform7 spews these two errors at the command line prompt:
(gnome-inform7:928077): Gtk-WARNING **: 16:25:38.572: Unknown tag 'indent-1'
(gnome-inform7:928077): Gtk-WARNING **: 16:25:38.572: Unknown tag 'indent-2'
-
On relaunch, or on opening a new game file, font size preferences are not respected. Have to go in and change them again on each launch. Although I would prefer it if the editing window and the Index/Documentation/Skein window either had the same font size, or could have font sizes set independently, I could tolerate it if it would remember my āMediumā font size setting; when I go into Preferences, it claims that itās set to Medium, but it hasnāt been applied; I have to switch back out of it and back into it every time.
-
I strongly suggest that āNew Extensionā should include the
---- DOCUMENTATION ----line in its template. -
The main āOpen Projectā window wonāt open extensions. As noted previously, āOpen Extensionā crashed and corrupted the recent file list ā though itās working now, for unknown reasons. But also, itāll only find extensions which are installed. Sometimes I have good reason to edit an extension which is stashed somewhere else, and sometimes the list of extensions hasnāt updated in the menu. There should be a way to āOpen Extension by Filenameā to open an arbitrary .i7x file for editing ā this looks easy to implementā¦
ā¦so this seems like a long list, but I honestly think most of it should be pretty small fixes (though maybe not the clickpasting). Iām not very experienced with graphics toolkit work so Iām not volunteering to fix most of them at this time.
A few more:
-
āSuggest a Featureā¦ā and āReport a Bugā¦ā under the āHelpā menu both lead to dead webpages. Probably best to remove them at this time, or to pop up a fixed window with some text suggesting more useful locations.
-
Help->About->Credits->License says on āSee Help->License for licensing informationā, which is clearly incorrect since there is no such menu item.
-
When quitting, and closing an extension, a blank window comes up instead of ādo you want to save changes?ā, and then freezes and has to be force-terminated.
-
In keeping with a suggestion I have now made in three other places, Inform 6 should be compiled and linked with the -flto option for link time optimization (which works under both gcc and clang and has been supported for 10 years). It runs twice as fast, which is a big deal.
-
I already tried adding it to the meson.build options for cflags, but it also has to be added to the linker flags (which did not happen automatically) and I have no idea how to do that with meson, which is a marvellously cryptic build system. I have not yet tried doing so with the gnome-inform7 program because itās not obvious where to add the option at all, but I betcha itāll speed it up and work tooā¦
Mostly the handling of extension editing in gnome-inform7 needs to be brought up to par with story editing. Itās much simpler, but itās just not fully implemented, with all these crashes on opening and closing files and not being able to paste examples from extensions. Until it is, the command line will be easier to work with. This really shouldnāt be that hard, so I guess I have good reason to be mad at you, Philip?
Dear god. Every time you go back to compile again, you have to run
$ virtualenv --python=python3 meson
$ source meson/bin/activate
$ pip install meson==0.55.0 ninja
before you can run āmeson compileā. Can I avoid this if I install mason and ninja-build in aptitude?
[I continue to believe that almost every build system after the Makefile was created because most programmers donāt understand Prolog, and they are all inferior. Ninja might be an exception, since it looks like it was written by people who understand Prolog. Meson is not an exception, being a āslow, complicated, and difficult to use interfaceā, to correct its creatorās description of it.]
You need the
source meson/bin/activate
one per shell session, but you donāt need to repeat the other steps. (Well, unless you delete the meson directory ā then youād have to start over ā but there isnāt a reason to do that unless you really need that disk space.)
The meson package you get from Debian Buster was too old a version, 0.49.2. gnome-inform7 requires meson >= 0.55.0 in its meson.build. Thatās why I had the virtualenv bit. It looks like anyone on Debian Bullseye (or Sid) or Ubuntu 20.10 (or 21.04) could just apt install meson.
Thanks ā I might not have thought to spell this out in my forthcoming INSTALL.md if you hadnāt brought it up.
I managed to poke at src/inform6/meson.build enough to get it to do link-time optimization, despite being unable to find any documentation explaining how to pass arguments. (Apparently it previously wasnāt compiled with any optimization?) This cuts the Inform 6 time on Counterfeit Monkey in half, so itās worth it. Patch here:
--- meson.build 2021-04-02 18:30:25.265046341 -0400
+++ meson.build.new 2021-04-02 18:30:19.536966090 -0400
@@ -1,12 +1,12 @@
inform6_extraflags = cc.get_supported_arguments(['-Wno-format-overflow',
'-Wno-unused', '-Wno-maybe-uninitialized', '-Wno-misleading-indentation',
- '-Wno-implicit-function-declaration'])
+ '-Wno-implicit-function-declaration', '-flto', '-O2'])
executable('inform6', 'arrays.c', 'asm.c', 'bpatch.c', 'chars.c', 'directs.c',
'errors.c', 'expressc.c', 'expressp.c', 'files.c', 'inform.c', 'lexer.c',
'linker.c', 'memory.c', 'objects.c', 'states.c', 'symbols.c', 'syntax.c',
'tables.c', 'text.c', 'veneer.c', 'verbs.c',
- c_args: ['-ansi', '-DLINUX', inform6_extraflags],
+ c_args: ['-ansi', '-DLINUX', inform6_extraflags], link_args: ['-flto', '-O2'],
install: true, install_dir: pkglibexecdir)
install_data('readme.txt', 'licence.txt', 'DebugFileFormat.txt',
And I think I have it working for gnome-inform7. It āfeelsā substantially faster in the āplayā cycle, though I donāt have a way to time it since itās not a command-line tool.
diff --git a/src/meson.build b/src/meson.build
index 05628fae..0313adc0 100644
--- a/src/meson.build
+++ b/src/meson.build
@@ -17,6 +17,8 @@ resources = gnome.compile_resources('resources',
'com.inform7.IDE.gresource.xml', dependencies: license_html, c_name: 'i7',
source_dir: meson.current_build_dir())
+linktime_optimization_flags = cc.get_supported_arguments(['-flto','-O2'])
+
gui = static_library('inform7gui', 'actions.c', 'app.c', 'app-colorscheme.c',
'builder.c', 'configfile.c', 'document.c', 'document-search.c', 'elastic.c',
'error.c', 'extension.c', 'file.c', 'history.c', 'html.c', 'lang.c',
@@ -28,11 +30,13 @@ gui = static_library('inform7gui', 'actions.c', 'app.c', 'app-colorscheme.c',
'welcomedialog.c', resources, resources_generated,
include_directories: top_include,
dependencies: [libm, libxml, glib, gio, gdk, gtk, gtksourceview, gspell,
- goocanvas, plist, webkit, ratify, libchimara])
+ goocanvas, plist, webkit, ratify, libchimara],
+ c_args: [linktime_optimization_flags], link_args: [linktime_optimization_flags])
executable('gnome-inform7', 'main.c', export_dynamic: true,
include_directories: '..', dependencies: [glib, gtk, gtksourceview],
- link_whole: gui, install: true, install_dir: get_option('bindir'))
+ link_whole: gui, install: true, install_dir: get_option('bindir'),
+ c_args: [linktime_optimization_flags], link_args: [linktime_optimization_flags])
test_data_dir = meson.current_source_dir() / 'tests'
test_inform7 = executable('test-inform7', 'tests/test.c', 'tests/app-test.c',
I guess meson wasnāt that hard to figure out though it would have been a lot better if ālink_argsā had been documented somewhere reasonable.
By the way, the reason link-time optimization makes a huge difference is that it allows inlining functions across different .c files. The structure for inform6 and gnome-inform7 both have massive numbers of cross-file calls due to the very reasonable (for the programmer, but not for the compiler) file structure.
The edit-test cycle for writing Inform 7 is pretty slow even on very fast computers (like my Intel Core i9 with solid state drives), and thereās nothing to be done about NI right now, so speeding up the rest of the cycle is, IMO, quite important. Iād suggest trying -flto -O2 on libchimara and libratify as well.
āactivatingā a virtualenv just adds its bin directory to $PATH. Instead of source venv/bin/activate; prog --help you can generally just say venv/bin/prog --help and not worry about which shell sessions have which virtualenvs activated.
2 Likes
In this case meson calls ninja so you needed them both in your PATH, which inspired how I did things. But when I learned of mesonās dependency on ninja, I had automatically reached for pip install presuming recent meson would want recent ninja. It turns out that meson 0.55.0 is fine with Debian Busterās ninja-build 1.8.2 package so the latter can be apt installed and sourcing meson/bin/activate is thus avoidable. But probably still easier.
2 Likes
ā¦I suspect ni is built from multiple C files as well, so I would bet that -flto O2 would speed it up significantly too, if anyone actually had a copy of the source code to compile. Just saying.
But since thereās nothing to be done there unless someone can get a copy of the source code to recompile, speeding up the rest of the edit-compile-test cycle should help. So I really strongly advise that improving the compilation options with -flto be done in all of gnome-inform7 and its subpackages.
Iāve been looking into how old -flto is, and itās over 10 years old, both in gcc and binutils, and in clang. Itās documented in gcc 4.5.4 (copyright 2008). It looks like the requirement to pass the flag to cc during the link stage was dropped recently, but that seems much more recent, so itās probably safer to pass it there.
David Kinderās repo should really update the README for Inform 6 regarding compilation because options which double the speed of the program are kind of important. I doubt he will listen, however, since he seems hostile. Weāll see.
I havenāt got a response from Ben Finney, who packaged Inform 6 for Debian, or David Griffith, who maintains the āInform 6 for UNIXā package. So much for that. I suppose I should try Adam Thonton of the i7 perl CLI package as well, especially since I have a bug fix for him anyway.
Almost everyone on Linux is working with an inform6 which takes twice as much time as it should to run, due to brain-dead compilation options. This should be a no-brainer to fix.
If youāre uncomfortable with -O2 for debugging reasons, I just tested, and on inform6, the same speedup is there if you specify -Og instead (which is described in the GCC manual as follows: " -Og should be the optimization level of choice for the standard edit-compile-debug cycle, offering a reasonable level of optimization while maintaining fast compilation and a good debugging experience."). -Og doesnāt show up until gcc 4.8.5 (2015), though, and may not be present in clang, so itās less compatible than -O2.
Philip Chimentoās gnome-inform7 should be compiled with these options. Zed Lopezās upcoming docker package should include these options too. All these tools seem to have the sort of source file structure with a lot of cross-file function calls, where it makes a huge difference in speed. It probably affects the interpreters too, though theyāre so fast itās unlikely to be noticeable.
I did a quick check with clang. Itās not as dramatic. -O2 is a reasonable speedup (40%), but -flto adds essentially nothing to that (maybe 1% better).
1 Like
Thank you, Zarf, for identifying that it is -O2 which is making the big difference and not -flto. I have verified that this is correct with GCC as well.
I am afraid I had the wrong baseline, and I apologize. I assumed that these projects were being compiled with optimization, because I have not seen a project compiled for release without optimization in literally decades. It is standard programming practice to compile C programs for release with -O2, which has been available in GCC since the late 1980s and since before Clang was introduced. I strongly advise that this be adopted, given the 40%+ speedup.
well, dunno about current Ubuntu, but if is still debian-derived, pip should install phyton 2 packages, and for installing python 3 packages, the command should be pip3.
For sure, for really old timers (CP/M, VMSā¦ and DECsystem 
) like me pip with = is a sure way for major confusion (< destination > = < source >, contrary to usual *nix conventions) so, sure that meson and ninja isnāt on the wrong side of the = ?
Best regards from Italy,
dott. Piergiorgio.
If you were using the system python, thatād be true. But the above is using virtualenv to install a local python3 instance that comes with its own python3-normative pip.
1 Like
Thanks for testing, everyone!
@nerodenā Iām happy to help, but Iā¦ wellā¦ sat down after work, dinner, and cleanup, logged in to read this thread and I have to say my motivationās all but gone now. I asked for help from people who were comfortable compiling things themselves, but if compiling it makes you as angry as it seems to do, then maybe thatās not quite what Iād call ācomfortableā? Donāt get me wrong, Iām glad you got there in the end, and I really appreciate the list of feedback items, just cannot overstate how valuable that is! But sheesh, Iād sure be able to sit down and start fixing bugs with more of a smile on my face if there were less negativity about incompetent-this and inferior-that 
Iāll try my best to pretend I didnāt see that, and hopefully give some helpful responses below 
Sorry about the lack of this. It hasnāt really been a priority because Iāve been spending my time getting the GTK 3 version to work at all, and hopefully this stage where people need to compile it themselves is of finite duration and I can just go back to providing easy-to-install packages where nobody has to even think about a C compiler. Thankfully @Zed has done this and now itās part of the branch: initial commit of INSTALL.md by zedlopez Ā· Pull Request #14 Ā· ptomato/inform7-ide Ā· GitHub
Iāve fixed this, the rpath is now set on install. For what itās worth, Iād suggest installing programs that you compile yourself into ~/.local which I believe would not need to have either the rpath or the LD_LIBRARY_PATH set.
The program does not actually poke at this file itself, it uses the respective GTK APIs to save recently used files, so Iām quite surprised at this file being corrupted. Did you happen to save a copy before you deleted it?
Looking at the error message, is it possible that itās the apostrophe in the extension name thatās the problem? If you open another extension with that name, does it crash again? If so, I can report this bug to GTK.
I fixed this recently but hadnāt pushed it yet. Should work now.
Ditto.
Hopefully no longer severe if the above one is fixed, but there is a āhouseā icon on the toolbar when youāre on the Extensions panel which should still take you to back to the list of extensions no matter what.
I may just remove this altogether once the Extensions panel has the bugs worked out; itās redundant, and no longer present in the Mac app.
Itās the second one in the menu, pretty sure itās thereā¦ If itās really not showing up for you, do let me knowā¦
The magical meson incantation to turn on optimization and LTO project-wide is
meson setup build -Dbuildtype=release -Db_lto=true
When I build RPM/DEB/Flatpak packages for Ubuntu, Fedora, Debian, Flathub, etc., the debug flags and optimization levels are automatically set for that platformās default for release builds, which on most of these platforms is -O2 plus a whole bunch of other -f flags. So I would guess itās not correct that most people are using an unoptimized I6. And I think itās a reasonable default that what you get out of the box when you compile something from source is a debug build. Iād actually rather that people have debug builds when they are testing this, so that I can get good crash information if need be. But would it help demystify this if the -Dbuildtype argument were added to the INSTALL.md, with a bit of text explaining the possible values that it takes?
Is there any downside to having LTO always on in a debug build? I could just always set it to be on, though it seems like if that were a good idea, then it wouldnāt be an option ĀÆ\_(ć)_/ĀÆ
For what itās worth, I just do pip3 install --user meson which installs the latest version in ~/.local/bin, though I agree itās tidier to use virtualenv. But yes you wonāt have to do this if you install it in aptitude and your apt repository has a new enough version.
I looked into this, apparently some people have complained that the GCC manual is not correct about the āgood debugging experienceā in practice, so Meson switched their default for debug builds back to -O0, but they intend to make -Og the default again if the debugging experience improves in the future.
Everything else from the list, is noted. Iāll see what I can do about it.
5 Likes
Since it looks like posting to this thread is preferredā¦
Iām testing on a virtual machine with Pop! OS 20.10 groovy. Regrettably, initial results are unpromising as compared to running the legacy versionās .deb installation last updated by @interactivefiction. Iāve experienced several issues so far.
Issues experienced on gtk3 version:
- IDE hang during compilation (frequent), requiring force quit of gnome-inform7
- interpreter hangs on replay (frequent), requiring force quit of gnome-inform7
- IDE hangs after compilation without launching interpreter (1 time), requiring force quit
- hang on attempt to install extension from Public Library (1 time), requiring force quit of gnome-inform7 [note that it was the first attempt to use this feature, similar to nerodenās report]
- hang on closing IDE (1 time), requiring force quit of gnome-inform7
- skein display can be easily confused, e.g. if selecting ānew knotā but canceling via ESC, skein display will show blank space between nodes and dotted line will not traverse all nodes (always)
- default color schemes often unreadable due to very low contrast, e.g. transcript boxes (always)
Issues first encountered on previous version which persist in gtk3 version:
- first compilation of new project unexpectedly opens save dialog (always)
- segfault and crash to desktop on compilation (occasional) [maybe 5-10% of the time, no cause or correlation found]
- new story dialog does not recall last specified directory (always)
- color of transcript boxes not reset correctly when replaying (always)
@ptomato, if there are any specific actions I can take to help in diagnosing any of the above, please let me know.
1 Like
Philip: sorry I demotivated you. 
For me, Iām sick a lot due to chronic illness, and when Iām not, my work (which thankfully I can schedule myself) takes priority. When I manage to get a block of functional time when Iām capable of programming, I sprint and do as much of it as I can before I get too sick again. When I slam into a brick ātoolchainā wall, it creates intense frustration.
I enjoy the compile-test-edit cycle, but when I sit down to work on Inform 7 code, and find Iām instead working on the toolchain, within my limited time windowā¦ or learning a new build system ā thatās the source of frustration for me. If I sat down to actually work on the toolchain, well, thatās OK then. (I used to be a build system maintainer for GCC.)
I also know that seeing a really long list of small bugs can be intimidating, and Iām impressed that you fixed most of them immediately.
Great debugging. You nailed it. Crashed and crashes again if you launch. (Though the recently-used file relocated itself to .local/share/recently-used.xbel.)
Itās the apostrophe. Thereās likely to be some way to āescapeā the apostrophe; it is worth checking whether they are supposed to be escaped in some manner.
Since GTK is not superfast at deploying bugfixes, some form of workaround would be useful ā assuming it is a GTK bug and Iām not ready to assume that yet, for reasons explained below. Right now, an attempt to open an extension with an apostrophe in the name (a) crashes the program and (b) makes it crash on startup as it tries to load the name with the apostrophe into the ārecently usedā menu list. A less disastrous failure mode would be good enough.
I have not tried opening a story with an apostrophe in the name. I should see whether it causes the same problem. This would also be informative.
I am incompetent to diagnose problems in graphical toolkits; I have a poor understanding of the paradigm, let alone the details. However, text Iām a bit better at. From tracing through the code and looking online for GTK3 documentation I find, for g_file_get_uri ():
a string containing the [GFile](https://developer.gnome.org/gio/stable/GFile.html)'s URI. If the [GFile](https://developer.gnome.org/gio/stable/GFile.html) was constructed with an invalid URI, an invalid URI is returned.
I didnāt manage to trace it back further to where the GFile was created. But I did make further progress.
I am finding information about something likely to be related: some URL recipients expect apostrophes to be written as %27, even though that isnāt specified in the definition of URIs or done by standard URI encoding schemes.
After rereading the error message, I strongly suspect itās that. The spaces are being transcoded to %20 (Iām not sure where you do that); the apostrophes also need to be transcoded to %27 before being embedded in a ādetailed action nameā, and this may not be done by standard URL-encoding utilities.
a string containing the Gg_menu_item_set_detailed_action: Detailed action name 'app.open-recent(('file:///home/neroden/Inform/Extensions/Nathanael%20Nerode/Nathanael's%20Cookbook.i7x','inform7_extension'))' has invalid format: 70:expected ',' after first tuple element
It is quite likely that GTK will tell you that GTK3 is working correctly and that you have to make that change yourself.
Munging the filenames to replace ' with %27 before embedding it in the action name appears to be, at worst, an improvement. If it prevents the file from opening, at least it doesnāt crash the program or wedge it so it crashes on startup.
Well, itās back. I really did go looking for it. Iām wondering if somehow the menu got initialized by something which didnāt happen on first program launch for some reason? This may be a very hard bug to track down. Especially if it goes away after you use the program.
When it wasnāt working, I seem to remember that the help menu didnāt have all its items in it; it was very short. I think Contents, License, Help on Installed Extensions, Recipe Book, and Visit Inform7. com were ALL missing (though I may be incorrect about the last one). The help menu is much longer now than it was before. Iām scratching my head. Like I say, I am not competent to debug graphical window interfaces. But it seems like the menu didnāt build properly ?!? ; only the last three items were present. This may be a very hard or impossible bug to track down, but maybe that information will help track it down.
I think to reproduce I would have to test it on a blank install with an Inform directory and Extensions downloaded but where gnome-inform7 had never run before. Maybe the menuās initialized by running your first compilation or something? That sounds weird so Iām probably wrong but itās the only thing I can think of?
Well, I guess youāre probably right for Flatpak/gnome-inform7.
I havenāt been able to get gnome-inform7 working for years, remember.
The inform6 packaged with the commandline release of inform 7 for Linux is not optimized, and that I am now sure of, because thatās the baseline I tested against. I am very certain that that copy of inform6 should be compiled optimized.
I researched the inform6 package in Debian (which wouldnāt be used by inform7 people but would by inform6 developers), and although I canāt tell for 100% sure (since itās debug-stripped), I dug as far in as buildd logs, and it looks like optimization flags didnāt actually get passed to the compilation. The package is old and suboptimally designed to start with and needs an update, but quite likely the most common one in use by inform6 developers.
Debugging information included, yes. Compile with the -g flag. (This is on by default in GCC now; it wasnāt in older compilers, which is why itās traditionally passed by build systems.) Turning off optimization, no. At least -O1 should be turned on for a standard release; it rarely impedes debugging and often helps it. This is standard practice stuff.
Let me quote the GCC manual:
If you are not using some other optimization option, consider using -Og (see Optimize Options) with -g. With no -O option at all, some compiler passes that collect information useful for debugging do not run at all, so that -Og may result in a better debugging experience.
In Ye Olden Days of the 1970s, it used to be assumed that debugging was always better with no optimization, but this has not been standard practice for decades. Debugging information now generally allows you to see what function in the original source code youāre stepping through, even if the function has been inlined. (It is still true that if more advanced transformations have been made, the inlined function may have ādisappearedā, which is why occasionally you want to step back down to lower optimization levels.)
Yes, it would help a ton.
So thereās a long, old history here. Iāll explain it. LTO doesnāt do much of anything if you donāt optimize at all.
The oldest optimizing compilers all did whole-program optimization.
Compiling a bunch of separate C files into individual relocatable object code and then linking them was developed during the era of computers with small working memory. Programs had gotten larger and it wasnāt possible to compile a whole program at once on one computer. This, of course, broke interprocedural optimizations between different files, but the hardware limitations meant that it seemed like a good tradeoff.
It has not been a good tradeoff since the 1990s. So it was considered desirable to do whole-program optimization by default since then. However, everyone had gotten used to the structure of compiling individual C files and then linking them, and changing that standard practice was decided to be too disruptive. So immense amounts of work was put for over 20 years into to designing a scheme which allowed for whole-program optimization while still doing the ācompile a lot of individual files, then linkā procedure. (There were added complications with the need to link to precompiled static libraries with no source, or precompiled shared libraries; these were solved.) This led to the ālink time optimizationā process, which was at first unreliable, but was stabilized and became robust around 2010. Further effort was made to tell the driver for the linker to do the right thing automatically, which seems to have happened roughly 5 years ago (so the -flto flag probably doesnāt have to be passed to the linker with gcc from the last 5 years or so, and I canāt tell for sure but I think it never had to be with clang). And so after 30 years of work, we can finally go back to the whole-program optimization standard behavior which we should have been using all along, but for accidents of history. Such are the results of path dependence.
It should, in fact, always be on for all normal programs. (There are some exotic exceptions for programming the kernel, device drivers, programs with assembly-language trampolines and live backpatching, and other programs that directly manipulate blocks of machine language, or wish to defeat optimization for extremely-low-level machine-language timing-related reasons ā stuff which arguably should have been written in assembly but is written in C. Also occasionally on a really huge program, gigabytes, it means your machine canāt fit the compilation in memory and the original motivation for separate compilation remains valid.) The reason why -flto isnāt on by default is essentially historical, and I hope I have explained why. It probably will be defaulted on eventually.
That said, Zarf figured out it doesnāt make too much difference on inform6, whereas -O2 makes a huge difference.
I do suspect -flto will make more of a difference on gnome-inform7 because the code paths seem to contain a function in one file, which wraps a function in another file, which wraps a function in a third fileā¦ which makes a ton of sense for program organization and readability, but without -flto none of that can be inlined. With -flto, that code structure tends to be transformed into a single function, eliminating the function call overhead and allowing the chipās cache to do its work.
Whew.
ā¦Think of the poor Debian or Fedora packager. Iāve helped out a few times with thatā¦ if upstream has nice clear compilation instructions, their job is easy; if not, their job is hard and they may decide to just not do it. There are people who do a lot of packaging, as a volunteer service, who have a lot of expertise in the details of the packaging ā but donāt want to really get into the details of the individual packages more than they have to ā and theyāre more inclined to work on packaging packages where upstream build instructions are clear. If upstream provides something which can be compiled from source reliably, the packager will provide the instant-download package for the enduser. This became the paradigm on Linux some decades back.
I still remember when it wasnāt the paradigm, but it is now, and it does work pretty well IMO ā which is one reason thereās been a lot of pushback against using Flatpak and Snap for non-sandboxed applications, because theyāre trying to break the paradigm. And breaking the paradigm was Larssonās explicit goal for Flatpak: put packaging entirely in the hands of the developer and force the developer to do all the packaging work. It ends up meaning that you have to do all the work which a distribution packager would do. It is āsimplifiedā by including every single library and essentially making static binary compiles (incidentally bloating the packages, but disk is cheap now), but the result is that the interfaces between the libraries the developer uses and other libraries become the developerās problem, where in the standard paradigm, the developer only worried about interfaces between the developerās code and the libraries the developer used. Larsson has his idea of how things should work, and I suspect it ends up being more maintenance work for the developer. Compatibility in a sandboxed world ā Alexander Larsson Nothing wrong with shipping Flatpak, but keeping enough build documentation out there for the standard ādistributionā paradigm to work easily seems desirable IMO.
And of course if I ever actually learn graphical interface programming, at which I am currently incompetent, I will probably try to make code contributions to improve my own experience. But if I go away for a week, I wonāt remember how to build it. I have had to look up the LD_LIBRARY_PATH invocation five times in an hour. Thank you again for fixing that ā Iām going to try compiling the updated version tonight. Which means I will have to read the build instructions again, because I am pretty close to a memoryless state machine. (Math/CS joke.)
Sorry this is so long and sprawling!
OK. So after my git update failed for some reason, I did what everyone using git does, nuked it and redownloaded gnome-inform7 and switched to the gtk3 branch. Having forgotten everything about the build process, I then went in and followed the INSTALL.md instructions up through āsudo meson installā. Then I opened a new shell and typed simply gnome-inform7ā¦
and it worked! THANK YOU PHILIP AND ZED
Now that the rpath is being set during install to /usr/local to include the appropriate subdirectory of /usr/local, the instructions regarding LD_LIBRARY_PATH can probably become a footnote (though I would leave them in).
I tested a story with an apostrophe in the title, and sure enough, it crashes in the same place, during save. Iām not quite clear where the apostrophe to %27 munging should be happening but Iām pretty sure thatāll fix the problem.
The transcript is now showing up in small white text on lime green background; I donāt know whatās up with that, but itās unreadable. There needs to be some way to set the transcript colors, and I havenāt found one.
If those two issues are fixed, it seems to be working for me.
I suspect a bunch of the āsettings arenāt savedā bugs are related, and it seems like graphical toolkit work. I wish I could just code up a patch for that but I donāt understand GTK at all, really. In the case of the fonts, the font combination on opening inform-gnome7 actually canāt be replicated by any of the preset defaults in the Preferences tab, which seems especially quirky.
Added note: in fact, the combination on opening has a font for the documentation smaller than any of the possible selectable options. Selecting āStandardā font sizes makes that font larger. I have no idea whatās going on there.
I have not yet figured out how to set this up once Iāve set up meson once. Do I delete the build/ subdirectory first? (That seems to work. Also, I note that -Dbuildtype=release uses -O3 by default, which is the aggressive āfaster even if it makes the code biggerā option.)