| | <<<Back 1 day (to 2012/07/12) | 2012/07/13 |
| henrys | dogmatic69:you can create a bug report at bugs.ghostscript.com, attach the files and the relevant command line. We probably won't be able to do much without that. | 00:10.35 |
| dogmatic69 | henrys: I just updated tcpdf and it seems to be fine now | 00:11.59 |
| | maybe something changed and they also fixed the code? | 00:12.25 |
| henrys | maybe so | 00:14.27 |
| kens | ping Robin_Watts | 10:09.31 |
| Robin_Watts | pong kens | 10:14.09 |
| kens | funny result with bmpcmp, can you look at my last one please ? | 10:14.27 |
| Robin_Watts | Did your cluster thing time out too? | 10:14.30 |
| kens | No, my clusrter run was OK but bmpcmp says 'can't compare images | 10:14.47 |
| Robin_Watts | Ah. Images changed sized. | 10:14.50 |
| kens | Ah. | 10:14.59 |
| | That shouldn't have happened | 10:15.08 |
| Robin_Watts | looks like rotation? | 10:15.10 |
| kens | That's possible, there is some stuff I changed relating to that. | 10:15.26 |
| | OK thanks I'll do the testing here. | 10:15.35 |
| Robin_Watts | np. now to figure out why my run timed out... | 10:15.47 |
| kens | That is odd, my run earlier was just fine | 10:15.56 |
| Robin_Watts | tor8: ping ? | 10:22.50 |
| BusError | Hi guys, I was trying to compile mupdf on debian sid with host libraries, and there's a small problem with the host openjpeg library. I made a small patch for it, with an explanation. Once patch is applied, it compile and works properly: http://pastebin.com/khSvNcjN | 10:24.20 |
| Robin_Watts | BusError: Don't use shared libraries. shared libraries are bad. use our libraries, not the shared libraries. | 10:25.08 |
| tor8 | Robin_Watts: morning | 10:25.24 |
| Robin_Watts | tor8: Can you log into skype please? | 10:25.40 |
| tor8 | BusError: it may compile, but it's masking a bug | 10:26.22 |
| | Robin_Watts: I don't have skype installed... | 10:26.30 |
| Robin_Watts | tor8: Ah, damn. | 10:26.41 |
| tor8 | any particular reason? if it's important I could install it. | 10:27.02 |
| BusError | well the readme stated the built in libraries were for windows or xcode | 10:27.22 |
| Robin_Watts | I have a customer asking me questions (he doesn't use the VOIP stuff, just the text messaging) | 10:27.26 |
| | BusError: No. The supplied projects are for MSVC or xcode. The libs are used for everything. | 10:27.50 |
| tor8 | I can't understand why anybody wants to use Skype as an IM when there are dozens of better and less locked down choices | 10:28.05 |
| | with decent clients... | 10:28.09 |
| Robin_Watts | I suspect he uses skype for VOIP too, just not with me. | 10:28.48 |
| | And in fact, I have had con-calls with them over it. | 10:28.55 |
| tor8 | Robin_Watts: can it wait till after lunch? | 10:29.19 |
| Robin_Watts | Sure. I'll keep talking to him. | 10:29.31 |
| tor8 | I'll install it and log in once I get back | 10:29.41 |
| | Robin_Watts: okay, I'm in, if you invite me now I can read the logs when I get back | 10:32.16 |
| BusError | Robin_Watts, I see no options in the makefile to use thirdparty/ stuff... it defaults to using the system ones on Linux it seems | 10:36.38 |
| Robin_Watts | BusError: In gs? | 10:36.55 |
| | Where did you get your gs source? | 10:37.07 |
| BusError | mupdf | 10:37.08 |
| Robin_Watts | OK. mupdf certainly uses Thirdparty stuff. | 10:37.25 |
| | that's what Makethird is about. | 10:37.33 |
| BusError | ah, forgot to make clean | 10:38.46 |
| chrisl | Robin_Watts: I think I've found the cause of the GS stack corruption..... | 11:29.31 |
| Robin_Watts | the gc_signal thing? | 11:29.54 |
| chrisl | Yeh | 11:29.58 |
| Robin_Watts | ooh, excellent. pray tell... | 11:30.05 |
| chrisl | http://git.ghostscript.com/?p=user/chrisl/ghostpdl.git;a=commitdiff;h=5822bc02 | 11:30.07 |
| Robin_Watts | ok. but if that was the problem, why didn't moving the pointer out of the mem into the lib_ctx solve it too? | 11:31.17 |
| chrisl | I thought it did solve it, just made it horrible slow? | 11:31.44 |
| Robin_Watts | ok, so if that was the problem, why did moving the pointer out of the mem make it horribly slow ? | 11:32.06 |
| chrisl | I *think* that was because in doing that, we'd end up mark/sweeping *all* saved spaces, instead of just the currently active one | 11:32.54 |
| | We should never GC a "saved" space, because that space cannot change | 11:33.29 |
| Robin_Watts | AIUI, the pointer is written to to say "we need a gc". | 11:34.21 |
| | No indication is ever given as to which space needed the gc. | 11:34.33 |
| | My patch never changed which spaces were gc'd. Just how they found the indicator variable. | 11:35.30 |
| | There is an argument that says "who cares, it works", but I'd like to feel that at least one of understands it :) | 11:36.25 |
| chrisl | I don't have *all* the answers, I just tracked down that was where the pointer we being put back to an "invalid" value - so that is *definitely* what caused the corruption | 11:37.11 |
| | s/we/was | 11:37.25 |
| Robin_Watts | kens: Did you see the email exchange that miles copied to support yesterday? between him and a customer? | 11:37.49 |
| | (I'm being careful what I say in a public forum, let me move to a private tab) | 11:38.40 |
| kens | Robin_Watts : yes | 11:39.25 |
| | but have not seen a report yet | 11:39.31 |
| Robin_Watts | It just arrived to support | 11:39.41 |
| | (see comments on private tab) | 11:41.13 |
| chrisl | Hmm, looks like pdfwrite is falling back to type 3 bitmap font for some reason, where Distiller doesn't. Spectacularly, they haven't sent the original file <sigh> | 11:50.25 |
| Robin_Watts | WONTFIX CUSTOMERTOOTHICK | 11:52.17 |
| kens | :-) | 11:52.23 |
| | OK well I'll look at the files. | 11:52.41 |
| chrisl | Robin_Watts: I have a *theory* about the performance problems caused by moving the pointer around...... | 11:52.51 |
| Robin_Watts | I love a good theory. | 11:53.03 |
| chrisl | If you look in gsalloc.c line ~1745 | 11:53.27 |
| Robin_Watts | Ah, right. With the dodgy comment. | 11:54.04 |
| chrisl | That bit code checks if the pointer exists, and write the current value from the current space back to the target of that pointer | 11:54.10 |
| Robin_Watts | Yes. | 11:54.38 |
| | No, sorry... | 11:54.47 |
| | It writes "the signalling value" back from the current space to the target of that pointer. | 11:55.02 |
| | but, as I read the code, every indexed space gets the same signalling value. | 11:55.37 |
| chrisl | Yes, which should be something like -100 for a *garbage collected space* | 11:55.55 |
| | But will be 0 for a non-garbage collected space | 11:56.20 |
| Robin_Watts | OK. But my patch didn't change what values were stored into each space. | 11:56.41 |
| | or what values each space stored back. | 11:56.48 |
| | It only changed the mechanism by which they found where to signal. | 11:57.07 |
| chrisl | But if we write zero to that pointer, *every* time we check whether we should do a gc, we'll do one | 11:57.38 |
| Robin_Watts | sorry? | 11:58.02 |
| chrisl | We do a gc when the variable reached >=0 | 11:58.52 |
| | That code needs to differentiate between garbage collected spaces and non-gc spaces | 11:59.42 |
| Robin_Watts | and how did my patch stop it differentiating? | 12:00.26 |
| chrisl | Because with your patch *all* the memory spaces would find the pointer valid in the current context | 12:01.04 |
| | Remember, I did say it was a theory - and it doesn't account for alexcher's patch causing the slow down..... | 12:02.16 |
| Robin_Watts | OK. I can't see a flaw in that immediately. | 12:02.26 |
| | so I propose to accept it and let it go. | 12:02.33 |
| | That does assume that the code that writes the pointer in is smart enough to only write it into gc'd spaces. | 12:03.10 |
| | which it may be - there is some 'mem_stable' stuff in that code that I don't entirely follow. | 12:03.26 |
| kens | The main difference in the PDF files is the size of the content streams | 12:04.00 |
| chrisl | kens: isn't that because of whole bunch of the text has been rendered in inline images? | 12:04.30 |
| kens | COuld be, which is bad, but I think they've used an old version of GS | 12:04.54 |
| Robin_Watts | so *maybe* we could use a version of my patch with a single pointer, but with a 'bool gcable' thing in each memory space? | 12:05.01 |
| | That would be neater (I feel) than having to reset the pointer on a restore? Though the behaviour on a restore is already so complex and baroque that this may not be much of an issue. | 12:06.06 |
| chrisl | Robin_Watts: we could, yes, but I feel we lose a big part of the benefit if we do that | 12:06.38 |
| Robin_Watts | what do we lose? | 12:06.57 |
| chrisl | We remove one entry from the gc_status struct, and put one back | 12:07.22 |
| Robin_Watts | right, but the one we put back is a static one that never changes. | 12:07.56 |
| | There is no need to walk all the different spaces anymore. | 12:08.13 |
| | (oh, well, we still need to walk the spaces to put the signalling value in) | 12:08.40 |
| chrisl | I don't currently know where we'd have to mark the gc'ed spaces, either, but that's probably easy enough to find.... | 12:09.28 |
| kens | Amusingly the decompressed files are much closer in size than the compressed files.... | 12:09.44 |
| chrisl | kens: I don't think it's worth spending more time on with so much missing information...... | 12:10.45 |
| kens | Just having a quick poke | 12:11.09 |
| | I've written teh response email already ;-) | 12:11.18 |
| Robin_Watts | is it something stupid like us not using ZLIB_COMPRESSION_BEST or whatever it is? | 12:11.33 |
| kens | Of course Acrobat has broken the content stream up into lots of smaller ones | 12:11.36 |
| | Robin_Watts : I'm not sure | 12:11.45 |
| chrisl | kens: So now you're removing the swear words? | 12:11.47 |
| kens | The diff of the uncompressed files is < 300k while the compressed ones differe by 400k | 12:11.59 |
| | chrisl no, just making a bit more certain ;-) | 12:12.13 |
| | It loosk like acrtobat has converted much of the text to vectors! | 12:12.39 |
| | The content streams are radically different | 12:13.05 |
| chrisl | Hmm, strange, the Distiller output had three fonts (Arial variants) not embedded, I think we had one, and a bunch of text as inline images | 12:13.39 |
| kens | I see lots of ' x y m x y l S' going on in our output | 12:14.10 |
| tor8 | Robin_Watts: the Makethird makefile picks up directories in the thirdparty directory if they exist, otherwise tries to use the system libraries. | 12:14.44 |
| kens | It 'looks' like dashed lines being presented as each dash individually | 12:14.54 |
| tor8 | the problem with this particular instance is that distros haven't upgraded their libopenjpeg in ages... | 12:15.11 |
| kens | Oh actually that is in the acrobat output too | 12:15.23 |
| | I see Hin-Tak is making friends again | 12:17.33 |
| chrisl | Interesting, if some had posted something like on a bug when he was handling bugzilla, he'd probably have banned them | 12:19.38 |
| kens | Yep | 12:19.55 |
| chrisl | Hmph, shame, I don't have admin rights on bugzilla ;-) | 12:20.34 |
| kens | Probably just as well I don't :-) | 12:20.57 |
| | chrisl I don't see any inline images in the page content streams | 12:21.57 |
| | The inline images I see are the CharProcs for the type 3 font | 12:22.12 |
| chrisl | kens: I was just going through Acrobat preflight - even so, I wouldn't be surprised if that accounted for much of the size difference | 12:23.57 |
| kens | One difference is that the distiller file is a PDF 1.5 and uses compressed xref | 12:24.11 |
| | chrisl I don't think so | 12:24.22 |
| | I used the 'audit space usage' and it showed the majority of the difference in the size of the content streams | 12:24.51 |
| | The acrobat file also uses object streams | 12:25.59 |
| chrisl | 'audit space usage' is a new one on me..... | 12:26.01 |
| kens | Just a moment | 12:26.18 |
| | Advanced->Print Production->PDF Optimizer' | 12:26.51 |
| | Then press the 'audit space usage' button at top right | 12:27.01 |
| | THis is Acrobat 9 | 12:27.10 |
| | I haven't found it in X yet | 12:27.22 |
| chrisl | Never noticed that before | 12:28.53 |
| kens | Its quite useful for these sorts of problems | 12:29.06 |
| chrisl | It's not the type of problem I often deal with - lucky me! | 12:29.25 |
| kens | It seems to be MIA in Acrobat X.... | 12:29.42 |
| chrisl | Probably judged to be "useful" and therefore has no place in Acrobat | 12:30.31 |
| kens | It seems like DIstiller just does a better job of compression, possibly that's why it splits up the content streams so much. | 12:35.03 |
| | The big difference is that Distiller compresses 3.02 Mb of content streams to 240k while we compress 3.21 Mb to 600k. | 12:41.38 |
| | BTW Robin_Watts thanks for fixing the bmpcmp display :-) Much better | 12:43.10 |
| Robin_Watts | kens: no, thanks to you and ray for prompting me to fix it :) | 13:04.24 |
| chrisl | Yay, my copy of 'The Apocalypse Codex" is coming early :-) | 13:25.42 |
| kens | is it released ? | 13:27.02 |
| chrisl | It's been out in hardback for a while, I just got a mail from Amazon saying delivery brought forward from 21st, to 14th | 13:28.03 |
| kens | oogh, must order it | 13:28.12 |
| paulgardiner | Robin_Watts: need to build mujstest-v8 for linux. Where can I find a copt of the v8 libs? | 14:57.51 |
| Robin_Watts | http://ghostscript.com/~robin | 14:58.08 |
| paulgardiner | ta | 14:58.14 |
| Robin_Watts | v8-3.9.xxxx.tgz | 14:58.29 |
| henrys | the brits are running away with the Tour | 15:06.48 |
| kens | Apparently so | 15:06.57 |
| chrisl | Agh, don't jinx it! | 15:07.17 |
| Robin_Watts | henrys: Now you know why we don't watch it. | 15:07.38 |
| | In Britian sport is something you watch so you can support the underdog and be underwhelmed by our performance. | 15:08.11 |
| chrisl | Another way to put that is that we're only fascinated by sports that we're crap at! | 15:08.48 |
| Robin_Watts | Still (to quote John Cleese) at least when we have a "World Series" we invite other countries :) | 15:09.01 |
| henrys | maybe you just have lawful pharmacists. | 15:09.02 |
| | chrisl:looking at the fix. | 15:11.02 |
| paulgardiner | Hmmm! I have cluster SEGVs that I cannot reproduce locally under windows or 32bit linux. :-) | 15:17.12 |
| Robin_Watts | paulgardiner: Do you have access to a 64bit linux box ? | 15:17.54 |
| paulgardiner | Not that I know of | 15:18.16 |
| henrys | chrisl:so psignal_status doesn't really belong at the level it is at, it should be in lib_ctx and we should need this save and restore stuff. right? But I guess if the fix works I'm okay with it. | 15:18.20 |
| | s/should/shouldn't | 15:18.35 |
| chrisl | henrys: psignal_status is specific to each space - it should only be set in gc spaces, and not in non-gc spaces. | 15:19.35 |
| Robin_Watts | chrisl: Could we: | 15:20.03 |
| | 1) put the psignal in the lib_ctx | 15:20.24 |
| | 2) put the value to store in the lib_ctx | 15:20.39 |
| | 3) have the code that does *psignal = value only do that if it's a gc space? | 15:21.20 |
| | That would simplify everything, avoid the need to do the nasty searches for which spaces to mark the pointer in, and avoid the restore hackery. | 15:22.42 |
| chrisl | It doesn't simplify the patch..... | 15:23.01 |
| Robin_Watts | The only problem is knowing whether a space is a gc space or not. Presumably we can tell that by looking to see if mem-stable != mem? | 15:23.37 |
| | chrisl: It complicates the patch, but simplifies the code. | 15:23.50 |
| chrisl | Not significantly, in my opinion - and I like the least invasive change that actually fixes the problem | 15:24.25 |
| Robin_Watts | Hmm. I disagree with that assessment, but... | 15:25.13 |
| henrys | chrisl:best to let alexcher and ray have a say too. | 15:35.12 |
| chrisl | henrys: alexcher has already commented on the bug | 15:35.28 |
| henrys | oh my I've ruffled Hin-Tak's feathers. | 15:37.24 |
| kens | :-) note the earlier log comments | 15:37.40 |
| Robin_Watts | We could easily go with Chrisl's patch, and maybe open an enhacement to clean the code up a bit? | 15:37.54 |
| chrisl | Robin_Watts: that, I think, would be the sensible option | 15:38.15 |
| marcosw | henrys: are we having a support meeting today? | 16:34.16 |
| henrys | if you'd like | 16:34.43 |
| | I did change a couple of your blockers | 16:35.04 |
| | are you okay with that? | 16:36.06 |
| marcosw | you mean 693085? What was the other one? | 16:36.47 |
| henrys | I thought there was another on mvrhel_laptop's plate I changed. | 16:37.20 |
| marcosw | 693061 is one of the other ones, but that is still a blocker | 16:38.05 |
| | The other mvrhel_laptop blocker was 692892, but that was fixed. | 16:39.16 |
| henrys | oh I guess I wanted to unblock that one for the same reason - no customers. | 16:39.24 |
| | 693061 that is. | 16:40.22 |
| marcosw | I'm happy to consider 693085 not a blocker, but if so I'm going to remove pxlcolor from the nightly/regression testing. Seems no point in testing things that we don't care about. | 16:42.15 |
| henrys | marcosw:I do care about it we just can't stop a release for it. | 16:43.01 |
| | marcosw:maybe I didn't understand the bug - all files are broken? | 16:44.45 |
| marcosw | I believe all files that use color are broken. | 16:45.49 |
| henrys | well I'll make it a blocker again. | 16:46.18 |
| | marcosw:okay I fixed the bug - sorry I thought it was one isolated file. | 16:48.20 |
| marcosw | my bad, I should have listed all the files affected. | 16:48.32 |
| | The same issue with bug 693061, it affects many files but I didn't list them. | 16:49.04 |
| henrys | so author is Robin_Watts and committor mvrhel_laptop | 16:50.48 |
| Robin_Watts | It was michaels patch. | 16:51.00 |
| | He sent it to me to test it (and maybe make a tiny fix), and so it fell to me to commit it. | 16:51.33 |
| henrys | marcosw:anything else for the meeting? Did you want to go through the bugs this week? | 16:52.36 |
| marcosw | there are only three new bugs, so probably not worth doing. However there are bugs assigned to support that we can look at together. | 16:53.12 |
| henrys | okay | 16:53.21 |
| marcosw | 692963 is the first one. I'm not sure why it was reopened. | 16:54.39 |
| henrys | well let's close that one, are you driving? | 16:55.30 |
| marcosw | yes, I'll drive. | 16:56.13 |
| henrys | next is the evolver folks didn't you report them to scott? | 16:56.46 |
| | I guess I did. | 16:57.20 |
| | should go to michael though | 16:57.40 |
| marcosw | Yes, so I guess we can leave it assigned to support. Unless we should make an account for scott. | 16:57.44 |
| Robin_Watts | Scott has a bugzilla account | 16:57.54 |
| henrys | marcosw:that's a pretty good idea let's assign it to scott | 16:58.40 |
| marcosw | 693030 is next. | 16:59.25 |
| henrys | probably should CC michael though as it looks like a regression | 16:59.26 |
| kens | Goodnight all | 17:00.27 |
| henrys | that could also go to scott | 17:01.05 |
| marcosw | 693030 already has a patch attached, so it seems a same to not not put it in 9.06 | 17:01.45 |
| | brb | 17:01.54 |
| henrys | what's next I must have mine in a different order | 17:01.58 |
| | okay | 17:01.59 |
| marcosw | I'm back. | 17:04.50 |
| | Is 693030 the one you suggested should go to scott? | 17:05.14 |
| henrys | yeah | 17:05.40 |
| marcosw | will do. | 17:05.46 |
| | 693098 is next. | 17:06.19 |
| henrys | you can put that in my black hole. | 17:07.02 |
| marcosw | are you the x11alpha guy? | 17:07.28 |
| henrys | yeah I'll start taking those, though it's likely to end up with michael | 17:08.10 |
| marcosw | done. Next is 693157. | 17:08.26 |
| henrys | alexcher:did you have a followup for that one. | 17:09.52 |
| | ? | 17:09.53 |
| | probably should go to russel. | 17:10.06 |
| marcosw | I think it might just be a problem with QuickBooks. I know that I when I print from Quicken the output is often scaled incorrectly. | 17:11.54 |
| henrys | we need an email to scott about 693161 and assign to scott | 17:12.37 |
| | marcosw:but alex said regular gs devices were okay - sounds like the windows printer stuff | 17:13.03 |
| marcosw | you're right, I only read the original description. | 17:13.37 |
| | is there any point to assigning bugs to Russell? Do we have any hope of him fixing them? | 17:14.49 |
| henrys | yes he will fix some things. | 17:15.14 |
| | and assign 693175 to tor for probable disposal. | 17:17.11 |
| marcosw | okay | 17:18.52 |
| henrys | and that's it right? | 17:20.34 |
| marcosw | yup. I'll email scott re. 693161 | 17:21.59 |
| chrisl | Time for me to finish - if someone can point Ray at Bug 692684, he can post any questions or concerns about the patch on the bug | 17:26.36 |
| Robin_Watts | Can I get a sanity check please? | 18:47.20 |
| | gs/base/siscale.c, line 491. | 18:47.39 |
| | ss->tmp = (byte *) gs_alloc_byte_array(...); | 18:47.58 |
| | why is there a *sizeof(float) in there ? | 18:48.05 |
| | tmp is used to hold bytes, not floats. | 18:48.26 |
| ray_laptop | Robin_Watts: is it to account for Colors ? (which would be wrong). In zoom_x it sets tp = tmp + c | 19:01.11 |
| Robin_Watts | Colors = Number of components, aiui. | 19:03.39 |
| | and no, that's what the * ss->params.spp_interp is for. | 19:04.02 |
| ray_laptop | Robin_Watts: right. | 19:05.50 |
| | Robin_Watts: that's part of mvrhel's commit 6aa157b4 | 19:09.36 |
| Robin_Watts | no, he just carries it forwards. | 19:12.26 |
| | ahem. it was my fault. | 19:14.32 |
| | marcosw: "Fetching source from users/mujstest" really? | 19:16.33 |
| henrys | ray_laptop:see the logs about weighing in on chrisl_away's fix for Bug 692684, I think you are the last one that is likely to comment on it. | 19:30.08 |
| ray_laptop | henrys: should I comment on the bug or just here ? | 19:30.43 |
| henrys | sorry ray_laptop I was away from irc - as long as it gets to chris. | 20:48.39 |
| ray_laptop | OK. | 20:55.04 |
| mvrhel_laptop | henrys: the blocker for the pxlcolor device should now be fixed | 21:17.44 |
| | 693085 that is | 21:19.31 |
| henrys | great news, I didn't realize so many files were affected when I unblocked it before. | 21:21.04 |
| mvrhel_laptop | I did not either. I guess the pxlcolor device is not run in the cluster push just the nightly? | 21:21.59 |
| | so I did not catch it at the time | 21:22.04 |
| henrys | right | 21:22.56 |
| mvrhel_laptop | I guess I need to get through Bug 693061 | 21:30.33 |
| henrys | mvrhel_laptop:you might have to do that without hintak's help ;-^ | 21:33.35 |
| mvrhel_laptop | :) | 21:34.37 |
| | yes | 21:34.41 |
| | ok. plane is loading. heading home. tty | 21:36.48 |
| | ttyl | 21:36.51 |
| | Forward 1 day (to 2012/07/14)>>> | |
IRC Logs