00:02.17 Opened logfile log/20131030. 00:02.17 ray_laptop: Could this be related to the fact that we see "leaking" profiles with NumRenderingThreads? 00:05.31 Chans: (ghostbot) in:#ghostscript 00:15.52 FORK(10230) --- fork starting for 'RSSFeeds', PID == 10230, bot_pid == 9787 --- 00:15.53 FORK(10230) !ERROR! cannot load my module: RSSFeeds 00:15.53 FORK(10230) fork: took 2s for RSSFeeds. 00:15.53 FORK(10230) --- fork finished for 'RSSFeeds' --- 00:19.18 mvrhel_laptop: I see the following pattern (looking at the large 550Kb chunks): 00:19.20 [a+]gs_malloc(gsicc_load_profile)(557168) = 0x3aa0058: OK, used=18849477, max=19434641 00:19.22 [a+]gs_malloc(lcms)(557168) = 0x3b30058: OK, used=19410025, max=19434641 00:19.23 [a+]gs_malloc(gsicc_load_profile)(557168) = 0x3bc0058: OK, used=19987681, max=19987681 00:19.25 [a+]gs_malloc(lcms)(557168) = 0x3c50058: OK, used=20548229, max=20548229 00:19.26 [a+]gs_malloc(gsicc_load_profile)(557168) = 0x3ce0058: OK, used=21125885, max=21125885 00:19.28 [a+]gs_malloc(lcms)(557168) = 0x3d70058: OK, used=21686433, max=21686433 00:19.29 [a-]gs_free(rc_free_icc_profile) 0x3ce0058(557168) 00:19.31 [a-]gs_free(lcms) 0x3d70058(557168) 00:19.32 [a+]gs_malloc(gsicc_load_profile)(557168) = 0x3ce0058: OK, used=21125885, max=21711049 00:19.34 [a+]gs_malloc(lcms)(557168) = 0x3d70058: OK, used=21686433, max=21711049 00:19.35 [a+]gs_malloc(gsicc_load_profile)(557168) = 0x3e00058: OK, used=22243945, max=22243945 00:19.37 [a+]gs_malloc(lcms)(557168) = 0x3e90058: OK, used=22804493, max=22804493 00:19.38 [a-]gs_free(rc_free_icc_profile) 0x3e00058(557168) 00:19.40 [a-]gs_free(lcms) 0x3e90058(557168) 00:19.41 In this snippet 0x3750058 gets allocated, then 0x3b30058 followed by 0x3bc0058, 0x3c50058, 0x3ce0058 and 0x3d70058. The onliest one I see getting freed in the sequence is 0x3ce0058. Since each of these is 550Kb, no wonder there's a problem. I _do_ see a lot of these getting freed by a GC later, so it seems we aren't managing these properly 00:19.44 * ray_laptop/#ghostscript floods IRC :-) 00:20.51 Chans: (ghostbot) in:#ghostscript 00:21.56 after the GC, it seems that the usage goes from 323,948,769 down to 26,744,325.! The garbage truck must have been really full :-) 00:22.52 Robin_Watts: sorry. I was putting together that flood for mvrhel_laptop. Maybe email might have been better. :-/ 00:23.27 Robin_Watts: Do we see a lot of leaked profiles during rendering. I thought it was only one or two ? 00:26.07 ray_laptop: For tiger it's 3 blocks per band. 00:26.19 but tiger hardly stresses the color system. 00:26.36 Robin_Watts: OK, but after each band, those get freed. 00:28.44 ray_laptop: Right, but what if in a more complex file than tiger, we're leaking more blocks. 00:28.45 Robin_Watts: please try tests_private/pdf/PDF_1.7_ATS/tests_private/pdf/AIX361DC_Save.pdf if you want, but all of the problems I see are during *writing* the clist 00:29.02 oh, ok. I was just mentioning it as an idea. 00:29.15 That does sound different. 00:31.19 The "used" at Outputpage start is 616,549,476 and at Outputpage end it is 618,125,584 and there are no GC's during print_page 00:32.05 Robin_Watts: and I don't mind questions. Mostly this is for mvrhel_laptop when he consults the logs 00:32.30 and me answering you helps keep him from some dead-ends 00:32.39 maybe 00:34.17 mvrhel_laptop: I am running HEAD debug build on Windows with: debugbin/gswin32c -r600 -dBandHeigt=128 -sDEVICE=ppmraw -o x.ppm -dPDFDEBUG -Z:a c:/Artifex/tests_private/pdf/PDF_1.7_ATS/AIX361DC_Save.pdf 00:34.42 the -Za is noisy, but tracks the large allocations well 00:35.48 I have the -Z: so I can separate parsing and rendering in the log. I capture the output with: > log 2>&1 00:36.28 Chans: (ghostbot) in:#ghostscript 00:36.35 ray_laptop: You know you misspelt BandHeight there, right? 00:36.39 mvrhel_laptop: I am going to see if there are other things I can see leaking. 00:36.45 Robin_Watts: oops. 00:36.55 just in case that is significant 00:37.09 but it shouldn't make a difference during clist writing. 00:37.19 I'll re-run it 00:37.27 Bah. No SSE3 support in VS2005 :( 00:38.07 that's why it had so many bands (729) 00:38.36 Robin_Watts: so what? Is anybody running anything older than 2008 ? 00:38.45 I run 2005 routinely. 00:38.53 (although I still have MSVC 6) 00:39.01 It's important that releases are done with VS2005. 00:39.25 cos VS2008 binaries don't run on anything older than XP SP1, if memory serves. 00:39.25 Robin_Watts: so why do you want (need) SSE3 ? 00:39.38 With SSE3 I can save a few cycles. 00:39.50 so I have some #ifdefs in there. 00:40.13 might be. I have an old machine I can check. Are you concerned about Windows 95 ?? 00:40.45 ray_laptop: Frankly I don't care. But 801 might not have SSE3 available in their targets. 00:40.54 so I'll leave the ifdef stuff in there for now. 00:40.55 Robin_Watts: true. 00:41.06 Robin_Watts: can't that be a runtime check ? 00:41.26 iirc, there's a call to check SSE level 00:42.10 ray_laptop: It could be a runtime check, but unless we really need them, runtime checks are bad. 00:44.01 >>> join/#ghostscript Noldorin (~noldorin@unaffiliated/noldorin) 00:44.12 Robin_Watts: BTW, the max_used with -dBandHeight=128 (52 bands) is 894,485,169 (slightly worse) and at Outputpage start it is the same, so the problem is totally during parsing 00:44.23 --- Saved uptime records. 00:44.23 Seen: Flushed 2 entries. 00:44.43 cool. 00:44.54 well, maybe :-/ 00:45.01 So with a single band, same issue? 00:45.41 Does it need to be 600dpi? 00:45.44 I haven't tried, but I will -- the allocation for the buffer will be larger, of course 00:45.54 Robin_Watts: that's there params 00:46.02 s/there/their/ 00:46.31 FORK(15178) --- fork starting for 'RSSFeeds', PID == 15178, bot_pid == 9787 --- 00:46.32 FORK(15178) !ERROR! cannot load my module: RSSFeeds 00:46.32 FORK(15178) fork: took 1s for RSSFeeds. 00:46.32 FORK(15178) --- fork finished for 'RSSFeeds' --- 00:46.40 If it was my problem I'd try to whittle everything down as small as possible, cos smaller things fit in my small brain more easily :) 00:47.27 >>> paulgardiner has signed off IRC (Remote host closed the connection) [#ghostscript] 00:47.55 Robin_Watts: as expected. max_used at Outputpage start time is: 1,398,485,170 00:48.13 !!!! :-0 00:48.33 That's with 1 band at 600dpi? 00:48.57 yep 00:49.10 testing page mode now. Should be similar 00:49.47 oh, the problem shows up in page mode too? 00:50.11 if it's during clist writing, why not (don't know yet) 00:51.40 of course, it could be a *lot* worse since the PDF 14 transparency will be in page mode. This is a pretty awful file. 00:51.50 and it is taking a LOT longer. 00:52.01 Chans: (ghostbot) in:#ghostscript 00:53.36 OK. in page mode max is: 889,346,965 00:54.49 and that happens before "Outputpage start time" as expected 00:55.31 although the larger max for a single band is somewhat inconguous 00:58.16 So it's not a clist problem. I'd find that a relief personally :) 00:58.47 I don't think I spelled incongruous correctly 00:58.48 Is the size of the leak resolution independent ? 01:01.34 I'll check... still collecting logs for BandHeight=128 01:01.45 OK, running -r72 page mode... 01:03.15 wow! page mode 72 dpi, max = 1,820,165,519 01:04.07 although, bear in mind that page mode allocates whatever size transparency buffers are needed, not constrained to a band 01:04.28 how can 72dpi be larger than 600dpi? 01:04.38 889Meg vs 1.8Gig ? 01:05.51 -r72 -dBandHeight=128 has a max at Outputpage start of 833,667,051 01:06.41 oh, I see. page mode > clist. gotcha. 01:06.56 retesting page mode 600 01:07.41 rats. Just thought of a better way to do this last SSE case. 01:07.51 Chans: (ghostbot) in:#ghostscript 01:07.54 will look at it tomorrow. I should go to bed. Have a good night ray. 01:08.17 you, too, Robin_Watts 01:15.18 the supposed page mode 600 was really 729 bands. I had used -dMaxBitmap=500m, but with transparency that used clist mode, and I didn't use -dBufferSpace=500m which would have given me 6 bands. 01:15.40 but the page mode 72 dpi is conclusive that it _is_ a parsing time problems 01:16.00 back to the pad+alignment debug... 01:17.12 FORK(32240) --- fork starting for 'RSSFeeds', PID == 32240, bot_pid == 9787 --- 01:17.13 FORK(32240) !ERROR! cannot load my module: RSSFeeds 01:17.13 FORK(32240) fork: took 2s for RSSFeeds. 01:17.13 FORK(32240) --- fork finished for 'RSSFeeds' --- 01:21.46 >>> ray_laptop has signed off IRC (Ping timeout: 240 seconds) [#ghostscript] 01:24.21 Chans: (ghostbot) in:#ghostscript 01:28.33 >>> join/#ghostscript marcosw (~marcosw@c-98-207-131-178.hsd1.ca.comcast.net) 01:33.34 >>> join/#ghostscript MedDev (~MDev@68-187-73-233.dhcp.unas.ut.charter.com) 01:40.21 Chans: (ghostbot) in:#ghostscript 01:44.41 Seen: Flushed 2 entries. 01:44.51 --- Saved uptime records. 01:47.22 FORK(16467) --- fork starting for 'RSSFeeds', PID == 16467, bot_pid == 9787 --- 01:47.23 FORK(16467) !ERROR! cannot load my module: RSSFeeds 01:47.23 FORK(16467) fork: took 2s for RSSFeeds. 01:47.23 FORK(16467) --- fork finished for 'RSSFeeds' --- 01:54.44 >>> join/#ghostscript akk (~akkana@adsl-69-105-235-1.dsl.pltn13.pacbell.net) 01:56.21 Chans: (ghostbot) in:#ghostscript 02:02.28 >>> MedDev has signed off IRC (Ping timeout: 240 seconds) [#ghostscript] 02:12.51 Chans: (ghostbot) in:#ghostscript 02:13.09 >>> join/#ghostscript ray_laptop (~chatzilla@cpe-76-171-54-81.socal.res.rr.com) 02:14.21 >>> Noldorin has signed off IRC (Quit: Computer has gone to sleep.) [#ghostscript] 02:17.42 FORK(4504) --- fork starting for 'RSSFeeds', PID == 4504, bot_pid == 9787 --- 02:17.43 FORK(4504) !ERROR! cannot load my module: RSSFeeds 02:17.43 FORK(4504) fork: took 2s for RSSFeeds. 02:17.43 FORK(4504) --- fork finished for 'RSSFeeds' --- 02:18.31 ircCheck: possible lost in space; checking.Wed Oct 30 02:18:31 2013 02:18.31 >ghostbot< TEST 02:18.31 IRCTEST: Yes, we're alive. 02:23.36 >>> join/#ghostscript MedDev (~MDev@68-187-73-233.dhcp.unas.ut.charter.com) 02:28.22 >>> marcosw has signed off IRC (Quit: marcosw) [#ghostscript] 02:28.42 Chans: (ghostbot) in:#ghostscript 02:30.24 >>> MedDev has signed off IRC (Ping timeout: 246 seconds) [#ghostscript] 02:38.24 >>> join/#ghostscript MedDev (~MDev@68-187-73-233.dhcp.unas.ut.charter.com) 02:41.49 >>> ray_laptop has signed off IRC (Ping timeout: 240 seconds) [#ghostscript] 02:43.25 !WARN! PERL: readdir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 862. 02:43.25 !WARN! PERL: closedir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 869. 02:44.05 Chans: (ghostbot) in:#ghostscript 02:45.35 --- Saved uptime records. 02:48.06 FORK(20034) --- fork starting for 'RSSFeeds', PID == 20034, bot_pid == 9787 --- 02:48.07 FORK(20034) !ERROR! cannot load my module: RSSFeeds 02:48.07 FORK(20034) fork: took 2s for RSSFeeds. 02:48.07 FORK(20034) --- fork finished for 'RSSFeeds' --- 02:51.04 >>> Fandekasp has signed off IRC (Read error: No route to host) [#ghostscript] 02:51.35 >>> join/#ghostscript Fandekasp (~Fandekasp@27-32-19-26.static.tpgi.com.au) 02:59.55 Chans: (ghostbot) in:#ghostscript 03:10.04 >>> MedDev has signed off IRC (Ping timeout: 264 seconds) [#ghostscript] 03:15.45 Chans: (ghostbot) in:#ghostscript 03:18.26 FORK(9382) --- fork starting for 'RSSFeeds', PID == 9382, bot_pid == 9787 --- 03:18.27 FORK(9382) !ERROR! cannot load my module: RSSFeeds 03:18.27 FORK(9382) fork: took 2s for RSSFeeds. 03:18.27 FORK(9382) --- fork finished for 'RSSFeeds' --- 03:20.55 ircCheck: possible lost in space; checking.Wed Oct 30 03:20:55 2013 03:20.55 >ghostbot< TEST 03:20.55 IRCTEST: Yes, we're alive. 03:22.19 >>> join/#ghostscript tkamppeter__ (~till@p5480AA5F.dip0.t-ipconnect.de) 03:23.01 >>> tkamppeter_ has signed off IRC (Read error: Operation timed out) [#ghostscript] 03:26.09 >>> akk has signed off IRC (Quit: +++) [#ghostscript] 03:31.19 Chans: (ghostbot) in:#ghostscript 03:35.43 >>> join/#ghostscript marcosw (~marcosw@c-98-207-109-212.hsd1.ca.comcast.net) 03:45.59 --- Saved uptime records. 03:47.02 >>> join/#ghostscript ray_laptop (~chatzilla@rrcs-64-183-45-163.west.biz.rr.com) 03:47.52 Chans: (ghostbot) in:#ghostscript 03:48.32 FORK(26251) --- fork starting for 'RSSFeeds', PID == 26251, bot_pid == 9787 --- 03:48.33 FORK(26251) !ERROR! cannot load my module: RSSFeeds 03:48.33 FORK(26251) fork: took 1s for RSSFeeds. 03:48.33 FORK(26251) --- fork finished for 'RSSFeeds' --- 04:18.59 FORK(14994) LOG: last message repeated 3 times 04:18.59 FORK(14994) --- fork starting for 'RSSFeeds', PID == 14994, bot_pid == 9787 --- 04:19.00 FORK(14994) !ERROR! cannot load my module: RSSFeeds 04:19.00 FORK(14994) fork: took 1s for RSSFeeds. 04:19.00 FORK(14994) --- fork finished for 'RSSFeeds' --- 04:24.09 LOG: last message repeated 3 times 04:24.09 ircCheck: possible lost in space; checking.Wed Oct 30 04:24:09 2013 04:24.09 >ghostbot< TEST 04:24.09 IRCTEST: Yes, we're alive. 04:31.54 >>> join/#ghostscript plinnell (~mrdocs@opensuse/member/mrdocs) 04:34.37 Chans: (ghostbot) in:#ghostscript 04:40.08 hmm... it appears that ghostbot might be down 04:40.18 restarting it... 04:40.49 Opened logfile log/20131030. 04:40.49 --- Started logging. 04:40.49 Loaded infobot.lang (77 items) 04:40.49 Loaded infobot.servers (1 servers) 04:40.49 USERFILE: Loaded: 0 users, 0 bans, 0 ignore 04:40.49 CHANFILE: Loaded: 1 chans 04:40.49 Loading MyModules... 04:40.49 Loaded Topic 04:40.49 Loaded Uptime 04:40.49 Loaded News 04:40.49 Loaded RootWarn 04:40.49 Loaded botmail 04:40.49 Loaded OnJoin 04:40.49 Module: Runtime: Loaded/Total [6/7] 04:40.49 Created shared memory (shm) key: [131076] 04:40.49 Opened SQLite connection to localhost 04:40.49 checkTables: creating new table connections... 04:40.50 LOG: Throttling. 04:40.49 Setup: 7 factoids. 04:40.50 Initial memory usage: 15788 KiB 04:40.50 ------------------------------------------------------- 04:40.51 Connecting to port 6667 of server irc.freenode.net (128.237.157.136) as ghostbot ... 04:40.51 starting main loop 04:40.51 -adams.freenode.net- *** Looking up your hostname... 04:40.51 -adams.freenode.net- *** Checking Ident 04:40.51 -adams.freenode.net- *** Found your hostname 04:40.58 -adams.freenode.net- *** No Ident response 04:40.58 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! 04:40.58 !!! Ok. Now type '/msg ghostbot PASS ' to get master access through DCC CHAT. 04:40.58 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! 04:40.58 End of motd. Now lets join some channels... 04:40.58 There are 207 users and 77721 invisible on 29 servers 04:40.58 29 IRC Operators online 04:40.58 6 unknown connection(s) 04:40.58 50682 channels formed 04:40.58 I have 3525 clients and 1 servers 04:40.58 >>> mode [+i] by ghostbot 04:41.04 >>> mode [+w] by ghostbot 04:41.44 --- Saved uptime records. 04:41.44 config (ghostbot): auto-setting param{chanlimitcheckInterval} = 10 04:41.44 config (ghostbot): auto-setting param{floodCycle} = 60 04:41.46 Chans: (ghostbot) join:#ghostscript 04:41.46 !FIXME! ircCheck: found channels to join! #ghostscript 04:41.46 joining #ghostscript 04:41.46 Schedulers: 22 will be running. 04:41.46 >>> join/#ghostscript ghostbot (~ghostbot@casper3.ghostscript.com) 04:41.46 >>> topic/#ghostscript is Ghostscript development and discussion | live channel log at http://ghostscript.com/irclogs/ | Info at http://www.ghostscript.com 04:41.46 >>> set by ray_laptop!~chatzilla@69.233.158.225 at Tue Aug 23 15:22:21 2011 04:41.46 #ghostscript: sync in 0.125s. 04:41.46 #ghostscript: [1 voice || 23 total] 04:41.46 ChanServ ==> Requesting ops for #ghostscript. (chanServCheck) 04:41.46 >ChanServ< OP #ghostscript 04:41.46 ChanServ: <== 'You are not authorized to perform this operation.'. 04:41.56 Chans: (ghostbot) in:#ghostscript 04:41.56 time taken to join all chans: 1m; rate: 6.0 sec/join 04:41.58 OK, seeing if that fixes it. 04:42.26 I suspect that doing edits on the logs messes up infobot 04:42.48 If it's OK, I should see this is a few 04:45.46 ray_laptop is addressing ghostbot 04:45.46 ghostbot appears OK. 04:45.46 Loaded Math 04:52.28 OK. Step 1 "cure everything my changes broke" :-) 04:52.39 At least it tigers :-) 04:57.14 Chans: (ghostbot) in:#ghostscript 05:02.02 regression running with the "normal" defaults. 05:02.48 Next I try forcing a pad and alignment locally.Alignment of 8 (default is 4) and pad of 5 05:11.47 FORK(28089) --- fork starting for 'RSSFeeds', PID == 28089, bot_pid == 24375 --- 05:11.48 FORK(28089) !ERROR! cannot load my module: RSSFeeds 05:11.48 FORK(28089) fork: took 2s for RSSFeeds. 05:11.48 FORK(28089) --- fork finished for 'RSSFeeds' --- 05:13.17 Chans: (ghostbot) in:#ghostscript 05:20.52 >>> plinnell has signed off IRC (Ping timeout: 264 seconds) [#ghostscript] 05:28.28 >>> join/#ghostscript plinnell (~mrdocs@opensuse/member/mrdocs) 05:29.08 Chans: (ghostbot) in:#ghostscript 05:30.07 >>> join/#ghostscript pipitas (~pipitas@p5B302BC3.dip0.t-ipconnect.de) 05:30.33 ray_laptop: you around? 05:36.48 mvrhel_laptop: yes, for a bit 05:36.58 ok. 05:37.20 So I was just sending a file to Robin for him to check with customer 801's device 05:37.44 I got around 17K segfaults from my alignment changes, so I would like an excuse to set it aside for the night 05:37.47 the interpreter is doing a range check error late in the running of the file and I can't quite figure out why 05:38.06 ray_laptop: wow that sounds like something I would do 05:38.34 naw, it's just that the planar device probably has some hidden assumptions 05:39.20 anyway, I can't get very far with my color testing until I figure out what is going wrong here. I will cc you in the email if you want to take a look in the morning 05:39.22 sort of "I know how memory is arranged -- don't bother me with accessing it the right way" ;-) 05:39.33 I was not aware that there were ICC profiles leaking by the way 05:39.36 mvrhel_laptop: I can look now. 05:39.38 or is it links 05:39.48 ray_laptop 05:39.53 ok let me email you the file 05:40.07 mvrhel_laptop: do we generate links during the parsing stage when it's going to the clst ? 05:41.05 but it is suspicious that the profiles are all exactly the same size as the one (just one) in the PDF -- obj 24 05:41.55 Seen: Flushed 2 entries. 05:41.55 --- Saved uptime records. 05:41.59 so, in the email, do you describe the problem ? or do you want to tell me here ? 05:42.12 ray_laptop: we will for graphic fills 05:42.38 ray_laptop: I just sent the email and described the issue 05:42.38 FORK(30656) --- fork starting for 'RSSFeeds', PID == 30656, bot_pid == 24375 --- 05:42.39 FORK(30656) !ERROR! cannot load my module: RSSFeeds 05:42.39 FORK(30656) fork: took 1s for RSSFeeds. 05:42.39 FORK(30656) --- fork finished for 'RSSFeeds' --- 05:42.48 mvrhel_laptop: OK. Checking ... 05:42.49 basically if you run it with the 8 bit customer device 05:42.56 no need to worry about a profile 05:42.59 got it 05:43.46 when an error like this happens in the interpreter it gets hard for me to debug 05:44.52 Chans: (ghostbot) in:#ghostscript 05:45.14 ray_laptop: so with the icc stuff, if we are doing a graphic fill, we will go ahead and render to the device value 05:45.17 no icc profile stored. 05:45.34 only in the case of images, and tranparency do profiles get put in the clist 05:45.39 well, you know that rangecheck is not as common as something line undefined 05:47.34 mvrhel_laptop: private tab, please 05:47.40 ok 05:49.03 mvrhel_laptop: do you see the tab ? 05:59.02 mvrhel_laptop: I'll have to pull in and build Robin's stuff. I get a segfault down in their device 05:59.16 oh wow 05:59.23 width600 == 0 when trying to divide 05:59.39 well Robin's stuff is an improvement over that.... 05:59.51 in their print_page 06:00.08 OK. well, I guess I'll have a look in the AM. 06:00.08 Chans: (ghostbot) in:#ghostscript 06:00.17 ray_laptop: ok sounds good 06:00.19 I am fading fast 06:00.41 since my son's as gotten into middle school late nights are harder for me 06:00.42 if you want to work on it in the meantime, set a brakpoint with a big count in gs_log_error 06:00.55 ray_laptop: yes I did that 06:01.05 the problem is that the error is printed by the interpreter 06:01.15 conditional on err == -15 06:01.49 hmm ok let me do that 06:01.55 gs_log_error will (should) show you the C code that sets it. 06:02.03 I would have thought though -Z# would have shown it 06:02.05 and it does not 06:02.10 unless it is done with PS and signalerror 06:02.40 >>> plinnell has signed off IRC (Ping timeout: 268 seconds) [#ghostscript] 06:02.50 that is what it seems to me, as I never got the -15 at the gs_log_error. 06:03.06 when Errror: range_check is printed 06:04.03 and it is bookended by some standard errors in indict.c 06:04.51 right before the rangecheck from the interpreter there is a idict.c error -2 but that occurs about a zillion times 06:05.07 also a -20 in gsparam, also a common one 06:05.12 no -15 06:05.32 just Error: /rangecheck 06:05.55 anyway. maybe Robin will figure it out while we sleep 06:06.02 have a good night ray_laptop 06:06.13 mvrhel_laptop: there are rangecheck signalled from the PS interp. 06:06.22 finding them is a bitch 06:06.33 ray_laptop: yes that is why I called you in :) 06:06.42 -dESTACKPRINT can help if you can get that printout. 06:07.15 oh I can stick on in where the error occurs 06:07.16 toward the bottom it shows you the "tail" of what you were executing (what remains in a proc) 06:07.17 in the ps code 06:07.51 mvrhel_laptop: I will pull in Robin's code and build and have a look in the AM 06:07.57 I am also fading. 06:08.03 ok. sounds good 06:08.08 g'nite 06:08.38 good night 06:12.15 >>> ray_laptop has signed off IRC (Ping timeout: 240 seconds) [#ghostscript] 06:12.55 >>> mvrhel_laptop has signed off IRC (Ping timeout: 240 seconds) [#ghostscript] 06:13.25 FORK(12393) --- fork starting for 'RSSFeeds', PID == 12393, bot_pid == 24375 --- 06:13.26 FORK(12393) !ERROR! cannot load my module: RSSFeeds 06:13.26 FORK(12393) fork: took 1s for RSSFeeds. 06:13.26 FORK(12393) --- fork finished for 'RSSFeeds' --- 06:16.22 Chans: (ghostbot) in:#ghostscript 06:25.40 >>> join/#ghostscript archdori_ (~Fandekasp@27-32-19-26.static.tpgi.com.au) 06:25.57 >>> pipitas has signed off IRC (Quit: Leaving.) [#ghostscript] 06:31.34 Chans: (ghostbot) in:#ghostscript 06:42.05 --- Saved uptime records. 06:42.05 Seen: Flushed 2 entries. 06:44.11 FORK(23391) --- fork starting for 'RSSFeeds', PID == 23391, bot_pid == 24375 --- 06:44.12 FORK(23391) !ERROR! cannot load my module: RSSFeeds 06:44.12 FORK(23391) fork: took 2s for RSSFeeds. 06:44.12 FORK(23391) --- fork finished for 'RSSFeeds' --- 06:47.36 Chans: (ghostbot) in:#ghostscript 07:13.35 >>> chrisl_away materializes into chrisl 07:13.45 ircCheck: possible lost in space; checking.Wed Oct 30 07:13:45 2013 07:13.45 >ghostbot< TEST 07:13.45 IRCTEST: Yes, we're alive. 07:14.56 FORK(31725) --- fork starting for 'RSSFeeds', PID == 31725, bot_pid == 24375 --- 07:14.57 FORK(31725) !ERROR! cannot load my module: RSSFeeds 07:14.57 FORK(31725) fork: took 2s for RSSFeeds. 07:14.57 FORK(31725) --- fork finished for 'RSSFeeds' --- 07:19.08 Chans: (ghostbot) in:#ghostscript 07:20.54 >>> join/#ghostscript plinnell (~mrdocs@107.18.186.29) 07:20.54 >>> plinnell has signed off IRC (Changing host) [#ghostscript] 07:20.54 >>> join/#ghostscript plinnell (~mrdocs@opensuse/member/mrdocs) 07:35.06 Chans: (ghostbot) in:#ghostscript 07:42.34 --- Saved uptime records. 07:42.45 >>> tkamppeter__ materializes into tkamppeter 07:45.01 FORK(29836) --- fork starting for 'RSSFeeds', PID == 29836, bot_pid == 24375 --- 07:45.02 FORK(29836) !ERROR! cannot load my module: RSSFeeds 07:45.02 FORK(29836) fork: took 2s for RSSFeeds. 07:45.02 FORK(29836) --- fork finished for 'RSSFeeds' --- 07:49.31 >>> join/#ghostscript pipitas (~pipitas@p5B302BC3.dip0.t-ipconnect.de) 07:51.01 Chans: (ghostbot) in:#ghostscript 07:53.22 >>> join/#ghostscript kens (~Miranda@31.185.216.66) 08:01.42 >>> join/#ghostscript tor7 (~tor@h-2-60.a230.priv.bahnhof.se) 08:07.06 Chans: (ghostbot) in:#ghostscript 08:15.31 FORK(2267) --- fork starting for 'RSSFeeds', PID == 2267, bot_pid == 24375 --- 08:15.32 FORK(2267) !ERROR! cannot load my module: RSSFeeds 08:15.32 FORK(2267) fork: took 2s for RSSFeeds. 08:15.32 FORK(2267) --- fork finished for 'RSSFeeds' --- 08:18.06 ircCheck: possible lost in space; checking.Wed Oct 30 08:18:06 2013 08:18.06 >ghostbot< TEST 08:18.07 IRCTEST: Yes, we're alive. 08:23.22 Chans: (ghostbot) in:#ghostscript 08:42.26 !WARN! PERL: readdir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 862. 08:42.26 !WARN! PERL: closedir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 869. 08:42.36 --- Saved uptime records. 08:45.49 FORK(2155) --- fork starting for 'RSSFeeds', PID == 2155, bot_pid == 24375 --- 08:45.50 FORK(2155) !ERROR! cannot load my module: RSSFeeds 08:45.50 FORK(2155) fork: took 2s for RSSFeeds. 08:45.50 FORK(2155) --- fork finished for 'RSSFeeds' --- 08:54.31 >>> pipitas has signed off IRC (Quit: Leaving.) [#ghostscript] 08:55.11 Chans: (ghostbot) in:#ghostscript 08:55.40 >>> join/#ghostscript mrdocs (~mrdocs@12.219.195.2) 08:55.40 >>> mrdocs has signed off IRC (Changing host) [#ghostscript] 08:55.40 >>> join/#ghostscript mrdocs (~mrdocs@opensuse/member/mrdocs) 08:56.16 >>> plinnell has signed off IRC (Ping timeout: 245 seconds) [#ghostscript] 08:56.24 >>> marcosw has signed off IRC (Quit: marcosw) [#ghostscript] 09:00.00 >>> join/#ghostscript plinnell (~mrdocs@107.18.186.29) 09:00.00 >>> plinnell has signed off IRC (Changing host) [#ghostscript] 09:00.00 >>> join/#ghostscript plinnell (~mrdocs@opensuse/member/mrdocs) 09:00.18 >>> mrdocs has signed off IRC (Ping timeout: 246 seconds) [#ghostscript] 09:10.40 Chans: (ghostbot) in:#ghostscript 09:15.15 >>> join/#ghostscript shmoon (~goodb0y@li474-116.members.linode.com) 09:15.18 hi 09:15.18 somebody said hello 09:15.18 not returning unaddressed greeting 09:15.33 are there any differences between what poppler and ghostscript does 09:15.39 Yes, many 09:15.39 or fundaentally both are meant to solve the dame purpose 09:15.49 same* 09:15.59 FORK(1018) --- fork starting for 'RSSFeeds', PID == 1018, bot_pid == 24375 --- 09:16.00 FORK(1018) !ERROR! cannot load my module: RSSFeeds 09:16.00 FORK(1018) fork: took 1s for RSSFeeds. 09:16.00 FORK(1018) --- fork finished for 'RSSFeeds' --- 09:16.27 i am trying to understand what each are for 09:16.40 from what i read, i understand that ghostscript is used to render pdf or PS documents 09:16.47 poppler does the same (rendering of pdf) 09:17.01 Its a PostScript and PDF interpreter (there are also PCL and XPS interpreters) 09:17.01 whether it is display (monitor) or printer 09:17.12 AFAIK poppler does not handle PostScript 09:18.37 so fundamentally both are meant for same purposes, kens ? 09:18.54 depends what exactly you mean. From your point of view, possibly yes. 09:19.19 hm ok 09:19.21 I am not an expert on Poppler 09:20.11 in poppler i can do pdf2text to get text out of pdf, can i do same with ghostscript? 09:20.20 There's the txtwrite device 09:21.00 hm, will read up a bit on it, thanks 09:21.42 If you have a goal in mind, explaining it might allow us to answer better. Generral questions tend to get general answers 09:24.07 yeah i completely agree 09:25.00 * kens/#ghostscript forgot to read the IRC logs :-( 09:26.02 kens: that "new" warning is down to change I did a while back - it's benign, but I have a change to stop the warning which I'll commit later 09:26.16 Oh, OK, I'm surprised you triggered a warning 09:26.26 Chans: (ghostbot) in:#ghostscript 09:26.54 Robin_Watts: (re yesterdays discussion with amonakov) I had an experimental patch to do gamma correct anti-aliasing (linearise colors, blend, convert back to srgb) for text 09:26.57 I got one of my colour problems fixed already this morning, going to try for another before I go out 09:27.24 kens: It wasn't something I considered - why would we warn when an optional entry is missing? I suspect it's for the benefit of Type 3 fonts...... 09:27.47 That's possible. I don't suppose Alex's Git log had any kind of explanation ? 09:28.36 Not of use, that I remember - I'll check again..... 09:28.50 I wouldn't be surprised to find it wasn't helpful 09:30.07 Robin_Watts: the problem with do fz_gamma_pixmap is that all non-b&w colors are already in sRGB color space, so they'll get all messed up. 09:31.36 amonakov: there's a patch sitting in my personal repo to do gamma correct antialiasing (on the "gamma" branch) 09:31.54 kens: the commit message doesn't explain the warning(s) - it's about encodings and symbolic fonts...... 09:32.10 Well, taht's definitely unhelpful :( 09:32.15 http://git.ghostscript.com/?p=user/tor/mupdf.git;a=commit;h=14693ddb7980c9754aa5a641c4b1dd1e9e620ecd 09:32.20 sybolic fonts aren't supposed to have encodings 09:38.11 Yes, true, but they often do..... anyway, it was basically that I missed that it's up to the caller of the proc to check if the font object has an encoding, when the encoding is optional 09:42.30 Chans: (ghostbot) in:#ghostscript 09:42.50 --- Saved uptime records. 09:43.01 Seen: Flushed 4 entries. 09:43.43 Off to squash..... 09:43.46 >>> chrisl has signed off IRC (Remote host closed the connection) [#ghostscript] 09:46.17 FORK(2214) --- fork starting for 'RSSFeeds', PID == 2214, bot_pid == 24375 --- 09:46.18 FORK(2214) !ERROR! cannot load my module: RSSFeeds 09:46.18 FORK(2214) fork: took 2s for RSSFeeds. 09:46.18 FORK(2214) --- fork finished for 'RSSFeeds' --- 09:58.42 Chans: (ghostbot) in:#ghostscript 10:15.30 LOG: last message repeated 3 times 10:15.30 >>> join/#ghostscript pipitas (~pipitas@p5B302BC3.dip0.t-ipconnect.de) 10:16.47 FORK(5740) --- fork starting for 'RSSFeeds', PID == 5740, bot_pid == 24375 --- 10:16.48 FORK(5740) !ERROR! cannot load my module: RSSFeeds 10:16.48 FORK(5740) fork: took 1s for RSSFeeds. 10:16.48 FORK(5740) --- fork finished for 'RSSFeeds' --- 10:21.28 >>> join/#ghostscript paulgardiner (~chatzilla@smtp.glidos.net) 10:25.17 bye folks, back in a bit 10:25.21 >>> kens has signed off IRC (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) [#ghostscript] 10:31.08 Chans: (ghostbot) in:#ghostscript 10:43.04 --- Saved uptime records. 10:43.14 Seen: Flushed 2 entries. 10:46.51 FORK(6934) --- fork starting for 'RSSFeeds', PID == 6934, bot_pid == 24375 --- 10:46.52 FORK(6934) !ERROR! cannot load my module: RSSFeeds 10:46.52 FORK(6934) fork: took 2s for RSSFeeds. 10:46.52 FORK(6934) --- fork finished for 'RSSFeeds' --- 10:47.56 Chans: (ghostbot) in:#ghostscript 10:51.10 >>> join/#ghostscript Steve___ (6d97a50a@gateway/web/freenode/ip.109.151.165.10) 10:51.24 hello 10:51.24 somebody said hello 10:51.24 not returning unaddressed greeting 10:52.52 I was wondering if anyone here could help with me some problems ive been having with Ghostscript? 11:00.22 Steve___: no one can help you if you first don't explain your problems. 11:01.33 hi tor7 - we use ghostscript with another program called PDF2TIFF - its basically a front end that sorts files into various folders depending on their extension 11:02.02 the problem we are having is that ghostscript seems to be converting 40kB PDFs into 8MB TIFFs - is there any way we can make the output smaller? 11:03.49 Steve___: TIFF generally doesn't compress very well. if you're looking for small file sizes and can live with RGB colors, I'd recommend using PNG instead. 11:04.21 also, PDF is a vector format, so files that only contain text or line art can be very small. render them to a bitmap and they'll be big no matter what. 11:04.51 Chans: (ghostbot) in:#ghostscript 11:05.57 if your TIFF are black&white (no grayscale) then you could try the tiffg4 device 11:07.56 right ok 11:09.12 >>> join/#ghostscript sebblonline (5d5dfdfb@gateway/web/freenode/ip.93.93.253.251) 11:09.16 how would I use the tiffg4 device? 11:10.02 we dont actually run ghostscript ourselves, we use another program as a front end that basically runs it for us 11:11.37 Steve___: I have no idea, you'd have to look at the front end program and see if you can tweak the options it calls gs with 11:11.59 ah ok, I was worried you might say that haha 11:12.34 ive had a look and there are no options for that, all it does is sort files in a folder before running the PDFs through ghostscript 11:13.05 im in contact with the guys who made the front end to see if they can recommend anything, but thanks for your help anyway 11:14.19 >>> Steve___ has signed off IRC (Quit: Page closed) [#ghostscript] 11:17.11 FORK(8818) --- fork starting for 'RSSFeeds', PID == 8818, bot_pid == 24375 --- 11:17.12 FORK(8818) !ERROR! cannot load my module: RSSFeeds 11:17.12 FORK(8818) fork: took 2s for RSSFeeds. 11:17.12 FORK(8818) --- fork finished for 'RSSFeeds' --- 11:18.39 Hi, does anyone know or can say, when there will be the next official release of mupdf downloadable on mupdf.com? Does that depend on the number of fixes or commits? I'm asking, because I made a report a month ago and wanted to know, when the fix will be available in the release. 11:20.36 Chans: (ghostbot) in:#ghostscript 11:27.28 >>> join/#ghostscript Steve___ (6d97a50a@gateway/web/freenode/ip.109.151.165.10) 11:28.10 hello again 11:31.50 what commands would I need in the command line to get it to output in smaller resolutions? 11:35.46 I found where our front end software runs the executable for ghostscript, and I was wondering if I could just add some specific options to the end of the filepath to change the output resolution, similar to this: "c:\path\to\exe\program.exe" -option1 - would that work with ghost script? 11:36.16 Chans: (ghostbot) in:#ghostscript 11:43.12 --- Saved uptime records. 11:43.43 Seen: Flushed 3 entries. 11:47.45 FORK(16348) --- fork starting for 'RSSFeeds', PID == 16348, bot_pid == 24375 --- 11:47.46 FORK(16348) !ERROR! cannot load my module: RSSFeeds 11:47.46 FORK(16348) fork: took 2s for RSSFeeds. 11:47.46 FORK(16348) --- fork finished for 'RSSFeeds' --- 11:51.56 Chans: (ghostbot) in:#ghostscript 11:57.09 so something like "c:\program files\gs\gs9.10\bin\gswin64c.exe" -gs -sDEVICE=tiffg4 -r600x600 ? 12:08.54 Chans: (ghostbot) in:#ghostscript 12:18.05 FORK(20673) --- fork starting for 'RSSFeeds', PID == 20673, bot_pid == 24375 --- 12:18.06 FORK(20673) !ERROR! cannot load my module: RSSFeeds 12:18.06 FORK(20673) fork: took 2s for RSSFeeds. 12:18.06 FORK(20673) --- fork finished for 'RSSFeeds' --- 12:18.24 Steve___: yes, something like that should work 12:18.44 sebblonline: we normally aim for two releases a year 12:19.36 I believe we're aiming at march for the next mupdf release 12:21.06 Ok, thanks for the info! 12:24.42 Chans: (ghostbot) in:#ghostscript 12:34.59 >>> archdori_ has signed off IRC (Read error: Connection reset by peer) [#ghostscript] 12:35.12 >>> Fandekasp has signed off IRC (Read error: Connection reset by peer) [#ghostscript] 12:35.22 >>> join/#ghostscript Fandekasp (~Fandekasp@27-32-19-26.static.tpgi.com.au) 12:36.15 sebblonline: Has a fix gone in for your bug? 12:37.36 >>> join/#ghostscript chrisl (~chrisl@cpc9-ando5-2-0-cust95.15-1.cable.virginm.net) 12:40.34 Chans: (ghostbot) in:#ghostscript 12:43.16 --- Saved uptime records. 12:43.26 !WARN! PERL: readdir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 862. 12:43.26 !WARN! PERL: closedir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 869. 12:43.47 Seen: Flushed 4 entries. 12:47.28 >>> join/#ghostscript kens (~Miranda@31.185.216.66) 12:48.28 FORK(30812) --- fork starting for 'RSSFeeds', PID == 30812, bot_pid == 24375 --- 12:48.29 FORK(30812) !ERROR! cannot load my module: RSSFeeds 12:48.29 FORK(30812) fork: took 1s for RSSFeeds. 12:48.29 FORK(30812) --- fork finished for 'RSSFeeds' --- 12:55.09 ok, SSE code all working. 12:56.52 Chans: (ghostbot) in:#ghostscript 12:58.58 >>> paulgardiner has signed off IRC (Remote host closed the connection) [#ghostscript] 13:01.57 >>> Fandekasp has signed off IRC (Ping timeout: 248 seconds) [#ghostscript] 13:02.26 >>> join/#ghostscript paulgardiner (~chatzilla@smtp.glidos.net) 13:02.52 >>> rayjj has signed off IRC (Ping timeout: 264 seconds) [#ghostscript] 13:05.21 >>> join/#ghostscript rayjj (~chatzilla@rrcs-64-183-45-165.west.biz.rr.com) 13:05.21 >>> mode/#ghostscript [+v rayjj] by ChanServ 13:13.20 Chans: (ghostbot) in:#ghostscript 13:17.41 >>> Steve___ has signed off IRC (Quit: Page closed) [#ghostscript] 13:18.39 FORK(30956) --- fork starting for 'RSSFeeds', PID == 30956, bot_pid == 24375 --- 13:18.40 FORK(30956) !ERROR! cannot load my module: RSSFeeds 13:18.40 FORK(30956) fork: took 2s for RSSFeeds. 13:18.40 FORK(30956) --- fork finished for 'RSSFeeds' --- 13:28.42 Chans: (ghostbot) in:#ghostscript 13:34.22 >>> join/#ghostscript Noldorin (~noldorin@unaffiliated/noldorin) 13:43.34 --- Saved uptime records. 13:44.00 Seen: Flushed 1 entries. 13:44.20 Chans: (ghostbot) in:#ghostscript 13:48.53 FORK(10031) --- fork starting for 'RSSFeeds', PID == 10031, bot_pid == 24375 --- 13:48.54 FORK(10031) !ERROR! cannot load my module: RSSFeeds 13:48.54 FORK(10031) fork: took 2s for RSSFeeds. 13:48.54 FORK(10031) --- fork finished for 'RSSFeeds' --- 13:52.27 >>> join/#ghostscript mvrhel_laptop (~chatzilla@c-50-159-85-185.hsd1.wa.comcast.net) 13:55.40 ircCheck: possible lost in space; checking.Wed Oct 30 13:55:40 2013 13:55.40 >ghostbot< TEST 13:55.41 IRCTEST: Yes, we're alive. 13:57.13 Morning mvrhel_laptop 14:00.47 Chans: (ghostbot) in:#ghostscript 14:08.18 good morning Robin_Watts 14:08.28 did you get a chance to look at the error? 14:08.41 it had me puzzled 14:12.19 >>> Noldorin has signed off IRC (Quit: Computer has gone to sleep.) [#ghostscript] 14:17.35 Chans: (ghostbot) in:#ghostscript 14:19.02 FORK(15944) --- fork starting for 'RSSFeeds', PID == 15944, bot_pid == 24375 --- 14:19.03 FORK(15944) !ERROR! cannot load my module: RSSFeeds 14:19.03 FORK(15944) fork: took 2s for RSSFeeds. 14:19.03 FORK(15944) --- fork finished for 'RSSFeeds' --- 14:23.16 >>> join/#ghostscript Noldorin (~noldorin@unaffiliated/noldorin) 14:26.21 kind of a pain in the ass recompiling everything when I switch git branches - guess I could change the GENDIR makefile variable for each branch. Does this only bother me? 14:27.00 I don't often switch branches 14:29.06 henrys: In theory, if all the dependencies are good, it should only rebuild what's changed, but...... well, hmmm :-( 14:31.01 once you have a project off on the side for a while something important will change like a makefile than your hosed. 14:31.36 I guess I just don't work like that 14:31.43 Well, when makefiles change, all bets are off - deal with it! 14:32.26 henrys: I don't find a minute or so to rebuild especially onerous, personally 14:32.45 takes longer on Windows... 14:33.15 True, but I assume henrys is on Mac most of the time 14:33.43 Chans: (ghostbot) in:#ghostscript 14:36.26 >>> Noldorin has signed off IRC (Quit: Computer has gone to sleep.) [#ghostscript] 14:37.49 oh no parallel compile on windows? 14:37.58 nope 14:38.08 Not with nmake, no 14:40.46 >>> kens has signed off IRC (Read error: Connection reset by peer) [#ghostscript] 14:42.20 >>> join/#ghostscript kens (~Miranda@31.185.216.66) 14:42.55 Interesting: qt has an nmake clone that supports parallel builds....... 14:44.05 --- Saved uptime records. 14:44.53 Seen: Flushed 5 entries. 14:46.10 chrisl: wow 14:46.49 henrys: I think it might balls up our detection of the VS version, though :-( 14:47.19 mvrhel_laptop: No, no luck at all. 14:47.38 mvrhel_laptop: I found myself pondering whether we actually need DeviceN stuff at all... 14:49.04 We only need to deal with 5 colorants; do we need to resort to DeviceN as soon as we do anything other than gray/rgb or cmyk ? 14:49.34 FORK(29897) --- fork starting for 'RSSFeeds', PID == 29897, bot_pid == 24375 --- 14:49.35 FORK(29897) !ERROR! cannot load my module: RSSFeeds 14:49.35 FORK(29897) fork: took 1s for RSSFeeds. 14:49.35 FORK(29897) --- fork finished for 'RSSFeeds' --- 14:49.44 Chans: (ghostbot) in:#ghostscript 14:52.58 >>> join/#ghostscript kersys (~kersys@188.19.21.52) 14:54.53 >>> kersys has signed off IRC (Read error: Connection reset by peer) [#ghostscript] 14:56.15 >>> tor7 has signed off IRC (Ping timeout: 246 seconds) [#ghostscript] 14:56.56 mvrhel_laptop: Aha. The rangecheck thing is my fault. It's in the put_params stuff. Let me try and figure out where/why 15:05.22 henrys: Did you read Marti's proposal about lcms2? 15:05.42 Chans: (ghostbot) in:#ghostscript 15:06.06 not carefully yet I will get to it shortly 15:06.57 ok, np. 15:08.05 >>> join/#ghostscript marcosw (~marcosw@c-24-130-197-170.hsd1.ca.comcast.net) 15:11.04 >>> join/#ghostscript tor7 (~tor@h-2-60.a230.priv.bahnhof.se) 15:13.03 >>> plinnell has signed off IRC (Ping timeout: 245 seconds) [#ghostscript] 15:13.48 mvrhel_laptop: ping me when you return. 15:19.50 FORK(31368) --- fork starting for 'RSSFeeds', PID == 31368, bot_pid == 24375 --- 15:19.51 FORK(31368) !ERROR! cannot load my module: RSSFeeds 15:19.51 FORK(31368) fork: took 2s for RSSFeeds. 15:19.51 FORK(31368) --- fork finished for 'RSSFeeds' --- 15:20.00 Robin_Watts: I am back 15:20.16 so you have a fix for the rangecheck 15:20.19 I have found the rangecheck mistake. that was me, sorry. 15:20.42 I get reasonable CMYB output, but the K output is broken for your file. 15:20.46 trying to figure out why now. 15:20.55 Do you want a new copy of the device? 15:21.15 yes that would be great 15:21.24 then I will look at the deviceN handling 15:21.45 gdevXXXX.c in my home dir. 15:21.53 ok thanks 15:21.53 Chans: (ghostbot) in:#ghostscript 15:21.56 I've got a hack in there at the moment. 15:22.21 The current code lists both "Blue" and "XXXXBlue" as colorants. 15:22.46 that is one odd thing that I don't believe is right 15:23.05 I've hacked the 'get_comp_index' function to treat "Blue" and "XXXXBlue" and "XxxxBlue" as being the same. 15:23.11 oh 15:23.19 in the new version on casper. 15:23.30 ok 15:23.31 You may decide that's a bad thing. 15:23.43 I did that just to see if that was the cause of the rangecheck (It wasn't) 15:23.47 right 15:23.54 I had done a similar thing 15:24.12 what was the source of the issue? 15:24.17 Robin_Watts: oh, bollocks. did you turn fz_stroke_state into a shared reference counted struct? 15:24.17 out of curiosity 15:25.16 mvrhel_laptop: put_params tests the values for being out of range. 15:25.27 and throws a range check if they are bad. 15:25.34 I had cocked up some of those tests :( 15:25.53 tor7: It is reference counted, and shared, yes. That may even have been me. 15:26.56 Robin_Watts: I'm scared. sharing a struct that just bundles some state... so I basically have to malloc a new stroke_state struct for each path I draw? 15:27.38 tor7: not sure offhand. Let me look. 15:27.39 I wonder why you did that though... before we just copied the data into the display list when needed 15:28.31 which is kind of what I still assumed, but now I've got pointers in the display list into my (stale and overwritten) stack-stored fz_stroke_state... :( 15:29.18 Currently I think you should always be using fz_new_stroke_state. 15:29.22 which will malloc. 15:29.31 Robin_Watts: I am making good progress on having the svg-device tigering 15:30.42 >>> chrisl has signed off IRC (Remote host closed the connection) [#ghostscript] 15:30.45 Robin_Watts: bah. I don't like it... it's a lot of keeping track of stroke states when I didn't use to have to, so as not to clobber any stowed away states by accident :( please tell me you had a good reason. 15:30.55 We *could* allow the use of stack based stroke_states by having them use a negative ref count, and when we 'keep' them, we could clone it automatically? 15:31.03 svg-input, not device 15:31.07 tor7: I'm sure I had a very good reason. 15:31.11 tor7: Right. 15:31.51 and I'm sure I discussed it with you at the time. Though I cannot remember why or when :) 15:32.11 Robin_Watts: me neither... though I do have a vague recollection of having discussed it! :) 15:33.05 my main worry is if we make the eventual "canvas" api, everyone and his mother is going to screw up and clobber stroke states that have been put into display lists 15:33.26 tor7: We have an 'unshare' mechanism in there. 15:34.02 Robin_Watts: if you'd done it to add dynamically allocated dash-stroke-lists I would have understood, but the dash list is still capped to 32 entries 15:34.14 tor7: No, it's not. 15:34.20 fz_new_stroke_state_with_len 15:34.36 ah, so that's why! 15:34.49 that ought to be ...with_dash_len 15:35.23 >>> join/#ghostscript chrisl (~chrisl@cpc9-ando5-2-0-cust95.15-1.cable.virginm.net) 15:35.24 feel free to rename. 15:35.36 will do. 15:36.02 Robin_Watts: how do you feel about not reference counting, still mallocing, but cloning when inserting into the display list? 15:36.31 or maybe we should make it opaque, and use some sort of copy-on-write mechanism 15:36.42 >>> pipitas has signed off IRC (Quit: Leaving.) [#ghostscript] 15:36.47 The 'unshare' is supposed to be copy on write. 15:36.51 anyway, I can proceed now that I know what's going on but this could be a sore spot in the api 15:37.13 I like the idea of having stack based ones with a negative ref count. 15:37.23 Chans: (ghostbot) in:#ghostscript 15:37.38 so we'd do: fz_stroke_state ss = fz_default_stroke_state; 15:37.46 Then ss.blah = ...; to set it up. 15:37.56 Then do the call with &ss 15:38.20 Then when the called thing does fz_keep_stroke_state, we have that spot refs = -1 and do a malloc/copy. 15:44.10 Robin_Watts: yeah, I think that's a reasonable approach 15:44.20 --- Saved uptime records. 15:44.23 or just refs = 0? 15:44.38 seeing as we use refs = -1 for const stuff 15:44.42 refs = -1 generally denotes constant... 15:44.44 yes. 15:45.02 I worry that 0 might work under debug builds and fail under release ones? 15:45.02 Seen: Flushed 5 entries. 15:45.10 if people forget to init them. 15:46.08 Use MAX_INT for stack based? 15:47.05 Robin_Watts: yeah, that is a worry 15:47.07 chrisl: yeah, -2, MAX_INT, any value like that would be fine. 15:47.25 I'm not opposed to -1 (if we think of it as 'magic' rather than 'const') 15:47.42 Robin_Watts: did you take a look at the commits on tor/master yet? 15:47.54 tor7: I suspect -2 would be better, as we get the option of having both 'const' and 'magic'. 15:48.17 tor7: sorry, no. Busy with 801 currently. 15:48.26 but I will try to as soon as I fix what I've broken here. 15:48.28 right. no rush. 15:48.55 >>> join/#ghostscript pipitas (~pipitas@p5B302BC3.dip0.t-ipconnect.de) 15:49.35 >>> marcosw has signed off IRC (Quit: marcosw) [#ghostscript] 15:50.15 FORK(11001) --- fork starting for 'RSSFeeds', PID == 11001, bot_pid == 24375 --- 15:50.16 FORK(11001) !ERROR! cannot load my module: RSSFeeds 15:50.16 FORK(11001) fork: took 1s for RSSFeeds. 15:50.16 FORK(11001) --- fork finished for 'RSSFeeds' --- 15:50.56 Robin_Watts: I see that yes, there is an issue with black 15:51.07 do you want me to figure it for you? 15:51.17 mvrhel_laptop: I'm working on it now. 15:51.43 ok 15:51.58 let me know when you have it fixed then I will take another look at things 15:52.30 I'm very confused, cos this was working earlier. 15:52.56 Oh, it works for tiger, but not for your file! 15:53.06 Chans: (ghostbot) in:#ghostscript 15:53.41 Robin_Watts: I get black output with my file. but it is def wrong 15:54.30 I get diagonal noise for black on your file. 15:55.08 oh not me 15:55.18 I get nice rectangles in the black plane 15:55.25 actually, I don't even get the other planes out readably. This is going to be something really stupid... 15:55.28 but I am using the icc profile and defining the colorants 15:55.31 too 15:55.41 i.e. using the customer command line 15:56.03 Robin_Watts: so the docx of October 14 is complete and latest. 15:56.32 Robin_Watts: I am going to create the psdcmyk output for this case as we should match that 15:56.42 plane for plane with their profile 15:56.48 henrys: If it has his time estimates at the bottom, yes. 15:56.59 mvrhel_laptop: Well, no. 15:57.27 Their device gets the noise offsets wrong per band. 15:57.28 color wise yes if I use the same profile 15:57.52 unless you set the bandheight to 256 or something. 15:58.06 Robin_Watts: no I don't see time estimates are you certain I was copied in? 15:58.13 Robin_Watts: I guess I am not following you 15:58.27 what noise offsets? I are you talking about halftoning? 15:58.41 s/I are/Are/ 15:58.52 henrys: On Sunday, Marti copied to tech 15:59.06 mvrhel_laptop: Yes, the halftoning. 15:59.26 Robin_Watts: only Artifex people can send to tech...... 15:59.34 The output from their device is 4bpp, with halftoning. 15:59.35 ok well the avg. of the squares should match 15:59.45 ok. 15:59.52 I did not mean pixel for pixel 15:59.54 Oh, let me forward to tech then. 15:59.57 mvrhel_laptop: Sorry. 16:00.45 chrisl: That's... a shame. 16:00.59 I've copied his message to tech now. 16:01.29 Robin_Watts: it's been that way since I joined 16:01.29 Robin_Watts: thanks for adding the pgm suffix and getting the range to 255. much better. 16:03.26 >>> join/#ghostscript ray_laptop (~chatzilla@rrcs-64-183-45-163.west.biz.rr.com) 16:03.36 morning, all. 16:03.41 morning ray 16:03.45 Robin_Watts: oh that is interesting 16:03.51 Robin_Watts: I'm going to look into my psdcmyk segfaults now 16:04.08 the psd device with their profile has the blacks wrong 16:04.14 I need to look at their profile 16:04.53 I suspect that we have an ordering issue here 16:06.47 Robin_Watts: looks good just need dollar estimate - does he want to send that privately, is that why it was not included in the document? 16:07.30 henrys: I figured that the rate he decides to charge artifex is nothing to do with me, and could be handled by you and Miles etc :) 16:07.55 okay I'll send him email 16:08.33 Chans: (ghostbot) in:#ghostscript 16:09.28 and the profile is fine 16:09.58 Robin_Watts: I'm surprised he got away with globals in a shared library without other complaints. 16:10.02 oh due 16:10.04 duh 16:10.46 I had copied their command line as it was in their readme 16:10.56 it will not work the way that they have it for that profile 16:14.06 EH?! band_height = 132, so how can I be being called with 133 lines of data each time? 16:14.06 interesting. colors are still wrong :( 16:14.25 oh. no actually they are correct 16:20.06 Robin_Watts: so the colors from the customer device look correct 16:20.19 when I use their profile and the proper name ordering 16:20.19 FORK(23534) --- fork starting for 'RSSFeeds', PID == 23534, bot_pid == 24375 --- 16:20.20 FORK(23534) !ERROR! cannot load my module: RSSFeeds 16:20.20 FORK(23534) fork: took 1s for RSSFeeds. 16:20.20 FORK(23534) --- fork finished for 'RSSFeeds' --- 16:20.25 in the command line 16:22.51 However, I just left one spot name in the list of colorants 16:23.02 it makes no sense to have Blue and XXXXBlue 16:23.27 Since the profile only has XXXXBlue according to their command line 16:23.38 mvrhel_laptop: I agree that we should just leave 1 spotname in the colorants. 16:23.57 But I worry that they might have PDF files set to have a "Blue" separation. 16:24.07 so mapping "Blue" to "XXXXBlue" might be smart? 16:24.17 Chans: (ghostbot) in:#ghostscript 16:25.29 Robin_Watts: The spot color "Blue" will end up using a lot of XXXXBlue when going through the profile 16:25.58 And is a common name 16:26.23 ok. I didn't realise that. 16:26.27 that may have different meanings not associated with their ink 16:26.38 I will plan to ask them about this 16:26.39 Then I wonder why they listed it in their device? 16:26.41 OK. 16:26.53 I would for now, just keep XXXXBlue 16:27.37 Seems sensible. I will make that change here. 16:28.06 >>> join/#ghostscript marcosw (~marcosw@c-98-207-109-212.hsd1.ca.comcast.net) 16:28.12 clist_dev_spec_op is not forwarding in the way I would have hoped it would. 16:28.33 It forwards to gdev_prn_dev_spec_op. 16:28.51 Not to the dev_spec_op of the clist target device. 16:31.39 oh... clist has stolen the dev_spec_op by that point... 16:31.47 I need to discuss this with ray... 16:31.51 ray_laptop: You here? 16:32.02 Robin_Watts: I understand why you are able to run without the pad. Each line "wraps" to the next line (maybe in the next plane) and then on the last line of the last plane, you pick up line_ptrs as the garbage. At least you aren't in danger of segfault as long as you have enough line ptrs 16:32.04 Robin_Watts: I am going over the DeviceN stuff now. num_std_colorant_names is set incorrectly for some reason 16:32.30 It's set to 5, right? 16:33.20 ray_laptop: So, I'm having trouble with the bandheight adjustment stuff. 16:33.24 right. 16:33.35 hmm.. I see. So clist should call the device's proc and rely on it calling the gdev_prn_spec_op proc ? 16:33.39 C M Y K B = 5 ? 16:33.39 looks like an issue in the graphics lib 16:33.51 right. but XXXXBlue is not a std colorant 16:34.00 kinda special 16:34.14 But it's 'standard' for this device maybe? I was guessing when I did this. 16:34.39 Why would we need to list "CMYK" as standard colorants? If it really means "standard" colorants, then why is that a device thing. 16:34.46 I assumed it meant "standard for this device". 16:35.01 i.e. "spot colors that we cope with without having to make new entries". 16:35.01 CMYK are standard. there is a test in the code to see if the device has the std CMYK colorants. and it does it by checking the number of std colorants == 4 16:35.13 not the best test 16:35.17 I feel 16:35.25 I need to look a bit closer 16:35.31 mvrhel_laptop: I'm going to leave this to you :) 16:35.33 like I said, this may be an issue in the graphics lib 16:35.57 ray_laptop: So, the problem I have here is that with mvrhel_laptop's file, it wants to use a band_height of 133. 16:36.19 and the band_height calculations are done several times, and each time the gxdso knocks it down to 132. 16:36.37 Robin_Watts: OK. And you want a multiple of 2, right ? 16:36.52 Then finally it has one last go with 133 only to find that it ends up in clist_dev_spec_op. 16:37.15 And that forwards to gdev_prn_dev_spec_op, which doesn't know anything about bandheights, so it returns 133. 16:37.34 Robin_Watts: this is all during device setup (prior to clist writing), right ? 16:38.08 clist_dev_spec_op *can't* forward to the target devices dev_spec_op, because the targets dev_spec_op is clist_dev_spec_op at this point. 16:38.14 ray_laptop: I assume so, yes. 16:38.26 In fact, yes, I'm sure it is. 16:38.31 Robin_Watts: clist has the target device and it's procs 16:38.50 cdev->target->procs.dev_spec_op == clist_dev_spec_op 16:39.42 and this dosen't work with the get_space_params, or didn't you try that ? 16:40.03 Chans: (ghostbot) in:#ghostscript 16:40.30 and that's what's being called (the target->procs.dev_spec_op) ? 16:40.52 I'm in clist_init_data 16:41.04 in gxclist.c at line 463 16:41.49 config (_default): backward-compatible option: found param{factoidDeleteDelay} (0) instead of chan option 16:43.05 >>> tor7 has signed off IRC (Remote host closed the connection) [#ghostscript] 16:43.55 !WARN! PERL: readdir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 862. 16:43.55 !WARN! PERL: closedir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 869. 16:45.05 --- Saved uptime records. 16:45.06 Seen: Flushed 6 entries. 16:45.39 >>> join/#ghostscript Noldorin (~noldorin@unaffiliated/noldorin) 16:47.29 Robin_Watts: so yes you should set Number colorants for CMYK to 4 on line 389 16:47.40 When they use their 5 color profile this has no effect 16:47.46 but with a CMYK profile it will 16:48.07 having it at 5 prevents proper color management of the CMYK to CMYK values 16:48.48 Robin_Watts: OK, so it's gdev_prn_allocate that does the dirty. It overwrites the procs with the clist procs right after (?) is does the setup as command list 16:49.03 it has tucked away the device's orig_procs 16:49.18 Can it forward to the orig_proc ? 16:49.43 forward to who ? 16:50.34 FORK(6161) --- fork starting for 'RSSFeeds', PID == 6161, bot_pid == 24375 --- 16:50.35 FORK(6161) !ERROR! cannot load my module: RSSFeeds 16:50.35 FORK(6161) fork: took 2s for RSSFeeds. 16:50.35 FORK(6161) --- fork finished for 'RSSFeeds' --- 16:50.40 Could clist_dev_spec_op forward to the original dev_spec_op somehow? Where is the original one saved? 16:50.53 Robin_Watts: do you mean make the orig_procs part of the gx_device_clist instead of in gx_device_printer ? 16:51.14 oh. 16:51.26 the original one is in gx_device_printer "orig_procs.dev_spec_op" 16:52.06 gdev_prn_dev_spec_op could maybe call the original one if there was one? 16:52.27 Are you sure this can't be done with the get_space_params 16:53.01 I'm not sure of anything anymore! 16:53.03 Robin_Watts: OK, that's an approach. It has the orig_procs 16:53.18 But when we discussed this before, we decided on the dev_spec_op. 16:53.45 Robin_Watts: yeah, I didn't fight you on it, and it's your favorite hammer ;-) 16:54.18 but we need to define the chaining process for dev_spec_op to make sure we don't end up with loops 16:54.59 generally a forwarding device calls its target procs 16:55.59 Chans: (ghostbot) in:#ghostscript 16:56.06 I can unlink the orig_proc before calling it, so it can't loop? 16:56.07 and (if I understand it) the actual devices are expected to call gx_default_spec_op ? 16:56.24 yes. 16:57.32 Might we ever have the same device having its dev_spec_op being called from more than 1 thread at a time? 16:58.47 Robin_Watts: maybe, why ? remember, each thread is a standalone device struct, so even if the spec_op sets something for the device, we are OK 16:58.55 I think 16:59.21 ray_laptop: To avoid loops, I could read orig_procs.dev_spec_op, then set that to NULL, then call it, then on return, reset it. 16:59.24 but the clist playback in threads can't call the spec_op, can it ? 16:59.54 ray_laptop: Maybe not now, maybe not tomorrow, but one day... 17:00.00 Robin_Watts: right, that's done several places, or set it to the default which we know never calls out 17:00.14 >>> sebblonline has signed off IRC (Quit: Page closed) [#ghostscript] 17:00.25 Robin_Watts: other than that one change, it all looks good to me color-wise 17:00.34 nice job 17:01.00 ray_laptop: Right. The only time this would go wrong is if people had a device with a dev_spec_op and made it call gdev_prn_dev_spec_op at the end. 17:01.07 Robin_Watts: OK, so I like having the gdev_prn_spec_op call the orig_procs.dev_spec_op with the method you describe 17:01.30 The 'unlinking' trick fails if we have multiple threads calling this. 17:01.35 all a device is ever supposed to call is gx_default_spec_op 17:01.43 Robin_Watts: and line 433 can go away 17:02.25 hello. what is the recommended way to submit mupdf (fitz) patches? 17:02.59 ray_laptop: In that case, I am tempted not to bother unlinking. 17:03.08 impressive looking work in the SSE2 area by the way 17:03.25 mvrhel_laptop: DevCMYKBBComponents is still needed, right? 17:03.56 oh yes 17:04.13 but the "number of standard colorants" should be 4, not 5? 17:04.13 but just the 5 of them 17:04.19 yes 17:04.56 I'm looking at the device definition now... 17:05.14 There is the XXXX_DEVICE(...) line 17:05.18 and that has a 5 in it. 17:06.04 Can you give me specific instructions for what to change please? It'll be safer than me trying to muddle it. 17:06.25 line 389 right after DevCMYKBBComponents 17:06.34 with the comment /* @@@ Number colorants for CMYK */ 17:06.40 should be 4 not 5 17:07.13 Robin_Watts: let me look at something in the clist processing before we decide on a method. 17:07.13 >>> Noldorin has signed off IRC (Quit: Computer has gone to sleep.) [#ghostscript] 17:07.27 But the MaxSeparations should be 5? 17:07.32 yes 17:08.03 mvrhel_laptop: Do we need the update_spot_equivalent_colors stuff? 17:08.08 and the ret_devn_params ? 17:08.22 and the get_color_mapping_procs? 17:08.33 and the get_color_comp_index 17:10.03 Robin_Watts: so update spot equivalent is not *really* needed for this device. Since it gives the device information that it can use. However, I don't know what happens if you have it null. ret_devn_params is needed 17:10.13 get_color_mapping_procs is needed 17:10.21 mvrhel_laptop: Am I right in thinking that your file should give a completely clear black plane ? 17:10.29 no 17:10.46 oh let me check in the case where we have no profile 17:11.43 Chans: (ghostbot) in:#ghostscript 17:11.49 or rather when the profile is CMYK 17:11.59 as no profile means this to be the case 17:12.45 Robin_Watts: ok so yes 17:12.51 Phew. 17:12.58 with out using the customer profile the black plane is blank 17:13.25 :) 17:13.31 OK, updated gdevXXXX.c in my home dir 17:13.55 Robin_Watts: since you and mvrhel_laptop have been going back and forth, where's the 'latest and greatest' code you guys are discussing. I wanted to look at it, too, in a bit 17:14.05 >>> kens has signed off IRC (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) [#ghostscript] 17:14.15 ray_laptop: I will do a zip of all my changes in a mo. 17:15.19 Robin_Watts: You don't have a tree in your home dir on casper ? 17:15.32 not with all my changes. 17:16.08 oh, I see the gdevXXXX.c file that has a time stamp of just a few minutes ago 17:16.25 ls -lt | head is your friend :-) 17:17.26 801.tar.gz in my home dir is refreshed with everything, including the gdev_prn_dev_spec_op we were just talking about. 17:17.43 Robin_Watts: I see two .zip's should I first grab the big one (XXXX_Project_0822.zip) ? 17:18.02 if it's the same as was on the FTP site, then I already have it 17:18.11 ray_laptop: The big one is their original device within 9.06 or something like that. 17:18.17 that's the one from the ftp site, yes. 17:18.22 Robin_Watts: so you can ditch update_spot_equivalent_colors 17:18.32 mvrhel_laptop: Great, thanks. 17:18.37 OK. So I just tar -x the 801.zip ? 17:18.46 let me double check on the others to see what the defaults do 17:18.51 on top of the code base I have ? 17:20.06 mvrhel_laptop: Does that mean I no longer need equivalent_cmyk_color_params equiv_cmyk_colors; in the device definitions? 17:20.20 ray_laptop: On top of a current ghostpdl, yes. 17:20.26 Robin_Watts: that is true 17:20.36 FORK(31305) --- fork starting for 'RSSFeeds', PID == 31305, bot_pid == 24375 --- 17:20.37 FORK(31305) !ERROR! cannot load my module: RSSFeeds 17:20.37 FORK(31305) fork: took 1s for RSSFeeds. 17:20.37 FORK(31305) --- fork finished for 'RSSFeeds' --- 17:20.43 you would use those to construct the simulated composited view 17:20.52 and we are not doing that 17:21.04 Great. I blindly copied some of this stuff from psdcmyk, I think. 17:21.25 Hmm. 17:21.45 the get_color_comp_index function makes reference to the equiv_cmyk_colors 17:22.45 hold on let me look this over more 17:25.55 Robin_Watts: it can be NULL 17:26.13 so just remove 17:26.32 and do the call with NULL 17:27.06 cool, thanks. 17:27.16 Chans: (ghostbot) in:#ghostscript 17:27.20 mvrhel_laptop: Len just called. I don't suppose you've gone back to looking at the massive allocation problem, have you ? I think we may need to jump on that soon. They are also P1. 17:27.21 Do we need the thing with the warnings about the number of separations? 17:27.50 no that can be removed 17:27.53 mvrhel_laptop: we need to get on this before he continues with some hacky solution (that's what he wanted to talk about) 17:28.58 ray_laptop: gone back to looking at? I really have not really looked at it as I thought we decided it was not an ICC problem, but now I guess it is 17:29.22 ray_laptop: I am about finished up here I think with helping Robin 17:29.35 mvrhel_laptop: Yes. MUCH appreciated. Thanks. 17:29.44 then I will help Len 17:29.52 Robin_Watts: I really did not do much 17:30.05 let me just check a couple other things 17:30.50 Robin_Watts: so you can remove warning_given from the device definition 17:31.00 just doing that. 17:34.29 So, new 801.tar.gz uploaded. 17:38.05 Robin_Watts: ok I think that is all I have for now 17:38.16 mvrhel_laptop: Thanks. 17:38.33 Robin_Watts: glad to help out the bit that I could 17:38.52 ray_laptop: Where did the alignment stuff land? Is that on hold while you fight fires for Len ? 17:38.53 ray_laptop: ok. let me run and do one thing (3 minutes) and then lets have fun with icc leaks 17:39.21 mvrhel_laptop, ray_laptop: Let me know if I can help with this leaky thing. I can try a memento run if that will help. 17:42.37 Chans: (ghostbot) in:#ghostscript 17:44.28 excuse me, I have a few questions, is this a good time? 17:44.57 I was wondering about the recommended way to submit patches, but there's a couple of other things I'd like to clarify as well 17:45.27 --- Saved uptime records. 17:45.37 Seen: Flushed 4 entries. 17:45.47 amonakov: Open a bug on bugs.ghostscript.com, mark it as an enhancement, describe exactly what it solves etc, and attach the patch. 17:46.37 ok, thanks 17:47.37 the other two questions were about how to add opt-in font hinting (fitz_enable_device_hints?), and assumed colorspace in fitz re: tor7's patch above 17:48.36 Either you'd add a hint to the device, or you'd put something in the context, similar to the antialiasing levels that are there now. 17:50.01 mvrhel_laptop: sorry. Took a while to get Len to let me go back to work :-/ 17:50.40 Robin_Watts: They aren't *real* leaks in that they just aren't being GC'd. 17:50.41 FORK(26411) --- fork starting for 'RSSFeeds', PID == 26411, bot_pid == 24375 --- 17:50.42 FORK(26411) !ERROR! cannot load my module: RSSFeeds 17:50.42 FORK(26411) fork: took 2s for RSSFeeds. 17:50.42 FORK(26411) --- fork finished for 'RSSFeeds' --- 17:51.51 and the profile is getting loaded over and over again even though we already have it laying around. We just "misplaced it" (i.e., forgot about it and left it for the GC to find later) 17:52.18 ray_laptop: ok. what do I need to do see this happening 17:52.20 Robin_Watts: I don't memento will help with that 17:52.51 ray_laptop: possibly not. 17:53.02 tor7: ping 17:53.08 ray_laptop: likely a tranparency group issue 17:53.32 just a guess anyway 17:53.39 alas, tor7 does not seem to be here; I was hoping to talk to him 17:53.51 ray_laptop: let me get set up with the file 17:54.17 mvrhel_laptop: I ran the file, with HEAD using: debugbin/gswin32c -r72 -sDEVICE=ppmraw -o x.ppm -dMaxBitmap=1g -d PDFDEBUG -Z:a AIX361DC_Save.pdf > log 2>&1 17:55.04 tor7: For the logs: Your reviews all look good. The only thing I have questions about is the first one... 17:55.19 Then in the log you can look for the *magic* size of the blocks being alloc'ed and freed (557168) 17:56.13 1) Does our PWG support really do CMYK already? 17:56.14 henrys: might end up doing a mt. bike trip in the Yukon this next summer 17:57.04 mvrhel_laptop: summer is a good time ;-) Sounds like quite an adventure. 17:57.04 tor7: actually, 1) was my only question in the end :) 17:57.16 mvrhel_laptop: the "forget" part may be that we are in a save / restore, but the profile(s) that we forgot were put in stable memory. stable memory is still subject to GC 17:58.55 Chans: (ghostbot) in:#ghostscript 18:00.44 mvrhel_laptop: but that's guessing. 18:01.02 >>> join/#ghostscript Noldorin (~noldorin@unaffiliated/noldorin) 18:02.18 Robin_Watts: to answer your question, I am going to budget the rest of the morning to the alignment code, then when I do a push, work on the other part of Len's issue -- getting an error page to print after a VMerror, with expected consultations with mvrhel_laptop if he needs it 18:02.36 so, back to alignment for a bit. 18:02.49 ray_laptop: I was going to say that if you want to throw it over to me, and concentrate on Len, feel free. 18:03.31 801 also did a 'bent' tiff device in their sourcetree. 18:03.45 I've ignored that for now, but possibly I should be looking at converting that over too ? 18:03.55 henrys: ^ 18:09.33 Robin_Watts: does it also get the same 4-bit munged stuff from their gxclthrd.c 18:09.39 yes. 18:10.01 Robin_Watts: but, I think they mentioned they need TIFF (not clear why). I thought it was just for monochrome 18:11.23 ray_laptop: So, the question is, do I push forwards with a new version of their tiff device, or do we just wait for the padding/alignment stuff, fix the SSE to make use of that, and then send them that as a starting shot? 18:14.05 Robin_Watts: well, it seems like the 'process_page' changes are common, so I'd say go ahead and start the tiff changes. We don't have to send it to them (we can send the color part sooner) 18:14.33 Chans: (ghostbot) in:#ghostscript 18:14.37 >>> Noldorin has signed off IRC (Quit: Textual IRC Client: www.textualapp.com) [#ghostscript] 18:20.14 >>> ray_laptop has signed off IRC (Ping timeout: 240 seconds) [#ghostscript] 18:21.12 FORK(22724) --- fork starting for 'RSSFeeds', PID == 22724, bot_pid == 24375 --- 18:21.13 FORK(22724) !ERROR! cannot load my module: RSSFeeds 18:21.13 FORK(22724) fork: took 2s for RSSFeeds. 18:21.13 FORK(22724) --- fork finished for 'RSSFeeds' --- 18:21.46 Damn. My dev_spec_op clist fix causes mass timeouts on the cluster 18:29.54 Robin_Watts: let's not worry about the tiff stuff 18:29.54 Chans: (ghostbot) in:#ghostscript 18:30.13 good answer :) 18:32.17 >>> join/#ghostscript Noldorin (~noldorin@unaffiliated/noldorin) 18:32.39 anybody have opinions about the best tablet out there these days. My son is looking for one. 18:33.45 >>> Noldorin has signed off IRC (Client Quit) [#ghostscript] 18:33.52 At what size? The new Nexus 7 is pretty damn good. 18:34.11 >>> join/#ghostscript Noldorin (~noldorin@unaffiliated/noldorin) 18:36.59 Robin_Watts: any chance you could add a mention of --debug into the documentation in Use.htm Debug switches 18:37.09 seems like something that should be there 18:37.18 sure. 18:37.19 and I think you did that extension yes? 18:37.20 thanks 18:37.36 for what ever reason I always forget the notation 18:37.43 and then have to go back and look at the commit 18:38.03 after looking at our great documentation :) 18:38.58 mvrhel_laptop: I did the extension, yes. 18:43.58 Robin_Watts: he wants a 10 he's looking at nexus 10 vs. iPad air 18:45.02 well, does he want shiny, but expensive, unexpandable, and walled garden, or does he want android? :) 18:45.32 --- Saved uptime records. 18:45.42 Chans: (ghostbot) in:#ghostscript 18:46.13 Seen: Flushed 5 entries. 18:49.43 Robin_Watts: he'll probably get an iPad so he can talk to the girls at the apple store ;-) 18:51.46 FORK(14494) --- fork starting for 'RSSFeeds', PID == 14494, bot_pid == 24375 --- 18:51.47 FORK(14494) !ERROR! cannot load my module: RSSFeeds 18:51.47 FORK(14494) fork: took 2s for RSSFeeds. 18:51.47 FORK(14494) --- fork finished for 'RSSFeeds' --- 18:51.51 and this is why apple is the most successful company in the world today :) 18:52.42 ray_laptop: so I am seeing some funny stuff go on in the transparency ICC code that may be the source of our problems 18:53.07 digging a little more to track down 18:53.48 henrys: Did you read about the peachy printer in the end? 18:54.07 I just gave in and pledged for castAR. 18:54.37 I feel that my geek status needed reinforcement :) 18:55.23 Robin_Watts: no I never got around to it. Thanks for reminding me. 18:55.45 >>> chrisl materializes into chrisl_away 19:00.23 >>> join/#ghostscript ray_laptop (~chatzilla@150.sub-70-197-64.myvzw.com) 19:01.23 Robin_Watts: the nexus 10 release is imminent and I'm sure the goal will be to outdo the air. The current 2012 model doesn't compete really. 19:01.53 Chans: (ghostbot) in:#ghostscript 19:02.20 ok. with this debug set up I should be able to figure out the issue 19:02.24 need to eat now though 19:02.32 mvrhel_laptop: thanks 19:03.44 darn. I rushed out to deliver lunches and my regression didn't start :-( running it now 19:04.14 that *should* fix the planar mode alignment+pad change issue 19:04.38 ray_laptop: Excellent. If there are remaining problems, feel free to mail me, and I can look tomorrow. 19:04.49 I'm going out to see Enders Game in a bit. 19:05.13 Robin_Watts: this one actually has the pad forced to 5 and the alignment forced to 8 19:05.29 so it's the 'stress test' 19:05.55 If you want I can run a pad of 64 and alignment of 16 later, as well 19:08.15 Enjoy the movie! My 14yr old *really* wants to see it. He read the series this summer 19:09.12 >>> join/#ghostscript plinnell (~mrdocs@opensuse/member/mrdocs) 19:12.16 Hi. I'm trying to convert a PDF page with some color to pure grayscale: "gs -o gray.pdf -sDEVICE=pdfwrite -sProcessColorModel=DeviceGray -sColorConversionStrategy=Gray color.pdf". However, it does not work (I *KNOW* it used to work on former occasions). 19:12.22 I used a current debug build from Git, and added "-Zc" to get debugging output about color.- 19:12.22 The only (to me) meaningful output line I can spot is this: 19:12.22 "Unable to convert color space to Gray, reverting strategy to LeaveColorUnchanged." 19:12.24 now I am suspecting that there is some funny stuff going on with the color space setting 19:12.49 Robin_Watts: Orson has really ruffled some feathers here ... 19:13.02 What could be wrong with my command (or with the input PDF)? 19:13.55 pipitas: You probably need ken. Try again in about 15 hours time. 19:15.45 Hmm… I need to print my train ticket for a departure 14 hours from now — on a printer which complains about low level inks for CMY, but which still has K ink enough :) 19:17.10 pipitas: Print to a greyscale bitmap. Print the bitmap. 19:17.53 Chans: (ghostbot) in:#ghostscript 19:18.48 pipitas: hopefullly your printer will allow that. I had a KM laser printer that refused to print a black page when out of yellow. 19:19.47 pipitas: my newer Epson *does* allow black only printing when out of color, in fact, it will even automatically print gray from a color page. Very high user friendly marks 19:20.43 and when I ran out of black, it let me print in CMY. Both required pressing "OK" on the panel 19:21.05 that's the way to do it, IMHO 19:21.35 Damn. Still SEGVs with my new patch. Will have to look why tomorrow. 19:21.56 FORK(27253) --- fork starting for 'RSSFeeds', PID == 27253, bot_pid == 24375 --- 19:21.56 ray_laptop: so it is interesting that the icc color space has no compareproc. 19:21.57 FORK(27253) !ERROR! cannot load my module: RSSFeeds 19:21.57 FORK(27253) fork: took 2s for RSSFeeds. 19:21.57 FORK(27253) --- fork finished for 'RSSFeeds' --- 19:22.28 plus Epson has individual C, M, Y and K cartridges so you don't have to waste the C and M when you run out of Y (which always goes fastest) 19:23.31 The net effect is that I am seeing a free and a new allocation where we don't need to be doing that 19:23.50 this is a performance hit at the least 19:23.58 >>> Noldorin has signed off IRC (Quit: Computer has gone to sleep.) [#ghostscript] 19:24.01 of course it is not the source of our growing pile of profiles 19:24.04 mvrhel_laptop: yeah, that might help (as long as we haven't lost track of the profile we've already loaded). A 'q' /ICCBased ... cs 'Q' could revert to something like DeviceRGB or DeviceGray and lose the profile 19:24.08 * pipitas/#ghostscript is going to remove the ink cartridges and shake them a bit in order to try and fool the printer in his host's home office… 19:25.21 pipitas: good luck. That often works with laser toner, but some inkjets have "smart" cartridges so you can't even refill them. They count drops and mark it as empty 19:26.27 my previous company did that nefarious deed since they planned on making lots of money on ink. They went out of business before the $$$ started rolling in 19:27.22 would it be kosher to add new field `int hint_all_glyphs' into struct fz_context_s? 19:28.55 hm, fz_font_context_s might be a better fit actually 19:33.03 >>> plinnell has signed off IRC (Quit: Konversation terminated!) [#ghostscript] 19:33.23 Chans: (ghostbot) in:#ghostscript 19:33.29 >>> join/#ghostscript plinnell (~mrdocs@opensuse/member/mrdocs) 19:39.30 >>> join/#ghostscript JakeSays (~quassel@chat.thatswhatjakesaid.com) 19:40.24 hello.. i have a mupdf question. i'm implementing this method in a custom device: fill_image_mask(fz_device *dev, fz_image *img, fz_matrix ctm, fz_colorspace * colorspace, float *color, float alpha) 19:41.12 my question is, how can i determine the actual bounds of the image as it will be displayed? the images are much larger than the space they consume in the rendered pdf 19:43.33 >>> plinnell has signed off IRC (Remote host closed the connection) [#ghostscript] 19:43.59 >>> join/#ghostscript plinnell (~mrdocs@opensuse/member/mrdocs) 19:45.41 --- Saved uptime records. 19:46.48 Seen: Flushed 7 entries. 19:48.53 Chans: (ghostbot) in:#ghostscript 19:52.05 >>> plinnell has signed off IRC (Ping timeout: 245 seconds) [#ghostscript] 19:52.15 FORK(30045) --- fork starting for 'RSSFeeds', PID == 30045, bot_pid == 24375 --- 19:52.16 FORK(30045) !ERROR! cannot load my module: RSSFeeds 19:52.16 FORK(30045) fork: took 1s for RSSFeeds. 19:52.16 FORK(30045) --- fork finished for 'RSSFeeds' --- 19:55.42 >>> ray_laptop has signed off IRC (Read error: Connection reset by peer) [#ghostscript] 20:04.45 Chans: (ghostbot) in:#ghostscript 20:10.43 JakeSays: The image is scaled to fit within a square from (0,0) to (1,1). And that square is then transformed by the ctm. 20:11.22 So if the ctm is (100, 0, 0, 200, 30, 40) then the image will end up being 100 wide by 200 tall, with its corner at (30,40) 20:12.16 And if you can't instantly see how I got those figures, you should read up on transformation matrices before doing anything else. 20:15.48 Robin_Watts: ah ok. yeah i understand the transformation. part i was missing was the scaling. 20:20.33 Chans: (ghostbot) in:#ghostscript 20:22.30 FORK(20412) --- fork starting for 'RSSFeeds', PID == 20412, bot_pid == 24375 --- 20:22.31 FORK(20412) !ERROR! cannot load my module: RSSFeeds 20:22.31 FORK(20412) fork: took 2s for RSSFeeds. 20:22.31 FORK(20412) --- fork finished for 'RSSFeeds' --- 20:33.13 Robin_Watts: would i need to convert the image dimensions from pixels to points before scaling/transforming, or does the normalizing to the unit square eliminate that need? 20:36.06 >>> join/#ghostscript pipitas1 (~pipitas@p5B302BC3.dip0.t-ipconnect.de) 20:36.36 Chans: (ghostbot) in:#ghostscript 20:39.05 mvrhel_laptop: Are you around? 20:39.20 yes 20:39.28 >>> pipitas has signed off IRC (Ping timeout: 264 seconds) [#ghostscript] 20:39.49 pipitas1^^ 20:40.09 Did you see my question from about 1hr 20min ago? 20:40.13 no 20:41.07 I tried to convert a 1page color PDF to grayscale, but got again a color PDF with message:    "Unable to convert color space to Gray, reverting strategy to LeaveColorUnchanged." 20:41.30 Command was: "gs -o gray.pdf -sDEVICE=pdfwrite -sProcessColorModel=DeviceGray -sColorConversionStrategy=Gray color.pdf" 20:41.48 This *USED* to work. 20:42.12 Either I don't remember the correct command, or the input PDF is somehow weird, or GS has a bug… 20:42.43 >>> join/#ghostscript mvrhel_laptop_ (~chatzilla@c-50-159-85-185.hsd1.wa.comcast.net) 20:42.44 mvrhel_laptop: I tried GS 9.10 as well as current Git. Both with same result. 20:42.54 sorry connection dropped 20:43.02 did you see my comment about pdfwrite color? 20:43.10 kens is in charge of this 20:43.17 and in the middle of a big change 20:43.26 pdfwrite did not make sure of the icc color settings 20:43.41 mvrhel_laptop: But it SHOULD work with the 9.10 release, no? 20:43.43 but you are not doing that I see 20:44.14 pipitas1: I would expect to see no real diff with the 9.10 release but you should check with kens 20:44.22 he will be around UK time 20:44.32 !WARN! PERL: readdir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 862. 20:44.32 !WARN! PERL: closedir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 869. 20:44.37 mvrhel_laptop: I know KenS in charge of pdfwrite, but I thought *you* can spot my mistake (if I made one). 20:44.53 >>> mvrhel_laptop has signed off IRC (Ping timeout: 248 seconds) [#ghostscript] 20:45.07 >>> mvrhel_laptop_ materializes into mvrhel_laptop 20:45.55 --- Saved uptime records. 20:46.16 pipitas1: I don't see any issue with your command line 20:46.32 unfortunately I can't test it out now 20:46.35 in middle of something 20:47.15 Seen: Flushed 5 entries. 20:52.23 Chans: (ghostbot) in:#ghostscript 20:52.34 FORK(3006) --- fork starting for 'RSSFeeds', PID == 3006, bot_pid == 24375 --- 20:52.35 FORK(3006) !ERROR! cannot load my module: RSSFeeds 20:52.35 FORK(3006) fork: took 2s for RSSFeeds. 20:52.35 FORK(3006) --- fork finished for 'RSSFeeds' --- 20:55.26 mvrhel_laptop: I understand 21:03.04 >>> join/#ghostscript Fandekasp (~Fandekasp@27-32-19-26.static.tpgi.com.au) 21:07.55 Chans: (ghostbot) in:#ghostscript 21:09.18 >>> join/#ghostscript Noldorin (~noldorin@unaffiliated/noldorin) 21:14.01 >>> join/#ghostscript ray_laptop (~chatzilla@150.sub-70-197-64.myvzw.com) 21:22.48 FORK(23187) --- fork starting for 'RSSFeeds', PID == 23187, bot_pid == 24375 --- 21:22.49 FORK(23187) !ERROR! cannot load my module: RSSFeeds 21:22.49 FORK(23187) fork: took 2s for RSSFeeds. 21:22.49 FORK(23187) --- fork finished for 'RSSFeeds' --- 21:23.09 ray_laptop: cluster testing the icc comparison test. 21:23.17 now I will see what else is going on 21:23.57 Chans: (ghostbot) in:#ghostscript 21:24.50 mvrhel_laptop: Ha! I beat you. My test is running first ;-) 21:25.11 hmm where is that reset button 21:26.41 mvrhel_laptop: if you had sudo access on a server, you could su to 'ray' and submit a "git abort" (not that I've ever abused my access that way ;-) ) 21:27.13 well this fix has cut way down on the icc allocation noise 21:27.27 not git abort, I mean toolbin/localcluster/gitpush.sh abort 21:27.57 mvrhel_laptop: Great! so the performance AND allocation should be a *lot* better 21:28.16 in fact it is looking like this was the issue 21:29.12 mvrhel_laptop except we still don't know why the old things were left around for the GC to clean up. 21:29.23 right. let me push on for a bit 21:30.41 mvrhel_laptop: I have to pick up kids today. My wife is on a shopping trip to help our niece decorate with balloons and stuff. 21:30.51 ok 21:31.29 oh. one of our fastest cluster machines, "i7", is --DOWN-- :-( 21:32.28 marcosw: are you doing maintenance on it, or did it finally overheat due to that extreme overclocking (or water cooling failure) ? 21:33.59 Robin_Watts: hey that worked. thanks! 21:34.14 I've (finally) got my phone (mostly free) wi-fi hotspot working. I can now heartily recommend PDAnet for an android based phone ! 21:35.44 it's a commercial product, but a one-time purchase is better than $15/mo my phone provider (Verizon) wants *on top of unlimited internet* 21:37.03 mvrhel_laptop: my cluster run is almost finished. Thanks for waiting ;-) 21:37.13 np 21:37.42 I'll see if I got less than 30K segfaults this time :-) 21:38.15 I fixed planar mode and broken non-planar mode :-( 21:38.34 so maybe now both will work 21:39.34 Chans: (ghostbot) in:#ghostscript 21:41.20 >>> ray_laptop has signed off IRC (Read error: Connection reset by peer) [#ghostscript] 21:44.48 >>> Noldorin has signed off IRC (Remote host closed the connection) [#ghostscript] 21:46.18 --- Saved uptime records. 21:47.30 Seen: Flushed 4 entries. 21:49.08 >>> join/#ghostscript ray_laptop (~chatzilla@150.sub-70-197-64.myvzw.com) 21:51.55 ray_laptop: so were you seeing the issue during writing or reading (clist) 21:52.07 I don't see any issues now with writing 21:52.23 all the profiles see to be getting freed with reference counting 21:52.27 s/see/seem/ 21:52.58 FORK(15595) --- fork starting for 'RSSFeeds', PID == 15595, bot_pid == 24375 --- 21:52.59 FORK(15595) !ERROR! cannot load my module: RSSFeeds 21:52.59 FORK(15595) fork: took 2s for RSSFeeds. 21:52.59 FORK(15595) --- fork finished for 'RSSFeeds' --- 21:53.12 when my cluster run is finished (assuming all is ok with it). would you mind checking if you still see the issue 21:55.33 Chans: (ghostbot) in:#ghostscript 21:58.08 >>> ray_laptop has signed off IRC (Read error: Connection reset by peer) [#ghostscript] 22:10.45 >>> join/#ghostscript Noldorin (~noldorin@unaffiliated/noldorin) 22:11.41 Chans: (ghostbot) in:#ghostscript 22:23.22 FORK(25860) --- fork starting for 'RSSFeeds', PID == 25860, bot_pid == 24375 --- 22:23.23 FORK(25860) !ERROR! cannot load my module: RSSFeeds 22:23.23 FORK(25860) fork: took 2s for RSSFeeds. 22:23.23 FORK(25860) --- fork finished for 'RSSFeeds' --- 22:23.38 >>> paulgardiner has signed off IRC (Read error: Connection reset by peer) [#ghostscript] 22:27.33 Chans: (ghostbot) in:#ghostscript 22:40.30 >>> join/#ghostscript marcosw2 (~marcos@c-98-207-109-212.hsd1.ca.comcast.net) 22:42.40 ray_laptop; for the logs when you get back. I am seing about a 5percent speed improvement with the fix on that file 22:42.56 not huge, but at least in the right direction 22:43.11 Chans: (ghostbot) in:#ghostscript 22:43.30 rayjj or mvrhel_laptop: I'm trying to figure out which version of Visual Studio I want to install on the Win7 regression machine. Is Visual Studio Express 2013 for Windows Desktop a reasonable choice? Or do I want Visual Studio Team Foundation Server Express 2013? 22:46.38 --- Saved uptime records. 22:47.53 Seen: Flushed 2 entries. 22:53.42 FORK(3944) --- fork starting for 'RSSFeeds', PID == 3944, bot_pid == 24375 --- 22:53.43 FORK(3944) !ERROR! cannot load my module: RSSFeeds 22:53.43 FORK(3944) fork: took 2s for RSSFeeds. 22:53.43 FORK(3944) --- fork finished for 'RSSFeeds' --- 22:57.22 marcosw2: team foundation server express isnt an ide 22:58.53 Chans: (ghostbot) in:#ghostscript 23:02.43 The express should be fine marcosw2 23:14.25 Chans: (ghostbot) in:#ghostscript 23:23.46 FORK(4691) --- fork starting for 'RSSFeeds', PID == 4691, bot_pid == 24375 --- 23:23.47 FORK(4691) !ERROR! cannot load my module: RSSFeeds 23:23.47 FORK(4691) fork: took 2s for RSSFeeds. 23:23.47 FORK(4691) --- fork finished for 'RSSFeeds' --- 23:37.24 >>> Noldorin has signed off IRC (Ping timeout: 246 seconds) [#ghostscript] 23:46.41 Chans: (ghostbot) in:#ghostscript 23:47.11 --- Saved uptime records. 23:48.57 Seen: Flushed 2 entries. 23:50.19 mvrhel_laptop: Why do we want anything newer than VS2005 installed? 23:50.32 All our projects build with VS2005. 23:54.00 FORK(10087) --- fork starting for 'RSSFeeds', PID == 10087, bot_pid == 24375 --- 23:54.01 FORK(10087) !ERROR! cannot load my module: RSSFeeds 23:54.01 FORK(10087) fork: took 2s for RSSFeeds. 23:54.01 FORK(10087) --- fork finished for 'RSSFeeds' --- 23:55.06 Robin_Watts: VS2005 would be fine 23:55.20 dang. thats old. 23:55.26 tell me about it 23:55.43 JakeSays: Anything newer than VS2005 loses compatability with old machines for no good reason. 23:55.58 i built mupdf earlier today with vs2012. worked fine. 23:56.24 Robin_Watts: well, the good reason is more $$ for ms. lol 23:59.39 I figured I should install the latest visual studio since the first thing we do when a ghostscript user complains about something being broken is to tell them to upgrade to the latest release.