| | <<<Back 1 day (to 2015/10/08) | 20151009 |
| kens | chrisl do you have a working ijs setup ? | 09:04.53 |
| chrisl | kens: I can build one | 09:05.22 |
| kens | Can you try the code in bug #696246 ? | 09:05.41 |
| chrisl | In a while.... | 09:05.58 |
| kens | I installed an ijs server but it doesn't work (possibly because I have no actual device) | 09:06.00 |
| | The rinkj problem reported there is a configuration problem (and lack of checking in the device) and I thnk the Uniprint problem is as well. The X11 problems seem, surprisingly, to be somethign to do with DSC processing, so I'll carry on with those. | 09:06.55 |
| | There's no rush about any of this | 09:09.00 |
| tor8 | Robin_Watts: oops. it looks like there are a *lot* of places that don't handle the weird text clip accumulate flag | 09:16.28 |
| chrisl | kens: http://git.ghostscript.com/?p=user/chrisl/ghostpdl.git;a=commitdiff;h=b68e05c | 09:56.53 |
| kens | Ah well that looks sensible | 10:00.43 |
| chrisl | Various other devices do the same thing, so.... | 10:00.58 |
| kens | Yeah I must have missed that one, I can't say I'm totally surprised | 10:01.18 |
| chrisl | So I'll push it? | 10:01.33 |
| kens | Absolutely, I'll carry on looking at the x11 device | 10:01.45 |
| | The other two devices mentioned there I thnk are config problems, so I'm going to ignore them | 10:02.06 |
| chrisl | Hmm, I think ijs is less horrible than x11..... | 10:02.32 |
| kens | The X11 one is just plain weird, it throws an error on ifelse, I have no idea why yet, but it seems to be something to do with DSC oparsing | 10:03.00 |
| | And nHin-Tak piping up pointlessly again | 10:03.33 |
| chrisl | I'm slightly surprised we actually build the IJS device on Windows - I wonder if *anyone* has ever used it for real | 10:09.05 |
| kens | I've no idea, it was something of a surprise to me too | 10:09.38 |
| chrisl | FWIW, the example IJS server builds just fine on Windows, and also interacts quite happily and correctly with the IJS device | 10:16.28 |
| kens | remarkable | 10:16.38 |
| chrisl | It's not exactly demanding code | 10:17.06 |
| kens | I'm still surprised it hasn't bit-rotted | 10:17.19 |
| | I wonder if there's some way I can politely get Hin-Tak to shut up and not comment on bugs assigned to me....... | 10:40.20 |
| chrisl | Erm, "shut up and stop making useless comments on bugs assigned to me" ??? | 10:42.23 |
| kens | I'm sure that's what he would put | 10:42.34 |
| | But given Henry seems to find his input occasionally useful I was hoping to be more polite | 10:43.00 |
| chrisl | You forgot the "allegedly" in that sentence | 10:43.34 |
| kens | I did say 'seems to' though :-) | 10:43.53 |
| | Memory watch points don't seem to work at all with Visual GDB | 10:44.41 |
| tor8 | chrisl: kens: you'd probably want to s/useless// in that sentence ... | 10:47.46 |
| chrisl | I did..... | 10:49.01 |
| kens | Arguably its a redundant word :-) | 10:49.35 |
| chrisl | Actually it probably should have been s/useless/mostly useless | 10:49.49 |
| tor8 | it's also more polite, and without the qualifier he can't argue that his comments are useful to get around the "shut up" part ;) | 10:50.18 |
| kens | I wouldn't mind so much if he was going to actually work on it, but he clearly wasn't and isn't, given that it took Chris almost no time to solve the problem | 10:50.26 |
| tor8 | anyway, lunch! | 10:50.41 |
| kens | wonders if it would be easier to butcher the x11 device to 'work' on WIndows than trying to debug it on Linux | 10:52.13 |
| Robin_Watts | VisualGDB :) | 10:59.04 |
| kens | That's what I'm usingf | 10:59.16 |
| | The memory watch point doesn't work | 10:59.23 |
| Robin_Watts | oh, right. Hmm. | 10:59.43 |
| | There is a visual gdb console window, I think in which you can enter gdb commands. | 11:00.01 |
| | You might be able to set stuff there ? | 11:00.17 |
| kens | TYheree is, and I have no idea what to enter because I know nothign about gdb | 11:00.19 |
| Robin_Watts | You want read or write watch? | 11:01.01 |
| kens | write | 11:01.05 |
| Robin_Watts | watch -l fred | 11:01.27 |
| kens | Umm, well I'll try it after lunch | 11:01.37 |
| Robin_Watts | That's dash lower case L. | 11:01.37 |
| | Where fred is the variable to watch. | 11:01.52 |
| kens | It isn't a vraibel really, its a memory address | 11:02.05 |
| Robin_Watts | watch address then. | 11:02.22 |
| kens | sounds suspiciously sensible for gdb | 11:02.34 |
| Robin_Watts | It's sebras' birthday today. For the logs - Happy Birthday Sebras! | 11:03.19 |
| kens | Mine too, I'd no idea we shared a date | 11:03.34 |
| Robin_Watts | really? Happy Birthday Ken then :) | 11:03.52 |
| kens | thanks :-) | 11:03.58 |
| chrisl | kens: I don't know how far you're got in debugging the x11 problem...... | 11:08.20 |
| kens | Not terribly | 11:08.30 |
| | The initial problem is caused by having a %! in the file, which blows up the DSC parsing | 11:08.47 |
| chrisl | I'm seeing currentpagedevice returning an empty dictionary | 11:08.47 |
| kens | That sounds related | 11:09.07 |
| chrisl | It causes an undefined error | 11:09.25 |
| kens | Tha'ts not what I see | 11:09.31 |
| | I'm getting a typecheck on ifelse if I recall correctly | 11:09.43 |
| chrisl | Are you running with PDFSTOPONERROR | 11:09.56 |
| kens | No, because I'm not using a PDF | 11:10.04 |
| | I'm using colorcir.ps | 11:10.12 |
| chrisl | Oh, I'm using the PDF from the bug | 11:10.21 |
| kens | That was for the ijs problem, the OP said later he was having trouble with x11alpha using colorcir.ps | 11:10.49 |
| chrisl | Oh, well, I'm seeing a different problem, then! | 11:11.11 |
| kens | Its probably related | 11:11.23 |
| chrisl | Without FirstPage/LastPage the page device dictionary has 80 entries, with FirstPage/LastPage it's empty | 11:11.51 |
| kens | Well that's clearly not right :-) | 11:12.03 |
| chrisl | This is in runpdfbeing | 11:12.10 |
| | runpdfbegin | 11:12.21 |
| kens | :-) | 11:12.24 |
| chrisl | /CumulativePageCount currentpagedevice /PageCount get def | 11:12.37 |
| kens | Its probably a related problem | 11:12.49 |
| | Sigh, Zoltan clearly has no idea that we don't support DCS | 11:13.18 |
| chrisl | kens: http://git.ghostscript.com/?p=user/chrisl/ghostpdl.git;a=commitdiff;h=95553954 | 11:59.04 |
| | I'm going in search of lunch...... | 11:59.29 |
| kens | ah, interesting | 11:59.40 |
| | I wonder why that didn't show up more easily | 12:00.24 |
| chrisl | kens: I'm not sure - and that is a rather hacky solution, but it solves the problem I see here | 12:11.54 |
| kens | Just testign it locally | 12:12.08 |
| | It deos also seem to solve my problems, so I guess they are the same. | 12:12.36 |
| | I'm fairly sure that I did do that in one of my early attempts on ths, I can't think why I didn't carry it over. | 12:12.58 |
| | TBH much of the code in that routine can best be described as 'hacky' | 12:13.14 |
| | Have you cluster tested it ? Not that I anticipate nay problems | 12:14.06 |
| chrisl | Well, the nonsense of having the "visible" stype field in the device structure adds to the confusion! | 12:14.21 |
| | I haven't cluster tested it - does the cluster test any of this? | 12:14.39 |
| kens | You can make it do so at build time | 12:14.53 |
| chrisl | 'Course, I'll find the file | 12:15.13 |
| kens | There's a couple of #defines that force teh subclassing to be present, even though it doesn't do anything | 12:15.16 |
| kens | is just getting the l;atest customer bug report :-( | 12:15.45 |
| | I have to say your fix looks entirely reasonable to me, I'm really surprised ths hadn't caused more issues. | 12:16.19 |
| | in gdevkrnlscalss.c there's FORCE_TESTING_SUBCLASSING | 12:17.08 |
| | If that's a '1' then all the devices get loaded | 12:17.31 |
| chrisl | I suspect it's because most devices use the convenience calls to enum/reloc the basic device contents (including child/parent), and then the rest of the device is zeroed when it's subclassed so the garbage collector sees the pointer as a dead end | 12:17.57 |
| kens | Ah, well that would make some sense | 12:18.10 |
| | There are a couple of other devices which don't so its good to get ths fixed. | 12:18.35 |
| chrisl | As to why there's a problem with x11.... <shrug> | 12:18.43 |
| kens | Good grief, teh customer file is 352 Mb uncompressed | 12:19.31 |
| chrisl | And it's one big JPX image? | 12:19.59 |
| kens | I bet its a massive image, probably JPEG2000 and it truly is running out of memory. | 12:20.01 |
| | One monster image, 11342x9938, 8bpc, DeviceRGB : 338150388 bytes | 12:22.08 |
| | Its only a DCT image though | 12:22.53 |
| | Hmm, there's an ImageMask in there too | 12:24.29 |
| | Ah, its a monster image with a monster mask | 12:25.21 |
| | Works fine to the display device though | 12:26.06 |
| | chrisl if that clister run is OK, please go ahead and push the fix, and close the bug report. | 12:27.34 |
| chrisl | kens: Okay. | 12:27.51 |
| kens | well the customer's file does indeed fial with a VMerror, and it looks genuine to me | 12:30.35 |
| | tryoing to allocate 2.6 Gb it looks like | 12:31.09 |
| chrisl | What if you use very low resolution for the output? | 12:31.19 |
| kens | just trying that now | 12:31.27 |
| | IKt was OK at 72 dpi with tiff24nc | 12:31.35 |
| | Looks like it'll be OK with tiffg4 too at that resolution | 12:31.48 |
| | Unsurprisingly its not fast to process that amount of data | 12:32.09 |
| chrisl | We do use "file" as the default clist storage? | 12:33.01 |
| kens | I have no idea. | 12:33.11 |
| | Its fine at 72 dpi though, os I really don't thnk its the PDF interpreter | 12:33.30 |
| chrisl | That is implied in the documentation | 12:33.37 |
| kens | There's documentation ? O.O | 12:34.08 |
| chrisl | http://www.ghostscript.com/doc/9.18/Language.htm#Banding_parameters | 12:34.54 |
| kens | + $(gsstruct_h) $(gxobj_h) $(MAKEDIRS)Fair enough. + $(gsstruct_h) $(gxobj_h) $(MAKEDIRS)Doesn't explain why we're trying to allocate 2.6 Gb though | 12:35.28 |
| chrisl | If we were using a memory based clist..... | 12:35.54 |
| kens | Hmmyes that would do it | 12:36.11 |
| chrisl | But I don't think that's the case | 12:36.24 |
| kens | Well, you assume the documentatoin is correct | 12:36.42 |
| | 300 dpi is also correct, I'll debug it and see where the allocaton is coming from | 12:37.21 |
| chrisl | We wouldn't have had all that hassle with stale temp files after a crash if we defaulted to memory clists | 12:37.26 |
| kens | Oh yeah I guess that's true. Of course, does the tiffg4 device even use the clist ? I guess it has no choice. | 12:37.53 |
| chrisl | It's just a prn device | 12:38.12 |
| kens | Looks like its caused by trying to handle an imagetype 3, whcih I'm guessing is what the PDF itnerpreter turns the image+Mask into | 12:42.33 |
| | It 'looks like' we make a memory device to render the image+mask to, and we make it at the resolutoin of the output, which means that really enormous images need really enormous humunguous amounts of memory | 12:44.13 |
| chrisl | We're not actually running out of memory..... | 12:49.50 |
| kens | The requested value is > mme->max something or other | 12:50.19 |
| | mmem->limit | 12:50.45 |
| chrisl | Oh, I don't even get that far..... | 12:50.56 |
| | I get the error in gx_mask_clip_initialize() | 12:51.08 |
| kens | gs_heap_alloc_bytes for me | 12:51.10 |
| | I'm not gtting to gx_mask_clip_initialize | 12:51.57 |
| chrisl | Hmm, strange | 12:52.16 |
| kens | I'm on a 32 bit build | 12:52.25 |
| | I thnk you are getting further | 12:52.31 |
| | THe memory request > 2^32/2 | 12:52.45 |
| | I'm just rebuilding an x64 binary | 12:53.32 |
| | whihc will be a full rebuild I think | 12:53.41 |
| chrisl | Even upping the limit in gx_mask_clip_initialize just means we vmerror later on | 12:54.18 |
| kens | Well fundamentally the problem is that we are trying to create an in-memory bitmap at the size of the output image | 12:54.43 |
| | Which is resolution dependent | 12:54.51 |
| | So potentially always likely to cause a vm error | 12:55.08 |
| chrisl | And doing so pre-clist.... | 12:55.19 |
| kens | Indeed! | 12:55.30 |
| | I'm not sure post clist would help, depends if it clips to the band size | 12:56.01 |
| chrisl | There would at least then be the option to clip to the band | 12:56.17 |
| kens | If it does that would be better. Otherwise we shoudl be creatng an image at the size of the input (htough even that is risky) | 12:56.25 |
| chrisl | I don't think we can do | 12:56.46 |
| | that | 12:56.48 |
| kens | I thought it just turned it into a type 1 image | 12:57.09 |
| | Which would then be rescaled as required when rendering | 12:57.27 |
| chrisl | I thought there would be problems applying the mask in the source space - especially if the mask and image dimensions don't match | 12:57.58 |
| kens | I'm not sure that would matter, we just need an image with the mask applied. Of course the quality may not be as good, but on the other hand, it stands more chance of working. | 12:59.18 |
| | But post clist seems to be the time this should bge done, and the memory device clipped to the band | 12:59.33 |
| | So maybe ths should be on Ray's desk ? | 12:59.46 |
| | I'm pretty sure its not a PDF interpreter problem | 12:59.58 |
| | Grr I can't debug a 64-bit executable because I have a 32-bit installtion of VS | 13:01.31 |
| chrisl | What??? | 13:01.42 |
| kens | Seems my VS installation is 32-bit and it can't debug a 64-bit executable, never realised that before | 13:02.09 |
| chrisl | Mine is 32 bit, and I'm pretty sure I can debug 64 bit exes | 13:02.32 |
| kens | Well, mine won't let me :-( | 13:02.46 |
| | wants me to use remote debugging | 13:03.09 |
| Robin_Watts | OK. rebooting to move PCs. bbiab. | 13:03.14 |
| chrisl | Hmm, so strange results from my subclassing fix..... | 13:04.18 |
| kens | Oh :-( | 13:04.30 |
| | Ah those look like files I had trouble with before | 13:05.06 |
| | psdcmyk is suspicious | 13:05.12 |
| | I thought 27-09 was a dictionary thng but I could be mistaken, did you do a bmpcmp ? | 13:05.46 |
| chrisl | My current bmpcmp is from that | 13:06.12 |
| kens | Justy looking | 13:06.18 |
| | the 27-09.ps looks ignorable | 13:06.25 |
| | Ah, the psdcmyk ones I know about :-) | 13:07.00 |
| chrisl | Bug688584.ps I've idea what it thinks is different there | 13:07.04 |
| kens | If you push the subclasses then it fixes a genuine problem the candidate output ios correct, the reference is wrong | 13:07.27 |
| | Bug688584.ps came up for me before, I chose to ignore it in the past | 13:08.21 |
| chrisl | So the "Page 9 exp" text appearing is not me? | 13:08.35 |
| kens | No its real and its correct | 13:08.45 |
| chrisl | I mean it's independent of my gc change | 13:09.01 |
| kens | Its caused by forcing on device subcalssing | 13:09.13 |
| | The device subclassing forces the code to take a 'proper' route and fixes a genuine problem in the device | 13:09.33 |
| | $(SolutionDir)..\debugbin\gswin32Your results look fine to me | 13:09.54 |
| | Grrr | 13:09.57 |
| | Your results look fine to me | 13:10.03 |
| chrisl | Alright, thanks | 13:10.12 |
| | TBH, I think the "right" solution would to have an allocator method "change_type" which does that stuff - but I don't want to go down that road just now | 13:11.35 |
| kens | Well, as always I tend to be conservative with changes, but you're probably correct and it would be neater. I thnk I just wanted to see the back of the whole thng by then. | 13:12.28 |
| chrisl | The thing is, the rest of that function would remain, because the allocator doesn't know about the "other" stype inside the structure..... | 13:13.23 |
| kens | Yeah, but it would look a bit less like voodoo | 13:13.49 |
| chrisl | True, I'll put it on my to-do list..... | 13:14.26 |
| | kens: well, VS2005 lets me debug 64 bit executables - I just checked | 13:15.11 |
| kens | Maybe you installed a 64-bit version | 13:15.37 |
| chrisl | There wasn't a 64 bit version of VS2005.... | 13:16.02 |
| kens | THen I'm baffled | 13:16.21 |
| chrisl | Have you got the exe to debug set in the project? | 13:16.44 |
| kens | I do yes | 13:16.59 |
| | I won't worry about it right now though | 13:17.11 |
| chrisl | No, just strange | 13:18.07 |
| marcosw | I'm having trouble using pipes with gswin32c.exe. The documentation says that -sOutputFile=%%pipe%%type should work but instead I end up with a file called %pipe%type. What am I doing wrong? | 14:19.02 |
| kens | I htnk you need to create the named pipe first ? | 14:19.26 |
| marcosw | If i run "echo a | more" in windows it does what you'd expect, -sOutputFile=%%pipe%%more generates a file called %pipe%more (I'm using more instead of type since type appears not to accept input from stdin, or whatever windows calls it). | 14:24.57 |
| kens | piping and named pipes are not the same, at least not in WIndows | 14:27.46 |
| | BUt I admit I've never tried ths stuff | 14:28.36 |
| marcosw | okay, nevermind. | 14:28.53 |
| mvrhel_laptop | something else for henrys to worry about while in Flint | 17:46.11 |
| | http://www.nytimes.com/2015/10/09/us/flint-michigan-detroit-water-supply-lead.html?rref=collection%2Fsectioncollection%2Fscience&action=click&contentCollection=science®ion=stream&module=stream_unit&version=latest&contentPlacement=5&pgtype=sectionfront | 17:46.13 |
| | Forward 1 day (to 2015/10/10)>>> | |
IRC Logs