| <<<Back 1 day (to 2017/02/09) | 20170210 |
sebras | Robin_Watts: in mupdf:1912de5f when can oldbot be != -1? | 13:15.28 |
| it seems to me it must always be >= 0 since gbot starts out at 0 and may only be set to whatever value gtop has, and that must necessarily be >= gbot..? | 13:16.14 |
Robin_Watts | sebras: If we throw an error before we get to the point where oldbot is set ? | 13:16.16 |
| oldbot is only every not -1 if we make it to pdf_process_contents. | 13:16.57 |
sebras | ah, yes of course. | 13:16.59 |
| why are there two calls to pdf_gsave()? | 13:17.15 |
| wouldn't one be sufficient? | 13:17.22 |
Robin_Watts | possibly. | 13:17.40 |
| I was making the minimum changes I could to avoid introducing more thinkos. | 13:18.00 |
sebras | Robin_Watts: I don't tink fz_var(gstate) is necessary anymore since it is not used in fz_alway()/fz_catch(). | 13:25.07 |
| other than that I can't fault the logic. without knowing any details it seems unecessary to do two gsaves and have three calls to grestore in the cleanup logic. | 13:27.17 |
| also I'm perplexed by gparent any why it is necessary to store in the processor state. wouldn't it be sufficient to have it as a local? git history sheds no light on why it is needed. | 13:28.15 |
| Robin_Watts: oh and what is blocking merging 696870? I recall having looked at that before..? | 13:29.07 |
tor8 | sebras: 696870 is not required; not sure why robin still has it on his branch | 13:36.15 |
sebras | tor8: the "but it seems we do" appears to tell a different story though. | 13:37.21 |
tor8 | sebras: Robin_Watts: commit 515c0106845a7dafd71abba6b29305e39c88380e adds the second gsave | 13:46.39 |
| I can't claim to understand they why, better ask Robin about it. | 13:47.48 |
sebras | tor8: mm, I also don't understand the story in the commit message. I'm slightly worried that we might be complicating the code because we don't understand it. :-/ | 13:52.23 |
| Forward 1 day (to 2017/02/11)>>> | |