Log of #mupdf at irc.freenode.net.

Search:
 <<<Back 1 day (to 2021/07/21)Fwd 1 day (to 2021/07/23)>>>20210722 
artifexirc-bot <sam_> hi all, is 1.18.1 an official release?03:19.55 
  <sam_> in e.g. 1.18.1-so-3.11.14, what's the latter part? -so-*?03:20.09 
  <sam_> is it a pre/post release patch?03:20.14 
  <malc> Lucas-C: (for the logs, i guess) llpp works (natively) under macOS. given that llpp uses mupdf to render PDFs undying dusk works fine with llpp (with undecumented -dcf (dimension cache "hack") it even starts much faster than competition)..06:31.48 
  <Robin_Watts> sam_: 1.18.1 is an official release.09:08.45 
  <Robin_Watts> 1.18.1-so-3.11.14 is a tweaked release we did for smart office 3.11.14, which uses MuPDF internally.09:09.17 
  <Robin_Watts> 1.19.0 should be around 'soon'.09:09.24 
  <paulgardiner> @Robin_Watts @sebras form filling is almost entirely working now. There's still a problem with formatting and verification, which I don't quite yet understand the nature of.10:45.07 
  <Robin_Watts> Fantastic.10:45.21 
  <Robin_Watts> Can you point me at a file that shows the problem?10:45.33 
  <sebras> See *sotech10:51.12 
  <sebras> There is a bug silver reported that Fred mentioned10:51.39 
  <sebras> The file form-05.pdf has the issue10:51.54 
  <sebras> I've been trying to build a test case to reproduce this10:52.17 
  <sebras> I can see that annotations other than the one being edited get JavaScript events triggered10:52.48 
  <sebras> Basically this means that they send alert events because the text contents of those annotations do not adhere to the validation requirements of the fields10:53.11 
  <sebras> The moreover most fields are flagged for updates when the single text field is having its contents changed10:53.44 
  <sebras> Also murun is lacking a number of interfaces to test this behavior10:54.24 
  <sebras> @Robin_Watts this bug: https://bugs.ghostscript.com/show_bug.cgi?id=70407810:57.27 
  <Robin_Watts> Ta.10:57.31 
  <paulgardiner> I'll chip in with more, if I can, when I understand what's happening better. In the AppKits, we purposely turn off these events during the typing into the field, and then turn them back on for the last update. It looks almost like the sense of the flag has become reversed.11:02.05 
  <Robin_Watts> @sebras So, when I load form-05.pdf into mupdf-gl, I see a warning thrown instantly, within doc_calculateNow.11:12.56 
  <Robin_Watts> I am unfamiliar with the workings of mujs. This might be one for @ator ?11:14.56 
  <Robin_Watts> It looks to me that the only fields that validate in form-05.pdf are the phone number fields. HPhone1, WPhone1, CPhone1 and "Mask2".11:18.38 
  <Robin_Watts> OK, Mask2, confusingly, looks like the SSN field.11:22.37 
  <paulgardiner> Warnings on opening is something we've possibly been seeing for a few months. I have a possibly unreliable recollection of there being some special casing - not to run the verification for the empty string, so always permitting the case of the field not having been filled in. Perhaps that special casing, if it ever existed, has been removed.11:22.43 
  <Robin_Watts> Fred claims that he sees warnings from this file on opening. MuPDF-gl certainly does not show me any trace for that. Neither do I see validation called for stuff on opening.11:23.28 
  <Robin_Watts> @paulgardiner are you seeing warnings on opening form-05.pdf ?11:23.39 
  <ator> I'm seeing the warnings11:24.01 
  <Robin_Watts> @ator How, and with what file?11:24.14 
  <ator> with form-05.pdf11:24.23 
  <ator> it's throwing an error because GetFieldValue calls this.getField() which returns null11:24.46 
  <ator> and then it tries to use the null value as an object11:24.58 
  <Robin_Watts> This is: warning: TypeError: cannot convert null to object11:25.14 
  <Robin_Watts> at GetFieldValue (24:20)11:25.14 
  <Robin_Watts> at 116/AA/C/JS:111:25.15 
  <Robin_Watts> at Doc.calculateNow (native)11:25.16 
  <Robin_Watts> at 24:1411:25.18 
  <Robin_Watts> ?11:25.19 
  <ator> yeah.11:25.20 
  <sebras> To see the issue you need to enable document JavaScript11:25.26 
  <sebras> And register a JavaScript event callback11:25.43 
  <Robin_Watts> I *thought* (but I could be wrong) that that is a different problem to what paul/fred are complaining about.11:25.59 
  <sebras> This callback will be called at times when it should not be11:26.02 
  <sebras> Oh no apparently there were more messages in the history that I hadn't read yet silly discord hiding them from me11:26.32 
  <ator> I added some printf debugging and it can't find a field named "Female" in that file11:26.38 
  <ator> no idea if that is relevant to anything else, just saw that sebras mentioned javascript errors and figured I'd investigate11:26.56 
  <paulgardiner> TestFormSigned.pdf issues a warning for a date on opening (the file I created for the testing of signatures locking fields)11:27.03 
  <Robin_Watts> mupdf-gl calls pdf_enable_js already.11:27.06 
  <paulgardiner> TestFormSigned.pdf issues a warning for a date on opening (the file I created for the testing of signatures locking fields) - in the AppKit that is11:27.30 
  <sebras> I'm not sure if MuPDF gl has registered a JavaScript event callback11:27.46 
  <sebras> But apparently that is at least what Fred is using11:27.53 
  <Robin_Watts> I'm breakpointing in the stuff that runs the js, so that should get hit regardless of there being a callback, I think.11:28.24 
  <Robin_Watts> @paulgardiner Where can I get that file please?11:28.35 
  <paulgardiner> https://cdn.discordapp.com/attachments/770685907279282196/867729915964293120/TestFormExpensesSigned.pdf11:28.53 
  <ator> however, that form script just seems broken, there is no field with that name in the document11:29.05 
  <ator> the closest is the /AP/D << /female 34 0 R /Off 33 0 R >> appearance state (but lowercase and definitely not the field name)11:30.27 
  <paulgardiner> We could possibly have a combinations of some files that have always produced alerts, should do and we've only just noticed, plus other files that shouldn't and do now.11:30.32 
  <sebras> @ator I doubt that the GetFieldValue warning is related to the issue paul mention.11:32.39 
  <sebras> @ator I would expect that it has been there since forever.11:32.59 
  <ator> @sebras yeah, seems completely unrelated. this is just in document 'recalc' callback and must've been there since forever11:33.56 
  <paulgardiner> I see results as though I'm calling pdf_set_widget_editing_state with random values. I don't think I am doing so.11:35.06 
  <Robin_Watts> Just to avoid running down a blind alley... to register for javascript events, I want to use pdf_set_doc_event_callback ?11:35.10 
  <sebras> @ator I got myself into trouble in murun though when trying to implement event callbacks in javascript: http://git.ghostscript.com/?p=user/sebras/mupdf.git;a=commitdiff;h=1c9e17b8b8c3317afe84dd4355ce99866fd1d73711:35.22 
  <sebras> @Robin_Watts yes11:35.41 
  <sebras> @Robin_Watts like for the JNI callback: http://git.ghostscript.com/?p=user/sebras/mupdf.git;a=blob;f=platform/java/jni/pdfdocument.c;h=493fd95c1d6e10341eafa6968dd36ddf0745b072;hb=1c9e17b8b8c3317afe84dd4355ce99866fd1d737#l311:37.01 
  <sebras> @ator what I want to accomplish is something like this:11:37.37 
  <sebras> var alerts = [];11:37.39 
  <sebras> var eventListener = {11:37.40 
  <sebras> onAlert: function(message) {11:37.41 
  <sebras> print('eventlistener.alert(' + message + ')');11:37.43 
  <sebras> alerts.push(message);11:37.44 
  <sebras> },11:37.45 
  <sebras> };11:37.46 
  <sebras> 11:37.48 
  <sebras> doc.enableJS();11:37.49 
  <sebras> doc.setEventListener(eventListener);11:37.50 
  <sebras> @ator and then I should be able to collect and validate the alerts emanating from mupdf after each call.11:38.06 
  <sebras> @ator and then I should be able to collect and validate the alerts emanating from mupdf after each widget modification.11:38.16 
  <Robin_Watts> right.11:39.13 
  <Robin_Watts> I shall attempt to attack this from mupdf-gl in C.11:39.24 
  <sebras> @paulgardiner what I have seen is that that validation alerts from the widget being edited are indeed suppressed, but validation alerts from _other_ widgets get triggered. not only that, but pdf_update_annot() returns TRUE not only for the text field I'm editing, but also the _other_ widgets. I assume this is also an issue.11:39.29 
  <sebras> that's fine for solving the bug, I need to be able to test this programmatically.11:39.59 
  <Robin_Watts> Absolutely.11:40.11 
  <sebras> that's fine for solving the bug, I need to be able to test this programmatically since that's also been requested.11:40.14 
  <ator> well, if the form js touches other widgets as part of recalculation etc that would be expected?11:40.29 
  <paulgardiner> It is sometimes intended and important that pdf_update_annot returns true for annotations other than that which is edited.11:40.41 
  <sebras> @ator even if ignore_trigger_events is set?11:41.04 
  <ator> no, if ignore_trigger_events is set we shouldn't be running any of the form scripts11:41.37 
  <paulgardiner> I'm surprised we get alerts from other fields in the inhibited state. I don't think that's intended. I haven't seen symptoms of that in the past11:42.21 
  <sebras> @ator I am setting ignore_trigger_events.11:42.31 
  <sebras> @ator I am setting ignore_trigger_events as is paul.11:42.37 
  <Robin_Watts> ok, so when we load the annots, we now run an update_annot pass to synthesise appearances for those that need it. That calls pdf_write_appearance, which then calls pdf_field_event_format, which calls the validation.11:43.10 
  <Robin_Watts> I'm guessing that previously, when we weren't synthesising on loading, you'd not have got those validations.11:43.36 
  <ator> @sebras use js_setregistry/getregistry or js_ref/unref to stash the event listener object11:43.48 
  <ator> in the callback data11:43.57 
  <ator> listener = js_ref(J, -1); js_getregistry(J, listener)11:44.53 
  <Robin_Watts> Should we perhaps nobble pdf_write_appearance not to trigger validation on empty values ?11:45.23 
  <ator> why does pdf_write_appearance trigger validation?11:45.45 
  <ator> it should only be running the formatting callback, not validation11:46.23 
  <paulgardiner> The other thing I think I'm seeing is a lack of formatting when I eventually reenable trigger events... but I am struggling to understand what I'm seeing. I'm looking for a good test file.11:46.59 
  <sebras> @ator pdf_update_appearance() calls pdf_write_appearance() calls pdf_write_widget_appearance() calls pdf_field_event_format() calls pdf_execute_js_action()11:47.01 
  <ator> @sebras that's formatting not validation11:47.26 
  <Robin_Watts> pdf_field_event_format is triggering the callback.11:47.27 
  <ator> different callbacks11:47.31 
  <ator> is it just me or does the pdf_field_event_format function look buggy?11:48.30 
  <sebras> @ator https://pastebin.com/raw/3niikEj511:48.36 
  <ator> it checks if AA/K/JS exists and then runs AA/F/JS11:48.41 
  <ator> the other functions check and run the same path...11:48.52 
  <Robin_Watts> pdf_field_event_format is returning me a message: The date/time entered () does not match the format (m/d/yy) of the field [ Date2 ]"11:49.24 
  <ator> like 2071 has a different path from line 207611:49.25 
  <Robin_Watts> Well, that'd do it 🙂11:49.31 
  <sebras> @ator looks buggy.11:49.34 
  <ator> copy pasta error11:49.42 
  <Robin_Watts> K is keystroke.11:50.14 
  <Robin_Watts> F is format.11:50.16 
  <ator> yeah11:50.19 
  <ator> and V is validation11:50.22 
  <Robin_Watts> So it's checking the wrong thing, but running the right one, so we'll still get the same callbacks.11:50.35 
  <sebras> changing it resolves the alerts.11:50.38 
  <Robin_Watts> ?!?11:50.50 
  <ator> could it be trying to run something that doesn't exist?11:50.59 
  <ator> that's certainly throw errors11:51.07 
  <Robin_Watts> Right, I follow, was reading the code wrong.11:51.30 
  <paulgardiner> In iOS at least, we cannot handle keystroke: the input system cannot cope with what is typed being altered on a key-by-key basis, hence the inhibiting while the field is typed into.11:55.17 
  <Robin_Watts> So... https://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=890fb4f4f51740d82c6494c8aa2fe3971c0b53e6 ?11:55.58 
  <sebras> @Robin_Watts LGTM.11:57.17 
  <Robin_Watts> pushed.11:57.58 
  <Robin_Watts> So, @sebras is presumably going to continue with his js tweaks so he can test that from scripts? But the actual bug is fixed, so @paulgardiner and @fredrossperry can retest?12:00.14 
artifexirc-bot <Robin_Watts> will scuttle back to GS unless there are other problems to look into.12:00.41 
  <paulgardiner> Will do12:00.42 
  <Robin_Watts> If anything else crops up, please call me back!12:01.03 
  <sebras> @ator in pdf_js_event_value() if fz_strdup() throws, won't we forget to js_pop()?12:37.00 
  <sebras> and is that a problem?12:37.30 
  <sebras> I stumbled upon a leak that I fixed: http://git.ghostscript.com/?p=user/sebras/mupdf.git;a=commitdiff;h=9b2fbb2447b9de2a5b8537c99c19b4a09ddd146c12:41.01 
  <ator> @sebras could be a minor problem yes, in that we'd run out of JS stack space eventually12:48.25 
  <ator> LGTM12:48.42 
  <sebras> interleaving the error handling systems of two languages are a PITA.12:48.50 
  <sebras> interleaving the error handling systems of two languages is a PITA.12:49.01 
  <ator> now add JNI and java to the mix :P12:49.05 
  <sebras> 🙂12:49.26 
  <sebras> @Robin_Watts http://git.ghostscript.com/?p=user/sebras/mupdf.git;a=commitdiff;h=df53633bb63f9c9e3f98b1dbd349cf3f70df1a65 we should never call pdf_field_value() directly as far as I can tell.12:56.10 
  <sebras> @ator thanks to the callback example you put on mujs.com I think I managed to get something that works and13:00.06 
  <sebras> @ator thanks to the callback example you put on mujs.com I think I managed to get something that works (and doesn;'t leak!) on sebras/bug-70407813:00.26 
  <sebras> can i ask for another review?13:00.36 
  <ator> @sebras hm, setting the callback data has no real destructor does it?13:03.35 
  <sebras> no.13:03.43 
  <ator> (not that it really matters)13:03.44 
  <sebras> hm. getregistry and hasproperty maybe should be in the other order.13:04.04 
  <sebras> no, scratch that. I stand by my commit as I've pushed it (it works, and I'm easily confused by the js stack 🙂 )13:05.24 
  <ator> js_hasproperty has a weird index (2)13:05.34 
  <sebras> that's what I thought too, but it works and I don't know what it shoudl be.13:05.56 
  <ator> js_getregistry(J, listener); if (js_hasproperty(J, -1, "onAlert")) ...13:05.56 
  <ator> getregistry looks up listener in the registry table, pushes the value to the top of the stack13:06.12 
  <ator> that's the 'listener' object you added with setEventListener13:06.27 
  <ator> so you want to see if that object has an onAlert property, so you look at the object on the top of the stack13:06.41 
  <ator> passing (2) probably works because it happens to be in stack slot 2 at the time13:07.05 
  <sebras> on https://mujs.com/examples.html in "Callbacks from C to JS" you are pushing null. why?13:07.15 
  <sebras> I do that too, but I don't understand why.13:07.42 
  <ator> pushnull in that example is the 'this' value13:07.50 
  <sebras> right.13:08.00 
  <ator> js_call expects the following on the stack: <function-object> <this-value> <arg-1> <arg-2> etc13:08.11 
  <ator> if there is no 'this' value, then it should be null13:08.41 
  <sebras> I can't see that I have a suitable 'this' value here, so null should be reasonable.13:09.06 
  <ator> then depending on the value of 'use strict' the "this" keyword will either evaluate to 'null' or find the global object13:09.14 
  <ator> yes. the 'this' value should only be set if you're doing the equivalent of "foo.bar()" in which case it should be set to "foo"13:09.38 
  <sebras> fixup commit pushed.13:10.22 
  <ator> LGTM13:11.09 
  <sebras> @ator let me DM you a link.13:12.11 
  <sebras> @ator when I run trace{1,2,3}.js there they run without exceptions.13:12.58 
  <sebras> as does trace4.js13:13.16 
  <sebras> the problem I think with trace4.js is that the fifth time I call update_page() to update all annotations and widgets it indicates that not only the date field being edited is updated but a whole slew of fields.13:14.20 
  <sebras> running mutool show form-05.pdf pages.1.Annots.*.AA | grep -v null indicates that there is a single calculate field so if the date field being edited and this recalculated field was updated I would get it.13:16.32 
  <sebras> I can't see a reason why all these fields should be updated, can you?13:17.42 
  <sebras> I'm thinking it might be a bug related to the recent annotation/localxref/action bugs we've fixed the last few days.13:17.44 
  <Robin_Watts> lgtm.13:32.08 
  <Robin_Watts> That reminds me of a random thought I had...13:32.19 
  <Robin_Watts> We have various functions (pdf_field_value is now one) that can't be static because they are used internally between different .c functions, but that aren't really part of the API.13:32.58 
  <Robin_Watts> I was wondering if we needed a naming convention to make that clear?13:33.14 
  <Robin_Watts> __pdf_field_value or something ?13:33.23 
  <sebras> aren't initial double underscores reserved for the compile?13:33.53 
  <sebras> aren't initial double underscores reserved for the compiler/linker?13:34.03 
  <Robin_Watts> I thought that was single underscores?13:34.08 
  <Robin_Watts> hence why I did doubl.e13:34.15 
  <Robin_Watts> hence why I did double.13:34.18 
  <Robin_Watts> No, you're right.13:34.44 
  <Robin_Watts> __ or _<UPPERCASE> are reserved for om,plementation.13:35.05 
  <Robin_Watts> __ or _<UPPERCASE> are reserved for the implementation.13:35.12 
  <Robin_Watts> so _pdf then ?13:35.17 
  <clam_> Robin_Watts: leading __ and _[A-Z= are reserved for all uses13:35.20 
  <clam_> Robin_Watts: _[a-z] is alse reserved, for identifiers with file scope13:36.03 
  <clam_> (or something)13:36.06 
  <clam_> i would have used some other mangling scheme13:36.18 
  <Robin_Watts> leading underscores looks to be reserved in C++.13:36.21 
  <clam_> no13:36.32 
  <clam_> and one little known factoid, trailing _t is reserved by POSIX... mupdf is most excellent for not using that13:37.23 
  <Robin_Watts> Except for fz_font_flags_t, fz_shaper_data_t, pdfapp_t, cursor_t, diy_fp_t,...13:38.24 
  <Robin_Watts> ```(a) Each identifier that contains a double underscore __ or begins with an underscore followed by an uppercase letter is reserved to the implementation for any use. (b) Each identifier that begins with an underscore is reserved to the implementation for use as a name in the global namespace.```13:38.48 
  <Robin_Watts> I still think having some consistent naming convention would be good for non-API functions.13:39.52 
  <clam_> Robin_Watts: aren't those internal?13:39.53 
  <Robin_Watts> possibly, yes.13:40.38 
  <ator> @Robin_Watts I'd rather merge the C files so they can be static :)14:12.41 
  <ator> @Robin_Watts I think sebras and I may be on to something about the extra dirty annotations14:14.08 
  <ator> it's because we purge the local xref that holds all the temporarily synthesized appearances when we edit one field14:14.30 
  <Robin_Watts> @ator ew. monolithic .c files are bad.14:14.34 
  <Robin_Watts> @ator right.14:14.42 
  <ator> and we then regenerate all the temporary appearances again14:14.47 
  <ator> which all show up as changes14:14.56 
  <Robin_Watts> So the "format" thing will get called on them all.14:15.05 
  <Robin_Watts> but not the validate.14:15.11 
  <ator> yeah. they'll all be formatted and as paul reported, unrelated fields will show up as changed because they lost their local-xref appearance stream14:15.47 
  <sebras> oh we're here now.14:16.01 
  <Robin_Watts> Yeah, that doesn't strike me as a bug, really.14:16.05 
  <sebras> ok, so many widgets are missing appearance streams entirely and their values are "", yet we regenerate appearancestreams for them.14:16.32 
  <sebras> ok, so many widgets are missing appearance streams entirely and their values are "", yet we regenerate appearance streams for them.14:16.42 
  <ator> well, we have to regenerate appearance streams (in case they have borders set, etc)14:17.06 
  <sebras> ator just mentioned that they might have borders or backround colors to me (privately) and thats correc.t14:17.09 
  <Robin_Watts> We *could* make text fields with non existent or empty values (and no borders) skip the generation step.14:17.31 
  <ator> @Robin_Watts a per-annotation local xref would solve the extra repaints it triggers14:17.37 
  <Robin_Watts> You can't do a per-annotation local xref.14:17.47 
  <ator> or if we could hoist the local xref to be on top of the new incremental xref instead of discarding it, or keep multiple levels of local xref?14:18.19 
  <ator> discarding it leads to lots of extra repaints on edits, which are bad14:18.37 
  <Robin_Watts> However we did it, we'd need to remove all the local xrefs on a genuine edit to the document.14:18.59 
  <Robin_Watts> What if all the widgets depended on some resource (say a font) in the document.14:19.18 
  <Robin_Watts> And we edit the document to change that font.14:19.26 
  <ator> yeah, I see only problems :(14:19.35 
  <Robin_Watts> We don't spot edits at the annotation level, we spot them at the document object level.14:19.50 
  <Robin_Watts> I don't see having to repaint all the annotations on an edit to be a *huge* issue.14:20.47 
  <sebras> paul and fred mentioned this as a change to how it worked previously. along with all the things we already fixed.14:21.29 
  <Robin_Watts> We can probably fairly simply optimise the code to do better on empty fields.14:21.45 
  <sebras> I could verify that it happened in some documents, but it took a bit of time to figure out why.14:21.49 
  <cgdae> You could have .c files #include other .c files. That way statics work, but code is still separated...14:23.23 
  <Robin_Watts> @cgdae But you lose the ability to drop functions at link time.14:23.44 
  <Robin_Watts> monolithic code is bad, M'kay.14:23.52 
  <Robin_Watts> I remember someone wrote a tool that allowed unwanted symbols to be dropped from libraries... 🙂14:24.48 
  <Robin_Watts> @sebras We get stuff right now that we didn't before (like when we open a document and it doesn't immediately tell us it's been altered). The extra repaints are a side effect of that.14:26.12 
  <Robin_Watts> Actually, I'm not sure we CAN optimise the code to do better on empty fields.14:27.11 
  <malc> Robin_Watts compiling with -ffuction/data-section and linking with --gc-sections?14:27.23 
  <Robin_Watts> AIUI, I could have a 'format' thing that took the empty string and returned "enter a name".14:27.48 
  <Robin_Watts> malc: Not portable.14:27.55 
  <Robin_Watts> function level linking is not supported everywhere.14:28.11 
  <malc> Robin_Watts: sure14:28.52 
  <ator> @Robin_Watts our usual naming convention for private auxiliary functions is "_imp"14:28.59 
  <malc> ator: isn't it imp_ instead?14:29.14 
  <ator> no, it's a suffix14:29.21 
  <malc> ah14:29.25 
  <cgdae> Oh hang on, was that me?14:29.53 
  <ator> @Robin_Watts that goes well with the pdf_field_foo stuff that do the internal implementation work of setting field stuff, not to be called directly14:29.56 
artifexirc-bot <malc> recalls reading EDG style guide years ago and being thoroughly impressed14:30.03 
  <Robin_Watts> We tend to use _imp when there is a pdf_foo and pdf_foo_imp14:30.05 
  <ator> and pdf_foo is the user access point and does setup stuff, and pdf_foo_imp does the heavy lifting14:30.37 
  <Robin_Watts> right.14:30.49 
  <ator> seems like the current pdf_annot_field_foo and pdf_field_foo separation14:30.51 
  <sebras> yes, I'm talking about when we end up with text == "" (or is it NULL?) in pdf_write_widget_appearance().14:31.04 
  <Robin_Watts> Yeah, but there are cases where that's not quite the case.14:31.16 
  <sebras> but at that point we've already _started_ the local synthesis.14:31.18 
  <Robin_Watts> @sebras There are 2 things to worry about here AIUI.14:31.52 
  <ator> anyway, since the pdf_field_foo stuff should now never be called directly (because it'll break all our dirty tracking, undo, etc) they should be renamed or hidden14:31.53 
  <sebras> I think there are many places, even internal to MuPDF, where we should be calling pdf_annot_field_value() e.g.14:32.02 
  <Robin_Watts> 1) The js callbacks, and 2) the 'changed' flag.14:32.03 
  <sebras> @Robin_Watts yes, and we would have to let the js callbacks run to determine that we can optimize the appearance for a field.14:32.48 
  <ator> the form js stuff can change things which shouldn't cascade events, so they still need access to some of the pdf_field_foo functions (which also need to set the 'changed' flag)14:32.52 
  <Robin_Watts> The js callbacks are triggered from pdf_field_event_format, and that has to happen before we can get 'text'.14:32.58 
  <sebras> yes. but if format == 0 and pdf_field_value() returns "", then we're in the case I'm talking about.14:33.43 
  <Robin_Watts> And how do we know we haven't just changed the text from 'something' to '' and therefore know that we need to redraw it?14:33.52 
  <Robin_Watts> if format ==0 and pdf_field_value returns "", then how do we know that in a previous call that would have been the same?14:35.33 
  <sebras> mm, I see the problem.14:35.45 
  <sebras> ok, so one should then carefully vet each place before changing it. ugh. 😕14:36.55 
  <Robin_Watts> If we held information about each annotation OTHER than in the document we could say 'has this changed since last time'? But we try REALLY hard not to do that.14:40.13 
  <sebras> @ator you gave me an LGTM on sebras/bug-704078 correct? it clusters fine. and my intent is to work trace?.js into the cluster.14:41.50 
  <sebras> and yes, the javascript could probably be optimized, but not by me right now. 🙂14:42.18 
  <sebras> I just want to get these into the cluster to avoid regressions for the things we've fixed.14:43.28 
  <sebras> @Robin_Watts you can remove robin/bug-704045 now! 🙂14:43.53 
  <ator> @sebras yes, LGTM14:46.07 
  <sebras> @ator excellent, thank you!14:48.36 
  <paulgardiner> It looks like form filling is working correctly now, along with pdf_update_annot, other than something odd happening with JS events. keystroke events are supposed to be able to change the value and don't seem to be.15:05.30 
  <avih> ator: can there be a case in mujs that something throws and there's no room at the stack to push an error? corollary: is it always safe to if (js_try(J)) js_pop(J); ?15:06.29 
  <Robin_Watts> @paulgardiner OK, can you point us at a file that shows that problem?15:07.08 
  <avih> (pop and return, of course)15:07.30 
  <paulgardiner> The "Home Phone" field in this doc15:09.19 
  <paulgardiner> https://cdn.discordapp.com/attachments/770685907279282196/867785390094024724/0920anim20fx-fo-dx-adr-mx.pdf15:09.20 
  <ator> avih: if js_try fails it'll throw an error to the containing scope (not the scope it tried to create but ran out of space for)15:24.51 
  <avih> huh?15:25.18 
  <avih> so js_dostring, or js_ploadstring etc can actually throw?15:25.59 
  <avih> (because they do js_try at the current scope, right?)15:26.28 
  <avih> something doesn't make sense, or is highly unexpected15:27.46 
  <ator> avih: yes, unfortunately. it's hard to work around the requirements of what is allowed inside the setjmp() call, so I haven't been able to figure out a clean way to do it15:27.54 
  <ator> I would have _liked_ for it to fail to the scope being set up, but haven't figured out a way to do it cleanly15:28.23 
  <malc> ator: ever looked at old sjlj implementation of C++ exceptions in G++?15:29.31 
  <avih> can you formulate the cases which could end up with this, and how to ensure they can't be reached?15:29.32 
  <ator> don't leave crap on the stack, and avoid deep recursion :)15:29.57 
  <ator> it shouldn't be a problem in practice if you only allocate stuff that needs to be freed _inside_ the try-scope15:30.29 
  <avih> at which level? also at the js code level? or only in c?15:30.30 
  <malc> no crap, no recursion ==> you are crap15:30.55 
  <ator> alloc() if (try()) { free(); } else { ... endtry(); free() } is not good15:31.24 
  <ator> if (try()) { free(); } else { alloc() ... endtry() free() } is good15:31.40 
  <avih> not sure i follow15:31.58 
  <avih> free what? js_freestate ?15:32.11 
  <ator> alloc/free non-js resources15:32.20 
  <ator> like fopen or other non-mujs related stuff15:32.36 
  <ator> if jmp_buf had been an actual pointer type and not some voodoo craptastic array-like object this could've been set up to be much cleaner15:33.49 
  <avih> well, it's not about resources actually. this is pure js. i'm writing something similar to js_trystring, and then i wasn't sure if "if (js_try(J) { js_pop(J, 1); return 1;" is actually 100% safe15:34.39 
  <ator> safe in what respect?15:35.12 
  <avih> and according to you, that first js_try can throw itself even before the tried code is executed15:35.12 
  <ator> yes.15:35.23 
  <avih> well, then i there there must is a js_tries(J) API which lets you know how many tries can be nested before the try stack runs out15:36.18 
  <avih> and if it's 0, you just fall back15:36.45 
  <ator> I've tried implementing js_try by wrapping setjmp, but you can't do that in C15:36.56 
  <avih> without trying15:36.57 
  <ator> setjmp MUST be used directly in an if-statement15:37.06 
  <avih> sure, but a js_tries(J) api can be used anyway15:37.24 
  <avih> so you test it before you start the try itself15:37.33 
  <ator> if you're handling exceptions anyway with js_try at all levels, it shouldn't matter15:37.49 
  <ator> only for js_dostring and js_pcall could you get surprised15:38.05 
  <avih> ok, then back to my earlier question, can you formulate the exact cases where it would be safe, and those where it wouldn't?15:38.31 
  <ator> again, you need to define "safe"15:38.42 
  <avih> that js_try will never throw15:38.53 
  <ator> well, in that case, it is not safe.15:39.03 
  <avih> but it would be if there was a js_tries API15:39.18 
  <avih> because then you'd know if the next js_try will throw15:39.59 
  <ator> my counter question is: why do you need js_try to not throw?15:40.18 
  <avih> because it's an endless recursion otherwise15:40.38 
  <ator> if you're implementing callbacks in C, then the calling contexnt javascript will catch the exception15:40.58 
  <ator> or bubble it up the try stack15:41.10 
  <avih> i don't have c callbacks15:41.11 
  <avih> (in this context)15:41.19 
  <ator> at some level you'll hit your biggest surrounding js_try15:41.22 
  <ator> the only problems it will cause are (a) if you don't have a surrounding js_try at the top level or (b) you allocate resources and they leak as in the example I gave earlier15:41.55 
  <avih> i have a pure js program, i load it with dostring, and then call functions in it with js_try, push push push, call, js_pop15:42.04 
  <ator> in that case you are guaranteed safe, unless you have called js_try too many times without a matching js_endtry15:42.50 
  <avih> i don't have a surrounding anything15:42.55 
  <ator> if you're not recursively calling functions that call js_try you have no problem15:43.12 
  <avih> because the try stack only grows for nested tries?15:43.41 
  <ator> you won't randomly run out of try-stack space except if you're deeply recursively doing 'try'15:43.44 
  <ator> yes.15:44.00 
  <avih> right, which does bring up the other case (the "normal" mpv js support) which does have nesting15:44.22 
  <ator> well, a nested try that fails will throw to the next try one level up. the only problem there will be possible leaks if you allocated stuff expecting that try will never throw.15:45.00 
  <avih> right15:45.25 
  <avih> well, could still be avoided to begin with with something which lets me know how many tries i have left15:45.49 
  <ator> actually, scratch my case (a) above as that can't happen (you will _always_ have a top level try if try is about to throw)15:45.50 
  <Robin_Watts> ator: Do we have a way of "printf"ing from within util.js?15:46.00 
  <avih> or even only if the next try is safe15:46.02 
  <Robin_Watts> I want to watch what happens inside AFSpecial_Keystroke.15:46.36 
  <ator> @Robin_Watts console.println()15:46.47 
  <Robin_Watts> Ta.15:46.51 
  <avih> ator: true :)15:46.56 
  <avih> (unless the try stack begins with 0 :p )15:47.06 
  <avih> ator: but like you said, it could skip releasing allocation if try throws. are you opposed to adding an api which lets you get info about the try stack?15:48.02 
  <avih> something along the lines of int js_tries(J) { return JS_TRYLIMIT - J->trytop; } ?15:52.06 
  <ator> I don't want to add more APIs :)15:52.09 
  <avih> i can understand that, but clearly it can lead to very undesirable edge cases15:52.44 
  <avih> and it's actually not hard to solve, or at least give the tools which allow the user to break their head how/if they want to use it15:53.14 
  <avih> but for completeness sake, i think it's highly important15:53.27 
  <ator> and if you do something like if (js_tries() > 0 && js_try()) then your code will be illegal C and not work. you know that right?15:53.46 
  <avih> i didn't15:54.23 
  <avih> how so?15:54.25 
  <avih> (i don't think i recall this type of setjmp limitation about being directly in "if"?)15:54.59 
  <ator> because js_try is a macro around setjmp. see https://pubs.opengroup.org/onlinepubs/9699919799/functions/setjmp.html15:55.05 
  <ator> "An application shall ensure that an invocation of setjmp() appears in one of the following contexts only:"15:55.19 
  <avih> well, js_try itself is also subject to these rules anyway, so js_tries will be subject to the limits documented at the same place and js_try :)15:56.43 
  <avih> as*15:56.56 
  <avih> from a completeness perspective - it's missing. sure, it has gotchas - like js_try does, but it's still usable if you're careful. otherwise you're blind15:57.36 
  <avih> ator: and, you could help avoiding footguns by supplying for instance a js_if_cantry() { if(try(J)) ... }16:00.37 
  <ator> not without invoking the wrath of Cthulhu! can't wrap it in a function (because the wrapped function would have returned by the time you longjmp, and you should not try to jump "down" the call stack)16:01.30 
  <avih> or whatever. setjump is a pain anyway. so js_tries could be documented to not be part of the js_try expression or some such16:01.47 
  <ator> can't wrap in nested macros without breaking if-else and making the changing the api16:01.56 
  <ator> the way you handle it is by catching the error js_try throws.16:02.19 
  <avih> yeah, it's ugly. but js_tries is ok, up to setjmp limitations - like js_try itself16:02.22 
  <ator> js_try at the top level (not nested, not recursive) won't throw, any js_try at a recursive level can throw (just like all other js_ functions can throw)16:03.05 
  <ator> the js_dostring and js_pcall etc utility functions were an early mistake back when I thought I could hide the exception handling altogether.16:03.59 
  <avih> :)16:04.22 
  <avih> i'm not actually concerned with nested ploadstring etc. i'm concerned that the try stack can run out even for my own tries16:05.16 
  <ator> if I were to implement mujs today I would have tried harder to avoid using setjmp/longjmp for the exception handling16:05.21 
  <avih> really?16:05.36 
  <ator> it's made impossible tail call optimization and a bunch of other stuff16:06.06 
  <ator> and code generation for try/finally has been made significantly more complicated16:06.34 
  <avih> i bet16:06.50 
  <avih> ator: so the gist of it is that a call can jump out of an arbitrary levels of nesting directly, but never out of the outer-most level?16:08.43 
  <avih> (jump out == throw)16:09.08 
  <avih> i.e skipping some of the catches along its way out16:09.36 
  <avih> or is it guaranteed to skip at most one catch?16:11.27 
  <avih> like, what are the rules here?16:12.17 
  <avih> is lus subject to similar issues that ploadstring can throw?16:17.20 
  <avih> lua*16:17.32 
  <avih> ator: actually, you can guarantee that ploadstring won't throw, because internally you do know what J-trytop is. it's only users which can't know if their next try will throw, but mujs is not subject to this limit16:22.29 
  <avih> (i'm trying to think if js_try can be modified in the same vein)16:23.03 
  <avih> (and then you start to realize that it's actually important also everywhere else mujs uses try internally, and then realize that it's unfair that mujs can be safe internally but users are kept in the dark, and find a great solution :) )16:25.39 
  <ator> avih: I never use ploadstring internally, all internal uses are safe in their try-handling16:28.51 
  <ator> avih: try/throwwill _never_ skip any catches.16:29.18 
  <ator> it will always go to the closest surrounding try16:29.32 
  <avih> right, it will just not enter a new level16:29.48 
  <ator> exactly.16:30.11 
  <avih> so what's the rule for safe usage? to always assume that a try can throw, unless it's at the outer-most level?16:30.43 
  <ator> yeah.16:30.52 
  <ator> assume everything can throw, and you'll generally be safe :)16:31.08 
  <avih> hmm.. well, that's at least a rule :)16:31.13 
  <avih> ator: appreciate the info and time. thanks.16:32.17 
  <malc> methinks ator is a https://en.wikipedia.org/wiki/Robustness_principle subscriber16:34.19 
  <avih> for reference, this "pure js program, call functions in it, without C callbacks" is an approach i'm trying to add support on windows for mpv feature which needs posix regex, so i'm using mujs for that (WIP)16:34.42 
  <avih> (obviously the regex syntax is not identical, but that would be documented)16:35.22 
  <avih> currently these features are disabled on windows (it's a very niche feature, but i thought it would be interesting to see how to make it happen)16:36.39 
  <Robin_Watts> @ator @sebras @paulgardiner 2 commits on robin/master. The final one may need some finessing in the other JS functions, but I think (hope) AFSpecial_KeystrokeEx is doing the right thing now.18:06.41 
  <sebras> @Robin_Watts ok. I'll take a look n a jiffy.18:22.34 
  <paulgardiner> @Robin_Watts I have a few thoughts on this, but we can discuss tomorrow18:54.49 
  <sebras> @Robin_Watts I worrry that console.println() will now print the same things twice and in different ways concerning spaces/linefeeds.19:28.19 
  <sebras> I rarely use console.println() myself so I won't be immediatley affected.19:28.42 
  <Robin_Watts> I think console.println should stop printing to stdout, possibly.22:49.38 
  <sam_> hey guys, thanks for the answer earlier23:21.36 
  <sam_> I can't see the 1.18.1 tarball itself, only so-* tags23:21.42 
 <<<Back 1 day (to 2021/07/21)Forward 1 day (to 2021/07/23)>>> 
ghostscript.com #ghostscript
Search: