| | <<<Back 1 day (to 2011/08/25) | 2011/08/26 |
| mvrhel2 | rats: one of those should have been cluster untested or they should have been squashed together | 00:03.11 |
| | sorry about the cluster run | 00:03.18 |
| Robin_Watts | signed up to the Hyatt Gold Passport thing on holiday (basically a reward card). | 09:22.44 |
| | Anyone know if we can we use that on artifex business trips? | 09:23.06 |
| kens | No idea, have to ask Miles | 09:23.19 |
| Robin_Watts | (I mean if Miles is getting the credits on his card, then clearly he's paying so that only seems fair, but if they are just going begging...) | 09:23.37 |
| kens | Like I said, have to ask Miles. But I would think he gets points or something, he books enough hotels | 09:24.07 |
| Robin_Watts | kens: It may be like air miles; it's not the person that books, or pays that matters, but the person who flies. | 09:25.00 |
| kens | Still no idea :-) | 09:25.24 |
| | Off out for a couple of hours, back later. | 09:44.49 |
| Robin_Watts | What are the permissible sizes of gx_color_value ? | 13:56.03 |
| | 8 or 16bits ? | 13:56.15 |
| kens | No idea. | 13:56.19 |
| Robin_Watts | Looks like it's hardwired to 16. | 13:57.02 |
| chrisl | kens: is your phone free? And is this an okay time to call? | 14:19.47 |
| kens | Ah, I htink so, yes. | 14:20.02 |
| | one second, I'll check phone | 14:20.42 |
| | Hi marcosw_ | 16:14.18 |
| | In Europe now ? | 16:14.24 |
| marcosw_ | hello | 16:14.30 |
| | yes, in Belgium. | 16:14.35 |
| Robin_Watts | doesn't know the flemish for Hello. | 16:14.39 |
| kens | Ah, good place for beer :-) | 16:14.44 |
| | Robin_Watts : could use French depending | 16:15.00 |
| marcosw_ | strange weather, it was 33 and sunny in Frankfurt and it's 16 and raining here. | 16:15.36 |
| kens | Anyway, I'm off ro the night. Have a good holiday Marcos | 16:15.40 |
| marcosw_ | night | 16:15.44 |
| | thx | 16:15.46 |
| Robin_Watts | It's Spa. It rains in Spa. | 16:16.08 |
| marcosw_ | good thing I booked a seat under cover. | 16:18.23 |
| henrys | off to a late start this morning... gave blood and went back to sleep for a while. | 16:18.24 |
| | kens, ray_laptop:after looking at the code for the memory leak now I'm really confused it looks like delete_instance pulls the plug on the entire allocator. So we must be allocating outside (foreign memory) | 16:21.05 |
| | I am not trying to interfere with fixing the bug but I'm working on something related. | 16:22.06 |
| mvrhel2 | good morning | 16:29.56 |
| | Robin_Watts, henrys: who is going to lead the way on comparing the pkmraw and plank device output? | 16:30.51 |
| henrys | crickets | 16:33.03 |
| | so are we going to rename plank to pkmraw and see what happens upon a push? | 16:33.45 |
| | I'll do some local tests today and Robin_Watts and I will sort it you don't have to worry about it. Do you have some way now to test the threshold code? | 16:37.04 |
| mvrhel2 | henrys: that is what I was thinking | 16:37.47 |
| | henrys: other than manual comparison on my machine no not really | 16:38.21 |
| | is the plank device tested now? | 16:38.30 |
| | i.e. just run? | 16:38.36 |
| | If so, I can do a push with the threshold code on to check for segvs | 16:38.50 |
| henrys | marcosw_:did marcosw_ add the device yet | 16:39.14 |
| | ? | 16:39.15 |
| mvrhel2 | that is my question | 16:39.25 |
| | to you :) | 16:39.29 |
| marcosw_ | mvrhel2: not yet, the was some question if the performance of the cluster would suffer, so I'm going to run a local test today and see what happens. | 16:39.31 |
| mvrhel2 | oh hi marcosw | 16:39.45 |
| marcosw_ | good morning (or evening) | 16:40.02 |
| Robin_Watts | back, sorry. Dogs have just arrived home again. | 16:40.41 |
| mvrhel2 | one idea we had was to do a push where the plank device and pkmraw device names were swapped | 16:40.57 |
| | that would probably do the test that I want | 16:41.23 |
| Robin_Watts | mvrhel2: That wouldn't work trivially, as I bet the files produced differ a bit. | 16:41.34 |
| mvrhel2 | why would they differ? | 16:41.48 |
| Robin_Watts | There is a comment field in pXm files. | 16:41.51 |
| mvrhel2 | oh | 16:41.55 |
| henrys | yes that would produce all diffs | 16:41.55 |
| Robin_Watts | and I'm not sure it's the same. | 16:41.57 |
| mvrhel2 | ok | 16:42.03 |
| Robin_Watts | We could tweak it to be the same I suspect. | 16:42.05 |
| ray_laptop | henrys: sorry, I was not watching. What 'memory leak' are you looking at ? | 16:42.11 |
| henrys | the planar rendering will be slightly different than the chunky also right? | 16:42.27 |
| Robin_Watts | but marcosw_ already tweaks it a bit in cluster runs. | 16:42.30 |
| mvrhel2 | I dont see why the rendering would be different | 16:42.38 |
| Robin_Watts | henrys: Isn't that the point of the test ? :) | 16:42.40 |
| marcosw_ | plank files and pkmraw files different in other ways, the header is different other than just the commnet. | 16:42.49 |
| Robin_Watts | marcosw_: How so? | 16:43.06 |
| henrys | ray_laptop:692372 | 16:43.15 |
| mvrhel2 | If both use the tiling HT code, then the rendering should be the same | 16:43.26 |
| marcosw_ | plank files are PAM files, pkmraw files are PPM files. | 16:43.35 |
| henrys | I was expecting pixel shifts, let's check it out on a few single files before a clusterpush. | 16:44.46 |
| Robin_Watts | marcosw_: Really? | 16:45.02 |
| ray_laptop | henrys: that bug is concerned with handle leakage. The memory wasn't being leaked (the graphics/imager states were being freed by the alloc_restore_all of imain.c | 16:45.05 |
| marcosw_ | test.plank: Netpbm PAM image file | 16:45.18 |
| ray_laptop | henrys: the problem was that when the chunks were freed, nothing was done to close the semaphores | 16:45.47 |
| Robin_Watts | I only used pam because I thought I couldn't use ppm. | 16:45.49 |
| ray_laptop | ppm is only 3 components. the pkmraw 'collapses' the K channel into the RGB | 16:46.33 |
| Robin_Watts | Oh, right. | 16:46.46 |
| | Then clearly we can't compare to that :( | 16:46.57 |
| henrys | ray_laptop:that I understand I thought you and kens were saying yesterday there was a memory leak after delete_instance which I thought odd. | 16:47.14 |
| marcosw_ | That's why I was surprised that bmpcmp worked on CMYK files, since we haven't had any of those previously. | 16:47.25 |
| ray_laptop | not without converting the PAM to PPM using the same method (which isn't too hard) | 16:47.31 |
| Robin_Watts | Is there a more direct equivlanet ? | 16:47.32 |
| henrys | have a meeting/phone call be back in 1/2 hour | 16:48.37 |
| ray_laptop | the 'bitcmyk' is the same except there is no header | 16:48.39 |
| marcosw_ | BTW, are plank files 32 or 4 bit? | 16:49.33 |
| Robin_Watts | 4 bit. | 16:49.39 |
| | planc = 32 | 16:49.45 |
| ray_laptop | that's not totally intuitive | 16:50.09 |
| marcosw_ | the pamcmyk4 and pamcmyk32 names were better chosen :-) | 16:50.34 |
| Robin_Watts | Yes. | 16:50.46 |
| ray_laptop | there are pamckyk4 and pamcmyk32 devices | 16:50.46 |
| Robin_Watts | Then those are the ones we should compare against. | 16:51.00 |
| mvrhel2 | yes | 16:51.08 |
| ray_laptop | so pamcymk4 should be comparable to plank and pamcmyk32 vs. planc | 16:51.24 |
| marcosw_ | (assuming they are 4 and 32 bit, respectively, if not they aren't at all well chosen) | 16:51.29 |
| mvrhel2 | :) | 16:51.36 |
| ray_laptop | is .5 seconds behind :-( | 16:51.38 |
| Robin_Watts | I think I added the pamcmyk4 device for exactly this reason, now I come to think of it. | 16:52.43 |
| mvrhel2 | the fog is lifted... | 16:54.15 |
| ray_laptop | Robin_Watts: at least you named it using the convention I had in the pamcmyk32 ;-) | 16:54.16 |
| marcosw_ | to summarize: I should run all the regression files through plank and look at the timings and also compare the bitmaps from plank to pamcmyk4 | 16:55.43 |
| mvrhel2 | no timings yet | 16:55.56 |
| ray_laptop | henrys: I am not aware of a memory leak after delete_instance | 16:55.58 |
| mvrhel2 | marcosw_: first we want to make sure that plank vs pamcmyk4 is equivalent bitmaps with the same tiling HT code | 16:56.32 |
| marcosw_ | the timings are supposed to be used to eliminate files from cluster testing that would hurt the performance of the cluster | 16:56.33 |
| mvrhel2 | once we find out we are OK there, then we will turn on the fast stuff | 16:56.47 |
| marcosw_ | I don't understand the "same tiling HT code" | 16:57.02 |
| mvrhel2 | and look at diffs and timing | 16:57.02 |
| | HT = halftoning | 16:57.41 |
| | by default both devices will use the our current halftoning method | 16:58.04 |
| | with a small change in the code, the plank device will use a faster (or should be faster) thresholding for images | 16:58.29 |
| | we are trying to first make sure that there are no issues with the planar device rendering | 16:59.15 |
| | before looking at halftone changes | 16:59.22 |
| Robin_Watts | mvrhel2: Did you back out the "force clist for patterns if planar" thing ? | 17:00.00 |
| mvrhel2 | yes I think so. let me double check | 17:00.12 |
| | yes I did | 17:00.54 |
| Robin_Watts | cool. | 17:01.00 |
| marcosw_ | I'm going to take a shower and go to dinner, will be back in an hour or so. | 17:02.10 |
| mvrhel2 | oops | 17:03.08 |
| | no Robin_Watts: I did not | 17:03.20 |
| | let me do that now | 17:03.23 |
| | darn | 17:03.27 |
| Robin_Watts | mvrhel2: No harm, no foul. | 17:03.46 |
| mvrhel2 | ok. now it is in there | 17:06.55 |
| Robin_Watts | mvrhel2: http://ghostscript.com/~robin/gxcvalue.h | 17:12.14 |
| marcosw_ | okay, will start plank vs. pamcmyk4 test now (using 7fee00). | 17:13.03 |
| Robin_Watts | mvrhel2: I've changed gx_color_value_to_byte and added the COLROUND and COLDUP macros. | 17:13.54 |
| henrys | back | 17:14.15 |
| | marcosw_:so you will be fairly available? should kens and I take over customer responses? If so when? | 17:15.44 |
| mvrhel2 | Robin_Watts: looks good | 17:16.24 |
| Robin_Watts | mvrhel2: COLDUP not too evil? :) | 17:16.43 |
| mvrhel2 | hehe well that area did make my eyes water | 17:17.00 |
| ray_laptop | henrys: I assume you saw the response from Freek -- I got the email to him just in time for his vacation to start :-/ | 17:17.18 |
| Robin_Watts | Was the best I could come up with that would compile nicely when FROM is constant. | 17:17.44 |
| mvrhel2 | I understand | 17:17.59 |
| henrys | ray_laptop:yeah I saw that, sigh ... | 17:18.31 |
| mvrhel2 | well at least it got there before he left | 17:18.46 |
| ray_laptop | right, and the other folks at the company (such as Bill B) got the email as well in case someone else will dive in. | 17:20.46 |
| | that smiley I didn't expect a B followed by a ) makes B) | 17:21.20 |
| marcosw_ | henrys: kens and you should take over support duties yesterday and today if I'm not online (which I clearly am, so no need). | 17:22.59 |
| ray_laptop | I'll give Bill a call (they're local to me) to see if he needs any help (I think he is the local manager) | 17:23.00 |
| henrys | ray_laptop:kens is working on pairing down alexchers bug list I think yours is the last one that seems a bit long ... but maybe they are just long standing open issues, do you want to handoff some of your problems? | 17:23.58 |
| | customer bug list (bug aging) | 17:24.13 |
| ray_laptop | henrys: I'll have a look... | 17:25.20 |
| | henrys: mvrhel: I was thinking that if cust 711 (Freek, etc.) have a problem with storing many linearized stochastic arrays that are all based on the same initial .pat data, we _could_ do the linearization on the fly (the linearization .dat data is small), but I guess we can wait for them to squawk | 17:30.07 |
| henrys | well I think the answer there is we shouldn't go above the rom space he reported for 8.71 he seemed to be happy with that and unhappy with anything larger. Is that the case? | 17:31.56 |
| | I can't imagine it would be. | 17:32.16 |
| ray_laptop | looks like henry is having connection problems. Going for coffee. bbiab. | 18:24.14 |
| rayjj | henrys: how much memory the customer will add for the halftone threshold arrays depends on how many and what width x height. | 18:56.40 |
| henrys | yes but I thought it could be reasonably kept under 1.5M which is what we have to play with. | 18:58.16 |
| rayjj | henrys: stochastic thresholds don't compress very well (as you might expect), but a 128x128 array is only about 36k | 18:59.03 |
| | and since it is mostly hex, it compresses to about 17k iirc | 18:59.35 |
| henrys | that why I thought the reduction we made to rom would more than compensate for anything you could add halftone wise. | 19:00.11 |
| rayjj | henrys: I agree (as long as they stay 'sane' with their halftones) | 19:00.48 |
| henrys | chrisl:are you still about? | 19:05.10 |
| marcosw_ | had forgotten how could food is in the french speaking bits of the planet | 19:46.08 |
| | s/could/good/ | 19:46.18 |
| chrisl | henrys: I'm not really (I forgot to change my status) but if there's something you need? | 19:55.59 |
| chrisl | moving to other computer..... | 20:02.06 |
| rayjj | marcosw_: I've been to Quebec, and am not sure that I entirely agree. I also don't particularly care for Haitian cuisine | 20:04.47 |
| | of course those from France wouldn't classify those as french speaking ;-) | 20:05.33 |
| marcosw_ | I've only spent a couple of days in Quebec and don't remember the food, which I guess means it wasn't particularly good or bad. | 20:06.52 |
| rayjj | hmm... Well, I'm not sure how this ran on Windows. The gstate ref counting of some things is honked up (people pointing to things without bumping the rc) | 20:06.53 |
| | tired of ddd -- going back to Windows to see if I can track it down. (ddd and xxgdb leave a lot to be desired, but ddd is better) | 20:08.17 |
| | insight is quite a bit nicer than ddd. If anyone knows of a better one, let me know | 20:21.08 |
| chrisl_r61 | rayjj: insight has its own problems - it's not a gui on gdb, it uses a gdb fork, dating back to gdb 6.8 (I think). It's also not widely available. Personally, I think ddd doesn't do much, but it does what it does quite well, and gives you access to the gdb command line for more esoteric stuff | 20:23.24 |
| rayjj | the variable and structure display is MUCH nicer than the 'data' mess with ddd (IMHO) | 20:24.42 |
| | back to laptop for now... | 20:25.27 |
| chrisl_r61 | true, that isn't great. My problem with insight is that, unless they update their gdb, it'll never have macro expansion, and I find that decidedly useful working on Ghostscript! | 20:26.03 |
| rayjj | chrisl_the insight version I just installed on peeves says GNU gdb 6.7.1 | 20:28.27 |
| | chrisl_(I ran insight --version) | 20:28.45 |
| | the gdb I have is GNU gdb (GDB) 7.0-ubuntu | 20:29.37 |
| | so it does look like it's 2+ years out of date | 20:30.01 |
| chrisl_r61 | It's always the risk when you fork a project, especially a big one like gdb | 20:30.26 |
| | Basically, I think I'm saying: there's a gap in the market for a nice and functional gdb gui | 20:32.39 |
| | rayjj: you could look at nemiver - it's a gtk based gdb gui. The only thing I really didn't like, when I tried it, was that there was no access to the gdb command line, and gdb's capabilities will always be way ahead of a separately developed gui. | 20:37.25 |
| rayjj | Insight looks quite nice, but I guess they just dropped it. The last news was July 2009. The download page claims "Insight releases typically coincide with GDB releases," but looks like that was optimisitc | 20:37.32 |
| chrisl_r61 | I can't get my head around why the insight guys forked gdb, given that the gui element is written in tcl/tk, it seems a pointless complication to maintain a gdb source base, too. | 20:39.01 |
| henrys | chrisl_r61:no big deal I'm working with miles on the russell stuff. | 20:39.47 |
| chrisl_r61 | henrys: okay. If it's urgent I'll look at the list of files Miles sent over the weekend, if it can wait, I'll do it on Monday | 20:40.38 |
| henrys | nothing urgent | 20:40.55 |
| chrisl_r61 | okay, I get it done on Monday. I must admit, I'm finding it hard to get excited about changes made five years ago! | 20:41.45 |
| rayjj | chrisl_I installed nemiver and it won't let me enter args :-( | 20:42.15 |
| chrisl_r61 | Oh, that's bad! | 20:42.55 |
| rayjj | chrisl: well, it doesn't like my -Z@\$\? If I use -Z@ then it works OK. | 20:45.32 |
| chrisl_r61 | maybe the backslashes need escaping or quoting or something. | 20:46.12 |
| rayjj | well it works with insight :-/ | 20:49.11 |
| chrisl_r61 | you could report it - the nemiver people claim to be keen to hear about problems | 20:50.13 |
| rayjj | chrisl_thanks for the suggestions. | 20:50.22 |
| chrisl_r61 | rayjj: there is also a way to use eclipse as a gdb gui, but I never figured out how to make it work - but, to be fair, I didn't try very hard. | 20:52.02 |
| Robin_Watts | rayjj: I never found a decent unix gui debugger. | 23:12.37 |
| | insight is the best of a bad lot. | 23:12.42 |
| | Forward 1 day (to 2011/08/27)>>> | |
IRC Logs