| | <<<Back 1 day (to 2017/10/02) | 20171003 |
| sebras | tor8: three small patches on sebras/master | 10:32.29 |
| tor8 | clang: error: unknown argument: '-no-pie' | 10:35.19 |
| | the first two LGTM | 10:35.30 |
| sebras | tor8: the -no-pie one is crucial to get any profiling out of gcc, apparently since 4.9 | 10:35.51 |
| | tor8: without it I still get a gmon.out, but gprof shows no data, presumably becasuse the symbols are gone..? I'm not sure. | 10:36.20 |
| tor8 | yeah. but it doesn't work with clang... (and presumably older versions of gcc either) | 10:36.37 |
| | gcc: error: unrecognized command line option '-no-pie' | 10:37.01 |
| sebras | that's what gcc? | 10:37.09 |
| tor8 | nor older versions of gcc :) | 10:37.10 |
| | gcc (Debian 4.9.2-10) 4.9.2 | 10:37.18 |
| sebras | it is recognized starting with gcc-5 onwards. | 10:38.20 |
| tor8 | that's too new :( | 10:39.03 |
| sebras | things like these make it really easy to seamlessly support multiple compilers. :-P | 10:39.04 |
| tor8 | rm -rf build=profile then :) | 10:39.12 |
| | I just use cachegrind anyway | 10:39.30 |
| | or 'perf top' | 10:39.40 |
| sebras | I used cachegrind too, but I wasn't keen on installing 300Mbyte of KDE just to visualize its data. | 10:39.55 |
| | so I figured I could use gprof for the same information, but of course I couldn't because something had changed. | 10:40.18 |
| tor8 | ...it broke because nobody uses gprof anymore, I reckon... | 10:40.47 |
| sebras | this was reported to gcc back in gcc-4.9 timeframe, but I guess they decided that it was important to do place independen executable linking and so you have to disable this optimization when doing gprof. | 10:41.54 |
| | at least that's what I think the flag is doing. :) | 10:42.12 |
| | before we rm -rf build=profile I should probably test all the other build variants. I assume that anything besides =debug and =release will be br0ken by this point. :-P | 10:43.01 |
| tor8 | =sanitize *should* work as well | 10:46.48 |
| | but yes, better test them all | 10:46.51 |
| | sebras: there are a handful of commits on tor/master for review (ignore the WIP ones) | 11:42.01 |
| sebras | tor8: ok. | 11:42.41 |
| tor8 | ah, I need to update the glfw submodule in that commit too | 11:43.05 |
| | and that reminds me I should contact the GLFW maintainer and see about the control key rework I want done | 11:43.25 |
| sebras | yes, | 11:43.51 |
| | do you mind asking about calling setlocale() too for input methods? | 11:44.04 |
| tor8 | maybe we should do that ourselves? | 11:44.15 |
| | I figure it's kind of bad form for libraries to call setlocale | 11:44.27 |
| sebras | I tend to agree, but then again they _do_ call setlocale() if X_HAVE_UTF8_STRING is not set. | 11:45.01 |
| | that define controls if Xutf8LookupString() is assumed present or not. | 11:45.35 |
| | tor8: but... pdf_widget_s was never defined!? so we only accessed it as a pointer?! | 11:48.59 |
| tor8 | yup. | 11:52.19 |
| | and casted it to pdf_annot whenever we needed to use it | 11:52.30 |
| LRN | i've noticed that mupdf doesn't have a dedicated API for determining whether a given file (or buffer) contains supported image. The only way to do that is to either rip the signature check code from mupdf, or to try to create an image from data and see if it fails | 13:47.00 |
| | (which is suboptimal, as there's no way to tell how much data it needs to succeed, so the safe way to do that is to pass it the whole file, which is expensive) | 13:47.36 |
| | (maybe it's possible to do it in a loop, giving it more and more data in each iteration, until it either succeeds, or fails with an "unknown format" error) | 13:48.21 |
| tor8 | LRN: if you have the file extension or mime-type you can check with fz_recognize_document | 13:54.08 |
| | there's no convenient way to check the magic signature. I believe you're talking about the image signature check in fz_new_image_from_buffer? | 13:56.02 |
| LRN | eys | 13:57.12 |
| | s/eys/yes/ | 13:57.16 |
| | do i understand correctly that do_compress_images opt only works for initially uncompressed images (which are then deflated) and on compressed images (which are just written in their already compressed form)? | 16:00.27 |
| | (i.e. mupdf won't do lossy recompression) | 16:01.28 |
| tor8 | we will not do lossy recompression, that is correct. | 16:25.19 |
| LRN | so, if i actually want lossy recompression, i have to do it myself. How? Get decompressed image pixels, compress them (using libjpeg or somesuch), and then give the result back to mupdf? | 16:31.16 |
| tor8 | LRN: yes. mupdf doesn't expose JPEG compression (only decompression) | 16:31.46 |
| LRN | okay | 16:34.29 |
| | Forward 1 day (to 2017/10/04)>>> | |
Log of #mupdf at irc.freenode.net.