Beta release of Inform App for Linux

This is a beta release of the Inform App for Linux with the new Inform compiler v10.1.0, recently announced.

It’s much like the release candidate I published a few weeks ago before the new compiler version was released, only now it contains the new compiler as well.

Aside from the new compiler, the only new feature since then is that you can now also build your project with old versions of the compiler, in case your project doesn’t yet work with the new version.

Download from here and please let me know if it works for you:

10 Likes

With the debian package, back to square one… segmentation fault when pressing compile button !!

current system:

Linux Duilio 5.10.0-13-amd64 #1 SMP Debian 5.10.106-1 (2022-03-17) x86_64 GNU/Linux

Zio, Ti dovresti cimentare di piu :wink:

(explanation of the pun above: Chimento in Italian means “Trial, effort”, and in Italy, often we colloqually refer to italo-americans as “zii d’ America” “American uncles”, because, well, not few Italian families have uncles emigrated in America…)

Best regards from Italy,
dott. Piergiorgio.

I tried both the deb and flatpak. Neither seem to work properly on my system. The deb build segfaults when i try to compile, gdb tells me the top of the stacktrace is this:

#0  __strcmp_avx2 () at ../sysdeps/x86_64/multiarch/strcmp-avx2.S:115
#1  0x00007fe1df6c5149 in g_str_equal () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x0000556b6bd10f10 in  ()
#3  0x0000556b6bd1131c in i7_app_get_inform_command_line ()
#4  0x0000556b6bd307f7 in i7_story_compile ()
#5  0x00007fe1de98d71f in g_closure_invoke () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#6  0x00007fe1de99fcf6 in  () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0

The flatpack version also crashes when compiling. I don’t see a segfault (but maybe flatpak hides that), the console output is:

** (inform7-ide:2): CRITICAL **: 11:04:08.813: on_language_version_chooser_changed: assertion 'id != NULL' failed

** (inform7-ide:2): CRITICAL **: 11:04:08.813: on_language_version_chooser_changed: assertion 'id != NULL' failed

** (inform7-ide:2): WARNING **: 11:04:11.824: Error setting custom icon on file /home/fg/inform/ld50/ld50.inform: Setting attribute metadata::custom-icon-name not supported

** (inform7-ide:2): WARNING **: 11:04:11.824: Error setting custom icon on file /home/fg/inform/ld50/ld50.materials: Setting attribute metadata::custom-icon-name not supported

This is on debian unstable running i3 as the window manager.

Both versions also segfault after trying to open a directory that’s not an inform project, immediately after I close the dialog that tells me it’s not a project.

on the segfault when trying to open a non-inform directory, there’s a solid clue in form of stderr reporting:

inform7-ide 

(inform7-ide:6867): Gtk-WARNING **: 11:18:11.919: Theme parsing error: <data>:1:88: Not using units is deprecated. Assuming 'px'.

** (inform7-ide:6867): WARNING **: 11:18:11.920: Invalid CSS: <data>:1:88Junk at end of value for font-size
free(): invalid pointer

also, I report that strangely the trio of 9.x closed-source binaries behave, and actually compiles & run the 'terps without issues, save a sequence of warnings:

(inform7-ide:5325): Gtk-WARNING **: 11:14:02.989: Theme parsing error: <data>:1:88: Not using units is deprecated. Assuming 'px'.

** (inform7-ide:5325): WARNING **: 11:14:02.989: Invalid CSS: <data>:1:88Junk at end of value for font-size

(inform7-ide:5325): GLib-GObject-CRITICAL **: 11:14:14.080: g_object_is_floating: assertion 'G_IS_OBJECT (object)' failed

(inform7-ide:5325): Gtk-CRITICAL **: 11:14:14.080: gtk_widget_show: assertion 'GTK_IS_WIDGET (widget)' failed

(inform7-ide:5325): Gtk-CRITICAL **: 11:14:14.080: gtk_list_box_insert: assertion 'GTK_IS_WIDGET (child)' failed

(inform7-ide:5325): GLib-GObject-CRITICAL **: 11:14:14.080: g_object_unref: assertion 'G_IS_OBJECT (object)' failed

(inform7-ide:5325): GLib-GObject-CRITICAL **: 11:14:14.080: g_object_unref: assertion 'G_IS_OBJECT (object)' failed

(inform7-ide:5325): GLib-GObject-CRITICAL **: 11:14:14.080: g_object_is_floating: assertion 'G_IS_OBJECT (object)' failed

(inform7-ide:5325): Gtk-CRITICAL **: 11:14:14.080: gtk_widget_show: assertion 'GTK_IS_WIDGET (widget)' failed

(inform7-ide:5325): Gtk-CRITICAL **: 11:14:14.080: gtk_list_box_insert: assertion 'GTK_IS_WIDGET (child)' failed

(inform7-ide:5325): GLib-GObject-CRITICAL **: 11:14:14.080: g_object_unref: assertion 'G_IS_OBJECT (object)' failed

(inform7-ide:5325): GLib-GObject-CRITICAL **: 11:14:14.080: g_object_unref: assertion 'G_IS_OBJECT (object)' failed

when in the case of inform 10, the warning prior of the segfault is much shorter:

inform7-ide 

(inform7-ide:4764): Gtk-WARNING **: 11:13:11.708: Theme parsing error: <data>:1:88: Not using units is deprecated. Assuming 'px'.

** (inform7-ide:4764): WARNING **: 11:13:11.708: Invalid CSS: <data>:1:88Junk at end of value for font-size

** (inform7-ide:4764): CRITICAL **: 11:13:14.793: on_language_version_chooser_changed: assertion 'id != NULL' failed

** (inform7-ide:4764): CRITICAL **: 11:13:14.793: on_language_version_chooser_changed: assertion 'id != NULL' failed

the first two warnings are common to both the segfault with v.10 and the successful compilation with 9.3/6M62, so perhaps the key to the issue lies in the third warning and/or the successive…

HTH, and
Best regards from Italy.

ps. command line RULEZ !!

Ok, I did some more testing and it’s probably going to be something simple. If I open an old project and try to build or run it, it crashes. If I first go to settings “Language version” is empty. If I set that to any value things work. This is both with the deb and the flatpak version.

I should have looked at this in the first place, or tried a new empty project…

1 Like

UPDATE: solved for me, simply moving out of picture the directory ~/Inform and letting inform7-ide 2.0 rebuilt it for itself…

now, testing the IDE with the WIPs. a little final step step toward declaring Inform 7 production-grade… :slight_smile:

the non-inform directory bug is still there, though. but with a little care (I have sorted-by-engine directory tree for works, so actually is a non-issue for me…) can be endured until closed.

Best regards from Italy,
dott. Piergiorgio.

When trying to release, I get “Error opening file /home/fg/inform/ld50/ld50.inform/Build/StatusCblorb.html: No such file or directory”

Edit: this happens with an old project when building with inform 10. If I build it with 9.x the release works. If I create a new project from scratch, 10 also works.

I think that I figured the segfault bug: perhaps is indeed the third warning, because segfault when I kept blank the language version selector. After I select a version, the segfault totally disappear.

If I’m correct, the fix is giving a default for the language version selector instead of its initial blank, either “current” or “inform 10.1.0…”

now practically production-grade, two major (show-stopper) bug whose can be very easily dodged with a little care…

Best regards from Italy,
dott. Piergiorgio.

Thanks for figuring all this out. It looks like I made the classic mistake of not testing the upgrade path :slight_smile:

I will try to get a new one out by Saturday.

I do love multilingual puns, dottore!

2 Likes

I have some hope that all of these problems were fixed by the same line of code.

Here is a link to another beta release.

Do make sure to uninstall the last beta release before installing this one, by the way.

I tested the deb build for this one on the same debian unstable system as the last one. I can test the flatpak later today if needed.

The basic stuff is fixed. I can open my old project (which I reverted back to its untouched state first, so the test is the same) and compile and run it.

Releasing still has the same “Error opening file /somewhere/project.inform/Build/StatusCblorb.html: No such file or directory”, but I’ve now isolated what that comes from a bit more. It’s nothing to do with a new vs old project, it appears as soon as there’s a “release along with a solution” in the source. Releasing along with cover art, a “Standard” website, the source text, or the “Quixe” interpreter is fine, just “a solution” breaks it, no idea if that’s i7 itself or the ide doing things wrong.

Opening something that’s not a project still crashes for me.

When playtesting my scene, the color scheme is a but unfortunate, I have dark deep blue on a dark gray background for my own input (flatpak).

This one’s actually a bug in Inblorb, and I’ve tracked down a solution. I assume it’ll be fixed in the official Inform 10.1.0.

I skipped over reading this the first time around. It’s fixed now. I don’t know if I’ll do another beta release before the real one, but in the real release you should be able to open as many non-Inform folders as you like and get an error message instead of a crash every time :smile:

Thanks!

1 Like

Unfortunately, this is a known bug and the theming system needs a bit of an overhaul before it can be fixed. There’s more info in Release candidate of Inform 7 IDE for GNOME - testing help wanted - #34 by ptomato

1 Like

on theming system, a minor but annoying bug is that the font size is correctly applied to the documentation pane, but not the source pane.

Best regards from Italy,
dott. Piergiorgio.

OK, same problem I’ve had before with gnome-inform7 is now happening with inform7-ide. After I’ve created a file with an apostrophe in the name, the code which saves recently opened files doesn’t escape the name properly, which means it crashes the next time I try to open a new project while looking up the “recent files” list.

Since there are multiple extensions in the Friends of I7 repo with apostrophes, most of them by me, this is quite problematic. I am thinking of removing the apostrophes.

What’s worse is I’m having trouble finding where the cache is hidden so I can nuke it.

Edit: Found it. It’s

~/.local/share/recently_used.xbel

Here’s the crash:

(inform7-ide:47771): GLib-GIO-ERROR **: 11:19:57.313: g_menu_item_set_detailed_action: Detailed action name 'app.open-recent(('file:///home/neroden/programming/inform-projects/Nathanael's%20Test%20Extension.i7x','inform7_extension'))' has invalid format: 61:expected ',' after first tuple element
Trace/breakpoint trap

This is with the .deb. I have absolutely no idea how to install flatpaks, I tried and gave up.

Frankly I am not dependent on the “recent files” list and I would be OK with as simplistic a solution as skipping over files with “problem filenames” when saving the recent files list, I just need it to stop crashing.

Closely related bug: Try “Open Extension” from the menu on one of the extensions with an apostrophe in the name. Instant crash. I think it’s very worthwhile to escape the apostrophes/single-quotes. I’ll see if I can find the relevant code in the git repo.

(I realized the IDE was picking up the setup from my previous attempted install, where, like a number of other people, I made the Extensions folder into a git checkout for the Friends of I7 extensions repo. Anyway, this will happen whenever there’s an extension with an apostrophe in the name.)

(inform7-ide:58555): GLib-GIO-ERROR **: 11:41:09.122: g_menu_item_set_detailed_action: Detailed action name 'app.open-recent(('file:///home/neroden/Inform/Extensions/Nathanael%20Nerode/Nathanael's%20Debug%20Tools.i7x','inform7_extension'))' has invalid format: 70:expected ',' after first tuple element

FWIW, the flatpak failure:

The application com.inform7.IDE depends on runtimes from:
  https://dl.flathub.org/repo/
Configure this as new remote 'flathub' [Y/n]: y
error: Remote "ide1-origin" not found

Update: Ok, I got the flatpak working with the magic incantations

flatpak install --user --bundle *.flatpak
flatpak run com.inform7.IDE

…and verified that the apostrophe crash occurs reliably with the flatpak too. So it’s not a flatpak-vs-deb issue. Even more fun, since the flatpak and deb version share reliance on recently-used.xbel, the breakage in one can prevent the other from launching.

It appears that the gtk_recent_manager_add_full does not accept the output of g_file_get_uri.

g_file_get_uri is doing its job according to specs, it appears. URIs can contain unescaped apostrophes. RFC 3986 - Uniform Resource Identifier (URI): Generic Syntax (RFC3986)

There is no particular specification for gtk_recent_manager_add_full, so it’s also legit for it to not accept apostrophes, it seems. :sigh:

The best thing to do is, I suspect, is – in the functions update_recent_story_file and update_recent_extension_file, possibly elsewhere – to take the URL output from g_file_get_url, then escape the apostrophes (replacing with %27), before passing ito into gtk_recent_manager_add_full.

Or it’s possible that a complete wrapper of g_file_get_url is the way to go. I know writing string handlers in C is a huge pain in the neck.

However, a crude hack which would stop the persistent crashing is simply to check the output from g_file_get_url to make sure it doesn’t contain an apostrophe and bail out if it does.

Update: I’m trying to write a wrapper which escapes the apostrophe.

OK, Much more substantial update. I’ve written a patch which escapes the apostrophes.

Fifth version – compiles with no warnings.
escape-apostrophes.diff.txt (5.3 KB)

I haven’t been able to test this.

Update: I’ve got Inform 7 building, but I haven’t figured out how to copy the pieces over to inform7-ide yet. I’ve got the meson build system up and running for inform7-ide, but I haven’t managed to figure out how to copy over all the correct files from Inform 7 itself, so I can’t actually get it building.

I managed to run the build system far enough to get it compiling and fixed some obvious bugs. So I would be ready to test it.

Unfortunately, then the build process crashes with:

[6/6] Linking target src/test-inform7
problem:  An internal error has occurred: Unable to open model CSS material for reading. The error was detected at line 332 of "/home/neroden/programming/inform-build/inweb/foundation-module/Chapter 5/HTML.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 www.inform7.com/bugs. 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.

(inform7-ide:73179): Gtk-CRITICAL **: 01:42:00.578: gtk_tree_store_get_value: assertion 'VALID_ITER (iter, tree_store)' failed

(inform7-ide:73179): GLib-GObject-WARNING **: 01:42:00.578: ../../../gobject/gtype.c:4333: type id '0' is invalid

(inform7-ide:73179): GLib-GObject-WARNING **: 01:42:00.579: can't peek value table for type '<invalid>' which is not currently referenced
Segmentation fault

I’ve basically been blindly copying things over from the Inform 7 build to try to get the build process to get far enough to compile, so I really have no idea what is going on there.

Philip (ptomato), I would appreciate it if you could give this patch a spin. I think it should do the trick, though it is hard to tell without testing. The key is that even though the URI encoder we were using doesn’t encode apostrophes, the decoders always decode %27, so we don’t have to worry about that end of it.

I’m kind of proud of this one – I haven’t done low-level byte-at-a-time code in a while.

1 Like