00:00.26 Opened logfile log/20130619. 00:00.26 --- Saved uptime records. 00:05.35 Chans: (ghostbot) in:#ghostscript 00:10.01 !WARN! PERL: readdir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 862. 00:10.01 !WARN! PERL: closedir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 869. 00:21.51 Chans: (ghostbot) in:#ghostscript 00:27.45 FORK(32583) --- fork starting for 'RSSFeeds', PID == 32583, bot_pid == 31304 --- 00:27.46 FORK(32583) !ERROR! cannot load my module: RSSFeeds 00:27.46 FORK(32583) fork: took 1s for RSSFeeds. 00:27.46 FORK(32583) --- fork finished for 'RSSFeeds' --- 00:43.17 >>> mvrhel_laptop has signed off IRC (Ping timeout: 248 seconds) [#ghostscript] 00:53.51 Chans: (ghostbot) in:#ghostscript 00:53.51 ircCheck: possible lost in space; checking.Wed Jun 19 00:53:51 2013 00:53.51 >ghostbot< TEST 00:53.51 IRCTEST: Yes, we're alive. 00:55.24 >>> join/#ghostscript SpNg_ (~ARolek@wsip-70-167-118-33.sd.sd.cox.net) 00:58.13 FORK(26035) --- fork starting for 'RSSFeeds', PID == 26035, bot_pid == 31304 --- 00:58.14 FORK(26035) !ERROR! cannot load my module: RSSFeeds 00:58.14 FORK(26035) fork: took 1s for RSSFeeds. 00:58.14 FORK(26035) --- fork finished for 'RSSFeeds' --- 01:00.00 >>> SpNg_ has signed off IRC (Client Quit) [#ghostscript] 01:00.31 --- Saved uptime records. 01:10.33 Chans: (ghostbot) in:#ghostscript 01:28.15 FORK(10351) LOG: last message repeated 3 times 01:28.15 FORK(10351) --- fork starting for 'RSSFeeds', PID == 10351, bot_pid == 31304 --- 01:28.16 FORK(10351) !ERROR! cannot load my module: RSSFeeds 01:28.16 FORK(10351) fork: took 1s for RSSFeeds. 01:28.16 FORK(10351) --- fork finished for 'RSSFeeds' --- 01:54.57 LOG: last message repeated 4 times 01:54.57 >>> join/#ghostscript henrys_ (~henrys@c-50-134-235-109.hsd1.co.comcast.net) 01:56.09 >>> henrys has signed off IRC (Ping timeout: 256 seconds) [#ghostscript] 01:56.10 >>> henrys_ materializes into henrys 01:56.52 >>> sojic has signed off IRC (Remote host closed the connection) [#ghostscript] 01:58.17 Chans: (ghostbot) in:#ghostscript 01:58.17 ircCheck: possible lost in space; checking.Wed Jun 19 01:58:17 2013 01:58.17 >ghostbot< TEST 01:58.17 IRCTEST: Yes, we're alive. 01:58.47 FORK(31534) --- fork starting for 'RSSFeeds', PID == 31534, bot_pid == 31304 --- 01:58.48 FORK(31534) !ERROR! cannot load my module: RSSFeeds 01:58.48 FORK(31534) fork: took 1s for RSSFeeds. 01:58.48 FORK(31534) --- fork finished for 'RSSFeeds' --- 02:01.17 --- Saved uptime records. 02:06.08 >>> join/#ghostscript tkamppeter_ (~till@p5DDBB41F.dip0.t-ipconnect.de) 02:09.38 >>> tkamppeter has signed off IRC (Ping timeout: 252 seconds) [#ghostscript] 02:14.15 Chans: (ghostbot) in:#ghostscript 02:29.11 FORK(15855) --- fork starting for 'RSSFeeds', PID == 15855, bot_pid == 31304 --- 02:29.12 FORK(15855) !ERROR! cannot load my module: RSSFeeds 02:29.12 FORK(15855) fork: took 1s for RSSFeeds. 02:29.12 FORK(15855) --- fork finished for 'RSSFeeds' --- 02:59.43 FORK(32686) --- fork starting for 'RSSFeeds', PID == 32686, bot_pid == 31304 --- 02:59.44 FORK(32686) !ERROR! cannot load my module: RSSFeeds 02:59.44 FORK(32686) fork: took 1s for RSSFeeds. 02:59.44 FORK(32686) --- fork finished for 'RSSFeeds' --- 03:02.01 --- Saved uptime records. 03:03.39 Chans: (ghostbot) in:#ghostscript 03:03.39 ircCheck: possible lost in space; checking.Wed Jun 19 03:03:39 2013 03:03.39 >ghostbot< TEST 03:03.39 IRCTEST: Yes, we're alive. 03:04.12 >>> join/#ghostscript mvrhel_laptop (~chatzilla@c-50-149-95-73.hsd1.wa.comcast.net) 03:19.19 Chans: (ghostbot) in:#ghostscript 03:21.34 >>> join/#ghostscript mrdocs (~mrdocs@opensuse/member/mrdocs) 03:22.43 >>> join/#ghostscript ray_laptop (~chatzilla@rrcs-64-183-45-163.west.biz.rr.com) 03:29.49 FORK(13765) --- fork starting for 'RSSFeeds', PID == 13765, bot_pid == 31304 --- 03:29.50 FORK(13765) !ERROR! cannot load my module: RSSFeeds 03:29.50 FORK(13765) fork: took 1s for RSSFeeds. 03:29.50 FORK(13765) --- fork finished for 'RSSFeeds' --- 03:32.13 >>> mrdocs has signed off IRC (Ping timeout: 246 seconds) [#ghostscript] 03:33.30 >>> join/#ghostscript mrdocs (~mrdocs@opensuse/member/mrdocs) 03:35.30 Chans: (ghostbot) in:#ghostscript 03:49.16 >>> mrdocs has signed off IRC (Ping timeout: 240 seconds) [#ghostscript] 03:50.46 >>> marcosw has signed off IRC (*.net *.split) [#ghostscript] 03:51.16 Chans: (ghostbot) in:#ghostscript 03:51.54 >>> Brando753 has signed off IRC (*.net *.split) [#ghostscript] 03:52.42 >>> join/#ghostscript marcosw (~marcos@67.169.6.130) 03:53.42 >>> join/#ghostscript Brando753 (~Brando753@unaffiliated/brando753) 03:53.59 >>> marcosw has signed off IRC (*.net *.split) [#ghostscript] 03:54.15 >>> Brando753 has signed off IRC (Max SendQ exceeded) [#ghostscript] 03:54.33 >>> join/#ghostscript Brando753 (~Brando753@unaffiliated/brando753) 03:55.40 >>> join/#ghostscript marcosw (~marcos@67.169.6.130) 04:00.11 FORK(31831) --- fork starting for 'RSSFeeds', PID == 31831, bot_pid == 31304 --- 04:00.12 FORK(31831) !ERROR! cannot load my module: RSSFeeds 04:00.12 FORK(31831) fork: took 1s for RSSFeeds. 04:00.12 FORK(31831) --- fork finished for 'RSSFeeds' --- 04:02.49 --- Saved uptime records. 04:07.43 Chans: (ghostbot) in:#ghostscript 04:07.43 ircCheck: possible lost in space; checking.Wed Jun 19 04:07:43 2013 04:07.43 >ghostbot< TEST 04:07.43 IRCTEST: Yes, we're alive. 04:10.03 !WARN! PERL: readdir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 862. 04:10.03 !WARN! PERL: closedir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 869. 04:24.11 Chans: (ghostbot) in:#ghostscript 04:30.15 FORK(12777) --- fork starting for 'RSSFeeds', PID == 12777, bot_pid == 31304 --- 04:30.16 FORK(12777) !ERROR! cannot load my module: RSSFeeds 04:30.16 FORK(12777) fork: took 1s for RSSFeeds. 04:30.16 FORK(12777) --- fork finished for 'RSSFeeds' --- 04:43.58 LOG: last message repeated 3 times 04:43.58 >>> ray_laptop has signed off IRC (Ping timeout: 276 seconds) [#ghostscript] 04:53.29 >>> join/#ghostscript ray_laptop (~chatzilla@cpe-76-171-54-81.socal.res.rr.com) 04:57.29 Chans: (ghostbot) in:#ghostscript 05:00.27 FORK(23958) --- fork starting for 'RSSFeeds', PID == 23958, bot_pid == 31304 --- 05:00.28 FORK(23958) !ERROR! cannot load my module: RSSFeeds 05:00.28 FORK(23958) fork: took 1s for RSSFeeds. 05:00.28 FORK(23958) --- fork finished for 'RSSFeeds' --- 05:03.33 --- Saved uptime records. 05:08.19 ircCheck: possible lost in space; checking.Wed Jun 19 05:08:19 2013 05:08.19 >ghostbot< TEST 05:08.19 IRCTEST: Yes, we're alive. 05:13.47 Chans: (ghostbot) in:#ghostscript 05:14.14 nice email to the customer ray_laptop 05:29.41 Chans: (ghostbot) in:#ghostscript 05:31.11 FORK(12283) --- fork starting for 'RSSFeeds', PID == 12283, bot_pid == 31304 --- 05:31.12 FORK(12283) !ERROR! cannot load my module: RSSFeeds 05:31.12 FORK(12283) fork: took 1s for RSSFeeds. 05:31.12 FORK(12283) --- fork finished for 'RSSFeeds' --- 05:56.37 Seen: Flushed 1 entries. 06:01.23 FORK(26820) --- fork starting for 'RSSFeeds', PID == 26820, bot_pid == 31304 --- 06:01.24 FORK(26820) !ERROR! cannot load my module: RSSFeeds 06:01.24 FORK(26820) fork: took 1s for RSSFeeds. 06:01.24 FORK(26820) --- fork finished for 'RSSFeeds' --- 06:02.11 Chans: (ghostbot) in:#ghostscript 06:03.59 --- Saved uptime records. 06:17.37 Chans: (ghostbot) in:#ghostscript 06:17.37 ircCheck: possible lost in space; checking.Wed Jun 19 06:17:37 2013 06:17.37 >ghostbot< TEST 06:17.37 IRCTEST: Yes, we're alive. 06:25.36 night all 06:25.38 >>> mvrhel_laptop has signed off IRC (Quit: ChatZilla 0.9.90 [Firefox 21.0/20130511120803]) [#ghostscript] 06:31.39 FORK(17841) --- fork starting for 'RSSFeeds', PID == 17841, bot_pid == 31304 --- 06:31.41 FORK(17841) !ERROR! cannot load my module: RSSFeeds 06:31.41 FORK(17841) fork: took 2s for RSSFeeds. 06:31.41 FORK(17841) --- fork finished for 'RSSFeeds' --- 06:33.57 Chans: (ghostbot) in:#ghostscript 06:43.00 >>> join/#ghostscript kens (~Miranda@87.115.212.206) 06:46.11 >>> chrisl_away materializes into chrisl 06:49.33 Chans: (ghostbot) in:#ghostscript 06:52.01 >>> ray_laptop has signed off IRC (Ping timeout: 276 seconds) [#ghostscript] 06:57.25 Seen: Flushed 1 entries. 07:02.11 FORK(9839) --- fork starting for 'RSSFeeds', PID == 9839, bot_pid == 31304 --- 07:02.13 FORK(9839) !ERROR! cannot load my module: RSSFeeds 07:02.13 FORK(9839) fork: took 2s for RSSFeeds. 07:02.13 FORK(9839) --- fork finished for 'RSSFeeds' --- 07:03.59 --- Saved uptime records. 07:05.57 Chans: (ghostbot) in:#ghostscript 07:12.43 >>> join/#ghostscript mrdocs (~mrdocs@c-76-102-153-54.hsd1.ca.comcast.net) 07:12.43 >>> mrdocs has signed off IRC (Changing host) [#ghostscript] 07:12.43 >>> join/#ghostscript mrdocs (~mrdocs@opensuse/member/mrdocs) 07:22.01 Chans: (ghostbot) in:#ghostscript 07:27.27 ircCheck: possible lost in space; checking.Wed Jun 19 07:27:27 2013 07:27.27 >ghostbot< TEST 07:27.27 IRCTEST: Yes, we're alive. 07:32.49 FORK(8529) --- fork starting for 'RSSFeeds', PID == 8529, bot_pid == 31304 --- 07:32.50 FORK(8529) !ERROR! cannot load my module: RSSFeeds 07:32.50 FORK(8529) fork: took 1s for RSSFeeds. 07:32.50 FORK(8529) --- fork finished for 'RSSFeeds' --- 07:38.23 Chans: (ghostbot) in:#ghostscript 07:39.10 kens: http://git.ghostscript.com/?p=user/chrisl/ghostpdl.git;a=commitdiff;h=42ee1094 07:40.15 I think the comment should read substream instead of subroutine ? 07:40.42 Er, yes - let me double check..... 07:41.04 Yeh, I'll change that 07:41.07 IObviously its not a problem, just had me puzzled for a moment as to what I was looking at 07:41.56 Another "interesting" fixed limit..... 07:42.13 Which limit is that ? 07:42.23 NUM_RESOURCE_CHAINS ? 07:42.32 No the 11 substreams 07:42.56 Really ? I hadn't noticed that, though it does prick a vague memory 07:43.15 I think it's 11, but it's definitely a fixed limit 07:43.59 That dereference in gdevpdf.c is a classic blunder 07:44.23 To be honest, these things should be reference counted, but that would be a *massive* project 07:44.46 Yes, it all started using garbage collected memory, and its way too late to change now 07:44.55 And is the source of so many ehadaches 07:45.11 All looks fine to me chrisl 07:45.40 Thanks, I'll push that - another one down :-) 07:45.47 I finally figured out what's wrong with bug #694353 as well. 07:45.58 And indeed its a broken PDF 07:46.32 Its been a busy week for bug reports :-( 07:47.11 Yeh, I did wonder about Marcos suddenly reporting a bunch of PDF related bugs just after Alex's departure! 07:47.26 Yeah, not fair! 07:47.31 :-) 07:47.55 So, is there a chance of handling the breakage in 694353? 07:48.34 Yeah its not too bad, its an image which has 2 filters (and in itself this is mad its [/ASCII85Decode/DCTDecode]) 07:48.53 And it has a /DecodeParams for the stream too, but the DecodeParams array is [<<>>] 07:49.02 Notice only one set of params, for 2 filters..... 07:49.13 And an irrelevant set at that 07:49.34 I think if we ignore teh decodeparams where teh number is not consistent with teh number of filters, we'll be OK 07:50.01 I'm just trying to code that neatly in PS at the moment (its a bit tricky becuae its used in a forall) 07:50.16 That sounds sane - decode params are optional for those filters. Any filter it's required for will error out in the filter code 07:50.48 Yes, and there is absolutely no way to know which filter teh params are for if there aren't the same number of each 07:51.22 Any idea what created the PDF? 07:51.32 iTextsharp I think, just a sec 07:51.51 Oh, a regular source broken files :-( 07:51.58 < Note that the file contains several Flate Encoded streams, but feels it necessary to ascii85 encode the DCT stream.... 07:52.47 Presumably just to make the biggest stream bigger 07:54.09 Chans: (ghostbot) in:#ghostscript 07:56.12 OK that fix worked, now for a cluster push 07:57.09 I beat you to it.... 07:57.18 :-P 07:57.44 It took me an age to find the offending area in teh PDF interpreter 07:57.44 Seen: Flushed 2 entries. 07:58.45 It's not very well laid out, IMO 07:58.58 You mean its spaghetti 07:59.37 Yeh, and the way it redefines procedures at various points drives me bonkers 07:59.47 Me too :-( 08:01.07 Again, I appreciate the idea of keeping the high level logic in Postscript, but there's *so* much in there that really should be done in C via internal operators, instead of coded in PS 08:02.30 >>> join/#ghostscript kens2 (~Miranda@40.249.125.91.dyn.plus.net) 08:03.20 FORK(26497) --- fork starting for 'RSSFeeds', PID == 26497, bot_pid == 31304 --- 08:03.21 FORK(26497) !ERROR! cannot load my module: RSSFeeds 08:03.21 FORK(26497) fork: took 1s for RSSFeeds. 08:03.21 FORK(26497) --- fork finished for 'RSSFeeds' --- 08:04.39 --- Saved uptime records. 08:04.54 >>> kens has signed off IRC (Ping timeout: 264 seconds) [#ghostscript] 08:09.35 Chans: (ghostbot) in:#ghostscript 08:10.13 !WARN! PERL: readdir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 862. 08:10.13 !WARN! PERL: closedir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 869. 08:10.58 chrisl do you remember where Till posted instructions on how to figure out what CUPS is doing with Ghostscript ? ie getting hold of the PostScript file and the command line ? 08:13.52 I'm not sure he ever did 08:14.20 Oh, well no problem then. The erporter with the CUPS problem will have to figure it out themselves 08:14.46 CUPS problem? Which one is that? 08:15.02 Arrived last night 'PDF printing very slow' opr soemthing 08:15.19 694360 08:15.44 Hmm, I haven't been getting the bug notification mails :-( 08:15.54 That's worrying 08:17.31 This is the best I've had: https://wiki.ubuntu.com/DebuggingPrintingProblems#Capturing_print_job_data 08:18.46 Hmm, what I really was hoping for was a GS command line. Of course, the reporter also hasn't suppliued an example file, nor indicated which pritner they are using.... 08:19.14 If they are expecting me to go pore through the Debian bug report they are going to be disappointed 08:20.15 My usual response is to say report it to CUPS, and the CUPS people can work out how to reproduce the problem in Ghostscript, then we'll investigate 08:20.15 Oh and I see Till has declared it a GS bug, and then told the reporter what to do, which he hasn't followed. 08:20.20 >>> join/#ghostscript tor8 (~tor@c-bd7871d5.04-50-6c756e10.cust.bredbandsbolaget.se) 08:21.39 Hmmm, I'm not getting mails from gs-bugs, gs-commits nor gs-regression 08:21.43 Well, Till told him to send the file and GS command line, I've told him to attach the file and give us a command line. So at least we're consistent 08:21.55 chrisl I didnt' get mail for your commit 08:22.23 Did you get mail for changing bugs status (I've changed three this morning)? 08:22.39 I got mail for one, the pdfwrite one 08:22.51 Presumably because I own it 08:23.04 Yeh, so the lists are down :-( 08:23.13 It looks that way 08:23.37 tor8: welcome to the internet. 08:24.43 I did get some email to support, but my mailbox was surprisingly empty this morning. I naively assumed it was just a quiet night 08:25.09 Chans: (ghostbot) in:#ghostscript 08:25.10 I got the ones about the HPGL file 08:25.25 Yes, that's the ones I got,, also I think one from Ray and a customer 08:25.33 tor8: I notice that the header-fixes were merged. did they go in with any noticable changes compared to what we did? 08:26.05 * kens2/#ghostscript sent mail to tech and support 08:26.07 sebras: uppercase include guard defines, but no other major changes 08:26.27 tech seems to be wroking 08:26.31 tor8: alright, and fixing up the pdf #includes I assume. 08:27.01 So the GMail lists are OK I guess, I think the other ones are 'non-gnu' lists or something like that 08:27.19 And suddenly a mail deluge 08:27.20 tor8: or no, seems like you left that out of the patch series..? 08:27.24 kens2: I restarted mailman on casper 08:27.42 tor8: is there a reason for that or did you just forget or postpone? 08:28.27 chrisl I still don't see your other 2 changes, but maybe they'll be along i na bit 08:28.59 sebras: postponed until we have cleaned up the pdf interdependecies 08:29.23 kens2: They've reached me, I changed two bugs to "in progress" 08:29.50 OK, not a problem. I think I'll close 694070 since the reporter says its fixed in 9.07 08:30.23 Yep, you could mention git bisect 08:30.32 I did :-) 08:30.32 Robin_Watts: too many different kinds of errors for that, we'd be better off looking up internationalised string from the error message string itself. 08:31.22 Another massive mail delivery 08:31.50 chrisl now I see your commit and bug changes 08:32.11 No SEGVs excellent ! 08:32.31 Strange, mailman was running on casper, but must have got it's knickers in a twist with the disk space incident 08:32.47 I did wonder if it might have been related to that 08:33.11 Well, it's working now.... 08:33.29 Yep, I'm happy. I see you've picked up on that one you did the patch for 08:33.39 FORK(23016) --- fork starting for 'RSSFeeds', PID == 23016, bot_pid == 31304 --- 08:33.40 FORK(23016) !ERROR! cannot load my module: RSSFeeds 08:33.40 FORK(23016) fork: took 1s for RSSFeeds. 08:33.40 FORK(23016) --- fork finished for 'RSSFeeds' --- 08:34.19 Yep, I'm just going to commit that patch once I eventually clear the remaining stuff out my git stash 08:34.33 Yes, I did say in the thread that seemed the best approach 08:35.15 Especially as it seems to be in use anyway - despite my request 08:35.25 :-) 08:41.35 Chans: (ghostbot) in:#ghostscript 08:58.39 Seen: Flushed 5 entries. 09:03.43 FORK(22223) --- fork starting for 'RSSFeeds', PID == 22223, bot_pid == 31304 --- 09:03.44 FORK(22223) !ERROR! cannot load my module: RSSFeeds 09:03.44 FORK(22223) fork: took 1s for RSSFeeds. 09:03.44 FORK(22223) --- fork finished for 'RSSFeeds' --- 09:04.53 --- Saved uptime records. 09:14.05 Chans: (ghostbot) in:#ghostscript 09:22.38 >>> join/#ghostscript paulgardiner (~chatzilla@smtp.glidos.net) 09:26.26 >>> join/#ghostscript Belleropone (ca456398@gateway/web/freenode/ip.202.69.99.152) 09:26.35 hi 09:26.35 somebody said hello 09:26.35 not returning unaddressed greeting 09:26.49 anyone can help me with ghostscript ? 09:27.05 Probably, depends on the question 09:27.27 hi kens2 09:27.47 i am using ghostscript to print my pdf outpur (from ERP) 09:27.51 chrisl, shouldn't ghostbot be saying hello for us ? 09:28.12 kens2: I dunno, I didn't mess with that - Robin_Watts did that stuff 09:28.34 that pdf should print from my solaris server to Epson dot matrix printer 09:28.51 everything is ok 2 days ago 09:29.22 but today the output from my printer is different 09:29.42 i am using this command : 09:29.43 gs -q -dNOPAUSE -dBATCH -sDEVICE=epsonc -sOutputFile={outfile} {infile} 09:29.43 So something changed 09:29.53 (dot matrix ? really ?) 09:30.08 yes, dot matrix, i need carbonize papers 09:30.15 really 09:30.30 carbonize paper, with 6 ply paper 09:30.33 * kens2/#ghostscript is astonished a dot matrix printer is still working :-) 09:30.59 nothing changed... :| 09:31.09 Chans: (ghostbot) in:#ghostscript 09:31.25 FYI, i am using Oracle Applications ERP 09:32.47 when i reprint the PDF output from 2 days ago (which is print nicely), today, some print is stack one another 09:33.06 Well, if its different output, then something has changed 09:33.40 it is the same output 09:34.10 FORK(12773) --- fork starting for 'RSSFeeds', PID == 12773, bot_pid == 31304 --- 09:34.11 FORK(12773) !ERROR! cannot load my module: RSSFeeds 09:34.11 FORK(12773) fork: took 1s for RSSFeeds. 09:34.11 FORK(12773) --- fork finished for 'RSSFeeds' --- 09:34.33 You just said it was diffferent 09:34.45 the printer output is different 09:35.34 :| really giving me headache 09:35.50 So *something* has changed 09:36.12 But I'm not sure how we can help you 09:36.22 We certainly don't have a printer to try it on 09:37.25 oww 09:37.56 hey, doesn't ghostscript have "paid" version ? 09:38.57 where i can get support ? 09:39.07 Its liccenced commercially, that's not quite the same as a paid version 09:39.25 As a free user, your best bet for support is here, or stack overflow 09:39.28 sebras is /msg'ing ghostbot 09:39.28 [sebras] hello? 09:39.28 notfound: hello 09:39.28 Loaded Math 09:39.46 If you have a reproducible bug you cna raise a Ghostscript bug report 09:39.58 Besides, if we actually can't help you, paying money won't change our abilities 09:41.10 ow... i thought it is like linux, where i can get support beside forum 09:42.31 Artifex do support contracts, but as chrisl said, if we can't help you for free, we can't help you for money either 09:42.47 Its also unclear why you think this is a Ghostscript problem 09:43.09 It worked before, you haven't changed GS, now it doesn't. Seems to me *something* must have changed 09:43.23 Belleropone: yes, but generally we can only help if we can either reproduce the problem, or at least have a *very* clear idea of what the problem is - that's true whether you're a free user or a commercially supported one. 09:43.44 >>> NoOova has signed off IRC (Quit: WeeChat 0.4.0) [#ghostscript] 09:44.02 i because i use the same pdf, and using the command i paste before 09:44.14 the output from printer is different 09:44.37 that's why i guess it is gs 09:45.09 if i may, i can send you the scanned output from yesterday, and today 09:45.25 not yesterday, i mean 2 days ago :D 09:45.28 Maybe your printer is broken 09:46.06 If you send Ghostscript the same input, under the same conditions, it will give you the same output 09:46.25 So somethign must have changed to get different output 09:47.04 hmmmm 09:47.24 Chans: (ghostbot) in:#ghostscript 09:48.05 let me take a deeper examine 09:48.20 btw, who are you guys ? 09:48.27 the developer ? 09:48.30 Yes 09:48.42 ow... that's great :D 09:48.47 tor8: OK. So drop fz_throw, rename fz_throw_message to fz_throw ? 09:49.22 this ghostscript is great 09:49.39 i really can print pdf to dot matrix printer 09:50.26 Robin_Watts: yes. and rethrow. keep the caught/caught_message 09:51.25 tor8: What do you want to happen with rethrow? 09:51.32 fz_rethrow() is the most common usage. 09:51.43 my other thought was to reverse the two 09:51.46 fz_rethrow_message(); is less popular. 09:52.00 fz_(re)throw -> fz_(re)throw_code 09:52.10 fz_(re)throw_message -> fz_(re)throw 09:52.21 fz_rethrow never mentions a code. 09:52.38 It's either fz_rethrow(ctx) or fz_rethrow_message(ctx, message, ...) 09:53.08 The vast majority of calls are fz_rethrow(ctx) (though obviously it doesn't look like that from the patch) 09:53.18 right, and there are almost 200 plain rethrows so going in and adding messages there will be a lot of work 09:53.41 tor8: weren't those the RJW-lines..? 09:54.40 okay, so just drop fz_throw and rename fz_throw_message -> fz_throw, and leave rethrow and caught as is? 09:54.53 tor8: That would be my preference I think. 09:55.09 Unless paulgardiner or sebras have any more cunning thoughts. 09:55.14 Forgetting my reservations about the whole thing, I was liking the current names in the patch 09:55.18 we have 450 regular throws in the old code 09:55.29 What's the current planned changes? 09:55.58 paulgardiner: 1) Remove fz_throw entirely (as it's never used). 2) Rename fz_throw_message to fz_throw 09:56.17 paulgardiner: we're discussing using: fz_throw(code, message), fz_rethrow() and fz_rethrow_message(message) 09:56.44 Oh okay. I think I get it. So we have no way to throw without a message, but that's fine because we don't want one. Is that it? 09:56.46 I proposed dropping fz_rethrow as well, but there are 200 call sites that need an informative message to be added 09:57.30 Robin_Watts: fz_throw() is used all over the place, is it not..? 09:58.06 Maybe I'm misunderstanding , but that sounds odd. Wouldn't that be forcing us to add a message everywhere we have clean up code 09:58.08 sebras: Robin_Watts has a patch on robin/master that adds an error code to fz_throw and turns all fz_throw inside a fz_catch into rethrows 09:58.10 sebras: All the fz_throws in the existing code became fz_throw_messages in my patch. 09:58.19 We're proposing reverting that. 09:58.32 oh, let me have look at the correct branch. :) 09:58.35 paulgardiner: yes, so I'm backing down on that proposal. 09:58.45 Seen: Flushed 7 entries. 09:59.05 Sounding good to me then 09:59.06 fz_throw always with message, fz_rethrow with optional message is our current idea 09:59.25 Yep good 09:59.36 >>> join/#ghostscript sojic (~sojic@92.55.124.153) 10:00.13 I still have some reservation about the whole idea, but I trust your combined intuition over mine alone :-) 10:00.18 tor8: sounds good to me. 10:01.19 paulgardiner: your reservation about rethrow passing along the unmodified error code? 10:01.20 where did the use for the error code come up? what kind of errors do we want to be able to distinguish because we think we can fix them...? 10:01.27 sebras: EAGAIN 10:01.31 for progressive loading 10:02.21 tor8: so basically the reason is that we might see errors because we don't have enough of the pdf to display a particular page. 10:02.46 sebras: Right. And we spot the errors at the top level and know that we should retry later. 10:02.47 tor8: my reservation is about having the message so devorced from the code. I think with most systems, you either rethrow, or throw a completely different error (hence different code and message). 10:03.13 But perhaps this is simply better than what is usual. 10:03.36 >>> chrisl materializes into chrisl_away 10:03.36 Chans: (ghostbot) in:#ghostscript 10:03.42 paulgardiner: isn't rethrow just a replacement for writing out catch and throw..? 10:03.49 paulgardiner: I think we have to think of our system as a combined error/logging one. 10:04.13 The error codes are normative, the error messages informative. 10:04.21 Robin_Watts: yes, that had occured to me. It does make a lot of sense as such 10:04.31 FORK(28138) --- fork starting for 'RSSFeeds', PID == 28138, bot_pid == 31304 --- 10:04.32 FORK(28138) !ERROR! cannot load my module: RSSFeeds 10:04.32 FORK(28138) fork: took 1s for RSSFeeds. 10:04.32 FORK(28138) --- fork finished for 'RSSFeeds' --- 10:04.33 When viewed like that, I don't think there is a strangeness. 10:04.43 sebras: yes, but rethrow would not provide a new message 10:05.15 paulgardiner: true. we used to have an error stack however. 10:05.25 --- Saved uptime records. 10:05.34 paulgardiner: from a debugging perspective this makes sense (and would reqire rethrow to provide a message). 10:06.18 Actually, yes. As combined error and logging it really does make a lot of sense. 10:07.11 Robin_Watts: hm.. what does "top level" in your example refer to? is that code still inside mupdf? 10:07.19 Robin_Watts: or is that in the client app? 10:07.47 sebras: client app, I believe 10:09.01 tor8: ok, so we're saying that we want to provide an error code (EAGAIN) to tell the client app whether it should try again (because the document might not have progressed far enought yet) or an error code (EINVAL) for documents that are actually broken..? 10:09.22 sebras: The former. 10:09.44 Robin_Watts: isn't it both cases? we want the app to be able to distinguish the two cases, no..? 10:10.17 sebras: Right, but the client app should check for the error being EAGAIN and try again. Anything else is taken to be fatal. 10:10.48 Robin_Watts: what operation failing inside mupdf would result in EAGAIN? failing to load an object? 10:10.59 or failing to load a part of the xref perhaps. 10:11.36 sebras: specifically, it it thrown by the stream code when you try to read off the end of the current extent of the stream. 10:13.56 Robin_Watts: how does that work with the xref loading? I vaguely recall something about the repair mode being driven incrementally. 10:16.29 tor8: to get the windows build with openssh to work, I had to change the gen_adobe_ca.h include within crypt_pkcs7.c to ../generated/gen_adobe_ca.h. Will that be correct for other platforms too? 10:19.03 Robin_Watts: in you patch you have a TryLater in pdf_repair_obj() where it is trying to look for PDF_TOK_ENDSTREAM (and if it can not find it scan for it). 10:19.15 Robin_Watts: wouldn't this cause problems with the approach you mentioned above? 10:19.55 Chans: (ghostbot) in:#ghostscript 10:21.25 tor8: Let me update the patch. 10:21.32 sebras: hold on. 10:21.38 tor8: progressive vs repair mode, I wondered that too. I wondered why the xref sections are needed at all when you are progressively loading the file, seeing as repair mode generates them on the fly 10:21.56 paulgardiner: no, it should be done with -I../generated in the project or makefile 10:22.12 tor8: okay. Will do 10:22.21 I might have missed those in the vcproj files 10:22.37 I think I did them though, but might've missed some 10:23.58 Just missed a couple 10:27.08 tor8: fix pushed to paul/master 10:32.33 There are some win32 solution fixes on robin master too. 10:34.39 FORK(11681) --- fork starting for 'RSSFeeds', PID == 11681, bot_pid == 31304 --- 10:34.40 FORK(11681) !ERROR! cannot load my module: RSSFeeds 10:34.40 FORK(11681) fork: took 1s for RSSFeeds. 10:34.40 FORK(11681) --- fork finished for 'RSSFeeds' --- 10:35.27 Chans: (ghostbot) in:#ghostscript 10:41.44 OK, robin/master updated as we talked about. 10:41.59 robin/progressive has the latest version of the progressive patch on too. 10:43.59 Robin_Watts: fz_rethrow_message should have __printflike() 10:44.14 tor8: will fix. 10:44.22 also, what is fz_pass_thru? 10:44.35 paulgardiner: Your win32 fixes look good. 10:45.04 Robin_Watts: your win32 header project fixes look good 10:45.05 tor8: fz_pass_thru(ctx, FZ_ERROR_TRYLATER) does: if (fz_caught(ctx) == FZ_ERROR_TRYLATER) fz_rethrow(ctx); 10:45.28 fz_pass_through, please 10:45.32 saves me lots of typing (and saves a function call in the rethrow cases) 10:45.34 ok. 10:45.51 Is fz_pass_thru still needed? 10:46.20 paulgardiner: Yes. For the occasional place where TRYLATER has to be treated differently to GENERIC. 10:46.51 Oh for places where we would otherwise loop rather than just throw a new message 10:47.50 I've pushed pauls win32 fixes along with mine. 10:47.54 Hmmm. The name fz_pass_through doesn't give any indication that it's a thing specific to TRYLATER 10:48.03 paulgardiner: It's not. 10:48.14 It passes the specified error through. 10:48.16 Takes an error code 10:48.17 ? 10:48.22 as arg? 10:48.34 fz_pass_through(ctx, error) 10:48.40 Right. 10:49.03 I was just watching the talker. not looking at the patch. 10:49.06 fz_rethrow_if(ctx, error) or some such? 10:49.27 tor8: I'm always prepared to accept better names :) 10:49.51 fz_rethrow_error perhaps? pass_through can mean so many things 10:50.14 fz_rethrow_specific? 10:50.46 paulgardiner: I've got a list of nitpicks I found when slicing up the headers 10:50.57 Of that set, I prefer fz_rethrow_if 10:51.35 pdf_specifics I'd write as pdf_document_cast (or something like it) 10:51.36 yeah, if is good, accept it sounds like it should take a boolean 10:51.41 HOTSPOT needs a PDF_ prefix 10:51.41 Chans: (ghostbot) in:#ghostscript 10:51.52 the Ff field flags should be uppercase and also PDF_ prefixed 10:51.58 tor8: yeah, pdf_document_cast is good 10:52.07 and crypt_pkcs7 should be moved to pdf sources 10:52.31 a general theme (for Robin_Watts as well) is conversion function naming 10:52.55 yes, all sounds like improvements to me 10:52.56 I prefer the form: Y Y_from_X(X) rather than Y X_to_Y(X) 10:53.59 the bin2hex, cquote and fontdump tools could probably be combined into one tool with a flag for ascii string or hex dumping 10:54.30 cquote probably doesn't strictly need to exist, bin2hex should work fine for it too 10:54.45 but having a readable generated header is of course not a bad thing 10:56.19 The only possible objection I have to the conversion function naming is down to where we expect the function to live. 10:56.49 elephant_to_giraffe lives in the elephant house. giraffe_from_elephant lives with the giraffes. 10:57.16 there you go with your hierarchical naming again ;) 10:57.53 but with our new ability to split functional units into several compilation units without making the implementation details public, that's less of a problem. 10:57.54 image_to_pixmap is the only X_to_Y variant left 10:58.12 ok, I'll fix it. 10:58.32 So, did we have a winner in the fz_pass_thru sweepstakes? 10:58.47 fz_rethrow_if ? 10:58.57 Seen: Flushed 4 entries. 10:59.14 Robin_Watts: fz_new_image_from_pixmap has the 'new' magic word in it 10:59.27 depending on the reference counting, perhaps pixmap_from_image should have 'new' too? 11:00.42 i.e. fz_image_to_pixmap -> fz_new_pixmap_from_image 11:01.20 fz_rethrow_if looks funky, but it is the most obvious of the suggestions 11:01.53 fz_rethrow_if_error or _if_code perhaps? or is that just making it longer but not improving clarity 11:02.39 I'll go with rethrow_if for now, and we can tweak it if we find a better version. I don't think this is being committed today :) 11:03.44 OK, exception handling commit should be good to go. The rethrow_if stuff is in the progressive loading one (a new version of that is also up) 11:03.51 fz_rethrow_specified_error 11:04.03 But yes "if" is fine 11:04.29 paulgardiner: I'd prefer your earlier suggestion of rethrow_specific to that, but it's still too much to type :) 11:04.59 exception patch LGTM 11:05.09 FORK(26289) --- fork starting for 'RSSFeeds', PID == 26289, bot_pid == 31304 --- 11:05.10 FORK(26289) !ERROR! cannot load my module: RSSFeeds 11:05.10 FORK(26289) fork: took 1s for RSSFeeds. 11:05.10 FORK(26289) --- fork finished for 'RSSFeeds' --- 11:05.49 --- Saved uptime records. 11:06.16 I would suggest adding FZ_ERROR_MEMORY or OUT_OF_MEM as one of the codes thrown in malloc/realloc 11:06.39 in case clients have their own caches they can clear out 11:06.54 which our scavenging malloc can't touch 11:07.37 Chans: (ghostbot) in:#ghostscript 11:10.25 tor8: yeah, that occurred to me this morning (and I then promptly forgot it) 11:11.06 I'm going for a run. Must read mvrhel's patches when I get back. 11:15.55 tor8: For that purpose I'd rather expose a 'scavenge' callback in the context though. 11:21.21 Robin_Watts: right. still, it might be a way to signal fatal errors separate from document-based errors 11:24.21 Chans: (ghostbot) in:#ghostscript 11:35.41 FORK(10298) --- fork starting for 'RSSFeeds', PID == 10298, bot_pid == 31304 --- 11:35.42 FORK(10298) !ERROR! cannot load my module: RSSFeeds 11:35.42 FORK(10298) fork: took 1s for RSSFeeds. 11:35.42 FORK(10298) --- fork finished for 'RSSFeeds' --- 11:58.59 LOG: last message repeated 4 times 11:58.59 Seen: Flushed 3 entries. 12:05.43 FORK(22820) --- fork starting for 'RSSFeeds', PID == 22820, bot_pid == 31304 --- 12:05.44 FORK(22820) !ERROR! cannot load my module: RSSFeeds 12:05.44 FORK(22820) fork: took 1s for RSSFeeds. 12:05.44 FORK(22820) --- fork finished for 'RSSFeeds' --- 12:06.03 --- Saved uptime records. 12:10.29 !WARN! PERL: readdir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 862. 12:10.29 !WARN! PERL: closedir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 869. 12:11.47 Chans: (ghostbot) in:#ghostscript 12:22.17 ircCheck: possible lost in space; checking.Wed Jun 19 12:22:17 2013 12:22.17 >ghostbot< TEST 12:22.17 IRCTEST: Yes, we're alive. 12:27.25 Chans: (ghostbot) in:#ghostscript 12:34.32 * henrys/#ghostscript knew guillaume was going to say that sigh 12:35.47 FORK(3203) --- fork starting for 'RSSFeeds', PID == 3203, bot_pid == 31304 --- 12:35.48 FORK(3203) !ERROR! cannot load my module: RSSFeeds 12:35.48 FORK(3203) fork: took 1s for RSSFeeds. 12:35.48 FORK(3203) --- fork finished for 'RSSFeeds' --- 12:37.35 tor8: good point. 12:39.39 FILE, FORMAT or SYNTAX for document parsing errors? 12:40.01 less crucial but if we're adding codes may as well make use of some basic categories 12:40.44 tor8: I think we should be driven by need in such things. 12:41.28 fair enough. 12:43.41 Chans: (ghostbot) in:#ghostscript 12:55.33 Robin_Watts: so, reshuffling source files? 12:55.49 paulgardiner: any suggestions? 12:55.57 sebras: you too. 12:56.39 tor8: pong. 12:57.13 sebras: we want to clean up the top level directory of mupdf (it's getting cluttered) 12:57.37 >>> join/#ghostscript dogisfat (d1765a73@gateway/web/freenode/ip.209.118.90.115) 12:57.49 tor8: maybe move android ios winrt win32 debian and friend under apps. 12:57.54 one idea we discussed was putting the library source files in one directory (say "source" or "library") and the platform specific apps in another (say "platform") 12:57.57 I think that would go a long way actually. 12:58.01 tor8: Not ignoring you - just struggling to think of anything useful to say 12:58.48 hm.. certs/ seems a bit unnecessary given that it is just a single file..? 12:59.08 Chans: (ghostbot) in:#ghostscript 12:59.12 and another for "data" files (the stuff that gets compiled into generated) 12:59.22 Seen: Flushed 4 entries. 12:59.32 tor8: could we put the cert-file there too? 12:59.35 the names of the top level directories could possibly be discussed 12:59.39 sebras: yes. 12:59.49 There is already a grouping in fitz based on the part of the name before the first _ 13:00.02 back. 13:00.10 I like "platform" 13:00.13 tor8: why is ucdn on the top level and not under thirdparty? 13:00.26 Maybe those prefixes could become subdirectories 13:00.39 and "source" (or "src") would seem to be the convention that other people follow. 13:00.57 paulgardiner: I'd like to drop the prefix_ from the fitz files, I think. 13:01.02 yes, platform is a good name. 13:01.36 as is src given that we already conform to the standard of having an include directory. 13:02.02 Robin_Watts: I was suggesting dropping the prefix on the files and putting them into directories named with the prefix 13:02.22 ... assuming the prefix sharing is to do with modularity 13:02.29 I don't think that's warranted now, is it? 13:02.45 The prefix sharing was partly to do with object files being uniquely named before. 13:02.53 Robin_Watts: so you favour fitz/open.c over fitz/stm_open? 13:02.55 .c 13:02.56 sebras: it's not a common upstream library 13:03.21 sebras: I favour fitz/stream.c over fitz/base_stream.c 13:03.32 object file uniqueness is the main reason for the current prefix based file names 13:03.40 that can be trivially solved in the makefile 13:03.51 but maybe less so on android and msvc solutions? 13:03.56 Probably not. Just a suggestion in reply to tor8's source-file-shuffling-suggestion request 13:03.56 If we split stream into separate .c's (say stream_open.c, stream_seek.c, stream_read.c etc) then I'd be happy with a prefix. 13:04.31 Robin_Watts: stream-open.c, stream-seek.c, stream-read.c and stream-imp.h 13:04.39 tor8: oops, yes. 13:04.57 pdf/stream.c is separate from fitz/stream.c though 13:05.06 that's the kind of collision in the build system I'm wary of 13:05.26 in the makefile I can easily add prefixes (or subdirs) in the build/debug/ output directory 13:05.36 not sure how win32 vcproject handles it 13:05.56 FORK(6096) --- fork starting for 'RSSFeeds', PID == 6096, bot_pid == 31304 --- 13:05.57 FORK(6096) !ERROR! cannot load my module: RSSFeeds 13:05.57 FORK(6096) fork: took 1s for RSSFeeds. 13:05.57 FORK(6096) --- fork finished for 'RSSFeeds' --- 13:06.16 --- Saved uptime records. 13:06.19 we can always drop the prefixes on fitz files 13:06.32 whether we also drop the pdf- and xps- prefixes is the issue at hand 13:06.38 We might have to split libmupdf into libfitz/libpdf etc. 13:06.48 Robin_Watts: in the vcproject? 13:06.55 yeah. 13:06.56 well, that would work for me 13:07.05 then they end up in separate output directories 13:07.10 indeed. 13:07.35 libmupdf-fitz.lib libmupdf-pdf.lib libmupdf-xps.lib 13:07.39 Might have a slight wrinkle with circular dependencies. 13:08.14 we shouldn't have any circular dependecies between the fitz/ and pdf/ stuff 13:08.28 fz_open_document (in libfitz) would depend on pdf_open_document (in libpdf) which would depend on fz_malloc (in libfitz) 13:08.36 apart from that one, yes 13:08.49 libmupdf-doc :) 13:08.54 but I think static libraries are safe for that though 13:09.12 but might need convoluted linker lines. but libmupdf-doc is fine. 13:09.21 I think MSVC copes, but gcc et al don't. 13:09.51 yeah. -lfitz -lpdf -lfitz is what's needed on some gcc based tool chains 13:10.16 but the unix makefile should just make one libmupdf.a anyway, IMO 13:10.45 To play devils advocate... 13:11.04 leaving the pdf_ prefixes does mean you can tell what the file is from the tab in MSVC alone. 13:11.29 that's a good point 13:11.35 source/pdf/pdf-stream.c then? 13:11.49 Yeah, drop the 'base_' and 'res_' ones from fitz. 13:11.54 yeah. 13:12.02 and keep the pdf/xps ones, etc. 13:12.08 paulgardiner, sebras: concur? 13:12.09 I think I may want to keep the draw- prefix (but drop the draw files in fitz/) 13:12.30 http://ghostscript.com/~tor/stuff/layout.txt 13:12.39 tor8: let me have a look. 13:13.01 need comments on names 13:13.08 tor8: where did the include directory go? 13:13.14 sebras: forgot it :) 13:13.15 I'd prefer resource to data, personally. 13:13.26 sebras: The include directory is done :) 13:13.37 Robin_Watts: agree, data is a bit too abstract. 13:13.55 yeah. resource is best. 13:13.57 tor8: you forgot apps/ too. 13:14.05 sebras: apps is in source/tool/ 13:14.08 or tools/ 13:14.22 not decided on whether I like or hate plural s in directory names 13:14.29 I would prefer apps to tools. 13:14.48 that directory would contain only the command line tools 13:14.51 mutool and mudraw 13:14.53 tools possibly implies "tools used during the build", like echogs, or mkrom etc. 13:14.54 Robin_Watts: I guess the idea is that x11 will move out from there and into platform at some point. 13:14.54 Chans: (ghostbot) in:#ghostscript 13:15.00 the pdfapp stuff would move into platform somewhere 13:15.07 OK., 13:15.08 platform/viewer perhaps 13:15.16 tor8: alright. 13:15.32 tor8: and ucdn? 13:15.34 Robin_Watts: but yes, I see your point (re tools used during build) 13:15.40 but those live in scripts 13:15.47 sebras: in source/ 13:16.01 If the viewer is moving out, my apps objection is greatly reduced. 13:16.04 I could live with tools. 13:16.19 Robin_Watts: how about "tool"? 13:16.29 sebras: Do we just have 1 ? 13:16.37 no, we have many 13:16.47 Then tools, IMHO. 13:16.48 Robin_Watts: tor8 opted for tool though. 13:16.48 but we have "include" not "includes" 13:17.00 "include files" 13:17.07 and include is the "standard" 13:17.17 resources too then? 13:17.22 certs, fonts, cmaps? 13:17.43 resources (or 'res' cos I'm lazy) 13:17.52 I reckon plurals, personally. 13:18.07 scripts :) 13:18.07 okay, reload the page 13:18.26 source, not library, personally. 13:18.56 alright, I'll go with plurals 13:19.23 library sounds a bit more like binaries would go there, but source contains only our library sources 13:19.25 >>> dogisfat has signed off IRC (Ping timeout: 250 seconds) [#ghostscript] 13:19.34 still, I'm fine with "source" 13:19.44 tor8: or sources? >;) 13:19.58 sebras: source can be an "uncountable" noun :) 13:20.00 how about platforms? 13:20.13 platform is short for platform specific source ;) 13:20.20 we don't contain the actual platforms there 13:20.27 ok then. they aren't real objections. 13:20.28 but I'll bow to a majority vote 13:20.35 platform 13:20.58 cbz would also go into source as I understand it. 13:21.40 tor8: have you had customer requirements for .so? maybe it is wise to consider that about now since you will have to rewrite the Makefiles a bit. 13:22.17 what is muimage.c and does it relly warrant a directory of its own? 13:22.44 I personally think muimage can live with cbz 13:22.56 sebras: it's a plain image fz_document type 13:23.05 mupdf hello.jpg 13:23.16 I think every document type should get its own dir, personally. 13:23.38 rename cbz to comic and support both zipped, unzipped directory and plain image files 13:24.04 Robin_Watts: muimage.c is a bit generic of a name (it collides with many other "image" files) 13:24.13 If they use the same source, then share the dir. Currently they don't, so they shouldn't. 13:24.25 Robin_Watts: rename muimage to img? 13:24.28 tor8: I'm always open to better names. 13:24.29 ok. 13:24.46 or jpeg? :) 13:24.55 tor8: do we support png? 13:25.03 sebras: jpeg, png and tiff IIRC 13:25.07 sebras: jpg/png/tiff. 13:25.20 same set as xps 13:25.33 we could add jpeg2k fairly trivially 13:25.43 but I don't see a lot of pressing need for it 13:25.53 tor8: then maybe cbz should be separate img for the time being imho. 13:28.16 >>> join/#ghostscript gandaro (~gandaro@wikipedia/Gorlingor) 13:30.45 Chans: (ghostbot) in:#ghostscript 13:30.52 * Robin_Watts/#ghostscript lunches 13:36.41 FORK(30143) --- fork starting for 'RSSFeeds', PID == 30143, bot_pid == 31304 --- 13:36.42 FORK(30143) !ERROR! cannot load my module: RSSFeeds 13:36.42 FORK(30143) fork: took 1s for RSSFeeds. 13:36.42 FORK(30143) --- fork finished for 'RSSFeeds' --- 13:39.00 Robin_Watts, paulgardiner, sebras: http://ghostscript.com/~tor/stuff/fitz-files.txt 13:39.05 list of new name candidates 13:39.14 stext = structured text (the text extraction device) 13:40.23 Looks pretty good to me 13:41.52 * sebras/#ghostscript looks 13:42.09 reload 13:42.09 tor8: crypt_pkcs7 -> dash. 13:42.19 sebras: mv crypt_pkcs7.c ../pdf/ 13:43.08 tor8: I'd still appreciate if it was dashing(!) though. 13:43.23 ...but something tells me that signature-checking never will be. 13:46.16 tor8: I'd be tempted (given the naming and length of the files) to combine draw-scale*.c into one file. 13:46.57 tor8: what is fitz-files.txt btw? I assume it shouldn't be in the listing..? 13:47.07 Chans: (ghostbot) in:#ghostscript 13:47.11 tor8: func.c -> function.c? 13:47.22 sebras: reload :) it's the list that I uploaded and I renamed func.c to function.c already :) 13:47.52 sebras: draw-scale.c and draw-scale-simple.c are exclusive and alternative versions of the same code 13:48.01 maybe a different scheme based on #ifdef is better there 13:48.17 or runtime choice of the implementation 13:48.25 tor8: that might be even better. 13:49.07 tor8: from an architectural standpoint it is strange that svg output is a device and pcl/pwg is not. 13:49.47 tor8: where did strema-seek.c go? 13:50.06 you mentioned it before. 13:50.27 stream-seek was a hypothetical example 13:50.30 tor8: what is trans.c? the transitions? 13:50.49 tor8: oh. I was suprised not to find it in the current source. :) 13:51.01 yes, transitions. I'll rename. 13:51.35 tor8: I have no problem with the image- prefix. 13:51.50 image.c has fz_image 13:51.55 image-xxx.c works on fz_pixmaps 13:52.19 tor8: ok, so what about pixmap- then? 13:52.45 possible. I'll let robin decide :) 13:52.56 once he gets back from lunch... 13:57.52 Robin_Watts: when/if we clean up the text extraction api more, text=input to device, raw-text=span soup, structured-text=analyzed and sorted text 13:59.34 >>> gandaro has signed off IRC (Quit: Leaving) [#ghostscript] 13:59.44 Seen: Flushed 4 entries. 14:03.45 Chans: (ghostbot) in:#ghostscript 14:06.23 --- Saved uptime records. 14:07.31 FORK(24981) --- fork starting for 'RSSFeeds', PID == 24981, bot_pid == 31304 --- 14:07.32 FORK(24981) !ERROR! cannot load my module: RSSFeeds 14:07.32 FORK(24981) fork: took 1s for RSSFeeds. 14:07.32 FORK(24981) --- fork finished for 'RSSFeeds' --- 14:08.10 load-xxx might be nicer than image-xxx. 14:08.33 As otherwise you might be surprised to see that we handle images of type xxx without ever using the image-xxx file :) 14:19.21 Chans: (ghostbot) in:#ghostscript 14:22.15 Robin_Watts: and device/output-svg? 14:25.17 dev-svg.c would work for me. 14:25.51 If we DO want to use subdirs for devices, then I'd have thought that a subdir per device would make more sense than a subdir with all the devices in. 14:27.18 so now we have some inconsistencies 14:27.23 draw-device 14:27.29 display-list without device prefix 14:27.33 stext-extract 14:27.44 device-bbox/trace 14:27.47 device-svg 14:28.21 stext-extract might become stext-device 14:28.48 then svg-device and if svg gets more files then they can go with the svg- prefix as well or move into an svg-device subdir 14:30.07 or the reverse: device-stext and device-draw and then auxiliary files stext-xxx and draw-xxx but that seems backwards to me 14:30.44 list-device, draw-device, stext-device 14:31.33 I'd still go with display-list though (since it has both the device and the playback in one file) 14:31.59 tor8: we could now split it into 2 files plus an implementation header though. 14:33.07 I don't want to split just yet, the playback part is only 200 odd lines 14:33.09 * Robin_Watts/#ghostscript buys shoes identical to a pair I currently own off the web. helen would be ashamed of me. 14:33.31 Robin_Watts: I buy shoes blindly off the web ;) 14:33.58 I don't think we need to get TOO het up about the internal naming as it's not a cast in stone public thing. We can rename etc later. 14:33.59 >>> tkamppeter_ materializes into tkamppeter 14:34.05 consistency is nice though, of course. 14:34.24 yes. so display-list.c to match the public display-list.h or list-device.c? 14:35.34 >>> join/#ghostscript talexb (~abeamish@p66.bluecatnetworks.com) 14:35.52 this means we'll also end up with trace-device.c and bbox-device.c 14:35.52 Chans: (ghostbot) in:#ghostscript 14:37.03 Personally, list-device.c 14:37.53 FORK(30341) --- fork starting for 'RSSFeeds', PID == 30341, bot_pid == 31304 --- 14:37.54 FORK(30341) !ERROR! cannot load my module: RSSFeeds 14:37.54 FORK(30341) fork: took 1s for RSSFeeds. 14:37.54 FORK(30341) --- fork finished for 'RSSFeeds' --- 14:52.09 Chans: (ghostbot) in:#ghostscript 15:00.13 Seen: Flushed 2 entries. 15:03.37 >>> chrisl_away materializes into chrisl 15:06.27 --- Saved uptime records. 15:07.25 Chans: (ghostbot) in:#ghostscript 15:08.05 FORK(5399) --- fork starting for 'RSSFeeds', PID == 5399, bot_pid == 31304 --- 15:08.06 FORK(5399) !ERROR! cannot load my module: RSSFeeds 15:08.06 FORK(5399) fork: took 1s for RSSFeeds. 15:08.06 FORK(5399) --- fork finished for 'RSSFeeds' --- 15:10.21 >>> Belleropone has signed off IRC (Ping timeout: 250 seconds) [#ghostscript] 15:23.31 Chans: (ghostbot) in:#ghostscript 15:37.47 Robin_Watts: do we always want to build non-v8 versions even if v8 is present? 15:38.12 tor8: I would say so. 15:38.12 FORK(2149) --- fork starting for 'RSSFeeds', PID == 2149, bot_pid == 31304 --- 15:38.13 FORK(2149) !ERROR! cannot load my module: RSSFeeds 15:38.13 FORK(2149) fork: took 1s for RSSFeeds. 15:38.13 FORK(2149) --- fork finished for 'RSSFeeds' --- 15:38.32 Otherwise the cluster will only ever test the v8 versions, and we might break the others without realising. 15:39.18 Robin_Watts: right. 15:39.48 Chans: (ghostbot) in:#ghostscript 15:48.20 >>> sebras has signed off IRC (Quit: leaving) [#ghostscript] 15:53.04 >>> join/#ghostscript mvrhel_laptop (~chatzilla@c-50-149-95-73.hsd1.wa.comcast.net) 15:55.41 Chans: (ghostbot) in:#ghostscript 15:55.53 Morning mvrhel_laptop 15:56.32 Good morning 15:57.20 I pushed your patches to golden (with a couple of whitespace fixes) 15:57.54 Robin_Watts: ok thanks. I am going to have more commit here in the next hour. mainly project compiler settings due to complaints form windows app certification 15:58.04 ok. 16:00.45 Seen: Flushed 3 entries. 16:05.45 OK that last bug has left me with a headache, so I'm off. Goodnight all 16:05.55 night kens2 16:06.01 >>> kens2 has signed off IRC (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) [#ghostscript] 16:07.19 --- Saved uptime records. 16:09.07 FORK(5196) --- fork starting for 'RSSFeeds', PID == 5196, bot_pid == 31304 --- 16:09.08 FORK(5196) !ERROR! cannot load my module: RSSFeeds 16:09.08 FORK(5196) fork: took 1s for RSSFeeds. 16:09.08 FORK(5196) --- fork finished for 'RSSFeeds' --- 16:10.37 !WARN! PERL: readdir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 862. 16:10.37 !WARN! PERL: closedir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 869. 16:11.55 Chans: (ghostbot) in:#ghostscript 16:33.36 Robin_Watts: two commits on tor/master and reshuffle proposal on tor/shuffle 16:33.47 tor8: ok. I'll look now. 16:34.07 I've run into a problem with the error code stuff, and my head is frazzled. 16:34.52 If the 'fz_always' block calls any functions that use try/catch it loses the errcode for the fz_catch. 16:34.56 I'm pleasantly surprised that git rebase -i handles renames when moving edits backwards in time :) 16:35.40 Robin_Watts: ohhh... that's a headache to solve I bet! 16:36.38 Robin_Watts: what is the ctx->error->stack[i].code for? 16:37.02 That's the magic coe to make us enter always/catch correctly. 16:37.33 hm, if code in fz_always block throws an exception, where do we end up? 16:37.53 catch. 16:38.19 and the problem is that the second throw overwrites the first throw's code? 16:38.27 I'm not sure I think that's actually a problem :) 16:38.57 we were doing something that went wrong, and in the process of cleaning up, another error happened 16:39.13 tor8: The problem is that having a try is enough to overwrite the code. 16:39.34 FORK(8776) --- fork starting for 'RSSFeeds', PID == 8776, bot_pid == 31304 --- 16:39.35 FORK(8776) !ERROR! cannot load my module: RSSFeeds 16:39.35 FORK(8776) fork: took 1s for RSSFeeds. 16:39.35 FORK(8776) --- fork finished for 'RSSFeeds' --- 16:39.36 I think I need to move errcode into the indexed thing. Will ponder that. 16:39.42 oh, right. 16:39.47 you zero the error code on a try 16:39.53 yeah. 16:40.20 would it be bad if we just left it as is on a try, and just set it to the code on throw, and reset on caught? 16:40.39 maybe move to a temporary place on catch and move back from temporary on rethrow 16:43.03 tor8: That would require a function call on every catch. 16:43.34 but only on 'taken' catches. 16:44.04 Chans: (ghostbot) in:#ghostscript 16:45.04 actually, I can avoid the function call, I think. 16:45.31 I think just setting on try should be enough for our purposes, no? 16:45.44 and caught would always read out the latest thrown code 16:45.57 I currently set it to 0 on try. 16:46.05 and that causes the problem. 16:46.18 yes, I wonder why you need to do that though... 16:46.25 I can't think of a reason 16:46.28 Why do I set to 0... 16:46.39 good question :) 16:46.45 Let me just try not doing that :) 16:49.56 hah. That solves it. 16:50.10 Thanks. 16:59.12 tor8: The md5 pixmap stuff was in a separate file, so the linker can elide it for the 99% of programs that won't need it. 16:59.42 We only use it in mudraw. No viewer will use it. 17:00.09 Robin_Watts: the md5 functions are used in normal pdf crypto functions as well 17:00.19 the basic password algorithm is md5 based 17:00.31 right, but that particular function (the md5 of pixmaps) is only used in the one place. 17:00.43 and it's a tiny function... 17:00.53 Chans: (ghostbot) in:#ghostscript 17:01.01 right, it is a tiny function. 17:01.10 but it doesn't hurt us to have it separate. 17:01.10 Seen: Flushed 3 entries. 17:01.32 if it had pulled in a big dependency that isn't normally used, I'd agree it would belong in a separate link unit 17:01.43 but since md5 is already needed elsewhere, I didn't see the harm 17:02.08 ok. 17:02.20 they both look fine. 17:02.34 I have the x11 changes here too, but you beat me to it. 17:02.44 and it seemed a bit silly to have a file with 5 lines in it :) 17:03.33 so the shuffle branch has a pretty big reworking of the Makefile 17:03.44 the vcprojects will need a lot of work as well 17:03.59 and I'm considering just swallowing the ucdn files into source/fitz/ and be done with it 17:08.13 --- Saved uptime records. 17:09.51 FORK(31336) --- fork starting for 'RSSFeeds', PID == 31336, bot_pid == 31304 --- 17:09.52 FORK(31336) !ERROR! cannot load my module: RSSFeeds 17:09.52 FORK(31336) fork: took 1s for RSSFeeds. 17:09.52 FORK(31336) --- fork finished for 'RSSFeeds' --- 17:10.37 >>> join/#ghostscript ray_laptop (~chatzilla@cpe-76-171-54-81.socal.res.rr.com) 17:13.54 tor8: I pushed mvrhel_laptop's commits. So I'll need to rebase yours on top of them. 17:13.57 Unless you want to do it. 17:14.32 I'll rebase 17:16.36 Robin_Watts: ./build/generated or ./generated ? 17:17.13 Chans: (ghostbot) in:#ghostscript 17:17.59 Having everything that gets built in build is nice, but might be odd for android etc. 17:18.06 as they don't build in build. 17:18.11 and nor does win32. 17:18.20 So generated might make more sense. 17:21.02 Robin_Watts: okay. new tor/shuffle 17:21.08 and tor/master rebased 17:21.36 I've pushed 2 of the 3 from tor/master 17:21.48 Is the third one ready to go? 17:22.00 yes. that's a harmless Makethird fix 17:22.16 that's not affected by the directory layout, but prepares for it 17:24.00 Pushed. 17:24.09 An exception handling fix on robin master 17:24.33 The Android build is broken; I have a commit up that fixes some of it, but I need to fix the includes etc too. 17:25.08 Robin_Watts: the android build needs to be remade significantly for the include and sources earthquakes 17:25.21 exception fix on robin/master looks good 17:26.15 the exception fix for android on robin/master is also good 17:26.39 Thanks. 17:26.55 when updating android, could you check if we can get rid of Core2.mk? 17:27.31 LOCAL_SRC_FILES could possibly use the same $(wildcard ) tricks 17:28.29 tor8: I think I plan to leave android broken until after shuffle goes in. 17:30.58 I'm fairly happy with the shuffle on tor/shuffle now 17:31.07 but do give it a thorough look 17:31.35 It's a bit of a nightmare to review because of the way viewgit shows it. 17:32.09 Robin_Watts: just check it out :) 17:32.20 gitk and viewgit both suck for viewing file renames 17:32.40 Chans: (ghostbot) in:#ghostscript 17:33.54 win32 projects need fixing. 17:34.03 I was hoping you could do that :) 17:34.09 will do. 17:34.14 for the makefile I made three libs 17:34.16 That will let me look at stuff. 17:34.27 libmupdf.a and libmupdf-js-none.a and libmupdf-js-v8.a 17:34.40 rather than libmupdf.a and libmupdf-v8.a 17:35.11 so if we add further js implementations, switching between them should be easier 17:36.19 -Iinclude -Iscripts -Igenerated should be enough for all the -I directives (excepting thirdparty) 17:36.29 did you really use 'Resources' rather than 'resources' ? 17:36.34 or is that just windows being crap ? 17:36.39 nope, all lowercase for me 17:36.50 Fonts and Images ? 17:37.48 all file names except README and COPYING and CHANGES (and the mixed case ones in android) are lowercase 17:39.10 for lack of a better name, the pdfapp stuff ended up in platform/x11 17:39.54 resources/fonts/ has CamelCase names, right? 17:40.10 yeah, the individual font and cmaps have camelcase names 17:40.20 FORK(25854) --- fork starting for 'RSSFeeds', PID == 25854, bot_pid == 31304 --- 17:40.21 FORK(25854) !ERROR! cannot load my module: RSSFeeds 17:40.21 FORK(25854) fork: took 1s for RSSFeeds. 17:40.21 FORK(25854) --- fork finished for 'RSSFeeds' --- 17:48.15 Chans: (ghostbot) in:#ghostscript 17:48.20 tor8: You've not updated generate.bat, right? 17:50.54 ok, I've done it. 17:55.45 tor8: 2>d:\cvs\artifex\mupdf.git\source\fitz\ucdn.c(94) : warning C4018: '<' : signed/unsigned mismatch 17:55.47 2>d:\cvs\artifex\mupdf.git\source\fitz\ucdn.c(96) : warning C4018: '<=' : signed/unsigned mismatch 17:55.53 Those aren't new, but... 17:58.58 >>> join/#ghostscript sebras (~sebras@casper3.ghostscript.com) 18:01.13 Seen: Flushed 2 entries. 18:03.41 Chans: (ghostbot) in:#ghostscript 18:06.43 Where has crypt_pkcs7.c gone ? 18:08.15 --- Saved uptime records. 18:09.05 Into pdf. 18:10.43 FORK(19063) --- fork starting for 'RSSFeeds', PID == 19063, bot_pid == 31304 --- 18:10.44 FORK(19063) !ERROR! cannot load my module: RSSFeeds 18:10.44 FORK(19063) fork: took 1s for RSSFeeds. 18:10.44 FORK(19063) --- fork finished for 'RSSFeeds' --- 18:12.14 Slightly odd that for windows I build source files from platform/x11 18:12.28 platform/shared ? 18:14.39 tor8, paulgardiner: Currently the win32 project file only includes the pkcs7 stuff in the tools that need it, not in the mupdf lib itself. Is there a reason for that ? Would it not be neater to have it in the mupdf lib? 18:16.18 >>> talexb has signed off IRC (Quit: Leaving) [#ghostscript] 18:20.05 Chans: (ghostbot) in:#ghostscript 18:22.37 tor8: win32 fixes on robin/shuffle 18:23.49 actually, I think I broke the openssl stuff. will fix it. 18:24.34 after I mow the lawn :( 18:27.17 tor8: are you there? 18:27.50 do you have a good version of the mupdf logo with transparent background? 18:28.19 or Robin_Watts 18:28.38 or is the vector file around someplace for the logo 18:31.37 henrys: do you know where I can get a vector version of the logo? 18:32.02 >>> Weezey has signed off IRC () [#ghostscript] 18:35.45 Robin_Watts: ping 18:36.39 Chans: (ghostbot) in:#ghostscript 18:38.16 i think he is mowing the lawn 18:38.25 maybe everyone is 18:41.05 FORK(1337) --- fork starting for 'RSSFeeds', PID == 1337, bot_pid == 31304 --- 18:41.06 FORK(1337) !ERROR! cannot load my module: RSSFeeds 18:41.06 FORK(1337) fork: took 1s for RSSFeeds. 18:41.06 FORK(1337) --- fork finished for 'RSSFeeds' --- 18:43.40 no I don't I'll ask Miles for you if you like. 18:43.58 mvrhel_laptop: ^^^ 18:44.16 henrys: oh. I can ask him 18:44.29 alright 18:47.59 henrys: I re-ran the mupdf/fuzzing tests and found 3 segfaults in the current build, all in jbig/j2k decoders. I've assigned them to you. 18:49.04 marcosw:something for zeniko to work on he didn't get enough problems last time because they were all in ghostscript. 18:53.43 Chans: (ghostbot) in:#ghostscript 18:55.33 mvrhel_laptop: http://ghostscript.com/~tor/mupdf-logo/ 18:55.47 awesome. thanks tor8 18:55.58 mvrhel_laptop: if you're looking for an app icon there's a 512x512 version in the 'ios' directory 18:56.35 tor8: oh ok. that might work too. I need something that I can put on a transparent background and get proper aliasing 18:56.43 with the background 18:57.09 mvrhel_laptop: the simplified-logo.xcf has high res bitmaps in layers you can use gimp to make it transparent 18:57.21 ok 18:57.24 it's the one I used for the app icons 18:57.28 thanks 18:57.55 I am passing the windows certification tests now, after fixing a bunch of stuff. now trying to make things look pretty 18:58.22 mvrhel_laptop: http://git.ghostscript.com/?p=mupdf.git;a=blob;f=ios/iTunesArtwork.png;h=45aec0b78c35ad190c53476268b956076e59baa7;hb=HEAD 18:59.03 henrys: I saw that the other jbig2/j2k issues had all been assigned to you, so did the same for the new ones as well. 18:59.07 that's the app icon we use for both ios and android 18:59.14 ok. I will do the same 18:59.27 mvrhel_laptop: I really ought to get a win8 device to test your app 18:59.40 although, I will make the gray transparent 18:59.54 as this will be similar to what the apps icons are like in win8 19:00.02 yeah, that probably fits the win8 theme better 19:00.03 marcosw:yes that's fine. I'll change the who_owns_what document soon 19:00.11 how will the black outline work on the background though? 19:00.21 is the app backdrop colored? 19:00.28 yes. it is a darker gray 19:00.42 okay, that ought to work. as long as it's not black-on-black :) 19:00.47 and it will have MuPDF in white letters at the bottom 19:00.52 no it should be ok 19:01.33 tor8: you can install win8 with vmware i think on your machine 19:01.43 Seen: Flushed 5 entries. 19:02.14 mvrhel_laptop: I'd still need a proper license though? 19:02.19 well, yes 19:02.34 its not freeware 19:02.38 :) 19:02.39 miles will pay for that though, I don't doubt :) 19:02.47 >>> ray_laptop has signed off IRC (Ping timeout: 260 seconds) [#ghostscript] 19:03.01 (proper, as opposed to upgrade) 19:03.03 yes, miles will gladly pay for it 19:04.42 mvrhel_laptop: back. 19:04.47 marcosw: pong 19:04.58 Robin_Watts: tor8 took care of me 19:06.03 mvrhel_laptop: ok. I have a vector version of the MuPDF logo here that I knocked up. 19:06.09 It's not perfect, but it's close. 19:06.35 oh really. well let me have that one too 19:06.37 Robin_Watts: you saw the link to the original logo SVG? 19:06.37 please 19:06.44 tor8: I have win8 running under VMware player. I bought a copy for 65-70 quid. 19:06.48 or is that the one you based it off 19:07.16 tor8: I did not. I did mine before I knew about the 512x512 one 19:07.27 Robin_Watts: the xcf is even bigger than the 512x512 19:07.48 non-antialiased render of the svg cropped to the app icon viewport 19:07.54 tor8: Where is the svg one ? 19:08.12 http://ghostscript.com/~tor/mupdf-logo/ has both svg and high-res xcf 19:08.33 the logo does weird stuff with the white areas, so it's not usable as is on a transparent background 19:08.33 --- Saved uptime records. 19:08.38 What's xcf ? 19:08.42 gimp's format 19:08.51 Ah. 19:08.58 layered bitmaps 19:09.16 I could tweak my one (done in xara) to match. 19:09.36 Chans: (ghostbot) in:#ghostscript 19:11.17 FORK(8011) --- fork starting for 'RSSFeeds', PID == 8011, bot_pid == 31304 --- 19:11.18 FORK(8011) !ERROR! cannot load my module: RSSFeeds 19:11.18 FORK(8011) fork: took 1s for RSSFeeds. 19:11.18 FORK(8011) --- fork finished for 'RSSFeeds' --- 19:12.45 ah. the svg one is working out nicely 19:13.52 oops. the white reflections in the handle are transparent though 19:14.00 tor8: those really should be white yes? 19:14.16 they should 19:14.22 mvrhel_laptop: yeah, that's what I meant earlier when I said the svg has funky white area 19:14.23 s 19:14.41 ok 19:14.53 the xcf should be high res enough for anything you need 19:15.14 if you want I can make it a png? 19:15.32 tor8: OK. robin/shuffle done now, I think. 19:15.37 that would be easier for me. I dont have gimp installed. 19:16.08 mvrhel_laptop: give me a few minutes 19:20.47 mvrhel_laptop: http://ghostscript.com/~tor/mupdf-logo/mupdf-simplified-logo.png 19:21.05 tor8: ok great. thanks 19:22.12 that will do the job 19:22.31 mvrhel_laptop: Do you want it as an icon? 19:22.40 i.e on a background rectangle? 19:23.14 Robin_Watts: the icons in win8 in the tiles have transparent backgrounds. this is what I wanted 19:23.24 they are placed over a gray backdrop 19:23.35 in the tiles 19:24.31 OK. For Android I needed: http://ghostscript.com/~robin/muPDFlogo.png 19:24.54 not here . that would look odd in win8 19:25.04 Chans: (ghostbot) in:#ghostscript 19:25.38 well, I've updated my .xar so I can produce others easily if required. 19:41.39 Chans: (ghostbot) in:#ghostscript 19:42.07 FORK(6423) --- fork starting for 'RSSFeeds', PID == 6423, bot_pid == 31304 --- 19:42.08 FORK(6423) !ERROR! cannot load my module: RSSFeeds 19:42.08 FORK(6423) fork: took 1s for RSSFeeds. 19:42.08 FORK(6423) --- fork finished for 'RSSFeeds' --- 19:56.32 ok. logos all updated and look good. testing certification on the arm device now to make sure that is fine too 19:57.21 need to eat lunch 19:57.23 bbiab 19:58.03 Chans: (ghostbot) in:#ghostscript 20:01.49 Seen: Flushed 3 entries. 20:04.12 >>> tor8 has signed off IRC (Quit: tor8) [#ghostscript] 20:09.03 --- Saved uptime records. 20:10.41 !WARN! PERL: readdir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 862. 20:10.41 !WARN! PERL: closedir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 869. 20:11.39 Robin_Watts: ok. I have pushed my updates that I needed before doing a store submission if you want to review 20:12.29 FORK(25895) --- fork starting for 'RSSFeeds', PID == 25895, bot_pid == 31304 --- 20:12.30 FORK(25895) !ERROR! cannot load my module: RSSFeeds 20:12.30 FORK(25895) fork: took 1s for RSSFeeds. 20:12.30 FORK(25895) --- fork finished for 'RSSFeeds' --- 20:14.57 Chans: (ghostbot) in:#ghostscript 20:19.44 >>> join/#ghostscript ray_laptop (~chatzilla@rrcs-64-183-45-163.west.biz.rr.com) 20:27.52 mvrhel_laptop: I think that most of what is needed to do the color/monochrome detection for MultipleDataSources in the clist is there. Just a little refactoring and corrections. 20:28.16 ray_laptop: ok that is good 20:28.53 Robin_Watts: http://msdn.microsoft.com/en-us/library/windows/apps/hh694069.aspx 20:29.02 mvrhel_laptop: when trying to explain to the customer why we needed extra buffers and what would be needed, I stepped into the code and found out that buffers were already being allocated 20:29.17 do we have a current ECCN number 20:29.28 ray_laptop: ah that is good 20:31.11 Chans: (ghostbot) in:#ghostscript 20:31.20 mvrhel_laptop: and the 'row_has_color' can handle separated planes if the 'spread' is calculated correctly (and the unpack done outside this function where we have access to the 'planes') 20:39.57 >>> chrisl materializes into chrisl_away 20:41.09 >>> sojic has signed off IRC (Remote host closed the connection) [#ghostscript] 20:42.51 FORK(11317) --- fork starting for 'RSSFeeds', PID == 11317, bot_pid == 31304 --- 20:42.52 FORK(11317) !ERROR! cannot load my module: RSSFeeds 20:42.52 FORK(11317) fork: took 1s for RSSFeeds. 20:42.52 FORK(11317) --- fork finished for 'RSSFeeds' --- 20:47.15 bbiaw 20:47.25 Chans: (ghostbot) in:#ghostscript 20:58.41 >>> join/#ghostscript tor8 (~tor@c-bd7871d5.04-50-6c756e10.cust.bredbandsbolaget.se) 21:02.03 Seen: Flushed 2 entries. 21:02.53 Chans: (ghostbot) in:#ghostscript 21:09.25 --- Saved uptime records. 21:13.03 FORK(7508) --- fork starting for 'RSSFeeds', PID == 7508, bot_pid == 31304 --- 21:13.04 FORK(7508) !ERROR! cannot load my module: RSSFeeds 21:13.04 FORK(7508) fork: took 1s for RSSFeeds. 21:13.04 FORK(7508) --- fork finished for 'RSSFeeds' --- 21:13.08 >>> tor8 has signed off IRC (Quit: tor8) [#ghostscript] 21:18.17 Chans: (ghostbot) in:#ghostscript 21:21.19 >>> join/#ghostscript sojic (~sojic@92.55.124.152) 21:34.03 Chans: (ghostbot) in:#ghostscript 21:43.05 FORK(31188) --- fork starting for 'RSSFeeds', PID == 31188, bot_pid == 31304 --- 21:43.06 FORK(31188) !ERROR! cannot load my module: RSSFeeds 21:43.06 FORK(31188) fork: took 1s for RSSFeeds. 21:43.06 FORK(31188) --- fork finished for 'RSSFeeds' --- 21:49.49 ircCheck: possible lost in space; checking.Wed Jun 19 21:49:49 2013 21:49.49 >ghostbot< TEST 21:49.49 IRCTEST: Yes, we're alive. 21:54.36 >>> paulgardiner has signed off IRC (Quit: ChatZilla 0.9.90 [Firefox 21.0/20130511120803]) [#ghostscript] 21:58.25 >>> ray_laptop has signed off IRC (Ping timeout: 248 seconds) [#ghostscript] 21:59.25 >>> join/#ghostscript wachunga (d1118701@gateway/web/freenode/ip.209.17.135.1) 22:05.53 Chans: (ghostbot) in:#ghostscript 22:09.39 --- Saved uptime records. 22:13.07 FORK(23526) --- fork starting for 'RSSFeeds', PID == 23526, bot_pid == 31304 --- 22:13.08 FORK(23526) !ERROR! cannot load my module: RSSFeeds 22:13.08 FORK(23526) fork: took 1s for RSSFeeds. 22:13.08 FORK(23526) --- fork finished for 'RSSFeeds' --- 22:22.07 Chans: (ghostbot) in:#ghostscript 22:27.01 >>> join/#ghostscript tor8 (~tor@c-bd7871d5.04-50-6c756e10.cust.bredbandsbolaget.se) 22:38.13 Chans: (ghostbot) in:#ghostscript 22:43.27 FORK(22672) --- fork starting for 'RSSFeeds', PID == 22672, bot_pid == 31304 --- 22:43.28 FORK(22672) !ERROR! cannot load my module: RSSFeeds 22:43.28 FORK(22672) fork: took 1s for RSSFeeds. 22:43.28 FORK(22672) --- fork finished for 'RSSFeeds' --- 22:44.53 >>> wachunga has signed off IRC (Quit: Page closed) [#ghostscript] 22:45.47 >>> sojic has signed off IRC (Remote host closed the connection) [#ghostscript] 22:51.13 >>> join/#ghostscript sojic (~sojic@92.55.124.152) 22:54.07 Chans: (ghostbot) in:#ghostscript 22:54.07 ircCheck: possible lost in space; checking.Wed Jun 19 22:54:07 2013 22:54.07 >ghostbot< TEST 22:54.07 IRCTEST: Yes, we're alive. 23:10.16 --- Saved uptime records. 23:10.16 Chans: (ghostbot) in:#ghostscript 23:13.34 FORK(24252) --- fork starting for 'RSSFeeds', PID == 24252, bot_pid == 31304 --- 23:13.35 FORK(24252) !ERROR! cannot load my module: RSSFeeds 23:13.35 FORK(24252) fork: took 2s for RSSFeeds. 23:13.35 FORK(24252) --- fork finished for 'RSSFeeds' --- 23:13.36 mvrhel_laptop: My reading of that would be that we do NOT need an ECCN. 23:13.49 oh ok 23:13.58 because all our use of encryption is for the list of tasks there. 23:14.38 yes. I see now 23:14.45 e.g. Authentication 23:14.52 digital signatures etc 23:15.01 I should have read that more carefully 23:15.07 sorry to have bothered you with it 23:17.00 no worrie.s 23:17.21 Robin_Watts: we do decryption of encrypted file contents though... 23:17.42 That's password encryption in my book. 23:18.16 and/or authentication/drm. 23:20.54 right. drm would cover it, I guess. 23:22.18 mvrhel_laptop: That commit looks OK to me. Want me to push it ? 23:22.29 Robin_Watts: let me add one little thing to it 23:22.43 mvrhel_laptop: A newline to the end of status.h ? :) 23:23.00 and mupdfwinrt.vcxproj.filters ? 23:23.04 I can do that too, plus I need to remove image_md5.c from the project 23:23.25 and Package.appmanifest ? 23:23.56 Robin_Watts: so those files are generated automatically. you want me to go in and edit them with a new line at the end? 23:24.05 in that case, no. 23:24.37 had they been manually edited we could have stopped git whinging, but not if they are autogenerated :) 23:26.07 Chans: (ghostbot) in:#ghostscript 23:26.23 well, they are generated based upon a gui like file that I edit 23:26.31 at least in the case of Package.appmanifest 23:27.04 mupdfwinrt.vcxproj.filters is a split off from the old vcproj file in older visual studio 23:27.19 and is generated based upon what you have in the solution 23:27.30 and the project in the solution that is 23:27.50 Robin_Watts: ok I pushed the appended one 23:28.24 did the win32 project get updated from the removal of image_md5.c 23:28.28 I did not see it in the commits 23:29.20 Possibly not. 23:29.42 Robin_Watts: so I heard back from my friend at MS 23:29.49 he said we need to do this 23:29.51 http://msdn.microsoft.com/en-us/library/windowsphone/help/jj215905(v=vs.105).aspx 23:29.54 about the PDF Reader app 23:29.56 but I've just completely rebuilt it for the shuffle branch, so hopefully that'll get pushed soon, and everything will need to change again :) 23:30.16 item 1 23:30.22 right. 23:30.46 henrys: who do we want to take care of that? 23:31.26 IMHO, we should send them a direct message stating that we believe they use MuPDF, and saying that if we don't hear back from them, we will be considering what legal action to take. 23:31.37 right 23:31.42 Then if we don't get a response, we do the takedown thing. 23:32.04 cos if they fail to respond to that, they won't respond to anything. 23:32.29 I had not gotten a response from them asking for the code (since it is supposedly GPL) 23:32.59 I will pass this along to Miles so that he is aware of it and push on 23:33.07 Miles is in surgery today. 23:33.27 So I suspect he may not be operating at full speed for a few days. 23:34.38 mvrhel: pushed to golden. 23:34.46 Robin_Watts: Thanks 23:34.55 oh his shoulder 23:36.31 mvrhel_laptop: yeah. 23:36.50 mvrhel_laptop: I'm working on making mupdf support progressive display of files as they download. 23:36.57 nice 23:37.15 Is there a mechanism for working on a file as it is downloaded under winrt ? 23:37.41 or would we need to write our own http fetcher for that as part of the app? 23:38.28 The current plan is that you'll wrap the downloading thing into a slightly modified fz_stream. 23:39.18 When you try to open it, mupdf will try to read from the file. If it reads off the end of the current stream, the stream code throws an error of a particular type. 23:39.34 That bubbles up and returns to the app. 23:39.52 The app can then check the type of the error it gets, and knows to retry when more data has arrived. 23:40.51 How utterly alien does that sound? :) 23:42.25 Chans: (ghostbot) in:#ghostscript 23:44.03 FORK(26044) --- fork starting for 'RSSFeeds', PID == 26044, bot_pid == 31304 --- 23:44.04 FORK(26044) !ERROR! cannot load my module: RSSFeeds 23:44.04 FORK(26044) fork: took 1s for RSSFeeds. 23:44.04 FORK(26044) --- fork finished for 'RSSFeeds' --- 23:47.32 >>> sojic has signed off IRC (Remote host closed the connection) [#ghostscript] 23:49.22 >>> tor8 has signed off IRC (Quit: tor8) [#ghostscript] 23:50.29 >>> mrdocs has signed off IRC (Ping timeout: 248 seconds) [#ghostscript] 23:52.03 alien enough that it's scared mvhrel off, it seems :) 23:52.22 Bedtime for me. I'll read logs in the mornings in case you (or anyone else) has any thoughts. 23:52.49 >>> join/#ghostscript sojic (~sojic@92.55.124.152) 23:58.01 Chans: (ghostbot) in:#ghostscript