00:11.08 Opened logfile log/20130826. 00:11.08 ircCheck: possible lost in space; checking.Mon Aug 26 00:11:08 2013 00:11.08 >ghostbot< TEST 00:11.08 IRCTEST: Yes, we're alive. 00:12.28 FORK(7485) --- fork starting for 'RSSFeeds', PID == 7485, bot_pid == 1061 --- 00:12.29 FORK(7485) !ERROR! cannot load my module: RSSFeeds 00:12.29 FORK(7485) fork: took 1s for RSSFeeds. 00:12.29 FORK(7485) --- fork finished for 'RSSFeeds' --- 00:19.08 --- Saved uptime records. 00:21.43 Chans: (ghostbot) in:#ghostscript 00:42.33 FORK(25922) LOG: last message repeated 3 times 00:42.33 FORK(25922) --- fork starting for 'RSSFeeds', PID == 25922, bot_pid == 1061 --- 00:42.34 FORK(25922) !ERROR! cannot load my module: RSSFeeds 00:42.34 FORK(25922) fork: took 1s for RSSFeeds. 00:42.34 FORK(25922) --- fork finished for 'RSSFeeds' --- 01:12.38 FORK(14334) LOG: last message repeated 5 times 01:12.38 FORK(14334) --- fork starting for 'RSSFeeds', PID == 14334, bot_pid == 1061 --- 01:12.39 FORK(14334) !ERROR! cannot load my module: RSSFeeds 01:12.39 FORK(14334) fork: took 1s for RSSFeeds. 01:12.39 FORK(14334) --- fork finished for 'RSSFeeds' --- 01:15.13 LOG: last message repeated 5 times 01:15.13 ircCheck: possible lost in space; checking.Mon Aug 26 01:15:13 2013 01:15.13 >ghostbot< TEST 01:15.13 IRCTEST: Yes, we're alive. 01:19.28 --- Saved uptime records. 01:25.33 Chans: (ghostbot) in:#ghostscript 01:42.48 FORK(7913) --- fork starting for 'RSSFeeds', PID == 7913, bot_pid == 1061 --- 01:42.49 FORK(7913) !ERROR! cannot load my module: RSSFeeds 01:42.49 FORK(7913) fork: took 1s for RSSFeeds. 01:42.49 FORK(7913) --- fork finished for 'RSSFeeds' --- 01:48.08 !WARN! PERL: readdir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 862. 01:48.08 !WARN! PERL: closedir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 869. 01:55.26 >>> marcosw has signed off IRC (Quit: marcosw) [#ghostscript] 01:57.33 Chans: (ghostbot) in:#ghostscript 02:12.58 FORK(3704) --- fork starting for 'RSSFeeds', PID == 3704, bot_pid == 1061 --- 02:12.59 FORK(3704) !ERROR! cannot load my module: RSSFeeds 02:12.59 FORK(3704) fork: took 1s for RSSFeeds. 02:12.59 FORK(3704) --- fork finished for 'RSSFeeds' --- 02:19.03 ircCheck: possible lost in space; checking.Mon Aug 26 02:19:03 2013 02:19.03 >ghostbot< TEST 02:19.03 IRCTEST: Yes, we're alive. 02:19.43 --- Saved uptime records. 02:21.58 >>> join/#ghostscript tkamppeter__ (~till@p5480A8CE.dip0.t-ipconnect.de) 02:25.43 >>> tkamppeter_ has signed off IRC (Ping timeout: 260 seconds) [#ghostscript] 02:29.38 Chans: (ghostbot) in:#ghostscript 02:43.03 FORK(32663) --- fork starting for 'RSSFeeds', PID == 32663, bot_pid == 1061 --- 02:43.04 FORK(32663) !ERROR! cannot load my module: RSSFeeds 02:43.04 FORK(32663) fork: took 1s for RSSFeeds. 02:43.04 FORK(32663) --- fork finished for 'RSSFeeds' --- 03:13.13 FORK(29072) LOG: last message repeated 4 times 03:13.13 FORK(29072) --- fork starting for 'RSSFeeds', PID == 29072, bot_pid == 1061 --- 03:13.14 LOG: last message repeated 4 times 03:13.14 >>> join/#ghostscript marcosw (~marcosw@67.169.6.130) 03:13.14 FORK(29072) !ERROR! cannot load my module: RSSFeeds 03:13.14 FORK(29072) fork: took 1s for RSSFeeds. 03:13.14 FORK(29072) --- fork finished for 'RSSFeeds' --- 03:18.38 Chans: (ghostbot) in:#ghostscript 03:19.53 --- Saved uptime records. 03:24.13 ircCheck: possible lost in space; checking.Mon Aug 26 03:24:13 2013 03:24.13 >ghostbot< TEST 03:24.13 IRCTEST: Yes, we're alive. 03:35.03 Chans: (ghostbot) in:#ghostscript 03:43.23 FORK(30759) --- fork starting for 'RSSFeeds', PID == 30759, bot_pid == 1061 --- 03:43.24 FORK(30759) !ERROR! cannot load my module: RSSFeeds 03:43.24 FORK(30759) fork: took 1s for RSSFeeds. 03:43.24 FORK(30759) --- fork finished for 'RSSFeeds' --- 03:47.59 >>> Noldorin has signed off IRC (Quit: Computer has gone to sleep.) [#ghostscript] 03:51.18 Chans: (ghostbot) in:#ghostscript 04:13.43 FORK(24544) --- fork starting for 'RSSFeeds', PID == 24544, bot_pid == 1061 --- 04:13.44 FORK(24544) !ERROR! cannot load my module: RSSFeeds 04:13.44 FORK(24544) fork: took 1s for RSSFeeds. 04:13.44 FORK(24544) --- fork finished for 'RSSFeeds' --- 04:19.58 --- Saved uptime records. 04:22.58 Chans: (ghostbot) in:#ghostscript 04:28.08 ircCheck: possible lost in space; checking.Mon Aug 26 04:28:08 2013 04:28.08 >ghostbot< TEST 04:28.08 IRCTEST: Yes, we're alive. 04:38.18 Chans: (ghostbot) in:#ghostscript 04:44.03 FORK(8711) --- fork starting for 'RSSFeeds', PID == 8711, bot_pid == 1061 --- 04:44.04 FORK(8711) !ERROR! cannot load my module: RSSFeeds 04:44.04 FORK(8711) fork: took 1s for RSSFeeds. 04:44.04 FORK(8711) --- fork finished for 'RSSFeeds' --- 04:45.04 >>> marcosw has signed off IRC (Quit: marcosw) [#ghostscript] 04:55.08 Chans: (ghostbot) in:#ghostscript 04:56.24 >>> join/#ghostscript marcosw (~marcosw@67.169.6.130) 05:10.48 Chans: (ghostbot) in:#ghostscript 05:14.38 FORK(3178) --- fork starting for 'RSSFeeds', PID == 3178, bot_pid == 1061 --- 05:14.39 FORK(3178) !ERROR! cannot load my module: RSSFeeds 05:14.39 FORK(3178) fork: took 1s for RSSFeeds. 05:14.39 FORK(3178) --- fork finished for 'RSSFeeds' --- 05:20.18 --- Saved uptime records. 05:21.31 >>> join/#ghostscript malc__ (~malc@213.33.220.118) 05:25.42 >>> join/#ghostscript pipitas (~pipitas@88.128.80.10) 05:27.08 Chans: (ghostbot) in:#ghostscript 05:32.18 ircCheck: possible lost in space; checking.Mon Aug 26 05:32:18 2013 05:32.18 >ghostbot< TEST 05:32.18 IRCTEST: Yes, we're alive. 05:42.38 Chans: (ghostbot) in:#ghostscript 05:44.53 FORK(14983) --- fork starting for 'RSSFeeds', PID == 14983, bot_pid == 1061 --- 05:44.54 FORK(14983) !ERROR! cannot load my module: RSSFeeds 05:44.54 FORK(14983) fork: took 1s for RSSFeeds. 05:44.54 FORK(14983) --- fork finished for 'RSSFeeds' --- 05:48.43 !WARN! PERL: readdir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 862. 05:48.43 !WARN! PERL: closedir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 869. 05:58.28 Chans: (ghostbot) in:#ghostscript 06:03.26 >>> marcosw has signed off IRC (Ping timeout: 240 seconds) [#ghostscript] 06:03.38 >>> join/#ghostscript marcosw (~marcosw@67.169.6.130) 06:14.13 Chans: (ghostbot) in:#ghostscript 06:15.38 FORK(10612) --- fork starting for 'RSSFeeds', PID == 10612, bot_pid == 1061 --- 06:15.39 FORK(10612) !ERROR! cannot load my module: RSSFeeds 06:15.39 FORK(10612) fork: took 1s for RSSFeeds. 06:15.39 FORK(10612) --- fork finished for 'RSSFeeds' --- 06:20.33 --- Saved uptime records. 06:20.48 >>> chrisl_away materializes into chrisl 06:29.33 Chans: (ghostbot) in:#ghostscript 06:34.53 ircCheck: possible lost in space; checking.Mon Aug 26 06:34:53 2013 06:34.53 >ghostbot< TEST 06:34.53 IRCTEST: Yes, we're alive. 06:41.13 >>> pipitas has signed off IRC (Quit: Leaving.) [#ghostscript] 06:44.11 >>> join/#ghostscript Jayson (dbe0a983@gateway/web/freenode/ip.219.224.169.131) 06:45.21 Chans: (ghostbot) in:#ghostscript 06:46.03 FORK(14562) --- fork starting for 'RSSFeeds', PID == 14562, bot_pid == 1061 --- 06:46.04 FORK(14562) !ERROR! cannot load my module: RSSFeeds 06:46.04 FORK(14562) fork: took 1s for RSSFeeds. 06:46.04 FORK(14562) --- fork finished for 'RSSFeeds' --- 06:48.39 >>> join/#ghostscript kens (~Miranda@222.141.90.146.dyn.plus.net) 06:51.37 chrisl ping 06:56.25 kens: pong 06:56.58 chrisl what do you think about another release ? I was going to suggest asking at the Tuesday meeting, but IIRC henry said we wouldn't have one this week 06:57.21 Yeh, Henry is away until Wed IIRC..... 06:58.20 My inclination is that it sounds like we do need another release, and we should start afresh, rather than build another on 9.08/9.09..... 06:59.04 I think so too. I would like to do a little more testing/investigation today, I realised I didn't check for initialisationfiles executing gstate, other than gs_dps.ps and I need to 06:59.56 Okay, so when you're ready, let me know, and I'll create a release branch, and ping a mail off to Marcos to start testing. 07:00.29 Right, hopefully it will be today, if I find any more problems I'm inclined to simply revert all the changes and go back to hte old behaviour 07:00.49 Chans: (ghostbot) in:#ghostscript 07:00.58 I'll get started now. 07:01.08 That sounds fair, at least for this release. 07:01.56 BTW, I'll be in and out a bit today - just in case I forget to meddle with my nick.... 07:02.24 Not a problem. By the way, the PLRM says that you should avoid allocating gstate objects in global VM :-( 07:02.30 >>> Jayson has signed off IRC (Quit: Page closed) [#ghostscript] 07:03.10 TaDa. do 'true setglobal gstate' and you get a VM error. 07:03.22 sorry invalidaccess 07:04.01 I'm doubtful if we can fix this. 07:04.33 Though I suppose technically we don't have to, the PLRM says this is expected behaviour 07:04.47 I just need to make sure it can't happen during startup 07:09.32 http://parall.ax/products/jspdf 07:10.59 maybe you should just feed gs through a c-to-js convertor (emscripten?) and be done with it... ;) 07:11.28 I bet GS would break a C to anything converter 07:13.09 sebras: I messed with gs and emscripten a while back - they didn't play nicely together..... 07:16.48 FORK(22943) --- fork starting for 'RSSFeeds', PID == 22943, bot_pid == 1061 --- 07:16.49 FORK(22943) !ERROR! cannot load my module: RSSFeeds 07:16.49 FORK(22943) fork: took 1s for RSSFeeds. 07:16.49 FORK(22943) --- fork finished for 'RSSFeeds' --- 07:17.08 Chans: (ghostbot) in:#ghostscript 07:20.13 Seen: Flushed 3 entries. 07:20.43 --- Saved uptime records. 07:33.38 Chans: (ghostbot) in:#ghostscript 07:45.12 >>> marcosw has signed off IRC (Quit: marcosw) [#ghostscript] 07:45.34 >>> join/#ghostscript marcosw (~marcosw@67.169.6.130) 07:46.48 FORK(29801) --- fork starting for 'RSSFeeds', PID == 29801, bot_pid == 1061 --- 07:46.49 FORK(29801) !ERROR! cannot load my module: RSSFeeds 07:46.49 FORK(29801) fork: took 1s for RSSFeeds. 07:46.49 FORK(29801) --- fork finished for 'RSSFeeds' --- 07:49.43 Chans: (ghostbot) in:#ghostscript 08:06.20 chrisl I've finished checking gstate; we always did raise an invalidaccess error when executing gstate in a global VM context, its not my change that caused that. Which means I only have to worry about executing gstate in the startup code, and that seems to be OK now. 08:08.20 kens: that sounds wrong to me, but I suppose if it's not a regression, then..... 08:09.00 The PLRM is pretty specific that its a bad idea, because the gstate can contain stuff in local VM (current halftone, etc) and if it does then an invalidaccess is the correct error 08:09.40 Fair enough.... 08:14.37 >>> join/#ghostscript Jayson (dbe0a983@gateway/web/freenode/ip.219.224.169.131) 08:17.43 FORK(22708) --- fork starting for 'RSSFeeds', PID == 22708, bot_pid == 1061 --- 08:17.44 FORK(22708) !ERROR! cannot load my module: RSSFeeds 08:17.44 FORK(22708) fork: took 1s for RSSFeeds. 08:17.44 FORK(22708) --- fork finished for 'RSSFeeds' --- 08:20.18 Seen: Flushed 2 entries. 08:21.08 --- Saved uptime records. 08:21.23 Chans: (ghostbot) in:#ghostscript 08:23.15 >>> join/#ghostscript tor7 (~tor@h-94-176.a230.priv.bahnhof.se) 08:27.58 >>> Jayson has signed off IRC (Quit: Page closed) [#ghostscript] 08:36.58 Chans: (ghostbot) in:#ghostscript 08:43.51 >>> join/#ghostscript paulgardiner (~chatzilla@smtp.glidos.net) 08:47.53 FORK(23924) --- fork starting for 'RSSFeeds', PID == 23924, bot_pid == 1061 --- 08:47.54 FORK(23924) !ERROR! cannot load my module: RSSFeeds 08:47.54 FORK(23924) fork: took 1s for RSSFeeds. 08:47.54 FORK(23924) --- fork finished for 'RSSFeeds' --- 08:53.08 Chans: (ghostbot) in:#ghostscript 08:54.19 >>> Brando753 has signed off IRC (Quit: o_O_o) [#ghostscript] 08:54.50 >>> join/#ghostscript Brando753 (~Brando753@unaffiliated/brando753) 09:01.12 >>> join/#ghostscript sojic (~sojic@95.180.248.14) 09:05.25 >>> sojic has signed off IRC (Ping timeout: 245 seconds) [#ghostscript] 09:07.04 chrisl: kens: no, I didn't expect emscripten to be able to convert any major project. anything of that size tends to contain code that is specialized in a way that any automatically converting tool would mess up. 09:09.10 sebras: it didn't take a lot to get the conversion to complete (which impressed me a lot!), but I had neither the time nor the inclination to fathom why it didn't run 09:09.18 Chans: (ghostbot) in:#ghostscript 09:11.31 sebras, tor7, paulgardiner: Morning all. 09:11.50 Hi Robin_Watts 09:11.56 I got my RLEd glyph storage/plotting code working over the weekend. 09:12.35 The latest bmpcmp run shows the few diffs I get (all due to a slight change in the blending of edge pixels - just rounding). 09:13.06 I need to get the conversion from freetype bitmap -> RLE done directly rather than going via fz_pixmaps to save time. 09:13.23 but otherwise the code is up on robin/master for anyone interested in looking at it. 09:16.12 Nice. So big space savings. 09:16.41 Why does RLE affect edge pixels? 09:16.45 paulgardiner: I hope so. 09:17.18 The RLE I use categorises pixels into runs of transparent pixels, runs of solid pixels, and runs of "edge" pixels. 09:18.08 FORK(12308) --- fork starting for 'RSSFeeds', PID == 12308, bot_pid == 1061 --- 09:18.08 The way we do blending of edge pixels involves merging 2 alpha values together. 09:18.09 FORK(12308) !ERROR! cannot load my module: RSSFeeds 09:18.09 FORK(12308) fork: took 1s for RSSFeeds. 09:18.09 FORK(12308) --- fork finished for 'RSSFeeds' --- 09:18.44 and the rounding works out slightly differently in the new code than the old code. 09:19.37 Oh okay. Makes sense 09:20.00 I haven't measured for space savings yet. 09:20.20 Seen: Flushed 4 entries. 09:20.21 but I'd hope that it should be worthwhile. 09:20.29 I'm also hoping for speed improvements. 09:21.09 --- Saved uptime records. 09:24.53 Chans: (ghostbot) in:#ghostscript 09:33.15 kens: so are we ready for a new release branch? 09:33.28 chrisl I'm as ready as I'll ever be :-( 09:33.40 I can't think of anythign else to test 09:33.56 Okay, I'll get that rolling.... 09:34.16 GHot to start somewhere I guess. Maybe people will test the RC this time.... 09:34.39 Doubt it 09:34.56 Sadly I'm inclined to agree :-( 09:41.13 Chans: (ghostbot) in:#ghostscript 09:48.18 FORK(32717) --- fork starting for 'RSSFeeds', PID == 32717, bot_pid == 1061 --- 09:48.19 FORK(32717) !ERROR! cannot load my module: RSSFeeds 09:48.19 FORK(32717) fork: took 1s for RSSFeeds. 09:48.19 FORK(32717) --- fork finished for 'RSSFeeds' --- 09:48.48 !WARN! PERL: readdir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 862. 09:48.48 !WARN! PERL: closedir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 869. 09:57.23 Chans: (ghostbot) in:#ghostscript 10:10.17 >>> join/#ghostscript sojic (~sojic@95.180.248.14) 10:12.58 Chans: (ghostbot) in:#ghostscript 10:16.27 >>> sojic has signed off IRC (Remote host closed the connection) [#ghostscript] 10:18.43 FORK(23374) --- fork starting for 'RSSFeeds', PID == 23374, bot_pid == 1061 --- 10:18.44 FORK(23374) !ERROR! cannot load my module: RSSFeeds 10:18.44 FORK(23374) fork: took 1s for RSSFeeds. 10:18.44 FORK(23374) --- fork finished for 'RSSFeeds' --- 10:20.28 Seen: Flushed 3 entries. 10:21.40 >>> chrisl materializes into chrisl_away 10:21.50 --- Saved uptime records. 10:29.38 Chans: (ghostbot) in:#ghostscript 10:35.23 ircCheck: possible lost in space; checking.Mon Aug 26 10:35:23 2013 10:35.23 >ghostbot< TEST 10:35.23 IRCTEST: Yes, we're alive. 10:45.58 Chans: (ghostbot) in:#ghostscript 10:49.03 FORK(5900) --- fork starting for 'RSSFeeds', PID == 5900, bot_pid == 1061 --- 10:49.04 FORK(5900) !ERROR! cannot load my module: RSSFeeds 10:49.04 FORK(5900) fork: took 1s for RSSFeeds. 10:49.04 FORK(5900) --- fork finished for 'RSSFeeds' --- 11:19.18 FORK(2827) LOG: last message repeated 4 times 11:19.18 FORK(2827) --- fork starting for 'RSSFeeds', PID == 2827, bot_pid == 1061 --- 11:19.19 FORK(2827) !ERROR! cannot load my module: RSSFeeds 11:19.19 FORK(2827) fork: took 1s for RSSFeeds. 11:19.19 FORK(2827) --- fork finished for 'RSSFeeds' --- 11:22.03 LOG: last message repeated 4 times 11:22.03 --- Saved uptime records. 11:33.08 Chans: (ghostbot) in:#ghostscript 11:37.49 tor7: ping 11:48.48 Chans: (ghostbot) in:#ghostscript 11:49.28 FORK(12252) --- fork starting for 'RSSFeeds', PID == 12252, bot_pid == 1061 --- 11:49.29 FORK(12252) !ERROR! cannot load my module: RSSFeeds 11:49.29 FORK(12252) fork: took 1s for RSSFeeds. 11:49.29 FORK(12252) --- fork finished for 'RSSFeeds' --- 12:20.23 FORK(9941) --- fork starting for 'RSSFeeds', PID == 9941, bot_pid == 1061 --- 12:20.24 FORK(9941) !ERROR! cannot load my module: RSSFeeds 12:20.24 FORK(9941) fork: took 1s for RSSFeeds. 12:20.24 FORK(9941) --- fork finished for 'RSSFeeds' --- 12:21.43 Seen: Flushed 1 entries. 12:22.18 --- Saved uptime records. 12:36.08 Chans: (ghostbot) in:#ghostscript 12:38.33 >>> saper_ materializes into saper 12:40.05 >>> join/#ghostscript Hemza (~chatzilla@197.207.206.215) 12:41.11 Hello,, i have a question about zathura building in ubuntu 12.4 12:43.44 >>> chrisl_away materializes into chrisl 12:43.49 Hemza: http://pwmt.org/projects/zathura/ ? 12:47.52 zathura uses MuPDF ? 12:48.00 apparently it can. 12:48.09 Robin_Watts: Iwant to know how I could install Mupdf as a shared library ( with -fPIC as mentioned in Zarthura's site). I come throught this patch http://bugs.ghostscript.com/show_bug.cgi?id=693009, but i don not know how to apply 12:49.22 Hemza: I think I'm right in saying that we don't offer a shared lib build in the standard makefile. 12:50.13 You'd need to discuss it with tor7 (the keeper of the Makefile) to be sure. 12:50.33 FORK(30420) --- fork starting for 'RSSFeeds', PID == 30420, bot_pid == 1061 --- 12:50.34 FORK(30420) !ERROR! cannot load my module: RSSFeeds 12:50.34 FORK(30420) fork: took 1s for RSSFeeds. 12:50.34 FORK(30420) --- fork finished for 'RSSFeeds' --- 12:51.31 Robin_Watts: thabk you 12:52.01 Chans: (ghostbot) in:#ghostscript 12:52.30 tor7: how could ii build Mupdf from source as a shared lib? or it is not possible! 12:53.30 Today is a bank holiday in the UK. 12:53.44 tor7 is in sweden - not sure it's a holiday there. 12:53.55 if it is, he may not be around. 12:54.03 ok 12:54.19 i hope he could reply 12:54.35 He might - just be prepared to wait a bit. 13:00.10 Hemza: just build with "make build=release CC='gcc -fPIC'" voila 13:02.09 malc__: Surely make build=release XCFLAGS="-fPIC" ? 13:02.32 and then you'll have to pick which of the libs to link with etc. 13:05.07 >>> tkamppeter__ materializes into tkamppeter 13:07.48 Chans: (ghostbot) in:#ghostscript 13:07.56 Robin_Watts: eh? CFLAGS works just as fine, and no, you don't need to care about libs 13:11.08 Robin_Watts & malc__ : thank you i will try it. 13:12.08 correction, CC works just as fine, not CFLAGS 13:13.22 Robin_Watts: when you have some spare time, have a look at my updated commit messages and the patch inspired by malc__'s problem. 13:14.42 Robin_Watts: I'm not sure if I'm harassing you too much, but I hope you take this as a gentle reminder. 13:18.27 >>> join/#ghostscript Noldorin (~noldorin@unaffiliated/noldorin) 13:21.18 FORK(26751) --- fork starting for 'RSSFeeds', PID == 26751, bot_pid == 1061 --- 13:21.19 FORK(26751) !ERROR! cannot load my module: RSSFeeds 13:21.19 FORK(26751) fork: took 1s for RSSFeeds. 13:21.19 FORK(26751) --- fork finished for 'RSSFeeds' --- 13:21.53 >>> join/#ghostscript atulagrwl (75cf5a20@gateway/web/freenode/ip.117.207.90.32) 13:21.53 Seen: Flushed 5 entries. 13:22.25 paulgardiner: ping 13:22.35 --- Saved uptime records. 13:23.07 atulagrwl: hi 13:24.07 Chans: (ghostbot) in:#ghostscript 13:24.21 paulgardiner: Can you look at one pdf to see why annotation is not appearing in mupdf (and all other pdf readers)? 13:25.56 Sure. It would be good to open a bug and attach it. 13:26.39 if you say it is a problem, I will log a bug. I just want to confirm it (quickly) 13:26.54 what is the best place to attach a pdf? 13:27.45 Anywhere on the web I can download it from. 13:27.49 Needless to say I do not known the copyright of the pdf :-) 13:28.54 Most likely, it has an annotation without an appearance stream. Other readers may be creating an appearance stream on the fly 13:29.40 paulgardiner: annotation is created using mupdf only and other readers can not show the annotation as well 13:30.17 Oh I see now 13:30.21 I am expecting some xref kind of issue again. (No idea just an hunch) 13:31.20 I'd certainly be interested to take a look. 13:35.39 paulgardiner: send the link of pdf to you in private chat 13:36.26 >>> malc__ has signed off IRC (Quit: leaving) [#ghostscript] 13:38.02 I tried to create simple test case but it worked. I suspect something wrong in the pdf. 13:40.43 Chans: (ghostbot) in:#ghostscript 13:44.08 paulgardiner: Got the link? 13:44.33 Yes 13:46.20 The incremental update in the file includes the new annotation, but not an updated page dict that refers to it (or an updated annotations array for the page). 13:46.28 How did you create this? 13:47.11 opened the file in mupdf (android) and added annotation and saved the file. 13:47.44 Oh okay. Worth opening a bug then. 13:49.04 !WARN! PERL: readdir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 862. 13:49.04 !WARN! PERL: closedir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 869. 13:49.36 paulgardiner: okay 13:50.20 Thanks 13:50.57 paulgardiner: Can I avoid attaching sample file to bug note as I don't want this file in public? 13:51.33 FORK(27781) --- fork starting for 'RSSFeeds', PID == 27781, bot_pid == 1061 --- 13:51.34 FORK(27781) !ERROR! cannot load my module: RSSFeeds 13:51.34 FORK(27781) fork: took 1s for RSSFeeds. 13:51.34 FORK(27781) --- fork finished for 'RSSFeeds' --- 13:53.14 atulagrwl: We can mark attachments as private. 13:53.19 atulagrwl: sure. Just give me a link to the original file without the added annotation. Also instructions as to exactly what to hightlight on which page might be useful in case the problem is specific to those details 13:53.25 hence only people in the company can see them. 13:53.53 sebras: Will do. 13:54.15 sebras: No problem about hassling me - my crap memory has been well documented. 13:54.17 Robin_Watts: ok, let me know if there are more messages I ought to have updated. 13:54.18 Robin_Watts: How does that work? Should atulagrwl attach the file and then one of us immediately mark it private? 13:54.41 paulgardiner: Either that, or he mails it to us and we can attach it and mark it private at the same time. 13:54.55 Right 13:55.22 I tried adding annotation on second page and see the problem. Have not tried doing that anywhere else yet. Adding ink annotation on first page also creates problem. 13:55.43 * atulagrwl/#ghostscript goes for dinner. Will be back in 10 mins 13:56.13 Chans: (ghostbot) in:#ghostscript 13:58.06 sebras: All look good to me. Will push them now. 14:01.36 Robin_Watts: excellent. 14:01.47 Robin_Watts: you did notice the new patch as well..? 14:01.56 the link dest one? 14:02.02 mm. 14:02.40 yeah, that's fine. Pushed that one too. 14:03.15 sebras, paulgardiner: Could one of you nod at "Fix memory leak in new glyph cache code" please? 14:03.34 http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=ba0afefc58ca583142463bd012bdd4b1b447582e 14:09.52 * sebras/#ghostscript reads the patch. 14:10.59 Hemza: Robin_Watts is right in that we don't support building mupdf as a shared library 14:11.01 Robin_Watts: looks sensible enough to me 14:11.23 paulgardiner, sebras: Thanks. 14:11.35 Robin_Watts: I'm not sure that your patch fixes all probolems though. 14:11.50 Robin_Watts: do you fz_keep_font() the font correctly when you insert it? 14:11.53 sebras: What do you think it gets wrong? 14:12.01 sebras: Yes, i believe so. 14:12.08 Memento gives it a clean bill of health. 14:12.20 Robin_Watts: pong. sorry, was taking a nap when you pinged me earlier. 14:12.20 Chans: (ghostbot) in:#ghostscript 14:12.24 (In fact, I only noticed the problem when memento showed leaks) 14:12.28 tor7: no worries. 14:12.35 Robin_Watts: ok, I haven't mamanged to check the code manually, but I'm worried that you might drop the font more than it is kept... 14:12.56 tor7: I was wanting to consult over the optimisation of my RLE glyph code. 14:13.03 >>> atulagrwl has signed off IRC (Ping timeout: 250 seconds) [#ghostscript] 14:13.17 Robin_Watts: okay. I looked over the first version of your commit this morning. 14:13.30 sebras: I don't believe I do - that would cause errors that the cluster would pick up, I think. 14:13.57 The cluster won't pick up leaks, but it will probably pick up stuff being dropped too often (and hence freeing too early) 14:14.06 and I was wondering why you had a fz_pixmap pointer in the fz_glyph 14:14.27 tor7: The RLE glyph stuff only works for black and white glyphs. 14:14.45 For colored glyphs (like type3's can be), we need to use the old pixmap code. 14:15.02 right. for the opengl device we also need to use the old pixmap code. 14:15.36 is there a way to know before calling render_glyph whether it will return a colored or b&w glyph? 14:15.49 tor7: not easily. 14:16.02 because I'm guessing you'll want to use the RLE for b&w type3 fonts as well 14:16.11 tor7: indeed, I do. 14:17.09 the ability to do colored type3 fonts is currently independent of the decision that they are cacheable 14:17.29 we have the "is-cachable" test in the type3 font code that the interpreter makes use of 14:17.31 Robin_Watts: ok, so the font is kept e.g. in fz_new_text() which is then transferred to fz_render_glyph() where it is inserted in the key but not kept. 14:17.41 one way out would be to make all colored glyphs non-cachable :) 14:17.51 considering how rare they are... 14:18.07 In fz_render_glyph, we either call fz_render_ft_glyph or fz_render_t3_glyph. 14:18.10 Robin_Watts: I'm not sure the latter is ok, and that ought to means that you can free the font from under the feet of the text-object, no..? 14:18.30 fz_render_ft_glyph always goes to a glyph. 14:18.58 Robin_Watts: sure, but before you call fz_render_ft_glyph you create the key. 14:19.06 Robin_Watts: which is meant to hold a reference to the font. 14:19.10 fz_render_t3_glyph always draws to a pixmap, and we go from that to a glyph, which may be RLEd or a pixmap. 14:19.12 Robin_Watts: which is what you attempt to freee. 14:19.19 sebras: Sorry, 2 conversations at once here. 14:19.29 Robin_Watts: oh. in the same area too. sorry about that. :) 14:20.04 sebras: The font always goes into the key. 14:20.19 and the font is then "kept" if we choose to insert the key. 14:20.49 If the key is just used for lookup, then we don't keep it (as the fz_text and hence the font) is guaranteed to be valid for the length of the life of the key. 14:21.09 This code is essentially unchanged from before my glyph cache rewrite. 14:21.36 Robin_Watts: ah, I didn't see that fz_keep_font(). ok. then I'm all ok with you patch. :) 14:21.36 it was just the cache entry dropping that I rewrote, and cocked up. 14:21.44 sebras: Thanks for the sanity check. 14:21.54 FORK(2729) --- fork starting for 'RSSFeeds', PID == 2729, bot_pid == 1061 --- 14:21.55 FORK(2729) !ERROR! cannot load my module: RSSFeeds 14:21.55 FORK(2729) fork: took 1s for RSSFeeds. 14:21.55 FORK(2729) --- fork finished for 'RSSFeeds' --- 14:22.04 Seen: Flushed 5 entries. 14:22.48 --- Saved uptime records. 14:22.50 tor7: Regardless of whether we cache or not, we need to cope with both colored and uncolored glyphs. 14:23.21 so it doesn't seem unreasonable to have an fz_glyph have different mechanisms internally for coping with colored/uncolored. 14:23.46 Hence in my patch we either have RLE for uncolored, or we drop back to using the existing pixmap code for colored. 14:24.53 tor7: You can close bug 694533 if you want now, and reduce your customer bugs to 0 :) 14:25.39 Robin_Watts: ah, thanks for that reminder. 14:26.36 tor7: In my latest patch, I moved all the RLE plotting code into fz_paint. 14:26.38 Robin_Watts: if colored type3 glyphs can use the fallback mechanism we have for uncachable glyphs, they bypass the cache altogether. doing so would mean only needing to worry about b&w glyphs. 14:27.09 I'm also not sure that we don't already do that 14:27.18 I *could* make colored glyphs uncacheable, but what would we gain by that? 14:27.48 FZ_DEVFLAG_UNCACHEABLE, drawn directly by the interpreter 14:27.59 we'd gain a cleaner API for dealing with glyphs in the cache and everywhere else 14:28.18 Currently colored glyphs are only uncacheable if they don't specify the colors as part of the glyph stream. 14:28.51 According to the spec, all glyphs *should* specify the colors they use as part of the stream, but in practise this does not happen in all cases. 14:29.03 but handling colored glyphs as a special case isn't currently that troublesome. I'd have to investigate to find a test file to test that code though. 14:29.13 Chans: (ghostbot) in:#ghostscript 14:29.23 hence we can end up with glyphs that render differently according to the current colors. 14:29.37 I spot those cases and set the UNCACHEABLE flag. 14:30.14 but my patch copes with all this just fine, I believe. 14:30.36 The reason I pinged you was to talk about the fz_paint_glyph code. 14:30.58 I moved the glyph plotting code into fz_paint, along with all the other code that does this kind of stuff. 14:31.01 Robin_Watts: just don't forget that I still want to be able to get a fz_pixmap from fz_render_xxx_glyph (or a similar function) 14:31.23 tor7: For the opengl device, sure. 14:32.13 the opengl device should (once I start using shaders again) render to a bigger size and convert the representation to a signed distance field 14:32.24 I suspect the best way to do that is to have 2 different functions we can call, one that returns a pixmap, one that returns a glyph. 14:32.43 okay, so fz_paint_glyph 14:33.19 and the actual guts of the two functions can largely be shared. In the ft case, we'd either make a pixmap or a glyph from the ft_bitmap as appropriate. 14:33.26 OK, fz_paint_glyph. 14:33.50 Robin_Watts: yes (re guts of two functions) 14:34.36 I had various different paths through the core fz_paint_glyph loop (are we using colorbv or not? if we are using it, was colorbv[n-1] == 255?) 14:34.59 >>> Hemza has signed off IRC (Ping timeout: 268 seconds) [#ghostscript] 14:35.12 and I had them all multiplexed into a single inline function that would hopefully expand itself out nicely. 14:35.47 You've done a similar thing elsewhere in the same file. 14:36.31 In the latest patch, I pulled them all out separately, cos 1) I think the code is more readable that way, and 2) it means I can then do the static inline expansion trick for N=2,4,any. 14:36.55 I just wanted to check you were happy with that. 14:36.57 yes, it looks nicer even though the RLE decoding logic is duplicated 14:37.18 Yeah, couldn't see a nice way to get the best of all worlds though. 14:37.37 fz_glyph_from_xxx should be named fz_new_glyph_from_xxx 14:38.16 ok. 14:38.52 all functions that return something that passes ownership needs one of the magic keywords in the name 14:39.04 I'll rename that, then do some tests to see how much memory we save (and see how the times compare). 14:39.05 (they're all listed in docs/naming.txt) 14:39.12 yeah, my bad. 14:39.23 I've missed the same instance a few times myself :) 14:40.25 I wonder about the _inline suffix though 14:40.44 have we used that naming before? 14:40.58 I'm always happy to get better naming suggestions. 14:41.20 _imp is our standard "this is the private 'implementation' function" suffix 14:41.27 but I'm happy to have a better convention than that 14:41.58 _imp would work for me. 14:42.35 fz_paint_glyph_inline to fz_paint_glyph_alpha and you can drop the _inline without naming ocllisions, I believe 14:44.48 Chans: (ghostbot) in:#ghostscript 14:47.37 yeah. nice one. 14:48.09 Did you look at any of my plotting optimisations? 14:51.58 FORK(24673) --- fork starting for 'RSSFeeds', PID == 24673, bot_pid == 1061 --- 14:51.59 FORK(24673) !ERROR! cannot load my module: RSSFeeds 14:51.59 FORK(24673) fork: took 1s for RSSFeeds. 14:51.59 FORK(24673) --- fork finished for 'RSSFeeds' --- 14:56.36 I've looked through the span painting optimisations 14:56.54 they look fine. 14:57.23 paint_affine caused my brain to melt just thinking about the problem domain :) 14:57.48 but having looked at it now, that one's fine too 14:57.57 how are the performance measurements of these optimisations? 14:58.27 tor7: they all gave noticable improvements on the raspberry pi. 14:59.15 I saw you added SWAR versions of a few 14:59.27 I did. 14:59.58 I wrote various versions of fz_paint_span_with_color and fz_paint_solid_color, including ARM code versions. 15:00.07 and then removed the #ifdef'd ones 15:00.16 Then in a later commit I removed all but the best version. yeah. 15:00.26 Chans: (ghostbot) in:#ghostscript 15:00.38 I was surprised that the ARM versions didn't outperform the C. 15:00.51 but if I ever want to try again I can pull them out of git. 15:00.54 compilers getting better, or hardware not behaving as it used to? 15:00.57 For now, better to keep the code clean. 15:01.02 tor7: probably a bit of both. 15:01.19 I'm sure hardware designers work hard to make C-generated code run fast :) 15:02.12 so, are you happy for me to push those? 15:08.14 yes, the first 4 are good to go 15:09.00 Thanks. 15:09.09 we should figure out the API to use for writing of images to outputs in both banded and non- 15:09.13 banded modes. 15:09.18 tor7: yeah. 15:09.35 it should be easy enough to make the primary image writing always use fz_output 15:09.49 and then take it from there. feel free to drop the png banded implementation in my lap. 15:16.23 Chans: (ghostbot) in:#ghostscript 15:22.08 Seen: Flushed 2 entries. 15:22.28 FORK(17988) --- fork starting for 'RSSFeeds', PID == 17988, bot_pid == 1061 --- 15:22.29 FORK(17988) !ERROR! cannot load my module: RSSFeeds 15:22.29 FORK(17988) fork: took 1s for RSSFeeds. 15:22.29 FORK(17988) --- fork finished for 'RSSFeeds' --- 15:22.58 --- Saved uptime records. 15:31.53 Chans: (ghostbot) in:#ghostscript 15:40.50 tor7: Something that occurred to me while debugging the RLE stuff... we should probably disable subpixel positioning for glyphs over a given size. 15:41.53 Robin_Watts: yeah. I'd ideally like for the number of subpixel positions we have to be a function of glyph size 15:42.11 so really small text has more subpixel variants, and at large enough sizes there'd be none 15:42.16 yeah, that'd be ideal. 15:42.46 I think it'd be possible with a few tweaks to how we generate the glyph cache key 15:44.37 So, running at 1200 dpi, the first 100 pages of PLRM cause 44712 evictions, totalling 300Meg of discarded data. 15:44.50 New RLE code: 13353 evictions, totalling 19.8Meg 15:45.34 max cache size for those tests? 15:45.56 That's with the standard 1Meg cache size 15:47.18 Chans: (ghostbot) in:#ghostscript 15:48.03 In total, to do the first 100 pages of pdf_reference17.pdf with no evictions, we need a cache size of 34.6Meg with the existing code. 15:50.25 >>> marcosw has signed off IRC (Quit: marcosw) [#ghostscript] 15:50.43 and 7.4Meg with the RLE stuff. 15:50.54 >>> join/#ghostscript marcosw (~marcosw@67.169.6.130) 15:52.33 FORK(21668) --- fork starting for 'RSSFeeds', PID == 21668, bot_pid == 1061 --- 15:52.34 FORK(21668) !ERROR! cannot load my module: RSSFeeds 15:52.34 FORK(21668) fork: took 1s for RSSFeeds. 15:52.34 FORK(21668) --- fork finished for 'RSSFeeds' --- 15:53.45 Hmm. At 72dpi, bitmaps win over RLEs in terms of space. 15:56.05 319K vs 590k cache size needed for first 100 pages 15:59.53 Chrisl interesting factoid. Acrobat cares about the maxPoints in a glyph, if we declare it incorrectly, it won't show glyphs which contain more points 16:00.07 Bug 694538 16:00.25 It doesn't seem to care about the number of contours though 16:02.06 A N Other rip of our acquaintance also appears to care, GS/FreeType don't 16:03.28 Chans: (ghostbot) in:#ghostscript 16:03.41 kens: Hrm, that's odd. I can remember why that other rip would care, but I'm surprised that Freetype doesn't, TBH 16:04.38 Its what seems to be causing the problem. We have two different subsets of a TT font which we combine into oe font. For reasona I haven't yet fathomed, we use the maxPoints fomr the first one. The problem is the first subset only contains 3 glyph, relatively simple.... 16:06.37 Oh, actually, maybe I do remember why Freetype will work - I think it ignores maxpoints and uses the numpoints from each individual glyph 16:06.48 :-) 16:07.09 I'm going to leave it until tomorrow now, I've been chasing this since this morning 16:08.31 I think that other rip you mention allocates a buffer for the points when the font is loaded (based on maxpoints), and (potentially) reuses the same buffer for all the glyphs. 16:09.15 Yes, I'm not objecting to the fact that it raises an error, just curious that FT doesn't 16:09.55 I'm a little surprised it doesn't at least warn 16:10.20 Makes sense, the font is supposed to be correct after all. Its pdfwrite making the error 16:11.37 Of course, it's possible Freetype does warn, and something about our integration means the warning gets swallowed 16:11.53 :-) 16:19.58 Chans: (ghostbot) in:#ghostscript 16:22.23 Seen: Flushed 4 entries. 16:23.03 FORK(19200) --- fork starting for 'RSSFeeds', PID == 19200, bot_pid == 1061 --- 16:23.04 FORK(19200) !ERROR! cannot load my module: RSSFeeds 16:23.04 FORK(19200) fork: took 1s for RSSFeeds. 16:23.04 FORK(19200) --- fork finished for 'RSSFeeds' --- 16:23.13 --- Saved uptime records. 16:34.05 >>> join/#ghostscript walterwego (~matt@71.90.116.38) 16:35.35 Chans: (ghostbot) in:#ghostscript 16:37.07 >>> part/#ghostscript walterwego (~matt@71.90.116.38) 16:37.26 tor7: ping 16:37.43 Speedwise it seems to be pretty much a wash between RLE or bitmap. 16:38.21 (there may be scope for me optimising the n=4 case a bit to use ints/SWAR etc, but...) 16:38.42 so I wonder if we should use bitmaps for small glyphs and RLE for large ones? 16:41.10 (comparing speeds was done with an infinite cache) 16:50.03 >>> chrisl materializes into chrisl__away 16:51.33 Chans: (ghostbot) in:#ghostscript 16:53.28 FORK(32428) --- fork starting for 'RSSFeeds', PID == 32428, bot_pid == 1061 --- 16:53.29 FORK(32428) !ERROR! cannot load my module: RSSFeeds 16:53.29 FORK(32428) fork: took 1s for RSSFeeds. 16:53.29 FORK(32428) --- fork finished for 'RSSFeeds' --- 17:10.26 LOG: last message repeated 3 times 17:10.26 >>> join/#ghostscript walterwego (~matt@71-90-116-38.dhcp.fdul.wi.charter.com) 17:11.48 >>> part/#ghostscript walterwego (~matt@71-90-116-38.dhcp.fdul.wi.charter.com) 17:16.51 >>> plinnell has signed off IRC (Read error: Operation timed out) [#ghostscript] 17:21.37 >>> join/#ghostscript sojic (~sojic@92.55.124.144) 17:22.38 Seen: Flushed 1 entries. 17:23.28 FORK(20824) --- fork starting for 'RSSFeeds', PID == 20824, bot_pid == 1061 --- 17:23.29 FORK(20824) !ERROR! cannot load my module: RSSFeeds 17:23.29 FORK(20824) fork: took 1s for RSSFeeds. 17:23.29 FORK(20824) --- fork finished for 'RSSFeeds' --- 17:23.38 --- Saved uptime records. 17:23.48 Chans: (ghostbot) in:#ghostscript 17:31.23 >>> sojic has signed off IRC (Remote host closed the connection) [#ghostscript] 17:39.18 Chans: (ghostbot) in:#ghostscript 17:39.25 >>> join/#ghostscript Sicos (541f1fe3@gateway/web/freenode/ip.84.31.31.227) 17:39.28 hi 17:39.28 somebody said hello 17:39.28 hi, sicos 17:39.54 does somebody overhere know if it is possible to find words in a pdf document with ghostscript? 17:40.07 What I want to do is detect special words and convert them to hyperlinks 17:42.07 Sicos: It is possible. You would have to use the text extraction device. 17:42.18 But I question whether gs is the best tool to do this with. 17:42.49 I think mupdf would be a better starting point. 17:43.24 well actually i want to use it on html files... at the moment I use wkHtmlToPDF for that. It makes clickable links and workds perfect. But it isn't updated since the last 3 years 17:43.56 I tried to rewrite wkhtmltopdf with QT but it seems that the author of wkhtmltopdf hacked the qt libraries to add hyperlink support 17:44.26 and I want to keep everything as standard as possible and concluded that it can't be done with QT 5.1 17:44.52 not without hacking QT 17:45.19 If your intent is to look for a process that starts with a pdf file and produces a modified pdf file, then mupdf is a better starting point than gs. 17:45.49 To use either gs or mupdf you would presumably have to have a stage that goes from html -> pdf first. 17:45.59 What you use for that stage is up to you. 17:46.29 although it would seem to be smartest to use a tool that doesn't throw away the hyperlink information present in the html if possible :) 17:46.42 I probably am going to make a hack for qt but I first need to find a lott of time for that 17:46.42 leak: 1 nuh{} items deleted; now have 30 17:47.07 There isn't going to be a 'quick' hack to do it with either gs or mupdf. 17:47.15 and my c++ is a little bit rusty 17:48.05 Sicos: Neither gs oe mupdf use C++. 17:49.45 !WARN! PERL: readdir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 862. 17:49.45 !WARN! PERL: closedir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 869. 17:53.14 >>> Sicos has signed off IRC (Quit: Page closed) [#ghostscript] 17:53.44 FORK(10329) --- fork starting for 'RSSFeeds', PID == 10329, bot_pid == 1061 --- 17:53.45 FORK(10329) !ERROR! cannot load my module: RSSFeeds 17:53.45 FORK(10329) fork: took 1s for RSSFeeds. 17:53.45 FORK(10329) --- fork finished for 'RSSFeeds' --- 17:55.18 Chans: (ghostbot) in:#ghostscript 18:22.53 Seen: Flushed 2 entries. 18:24.18 --- Saved uptime records. 18:24.18 FORK(3570) --- fork starting for 'RSSFeeds', PID == 3570, bot_pid == 1061 --- 18:24.19 FORK(3570) !ERROR! cannot load my module: RSSFeeds 18:24.19 FORK(3570) fork: took 1s for RSSFeeds. 18:24.19 FORK(3570) --- fork finished for 'RSSFeeds' --- 18:26.53 Chans: (ghostbot) in:#ghostscript 18:48.48 ircCheck: possible lost in space; checking.Mon Aug 26 18:48:48 2013 18:48.48 >ghostbot< TEST 18:48.48 IRCTEST: Yes, we're alive. 18:49.17 >>> kens has signed off IRC (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) [#ghostscript] 18:54.53 FORK(31706) --- fork starting for 'RSSFeeds', PID == 31706, bot_pid == 1061 --- 18:54.54 FORK(31706) !ERROR! cannot load my module: RSSFeeds 18:54.54 FORK(31706) fork: took 1s for RSSFeeds. 18:54.54 FORK(31706) --- fork finished for 'RSSFeeds' --- 18:59.48 Chans: (ghostbot) in:#ghostscript 19:24.28 LOG: last message repeated 3 times 19:24.28 --- Saved uptime records. 19:25.28 FORK(26694) --- fork starting for 'RSSFeeds', PID == 26694, bot_pid == 1061 --- 19:25.29 FORK(26694) !ERROR! cannot load my module: RSSFeeds 19:25.29 FORK(26694) fork: took 1s for RSSFeeds. 19:25.29 FORK(26694) --- fork finished for 'RSSFeeds' --- 19:31.03 Chans: (ghostbot) in:#ghostscript 19:48.26 Quick testing suggests that the RLE with 1Meg cache is a noticable win on J12 at 1200dpi, against non RLE with a 4 Meg cache. 19:53.56 >>> join/#ghostscript sojic (~sojic@92.55.124.144) 19:55.53 FORK(22773) --- fork starting for 'RSSFeeds', PID == 22773, bot_pid == 1061 --- 19:55.54 FORK(22773) !ERROR! cannot load my module: RSSFeeds 19:55.54 FORK(22773) fork: took 1s for RSSFeeds. 19:55.54 FORK(22773) --- fork finished for 'RSSFeeds' --- 19:57.58 >>> sojic has signed off IRC (Remote host closed the connection) [#ghostscript] 20:02.38 Chans: (ghostbot) in:#ghostscript 20:23.08 Seen: Flushed 1 entries. 20:24.38 --- Saved uptime records. 20:26.03 FORK(11432) --- fork starting for 'RSSFeeds', PID == 11432, bot_pid == 1061 --- 20:26.04 FORK(11432) !ERROR! cannot load my module: RSSFeeds 20:26.04 FORK(11432) fork: took 1s for RSSFeeds. 20:26.04 FORK(11432) --- fork finished for 'RSSFeeds' --- 20:34.03 Chans: (ghostbot) in:#ghostscript 20:48.47 >>> join/#ghostscript plinnell (~mrdocs@opensuse/member/mrdocs) 20:50.13 Chans: (ghostbot) in:#ghostscript 20:50.13 ircCheck: possible lost in space; checking.Mon Aug 26 20:50:13 2013 20:50.13 >ghostbot< TEST 20:50.13 IRCTEST: Yes, we're alive. 20:55.19 >>> join/#ghostscript pipitas (~pipitas@p5B30389D.dip0.t-ipconnect.de) 20:55.42 >>> join/#ghostscript sojic (~sojic@92.55.124.144) 20:56.32 FORK(5461) --- fork starting for 'RSSFeeds', PID == 5461, bot_pid == 1061 --- 20:56.33 FORK(5461) !ERROR! cannot load my module: RSSFeeds 20:56.33 FORK(5461) fork: took 1s for RSSFeeds. 20:56.33 FORK(5461) --- fork finished for 'RSSFeeds' --- 20:56.46 >>> pipitas has signed off IRC (Client Quit) [#ghostscript] 21:06.48 Chans: (ghostbot) in:#ghostscript 21:12.06 >>> plinnell has signed off IRC (Ping timeout: 245 seconds) [#ghostscript] 21:20.23 >>> tor7 has signed off IRC (Quit: Leaving.) [#ghostscript] 21:23.01 >>> part/#ghostscript Zaister (zaister@shell2.powershells.de) 21:23.31 Chans: (ghostbot) in:#ghostscript 21:25.03 --- Saved uptime records. 21:25.40 >>> sojic has signed off IRC (Remote host closed the connection) [#ghostscript] 21:27.18 FORK(7699) --- fork starting for 'RSSFeeds', PID == 7699, bot_pid == 1061 --- 21:27.19 FORK(7699) !ERROR! cannot load my module: RSSFeeds 21:27.19 FORK(7699) fork: took 1s for RSSFeeds. 21:27.19 FORK(7699) --- fork finished for 'RSSFeeds' --- 21:32.34 >>> join/#ghostscript sojic (~sojic@92.55.124.144) 21:39.08 Chans: (ghostbot) in:#ghostscript 21:46.48 leak: 1 nuh{} items deleted; now have 27 21:48.50 >>> marcosw has signed off IRC (Quit: marcosw) [#ghostscript] 21:49.53 !WARN! PERL: readdir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 862. 21:49.53 !WARN! PERL: closedir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 869. 21:54.43 Chans: (ghostbot) in:#ghostscript 21:54.43 ircCheck: possible lost in space; checking.Mon Aug 26 21:54:43 2013 21:54.43 >ghostbot< TEST 21:54.43 IRCTEST: Yes, we're alive. 21:55.04 >>> paulgardiner has signed off IRC (Quit: ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]) [#ghostscript] 21:55.05 >>> join/#ghostscript pipitas (~pipitas@p5B30389D.dip0.t-ipconnect.de) 21:57.28 FORK(11217) --- fork starting for 'RSSFeeds', PID == 11217, bot_pid == 1061 --- 21:57.29 FORK(11217) !ERROR! cannot load my module: RSSFeeds 21:57.29 FORK(11217) fork: took 1s for RSSFeeds. 21:57.29 FORK(11217) --- fork finished for 'RSSFeeds' --- 22:02.14 >>> sojic has signed off IRC (Remote host closed the connection) [#ghostscript] 22:03.00 >>> join/#ghostscript sojic (~sojic@92.55.124.144) 22:11.18 Chans: (ghostbot) in:#ghostscript 22:20.23 >>> pipitas has signed off IRC (Quit: Leaving.) [#ghostscript] 22:25.13 --- Saved uptime records. 22:27.28 Chans: (ghostbot) in:#ghostscript 22:27.38 FORK(14183) --- fork starting for 'RSSFeeds', PID == 14183, bot_pid == 1061 --- 22:27.39 FORK(14183) !ERROR! cannot load my module: RSSFeeds 22:27.39 FORK(14183) fork: took 1s for RSSFeeds. 22:27.39 FORK(14183) --- fork finished for 'RSSFeeds' --- 22:32.34 >>> sojic has signed off IRC (Remote host closed the connection) [#ghostscript] 22:43.38 Chans: (ghostbot) in:#ghostscript 22:47.00 >>> join/#ghostscript sojic (~sojic@92.55.124.144) 22:54.08 >>> sojic has signed off IRC (Remote host closed the connection) [#ghostscript] 22:58.03 FORK(21800) --- fork starting for 'RSSFeeds', PID == 21800, bot_pid == 1061 --- 22:58.04 FORK(21800) !ERROR! cannot load my module: RSSFeeds 22:58.04 FORK(21800) fork: took 1s for RSSFeeds. 22:58.04 FORK(21800) --- fork finished for 'RSSFeeds' --- 22:59.13 Chans: (ghostbot) in:#ghostscript 22:59.13 ircCheck: possible lost in space; checking.Mon Aug 26 22:59:13 2013 22:59.13 >ghostbot< TEST 22:59.13 IRCTEST: Yes, we're alive. 23:02.45 So RLE is a win for the NoAA case (in some cases a massive win). 23:03.00 But it's a loss for the AA case. 23:03.10 I'll need to do some profiling to see why. 23:06.44 >>> join/#ghostscript sojic (~sojic@92.55.124.144) 23:12.27 >>> sojic has signed off IRC (Remote host closed the connection) [#ghostscript] 23:14.44 >>> join/#ghostscript joo0nas (~sanoj@188-183-5-254-static.dk.customer.tdc.net) 23:15.04 Chans: (ghostbot) in:#ghostscript 23:16.18 >>> join/#ghostscript sojic (~sojic@92.55.124.144) 23:23.43 Seen: Flushed 1 entries. 23:25.28 --- Saved uptime records. 23:28.48 FORK(1074) --- fork starting for 'RSSFeeds', PID == 1074, bot_pid == 1061 --- 23:28.49 FORK(1074) !ERROR! cannot load my module: RSSFeeds 23:28.49 FORK(1074) fork: took 1s for RSSFeeds. 23:28.49 FORK(1074) --- fork finished for 'RSSFeeds' --- 23:30.53 Chans: (ghostbot) in:#ghostscript 23:58.05 LOG: last message repeated 3 times 23:58.05 >>> join/#ghostscript mvrhel_laptop (~chatzilla@KYNcd-02p12-120.ppp11.odn.ad.jp) 23:58.55 FORK(4194) --- fork starting for 'RSSFeeds', PID == 4194, bot_pid == 1061 --- 23:58.56 FORK(4194) !ERROR! cannot load my module: RSSFeeds 23:58.56 FORK(4194) fork: took 1s for RSSFeeds. 23:58.56 FORK(4194) --- fork finished for 'RSSFeeds' ---