| | <<<Back 1 day (to 2014/09/15) | 2014/09/16 |
| henrys | marcosw: for the logs did not get around to bisecting pdfwrite regression, I did check that the commit we thought fixed the issue (see chrisl's suggestion above) does not fix the problem. | 05:03.41 |
| | s/regression/fix ... see support email to catalin | 05:08.15 |
| marcosw_ | henrys: okay, will look at the email | 05:29.31 |
| | henrys: I just bisected the problem and came up with the commit that was discussed on irc: http://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=b442d9a0 | 05:49.03 |
| | I applied that patch to a clean copy of 9.10 and it does indeed seem to fix the problem. | 05:49.23 |
| kens | chrisl you have a minute ? | 08:38.15 |
| | Hmm, that's odd, chrisl your latest commit caused a stack of 'Error reading input file' reports | 08:42.54 |
| | That's the c_alone fix | 08:43.35 |
| chrisl | kens: Hmm, it didn't when I pushed it manually | 08:45.03 |
| kens | I'm surprised.... | 08:45.10 |
| | "Unrecoverable error: undefined in .uninstallpagedevice" | 08:45.28 |
| | I can't see how your change could do that, you didn't push something else as well by accident ? | 08:45.43 |
| chrisl | Hmm, I better zap those commits :-( | 08:46.20 |
| kens | SOmething seems to be wrong, I don't have a commit mail for the c_alone fix yet | 08:46.40 |
| | Ah, there were 2 together, OK | 08:47.10 |
| chrisl | I've killed those commits for now.... | 08:47.39 |
| kens | The BG_print one I could understand causing that error | 08:47.41 |
| chrisl | Oh, all the errors were with cups - :-( | 08:52.38 |
| kens | Ah, I hadn't noticed that. | 08:52.52 |
| | Ah yes, so they are. | 08:53.11 |
| chrisl | And it's not going wrong locally :-( | 09:00.06 |
| kens | Not even with teh same command line ? | 09:00.20 |
| chrisl | Nope | 09:00.40 |
| kens | That's not great :-( | 09:00.52 |
| chrisl | The cluster says "Unknown device: cups" | 09:01.15 |
| kens | Very odd.... | 09:01.26 |
| chrisl | I wonder if those machines have been updated and libcups has disappeared - as it has tendency to do..... | 09:02.33 |
| kens | Ah, that is possible. I did notice that it was (mostly) miles and kilmeters | 09:02.52 |
| | You could disable those two and rerun | 09:04.07 |
| | Then hassle Marcos :-) | 09:04.23 |
| chrisl | I've done a clusterpush without those two commits - do HEAD is your pdfwrite font fix | 09:06.03 |
| kens | Hmm, OK. I'm pretty sure that was OK when I pushed it | 09:06.27 |
| chrisl | kens: so, did you need something else, or was it just the cluster problem? | 09:06.34 |
| kens2 | Irritating network :-( | 09:08.41 |
| chrisl | kens2: did you need something else, or was it just the cluster problem? | 09:09.15 |
| kens2 | I did have a question, but I figured it out. A font is being synthesised as a small caps variant because of the font Flags in the PDF file. Synthesised fonts like this may put paid to capturing outlines. | 09:09.26 |
| chrisl | Aren't they already (non-font) outlines in the output? | 09:09.56 |
| kens2 | Yes, and no. | 09:10.12 |
| chrisl | Hrm..... | 09:10.31 |
| kens2 | THe problem is that we detect the missing small caps glyphs. That triggers a fallback to 'the default' | 09:10.49 |
| | Now for any glyph in the font natively (eg 'T') that produces a bitmap | 09:11.06 |
| chrisl | You mean we detect that the small caps glyphs are not charstrings? | 09:11.37 |
| kens2 | FOr any glyph not in the font (eg 'e', because its a small cap font) then we synthesise a glyph from 'E'. THat comes out as an outline | 09:11.38 |
| chrisl | Oh, I think I see..... | 09:12.14 |
| kens2 | So when I capture the outline, the 'T' works, but the 'outline' for the synthesies fonts is a 'BT...ET' sequence | 09:12.48 |
| | At which point it all gets very complicated | 09:13.13 |
| chrisl | So, (not right now!) would a way forward be to pass the flags to pdfwrite and skip the glyph synthesising part? | 09:13.20 |
| kens2 | Hmmm. | 09:14.18 |
| | I'm not certain that would work. We would need to pick up the cap glyphs and embed them, which would mean adding lots of unpleasant code to pdfwrite. As if ti werent' complicated enough already | 09:15.04 |
| | I feel it should be possible to reference another font from a PDF type 3, but I'm having trouble getting that to work | 09:16.21 |
| chrisl | OKay, could we better communicate to pdfwrite that we're using a synthesized font so it goes into generating an outline type 3 right away, rather than going to "default"? | 09:17.11 |
| kens2 | Err, no, that won't work. Right now we *do* want it to go to default, and not go to an outline. | 09:17.45 |
| | I already do this for CIDFOnts with a BuildGlyph, for pretty much this reason | 09:18.03 |
| arvind | weteg | 09:18.12 |
| chrisl | <sigh> your pdfwrite font fix, which ran without problem when you committed it, now has those errors - looks like kilometers and miles are broken | 09:18.34 |
| kens2 | Well, at least you can be reasonably assured it wasn't anything you've done. | 09:18.55 |
| | Best disable those and send email to marcos I think | 09:19.05 |
| chrisl | I've disabled them, doing another clusterpush with my commits to double check. Once that's done, I'll mail marcosw | 09:19.42 |
| kens2 | Makes sense. | 09:19.59 |
| | Well it looks like I can spot the fact that we have a type 1 font where the CharString is not a string. That might be workable. | 09:21.15 |
| chrisl | I wish the synthesised fonts didn't work that way..... | 09:21.48 |
| kens2 | I already have a check in there for a crummy Adobe font which makes the /.notdef a procedure, in that case we manufacture a CharString for it. This is the test that's causing the fallback by the way. I can make it stop capturing outlines at that point, it *might* work but its all held together with string now. | 09:23.09 |
| | Ha, in fact that test isn't in the pdfwrite code at all, its in zcharout.c | 09:24.15 |
| chrisl | Well, if Adobe does it..... | 09:24.57 |
| kens2 | Apparently (from teh comments) it was the Adobe PS4 windows print driver. WHich is *long* obselete | 09:26.48 |
| Powl | hi guys | 11:33.53 |
| | could anyone help me with MuPDF for Android? | 11:34.08 |
| | I requested a bugreport http://bugs.ghostscript.com/show_bug.cgi?id=695488 | 11:36.29 |
| tor8 | Powl: maybe. you'd be better off using an older, not broken, release of the NDK | 11:36.56 |
| Powl | Hi, i tried rev. 10b, 10, and 9d | 11:37.28 |
| | always same error :( | 11:37.41 |
| tor8 | the past few NDK releases are missing some standard library C functions | 11:37.41 |
| Powl | what rev. would you recommend? | 11:38.02 |
| tor8 | I believe the latest version I used successfully myself (I'm not the primary android developer here) was 8c | 11:38.27 |
| Powl | ok thanks, i'm gonna give it a try | 11:39.12 |
| tor8 | Powl: it might also be a build configuration issue, we haven't had the time to prioritise looking into fixing the android build with recent NDKs | 11:39.41 |
| | the main mupdf android developers are in crunch mode on another project at the moment | 11:40.11 |
| Powl | oh ok i see. I was just wondering why i have this error: cannot locate "rand" symbol referenced by libmupdf.so | 11:42.26 |
| tor8 | Powl: either it's because the NDK isn't shipping the rand() function, or there's some header file trickery that goes wrong | 11:58.52 |
| Powl | this is still up to date http://www.mupdf.com/docs/how-to-build-mupdf-for-android ? | 12:00.34 |
| Robin_Watts | tor8, Powl: I use r8e. | 12:00.57 |
| | Powl: Yes, though I prefer to point people at platform/android/ReadMe.txt in the code, as it's more detailed. | 12:14.23 |
| Powl | Hey, it works now :) | 12:14.43 |
| | i used ndk 8c. The revision tor8 recommended | 12:15.08 |
| | as tor8 mentioned, i think the function is missing in newer ndk revs | 12:15.55 |
| Robin_Watts | yeah, only so much we can do to work around google breaking shit. | 12:17.09 |
| Powl | :) | 12:18.02 |
| | just one question. Is it possible to use Mupdf with Android Studio? | 12:18.34 |
| | i couldnt find any information on how to integrate it in AS or eclipse on the page | 12:19.20 |
| Robin_Watts | We don't use Eclipse or AS. | 12:20.04 |
| | But others do. | 12:20.09 |
| Powl | ok | 12:20.39 |
| tor8 | Robin_Watts: http://stackoverflow.com/questions/25475055/android-ndk-load-library-cannot-locate-srand | 13:17.25 |
| | suggests it may be a configuration problem | 13:17.39 |
| Robin_Watts | not sure I believe that, but... | 13:18.59 |
| kens | Robin_Watts: your favourite muppet is back.... Looks like one of his questions may make sense though | 13:39.07 |
| henrys | did tell marcosw that wasn't the patch, although the discussion was confusing. | 13:57.07 |
| chrisl | henrys: marcosw said he tried it, and it worked, so...... | 13:59.02 |
| kens | Yeah, but their description is confusing | 13:59.16 |
| | THey did talk about getting one extra page, which sounds a lot like the problem that commit fixed. | 13:59.34 |
| | But the 'problem' (if there is one) is actually in the PCL interpreter | 13:59.50 |
| henrys | chrisl: well yes but the parent worked as well so that wasn't issue. | 14:00.02 |
| | kens: oh you found it? I was just about to bisect? | 14:00.39 |
| kens | -dFirstPage and -dLastPage aren't working with pcl6.exe for this file. | 14:00.41 |
| | Its not pdfwrite, and its the same in the current code | 14:01.00 |
| | If I use the display device I get approximately the same result | 14:01.16 |
| | I'd 'guess' that it might be something to do with PCL5 pass through, but I really don't know | 14:01.41 |
| henrys | kens: I'll look at it after the meeting. | 14:03.31 |
| kens | OK NP | 14:03.37 |
| kens | thinks coffee..... | 14:04.46 |
| henrys | maybe http://deathwishcoffee.com/ for today | 14:12.14 |
| kens | Hmm, I wonder if they ship to the UK...... | 14:12.43 |
| henrys | they got your flag so I suppose so | 14:13.01 |
| kens | Ah yes, just spotted that | 14:13.13 |
| | Via amazon | 14:13.22 |
| | Wow, £19 for 100g | 14:13.48 |
| | Ah no, £4.19 for 100g | 14:14.01 |
| | Must be supplied i some archaic Imperial weight | 14:14.19 |
| henrys | a bit more than double what I pay for decent brew | 14:14.37 |
| chrisl | It seems to be beans, though, I don't have a coffee grinder...... | 14:16.11 |
| kens | THey say they do gound as well | 14:16.21 |
| | Though I can't see a ground bag | 14:16.49 |
| chrisl | http://www.amazon.co.uk/Death-Wish-Coffee-Strongest-Organic/dp/B006CQ1ZHI/ref=aag_m_pw_dp?ie=UTF8&m=AR5TNTC1K4J98 | 14:17.11 |
| kens | Yeah I was about to paste that URL :) | 14:17.23 |
| | WOuld do better to buy it in the US, $19.99 per 1lb bag | 14:18.07 |
| chrisl | If it's really *that* strong, it might count as smuggling ;-) | 14:18.36 |
| kens | Might also come back with some coffee beetles :-) | 14:18.53 |
| Robin_Watts | ho ho ho. | 14:19.21 |
| kens | Is your kitchen vermin free now ? | 14:19.30 |
| Robin_Watts | I hope so. We'll find out in a few months. | 14:20.00 |
| henrys | I'm sure it is he's an excellent debugger | 14:20.01 |
| Robin_Watts | badoom-tish! | 14:20.14 |
| kens | Morning rayjj | 14:21.24 |
| AlexG___ | I have a question regarding stream object generation using [ {my_prevsly_defned_str_obj} (... stream content ...) /PUT pdfmark | 14:23.14 |
| kens | AlexG___ : Are you referring to MuPDF or Ghostscript ? | 14:23.37 |
| kens | assume sGhostscript | 14:23.47 |
| AlexG___ | Ghostscript tends to insert line breaks in longer streams at spaces. | 14:24.00 |
| kens | Hmm, that seems, unlikely..... | 14:24.19 |
| AlexG___ | In case of, say embedded JavaScript, this leads to broken code (AR complains about syntax error when trying to execute the code) | 14:25.09 |
| henrys | Robin_Watts: did you report it to a gov't agency presumably they shouldn't be letting the rice leave or come in. | 14:25.29 |
| | ? | 14:25.31 |
| Robin_Watts | henrys: I did not. Who needs that grief? | 14:25.54 |
| | Also, the rice is only our best guess for the origin of the beetles. | 14:26.18 |
| | tor8: Hmm. golden/master builds of mupdf appear broken on windows. | 14:26.47 |
| rayjj | morning, kens, and everybody else | 14:26.56 |
| henrys | hi rayjj | 14:27.21 |
| rayjj | kens: can you review my fixes for viewraw.ps and bitrgb ? | 14:27.21 |
| kens | marcosw there is no patch to fix that customer problem, it exists in the current HEAD code | 14:27.29 |
| rayjj | kens: can you review my fixes for viewraw.ps and bitrgb ? | 14:27.38 |
| | hi, henrys | 14:27.50 |
| kens | rayjj if you really feel its required. | 14:27.52 |
| rayjj | kens: not really. I just wanted to follow protocol | 14:28.14 |
| kens | Hmm, I thought we'd agreed to differ on that :-) | 14:28.38 |
| rayjj | kens: we did. | 14:28.48 |
| kens | I doubt I could see any faults. | 14:28.50 |
| | But I'll look, this is on your repo ? | 14:28.57 |
| AlexG___ | kens: For instance I had a case here, where 'throw new Error ('bla,bla');' turns out to be 'throw<linebreak here>new Error(...)' in the stream of the pdf object. This lead to an error in AR. | 14:28.57 |
| kens | AlexG___ : I can't possibly comment | 14:29.20 |
| Robin_Watts | AlexG___: We'd need to see a concrete example of it going wrong with a supplied file on a modern version of gs. | 14:29.50 |
| | And then it'd go onto the stack of stuff for us to look at if we have time. | 14:30.09 |
| marcosw | kens: I didn't try head, but it's fixed in 9.14. | 14:30.12 |
| tor8 | Robin_Watts: hm, let me try on my windows machine | 14:30.18 |
| henrys | kens, marcosw : I'll just wait for a bug and then I'll fix it. | 14:30.22 |
| rayjj | kens: yes. The reason that RGB 4 bit was broken was two-fold. First the bitrgb device was supposed to be writing 12 bits in 16 bit words, but the color was being encoded as 15 bits (5 bits each) in the 16 bit word | 14:30.34 |
| kens | marcosw, are you sure ? I don't have a 9.14 ghostpcl to try it on, but its not right with the HEAD | 14:30.45 |
| SYAOnline | Hello! I have a pdf that has multiple shade objects and because of this the allocation count of fz_shade objects gets to ~46000. This causes the application to reach the 2GB threshold of 32bit app and crashes. | 14:30.50 |
| AlexG___ | I am using 9.15 GIT prerelease a couple of weeks old. I will try and create some example input. Bye! | 14:31.12 |
| Robin_Watts | tor8: It's a missing file in the solution. Making a patch now. | 14:31.21 |
| rayjj | and the viewraw.ps didn't handle 4 bit properly because images couldn't read the 12 bits in 16 bits | 14:31.41 |
| marcosw | pcl914 -dNOPAUSE -sDEVICE=pdfwrite -r300 -dFirstPage=1 -dLastPage=1 -sOutputFile=out.pdf IRS_3_202pgs.pcl | 14:32.00 |
| | marcos@i7:[14]% gsheadppm out.pdf | 14:32.05 |
| | GPL Ghostscript GIT PRERELEASE 9.16 (2014-03-25) | 14:32.06 |
| | Copyright (C) 2014 Artifex Software, Inc. All rights reserved. | 14:32.06 |
| | This software comes with NO WARRANTY: see the file PUBLIC for details. | 14:32.06 |
| | Processing pages 1 through 1. | 14:32.06 |
| | Page 1 | 14:32.06 |
| | marcos@i7:[15]% | 14:32.06 |
| SYAOnline | My question is why the float function[256][FZ_MAX_COLORS + 1]; is static allocated and not dynamic : float *function[256]; since then only calls I've seen are going only up to colorspace->n; | 14:32.12 |
| kens | marcosw : Did you *look* at the output ? | 14:32.22 |
| marcosw | marcos@i7:[15]% pcl910 -dNOPAUSE -sDEVICE=pdfwrite -r300 -dFirstPage=1 -dLastPage=1 -sOutputFile=out.pdf IRS_3_202pgs.pcl | 14:32.30 |
| | marcos@i7:[16]% gsheadppm out.pdf | 14:32.30 |
| | GPL Ghostscript GIT PRERELEASE 9.16 (2014-03-25) | 14:32.30 |
| | Copyright (C) 2014 Artifex Software, Inc. All rights reserved. | 14:32.30 |
| | This software comes with NO WARRANTY: see the file PUBLIC for details. | 14:32.30 |
| | Processing pages 1 through 2. | 14:32.31 |
| | Page 1 | 14:32.31 |
| | Page 2 | 14:32.32 |
| | marcos@i7:[17]% | 14:32.32 |
| | yes, do you need me to send you a copy of out.pdf? | 14:32.38 |
| kens | Not really. | 14:32.44 |
| | But for me on current code, this doesn't work, nor does it work with the PCL interpreter and the display device | 14:33.03 |
| henrys | kens: there could be a separate issue with the display device. | 14:33.24 |
| kens | I get multiple pages out, and the later pages are a mess. | 14:33.29 |
| Robin_Watts | tor8: Fix on robin/master | 14:33.40 |
| kens | henrys I guess that's opssible, I will quickly try tiff | 14:33.54 |
| tor8 | Robin_Watts: yeah, missing jmemcust | 14:34.07 |
| | Robin_Watts: LGTM | 14:34.29 |
| kens | henrys it does seem OK with tiff | 14:34.39 |
| Robin_Watts | tor8: Ta. | 14:35.11 |
| henrys | I thought we'd just focus on release business for the meeting unless there are other issues. We do have the staff meeting coming up, I'll fix up the workflowy and send out a message to tech. | 14:35.23 |
| kens | henrys, marcosw apologies, it does seem OK with pdfwrite also | 14:35.42 |
| | display device must be a separate problem | 14:35.51 |
| henrys | kens: still a bug I know that stuff never got a lot of testing with the display devices. | 14:37.42 |
| marcosw | kens: np | 14:37.46 |
| chrisl | henrys: as per my mail to tech, I've created a new release candidate with the fixes for the regressions - I'll send a proper announcement out before I finish today | 14:38.13 |
| henrys | chrisl: okay and then we start the test cycle again? | 14:38.43 |
| kens | I presume so | 14:38.51 |
| SYAOnline | anyone from MuPDF here? | 14:39.03 |
| rayjj | chrisl: I'd like to get the two patches (from my personal repo) pulled in as well (for viewraw.ps with RGB 4-bit) | 14:39.06 |
| chrisl | rayjj: too late, the release candidate is already done | 14:39.29 |
| kens | rayjj I casn't see any problem with those commits, but then, I'm not certain I would | 14:39.31 |
| Robin_Watts | SYAOnline: Yes, but we are in a meeting right now. Ask your question, but be prepared to wait a bit for an answer. | 14:39.38 |
| SYAOnline | ok! Ty for the answer! Robin_Watts | 14:40.18 |
| rayjj | chrisl: you couldn't wait until after the meeting ? :-( | 14:40.18 |
| marcosw | chrisl: I'll rerun the tests with rc2 starting today, should be done by Friday. Sorry for not having found those issues when they first appeared, I'll pay more attention to the weekly tests going forwarrd. | 14:40.24 |
| kens | The question is up above. | 14:40.25 |
| henrys | rayjj: I can't see that being very important to get in. | 14:40.36 |
| chrisl | rayjj: I did the rc about 3 hours ago - I had no idea you had stuff pending | 14:40.46 |
| henrys | marcosw: have we looked at speeding this up? Your garage could predict the weather. | 14:41.45 |
| rayjj | chrisl: oh, well. TZ bites us again. At least if anybody needs viewraw.ps that really works, it'll be on git :-/ | 14:41.55 |
| kens | I suspect it'll mainly be of use internally | 14:42.25 |
| Robin_Watts | SYAOnline: Whats the problem with it being statically allocated? | 14:42.38 |
| rayjj | henrys: it isn't that important. It would be if we were working with a customer that wanted 4-bit | 14:42.38 |
| | (as cust 801 did). | 14:42.58 |
| SYAOnline | I have a pdf that has ~46000 shades... or at least that is the number of allcations | 14:43.19 |
| chrisl | marcosw: do we test bitrgb in the weekly test? | 14:43.39 |
| Robin_Watts | SYAOnline: So the issue is that it takes extra space in the display list, I guess. | 14:43.41 |
| henrys | tor8: mupdf release? | 14:43.56 |
| SYAOnline | and because of that, 46000 * 256 * 33 * 4 well you get to 2GB of allocated memory | 14:44.05 |
| Robin_Watts | dynamic allocation would be slower, but would take less memory. | 14:44.11 |
| tor8 | henrys: but I don't want to! *whine* | 14:44.19 |
| Robin_Watts | Sure, I see the issue. I'll ponder on it. | 14:44.23 |
| marcosw | henrys: I've thought about it, but it currently takes 2 1/2 days and the best I could do would be 1 day or so. But to get to that I'd have to think and do work. | 14:44.26 |
| | chrisl: good question. let me check... | 14:44.42 |
| Robin_Watts | tor8: You wanna work on SOT, and I'll do the MuPDF release? | 14:44.49 |
| tor8 | henrys: should be able to tag what we have, now that robin has fixed the windows build regression | 14:44.53 |
| Robin_Watts | tor8: We should try and fix the android problems. | 14:45.10 |
| | Or at least put a note in the build instructions. | 14:45.27 |
| kens | Yes, that's going to keep on coming up | 14:45.35 |
| henrys | tor8: nice to have it out there before the meeting. | 14:45.37 |
| SYAOnline | I've tried to allocate it dyanmic myself, but somehow the memory gets rewritten or something else.. because it's a difference between the pdf read when memory it's static and when the memory is dynamic | 14:45.40 |
| tor8 | Robin_Watts: yeah. I guess I'll have to mess up my linux install then :( stupid 32-bit p.o.s. | 14:45.41 |
| marcosw | chrisl: oddly enough we only test bitrgb for ghostxps. | 14:45.50 |
| rayjj | chrisl: even if we test bitrgb, I'd really doubt that we test 4-bit (where there will be a difference) | 14:45.54 |
| marcosw | which is the same as the clusterpush regression testing. | 14:46.19 |
| henrys | chrisl: the open change scares me, anytime that is fooled with hell follows | 14:46.35 |
| chrisl | henrys: huh?? | 14:46.56 |
| SYAOnline | and I can't find the place where everything goes to hell. From what I've searched the function member only has colorspace->n values for each of it's first dimension memeber.. | 14:47.00 |
| marcosw | rayjj: correct, we only test bitrgb with -dGrayValues=256 (which I presume means 8 bit). | 14:47.19 |
| rayjj | henrys: the is_open pdfwrite change ? | 14:47.32 |
| kens | THat one isn't in the release | 14:47.40 |
| henrys | chrisl: oh that didn't make it in ... | 14:47.54 |
| | nvm | 14:47.59 |
| rayjj | marcosw: right -dGrayValues=256 generates 24-bit RGB | 14:47.59 |
| kens | I don't think altering the is_open is risky, its right now, it was wrong before | 14:48.23 |
| chrisl | rayjj, henrys, marcosw: so there really is nothing stopping us pulling in Ray's latest changes between the rc and the release, since the release testing won't touch those changes anyway | 14:49.10 |
| rayjj | if I was the worrying sort (and if we didn't have regression testing), the c_alone change would be scarier | 14:49.16 |
| kens | I'm pretty confident about that one too. As chrisl says, it was a benign warning anyway | 14:49.37 |
| henrys | chrisl: It's up to you I vote no. | 14:49.50 |
| kens | THe one that worries me is the pdfwrite freeing the complete font copy :-) | 14:49.54 |
| chrisl | henrys: okay, I'm fine with that | 14:50.07 |
| AlexG___ | kens: I must apologise. It is not Ghostscript's fault, but that of dvips (TeX). The latter inserts, sometimes, newlines for spaces in the PS already. | 14:50.16 |
| rayjj | kens: yeah. It _should_ be OK. Just touching anything with GC memory seems like sneezing in a house of cards | 14:50.24 |
| kens | AlexG___ : No problem, liek I said, I couldn't see how GS would be doing that. | 14:50.33 |
| marcosw | chrisl: I don't think testing a rc and then changing it for the release is a good idea; no matter how safe the change. | 14:50.34 |
| mvrhel_laptop | right | 14:50.44 |
| marcosw | if ray's changing are important why don't you do a rc3? | 14:50.54 |
| rayjj | chrisl: I don't feel strongly that it needs to be in. Like I said, it'll be available if anyone uses it | 14:51.05 |
| | marcosw: Nooooo | 14:51.22 |
| chrisl | marcosw: I'm p*ssed at having to do an rc2!! | 14:51.29 |
| henrys | tor8:miles is going to be asking about android $ at the meeting. Let's bit the bullet and get it out there. | 14:52.11 |
| | bite | 14:52.35 |
| marcosw | byte? | 14:52.43 |
| | (sorry) | 14:52.48 |
| kens | nibble :-) | 14:52.55 |
| henrys | I'm getting a snack before the next meeting on skype | 14:53.29 |
| | ... | 14:53.31 |
| chrisl | rayjj: at the point where valgrind complained about c_alone being unitialised, the value of c_alone has no effect on the program flow | 14:53.35 |
| | Which is why I commented that it was benign..... | 14:53.49 |
| mvrhel_laptop | bbiab | 14:53.51 |
| tor8 | henrys: we haven't flipped the bit to make it paid yet? | 14:54.04 |
| rayjj | chrisl: yes, I agree. I was (mostly) just kidding about being scared about any change in the GC logic | 14:54.15 |
| kens | Yes, because if its 0 we go to allocate, andf if its not we test c_top and c_bot, which are definitely both 0 and go to allocate | 14:54.18 |
| chrisl | rayjj: well, that's not really gc, it's more allocator, but I know what you mean | 14:55.20 |
| kens | Why do you think I didn't make the change, but left it for chris ? :-) | 14:55.40 |
| rayjj | kens: hehe | 14:55.49 |
| chrisl | marcosw: did you see my mail about kilometers and miles? | 14:56.02 |
| marcosw | kens and henrys: now I'm confused, I just bisected the extra page pcl issue and with the IRS_3_202pgs.pcl test file and came up with the same patch, the pdfwrite revert. Does this perchance only fail on windows and/or is indeterministic? | 14:56.05 |
| kens | marcosw : THat's a puzzle | 14:56.22 |
| marcosw | chrisl: no, I upgraded them from 12.04 to 14.04 yesterday. | 14:56.29 |
| kens | I can pull the 9.14 source and rebuild and try it here | 14:56.57 |
| | It *could* be indeterministic | 14:57.06 |
| chrisl | marcosw: right, and, usual, libcups2-dev and libcupsimage2-dev have been removed instead of upgraded....... | 14:57.17 |
| | s/usual/as usual | 14:57.26 |
| kens | marcosw : I'll try bisecting it as soon as we're done here, my checkout is clean atm | 14:58.05 |
| henrys | tor8: I thought we were going to do an android release with the latest code and make that version paid. | 14:58.07 |
| marcosw | chrisl: I'm sure you are correct. Oddly I fired off a test and thought it came back clean, I must have looked at the wrong results. | 14:59.05 |
| rayjj | henrys: re the company M board, I seem to have more of the needed info (thanks to MQ). Now I can't get their toolchain to run on my ubuntu linux. I wonder if it's made for Cygwin. | 14:59.11 |
| tor8 | henrys: okay. | 14:59.12 |
| chrisl | marcosw: I should probably report it as a bug........ | 14:59.48 |
| henrys | tor8: I guess Robin_Watts or paulgardiner do the android release? | 15:00.19 |
| Robin_Watts | henrys: It's normally me. | 15:00.36 |
| tor8 | henrys: I believe Robin_Watts has done the previous android releases | 15:00.38 |
| | he certainly has the know-how and account info etc | 15:00.48 |
| marcosw | chrisl: you mean with ubuntu? | 15:01.15 |
| Robin_Watts | The account info is in a text file in my home dir on casper. But I'm happy to do the builds etc. | 15:01.18 |
| chrisl | marcosw: yes | 15:01.21 |
| Robin_Watts | Actually, it might be on a wiki page now. | 15:01.26 |
| rayjj | chrisl: marcosw (or any linux person): if I have a file (gcc in this case) that "file" shows as "gcc: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.8, stripped", but won't execute (perms=-rwxr-xr-x) what could the problem be | 15:01.37 |
| marcosw | chrisl: not a bad idea, it's something till would care about. | 15:01.41 |
| | rayjj: are you running Linux 2.6.8 (or presumably later)? | 15:02.15 |
| henrys | Robin_Watts: so this time we need an apk on mupdf.com. | 15:02.16 |
| chrisl | rayjj: do you get any kind of error at all? | 15:02.26 |
| Robin_Watts | henrys: We need 4 apks on mupdf.com :) | 15:02.40 |
| rayjj | marcosw: Linux ubuntu12 3.8.0-29-generic #42~precise1-Ubuntu SMP Wed Aug 14 16:19:23 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux | 15:02.44 |
| tor8 | henrys: we already have apks on mupdf.com | 15:02.44 |
| rayjj | chrisl: "not found" | 15:02.54 |
| marcosw | chrisl: this "sudo apt-get install libcupsimage2-dev" fixes the problem. | 15:03.14 |
| tor8 | Robin_Watts: henrys: I'm going to look into the recent android build issues people have been having | 15:03.25 |
| rayjj | chrisl: actually "No such file or directory" | 15:03.38 |
| chrisl | marcosw: Oh, I thought libcups2-dev needed installed separately - so that's one thing that's been fixed...... | 15:03.53 |
| | rayjj: even if you give the full path to the exe? | 15:04.09 |
| rayjj | chrisl: yes, and even if I cd to the path with the bin. BTW, the ls -l is: -rwxr-xr-x 2 2608 users 274816 Aug 30 2012 (so it's definitely a non-zero file size, but the result from "file" tells me that) | 15:05.50 |
| marcosw | libcupsimages2-dev pulls in a bunch of other stuff, including libcups2-dev. Not sure why it's installing krb5-multidev and libgcrypt11-dev... | 15:06.26 |
| rayjj | would it be a problem if it was built for a 32-bit linux (I'm running 64-bit) | 15:06.51 |
| chrisl | rayjj: in which case it's possible that the "No such file or directory" error is actually from the linker because it's not finding a library file | 15:07.19 |
| | marcosw: cups (optionally) uses encryption for something or other...... | 15:07.44 |
| rayjj | chrisl: what are the linux tools to track that down ? | 15:07.51 |
| chrisl | rayjj: ldd <exe name> should tell you what the dependencies are | 15:08.30 |
| marcosw | chrisl: figured out why my clusterpush didn't find the missing cups stuff, I did a lowres test, which doesn't test cups :-( | 15:09.08 |
| chrisl | marcosw: ah, I didn't realise that - good to know! | 15:09.28 |
| henrys | Robin_Watts, tor8: just the builds are fine, I'll take it from there. | 15:09.31 |
| rayjj | chrisl: strace tells me: execve("bin/arm-M-eabi-gcc-4.6.4", ["bin/arm-M-eabi-gcc-4.6.4"], [/* 22 vars */]) = -1 ENOENT (No such file or directory) | 15:10.13 |
| Robin_Watts | henrys: I'll do the android builds, put the apks on mupdf.com, upload them to the google developer console, but leave them in 'beta'. | 15:10.47 |
| rayjj | chrisl: hmm... ldd says "not a dynamic executable" | 15:10.58 |
| Robin_Watts | henrys: Then you can publish them when you set the price etc. | 15:11.00 |
| henrys | Robin_Watts: well tor8 said something about looking into build problems | 15:11.25 |
| chrisl | rayjj: Hmm, that's.... odd | 15:11.29 |
| Robin_Watts | henrys: Yes, we are getting lots of complaints from people saying that mupdf doesn't build on android at the moment. | 15:11.52 |
| | The problem is that google broke the latest ndks. | 15:12.01 |
| rayjj | chrisl: agreed. "file" thinks it is "32-bit LSB executable" but ldd gripes | 15:12.38 |
| henrys | Robin_Watts: okay so that's not release related | 15:12.43 |
| Robin_Watts | It's probably just a bit of #ifdeffery to fix it, and it would be really good to get that in before the release, otherwise we will spend the next 6 months a) answering the same bloody questions, and b) getting slated on the web cos our source doesn't work. | 15:12.46 |
| | It is release related. If it's going to take more than a day or so to fix, we can skip it though. | 15:13.17 |
| rayjj | chrisl: doing "file" on the native gcc I get: /usr/bin/gcc-4.6: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.24, BuildID[sha1]=0xf4ec9286085ca4313ac604f734a3764c20c491f0, stripped | 15:13.50 |
| | oops. have to take my son to school. bbiab | 15:14.02 |
| kens | marcosw as far as I can see, that commit you pointed them to (and the patch) resolves the problem. I can't see that its indeterministic at all. If I take a vanilla 9.10 source checkout then I see the problem, apply that single patch and nothing else, the problem goes away | 15:32.40 |
| | marcosw : you could ask them to try the same, and if they have any other patches applied. Obviously we're not in a position to know what random selection of patches they may already have applied, and its conceivable (though highly unlikely) that they've done something else to break it. | 15:34.26 |
| rayjj | chrisl: Just on the off chance, I'm going to install a 32-bit ubuntu VM and try the stuff there. The other option is to download the sources for their toolchain and build them on my (64-bit) VM | 15:49.59 |
| | chrisl: if you think of anything else, please let me know (I'll check the logs if I've been away) | 15:50.34 |
| marcosw_ | kens: for the logs, thanks for verifying that the patch works for you as well. I'll email them. | 15:50.46 |
| chrisl | rayjj: if you can find a list of dependencies, Ubuntu has most of them available as 32 bit builds packaged to install on a 64 bit system | 15:52.05 |
| | But the fact that the linker seems to be getting confused isn't a great sign :-( | 15:53.22 |
| rayjj | chrisl: right. I wonder if this toolchain was built for Cygwin or something ? | 15:55.01 |
| henrys | kens: I have no problem with the pcl file with X11 so specific to display, very odd. | 15:55.05 |
| chrisl | rayjj: is the toolchain available to download somewhere? | 15:55.26 |
| rayjj | chrisl: yes, let me email my login info to you. | 15:55.47 |
| chrisl | rayjj: built for cygwin, the file output looks like: "PE32 executable (console) Intel 80386 (stripped to external PDB), for MS Windows" | 15:57.27 |
| kens | henrys, I won't worry about it, it works fine with tiff and pdfwrite on current code, so it must be something truly odd | 15:58.31 |
| chrisl | kens: did you say that the extra pages were messed up on the display device? | 16:00.21 |
| kens | chrisl, yes, just the same as the old pdfwrite behaviour | 16:00.37 |
| | its as if it flushes the final pages | 16:00.45 |
| chrisl | Right, and the display device draws objects as they are passed down to graphics lib - it doesn't wait for a showpage type operation | 16:01.49 |
| | So, if the PCL interpreter is continuing to consume the file....... | 16:02.26 |
| kens | Yes, but if I recall correctly, it didn't close the page either. I could be mistaken | 16:02.29 |
| henrys | chrisl: so does x11 I was hoping to reproduce it there less I have to start up the dreaded windows 8.1 virus | 16:02.35 |
| kens | It definitely doe scnosume the remainder of the file, just as PostScript would | 16:02.55 |
| chrisl | henrys: x11 often resorts to rendering to a secondary buffer, and then blitting that to the x11 display buffer - I don't think display ever does that | 16:03.37 |
| kens | chrisl I'm about to go out to eat, I'll try the installer tomorrow | 16:05.05 |
| chrisl | kens: thanks - no hurry, it was never a candidate to go into this release | 16:05.27 |
| rayjj | chrisl: I emailed the company M info | 16:06.25 |
| | just in case... | 16:06.33 |
| chrisl | Umm, not the most intuitive site, then...... | 16:10.28 |
| rayjj | chrisl: well, no | 16:10.44 |
| | chrisl: at least we seem to be past all of the "you can't download this" problems | 16:11.13 |
| | installing ubuntu 14 32-bit VM .... | 16:11.57 |
| henrys | chrisl: I didn't know if you knew but you can call gs_flushpage(pgs) in the debugger to flush ouptut. Useful while debugging with X11 if you want to see what is on the screen while stepping | 16:12.22 |
| marcosw | rayjj: in your copious free time could you fix <http://bugs.ghostscript.com/show_bug.cgi?id=695244>? I'm tired of seeing seg faults in the regression reports. | 16:13.07 |
| rayjj | henrys: yeah, in the PDFSTEP with gs, I use the PS .outputpage to do that, too | 16:13.11 |
| chrisl | henrys: I didn't know, could be useful, thanks. TBH, I try to avoid using x11(alpha) - I don't like them very much | 16:13.37 |
| rayjj | marcosw: I've had trouble reproducing that one. I'll try again on peeves. | 16:13.50 |
| chrisl | rayjj: arm-M-linux-gnueabi-gcc-4.6.4 executes for me..... | 16:15.03 |
| | What version of Ubuntu are you running? | 16:15.18 |
| rayjj | robin_watts: can you edit the logs ??? | 16:16.06 |
| chrisl | Oh, shoot - sorry..... | 16:16.24 |
| | I didn't realise when I pasted it that it had the name there | 16:16.46 |
| rayjj | chrisl: it's a pain, but we are not supposed to mention them (I hand edited my pastes to change it) | 16:16.55 |
| chrisl | It just didn't occur to me it would be in the executable name as well as the path | 16:17.37 |
| rayjj | chrisl: I was on Linux ubuntu12 3.8.0-29-generic #42~precise1-Ubuntu SMP Wed Aug 14 16:19:23 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux | 16:17.43 |
| | I'm trying ubuntu 14 32-bit | 16:17.59 |
| chrisl | rayjj: check on your 64 bit machine if you have a package called "libc6-i386" available | 16:18.50 |
| kens | Heading out, night all | 16:19.30 |
| chrisl | Just to check if ghostbot is logging - because it wasn't for a while.... | 17:37.17 |
| | Indeed is working now...... | 17:38.04 |
| mvrhel_laptop | bbiaw | 21:09.50 |
| | Forward 1 day (to 2014/09/17)>>> | |
IRC Logs