00:04.11 Opened logfile log/20130123. 00:04.11 >>> marcosw has signed off IRC (Quit: marcosw) [#ghostscript] 00:06.18 Chans: (ghostbot) in:#ghostscript 00:09.26 >>> tkamppeter has signed off IRC (Ping timeout: 252 seconds) [#ghostscript] 00:09.45 >>> join/#ghostscript tkamppeter (~till@p5DDBB80F.dip.t-dialin.net) 00:11.28 ircCheck: possible lost in space; checking.Wed Jan 23 00:11:28 2013 00:11.28 >ghostbot< TEST 00:11.28 IRCTEST: Yes, we're alive. 00:21.58 Chans: (ghostbot) in:#ghostscript 00:24.03 >>> mrdocs has signed off IRC (Ping timeout: 255 seconds) [#ghostscript] 00:30.18 FORK(15086) --- fork starting for 'RSSFeeds', PID == 15086, bot_pid == 947 --- 00:30.19 FORK(15086) !ERROR! cannot load my module: RSSFeeds 00:30.19 FORK(15086) fork: took 2s for RSSFeeds. 00:30.19 FORK(15086) --- fork finished for 'RSSFeeds' --- 00:38.38 Chans: (ghostbot) in:#ghostscript 00:54.07 --- Saved uptime records. 00:54.18 Chans: (ghostbot) in:#ghostscript 01:00.38 FORK(24329) --- fork starting for 'RSSFeeds', PID == 24329, bot_pid == 947 --- 01:00.39 FORK(24329) !ERROR! cannot load my module: RSSFeeds 01:00.39 FORK(24329) fork: took 2s for RSSFeeds. 01:00.39 FORK(24329) --- fork finished for 'RSSFeeds' --- 01:15.27 LOG: last message repeated 3 times 01:15.27 ircCheck: possible lost in space; checking.Wed Jan 23 01:15:27 2013 01:15.27 >ghostbot< TEST 01:15.28 IRCTEST: Yes, we're alive. 01:25.57 Chans: (ghostbot) in:#ghostscript 01:31.18 FORK(19973) --- fork starting for 'RSSFeeds', PID == 19973, bot_pid == 947 --- 01:31.19 FORK(19973) !ERROR! cannot load my module: RSSFeeds 01:31.19 FORK(19973) fork: took 2s for RSSFeeds. 01:31.19 FORK(19973) --- fork finished for 'RSSFeeds' --- 01:54.27 --- Saved uptime records. 01:57.27 Chans: (ghostbot) in:#ghostscript 02:01.28 FORK(25912) --- fork starting for 'RSSFeeds', PID == 25912, bot_pid == 947 --- 02:01.29 FORK(25912) !ERROR! cannot load my module: RSSFeeds 02:01.29 FORK(25912) fork: took 2s for RSSFeeds. 02:01.29 FORK(25912) --- fork finished for 'RSSFeeds' --- 02:16.16 >>> tor8 has signed off IRC (Quit: tor8) [#ghostscript] 02:19.17 ircCheck: possible lost in space; checking.Wed Jan 23 02:19:17 2013 02:19.17 >ghostbot< TEST 02:19.17 IRCTEST: Yes, we're alive. 02:29.52 Chans: (ghostbot) in:#ghostscript 02:32.12 FORK(2916) --- fork starting for 'RSSFeeds', PID == 2916, bot_pid == 947 --- 02:32.14 FORK(2916) !ERROR! cannot load my module: RSSFeeds 02:32.14 FORK(2916) fork: took 2s for RSSFeeds. 02:32.14 FORK(2916) --- fork finished for 'RSSFeeds' --- 02:54.42 LOG: last message repeated 3 times 02:54.42 --- Saved uptime records. 03:01.42 Chans: (ghostbot) in:#ghostscript 03:02.22 FORK(8633) --- fork starting for 'RSSFeeds', PID == 8633, bot_pid == 947 --- 03:02.23 FORK(8633) !ERROR! cannot load my module: RSSFeeds 03:02.23 FORK(8633) fork: took 1s for RSSFeeds. 03:02.23 FORK(8633) --- fork finished for 'RSSFeeds' --- 03:23.52 ircCheck: possible lost in space; checking.Wed Jan 23 03:23:52 2013 03:23.52 >ghostbot< TEST 03:23.52 IRCTEST: Yes, we're alive. 03:32.57 FORK(15296) --- fork starting for 'RSSFeeds', PID == 15296, bot_pid == 947 --- 03:32.59 FORK(15296) !ERROR! cannot load my module: RSSFeeds 03:32.59 FORK(15296) fork: took 2s for RSSFeeds. 03:32.59 FORK(15296) --- fork finished for 'RSSFeeds' --- 03:34.17 Chans: (ghostbot) in:#ghostscript 03:36.42 >>> join/#ghostscript tkamppeter_ (~till@p5DDB9A13.dip.t-dialin.net) 03:38.00 >>> tkamppeter has signed off IRC (Read error: Operation timed out) [#ghostscript] 03:50.17 Chans: (ghostbot) in:#ghostscript 03:51.07 !WARN! PERL: readdir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 862. 03:51.07 !WARN! PERL: closedir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 869. 03:54.57 --- Saved uptime records. 04:03.17 FORK(17997) --- fork starting for 'RSSFeeds', PID == 17997, bot_pid == 947 --- 04:03.18 FORK(17997) !ERROR! cannot load my module: RSSFeeds 04:03.18 FORK(17997) fork: took 1s for RSSFeeds. 04:03.18 FORK(17997) --- fork finished for 'RSSFeeds' --- 04:04.49 >>> mvrhel_laptop has signed off IRC (Ping timeout: 248 seconds) [#ghostscript] 04:05.57 Chans: (ghostbot) in:#ghostscript 04:27.07 ircCheck: possible lost in space; checking.Wed Jan 23 04:27:07 2013 04:27.07 >ghostbot< TEST 04:27.07 IRCTEST: Yes, we're alive. 04:33.27 FORK(5463) --- fork starting for 'RSSFeeds', PID == 5463, bot_pid == 947 --- 04:33.28 FORK(5463) !ERROR! cannot load my module: RSSFeeds 04:33.28 FORK(5463) fork: took 1s for RSSFeeds. 04:33.28 FORK(5463) --- fork finished for 'RSSFeeds' --- 04:37.47 Chans: (ghostbot) in:#ghostscript 04:38.17 >>> join/#ghostscript mvrhel_laptop (~chatzilla@c-174-61-155-196.hsd1.wa.comcast.net) 04:44.40 >>> join/#ghostscript marcosw (~marcosw@67.169.6.130) 04:53.37 Chans: (ghostbot) in:#ghostscript 04:55.07 >>> join/#ghostscript ray_laptop (~chatzilla@rrcs-64-183-45-163.west.biz.rr.com) 04:55.17 --- Saved uptime records. 05:03.37 FORK(24106) --- fork starting for 'RSSFeeds', PID == 24106, bot_pid == 947 --- 05:03.38 FORK(24106) !ERROR! cannot load my module: RSSFeeds 05:03.38 FORK(24106) fork: took 1s for RSSFeeds. 05:03.38 FORK(24106) --- fork finished for 'RSSFeeds' --- 05:09.47 Chans: (ghostbot) in:#ghostscript 05:13.04 >>> marcosw has signed off IRC (Quit: marcosw) [#ghostscript] 05:25.37 Chans: (ghostbot) in:#ghostscript 05:31.17 ircCheck: possible lost in space; checking.Wed Jan 23 05:31:17 2013 05:31.17 >ghostbot< TEST 05:31.17 IRCTEST: Yes, we're alive. 05:33.57 FORK(24662) --- fork starting for 'RSSFeeds', PID == 24662, bot_pid == 947 --- 05:33.58 FORK(24662) !ERROR! cannot load my module: RSSFeeds 05:33.58 FORK(24662) fork: took 1s for RSSFeeds. 05:33.58 FORK(24662) --- fork finished for 'RSSFeeds' --- 05:41.57 Chans: (ghostbot) in:#ghostscript 05:42.26 >>> join/#ghostscript mrdocs (~mrdocs@opensuse/member/mrdocs) 05:47.13 >>> ray_laptop has signed off IRC (Ping timeout: 248 seconds) [#ghostscript] 05:55.47 --- Saved uptime records. 05:57.27 Chans: (ghostbot) in:#ghostscript 06:04.07 FORK(20377) --- fork starting for 'RSSFeeds', PID == 20377, bot_pid == 947 --- 06:04.08 FORK(20377) !ERROR! cannot load my module: RSSFeeds 06:04.08 FORK(20377) fork: took 1s for RSSFeeds. 06:04.08 FORK(20377) --- fork finished for 'RSSFeeds' --- 06:34.07 LOG: last message repeated 4 times 06:34.07 ircCheck: possible lost in space; checking.Wed Jan 23 06:34:07 2013 06:34.07 >ghostbot< TEST 06:34.07 IRCTEST: Yes, we're alive. 06:34.57 FORK(25465) --- fork starting for 'RSSFeeds', PID == 25465, bot_pid == 947 --- 06:34.58 FORK(25465) !ERROR! cannot load my module: RSSFeeds 06:34.58 FORK(25465) fork: took 1s for RSSFeeds. 06:34.58 FORK(25465) --- fork finished for 'RSSFeeds' --- 06:45.17 Chans: (ghostbot) in:#ghostscript 06:55.57 --- Saved uptime records. 07:00.47 Chans: (ghostbot) in:#ghostscript 07:05.07 FORK(27897) --- fork starting for 'RSSFeeds', PID == 27897, bot_pid == 947 --- 07:05.08 FORK(27897) !ERROR! cannot load my module: RSSFeeds 07:05.08 FORK(27897) fork: took 1s for RSSFeeds. 07:05.08 FORK(27897) --- fork finished for 'RSSFeeds' --- 07:29.37 >>> mvrhel_laptop has signed off IRC (Ping timeout: 248 seconds) [#ghostscript] 07:32.07 Chans: (ghostbot) in:#ghostscript 07:35.37 FORK(29085) --- fork starting for 'RSSFeeds', PID == 29085, bot_pid == 947 --- 07:35.38 FORK(29085) !ERROR! cannot load my module: RSSFeeds 07:35.38 FORK(29085) fork: took 1s for RSSFeeds. 07:35.38 FORK(29085) --- fork finished for 'RSSFeeds' --- 07:37.27 ircCheck: possible lost in space; checking.Wed Jan 23 07:37:27 2013 07:37.27 >ghostbot< TEST 07:37.27 IRCTEST: Yes, we're alive. 07:42.08 >>> chrisl_away materializes into chrisl 07:48.02 Chans: (ghostbot) in:#ghostscript 07:51.22 !WARN! PERL: readdir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 862. 07:51.22 !WARN! PERL: closedir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 869. 07:56.22 --- Saved uptime records. 07:57.43 >>> join/#ghostscript kens (~Miranda@87.113.176.59) 08:03.42 Chans: (ghostbot) in:#ghostscript 08:05.52 FORK(12112) --- fork starting for 'RSSFeeds', PID == 12112, bot_pid == 947 --- 08:05.53 FORK(12112) !ERROR! cannot load my module: RSSFeeds 08:05.53 FORK(12112) fork: took 1s for RSSFeeds. 08:05.53 FORK(12112) --- fork finished for 'RSSFeeds' --- 08:36.02 FORK(17360) --- fork starting for 'RSSFeeds', PID == 17360, bot_pid == 947 --- 08:36.03 FORK(17360) !ERROR! cannot load my module: RSSFeeds 08:36.03 FORK(17360) fork: took 2s for RSSFeeds. 08:36.03 FORK(17360) --- fork finished for 'RSSFeeds' --- 08:40.37 LOG: last message repeated 3 times 08:40.37 >>> join/#ghostscript jghali_ (~jghali@ADijon-157-1-2-2.w90-56.abo.wanadoo.fr) 08:41.12 ircCheck: possible lost in space; checking.Wed Jan 23 08:41:12 2013 08:41.12 >ghostbot< TEST 08:41.12 IRCTEST: Yes, we're alive. 08:41.35 >>> tkamppeter_ materializes into tkamppeter 08:43.47 >>> UukGoblin has signed off IRC (Changing host) [#ghostscript] 08:43.47 >>> join/#ghostscript UukGoblin (~jaa@unaffiliated/uukgoblin) 08:44.01 >>> jghali has signed off IRC (Ping timeout: 248 seconds) [#ghostscript] 08:51.47 Chans: (ghostbot) in:#ghostscript 08:56.37 --- Saved uptime records. 09:06.27 FORK(15047) --- fork starting for 'RSSFeeds', PID == 15047, bot_pid == 947 --- 09:06.28 FORK(15047) !ERROR! cannot load my module: RSSFeeds 09:06.28 FORK(15047) fork: took 1s for RSSFeeds. 09:06.28 FORK(15047) --- fork finished for 'RSSFeeds' --- 09:07.36 Chans: (ghostbot) in:#ghostscript 09:15.58 >>> kens has signed off IRC (Read error: Connection reset by peer) [#ghostscript] 09:16.57 >>> join/#ghostscript tor8 (~tor@c-f77c71d5.04-50-6c756e10.cust.bredbandsbolaget.se) 09:23.26 Chans: (ghostbot) in:#ghostscript 09:31.50 >>> join/#ghostscript paulgardiner (~chatzilla@smtp.glidos.net) 09:36.37 FORK(1151) --- fork starting for 'RSSFeeds', PID == 1151, bot_pid == 947 --- 09:36.38 FORK(1151) !ERROR! cannot load my module: RSSFeeds 09:36.38 FORK(1151) fork: took 2s for RSSFeeds. 09:36.38 FORK(1151) --- fork finished for 'RSSFeeds' --- 09:37.45 >>> chrisl materializes into chrisl_away 09:39.25 Chans: (ghostbot) in:#ghostscript 09:39.30 >>> join/#ghostscript kens (~Miranda@87.113.176.59) 09:44.36 ircCheck: possible lost in space; checking.Wed Jan 23 09:44:36 2013 09:44.36 >ghostbot< TEST 09:44.36 IRCTEST: Yes, we're alive. 09:53.19 >>> kens has signed off IRC (Read error: Connection reset by peer) [#ghostscript] 09:55.11 Chans: (ghostbot) in:#ghostscript 09:57.01 --- Saved uptime records. 09:57.30 >>> join/#ghostscript kens (~Miranda@87.113.176.59) 10:06.52 FORK(14626) --- fork starting for 'RSSFeeds', PID == 14626, bot_pid == 947 --- 10:06.53 FORK(14626) !ERROR! cannot load my module: RSSFeeds 10:06.53 FORK(14626) fork: took 2s for RSSFeeds. 10:06.53 FORK(14626) --- fork finished for 'RSSFeeds' --- 10:11.31 Chans: (ghostbot) in:#ghostscript 10:19.21 >>> kens has signed off IRC (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) [#ghostscript] 10:20.32 https://play.google.com/store/apps/details?id=com.artifex.mupdfdemo&feature=search_result#?t=W251bGwsMSwyLDEsImNvbS5hcnRpZmV4Lm11cGRmZGVtbyJd 10:27.01 Chans: (ghostbot) in:#ghostscript 10:27.28 Lovely 10:37.22 FORK(16320) --- fork starting for 'RSSFeeds', PID == 16320, bot_pid == 947 --- 10:37.23 FORK(16320) !ERROR! cannot load my module: RSSFeeds 10:37.23 FORK(16320) fork: took 2s for RSSFeeds. 10:37.23 FORK(16320) --- fork finished for 'RSSFeeds' --- 10:40.31 Robin_Watts: how come that the developers page does not link to mupdf.com..? 10:41.29 Does now :) 10:41.44 Might take a few hours to show up. 10:41.53 ah. :) 10:43.03 Chans: (ghostbot) in:#ghostscript 10:55.56 >>> join/#ghostscript jghali__ (~jghali@ADijon-157-1-158-189.w92-130.abo.wanadoo.fr) 10:57.31 --- Saved uptime records. 10:59.01 Chans: (ghostbot) in:#ghostscript 10:59.22 Seen: Flushed 3 entries. 10:59.32 >>> jghali_ has signed off IRC (Ping timeout: 245 seconds) [#ghostscript] 11:01.23 >>> sivoais has signed off IRC (Read error: Connection reset by peer) [#ghostscript] 11:01.49 >>> henrys has signed off IRC (Ping timeout: 248 seconds) [#ghostscript] 11:08.01 FORK(19333) --- fork starting for 'RSSFeeds', PID == 19333, bot_pid == 947 --- 11:08.02 FORK(19333) !ERROR! cannot load my module: RSSFeeds 11:08.02 FORK(19333) fork: took 1s for RSSFeeds. 11:08.02 FORK(19333) --- fork finished for 'RSSFeeds' --- 11:14.21 Chans: (ghostbot) in:#ghostscript 11:37.56 Robin_Watts: argh! now I finally figured out why the tinting on the file picker icons didn't work... 11:38.07 FORK(9111) --- fork starting for 'RSSFeeds', PID == 9111, bot_pid == 947 --- 11:38.08 FORK(9111) !ERROR! cannot load my module: RSSFeeds 11:38.08 FORK(9111) fork: took 2s for RSSFeeds. 11:38.08 FORK(9111) --- fork finished for 'RSSFeeds' --- 11:38.10 setBackgroundResource() should be setImageResource()... 11:38.54 tor8: Ah. 11:39.16 Robin_Watts: also, the lack of a path to where the navigation is is driving me nuts... 11:39.21 Well, if you fix the icons we can rebuild and reupload, and I can test the auto update thing with Helens phone :) 11:39.36 Robin_Watts: I want to experiment more with the icons 11:39.44 I'm not entirely happy with some of them 11:40.38 maybe we should make a list of all icons we can think of that we'll want to use 11:40.48 thinking ahead of the features for annotation that are in development 11:46.11 Chans: (ghostbot) in:#ghostscript 11:51.31 !WARN! PERL: readdir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 862. 11:51.31 !WARN! PERL: closedir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 869. 11:53.45 tor8: http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=75643c9a1353b77b59e4c3006298a5feac81e33a 11:53.57 Fixes various files. I've just been through the bmpcmp. 11:57.51 --- Saved uptime records. 11:59.31 Seen: Flushed 2 entries. 12:01.41 Chans: (ghostbot) in:#ghostscript 12:08.51 FORK(15531) --- fork starting for 'RSSFeeds', PID == 15531, bot_pid == 947 --- 12:08.52 FORK(15531) !ERROR! cannot load my module: RSSFeeds 12:08.52 FORK(15531) fork: took 1s for RSSFeeds. 12:08.52 FORK(15531) --- fork finished for 'RSSFeeds' --- 12:08.58 Robin_Watts: fz_transform_vector for transforming points that are used as vectors (i.e. ignore the translation)? 12:11.24 tor8: could do, I guess. 12:12.09 Would that be useful anywhere else? 12:17.47 Robin_Watts: probably not 12:17.57 Chans: (ghostbot) in:#ghostscript 12:19.30 If it was used in more than one place then that function would be more clearly a win. 12:22.47 Woo Hoo! I have smart advance working with pretty scrolling effects within a page. 12:22.59 Need to sort the advance to next page thing now. 12:34.11 Chans: (ghostbot) in:#ghostscript 12:37.59 >>> chrisl_away materializes into chrisl 12:39.19 FORK(18026) --- fork starting for 'RSSFeeds', PID == 18026, bot_pid == 947 --- 12:39.20 FORK(18026) !ERROR! cannot load my module: RSSFeeds 12:39.20 FORK(18026) fork: took 1s for RSSFeeds. 12:39.20 FORK(18026) --- fork finished for 'RSSFeeds' --- 12:50.31 Chans: (ghostbot) in:#ghostscript 12:58.41 --- Saved uptime records. 13:00.11 Seen: Flushed 2 entries. 13:06.21 Chans: (ghostbot) in:#ghostscript 13:09.31 FORK(19176) --- fork starting for 'RSSFeeds', PID == 19176, bot_pid == 947 --- 13:09.32 FORK(19176) !ERROR! cannot load my module: RSSFeeds 13:09.32 FORK(19176) fork: took 1s for RSSFeeds. 13:09.32 FORK(19176) --- fork finished for 'RSSFeeds' --- 13:15.00 >>> join/#ghostscript kens (~Miranda@87.113.176.59) 13:21.21 >>> kens has signed off IRC (Read error: Connection reset by peer) [#ghostscript] 13:22.31 Chans: (ghostbot) in:#ghostscript 13:28.01 ircCheck: possible lost in space; checking.Wed Jan 23 13:28:01 2013 13:28.01 >ghostbot< TEST 13:28.01 IRCTEST: Yes, we're alive. 13:36.14 >>> join/#ghostscript kens (~Miranda@87.113.176.59) 13:38.26 Chans: (ghostbot) in:#ghostscript 13:39.36 FORK(17495) --- fork starting for 'RSSFeeds', PID == 17495, bot_pid == 947 --- 13:39.37 FORK(17495) !ERROR! cannot load my module: RSSFeeds 13:39.37 FORK(17495) fork: took 1s for RSSFeeds. 13:39.37 FORK(17495) --- fork finished for 'RSSFeeds' --- 13:58.46 --- Saved uptime records. 14:06.27 network kicking time 14:09.46 FORK(19552) --- fork starting for 'RSSFeeds', PID == 19552, bot_pid == 947 --- 14:09.47 FORK(19552) !ERROR! cannot load my module: RSSFeeds 14:09.47 FORK(19552) fork: took 1s for RSSFeeds. 14:09.47 FORK(19552) --- fork finished for 'RSSFeeds' --- 14:10.16 Chans: (ghostbot) in:#ghostscript 14:11.01 >>> kens has signed off IRC (Read error: Connection reset by peer) [#ghostscript] 14:11.19 >>> join/#ghostscript kens (~Miranda@87.113.176.59) 14:11.28 >>> join/#ghostscript sivoais (~zaki@199.19.225.239) 14:26.06 Chans: (ghostbot) in:#ghostscript 14:40.06 FORK(23652) --- fork starting for 'RSSFeeds', PID == 23652, bot_pid == 947 --- 14:40.07 FORK(23652) !ERROR! cannot load my module: RSSFeeds 14:40.07 FORK(23652) fork: took 1s for RSSFeeds. 14:40.07 FORK(23652) --- fork finished for 'RSSFeeds' --- 14:58.56 LOG: last message repeated 4 times 14:58.56 --- Saved uptime records. 15:00.46 Seen: Flushed 1 entries. 15:07.24 >>> join/#ghostscript marcosw (~marcosw@67.169.6.130) 15:09.06 ircCheck: possible lost in space; checking.Wed Jan 23 15:09:06 2013 15:09.06 >ghostbot< TEST 15:09.06 IRCTEST: Yes, we're alive. 15:10.16 FORK(25283) --- fork starting for 'RSSFeeds', PID == 25283, bot_pid == 947 --- 15:10.17 FORK(25283) !ERROR! cannot load my module: RSSFeeds 15:10.17 FORK(25283) fork: took 1s for RSSFeeds. 15:10.17 FORK(25283) --- fork finished for 'RSSFeeds' --- 15:14.11 Chans: (ghostbot) in:#ghostscript 15:22.53 >>> marcosw has signed off IRC (Quit: marcosw) [#ghostscript] 15:30.31 Chans: (ghostbot) in:#ghostscript 15:34.02 >>> join/#ghostscript ray_laptop (~chatzilla@cpe-76-171-54-81.socal.res.rr.com) 15:40.51 FORK(28664) --- fork starting for 'RSSFeeds', PID == 28664, bot_pid == 947 --- 15:40.52 FORK(28664) !ERROR! cannot load my module: RSSFeeds 15:40.52 FORK(28664) fork: took 1s for RSSFeeds. 15:40.52 FORK(28664) --- fork finished for 'RSSFeeds' --- 15:46.31 Chans: (ghostbot) in:#ghostscript 15:48.38 >>> mrdocs has signed off IRC (Ping timeout: 244 seconds) [#ghostscript] 15:51.50 Robin_Watts: http://ghostscript.com/~tor/stuff/mupdf-debug-batch.apk yet another set of icons 15:52.04 rather fat and rounded, but it turned out nicer than I would have expected 15:52.34 !WARN! PERL: readdir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 862. 15:52.34 !WARN! PERL: closedir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 869. 15:55.12 Yeah, I quite like those 15:55.38 paulgardiner: the set is a bit more complete than the old "iconic" set as well 15:56.10 if it ends up missing things, it'll be harder to find ones that match though... given how much character it has 15:57.47 I'm up to my ears in this smart motion stuff. 15:57.57 It looks really promising, I just can't get the moving back a page to work. 15:59.41 --- Saved uptime records. 15:59.50 >>> join/#ghostscript henrys (~henrys@67.138.171.234) 16:01.01 >>> ray_laptop has signed off IRC (Ping timeout: 248 seconds) [#ghostscript] 16:01.11 Seen: Flushed 3 entries. 16:02.17 >>> kens has signed off IRC (Read error: Connection reset by peer) [#ghostscript] 16:02.27 Chans: (ghostbot) in:#ghostscript 16:02.41 >>> join/#ghostscript Robin_Watts_ (~chatzilla@82.153.127.105) 16:03.11 >>> join/#ghostscript kens (~Miranda@87.113.176.59) 16:04.18 >>> Robin_Watts has signed off IRC (Ping timeout: 246 seconds) [#ghostscript] 16:04.21 >>> Robin_Watts_ materializes into Robin_Watts 16:11.01 FORK(28978) --- fork starting for 'RSSFeeds', PID == 28978, bot_pid == 947 --- 16:11.02 FORK(28978) !ERROR! cannot load my module: RSSFeeds 16:11.02 FORK(28978) fork: took 1s for RSSFeeds. 16:11.02 FORK(28978) --- fork finished for 'RSSFeeds' --- 16:18.21 Chans: (ghostbot) in:#ghostscript 16:24.26 tor8: Ugh. I hate the directory icon, 16:25.20 All the others seem nice though. 16:26.01 >>> henrys has signed off IRC (Quit: henrys) [#ghostscript] 16:26.25 http://ghostscript.com/~robin/MuPDF-debug.apk 16:26.45 tor8, paulgardiner: That has a first version of smart motion implemented. Let me know what you think. 16:30.19 Like it. Seems to work fine. 16:34.01 Chans: (ghostbot) in:#ghostscript 16:41.11 FORK(14657) --- fork starting for 'RSSFeeds', PID == 14657, bot_pid == 947 --- 16:41.12 FORK(14657) !ERROR! cannot load my module: RSSFeeds 16:41.12 FORK(14657) fork: took 1s for RSSFeeds. 16:41.12 FORK(14657) --- fork finished for 'RSSFeeds' --- 16:41.42 >>> join/#ghostscript henrys (~henrys@c-50-134-235-109.hsd1.co.comcast.net) 16:42.20 Morning henrys 16:42.37 howdy Robin_Watts 16:47.22 tor8: Oh! fz_transform_vector already exists! 16:47.53 Robin_Watts: ahem. I didn't know that! 16:48.11 I'll update the review :) 16:48.58 >>> join/#ghostscript Gigs- (~Gigs@206-248-204-121.unassigned.ntelos.net) 16:48.58 >>> Gigs- has signed off IRC (Changing host) [#ghostscript] 16:48.58 >>> join/#ghostscript Gigs- (~Gigs@pdpc/supporter/28for7/gigs) 16:48.59 parent caught SIGTERM (pid 947). 16:48.59 --- Start of quit. 16:48.59 Memory Usage: 17432 KiB 16:48.59 Seen: Flushed 4 entries. 16:48.59 QUIT ghostbot has quit IRC (dive! dive! dive!) 16:48.59 --- Saved USERFILE (1 users; 0 bans; 0 ignore) at Wed Jan 23 16:48:59 2013 16:48.59 --- Saved CHANFILE (2 chans) at Wed Jan 23 16:48:59 2013 16:48.59 --- Saved uptime records. 16:48.59 Closed DBI connection to localhost. 16:48.59 Closed shared memory (shm) key: [0] 16:51.10 Opened logfile log/20130123. 16:51.10 --- Started logging. 16:51.10 Loaded infobot.lang (77 items) 16:51.10 Loaded infobot.servers (1 servers) 16:51.10 USERFILE: Loaded: 0 users, 0 bans, 0 ignore 16:51.10 CHANFILE: Loaded: 1 chans 16:51.10 Loading MyModules... 16:51.10 Loaded Topic 16:51.10 Loaded Uptime 16:51.10 Loaded News 16:51.10 Loaded RootWarn 16:51.10 Loaded botmail 16:51.10 Loaded OnJoin 16:51.10 Module: Runtime: Loaded/Total [6/7] 16:51.10 Created shared memory (shm) key: [0] 16:51.10 Opened SQLite connection to localhost 16:51.10 checkTables: creating new table connections... 16:51.10 Setup: 6 factoids. 16:51.10 Initial memory usage: 15780 KiB 16:51.10 ------------------------------------------------------- 16:51.10 Connecting to port 6667 of server irc.freenode.net (213.179.58.83) as ghostbot ... 16:52.13 !WARN! PERL: Can't connect to irc.freenode.net:6667! at /usr/share/perl5/Net/IRC.pm line 195 16:52.13 !ERROR! IRC: connection failed. 16:52.13 !ERROR! add "set ircHost 0.0.0.0" to your config. If that does not work 16:52.13 !ERROR! Please check /etc/hosts to see if you have a localhost line like: 16:52.13 !ERROR! 127.0.0.1 localhost localhost 16:52.13 !ERROR! If this is still a problem, please contact the maintainer. 16:53.01 Opened logfile log/20130123. 16:53.01 --- Started logging. 16:53.01 Loaded infobot.lang (77 items) 16:53.01 Loaded infobot.servers (1 servers) 16:53.01 USERFILE: Loaded: 0 users, 0 bans, 0 ignore 16:53.01 CHANFILE: Loaded: 1 chans 16:53.01 Loading MyModules... 16:53.01 Loaded Topic 16:53.01 Loaded Uptime 16:53.01 Loaded News 16:53.01 Loaded RootWarn 16:53.01 Loaded botmail 16:53.01 Loaded OnJoin 16:53.01 Module: Runtime: Loaded/Total [6/7] 16:53.01 Created shared memory (shm) key: [32769] 16:53.01 Opened SQLite connection to localhost 16:53.01 checkTables: creating new table connections... 16:53.01 Setup: 6 factoids. 16:53.01 Initial memory usage: 15780 KiB 16:53.01 ------------------------------------------------------- 16:53.02 LOG: Throttling. 16:53.01 Connecting to port 6667 of server irc.freenode.net (128.237.157.136) as ghostbot ... 16:53.02 starting main loop 16:53.02 -adams.freenode.net- *** Looking up your hostname... 16:53.02 -adams.freenode.net- *** Checking Ident 16:53.04 -adams.freenode.net- *** Found your hostname 16:53.10 -adams.freenode.net- *** No Ident response 16:53.10 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! 16:53.10 !!! Ok. Now type '/msg ghostbot PASS ' to get master access through DCC CHAT. 16:53.10 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! 16:53.10 End of motd. Now lets join some channels... 16:53.10 There are 203 users and 85585 invisible on 32 servers 16:53.10 34 IRC Operators online 16:53.10 4 unknown connection(s) 16:53.10 42805 channels formed 16:53.10 I have 3335 clients and 1 servers 16:53.10 >>> mode [+i] by ghostbot 16:53.16 >>> mode [+w] by ghostbot 16:53.26 --- Saved uptime records. 16:53.26 config (ghostbot): auto-setting param{chanlimitcheckInterval} = 10 16:53.26 config (ghostbot): auto-setting param{floodCycle} = 60 16:53.27 Chans: (ghostbot) join:#ghostscript 16:53.27 !FIXME! ircCheck: found channels to join! #ghostscript 16:53.27 joining #ghostscript 16:53.27 Schedulers: 22 will be running. 16:53.28 >>> join/#ghostscript ghostbot (~ghostbot@casper3.ghostscript.com) 16:53.28 >>> topic/#ghostscript is Ghostscript development and discussion | live channel log at http://ghostscript.com/irclogs/ | Info at http://www.ghostscript.com 16:53.28 >>> set by ray_laptop!~chatzilla@69.233.158.225 at Tue Aug 23 15:22:21 2011 16:53.28 #ghostscript: sync in 0.113s. 16:53.28 #ghostscript: [27 total] 16:53.28 ChanServ ==> Requesting ops for #ghostscript. (chanServCheck) 16:53.28 >ChanServ< OP #ghostscript 16:53.28 ChanServ: <== 'You are not authorized to perform this operation.'. 16:53.38 Chans: (ghostbot) in:#ghostscript 16:53.38 time taken to join all chans: 31s; rate: 3.1 sec/join 16:54.10 chrisl:we seem to generating tiff configuration files somewhere other than the build "gendir", I didn't track it down, I noticed in when trying to build a windows system in a shared directory after a unix build. I did clean and even blew away the "gendir" 16:54.31 chrisl:not a big deal but if it is something easily fixed great. 16:54.35 Robin_Watts: I would prefer a different name for "p2", like "dp" or something more diff/delta-ish. other than that it looks good. 16:55.02 Robin_Watts: I used 'dir' in a few other places 16:55.38 >>> join/#ghostscript ray_laptop (~chatzilla@rrcs-64-183-45-163.west.biz.rr.com) 16:55.59 henrys: I mentioned that a *long* time ago. Problem: gendir doesn't exist during configure - also, when I checked it before, the libtiff configure script didn't work from a different directory 16:56.09 >>> join/#ghostscript mvrhel_laptop (~chatzilla@ip-64-134-128-119.public.wayport.net) 16:56.15 good morning 16:56.30 Morning michael. 16:57.05 tor8: p2 => dir done 16:57.19 cool. I will try the download on the nexus when I get back home (at coffee shop now) 16:57.40 Robin_Watts: push away! 16:57.44 ta. 16:57.46 chrisl:ah okay 16:58.00 Robin_Watts: paulgardiner: two quick android related reviews on tor/icons 16:58.57 henrys: I did think we could do something like create a "tiff-config" directory - *if* the tiff configure works now 16:59.30 tor8: Urm... so if I'm in /mnt/sdcard/Download, the file picker will have "/mnt/sdcard/Download" where it used to have .. ? 16:59.40 OK off for pizzagoodnight all 16:59.44 night kens 16:59.46 Robin_Watts: yeah. feel free to improve it. 16:59.56 Robin_Watts: but it has the "up" arrow there so it made sort of sense 17:00.01 chrisl:does it make sense to have gendir created by configure? 17:00.01 >>> kens has signed off IRC (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) [#ghostscript] 17:00.52 tor8: it would be nicer if it said "[/mnt/sdcard]" and the title bar said: "MuPDF 1.1: Download" 17:01.12 or maybe we could just make it say "/mnt/sdcard/Download/.." ? 17:01.15 henrys: "gendir" differs depending on the type of build you do, we don't know what it will be at configure time - release, debug, etc 17:01.19 Robin_Watts: or "[ Up one level ]" and the title had the path? 17:01.20 chrisl:as it is now everything but tiff generates to gendir right? 17:01.51 tor8: That would be nicest. 17:01.54 henrys: IIRC, tiff is the only other configure script we run, now 17:02.03 chrisl:yeah I was thinking of pushing all those options up to configure 17:02.11 I'm not sure how to set the title programmatically though. 17:02.22 I suppose that would be a big change. 17:02.32 Robin_Watts: that feels like a horrible hack though... 17:02.51 Does it? That feels correct to me. 17:03.25 (The title saying "MuPDF 1.1: path" and .. being "[Up one level]") 17:03.46 I mean abusing the title like that. But it's the best idea so far. 17:04.00 chrisl:but it would simplify the makefiles quite a bit. 17:04.33 wooah. henrys, you want to configure between release and debug builds? 17:04.41 henrys: well, I like not having to re-configure for the different builds. 17:04.43 No way, dude. 17:05.47 Robin_Watts: the bounce back when trying to swipe to flip pages is really annoying! 17:06.22 chrisl:okay fair enough 17:06.25 Also, not being funny, but the way it used to "work" that stuff was done in both configure and makefiles. We discussed it a couple of years ago, and all agreed to handling it in the makefiles - and we've devoted a fair amount of time to getting all working nicely. 17:06.26 but I guess that's the android gesture recognizer not being as good as apple's 17:07.11 tor8: dunno. 17:07.25 I think Paul took the decision that any 'fling' stops at page boundaries. 17:07.41 The alternative is to let the fling continue, and then to reset from where it stops. 17:07.50 That would make swiping easier. 17:08.12 But it may have issues with how many pages we have loaded at a time or something. 17:08.55 It's the scroller that made that decision really. We could have used OverScroller but it's not in v8 17:09.30 I guess we could fake it or make it conditional 17:09.31 Well, we could use OverScoller if it's present, and the current one otherwise ? 17:09.51 Chans: (ghostbot) in:#ghostscript 17:10.03 The question is, do we make left/right do what up/down do now ? 17:11.44 For chinese text in rows? :-) 17:11.58 henrys: is there somewhere "central" where we can grab the contributor agreement? 17:12.54 chrisl:oh did we not put that up yet I've ticked it off my todo list 17:13.18 nothing back from URW BTW... 17:13.20 yes 17:13.22 If you had zoomed in to lose the margins, then it would move hard right before a page change which would be detrimental 17:13.25 s/yes/yet 17:13.49 paulgardiner: No. It only moves right if it can fit a whole new column in. 17:14.04 henrys: I've never even seen the agreement..... I don't know it Robin did the bugzilla hackery for it at some point 17:14.10 oh ok 17:14.22 chrisl: I did not. 17:14.46 I'll send it to tech 17:14.56 Cool thanks. 17:15.24 And I'll update the interested users about the URW thing...... 17:16.16 done 17:17.53 Thanks 17:20.49 tor8: I have a version working here with the title etc. Will upload an apk in a sec. 17:23.38 FORK(4610) --- fork starting for 'RSSFeeds', PID == 4610, bot_pid == 6683 --- 17:23.39 FORK(4610) !ERROR! cannot load my module: RSSFeeds 17:23.39 FORK(4610) fork: took 2s for RSSFeeds. 17:23.39 FORK(4610) --- fork finished for 'RSSFeeds' --- 17:23.59 henrys: so, in new(er) libtiff we're using now, the configure script works okay from a different directory, so I think it would be good to change things around to use a "config" directory, or similar. 17:25.43 Chans: (ghostbot) in:#ghostscript 17:26.46 chrisl:that would make it easier for shared directory builds. 17:27.28 henrys: I'll put it on my todo list..... I would certainly prefer it to work that way 17:28.19 although I bet there is a simple way to get rid of extra files using git. - remove everything not under source control. 17:28.26 git clean 17:29.03 tor8, paulgardiner: http://ghostscript.com/~robin/MuPDF-debug.apk 17:29.12 Observe the file picker. 17:29.45 henrys: or with extreme prejudice: git clean -x -f -d 17:30.27 git alias nuke="git clean -x -f -d" :) 17:31.05 I prefer not to make something that extreme too easy! 17:32.56 indeed I know I'll eventually lose an added file once I start the git clean habit 17:33.37 not added in the git sense 17:33.45 but something I want in the directory. 17:34.31 My most common one is losing a cut-down test file to git clean - but then, I also lose them to "make clean" since we started obliterating the obj and bin dirs for that. 17:34.41 alexcher: I'm glad you were able to duplicate bug 693496. Cust 532 would like an estimate for when it will be fixed. 17:37.22 ray_laptop: have you got a sec to talk about something related to the GC problem I'm looking at (Bug 693571)? 17:40.17 chrisl: sure. 17:41.07 Chans: (ghostbot) in:#ghostscript 17:42.04 ray_laptop: cool. So, in the gs_ref_memory_t structure we've got the chunk list (cfirst), the current chunk (pcc) in the list and the "active" chunk (cc) 17:43.39 Now "cc" is "in-line" with the gs_ref_memory_t structure, so we end up copying the contents of the chunk into and out of that and the chunk list 17:44.32 alloc_close_chunk() and alloc_open_chunk() do that copying. 17:44.47 ok, following so far 17:45.19 So, what I'm wondering is: do we really need the "cc", can't we just use "pcc" and ditch all the copying? 17:46.07 chrisl: then where will the current chunk be ? Just allocated on it's own ? 17:47.02 ray_laptop: it already is allocated, and held in the chunk list, what's in cc is a copy 17:47.43 chrisl: OK, right. But how does not copying to 'cc' cure the problem ? 17:49.35 ray_laptop: the issue in this bug is that we get into garbage collection with a chunk that hasn't been "closed" since the last "free" operation, hence the pointers in the chunk in the chunk list do not match the pointers in the cc structure 17:50.39 So, the chunk validator tries to validate memory that has actually been freed 17:52.21 I have a fix for that, but it strikes me as pointless doing the copying back and forth when we could simply use the chunk in the chunk list directly (via the pcc pointer) 17:53.22 chrisl: but the start of a GC calls alloc_close_chunk before it does the GC 17:53.32 Seen: Flushed 8 entries. 17:53.42 --- Saved uptime records. 17:53.42 FORK(1159) --- fork starting for 'RSSFeeds', PID == 1159, bot_pid == 6683 --- 17:53.44 FORK(1159) !ERROR! cannot load my module: RSSFeeds 17:53.44 FORK(1159) fork: took 2s for RSSFeeds. 17:53.44 FORK(1159) --- fork finished for 'RSSFeeds' --- 17:53.50 ireclaim.c line 125 17:55.20 chrisl: so how can we get into garbage collection with a chunk that hasn't been "closed" since the last "free" 17:55.31 >>> join/#ghostscript sebras (~sebras@casper3.ghostscript.com) 17:56.12 ray_laptop: we only close the current chunk in the "top" allocator....... 17:56.29 ray_laptop: the problem is when we do a save: we can use the allocator *after* it has been "saved", and that can leave it in an "unstable" state 17:57.03 Chans: (ghostbot) in:#ghostscript 18:05.20 chrisl: so you are seeing a 'free' in a chunk that isn't an 'inner_chunk' ? 18:07.39 ray_laptop: err, is it an inner_chunk? During a save operation, we can free memory using "mem->saved.state", and that leaves us in the unstable state 18:12.25 Chans: (ghostbot) in:#ghostscript 18:15.12 ray_laptop: (now that my debugger is talking to me again!), this is happening in alloc_save_state() 18:18.15 If we're past the first save level, we call save_set_new() passing in the *previous* generation of allocator. That can eventually call drop_redundant_changes() which can free memory in an allocator whose current chunk has already been alloc_close_chunk()'ed 18:21.09 Hmm, the cluster seems to be throwing a fit again :-( 18:23.56 FORK(28345) --- fork starting for 'RSSFeeds', PID == 28345, bot_pid == 6683 --- 18:23.57 FORK(28345) !ERROR! cannot load my module: RSSFeeds 18:23.57 FORK(28345) fork: took 2s for RSSFeeds. 18:23.57 FORK(28345) --- fork finished for 'RSSFeeds' --- 18:26.00 >>> join/#ghostscript marcosw (~marcosw@67.169.6.130) 18:27.57 chrisl: All of the 'save' stuff is something I've never (as far as I can recall) dug into, but I thought that 'changes' were all supposed to be allocated in the chunks after the save, so how can there be a change from an outer chunk being freed by drop_redundant_changes ?? 18:28.43 Chans: (ghostbot) in:#ghostscript 18:30.17 ray_laptop: changes are allocated after the save - once we've "saved" an allocator, though, we try to get rid of any pointless "changes", and that's where this problem arises. 18:32.10 ray_laptop: so, if you put a breakpoint in alloc_save_state(), and skip to the first non-global save (the third call, for me)....... 18:33.04 At that point lmem->save_level == 2 18:33.31 chrisl: I need to fire up the debugger with the problem file. Just a mo... 18:36.25 oh, great. It's rebuilding about eveerything :-( 18:37.05 Okay, that'll give time to go grab a drink - back in a sec 18:38.58 chrisl: OK. It's the 4th bp for me, but I'm there 18:39.23 That's the first call with global == 0 18:40.12 Right, cool. So it calls alloc_save_space() which closes the current chunk, "saves" the allocator etc.... 18:40.50 And the "saved" allocator is moved into lsave->saved 18:41.36 Oops, sorry: lsave->state is the "saved" allocator 18:43.38 So, then, further down, we call save_set_new() passing in the "saved" allocator from lsave->state 18:43.54 chrisl: OK. right 18:44.13 Then we call save_set_new_changes() 18:44.33 Chans: (ghostbot) in:#ghostscript 18:44.46 And in there, we *may* call drop_redundant_changes(), which can free memory in that allocator 18:45.28 chrisl: OK. This time it didn't do the drop_redundant call 18:46.24 No it doesn't do it every time, but it illustrates that we can end up freeing memory in an allocator that is not expected to be used at that stage. 18:47.43 ray_laptop: for me, it will call drop_redundant_changes() on the fifteenth call to alloc_save_state() 18:48.39 chrisl: I have a bp in drop_redundant_changes and I get an exception BEFORE it is ever called. But that seems to be because I have -Zu set 18:49.27 ray_laptop: there is an issue with the memory pointer not being set for one of the printf calls - I have a fix for that, too 18:49.32 the last thing it printed was: [u]GC finalizing stream 0x299ead0 18:49.54 chrisl: OK. I'll turn that off for now 18:52.31 yeah. I have the UI swiping working now in my mupdf windows metro app 18:53.09 have to step out for bit to get wifes computer at the fedex store. somehow they missed me 3 days in row 18:53.45 --- Saved uptime records. 18:53.56 Seen: Flushed 3 entries. 18:54.06 FORK(4142) --- fork starting for 'RSSFeeds', PID == 4142, bot_pid == 6683 --- 18:54.07 FORK(4142) !ERROR! cannot load my module: RSSFeeds 18:54.07 FORK(4142) fork: took 1s for RSSFeeds. 18:54.07 FORK(4142) --- fork finished for 'RSSFeeds' --- 18:55.48 mvrhel_laptop: Nice. 18:57.39 >>> mvrhel_laptop has signed off IRC (Ping timeout: 248 seconds) [#ghostscript] 18:59.47 chrisl: OK, so I see it freeing some changes. A 'real' then a 'string', a 'name', ... 19:00.18 ray_laptop: so it's freeing in an already "saved" allocator, which is not expected 19:01.06 hence the problem: the call to alloc_close_chunk() when we start gc only applies to the "top" allocator 19:01.16 Chans: (ghostbot) in:#ghostscript 19:07.36 chrisl: so this must happen ALL the time. Why only a failure with this file ? 19:08.51 ray_laptop: Well, not only this file, but with -Z@ - it may well be happening all the time, but if we don't zap the memory, we'll not see a problem 19:10.26 there is a comment in i_free_object about not overwriting contents if something is from an older save level. 19:11.25 We can't know it's an earlier save level, because we explicitly use the previous allocator instance..... 19:11.57 Also, the memory being freed must be at the bottom of the chunk, so we have to move the cbot pointer 19:12.10 chrisl: so is the problem in chunk_locate_ptr not returning the correct bool ? 19:13.39 ray_laptop: no, the problem is after we've freed memory (which uses the mem->cc chunk) we never apply those changes to mem->pcc (the chunk in the chunk list). The gc code only ever uses the chunks in chunk list 19:15.22 chrisl: OK, I see. So it is using (writing to 'cc') for a chunk that has not been 'opened' and doesn't get 'closed' 19:15.58 ray_laptop: yes. So my fix is to add an open/close around the drop_redundant_changes() call 19:17.24 chrisl: but different 'changes' might be in different chunks 19:17.34 Chans: (ghostbot) in:#ghostscript 19:18.14 ray_laptop: doesn't the allocator handle that possibility? 19:19.16 ray_laptop: if the memory is not in the current chunk, the allocator should close the current chunk, and open the appropriate chunk 19:21.28 chrisl: I'm looking at i_free_object to see how (or if) it does that, but it isn't obvious. It seems like it should be done by 'chunk_locate_ptr' 19:22.23 ray_laptop: well, it can't expect the caller to know what chunk a block of memory was allocated in 19:24.30 FORK(22601) --- fork starting for 'RSSFeeds', PID == 22601, bot_pid == 6683 --- 19:24.31 FORK(22601) !ERROR! cannot load my module: RSSFeeds 19:24.31 FORK(22601) fork: took 2s for RSSFeeds. 19:24.31 FORK(22601) --- fork finished for 'RSSFeeds' --- 19:24.55 chrisl: right. OK, so it scans to find the chunk. The while ((cld.cp = cld.memory->clast), !chunk_locate_ptr(ptr, &cld) 19:27.33 but I don't see where it sets the 'cc' (that it later uses) 19:27.36 ray_laptop: I think if the memory we're freeing is not in the current chunk, we write the changes straight back to the chunk from the list - no need to open and close 19:29.09 In fact, most of the time, we don't even change the chunk, we just "tag" the memory as free with pp->o_type = &st_free 19:29.54 chrisl: I see it setting 'cld.cp' (and sometimes it sets that to &imem->cc) 19:31.03 but isave.c line 854 just starts using imem->cc (as if the chunk is opened) 19:31.57 isave.c? 19:33.18 chrisl: sorry, gsalloc.c 19:33.49 Chans: (ghostbot) in:#ghostscript 19:34.43 ray_laptop: It does assume the chunk is open, yes. Opening and closing on every operation is a huge performance hit 19:37.33 chrisl: I agree that would be a performance hit, but it seems that after we find the chunk with chunk_locate_ptr we need to open the chunk if it wasn't already open 19:38.14 chrisl: we must be missing something, or how could this work ??? 19:40.28 ray_laptop: if you look at the chunk_locate macro, I think it handles the problem you're thinking of 19:41.25 chrisl: is i_free_object, it doesn't use chunk_locate -- it uses chunk_locate_ptr 19:41.52 ray_laptop: line 901 19:43.10 chrisl: imem->cc is used in line 854 19:44.23 ray_laptop: yes, and we should be covered by the fact that we're checking the address. 19:45.49 >>> marcosw has signed off IRC (Quit: marcosw) [#ghostscript] 19:45.57 ray_laptop: generally speaking, the "active" chunk will always be "open" 19:46.28 chrisl: OK, that is only done when the the end of the object matches what's in cc.cbot, so what's in cc should be correct 19:47.18 ray_laptop: yes, so even if the chunk happens to be "closed" the data in "cc" will be correct 19:48.12 and the o_alone case just de-links a chunk from the list, so it doesn't modify the contents of the 'cc' 19:48.23 Yep 19:50.12 ray_laptop: And the very last case, we only mark the header with pp->o_type = &st_free 19:50.22 Chans: (ghostbot) in:#ghostscript 19:50.24 chrisl: but where does the imem->cc get copied in ? I don't see chunk_locate doing it 19:50.44 ray_laptop: copied in for what? 19:51.55 ray_laptop: I was going to say, I'm a little bemused by line 913/914 19:52.32 imem->cc.int_freed_top gets examined and conditionally modified 19:52.48 chrisl: right that's the spot 19:53.25 Okay, so I'm not sure about that, but it's not really relevant for the current bug..... 19:53.55 --- Saved uptime records. 19:53.57 chrisl: granted (probably, depending on what the int_freed_top is used for) 19:54.07 Seen: Flushed 3 entries. 19:54.27 ray_laptop: oh, I think it doesn't matter - that's just the address of the highest object on a freelist, I think it's not specific to the current chunk 19:54.37 FORK(11323) --- fork starting for 'RSSFeeds', PID == 11323, bot_pid == 6683 --- 19:54.38 FORK(11323) !ERROR! cannot load my module: RSSFeeds 19:54.38 FORK(11323) fork: took 1s for RSSFeeds. 19:54.38 FORK(11323) --- fork finished for 'RSSFeeds' --- 19:55.41 Oh, not sure.... :-( 19:56.00 >>> jghali__ materializes into jghali 19:56.08 chrisl: it seems to relate to 'trim_obj' 19:56.58 ray_laptop: Anyway, in the context of this bug, but the cbot and ctop pointers that are important - those are what gc uses to know where to scan 19:58.02 chrisl: or maybe the decision to call consolidate_chunk_free, but anyway, cbot and ctop, OK 20:00.56 chrisl: so since i_free_object writes directly into the chunk and doesn't really modify cbot or ctop -- just messes with the o_type of the object (ignoring the o_alone case), how is it getting confused ? 20:01.34 ray_laptop: line 857, it's writes to cbot 20:03.22 right, but we said that was OK didn't "we" because of the ptr comparison ? 20:04.22 ray_laptop: that means it's the current chunk, yes. But if we don't "close" it before gc, the change doesn't get written back to the chunk list 20:05.02 OK, so closing the chunk after the drop_redundant_changes is what is missing ? 20:05.40 Yes. But for symmetry, I added an open chunk before drop_redundant_changes(), too 20:06.20 Chans: (ghostbot) in:#ghostscript 20:06.22 That leaves everything in a nice stable state, so the gc code doesn't get confused 20:10.03 ray_laptop: that change cluster tests okay, but I want to run my own test script tomorrow with -Z@, too 20:10.32 chrisl: alloc_open_chunk probably won't do anything because alloc_save_space did alloc_close_chunk then writes mem->pcc = 0 20:11.48 ray_laptop: pcc isn't null when I get to drop_redundant_changes()..... 20:13.53 ray_laptop: the reason being the allocator being saved is assigned before that happens line 401 20:16.37 chrisl: OK, I see 20:17.51 I still don't know why we didn't see this a LONG time ago. I run with -Z@$? a lot 20:19.12 It's quite a few circumstances conspiring to get us there, although, I agree, I'm surprised it hasn't appear before 20:20.01 chrisl: are you going to fix that int_freed_top (potential) problem as well ? 20:21.04 ray_laptop: I can look into it sure - but I think it's benign. I think it will only mean we'll call consolidate_chunk_free() sometimes when it won't help, and won't call it sometimes when it might help 20:22.02 chrisl: which might mean using more memory than needed, but I am pretty sure that GC resets this 20:22.42 Chans: (ghostbot) in:#ghostscript 20:22.49 ray_laptop: yes, by "benign" I meant no crashes, and no *huge* memory problems. 20:24.19 ray_laptop: but what I really wanted your opinion on was the idea of getting rid "cc" and access chunks (more) directly via pcc - so we don't have to worry about keeping the "cc" entry, and the chunk list in sync with the open/close chunk copying 20:24.49 FORK(1512) --- fork starting for 'RSSFeeds', PID == 1512, bot_pid == 6683 --- 20:24.50 chrisl: I doubt I helped any, but at least you dragged me along enough to help me understand what you found, but I'll still let you fix anything else in save/restore in the future ;-) 20:24.50 FORK(1512) !ERROR! cannot load my module: RSSFeeds 20:24.50 FORK(1512) fork: took 1s for RSSFeeds. 20:24.50 FORK(1512) --- fork finished for 'RSSFeeds' --- 20:25.09 Gee thanks! 20:25.33 >>> join/#ghostscript marcosw (~marcosw@c-67-164-54-215.hsd1.ca.comcast.net) 20:26.37 chrisl: have you found any reason for the opening/closing chunk and having a copy of the 'current' chunk embedded in the gs_ref_memory ? 20:27.17 like maybe that copy gets used during the GC or something ? 20:28.22 ray_laptop: not so far. I thought it was maybe for during initialisation, but that's not the case. My best guess (so far) is that it dates from when pointer accesses were relatively expensive, so the effort of copying was offset by having to use the pointer less often 20:28.52 not important, just curious. It could be something like that (avoiding indirection) 20:29.23 or localizing memory access to improve likelihood of a cache hit 20:29.47 but compared to the rest of all of the stuff we do, it seems funky 20:30.16 I'm not convinced we get a net benefit from it these days, assuming we ever did 20:30.56 ray_laptop: But I only looked at it briefly, then I wanted to run it past you before I spent any more time on it 20:31.31 I just got the report from the weekly -Z@ run. Once you fix it, you'll probably have to get marcosw to re-run it 20:32.43 Can do. As I said, I'll run my own script tomorrow, for my own peace of mind 20:35.18 ray_laptop: anyway, I need to stop now - I'm losing the ability to type. Thanks for going through this with me...... 20:37.33 hmm, that's strange. I just got the email about the -Z@ regression run, and it says :results for 2013_01_23_2ae1a17..." but the latest commit it shows was on Jan 18th (the 2ae1a1a7 one) 20:37.59 chrisl: np. Thanks for being patient as I stumbled along :-) 20:38.23 methinks marcos should look into that 20:38.55 Chans: (ghostbot) in:#ghostscript 20:40.57 Right, goodnight, and god bless...... 20:41.09 >>> chrisl materializes into chrisl_away 20:41.51 maybe the cutoff time is before those later commits yesterday. 20:43.17 >>> join/#ghostscript Leolo_3 (~fil@24-54-35-233.mg.cgocable.ca) 20:43.44 I have what might be a silly question : how does one set the output device w/in postscript? 20:44.08 systemdict /DEVICE /ppmraw def doesn't seem to work 20:44.30 I suspect one Can't Do That For Obvious Reasons 20:44.43 I want the equiv of -sDEVICE=ppmraw 20:45.38 Leolo_3: with Ghostscript it is easy. (check doc/Use.htm): (ppmraw) selectdevice 20:45.54 ha! 20:46.06 ok, I was looking in 100% the wrong direction :-) 20:46.09 Read the Fine Manual ;-) 20:46.45 Leolo_3: generally you can't define stuff in systemdict anyway 20:47.19 I'm pretty much a postscript newbie. I did a lot of forth way way back in the day, but apart from that, I'm cargo culting 20:48.16 PS is LOTS more fun than forth, (and lots more confusing) 20:48.21 would something like "devicesnames { dup = selectdevice currentpagedevice /HWResolution get == } forall" be at all feasable? 20:48.39 forth was helluva cool. but that was 20+ years ago 20:50.00 >>> join/#ghostscript mvrhel_laptop (~chatzilla@c-174-61-155-196.hsd1.wa.comcast.net) 20:50.09 oooo... it is, except that x11 doesn't work, so I have to filter out the bad device 20:50.41 Leolo_3: well, you've mispelled devicenames but otherwise that works for _some_ devices. 20:51.28 yeah 20:51.39 although, why you want to do that, I don't know 20:52.56 i want to get the all the default resolutions 20:53.25 so I my prog can then calculate DEVICEWIDTHPOINTS properly 20:53.46 !WARN! PERL: readdir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 862. 20:53.46 !WARN! PERL: closedir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 869. 20:54.06 --- Saved uptime records. 20:54.26 Seen: Flushed 3 entries. 20:54.26 Chans: (ghostbot) in:#ghostscript 20:54.56 FORK(20360) --- fork starting for 'RSSFeeds', PID == 20360, bot_pid == 6683 --- 20:54.57 FORK(20360) !ERROR! cannot load my module: RSSFeeds 20:54.57 FORK(20360) fork: took 1s for RSSFeeds. 20:54.57 FORK(20360) --- fork finished for 'RSSFeeds' --- 20:56.01 Leolo_3: not GS has PS extensions, like .sort that is handy, too. Try: devicenames dup length array copy { 100 string cvs exch 100 string cvs gt } .sort = 20:56.59 Leolo_3: but DEVICEWIDTHPOINTS is ALWAYS in 1/72 inch. But if you want to set an exact number of pixels, you can use -gWWWxHHH option on the command line 20:58.16 Leolo_3: actually on that .sort example, you probably want == 20:59.33 -g is also in points, no? 20:59.49 oh fuck me, no it isn't 21:00.03 I wanted, -dDEVICEWIDTH, not DEVICEWIDTHPOINTS 21:00.07 SO MUCH TIME WASTED 21:00.08 Leolo_3: but DEVICEWIDTHPOINTS is the command line option. With PS use: << /PageSize [ width height ] >> setpagedevice 21:01.52 I would suggest a read through at least Use.htm :-) 21:03.21 I didn't, but I guess I'm just blind 21:04.15 ok, this works better ... but still have problems 21:05.58 ok, -dDEVICEWIDTH=2369 -dDEVICEHEIGHT=1737 -r72x72 produces what I want, but -dDEVICEWIDTH=2369 -dDEVICEHEIGHT=1737 -r100x100 doesn't 21:06.17 oh, because of the 2nd conversion step 21:06.46 >>> ray_laptop has signed off IRC (Ping timeout: 256 seconds) [#ghostscript] 21:10.45 Chans: (ghostbot) in:#ghostscript 21:15.47 >>> marcosw has signed off IRC (Quit: marcosw) [#ghostscript] 21:25.08 FORK(8972) --- fork starting for 'RSSFeeds', PID == 8972, bot_pid == 6683 --- 21:25.09 FORK(8972) !ERROR! cannot load my module: RSSFeeds 21:25.09 FORK(8972) fork: took 2s for RSSFeeds. 21:25.09 FORK(8972) --- fork finished for 'RSSFeeds' --- 21:26.43 Chans: (ghostbot) in:#ghostscript 21:54.21 --- Saved uptime records. 21:54.41 Seen: Flushed 2 entries. 21:55.22 FORK(29272) --- fork starting for 'RSSFeeds', PID == 29272, bot_pid == 6683 --- 21:55.23 FORK(29272) !ERROR! cannot load my module: RSSFeeds 21:55.23 FORK(29272) fork: took 2s for RSSFeeds. 21:55.23 FORK(29272) --- fork finished for 'RSSFeeds' --- 21:58.33 Chans: (ghostbot) in:#ghostscript 22:09.33 ircCheck: possible lost in space; checking.Wed Jan 23 22:09:33 2013 22:09.33 >ghostbot< TEST 22:09.33 IRCTEST: Yes, we're alive. 22:14.48 Chans: (ghostbot) in:#ghostscript 22:17.33 >>> mvrhel_laptop has signed off IRC (Ping timeout: 276 seconds) [#ghostscript] 22:24.14 >>> join/#ghostscript adamben (~Adam@binpress/adamben) 22:24.33 hey all - anyone awake? 22:25.33 FORK(28988) --- fork starting for 'RSSFeeds', PID == 28988, bot_pid == 6683 --- 22:25.34 FORK(28988) !ERROR! cannot load my module: RSSFeeds 22:25.34 FORK(28988) fork: took 1s for RSSFeeds. 22:25.34 FORK(28988) --- fork finished for 'RSSFeeds' --- 22:28.27 >>> paulgardiner has signed off IRC (Quit: ChatZilla 0.9.89 [Firefox 18.0.1/20130116073211]) [#ghostscript] 22:30.20 Chans: (ghostbot) in:#ghostscript 22:54.42 --- Saved uptime records. 22:54.52 Seen: Flushed 1 entries. 22:55.53 FORK(25183) --- fork starting for 'RSSFeeds', PID == 25183, bot_pid == 6683 --- 22:55.54 FORK(25183) !ERROR! cannot load my module: RSSFeeds 22:55.54 FORK(25183) fork: took 1s for RSSFeeds. 22:55.54 FORK(25183) --- fork finished for 'RSSFeeds' --- 22:57.36 adamben: some of us are still here. is there anything in particular you want to ask about? :) 22:58.15 I thought it was the place to ask about muPDF commercial license 22:58.17 but maybe Im wrong 23:01.50 Chans: (ghostbot) in:#ghostscript 23:26.03 FORK(21598) LOG: last message repeated 3 times 23:26.03 FORK(21598) --- fork starting for 'RSSFeeds', PID == 21598, bot_pid == 6683 --- 23:26.04 FORK(21598) !ERROR! cannot load my module: RSSFeeds 23:26.04 FORK(21598) fork: took 2s for RSSFeeds. 23:26.04 FORK(21598) --- fork finished for 'RSSFeeds' --- 23:27.07 LOG: last message repeated 3 times 23:27.07 adamben: no, you have come to the right place. sorry for the delay. 23:27.26 Alright 23:28.09 sebras: Are you associated with Artifex? 23:28.16 adamben: I'm not working for Artifex, the company who licenses MuPDF. 23:28.25 ahah 23:28.25 ok 23:28.35 I was going to ask you about their pricing 23:28.49 Im looking to distribute a PDF component for Android and I'd like to license their PDF viewer 23:28.52 adamben: but I recommend that you contact Scott Sackett at sales@artifex.com or at +1 940 482 7985. 23:29.13 adamben: yes, I understand. I have seen this question come up a few times. :) 23:29.20 great 23:29.23 sending him an email 23:29.42 adamben: I believe that you can also find contact info for him here, should you loose it: http://www.artifex.com/ 23:30.46 loose -> lose. my fingers write fast, but not correctly. 23:31.13 right 23:31.16 Just sent him an emai 23:31.18 *email 23:31.22 adamben: for any techincal questions you might have, feel free to ask here. 23:31.30 I have some technical Q now :) 23:31.35 or more featuresets wise 23:31.38 might take some time before someone answers though. :) 23:31.43 why? 23:32.25 adamben: some developers are in .uk, some are in the us... 23:32.40 Do you think I'll get a response by tomorrow? 23:33.20 Chans: (ghostbot) in:#ghostscript 23:33.21 adamben: technical questions rarely go unanswered that long. 23:33.54 Can I PM you? 23:34.07 adamben: sure, no problem. 23:35.24 adamben: I should emphasisze that I'm not working for artifex though, I'm just a hang-around here. 23:35.38 no problem - sent you a message ;) 23:46.10 >>> join/#ghostscript mrdocs (~mrdocs@opensuse/member/mrdocs) 23:50.08 Chans: (ghostbot) in:#ghostscript 23:55.06 Seen: Flushed 2 entries. 23:55.16 --- Saved uptime records. 23:55.38 >>> adamben has signed off IRC (Quit: Computer has gone to sleep.) [#ghostscript] 23:56.08 FORK(16429) --- fork starting for 'RSSFeeds', PID == 16429, bot_pid == 6683 --- 23:56.09 FORK(16429) !ERROR! cannot load my module: RSSFeeds 23:56.09 FORK(16429) fork: took 1s for RSSFeeds. 23:56.09 FORK(16429) --- fork finished for 'RSSFeeds' ---