Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[kahrkunne]

EDIT2: Okay, I know a way to fix it. I've found an alternative libz.so that makes it work, so doing LD_PRELOAD=path/to/libz.so ./df makes it work. How do I intergrate this with PyNLP? Like, what exactly is run when I press 'Play Dwarf Fortress!'?

It will ultimately run either the df script or the dfhack script in the Dwarf Fortress folder (depending on whether DFHack is enabled or not), so I would suggest editing those scripts.

In df, add LD_PRELOAD=path/to/libz.so in front of ./libs/Dwarf_Fortress

If dfhack, find the line PRELOAD_LIB=./hack/libdfhack.so and change it to PRELOAD_LIB="./hack/libdfhack.so path/to/libz.so" (including the quotes).

Ok, so in your avrage use case, what does os.path.join(paths.get('df'), 'df') return?

It returns <DF folder>/df.

I had already edited the df script in the dfhack folder, and it works if I launch just that, but it didn't work when doing it through PyLNP. That's why I wondered what exactly it was excecuting.
I did the thing in the dfhack script now and it appears to launch *something* which instantly closes. Might have made a typo but I don't think so.
EDIT: No, didn't make a typo anywhere. running ./df from the df_linux directory still works, so the only thing I can think of is that something is wrong with the instruction you gave me on dfhack.

[Pidgeot]

I had already edited the df script in the dfhack folder, and it works if I launch just that, but it didn't work when doing it through PyLNP. That's why I wondered what exactly it was excecuting.
I did the thing in the dfhack script now and it appears to launch *something* which instantly closes. Might have made a typo but I don't think so.
EDIT: No, didn't make a typo anywhere. running ./df from the df_linux directory still works, so the only thing I can think of is that something is wrong with the instruction you gave me on dfhack.

That is the best I can tell you based on what I can see, but as I have already said, I don't play DF on Linux, and I'm not an expert on getting DF to run on Linux.

I can, however, tell you it isn't a PyLNP issue, because all PyLNP does to launch DF on Linux is run a shell script (either df, or dfhack through xdg-terminal). I really can't offer any more advice than I've done so far; you'll need to ask someone else.

[kahrkunne]

I had already edited the df script in the dfhack folder, and it works if I launch just that, but it didn't work when doing it through PyLNP. That's why I wondered what exactly it was excecuting.
I did the thing in the dfhack script now and it appears to launch *something* which instantly closes. Might have made a typo but I don't think so.
EDIT: No, didn't make a typo anywhere. running ./df from the df_linux directory still works, so the only thing I can think of is that something is wrong with the instruction you gave me on dfhack.

That is the best I can tell you based on what I can see, but as I have already said, I don't play DF on Linux, and I'm not an expert on getting DF to run on Linux.

I can, however, tell you it isn't a PyLNP issue, because all PyLNP does to launch DF on Linux is run a shell script (either df, or dfhack through xdg-terminal). I really can't offer any more advice than I've done so far; you'll need to ask someone else.

Well, I'll try something else then, thanks for your help.
For what it's worth, running the dfhack script directly gives

Spoiler (click to show/hide)

kahr[df_linux]>./dfhack
env: ./libs/libz.so: Permission denied

EDIT: had to chmod the .so file, but now I"m getting a segfault.
EDIT2: got it to work.

[kahrkunne]

Okay, found some interesting new bugs!
* PyLNP becomes unresponsive after game in launched
* Close on game launch function doesn't work
* Autostart utilities start after launcher is closed, even when close on game launch function is disabled
I'd be able to deal with all these if it weren't for the next thing:
* Forcibly killing the launcher also kills the dfhack terminal

[Pidgeot]

Okay, found some interesting new bugs!
* PyLNP becomes unresponsive after game in launched

You're launching through a terminal, right? In that case, you should be able to use CTRL-C when it's hanging to force it to close, and generate a stack trace in the process. (You will likely have to look in one of the log files, stderr.txt and stdout.txt.) This would be most helpful for debugging (but see below first, because I do have an idea)

* Close on game launch function doesn't work
* Autostart utilities start after launcher is closed, even when close on game launch function is disabled
I'd be able to deal with all these if it weren't for the next thing:
* Forcibly killing the launcher also kills the dfhack terminal

I do not have a running system that allows me to reproduce your problems, and Arch has too few "fixed" packages to allow me to create a new VM to properly replicate your setup (I don't have enough information about which packages you have which may affect the issue).

However, it sounds to me like the xdg-terminal script isn't spawning a new, independent terminal like it should. A guess: since you have no DE, maybe that new terminal doesn't have a way of attaching to a proper parent, so it remains a child process of PyLNP - run pstree while it's hanging to check. If DF remains a child process of PyLNP, then that's the problem.

I have tried every single option I could find to handle that, and xdg-terminal was the only solution that came even close to being reliable; the only possible fix is to figure out a way to make xdg-terminal do it on a case-by-case basis. Since I do not have access to this environment, that means you'll have to either fix it yourself, launch DF manually, or avoid DFHack.

Of course, I would very much *like* to fix it if possible, but I will need your help to figure out what works.

Judging by the documentation, it does seem that you can indeed tell i3wm to launch DFHack in the intended way. If I am reading the documentation correctly (and I make no guarantees that I am), you should try to modify xdg-terminal (similar to what you did earlier) to run this command instead:

Code: [Select]

i3-msg exec --no-startup-id i3-sensible-terminal -e "$command"
If that works, I would also like to know what happens with this:

Code: [Select]

i3-msg exec i3-sensible-terminal -e "$command"
and this:

Code: [Select]

i3-msg exec --no-startup-id "$command"
...and if that last one works, please try this one too:

Code: [Select]

i3-msg exec "$command"
A properly working solution would end up spawning two new windows: one for DFHack's terminal, and one for DF itself, and both should continue to exist when PyLNP is not running. For the second and fourth command, pay special attention to the behavior of mouse cursors and other UI aspects.

It is important that I know exactly which of these commands work; otherwise I cannot fix it properly.

Finally, I need to find a way to reliably detect that i3wm is running (not merely installed). Please check your environment variables in a fresh terminal (run the command "export") and check if any of them seem relevant to i3 (and if so, please let me know name and value of all such variables, since some may be more reliable than others). If there are too many, or if you don't know which ones seem relevant, consider sending the entire output from "export" in a PM; I should be able to figure it out from there.

[kahrkunne]

I'll try all of that later, but first let me tell you a bit more about the behaviour that's going on:
* Xkill'ing the window of PyLNP does NOT kill the dfhack window, and it does NOT free the terminal it was launched from
* Pressing Control-C in the terminal I ran PyLNP from kills both the PyLNP window and the DFHack window
* Neither of these things kills DF itself
This would indicate that both the DFHack window and the PyLNP window are children of the terminal they were spawned from
Furthermore:
* The PyLNP window itself hangs, but neither the DFHack window nor the DF window themselves hang

Other than that, I think you're using i3-msg wrong, because it's intended to be used for IPC between something and i3wm.
Also, i3-msg has no --no-startup-id option.
Also, from some small tests on the command line here, the correct syntax appears to be  "i3-msg exec 'i3-sensible-terminal -e $command'". Important is that $command doesn't exit immediately (for example, entering 'ls' in the place of $command will immediately exit, while entering 'vim' means it will stay alive. Strangely enough it also immediately exits when entering 'ls | less', while it shouldn't)

Lastly:
kahr[~]>export | grep i3
DESKTOP_STARTUP_ID=i3/i3-sensible-terminal/575-14-K-02_TIME59928497

I'm sure there is a way to know if i3 is running, because things like screenfetch can accurately show it. A cheap hack would be to just check if 'pidof i3' returns something and hope the user is not weird enough to have something running by the name of i3 that is not i3wm.

EDIT: seeing as how --no-startup-id is not an option on i3-msg, and because i3-msg exec vim only prints '[{"success":true}]' without spawning anything, I think i3-msg exec 'i3-sensible-terminal -e "$command"' should be the right syntax, which I'll try out shortly after I save my DF game.
When testing that but substituting $command with 'vim', I can also see that it gives control back to the terminal it was launched from, so this looks promising.
Note however that if i3-sensible-terminal does not evaluate to urxvt, it's syntax might be different (it might not use the -e for example) and everything will break.

EDIT2: A little correction on my earlier bug report: utilities set to auto excecute don't excecute after PyLNP exits, but after DF exits. Of course, there is no reason why I would want DwarfTherapist to run *after* I'm done playing DF, so that's a bug.

EDIT3: Okay, I changed the line in xdg-terminal, and I did a little test by running './xdg-terminal vim'.
It shows some odd results: It appears to only partially give control back to the terminal it was launched from: I can type 'ls' (or any command, also tested with 'exit') in that terminal, and nothing will happen, but when I close the vim window spawned, ls will excecute.
I doubt this is going to work, but I'll compile it and test it anyways. I'll also provide those log files you asked for.

EDIT4: Okay, results:
* PyLNP still goes unresponsive
* Control-C'ing in the terminal PyLNP was launched from still makes the DFHack window exit
Basically, nothing changed.
None of the log files (stderr.txt, stdout.txt) contain anything either, any the pressing of Control-C only gives the standard KeyboardInterrupt traceback.

EDIT5: Here's the output of pstree: http://pastebin.com/U7FGcjV5
The relevant part is beneath upowerd
Interestingly, apparently when I press Control-C in the terminal only once, only dfhack exits and the PyLNP window becomes responsive again, and when i press Control-C again, the PyLNP window closes too (I always spam Control-C so I never noticed this)
Another interesting thing: because DF is a child of DFHack (after all, the dfhack script launches DF), this means that DFHack doesn't really exit when it's window is closed.
Very interesting.

EDIT6: Okay, so I got in a situation where:
* PyLNP is killed (using pkill PyLNP)
* DFHack's window is still alive
* DF is still alive
For now, a fix appears to be to manually pkill PyLNP, then manually restart it

[Pidgeot]

It sounds like I can't do anything about this, then. Sorry.

[kahrkunne]

It sounds like I can't do anything about this, then. Sorry.

Oh well, it can't be helped.
I'm not gonna keep trying to fix it either. I was fine with doing this much, but I'd rather not dive into the internals of your buggy software, I've got better things to do.
Can you at least solve the issue with autostart utilities not starting until DF exits?

[Pidgeot]

I was fine with doing this much, but I'd rather not dive into the internals of your buggy software, I've got better things to do.

I have told you repeatedly what the problem is and what is needed to fix it, and I have done everything I can to try and find a solution. Kindly back off the attitude.

Can you at least solve the issue with autostart utilities not starting until DF exits?

No, because they already do under normal circumstances. The problem is that your setup doesn't appear to provide any way of spawning an *independent terminal* from code, which is necessary if you want to use DFHack; it hijacks the existing one. There is literally nothing that can be done without that; Linux has no standardized way of doing this, and xdg-terminal is the closest thing there exists. This isn't just true for PyLNP, it is true for every GUI-based launcher that can possibly exist.

The command that your window manager provides to actually spawn a new terminal (i3-sensible-terminal) didn't work, as evidenced by the fact that it did not solve the problem. Now, I can't be sure if that's because i3 needs a slightly different command for that, or if it simply isn't supported - I don't use i3 myself, and I can't spend hours learning the intricacies of every esoteric window manager out there.

If you want a proper fix, do the legwork and talk to the i3 guys to find out how to actually make a shell script successfully spawn an independent terminal with a different command (it's your system; you're the only one who can find out what will work). Or use a DE that already works (there are several!). Or convince the DFHack guys to implement a custom window for their terminal so it no longer needs to be launched from one. Or turn off DFHack, because vanilla DF doesn't have this problem.

[kahrkunne]

I was fine with doing this much, but I'd rather not dive into the internals of your buggy software, I've got better things to do.

I have told you repeatedly what the problem is and what is needed to fix it, and I have done everything I can to try and find a solution. Kindly back off the attitude.

Can you at least solve the issue with autostart utilities not starting until DF exits?

No, because they already do under normal circumstances. The problem is that your setup doesn't appear to provide any way of spawning an *independent terminal* from code, which is necessary if you want to use DFHack; it hijacks the existing one. There is literally nothing that can be done without that; Linux has no standardized way of doing this, and xdg-terminal is the closest thing there exists. This isn't just true for PyLNP, it is true for every GUI-based launcher that can possibly exist.

The command that your window manager provides to actually spawn a new terminal (i3-sensible-terminal) didn't work, as evidenced by the fact that it did not solve the problem. Now, I can't be sure if that's because i3 needs a slightly different command for that, or if it simply isn't supported - I don't use i3 myself, and I can't spend hours learning the intricacies of every esoteric window manager out there.

If you want a proper fix, do the legwork and talk to the i3 guys to find out how to actually make a shell script successfully spawn an independent terminal with a different command (it's your system; you're the only one who can find out what will work). Or use a DE that already works (there are several!). Or convince the DFHack guys to implement a custom window for their terminal so it no longer needs to be launched from one. Or turn off DFHack, because vanilla DF doesn't have this problem.

Calm the heck down there mate
I don't know what your problem is, but you're pretty vicious.
I'd just like to let you know that I've spent several hours trying to debug your software and doing my best to provide all information relevant (and with pleasure - I'd love it if some of the bugfixes you applied will help you or someone else in the future!)
There is no need to get mad at me for literally nothing. I've written software myself, and I know how much it sucks if you don't know how to fix something, but that's no excuse to get mad at the one reporting bug reports.
Another thing: your software is buggy. It's not working as intended. It's intended to function properly on GNU/Linux systems and it doesn't, at least not for me. 'works on my machine' IS NEVER AN EXCUSE! You can't blame the people who use your software on your software not working by saying it works on your machine or it works under the "normal" circumstances. remember that there is no standard DE/WM on GNU/Linux and therefore there is no such thing as "the normal circumstances".
There is no shame in not being able to fix a bug in your software (yes, as long as it's something that's intended to work, yet doesn't work in your software (and that includes xdg-terminal because it's bundled with your software) it's a bug in your software). I can understand that you can't fix this bug without more extensive knowledge of i3 (although I'm not 100% sure it's an i3-specific issue), and nobody expects you to.
I, as a bug reported, am merely asking for help and trying to help you remove bugs from your software. I have no expectations of you, so don't act like I do.
Also, if you'd actually read my post properly, you'd see that I got everything to work with DFHack working (in fact DFHack had been working for a long time as I've said so in my posts, yet keeping the PyLNP window responsive was something that I had not been able to get to work, and killing the PyLNP window used to kill the DFHack terminal until I found a fix in that in my previous post
Furthermore, the issue with autostart applications not launching until DF is exited has absolutely nothing to do with DFHack, demonstrated by the fact that the issue still occurs when I run it without DFHack. This is probably not related to i3 at all and instead just another bug in your software.
Once again, nobody is accusing or blaming you for anything, nor does anyone have some expectations of you. In fact, I'm just glad you're providing this, and that you're actively trying to fix the bugs in your software and help me resolve my issues. So there's no need to get so damn defensive

So thank you for your help, I'll fix the other bugs in your software on my own, because you're clearly unwilling to help me any further.

[kahrkunne]

Also,
i3-msg exec 'nohup i3-sensible-terminal -e "$command"'
seems to work, will do further testing later.

Even better: just nohup urxvt -e "$command" should work as well.
As a general rule of thumb, I trust that 'nohup [terminal] -e [command]' will work on every linux system. (tested so far with multiple commands and both urxvt and xterm)

EDIT: no dice
I can confirm that running "nohup urxvt -e 'vim'" does spawn an independent terminal running vim, and the same works for multiple other commands, yet it does not work for dfhack (even when running dfhack manually).
Anyways, this appears to be a dfhack bug, and not a PyLNP bug, nor an i3 bug.

EDIT2: "urxvt -e './dfhack' & gives control back to the terminal, but makes it so that the terminal can't be closed (you have running jobs)
I can probably come up with some (perhaps hacky) way to 'disown' DFHack though, and then it'd work.

EDIT3:
urxvt -e './dfhack' &; disown %urxvt
It works. Should work on any linux distribution with urxvt installed.
Should also work with any other terminal.
There you go, a standard linux way of doing what you wanted to do. Will intergrate it with xdg-terminal and test it in a sec, but I see no reason why it wouldn't work.
It should have worked with nohup as well, but oh well, this works.

EDIT4:
All you have to do now is add a check in xdg-terminal to see if someone is using i3, then make it excecute 'i3-sensible-terminal -e "$command" &; disown %i3-sensible-terminal' (I tested that, it works)
A better, WM/DE independent method would be to get whatever terminal the user is using (using $TERM for example (take care not to just excecute $TERM, becuase in my case $TERM evaluates to rxvt-unicode-256color, as I'm using urxvt with 256 color support)) then just excecute '$TERMINAL -e "$command" &; disown %$TERMINAL'. Just default to xterm if you can't extract the terminal from somewhere (although keep in mind that some people don't have xterm installed (yes it's weird, but I myself ran a system without xterm for a long time)). Then you can get rid of all the DE-detecting code in there as well.

[kahrkunne]

Okay, fixed it.
Making xdg-terminal run

Spoiler (click to show/hide)

'i3-sensible-terminal -e "$command" &
disown %i3-sensible-termina

(substituting the newline for a ; caused an error to be spit out, but this is better practice anyways) works. It also fixes the autostart issue.

Well, that's it. Try to intergrate all bug fixes into some release and I'll test it for you.
Hope this helps someone!

[Pidgeot]

Calm the heck down there mate
I don't know what your problem is, but you're pretty vicious.

Here's my "problem":

I was fine with doing this much, but I'd rather not dive into the internals of your buggy software, I've got better things to do.

This sounds incredibly angry and condescending, at least to me.

Since that apparently wasn't how you intended your post to read, we clearly had a misunderstanding, and I apologize for that. If you're willing to forget that ever happened, then so am I.

there is no standard DE/WM on GNU/Linux and therefore there is no such thing as "the normal circumstances".

Correct; pretty much the only thing that's standard is the kernel and /bin/sh. That's more or less the problem.

I disagree, however, that there is no such thing as "normal" (or at least, that there is no such subset). KDE, GNOME, MATE, and xfce covers the vast majority of (non-server) Linux systems when combined, and last I checked, all of those *do* work.

Also,
i3-msg exec 'nohup i3-sensible-terminal -e "$command"'
seems to work, will do further testing later.

Even better: just nohup urxvt -e "$command" should work as well.
As a general rule of thumb, I trust that 'nohup [terminal] -e [command]' will work on every linux system. (tested so far with multiple commands and both urxvt and xterm)

By "work", do you mean "PyLNP doesn't freeze", or "DFHack continues to have a working terminal even when PyLNP is closed"? When I originally looked into this, it was not my impression that nohup could work as intended here (but it is possible that I didn't consider the combination of nohup and terminal executable).

Okay, fixed it.
Making xdg-terminal run

Spoiler (click to show/hide)

'i3-sensible-terminal -e "$command" &
disown %i3-sensible-termina

(substituting the newline for a ; caused an error to be spit out, but this is better practice anyways) works. It also fixes the autostart issue.

Well, that's it. Try to intergrate all bug fixes into some release and I'll test it for you.
Hope this helps someone!

Isn't disown a bash command? xdg-terminal is a /bin/sh script; I wouldn't expect disown to work at all unless you install bash as sh.

EDIT: Testing on a Mint VM, there is no disown command in the default shell (dash, which is also installed as sh), and while bash is certainly extremely common, I'm not sure if changing the script to require bash is a good idea. Nice thought, though.

[kahrkunne]

What is /bin/sh for you?
For me /bin/sh --version gives

Spoiler (click to show/hide)

GNU bash, version 4.3.30(1)-release (x86_64-unknown-linux-gnu)
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Clearly, /bin/sh is bash for me.
Doing some quick googling, turns out disown is a built-in of bash and ksh. But really, good luck finding a GNU/Linux system that doesn't have bash in it, and making PyLNP depend on bash in exchange for getting a DE/WM independent way of spawning an independent terminal seems like a small tradeoff for me.

While I agree with you that the majority of people use KDE/GNOME/MATE/XFCE/cinnamon/Unity/whatever, there is a fair amount of people that don't. Whether or not it's worth supporting the group that doesn't use any of those is a different question altogether, but by saying you support Linux you say that you also support people that have a different choice in DEs and WMs.

By 'work' I mean that:
* DFHack has an independent terminal that persists even when the terminal PyLNP was started from is closed
* The autostart utilities now work
* The "Close GUI on launch" option now works
* The GUI no longer stops working when DF closes
Basically, it solves all issues I found
EDIT: Okay, I found a peculiar bug: You know how I said that when you close the terminal PyLNP was started from, DFHack now attains it's own independent terminal? Apparently this is only when PyLNP has the "close GUI on launch" option turned on. That is, if you don't make the GUI close on launch, this fix doesn't work.

Also, try asking 100 DF-playing GNU/Linux users. If you can find even one that doesn't have bash, ksh or zsh installed, you win.

EDIT: 'nohup i3-sensible-terminal -e "$command" &' works. This removes the bash dependency and should work with dash as well.
EDIT2: Okay, the DFHack terminal closing when PyLNP is still open only occurs when pressing Control-C in the terminal PyLNP was run from, and not when normally exiting PyLNP (that is, by pressing the cross button (if you have one), using xkill or kill, or using the exit button or shortcut in PyLNP itself).
So really, this shouldn't be a problem to anyone, it's just a little gotcha.
EDIT3: using 'nohup i3-sensible-terminal -e "$command" > /dev/null &' instead should prevent nohup from creating a nohup.out file in the directory PyLNP was launched from. Testing shortly.
EDIT4: running xdg-terminal with dash instead of bash gives './xdg-terminal: 305: [: x: unexpected operator'.  I personally see nothing wrong with that line, and it keeps working for me, but I cannot say for sure if it will still work when ran under an environment that uses xfce.
EDIT5: can confirm that adding the '> /dev/null' part works and prevents nohup from creating an annoying nohup.out file.

[Pidgeot]

EDIT: 'nohup i3-sensible-terminal -e "$command" &' works. This removes the bash dependency and should work with dash as well.

Excellent! I have updated xdg-terminal to call that command if it detects i3 (which it does by seeing if $DESKTOP_STARTUP_ID starts with the string "i3/", since this appears to be doable). No other files have been changed, so if you want to double-check, it's probably easiest if you just downloaded it directly.

Also, the change only applies to i3 - I'll need to do some more testing on various systems before I'd feel confident in making it part of the standard fallback, and the next DF release (and by extension, the next PyLNP build) is a bit too close for that.

Thank you very much for your effort.