| | <<<Back 1 day (to 2013/05/20) | 2013/05/21 |
| vtorri_ | why isn't fz_authenticate_password() taking a const char * as password ? | 03:50.59 |
| test_ | helo | 05:02.33 |
| sebras | vtorri: likely because we until recently tried to avoid const. | 06:37.22 |
| vtorri_ | sebras, ok | 08:46.23 |
| sebras | vtorri_: I wouldn't be surprised if we were to change this in the near future now that we use const more. | 08:47.04 |
| vtorri_ | :) | 08:47.18 |
| | they could warn about possible bugs | 08:47.34 |
| sebras | vtorri_: yes, but they spread like wildfire, which is why I truely detest const. I recognize that they make sense in library interfaces, like mupdf's. | 08:50.52 |
| paulgardiner | sebras: I remember a project where, because of warnings being reported as errors, I had to define a union containing a char * and a const char * field so as to trick the compiler into allowing me to convert the const away | 09:02.14 |
| sebras | paulgardiner: ugh. | 09:04.11 |
| tor8 | paulgardiner: ick1 | 09:04.16 |
| vtorri_ | i'm almost sure that there is a gcc option which disable such warning | 09:04.30 |
| | better that than your trick | 09:04.42 |
| tor8 | paulgardiner: and on icky notes, how is the easiest way to test signing stuff in pdf on your branch? | 09:04.45 |
| | I've got an openssl library build here, but want to see if it actually works and also how much I can slim down the build | 09:05.08 |
| paulgardiner | Changing gcc options wasn't permitted for that project. | 09:05.46 |
| | tor8: I have 4 files I can send you. One is signed with an Adobe certified certificate. The others are 3 states of a file I've signed, the states being unsigned, signed, and post-signing altered. | 09:07.21 |
| tor8 | paulgardiner: that would be great if you could. email or upload to casper? | 09:08.52 |
| paulgardiner | will do | 09:09.06 |
| Robin_Watts | Add them to the svn test repo ? | 09:09.20 |
| paulgardiner | yeah. would make sense | 09:09.58 |
| Robin_Watts | : despairs of potential customer. | 09:14.10 |
| | "Your code leaks", "So it does, here is a fixed version." | 09:14.30 |
| | "Your code still leaks", "Where, I cannot reproduce a leak any more, can you show me how it leaks or provide evidence?" | 09:15.13 |
| | "Your code still leaks. Here is a memory dump." | 09:15.27 |
| | "That memory dump doesn't show any leakage. Why do you think it leaks?" | 09:15.52 |
| | "Your code or our code still leaks. Fix it!" | 09:16.08 |
| paulgardiner | tor8: SignatureTestFiles.zip is now in my home directory on casper. | 09:16.09 |
| Robin_Watts | "I cannot find any leaks in our code. Please can you tell me how to reproduce such a leak? Why do you think it leaks?" | 09:17.06 |
| tor8 | EET LEEEEEKS!!! | 09:17.23 |
| Robin_Watts | "Code leaks! You have all our code, please fix our code!" | 09:17.36 |
| | "We can't proceed any further without you having at least a customer agreement!" | 09:17.53 |
| kens | Oh yeah, been there.... | 09:17.54 |
| Robin_Watts | "I don't accept this! You must fix your code!" | 09:18.03 |
| kens | Robin_Watts : can I interrupt a moment ? | 09:18.20 |
| Robin_Watts | kens: I've ranted myself out now. go for it. | 09:18.30 |
| kens | I have a vague (and as normal unreliable) meory that you added somethign to paramtere parsing to check for unparsedparameters ? | 09:19.03 |
| Robin_Watts | I thought about it, and we discussed it. I don't think anything was actually coded. | 09:19.31 |
| kens | Oh, then I'm wrong. | 09:19.38 |
| Robin_Watts | though my memory is notoriously poor. | 09:19.38 |
| kens | There is something in there which raises an undefined error if any member of a parmatger list is not parsed | 09:19.58 |
| Robin_Watts | git blame ? | 09:20.20 |
| | Can you point me at some code? | 09:20.34 |
| kens | Well, I was kind of wondering if you knew how I could find out what the parameter item was, one moment | 09:20.45 |
| sairam | hey | 09:21.37 |
| ghostbot | que tal | 09:21.37 |
| kens | Grr ran right past it, one more moment | 09:22.03 |
| sairam | i have a qurey regarding Mu pdf, can you help me out? | 09:23.04 |
| kens | Robin_Watts : iparam.c, ref_param_read_commit() at around line 839 | 09:23.09 |
| | " /* Check to make sure that all parameters were actually read. */" | 09:23.28 |
| | NB this is not the same as setting teh parameters on the command line, this is the result of putdeviceparams | 09:24.04 |
| Robin_Watts | That code dates from 1998, so it ain't my fault. Phew. | 09:25.11 |
| kens | :-) | 09:25.15 |
| | Well, I guess its back to plodding my way through trying to figure it out :-( | 09:25.40 |
| tor8 | sairam: ask, instead of asking to ask. | 09:25.50 |
| kens | is lost in a maze of twisty macros again | 09:26.04 |
| tor8 | (bah, too late) | 09:26.11 |
| kens | Hmm, waited less than 2 minutes, not a lot of patience there | 09:26.33 |
| Robin_Watts | kens: yeah, sorry I have no clue how this code works. | 09:27.37 |
| kens | NP | 09:27.41 |
| paulgardiner | What sort of brokenness does pdf_repair_xref repair? | 09:45.41 |
| | ... where "brokenness of the xref" is not really the answer I'm looking for. :-) | 09:46.14 |
| tor8 | paulgardiner: pdf_repair_xref rebuilds a new xref from scratch by parsing the entire file | 09:47.34 |
| | it's triggered off of any number of potential errors in normal xref loading. basically, if we throw an exception in the xref loading, we fall back to that function | 09:48.10 |
| paulgardiner | I see. So that process would have to produce an xref as a single section? | 09:49.16 |
| Robin_Watts | paulgardiner: essentially, yes. | 09:49.55 |
| paulgardiner | That's good. Means I don't have to worry about understanding that bit for the sake of keeping the sections separate. | 09:50.45 |
| Robin_Watts | If we have to repair, then all bets are off about digital signatures etc anyway. | 09:51.43 |
| paulgardiner | Yes true. | 09:51.58 |
| Robin_Watts | tor8: 3 reviews on robin/master for you. | 09:55.26 |
| tor8 | Robin_Watts: the getopt handling for colorspace and alpha is order dependent | 10:04.09 |
| | I'd rather drop the -a flag for clarity | 10:04.52 |
| | the -g can be a shortcut for "-c gray" | 10:05.05 |
| Robin_Watts | tor8: I'm happy to drop -a if we have to. | 10:05.42 |
| tor8 | and we could put the list of allowed colorspaces in the format table | 10:05.48 |
| | instead of the switch | 10:05.54 |
| Robin_Watts | format table ? | 10:06.10 |
| tor8 | a format table, then | 10:06.46 |
| | similar to the suffix_table | 10:06.52 |
| Robin_Watts | They are. | 10:06.58 |
| | cs_name_table, at the top | 10:07.12 |
| tor8 | I mean extend the suffix_table with an "int allowed_cs[6];" array | 10:08.10 |
| | so we have both default and list of supported colorspaces per format in the data table | 10:08.25 |
| Robin_Watts | oh, I see. | 10:08.45 |
| | I'd rather have a separate table, I think, in case we ever have output formats that can have several suffixes. | 10:09.38 |
| tor8 | the pwg_options struct, is that a binary blob that you need to copy around from some pipeline? | 10:09.39 |
| | Robin_Watts: fair enough. | 10:09.51 |
| Robin_Watts | tor8: It is not a binary blob, deliberately. | 10:10.05 |
| tor8 | but it should be tables at least, not a set of switches | 10:10.08 |
| | I don't see any code using the struct | 10:10.19 |
| Robin_Watts | tor8: The code to write the header uses the struct. | 10:10.33 |
| | There is no code to fill the struct currently. | 10:10.43 |
| tor8 | right. | 10:10.48 |
| Robin_Watts | but any mupdftoraster we do would need it. | 10:10.56 |
| tor8 | if it's not a binary blob, why the [u]int32_t types? | 10:11.04 |
| Robin_Watts | tor8: because the range/values of the types are defined in the spec to be those types. | 10:12.17 |
| tor8 | if we're to start using those types, the tiff and png code ought to have them too | 10:12.49 |
| Robin_Watts | tor8: you'd rather they were just int and unsigned int ? | 10:13.08 |
| tor8 | and then we're not far off from using size_t and off_t as well ;) | 10:13.15 |
| | if I wrote the code, that's what I'd have done | 10:13.24 |
| | (int and unsigned int, no explicit bit size) | 10:13.35 |
| Robin_Watts | The values are defined in the spec to have a specific bit size. | 10:13.54 |
| | hence I followed that. | 10:13.59 |
| tor8 | but that's just my preference for less visual clutter | 10:14.00 |
| Robin_Watts | I find uint32_t much nicer than "unsigned int" :) | 10:14.14 |
| | less cluttered. | 10:14.20 |
| tor8 | eww | 10:14.22 |
| | digits and underscores and pointless suffix | 10:14.33 |
| | visual noise | 10:14.48 |
| | (and it fails the read it out loud test) | 10:15.18 |
| | paulgardiner: conservatively, we need at 405 of the 583 openssl source files | 11:04.43 |
| | just by going from the link map to pull in just the object files that are used | 11:04.57 |
| paulgardiner | Maybe not surprising. PKCS7 involves a combination of all sorts of standards. | 11:10.26 |
| tor8 | it pulls in most of the asn.1, x509, and evp files which make up the bulk of files | 11:11.08 |
| | but there's also pkcs12 and a host of other files which probably shouldn't be there | 11:12.02 |
| | shouldn't need to be there | 11:12.09 |
| | OpenSSL_add_all_algorithms() maybe that one is the culprit? | 11:13.18 |
| paulgardiner | Yes, that might well be pulling in stuff we don't need. | 11:14.20 |
| tor8 | ugh. the stripped static library is still 1.8M large :( | 11:27.01 |
| | without that call, I can get it down to 330 files, but then nothing works :) | 11:29.20 |
| paulgardiner | tor8: :-) | 11:30.42 |
| tor8 | paulgardiner: I'm inclined to go #ifdef HAVE_OPENSSL here and just use the system library if it's available, and stub to no-ops if it isn't | 11:36.38 |
| | paulgardiner: would it be possible to use the command line tools to do the error checking by pipe/fork/exec? | 11:37.17 |
| | or does the way you have to use the BIO functions make that impossible | 11:37.46 |
| | I guess that's for discussing on tonight's meeting | 11:39.08 |
| paulgardiner | We'd need to write two temp files one with the pkcs7 certificate and another with the concatenated parts of the file that are included in the digest | 11:40.00 |
| tor8 | executing external commands is a portability nightmare in and of itself, so scratch that thought | 11:41.49 |
| Robin_Watts | tor8: Revised patch online. | 11:49.30 |
| | tor8: Do we assume that int's are at least 32bit elsewhere in the mupdf code? I guess we do. | 12:10.18 |
| | I can change the int32_t's/uint32_t's to ints and unsigned ints if you'd prefer. | 12:10.38 |
| tor8 | Robin_Watts: yes, we do. | 12:10.44 |
| | 16-bit ints are long dead and buried | 12:10.56 |
| Robin_Watts | tor8: New patches online then. | 12:15.20 |
| tor8 | move default_cs into fromat_cs_table? | 12:16.42 |
| Robin_Watts | I prefer it where it is. | 12:17.29 |
| | cos we're looking in the suffix table when we need it. | 12:18.32 |
| | I'd have to do a different lookup. | 12:18.40 |
| tor8 | you start with cs set to CS_UNSET | 12:19.01 |
| Robin_Watts | I do. | 12:19.08 |
| tor8 | so you'd just need to test if cs is unset when checking the permitted colorspaces | 12:19.26 |
| Robin_Watts | ok. | 12:20.05 |
| tor8 | wouldn't that be better? | 12:20.23 |
| Robin_Watts | tor8: I prefer the other way, but not strongly enough to have a fight about it. | 12:25.30 |
| | new patch online. | 12:25.37 |
| tor8 | Robin_Watts: fab. those three are good to go. | 12:26.54 |
| Robin_Watts | ta. | 12:26.58 |
| tor8 | there's a simple fix sitting on tor/master that wants in as well | 12:27.15 |
| Robin_Watts | tor8 speeks weegie! | 12:27.51 |
| | ok, looks good. will push tat. | 12:28.46 |
| | that | 12:28.48 |
| tor8 | Robin_Watts: "weegie"? | 12:30.22 |
| Robin_Watts | Glaswegian. | 12:31.01 |
| | "Wants in" is a particular form of speech that's common in Glaswegian, as is "Needs fixed". | 12:31.30 |
| tor8 | I've never been near the place! but I guess I've been contaminated by their linguistic influence anyway... | 12:32.19 |
| Robin_Watts | I'm now having a crisis of confidence over this - I've heard "wants in" in common usage, but I *think* it comes from there... | 12:34.05 |
| paulgardiner | I've heard "wants in" in common usage too, but had never noticed that it's the same structure as Needs fixed. | 12:35.23 |
| | Is it a form of "wants entry" and "needs fixing" or is it a shortening of "wants to be in" and "needs to be fixed"? | 12:36.26 |
| tor8 | it's a turn of words I've used in swedish too. it is grammatically sound (though anthropomorphising) unlike "needs fixed" | 12:36.27 |
| Robin_Watts | "wants in" == "wants to go/be in" | 12:37.50 |
| | "needs fixed" == "needs to be fixed" | 12:38.03 |
| | hence me thinking the two are similar usage. | 12:38.15 |
| tor8 | hm, point you have | 12:38.20 |
| vtorri_ | FZ_META_FORMAT_INFO allows to retrieve the PDF version of the PDF doc. With XPS, only "XPS" is returned. Is it normal that there is no version ? | 12:54.10 |
| Robin_Watts | vtorri_: Yes. | 12:56.38 |
| vtorri_ | Robin_Watts: same for comic book i guess (not tried yet) | 12:57.23 |
| Robin_Watts | probably | 12:58.40 |
| | tor8: Patch on robin/master to add 1bpp PWG output. | 13:15.26 |
| tor8 | Robin_Watts: looks like you pushed the foreach text macros | 13:16.11 |
| Robin_Watts | tor8: oh, balls, probably. | 13:17.54 |
| tor8 | I'm thinking we need to get a story together regarding multi-page output and multi-page devices | 13:18.09 |
| | Robin_Watts: have you reviewed it? :) | 13:18.20 |
| | (the foreach macros) | 13:18.27 |
| Robin_Watts | vaguely :) | 13:18.32 |
| | I distrust such macroisation in general. | 13:18.48 |
| tor8 | I'm not convinced they're a good idea, but it might help if we do more churn on the text structures | 13:18.54 |
| Robin_Watts | I can revert them, or rebase/force push, or we can leave them there. Your call. | 13:19.51 |
| tor8 | I'd rebase/force push | 13:20.35 |
| Robin_Watts | ok. | 13:20.42 |
| tor8 | given they've been live only 5 minutes | 13:20.45 |
| Robin_Watts | They've been there longer than that, but OK. | 13:21.02 |
| tor8 | hmm. well. maybe just revert thenL | 13:21.12 |
| | ? | 13:21.13 |
| | I want to spend some more time to rework the text api:s before the next release | 13:21.33 |
| Robin_Watts | rebased/force pushed. | 13:21.50 |
| tor8 | monochrome looks good, but I see you already pushed :) | 13:25.11 |
| Robin_Watts | tor8: Sorry, yes, I did push that. | 14:19.17 |
| vtorri_ | poppler has an API to know "whether the document is linearized" | 14:33.49 |
| | what is it ? | 14:33.54 |
| | i don't find it in mupdf | 14:34.01 |
| Robin_Watts | vtorri_: Indeed. | 14:40.04 |
| | We don't make use of linearised information yet, hence we don't detect it. | 14:40.20 |
| vtorri_ | ok | 14:40.29 |
| | and what is the status of forms and annotations in mupdf ? | 14:41.32 |
| henrys | Robin_Watts:do we have an svgwrite mupdf feature enhancement bug? | 14:44.51 |
| | report | 14:45.00 |
| Robin_Watts | I don't think so. | 14:45.18 |
| henrys | I'll make one. | 14:46.28 |
| vtorri_ | svg ?? | 14:46.29 |
| Robin_Watts | vtorri: Yes. We have prototype code for outputting SVG from mupdf | 14:47.13 |
| | vtorri_: Preliminary support for forms and annotations is in. | 14:47.48 |
| | annotations is still a way off being entirely complete, but forms is nearly there. I think that's fair, paulgardiner ? | 14:48.26 |
| paulgardiner | Yes. I'd agree with that. | 14:48.54 |
| vtorri_ | ok | 14:49.07 |
| | and outputting postscript ? | 14:49.36 |
| | btw, the wikipedia page of mupdf does not mention CBZ support | 14:50.22 |
| Robin_Watts | vtorri_: Nope. We can't output postscript really. | 14:50.23 |
| | vtorri_: postscript can't support transparency, so... | 14:50.47 |
| | vtorri_: Neither does it mention JPEG/PNG or TIFF support either I'd imagine. | 14:51.11 |
| henrys | Robin_Watts:If you have code ready to be tested add the git info to the bug I just made. | 14:51.39 |
| vtorri_ | indeed | 14:51.43 |
| sebras | vtorri_: also it is bad form to edit one's own wikipedia page. | 14:53.02 |
| Robin_Watts | henrys: added. | 14:53.53 |
| henrys | 5 of the meeting | 14:55.27 |
| | paulgardiner: status report is useful to me but I feel like your being "singled out" so we can make it optional for you. I can certainly read commit logs and such. | 14:59.59 |
| | s/your/you're | 15:00.12 |
| | english | 15:00.16 |
| mvrhel_laptop | good morning | 15:01.12 |
| henrys | but speaking of the status report I thought we already had some pieces of incremental update working for some other thing, I guess I'm mistaken. | 15:01.15 |
| | hi mvrhel_laptop | 15:01.34 |
| | incremental update - last paragraph of paulgardiner's status report. | 15:02.14 |
| Robin_Watts | henrys: We have been able to update pdf objects within the memory structure, but we've never had it so that when we write the file out again we get the same xref structure as before. | 15:02.23 |
| paulgardiner | henrys: I have refered to something as "partial update" before. Could that be what you are thinking of? | 15:02.36 |
| henrys | yes that is what I'm thinking of. | 15:02.55 |
| Robin_Watts | That was "partial update" of the screen - when a form field changes, redraw just that bit of the screen, not the whole page, AIUI. | 15:03.26 |
| paulgardiner | Possibly I have confused the two terms before, which wont have helped. | 15:04.13 |
| | I'm running into a few problems with incremental update, where I could do with some advice. | 15:05.04 |
| tor8 | before pdf 1.5 was released with compressed object streams, we supported incremental updates (basically appending new objects and a new xref to an existing pdf when saving) | 15:05.20 |
| | paulgardiner: I have a few questions for you then | 15:05.41 |
| vtorri_ | tiff support is for mupdf > 1.2, right ? | 15:05.44 |
| tor8 | do we need to preserve the original xref link chain when reading a file? | 15:05.59 |
| Robin_Watts | vtorri_: tiff input is post 1.2, yes. | 15:06.02 |
| paulgardiner | tor8: Really! I didn't know that. | 15:06.03 |
| Robin_Watts | paulgardiner: me either. | 15:06.28 |
| tor8 | I did it back then by just keeping a dirty flag in the xref, and when saving in incremental mode I'd make a new xref section containing only the diffs and a trailer pointing to the previous xref | 15:07.04 |
| paulgardiner | tor8: I don't think we need to for the sake of writing out changes, but we need it so as to be able to test whether changes during last signing are ones that are allowed. | 15:07.10 |
| henrys | tor8:but you guys have pdf writing - well linearized pdf writing was marked complete some time ago so you can't just write the whole works back to a file? | 15:07.18 |
| Robin_Watts | For PDF writing, we construct the file structure from scratch, currently. | 15:07.49 |
| tor8 | so I think "have history of all revisions" and "saving an incremental update" are separate issues | 15:07.53 |
| paulgardiner | tor8: yes | 15:08.04 |
| Robin_Watts | So everything goes into a single xref. | 15:08.07 |
| paulgardiner | tor8: but both issues are relevent to signatures | 15:08.31 |
| | henrys: writing out the whole file is fine if the file isn't alrady signed, but if it is the process invalidates the signature | 15:09.22 |
| henrys | ah of course | 15:09.30 |
| tor8 | paulgardiner: Robin_Watts: d219624c5cfb98556c71cf71d6eed6727846badc is the commit that rips out the (at the time starting to bit rot) code to write out pdf files | 15:09.35 |
| Robin_Watts | paulgardiner: So, to check my understanding here... suppose we have a file that has 3 xrefs in. The first xref can be signed by one person, the second one might have someone elses signature on it, and the third might have someone elses. | 15:09.38 |
| henrys | you can even have different signatures for different parts of the document that have to be maintained. | 15:10.00 |
| paulgardiner | Robin_Watts: yes could be | 15:10.20 |
| tor8 | pdf_updatexref is the function that did the incremental update saving | 15:10.30 |
| Robin_Watts | paulgardiner: In order to write out the signatures unchanged in an updated file, you'll need to be able to write EXACTLY the same sequence of bytes all the way up to the end of the existing. | 15:10.58 |
| | file. | 15:10.59 |
| paulgardiner | No one can add a signature to an already signed document without using the incremental update mechanism | 15:11.03 |
| tor8 | incremental updates should open the file in append mode | 15:11.37 |
| paulgardiner | Robin_Watts: I was assuming we'd byte-wise copy the existing file and then append to it | 15:11.41 |
| | tor8: or that | 15:11.49 |
| tor8 | or actually, make a copy of the original file and then append data to it, so as not to clobber a file if something goes wrong | 15:11.55 |
| Robin_Watts | So it's not just a question of keeping the xrefs separate in memory. | 15:11.57 |
| paulgardiner | .. if we think it's safe | 15:12.01 |
| Robin_Watts | right, that makes sense. | 15:12.13 |
| | As long as you weren't hoping to avoid that byte copy thing, I'm in agreement. | 15:12.35 |
| paulgardiner | Keeping the xrefs separate in memory isn't actually necessary for incremental update, as tor8 just pointed out. | 15:12.40 |
| | Keeping the xrefs separate is needed so as to be able to compare different versions of the same file, and see whether anything has changed that shouldn't have | 15:13.17 |
| Robin_Watts | right. | 15:13.30 |
| | I can't see that it's a huge change to the way we work to keep a list of xrefs. | 15:13.53 |
| paulgardiner | But I'm imagining that the solutions to both problems will be connected | 15:14.05 |
| tor8 | Robin_Watts: the xref loading code needs a fair bit of juggling around to make that work | 15:14.17 |
| Robin_Watts | a few places where we resolve references, will have to follow the chain of xrefs back (possibly just one) | 15:14.24 |
| tor8 | but the rest of the code should be fairly unaffected | 15:14.31 |
| paulgardiner | Robin_Watts: I started on that, but it changes the code in a huge number of places, and I'm wondering whether, given that, I should encapsulate the xref as a seperate module. | 15:15.04 |
| tor8 | the question is how to do edits to the xref. make new xref sections to hold the updates? | 15:15.05 |
| paulgardiner | We mess with doc->table and doc->len all over the place | 15:15.29 |
| tor8 | paulgardiner: almost all of object accesses go through a handful of functions, but I can agree that the xref loading and repair code could do with some refactoring | 15:16.00 |
| | it's been mostly stable for a long time | 15:16.12 |
| Robin_Watts | paulgardiner: Improved encapsulation is always good, as long as it's doesn't slow anything critical down. | 15:16.53 |
| paulgardiner | pdfshow.c pdfposter.c pdfinfo.c pdfclean.c ... and more all refer directly to table and len | 15:17.24 |
| Robin_Watts | tor8: presumably we can have a flag on each xref as to whether it's 'frozen' or not. | 15:17.30 |
| | If we make a change and the topmost xref is frozen, we make a new 'unfrozen' one on the top of the stack. | 15:18.09 |
| | and changes go in there. | 15:18.15 |
| paulgardiner | I was thinking that on first document change, we spawn another level of xref section in memory | 15:18.23 |
| | What Robin_Watts said :-) | 15:18.37 |
| tor8 | yeah. then we definitely need some low level xref accessor functions to hide the icky details | 15:19.03 |
| Robin_Watts | you were pithier. | 15:19.03 |
| paulgardiner | tor8: quite | 15:19.12 |
| tor8 | pdf_count_objects already exists :) | 15:19.20 |
| paulgardiner | Robin_Watts: :-) | 15:19.23 |
| Robin_Watts | I have a branch here that adds progressive loading. | 15:19.48 |
| | I had a quick look at it the other day to see if I'd made any changes to the xref stuff because of that, and couldn't see anything huge. | 15:20.17 |
| vtorri_ | in mupdf 1.2, i think i've found a bug in the doc of fz_link_dest_s : | 15:20.54 |
| | "of gotor.lr and gotor.rb" | 15:20.58 |
| paulgardiner | There is possibly another approach to this with less change: | 15:21.09 |
| vtorri_ | i think it's lt and not lr | 15:21.09 |
| henrys | since the meeting is coming up and miles will ask I wanted to check in about milestone 3 and 5 - did we want to wait for customer demand for those or are they in progress? | 15:21.14 |
| Robin_Watts | looks up what they are again. | 15:21.30 |
| henrys | Milestone 3: Add RTL reordering pass to text extraction for copy/paste, search and reflow | 15:21.40 |
| paulgardiner | we could keep the exiting table and len, but also have a secondary copy of the xref with split sections. | 15:21.43 |
| henrys | Milestone 5: Simple Marked region analysis and plumbing to send images through to the created html. | 15:21.53 |
| paulgardiner | That would require less change. | 15:21.59 |
| tor8 | henrys: milestone 3 is done (but there seems to have been a few bugs introduced in the apps that we need to track down due to the current text api upheavals) | 15:22.14 |
| henrys | tor8:okay new features have bugs got it. | 15:22.49 |
| Robin_Watts | Milestone 5: We have simple marked region analysis. And we have plumbing to send images through to the created html. | 15:22.51 |
| | I wouldn't claim it's complete, but we have a first cut. | 15:23.09 |
| henrys | so the whole business is done. | 15:23.21 |
| Robin_Watts | So "waiting for customer demand" sounds great to me. | 15:23.23 |
| henrys | I'll make that so. | 15:23.51 |
| Robin_Watts | We should try to make sure that we have the android app searching/annotating properly before next week though. | 15:24.13 |
| | i.e. in time to get fixed builds up onto google play for the show. | 15:24.34 |
| paulgardiner | Robin_Watts: I didn't know it was broken. | 15:25.07 |
| henrys | I was just going to ask when all of this will be on google play. | 15:25.09 |
| paulgardiner | Robin_Watts: is that because of the text bugs tor8 mentioned? | 15:25.38 |
| Robin_Watts | paulgardiner: yeah. | 15:25.44 |
| henrys | mvrhel_laptop: 5 more minutes anything on the viewer? | 15:25.45 |
| tor8 | bugs 694077 and 694081 need to be fixed first | 15:25.47 |
| henrys | we also needed the list of third party apps, did chrisl end up with that? | 15:26.31 |
| tor8 | bug 693944 might be related but needs investigation | 15:26.36 |
| mvrhel_laptop | henrys: just one question. so after I push up my changes to my repos on casper, do I just alert tor8 and then he will move them to golden if all is fine? | 15:26.38 |
| | I pushed up one this morning that added the password support | 15:26.51 |
| | I just need to fix one orientation bug, add in the state saving and I think that is it | 15:27.10 |
| Robin_Watts | mvrhel_laptop: You alert either tor8 or me, I guess. | 15:27.29 |
| mvrhel_laptop | Robin_Watts: ok consider yourself alerted.... | 15:27.47 |
| henrys | anything else for the meeting? | 15:28.25 |
| Robin_Watts | The "rule" is that all commits get reviewed by one other developer. paulgardiner has reviewed in the past, but he can't push to the main repo, AIUI. | 15:28.27 |
| henrys | why not? | 15:28.47 |
| Robin_Watts | henrys: permission issue, I think? Maybe it's been sorted. | 15:28.59 |
| mvrhel_laptop | Robin_Watts: ok sounds reasonable (about the review by one other) | 15:29.16 |
| tor8 | and significant changes to how any core library stuff works should preferably be reviewed by more eyes | 15:29.55 |
| mvrhel_laptop | right | 15:30.03 |
| tor8 | public API changes etc | 15:30.05 |
| paulgardiner | henrys: concerning the reports, maybe play it by ear. I do sometimes think I'm listing every detail rather than things people need to know. | 15:30.10 |
| tor8 | since often they have ripple on effects that all of us may not notice at first | 15:30.34 |
| | we've all been guilty of that in the past... | 15:30.50 |
| | I'm usually guilty of breaking the android build or forgetting to update the win32 project files... | 15:31.27 |
| Robin_Watts | Thank god no one cares about breaking the ios build :) | 15:31.52 |
| tor8 | indeed! let it rot! | 15:32.00 |
| henrys | paulgardiner:completely up to you on the status report. | 15:32.05 |
| vtorri_ | tor8, add a document for the release manager | 15:32.06 |
| | a list of stuff to do | 15:32.13 |
| paulgardiner | henrys: great | 15:32.14 |
| tor8 | actually, the ios app has user reviews begging for printing support | 15:32.26 |
| | people want to print their XPS files apparently! | 15:32.40 |
| henrys | what are you talking about our best customer for mupdf uses iOS? | 15:32.49 |
| Robin_Watts | henrys: but they use their own app. | 15:33.03 |
| tor8 | henrys: they don't use our app | 15:33.04 |
| henrys | also with reflow we could make pdf inroads on iPhone and iPad - preview doesn't' have it. | 15:33.42 |
| Robin_Watts | tor8: That customer has been talking to me about printing from their app. | 15:33.50 |
| henrys | nobody uses our app, what does that have to do with anything? | 15:34.12 |
| Robin_Watts | Their plan is to save single pages out of their (protected) PDFs and send them. | 15:34.17 |
| | henrys: When we add new files etc, we forget to add them to the ios project file. | 15:34.48 |
| henrys | the app is a reference point and a sales tool. | 15:34.59 |
| Robin_Watts | Right, so we make the ios app build for each release we do. | 15:35.16 |
| henrys | okay that's fine, let it rot didn't sound like that. | 15:35.42 |
| Robin_Watts | well, when I say we, I obviously mean tor :) | 15:36.10 |
| paulgardiner | Sometimes I'm tempted to have a hack at the iOS app, but I fear it would eat too much time | 15:36.20 |
| tor8 | paulgardiner: please do! if it means I don't have to :) | 15:37.07 |
| | we're over time, but I did want to talk about our options for openssl | 15:37.41 |
| henrys | it's much more entertaining to have tor8 responsible for it. | 15:37.41 |
| Robin_Watts | mvrhel_laptop: tab vs spaces in your commit. | 15:37.46 |
| mvrhel_laptop | rats | 15:37.50 |
| Robin_Watts | mvrhel_laptop: I can fix if you want. | 15:37.58 |
| mvrhel_laptop | Robin_Watts: please and thank you | 15:38.05 |
| Robin_Watts | tor8: Go for it, we're all back here in 23 mins anyway, right? | 15:38.22 |
| henrys | tor8:oh right this openssl kitchen sink sounds awful. | 15:38.25 |
| mvrhel_laptop | tor8: so for the tabs/space thing, I can set up git so take care of it for me correct? | 15:38.54 |
| tor8 | henrys: yeah. it's HUGE. takes twice as long to compile just openssl as mupdf and all third party libraries combined | 15:38.58 |
| Robin_Watts | Do they have some cunning scheme whereby the algorithms used can be selected by options at runtime etc or something? | 15:39.26 |
| tor8 | mvrhel_laptop: there are options, yes. one way is to set up git to disallow committing changes that have whitespace errors. | 15:39.27 |
| mvrhel_laptop | hmmm. I think what I need to do is get VS set up differently for the mupdf project vs. the gs project | 15:39.53 |
| tor8 | Robin_Watts: yeah. you register functions in some lookup table at start (the OpenSSL_add_all_algorithms call) | 15:40.00 |
| henrys | I frequently ask myself how anyone could be so stupid not to split that up into manageable smaller libraries than I look at gs and think oh that's how ;-) | 15:40.07 |
| Robin_Watts | mvrhel_laptop: If you figure out how, please let me know :) | 15:40.08 |
| mvrhel_laptop | I have VS set up to put spaces every time I hit a tab | 15:40.20 |
| Robin_Watts | mvrhel_laptop: I have to change VS manually between gs and mupdf. | 15:40.41 |
| mvrhel_laptop | that wont work for me. I will never remember | 15:41.02 |
| Robin_Watts | Maybe in versions > 2005 that can be done on a per-project basis. | 15:41.03 |
| tor8 | slimming down the build to the bare minimum used cuts down 180 files, but still leaves 400 files to build | 15:41.17 |
| Robin_Watts | mvrhel_laptop: I "git diff" before I commit, and it shows spaces as red. | 15:41.31 |
| tor8 | and the resulting binary is nearly 2MB code size | 15:41.32 |
| | s/binary/library/ | 15:41.40 |
| paulgardiner | tor8: that's not huge compared with v8 though, is it? | 15:42.01 |
| mvrhel_laptop | Robin_Watts: ok that is an idea | 15:42.01 |
| tor8 | paulgardiner: v8 is a monstrosity! | 15:42.16 |
| vtorri_ | :) | 15:42.46 |
| paulgardiner | Yeah, and it exists solely to make openssl look slim and slick. :-) | 15:42.55 |
| tor8 | mvrhel_laptop: another option is to set up git to automatically convert tabs and spaces when you commit / check out | 15:43.11 |
| Robin_Watts | v8 is not a monstrosity. Javascript is a monstrosity, and v8 just happens to implement it. | 15:43.19 |
| tor8 | super optimising kitchen sink javascript jit-compiler is way overkill for what we need | 15:43.49 |
| vtorri_ | tor8, http://codepad.org/YlQEe3cv | 15:44.00 |
| paulgardiner | I think tor8 meant "is written in C++" | 15:44.01 |
| mvrhel_laptop | brb | 15:46.04 |
| tor8 | mvrhel_laptop: http://stackoverflow.com/a/2316728/14849 | 15:46.26 |
| henrys | tor8:have we looked around for simple libraries to do what we need? | 15:46.37 |
| tor8 | henrys: my google foo must be weak, or there aren't many options | 15:46.54 |
| | the only other candidate I found was libpki fromhttp://www.openca.org but that looks dead | 15:47.22 |
| | last update several years ago | 15:47.29 |
| vtorri | tor8, and SpiderMonkey ? | 15:47.51 |
| paulgardiner | The trouble with pkcs7 is that it combines a whole lot of different standards. | 15:48.04 |
| Robin_Watts | vtorri: Bad license, IIRC. | 15:48.40 |
| vtorri | ha | 15:49.16 |
| | don't know | 15:49.19 |
| | it's MPL | 15:49.23 |
| henrys | tor8:do you know what is used on Android devices for ssl in general? | 15:49.46 |
| vtorri | there is someting abuoot AGPL in wikipedia, about MPL | 15:49.55 |
| tor8 | sebras: what was the name of that c-based javascript interpreter you found? | 15:50.02 |
| sebras | tor8: you mean your duckduckgo-foo..? | 15:50.19 |
| | sebras: I don't remember.. :( | 15:50.42 |
| ray_laptop | kens: I'm looking at the logs to see if you got your question answered about unparsed device params | 15:50.52 |
| tor8 | sebras: I meant my intarwebzhuntingskillz! | 15:50.52 |
| Robin_Watts | henrys: Has anyone looked at bouncycastle ? | 15:51.05 |
| kens | ray_laptop : I have worked my way through it and fixed my problem | 15:51.09 |
| sebras | tor8: do you remember where I sent the link for the c-based javascript interpreter? | 15:51.12 |
| kens | It turns out that ps2write behaves the same. | 15:51.27 |
| Robin_Watts | hmm. bouncycastle = java and C# | 15:51.45 |
| paulgardiner | Anyway, what's the plan with openssl? | 15:52.06 |
| henrys | the other route is to require somebody to install ssl if they want signatures to work. | 15:52.09 |
| kens | ray_laptop : it doesn't cause the same problem because it sets dev->is_open to flase, and resets it to true around the call (UGGH) | 15:52.18 |
| sebras | tor8: http://code.google.com/p/tiny-js/ this one? | 15:52.25 |
| ray_laptop | kens: OK. It is an intentional part of the design for deviceparams -- that's why a device has to have a get_params that returns all of the parameters possible via a put_params | 15:52.29 |
| tor8 | paulgardiner: at the moment I'm thinking make it an optional dependency and require it on the system if we use it | 15:52.34 |
| sebras | tor8: it is still c++ though. | 15:52.41 |
| tor8 | sebras: no, not that one. | 15:52.49 |
| henrys | Robin_Watts:not familiar with it at all. | 15:53.07 |
| paulgardiner | tor8: we'd need to do something on the cluster for testing. | 15:53.08 |
| sebras | tor8: re: openssl why are we not doing our own Makefile like we have for libjpeg..? | 15:53.22 |
| | tor8: or this is just a matter of source code size, whether it is compiled or not..? | 15:53.43 |
| | tor8: http://code.google.com/p/quad-wheel/ this one? | 15:54.01 |
| tor8 | sebras: I have (locally) a makefile to build it with our build system | 15:54.25 |
| | the issue is that it dwarfs mupdf | 15:54.31 |
| ray_laptop | kens: there are several places tha do that. It's primarily intended to avoid opening and closing the device repeatedly during all of the 'setpagedevice' actions that often occur at the start of files. Peter came up with that hack to avoid the x11 window closing and re-opening a bunch of times | 15:54.39 |
| tor8 | sebras: that's the one! | 15:54.43 |
| sebras | tor8: so the problem is the dependencies between openssl's .c-files..? | 15:54.56 |
| tor8 | sebras: the problem is that openssl is 2MB of code | 15:55.12 |
| kens | ray_laptop : its intentional all right, it prevents the device being reopened, even though some parameters are not processed | 15:55.15 |
| tor8 | in a minimal build | 15:55.19 |
| sebras | tor8: when we compile libjpeg do we compile _all_ of it? or just the parts we need? | 15:55.51 |
| | tor8: if it is only the parts we need, why can't we do the same for openssl? | 15:56.03 |
| ray_laptop | kens: well, if you've worked it out, fine. But I don't follow what problem you were having | 15:56.09 |
| tor8 | sebras: that's what I mean. compiling *just* what we need removes 180 source files. | 15:56.22 |
| kens | ray_laptop : the problem was that my device was having its 'open' routine called twice. | 15:56.35 |
| | And I couldn't figure out why | 15:56.44 |
| tor8 | that still leaves 405 source files, and 2MB of library | 15:56.48 |
| ray_laptop | tor8: ouch! so much for "small footprint" | 15:57.15 |
| tor8 | ray_laptop: exactly why I don't want it! | 15:57.29 |
| ray_laptop | between v8 and openssl mupdf is beginning to bloat | 15:57.33 |
| sebras | tor8: and that is for the digital signatures..? or is this _only_ for the crypto algos we need..? | 15:57.41 |
| tor8 | sebras: for the digital signatures | 15:57.50 |
| | just the crypto algos would be tiny | 15:57.56 |
| | (in comparison) | 15:58.01 |
| sebras | tor8: ah, then I get it. :) I failed to comprehend how RC4 and AES could be 2MB of binary. :) | 15:58.26 |
| tor8 | the problem is that pkcs7 pulls in a lot of dependent crap. like x509 and asn1 | 15:58.27 |
| vtorri | ray_laptop, v8 and openssl will be statically linked to mupdf ? | 15:58.38 |
| sebras | tor8: is it permissible to use these in PDF as well..? maybe the PDF spec restricts the use of some parts..? | 15:59.13 |
| | or no..? | 15:59.17 |
| ray_laptop | vtorri: in an embedded environment, probably, yes. That depends on the platform and build process | 15:59.19 |
| tor8 | sebras: ask paul :) | 15:59.31 |
| | we may be able to slim it down further, if we know exactly what we can cut out | 15:59.54 |
| | (by about 100 more files, at best) | 16:00.16 |
| sebras | tor8: right. of course that might mean that we'd need to change the code. | 16:00.17 |
| paulgardiner | Both x509 and asn1 are integral to pkcs7 | 16:00.27 |
| vtorri | ray_laptop, on desktop, these are already used by other libs/prog, so it increase the mupdf size for nothing | 16:00.37 |
| mvrhel_laptop | tor8: thanks for the link above | 16:00.39 |
| tor8 | sebras: there's a "register all crypto algorithms" function to initialise openssl | 16:00.47 |
| henrys | has anyone thought to ask the openssl folks? | 16:00.51 |
| tor8 | that one could possibly be trimmed | 16:00.53 |
| vtorri | in my case, i just link jbig2dec statically against mupdf, all other are shared linked | 16:01.05 |
| tor8 | mvrhel_laptop: if you have a unix-like system, expand and unexpand are the tools to call | 16:01.15 |
| ray_laptop | vtorri: what platform are you on ? | 16:01.48 |
| tor8 | expand -t4 and unexpand -t4 | 16:01.54 |
| vtorri | ray_laptop, linux, windows, BSD*, solaris, mac os x | 16:02.17 |
| | desktop | 16:02.34 |
| ray_laptop | tor8: unfortunately, it looks like expand/unexpand aren't in the msysgit by default | 16:02.52 |
| Robin_Watts | I'm happy to pass mvrhel_laptop's review, but it's in C++, so my understanding is limited. Anyone else want to look before I push it? speak now... | 16:02.56 |
| ray_laptop | if mvrhel_laptop did it, it must be good ;-) | 16:03.19 |
| mvrhel_laptop | ha | 16:03.25 |
| Robin_Watts | ray_laptop: Shh! You're giving away my secrets :) | 16:03.40 |
| kens | Did we start GS meeting ? I didn't notice..... | 16:03.54 |
| henrys | oh meeting time. | 16:03.58 |
| Robin_Watts | mvrhel_laptop: pushed. | 16:04.16 |
| mvrhel_laptop | Robin_Watts: great. thanks | 16:04.27 |
| henrys | unfortunately, since the meeting is coming up I looked at the agenda ;-) | 16:04.31 |
| sebras | tor8: might be worthwhile to try quad-wheel. is it a good enough license for you? | 16:04.41 |
| henrys | mvrhel_laptop:you have a few promised for next meeting | 16:05.41 |
| tor8 | sebras: I believe MIT is good enough | 16:05.44 |
| mvrhel_laptop | henrys: yes. I know.... | 16:05.54 |
| | I need to get busy | 16:06.06 |
| henrys | okay - I know you have been doing the viewer. | 16:06.17 |
| | mvrhel_laptop: if you think somebody can help with simplifying testing or something let me know. | 16:06.50 |
| | chrisl: is the tmp file bug closed? | 16:07.05 |
| | I mean should it be closed? | 16:07.14 |
| chrisl | henrys: that's ray_laptop's surely | 16:07.23 |
| mvrhel_laptop | ok. marcosw and I chatted about testing issues last week at the open printing meeting | 16:07.29 |
| henrys | ray_laptop? | 16:07.41 |
| | chrisl: I thought you had been looking at it also. | 16:08.00 |
| | kens:did we remove the pswrite name? | 16:08.28 |
| chrisl | henrys: no, I had a very vague idea that Ray and discussed at the meeting, and concluded it wouldn't work | 16:08.28 |
| ray_laptop | I was wrapped up with cust 801 hand holding, but I should be able to wrap up the temp file issue. I _will_ take the approach of keeping the existing calls, and adding new ones that delete on close. | 16:08.46 |
| henrys | chrisl, ray_laptop: yes it's 693121 | 16:09.00 |
| ray_laptop | Just to avoid surprise by clients that may call them | 16:09.01 |
| kens | henrys chrisl removed it already | 16:09.20 |
| henrys | kens:great | 16:09.31 |
| kens | At the moment we still haveepswrite | 16:09.36 |
| | have epswrite | 16:09.43 |
| mvrhel_laptop | ray_laptop: I see that 801 found some issues in the auto color stuff. not sure what is going on there | 16:09.52 |
| | Robin_Watts: this might be useful | 16:11.47 |
| | http://mkdot.net/community/mknetug/b/lz/archive/2009/03/31/visual-studio-how-to-work-with-different-tab-settings-per-project.aspx | 16:11.49 |
| henrys | mvrhel_laptop, ray_laptop:about the 801 stuff does it make sense that an independent staff member test chanoes like this before sending to a customer? It just seems large changes are going to have problems, we can expect that. | 16:12.20 |
| | s/chanoes/changes | 16:12.35 |
| Robin_Watts | mvrhel_laptop: Cunning. | 16:13.02 |
| tor8 | mvrhel_laptop: if you're not tied to MSVS, sublime text 2 is smart about tab settings -- it autodetects tab/spaces and indentation depth and does the right thing. it's a shame most other editors don't do the same... | 16:13.07 |
| Robin_Watts | Even more cunning if I can have the shortcuts load the project files too. | 16:13.25 |
| mvrhel_laptop | henrys: yes that probably makes sense | 16:13.33 |
| ray_laptop | henrys: that was sort of garbled with [\0x1d] | 16:13.52 |
| henrys | ray_laptop:huh? is there something with my irc client? | 16:14.53 |
| ray_laptop | henrys: but w.r.t. changes that were specifically developed for cust 801, we really don't have any other users, so they are going to be bleeding edge. Same as other customers that get 'special' enhancements | 16:15.51 |
| henrys | kens, chrisl:ray_laptop wanted feedback on 691513? | 16:16.07 |
| sebras | tor8: qual-wheel is about 10k LOC, however it suffers from some 32- vs 64-bit issues. | 16:16.20 |
| kens | henrys, I hoped chris would look at it | 16:16.51 |
| sebras | tor8: if I remove -Werror from the makefile and compile it anyway. I get segfaults when running the binary with some js-input. | 16:17.04 |
| chrisl | It hasn't seemed terribly important...... | 16:17.07 |
| henrys | ray_laptop should know better to ask 2 people - the outcome is inevitable ;-) | 16:17.21 |
| sebras | tor8: also upstream seems dead, so basically you'd take on the project. | 16:17.47 |
| tor8 | sebras: the upstream has two commits, so probably just a dead code drop | 16:18.01 |
| | but it may be worth reviving or taking on | 16:18.12 |
| sebras | tor8: yes, actually bug #2 is someone asking for source. :) | 16:18.21 |
| tor8 | depends on how far from usable it is | 16:18.22 |
| ray_laptop | so which one us our ToUnicode expert kens or chrisl ? | 16:18.28 |
| kens | henrys as far as I can see, the PDF file uses a font, and doesn't include it (CIDFont) which is illegal. We make an effort and it doesn't work. | 16:18.29 |
| henrys | chrisl:if you say that in a comment I will ignore it for the agenda. | 16:18.40 |
| kens | ToUnicode is not supposed to be used for rendering in any circumstance | 16:18.49 |
| chrisl | henrys: I meant that I haven't looked at it at all, because it didn't seem important. | 16:19.15 |
| sebras | tor8: seems useful to me, but I don't know how far from ecma-262 it is. is there an testkit for this..? | 16:19.16 |
| ray_laptop | kens: so is Adobe using the ToUnicode do you think ? | 16:19.53 |
| | (my comment #11) | 16:20.04 |
| Robin_Watts | sebras/tor8: How important is this really? We have v8, and it works. Why rock the boat? | 16:20.12 |
| tor8 | ray_laptop: we use the ToUnicode as a last attempt to get something reasonable in mupdf for this case | 16:20.17 |
| chrisl | henrys: but as kens says: it's a file that doesn't follow the spec, we make a stab it, and it doesn't work - moral of the story: follow the spec | 16:20.22 |
| kens | ray_laptop : could be, possibly, see my comment #9 | 16:20.24 |
| tor8 | Robin_Watts: because it'd be swell to be able to not rely on the monster v8 and actually include javascript support in the default builds | 16:20.48 |
| | and not lose face when calling it lightweight... | 16:21.02 |
| vtorri | http://bugs.ghostscript.com/show_bug.cgi?id=694090 | 16:21.08 |
| henrys | chrisl:anytime a bug is very close to being finished it's important ;-) | 16:21.08 |
| tor8 | but it's not hugely important, imo | 16:21.12 |
| vtorri | my foirst contribution... | 16:21.28 |
| | first* | 16:21.31 |
| kens | ray_laptop : the way to tell, I suppose, would be to modify the ToUnicode CMap and see if Acrobt displys something different | 16:21.36 |
| ray_laptop | kens: OK. so either you or chrisl can close this | 16:21.38 |
| chrisl | It's listed as "resolved" | 16:21.55 |
| kens | ray_laptop : I'll leave it to chrisl | 16:21.57 |
| henrys | chrisl:did you end up with third party apps for mupdf? | 16:22.10 |
| chrisl | henrys: I never got an answer from Robin_Watts - I meant to ping him about it today | 16:22.38 |
| ray_laptop | kens: that's an interesting idea. zap the ToUnicode map and see if it confuses Adobe. Then file a bug with Adobe if it does :-) | 16:22.47 |
| Robin_Watts | chrisl: All yours, if you want it. | 16:22.51 |
| kens | ray_laptop : I'msure they'll say 'follow the spec' | 16:23.02 |
| chrisl | Okay, henrys looks like I'm doing it | 16:23.05 |
| kens | ray_laptop : after they've said 're-install Acrobat, re-install Windows....' | 16:23.23 |
| chrisl | kens: is the status of 691513 not already "resolved"? | 16:23.37 |
| kens | chrisl it is | 16:23.57 |
| chrisl | So I can't do any more than that | 16:24.23 |
| | henrys: 691513 has been "resolved" since February, it looks like | 16:25.12 |
| ray_laptop | kens: well, the spec is clear that ToUnicode is only used for text extraction. | 16:25.16 |
| henrys | marcosw, alexcher :meeting news. | 16:25.29 |
| kens | ray_laptop : if I remove teh ToUnicode CMaps, then the file still works, so its not that | 16:25.31 |
| henrys | ? | 16:25.33 |
| ray_laptop | chrisl: you're right. henrys brought it up. How come, henrys | 16:26.10 |
| henrys | marcosw:how often with gcov be regenerated I have some changes. | 16:26.11 |
| kens | ray_laptop : chrisl of course, as its a CIDFont, we'll be using DroidSans, not TimesNewRoman, unless the user had specified a cidfmap | 16:26.32 |
| alexcher | henrys: I don't have any news. | 16:26.56 |
| henrys | ray_laptop:oh sorry the last comment say I reopened the bug - I would expect another comment if that changed? | 16:27.16 |
| ray_laptop | kens: so, we should be able to map that Ordering to TimesNewRoman and get the same as Adobe ??? | 16:27.32 |
| chrisl | kens: I think the only confusion there was the claim there's only a problem with pdfwrite? | 16:27.54 |
| kens | ray_laptop : if you define an entry in cidfmap to use times.ttf, it will 'probably' work | 16:28.00 |
| ray_laptop | henrys: I lied (I guess). I don't really remember | 16:28.08 |
| | let's just drop it. It's been closed a while, and it never was a customer bug. | 16:28.39 |
| henrys | ray_laptop:agreed. | 16:28.50 |
| ray_laptop | henrys: do you have anything else to waste our time with ;-) | 16:29.03 |
| henrys | We are at the 1/2 hour. | 16:29.23 |
| | ray_laptop:no but I'll work on it for next meeting. | 16:29.34 |
| ray_laptop | henrys: got to hone those pointy haired management skills ;-) | 16:29.54 |
| henrys | I've gotten back into reading dilbert it's been pretty good lately. | 16:30.20 |
| | I haven't read it in a long time. | 16:30.36 |
| | I was going to bring up what on earth are we doing with 15000 bugs marcosw made but I'm not going there today. | 16:31.27 |
| mvrhel_laptop | I will send out an email, but I am out Wed-Fri this week | 16:31.30 |
| marcosw_ | henrys: I didn't 'make' the bugs, I only entered them into the bug tracker. Don't blame the messenger. | 16:32.11 |
| ray_laptop | oh, that reminds me. I will be out most of Thursday. I'll also send out the email | 16:32.14 |
| | marcosw: you wrote the bot that submitted the bugs, so you get the blame ;-) | 16:32.36 |
| Robin_Watts | and I'm in Boston at the show from next Wednesday -> Sunday. | 16:32.46 |
| ray_laptop | Robin_Watts: have fun there. Are you going to talk a lot about our new WinRT viewer ;-) | 16:33.27 |
| henrys | Robin_Watts:great town Robin_Watts spend some time getting around? | 16:33.40 |
| | s/?/! | 16:33.46 |
| marcosw_ | ray_laptop: we should blame Steve Capps, he's listed in the wikipedia article as one of the earliest examples of fuzzing. | 16:34.12 |
| Robin_Watts | henrys: We have saturday to go sightseeing, plus any time we can grab on the evenings etc. | 16:34.12 |
| mvrhel_laptop | henrys: and then next week I am going to be up in Vancouver at the IEEE ICASSP conference presenting a paper | 16:34.55 |
| henrys | what is the paper about? | 16:35.58 |
| Robin_Watts | bets on "color". | 16:36.24 |
| mvrhel_laptop | it is about creating optimal color tables when you have signal dependent (Poisson) noise | 16:36.46 |
| | Robin_Watts is right | 16:36.50 |
| monxalo | hi guys, first of all, let me thank you for an awesome pdf library :). Second, i would like to know how can someone contribute to the project, namely the 'android' submodule. I know there's an issue tracking, but i did not find any info on how to contribute. | 16:37.02 |
| ray_laptop | monxalo: contribute money or help improve the code ? | 16:38.10 |
| henrys | mvrhel_laptop: why would you want to do that ? ;-) | 16:38.18 |
| ray_laptop | helping with the code is always welcome ! | 16:38.24 |
| monxalo | with code ofc :) | 16:39.24 |
| Robin_Watts | monxalo: Well, the developers are here all day, every day, so coming here is a good start. | 16:39.50 |
| monxalo | with money i would contribute to the whole project, not just the android submodule :P | 16:40.02 |
| ray_laptop | monxalo: Robin_Watts, tor8 and paulgardiner are the people to ask. | 16:40.04 |
| mvrhel_laptop | so the raw data from a camera has Poisson noise and you can decrease the effects of this just a tiny bit if you account for the signal dependency of the noise in the table construction | 16:40.05 |
| Robin_Watts | Do you have a particular area you'd like to work in? | 16:40.10 |
| | I mean, if there is something in particular you want it to do that it doesn't do, then let us know. | 16:40.29 |
| | Otherwise we can come up with lots of ideas :) | 16:40.36 |
| | One thing I'd like to see is to see a reflection layer built to expose the standard MuPDF library API into java. | 16:41.24 |
| monxalo | 'm just interested on improving the android submodule, it's my area of expertise :). | 16:41.30 |
| ray_laptop | identifying performance hot spots and improving performance is something that doesn't need a lot of interaction with us. | 16:41.32 |
| chrisl | henrys, kens, ray_laptop: I've added a concluding comment to 691513, to hopefully reduce future confusion | 16:41.59 |
| kens | :-) | 16:42.05 |
| monxalo | yeah, mainly that, just improving some overdrawing issues on the android submodule, for starters :) | 16:42.22 |
| ray_laptop | chrisl: Thanks. I'm sure you eased henrys' mind | 16:42.26 |
| | ;-) | 16:42.31 |
| chrisl | ray_laptop: it seemed a shame to spend so much time talking about it, and not make a change! | 16:42.52 |
| henrys | chrisl, ray_laptop:now I'll sleep without tossing and turning ;-) | 16:43.35 |
| Robin_Watts | monxalo: What sort of overdrawing issues? | 16:43.53 |
| ray_laptop | chrisl: right, it's like when you go to the doctor's office, spend a lot of time waiting, and they say -- it'll clear up on its own. You feel like you just wasted 2 hours (and the $10 copay) | 16:44.21 |
| monxalo | here, i'll post a link, you guys know of the 'Show GPU overdraw' option on 'Developer options' in recent android releases? | 16:45.23 |
| chrisl | ray_laptop: exactly! | 16:45.33 |
| Robin_Watts | monxalo: I'd not seen it, no. | 16:46.11 |
| | If you can tell us how to reduce it, we'd clearly be interested. | 16:46.29 |
| henrys | chrisl:is changing the ghostscript website to be like mupdf just a css change or is it something more radical? | 16:47.05 |
| monxalo | sure | 16:47.10 |
| henrys | actually the agenda looks really good. Lots of stuff completed FWIW. | 16:48.49 |
| monxalo | http://s23.postimg.org/si2neehwr/device_2013_05_21_172948.png, so basically this is pdf open on the current MuPDF android app. | 16:48.52 |
| henrys | chrisl:I keep pinging URW nothing from my last of a week ago. | 16:49.47 |
| marcosw_ | henrys: I have to run, anyone have anything for me? | 16:49.53 |
| monxalo | the colors, represent how many times that area was overdrawn. | 16:49.54 |
| Robin_Watts | ok. | 16:50.03 |
| | which colors mean which? | 16:50.28 |
| henrys | marcosw_:just when gcov witll be regenerated? | 16:50.33 |
| Robin_Watts | mvrhel_laptop: That vs trick works a treat, thanks! | 16:50.36 |
| monxalo | blue - 1 x, green - 2 x, light red - 3x, red - 4x or more. | 16:50.36 |
| ray_laptop | hmm... so, when I back port the (rather extensive) BGPrint changes to 9.07 for cust 801, it fails to open the scratch files for the thread. But this works on the HEAD rev. I'm firing up a second debugger on the HEAD rev to see if I can find out why. | 16:50.52 |
| henrys | marcosw_: is it on a schedule? | 16:50.58 |
| mvrhel_laptop | Robin_Watts; cool. I will do the same | 16:50.59 |
| ray_laptop | too bad Windoze doesn't have strace :-( | 16:51.04 |
| Robin_Watts | ray_laptop: sysinternals.com | 16:51.20 |
| | ray_laptop: process monitor | 16:51.35 |
| marcosw_ | currently it's a manual process, but I'm about to starting running it as a cronjob, probably weekly. | 16:51.37 |
| henrys | marcosw_:okay thanks and you have a few bug | 16:52.00 |
| | customer followup stuff. | 16:52.07 |
| marcosw_ | henrys: yeah, I noticed :-) | 16:52.10 |
| ray_laptop | Robin_Watts: I'll try it. It tends to be inordinately noisy, iirc | 16:52.11 |
| | Robin_Watts: but thanks | 16:52.16 |
| Robin_Watts | ray_laptop: You can set what you want reported etc. | 16:52.28 |
| henrys | marcosw_: have a good day! | 16:52.29 |
| chrisl | henrys: I'm not surprised - I expected we'd have a bit of a wait | 16:52.35 |
| Robin_Watts | so it's exactly as noisy as you need it to be. | 16:52.35 |
| marcosw_ | thx. I'll be back later | 16:52.37 |
| Robin_Watts | and you can restrict it to just the target process, obviously. | 16:52.45 |
| henrys | chrisl:I take it we have done everything with source forge and google code. source forge has the message. so I can strike that item? | 16:53.54 |
| chrisl | henrys: I haven't done anything with them, and wasn't planning to until the next release is due | 16:55.09 |
| | Oh, except I need to sort out the jbig2dec sf page - it slipped my mind because it took me so long to access it! | 16:55.47 |
| henrys | well source forge says where to go we should probably leave that as is, and we agreed not to change google code because of certificate avoidance, so nothing to do right? | 16:56.38 |
| chrisl | henrys: I was going to say explicitly that the GS sourceforge project was defunct and, as I said, the jbig2dec page needs revised | 16:57.50 |
| henrys | chrisl: okay I'll leave it in. | 16:59.16 |
| ray_laptop | Robin_Watts: Thanks for the suggestion, but parallel debugging showed a difference. _wfopen works (in HEAD) but fopen (in 9.07) doesn't! :-/ | 17:01.07 |
| Robin_Watts | ray_laptop: What filename ? | 17:01.41 |
| henrys | alexcher:I think it would be reasonable for you to start in on marcosw fuzzing list if you aren't working on other bugs - simplify and assign to owner? | 17:02.56 |
| | alexcher:oh wait was he doing a valgrind analysis first? | 17:03.41 |
| Robin_Watts | marcosw_, henrys: I went through a few fuzzing bugs the other day. Lots of them seem to have gone away, if you build with -DENABLE_VALGRIND -DPACIFY_VALGRIND | 17:03.56 |
| henrys | if I build with the -D's I don't get a crash but I do if I don't - ^-) | 17:05.09 |
| marcosw_ | Robin_Watts, henrys: so we should make -DENABLE_VALGRIND -DPACIFY_VALGRIND the default? | 17:05.58 |
| Robin_Watts | marcosw_: For valgrind testing, it should be the default. | 17:06.13 |
| | But otherwise, no. | 17:06.21 |
| henrys | I think all customers should run the code under valgrind. | 17:06.24 |
| marcosw_ | what about for fuzzing? | 17:06.26 |
| Robin_Watts | marcosw_: the -D's should never affect crashing or not, so henrys has me confused :( | 17:08.10 |
| marcosw_ | but you said the same thing: that the crashes go away if you build with -DENABLE_VALGRIND -DPACIFY_VALGRIND | 17:08.43 |
| henrys | well an example 693859 says it crashes that's one of the bugs - and Robin_Watts said lots of them go away with ... | 17:09.43 |
| Robin_Watts | marcosw_: Sorry, no. I was saying that the valgrind errors go away with the -D's. | 17:09.55 |
| henrys | thanks I see. | 17:10.29 |
| | marcosw_:so you can go through them or alexcher can be the front man if you're busy. | 17:11.35 |
| marcosw_ | I'm not sure I see. For some of the fuzzing bugs the valgrind messages go away if you use -DENABLE_VALGRIND -DPACIFY_VALGRIND but the crashes remain? That seems to suggest that running valgrind on the fuzzing issues is not useful. | 17:12.52 |
| Robin_Watts | marcosw_: The purpose of "-DENABLE_VALGRIND -DPACIFY_VALGRIND" is to cut out false valgrind warnings. | 17:15.15 |
| mvrhel_laptop | Robin_Watts: cool. I now have two VS start options and it seems to work nicely. Hopefully that will be the end of my tab/space issues | 17:16.03 |
| Robin_Watts | If you valgrind gs and it gives you loads of valgrind warnings, you might think "aha, these point to problems that might later be causing the crashes". | 17:16.06 |
| | Far better to valgrind a version of gs that hides as many of the false warnings. | 17:16.37 |
| | as possible | 17:16.43 |
| mvrhel_laptop | back to some productive work... | 17:16.47 |
| Robin_Watts | mvrhel_laptop: Thanks for finding that! | 17:16.54 |
| mvrhel_laptop | sure np | 17:16.59 |
| marcosw_ | Robin_Watts: so you say that adding "-DENABLE_VALGRIND -DPACIFY_VALGRIND" reduces the valgrind false error messages for fuzzing issue, allowing the "real" issues to be more obvious? | 17:17.27 |
| Robin_Watts | marcosw_: An admirable way of putting it, yes. | 17:17.40 |
| ray_laptop | Robin_Watts: sorry, I was chasing parallel debuggers down the chain of MS CRTL functions. It makes it all the way down to CreateFile (which I can't trace into) and all the parameters are identical (except one has the filename in UTF-8) and UTF-8 works, but ASCII doesn't :-( | 17:19.00 |
| marcosw_ | thx for clarifying; I will re-run the fuzzing crashes under valgrind with "-DENABLE_VALGRIND -DPACIFY_VALGRIND" and close/open bugs as appropriate. | 17:19.02 |
| | oops, now I really have to go. bbaiw. | 17:19.14 |
| Robin_Watts | marcosw: Thanks. | 17:19.23 |
| | ray_laptop: So what was the filename in question? | 17:19.35 |
| | http://msdn.microsoft.com/en-us/library/yeby3zcb(v=vs.80).aspx | 17:20.58 |
| | _wfopen is a wide-character version of fopen; the arguments to _wfopen are wide-character strings. _wfopen and fopen behave identically otherwise. | 17:21.08 |
| | so unless there is a strange char or two in the filename, I'm at a loss to explain the difference. | 17:21.26 |
| | henrys: Just as a sanity check - is there anything outstanding that you're expecting from me before the meeting? | 17:22.37 |
| | (I have to panic a week before everyone else :) ) | 17:22.50 |
| ray_laptop | Robin_Watts: in the debugger they look quite similar: one is "C:\Temp\_te7B53.tmp" and the other is "C:\Temp\_te41FB.tmp" It should be obvious which one works :-) | 17:22.52 |
| Robin_Watts | should it? | 17:23.42 |
| ray_laptop | Robin_Watts: one shows in the debugger as type "const char *" and the other shows as type "const wchar_t *" Now can you tell ? | 17:24.48 |
| henrys | Robin_Watts: nope I mean you have open projects on the agenda but I was just bringing stuff up that seemed reasonable to be addressed before the next meeting. | 17:24.49 |
| ray_laptop | henrys: wait a minute. Read your manager's handbook. Where in there is the word "reasonable" mentioned ??? ;-) | 17:25.27 |
| Robin_Watts | henrys: Yeah, I checked the agenda and couldn't see anything that I thought was a) mine, and b) due. But it's nice to have it confirmed :) | 17:25.44 |
| | thanks. | 17:26.29 |
| henrys | ray_laptop:yes there is that ;-) | 17:27.40 |
| ray_laptop | Robin_Watts: I'm at a loss. It looks like I can deal with automatic tempfile delete on close, but only #ifndef GS_NO_UTF8 :-( | 17:28.21 |
| Robin_Watts | ray_laptop: so just recap me. | 17:28.58 |
| | It's working with the UTF8 changes in, but not without them? | 17:29.08 |
| | craptastic test: add a hack so that instead of doing fopen(blah) you do wblah = convert_to_utf8(blah); _wfopen(wblah); | 17:30.06 |
| ray_laptop | Robin_Watts: right. _wfopen works, fopen doesn't | 17:30.07 |
| Robin_Watts | and see if that works. | 17:30.11 |
| | If it does, then you have confirmation that _wfopen and fopen work differently. | 17:30.29 |
| ray_laptop | Robin_Watts: that's easy. in 9.07 gp_mswin.c gp_fopen, I just change #ifdef WINDOWS_NO_UNICODE to #if 0 | 17:31.48 |
| | Robin_Watts: trying it now... | 17:32.01 |
| | with the convert_to_utf8 inserted, of course... | 17:33.31 |
| Robin_Watts | right, I was just trying to figure that out :) | 17:33.56 |
| mvrhel_laptop | bbiab | 17:39.32 |
| ray_laptop | yuck. Doesn't build cleanly. I think I'll just try a stock build with USEUNICODE=1 | 17:43.55 |
| | Robin_Watts: hmm... that's not it (of course, I guess that is a bit reassuring). It must be something else ??? It's using _wfopen now, and still fails. So, back to the debuggers :-( (and maybe sysinternals) | 17:52.31 |
| Robin_Watts | ray_laptop: damn. | 17:52.52 |
| kens | Goodnight all | 17:57.49 |
| ray_laptop | hmm... I tried building HEAD with GS_NO_UTF8=1 and it gets an unresolved external :-( Maybe a bug for chrisl | 18:11.49 |
| Robin_Watts | Yes, fgr chrisl, definitely. Excellent plan! | 18:13.09 |
| | s/fgr/for/ | 18:13.14 |
| ray_laptop | Robin_Watts: I must be missing something. debugobj/gssprintf.obj _is_ in the list of objects for the linker! And nm debugobj/gssprintf.obj has the "unresolved" item in it. ???? | 18:21.35 |
| Robin_Watts | ordering? | 18:21.59 |
| ray_laptop | ordering ??? | 18:22.09 |
| Robin_Watts | For linux at least the order of the object files matters. | 18:22.23 |
| ray_laptop | ordering what? pizza ??? | 18:22.27 |
| | how could that result in unresolved ??? | 18:22.51 |
| Robin_Watts | link a b c | 18:23.02 |
| | unresolved things from b are only resolved in things to the left of b. | 18:23.24 |
| | or is it the right? | 18:23.32 |
| | and that may only be libs, not object files. | 18:23.41 |
| ray_laptop | with libs, I could understand it | 18:23.56 |
| Robin_Watts | What's the unresolved item? | 18:24.32 |
| ray_laptop | and I would expect it to be to the right (things unresolved in a can be resolved in b or c) | 18:24.37 |
| | _gs_sprintf | 18:24.46 |
| Robin_Watts | I'd worry that windows was adding another _ on it or something. | 18:25.09 |
| ray_laptop | but objects mentioned explicitly _should_ always be included | 18:25.18 |
| Robin_Watts | is it prototyped everywhere it is used? | 18:25.21 |
| ray_laptop | Robin_Watts: I thought that might be the problem, and I added #incude "gssprintf.h" to gp_wgetv.c | 18:25.59 |
| | Robin_Watts: the only place gssprintf.h was #included was by gssprintf.c -- sloppy practice, IMHO. It's used in 27 files | 18:31.16 |
| Robin_Watts | ray_laptop: gssprintf.h is a new thing right? Only in the past 3 weeks or so? | 18:32.00 |
| ray_laptop | Robin_Watts: right. I'll just leave that for chrisl and open a bug for him. It's not like I needed it. | 18:32.54 |
| | I'm surprised that linux didn't spew a bunch of warnings | 18:33.57 |
| | (or maybe it did and they were just ignored as usual) ;-) | 18:34.14 |
| Robin_Watts | tor8: ping | 18:36.58 |
| | tor8: http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=db9f1dadbc7c302bc6c1947760b95715dd1652e3 | 18:37.32 |
| tor8 | Robin_Watts: fab! | 18:38.09 |
| Robin_Watts | tor8: Thanks. | 18:38.25 |
| | monxalo has given us a useful patch too that should speed up our redraw on android. | 18:39.05 |
| | It might get us to 60fps rather than 30fps on the posh nexus devices. | 18:39.25 |
| | I'll get paulgardiner to look at the patch tomorrow. He's indicated that he's happy to sign the CLA too. | 18:39.54 |
| | Damn. Still getting crashes :( | 18:46.22 |
| ray_laptop | Robin_Watts: so here's what the failure shows: | 18:58.44 |
| | 11:52:00.4517676 AMgswin32c.exe9472CreateFileC:\Temp\_teD6BD.tmpSHARING VIOLATIONDesired Access: Generic Read, Disposition: Open, Options: Synchronous IO Non-Alert, Non-Directory File, Attributes: N, ShareMode: Read, Write, AllocationSize: n/a | 18:58.46 |
| | The case that works gives: | 18:58.47 |
| | 11:57:25.9784604 AMgswin32c.exe2320CreateFileC:\temp\_te8C65.tmpSUCCESSDesired Access: Generic Read, Disposition: Open, Options: Synchronous IO Non-Alert, Non-Directory File, Attributes: N, ShareMode: Read, Write, AllocationSize: n/a, OpenResult: Opened | 18:58.49 |
| | I can't see any difference | 18:59.27 |
| Robin_Watts | no, me either. | 18:59.40 |
| | C:\temp vs C:\Temp ? | 19:00.00 |
| ray_laptop | So the failure case opens the file that fails (different run this time) with: | 19:09.11 |
| | 12:00:55.7084608 PMgswin32c.exe7832CreateFileC:\temp\_teEFBA.tmpSUCCESSDesired Access: Generic Read, Disposition: Create, Options: Synchronous IO Non-Alert, Non-Directory File, Attributes: N, ShareMode: None, AllocationSize: 0, OpenResult: Created | 19:09.13 |
| | The case that works opened: | 19:09.14 |
| | 11:55:02.6152154 AMgswin32c.exe2320CreateFileC:\temp\_te8C65.tmpSUCCESSDesired Access: Generic Read, Disposition: Create, Options: Synchronous IO Non-Alert, Non-Directory File, Attributes: N, ShareMode: None, AllocationSize: 0, OpenResult: Created | 19:09.16 |
| Robin_Watts | http://support.microsoft.com/kb/316609 | 19:12.16 |
| | So temp vs Temp made a difference? Or the problem doesn't always occur ? | 19:12.32 |
| ray_laptop | Robin_Watts: I don't know why one is getting C:/Temp and the other C:/temp but the problems are VERY repeatable. | 19:13.47 |
| Robin_Watts | The difference between the earlier 2 and the later 2 are "ShareMode: None" vs "ShareMode: Read,Write" | 19:14.03 |
| | If you open without sharing, then it seems reasonable not to get a Sharing Violation. | 19:14.44 |
| ray_laptop | Robin_Watts: Both are opened the same way (ShareMode: None) and when the failure occurs, they are both ShareMode: Read, Write | 19:17.54 |
| | I assume that ShareMode: None defaults to Read, Write because that's how it ends up. | 19:18.27 |
| | The kb article you mentioned above does say "When you open a file, you must always handle a sharing violation in a graceful manner so that you do not affect the user of the system or cause the system to crash. You can do this by using a simple retry mechanism. You may have to perform multiple retries before the file is unlocked. " | 19:19.13 |
| Robin_Watts | ray_laptop: CreateFile takes ShareMode as an argument. | 19:19.15 |
| | What mode are you passing to _wfopen ? | 19:19.52 |
| ray_laptop | which time ? | 19:20.03 |
| Robin_Watts | ray_laptop: Are you passing different modes at different times? | 19:20.32 |
| ray_laptop | Robin_Watts: based on that BS about "you must retry" I used the debugger "Set Next Statement" and guess what. The second time it worked. So whazzup with that ??? | 19:21.25 |
| Robin_Watts | ray_laptop: Do you have antivirus on this machine? | 19:21.45 |
| | lots of stuff like antivirus hooks the file creation things. | 19:22.14 |
| | whenever a file is created the AV scans it. | 19:22.21 |
| | hence if you open with "no sharing" you're fine. | 19:22.36 |
| | If you open with "sharing", then you have to be prepared for someone else instantly grabbing a handle to your file and the sharing failing. | 19:23.02 |
| | hence me wondering how you can be asking for sharing sometimes, and not sharing on other times. | 19:23.20 |
| ray_laptop | Robin_Watts: when we create the file initially we use fmode="w+b", then when we open it for read, we use fmode="rb" | 19:23.20 |
| Robin_Watts | And are both of those failing? or just one of them? | 19:23.36 |
| | If the only failures you are seeing are on the "w+b" ones, that would kinda make sense. | 19:23.49 |
| ray_laptop | one fails (9.07 code) and HEAD works. We always have the same fmode pattern | 19:24.01 |
| Robin_Watts | which fmode pattern? | 19:24.14 |
| ray_laptop | so I wonder if my virus checker or something sees C:\Temp but doesn't see c:\temp ??? | 19:25.10 |
| Robin_Watts | ray_laptop: Stranger things have happened. | 19:25.23 |
| ray_laptop | and causes the temporary lock | 19:25.25 |
| Robin_Watts | Which fmode pattern is failing? | 19:25.38 |
| | or are both failing? | 19:25.42 |
| ray_laptop | the fmode pattern is always the same for 9.07 and HEAD. HEAD works and 9.07 fails | 19:26.09 |
| Robin_Watts | ray_laptop: Right. The fmode pattern is always the same for 9.07 and HEAD. I get that. | 19:26.32 |
| | BUT WHAT IS THE PATTERN? | 19:26.36 |
| ray_laptop | gp_open_scratch_file_64 uses fmode w+b then it writes AND reads the files. Then we open the same file name to allow BGPrint (still in the main thread) with fmode rb | 19:27.54 |
| | the open with fmode rb works in HEAD and fails in 9.07 | 19:28.21 |
| Robin_Watts | OK, so the failure is on an rb access. | 19:29.03 |
| ray_laptop | correct. and there is still a FILE * (handle) open with the fmode w+b in BOTH cases | 19:29.39 |
| Robin_Watts | Ah. And which of those has ShareMode: None ? | 19:30.16 |
| ray_laptop | Robin_Watts: Both are opened with ShareMode: None | 19:31.23 |
| Robin_Watts | ray_laptop: Except in the failure case the report always comes back as saying ShareMode: Read,Write ? | 19:31.59 |
| | In fact, in the examples you pasted earlier, both a success and a failure came back with ShareMode Read/Write | 19:33.18 |
| | so I'm confused. | 19:33.38 |
| ray_laptop | Robin_Watts: I am still getting used to procmon I'm going to double check... | 19:35.52 |
| Robin_Watts | tor8: http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=7ca8145238935fb5d704dd72c078fd946885a7e5 | 19:46.53 |
| | So _wfopen calls _wfsopen with _SH_DENYNO | 19:54.11 |
| | i.e. Permits read and write access. | 19:54.25 |
| ray_laptop | Robin_Watts: when I traced down into the fopen path, it also ended up with _SH_DENYNO | 20:06.58 |
| | Robin_Watts: after more careful comparison, I see a different pattern of close/re-open of the file that fails in one case and succeeds in another. I'm going to look at what else has changed with HEAD that may not have been in the patch | 20:08.30 |
| Robin_Watts | ok. | 20:09.00 |
| ray_laptop | Robin_Watts: when it works, the file has been closed, but still re-opened for w+b | 20:09.10 |
| | tracking that down, but first some lunch... | 20:09.39 |
| | bbiaw | 20:09.43 |
| SpNg | is there an easy way to extract common color values from an eps file with ghostscritp? | 21:40.12 |
| | Forward 1 day (to 2013/05/22)>>> | |
IRC Logs
