00:04.42 Opened logfile log/20130321. 00:04.41 ray_laptop: you here? 00:06.00 Robin_Watts: yes 00:06.22 Did you see my earlier burblings about gc and the gs_state->halftone ? 00:06.48 yes, but I didn't really look at it. Just a minute... 00:07.07 I just wondered if you had any instant idea about it. 00:08.30 so, by "marking through", do you mean tracing the gs_state, marking objects which are enumerated by the gs_state ? 00:09.29 Yes. Line 878 of igc.c 00:10.11 >>> join/#ghostscript JakeSays (~quassel@2601:7:7580:28:61d1:b71f:388b:c754) 00:12.34 Chans: (ghostbot) in:#ghostscript 00:14.14 line 878 does not say if (o_is_unmarked(ptr)) which you mentioned in the logs, but I see: if (!ptr_struct_mark(&nep, pstate)) 00:14.24 FORK(11301) --- fork starting for 'RSSFeeds', PID == 11301, bot_pid == 1004 --- 00:14.26 FORK(11301) !ERROR! cannot load my module: RSSFeeds 00:14.26 FORK(11301) fork: took 2s for RSSFeeds. 00:14.26 FORK(11301) --- fork finished for 'RSSFeeds' --- 00:14.47 right, and in ptr_struct_mark, it leads to if (o_is_unmarked(ptr)) 00:16.18 Robin_Watts: in line 1088 I see: if (!o_is_unmarked(ptr)) -- not exactly what you mentioned in the logs: if (o_is_unmarked(ptr)) 00:16.34 but close :-) 00:16.38 Sorry, probably a typo on my part. 00:16.49 The entire object header looks sensible to me. 00:17.11 size, type, reloc etc. 00:17.36 well, size, and type at least. 00:17.44 OK. so the pointer isn't pointing at the expected place, but offset by some amount ? 00:17.51 oh, and reloc. 00:18.16 Robin_Watts: or do you think valgrind is confused somehow ? 00:18.18 ray_laptop: The pointer points to the halftone, as expected. 00:18.31 and the object header is before that, and that looks reasonable. 00:18.53 So it looks to me like valgrind is being confused about the the value being uniniitalised. 00:19.05 Robin_Watts: OK. 00:19.11 I wonder why ? 00:19.21 On obj_header_data_s, there is some bitfield stuff. 00:19.29 In obj_header_data_s, there is some bitfield stuff. 00:19.48 Robin_Watts: have you tried valgrind on a DEBUG build -- with -Z@$? on that file 00:19.51 What is the: unsigned _:1, smark:obj_mb_bits; about? 00:20.11 I haven't tried those flags, no. 00:20.25 I can't see us ever accessing _ 00:20.34 Robin_Watts: got me there -- that's some of Peter's magic stackless GC trace magic, AFAIK 00:22.05 hmm. Maybe he's assuming that _h.alone will be in the same place as _m._ will be. 00:22.31 I didn't think you were allowed to assume anything about the order of bitfields 00:24.57 I bet valgrind is thinking that some of the bits are undefined. 00:25.15 I'm going to risk my sanity by trying to understand this tomorrow. 00:25.16 Robin_Watts: isn't that the point of bitfields ? to define the order. But that applies to bitfields in a struct -- unions are a different matter 00:25.37 ray_laptop: No. The point of bitfields is to allow space efficient storing. 00:25.56 K&R is at pains to say that the order and packing of bitfields is implementation dependent. 00:26.26 --- Saved uptime records. 00:26.36 those are some pretty yucky macros and structs/unions 00:26.39 It then goes on to say that the ANSI standard makes it even more implementation dependent, and so people should read everything about bitfields as being implementation dependent qithout qualification. 00:27.39 Seen: Flushed 2 entries. 00:27.58 ray_laptop: Damn straight. 00:28.32 Chans: (ghostbot) in:#ghostscript 00:32.22 ray_laptop: with respect to 693178... is it possible to say "only check for this optimisation if my device is capable of coping with devn color" ? 00:32.24 Robin_Watts: so you think that we are just lucky that all of the compilers we've encountered implement bitfields consistently ? Seems a bit unlikely 00:33.04 ray_laptop: I suspect that all compilers pack bitfields always either MSB or LSB. 00:33.15 so peters code is fine. 00:33.46 Robin_Watts: well, it actually isn't that the device isn't capable -- just that the color type's dc_write proc (for clist serialization) doesn't let it write 00:34.07 I suspect that valgrind is being upset by the use of bitfields. 00:34.27 So we should disable the optimisation for some subset of color types ? 00:34.38 so the "default" code is supposed to "simplify" it by doing the pattern differently 00:35.51 If we had a "can this color type be serialised" call, we could intelligently pick whether to do the optimisation or not ? 00:35.52 Robin_Watts: let me mull that over. That's a good idea, I think. It will prevent most devices from being impacted (in case the optimization was actually more useful than I think) 00:36.55 ray_laptop: Or change the code to scribble 0's into the mask when the optimisation hits, and then clusterpush to see how often we encounter files like that? :) 00:39.20 Robin_Watts: we can check if (pdevc->type->write == gx_dc_cannot_write) 00:40.14 Robin_Watts: Well, that's a way to see how many times it is encountered -- change the data to write at least 1 bit of '0' and then don't optimize 00:40.23 ray_laptop: exactly. 00:44.54 Chans: (ghostbot) in:#ghostscript 00:45.14 FORK(23370) --- fork starting for 'RSSFeeds', PID == 23370, bot_pid == 1004 --- 00:45.15 FORK(23370) !ERROR! cannot load my module: RSSFeeds 00:45.15 FORK(23370) fork: took 1s for RSSFeeds. 00:45.15 FORK(23370) --- fork finished for 'RSSFeeds' --- 00:58.02 Robin_Watts: trying that now. 01:01.26 Chans: (ghostbot) in:#ghostscript 01:02.04 want to place any bets ? 01:02.52 >>> sojic has signed off IRC (Remote host closed the connection) [#ghostscript] 01:03.30 I think the number of times that a pattern ends up being solid will be quite rare, and then only at low res, so the files run so fast it won't matter anyway 01:04.10 possibly, yes. 01:04.33 but is there also the case where we have a very small pattern that's repeated a lot ? 01:04.46 back in 1993 or before when this probably was introduced, it might have mattered 01:05.14 Robin_Watts: there is code to replicate patterns up to 32-bits iirc 01:05.23 at least in X 01:05.50 Robin_Watts: also halftone tiles (where it is fairly likely) 01:06.21 I'm not sure about colored patterns, however 01:08.37 bbiaw 01:13.00 >>> ray_laptop has signed off IRC (Ping timeout: 260 seconds) [#ghostscript] 01:15.32 FORK(7621) --- fork starting for 'RSSFeeds', PID == 7621, bot_pid == 1004 --- 01:15.33 FORK(7621) !ERROR! cannot load my module: RSSFeeds 01:15.33 FORK(7621) fork: took 1s for RSSFeeds. 01:15.33 FORK(7621) --- fork finished for 'RSSFeeds' --- 01:16.42 >>> join/#ghostscript marcosw (~marcosw@67.169.6.130) 01:16.42 Chans: (ghostbot) in:#ghostscript 01:18.34 >>> join/#ghostscript Fandekasp (~Fandekasp@p17205-ipngn100203yosemiya.okinawa.ocn.ne.jp) 01:27.02 --- Saved uptime records. 01:27.48 Seen: Flushed 2 entries. 01:32.30 Chans: (ghostbot) in:#ghostscript 01:40.39 >>> marcosw has signed off IRC (Quit: marcosw) [#ghostscript] 01:45.36 FORK(24873) --- fork starting for 'RSSFeeds', PID == 24873, bot_pid == 1004 --- 01:45.37 FORK(24873) !ERROR! cannot load my module: RSSFeeds 01:45.37 FORK(24873) fork: took 1s for RSSFeeds. 01:45.37 FORK(24873) --- fork finished for 'RSSFeeds' --- 01:48.22 Chans: (ghostbot) in:#ghostscript 01:53.37 >>> join/#ghostscript marcosw (~marcosw@67.169.6.130) 02:03.54 Chans: (ghostbot) in:#ghostscript 02:09.16 ircCheck: possible lost in space; checking.Thu Mar 21 02:09:16 2013 02:09.16 >ghostbot< TEST 02:09.16 IRCTEST: Yes, we're alive. 02:14.48 >>> tsbtmn has signed off IRC (Ping timeout: 240 seconds) [#ghostscript] 02:15.58 FORK(828) --- fork starting for 'RSSFeeds', PID == 828, bot_pid == 1004 --- 02:15.59 FORK(828) !ERROR! cannot load my module: RSSFeeds 02:15.59 FORK(828) fork: took 1s for RSSFeeds. 02:15.59 FORK(828) --- fork finished for 'RSSFeeds' --- 02:16.46 >>> join/#ghostscript tsbtmn (~tsbtmn@unaffiliated/tsbtmn) 02:20.18 Chans: (ghostbot) in:#ghostscript 02:27.06 --- Saved uptime records. 02:28.50 >>> Fandekasp has signed off IRC (Ping timeout: 255 seconds) [#ghostscript] 02:30.53 >>> join/#ghostscript jghali_ (~jghali@ADijon-157-1-108-200.w90-56.abo.wanadoo.fr) 02:32.28 >>> jghali has signed off IRC (Ping timeout: 272 seconds) [#ghostscript] 02:36.20 Chans: (ghostbot) in:#ghostscript 02:38.54 >>> marcosw has signed off IRC (Quit: marcosw) [#ghostscript] 02:41.28 !WARN! PERL: readdir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 862. 02:41.28 !WARN! PERL: closedir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 869. 02:46.00 FORK(9790) --- fork starting for 'RSSFeeds', PID == 9790, bot_pid == 1004 --- 02:46.01 FORK(9790) !ERROR! cannot load my module: RSSFeeds 02:46.01 FORK(9790) fork: took 1s for RSSFeeds. 02:46.01 FORK(9790) --- fork finished for 'RSSFeeds' --- 02:52.22 Chans: (ghostbot) in:#ghostscript 03:13.02 ircCheck: possible lost in space; checking.Thu Mar 21 03:13:02 2013 03:13.02 >ghostbot< TEST 03:13.02 IRCTEST: Yes, we're alive. 03:16.18 FORK(16534) --- fork starting for 'RSSFeeds', PID == 16534, bot_pid == 1004 --- 03:16.19 FORK(16534) !ERROR! cannot load my module: RSSFeeds 03:16.19 FORK(16534) fork: took 1s for RSSFeeds. 03:16.19 FORK(16534) --- fork finished for 'RSSFeeds' --- 03:23.06 Chans: (ghostbot) in:#ghostscript 03:27.28 --- Saved uptime records. 03:39.08 Chans: (ghostbot) in:#ghostscript 03:47.02 FORK(14558) --- fork starting for 'RSSFeeds', PID == 14558, bot_pid == 1004 --- 03:47.03 FORK(14558) !ERROR! cannot load my module: RSSFeeds 03:47.03 FORK(14558) fork: took 1s for RSSFeeds. 03:47.03 FORK(14558) --- fork finished for 'RSSFeeds' --- 03:51.57 >>> join/#ghostscript tkamppeter_ (~till@p5DDB81FC.dip.t-dialin.net) 03:55.00 Chans: (ghostbot) in:#ghostscript 03:55.45 >>> tkamppeter has signed off IRC (Ping timeout: 260 seconds) [#ghostscript] 04:10.52 Chans: (ghostbot) in:#ghostscript 04:16.14 ircCheck: possible lost in space; checking.Thu Mar 21 04:16:14 2013 04:16.14 >ghostbot< TEST 04:16.14 IRCTEST: Yes, we're alive. 04:17.14 FORK(22398) --- fork starting for 'RSSFeeds', PID == 22398, bot_pid == 1004 --- 04:17.15 FORK(22398) !ERROR! cannot load my module: RSSFeeds 04:17.15 FORK(22398) fork: took 1s for RSSFeeds. 04:17.15 FORK(22398) --- fork finished for 'RSSFeeds' --- 04:26.54 Chans: (ghostbot) in:#ghostscript 04:27.50 --- Saved uptime records. 04:42.46 Chans: (ghostbot) in:#ghostscript 04:47.38 FORK(31445) --- fork starting for 'RSSFeeds', PID == 31445, bot_pid == 1004 --- 04:47.39 FORK(31445) !ERROR! cannot load my module: RSSFeeds 04:47.39 FORK(31445) fork: took 1s for RSSFeeds. 04:47.39 FORK(31445) --- fork finished for 'RSSFeeds' --- 05:17.42 FORK(10675) LOG: last message repeated 3 times 05:17.42 FORK(10675) --- fork starting for 'RSSFeeds', PID == 10675, bot_pid == 1004 --- 05:17.43 FORK(10675) !ERROR! cannot load my module: RSSFeeds 05:17.43 FORK(10675) fork: took 1s for RSSFeeds. 05:17.43 FORK(10675) --- fork finished for 'RSSFeeds' --- 05:19.32 LOG: last message repeated 3 times 05:19.32 ircCheck: possible lost in space; checking.Thu Mar 21 05:19:32 2013 05:19.32 >ghostbot< TEST 05:19.32 IRCTEST: Yes, we're alive. 05:27.56 --- Saved uptime records. 05:30.12 Chans: (ghostbot) in:#ghostscript 05:37.31 >>> mvrhel_laptop has signed off IRC (Ping timeout: 252 seconds) [#ghostscript] 05:46.44 Chans: (ghostbot) in:#ghostscript 05:48.10 FORK(14979) --- fork starting for 'RSSFeeds', PID == 14979, bot_pid == 1004 --- 05:48.11 FORK(14979) !ERROR! cannot load my module: RSSFeeds 05:48.11 FORK(14979) fork: took 1s for RSSFeeds. 05:48.11 FORK(14979) --- fork finished for 'RSSFeeds' --- 06:18.18 FORK(18721) --- fork starting for 'RSSFeeds', PID == 18721, bot_pid == 1004 --- 06:18.19 FORK(18721) !ERROR! cannot load my module: RSSFeeds 06:18.19 FORK(18721) fork: took 1s for RSSFeeds. 06:18.19 FORK(18721) --- fork finished for 'RSSFeeds' --- 06:23.56 ircCheck: possible lost in space; checking.Thu Mar 21 06:23:56 2013 06:23.56 >ghostbot< TEST 06:23.56 IRCTEST: Yes, we're alive. 06:28.16 --- Saved uptime records. 06:28.28 >>> join/#ghostscript oy (~oy@f055146116.adsl.alicedsl.de) 06:34.34 Chans: (ghostbot) in:#ghostscript 06:42.08 !WARN! PERL: readdir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 862. 06:42.08 !WARN! PERL: closedir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 869. 06:48.46 FORK(24768) --- fork starting for 'RSSFeeds', PID == 24768, bot_pid == 1004 --- 06:48.47 FORK(24768) !ERROR! cannot load my module: RSSFeeds 06:48.47 FORK(24768) fork: took 1s for RSSFeeds. 06:48.47 FORK(24768) --- fork finished for 'RSSFeeds' --- 06:50.56 Chans: (ghostbot) in:#ghostscript 07:19.14 FORK(29384) LOG: last message repeated 3 times 07:19.14 FORK(29384) --- fork starting for 'RSSFeeds', PID == 29384, bot_pid == 1004 --- 07:19.15 FORK(29384) !ERROR! cannot load my module: RSSFeeds 07:19.15 FORK(29384) fork: took 1s for RSSFeeds. 07:19.15 FORK(29384) --- fork finished for 'RSSFeeds' --- 07:20.24 LOG: last message repeated 3 times 07:20.24 >>> tkamppeter_ materializes into tkamppeter 07:22.30 Chans: (ghostbot) in:#ghostscript 07:27.48 ircCheck: possible lost in space; checking.Thu Mar 21 07:27:48 2013 07:27.48 >ghostbot< TEST 07:27.48 IRCTEST: Yes, we're alive. 07:28.32 >>> chrisl_away materializes into chrisl 07:29.02 --- Saved uptime records. 07:38.56 Chans: (ghostbot) in:#ghostscript 07:42.36 >>> join/#ghostscript umesh (3d5fead3@gateway/web/freenode/ip.61.95.234.211) 07:43.18 >>> umesh has signed off IRC (Client Quit) [#ghostscript] 07:49.36 FORK(405) --- fork starting for 'RSSFeeds', PID == 405, bot_pid == 1004 --- 07:49.37 FORK(405) !ERROR! cannot load my module: RSSFeeds 07:49.37 FORK(405) fork: took 1s for RSSFeeds. 07:49.37 FORK(405) --- fork finished for 'RSSFeeds' --- 07:52.39 >>> join/#ghostscript kens (~Miranda@87.113.116.18) 07:54.48 Chans: (ghostbot) in:#ghostscript 08:19.54 FORK(25885) --- fork starting for 'RSSFeeds', PID == 25885, bot_pid == 1004 --- 08:19.55 FORK(25885) !ERROR! cannot load my module: RSSFeeds 08:19.55 FORK(25885) fork: took 1s for RSSFeeds. 08:19.55 FORK(25885) --- fork finished for 'RSSFeeds' --- 08:29.34 --- Saved uptime records. 08:31.30 ircCheck: possible lost in space; checking.Thu Mar 21 08:31:30 2013 08:31.30 >ghostbot< TEST 08:31.30 IRCTEST: Yes, we're alive. 08:42.24 Chans: (ghostbot) in:#ghostscript 08:49.58 FORK(17328) --- fork starting for 'RSSFeeds', PID == 17328, bot_pid == 1004 --- 08:49.59 FORK(17328) !ERROR! cannot load my module: RSSFeeds 08:49.59 FORK(17328) fork: took 1s for RSSFeeds. 08:49.59 FORK(17328) --- fork finished for 'RSSFeeds' --- 09:20.26 FORK(15831) LOG: last message repeated 4 times 09:20.26 FORK(15831) --- fork starting for 'RSSFeeds', PID == 15831, bot_pid == 1004 --- 09:20.27 FORK(15831) !ERROR! cannot load my module: RSSFeeds 09:20.27 FORK(15831) fork: took 1s for RSSFeeds. 09:20.27 FORK(15831) --- fork finished for 'RSSFeeds' --- 09:30.10 LOG: last message repeated 4 times 09:30.10 --- Saved uptime records. 09:31.46 Chans: (ghostbot) in:#ghostscript 09:31.46 ircCheck: possible lost in space; checking.Thu Mar 21 09:31:46 2013 09:31.46 >ghostbot< TEST 09:31.46 IRCTEST: Yes, we're alive. 09:47.34 Chans: (ghostbot) in:#ghostscript 09:50.36 FORK(11909) --- fork starting for 'RSSFeeds', PID == 11909, bot_pid == 1004 --- 09:50.37 FORK(11909) !ERROR! cannot load my module: RSSFeeds 09:50.37 FORK(11909) fork: took 1s for RSSFeeds. 09:50.37 FORK(11909) --- fork finished for 'RSSFeeds' --- 10:05.26 >>> join/#ghostscript sojic (~sojic@95.180.254.49) 10:06.32 >>> jghali_ materializes into jghali 10:14.49 >>> join/#ghostscript tor8 (~tor@c-267571d5.04-50-6c756e10.cust.bredbandsbolaget.se) 10:19.34 Chans: (ghostbot) in:#ghostscript 10:20.54 FORK(7866) --- fork starting for 'RSSFeeds', PID == 7866, bot_pid == 1004 --- 10:20.55 FORK(7866) !ERROR! cannot load my module: RSSFeeds 10:20.55 FORK(7866) fork: took 1s for RSSFeeds. 10:20.55 FORK(7866) --- fork finished for 'RSSFeeds' --- 10:30.18 --- Saved uptime records. 10:32.13 >>> sojic has signed off IRC (Remote host closed the connection) [#ghostscript] 10:35.20 Chans: (ghostbot) in:#ghostscript 10:35.20 ircCheck: possible lost in space; checking.Thu Mar 21 10:35:20 2013 10:35.20 >ghostbot< TEST 10:35.20 IRCTEST: Yes, we're alive. 10:42.24 !WARN! PERL: readdir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 862. 10:42.24 !WARN! PERL: closedir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 869. 10:50.42 Chans: (ghostbot) in:#ghostscript 10:51.12 FORK(30419) --- fork starting for 'RSSFeeds', PID == 30419, bot_pid == 1004 --- 10:51.13 FORK(30419) !ERROR! cannot load my module: RSSFeeds 10:51.13 FORK(30419) fork: took 1s for RSSFeeds. 10:51.13 FORK(30419) --- fork finished for 'RSSFeeds' --- 10:59.05 >>> join/#ghostscript sojic (~sojic@95.180.254.49) 11:04.23 >>> sojic has signed off IRC (Remote host closed the connection) [#ghostscript] 11:07.04 Chans: (ghostbot) in:#ghostscript 11:08.57 >>> join/#ghostscript paulgardiner (~chatzilla@smtp.glidos.net) 11:20.26 >>> join/#ghostscript marcosw (~marcosw@67.169.6.130) 11:21.26 FORK(19429) --- fork starting for 'RSSFeeds', PID == 19429, bot_pid == 1004 --- 11:21.27 FORK(19429) !ERROR! cannot load my module: RSSFeeds 11:21.27 FORK(19429) fork: took 1s for RSSFeeds. 11:21.27 FORK(19429) --- fork finished for 'RSSFeeds' --- 11:23.12 Chans: (ghostbot) in:#ghostscript 11:30.30 --- Saved uptime records. 11:37.47 >>> marcosw has signed off IRC (Quit: marcosw) [#ghostscript] 11:38.47 Chans: (ghostbot) in:#ghostscript 11:38.47 ircCheck: possible lost in space; checking.Thu Mar 21 11:38:47 2013 11:38.47 >ghostbot< TEST 11:38.47 IRCTEST: Yes, we're alive. 11:51.54 FORK(21881) --- fork starting for 'RSSFeeds', PID == 21881, bot_pid == 1004 --- 11:51.55 FORK(21881) !ERROR! cannot load my module: RSSFeeds 11:51.55 FORK(21881) fork: took 1s for RSSFeeds. 11:51.55 FORK(21881) --- fork finished for 'RSSFeeds' --- 11:54.10 Chans: (ghostbot) in:#ghostscript 12:02.47 >>> join/#ghostscript sojic (~sojic@95.180.252.83) 12:03.17 >>> join/#ghostscript sojic_ (~sojic@92.55.124.20) 12:07.40 >>> sojic has signed off IRC (Ping timeout: 260 seconds) [#ghostscript] 12:10.49 >>> sojic_ has signed off IRC (Ping timeout: 258 seconds) [#ghostscript] 12:10.59 Chans: (ghostbot) in:#ghostscript 12:22.28 FORK(31340) --- fork starting for 'RSSFeeds', PID == 31340, bot_pid == 1004 --- 12:22.29 FORK(31340) !ERROR! cannot load my module: RSSFeeds 12:22.29 FORK(31340) fork: took 1s for RSSFeeds. 12:22.29 FORK(31340) --- fork finished for 'RSSFeeds' --- 12:27.47 Robin_Watts: ping 12:30.56 --- Saved uptime records. 12:31.02 Seen: Flushed 1 entries. 12:32.59 fascinating bug fix chrisl, congratulations on that one 12:33.20 * kens/#ghostscript lunches 12:42.42 Chans: (ghostbot) in:#ghostscript 12:52.36 FORK(29409) --- fork starting for 'RSSFeeds', PID == 29409, bot_pid == 1004 --- 12:52.37 FORK(29409) !ERROR! cannot load my module: RSSFeeds 12:52.37 FORK(29409) fork: took 1s for RSSFeeds. 12:52.37 FORK(29409) --- fork finished for 'RSSFeeds' --- 13:22.37 LOG: last message repeated 4 times 13:22.37 >>> kens has signed off IRC (Read error: Connection reset by peer) [#ghostscript] 13:22.57 FORK(25838) --- fork starting for 'RSSFeeds', PID == 25838, bot_pid == 1004 --- 13:22.58 FORK(25838) !ERROR! cannot load my module: RSSFeeds 13:22.58 FORK(25838) fork: took 1s for RSSFeeds. 13:22.58 FORK(25838) --- fork finished for 'RSSFeeds' --- 13:24.45 chrisl: pong 13:25.03 >>> join/#ghostscript kens (~Miranda@87.113.116.18) 13:25.08 >>> part/#ghostscript kyak (~kyak@unaffiliated/kyak) 13:27.10 Alas, chrisl's fix doesn't explain the valgrind warning I'm seeing. 13:27.21 * Robin_Watts/#ghostscript grabs lunch. back in a bit. 13:30.38 Chans: (ghostbot) in:#ghostscript 13:31.08 Seen: Flushed 2 entries. 13:31.08 --- Saved uptime records. 13:44.44 chrisl:nice - but watch out you are going to own the memory code if you keep this up. 13:46.50 Chans: (ghostbot) in:#ghostscript 13:50.20 jeez there is some bug in gnu indent that put a blank line after every local variable declaration, I used the same parameters in C-style.htm, must be an introduced problem. 13:53.48 FORK(32005) --- fork starting for 'RSSFeeds', PID == 32005, bot_pid == 1004 --- 13:53.49 FORK(32005) !ERROR! cannot load my module: RSSFeeds 13:53.49 FORK(32005) fork: took 1s for RSSFeeds. 13:53.49 FORK(32005) --- fork finished for 'RSSFeeds' --- 14:03.12 Chans: (ghostbot) in:#ghostscript 14:06.12 >>> paulgardiner has signed off IRC (Ping timeout: 258 seconds) [#ghostscript] 14:07.26 >>> join/#ghostscript paulgardiner (~chatzilla@smtp.glidos.net) 14:18.15 Robin_Watts: so where are we ith the ubuntu discussions? 14:18.41 tor8: No replies as yet. Waiting for the meeting this evening. 14:19.21 Chans: (ghostbot) in:#ghostscript 14:20.58 Robin_Watts: can you send an email to tech about the meeting time tonight or if you want I can do it. Others may be interested. 14:21.39 henrys: 4:30EST tonight in #ubuntu-touch-meeting. I'll send an email. 14:21.58 should be EDT 14:24.17 FORK(1003) --- fork starting for 'RSSFeeds', PID == 1003, bot_pid == 1004 --- 14:24.18 FORK(1003) !ERROR! cannot load my module: RSSFeeds 14:24.18 FORK(1003) fork: took 2s for RSSFeeds. 14:24.18 FORK(1003) --- fork finished for 'RSSFeeds' --- 14:29.53 Robin_Watts: what I was going to say was that now I've cleared up the three GC problems I acquired at the meeting, I can look at the valgrind warnings if you want shot of them 14:30.19 Let me continue to look for a bit. If I don't get anywhere I'll hand them off. 14:30.28 'Kay 14:30.37 y 14:30.59 henrys: I don't mind doing GC problems, as long there isn't much time pressure on them........ 14:31.10 --- Saved uptime records. 14:31.20 Seen: Flushed 4 entries. 14:34.09 chrisl, Robin_Watts:I've been playing with the valgrind gdb server really nice, basically run gdb and it breaks on a valgrind error, a little more flexible than the previous setup where you could just invoke gdb when a problem happens 14:34.28 henrys: ooh, that does sound nice. 14:34.54 henrys: that sounds interesting, I've been meaning to look at it, but never got around to it 14:35.14 henrys: Any useful links on how to install/use it ? 14:35.27 let me find it. 14:35.27 Chans: (ghostbot) in:#ghostscript 14:36.08 http://valgrind.org/docs/manual/manual-core-adv.html#manual-core-adv.gdbserver 14:39.02 henrys: Interesting. If that works with ddd, so much the better. 14:39.32 it work with emacs which uses --annotate option to communicate with gdb don't know about ddd 14:39.45 Robin_Watts: all you should need to do is enter the gdb command in the gdb prompt window in ddd 14:40.14 * Robin_Watts/#ghostscript should look into emacs and gdb. 14:40.31 * chrisl/#ghostscript shudders at the very thought of emacs...... 14:40.51 leak: 1 nuh{} items deleted; now have 30 14:41.52 Long ago I used to debug in a terminal - but I can't imagine doing it now. sort of like going back to a modem or something. 14:42.30 !WARN! PERL: readdir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 862. 14:42.30 !WARN! PERL: closedir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 869. 14:42.54 Yes, but emacs? For something so entrenched in Unix mythology it always seemed totally against the unix philosophy to me 14:43.08 chrisl:at my old company most folks debugged in emacs but used vi or other editiors 14:43.12 editors 14:44.43 i.e. debugging in emacs doesn't require much emacs foo. 14:44.57 vi. The hairshirt of computing for 30 years. 14:45.11 and I find ddd aesthetically revolting 14:45.23 * Robin_Watts/#ghostscript mostly uses gdb in a terminal. 14:45.33 Motif was never the prettiest toolkit! 14:45.36 cos ddd is grim. 14:46.10 Robin_Watts: It is hard for me to imagine you wouldn't see emacs a big improvement over that. 14:47.59 Whilst ddd is indeed grim, I find it less so than cgdb...... 14:48.23 >>> join/#ghostscript Houl (~Parmi@unaffiliated/houl) 14:48.40 * kens/#ghostscript much prefers ddd to gdb 14:50.41 (gswin32c) I want to merge several pdf files into one ... keeping the exact quality of images (mostly JPGs, a few PNGs) .. how to do that? 14:51.11 Depends what you mean, the short answer is don't use pdftk 14:51.18 gdb is a great debugger, unfortunately Xcode is the only decent client IDE 14:51.20 is don't, use pdftk 14:51.34 Chans: (ghostbot) in:#ghostscript 14:51.51 henrys: does Xcode let you access the gdb command line? 14:52.00 chrisl:yes 14:52.03 henrys: That's damning with faint praise. Xcode is unusable. 14:52.33 kens: so far I've tried gswin32c -dNOPAUSE -sDEVICE=pdfwrite -sOUTPUTFILE=merged.pdf -dBATCH -dPDFSETTINGS=/prepress input1.pdf input2.pdf 14:52.36 it's still compressing 14:53.02 (I don't yet understand all given options) 14:53.06 Houl: No tweaks you give to gs will prevent it uncompressing and recompressing images. 14:53.19 There is no mechanism for passing images through unchanged. 14:53.24 Robin_Watts: are there any tweaks? 14:53.34 Robin_Watts: hmm 14:53.53 so the answer is: don't use ghostscript 14:53.58 ? 14:54.00 yes, use pdftk 14:54.07 Houl: As kens said earlier, yes. 14:54.27 FORK(20932) --- fork starting for 'RSSFeeds', PID == 20932, bot_pid == 1004 --- 14:54.28 FORK(20932) !ERROR! cannot load my module: RSSFeeds 14:54.28 FORK(20932) fork: took 1s for RSSFeeds. 14:54.28 FORK(20932) --- fork finished for 'RSSFeeds' --- 14:54.41 ok, thanks. 14:55.11 Robin_Watts:I didn't look very carefully but last I checked it was similar to M$ debugging. Why is it unusable? 14:55.41 I *really* dislike the MS debugger - this is all about what you're used to, though 14:55.51 henrys: Everything about Xcode is horrible. 14:56.12 Because it comes from Apple? 14:56.47 You know the past 30 years of shared computing experience that influences how your expectations of things should work? the names you use for things? the way of organising stuff? Well, fuck all that, we're Apple, and we're going to be different. 14:59.23 Robin_Watts: I feel similarly about MS - although Apple seem to have more over a shorter period, on that front 14:59.46 Robin_Watts: of late it seems to be working for Apple. 15:00.00 chrisl: I was reluctant to embrace VS, but actually, it behaves pretty much exactly as I'd want it to. 15:00.29 Admittedly, that might be because it's been my debugging platform of choice for years, but I never remember any "WTF?" moments with it. 15:00.41 Robin_Watts: like I said, it's just what you're used to - I'd probably get on okay with VS if I used it regularly 15:01.32 I'd probably find Xcode OK if I could only persuade it just to start the damn thing I want it to with the args I want without it having to be wrapped in some horrible Xcode project. 15:04.08 https://sourceforge.net/projects/ghostscript/?source=directory: That points to svn.ghostscript.com and the license is GPLv2 there. 15:04.18 In VS, I find having command line options for the target exe buried in the project options unspeakably annoying - largely because gs is so command-line-centric 15:04.38 I'd change it, but I'm not an admin. chris, giles, ray and miles are. 15:05.04 I need to work out *how* you change it - it just finished upgrading the project..... 15:05.16 yeah, that's why I was looking :) 15:05.46 Is there anything visible from the "outside" as a result of the upgrade? 15:06.25 We have 2 thumbs down reviews on sourceforge. The first says "Excellent application! Nice and easy to use." and the second says "good app, always use it for my postscript files. thank you, guys!" 15:06.38 chrisl: nafc, sorry. 15:06.56 ;-) License should be right now 15:07.11 license is indeed right. 15:07.26 Chans: (ghostbot) in:#ghostscript 15:08.08 Huh, the current version is listed as 9.05..... 15:09.21 >>> join/#ghostscript docampo (be137acc@gateway/web/freenode/ip.190.19.122.204) 15:10.45 Hi, anybody available to give me a hand on Android? 15:11.44 >>> join/#ghostscript marcosw (~marcosw@69-170-60-203.static-ip.telepacific.net) 15:12.16 docampo: Go for it. 15:15.18 Ok, here is the situation: On the muPDF Activity , I am implementing onConfigurationChange, to not "re-create" the activity when switching between landscape/portrait 15:16.26 I this method, I do the following, in order to refresh the view: 15:16.35 pageAdapter.notifyDataSetChanged(); 15:16.41 mDocView.setAdapter(pageAdapter); 15:17.48 The view is actually being refreshed, but for some reason, the render is not complete. Say, 70% of the page is rendered as it should, and the rest is rendered but as it would be in "low quality" 15:18.07 I don't know if I am being clear. 15:18.42 docampo: We render in 2 phases; first a scaled view of the cached bitmap, then a 'high quality' redraw that should make everything sharp. 15:18.57 Is it possible that the high quality redraw is being done with the old orientation? 15:19.22 so that when that completes what you see as being properly redrawn is actually the intersection between the old and the new visible areas? 15:19.25 That could be possible. 15:19.37 That would be about 70% of the screen, I guess. 15:19.51 Yes, I think that could be the situation. How could I solve this? 15:20.13 So, I'm guessing that the high quality redraw is being kicked off before the details of the screen size change have made it down that far. 15:20.50 I think you need to ensure that the details of the screen size change get passed down before starting the HQ redraw :) 15:22.19 It's been way too long since I coded this stuff (and paulgardiner has changed the structure of the app since then) for me to be able to give you a clearer answer than that off the top of my head. 15:22.21 How can I ensure that? I think that "getPageSize" is being called, and returning the correct size. Is there any other thing that I should take into account? 15:23.26 And, when the HQ redraw start? 15:23.36 Chans: (ghostbot) in:#ghostscript 15:24.21 getPageSize is to do with the document page size. That won't change when you rotate the device. 15:24.37 Its the size of the screen to which we are redrawing that needs to change. 15:25.08 FORK(19911) --- fork starting for 'RSSFeeds', PID == 19911, bot_pid == 1004 --- 15:25.09 FORK(19911) !ERROR! cannot load my module: RSSFeeds 15:25.09 FORK(19911) fork: took 1s for RSSFeeds. 15:25.09 FORK(19911) --- fork finished for 'RSSFeeds' --- 15:25.20 Ah, got it. But I am not sure I understand how can I control that. 15:25.35 drawPage is the thing that does the redraw. 15:25.49 docampo: in PageView, the ImageView called mPatch has a size dependent on the screen size. Those would need to be recreated. 15:27.07 Thanks, Robin_Watts and paulgardiner, I'll take a look. 15:27.16 I say those because each PageView will have a subview called mPatch. 15:27.46 docampo: Can I ask why you are wanting to stop the activity being restarted on a rotate? 15:27.50 There could be many values within ReadView that need recalculating. It's difficult to predict. 15:27.56 I wasn't aware that was even an option :( 15:29.08 I have to do some stuff when rotation change. Also, there is some stuff on the onCreate method that shouldn't happen any time the user rotates the device. 15:29.09 >>> kens has signed off IRC (Read error: Connection reset by peer) [#ghostscript] 15:29.37 >>> join/#ghostscript kens (~Miranda@87.113.116.18) 15:29.40 docampo: Such as? 15:29.41 BUT, I could figure out a way to re-create the view and avoid doing that stuff I need to do just once. 15:30.06 Oh, right, *your* app has stuff that mustn't be done repeatedly, sorry. 15:30.18 yes 15:31.28 --- Saved uptime records. 15:31.38 Seen: Flushed 7 entries. 15:32.26 This stuff, on a "low range" device, was throwing an OutOfMemoryError 15:38.24 >>> join/#ghostscript mvrhel_laptop (~chatzilla@c-24-17-196-27.hsd1.wa.comcast.net) 15:38.41 could it be that onMeasure is not being called? Or something related to it? 15:39.20 Chans: (ghostbot) in:#ghostscript 15:39.59 You may need to trigger a layout, although I'd have expected the system to do that for you. 15:41.01 paulgardiner: If he's trapping the rotation event, maybe not? 15:41.33 Are you going to end up in the situation where the top bar doesn't move? 15:43.09 I'm not following you, which top bar? 15:47.42 In the file picker view, you can still see androids top bar. 15:53.08 chrisl: OK. I'm going to run screaming from this valgrind problem, at least for now. 15:53.42 Robin_Watts: okay, can you give me a file and command line to reproduce the problem exactly? 15:54.14 valgrind --db-attach=yes --track-origins=yes debugbin/gs -sDEVICE=tiffscaled -dDownScaleFactor=3 -r600 -o out.tif /mnt/hgfs/artifex/ghostpcl/tests_private/comparefiles/Bug690025a.pdf 15:54.34 Just to let you know, I think I got it fixed: it was that on the configChanges properties, I was managing to "screenSize". I needed to do this on the past because some Android version requires this to fire onConfigurationChange. 15:54.49 But for now, it seem to be working. 15:55.07 docampo: OK. fair enough. 15:55.17 Can I ask what sort of app you are developing? 15:55.17 FORK(7246) --- fork starting for 'RSSFeeds', PID == 7246, bot_pid == 1004 --- 15:55.18 FORK(7246) !ERROR! cannot load my module: RSSFeeds 15:55.18 FORK(7246) fork: took 1s for RSSFeeds. 15:55.18 FORK(7246) --- fork finished for 'RSSFeeds' --- 15:55.53 Robin_Watts: Cool, I'll look at it tomorrow. FWIW, I think there is a fundamental issue in that we don't seem to initialize the gc flags for new "st_-type" allocations 15:56.11 >>> marcosw has signed off IRC (Quit: marcosw) [#ghostscript] 15:56.11 Chans: (ghostbot) in:#ghostscript 15:56.39 chrisl: I've added various memsets to try forcing flags to 0 for objects, and that seemed to shift the problem slightly. 15:56.58 The current one I'm seeing is a block of bytes. 15:57.32 >>> join/#ghostscript ray_laptop (~chatzilla@rrcs-64-183-45-163.west.biz.rr.com) 15:58.27 Robin_Watts: yes, the one I looked at I got down to two warnings, and the valgrind's "track origins" output was buggered.... the line it pointed to didn't have an allocation nor a variable declaration (in fact, I think it was white space.....) 16:00.14 >>> join/#ghostscript gandaro (~gandaro@wikipedia/Gorlingor) 16:03.30 tor8: we're not automatically pulling commits across from ghostpdl to the jbig2dec repo - should we be doing so, or is there a reason you left it? 16:04.33 chrisl: I want to add my admiration for digging out that obscure path memory issue. Any tips on what techniques you use ? I tend to get stuck using the methods I've always used and you may have a different approach that might help. 16:04.46 >>> gandaro has signed off IRC (Client Quit) [#ghostscript] 16:07.26 >>> join/#ghostscript gandaro (~gandaro@wikipedia/Gorlingor) 16:11.17 ray_laptop: thanks - I have to admit, that last one was a b*stard! 16:12.28 Chans: (ghostbot) in:#ghostscript 16:13.08 Robin_Watts: BTW, the test to detect how often the pattern optimization was used came up with over 2000 "hits". Even allowing for multiple hits due to the same test file, just different devices, I decided to leave it in 16:13.32 ray_laptop: Seems sensible. 16:13.55 Robin_Watts: I found a way to 'revert' the case down to devn_fill_rectangle 16:15.19 ray_laptop: As for techniques, I don't think I have any special tricks - I have a surprisingly good memory for things that interest me. The thing I find helps the most is to get clear in your head the layout of objects and their contents in memory - I don't mean the entire memory layout, but where the headers are, and the various mark/reloc variables. Then you can quickly inspect their values for a given object. 16:16.35 chrisl: I have a crontab job that should pull across daily 16:17.18 tor8: I only see a cron entry for updating the mupdf third party libs 16:18.42 ray_laptop: From a psychological perspective, I also like to keep reminding myself that there's nothing "magic" in there - it just seems that way because of all the crazy macros. What the garbage collector does is really very simple, it's the macros and the sheer number of objects that make it difficult to decipher. 16:20.30 ray_laptop: does the Visual Studio debugger expand macros for you? 16:21.05 chrisl: The problem I most often find is that I want to track what happens to a given object back in time. 16:21.28 chrisl: no, but it has a "Go to Definition" right mouse action 16:21.28 i.e. I want to find out when a given object was allocated, or when it was reloced there etc. 16:22.37 Robin_Watts: I tend to work the other way - I work out what type of object it is, find which instance causes the problem, then work *forward* from the creation 16:22.39 darn. have to reboot. Windoze is confused and thinks a file that doesn't even exist is still locked 16:23.01 ray_laptop: handle ? 16:23.29 Bah. There is a sysinternals tool for closing handles. 16:23.32 I use conditional breakpoints (or sometime add in C code) to spot the enumeration or relocation of a certain address. 16:24.04 ray_laptop: gdb has a "macro expand" command, which completely expands a macro for you - makes things easier 16:24.07 gdb is much nicer than windows because the addresses are always different. They stay the same in repeated gdb runs 16:24.19 ray_laptop: In procexp you can "Find" a handle. 16:24.29 chrisl: what's the gdb command ? 16:24.31 Then you can close it. 16:24.44 ray_laptop: macro expand 16:24.57 too obvious. Thanks, chrisl 16:25.13 obviously you have to give it the parameters, too 16:25.33 FORK(26879) --- fork starting for 'RSSFeeds', PID == 26879, bot_pid == 1004 --- 16:25.34 FORK(26879) !ERROR! cannot load my module: RSSFeeds 16:25.34 FORK(26879) fork: took 1s for RSSFeeds. 16:25.34 FORK(26879) --- fork finished for 'RSSFeeds' --- 16:28.10 Chans: (ghostbot) in:#ghostscript 16:29.39 Robin_Watts: you can work "backwards" tracing an object by judicious use of conditional break points in the enum_ptrs and reloc_ptrs functions 16:31.10 ray_laptop: so, for example: "macro expand ref_assign(a,b)" gives "expands to: (*(a) = *(b))" 16:31.16 chrisl: For non GC stuff, I use memento, as that labels each block with a sequence number, so it's easy to follow that. 16:31.43 Robin_Watts: right. That's why a debug chunk allocator has that feature as well. 16:31.43 --- Saved uptime records. 16:31.58 non GC stuff is mch easier 16:32.08 Seen: Flushed 6 entries. 16:32.11 I daresay there is a set of -Z flags that will output all the details of allocations/relocs etc, so I could trace it through that, but.... 16:32.45 Robin_Watts: exactly. Unless it's a VERY simple case, the amount of debug is daunting. 16:32.57 Robin_Watts: yes, that is a great help. I have thought about adding something like that to the GC data for debug builds - not sure how it would work, though. 16:33.26 but I sometimes set the gs_debug[] elements after breakpoints to cut it down 16:34.13 chrisl: can we just stick an "int sequence" into obj_header_data_t ? 16:34.28 chrisl: that's a good idea. An object sequence number would help track objects 16:34.55 The IGC_PTR_STABILITY_CHECK stuff seems to put extra stuff in there. 16:35.00 Robin_Watts: we'd have to make sure that it got copied to new locations when we did a reloc - that was the bit I wasn't clear on 16:35.09 why didn't I think of that 20 years ago ? 16:35.55 chrisl: presumably either it will happen magically, or hunting for IGC_PTR_STABILITY_CHECK will find code that copies that bit ? 16:35.59 chrisl: see -- that's why I wanted to chat about how you do things. Helps me unfreeze the gray cells 16:37.20 Robin_Watts: I don't think it will happen magically, because I don't think we copy the header contents around, but maybe the ptr stability stuff would. I don't think it's a huge deal, I just never had the chance to sit down and investigate properly. 16:38.15 >>> ray_laptop has signed off IRC (Remote host closed the connection) [#ghostscript] 16:38.25 The other issue is Postscript refs - they might need special handling 16:41.07 Robin_Watts: Actually, I think one thing that made me cautious about it was that I was concerned that the might be places in the code that assume the header is a given size, and that would be a pain (as well as *really* bad) 16:41.36 chrisl: Right, but the IGC_PTR_STABILITY_CHECK would seem to indicate that that isn't the case. 16:41.58 Robin_Watts: I admire your optimism...... 16:43.52 Chans: (ghostbot) in:#ghostscript 16:44.16 My optimism is essential. If I learnt from mistakes, I'd never attempt anything... 16:46.11 It does look eminently doable - I'll do it as a mini-project, if we think it would be useful - and it seems we do. 16:46.19 >>> join/#ghostscript ray_laptop (~chatzilla@rrcs-64-183-45-163.west.biz.rr.com) 16:47.07 chrisl: It sounds useful to me. 16:47.47 I'll make a start tomorrow - if we're right, it shouldn't take long at all. If we're wrong....... 16:49.19 Robin_Watts: I'd thought of just simple, incrementing id - is that what mememto does? 16:49.31 chrisl: Exactly. 16:49.37 chrisl: that's what the chunk allocator does 16:49.41 Good, I like simple :-) 16:50.27 Memento has functions you can call from the debugger to tell it to stop when we reach certain allocations, or to find a given block by id number etc too, but that's just icing on the cake. 16:51.13 Memento increases the id on frees too, so the number isn't "how many allocations have we done", it's "how many allocation events have there been" 16:51.53 Hmm, that could be harder because of the way GC "frees" memory, but we'll see 16:52.48 I think just being easier to identify that "this is the object of interest" will be a big benefit 16:53.54 chrisl: Indeed, it may not be appropriate here. 16:54.29 Except maybe to have all gcs count as 'an allocation event'. 16:55.17 Actually, it must be easy enough because -Z@ fills gc'ed memory with a different pattern to freed memory 16:55.28 It'd be nice if the object numbers were mentioned in the debugging, but that's a tedious task. I could help with that if required. 16:55.38 FORK(23507) --- fork starting for 'RSSFeeds', PID == 23507, bot_pid == 1004 --- 16:55.39 FORK(23507) !ERROR! cannot load my module: RSSFeeds 16:55.39 FORK(23507) fork: took 1s for RSSFeeds. 16:55.39 FORK(23507) --- fork finished for 'RSSFeeds' --- 16:56.06 Robin_Watts: once the infrastructure is in place, it should be easy enough to tweak as we work with it 16:56.12 yeah. 16:56.54 paulgardiner: http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=bfb6ba336570817182082ce3badd5f80863e01c4 16:57.16 I'd do it now, but I have to finish shortly - squash training, and then a league match - what was I thinking?!?! 16:57.29 ouch. 16:58.10 Robin_Watts: just looking 16:58.21 :-) 16:58.34 If I'm playing well, the training will help - if I'm playing badly, I'm buggered either way 17:00.14 eek. 17:00.34 Chans: (ghostbot) in:#ghostscript 17:00.36 paulgardiner: Stupid typo in that commit. 17:00.49 return 0 ? 17:01.39 yeah. 17:03.31 Ah! I'm a little worried about stalling the UI. I think countPages is something we otherwise do only in the background. 17:03.53 paulgardiner: OK... 17:04.10 We seem to do it in various different places. 17:05.57 >>> join/#ghostscript marcosw (~marcosw@eduroam-248-199.ucsc.edu) 17:06.54 chrisl: the mirror-thirdparty.sh script also does jbig2dec 17:11.07 Yep, that's fine. 17:13.43 tor8: okay, yes I see. It seems my local jbig2dec repo is borked - it claims to be up to date, but the last commit is from ~6 months ago. A fresh clone is correct - sorry about that. 17:14.27 bbiaw 17:14.34 chrisl: great! I was worried the scripts were broken... 17:15.29 tor8: no definitely my repo 17:15.31 tor8: At some point, either you or paulgardiner needs to look over the reflow branch. 17:16.31 I'm off out tonight, and need to stop soon, but I could take a look tomorrow 17:17.09 paulgardiner: I was imagining that tor8 would like to look himself, but the more eyes the better. 17:17.52 Chans: (ghostbot) in:#ghostscript 17:18.11 Yeah, both having a look sounds good. 17:18.27 Robin_Watts: I will take a look tomorrow as well. I'd like to get some rudimentary BiDi/RTL stuff in there and that should be base off your new datastructures. 17:21.39 >>> chrisl materializes into chrisl_away 17:26.27 FORK(17343) --- fork starting for 'RSSFeeds', PID == 17343, bot_pid == 1004 --- 17:26.28 FORK(17343) !ERROR! cannot load my module: RSSFeeds 17:26.28 FORK(17343) fork: took 2s for RSSFeeds. 17:26.28 FORK(17343) --- fork finished for 'RSSFeeds' --- 17:32.19 --- Saved uptime records. 17:32.29 Seen: Flushed 6 entries. 17:34.04 Chans: (ghostbot) in:#ghostscript 17:35.40 ray_laptop: ping 17:39.28 >>> Houl has signed off IRC (Quit: weil das Wetter so schön ist) [#ghostscript] 17:39.35 OK goodnight everyone 17:39.58 >>> kens has signed off IRC (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) [#ghostscript] 17:40.33 marcosw: sorry -- was on the phone 17:41.27 I may have figured it out on my own. GIve me a sec... 17:49.45 ray_laptop: I was trying to duplicate a customer problem and build without the pdfwrite device, turns out you also have to remove the ps2write device (I understand why this is but it's still kind of odd, explicitly removing a device and still having it available). 17:50.25 Chans: (ghostbot) in:#ghostscript 17:54.19 marcosw: while the files get included, I don't think the pdfwrite device should be on the devices list -- Note that you have to do a 'clean' before rebuilding sometimes to get rid of devices since the .dev files will still be found by genconf 17:55.16 I tripped over that because I still had the 'pswrite' device on the list, but then the objects weren't included so I got an 'unresolved' link error 17:56.45 FORK(16848) --- fork starting for 'RSSFeeds', PID == 16848, bot_pid == 1004 --- 17:56.46 FORK(16848) !ERROR! cannot load my module: RSSFeeds 17:56.46 FORK(16848) fork: took 2s for RSSFeeds. 17:56.46 FORK(16848) --- fork finished for 'RSSFeeds' --- 18:02.46 >>> join/#ghostscript vtorri (~vtorri@enlightenment/developer/vtorri) 18:02.56 tor8, ping 18:04.51 tor8: better version of that timing commit: http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=a291ddac0d6b7923cdcbd6644bdd89dd315b6921 18:04.55 vtorri: hi. 18:05.00 Robin_Watts, hey 18:05.08 You may have missed tor8 for the night. can I help? 18:05.35 Robin_Watts, i wanted to mention a very minor warning to fix in fitz 18:05.55 Robin_Watts, ./src/modules/pdf/mupdf-1.2/fitz/fitz.h:3068:1: warning: function declaration isn't a prototype 18:06.04 just add void 18:06.24 Chans: (ghostbot) in:#ghostscript 18:07.08 tor8: also http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=c92a51cb111f997c94ec48e20cce90ca27073b55 18:07.42 vtorri: What function declaration is that? 18:07.58 int fz_javascript_supported ? 18:08.09 yes 18:08.48 it's the only function with no parameter which does not have void 18:09.16 vtorri, tor8: And so: http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=a621800cec7f46c3d3fe34ce7347257110935ea3 18:09.21 vtorri: Thanks. 18:09.41 Robin_Watts, check the definition of the function too 18:11.17 vtorri, tor8:http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=afd5d5dd443a9f37aff1e48f96136ab2e11213bb 18:11.30 vtorri, tor8: http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=afd5d5dd443a9f37aff1e48f96136ab2e11213bb 18:11.32 Thanks. 18:11.39 you're welcome 18:12.00 That'll hit the main repo as soon as tor8 OK's it. 18:12.09 ok 18:12.36 i have a bunch of gcc warning flags :) 18:14.32 aren't we really at a point where we should get away from the 'gatekeeper' model for mupdf git -- we now have cluster regression for mupdf available and working without a gatekeeper on Ghostscript has worked fine for years 18:15.31 plus it would keep the mupdf commits from getting batched up and disperse the commit regression runs and the emails for the commits and the regressions 18:16.37 ray_laptop: No. It's not a 'gatekeeper' model, it's a 'code review' one. 18:16.56 and I'd argue that code reviews would help on gs too. 18:16.58 still it batches thing up 18:17.26 ray_laptop: Right, but a mupdf commit takes 5 minutes to run through on the cluster, and the user jobs take priority. 18:17.32 Robin_Watts: on gs we all get commits and look over the changes after the fact. It's more efficient 18:17.57 ray_laptop: On gs we get commits, followed by commits to fix the breakages. 18:19.00 If people do a private regression run, breakages shouldn't happen. I thought that was our modus operandi 18:19.04 on mupdf we get code reviews, so the code tends to be in nicer shape when it goes in. How many times have you ever shown your code to someone only for them to look at it and say "wouldn't it be a bit nicer if you'd done it like that?" 18:19.34 never on a mupdf commit ;-) 18:19.38 (maybe your code is perfect - I know that mine benefits from someone else casting their eyes over it) 18:19.47 (oops missed the :) there) 18:20.44 Code reviews work well for mupdf. I'd personally like to see us try them on gs, but I raised that idea years ago, and got smacked down, so so be it. 18:21.17 I sometimes ask a particular person (someone that I know is familiar with an area) as I am working on a change, but I'm not sure that we could have just one person review all gs commits 18:21.31 ray_laptop: Right, and we're not in that position for mupdf. 18:21.35 yeah I really don't think the gs review after commit model works at all. Everyone ignores the commits AFAICT, there is no review. 18:21.55 Chans: (ghostbot) in:#ghostscript 18:22.11 The rule is that every commit that hits the mupdf golden git repo should have been looked at by at least 2 developers (the original author, and one other) 18:22.18 Robin_Watts, i guess that you don't care about unused parameters, right ? 18:22.21 we had tried forcing 'ownership' of certain aspects to individuals, but that finally fell apart when people needed to touch too many areas to 18:22.57 ah some chat on ubuntu irc 18:23.11 Robin_Watts: do preliminary commits get bounced often, then ? 18:23.52 For some areas of code there will inevitably be cases where only one person really understands the code (say, in gs, clist changes may not make much change to anyeone other than ray), but even dumb users can spot silly typos etc. 18:24.10 ray_laptop: It's extremely typical for commits to be tweaked slightly, yes. 18:24.30 Either for reasons of style, or for silly typos, or for people spotting corner cases. 18:24.49 Also, it serves to ensure that all the knowledge about particular areas isn't completely embedded in just one developers head. 18:25.18 henrys: Meetings are going on all day there. Ours isn't schedules for 2 hours, right? 18:25.29 Currently it's the calculator app meeting. 18:25.44 well, we have LOTS of spelling errors in comments, but for most of those, it was the code 'owner' that made the errors and that person would accept no critique 18:26.34 is all the discussion on #ubuntu, or are there separate channels ? 18:27.15 Robin_Watts: well I watch for a while earlier and it was completely dead - now lots of activity, I know it isn't relevent to us 18:27.26 FORK(21998) --- fork starting for 'RSSFeeds', PID == 21998, bot_pid == 1004 --- 18:27.27 FORK(21998) !ERROR! cannot load my module: RSSFeeds 18:27.27 FORK(21998) fork: took 2s for RSSFeeds. 18:27.27 FORK(21998) --- fork finished for 'RSSFeeds' --- 18:28.03 ray_laptop: I'm currently lurking on #ubuntu-desktop, #ubuntu-touch and #ubuntu-touch-meeting 18:28.11 ray_laptop: Robin_Watts sent out email about tuning in. 18:28.21 The latter is where the meeting is due to take place. 18:28.40 I worry that if we all turn up, we'll drown out the devs, but... :) 18:30.33 i have a problem with the jbig2dec included in mupdf 18:30.47 config_types.h is requires but i can't find it 18:31.00 is it generated in a Makefile ? 18:31.38 vtorri: this is the jbig2dec you get from git submodules? 18:31.47 and on what platform are you building? 18:31.48 from the mupdf1.2 source 18:32.06 win32 (msys/mingw-w64) 18:32.22 win64 actually 18:32.32 Seen: Flushed 6 entries. 18:32.32 --- Saved uptime records. 18:32.33 So you're building using MSVC? 18:32.37 no 18:32.41 msys/mingw-w64 18:33.14 OK, so jbig2dec/os_types.h has a rats nest of #ifdefs at the top. 18:33.55 If you've defined HAVE_CONFIG_H then it (reasonably enough I feel) will look for config_types.h 18:34.03 hoo, indeed 18:34.11 it is defined 18:34.29 So... don't define it, or provide a config_types.h :) 18:34.50 what should i contain ? 18:34.53 it* 18:35.13 essentially we use it for definitions of {u,}int{8,16,32}_t 18:35.22 hmm 18:35.52 if you don't define it, and don't define any of the other things, you'll end up using the definitions in that file which are fairly sane. 18:36.36 ok, the c99 types are already defined by mingw-w64 18:36.45 so an empty file is enough 18:37.35 Chans: (ghostbot) in:#ghostscript 18:39.19 Robin_Watts, you won't fix the warning "unused parameter", right ? 18:40.15 vtorri: I think most of our 'unused parameter' warnings are because functions are defined to take a particular set of params so we can take function pointers to them. 18:40.39 i.e. they are only unused in certain implementations. 18:40.54 ok 18:41.01 so there is no 'correct' way to fix the code. We can't just remove the unused params. 18:41.08 and shadow variable warnings ? 18:41.59 Those we should fix. 18:42.09 pass -Wshadow, then :) 18:42.32 and you'll see that there're a lot of them 18:42.52 !WARN! PERL: readdir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 862. 18:42.52 !WARN! PERL: closedir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 869. 18:43.07 well, lot is maybe exagerated 18:43.55 there are also some uninitialized variables 18:44.07 vtorri: Those are spurious. 18:44.46 gcc's warning that a variable may be used when uninitialised are frequently wrong. 18:45.05 The warning really means "I'm too thick to convince myself that this is safe, so I'll complain" 18:45.08 int pdf_js_supported(); in mupdf-internal.h 18:45.16 (missing void too) 18:45.45 check definition too 18:47.11 vtorri: tor8: http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=e219f89eab0e937b14ac2d8838296078f5fa2b35 18:47.14 Thanks. 18:47.33 henrys: This CLA in bugzilla thing. 18:47.33 Robin_Watts: LGTM 18:47.55 tor8: 2 others there too... 18:48.02 http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=a291ddac0d6b7923cdcbd6644bdd89dd315b6921 18:48.09 (better version that works without using clock) 18:48.20 and http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=c92a51cb111f997c94ec48e20cce90ca27073b55 18:49.06 henrys: When attaching a patch, people have to click the 'patch' checkbox. 18:49.49 Can I just change the template to say "By uploading a patch you accept the Artifex CLA" with a link to the CLA ? 18:50.00 Or do you want acceptance to be a separate step? 18:50.16 fitz/util_time.c has gettimeofday for windows 18:50.45 tor8: Using GetTickCount is faster. 18:51.04 Robin_Watts: okay. then the 3 oldest on robin/master LGTM 18:51.10 tor8: Thanks. 18:51.32 GetTickCount has a precision of E-2s 18:51.42 1E-2s 18:52.01 It's a millisecond counter. And I want a millisecond counter :) 18:52.23 it's not millisecond 18:52.30 it's above 18:52.43 (contrary to what msdn says) 18:53.13 vtorri: It returns values in milliseconds. It may not be ACCURATE to milliseconds (i.e. there is jitter) 18:53.13 Chans: (ghostbot) in:#ghostscript 18:53.21 For what I need, it's perfect. 18:53.24 ok 18:53.49 otherwise, you have high frequency counters 18:54.02 indeed. I have used them before for profiling. 18:54.27 This is for some debug code to give a rough idea of the contention of using locks. 18:54.58 It's impossible to do that accurately without system support, so a small amount of jitter isn't going to make a large difference. 18:55.13 ok 18:56.22 >>> marcosw has signed off IRC (Quit: marcosw) [#ghostscript] 18:58.07 FORK(19871) --- fork starting for 'RSSFeeds', PID == 19871, bot_pid == 1004 --- 18:58.08 FORK(19871) !ERROR! cannot load my module: RSSFeeds 18:58.08 FORK(19871) fork: took 2s for RSSFeeds. 18:58.08 FORK(19871) --- fork finished for 'RSSFeeds' --- 19:10.07 Chans: (ghostbot) in:#ghostscript 19:20.46 Robin_Watts:A signed Artifex CLA is prerequisite to patch acceptance. Where Aritfex CLA is a link? 19:26.54 Chans: (ghostbot) in:#ghostscript 19:28.51 FORK(14418) --- fork starting for 'RSSFeeds', PID == 14418, bot_pid == 1004 --- 19:28.52 FORK(14418) !ERROR! cannot load my module: RSSFeeds 19:28.52 FORK(14418) fork: took 2s for RSSFeeds. 19:28.52 FORK(14418) --- fork finished for 'RSSFeeds' --- 19:29.16 yes. 19:30.04 henrys: You actually want a signed CLA? 19:30.21 or you just want them to have accepted the CLA as part of the patch upload process? 19:31.07 The simplest thing for me to do is to change the wording on the attachment thing and have a link to the CLA. 19:31.16 Robin_Watts: after the experience we've had yes. 19:31.53 A more complex thing might have the submit button go to another page that shows the CLA and says "only continue to upload your patch if you agree with this" 19:32.08 but it sounds like neither of those are enough for what you want. 19:32.38 Seen: Flushed 4 entries. 19:32.38 --- Saved uptime records. 19:33.19 Robin_Watts: your solution doesn't need to enforce the policy, we'll do that, the notice just saves us a step 19:33.35 ok. 19:33.54 >>> join/#ghostscript ray_work (~ray_dual@rrcs-64-183-45-162.west.biz.rr.com) 19:37.12 >>> ray_laptop has signed off IRC (Quit: ChatZilla 0.9.90 [Firefox 19.0.2/20130307023931]) [#ghostscript] 19:41.00 >>> join/#ghostscript Fandekasp (~Fandekasp@platinum-static25142.nirai.ne.jp) 19:42.31 Wow! my fix for the 09-03.PS psdcmyk clist bug 693718 showed up a very significant progression on comparefiles/PP0001G0.pdf.psdcmyk.300.1 -- Quite unexpected. We used to be missing a LOT of text but other stuff, too 19:42.41 Chans: (ghostbot) in:#ghostscript 19:44.35 ray_work: Nice. 19:45.50 ray_work:good news, do you think someone should look at the psdcmyk output? 19:46.56 that's a lot of eyeball time. Maybe automate flattening it to RGB (like bmpcmp does) and compare to ppmraw output ? 19:47.48 actually, bmpcmp flattens to cmyk, iirc. But RGB would be enough to equal or exceed eyeball review 19:49.22 bmpcmp compares in cmyk and just converts to rgb for diff. 19:51.42 Robin_Watts: right, but comparing ppmraw RGB to (psdcmyk flattened to RGB) should be sufficient, right ? 19:52.03 yes, just saying that bmpcmp won't do it as is. 19:53.06 Robin_Watts: I realize that. 19:53.18 but yes, it's a good idea. 19:58.59 Chans: (ghostbot) in:#ghostscript 19:58.59 FORK(11774) --- fork starting for 'RSSFeeds', PID == 11774, bot_pid == 1004 --- 19:59.00 FORK(11774) !ERROR! cannot load my module: RSSFeeds 19:59.00 FORK(11774) fork: took 1s for RSSFeeds. 19:59.00 FORK(11774) --- fork finished for 'RSSFeeds' --- 20:01.18 >>> join/#ghostscript marcosw (~marcosw@c-67-164-54-215.hsd1.ca.comcast.net) 20:01.45 what the heck. my gitpush localcluster regression thinks it has 17K objects to write, but it is only 4 objects from origin/master that I last did a localcluster test from 20:04.04 Robin_Watts: meeting starting in #ubuntu-touch-meeting (it looks like) 20:04.48 well, maybe :-/ 20:06.43 >>> docampo has signed off IRC (Ping timeout: 245 seconds) [#ghostscript] 20:07.07 henrys: http://bugs.ghostscript.com/attachment.cgi?bugid=693692&action=enter 20:07.44 ray_work: That's for the RSS reader, I think. 20:08.30 Robin_Watts: I think so. But the #endmeeting already happened for that one :-) 20:10.05 Robin_Watts: for the CLA, it's http://bugs.ghostscript.com/attachment.cgi?id=9346 20:10.50 ray_work: that's what I link to at the above link. 20:12.53 Robin_Watts:looks good to me. 20:12.56 thanks 20:13.01 np. 20:16.01 Chans: (ghostbot) in:#ghostscript 20:29.17 FORK(21430) --- fork starting for 'RSSFeeds', PID == 21430, bot_pid == 1004 --- 20:29.18 FORK(21430) !ERROR! cannot load my module: RSSFeeds 20:29.18 FORK(21430) fork: took 1s for RSSFeeds. 20:29.18 FORK(21430) --- fork finished for 'RSSFeeds' --- 20:32.49 --- Saved uptime records. 20:32.59 Seen: Flushed 3 entries. 20:33.25 Robin_Watts, now there should be our meeting at #ubuntu-touch-meeting. 20:33.39 tkamppeter: Yeah, I'm there, as are others. 20:45.07 >>> join/#ghostscript paulgardiner_ (~chatzilla@smtp.glidos.net) 20:46.54 >>> paulgardiner has signed off IRC (Ping timeout: 276 seconds) [#ghostscript] 20:47.02 >>> paulgardiner_ materializes into paulgardiner 20:48.01 Chans: (ghostbot) in:#ghostscript 20:49.49 >>> join/#ghostscript paulgardiner_ (~chatzilla@smtp.glidos.net) 20:52.16 >>> paulgardiner has signed off IRC (Ping timeout: 252 seconds) [#ghostscript] 20:52.29 >>> paulgardiner_ materializes into paulgardiner 20:59.51 FORK(23153) --- fork starting for 'RSSFeeds', PID == 23153, bot_pid == 1004 --- 20:59.52 FORK(23153) !ERROR! cannot load my module: RSSFeeds 20:59.52 FORK(23153) fork: took 1s for RSSFeeds. 20:59.52 FORK(23153) --- fork finished for 'RSSFeeds' --- 21:03.27 Chans: (ghostbot) in:#ghostscript 21:04.13 well that was interesting... 21:05.16 I think we've got in at the right point of the project (i.e. before anything has been started) 21:06.15 yes, I think there are some issues, I think they are stuck with the cairo library and poppler for apps .. so that's a hurdle 21:06.21 >>> join/#ghostscript kens (~Miranda@87.113.116.18) 21:06.30 Just got in, waS THE MEETING USEFUL ? 21:07.17 Whatever apps use to output pdf is up to them. 21:07.36 OK 21:10.36 Whether they can overcome the impetus of just sticking with what they know is going to be the question. 21:10.52 Hmm I suspect the answer to that one will be 'no' 21:11.33 usually seems to be the case... one would hope that being a new platform the inertia to overcome may be less... 21:12.27 >>> part/#ghostscript tor8 (~tor@c-267571d5.04-50-6c756e10.cust.bredbandsbolaget.se) 21:12.35 they all use cairo as a graphics library right? and that library can produce pdf? poppler and cairo are under the same group and presumably that is desirable - eating your own dog food. We have discussed getting MuPDF a real graphics graphics library API that apps could use. Maybe we should study that more. 21:15.51 henrys: If we had pdfout, then the device interface *is* that interface. 21:19.39 Chans: (ghostbot) in:#ghostscript 21:20.09 Robin_Watts:I guess I'm not following the - the app writers need cairo to draw pictures on the screen - let's say the paint tool app - it draws lines, beliers, whatever with cairo. How do I replace that with mupdf. - where is the api call to draw a curve? 21:20.51 henrys: fz_create_pixmap to make something to draw on. 21:21.12 dev = fz_new_draw_device(pixmap) 21:21.27 Then you call any of our drawing functions with that device. 21:21.58 You can build paths and call fz_fill_path(dev, path); etc. 21:22.51 Or you can call fz_fill_text etc. 21:23.19 Essentially the interpreter reads through pdf content streams breaking them down to such calls. 21:23.39 The draw device knows how to render such calls. 21:24.09 And the display list device knows how to record such calls such that it can play them back to another device (such as the draw device) later. 21:24.39 If we had a pdfout device (which we kinda do, but it's unfinished), then people could render to PDF just by calling the device interface. 21:26.34 but I'm an app programmer how would I possibly figure all that out? What we need is to package it as a documented library - see http://cairographics.org/manual/. 21:28.55 henrys: Well, step 1 would be to finish pdfout :) 21:29.53 agreed 21:30.13 FORK(17655) --- fork starting for 'RSSFeeds', PID == 17655, bot_pid == 1004 --- 21:30.14 FORK(17655) !ERROR! cannot load my module: RSSFeeds 21:30.14 FORK(17655) fork: took 1s for RSSFeeds. 21:30.14 FORK(17655) --- fork finished for 'RSSFeeds' --- 21:31.18 OK I have to go again, night all 21:31.32 >>> kens has signed off IRC (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) [#ghostscript] 21:33.12 --- Saved uptime records. 21:33.12 Seen: Flushed 5 entries. 21:35.47 Chans: (ghostbot) in:#ghostscript 21:43.29 >>> join/#ghostscript JakeSaysSays (~quassel@c-71-195-236-35.hsd1.ut.comcast.net) 21:46.08 Robin_Watts, do you have a file sample-for-large-pxlcolor-output.pdf in your test repo? It is dead-slow with GS and really fast with both MuPDF and Poppler. 21:46.10 >>> JakeSays has signed off IRC (Ping timeout: 258 seconds) [#ghostscript] 21:47.20 tkamppeter: Not that I can see. 21:48.00 >>> sivoais has signed off IRC (Ping timeout: 252 seconds) [#ghostscript] 21:48.45 >>> join/#ghostscript sivoais (~zaki@unaffiliated/sivoais) 21:49.56 tkamppeter: to what device are you rendering in gs? pxlcolor has a different performance profile than raster devices. 21:50.57 Robin_Watts, see your mail. 21:51.27 Chans: (ghostbot) in:#ghostscript 21:54.01 henrys, I simply displayed the files on the screen, no hi-res print output. 21:54.46 Simply 21:55.01 gs sample-for-large-pxlcolor-output.pdf 21:55.03 and 21:55.08 mupdf sample-for-large-pxlcolor-output.pdf 21:55.47 on Linux. I also opened it with MuPDF on the Nexus 7 (Android) and it renders quickly there, too. 21:55.53 there are some problems with the default x11 device - we don't have a user base for it. If you can reproduce the problem going to a file it would be nice to have a bug report. 21:57.02 henrys, OK, so PDF screen display on Linux with GS should better be avoided. 21:58.14 tkamppeter: that's my view of it. I sort of see it as a development tool. 21:58.55 in the debugger you can see the graphics drawn as you step through the code, that's what it is good for. 21:59.37 henrys: So it's utterly useless on windows then. 22:00.28 tkamppeter: 16 page document. I wonder if just one page is slow. 22:00.43 FORK(2842) --- fork starting for 'RSSFeeds', PID == 2842, bot_pid == 1004 --- 22:00.44 FORK(2842) !ERROR! cannot load my module: RSSFeeds 22:00.44 FORK(2842) fork: took 1s for RSSFeeds. 22:00.44 FORK(2842) --- fork finished for 'RSSFeeds' --- 22:02.46 Robin_Watts:it is an X11 device. 22:02.46 So the windows display device doesn't have the same problem? 22:03.06 Robin_Watts, the article text is slow under X11, the pictures are no problem. 22:04.07 is the default device x11alpha? 22:05.04 Robin_Watts, yes, if I switch to X11, rendering is fast again. 22:05.22 I understand. 22:05.59 Robin_Watts, so no good sample to show how much faster MuPDF is. 22:06.47 >>> marcosw1 has signed off IRC (Ping timeout: 256 seconds) [#ghostscript] 22:07.21 Chans: (ghostbot) in:#ghostscript 22:18.33 >>> join/#ghostscript marcosw1 (~marcos@67.169.6.130) 22:24.43 Chans: (ghostbot) in:#ghostscript 22:26.45 >>> oy has signed off IRC (Quit: tschüß) [#ghostscript] 22:31.21 FORK(24504) --- fork starting for 'RSSFeeds', PID == 24504, bot_pid == 1004 --- 22:31.22 FORK(24504) !ERROR! cannot load my module: RSSFeeds 22:31.22 FORK(24504) fork: took 1s for RSSFeeds. 22:31.22 FORK(24504) --- fork finished for 'RSSFeeds' --- 22:33.17 --- Saved uptime records. 22:33.27 Seen: Flushed 3 entries. 22:40.25 Chans: (ghostbot) in:#ghostscript 22:41.51 leak: 1 nuh{} items deleted; now have 33 22:42.28 tkamppeter: Oh, and mupdf has cunning stuff in to support multi-threaded rendering etc. dunno if that's useful for you. 22:43.28 !WARN! PERL: readdir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 862. 22:43.28 !WARN! PERL: closedir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 869. 22:50.08 the fitz rendering is (mostly) designed to support AA rendering everywhere. In fact turning it off for some devices (that have low depth) was only added after a few years. 22:51.01 OTOH, gs has AA (TextAlphaBits and GraphicsAlphaBits) sort of kloodged in 22:52.01 since gs was/is mostly printer focused and there aren't low res contone printers 22:53.17 Robin_Watts: Does mupdf to x11 only update the page when the rendering of the page is complete ? 22:56.47 Chans: (ghostbot) in:#ghostscript 22:58.47 >>> join/#ghostscript ray_laptop (~chatzilla@rrcs-64-183-45-163.west.biz.rr.com) 23:01.29 FORK(1170) --- fork starting for 'RSSFeeds', PID == 1170, bot_pid == 1004 --- 23:01.30 FORK(1170) !ERROR! cannot load my module: RSSFeeds 23:01.30 FORK(1170) fork: took 1s for RSSFeeds. 23:01.30 FORK(1170) --- fork finished for 'RSSFeeds' --- 23:12.39 Chans: (ghostbot) in:#ghostscript 23:21.09 >>> join/#ghostscript tor8 (~tor@c-267571d5.04-50-6c756e10.cust.bredbandsbolaget.se) 23:28.21 Chans: (ghostbot) in:#ghostscript 23:30.01 >>> marcosw has signed off IRC (Quit: marcosw) [#ghostscript] 23:31.10 >>> join/#ghostscript marcosw (~marcosw@c-67-164-54-215.hsd1.ca.comcast.net) 23:31.33 FORK(14181) --- fork starting for 'RSSFeeds', PID == 14181, bot_pid == 1004 --- 23:31.34 FORK(14181) !ERROR! cannot load my module: RSSFeeds 23:31.34 FORK(14181) fork: took 1s for RSSFeeds. 23:31.34 FORK(14181) --- fork finished for 'RSSFeeds' --- 23:33.29 --- Saved uptime records. 23:33.39 Seen: Flushed 2 entries. 23:43.43 Chans: (ghostbot) in:#ghostscript 23:48.49 has anyone else seen this error? 23:48.50 misc errors: Use of uninitialized value $mujstest in concatenation (.) or string at run.pl line 1449. (repeated MANY times) 23:49.48 marcosw: the question above is probably for you 23:50.25 ray_laptop: oops, probably my tinkering with the cluster code earlier today. 23:50.43 marcosw: np. That's what I assumed 23:51.14 marcosw: so we need a regression test to allow you to test your changes to the regression scripts :-) 23:51.31 and then another script to test that, and ... 23:52.02 ray_laptop: I've lobbied for a test cluster for some time :-) 23:55.40 ray_laptop: should be sorted. 23:56.32 ray_laptop: just to confirm, these errors only happened during bmpcmp runs, correct?