| | <<<Back 1 day (to 2020/12/01) | Fwd 1 day (to 2020/12/03)>>> | 20201202 |
| clam | ator: (for the logs) "clang: error: the clang compiler does not support '-march=native'" on arm mac machine | 03:15.16 |
| | correction clang does not support -march=native even on this, x86_64, box | 10:26.23 |
| ator | then I guess, don't use build=native? :) | 10:27.45 |
| clam | ator: now, pray tell, how am i to know when you will fix it and i'm not reaping all the amazing benefits of nativity??? | 10:39.43 |
| ator | how am I supposed to fix it? if the feature isn't there, I can't well use it. | 10:40.19 |
| clam | ator: a) if clang is used do not pass it -march=native b) profit! | 10:40.50 |
| ator | anyway, isn't it more a thing for the umpteen flavours of x86 (not the AMD 64-bit instruction set) with all the weird features added each generation? | 10:41.24 |
| | like MMX, SSE, SSE2, AVX, I lose track of all the TLAs | 10:42.05 |
| | some instructions being faster on 686 than 586 than 486, etc, etc. | 10:42.29 |
| clam | and i know what all those acronyms mean... except for bloody TLA! | 10:42.46 |
| | That Awesome Acronym probably | 10:44.04 |
| ator | three letter acronym means three letter acronym! | 10:44.34 |
| clam | ator: naturally, how very http://www.bash.org/?6460 of me :) | 10:46.53 |
| sebras | @ator care to review sebras/ossfuzz? it appears to fix no less than three issues. | 12:08.03 |
| artifexirc-bot | <Robin_Watts> sebras: If @ator isn't about, I can take a look? | 12:42.33 |
| | <Robin_Watts> @sebras Ah, well, that's my code, and you're right, it's broken in a dumb way. | 12:44.06 |
| | <Robin_Watts> Your fix lgtm. | 12:44.09 |
| | <sebras> Alright, tanks. :) | 13:14.55 |
| | <ator> @sebras https://www.youtube.com/watch?v=zXBDPdNrIKw | 13:31.26 |
| sebras | @ator :) | 14:27.38 |
| artifexirc-bot | <Robin_Watts> @ator Did you get a chance to look over those commits? | 14:42.04 |
| | <ator> @Robin_Watts Yes. Still looking :) | 15:02.40 |
| | <ator> @Robin_Watts one odd comment though, on pdf_discard_journal. "This is called implicitly when a non-undoable change occurs (such as a pdf_update_annot after a page change" | 15:03.23 |
| | <ator> doesn't the local_xref stuff afterwards make that comment obsolete? | 15:03.55 |
| | <Robin_Watts> pdf_discard_journal is now only called on a repair. | 15:04.38 |
| | <Robin_Watts> so I can probably fix that comment. | 15:04.44 |
| | <ator> good, that confirms I didn't miss anything regarding how it's used | 15:05.05 |
| | <Robin_Watts> Commit updated. | 15:06.14 |
| | <ator> I'm not 100% convinced of the need for pdf_end_operation and the (to me ugly) pdf_begin_implicit_operation | 15:06.15 |
| | <ator> is the reasoning to make sure we don't change stuff accidentally? | 15:06.30 |
| | <ator> or rather unaware | 15:06.41 |
| | <Robin_Watts> Partly, yes. | 15:06.42 |
| | <ator> the journaling commit adds begin_implicit_operation in pdf_load_annots around the update_annot call; that remains later when you add the local_xref | 15:07.33 |
| | <Robin_Watts> Yes. | 15:07.46 |
| | <ator> does the journal contain changes to local_xref too, or how do these intersect? | 15:07.52 |
| | <Robin_Watts> The journal does not contain changes to local_xref. (let me check that...) | 15:08.14 |
| | <Robin_Watts> The journal does not contain changes to local_xref. (let me check that... checked :)) | 15:08.37 |
| | <ator> if the local_xref changes are not part of undo/redo, or dirtied so they get regenerated, couldn't we get in trouble? | 15:09.09 |
| | <Robin_Watts> hmm. maybe. | 15:09.46 |
| | <Robin_Watts> I think I force the page to be reloaded in mupdf-gl on an undo/redo. | 15:10.06 |
| | <Robin_Watts> so we sidestep that problem there, but in other uses... yes. | 15:10.27 |
| | <ator> I suspect we're relatively safe, since the local_xref is only used for missing annotation appearances (so far) | 15:10.31 |
| | <ator> any change would make a non-local_xref update | 15:10.43 |
| | <ator> UI-wise in mupdf-gl I'd like keybindings for undo and redo as well (ctl-z and shift-ctl-z) | 15:11.29 |
| | <Robin_Watts> Possibly, on any document undo/redo, we should run through the pages, and invalidate any local annot appearances. | 15:11.40 |
| | <ator> but in doing that, it would sort of be nice to go back to the current page at the time in the history stack | 15:11.45 |
| | <ator> I think it's undo that takes an annot from local to global and vice versa that could be a problem | 15:12.18 |
| | <ator> in any case, reloading the page is the safe thing to do when hitting undo/redo for all viewers | 15:12.47 |
| | <Robin_Watts> yeah. I don't see this as a blocker, necessarily. | 15:13.00 |
| | <ator> only possible "blocker" to this would be if the UI wants to hold on to the current selected annotation across undo/redo | 15:13.33 |
| | <ator> but I don't see that as an important feature, don't know if any tool does that with undo/redo | 15:13.57 |
| | <Robin_Watts> I've added comments to undo/redo to say people should reload the page. | 15:16.58 |
| | <ator> should memset the key in pdf_find_font_resource (in case of unexpected padding) | 15:18.35 |
| | <Robin_Watts> done. | 15:20.41 |
| | <ator> renumber_pages won't work as expected, renumberobj only affects dictionaries and arrays and the page->obj and annot->obj are indirect references | 15:21.30 |
| | <ator> need to drop the old, and create a new indirect for those objects | 15:22.10 |
| | <ator> using the opts->renumber_map | 15:22.17 |
| | <ator> (sorry about the sharp edges in renumberobj) | 15:22.44 |
| | <Robin_Watts> renumberobj fixes indirects within things. | 15:22.58 |
| | <Robin_Watts> but not top level. | 15:23.03 |
| | <Robin_Watts> so need to fix the top level case. | 15:23.15 |
| | <ator> and we shouldn't change the indirect pdf_obj directly, in case it's shared | 15:24.00 |
| | <Robin_Watts> oh, we only ever hit the top level case. | 15:24.07 |
| | <Robin_Watts> OK. will fix. | 15:24.16 |
| | <ator> so we need page->obj = pdf_new_indirect(opts->renumber_map[pdf_to_num(page->obj)]) but without leaking and error checking | 15:24.56 |
| | <Robin_Watts> @ator Commit updated. | 15:48.25 |
| | <Robin_Watts> Not sure any leaking or error checking is actually needed. | 15:49.05 |
| | <ator> @Robin_Watts source/pdf/pdf-resources.c:22:2: warning: implicitly declaring library function 'memset' -- needs to include <string.h> | 15:56.57 |
| | <Robin_Watts> ok. | 15:57.03 |
| | <ator> clang is being whiny about void* cast from int | 15:57.26 |
| | <ator> platform/gl/gl-main.c:1199:27: warning: cast to 'void *' from smaller integer type 'int' | 15:57.28 |
| | <ator> I solved that locally by doing (void*)(intptr_t)(i+1) | 15:57.42 |
| | <ator> count is uninitialized in the same function if not a pdf file | 15:58.03 |
| | <ator> pos = 0, count = 0; | 15:58.38 |
| | <ator> or pos = count = 0; | 15:58.42 |
| | <ator> in the else branch | 15:58.48 |
| | <Fred> @ator "if the UI wants to hold on to the current selected annotation across undo/redo" - it does. If I am resizing an annotation, changing color, etc. | 15:59.05 |
| | <ator> @fredrossperry do you want to keep it selected when you hit undo though? | 16:00.36 |
| | <Fred> Optimally, yes. | 16:01.02 |
| | <ator> if I undo something I expect the selection to be changed to the thing that was selected when I did the operation, or cleared | 16:01.16 |
| | <ator> if I edit annotation A, select annotation B, and do undo | 16:01.28 |
| | <ator> I don't expect B to stay selected | 16:01.33 |
| | <ator> since the undo changes back the edit of annotation A | 16:01.55 |
| | <Fred> True, but If I select annot A, change its size, then undo, I'd expect it to stay selected. | 16:02.00 |
| | <ator> maybe we should be able to associate current selection and current location with an undo step | 16:02.26 |
| | <Robin_Watts> @ator Fixed. | 16:02.29 |
| | <ator> then if you edit something, go somewhere else, and hit undo it'd be really nice to pop back to where you were | 16:02.45 |
| | <Fred> or, at least associate current selection with an undo step. | 16:03.11 |
| | <Robin_Watts> @fredrossperry Well, you can remember what number the annot is, then undo, then reselect it after the reload. | 16:03.12 |
| | <ator> I'd like to remember the number of the annotation and page and maybe zoom level, as well :) | 16:03.50 |
| | <Fred> "reload"? I'm just talking about normal operation. | 16:03.52 |
| | <Robin_Watts> "Current selection" is an app level thing. "undo history" is a document level thing. | 16:03.56 |
| | <Robin_Watts> When you do 'undo' or 'redo' you need to "reload" the page. | 16:04.14 |
| | <Robin_Watts> Having "Current Selection" involved in the undo history is not going to happen. | 16:04.38 |
| | <Fred> ok. But I need to have an identity of some sort for the selected object so I (the app) can re-select it. | 16:05.18 |
| | <Fred> ...after undo. | 16:05.28 |
| | <Robin_Watts> Annots don't change number. | 16:05.47 |
| | <Fred> Is the number available in the Java API? (looking...) | 16:06.08 |
| | <Robin_Watts> The fourth annotation on a page will still be the fourth annotation on a page 🙂 | 16:06.17 |
| | <Robin_Watts> GetAnnotations returns an array, I believe. | 16:06.31 |
| | <ator> PDFAnnotation.getObject().asIndirect() | 16:06.47 |
| | <ator> the fourth annotation may not be the fourth, if the second annotation is the one deleted and then you undo/redo | 16:07.25 |
| | <ator> but the object numbers should stay stable | 16:07.34 |
| | <Robin_Watts> @ator Oh, true. | 16:07.59 |
| | <Fred> don't see PDFAnnotation.getObject() | 16:08.04 |
| | <Fred> maybe since 1.18.x? | 16:08.14 |
| | <ator> commit dbe1927a976513b2231b3d4bbb48fa410db864b2 adds it (on master) | 16:08.28 |
| | <Fred> Ah, recent then. | 16:09.30 |
| | <ator> yes, just after 1.18 | 16:09.41 |
| | <Fred> thanks. | 16:09.47 |
| | <ator> missed it by 2 weeks | 16:09.51 |
| | <ator> that commit can be trivially cherry-picked to 1.18.x | 16:10.08 |
| | <Fred> Then I (the app) would need to select it by number. | 16:10.11 |
| | <Fred> don't need it on 1.18.x without undo. | 16:11.06 |
| | <Robin_Watts> Yeah, you should be moving to master for the undo stuff, so you'll get both then. | 16:11.45 |
| clam | ator: https://repo.or.cz/llpp.git/commitdiff/fb9db17eabfd561ad4e39180d4c27754d6beb06a | 17:08.46 |
| artifexirc-bot | <Robin_Watts> @ator So, where are we with those commits? Did I do all the updates you wanted? | 17:12.14 |
| | <ator> it's still buggy :( | 17:39.26 |
| | <ator> can't create new annotatinos with mupdf-gl | 17:39.33 |
| | <ator> get an "error: Can't alter an object other than in an operation" and then the screen starts flickering like crazy | 17:39.49 |
| | <Robin_Watts> bah. | 17:50.03 |
| | <Robin_Watts> Ok, I have fixes for those. | 18:19.02 |
| | <Robin_Watts> Ink stuff doesn't appear to actually show up? | 18:19.18 |
| | <ator> ink stuff happens in the canvas edit mode thingy (brain is mush, can you tell?) | 18:20.07 |
| | <Robin_Watts> I can see the ink stuff as I scribble it, but when I release it, it vanishes - but an annotation is there cos I can delete it. | 18:24.22 |
| | <ator> when you release after scribbling, it should call set_vertex_list or something like than and then pdf_update_annot | 18:25.49 |
| | <ator> in do_edit_ink() | 18:26.13 |
| | <Robin_Watts> Updated commits on robin/master | 18:27.24 |
| | <Robin_Watts> git logg -20 | 18:27.27 |
| | <ator> yeah, can't see the scribbles. crashes with "can't alter ..." when changing the border width | 18:29.58 |
| | <ator> which is what I tried to do to force an appearance change | 18:30.12 |
| | <ator> clicking in the "Undo history" list throws up error: Cannot cache local object 8388608 without a local xref | 18:31.27 |
| | <ator> square and circle work, line doesn't | 18:32.13 |
| | <Robin_Watts> I've fixed the undo history crash. | 18:47.08 |
| | <Robin_Watts> I don't entirely understand how I broke ink stuff. I'll keep basing. | 19:04.26 |
| | <Robin_Watts> I don't entirely understand how I broke ink stuff. I'll keep bashing. | 19:04.28 |
| clam | ator: if for some reason you would need blood dripping out of your eyes - https://www.youtube.com/watch?v=2Z4OQBLSljQ | 19:59.05 |
| | <<<Back 1 day (to 2020/12/01) | Forward 1 day (to 2020/12/03)>>> | |
Log of #mupdf at irc.freenode.net.