| <<<Back 1 day (to 2012/06/26) | 2012/06/27 |
mvrhel | Robin_Watts: I am getting no where with this file | 04:12.28 |
| If you can poke at it some tomorrow I would greatly appreciate | 04:12.39 |
| pulling my hair out on this | 04:12.49 |
ray_work | I am also developing an even higher hairline, but at least VS 2008 SP1 seems to be happy. Updating VS 2005 now, then I will (probably tomorrow) move the other apps over. | 04:26.24 |
| -- the ones that installed OK with the last attempt | 04:26.44 |
| at least with VS and msysgit I can get real work done | 04:27.27 |
| about 15% of 1.3Gb download for the updates after VS 2008 SP1 and VS 2005 install. | 04:28.46 |
| bbiaw | 04:28.53 |
mvrhel | ray_work: sounds like loads of fun... | 05:14.00 |
kens | chrisl, I finally fixed #692365 | 08:40.30 |
chrisl | kens: Oooh, excellent! | 08:46.45 |
| kens: Hah! Another ages to track down, but one character change fix! | 08:47.39 |
kens | Yeah, couldn't believe it when I found it :-( | 08:51.24 |
| Hmm, is macpro disabled on the cluster for a reason ? | 09:08.16 |
chrisl | I wondered that..... | 09:08.56 |
kens | Well, I'm not going to touch it, just in case | 09:09.11 |
chrisl | We might remember to ask henrys later on | 09:09.35 |
kens | Well, we 'might', I wouldn't count on me remembering | 09:09.54 |
chrisl | I did say 'might' for a reason :-) | 09:10.40 |
Robin_Watts | Morning tor8 | 09:19.25 |
tor8 | morning Robin_Watts | 09:37.15 |
Robin_Watts | I have a couple of small Makefile tweaks up for review on my casper branch if you have a mo. | 09:37.42 |
tor8 | all-nojs or all-js? | 09:39.54 |
Robin_Watts | "all" builds everything, including js if the library is there. | 09:40.17 |
| if there is no thirdparty v8, it doesn't build the js stuff. | 09:40.37 |
| But with the cluster we don't want to have to keep removing/reinserting the v8 lib, so I'd like to be able to tell it to make everything except the js stuff (for the standard mupdf tests) | 09:41.42 |
| hence all-nojs | 09:41.48 |
tor8 | right, so nojs skips building with v8 even if it's found. good. | 09:55.46 |
Robin_Watts | paulgardiner, tor8: There is at least a possibility that mujstest is working on the cluster | 11:31.45 |
paulgardiner | Excellent | 11:32.01 |
Robin_Watts | Having said that, the cluster is now not responding for me. | 11:35.48 |
| tor8: Is there a reason that you know why the cluster should be testing debug builds of mupdf rather than release ones? | 11:36.52 |
tor8 | Robin_Watts: not that I know. | 11:38.32 |
Robin_Watts | actually, marcosw has taken the mujstest stuff out of the cluster for now. | 12:02.27 |
| We'll have to wait til he comes back to see why. | 12:02.36 |
scott-san | Robin_Watts | 13:25.04 |
Robin_Watts | hi scott-san | 13:26.01 |
scott-san | Good afternoon to you. Just got an email from a potential customer that our URL might be down. | 13:26.37 |
Robin_Watts | mupdf.com works for me. | 13:27.16 |
| artifex.com... doesn't. | 13:27.20 |
| mace: You awake? | 13:27.32 |
chrisl | artifex.com works for me...... | 13:27.42 |
kens | and for me | 13:28.09 |
chrisl | as does ghostscript.com and mupdf.com | 13:28.38 |
Robin_Watts | Just artifex.com that's not working for me. | 13:29.01 |
chrisl | I'd guess that's an ISP problem, given kens and I get there okay | 13:29.29 |
scott-san | Just got your email Robin. I'll place the call tomorrow at 10:00 Central here in Texas. I'm thinking that you are 6 hours ahead or 4:00 P.M. your time. I'll try your number now to make sure all is working OK? | 13:30.04 |
paulgardiner | artifex.com working ok from here | 13:30.27 |
Robin_Watts | scott-san: go for it. | 13:30.39 |
kens | scott-san : where is potential customer located ? | 13:31.15 |
| I wonder if its a routing problem | 13:31.23 |
scott-san | The guy that couldn't get on artifex.com is from Ireland. | 13:33.27 |
kens | Then it could be some kind of routing problem since its affecting Robin too | 13:33.51 |
| Ireland is 'close enough' I expect | 13:34.09 |
scott-san | I'll talk to you guys later. Have a good day all! | 13:34.19 |
kens | bb scott-san | 13:34.24 |
Robin_Watts | night scott. | 13:34.30 |
kens | Robin_Watts : could you have a look here : | 13:35.26 |
| http://stackoverflow.com/questions/11223530/mupdf-for-android | 13:35.26 |
Robin_Watts | They haven't followed the copious detailed instructions in android/ReadMe.txt | 13:37.31 |
kens | : shall I reply and say that ? | 13:37.47 |
Robin_Watts | I'll answer in a mo. | 13:39.07 |
kens | OK thanks | 13:39.17 |
Robin_Watts | kens: Answered. | 13:46.21 |
kens | Robin_Watts : thanks | 13:49.13 |
ray_work | morning, all | 14:01.34 |
kens | Hi ray_work | 14:01.41 |
mace | Robin_Watts: vaguely | 14:02.59 |
Robin_Watts | mace: Was just checking - you aren't fiddling with artifex.com at the moment are you? | 14:03.19 |
mace | nope, haven't touched it | 14:03.27 |
| don't have access | 14:03.30 |
Robin_Watts | Didn't think I could blame you, but thought it was worth checking :) Thanks. | 14:03.44 |
mace | that reminds me, i need to chase miles | 14:03.46 |
| he's gone silent'n'deep | 14:03.54 |
Robin_Watts | he was away on holiday. | 14:04.07 |
| when did you try to contact him? | 14:04.23 |
| He was out all last week - should be back now I think. | 14:05.10 |
mace | last emailed him on the 31st May | 14:07.15 |
| have just sent another | 14:07.22 |
ray_work | grrr... I have to boot from the old HD (which is the system that kept crashing) and fire up Adobe Illustrator and Photoshop to "deactivate" the license so I can activate it on the new machine. | 14:15.00 |
| or try and get through to Adobe and get support :-( | 14:15.23 |
mace | good luck with that :) | 14:16.04 |
ray_work | In the past I could have just flown up to San Jose and gone in and pestered someone, since I had a badge. Probably would have been faster than waiting for their support to respond | 14:18.30 |
Robin_Watts | ray_work: Surely you need to fly to Mumbai to speak to the relavent people these days? | 14:20.20 |
ray_work | Robin_Watts: I want somebody that knows what they are doing -- not customer support | 14:20.57 |
| they should just make the script that they give to those guys available and let people step through on their own | 14:21.52 |
| then if you get to the end and the problem persists, you immediately get the supervisor | 14:22.30 |
Robin_Watts | Most people are incapable of following simple step by step instructions. | 14:22.55 |
ray_work | Robin_Watts: sad but true | 14:23.12 |
Robin_Watts | I got a photobook of my pictures from vietnam done recently. | 14:23.46 |
| and about 1/4 of the left hand pages have bad registration between the color plates. | 14:24.11 |
| So I complained. | 14:24.20 |
| and they asked me to scan in a page to show the problem (so I did) | 14:24.32 |
ray_work | let me guess -- they blamed their software | 14:24.43 |
Robin_Watts | and they agreed that there was indeed a problem and they would reprint it. | 14:24.45 |
| BUT... they didn't want to reprint it from the version of the book that they had on their system. | 14:25.09 |
| They wanted me to reupload the book from my machine again. | 14:25.23 |
ray_work | oh, no | 14:25.38 |
Robin_Watts | I asked how exactly that was supposed to get them anything different on their machine... | 14:25.55 |
ray_work | chrisl: I just saw your email about the Artifex 'downloads' page. I'll see if I can get in, and send you instructions to do so. | 14:29.52 |
chrisl | ray_work: great, thanks. Are you happy if I just replace the "current stable" bit with a link to to the ghostscript.com download pages? | 14:31.07 |
Robin_Watts | tor8: ping | 14:51.10 |
| Hi mvrhel | 15:00.35 |
| I have some (limited) news for you. | 15:00.40 |
| The crash on linux with your patch/file happens in gs_param_list_unserialize | 15:01.18 |
| On the first call to gs_param_list_unserialize, 'type' is initially read as 0. Then we go around the loop, and type gets read as 6164 (which looks suspiciously like a bogus value to me) | 15:02.06 |
| Then it does the memcpy at line 254, and it's then that the exception is raised, claiming a buffer overflow. | 15:03.00 |
| probably because value_top_sizeof (which has just been set to gs_param_type_sizes[type]) is bogus. | 15:03.46 |
ray_work | oh no. I booted from my old hard drive and started up Illustrator to 'deactivate' it, and it won't (Deactivation Unsuccessful Error code 194:1). At least I was able to deactivate Photoshop OK. | 15:03.54 |
mvrhel | Robin_Watts: ok thanks | 15:04.38 |
| On both my 64 bit windows and 64 bit linux, the clist rastering function errors out | 15:05.14 |
| with an unknown error -1 | 15:05.26 |
| I am trying to see where that is happening | 15:05.34 |
Robin_Watts | The backtrace I get is: | 15:05.48 |
ray_work | mvrhel: is it a DEBUG build ? | 15:05.50 |
mvrhel | ywa | 15:05.54 |
| yeas | 15:05.56 |
| yes | 15:06.01 |
| cant type | 15:06.05 |
ray_work | you can set a bp in gs_log_errors conditional on err == -1 | 15:06.12 |
mvrhel | oh good point | 15:06.24 |
| it was about 12:15 am when I was working on this | 15:06.41 |
Robin_Watts | /lib/libc.so.6(__fortify_fail+0x37)[0x7fe3293ecb87] | 15:06.43 |
| /lib/libc.so.6[0x7fe3293ebb30] | 15:06.44 |
| bin/gs(gs_param_list_unserialize+0x115)[0x6841b5] | 15:06.46 |
| bin/gs(clist_playback_band+0x69a6)[0x67bba6] | 15:06.48 |
| bin/gs(clist_playback_file_bands+0x138)[0x67c508] | 15:06.50 |
| bin/gs(clist_render_rectangle+0xfb)[0x67c73b] | 15:06.51 |
| bin/gs(clist_rasterize_lines+0x21f)[0x67ca0f] | 15:06.53 |
| bin/gs(clist_get_bits_rectangle+0x1f9)[0x67d119] | 15:06.54 |
| bin/gs[0x691556] | 15:06.56 |
| bin/gs(gx_downscaler_get_bits_rectangle+0x216)[0x66e2f6] | 15:06.57 |
| bin/gs[0x73f24b] | 15:06.59 |
| bin/gs(gdev_prn_output_page+0x78)[0x66c388] | 15:07.01 |
| bin/gs[0x525fc5] | 15:07.03 |
| bin/gs[0x4f7476] | 15:07.04 |
| bin/gs(gs_interpret+0x15b)[0x4f8a4b] | 15:07.06 |
| bin/gs(gs_main_run_string_end+0x2c)[0x4ed5ec] | 15:07.07 |
| bin/gs[0x4ee79e] | 15:07.09 |
| bin/gs[0x4eef0e] | 15:07.10 |
| bin/gs(gs_main_init_with_args+0x3a4)[0x4f0944] | 15:07.12 |
| bin/gs(main+0x54)[0x4660a4] | 15:07.13 |
| /lib/libc.so.6(__libc_start_main+0xfd)[0x7fe329313abd] | 15:07.15 |
| bin/gs[0x465f89] | 15:07.16 |
| So my error is happening in the clist rasterisation stuff too. | 15:07.22 |
ray_work | bbiab (have to switch cars with my wife) | 15:07.58 |
mvrhel | ok. I have to get my son ready and out to lacrosse camp then take my wife for her follow-up dr. appt. when I get back I will follow up on this | 15:08.04 |
| thanks Robin_Watts | 15:08.07 |
Robin_Watts | np. Let me know if there are more tests you'd like done. | 15:08.19 |
mvrhel | ok thanks | 15:08.28 |
Robin_Watts | Hi marcosw | 16:41.13 |
| Got time to talk for a mo ? | 16:41.18 |
tor8 | Robin_Watts: pong. | 16:42.52 |
Robin_Watts | tor8: I have a con-call tomorrow with a mupdf customer. | 16:43.09 |
| they've just mailed in various files that they say are slow. | 16:43.20 |
| they are using an ARM9 with no floating point hardware. | 16:43.39 |
tor8 | Oooh. no FP might hurt just a bit. | 16:44.16 |
Robin_Watts | Now, the only ARM 9 device I have here is a Nintendo NDS :) | 16:44.27 |
tor8 | at least we don't use doubles :) | 16:44.40 |
Robin_Watts | I *could* port mupdf to that and profile it, but I worry about the memory footprint :) | 16:45.00 |
| I've asked them if they have a profiler. | 16:45.13 |
| Are you interested in seeing these mails/files etc ? | 16:45.26 |
tor8 | I would like to see them, at least the emails. | 16:46.04 |
| brb, dinner | 16:46.06 |
Robin_Watts | ok. I'll forward them along. | 16:46.14 |
henrys | and the fires continue wow http://photos.denverpost.com/mediacenter/2012/06/photos-waldo-canyon-fire-near-garden-of-the-gods/38318/ | 16:51.51 |
chrisl | Robin_Watts: do we know what they are comparing with to judge mupdf to be slow on these files? | 16:52.15 |
Robin_Watts | slowness, no. They basically say "if it takes more than 5 seconds a page, it's slow" | 16:52.47 |
| for rendering differences "imagemagick" :) | 16:53.00 |
chrisl | Well, that's complete nonsense - especially on an embedded device...... | 16:53.13 |
Robin_Watts | chrisl: To be fair, they aren't stamping their feet and screaming. | 16:54.46 |
henrys | It might be reasonable to compare a simple text job that mupdf is known to rip fast say PLRM on the system then compare that to a host if it is the same multiplier we'd suspect a systemic problem. | 16:55.16 |
| same multiplier as the jobs they sent. | 16:55.37 |
Robin_Watts | henrys: My understanding is that most files are fine, these are the slow ones they have identified. | 16:55.52 |
| we'll find out more tomorrow in the con-call. | 16:56.00 |
chrisl | Robin_Watts: I suppose it does depend on what they actually want - but I can easily create a page which will take more than 5 seconds to render in Acrobat on a "real" computer | 16:56.11 |
henrys | Robin_Watts:sorry I didn't get through all the emails. | 16:57.25 |
Robin_Watts | henrys: np. | 16:57.44 |
| tor8: Patch for review on my casper repo. | 17:08.08 |
| (master branch) | 17:08.15 |
| and another | 17:31.53 |
mvrhel | henrys: that photo is crazy | 17:37.33 |
henrys | day after day is above 100 and single digit humidity probably more to come. | 17:43.02 |
mvrhel | we are having our first real sunny no rain day here | 17:43.24 |
| we might hit 73 today | 17:43.37 |
| Robin_Watts: so sure enough, I am getting the unknown error in gs_param_list_unserialize during clist playback. At least now, I have something I can debug | 17:50.35 |
Robin_Watts | Is there a gs_param_list_serialize ? | 17:53.58 |
| Cos I bet the first call to that is writing garbage into the clist, and the unserialize is tripping over it. | 17:54.20 |
mvrhel | well who knows if it is even supposed to be in there. I need to catch the valid command before and look at the clist buffer | 17:54.29 |
| to see what is there | 17:54.40 |
| working on that now | 17:54.54 |
| i.e. the command call itself may be garbage | 17:55.50 |
Robin_Watts | I follow | 17:56.02 |
tor8 | Robin_Watts: both on robin/master look fine | 18:01.13 |
Robin_Watts | tor8: Thanks. | 18:01.38 |
mvrhel | so sure enough, the command before we explode is cmd_op_copy_color_alpha | 18:07.20 |
| which is the obvious candidate | 18:07.31 |
| ok so the cmd_op_copy_color_alpha was fine | 18:17.51 |
Robin_Watts | was fine when writing? | 18:18.51 |
| maybe it's leaving the pointer in the wrong place when reading? | 18:19.00 |
mvrhel | ick this extended command following it is wacked though | 18:19.20 |
| I need to see who is writing out this garbage | 18:19.31 |
| Robin_Watts: it was fine in writing and in reading and in implementing | 18:20.56 |
| the clist buffer data after this one is crazy stuff | 18:21.18 |
| and sure enough, we never write out a command for this one that we are reading back | 18:22.09 |
Robin_Watts | right, so maybe it's managing to write out the correct data, but somehow leaving the clist in a confused state so that subsequent writes are upset? | 18:22.12 |
mvrhel | maybe. I need to catch it in the writing phase for this one and see what is going on after that | 18:22.36 |
Robin_Watts | or it's reading the correct data in, but leaving it in a confused state so that subsequent reads are upset. | 18:22.58 |
| Can you use -Zl to see what the clist should look like on writing ? | 18:23.34 |
| I'll shut up and leave you to it. You don't need me kibbitzing. | 18:23.52 |
mvrhel | the file takes *forever* with -Zl | 18:24.13 |
| I think I have a way to catch it using breakpoint counting | 18:24.36 |
Robin_Watts | ooh. I have a displaylist vs non displaylist bug in mupdf. | 18:26.37 |
| tor8: Another patch for you to review, whenever you have time. Thanks. | 18:46.48 |
tor8 | Robin_Watts: looks okay. | 18:49.13 |
Robin_Watts | Thanks. | 18:49.23 |
mvrhel | hmm well we never do a write with cmd_op_copy_color_alpha to the clist with those parameters so that command is wrong. need to eat lunch and go back one more command... | 19:15.54 |
| I suspect the raster length is wrong | 19:16.25 |
Robin_Watts | I have a CMYK jpeg that's displaying wrong in mupdf. joy. | 19:17.56 |
tor8 | Robin_Watts: I approve of the fz_adjust_rect_for_stroke patch | 19:20.59 |
Robin_Watts | The bmpcmp is convincing :) | 19:21.59 |
ray_work | mvrhel: BTW, if you have a rough idea of a hit count breakpoint you can turn on -Z flags at the breakpoint by setting gs_debug['L'] to non-zero (in a watch window) | 19:58.21 |
| mvrhel: NOTE that turning on gs_debug['L'] during clist playback of a band will die because it hasn't set up some kind of offset_map, so don't try that | 19:59.42 |
| mvrhel: I *think* that you can turn on gs_debug['L'] when starting playback of a band, so if you know the offending band you can cut down the noise (and time) in the trace | 20:15.32 |
| if my laptop were up, I could tell you for sure (est. time remaining 4 hrs -- been running for 4 hrs) | 20:16.12 |
| oops. problem at the pool -- I have to run... bbiaw | 20:18.04 |
Robin_Watts | marcosw: ping ? | 22:53.16 |
| Forward 1 day (to 2012/06/28)>>> | |