| | <<<Back 1 day (to 2015/10/13) | 20151014 |
| ThatGuy_ | bugs submitted: http://bugs.ghostscript.com/show_bug.cgi?id=696272 http://bugs.ghostscript.com/show_bug.cgi?id=696273 | 00:23.13 |
| | thanks again! | 00:23.15 |
| | take care | 00:23.18 |
| rayjj | ThatGuy_ forgot to attach a sample file :-( I reminded him on the GhostXPS bug | 00:29.53 |
| mvrhel_ | tor8: for the logs. So I was able to get my ubuntu updated and the various required gl packages installed. All the header files are found. But linking it dies. | 06:00.49 |
| | LINK build/debug/mupdf-gl | 06:01.02 |
| | \user\bin\ld: cannot find -lGL | 06:01.44 |
| | I can't figure this one out | 06:02.10 |
| tor8 | Robin_Watts: several commits on tor/master for review (ignore the top 3, they're for post release) | 11:19.13 |
| Robin_Watts | Why do we build different types of app in release/debug build for windows ? | 11:20.28 |
| tor8 | so we can see debug messages and fz_warn and fz_throw errors printed to stderr/stdout :) | 11:21.01 |
| | if you know a better way, I'm all ears | 11:21.24 |
| Robin_Watts | Messages should go to OutputDebugString. | 11:23.09 |
| | Ideally we should try to mention bug numbers in the commit messages in future. | 11:24.57 |
| tor8 | Robin_Watts: oh. I wasn't aware of USE_OUTPUT_DEBUG_STRING's existence :) | 11:25.47 |
| | should add that flag to mupdf-gl's debug build and then always use WinMain. | 11:26.03 |
| Robin_Watts | That sounds nicer. | 11:26.32 |
| | stylistically I dislike FZ_UNUSED as a suffix. Does it need to be ? | 11:27.09 |
| tor8 | hm, the project file config flags are a bit inconsistent for the 'mupdf' project | 11:27.37 |
| | the Preprocessor definitions include a lot of thirdparty library options in debug configs but not release | 11:28.23 |
| Robin_Watts | tor8: That sounds bad. | 11:29.54 |
| | Otherwise the commits look good to me. | 11:30.01 |
| tor8 | Robin_Watts: visual studio is not good at displaying the configuration options... there's just no overview :( | 11:31.36 |
| Robin_Watts | yeah. | 11:31.53 |
| tor8 | Robin_Watts: okay, updated win32 release mode commit on tor/master. | 11:40.53 |
| | the FZ_UNUSED macro, as far as I can see from gcc's __attribute__ docs, needs to be at the end. ugly as it is. | 11:41.12 |
| Robin_Watts | FZ_UNUSED(x) ? | 12:15.58 |
| | Just pondering if we're ever going to come up against something that will need it at the start. | 12:16.38 |
| | looks good. | 12:18.06 |
| | simon91: tor8 is about to commit your fixes. Thanks. | 12:30.17 |
| simon91 | Robin_Watts: many thanks back to you folks! | 12:40.47 |
| | Robin_Watts: currently I'm writing up a fix for http://bugs.ghostscript.com/show_bug.cgi?id=696260. That is I'm adding a pdf_write_document_to_file, which takes a FILE * instead of the filename. I just have to do some more testing with the signature part. | 12:45.57 |
| Robin_Watts | great. | 12:46.10 |
| simon91 | Robin_Watts: Actually the filename is nowhere needed. So it's not a big patch. | 12:48.58 |
| tor8 | simon91: Robin_Watts: pdf_write_document should really be taking a fz_output rather than a FILE* | 12:52.52 |
| | there are old bits of code left still using FILE*'s rather than fz_stream/fz_output for i/o that still need to be updated | 12:53.22 |
| Robin_Watts | tor8: Can we seek in an fz_output ? Do we need to seek as we write a document? | 12:53.32 |
| tor8 | Robin_Watts: I'm not sure, I don't think we should need to | 12:53.51 |
| simon91 | tor8: yes, but then you have to rewrite larg parts of it as it's jusing FILE and not fz_outptu internally | 12:54.17 |
| tor8 | simon91: yeah. I'm going to do that, but after the upcoming release. | 12:55.18 |
| simon91 | tor8: We could add the fz_output variant later, when we add object streams. | 12:55.30 |
| | and implement the to_file variant on top of it | 12:55.58 |
| tor8 | yeah. the write to a filename variants should do the 'safe' juggling of write, close, rename so we don't end up with a clobbered broken file in case of errors | 12:56.48 |
| simon91 | tor8: yes of course I would keep the filename variants for backwards compatibility. | 12:58.42 |
| | Robin: you need toseek to get the xref offsets. | 13:00.13 |
| Robin_Watts | I'm not sure we can seek in fz_outputs. | 13:00.54 |
| simon91 | tor8, Robin_Watts: have to go to a course now. See you | 13:01.36 |
| tor8 | you only need to 'tell' to get the xref offsets | 13:01.44 |
| Robin_Watts | simon91: CU. | 13:01.54 |
| simon91 | tor8: but for the first tell you need a seek | 13:03.18 |
| | after that you could do it yourself | 13:03.47 |
| | ok I have to go now. CU | 13:05.13 |
| mvrhel | tor8 any ideas why I would still have the issues on ubuntu with my mupdf build. I am all updated and I have mesa-common.dev installed | 14:27.13 |
| tor8 | mvrhel: hard to tell. can you run 'glxgears'? | 14:28.59 |
| | it sounds like you don't have opengl installed | 14:29.22 |
| | if you don't have 'glxgears', it should be part of the 'mesa-utils' package | 14:30.06 |
| mvrhel | yes the gears work | 14:51.10 |
| | tor8: ok I figured it out | 14:58.44 |
| | needed libgl1-mesa-dev | 14:58.56 |
| | this stuff needs to be in the documentation | 14:59.06 |
| | at some point | 14:59.09 |
| tor8 | mvrhel: right, that's the first package I told you to install yesterday :) | 15:12.48 |
| mvrhel | tor8: you are right. that was when I was having ubuntu end of life issues so nothing was installing. sorry about that | 15:15.39 |
| rayjj | chrisl: As far as I can tell gxino12b.c and gxino16b.c are never used and we don't need the chicanery of having those procs be "variable" at build time (determined by which 12 and 16 bit gxi functions are linked in) | 16:49.03 |
| chrisl | rayjj: they don't seem to be referenced for any make file..... | 16:52.36 |
| rayjj | chrisl: why I am looking at this is trying to find an indeterminism using helgrind, and I get false positives from gxipixel.c 856, 857 | 16:53.09 |
| | chrisl: all I can guess is that they were there for Level 1 PS or something | 16:55.21 |
| | but we only support Level 2 | 16:55.46 |
| chrisl | rayjj: In theory, there's still sort of support for a Level 1 only build - but I strongly suspect it's bitrotted, and who the hell would want less that Level 3?!?! | 16:56.41 |
| rayjj | chrisl: exactly. While we haven't pulled some of the Level 1 only nonsense out, we made a policy decision many years ago that we would no longer support less than Level 2 | 16:58.00 |
| chrisl | rayjj: as I said, neither gxino12b.c and gxino16b.c are built by any makefile in any configuration, so they are clearly never used | 16:58.29 |
| rayjj | chrisl: agreed. I ran: find . -name "*.mak" -exec grep gxino "{}" \; -print | 16:58.45 |
| | just to make sure it wasn't needed for pcl or xps | 16:59.24 |
| chrisl | rayjj: so, if you want to rip out that stuff, you'll have my full support.... but false positives are anything but unusual for valgrind - hence my dislike for it as a "testing" tool | 17:01.11 |
| | rayjj: they weren't used or referenced by XPS or PCL before the build reorganisation either, so I think they are totally moribund | 17:03.59 |
| rayjj | chrisl: I'll work up a patch to get rid of that stuff (there was a level of indirection in gximdecode.c as well for unpackicc_16) and run it by you for review. Nothing urgent | 17:05.19 |
| mvrhel_laptop | Robin_Watts: On my repos is a simple commit for mupdf. I let an unused variable sneak by in my last commit | 18:27.52 |
| Robin_Watts | mvrhel_laptop: OK, lgtm. | 18:28.39 |
| mvrhel_laptop | thanks | 18:28.43 |
| Robin_Watts | np. | 18:28.46 |
| | Forward 1 day (to 2015/10/15)>>> | |
IRC Logs