| | <<<Back 1 day (to 2016/11/14) | 20161115 |
| Robin_Watts | tor8: openjpeg commit on robin/master | 13:11.50 |
| tor8 | Robin_Watts: 2 commits LGTM, as do the 2 commits on sebras/master | 13:21.23 |
| Robin_Watts | Thanks. | 13:23.52 |
| sebras | tor8: did you merge the commits on sebras/master or are you waiting for me? | 15:33.18 |
| Robin_Watts | sebras: I believe tor8 has OK'd them, but has not pushed them. | 15:35.11 |
| | I will check out the curl build now. | 15:35.17 |
| sebras | Robin_Watts: on win32? Excellent . | 15:36.10 |
| Robin_Watts | sebras: build fails. Let me try and fix it. | 15:43.58 |
| sebras | Robin: ok, I tried to fix the vcproj and add the lib directory to get at the curl_setup.h header. | 15:46.00 |
| Robin_Watts | sebras: It looks like their vcproj is out of date :( | 15:47.05 |
| sebras | Robin_Watts: oh, upstreams?! | 15:48.16 |
| | Robin_Watts: hrm... | 15:48.18 |
| | Robin_Watts: are you able to resolve the issue? | 16:05.31 |
| | Robin_Watts: in that case we can send a patch upstream and put it on origin/mupdf until it is properly merged (or delay 1.10 until your fix hits curl/master) | 16:06.04 |
| Robin_Watts | sebras: I am resolving it now. | 16:07.16 |
| | I am happy that my resolved version will be fine for MuPDF. I am not so happy that it will be correct enough to pass upstream. | 16:07.43 |
| | I would suggest that we report it to them and then take their fix when it appears rather than offering ours. | 16:07.58 |
| | But use ours in the meantime. | 16:08.06 |
| sebras | ok | 16:08.11 |
| Robin_Watts | Ok, so my updated commit is on robin/sebras_master | 16:22.11 |
| sebras | Robin_Watts: let me check. | 16:22.25 |
| Robin_Watts | sebras: Oh, hmm. | 16:22.29 |
| | And the commit in question is on the curl repo as sebras_new | 16:23.18 |
| sebras | Robin_Watts: oh. axtls.c is no in lib/vtls..? I simply removed it from our make file | 16:24.43 |
| | and it built successfully! | 16:24.49 |
| | to me that means that we don't really need it. | 16:25.03 |
| Robin_Watts | sebras: We may not need it. | 16:26.20 |
| | I started out trying to guess where stuff had gone, and then just removed everything it was missing and added stuff back in to patch the missing symbols. | 16:26.51 |
| ray_laptop | tkamppeter: ARE YOU PUTTING ALL THOSE "A5" bugs in, OR DID YOU GET YOUR ID HACKED ???? | 16:34.40 |
| sebras | Robin_Watts: I think there are more files we can remove. | 16:35.08 |
| | Robin_Watts: let me work on that a bit. | 16:35.15 |
| Robin_Watts | ray_laptop: It's not til. Til is just the assignee. | 16:35.35 |
| ray_laptop | Robin_Watts: oh, sorry I misread it | 16:35.59 |
| | it is "fujioka" | 16:36.38 |
| Robin_Watts | sebras, fredross-perry, tor8: I've been having a conversation with a free user about windows builds of the mupdf JNI code. | 16:41.10 |
| fredross-perry | yes? | 16:41.29 |
| Robin_Watts | He's suggested that we should have the JNI code look for different named DLLs according to whether it's on a 64 or 32bit platform. | 16:41.47 |
| | currently we load mupdf_java | 16:42.00 |
| | I'm thinking that on a 64bit platform we'd look for mupdf_java64 instead ? | 16:42.16 |
| fredross-perry | better to do mupdf_java32 and mupdf_java64 I think. Just to be clear. | 16:42.47 |
| sebras | yeah I like that suggestion, but I'm not sure I understand why we cannot use the same filename..? | 16:43.10 |
| | is there something preventing this? | 16:43.18 |
| Robin_Watts | In jmupdf (another java wrapper project, I guess) it looks for mupdf_java on macos, mupdf_java32 on 32bit, mupdf_java64 on 64bit. | 16:43.28 |
| | sebras: The idea is to build a single jar that contains the compiled java and both JNIs and then works on any platform, I guess. | 16:43.59 |
| | i.e. if you want to have both in the same build, you can't use the same name. | 16:44.17 |
| | Let me pastebin this code... | 16:44.41 |
| | http://pastebin.com/WSjRic3n | 16:45.07 |
| | That makes it seem like both windows and linux would change name, but macos would not. | 16:45.47 |
| | Does macos insist on 32bit builds for java DLLs? | 16:46.02 |
| | If I change the JNI to load mupdf_java32 and mupdf_java64 libraries, then we ought to update the makefiles to make them like that. | 16:49.38 |
| fredross-perry | There are 32- and 64-bit JVMs for OSX. Not sure about Java 7, may only be 64-bit. | 16:49.42 |
| Robin_Watts | Updating the MSVC projects to make different named things is easy, I think. | 16:50.08 |
| | I fear makefiles might be harder... | 16:50.36 |
| fredross-perry | Sorry, I mean "There are 32- and 64-bit Java 6 JVMs for OSX" | 16:51.46 |
| Robin_Watts | fredross-perry: Hmm. Windows is on java 8. | 16:52.10 |
| fredross-perry | Not sure if Java 7 and 8 have 32-bit versions for Windows. Maybe they do. | 16:52.40 |
| Robin_Watts | Java 8 is available on mac, 64bit only. | 16:53.22 |
| | 7 is 64bit only. | 16:53.39 |
| fredross-perry | yes | 16:53.42 |
| Robin_Watts | OK, so it seems reasonable to go 64bit only on mac. | 16:53.48 |
| fredross-perry | but 6 is 32 and 64. | 16:53.50 |
| Robin_Watts | but I suspect we don't care about supporting 6. | 16:54.03 |
| fredross-perry | agreed (64 onl mac) | 16:54.04 |
| Robin_Watts | but we can still call the dll mupdf_java64 | 16:54.16 |
| fredross-perry | yes | 16:54.23 |
| Robin_Watts | so I need a way to detect 64 or 32bit in a Makefile. | 16:55.28 |
| | I could do a tiny C program that checked sizeof(void *)? | 16:55.57 |
| fredross-perry | look here? http://stackoverflow.com/questions/714100/os-detecting-makefile | 16:58.08 |
| Robin_Watts | Ta. | 16:58.22 |
| | Will need to update the android build stuff too. | 16:59.10 |
| fredross-perry | can this be trusted: getconf LONG_BIT | 16:59.38 |
| | says 64 on my system. | 16:59.47 |
| | my OSX system. | 16:59.53 |
| Robin_Watts | That stackoverflow thing assumes gnu make. | 17:00.16 |
| fredross-perry | getconf LONG_BIT works on Linux too | 17:03.06 |
| Robin_Watts | If that's returning the OS setting rather than the target of the compiler, that's no good. | 17:04.05 |
| | cos (for example) I have a 64bit linux VM that I use, but I can do 32bit builds on it with appropriate flags. | 17:04.31 |
| fredross-perry | no, I think it's not the compiler target. | 17:05.43 |
| Robin_Watts | fredross-perry: I'll have to google to understand how getconf works to see how it can be. | 17:08.50 |
| fredross-perry | ok | 17:08.58 |
| Robin_Watts | misread your previous comment. Too many negatives :) | 17:11.02 |
| chrisl | Robin_Watts: getconf is just a exe called from the shell, so it won't reflect the compiler, or compiler flags in a makefile | 17:22.50 |
| sebras | oh. so openssl is really two libraries, libcrypto and openssl. | 17:27.39 |
| | who knew?! | 17:27.41 |
| Robin_Watts | libcrypto and libssl, I think? | 17:33.36 |
| sebras | Robin_Watts: yeah, but we really don't need libssl if we only use it for the signature checking. | 17:34.03 |
| | Robin_Watts: then libcrypto suffices. | 17:34.08 |
| | Robin_Watts: would suffice..? | 17:34.23 |
| Robin_Watts | pass. | 17:35.55 |
| | tor8, sebras, fredross-perry: 3 commits on robin/master. | 17:49.13 |
| | (Ignoring the top 2) First 2 are innocuous, 3rd one is the 32/64bit stuff. Let me know what you think. | 17:50.10 |
| fredross-perry | looks legit. | 17:54.15 |
| | what does fz_buffer_storage do? | 17:55.07 |
| | tor8, sebras, robin_watts: two can play at this game. I've got six commits on my mupdf master for review. | 17:58.23 |
| sebras | fredross-perry: do we depend on new features in the later gradle versions? | 18:00.31 |
| | fredross-perry: or why do we need to update it? | 18:00.39 |
| fredross-perry | I don't think so. | 18:00.54 |
| sebras | fredross-perry: but that is the version you have tested with? | 18:01.07 |
| fredross-perry | yes | 18:01.13 |
| sebras | fredross-perry: right, then it makes sense to me to update anyway. :) | 18:01.32 |
| fredross-perry | Right. Users will be doing that anyway. | 18:01.50 |
| sebras | fredross-perry: oh? is that done automagically by the tools? | 18:02.30 |
| fredross-perry | No, but the tools ask you if you want to update, and some people will do it. | 18:03.18 |
| Robin_Watts | fredross-perry: fz_buffer_storage returns buf->len and writes buf->data into the pointer argument. | 18:03.35 |
| | I hid the implementation of fz_buffer in a recent commit, hence we can no longer just say buf->len, and buf->data. | 18:04.00 |
| sebras | fredross-perry: aha, so we want the version to reflect the version we tested with, and if users tested with something else we have no idea if it might work. | 18:04.10 |
| fredross-perry | I think that's always true. | 18:04.59 |
| | robin - I see. | 18:05.03 |
| sebras | fredross-perry: your fling patch looks plausible, but I cannot say I entirely understand the math in there. | 18:07.38 |
| | fredross-perry: or where the magic numbers 3, 5, 400 and 600 come from. (400 might come from the default value in smoothscrollBy() though). | 18:08.08 |
| Robin_Watts | enum { SMOOTH_SCROLL_AMOUNT = 400 }; etc, maybe. | 18:11.01 |
| sebras | Robin_Watts: private static final blah BLAH would follow the style better. | 18:11.56 |
| Robin_Watts | oh, it's java. Sorry. | 18:12.13 |
| | of course. | 18:12.17 |
| sebras | I'm sensing that I ought to be able to get the math, but no. :) | 18:12.25 |
| | Robin_Watts: didn't they add enums recently? | 18:12.35 |
| Robin_Watts | OK, updated version of my 32/64 commit online (fixed android builds). | 18:12.41 |
| | possibly. | 18:12.43 |
| fredross-perry | They are numbers I cooked up after some trial and error. I can invent some names for them and make them static ints. | 18:12.48 |
| Robin_Watts | fetches freds stuff. | 18:12.51 |
| sebras | fredross-perry: ok, so they are genuinely arbitrary? | 18:13.22 |
| fredross-perry | The math basically arranges for a farther fling over a somewhat lengthened time, when you fling faster. | 18:13.35 |
| Robin_Watts | fredross-perry: I thought I'd reviewed the "fix to maintain center" before? | 18:13.42 |
| fredross-perry | you did, in NUI. | 18:13.52 |
| | I think. | 18:13.55 |
| sebras | fredross-perry: it seemed to me that the height/3 + 5 * height / 3 * ratio out to mean something about scroll at most one third of the size of the viewport or something like that. | 18:14.02 |
| Robin_Watts | Ah, ok. | 18:14.06 |
| fredross-perry | sebras - the idea is that you'r | 18:15.16 |
| sebras | fredross-perry: concerning toStructuredText() I think you should be able to call toStructuredText() without arguments now and it should automagically work. | 18:15.20 |
| Robin_Watts | fredross-perry: All (apart from the WIP one that I didn't look at) look good to me, EXCEPT for the fact that the Author and Committer fields are still wrong and need to be fixed. | 18:15.56 |
| sebras | fredross-perry: tor8 noticed your patch and had me make the JNI-bindings accept no argument so you don't have to add the string for no reason (especially since the previous comment according to your patch shows some confusion about what these are :) ) | 18:16.17 |
| fredross-perry | sebras - the idea is that you fling anywhere from h/3 to 2h, depending on the fling speed. And that it takes anywhere form 400 to 1000 msec, also depending on the speed. | 18:16.56 |
| sebras | fredross-perry: ah! now I get it! :) | 18:18.10 |
| | fredross-perry: ok, apart from what I have mentioned above these patches look ok to me. | 18:21.05 |
| | fredross-perry: I did not review the WIP commit either. | 18:21.24 |
| fredross-perry | I am going to fix toStructuredText, and the magic numbers and then you can re-review. Thanks. Stay tuned | 18:22.33 |
| Robin_Watts | and fix your committer/author names :) | 18:23.02 |
| sebras | Robin_Watts: macos is 64 bit only? how come? | 18:24.44 |
| Robin_Watts | sebras: The JVMs for macos are only available in 64 bit for for java 1.7 and 1.8 | 18:25.12 |
| sebras | Robin_Watts: if I claim that you accidentally got curl/openjpeg updates into the JNI 32/64bit commit, would I be reading the diff correctly? | 18:28.53 |
| | Robin_Watts: is the simple layertest file up for review too? | 18:29.31 |
| Robin_Watts | You would. I forgot to submodule update when coming back from your branch. | 18:29.43 |
| | sebras: No. | 18:29.47 |
| | That was an example I threw together for a customer. | 18:29.55 |
| | I should delete it cos it's on a branch. | 18:30.07 |
| | Will fix my cockup. | 18:30.17 |
| | Ok, updated commit online. Thanks for spotting that. | 18:31.57 |
| fredross-perry | OK, I fixed toStructuredText, and the magic numbers. | 18:32.13 |
| | thanks | 18:32.17 |
| sebras | Robin_Watts: LGTM. | 18:33.49 |
| Robin_Watts | sebras: Thanks. | 18:33.56 |
| sebras | fredross-perry: I think you missed the 2nd call to .toStructuredText() in DocPageView. | 18:35.14 |
| fredross-perry | feck. | 18:35.19 |
| sebras | fredross-perry: and if you reorder your patches so the GSDLLCALL thing is below your WIP patch, then I think that is good to go in as well. | 18:35.53 |
| fredross-perry | will do. | 18:36.05 |
| Robin_Watts | fredross-perry: But PLEASE fix your commit/author names before pushing! | 18:36.21 |
| fredross-perry | please remind me how to do that, and how did it change, I though I fixed that long ago. | 18:36.53 |
| Robin_Watts | fredross-perry: git config --global user.name="Joe Blow" | 18:37.41 |
| | fredross-perry: git config --global user.email="JoeBlow@Blow.com" | 18:37.54 |
| | That will fix it for future commits. | 18:38.13 |
| | To fix the existing commits... you'll need to do a git rebase -i HEAD~10 or something, and set all your commits to 'r' for reword I guess. | 18:39.23 |
| | Touching the commits messages should hopefully update at least the committer field. | 18:39.48 |
| fredross-perry | swell, trying. | 18:40.15 |
| Robin_Watts | Updating the author field may require git rebase -i HEAD~10 and setting them all to 'e' so you can do some git magic at the command line for each one. | 18:40.27 |
| | bug 697301 is an error in the bidi code. Yuck. | 18:45.40 |
| sebras | Robin_Watts: please take a look at sebras/master | 18:47.23 |
| | Robin_Watts: I noticed that https had stopped working, but using my openssl patch it now works again. | 18:47.46 |
| | and we get curl updated as well. | 18:47.59 |
| | Robin_Watts: but again I need your help in compiling thig. | 18:48.10 |
| Robin_Watts | Is there not a readme file that needs updating too? | 18:48.51 |
| fredross-perry | Robin: git commit --amend --author "Fred Ross-Perry <fred.ross-perry@artifex.com>" | 18:49.03 |
| Robin_Watts | Nice. | 18:49.13 |
| fredross-perry | all set on my master. | 18:49.17 |
| Robin_Watts | sebras: I can't find an SSL reference in the readmes. | 18:50.08 |
| sebras | Robin_Watts: ok..? I'm not sure what to repond to that. :) | 18:50.31 |
| Robin_Watts | sebras: It means "ignore my previous question about if you need to update a readme" :) | 18:50.55 |
| sebras | Robin_Watts: ah! my eyes lost it in the discussion anyway. :) | 18:51.30 |
| Robin_Watts | Is your thirdparty/curl different to mine now? | 18:51.56 |
| sebras | Robin_Watts: yes, I merged curl-7_51_0 once more. | 18:52.20 |
| | on top of your patch. | 18:52.26 |
| Robin_Watts | sebras: So I need to rebuild to retest? | 18:52.32 |
| sebras | that seems to be the correct way to go..? | 18:52.33 |
| | Robin_Watts: I would say yes. | 18:52.47 |
| Robin_Watts | Urm... That feels odd to me. | 18:53.58 |
| | The solution file that I updated came from curl-7_51_0 right? | 18:54.20 |
| sebras | Robin_Watts: oh! | 18:54.30 |
| | Robin_Watts: ok, in that case the merge should go before your update! | 18:54.40 |
| Robin_Watts | Didn't it? | 18:54.43 |
| sebras | Robin_Watts: no. :) | 18:55.00 |
| Robin_Watts | Unless I'm even more confused than usual, I think so. | 18:55.01 |
| sebras | Robin_Watts: you missed the merge. :) | 18:55.06 |
| fredross-perry | Robin_Watts: when I build I now get libmupdf_java32.so for Android. Is that what you expect? | 18:55.16 |
| Robin_Watts | fredross-perry: Yes. | 18:55.24 |
| fredross-perry | ok thanks | 18:55.30 |
| Robin_Watts | I think I've updated everything to load that new name. | 18:55.35 |
| | If I've missed anything please slap me. | 18:55.50 |
| fredross-perry | checking it now... | 18:56.08 |
| | but can I slap you in any case? Post-election anger management. | 18:56.28 |
| | oops | 18:56.32 |
| Robin_Watts | :) | 18:56.50 |
| sebras | Robin_Watts: ok, I think have updated the patches and repos now. | 18:57.34 |
| Robin_Watts | gitk doesn't show much changing in the merge... | 19:00.25 |
| sebras | git diff 41fc6eb..af06fe0 | 19:00.56 |
| Robin_Watts | Ok, but diff does. | 19:00.58 |
| | :) | 19:01.01 |
| sebras | sometimes these tools are a bit too smart. | 19:01.20 |
| Robin_Watts | Hmmm.... | 19:02.38 |
| | git diff f82bbe0..af06fe0 | 19:03.01 |
| sebras | Robin_Watts: yes..? | 19:03.16 |
| fredross-perry | Robin - two issues with getLibraryName. (1) use getLibraryName(), not getLibraryName(void). (2) return "mupdf_java32" needs a semicolon. | 19:03.25 |
| sebras | Robin_Watts: I didn't want to include curl/master as they haven't been declared "stable" by upstream. | 19:03.42 |
| Robin_Watts | fredross-perry: D'Oh. How did that build then? | 19:04.25 |
| fredross-perry | dunno | 19:04.38 |
| Robin_Watts | sebras: That diff command should give the difference between the master curl branch and our merge of it. | 19:04.55 |
| | sebras: Yes? | 19:05.05 |
| sebras | Robin_Watts: no, that diff should show the diff between curl/master and 7.51.0 and any local patches we have I think. | 19:05.45 |
| fredross-perry | Robin - and then, System.getProperty("sun.arch.data.model") returns null. | 19:06.03 |
| Robin_Watts | fredross-perry: On macos ? | 19:06.52 |
| fredross-perry | no, Android. | 19:06.58 |
| Robin_Watts | crap. bloody android being different. | 19:07.13 |
| | But again, how did the mupdf I built and installed run on my phone? | 19:07.32 |
| | sebras: af06fe0 = the state after we have merged. | 19:08.24 |
| | OK, so I should have done: | 19:08.39 |
| | git diff curl-7_51_0..af06fe0 | 19:08.52 |
| | If you run that diff command, you would expect to see just our local changes showing really, right? | 19:10.08 |
| sebras | Robin_Watts: yes, that's what I would expect. | 19:10.43 |
| Robin_Watts | Instead of which I see lots of things which haven't been pulled over from the curl release - including new VS stuff. | 19:10.45 |
| | I fear the merge is bad. | 19:10.53 |
| | Oh, no, wait.... | 19:12.03 |
| | I see. Curl have REMOVED the vs solution. | 19:13.38 |
| | So I understand now. | 19:13.45 |
| sebras | Robin_Watts: actually I think may we added it ourselves in 40d5eb1db3bcb0640987440a7274bf94284855d2..? | 19:14.45 |
| Robin_Watts | sebras: gitk f82bbe0 -- vs | 19:15.07 |
| | That shows you the commit where they removed it. | 19:15.17 |
| sebras | git show f82bbe0 shows me "curl: add --fail-early"..? | 19:15.50 |
| Robin_Watts | mupdf-curl builds OK for me with your latest commit, so I reckon that's good. | 19:15.50 |
| | yes. | 19:16.06 |
| | "gitk f82bbe0 -- vs" says "show me all the commits prior to f82bbe0 that touched 'vs'" | 19:16.36 |
| sebras | Robin_Watts: ok, and in which commit are you claiming that they removed their vc.proj-file? | 19:17.19 |
| | .vcproj | 19:17.23 |
| | I'm claming that we created it from scratch on origin/mupdf | 19:17.46 |
| Robin_Watts | 29d790fe6053ba8bb0b4ade48a6fe8b98ab189d9 | 19:17.47 |
| | Hmm. OK, I think you might be right. | 19:18.11 |
| | They remove a lot of other vs clobber, but not the vcproj file. | 19:18.21 |
| malc_ | sebras: how does one clam? | 19:18.26 |
| Robin_Watts | It's a more modest form of claim. | 19:18.51 |
| | There is no I in clam. | 19:18.55 |
| | sebras: So you're right. | 19:19.10 |
| sebras | Robin_Watts: so then we're good to go on the curl thingies..? | 19:19.57 |
| Robin_Watts | Yes. | 19:24.11 |
| sebras | Robin_Watts: sweet. | 19:24.19 |
| | Robin_Watts: then I'll push origin/sebras_new as origin/mupdf and remove sebras_new | 19:24.47 |
| Robin_Watts | I'm still trying to figure out how my java changes didn't break everything | 19:25.20 |
| sebras | Robin_Watts: yeah, they broke my java build too. | 19:25.34 |
| Robin_Watts | And yet, not mine. | 19:25.47 |
| | OH! | 19:25.56 |
| | Idiot. Testing the android build does not test the java code. | 19:26.11 |
| malc_ | Robin_Watts: oh there is... in BE | 19:27.01 |
| sebras | Robin_Watts: aha! so I might have messed up on my own. when building platform/java we build build/java/libmupdf.a but when doing to we ask make to detect at compile time whether the system has openssl/libcrypto | 19:30.19 |
| | Robin_Watts: and of course it does! | 19:30.27 |
| | Robin_Watts: so we turn on all the HAVE_-flags | 19:30.41 |
| Robin_Watts | ah, whoops. | 19:30.56 |
| fredross-perry | Robin - for Android, looking for "dalvik": http://pastebin.com/Gj1xBpc2 | 19:31.02 |
| sebras | Robin_Watts: later on we compile the .so but at that point we forget the flags that were used to compile the .a-libraries. | 19:31.05 |
| Robin_Watts | git pull --rebase golden master | 19:31.12 |
| | Stupid not-focussed shell. | 19:31.32 |
| | fredross-perry: 1 commit on robin/master to fix my java ineptness, I hope. | 19:31.55 |
| | fredross-perry: dalvik isn't used in M or above though, right? | 19:32.26 |
| fredross-perry | I'm running N and it works. | 19:32.41 |
| | but I could be wrong. | 19:32.51 |
| Robin_Watts | I thought that they'd changed to ART ? | 19:33.07 |
| fredross-perry | Anyway, maybe this is best put in JNI? So you can do sizeof some data thingy | 19:33.14 |
| Robin_Watts | fredross-perry: OK, so they return Dalvik for both Dalvik and ART. | 19:34.33 |
| fredross-perry | For the time being. | 19:34.44 |
| Robin_Watts | fredross-perry: To put it in JNI, it'd need to go into the .dll. | 19:34.55 |
| | That's the thing that we are trying to load :) | 19:35.02 |
| fredross-perry | hm. | 19:35.06 |
| | I hate it whan you're right. | 19:35.14 |
| Robin_Watts | It happens so rarely though. | 19:35.25 |
| fredross-perry | ;-) | 19:35.39 |
| Robin_Watts | Stackoverflow has some suggestions, but they seem to rely on knowing you're building for android. | 19:36.17 |
| | One possibility is just "try to load the 64bit .dll. If that fails, load the 32bit one" | 19:36.54 |
| | try { System.loadLibrary("mupdf_java64"); } catch (Throwable) { System.loadLibrary("mupdf_java32"); } | 19:38.57 |
| fredross-perry | Robin - I am OK with what you have now. But maybe put comments in that talk about all the cases we know we're covering. | 19:39.11 |
| Robin_Watts | fredross-perry: Sure. Will amend. | 19:39.27 |
| fredross-perry | actually I'm not. Sorry. | 19:41.38 |
| | if (val == null || val.equals("64")) : we get null on Android, s this would return mupdf_java64. | 19:42.22 |
| | But we want mupdf_java32 for Android, yes? | 19:42.36 |
| Robin_Watts | yeah, I have that fixed here. | 19:47.01 |
| | git push -f origin master | 19:47.13 |
| | This is why I have all my passwords as expletives. | 19:47.36 |
| | If I type them in the wrong window, no one can tell. | 19:47.46 |
| | Ok, updated version online. | 19:47.59 |
| sebras | Robin_Watts: you cannot net /* comments */ | 19:51.14 |
| | Robin_Watts: so the Android comment in the comment terminates the comment and causes javac to complain for me. | 19:51.37 |
| Robin_Watts | sebras: Thanks... | 19:51.49 |
| sebras | Robin_Watts: np. | 19:52.13 |
| Robin_Watts | Try that? | 19:52.46 |
| | Thanks for testing this stuff for me. | 19:52.53 |
| sebras | Robin_Watts: works for me. | 19:54.45 |
| | oh, and I get a libmupdf_java32.so on my 32-bit linux. | 19:55.22 |
| Robin_Watts | sebras: Fab. | 19:57.51 |
| fredross-perry | Robin - android compiler does not like your block comment that also includes braces. | 19:58.03 |
| Robin_Watts | ?!? | 19:58.36 |
| | Am I alone in thinking that's just wrong of it? | 19:59.01 |
| fredross-perry | sorry, it's this (I think): * /* Android */ | 20:00.04 |
| Robin_Watts | fredross-perry: Ah, you're a version behind, I think. | 20:00.22 |
| | (Sorry, I cocked up) | 20:00.27 |
| fredross-perry | I am not going NEAR that lovely expression ..... | 20:00.47 |
| | Ah, better. | 20:01.43 |
| | OK, I'm good with it | 20:03.18 |
| Robin_Watts | Thanks. | 20:03.36 |
| sebras | Robin_Watts: ok, care to look at sebras/master once more? | 20:04.04 |
| Robin_Watts | sebras: looks plausible to me. | 20:05.45 |
| sebras | Robin_Watts: nice. let's hope that tor8 shares your opinion tomorrow. | 20:06.21 |
| | I'll also cluster it to make sure I haven't broken anything. | 20:06.44 |
| Robin_Watts | I'll try fixing the bidi crash tomorrow. | 20:07.15 |
| sebras | sleeps | 20:09.28 |
| | Forward 1 day (to 2016/11/16)>>> | |
Log of #ghostscript at irc.freenode.net.