| | <<<Back 1 day (to 2015/03/17) | 20150318 |
| chrisl | kens: and also slight tweak to your fix for Bug 695860 (see what you think): http://git.ghostscript.com/?p=user/chrisl/ghostpdl.git;a=commitdiff;h=3c4edb1e | 08:41.57 |
| kens | Yes that makes sense too | 08:43.27 |
| | Saves me coding up pdfwrite to ignore BGPrint :-) | 08:43.47 |
| chrisl | Mainly, it saves the cost of a full currentpagedevice (get_params) call | 08:44.26 |
| kens | Yep, not vastly important since we are shutting down, but definitely worthwhile | 08:44.47 |
| chrisl | Well, considering we've had customers complain about startup time, presumably the same customer(s) would also notice a longer shutdown time, so...... | 08:45.49 |
| kens | Yes, worthwhile, like I said. | 08:46.02 |
| chrisl | Quick clusterpush, then.... I have fiddled with it since I cluster tested it last night | 08:46.39 |
| kens | Makes sense | 08:46.52 |
| tor8 | Robin_Watts: fz_seek should take an off_t (not a size_t) to match lseek() | 10:57.12 |
| Robin_Watts | tor8: yeah, probably | 10:58.11 |
| | It does in my copy here... | 10:58.40 |
| tor8 | we seek from the end for finding the startxref offset, IIRC | 10:58.41 |
| | ah, yes, the large file support changes it back | 10:59.04 |
| Robin_Watts | Yeah, I'll probably squash some of those commits. | 10:59.35 |
| tor8 | ah, you use fopen/fseek/ftell in pdf-write | 11:00.45 |
| | I was going to say we don't need those :/ | 11:00.53 |
| | Robin_Watts: off_t is 64-bit when -D_FILE_OFFSET_BITS=64 | 11:03.06 |
| | or use off64_t | 11:03.32 |
| | if using _LARGEFILE_SOURCE | 11:03.48 |
| Robin_Watts | tor8: We *really* shouldn't be using open/lseek etc. We should be entirely FILE * based, frankly. | 11:07.56 |
| | IMAO. | 11:08.02 |
| tor8 | that would mean all I/O is double buffered though | 11:08.24 |
| Robin_Watts | tor8: And that would be bad because... | 11:08.44 |
| tor8 | too many memcpy's :) | 11:08.53 |
| Robin_Watts | Given the speed of CPU vs io these days, I think that's a win. | 11:09.29 |
| tor8 | one (or two, depending on the libc) from the kernel into the FILE*, one from the FILE* into the fz_buffer | 11:09.35 |
| | CPU speed is not my worry, it's memory bandwidth | 11:09.47 |
| Robin_Watts | memory bandwidth is still much faster than io. | 11:10.04 |
| tor8 | well, given that we should be using fz_stream/fz_output everywhere, changing the backing from file descriptors to FILE* should be a minor bit of surgery | 11:10.56 |
| | I've also got an unhealthy dislike for libc's stdio.h ... it's full of crap design :( | 11:11.26 |
| Robin_Watts | I use fz_off_t everywhere. | 11:11.33 |
| tor8 | like the arguments to fwrite... | 11:11.47 |
| Robin_Watts | That's defined to be int or int64_t (or __int64) as required. | 11:11.49 |
| | I still need to get the output of offsets correct. | 11:12.52 |
| | still using %d everywhere. | 11:13.00 |
| tor8 | use fz_printf everywhere, and add %D and %U flags for 64-bit? | 11:13.30 |
| Robin_Watts | fz_printf requires fz_context. | 11:13.52 |
| tor8 | or %ld prefixes | 11:13.55 |
| | where is that a problem? | 11:14.02 |
| Robin_Watts | I think I like the idea of %o for offset. | 11:14.07 |
| | tor8: can't remember offhand, but somewhere :) | 11:14.19 |
| tor8 | we should have a context everywhere except for fz_new_context :) | 11:14.29 |
| | %o is for octal | 11:14.46 |
| | otherwise I would agree | 11:14.55 |
| | although, we don't actually use %o anywhere | 11:15.36 |
| | I wonder what we do when we format pdf string escapes | 11:15.54 |
| | ah, we do that manually not with printf | 11:16.13 |
| Robin_Watts | I have a customer SOT thing to finish first though. | 11:17.18 |
| tor8 | Robin_Watts: fseeko takes an off_t (which can be 64-bit with _FILE_OFFSET_BITS 64) | 11:17.55 |
| | if we want to start using FILE* with large file support | 11:18.14 |
| fredross-perry | I made a 32-bit gsview (on Fedora) if someone wants to give it a spin. No installer yet. http://www.ghostscript.com/~fred/gsview/linux/gsview32.zip | 19:32.21 |
| Robin_Watts | I will try and have a look when I get unburied. | 19:33.18 |
| | Forward 1 day (to 2015/03/19)>>> | |
IRC Logs