Gnome-inform7 6L38/6M62 IDE now running on modern Ubuntu & Fedora OS

Since I’ve had no luck creating my own account on the Mantis bug-tracker, would someone kindly repost this bug report for me?

I’m running Linux Mint 19.2 “Tina”, using the Mate desktop.

The Inform 7 IDE opens as it should and seems to run okay (It does tend to crash when compiling small projects, but I’m used to that.)

However at some point it seems to interfere with the display manager (I think.) What happens is that the taskbar ceases to be displayed, and there’s a gap (showing the desktop background) between the edge of the I7 window and the edge of the screen. The functionality of the taskbar remains: if I click on the area where the Menu button would be, then the Menu appears, and I’m able to select most programs and launch them as usual.

One that doesn’t work as usual is “Quit”. Clicking on the Quit entry usually launches a small central window with the options Log Out, Cancel, Shut Down etc, but this central window doesn’t open, and I have to wait until the auto countdown triggers shutdown.

Thanks,

DD

Hi Dizzydonut-

This sounds like a possible GTK issue or a cumulative memory leak affecting things system wide (perhaps caused by the frequent compilation crashes you mention). I did not get the opportunity to test on Linux Mint only Ubuntu 16.04 / 18.04 and Fedora 29 / 30 using the Xorg display manager. In some testing I did observe that the gnome-inform7 compilation crashes were reduced significantly by launching the application from a commandline window. Is it possible you could try and launch the application (after a fresh reboot of the computer) from the commandline by typing gnome-inform7 at the command line prompt? This should launch the IDE and also leave a commandline window open that you will see various messages appear in. If you see a difference in behavior it would be great to know!

Okay, I’ll do that and report back. Thanks for the quick response!

If there is interest I do have an ubuntu 19.10 build working as well as an early test version for Fedora 31; however, I could use some assistance testing them out from the community as there are further new workarounds required for these operating systems. Please let me know if you have any interest to help with testing.

1 Like

Hiya @interactivefiction

Responding a lot later than I’d intended, sorry! I’ve been opening I7 via a terminal window, and it’s been pretty well behaved overall. There are a lot of warnings when it first opens, mostly saying that various extension files aren’t recognized. When it has crashed, it was always on recompiling, with the following message in the terminal window:

Gdk:ERROR:/build/gtk+2.0-AoeliP/gtk+2.0-2.24.32/gdk/gdkregion-generic.c:1110:miUnionNonO: assertion failed: (y1 < y2)
Aborted (core dumped)

I’ve attached a zip of the full startup, in case any of the warnings are helpful.

The mysterious business of I7 interfering with the taskbar being drawn (and the shutdown window being displayed) continues, but I’ve not been able to see any pattern – except, of course the “when least convenient” pattern common to all bugs!

By the way, I7 is complaining that my extensions folder contains things it shouldn’t, e.g. " Locksmith.h - non-folder found where author folders should be" but since I don’t know where my extensions folder actually is I can’t open it to have a look-see. Where does it install to? I’ve checked /home/ and /usr/ but can’t find it.

As always, thanks for your help in maintaining this tool for us.
Inform7 crash 2019-12-21.txt.zip (753 Bytes)

Hi Dizzydonut-

I took a look at the crash log and one thing that jumped out immediately to me is the similarity of your issue with:

I was wondering if you could try the preference settings workaround advised in the above thread that claims it is possible to “miraculously” fix them :wink:? For what it is worth, looking at other errors similar to this online I can see that there are others that have seen this behavior with GTK2. I will do some more digging on my side. Hopefully, the workaround in the thread above help on your side!

On my Fedora system it appears to be: /home/ < username > /Inform7/Extensions

1 Like

Unfortunately in this version of the IDE, the File Edit View etc. menus don’t open, so I can’t tinker with the styles etc. I do use the text search quite often, because I’ve read the docs so often that I know something can be done, but often only that it’s in the example with the “starry void,” or something. It’ll be annoying if that’s what’s causing the crashes, but hey.

As for the crashes occurring because the code has no errors – that can’t be my problem! :slightly_smiling_face:

1 Like

Ok, so none of the normal menu items work. A big hassle. I may try making a Linux Mint build specifically. You are on Linux Mint 19.2 currently? I am curious if, at least, your menus would work correctly if the build was made on the specific OS you are using. I do think the code may have errors; however, gtk2 is an older API so I would expect this type of issue is more likely to get resolved during migration to gtk3 (something I believe ptomato is working on based on a quick glance at the branches in the gnome-inform7 git repo).

Ah, on my system (Linux Mint) the folder just says “Inform” so I’d mixed in I6 stuff where it shouldn’t be. Thanks for the pointer.

Fixed now. For future reference, the path is:

~/Inform/Extensions

1 Like

Linux Mint 19.2 “Tina” yes. They worked on the previous version though. (6L38) Of course I’d be delighted if you’d consider making such a build, but not if it’s going to be a huge amount of work. Expert volunteer hours are precious.

Very interesting so 6L38 worked before but 6M62 has a problem with the menus. That helps narrow things down quite a bit. Spinning up a VM for Linux Mint is not a big effort nor is making the build itself. That said, the fact that it worked for 6L38 tells me there is a change to the code that introduced this behavior. I may be able to see what that difference is by comparing the code for 6L38 to 6M62. Rather than building a 6M62 specifically for Linux Mint, let me put some effort into seeing what may have changed between the two builds. I will keep you updated!

1 Like

trouble is for Debian 10, whose 64b packages are now amd64… it’s possible to repack into amd64.deb ?

Best regards from Italy,
dott. Piergiorgio.

Personally I have not tested on Debian, only Ubuntu and Fedora. Generally x86_64 versus amd64 are different names for the same thing. So assuming the proper library versions are available on your distro, it should work in theory :slightly_smiling_face:

https://wiki.debian.org/DebianAMD64Faq

trouble is, x86_64 ni always segfaults here and amd64 ni never segfaults… for now.

this is the ni whose always segfault here:

-rwxr-xr-x 1 root root 3051776 gen 13 2016 ni
ni: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, for GNU/Linux 2.6.26, BuildID[sha1]=02a8ac3b08afbbcc7951dc34dd0b917f04afe6a5, stripped

and this is the working amd64 ni:

-rwxr-xr-x 1 pigi pigi 3403624 mag 29 2018 ni
ni: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked, for GNU/Linux 2.6.32, BuildID[sha1]=45a0638d8640fb9d737fbdcbdc59ddbbfa9b8ce1, stripped

I agree that both are x86_64, but are clearly two different ni…

Best regards from Italy,
dott. Piergiorgio.

1 Like

Great info! The ni used in the debs is actually a precompiled binary I obtained from the official Inform7 website. It appears it is statically linked agains a different kernel than you are on. Do you have a link to the ni you are using or a deb package that contains it? Also, may I ask a few questions:

  1. Is the user interface for gnome-inform7 opening up for you?
  2. Is the segfault encountered only when you attempt to compile?
  3. Which debian package have you attempted to use?
  1. yes, only issue is that crashes when I run a glulx build without fully closing the precedent run (I’m not sure to have explained well…)

Next time, I look into the 'terp, eventually changing also that binary.

  1. damn well, YES ! solved putting that 2018 ni binary.

  2. dunno I know now. so many install/disinstall/mucking around, I fear is a sort of mishmash of various flavour of 6M62 (and no, I don’t want to attempt a full cleaning & reinstalling, too many brittle things around, IMVHO.

Now I must get ready for a political meeting (Italian politics… still “keep your dagger ready and watch your six” grade, trust me), so I’ll reply either late in night (CET) or tomorrow.

Best regards from Italy,
dott. Piergiorgio.

1 Like

Nice work! :slightly_smiling_face: It sounds like you have some improvement on your issue by replacing the ni. If it is possible, can you point me to the location of the ni binary you are using? I would like to download it for myself and when I have time package a gnome-inform7 Debian 10 build using that ni binary. It would be nice if other authors do not have to manually replace the ni in the future.

This ni is already packaged in the official (that is, inform7.com), that is:

http://inform7.com/apps/6M62/I7_6M62_Linux_all.tar.gz

I suggest navigating in the archives inside with a file & archive manager (I use mc, because, well, for me CLI interface and keyboard is much faster than mouse) and extract that ni from the relevant sub-archive.

HTH and
Best regards from Italy,
dott. Piergiorgio.

1 Like

Thanks Piergiorgio! I did a quick check and the ni in both debs I posted for Ubuntu 16.04 and 18.04 is quite old. I pulled the tar and compared against the x86_64 ni and found the 2018 version your debug info referenced. It looks like this may be a requirement for Debian 10. Appreciate your help digging into the details. I will attempt to build a new package that includes the updated ni specifically for Debian 10 when I get some free time.

1 Like