| | <<<Back 1 day (to 2016/06/13) | 20160614 |
| sebras | tor8: I need help in understanding the regression output. | 11:10.59 |
| | tor8: if you click on sebras I see the main report | 11:11.18 |
| | tor8: listing the differences from trunk | 11:11.29 |
| | tor8: it list 110 differences for the mupdf tests first | 11:11.54 |
| | tor8: after that there is a section on regression that have started producing errors. | 11:12.09 |
| | tor8: and it is this section I don't understand. | 11:12.17 |
| chrisl | sebras: the code detecting existing/new errors isn't perfect, so occasionally you get a "new" error reported that isn't new | 11:13.23 |
| sebras | chrisl: ah. because I'm seeing the same error log and same exit code on both... | 11:13.55 |
| | chrisl: is the timeout detection test equally unstable? | 11:15.25 |
| chrisl | sebras: Yes, for certain files. If the file is already on the edge of the timeout, then small change in the code can trip it or, more usually, the cluster node doing something else at the time the test runs can cause it to trip | 11:16.39 |
| sebras | chrisl: I wonder what the timeout is. | 11:17.43 |
| | chrisl: I'm hoping that it is something competely unreasonable like 5min or so. | 11:18.01 |
| chrisl | sebras: obviously, I would check the file in question to make sure the time it takes *is* still reasonable | 11:19.02 |
| sebras | chrisl: it takes 10ms on my laptop... | 11:21.34 |
| | chrisl: however from the command line used in the log it seems as if it is not using the normal mutool draw to render. | 11:22.16 |
| | chrisl: but mupdf doesn't build pdfshow any more, only mutool draw | 11:23.01 |
| | pdfdraw, obviously. | 11:23.08 |
| tor8 | sebras: Robin_Watts: oh bollocks, the CJK quotes U+201C and U+201D characters in droid sans fallback are not fullwidth, but we've got a file that assumes they are resulting in badly mangled text :( | 11:24.34 |
| Robin_Watts | tor8: Surely we lay stuff out with 'widths' ? | 11:25.59 |
| | so at worst they should be a bit too spaced out? | 11:26.16 |
| chrisl | sebras: FWIW, I would do another clusterpush, in case the timeout(s) were just an aberation | 11:26.53 |
| tor8 | Robin_Watts: at best they'll be oddly placed in their 'boxes' (flush left in its box, rather than sitting at the right edge) | 11:27.31 |
| | this file has them drawn at explicit coordinates, not relying on the actual glyph widths | 11:27.53 |
| | bug 696836 | 11:28.30 |
| ts1690 | hiya. am getting compile error vs2012 with debug but not release: pdf-js.c(568): fatal error C1083: Cannot open include file: 'gen_js_util.h': No such file or directory | 11:29.10 |
| tor8 | arguably, the file is badly behaved because it has used explicit positioning to 'kern' away the whitespace it assumes is on the left edge of the fullwidth opening quote | 11:29.14 |
| Robin_Watts | Right, but even so, they shouldn't overlap with anything. | 11:29.14 |
| ts1690 | what actually generates that file? | 11:29.22 |
| tor8 | and that kerning puts it right on top of another glyph | 11:29.23 |
| Robin_Watts | tor8: right. | 11:29.41 |
| | ts1690: What platform/config are you building for ? | 11:30.26 |
| ts1690 | also you said yesterday Robin that libfonts is not needed for the mupdf library. freetype is though yes? sorry to interrupt your current discussion | 11:30.26 |
| | Debug x64 | 11:30.49 |
| Robin_Watts | ts1690: libfonts is required. Not sure it needs to be x64 though. I could be wrong though... | 11:31.12 |
| ts1690 | i am trying to integrate mupdf into an existing system, it already has freetype so have removed it from the downloaded mupdf build, am i right in understanding i only need libmupdf? | 11:32.04 |
| tor8 | ts1690: generate.bat should generate that file | 11:32.31 |
| ts1690 | so generate.bat should be run automatically yes? | 11:33.00 |
| tor8 | ts1690: it should, yes | 11:33.09 |
| ts1690 | hmm | 11:33.14 |
| Robin_Watts | ok, you're right, libfonts is needed. | 11:33.15 |
| tor8 | you may need to clear out the 'generated' folder to make it regenerate properly | 11:33.20 |
| | libfonts has the embedded font data that mupdf needs | 11:33.33 |
| ts1690 | so to integrate mupdf into a system i need libfonts.lib, libmupdf.lib libthirdparty.lib, should that do it? | 11:34.13 |
| Robin_Watts | Ugh. Many size_t to int warnings. | 11:34.21 |
| ts1690 | will try clearing the generated folder thanks tor | 11:34.29 |
| sebras | tor8: ok, so after having run through the cluster twice I now believe the results I'm seeing. do you or I push to master? | 11:34.30 |
| tor8 | Robin_Watts: I'm still not 100% convinced moving to size_t solves any real issues ... it just postpones them on some platforms (from 2GB to 4GB limit) | 11:35.00 |
| | sebras: go ahead | 11:35.23 |
| Robin_Watts | tor8: The change that went in last week was to allow pixmaps > 4Gig. | 11:35.36 |
| sebras | tor8: this is scary. | 11:36.14 |
| tor8 | Robin_Watts: maybe we should have moved to intptr_t then? | 11:36.16 |
| | that should be 64-bit with 64-bit pointers, and 32-bit with 32-bit pointers | 11:36.30 |
| Robin_Watts | tor8: No. size_t was the right thing to use. | 11:36.33 |
| | Now, to fix the warnings I'm seeing now, might require ptrdiff_t.... | 11:37.13 |
| ts1690 | the release build doesnt complain about the gen_js_util.h file and in fact its not there anywhere in the folders. so is release and debug different regarding generated files? | 11:37.42 |
| tor8 | ts1690: the generated files should be common between release and debug | 11:40.53 |
| ts1690 | it just doesnt seem to be generated | 11:41.31 |
| Robin_Watts | ts1690: I think the invovation for generated.bat is wrong in the 64bit project file. | 11:41.46 |
| ts1690 | cannot see it in the folders on release or denug | 11:41.50 |
| | ah ok Robin, can i fix it? | 11:42.03 |
| Robin_Watts | Yeah, just copy the nmake settings from 32bit to 64bit. | 11:42.18 |
| | I'm doing it here now, and will put up a commit for review in a bit. | 11:42.29 |
| ts1690 | hmm is that easy? | 11:42.31 |
| | ah ok thanks | 11:42.36 |
| | you have svn? git? | 11:43.00 |
| | is wierd have managed to compile it sometimes | 11:43.38 |
| Robin_Watts | git | 11:43.52 |
| ts1690 | k thx | 11:44.08 |
| | you have a url handy? | 11:44.17 |
| | nm will go seek | 11:44.26 |
| Robin_Watts | tor8: Updated tiff commits on robin/master, plus MSVC build fixes. | 11:48.15 |
| sebras | tor8: Robin_Watts: eeep! I just pushed to golden. that was a bit scary... :) | 11:51.29 |
| tor8 | Robin_Watts: LGTM | 11:51.47 |
| Robin_Watts | sebras: Congrats :) | 11:52.16 |
| tor8 | Robin_Watts: bah, there are still double constants | 11:52.28 |
| | "0." | 11:52.31 |
| sebras | tor8: hm... robin was logged out/in so he might have missed your message. | 11:53.05 |
| tor8 | and some odd tabs and 'register' keywords | 11:53.10 |
| Robin_Watts | sebras: I saw the lgtm, and I saw you say you'd pushed to golden. | 11:53.33 |
| tor8 | Robin_Watts: the TIFF SGI commit still has "0." constants and some odd tabs and 'register' keywords | 11:53.49 |
| Robin_Watts | tor8: will check, thanks. | 11:53.57 |
| tor8 | regular TIFF commit, 64-bit fixes, muraster LGTM | 11:54.12 |
| Robin_Watts | I see 2 places where I got "0." instead of "0". Do you see more ? | 11:56.48 |
| | Updated commit online. | 11:57.24 |
| | I have (1.f/UVSCALE) which is required cos UVSCALE = 410. | 11:58.56 |
| tor8 | Robin_Watts: ah, the libmupdf.vcproj reordering changes in the TIFF SGI commit, would be nice if they could be merged with the other MSVC fixes or split to a separate commit | 12:00.19 |
| Robin_Watts | tor8: will split. | 12:00.33 |
| | Ah, sebastian just rewound the mujs changes. | 12:04.56 |
| tor8 | Robin_Watts: sebras: d'oh! I missed that line in the diff when reviewing :( | 12:06.36 |
| Robin_Watts | tor8: OK, first 3 commits should be good to go (still working on muraster) | 12:06.42 |
| | tor8: easy to do. submodules are a pain. | 12:06.50 |
| tor8 | Robin_Watts: especially with git add -u | 12:07.02 |
| sebras | tor8: Robin_Watts: aw, crap. my apologies. what do we do now? | 12:08.23 |
| tor8 | Robin_Watts: LGTM | 12:08.32 |
| Robin_Watts | sebras: One of my commits puts it back. don't sweat it. | 12:08.42 |
| sebras | or rather how do you want me to fix it? | 12:08.42 |
| | Robin_Watts: ok. hm... just what you need when pushing to golden for the first time. :-( | 12:09.16 |
| Robin_Watts | sebras: no biggie. | 12:09.44 |
| | ts1690: OK, fixed version committed to git. | 12:10.13 |
| ts1690 | excellent thanks Robin will check it out (pun not intended) :) | 13:08.08 |
| | wow 12 out of 12 win x64 compiled out of the box! Slight fix on Release mode: Configuration manager for lib fonts on x64 Release is currently unticked and win32. Generated on debug and release is win32. Except for that "Good job guys!" :) | 13:22.34 |
| Robin_Watts | ts1690: Thanks. Will fix that. | 13:24.29 |
| | Thunderstorm here. If I get disconnected, I apologise. | 14:03.41 |
| jogux | Robin_Watts: did you get the flash floods etc down by you? | 14:12.21 |
| Robin_Watts | Not that I am aware of. | 14:12.37 |
| | I'm in a high bit of the village. | 14:12.48 |
| jogux | maybe passed the north of you. Milton Keynes had some very very heavy rain storms Sunday/Monday. | 14:13.19 |
| Robin_Watts | We do get the odd bit of flooding here, but it tends to only happen after several solid days of rain when the ground upstream is utterly sodden and everything just runs off. | 14:13.20 |
| marcosw | Robin_Watts: what is the output format from mutool draw -o test.pam supposed to be? It claims cmyk in the header but ImageMagick renders the output as entirely black. If I add -c cmyk to the command line the header doesn't change but ImageMagick converts the file correctly. | 18:51.28 |
| Robin_Watts | marcosw: pam can be any format. | 19:02.50 |
| | any color space, sorry. | 19:03.03 |
| | I think it's rgb by default. | 19:03.08 |
| | { OUT_PAM, CS_RGB_ALPHA, { CS_GRAY, CS_GRAY_ALPHA, CS_RGB, CS_RGB_ALPHA, CS_CMYK, CS_CMYK_ALPHA } }, | 19:03.30 |
| marcosw | Robin_Watts: i think it's RGBA, since it's 4 bytes/pixel but it puts CMYK in the header | 19:03.44 |
| Robin_Watts | yeah, RGB + Alpha by default, but can be any of the list. | 19:03.49 |
| | marcosw: oops. | 19:04.02 |
| | I probably broke the output routine when I added the ability to render without alpha. | 19:04.35 |
| | Will fix. | 19:04.42 |
| | Forward 1 day (to 2016/06/15)>>> | |
IRC Logs