| | <<<Back 1 day (to 2011/10/13) | 2011/10/14 |
| mvrhel2 | talk to you tomorrow Robin_Watts | 00:07.35 |
| kens | Slightly unfair, but.... | 09:20.15 |
| | http://i.imgur.com/76RkJ.png | 09:20.15 |
| chrisl_r61 | kens: that's not really surprising, given the relative public exposure of each. It would be nice to think the press would try to redress that balance but, back in reality...... | 09:37.57 |
| chrisl_r61 | reboots...... | 09:53.26 |
| Robin_Watts | buys another 4 gig of memory; potentially faster, but needs BIOS tweaks. If it works, I'll buy another 4Gig to go with it, and bin my existing 4Gig. If not, I'll run it at stock speed with the 4gig I've already got. | 10:25.19 |
| | To install windows 7, I was thinking about buying a new HD. | 10:28.59 |
| | Am now thinking I might buy an SSD for windows 7, and keep the same drive for bulk storage. | 10:29.25 |
| | https://www.facebook.com/photo.php?fbid=10150853573655652&set=a.10150366500670652.584754.816790651&type=1&theate | 10:40.57 |
| | kens: If you allocate something using gs_alloc_bytes, can the garbage collector throw it away? | 11:03.14 |
| tor8 | Robin_Watts: I have two SSD drives in my computer. best upgrade I ever did. | 11:07.47 |
| Robin_Watts | tor8: What size/speed ? | 11:08.04 |
| tor8 | 120gb and 160gb | 11:08.32 |
| Robin_Watts | I was thinking that a relatively small one (64Gig) would be more than enough to hold my OS + visual studio. | 11:08.52 |
| | Which make/model, do you remember? | 11:09.19 |
| tor8 | my C partition that holds windows and programs is 120gb, and it's about half full | 11:09.30 |
| | so I think 64gb will be a bit tight. 80gb is doable. | 11:09.42 |
| Robin_Watts | I was expecting to put most programs on the harddrive. | 11:09.58 |
| kens | Sorry, Miranda crashed | 11:10.27 |
| tor8 | I don't have a hard drive, I put my data on the second SSD | 11:10.29 |
| | you definitely want programs on the SSD | 11:10.37 |
| kens | Robin_Watts : if you alloc_bytes I think they are immune to garbage collection. But don't quote me ;-) | 11:10.45 |
| tor8 | Robin_Watts: one an intel, the other an ocz vertex | 11:11.08 |
| Robin_Watts | gs_alloc_bytes seems to be getting from the chunk memory manager. | 11:11.20 |
| tor8 | performance has been roughly the same on the benchmark program I used | 11:11.22 |
| | about 150-200mb/s read and write speeds | 11:11.36 |
| Robin_Watts | And that gets 'compacted' trashing the byres. | 11:11.39 |
| tor8 | Robin_Watts: you probably want your source files on the SSD, really speeds up compilation | 11:12.18 |
| kens | Robin_Watts : I think you stuill need to use immoveable memory | 11:12.52 |
| | Otherwise the pointer moves | 11:13.04 |
| | But Ray is probably a better person to ask | 11:13.17 |
| Robin_Watts | I marked the 16 bytes before the block (the header byres) with data breakpoints, and it next gets hit during a reclaim. | 11:13.20 |
| | kens: This isn't my code. This is preexisting planar code. | 11:13.35 |
| kens | Well I could be mistaken | 11:13.40 |
| Robin_Watts | No, I think you're right. | 11:13.51 |
| | Either this data should be in immovable memory (and the code is wrong), or it should be movable, and the GC is failing to detect that the chunk is in use. | 11:15.00 |
| kens | Umm, dunno ? | 11:15.14 |
| | Going to fetch me some lunch, back in a bit | 11:15.25 |
| Robin_Watts | Actually, this code is in ALL memory devices, so I don't believe it can be wrong - surely we'd have seen it before? | 11:21.54 |
| | Smeg. Crimson Kipper :( | 12:15.48 |
| kens | Smoke me one, I'll be back for breakfast | 12:16.19 |
| Robin_Watts | So, we open a pattern_accumulator device. That creates 'bits' and 'mask' memory buffer devices, which we then redirect all the drawing operations into. | 12:46.37 |
| kens | To create a tile ? | 12:47.09 |
| Robin_Watts | So when we've played back the pattern paint procedure, we have bits and mask being the images used for the tile. | 12:47.21 |
| | Yes. | 12:47.25 |
| | Then we close the pattern_accumulator device. | 12:47.40 |
| | How does 'bits' make it out from the pattern_accumulator into the tile ? | 12:48.04 |
| kens | pattern_finish moves it into the tile ? | 12:48.18 |
| Robin_Watts | s/tile/pattern cache/ | 12:48.24 |
| kens | I don't recall exactly | 12:48.27 |
| Robin_Watts | pattern_finish looks like a PDFwrite only thing. | 12:49.24 |
| kens | No thre's one for the regular patterns | 12:49.37 |
| | pdfwrite handles it as high level | 12:50.01 |
| | maybe its called something else... | 12:50.23 |
| | pattern_paint_finish ? | 12:52.26 |
| | calls pattern_cache_add_entry | 12:52.46 |
| | In zpcolor.c | 12:52.59 |
| Robin_Watts | brilliant! Thanks | 12:55.01 |
| kens | No problem | 12:55.06 |
| Robin_Watts | Right. The data in that buffer has been corrupted by the time we get there. | 13:03.47 |
| | It's corrupted by a gc, because that object in the chunk is not recognised as being in use. | 13:04.51 |
| | So something is failing to mark it. | 13:05.12 |
| | Lunchtime. | 13:05.28 |
| | Then pray for ray to arrive :) | 13:05.36 |
| | Morning mvrhel2 | 13:57.08 |
| kens | mvrhel2 is early today | 13:57.24 |
| mvrhel2 | good morning. | 13:57.40 |
| Robin_Watts | What's the -Z flag that lists operators ? | 13:58.11 |
| mvrhel2 | yes. early computer turn on, but off to eat and to help get kids out the door | 13:58.12 |
| Robin_Watts | Ah. This problem is triggered by a periodic gs, not an explicit one. | 14:13.05 |
| | Hence that may be why the problem moves around. | 14:13.24 |
| | If the periodic reclaim goes off *immediately* after a pattern_paint_prepare, we have problems. | 14:17.01 |
| kens | Ah, after the allocation but before it get sadded to the cache ? | 14:17.43 |
| Robin_Watts | Yes. | 14:18.06 |
| | It's pointed to by the device though. | 14:18.20 |
| kens | So sort of a race condition | 14:18.22 |
| mvrhel2 | oh wow | 14:18.32 |
| Robin_Watts | mvrhel2: To put it mildly :( | 14:18.51 |
| mvrhel2 | if its pointed to by the device, is that member variable enumerated for gc? | 14:19.42 |
| Robin_Watts | I'd guess not, because it's not marked :) | 14:20.01 |
| mvrhel2 | ok. well that would solve the problem | 14:20.14 |
| Robin_Watts | But I haven't managed to understand that bit of the code yet. | 14:20.18 |
| | I can't even tell if the device gets enumerated. | 14:20.28 |
| | (i.e. I can't tell if the problem is that the device isn't enumerated, or whether it is enumerated, but misses that member) | 14:21.17 |
| mvrhel2 | oh. I remember something about this | 14:21.19 |
| | bbiab | 14:21.24 |
| Robin_Watts | mvrhel2: You can't do that! That's like the Mathematician that always sent a telegram to one of his friends saying "I have found a really neat proof of fermats last theorem. Will discuss it when I return" before he flew anywhere. | 14:22.24 |
| | He figured that if the plane crashed, he'd get a footnote in history. | 14:22.40 |
| chrisl | Robin_Watts: could you try an experiment of adding the problem memory to gc explicitly? | 14:25.03 |
| Robin_Watts | chrisl: I'm hesitant to do anything that changes the binary. | 14:25.29 |
| chrisl | It's going to be hard to fix, then ;-) | 14:25.51 |
| Robin_Watts | I'm going to try to breakpoint the pattern accumulator enumeration code. | 14:26.08 |
| kens | But if the binary changesm the memory layout will and then the problem will go away... | 14:26.13 |
| Robin_Watts | to see if it's ever run. | 14:26.20 |
| funone | hi all | 14:29.23 |
| | is anyone here familiar with mupdf? | 14:29.33 |
| Robin_Watts | Too many macros in this enum stuff. | 14:29.34 |
| Robin_Watts | orders more pins from amazon | 14:29.41 |
| | funone: Yes... tor8, sebras and me. | 14:29.52 |
| funone | sorry to trouble you guys | 14:30.01 |
| Robin_Watts | np. | 14:30.07 |
| funone | but if i have a pdf with say, a url or email address | 14:30.12 |
| | I'm using android with mupdf | 14:30.18 |
| Robin_Watts | OK, the android port of mupdf is a very simple beast. | 14:30.33 |
| funone | I haven't been able to find out how to do say, when the user taps on a url | 14:30.35 |
| Robin_Watts | it doesn't currently support tapping on a URL. | 14:30.42 |
| funone | to launch the email program | 14:30.43 |
| Robin_Watts | but it shouldn't be hard to do. | 14:30.48 |
| funone | i can write all the detection code on android | 14:30.56 |
| | no issues for the touchscreen | 14:31.01 |
| | i just don't know what to call on mupdf | 14:31.08 |
| | to check whether the spot contains a url | 14:31.25 |
| Robin_Watts | Let me have a quick look. | 14:31.27 |
| kens | Hmm ray just updated a bug, but he's not on IRC.... | 14:32.41 |
| tor8 | funone: you can loop through the page->links list that's loaded with the page | 14:32.52 |
| | funone: see apps/pdfapp.c pdfapp_onmouse() | 14:33.15 |
| funone | hmm lemme check | 14:34.20 |
| Robin_Watts | tor8: beat me to it :) | 14:34.57 |
| funone | ah ic | 14:38.46 |
| | ok 2 more noobs questions | 14:38.52 |
| | i see the default res is 640 x 480 | 14:39.00 |
| | this resolution is fixed? | 14:39.17 |
| ray_laptop | Robin_Watts: et al. I saw questions about the planar 'bits' not getting traced by the GC. | 14:40.09 |
| Robin_Watts | ray_laptop: yes. | 14:40.28 |
| ray_laptop | Robin_Watts: IIRC, when it goes into planar mode, it creates N mem devices, one for each plane, right ? | 14:40.54 |
| Robin_Watts | funone: The android app reads the res from the device. | 14:41.12 |
| | ray_laptop: No. | 14:41.23 |
| ray_laptop | Oh, OK. | 14:41.35 |
| Robin_Watts | It creates 1, and then does magic with it. | 14:41.46 |
| ray_laptop | Robin_Watts: I see. | 14:41.54 |
| funone | robin: the android app side does, but in pdfapp.c | 14:43.32 |
| | oid pdfapp_init(pdfapp_t *app){memset(app, 0, sizeof(pdfapp_t));app->scrw = 640;app->scrh = 480;app->resolution = 72;} | 14:43.48 |
| | i don't see the mupdf resolution being changed anywhere | 14:44.05 |
| | The reason I'm asking is so i know whether I have to make adjustments for the x,y i send down from the app to onMouse | 14:44.35 |
| ray_laptop | Robin_Watts: I have to take my youngest to school, and you are off in mupdf-land, so we can discuss later (after I finish reviewing the logs) | 14:44.54 |
| Robin_Watts | ray_laptop: Thanks | 14:45.04 |
| | funone: I see. | 14:45.16 |
| | pdfapp.c changes srcw and srch internally. | 14:45.30 |
| | scrw and scrh, sorry. | 14:45.36 |
| funone | okie | 14:45.40 |
| | so i can assume it will always match the current screen resolution? | 14:45.55 |
| Robin_Watts | actually... ignore that. it doesn't. | 14:46.10 |
| | pdfapp_onmouse takes the x/y and transforms them as appropriate. | 14:46.54 |
| | see the first 6 lines or so. | 14:47.12 |
| | that converts from screen x/y to document space. | 14:47.21 |
| | and the link rectangles are stored in docspace. | 14:47.32 |
| funone | ah ic | 14:48.43 |
| | i also just noticed it calls winopenuri | 14:48.57 |
| Robin_Watts | to be clear; pdfapp.c isn't used in the android port. | 14:49.50 |
| funone | okie dokie | 14:52.02 |
| | thanks for the tips | 14:52.11 |
| | helps alot | 14:52.12 |
| Robin_Watts | OK, the pattern accumulator is never enumerated. | 15:01.31 |
| | That is to say, basic_enum_ptrs is never entered with pstype == st_device_pattern_accum | 15:08.44 |
| | ooh, I lie. I had my breakpoint foo wrong. | 15:11.55 |
| | ray_laptop: Still inching forwards... | 15:32.49 |
| ray_laptop | Robin_Watts: so, memory devices have an ENUM for their 'base' area (ordinarily the bits and line pointers that follow). See gdevmem.c line 33+ | 15:38.15 |
| Robin_Watts | ray_laptop: Right, planar devices use exactly the same thing. | 15:38.42 |
| | except they have n times as many line pointers. | 15:38.50 |
| ray_laptop | now this _usually_ lets the GC know about the raster area, BUT... | 15:38.50 |
| | the GC doesn't care about size | 15:39.10 |
| Robin_Watts | indeed. | 15:39.20 |
| ray_laptop | but line_ptrs are also enumerated | 15:39.33 |
| | unless 'foreign_line_pointers' is set | 15:39.52 |
| | the BUT... is that the mem device must still be pointed to by something that will be enumerated | 15:40.24 |
| Robin_Watts | right. which in this case should be the pattern accumulator device. | 15:41.35 |
| | But something strange is going on here... trying to suss it with the debugger, but it's hellish. | 15:42.03 |
| ray_laptop | I suspect that the mem device is no longer in the current gstate when the GC runs (after the pattern has been painted) | 15:42.23 |
| | Robin_Watts: the definition of the gx_device_pattern_accum _does_ enumerate the mask and bits devices (and other stuff) gxpcolor.h:285 | 15:46.28 |
| Robin_Watts | ray_laptop: Yes, like I say something strange is going on. | 15:46.56 |
| | Don't let me disturb you any more for now. | 15:47.06 |
| | but please stay on irc! :) | 15:47.10 |
| ray_laptop | Robin_Watts: I'm not sure where the pattern_cache gets enumerated ... | 15:48.24 |
| | Robin_Watts: it _does_ look like the pattern_cache_add_entry is done _before_ the padev is closed, and before the gs_state_free_chain, so it still should be traced | 15:50.15 |
| Robin_Watts | ray_laptop: Yeah. Please don't spend any more time on this. | 15:50.41 |
| | I'm trying to trace it in another window. | 15:50.54 |
| | When I have more concrete stuff (or more questions) I'll ask. | 15:51.11 |
| | If this is a red herring, better that it wastes my time rather than both of us. | 15:51.39 |
| | Oh god. I bet I know what it is. | 15:53.35 |
| ray_laptop | Robin_Watts: ahh. the 'tiles' linked list is traced by the pattern_cache and the tile GC struct def traces tbits.data, tmask.data, cdev, and ttrans | 15:53.38 |
| Robin_Watts | When the VM compacts it moves the bitmap + line pointers, right? | 15:54.18 |
| | But I bet it doesn't know about planar line pointers. | 15:54.28 |
| | hence only the first mdev->height get rewritten. | 15:54.38 |
| ray_laptop | Robin_Watts: I'm just doing some looking to help set up (in our minds) what is _supposed_ to be happening | 15:54.39 |
| Robin_Watts | so the remaining 3*mdev->height pointers stay pointing at the old address. | 15:55.07 |
| ray_laptop | Robin_Watts: it knows about 'base' and 'line_pointers' | 15:55.09 |
| Robin_Watts | That's *exactly* what I'm seeing. | 15:55.13 |
| | Yes, but it thinks that there are only mdev->height line_ptrs to rewrite, right? | 15:55.30 |
| | Yeah, line 51 of gdevmem.c | 15:56.34 |
| ray_laptop | Robin_Watts: Oh, when it moves the 'base' it adjust the line_pointers, but just not enough of them. I haven't seen where the line_pointers are all RELOC'ed | 15:56.38 |
| | Robin_Watts: right -- that just uses 'height' | 15:57.07 |
| | Robin_Watts: looks like that's it. | 15:59.10 |
| | Robin_Watts: if the gdev_mem_open_scan_lines used gs_alloc_bytes_immovable that would also resolve it, right ? | 16:01.35 |
| Robin_Watts | Possibly. | 16:01.51 |
| | but that would mean bitmaps became uncompactable (and potentially ungcable) | 16:02.13 |
| ray_laptop | If the pattern is pretty large, then it will go in its own chunk and never get moved, but for small patterns | 16:02.18 |
| | Robin_Watts: immovable is still GC-able and traced | 16:02.33 |
| ray_laptop | thinks | 16:03.04 |
| | Robin_Watts: see: doc/Develop.htm#Movability | 16:04.12 |
| Robin_Watts | S'OK. It's a trivial fix now I've found it. | 16:04.26 |
| | Testing now. | 16:04.28 |
| ray_laptop | Robin_Watts: you fixed the calculation for how many line pointers to reloc to include the num_planes ? | 16:05.12 |
| Robin_Watts | yes. | 16:05.18 |
| ray_laptop | Robin_Watts: sounds fine. | 16:05.31 |
| Robin_Watts | Bingo. seems to have worked. | 16:05.35 |
| | Only took 2 days :( | 16:05.40 |
| | At least the bug wasn't in my code. | 16:06.06 |
| | (was in Peters original stuff) | 16:06.19 |
| | ray_laptop: Thanks for your help. | 16:09.13 |
| henrys | marcosw_ around? if so we could have the bug meeting. | 16:10.21 |
| Robin_Watts | ray_laptop: Can you tell me what the RELOC_PTR(gz_device_memory, line_ptrs); line does? | 16:12.09 |
| | line 60ish. | 16:12.17 |
| | Oh, ignore me, I see. | 16:12.49 |
| ray_laptop | Robin_Watts: np. Sometimes it just helps to 'talk things out' | 16:22.16 |
| mvrhel2 | cool. so you have it figured out then | 16:35.59 |
| Robin_Watts | mvrhel2: Yeah, fixed and committed. | 16:39.41 |
| | 5 second fix. 2 days to figure out what was going wrong :( | 16:39.55 |
| marcosw_ | henrys and ray_laptop: we can do the support meeting now, if both of you are available. | 16:43.35 |
| ray_laptop | mvrhel2: I closed that WTS bug as WONTFIX | 16:43.46 |
| henrys | marcosw_:okay | 16:44.11 |
| marcosw_ | anyone have a preferred starting point? | 16:44.26 |
| henrys | 692573 | 16:45.32 |
| marcosw_ | seems correctly assigned | 16:46.16 |
| mvrhel2 | ray_laptop: thanks! | 16:46.21 |
| kens | Haven't looked at it yet. Its next on my list when I'm sure teh text rendering stuff is done. | 16:46.28 |
| henrys | 692574 can go to alex if you are driving. | 16:46.52 |
| marcosw_ | okay, will reassign to alex | 16:47.05 |
| | 275 is mupdf and assigned to tor. | 16:48.08 |
| henrys | 577 to chrisl | 16:48.46 |
| marcosw_ | i think 277 should go to chrisl | 16:48.47 |
| henrys | 577 you mean? | 16:49.06 |
| marcosw_ | yeah. | 16:49.47 |
| | 579 was assigned to chrisl by chrisl, so that seems okay. | 16:50.04 |
| Robin_Watts | 580 should be me, probably, cos it's a VS solution thing. | 16:50.20 |
| henrys | robin_watts might be cc'd on 692580 | 16:50.27 |
| marcosw_ | I agree with Robin_Watts, let's assign it to him (we can cc chrisl) | 16:50.55 |
| henrys | yeah he needs an easy one! | 16:51.21 |
| marcosw_ | 581 can stay with chrisl | 16:51.42 |
| | 582 is a mudpf patch | 16:52.02 |
| | 586 is mupdf assigned to tor | 16:53.19 |
| henrys | I'm up to 589 which is good with kens | 16:53.40 |
| ray_laptop | 589 has what looks like a support tag on it (#1522) I wonder if this is from company using our stuff | 16:54.27 |
| | and looking for free support | 16:54.36 |
| marcosw_ | don't we provide free support to companies using the gpl version of Ghostscript? | 16:56.46 |
| ray_laptop | I think we may have to close 590 as WORKSFORME Alex and Chris have spent enough time already (IMHO). BTW, I thought bugs were to stay with Marcos until they were replicated | 16:56.47 |
| henrys | we should write "please post the original bug (#1522) report in entirety" | 16:56.53 |
| ray_laptop | marcosw_: yes, but we would like them to sign up for a support contract. If they are big enough to have a support staff, they can send some $$$ our way | 16:57.45 |
| chrisl | ray_laptop: I did manage to reproduce 590, I haven't had time to write it up yet - the description is poor...... | 16:58.00 |
| ray_laptop | henrys: I like that idea | 16:58.01 |
| henrys | ray_laptop:yes I'm going to write something like that. | 16:58.21 |
| ray_laptop | chrisl: OK. But still we've had you AND Alex trying to reproduce this, rather than just Marcos (when he gets around to it). | 16:58.59 |
| chrisl | ray_laptop: I thought that only applied to commercial customer reports | 16:59.27 |
| marcosw_ | why pay for the cow when the milk is free? I know, we can have the GPL release of Ghostcript trail the commercial release by a year, that would encourage companies to pay for it! | 16:59.28 |
| henrys | it was a component assignment right? So it's up to engineers to reassign to marcos | 16:59.46 |
| | ray_laptop:I'll bring it up at the tuesday meeting but we've discussed it before. | 17:00.29 |
| ray_laptop | marcosw_: we offer priority on bug fixes for customers. That's the advantage to them. At the very least we should make sure free user support doesn't distract us | 17:01.19 |
| marcosw_ | if it's any consolation I can't get 590 to fail. | 17:01.27 |
| henrys | so 590 goes to marcosw_? | 17:01.29 |
| chrisl | marcosw_: for 590, you have to convert to PDF using pdfwrite, then run the resulting PDF - that failed for me with 9.04 | 17:02.10 |
| ray_laptop | chrisl: when will you be able to post the info on replicating 590 ? Does this look like it stays with Alex ? | 17:02.17 |
| marcosw_ | ray_laptop: 692589 is P4, which means that it is lower priority than bugs reported by customers. | 17:02.39 |
| ray_laptop | marcosw_: right. So if it is a company, they should know they have an option for P2 level support. | 17:03.17 |
| henrys | marcosw_:can you bisect 591 alexcher has a full plate. | 17:03.39 |
| ray_laptop | chrisl: that's what the guy said in the original description wasn't it? | 17:04.00 |
| chrisl | ray_laptop: yes, sort of, but the title is less than helpful, I feel | 17:04.26 |
| marcosw_ | ray_laptop: maybe we should mention that on our website? Individually contacting everyone who reports a bug to let them know that we would fix their issue more quickly if they paid us money seems like a lot of work. | 17:04.39 |
| ray_laptop | marcosw_: good idea ! | 17:04.54 |
| marcosw_ | I'll bisect 591, I reassigned it to me. | 17:05.24 |
| ray_laptop | marcosw_: put it on the bugs web site | 17:05.31 |
| henrys | and tim waugh should be told we'll take a list of coverity problems - a bug per coverity issue is going to be a problem. | 17:06.07 |
| marcosw_ | 562 is okay as is. | 17:06.41 |
| ray_laptop | 592 is really an enhancement request, isn't it? | 17:07.05 |
| henrys | 94-99 | 17:07.07 |
| marcosw_ | ray_laptop: I was thinking the same thing, but tor can decide how to classify it. | 17:07.33 |
| henrys | 601 should be marcosw_ for reproduction. | 17:08.53 |
| marcosw_ | henrys: 601? | 17:09.12 |
| ray_laptop | I don't see 601 | 17:09.24 |
| henrys | woops 600 | 17:09.27 |
| | I'll contact tim waugh if you want. | 17:09.52 |
| marcosw_ | henrys: yes, thanks. What shall we do about the already opened bugs? | 17:10.20 |
| henrys | I was going to ask him to close them. | 17:10.39 |
| | 598 looks egregious though | 17:11.13 |
| ray_laptop | I requested that Leonid attach his device driver code for get and put params. He probably is doing something wrong. | 17:11.22 |
| Robin_Watts | If he's providing patches, then surely one patch per bug is better ? | 17:11.52 |
| henrys | Robin_Watts:agreed I'll leave him alone. | 17:13.24 |
| | marcosw_:do you want to take on integrating the patches that look obviously right? | 17:14.21 |
| | and reassign other to owners? | 17:14.35 |
| Robin_Watts | I suspect that one is from refactored code. | 17:14.42 |
| henrys | ray_laptop, marcosw_:are we done? | 17:15.16 |
| marcosw_ | henrys: sure. | 17:15.59 |
| henrys | there is still a bit of a list assigned to support but many are tim's. | 17:16.45 |
| marcosw_ | henrys: I was looking at those. | 17:16.58 |
| henrys | yeah 692470 swamp | 17:18.21 |
| chrisl | I have to go - have a weekend everyone...... | 17:18.23 |
| | good that is | 17:18.31 |
| ray_laptop | btw, are we confirmed for the dates for the next staff meeting 12/3-12/4 ? | 17:22.44 |
| henrys | ray_laptop:no I've asked miles just a couple days ago to get the email going - I know he's busy with other stuff. | 17:23.49 |
| | marcosw_:let's fool with the remaining support bugs next time. | 17:24.11 |
| Robin_Watts | ray_laptop: Those were the dates that were most recently suggested though. | 17:24.18 |
| | (at least within my hearing range) | 17:24.37 |
| ray_laptop | I just called Miles. He said the dates are solid -- just not the location | 17:24.55 |
| henrys | is leaving the coffee shop and will be offline for a bit. | 17:26.42 |
| marcosw_ | henrys: sounds reasonable. | 17:27.42 |
| Robin_Watts | mvrhel2: You here? | 17:35.11 |
| mvrhel2 | I am. chugging away at screen creation. | 17:36.28 |
| Robin_Watts | Can I interrupt briefly? | 17:36.38 |
| mvrhel2 | sure | 17:36.42 |
| Robin_Watts | In gxht.c line658 | 17:36.54 |
| mvrhel2 | hold on let me get there | 17:37.09 |
| | don't even have the project open | 17:37.20 |
| Robin_Watts | gxcht.c, sorry. | 17:37.37 |
| mvrhel2 | ok. I am there. but fearing a major context switch | 17:38.42 |
| Robin_Watts | If I'm reading this correctly, that whole 'if' is an optimisation, right ? | 17:39.02 |
| | i.e. I should be able to disable it, and see no ill effects (other than the code running a bit slower) | 17:39.23 |
| mvrhel2 | that seems correct | 17:40.24 |
| | it is certainly a special case that the general fill should handle | 17:40.53 |
| Robin_Watts | If I disable it, I get differences in the pamcmyk4 output. | 17:41.17 |
| | In exactly the same place that I get differences between it and plank. | 17:41.32 |
| | I suspect that phase goes wrong in there somewhere. | 17:41.48 |
| mvrhel2 | it sounds like it | 17:41.55 |
| Robin_Watts | ok, I'll keeo digging. Just wanted a sanity check before I lose another 2 days to a snark hunt. | 17:42.23 |
| | Thanks. | 17:42.28 |
| mvrhel2 | It may help to make a special example with a known fill location (and phase) | 17:43.36 |
| | I had to do that when I was working to get the fast thresholding in phase with the old tile fill approach | 17:43.59 |
| Robin_Watts | Yes. Using the gs postscript extensions. | 17:44.05 |
| mvrhel2 | ok. back to adding dot shape. almost there | 17:44.41 |
| Robin_Watts | Even disabling that optimisation is not enough to get pamcmyk4 to agree between banded and non-banded modes. | 17:50.46 |
| mvrhel2 | darn | 18:02.14 |
| Robin_Watts | But disabling the strip_copy_rop is. So there is something that's going wrong in that call. | 18:02.43 |
| kens | Goodnight all | 18:16.34 |
| ray_laptop | henrys: Good job identifying that jritmeijer is probabaly the one at muhimbi. Wow! $999 price tag ! | 18:27.57 |
| henrys | I'm glad you noticed the tracking number I missed it entirely. | 18:29.35 |
| mvrhel2 | lunch time. bbiab | 18:30.58 |
| Robin_Watts | http://blog.muhimbi.com/2011/09/pdfa-support-in-muhimbi-pdf-converter.html | 18:36.25 |
| | Yeah, "Download the GPL release of ghostscript"... | 18:36.35 |
| mvrhel2 | are these guys a customer? | 18:44.31 |
| | I see that the R of K & R just recently died | 18:48.45 |
| arthurf | henrys: I was impressed with the detective work around 589 - in fact I laughed out loud here in my cube. That was pretty cool. Liked comment 7. | 18:50.41 |
| ray_laptop | Robin_Watts: thanks for the link -- one of should send that to Miles. It looks like they don't fit our interpretation of GPL use of Ghostscript in that their non-GPL product seamlessly uses Ghostscript to do the work | 18:51.38 |
| | altough they try because the have the end user download GS directly, so they don't distribute it. (according to that blog). Still an opportunity for a support contract. | 18:53.54 |
| | or a chance for them to improve their product so that the user doesn't have to do a separate install. | 18:55.08 |
| Robin_Watts | mvrhel2: exit(EXIT_FAILURE); :( | 18:58.42 |
| henrys | we have this fox in the neighborhood that acts like a dog - he's napping in my neighbors yard right now. | 21:37.21 |
| mvrhel2 | wow | 21:49.18 |
| | in the daylight? | 21:49.22 |
| henrys | yes he let's sabrina and I get real close to him too. haven't petted him yet ;-) | 21:50.21 |
| mvrhel2 | probably best :) | 21:50.56 |
| | Forward 1 day (to 2011/10/15)>>> | |
IRC Logs
