| | <<<Back 1 day (to 2011/10/04) | 2011/10/05 |
| Robin_Watts | spins the update roulette wheel and allows VMWare Player 4 to do it's thing. | 12:27.01 |
| | reboot | 12:32.15 |
| | gah. 2 reboot.s | 12:58.41 |
| henrys | kens:beyond what is written to stdout, and stderr are there any other status reporting facilities in pdfwrite? | 15:03.27 |
| kens | I don't think so, no. | 15:04.19 |
| henrys | I thought not but I wanted to be sure. | 15:04.36 |
| | there is that status business in dll.htm, I've never used that maybe ray knows about that. | 15:10.46 |
| kens | Never seen that, will go look | 15:10.58 |
| henrys | it is supposed to be obsolete... | 15:15.12 |
| kens | can't see it in docs | 15:16.14 |
| henrys | another agenda item... actually get rid of it. | 15:16.19 |
| kens | :-) | 15:16.26 |
| ray_laptop | henrys: what 'status business' ? The only 'status' I see in DLL.htm is the return code | 15:34.45 |
| kens | yes, that's all I saw | 15:34.57 |
| ray_laptop | henrys: what kind of status from pdfwrite are you looking for (and why) ? | 15:35.12 |
| henrys | the obsolete dll.htm callback function. | 15:37.36 |
| ray_laptop | henrys: did you mean to get rid of the gsdll entry points (and DLL.htm) entirely ? It is probably about time. | 15:37.40 |
| | since they've been replaced by the gsapi calls (and API.htm) | 15:38.17 |
| henrys | I don't know what the customer wants I asked and explained he could write a postscript program to query some types of information. | 15:38.25 |
| ray_laptop | henrys: not much available except the page count when writing PDF's. The pdfwrite doesn't export anything like number of objects or anything | 15:39.38 |
| | henrys: the PS snippet for querying how many pages have been written is: currentpagedevice /PageCount get | 15:40.32 |
| | I've had customers request 'progress' information when rendering (so they could update a progress bar), but never with pdfwrite. | 15:41.38 |
| henrys | I'll forward his request to support when he responds to what he wants. I'd like to duck out of it now anyway... | 15:41.59 |
| ray_laptop | henrys: sounds like a good 'VP | 15:42.22 |
| | thing to do | 15:42.37 |
| | rained a bit yesterday, but now it's really coming down. | 15:43.24 |
| henrys | I really hope they didn't try and use that dll api instead of the regular api.htm | 15:43.32 |
| ray_laptop | it's really easy enough to switch over to the gsapi calls -- most things are quite similar | 15:52.02 |
| henrys | the dll api does have a page callback, we should have some facility like that in API.htm. | 16:00.54 |
| kens | heading off, night all | 16:53.55 |
| henrys | bye kens | 16:54.09 |
| Robin_Watts | Aloha! | 17:01.50 |
| mvrhel2 | Aloha Robin_Watts | 17:02.03 |
| Robin_Watts | How's Maui? | 17:04.45 |
| mvrhel2 | good. we drove all the way around the east side of the island yesterday | 17:06.29 |
| | I had not done that before | 17:06.34 |
| henrys | watch out for the nude beach if you have your kids. | 17:07.01 |
| Robin_Watts | Maiu is basically a figure 8 tilted so it's axis is north west/south east, right? | 17:07.20 |
| mvrhel2 | yes | 17:07.29 |
| Robin_Watts | When I got the hire car I was told that there were some 'no go' areas. | 17:07.52 |
| mvrhel2 | the south east road is very rough and unimproved with sheer drop offs on one lane roads | 17:08.02 |
| Robin_Watts | (i.e. areas where the road was bad, and I would be uninsured if I drove there) | 17:08.06 |
| mvrhel2 | supposedly this was one of those areas | 17:08.17 |
| Robin_Watts | Is that "The Road to Hana" ? | 17:08.19 |
| mvrhel2 | but there is a question as to what is unimproved | 17:08.27 |
| | it had patches on pot holes | 17:08.34 |
| | of course in spots that is all that the road was was patches | 17:08.46 |
| | so yes. this is the road to hana but we went beyone hana which is the crazy bad road | 17:09.17 |
| Robin_Watts | I drove round the north west side intending to stop when I hit the bad road, and pretty much made it round without finding any problems. | 17:09.22 |
| | Right. | 17:09.27 |
| mvrhel2 | if you made it aournd the north west part then the south east part would be easy for you | 17:09.48 |
| Robin_Watts | When we did the Road to Hana we were late in the day by the time we arrived, so I didn't carry on much further. | 17:09.52 |
| ray_laptop | mvrhel2: just the person I need. | 17:10.08 |
| | mvrhel2: hope you're having a good time | 17:10.22 |
| mvrhel2 | I tried driving around the north west part and there were too many people going opposite ways on the one way sections | 17:10.25 |
| | ray_laptop: if you want me to take over that RGBW issue I can work on it today | 17:10.53 |
| henrys | it's an incredible drive though - road to Hana | 17:10.57 |
| ray_laptop | if none of the kids are prone to car sickness | 17:11.12 |
| Robin_Watts | ray_laptop: It's a hire car :) | 17:11.29 |
| ray_laptop | yuk! | 17:11.41 |
| | and that's why you need to keep the windows rolled down | 17:12.14 |
| mvrhel2 | luckily we did not have any of those issues | 17:12.52 |
| ray_laptop | mvrhel2: if you are available for a spot of work stuff, then let me tell you what's going on. | 17:12.55 |
| | btw, the gdevcups is REALLY ugly code. | 17:14.29 |
| mvrhel2 | yes. I know that :) | 17:14.47 |
| ray_laptop | mvrhel2: so what is happening is that the cups device has num_components == 4 and depth == 32, but of course, the pdf14 device just wants RGB, so it is 3 components, 24-bit | 17:16.05 |
| | the problem is that the clist cmd_put_color writes using the cldev->clist_color_info.depth which is 32, and then when we read the color we use the 'tdev' which has 24 bits | 17:17.23 |
| | there's a comment in gxclutil.c line 554 that mentions what it is doing | 17:18.46 |
| mvrhel2 | ok. that wont work | 17:18.47 |
| ray_laptop | but I can't see how that will ever work, even for normal 24 bit RGB if the pdf14 is working in a CMYK color space. | 17:19.37 |
| mvrhel2 | ray_laptop: I will need to dig into things to see what is going on | 17:20.15 |
| ray_laptop | in this case it's the other way around -- we are writing MORE bytes than we read, but either way seems wrong | 17:20.51 |
| Robin_Watts | ray_laptop, mvrhel2: Before I forget (and not to distract you from what you're discussing now) I made some changes to the clist code to pass planar data in a strip_copy_rop call the other day (i.e. tile_slot now has planar stuff). It may be worth one of you sanity checking my code in case I've done something stupid. | 17:21.42 |
| ray_laptop | Robin_Watts: I glanced at the commit, but I'll look more closely since you asked so nicely ;-) | 17:22.38 |
| mvrhel2_ | sorry dropped off | 17:23.41 |
| | ray_laptop: I am going to grab some breakfast and then I will dig into this | 17:24.30 |
| ray_laptop | mvrhel2: np. So maybe we just aren't initializing clist_color_info correctly ? | 17:24.53 |
| | mvrhel2: OK. Check with me after breakfast and I may have more understanding (so maybe you won't have to help) | 17:25.52 |
| | mvrhel2: if I'm not on IRC, then just give me a call. | 17:26.20 |
| mvrhel2 | ok | 17:26.25 |
| ray_laptop | mvrhel2: for when you get back. I see how the normal RGB case works when we switch to CMYK, you set the clist_color_info.depth, etc. in pdf14_update_device_color_procs_push_c | 17:49.38 |
| | mvrhel2: and correspondingly in ..._color_procs_pop_c | 17:50.19 |
| mvrhel2 | ray_laptop: and why does it not get updated with the RGBW case? | 18:02.49 |
| ray_laptop | mvrhel2: usually the RGB case is already OK with clist_color_info because the initial compositor device is 24-bit RGB and the clist device color_info matches. | 18:02.56 |
| | mvrhel2: in the RGBW case, the pdf14 device depth does NOT match the clist_color_info depth (and num_components) | 18:03.48 |
| | the code in c_pdf14trans_clist_write_update (gdevp14.c line 6890) has me a little confused. | 18:05.03 |
| | but in this case it isn't re-calculating the clist_color_info.depth because 8*num_components _does_ equal the depth | 18:06.09 |
| | so the clist_color_info never gets changed to match the p14dev's color_info | 18:06.32 |
| mvrhel2 | ray_laptop: sorry it is going to be a bit longer before I can follow this. going to take the kids snorkling right now | 18:07.39 |
| ray_laptop | I added code to do that, but am confused by the aforementioned 'if' stmt | 18:07.45 |
| | mvrhel2: OK. I'll continue testing with my patch | 18:08.07 |
| | have fun snorkeling -- I'll email if I find out about the area I have in question, and let you know the results of my testing | 18:08.51 |
| | ahh, I see what that funky code's about. It is re-computing if the depth per component is not 8, but if I use the color_info from the p14dev, it will ALWAYS be 8 bits per component (from the protoype) so that code is no longer needed (with my patch) | 18:21.25 |
| Robin_Watts | tor8: Here? | 18:50.40 |
| | tor8, sebras: I've just pushed a new version of mupdf to the 'context' branch on my repo on casper. | 18:54.26 |
| | This passes memento memory squeezing for pdfdraw on tiger.pdf | 18:54.43 |
| marcosw_ | alexcher: you around? | 19:12.44 |
| marcosw_ | realizes it's not unusual for most of you, but we are in the midst of a thunderstorm (we only have 1 or 2 a year in northern california). | 19:21.05 |
| henrys | how do Californians survive outside of their native never changing climate? | 19:38.46 |
| | I wasn't sure if I was clear about the pcl bugs at the meeting yesterday, one I assigned back to you and wanted to push back. I can do it if you prefer, let me know. | 19:40.41 |
| | marcosw_^^^ | 19:41.14 |
| | marcosw_ ^^^ | 19:41.30 |
| marcosw_ | you mean http://bugs.ghostscript.com/show_bug.cgi?id=692545 | 19:41.58 |
| henrys | yes | 19:42.24 |
| | the other one I fixed, tom should be notified but his email is on the bug. | 19:43.02 |
| marcosw_ | I was going to try the file on another couple of HP printers. If they printed it correctly that would be 4 to 1 in favor of it being an issue with your printer. | 19:43.04 |
| henrys | Even so, best to be responsive and tell them we've found a problem on an HP printer so we don't consider it a very serious problem but whatever you think. | 19:45.45 |
| | if you want me to work on it I'll need to reduce it and send you parts of the file to print which may involve some back and forth. | 19:47.16 |
| marcosw_ | what model printer do you have? I'll let the customer know. | 19:51.59 |
| | henrys: ^^^ | 19:53.51 |
| henrys | color laserjet 4600 | 19:56.22 |
| sebras | Robin_Watts: it would be ok to have two pairs of fz_try/fz_catch in a function, right? if that is the case why do you need the break stuff in pdf_load_image_impl..? | 19:56.47 |
| Robin_Watts | Yes, it's fine to have 2 pairs. | 19:57.07 |
| sebras | Robin_Watts: I'm a bit late to react, I know... | 19:57.08 |
| Robin_Watts | You mean sequentially, or nested? (both are fine) | 19:57.18 |
| sebras | sequentially in this case. | 19:57.25 |
| | the first would take care of the j2k special case while the second takes care of the normal case. | 19:57.48 |
| | basically you could set a local variable (or check an existing one) to see if the j2k load was successful..? | 19:58.24 |
| Robin_Watts | sebras | 19:58.29 |
| | sebras: Yes, there are other ways to work. | 19:58.40 |
| sebras | if this is the only case where break is needed maybe it can be worked around. | 19:58.43 |
| | not sure whether it makes sense or not. | 19:58.56 |
| Robin_Watts | sebras: Both tor8 and I are in agreement that it's better to have a break context there than not. | 19:59.12 |
| | The big restriction with the macros is that you must not return from the try. | 19:59.43 |
| sebras | Robin_Watts: I did read the log, but I sensed that neither of you appeared to discuss the alternatives... | 19:59.45 |
| | I know. | 19:59.48 |
| Robin_Watts | (or 'goto' out of it) | 19:59.49 |
| | As such, being able to 'break' out is a clean alternative to having to put a label at the end of the try bit. | 20:00.18 |
| sebras | I agree that it is kind of neat, but if this is an exceptional circumstance then maybe break/continue should not have this extra use. | 20:01.43 |
| arthurf | henrys: re "how do Californians survive outside of their native never changing climate?" I was in Longmont for 9.5 years, never quite got used to the cold - had to come back home. | 20:02.08 |
| sebras | Robin_Watts: basically pdf_is_jpximage() seens to me to be an early return structure, and as such it may be more common in mupdf than I realize. | 20:02.35 |
| henrys | is that arthur ford? | 20:03.03 |
| arthurf | it is | 20:03.10 |
| Robin_Watts | sebras: Maybe. I'm quite prepared to believe that the way I have the code at the moment is suboptimal. | 20:03.21 |
| | Feel free to have a play. | 20:03.28 |
| | being called for food. | 20:03.44 |
| henrys | arthurf:I don't know, really pretty mild in contrast to say the northeast winters but we do have some cold. | 20:04.18 |
| sebras | Robin_Watts: I'm just wary of adding more non-traditional macro-hacks. unless they are indeed required or used a lot. | 20:04.34 |
| henrys | arthurf:are you still with the same company? | 20:04.42 |
| sebras | Robin_Watts: I will try to have a stab at it next week when I have vacation (after having resigned). | 20:05.02 |
| arthurf | henrys - no - I left InfoPrint in 2009 and went back to Southern California | 20:05.09 |
| henrys | bbiab | 20:09.34 |
| | marcosw_:I guess you looked but nothing the logs? | 20:46.00 |
| | on the miles machine that is. | 20:46.30 |
| marcosw_ | henrys: I'm sorry, but what logs are you asking about? | 21:15.41 |
| | right you mean the system logs... | 21:16.02 |
| | The only thing that's suspicious is in syslog: | 21:22.08 |
| | Sep 29 01:00:37 miles kernel: [32369.028867] BUG: soft lockup - CPU#0 stuck for 61s! [kswapd0:94] | 21:22.09 |
| | Sep 29 01:00:37 miles kernel: [32369.028873] Modules linked in: binfmt_misc ppdev snd_hda_codec_atihdmi snd_hda_codec_realtek snd_hda_intel snd_seq_dummy snd_hda_codec snd_seq_oss snd_hwdep snd_seq_midi snd_pcm_oss snd_rawmidi snd_mixer_oss fbcon tileblit font bitblit softcursor snd_pcm fglrx(P) snd_seq_midi_even | 21:22.10 |
| | Sep 29 01:00:37 miles kernel: [32369.028933] CPU 0: | 21:22.10 |
| | Sep 29 01:00:37 miles kernel: [32369.028936] Modules linked in: binfmt_misc ppdev snd_hda_codec_atihdmi snd_hda_codec_realtek snd_hda_intel snd_seq_dummy snd_hda_codec snd_seq_oss snd_hwdep snd_seq_midi snd_pcm_oss snd_rawmidi snd_mixer_oss fbcon tileblit font bitblit softcursor snd_pcm fglrx(P) snd_seq_midi_even | 21:22.10 |
| | Sep 29 01:00:37 miles kernel: [32369.028988] Pid: 94, comm: kswapd0 Tainted: P W 2.6.32-33-generic #72-Ubuntu System Product Name | 21:22.10 |
| henrys | marcosw_:not much there, darn. BTW can you make all the source code associated with the cluster available in the tree? You used to have all the server stuff in the localcluster directory. | 23:15.07 |
| Robin_Watts | henrys: The cluster code is all in a git repo on casper. | 23:15.28 |
| | http://git.ghostscript.com/?p=cluster.git;a=summary | 23:15.43 |
| henrys | thanks | 23:16.02 |
| Robin_Watts | Having said that, I bet it's out of date... | 23:16.17 |
| henrys | actually I wanted to check which directories are tested in the local push, but the code should be open for us too look at. | 23:17.43 |
| | I think there's been a change since july. | 23:18.30 |
| Robin_Watts | henrys: /home/regression/cluster is world readable I believe. | 23:19.16 |
| henrys | ah found my answer in build.pl thanks. | 23:23.45 |
| Robin_Watts | mupdf seems to be memory squeezing OK now. | 23:25.52 |
| | tiger.pdf is clean, and pdf_reference is at 33000 and counting without leaking. | 23:26.07 |
| | Forward 1 day (to 2011/10/06)>>> | |
IRC Logs