| | <<<Back 1 day (to 2017/01/22) | 20170123 |
| gahr | hi, I'm getting an unexpected behaviour here: http://pastebin.com/NP75rGUA | 12:43.44 |
| | it looks like you can't put both a real and an int key in a dict when their arithmetic values are equal | 12:44.45 |
| Robin_Watts | gahr: Indeed, that's exactly what it looks like. | 12:45.15 |
| | I'm not sure PS differentiates between integer and real. | 12:45.50 |
| | everything is just "numbers". | 12:46.02 |
| gahr | the thing is that if I substitute (3 (Int)) with (3.0 (Real)) I'd expect to get (3.0 (Real)) back | 12:46.02 |
| | well ps per se differentiates between them, in fact you get --integertype-- and --realtype-- on them | 12:46.23 |
| Robin_Watts | Ok, so PS knows about integers and reals, but I'm not sure that you can trust that what you store is what you get back. | 12:47.05 |
| gahr | it's kind of confusing that you get the first key with the second value, isn't it? | 12:47.57 |
| | while it's true that (k1 k2 eq) is true, they are two different objects when it comes to type.. | 12:48.54 |
| chrisl | That's not how the eq operator works on numbers | 12:49.29 |
| | You need to revise your expectations | 12:49.37 |
| gahr | chrisl: I think I understand.. and it also makes sense.. since (3 3.0 eq), the second store will just replace the value, keeping the key as is | 12:51.55 |
| chrisl | gahr: yes, dictionary key matching basically works to the same rules as the eq operator | 12:52.41 |
| gahr | this clarifies a thing that wasn't clear from PLRM, that dict uses exactly the eq operator for searching | 12:52.44 |
| | that's it | 12:52.55 |
| | basically, or exactly? | 12:52.59 |
| | is there any other subtleties I need to take care of? | 12:53.09 |
| chrisl | Sorry, what I meant was, "basically, dictionary key matching uses the same rules as the eq operator" | 12:53.35 |
| gahr | thanks a lot! | 12:54.07 |
| chrisl | If you really need to differentiate between 3 and 3.0 in these cases, you probably need to convert to a string | 12:55.05 |
| gahr | makes sense | 12:57.57 |
| tor8 | Robin_Watts: got a moment? | 13:11.42 |
| Robin_Watts | Sure. | 13:11.49 |
| tor8 | two things | 13:11.54 |
| | one: libmupdf_java*.so naming ... can't remember why we have code for loading libmupdf_java32.so and libmupdf_java64.so and libmupdf_java.so with all the names | 13:12.34 |
| | is this for windows or ios or android? | 13:12.46 |
| | android always calls the library libmupdf_java.so IIRC | 13:12.53 |
| Robin_Watts | I can't remember either. | 13:14.21 |
| | oh... it might be for android... | 13:14.38 |
| tor8 | for android, wouldn't it be better to name the .so by ABI? | 13:14.48 |
| Robin_Watts | consider the case where you want to build a single .jar file with both 32 and 64bit cases. | 13:15.00 |
| tor8 | so libmupdf_java_armeabi-v7a.so, etc? | 13:15.01 |
| Robin_Watts | tor8: That would probably be nicer. | 13:15.11 |
| tor8 | two: several commits on mupdf:tor/master, including a new Android.mk which allows building the android JNI stuff without needing a full project, etc. | 13:15.19 |
| | which allows building the NUI app by calling an externalNdkBuild step | 13:15.31 |
| | which sebras has been working on getting to work | 13:15.38 |
| sebras | tor8: if you want to use the target ABI you can use mupdf_java-$(TARGET_ARCH_ABI) I believe | 13:18.04 |
| tor8 | sebras: yeah, question is how to get TARGET_ARCH_ABI from the java side of things | 13:18.41 |
| Robin_Watts | tor8: Ok, so the makefile commit has an 'android' step that depends on generate. | 13:19.39 |
| | The generate step requires a host based C compiler to be set up. | 13:19.53 |
| | So for windows, that will fall on it's ass. | 13:20.05 |
| | How about: | 13:20.14 |
| sebras | tor8: I think Build.SUPPORTED_ABIS which is a String[] would give you that information. | 13:20.37 |
| Robin_Watts | android: android_no_generate generate and then android_no_generate: being what you have there? | 13:21.12 |
| | (or does it need to be generate android_no_generate?) | 13:21.26 |
| tor8 | Robin_Watts: we could add a bat file to invoke ndk-build with the same arguments on windows?+ | 13:21.50 |
| | and that could call generate.bat | 13:21.56 |
| | a platform/java/android.bat | 13:22.47 |
| Robin_Watts | The problem is that many people developing on windows may not HAVE a host based C compiler installed. | 13:23.03 |
| tor8 | Robin_Watts: then they have a real problem | 13:23.12 |
| Robin_Watts | tor8: indeed. | 13:23.18 |
| sebras | the only way around that is to distribute a tarball where make generate has already been run | 13:23.34 |
| tor8 | if we ship SDK tarballs, I would assume they would come with the generate folder pre-created | 13:23.35 |
| Robin_Watts | Now, something that said "You need to install XXXX and do YYYY" would be a step up. | 13:23.45 |
| sebras | akin to git repos not having run autogen.sh, but tarballs having already run that script | 13:23.51 |
| Robin_Watts | sebras: Indeed. | 13:24.03 |
| | The SDK would have had that step done | 13:24.15 |
| sebras | same as tor8 said, but more verbose (as usual) | 13:24.15 |
| tor8 | Yes. I think we can assume that if you check things out with git you have a proper development environment set up. | 13:24.51 |
| | so, a script to call ndk-build on windows without needing 'make' | 13:25.11 |
| | and a script to create an SDK | 13:25.18 |
| | or do we envision the SDK to be a binary only thing? | 13:25.28 |
| | or a source thing | 13:25.31 |
| | I would hope a source thing | 13:25.42 |
| Robin_Watts | tor8: Me too. | 13:25.46 |
| tor8 | or we'll need yet another Android.mk to use prebuilt libraries, and that's ugh | 13:25.56 |
| | so, an android source sdk zipfile creator that packages up the source and generated code | 13:26.19 |
| sebras | attempting to remove the generate step altogether doesn't seem feasiable either, then we'd just depend on _another_ script language whose interpreter must be set up. | 13:26.27 |
| Robin_Watts | The problem with the "Use system Noto fonts" one is that no phone actually has all the noto fonts installed. Every phone gets a different random subset. | 13:26.54 |
| tor8 | Robin_Watts: yeah... and older phones won't have any of them. | 13:27.14 |
| | I wonder who decides which noto fonts get installed on a phone. | 13:27.43 |
| | or are they installed on an as-needed basis? | 13:27.55 |
| Robin_Watts | Could we maybe have 2 targets in the makefile. | 13:27.57 |
| | 1 for 'generate' and 1 for 'android'. | 13:28.14 |
| | No, scratch that. | 13:28.26 |
| tor8 | the android target depends on the generate target. without generate, android won't build. | 13:28.36 |
| | and with pregenerated files, 'make generate' should be a no-op. | 13:28.47 |
| | unless you change the files, in which case you really should be regenerating them | 13:29.16 |
| Robin_Watts | Can we do some clever makefile thing so that if the generate target is called on windows, it prints an error message ? | 13:29.22 |
| | CC=echo "You need to regenerate the generated data. This requires you to run generate.bat with Visual C++ installed" | 13:30.17 |
| tor8 | you mean a more userfriendly message than "I can't build this"? | 13:30.26 |
| Robin_Watts | OR make the generated target run generate.bat, and have generate.bat fail with an informative error in the case where it can't find a compiler ? | 13:30.57 |
| tor8 | well, the makefiles assume that if you're calling 'make' on windows you're using MinGW | 13:31.06 |
| Robin_Watts | The latter is probably the nicest. | 13:31.12 |
| | tor8: Urgh. | 13:31.20 |
| tor8 | the android studio externalNdkBuild step calls ndk-build directly (not via Makefile) | 13:31.32 |
| Robin_Watts | What fonts are added to what phone image is decided by the phone manufacturer. | 13:31.52 |
| | They are not downloaded as required. | 13:31.57 |
| sebras | Robin_Watts: yeah, they live in /system/fonts so definitely by the vendor | 13:33.00 |
| | Robin_Watts: I assume that android studio and the 55Gbyte that comes with it can handle NDK-based builds on windows too..? | 13:33.48 |
| | otherwise I'm not sure how this can ever work. | 13:34.44 |
| Robin_Watts | Android Studio has an ndk bundle that downloads using the update manager. | 13:34.50 |
| | that contains a windows based cross compiler for the different targets. Same as the unix stuff. | 13:35.14 |
| sebras | Robin_Watts: same on Linux, and I assume that means that when a studio project says it has an NDK-dependency that this is handled appropriately even on Windows | 13:35.30 |
| tor8 | Robin_Watts: I think a platform/win32/android.bat that calls platform\win32\generate.bat and ndk-build with proper arguments is the best way for MSVC-builds | 13:35.42 |
| Robin_Watts | sebras: Yes. | 13:35.52 |
| | tor8: Urm... the problem is people will download this, plug it into their AS builds. The AS build will call gradle. gradle will call the makefile AIUI. | 13:36.26 |
| sebras | Robin_Watts: no, the gradle script is separate. | 13:36.44 |
| tor8 | nope, gradle will call ndk-build on Android.mk. not the makefile | 13:36.48 |
| sebras | Robin_Watts: it has nothing to do with the Makefile | 13:36.54 |
| Robin_Watts | oh, OK. | 13:36.55 |
| | seems reasonable to me then. | 13:37.10 |
| tor8 | the Makefile 'android' target is just a convenience for if you want to build it without using android studio | 13:37.10 |
| Robin_Watts | tor8: right. | 13:37.18 |
| tor8 | so for an SDK we wouldn't have to worry about anything other than shipping it with 'make generate' results | 13:37.41 |
| sebras | tor8: but it will only build the NDK-parts of mupdf though. | 13:37.58 |
| tor8 | sebras: it will *only* build the JNI library, yes. | 13:38.20 |
| | it will not build any of the java sources or anything else | 13:38.29 |
| | but if you want to cook your own, you copy the libmupdf_java.so from that step and the platform/java/src classes and off you go | 13:38.55 |
| sebras | tor8: exactly. I think there is an option of building... what was it again.. .aapt? | 13:39.14 |
| tor8 | aapt is the tool to package stuff up into an APK isn't it? | 13:40.29 |
| sebras | no. aapt is the android libraries. | 13:40.40 |
| | I believe. | 13:40.43 |
| | similar to .jar but they can contain both code and data. | 13:40.54 |
| chrisl | You could ship the Windows executables required for the "generate" target | 13:41.00 |
| tor8 | chrisl: yeah, that's a good point. | 13:41.27 |
| sebras | tor8: we'd need a way to keep track of when cmapdumps dependencies change though. | 13:41.54 |
| | tor8: so we know when to regenerate the .exes | 13:42.02 |
| tor8 | sebras: shipping java classes on android needs to be compiled to dex files don't they? | 13:42.52 |
| | I think we're much safer shipping java sources | 13:42.59 |
| | but allowing to build the JNI code with a simple step and copying the binaries is going to solve a lot of people's headaches | 13:43.33 |
| | when making their own projects | 13:43.39 |
| | they just run the 'make android' thing and copy the so-files wherever in their own projects as 'prebuilt shared library' | 13:44.01 |
| sebras | tor8: my assumption is that this is not what will happen. | 13:47.29 |
| | tor8: I assume that they'd start the android studio project and extract whatever they need from there. | 13:47.50 |
| | but then again, I'm by no means any expert in how android modules are normally distributed. | 13:48.18 |
| tor8 | Robin_Watts: so the commits up to and including 'add ndk-build makefile' are good to go? | 13:50.52 |
| | but not the 'use system noto fonts' commit | 13:51.00 |
| Robin_Watts | tor8: Yeah. | 13:51.24 |
| tor8 | Robin_Watts: thanks. | 13:51.29 |
| Robin_Watts | tor8: For people putting mupdf into an embedded android device, they will want to tune the included fonts themselves. | 13:52.26 |
| | For people putting mupdf into a downloadable app - they will want to make a tradeoff between installed size, and pervasiveness of fonts. | 13:53.07 |
| tor8 | Robin_Watts: they could use the commit and tweak the TOFU bits in Android.mk | 13:53.21 |
| Robin_Watts | The gold standard way of doing that would be to enable fonts to be downloaded and added in packs as required. | 13:53.27 |
| | So having a fallback mechanism in place would be good, even if we don't use it ourselves. | 13:53.55 |
| tor8 | or change the commit to look in for app resources instead of /system/fonts | 13:53.58 |
| | yeah, the fallback callbacks are in | 13:54.11 |
| | but maybe we should not push the android /system/fonts implementation of them | 13:54.23 |
| Robin_Watts | tor8: If app/resources is what happens with 'extension data' or whatever it's called. | 13:54.30 |
| Robin_Watts | must get food before cleaners arrive. bbiab. | 13:54.55 |
| tor8 | agh, I just realized I cocked up the fallback commit. I will make a followup that fixes it properly. | 13:56.46 |
| | I only call the system callback for sans fonts, not serif fonts. | 13:56.53 |
| sebras | tor8: so it seems like the studio/gradle way of adding library usage is to simply add compile 'com.example.domain:library:1.2.3' in build.gradle and have gradle automagically download the library for you and then you can just use it. | 13:57.29 |
| | tor8: at least if I understand https://android.jlelse.eu/the-complete-guide-to-creating-an-android-library-46628b7fc879#.n9ogufgxi | 13:57.46 |
| tor8 | sebras: then we need to make a mupdf-android-library.git project for the JNI library? | 14:00.51 |
| sebras | if we care about this use case, I believe that this is the case. | 14:01.44 |
| tor8 | so then we will have a git repository dependency chain of: mupdf-android-viewer-nui -> mupdf-android-library -> mupdf -> thirdparty/* | 14:02.55 |
| sebras | yes. | 14:03.06 |
| | gradle support fetching prebuilt stuff from maven/ivy repositories apparently. | 14:03.54 |
| tor8 | hm, what's the difference between this AAR they mention and the AAPT you mentioned above? | 14:04.40 |
| sebras | I was mistaken, I meant aar. | 14:05.08 |
| tor8 | okay | 14:05.20 |
| sebras | aapt is a resource packaging tool apparently. | 14:05.20 |
| | tor8: illustrated here: https://developer.android.com/images/build.png"> class=wrapy>http://web.archive.org/web/20140715083911im_/https://developer.android.com/images/build.png | 14:05.40 |
| | tor8: I wonder how maven repositories that distribute binary packages combine with GPL though. | 14:15.16 |
| tor8 | Robin_Watts: one commit on tor/master when you got a moment | 14:32.58 |
| Robin_Watts | the serif one? | 14:34.32 |
| | lgtm. | 14:35.30 |
| tor8 | Robin_Watts: Thanks. | 14:38.40 |
| Robin_Watts | np. | 14:39.25 |
| tor8 | Robin_Watts: okay, so now the mupdf-android-viewer-nui.git should check out and build properly. | 14:43.47 |
| | thanks to sebras | 14:43.55 |
| sebras | I hope. | 14:45.47 |
| | seems to work here at least. | 14:45.53 |
| | tor8: mupdf:sebras/wip -nui:sebras/wip I just tested this on my device and it appears to work. win32 has not been tested so review carefully. | 15:19.46 |
| | Forward 1 day (to 2017/01/24)>>> | |
Log of #ghostscript at irc.freenode.net.
