| | <<<Back 1 day (to 2016/03/29) | 20160330 |
| RobinWattsLenovo | I hate trains. | 08:39.50 |
| jogux | more or less than you hate freenode? ;) | 08:44.33 |
| RobinWattsLenovo | More, much more. | 08:46.30 |
| | I don't pay for freenode. | 08:46.34 |
| jogux | :( | 08:46.37 |
| | where're you off to? | 08:46.48 |
| RobinWattsLenovo | Just into london for the morning. | 08:48.40 |
| | Ok, going to shut the hotspot down. back later. | 08:49.22 |
| tor8 | Robin_Watts: you around? | 11:41.50 |
| chrisl | tor8: Robin_Watts said earlier he was up in London "for the morning" - he didn't say exactly when he'd be back | 11:43.07 |
| tor8 | chrisl: ah, thanks. | 11:43.12 |
| | I'm seeing some very weird behaviour with the harfbuzz shaping -> fz_text output | 11:43.28 |
| | it's getting very confused when it can't encode certain characters... | 11:43.45 |
| | http://ghostscript.com/~tor/samb.xhtml | 11:44.18 |
| RobinWattsLenovo | tor8: Hi. | 12:47.11 |
| | What problem are you seeing? | 12:47.27 |
| tor8 | Robin_Watts: mutool draw -Ftrace to see the issues | 13:06.41 |
| | U+2165 is missing completely, the space characters aren't ever added to the fz_text, and lots of text after the missing U+2165 have ucs=-1 | 13:07.18 |
| | RobinWattsLenovo: ^ | 13:07.39 |
| RobinWattsLenovo | I'm on the train at the moment, so not hugely easy to do that at the moment. I'll look as soon as I get home. Sounds like a mistake in my code extracting from the harfbuzz stuff. | 13:08.46 |
| tor8 | U+1e43 is found in the fallback font, and that word gets messed up completely | 13:08.54 |
| | yes, it looks like the cluster mapping stuff is going crazy | 13:10.33 |
| Robin_Watts | tor8: OK, was a simple cockup on my part. | 15:20.46 |
| | But it's revealed leaks, so I'll have a look at that too. | 15:21.04 |
| tor8 | Robin_Watts: so, I finally got the old android viewer to build using gradle | 15:23.32 |
| | but I'm fast running out of patience... | 15:23.41 |
| Robin_Watts | Which gradle? :( | 15:24.54 |
| tor8 | exactly! | 15:25.04 |
| | I finally found gradle 2.2 and got that installed | 15:25.13 |
| | the version on gradle.org is 2.12 | 15:26.08 |
| Robin_Watts | I reckon we should be shooting for using the latest version of the android studio gradle plugin. The one that comes with 2 (which is still in beta), which I hope is unchanged in 2.1 (which is in preview) | 15:26.10 |
| | pedro_mac knows more about this than me. | 15:26.31 |
| tor8 | FAILURE: Build failed with an exception. | 15:26.31 |
| | * Where: | 15:26.31 |
| | Build file '/home/tor/src/mupdf/platform/android/example/app/build.gradle' line: 2 | 15:26.31 |
| | * What went wrong: | 15:26.31 |
| | A problem occurred evaluating project ':app'. | 15:26.31 |
| | > org.gradle.api.Project.getPluginManager()Lorg/gradle/api/plugins/PluginManager; | 15:26.32 |
| pedro_mac | Robin_Watts: Iâd agree; the problem Iâve found is that weâre often running into issues with mismatched gradle and plugin versions, combined with dependencies between Android Studio and corresponding plugin versions. Iâm not sure if 2.1 will retain the same model since the bleeding edge experimental plugin has changed it to clean up the scopes & naming so the existing gradle files donât work with it | 15:30.04 |
| tor8 | I have found a clue ... one project seems to be referring to gradle 2.10 and the other one to gradle 2.2 | 15:30.32 |
| pedro_mac | Iâve just switched to 2.0beta7 because Iâm not 100% convinced about the 2.1 Preview | 15:30.33 |
| tor8 | egads what a mess | 15:30.35 |
| Robin_Watts | I was hoping that they'd have gotten that change out of the way :( | 15:31.01 |
| pedro_mac | tor8: there was a bug in android studio a few versions back where it thought 2.10 was less than 2.2, but that has been fixed afaik | 15:31.19 |
| Robin_Watts | So, should we all shoot for android studio 2.0beta 7 and live with that? | 15:31.29 |
| | Then we can fix any problems when 2.1 actually comes out | 15:32.11 |
| tor8 | Robin_Watts: well, given that we should drop a release soon I'm going to suggest we drop trying for any kind of gradle support in this release | 15:32.21 |
| pedro_mac | thereâs another issue with that unfortunately; they introduced checks to make builds fail if the beta versions of the plugin were out of date (roughly monthly) | 15:32.27 |
| | you can set an environment variable to supply the SHA of the rlevant plugin version to let it build, but we wouldnât really want to do that in a release | 15:33.27 |
| Robin_Watts | tor8: Well, as long as we have *a* method of building all the different things, then I can live without gradle for not. | 15:33.30 |
| | s/not/now/ | 15:33.39 |
| tor8 | the old viewer still builds with ndk-build and ant | 15:33.45 |
| pedro_mac | I think Android Studio 1.5 is still the latest âstableâ version | 15:33.49 |
| tor8 | I can't get the new viewer to build even with gradle at the correct version | 15:33.53 |
| | it's not invoking any kind of ndk build | 15:33.58 |
| Robin_Watts | And we can say "We'll do a gradle release whenever they finally stop messing with it" | 15:34.11 |
| pedro_mac | Iâd be inclined to do that | 15:34.24 |
| | tor8: does the gradle file include the relevant jni directory definitions? I thought mupdf had its source files somewhere other than the default location? | 15:35.39 |
| tor8 | pedro_mac: no idea, I just started looking at fredross-perry's code | 15:36.03 |
| Robin_Watts | tor8: Ah, the leaks are because htdoc_open_document is not setting refs to 1, so the doc is never being dropped properly. | 15:37.02 |
| pedro_mac | tor8: np - the gradle projects are set up with default paths for the java and jni sources. If the project needs to keep its sources elsewhere then you need to explicitly set the jni path variables in the gradle build file. | 15:38.01 |
| tor8 | pedro_mac: the build.gradle I'm looking at just has a hardcoded sharedLibraryFile = file("libs/armeabi-v7a/libmupdf_java.so") line in it | 15:40.21 |
| pedro_mac | ah, so youâre not actually building the code, just including a prebuilt .so? | 15:40.49 |
| | that should be easier then :) | 15:41.06 |
| tor8 | pedro_mac: we don't have prebuilt .so's ... I was expecting this build file to actually build libmupdf_java.so | 15:41.27 |
| | otherwise the build system is kinda pointless :) | 15:41.38 |
| pedro_mac | tor8: ok, but if you want that then gradle needs to know where the source is | 15:42.17 |
| tor8 | pedro_mac: we have three bits of source that need to be built; the C code and JNI wrappers need to be cross compiled into a libmupdf_java.so. that's the regular mupdf library, and platform/java/mupdf_native.c | 15:44.23 |
| | the common classes that reference the JNI functions, which we have in platform/java/com/artifex/mupdf/fitz/*.java | 15:44.33 |
| | and the actual example app | 15:44.40 |
| | fredross-perry: I'm having trouble building the new example viewer | 15:44.49 |
| sebras | tor8: did you have time to look at sebras/master? | 15:50.33 |
| | tor8: I picked up fredross-perry's patch so that we again can build the (old) android app on master | 15:50.58 |
| tor8 | sebras: I am also fixing that bug in the big java directory structure/build system reorg commit I'm working on now | 15:51.45 |
| fredross-perry | tor8: I need to write some instructions. You have to build the old view and then pull a .so file out of it and copy it to the new viewer. | 15:52.08 |
| Robin_Watts | tor8: 2 commits on robin/master then. | 15:52.16 |
| | both 1 liners. | 15:52.18 |
| sebras | tor8: oki, great. I needed that yesterday when trying to build the android app. | 15:53.22 |
| fredross-perry | so grab libs/armeabi-v7a/libmupdf_java.so from the old viewer and copy it to the mupdf folder of the new viewer | 15:54.12 |
| tor8 | Robin_Watts: that fixes one of the oddities (the -1's and duplicated text) | 15:54.18 |
| | I'm still missing the .notdef for the character we can't encode | 15:54.36 |
| Robin_Watts | Ah, the VI? | 15:55.44 |
| tor8 | the VI goes missing completely | 15:55.51 |
| Robin_Watts | That's a separate bug. Will fix. | 15:55.55 |
| tor8 | and, depending on the font used we sometimes get space characters, sometimes not | 15:56.18 |
| | fredross-perry: thanks. I finally got it running on my tablet! | 16:08.34 |
| fredross-perry | tor8: sweet. I see that we also need libgs.so. But not sure where customers will get that from. | 16:09.26 |
| tor8 | fredross-perry: for the example viewer we don't | 16:09.42 |
| fredross-perry | did you take it out of the build? | 16:09.58 |
| | itâs referenced in platform/android/viewer/mupdf/build.gradle | 16:10.30 |
| tor8 | fredross-perry: yes. we shouldn't need it. libgs is only for the 'gproof' support. | 16:10.32 |
| Robin_Watts | libgs.so is just for GPROOF builds, and no one should be doing them really. | 16:10.33 |
| fredross-perry | Right. So just remove it from the build file then. | 16:11.09 |
| | iâve removed it from mine (on my master) | 16:17.40 |
| tor8 | fredross-perry: okay, I've got it building and sorted the makefiles and directory renames on tor/master. | 16:19.50 |
| | if you could test that and let me know what I broke I'd be grateful | 16:22.28 |
| fredross-perry | tor8: looking now. | 16:22.31 |
| Robin_Watts | tor8: So... if we use the displaylist, we don't get spaces or that glyph. | 16:23.52 |
| | If we avoid the displaylist, we DO get spaces and that glyph. | 16:24.07 |
| | Is the displaylist not playing back non-marking things maybe? | 16:25.03 |
| | Yeah, spaces are sent through with NULL rects. | 16:28.45 |
| | so they are elided by the displaylist playback code. | 16:29.12 |
| | OK, so that glyph fails to be found in any font, so we end up sending it as Times Roman, ucs=8549, gid=0 | 16:34.13 |
| | Times Roman doesn't use a [] char for gid 0, hence we see it as an unmarking glyph. | 16:34.50 |
| | hence it doesn't appear in -Ftrace when we don't use the display list. | 16:35.03 |
| tor8 | ah, so it's display list dependent... hmm. | 16:35.38 |
| | that seems, not good. we don't want to drop notdef glyphs, even if the font has them invisible. | 16:36.17 |
| | step one: make the .notdef glyph visible for our base 14 fonts. | 16:37.53 |
| | my trick with replacing it with a bullet doesn't work with harfbuzz shaping | 16:38.07 |
| fredross-perry | tor8: all seems good. I also want to revise the exampleâs java source to further simplify. I got rid of the âgraphicsâ folder and the PageCanvas class. | 16:41.58 |
| Robin_Watts | If we want not to elide spaces, then we probably need to make fz_bound_text return a non zero bounding box for spaces. | 16:42.38 |
| | tor8: So... you want to bend the base14 fonts to include a visible notdef char ? | 16:45.24 |
| tor8 | fredross-perry: go for it. just be aware that I changed the package name to com.artifex.mupdf.example | 16:47.21 |
| fredross-perry | I see that. Can I just push a commit to your master then? | 16:47.38 |
| tor8 | Robin_Watts: I think that would be best; and also non-zero bounding box for spaces | 16:47.41 |
| | fredross-perry: yeah, you can work off the commits on my master | 16:48.49 |
| | we'll need to rebase and reword the commit message a bit (remove the WIP since it seems to work) | 16:49.06 |
| Robin_Watts | tor8: So I'm going to let you bend the base14 fonts. | 16:53.04 |
| | I'll look into bending fz_bound_text to give a non-zero bounding box for spaces. | 16:53.05 |
| | Presumably we want a non-zero bounding box for ALL non marking glyphs? | 16:53.05 |
| tor8 | I wonder why it's coming out as zero | 16:53.06 |
| Robin_Watts | I could make it so that if the bbox based on the outline is empty, I'd fudge one based on the advance of the glyph and the font bbox for the height ? | 16:53.06 |
| tor8 | I guess because they're using accurate bboxes? | 16:53.06 |
| Robin_Watts | tor8: We take the bbox of the outline, yes. | 16:53.06 |
| tor8 | I thought we only did that for fonts loaded with use_glyph_bbox set to true | 16:53.17 |
| Robin_Watts | I'm looking at fz_bound_ft_glyph | 16:53.34 |
| tor8 | in fz_new_font we set bbox_table to NULL if use_glyph_bbox is false | 16:54.26 |
| Robin_Watts | Are we going to break PDF by having notdef be visible ? | 16:54.29 |
| tor8 | Robin_Watts: No. we might break it more by having it not visible :) | 16:54.48 |
| fredross-perry | tor8: I appear not to have permission to commit to your master. check your email, I sent you the (new) complete source for the example. Just replace what you have with that. | 16:55.27 |
| tor8 | fredross-perry: okay, I'll drop those files in and update the commit | 16:55.51 |
| fredross-perry | make sure to replace the folder so âgraphicsâ and âPageCanvasâ get deleted. | 16:56.27 |
| Robin_Watts | fredross-perry: In general, no, you can't commit to other peoples repos. The done thing is to pull their branch to your repo, then add/modify commits there, and they can pull it back if you want. | 16:56.58 |
| | s/you want/they agree with the changes/ | 16:57.13 |
| fredross-perry | robin: thanks. | 16:57.43 |
| tor8 | fredross-perry: okay, I've squished your changes into the example viewer commit and re-pushed that to tor/master | 17:02.29 |
| fredross-perry | sweet. checking... | 17:02.39 |
| tor8 | fredross-perry: cleaned up the tab/space stuff while I was at it. | 17:03.42 |
| fredross-perry | sweet | 17:03.48 |
| tor8 | Robin_Watts: html-doc should be calling fz_new_document instead of fz_malloc_struct. | 17:06.11 |
| | I thought I'd changed all the document handlers to do that... :/ | 17:06.17 |
| | and that sets the refs to 1 | 17:06.39 |
| Robin_Watts | tor8: Will fix it to do that. | 17:11.58 |
| tor8 | Robin_Watts: I've also tweaked font handling a bit for EPUB | 17:12.46 |
| | on tor/master | 17:12.50 |
| | and some experiments on tor/urw | 17:12.54 |
| | I wanted to see if we could use the Noto fonts as default, so needed a way to expose our built in fonts by name | 17:13.35 |
| Robin_Watts | Use the Noto fonts as default for what ? | 17:13.52 |
| tor8 | so a user.css with: html { font-family: "Noto Serif" } should do that | 17:14.04 |
| | default font for epub | 17:14.08 |
| | it would help with getting weird font mismatches when one glyph in the middle of a word gets subbed | 17:14.23 |
| Robin_Watts | Right, that makes sense. | 17:14.27 |
| tor8 | but it's pretty ugly :( | 17:14.30 |
| | but with this commit, there's at least a way to do it if you want to use noto serif as your body text font | 17:14.46 |
| Robin_Watts | Uglier than Times Roman? | 17:15.01 |
| tor8 | IMO, yes. | 17:15.06 |
| | but Times Roman is also a pretty terrible font | 17:15.17 |
| | Charis SIL would be a very good default font, but that's a pretty big chunk of font data to embed | 17:15.33 |
| Robin_Watts | Ok, so updated ref commit on robin/master, with another one to fix bounding spaces. | 17:19.21 |
| tor8 | Robin_Watts: fab, all 3 LGTM | 17:20.18 |
| fredross-perry | tor8: looks good. | 17:21.05 |
| tor8 | fredross-perry: thanks. I'll see about getting it pushed tomorrow. It's getting dinner time here now. | 17:21.34 |
| fredross-perry | all right | 17:21.59 |
| Robin_Watts | tor8: All the commits on tor/master up apart from the last 2 look OK to me. | 17:36.28 |
| | I'm not looking at the last 2 - leaving that to you and fred unless you specifically want it looked at. | 17:36.49 |
| | If I had a criticism of the earlier commits it would be that there are some magic numbers in there. (*4, + 2, [12] etc) that might be nicer done as enums, but that's a small thing and they are mostly clear from context. | 17:37.45 |
| | The urw stuff seems reasonable. Presumably that'll be bent for notdef stuff tomorrow though. | 17:38.37 |
| | Is it April already? http://techcrunch.com/2016/03/30/be-very-afraid-hell-has-frozen-over-bash-is-coming-to-windows-10/ | 17:41.56 |
| | "A genuine Ubuntu image on top of Windows 10". Not a VM. Not cross-compiled tools. | 17:45.16 |
| inkbottle | Might be OT: but how do I do to have cmb10.pfb instead of Helvetica in my HelloWorld.pdf? | 17:47.01 |
| | I'm currently reading in "developing with pdf" | 17:48.32 |
| Robin_Watts | inkbottle: You reauthor the PDF from the original source format. | 17:51.24 |
| | User mode ubuntu binaries will run on windows 10. | 17:52.14 |
| inkbottle | Hum, this is my file http://paste.debian.net/422815/, I use linux debian, I'd like to replace Helvetica by /usr/share/texlive/texmf-dist/fonts/type1/public/amsfonts/cm/cmb10.pfb | 17:53.35 |
| marcosw1 | Robin_Watts: so we can stop shipping gswin32c.exe? :-) | 17:54.29 |
| Robin_Watts | inkbottle: You can't start from a PDF file, and change it to a new PDF file with different fonts. | 17:54.30 |
| | marcosw1: I typed that joke, and then thought better of it :) | 17:54.46 |
| marcosw1 | so microsoft will have to ship all of the the linux libraries?! | 17:55.18 |
| inkbottle | Robin_Watts: yes but I can't make it accept /usr/share/texlive/texmf-dist/fonts/type1/public/amsfonts/cm/cmb10.pfb | 17:55.30 |
| | it just remains on "default" font | 17:55.48 |
| Robin_Watts | inkbottle: You *CAN'T* start from a PDF file, and change it to a new PDF file with different fonts. | 17:57.02 |
| inkbottle | OK | 17:57.20 |
| Robin_Watts | And even if you could fiddle around in a PDF file to change fonts without breaking everything, PDF doesn't understand tex format fonts. | 17:57.43 |
| inkbottle | Robin_Watts: OK, thanks; I'll keep searching and I'll come back when I have new relevant questions | 18:01.30 |
| marcosw1 | Robin_Watts: you have a fastjoin running on casper that has used 4 hours of cpu time. I think you need to think of a different name. | 18:10.50 |
| Robin_Watts | marcosw1: Well, I've improved fastjoin so it doesn't infinite loop. | 18:21.01 |
| | It's very fast now, but still isn't quite giving the same results as join. Will keep fiddling later. | 18:21.26 |
| | So I've reverted to join temporarily. | 18:23.52 |
| tkamppeter | chrisl, hi | 18:25.02 |
| | Robin_Watts, hi | 18:25.39 |
| | Robin_Watts, I have a student who came with some own ideas on MuPDF. | 18:34.39 |
| Robin_Watts | tkamppeter: Hi. | 19:05.41 |
| | I did some more work on printer output. | 19:05.59 |
| | We now have mono and rgb pcl5/5c output. | 19:06.14 |
| | We have postscript image output (greyscale, rgb, cmyk) | 19:06.36 |
| tkamppeter | Great. | 19:07.39 |
| Robin_Watts | What did the student come up with ? | 19:07.55 |
| tkamppeter | Robin_Watts, what does PostScript image output mean? All text and high-level graphics is turned to a bitmap and this sent out as a PS file to the printer? | 19:08.50 |
| Robin_Watts | yes. We render to an image, then wrap that as a postscript output stream. | 19:09.16 |
| tkamppeter | Robin_Watts, the student wants to add text search facilities so that if you view a PDF on the screen with MuPDF, you can search for text, and he also told that he wants to do printing backends. | 19:10.01 |
| Robin_Watts | OK, MuPDF has the facility to do text searches, so that's certainly possible. | 19:10.41 |
| tkamppeter | Robin_Watts, this kind of PS output would be good enough for a phone. One only needs to check efficiency so that the PS-wrapped bitmap gets also printed on printers with lower memory/CPU power. | 19:12.17 |
| Robin_Watts | And new printing backends would be welcome. Presumably he's thinking of things like high level pclxl output? | 19:12.29 |
| | tkamppeter: I suspect PCL is more likely to be useful for low end printers than PS. | 19:13.04 |
| | The current PCL output is similar - it's just an image sent as graphics. | 19:13.25 |
| tkamppeter | Robin_Watts, so should the phone then if it discovers that a printer supports both PS and PCL (5/5e/5c) select PCL output? | 19:14.10 |
| Robin_Watts | tkamppeter: Possibly. But basically, if a printer supports PS, it's probably not a low end one :) | 19:14.56 |
| tkamppeter | Robin_Watts, there are actually low-end PS printers, often with insufficient memory, which do not print some PS files or take ages but in PCL they perform OK. | 19:16.10 |
| Robin_Watts | tkamppeter: Then using PCL would seem to be a good idea in those cases, yes. | 19:16.31 |
| tkamppeter | Robin_Watts, and if we go through a bitmap anyway it probably does not matter whether we actually do PS or PCL. | 19:17.15 |
| | Robin_Watts, I think that under Windows such low-end PS printers are used in PCL-mode, too. | 19:17.47 |
| | Robin_Watts, If a printer supports PS and no PCL one can probably assume that it is powerful enough to do everything in PS. Do you know any such model? | 19:18.47 |
| Robin_Watts | I do not, but then I am not up on current printers. chrisl and HenryStiles may have better knowledge. | 19:19.16 |
| | I have 2 laser printers, both PCL ones. | 19:19.34 |
| tkamppeter | Robin_Watts, so I think I will make the automatic printer setup prefer PCL over PS if both are supported, so that the mobile devices "just print". | 19:21.42 |
| Robin_Watts | tkamppeter: We still need to do some work on tuning printer margins per model etc. | 19:22.19 |
| | That's the kind of thing that a gsoc'er could help with. | 19:22.36 |
| tkamppeter | Robin_Watts, is there already a bitmap-wrapper PCL-XL backend in MuPDF? | 19:22.42 |
| | Robin_Watts, good idea. How will the margin tuning work? Poll printers? Model databases? | 19:23.19 |
| Robin_Watts | tkamppeter: Model databases I would think. | 19:23.38 |
| | The PCL output code needs to be given details of what offsets to use, and what the actual paper margins are. | 19:24.57 |
| | Mupdfs PCL output routines need to tweaked to honour those values. | 19:25.20 |
| | and then it's a question of the caller passing in the appropriate ones. | 19:25.28 |
| tkamppeter | Robin_Watts, or can one simply send a bitmap with zero margins and if the printer does not do full-bleed more or less of the pixels at the borders do not get printed? | 19:25.47 |
| Robin_Watts | tkamppeter: Sadly, it's not quite that simple. | 19:26.02 |
| | PCL has an inbuilt 1/4" offset for the left hand edge. | 19:26.18 |
| | on most models. | 19:26.38 |
| | But on other models if we adjust to avoid that, we lose the left hand edge of the data. | 19:26.58 |
| | so it requires a test page or two to be printed to work out the exact values. | 19:27.18 |
| tkamppeter | So in both cases, PS and PCL one needs a comprehensive printer database or only some quirk rules for certain manufacturers/models? | 19:31.40 |
| Robin_Watts | tkamppeter: I'm not sure. Testing would be part of the work. | 19:33.23 |
| | Defining a step by step routine to calculating the values to use would certainly be useful. | 19:33.54 |
| tkamppeter | Robin_Watts, would you mentor this student? | 19:34.15 |
| Robin_Watts | tkamppeter: I'll certainly help. | 19:38.34 |
| | (Of course, I am on holiday in August for 2 weeks) | 19:38.49 |
| | I'll certainly help him with working on the mupdf source code, or writing code to call MuPDF. | 19:39.23 |
| | I can be of limited help with the actual "interfacing to the ubuntu world" side of things though. | 19:39.53 |
| tkamppeter | Robin_Watts, the GSoC ends mid-August, so it is not such a problem with your vacation. | 19:40.06 |
| Robin_Watts | Right. I head out on Aug 20th. | 19:41.14 |
| tkamppeter | Robin_Watts, so I will invite you as mentor for the GSoC, so you only need to confirm Google's invitation e-mail and then you can see the application and click "WANT TO MENTOR". | 19:41.15 |
| Robin_Watts | Sure. | 19:41.21 |
| tkamppeter | Robin_Watts, no prob, I think there it is all over. | 19:41.40 |
| | Robin_Watts, you should have gotten mail now. | 19:50.24 |
| sebras | Robin_Watts: ok, so I have taught myself how to debug android apps using ndk-gdb now. | 23:11.51 |
| | only to find out that the issue is likely caused by someone forgetting to intitialize fz_write_options to 0. | 23:12.15 |
| | Robin_Watts: it's quite embarrassing that I closed the bug thinking that the issue was fixed (I verified it at the commit, the commit prior, the commit after, and then using 1.8). | 23:13.19 |
| | seems I was just having luck with my uninitialized stack variables. :-/ | 23:13.52 |
| | Robin_Watts: tor8: intialization commit for review at sebras/master. | 23:48.55 |
| | Robin_Watts: tor8: without the fix the android app crashes 6 out of 10 times, with the fix 0 of 10. | 23:49.42 |
| | Forward 1 day (to 2016/03/31)>>> | |
IRC Logs