| | <<<Back 1 day (to 2014/09/14) | 2014/09/15 |
| bigeast | Hi, are there any mupdf developers or users there? I find mupdf on x11 can't display Chinese file name correctly, and I modify the source code in platform/x11/x11_main.c a little and it works fine. I'm not sure if this is a bug or just related to my environment. Please check this gist: https://gist.github.com/bigeast/6fb5dd578e7b7fdaf668 | 03:04.47 |
| tor8 | bigeast: like you mention, it's probably a limitation in your window manager | 08:52.29 |
| | XmbSetWMProperties depends on the current locale for its encoding | 08:53.29 |
| | which is often, but far from always, UTF-8 | 08:53.54 |
| kens | Morning tor8 | 08:57.15 |
| | It was getting lonely here this morning :-) | 08:57.29 |
| sebras | kens: hi | 09:00.23 |
| kens | Morning sebras | 09:00.30 |
| chrisl | kens: ping | 09:48.27 |
| kens | morning chrisl | 09:48.32 |
| chrisl | Morning..... | 09:48.38 |
| kens | Didn't see you because you don't have voice status, I wonder why | 09:48.52 |
| chrisl | Probably because my connection dropped a few times over the weekend | 09:49.22 |
| kens | Still, I woudl expect you t be assigned it now | 09:49.34 |
| chrisl | I had to "identify"..... | 09:49.59 |
| kens | Oh.... | 09:50.03 |
| chrisl | If I want to send parameters to a device from our PS code, what's the convention for doing so? setpagedevice, .setpagedevice, .putdeviceparams?? | 09:50.37 |
| kens | Hmmm..... | 09:50.58 |
| | I'm not sure there is a convention :-) | 09:51.04 |
| | But, you may *have* to use setpagedevice. | 09:51.15 |
| chrisl | Or if there's no convention, do you have a preference? | 09:51.15 |
| kens | If you don;t use setpagedevice, then the parameter will not be reflected in the saved page device dictionary,so a call to currentpagedevice will eb incorrect, unless you add the key to the volatile keys list, so it gets read on every call to currentpagedevice | 09:51.59 |
| | I don't know whether you feel that's important. DO you need it to follow gsave/grestore ? | 09:52.29 |
| chrisl | This is when we're shutting down the interpreter, so it's probably not vital - but on basis, setpagedevice is probably best | 09:53.10 |
| kens | I'd guess os, it probably prevents the kind of confusion I was fighting with the other week | 09:53.31 |
| | Presumably you saw my comment son #695486 ? | 09:54.12 |
| chrisl | In general, I'd prefer to use "proper" PS operators, anyway - it's less confusion when someone else looks at the code | 09:54.12 |
| kens | Yes, also true. | 09:54.20 |
| chrisl | I just cluster tested the fix for 695486 | 09:54.35 |
| kens | If its the same as what I did, it passes | 09:54.47 |
| chrisl | I think it's sort of the opposite - I initialise c_alone to false - as false is the most common case | 09:55.24 |
| | I *hate* the way that "current chunk" stuff works :-( | 09:55.35 |
| kens | Looking at hte way the tets works, that means a more extensive check, becuae it'll calculate ctop-cbot and so on, so it might be slower I felt | 09:56.12 |
| | Whereas setting ti to true caused it to fall out on the first part of the test | 09:56.30 |
| | NB, having an uninitialised variable means its (usually) nont 0, so the code path is (generally) the same by setting it to true | 09:57.18 |
| chrisl | It should only ever happen with the very first allocation call to a new allocator, so it's unlikely to be a measurable difference | 09:58.24 |
| kens | I wasn't sure about that, but if you are, NP | 09:58.42 |
| chrisl | Yeh, as soon as we allocate a "real" chunk to use, cc will contain the values from that | 09:59.22 |
| kens | OK good enough for me | 09:59.33 |
| chrisl | But I don't understand why cc isn't a pointer to the current chunk, instead of copying the contents of the chunk into cc when we "open" it, and back again when we "close" it | 09:59.44 |
| kens | I couldn't possibly comment :-) | 09:59.59 |
| | It did surprise me though, I expected a seg fault when I saw ir | 10:00.13 |
| chrisl | I *suspect* it dates from the time that traversing a pointer was a more expensive operation than directly accessing the struct, so the expense of the copying was ameliorated by the quicker access - but that hasn't been true for many, many years...... | 10:01.38 |
| kens | Hmm, you owuld need to be accessing the member quite a bit for that to be the case, but I guess so | 10:02.17 |
| | Huh, I'd very much like to know how the 'current' font is pointing to the pdfwrite font cache when we close the interpreter. | 10:04.29 |
| chrisl | Oh my...... :-( | 10:06.43 |
| kens | I'm not sure how it happens at all. the interpreter executes a restore, and the current fotn seems to be pointing at the last font used in the job (which is bad anyway). And somehow that is pointing at the pdfwrite font cahce. I have no clue as to how | 10:07.36 |
| | I sort of suspect that the job has mismatched gsave/grestore, but..... | 10:08.05 |
| chrisl | Yes, but the pdfwrite copied font should never be referenced by a graphics state, should it? Or if it is, it should only be in a context controlled by pdfwrite (i.e. *after* interpretation is complete) | 10:09.23 |
| kens | A copied font should *never* be in a graphics state | 10:09.49 |
| | And this does not appear to be a copied font. Neverheless, its poiting at the pdfwrite font cache | 10:10.07 |
| | But not when I copy the font it isn't :-( | 10:10.20 |
| chrisl | Are there any cases where the font copying code might decide not to copy, just return a reference? I don't remember there being | 10:10.50 |
| kens | Oops, there it goes. | 10:10.55 |
| | Looks like there's a self-reference or soemthing. | 10:11.13 |
| | Oh good, my books for the staff meeting flights have shipped. Nice to have some good news. | 10:11.43 |
| | chrisl I can't think of any way for the font dir from pdfwrite to be copied into a font in the interpreter :-( | 10:24.39 |
| | But it seems to be happening somehow | 10:24.48 |
| chrisl | Hmmm, there's nothing springs to mind - I can probably take a look this afternoon, if you like | 10:26.27 |
| kens | It might help if you have some time | 10:26.42 |
| chrisl | I have a bemusing cluster test to look at first....... | 10:28.26 |
| kens | Your last run ? | 10:28.35 |
| chrisl | Yeh | 10:28.38 |
| kens | Hmm, you seem to have 2 sets of changes | 10:29.13 |
| | 1 for hte c_alone and one somethign to do with gb_print | 10:29.24 |
| | or even bg_print | 10:29.32 |
| chrisl | Yep. the c_alone one is fine, I tested that before | 10:29.43 |
| kens | and a setpagedevice | 10:29.53 |
| | Is that really correct ? with a single '<' | 10:30.21 |
| chrisl | Where? | 10:30.43 |
| kens | In the #ifndef PSI_INCLUDED block in imain.c | 10:31.01 |
| | "< /setpagedevice .systemexec" | 10:31.25 |
| chrisl | That's not what's in my local copy - it must be a quirk of the diff | 10:31.53 |
| kens | Oh.... | 10:31.59 |
| | TO be honest, its only 29-02.ps that's different it seems | 10:32.50 |
| chrisl | But it looks like it's causing an extra page to be emitted with some jobs.... weird | 10:33.00 |
| kens | Well just that one job | 10:33.22 |
| chrisl | Yes, just that job..... | 10:33.36 |
| kens | gs to run it | 10:33.45 |
| | I wonder if its somethign to do with the 3 copies | 10:34.37 |
| | Its setting /#copies, which is sort of setpagedevice related | 10:35.09 |
| chrisl | Could be, but I thought we'd be all done with that by the time we're shutting down | 10:35.30 |
| kens | Hmmmm | 10:35.32 |
| | The test says three pages, and we only emit 2 | 10:35.59 |
| chrisl | Hrm, I get 9 pages out..... | 10:36.55 |
| kens | Oh no, the 3rd page is rotated | 10:36.57 |
| | Distiller produces 6 | 10:37.04 |
| | My copy of GS produces 6 also | 10:37.36 |
| | oops no, that was the PDF file | 10:37.51 |
| | 5 pages in my GS | 10:38.26 |
| chrisl | Hmm, I get 8 pages out without that change in place | 10:39.17 |
| kens | ROFL | 10:39.25 |
| chrisl | Do we have more than one copy of 29-02.PS? | 10:39.47 |
| kens | Its possible | 10:39.59 |
| | Ah, mine is from the level 2 CET, the cluster seems to be testing the ps3cet | 10:40.27 |
| chrisl | I'm using the ps3cet one | 10:40.45 |
| kens | Let em get that one | 10:40.53 |
| | Still has 6 pages in Distiller | 10:41.40 |
| | Hmm, claims to be still level 2 cet as well, even though I grabbed it fromteh ps3cet folder | 10:42.19 |
| | I'musing the display device, what are you using ? | 10:42.42 |
| chrisl | ppmraw | 10:42.53 |
| kens | Still produces 5 pages for me | 10:42.55 |
| | Seems 8 pages from ppmraw | 10:43.44 |
| chrisl | I don't think setpagedevice should never cause an extra page to emitted | 10:44.09 |
| | s/never/ever | 10:44.17 |
| kens | I'm not certain, it might if there was content on the page (eg turningduplex on/off), I'd have to check the PLRM | 10:44.42 |
| chrisl | In that case, we'd have to emit that page before shutting down the device, anyway | 10:45.28 |
| kens | OK Distiller probably isn't a reliable test, and I'm guessing the display device isn't, the extra pages are caused by setting /#copies | 10:45.35 |
| | So, what extra page do you get with your change in place ? | 10:46.59 |
| chrisl | Yeh, I'm guessing it's because the job defines an EndPage proc | 10:47.44 |
| kens | Well, I'd try your patch, but the diff is wrong, so I can't.... | 10:48.43 |
| chrisl | Switching it to use .putedeviceparams avoids the extra page...... | 10:52.30 |
| kens | Well, that's probably the easiest answer. If it only takes effect at startup/shutdown, it doesn't matter if its not in the dictionary copy of the params | 10:53.13 |
| chrisl | It's *only* at shutdown | 10:53.32 |
| kens | Well I'd guess its not worth worrying about then | 10:53.47 |
| | If you want me to I can poke at it, I messed with setpagedevice the most recently of us | 10:54.07 |
| chrisl | No, I know why the extra page came out, I'm just wondering if I can work around that | 10:55.07 |
| kens | Oh OK | 10:55.17 |
| | Hmm, The Reg has an article saying that freenode users should change passwords, apparently there's been a security breach | 10:57.16 |
| chrisl | The other option is that I could manually update the page device dict | 10:57.26 |
| kens | Manually updating the page device dict is OK too. If this is sotred in the device params, then you can also just add it to the volatile keys | 10:58.06 |
| chrisl | It's a shame to add that overhead for one time per-instance it gets used in this way | 10:59.05 |
| kens | I'd prefer not to, it slows down every gsave | 10:59.24 |
| | marcos is up and about ? O.O | 11:05.17 |
| chrisl | kens: are you sure the font in this job is ending up in the graphics state? | 12:48.31 |
| kens | chrisl no, I just wrote about that, but I had falle offline :-( | 12:48.47 |
| chrisl | It looks to me like the font isn't being freed by pdfwrite | 12:49.10 |
| kens | I think the problem is that pdfwrite is not freeing its copy of the font. THis means that at end of job, we do garbage collection, which collects the copied font, a yeah whjat you said..... | 12:49.29 |
| | I *think* we have both a 'copied' and 'complete' font copy, and its only freeing the 'copied' one | 12:50.06 |
| | So all I need to do (I think) is work out where the copied font is being freed, and if 'complete' is not equal to 'copied' free that too | 12:51.31 |
| chrisl | I don't really understand why it needs two copies...... | 12:52.18 |
| kens | I can't remember now why it has 2 | 12:52.31 |
| | Especially since they are often the same | 12:52.43 |
| | Something to do with subset fonts | 12:53.00 |
| chrisl | Yeh, I sort of get that, but I would have thought the point it decides it needs a "copy complete" would be a good time to dispose of the "copy stripped" | 12:53.57 |
| kens | I think its to do with the 'embed below' percentage. If we are always subsetting then we do not need a full copy, so copied = complete. If we never subset, tehn we don't need a copy, so copied = complete. If we aren't sure, then we need a running subset, and a complete font, so we can decide which one we need | 12:54.54 |
| | Oh, chrisl, what's the invocation to get make to build libgs.so on Mac OS/X ? | 12:58.57 |
| chrisl | It doesn't, it'll build libgs.dylib - make so | 12:59.29 |
| kens | :-) Well, whatever its called, thanks. | 12:59.44 |
| | I'll just answer that SO question | 12:59.53 |
| | I like the email to support, its almost a haiku | 13:10.47 |
| chrisl | Some hint about the subject would be nice..... | 13:11.09 |
| kens | incomplete impre | 13:11.28 |
| chrisl | Well, I can't argue with that! | 13:12.09 |
| kens | Yay! freeing the 'complete' font fixes the problem. Thanks chrisl | 13:15.27 |
| chrisl | kens: makes me wish I'd actually done something to help! | 13:15.53 |
| kens | Well, you confirmed my suspicion :-) | 13:16.08 |
| | I hate the convoluted way stuff gets freed, its so easy to miss things like this. | 13:16.29 |
| | (in pdfwrite that is) | 13:16.37 |
| | I must have been having a good few days when I cleaned up the majority of the allocations. I wonder how many more little gotchas like this are lying around :-( | 13:17.18 |
| chrisl | Still, that's another pdfwrite memory leak zapped | 13:17.40 |
| kens | Oh yeah, I'[mpleased to fix it, and happy it didn't take longer to find | 13:17.57 |
| | Cluster test time | 13:18.31 |
| chrisl | There's a queue..... | 13:18.55 |
| kens | :-) | 13:19.00 |
| | I'm reasonably confident, so no rush | 13:19.11 |
| | I presume this is going to mean a new RC ? | 13:19.49 |
| chrisl | I think so. | 13:20.09 |
| kens | Stupid network :-( | 13:22.53 |
| | Can we kill pswrite while we're at it too please ? And import Ray's viewraw.ps, that should be safe enough since its just a utility. I'm not so happy about the SMask change though, since it breaks some files with pdfwrite | 13:26.08 |
| chrisl | the pswrite axing is already on the release branch. I really wasn't too bothered about viewraw.ps - is someone using it? | 13:27.26 |
| kens | No, it's new, but its kind of handy | 13:27.48 |
| | By no menas vital thoguh | 13:28.04 |
| chrisl | cluster claims I have differences with 29-02.PS but bmpcmp says "no"......... | 13:28.40 |
| kens | Weird..... | 13:28.52 |
| chrisl | And I ran it twice and it isn't listed as being different from the previous, which *suggests* not a indeterminism | 13:29.45 |
| kens | Definitely strange, I can't think what would be differetn, and so subtly different as to disappear with fuzzy comparison | 13:30.24 |
| chrisl | bmpcmp doesn't default to fuzzy comparison, does it? | 13:30.48 |
| kens | No, it shows even single pixels | 13:31.03 |
| | My mistake | 13:31.10 |
| chrisl | Phew, had me worried I'd been making the wrong assumption | 13:31.30 |
| kens | I just wasn't thinking it through | 13:31.49 |
| chrisl | Oh, I see, that latest version of my shut down changes results in only seven pages, rather than eight <sigh> | 13:33.29 |
| kens | O.O | 13:33.40 |
| | But clearly all 7 pages are the same as previously :-) | 13:34.05 |
| chrisl | Yes, indeed | 13:34.29 |
| kens | Odd that the last page shuold go missing | 13:35.13 |
| | I'd have expected one of the copies of page 3 | 13:35.31 |
| chrisl | Okay, reverting to the previous version of that change.... | 13:37.38 |
| henrys | kens: the pdfwrite question from catalin? That was an involved change spanning several commits I thought, wasn't it? | 13:42.17 |
| kens | Oh oh, *lots* of seg faults | 13:42.21 |
| | henrys I haven't a clue to be honest, I don't know what she's talking about | 13:42.37 |
| henrys | kens: I thought it was to fix FirstPage and LastPage in pdf, which ray helped with but maybe I'm confusing that with %d | 13:44.07 |
| kens | pdfwrite has always worked with FIrstPage and LastPage, because that's all done at the interpreter end,pdfwrite just sees what the interpreter sends. Ray did all (or at least most of) the '%d' stuff for one-file-per-page output | 13:45.12 |
| | I'm not at all clear on what Catalin's problem is | 13:45.27 |
| | I can give their test file a try if they've sent it some time in the pasty | 13:46.37 |
| | past* | 13:46.40 |
| henrys | we know it fails in 9.10 and works in 9.14 | 13:47.29 |
| kens | Oh, but I don;t have a copy of ghostpcl from that vintgage. I can always pull the source and build it I guess | 13:47.31 |
| | henrys I don't recall fixing anything that sounds like that. So its pretty hard to categorise it as being multiple commits or one (or just 'fixed in passing') | 13:48.10 |
| henrys | I guess marcosw1 can bisect it. But he may call foul because the bug originated on my watch ;-( | 13:48.19 |
| kens | :-D | 13:48.26 |
| | I can give it a whirl if you like, sounds more like a pdfwrite thing than anything else, though its hard to see what. I'd have to pull the 9.10 sources though, so I'd like to finish this bug first. | 13:49.07 |
| | What with Marcos having made it a P1 and all | 13:49.24 |
| henrys | I'll ask marcosw1 first then we'll see. | 13:49.35 |
| kens | OK fair enough | 13:49.42 |
| | I expect marcosw1 can bisect it quicker than me anyway | 13:50.04 |
| | cluster getting a good workout today, marcos' garage will be nice and warm when he gets up | 13:50.47 |
| chrisl | kens: I thought Catalin's problem was related to: http://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=3894e9c | 13:55.59 |
| kens | chrisl you could be correct :-) | 13:56.13 |
| chrisl | And thus: http://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=b442d9a0 | 13:56.34 |
| kens | But I've a feeling I unid that commit | 13:56.38 |
| | Oh well, there you go | 13:56.53 |
| chrisl | Well, poking around in BGPrint has been fun........ | 13:58.01 |
| henrys | so the undo fixed it? | 13:58.02 |
| kens | henrys, I don't know for sure, its a guess | 13:58.13 |
| | You could try re-instating the original patch and see if it goes wrong as described | 13:58.29 |
| chrisl | henrys: the problem is, we're not sure what else may have happened in between | 13:58.43 |
| kens | henrys it should never produce more than 1 extra page anyway, and that doesn't sound quite like what they are saying | 13:59.26 |
| henrys | kens: well if marcos is busy I'll get to bisecting some time today. Shouldn't be hard to track down. | 14:00.10 |
| kens | Hmm, actually, maybe it is. | 14:00.11 |
| | henrys, before bisecting, just try applying that first patch again, and see if it shows the problem. | 14:00.41 |
| henrys | I have to do a run to the airport and will be back in an hour or so. | 14:00.43 |
| kens | OK | 14:00.47 |
| henrys | kens: will do, makes sense | 14:01.00 |
| kens | Its pretty simple so it won't take long to check out | 14:01.31 |
| kens | grumbles once again about customers taking 'just one patch' because they are close to release and don't want to restart their testing. | 14:03.19 |
| chrisl | rayjj: I have a solution for the BGPrint seg fault | 16:01.31 |
| rayjj | chrisl: Great! | 16:01.40 |
| chrisl | rayjj: it's here: http://git.ghostscript.com/?p=user/chrisl/ghostpdl.git;a=commitdiff;h=d0f4f96 | 16:02.04 |
| rayjj | chrisl: I haven't finished reviewing the IRC logs... | 16:02.08 |
| | chrisl: OK, I looked at it. Seems to make sense, particularly the bit about letting the bg_print complete when BGPrint get set to false | 16:04.27 |
| | chrisl: the business with BeginPage/EndPage I don't quite follow -- particularly why BeginPage is relevant on shutdown | 16:05.15 |
| | chrisl: the EndPage returning //false seems to be enough to prevent an extra page | 16:05.42 |
| chrisl | rayjj: it explains why it was intermittent - if everything happened to get initialised before we reached the I/O table in gc, it would work, and if it didn't get to trying to initialise until gc was complete, it would (probably) work | 16:06.27 |
| rayjj | chrisl: I understand that the timing of gc of the IODevice table relative to the finishing of the the background print would cause indeterminate behavior, but how does that explain the need to zap BeginPage ? | 16:09.17 |
| | chrisl: sorry if I'm being dense -- coffee is not working yet | 16:09.51 |
| chrisl | rayjj: I wanted to ensure that an existing BeginPage didn't try to mark the page or do anything else that could trip us up at that stage | 16:10.15 |
| | It is, admittedly, a belts and braces (or suspenders, US!) addition | 16:11.29 |
| rayjj | chrisl: but main_finit can't cause invocation of BeginPage | 16:11.51 |
| kens | So MS is indeed buying Minecraft make Mojang for $2.5 billion. And Minecraft doesn't break even. We must be in the wrong business :-( | 16:12.53 |
| chrisl | rayjj: I believe the setpagedevice will implicitly start a new page | 16:13.46 |
| kens | It does do so, yes | 16:14.36 |
| rayjj | chrisl: oh, right. It does both Install and BeginPage | 16:14.38 |
| chrisl | I figure Install is safe enough..... | 16:15.38 |
| rayjj | chrisl: so if you had used .putdeviceprops, it wouldn't have been required, right ? | 16:16.23 |
| chrisl | I tried .putdeviceparams and it caused other problems | 16:17.04 |
| rayjj | and worrying about the PS level 'currentpagedevice' dict during gs_main_finit doesn't seem important | 16:17.08 |
| chrisl | rayjj: in theory I would agree - in practice, it's an assumption I'd rather not make, given how hard it can be to debug problems in those areas | 16:19.28 |
| robin_watts_mac | Bah. Didn't realise I'd closed this window. | 16:19.38 |
| | Did I miss anything? | 16:19.42 |
| kens | Nothing important | 16:19.50 |
| rayjj | chrisl: OK, well, the change is OK with me. I don't think it is worth digging into further | 16:19.51 |
| robin_watts_mac | has been working at a friends house today due to home being fumigated. | 16:20.07 |
| | The bloke didn't warn me that I couldn't be in the house while he was spraying the kitchen :( | 16:20.28 |
| kens | Why is he spraying the kitchen ? | 16:20.51 |
| chrisl | rayjj: using .putdeviceparams directly caused 29-02.PS to lose a page | 16:20.53 |
| robin_watts_mac | kens: We went on holiday to Bhutan. We thought it would be terribly clever to bring back a bag of bhutanese red rice. | 16:21.27 |
| kens | Oh, oh..... | 16:21.35 |
| robin_watts_mac | We didn't realise that we'd also be bringing back a load of bhutanese beetles too. | 16:21.45 |
| kens | I take it you brought back some tourists ? | 16:21.45 |
| robin_watts_mac | If this fails to kill the buggers, we're selling the house and moving somewhere else. Not going through all this again. | 16:22.16 |
| chrisl | I'll await the news of the Oxfordshire border being closed...... | 16:22.31 |
| kens | Nuke them! Its the only way to be sure..... | 16:22.45 |
| chrisl | That might make them stronger! | 16:23.02 |
| robin_watts_mac | They aren't 'dirty' (no diseases, no health issues), but we'd really rather they just buggered off. | 16:23.03 |
| kens | I wonder if they eat the local wildlife..... | 16:23.33 |
| robin_watts_mac | kens: They are about half the size of a grain of rice. | 16:23.46 |
| kens | Oh well, time to head off, goodnight all | 16:23.51 |
| robin_watts_mac | local wildlife would need to be pretty small. | 16:23.55 |
| kens | so, only small wildlife then | 16:24.00 |
| robin_watts_mac | Night kens. | 16:24.05 |
| chrisl | rayjj: I have to go - I'll sit on the commit until tomorrow morning (here), if something problematic springs to mind, leave a note here, or via e-mail | 16:25.08 |
| rayjj | chrisl: OK | 16:25.21 |
| chrisl | 'Nite all! | 16:25.42 |
| | Forward 1 day (to 2014/09/16)>>> | |
IRC Logs