| | <<<Back 1 day (to 2011/12/05) | 2011/12/06 |
| mvrhel | good night | 05:15.57 |
| kens | Hmm, we missed this one: | 08:09.44 |
| | http://www.theregister.co.uk/2011/12/06/training_invades_miami_beach/ | 08:09.44 |
| Robin_Watts | Oddly, I'm much colder this morning than I have been for the last few mornings. | 10:39.43 |
| kens | Strange ;-) | 10:39.59 |
| Robin_Watts | http://www.ebuyer.com/christmas-specials | 15:16.54 |
| | How much must toner/ink be marked up to make that possible... | 15:17.10 |
| kens | Crazy. | 15:17.54 |
| Robin_Watts | Cheapest toner price = 50UKP according to Mr Google. | 15:18.12 |
| kens | Robin, recent question to support regarding pdf_findfont.c is that MuPDF ? | 15:19.00 |
| | I don't think we have a file wth that name in GS | 15:19.43 |
| Robin_Watts | yes | 15:19.57 |
| kens | Godd, saves me replying ;-) | 15:20.07 |
| Robin_Watts | I'll handle that, thanks. | 15:20.23 |
| kens | NP | 15:20.27 |
| Robin_Watts | BT engineer coming tomorrow am. Was expecting it to take longer than that. | 16:14.36 |
| kens | Sounds hopeful though, you downlloaded the thingy ? | 16:15.02 |
| Robin_Watts | No, turned out to be impossible to run the test they wanted. | 16:15.17 |
| kens | :-) | 16:15.22 |
| | Worth waiting then.... | 16:15.30 |
| Robin_Watts | I shall just steal his van keys until he fixes it. | 16:15.46 |
| | The exchange is close enough that he can walk :) | 16:15.55 |
| kens | :-) | 16:16.08 |
| Robin_Watts | The latest mail from Len to Ray... sounds like a job for Memento memsqueezing maybe? | 16:57.05 |
| | Maybe not, as it's a 'fail' then 'pass' thing... | 16:57.46 |
| mvrhel_ | my connection is flaky today | 16:59.02 |
| Robin_Watts | Morning ray_laptop | 16:59.47 |
| | I was just commenting that memento memsqueezing might be an idea for the latest crash from Len? | 17:00.06 |
| ray_laptop | hi, Robin_Watts (et al.) | 17:00.20 |
| kens | Hi ray | 17:00.56 |
| ray_laptop | I hope everyone had a good flight back | 17:01.49 |
| kens | Yes, not bad at all, | 17:02.03 |
| chrisl | Hmm, mine was not good...... | 17:02.58 |
| Robin_Watts | Mine was fine. Maybe chrisl's bit of the plane had turbulence :) | 17:03.38 |
| ray_laptop | I had talked with Len about the allocation pattern -- it's totally expected when the request for a page buffer fails, and then a request for the clist buffer succeeds, but the 'clist_find_bits' with a bogus offset doesn't make sense | 17:04.05 |
| chrisl | Robin_Watts: Not turbulance. I foolishly agreed to swap seats after being asked by a rather pretty young lady. I ended up in a less than ideal seat - my own fault...... | 17:04.47 |
| ray_laptop | chrisl: the wings stayed on I hope | 17:04.56 |
| chrisl | ray_laptop: oh yes, thank goodness it was only an eight hour flight! | 17:05.22 |
| ray_laptop | chrisl: should have just offered her your seat, then stayed in it (let her have your lap) ;-) | 17:05.32 |
| mvrhel | hehe | 17:05.37 |
| chrisl | ray_laptop: that would have been considerably more comfortable.... for me, anyway! ;-) | 17:06.04 |
| mvrhel | ethan and I managed to make all our standby flights. we were the last ones on both of them | 17:06.10 |
| Robin_Watts | mvrhel: Nice. | 17:06.31 |
| ray_laptop | mvrhel: GREAT! much better than arriving at 1am with a sleepy kid | 17:06.43 |
| mvrhel | yes | 17:06.47 |
| | we were back at home by 9:30 (PST) | 17:06.58 |
| Robin_Watts | anyone here understand the 'shared' aspects of clip paths ? | 17:09.58 |
| mvrhel | I dont even understand the question | 17:10.21 |
| ray_laptop | Robin_Watts: path sharing is not something I've dug into. | 17:13.23 |
| Robin_Watts | In gs, paths have a 'local_segments' thing. That gets used when paths are allocated entirely on the stack. | 17:13.37 |
| | Sometimes with clip paths you can initialise them to 'share' the segments from another path. | 17:13.59 |
| mvrhel | ah ok | 17:14.03 |
| ray_laptop | Robin_Watts: sounds like something overly complex that Peter liked to do to save a smidgeon of memory | 17:14.37 |
| kens | I'm guessing its to do with gstates. | 17:15.08 |
| Robin_Watts | And the code for that currently barfs if the other path is stack allocated (presumably because the other path might fall out of scope and hence you'd be left with a dangling pointer) | 17:15.08 |
| kens | If you create a clip path then gsave, thenadd more clips, you can 'share' the earlier segments iwht the later | 17:15.35 |
| ray_laptop | Robin_Watts: not surprising that that would cause problems | 17:15.41 |
| Robin_Watts | BUT... the particular usage here, it'd be nested, so it'd be safe to do. | 17:15.47 |
| kens | Got to go, night all | 17:15.56 |
| Robin_Watts | I might have to add a new init function that just avoids the check. | 17:16.03 |
| ray_laptop | kens: g'nite | 17:16.04 |
| | Robin_Watts: I do know that the reference counting tracking (-Z^) bombs sometimes on paths, and there is a hack in rc_object_type_name to try and detect things on the stack | 17:19.35 |
| | it is properly documented with: ****** THIS IS A HACK. ****** | 17:20.08 |
| mvrhel | hehe | 17:20.41 |
| ray_laptop | don't look at that code on a full stomach ;-) | 17:20.51 |
| | pretty interesting that our new customer found some dead code in pdf_find_builtin_font (mupdf) | 17:41.35 |
| Robin_Watts | ray_laptop: I wonder if they are feeding it through some automated tool. | 17:42.13 |
| ray_laptop | does anybody recognize what tool they were using ? | 17:42.19 |
| Robin_Watts | No. | 17:42.26 |
| ray_laptop | the snippet in the email looked like it came from some automated tool | 17:42.50 |
| Robin_Watts | yeah. | 17:43.09 |
| ray_laptop | Robin_Watts: are you and tor8 going to leave it up to Marcos to respond? If so, we should ask marcosw to ask them what tool they use. | 17:44.08 |
| Robin_Watts | ray_laptop: I've responded. | 17:44.41 |
| | Have you not seen the response? I thought support was copied... | 17:44.54 |
| ray_laptop | I don't suppose we should count the time to remove dead code against their support hours ;-) | 17:44.55 |
| | Robin_Watts: I haven't seen your response yet | 17:45.23 |
| Robin_Watts | I sent it almost 2 hours ago. | 17:45.52 |
| | and support was copied. | 17:45.58 |
| ray_laptop | Robin_Watts: did you cc support ? | 17:46.01 |
| | OK -- probably just circling the globe | 17:46.22 |
| | I vaguely recall a fiction story from many years ago that had a scheme for storing data by making store and forward mail servers keep passing it around | 17:47.48 |
| | Robin_Watts: If I don't see it in a bit, I'll check my spam | 17:48.55 |
| Robin_Watts | I don't think I've seen it bounce back to me yet. | 17:50.01 |
| chrisl | mvrhel: I got your mail about Max's document, and I've got some initial reactions, but I'd like to think about it a bit more - when is the visit scheduled for? | 17:55.28 |
| mvrhel | we are going next week wed. | 18:01.13 |
| | chrisl: so take your time | 18:01.19 |
| | and thanks | 18:01.56 |
| | it is interesting to me to read it now compared to when I read it when I first started at artifex and knew a minimal amount about ghostscript | 18:02.42 |
| chrisl | mvrhel: No problem. It is difficult because the two architectures are *so* different, some of the stuff he talks about has no direct analogue between the two implementations. | 18:03.29 |
| Robin_Watts | I'm nosey, and this is piquing my interest... what document is this? | 18:03.57 |
| mvrhel | I suspected this. | 18:04.00 |
| | it is a document that is about 4 years old from a potential customer comparing gs with jaws | 18:04.31 |
| chrisl | I think a lot of the stuff in the document stems from Jaws being a design totally targeted at being an SDK, whilst Ghostscript is more of a "complete application" | 18:05.45 |
| mvrhel | yes I was wondering about this since he mentions how "this can be done in jaws without the source" | 18:06.18 |
| | a few times | 18:06.21 |
| chrisl | Yes, Jaws lets you "register" methods in the library to provide your own devices, device classes, Postscript devices (as is %device% type devices), and so on...... | 18:07.30 |
| mvrhel | well I appreciate your comments and also any education you can provide me about jaws | 18:08.07 |
| | need to step out for a bit | 18:08.16 |
| | bbiaw | 18:08.17 |
| Robin_Watts | ray_laptop: My mail just reached me | 18:11.03 |
| chrisl | mvrhel: (for when you get back) I'm trying to send you an e-mail with some relevant info, but gmail keeps timing out. If you actually end up getting several copies, that's why....... | 18:44.04 |
| ray_laptop | Robin_Watts: me too | 19:08.56 |
| Robin_Watts | mvrhel: ping me when you get back ? | 19:17.42 |
| mvrhel | Robin_Watts: I am back | 19:44.01 |
| Robin_Watts | Ah, cool. | 19:44.07 |
| | Got 5 mins for me? | 19:44.12 |
| mvrhel | for you, of course | 19:44.22 |
| Robin_Watts | http://bugs.ghostscript.com/show_bug.cgi?id=692526 | 19:44.26 |
| | :) | 19:44.27 |
| | What's happening is that we're getting an error returned from the fill_path routine. | 19:45.10 |
| | Superficially the code appears to catch and cope with the error. | 19:45.46 |
| mvrhel | is this some clist/transparency/pattern fun one | 19:45.58 |
| Robin_Watts | but a bit later on, pdf14_compose_group is called. | 19:45.59 |
| | it is. | 19:46.03 |
| | maskbuf != NULL, but masbug->transfer_fn == NULL | 19:46.23 |
| | So we get a SEGV. | 19:46.27 |
| mvrhel | oh | 19:46.41 |
| Robin_Watts | s/masbug/maskbuf/ | 19:46.42 |
| | Now, I have a fix that stops the error being generated, hence the SEGV goes away. | 19:47.00 |
| | BUT that leaves the problem (that the cleanup code is broken) in the code. | 19:47.35 |
| mvrhel | hmm I need to take a quick look at the transfer_fn | 19:48.28 |
| | hold on | 19:48.35 |
| Robin_Watts | I'm tempted to commit my fix, put a note in the bug about how to reproduce the problem and then pass it to you. Does that seem fair? | 19:48.44 |
| | holding. | 19:48.46 |
| mvrhel | Robin_Watts: that seems plenty fair | 19:49.02 |
| Robin_Watts | cool. We've stopped the regression with my fix, so it's not a huge priority - just don't want to drop it entirely. | 19:49.33 |
| mvrhel | Robin_Watts: ok. I will watch out for the bug that you send me and tackle it in the near future | 19:53.04 |
| Robin_Watts | cool. just writing the commit message now. | 19:53.16 |
| ray_laptop | marcosw: are you here ? | 19:56.10 |
| | does anyone know where the ATS files are ??? (I thought they were being uploaded by marcos, but can't find an email about where) | 19:57.00 |
| | I did see an email about the PS ATS from marcos on 9/5 but no mention of the PDF ATS | 19:59.45 |
| | oops. nm. I found the email from Miles on 4/22 -- we don't have the PDF ATS, only: PS (3/30/99), PXL (3/30/01), PXL (7/14/06), PCL5 (7/14/06), XPS (10/16/06), PCL5 (10/29/09), PXL (10/19/09) | 20:04.42 |
| ray_laptop | wonders if I can convert one of the PS ATS file to PDF to get a complex enough file. | 20:08.11 |
| Robin_Watts | ray_laptop: What sort of 'complexity' are you looking for ? | 20:08.54 |
| ray_laptop | cust 532 has a single page 32Mb PDF ATS single page file that fails -- it takes an hour to print if there is enough memory. | 20:10.04 |
| | I'm trying to find out whether or not it has transparency, but I think that it does not (because it was trying to use page mode) | 20:10.49 |
| Robin_Watts | This is the file that Len has been talking about? | 20:10.56 |
| ray_laptop | Robin_Watts: yes. | 20:11.02 |
| Robin_Watts | Did he not give us that file? | 20:13.16 |
| ray_laptop | Robin_Watts: no -- they are not sure that their QL license permits it. (file AIX361DC_X_3.pdf) | 20:14.05 |
| Robin_Watts | Let me try a memory squeeze run of j11.pdf | 20:14.40 |
| ray_laptop | The J11 file that I _do_ have doesn't crash for them -- it was sort of a red herring that caused me some work trying to get it to fail | 20:14.48 |
| Robin_Watts | AH. | 20:15.00 |
| | ray_laptop: Presumably they have unix boxen there? | 20:15.11 |
| ray_laptop | Robin_Watts: sure if you can, but they are running a 8.71 + a bunch of patches | 20:15.14 |
| Robin_Watts | oh, right, no memento. | 20:15.29 |
| ray_laptop | that too | 20:15.35 |
| Robin_Watts | I was going to suggest that we build a memento binary and send it to them for them to run the file with. | 20:15.56 |
| ray_laptop | I am going to build their code base for running locally and just try setting -K limits from a script until I get a failure. | 20:16.49 |
| | Robin_Watts: memento 'squeeze' doesn't work on windoze does it ? | 20:17.36 |
| Robin_Watts | ray_laptop: It does, but not as well. | 20:17.49 |
| | To do it fast, I use fork, and that's not available on windows. | 20:18.05 |
| ray_laptop | Robin_Watts: how "not as well" ? | 20:18.05 |
| | Robin_Watts: I see -- so not a lot different than repeated -K runs | 20:18.26 |
| | but a lot more finely grained | 20:18.39 |
| Robin_Watts | You can write a script to set an environment variable, then run the program, then reset it, then run it again etc. | 20:18.39 |
| | yeah. | 20:18.45 |
| | The linux build is a lot faster because only the 'post-failure' points are repeated. | 20:19.08 |
| ray_laptop | I'll try to get a build working on peeves, then see if I can add memento onto it. It will be good to reassure us (and me) that we are catching and handling alloc fails | 20:20.39 |
| | one more task to distract me. Sigh :-( | 20:21.04 |
| | Robin_Watts: have you done a squeeze run with the current code anytime recently (and opened bugs for places we don't cope) ? | 20:22.37 |
| Robin_Watts | ray_laptop: I have run files through it yes. | 20:23.10 |
| | But not *that* recently. | 20:23.20 |
| | And there are LOTS of places we don't cope (leaks rather than crashes in general) | 20:23.39 |
| | We don't have enough bug numbers to open 'em all :) | 20:23.53 |
| ray_laptop | Robin_Watts: leaks ? where we fail an allocation and keep going, or just exit leaving the 'heap_memory_free_all' to clean up ? | 20:32.29 |
| Robin_Watts | ray_laptop: Where the app shuts down without having cleared all the blocks. | 20:34.43 |
| ray_laptop | Robin_Watts: the crashes are of more concern, but I suppose the others are also an issue for an embedded environment that doesn't have its own cleanup method for a process/thread | 20:37.10 |
| | for cust 532, they have their own list of allocations and can clean up. | 20:37.53 |
| Robin_Watts | ray_laptop: The leaking at the end of the app is not the end of the world - most things tidy up at app shutdown. | 20:43.02 |
| | The problem is it can be symptomatic of leaking during the run - which is more of an issue. | 20:43.24 |
| ray_laptop | Robin_Watts: agreed that leaking during a run is problematic, but also easier to spot and not related to allocation failure. | 20:54.34 |
| | moving to a new locale. bbiab | 21:01.17 |
| bbhoss | Can anyone give me any hints on why this shows up? "GPL Ghostscript 8.71: Unrecoverable error, exit code 1" | 23:54.04 |
| | it appears to be a transient issue | 23:54.27 |
| | this is on ubuntu 10.04 if that helps | 23:54.36 |
| | Forward 1 day (to 2011/12/07)>>> | |
IRC Logs