| | <<<Back 1 day (to 2015/02/17) | 20150218 |
| Robin_Watts | tor8: Yes, we're good. | 00:14.28 |
| | I've got the display list commit updated too. | 00:14.38 |
| | but I want to tweak the path handling a bit. | 00:14.44 |
| | just cluster testing it now. | 00:20.42 |
| kens | FreezingAlt : in response to your question last night, its impossible for us to tell without seeing your PDF file, at the very least. We've offered advice based on your description, but that almost certainly leaves out a considerable amount of informaiton. Also, as I said yesterday, Google *does* use OCR on PDF files, it uses it for Google Docs so I imagine Google use the same technology all over. Also, what do you mean by 'Goog | 08:10.04 |
| | le' ? THe search engine ? Google Docs, GMail ?..... | 08:10.05 |
| | Chrisl I think its time Vikas Arora was kicked off Bugzilla | 09:01.06 |
| chrisl | kens: yeh, probably. Unfortunately, I can't do it.... | 09:02.43 |
| kens | Me neither, but I think we should petitionMarcos when he comes online next | 09:03.00 |
| henrys | kens:up late can't we simply direct him to gnu mailman? That's where the problem has to be fixed if they want to fix it. | 09:04.30 |
| kens | henrys, this isn't the only more or less incomprehensible/pointless bug he's raised. | 09:04.58 |
| | THere's one still open and assigned to marcos that we have autocomplete enabled in teh browser | 09:05.19 |
| chrisl | henrys: the problem that *we* host those mailing lists, so it is our configuration | 09:05.40 |
| kens | To be honest its his attitudde and CAPITAL LETTERS which is really annoying, he clearly annoyed Ray overnight too. I think we've put up with him long enough | 09:06.18 |
| henrys | chrisl: I thought the html had to be modified to fix that. | 09:06.19 |
| kens | He's not reporting GS bugs so he's not helping us. | 09:06.34 |
| chrisl | henrys: no, this is mostly down to our apache configuration | 09:07.22 |
| henrys | chrisl: hmm http://stackoverflow.com/questions/2530/how-do-you-disable-browser-autocomplete-on-web-form-field-input-tag | 09:08.07 |
| | We don't want this nut calling up his comrades to attack us, but I suppose he's harmless | 09:11.29 |
| chrisl | henrys: the annoying this is that things like the Apache version being visible is a good thing to address, but getting all uppity (and then rude!) about trivial or harmless stuff gets annoying | 09:13.04 |
| henrys | chrisl: I completely agree, I can try dropping a comment about mailman or knock him off. up to you guys I haven't read all his drivel. | 09:16.59 |
| kens | He has olpened at least 2 (maybe 3) other bugs and they are almost all nonsensical ot dumb (public files are PUBLIC!) | 09:17.43 |
| | He looks like another 'security researcher' who wnaders the web looking for well known exploit vulnerabilities and then reporting them in the hope of a bounty | 09:18.30 |
| chrisl_r500 | The noise on the bugtracker is a little irritating, but now he's getting rude..... | 09:18.49 |
| henrys | so I should take that as delete the user? | 09:22.56 |
| kens | My vote is to remove him | 09:23.11 |
| chrisl_r500 | As per bloody usual, cust 532's simulator doesn't even open the project - I really hate the amount of time I waste on this :-( | 09:25.25 |
| henrys | done - well he's disable, deleting users is not recommended by the bugzilla folks... | 09:33.21 |
| chrisl_r500 | thanks henrys | 09:34.23 |
| henrys | chrisl_r500: how did you get stuck with 532? | 09:34.38 |
| chrisl_r500 | henrys: it's font stuff | 09:34.51 |
| henrys | chrisl_r500: ugh, I was hoping you could stay on the project. that sucks. | 09:36.28 |
| chrisl_r500 | henrys: thr really annoying thing is that it's going to take me longer to get their simulator working than it took me to actually fix the code :-( | 09:36.50 |
| | I really don't know how Ray hasn't lost patience with this nonsense...... | 09:38.19 |
| henrys | chrisl_r500: ray knows how much revenue they generate and he likes his bonus? | 09:39.00 |
| | but indeed they are a menace. | 09:39.47 |
| chrisl_r500 | henrys: that may be true but, still, pointlessly wasting time gets on my nerves massively | 09:39.57 |
| henrys | chrisl_r500: why don't they send us a "set up" simulator that just runs? I must be missing something. | 09:40.39 |
| chrisl_r500 | henrys: I have no idea. For the first while, I reported every problem I had when I got a new sim, and they always replied that they weren't concerned about stuff like that - so I gave up | 09:41.52 |
| henrys | chrisl_r500: I do believe that can be "fixed", we just say we'll look at it when you send us something that runs properly, if you want to push back we'll ask ray to do it when he gets in. Whatever you want to do. | 09:45.33 |
| chrisl_r500 | I think I tried that before, to no avail..... | 09:46.31 |
| tor8 | Robin_Watts: two fixes (one serious) on tor/master | 10:26.42 |
| kens | back in a couple of hours | 10:26.42 |
| Robin_Watts | tor8: looking now... | 10:26.42 |
| | both look plausible. | 10:28.05 |
| | I have 1 diff to investigate with my displaylist commit. | 10:28.29 |
| tor8 | Robin_Watts: thanks. | 10:29.51 |
| Robin_Watts | tor8: We never trim paths, do we ? | 11:50.05 |
| | Display list review ready to go. | 11:52.16 |
| | I wonder... would it be worth us always trimming a path when we fz_keep it? | 11:52.55 |
| | fz_keep implies it's going to be kept around for a while (like in a display list) | 11:53.10 |
| | hence the memory saving is probably worth having. | 11:53.20 |
| | mupdf cluster tests are currently completing in 2 minutes 20 seconds. boggle. | 12:08.08 |
| | According to my last 2 cluster runs, the display list rework takes us from 231 mins to 237 mins. | 12:11.17 |
| | And the path trimming takes us from 237 to 239. | 12:11.30 |
| | but I'm not sure what the noise factor in those measurements is. | 12:11.54 |
| | Noise is +/- 1 minute at least | 12:23.10 |
| | Interesting. 32bit windows app crap out at 2Gig of allocated memory. | 12:36.53 |
| | I was vaguely hoping they might manage 4. | 12:37.06 |
| | actually, I guess it's not a surprise, as 32bit windows OS can only handle just over 3gig memory in total... | 12:44.09 |
| | malc_: Hey. | 12:56.45 |
| | That j1.pdf file... | 12:56.49 |
| malc_ | Robin_Watts: hey.. tor just told me to talk to you about soup | 12:57.07 |
| jogux | robin_watts: I think linux has a similar 2G limit (unless you enable PAE possibly) | 12:57.15 |
| tor8 | Robin_Watts: not sure if it's worth bothering with trimming, due to malloc alignment | 12:57.17 |
| malc_ | Robin_Watts: it assumes tdev spans is not null and segfaults if it isn't so | 12:57.24 |
| tor8 | and on windows a realloc is always a new malloc + memcpy IIRC, never in-place like on linux | 12:57.33 |
| Robin_Watts | tor8: hmm. | 12:58.06 |
| tor8 | with exponential growth, we never waste more than 50% | 12:58.33 |
| Robin_Watts | But 50% is quite a lot when it comes to displaylists. | 12:58.51 |
| | malc_: Got a pointer to where in the code? | 12:59.44 |
| tor8 | Robin_Watts: just as an idea to consider | 13:00.01 |
| | if we have a 'finalize' path to change the representation to a final version | 13:00.16 |
| | or clone-path | 13:00.22 |
| malc_ | Robin_Watts: strain_soup : for loop | 13:00.25 |
| tor8 | where the path is all one malloc for both the fz_path and the cmd and coords arrays | 13:00.39 |
| | just packed after each other in one malloc | 13:00.52 |
| | can't do that for parsing, since we don't know how big it will be so it must grow | 13:01.03 |
| | the best we can do is to undo my opengl array splitting | 13:01.29 |
| | and just have one command/coord array instead of two | 13:01.37 |
| Robin_Watts | malc: Does putting if (soup == NULL) return; at the top of strain_soup solve it? | 13:01.53 |
| tor8 | and maybe just enough space pre-allocated to support rects without a second malloc for the array | 13:02.01 |
| Robin_Watts | tor8: ISTR that in at least some of the picsel structures, we had a flattened form. | 13:02.26 |
| tor8 | flattened? | 13:03.13 |
| malc_ | Robin_Watts: sure | 13:03.21 |
| Robin_Watts | The opengl splitting is actually a good thing potentially, cos it means we only use a byte for each tag, rather than a float. | 13:03.30 |
| | tor8: I mean header + data in a single malloc block of exactly the right size. | 13:03.55 |
| tor8 | yeah. that would be the ideal layout for maximum read efficiency | 13:04.20 |
| | we could do something like we did for the lexbuf where we have a preallocated small area | 13:04.39 |
| | and if the path exceeds that space, allocate a separate buffer | 13:04.50 |
| | would be interesting to see how much we can gain if we do that for both fz_path and fz_text | 13:06.00 |
| | for common sizes, like simple rectangles and 100 chars of text | 13:06.13 |
| Robin_Watts | tor8: We could have a convention in the fz_path header that NULL cmd/coord pointers mean 'data follows immediately after this block'. | 13:06.49 |
| tor8 | merge the cmd/coord array into one union array | 13:07.09 |
| Robin_Watts | merge header/cmd/coords, yes. | 13:07.26 |
| tor8 | then if that points to the static tail member of the fz_path struct, then they're not separately allocated | 13:07.32 |
| Robin_Watts | I'd be keep to eliminate pointers in the fz_path block in that case, cos I want to still be able to move the structure around in memory without having to update pointers. | 13:08.24 |
| tor8 | struct fz_path { int len, cap; union { int cmd; float coord; } *data, static_data[8+6]; } | 13:08.43 |
| Robin_Watts | If the combined size is small enough, we could even roll that inline into the display list. | 13:08.45 |
| tor8 | and init with path->data = path->static_data | 13:08.48 |
| | clone small paths into the display list? | 13:09.12 |
| Robin_Watts | possibly, yes. | 13:09.27 |
| | likewise text. | 13:09.32 |
| tor8 | static_data should be enough to hold a rectangle (hoping that's the most common use): moveto, 3x lineto, closepath, end | 13:09.48 |
| | oh wait, we don't have a separate end opcode do we? | 13:10.04 |
| | so 8+5 | 13:10.12 |
| | 8 for the 4 xy coords | 13:10.19 |
| Robin_Watts | tor8: I was pondering updating the path format so we had more efficient storage. | 13:10.23 |
| tor8 | hline,vline? | 13:10.41 |
| | or something bit-packing? | 13:10.48 |
| Robin_Watts | (like potentially tags meaning: 'rectangle' (+ 4 points) | 13:10.52 |
| | and hline, vline, v, c, y, conics etc. | 13:11.14 |
| tor8 | hline, vline, rect commands could help, but I'm not convinced the gains are significant enough over just optimizing like we've just discussed | 13:11.32 |
| Robin_Watts | Picsels stuff does bitpacking compression, but that's much easier when you are dealing with ints :) | 13:11.48 |
| tor8 | not wasting memory and most of all avoiding secondary mallocs | 13:11.52 |
| Robin_Watts | tor8: This can all be played with as a background task. | 13:12.10 |
| tor8 | my code is in pieces (neck deep in pdf_csi/process/processor) | 13:12.26 |
| Robin_Watts | but the display list stuff is good to go now whenever you come up for air. | 13:12.35 |
| tor8 | but I may take a stab at the discussed changes later | 13:12.44 |
| Robin_Watts | I'm going to go back to the SOT salt mine. | 13:12.45 |
| tor8 | go ahead and push the display list stuff if you're happy. I'm concerned about the slowdowns you mentioned, but they seem to be smaller than the usual cluster variance | 13:13.19 |
| Robin_Watts | I'm not surprised the displaylist is slower (after all we're doing more packing/unpacking etc than before) | 13:13.49 |
| malc_ | Robin_Watts: so what about j1? | 13:13.56 |
| Robin_Watts | but the slowdown is pretty minimal. | 13:13.58 |
| tor8 | reducing memory pressure and cache misses should be faster even if it does a bit more computation than packing/unpacking | 13:13.59 |
| | unless the memory differences aren't substantial | 13:14.06 |
| | s/than/when/ | 13:14.20 |
| Robin_Watts | tor8: I suspect the display list will still be sufficiently large that we cache bust. | 13:14.37 |
| | malc_: On what platform were you seeing it run out of memory ? | 13:14.49 |
| tor8 | Robin_Watts: okay. let's sit on it for a day or two while I ponder the fz_path/fz_text stuff | 13:15.01 |
| | maybe we can figure out something really smart :) | 13:15.07 |
| malc_ | Robin_Watts: linux | 13:15.27 |
| | x86_64 | 13:15.33 |
| tor8 | I managed to run out of memory building the display list for j1 as well, IIRC | 13:16.00 |
| Robin_Watts | (to be clear, I think the display list stuff is a big win in memory terms already. But it's not so much of a win that cache effects start to show up) | 13:16.01 |
| tor8 | Robin_Watts: right. | 13:16.07 |
| malc_ | Robin_Watts: tor said that it builds insane amount of display list entries.. and things work without them (i haven't checked) | 13:16.10 |
| Robin_Watts | tor8: yeah. | 13:16.11 |
| | malc_: Indeed. | 13:16.18 |
| | Even with my display list changes, it takes more than 2Gig. | 13:16.39 |
| malc_ | Robin_Watts: this machine has 1.5 total :) | 13:17.02 |
| Robin_Watts | It runs in very little memory without the display list being used :) | 13:18.21 |
| | tor8: torture test used to take 351Meg. Now it takes 216Meg | 13:36.15 |
| | no, sorry... | 13:36.42 |
| | peak memory use used to be 336Meg. It's now 95Meg. | 13:37.02 |
| kens | paulgardiner : (sorry) could you look at this one too please ? | 13:39.45 |
| | http://stackoverflow.com/questions/28582376/how-to-add-geometry-annotations-to-pdf-files-using-mupdf | 13:39.46 |
| Robin_Watts | Without the path trimming, peak memory use is 202Meg. | 13:39.50 |
| paulgardiner | kens: thanks for pointing it out. Answered. | 13:50.52 |
| kens | thanks paul | 13:51.04 |
| malc_ | uhmm.. fz_new_svg_device is weird, first two lines allocate and fill the same field.. | 14:41.29 |
| DevC | hi there | 14:50.03 |
| ghostbot | Welcome to #ghostscript, the channel for Ghostscript and MuPDF. If you have a question, please ask it, don't ask to ask it. Do be prepared to wait for a reply as devs will check the logs and reply when they come on line. | 14:50.03 |
| tor8 | malc_: eh, yeah. | 14:50.27 |
| DevC | im searching a list of command lines arguments which mupdf is accepting | 14:50.33 |
| tor8 | refactoring errors are bound to remain... | 14:50.51 |
| | DevC: mupdf -h will list them | 14:51.33 |
| | but basically, it accepts very few command line arguments | 14:51.44 |
| | -b for anti-aliasing, -p for password, -r for resolution and -C for tint color | 14:52.01 |
| DevC | unfortunately not on windows | 14:52.44 |
| tor8 | yeah. the windows viewer doesn't have the same command line processing. | 14:53.02 |
| | there's a new x11 and win32 viewer in the works, but it's been delayed so won't make it into the next release | 14:53.25 |
| | the windows viewer only takes -p password option | 14:54.06 |
| DevC | Im trying to open a pdf file through a qt application | 14:54.45 |
| | on the windows command line shell i use ./mupdf test.pdf | 14:55.15 |
| | and it opens without any problems | 14:55.24 |
| | If I try to do this with Qt nothing happens | 14:55.51 |
| tor8 | Qt on windows? | 14:56.00 |
| DevC | yes | 14:56.06 |
| tor8 | so not using fork/exec then? | 14:56.25 |
| | I'm not really a windows expert, and I know even less about Qt... | 14:57.05 |
| DevC | maybe I really should try this with functions from stdio like popen etc | 14:57.48 |
| | thx tor8 | 14:58.14 |
| rayjj | chrisl: I saw in the logs about your problem with the simulator(s) | 15:11.35 |
| | chrisl: the argument to "setsim.bat" is polaris (sorry I forgot to give you that little tidbit) -- I also usually edit the setsim.bat to manually select the VS version. I delete the "REM" from the line: set OVERRIDE_VS_VERSION=%VS90COMNTOOLS% | 15:15.00 |
| | chrisl: that's for VS 2008 | 15:15.37 |
| chrisl_r500 | rayjj: those are things I know or can work out, but I still end up faffing around - they *still* haven't fixed the missing AUXDIR declaration in msvc32.mak | 15:18.29 |
| rayjj | chrisl: oh, right -- pollutes the root and if your root isn't writeable ... | 15:19.45 |
| | chrisl: are you up and limping along? or still faffing ? | 15:20.49 |
| chrisl_r500 | rayjj: I'm all done - finished this morning. I just wanted to wait until well after COB in Japan before sending the mail | 15:21.43 |
| rayjj | chrisl: that *might* work, but sometimes they work late | 15:22.30 |
| chrisl_r500 | rayjj: I don't intend to send it for a short while yet - I said it would be Thursday, so..... | 15:23.31 |
| tor8 | Robin_Watts: quick question, in pdf_process_stream, the fz_catch if-else chain | 15:46.32 |
| | am I reading correctly that rethrowing on FZ_ERROR_ABORT depends on whether we have a cookie? | 15:47.03 |
| Robin_Watts | looking.... | 15:47.04 |
| | Yes. | 15:47.27 |
| | If we don't have a cookie, and we get a TRY_LATER, we rethrow it. | 15:48.14 |
| | Hmm. I need to think about this. | 15:49.06 |
| tor8 | so without a cookie, we ONLY rethrow TRY_LATER and ignore all others? | 15:49.15 |
| | that sounds...weird | 15:49.18 |
| Robin_Watts | That sounds wierd to me too. | 15:50.09 |
| malc_ | 3 | 15:50.57 |
| henrys | rayjj: we agreed last meeting to let chrisl_r500 work on the library project, is there more stuff from 532? | 15:50.59 |
| Robin_Watts | tor8: OK, so before the trylater stuff, we used to do: | 15:52.51 |
| | if (we have a cookie) cookie->errors++; | 15:53.04 |
| | if (!ignoring_errors) ... | 15:53.12 |
| | i.e. we'd always swallow the error | 15:54.11 |
| | so the new code is consistent with that, I think. | 15:54.38 |
| tor8 | right. so we only want to propagate TRYLATER | 15:54.45 |
| | and ABORT | 15:54.50 |
| | but we want to do that in all cases, regardless of cookie no? | 15:54.59 |
| chrisl | henrys: exactly who else would make sense to look at font issues from 532? | 15:55.27 |
| henrys | kens | 15:56.08 |
| chrisl | henrys: kens is fully occupied, and doesn't have experience with the simulator | 15:56.39 |
| kens | I did build it once, I think | 15:56.52 |
| Robin_Watts | tor8: If you ignore the FZ_ERROR_ABORT case, the code is correct. | 15:57.05 |
| | TRY_LATER gets passed on if there is no cookie, or if the cookie says that incomplete rendering is not OK. | 15:57.47 |
| | If we get a TRY_LATER and we have a cookie and that cookie says that incomplete rendering is OK, we just up the incomplete count. | 15:58.24 |
| | So the problem is with the addition of the FZ_ERROR_ABORT code. | 15:58.42 |
| | How about: | 15:58.46 |
| henrys | chrisl: I imagine rayjj could track down the bug and ask you a few questions and probably get it done also. | 15:59.16 |
| rayjj | henrys: sorry. My chatzilla highlighting was flaky | 15:59.20 |
| chrisl | henrys: it feels silly to save a couple of hours of my time, only take up possibly several more of someone else's - we're *all* busy | 16:00.11 |
| rayjj | I don't know of anything that needs chrisl from 532 | 16:00.19 |
| Robin_Watts | if ((caught == fz_caught(ctx)) == FZ_ERROR_TRYLATER) | 16:00.39 |
| | { | 16:00.41 |
| | if (!csi->cookie || !csi->cookie->incomplete_ok) | 16:00.43 |
| | fz_rethrow(ctx); | 16:00.45 |
| | cs->cookie->incomplete++; | 16:00.47 |
| | /* Swallow the error */ | 16:00.48 |
| | } | 16:00.50 |
| | else if (caught == FZ_ERROR_ABORT) | 16:00.51 |
| | { | 16:00.53 |
| | fz_rethrow(ctx); | 16:00.54 |
| | } | 16:00.56 |
| | else if (csi->cookie) | 16:00.57 |
| | { | 16:00.59 |
| | csi->cookie->errors++; | 16:01.00 |
| | } | 16:01.02 |
| rayjj | henrys: the only thing pending from 532 (on my plate, not high priority) is the tiling mismatch to Adobe | 16:01.06 |
| tor8 | Robin_Watts: yeah, that's easier to follow | 16:01.28 |
| rayjj | *HATES* the mupdf style of braces on separate lines | 16:01.33 |
| Robin_Watts | rayjj: I've looked at tiling mismatches with adobe before. There are some bugs in bugzilla about it. | 16:02.03 |
| rayjj | particularly when it gets pasted here :-) | 16:02.06 |
| chrisl | much *prefers* the braces on separate lines..... much easier to identify code blocks | 16:02.15 |
| Robin_Watts | rayjj: In particular we differ in the cases where we are allowed to differ :) | 16:02.33 |
| rayjj | Robin_Watts: yeah, the problem comes up when I enable the "match Adobe" area, because then one of the ATS files gets white lines | 16:02.59 |
| | Robin_Watts: but they want to use the match Adobe mode even with TilingType == 2 (which allows us to adjust the tile dimensions) because one of the fts files matches better | 16:04.02 |
| chrisl | rayjj: IIRC, the tiling in question is device dependent. | 16:04.03 |
| rayjj | chrisl: it depends on TilingType | 16:04.17 |
| | chrisl: but TilingType 2 is _supposed_ to let the device pick a "nice" tile size (so it can tile faster), but Adobe doesn't do that | 16:05.29 |
| Robin_Watts | rayjj: Tell 'em to get stuffed. | 16:05.38 |
| | Seriously. that's an unreasonable request. | 16:06.02 |
| rayjj | chrisl: I've pointed that out to them (somewhat more diplomatically than Robin_Watts suggests) | 16:06.11 |
| | which is why it's a low priority | 16:06.31 |
| | it works OK in most cases, but with the ATS file, the tile is painted with an image, and the image doesn't quite fill the "adjusted" tile size (because of the GS "center of pixel" image painting rules) | 16:08.07 |
| malc_ | 3 | 16:09.03 |
| rayjj | I am investigating fudging the ctm to make the image always fill the area | 16:09.08 |
| Robin_Watts | pandora.box.open(); | 16:10.20 |
| chrisl | Next thing, we'll be trying to pixel match Adobe's image interpolation!! | 16:10.58 |
| Robin_Watts | rayjj: And then they'll come up with a case that uses both images and paths. | 16:11.25 |
| rayjj | Robin_Watts: I was going to try anything first on our regression, so I can see what, if anything, is negatively impacted there | 16:20.14 |
| | Robin_Watts: and run the ATS manually before and after | 16:20.53 |
| | Robin_Watts: but first I want to finish fixing the pattern-clist problems. Those are crashes that have been in for a long time | 16:21.33 |
| henrys | rayjj: did adobe switch to doubles in pdf or is it all single precision floats like PostScript? Do we know that? | 16:21.53 |
| rayjj | henrys: I have no idea | 16:22.14 |
| | henrys: but they do a lot less in integer than GS does | 16:22.56 |
| Robin_Watts | float, I believe. | 16:22.59 |
| henrys | rayjj: I was thinking that could be the source of us failing to exactly emulate adobe here, if we are say using singles where we are using doubles. | 16:23.15 |
| | s/we/they | 16:23.33 |
| rayjj | our 'fixed' coordinate representation is part of what causes us to have difficulty | 16:23.37 |
| chrisl | When you say "Adobe", do you mean Acrobat, CPSI or what? I bet Acrobat and CPSI don't exactly match...... | 16:24.02 |
| rayjj | chrisl: you are correct | 16:24.14 |
| | chrisl: for PDF, Acrobat is usually the "standard" | 16:24.42 |
| chrisl | And there's whatever their PDF only "RIP" is called... whatever that is based on | 16:25.02 |
| henrys | then I sign up for Robin_Watts recommended response to the customer ... | 16:25.17 |
| chrisl | Oh yes, PDF Print Engine..... | 16:25.44 |
| rayjj | chrisl: and I always make sure and compare to Acrobat "save to image" results (*not* the screen view). That's for any bugs, not just cust 532 | 16:25.49 |
| chrisl | rayjj: yes, Acrobat's display takes *many* liberties - the image output, less so | 16:26.30 |
| henrys | henrysx6 froze during the last regression run | 16:51.14 |
| Robin_Watts | Have you tried turning it off and on again? | 16:54.51 |
| henrys | Robin_Watts: yea it's running now. need to look at the logs and see what went wrong. | 17:00.05 |
| Robin_Watts | https://www.youtube.com/watch?v=nn2FB1P_Mn8 | 17:00.12 |
| | kens: I'll reply to that SOT request then. | 17:02.57 |
| kens | Eh what ? | 17:03.05 |
| | What SOT request ? | 17:03.11 |
| | Oh that one | 17:03.21 |
| Robin_Watts | A request came in. You forwarded it to Miles, he just replied. | 17:03.26 |
| | Just didn't want both of us to do it. | 17:03.34 |
| kens | Yeah, I did look in our customer list, I didn't see them there, maybe I have an old list. But I certainly can't say anything sensible so yes please, do reply :-) | 17:04.10 |
| | chrisl for the logs. I'm looking at a weird memory problem and could use some input, if you have some time tomorrow could you ping me pleae ? | 17:06.41 |
| | And with that I'm off. Goodnight all | 17:07.00 |
| mvrhel_laptop | bye kens | 17:07.04 |
| Robin_Watts | mvrhel_laptop: tor8 pulled the rug. | 17:17.49 |
| mvrhel_laptop | Robin_Watts: ok thanks for letting me know. up to my ears right now in deviceN color fun. I may take a break this afternoon and try to get the fixes for windows in place | 17:19.27 |
| Robin_Watts | mvrhel_laptop: np. | 17:19.43 |
| mvrhel_laptop | Robin_Watts: have you had a chance to watch black mirror yet? | 17:20.07 |
| Robin_Watts | mvrhel_laptop: Not yet, no. | 17:20.50 |
| mvrhel_laptop | car is still in shop :( they had to order a part from germany. this is going to cost a small fortune | 17:22.29 |
| Robin_Watts | ooh. it's on amazon prime. | 17:22.33 |
| mvrhel_laptop | we have been watching it on net flix. only seen the first 2 episodes | 17:23.06 |
| henrys | mvrhel_laptop: drivin' a porsche? | 17:23.44 |
| mvrhel_laptop | not quite | 17:23.53 |
| pedro_mac | mvrhel_laptop: I ended up getting soem parts shipped here from the US because it was half the price of getting them from Germany | 17:24.01 |
| mvrhel_laptop | its an older mercedes 2006 | 17:24.05 |
| | the transmission computer went out | 17:24.18 |
| pedro_mac | ouch | 17:25.27 |
| mvrhel_laptop | the thing would lose its mind now and then and decide it was going to stay in 3 gear regardless of the engine speed (its a 7 speed transmission) | 17:25.28 |
| pedro_mac | mvrhel_laptop: youâll get used to it eventually ;) | 17:26.09 |
| mvrhel_laptop | turning off and on would reset everything. this whole thing sound to me more like a sensor issue compared to a computer issue. but what do I know about computers | 17:26.23 |
| Robin_Watts | Clutch down, turn the ignition off, turn it on again, clutch back in. All without dropping below 60mph :) | 17:27.04 |
| mvrhel_laptop | if they swap it out and then tell me it also needs some sensor then I will really be suspicious | 17:27.06 |
| Robin_Watts | automatics are the work of satan :) | 17:27.28 |
| mvrhel_laptop | yes. I have to agree. | 17:28.04 |
| henrys | how do you text with both hands using a manual? ;-) | 17:29.33 |
| Robin_Watts | henrys: Get into sixth, and don't drop below 60mph. No need to change gear. | 17:30.36 |
| henrys | brilliant | 17:31.20 |
| mvrhel_laptop | right now the indexed color space is using gx_default_remap_color as its remap proc. I am going to change this and give it its own unique remap proc as this is causing me problems when the base space is DeviceN | 17:32.47 |
| | or Sep | 17:32.59 |
| | then I should be able to solve this problem | 17:33.25 |
| henrys | mvrhel_laptop: that's good but I suspect he's going to run into other stuff and we probably should fix it. we'll see. | 17:37.59 |
| mvrhel_laptop | henrys: yes I suspect that will be the case since unfortunately he is the first to finally make use of this. | 17:38.36 |
| henrys | mvrhel_laptop: it is the first real commercial customer pushing the code in a non-trivial way. | 17:38.50 |
| mvrhel_laptop | yes | 17:38.57 |
| FreezingCold | [04:39:49] <kens> FreezingAlt : in response to your question last night, its impossible for us to tell without seeing your PDF file, at the very least. We've offered advice based on your description, but that almost certainly leaves out a considerable amount of informaiton. Also, as I said yesterday, Google *does* use OCR on PDF files, it uses it for Google Docs so I imagine Google use the same technology all over. Also, what do you mean by 'Goog | 18:38.09 |
| | the search engine | 18:38.13 |
| fredross-perry | still getting the hang of git. I (think I) created a branch in my mupdf repo containing changes to the iOS build that resulted from the recent mupdf API changes. Anyone care to take a look? Then whatâs the protocol foro testing/releasing an update? | 22:28.02 |
| | Forward 1 day (to 2015/02/19)>>> | |
IRC Logs