| | <<<Back 1 day (to 2015/09/27) | 20150928 |
| kens | rsc the current version of Ghostscript does not produce any warnings or errors for me with your PDF file. You don't say what version you are using, on what OS, nor do you give a complete command line. | 07:10.44 |
| | The PDF file only contains a single font, a CIDFont TrueType outlines version of Wingdings, so either its that, or you have a substitute font defined for the missing fonts, and that font is broken. | 07:11.31 |
| | If you think this is a bug I'd suggest you open a bug report where all the details required to reproduce the problem can be captured. | 07:12.14 |
| rsc | kens: sorry. It complains about Arial-BoldMT | 07:16.49 |
| kens | Arial-BoldNT is not embedded in the PDF file, so there must be (somewhere) a message telling you its using a substitute | 07:17.25 |
| Robin_Watts | Morning tor8. Good weekend? | 10:03.25 |
| | Bunch of reviews on robin/master, if you wouldn't mind. | 10:04.46 |
| tor8 | Robin_Watts: Morning. Looking now. | 10:05.24 |
| | Robin_Watts: depressing indeed. have we filed a bug report with the gcc devs? | 10:07.08 |
| Robin_Watts | I have not. | 10:07.20 |
| tor8 | all LGTM, but I worry about what'll happen to that volatile int stuff years down the line when it's not required anymore | 10:07.40 |
| Robin_Watts | tor8: I can excuse it to myself, in that it's entirely harmless. | 10:08.02 |
| | It forces a write to happen, in a case where it would always have to happen anyway for correctness. | 10:08.31 |
| | So it's untidy, but has no actual cost. | 10:08.47 |
| tor8 | the cost is 8 lines of comment explaining WTF :) | 10:09.53 |
| Robin_Watts | Yes. | 10:10.05 |
| | Untidy in the source, but no cost in the binary. | 10:10.13 |
| tor8 | Robin_Watts: oh, it looks like I never pushed the tor/master stuff to origin | 10:12.08 |
| Robin_Watts | yeah, I just checked that to see if I should rebase. | 10:12.38 |
| | You push, I'll rebase ? | 10:12.40 |
| tor8 | will do. | 10:12.54 |
| | done. | 10:13.24 |
| | so, I guess the big question now is whether the release should include the new opengl-based viewer | 10:13.44 |
| | it currently does almost everything the x11/win32 viewer does. only bit missing is some form filling on win32. | 10:14.11 |
| | but it does allow searching in unicode and has the nice outline side panel | 10:14.42 |
| Robin_Watts | tor8: I see no downside to including it. | 10:15.01 |
| | It's an extra 'preview' of coming attractions. | 10:15.12 |
| tor8 | I will need to push a few local fixes to our glfw-repo | 10:15.19 |
| | I've got some tweaks there that improve things a bit | 10:15.28 |
| Robin_Watts | Nothing that currently works will stop working because of it. | 10:15.32 |
| tor8 | yeah, it's just going to bloat the download but I don't think that's all that important anymore | 10:15.50 |
| | considering we dropped the bloat by only shipping one mutool binary :) | 10:16.12 |
| sebras | tor8: can't you add a test to check what version of GCC is being used and trigger on 6.0 or something and cause a #error. | 10:26.01 |
| | tor8: that way you can create a reminder for yourself in the future to remove the volatile cast once you consider gcc 4.9.x to be irrelevant. | 10:26.38 |
| Robin_Watts | sebras: We also generate a load of bugs for ourselves when gcc 6.0 comes out into beta testing and bleeding edgers run into it. | 10:28.24 |
| tor8 | I'm more and more of the opinion that optimizing compilers should never be used... | 10:30.09 |
| Robin_Watts | tor8: bug 696172. | 10:38.34 |
| | They have 0 length strokes, with circular end caps. | 10:38.47 |
| | Acrobat, gs etc render a spot. muPDF does not. | 10:39.05 |
| tor8 | I thought we'd special cased 0 length strokes? | 10:39.32 |
| | somewhere in the pdf interpreter, since the rules for how to handle zero length strokes differ between XPS and PDF | 10:40.03 |
| | or is it an interaction between 0-length and square linecaps? | 10:42.26 |
| Robin_Watts | Let me double check before I waste more of your time. | 10:43.04 |
| | Oh, ffs. | 11:39.30 |
| | The volatile fix breaks windows builds. | 11:39.37 |
| tor8 | Robin_Watts: I wonder ... what if we change fz_try into an actual function call? | 11:42.41 |
| | make it static inline in the header for performance | 11:42.50 |
| Robin_Watts | setjmp can't be in a function. | 11:42.55 |
| | but I'm trying a change now. | 11:43.06 |
| tor8 | oh, yeah... nevermind | 11:45.07 |
| Robin_Watts | ok, I have a version that works locally. | 11:46.03 |
| tor8 | I wonder how many other bits of code this compiler bug affects | 11:46.13 |
| Robin_Watts | let me see if that works on the aws instance. | 11:46.15 |
| tor8 | there's gotta be hundreds of projects that use setjmp that could be negatively affected | 11:46.32 |
| Robin_Watts | Yeah, it's mind boggling. | 11:50.20 |
| | OK, I have a version that works both on windows, and on the affected linux box. | 11:51.14 |
| | that's using a non-inline function. | 11:51.20 |
| | Let me try with an inline function. | 11:51.36 |
| | The static inline fixes the linux issue... trying windows... | 11:53.57 |
| | and on windows. | 11:54.30 |
| | ok, I'll prepare a commit with that in instead. | 11:56.28 |
| | tor8: Updated versions of the commits there, rebased on golden. | 12:33.29 |
| | And you're right, we do special case 0 length strokes. | 12:33.46 |
| tor8 | Robin_Watts: why not merge fz_push_try and fz_trying into one function? | 12:52.15 |
| Robin_Watts | cos fz_push_try can return 0, and thus setjmp doesn't happen. | 12:52.44 |
| tor8 | ah. | 12:52.59 |
| Robin_Watts | The 'overflow' case. | 12:53.15 |
| tor8 | yes, I see that now. just reading the source to fz_push_try. | 12:53.38 |
| | all LGTM then | 12:53.40 |
| Robin_Watts | and fz_push_try only happens on the initial try. | 12:53.49 |
| | fz_pushing happens on both throw and catch. | 12:53.59 |
| | Ta. | 12:54.15 |
| tor8 | Robin_Watts: um, as far as I can see fz_push_try only happens in the one place | 12:55.43 |
| Robin_Watts | tor8: It does. | 12:56.16 |
| | fz_push_try only happens in the fz_try macro. | 12:56.49 |
| | As does fz_pushing. | 12:56.59 |
| | But if we longjmp, we reappear out of the setjmp, and that causes fz_pushing to get called a second time. | 12:57.17 |
| tor8 | yes, so if we were to merge fz_push_try/fz_trying, then we'd have to cope with the setjmp value zero causing us to skip pushing | 12:58.05 |
| | the way you've written it is clearer | 12:58.10 |
| | Robin_Watts: can you try building the non-workaround code with -fno-tree-dominator-opts on the problem machine? | 13:01.46 |
| Robin_Watts | 2>c:\artifex\mupdf.git\source\fitz\util.c(335) : warning C4305: '=' : truncation from 'int' to 'float' | 13:02.46 |
| | Should they be FLT_MIN and FLT_MAX ? | 13:03.13 |
| tor8 | oh bollocks | 13:03.56 |
| | not FLT_MIN, that's the floating point value nearest zero | 13:04.17 |
| | could use something like -1e20 and 1e20 | 13:05.05 |
| Robin_Watts | -FLT_MAX ? | 13:05.07 |
| tor8 | or -FLT_MAX yes | 13:05.17 |
| Robin_Watts | ok, I'm making a commit for that now. | 13:05.33 |
| tor8 | Robin_Watts: okay, I've found something in the C specs which may explain odd gcc behaviour | 13:06.49 |
| Robin_Watts | tor8: go on... | 13:07.16 |
| tor8 | It should only appear one one of the following contexts: | 13:07.24 |
| | the entire controlling expression of a selection or iteration statement; | 13:07.31 |
| | one operand of a relational or equality operator with the other operand an integer | 13:07.35 |
| | constant expression, with the resulting expression being the entire controlling | 13:07.35 |
| | expression of a selection or iteration statement; | 13:07.44 |
| | the operand of a unary ! operator with the resulting expression being the entire | 13:07.48 |
| | controlling expression of a selection or iteration statement; or | 13:07.48 |
| | the entire expression of an expression statement (possibly cast to void). | 13:07.48 |
| | so "if (setjmp() == 0)" is illegal, but "if (setjmp())" or "if (!setjmp())" are legal | 13:08.37 |
| Robin_Watts | "one operand of a relational or equality operator with the other operand an integer constant expression" | 13:09.29 |
| tor8 | so setting a variable, and then testing it, is not valid apparently, like "if (!(code = setjmp()))" | 13:09.30 |
| | ah, my bad | 13:09.47 |
| Robin_Watts | "one operand of a relational or equality operator with the other operand an integer constant expression" covers 0 ==setjmp(), I think. | 13:09.48 |
| tor8 | so that is still valid, but assignind and then comparing in the same compound expression is not | 13:10.04 |
| Robin_Watts | but I agree that setting a variable and then testing it might not be valid. | 13:10.09 |
| | The question is, is my fixed version valid... | 13:10.23 |
| tor8 | http://open-std.org/jtc1/sc22/wg14/www/docs/n1494.pdf page 275 | 13:10.53 |
| | oh, good question. it's not an expression statement, it's an argument | 13:11.34 |
| | we might need to rethink the macros altogether :( | 13:12.18 |
| Robin_Watts | Is an argument not an expression statement ? | 13:12.22 |
| | tor8: Actually, I can just do the assignment before doing the longjmp. | 13:12.56 |
| tor8 | a statement ends with a ';' :) | 13:13.02 |
| | mujs might have similar problems | 13:13.28 |
| | the js_try macro uses comma expressions | 13:13.38 |
| | #define js_try() (js_savetry(), setjmp()) | 13:13.53 |
| | I guess I could wrap the savetry to return a jmp_buf and wrap it all up | 13:14.12 |
| Robin_Watts | Yeah, let me try for that fix here. | 13:14.24 |
| tor8 | so it becomes setjmp(savetry()) | 13:14.24 |
| | so we could conceivable do something similar for fz_try | 13:14.41 |
| Robin_Watts | As long as savetry doesn't cope with overflow, sure. | 13:14.43 |
| tor8 | it does, but then it longjmps away to another context | 13:15.13 |
| | but then I don't see how that should matter | 13:15.49 |
| | the arguments to setjmp are only evaluated once | 13:15.59 |
| Robin_Watts | We currently have: if (fz_push_try() && setjmp(buf)) | 13:16.25 |
| | if fz_push_try detects an overflow, it returns 0, and the setjmp never happens. | 13:16.51 |
| tor8 | ah. in mujs, js_savetry just does a throw to the outer try-block in case of overflow | 13:17.38 |
| | if (setjmp(fz_push_try()) should work. the top level try should never fail on overflow | 13:17.53 |
| Robin_Watts | Gotcha. | 13:18.03 |
| tor8 | and if we overflow, just throw instead of trying? | 13:18.04 |
| | i.e. do what mujs does | 13:18.14 |
| Robin_Watts | Yes. Let me try that. | 13:18.33 |
| tor8 | Robin_Watts: bah. jmp_buf being an array type is really messy. | 13:22.38 |
| | jmp_buf *js_savetry(...) and setjmp(*js_savetry()) | 13:23.31 |
| Robin_Watts | Have the function return a jmp_buf cast a (void *) and uncast in the setjmp ? | 13:23.46 |
| tor8 | return the &jmp_buf | 13:23.56 |
| | but it's really headache inducing :( | 13:24.07 |
| | a jmp_buf is essentially a typedef __builtin_jmp_buf jmp_buf[1]; | 13:24.40 |
| | just so it can be backwards compatible with automatic decomposition of array to pointer-to-first-element-of-an-array | 13:25.17 |
| Robin_Watts | OK, I have a compile that seems to work. Will test it properly after lunch. | 13:32.16 |
| tor8 | though the *js_savetry() might be awkward and bad, unpacking the whole jmp_buf into temporary storage to take the address of it again | 13:32.18 |
| | let me poke a bit more, I might come up with a more elegant jmp_buf passing solution | 13:32.37 |
| Robin_Watts | I don't see why jmp_bufs ever get unpacked with what I have here... | 13:32.52 |
| | We only ever return the address of them. | 13:33.03 |
| | And taking the *(that address) only returns a further address. | 13:33.27 |
| | So there is no cost there. | 13:33.34 |
| tor8 | setjmp needs a jmp_buf, so we dereference the pointer to get the value | 13:33.36 |
| Robin_Watts | setjmp takes a pointer. | 13:33.50 |
| | it might be an 'array' rather than a technical pointer, but it's still a pointer in effect. | 13:34.25 |
| tor8 | *jmp_buf_ptr is an array[1] | 13:34.27 |
| | so as I understand the call setjmp(*buf_ptr) | 13:34.39 |
| | it dereferences buf_ptr to the full array[1] and then takes the address of that temp copy and passes to setjmp | 13:34.59 |
| | which would be wrong on many levels :( | 13:35.15 |
| | Robin_Watts: a solution without having to mess with return types and casting: setjmp((push(), buf[top])). | 14:17.35 |
| Robin_Watts | Nice. | 14:30.40 |
| | tor8: I wonder... | 14:46.24 |
| | rather than try being: if (setjmp(push(), buf) == 0) | 14:46.49 |
| | we could have try be: {{{ push(); if (setjmp(buf) == 0) | 14:47.15 |
| | And have catch start with }}} | 14:47.27 |
| | That would have the nice effect of being a compile time check for mismatched try/catches. | 14:47.50 |
| | as well as reducing complexity (and hence potential future problems) around the setjmp. | 14:48.26 |
| tor8 | won't that nesting break on the fz_catch else statement? | 14:49.46 |
| | bah, my brain's mush. ignore me. | 14:50.02 |
| Robin_Watts | We lose the ability to have the catch be 'else if', but that train sailed when we added always. | 14:51.54 |
| tor8 | Robin_Watts: wait, we're using the return value but assigning it to a variable is illegal | 14:52.17 |
| Robin_Watts | Where are we doing that? | 14:52.31 |
| tor8 | when we set 'code' | 14:52.37 |
| Robin_Watts | My new version doesn't assign. | 14:52.46 |
| tor8 | I haven't seen your new version yet | 14:52.53 |
| Robin_Watts | Gimme a mo, and I'll get a version online for you. | 14:52.57 |
| | tor8: Look now. | 14:55.36 |
| tor8 | Robin_Watts: the do/while(0) in the try/always block -- that's just to catch "break" right? | 15:39.10 |
| Robin_Watts | yes. | 15:39.17 |
| tor8 | Robin_Watts: looks reasonable. | 15:57.38 |
| Robin_Watts | Both of them? | 15:57.58 |
| | Can you have a quick look at fz_add_line_dot in draw-path.c ? | 15:58.22 |
| | We calculate n from the flatness. | 15:58.36 |
| | If the flatness is too low, n can be 2. | 15:58.50 |
| | That means dots go in as a horizontal line of no size. | 15:59.00 |
| | Should we force n to be at least 3 or 4 ? | 15:59.11 |
| | brb. | 15:59.54 |
| tor8 | both patches LGTM | 16:02.11 |
| | Robin_Watts: looking. | 16:02.14 |
| | yes, forcing it to be at least 3 should work | 16:03.12 |
| Robin_Watts | ok, ta. | 16:08.32 |
| | Morning fredross-perry. | 16:11.31 |
| | Did you find what you wanted in SOT in the end? | 16:11.39 |
| | We should try to get your gsproof mupdf changes into the repo asap as we have a release coming up. | 16:12.09 |
| | Are your latest changes pushed to your repo? | 16:12.41 |
| henrys | fantastic eclipse last night here in my timezone. | 16:21.24 |
| kens | didn't get up at 03:30 to see it | 16:22.03 |
| henrys | would have been just at sunset on the west coast not sure if they saw it. supermoon - best one I've seen. | 16:22.43 |
| Robin_Watts | tor8: bug696148 looks like a genuine bug. | 16:28.22 |
| | The file has a CID font with 1 descendant font. That font is called "GlyphLessFont" | 16:29.02 |
| kens | THat looks like one of ours | 16:29.15 |
| fredross-perry | Robin_Watts: yes everything is in my repo regrding proofing. | 16:29.31 |
| Robin_Watts | The CID font has a specified default width of 500, but no other widths arrays. | 16:29.36 |
| kens | Still sounds like one of ours :-) | 16:29.48 |
| Robin_Watts | fredross-perry: Last time I looked there were problems with styles etc. | 16:29.53 |
| kens | The text is all in Tr 3 | 16:29.57 |
| Robin_Watts | kens: I believe it's output by tesseract. | 16:29.59 |
| fredross-perry | styles: | 16:30.08 |
| | styles? | 16:30.11 |
| kens | Robin_Watts : yes sorry I should have said one of *mine* | 16:30.18 |
| Robin_Watts | TABs vs spaces etc. | 16:30.20 |
| kens | I supplied them that font | 16:30.23 |
| Robin_Watts | kens: Right. | 16:30.32 |
| fredross-perry | oh yes. iâll fix that today. | 16:31.00 |
| kens | Their previous font was not good and broke Ghostscript so I gave them a valid (and smaller) font | 16:31.04 |
| Robin_Watts | We ask freetype for the advance for each glyph, and get back 0 (i.e. the default is not being consulted). | 16:31.08 |
| | hence we think that there is a space between every glyph. | 16:31.20 |
| fredross-perry | anything more to be done re: performance? | 16:31.28 |
| Robin_Watts | fredross-perry: Not for the release, certainly :) | 16:31.39 |
| fredross-perry | ok | 16:31.50 |
| kens | Robin_Watts : there are no real glyphs in the font | 16:31.53 |
| Robin_Watts | and probably not until we have at least a sniff of a customer being interested. | 16:32.03 |
| kens | Hence the name..... | 16:32.08 |
| Robin_Watts | Fonts in mupdf are traditionally a tor area, so I'll wait to hear back from tor. | 16:33.09 |
| kens | OK. The problem as I recall was that their prevous font broke txtwrite, but I could be making that up | 16:33.36 |
| | FWIW GS' txtwrite produces what looks like sensible output | 16:34.29 |
| | But we don't get the 'NC' or '2' between the solenoids | 16:35.18 |
| | Seems Acrobat doesn't either, must be not text in the original | 16:36.11 |
| | Right, heading off, night all | 16:36.58 |
| tor8 | Robin_Watts: ah. I think we should consult the PDF widths, but we only have the glyph index not the character index so I'm not sure how we'd go about it. | 17:24.19 |
| | I'll look into it tomorrow, it's getting late today | 17:24.28 |
| fredross-perry | robin_watts: tab/space issue should be fixed now. | 18:24.40 |
| Robin_Watts | fredross-perry: Ta. I'll look over your changes tomorrow then. | 18:25.20 |
| fredross-perry | right | 18:25.27 |
| Robin_Watts | fredross-perry: Ugh. You just did a fixup commit at the end? | 18:34.41 |
| fredross-perry | yes. Unfortunately the commits that needed fixing were several pushed commits back. | 18:35.23 |
| Robin_Watts | fredross-perry: This is git :) | 18:35.46 |
| fredross-perry | indeed. | 18:35.53 |
| Robin_Watts | A really useful command: git rebase -i HEAD~10 | 18:36.20 |
| fredross-perry | and anyway, the full code for proofing is sprinkeld over several commits anyway. | 18:36.32 |
| Robin_Watts | That pops up a window with a list of the last 10 commits in, preceeded by "pick". | 18:37.01 |
| | You can reorder the lines there, and save the file, and it will reorder the commits. | 18:37.15 |
| | by changing 'pick' to various other things, you can squash commits together. | 18:37.33 |
| | So you can (and should) rewrite history to produce the tidiest set of commits possible. | 18:37.56 |
| fredross-perry | hmmm. | 18:37.56 |
| Robin_Watts | Also, every commit message should be of the form: | 18:38.39 |
| | <72 chars or less summary>\n\n<longer description over as many paragraphs as required> | 18:39.06 |
| fredross-perry | got it. Iâll probably just take it apart and put it back together as one. Take me a while. | 18:40.05 |
| Robin_Watts | fredross-perry: It's really worth learning git rebase -i. | 18:40.19 |
| | It's massively powerful. | 18:40.26 |
| | It's the git command I use most. | 18:40.32 |
| | Typically, if I find something I broke a few commits back, I make a small commit that fixes it. | 18:40.56 |
| sebras | Robin_Watts: perhaps git add -p or git commit -p | 18:41.05 |
| Robin_Watts | Then I 'git rebase -i HEAD~10' and move the line for the fixup commit to be just after the commit it fixes. | 18:41.32 |
| | I change that line from 'pick' to 'f' and save the file. | 18:41.44 |
| | That tells git that my commit was a 'fixup' and it rolls them in together. | 18:42.02 |
| | Also, if you 'git rebase -i HEAD~10' and change any of the 'pick' to 'r' and save the file, it'll give you the option to reword the commit message. | 18:42.55 |
| | So you can fix typos, and formatting without having to redo everything. | 18:43.11 |
| sebras | Robin_Watts: sometimes 'edit' is useful too, if you haven't got the fixup patch yet. | 18:43.37 |
| Robin_Watts | sebras: yeah, but 'edit' means you have to get your change right during the rebase phase. | 18:44.06 |
| | I prefer to spend as little time as possible in the rebase process. | 18:44.19 |
| | The nice thing about rebase is that you can do it in tiny increments and so not have to try to remember to everything at once. | 18:44.53 |
| sebras | and most importantly git rebase --abort if you end up in a state that you don't know how to recover from (but you will lose any changes that you did during the rebase phase) | 18:45.40 |
| | I've found that I sometimes discover new things that need fixing or cases that I've forgotten when I have take a series of commits that were not logically separate and tried to separate them into logically independent commits. | 18:48.47 |
| | granted, it takes time. but sometimes it does pay off because you look at your code once more and try to figure out how you can make each patch obviously correct to the recipient. | 18:49.33 |
| Robin_Watts | It's HUGELY better for the codebase in the long run. | 18:51.48 |
| | You end up with a series of coherent thought out commits rather than "try this", "oops, no, try this", "almost there..." etc. | 18:52.22 |
| fredross-perry | thanks guys | 18:53.55 |
| Robin_Watts | Sorry, I know this is a pain. | 18:54.19 |
| fredross-perry | sure, but thansk for all the detailed help. | 18:58.11 |
| | Robin, Joseph: I reworked my repo so there's now just two commits, one for proofing, and one for iCloud. | 21:59.53 |
| | Forward 1 day (to 2015/09/29)>>> | |
IRC Logs