00:07.46 Opened logfile log/20130528. 00:07.46 Chans: (ghostbot) in:#ghostscript 00:14.12 FORK(12111) --- fork starting for 'RSSFeeds', PID == 12111, bot_pid == 948 --- 00:14.13 FORK(12111) !ERROR! cannot load my module: RSSFeeds 00:14.13 FORK(12111) fork: took 1s for RSSFeeds. 00:14.13 FORK(12111) --- fork finished for 'RSSFeeds' --- 00:17.54 ircCheck: possible lost in space; checking.Tue May 28 00:17:54 2013 00:17.54 >ghostbot< TEST 00:17.54 IRCTEST: Yes, we're alive. 00:23.27 Chans: (ghostbot) in:#ghostscript 00:43.43 LOG: last message repeated 3 times 00:43.43 >>> marcosw_ has signed off IRC (Quit: marcosw_) [#ghostscript] 00:44.27 FORK(22774) --- fork starting for 'RSSFeeds', PID == 22774, bot_pid == 948 --- 00:44.28 FORK(22774) !ERROR! cannot load my module: RSSFeeds 00:44.28 FORK(22774) fork: took 1s for RSSFeeds. 00:44.28 FORK(22774) --- fork finished for 'RSSFeeds' --- 00:54.55 Chans: (ghostbot) in:#ghostscript 00:57.59 --- Saved uptime records. 01:11.01 Chans: (ghostbot) in:#ghostscript 01:15.15 FORK(8098) --- fork starting for 'RSSFeeds', PID == 8098, bot_pid == 948 --- 01:15.16 FORK(8098) !ERROR! cannot load my module: RSSFeeds 01:15.16 FORK(8098) fork: took 1s for RSSFeeds. 01:15.16 FORK(8098) --- fork finished for 'RSSFeeds' --- 01:21.51 ircCheck: possible lost in space; checking.Tue May 28 01:21:51 2013 01:21.51 >ghostbot< TEST 01:21.51 IRCTEST: Yes, we're alive. 01:27.18 Chans: (ghostbot) in:#ghostscript 01:45.54 FORK(22581) --- fork starting for 'RSSFeeds', PID == 22581, bot_pid == 948 --- 01:45.55 FORK(22581) !ERROR! cannot load my module: RSSFeeds 01:45.55 FORK(22581) fork: took 1s for RSSFeeds. 01:45.55 FORK(22581) --- fork finished for 'RSSFeeds' --- 01:58.46 --- Saved uptime records. 01:58.56 Chans: (ghostbot) in:#ghostscript 02:16.32 FORK(4246) --- fork starting for 'RSSFeeds', PID == 4246, bot_pid == 948 --- 02:16.33 FORK(4246) !ERROR! cannot load my module: RSSFeeds 02:16.33 FORK(4246) fork: took 1s for RSSFeeds. 02:16.33 FORK(4246) --- fork finished for 'RSSFeeds' --- 02:26.42 ircCheck: possible lost in space; checking.Tue May 28 02:26:42 2013 02:26.42 >ghostbot< TEST 02:26.42 IRCTEST: Yes, we're alive. 02:30.03 >>> join/#ghostscript tkamppeter_ (~till@p5DDB918E.dip0.t-ipconnect.de) 02:31.33 >>> join/#ghostscript JakeSays (~quassel@63.226.106.92) 02:32.03 Chans: (ghostbot) in:#ghostscript 02:33.31 >>> tkamppeter has signed off IRC (Ping timeout: 264 seconds) [#ghostscript] 02:47.06 FORK(19752) --- fork starting for 'RSSFeeds', PID == 19752, bot_pid == 948 --- 02:47.07 FORK(19752) !ERROR! cannot load my module: RSSFeeds 02:47.07 FORK(19752) fork: took 1s for RSSFeeds. 02:47.07 FORK(19752) --- fork finished for 'RSSFeeds' --- 02:47.46 Chans: (ghostbot) in:#ghostscript 02:58.56 --- Saved uptime records. 03:03.10 Chans: (ghostbot) in:#ghostscript 03:07.44 >>> JakeSays has signed off IRC (Read error: Connection reset by peer) [#ghostscript] 03:08.34 >>> join/#ghostscript JakeSays (~quassel@63.226.106.92) 03:10.01 >>> join/#ghostscript JakeSaysSays (~quassel@63.226.106.92) 03:13.06 >>> JakeSays has signed off IRC (Ping timeout: 256 seconds) [#ghostscript] 03:17.12 FORK(24593) --- fork starting for 'RSSFeeds', PID == 24593, bot_pid == 948 --- 03:17.13 FORK(24593) !ERROR! cannot load my module: RSSFeeds 03:17.13 FORK(24593) fork: took 1s for RSSFeeds. 03:17.13 FORK(24593) --- fork finished for 'RSSFeeds' --- 03:18.07 >>> JakeSaysSays materializes into JakeSays 03:19.18 Chans: (ghostbot) in:#ghostscript 03:26.51 >>> join/#ghostscript JakeSaysSays (~quassel@63.226.106.92) 03:29.03 >>> JakeSays has signed off IRC (Ping timeout: 240 seconds) [#ghostscript] 03:29.40 >>> JakeSaysSays materializes into JakeSays 03:30.00 ircCheck: possible lost in space; checking.Tue May 28 03:30:00 2013 03:30.00 >ghostbot< TEST 03:30.00 IRCTEST: Yes, we're alive. 03:35.07 Chans: (ghostbot) in:#ghostscript 03:37.25 >>> JakeSays materializes into JakeSaysSays 03:37.52 >>> JakeSaysSays materializes into JakeSays 03:45.56 >>> join/#ghostscript plinnell (~mrdocs@c-76-102-153-54.hsd1.ca.comcast.net) 03:45.56 >>> plinnell has signed off IRC (Changing host) [#ghostscript] 03:45.56 >>> join/#ghostscript plinnell (~mrdocs@opensuse/member/mrdocs) 03:47.21 >>> join/#ghostscript JakeSaysSays (~quassel@63.226.106.92) 03:47.59 FORK(23606) --- fork starting for 'RSSFeeds', PID == 23606, bot_pid == 948 --- 03:48.00 FORK(23606) !ERROR! cannot load my module: RSSFeeds 03:48.00 FORK(23606) fork: took 1s for RSSFeeds. 03:48.00 FORK(23606) --- fork finished for 'RSSFeeds' --- 03:49.59 >>> JakeSays has signed off IRC (Ping timeout: 256 seconds) [#ghostscript] 03:50.11 !WARN! PERL: readdir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 862. 03:50.11 !WARN! PERL: closedir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 869. 03:51.11 Chans: (ghostbot) in:#ghostscript 03:54.31 >>> JakeSaysSays has signed off IRC (Ping timeout: 256 seconds) [#ghostscript] 03:58.49 >>> join/#ghostscript JakeSays (~quassel@63.226.106.92) 03:59.19 --- Saved uptime records. 04:08.07 Chans: (ghostbot) in:#ghostscript 04:09.13 >>> henrys has signed off IRC (Quit: henrys) [#ghostscript] 04:09.36 >>> join/#ghostscript JakeSaysSays (~quassel@63.226.106.92) 04:11.24 >>> JakeSays has signed off IRC (Ping timeout: 240 seconds) [#ghostscript] 04:14.05 >>> JakeSaysSays materializes into JakeSays 04:18.25 FORK(22613) --- fork starting for 'RSSFeeds', PID == 22613, bot_pid == 948 --- 04:18.26 FORK(22613) !ERROR! cannot load my module: RSSFeeds 04:18.26 FORK(22613) fork: took 1s for RSSFeeds. 04:18.26 FORK(22613) --- fork finished for 'RSSFeeds' --- 04:21.44 >>> join/#ghostscript alireza (413144ad@gateway/web/freenode/ip.65.49.68.173) 04:22.55 >>> join/#ghostscript JakeSaysSays (~quassel@63.226.106.92) 04:24.32 >>> JakeSaysSays materializes into JakeSays2 04:24.41 >>> JakeSays2 has signed off IRC (Client Quit) [#ghostscript] 04:24.51 Chans: (ghostbot) in:#ghostscript 04:25.06 >>> join/#ghostscript JakeSays2 (~quassel@63.226.106.92) 04:25.07 >>> JakeSays has signed off IRC (Ping timeout: 256 seconds) [#ghostscript] 04:25.35 >>> JakeSays2 materializes into JakeSays 04:25.45 >>> join/#ghostscript alireza_ (413144ad@gateway/web/freenode/ip.65.49.68.173) 04:25.50 How can i read pdf file as bytes , while using MuPdf Im using my own encryption/decryption and i need in first step decrypt pdf in ram 04:26.17 >>> alireza has signed off IRC (Ping timeout: 250 seconds) [#ghostscript] 04:26.41 >>> JakeSays materializes into JakeSays2 04:27.04 >>> JakeSays2 materializes into group 04:27.37 >>> group materializes into JakeSays2 04:28.15 >>> JakeSays2 materializes into JakeSays3 04:28.22 >>> JakeSays3 materializes into JakeSays4 04:28.31 >>> JakeSays4 materializes into JakeSays 04:30.11 >>> alireza_ has signed off IRC (Ping timeout: 250 seconds) [#ghostscript] 04:40.57 Chans: (ghostbot) in:#ghostscript 04:49.03 FORK(23182) --- fork starting for 'RSSFeeds', PID == 23182, bot_pid == 948 --- 04:49.04 FORK(23182) !ERROR! cannot load my module: RSSFeeds 04:49.04 FORK(23182) fork: took 1s for RSSFeeds. 04:49.04 FORK(23182) --- fork finished for 'RSSFeeds' --- 04:49.07 >>> sivoais has signed off IRC (Ping timeout: 260 seconds) [#ghostscript] 04:49.38 >>> join/#ghostscript mvrhel_laptop (~chatzilla@c-50-149-95-73.hsd1.wa.comcast.net) 04:49.57 >>> join/#ghostscript sivoais (~zaki@unaffiliated/sivoais) 04:56.11 Seen: Flushed 1 entries. 04:56.31 Chans: (ghostbot) in:#ghostscript 04:59.16 >>> sivoais has signed off IRC (Read error: Connection reset by peer) [#ghostscript] 04:59.56 --- Saved uptime records. 04:59.58 >>> join/#ghostscript sivoais (~zaki@unaffiliated/sivoais) 05:08.12 >>> sivoais has signed off IRC (Ping timeout: 256 seconds) [#ghostscript] 05:09.56 >>> join/#ghostscript sivoais (~zaki@unaffiliated/sivoais) 05:11.43 >>> join/#ghostscript marcosw_ (~marcosw@67.169.6.130) 05:12.23 Chans: (ghostbot) in:#ghostscript 05:17.27 >>> sivoais has signed off IRC (Ping timeout: 240 seconds) [#ghostscript] 05:19.11 FORK(21254) --- fork starting for 'RSSFeeds', PID == 21254, bot_pid == 948 --- 05:19.12 FORK(21254) !ERROR! cannot load my module: RSSFeeds 05:19.12 FORK(21254) fork: took 1s for RSSFeeds. 05:19.12 FORK(21254) --- fork finished for 'RSSFeeds' --- 05:19.57 >>> join/#ghostscript sivoais (~zaki@unaffiliated/sivoais) 05:28.39 Chans: (ghostbot) in:#ghostscript 05:28.39 ircCheck: possible lost in space; checking.Tue May 28 05:28:39 2013 05:28.39 >ghostbot< TEST 05:28.39 IRCTEST: Yes, we're alive. 05:28.43 >>> sivoais has signed off IRC (Ping timeout: 264 seconds) [#ghostscript] 05:29.59 >>> join/#ghostscript sivoais (~zaki@unaffiliated/sivoais) 05:38.48 >>> sivoais has signed off IRC (Ping timeout: 256 seconds) [#ghostscript] 05:40.00 >>> join/#ghostscript sivoais (~zaki@unaffiliated/sivoais) 05:44.32 Chans: (ghostbot) in:#ghostscript 05:48.26 >>> sivoais has signed off IRC (Ping timeout: 256 seconds) [#ghostscript] 05:49.26 FORK(18925) --- fork starting for 'RSSFeeds', PID == 18925, bot_pid == 948 --- 05:49.27 FORK(18925) !ERROR! cannot load my module: RSSFeeds 05:49.27 FORK(18925) fork: took 1s for RSSFeeds. 05:49.27 FORK(18925) --- fork finished for 'RSSFeeds' --- 05:49.59 >>> join/#ghostscript sivoais (~zaki@unaffiliated/sivoais) 05:58.35 >>> sivoais has signed off IRC (Ping timeout: 256 seconds) [#ghostscript] 06:00.01 >>> join/#ghostscript sivoais (~zaki@unaffiliated/sivoais) 06:00.21 Chans: (ghostbot) in:#ghostscript 06:00.21 --- Saved uptime records. 06:08.50 >>> sivoais has signed off IRC (Ping timeout: 256 seconds) [#ghostscript] 06:10.01 >>> join/#ghostscript sivoais (~zaki@unaffiliated/sivoais) 06:15.55 >>> sivoais has signed off IRC (Read error: Connection reset by peer) [#ghostscript] 06:16.22 >>> join/#ghostscript sivoais (~zaki@unaffiliated/sivoais) 06:16.32 Chans: (ghostbot) in:#ghostscript 06:19.34 FORK(13177) --- fork starting for 'RSSFeeds', PID == 13177, bot_pid == 948 --- 06:19.35 FORK(13177) !ERROR! cannot load my module: RSSFeeds 06:19.35 FORK(13177) fork: took 1s for RSSFeeds. 06:19.35 FORK(13177) --- fork finished for 'RSSFeeds' --- 06:31.54 LOG: last message repeated 3 times 06:31.54 ircCheck: possible lost in space; checking.Tue May 28 06:31:54 2013 06:31.54 >ghostbot< TEST 06:31.54 IRCTEST: Yes, we're alive. 06:36.34 >>> chrisl_away materializes into chrisl 06:43.35 >>> join/#ghostscript tor8 (~tor@c-bd7871d5.04-50-6c756e10.cust.bredbandsbolaget.se) 06:48.37 Chans: (ghostbot) in:#ghostscript 06:49.59 FORK(8732) --- fork starting for 'RSSFeeds', PID == 8732, bot_pid == 948 --- 06:50.00 FORK(8732) !ERROR! cannot load my module: RSSFeeds 06:50.00 FORK(8732) fork: took 1s for RSSFeeds. 06:50.00 FORK(8732) --- fork finished for 'RSSFeeds' --- 06:56.53 >>> join/#ghostscript kens (~Miranda@159.79.112.87.dyn.plus.net) 07:00.49 --- Saved uptime records. 07:04.41 Chans: (ghostbot) in:#ghostscript 07:20.27 FORK(5453) --- fork starting for 'RSSFeeds', PID == 5453, bot_pid == 948 --- 07:20.28 FORK(5453) !ERROR! cannot load my module: RSSFeeds 07:20.28 FORK(5453) fork: took 1s for RSSFeeds. 07:20.28 FORK(5453) --- fork finished for 'RSSFeeds' --- 07:36.31 ircCheck: possible lost in space; checking.Tue May 28 07:36:31 2013 07:36.31 >ghostbot< TEST 07:36.31 IRCTEST: Yes, we're alive. 07:37.50 >>> mvrhel_laptop has signed off IRC (Quit: ChatZilla 0.9.90 [Firefox 21.0/20130511120803]) [#ghostscript] 07:50.19 !WARN! PERL: readdir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 862. 07:50.19 !WARN! PERL: closedir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 869. 07:50.49 FORK(4301) --- fork starting for 'RSSFeeds', PID == 4301, bot_pid == 948 --- 07:50.50 FORK(4301) !ERROR! cannot load my module: RSSFeeds 07:50.50 FORK(4301) fork: took 1s for RSSFeeds. 07:50.50 FORK(4301) --- fork finished for 'RSSFeeds' --- 07:51.41 >>> kens has signed off IRC (Read error: Connection reset by peer) [#ghostscript] 07:52.21 Chans: (ghostbot) in:#ghostscript 07:59.09 >>> join/#ghostscript kens (~Miranda@159.79.112.87.dyn.plus.net) 08:01.19 --- Saved uptime records. 08:08.35 Chans: (ghostbot) in:#ghostscript 08:20.57 FORK(29989) --- fork starting for 'RSSFeeds', PID == 29989, bot_pid == 948 --- 08:20.58 FORK(29989) !ERROR! cannot load my module: RSSFeeds 08:20.58 FORK(29989) fork: took 1s for RSSFeeds. 08:20.58 FORK(29989) --- fork finished for 'RSSFeeds' --- 08:26.14 LOG: last message repeated 3 times 08:26.14 >>> join/#ghostscript paulgardiner (~chatzilla@smtp.glidos.net) 08:33.15 paulgardiner: Morning 08:33.31 henrys spotted something yesterday in the android app. 08:33.35 hi. I saw the thing about select text in reflw 08:33.50 Was there anything else> 08:33.52 ? 08:33.58 no, that was it. 08:34.45 I'll see I can sort that out. I had problems downloading the ndk last night, but hopefully I can get it now. 08:41.15 Chans: (ghostbot) in:#ghostscript 08:51.55 FORK(714) --- fork starting for 'RSSFeeds', PID == 714, bot_pid == 948 --- 08:51.56 FORK(714) !ERROR! cannot load my module: RSSFeeds 08:51.56 FORK(714) fork: took 1s for RSSFeeds. 08:51.56 FORK(714) --- fork finished for 'RSSFeeds' --- 08:57.29 Seen: Flushed 2 entries. 09:01.16 With r8e I can now build but clean fails 09:02.06 --- Saved uptime records. 09:02.27 paulgardiner: ndk-build clean fails? 09:02.33 yes 09:02.39 yeah, they made changes. 09:02.50 I do ndk-build under a DOS window. Where are you running it ? 09:03.00 It still seems to cause a complete rebuild 09:04.43 odd. It's r8e that I'm using here, and it only rebuilds what it needs to. 09:05.02 stupid question: have you still got the old one in your path ? 09:05.28 No sorry. I mean clean still seems to work although it reports failure 09:07.59 BTW, I found that to build without explicitly mentioning the location of the ndk, I just had to put it on the path. 09:08.30 paulgardiner: Right. I have always had the NDK on the path. 09:09.40 Ah right, so had I, but had forgot that that's what's needed since last time I changed NDK. 09:13.35 Chans: (ghostbot) in:#ghostscript 09:21.00 paulgardiner: Should we disable printing as well from reflow mode ? 09:21.46 If so, then we should probably disable the whole menu. 09:22.00 robin_watts: I think it still works, although it wouldn't be the reflowed version that was printed (well - the way cloud pring works, it might be) 09:22.33 FORK(559) --- fork starting for 'RSSFeeds', PID == 559, bot_pid == 948 --- 09:22.34 FORK(559) !ERROR! cannot load my module: RSSFeeds 09:22.34 FORK(559) fork: took 1s for RSSFeeds. 09:22.34 FORK(559) --- fork finished for 'RSSFeeds' --- 09:22.35 paulgardiner: ? 09:23.12 I think print works, but it will still just send the pdf to cloud print. 09:23.23 right, so it won't be the reflowed version. 09:23.35 which makes me think we should disable printing in reflow mode. 09:23.57 Well it shouldn't be, but my attempts at using cloud print has yielded reflowed text 09:24.11 robin_watts: yeah ok. Makes sense 09:24.48 hmm. I get print failed. 09:24.57 even without picking a printer. 09:25.23 Only in reflow mode? 09:25.48 in normal mode too. 09:27.02 Why does the reflow button have a contentDescription of "search_document" ? 09:28.36 copy-and paste screw up I'd guess 09:28.44 Print works for me 09:29.29 Chans: (ghostbot) in:#ghostscript 09:29.36 ... although I still get a reflowed page - badly at that 09:29.43 likewise outline view. 09:29.56 ok, so maybe it's my printer setup or something. 09:30.05 You get a reflowed page printed? 09:31.09 Yes, but not reflowed by the app of course 09:31.38 paulgardiner: So do you get the same thing printed whether it's from reflowed mode, or not ? 09:31.47 Yes 09:32.12 ok, so I think we should disable the print button (and the whole menu in fact) when in reflow mode. 09:32.31 At some point we should possibly consider offering PWG printing as an option. 09:33.18 rather than saving the PDF page out, we'd print to PWG raster and send that. 09:33.19 Yes. I'm just making the change now to disable the whole menu 09:38.11 We don't have "reflow mode" in our translated list of strings. Closest is "Entering reflow mode" 09:39.09 I guess if I add one, it will come out in english for all languages 09:45.13 Chans: (ghostbot) in:#ghostscript 09:49.44 robin_watts: ok. Patch is up 09:53.21 FORK(2325) --- fork starting for 'RSSFeeds', PID == 2325, bot_pid == 948 --- 09:53.22 FORK(2325) !ERROR! cannot load my module: RSSFeeds 09:53.22 FORK(2325) fork: took 1s for RSSFeeds. 09:53.22 FORK(2325) --- fork finished for 'RSSFeeds' --- 09:55.57 Ta. 09:57.45 Seen: Flushed 2 entries. 10:01.17 Chans: (ghostbot) in:#ghostscript 10:02.09 --- Saved uptime records. 10:02.44 Pushed, thanks. 10:02.45 >>> join/#ghostscript sojic (~sojic@77.29.223.96) 10:12.14 robin_watts, tor8: I've just pushed another one up to my repo. Changes all access the xref table to be via an interface. Perhaps best not to take on before generating the new android release 10:17.11 Chans: (ghostbot) in:#ghostscript 10:19.15 paulgardiner: In pdf_repair.c ... 10:19.36 you get the len (1 function call). If it's not long enough, we call resize (another function call). 10:19.49 Then we call pdf_get_xref_entry (another function call) 10:20.04 Can we not call pdf_get_xref_entry and have that resize if required ? 10:21.24 In pdf_repair_obj_streams we call pdf_xref_len every time around the loop. 10:21.41 I wondered about that. Then I think we have to decide on the strategy used to increase the allocation and have the choice between wasting memory or reallocing every call 10:21.53 twice. 10:22.08 pdf_get_xref_entry_resizing ? 10:22.17 yes 10:22.54 I mean, we could have a separate entry point that got the pdf_xref and resized if required. 10:23.07 I was looking to make the changes as small and obvious as possible for now. 10:23.13 In lots of places we call pdf_get_xref and then assume that it's non-NULL. 10:23.50 To date this has meant calling pdf_xref_len and checking that i < len 10:24.00 FORK(6294) --- fork starting for 'RSSFeeds', PID == 6294, bot_pid == 948 --- 10:24.01 FORK(6294) !ERROR! cannot load my module: RSSFeeds 10:24.01 FORK(6294) fork: took 1s for RSSFeeds. 10:24.01 FORK(6294) --- fork finished for 'RSSFeeds' --- 10:24.16 and that means the get can't fail. 10:24.48 but if our intention is to keep the xrefs as a sequence of tables going backwards in time, might there not be gaps between the tables? 10:25.08 i.e. the first xref might define 0-100, and the second might then define 200-300 10:25.29 so if someone asks for object 150, 150 < 300, but there is no object to return ? 10:26.23 Also, I don't think it should be pdf_get_xref_entry - maybe lookup instead? tor dislikes get. 10:28.04 I have these things in mind, but this patch was just supposed to do most of the changes for the sake of adding the interface, while being minimal. 10:28.48 I get that, but adding having an interface for the sake of having an interface doesn't feel like a step forward. 10:29.17 It was just to get the parts in that will conflict with other peoples changes. 10:30.19 To make a step forward, I will need the interface in place. 10:31.05 I was just trying to avoid building up the whole chunk of work while frequently rebasing changes all over the source. 10:31.44 ok. 10:32.52 I could address some of the efficiency concerns if I can still keep the changes pretty minimal and obvious. 10:33.13 I worry that to fix the interface you're going to need to change every line that you've just changed here. 10:33.45 I had thought before about making get_entry perform allocation, but then there's the worry of doing multiple reallocs, or using len doubling and wasting space. 10:34.05 Chans: (ghostbot) in:#ghostscript 10:34.28 Well, if we use a separate entry point (lookup_with_resize), then it can perform exactly as it currently does, no? 10:34.30 In any case, I think I will eventually need two forms of get_entry, one for access the existing entry and one for creating a new one 10:37.16 pdf_set_xref_trailer... why not have that take the reference it's passed ? 10:37.24 paulgardiner: I can't help but think that pdf_resize_xref should be private, and automatic 10:37.25 Oh! Right! In pdf_repair_obj_stm: I'd remembered that as doing the len check before the loop, but it does it repeatedly 10:37.57 pdf_*_xref_entry will allocate a slot in the xref table and return a pointer to it 10:38.13 In lots of places you get the length in the for loop. 10:38.31 Oh ok. Somehow I hadn't picked that up. 10:38.51 however, maybe we don't need to expose the pdf_xref_entry struct at all if we make a call like pdf_update_xref_slot(xref, index, type, ofs, gen, stm_ofs) ? 10:38.52 I though I saw several places where we were checking before the loop. 10:38.57 pdf_set_xref_trailer: Everywhere it's called you pass in a reference, the routine takes the reference, then the caller drops the reference. 10:39.59 tor8: I think that would be clumsy. 10:40.19 paulgardiner: Having just dumped all over it, I actually think it's a reasonable step on the way to where we want to be. 10:40.21 pdf_set_xref_trailer: I thought that was sort of the paradigm we use in mupdf. Lots of functions do that. 10:40.27 Robin_Watts: probably, yes. just a thought. 10:40.37 and I must go pack, so bbiab, sorry. 10:42.27 Making the allocation private and automatic was originally my intention. Looking now, I'm not sure why I changed my mind. 10:43.42 >>> sojic has signed off IRC (Remote host closed the connection) [#ghostscript] 10:44.55 paulgardiner: robin probably needs to pipe in, but pdf_xref_obj looks out of place to me (we already have pdf_load_object which does the same, and a little bit more) 10:45.11 maybe it's not safe to load the object when renumbering the xref 10:45.15 Line 406 of pdf_repair.c allocates to max before a loop... but I could use the "trick" of calling get_entry before the loop for the max entry. Is that nasty? 10:45.51 tor8: Good point. Yes: see what Robin says. 10:46.13 paulgardiner: how about pdf_new_xref(maxnum + 1) ? 10:46.20 >>> join/#ghostscript sojic (~sojic@77.29.223.96) 10:46.36 I'm thinking we want a whole new api for just creating xrefs in two different ways 10:46.46 either by repairing, or by reading xref sections 10:46.58 so maybe separate the initial xref setup from the xref table creation a bit more 10:47.10 this looks like a good step towards that, but I think we can go further 10:47.14 Three: when making document changes. 10:47.31 and three: modifying an existing xref 10:47.41 yes 10:47.44 and four: cleaning it up before saving it 10:47.46 and five: saving it 10:48.04 and five b: saving an incremental update to it 10:48.26 and of course the implicit, "get stuff out of it" :) 10:48.32 Yes, but - as I said before - I'm looking now just to make some initial changes to avoid rebasing while I do the main body of work 10:48.55 yeah, I'm not averse to incremental updates getting there and breaking stuff along the way 10:49.15 So the interface doesn't need to be exactly correct, just reasonably close. 10:50.05 Chans: (ghostbot) in:#ghostscript 10:51.46 we have functions to: create (allocate), delete and update objects in the xref 10:52.04 now we need functions to do the same on slots in the xref, at a lower level 10:52.29 something to match pdf_create_object, pdf_delete_object, pdf_update_object but per slot, right? 10:52.51 I'm not sure. 10:52.55 pdf_(set_)xref_trailer is good to go, including the reference counting robin griped about anyway 10:53.13 Most of the time we will need exactly what we already have. 10:53.17 not too happy about pdf_xref_len, _obj, and pdf_replace_xref 10:54.01 maybe we should disconnect the xref table from the pdf_document struct? 10:54.11 FORK(22088) --- fork starting for 'RSSFeeds', PID == 22088, bot_pid == 948 --- 10:54.12 FORK(22088) !ERROR! cannot load my module: RSSFeeds 10:54.12 FORK(22088) fork: took 1s for RSSFeeds. 10:54.12 FORK(22088) --- fork finished for 'RSSFeeds' --- 10:54.20 so we can manipulate multiple xrefs without having it tied to an actual document 10:54.44 that would help renumberobjs and the repair code I think 10:55.09 * sebras/#ghostscript always gets nervous when renumberobjs is mentioned. 10:55.17 Yeah, in the plan, but I just wanted to get an interface in place for now. 10:55.21 pdf_get_xref_entry serves dual purpose here, both to read and to get a pointer to update 10:55.29 tor8: That might be nice, if it means we can clone an xref, then do the pdf clean stuff on that cloned xref, and save it out without being destructive to the original xref. 10:55.37 paulgardiner: certainly. one step at a time. 10:55.59 I did have a separate opaque pdf_xref type, but I took it out because I am so far not changing behaviour (hopefully) 10:56.01 but I think separating the pdf_xref_table from the pdf_document would make xref table manipulations and iterations clearer in the interface. 10:56.20 robin_watts: yes I wondered about that. 10:56.28 and having that one be a linked list internally for the sections would fall out naturally 10:57.04 >>> sojic has signed off IRC (Remote host closed the connection) [#ghostscript] 10:57.09 and as robin said, we can edit a cloned xref table without clobbering the original 10:57.13 tor8: yes, next step would be to change the existing table to something that can hold the sections 10:57.55 tor8: yes, we need to be able to add a new section for the sake of edits in any case 10:57.55 Seen: Flushed 3 entries. 10:57.57 paulgardiner: can you split the xref_trailer changes out into a separate patch then we can commit that at once 10:58.30 or maybe we should rename it pdf_document_trailer if we're splitting the pdf_xref_table out? 10:58.40 I could, but I'd rather get the rest to a state everyone is happy with. 10:58.42 to separate the pdf_xref_* functions from pdf_document_* based on their arguments 10:59.32 We need separate trailers per xref section 10:59.33 >>> join/#ghostscript sojic (~sojic@77.29.223.96) 10:59.34 paulgardiner: I'm always in favor of splitting commits into small independent parts (sebras always blames me for not doing it enough) 10:59.53 Okaty. I'll do that and be back. 10:59.57 paulgardiner: yeah, but most users of a trailer only needs the latest one, so that should be accessed through pdf_document 11:00.18 so s/pdf_xref_trailer/pdf_document_trailer/ and make that one commit without the other stuff 11:00.19 I can also do the privatisation of xref-resize if that helps 11:00.27 you know how to use git gui to stage individual hunks right? 11:00.43 tor8: yeah sure 11:00.55 just the trailer in one commit, please 11:01.19 (since it touches so many other files) 11:01.41 Is it really pdf_document_trailer? I imagine I am later going to need a version that asks for the trailer of a specific level of xref section. 11:01.56 paulgardiner: we'll need that later too in some places 11:02.18 but things like the pdf_outline and nametree only need the final trailer 11:02.38 --- Saved uptime records. 11:02.44 question: pdf_trailer or pdf_document_trailer? 11:02.57 What if we want to provide the feature of displaying a previous version of the doucment 11:03.14 then you'd rewind the xref on the document, I would imagine 11:03.26 and all pdf_document_trailer and pdf_load_object etc would fall out naturally from that 11:03.36 Ah good. I was thinking, we might want to have a sort of set level method 11:03.44 yeah! 11:04.14 I think pdf_trailer is probably a better name 11:04.19 sounds like there will be a sequence of patches that I want to review when I get home tonight. 11:04.33 the pdf_document_ stuff is more for the "page" level fz_document abstraction 11:04.35 I was thinking of introducing a pdf_xref type, but I don't think we'll ever want to deal with the xref separately from the document. 11:04.35 level 11:05.00 paulgardiner: I think we will, for the repair and saving and renumbering/garbage collection/linearisation code 11:05.09 and the xref loading code, obviously :) 11:05.25 enough places where I think it would help the abstraction to keep the xref table separate from the document 11:05.41 That would be pdf_xref_section, I think, not pdf_xref 11:05.51 Chans: (ghostbot) in:#ghostscript 11:06.03 paulgardiner: I was thinking they could be the same :) 11:06.12 pdf_xref has a trailer and a linked list "next" pointer 11:06.17 and a table 11:06.43 and pdf_document would point at the last such pdf_xref (_section) for its xref 11:07.16 or were you thinking a pdf_xref_section as such, and a separate wrapper pdf_xref that held those with some extra data and as a high level interface for allocating new sections and setting the level? 11:08.12 In a previous version of this, I introduced pdf_xref, and made all the methods take an object of that type, but then I found I almost always needed the doc also (if for nothing else the fz_context) and it was always the docs xref I was passing 11:08.53 So in this version I changed to just passing the doc, thinking we could also pass a level number if we wanted to distinguish sections. 11:13.18 paulgardiner: then you missed the gyrations we go through because the xref table being tied to the document in the object renumbering code :) 11:14.21 yeah, but that could probably be done by access two levels at once, or perhaps even having a renumbering method 11:15.23 spawn a new level; repeatedly { grab from one level down; put in top level} 11:15.55 sounds hacky to me. I prefer less coupling of data structures. 11:17.08 I was thinking it wasn't unlike the process of updating a document, where many object are still obtained from lower sections, but new additions go in the top section 11:17.35 ... but maybe that isn't a good way to think about it. I have to admit I don't completely understand the renumbering code. 11:18.49 I think when accessing objects at a high level, you're dealing with a document and the current way of having an implicit one-and-only xref makes sense 11:19.45 but doing these table manipulations, when loading and repairing, and in the garbage collection and renumbering and when saving out the document, having explicit xref table structs would help 11:20.41 an xref is still tied to a given document, but you can have multiple independent xrefs (that still point to the same file and offsets of objects in the file) in different states of completion 11:20.58 maybe it's a bad idea, I don't know, but I don't think it can hurt 11:21.24 the renumbering still needs to take care to renumber all the indirect references 11:21.44 Chans: (ghostbot) in:#ghostscript 11:22.12 pdf_load_object would probably be refactored to call pdf_xref_load_object on the "current" xref, if we're thinking of the final plan 11:22.35 (can't help but think face-to-face time with pen and paper would help in these sorts of discussions) 11:22.39 Hmm, so the xref type sort of encapsulates the document plus the level of xref section you are dealing with. 11:22.50 http://ghostscript.com/~robin/MuPDF-40.apk 11:23.30 Even across IRC it's been very useful. 11:24.30 FORK(17380) --- fork starting for 'RSSFeeds', PID == 17380, bot_pid == 948 --- 11:24.31 FORK(17380) !ERROR! cannot load my module: RSSFeeds 11:24.31 FORK(17380) fork: took 1s for RSSFeeds. 11:24.31 FORK(17380) --- fork finished for 'RSSFeeds' --- 11:29.48 robin_watts: looks good to me 11:30.00 paulgardiner: yeah, I think we might need these structs: pdf_document, pdf_xref, pdf_xref_section and pdf_xref_entry 11:30.27 where the pdf_xref is the "head" of the linked list and has the xref access functions and does the resizing and allocating new sections etc 11:31.13 I did introduce pdf_xref, but decided to take it out again for now while I was just adding part of the interface. 11:31.42 paulgardiner: yeah. it's not crucial until you start adding separate sections 11:32.23 or rather, add the api now without the explicit pdf_xref argument, and then add that in a second commit once we're happy with the names? 11:33.54 Oh yes: pdf_replace_xref was only ever intended to be a temporary addition - juist so that I'd covered all direct access to the table by interfaces. 11:34.00 paulgardiner: http://pastebin.com/hS2qjV8z something like that's what I mean (just to make sure we're on the same page on what I'm actually saying) 11:37.35 Chans: (ghostbot) in:#ghostscript 11:41.49 Yes, pretty much what I was thinking, except I was avoiding for now making pdf_xref explicit in the interface until the stage of adding code that needs it. 11:42.50 right. 11:42.58 And presumably there would be a call to get an entry without specifying a specific xref, like there is for the trailer 11:43.13 paulgardiner: possibly, if we need it 11:43.25 Guys, can you test MuPDF-40 and 41.apk please? 11:43.38 I think a function like that would sit at an uncomfortable level between pdf_*_object and the xref load/edit/save levels 11:43.41 But isn't that the one we mostly need. All the existing code wants the latest trailer 11:44.27 I mean entry not trailer 11:44.49 all the pdf_*_object functions want the latest entry, yes 11:45.11 Oh. Hang on. Maybe most of the code that needs explicit access to the entry is code that is saving or renumbering 11:45.13 I've not read back through the logs yet, but... 11:45.15 so it may make sense to just make those functions that take the latest entry, and then inject the explicit level functions later 11:45.36 the editing and loading would be better off using an explicit one 11:45.57 it seems to me that in order to seamlessly step backwards and forwards through time, we'll want the ability to set the 'current' level on the document. 11:46.12 robin_watts: yes 11:46.18 and that current level will affect what the pdf_*_object returns. 11:46.30 Although, we also need to be able to ask what has changed between levels 11:46.31 so they aren't strictly the "latest" at all times. 11:46.52 Robin_Watts: yeah, we talked about that. having the xref be an explicit struct and the document have a 'current' xref section would do that. 11:47.55 I'm uploading the apks to google play now. I won't publish them until this evening, but I could really do with sanity checks asap please. 11:48.15 difference between -40 and -41? 11:49.05 Robin_Watts: the apks feel sluggish. debug build or release? 11:49.10 We could handle incremental update without mentioning explicit xrefs. By having a get_entry_for_the_purpose_of_update method. That would spawn a new top section if that hadn't been done since loading the doc or last save, and return an entry from that top section 11:49.25 tor8: -40 is armeabi 11:49.32 -41 is armeabi-v7a 11:49.39 tor8: All release builds. 11:50.13 and the difference between those is? (I vaguely recall one of them using fp emulation) 11:50.23 !WARN! PERL: readdir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 862. 11:50.23 !WARN! PERL: closedir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 869. 11:50.32 tor8: v7a has faster fp 11:50.45 40 is softfp, I believe 11:51.32 really, you think they are slower than previous releases? 11:51.52 it takes a good second to open up pdfref13.pdf ... which I think used to be almost instantaneous 11:52.15 tor8: which one? 11:52.18 could be my phone being slow 11:52.25 both -40 and -41 are equally sluggish 11:52.33 lemme reboot it see if that helps 11:54.01 Chans: (ghostbot) in:#ghostscript 11:54.45 ouch. 4 second startup time of pdfref13 from a cold boot :( 11:54.45 FORK(12896) --- fork starting for 'RSSFeeds', PID == 12896, bot_pid == 948 --- 11:54.46 FORK(12896) !ERROR! cannot load my module: RSSFeeds 11:54.46 FORK(12896) fork: took 1s for RSSFeeds. 11:54.46 FORK(12896) --- fork finished for 'RSSFeeds' --- 11:55.07 2 seconds for pdfref17 while warm 11:55.30 do you have an ancient apk sitting somewhere? one from before javascript 11:56.35 tor8: There are various in the same place you got -40 and -41 from. 11:57.43 At the moment it's version 16/17 on google play. 11:57.55 17 being armeabi-v7a 11:58.05 Seen: Flushed 4 entries. 11:59.21 That takes just as long. 12:02.05 version 12 is just as long. 12:02.45 --- Saved uptime records. 12:03.08 right. so probably just my phone being slow then, not a recent regression 12:04.07 version 9 seems faster :( 12:05.13 Robin_Watts: hello bisect. 12:05.17 >>> join/#ghostscript henrys (~henrys@c-50-134-235-109.hsd1.co.comcast.net) 12:05.24 sebras: bugger that. 12:06.56 D:/android-ndk-r8e/toolchains/arm-linux-androideabi-4.6/prebuilt/windows/bin/arm-linux-androideabi-gcc -MMD -MP -MF ./obj/local/armeabi-v7a/objs/mupdfcore/__/__/pdf/pdf_unicode.o.d -fpic -ffunction-sections -funwind-tables -fstack-protector -no-canonical-prefixes -march=armv7-a -mfloat-abi=softfp -mfpu=vfpv3-d16 -mthumb -Os -g -DNDEBUG -fomit-frame-pointer -fno-strict-aliasing -finline-limit=64 -I 12:06.58 ../thirdparty/jbig2dec -I../thirdparty/openjpeg/src/lib/openjp2 -I../thirdparty/jpeg -I../thirdparty/zlib -I../thirdparty/freetype/include -I../draw -I../fitz -I../pdf -I../xps -I../cbz -I../image -I../ucdn -I../scripts -I.. -I../thirdparty/v8-3.9/include -ID:/android-ndk-r8e/sources/cxx-stl/stlport/stlport -ID:/android-ndk-r8e/sources/cxx-stl//gabi++/include -Ijni -DANDROID -DARCH_ARM... 12:06.59 ...-DARCH_THUMB -DARCH_ARM_CAN_LOAD_UNALIGNED -DAA_BITS=8 -Wa,--noexecstack -ID:/android-ndk-r8e/platforms/android-8/arch-arm/usr/include -c jni/../../pdf/pdf_unicode.c -o 12:07.01 ./obj/local/armeabi-v7a/objs/mupdfcore/__/__/pdf/pdf_unicode.o 12:07.32 So it builds with -Os and -DNDEBUG, but it does have -g. 12:07.53 but -g shouldn't affect the speed, right? 12:08.47 Robin_Watts: AFAIK, no. 12:09.17 Chans: (ghostbot) in:#ghostscript 12:16.01 Robin_Watts: -g will make the code bigger, that could affect cacheing, etc 12:16.13 chrisl: Will it? 12:16.27 I thought -g meant "keep debug symbols" 12:16.43 The are stored in the exe 12:16.47 so the .o files are bigger, but the linked final version (assuming -g isn't there on the link) should be the same size. 12:16.57 I will check to see if -g is on the link. 12:18.08 Robin_Watts: even if the linked final version is bigger then I think it is only debug-symbols in the file. 12:18.47 Robin_Watts: and I believe these are in segments that are not loaded by the program loader so I doubt that they will affect performance at all. 12:18.48 sebras: Right, but there is still time taken to load that larger lump off the storage. 12:18.56 sebras: maybe. 12:19.08 you have more faith than I do :) 12:19.16 >>> Fandekasp has signed off IRC (Ping timeout: 276 seconds) [#ghostscript] 12:19.20 >>> chrisl materializes into chrisl_away 12:20.55 >>> join/#ghostscript Fandekasp (~Fandekasp@27-32-19-26.static.tpgi.com.au) 12:21.42 I had the debuggable flag set in the apk. 12:22.03 unsetting that saves 100K from the apk. 12:23.41 Robin_Watts: yes, probably. ;) 12:24.59 FORK(7965) --- fork starting for 'RSSFeeds', PID == 7965, bot_pid == 948 --- 12:25.00 FORK(7965) !ERROR! cannot load my module: RSSFeeds 12:25.00 FORK(7965) fork: took 1s for RSSFeeds. 12:25.00 FORK(7965) --- fork finished for 'RSSFeeds' --- 12:25.59 Chans: (ghostbot) in:#ghostscript 12:26.54 New MuPDF-41.apk online. Still doesn't seem any faster :( 12:30.08 tor8: Still, it's speed when it's up and running seems OK ? 12:31.28 it's = it is. ;) 12:31.46 it's no 60fps updates, but seems okay 12:32.19 tor8: yeah, sorry. 12:32.33 shame, I was hoping the redraw tweaks would have got us to 60fps 12:32.49 trying on my nexus 10 now 12:32.55 (that was my htc desire x) 12:33.21 hmm. I know the desire and the desire hd. don't know the x. 12:33.53 it's a lower powered, slimmer, better battery life one :) 12:34.02 and significantly cheaper! 12:34.40 tor8: feels smoother on the transformer, but maybe that's just me. 12:35.29 hmm. the nexus 10 has some odd epilepsy inducing flicker when paging! 12:35.39 I think that's a show stopper we need to fix. 12:35.43 Robin_Watts: by all means skip the meeting today if you need time to get ready. 12:35.59 oops. 12:36.05 it killed my tablet :( 12:36.16 I held the finger down, massive 60fps flickering, then power down. 12:36.18 tor8: how do you get the flicker when paging? 12:36.38 maybe because I'm low battery 12:36.43 but it's plugged in and charging... 12:37.53 henrys: thanks, I think I should be Ok. 12:41.23 Chans: (ghostbot) in:#ghostscript 12:50.34 robin_watts, tor8: New version pushed. Two parts split up. Renamed pdf_xref_trailer to pdf_trailer. Made pdf_resize_xref private and automatic 12:50.52 * paulgardiner/#ghostscript hides under desk 12:55.15 FORK(3076) --- fork starting for 'RSSFeeds', PID == 3076, bot_pid == 948 --- 12:55.16 FORK(3076) !ERROR! cannot load my module: RSSFeeds 12:55.16 FORK(3076) fork: took 1s for RSSFeeds. 12:55.16 FORK(3076) --- fork finished for 'RSSFeeds' --- 12:57.17 Chans: (ghostbot) in:#ghostscript 12:58.29 Seen: Flushed 6 entries. 13:03.03 --- Saved uptime records. 13:03.08 trailer commit LGTM 13:03.45 robin needs to weigh in about pdf_xref_obj vs pdf_load_object in the second commit 13:04.23 I'm starting to dislike our naming convention :( 13:04.41 pdf_xref_entry as a type collides with pdf_xref_entry as my preferred name for "pdf_get_xref_entry" 13:05.19 tor8: pdf_xref_entry_f() to signify that it is a function? *being ironic* 13:05.39 (PdfXrefEntry camelcase types, or no typedef explicit s"struct pdf_xref_entry" would have been my preference) 13:05.41 (as usually people solve this by appending _t to identify types...) 13:05.53 yeah. ick. 13:06.40 sebras: pdf_xref_entry__pdf_xref_entry__pdf_document__int() to make sure you know what all the arguments are and the return value! 13:06.58 or we can just write it all in ObjC ;) 13:07.18 >>> join/#ghostscript gandaro (~gandaro@wikipedia/Gorlingor) 13:07.42 * sebras/#ghostscript detects a serious suggestion. 13:13.53 Chans: (ghostbot) in:#ghostscript 13:21.42 I quite like the _t thing. Makes the types stand out - but not mixed use within the project obviously. :-) 13:23.52 Oh - pretty sure I don't like this so I imagine you wont, but: Type pdf_xref_entry, function pdf_xrefs_entry 13:24.19 I think I would like it if I could put the apostrophy in 13:24.56 paulgardiner: genitive s? it's a thought. but not now, we'd have to rename too much to match. 13:25.26 FORK(30716) --- fork starting for 'RSSFeeds', PID == 30716, bot_pid == 948 --- 13:25.27 FORK(30716) !ERROR! cannot load my module: RSSFeeds 13:25.27 FORK(30716) fork: took 1s for RSSFeeds. 13:25.27 FORK(30716) --- fork finished for 'RSSFeeds' --- 13:26.10 >>> kens has signed off IRC (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) [#ghostscript] 13:26.27 >>> join/#ghostscript kens (~Miranda@159.79.112.87.dyn.plus.net) 13:26.52 tor8: so, with a recharged nexus 10, does it still flicker/crash? 13:27.24 * Robin_Watts/#ghostscript was at pains to ask for people to test stuff a few days ago, specifically to avoid this kind of last minute problem :( 13:29.02 nope, it must've been low power related 13:29.15 tor8: phew! 13:29.25 Does it look like 60fps or not? 13:29.39 gah, I finally figured out why I sometimes "fail" the flipping gesture 13:29.49 Chans: (ghostbot) in:#ghostscript 13:29.53 if the finger leaves the screen off the bottom edge, it won't flip 13:29.55 I was really hopeful that the overdraw fixes might have got us to 60fps. 13:30.33 it looks pretty smooth, but not sure if it hits 60fps consistently 13:30.49 it may just be dropping a few frames a second, and that'll make it look jerky 13:30.53 I think previously we were hitting 30fps all the time. 13:31.19 it's noticeably laggy though... the page trails after the finger motion by about 1/3 of a second 13:31.43 or 1/5 or something like that 13:31.44 I'm not seeing any sluggishness here, but maybe it just isn't apparent on the S2... or my eyes aren't sensitive to it 13:32.11 it has some ease-in-ease-out animatin thing going on that delays the page tracking 13:32.30 probably makes it look cooler, but probably a main reason why android feels sluggish compared to ios 13:33.01 page almost feels stuck to my finger on S2 13:33.12 on portrait mode I get these jerky stops when panning between pages 13:33.20 landscape mode, less noticeable 13:33.58 There is a slight lag on the transformer. 13:34.04 portrait is not hitting 60fps consistently 13:34.25 we should all go and buy high speed cameras! 13:34.40 This has to be in the Java, right? And I'd have though that we haven't changed anything in the java that could affect this other than the overdraw patch, and that has to speed it up if anything 13:35.35 The slowdown in document loading is probably in the native code, and the redraw 'lag' is probably down to the java. 13:35.42 the stop/jerk might be context switches when queuing up a new page render that causes it to miss a few frames 13:35.44 S2 has to be hitting 60. Looks very smooth and I think I'd notice dropped frames 13:35.53 it happens when the page is exactly halfway across 13:36.18 I can't see that we can ever be worse w.r.t. redraw than we were before. 13:36.30 Robin_Watts: it's not worse that before! 13:36.35 This page flipping, not dragging while zoomed in then? 13:36.39 but possibly more noticable when frames are dropped :) 13:37.21 the jerking doesn't happen when zoomed in, only when flipping and only when the page crosses the 50% halfway line 13:37.43 it's silky smooth, then BAM ten dropped frames, then a big jump to catch up 13:38.06 tor8: yeah, I get the slight 'tug' as we drag from page to page. 13:38.12 I would expect that. 13:38.12 but I have to say, I quite like it. 13:38.21 It means I get to 'feel' when I've moved to the next page. 13:38.23 (robin_watts: sorry, didn't get any time to look at the apks over the weekend) 13:38.32 Robin_Watts: I hate it. 13:38.59 gaaah! 13:38.59 could we try not queuing until the next page has settled / animation stopped? 13:39.26 google play won't accept me uploading these apks. All it says is "Upload failed" 13:39.27 I don't want to see it jerk just because of what happens in the background. this is a multi-core device dammit! 13:39.55 presumably because it has had apk's 40,41,42,43 before, even though I never published them, and deleted them. 13:40.07 I think delaying the queuing up of new jobs until after animations would make the page tab look smoother as well 13:43.21 robin_watts: could you have run out of space on their server because their not really deleting them? 13:45.18 I cannot delete any apk that has ever been published. 13:45.25 therefore I don't believe space can be an issue. 13:45.45 Chans: (ghostbot) in:#ghostscript 13:46.02 Yeah. Space can't really be an issue with Google 13:46.13 tor8: I don't think that's something we can try to do today. paulgardiner ? 13:47.38 >>> join/#ghostscript monxalo (55f647e7@gateway/web/freenode/ip.85.246.71.231) 13:47.43 robin_watts: I think it would be risky to attempt something like that just before a release 13:48.39 paulgardiner: I want to try it on a branch, and hold off on merging it until after this release. 13:49.06 Yeah sure. No problem with that 13:49.15 and preferably before we forget :) 13:49.53 in fact, doing it myself gives me more excuses to procrastinate from the loom specter of Gtk+ 13:50.49 tor8: but you're still going to have that done by the next meeting, right? :) 13:51.03 * tor8/#ghostscript breaks down and cries. 13:51.09 I probably can't help much. I'm pretty sure my S2 isn't showing the problem 13:55.27 tor8: there, there. I'm showing up at your place tonight. we can be baffled over GTK+ together! :) 13:55.28 FORK(23135) --- fork starting for 'RSSFeeds', PID == 23135, bot_pid == 948 --- 13:55.29 FORK(23135) !ERROR! cannot load my module: RSSFeeds 13:55.29 FORK(23135) fork: took 2s for RSSFeeds. 13:55.29 FORK(23135) --- fork finished for 'RSSFeeds' --- 13:56.17 or tear our few remaining hairs out over android multithreading issues... 13:58.17 tor8: if we have to resort to hair tearing I'm not sure I want to show up. 13:58.57 Seen: Flushed 4 entries. 14:01.47 Chans: (ghostbot) in:#ghostscript 14:03.07 --- Saved uptime records. 14:08.59 Hello there, paulgardiner can you help me with some insights/directions to implement a 2 page view on the android app? :) 14:09.36 Btw, thanks for the documentation on the classes, that helps a lot. :) 14:10.21 >>> marcosw_ has signed off IRC (Quit: marcosw_) [#ghostscript] 14:10.51 monxalo: Yes, sure. I think I my have a patch on an old branch. I'll just take a look 14:12.05 tor8, you'll use gtk+ for the GUI ? 14:12.35 Great, so the approach i'm going, is using a container (ViewGroup) to wrap around 2 MuPDFPageView, in an effort to reuse most of the classes. 14:12.44 monxalo: There's this patch: http://git.ghostscript.com/?p=user/paulg/mupdf.git;a=commitdiff;h=3eb2c1685f1e9774eb8c2c8f953bae8190c14618 14:13.34 Thanks, that looks a lot simpler. :) 14:14.13 monxalo: I was imagining that you'd want to alter ReaderView. It's that class that controls the motion of the pages and could bring two onto the screen rather than one 14:15.04 Ah yes. This patch seems to change only ReaderView 14:15.22 I'd imagine that if you were going to start having 2 pages on the screen at once, you'd want to make it so that we cache 4 pages rather than 3. 14:15.22 You may want also to add more cached pages in mupdf.c 14:16.08 Ha. I beat you to it that time... uusual. 14:16.16 unusual 14:16.40 Humm, and this also handles zooming, updateHq on each respective page region? 14:17.11 Chans: (ghostbot) in:#ghostscript 14:17.34 monxalo: I'd have thought so. It's been a while. At least it would be a good starting point. 14:18.01 >>> sivoais has signed off IRC (Ping timeout: 249 seconds) [#ghostscript] 14:18.02 >>> alexcher has signed off IRC (Ping timeout: 249 seconds) [#ghostscript] 14:18.02 >>> deleet has signed off IRC (Ping timeout: 249 seconds) [#ghostscript] 14:18.04 >>> join/#ghostscript deleet_ (~deleet@chronos.andreferreira.com) 14:18.12 >>> join/#ghostscript alexcher (~alexcher@pool-173-49-254-118.phlapa.fios.verizon.net) 14:18.29 Eheh, 1 year patch :). 14:18.43 >>> join/#ghostscript sivoais (~zaki@unaffiliated/sivoais) 14:19.40 gah. I still can't upload to google :( 14:21.23 >>> chrisl_away materializes into chrisl 14:25.37 FORK(18217) --- fork starting for 'RSSFeeds', PID == 18217, bot_pid == 948 --- 14:25.38 FORK(18217) !ERROR! cannot load my module: RSSFeeds 14:25.38 FORK(18217) fork: took 1s for RSSFeeds. 14:25.38 FORK(18217) --- fork finished for 'RSSFeeds' --- 14:32.45 Chans: (ghostbot) in:#ghostscript 14:39.16 The nook is an android 2.1 platform. 14:39.20 I think we require 2.2 :( 14:40.10 We are all published on google play, btw. 14:41.34 2.2 introduces ScaleGestureDetector 14:41.44 i.e. multitouch. 14:49.19 Chans: (ghostbot) in:#ghostscript 14:49.25 paulgardiner, tor8: The first part of paul's review has "pdf_set_xref_trailer" 14:49.52 I guess we have sets, not gets ? 14:50.18 Robin_Watts: yeah. and pdf_set_xref_trailer should eventually take an explicit pdf_xref 14:50.26 >>> join/#ghostscript mvrhel_laptop (~chatzilla@c-50-149-95-73.hsd1.wa.comcast.net) 14:50.29 we have sets, but not gets, in general 14:50.42 I still think pdf_set_xref_trailer should take on the reference that it is passed. 14:50.59 i.e. ownership of the reference passes in. 14:51.04 henrys: are you here? 14:51.12 It makes both the implementation and the use of the function easier. 14:51.14 Robin_Watts: no. it's irregular. when using ref counting everything HAS to be regular or you'll mess up two years later. 14:51.18 or even two months :) 14:51.29 Robin_Watts: when do you head to Boston? 14:51.35 mvrhel_laptop: yes I thought you were out today? 14:51.36 mvrhel_laptop: Tomorrow morning. 14:51.41 if you create it with a function that has "new" or "load" in the name, you must "drop" it 14:51.44 henrys: getting ready to leave now 14:51.55 tor8: We already have functions that take on ownership. 14:51.56 just wanted to make sure you knew I am going to miss the meetings 14:52.27 Robin_Watts: which ones? I know we added some, but I think we gave them a suffix to indicate said behaviour 14:52.32 We document them as taking ownership. 14:52.54 I am hoping to wrap up the windows viewer this week. just need to add keyboard zooming and save the state when it goes into suspension 14:52.55 We have _drop versions of some 14:53.08 ah, yes. that's the suffix. 14:53.20 so we'd need pdf_set_xref_trailer_and_drop 14:53.21 And they drop even in error cases. 14:53.35 mvrhel_laptop: great good luck at your talk. 14:53.36 fz_new_list_device takes ownership of the list device. 14:53.43 mvrhel_laptop: Yeah, have fun. 14:54.08 Robin_Watts: does not parse 14:54.40 ttyl 14:54.52 thanks 14:54.54 >>> mvrhel_laptop has signed off IRC (Client Quit) [#ghostscript] 14:54.54 tor8: ahem of the list. 14:55.04 The nice thing about the convention of not taking ownership is that you can call functions that either inspect or keep an object without having to work out which it does. 14:55.25 tor8: OK, so using a suffix (_and_drop) would work too. 14:55.41 but my point is it simplifies the calling code. 14:55.41 FORK(10454) --- fork starting for 'RSSFeeds', PID == 10454, bot_pid == 948 --- 14:55.42 FORK(10454) !ERROR! cannot load my module: RSSFeeds 14:55.42 FORK(10454) fork: took 1s for RSSFeeds. 14:55.42 FORK(10454) --- fork finished for 'RSSFeeds' --- 14:55.54 - xref->trailer = pdf_new_dict(ctx, 5); 14:55.56 + obj = pdf_new_dict(ctx, 5); 14:55.56 Process: '+' flag detected; changing reply to public 14:55.58 + pdf_set_xref_trailer(xref, obj); 14:55.58 Process: '+' flag detected; changing reply to public 14:56.00 + pdf_drop_obj(obj); 14:56.00 Process: '+' flag detected; changing reply to public 14:56.02 + obj = NULL; 14:56.02 Process: '+' flag detected; changing reply to public 14:56.13 lessening the number of lines but possibly making it require more thought. 14:56.15 Robin_Watts: or just (_drop) but I think we should be a bit restrictive with that behaviour and reserve it for the instances where there are dozens of calls to the function 14:56.46 pdf_xref_set_trailer_drop(xref, pdf_new_dict(ctx, 5)); 14:56.58 >>> Fandekasp has signed off IRC (Ping timeout: 256 seconds) [#ghostscript] 14:57.30 pdf_array_push_drop and friends are common enough that I felt it was okay to make an exception for it 14:58.39 >>> join/#ghostscript Fandekasp (~Fandekasp@27-32-19-26.static.tpgi.com.au) 14:58.54 to go out on a wild tangent here... since we have a context everywhere, autodrop in the objc style would be possible to implement, and could simplify a lot of reference counting. 14:59.12 tor8: Would it? 14:59.12 Seen: Flushed 7 entries. 14:59.14 I guess having both flavours is never a bad thing. Typically the _drop version has to use exception handling so you can end up with two levels of try catch - but not in this case I think 14:59.28 Robin_Watts: I think I've discussed it before, but concluded that it probably wasn't worth it. 14:59.57 1 minute of the meeting 15:00.11 tor8: wouldn't we need to have markers to say when we enter and leave a function? 15:00.20 Robin_Watts: that one example is contrived, the other instances actually use the new dict a bit before sticking it in the trailer. 15:01.09 Robin_Watts: an autodrop pool would need to have "clear the pool" at safe intervals (like in an event loop) 15:01.19 tor8: sounds filthy. 15:01.24 and that would need nesting scope 15:01.32 did we ever get the third party app list for MuPDF up - chrisl I think took that one? 15:01.37 Robin_Watts: it is. but it takes away 90% of reference counting headaches in ObjC 15:01.45 >>> monxalo has signed off IRC (Quit: Page closed) [#ghostscript] 15:01.48 robin_watts: my thoughts exactly until I programmed under iOS and found that is a very powerful idea 15:02.00 henrys: no, I didn't do it yet - I figured it wasn't required until the next release? 15:02.01 tor8: Until something stops working. 15:02.19 in the Cocoa frameworks you can create and use temporary objc objects willy nilly without a care about reference counting, and the autorelease pools will clean up after you're done 15:03.04 tor8: right, but we can't rely on an event loop happening soon enough. 15:03.07 chrisl:no miles just requested it - didn't say when. I suppose it could wait until then. 15:03.13 --- Saved uptime records. 15:03.20 the main issue it solves is "alloc" returning a new temporary object but you don't want explicit ownership of it (or you're passing it to some other function, which does take ownership), so it goes in the autorelease pool to be released "sometime after the function has returned" 15:03.23 henrys: I'll do it tomorrow - it won't take long 15:03.33 chrisl: okay 15:03.42 robin_watts: That said, I did spend several hours the other day staring at some ObjC wondering why something was never getting freed. :-) 15:03.46 Robin_Watts: so if you're making lots of garbage, you're supposed to make a new pool and stick it around loops that do the work 15:03.52 suppose we start using that on, say, a search operation. 15:04.00 and then we search a 1300 page file. 15:04.10 so in the search case, for each page you'd make and clear the pool 15:04.22 paulgardiner:there is the issue of strong vs weak pointer in ObjC is that the issue? 15:04.30 right, so it still requires work to ensure you clear the pool every now and then. 15:04.50 Chans: (ghostbot) in:#ghostscript 15:04.51 and it bloats every object. 15:04.56 henrys: It could be. Is a weak ref one that doesn't up the count? 15:05.00 Robin_Watts: yes. but it spares you the tedium of passing ownership around everywhere. 15:05.17 paulgardiner: yes 15:05.33 in mupdf we made the "exception" that fz_dict_gets etc don't do "keep" on the returned object and that's worked fine so far 15:05.39 basically it means if nobody else is using this free it I don't care about it. 15:06.19 >>> Fandekasp has signed off IRC (Ping timeout: 276 seconds) [#ghostscript] 15:06.26 tor8: We'd still have to have the ability to be rigorous, so ownership passing would still have to be defined at the API level. 15:06.28 >>> tkamppeter_ materializes into tkamppeter 15:06.37 but it would free people to make slip ups without it mattering so much. 15:06.48 Robin_Watts: the idiom in objc for constructors is to "return [self autorelease];" 15:06.50 henrys: right. It was a CCNode heirarchy in cocos2d. I wondered if the parent pointers were holding on to it, but those are weak refs, so I guess not. 15:06.51 New Ghostscript crasher: http://bugs.ghostscript.com/show_bug.cgi?id=694275 15:07.24 I kinda feel that it's giving people more rope to hang themselves with. 15:07.26 which for pdf_dict_gets would be: return fz_auto_drop(ctx, value, pdf_drop_obj) 15:07.49 because any passing of a reference counted object has to have keep/drop 15:08.09 sorry, make that: return fz_auto_drop(ctx, pdf_keep_obj(value), pdf_drop_obj)) 15:08.27 which is more annoying than what we have now 15:08.28 thanks tkamppeter I'll bring it up at the gs meeting in an hour or so. 15:08.50 paulgardiner:so you are beginning the iOS port? 15:09.34 henrys: he he. No. This was a weekend activity - a game that I'm very very very slowly writing - maybe, possibly. 15:10.42 I guess this is mainly for michael but I think any desktop app should support loading files into an already running process - a bug to that effect was raised against the mupdf x11 viewer this week. Is that going to be a big problem? 15:12.10 henrys: Any *new* app? 15:12.19 henrys: the app is hard wired to do one document 15:12.25 and it's one process per window 15:12.26 paulgardiner:ah so your practicing with iOS so you _can_ port the mupdf android changes to ios 15:12.44 ;-) 15:13.04 henrys: exactly. Tor's comments have made me realise how much fun it must be. 15:14.37 Robin_Watts, tor8: I'm talking about the viewer app michael is working on for windows and tor8 on linux 15:15.20 right. 15:15.41 It depends on what model you take for the app. 15:16.03 Acrobat loads as a 'empty' app into which you can load multiple files. 15:16.16 henrys: none of our apps are multiple document interfaces (you know the windows-within-a-window, or tabs) 15:16.18 (Multiple files, single window, there is a UI term for it that escapes me). 15:16.24 Actually, I am tempted to have a look that iOS port. The main thing that scares me off is not comletely understanding the tricks Tor had to come up with to control motion of the page. The equivalent Android mechanism, although complex, is at least straightforward 15:16.30 MDI = Multiple Document Interface, that's the one, thanks tor. 15:16.46 MDI is a STUPID paradigm. 15:16.47 so it makes no sense to do multiple documents, single process, except for macosx 15:16.52 >>> sojic has signed off IRC (Remote host closed the connection) [#ghostscript] 15:16.56 which is a stupid system to begin with 15:18.12 sorry, let me correct myself. MDI as implemented on windows is a stupid paradigm. 15:18.55 I think if you click on a pdf file folks will expect not to start a new process if one is open on either windows or mac os x - certainly not the latter, windows I'm not positive about. 15:19.22 henrys: Who cares what goes on behind the surface? It's the UI that matters. 15:19.23 I think even evince does this now. 15:19.36 When you open a new browser window on chrome, that starts a new process. 15:19.50 s/browser window/browser tab/ 15:20.06 The question is whether the UI does what you expect. 15:20.23 With Acrobat in windows, if you click another PDF file, you get another window. 15:20.33 Chans: (ghostbot) in:#ghostscript 15:20.43 Who cares whether that's a single process or multiple ones ? 15:20.45 I loathe this new paradigm of apps opening documents replacing the old one I was viewing. stupid crap. 15:21.14 what if you want two open side by side? no can do, sir. now shut up and bow down to almight Jobs. 15:21.15 What the user who opened the bug was wanting was some way to start a new PDF file up and have it replace the old one (same window, same position, etc). 15:21.29 That's *not* what most people want. 15:21.38 and would be a huge UI fail. 15:21.44 tor8: you use open -n for a new process. 15:22.22 >>> join/#ghostscript marcosw_ (~marcosw@c-67-164-54-215.hsd1.ca.comcast.net) 15:22.23 Might it be added as a configurable option? 15:22.31 henrys: the new lion (or mountain lion) preview has some stupid default that replaces whatever pdf you were viewing with the now one you opened. took me ages to find the setting to turn that shit off. 15:23.02 tor8: windows photo and fax viewer used to do the same. drove me mad. 15:23.16 but they fixed that for windows 7. 15:23.45 Doesn't the app just have to announce itself as a consumer of certain file types and then react to a certain windows message? 15:24.47 paulgardiner: You're thinking of RISC OS :) 15:25.11 okay I'll let that request rest until the next battle uhum meeting. 15:25.18 Actually, I may be. I knew I'd had to handle something like that before. 15:25.39 having an option is probably not a bad idea, but it should not be default behaviour. 15:25.45 I'm still not sure what we decided about openssl. 15:25.45 FORK(15339) --- fork starting for 'RSSFeeds', PID == 15339, bot_pid == 948 --- 15:25.47 FORK(15339) !ERROR! cannot load my module: RSSFeeds 15:25.47 FORK(15339) fork: took 2s for RSSFeeds. 15:25.47 FORK(15339) --- fork finished for 'RSSFeeds' --- 15:25.59 me neither. 15:26.15 that was next in my notes - signatures 15:26.29 on tor/openssl is one way to build it using configure && make if openssl is present in thirdparty 15:26.47 but I want to polish that some more to deal with system installed and complete absence as well 15:27.04 and figure out a story for win32 15:27.16 Still not got my signature checking code commited, or added to android. Parked it until we decide on openssl 15:27.41 paulgardiner: is libcrypto available on android? 15:28.27 I don't think so. Google shows lots of discussion about building it 15:28.38 We could use the same mechanism as for v8 15:28.57 Distribute our own prebuilt libs that is. 15:29.06 rats. because their build system uses perl scripts so I bet it's a bitch to cross compile. 15:29.32 robin_watts: last week you said something about building it fore andrpod - or am I misremembering 15:29.37 I have another way to build it using our existing make rules, but that might miss some crucial #define or other that the configure sets up 15:30.16 paulgardiner: I've never touched openssl. 15:30.38 oh okay. Not sure where I picked that up from 15:31.38 wow I'd think there would be something native on android. 15:32.37 paulgardiner: I liked the android class documentation - nice. 15:35.22 Robin_Watts: good luck at AnDev - we'll try to be available for you SMS if you need to. 15:35.52 Chans: (ghostbot) in:#ghostscript 15:35.57 henrys: Thanks. 15:36.09 I'll be on irc, I imagine. 15:36.09 henrys: oh good. Can probably add more detail for some of the classes, but I thought I'd wait to see what parts people ask about 15:36.42 anything else for the meeting - sounds like openssl is still a problem. 15:36.44 ? 15:37.28 pulling out parts of a crypto library is like a major sin in the security world up there with rolling your own. 15:37.45 tor8: the openssl build using perl should be fine if we are going for the same approach as v8 15:38.38 I'd somehow gotten the idea that someone else was looking at building openssl for Android. Sounds like I should maybe have a go. 15:39.19 android has a customised version of bouncy castle in it. 15:39.34 Is that java though? 15:39.47 >>> join/#ghostscript ray_laptop (~chatzilla@rrcs-64-183-45-163.west.biz.rr.com) 15:39.53 yes. 15:40.13 so it'd require some cunning callbacks from jni -> java to be usable I imagine. 15:40.40 Yes. Sounds hellish 15:40.42 ick. 15:42.09 OK, I can get mupdf installed on the nook, by knocking out all the ScaleGestureDetector stuff. 15:42.22 and building for armeabi. 15:43.28 http://stackoverflow.com/questions/9697825/how-to-digitally-sign-a-pdf-in-android-device 15:44.11 iText is java isn't it ? 15:44.15 of course itext is java 15:44.50 hence it can be using bouncycastle. 15:45.18 and indeed, it does use that (so Mr Google says) 15:45.50 huh there is this pdfblackbox 15:47.01 I'm going to prepare for the next meeting. 15:47.36 "PDFBlackbox includes own PDF processor and does not use third-party libraries for cryptography operations or for loading or saving PDF documents." 15:50.35 !WARN! PERL: readdir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 862. 15:50.35 !WARN! PERL: closedir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 869. 15:51.47 Chans: (ghostbot) in:#ghostscript 15:51.53 So openssl. I'm still uncertain who's doing what. 15:53.35 tor8: I have win32 versions of the libs here. Was it linux versions you build? 15:53.46 Have we dismissed bouncy castle? 15:54.24 paulgardiner: yeah, I have the Makethird build unix versions 15:54.37 I can also have it pick up system version from pkg-config 15:54.42 ray_laptop: do you have time to look at the Parrots.zip file that came in on Sunday to see why the transfer curve isn't being applied? 15:54.44 and macosx has it already pre-installed 15:54.45 henrys: would be very awkward to use via a java api 15:55.07 paulgardiner, tor8: I think we should proceed with openssl under the same terms as v8. 15:55.18 We only ever need to successfully compile it once per platform :) 15:55.23 Robin_Watts: use if it's there, else ignore completely? 15:55.29 tor8: right. 15:55.39 we could try to use the system versions (which would work fine on unixes) 15:55.50 BUT... we should design the API so that there is a veneer layer. 15:55.59 akin to the pdf_js stuff. 15:56.00 FORK(18745) --- fork starting for 'RSSFeeds', PID == 18745, bot_pid == 948 --- 15:56.01 FORK(18745) !ERROR! cannot load my module: RSSFeeds 15:56.01 FORK(18745) fork: took 2s for RSSFeeds. 15:56.01 FORK(18745) --- fork finished for 'RSSFeeds' --- 15:56.16 so that anyone can reimplement the veneer to hook us up to a different openssl lib. 15:56.18 I would wrap the signature checking stuff into a veneer layer with both a null and an openssl based implementation 15:56.27 tor8: right. 15:56.28 which is predicated on HAVE_OPENSSL 15:56.47 then the source is independent of makefile hackery to link in the openssl 15:57.07 marcosw: sorry, I was reading the logs. I'll have a look at Parrots 15:57.13 on windows, I'm happy to go the v8 route and provide an openssl libcrypto.a download 15:57.16 exactly like pdf_js_{v8,none}.c, right? 15:57.21 Robin_Watts: yeah. 15:57.58 paulgardiner: The first of your API reviews looks fine to me. 15:57.58 Robin_Watts: my worry on windows is it'll lead to an explosion of targets. with/without both v8 and openssl makes 4 possible combinations 15:58.06 tor8: I think last week you suggested I move my crypto routines to fz_crypto.c 15:58.31 crypto_pkcs7_(openssl|null).c would be my suggestion 15:58.32 I guess it could be that that has a nulled version 15:58.34 tor8: We can insist on the lib on windows, probably. 15:58.47 or have different configs in the solution. 15:58.48 or just crypto_pkcs7.c for now with a #ifdef HAVE_OPENSSL 15:59.02 Robin_Watts: it would be good to be able to check it out and just build 15:59.15 on unix, it's fine because we can skip the openssl library if it isn't there via the makefiles 15:59.25 Seen: Flushed 8 entries. 15:59.26 tor8: Right, so we have release-ssl and release configs. 15:59.50 we choose not to use configs for v8 15:59.58 Can't remember why now 16:00.13 Robin_Watts: configs could work for ssl, especially if we go the one file with big ifdef route 16:00.36 configs can also select between files 16:01.12 okay the gs meeitng 16:01.34 alexcher:did you see tkamppeter's new bug? 16:02.01 henrys: yes, I did. 16:02.23 FWIW, I can reproduce the problem here 16:02.30 marcosw, marcosw_: do you need help dispatching your bizillion bugs, it looks like a very large number of problems to sort through. 16:02.37 ? 16:03.04 chrisl:is it just pdfwrite? 16:03.24 chrisl can you tell me what goes wrong / A back trace ? I cannot reproduce it 16:03.38 henrys: I don't know yet - I *literally* just saw it crash as your question came up 16:03.40 henrys: yes, i was going to ask people to grab bugs that were in their area of responsibility, but if you have time to help assign that would be great. 16:04.01 Given that its in sprintf I would guess its writing the link annotation 16:04.01 --- Saved uptime records. 16:04.15 marcosw_:I'll start from the largest bug id and go backwards. 16:04.50 kens: looks like it's happening in write_xref_section() 16:05.03 Oh, tha'ts 'unexpected' 16:05.17 Ah, but I did fix something there I think 16:05.42 Its because we reserve an entry for an item (the N'th page) but don;t ever write that page,so the xref has a hole in it 16:05.56 ray_laptop:do you need more help with stuff from the new customer? alexcher and chrisl could jump in. 16:06.04 If you look at Till's pdfmark it has a Link annotation with a Dest of Page 3, but the fikle only has 1 page 16:06.38 ray_laptop:getting them up and going I think is the high priority thing right now. 16:07.21 Chans: (ghostbot) in:#ghostscript 16:07.30 marcosw_ and all - all jpeg2000 and jbig2 stuff go to alexcher 16:07.37 OK 16:07.48 henrys: are you talking about cust. 801 ? 16:08.13 ray_laptop: yea 16:08.15 if so, their requests are a bit strange. 16:08.59 henrys: does that include the mudpf issues (or have they been fixed? Robin_Watts suggested that in a recent email)? 16:09.02 for instance, they asked to speed up the first job, but they've coded up a server mode, so why do they care about the first job? 16:09.48 kens: it reads a value for "pos" of 571230650368 from the temp file, and that overflows the 21 bytes in "str" 16:09.59 chrisl that owuld do it :-) 16:10.00 henrys: I'll check, but I think there is a request pending from cust 801 regarding auto color mode that mvrhel didn't respond to (I thought he was) 16:10.13 chrisl sounds like it is the 64-bit file stufcf, as I suspected 16:10.22 Is it crashing woth the current code ? 16:10.34 don't know, let me check 16:11.09 marcosw_:I'd like to just assign them alex - hopefully any problem in mupdf is reproducible in gs. 16:12.15 marcosw_:if not alexcher will sort it and reassign. 16:12.30 henrys: so, if someone wants to take a look at the one titled "#15 : Auto color mode" that would be fine. I am trying to resolve their BGPrint mode issue 16:12.41 henrys: alexcher doesn't like to give up his bugs :-) 16:13.17 marcosw_:maybe this will give him practice. 16:13.53 ray_laptop:I do think michael has to deal with that one. I thought there were more. 16:14.13 marcosw_: I believe I have fixed all the mupdf problems except 1. 16:14.14 marcosw_: we already have an open bug about long paths on the command line 16:14.27 (the SEGVs, not the valgrind issues) 16:14.45 I will try and close the bugs asap, but it might not happen before I fly. 16:14.48 chrisl: i thought we did, but couldn't find it immediately. 16:15.04 marcosw_: give me a sec 16:15.33 http://bugs.ghostscript.com/show_bug.cgi?id=693380 16:15.34 I found one for SCO builds, but I figured that was a different prolbem 16:15.42 marcosw_:where is the code that created these mutated pdf files? 16:16.06 does google have a home for it? 16:16.18 kens: I can't reproduce the crash on current master 16:16.24 paulgardiner, tor8: get vs lookup.... my memory was that get would get you a reference, and lookup would not ? 16:16.41 chrisl that's probably good news I think. I did do some fixes in that area 16:17.27 Hopefully either Till or the original poster can try tghe latest code. 16:17.32 I don't know where the code to mutate the pdf files is. I can ask for it. Why do you want it? Don't we have enough bugs :-( 16:18.10 kens: it does seem to produce a broken PDF though 16:18.44 chrisl if you or Till wants to repor that (and I can reproduce it....) I'll have a go at it. The minimal file Till attached works OK for me on WIndows 16:19.25 Robin_Watts: find vs lookup 16:20.02 ray_laptop:actually if you haven't gotten to 694059 694060 it would be good to get either of those to alexcher or chrisl for preliminary analysis. 16:20.48 >>> tkamppeter has signed off IRC (Remote host closed the connection) [#ghostscript] 16:20.52 marcosw_:I was hoping for a README that explained the methodology 16:21.28 henrys: 694059 doesn't need much analysis - the code specifically disallows certain compression scheme/bit depth combinations. It doesn't say *why* though 16:22.34 henrys, ray_laptop: I'll take 694059 694060, since the tiff devices are not unknown to me 16:23.12 chrisl:okay well this is a top ten p1 thing but it has one comment dated 5/9 so I thought somebody ought to do something. 16:23.32 Chans: (ghostbot) in:#ghostscript 16:24.01 >>> join/#ghostscript monxalo (5d6c7e68@gateway/web/freenode/ip.93.108.126.104) 16:24.12 henrys: I suspect the compression one is because it doesn't make sense to apply byte-wise compression to 1 bit image data 16:25.20 and 060 is just a documentation issue? 16:25.45 maybe marcosw_ has already followed up on these - I didn't check emails. 16:26.15 No, I think there's probably an issue - we shouldn't be producing a composite file for 1 bpp output. But it's probably fairly trivial to fix 16:26.28 marcosw: those Parrots files are strange. They seem to use binary object encoding (just a few places) and they use the Adobe ProcSet. I can't easily find where they do settransfer or setcolortransfer, so I'm adding debug 16:26.49 FORK(21226) --- fork starting for 'RSSFeeds', PID == 21226, bot_pid == 948 --- 16:26.50 FORK(21226) !ERROR! cannot load my module: RSSFeeds 16:26.50 FORK(21226) fork: took 2s for RSSFeeds. 16:26.50 FORK(21226) --- fork finished for 'RSSFeeds' --- 16:27.26 chrisl: I wondered about 'pack' with 1 bpp. It will give you a little compression for large runs of white or black, and that's about it 16:28.04 usually that customer is pretty noisy I'm surprised we got away with letting those sit so long. 16:28.05 chrisl: I assumed that it is because it is easier to unpack than G4 (they may have SSE or H/W for it) 16:28.33 ray_laptop: exactly, pretty daft. But I'm aware of any technical reason for it. I just need to double check that libtiff is okay with it 16:28.48 I'm NOT aware.... 16:29.25 okay 30 minutes - done! 16:29.38 ray_laptop: okay, don't spend too much effort. It's not our problem if the customer is generating bad PostScript (as I said in my email, Photoshop and Acrobat don't perform expected transfer function either). 16:31.31 marcosw_:I wonder if the bug aging list should come out more frequently if there is a top ten customer in it. We shouldn't have let these two slip. 16:31.32 >>> marcosw_ has signed off IRC (Quit: marcosw_) [#ghostscript] 16:31.47 >>> join/#ghostscript tkamppeter (~till@p5DDB918E.dip0.t-ipconnect.de) 16:32.09 I have RedMon working on 64-bit Windows. What else is needed for the port monitor project? 16:32.58 alexcher:you were writing a port monitor that would be our code - not Russells 16:33.40 kens: Using the full file from 694275 I get a valid PDF, and no crash with current master. So I think it's all good. 16:33.57 maybe were is a bad tense to use - "you are" would seem more appropriate. 16:33.58 chrisl, that's something of a relief, will you put something in the buig thread ? 16:34.11 kens: just about to, yes. 16:34.19 chrisl thanks :-) 16:36.10 henrys: Fine, it is mostly a DDK sample anyway. What other functionality is needed. 16:37.31 marcosw: I set a breakpoint in the C code in BOTH zsettransfer and zsetcolortransfer and the only 'hit' was during our initialization of the default transfer function. 16:38.19 I think that is all that is on your desk - the other pieces are sprint and xps improvement and we'll bundle it all together so we have a complete printing solution for windows like gsprint - did you have other ideas about the project? 16:38.43 s/sprint/our own gsprint/ 16:39.33 Chans: (ghostbot) in:#ghostscript 16:39.49 alexcher ^^^ 16:40.06 OK 16:41.28 alexcher:you should check each jbig2 and jpeg2000 problem in both ghostscript and mupdf, Shelly I think can work on both but I think Simon is mupdf only. 16:42.05 >>> monxalo has signed off IRC (Ping timeout: 250 seconds) [#ghostscript] 16:42.12 Yes 16:42.24 marcosw: If I use the Install procedure to change the default graphics state transfer function, it is effective for either file. For example, to make it lighter: 16:42.26 gs ... -c "<< /Install { { .4 exp } settransfer } >> setpagedevice" -f Parrots.ps 16:42.31 alexcher:I assume you saw their email to Robin_Watts and support you can follow up with that note and dispatch them how you see fit. 16:42.50 marcosw: can you take it from here ? 16:43.05 henrys: yes, I did. 16:44.27 ray_laptop:I think marcosw fell off. 16:45.39 henrys: OK. I'll just reply to them. 16:45.52 paulgardiner: Second API review; same comments as originally, but I don't see anything hugely offensive in it. 16:48.18 What were the comments again? You mentioned the placed where there were three function calls check len; resize; get entry; but I've dealt with that. 16:48.47 for's with function calls. 16:49.01 read len into a variable, and then use that. 16:49.38 Ah yes. Call in the test. 16:49.51 OK I'm going to call it a night, bye all 16:49.53 I could change that 16:50.22 chrisl:I'm going to assign the free type fuzzing issues to you without commenting in each that it is a problem in the free type code. 16:50.32 >>> kens has signed off IRC (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) [#ghostscript] 16:50.45 henrys: I assumed marcosw would do that, anyway 16:50.47 tor8: what was it that you wanted to check with robin about pdf_xref_obj? 16:51.53 which reminds me I did hear from URW - resounding "no" to the buyout and they are going to fix the widths for a fee. 16:52.29 they consider the GPL fonts unsupported 16:52.43 chrisl ^^^ 16:52.48 Hmm, oh well..... 16:53.16 henrys: I could have fixed them myself, but I doubt they'd take patches 16:53.57 Robin_Watts: does mupdf write jpegs? 16:54.06 chrisl: Not currently, why? 16:54.20 chrisl: best to keep things in their handwriting 16:54.39 Robin_Watts: I'm just starting on thirdparty list 16:55.29 I think there are many more jpeg2000 problems than previously identified - Robin_Watts 16:55.40 chrisl: ah, right. 16:55.55 henrys: Not from the mupdf fuzzing files? 16:55.55 Chans: (ghostbot) in:#ghostscript 16:56.18 oh right no, ghostscript 16:56.41 right. The mupdf ones have all been fixed. 16:57.00 marcosw:for the logs we probably should fuzz luratech as well. 16:57.00 FORK(8836) --- fork starting for 'RSSFeeds', PID == 8836, bot_pid == 948 --- 16:57.01 FORK(8836) !ERROR! cannot load my module: RSSFeeds 16:57.01 FORK(8836) fork: took 1s for RSSFeeds. 16:57.01 FORK(8836) --- fork finished for 'RSSFeeds' --- 16:57.17 marcosw:the luratech build that is. 16:59.27 Seen: Flushed 9 entries. 17:00.12 henrys: did we also fuzz the UFST build, or do we need to do that as well ? 17:00.44 henrys: those two are our 'customer only' libraries that GPL users never see 17:00.44 ray_laptop: OMFG!! *PLEASE* don't go there! 17:00.53 ray_laptop:good point we probably should. chrisl is getting the bulk of the fuzzing action already. 17:01.01 sorry, chrisl 17:01.10 at least of the problem I'm assigning now. 17:01.22 I won't be fixing any fuzzing problems in UFST 17:01.27 I guess I will wear my kevlar to the next meeting 17:01.56 and not turn my back on chrisl ;-) 17:02.16 I should fix some of the default assignments for component owners in bugzilla while I'm doing this. 17:02.41 henrys: you could take ownership of UFST -- I doubt that chrisl would mind ;-) 17:02.56 ray_laptop: like I say, I'm refusing point-blank to work on fuzzing problems in UFST. I'd consider forwarding them to Monotype, though 17:03.06 that would dull my pointy hair 17:03.43 henrys: we wouldn't want that. You're already dull enough ;-) 17:03.57 paulgardiner: Could not find method android.view.MotionEvent.getActionMasked, referenced from method com.artifex.mupdfdemo.MuPDFReaderView.onTouchEvent 17:04.23 --- Saved uptime records. 17:04.33 if our meeting is over, I've got to take my car in. Anything else for me right away ? 17:04.46 nope we're done 17:05.16 henrys: (marcosw for the logs). Reply sent to cust 801 about the settransfer (and cc the usual population) 17:05.41 ray_laptop:great. If marcosw pops back I'll point him to this stuff. 17:05.56 bbiaw 17:06.29 henrys: I'm a bit surprised there are issues coming up in Freetype, given the way we parse the font into a gs_font and then rebuild it to pass into freetype 17:08.08 robin_watts: looks like you can replace that with getAction() & ACTION_MASK 17:09.03 chrisl: thanks for taking the tiffsep bugs. 17:11.27 event.getAction() & event.ACTION_MASK... compiled... 17:11.57 ray_laptop: no problem - they don't look very onerous 17:12.07 Chans: (ghostbot) in:#ghostscript 17:13.41 >>> ray_laptop has signed off IRC (Ping timeout: 248 seconds) [#ghostscript] 17:15.53 I've been changing the component from "fuzzing" to the actual component. Hope that is okay - fuzzing is not really a component - maybe that should be stated elsewhere. 17:21.46 >>> chrisl materializes into chrisl_away 17:27.33 FORK(8183) --- fork starting for 'RSSFeeds', PID == 8183, bot_pid == 948 --- 17:27.34 FORK(8183) !ERROR! cannot load my module: RSSFeeds 17:27.34 FORK(8183) fork: took 1s for RSSFeeds. 17:27.34 FORK(8183) --- fork finished for 'RSSFeeds' --- 17:28.03 Chans: (ghostbot) in:#ghostscript 17:28.54 I have mupdf running on the nook. 17:29.02 No multi-touch it seems, so I can't zoom. 17:29.22 >>> join/#ghostscript marcosw_ (~marcosw@eduroam-228-16.ucsc.edu) 17:29.24 and I had to disable the setImageFilter calls on the buttons. 17:29.36 but we can at least see mupdf running on an e-ink device. 17:30.27 >>> SpNg has signed off IRC (Quit: SpNg) [#ghostscript] 17:31.00 henrys: replying to your comment regarding the bug aging list, I think an alternative is to have bugzilla send out reminders. I'll check it's that's an option. 17:31.37 marcosw_:thanks ray_laptop had some stuff for you also (in the logs) 17:32.09 Robin_Watts: I didn't even know the nook was android. 17:32.34 henrys: It is. I bought one (30 quid!), and rooted it 17:32.42 and installed the amazon kindle app :) 17:32.48 wasn't MS going to buy it at one point? 17:33.04 That was a very recent rumour. It might still be happening. 17:33.06 Robin_Watts: oh cool. 17:36.25 henrys: found the irc messages for me in the archive. 17:36.44 marcosw_:okay 17:38.35 marcosw_:I wonder why you can't change the component on multiple bugs - that would sure make this go faster. 17:41.02 henrys: particularly odd since they have a pull down for Component. Preusmably a bug in bugzilla. 17:41.31 is this for the fuzzing issues? I haven't been changing the component when I reassign them. 17:42.21 marcosw_:yeah I said something about that in the logs - but I don't care if you want to leave it. 17:44.09 Chans: (ghostbot) in:#ghostscript 17:47.33 marcosw_:I did a handful of them I'll come back later and do some more. 17:57.41 FORK(1850) --- fork starting for 'RSSFeeds', PID == 1850, bot_pid == 948 --- 17:57.42 FORK(1850) !ERROR! cannot load my module: RSSFeeds 17:57.42 FORK(1850) fork: took 1s for RSSFeeds. 17:57.42 FORK(1850) --- fork finished for 'RSSFeeds' --- 17:59.53 Seen: Flushed 6 entries. 18:00.13 Chans: (ghostbot) in:#ghostscript 18:04.47 --- Saved uptime records. 18:11.05 >>> join/#ghostscript monxalo (~monxalo@238.24.37.188.rev.vodafone.pt) 18:12.29 Robin_Watts: whether it's necessary and why not use pdf_load_object instead 18:12.53 tor8? 18:13.17 right. sorry. 18:15.28 I've got to run. Parents here. 18:15.35 It looks like there might be some overlap, yes. 18:15.47 alright. ttytm. have fun! 18:16.47 Chans: (ghostbot) in:#ghostscript 18:18.58 >>> monxalo has signed off IRC (Remote host closed the connection) [#ghostscript] 18:22.17 >>> paulgardiner has signed off IRC (Read error: Connection reset by peer) [#ghostscript] 18:27.59 FORK(22194) --- fork starting for 'RSSFeeds', PID == 22194, bot_pid == 948 --- 18:28.00 FORK(22194) !ERROR! cannot load my module: RSSFeeds 18:28.00 FORK(22194) fork: took 1s for RSSFeeds. 18:28.00 FORK(22194) --- fork finished for 'RSSFeeds' --- 18:33.03 Chans: (ghostbot) in:#ghostscript 18:40.11 >>> join/#ghostscript ray_laptop (~chatzilla@cpe-76-171-54-81.socal.res.rr.com) 18:48.47 Chans: (ghostbot) in:#ghostscript 18:58.05 FORK(22298) --- fork starting for 'RSSFeeds', PID == 22298, bot_pid == 948 --- 18:58.06 FORK(22298) !ERROR! cannot load my module: RSSFeeds 18:58.06 FORK(22298) fork: took 1s for RSSFeeds. 18:58.06 FORK(22298) --- fork finished for 'RSSFeeds' --- 19:00.27 Seen: Flushed 2 entries. 19:04.31 Chans: (ghostbot) in:#ghostscript 19:04.51 --- Saved uptime records. 19:09.21 >>> ray_laptop has signed off IRC (Ping timeout: 248 seconds) [#ghostscript] 19:18.54 >>> join/#ghostscript malc__ (~malc@188.123.241.147) 19:20.34 Chans: (ghostbot) in:#ghostscript 19:20.34 ircCheck: possible lost in space; checking.Tue May 28 19:20:34 2013 19:20.34 >ghostbot< TEST 19:20.34 IRCTEST: Yes, we're alive. 19:27.52 >>> marcosw_ has signed off IRC (Quit: marcosw_) [#ghostscript] 19:28.12 FORK(15796) --- fork starting for 'RSSFeeds', PID == 15796, bot_pid == 948 --- 19:28.13 FORK(15796) !ERROR! cannot load my module: RSSFeeds 19:28.13 FORK(15796) fork: took 1s for RSSFeeds. 19:28.13 FORK(15796) --- fork finished for 'RSSFeeds' --- 19:29.02 >>> join/#ghostscript marcosw_ (~marcosw@eduroam-228-16.ucsc.edu) 19:35.59 Chans: (ghostbot) in:#ghostscript 19:50.53 !WARN! PERL: readdir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 862. 19:50.53 !WARN! PERL: closedir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 869. 19:52.55 Chans: (ghostbot) in:#ghostscript 19:57.44 >>> malc__ has signed off IRC (Quit: leaving) [#ghostscript] 19:58.21 FORK(9670) --- fork starting for 'RSSFeeds', PID == 9670, bot_pid == 948 --- 19:58.22 FORK(9670) !ERROR! cannot load my module: RSSFeeds 19:58.22 FORK(9670) fork: took 1s for RSSFeeds. 19:58.22 FORK(9670) --- fork finished for 'RSSFeeds' --- 20:05.27 --- Saved uptime records. 20:08.49 Chans: (ghostbot) in:#ghostscript 20:18.05 >>> marcosw_ has signed off IRC (Quit: marcosw_) [#ghostscript] 20:24.35 Chans: (ghostbot) in:#ghostscript 20:24.35 ircCheck: possible lost in space; checking.Tue May 28 20:24:35 2013 20:24.35 >ghostbot< TEST 20:24.35 IRCTEST: Yes, we're alive. 20:28.27 FORK(31418) --- fork starting for 'RSSFeeds', PID == 31418, bot_pid == 948 --- 20:28.28 FORK(31418) !ERROR! cannot load my module: RSSFeeds 20:28.28 FORK(31418) fork: took 1s for RSSFeeds. 20:28.28 FORK(31418) --- fork finished for 'RSSFeeds' --- 20:29.34 >>> join/#ghostscript SpNg (~ARolek@wsip-70-167-118-33.sd.sd.cox.net) 20:29.45 >>> robin_watts_mac has signed off IRC (Remote host closed the connection) [#ghostscript] 20:29.50 is there an easy way to extract what color space is being used in an EPS file? 20:40.59 Chans: (ghostbot) in:#ghostscript 20:58.45 FORK(25245) --- fork starting for 'RSSFeeds', PID == 25245, bot_pid == 948 --- 20:58.46 FORK(25245) !ERROR! cannot load my module: RSSFeeds 20:58.46 FORK(25245) fork: took 1s for RSSFeeds. 20:58.46 FORK(25245) --- fork finished for 'RSSFeeds' --- 21:00.37 Seen: Flushed 1 entries. 21:05.41 --- Saved uptime records. 21:13.09 Chans: (ghostbot) in:#ghostscript 21:17.09 >>> join/#ghostscript marcosw_ (~marcosw@c-67-164-54-215.hsd1.ca.comcast.net) 21:28.33 Chans: (ghostbot) in:#ghostscript 21:28.53 FORK(19879) --- fork starting for 'RSSFeeds', PID == 19879, bot_pid == 948 --- 21:28.54 FORK(19879) !ERROR! cannot load my module: RSSFeeds 21:28.54 FORK(19879) fork: took 1s for RSSFeeds. 21:28.54 FORK(19879) --- fork finished for 'RSSFeeds' --- 21:29.56 >>> mrdocs has signed off IRC (Quit: Konversation terminated!) [#ghostscript] 21:33.47 ircCheck: possible lost in space; checking.Tue May 28 21:33:47 2013 21:33.47 >ghostbot< TEST 21:33.47 IRCTEST: Yes, we're alive. 21:43.17 >>> part/#ghostscript gandaro (~gandaro@wikipedia/Gorlingor) 21:44.07 Chans: (ghostbot) in:#ghostscript 21:45.41 >>> join/#ghostscript sojic (~sojic@92.55.124.137) 21:59.05 FORK(15003) --- fork starting for 'RSSFeeds', PID == 15003, bot_pid == 948 --- 21:59.06 FORK(15003) !ERROR! cannot load my module: RSSFeeds 21:59.06 FORK(15003) fork: took 1s for RSSFeeds. 21:59.06 FORK(15003) --- fork finished for 'RSSFeeds' --- 22:00.17 Chans: (ghostbot) in:#ghostscript 22:06.01 --- Saved uptime records. 22:16.31 Chans: (ghostbot) in:#ghostscript 22:26.26 >>> tor8 has signed off IRC (Quit: tor8) [#ghostscript] 22:29.23 FORK(16456) --- fork starting for 'RSSFeeds', PID == 16456, bot_pid == 948 --- 22:29.24 FORK(16456) !ERROR! cannot load my module: RSSFeeds 22:29.24 FORK(16456) fork: took 1s for RSSFeeds. 22:29.24 FORK(16456) --- fork finished for 'RSSFeeds' --- 22:32.15 Chans: (ghostbot) in:#ghostscript 22:35.52 >>> marcosw_ has signed off IRC (Quit: marcosw_) [#ghostscript] 22:37.22 ircCheck: possible lost in space; checking.Tue May 28 22:37:22 2013 22:37.22 >ghostbot< TEST 22:37.22 IRCTEST: Yes, we're alive. 22:40.57 >>> setmeaway has signed off IRC (Ping timeout: 252 seconds) [#ghostscript] 22:47.39 Chans: (ghostbot) in:#ghostscript 22:53.35 >>> join/#ghostscript Fandekasp (~Fandekasp@27-32-19-26.static.tpgi.com.au) 22:59.29 FORK(20799) --- fork starting for 'RSSFeeds', PID == 20799, bot_pid == 948 --- 22:59.30 FORK(20799) !ERROR! cannot load my module: RSSFeeds 22:59.30 FORK(20799) fork: took 1s for RSSFeeds. 22:59.30 FORK(20799) --- fork finished for 'RSSFeeds' --- 23:03.33 Chans: (ghostbot) in:#ghostscript 23:06.37 --- Saved uptime records. 23:14.08 >>> JakeSays has signed off IRC (Read error: Connection reset by peer) [#ghostscript] 23:14.19 >>> jghali has signed off IRC (Read error: Connection reset by peer) [#ghostscript] 23:14.36 >>> join/#ghostscript jghali (~jghali@ADijon-157-1-7-3.w90-56.abo.wanadoo.fr) 23:15.24 >>> join/#ghostscript JakeSays (~quassel@63.226.106.92) 23:16.22 >>> sojic has signed off IRC (Remote host closed the connection) [#ghostscript] 23:19.39 Chans: (ghostbot) in:#ghostscript 23:29.37 FORK(8789) --- fork starting for 'RSSFeeds', PID == 8789, bot_pid == 948 --- 23:29.38 FORK(8789) !ERROR! cannot load my module: RSSFeeds 23:29.38 FORK(8789) fork: took 1s for RSSFeeds. 23:29.38 FORK(8789) --- fork finished for 'RSSFeeds' --- 23:41.07 LOG: last message repeated 3 times 23:41.07 ircCheck: possible lost in space; checking.Tue May 28 23:41:07 2013 23:41.07 >ghostbot< TEST 23:41.07 IRCTEST: Yes, we're alive. 23:50.57 !WARN! PERL: readdir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 862. 23:50.57 !WARN! PERL: closedir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 869. 23:51.27 leak: 1 nuh{} items deleted; now have 24 23:52.07 Chans: (ghostbot) in:#ghostscript 23:59.55 FORK(30728) --- fork starting for 'RSSFeeds', PID == 30728, bot_pid == 948 --- 23:59.56 FORK(30728) !ERROR! cannot load my module: RSSFeeds 23:59.56 FORK(30728) fork: took 1s for RSSFeeds. 23:59.56 FORK(30728) --- fork finished for 'RSSFeeds' ---