| <<<Back 1 day (to 2013/06/16) | 2013/06/17 |
vtorri | chrisl, i have filled a bug report about compiling gs with msys | 06:38.32 |
chrisl | vtorri: I saw it | 06:42.09 |
vtorri | chrisl, there are other compilation errors with jpeglib and libpng which are provided with gs | 06:42.51 |
| also, there are compilation warnings about pointer to int on win 64bits | 06:43.14 |
| because on win 64 bits, long are 32 bits long, unlike on unix | 06:43.40 |
chrisl | Yeh, those are mostly benign - just the compiler being dumb | 06:43.55 |
| vtorri: FWIW, I only get one link error on msys - no errors in jpeg nor png | 06:44.26 |
vtorri | i'm waiting for the libtiff problem to be fixed to provide other bug reports | 06:45.11 |
chrisl | I don't see the libtiff problem - has msys removed size_t recently? | 06:45.48 |
vtorri | it depends on the toolchain | 06:46.15 |
| try mingw-w64 | 06:46.29 |
| it's better than mingw.org | 06:46.40 |
chrisl | Why would mingw-w64 remove a (now standard) data type?? | 06:47.01 |
vtorri | in addition, the math routines in mingw-w64 are faster than the ones in mingw.org and vc++ | 06:47.05 |
| not removed | 06:47.13 |
| moved | 06:47.18 |
| well | 06:47.21 |
| include stdlib.h | 06:47.27 |
chrisl | So does libtiff compile on its own? | 06:47.51 |
vtorri | and ask the mingw-w64 devs :) | 06:47.57 |
| yes | 06:48.04 |
| i have compiled it myself | 06:48.10 |
chrisl | Which version, though? We use the libtiff configure script, so..... | 06:48.47 |
vtorri | libtiff 4.0.3 | 06:49.13 |
chrisl | Hmm, we've got 40.01 | 06:49.52 |
| 4.0.1 | 06:49.55 |
vtorri | my compilation flas are --disable-static --disable-cxx | 06:50.50 |
| (except the host and prefix) | 06:50.58 |
chrisl | So why are you using those? | 06:51.17 |
vtorri | i never use static versions on windows | 06:51.48 |
| and for my needs, i don't care about c++ stuff | 06:52.10 |
chrisl | Oh, for libtiff | 06:52.24 |
vtorri | chrisl, yes | 06:52.29 |
| they are compilation flags when i have compiled libtiff myself | 06:52.54 |
| btw, libtiff 4.0.3 is "old" (september 2012) so mabe it should be updated in the gs repo | 06:54.03 |
| maybe* | 06:54.50 |
chrisl | I know, I keep an eye on the updates, and what's changed. | 06:55.02 |
vtorri | ok | 06:55.10 |
chrisl | Well, I'll look at the build problem properly at some point, but I've got higher priority stuff to be working on | 06:55.37 |
vtorri | btw, iirc, a sub-configure is used for libtiff, right ? | 06:55.41 |
chrisl | Yes it is | 06:55.50 |
vtorri | iirc, the configure prefix of gs is not passed to the libtiff one, is it intentional ? | 06:56.13 |
chrisl | Yes. We don't "install" anything from libtiff, so there's no point | 06:56.38 |
vtorri | ok | 06:56.45 |
chrisl | We use the configure script to get the platform specific header files, and that's pretty much all | 06:57.13 |
vtorri | ok | 06:57.19 |
| also, you provide a way to use an external libtiff, but why isn't it the same for libjpeg and libpng ? | 06:57.57 |
chrisl | Again before my time | 06:58.15 |
vtorri | ok | 06:58.20 |
chrisl | The configure option is redundant, anyway. *If* we allow the external lib to be used, you can prompt it by removing the directory from the Ghostscript source tree, and rerunning configure | 06:59.13 |
vtorri | or you can remove it defenitively and make libtiff a needed dependency | 07:00.40 |
chrisl | No we won't do that | 07:01.05 |
vtorri | ok | 07:01.22 |
| just for my curiosity, why ? | 07:01.43 |
chrisl | We have spent considerable time doing QA on the source code we ship - if you link to random version of a library, that QA is rendered useless | 07:02.29 |
| We also have occasional fixes that take time to get into the upstream project (or aren't accepted for some reason), so the source we ship *may* be patched | 07:03.31 |
vtorri | ok | 07:03.47 |
chrisl | Hmm, I've now been to five web sites related to mingw_w64 and I haven't found an installer on any of them....... | 07:04.53 |
vtorri | i give you a link | 07:05.15 |
| chrisl, do you have win 32 bits or win 64 bits ? | 07:05.44 |
chrisl | 64 | 07:05.49 |
vtorri | chrisl, do you prefer gcc 4.7 or 4.8 ? | 07:06.21 |
chrisl | Don't care, either should work fine | 07:06.34 |
vtorri | http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/rubenvb/gcc-4.8-release/x86_64-w64-mingw32-gcc-4.8.0-win64_rubenvb.7z/download | 07:06.55 |
| download it somewhere (like in /mingw/mingw64 or something like that) | 07:07.29 |
| update PATH so that it first points to the 'bin' subdir | 07:07.48 |
| and that's all | 07:07.52 |
chrisl | Ugh, this really has nothing to do with the normal mingw project, does it? | 07:08.56 |
vtorri | indeed | 07:09.02 |
| it's better | 07:09.07 |
chrisl | It's "better" except when it doesn't work...... | 07:09.25 |
vtorri | heh | 07:09.44 |
| i compiled libtiff myself with that toolchain | 07:09.56 |
| and it workds flawlessly | 07:10.02 |
| works | 07:10.06 |
| so... | 07:10.11 |
| maybe there is a problem on your side | 07:10.31 |
chrisl | So, I've compiled Ghostscript 9.07 on mingw and it works fine - no problem here | 07:10.42 |
vtorri | if you think that it's sufficient for you, then forget my bug report | 07:11.41 |
chrisl | I will look at it, when I get time. But my comments about being a "niche" platform count even more, in this case, and I'll prioritise (partly) on that basis | 07:12.51 |
vtorri | mingw-w64 is nowadays more used than the original mingw | 07:13.50 |
| just because mingw-w64 is quickly improving, while mingw is almost stagnating | 07:14.27 |
chrisl | I doubt that, baring in mind that msys-git is currently the best way to use git on Windows..... | 07:14.50 |
vtorri | you won't see gc 4.8 in mingw this year | 07:14.52 |
| i'm talking about mingw | 07:15.08 |
| not msys | 07:15.12 |
chrisl | They are quite intimately related | 07:15.30 |
vtorri | msys can use any toolchain that you want | 07:15.49 |
| so not so related | 07:15.54 |
| see, even cygwin is currently using mingw-w64 | 07:16.09 |
| and MSYS 2 also | 07:16.20 |
chrisl | If it's so popular, how come there's no installer..... ;-) | 07:17.25 |
vtorri | ho, btw, you're right, msys-git is quite nice, i use it | 07:17.27 |
kens | chrisl can I interrupt a bit ? | 07:17.48 |
chrisl | kens: please do! :-) | 07:18.00 |
kens | bug #694319 | 07:18.14 |
| It 'looks' like memory corruption, I cna only make the problem exhibit on Linux, not on any flavour of Windows buld | 07:18.39 |
vtorri | why an installer when it's just a tarball to decompress, but there is one, but i stop here | 07:18.45 |
kens | chrisl can you try the bug and see what result you get ? | 07:19.06 |
| I had to modify the source even to get to the same point that Marcos put in his traceback | 07:19.37 |
| Of course, the problem is basically down to making the PDF itnerpreter continue after an error... | 07:20.30 |
chrisl | A debug build runs to completion for me, I'll try a release build once it's built | 07:21.15 |
kens | debug build failed for me :-( | 07:21.25 |
| 64-bit mind but I'm sure tha'ts what you are using | 07:21.40 |
chrisl | Yes, 64 bit | 07:21.50 |
kens | Makes me think its even more likely to be memory corruption | 07:22.11 |
chrisl | Release build seg faulted on page 45 | 07:22.36 |
kens | It shoudl seg fault on closing | 07:22.52 |
| When it writes out the PS file | 07:23.00 |
| Its a 45 page file so I guess that's the same | 07:23.23 |
| My debug version also give me a memory warning about chunks | 07:24.27 |
chrisl | Hmm, I'm going to grab a coffee, then I'll try it again with a fresh build | 07:25.13 |
kens | OK I'll keep poking with a stick | 07:25.26 |
chrisl | Hmm, still no crash in a debug build, but valgrind throws out a bewildering array of errors :-( | 07:34.19 |
| Ah! running under valgrind crashes - actually, it crashes valgrind, too! | 07:35.18 |
| kens: I did find a stack corruption problem in gxtype1.c the other day, with this file. It might be related | 07:38.07 |
| vtorri: what environment do you run that toolchain in? | 07:43.33 |
vtorri | chrisl, msys | 07:43.47 |
kens | chrisl went to get a coffee, back now | 07:44.03 |
chrisl | vtorri: OKay, so I get no errors in libtiff, and I get all the way to the same linker error I got with the "stock" mingw32 tool chain | 07:44.36 |
vtorri | chrisl, i did what i have said : untar the tarball in /mingw/mingw64 (that is c:/mingw/mingw64), update PATH and that's all | 07:44.44 |
| really ? | 07:44.56 |
| arg | 07:44.58 |
| strange | 07:45.10 |
chrisl | The link error is down to mingw being a half breed between Windows and Unix - we're pulling in *some* Windows code, and *some" Unix code, and we're missing a bit of the Windows code. | 07:45.50 |
vtorri | you are sure that the PATH in msys begins with the bin one of the mingw-w64 toolchain ? (in case...) | 07:46.10 |
kens | chrisl The problem I see is that the stream which is being written to 'seems' OK, but when it is freed I get a 'Chunk parsing error' in gsalloc.c(1461) followed by a SEGV at line 874 | 07:46.12 |
chrisl | kens: the crash I saw was in the Type 1 code | 07:46.59 |
kens | Oh, very different then | 07:47.09 |
vtorri | going to work | 07:47.10 |
| bye | 07:47.13 |
chrisl | vtorri: yes, it's deinitely using the mingw x64 compiler | 07:47.18 |
kens | Let me update my source | 07:47.37 |
| Hmm, Git says my master is up to date | 07:48.51 |
chrisl | kens: the problem I saw the other day was that a glyph runs a subr with no numbers on the operand stack, when pops one or number off the (already empty stack), then the subr pushes numbers onto the stack - the op stack pointer now being *below* the bottom of the actual stack. The result is that the C stack gets corrupted. | 07:50.47 |
kens | Seems like a very different problem | 07:51.31 |
| I just did a clean and a debug clean and am rebuilding both | 07:52.24 |
chrisl | kens: if you're interested: http://git.ghostscript.com/?p=user/chrisl/ghostpdl.git;a=commitdiff;h=1d49dbbc | 07:54.01 |
kens | I see, but I should have that commit already | 07:54.30 |
chrisl | No, I never committed that - and I just noticed a mistake! | 07:54.51 |
kens | Oh, I just noticed it wasn't a commit | 07:55.01 |
| Oh, a clean debug build doesn't segv now | 07:56.13 |
chrisl | That commit fixed the crash I saw in pdfwrite (I think) with that file in a debug build, but it still crashed in a release build.... | 07:56.24 |
| Which is why I didn't push the change | 07:56.40 |
kens | D'oh, I need the -r300 | 07:57.00 |
chrisl | Even with that commit "fixed", it still crashes in a release build :-( | 07:57.37 |
kens | OK with -r300 debug and release builds still seg fault | 07:57.47 |
| Presumably your fix prevents the memory corruption in a debug build | 07:58.16 |
chrisl | It prevents *one* of the memory corruptions.... | 07:58.40 |
kens | :( | 07:58.47 |
chrisl | But a debug build runs to completion for me - for goodness sake :-( | 07:59.04 |
kens | It probably just shifts the corruption to somewhere harmless | 07:59.29 |
| I don;t even get teh same fault as Marcos in a debug build, for me that crashes in stell() | 07:59.55 |
| I have to patch around that to get to the point where Marcos sees a crash | 08:00.10 |
chrisl | kens: in your repo, is the latest commit your last commit ("silence a valgrind warning.....")? | 08:01.49 |
kens | Yes that's what I have | 08:02.00 |
| A release build, run under ddd doesn't file, it gives a nice error and exits | 08:02.19 |
| door, brb | 08:02.24 |
| Ooops our next door neighbour has locked herself out of the house. However, she's locked the kids *in* the house..... | 08:04.09 |
| chrisl I think you should probably commit your fix, since it fixes at least one problem | 08:04.35 |
chrisl | kens: okay, I'll do that | 08:05.02 |
kens | back to our neighbours again.... Might be a while | 08:05.24 |
| OK back again | 08:14.37 |
chrisl | I'm doing a clusterpush on that change before I push it to casper | 08:17.05 |
kens | Seems reasonable | 08:17.12 |
| I'm applying it here, but its unfamiliar tools time so its taking me longer than I would like | 08:17.31 |
chrisl | Hmm, there's compile fails on the cluster :-( | 08:17.57 |
| Oops, I see - must have typed part of a command into the editor windows! | 08:19.10 |
kens | Been there, got all the T-shirts | 08:19.31 |
chrisl | And now the cluster seems to be throwing a hissy fit :-( | 08:23.28 |
kens | chrisl that change, I can see the c_callsubr needs to have fixed2int prepended to the pdata-.... But in the c2_callgsubr is the csp < &(cstack[0]) the right way round ? | 08:24.37 |
| Actually, forget that | 08:25.56 |
chrisl | kens: that was the mistake I mentioned earlier..... git.ghostscript.com/?p=user/chrisl/ghostpdl.git;a=commitdiff;h=579e9024 | 08:26.20 |
kens | I think I'll wait until you commit it, then I cna pull the correct version :-) | 08:26.52 |
chrisl | That might be easier..... | 08:27.37 |
kens | Its easier for me than trying to cut/paste between VM and Windows, and use nano.... | 08:28.04 |
chrisl | Can't you just pull into your Windows repo? | 08:28.38 |
kens | Yes, but I don't need to, Windows works | 08:28.57 |
| But I have the Firfox window in Windows, and the editor in Linux.... | 08:29.15 |
chrisl | Well, you could just pull into your linux repo....... | 08:29.36 |
kens | And I will, when you commit it :-) | 08:29.46 |
chrisl | The cluster seems happy now, so shouldn't be too long | 08:30.16 |
kens | Indeed, that's why I thought I'd wait, its probably quicker than me struggling with VMs and stuff | 08:30.37 |
| chrisl I wonder if memento can help spot the memory corruption remaining in that problem file ? | 08:38.57 |
| I'll try a build and run fter I get your fix. | 08:39.08 |
chrisl | It's possible. I'll also try a valgrind run with the one allocation per chunk hack | 08:40.21 |
kens | Hmm, turns out our neghbour didn't lock herself out exactly, she went out to the garden and her 4 year old son locked the door behind her.... | 08:45.53 |
chrisl | :-) | 08:46.28 |
kens | Of course, he then couldn't figure out (or be told) how to unlock it | 08:46.46 |
chrisl | Or didn't want to? | 08:47.14 |
kens | Oh I think he wanted to, by the time I got there *both* children were in floods of tears | 08:47.35 |
| Fortunately she'd left an upstairs window open, so I used our ladder to climb in | 08:47.57 |
chrisl | Well, live and learn, I suppose | 08:48.13 |
kens | :-D | 08:48.19 |
| I think that's the thrid time in 3 years I've had to get her back into her house.... | 08:48.48 |
chrisl | You should start charging a fee | 08:49.14 |
kens | Well, at least its better than fixing people's computers | 08:49.39 |
| your cluster run looks OK | 08:50.34 |
chrisl | Yeh, exactly what I expected, so pushed | 08:50.49 |
kens | Great I'll go synchronise | 08:51.02 |
chrisl | I've noted it on the bug | 08:52.11 |
kens | Hmm debug build still SEGV, I'll do a full clean and rebuild | 08:55.59 |
chrisl | That does not surprise me - the crash I saw that sparked that fix was quite proximate to the fix | 08:57.38 |
kens | Well, I still get a SEGV, time to fire up ddd | 08:57.55 |
| Yes, same crash, same place | 08:58.58 |
chrisl | It's weird that I don't see the crash in a debug build | 08:59.24 |
kens | I get it both debug and release | 08:59.37 |
| Though as I said, I have to put a patch in just to get that far, mornally it crashes even earlier for me (on a debug build anyway) | 09:00.00 |
chrisl | You are using 64 bit LInux? | 09:00.29 |
kens | Certainly am | 09:00.34 |
chrisl | Bemused...... | 09:00.54 |
kens | In a VM of course, with 2GB memory. But its the same crash Marcos reported on a real Linux installation | 09:01.09 |
| Or at least the backtrace is the same | 09:01.27 |
chrisl | Well, I've started a valgrind run with the single block per chunk hack, but it's going to take an age to run :-( | 09:01.43 |
kens | If I could use ddd better I might be ablle to solve this (and if I understood GS's memory handling too) | 09:02.07 |
| What I see is that in i_free_object() 'pstype' is invalid memory | 09:02.52 |
| that's given by the block of memory -1, cast to a obj_header_t pointer, and then the 'o_type' member of that structure | 09:03.32 |
| But it looks like that's actually a macro os some kind | 09:03.59 |
chrisl | So, what I would normally do is find where the object is allocated, and put a watch on the pstype entry | 09:04.16 |
kens | Its a stream, figuring out where its allocated could be tricky | 09:04.52 |
| NB there is no psype entry | 09:05.08 |
| pstype is given by pp->o_type but that's not a member either so I assume its a macro | 09:05.46 |
chrisl | I think it's a union | 09:06.23 |
kens | In fact it seems to be o->d->o->t.type | 09:06.26 |
| That first o should be a pp | 09:06.40 |
kens | would be a lot happier if this would fail under Windows | 09:07.34 |
| Oh, and it looks like pdev->strm (and probably pdev) are subject to relocation by the garbage collector | 09:11.22 |
chrisl | Oh wonderful :-( | 09:12.26 |
| Aha! I can get it go wrong on peeves | 09:14.34 |
kens | You're ahead of me. FOr what its worth the stream is allocated in gdev_vector_open_file_options | 09:15.01 |
| (gdevvec.c) | 09:15.10 |
chrisl | Okay, if I use gcc 4.4.1 I can get it to wrong here, too..... | 09:18.24 |
kens | What were you using before ? Something more recent ? | 09:18.38 |
chrisl | 4.7.2 | 09:19.08 |
kens | Well that would change the memory pattern I guess | 09:19.27 |
chrisl | Okay, so pstype ends up as some crazy address out around Saturn? | 09:20.14 |
kens | Well its certainly barking | 09:20.25 |
chrisl | Would it make you happy if I offered to run with this one? | 09:20.45 |
kens | I can't look at it right now, I'm back at the beginning in the debugger, looking at the allocation in i_alloc_strcut | 09:20.50 |
| chrisl it would make me happy, but I'd feel gulty | 09:21.01 |
| I'm running a Memento build at the same time | 09:21.12 |
| just to see if it tells me anything | 09:21.26 |
chrisl | Okay, if memento doesn't show anything useful, let me hammer on it for a bit - I'm at least more familiar with the debugging tools | 09:22.09 |
kens | And the Ghostscript memory stuff..... | 09:22.24 |
chrisl | Oh, it also thinks the memory allocation was 1531390564 bytes - that's probably wrong! | 09:23.06 |
kens | I didn't notice that, but I'm sure its wrong :-) Its undoubtedly the same memory corruption | 09:23.32 |
chrisl | Yes, the memory header ID is corrupted as well | 09:24.06 |
kens | I'm not surprised, something is scribbling whwere it ought not to | 09:24.26 |
| I was fairly sure that was the case, but at least you;ve confirmed it | 09:24.40 |
| Oh, looks like all the stuff in i_alloc_struct comes down to macros | 09:25.11 |
chrisl | Yes, nice isn't it :-( | 09:25.56 |
kens | Incomprehensible would be a better description, I was hoping to find the memory being stomped on. Oh well..... | 09:26.20 |
| Ah its OK obj tells me what I want I think | 09:26.47 |
chrisl | The memory header seems to be getting overwritten in gs_md5_append | 09:39.29 |
kens | Hmm, interesting, that's kind of an odd place | 09:39.49 |
| Memento is going to be a while, its on page 9 at the moment :-( | 09:40.33 |
chrisl | Hmmm, something borked - gdb and/or ddd think that md5.c is in debugobj :-( | 09:45.26 |
kens | :-O | 09:45.36 |
| I did get some similar madness, complaining that it couldn't find soure files in debugobj (while simultaneously displaying the source files...) | 09:46.13 |
chrisl | It seems very adamnt about it | 09:48.22 |
| or even adamant | 09:48.30 |
kens | Or Adam Ant ? | 09:48.40 |
| I have no idea whay it would be complaining about that | 09:48.52 |
| chrisl what was it trying to process when it called gs_md5_append ? | 09:51.01 |
| (Memento has reached page 10...) | 09:51.19 |
chrisl | I don't know, whatever was going on, I couldn't inspect variables, or anything :-( | 09:51.40 |
kens | O.O | 09:51.48 |
| Seriously messed up | 09:51.54 |
chrisl | Yep | 09:52.02 |
kens | I have to confess I'm not making any progress here, just floundering in the dark. And memnto only reached page 13 so far | 10:06.18 |
| But the first content stream error is on pag 12 | 10:06.35 |
chrisl | Memento sets the single allocation per chunk flag, and that *really* hurts the speed | 10:07.09 |
kens | I guess that explains it then | 10:07.19 |
chrisl | kens: any idea where cos_stream_t is defined? | 10:10.45 |
kens | One second, I can find that | 10:10.55 |
| Its a cos_stream_s | 10:11.11 |
chrisl | I mean actually defined, yes, but I can't find that defined | 10:11.26 |
kens | seems to be defined i gdevpdfo.h | 10:11.29 |
| Using... A macro! | 10:11.44 |
| Its a horrible macro too | 10:12.37 |
chrisl | Okay, I'm starting to see some vague light - let me try to clarify my thoughts...... | 10:13.36 |
| Actually, maybe a caffeine boost is in order...... | 10:16.08 |
kens | OK no problem | 10:16.18 |
chrisl | kens: <sigh> this is going to take some time, but it is definitely a memory management problem - I suggest you leave it with me for a while | 10:30.57 |
kens | jumps at it | 10:31.27 |
| Thanks chris | 10:31.36 |
chrisl | I'll let you know when I come up with something worth reporting.... | 10:32.02 |
kens | ok | 10:32.11 |
Robin_Watts | paulgardiner, tor8: png | 10:58.04 |
paulgardiner | Hi | 10:58.27 |
ghostbot | hola | 10:58.27 |
Robin_Watts | paulgardiner: See your email. | 10:58.38 |
paulgardiner | Ah right. Just reading it now | 10:59.41 |
tor8 | morning | 10:59.53 |
Robin_Watts | paulgardiner: Actually, while I remember. You said last week that you had a tweaked version of the smoothness review on your repo. | 11:00.04 |
| I couldn't find it. | 11:00.06 |
| tor8: morning. | 11:00.10 |
| tor8: Similarly see your email :) | 11:00.28 |
paulgardiner | Robin_Watts: Yeah, I forgot to push, but did this morning, so you should see it now | 11:00.29 |
Robin_Watts | I'm going to try to pull my progressive changes up to the current master now, so you two can pull them apart. | 11:01.13 |
paulgardiner | Robin_Watts: I agree with your interpretation | 11:04.01 |
tor8 | Robin_Watts: the startup time discussion from a few weeks ago, that just petered out or did we come to any conclusions? | 11:04.56 |
Robin_Watts | tor8: It petered out. | 11:05.06 |
tor8 | paulgardiner should get a nexus 10 (or similarly high powered device) so he can see the same glitchiness with scrolling frame drops | 11:05.40 |
paulgardiner | tor8: After our discussion at the meeting, I may be able to address it without the feedback of having a device that shows the problem. | 11:06.41 |
Robin_Watts | Nexus 10 has a dual core CPU. | 11:07.08 |
| Nexus 7 has a quad core. | 11:07.14 |
paulgardiner | tor8: it would be handy though, to bring henrys in on this, just to keep him in the loop on all things I'm looking into | 11:07.30 |
Robin_Watts | Given that we have a Nexus 10 between us, I wonder if we should get a Nexus 7 as the next device? | 11:07.43 |
| THe Nexus 4 is similarly quad core. | 11:08.01 |
kens | Stella has one of those | 11:08.03 |
| Nexus 7 | 11:08.09 |
paulgardiner | On the other hand, possibly access to a device that performs significantly differently to my S2 may be handy | 11:08.21 |
Robin_Watts | kens: I bet she'd be unwilling to loan it out though :) | 11:08.22 |
kens | Highly :-) | 11:08.28 |
| Think Gollum and ring :-( | 11:08.48 |
paulgardiner | kens: Ha. Like it. :-) | 11:09.19 |
| They have Nexus 4 as reference device. Well they say (such as) | 11:11.32 |
Robin_Watts | The transformer prime is quad core, so we can use that. | 11:13.37 |
paulgardiner | Do we understand the correlation between hardware and glitching? | 11:15.51 |
kens | lunches | 11:22.26 |
Robin_Watts | paulgardiner: I think the belief is that we glitch on everything. We just don't notice it on devices that aren't hitting 30fps anyway. | 11:23.45 |
paulgardiner | Do you mean not hitting 60fps? | 11:24.55 |
Robin_Watts | no. | 11:25.04 |
paulgardiner | My S2 looks too smooth to be missing 30fps | 11:25.13 |
Robin_Watts | So, I'm trying to get the progressive commit up to date (and of course that's conflicted with paulgardiner's recent xref changes) | 11:36.19 |
| The JNI bindings - I would have thought that we want to construct the JNI interface carefully so that it mirrors the C as much as possible - but there may be a case for deviating slightly if it's more natural to the java interface obtained. | 11:37.37 |
| and probably to do that, we'd want to have the header file changes done first? I guess that's not essential, but feels right to me. | 11:38.04 |
tor8 | Robin_Watts: how deep do we want the JNI bindings to go? | 11:39.10 |
| the fz_document and fz_device stuff are obviously needed | 11:39.25 |
| and also the pdf_obj and xref edit/save layer, or do we want to use the higher level abstraction for annotations and widgets? | 11:40.13 |
Robin_Watts | tor8: This is what we need to decide. | 11:40.26 |
tor8 | header file changes should probably go through soon-ish | 11:40.34 |
Robin_Watts | I think we should push forward with the header file changes. | 11:40.48 |
paulgardiner | That's probably the right approach for the JNI bindings, but I also wonder about instead thinking carefully about how it would be used from android and targetting that specifically. | 11:41.03 |
Robin_Watts | Then try to get a minimal JNI set in place (fz_document/fz_device) | 11:41.13 |
| and I suspect our experience doing that will color our thoughts on the shape of the rest of it. | 11:41.30 |
| paulgardiner: It might be nice to drive the JNI work by what we'd need to move the android app over to using it. | 11:42.23 |
tor8 | Robin_Watts: would it be worth doing more language bindings at the same time (like Lua, Python and/or Javascript) so we don't paint ourselves into a java language specific corner for how the foreign-language apis will look like | 11:42.50 |
paulgardiner | I also wonder about asking Google how they'd like the JNI interface. IMHO, the android architecture is expertly crafted, certainly far better than any interface I've ever designed | 11:42.51 |
Robin_Watts | I believe that's what mvrhel did with the Win8 stuff. | 11:42.52 |
| tor8: I would be wary about taking on too much work. | 11:43.27 |
| Bear in mind they say "Release in the second half of 2013" | 11:43.44 |
tor8 | if we provide enough low level APIs for JNI, wrapping those up in some elegantly crafted java classes to provide activities and UI components doesn't have to touch any JNI stuff | 11:44.03 |
Robin_Watts | Even if they mean release in November, that's probably "final QA by october." | 11:44.11 |
paulgardiner | tor8: but multiple JNI calls is inefficient. My thinking stems from realising that if a full low-level JNI interface had been available when I started work on the app, I would probably still have had to make my own higher-level JNI entry points. | 11:45.52 |
tor8 | paulgardiner: how inefficient are we talking? milliseconds per call? | 11:46.18 |
paulgardiner | tor8: yeah, good point. Mostly we call the JNI to do a fairly large task like to render. If that involves 8 JNI calls rather than 1, it would probably have small effect in time taken as a percentage of the total | 11:48.06 |
tor8 | I think the biggest bit of work doing JNI bindings is transferring data structures like the outline tree and arrays etc | 11:48.25 |
| another question is how closely to match with java classes for struct | 11:50.41 |
| s | 11:50.42 |
| it'd be cool if we did have java classes for devices and documents and pages rather than a single big "here's the JNI wrapper" class | 11:53.00 |
Robin_Watts | tor8: yes, that's the way it should be. | 11:53.19 |
| PDFDocument extends FzDocument. | 11:53.42 |
| FzDrawDevice extends FzDevice etc. | 11:53.56 |
| FzPage | 11:54.25 |
tor8 | yup. | 11:54.38 |
| Robin_Watts: updated windows mingw commit on tor/master | 11:55.08 |
| doesn't change the main/wmain stuff other than the #ifdef | 11:55.19 |
Robin_Watts | tor8: I'll get to that as soon as I have all the bits put back together here :) | 11:55.38 |
tor8 | I wonder what MSVC does in the presence of both main() and wmain() | 11:55.57 |
Robin_Watts | barfs, I bet. | 11:56.25 |
tor8 | mingw doesn't seem to recognize wmain, even with -municode | 11:56.42 |
| warning: ambiguous entry point; selected 'mainCRTStartup' | 11:59.14 |
| so it picked main() rather than wmain()... | 11:59.50 |
| Robin_Watts: and wchar/utf-8 function reshuffling commit on tor/master | 12:34.04 |
chrisl | kens: ping | 12:51.10 |
kens | chrisl pong | 12:57.24 |
| (but I have to go dismantle a wardrobe shortly) | 12:57.38 |
chrisl | kens: so, now I'm confused, and have the beginnings of a headache. What did you patch to get past the stream error? | 12:58.00 |
kens | which stream error ? | 12:58.40 |
| I had a problem in cos_add_stream that I had to work around (stream was null, not being tested) | 12:59.03 |
chrisl | I thought you said you had to apply a patch to get to the error Marcos reported? | 12:59.13 |
kens | Yes, the one in cos_add_stream | 12:59.29 |
| Otherwise it SEGV's there for me | 12:59.38 |
| Or did, anyway | 12:59.42 |
| Give me a minute to power up a VM | 13:00.01 |
| Yes in cos_stream_add I tested for (!s) and return 0 if it is NULL, otherwise it tries to stell(s) and that SEGVs | 13:01.40 |
| I'll just stash that and try without it | 13:02.02 |
chrisl | kens: hmm, the problem I'm seeing is that pcs->pdev is garbage, so we never get to there | 13:02.34 |
kens | That's not a problem I have seen so far | 13:02.50 |
chrisl | Using -Z@ the pointer value is 0xa1a1....... | 13:03.25 |
kens | Well that's no good | 13:03.34 |
| pcs is a pointer to a colour space ? | 13:03.44 |
chrisl | kens: no, it's some stream thing in cos_stream_add() | 13:04.30 |
kens | Oh.... | 13:04.37 |
| Just a minunte, I'll runn ddd | 13:04.49 |
chrisl | it's a cos_stream_t *pcs | 13:05.31 |
kens | I get a SEGV in stell(stream *s) , because s is NULL | 13:05.58 |
| called from cos_stream_add mind you | 13:06.17 |
| Looks like i'm just lucky to get that far I think | 13:06.49 |
chrisl | So with -Z@ I get pcs->pdev == (gx_device_pdf *) 0xa1a1a1a1a1a1a1a1 | 13:06.50 |
Robin_Watts | kens: You neighbour has now locked herself in a wardrobe? | 13:06.59 |
kens | Robin_Watts : ROFL | 13:07.08 |
| Its one we're selling (and no, to the best of my knowledge there is no door to Narnia) | 13:07.25 |
| chrisl looks like hte pdev is borked for me | 13:08.37 |
| FirstPage is 1065353215 | 13:09.01 |
chrisl | OKay, so that's at least consistent | 13:09.04 |
kens | It looks like I'm just 'lucky' in the sense that it isn't badly enough broken to cause a prblem for me (at that point) | 13:09.32 |
chrisl | Well, value it gets with -Z@ suggests that the memory has not been set after allocation | 13:10.13 |
kens | Hmm, well I *think* this particular stream is the main output file, which is opened in gdev_vector_open_file_options or similar name | 13:10.57 |
| But I also think its been relocated since it was opened | 13:11.17 |
chrisl | No, I don't think it is the main file - it may be a filter "on top" of the main file | 13:12.09 |
kens | Yeah in the back trace I see it starting from pdf_close calling ps2write_dsc_header which calls copy_procsets, so this *should* all be going into the main file | 13:12.13 |
| OK it could be a filter, true | 13:12.26 |
| Probably is in fact | 13:12.32 |
chrisl | The cos_procs suggest it's an A85E fitler | 13:13.03 |
kens | My only caveat is that because we are ignoring errors in the PDF interpreter, its entirely possible that its not writing to the file it *thinks* it is. | 13:13.06 |
| pdev->strm is the 'current' stream, but that changes depending on what we are doing. If we don't reset it properly, then it could be pointing to a temporary file. | 13:13.51 |
| I'll have to go and dismantle this wardrobe, I'll be back in a bit. | 13:14.08 |
chrisl | OKay, thanks | 13:14.15 |
kens | OK wardrobe dispatched | 13:54.16 |
Robin_Watts | tor8: both commits look good to me. will push them. | 14:01.21 |
paulgardiner | Email that came in from tech with time 14:11 keeps killing Thunderbird | 14:03.32 |
Robin_Watts | 14:11 in what timezone? | 14:04.48 |
| I've got one called "support11:41:16" ? | 14:05.30 |
kens | Could be the HPGL interpreter one, it has attachments | 14:06.00 |
| 2xtiff file and a PDF | 14:06.08 |
| SOrry HPGL file I mean | 14:06.14 |
Robin_Watts | ooh, yes. | 14:06.23 |
| that makes my thunderbird unhappy too. | 14:06.33 |
kens | Eudora is OK with it | 14:06.42 |
Robin_Watts | I bet eudora doesn't try to do thumbnails of the tiffs or something stupid, and thunderbird does. | 14:08.05 |
kens | Nope, too old to do that | 14:08.13 |
| I just get an icon for the associated program | 14:08.25 |
Robin_Watts | kens: Is it worth you zipping the attachments and resending the mail with the zipfile ? | 14:09.07 |
kens | I cna f you want, but to be honest its pretty clearly one for Marcos and Henry | 14:09.28 |
Robin_Watts | I guess. | 14:09.36 |
kens | The missing image is misleading I think | 14:09.38 |
Robin_Watts | I feel bad deleting the mail. | 14:09.50 |
kens | I see more than a missing image, it looks more like a whole colour overlay has gone | 14:09.52 |
| I'll zip and send it to support | 14:10.17 |
chrisl | Hmm, 17Mb of uncompressed attachments, I'm surprised it caused a splutter or two! | 14:12.04 |
kens | THe zip is 8Mb its on its way now along with the text of the original message | 14:13.41 |
| Of course, it takes a lot longer to *send* *mb thant to receive 17.... | 14:14.22 |
tor8 | Robin_Watts: thanks. | 14:15.22 |
| so should I go ahead and do the include file shuffle? | 14:15.38 |
kens | Hmm, when I run the file provided, I get 2 pages of PJL.... Well I guess Henry will know what magic runes to write to make it work | 14:17.23 |
Robin_Watts | tor8: I think you should. | 14:17.42 |
| tor8: Do you have a version in the repo for us to look at? | 14:17.59 |
| Or are you still working on it ? | 14:18.03 |
tor8 | Robin_Watts: tor/headers has the first step | 14:18.14 |
| next step is merging the regular and -internal headers | 14:18.27 |
kens | OK Robin_Watts paulgardiner, the mail has been resent with teh attachments zipped, and has left my mcahine, should be with you 'soon' | 14:18.34 |
tor8 | and after that, split them into modules | 14:18.36 |
Robin_Watts | Gonna do all that on a branch? Sounds good. | 14:19.33 |
tor8 | Robin_Watts: any preference for which modules (or how to name them) are welcome | 14:19.35 |
| the merging and splitting will make any header file changes difficult to merge though | 14:19.53 |
| so if there are any pending commits that affect header files, now's the time to say so | 14:20.08 |
Robin_Watts | tor8: We'll cope. | 14:20.14 |
| aargh. | 14:22.42 |
| With the progressive loading code, whenever I met an xref, I just ensured that the table was big enough. | 14:23.08 |
| and whenever I read an object, I put it into the table. | 14:23.17 |
| With the new code that keeps xrefs in the order they were in before, that's hard. | 14:23.41 |
| How do I know what xref an object goes into ? | 14:23.57 |
henrys | marcosw are you fielding guillaume's bug or should I look at it directly? | 14:31.54 |
kens | I tried his file and got a page of PJL henrys, but then I know nothing :-) | 14:36.02 |
henrys | probably best for it to go through the system. | 14:37.18 |
| oh I see you guys were talking about it. | 14:38.33 |
kens | :-) | 14:38.37 |
henrys | he's french what can you do. | 14:39.51 |
| ? | 14:39.55 |
kens | I've made no effort to work on it (no poitn really) just tried one quick run of current code, it didn't do what I expected, so I stopped | 14:41.05 |
henrys | oh damn now you have me curious - I was looking at a bike catalog ;-) | 14:41.52 |
kens | wwwwwwwbike catalog sounds more fun | 14:42.13 |
tor8 | Robin_Watts: I have a list of 35 potential sub-headers for fitz.h | 14:44.02 |
henrys | kens:fwiw you need -lRTL for plotter files otherwise you will get PJL | 14:44.49 |
tor8 | I could make more or fewer, a bit depeding on how tightly we want to group related things to gether | 14:44.52 |
| fz_path, fz_text, etc could all go into device.h along with the device functions | 14:45.11 |
| or live in their own header | 14:45.16 |
Robin_Watts | tor8: I'd favour separate headers, personally. I think. | 14:45.57 |
tor8 | buffer, compressed-buffer, stream, output as separate I think | 14:46.39 |
| -dashes or _underscores? | 14:46.53 |
Robin_Watts | _underscore | 14:47.09 |
| _ is an ISO 9660 char, - isn't. | 14:47.23 |
sebras | Robin_Watts: hm.. but using - means less shifting... | 14:47.23 |
paulgardiner | kens: TB much happier with newly sent HPGL message, thanks. | 14:48.30 |
kens | Ah OK good to know you got it | 14:48.39 |
sebras | Robin_Watts: oh, and isn't joliet more or less standard nowadays..? | 14:50.11 |
chrisl | kens: http://git.ghostscript.com/?p=user/chrisl/ghostpdl.git;a=commitdiff;h=bd08091d | 14:50.16 |
Robin_Watts | sebras: yes. The ISO 9660 objection is a historical one, really :) | 14:50.48 |
kens | chrisl so the problem is a 'broken' font ? | 14:50.51 |
chrisl | Well, it's a font that causes an error to occur during the attempt to write it out - baring in mind the fix I put in earlier for this file, broken font isn't surprising! | 14:51.52 |
kens | I have a feeling there are a number of errors with this (or a very simlar) cause | 14:52.13 |
chrisl | Yeh, but the combination of Ghostscript's filters implementation, and pdfwrite's own stream stuff made it a royal pain :-( | 14:53.14 |
kens | OK so if we get an error, rather than simply abort out, we flush the stream and 'end' the file ? | 14:53.15 |
| Oh, and stil return the error code, OK | 14:53.42 |
chrisl | Yes, exactly. That pops all the extra filters off the output file, and leaves everything the filter chain where it was to start with | 14:54.00 |
kens | Right. This is what I was saying before about the error handling in pdfwrite not really being up to this. I *very* strongly suspect there are a lot of places like this. | 14:54.29 |
| Anyway, the fix looks fine to me, thanks for doign that! | 14:54.42 |
tor8 | Robin_Watts: http://ghostscript.com/~tor/stuff/fitz_headers.txt | 14:54.57 |
| sebras: ^ | 14:55.01 |
chrisl | kens: Yep, there are plenty more in that function alone - but I'm pretending I didn't see them............ | 14:55.16 |
kens | chrisl I think those sorts of problems are scattered through the pdfwrite code :-( | 14:55.34 |
Robin_Watts | tor8: base => fitz ? | 14:55.34 |
tor8 | Robin_Watts: include/mupdf/fitz/base was my thought | 14:55.54 |
kens | I've tried to be careful to avoid these myself, but I've made no attempt to fix the existing ones (too big a job) | 14:55.57 |
tor8 | and include/mupdf/fitz/io/buffer.h | 14:56.09 |
| etc | 14:56.10 |
chrisl | kens: like I said in Miami, there's not point trying to track them all down, the best we can do is address them as we find them. | 14:56.13 |
sebras | tor8: Robin_Watts: actually when I grep in the result of find /usr/include I find more - in the names than _. | 14:56.29 |
tor8 | then we don't collide with include/mupdf/pdf/filter.h and include/mupdf/fitz/filter.h | 14:56.34 |
kens | Yeah, its just a shame there are so many points of failure. Oh well, please go ahead and commit it chrisl | 14:56.39 |
chrisl | kens: just running a clusterpush, will commit after that | 14:56.58 |
kens | would be highly surprised if the cluster showed any errors. | 14:57.19 |
chrisl | I know, but just to be safe - plus I can got make a cuppa! | 14:57.44 |
sebras | tor8: what would be the names of the collection headers? include/mupdf/base.h? | 14:58.13 |
tor8 | include/mupdf/fitz.h would include include/mupdf/fitz/base.h etc | 14:58.30 |
| and include/mupdf/fitz/base.h would include include/mupdf/fitz/base/*.h | 14:58.49 |
| might skip the intermediate ones though | 14:59.08 |
sebras | tor8: right. | 14:59.13 |
| tor8: do we want to keep annot or do we want annotation..? | 14:59.29 |
tor8 | sebras: good catch | 14:59.58 |
Robin_Watts | tor8:sorry, phone call. | 15:00.33 |
| I'm not sure I see the point of fitz/base/xxx.h Why not just fitz/xxx.h ? | 15:00.56 |
henrys | kens:I think there is confusion best sorted out by marcos, I get reasonable output and his tiff's look very similar to me, but neither have color. | 15:01.12 |
sebras | tor8: also write_document seems too long. why not just write..? | 15:01.13 |
Robin_Watts | From the point of view of a caller, what significance does the 'base' have ? | 15:01.15 |
| sebras: fz_write does something else. | 15:01.26 |
tor8 | too many header files, or dnoh.t | 15:01.32 |
| brb reboot, mac has iues wih usb agn | 15:01.44 |
Robin_Watts | dnoh.t ? | 15:01.45 |
| ok. | 15:01.51 |
sebras | Robin_Watts: something tells me tor8 will be annoyed once I get there tonight... ;) | 15:02.17 |
Robin_Watts | tor8: so, you were saying why "base" is important. | 15:04.33 |
tor8 | every couple of days my macosx 10.8 usb driver goes nuts and starts rate limiting my typing to approx 1 key per 2 seconds | 15:04.52 |
| so yes, were you objecting to just the base/ or also the io/ and resource/ subdirs? | 15:05.18 |
Robin_Watts | I really dislike base. and resource. | 15:06.18 |
| and path should not be in device. | 15:06.25 |
| I can live with device | 15:07.31 |
| why should any of the draw headers be exposed? | 15:07.43 |
tor8 | Robin_Watts: the draw headers should move into source/draw and be made internal to the draw device | 15:09.11 |
| but one step at a time | 15:09.13 |
Robin_Watts | This is the time to make that step. | 15:09.36 |
tor8 | what would you suggest for resource and base? just drop them all in one big mess at the top? | 15:09.38 |
Robin_Watts | because we might choose to put things in subdirs now, only to find that when we 'privatise' stuff, we're left with such a small set in a subdir that it makes it pointless. | 15:10.39 |
tor8 | path and text are only used in the device calls, hence my putting them there | 15:10.43 |
Robin_Watts | tor8: Shouldn't there be a 'search' thing somewhere? | 15:11.18 |
| text will be used by that too. | 15:11.26 |
tor8 | Robin_Watts: that's a different text, currently in output/text | 15:11.45 |
Robin_Watts | I think I'm broadly in favour of having everything in a big mess at the top :) | 15:11.55 |
sebras | tor8: hm.. what is a compress_buffer as opposed to a regular buffer? | 15:12.07 |
tor8 | a big mess at the top works for a first step | 15:12.07 |
| but it's not a good long term solution to have 50+ files in one directory | 15:12.28 |
| or maybe it is, I haven't tried that approach yet :) | 15:12.42 |
sebras | tor8: I would think that gs has proven that quite well, yes. | 15:12.50 |
tor8 | I prefer subdirs to prefixes | 15:13.12 |
Robin_Watts | sebras: A compressed buffer is what we use in fz_images | 15:13.14 |
| It's a buffer of data, plus details of the compression used on it. | 15:13.26 |
tor8 | prefixes + 8 char max file length + 1000+ files in one directory makes for gs pain | 15:13.30 |
Robin_Watts | so we can decompress it on demand. | 15:13.38 |
sebras | Robin_Watts: aha, ok. but is there reason enough to separate those from the regular ones? header-wise? | 15:13.49 |
Robin_Watts | There are only 37 headers in there, so far, and hopefully some of those will be privatised. | 15:14.02 |
| sebras: It's a different data type. | 15:14.11 |
tor8 | Robin_Watts: better names for text-used-in-device and text-extracted-from-page-used-in-search | 15:14.21 |
Robin_Watts | And it may be one we can hide. | 15:14.27 |
tor8 | pcl-output or output-pcl or just plain pcl? | 15:14.56 |
Robin_Watts | The 'out' dir was one I was happy with as a subdir. | 15:15.23 |
| That makes sense, because it groups a set of identical things. | 15:15.33 |
tor8 | I think both the io and output subdirs could stay | 15:15.40 |
Robin_Watts | device/{draw,path,text} makes sense too. | 15:15.50 |
| Sorry! | 15:16.00 |
| device/{draw,text} makes sense too. | 15:16.08 |
| less keen on the io one. | 15:16.31 |
tor8 | device/{device, display-list, draw, text}? | 15:16.49 |
Robin_Watts | Do we need a public device/device.h ? | 15:17.27 |
| I guess in case people define their own devices. | 15:17.36 |
| yeah, then like that. | 15:17.39 |
tor8 | I think we do. for people using it as a 'canvas' api | 15:17.50 |
Robin_Watts | but fz_path should be at the top level, IMHO. | 15:17.54 |
| tor8: OK. | 15:17.59 |
tor8 | fz_path and fz_text could live in device.h, IMO | 15:18.21 |
| or at the top | 15:18.26 |
Robin_Watts | Yes, they could live in device.h | 15:20.29 |
| or at the top. But not in device/ | 15:20.42 |
| Morning mvrhel_laptop | 15:20.56 |
| I haven't had a chance to look at that .xap yet, sorry. I did ask for a source pointer on their facebook page, but have had no response yet. | 15:21.19 |
| mvrhel_laptop, tor8: I did wonder about adding a bit of code into MuPDF to allow us to open PDF files that start with 'MuPDF' rather than "PDF". | 15:21.59 |
tor8 | Robin_Watts: drop the resource/ subdir as well then? | 15:22.14 |
Robin_Watts | I would personally. | 15:22.24 |
tor8 | just output, device and document for now? | 15:22.25 |
Robin_Watts | I dislike document too. | 15:22.40 |
tor8 | I rather like having document and resources separate | 15:22.59 |
Robin_Watts | I see the argument for using subdirs to say "here is a set of things that do the same kind of thing" | 15:23.03 |
| hence for devices, or outputs. | 15:23.10 |
tor8 | they're related but somewhat independent groups of things | 15:23.12 |
Robin_Watts | It seems arbitrary to me that a colorspace is a resource, where a path is not. | 15:23.37 |
| If we DO have a resource dir, then path should live in it. | 15:24.09 |
tor8 | fz_path and fz_text could live there as well, but in general the resources are things we stick in fz_store | 15:24.16 |
Robin_Watts | Then display_list shouldn't be in there. | 15:24.44 |
| If we say that resource contains 'reference counted resources; then display_list and path certainly belong there. | 15:25.41 |
| s/;/'/ | 15:25.47 |
tor8 | some things belong in potentially many places | 15:26.23 |
| like the display list | 15:26.27 |
Robin_Watts | I'd put the display list just in devices/list.h for now. | 15:27.08 |
tor8 | or different aspects of them in separate headers, but that's starting to get annoying | 15:27.36 |
Robin_Watts | cos no one will need it without devices/list.h at the moment - and if they ever do, we can split it out, and including devices/list.h will still be enough. | 15:27.41 |
| so actually, I've just argued myself into putting path.h into devices/device.h | 15:28.10 |
tor8 | the path stuff should be either in resource/path.h or device/device.h | 15:28.40 |
Robin_Watts | Splitting more in future can never hurt us. Splitting too early can (as we may split into the wrong place). | 15:28.41 |
| device/device.h I think. (Sorry, reversing my earlier dogmatism) | 15:29.00 |
tor8 | I'll err on the side of not splitting then :) | 15:29.28 |
mvrhel_laptop | good morning | 15:45.23 |
kens | chrisl I thiknk the other bug (6949a8) is a similar problem, the input is broken and even though Windows doesn't crash, it writes a not very good PDF file out. | 15:45.45 |
| Lots of bits missing | 15:45.52 |
chrisl | kens: there's a type in the bug number - but I can take a look at that one tomorrow, if you like | 15:47.57 |
kens | lol 694318 | 15:48.11 |
| again can't make it fail o Windows | 15:48.38 |
chrisl | I'll take a crack at it tomorrow - like I said, being familiar with the tools makes quite a difference | 15:49.16 |
kens | Well you got further than me *much* faster | 15:49.33 |
chrisl | But I can't face another bug like that today ;-) | 15:50.06 |
kens | I know the feeling | 15:50.12 |
chrisl | I also need to run an errand - bbiab........ | 15:51.01 |
kens | OK I've had more than enough today, I'm off for teh night... | 16:10.03 |
tor8 | Robin_Watts: argh! circular dependencies...! | 16:18.47 |
Robin_Watts | tor8: really? such as? | 16:19.40 |
tor8 | fz_document depends on fz_annot depends on fz_document... | 16:21.00 |
Robin_Watts | fz_annot is an opaque type, right? | 16:23.07 |
| So typedef struct fz_annot_s fz_annot; goes in document.h | 16:23.41 |
paulgardiner | I'd imagine we'll run into a lot of that if we make struct details visible in the public headers | 16:23.53 |
Robin_Watts | and annot.h #includes "fz_document.h" | 16:24.03 |
tor8 | yeah. I'm going to have to do a lot of shuffling of typedefs in the right order. | 16:24.04 |
Robin_Watts | document.h should never need to then include annot.h, right? | 16:24.27 |
tor8 | not this particuar instance | 16:24.44 |
| there's however the case of fz_font depending on both fz_device and fz_display_list | 16:25.09 |
| which I solved by using forward declarations of the opaque structs | 16:25.26 |
| but not the typedefs | 16:25.34 |
Robin_Watts | tor8: I don't follow that. | 16:34.39 |
| Can't we get font.h to include device.h and list.h and do the typedef struct fz_font_s fz_font; in device.h ? | 16:36.08 |
mvrhel_laptop | ugh. this is driving me bananas. so I need to make sure that the windows app can open files on microsofts skydrive. First time I try to open the file, it fails to even get the file name after the file picker and of course things explode. Second time it works just fine. It is like I am not waiting sufficiently for it to be locally downloaded but it is not clear in the documentation how... | 17:47.30 |
| ...to ensure this. it is just all supposed to work | 17:47.31 |
| ok got that working now | 18:30.35 |
| now I need to get the open with working | 18:31.04 |
ray_laptop | mvrhel_laptop: Are you here ? | 20:00.21 |
mvrhel_laptop | ray_laptop: I am. just about ready to go eat lunch. whats up? | 20:00.45 |
ray_laptop | mvrhel_laptop: cust 801's Autocolor Detection Problem #2 is something I need your advice on. It is because clist_begin_typed image treats all RGB images with MultipleDataSources as color | 20:01.38 |
| in non-clist mode it gets it right. | 20:01.54 |
mvrhel_laptop | MultipleDataSources. ick | 20:02.27 |
ray_laptop | /* Decide if we need to do any monitoring of the colors. Note that multiple source | 20:02.55 |
| (planes) is treated as color */ | 20:02.57 |
| pie->unpack = NULL; | 20:02.59 |
| if (dev_profile->pageneutralcolor && pie->color_space.icc_info.data_cs != gsGRAY | 20:03.00 |
| && (pie->num_planes == 1)) { | 20:03.02 |
| else we say the page is color | 20:03.22 |
mvrhel_laptop | hmm . is there a case in pdf where pie->num_planes != 1? | 20:03.56 |
| didnt you and I talk about this | 20:04.00 |
ray_laptop | mvrhel_laptop: we may have talked about this. In this case the file is PS | 20:04.19 |
mvrhel_laptop | ray_laptop: and if you remove the && (pie->num_planes == 1) | 20:04.53 |
| what happens | 20:04.56 |
| I am trying to remember if I coded this up so that multiple sources work anyway | 20:05.15 |
| need to look at code. let me get gs up | 20:05.28 |
ray_laptop | mvrhel_laptop: I suspect that it will get confused, but I will look into it. | 20:05.34 |
| mvrhel_laptop: it works OK in non-clist mode. | 20:05.50 |
| but I don't want to force it to non-HL image mode (rectangles) for this case. But that would be a quick (and dirty) fix. | 20:06.42 |
mvrhel_laptop | so the fix if one is needed will be in cmd_image_plane_data_mon | 20:06.59 |
ray_laptop | mvrhel_laptop: let me trace what happens treating num_planes > 1 the same. | 20:07.19 |
mvrhel_laptop | the call of row_has_color | 20:07.19 |
| aound line 2204 | 20:07.39 |
| so you may have to collect the plane data | 20:07.54 |
ray_laptop | mvrhel_laptop: I'd have to keep one row to compare against. | 20:08.12 |
mvrhel_laptop | or have a special (and costly new cmd_image_plane_data_multiple_sources_mon function) | 20:08.31 |
ray_laptop | since all 3 (or 4) rows have to match up in order to be mono | 20:08.39 |
mvrhel_laptop | that would probably be the way that I would go | 20:08.51 |
ray_laptop | the costly new function ? | 20:09.04 |
mvrhel_laptop | is to have a replacement for cmd_image_plane_data_mon | 20:09.10 |
| when num_planes > 1 | 20:09.20 |
| which was a replacement for cmd_image_plane_data | 20:09.47 |
ray_laptop | mvrhel_laptop: OK. Let me dig into it and see | 20:09.49 |
mvrhel_laptop | ok. i am going to grab a bit to eat. | 20:09.58 |
ray_laptop | mvrhel_laptop: OK. buen provecho | 20:10.16 |
mvrhel_laptop | then I need to go and get a couple things at store. today is my daughters birthday | 20:10.17 |
ray_laptop | mvrhel_laptop: I'll run it by you when I have something, or will contact you if I hit a wall, but I should be able to handle it. Thanks for the chat | 20:11.00 |
| Forward 1 day (to 2013/06/18)>>> | |