| | <<<Back 1 day (to 2017/06/27) | 20170628 |
| ray_laptop | Robin_Watts: cluster appears sick. My changes built, but then they just sit saying "Starting jobs" | 00:10.50 |
| | Robin_Watts: then Connection timed out, quitting: alarm | 00:11.29 |
| mvrhel_laptop | Robin_Watts: actually I was mistaken colors were correcct | 00:16.19 |
| | we are matching adob | 00:16.24 |
| | e | 00:16.26 |
| | ok . have go make dinner... | 00:16.33 |
| dabu | Hi, | 05:50.21 |
| | @Sebras: I'm very sorry for such a late reply, I was swamped in the last couple of days. I tested the commit 31a87a1da and it indeed compiles without errors. | 05:51.00 |
| tor8 | Robin_Watts: have you looked at bug 698102 | 08:43.30 |
| Robin_Watts | tor8: I have not, but it looks plausible. | 09:28.17 |
| | Let me look at that now. | 09:28.24 |
| | tor8: That's fixed in the current code already. | 09:30.03 |
| tor8 | okay. | 09:30.45 |
| sebras | dabu (for the logs): no worries, thank you for verifying the fix! :) | 11:33.09 |
| | tor8: you did notice that I reviewed part of your tor/master yesterday, right? | 12:38.29 |
| | tor8: oh, and of course I have a new set of patches on sebras/master today! :) | 12:38.40 |
| tor8 | yes, the FZ_MAX_SEPARATIONS is part of my header file rework | 12:41.56 |
| sebras | tor8: ok, but that patch is not completed yet..? | 13:04.35 |
| | tor8: since gproof still uses same define. | 13:04.57 |
| tor8 | no, I'm going to have to start over after the lcms branch. but it did trigger a bunch of cleanup commits that have gone in already. | 13:05.11 |
| sebras | tor8: yeah, the lcms branch caused a bit of grief (don't get me wrong, I'm happy we get better colors now!). :) | 13:15.07 |
| | tor8: can I trouble you with a review of sebras/master? | 13:37.50 |
| tor8 | sebras: ugh, nested fz_try in the same function in the HTML one :( | 13:41.46 |
| | sebras: the fz_hml and fz_pool are linked, dropping one drops the other | 13:44.13 |
| sebras | tor8: tor8 hm.. the inner fz_try() could be moved out to preceed the out fz_try() if I'm not mistaken. | 13:45.20 |
| tor8 | the g.pool alloc and try/catch drop_pool at the end was good as originally written | 13:46.04 |
| sebras | not if fz_pool_alloc throws, right? | 13:46.38 |
| tor8 | yes, I mean the commit named "Drop html object and its pool upon error." | 13:47.27 |
| sebras | so, I saw a leak here, but that was probably two weeks ago now, and who knows using what file. :-( | 13:47.32 |
| | yes, I know what commit you mean. | 13:47.54 |
| tor8 | in the commit before that, if fz_new_pool throws, we would leak the css, xml, and image tree | 13:48.11 |
| | so moving that into the try is good | 13:48.37 |
| | fz_html is a pool-allocated object, and the root fz_html struct holds a pointer to the pool that allocated it | 13:49.16 |
| | so when we drop the fz_html, it will drop the corresponding pool and free all memory for the html tree in one go | 13:49.31 |
| | and the other way is also true, dropping the pool will also free up all the html memory | 13:49.49 |
| | even if the original fz_html allocation failed | 13:50.00 |
| sebras | tor8: ah, so you're saying either can be freed, but at most one of them? | 13:50.47 |
| tor8 | yes. freeing both is going to end up in a double free. | 13:51.04 |
| sebras | tor8: and additionally that keep edf692d but throw away ddcace? | 13:51.08 |
| tor8 | rework edf69 to flatten the try-nesting and throw away ddcace | 13:51.46 |
| | 08b24ce7759f388ce9059dea987ba99f1ec0288a LGTM | 13:51.53 |
| | 4843aa82ec6ed1f6431870c364c2ca19d97ea3c2 LGTM | 13:52.18 |
| | d176fd7a7cb23c99e5d119ab2e0ff855ee867f4e LGTM | 13:52.29 |
| | bd499681dae7a1e9f208ef29a36a955d607b83de LGTM | 13:52.37 |
| | a7af445d0afac8818bb5d82f2129c4d0d4c94abb LGTM | 13:52.50 |
| | so, everything but the HTML commits and the filter chain which I haven't looked at yet | 13:53.12 |
| sebras | tor8: one question though... when we warn "ignoring styles due to errors:" what is it that prevents the css from being used? | 13:59.22 |
| | tor8: it seems to me that if e.g. fz_add_css_font_faces() then some css will still be used..? | 14:00.16 |
| tor8 | sebras: we ignore @font-face or font-family directives where we can't load the font | 14:03.27 |
| | sebras: but actual CSS parsing syntax errors cause us to ignore the whole stylesheet | 14:03.42 |
| | fz_add_css_font_faces never throws (it catches and warns with a different message: "cannot load font-face" | 14:04.47 |
| | if parse_stylesheet throws, I believe we insert rules as far as we managed to parse | 14:08.47 |
| sebras | oh, that happened at the end of fz_add_css_font_face(), I never noticed, just assumed it could throw. | 14:08.52 |
| | tor8: I assueme doing that is reasonable. | 14:09.36 |
| tor8 | the CSS struct is also pool allocated (fz_new_css has its own pool though, so not as many gotchas as the html parser) | 14:09.43 |
| sebras | tor8: ok, sebras/master has been updated now. | 14:42.20 |
| | tor8: oh, and do note that the pdf name thingy results in a new error as noted in my cluster run. | 14:43.10 |
| tor8 | sebras: the MSVR_176 missing range check.pdf file? | 14:58.13 |
| | that one failed before too, but with a different symptom | 14:58.20 |
| sebras | tor8: yes, and the file itself is bogus. | 14:59.15 |
| | tor8: previously we were able to do mutool show MSVR_176 grepable though. | 14:59.33 |
| | and now we can't. | 14:59.37 |
| | tor8: previously we managed to recover objects 4,6,7,8,9,12 and 13 as well as the trailer. | 15:00.56 |
| tor8 | sebras: yeah, but only because we parsed an obviously bogus /name (that is 64k long and ran into the lexbuf hard limit) | 15:02.33 |
| sebras | ok, so that means I get a final LGTM on everything on sebras/master? | 15:04.01 |
| | I have flattened the try-thingies in the last commit. | 15:12.08 |
| tor8 | sebras: will review again after dinner | 15:13.15 |
| | I think the long name thing could be improved though | 15:13.28 |
| | e = s + min(127, lb->size) at the top | 15:13.44 |
| | now we only trigger the error if the lexbuf runs out of space | 15:13.55 |
| sebras | ah, true! | 15:14.02 |
| | also I don't know what numbers of lb->size pdf_lexbuf_grow() will cause. | 15:17.07 |
| | if we enter lex_name() with lb->size == 10 e.g. and then it grows a few times and the next to last time it grows to ... | 15:17.54 |
| | never mind. | 15:17.57 |
| | if I just cap e after growing it will work. | 15:18.13 |
| | tor8: ok, sebras/master updated with a new patch. | 15:23.17 |
| | tor8: hm... we end up in "cannot parse object (%d %d R) - ignoring rest of file", when parsing Bug694429.pdf | 17:07.47 |
| | tor8: if we can't parse the object at the current position, would it be possible to advance a bit (a byte? a few bytes?) and try again? | 17:08.27 |
| Robin_Watts | sebras: urgh... | 17:17.38 |
| sebras | Robin_Watts: I know, for a large broken file that would be...a long wait. | 17:19.11 |
| Robin_Watts | sebras: I'm just not convinced it would ever really help. | 17:19.31 |
| | and it might interfere with the 'just in time' repair stuff. | 17:19.59 |
| | and the 'progressive mode' stuff. | 17:20.04 |
| sebras | Robin_Watts: in this particular case we would likely find more objects that might possibly allow us to draw a page. | 17:20.16 |
| | progressive mode is...? | 17:20.35 |
| Robin_Watts | FZ_ERROR_TRYLATER | 17:20.41 |
| sebras | linear pdf? is that what you meant? | 17:20.43 |
| | ah. | 17:20.58 |
| | what I'm referring to is the just in time repair stuff, is it not? | 17:21.27 |
| Robin_Watts | oh, you're hitting this error while repairing. gotcha. | 17:21.55 |
| sebras | yes, and the question is how hard we should try. | 17:22.09 |
| | Robin_Watts: previously, because we accepted arbitrarily large names we might have handled Bug694429.pdf gracefully | 17:22.42 |
| | Robin_Watts: but now we don't because the object with the large /Name fails to parse and then the entire document is discarded (because the page tree does not preceed the bogus object) | 17:23.20 |
| Robin_Watts | sebras: You could try skipping until the end 'endobj' and starting again from there. | 17:23.57 |
| sebras | Robin_Watts: btw, in fz_drop_colorspace_context() there's a FIXME about dropping(?) bgr but in fz_set_cmm_engine() it is simply dropped. wouldn't this indicate that it should just be dropped at the FIXME? | 17:24.16 |
| | Robin_Watts: that's not a bad idea actually! | 17:24.28 |
| Robin_Watts | sebras: had to happen eventually. | 17:24.39 |
| | I think that fixme is addressed in the next commit I am preparing. | 17:25.11 |
| sebras | Robin_Watts: oh and if fz_set_cmm_engine() is called with an engine the icc colorspaces are never really dropped in fz_drop_colorspace_context(). | 17:25.19 |
| Robin_Watts | But I have my SOT hat on today. | 17:25.19 |
| sebras | Robin_Watts: ok. | 17:25.27 |
| Robin_Watts | sebras: really? | 17:25.39 |
| | If fz_set_cmm_engine doesn't change the engine, we just leave, and the colorspaces stay in place. | 17:26.36 |
| | If it does change, we drop 'em all, then set the engine, then reload 'em all. | 17:26.58 |
| sebras | ctx = fz_new_context((showmemory == 0 ? NULL : &alloc_ctx), locks, (lowmemory ? 1 : FZ_STORE_DEFAULT)); | 17:27.37 |
| | followed by: | 17:27.40 |
| | fz_drop_context(ctx); | 17:27.43 |
| | immediately after | 17:27.50 |
| | and then exit(1) in mudraw has both valgrind and ASAN detect leaks. | 17:28.03 |
| | oh, because the fz_new_icc_colorspace() flas is_static is set. | 17:31.54 |
| | this means that fz_drop_colorspace_imp() is never called for these colorspaces, nor is free_icc(). | 17:34.22 |
| | I guess this is because fz_device_rgb() will always return a borrowed reference from the previously static object. | 17:35.28 |
| | fixed it. | 17:53.46 |
| | that fix is now on sebra/master along with a three more that I fished out of sebras/wip\ | 18:02.36 |
| | they cluster well apart from the /Name regressions I mentioned before. | 18:02.56 |
| | please have a look. | 18:03.00 |
| sebras | sleeps. | 18:03.05 |
| sphalerite | Hi all, I'm doing a presentation (which I have in pdf format) and was hoping to be able to have the next slide (page) of it visible on my laptop's monitor while projecting the current one. Can I do this with mupdf-x11? | 19:06.18 |
| Robin_Watts | nope. | 19:33.39 |
| | At least, not without running 2 copies of it :) | 19:33.54 |
| sphalerite | aww | 19:34.55 |
| | Is there a way to remote-control mupdf-x11 (using a fifo or something) besides injecting X events? | 19:35.31 |
| | (if not I'm going to try hacking it in) | 19:35.44 |
| | Also, if anyone else uses mupdf for presentations and enjoys terrible terrible hacks involing HTTP and bash, you may be like this 95-line monstrosity https://github.com/lheckemann/presremote | 19:37.03 |
| Robin_Watts | sphalerite: It's the easiest program in the world to hack. | 19:47.52 |
| | adding a remote control would be dead simple. Submit us a patch, and we'll consider it. | 19:48.16 |
| sphalerite | Sweet | 19:48.41 |
| | Robin_Watts: that was indeed incredibly easy | 20:06.03 |
| | Got it all working nicely now. Where do patches go? | 20:25.52 |
| ray_laptop | sphalerite: you will need to complete the agreement for us to be able to distribute the patch -- http://bugs.ghostscript.com/attachment.cgi?id=9346 then the easiest way is to open an enhancement bug and attach the patch | 20:32.04 |
| sphalerite | eeeh, never mind then. It's a fairly trivial change anyway (just reading on stdin and feeding it into onkey), 5 lines or something | 20:34.34 |
| ray_laptop | sphalerite: well, you are welcome to go ahead and put the patch against the bug -- other GPL users can pull it in. It's just that we can't include it in the standard distribution without the agreement | 20:36.00 |
| | or you can just post a link to the patch here and when people search the logs (google or whatever) they can find it | 20:36.52 |
| sphalerite | https://gist.github.com/lheckemann/932aaec17b0c0c3a84ab3cf52d11c567 | 20:43.31 |
| mvrhel_laptop | Robin_Watts; Finally tracked down the color issue I was running into | 23:55.35 |
| | it was from when you refactored a few things I had written | 23:55.47 |
| | Now the color space blending seems to be working correctly | 23:57.54 |
| | Going to do a cluster push to see what comes up | 23:58.14 |
| | Forward 1 day (to 2017/06/29)>>> | |
Log of #mupdf at irc.freenode.net.