| | <<<Back 1 day (to 2017/01/17) | 20170118 |
| sebras | tor8 (for the logs): if we're going to have new android devs clone mupdf-android-viewer-nui and then simply compile it from within android studio then I'm not sure we can keep cmapdump etc as they cannot be compiled for the host system by ndk. BUILD_HOST_EXECUTABLE is not supported. | 00:52.20 |
| vtorri | tor8: hello | 11:23.53 |
| | tor8: mupdf 1.10a generates several source files for fonts with fontdump | 11:24.31 |
| | tor8: are all of them necessary for a compilation on mac, windows and linux platforms ? | 11:24.54 |
| tor8 | morning vtorri | 11:40.50 |
| | vtorri: which ones are required depends on the exact font set you want. see the comment at the head of source/fitz/noto.c and the "TOFU" section in include/mupdf/fitz/config.h | 11:41.54 |
| vtorri | tor8: thank you | 11:43.30 |
| | tor8: also, I think that in Makerules, MSYS2 is not supported | 11:44.06 |
| | in MSYS2, uname returns: | 11:44.13 |
| | MSYS_NT-6.1 | 11:44.22 |
| tor8 | vtorri: hm, try adding a line at the top of Makerules | 11:44.59 |
| | OS := $(OS:MSYS%=MINGW) | 11:45.09 |
| vtorri | ok, i've launched the compilation | 11:45.49 |
| | tor8: compilation failed | 11:49.01 |
| | https://thepasteb.in/p/pghQ10R2R4RSR | 11:49.31 |
| | it seems that it anyway tries to compile X stuff | 11:49.55 |
| tor8 | it looks like _WIN32 might not be set using MSYS2? | 11:50.14 |
| | ah, no, I just haven't updated Makethird to allow building GLFW for windows using the makefile | 11:51.32 |
| | make HAVE_GLFW=no | 11:53.39 |
| vtorri | tor8: seems good, now | 11:57.12 |
| | tor8: do you plan to release a mupdf 1.10b for the windows fix ? | 13:04.40 |
| tor8 | vtorri: no. we only officially support visual studio for windows, and I'm not going through the hell that is cooking a release for such a minor detail. | 13:23.07 |
| vtorri | tor8: so maybe in 1.11 ? | 13:26.12 |
| sebras | Robin_Watts: oh, wrong channel... android-ndk-profiler... :) | 14:33.15 |
| | Robin_Watts: I'm unsure what it was supposed to profile, the C-code I assume? | 14:48.54 |
| Robin_Watts | sebras: Yes, the C code. | 15:16.56 |
| sebras | Robin_Watts: I don't think there is merti in carrying over the ndk profiler changes to the new app. I read on android-ndk-profilers webpage that this library has been abandoned. | 18:25.09 |
| Robin_Watts | sebras: Sure. It was the best of a bad lot when I used it. | 19:08.49 |
| | If there is something better out there, we should use that. At any rate it's not a hugely important thng. | 19:09.15 |
| sebras | Robin_Watts: I'm just wary of carrying stuff over from -old to -nui that we aren't using or don't know how to use any more. | 19:27.00 |
| Robin_Watts | sebras: Sure. If we ever need it, then we'll put it back. | 19:27.16 |
| | I'd like to hope that Android Studio would have something for profiling in. | 19:27.52 |
| sebras | Robin_Watts: I can see individual java functions and it is measured in ms and calls and callstacks | 19:39.10 |
| | but nothing in the C-code of course. | 19:41.23 |
| Robin_Watts | Right. It's the C code that's the interesting bit to us. | 19:44.41 |
| sebras | Robin_Watts: the Java code too though. | 19:44.55 |
| Robin_Watts | Not in terms of profiling, so much, I would have thought. | 19:45.11 |
| sebras | Robin_Watts: we might do silly things by mistake at all levels. | 19:45.13 |
| Robin_Watts | true. | 19:45.17 |
| sebras | Robin_Watts: since I didn't find any profiling info over at android.com I found this https://www.virag.si/2015/08/profiling-native-ndk-code-in-android/ | 19:46.05 |
| | that blogpost along with its comment suggests that native profiling is... not so easy. | 19:46.51 |
| Robin_Watts | So, given we don't have tegra devices (well, I have one, but it's old), 3 is out. | 19:47.03 |
| sebras | I might try android_ndk_perf since I happen to have a nexus 10. | 19:47.11 |
| Robin_Watts | OK. | 19:47.26 |
| | but honestly, this isn't a priority. | 19:47.42 |
| sebras | but it has version 5.1.1 so that might cause issues. | 19:47.43 |
| | I'll keep the android_ndk-stuff out of the make files. | 19:48.05 |
| Robin_Watts | cos we can profile the code on the pi, and have a reasonable expectation of it being the same. | 19:48.14 |
| | crap. I appear to have killed the cluster. | 19:52.10 |
| sebras | Robin_Watts: optmizing the scripts? | 19:52.38 |
| Robin_Watts | Trying to fix stuff I broke before, yeah. | 19:52.51 |
| sebras | Robin_Watts: in pdf_recognize() we check for the .pdf extension and the pdf mimetype, but what is the magic being pdf that we're checking for? | 19:56.47 |
| Robin_Watts | sebras: PDF files should begin %!PDF-1.xxx | 19:57.17 |
| sebras | I know, but we're checking for magic being "pdf"... | 19:57.43 |
| Robin_Watts | or at least, that should appear within the first 1K (IIRC) of the file. | 19:57.43 |
| | sebras: offhand, I don't know, and I'm trying to fix the cluster ATM. | 20:01.04 |
| sebras | np, if you knew it would save some detective work. | 20:01.31 |
| Robin_Watts | magic is the mimetype, is it not? | 20:02.16 |
| sebras | seems to be something used in android when the input is a stream..? | 20:02.40 |
| Robin_Watts | tiff or image/tiff | 20:02.50 |
| sebras | Robin_Watts: my understanding was that only image/tiff was a recognized mimetype. this is why I'm wondering what just "tiff" is. | 20:03.35 |
| Robin_Watts | See the docs for fz_open_document_with_stream | 20:04.03 |
| | mimetypes are many and varied. | 20:04.12 |
| | people abuse them terribly, so we check the obvious candidates. | 20:04.38 |
| sebras | right, then checking for simply "tiff" is basically a workaround for bogus library clients or frameworks using mupdf. | 20:07.13 |
| Robin_Watts | yes. | 20:07.48 |
| araxe | mvrhel: any news about mupdf porting in uwp? | 22:08.39 |
| | Forward 1 day (to 2017/01/19)>>> | |
Log of #ghostscript at irc.freenode.net.