| <<<Back 1 day (to 2018/05/12) | 20180513 |
deadc0de | Hi there, I'm using mupdf on gentoo and been trying to get auto reloading with SIGHUP working, every time HUP is received by mupdf it shuts down though. Any ideas why? | 08:46.05 |
avih | deadc0de: doesn't SIGHUM mean the controlling terminal is closed, hence app started from that terminal should be closed too? | 08:54.04 |
| P* | 08:54.08 |
| i.e. that's basically a "kill" signal | 08:54.47 |
deadc0de | technically yes, but sending it directly to the process (kill -s SIGHUP <pid>) is meant to reload the PDF according to mupdf man page | 08:57.58 |
moolc | deadc0de: mupdf doesn't handle SIGHUP | 08:58.00 |
| deadc0de: (llpp does, maybe that's the source of confusion?) | 08:58.14 |
| and indeed SIGHUP is explicitly mentioned in mupdf's man page | 08:59.08 |
deadc0de | what's llp? | 08:59.12 |
moolc | yet the sources have no traces of HUP handling | 08:59.29 |
| deadc0de: PDF pager that uses mupdf as the rendering library - https://www.youtube.com/watch?v=qNszKpCUXhQ&list=PLLAukRknwSgFhpYsDKHY0oWpvV03Qj4AE | 09:00.09 |
| deadc0de: okay, it looks as if mupdf-x11 does handle SIGHUP, while mupdf-gl does not | 09:01.20 |
| and you are probably using the latter | 09:01.33 |
deadc0de | let me give that a go | 09:01.44 |
| that does seem to do the trick | 09:05.00 |
| might be worth putting that into the man page :) | 09:05.27 |
moolc | nah | 09:08.08 |
avih | moolc: how should an application differentiate SIGHUP which is supposed to kill it from one which should be interpreted as a custom command? | 09:08.12 |
moolc | avih: by saying - "I treat HUP as an external signal to do my own thing" somewhere in documentation | 09:08.51 |
| avih: and i guess your question is more meta... and i don't know the answer to it, sorry | 09:09.24 |
deadc0de | avih: you just register your own signal handler for SIGHUP and override the default behaviour | 09:09.46 |
avih | moolc: but wouldn't it get the signal when it should be closed regardless of its man page? and reloading instead of closing it an unexpected behavior, isn't it? | 09:09.51 |
moolc | avih: correct | 09:10.03 |
avih | i'd sort of understand if it was "reporposing" some signal with loosely related semantics, but specifically HUP sounds to me like a bad idea to ignore. | 09:11.17 |
| or reporpose | 09:11.34 |
| u* | 09:11.39 |
moolc | avih: it's actually quite common to re-purpose HUP for that (at least that's my impression) | 09:13.19 |
| after all i must have got that idea somewhere when doing it in my own thing | 09:13.39 |
avih | well.. i'm not familiar enough with the subject to discuss, but i'll take your word for it. though TBH i still find it weird. | 09:14.30 |
moolc | avih: https://en.wikipedia.org/wiki/SIGHUP | 09:15.01 |
avih | like, im my mind, this would cause the following behavior: 1. you run mupdf from a terminal. 2. you close the terminal, maybe expecting mupdf to close. 3. instead of closing, mupdf reloads the document. | 09:15.28 |
| yes, i did read it before i responded initially | 09:15.57 |
| (the wikipedia page) | 09:16.07 |
moolc | "This convention survives to this day in packages such as Apache and Sendmail." | 09:16.38 |
| i really don't want to argue with software experts that gave us Apache and Sendmail | 09:16.58 |
| even qmail uses sighup in the same fashion... | 09:18.00 |
| so there | 09:18.01 |
avih | you shouldn't, but you should notice these are typically daemons, so it's not unreasonable of them to treat HUP specially. and mupdf isn't, afaik | 09:18.02 |
| (not sure about qmail, pretty sure about the two formers) | 09:18.43 |
moolc | avih: for all intents and purposes those gui applications are daemons | 09:19.59 |
| (in this case they do not have(nor care about) controlling tty) | 09:20.20 |
avih | k, as i said, not familiar enough to discuss. thx. | 09:20.27 |
inflex | moolc, everything wokring very nicely now here with my modified mupdf. | 10:15.13 |
moolc | inflex: cool, congrats | 10:15.49 |
inflex | but a question; when there's multiple items returned from a page search, each item on the page is highlighted, is there a way to put an additional highlight on each one if you know the bbox? | 10:15.55 |
moolc | inflex: i have nothing to do with mupdf development. better ask tor or sebras | 10:16.44 |
inflex | okay np. | 10:16.50 |
| It's probably something I can do with GLUT | 10:17.00 |
| can mupdf-gl be built for Windows using mingw? | 16:53.27 |
| ( seems like adding "export CC=gcc" was the key | 17:13.19 |
| Forward 1 day (to 2018/05/14)>>> | |