| | <<<Back 1 day (to 2011/10/05) | 2011/10/06 |
| marcosw_ | Robin_Watts: you still here? | 00:13.50 |
| ray_laptop | mvrhel2: I think the patch is good (with the variable assignment put back in that I mistakenly deleted). Is it OK if I commit it ? | 02:35.01 |
| | tkamppeter_: I have a patch for bug 692568 | 03:09.16 |
| | I decided to go ahead and commit it. | 03:30.17 |
| BamJangles | anyone alive? | 03:43.32 |
| mvrhel2 | ray_laptop: thanks for fixing that | 04:13.03 |
| ray_laptop | mvrhel2: sorry -- I was working on something else. | 04:32.46 |
| | mvrhel2: I'm pretty sure, but you can think about it from my log and bug comments and see if it makes sense to you. | 04:33.20 |
| mvrhel2 | Yes it makes sense | 04:35.09 |
| chrisl | Huh, Steve Jobs dead - didn't see that coming so soon........ | 07:38.06 |
| kens | I guessed it was on the cards after he resigned. | 07:38.21 |
| | But I'll be impressed if he can manage this come-back | 07:38.35 |
| chrisl | Yes, but as I say, not this soon - given he remained as chairman. | 07:38.52 |
| kens | Yeah, but that's really a figure-head role, Gates is still chairman of Microsoft | 07:39.19 |
| chrisl | True - the other thing is, the reporting saying he was "found dead", suggests to me it wasn't expected (at this time) by those close to him. | 07:40.23 |
| kens | Hmm, missed that part of the report. | 07:40.40 |
| | I kind of skimmed the effusive and irrationa obituaries. | 07:40.57 |
| chrisl | I didn't look at the obits, but most new agencies seem to the using the "found dead" phrase, so I'd guess that's what the official statement says | 07:41.50 |
| | s/new/news | 07:41.57 |
| kens | Well, at least he wasn't bodily tanslated... | 07:42.26 |
| | translated | 07:42.30 |
| chrisl | More likely he sublimed....... | 07:42.43 |
| chrisl | wonders what the Apple share price will do today | 07:43.50 |
| kens | Interesting question. | 07:45.27 |
| Robin_Watts | Well, given it dropped 5% after the 4S wasn't called the 5... | 09:30.03 |
| chrisl | It will probably depend on how much confidence investors have in the new guy - and they haven't had long to develop an opinion | 09:36.34 |
| kens | Out for lunch today, back later. | 10:49.29 |
| Robin_Watts | tor8: Morning | 11:54.20 |
| tor8 | hi | 11:54.27 |
| Robin_Watts | Up to over 750000 allocations with pdf_reference17.pdf and it's still running clean. | 11:54.59 |
| tor8 | sweet :) | 11:55.39 |
| Robin_Watts | I am struck by just how much gets loaded how soon though. | 11:55.49 |
| | Does the code run through loading every object when it starts ? | 11:56.11 |
| tkamppeter | chrisl, can you have a look at http://bugs.ghostscript.com/show_bug.cgi?id=692572, I have assigned it to the PDF interpreter, but can also be CM. | 11:56.36 |
| tor8 | with the display list in use, I believe everything that's ever needed for a page will be loaded up front | 11:56.37 |
| Robin_Watts | Even before the display list. | 11:56.51 |
| tor8 | but no, we don't load every object unless we are in repair mode | 11:56.54 |
| tkamppeter | kens, ^^ | 11:56.56 |
| tor8 | we load the page tree early though, I've been meaning to make that lazily loaded | 11:57.09 |
| Robin_Watts | Because doing 800000+ allocations just to render the first page seems excessive :) | 11:57.46 |
| tor8 | yeah... that does sound a but much | 11:58.44 |
| Robin_Watts | I fear it may be 3 million. | 11:58.56 |
| tor8 | I wonder if there's an easy way to profile that | 11:59.31 |
| Robin_Watts | Memento! :) | 11:59.39 |
| tor8 | see out where all the allocations stem from | 11:59.42 |
| | pardon my grammar | 11:59.51 |
| | still waking up :) | 11:59.57 |
| Robin_Watts | I have something in mind for Memento that will help with that. | 12:00.39 |
| | I wonder if I've broken this then. | 12:02.34 |
| | It looks to me like pdf_open_xref_with_stream does pdf_load_object on every object in the xref. | 12:03.02 |
| | even without a repair. | 12:03.13 |
| tor8 | I know we load all the objects during a repair, but we shouldn't be doing that in the normal case | 12:05.26 |
| Robin_Watts | I wonder if I've broken that with the try/catchification. | 12:06.31 |
| | yes, I've broken it :( | 12:07.26 |
| | Easy fix though. | 12:07.49 |
| | Also, we pull the whole content stream into a buffer before we run it ? | 12:08.12 |
| chrisl | tkamppeter: Yet again, Bug 692572 works just fine with our lcms - you *really* must test with *our* default build before reporting issues to us. | 12:10.29 |
| tor8 | Robin_Watts: yeah. easiest way to deal with the content stream array crap | 12:11.31 |
| | and also being able to seek to other places to load resources on the fly | 12:11.56 |
| Robin_Watts | tor8: In my pdf code I had a filter type that just concatenated an array of filters. | 12:12.04 |
| tor8 | I did something similar before, but then we front-loaded all images and font resources from the /Resources dict whether they were used or not to avoid seeking in the underlying file | 12:12.50 |
| Robin_Watts | isn't the seeking thing just a matter of ensuring you seek back to the right place in the file before reading the next block? | 12:13.03 |
| tor8 | yeah, nasty stuff to get right with all the pipeline complexity and/or sharing a file descriptor between multiple streams | 12:13.49 |
| tkamppeter | chrisl, the backtrace made the impression that this time it crashed inside GS, but probably I am not much into GS's internals that I can well determine that. Sorry. | 12:28.51 |
| chrisl | tkamppeter: You're not wrong, gx_remap_ICC() is a GS function, but gs 9.04 as distributed by us, | 12:31.40 |
| | works fine, so I conclude it's lcms that's the problem | 12:32.01 |
| marcosw_ | kens: can I ask you to try and duplicate a windows only bug? I've already tried and works for me with XP SP3 (which is what the customer is using). If you have it's: http://bugs.ghostscript.com/show_bug.cgi?id=692571 | 14:20.52 |
| Robin_Watts | marcosw_: Morning. You were looking for me last night ? | 14:21.11 |
| marcosw_ | Robin_Watts: I was going to ask you to look at the bug I just irc'd kens about. You were the only one still up :-) | 14:21.48 |
| Robin_Watts | I have 32bit XP SP3 here. | 14:21.52 |
| marcosw_ | It'd be helpful if you could try and duplicate it; if not than it's likely a setup with the customers Windows. | 14:22.41 |
| Robin_Watts | Gimme 5 mins, and I'll have a look. | 14:24.26 |
| K4R0L15 | Hello everyone | 14:24.38 |
| marcosw_ | btw, for those of you discussing Apple's stock price it opened sharply lower but has already recovered and is now up 1%. | 14:24.58 |
| Robin_Watts | marcosw_: I get a warning (page 13, stream length incorrect), but otherwise it's fine. | 14:31.19 |
| | That's running HEAD of course. | 14:31.33 |
| henrys | marcosw_:I was reading an article in the Times about how influential he was relative to other CEO's, all these products really were kind of a singular vision of his. Bad news for apple long term. | 14:31.36 |
| marcosw_ | Robin_Watts: thanks. unfortunately that's the same results I get. How much trouble would it be for you to try 9.04? | 14:33.52 |
| Robin_Watts | I can checkout and rebuild with 9.04 with my super git powers. | 14:34.27 |
| | but not at the moment. | 14:34.30 |
| kens | sorry marcosw wasn't paying attention | 14:34.45 |
| Robin_Watts | I'm running the plank vs pamcmyk4 differences at the moment. | 14:34.47 |
| | So far I haven't found any differences. | 14:35.00 |
| | (8 files tested) | 14:35.16 |
| kens | my checkout is not in a good state for checking builds | 14:35.17 |
| chrisl | marcosw_: I have GS 9.04 installed on a 32 bit Win7 VM, if that's okay? | 14:46.51 |
| marcosw_ | chrisl: should be okay. The customer says it fails under win32 and 2003, so testing on Win7 should be another useful data point (particularly if it fails). Thx. | 14:48.03 |
| chrisl | I'll check it in a moment | 14:48.27 |
| | marcosw_: Nope, sorry - same warning about stream length, but runs to completion. Give me a minute, and I'll double check the AFX release. | 14:50.56 |
| marcosw_ | okay. I'll add this to the bug report. | 14:51.10 |
| chrisl | marcosw_: the AFX release crashes....... | 14:52.33 |
| marcosw_ | sorry, what's the AFX release? | 14:53.38 |
| chrisl | Artifex - the non-GPL release | 14:54.01 |
| henrys | luratech? Good thinking to check that chrisl. | 14:55.25 |
| chrisl | henrys: Could be Luratec, it's the only difference I can think of that might be responsible - and it does seem to be a scanned document, so might be using JBIG2 | 14:57.38 |
| henrys | marcosw:I need all the pcl bugs from bugzilla in the bug database like you do do with pdf/ps, I have a large pcl change coming and I fear regressions. Do you have a quick way of getting the attachment with a script or do you visit each bug manually? | 14:59.47 |
| | marcosw_ ^^^ | 15:00.32 |
| marcosw_ | henrys: I do it manually | 15:01.02 |
| henrys | okay thanks | 15:01.36 |
| chrisl | henrys, marcosw_ that test job does use JBIG2 on page 13 (at least), so luratec is looking a good bet. | 15:05.42 |
| marcosw_ | chrisl: thanks for the suggestion. I'm trying the luratech build now. | 15:06.30 |
| Robin_Watts | So it might be a corrupt JBIG2 stream; non-luratech gives a warning, luratech falls over. | 15:06.39 |
| chrisl | Robin_Watts: it could be. The "stream length incorrect" warning gets emitted before the crash. | 15:10.03 |
| | Robin_Watts: have you got a sec? | 15:11.49 |
| Robin_Watts | Sure. | 15:11.59 |
| chrisl | I've got a problem on SPARC which appeared with your commit 1553ea878b414b4ac389f7cec4c2076bc52be966 | 15:12.36 |
| | Oh, crap, no hang on, wrong problem, give me a mo | 15:12.58 |
| | Commit 38720da47205c029d9bee6c3b792791b6f39277d is the one I mean (too many windows open!) | 15:13.54 |
| | Diff: http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=38720da47205c029d9bee6c3b792791b6f39277d;hp=b246d9d85c119f101956ba07cf9e1c8b9f510b49 | 15:14.24 |
| Robin_Watts | Really? | 15:15.15 |
| chrisl | Now, the problem is that it now results in short runs being rendered with the code in mem_mono_copy_mono() instead of delegating to mem_mono_strip_copy_rop_dev | 15:15.22 |
| Robin_Watts | I'm slightly surprised at that. | 15:15.50 |
| | The code used to always use the code in mem_mono_copy_rop. | 15:16.03 |
| chrisl | And this is an issue because mem_mono_copy_mono doesn't honor pointer alignment - it assumes it can use 16 bit alignment | 15:16.22 |
| Robin_Watts | Then I changed it to always call my new ROP run stuff. | 15:16.29 |
| | Then I changed it to only call the new ROP run stuff if the width was >=32 | 15:16.53 |
| | So presumably this file would never have worked, then would have worked, then wouldn't have worked. | 15:17.23 |
| chrisl | I'd guess so, I can go try it on early versions, if you want. | 15:17.47 |
| Robin_Watts | I think it would be worth confirming that I haven't somehow broken the code in mem_mono_copy_rop. | 15:18.11 |
| chrisl | mem_mono_strip_copy_rop_dev() seems to work fine, it's when we skip that call that the problem arises | 15:19.07 |
| Robin_Watts | Right. mem_mono_strip_copy_rop_dev is my stuff. | 15:20.19 |
| chrisl | But is slower for short runs? | 15:20.35 |
| Robin_Watts | The rest of the stuff in this file is peters. | 15:20.52 |
| | timings would suggest it's slower, yes. | 15:21.06 |
| | But possibly because I honour alignment :) | 15:21.15 |
| | If a version of the code from before I made any changes to this file at all still crashes, then it would show that the problem is prehistoric. | 15:21.58 |
| chrisl | Okay, I'll dig that out, give it a whirl | 15:22.26 |
| Robin_Watts | And the fix would then either be to fix peters code (no way!) or to force us to take the slower branch every time if alignment is an issue. | 15:22.32 |
| chrisl | To be honest, I don't think fixing Peter's code would be *that* hard, but I suspect it would then lose the performance benefit it currently has - when it doesn't crash! | 15:23.33 |
| Robin_Watts | From a quick look, it does look like peters code is trying to cope with alignment etc. | 15:23.59 |
| chrisl | Yes, but's aligning to 16 bits, which ain't much good in a 32/64 bit world...... | 15:24.41 |
| Robin_Watts | Are you saying that a sparc can't cope with reading 16 bits of data unless it's from a 32bit aligned address? | 15:26.08 |
| chrisl | Er, IIRC, it can't cope unless it from a 64 bit aligned address | 15:26.39 |
| Robin_Watts | !?!?!?! | 15:26.55 |
| henrys | I'd be really surprised if Peter's original code didn't work, he was really particular about alignment... | 15:27.02 |
| Robin_Watts | ARM used to care about alignment. | 15:27.23 |
| chrisl | "Modern" SPARC is 64 bit kernel space, (usually) 32 bit user space, but it still enforces (64 bit!) hardware alignment - it's *really* crap :-( | 15:28.02 |
| Robin_Watts | The rule is that you can load an n bit chunk of data as long as you're aligned to n bits. | 15:28.07 |
| henrys | chrisl:did you check arch.h for correct settings? | 15:28.49 |
| chrisl | henrys: Yes, I did - it looks right. | 15:29.07 |
| | Given the vintage of this code, it was probably written when SPARCs were 32 bit hardware, so 32 bit alignment would work | 15:29.43 |
| Robin_Watts | chrisl: How can it possibly insist on 64bit alignment for 16bit data transfers? | 15:31.09 |
| chrisl | Robin_Watts: *shrug*. It's a long time since I dug into that side of Sun hardware | 15:32.20 |
| henrys | marcosw_:what's up with the fixed customer bugs? | 15:38.09 |
| Robin_Watts | chrisl: http://dlc.sun.com/osol/docs/content/DRIVER/hwovr-1.html | 15:40.37 |
| | That's what I would have expected. | 15:40.58 |
| chrisl | Hmm, I seemed to remember it didn't quite work out that way, but as I say, it was >5 years ago. Anyway, I'm build an earlier version to try now (takes a while on an old SPARC!) | 15:42.33 |
| ray_laptop | are we going to upstream the JBIG2 luratech problem to them ? (and if so, who will contact them?) | 16:02.11 |
| | or are we going to have one of us dig into their code ? | 16:02.32 |
| henrys | alexcher should verify it isn't a language bug and then report it to luratech. | 16:02.53 |
| | I'll report it if he doesn't want to. | 16:03.18 |
| | but not until it is a verified luratech problem. | 16:03.49 |
| | gawd it takes forever to collect attachments for the bug database. | 16:04.51 |
| ray_laptop | we seem to have a few bugs assigned to 'support'. Are we going to discuss those (or any others) ? | 16:09.38 |
| henrys | I think miles is going to call. | 16:13.08 |
| kens | off for the night, bye everyone | 16:13.20 |
| Robin_Watts | night kens | 16:13.27 |
| tkamppeter | ray_laptop, thanks for the fix, I have applied it (and got it still into Oneiric) and now the clist problem is solved. | 16:13.42 |
| ray_laptop | have to take the dog to the vet for shots. bbiab. | 16:14.46 |
| henrys | hmm I said I think miles is going to call so ray_laptop heads for the vet ;-) | 16:33.30 |
| chrisl | Robin_Watts: it's a bit hard to tell because of all the macro nonsense (and not have macro expansion on the SPARC debugger!), but it does look like we're getting a 32 bit write to a 16 bit aligned address. I'll hit it with a git bisect tomorrow, because I'm almost out of time today. | 16:40.20 |
| Robin_Watts | chrisl: OK. | 16:40.38 |
| | So it's dying in peters original code, before I touched any of it? | 16:41.16 |
| chrisl | No, back before 027da430a5b8d7e377ae36098607717b345eb097 it worked fine, but I don't know, yet, when it stopped working. | 16:42.44 |
| | It's slow going because the SPARC is painfully slow to build to GS...... | 16:45.00 |
| marcosw_ | chrisl: you were correct, the luratech build does crash on the file. Thanks again for remembering that the default customer build now uses the luratech decoder. In my defense this may be the first instance of the internal decoder working better than the luratech decoder. | 16:57.03 |
| chrisl | marcosw_: np, glad to get to the bottom of it (from our POV at least) | 16:58.09 |
| henrys | marcosw_:it should go to alex first to check for abuse of the api - then I'll contact luratech after alexcher looks at it. | 16:59.09 |
| marcosw_ | henrys: thanks for the suggestion, I'll assign it to Alex and also check to see if it's a regression. | 16:59.46 |
| chrisl | I was going to say, couldn't we extract the JBIG2 data, and try the luratech demo on it - but I can't get the luratech code to build :-( | 17:03.12 |
| ray_laptop | chrisl: I had built the luratech standalone in a previous release. I'll see if I can get it to build. | 17:09.02 |
| | chrisl: the jb2_demo built OK for me. | 17:14.20 |
| henrys | ray_laptop:well does the extract jbig2 work? | 17:15.50 |
| ray_laptop | henrys: I was going to extract it manually from the stream object | 17:16.34 |
| | I have to download the problem file first | 17:16.56 |
| chrisl | ray_laptop: you're on Windows, I assume? I was trying on Linux | 17:17.34 |
| ray_laptop | chrisl: yes, on Windwos | 17:17.51 |
| mvrhel2 | Robin_Watts: So I finally verified that Marti's tools that come with lcms2 do a crazy rendering with the same profile that I put in the pdf file that we have the regression on. Marti's results are way different then three other CMMs that I checked. I will wrap this up and get it out to him | 17:18.07 |
| ray_laptop | Win 7 64-bit Pro, specifically | 17:18.11 |
| chrisl | ray_laptop: I didn't try Windows because all my Win machines are powered down now | 17:18.45 |
| Robin_Watts | mvrhel2: Cool. The sooner we can get back onto the lcms2 train, the better. | 17:18.57 |
| mvrhel2 | yes. I agree | 17:19.05 |
| | This is such an extreme case, if we don't hear something back from him soon I would vote that we push forward anyway | 17:19.36 |
| | with lcms2 | 17:19.39 |
| Robin_Watts | Well, the first step in that is probably getting marcosw to run lcms1 vs lcms2 comparisons. | 17:21.42 |
| mvrhel2 | yes | 17:21.48 |
| Robin_Watts | Then porting our changes into lcms2 and reporting them upstream. | 17:21.59 |
| mvrhel2 | yes | 17:22.05 |
| Robin_Watts | states the obvious :) | 17:22.20 |
| mvrhel2 | I think we would want to do the port into lcms2 though before the comparison | 17:23.04 |
| Robin_Watts | mvrhel2: I was thinking we'd do the comparison, then when we were happy, swap to lcms2 by default. | 17:24.02 |
| | Then do the port. | 17:24.10 |
| | as the ports are all speed optimisations, right? | 17:24.20 |
| | So the cluster tests as we commit those will tell us of any diffs. | 17:24.30 |
| mvrhel2 | Robin_Watts: no there are minor diffs from the optimizations too | 17:24.31 |
| Robin_Watts | Right, but we'll spot those minor diffs with the usual per-commit testing. | 17:24.53 |
| mvrhel2 | and we already went through those | 17:24.56 |
| Robin_Watts | Fair enough. | 17:25.05 |
| mvrhel2 | I am fine either way though | 17:25.24 |
| Robin_Watts | On windows, I get identical results for plank and pamcmyk4 using the command lines that marcosw sent for 012-09.ps | 17:38.36 |
| | On 64bit linux, I get differences. | 17:38.50 |
| | Let's try 32bit linux. | 17:39.12 |
| | ray_laptop: Any chance you could install imagemagick on peeves please? | 17:43.51 |
| ray_laptop | Robin_Watts: OK. just a minute... | 17:49.08 |
| Robin_Watts | ray_laptop: Thanks. | 17:49.18 |
| ray_laptop | chrisl: henrys: I added the jb2 file and the results I get from the luratech demo with the object 613 (the one that reports stream length incorrect). | 17:49.54 |
| | chrisl: henrys: the demo fails so we can probably now send it to luratech | 17:50.18 |
| henrys | send me the naked jbig2, if you want me to talk with them. | 17:51.51 |
| ray_laptop | henrys: I attached it to the bug | 17:52.09 |
| henrys | great. | 17:52.26 |
| ray_laptop | henrys: note that this is just the binary stream from the PDF file. I don't know if a .jb2 file is supposed to have some sort of header. | 17:53.42 |
| Robin_Watts | "fails" = crashes ? | 17:54.09 |
| ray_laptop | I guess I will try the luratech compressor to see what it spits out. | 17:54.24 |
| | but first I will see to Robin_Watts' request... | 17:54.38 |
| henrys | ray_laptop:that should be private I believe. | 17:55.17 |
| ray_laptop | Robin_Watts: OK, peeves should have imagemagick | 17:55.45 |
| Robin_Watts | ray_laptop: Thanks. | 17:55.55 |
| ray_laptop | henrys: I suspect that file needs a header of some sort. The files created by the luratech demo compression option has a header (I don't know how much is the header): | 18:09.41 |
| | 00000000: 97 4A 42 32 0D 0A 1A 0A 01 00 00 00 01 00 00 00 |.JB2............| | 18:09.43 |
| | henrys: I think it is the first 8 bytes, but when I stick that on the front of the data I pasted, PS still can't open it and luratech is just as confused by it. | 18:10.40 |
| henrys | I'll just kick the pdf up to them (luratech) and see if they have any quick ideas. | 18:13.02 |
| ray_laptop | henrys: might as well pass the data I extracted from the PDF in case that helps them. | 18:14.29 |
| henrys | please make that private - it looks like it has names and stuff in it. | 18:14.59 |
| ray_laptop | henrys: OK, will do. | 18:17.51 |
| | henrys: done. marked private. | 18:19.34 |
| Robin_Watts | Gah. I hate C compilers. | 18:47.59 |
| | __FUNCTION__ is supposed to be a magic predefine that tells you the function you're in. But it's not. | 18:48.45 |
| | it's a magic variable thing, so you can't use it in expressions like: __FUNCTION__ ":" __FILE__ | 18:49.17 |
| | Oh joy. | 19:47.55 |
| | 32bit windows gives pamcmyk4 and plank the same results. | 19:48.16 |
| | 32bit linux gives pamcymk4 and plank the same results (but different to windows) | 19:48.36 |
| | 64bit linux gives them completely different results to anyone else. | 19:48.56 |
| | and each other. | 19:50.25 |
| | mvrhel2: When you commit, could you put a bit more than "Fix for Bug 292507" in the first line please? | 23:40.39 |
| | "Fix for Bug 292507. pdf14 cmyk issues" or something, would be much more helpful. | 23:42.09 |
| mvrhel2 | Robin_Watts: sorry. I usually put more in the following paragraph | 23:44.14 |
| Robin_Watts | mvrhel2: No worries. | 23:44.40 |
| | I was struck when I did a: "git logg -20" (to just look at the last 20 commits) that the ones with just a bug number in are much less helpful :) | 23:45.14 |
| mvrhel2 | did you have any specific questions about a commit? | 23:45.14 |
| Robin_Watts | mvrhel2: No, I was looking to check that nothing recently would have changed something, and most commits I could discard purely from looking at the logg. | 23:45.58 |
| | (git logg is an alias here that lists just the revisions and the first lines of the messages - I know you use tortoise) | 23:46.28 |
| | No big deal - I'm sure I've been guilty of doing the same thing in the past. | 23:46.56 |
| mvrhel2 | ok. I understand | 23:47.26 |
| | I will add some additional information on the bug fix commits | 23:47.44 |
| | first line | 23:47.47 |
| | Robin_Watts: did you need anything from me with respect to planar/halftoning? Since I have closed all my customer issues, I am going to work on our screen creation stuff | 23:52.29 |
| Robin_Watts | Not at the moment. | 23:52.40 |
| | I'm going to try and understand the 32bit vs 64bit differences I'm seeing tomorrow. | 23:52.57 |
| | I think the linux vs windows differences are to do with page sizes. | 23:53.11 |
| mvrhel2 | getting a common interface between genpat and my code plus adding in multi-level, min dot, and different vertical and horizontal sizes into my stuff | 23:53.18 |
| | ok. good luck with that | 23:53.41 |
| Robin_Watts | Right. 32bit linux and 32bit windows plank/pamcmyk4 all agree when I force the pagesize. | 23:57.58 |
| | So now to figure out why the 64bit linux ones disagree with that (and itself) | 23:58.23 |
| mvrhel2 | well all of this is great progress | 23:59.40 |
| | Forward 1 day (to 2011/10/07)>>> | |
IRC Logs