recompiled Termonad has references to files from /nix/store that are invalid after garbage collecting

[yoctocell]

When I install termonad with nix-build and run ./result/bin/termonad I get an error saying

termonad-linux-x86_64: Failed to open file “/nix/store/jh90rkvpn6csgjlbjr0sxbwqrykbflb8-termonad-3.1.0.1-data/share/ghc-8.8.3/x86_64-linux-ghc-8.8.3/termonad-3.1.0.1/img/termonad-lambda.png”: No such file or directory (4)

It seems to be looking for the image for termonad 3.1.0.1, but I am on version 4.0.0.1. Is this termonad's problem or is it nix's problem?

[cdepillabout]

@yoctocell Could you list the exactly commands you used to build and run Termonad?

Also, just to make sure, you may want to delete ~/.cache/termonad, which holds your compiled Termonad binary. It is possible that there is an old compiled version of Termonad in that directory that is getting picked up for whatever reason.

[yoctocell]

Also, just to make sure, you may want to delete ~/.cache/termonad, which holds your compiled Termonad binary. It is possible that there is an old compiled version of Termonad in that directory that is getting picked up for whatever reason.

This solved the problem for me, Thanks! Feel free to close this issue.

[refaelsh]

@yoctocell Could you list the exactly commands you used to build and run Termonad?

Also, just to make sure, you may want to delete ~/.cache/termonad, which holds your compiled Termonad binary. It is possible that there is an old compiled version of Termonad in that directory that is getting picked up for whatever reason.

I had the same problem just now and this helped me too. I use NixOS btw.
Maybe its a bug and not a one time occurance of some esoteric edge case?

[cdepillabout]

Here's my guess as to what happened:

1. You installed Termonad 3.1.0.1 with Nix, and it ended up in the Nix store at a path like /nix/store/jh90rkvpn6csgjlbjr0sxbwqrykbflb8-termonad-3.1.0.1/.
2. You ran Termonad, and it recompiled ~/.config/termonad/termonad.hs and created the executable ~/.cache/termonad/termonad-linux-x86_64. This executable has some embedded data files (/nix/store/jh90rkvpn6csgjlbjr0sxbwqrykbflb8-termonad-3.1.0.1-data/share/ghc-8.8.3/x86_64-linux-ghc-8.8.3/termonad-3.1.0.1/img/termonad-lambda.png).
3. You installed Termonad 4.0.0.1 with Nix, and garbage-collected Termonad 3.1.0.1.

Since you garbaged collected, the file /nix/store/jh90rkvpn6csgjlbjr0sxbwqrykbflb8-termonad-3.1.0.1-data/share/ghc-8.8.3/x86_64-linux-ghc-8.8.3/termonad-3.1.0.1/img/termonad-lambda.png that is being used by ~/.cache/termonad/termonad-linux-x86_64 no longer exists.

If you delete ~/.cache/termonad, Termonad 4.0.0.1 knows to try to recompile itself. When it recompiles itself, the new ~/.cache/termonad/termonad-linux-x86_64 binary will be referencing termonad-lambda.png from Termonad 4.0.0.1, so everything should work.

Is anyone able to confirm that this is actually the problem?

---

The logic for how Termonad determines when it should recompile itself is detailed here:

https://hackage.haskell.org/package/termonad-4.4.0.0/docs/Termonad.html#v:defaultMain

Termonad is checking timestamps between the ~/.config/termonad/termonad.hs and ~/.cache/termonad/termonad-linux-x86_64 files. Maybe it should also check the timestamp on the /nix/store/abcxyz-termonad-3.1.0.1/bin/termonad binary? (Although this wouldn't work in Nix's cases, since everything in /nix/store is at epoch time 0....)

Or maybe Termonad could just use file-embed to embed the .png file inside itself?? I'm not sure what the best solution here would be.

I'm open to suggestions on what the best way to fix this would be.

[refaelsh]

Here's my guess as to what happened:

1. You installed Termonad 3.1.0.1 with Nix, and it ended up in the Nix store at a path like /nix/store/jh90rkvpn6csgjlbjr0sxbwqrykbflb8-termonad-3.1.0.1/.

2. You ran Termonad, and it recompiled ~/.config/termonad/termonad.hs and created the executable ~/.cache/termonad/termonad-linux-x86_64. This executable has some embedded data files (/nix/store/jh90rkvpn6csgjlbjr0sxbwqrykbflb8-termonad-3.1.0.1-data/share/ghc-8.8.3/x86_64-linux-ghc-8.8.3/termonad-3.1.0.1/img/termonad-lambda.png).

3. You installed Termonad 4.0.0.1 with Nix, and garbage-collected Termonad 3.1.0.1.

Since you garbaged collected, the file /nix/store/jh90rkvpn6csgjlbjr0sxbwqrykbflb8-termonad-3.1.0.1-data/share/ghc-8.8.3/x86_64-linux-ghc-8.8.3/termonad-3.1.0.1/img/termonad-lambda.png that is being used by ~/.cache/termonad/termonad-linux-x86_64 no longer exists.

If you delete ~/.cache/termonad, Termonad 4.0.0.1 knows to try to recompile itself. When it recompiles itself, the new ~/.cache/termonad/termonad-linux-x86_64 binary will be referencing termonad-lambda.png from Termonad 4.0.0.1, so everything should work.

Your description is exactly accurate, this is exactly what happened in my case.

[refaelsh]

Or maybe Termonad could just use file-embed to embed the .png file inside itself??

IMHO, this is the solution. If you agree, and give me some pointers, I would like to open a PR.

[cdepillabout]

@refaelsh Thanks for taking a look at this.

Here's the line where the .png file is being read from the data-files section in the .cabal file:

termonad/src/Termonad/App.hs

Line 374 in d6c8d74

termonadIconPath <- getDataFileName "img/termonad-lambda.png"

I imagine the easiest change could be to stop using data-files here, and instead just use https://hackage.haskell.org/package/file-embed to directly embed the file with TH.

[refaelsh]

@refaelsh Thanks for taking a look at this.

Here's the line where the .png file is being read from the data-files section in the .cabal file:

termonad/src/Termonad/App.hs

Line 374 in d6c8d74

termonadIconPath <- getDataFileName "img/termonad-lambda.png"

I imagine the easiest change could be to stop using data-files here, and instead just use https://hackage.haskell.org/package/file-embed to directly embed the file with TH.

I will try it. If I get somewhere, I will open a PR. Thank you for the pointers, it helps :-)

[refaelsh]

I am stuck. The file-embed library you suggested can embed the file in the form of ByteString but the windowSetDefaultIconFromFile function expects a path to the icon. Logically, it makes no sense to write the ByteString to a temp file, call the windowSetDefaultIconFromFile and then delete the temp file. Or does it?

[cdepillabout]

@refaelsh I poked around a little in gi-gtk, and it looks like there is a function windowSetDefaultIcon which allows you to set the icon from a raw PixBuf.

Maybe you can find a way to convert the ByteString into a Pixbuf. I'm sure there's some way to do that, but I don't know how easy it is.

[refaelsh]

@refaelsh I poked around a little in gi-gtk, and it looks like there is a function windowSetDefaultIcon which allows you to set the icon from a raw PixBuf.

Maybe you can find a way to convert the ByteString into a Pixbuf. I'm sure there's some way to do that, but I don't know how easy it is.

Yea, I've seen that possibility too. I did not want to mention it because a quick google search tolled me that converting a ByteString into a Pixbuf is something that nobody has ever done before.
But I understand what you are getting at. I will give it another try. Maybe ask on stackoverflow.

[refaelsh]

I've opened PR #227 to continue discussion.