| | <<<Back 1 day (to 2014/01/16) | 2014/01/17 |
| kens | Great a reply form the customer that *still* doesn't explain what they are doing, or why | 08:22.28 |
| chrisl | kens: and that didn't cc support? | 08:25.37 |
| kens | Oh not again.... | 08:25.48 |
| | Yeah they chopped support off again and sent it direct to me what a bunch of buffoons | 08:26.15 |
| | When you see the mail, notice that he left all the poeople in his org copied in, but removed Miles and support from our CC list..... | 08:27.49 |
| chrisl | kens: Amazing that they never thought to explain that their product has essentially the same name as a standard feature in Windows - that could never cause confusion.... | 09:07.10 |
| kens | Yeah I did think that was fairly brain-dead too | 09:07.28 |
| | Presumably their 'consultant' expected tehm to answer that question, but they just lumped it in with all the other ones and sent it to us | 09:08.12 |
| | (well, sent it to me...) | 09:08.41 |
| | dir /temp/out.tif | 09:08.54 |
| | oops :-) | 09:08.58 |
| chrisl | Maybe we should get Scott to fly over there - with his baseball bat! | 09:09.12 |
| kens | :-D | 09:09.29 |
| Robin_Watts | Morning tor8 | 12:39.04 |
| tor8 | hi Robin_Watts | 12:43.53 |
| Robin_Watts | so, this problem with repair during xref creation. | 12:46.16 |
| | I believe that the only time this is a problem is when we are fiddling with trailer entries. | 12:46.46 |
| tor8 | and the error is the refcount hits zero and we read freed memory/ | 12:48.08 |
| Robin_Watts | yes. The automatic repair happens and it leaves people holding a duff handle. | 12:48.35 |
| | I was going to say "the only time we ever use trailer entries is while setting up the crypt" | 12:49.12 |
| | or at least "the only time we ever use trailer entries is in internal MuPDF calls" at least. | 12:49.32 |
| | but I'm having a crisis of confidence about both of those. | 12:49.43 |
| tor8 | yeah, we use them to find the root of the page tree and all sorts of things | 12:50.36 |
| Robin_Watts | If either of those were true, then we could feel fairly good about a solution where a small amount of extra magic was required, because they'd be hidden from users. | 12:51.05 |
| tor8 | anyway, the duff handle would be solved by a pair of keep/drop (like a mutex) where you set the throw_on_repair flag, would it not? | 12:51.20 |
| Robin_Watts | tor8: But finding the root of the page tree is done internally to mupdf - it's not something user code would ever be doing, right? | 12:51.51 |
| tor8 | fz_keepobj(xref->trailer) at the head | 12:51.57 |
| | yeah, this whole repair-under-the-hood thing probably breaks a lot of assumptions we've made about when we can skip a keep/drop | 12:52.43 |
| | like the whole pdf_dictgets stuff that guarantees the object a lifetime until the return of the current function | 12:53.01 |
| Robin_Watts | So our handles remain valid, but they will continue to point to the unrepaired stuff. | 12:53.16 |
| | For any object *not* in the trailer, we're fine. | 12:53.39 |
| | as repair never discards an object. | 12:53.44 |
| | so handles remain valid. | 12:53.49 |
| tor8 | which we've solved by letting the old objects live on (we assume they are okay, even when we spot an error with the xref) | 12:53.52 |
| | but forgot completely about the trailer | 12:54.04 |
| Robin_Watts | The problem here is purely with the trailer. | 12:54.08 |
| | We *could* introduce a 'pre_repair_trailer' object. | 12:54.24 |
| tor8 | I think maybe a more robust way would be for the trailer to live on during a repair, by stowing it somewhere for freeing up later. maybe invent an xref slot for it? | 12:54.31 |
| Robin_Watts | And when we do a repair, put the trailer into pre_repair_trailer. | 12:54.44 |
| tor8 | but since we only expect to repair once, an extra storing place for it should suffice I think | 12:54.56 |
| Robin_Watts | Then free it on document close when we free the trailer. | 12:54.57 |
| | yeah. | 12:55.01 |
| tor8 | yeah. that should work. | 12:55.07 |
| Robin_Watts | That's certainly a simpler fix than mine. | 12:55.11 |
| | Mine has the advantage that it's a "generic" solution if we're going to hit this in lots of places. | 12:55.30 |
| tor8 | and it makes a lot of sense when you explain it :) | 12:55.32 |
| Robin_Watts | but I really hope we aren't. | 12:55.34 |
| | OK. I'll try for the simpler fix. Thanks! | 12:55.42 |
| tor8 | I think we should be safe in the assertion that we have all objects (that are in danger of a repair) backed in the xref | 12:56.14 |
| | so it's just the trailer we forgot that we shouldn't zap | 12:56.29 |
| kens2 | Robin_Watts : paulgardiner can one of you look at this: | 13:02.58 |
| | http://stackoverflow.com/questions/21181085/mupdf-unsupportedoperationexception-when-open-the-pdf | 13:02.58 |
| tor8 | kens2: gotta love the helpful comment "If you just don't want to throw the exception you can comment it out." oh, the sheep herding sheep... | 13:03.59 |
| kens2 | Yeah well that's SO for you..... | 13:04.13 |
| Robin_Watts | I have my finger on my nose. | 13:04.16 |
| tor8 | kens2: can I just downvote the question? | 13:04.32 |
| kens2 | Sounds good to me :-) | 13:04.46 |
| | At least the commenter did say 'you should figure out why this is being clalled' unlike the answer which just 'fixed' it by commentn ing it out | 13:05.24 |
| Robin_Watts | tor8, paulgardiner: 2 commits on robin/master then. | 13:50.42 |
| paulgardiner | Both look fine | 13:58.53 |
| tor8 | Robin_Watts: so we're back to fudging with floating point numbers, eh? :) | 14:00.49 |
| | I have a feeling I ought to reread and reacquaint myself with how the xref loading and repair code works again. so much has changed! :) | 14:02.37 |
| | both look fine, iff pdf_set_populating_xref_trailer is guaranteed to only be called once during a repair | 14:03.03 |
| Robin_Watts | tor8: pdf_set_populating_xref_trailer is called strictly once during a repair. | 14:34.19 |
| | and we only ever repair once. | 14:34.31 |
| henrys | ugh pspcl6 in ray_laptop's' support email | 14:59.33 |
| | damn | 14:59.35 |
| kens2 | Yes I saw that, but only evaluating | 14:59.47 |
| tor8 | Robin_Watts: LGTM then. | 15:00.52 |
| Robin_Watts | tor8: Memento fix on robin/master | 15:10.26 |
| tor8 | Robin_Watts: LGTM (though I can't say I understand any of it) | 15:11.35 |
| Robin_Watts | tor8: Any block allocated in memento has a memento header just before it, along with 16 bytes of 'pre' bytes. | 15:12.55 |
| | and 16 bytes of post bytes. | 15:13.02 |
| | pre/post are set to constant values so we can spot overwrites. | 15:13.20 |
| tor8 | why first make them defined, then undefined? | 15:13.35 |
| Robin_Watts | this code is resetting them after a realloc. | 15:13.41 |
| tor8 | oh, right, realloc. | 15:13.59 |
| | okay, I get it then | 15:14.03 |
| Robin_Watts | Ta. | 15:14.09 |
| tor8 | zenikos xps path_bound fix is worrying. we shouldn't be seeing any visibly different results in the first place... | 15:14.35 |
| Robin_Watts | tor8: Indeed. | 15:14.48 |
| | I've tested, and it's just antialiasing differences I think. | 15:14.58 |
| tor8 | in that case, the bound_path must be clipping too tightly. | 15:15.16 |
| | any reason I can see | 15:15.20 |
| | anyway, gotta go. will probably be back in a few hours. | 15:15.23 |
| Robin_Watts | yeah. I was hoping to cluster test and see a big diff I could investigate. | 15:15.34 |
| tor8 | (oh, and I got eval to work!) | 15:15.36 |
| Robin_Watts | ttyl. | 15:15.37 |
| | excellent! | 15:15.40 |
| tor8 | stupid scoping rule differences between eval, global and function body code... :( | 15:16.08 |
| mvrhel_laptop | good morning | 16:08.07 |
| Robin_Watts | morning | 16:08.40 |
| paulgardiner | hi mvrhel_laptop | 16:09.12 |
| mvrhel_laptop | Robin_Watts: sorry again about the goof up of committing the VS2012 vers. of the win32 solution | 16:10.59 |
| Robin_Watts | mvrhel_laptop: No worries. We've all done it before. And I think I reviewed that patch :) | 16:11.25 |
| mvrhel_laptop | bbiaw | 18:16.50 |
| henrys | trying out smartgit hope I don't break the repo ;-) | 18:50.57 |
| Robin_Watts | tor8: ping | 19:02.19 |
| | henrys: Is that all zenikos jbig/opj patches? | 19:12.37 |
| henrys | Robin_Watts: I think so. Did he put everything in the ghostpdl local repo, I didn't look elsewhere | 19:19.16 |
| Robin_Watts | Yes, I think so. | 19:19.40 |
| | I'll run the extractor script and then update mupdf. | 19:20.36 |
| henrys | I don't know what the penalty should be for an at symbol in a filename but it ought to be severe. | 19:21.11 |
| Robin_Watts | Almost as severe as ending in .pl | 19:21.39 |
| henrys | Robin_Watts: we are set up here http://pdfliberation.wordpress.com/ our logo had a transparent background and wasn't visible on there black page so I replaced it with a white background, maybe we should have a special logo for dark backgrounds. | 21:50.39 |
| mvrhel_laptop | microsoft has created an impressive set of hurdles/obfuscation/smoke and mirrors/lack of documentation for their driver development | 22:50.01 |
| | I have not seen anything like this in some time | 22:50.15 |
| | especially when the manual starts out talking about how much easier they have made it | 22:50.37 |
| | I can't imagine what it used to be like | 22:50.47 |
| ray_laptop | mvrhel_laptop: I last delved into Windows drivers in 2002 or so. It wasn't _that_ hard. But typically MS has had plenty of time to obfuscate things immensely since then. | 23:09.30 |
| | mvrhel_laptop: printer drivers, that is. Other "hardware drivers" have always been a mess | 23:10.19 |
| mvrhel_laptop | hmm. I guess I am just a little slow. I am almost there, but running into some signing issues | 23:11.25 |
| ray_laptop | I was spoiled by the ease and simplicity of linux hardware drivers. Now, admittedly, CUPS has made linux printing more obtuse | 23:11.32 |
| mvrhel_laptop | bbiaw | 23:12.45 |
| ray_laptop | mvrhel_laptop: I am bogged down in compositor chain mess. The thing is, that I have it working to use a pdf14 clist type device to 'accumulate' a page and play it back to something like 'display' or 'pxlcolor'. The problen is after that. | 23:13.21 |
| | I am now wondering about having a pdf14 clist ompositor that has a non-clist pdf14 compositor as the next in the chain, with the "ultimate" target being the original device (e.g., 'dispay') | 23:14.55 |
| | I thought I was almost done, but all of the gstates tat have pointers to the 'device' make it a mess. | 23:15.50 |
| mvrhel_laptop | oh. yes. I can only imagine | 23:24.24 |
| marcosw1 | sebras and Robin_Watts: casper is dazed and confused, I'm going to have to reboot it in a few minutes | 23:47.05 |
| Robin_Watts | marcosw1: OK. I'm logged out. | 23:47.32 |
| marcosw1 | Robin_Watts: thanks, I'm glad you weren't running a long job | 23:52.14 |
| sebras | ok. by. | 23:52.45 |
| | bye... | 23:52.47 |
| tor8 | Robin_Watts: pong. | 23:54.47 |
| Robin_Watts | hi | 23:54.56 |
| ghostbot | bonjour, robin_watts | 23:54.56 |
| Robin_Watts | did I ping earlier? | 23:55.01 |
| | ah yes, but I sorted it. | 23:55.24 |
| | 2 commits on robin/master when you get a mo. | 23:55.33 |
| tor8 | Robin_Watts: last one has a typo in the commit message, but otherwise both LGTM | 23:59.22 |
| | Forward 1 day (to 2014/01/18)>>> | |
IRC Logs