| | <<<Back 1 day (to 2013/06/17) | 2013/06/18 |
| mvrhel_laptop | finally I see how to do this proper launching of the app based upon a file association | 05:44.59 |
| | talk about something not being well documented | 05:45.20 |
| | done for the night | 05:45.35 |
| kens | chrisl ping | 06:53.37 |
| chrisl | kens: pong | 06:56.26 |
| kens | your fix for 694354 looks OK to me (as much as I knw about it, wich isn't a lot) | 06:56.50 |
| | Did you see teh scan-build compilation warnings on the T1 checking code ? | 06:57.19 |
| chrisl | Yes, but I'm not sure what it's on about - those lines are the same as the used to be | 06:57.50 |
| kens | I know. Its probable that the warning always existed, but changing teh source code gets yo ua 'new' warning | 06:58.16 |
| | I just wondered if you knew what its comlaining about :-) | 06:58.31 |
| chrisl | I haven't got a clue, and I've lost the mail..... | 06:59.20 |
| kens | Hang on, I can paste the warning | 06:59.32 |
| | ./base/gxtype1.c:458:21: warning: The left operand of '>>' is a garbage value | 06:59.43 |
| | c = fixed2int_var(*csp) + pdata->subroutineNumberBias; | 06:59.44 |
| | ^~~~~~~~~~~~~~~~~~~ | 06:59.44 |
| | THe '^----' is supposed to point at fixed2int_var, which I guess is a macro | 07:00.08 |
| chrisl | I wonder if we should have the *csp in an extra pair of parentheses | 07:00.45 |
| kens | Possibly, its nested macro time again | 07:01.15 |
| | Bizarrely its not complaining about the '<<' which coems earlier in the macro | 07:01.52 |
| | It 'appears' to be complaining about the (_fixed_lo(x) >> | 07:02.41 |
| chrisl | I can't see anywhere else that we use those macros on a dereferenced pointer, so it might mean assigning to a local variable, and calling the macro on that | 07:03.10 |
| kens | Not sure its worth it for a compiler warning, the code apparently works, so I assume its just the scanner getting its knickers twisted | 07:04.33 |
| chrisl | I think so - it definitely works, because I could see it being evaluated correctly | 07:05.28 |
| kens | So I think we should ignore it, while I like getting rid of warnings, I'm not convinced we should meddle with teh code when its just the comiler throwing a hissy fit. | 07:06.04 |
| chrisl | Oh, I wonder: it looks like we could change it to "csp[0]" and make it happy | 07:07.56 |
| kens | Hmm, well its the same so I guess.... You want to try it and see ? | 07:08.19 |
| chrisl | I'm not sure how to prompt a scan-build test other than a commit | 07:08.59 |
| kens | Don't you get one with a cluster push ? Maybe not. | 07:09.16 |
| | Its not important enough to worry about, maybe ask Marcos this afternoon | 07:09.51 |
| chrisl | No, you don't. I'm just looking at the scan-build report, and other places that use an array index don't elicit a warning. | 07:09.59 |
| kens | Well, maybe just commit it then | 07:10.20 |
| | It won't do any actual harm | 07:10.29 |
| chrisl | Actually, looking at the previous scan-build reports - I haven't the faintest idea! | 07:13.46 |
| kens | Then lets just ignore it :-) | 07:14.04 |
| | I see Guillaume is sending huge tiffs to the support list again | 07:14.29 |
| chrisl | I might be able to do a scan-build test locally | 07:16.20 |
| kens | I wouldn't worry | 07:16.33 |
| | Hmm, sseek past end of file doesn't return an error.... | 07:31.57 |
| chrisl | Does it set the status? Or do you have to try to read from it before there's any indication? | 07:33.56 |
| kens | Not sure what you mean. | 07:34.22 |
| | It turns out that lseek64 (on windows anyway) also doesn't return an error when you do that. | 07:34.41 |
| | FWIW we've already done a seek to 0 twice without problems | 07:34.58 |
| chrisl | Oh, so you probably need to try to read from it | 07:35.03 |
| kens | Indeed. | 07:35.13 |
| | It just means that we cannot detect a stupidly large 'startxref' immediatley | 07:35.33 |
| | I was rather expecting we would | 07:35.47 |
| | So back to the PostScript code | 07:36.10 |
| | Hmm, looks like we *do* try to read form teh file, oddly that salso doesn't trigger an error (huh ?) | 07:37.42 |
| | Great, the check_read_file routine is a macro, which uses other macros and ends up with C code in the header file. I hate this stuff. | 07:40.02 |
| chrisl | kens: running scan-build locally, neither of those lines produce warnings...... | 07:52.23 |
| kens | Oh, great, consistency :-( | 07:52.38 |
| chrisl | Yep, I'm going to ignore it | 07:52.50 |
| kens | I htink that's the right thing to do, it works, and I believe its always produced these warnings Its just a confused compiler. | 07:53.23 |
| chrisl | At least I know how to run scan-build now! | 07:54.21 |
| kens | Well, it looks like the whole file scanner logic is stuffed. If I setfileposition beyond the end of file, then read from the stream, it happily returns me the character from the last location it had buffered up. | 07:54.28 |
| chrisl | What happens if you do bytesavailable? | 07:55.01 |
| kens | Not sure, I'd guess it returns me the amount of data it currently has buffered. | 07:55.22 |
| | Basically its just read the integer relating to startxref. We then setfileposition to a mad number. When I use token on the file, it reads from the '\n' at the end of the integer. Clearly this is wrong. | 07:56.23 |
| | The buffers should have been reset after the setfileposition | 07:56.41 |
| | Hmm, I wonder if I'm looking at differetn streams. | 07:58.58 |
| kens | coffees | 08:04.21 |
| | Hmm, lots of timeouts on the cluster | 08:26.09 |
| chrisl | I don't think that can be related to the commit | 08:34.34 |
| kens | Beats me... Its weird though | 08:34.49 |
| chrisl | All the timeouts were on one machine | 08:36.14 |
| kens | Sounds like its broken then | 08:36.23 |
| | Ah, one of Alex's | 08:36.43 |
| | disable it and try again ? | 08:36.53 |
| chrisl | I'm doing a local run with the same source - if that completes okay, I'll disable the machine | 08:37.01 |
| | I mean, if that throws timeouts, I'll disable the machine | 08:37.52 |
| kens | :-) | 08:38.07 |
| | slushfile seems to be causing the problem, when we've gone off teh end of the file. Somehow its resetting the file back to an earlier state, so we have bytes available again | 08:39.46 |
| | s/slushfile/flushfile/ | 08:39.56 |
| | :-) I have a neat and easy fix, you were right about bytesavailable :-) | 08:41.55 |
| chrisl | So, everything else is messed up, but bytesavailable does something sane? | 08:47.18 |
| kens | Actually I'm not sure. It seems that by doing bytesavailable I'm getting an error on *every* PDF file, which is nt good. | 08:47.45 |
| chrisl | Some filters mean byteavailable does slightly odd things, IIRC | 08:48.23 |
| kens | Yes, bytesavailable is causing an error if I execute it immediately after setfileposition | 08:48.40 |
| | O.O | 08:48.46 |
| chrisl | That seems like a fairly normal thing to do.... | 08:49.07 |
| kens | Hmm, reading the spec I guess it is | 08:49.37 |
| | The stream is definitely screwed up after the first time we call setfileposition. It seems like flushfile resets the pointers back into the buffer, but doesn't update the position, so the stream code *thinks* its reading from way up at teh top of the file, but its not. | 08:55.01 |
| tor8 | morning Robin_Watts, paulgardiner | 08:56.24 |
| chrisl | kens: So how does it ever work? | 08:56.42 |
| NoOova | Hello all! | 08:56.51 |
| paulgardiner | hi tor8 | 08:56.52 |
| kens | chrisl as long as you don't ever go past the end of file, I think its fine | 08:56.58 |
| Robin_Watts | tor8: morning tor8. Just running out for a doctors appointment. back in a bit. | 08:56.59 |
| NoOova | Could i know how many pages PDF has? | 08:57.03 |
| | with ghostscript | 08:57.09 |
| tor8 | header split stuff up on tor/master | 08:57.10 |
| kens | NoOova, use pdf_info.ps I believe that tells you | 08:57.32 |
| tor8 | going to reorder some of the patches, but it's ready for looking and comments | 08:57.33 |
| NoOova | kens: thank you | 08:57.56 |
| tor8 | the fitz stuff is pretty much ready, the pdf split could do with some more work | 08:58.08 |
| kens | chrisl I think I'm beginning to see, it actually goes wrong earlier than I thought.... | 09:01.10 |
| | Burrowing into the PostScript.... | 09:01.24 |
| | Yeah, it thinks hte bytesavailable is silly before I even get to findxref | 09:02.53 |
| | OK the stream stuff is fine. The problem is that we consider a 'xref\ntrailer', ie a broken xref, to be 'vlaid' and simply ignore it. If we rebuild the xref instead its OK. | 09:38.16 |
| chrisl | That was intentional, wasn't it? | 09:39.17 |
| kens | Well.... its the exit condition for the loop, so I can't meddle with it (that is it processes each sub entry until it finds 'trailer') | 09:39.51 |
| | But a totally empty xref isn't valid, we should rebuild it, if we don't we get errors because we can't find any of teh objects | 09:40.14 |
| | OK found a fix, we can check to see if the number of defined objects is 0, if it is then we need to rebui,ld the xref. | 09:46.33 |
| | cluster push time | 09:47.18 |
| paulgardiner | tor8: definitely an improvement. One slight dislike though, that it has the impression of splitting textually but not necessarily modularly, in that still large groups of c files have access to all the inner details of many structures. | 09:48.30 |
| tor8 | paulgardiner: yes. many things still need to be moved to per-module headers that live with the source | 09:49.02 |
| | like I did for "draw.h" | 09:49.07 |
| paulgardiner | Ah right. That's future plans. | 09:49.14 |
| tor8 | it was a bit much to tackle in one evening :) | 09:49.27 |
| paulgardiner | :-) | 09:49.33 |
| tor8 | I think many functions and most structs could be taken out and hidden in per-module source headers | 09:50.06 |
| Robin_Watts | tor8: The header guards you've used are: #ifndef draw_h\n#define draw_h\n....#endif | 10:08.33 |
| | personally, I'd prefer DRAW_H | 10:08.47 |
| | defines being cALL_CAPS feels better to me. | 10:09.00 |
| | And possibly they should be FITZ_DRAW_H for sanity. | 10:09.39 |
| | (can be a future update - not suggesting we hold up the commit for this) | 10:10.12 |
| | ok, I've now looked over all of them, and they look like a great step in the right direction. | 10:13.44 |
| | go for it. | 10:13.52 |
| | paulgardiner, tor8: Are you here? | 10:21.17 |
| paulgardiner | yep | 10:21.23 |
| Robin_Watts | I've resurrected the progressive commit. | 10:21.37 |
| | In order to test it, I've got a -p flag to mupdf which you can use to set the number of bps with which the file arrives. | 10:22.20 |
| | So: "mupdf -p 1024 test.pdf" will simulate test.pdf arriving at 1024 bps. | 10:22.46 |
| | so when you first run the file you get a message back "not enough data to open the file" (or something like that) in an alert box. When you hit the OK button it retries. | 10:23.25 |
| | eventually you have enough information and the first page is displayed, then subsequent pages become accessible as the data arrives. | 10:23.52 |
| | The way it currently works is that the stream reading code throws a specific exception meaning "not enough data, try later". | 10:24.33 |
| | As far as I can see there are 2 possible ways to achieve progressive loading. | 10:25.29 |
| | One is to have the stream reading block until data arrives (which blocks everything), and the other is to have a way to bale out with a specific error meaning 'not enough data'. | 10:26.09 |
| | I've opted for the latter. | 10:26.17 |
| | but there is a slight problem, in that when the lower level stream reading code throws "not enough data", higher level functions can catch the exception, tidy up after themselves and rethrow a new exception (say "failed to parse dictionary"). | 10:27.16 |
| paulgardiner | I'll have a think about how this might fit into the Android app | 10:27.23 |
| Robin_Watts | so I've had to add bits of code in various catches to say "If I caught "not enough data" then make sure I throw "not enough data" again". | 10:28.00 |
| | I do wonder if it would be smart to treat the "not enough data" case as a special one. | 10:28.29 |
| | And have an 'fz_suspend()' call, which would do an fz_throw("Not enough data"); | 10:28.56 |
| | It would also set a flag internally to the error code, so that any subsequent throw would automatically be taken as a suspend. | 10:29.24 |
| | That way we wouldn't need to have special case code scattered everywhere. | 10:29.38 |
| paulgardiner | I don't know. Detecting and special-casing certain errors is not an unusual thing to do. | 10:31.21 |
| | I mean doing that within the general body of the code. | 10:31.37 |
| | Do you have to test with strcmp, or do we have error codes also? | 10:31.59 |
| Robin_Watts | My current patch adds error codes. | 10:32.09 |
| | The idea of not having to specifically add 'pass thru' code in every catch makes the special case suspend seem tempting. | 10:33.01 |
| paulgardiner | I guess I'm not completely understanding. I would have thought our common use of rethrow would handle most cases. | 10:34.59 |
| Robin_Watts | paulgardiner: If we only ever did catch() { rethrow() } then you'd be right, we'd be fine. | 10:35.30 |
| | but our code frequently does catch() { throw("some new error") } | 10:35.52 |
| | so we lose the fact that it was a TRYLATER error. | 10:36.14 |
| paulgardiner | I'm surprised we do that much | 10:36.32 |
| Robin_Watts | We do that everywhere. | 10:36.42 |
| paulgardiner | And for good reason? | 10:37.10 |
| Robin_Watts | We tend to rethrow with "more helpful" error messages at each stage. | 10:37.15 |
| | One possibility would be to add error codes, and to persist the error code when we throw from a catch ? | 10:37.46 |
| paulgardiner | Yes, unless explicitly overwritten | 10:38.08 |
| Robin_Watts | Or to set the top bit in the error code to mean "this is a persistent one, so subsequent throws should keep the same value" ? | 10:38.19 |
| paulgardiner | I guess we commonly change errors to "such-and-such function failed". Perhaps we shouldn't be doing that. | 10:39.05 |
| | It was okay when it was almost always memory allocation failure. | 10:39.33 |
| Robin_Watts | well, if we persist the error code, we can safely do that. | 10:39.35 |
| | I'm going to go for a run. Hopefully tor8 may have a chance to comment on this before I get back. | 10:39.52 |
| paulgardiner | But maybe it goes against typical use of exception handling | 10:40.09 |
| Robin_Watts | paulgardiner: If you have any further thoughts, please let me know. | 10:40.09 |
| | Current patch is on robin master if you want to look at it. | 10:40.57 |
| | observe places where I've had to add fz_pass_thru calls. | 10:41.24 |
| | paulgardiner: At the moment the android app is only invoked on fully downloaded files. | 10:49.36 |
| | Presumably we'd have to somehow be fed data as it arrives and would wrap that in something that can suspend. | 10:50.15 |
| | (i.e. throw) | 10:50.26 |
| paulgardiner | I have a nasty feeling blocking may turn out to be best for the Android app. Otherwise we'll be busy waiting | 10:51.58 |
| Robin_Watts | but blocking has problems. | 10:52.15 |
| | suppose the app asks for page 30 and we don't have page 30 yet. | 10:52.47 |
| | do we really want to block for ages? | 10:52.57 |
| | As a user I'd rather be able to say "forget that, I'll look again at the pages I do have". | 10:54.36 |
| paulgardiner | We wouldn't block the UI and we could provide the user with a get otu | 10:55.04 |
| | out | 10:55.06 |
| Robin_Watts | How could the user get out ? | 10:55.16 |
| paulgardiner | I was more imangining the page count incrementing as they wait | 10:55.42 |
| Robin_Watts | And having the throwing/suspension mechanism in place does not preclude us from blocking as an alternative. | 10:55.49 |
| | paulgardiner: But we don't know what byte ranges correspond to what pages. | 10:56.06 |
| | (in theory that information is in the hint stream, but no one can read hint streams (even acrobat doesn't!) and so you can't trust them.) | 10:56.39 |
| paulgardiner | Confused. Then how can you ever display a page (other than the first, which is special cased) without the whole doc | 10:57.14 |
| | ? | 10:57.15 |
| Robin_Watts | paulgardiner: You suck it and see. | 10:57.30 |
| | Linearized PDFs suck, m'kay. | 10:57.45 |
| | Linearised PDF is designed to allow the first page to be rendered quickly. The rest will be rendered when the whole thing finishes downloading. | 10:58.19 |
| | Try it in chrome. | 10:58.24 |
| paulgardiner | So should that be what we implement? | 10:58.58 |
| Robin_Watts | actually, I lie. Chrome does better. | 10:59.57 |
| paulgardiner | If there is some way to detect when pages are fully defined, then presumably a background thread could be working through the pages announcing the presence of each as it becomes ready | 11:00.44 |
| Robin_Watts | paulgardiner: We could have a background thread attempting to render each page in turn. | 11:01.29 |
| | but only one thing at a time can ever be reading from the file in MuPDF. | 11:01.42 |
| paulgardiner | Or load it at least | 11:01.49 |
| Robin_Watts | load requires the parsing of the content streams to check for resources like images etc. | 11:02.15 |
| | and we'd need to load each image etc too to see if it was there. | 11:02.27 |
| kens | chrisl ping | 11:02.43 |
| paulgardiner | Maybe that needs to change for this to be done properly... or at least we should think through how we'd do this if starting from scratch, even if we can't go there | 11:02.44 |
| Robin_Watts | paulgardiner: But regardless, we can only have 1 thread accessing the file at a time. | 11:03.16 |
| | so blocking on loading a page would prevent any other pages being loaded in the meantime. | 11:03.41 |
| paulgardiner | We can't have multiple threads reading? | 11:03.50 |
| Robin_Watts | paulgardiner: Indeed. | 11:03.57 |
| paulgardiner | A restriction on some OS's? | 11:04.18 |
| kens | general question, can anyone get Bugzilla to work ? | 11:04.22 |
| chrisl | kens: pong | 11:04.49 |
| kens | Can you get to any Bugzilla reprts ? | 11:04.57 |
| Robin_Watts | kens: bugzilla broken :( | 11:05.07 |
| chrisl | No "internal error......" | 11:05.08 |
| kens | All I get is a red screen with an error | 11:05.08 |
| | Ah so its not just me then | 11:05.13 |
| kens | feels better about that | 11:05.22 |
| Robin_Watts | paulgardiner: It's to do with our use of FILE *'s. | 11:05.24 |
| kens | Thansk chrisl | 11:05.35 |
| chrisl | np | 11:05.41 |
| paulgardiner | Robin_Watts: so maybe we need to change that to do this the best it can be done. | 11:05.59 |
| Robin_Watts | 2 threads seeking around in the file would bugger each other up. | 11:06.03 |
| paulgardiner | I thought each FILE handle held their own pointer | 11:07.00 |
| | s/their/its/ | 11:07.07 |
| Robin_Watts | paulgardiner: Indeed. | 11:07.22 |
| | and we have 1 FILE *. | 11:07.36 |
| | so if 2 threads want to use it we have contention. | 11:07.48 |
| | We don't access the file through FILE *'s though within mupdf, we use our fz_stream abstraction. | 11:08.30 |
| paulgardiner | I know we established that I wasn't the best of testers earlier, but it seems to be working for me now | 11:08.33 |
| | viewing bugs at least | 14:28.01 |
| tor8 | Robin_Watts: right. | 14:31.36 |
| Robin_Watts | using _impl.h clearly divides internal and external headers and avoids such collisions. | 14:32.03 |
| | did anyone hear anything from Miles about yesterdays meeting? | 14:32.40 |
| | Miles goes in for surgery tomorrow. | 14:32.57 |
| henrys | yes we'll talk about it at the meeting - there's not much news there still mulling | 14:36.49 |
| | they're | 14:37.00 |
| Robin_Watts | henrys: that in itself is good news though. | 14:37.08 |
| | better than "we've decided to go with a competitor". | 14:37.32 |
| henrys | yes of course | 14:37.54 |
| Robin_Watts | kens: Did you ever sort your headphones out? | 14:38.40 |
| kens | No :-( | 14:38.46 |
| | Hotel couldn't find them | 14:38.51 |
| Robin_Watts | kens: They are *such* tossers. | 14:39.01 |
| kens | Indeed..... | 14:39.07 |
| | Well, my fault | 14:39.11 |
| henrys | I ordered some bluetooth phones, can't wait to try them out. | 14:39.32 |
| Robin_Watts | henrys: which ones? | 14:39.42 |
| henrys | plantronics | 14:40.36 |
| | http://www.amazon.com/dp/B00AFGP5MM/ref=pe_385040_30332200_pe_309540_26725410_item | 14:40.53 |
| | how did I survive 3 marriages without a pair of those I ask myself? ;-) | 14:41.52 |
| Robin_Watts | by asking questions like that within earshot of your wives? :) | 14:42.22 |
| kens | 3 ? | 14:43.20 |
| henrys | well not counting duplicates, yes | 14:43.44 |
| kens | o.O | 14:43.51 |
| henrys | kens:did you see my questions about ocr and acrobat? | 14:43.59 |
| kens | err no, I'll look back, one moent | 14:44.11 |
| Robin_Watts | henrys: Presumably acrobat places "ignore" text over the image. | 14:44.24 |
| | so OCR doesn't change the appearance, it just adds searchability. | 14:44.46 |
| kens | henrys when/where did you ask your ocr question ? I don;t see it in the irc logs | 14:46.28 |
| henrys | Robin_Watts:okay that's what I thought the other possibility would be to make a bitmap font - type 3 of each character image. | 14:46.57 |
| Robin_Watts | henrys>kens:do you know offhand what acrobat does with ocr'ing images of text - I don't think it replaces the images - the files actually get larger. | 14:47.10 |
| | henrys: but every char might be subtlely different. | 14:47.36 |
| kens | Robin_Watts : it puts text over the top in text rendering mode err, 4 I think, no stroke and no fill. | 14:48.01 |
| Robin_Watts | kens: Right, in mupdf terms thats 'ignore' text | 14:48.21 |
| kens | That's the one yes. | 14:48.28 |
| | You can still search it in Acrobat | 14:48.37 |
| | But it makes no marks | 14:48.44 |
| | IIRC the GS text extraction device pulls it out as well. | 14:48.57 |
| dogisfat | Is there any documentation on the fields of the gx_image_plane_s structure? I have checked the drivers.html yet it only states that the structure needs to be initialized. I have also performed a search of all of the source documents... | 14:49.35 |
| kens | Did anyone get a gs-cvs email with my commit 95cd6ab ? | 14:50.30 |
| henrys | kens:on my list of wild crazy ideas is to get into ocr we do have a cross license opportunity to get an engine. | 14:50.33 |
| | kens:so I was just seeing what folks actually do. | 14:50.49 |
| kens | henrys, its not impossible. | 14:50.49 |
| Robin_Watts | dogisfat: It's defined in gxdevcli.h, but with no english text there. | 14:51.20 |
| kens | Like I said what Acrobat does is leave the image untouched as an image in teh PDF, then puts the OCR'ed text in 'no rendering' text mode on top. | 14:51.21 |
| Robin_Watts | const byte * data = pointer to the data. | 14:51.32 |
| | raster = Number of bytes to go from a pixel to the same pixel on the row below. | 14:51.58 |
| henrys | kens:it's been sitting on the dashboard for hours - I assume the casper problems are holding things up. | 14:52.21 |
| Robin_Watts | data_x = offset into data of the first pixel. | 14:52.42 |
| kens | henrys yes, but I didn't get the commit hook email either | 14:52.51 |
| Robin_Watts | where the units of data_x are not (necessarily) bytes. | 14:53.03 |
| kens | Fortunately I did run a test first, so I'm confident its OK :-) | 14:53.07 |
| kens | supposes the casper problem is stalling the email too | 14:53.21 |
| henrys | kens:yes lots of casper stuff seems to be broken | 14:53.24 |
| Robin_Watts | I did SMS marcos. | 14:53.34 |
| kens | henrys was that enough info on OCR ? | 14:53.46 |
| Robin_Watts | Interestingly if you type "borked" my phone corrects it to "Hitler". | 14:53.53 |
| kens | That's an interestin gone | 14:54.04 |
| | Not seen that before | 14:54.11 |
| henrys | kens:yes, I'll put it on the maybe agenda list in case we want to kick the idea around more. | 14:54.19 |
| Robin_Watts | "casper is Hitler :(" | 14:54.24 |
| chrisl | bugzilla seems to be working again | 14:56.28 |
| kens | Indeed it is, I update a bug status | 14:56.42 |
| henrys | marcosw sent mail | 14:56.59 |
| kens | Wow, a 100Gb temp file ! | 14:57.23 |
| henrys | didn't say how that got written | 14:57.42 |
| kens | No, I hope it wasn't me ..... | 14:57.51 |
| chrisl | Whoops that was me - although I can't fathom how it got created because casper cut me off when it was only a few bytes | 14:58.10 |
| kens | COffee time | 14:58.33 |
| chrisl | Normally if the tty dies, all processes associated with it are killed, too | 14:58.39 |
| henrys | ok mupdf meeting - the customer meeting went well, they feel we are the superior technical choice and the conversation is now focused on business. | 15:00.41 |
| Robin_Watts | henrys: Cool. Are they performing due diligence on us in the background then? | 15:01.26 |
| | (i.e. are there engineers scouring over our code at the moment? Is it worth us being in contact with such people if they are?) | 15:01.53 |
| henrys | no my understanding is they've already made the technical assessment. | 15:02.34 |
| Robin_Watts | excellent. | 15:02.47 |
| dogisfat | So are the units of data_x and the data contained within the data pointer are given in the gs_pixel_image_t pointer passed into _begin_typed_image? For a test image have bits per component of 8 and a number of components as 3 resulting in a depth of 24. How does that correlate to the stored data? | 15:03.13 |
| mvrhel_laptop | henrys: great | 15:03.22 |
| Robin_Watts | dogisfat: Presumably you're working in a planar manner there? | 15:04.20 |
| | so a plane of R, a plane of G and a plane of B. | 15:04.39 |
| | hence data_x is in bytes in this case, probably. | 15:04.49 |
| henrys | so status of signatures openssl bloat etc.? | 15:04.51 |
| | mvrhel_laptop: I sent you an email that you submitted the wrong phone number for me. Did you see that. | 15:05.59 |
| | ? | 15:06.01 |
| mvrhel_laptop | henrys: yes. I got that number off the contact list | 15:06.15 |
| | sorry about that | 15:06.20 |
| henrys | oh I should change that I don't know where that number came from. | 15:06.55 |
| mvrhel_laptop | when is that last time Joann sent out a contact list | 15:06.58 |
| Robin_Watts | Is there a version with paulgardiner included? | 15:07.21 |
| henrys | Are these clown demanding this of every submitter to the app store? | 15:07.21 |
| paulgardiner | henrys: I'm in the process of updating some of the functions that create and alter annotations, so that they play well with the new xrefs with separated sections | 15:07.24 |
| mvrhel_laptop | henrys: apparently. for companies not individuals | 15:08.28 |
| | they don't want some yahoo to claim they are some company that they are not | 15:08.59 |
| henrys | paulgardiner: oh okay yes. | 15:09.05 |
| mvrhel_laptop | also, I had to pay $99 to register | 15:09.08 |
| | and had to jump through some credit card security tricks | 15:09.32 |
| henrys | I'm using the agenda for the Tuesday meetings now, I don't see much to address there, and can't think of any other topics. Does anyone else have meeting like stuff or should we cut it short this time? | 15:10.38 |
| paulgardiner | henrys: will need to do the same for the form-field code too, and then change the saving code to support writing just the most recent xref section to the end of the existing file | 15:10.53 |
| mvrhel_laptop | I have files opening through skydrive now and I am going to get it so that mupdf will work as the default app (if selected) or if they do an open with. | 15:11.07 |
| henrys | mvrhel_laptop: what are individual charged? | 15:11.21 |
| mvrhel_laptop | $49 I think | 15:11.28 |
| Robin_Watts | henrys: If we get the customer deal that's just been discussed, there are a couple of things we'll need to get into the code post-haste. 1) Progressive loading, 2) JNI bindings. | 15:12.01 |
| | I think they were the only things in the list that we didn't have ready to go. | 15:12.34 |
| mvrhel_laptop | I have a contact at MS who may be able to help me crack that xap file so that we can check if for certain strings if we desire. I was not happy to see that on the windows phone site | 15:13.25 |
| Robin_Watts | mvrhel_laptop: Do MS have a 'this app is infringing, please remove it' link ? | 15:13.58 |
| paulgardiner | Robin_Watts: were those two items necessary before initial delivery or could they be part of the subsequent work? | 15:14.03 |
| henrys | Robin_Watts:lf we get the deal then that can become the focus of the entire group and I'm sure it will get done quickly. | 15:14.05 |
| | are you worried about it. | 15:14.10 |
| mvrhel_laptop | Robin_Watts: I am certain they do | 15:14.13 |
| | Do we know if these guys are customers | 15:14.38 |
| henrys | s/\./\?/ | 15:14.39 |
| Robin_Watts | henrys: delivery of the code would be for "as part of a release in the latter half of 2013" | 15:14.46 |
| | and you have to assume that that will mean they'll want it in time to get it QAd etc. | 15:15.02 |
| mvrhel_laptop | whoa that is coming up real quick | 15:15.11 |
| Robin_Watts | so we probably ought to be thinking about it in advance. | 15:15.14 |
| | mvrhel_laptop: yeah! | 15:15.16 |
| dogisfat | Robin_Watts: The num_planes value for the image contains a value of 1 as defined in the gx_image_enum_procs_s. I think the image was not broken into color planes. | 15:15.51 |
| Robin_Watts | dogisfat: Then probably the units are '3 bytes'. | 15:16.19 |
| dogisfat | Robin_Watts: Ok, is there anyway to programmatically determine this? | 15:17.11 |
| Robin_Watts | henrys: I spent yesterday playing with the progressive code I have, and that's what lead to the discussion on the error stuff this morning. | 15:17.11 |
| | dogisfat: You should be able to get it from context somehow. | 15:17.44 |
| | but I don't know how offhand. | 15:17.50 |
| dogisfat | Robin_Watts: Thank you, I will investigate. | 15:18.19 |
| Robin_Watts | henrys: should we add those 2 things to the agenda ? | 15:18.19 |
| | s/agenda/workflowy/ | 15:18.30 |
| mvrhel_laptop | Robin_Watts: so there is a report concern but nothing about infringing on the list | 15:19.06 |
| | I will ping a friend at MS to see | 15:19.22 |
| henrys | yes, I'll put it in. A decision is imminent so I'm not that concerned about it. Worrying about it now give you only a couple more days to worry as I understand it. | 15:19.29 |
| tor8 | Robin_Watts: how far along is the progressive loading? is the error code return the main thing left, to make it behave better in the face of other actual errors (i.e. not EAGAIN) | 15:19.39 |
| Robin_Watts | mvrhel_laptop: ok. We ought to buy a copy of the full version, and then send them an email demanding their source. | 15:19.44 |
| | tor8: I think that's all that's left. | 15:19.59 |
| mvrhel_laptop | well , the one is free and I already downloaded it. | 15:20.04 |
| Robin_Watts | mvrhel_laptop: Right, me too. | 15:20.15 |
| mvrhel_laptop | I will buy the pro version too and then ask for the source for that | 15:20.23 |
| tor8 | Robin_Watts: right. that shouldn't be more than a couple of afternoons to track down and fix the thow/rethrow thing we discussed. | 15:20.30 |
| Robin_Watts | tor8: no, I'm going to do that now. | 15:20.45 |
| tor8 | which leaves us with the bigger task of designing a JNI interface | 15:20.47 |
| | Robin_Watts: updated header branch on tor/headers | 15:21.07 |
| henrys | progressive is already on the agenda? | 15:21.07 |
| mvrhel_laptop | Robin_Watts: are we sure that they are not a customer. | 15:21.11 |
| henrys | right? | 15:21.12 |
| tor8 | uppercased and rearranged to reduce the time the build is broken | 15:21.24 |
| Robin_Watts | tor8: right. henrys: it is? ok, sorry | 15:21.43 |
| henrys | I added the JNI bindings. | 15:22.03 |
| Robin_Watts | mvrhel_laptop: If they were a customer they would not be advertising it as GPL. | 15:22.05 |
| mvrhel_laptop | ah ok | 15:22.25 |
| | I am going to ping my contact at MS then too | 15:22.32 |
| Robin_Watts | How do people feel about adding code within mupdf to allow us to spot that it's mupdf in use ? | 15:23.08 |
| tor8 | Robin_Watts: any ideas? | 15:23.24 |
| Robin_Watts | needn't be big. | 15:23.28 |
| tor8 | it'd have to be something that's non-trivial to spot and remove though | 15:23.38 |
| Robin_Watts | we could accept %MUPDF- as well as %PDF as a header. | 15:23.51 |
| mvrhel_laptop | Robin_Watts: I liked your idea of being able to read in something like .. yes exactly | 15:24.01 |
| Robin_Watts | or if /Root was missing accept /MuRoot ? | 15:24.08 |
| henrys | tor8:have you done any study of the OpenGL stuff? | 15:24.32 |
| Robin_Watts | tor8: That'd be easy to remove, but I guarantee you 99% of people wouldn't bother. | 15:24.36 |
| tor8 | Robin_Watts: hard to say conclusively that either of those aren't just lax readers doing repairs | 15:24.45 |
| | Robin_Watts: what about in the presence of /MuPDF toss an error? | 15:25.11 |
| Robin_Watts | tor8: Could do. | 15:25.30 |
| tor8 | henrys: yes, I have spent a couple of days reading papers and gl extensions | 15:25.40 |
| | waiting for delivery on a new computer which will have an nvidia graphics card | 15:25.54 |
| paulgardiner | Wouldn't it be better if it didn't have the string "mu" in so that it would look like handling a legitimate special case | 15:25.55 |
| Robin_Watts | until some malicious generator of PDF files decides they don't like us, and wants to avoid us being used to read files. | 15:26.02 |
| henrys | tor8:what are you getting? | 15:26.10 |
| tor8 | a new haswell based i5 computer with an nvidia gt 640 | 15:26.28 |
| | the most recent nvidia card with passive cooling | 15:26.37 |
| | I'm hoping to do the opengl development on a pure linux machine | 15:27.02 |
| | opengl doesn't work very well in virtualbox, and debugging graphics code on windows is a nightmare | 15:27.19 |
| | hence me setting up another box | 15:27.31 |
| Robin_Watts | tor8: You've gone for "draw-imp.h" rather than "draw_imp.h" | 15:27.52 |
| tor8 | Robin_Watts: yeah. we went with dashes in the other header files too. you going to bring up iso9660 again? :) | 15:28.32 |
| | I'm flexible | 15:28.39 |
| henrys | tor8:well it should be an interesting project - what about differences between open-gl and OpenGL ES? | 15:28.40 |
| Robin_Watts | no, if that's the decision we've made, I can live with it. | 15:28.46 |
| | As long as we are consistent. | 15:28.51 |
| tor8 | Robin_Watts: well, we do have _ in the prefix_module.c names so we're not very consistent | 15:29.07 |
| | shall I change to underscores (and ignore sebras complaints about shifting)? | 15:29.29 |
| Robin_Watts | within C for symbols we have to use _. | 15:29.37 |
| | Within filenames we can use - or _, but should be consistent. | 15:29.47 |
| | aesthetically, I think I prefer -. | 15:29.55 |
| | but my sense of consistency says _. | 15:30.07 |
| | so I don't really care as long as we pick one and stick to it. | 15:30.25 |
| tor8 | Robin_Watts: when we (hopefully soon) rearrange the source files we can drop the xxx_module prefixes | 15:30.29 |
| henrys | tor8:the new Mac Pro looks interesting. I can't believe it 1/8 the size of what I have now. But this beast has gone quite some time without an upgrade. | 15:30.32 |
| Robin_Watts | tor8: woo hoo! | 15:30.38 |
| tor8 | and then - would be consistent in all file names | 15:30.38 |
| | henrys: the trash can? | 15:30.45 |
| henrys | yes | 15:30.53 |
| Robin_Watts | henrys: but it's a toaster, right? | 15:30.55 |
| kens | *designer* trash can please :-) | 15:31.01 |
| Robin_Watts | No scope for expansion at all. | 15:31.07 |
| tor8 | Robin_Watts: expansion is all to be done by external units plugged in via cables | 15:31.27 |
| Robin_Watts | except by USB etc, so it'll look like it's on lifesupport. | 15:31.33 |
| tor8 | defeating the whole "designer" trash can ideal with a snake nest of cables... | 15:31.38 |
| henrys | if it's 1/8 the size I don't really care what it looks like. | 15:31.44 |
| kens | henrys you will after you plug 10 units into it | 15:31.59 |
| tor8 | Robin_Watts: woo hoo to dropping the prefix? | 15:32.03 |
| henrys | what do I need to add to it? | 15:32.11 |
| Robin_Watts | henrys: right, but by the time you've added 2 external harddrives and their powerbricks etc... | 15:32.19 |
| kens | I have no idea, but I'll bet you will | 15:32.23 |
| Robin_Watts | tor8: indeed. | 15:32.28 |
| tor8 | almost all usb-3 external drives need power bricks :( | 15:32.38 |
| Robin_Watts | henrys: And what about when you want that mid-life graphics card update... | 15:32.45 |
| tor8 | Robin_Watts: then let's do that next :) | 15:32.55 |
| kens | Is it possible to upgrade the graphics ? | 15:33.17 |
| Robin_Watts | kens: Yes. You go to the apple store, and they take your old one away, plus a kidney and they give you a new one. Then they take your spleen for transferring your software across, some of which may even still work. | 15:34.06 |
| tor8 | kens: nope. that's probably the biggest gripe people have with the trashcan. | 15:34.08 |
| kens | LOL an immediate differenc fof opinion :-) | 15:34.22 |
| Robin_Watts | kens: I think we were actually in total agreement there :) | 15:34.41 |
| henrys | By the time I need a new graphics card for that I'll want a new workstation | 15:34.56 |
| kens | Yes == no ? | 15:34.58 |
| Robin_Watts | kens: You sell your old one, you buy next years. | 15:35.11 |
| kens | :-) | 15:35.22 |
| | I don't buy apple, so not a problem for me | 15:35.33 |
| henrys | I have thought about a switch back to Linux | 15:36.49 |
| | recently | 15:36.52 |
| kens | Windows 8 is pushing me that way too | 15:37.02 |
| | If it had a decent debugger I'd probably migrate | 15:37.19 |
| henrys | yea I don't know if MS is going in any better direction than apple. | 15:37.42 |
| tor8 | kens: how is lldb shaping up? (the llvm based debugger) | 15:37.59 |
| kens | No idea, I only use ddd at the moment | 15:38.14 |
| | WHich drives me nuts | 15:38.22 |
| | And is still the best option that I know of | 15:38.31 |
| chrisl | tor8: lldb is a replacement for gdb, isn't it? Still no worthwhile GUI? | 15:38.47 |
| tor8 | chrisl: I haven't checked, but given that it's not under RMS maintainership there may actually be some hooks that make it easy to write GUIs on top of it. | 15:39.28 |
| kens | It says its the default debugger in XCode on the Mac | 15:40.09 |
| chrisl | tor8: that's possible, although I don't think RMS has been active on gdb for many years, and the current maintainers still don't bother :-( | 15:40.28 |
| kens | Lots of stuff about how wonderful a ddebuggger it is, no indication of GUI | 15:40.48 |
| | Ah, it appears to be all command line driven, just like gdb | 15:41.23 |
| tor8 | Robin_Watts: okay, do a double check on tor/headers and when you give the ok I'll push | 15:41.33 |
| | if you can test the android and winrt builds that'd be swell! | 15:41.48 |
| chrisl | kens: will probably work with ddd then! | 15:41.52 |
| kens | chrisl, yes but that doesn't really help...... | 15:42.03 |
| | Oh actually, the command line is comletely different. THey claim its much better | 15:42.25 |
| Robin_Watts | tor8: It's changed in the last 5 mins? | 15:42.58 |
| tor8 | I think I fixed the android and winrt builds in a squash in the last 5 mins | 15:43.16 |
| Robin_Watts | so it has. | 15:43.17 |
| tor8 | the "Merge common and internal" patch has fixes | 15:43.25 |
| | and there's a rename-the-generated-header-files patch as well | 15:43.36 |
| | with -I$(GEN) I'm afraid of header file name conflicts | 15:43.54 |
| | (and we want -I$(GEN) for an eventual source layout shuffle) | 15:44.09 |
| Robin_Watts | Looks good to me. | 15:44.22 |
| | go for it. | 15:44.28 |
| tor8 | now we wait and watch zeniko cry... :) | 15:45.00 |
| Robin_Watts | We could send him an email and warn him that large changes are coming, so he might want to hold off for a few days? | 15:46.03 |
| tor8 | yeah. will you? | 15:46.19 |
| Robin_Watts | ok. | 15:46.24 |
| tor8 | given that we'll probably do the source shuffle the next couple of days as well... | 15:46.34 |
| | he might prefer the pain of one hit at once | 15:46.44 |
| henrys | has anybody experience eclipse c debugging | 15:47.02 |
| | ? | 15:47.03 |
| chrisl | I tried it, couldn't make it work. And it doesn't give access to the debugger command line | 15:47.36 |
| henrys | it seems to have mouseover | 15:47.46 |
| chrisl | When I looked, it had no way to set global watch points, no way to expand macros, and a couple of other missing things which I use regularly | 15:48.24 |
| henrys | another release is due this month - the CDT that is. | 15:51.07 |
| chrisl | henrys: I remember now: there was some messing around needed to use the eclipse debugger if your project is built outside the eclise IDE, and I couldn't get that to work reliably. | 15:57.29 |
| henrys | it works pretty well for python I've found, I can't imagine it working for something large like gs. | 15:58.45 |
| | the usual java glacier bloat | 15:59.12 |
| | so now a gs meeting... | 15:59.40 |
| | seems like __SSE__ is defined in gcc chrisl at least it enabled on my linux box for openjpeg | 16:00.39 |
| chrisl | henrys: okay, that's more difficult to disable then | 16:01.36 |
| | henrys: is there a reason you'd want to disable it if the compiler says it's there? | 16:02.47 |
| henrys | With alex leaving I sort of browsed over some stuff of his stuff like say gs_init.ps, and was immediately struck with why do we need 1/2 this stuff. Does anyone really configure ghostscript using gs_init.ps? | 16:03.40 |
| | chrisl:I don't know I assume if somebody wants to turn it off they will and it will be turned off in gs and not in openjpeg which I find odd. | 16:04.28 |
| kens | henrys *nobody* touches gs_init.ps to the best of my knowledge, though Ray may know differently. I include us in that nobody too | 16:05.08 |
| chrisl | henrys: IIRC, there isn't a standard way to override compiler built-ins like that. | 16:05.15 |
| henrys | a more specific example why redefine setdash? other than too gobble up resources. | 16:05.28 |
| kens | henrys we do that sort of thing all o ver the place, there are sometimes reasons.... | 16:05.50 |
| | Looks to me like that is intended to do argument checking that teh original setdash doesn't do | 16:06.37 |
| | If it was me, I'd have added teh argument checking in C, but then that's my preference. | 16:06.54 |
| henrys | well I see very big reasons to get rid of as much as we can - rom bulk, interpreting stuff that need not be ... | 16:06.58 |
| kens | henrys the comment does say its for compatibility with Adobe interpreters | 16:07.15 |
| | Ah, I see. | 16:07.36 |
| henrys | kens:what other interpreters do we care about. | 16:07.37 |
| | ? | 16:07.40 |
| kens | Its limiting the number of arguments in the array to 11 | 16:07.46 |
| Robin_Watts | If we're "better" than Adobe ones, do we care? (i.e. if we accept more entries than Adobe, do we care that we don't give an error when they do?) | 16:08.08 |
| kens | Which is vital at present as we have that fixed in a lot of places. Robin has a enhancement to srot it out | 16:08.13 |
| ray_laptop | kens: we had a few customers that would put special default customizations in gs_init.ps. A few years ago I started encouraging them to do it via extra init files that are run using args | 16:08.21 |
| chrisl | Robin_Watts: a lot of QL tests can "fail" if you don't throw an error at the same time when CPSI does | 16:09.00 |
| kens | Robin_Watts : personally I would be very happy to lift the '11 arguments' limit, but its baked into the clist and pdfwrite | 16:09.02 |
| ray_laptop | more than Adobe's "Implementation limits" is fine I think | 16:09.03 |
| Robin_Watts | chrisl: I repeat: do we care? | 16:09.22 |
| kens | The dash array is a fixed size (11) array of floats inside some structures | 16:09.36 |
| ray_laptop | kens: is it coded as "11" or does it use some kind of #define | 16:10.02 |
| henrys | which we don't want to do anyway. But everything I read in gs_init.ps is of that ilk. We simply don't need this crap and it's a performance and maintenance burden. You can't profile it, debug it⦠and nobody speaks postscript anymore. | 16:10.05 |
| kens | ray_laptop : its a #define | 16:10.11 |
| | But..... | 16:10.15 |
| Robin_Watts | If we say "We pass all QL tests, except for ones where we fail because we exceed the expectations of the test." is anyone going to hold that against us? | 16:10.26 |
| kens | The current spec has no limit (its a level 1(!!!) limit) | 16:10.29 |
| chrisl | Robin_Watts: well, I don't, but there was sufficient care here that I had to spend weeks making sure the move to 64 bit integers would be done in such a way we could pass those tests. | 16:10.37 |
| kens | Robin_Watts : customers *do* complain about that, and it takes time to explain it to them in very small words. | 16:10.50 |
| ray_laptop | kens: so it sounds like we should make those dynamic arrays | 16:10.55 |
| kens | but I'm in favour of that approach myself | 16:10.58 |
| | ray_laptop : yes, that's what Robin_Watts's enhancement is for | 16:11.13 |
| | NB we already exceed Adobe interpreters with arrays I think, since Alex opened those up beyond 64k entries | 16:11.43 |
| henrys | I really don't care about setdash the point is whatever you want to do can be moved to C | 16:11.55 |
| kens | henrys, I would rather see argumetn checking in C, yes | 16:12.09 |
| | The way we are now, some in PostScript soem in C is desperately confusing | 16:12.37 |
| Robin_Watts | If setdash fails, the error raised is presumably a postscript one. | 16:12.55 |
| kens | Robin_Watts : yes ? | 16:13.02 |
| henrys | We really pay for all this crap - the space - every time we start up we interpret all this stuff only to get an answer we knew before we started. | 16:13.05 |
| Robin_Watts | so perhaps it's easier to code the raising of that error in PS than C? | 16:13.23 |
| ray_laptop | I agree that moving arg checking to the z functions in the interp makes sense | 16:13.30 |
| kens | Robin_Watts : no, not really, we return PostScript errors from C all the time | 16:13.36 |
| Robin_Watts | Fair enough then. | 16:13.49 |
| chrisl | Ironically, it's probably harder to raise a PS error from PS than from C | 16:14.19 |
| kens | Indeed, it requires us to use signalerror | 16:14.44 |
| | instead of simply returning a enumerated error | 16:14.57 |
| henrys | if you go through gs_init.ps there are many more examples, if we could gradually start moving that stuff to C or getting rid of it since much of it is very old we could put a significant dent in startup ... | 16:15.12 |
| kens | henrys I'm happy with that, but I have enough to do right now :-) | 16:15.29 |
| henrys | yes as time permits - I may look at it too and I'll ask you guys for review if I do anything the PCL business is getting slow. | 16:16.04 |
| | I meant to ask at the MuPDF meeting if sebras got his NDA? | 16:17.51 |
| | kens:did chrisl look at the eps write gc problem, that should be fun? | 16:19.24 |
| chrisl | I haven't yet, no | 16:19.49 |
| henrys | chrisl:not sure what to do __SSE__ - I was building a function call tracer with gcc specifics and it didn't like SSE for some reason. | 16:21.23 |
| | other meeting stuff? | 16:21.59 |
| chrisl | henrys: well, to start with, I can make it so --disable-sse works on gcc - we can worry about other compilers if someone asks | 16:22.10 |
| kens | henrys I was planning to modify the ps2write device to accumulate its own bounding box, because otherwise I will throw my PC out of a nearbly window. Trying to get the devices to play together was too frustrating | 16:22.32 |
| henrys | kens:years ago I ripped the bounding box out of pcl - it's a chinese finger puzzle. | 16:23.26 |
| kens | Well, its trying to get two devices to play together that's the problem, bbox I understand | 16:23.51 |
| | Then enumerators were driving me up the wall | 16:24.00 |
| | But ps2write/pdfwrite have to know about all sorts of stuff, so I think accumulating a bbox should be possible | 16:24.30 |
| | Might have to guess at y extents for text though | 16:24.45 |
| henrys | yes pcl used bbox as a forwarding device it is fine as an output device, that is easy - sticking in a chain of devices is the hell part | 16:25.13 |
| kens | Yes, that's what I found, it works OK if you are a low level device, it doesn't work at all for high level devices | 16:25.38 |
| | Becuase of the text enumerator business | 16:25.52 |
| ray_laptop | kens: can't you collect the position for the extents in the text enum end ? | 16:30.42 |
| Robin_Watts | tor8: I'm getting compile failures on windws. | 16:31.05 |
| kens | ray_laptop : If I do that in pdfwrite, I may as well do all the extents in pdfwrite. | 16:31.17 |
| | (which is what I plan) | 16:31.23 |
| Robin_Watts | mostly to do with the javascript stuff - I'm guessing you don't have v8 installed ? | 16:31.26 |
| ray_laptop | kens: even when it's a high level device, we have to update the currentpoint in the graphics state | 16:31.33 |
| Robin_Watts | Also, can't find gen_cmap_cns.h and gen_font_base14.h | 16:31.44 |
| henrys | okay 9:30 have a good day everyone! | 16:31.47 |
| kens | ray_laptop : yes, but that only affects the x extent, nto the y extent | 16:31.49 |
| | (unless its a vertical font) | 16:32.05 |
| Robin_Watts | Should the pdf headers include the fitz headers they rely on ? I'd say yet. | 16:32.12 |
| ray_laptop | kens: oh, you mean the character height, right | 16:32.12 |
| Robin_Watts | s/yet/yes/ | 16:32.15 |
| kens | ray_laptop : yes exactly | 16:32.18 |
| | the bbx device looks at the bitmaps, obviously pdfwrite can't do that | 16:33.01 |
| ray_laptop | Robin_Watts: sounds like a good way to work it. I hate the way gs only does that sometimes | 16:33.08 |
| | kens: right. | 16:33.34 |
| tor8 | Robin_Watts: agh. the win32/generate.bat fix was incomplete... | 16:34.11 |
| henrys | mvrhel_laptop: is there more auto color mode stuff to do ? | 16:34.42 |
| mvrhel_laptop | henrys: I think ray_laptop was taking care of the planar (multiple sources case). | 16:35.09 |
| ray_laptop | henrys: yes | 16:35.19 |
| mvrhel_laptop | ray_laptop: it sounds like they are a little confused | 16:35.25 |
| ray_laptop | I am going to do it and just consult mvrhel_laptop if needed | 16:35.34 |
| henrys | oh okay we agree that should be P1 yes? | 16:35.55 |
| tor8 | Robin_Watts: fix up on tor/master | 16:35.55 |
| ray_laptop | mvrhel_laptop: I hadn't read their reply yet -- sounds like they are willing to go without the change | 16:36.43 |
| | which makes it easier for me ;-) | 16:36.54 |
| mvrhel_laptop | yes :) | 16:36.59 |
| Robin_Watts | tor8: Ah, so you're still using fitz.h etc, rather than individual requirements in the headers as yet ? | 16:37.41 |
| chrisl | kens: I think I have a fix for 694318 - need to clusterpush, but that'll be tomorrow | 16:37.47 |
| kens | chrisl I'm impressed! | 16:37.58 |
| chrisl | I've been digging in pdfwrite, I'm less than impressed...... | 16:38.25 |
| tor8 | Robin_Watts: in the sources, yes... | 16:38.29 |
| kens | chrisl join the party | 16:38.34 |
| tor8 | each header compiles on its own, so dependencies on each sub-header is good | 16:38.49 |
| Robin_Watts | tor8: And in the include headers. | 16:38.50 |
| chrisl | kens: less of a party, more support group, I think! | 16:38.57 |
| Robin_Watts | tor8: Urm... | 16:38.58 |
| tor8 | except in the pdf split | 16:39.01 |
| kens | :-) | 16:39.03 |
| mvrhel_laptop | henrys: I have a few issues still to track down on the overprint bugs 694295 and 694296 for some reason I am getting segvs during clusterpush but not locally on my builds here (including 64 bit linux debug build) | 16:39.06 |
| Robin_Watts | Ah, it was the pdf ones I was looking at :) | 16:39.12 |
| tor8 | since I'm less confident about where to draw the lines on the pdf splits | 16:39.21 |
| | they were a lot less obvious than the fitz ones | 16:39.26 |
| | and the dependencies are a bit icky | 16:39.32 |
| chrisl | kens: anyway, I'll stick it up for review tomorrow. | 16:39.34 |
| Robin_Watts | OK, your fix solves building. I'll push it. | 16:39.35 |
| henrys | mvrhel_laptop: do you know what machine? | 16:39.50 |
| kens | chrisl no problem, I'm finishgin now anyway, had enough for one day, picking my way through the PDF interpreter | 16:39.52 |
| | Night all | 16:39.59 |
| chrisl | nite kens | 16:40.04 |
| ray_laptop | bye, kens | 16:40.06 |
| henrys | mvrhel_laptop: just thinking it could be macpro | 16:40.09 |
| mvrhel_laptop | henrys: let me redo a couple things and see where I am | 16:40.14 |
| | I got frustrated and took a break for a couple days from it | 16:40.40 |
| henrys | mvrhel_laptop: marcosw can probably help too. | 16:40.42 |
| mvrhel_laptop | ok | 16:40.57 |
| ray_laptop | mvrhel_laptop: it's not correlated to particular machines is it ? | 16:41.11 |
| mvrhel_laptop | ray_laptop: don't know, I need to do a bit more checking | 16:41.32 |
| ray_laptop | mvrhel_laptop: I see your most recent regression. It's definitely not specific to a single machine | 16:42.32 |
| | mvrhel_laptop: a few of the segfaults were on peeves, so you can log in and try and duplicate it | 16:43.23 |
| mvrhel_laptop | ray_laptop: ok. well like I said it has been a few days. I need to do a little more testing here before I waste anyones time | 16:43.44 |
| ray_laptop | or miles if you want to do x11 debugging | 16:43.49 |
| mvrhel_laptop | ray_laptop: ok thanks. lets wait on that for a bit | 16:43.59 |
| ray_laptop | mvrhel_laptop: np. | 16:45.09 |
| marcosw | henrys: sorry, lost track of time and missed the meeting, I'll read the logs... | 16:47.02 |
| chrisl | mvrhel_laptop: these pdfwrite and ps2write memory corruptions I've been working on disappeared using an up to date gcc (I've for 4.7.2 here), I had to build with 4.4.x or 4.5.x to see the crashes | 16:47.06 |
| mvrhel_laptop | chrisl: ick | 16:47.46 |
| | I will check my gcc version. | 16:48.05 |
| chrisl | yeh, clearly the newer compilers moved memory around enough to "hide" the problem. | 16:48.18 |
| | marcosw: sorry about the casper thing - I still can't fathom a normal process continuing with no tty attached...... | 16:48.55 |
| | henrys: okay, I've got configure changes which disable the openjpeg SSE code when using gcc - I'll commit it tomorrow. | 16:49.53 |
| sebras | chrisl: would you mind setting your git repo on casper to be exported? I'm unable to clone it. :) | 16:49.55 |
| chrisl | sebras: my ghostpdl one? | 16:50.16 |
| marcosw | chrisl: yeah, that shouldn't happen. in any case, I've set a limit of 10gigs as the maximum file size in /etc/security/limits.conf, so it can't happen again. | 16:50.16 |
| sebras | or I was a few days ago at least. | 16:50.16 |
| | chrisl: no the mupdf one! I never dabble in gs. :) | 16:50.28 |
| tor8 | touch /home/chrisl/repos/mupdf.git/git-daemon-export-ok | 16:50.41 |
| chrisl | Yeh, just doing that now..... | 16:50.57 |
| sebras | tor8: you are typing in the wrong window... | 16:51.08 |
| chrisl | tor8: does it take effect immediately, do you know? | 16:51.46 |
| sebras | chrisl: it does. thanks! :) | 16:52.12 |
| chrisl | Cool | 16:52.17 |
| | sebras: although, you won't find anything interesting in there! | 16:53.15 |
| henrys | marcosw:any hope of you getting your design jet to work soon. I can't reproduce the customer problem with the 3rd party HPGL solution I have, it prints as we do. | 16:53.30 |
| marcosw | tor8 and Robin_Watts: there are some mupdf commands that allocate a lot of memory (i.e. gigs). For example: "mupdf/build/debug/mudraw -r200 -o test.ppm ./Bug692174.pdf" allocates 4.8 gigs. Is this reasonable? | 16:53.39 |
| henrys | marcosw:it's difficult to cut down the file and know I haven't deleted the problem if I can't reproduce it. | 16:54.06 |
| Robin_Watts | marcosw: Yes. | 16:54.07 |
| marcosw | henrys: I've ordered a new power supply (it doesn't power on at all, so I suspect that's the problem). | 16:54.15 |
| sebras | chrisl: not now maybe, but possibly tomorrow... | 16:55.18 |
| ray_laptop | marcosw: that file has a MediaBox of 10199 x 6496 but no transparency | 16:55.23 |
| marcosw | Robin_Watts: so these jobs may start to fail; in addition to setting file size limits on casper I've set a 4 git virtual memory limit on each of the cluster nodes since some of the valgrind/fuzzing issues allocate all of the memory before failing and I'm tired of having cluster nodes falling over when that happens (this is why the cluster has been so flakey the last day or so). | 16:56.16 |
| ray_laptop | marcosw: so that's only 1.4G at 200 dpi (for the bitmap) | 16:56.44 |
| Robin_Watts | ray_laptop: 4 components, not 3. | 16:57.00 |
| | so 2Gig. | 16:57.04 |
| ray_laptop | Robin_Watts: right. But not 4.8 | 16:57.20 |
| Robin_Watts | Plus any other things needed to render it (image buffers etc?) | 16:57.39 |
| ray_laptop | Robin_Watts: does mupdf still do the dumb thing with images and load the entire image rather than processing from the stream ? | 16:58.31 |
| Robin_Watts | mupdf does lots of smart things with images, but yes, it still decodes them in their entirety unless it can safely subsample them. | 16:59.12 |
| marcosw | henrys: btw, I don't know if you noticed it, but the missing image in the customer HPGL file is actually not missing, it's just drawn in the wrong place. | 16:59.46 |
| ray_laptop | Robin_Watts: I thought tor or somebody was going to fix it so that images didn't have to be buffered in entirety | 17:00.07 |
| Robin_Watts | ray_laptop: We'd have to rewrite all sorts of stuff for that. | 17:00.38 |
| ray_laptop | Robin_Watts: I was write. Another thing that never got done. http://bugs.ghostscript.com/show_bug.cgi?id=690665 | 17:02.38 |
| henrys | marcosw:no I didn't notice that. I'll look more carefully I thought we were missing a fill in the map | 17:02.48 |
| ray_laptop | still hasn't 'ripened' -- it's only from 2 years ago | 17:03.21 |
| Robin_Watts | ray_laptop: We have made various improvements in the last 2 years. | 17:04.04 |
| | but we still essentially decode -> pixmap then scale pixmap then plot pixmap. | 17:04.26 |
| | The pixmaps can be many times smaller now than they could before, but they are still whole images. | 17:05.03 |
| marcosw | henrys: it seems to only happen at certain resolutions, I'll try to add a comment to the bug. | 17:07.01 |
| henrys | ah resolution dependent positioning of the raster, I bet that is it. | 17:07.45 |
| marcosw | henrys: off course now I can't reproduce it :-( | 17:12.57 |
| henrys | marcosw:right at 600 dpi I see it. | 17:25.55 |
| mvrhel_laptop | whew. finally have the open with stuff working now and mupdf can be the default pdf/xps/oxps/cbz app for windows 8 and it works across skydrive | 17:57.06 |
| | Robin_Watts: I will probably have a commit for you to review later today | 17:57.19 |
| | or in your morning | 17:57.26 |
| Robin_Watts | mvrhel_laptop: OK. | 17:57.27 |
| | If you miss me this evening, send me a mail to remind me :) | 17:57.38 |
| mvrhel_laptop | ok thanks | 17:57.47 |
| Robin_Watts | paulgardiner, tor8: Exception handling changes on robin/master | 19:20.52 |
| | mvrhel_laptop: Just in case you haven't realised, mupdf has had a bit of an earthquake today. | 19:21.20 |
| | Header files have all been shaken apart. | 19:21.34 |
| | This may mean you have a bit of trouble with the rebasing. If you do, then feel free to push your commit as is to your repo, and I'll try and sort it for you tomorrow. | 19:22.11 |
| | (so you might want to push it early so you have a saved version). | 19:22.28 |
| mvrhel_laptop | Robin_Watts: ok thanks for the heads up | 19:30.35 |
| | most of my changes are in the ui stuff so ideally there will not be to many rebasing issues | 19:31.06 |
| Robin_Watts | tor8, paulgardiner: OK, both error handling changes and progressive loading patches up there. | 20:05.23 |
| henrys | what are folks using these days to look at very large images (png's etc.). ImageMagick is seems to be getting slower every time I upgrade. | 20:59.38 |
| tor8 | Robin_Watts: the __printflike attribute to fz_throw_message needs to be updated | 21:10.21 |
| | do we ever use the plain fz_throw/fz_rethrow without _message? it looks like we don't, so I wonder if we shouldn't just make the _message the one and only variant | 21:11.17 |
| mvrhel_laptop | Robin_Watts: so on my repos is the fix for the change in the header structure and also some stuff related to having the app as the default app and having it be file driven (e.g. open with) | 22:01.50 |
| | bbiab | 22:28.01 |
| | windows store app certification testing has found a few issues.... | 23:31.43 |
| Robin_Watts | tor8: For the logs: We don't use the non-message variant of throw. | 23:48.13 |
| | But maybe we should. | 23:48.21 |
| | If we want to offer proper internationalisation, we should move over to looking the strings up from the error code. | 23:48.57 |
| | Any thoughts? | 23:49.02 |
| | Forward 1 day (to 2013/06/19)>>> | |
IRC Logs