| | <<<Back 1 day (to 2020/11/12) | Fwd 1 day (to 2020/11/14)>>> | 20201113 |
| artifexirc-bot | <Fred> @ator your fix for cjk fonts seems to work. | 01:47.46 |
| malc_ | /names | 07:51.44 |
| | sorry | 07:51.57 |
| artifexirc-bot | <ator> @fredrossperry There's a new commit for the CJK handling on tor/master. Could you please give that a try? | 11:33.33 |
| | <ator> "Fall back to system fonts in fz_new_cjk_font." | 11:34.09 |
| sebras | @ator LGTM "Remove Luratech from list of thirdparty modules." | 11:46.38 |
| malc_ | is so happy not to see all the disagreeing bot anymore yet know that people come from the web of evil | 11:48.10 |
| sebras | malc_: I'm actually using both discord and irc at the moment. | 11:48.36 |
| malc_ | sebras: yes i | 11:48.51 |
| | _KNOW_ | 11:48.55 |
| sebras | ator: LGTM "Fall back to system fonts in fz_new_cjk_font." | 11:49.26 |
| malc_ | sebras: and my immense elisp foo also allows me too know that ator posts from discord | 11:49.28 |
| sebras | ator: did you have a look at the my signature locking patch yesterday? | 11:49.54 |
| | ator: I'm hoping I'm taking the correct approach here. | 11:50.09 |
| ator | sebras: why split pdf_widget_is_locked and pdf_signature_is_locked? | 12:11.31 |
| malc_ | ator: is there any reason for you switching between irc/discord? [i gots to know: https://www.youtube.com/watch?v=xYgRVMxjLhc] | 12:18.10 |
| ator | malc_: just which window is currently in focus :D | 12:19.05 |
| malc_ | ator: hah :) | 12:20.21 |
| malc_ | is as relieved as the "punk" in the video, a lot less disappointed too | 12:20.50 |
| sebras | because I initially also write a pdf_signature_is_locked(), but theb found pdf_widget_is_signed() that calls pdf_signature_is_signed(). so I followed this pattern. | 12:44.15 |
| | Aw | 12:44.55 |
| | wrote.... then... | 12:45.07 |
| | ator: @ator ^^ | 12:47.03 |
| ator | sebras: ah, good enough explanation for me :) | 12:48.01 |
| | yeah, that stuff LGTM | 12:48.04 |
| sebras | ok, then I'll push in a bit and update my tests before pushing those too. | 12:49.04 |
| | ator: as expected half of my previous tests not fail with an error. | 13:31.33 |
| | ator: but I'm inclined to keep those tests anyway since they exercise the locking part. | 13:32.54 |
| ator | s/not/now/? | 13:32.57 |
| sebras | y | 13:33.02 |
| ator | add a widget.unlock() and extend the tests? | 13:33.30 |
| | doubt it's worth it though | 13:33.46 |
| sebras | well, do we want to support unlocking? | 13:34.33 |
| artifexirc-bot | <paulgardiner> I hadn't realised there was a concept of being locked that applies directly to a widget independently of being listed in a signature field's locked field's list. | 13:41.02 |
| | <paulgardiner> I hadn't realised there was a concept of being locked that applies directly to a widget, independently of being listed in a signature field's locked field's list. | 13:41.29 |
| | <Robin_Watts> Yeah. I'm kind of deep in something else at the moment, so reluctant to get dragged out of it, but I'm not really following how we could ever sensibly unlock stuff. | 13:48.06 |
| sebras | @ator do you mind looking at sebras:mupdf/signatures I think I've improved the signature tracing a bit more. | 15:06.10 |
| ator | sebras: s/signd/is_signed/ | 15:15.50 |
| sebras | that's the original name, but I'll rename it. | 15:17.13 |
| | ator: I probably messed up the strings. | 15:31.15 |
| | ator: but I'm not quite sure what happens wrt to escaping of apostophes and quotation marks. | 15:32.16 |
| malc_ | sebras: "wrt to"? | 15:36.06 |
| sebras | malc_: with respect to to! | 15:36.34 |
| malc_ | sebras: "to to" is how (small) people here describe trains with steam engines :) (chu-chu works to) | 15:38.14 |
| sebras | malc_: yeah, I know I made a typo. | 15:39.44 |
| | luckily it was here and not in the code. :) | 15:39.52 |
| malc_ | sebras: i don't think this qualifies as a typo though... thinko maybe | 15:40.45 |
| sebras | malc_: not-paying-attention-o. | 15:42.53 |
| | ator: in pdf_save_document() at line 3635 or so we have a check that amounts to if (doc->num_incremental_sections == 0) return; | 15:49.00 |
| | ator: that implies that mupdf-gl cannot save a file under a different name without something having changed in the document. | 15:49.22 |
| | ator: that makes no sense to me. | 15:49.28 |
| ator | sebras: huh. you're right. that seems broken. | 15:51.26 |
| | leftovers from the original assumption that incremental writes would always overwrite the original file... | 15:51.57 |
| Hi | Hello mupdf peeps | 16:05.51 |
| sebras | Hi: hello. | 16:06.15 |
| Hi | Just wanna say loving the product :) | 16:06.55 |
| | Keep up the good work! | 16:07.17 |
| sebras | Hi: we are, thank you! :) | 16:09.03 |
| | ator: since murun will always return 1 on exceptions, the trace script ought to return something else in case it fails. and preferably a unique value at each check of "errored". | 16:15.37 |
| | ator: doing that would limit us to 127 checks of errored due to the limitation of unique exit code values. do you think that will be a problem? | 16:16.27 |
| | ator: I'm betting that it only rarely will be a problem, but when it happens it might not be so obvious. | 16:16.53 |
| | exit(3) says it passes status & 0xff back to the parent, but status == 0x80 if the was a segfault (or was it another signal?). | 16:18.23 |
| | hm. maybe exit status == 128 + signal number is only true for bash? | 16:21.56 |
| artifexirc-bot | <Fred> @ator your new commit for the CJK handling on tor/master works as well. | 16:35.34 |
| sebras | @Robin_Watts how do you feel about the top commit here? http://git.ghostscript.com/?p=user/sebras/mupdf.git;a=shortlog;h=refs/heads/signatures | 16:39.08 |
| artifexirc-bot | <Robin_Watts> sebras: instead of errored++; how about get_next_error(&errored); ? | 16:40.53 |
| | <Robin_Watts> where errored stops incrementing (or wraps) when it hits 127 ? | 16:41.08 |
| | <Robin_Watts> sebras: instead of errored++; how about trace_next_error(&errored); ? | 16:41.32 |
| sebras | Robin_Watts: sure. | 16:41.40 |
| artifexirc-bot | <Robin_Watts> sebras: Otherwise seems great. thanks! | 16:41.56 |
| | <Robin_Watts> I'm not sure the cluster reports changed error codes though... | 16:42.24 |
| sebras | we print it out in the log. | 16:42.43 |
| | return: $? | 16:42.51 |
| artifexirc-bot | <Robin_Watts> Right. But the list of changed files only lists: | 16:43.43 |
| | <Robin_Watts> 1) files that have started to produce an error. | 16:43.52 |
| | <Robin_Watts> 2) files that have stopped producing an error. | 16:44.01 |
| | <Robin_Watts> 3) files that weren't producing an error and still aren't, but the md5 has changed. | 16:44.25 |
| | <Robin_Watts> It won't ever list files that used to produce an error and now produce a different one. | 16:44.44 |
| | <Robin_Watts> (though it will include that in the total of files that produced errors, which should ideally be 0.) | 16:45.04 |
| sebras | @Robin_Watts I guess I could make it part of the md5..? | 17:04.59 |
| | @Robbin_Watts: otherwise we will never detect if a file used to exit with 0 and now exits with something else? | 17:05.35 |
| | even before my patch. | 17:05.39 |
| artifexirc-bot | <Robin_Watts> It could, but it doesn't look at the md5s for erroring files. | 17:05.49 |
| | <Robin_Watts> No, that would be case 1). | 17:06.03 |
| sebras | ok, then it is not useful to check in a test case that we know will generate an exception, because we cannot differentiate that from one that erroreds out. | 17:07.49 |
| artifexirc-bot | <Robin_Watts> If a (file_gives_error && !file_errored_before) { print "hey, new error!" } else if (!file_gives_error && file_errored_before) { print "Hey, fixed error!" } else if (md5 != old_md5) { print "File diff!" } | 17:08.25 |
| | <Robin_Watts> @sebras Right. | 17:08.40 |
| | <Robin_Watts> None of the test scripts should generate an exception for the expected run. | 17:09.21 |
| | <Robin_Watts> presumably mutool run can catch exceptions and translate them to error exits? | 17:09.49 |
| sebras | having differentiated exit statuses does tell us _where_ it errored out though. | 17:21.17 |
| | @Robin_Watts try/catch/finally are implemented as far as I know. | 17:23.41 |
| artifexirc-bot | <Robin_Watts> @sebras Yes. Differentiated exit statuses are a good thing, I agree. | 17:24.46 |
| | <Robin_Watts> I'm just saying that they aren't quite the magic bullet you might hope for with the cluster. | 17:25.01 |
| | <Robin_Watts> Possibly, i could update the cluster to spot changed error statuses. | 17:25.23 |
| | <Robin_Watts> but that's not something for a friday evening, cos who knows what strange knock on effects it might have. | 17:25.47 |
| sebras | agreed. | 17:26.03 |
| | @Robin_Watts the rest of the commits on that branch attempt to validate more of the signatures in the trace files. | 17:27.57 |
| artifexirc-bot | <Robin_Watts> @sebras OK, so I'm having to read back a bit on that branch to understand stuff. | 17:31.28 |
| | <Robin_Watts> By "isLocked" you mean "isReadOnly" ? | 17:31.39 |
| sebras | yes, kind of. | 17:31.56 |
| | the spec says that when we are locking a signature field this means setting ReadOnly. since there are two different variants of ReadOnly, I lump them together and call that Locked. | 17:32.42 |
| artifexirc-bot | <Robin_Watts> ok. | 17:33.13 |
| sebras | as far as I have understood they are identical. | 17:33.18 |
| artifexirc-bot | <Robin_Watts> pdf_widget_is_locked() appears to assume that the widget is a signature. | 17:33.28 |
| sebras | so does pdf_widget_is_signed(). | 17:33.39 |
| artifexirc-bot | <Robin_Watts> Right, but pdf_signature_is_signed() checks for it being a Sig and gives 0 otherwise. | 17:34.47 |
| | <Robin_Watts> There is no such type check in pdf_signature_is_locked. | 17:36.43 |
| sebras | yeah, I'm adding it. | 17:36.53 |
| artifexirc-bot | <Robin_Watts> ah, cool. Then I'm happy 🙂 | 17:37.09 |
| sebras | that commit has already been pushed, so it will be a follow up commit. | 17:37.37 |
| | though if it is not a signature, I think the original code would return 0 anyway. | 17:38.14 |
| | unless they are ReadOnly for other reasons of course. | 17:38.28 |
| | ator also asked about the pdf_widget_is_locked vs pdf_signature_is_locked, by only response is that this is how it looked for pdf_widget_is_signed. | 17:38.59 |
| artifexirc-bot | <Robin_Watts> Presumably you'll squash the current fixup one in your tree? | 17:41.57 |
| sebras | after ator has reviewed it, yes. | 17:42.13 |
| | the fixup is only a conveninece for his reviewing (any review comment fixes goes there). | 17:42.34 |
| artifexirc-bot | <Robin_Watts> right. | 17:42.40 |
| | <Robin_Watts> The "Allow saving unchanged documents" one looks wrong to me... | 17:43.05 |
| sebras | git commit --fixup is your friend, along with git rebase --autosquash, but I never use the latter. :) | 17:43.23 |
| | @Robin_Watts: well, I can't save an unchanged document to a new filename in mupdf-gl. | 17:43.50 |
| | _that_ seems wrong to me. | 17:44.07 |
| artifexirc-bot | <Robin_Watts> I think in the first hunk you shouldn't remove the lines, you should move them to after ensure_initial_incremental_contents. | 17:44.09 |
| | <Robin_Watts> cos that fixes your issue by copying the original contents across, but doesn't then append a \n | 17:44.39 |
| sebras | doesn't append a \n? | 17:45.18 |
| | what does this mean? | 17:45.37 |
| artifexirc-bot | <Robin_Watts> If you look at do_pdf_save_document... | 17:45.56 |
| sebras | y | 17:46.06 |
| artifexirc-bot | <Robin_Watts> You are right, in that if the current code is called to save a document to a new document 'incrementally', the test will exit and nothing will be written. | 17:46.47 |
| | <Robin_Watts> But if you remove that test, and imagine what now happens... | 17:47.03 |
| | <Robin_Watts> ensure_incremental_contents copies the old file contents to the new file. | 17:47.27 |
| | <Robin_Watts> Then we seek to the end and output '\n'. | 17:47.38 |
| | <Robin_Watts> then the rest of the code doesn't actually write anything (I hope!) | 17:47.52 |
| | <Robin_Watts> so the net effect is that each time we save a document, like that, we're adding a '\n' to the end. | 17:48.11 |
| | <Robin_Watts> The correct thing to do, I think, is to move the ensure_incremental_contents() call to be just before the if (doc->num_incremental_sections == 0) call. | 17:48.47 |
| sebras | ah, yes. that's correct. | 17:48.56 |
| artifexirc-bot | <Robin_Watts> So, with that change, all those commits would lgtm. | 17:49.41 |
| sebras | @Robin_Watts the problem is that saving in mupdf-gl is based on pdf_save_document(), not do_pdf_save_document(). | 17:56.16 |
| artifexirc-bot | <Robin_Watts> pdf_save_document calls do_pdf_save_document | 17:56.32 |
| | <Robin_Watts> I agree with the fix to pdf_save_document that you have. | 17:57.23 |
| sebras | ah, then I misunderstood you! | 17:58.23 |
| | I thought you opposed both parts. | 17:58.28 |
| | sebras/signatures updated. | 17:59.14 |
| | I too much back and forth for fixup commits, sorry. :) | 17:59.42 |
| artifexirc-bot | <Robin_Watts> no problem. | 17:59.59 |
| sebras | forgot capping errored at 127. | 18:01.41 |
| | maybe it is only bash that treats signals and error codes that way? | 18:02.24 |
| artifexirc-bot | <Robin_Watts> @sebras I thought that was a unix thing. | 18:02.54 |
| | <Robin_Watts> rather than bash. | 18:02.59 |
| malc_ | Robin_Watts, sebras: i'm puzzled, what are you guys talking about (the 127 thing)? | 18:04.41 |
| sebras | malc_: yes. | 18:05.01 |
| artifexirc-bot | <Robin_Watts> return codes from programs in unix. My understanding is that we only actually get 7 bits worth. | 18:05.23 |
| | <Robin_Watts> 8 bits, according to T'internet. | 18:06.02 |
| malc_ | Robin_Watts: ah that | 18:06.08 |
| | sebras: nice answer.. | 18:06.43 |
| sebras | the WIFEXITED anf WIFSIGNALED macros seem to indicate that the exit status and the signal number are kept separate. | 18:07.07 |
| | so it might be that it is only bash that folds the signal number into the exit status. | 18:07.30 |
| artifexirc-bot | <Robin_Watts> @sebras Perl sticks them into a 16bit value, I think. (returncode<<8) | other thing | 18:09.01 |
| | <Robin_Watts> or something like that. | 18:09.06 |
| sebras | yes, that's what I'm seeing when looking at the macros that are supposed to be used by wait(). | 18:09.24 |
| | so maybe my patch should be limiting errored to 255 then. | 18:09.39 |
| malc_ | sebras, Robin_Watts: i believe this question can best be answered on #glibc or #musl not via web search | 18:10.00 |
| | ore even reading through C and/or SUS | 18:10.16 |
| sebras | but it is not unlikely that mutool run will run the trace file from a bash shell... :) | 18:10.17 |
| artifexirc-bot | <Robin_Watts> @sebras It will be bash in the cluster. | 18:11.25 |
| sebras | @Robin_Watts on my machine too. I don't think ator is running rc any more, so I think I can ignore what it does. :) | 18:12.20 |
| | agh! sebras: read the _entire_ paragraph in the spec before implementing things. :-P | 18:29.07 |
| | <<<Back 1 day (to 2020/11/12) | Forward 1 day (to 2020/11/14)>>> | |
Log of #mupdf at irc.freenode.net.