| | <<<Back 1 day (to 2011/11/08) | 2011/11/09 |
| Robin_Watts | mvrhel: Did you get the car booking sorted? | 00:43.18 |
| mvrhel | Robin_Watts: no I have not. the costs that I am seeing seem very high | 00:43.42 |
| Robin_Watts | I don't see why I should be getting better rates than you, but I can try to book for you from here maybe? | 00:43.44 |
| | When would you want to pick up? | 00:43.53 |
| mvrhel | well we are arriving Monday morning | 00:44.04 |
| | around 8:00am | 00:44.13 |
| Robin_Watts | Miami International? | 00:44.48 |
| mvrhel | yes | 00:44.53 |
| | I was thinking that I would return it Friday morning when I had to take my wife to the airport | 00:45.11 |
| | or rather she would return it perhaps | 00:45.23 |
| | I have not thought this through yet | 00:45.32 |
| Robin_Watts | 200 dollars or so for a Chevy Aero. | 00:46.47 |
| | mvrhel: Don't feel you have to get a car if you don't want one. | 00:48.07 |
| mvrhel | wow. I dont understand how you get that price. mine comes out 100/day | 00:51.12 |
| | comes to $481 | 00:52.14 |
| | what are these people smoking | 00:52.18 |
| | hmm ok. with the areo is is 79 per day | 00:53.35 |
| Robin_Watts | That's still way more. | 00:53.49 |
| | What car would you like? | 00:53.53 |
| mvrhel | yes makes no sense | 00:53.54 |
| Robin_Watts | Damn. I was going to suggest I book it, but they'll want my credit card when you collect. | 00:54.38 |
| mvrhel | Robin_Watts: don't worry about this. | 00:54.51 |
| Robin_Watts | Try telling the site you're from the UK? | 00:54.52 |
| mvrhel | apparently | 00:55.04 |
| | I will look into that | 00:55.09 |
| | I need to look at all the costs for this stuff | 00:55.25 |
| | i.e. how much is the shuttle vs. car etc | 00:55.34 |
| | weird a mini van from alamo is only 208 for that whole time | 00:58.49 |
| | with taxes and fees | 00:59.00 |
| | hold 7 people | 00:59.17 |
| | maybe I should get that and just come and pick you up | 00:59.29 |
| | Robin_Watts: what is the cost of your rental? | 01:01.01 |
| Robin_Watts | 81 quid. So 120 dollars or so. | 01:01.21 |
| mvrhel | it seems the mini van is my cheapest option at 209 with taxes | 01:02.01 |
| Robin_Watts | Well, if you get a minivan, miles could get a normal car? | 01:02.17 |
| mvrhel | I guess I will book it now | 01:02.20 |
| | yes | 01:02.22 |
| | I will ping him about this | 01:02.27 |
| | or I could even pick people up | 01:02.40 |
| Robin_Watts | It's a fair hike to the airport and back - be wary about volunteering :) | 01:03.00 |
| | Tell Miles I've got a 4/5 seater thing booked, will you? | 01:03.23 |
| mvrhel | Yes I will do that | 01:03.55 |
| | oh how far is the airport? | 01:04.03 |
| Robin_Watts | 30 mins or so, I guess? | 01:04.14 |
| mvrhel | ok | 01:04.19 |
| Robin_Watts | (one way) | 01:04.25 |
| mvrhel | so for scott its like a trip into town | 01:04.49 |
| Robin_Watts | :) | 01:04.55 |
| mvrhel | what day are you returning your car? | 01:05.58 |
| | oh you are returning yours to the local place | 01:06.08 |
| Robin_Watts | In theory, thursday night. | 01:06.10 |
| | but I fear it may be closed when I get there, so it might be friday morning. | 01:06.26 |
| | yeah, to the local place. | 01:06.42 |
| | There is an Alamo place on south beach. | 01:06.56 |
| mvrhel | ok. I have booked this to return friday morning so that I can take my wife and alden to the airport (or they can drive it themselves) | 01:06.59 |
| | but then I leave Saturday evening/afternoon | 01:07.18 |
| Robin_Watts | ah, if they've got to go to the airport, that's probably easiest. | 01:07.23 |
| | I think there are 4 of us going to the airport at the same time on sunday, so sharing a cab may be affordable. | 01:08.10 |
| mvrhel | right I think Ray and I both leave Saturday | 01:08.28 |
| | My son Ethan will also be with me that day | 01:08.38 |
| | I am starting to be a bit overwhelmed with these logistics.... | 01:09.29 |
| | grumble | 01:09.54 |
| Robin_Watts | mvrhel: It gets to a point where I take a best guess and figure that anything else can be solved with judicious application of money :) | 01:11.42 |
| | bedtime for me. night. | 01:13.33 |
| mvrhel | yes | 01:13.38 |
| | have a good night | 01:13.44 |
| tkamppeter | Did someone already have a look at bug 692626? It breaks printing from LibreOffice on PostScript printers totally. | 09:33.51 |
| kens | No, I haven't looked at it, busy with customer problems | 09:34.28 |
| tkamppeter | kens, should I perhaps better return to use Poppler for PDF->PS in Oneiric or is there are chance of a simple and quick fix? | 09:40.17 |
| kens | tkamppeter I don't know what is wrong, until I do I can't say whether there is a possible quick fix. | 09:41.43 |
| | I've just finished fixing a Seg fulat, and I'm not wrking ona customer problem which causes a simple PostScript file to eat 2GB of memory, tracking the memory is non-trivial. | 09:42.25 |
| | I still have a number of issues to address with transparency flattening, which affetcs both PostScript output and PDF/A outptu (does not support PDF > 1.3) | 09:43.00 |
| | All of these are issues I deem to be important, all of them will likely also affect your Oeniric relaee (PDF->PostScript) | 09:43.37 |
| tkamppeter | kens, Oneiric is already released, after release this bug got reported and now I need to issue an update for Oneiric quickly to fix this common printing case. | 09:44.57 |
| | kens, quickest would be to return to Poppler but this looses GS's color management, but more important is to be able to print at all. | 09:46.34 |
| kens | tkamppeter I can't promise anything, I'm just trying to give you a sense of what it is I'm up to. | 09:51.09 |
| | I'm not ignoring the bug, but its not the only issue on my plate right now. | 09:51.25 |
| | The regular staff meeting was last night, but I will atlk to henry when he comes online later this afternoon. | 09:52.09 |
| | However I won't switch tsks from teh memory issue right now. | 09:52.24 |
| tkamppeter | kens, I understand, I only have posted as I need to make a decision so that our users can print. | 10:07.50 |
| kens | If you pop back in this afternoon you cna see whatever Henry says. | 10:09.43 |
| | I've sent him an email asking him to review the logs adn read this conversation. | 10:10.06 |
| tkamppeter | kens, thanks. | 10:10.35 |
| kens | No problem. | 10:11.32 |
| Robin_Watts | summons tor8 | 11:45.26 |
| kens | tkamppeter ping ? | 12:48.43 |
| Robin_Watts | kens: This memory leak thing... | 12:49.06 |
| kens | yes Robin_Watts ? | 12:49.15 |
| Robin_Watts | Is that bug 692670 ? | 12:49.15 |
| kens | Yes | 12:49.21 |
| Robin_Watts | Did you get anywhere with it? | 12:49.28 |
| kens | Not yet, I was going to talk to you about it after lunch | 12:49.42 |
| Robin_Watts | I'm just trying a tweak to Memento that might help. | 12:49.42 |
| kens | DO you know what the output from -ZA means ? All the cryptic flags and stuff ? | 12:50.03 |
| | I was also going to write something to remove matching alloc/free pairs. | 12:50.20 |
| Robin_Watts | I figure if I make a new postscript operator that lists all the blocks that have been allocated and are still around since the last time it was called, we can put that on every showpage, and see what's leaking. | 12:50.36 |
| kens | That sounds possilbe. THe problem with pdfwrite is that stuff does deliberately 'leak' acorss pages', its saved up until the job ends. | 12:51.13 |
| | In fact until GS is closed actually | 12:51.27 |
| Robin_Watts | right. | 12:51.30 |
| kens | Hmm can you get to bbc.co.uk ? | 12:52.03 |
| Robin_Watts | yes. | 12:53.00 |
| kens | Weird, I can't.... | 12:53.06 |
| | Other web sites are OK though. | 12:53.14 |
| | Can you tell me the IP address ? | 12:53.25 |
| | Huh, its replying to ping. | 12:53.48 |
| Robin_Watts | 212.58.241.131 | 12:53.49 |
| kens | I'm seein 244.70... | 12:54.03 |
| Robin_Watts | The bbc has arrangements with many ISPs to provide local caches. | 12:54.14 |
| kens | Oh, now its working.... | 12:54.22 |
| | oooh: | 12:54.49 |
| | http://www.bbc.co.uk/news/technology-15648899 | 12:54.49 |
| Robin_Watts | Ditching flash good. Replacing it with AIR, oh god... | 12:55.46 |
| kens | Yep :-( | 12:55.52 |
| | Hi tor8 | 12:57.26 |
| tor8 | hi | 12:57.39 |
| ghostbot | hey | 12:57.39 |
| Robin_Watts | tor8: I had thoughts on the gridfitting stuff. | 12:57.57 |
| | I'm going to factor the gridfitting stuff out into a single function. | 12:58.12 |
| | and make it sensitive to FLT_EPSILON. | 12:58.23 |
| | I hope that will solve the problems. | 12:58.32 |
| tor8 | Robin_Watts: okay! | 12:58.36 |
| | another thought, why not use round for all but the 1 pixel wide/tall cases? | 12:59.22 |
| Robin_Watts | or to put it another way... why not round, unless that would cause the images to disappear ? | 13:00.40 |
| | I think that will have problems. | 13:00.49 |
| | Consider a 100x100 image that's actually only non transparent for 2 pixels around the edge. | 13:01.13 |
| | Then consider another image that sits in the middle of that and is supposed to cover the 96x96 pixels of the first. | 13:01.38 |
| tor8 | right! | 13:01.58 |
| Robin_Watts | It would be possible, I think, under the round scheme, for the inner image to shrink, and leave cracks. | 13:02.12 |
| | kens: Another idea... | 13:05.55 |
| | test.ps is 2400 pages, or something stupid. | 13:06.05 |
| kens | 1500'is | 13:06.16 |
| Robin_Watts | Is it worth making it so that it's 2400 copies of the SAME page ? | 13:06.21 |
| | and seeing if the problem still occurs ? | 13:06.30 |
| kens | Eah cpage has a procedure which calls 131 other procedures, each of whic hdrawss an image | 13:06.36 |
| | The pages *are* all identical | 13:06.47 |
| Robin_Watts | Do they all call the same top level procedure ? | 13:07.22 |
| kens | Yes. | 13:07.28 |
| | Its a carppy way to draw a logo..... | 13:07.43 |
| | I assume its done because its too big for a single 64k string source, and predates ReusabelStreamDecode | 13:08.04 |
| Robin_Watts | I get 1300 new blocks each page. | 13:08.32 |
| kens | I'm not sure what that measn.... | 13:08.43 |
| | I see 1n increase of ~1.1Mb per page | 13:08.52 |
| Robin_Watts | Every new page 'leaks' 1300 allocations. | 13:08.58 |
| kens | Some of those undoubtedly are not leaks. | 13:09.23 |
| Robin_Watts | yeah, hence the quotes :) | 13:09.36 |
| kens | Each image gets a new object ID which is a composite PostScript object, and an image dictionary.... | 13:09.48 |
| | I'm not sure of the lifetime of the ditionary but theobject ID persists until teh file is compelteed | 13:10.06 |
| Robin_Watts | There are 1300 blocks extant at the end of each page that were not extant at the end of the previous page. | 13:10.53 |
| kens | Robin_Watts : I need to get some lunch and get back to this, give me an hour or two. | 13:11.03 |
| | If tkamppeter turns up ask him to ping me when I'm back | 13:11.10 |
| Robin_Watts | I'm going to get lunch soon too. | 13:11.20 |
| kens | OK good timing then | 13:11.26 |
| Robin_Watts | Popular sizes are 40, 288, 2600, and 2160. | 13:11.58 |
| tkamppeter | kens, hi | 13:13.16 |
| kens | tkamppeter, a possible work around: Have you considered switching back to pswrite instead of ps2write ? | 13:20.53 |
| | I haven't tested it, it may give working results, and will stilll give you all the other colour stuff in the latest version of GS. | 13:21.14 |
| tkamppeter | kens, pswrite is not suitable as it flattens all text to huge bitmaps. | 13:25.25 |
| kens | Ah well, just a thought. | 13:26.32 |
| Robin_Watts | Did ray do something to make vmreclaim work less often recently ? | 14:11.30 |
| kens | Yes | 14:11.36 |
| | He redefined 2 vmreclaim to do nothing | 14:11.46 |
| Robin_Watts | so if I do '2 vmreclaim' it might not do anything? | 14:11.54 |
| kens | .vmrecalim however still works as before | 14:11.57 |
| Robin_Watts | Ah, thanks. | 14:12.04 |
| kens | Robin_Watts : it shuold do nothing | 14:12.05 |
| | Robin_Watts : So I have a memento build now (I believe) how do I see allocations ? | 14:12.44 |
| Robin_Watts | Let me give you a patch, hold on. | 14:13.24 |
| kens | OK I'll send you a reduced file too ;-) | 14:13.34 |
| Robin_Watts | http://ghostscript.com/~robin/0001-Memento.patch | 14:14.29 |
| | git am 0001-Memento.patch to apply it. | 14:14.42 |
| kens | One momment | 14:14.50 |
| | OK revuilding. | 14:16.08 |
| | OK built | 14:17.06 |
| | H,, shuld I exepct to see something ? | 14:17.35 |
| | should | 14:17.44 |
| Robin_Watts | OK, take your test5.ps and duplicate the last 2 lines. | 14:18.10 |
| | So that we have 2 pages. | 14:18.16 |
| | Then run: | 14:18.20 |
| | gs/membin/gswin32c.exe -sDEVICE=pdfwrite -sOutputFile=out.pdf ../MyTests/test5.ps | 14:18.30 |
| | So we get showpage prompts. | 14:18.42 |
| kens | Well, I'm running the windowed version, and I already get showpage prompts | 14:18.59 |
| | Still nothing to see | 14:19.05 |
| Robin_Watts | I've changed the code that does the showpage prompt is gs_init.ps to vmreclaim then output the list of new blocks. | 14:19.50 |
| | It's down to 18 blocks between the first and second showpage for me now - much more managable. | 14:20.16 |
| kens | OK, that worked in gswin32c, but not gswin32 | 14:20.17 |
| Robin_Watts | So, we have a list of the block numbers and sizes that leaked. | 14:20.39 |
| | "leaked" | 14:20.43 |
| kens | Yes, that's why I reduced the complexity ;-) | 14:20.43 |
| Robin_Watts | Now, we can rerun in the debugger and look at each of those blocks. | 14:21.01 |
| | Set up the debugger to run the exact same command. | 14:21.17 |
| kens | The memory pointers will be different | 14:21.27 |
| | But give me a moment | 14:21.35 |
| Robin_Watts | That's why we use block numbers, not memory pointers. | 14:21.52 |
| kens | OK I *think* that's the same | 14:22.25 |
| Robin_Watts | I've cut/pasted myself the list of block numbers into an editor window. | 14:22.43 |
| | 68445 is the first one for me (listed in reverse order, sorry) | 14:22.54 |
| kens | I have them open in an editor | 14:22.55 |
| Robin_Watts | so put a breakpoint on Memento_inited. | 14:23.29 |
| kens | I don't get the showpage delimiters. | 14:23.33 |
| | WHich makes it hard to see. | 14:23.41 |
| Robin_Watts | What command are you using ? | 14:23.46 |
| kens | As above with 2> out.log appended | 14:24.02 |
| | To capture stderr | 14:24.13 |
| Robin_Watts | There are only 2 pages, right ? | 14:24.17 |
| kens | Yes | 14:24.23 |
| Robin_Watts | So look for "Blocks allocated and still extant" | 14:24.32 |
| | That's the start of the second pages output. | 14:24.49 |
| kens | OK in that case the first block after that is 68948 for me | 14:24.54 |
| Robin_Watts | I have 18 blocks after that totalling 9120 bytes. | 14:25.09 |
| kens | Yes | 14:25.22 |
| Robin_Watts | They are listed in reverse order of allocation (sorry, just the way the linked list works out) | 14:25.41 |
| kens | blocks 1 2 and 5 look possible | 14:25.49 |
| Robin_Watts | So the last one is the first one, as it were. | 14:25.51 |
| kens | OK breakpoint | 14:26.12 |
| Robin_Watts | Right, 1,2 and 5 are the large ones for me. | 14:26.23 |
| kens | I'm looking for ~4k so two of those would be right (I think) | 14:26.40 |
| Robin_Watts | So restart and run til you hit the breakpoint. | 14:26.41 |
| kens | done that | 14:26.47 |
| Robin_Watts | Ctrl-Alt-Q | 14:26.54 |
| kens | Yes, quickwatch | 14:27.09 |
| Robin_Watts | Memento_breakAt(blocknumber) | 14:27.26 |
| | so for me Memento_breakAt(68739) | 14:27.39 |
| | (that's block '5') | 14:27.48 |
| kens | 68940 for me | 14:28.08 |
| | and done | 14:28.13 |
| Robin_Watts | close the quickwatch window and carry on. | 14:28.24 |
| kens | yep, gets to end of job and GS> prompt | 14:28.39 |
| | No break | 14:28.43 |
| Robin_Watts | Same for me :( | 14:28.57 |
| kens | OK, not just me then | 14:29.06 |
| | Different numbers in debugger | 14:31.03 |
| | Will try that number | 14:31.07 |
| Robin_Watts | Looking like a bug in Memento. Probably something stupid with the chunk allocator stuff. | 14:31.33 |
| | Oh, god, sorry. | 14:31.59 |
| | You also need to breakset Memento_breakpoint :) | 14:32.10 |
| kens | I wondered about that. | 14:32.18 |
| | OK so I have a breakpoint at Memento_breakpoint | 14:33.17 |
| | and its been hit. | 14:33.20 |
| | Set a condition ? | 14:33.24 |
| Robin_Watts | Ok, so you've stopped where it's doing that allocation. | 14:34.32 |
| kens | I'm, not sure I have | 14:34.40 |
| Robin_Watts | You can look up the stack and see where it's been called from. | 14:34.50 |
| kens | I have set an unconditional breakpoint at Memento_breakpoint | 14:34.52 |
| Robin_Watts | kens: And Memento calls Memento_breakpoint when it's about to allocate the blocknumber you gave to Memento_breakAt() | 14:35.25 |
| kens | Yes, I just tracked back that far | 14:35.33 |
| | Its been called from gsicc_load_profile_buffer | 14:35.53 |
| | Seems that we are DCT encoding the output and that is causing an ICC load for every image | 14:36.15 |
| Robin_Watts | Ah... so are you keeping an icc profile per page around? | 14:36.16 |
| kens | *I* am not.... | 14:36.23 |
| | choose_DCT_params calls gsicc_init_device_profile | 14:36.48 |
| | WHich eventually loads the profile and so on. | 14:36.57 |
| | I suspec thit is being done multiple times, but only one is being freed. | 14:37.13 |
| | there are three identical sized allocations, if 2 of them are left dangling then I would get 4K which is pretty much exactly thte size I'm looking for | 14:37.46 |
| | I should check the other three | 14:38.01 |
| Robin_Watts | Now do Ctrl-Alt-Q and Memento_breakAt(next number) | 14:38.32 |
| | and then carry on. | 14:38.35 |
| kens | Oh, I just restarted the executable ;-) | 14:38.43 |
| | Didn't break, must have screwed up | 14:40.05 |
| | Yes, sure did | 14:40.28 |
| Robin_Watts | ok, all 3 of the ~2K allocations I see come from choose_DCT_params loading the icc profile, but they aren't identical. | 14:40.29 |
| | I see 2600, 2600, and 2160 bytes. | 14:40.59 |
| kens | Hmm, any pair is in the range I want | 14:41.31 |
| | Hmm, is not breakpointing now :-( | 14:41.54 |
| | OK, I cna't spell | 14:42.26 |
| Robin_Watts | IN choose_DCT_params, we call gs_make_mem_device. | 14:43.23 |
| | to get a device in &mdev. | 14:43.32 |
| kens | Yep | 14:43.41 |
| Robin_Watts | We retain that, and we load the icc profile into that... | 14:43.44 |
| kens | Well, seems reasonable | 14:43.53 |
| Robin_Watts | I can't see where mdev is ever freed (or stored) before we exit that function. | 14:43.57 |
| kens | That would be a bad thing. | 14:44.06 |
| | But it must get closed somewhere I think. Possibly it has no finalize member | 14:44.19 |
| Robin_Watts | mdev has no finalize entry. | 14:45.26 |
| kens | I guess that's the problem. But I'm only guessing. | 14:45.39 |
| | Presumably it uses a default finalize. | 14:45.58 |
| Robin_Watts | when ? | 14:46.11 |
| kens | I have no idea..... | 14:46.23 |
| | This is a new area of pdfwrite for me, its always worked before and never needed attention | 14:46.50 |
| | Anyway, I know where to go looking I think, so thanks for the assistance! | 14:47.12 |
| Robin_Watts | mdev is on the stack, so I don't see how it can safely EVER be finalised after we've left that function. | 14:47.36 |
| kens | I don't know, but I'll look into the problem, I cna track through the C code OK. | 14:47.57 |
| | Now I know where to go poking at least | 14:48.10 |
| kens | goes to fetch coffee | 14:51.53 |
| Robin_Watts | I just tried doing a gx_device_retain(&mdev, false); to bin the device, and it called the finalize thing, and fell over in a nasty heap. | 14:55.24 |
| | I think the finalize gubbins won't work for stuff allocated on the stack. | 14:55.41 |
| | or rather using ref counts to call it. | 14:58.24 |
| | A direct call to gx_device_finalise(pdev->memory, &mdev); might | 14:58.43 |
| henrys | it might be best to simply allocate the device. | 14:59.17 |
| Robin_Watts | Right, that stops the leak for me. | 14:59.59 |
| | but care needs to be taken in there so all the 'if (code < 0) return' cases, correctly finalize before they bale. | 15:00.48 |
| Robin_Watts | thinks that deserves a cup of tea. back in a mo. | 15:01.12 |
| kens | has hot orange instead, still not feeling well :-( | 15:05.44 |
| | I hate this device stuff, its too complictaed. | 15:07.23 |
| | Allocating it on the stack just seems stupid. | 15:07.50 |
| Robin_Watts | kens: Why? Saves a malloc/free pair. | 15:08.08 |
| henrys | I was on a campaign to make all device allocation malloc'd | 15:08.38 |
| kens | Because it implicitly leaves stuff dangling. | 15:08.46 |
| henrys | the bookkeeping gets too complicated. | 15:08.49 |
| kens | Exactly. | 15:08.54 |
| Robin_Watts | henrys: If you mean "remove it from the gc domain", I'd be with you. | 15:09.09 |
| kens | I'm going to change tihs one to a malloc'ed device. | 15:09.11 |
| Robin_Watts | kens: I'll push the memento changes in a separate commit (without the gs_init.ps changes) | 15:09.51 |
| kens | Can fix the 'return code' problems by using a goto, just like everywhere else. | 15:09.53 |
| henrys | Robin_Watts:well that's another issue. - I am just saying they should be malloc'd | 15:09.55 |
| kens | Robin_Watts : That'd be great, this looks useful to me. | 15:10.09 |
| Robin_Watts | Should I leave the gs_init.ps changes in, just commented out ? | 15:10.32 |
| kens | I would, yes. | 15:10.44 |
| Robin_Watts | Will do then. | 15:10.50 |
| kens | Easier to change. But needs a 'dno't use this unless you know what you're doign' comment | 15:11.01 |
| Robin_Watts | done. | 15:20.43 |
| kens | Robin_Watts : If I just finalize the dvice, it seems to be OK. | 15:39.47 |
| Robin_Watts | yes, that was my experience too. | 15:40.00 |
| kens | Oh, thought you said it crashed | 15:40.09 |
| Robin_Watts | If I tried to do it using reference counting, it crashed. | 15:40.21 |
| | If I called gx_device_finalize it worked fine. | 15:40.32 |
| kens | Oh, well I think I'll just stick with finalizing it | 15:40.34 |
| Robin_Watts | That was my thought - but you need to add more gotos to fix the error exits. | 15:41.00 |
| kens | That's not a problem. | 15:41.12 |
| | Its not a huge routine | 15:41.21 |
| Robin_Watts | indeed. | 15:41.27 |
| kens | In fact thre are only 2 places, so I'll just add finalize to hte error handling. | 15:41.50 |
| | well, 3.... | 15:42.06 |
| Robin_Watts | I reckon "goto error;" is neater, personally, but... | 15:42.59 |
| | whatever you see best, obviously. | 15:43.14 |
| kens | If it was any more complex I would, but this is simple enough. | 15:43.14 |
| | Damn, found another one, OK goto it is | 15:43.35 |
| | OK, lets see if that's OK on the cluster | 15:47.36 |
| tkamppeter | henrys, can you have a look at bug 692626, it breaks printing from LibreOffice to PostScript printers under Linux. I would like to issue a GS update for Ubuntu Oneiric if there is a simple fix for the bug. If not I would have to switch Oneiric back to Poppler for PDF->PS, loosing color management. Problem seems to be a font problem wehn converting PDF to PS. | 15:50.42 |
| kens | If this fix for the memory problem works ou OK< I'll look at it next tkamppeter. Testing the fix now. | 15:51.12 |
| | memory problem fix that is | 15:51.22 |
| | At this rate the cluster tests will be finished before my local test of the customer's original job.... | 16:14.45 |
| Robin_Watts | Is the local test showing the expansion in memory size? | 16:18.32 |
| kens | No, it slooks fine, I just want to look at the output, and give a peak number to the customer | 16:18.51 |
| | Currently at 25Mb | 16:19.00 |
| | I'm expectng it to finish at around 26.5 Mb | 16:19.21 |
| Robin_Watts | It was taking a couple of seconds a page for me - that's got to mean at least an hour. | 16:19.25 |
| henrys | tkamppeter:we agreed kens would look at it next. | 16:19.28 |
| kens | Well, its a job designed to run slowly. | 16:19.46 |
| | Has been running now for 28 minutes | 16:20.03 |
| | Finished | 16:20.21 |
| | Just under 26 Mb | 16:20.29 |
| Robin_Watts | nice one. | 16:20.34 |
| kens | Thanks to you and Memento, otherwise I'd probably still be struggling. | 16:20.53 |
| Robin_Watts | One day Memento will solve a bug without me needing to hack on it for a bit :/ | 16:21.09 |
| kens | But each time its capabilities improve ;-) | 16:21.27 |
| | Trouble is memory bugs do tend to be a bit 'custom' | 16:21.40 |
| Robin_Watts | yeah. | 16:21.47 |
| | Bah. I've redone the mupdf gridfitting, and now the shift is REALLY obvious. And I can't see why :( | 16:22.25 |
| kens | OK tkamppeter I'm going to commit this now and will get to your bug #69262 tomorrow morning | 16:22.43 |
| | #692626 | 16:22.55 |
| henrys | I think I'm addicted to battlestar galactica | 16:23.15 |
| Robin_Watts | henrys: It's very good. | 16:23.26 |
| kens | board game, TV series or computer game ? | 16:23.32 |
| henrys | tv I don't know what I'll do when I watch them all. | 16:23.52 |
| Robin_Watts | (but don't bother watching "The Plan") | 16:23.57 |
| kens | Good grief, now the PCL/XL files have strated shogin indeterminisms..... | 16:24.04 |
| henrys | with your memory fix you mean? | 16:26.48 |
| kens | Its not my fix, that can only affect pdfwrite, but these are reported against rendering: | 16:27.34 |
| | ran 59921 tests in 1812 seconds on 11 nodes | 16:27.34 |
| | Differences in 5 of 48379 non-pdfwrite/ps2write test(s): | 16:27.34 |
| | tests_private/customer_tests/bug691464b.xl.pbmraw.600.1 pcl peeves i7 | 16:27.34 |
| | tests_private/customer_tests/bug691464b.xl.pbmraw.75.0 pcl x6 peeves | 16:27.34 |
| | tests_private/customer_tests/bug691464b.xl.ppmraw.600.1 pcl miles inches | 16:27.35 |
| | tests_private/customer_tests/bug691464b.xl.ppmraw.75.0 pcl meters i7b | 16:27.35 |
| | tests_private/pcl/pcl5efts/fts.2291.ppmraw.600.1 pcl inches macpro | 16:27.36 |
| henrys | well added new test files the bug* ones yesterday don't know about the fts. | 16:28.29 |
| kens | AH! THe fts one is a regular attendee | 16:28.50 |
| | Robin_Watts : How do I get rid of the Memento patch ? | 16:30.59 |
| henrys | sometimes it amazes me what I write ... "I added the bug* test files yesterday" is what I meant to say. | 16:31.14 |
| kens | I understood, no problem | 16:31.29 |
| Robin_Watts | git reset --hard HEAD~1 ? | 16:31.39 |
| kens | Which presumably will kill my changes :-( | 16:31.52 |
| | Though I did commit them, so maybe not | 16:32.00 |
| kens | wonders if I just shafted my Git repo | 16:32.20 |
| Robin_Watts | That command will revert you by 1 commit. | 16:32.29 |
| kens | OK so that will get rid of my fixes then ? But not the Memento patch | 16:32.49 |
| | Or am I more confused than normal ? | 16:33.03 |
| Robin_Watts | OK. so did you just do that command?> | 16:33.21 |
| kens | Yep | 16:33.27 |
| | I'm wondering what's gone poof ;-) | 16:33.39 |
| Robin_Watts | gir reflog | 16:33.48 |
| | git relog -20 | 16:33.52 |
| | That will show you a log of recent activity with the hashes next to it. | 16:34.23 |
| kens | Yes, but I'm not sure if the fact that my changes are listed is good or not | 16:34.44 |
| Robin_Watts | Find out which one had your changes in. | 16:34.57 |
| kens | It has teh 'am' Memento patch as well as my commit | 16:34.58 |
| | HEAD[1] | 16:35.05 |
| | Err no | 16:35.10 |
| | HEAD[2] | 16:35.12 |
| Robin_Watts | And what's the hash ? | 16:35.16 |
| kens | The Memento patch is at HEAD[3] | 16:35.19 |
| | My code is hash 52882a0 | 16:35.32 |
| | THe memento patch is 7c6e15e | 16:35.45 |
| Robin_Watts | So git log -10 shows the memento patch as being the HEAD ? | 16:35.50 |
| kens | No. | 16:35.58 |
| | HEAD[0] says HEAD~1: uipdating HEAD | 16:36.10 |
| Robin_Watts | no. not reflog, git logg -10 | 16:36.25 |
| kens | HEAD[1] says checkout:mmoving from master to 1366...... | 16:36.30 |
| Robin_Watts | chuck the output from git reflog -10 and git logg -10 into a pastebin :) | 16:37.06 |
| kens | I think its trying to tell me the asme thing as Git GUI, there's a collision | 16:37.09 |
| Robin_Watts | kens: We can probably just revert to before the memento patch went in, then cherry pick your changes. | 16:38.06 |
| | Then nothing should conflict. | 16:38.17 |
| kens | http://pastebin.com/v0hizW8B | 16:38.30 |
| | I can always redo my changes, it wasn't hugely extensive | 16:38.44 |
| Robin_Watts | git rebase --abort | 16:39.06 |
| kens | OK | 16:39.29 |
| Robin_Watts | That will put you back to where you were before the rebase. | 16:39.31 |
| | What's the top of git logg -10 now ? | 16:40.00 |
| kens | git logg looks the same | 16:40.03 |
| Robin_Watts | so HEAD is 138d68e ? | 16:40.23 |
| kens | No, still 52882a0 | 16:40.34 |
| Robin_Watts | ok. IT wasn't that in the pastebin :) | 16:40.49 |
| | so: git reset --hard HEAD~2 | 16:41.12 |
| kens | Really ? says that hash ewith (master) when I look at it | 16:41.22 |
| | THough it doesn't say HEAD that's true | 16:41.30 |
| Robin_Watts | Now where are master and HEAD ? | 16:41.55 |
| kens | Head is now at 138d68e | 16:42.01 |
| | git logg says master at the same place | 16:42.20 |
| | Along with some weird branching.... | 16:42.37 |
| | for cluster/ken and origin/master | 16:42.50 |
| tkamppeter | kens, OK, I am looking forward for tomorrow ... | 16:42.55 |
| Robin_Watts | Damn. I need to remember how to get master back to be the same as HEAD. | 16:43.21 |
| kens | tkamppeter I doubt it will be fixed tomorrow, you never kl=now, but I can't promise that. | 16:43.22 |
| | HEAD and master are at teh same place | 16:43.33 |
| tkamppeter | kens, OK. | 16:43.41 |
| kens | Want another pastebin ? | 16:43.42 |
| Robin_Watts | oh, right, so head and master are both 138d68e ? | 16:43.55 |
| kens | Yes | 16:44.00 |
| | Above that are two 'branches' | 16:44.08 |
| Robin_Watts | Now just do: git cherry-pick 52882a0 | 16:44.10 |
| kens | One labelled cluster/ken and one labelled origin/master | 16:44.19 |
| Robin_Watts | Perfect. | 16:44.25 |
| kens | OK can I 'git up' now ? | 16:44.58 |
| Robin_Watts | That will pull just your changes onto your master. | 16:45.08 |
| | Now you can git up, yes. | 16:45.14 |
| | I assume that's git pull --rebase | 16:45.25 |
| kens | I assume so :-) | 16:45.35 |
| | THat looks better | 16:45.40 |
| | Now lets try to push | 16:45.45 |
| | Whew that saeems to be done, thanks. | 16:46.03 |
| Robin_Watts | np. | 16:46.09 |
| kens | Can I get rid of the dangly bit in git logg somehow ? | 16:46.22 |
| | Or maybe I don't need to. | 16:46.39 |
| Robin_Watts | The cluster 'dangle' will go next time you cluster push. | 16:46.43 |
| kens | Aha, OK thanks. | 16:46.56 |
| Robin_Watts | (or rather it'll be moved to be whatever you push next time) | 16:47.09 |
| kens | Just time to write up the bug report then I have to dash. Have to take Melanie to the local sixth form college to see about A levels next year. | 16:47.33 |
| Robin_Watts | tor8: Bah. I was testing it wrong. | 17:04.38 |
| mvrhel | henrys: so that is good news about the screens for the customer | 17:27.39 |
| Robin_Watts | tor8: ping ? | 17:43.09 |
| | http://ghostscript.com/~robin/0001-tor.patch | 17:44.15 |
| ray_laptop | mvrhel: I also was glad to hear that the stochastic threshold array took care of Freek's issues. | 17:50.43 |
| mvrhel | yes | 17:52.31 |
| kens | Heading off now, goodnight all. | 17:55.24 |
| ray_laptop | darn. TortoiseGit is hung. I have to reset my system. I sure hope that my git repo doesn't get honked up :-( | 18:00.25 |
| henrys | mvrhel, ray_laptop:that is good news I was worried those guys were going to disappear. | 18:20.03 |
| | I wonder if my new pcl test files have slowed down the cluster. | 18:20.17 |
| mvrhel | brb | 19:10.26 |
| Robin_Watts | mvrhel: You remember there was that bug about lcms and gs differing in how we round 16 bit color values to 8 bit ones? | 19:37.14 |
| | I have a patch to fix it. http://ghostscript.com/~robin/0001-colround.patch | 19:37.46 |
| | If you have a chance to cast your eyes over it, I'd welcome comments. | 19:38.03 |
| mvrhel | Robin_Watts: ok. I will look this over | 19:38.20 |
| Robin_Watts | If I'm about to change every output file, probably best I only do it once :) | 19:38.30 |
| | Thanks. | 19:38.34 |
| | tor8: ping | 19:44.14 |
| tor8 | Robin_Watts: am here now. | 19:45.10 |
| Robin_Watts | ah, cool. | 19:45.16 |
| | I have a patch above that I hope will solve the rounding issues. | 19:45.31 |
| | Part of the fix is to only add 32767 rather than 32768. | 19:45.51 |
| | I'm not 100% happy about that, but if it works, I'm prepared to swallow it :) | 19:46.09 |
| tor8 | just read your comment on it :) | 19:47.14 |
| mvrhel | bbiab lunch time | 20:01.23 |
| tor8 | Robin_Watts: patch does not apply | 20:13.37 |
| Robin_Watts | Are you all pushed up? | 20:15.26 |
| | if so, I'll pull in, and remake the patch. | 20:15.46 |
| tor8 | hang on, I'm having some network trouble getting to casper | 20:16.07 |
| | can you reach casper? | 20:16.43 |
| Robin_Watts | I'm logged into it yes. | 20:17.12 |
| | Let me try a new connection. | 20:17.16 |
| | yeah, that works too. | 20:17.36 |
| tor8 | grr. I'm losing the connection at the 16th hop | 20:18.39 |
| Robin_Watts | It's a small enough patch to apply manually, I suspect. | 20:18.58 |
| tor8 | I tried applying it cleanly, but got some noise about draw_simple_scale | 20:19.31 |
| | so I tried applying it on top of the old patch you sent yesterday, but that failed miserably too | 20:19.44 |
| Robin_Watts | It should apply cleanly (it incorporates yesterdays patch) | 20:19.59 |
| | The draw_simple_scale changes are just that I deleted draw_simple_scale_gridfit | 20:20.15 |
| tor8 | okay, I can reach casper but ssh hangs waiting to let me in :( | 20:20.51 |
| Robin_Watts | just checked the diffs - it's a very simple patch to apply manually. | 20:21.10 |
| tor8 | yeah. I'll do that while waiting on casper to wake up. | 20:21.32 |
| | okay, edited the diff to take out draw_simple_scale and it fits | 20:23.47 |
| | Robin_Watts: the new grid fit matrix works better for fz_paint_image_imp, compared with the old one | 20:33.49 |
| | but I still get the twice-as-much-as-we-ought effect if I let fz_transform_pixmap gridfit | 20:35.04 |
| mvrhel | Robin_Watts: The color rounding patch looks good. | 21:29.33 |
| Robin_Watts | mvrhel: Thanks. | 22:07.24 |
| | tor8: really? I might have to bite the bullet and try and get setup for ios dev so I can debug it here :( | 22:08.16 |
| | but not tonight :) | 22:08.24 |
| tor8 | Robin_Watts: are you off to finish fallout 3 in time for skyrim? | 22:09.02 |
| | Forward 1 day (to 2011/11/10)>>> | |
IRC Logs