| | <<<Back 1 day (to 2017/06/14) | 20170615 |
| parik | help | 05:23.38 |
| | I want to update my pdf after change annotations | 05:24.05 |
| | what should i do please help me | 05:24.14 |
| sebras | dabu: https://stackoverflow.com/questions/41249041/c-in-xcode-redeclaration-of-function-must-have-the-overloadable-attribute-error | 06:55.20 |
| | dabu: seems like someone saw a similar error as you do in mupdf. | 06:55.38 |
| | dabu: do you care to check if you happen to use clang with -fmodules inside xcode? | 06:56.00 |
| dabu | I wasn't actually using Xcode, just regular make on the terminal. | 06:58.01 |
| sebras | dabu: if that is the case then I think the problem is that there's a line in our public header output.h where we redeclare strlen without including string.h that is likely the culprit in this case. | 06:58.06 |
| dabu | If you want I can try it though | 06:58.07 |
| sebras | dabu: hm... if you build using "make verbose=yes" you should be able to determine the command. | 06:58.34 |
| | dabu: but i'm guessing that -fmodules is implicitly turned on. | 06:58.54 |
| | dabu: since the Makefiles do not appear to mention -fmodules at all. | 07:00.56 |
| dabu | What exactly should "make verbose=yes" tell me? | 07:01.29 |
| sebras | dabu: you should be able to see the clang command used to compile the files where you have errors in the log | 07:02.05 |
| | dabu: and that command might specify -fmodules | 07:02.24 |
| dabu | Ok, let me just pull the repo once again and check | 07:02.41 |
| sebras | dabu: thanks, I don't have access to an macos machine so I'm unable to test this. thanks for helping out. :) | 07:03.07 |
| | tor8 (for the logs): if I'm right in this then the change in output.h in commit 9534243f6849d1938195c1f27adaa5745056f138 might be a bad idea. | 07:03.50 |
| dabu | I see no mention of "fmodules" | 07:10.12 |
| | clang is invoked with | 07:10.16 |
| | clang -MMD -MP -MF | 07:10.16 |
| sebras | dabu: ok, that seems reasonable I believe. then I'm guessing that -fmodules is enabled by default in your setup. not sure if there's a way to ask clang to print the default settings. | 07:16.56 |
| | dabu: if -fmodules is enabled by default, combined with the inline redeclaration of strlen in include/mupdf/fitz/output.h, would certainly explain the errors you see. | 07:17.58 |
| dabu | Is there I way I can check if "-fmodules" is enabled by default? | 07:19.57 |
| sebras | dabu: I haven't found a way yet. | 07:20.41 |
| | dabu: the reason I ask about this is that I have compiled before using clang and it worked fine for me. | 07:21.33 |
| | dabu: on this machine I'm currently installing clang, but I'm on a _relly_ slow network so it might take me some time to reverify that I can successfully compile using clang. | 07:22.04 |
| dabu | Well, you never know what does MacOS implementation do | 07:22.59 |
| | so it's kinda hard to predict | 07:23.05 |
| | clang --version | 07:24.24 |
| | Apple LLVM version 8.1.0 (clang-802.0.42) | 07:24.24 |
| | Target: x86_64-apple-darwin16.5.0 | 07:24.24 |
| | Thread model: posix | 07:24.26 |
| | InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin | 07:24.28 |
| | I wonder if I install clang from a repository it will work the same | 07:25.09 |
| sebras | dabu: I have no idea, macos is mysterious to me. :) | 07:25.26 |
| dabu | As for everyone I think :) | 07:26.13 |
| sebras | dabu: ok, so this might take a while. apparently I'll have to download a few hundred megabytes and I'm getting just about 30Kbyte/s... | 07:28.12 |
| | dabu: I'll try to compile once it is downloaded. if you are able to stick around (or come back tomorrow, depending on your timezone) I'd appreciate that. | 07:29.08 |
| dabu | Sorry, I also have no other machine currently to test it | 07:29.47 |
| | Yeah, no problem | 07:29.50 |
| | I can stick around | 07:29.53 |
| | but... if I'm disconnected I won't see messages in between my connections, right? | 07:30.22 |
| | I hardly ever use IRC | 07:30.39 |
| sebras | dabu: that's correct. | 07:31.13 |
| | dabu: though this particular channel is logged over at https://ghostscript.com/mupdfirclogs/current.html | 07:31.42 |
| dabu | Oh, that's great | 07:32.11 |
| | So it's 9:32 AM right now, so I'll probably be here in the evening or afternoon | 07:32.43 |
| sebras | dabu: sounds good. | 07:33.43 |
| Robin_Watts | Morning tor. | 09:20.49 |
| | Your commits all lgtm. | 09:20.55 |
| | I added a few too. | 09:21.32 |
| | Mainly an attempt at fixing java stuff. | 09:21.49 |
| | I'm going to poke at moving aa stuff out of the context today. | 09:22.51 |
| | and into the draw device options. | 09:22.59 |
| tor8 | Robin_Watts: okay. | 09:34.39 |
| | Robin_Watts: enums ABSOLUTECOLORIMETRIC colud do with an underscore | 09:36.25 |
| Robin_Watts | tor8: ok. | 09:36.34 |
| tor8 | some of the mupdf_native.c fixes intended for the "Fix MSVC build and some ething things" look like they're included in the "Fix javalib" commit instead | 09:38.38 |
| | the size_t thing | 09:38.42 |
| Robin_Watts | oops. will juggle. | 09:38.50 |
| tor8 | apart from that, all LGTM | 09:40.01 |
| Robin_Watts | Updated. Thanks | 09:41.43 |
| tor8 | Robin_Watts: might be useful to add a ColorParams.pack(RenderingIntent i, int boolean bp, op, opm)? | 09:46.21 |
| Robin_Watts | tor8: ah yes. | 09:46.45 |
| | For a while I had the ri at bit 0, which meant packing was just or. | 09:47.04 |
| | but I moved that because ri might grow in future. | 09:47.29 |
| tor8 | I'd be okay with that too. java enums are funky. | 09:47.31 |
| Robin_Watts | oh, crap, lcms needs them in a different order. | 09:48.39 |
| tor8 | needs what? | 09:49.31 |
| Robin_Watts | Let me reorder them, put it back to bit 0, and leave some spare bits in there for future expansion. | 09:49.37 |
| | the enum needs to be in a different order. | 09:49.45 |
| tor8 | oh. | 09:49.49 |
| | right. | 09:49.57 |
| Robin_Watts | fixed. | 09:55.40 |
| | tor8: I'd forgotten to rebase lcms onto the top of the scan converter changes. Just done that. | 11:32.14 |
| kens | #join #artifex | 12:13.26 |
| tor8 | Robin_Watts: did you figure out what went wrong with the scan converter commit? | 12:29.14 |
| Robin_Watts | tor8: yes. What is there is correct now I believe. | 12:49.41 |
| tor8 | avih: there's a commit on mujs:tor/master with some pkgconfig stuff | 13:33.08 |
| avih | tor8: thanks. i'll let you know if something comes up. | 13:36.22 |
| | also thx for the install file flags | 13:36.35 |
| | tor8: first feedback on windows mingw: | 13:43.45 |
| | <RiCON> hm, shared lib isn't .so in mingw/windows | 13:43.46 |
| | <avih> it's not? | 13:43.46 |
| | <RiCON> no. | 13:43.46 |
| | <avih> what is it? dll? | 13:43.47 |
| | <RiCON> .dll and implib .dll.a | 13:43.49 |
| | <avih> k, i'll forward it. thanks. | 13:43.51 |
| | <RiCON> .dll gets installed to bindir so executables can use it and implib to libdir | 13:43.53 |
| | <RiCON> and separate rules to install-static and install-shared would be appreciated | 13:45.08 |
| | <avih> is it common elsewhere too? | 13:45.08 |
| | <RiCON> the separate rules? | 13:45.08 |
| | <avih> yes | 13:45.08 |
| | <RiCON> no, common would be a configure flag to --disable-{shared,static} | 13:45.08 |
| | <avih> right | 13:45.08 |
| tor8 | avih: does mpv build on mingw? | 13:45.19 |
| avih | yes | 13:45.24 |
| tor8 | package maintainers are insane and impossible to please... I'm of a good mind to just not provide any "install" target at all and leave it up to distro maintainers. like we do with mupdf. | 13:46.32 |
| | I'm not entirely convinced of the utility of a shared library | 13:47.10 |
| avih | mpv can be built as libmpv, and now it can utilize mujs if it's there, but it needs .so, or -fPIC to be used in a lib, as far as i understand | 13:48.55 |
| tor8 | and the mpv build system requires external libraries to be available via pkgconfig or something similar? | 13:49.26 |
| avih | fwiw, the missing .so or -fPIC for linking with a lib wasn't considered a real issue of mujs | 13:49.41 |
| | yes, pkgconfig is preferably the way to find packages | 13:50.13 |
| | (else it looks at system dirs, but apparently the two who tried using mujs already had custom dir for mpv deps, so it deeded CFLAGS etc to make it build and link) | 13:52.12 |
| | needed* | 13:52.28 |
| | (where the rest of the deps were handled correctly with pkgconfig) | 13:52.48 |
| sebras | tor8: did you see dabu's compile log from before where his macos-based clang complains about us redeclaring strlen: https://gist.githubusercontent.com/rafal-adamek/9fbd6afab8d05fad3c6daa8af783095b/raw/f2dbab9d74247686913556f9fa1f8d8469fdc766/gistfile1.txt | 13:53.25 |
| | tor8: given this https://stackoverflow.com/questions/41249041/c-in-xcode-redeclaration-of-function-must-have-the-overloadable-attribute-error | 13:53.34 |
| | tor8: I believe that we should refrain from redeclaring it, but I'm unable to verify this. | 13:53.55 |
| tor8 | sebras: yeah. those static inline functions should be turned into proper functions and then we won't need that hack. | 13:54.10 |
| sebras | tor8: I tried to compile with my linux-based clang 3.9.1 and I see no issue. | 13:54.20 |
| tor8 | it's Apple's fork of clang that tries to be more "user friendly", I reckon | 13:54.43 |
| | and that redefine is from my include file cleanup work in progress | 13:55.33 |
| sebras | tor8: oh. | 13:55.42 |
| | tor8: I'm confused... did you merge that? | 13:55.57 |
| avih | tor8: there was also a comment on ifeq "$(shell uname)" "Linux" (which just moved but shows at the diff) that it can be incorrect when cross compiling. there are many setups which build windows apps on linux with mingw, i do too. i don't think i noticed issues though, and i don't know what it should do. | 13:56.03 |
| tor8 | no, but it's part of the cleanups that I did in preparation | 13:56.18 |
| | avih: the makefile is not intended as the end-all-be-all solution. if you're cross compiling or doing *anything* out of the ordinary, just use "cc -c one.c" and be done with it. | 13:56.59 |
| | and I consider mingw to be out of the ordinary :) | 13:57.08 |
| avih | you do realize there are like two orders of magnitude more windows users than linux users, excluding android? :) | 13:57.32 |
| sebras | tor8: so should I be moving all inline fz_write() into output.c or so? | 13:57.34 |
| tor8 | avih: yes, but they mostly use MSVC :P | 13:57.43 |
| | sebras: yes, we should do that. | 13:58.06 |
| avih | i wouldn't say so. mingw is quite common to build windows apps | 13:58.22 |
| tor8 | avih: open source developers are also two orders of magnitude less common ;) | 13:58.44 |
| avih | sure though, MSVC is more common | 13:58.46 |
| sebras | tor8: let me whip up a patch. | 13:58.51 |
| tor8 | sebras: after this lcms stuff is in, I can go back to the header file stuff | 13:59.14 |
| | enough is changing in the header files that I should probably restart... | 13:59.24 |
| | sebras: so a patch to move them is not going to conflict, and would be appreciated | 13:59.58 |
| sebras | tor8: ok, I noticed that the lcms stuff is in the unit of days away. | 14:01.12 |
| tor8 | sebras: hopefully, yes | 14:02.56 |
| | the question is how to merge it in, squashed or branched | 14:03.13 |
| | I think it depends on whether it builds on every step along the way | 14:03.33 |
| sebras | tor8: well... you know my position on this so I'll refrain from chiming in on this. | 14:07.28 |
| tor8 | sebras: thing is there are a hundred commits so making sure the cluster doesn't become unavailable for a week is also an issue :) | 14:08.05 |
| sebras | tor8: I guess robin would be able to kick the cluster and just test the very last commit..? | 14:08.48 |
| | tor8: but you could of course compile test this locally. | 14:09.13 |
| Robin_Watts | tor8: We have options... | 14:09.25 |
| tor8 | sebras: bisecting should work, and that's the only real issue IMO | 14:09.29 |
| sebras | tor8: yes. | 14:09.41 |
| Robin_Watts | For henrys last big commit, I ran an overnight test to make sure it compiled at every stage before he committed. | 14:09.54 |
| sebras | tor8: preferably compiling as well, but if there are visual regressions along the way that are later on fixed... meh. | 14:10.04 |
| Robin_Watts | If we limit ourselves to 72dpi ppm (and skip mujstest) say, then that overnight test will run fast enough. | 14:10.46 |
| tor8 | Robin_Watts: there are three warnings in the lcms2 module that look like they were introduced by mvrhel | 14:11.59 |
| | ContextID = ContextID; | 14:12.04 |
| sebras | Robin_Watts: skipping mujstest would be safe as well since you are not doing anything with forms stuff..? | 14:12.12 |
| Robin_Watts | sebras: Yes, and it's SLOW. | 14:12.33 |
| sebras | Robin_Watts: oh. why is that? | 14:12.45 |
| Robin_Watts | Those should probably be (void)ContextID; | 14:12.52 |
| | sebras: Dunno, but mujstest takes twice as long to run as mupdf, for a much smaller number of files. | 14:13.09 |
| tor8 | it's the interactive forms random stabbing about with events clicking on the page | 14:13.30 |
| Robin_Watts | Yeah, but I don't know exactly what part of it is slow. | 14:13.58 |
| tor8 | Robin_Watts: I think it would be fine to disable mujstest and rejig a new set once we get forms and stuff working on a desktop viewer | 14:14.26 |
| | I expect I'll break everything once I get around to that (oh, how I keep procrastinating) | 14:14.55 |
| Robin_Watts | tor8: "short term" disabling of mujstest will turn into permanent disabling :( | 14:15.16 |
| tor8 | we haven't touched the forms and events code that mujstest tests in *years* | 14:15.32 |
| Robin_Watts | indeed. | 14:15.36 |
| tor8 | and I've been meaning to rejig that code and expose it to JNI and mujs for a while now | 14:16.07 |
| | and make a desktop viewer using it | 14:16.14 |
| | but, well, procrastination's my master! | 14:16.23 |
| sebras | tor8: well.. my master now contains a commit you can review! | 14:18.25 |
| | compiles fine with gcc, I' | 14:19.08 |
| | ll try it with clang too in a bit. | 14:19.13 |
| tor8 | agh, git logg and gitk is annoying now with umpteen different lcms-branches taking up so much space | 14:19.30 |
| sebras | tor8: good motivation to merge them? | 14:19.50 |
| tor8 | sebras: LGTM | 14:20.19 |
| sebras | tor8: compiled fine with clang too. | 14:20.33 |
| | tor8: do I wait for dabu to come back to test the commit out, or do we gamble on that this fixes the errors he saw? | 14:20.56 |
| | s/this fixes/this completely fixes/. | 14:21.09 |
| tor8 | sebras: regardless of whether it fixes the errors he saw it's a commit I want in :) | 14:21.33 |
| avih | tor8: this patch has been suggested to allow avoiding shared lib on windows, while also allowing avid downstream to improve it with proper shared lib on windows: http://sprunge.us/BdPU | 14:22.53 |
| tor8 | sebras: the first 6 commits on sebras/wip also LGTM (though some of those are mine...) | 14:23.14 |
| | avih: sure, I can do something like that | 14:23.51 |
| avih | k, thanks | 14:24.21 |
| tor8 | avih: on tor/master now | 14:26.44 |
| avih | k. will let you know. thanks. | 14:26.57 |
| sebras | tor8: yeah, I have been meaning to ask you about the how to compile mupdf for android one's though. | 14:28.37 |
| | tor8: 1) have update those commits since you wrote them and 2) shouldn't the android ones go into mupdf-android-* | 14:29.08 |
| | ? | 14:29.11 |
| | tor8: tough perhaps not how to build the mupdf android library. | 14:29.30 |
| tor8 | yeah, but the files in mupdf/docs are what go on the web page | 14:31.20 |
| sebras | tor8: does that happen automagically? | 14:31.37 |
| tor8 | no, I scp them over manually | 14:31.53 |
| avih | tor8: how should it be installed now from clean git clone? make install or make install-static both complain on "error: one.c: No such file or directory" | 14:33.11 |
| | (when cross compiling from linux to windows - used to work till yesterday) | 14:33.43 |
| sebras | tor8: then I'll push up to and including c0cd3add to master, ok? | 14:40.02 |
| tor8 | sebras: ok. | 14:41.36 |
| | avih: really? one.c is part of the dependency chain... | 14:41.45 |
| | and one.c is checked in | 14:42.59 |
| avih | tor8: i'm seeing this, after git reset --hard && git clean -xfd : https://0x0.st/liH.txt | 14:43.09 |
| sebras | tor8: btw, as I mentioned over at #gs maybe https://github.com/google/oss-fuzz#accepting-new-projects might make sense for mupdf/mus? | 14:44.06 |
| | mujs. | 14:44.09 |
| tor8 | make clean removes one.c, but the 'release' target should recreate it | 14:44.15 |
| | oh, it might be because of the -j8 | 14:44.30 |
| | yeah. | 14:44.41 |
| | hm. | 14:44.43 |
| Robin_Watts | sebras: sounds interesting. | 14:45.43 |
| tor8 | avih: new commit on tor/master | 14:50.08 |
| avih | checking | 14:50.17 |
| | tor8: works for me. thanks :) | 14:55.57 |
| | how did it go with the lcms(2?) thingy | 14:56.05 |
| Robin_Watts | avih: Still going... | 14:59.19 |
| avih | oh, i got that impression too but tor said he'll have time once it's done, so i assumed i missed it crossing the finish line :) | 14:59.55 |
| Robin_Watts | tor8: Is there much stopping us from pushing it as is? | 15:00.13 |
| | I've fixed the java (subject to a review), and you've fixed the javascript, right? | 15:01.01 |
| avih | tor8: fwiw, at least one place which provides daily mpv builds for windows already incorporated mujs https://github.com/shinchiro/mpv-winbuild-cmake/commit/eaf80dc . though that's not the official mpv windows build | 15:03.30 |
| tor8 | Robin_Watts: no serious blockers that I can think of | 15:35.39 |
| | I might do a second look through a squished commit tomorrow | 15:35.49 |
| | see if I catch any other oddities | 15:35.55 |
| sebras | tor8: I just tried my ibus input method with mupdf-gl and the characters don't show up. just so you know. | 15:43.24 |
| tor8 | sebras: okay. can we investigate that tomorrow or next week? | 15:59.17 |
| | I'm signing off now. | 15:59.24 |
| sebras | tor8: oh, and today is your birthday right? | 15:59.42 |
| Robin_Watts | Night tor8 | 15:59.45 |
| | Oh, happy birthday. | 15:59.49 |
| tor8 | sebras: yes. time for cake! | 15:59.51 |
| sebras | tor8: happy birthday! :) | 15:59.56 |
| tor8 | thanks! | 16:00.09 |
| kens | THe cake is a lie :-) | 16:00.15 |
| sebras | tor8: and you are out tomorrow? | 16:00.15 |
| tor8 | no, I will be here tomorrow | 16:00.22 |
| kens | Happy Birthday tor8 | 16:00.25 |
| tor8 | kens: no, I've prodded at the cake. it's delicious and moist! | 16:00.39 |
| kens | O.O | 16:00.52 |
| tor8 | night all | 16:01.47 |
| Robin_Watts | sebras: Shame tor has left: https://stackoverflow.blog/2017/06/15/developers-use-spaces-make-money-use-tabs/ | 16:14.17 |
| sebras_ | Robin_Watts: I saw that a minute ago. :) | 16:15.04 |
| sebras | Robin_Watts: I'm guessing we should reimplement mupdf/gs in clojure..? | 16:17.39 |
| | Robin_Watts: then it would matter less if we use tabs or spaces. | 16:17.53 |
| kens | Lisp.... | 16:18.16 |
| Robin_Watts | has escaped orwell, and ML, thanks :) | 16:18.39 |
| sebras | kens: I _am_ translating clisp to swedish at the moment... | 16:20.04 |
| kens | That seems like a lot of work | 16:20.18 |
| sebras | kens: 1500 text strings or so. | 16:20.31 |
| kens | Surely Mandarin woudl make more sense :-) | 16:20.37 |
| sebras | kens: still a bit too difficult. perhaps in the future! :) | 16:21.56 |
| | Robin_Watts: I took one of the slower mujstest files and ran it locally. | 16:23.43 |
| | Robin_Watts: seems like whenever we see a click even we run pdfapp_onmouse() which in turn runs pdfapp_updatepage() a couple of times. | 16:24.39 |
| | Robin_Watts: this happens for every CLICK command in the script, and some scripts have a lot. | 16:24.57 |
| kens2 | Well that was odd. Windows just died. Totally shut off, no Blue Screen of Death or anything :-( | 16:25.30 |
| sebras | Robin_Watts: so one of the reasons mujstest is SLOW is that we redraw the pages a LOT. | 16:26.32 |
| Robin_Watts | sebras: Oh, yes, after every interaction. | 16:26.49 |
| sebras | Robin_Watts: do we need to redraw the page during testing when a widget is focused? | 16:30.00 |
| | Robin_Watts: or at all? I think we'd only need to redraw it just before handling the SCREENSHOT command, no..? | 16:30.37 |
| Robin_Watts | sebras: If the appearance of the page might change, yes. | 16:30.45 |
| | (I dunno if we change the appearance of the page when we focus something. It's WAY too long since I looked at this stuff. Or almost long enough). | 16:31.12 |
| sebras | good night! | 17:06.33 |
| dabu | sebras, I'm really sorry I couldn't be here sooner. I can see that your day is over now, so I'll report back tomorrow | 17:20.48 |
| kroovy | hi, is there way to open a pdf scrolled to a specific page with mupdf? | 18:57.19 |
| Robin_Watts | kroovy: short answer, no. | 20:47.14 |
| | long answer, what version of mupdf? | 20:47.23 |
| | (if linux or windows, it's an easy enough fix, probably) | 20:48.04 |
| kroovy | Robin_Watts: i use a openbsd port | 20:54.39 |
| | what would be the attempt? | 20:54.48 |
| Robin_Watts | kroovy: I just looked at the mupdf viewer code for x11. | 22:50.19 |
| | Try: mupdf filename.pdf pagenumber | 22:51.03 |
| | so mupdf pdf_reference17.pdf 100 | 22:51.10 |
| | Forward 1 day (to 2017/06/16)>>> | |
Log of #mupdf at irc.freenode.net.