| | <<<Back 1 day (to 2012/07/18) | 2012/07/19 |
| Robin_Watts | sebras: So we maybe have a flag in the pdf_function that we set to 1 the first time we warn? | 00:29.38 |
| | So we only ever warn once in eval_function ? | 00:29.58 |
| mvrhel | marcosw are you there? | 05:58.59 |
| | or henrys | 05:59.40 |
| | I guess it is a bit late... | 05:59.55 |
| | good night all | 06:13.48 |
| paulgardiner | Robin_Watts: I looked over the test-generator patch and it looks fine to me. | 08:02.45 |
| sebras | Robin_Watts: that's definitely an option. | 08:46.27 |
| | Robin_Watts: also I guess there's a decision of whether to warn early (when loading the function) or late (when evaluating the function). | 08:47.03 |
| | Robin_Watts: oh, and I started to separate/squash my function patches yesterday but it was too late in the evening/night for me to make something that I trust. | 08:54.46 |
| kammerer | Hi ALL, what is the best way to extract text from specified region in page? | 09:04.14 |
| chrisl | kammerer: you're best hop is probably to use the XML output from either mupdf or Ghostscript txtwrite device, and parse the XML to find what text segments intersect your region of interest | 09:41.44 |
| | s/hop/hope | 09:41.50 |
| kammerer | chrisl: big thx | 09:43.00 |
| chrisl | kammerer: sorry there isn't a simpler answer | 09:43.23 |
| Robin_Watts | sebras: So... you're suggesting validating the functions at load time rather than eval time? | 10:06.35 |
| | That sounds like a nice idea if possible. | 10:06.41 |
| | especially if it means we can irradicate the possibility of the function eval failing entirely. | 10:07.04 |
| | paulgardiner: When I commit this, all your mjs files are going to be out of date :( | 10:50.47 |
| paulgardiner | Don't understand. "out of date"? Different to what the script would generate? | 10:51.58 |
| Robin_Watts | I mean, different to all the ones I put on a blu-ray for you. | 10:52.16 |
| paulgardiner | Oh! | 10:52.27 |
| Robin_Watts | is pdf_text_stride yours ? | 10:53.15 |
| paulgardiner | Were the scripts a large proportion of what was on that blu-ray? | 10:53.15 |
| Robin_Watts | no, they were tiny. | 10:53.26 |
| paulgardiner | Robin_Watts: pdf_text_stride is mine, yes. | 10:53.40 |
| Robin_Watts | but either you're going to need to regenerate yourself, or you can svn checkout. | 10:53.49 |
| | Try: mudraw -j out.mjs ..\ghostpcl\tests_private\pdf\forms\v1.6\sf328-cert-foreign-int-ext-venx-feb06.pdf | 10:54.26 |
| | pdf_text_stride is entered with len = 1, room = -566 | 10:54.52 |
| | So the first for loop never runs. | 10:55.10 |
| | We then go into the if, and h.w is used without ever having been initialised. | 10:55.24 |
| paulgardiner | Doesn't sound ideal! | 10:55.33 |
| Robin_Watts | And what's the i-- about ? | 10:55.41 |
| | oh, for count, sorry. | 10:55.48 |
| | if (x > room && i) ? | 10:55.59 |
| | But even then I'd be suspicious of the fact that room is negative. | 10:57.02 |
| paulgardiner | Yeah room shouldn't be negative | 10:58.20 |
| Robin_Watts | splitter->unscaled_width = 34, splitter->x = 600 | 10:58.51 |
| | hence room = 34 - 600 = -566 | 10:59.11 |
| | (in text_splitter_layout) | 10:59.48 |
| paulgardiner | Hmmm, I thought for a moment that pdf_text_stride was broken even for room = 0.0, but no it is ok. Just being called wrongly. Do we tend to use asserts in mupdf? | 11:02.26 |
| Robin_Watts | There aren't many, but they are there. | 11:02.55 |
| | The cluster testing runs without asserts of course. | 11:09.33 |
| paulgardiner | Why's that? | 11:10.53 |
| Robin_Watts | It tests release builds | 11:11.41 |
| | and the point of assert is that it compiles away to nothing in release builds. | 11:12.09 |
| paulgardiner | Oh ok. I didn't realise it was release builds. | 11:12.40 |
| Robin_Watts | It was debug for a long time, but we changed it. | 11:13.23 |
| | debug builds often fill unused memory so hiding problems. | 11:13.43 |
| paulgardiner | Robin_Watts: I broke it when I fixed the failure to terminate in very thin text fields. I have a fix I'll push in a minute | 11:26.32 |
| Robin_Watts | paulgardiner: Cool. I'll review that, push it, then regenerate the mjs stuff and push all that. | 11:31.09 |
| paulgardiner | Pushed. I've also started a mujstest run to check it doesn't break loads of other things. | 11:32.48 |
| | Robin_Watts: actually that's a bit crap. I might do it another way | 11:38.50 |
| Robin_Watts | ok. | 11:39.00 |
| paulgardiner | Pushed | 11:51.30 |
| Robin_Watts | Ok, so you only add span on if it will fit, rather than adding it on repeatedly until it overflows then backing the last one out ? | 11:53.31 |
| | That does seem nicer. | 11:53.38 |
| paulgardiner | Yeah, I avoid break in loops if I can, but in this case it's better that way | 11:54.20 |
| Robin_Watts | new mjs files going into svn now... | 12:10.04 |
| sebras | Robin_Watts: well, I'm advocating validating the functions at load time, giving warnings if something is wrong (incorrect number of inputs/outputs), and then later during evaluation replacing missing input values with zero and ignoring excess output values. | 12:13.21 |
| Robin_Watts | That sounds perfect. | 12:13.34 |
| sebras | Robin_Watts: alrighty, then I know what to do tonight. :) | 12:13.52 |
| Robin_Watts | So the warnings etc come out early, and we cope as best we can (the eval can never fail) | 12:13.53 |
| sebras | exactly. | 12:14.11 |
| | and also the warnings come out once instead of at each eval. | 12:15.10 |
| | so some kind of implicit rate limiting. :) | 12:15.22 |
| paulgardiner | Robin_Watts: My last mujstest showed a huge number of diffs. Might that be because of your changes to the mjs files? | 13:29.01 |
| Robin_Watts | Yes, I've not committed the git changes yet. | 13:53.46 |
| | I was going to look at the bmpcmp first | 13:53.57 |
| | Hmm. My bmpcmp produced a completely different set of differences than I was expecting. | 13:57.00 |
| | oh, I understand why it shows few differences overall. | 13:57.35 |
| | OK, I've pushed now. When those tests finish, we should get sane results again. | 13:58.05 |
| paulgardiner | Great. I'll try a run with my last change removed to see what's due to it | 13:59.04 |
| Robin_Watts | Hi mvrhel. | 14:54.35 |
| | Got 5 mins for me ? | 14:54.51 |
| pickcoder | what aspect of a process does "/ioerror in --run-- " pertain to. It was followed by an XREF reading error and then an ioerror in quit. | 15:39.31 |
| mvrhel | Robin_Watts: I have to head out in a couple secs. for my daughters dr. appt | 15:47.01 |
| Robin_Watts | You go, I've made a bit more progress. | 15:47.13 |
| | But I may well want to ask you some more questions later if you're available. | 15:47.31 |
| mvrhel | ok. i will ping you when i get back | 15:47.33 |
| Robin_Watts | Thanks. | 15:47.35 |
| mvrhel | quick question | 15:50.41 |
| | if I put psdcmyk at the end of my clusterpush will it do just that device? | 15:50.57 |
| Robin_Watts | --filter=psdcmyk maybe | 15:51.06 |
| mvrhel | Robin_Watts: ^^ | 15:51.10 |
| | oh | 15:51.14 |
| Robin_Watts | Or maybe just filter=psdcmyk. | 15:53.30 |
| | I wrote an email about this, thus allowing me to completely forget it. Hold on, I'll check :) | 15:53.49 |
| | yeah: 8/11/2011 to tech. | 15:54.28 |
| | clusterpush.pl xps filter=xpsfts-a4 | 15:54.38 |
| mvrhel | oh that is the test files though | 15:55.06 |
| Robin_Watts | clusterpush.pl xps filter=xpsfts-a4,72 | 15:55.10 |
| mvrhel | is there a --? | 15:55.16 |
| | and what about devices? | 15:55.26 |
| Robin_Watts | It just checks for the presence of the strings in the test filename: tests_private/comparefiles/Bug691783.pdf.pgmraw.300.0 | 15:55.34 |
| | So it will do banding/devices/filenames/resolutions. | 15:55.44 |
| | No --, I misremembered, sorry. | 15:55.56 |
| mvrhel | ok thanks! | 15:56.07 |
| Robin_Watts | let me know how it gets on - it's not had much testing. | 15:56.26 |
| | ctile->depth == 0 sounds bad to me. | 15:58.58 |
| | Aha. | 16:04.06 |
| | gx_dc_serialized_tile uses a byte for the depth. This is bad when we have depths of > 256 :) | 16:04.39 |
| Robin_Watts | waves a fresh pot of coffee under the webcam and hopes for ray to appear... | 16:23.39 |
| fm__ | chrisl, anything new to test for me? | 16:34.32 |
| chrisl | fm__: no, we know what the problem is, and I've given a proposed solution to the relevant engineer for his consideration. | 16:35.33 |
| fm__ | thanks. is there any bugreport in bugs.ghostscript.com which i should link to https://bugs.launchpad.net/ubuntu/+source/ghostscript/+bug/1025061 ? | 16:37.50 |
| chrisl | fm__: no, I haven't created a bug - I suppose I should - I'll do it in a bit, and post it on launchpad | 16:38.41 |
| fm__ | great | 16:39.07 |
| chrisl | fm__: done | 16:45.50 |
| fm__ | chrisl, thanks | 16:50.25 |
| Robin_Watts | hey ray_laptop | 17:33.00 |
| | Got a mo? | 17:33.05 |
| ray_laptop | Robin_Watts: sure -- just discovered that what I thought I screwed up with my fill_rectangle_hl_color changes wasn't me at all -- HEAD has the same problem | 17:33.56 |
| | Robin_Watts: so, how can I help ? | 17:34.22 |
| Robin_Watts | I've been looking into bug 693185 | 17:34.38 |
| | specifically the SEGVs with psdcmyk when the MAX components thing is set to 32. | 17:35.06 |
| | I've found a problem and fixed it, and the SEGVs stop, but along the way I found something else. | 17:35.22 |
| | and it's a clist thing, so I'd like to run it past you. | 17:35.33 |
| | pcls->colors_used | 17:35.55 |
| | That looks to be a gx_color_index. | 17:36.05 |
| ray_laptop | Robin_Watts: well, that's right what I'm in the middle of -- a clist SEGV (and mis-rendering with NumRenderingThreads=1) | 17:36.27 |
| Robin_Watts | and in various places in the code we set it to values like: ((gx_color_index)1 << cldev->clist_color_info.depth) - 1 | 17:36.27 |
| | Right. This isn't anything to do with NumRenderingThreads. It's just to do with planar stuff. | 17:36.57 |
| | The problem is that clist_color_info.depth can be a large number (say 256, if the max components is 32) | 17:37.49 |
| | 1 << 256 is undefined in C. | 17:38.01 |
| | so, I think we need to find an alternative way to work here. | 17:38.18 |
| ray_laptop | Robin_Watts: gx_clist_state doesn't have a colors_used | 17:39.03 |
| Robin_Watts | gxcldev.h line 273 would beg to differ | 17:40.18 |
| ray_laptop | oops -- I traced the wrong struct | 17:40.26 |
| | (tags led me to the 'common_members' | 17:40.50 |
| Robin_Watts | Presumably we only actually need 1 bit per component to indicate its usage? | 17:41.27 |
| ray_laptop | Robin_Watts: that is true | 17:41.59 |
| Robin_Watts | So moving to a bitfield would save our bacon. | 17:42.10 |
| | (Well, at least get us up to 64 max components, which is the limit elsewhere in the code) | 17:42.29 |
| ray_laptop | so for up to 64 components we could get by with uint64_t | 17:42.31 |
| Robin_Watts | So, I may try and look at that then tomorrow. | 17:43.06 |
| ray_laptop | but if we are changing it, I'd think that going up to at least 256 components for this area wouldn't be that much different (byte colors_used[8]) | 17:43.45 |
| | oops math wrong | 17:44.04 |
| | colors_used[256/8] | 17:44.22 |
| Robin_Watts | We cease to be able to deal with that in such a simple way though. | 17:44.52 |
| ray_laptop | but it does mean that we'd have to use the color_info shift and mask stuff to derive the bit # | 17:45.21 |
| Robin_Watts | Yes. | 17:45.29 |
| | Urm, no. | 17:45.35 |
| | Well, in some cases, yes. | 17:46.00 |
| | To go from a color_index to a bitfield value, yes. | 17:46.19 |
| | We'd have a harder time converting from gx_color_info -> bitfield. | 17:46.49 |
| ray_laptop | right -- but for a hl_color we can get it from the ccolor (or something) | 17:46.56 |
| Robin_Watts | exactly. | 17:47.03 |
| | Rather than colors_used[256/8], we should use colors_used[(MAX_COMPONENTS+7)/8] | 17:47.44 |
| ray_laptop | the colors_used isn't used much elsewhere | 17:47.45 |
| | Robin_Watts: I assume you mean GS_CLIENT_COLOR_MAX_COMPONENTS, but yes | 17:48.21 |
| Robin_Watts | yes, I just wasn't going to type all that :) | 17:48.32 |
| ray_laptop | does much cut and paste | 17:48.49 |
| | Robin_Watts: so the planar code actually uses 'colors_used' ? (I haven't looked at it much yet) | 17:49.58 |
| Robin_Watts | I am not aware of it using colors_used. | 17:50.16 |
| | I have to confess, I don't understand what colors_used is about. | 17:50.26 |
| ray_laptop | it is *supposed* to indicate what components are used so that we can skip rendering bands that are blank | 17:51.08 |
| Robin_Watts | Looks like it's something to do with copy_rop? | 17:51.11 |
| | searching on colors_used, I can only see it be READ in 1 place. | 17:51.39 |
| ray_laptop | and for the entire page (page_info.colors_used) we can determine if a page is only black | 17:52.08 |
| Robin_Watts | actually, that's only used so it can be updated. | 17:52.40 |
| | I can't see where it's ever used. | 17:52.47 |
| ray_laptop | the 'rop' part of it is also intended as an optimization -- was used by the 'wts' device to decide if we had any non-idempotent rops in a band, and if so we would render that band in RGB contone, otherwise render directly to halftoned CMYK | 17:53.54 |
| Robin_Watts | And it's broken in clist_strip_copy_rop2 anyway. | 17:53.58 |
| | Can you see anywhere it's used in the current source ? | 17:54.17 |
| ray_laptop | Robin_Watts: since no one ever used it, and it's broken, I think we should just get rid of them both until we put in something that is correct. | 17:54.58 |
| Robin_Watts | Fab. I heartily agree :) | 17:55.14 |
| | I will prepare a patch. | 17:56.05 |
| ray_laptop | IMHO, I think we should collect the 'band_stats' (for whatever we decide we want) at init_reader time, writing an array into a pseudo-band that the reader can read back | 17:56.29 |
| | Robin_Watts: but a patch to rip it out is a good start. | 17:56.44 |
| | because it will make sure that nobody uses it. | 17:56.59 |
| | Robin_Watts: so does this relate to the SEGV at all ? | 17:57.20 |
| Robin_Watts | no. | 17:57.35 |
| | The SEGV was because when putting a pattern through the clist we wrote the depth into a byte wide value. | 17:57.53 |
| | so a depth of 256 was coming out as 0, resulting in a NULL pinst pointer. | 17:58.07 |
| ray_laptop | Robin_Watts: please try: gs -r72 -sDEVICE=psdcmyk -o colorcir.psd -dNumRenderingThreads=1 -dBandHeight=800 examples/colorcir.ps | 17:58.26 |
| | take a look at the output -- it's REALLY screwy | 17:59.20 |
| Robin_Watts | That still SEGVs. | 17:59.32 |
| | output ? | 17:59.39 |
| ray_laptop | what OS ? | 17:59.41 |
| Robin_Watts | windows 7 64 bit | 17:59.49 |
| ray_laptop | hmm... I get output (with debugbin/gswin32c) | 18:00.16 |
| | same OS, VS 9 | 18:00.40 |
| Robin_Watts | VS2005, so that's 8, I think. | 18:01.11 |
| ray_laptop | oh, well -- I'm digging into it. I just thought you might be able to look at it and say "oh, the plane offsets are all bogus" or something. I'm comparing Threads=0 to Threads=1 | 18:02.09 |
| Robin_Watts | I'll have a look in a mo. | 18:02.27 |
| ray_laptop | go ahead and fix your issue first. I'll let you know if I need any info about the planar setup | 18:03.19 |
| | Robin_Watts: I got an email about ARM Tech Con locally (well, Santa Clara) and of Oct. think it is worth attending ? | 18:07.01 |
| Robin_Watts | ray_laptop: I rather suspect that such things tend to be "let us tell you how marvellous our new suite of compiler tools is..." | 18:07.33 |
| ray_laptop | I haven't looked at agenda yet. | 18:08.07 |
| | http://eetevents.com/portal/wts/cemciv2dviB6edETB6-7-C2gAO7N6c | 18:08.21 |
| | looks like a lot of H/W discussions | 18:09.56 |
| | but there are several S/W papers as well. | 18:10.49 |
| | I notice that the one "Is C++ Fast Enough for Embedded Programming?" was cancelled (don't blame him) | 18:11.30 |
| Robin_Watts | HARDWARE/SOFTWARE CODESIGN | 18:11.32 |
| ray_laptop | Robin_Watts: yeah, that looked interesting | 18:11.46 |
| Robin_Watts | ho ho. That was what my PhD was supposed to be in. Sponsored by ARM :) | 18:11.53 |
| ray_laptop | that and GPGPU ON ARM | 18:12.53 |
| | and Take GPU Processing Power Beyond Graphics with GPU Computing on Mali | 18:13.24 |
| Robin_Watts | "ADVANCE COMPILER OPTIMIZATIONS FOR THE SMALLEST, FASTEST CODE" by someone from Greenhills. Last time I used the greenhills compiler it couldn't actually give me working code, let alone optimise it. | 18:13.31 |
| ray_laptop | Yeah, I remember fighting GreenHills compiler trying to work around it's glitches. Having to desk check the disassembled code isn't fun | 18:15.00 |
| | another one that might be interesting is "Taking Advantage of Quad ARM Cortex A-9 CPUs and ARM Mali GPUs for Rich Graphical Effects" | 18:15.41 |
| Robin_Watts | yeah, I suspect that's "Use OpenGLES". | 18:16.03 |
| | "but avoid these specific bits as they were optional and we haven't implemented them fully" | 18:16.38 |
| ray_laptop | well, I might go up for part of it, but too bad it's over halloween -- that's an important time for my 6 (he'll be 7 by then) year old. They do a historical bio of someone, then dress up and do a presentation to the whole school and parents | 18:18.57 |
| | well, back to work on the screwy planar painting ... | 18:20.18 |
| Robin_Watts | Ok, that solves all the SEGVs, but bumping the number of components up does show differences. | 18:21.05 |
| | ray_laptop: Actually, the band complexity looks at the colors_used. | 18:25.52 |
| | And the clist writer looks at uses_color when writing. | 18:27.51 |
| | It looks to me like we jump through lots of hoops collecting this 'uses_color' information, and the only place we use it is in clist_image_plane_data at line 787 | 18:30.37 |
| | actually, not even there. | 18:31.24 |
| | ray_laptop: Can the band complexity stuff be ripped out too? | 18:31.35 |
| ray_laptop | Robin_Watts: yes, please !!! | 18:32.06 |
| Robin_Watts | That was the opposite answer I was expecting, but OK :) | 18:32.30 |
| ray_laptop | it'll make it easier for me to put in right afterwards (a clean slate). | 18:33.02 |
| | part of the problem with the colors_used and uses_color nonsense it that it did an "OR" which really is only valid for a subtractive color model | 18:34.30 |
| | IMHO, we should collect useful band_statistics AND write it to the clist (in a pseudo band) | 18:35.53 |
| | we might want to make collection of ROP and colors_used bits optional so devices that don't need it don't bother to collect it. | 18:37.20 |
| | but we should collect the color info correctly, if we do it at all -- which is fairly easy for RGB and CMYK (taking polarity and bits_per_component into account), but is trickier for devn | 18:38.53 |
| | I found the smoking gun with the funky rendering. | 19:06.18 |
| | now to find out why and fix it. Shouldn't be much longer | 19:06.53 |
| Robin_Watts | Damn and blast. | 19:07.16 |
| mvrhel | Robin_Watts I am back | 19:07.20 |
| Robin_Watts | brb, sorry. | 19:07.29 |
| mvrhel | if you still need to chat | 19:07.31 |
| | np | 19:07.34 |
| Robin_Watts | mvrhel: Sorry, that was the front door. | 19:08.59 |
| | mvrhel: I have fixed the psdcmyk SEGVs with the max components being 32. | 19:09.35 |
| | We were trying to pack a pattern t34le depth of 256 into a byte for the clist, and obviously that wasn't working so well :) | 19:10.01 |
| mvrhel | oh great | 19:10.01 |
| Robin_Watts | There are still some differences (minor ones) in psdcmyk banded when I up the components to 32 though. | 19:10.37 |
| | I spotted that the colors_used mechanism can't work now. | 19:10.56 |
| mvrhel | I was wondering what that was all about | 19:11.12 |
| Robin_Watts | I'd hoped to just rip it all out, but that looks like it isn't going to work. | 19:11.25 |
| | It's looking like I'm going to have to look at making colors_used be a bitfield rather than a gx_color_index | 19:13.16 |
| | I'll look into that tomorrow. | 19:13.29 |
| mvrhel | that sounds reasonable | 19:13.35 |
| | marcosw1: so can I close 693061? | 19:20.47 |
| | marcosw1: also I just committed a fix for gemma's last issue | 19:21.17 |
| Robin_Watts | 693061 is what ray is looking at I think. | 19:57.16 |
| | I've been looking into 692185 | 19:58.55 |
| | 693185 | 19:59.00 |
| ray_laptop | mvrhel: so the problem with the NumRenderingThreads > 0 in planar mode devices is that it isn't picking up the is_planar. | 20:04.18 |
| mvrhel | what isnt picking it up? the clist devices? | 20:04.46 |
| ray_laptop | when it creates the clist devices for the threads to use when rendering | 20:04.49 |
| mvrhel | ok | 20:04.53 |
| | that should be an easy fix | 20:05.04 |
| ray_laptop | that causes the 'tile_cache_size' to differ and then we get different pointers for where the data starts | 20:05.33 |
| | mvrhel: yes, but I need to make sure that the dev_spec_op doesn't need to be other than the default. | 20:06.32 |
| mvrhel | ray_laptop: not sure I understand what needs to be done with the spec_op, but I can see where this would have caused a segv | 20:07.29 |
| ray_laptop | mvrhel: possibly. It definitely gets the parts of the buffer space messed up | 20:11.49 |
| mvrhel | sure | 20:12.01 |
| | bbiab | 20:17.41 |
| ray_laptop | OK, cluster testing a patch. Also I'll check on peeves to see if it fixes the SEGV (it wasn't reproduced on Windows). | 20:35.00 |
| | If this is the fix, I probably need to make the fill_rectangle_hl_color change separate from the fix. :-( | 20:39.04 |
| | HURRAY. The SEGV on peeves is cured (it was VERY repeatable before, even with the fill_rectangle_hl_color changes) | 20:40.17 |
| | bbiaw | 20:41.00 |
| | my git logg tree is looking REALLY funky after I tried to split up my commits into the bug fix and the change to the fill_rectangle_hl_color changes. I _think_ it is OK :-( | 23:07.01 |
| | doesn't help that I have clusterpush stuff messing it up in between | 23:07.28 |
| sebras | Robin_Watts tor8: I chopped my mega-patch into pieces and tried to write a bit more informative commit messages. have a look at them over at sebras/master and tell me what you think | 23:28.20 |
| | and yeah, I don't expect any comments until tomorrow or even later. | 23:28.43 |
| | and reworing commit messages are fine. I'm not good at writing them as tor8 can testify to. | 23:43.28 |
| | see! rewor_D_ing. | 23:43.56 |
| | Forward 1 day (to 2012/07/20)>>> | |
IRC Logs