| | <<<Back 1 day (to 2016/05/09) | 20160510 |
| tor8 | sebras: might it not make sense to check for %[0 | 09:47.34 |
| | %[0-9]*d and append a page number before the suffix if missing? | 09:47.51 |
| sebras | tor8: maybe, but then same should be done for mutool draw, right? | 09:49.14 |
| tor8 | sebras: yes. | 09:49.28 |
| sebras | tor8: oh, and would you like to error out on any other conversion specifier? | 09:49.48 |
| tor8 | so a helper function, fz_format_output_path() that only looks for %[0-9]d and ignores all other conversions maybe | 09:50.13 |
| | so fmt("foo.pdf", 5) would return "foo-5.pdf" and fmt("foo%3d.pdf", 5) "foo005.pdf" | 09:51.19 |
| | sebras: oh, and I'd take the occasion to move the PNG writing functions into output-png.c as well | 09:53.00 |
| | that can be a separate patch though | 09:53.23 |
| sebras | tor8: ok, then I'll make that as the first patch. | 09:56.24 |
| | tor8: also is there anything preventing any of the changes over at sebras/master from being merged? | 10:00.28 |
| tor8 | sebras: all LGTM. have you let Robin_Watts have a look at the assert commit? | 10:05.57 |
| Robin_Watts | looking... | 10:06.05 |
| sebras | tor8: oh, no. I forgot to ask robin. | 10:06.21 |
| Robin_Watts | That's a bad macro. | 10:06.43 |
| | You need to wrap it in do { ... } while (0) | 10:07.02 |
| | Otherwise if (foo) fz_assert(bar); else baz; will do strange things. | 10:07.34 |
| sebras | Robin_Watts: fixed (locally). do you like the approach at all? | 10:08.36 |
| Robin_Watts | Also, asserts get used in places where there may not be exception handling. | 10:08.37 |
| | I don't think I do, sorry. | 10:08.45 |
| | assert is used to mean "This condition is assumed to be true." | 10:09.12 |
| | If it's ever wrong, then it's a fatal error, it's not a continuable thing. | 10:09.28 |
| | And it's supposed to be 0 cost in release builds. | 10:09.52 |
| sebras | Robin_Watts: the reason for the patch was me and tor8 debating the assert() in fz_lookup_device_colorspace(). | 10:11.25 |
| Robin_Watts | I could see the argument that that should not be an assert. | 10:12.04 |
| sebras | Robin_Watts: this then led to discussing whether asserts() should be tied into the exception handling and be treated as fatal (but always checked). | 10:12.53 |
| Robin_Watts | That's a marvellously unused function of course... | 10:12.54 |
| | I'd say no. | 10:13.05 |
| sebras | Robin_Watts: I'm contemplating using it in the output stuf I'm working on, hence I found it. | 10:13.33 |
| Robin_Watts | assertable conditions are supposed to be true by construction. | 10:13.40 |
| tor8 | now I remember! that function was added at sumatrapdf's request. | 10:13.49 |
| Robin_Watts | hence they shouldn't *need* to be checked. | 10:13.50 |
| tor8 | way before we had fz_device_rgb(ctx) functions, and fz_device_rgb was a global variable | 10:14.07 |
| sebras | tor8: do they still use ite? | 10:14.20 |
| | tor8: I'll check. | 10:15.09 |
| tor8 | sebras: no. they hvaen't updated their mupdf in over a year. | 10:15.24 |
| sebras | tor8: :( | 10:15.35 |
| Robin_Watts | I'm not entirely averse to the idea of an fz_assert (that behaves like assert). | 10:16.59 |
| | Or to fz_checkcondition() that behaves like your current fz_assert. | 10:17.20 |
| | but costing us runtime for fz_assert, or using fz_assert to check stuff that is not true by construction is bad, IMAO. | 10:18.04 |
| sebras | Robin_Watts: right, but making it sensitive to NDEBUG would be trivial. | 10:18.29 |
| Robin_Watts | sebras: Making the current one sensitive to NDEBUG, sure. But then I don't want asserts to be thrown. The point of them is to stop where you are so you can debug what went wrong in the reasoning about the program. | 10:19.25 |
| sebras | Robin_Watts: tor8: ok so I found that sumatrapdf since may 17th 2013 (https://github.com/sumatrapdfreader/sumatrapdf/commit/c95e2c351823a50251c42d17d195c6b3cdd50745) no longer uses fz_lookup_device_colorspace() (used to be called fz_find_device_colorspace() if you want to search the commitdiff). so my proposal then is to remove fz_lookup_device_colorspace() from mupdf and also scrap the fz_assert() patch (since reimplementing assert() in an identical f | 10:24.08 |
| Robin_Watts | Sounds good to me. | 10:25.44 |
| sebras | Robin_Watts: alright. :) | 10:25.51 |
| | tor8: ? | 10:25.53 |
| | Robin_Watts: hm... since you know more about the win32 stuff than I do, what is libmupdf.def about and do we indeed keep that updated with the scripts/gen_libmupdf.def.py? | 10:27.06 |
| Robin_Watts | I know bugger all about libmupdf.def | 10:27.33 |
| | I can't even see such a thing. | 10:28.20 |
| sebras | Robin_Watts: ehm... ?-) /me noticed that he was still in the sumatrapdf repo. and no, they haven't kept it updated. | 10:28.21 |
| chrisl | IIRC, the def file contains the entry for a DLL | 10:28.37 |
| Robin_Watts | sebras: I think .def files may list the entry points.... for what chrisl said. | 10:28.49 |
| | so they need it cos they turn mupdf into a dll, we don't. | 10:29.05 |
| sebras | Robin_Watts: mmm, I should have realized. sorry for the noise. | 10:29.22 |
| Robin_Watts | no worries. | 10:29.27 |
| chrisl | Since the VS linker doesn't seem to support a --export-all equivalent option | 10:30.15 |
| tor8 | sebras: you have my permission to nuke (almost) all dead code that's not being actively used | 10:43.15 |
| Robin_Watts | Another job to think about, is to move as many of the private implementation details out of the include/mupdf/XXX/YYY.h headers into source/XXX/YYY-imp.h headers as possible. | 10:45.13 |
| sebras | Robin_Watts: would you accept a patch to gs making gitpush.sh executable? I'm having a symlink from ~/bin/gitpush.sh to ~/src/gs/toolbin/localcluster/gitpush.sh and it would be nice if it worked out of the box? | 10:53.08 |
| Robin_Watts | Sure. | 10:53.26 |
| sebras | Robin_Watts: similar to clusterpush.pl which is mode 755. | 10:53.27 |
| Robin_Watts | sebras though I find that: git config alias.cluster "sh gitpush.sh" works well :) | 10:54.02 |
| | (or something like that at least) | 10:54.12 |
| | Then I can just "git cluster" | 10:54.20 |
| | There probably needs to be a ! in there or something. | 10:54.36 |
| sebras | Robin_Watts: you told me to use git config alias.cluster "!gitpush.sh" I think. | 10:54.43 |
| | Robin_Watts: at least I have cluster = !gitpush.sh in ~/.gitconfig now | 10:54.57 |
| Robin_Watts | There might possibly be issues with trying to execute the script in place within your git dir. | 10:55.36 |
| | which is why mine is copied out. | 10:55.43 |
| sebras | Robin_Watts: !bash -C gitpush.sh does indeed work. | 10:59.18 |
| ferter | hi everyone! may i ask you a tiny little question? is there a way to sort of "rewind" a pdf_document? because at some point i'm trying to get display list in my app and it returns NULL. through debugging i found out, that i'm probably at the end of a document, as pdf_lex returns PDF_TOK_EOF | 15:49.56 |
| | don't want to bother you and ask, why is this happening | 15:50.29 |
| | just want to know | 15:50.34 |
| | if i can get back to the beginning of pdf_document or i should rework my logic? | 15:51.41 |
| | thank you in advance | 15:52.01 |
| Robin_Watts | ferter: What are you using? | 15:56.14 |
| ferter | mupdf | 15:56.24 |
| Robin_Watts | I don't understand why you should ever be at the PDF_TOK_EOF level. | 15:56.53 |
| | Why don't you explain from the start what you are doing, and how the problem arises. | 15:57.49 |
| ferter | well. i open a pdf document and then i generate a thumbnail for every page. in order to do so, i create a display list and annotation list for every page. this operation takes some time. and today i discovered a bug, - if i try to save document as i'm creating thumbnails, - they won't create. through debugging i found out, that the problem is, that i get to PDF_TOK_EOF level. i should mention that both creating thumbnail and sav | 16:05.34 |
| | perfectly* | 16:06.00 |
| Robin_Watts | ferter: So you are thumbnailing on a background thread? | 16:06.22 |
| ferter | yes | 16:06.43 |
| Robin_Watts | I refer you to the 3 rules of Multi-threading in docs/overview.txt | 16:07.05 |
| | Rule 2: No simultaneous calls to MuPDF in different threads are allowed to use the same document. | 16:07.28 |
| | ferter: You CAN still access the document in different threads, you just need to be careful. | 16:20.20 |
| ferter | Robin_Watts: ok thanks, i found out that i Do have problems with my mutex. thank tou | 16:42.22 |
| | you* | 16:42.26 |
| Robin_Watts | ferter: Fab. | 16:51.43 |
| rayjj | Robin_Watts: I am trying: draw -r1200 -o /dev/null -F pbm -c mono -A 0 -B 1200 -s tm -P ../testing/j9_acrobat.pdf | 19:36.41 |
| | Robin_Watts: it is hanging about 60% of the time | 19:37.06 |
| | it reports the 'fastest' and 'slowest' pages, then hangs | 19:37.31 |
| | Robin_Watts: I got it to hang in gdb (release build, so limited info), and it is in pthread_cond_wait from my_semaphore_wait, not surprisingly from mudraw_main | 20:39.37 |
| | Robin_Watts: ah ha. I got it to fail with a debug build (took 15 tries in gdb) | 21:00.45 |
| | #0 0x76f8b7a4 in __pthread_cond_wait (cond=0x12aad80 <bgprint+128>, mutex=0x12aad64 <bgprint+100>) at pthread_cond_wait.c:187 | 21:04.11 |
| | #1 0x00012c80 in my_semaphore_wait (sem=0x12aad60 <bgprint+96>) at source/tools/mudraw.c:204 | 21:04.12 |
| | #2 0x000177c4 in mudraw_main (argc=16, argv=0x7efff6c8) at source/tools/mudraw.c:1759 | 21:04.14 |
| | #3 0x000121b8 in main (argc=17, argv=0x7efff6c4) at source/tools/mutool.c:105 | 21:04.15 |
| | p *sem | 21:04.17 |
| | $4 = {count = 0, mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __kind = 0, __nusers = 1, {__spins = 0, __list = {__next = 0x0}}}, | 21:04.18 |
| | __size = '\000' <repeats 16 times>, "\001\000\000\000\000\000\000", __align = 0}, cond = {__data = {__lock = 0, __futex = 11, __total_seq = 6, | 21:04.20 |
| | __wakeup_seq = 5, __woken_seq = 5, __mutex = 0x12aad64 <bgprint+100>, __nwaiters = 2, __broadcast_seq = 0}, | 21:04.22 |
| | __size = "\000\000\000\000\v\000\000\000\006\000\000\000\000\000\000\000\005\000\000\000\000\000\000\000\005\000\000\000\000\000\000\000d\255*\001\002\000\000\000\000\000\000\000\000\000\000", __align = 47244640256}} | 21:04.23 |
| | (since I'm on pi3 via ssh, I can't stay in gdb, so I just captured it here -- sorry) | 21:05.00 |
| sebras | tor8 (for the logs): ok, so I bmpcmped everything on sebras/master and I'm seeing one (2?) regressions concerning bmp, but I can't reproduce it locally (yet). | 23:55.55 |
| | tor8: also I have a few patched in the works over at sebras/wip. opinions on fz_format_output_path() are welcome. I let the writers determine the format (out{-%0d.png,.pdf.cbz}) unless set explicitly and then I only care about %[0-9]d. I think that's good enough. | 23:58.28 |
| | especially if we use PATH_MAX for the buffer (and we already include limits.h so that should be safe). | 23:58.56 |
| | Forward 1 day (to 2016/05/11)>>> | |
IRC Logs