00:14.42 Opened logfile log/20131105. 00:14.42 >>> join/#ghostscript plinnell (~mrdocs@14.sub-70-197-5.myvzw.com) 00:14.42 >>> plinnell has signed off IRC (Changing host) [#ghostscript] 00:14.42 >>> join/#ghostscript plinnell (~mrdocs@opensuse/member/mrdocs) 00:17.28 >>> join/#ghostscript suleymancelik (~suleymanc@178.233.168.111) 00:19.28 >>> join/#ghostscript Micha` (~user@AMontpellier-654-1-98-87.w90-0.abo.wanadoo.fr) 00:27.42 Chans: (ghostbot) in:#ghostscript 00:27.52 --- Saved uptime records. 00:28.42 Seen: Flushed 1 entries. 00:29.44 FORK(24592) --- fork starting for 'RSSFeeds', PID == 24592, bot_pid == 5299 --- 00:29.45 FORK(24592) !ERROR! cannot load my module: RSSFeeds 00:29.45 FORK(24592) fork: took 1s for RSSFeeds. 00:29.45 FORK(24592) --- fork finished for 'RSSFeeds' --- 00:38.32 ircCheck: possible lost in space; checking.Tue Nov 5 00:38:32 2013 00:38.32 >ghostbot< TEST 00:38.32 IRCTEST: Yes, we're alive. 00:43.52 Chans: (ghostbot) in:#ghostscript 00:50.27 oh, jeez. I should really learn to read clusterpush results :( 00:51.03 So just 1 worrying result showing up in the test. Let me try running it in high res... 00:52.58 >>> plinnell has signed off IRC (Ping timeout: 240 seconds) [#ghostscript] 01:00.06 FORK(29660) --- fork starting for 'RSSFeeds', PID == 29660, bot_pid == 5299 --- 01:00.07 FORK(29660) !ERROR! cannot load my module: RSSFeeds 01:00.07 FORK(29660) fork: took 1s for RSSFeeds. 01:00.07 FORK(29660) --- fork finished for 'RSSFeeds' --- 01:00.26 Chans: (ghostbot) in:#ghostscript 01:28.52 --- Saved uptime records. 01:28.52 Seen: Flushed 1 entries. 01:31.04 FORK(6832) --- fork starting for 'RSSFeeds', PID == 6832, bot_pid == 5299 --- 01:31.05 FORK(6832) !ERROR! cannot load my module: RSSFeeds 01:31.05 FORK(6832) fork: took 1s for RSSFeeds. 01:31.05 FORK(6832) --- fork finished for 'RSSFeeds' --- 01:31.56 Chans: (ghostbot) in:#ghostscript 01:52.34 LOG: last message repeated 3 times 01:52.34 ircCheck: possible lost in space; checking.Tue Nov 5 01:52:34 2013 01:52.34 >ghostbot< TEST 01:52.34 IRCTEST: Yes, we're alive. 02:01.06 FORK(10308) --- fork starting for 'RSSFeeds', PID == 10308, bot_pid == 5299 --- 02:01.07 FORK(10308) !ERROR! cannot load my module: RSSFeeds 02:01.07 FORK(10308) fork: took 1s for RSSFeeds. 02:01.07 FORK(10308) --- fork finished for 'RSSFeeds' --- 02:03.40 Chans: (ghostbot) in:#ghostscript 02:29.02 --- Saved uptime records. 02:32.04 FORK(24059) --- fork starting for 'RSSFeeds', PID == 24059, bot_pid == 5299 --- 02:32.05 FORK(24059) !ERROR! cannot load my module: RSSFeeds 02:32.05 FORK(24059) fork: took 1s for RSSFeeds. 02:32.05 FORK(24059) --- fork finished for 'RSSFeeds' --- 02:36.08 Chans: (ghostbot) in:#ghostscript 02:47.50 >>> join/#ghostscript mvrhel_laptop (~chatzilla@50.159.85.185) 02:53.04 Chans: (ghostbot) in:#ghostscript 02:53.04 ircCheck: possible lost in space; checking.Tue Nov 5 02:53:04 2013 02:53.04 >ghostbot< TEST 02:53.04 IRCTEST: Yes, we're alive. 02:56.45 >>> Noldorin has signed off IRC (Read error: Connection reset by peer) [#ghostscript] 02:59.18 >>> join/#ghostscript plinnell (~mrdocs@sccc-66-78-236-243.smartcity.com) 02:59.18 >>> plinnell has signed off IRC (Changing host) [#ghostscript] 02:59.18 >>> join/#ghostscript plinnell (~mrdocs@opensuse/member/mrdocs) 03:00.58 >>> join/#ghostscript Noldorin (~noldorin@unaffiliated/noldorin) 03:02.18 FORK(27909) --- fork starting for 'RSSFeeds', PID == 27909, bot_pid == 5299 --- 03:02.19 FORK(27909) !ERROR! cannot load my module: RSSFeeds 03:02.19 FORK(27909) fork: took 1s for RSSFeeds. 03:02.19 FORK(27909) --- fork finished for 'RSSFeeds' --- 03:04.30 !WARN! PERL: readdir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 862. 03:04.30 !WARN! PERL: closedir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 869. 03:09.04 Chans: (ghostbot) in:#ghostscript 03:12.48 >>> plinnell has signed off IRC (Ping timeout: 240 seconds) [#ghostscript] 03:15.31 >>> join/#ghostscript tkamppeter_ (~till@p5DDB9D8D.dip0.t-ipconnect.de) 03:19.07 >>> tkamppeter has signed off IRC (Ping timeout: 260 seconds) [#ghostscript] 03:24.58 Chans: (ghostbot) in:#ghostscript 03:29.22 --- Saved uptime records. 03:32.34 FORK(31256) --- fork starting for 'RSSFeeds', PID == 31256, bot_pid == 5299 --- 03:32.35 FORK(31256) !ERROR! cannot load my module: RSSFeeds 03:32.35 FORK(31256) fork: took 1s for RSSFeeds. 03:32.35 FORK(31256) --- fork finished for 'RSSFeeds' --- 03:40.42 Chans: (ghostbot) in:#ghostscript 03:43.23 >>> Noldorin has signed off IRC (Quit: Computer has gone to sleep.) [#ghostscript] 03:56.16 Chans: (ghostbot) in:#ghostscript 03:56.16 ircCheck: possible lost in space; checking.Tue Nov 5 03:56:16 2013 03:56.16 >ghostbot< TEST 03:56.21 IRCTEST: Yes, we're alive. 04:02.49 FORK(4267) --- fork starting for 'RSSFeeds', PID == 4267, bot_pid == 5299 --- 04:02.50 FORK(4267) !ERROR! cannot load my module: RSSFeeds 04:02.50 FORK(4267) fork: took 1s for RSSFeeds. 04:02.50 FORK(4267) --- fork finished for 'RSSFeeds' --- 04:11.59 Chans: (ghostbot) in:#ghostscript 04:12.02 >>> join/#ghostscript marcosw (~marcosw@c-98-207-109-212.hsd1.ca.comcast.net) 04:16.10 >>> suleymancelik has signed off IRC (Quit: Leaving...) [#ghostscript] 04:27.53 Chans: (ghostbot) in:#ghostscript 04:29.02 >>> marcosw has signed off IRC (Quit: marcosw) [#ghostscript] 04:29.45 --- Saved uptime records. 04:32.57 FORK(9544) --- fork starting for 'RSSFeeds', PID == 9544, bot_pid == 5299 --- 04:32.58 FORK(9544) !ERROR! cannot load my module: RSSFeeds 04:32.58 FORK(9544) fork: took 1s for RSSFeeds. 04:32.58 FORK(9544) --- fork finished for 'RSSFeeds' --- 04:43.27 Chans: (ghostbot) in:#ghostscript 04:59.31 ircCheck: possible lost in space; checking.Tue Nov 5 04:59:31 2013 04:59.31 >ghostbot< TEST 04:59.31 IRCTEST: Yes, we're alive. 05:03.22 FORK(21254) --- fork starting for 'RSSFeeds', PID == 21254, bot_pid == 5299 --- 05:03.23 FORK(21254) !ERROR! cannot load my module: RSSFeeds 05:03.23 FORK(21254) fork: took 1s for RSSFeeds. 05:03.23 FORK(21254) --- fork finished for 'RSSFeeds' --- 05:15.14 Chans: (ghostbot) in:#ghostscript 05:29.56 --- Saved uptime records. 05:31.08 Chans: (ghostbot) in:#ghostscript 05:33.40 FORK(1075) --- fork starting for 'RSSFeeds', PID == 1075, bot_pid == 5299 --- 05:33.41 FORK(1075) !ERROR! cannot load my module: RSSFeeds 05:33.41 FORK(1075) fork: took 1s for RSSFeeds. 05:33.41 FORK(1075) --- fork finished for 'RSSFeeds' --- 06:02.46 LOG: last message repeated 4 times 06:02.46 ircCheck: possible lost in space; checking.Tue Nov 5 06:02:46 2013 06:02.46 >ghostbot< TEST 06:02.46 IRCTEST: Yes, we're alive. 06:04.36 FORK(20745) --- fork starting for 'RSSFeeds', PID == 20745, bot_pid == 5299 --- 06:04.37 FORK(20745) !ERROR! cannot load my module: RSSFeeds 06:04.37 FORK(20745) fork: took 1s for RSSFeeds. 06:04.37 FORK(20745) --- fork finished for 'RSSFeeds' --- 06:18.29 Chans: (ghostbot) in:#ghostscript 06:30.29 --- Saved uptime records. 06:33.53 Chans: (ghostbot) in:#ghostscript 06:34.53 FORK(25753) --- fork starting for 'RSSFeeds', PID == 25753, bot_pid == 5299 --- 06:34.54 FORK(25753) !ERROR! cannot load my module: RSSFeeds 06:34.54 FORK(25753) fork: took 1s for RSSFeeds. 06:34.54 FORK(25753) --- fork finished for 'RSSFeeds' --- 06:41.15 >>> join/#ghostscript suleymancelik (~suleymanc@95.0.196.154) 06:49.37 Chans: (ghostbot) in:#ghostscript 06:51.26 >>> mvrhel_laptop has signed off IRC (Ping timeout: 240 seconds) [#ghostscript] 07:00.24 >>> join/#ghostscript plinnell (~mrdocs@c-76-102-153-54.hsd1.ca.comcast.net) 07:00.24 >>> plinnell has signed off IRC (Changing host) [#ghostscript] 07:00.24 >>> join/#ghostscript plinnell (~mrdocs@opensuse/member/mrdocs) 07:05.21 !WARN! PERL: readdir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 862. 07:05.21 !WARN! PERL: closedir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 869. 07:05.21 Chans: (ghostbot) in:#ghostscript 07:05.21 ircCheck: possible lost in space; checking.Tue Nov 5 07:05:21 2013 07:05.21 >ghostbot< TEST 07:05.21 IRCTEST: Yes, we're alive. 07:05.31 FORK(3549) --- fork starting for 'RSSFeeds', PID == 3549, bot_pid == 5299 --- 07:05.32 FORK(3549) !ERROR! cannot load my module: RSSFeeds 07:05.32 FORK(3549) fork: took 1s for RSSFeeds. 07:05.32 FORK(3549) --- fork finished for 'RSSFeeds' --- 07:17.33 >>> suleymancelik has signed off IRC (Quit: Leaving...) [#ghostscript] 07:21.21 Chans: (ghostbot) in:#ghostscript 07:24.30 >>> join/#ghostscript suleymancelik (~suleymanc@95.0.196.154) 07:30.49 --- Saved uptime records. 07:35.33 FORK(10555) --- fork starting for 'RSSFeeds', PID == 10555, bot_pid == 5299 --- 07:35.34 FORK(10555) !ERROR! cannot load my module: RSSFeeds 07:35.34 FORK(10555) fork: took 1s for RSSFeeds. 07:35.34 FORK(10555) --- fork finished for 'RSSFeeds' --- 07:36.55 Chans: (ghostbot) in:#ghostscript 07:48.54 >>> chrisl_away materializes into chrisl 07:53.19 Chans: (ghostbot) in:#ghostscript 07:59.16 >>> join/#ghostscript suleymanceli (~suleymanc@178.233.164.4) 07:59.16 >>> suleymancelik has signed off IRC (Read error: Connection reset by peer) [#ghostscript] 08:01.50 >>> join/#ghostscript kens (~Miranda@31.185.216.66) 08:05.41 FORK(20888) --- fork starting for 'RSSFeeds', PID == 20888, bot_pid == 5299 --- 08:05.42 FORK(20888) !ERROR! cannot load my module: RSSFeeds 08:05.42 FORK(20888) fork: took 1s for RSSFeeds. 08:05.42 FORK(20888) --- fork finished for 'RSSFeeds' --- 08:09.45 Chans: (ghostbot) in:#ghostscript 08:09.45 ircCheck: possible lost in space; checking.Tue Nov 5 08:09:45 2013 08:09.45 >ghostbot< TEST 08:09.45 IRCTEST: Yes, we're alive. 08:25.32 Chans: (ghostbot) in:#ghostscript 08:31.26 --- Saved uptime records. 08:36.10 FORK(5071) --- fork starting for 'RSSFeeds', PID == 5071, bot_pid == 5299 --- 08:36.11 FORK(5071) !ERROR! cannot load my module: RSSFeeds 08:36.11 FORK(5071) fork: took 1s for RSSFeeds. 08:36.11 FORK(5071) --- fork finished for 'RSSFeeds' --- 08:40.56 Chans: (ghostbot) in:#ghostscript 09:04.34 >>> join/#ghostscript tor7 (~tor@h-2-60.a230.priv.bahnhof.se) 09:05.59 Robin_Watts: "naughty gcc ways"? 09:06.29 FORK(12209) --- fork starting for 'RSSFeeds', PID == 12209, bot_pid == 5299 --- 09:06.30 FORK(12209) !ERROR! cannot load my module: RSSFeeds 09:06.30 FORK(12209) fork: took 1s for RSSFeeds. 09:06.30 FORK(12209) --- fork finished for 'RSSFeeds' --- 09:11.14 >>> suleymanceli has signed off IRC (Quit: Linkinus - http://linkinus.com) [#ghostscript] 09:11.35 >>> join/#ghostscript suleymancelik (~suleymanc@95.0.196.154) 09:13.35 Chans: (ghostbot) in:#ghostscript 09:31.42 --- Saved uptime records. 09:31.42 Seen: Flushed 1 entries. 09:36.14 >>> join/#ghostscript sebblonline (5d5dfdfb@gateway/web/freenode/ip.93.93.253.251) 09:36.34 FORK(16049) --- fork starting for 'RSSFeeds', PID == 16049, bot_pid == 5299 --- 09:36.35 FORK(16049) !ERROR! cannot load my module: RSSFeeds 09:36.35 FORK(16049) fork: took 1s for RSSFeeds. 09:36.35 FORK(16049) --- fork finished for 'RSSFeeds' --- 09:36.52 >>> join/#ghostscript suleymanceli (~suleymanc@178.233.164.4) 09:36.52 >>> suleymancelik has signed off IRC (Read error: Connection reset by peer) [#ghostscript] 09:45.14 Chans: (ghostbot) in:#ghostscript 09:55.22 >>> suleymanceli has signed off IRC (Quit: Leaving...) [#ghostscript] 10:00.58 Chans: (ghostbot) in:#ghostscript 10:02.33 >>> join/#ghostscript suleymancelik (~suleymanc@178.233.185.141) 10:04.16 tor7: gcc extensions. 10:04.32 like not having to have declarations at the start of blocks. 10:04.41 oh, you mean c99... 10:04.58 that 14 year old standard that MS still hasn't bothered to update to 10:05.55 >>> Micha` has signed off IRC (Quit: rcirc on GNU Emacs 24.3.1) [#ghostscript] 10:06.08 I'm pretty sure MS doesn't require you to have cdeclarations at the start of blocks, but I think it issues a warning 10:06.25 Mayeb I'm wrong, I can't keep the various compilers straight any more 10:07.15 FORK(31220) --- fork starting for 'RSSFeeds', PID == 31220, bot_pid == 5299 --- 10:07.16 FORK(31220) !ERROR! cannot load my module: RSSFeeds 10:07.16 FORK(31220) fork: took 1s for RSSFeeds. 10:07.16 FORK(31220) --- fork finished for 'RSSFeeds' --- 10:11.15 mvrhel hit the problem yesterday, and it was MSVC that whinged, I believe. 10:11.37 Maybe he has the 'treat warnings as errors' option set 10:11.49 BUt anyway.... 10:12.29 IIRC, we disable MS "extensions" for most things except one or two of the third part libs..... 10:17.34 Chans: (ghostbot) in:#ghostscript 10:31.56 Seen: Flushed 4 entries. 10:32.26 --- Saved uptime records. 10:33.38 Chans: (ghostbot) in:#ghostscript 10:37.22 FORK(9115) --- fork starting for 'RSSFeeds', PID == 9115, bot_pid == 5299 --- 10:37.23 FORK(9115) !ERROR! cannot load my module: RSSFeeds 10:37.23 FORK(9115) fork: took 1s for RSSFeeds. 10:37.23 FORK(9115) --- fork finished for 'RSSFeeds' --- 10:41.48 >>> join/#ghostscript paulgardiner (~chatzilla@smtp.glidos.net) 10:50.12 Chans: (ghostbot) in:#ghostscript 10:58.14 >>> suleymancelik has signed off IRC (Quit: Leaving...) [#ghostscript] 11:05.26 !WARN! PERL: readdir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 862. 11:05.26 !WARN! PERL: closedir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 869. 11:07.08 Chans: (ghostbot) in:#ghostscript 11:07.38 FORK(9231) --- fork starting for 'RSSFeeds', PID == 9231, bot_pid == 5299 --- 11:07.39 FORK(9231) !ERROR! cannot load my module: RSSFeeds 11:07.39 FORK(9231) fork: took 1s for RSSFeeds. 11:07.39 FORK(9231) --- fork finished for 'RSSFeeds' --- 11:16.04 >>> join/#ghostscript suleymancelik (~suleymanc@178.233.164.4) 11:17.28 ircCheck: possible lost in space; checking.Tue Nov 5 11:17:28 2013 11:17.28 >ghostbot< TEST 11:17.28 IRCTEST: Yes, we're alive. 11:22.45 Chans: (ghostbot) in:#ghostscript 11:33.07 --- Saved uptime records. 11:37.49 FORK(8879) --- fork starting for 'RSSFeeds', PID == 8879, bot_pid == 5299 --- 11:37.50 FORK(8879) !ERROR! cannot load my module: RSSFeeds 11:37.50 FORK(8879) fork: took 1s for RSSFeeds. 11:37.50 FORK(8879) --- fork finished for 'RSSFeeds' --- 11:38.59 Chans: (ghostbot) in:#ghostscript 11:42.37 >>> tkamppeter_ materializes into tkamppeter 11:55.05 Chans: (ghostbot) in:#ghostscript 12:07.55 FORK(2065) --- fork starting for 'RSSFeeds', PID == 2065, bot_pid == 5299 --- 12:07.56 FORK(2065) !ERROR! cannot load my module: RSSFeeds 12:07.56 FORK(2065) fork: took 1s for RSSFeeds. 12:07.56 FORK(2065) --- fork finished for 'RSSFeeds' --- 12:08.21 >>> suleymancelik has signed off IRC (Ping timeout: 245 seconds) [#ghostscript] 12:11.19 Chans: (ghostbot) in:#ghostscript 12:16.42 >>> join/#ghostscript suleymancelik (~suleymanc@178.233.185.141) 12:21.29 ircCheck: possible lost in space; checking.Tue Nov 5 12:21:29 2013 12:21.29 >ghostbot< TEST 12:21.29 IRCTEST: Yes, we're alive. 12:26.36 Chans: (ghostbot) in:#ghostscript 12:28.13 http://www.pdflite.com/ I just discovered this project due to wikipedia updating its pdf sw category 12:28.29 apparently it is based on sumatrapdf and so it uses mupdf. 12:28.52 maybe interesting to see where they take it. 12:32.30 Seen: Flushed 1 entries. 12:33.12 --- Saved uptime records. 12:34.36 Uses Ghostscript, too...... 12:35.31 chrisl: where? how? 12:35.38 I can't find it in their source file. 12:35.58 Their "PDF Printer" is just a port monitor, with call out to Ghostscript 12:36.21 chrisl: ah, so gs is installed as a separate project? 12:36.31 It looks like it, yes 12:36.46 and RdMon too presumably 12:36.51 RedMon 12:37.00 kens: what is redmon? 12:37.07 port monitor 12:37.50 aha. 12:38.00 FORK(3302) --- fork starting for 'RSSFeeds', PID == 3302, bot_pid == 5299 --- 12:38.01 FORK(3302) !ERROR! cannot load my module: RSSFeeds 12:38.01 FORK(3302) fork: took 1s for RSSFeeds. 12:38.01 FORK(3302) --- fork finished for 'RSSFeeds' --- 12:38.05 Part of the Windows Printing System 12:38.12 sebras: if you look in PsEngine.cpp...... 12:38.13 captures what goes to a 'port' 12:39.17 chrisl: ah, gswin32c.exe. found it. 12:39.18 So when you print to a PostScripr printer, PS goes to the port. Capture that, feed it to GS and.... 12:40.30 sebras: I don't think sumatra has a "PDF printer", so I wonder why the pdflite source files related to theirs are "Copyright 2012 the SumatraPDF project authors"...... 12:40.32 hard to see what is sumatrapdf code and pdflite code. 12:41.27 chrisl: well, I do find a PsEngine.cpp even in sumatrapdf... 12:42.19 Oh, I didn't know that. I don't remember pdf creation being listed on Sumatra's website last time I looked 12:42.37 chrisl: I'm not sure they _use_ it. 12:43.07 Chans: (ghostbot) in:#ghostscript 12:43.21 >>> kens has signed off IRC (Ping timeout: 240 seconds) [#ghostscript] 12:43.34 chrisl: so... this still puzzles me. can I download pdflite and build from source and get pdflite? 12:45.03 sebras: I don't know, and I'm not really bothered enough to try! It may be that pdflite and sumatra are collaborating, hence the "cross over" of source files 12:46.09 chrisl: | you get that vertical bar back, I like periods better than exclamation marks. ;) 12:46.37 chrisl: np. I'm just puzzled. 12:47.04 But I was exclaiming my disinclination to try, so appropriate 12:47.39 chrisl: no need, I know all of you are usually busy. 12:48.28 >>> join/#ghostscript kens (~Miranda@31.185.216.66) 12:48.33 I'm just a bit sick and at home, so I'm just mucking about. 12:48.37 sebras: I just get a little irritated at applications that proclaim "we support PDF creation" and then buried somewhere else says "if you download Ghostscript to the actual hard bit".... 12:48.51 sebras: nothing serious, I hope 12:49.12 chrisl: just some stomach-illness I brought with me from shanghai. 12:49.50 chrisl: I'm getting better though. :) 12:49.58 "traveller's curse" ;-) 12:53.26 chrisl: ! 12:58.54 Chans: (ghostbot) in:#ghostscript 13:08.24 FORK(18424) --- fork starting for 'RSSFeeds', PID == 18424, bot_pid == 5299 --- 13:08.25 FORK(18424) !ERROR! cannot load my module: RSSFeeds 13:08.25 FORK(18424) fork: took 1s for RSSFeeds. 13:08.25 FORK(18424) --- fork finished for 'RSSFeeds' --- 13:19.48 LOG: last message repeated 3 times 13:19.48 >>> Fandekasp has signed off IRC (Ping timeout: 240 seconds) [#ghostscript] 13:27.10 I would really like to see a "Don't install any Toolbars or other sneak software" clause in the GPL 13:27.22 >>> chrisl materializes into chrisl_away 13:28.18 and beware when you update your graphics card drivers, AMD now bundles some crapware that it installs if you don't pay attention 13:28.27 (for any windows users) 13:31.34 Chans: (ghostbot) in:#ghostscript 13:32.36 Seen: Flushed 4 entries. 13:33.46 --- Saved uptime records. 13:36.18 >>> join/#ghostscript Micha` (~user@AMontpellier-654-1-98-87.w90-0.abo.wanadoo.fr) 13:37.15 paulgardiner: Hi! Do I recall correctly that you are in charge of the Android mupdf? 13:38.35 FORK(22074) --- fork starting for 'RSSFeeds', PID == 22074, bot_pid == 5299 --- 13:38.36 FORK(22074) !ERROR! cannot load my module: RSSFeeds 13:38.36 FORK(22074) fork: took 1s for RSSFeeds. 13:38.36 FORK(22074) --- fork finished for 'RSSFeeds' --- 13:39.51 Micha`: sorry on the phone. I'll get back to you 13:41.19 No problem. 13:48.20 Chans: (ghostbot) in:#ghostscript 14:00.39 >>> join/#ghostscript suleymanceli (~suleymanc@95.0.196.154) 14:00.39 >>> suleymancelik has signed off IRC (Read error: Connection reset by peer) [#ghostscript] 14:00.45 >>> kens has signed off IRC (Read error: Connection reset by peer) [#ghostscript] 14:02.31 >>> join/#ghostscript kens (~Miranda@31.185.216.66) 14:04.34 Chans: (ghostbot) in:#ghostscript 14:08.58 FORK(4236) --- fork starting for 'RSSFeeds', PID == 4236, bot_pid == 5299 --- 14:08.59 FORK(4236) !ERROR! cannot load my module: RSSFeeds 14:08.59 FORK(4236) fork: took 1s for RSSFeeds. 14:08.59 FORK(4236) --- fork finished for 'RSSFeeds' --- 14:17.57 Micha`: I'm back. I wouldn't say I am in charge of the Android build, but I may be able to help on issues with it. 14:19.33 have the clocks changed in the US yet? 14:20.01 wwI think yes 14:20.40 Chans: (ghostbot) in:#ghostscript 14:25.38 Robin_Watts: no meeting today though, henrys is moving house? 14:26.07 oh, right, of course. 14:26.19 I'd completely forgotten that. 14:31.54 paulgardiner: Well, I have no issue :-) 14:32.15 Excellent. That's what I like to hear. :-) 14:32.19 I'm taking mupdf as a base for a PDF annotator I'll need for work. To get use to the library, Android programming, Java programming, and all those hipster things, I did several toy projects. 14:32.29 One of them is to integrate a color picker for the Ink annotations, and I'm pretty much done with that. 14:32.45 I designed a new paintbrush picker for that in an independent library. So my questions are: 1. Would you be interested in having a look, and possibly integrate the changes? 2. In case of a mid-inking color change, what would be the expected behavior: save the current annotation and start a new one, or change the color of the current one? 14:32.48 Nice. 14:33.08 Seen: Flushed 5 entries. 14:33.10 Really, the changes in the software are minim. 14:33.34 But boy ho boy did I have a hard time with the color picker. 14:34.23 --- Saved uptime records. 14:34.48 Not sure what's best. One similar app I saw didn't allow setting of colour and width during the addition of the annotation, but allowed for changing those as a separate edit operation. 14:35.40 Whoever documented the Android API should be put under surveillance his schizophrenic behavior. 14:35.42 And the choice to edit was provided when the annotation was selected 14:36.11 IIRC, ezpdf allows for the change by saving the current annot and creating a new one. 14:36.31 Chans: (ghostbot) in:#ghostscript 14:38.04 Yeah. It makes sense to have a single color for each annotation because that makes the interface true to the PDF format, although it might not be the most convenient for the user. 14:38.52 I think its Adobe Reader that creates ink annotations with whatever color and width was last selected, and then you can touch select them to change any aspect 14:39.10 What I can do, though, is to provide the palette button on the annotation bar (the one with highlight, underline, strike, and ink). That way, the color is fixed beforehand. 14:39.20 FORK(7774) --- fork starting for 'RSSFeeds', PID == 7774, bot_pid == 5299 --- 14:39.22 FORK(7774) !ERROR! cannot load my module: RSSFeeds 14:39.22 FORK(7774) fork: took 2s for RSSFeeds. 14:39.22 FORK(7774) --- fork finished for 'RSSFeeds' --- 14:40.11 The downside of that is you probably don't want the same color for each type of annotation. 14:40.34 Presumably the palette button would set the color for all the annotation types. 14:40.35 Color customization makes sense for the other ones, though I planned to store the color in different parameters for each. 14:40.43 Precisely. 14:41.33 The Adobe way is quite nice because whenever you create an annotation you get whatever color you last selected for that annoation type. 14:41.44 Also avoids the need for an extra button. 14:42.03 ... at least on that menu bar 14:42.44 But I'm not particularly against other schemes. 14:43.56 Ah hang on. I know another argument for it: to be able to edit the color of an existing annotation is needed any way, so it makes sense to make that the main way to do it. 14:46.15 >>> join/#ghostscript Noldorin (~noldorin@unaffiliated/noldorin) 14:46.41 Editing the color of an already stored annotation would require a little bit more work, but I know how to do it, and that's still formative. However, isn't it a little bit counterintuitive to first draw something then change its color? 14:47.51 Maybe we can find a nice design to select the color of an annotation type in the annot bar too... 14:51.34 I have no hard oppinion. The only thing I will say, is I was surprised how well the create-then-edit method worked. Seemed quite natural in a touch-based UI where operations are so quick 14:52.36 Robin_Watts: a handful of commits on tor/master for review when you've got a mo 14:52.46 Chans: (ghostbot) in:#ghostscript 14:53.31 ... and come to think of it, it's no greater a number of operations than the other way around - just a smaller UI 14:54.07 tor7: if (*p++ == '>) goto parse_text; ? 14:54.32 but that's purely a style thing, that commit is fine. 14:55.00 and the dash_len one is fine too. 14:55.10 Robin_Watts: hm, let me ponder the style thing 14:55.46 no, it needs to be a while. it's skip until '>' or end of string 14:55.56 but I see what you mean 14:56.35 I wasn't suggesting not having as a while. 14:56.43 just that the inner bits could be simplified. 14:56.55 yeah, I see what you mean now 14:57.06 >>> suleymanceli has signed off IRC (Ping timeout: 245 seconds) [#ghostscript] 15:00.56 The tree one... I am not familiar with AA trees. 15:00.58 Robin_Watts: pull again, I one-linerised it as you suggested. much more comprehensible that way. 15:01.21 what's the benefit to the use of sentinel rather than just 'NULL' ? 15:01.24 https://en.wikipedia.org/wiki/AA_tree a simplified variant of a red-black tree 15:01.35 tor7: I'd agree, but all my colleagues would disagree. I'm so happy to be part of mupdf! :) 15:01.49 >>> join/#ghostscript mvrhel_laptop (~chatzilla@c-50-159-85-185.hsd1.wa.comcast.net) 15:01.50 Robin_Watts: it makes the inner loops easier (no need for special casing NULL tests) 15:02.15 Arne Andersson. Any relation? :) 15:02.23 tor7: isn't there a bug in the fz_debug_xml()? in the new for-loop you fz_debug_xml item->down... shouldn't this be child? 15:02.56 sebras: ahem. yes. 15:03.26 Robin_Watts: apart from andersson being the #1 most common surname in sweden? nope :) 15:04.47 tor7: the aa-tree is supposed to be used for text-search? 15:05.12 sebras: I'm using it to look up nodes by id-name in the svg parser 15:05.22 paulgardiner: Ok, sounds good. I'll get back to you when it's done then! 15:05.22 our hash table is optimised for fixed key lengths 15:05.32 !WARN! PERL: readdir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 862. 15:05.32 !WARN! PERL: closedir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 869. 15:05.36 and an aa-tree is trivial to implement... 15:05.36 tor7: As a style thing, I prefer to typedef a function type and use that as an arg. 15:05.51 rather than having void (*arg)(.......) everywhere. 15:06.06 Micha`: excellent 15:06.14 Robin_Watts: we could make a generic fz_free_func typedef, I think we have that same function pointer signature in a couple of other places 15:06.19 I can see a few places where the sentinel stuff avoids checks, yeah. 15:08.01 tor7: OK, all lgtm. 15:08.29 Robin_Watts: fab. I'll fix the bug sebras spotted and push then. 15:08.29 Chans: (ghostbot) in:#ghostscript 15:09.03 tor7: not done with aa-tree, but push if you want. 15:09.24 FORK(22954) --- fork starting for 'RSSFeeds', PID == 22954, bot_pid == 5299 --- 15:09.25 FORK(22954) !ERROR! cannot load my module: RSSFeeds 15:09.25 FORK(22954) fork: took 1s for RSSFeeds. 15:09.25 FORK(22954) --- fork finished for 'RSSFeeds' --- 15:09.37 sebras: I can wait :) 15:11.22 paulgardiner: By the way, I pushed a few bug reports which are somewhat related to annotations and the Android app. I think some of them should be cleared before we commit this whole color picker thing. If you have the time, can you have look? I usually provide patch proposals, so it's basically just a matter of reviewing those. 15:11.54 Micha`: oh okay. Will do. Thanks for pointing it out 15:12.12 paulgardiner: No trouble, thanks! 15:21.24 rayjj: there? 15:21.32 Bit early 15:22.02 thanks 15:22.24 if ray_laptop is here then Ray is here usually 15:22.35 glad you all didn't talk too much so I could read the scrollback... I need to turn logging on 15:22.46 this channel is logged 15:22.57 you can read the logs.... 15:24.01 tor7: ok, done. lgmt too. 15:24.48 Chans: (ghostbot) in:#ghostscript 15:30.57 Robin_Watts: one more on tor/master (the stroke state on the stack changes we discussed last week) 15:31.29 >>> join/#ghostscript marcosw (~marcosw@c-98-207-109-212.hsd1.ca.comcast.net) 15:31.40 morning 15:31.47 tor7: that's only a renaming commit, no..? 15:31.50 marcosw: Aha, hi. 15:31.56 uh oh 15:32.07 sebras: no? 15:32.12 marcosw: 801 says it's uploaded 2 files to "the ftp site". 15:32.13 tor7: or did you stick the stork state commit on tor/svg.. yes. 15:32.25 it changes how fz_keep_stroke_state works 15:32.32 sebras: you may have pulled before my push completed 15:32.36 it's on both tor/svg and tor/master 15:33.02 tor7: whoa! indeed. refetching moved tor/master 15:33.16 Seen: Flushed 8 entries. 15:33.30 Robin_Watts: there is a new "data_file.zip" that contains two files. 15:33.39 >>> chrisl_away materializes into chrisl 15:33.43 meeting time? 15:33.56 Phew, almost late again..... 15:33.56 tor7: That looks lovely. 15:34.08 mvrhel_laptop: No meeting this week, henrys is moving house. 15:34.09 mvrhel_laptop: chrisl: henrys is out today, I believe the meeting is cancelled. 15:34.17 mvrhel_laptop: You can go back to bed for a bit :) 15:34.42 marcosw: OK. I'll need to look for the login details again... 15:34.49 tor7: doh, of course! Ah well..... 15:34.49 --- Saved uptime records. 15:35.03 I'll just put it on casper 15:35.07 how did i miss that important memo 15:35.14 chrisl: for once I remember the time correctly, and the meeting is cancelled :) just my luck... 15:35.36 oh there it is 15:35.56 it was too far in advance 15:36.10 tor7: I don't understand the code, but I spot no errors. 15:36.35 in that case bbiab 15:36.56 tor7: well, at least I didn't actually rush back - I just couldn't hit another squash ball to save my life, so ended the session 15:37.05 Robin_Watts: okay, ~marcos/data_file.zip is on casper. 15:37.39 sebras: currently we have to create a new fz_new_stroke_state for each graphics call, and make sure to keep it 'const' after use so we don't mess up the display list 15:38.00 I wanted a use case where I could keep the stroke state on the stack, and have the display list automatically create its own clones 15:38.28 so I don't have to worry about clobbering old data, and not worry about object lifetimes 15:38.44 this was the easiest way I found, that didn't mess with existing code 15:39.35 sebras: the reason we don't do this always is because we can support arbitrary dash pattern lengths (and thus need to keep stroke states in the heap) 15:39.42 FORK(25846) --- fork starting for 'RSSFeeds', PID == 25846, bot_pid == 5299 --- 15:39.42 tor7: ok. so presumably fz_default_stroek_state will be used elsewhere later on. 15:39.43 FORK(25846) !ERROR! cannot load my module: RSSFeeds 15:39.43 FORK(25846) fork: took 1s for RSSFeeds. 15:39.43 FORK(25846) --- fork finished for 'RSSFeeds' --- 15:39.50 sebras: in the svg device :) 15:39.57 tor7: ok. 15:40.00 in the "Implement graphcs state stack" commit 15:40.55 I like that you separate out commits in logical steps. I'm sooo unused to that when reading patches at work. :-/ 15:41.05 Chans: (ghostbot) in:#ghostscript 15:41.12 the svg parser can tiger, and read back robin's svgdevice output for paths and text (which he draws as symbol/use paths) 15:41.31 tor7: Oh. that's excellent! 15:41.44 sebras: it's all your fault! 15:41.45 I didn't realise we could eat our own dog food yet. 15:41.56 tor7: sorry, but it makes the git look nice. :) 15:41.59 Robin_Watts: we can't do much else, but that's my primary goal :) 15:42.52 >>> join/#ghostscript ray_laptop (~chatzilla@rrcs-64-183-45-163.west.biz.rr.com) 15:42.58 morning, all 15:43.12 good thing there is no meeting. The kids were running late today. 15:43.46 Morning ray_laptop 15:43.53 School doesn't start until 7:48, but they like to get there early (usually) to chat with their friends. Today they were dragging 15:44.01 I have 3 commits on robin/master that should get the alignment stuff working. 15:44.14 ray_laptop : Gigs was looking for you earlier 15:45.07 tor7: question though... in fz_clone_stroke_state(), extra seems to refere to the unused entries in dash_list. why do you need to copy them? and wouldn't you copy too little data into the clone? 15:45.24 kens: thanks. I see. But he didn't ask a question fo rthe logs. I'll check my email 15:45.42 He's onlione so I guess he will ask again 15:45.50 tor7: to me nelem - len would make sense. 15:45.56 tor7: maybe. 15:46.12 sebras: stroke->dash_list is at the end of the struct and always has 32 entries 15:46.26 extra is how many extra entries over those 32 that are malloced 15:46.39 kens: yes, especially since you mentioned his name (if he has highlighting on) 15:46.53 so yes, we might copy less than the full struct if dash_len < 32 15:47.33 tor7: but then clone->dash_len would be <32 so it ought not to be a problem. 15:48.10 tor7: at the same time as I realized that dash_list was 32+ entires I promptly forgot about it... 15:49.51 tor7: ok, no more reviews today. 15:50.19 marcosw: where is the FTP site that 801 uses ? 15:50.57 in my home office: ftp://marcosw.no-ip.com 15:51.21 marcosw: oh, thanks. I was looking on casper :-/ 15:51.49 I put the latest file from customer 801 on casper: ~marcos/data_file.zip 15:51.56 marcosw: I don't think I have the password for that. 15:52.06 to make it easer for Robin_Watts. 15:52.07 marcosw: I did see data_file.zip on casper. 15:52.18 is it still being uploaded ? 15:52.23 ray_laptop: I'll forward the password login information to you. 15:52.44 ray_laptop: no, it's ocmplete 15:53.03 marcosw: Thanks! 15:53.17 marcosw: I echo "Thanks" 15:54.28 ray_laptop: I've just got the pad/align stuff passing all my tests, so I'm going to modify the 801 device to use it, fix the SSE to use the aligned versions and then do some timing tests. 15:55.10 Robin_Watts: were the mods to allow timing (suppress output) in the 801.tar.gz ? 15:55.13 I've emailed tech@artifex with the customer 801 ftp site login information. 15:55.23 marcosw: thanks 15:56.45 Robin_Watts: I've got a branch with your changes, so if you update the 801.tar.gz, it would be appreciated (or if you also are on a branch, just send me the patch) 15:57.15 Chans: (ghostbot) in:#ghostscript 15:57.41 Robin_Watts: but I think you mentioned that you weren't using git because you didn't want to inadvertently 'push' 15:58.43 ray_laptop: When I get it working, I'll update the zip, yes. 15:59.00 Robin_Watts: Ta 15:59.04 ray_laptop: The mods to allow timing may not have been in 801.tar.gz 15:59.25 Did someone on here mention an nmake clone that uses multiple cores? 15:59.30 Robin_Watts: it didn't look like it 15:59.44 I am trying 'jom', but that doesn't seem to like our makefiles. 16:00.54 ray_laptop, Robin_Watts: it (jom) doesn't work: it doesn't seem to correctly support the "include" directive :-( 16:01.30 chrisl: Right, that was what I thought. Shame. 16:02.33 And as it's "good enough" to build qt, I doubt our weird requirements will be fulfilled unless we hack on it ourselves.... 16:03.02 Hmm. There are fixed bugs in there wrt !include, so it does support that... 16:04.09 Yep, but there is something in *how* supports it that is missing. 16:04.20 ray_laptop: hey.. heh yeah I know what you meant about the banging it... once you get a bad knuckle it just gets worse 16:04.55 Robin_Watts: or maybe it doesn't like recursive calls? I can't remember what target(s) I tried 16:05.01 ray_laptop: for my purposes I may be able to ignore DN colorspaces and just mess with separation spaces... a lot of the times these programs seem to put colorants into DN spaces they didn't need to be in 16:05.11 It complained that it couldn't find 'debugclean:' for me. 16:05.57 I tried a couple of targets, it complained about not finding any of them 16:06.50 ray_laptop: sometime when you have a few minutes I'd like to expand on what you were telling me about the planar rendering 16:07.07 bbiab 16:07.08 >>> marcosw has signed off IRC (Quit: marcosw) [#ghostscript] 16:08.26 tor7, Robin_Watts: why does fz_expand_rect not expand empt rectangles? Answering my own question, I suppose in many cases empty rectangles are uninitialised, but I have a case where the rectangle is initentionally a point. 16:09.40 Robin_Watts: TBH, I wasn't inclined to devote much more than a cursory look at jom - I'm not going to substantially rejig the Windows build to get it working with jom, so.... 16:09.54 paulgardiner: An empty rectangle is any rectangle where x1 < x0 or y1 < y0 16:10.07 chrisl: no, indeed. i might play with the jom sources. 16:10.18 FORK(24087) --- fork starting for 'RSSFeeds', PID == 24087, bot_pid == 5299 --- 16:10.19 FORK(24087) !ERROR! cannot load my module: RSSFeeds 16:10.19 FORK(24087) fork: took 1s for RSSFeeds. 16:10.19 FORK(24087) --- fork finished for 'RSSFeeds' --- 16:10.24 paulgardiner: So how can you expand an empty rectangle meaningfully? 16:10.46 Robin_Watts: it might be worth seeing what the diagnostics output says 16:10.56 suppose I take the intersection of 2 rectangles (0,0)->(1,1) and (2,2)->(3,3) 16:10.58 That's empty. 16:11.02 How can I expand that? 16:11.23 chrisl: I tried, it didn't say anything. I'll play at some point. 16:11.54 Robin_Watts: ah, less than useful :-( 16:13.07 Robin_Watts: no, an empty rectangle is one with x0==x1 or y1==y0. your case is the infinite rectangle. 16:13.26 >>> mvrhel_laptop has signed off IRC (Ping timeout: 240 seconds) [#ghostscript] 16:13.30 paulgardiner: am empty rectangle with a defined position, and an empty rectangle with no position, that's a good question how to distinguish 16:13.39 Yeah 16:13.59 Chans: (ghostbot) in:#ghostscript 16:14.23 I can do the expansion in line in the place where I know it is intentionally a single point. 16:14.39 paulgardiner: I am afraid that expanding an empty rectangle might potentially break some assumption somewhere 16:14.47 But I was just checking we think the current imp is correct 16:14.56 paulgardiner: That would seem the best solution to me, unless you can come up with a better representation of empty/infinite rects. 16:15.12 if you check the use cases, it might turn out that we can safely expand empty rects (the default fz_empty_rect is just located at 0,0) 16:15.20 No. I think that's best. I just wanted to check what you thought 16:16.28 but I think we may have some optimisations where we return fz_empty_rect if an intersection is empty, and that is supposed to be at an undefined location 16:16.39 I guess we could have fz_expand_known_to_be_welldefined_rect... assuming someone could think of a snappy name for it 16:16.41 and then if we expand it to make sure we cover and strokes, it'll go wrong 16:16.56 fz_expand_rect_or_point ? 16:17.06 Oh yeah 16:17.45 But is it worth adding? 16:17.56 paulgardiner: probably not, if you only use it in one spot 16:17.57 That is a good name 16:18.13 Okay. Thank. I'll stick with the inline code 16:18.27 paulgardiner: or just make it static local to that file 16:20.21 Have it as a static local function for now. 16:20.37 That way we can easily make it global if we need it later, and it keeps the code clear. 16:21.13 FWIW, I went through the other use of fz_expand_rect when I was working on this bug, and saw no other obvious occurrence of a potential one point rectangle. 16:21.42 However, there are many places where two rectangles are intersected, and no difference is made between a one point intersection and no intersection at all. 16:22.16 At the time, Robin told me this is due to the fact that rectangles are bottom-right open and top-left closed, so it probably makes sense. 16:23.12 Micha`: Ah. I have a question 16:23.19 We all do. 16:23.42 (Though the answer to most is likely "chocolate chips cookies") 16:23.43 Your patch looks to avoid the expansion in the non-empty case. Is that a slip? 16:25.00 Sorry, you mean to avoid the expansion in the empty case? 16:25.37 Oh no. I see. I'm misreading it 16:26.55 Ahah, I see what you mean. I pondered on using a "non_empty" variable for it to be more readable :-) 16:27.12 Gigs-: sorry. I had a phone call. So, what did you want to talk about (something about planar rendering) ? 16:27.16 Nah! It's just me being daft. 16:27.55 I'll take your word for it, then :-) 16:28.02 I think empty might be equiv to k == 0 16:30.03 You are right. I didn't read the code close enough. 16:30.03 Chans: (ghostbot) in:#ghostscript 16:30.18 ray_laptop: Bugger. I haven't fixed the NumRenderingThreads case yet :( 16:30.34 It was correct is all that matters. Nice to have this subtle bug fixed 16:31.17 (Though my personal daftness could interfere with my close reading :-)) 16:33.30 >>> join/#ghostscript mvrhel_laptop (~chatzilla@ip-64-134-128-116.public.wayport.net) 16:33.51 Seen: Flushed 11 entries. 16:35.12 --- Saved uptime records. 16:36.08 >>> kens has signed off IRC (Ping timeout: 240 seconds) [#ghostscript] 16:36.52 Robin_Watts: I guess timing when that doesn't work is a bit premature ;-) 16:37.51 Robin_Watts: BTW, I suggest timing with NumRenderingThreads=0 as well (just for reference), and I had suggested collecting the timing from the JEITA tests for the customer 16:39.10 Robin_Watts: of course, we might want to use some other "well known" tests like PLRM or PDF Reference, and maybe Altona (but those are killers!) 16:39.45 The Altona won't show much difference due to your improvements, so maybe leave those out. 16:40.15 >>> sebblonline has signed off IRC (Quit: Page closed) [#ghostscript] 16:40.45 FORK(21776) --- fork starting for 'RSSFeeds', PID == 21776, bot_pid == 5299 --- 16:40.46 FORK(21776) !ERROR! cannot load my module: RSSFeeds 16:40.46 FORK(21776) fork: took 1s for RSSFeeds. 16:40.46 FORK(21776) --- fork finished for 'RSSFeeds' --- 16:46.02 Chans: (ghostbot) in:#ghostscript 16:50.38 ray_laptop: The altona tests are MASSIVELY faster with the new device than the old. 16:50.49 but that's more to do with changes from 9.06 to 9.10 16:51.32 >>> tor7 has signed off IRC (Remote host closed the connection) [#ghostscript] 16:56.47 Robin_Watts: well, I guess we should mention that to make sure they have sufficient incentive to move to newer versions :-) 16:59.29 My previous mail to them alluded to that, I think. 17:01.33 Robin_Watts: little commit on paul/master when you have a moment 17:01.53 Chans: (ghostbot) in:#ghostscript 17:04.18 ray_laptop: sorry i had a phone call too :P 17:04.43 paulgardiner: lgtm. 17:05.02 ray_laptop: planar means it's maintaining for example an 8 bit raster plane for each colorant right... after all of them are rendered how does it know what overprints what? 17:05.43 Robin_Watts: ta muchly 17:06.47 Gigs-: The overprinting is done when we draw into the planes. 17:07.48 if we have planes for C, M, Y, K and say, Orange, and Orange is supposed to overprint the others, then when we draw a shape in Orange, that clears that C, M,Y, K planes, AIUI. 17:09.07 what if you encounter CMY data later that is under the Orange? 17:09.18 do you have to pre-sort the rendering process? 17:09.51 or is it assumed that overprint is controlled in PDF by the ordering of the objects anyway 17:11.04 FORK(16213) --- fork starting for 'RSSFeeds', PID == 16213, bot_pid == 5299 --- 17:11.05 FORK(16213) !ERROR! cannot load my module: RSSFeeds 17:11.05 FORK(16213) fork: took 1s for RSSFeeds. 17:11.05 FORK(16213) --- fork finished for 'RSSFeeds' --- 17:18.00 Chans: (ghostbot) in:#ghostscript 17:20.30 Gigs-: I'm no expert here, but I assume that if you meet CMYK later that plots under the Orange, it'll be laid down. 17:20.38 mvrhel_laptop is the overprinting expert. 17:21.35 what is the question? 17:22.38 Gigs. When we are doing a new drawing that is overprint, it uses the overprint compositor to get what was previously drawn and does the proper drawing in the bands that need it 17:22.55 i.e. a get_bits of what is in the planes now. 17:23.13 then it looks at what colorants are supposed to change and changes only those 17:23.24 and then puts the new values back 17:23.55 * Robin_Watts/#ghostscript realises there is stuff about this he hadn't appreciated. 17:24.04 this is only guaranteed to work when we maintain a separate plane for each colorant 17:24.08 mvrhel_laptop: if you'll excuse a couple of silly questions... 17:24.24 so, overprint is specified in that something says "Orange overprints CMYK" 17:24.40 no you don't get to say it overprints only CMYK 17:24.52 you could have other colorants 17:24.53 You only get to say "Orange overprints" ? 17:25.34 you have two binary settings overprint on/off and overprint mode 17:25.50 overprint mode uses special handling for cases where the target value is 0 17:25.55 i.e. no ink yet 17:25.59 Ah, so it's not even a per colorant thing? 17:26.07 right 17:26.09 It's just globally 'overprinting or not'. 17:26.11 Right. 17:26.14 right 17:26.36 actually not the target value is 0 17:26.52 but the source color value of 0 has special meaning when mode is set 17:27.00 OK. so suppose I draw something on the page, then I change to Orange, and set overprint mode on. Then I draw that on top. That will remove the CMYK from the parts of the page where the orange goes. 17:27.44 Now if I turn overprint off again, and draw on top again, I can get a mix of orange and other colors ? 17:29.06 overprint "on" means don't erase other plates 17:29.11 mvrhel_laptop: right, so if you paint with CMYKB = 0xff0000ff00 with overprint mode set to look at colorants, only M and K get modified 17:29.22 actually the overprint mode only is relevant for CMYK 17:30.02 mvrhel_laptop: so, in my example, B would get modified ? 17:30.11 good question 17:30.28 acutally no you are correct ray_laptop 17:30.36 mvrhel_laptop: OK, thanks. 17:30.42 the spec is a little oddly written wrt this though 17:30.52 * ray_laptop/#ghostscript agrees 17:31.12 although the spec does say 17:31.14 Nonzero overprint mode applies only to painting operations that use the current color in the graphics state when the current color space is DeviceCMYK 17:31.28 so this is not a DeviceN color space 17:31.44 if you were painting with CMYKB mode should have no effect 17:31.51 mvrhel_laptop: right, but our device profile may have B set, right ? 17:32.16 oh lets not pull color management into this dicussion 17:32.22 mvrhel_laptop: OK. 17:32.43 it can be the elephant in the room ;-) 17:32.48 so Robin_Watts with overprint on, if you are drawing with Orange only the orange plane will be changed 17:33.00 with overprint off, you will end up blowing away the CMYK planes 17:33.51 if you are drawing with CMYK values with overprint on and mode on, then which planes get left alone depends upon what source CMYK values are zeror 17:34.00 those that are zero will not be drawn 17:34.00 Chans: (ghostbot) in:#ghostscript 17:34.00 Seen: Flushed 6 entries. 17:34.23 mvrhel_laptop: so, just to make sure I understand, with overprint on, and DeviceCMYK source color, it will never modify the Orange plane, right ? 17:34.38 right 17:34.48 irrespective of overprint mode 17:34.49 mvrhel_laptop: Thanks. 17:34.55 oh no 17:35.02 oh yes sorry ray_laptop 17:35.09 mvrhel_laptop: thanks 17:35.20 I was thinking you said irrespective of overprint on/off not mode 17:35.33 mvrhel_laptop: np 17:35.47 by regardless of the mode, if op is on, the orange plane will be left alone with drawing CMYK 17:35.57 --- Saved uptime records. 17:36.13 mvrhel_laptop: that's what I tried to say :-) 17:36.18 right. 17:36.48 Now I worry about if we are doing op mode correctly in the DeviceN case where we have CMYK+O . 17:37.01 I will have to double check this at some point 17:37.26 mvrhel_laptop: there's also the complication of separation spaces with process color names - so /Separation /Cyan behaves differently to CMYK with MYK all zero. 17:38.05 actually a sep space with just C will behave like CMYK with op mode on and M=Y=K=0 17:38.17 that I know works 17:38.30 Yeh, I meant just overprint, not opm 17:38.43 right with opm false those will behave differently 17:38.50 with opm true they will behave the same 17:39.02 overprint is a messy hack :-( 17:39.19 yes. I agree. 17:39.43 Sorry, just sticking my nose in as I don't want to start debugging my next ufst problem :-( 17:41.12 FORK(26044) --- fork starting for 'RSSFeeds', PID == 26044, bot_pid == 5299 --- 17:41.13 FORK(26044) !ERROR! cannot load my module: RSSFeeds 17:41.13 FORK(26044) fork: took 1s for RSSFeeds. 17:41.13 FORK(26044) --- fork finished for 'RSSFeeds' --- 17:41.41 Robin_Watts: can a process_fn figure out if it's "dev_" parameter is a clist or not ? 17:42.07 ray_laptop: That's the kind of question I'd ask you :) 17:42.14 Robin_Watts: I'm thinking that it will know it is a gx_device_printer, so it should be able to use PRINTER_IS_CLIST, right ? 17:42.32 That's a horrible hack, right? 17:43.11 Nothing guarantees that process_page is only called for gx_device_printers. 17:43.31 Robin_Watts: well, it's a defined macro, widely used. As long as everybody that wants to know uses the macro, we can always fix it by making it explicit 17:44.09 Robin_Watts: a device defines its process_fn, and *it* knows it is a gx_device_printer, right ? 17:44.27 Ok. That is true. 17:44.28 Robin_Watts: (I am thinking of the xxxx-aps device, of course) 17:44.46 why should the xxxx-aps device need to know if it's a clist or not ? 17:45.04 Robin_Watts: an enhancement I'm working on :-) 17:46.28 but to let the secret out, I've fixed cmd_drawing_color_usage for devn colors, and so if a plane has no usage, it will be all 0's 17:46.58 so, for that colorant of a band, we can take a really fast path 17:47.21 Robin_Watts: and that will be *very* common on things like text pages 17:48.34 ray_laptop: Right. Nice. 17:48.40 Robin_Watts: I was also thinking of skipping alll of the average and BNM and packing and just writing 0's if all the input bytes are 0's 17:48.50 yes indeed. 17:49.01 Robin_Watts: the latter would take care of margins 17:49.19 or places where there is something small on the plane 17:50.00 Chans: (ghostbot) in:#ghostscript 17:50.24 I don't know how much the latter help, since it means a conditional branch, but we can test it 17:50.26 ray_laptop: You're talking about changing the SSE code to spot the all 0 case, right? 17:50.59 Robin_Watts: for the second case, yes. The first case doesn't need the SSE loop 17:52.19 the second case doesn't help the memory bandwidth, but it does skip quite a few SSE instructions 17:53.22 Yeah, the color_usage let's us just go to a memset. The spotting all 0's does indeed save a lot, and would probably be a smart move. 17:54.30 so my guess is that it would help, but for cases where there most of the area is scribbled on (such as the black plane on a text page), we'd have to rely on branch prediction working right 17:55.26 there is a way to "hint" a branch prediction, and we could set the hint to "branch not taken" so the case where we have a lot of work to do doesn't get dinged 17:56.09 of course, the support for hints is processor dependent, but seems to be a no-op if it is not supported (such as on AMD) 17:56.50 but current literature seems to suggest that manual hinting isn't really needed 17:58.31 >>> join/#ghostscript marcosw (~marcosw@c-98-207-109-212.hsd1.ca.comcast.net) 18:00.15 I can't see that the cost of a test and a branch should be significant. 18:00.57 So our big potential MuPDF customer (395) is back in touch again with a list of questions. 18:01.17 So I will have to devote some time to that tomorrow to take some timings. 18:04.38 Robin_Watts: I can do the timings for cust 801 if you want (once I get your latest code with the alignment and timing mode changes) 18:05.10 ray_laptop: Thanks. 18:06.20 Chans: (ghostbot) in:#ghostscript 18:09.39 >>> chrisl materializes into chrisl_away 18:11.03 >>> join/#ghostscript sojic (~sojic@92.55.124.157) 18:11.14 FORK(1217) --- fork starting for 'RSSFeeds', PID == 1217, bot_pid == 5299 --- 18:11.15 FORK(1217) !ERROR! cannot load my module: RSSFeeds 18:11.15 FORK(1217) fork: took 2s for RSSFeeds. 18:11.15 FORK(1217) --- fork finished for 'RSSFeeds' --- 18:22.40 Chans: (ghostbot) in:#ghostscript 18:30.26 Robin_Watts: There is a what looks like a really *ugly* hack in gx_default_create_buf_device -- it uses the "color_usage" to signal "page_device" to the make_mem_device. It used to be based on 'band_complexity" back when we had that :-( 18:32.11 The "special hack for setting up printer devices" ? 18:32.57 Yes, I've been working in that area, and while this work has removed one nasty hack, and cleaned up some code, it's left that one. 18:33.15 ray_laptop: My first quick test indicates that the aligned SSE is now working. 18:33.29 Robin_Watts: great! 18:33.32 I've updated the 801.tar.gz 18:33.55 Robin_Watts: thanks. Does it have the timing method changes, too ? 18:33.56 But it relies on the commits on robin/master being applied obviously. 18:34.02 ray_laptop: It does. 18:34.02 Seen: Flushed 4 entries. 18:34.24 So, can you look over the commits on robin/master when you get a chance please? 18:34.46 I'd like your opinion on whether anything there can be done better before we continue. 18:34.47 Robin_Watts: OK. I'll look at those, now 18:34.51 Thanks. 18:36.12 --- Saved uptime records. 18:38.14 Chans: (ghostbot) in:#ghostscript 18:38.23 >>> join/#ghostscript henrys (~henrys@c-76-25-94-13.hsd1.co.comcast.net) 18:39.18 Hi henrys. Move done ? 18:41.26 FORK(6546) --- fork starting for 'RSSFeeds', PID == 6546, bot_pid == 5299 --- 18:41.27 FORK(6546) !ERROR! cannot load my module: RSSFeeds 18:41.27 FORK(6546) fork: took 1s for RSSFeeds. 18:41.27 FORK(6546) --- fork finished for 'RSSFeeds' --- 18:44.00 >>> sojic has signed off IRC (Read error: Connection reset by peer) [#ghostscript] 18:44.23 >>> join/#ghostscript sojic (~sojic@92.55.124.157) 18:45.29 Robin_Watts: Looks, OK, but you could move the #ifdef TEST_PAD_AND_ALIGN into gxbitmap.h and make it active for all devices (just #define bitmap_raster_pad_align_ to ignore 'pad' and 'log2_alig' and use the test values) 18:46.00 that might stress some devices :-) 18:46.58 ray_laptop: No, I definitely don't want to do that. 18:47.21 the bugs I have been chasing all day are to do with devices not copying pad and log2_align_mod each time they make a new device. 18:47.46 hence having those values ignored would not test the propagation of those values through the system. 18:48.04 I picked ppm and psd as being good test candidates cos that's one planar and one not. 18:48.24 Robin_Watts: OK. So, the changes look fine. Go ahead with them, as far as I am concerned 18:48.53 >>> sojic has signed off IRC (Ping timeout: 272 seconds) [#ghostscript] 18:49.33 ray_laptop: Thanks. 18:50.28 >>> paulgardiner has signed off IRC (Quit: ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]) [#ghostscript] 18:54.28 Chans: (ghostbot) in:#ghostscript 19:05.38 !WARN! PERL: readdir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 862. 19:05.38 !WARN! PERL: closedir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 869. 19:10.02 Chans: (ghostbot) in:#ghostscript 19:10.58 ray_laptop: Hmm. 19:11.38 FORK(31997) --- fork starting for 'RSSFeeds', PID == 31997, bot_pid == 5299 --- 19:11.39 FORK(31997) !ERROR! cannot load my module: RSSFeeds 19:11.39 FORK(31997) fork: took 1s for RSSFeeds. 19:11.39 FORK(31997) --- fork finished for 'RSSFeeds' --- 19:11.41 On their 2 supplied files (J12 and J6), the old device beats us on J12 (20.3s old vs 20.8s new). 19:12.16 but on J6 the new one is a convincing win (30.9 old, 24.5 new) 19:14.36 >>> mvrhel_laptop has signed off IRC (Ping timeout: 245 seconds) [#ghostscript] 19:14.40 >>> Noldorin has signed off IRC (Write error: Broken pipe) [#ghostscript] 19:14.51 Robin_Watts: yes, I'm in, of course it is all chaos, but most of our stuff is at the new place. 19:15.11 cool. 19:15.24 Robin_Watts: so, maybe with skipping some empty planes, we can beat them on J12 as well :-) 19:15.33 ray_laptop: We can hope. 19:18.37 Robin_Watts: at least since those are .ps files, they don't have any transparency that isn't flattened 19:20.35 >>> join/#ghostscript henrys_ (~henrys@c-76-25-94-13.hsd1.co.comcast.net) 19:21.45 >>> henrys has signed off IRC (Ping timeout: 265 seconds) [#ghostscript] 19:21.46 >>> henrys_ materializes into henrys 19:21.56 Robin_Watts: On J12, many of those pages will be helped with the the SSE skipping 0's on a plane, so I'll definitely tackle that. Some of the pages look like they may be able to skip planes for many of the bands 19:22.30 Robin_Watts: like the ones with black text to the left or right of the image will be helped by 0 skipping 19:23.03 ray_laptop: I've just added skipping to the non averaging case. 19:23.27 Robin_Watts: Oh, OK. 19:23.54 but your timing doesn't include that yet, does it ? 19:25.36 Chans: (ghostbot) in:#ghostscript 19:25.49 240 ppm on the J6 is pretty impressive (up from 193) 19:31.07 no, not yet. 19:34.24 Seen: Flushed 3 entries. 19:36.36 --- Saved uptime records. 19:36.49 ray_laptop: Hmm. Testing for all the bits of an SSE reg being zero is not trivial :( 19:36.50 >>> join/#ghostscript mvrhel_laptop (~chatzilla@c-50-159-85-185.hsd1.wa.comcast.net) 19:37.32 mvrhel_laptop, ray_laptop: Do either of you guys know any SSE tricks for quickly testing that all the bits in an SSE register are 0 ? 19:37.48 I have an SSE register full of zeros if that helps. 19:41.30 Chans: (ghostbot) in:#ghostscript 19:42.12 FORK(14551) --- fork starting for 'RSSFeeds', PID == 14551, bot_pid == 5299 --- 19:42.13 FORK(14551) !ERROR! cannot load my module: RSSFeeds 19:42.13 FORK(14551) fork: took 1s for RSSFeeds. 19:42.13 FORK(14551) --- fork finished for 'RSSFeeds' --- 19:47.30 Hmm. With SSE4 we can do it, but not easily without that. 19:55.10 Your password format is invalid. Your Passwords must be at least 6 characters long and not start or end with a digit. 19:55.15 FUCKING RAGE 19:55.31 I'm about to smash this fucking computer, people don't fucking deserve computers 19:56.13 I'm going to write a virus that deletes every web site that defines more than 20% of the parameters in px or has a retarded password policy 19:56.31 oh hah I'm sorry wrong channel! 19:56.39 /rant 19:57.08 Gigs-: I feel your pain :) 19:57.21 heh, sorry I usually reserve such rants for other channel 19:58.21 Chans: (ghostbot) in:#ghostscript 20:00.26 I hope no one writes that virus now that I'm publicly logged saying that heh 20:01.45 Robin_Watts: iirc, there is a 'find first one' kind of thing 20:02.52 >>> Micha` has signed off IRC (Ping timeout: 249 seconds) [#ghostscript] 20:05.05 ray_laptop: a CLZ operation... 20:06.58 I can't find it :( 20:12.40 FORK(29789) --- fork starting for 'RSSFeeds', PID == 29789, bot_pid == 5299 --- 20:12.41 FORK(29789) !ERROR! cannot load my module: RSSFeeds 20:12.41 FORK(29789) fork: took 1s for RSSFeeds. 20:12.41 FORK(29789) --- fork finished for 'RSSFeeds' --- 20:14.30 Chans: (ghostbot) in:#ghostscript 20:16.58 Robin_Watts: but if you have a register that is 0's you can pcmpeqd - Compares 4 32bit integers. 20:18.24 >>> marcosw has signed off IRC (Quit: marcosw) [#ghostscript] 20:18.30 as an intrinsic, that is: _mm_cmpeq_epi32 20:18.44 ray_laptop: And that puts the answer in an mm register. 20:19.03 It doesn't let me: if (_mm_cmpeq_epi32(...)) goto skip; 20:25.19 Oh, joy. 20:25.39 My CPU doesn't support SSE4, hence my carefully written code fails :( 20:27.54 Robin_Watts: what did you do that used SSE4 -- I'd only seen SSE3 in the previous ? 20:28.28 ray: _mm_testc128 20:28.42 ray: _mm_testc_si128 20:29.33 >>> plinnell has signed off IRC (Ping timeout: 252 seconds) [#ghostscript] 20:29.35 Robin_Watts: strange, but the SSE (2,3, 4) that I'm using doesn't mention that :-/ 20:30.16 Chans: (ghostbot) in:#ghostscript 20:32.00 It's equivalent to the ptest instruction. 20:33.42 Robin_Watts: thainks. I found them at: http://software.intel.com/sites/products/documentation/studio/composer/en-us/2011Update/compiler_c/intref_cls/common/intref_sse41_test.htm 20:34.50 Seen: Flushed 3 entries. 20:34.50 testz checks for all 0' testc checks for all ones and testnzc checks for at least one 0 and at least one 1. 20:35.34 But, I see that these are SSE4 as you mention :-( 20:35.59 not quite. 20:36.15 one is (a & b) == 0 20:37.01 one is (a & b) == b 20:37.01 --- Saved uptime records. 20:37.10 and one is wackier :) 20:38.27 yeah, the intel guide for testznc says: ( ( (s1 & s2) != 0 && (~s1 & s2) != 0 ) ? 1 : 0 ) 20:39.45 which we don't need unless we are going to treat all 1's as an optimized case as well 20:40.02 so I can't see anyway to do this "empty" check without SSE4 that will be any faster than just loading the values into normal x86 registers and checking there. 20:42.14 Robin_Watts: well loading something into SSE registers that has already been loaded will at least still be in L1 cache, so will load fast 20:42.59 and you can have the SSE4 instruction with conditional compile 20:43.09 FORK(13022) --- fork starting for 'RSSFeeds', PID == 13022, bot_pid == 5299 --- 20:43.10 FORK(13022) !ERROR! cannot load my module: RSSFeeds 20:43.10 FORK(13022) fork: took 1s for RSSFeeds. 20:43.10 FORK(13022) --- fork finished for 'RSSFeeds' --- 20:43.25 I have to run a couple of errands. bbiaw 20:43.28 yeah. 20:46.00 Chans: (ghostbot) in:#ghostscript 20:52.06 >>> ray_laptop has signed off IRC (Ping timeout: 245 seconds) [#ghostscript] 20:54.37 The zero test costs more that it saves doing it without SSE. 21:00.03 >>> join/#ghostscript Fandekasp (~Fandekasp@27-32-19-26.static.tpgi.com.au) 21:02.14 Chans: (ghostbot) in:#ghostscript 21:05.14 >>> join/#ghostscript ray_laptop (~chatzilla@cpe-76-171-54-81.socal.res.rr.com) 21:05.40 The zero test costs more that it saves doing it without SSE. 21:08.12 mvrhel_laptop: You here? 21:08.23 I've got scott asking me what version of XPS we are shipping. 21:13.24 FORK(26124) --- fork starting for 'RSSFeeds', PID == 26124, bot_pid == 5299 --- 21:13.25 FORK(26124) !ERROR! cannot load my module: RSSFeeds 21:13.25 FORK(26124) fork: took 1s for RSSFeeds. 21:13.25 FORK(26124) --- fork finished for 'RSSFeeds' --- 21:14.04 >>> join/#ghostscript marcosw (~marcosw@c-98-207-131-178.hsd1.ca.comcast.net) 21:17.48 Chans: (ghostbot) in:#ghostscript 21:27.51 my internet is now about 2x faster than the wireless I have. 21:33.52 Chans: (ghostbot) in:#ghostscript 21:34.53 >>> join/#ghostscript Noldorin (~noldorin@unaffiliated/noldorin) 21:35.03 Seen: Flushed 3 entries. 21:37.06 --- Saved uptime records. 21:43.32 FORK(16570) --- fork starting for 'RSSFeeds', PID == 16570, bot_pid == 5299 --- 21:43.33 FORK(16570) !ERROR! cannot load my module: RSSFeeds 21:43.33 FORK(16570) fork: took 1s for RSSFeeds. 21:43.33 FORK(16570) --- fork finished for 'RSSFeeds' --- 21:45.51 >>> ray_laptop has signed off IRC (Ping timeout: 245 seconds) [#ghostscript] 21:49.47 Robin_Watts: in mu when you have your pdf_obj how do you know which type converter to use? 21:50.07 Chans: (ghostbot) in:#ghostscript 21:50.45 like if I'm going over an array pulling elements, how can I detect the type without trying every type conversion to see which one works 21:57.43 >>> join/#ghostscript sojic (~sojic@92.55.124.139) 22:00.30 >>> join/#ghostscript sojic_ (~sojic@31.11.87.135) 22:03.56 >>> sojic has signed off IRC (Ping timeout: 246 seconds) [#ghostscript] 22:06.12 Chans: (ghostbot) in:#ghostscript 22:11.28 >>> join/#ghostscript ray_laptop (~chatzilla@rrcs-76-79-131-2.west.biz.rr.com) 22:13.32 >>> join/#ghostscript sojic (~sojic@92.55.124.139) 22:13.52 FORK(29674) --- fork starting for 'RSSFeeds', PID == 29674, bot_pid == 5299 --- 22:13.53 FORK(29674) !ERROR! cannot load my module: RSSFeeds 22:13.53 FORK(29674) fork: took 1s for RSSFeeds. 22:13.53 FORK(29674) --- fork finished for 'RSSFeeds' --- 22:16.28 >>> sojic_ has signed off IRC (Ping timeout: 240 seconds) [#ghostscript] 22:22.28 Chans: (ghostbot) in:#ghostscript 22:27.29 >>> Noldorin has signed off IRC (Quit: Computer has gone to sleep.) [#ghostscript] 22:33.01 Robin_Watts: I saw your comment that testing takes longer than the unconditional execution. 22:35.08 Seen: Flushed 2 entries. 22:37.30 --- Saved uptime records. 22:38.12 Chans: (ghostbot) in:#ghostscript 22:44.48 FORK(22509) --- fork starting for 'RSSFeeds', PID == 22509, bot_pid == 5299 --- 22:44.49 FORK(22509) !ERROR! cannot load my module: RSSFeeds 22:44.49 FORK(22509) fork: took 1s for RSSFeeds. 22:44.49 FORK(22509) --- fork finished for 'RSSFeeds' --- 22:59.28 >>> henrys has signed off IRC (Ping timeout: 240 seconds) [#ghostscript] 23:01.04 >>> join/#ghostscript henrys (~henrys@76.25.94.13) 23:02.38 >>> marcosw has signed off IRC (Quit: marcosw) [#ghostscript] 23:06.28 !WARN! PERL: readdir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 862. 23:06.28 !WARN! PERL: closedir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 869. 23:10.29 >>> sojic has signed off IRC (Remote host closed the connection) [#ghostscript] 23:10.29 Chans: (ghostbot) in:#ghostscript 23:11.05 >>> join/#ghostscript sojic (~sojic@92.55.124.139) 23:15.12 >>> join/#ghostscript sojic_ (~sojic@92.55.124.139) 23:15.13 FORK(1632) --- fork starting for 'RSSFeeds', PID == 1632, bot_pid == 5299 --- 23:15.14 FORK(1632) !ERROR! cannot load my module: RSSFeeds 23:15.14 FORK(1632) fork: took 2s for RSSFeeds. 23:15.14 FORK(1632) --- fork finished for 'RSSFeeds' --- 23:15.47 >>> sojic has signed off IRC (Ping timeout: 272 seconds) [#ghostscript] 23:16.20 >>> ray_laptop has signed off IRC (Ping timeout: 240 seconds) [#ghostscript] 23:22.28 >>> join/#ghostscript Noldorin (~noldorin@unaffiliated/noldorin) 23:24.51 >>> join/#ghostscript henrys_ (~henrys@c-76-25-94-13.hsd1.co.comcast.net) 23:24.55 >>> henrys has signed off IRC (Ping timeout: 260 seconds) [#ghostscript] 23:24.56 >>> henrys_ materializes into henrys 23:26.46 Chans: (ghostbot) in:#ghostscript 23:30.13 >>> sojic_ materializes into sojic 23:37.16 ircCheck: possible lost in space; checking.Tue Nov 5 23:37:16 2013 23:37.16 >ghostbot< TEST 23:37.16 IRCTEST: Yes, we're alive. 23:37.36 --- Saved uptime records. 23:41.52 >>> sojic has signed off IRC (Remote host closed the connection) [#ghostscript] 23:42.26 >>> join/#ghostscript sojic (~sojic@92.55.124.139) 23:42.56 Chans: (ghostbot) in:#ghostscript 23:45.22 FORK(7941) --- fork starting for 'RSSFeeds', PID == 7941, bot_pid == 5299 --- 23:45.23 FORK(7941) !ERROR! cannot load my module: RSSFeeds 23:45.23 FORK(7941) fork: took 1s for RSSFeeds. 23:45.23 FORK(7941) --- fork finished for 'RSSFeeds' --- 23:47.11 >>> sojic has signed off IRC (Ping timeout: 272 seconds) [#ghostscript] 23:59.56 Chans: (ghostbot) in:#ghostscript