| | <<<Back 1 day (to 2012/07/01) | 2012/07/02 |
| malc_ | Robin_Watts: hi, around? | 00:02.31 |
| | or rather.. | 00:04.04 |
| | sebras: hi, around? | 00:04.13 |
| Robin_Watts | sebras: So just looking at your write bits stuff now. | 09:44.23 |
| | I know why your test code fails with the existing code. | 09:44.41 |
| | I assume that the values to be written on entry are correctly masked. | 09:45.06 |
| | Whereas you call in with all bits set. | 09:45.17 |
| sebras | Robin_Watts: ok. so you are saying there is no bug, it's just that I misunderstood the interface? | 09:47.00 |
| Robin_Watts | sebras: I'm saying your test code is invalid. | 09:47.42 |
| | That's all so far. | 09:48.05 |
| sebras | Robin_Watts: oh, and I got a mail from malc_ about pthread return code checking in the sample code. I have a patch but I can't push it from my server and my desktop is shutdown. | 09:48.08 |
| | Robin_Watts: ok. I believe that I would get the same erroneous behaviour if I were to use correctly masked val though. | 09:48.59 |
| | Robin_Watts: but I have not tested that of course. | 09:49.07 |
| Robin_Watts | I suspect you are right. | 09:49.10 |
| sebras | Robin_Watts: I'm happy to work through the code tonight, but I have to work a bit over here as well. :) | 09:52.11 |
| Robin_Watts | sebras: Sure. This was in no way a complaint, just an observation. | 09:52.58 |
| | If I was capable of having written non broken code to start with this wouldn't have been an issue. | 09:53.34 |
| sebras | np. :) | 09:55.14 |
| Robin_Watts | sebras: New patch pushed to my master branch with fixed code, and the test code I used. | 10:46.26 |
| sebras | Robin_Watts: yey!, I'll have a look at it tonight. :) do contempalte the fz_buffer_hexdump code though. because I'm thinking that something like it makes sense when debugging in gdb... | 10:52.54 |
| Robin_Watts | sebras: We should ask tor8 about that. | 10:53.29 |
| | No bloat etc. | 10:53.34 |
| | In MSVC you just open a memory window... | 10:54.00 |
| chrisl | Thus begins the painful process of learning a new IRC client....... | 10:58.16 |
| Robin_Watts | chrisl: What client ? | 10:58.33 |
| chrisl | Trying Smuxi | 10:58.55 |
| Robin_Watts | What are the perceived advantages ? | 10:59.11 |
| chrisl | It's standalone - doesn't depend on Firefox or xulrunner (as xulrunner is no longer supported on Ubuntu) | 10:59.48 |
| sebras | Robin_Watts: on the other hand we _do_ have pdf_debug_obj() and friends. so maybe it ought to be fz_debug_buffer() which also would print the values of cap/len/etc... | 10:59.48 |
| Robin_Watts | sebras: I do not disagree with you. | 11:00.13 |
| sebras | Robin_Watts: any reasonable linker would optimize those away since they are normally not called. | 11:00.15 |
| Robin_Watts | sebras: Ah, well, there I do disagree. | 11:00.27 |
| sebras | Robin_Watts: ok..? | 11:00.35 |
| | Robin_Watts: is there a linker that takes unused code into account? | 11:00.49 |
| Robin_Watts | Its rare for linkers to do function level removal. | 11:01.06 |
| | Most linkers can remove 'compilation units', which is generally complete .c or .s files. | 11:01.30 |
| sebras | Robin_Watts: is it!? but, but... why? | 11:01.30 |
| Robin_Watts | because if I have a .c file that has 2 functions in, the compiler will generate 1 .o that includes both those functions. | 11:02.02 |
| | It can feel free to share string and constant literals between the two. | 11:02.14 |
| | When it then comes to link time, even if it spots it can drop 1 of those 2 functions, how can it do it? It can't easily know which bits within the .o came from which function, which bits are shared etc. | 11:03.10 |
| chrisl | The GNU linker definitely doesn't remove unused functions - I don't know if the optimiser will...... | 11:03.44 |
| Robin_Watts | toolchains that do function level linking typically do function level compiling too (each function goes into separate sections within the .o with no code sharing etc). | 11:04.02 |
| | that way they can drop unused stuff at a finer granulatiry. | 11:04.17 |
| | or granularity. | 11:04.23 |
| | So, if we add such debug functions they should go into a separate .c file. That way they can be optimised away. | 11:04.55 |
| | and that kind of decision, I like to run past tor8 as it's his aesthetic taste that guides mupdf. | 11:05.27 |
| sebras | Robin_Watts: I see your point (at least in case linkers work as you mention). but then we really ought to move most of the debug functions to separate .c-files that are only included in the non-release-builds. | 11:09.18 |
| | Robin_Watts: for consistency I mean. | 11:09.25 |
| | Robin_Watts: and yes tor8 ought to be part of that decision. :) | 11:09.35 |
| Robin_Watts | We can safely include those in release builds too. | 11:09.55 |
| | Because the compiler/linker can drop them with no problems. | 11:10.10 |
| | BUT... the problem with that is that it affects the structure of the code; inline struct definitions etc. | 11:10.30 |
| | they have to become visible over 2 .c files etc. | 11:10.53 |
| | At Picsel, we structured code with lots of headers (API functions in one headers, internal definitions in another etc, kept in separate directories etc) so we could safely do this. | 11:11.56 |
| | with mupdf we have a much more minimal structure, so it's harder. | 11:12.14 |
| | but with the fitz/fitz-internal and mupdf/mupdf-internal split it's easier now than it was previously, so may well be worth revisiting. | 11:12.49 |
| sebras | Robin_Watts: indeed. | 11:13.26 |
| | Robin_Watts: and yes of course having that debug-code around would affect the compilers decisions when it comes to optimization. | 11:14.05 |
| Robin_Watts | The worry I have is that the more stuff we push into 'mupdf-internal.h' say, the more 'public' that stuff becomes. | 11:17.52 |
| | and hence the harder it becomes to change in future versions. | 11:18.07 |
| | At picsel we had blah-impl.h headers that contained implementation specific things. | 11:18.56 |
| | (And in fact, we even had those at the api level because we were targetting systems that didn't have inlines, and so we had to use macros for speed. | 11:19.39 |
| | chrisl: Don't worry, the abort of my cluster run was deliberate - I've not broken the cluster (yet) today :) | 11:24.15 |
| paulgardiner | For app writers it's attractive to be able to get all of mupdf's features from just including mupdf.h, but it seems less clear to me that comining all the internal stuff into the one mupdf-internal.h is advantageous. | 11:25.56 |
| chrisl | Robin_Watts: I hadn't even noticed - but thanks.... | 11:26.31 |
| Robin_Watts | paulgardiner: Until recently, everything was in fitz.h. Everything. | 11:27.13 |
| | Does anyone have a clue how commits make it into the cluster queue? | 11:41.42 |
| | I'd assumed it was a git hook, but I can't see one. | 11:41.53 |
| | I can see where we generate the emails. | 11:42.00 |
| | maybe the cluster gets the email too ? | 11:42.08 |
| | but I can't see an obvious hook for that either. | 11:42.32 |
| | oh, so stupid. | 12:00.16 |
| chrisl | Robin_Watts: did you find it, then? | 12:02.22 |
| Robin_Watts | yeah. couldn't see for looking. | 12:02.31 |
| | The clustermaster script checks. | 12:03.01 |
| chrisl | Yeh, maybe we should consider using a hook at some point in the future.... | 12:04.08 |
| | Hmmm, how, I find my self wondering, can a change in jbig2dec cause differences and errors to appear in the PCL interpreter? | 12:06.16 |
| Robin_Watts | indetermistic files? | 12:07.14 |
| chrisl | We're talking 214 jobs started producing errors - I don't think we have that many indeterminisms at the moment | 12:09.02 |
| Robin_Watts | clusterpush a vanilla tree? | 12:09.52 |
| chrisl | The push from my other machine (with build changes that *could* influence PCL) gave no differences, and no new errors...... | 12:10.23 |
| Robin_Watts | interesting... I just a spam that starts: "My name is Lisa Donald .I am the new Chancellor of the Exchequer(HM Treasury) in the United Kingdom." | 12:10.51 |
| chrisl | And I just paid my tax bill - damn! | 12:11.19 |
| | Okay, trying a vanilla source tree, now - let's see what happens..... | 12:14.18 |
| Robin_Watts | Now, with a bit of luck, we should see a mujstest test scheduled on the forms branch... | 12:16.19 |
| kens | chrisl I'm seeing a lot of seg faults suddenly | 12:16.59 |
| chrisl | kens: I haven't committed anything..... | 12:17.31 |
| | kens: I'm assuming all those don't trace back to your changes? | 12:18.32 |
| Robin_Watts | lunchtime. | 12:19.18 |
| kens | chrisl some maybe, toehrs I can't see how | 12:20.17 |
| chrisl | kens: well, I managed to get an unchanged master pushed before Robin_Watts's mupdf tests, so we'll see what that throws up | 12:21.23 |
| kens | rested in the result | 12:27.12 |
| | I'll be interested* | 12:27.20 |
| chrisl | Hmm, cluster seems stuck now :-( | 12:33.16 |
| kens | :-( | 12:34.14 |
| sebras | tor8: Robin_Watts and I discussed moving pdf_debug_obj() and friends to separate .c-files for debugging. the embryo of the discussion was my fz_buffer_hexdump() in sebras/master. have a look at the logs and the patch if you have time. | 12:44.21 |
| Robin_Watts | chrisl, kens: cluster is still moving, but slowly, right ? | 13:00.44 |
| | ok, it keeps timing out, and restarting. | 13:05.42 |
| | Let me cancel my job to let yours run. | 13:05.48 |
| kens | Its not quite right in some way | 13:06.16 |
| Robin_Watts | The first queued mujstest will die with a compilation failure. | 13:07.46 |
| | Morning marcosw_: Is that really you? | 13:12.34 |
| marcosw_ | and why wouldn't it be? | 13:12.51 |
| Robin_Watts | Well, it might have just been a computer connecting in your absence. | 13:13.08 |
| chrisl | Robin_Watts: it's weird, I think your clusterpush restarted after a while, but it seems okay (for) now | 13:13.33 |
| Robin_Watts | I've tweaked the cluster so that it schedules mujstest jobs on any forms commit. | 13:13.34 |
| | chrisl: I suspect the problem is that my mujstest bmpcmp was taking longer per job than the cluster expected. | 13:14.06 |
| | Hence it restarts the whole job after a while. | 13:14.22 |
| | We probably need to adjust the timeouts. | 13:14.32 |
| chrisl | Oh, I actually thought that was a ghostpdl push..... | 13:14.47 |
| marcosw_ | presumably the bitmaps are large and the rsync's are taking a long time? | 13:15.24 |
| Robin_Watts | could be. | 13:17.03 |
| | Do we rsync after each individual file? | 13:17.36 |
| chrisl | Hmm, four machines not playing...... | 13:18.36 |
| | Still getting all those PCL errors with a vanilla master clusterpush..... :-( | 13:23.56 |
| marcosw_ | Robin_Watts: yes, each file is rsync'd after bmpcmp. | 13:25.29 |
| | why is the cluster stuck at "Updating mupdf"? | 13:26.34 |
| | it's trying to rsync casper.ghostscript.com:/home/tor/public_html/mupdf/download/mupdf-thirdparty.zip did that change? | 13:28.12 |
| Robin_Watts | no. | 13:28.27 |
| | will mupdf-thirdparty not be nuked by the --delete each time, in the same way the v8 stuff is ? | 13:31.31 |
| marcosw_ | actually it's fetching the v8 library. It looks like I only fixed the user mujstest path, not the git commit mujstest path. | 13:31.41 |
| Robin_Watts | Ah. | 13:31.55 |
| marcosw_ | Robin_Watts: for clusterpush operations the cluster assumes the third party code is being pushed along with the mupdf source (since it's intended to be run from a directory that the user is using to compile mupdf). the git commit path doesn't do an rsync, so it doesn't delete anything. | 13:33.15 |
| | that being said the v8 libraries should be okay... | 13:33.34 |
| Robin_Watts | We always want the cluster machines to supply their own v8 libs. | 13:41.35 |
| | because they are prebuilt, and will differ on a per-machine basis. | 13:41.47 |
| marcosw_ | Robin_Watts: found the likely problem: Can't call method "mtime" on an undefined value at run.pl line 678. | 13:50.02 |
| Robin_Watts | marcosw_: Are you fixing that, or should I? | 13:52.33 |
| | (Don't think we should both try editing stuff at the same time :) ) | 13:52.50 |
| marcosw_ | Robin_Watts: I'm not sure what's wrong with the line (btw, it's now line 681). | 13:52.58 |
| | I added some debugging code and reran it | 13:53.10 |
| | is it just that you can't run stat()->mtime on a a missing file? | 13:53.35 |
| Robin_Watts | $oldTime=0; if (-e "$mupdfSource/$v8src") $oldTime=stat... | 13:53.44 |
| | yes. | 13:53.46 |
| marcosw_ | right, I'll fix it. | 13:54.03 |
| | now to restart the cluster nodes (they don't handle run.pl errors gracefully). | 13:55.36 |
| | well, that seems to have worked... | 14:07.06 |
| Robin_Watts | Urm... | 14:07.27 |
| marcosw_ | I'm guessing the number of jobs in the queue is a surprise to you? | 14:07.44 |
| Robin_Watts | I was expecting d03 to fail with a compiler error. | 14:07.49 |
| | Yes. | 14:08.17 |
| | oh. Is the fact that we swap a single mupdf tree back and forth between master and forms going to be upsetting it now ? | 14:08.59 |
| | yeah... master is currently set to d03b9b3, which isn't a commit on the master branch. | 14:10.21 |
| | marcosw: Are you playing with this? | 14:14.09 |
| marcosw_ | Robin_Watts: no. I figure git issues are your thing :-) | 14:17.06 |
| Robin_Watts | ok :) | 14:17.14 |
| marcosw_ | I have to run, be back online later. | 14:18.01 |
| Robin_Watts | ok, I *may* have a fix. | 14:21.54 |
| | tor8: ping | 14:59.08 |
| tor8 | Robin_Watts: hi | 14:59.38 |
| Robin_Watts | You know your fix for that fix that had the alpha in it? | 14:59.50 |
| | synthesising italics? | 14:59.58 |
| | well, I have another file here from the same source (normal_205.pdf) | 15:00.11 |
| | and that has 'a' in place of alpha. | 15:00.21 |
| | and it looks like it's looking for SybolMT,Bold | 15:00.37 |
| | SymbolMT,Bold even. | 15:00.43 |
| tor8 | Robin_Watts: oh, bother | 15:01.01 |
| Robin_Watts | IS that simple to deal with in the same way? | 15:01.11 |
| | (What does MT mean?) | 15:01.18 |
| tor8 | MT is for monotype | 15:01.37 |
| | Robin_Watts: we might get away with adding them to the base_font_names array in pdf_font.c | 15:02.12 |
| | but that might lose the synthesis of bold/italic unless we make it interact with my previous fix as well | 15:02.47 |
| Robin_Watts | can we special case ignoring "MT" ? | 15:03.24 |
| chrisl | Robin_Watts: even if you can work around some of these problems, it will be important to emphasise that if they use a non-base14 font, and don't embed it, the results are going to be unpredicatable.... | 15:03.31 |
| Robin_Watts | or is this pointing to us needing a different mechanism. | 15:03.36 |
| | chrisl: Sure. | 15:03.45 |
| tor8 | Robin_Watts: chrisl: we have a list of alternate names for all the base 14 fonts | 15:04.24 |
| chrisl | Robin_Watts: I just point it out because of the number of times I hear: "well, you made it work the last time...." | 15:04.35 |
| tor8 | all the various windows and windows driver names for them | 15:04.37 |
| paulgardiner | Robin_Watts, tor8: Would you cast an eye over the latest commit on paul/forms when you have a moment? | 15:04.40 |
| Robin_Watts | paulgardiner: Ooh, cluster fodder! | 15:05.41 |
| tor8 | Robin_Watts: how about we add symbol, symbol-italic, symbol-bold, symbol-bolditalic to the base_font_list and change the workaround to make synthetic variants in load_base_font | 15:05.50 |
| chrisl | tor8: as I say, my point is more about ensuring sensible future expectations from the consumer....... | 15:05.57 |
| paulgardiner | Oh right. Sounds good. | 15:06.01 |
| Robin_Watts | tor8: That sounds plausible. | 15:06.12 |
| tor8 | chrisl: yeah, no opposition there. but we already have *MT workarounds for the regular base fonts | 15:06.20 |
| | I've just never seen symbol being used in italic or bold before | 15:06.29 |
| paulgardiner | Robin_Watts: Is it possible now for us to grep out all the cases where v8 complains about undefined properties and functions? | 15:06.54 |
| Robin_Watts | On the cluster? No. | 15:07.07 |
| | oh, urm... | 15:07.15 |
| | maybe, yes. | 15:07.17 |
| chrisl | tor8: It doesn't actually make sense to "style" Symbol, but "sense" rarely enters into what "designers" do... | 15:07.30 |
| Robin_Watts | paulgardiner: Let me fiddle for a mo. | 15:08.30 |
| paulgardiner | Robin_Watts: Oh great. Thanks. | 15:09.25 |
| Robin_Watts | paulgardiner: OK. If you look on the dashboard. | 15:17.17 |
| | http://ghostscript.com/regression/ | 15:17.28 |
| | Look at the topmost mujstest line. Click on 'logs' | 15:17.46 |
| | That will show you more links. | 15:18.20 |
| paulgardiner | Yep.With you so far | 15:18.40 |
| Robin_Watts | Click on the 'log' link under fathoms | 15:18.41 |
| | That gives all the stdout/stderr from running those jobs. | 15:19.03 |
| paulgardiner | I have two lines. Top: fathoms feet herysx6... Bottom: log out log out log out... | 15:21.09 |
| Robin_Watts | Right | 15:21.17 |
| | for each host (fathoms, henrysx6, ...) there are 2 links underneath (log, out) | 15:21.50 |
| | paulgardiner: Looking at your patch... | 15:27.45 |
| | Minor thing: in recalculate, the entirety of the function is inside if (co) { ... } | 15:28.07 |
| | I'd personally prefer if (!co) return; | 15:28.20 |
| | less righthand creep. | 15:28.37 |
| | and it should be static void recalulcate | 15:28.47 |
| | +c | 15:28.57 |
| paulgardiner | Where's the missing 'c'? | 15:41.36 |
| Robin_Watts | In the way I typed "recalculate" :) | 15:41.55 |
| tor8 | Robin_Watts: ah, the difference in normal_205 is that it actually has a font descriptor (so it's not pretending it's a base 14 font) | 15:44.46 |
| | but the font descriptor has serious issues ... | 15:45.58 |
| Robin_Watts | ah, ok. | 15:50.21 |
| | I have the file chopped down to a single char if that helps. | 15:50.47 |
| paulgardiner | Robin_Watts: There: fixed that missing void. | 15:50.55 |
| Robin_Watts | otherwise, I shall be looking at the next one in the list. | 15:50.58 |
| | paulgardiner: Fab. | 15:51.05 |
| paulgardiner | Robin_Watts: what did the cluster make of it? | 15:51.05 |
| Robin_Watts | kens got in with his job first, so we are still waiting. | 15:51.24 |
| paulgardiner | oh ok | 15:51.32 |
| Robin_Watts | ok. New version queued in the cluster. | 15:52.31 |
| | kens job is almost done. | 15:52.41 |
| kens | sorry Robin_Watts | 15:52.41 |
| paulgardiner | The forms are going to act a but odly at the moment in tests because we'll be putting pros where digits are expected. | 15:52.43 |
| Robin_Watts | kens: Hey, I've hogged it all day, I'm not going to complain :) | 15:53.00 |
| paulgardiner | bit oddly I mean | 15:53.06 |
| Robin_Watts | will they refuse the change? | 15:53.37 |
| | or will they only take the digits from the change ? | 15:53.44 |
| mvrhel_laptop | good morning | 15:55.16 |
| Robin_Watts | Morning mvrhel_laptop | 15:55.35 |
| paulgardiner | They'll take the digits fromt the change at the moment | 15:56.29 |
| Robin_Watts | paulgardiner: Well, that sounds ideal. | 15:56.38 |
| | I deliberately have all the Lorem Ipsum text start with a number for that reason. | 15:56.53 |
| paulgardiner | Oh ok good | 15:57.22 |
| Robin_Watts | 1 Lorem Ipsum, 2 Lorem Ipson, 3 Lorem Ipsum | 15:57.26 |
| | Ahhahahah! </Count> | 15:57.32 |
| | paulgardiner: Cluster says 465 differences. Still showing 4 SEGVs. | 16:04.08 |
| | http://ghostscript.com/cgi-bin/clustermonitor.cgi?report=robin | 16:04.33 |
| paulgardiner | Oh right. I didn't realise we still had segvs | 16:04.37 |
| Robin_Watts | Nor did I until earlier today when it started showing real results. | 16:04.59 |
| | Trying for the bmpcmp now. | 16:05.17 |
| | ooh! bmpcmp worked. | 16:10.16 |
| | paulgardiner: In fact, I've just copied the bmpcmp results from mine to yours, so even if I run a new bmpcmp, you'll still have the results saved. | 16:26.17 |
| paulgardiner | Oh right. Thanks. | 16:26.44 |
| Robin_Watts | If you can think of a way that we can autogenerate the .mjs files getting the text type write, then do tell me. | 16:27.56 |
| | s/write/right/ | 16:28.03 |
| | (If we could know that given fields were dates or phone numbers or numbers before I output them, then I could generate them correctly) | 16:28.57 |
| | Can we easily see what js functions are run to validate a field? | 16:29.35 |
| kens | Well I'm still getting 'some' seg faults with PCL files, all on kilometers | 16:45.08 |
| | And that's with a buld of HEAD | 16:45.16 |
| | I guess I'll try a simple modification | 16:46.19 |
| chrisl | kens: I still got a load of errors, and some seg faults with PCL with changes to master - all on kilometers, too, I think. Maybe we should disable it until marcosw can investigate. | 16:51.00 |
| Robin_Watts | I can disable kilometers if you want to make progress. | 16:52.46 |
| | my enabling/disabling from the dashboard code doesn't seem to be working :( | 16:53.07 |
| chrisl | It's never worked for me - authentication always failed..... | 16:53.51 |
| Robin_Watts | chrisl: It uses the same authentication as for bmpcmp. | 16:54.11 |
| chrisl | I thought I'd tried that, maybe not.... | 16:54.34 |
| Robin_Watts | Its entirely possible I've screwed up. | 16:56.54 |
| | tor8: ping | 16:57.38 |
| tor8 | yes? | 16:57.49 |
| chrisl | Well, I'm fairly sure I tried it before, but the authentication seems to work now - but the node doesn't get disabled.... | 16:58.01 |
| Robin_Watts | Found a problem with the prediction filter. | 16:58.05 |
| | putcomponent assumes it's writing to zeroed memory. | 16:58.29 |
| | I have a fix, but you may be able to think of a better one. | 16:58.50 |
| | Fix pushed to my master branch for your consideration. | 16:59.56 |
| mvrhel_laptop | marcosw: I reclosed bug 693159. It works fine for me. Perhaps you can check too? | 17:16.47 |
| | thanks | 17:16.49 |
| tor8 | Robin_Watts: wouldn't a memset in fz_predict_tiff be faster? | 17:40.44 |
| kens | chrisl sorry to miss your comment, yes I think there is some problem with kilometers | 17:43.05 |
| mvrhel_laptop | marcosw_: you there? | 17:43.27 |
| kens | Fortuneatly, here's a marcos, justin time | 17:43.31 |
| marcosw_ | mvrhel_laptop: I am here | 17:43.34 |
| chrisl | kens: we just need to find a way to take it down.... | 17:43.36 |
| mvrhel_laptop | marcosw_: I reclosed bug 693159. It works fine for me. Perhaps you can check too? | 17:43.49 |
| marcosw_ | is that the low dpi icc issue? | 17:44.07 |
| mvrhel_laptop | yes | 17:44.18 |
| | he also has GS_CLIENT_COLOR_MAX_COMPONENTS set to 64 | 17:44.37 |
| | in gscolor.h | 17:44.41 |
| kens | chrisl I have a bunch of seg faults and differences, but not in pdfwrite, which is where I made the changes, so it seems unreasonable | 17:45.31 |
| chrisl | kens: I got seg faults, errors and differences with an untouched master - that's definitely unreasonable! | 17:46.34 |
| mvrhel_laptop | oh great | 17:46.44 |
| chrisl | marcosw_: ping | 17:46.56 |
| mvrhel_laptop | so my clusterpush is probably not going to tell me much? | 17:47.06 |
| kens | chrisl, yes much like waht I found | 17:47.21 |
| marcosw_ | mvrhel_laptop: I'll have a look, it would be nice if the git commit hash were listed in the original report; saying master as the version isn't much help | 17:47.23 |
| mvrhel_laptop | right | 17:47.44 |
| chrisl | mvrhel_laptop: for now, ignore problems that kilometers throws up | 17:47.56 |
| mvrhel_laptop | ok | 17:48.02 |
| marcosw_ | chrisl: yes | 17:49.10 |
| chrisl | marcosw_: there's a customer bug report in support, I've created a bug, but I failed to identify the customer number...... | 17:49.51 |
| | marcosw_: subject of the support mail is: "DSP-1286: Page 4 of the attached PDF isn't rendered completely" | 17:50.32 |
| mvrhel_laptop | Robin_Watts: question for you | 17:51.09 |
| | or for anyone else who has a suggestion on this question | 17:51.57 |
| marcosw_ | chrisl: did you need me to do anything other than add the customer number to the bug and email the customer the bug number? | 17:52.40 |
| chrisl | marcosw_: and reply to the customer - thank you :-) | 17:53.05 |
| kens | chrisl I'm seeing some funny results even off kilometers | 17:53.24 |
| | Eg: | 17:54.04 |
| | Differences in 31 of 53042 non-pdfwrite/ps2write test(s): | 17:54.05 |
| | ... | 17:54.05 |
| | tests_private/pdf/PDF_1.7_FTS/fts_19_1920.pdf.psdcmyk.300.1 gs i7a meters | 17:54.05 |
| | tests_private/pdf/PDF_1.7_FTS/fts_24_2409.pdf.psdcmyk.300.1 gs inches macpro | 17:54.05 |
| | tests_private/pdf/PDF_1.7_FTS/fts_25_2504.pdf.psdcmyk.300.1 gs henrysx6 macpro | 17:54.05 |
| | tests_private/pdf/PDF_1.7_FTS/fts_25_2507.pdf.psdcmyk.300.1 gs i7a inches | 17:54.05 |
| chrisl | kens: well, I'm pretty darned certain it ain't my fault this time...... | 17:54.28 |
| kens | But all the others are on kilmeters its true | 17:54.29 |
| | chrisl I'm not trying to blame anyone .;-) | 17:54.39 |
| | But its making it hard for me to evaluate the changes I'm trying to make.... | 17:54.53 |
| chrisl | Me, too :-( | 17:55.18 |
| kens | FWIW I've got those same files showing diffs on 2 consecutive runs | 17:55.35 |
| | With modified code and HEAD | 17:55.48 |
| chrisl | But none of the recent commit runs list any such issues | 17:56.09 |
| kens | So they seem to be consistently indeterminate | 17:56.09 |
| | Actually I take that back | 17:56.39 |
| | THey aren't the same files at all | 17:56.44 |
| | I'm obviously too tired to read | 17:56.56 |
| | They are all with teh psdcmyk device though | 17:57.40 |
| | So I think there's something wrong there | 17:57.46 |
| mvrhel_laptop | well I had an interesting output from kilometers | 17:57.54 |
| | 700+ errors reading input file | 17:58.05 |
| kens | :-O | 17:58.19 |
| chrisl | mvrhel_laptop: that's the kind of thing I've been seeing - lower numbers because I was running lowres | 17:58.58 |
| kens | Well I'm going to assume my code is OK and carry on. Tomorrow though.... | 17:59.12 |
| mvrhel_laptop | my changes should only be in xps | 17:59.33 |
| kens | Its cost me a bit of time today unfortunately, chasing phantoms. mvrhel_laptop mine should only be in pdfwrite, btu I'm seeing diffs all over and seg afults too | 17:59.55 |
| | Anyway, I'm off for the nigh, bye all | 18:00.11 |
| mvrhel_laptop | bye kens | 18:00.18 |
| chrisl | mvrhel_laptop: and I had a change in jbigdec that through piles of errors in pcl - which doesn't use jbig2 | 18:00.37 |
| | Interestingly, my "gs lowres" push seems to have produced sane output..... | 18:00.44 |
| tor8 | sebras: hm, splitting debug printing functions to a separate files means we have to move opaque types into a common header file. at least in theory, it may already be the case for many of the instances. | 18:00.51 |
| Robin_Watts | mvrhel_laptop: hi | 18:59.46 |
| | I couldn't figure out the question from the logs. | 18:59.58 |
| mvrhel_laptop | well I did not ask it | 19:00.14 |
| Robin_Watts | That makes sense then. | 19:00.24 |
| mvrhel_laptop | as too much else was going on | 19:00.24 |
| Robin_Watts | My answer is therefore 23 and a fifth. | 19:00.43 |
| mvrhel_laptop | so there is a customer that wants to use a 6 color ICC profile for a device that has 8 output colorants | 19:00.58 |
| sebras | tor8: yeah, I'm thinking of what's in fitz-internal.h, including that may very well suffice. | 19:01.02 |
| mvrhel_laptop | I am toying with two things | 19:01.32 |
| | 1) make a new demo device that shows how this would work | 19:01.44 |
| Robin_Watts | mvrhel_laptop: That sounds like cross-dressing to me. | 19:01.54 |
| mvrhel_laptop | 2) kludge something together with tiffsep/psdcmyk for this | 19:02.09 |
| Robin_Watts | how would it work? | 19:02.36 |
| mvrhel_laptop | Robin_Watts: yes. it is a bit of a mess. Right now, we allow a cmyk device profile for tiffsep | 19:02.48 |
| | and the cmyk colorants are managed | 19:02.54 |
| | and the rest pass through untouched | 19:03.02 |
| | with the case above, 2 colorants would pass through untouched (if present in the document) | 19:03.30 |
| Robin_Watts | Right | 19:03.38 |
| mvrhel_laptop | there are some issues though | 19:03.47 |
| | the profile that he has (and this is true in general) does not list any colorant names | 19:04.05 |
| | so there is no way to associate the profile colorants with colorants in the document | 19:04.31 |
| Robin_Watts | Could this be implemented at the lcms 2 level? | 19:04.32 |
| mvrhel_laptop | Robin_Watts: well any conversions will work in lcms | 19:04.51 |
| Robin_Watts | i.e. by implementing a "make an 8 way profile from a 6 way one" | 19:05.12 |
| mvrhel_laptop | for example, if we have gray, RGB or CMYK input, they would get mapped to 6 color output by lcms | 19:05.17 |
| Robin_Watts | i.e. pack/unpack data on entry/exit from lcms | 19:05.32 |
| mvrhel_laptop | the issue is DeviceN or separation input colors handling | 19:05.52 |
| | I can't tell if they should pass through directly or not. I am thinking that I will need to require the colorant tag in the profile | 19:06.30 |
| | there is such a thing, and it lists the names of the colorants | 19:06.45 |
| Robin_Watts | Or you implement something to allow you to give names to colorants even if they aren't in the profile. | 19:07.09 |
| mvrhel_laptop | this is what I require when I allow the use of DeviceN profiles as input profiles | 19:07.18 |
| | Robin_Watts: oh good point | 19:07.28 |
| | I guess we have that already | 19:07.33 |
| | in the SeparationNames | 19:07.45 |
| | and Order | 19:07.49 |
| | hmm | 19:07.54 |
| | good point | 19:07.56 |
| | ok. That could work | 19:08.03 |
| Robin_Watts | InputProfileColorantNames = << puse, beige, tope, vomit >> | 19:08.05 |
| mvrhel_laptop | hehe | 19:08.13 |
| | ok | 19:08.40 |
| | I think this makes a lot of sense. | 19:08.52 |
| | I am going to think more about this. I knew you would have a good thought about it. | 19:09.46 |
| | thanks. | 19:09.50 |
| Robin_Watts | you're welcome. | 19:10.02 |
| mvrhel_laptop | I am going to head off to lunch | 19:10.03 |
| Robin_Watts | have fun | 19:10.14 |
| mvrhel_laptop | ttyl | 19:10.21 |
| Robin_Watts | tor8: ping | 19:17.57 |
| | Do you have any interest in bugs in the mupdf shading code ? | 19:18.12 |
| sebras | Robin_Watts: I do! :) | 19:22.12 |
| Robin_Watts | tests_private/pdf/customer394/problem/normal_262.pdf | 19:22.38 |
| mvrhel | Robin_Watts: you get the same result? I am not seeing that at all | 20:25.19 |
| | with win32 debug build | 20:25.32 |
| Robin_Watts | Yes. | 20:25.35 |
| mvrhel | strange | 20:25.42 |
| | I may have to pass this off to you then | 20:25.53 |
| | as I can't debug what I dont see | 20:26.03 |
| | let me run one more time | 20:26.15 |
| Robin_Watts | What hash are you on? | 20:26.17 |
| mvrhel | on the log, the last one is ec033 | 20:27.55 |
| | if that is what you mean | 20:28.02 |
| Robin_Watts | I don't have an ec033. | 20:28.17 |
| mvrhel | that is the AA support for copy_alpha | 20:28.39 |
| Robin_Watts | just retesting with 3a5a524 now. | 20:28.50 |
| | really? | 20:28.53 |
| | * 3a5a524 (origin/master, origin/HEAD) Fix for broken AA support for devices tha | 20:29.04 |
| mvrhel | http://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=3a5a524ea71a58cc0e9e0200bb98a2fc341ec033 | 20:29.13 |
| | oh I grabbed the ending digits | 20:29.29 |
| Robin_Watts | Ah. Always use the leading digits :) | 20:29.40 |
| mvrhel | so yes that is where I am | 20:29.47 |
| Robin_Watts | Fab. Just doing a clean rebuild of that. | 20:29.58 |
| mvrhel | let me do a clean and rebuild | 20:30.11 |
| | oh crap | 20:31.21 |
| | I ran the wrong command line | 20:31.25 |
| | Robin_Watts: that is likely the issue :) | 20:31.42 |
| Robin_Watts | ha :) | 20:32.42 |
| mvrhel | ok I have the issue now | 20:34.28 |
| Robin_Watts | phew :) | 20:34.52 |
| mvrhel | definitely related to the tiffsep device. tiff32nc works just fine with this setup | 20:36.24 |
| | so this is one of those rare cases where things render correctly in clist mode but not in immediate mode | 20:54.05 |
| | source profile is not getting set for some reason | 20:59.46 |
| | ok vmreclaim is screwing it up. I recall having this issue before | 21:02.42 |
| sebras | Robin_Watts: oh I didn't realize it was a customer bug. :-/ | 21:12.30 |
| Robin_Watts | sebras: It's one of about 200 odd files they dropped on us. I'm just gradually looking through them. | 22:36.24 |
| | I didn't fancy tackling it at 8pm :) | 22:36.37 |
| | I'll have a look tomorrow or something. | 22:36.45 |
| ray_laptop | mvrhel: RU there (returning your call) | 22:38.39 |
| | Forward 1 day (to 2012/07/03)>>> | |
IRC Logs