| | <<<Back 1 day (to 2015/07/02) | 20150703 |
| kangkangtm | Hi | 03:00.47 |
| 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. | 03:00.47 |
| kangkangtm | I download the source code of MuPDF 1.6, and run it on Windows RT | 03:04.34 |
| | But it runs very slow | 03:05.10 |
| | However, I download the MuPDF from Windows store | 03:05.36 |
| | It runs very well | 03:06.47 |
| rayjj | mvrhel: I am looking at the last bit -- fixing the transfer function differences in the fast HT case. Did you ever do any testing with TRANSFER_IN_THRESHOLDS set to 1 ? | 03:25.07 |
| | mvrhel: BTW, thanks for having a look at my changes | 03:25.32 |
| | mvrhel: it looks to me that if TRANSFER_IN_THRESHOLDS is 1 the code will doubly apply the transfer function | 03:26.18 |
| chrisl | kens: ping | 08:14.48 |
| kens | pong | 08:15.07 |
| chrisl | When you have a minute, would you cast your eye over the second and third top commits in my repo? | 08:15.28 |
| kens | SO is that the strtok and TurboC ones ? | 08:17.24 |
| | or strtok and trio ? | 08:17.34 |
| chrisl | strtok and trio | 08:17.44 |
| kens | Yeah just figured that | 08:17.50 |
| chrisl | The TurboC one is just deleting a file, so..... | 08:18.02 |
| kens | That's what I worked out, it wasn't hard once I looked :-) | 08:18.15 |
| chrisl | The trio/sprintf one, is mainly for gs/base/gssprintf.c | 08:19.03 |
| kens | Yeah I'm looking at that, there's nopthign I can say about configure and stuff :-) | 08:19.21 |
| chrisl | The other stuff is just "house keeping" | 08:19.37 |
| | For both commits, I have branches with the original sources, so we have a record of what was tweaked to work in gs | 08:20.28 |
| kens | Robin won't like the PREFIX macro :-) | 08:20.31 |
| | Or most of them in fact | 08:21.00 |
| chrisl | Tough. I'm trying to keep the changes from the originals to a minimum | 08:21.21 |
| kens | I wasn't proposing you should change, just amused. | 08:21.36 |
| chrisl | I also think it would be wise, at some point, to make the effort to switch to using gs_snprintf() everywhere it's feasible...... | 08:24.52 |
| kens | I guess so, that's probably mostly work for me in pdfwrite I expect.... | 08:25.23 |
| | Well I'[m not going to try and read through all the Apache code, it looks sensible to me though. | 08:26.07 |
| chrisl | By it's nature, the Apache code is generally quite robust.... | 08:26.32 |
| kens | gxclmem.c you've changed from using gs_sscang to sscanf ? | 08:27.02 |
| chrisl | We don't have a gs_sscanf() right now | 08:27.32 |
| | And it's parsing an integer, so no requirement for us to have one | 08:28.00 |
| kens | RIght I was just checking if that wa why. SO I guess that's the only place we use it, because it wouldn't compile. Strange there's only 2 uses. | 08:28.05 |
| chrisl | There may be other places that use sscanf() in things like parameter parsing, but in those cases we *do* want the locale to take effect | 08:29.06 |
| kens | I guess so. | 08:29.21 |
| chrisl | The only other place(s) we need that functionality is in psi, where we use the Postscript number parsing instead | 08:29.55 |
| Robin_Watts | kens: Yeah, those macros are poor :( | 08:32.30 |
| kens | Well they both look fine to me, not that that means much | 08:32.37 |
| Robin_Watts | But if this is imported code that we might want to keep importing, there is an argument for not changing them. | 08:32.52 |
| kens | Yes, I agree with Chris on that point | 08:33.08 |
| | You could report it to the Apache people | 08:33.18 |
| Robin_Watts | If this is code we don't think will ever change, then we can tweak them slightly. | 08:33.27 |
| | but that should be done after the initial import. | 08:33.35 |
| chrisl | As there is always the chance of security issues arising in these things, I'd rather keep it as easy to update as possible | 08:35.08 |
| | Mind you, given that the macros are only used locally, I'm guessing those are historic code from when gcc wasn't very good at inlining.... otherwise, I can't see any advantage over a static inline function | 08:37.05 |
| kens | Like I said, I'd go ahead and commit it | 08:38.13 |
| Robin_Watts | I am certainly not arguing against committing them. | 08:38.27 |
| | macros like STR_TO_DEC would be trickier as static inlines as they take 2 params and update both. | 08:39.00 |
| Robin_Watts | pops out. bbiab. | 08:39.15 |
| chrisl | I've pushed those, and the branches with the tweakings to golden, so hopefully if we have to import again, it won't be a huge PITA | 08:40.03 |
| | So the dreaded strtok is banished, never to return, and trio is gone, gone, gone..... | 08:41.35 |
| kens | Well, progress then.... | 08:42.06 |
| Robin_Watts | So, fred did modifications to mupdf so it would build with gradle - but I can't see them in his repo... | 11:47.02 |
| | ooh. How has golden mupdf.git ended up with a chrisl/master ? | 11:47.57 |
| chrisl | It's doing the mirroring to github | 11:48.14 |
| Robin_Watts | Ah! | 11:48.21 |
| | That makes sense. Ta. | 11:48.33 |
| chrisl | Or, it should be - I'm not sure yet..... | 11:48.37 |
| jogux | chrisl: the github mirroring did look like it was working to me btw :) | 13:13.30 |
| chrisl | jogux: I *think* it is, but I had to poke it manually, and then tweak it after Robin_Watts's last commits - so I'm hedging my bets until a few more commits go in | 13:15.37 |
| jogux | ah ;-) | 13:15.45 |
| rayjj | morning, all | 13:47.50 |
| | mvrhel: when you are actually awake, please ping me | 13:48.16 |
| | this gx_ht_construct_transfer_inverse is somewhat difficult. It's close, but off by a bit compared with the "normal" transfer function results. I know what it should be, now just have to figure out how to have that procedure generate the correct inverse | 14:11.28 |
| | hmm... found one 'typo' in the binary search. It was computing the float_val for the value as k/256.0 instead of k/255. (255 s/b 1.0) | 14:34.15 |
| | also binary search fails to get the 'best' result when it detects a 'hit' eg. frac_val==25309 it has a min_pos of 739 corresponding to a value of 25255, and a mid_pos of 741, value=25364 and a max_pos of 743, value 25309 but then is uses the mid_pos of 741 when, clearly, the better 'pos' to use s/b 743 | 14:49.05 |
| | I guess this code never really got used (it was #if'ed out) | 14:49.36 |
| | oops. mis-read the debug values. it's OK | 14:52.07 |
| mvrhel | actually awake rayjj? | 16:48.51 |
| tkamppeter | Has anyone read this bug report: http://bugs.ghostscript.com/show_bug.cgi?id=695124 It is a longer monologue by Hin-Tak Leung. Does his patch make sense? | 17:44.49 |
| | marcosw, hi | 20:12.48 |
| | Forward 1 day (to 2015/07/04)>>> | |
IRC Logs