00:00.15 Opened logfile log/20130322. 00:00.15 Chans: (ghostbot) in:#ghostscript 00:01.52 >>> tor8 has signed off IRC (Quit: tor8) [#ghostscript] 00:01.52 FORK(18998) --- fork starting for 'RSSFeeds', PID == 18998, bot_pid == 1004 --- 00:01.54 FORK(18998) !ERROR! cannot load my module: RSSFeeds 00:01.54 FORK(18998) fork: took 3s for RSSFeeds. 00:01.54 FORK(18998) --- fork finished for 'RSSFeeds' --- 00:11.40 marcosw: sorry. Yes, this was a bmpcmp run and subsequent localcluster runs (user runs) were fine. 00:12.16 open house at the middle school tonight. I might be back on later... 00:12.20 >>> ray_laptop has signed off IRC (Quit: ChatZilla 0.9.90 [Firefox 19.0.2/20130307023931]) [#ghostscript] 00:12.24 ray_laptop: that's what it looked like. a bmpcmp run didn't initialize some memory values. 00:16.27 Chans: (ghostbot) in:#ghostscript 00:22.20 >>> marcosw has signed off IRC (Quit: marcosw) [#ghostscript] 00:31.59 FORK(27647) --- fork starting for 'RSSFeeds', PID == 27647, bot_pid == 1004 --- 00:32.00 FORK(27647) !ERROR! cannot load my module: RSSFeeds 00:32.00 FORK(27647) fork: took 1s for RSSFeeds. 00:32.00 FORK(27647) --- fork finished for 'RSSFeeds' --- 00:32.16 >>> gandaro has signed off IRC (Read error: Connection reset by peer) [#ghostscript] 00:33.05 Chans: (ghostbot) in:#ghostscript 00:33.55 Seen: Flushed 2 entries. 00:34.05 --- Saved uptime records. 00:35.59 >>> JakeSaysSays materializes into JakeSays 00:46.11 ray_work: I strongly suspect that the bitmap only gets displayed at the end of rendering. 00:48.47 Chans: (ghostbot) in:#ghostscript 00:54.31 >>> paulgardiner has signed off IRC (Quit: ChatZilla 0.9.90 [Firefox 19.0.2/20130307023931]) [#ghostscript] 00:59.44 TTOTD: When outputting debugging to file, it helps if it all goes to the same file. 01:02.13 FORK(9601) --- fork starting for 'RSSFeeds', PID == 9601, bot_pid == 1004 --- 01:02.14 FORK(9601) !ERROR! cannot load my module: RSSFeeds 01:02.14 FORK(9601) fork: took 1s for RSSFeeds. 01:02.14 FORK(9601) --- fork finished for 'RSSFeeds' --- 01:03.03 tor8 or paulgardiner: (For the logs) http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=bf08301ded2f44e33bebf5572587a9c7102dcc98 01:04.39 Chans: (ghostbot) in:#ghostscript 01:32.21 FORK(15161) --- fork starting for 'RSSFeeds', PID == 15161, bot_pid == 1004 --- 01:32.22 FORK(15161) !ERROR! cannot load my module: RSSFeeds 01:32.22 FORK(15161) fork: took 1s for RSSFeeds. 01:32.22 FORK(15161) --- fork finished for 'RSSFeeds' --- 01:34.17 --- Saved uptime records. 01:34.17 Seen: Flushed 1 entries. 01:36.43 Chans: (ghostbot) in:#ghostscript 02:02.29 FORK(12704) LOG: last message repeated 3 times 02:02.29 FORK(12704) --- fork starting for 'RSSFeeds', PID == 12704, bot_pid == 1004 --- 02:02.30 FORK(12704) !ERROR! cannot load my module: RSSFeeds 02:02.30 FORK(12704) fork: took 1s for RSSFeeds. 02:02.30 FORK(12704) --- fork finished for 'RSSFeeds' --- 02:03.45 LOG: last message repeated 3 times 02:03.45 ircCheck: possible lost in space; checking.Fri Mar 22 02:03:45 2013 02:03.45 >ghostbot< TEST 02:03.45 IRCTEST: Yes, we're alive. 02:08.51 Chans: (ghostbot) in:#ghostscript 02:32.31 FORK(11574) --- fork starting for 'RSSFeeds', PID == 11574, bot_pid == 1004 --- 02:32.32 FORK(11574) !ERROR! cannot load my module: RSSFeeds 02:32.32 FORK(11574) fork: took 1s for RSSFeeds. 02:32.32 FORK(11574) --- fork finished for 'RSSFeeds' --- 02:34.57 --- Saved uptime records. 02:40.35 Chans: (ghostbot) in:#ghostscript 02:43.51 !WARN! PERL: readdir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 862. 02:43.51 !WARN! PERL: closedir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 869. 02:56.37 Chans: (ghostbot) in:#ghostscript 03:02.35 FORK(7453) --- fork starting for 'RSSFeeds', PID == 7453, bot_pid == 1004 --- 03:02.36 FORK(7453) !ERROR! cannot load my module: RSSFeeds 03:02.36 FORK(7453) fork: took 1s for RSSFeeds. 03:02.36 FORK(7453) --- fork finished for 'RSSFeeds' --- 03:04.18 >>> Robin_Watts has signed off IRC (Read error: Connection reset by peer) [#ghostscript] 03:04.45 >>> join/#ghostscript Robin_Watts (~chatzilla@109.176.211.239) 03:06.51 ircCheck: possible lost in space; checking.Fri Mar 22 03:06:51 2013 03:06.51 >ghostbot< TEST 03:06.51 IRCTEST: Yes, we're alive. 03:12.09 Chans: (ghostbot) in:#ghostscript 03:31.28 >>> join/#ghostscript marcosw (~marcosw@adsl-108-194-199-51.dsl.pltn13.sbcglobal.net) 03:32.43 FORK(1798) --- fork starting for 'RSSFeeds', PID == 1798, bot_pid == 1004 --- 03:32.44 FORK(1798) !ERROR! cannot load my module: RSSFeeds 03:32.44 FORK(1798) fork: took 1s for RSSFeeds. 03:32.44 FORK(1798) --- fork finished for 'RSSFeeds' --- 03:35.39 --- Saved uptime records. 03:40.35 >>> marcosw has signed off IRC (Quit: marcosw) [#ghostscript] 03:44.03 Chans: (ghostbot) in:#ghostscript 03:54.05 >>> tkamppeter has signed off IRC (Ping timeout: 246 seconds) [#ghostscript] 04:00.15 Chans: (ghostbot) in:#ghostscript 04:03.01 FORK(32431) --- fork starting for 'RSSFeeds', PID == 32431, bot_pid == 1004 --- 04:03.02 FORK(32431) !ERROR! cannot load my module: RSSFeeds 04:03.02 FORK(32431) fork: took 1s for RSSFeeds. 04:03.02 FORK(32431) --- fork finished for 'RSSFeeds' --- 04:06.45 >>> join/#ghostscript tkamppeter (~till@p5DDB95B2.dip.t-dialin.net) 04:10.45 ircCheck: possible lost in space; checking.Fri Mar 22 04:10:45 2013 04:10.45 >ghostbot< TEST 04:10.45 IRCTEST: Yes, we're alive. 04:16.37 Chans: (ghostbot) in:#ghostscript 04:23.25 whew. finally getting somewhere with the async calls in the windows app and keeping all the rendering thread safe. no mutex locks etc and I wanted to be able to render the document thumbnails but not block any full res resolution renderings while that is going on and of course no blocking of the UI 04:32.19 Chans: (ghostbot) in:#ghostscript 04:33.25 FORK(4238) --- fork starting for 'RSSFeeds', PID == 4238, bot_pid == 1004 --- 04:33.26 FORK(4238) !ERROR! cannot load my module: RSSFeeds 04:33.26 FORK(4238) fork: took 1s for RSSFeeds. 04:33.26 FORK(4238) --- fork finished for 'RSSFeeds' --- 04:35.05 Seen: Flushed 1 entries. 04:36.31 --- Saved uptime records. 04:45.57 closed 3 bugs that I think I have fixed recently (made a lot of changes that are in similar areas) and they no longer fail. (plus the original 3 bugs and 3 I found along the way, of course) 04:46.07 >>> join/#ghostscript marcosw (~marcosw@67.169.6.130) 04:47.01 bug scrub can be rewarding sometimes, but I hate when none of the bugs I think might be fixed are not 04:48.11 Chans: (ghostbot) in:#ghostscript 04:48.50 mvrhel_laptop: great! I look forward to seeing the windows viewer in all of its glory :-) 04:51.01 enough work for today. Tomorrow going to play with digital signing for Windows drivers :-( 04:51.21 doesn't look to hard -- just a lot of hoops to jump through. 04:52.02 mvrhel_laptop: do you have to deal with digital signing your viewer in order to get it to install nicely on Win8 (or is only drivers that they pick on) ? 04:58.39 ray_work, i'm writing a multi doc rendering lib, cross platform, and i plan to make it fully async too 04:59.18 >>> marcosw has signed off IRC (Quit: marcosw) [#ghostscript] 05:03.43 FORK(4754) --- fork starting for 'RSSFeeds', PID == 4754, bot_pid == 1004 --- 05:03.44 FORK(4754) !ERROR! cannot load my module: RSSFeeds 05:03.44 FORK(4754) fork: took 1s for RSSFeeds. 05:03.44 FORK(4754) --- fork finished for 'RSSFeeds' --- 05:04.33 Chans: (ghostbot) in:#ghostscript 05:08.56 vtorri: yes, I've seen you chatting w/ Robin_Watts and sometimes tor 05:09.21 vtorri: is your implementation on Windoze or what ? 05:09.32 cross platform 05:09.51 at least it will work for linux, widows and mac os x 05:09.53 vtorri: I know you said "cross platform", but which platforms 05:10.16 vtorri: are you using Qt or some other cross platform tools ? 05:10.24 other one 05:10.26 EFL 05:11.03 you konw them ? 05:11.06 vtorri: thanks. I'll check that out (and probably run screaming). Cross platform tools are nice, but have a large learning curve 05:11.15 indeed 05:11.20 at least when dealing with UI issues 05:12.33 check what can be done with the EFL: 05:12.35 http://www.rasterman.com/files/wp2.avi 05:15.39 this is the wallpaper selector of E17 05:16.03 i plan to do the same for an 'exposé' like effect 05:16.08 for my app 05:18.26 vtorri: reminiscent of an XPS viewer I saw Microsoft demoing about 3 years ago (before Win 7 was released) 05:19.20 vtorri: so the 'expose' will go from a thumbnail of pages to the page at full size ? 05:19.28 yes 05:19.36 cute 05:20.21 and if I want to then only see that page, I click on it or something ? And can return to the thumbnails somehow ? 05:20.32 yes 05:20.51 Chans: (ghostbot) in:#ghostscript 05:21.38 in the expose mode, you click on a thumbnail. The page is shown. 05:21.41 vtorri: well, good luck ! 05:21.54 time for bed... 05:22.05 you click elsewhere than on an icon, you return in the expose mode 05:22.19 click on the icon, and then, the page is really selected 05:22.29 thanks and good night 05:22.43 vtorri: can I see the pages without the icon tiles collected around the edge ? 05:23.14 yes 05:23.33 it will be different from that wallpaper selector 05:23.42 you have to read a document 05:23.43 OK. Thanks for the info. 05:23.55 so that doc must not have hidden parts 05:33.51 FORK(9136) --- fork starting for 'RSSFeeds', PID == 9136, bot_pid == 1004 --- 05:33.52 FORK(9136) !ERROR! cannot load my module: RSSFeeds 05:33.52 FORK(9136) fork: took 1s for RSSFeeds. 05:33.52 FORK(9136) --- fork finished for 'RSSFeeds' --- 05:35.37 Seen: Flushed 2 entries. 05:36.37 --- Saved uptime records. 05:37.53 Chans: (ghostbot) in:#ghostscript 05:41.19 ray_work: so yes, it has to be submitted and approved 05:42.17 but it windows8 does "install" it as is on my local machine. not sure about how it is shared and installed on others 05:43.14 I will have to look at that later. the way the async stuff works is taking me a little time to get used to . i would prefer if I had more control over threads in the standard way 05:54.25 Chans: (ghostbot) in:#ghostscript 06:04.05 FORK(6934) --- fork starting for 'RSSFeeds', PID == 6934, bot_pid == 1004 --- 06:04.06 FORK(6934) !ERROR! cannot load my module: RSSFeeds 06:04.06 FORK(6934) fork: took 1s for RSSFeeds. 06:04.06 FORK(6934) --- fork finished for 'RSSFeeds' --- 06:14.40 LOG: last message repeated 3 times 06:14.40 >>> join/#ghostscript oy (~oy@g225208188.adsl.alicedsl.de) 06:24.48 done for the night 06:24.50 good night all 06:26.20 Chans: (ghostbot) in:#ghostscript 06:29.19 >>> mvrhel_laptop has signed off IRC (Ping timeout: 252 seconds) [#ghostscript] 06:34.43 FORK(7646) --- fork starting for 'RSSFeeds', PID == 7646, bot_pid == 1004 --- 06:34.44 FORK(7646) !ERROR! cannot load my module: RSSFeeds 06:34.44 FORK(7646) fork: took 1s for RSSFeeds. 06:34.44 FORK(7646) --- fork finished for 'RSSFeeds' --- 06:35.39 Seen: Flushed 1 entries. 06:37.19 --- Saved uptime records. 06:42.47 Chans: (ghostbot) in:#ghostscript 06:43.57 !WARN! PERL: readdir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 862. 06:43.57 !WARN! PERL: closedir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 869. 06:58.49 Chans: (ghostbot) in:#ghostscript 07:05.17 FORK(9991) --- fork starting for 'RSSFeeds', PID == 9991, bot_pid == 1004 --- 07:05.18 FORK(9991) !ERROR! cannot load my module: RSSFeeds 07:05.18 FORK(9991) fork: took 1s for RSSFeeds. 07:05.18 FORK(9991) --- fork finished for 'RSSFeeds' --- 07:11.30 >>> chrisl_away materializes into chrisl 07:15.01 Chans: (ghostbot) in:#ghostscript 07:25.26 >>> vtorri has signed off IRC (Ping timeout: 252 seconds) [#ghostscript] 07:25.41 ircCheck: possible lost in space; checking.Fri Mar 22 07:25:41 2013 07:25.41 >ghostbot< TEST 07:25.41 IRCTEST: Yes, we're alive. 07:31.03 Chans: (ghostbot) in:#ghostscript 07:35.45 FORK(15310) --- fork starting for 'RSSFeeds', PID == 15310, bot_pid == 1004 --- 07:35.46 FORK(15310) !ERROR! cannot load my module: RSSFeeds 07:35.46 FORK(15310) fork: took 1s for RSSFeeds. 07:35.46 FORK(15310) --- fork finished for 'RSSFeeds' --- 07:37.31 --- Saved uptime records. 07:45.53 >>> join/#ghostscript kens (~Miranda@87.113.116.18) 07:46.35 Chans: (ghostbot) in:#ghostscript 07:58.14 kens: do we actually care about the pdfwrite/ps2write build "bug"?? 07:58.42 chrisl, imo no. I will look at it, but I suspect it is 'unfixable'. My solution is to remove one of teh '.,ak' files 07:58.48 .mak files* 07:59.05 I think the problem is that *noth* devices are defined in the same C source file 07:59.26 So you can't remove one of tehm just by removing C input files from the build 07:59.35 I think I can fix it, we're using a sort of "short cut" to handle the dependency 08:00.06 Although, I'm not totally sure....... 08:00.27 But the current behaviour is intentional 08:00.39 Hmm, why ? 08:01.08 From devs.mak: "Since ps2write actually is a clone of pdfwrite, we just depend on it." 08:01.35 Right, which is pretty much what I sadi in the bug report, these aren't so much devices in comman as the *same* device 08:02.12 Since the 2 devices are both defined in gdevpdf.c, I'm not at all sure how you could remove one of them. 08:02.33 Sure, as I say, it was clearly done this way on purpose - so it's not accidental 08:02.43 Chans: (ghostbot) in:#ghostscript 08:03.13 Yes, I see. I'm not bothereed myself, I was goinjg to propose removing one of the .mak files as a solution (having both does seem odd), but its up to you 08:03.41 The only alternative is to move the definition of ps2write into its own file and to be honest I can'tr see any point. 08:03.54 Its not like it would actually save anything 08:04.19 No, exactly - I'd close it "won't fix" 08:04.42 OK in that case I'll do so, just looking at the other one Macros raised, which is at least a bug :-) 08:05.29 Yeh, I'm looking at the tiff build one. 08:05.59 I passed on that one. The one to support this morning looks like a nightmare 08:05.59 FORK(31225) --- fork starting for 'RSSFeeds', PID == 31225, bot_pid == 1004 --- 08:06.00 FORK(31225) !ERROR! cannot load my module: RSSFeeds 08:06.00 FORK(31225) fork: took 1s for RSSFeeds. 08:06.00 FORK(31225) --- fork finished for 'RSSFeeds' --- 08:06.46 I've never seen anything like that error message 08:07.13 No me neither 08:07.54 Oh, I wonder if they are somehow spawning GS as a thread of execution, in which case it could be their app causing the problem. 08:08.16 Or the fact that GS doesn't clean up very well 08:08.25 I think that is what they're doing - it could be that stack problem that Ray just fixed 08:08.42 Of course their test app is written in something weird and M$ ish 08:10.14 C#? 08:10.23 It calls something that looks like it ought to start a 'process' but I wonder if it really spawns a thread. Not sure what langage this is, could well be C# yes 08:10.47 Well, based on the .cs 08:11.04 I'm looking at the code, which is 'sort of' like C++ 08:12.02 Yes its C# 08:12.45 Bit hard for us to help with that 08:13.12 Despite hte use of teh word 'process' I would guess its spawning a thread 08:13.19 That could explain the weird error message - it might be from the C# runtime 08:13.29 I think it is basically yes 08:13.50 I suspect that the GS executable is spawned as a thread and is therefore using the C# app address space. 08:14.24 Presumably our porr cleanup leaves stuff lying around and eventually it can't spawn a new process because it hasn't got enough memory. Or something like that. 08:15.01 I suppose using process explorer woudl show whether gswin32c is a prcoess or a thread 08:16.15 I'm struggling to find reference for this stuff to find what "new Process..." actually does 08:16.37 Fundamentally this is a pretty lousy way to run Ghostscript, or any other command line process, if teh above is true. It relies on the process cleaning up perfectly. Arguably the thread handler ought to clean up the memory used by the thread when it terminates of course, but this is Microsoft we're talking about 08:16.47 chrisl new is a C++ operator 08:16.59 Also C# 08:17.11 if you have vs installed look for System.Diagnositics.Process 08:17.22 In the 'SeaRCH' UNDER HELP 08:17.40 kens: no, the thread handler doesn't clean up memory - it doesn't work like a process completing 08:17.55 chrisl then if it is a thread, its not going to work well 08:18.21 THis is suspicious: 08:18.21 "A Process component provides access to a process that is running on a computer. A process, in the simplest terms, is a running application. A thread is the basic unit to which the operating system allocates processor time. A thread can execute any part of the code of the process, including parts currently being executed by another thread." 08:18.49 But then, Ghostscript shouldn't leak any resources - we certainly don't leak memory on Unix-like systems 08:18.54 Looks to me like it does run the process as a thread (nicely corrupted terminology MS) 08:19.11 chrisl GS has memory allocated when the process 08:19.11 Chans: (ghostbot) in:#ghostscript 08:19.16 exits 08:19.32 It does not clean up 100% 08:19.45 Hmm, well, it does on Unix..... 08:19.59 It certainly does not on Windows, according to Memento 08:20.30 And when I brought it up (pdfwrite memory cleanup) I was told that this was known and nobody cared because its all one-time allocations that get freed when the process exits 08:21.13 One of the last things the code does is shut down the memory manager(s) and that releases all the memory - valgrind reports no leaked blocks on Linux 08:21.38 Well I guess maybe Memento can't catch that 08:21.56 If someone runs their application it should be easy enough to see if the memory usage is increasing. 08:22.32 Do you know what the leaked memory is for? IIRC, the Jaws "GUI" app left memory allocated on exit for the Windows gui crap 08:22.37 Its also possible that the memory simply becomes fragmented, and not enough contiguous memory is available to lauch the large) Ghostscript executable 08:22.59 Not GUI stuff, this was stuff reported by Memento 08:23.21 It still could be text buffers and stuff like that 08:23.58 I don't know, it wasn't what I was cahsing so I ignored it. Made my life a bit harder because I had to sift my allocations out at the end 08:25.41 Mind you, 576 dpi - add in a bit of transparency, and that could use a *lot* of memory....... 08:26.12 Yeah its fairly high resolution, but the file appears to be text only (I didn't chec all 400 pages) 08:26.51 Oh, well it shouldn't be a problem...... 08:28.48 Hmm, well, if my cursory reading is right, that code should be creating a process, not a thread 08:29.40 chrisl it says process, but the doc (see above) says 'a thread is the basic unit to which the operating system allocates processor time' 08:29.59 I don't trust MS to make a proper ditinction between threads and processes. 08:30.14 Yes, but there are specific c# calls to spawn a thread 08:30.15 THe only way to tel is probably going to be to run their test app :-( 08:30.50 Well if we aren't spawning a thread (I don't think their command line does that), its hard to see how we can be responsible for a thread error. 08:31.32 Except that all processes are threads (but not all threads are processes) 08:31.55 Well I'm going to get on with real work and leave it just now 08:32.50 I wonder if they're exhausting resources before the c# garbage collector runs - I wonder if explicitly destroying the object would help...... 08:33.03 I don't know, its worth trying 08:33.12 If you can reproduce the problem... 08:34.05 of course if it truly does generate a random set of pages, then its definitely going to be awkward to reproduce 08:34.21 indeterminate test harnesses don't really help 08:34.51 Chans: (ghostbot) in:#ghostscript 08:36.07 Seen: Flushed 2 entries. 08:36.18 FORK(21186) --- fork starting for 'RSSFeeds', PID == 21186, bot_pid == 1004 --- 08:36.19 FORK(21186) !ERROR! cannot load my module: RSSFeeds 08:36.19 FORK(21186) fork: took 2s for RSSFeeds. 08:36.19 FORK(21186) --- fork finished for 'RSSFeeds' --- 08:36.49 No, I'm not going to volunteer for this one..... 08:37.10 * chrisl/#ghostscript (quoting Robin_Watts) touches nose! 08:37.26 * kens/#ghostscript has finger on nose also 08:37.36 --- Saved uptime records. 08:38.16 Okay, back to makefile fun....... 08:38.37 Not done my morning Stack Overflow review yet.... 08:51.03 Chans: (ghostbot) in:#ghostscript 08:55.30 >>> setmeaway has signed off IRC (Read error: Connection reset by peer) [#ghostscript] 08:55.48 >>> join/#ghostscript setmeaway (setmeaway3@119.201.52.130) 09:06.45 Chans: (ghostbot) in:#ghostscript 09:06.45 FORK(12257) --- fork starting for 'RSSFeeds', PID == 12257, bot_pid == 1004 --- 09:06.47 FORK(12257) !ERROR! cannot load my module: RSSFeeds 09:06.47 FORK(12257) fork: took 2s for RSSFeeds. 09:06.47 FORK(12257) --- fork finished for 'RSSFeeds' --- 09:36.13 >>> join/#ghostscript gandaro (~gandaro@wikipedia/Gorlingor) 09:36.33 Seen: Flushed 2 entries. 09:36.53 FORK(26210) --- fork starting for 'RSSFeeds', PID == 26210, bot_pid == 1004 --- 09:36.54 FORK(26210) !ERROR! cannot load my module: RSSFeeds 09:36.54 FORK(26210) fork: took 1s for RSSFeeds. 09:36.54 FORK(26210) --- fork finished for 'RSSFeeds' --- 09:37.49 --- Saved uptime records. 09:38.59 Chans: (ghostbot) in:#ghostscript 09:38.59 ircCheck: possible lost in space; checking.Fri Mar 22 09:38:59 2013 09:38.59 >ghostbot< TEST 09:39.00 IRCTEST: Yes, we're alive. 09:42.21 >>> join/#ghostscript tor8 (~tor@c-267571d5.04-50-6c756e10.cust.bredbandsbolaget.se) 09:56.07 Chans: (ghostbot) in:#ghostscript 10:02.09 >>> join/#ghostscript sojic (~sojic@77.29.52.43) 10:06.57 FORK(24676) --- fork starting for 'RSSFeeds', PID == 24676, bot_pid == 1004 --- 10:06.59 FORK(24676) !ERROR! cannot load my module: RSSFeeds 10:06.59 FORK(24676) fork: took 2s for RSSFeeds. 10:06.59 FORK(24676) --- fork finished for 'RSSFeeds' --- 10:11.39 Chans: (ghostbot) in:#ghostscript 10:30.41 Morning tor8. More reviews on robin/master for you. 10:37.05 Seen: Flushed 1 entries. 10:37.06 FORK(2537) --- fork starting for 'RSSFeeds', PID == 2537, bot_pid == 1004 --- 10:37.07 FORK(2537) !ERROR! cannot load my module: RSSFeeds 10:37.07 FORK(2537) fork: took 2s for RSSFeeds. 10:37.07 FORK(2537) --- fork finished for 'RSSFeeds' --- 10:38.05 --- Saved uptime records. 10:44.13 !WARN! PERL: readdir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 862. 10:44.13 !WARN! PERL: closedir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 869. 10:44.53 Chans: (ghostbot) in:#ghostscript 11:02.09 LOG: last message repeated 3 times 11:02.09 >>> join/#ghostscript paulgardiner (~chatzilla@smtp.glidos.net) 11:04.09 Robin_Watts: store debugging fns LGTM 11:06.17 tor8: D'oh. 2 more there now that I'd forgotten to push. 11:06.47 For the reflow stuff, would it be easier if I made a branch with the commits all squashed? 11:07.27 FORK(14026) --- fork starting for 'RSSFeeds', PID == 14026, bot_pid == 1004 --- 11:07.28 FORK(14026) !ERROR! cannot load my module: RSSFeeds 11:07.28 FORK(14026) fork: took 1s for RSSFeeds. 11:07.28 FORK(14026) --- fork finished for 'RSSFeeds' --- 11:16.53 Chans: (ghostbot) in:#ghostscript 11:21.29 Robin_Watts: or a few squashed by category 11:21.50 >>> join/#ghostscript setmeaway2 (setmeaway3@118.45.149.119) 11:25.08 >>> setmeaway has signed off IRC (Ping timeout: 245 seconds) [#ghostscript] 11:31.31 tor8, paulgardiner: I'm going to spend a couple of hours trying to reduce the noise in the reflow branch to make it easier for you guys. 11:31.50 so, unless you've started already, don't start looking! :) 11:32.23 Ok. Let us know when it's ready 11:33.35 Chans: (ghostbot) in:#ghostscript 11:34.00 >>> Fandekasp has signed off IRC (Ping timeout: 256 seconds) [#ghostscript] 11:37.37 Seen: Flushed 3 entries. 11:37.48 FORK(21493) --- fork starting for 'RSSFeeds', PID == 21493, bot_pid == 1004 --- 11:37.49 FORK(21493) !ERROR! cannot load my module: RSSFeeds 11:37.49 FORK(21493) fork: took 2s for RSSFeeds. 11:37.49 FORK(21493) --- fork finished for 'RSSFeeds' --- 11:38.08 --- Saved uptime records. 11:49.27 Chans: (ghostbot) in:#ghostscript 12:08.06 FORK(11866) --- fork starting for 'RSSFeeds', PID == 11866, bot_pid == 1004 --- 12:08.07 FORK(11866) !ERROR! cannot load my module: RSSFeeds 12:08.07 FORK(11866) fork: took 2s for RSSFeeds. 12:08.07 FORK(11866) --- fork finished for 'RSSFeeds' --- 12:14.21 paulgardiner: There is a pdf_device commit waiting on robin/master that you might want to look at. 12:18.24 >>> join/#ghostscript daiane (bb0bcac4@gateway/web/freenode/ip.187.11.202.196) 12:21.41 Chans: (ghostbot) in:#ghostscript 12:21.57 >>> daiane has signed off IRC (Client Quit) [#ghostscript] 12:22.16 Looking... and at the fixing of warnings 12:37.33 Chans: (ghostbot) in:#ghostscript 12:38.13 Seen: Flushed 2 entries. 12:38.14 FORK(2060) --- fork starting for 'RSSFeeds', PID == 2060, bot_pid == 1004 --- 12:38.15 FORK(2060) !ERROR! cannot load my module: RSSFeeds 12:38.15 FORK(2060) fork: took 2s for RSSFeeds. 12:38.15 FORK(2060) --- fork finished for 'RSSFeeds' --- 12:38.29 --- Saved uptime records. 12:38.54 Robin_Watts: Unlikely to matter I guess, but should diff be set to 1 also when the colorspace changes? 12:39.06 paulgardiner: It should. Do i not do that? 12:39.42 Isn't that what the first hunk of the diff does? 12:39.44 :-) Sorry, I'm looking I was looking at my local copy for the sake of checking the warning fixes, and I carried on looking at it 12:39.54 ah! :) 12:40.15 Those two commits look fine. 12:40.25 I obviously only got 1/2 way through that code :) 12:41.16 Yeah. That's partly what confused me: the old copy seemed to have the intention of handling the case 12:42.24 Robin_Watts: warnings look fine 12:42.37 tor8, paulgardiner: Thanks. 12:53.55 Chans: (ghostbot) in:#ghostscript 13:08.48 FORK(32332) --- fork starting for 'RSSFeeds', PID == 32332, bot_pid == 1004 --- 13:08.49 FORK(32332) !ERROR! cannot load my module: RSSFeeds 13:08.49 FORK(32332) fork: took 1s for RSSFeeds. 13:08.49 FORK(32332) --- fork finished for 'RSSFeeds' --- 13:16.41 >>> join/#ghostscript chrisl_r61 (~chrisl_r6@cpc1-ando5-2-0-cust33.15-1.cable.virginmedia.com) 13:17.26 >>> join/#ghostscript Fandekasp (~Fandekasp@platinum-static25142.nirai.ne.jp) 13:26.05 Chans: (ghostbot) in:#ghostscript 13:27.26 >>> sojic has signed off IRC (Remote host closed the connection) [#ghostscript] 13:31.52 >>> Fandekasp has signed off IRC (Ping timeout: 256 seconds) [#ghostscript] 13:33.07 >>> join/#ghostscript Fandekasp (~Fandekasp@platinum-static25142.nirai.ne.jp) 13:38.03 >>> Fandekasp has signed off IRC (Ping timeout: 245 seconds) [#ghostscript] 13:38.53 FORK(23642) --- fork starting for 'RSSFeeds', PID == 23642, bot_pid == 1004 --- 13:38.54 FORK(23642) !ERROR! cannot load my module: RSSFeeds 13:38.54 FORK(23642) fork: took 1s for RSSFeeds. 13:38.54 FORK(23642) --- fork finished for 'RSSFeeds' --- 13:39.03 --- Saved uptime records. 13:39.13 Seen: Flushed 3 entries. 13:41.57 Chans: (ghostbot) in:#ghostscript 13:43.42 >>> join/#ghostscript sojic (~sojic@77.29.52.43) 13:44.22 >>> join/#ghostscript Fandekasp (~Fandekasp@platinum-static25142.nirai.ne.jp) 13:46.37 >>> paulgardiner has signed off IRC (Quit: ChatZilla 0.9.90 [Firefox 19.0.2/20130307023931]) [#ghostscript] 13:47.47 ircCheck: possible lost in space; checking.Fri Mar 22 13:47:47 2013 13:47.47 >ghostbot< TEST 13:47.47 IRCTEST: Yes, we're alive. 13:50.22 >>> Fandekasp has signed off IRC (Remote host closed the connection) [#ghostscript] 13:50.37 >>> join/#ghostscript Fandekasp (~Fandekasp@platinum-static25142.nirai.ne.jp) 13:56.38 >>> join/#ghostscript paulgardiner (~chatzilla@smtp.glidos.net) 13:58.35 Chans: (ghostbot) in:#ghostscript 14:00.16 >>> Fandekasp has signed off IRC (Ping timeout: 252 seconds) [#ghostscript] 14:02.20 >>> join/#ghostscript Guest48324 (~Fandekasp@platinum-static25142.nirai.ne.jp) 14:09.06 FORK(17153) --- fork starting for 'RSSFeeds', PID == 17153, bot_pid == 1004 --- 14:09.07 FORK(17153) !ERROR! cannot load my module: RSSFeeds 14:09.07 FORK(17153) fork: took 2s for RSSFeeds. 14:09.07 FORK(17153) --- fork finished for 'RSSFeeds' --- 14:13.17 >>> join/#ghostscript mvrhel_laptop (~chatzilla@c-24-17-196-27.hsd1.wa.comcast.net) 14:13.57 Chans: (ghostbot) in:#ghostscript 14:23.47 wow adobe is doing really well revenues wise with the $50 a month creative cloud. I'm surprised these apps with very heavy UI's don't have latency problems over the web. I can't imagine something like freehand drawing with a stylus would keep up with an artist. 14:24.44 >>> join/#ghostscript marcosw (~marcosw@67.169.6.130) 14:29.59 Chans: (ghostbot) in:#ghostscript 14:30.10 tor8, paulgardiner: OK. Reflow branch rejigged. 14:30.23 I think that's better. I'm going diff blind though. 14:31.45 There are some xps files that seem to show up as changed quite a lot in mupdf regresion runs. 14:32.10 Seem to involve xeon and macpro a lot. 14:38.15 1 trivial fix on robin/master 14:38.24 tor8, paulgardiner: ^ 14:39.34 Seen: Flushed 2 entries. 14:39.34 --- Saved uptime records. 14:39.55 FORK(11206) --- fork starting for 'RSSFeeds', PID == 11206, bot_pid == 1004 --- 14:39.56 FORK(11206) !ERROR! cannot load my module: RSSFeeds 14:39.56 FORK(11206) fork: took 2s for RSSFeeds. 14:39.56 FORK(11206) --- fork finished for 'RSSFeeds' --- 14:42.02 trivial fix fine 14:42.17 Thanks. 14:42.37 I'm doing less well at checking the reflow stuff. There is a lot of it 14:42.56 Android changes look fine 14:44.10 paulgardiner: Yeah, there is a fair amount of reflow stuff, and I'm prepared to believe that you/tor might see bits you want changed before we take it on. 14:44.33 (although I hope we might be able to take it on and then refine it, but...) 14:45.01 !WARN! PERL: readdir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 862. 14:45.01 !WARN! PERL: closedir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 869. 14:45.14 Any particular parts that you thought might be objectional? 14:45.27 Not really. 14:45.51 There is a bubblesort hidden in there somewhere. 14:46.01 Chans: (ghostbot) in:#ghostscript 14:49.53 chrisl:was the problem to that all generated files should go to one directory fixed? Before we were seeing tiff stuff created in the tiff tree, I meant to put that on the agenda. 14:51.57 marcosw:since the policy is customers only at support@artifex.com I don't think bugzilla should have any default assignments going to support, are you okay with that. I can fix it or you can, wanted to run it by you first at least. 14:53.35 So I can reproduce the macpro vs other xps diffs. 14:53.56 I wonder if this is to do with atof or sscanf being different on the macpro ? 14:54.55 Robin_Watts: I'm not seeing anything I don't like 14:56.23 paulgardiner: That's good to know. I spent so long staring at that code I think I've lost all perspective on it :) 15:02.44 Chans: (ghostbot) in:#ghostscript 15:08.04 Hmm, the command lines have disappeared from the cluster log files :-( 15:08.46 Still int the ones I see 15:09.47 chrisl_r61 I wrote to chrisl above don't know if you saw it. 15:10.07 FORK(5467) --- fork starting for 'RSSFeeds', PID == 5467, bot_pid == 1004 --- 15:10.09 FORK(5467) !ERROR! cannot load my module: RSSFeeds 15:10.09 FORK(5467) fork: took 2s for RSSFeeds. 15:10.09 FORK(5467) --- fork finished for 'RSSFeeds' --- 15:10.34 henrys: sorry, I didn't - no not fixed yet, other crap keeps hitting my queue before it..... 15:11.08 chrisl_r61:I can create a bug if you want, let me know 15:11.38 henrys: no necessary - it is written on the whiteboard in my office, so I won't forget! 15:11.44 s/no/not 15:12.14 kens: the local push I just did, the log files are "formatted" timing, md5 etc 15:12.22 Hmm 15:12.41 Oh, hang on a sec..... 15:12.46 Not what I'm seeing for my last set 15:12.57 AH you are looking at result email 15:13.03 you need individual machine logs 15:13.54 Oh, that is odd - I have two browser tabs open, both the same address, one shows the "formatted" log, and one the old style "dump" I was expecting..... 15:15.31 Well, confusing, but I have the command line I needed. 15:15.37 :) 15:19.22 Chans: (ghostbot) in:#ghostscript 15:39.36 LOG: last message repeated 3 times 15:39.36 Seen: Flushed 5 entries. 15:39.56 --- Saved uptime records. 15:40.16 FORK(4483) --- fork starting for 'RSSFeeds', PID == 4483, bot_pid == 1004 --- 15:40.17 FORK(4483) !ERROR! cannot load my module: RSSFeeds 15:40.17 FORK(4483) fork: took 1s for RSSFeeds. 15:40.17 FORK(4483) --- fork finished for 'RSSFeeds' --- 15:47.52 tor8: To run mudraw on an exploded xps file, what bit do I point it at again? 15:48.20 _rels/.rels 15:49.05 error: cannot find end of central directory 15:50.01 kens: I am looking at your comment on 693722. We have many instances of modules that include MANY devices, but not all of the devices get built in. For example, pamcmyk is in gdevpbm.c but is not part of the standard Windows build 15:50.58 kens: so why does the device list get populated with the pdfwrite device ? (I know all the files will still be linked in, but that is different) 15:51.13 Robin_Watts: odd... 15:51.25 ./_rels/.rels works. 15:51.29 that means it doesn't detect it being a xps-in-a-directory 15:51.29 Chans: (ghostbot) in:#ghostscript 15:51.47 It needs "/_rels/.rels" in the path "_rels/.rels" isn't enough 15:52.03 1ray as far as I understand it,the macros defining the devices caus ehtem to be defined. SO if you include a source file with a macro definition of a device then that device is included. Is this not correct / 15:52.32 Robin_Watts: what you said :) I just checked too. 15:53.02 kens: I am looking at what might be wrong in the makefiles... 15:53.15 kens: AIUI, including a source file is NOT enough to get all the devices that that source file defines included. 15:53.28 ray_work: there is *nothing* wrong in the makefiles, it was intentionally written that way 15:54.03 kens: OK. the problem is that the ps2write.dev does ADDMOD $(DD)ps2write -include $(DD)pdfwrite.dev 15:54.03 ray_work: there is even a comment in the makefile making it clear it was intentional 15:54.21 ray_work : see chrisl comment above and the note in the bug thread 15:54.25 ray_work: that's not a problem!!! 15:56.50 kens: (and chrisl): just because it was "intentional" (not sure it wasn't just for convenience) doesn 15:57.09 doesn't mean that it is very difficult to fix. 15:57.23 No, but I don't see it as a major problem eitgher 15:57.26 Of course it was just for convenience - but what benefit do we derive from changing it? 16:01.49 kens: I was commenting on your statements that there is no way to do this. It's actually quite simple -- the problem is the -include pdfwrite.dev invokes uses the SETDEV2 macro 16:02.25 so it's only a couple of lines to change it 16:02.28 ray_work : I detest the way we define devices, and I'm no expert on teh build. I did say if it bothred Marecos enough he could raise it as a build issue 16:03.09 marcosw: is it worth fixing ? If so I'll develop the patch and pass it to chrisl for review 16:03.34 kens: I assume marcosw had a reason to open the bug in the first place. 16:03.51 I have no idea, apart from the fatc that it's 'differnt' to other devies 16:04.01 Because he didn't say why this was a problem 16:04.59 kens: just for the record, the SETMOD just defines a helper .dev module (usually a library or collection of modules). The SETDEV2 is what also puts the device into the device list 16:07.08 Chans: (ghostbot) in:#ghostscript 16:09.25 kens: so if what is there now for the pdfwrite.dev : target instead were to be changed to a pdflib.dev target then this BOTH the ps2write.dev and the pdfwrite.dev just become two line definitions that -include pdflib.dev 16:10.08 (well, maybe three line definitions) 16:10.16 ray_work: why do you care? 16:10.47 FORK(29136) --- fork starting for 'RSSFeeds', PID == 29136, bot_pid == 1004 --- 16:10.48 FORK(29136) !ERROR! cannot load my module: RSSFeeds 16:10.48 FORK(29136) fork: took 2s for RSSFeeds. 16:10.48 FORK(29136) --- fork finished for 'RSSFeeds' --- 16:11.04 chrsl: why do I want to make sure kens knows why it happens, and that there is an easy way to fix it ? 16:11.21 * kens/#ghostscript is not interested 16:11.42 kens: perfectly fine with me. 16:12.15 Mostly I don't like incorrect information being spread in the bug tracker, because people might get confused 16:14.26 Having one (set of) devices that works differently to others is bad. We should strive for consistency. 16:14.55 A consistently mad build system is better than an inconsistently mad one :) 16:14.59 Robin_Watts: so you are thinking that's why marcosw opened the bug ? 16:15.24 I'll wait until marcosw weighs in... 16:15.56 It sounds like it confused marcosw. And if it confuses marcosw it's entirely possible it'll confuse other people. 16:16.51 It's worth noting that I've never found anyone that was entirely happy with the build system they were used. I think it's a fact of nature that everyone will consider their build system to be suboptimal. 16:17.41 Robin_Watts: well, ghostscript's build system is a bit more arcane than many -- what with all the 'helper' generated programs 16:18.31 ray_work: Everyones build system has quirks such as that. Everyone believes that their system is worse than everyone elses. 16:19.09 a clue that there shouldn't be build systems 16:19.42 * Robin_Watts/#ghostscript should introduce henrys to Julian Smith one day :) 16:20.18 henrys: right. we should go back to the good old days of just compiling each file by itself, then putting all the object files on a link command line ;-) 16:20.50 at least we don't use Jam (anymore) 16:22.37 who is juilan smith 16:22.39 ? 16:23.03 friend of mine. one of the guys behind undodb. 16:23.33 Chans: (ghostbot) in:#ghostscript 16:23.35 Has written at least 2 build systems that I know of. 16:24.23 Is extremely good at pointing at things in computing and saying "but we've been doing that wrong for years". 16:33.52 >>> sojic has signed off IRC (Remote host closed the connection) [#ghostscript] 16:39.32 Chans: (ghostbot) in:#ghostscript 16:39.52 Seen: Flushed 6 entries. 16:40.12 --- Saved uptime records. 16:40.58 FORK(9181) --- fork starting for 'RSSFeeds', PID == 9181, bot_pid == 1004 --- 16:40.59 FORK(9181) !ERROR! cannot load my module: RSSFeeds 16:40.59 FORK(9181) fork: took 1s for RSSFeeds. 16:40.59 FORK(9181) --- fork finished for 'RSSFeeds' --- 16:41.40 Robin_Watts, kens, chrisl, and ray_work: I opened bug 693722 because I wasted a bunch of time trying to build a gs without the pdfwrite device and couldn't. I needed gs without pdfwrite for bug 693721. I also tried building with just the TIFF devices, but that didn't work either (which explains bug 693720). 16:50.23 pdfwrite.dev and ps2write.dev being inseparable is a bug according to the documentation (see doc/Make.htm#Features_and_devices, which says you may omit devices by removing them from the DEVICE_DEVS definition in the Makefile, removing pdfwrite.dev from the Makefile does not remove it from the build). I suppose kens will argue that it's a documentation error :-) 16:50.48 That or a build prcoess bug, its *NOT* mine. 16:51.02 no kens argued - assign it to chrisl as I recall. 16:52.55 ray_work, marcosw ^^^ 16:53.16 >>> join/#ghostscript ray_laptop (~chatzilla@rrcs-64-183-45-163.west.biz.rr.com) 16:54.18 marcosw: I just posted a patch (tested on my Windows build) that works. see bug 693722 16:55.24 I don't see any harm in making the change, but I'll leave it up to the rest of you to duke out 16:55.54 Chans: (ghostbot) in:#ghostscript 16:56.23 ray_work:I don't like calling something a lib that isn't but I'll stay out of it too. 16:57.03 I don't care what it's called. That is also a trivial change: pdfstuff.dev is fine with me :-) 16:58.08 pdfwritecore.dev ? 16:58.22 pdfwrshared or pdfwrcommon also (or what Robin_Watts said). 16:58.34 Robin_Watts: any of those is fine by me. 16:58.35 the point of posting the patch was to show _how_ to do it 16:58.39 common is nice. 16:59.42 Robin_Watts: we used to have to keep .dev names to 8 char, but I think we abandoned that since all systems have long filenames (at least the build systems) 16:59.54 pdfwrcore ? 17:00.32 IF we're abandoning 8 chars, then let's abandon 9 too. pdfwritecommon seems nicest to me. 17:00.49 but I'm only involved in this cos I'm nosey, so feel free to ignore me :) 17:01.49 in the interest of ruffling feathers: code review works again … ;-) 17:02.30 henrys: in this case, the feathers were ruffled by my review of the bug commentary. 17:08.23 chrisl: A makefile question for you (new topic -- I'm done with the previous one). gs.mak lines 376 and 377 set FEATURE_DEVS_EXTRA= and DEVICE_DEVS_EXTRA= (no contents). With stoopid nmake, this redefines the macros, making the intended use non-functional 17:09.06 chrisl: do we really need these? undefined macros are harmless in all makes that I know of. 17:09.24 they just default to an empty string 17:09.24 ray_laptop: okay, I wasn't aware of what the intended purpose was.... was can probably remove the assignments 17:10.18 ray_laptop: We could protect them with a conditional 17:10.26 chrisl: this works OK on linux make (and most other make implementations) because they don't assign something that already has a value 17:11.04 ray_laptop: as I say, we can make them conditional on not being defined already 17:11.04 FORK(22565) --- fork starting for 'RSSFeeds', PID == 22565, bot_pid == 1004 --- 17:11.05 FORK(22565) !ERROR! cannot load my module: RSSFeeds 17:11.05 FORK(22565) fork: took 1s for RSSFeeds. 17:11.05 FORK(22565) --- fork finished for 'RSSFeeds' --- 17:11.14 chrisl: we don't allow conditional statements in the shared .mak files (like lib.mak and gs.mak) since those also are not the same on different makes 17:11.34 Chans: (ghostbot) in:#ghostscript 17:11.44 ray_laptop: oh, sorry I thought you were in a windows specific file 17:11.54 only the top makefiles that are specific to a particular build system can have conditionals 17:12.31 Well, as I said, removing is probably fine 17:13.07 chrisl: I found a couple of other problems with these optional macros in msvc.mak as well so if you don't object, I'll fix them in the same patch 17:13.26 ray_laptop: sure, no problem 17:14.21 the other problem is that the 'nmake' invocations for the other targets don't populate the invocation with FEATURE_DEVS_EXTRA=$(FEATURE_DEVS_EXTRA) (same for DEVICE_DEVS_EXTRA) 17:14.50 that's the problem with nested nmake invocations :-( 17:15.47 as the common/msvc_top.mak shows. 17:16.16 it would be so much nicer if the macros were inherited 17:16.51 chrisl: unix make does inherit macro values, doesn't it ? 17:17.45 ray_laptop: I think it does, it uses environment variables - but I would prefer to fix it properly than rely on that 17:18.30 chrisl: mess up the unix make to add all of the junk that msvc_top.mak has ? Noooooo... 17:19.13 ray_laptop: okay, we'll not worry about it then 17:19.50 this is already a nightmare because the pcl make has to be manually maintained every time we add a macro (and we -- the gs-centric folks -- usually forget) 17:20.32 ray_laptop: that's why I want to have pcl/xps built "properly" by the gs build system - as discussed at the staff meeting 17:20.43 chrisl: I meant that if you really want to do that to the unix makefiles, fine. As long as you keep them up to date 17:22.51 ray_laptop: no, let's not worry about it 17:23.46 chrisl: currently msvc_top.mak has 62 macros that it passes down into the nmake !!! 17:24.20 and I have no idea if that is a complete list :-( 17:25.30 chrisl: I hope you can get things straightened out. I don't envy you. Maybe you can put pharmaceuticals on your expense report ;-) 17:25.46 :-) 17:26.05 or at least hair replacement treatments 17:27.25 Chans: (ghostbot) in:#ghostscript 17:40.04 Seen: Flushed 7 entries. 17:40.24 --- Saved uptime records. 17:41.50 FORK(4350) --- fork starting for 'RSSFeeds', PID == 4350, bot_pid == 1004 --- 17:41.51 FORK(4350) !ERROR! cannot load my module: RSSFeeds 17:41.51 FORK(4350) fork: took 1s for RSSFeeds. 17:41.51 FORK(4350) --- fork finished for 'RSSFeeds' --- 17:43.30 Chans: (ghostbot) in:#ghostscript 18:07.24 >>> kens has signed off IRC (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) [#ghostscript] 18:11.58 FORK(5948) --- fork starting for 'RSSFeeds', PID == 5948, bot_pid == 1004 --- 18:11.59 FORK(5948) !ERROR! cannot load my module: RSSFeeds 18:11.59 FORK(5948) fork: took 1s for RSSFeeds. 18:11.59 FORK(5948) --- fork finished for 'RSSFeeds' --- 18:15.40 Chans: (ghostbot) in:#ghostscript 18:18.58 >>> chrisl materializes into chrisl_away 18:31.22 Chans: (ghostbot) in:#ghostscript 18:31.22 ircCheck: possible lost in space; checking.Fri Mar 22 18:31:22 2013 18:31.22 >ghostbot< TEST 18:31.22 IRCTEST: Yes, we're alive. 18:32.28 >>> ray_laptop has signed off IRC (Ping timeout: 252 seconds) [#ghostscript] 18:36.18 So, we're getting different FP results on macpro and on windows. 18:36.30 a + (b-a)*d 18:37.42 where *(int*)&a = 0x3f800000 *(int *)&b = 3e40c0c1 *(int *)&d = 0x3e40c0c0 18:38.37 Sorry. *(int *)&d = 0x3f800000 18:39.15 macpro gives result r, where *(int *)&r = 0x3e40c0c0 18:39.30 wheras windows gives 0x3e40c0c1 18:40.26 Seen: Flushed 1 entries. 18:41.06 --- Saved uptime records. 18:41.44 3f800000 = 1.0, so it seems that windows is right :) 18:42.04 FORK(26147) --- fork starting for 'RSSFeeds', PID == 26147, bot_pid == 1004 --- 18:42.05 FORK(26147) !ERROR! cannot load my module: RSSFeeds 18:42.05 FORK(26147) fork: took 1s for RSSFeeds. 18:42.05 FORK(26147) --- fork finished for 'RSSFeeds' --- 18:42.06 If simple FP can vary between machines, how is the cluster ever working!? 18:44.52 >>> join/#ghostscript ray_laptop (~chatzilla@cpe-76-171-54-81.socal.res.rr.com) 18:45.08 !WARN! PERL: readdir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 862. 18:45.08 !WARN! PERL: closedir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 869. 18:47.34 Chans: (ghostbot) in:#ghostscript 19:06.31 tor8, paulgardiner: 2 small patches on robin/master 19:10.36 >>> ray_laptop has signed off IRC (Ping timeout: 252 seconds) [#ghostscript] 19:11.23 Robin_Watts: Look fine, although I'm astounded that those two versions could give different results. 19:11.42 paulgardiner: It's a difference in the bottom bit. 19:12.30 FORK(14831) --- fork starting for 'RSSFeeds', PID == 14831, bot_pid == 1004 --- 19:12.31 FORK(14831) !ERROR! cannot load my module: RSSFeeds 19:12.31 FORK(14831) fork: took 1s for RSSFeeds. 19:12.31 FORK(14831) --- fork finished for 'RSSFeeds' --- 19:15.45 If it had been a + b +c I'd guess it was down to non-associativity, but you'd think there was only one way to calculat a + (b - a) *x ... unless it was being really clever and making it b * x + a * (1-x) 19:16.18 why would that be clever? That's 2 muls instead of 1. 19:19.48 Chans: (ghostbot) in:#ghostscript 19:20.36 1 more patch, also tiny. 19:25.18 Yeah, that makes no sense, so the only freedom it has is commutability. Surely that would count as a processor bug if plus or times didn't commute 19:25.43 paulgardiner: You would hope that a + (b-a)*1 = b 19:26.05 but my fix makes all the machines make a+(b-a)*1 be not quite b. 19:27.56 I'm less surprised at that than at there being two possibly values. 19:28.21 Was x == 1 the only failing case? 19:28.47 x == 1 was the case I spotted. 19:29.26 I fear this same problem may occur elsewhere in the code (like in the antialiasing code). So it may not be possible to get it consistent :( 19:29.51 even with this fix in, I'm seeing some files giving different results. 19:31.39 Optimiser might be spotting the x == 1 case, but that's a really bad thing to do with floating point. 19:32.29 paulgardiner: It's a variable. Don't see how it could. 19:33.03 store-bookkeeping commit looks good 19:33.57 yeah it can't be. The only other thing I can think of is the plus and times instructions themselves don't commute. 19:36.20 Chans: (ghostbot) in:#ghostscript 19:36.35 paulgardiner: If it was an ARM thing I'd look at the assembly :) 19:37.23 Yeah, still getting funny blending on the edges of things. On both text and line art :( 19:37.43 Would be insteresting to know what b -= a; x *= b; x += a; return x; does and b -= a; b *= x; a += b; return a; 19:38.07 So the cluster may have problems with FP usage. 19:40.32 Seen: Flushed 2 entries. 19:41.32 --- Saved uptime records. 19:42.38 FORK(4820) --- fork starting for 'RSSFeeds', PID == 4820, bot_pid == 1004 --- 19:42.39 FORK(4820) !ERROR! cannot load my module: RSSFeeds 19:42.39 FORK(4820) fork: took 1s for RSSFeeds. 19:42.39 FORK(4820) --- fork finished for 'RSSFeeds' --- 19:52.22 Chans: (ghostbot) in:#ghostscript 20:13.06 FORK(32452) LOG: last message repeated 3 times 20:13.06 FORK(32452) --- fork starting for 'RSSFeeds', PID == 32452, bot_pid == 1004 --- 20:13.07 FORK(32452) !ERROR! cannot load my module: RSSFeeds 20:13.07 FORK(32452) fork: took 1s for RSSFeeds. 20:13.07 FORK(32452) --- fork finished for 'RSSFeeds' --- 20:23.29 LOG: last message repeated 3 times 20:23.29 >>> marcosw has signed off IRC (Quit: marcosw) [#ghostscript] 20:25.02 Chans: (ghostbot) in:#ghostscript 20:40.34 ircCheck: possible lost in space; checking.Fri Mar 22 20:40:34 2013 20:40.34 >ghostbot< TEST 20:40.34 IRCTEST: Yes, we're alive. 20:41.44 --- Saved uptime records. 20:43.10 FORK(19264) --- fork starting for 'RSSFeeds', PID == 19264, bot_pid == 1004 --- 20:43.11 FORK(19264) !ERROR! cannot load my module: RSSFeeds 20:43.11 FORK(19264) fork: took 1s for RSSFeeds. 20:43.11 FORK(19264) --- fork finished for 'RSSFeeds' --- 20:56.56 Chans: (ghostbot) in:#ghostscript 21:13.18 FORK(5099) --- fork starting for 'RSSFeeds', PID == 5099, bot_pid == 1004 --- 21:13.19 FORK(5099) !ERROR! cannot load my module: RSSFeeds 21:13.19 FORK(5099) fork: took 1s for RSSFeeds. 21:13.19 FORK(5099) --- fork finished for 'RSSFeeds' --- 21:26.39 >>> join/#ghostscript ray_laptop (~chatzilla@rrcs-24-43-98-229.west.biz.rr.com) 21:27.26 >>> join/#ghostscript ray_laptop_ (~chatzilla@rrcs-24-43-98-229.west.biz.rr.com) 21:29.05 >>> oy has signed off IRC (Quit: tschüß) [#ghostscript] 21:29.05 Chans: (ghostbot) in:#ghostscript 21:31.24 >>> ray_laptop has signed off IRC (Ping timeout: 272 seconds) [#ghostscript] 21:31.36 >>> ray_laptop_ materializes into ray_laptop 21:35.48 >>> ray_laptop has signed off IRC (Ping timeout: 248 seconds) [#ghostscript] 21:39.10 >>> chrisl_r61 has signed off IRC (Remote host closed the connection) [#ghostscript] 21:42.06 --- Saved uptime records. 21:43.36 FORK(21312) --- fork starting for 'RSSFeeds', PID == 21312, bot_pid == 1004 --- 21:43.37 FORK(21312) !ERROR! cannot load my module: RSSFeeds 21:43.37 FORK(21312) fork: took 1s for RSSFeeds. 21:43.37 FORK(21312) --- fork finished for 'RSSFeeds' --- 21:45.02 Chans: (ghostbot) in:#ghostscript 21:45.02 ircCheck: possible lost in space; checking.Fri Mar 22 21:45:02 2013 21:45.02 >ghostbot< TEST 21:45.02 IRCTEST: Yes, we're alive. 22:01.32 Chans: (ghostbot) in:#ghostscript 22:14.12 FORK(11916) --- fork starting for 'RSSFeeds', PID == 11916, bot_pid == 1004 --- 22:14.13 FORK(11916) !ERROR! cannot load my module: RSSFeeds 22:14.13 FORK(11916) fork: took 1s for RSSFeeds. 22:14.13 FORK(11916) --- fork finished for 'RSSFeeds' --- 22:25.07 LOG: last message repeated 3 times 22:25.07 >>> henrys has signed off IRC (Quit: henrys) [#ghostscript] 22:33.36 Chans: (ghostbot) in:#ghostscript 22:42.40 --- Saved uptime records. 22:44.16 FORK(1316) --- fork starting for 'RSSFeeds', PID == 1316, bot_pid == 1004 --- 22:44.17 FORK(1316) !ERROR! cannot load my module: RSSFeeds 22:44.17 FORK(1316) fork: took 1s for RSSFeeds. 22:44.17 FORK(1316) --- fork finished for 'RSSFeeds' --- 22:45.16 !WARN! PERL: readdir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 862. 22:45.16 !WARN! PERL: closedir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 869. 22:49.28 Chans: (ghostbot) in:#ghostscript 22:49.28 ircCheck: possible lost in space; checking.Fri Mar 22 22:49:28 2013 22:49.28 >ghostbot< TEST 22:49.28 IRCTEST: Yes, we're alive. 23:06.18 Chans: (ghostbot) in:#ghostscript 23:14.42 FORK(26478) --- fork starting for 'RSSFeeds', PID == 26478, bot_pid == 1004 --- 23:14.43 FORK(26478) !ERROR! cannot load my module: RSSFeeds 23:14.43 FORK(26478) fork: took 1s for RSSFeeds. 23:14.43 FORK(26478) --- fork finished for 'RSSFeeds' --- 23:27.16 >>> paulgardiner has signed off IRC (Quit: ChatZilla 0.9.90 [Firefox 19.0.2/20130307023931]) [#ghostscript] 23:38.32 Chans: (ghostbot) in:#ghostscript 23:39.37 >>> gandaro has signed off IRC (Quit: Leaving) [#ghostscript] 23:41.36 >>> Guest48324 has signed off IRC (Read error: Connection reset by peer) [#ghostscript] 23:43.04 --- Saved uptime records. 23:43.51 >>> join/#ghostscript marcosw (~marcosw@c-67-164-54-215.hsd1.ca.comcast.net) 23:44.50 FORK(19378) --- fork starting for 'RSSFeeds', PID == 19378, bot_pid == 1004 --- 23:44.51 FORK(19378) !ERROR! cannot load my module: RSSFeeds 23:44.51 FORK(19378) fork: took 1s for RSSFeeds. 23:44.51 FORK(19378) --- fork finished for 'RSSFeeds' --- 23:54.04 Chans: (ghostbot) in:#ghostscript 23:54.04 ircCheck: possible lost in space; checking.Fri Mar 22 23:54:04 2013 23:54.04 >ghostbot< TEST 23:54.04 IRCTEST: Yes, we're alive.