| | <<<Back 1 day (to 2015/01/02) | 20150103 |
| mvrhel_laptop | ok. indexed color spaces working for xpswrite now. also had to fix a crazy case where there were tons of images. since we were leaving all the streams open for each item in the zip archive this was a problem. got that fixed. getting close to where we can maybe run the xpswrite device with all the files | 00:26.07 |
| | done for the day | 00:26.13 |
| rayjj | the xps parser (gxps) is really "unfinished". Almost all of the calls to xps_alloc assume that we never run out of memory. SLOPPY! | 20:14.17 |
| | I sure hope the mupdf xps parser is better. | 20:14.40 |
| | I caught all I have patience for -- at least the xps_alloc calls, but stream alloc calls and callers that don't check if the functions they called worked (many "void" functions) exceed my patience for now | 21:42.34 |
| | it should at least fix the fts_06_0626.pdf.xps ppmraw 300 problem (that fails with the "-K1000000" limit | 21:43.48 |
| | and if there ever was a code == 0 return from XML_Parse it would try to print the error string using 'xp' AFTER the call to XML_ParserFree(xp) | 21:46.26 |
| | henrys: is there another disk space problem with macpro ? | 22:27.04 |
| | henrys: I disabled macpro just to try again. I'll let you know via email if I actually find anything | 22:28.28 |
| henrys | rayjj: there is 65G free on the mac where you are testing nothing has changed there. | 23:07.52 |
| Robin_Watts | rayjj: The xps parser in mupdf is (AIUI) much the same as the gxps one. | 23:37.31 |
| | There was very little checking for memory allocation failures, which is why we moved to the exception throwing scheme. | 23:37.59 |
| | Now everything is checked. | 23:38.03 |
| | We can use Memento to run a memory squeeze test on gxps if you want - that will exhaustively try failing every allocation in a given run, and it'll tell us which ones leak/crash. | 23:38.55 |
| rayjj | Robin_Watts: Yeah, we probably need to do the memento "squeeze" test on gxps. Now that I've fixed a few, I'm sure there are only a few hundred more | 23:45.43 |
| | :-) | 23:45.49 |
| | Robin_Watts: so the mupdf xps "squeeze" test was done ? | 23:46.40 |
| Robin_Watts | rayjj: Various squeeze tests have been done on mupdf, yes. | 23:47.07 |
| | (and various on ghostscript) | 23:47.15 |
| rayjj | Robin_Watts: with XPS input ? | 23:47.18 |
| Robin_Watts | pass. | 23:47.25 |
| | do a memento build of whichever program you want on linux. | 23:47.50 |
| rayjj | Robin_Watts: yeah, I knew that gs had some squeeze testing. The problem with exhaustive testing is that fixing all of the failures is exhausting | 23:48.07 |
| Robin_Watts | then do: MEMENTO_SQUEEZEAT=1 gxps -o /dev/null -sDEVICE=ppmraw in.xps | 23:48.26 |
| | And you probably want to capture stdout/stderr. | 23:48.51 |
| rayjj | Robin_Watts: it uses an environment variable ? | 23:48.53 |
| Robin_Watts | To trigger on, yes. | 23:49.04 |
| | and then it does magic forking trickery. | 23:49.16 |
| rayjj | Robin_Watts: OK, thanks. | 23:49.23 |
| | yes, I knew how it works -- just not how much has been done | 23:49.42 |
| Robin_Watts | TBH, I avoid the xps stuff, and it's probably only me that's really played with this. | 23:50.40 |
| rayjj | Robin_Watts: I don't blame you. The only reason I started paying attention was that xps segfaults started showing up now that we are testing xpswrite | 23:51.35 |
| | and I fixed a couple of irritating xpswrite bugs on Windoze now that we will be using it with gswin printing | 23:52.45 |
| Robin_Watts | IIRC sometimes the forking gets into a state (don't really understand why). | 23:55.38 |
| | but you can restart it by using MEMENTO_SQUEEZEAT=whatever the next number was. | 23:56.01 |
| rayjj | henrys: with macpro out of the cluster testing, all of the "34 regression file(s) have started producing errors" went away | 23:56.08 |
| Robin_Watts | You can run the test on windows too, but that can't do forking, so it's less efficient, and may possibly require a shellscript. | 23:56.50 |
| henrys | rayjj: this problem only happens with your change? | 23:57.41 |
| rayjj | I thought the cluster ran both parts of a job on the same machine (to avoid net traffic) but I see things like: | 23:57.48 |
| | tests_private/xps/sumatra/1803_-_JPEG-XR_support.xps.pdf.ppmraw.72.0 xps pdfwrite picas macpro Error_reading_input_file | 23:57.50 |
| | tests_private/xps/sumatra/1803_-_JPEG-XR_support.xps.ppmraw.72.0 xps peeves macpro Error_reading_input_file | 23:57.51 |
| | which seems to indicate that the first step (xpswrite) was on picas or peeves and the second (gxps) was on macpro | 23:58.33 |
| | which might even be a network transfer issue | 23:58.53 |
| | off to do chores... | 23:59.03 |
| | Forward 1 day (to 2015/01/04)>>> | |
IRC Logs