| <<<Back 1 day (to 2013/01/27) | 2013/01/28 |
ray_laptop | Bug 693590 looked sort of obvious, but something with psdcmyk cropped up in regression testing. May have been there and masked by the other bugs. Testing to see if the bug reported all the cases, or just a few | 00:04.05 |
mvrhel_laptop | henrys: oh I forgot about that | 01:00.19 |
| I will take a look at it late tonight or tomorrow | 01:00.31 |
kens | chrisl I've got a fix for the bookmarks problem in test now. | 08:32.30 |
chrisl | kens: Cool - but no rush, given the blockers, the critical and the stuff reported over night :-( | 08:33.30 |
kens | Yes, I noticed Marcos had been busy again :-( | 08:33.49 |
chrisl | And I'm trying to decide whether I want to test the build on XP with VS2010...... | 08:34.55 |
kens | I think that's a 'no'.... | 08:35.05 |
chrisl | Well, I realised I have an XP machine here - my own laptop has XP on it, it just hasn't been booted into XP ~1 year | 08:35.56 |
kens | I really don't think it's worth it.... | 08:36.12 |
chrisl | You're probably right | 08:36.29 |
| And I thought I was saving overall effort by remembering the stroked font fix you did - that'll learn me! | 08:37.09 |
kens | I was imp[ressed you'd remembered it! | 08:37.27 |
chrisl | It was out of the ordinary enough to stick in my mind | 08:38.04 |
kens | chrisl do you remember if we own gsprint now ? | 08:47.47 |
chrisl | I believe we do, but I'm not 100% sure | 08:48.15 |
kens | Well its another free user batch printing 'many' PDF files, and presumably not paying us or Russel. | 08:50.14 |
| So I don't think I have much sympathy | 08:50.27 |
chrisl | You mean many PDFs with the same instance? | 08:52.31 |
kens | Yeah I think so, using gsprint | 08:52.42 |
| 693593 | 08:53.07 |
chrisl | Yeh, I just saw it - I'd have thought that risky from a print queue perspective, anyway | 08:53.50 |
kens | Well yes, thousands of print jobs and 'something goes wrong'. I mean,. this is Windows....... | 08:54.20 |
chrisl | :-) | 08:55.25 |
kens | OK fix for outlines commited (also fixes articles, named destinations and page labels) | 08:57.59 |
| Now to look at the next one from Marcos | 08:59.17 |
| Oh joy a pattern in an SMask | 09:00.38 |
| Now, is Marcos using the original file or the simplified version :-( | 09:01.15 |
chrisl | I must admit, it is confusing that we (allegedly) get an infinite loop in gc_objects_clear_marks() since that's traversing memory we've already scanned once. | 09:05.52 |
kens | I don't think its true | 09:06.15 |
chrisl | Which part? | 09:06.33 |
kens | THe file takes several seconds to open in Acrobat, and to render (at 72 dpi) in Ghostscript. When I use pdfwrite it goes slowly and produces lots of warnings | 09:06.54 |
| I think its just very slow (on page 2) | 09:07.02 |
| Oh look, its a Cairo-produced file | 09:07.24 |
chrisl | That would make some sense if pdfwrite is, for some reason, flattening the transparency? | 09:07.42 |
kens | So we can expect insane nesting, stupid transparency and a file which is hideously over-complicated | 09:07.53 |
chrisl | Nice! | 09:08.07 |
kens | Presuambly this is why its also slow on Acrobat | 09:08.10 |
| OK extracting page 2 gets me the same lengthy flow of 'Error reading a content stream' messages | 09:10.16 |
| Its possible the PDF interpreter is retrying the form endlessly I suppose, though I'm doubtful. | 09:11.26 |
chrisl | A self referencing SMask group? | 09:12.09 |
kens | And the uncompressed PDF (just page 2) is > 8Mb | 09:12.26 |
| Oh yeah, patterns which call forms which use patterns, which call forms, whic use patterns..... | 09:13.31 |
| All using transparency of course. | 09:13.45 |
chrisl | If Acrobat takes a long time to render it, that's a *very* clear sign you've done something stoopid | 09:14.33 |
kens | Well, its a page full of coupons for McD's, here's the content stream for the page: | 09:15.13 |
| stream | 09:15.13 |
| q | 09:15.14 |
| Q | 09:15.14 |
| endstream | 09:15.14 |
| Grrr | 09:15.21 |
| "stream | 09:15.30 |
| "q | 09:15.30 |
| "/x692 Do | 09:15.30 |
| "Q | 09:15.30 |
| "endstream | 09:15.30 |
chrisl | Nice and simple then..... ;-) | 09:15.51 |
kens | And object 692 sets a pattern and fills a rectangle with it.... | 09:16.12 |
| AH, of course, x692 is in fact object 1720, that makes sense | 09:16.48 |
| And that form content stream draws 2 XObjects | 09:17.10 |
| THe first of those draws 6 XObjects.... | 09:18.05 |
| Oh, and a bunch of other ones later | 09:18.24 |
| hundreds of them | 09:18.42 |
| Classic. The resources dictionary for the form lists objects /s101 to /s155 as pointing to the identical object '1724 0 R' then /s162 to /s325 all point to object 1726, and so on. SO it needlessly defines dozens of duplicate objetcs. Presumably in order to slow down the interpreter.... | 09:20.56 |
| As near as I can see that uses 3 actual different objects, but defines a couple of hundred different resources for them. | 09:22.18 |
| And that's just the ExtGStates | 09:22.46 |
chrisl | I can't believe cairo haven't been forced to fix this crap! | 09:23.28 |
kens | I'm guessing that this has tripped over the nesting level problem again, which is why its generating errors, and that is causing some amount of memory thrashing, but I don't think its actually in an infinte loop, just very slow. | 09:24.43 |
| Just running it through ps2write to see what happens | 09:25.44 |
| Surprise, surprise, it works fine | 09:26.11 |
| Because all the stupid transparency just gets rendered | 09:26.47 |
| Yes increasing the gstate stack depth gets rid of the form errors. However GS does seem to vanish off into a loop then. | 09:30.01 |
| Oh, and then seg faults.... | 09:30.19 |
Robin_Watts | paulgardiner: hey | 11:21.55 |
paulgardiner | hi | 11:22.07 |
Robin_Watts | Do you want to take a look at the commits on robin/master ? | 11:22.10 |
paulgardiner | Sure | 11:22.18 |
Robin_Watts | I spent time on saturday with Sebras, and I think we got it working in the end. | 11:22.27 |
| http://ghostscript.com/~robin/MuPDF.apk is the latest apk. If tor/you agree with the reviews, I'll get that uploaded to google later. | 11:23.10 |
paulgardiner | Which ones need reviewing? | 11:23.12 |
Robin_Watts | Smart Motion and NullPointer exception. | 11:24.21 |
| but I was thinking that you'd be best placed for the latter, and tor8 for the former. | 11:24.36 |
| (not that I won't welcome comments on both of course) | 11:24.45 |
paulgardiner | Ah. I'd fetch only Robin, not origin too, so it looked like there were loads | 11:26.27 |
tor8 | paulgardiner: "git remote update" fetches all origins, and submodules | 11:27.42 |
Robin_Watts | oh, I missed that tor8 was here too. | 11:27.58 |
| Morning tor8. | 11:28.03 |
paulgardiner | tor8: ah right. Thanks | 11:28.16 |
tor8 | Robin_Watts: just popped in the minute you started writing, I think, going by the logs. morning! | 11:28.21 |
| I see you were busy this weekend. | 11:28.26 |
Robin_Watts | Yeah, the gmail attachment thing was a bit of a bitch. | 11:28.45 |
| Or rather, I made a stupid mistake that cost me hours. | 11:28.53 |
tor8 | JNI is a bit of a disaster from what I recall of messing with it 15 years ago... | 11:29.27 |
Robin_Watts | I've also started a local branch on which I am experimenting with making mupdf handle rectangles/matrices by reference rather than by value. | 11:29.38 |
tor8 | Robin_Watts: I'm not sure there will be any realistic gains from that though (matrix/rect by ref) | 11:30.01 |
Robin_Watts | I am sure that working by reference will be faster on ARMs at least. | 11:30.05 |
tor8 | since almost every function that takes one modifies it so needs to make another copy anyway | 11:30.14 |
Robin_Watts | tor8: actually, no, I don't think that's the case. | 11:30.30 |
tor8 | ctm = fz_concat(localthingy, ctm) is in most functions that take a matrix | 11:30.47 |
Robin_Watts | indeed. | 11:31.04 |
tor8 | Robin_Watts: so make damn sure you set them as "const" or we'll have a bazillion little bugs | 11:31.17 |
Robin_Watts | so fz_pre_mul(ctm, localthingy) | 11:31.32 |
tor8 | and all functions that take a rect usually intersect it | 11:31.34 |
Robin_Watts | yeah, this is why I am trying it on a branch. | 11:31.52 |
tor8 | fz_concat(localctm, localthingy, ctm) | 11:31.56 |
Robin_Watts | tor8: That's exactly what I have at the moment :) | 11:32.14 |
tor8 | fz_concat(fz_matrix *out, const fz_matrix *a, const fz_matrix *b) | 11:32.22 |
| Robin_Watts: re the bbox/rect/bounds naming. any preference? | 11:32.45 |
Robin_Watts | We may find that we want to pass matrices by value in the dev interface, but do all the fiddling with them within the functions by reference. | 11:33.09 |
| tor8: I'm still struggling to see what we gain with the bbox -> rect thing. | 11:33.30 |
tor8 | Robin_Watts: no, let's not mix | 11:33.34 |
| a naming convention (ctm in arguments, localctm in the modified local matrix) will be better | 11:33.55 |
| Robin_Watts: rect/bbox was a mess in the text device and apps code | 11:34.24 |
Robin_Watts | With the new code we end up with rects that happen to be bboxes. | 11:34.33 |
| I'd rather have them specifically named that way. | 11:34.51 |
tor8 | now that everything is cleaned up to one type consistently everywhere, we can reintroduce fz_irect in the drawing device | 11:35.14 |
Robin_Watts | rect -> bbox is also bad for performance (floats are bad, M'kay) | 11:35.23 |
tor8 | Robin_Watts: floats are good, on intel arch's | 11:35.36 |
Robin_Watts | tor8: floats are bad, on ARMs. | 11:35.44 |
tor8 | stupid arm! | 11:35.54 |
Robin_Watts | Thinking back to what one of our customers said... | 11:36.02 |
paulgardiner | Robin_Watts: coo nice. That has worked out neatly. | 11:36.03 |
tor8 | Robin_Watts: yeah. I'll make a stab at irect in the pixmap and draw device. | 11:36.46 |
Robin_Watts | ...they spent a lot of time optimising stuff to avoid FP where possible. And they tweaked all the matrix stuff as it made a big difference for them. | 11:36.51 |
tor8 | but first, I wonder if we can do anything about the two rounding functions | 11:36.58 |
paulgardiner | Robin_Watts: only thought was whether env and thiz would be better in a structure separate from globals, as it seems that where env and thiz are needed, no other part of globals is. | 11:36.59 |
Robin_Watts | paulgardiner: env and thiz being in globals; get_globals updates env and thiz every time. | 11:37.21 |
tor8 | Robin_Watts: did that customer use 32-bit fixed point or 64-bit? | 11:37.31 |
Robin_Watts | in case env and thiz change between calls. | 11:37.34 |
| tor8: They still used floats, just were more efficient about it, AIUI. | 11:37.46 |
tor8 | Robin_Watts: I know we've gone to great care to avoid doubles everywhere | 11:38.12 |
Robin_Watts | I think there is scope for us being smarter with the matrix stuff. | 11:38.22 |
| let me have the rest of the day to bash at this stuff, and we'll see how it ends up and take a view on it. | 11:38.36 |
tor8 | I don't oppose fz_matrix and fz_rect being passed by value, but if and only if we spread const and be strict about constness everywhere | 11:39.05 |
paulgardiner | Robin_Watts: oh yeah ok. Makes sense | 11:39.08 |
| Robin_Watts: looks fine | 11:39.20 |
Robin_Watts | tor8: OK, sounds good. I'm trying to add consts. | 11:39.23 |
| paulgardiner: Thanks. | 11:39.26 |
| tor8: Do you want to try the new apk and see if it solves the 'scrolling a tiny amount' problems? | 11:39.42 |
tor8 | Robin_Watts: should probably constify most of the rest of the API where it makes sense too | 11:39.48 |
| Robin_Watts: will do. | 11:39.55 |
Robin_Watts | tor8: sure. | 11:39.56 |
| Thanks. | 11:39.58 |
tor8 | Robin_Watts: oh yeah, icons too, but I guess that can wait for yet another market update? | 11:41.39 |
Robin_Watts | IF the icons are ready to go, I can rebuild/upload that | 11:42.18 |
tor8 | Robin_Watts: haven't noticed any weird behaviour so far with the new apk so I'd reckon the smart scrolling works | 11:43.50 |
| tapping on the bottom and on the right is meant to behave the same, yes? | 11:44.34 |
Robin_Watts | yes. | 11:45.14 |
tor8 | Robin_Watts: oh, when you do the matrix/rect by reference branch, where did you base it off? the rect revamp or before? | 11:45.21 |
| (worrying about painful merges) | 11:45.28 |
Robin_Watts | before. | 11:45.34 |
tor8 | ugh. | 11:45.37 |
Robin_Watts | but I'll take the pain of the rebase. | 11:45.41 |
tor8 | Robin_Watts: do it in two parts, one for matrix and one for rect. for your own sanity. | 11:46.02 |
Robin_Watts | Too late :) | 11:46.16 |
| (both with the commits and with my sanity :) ) | 11:46.25 |
tor8 | rats! | 11:46.34 |
Robin_Watts | Fwibble. | 11:46.49 |
tor8 | right, so round_rect adds 0.001 to the values to allow very-near-integer values to round rather than just strictly floor/ceil truncating | 11:47.31 |
| question is, whether that's worth worrying about | 11:47.49 |
| for all internal rects for temporary scratch pixmaps and font glyphs it shouldn't matter | 11:48.22 |
| the only place I see it could be relevant is for the page media box rounding to an integer size to render | 11:48.52 |
Robin_Watts | I can only imagine that that was added because we had a specific file that was rendering wrongly. | 11:49.29 |
| possibly because something was working out as 0.9999999 etc. | 11:49.43 |
| Moving from ints to floats will only worsen this kind of problem :( | 11:50.08 |
tor8 | Robin_Watts: no it won't. *nothing* changes rendering wise from that patch. | 11:50.25 |
| we probably did the fuzzy because of the white borders that can appear on pages that have a solid fill that exactly matches the mediabox boundaries | 11:51.14 |
Robin_Watts | Ah, could be. I'd hope that git blame would show us? | 11:51.46 |
tor8 | agh, soooo many uninitialized warnings with release build :( | 11:52.40 |
| huh, no diffs at all with any of the sumatra files if I just do the exact rounding everywhere. | 11:54.00 |
| except the warning for /TR disappeared. did I wrongly simplify that if test? | 11:54.34 |
Robin_Watts | I stared at that for a while. | 11:57.31 |
| I think you didn't simplify it, you fixed it. | 11:57.39 |
| You changed a "!tr" to a "tr" | 11:57.53 |
| but if you weren't aware of changing the behaviour we should double check. | 11:58.13 |
tor8 | it didn't make sense the way I tried to read it | 11:58.15 |
| so I *think* I fixed it | 11:58.23 |
| gcc threw a warning at it, which prompted me to look and it just didn't make sense | 11:58.44 |
Robin_Watts | Then I think we're good. | 11:59.10 |
tor8 | Robin_Watts: http://git.ghostscript.com/?p=mupdf.git;a=commit;h=5409d2f3ba310b59074ec590ea69ecd423653d85 | 12:02.36 |
| that's where you introduced the two separate ones | 12:02.47 |
Robin_Watts | Does that bug have an example file on? | 12:03.15 |
tor8 | nope. | 12:03.24 |
| I think though, before we had fuzz with FLT_EPSILON always | 12:03.33 |
sebras | tor8: the uninitialized warnings are mine. I tried to point to a fix patch, but you never took it. | 12:03.42 |
tor8 | you wanted exact rounding for the temp buffers so introduced the split | 12:03.52 |
Robin_Watts | ok. | 12:05.14 |
tor8 | I believe we should be okay with exact rounding everywhere though | 12:08.41 |
Robin_Watts | exact being +.0001 ? :) | 12:10.36 |
| yes, you may be right. | 12:10.42 |
tor8 | Robin_Watts: exact being just plain floor/ceil | 12:10.58 |
Robin_Watts | no, that's no good. see the problem the bug was for. | 12:11.17 |
tor8 | i.e. fz_bbox_covering_rectt everywhere | 12:11.20 |
| "round slavishly to ensure we have a bbox that covers the rect" is what you added | 12:11.51 |
| "round, allowing for slight calculation errors" is what I'm doubting we have a need for | 12:12.13 |
Robin_Watts | ok, sorry. | 12:12.27 |
| If your tests show it's safe, I won't fight it. | 12:12.38 |
tor8 | (did you get my meaning taken as opposite) | 12:12.39 |
Robin_Watts | you may be right. | 12:12.43 |
tor8 | Robin_Watts: I'd be happier with more tests, but I get zero diffs on the sumatra files from master to float-rect-everywhere with slavish rounding | 12:13.30 |
Robin_Watts | tor8: clusterpush! | 12:13.44 |
tor8 | how do? | 12:14.01 |
| it's ... been a while since I did that. /hangs-head-in-shame I should know this by now. | 12:14.23 |
Robin_Watts | If you've set it up, then 'git cluster' :) | 12:14.41 |
tor8 | I have not :) I've got the cluster ssh key installed but that's it | 12:15.01 |
| is there an email I can search for? | 12:15.19 |
Robin_Watts | If not (and you're not on windows), then PATHTOGHOSTPCL/gs/toolbin/clusterpush.sh | 12:15.26 |
| tor8: I did send an email around about clusterpushing on windows, but you're on your mac, right? | 12:15.58 |
tor8 | I'm on linux mostly, actually | 12:16.16 |
Robin_Watts | oh, even better. | 12:16.21 |
tor8 | Robin_Watts: I don't have that path | 12:17.19 |
| there's a gs/toolbin/localcluster directory with a couple different scripts in it | 12:17.35 |
Robin_Watts | gs/toolbin/localcluster/clusterpush.sh, sorry. | 12:17.37 |
| and it might be .pl not .sh | 12:17.49 |
tor8 | you mean gitpush.sh or clusterpush.pl? | 12:17.55 |
Robin_Watts | clusterpush.pl | 12:18.17 |
| gitpush.sh is my script to allow git based pushes (created for windows users like me) | 12:18.39 |
tor8 | Robin_Watts: right. | 12:18.47 |
| what happened to the separate cluster.git repository? | 12:18.57 |
| or is that cluster.git stuff only on the server side? | 12:19.17 |
Robin_Watts | That's the server side. | 12:19.33 |
| So, 30 differences. | 12:30.32 |
| Now do: clusterpush.pl bmpcmp | 12:30.40 |
tor8 | Robin_Watts: right, so most can't be compared due to ending up a different size | 12:39.21 |
Robin_Watts | ok, so we do get stuff a different size. check those manually for white lines etc? | 12:39.46 |
| Other ones look either neutral or progressions to me. | 12:41.40 |
| (In the bmpcmp it's "Candidate, Reference, Diff" (or "New, Old, Diff"). Different to sane. | 12:42.19 |
| and to compare them hold the ctrl button and waggle the mouse into/out of the left hand image to see them swap. | 12:42.42 |
tor8 | the javascript doesn't work | 12:44.09 |
| number 23 looks worrying to me, the arrowhead turning blue at the tip | 12:44.23 |
Robin_Watts | What browser? | 12:44.52 |
| Yes, that is bad :( | 12:45.05 |
tor8 | chrome on windows | 12:45.11 |
Robin_Watts | I'm using chrome on windows too. | 12:45.19 |
tor8 | the popup zoom works, but it never toggles | 12:45.26 |
Robin_Watts | and the javascript works for me :( | 12:45.28 |
| Left hand image for toggling. | 12:45.44 |
| and you need to hold ctrl. | 12:45.50 |
| and move the mouse pointer into/out of the image. | 12:46.13 |
tor8 | ah. pushing ctrl while inside doesn't toggle | 12:46.16 |
| you have to cross the image border with control held down | 12:46.25 |
Robin_Watts | yeah. | 12:46.31 |
tor8 | but it stays stuck after leaving, so now I don't know which is reference anymore :( | 12:46.56 |
Robin_Watts | Put the mouse int he middle image and I think it all resets. | 12:47.46 |
tor8 | with the mouse over the image, press control and leave the image frame | 12:47.49 |
| and it gets stuck in the toggled state | 12:47.57 |
Robin_Watts | yes. If you want to suggest a fix for the javascript please feel free :) | 12:48.21 |
tor8 | um, no :) | 12:48.29 |
Robin_Watts | It's not perfect, but it's much better than not having it at all. | 12:48.49 |
tor8 | I'll learn to live with the way it works! better that than hacking JS in a browser. | 12:49.11 |
Robin_Watts | I think it all worked fine until people wanted it put on the ctrl key cos it was confusing otherwise. | 12:52.06 |
tor8 | yeah. I'd prefer it without the control key | 12:52.25 |
| or just toggle *all* of them on the page when pressing and releasing control | 12:52.38 |
plauto | cannot compile gs from git | 13:33.49 |
| ./autogen.sh && make so | 13:33.57 |
| output here | 13:34.00 |
| http://pastebin.com/EVqEZEVj | 13:34.07 |
| fedora 17 64 bit with gcc 4.7.2 | 13:34.28 |
| any help? | 13:34.31 |
Robin_Watts | plauto: Does a normal build work? | 13:36.07 |
| (i.e. not a .so build) | 13:36.11 |
plauto | yes, it works fine | 13:36.18 |
Robin_Watts | so, one for chrisl maybe? | 13:38.13 |
chrisl | Let me check it..... | 13:38.41 |
| plauto: it works for me on Ubuntu 64 bit 4.7.2 | 13:44.17 |
| er that should be "with gcc 4.7.2" | 13:44.38 |
kens | I have a Feora installed in VM< let me see what gcc I have | 13:44.47 |
Robin_Watts | I wonder if crt1.o is being included twice for plauto | 13:45.18 |
| oh, possibly both crt1.o and crti.o are included. | 13:45.49 |
kens | Oh I'm afraid the latest 64-bit Fedora I have installed is 14 | 13:46.00 |
Robin_Watts | lunches | 13:46.28 |
plauto | kens: i get linking errors also on a centos 6 | 13:48.38 |
| gcc 4.4.6 | 13:48.47 |
| let me see if it's the very same error... | 13:48.58 |
kens | Umm, OK let me boot Fedora and see what gcc I have tehre,its probably old htough | 13:49.09 |
| My gcc is only 4.5.1 | 13:52.09 |
| I'll get a git update and see what happens | 13:52.21 |
| OK updated master to HEAD | 13:54.21 |
| plauto did you do ./autogen.sh in ghostpdl or gs ? | 13:54.40 |
plauto | in gs | 13:54.55 |
| hope it's not a problem | 13:55.01 |
kens | ok running it now | 13:55.02 |
| Not a problem, just that they are differeny, and I want to make sure I'm doing the same as you | 13:55.43 |
kens | twiddles fingers waiting for compilation to finish | 13:56.43 |
| Yes, I get the same problem with gcc 4.5.1 | 13:58.41 |
| I oculd try updating gcc, what do you think chrisl ? | 13:58.59 |
chrisl | kens: I don't think it's gcc version dependant. I'm downloading Fedora..... | 13:59.46 |
kens | OK if there's anything I can do let me know | 13:59.59 |
chrisl | Find a Fedora maintainer, and smack them? | 14:00.16 |
kens | :) | 14:00.24 |
| Just quickly trying a regular make | 14:00.43 |
| I'm 'fairly' sure this used to work | 14:00.51 |
plauto | chrisl, if it helps you, very similar problem on centos 6 too | 14:01.06 |
kens | I don't normally build an so | 14:01.07 |
chrisl | plauto: don't have centos either, and I really don't want to get it - it's packed full of obsolete packages | 14:01.40 |
kens | OK regular build is just fine, its the so build | 14:02.24 |
Robin_Watts | stops being distracted by mupdf and really goes to lunch. | 14:03.37 |
chrisl | I don't see how a different distribution can cause that kind of problem | 14:04.14 |
kens | I am also puzzled, but like I said, its quite clear here | 14:04.31 |
| I've shutdown my VM, but if you can't reproduce it I can tart it up easily enough | 14:04.55 |
chrisl | It'll be a while, even the download is taking a while, it's a DVD image | 14:05.21 |
Robin_Watts | plauto: Dumb question, but have you cleaned before you built? | 14:31.40 |
plauto | yes, fresh git clone | 14:32.04 |
Robin_Watts | tor8: So, did you pass the smart motion fix review then? | 14:50.05 |
tor8 | Robin_Watts: yes. | 15:06.24 |
Robin_Watts | Thanks. | 15:06.31 |
Robin_Watts | reinstalls MuPDF from the app store, before uploading new apk, to test auto update. | 15:09.27 |
henrys | chrisl:thanks for bringing up the blockers I didn't even notice. | 15:27.30 |
chrisl | henrys: it was a surprise to me! Total coincidence I noticed when I did | 15:29.00 |
sebras | Robin_Watts: so you posted a new MuPDF to Play today? | 15:41.44 |
Robin_Watts | sebras: I did. Have you seen it yet? | 15:41.58 |
| It's not showing on my phone yet. | 15:42.28 |
| or on the web. | 15:42.45 |
sebras | Robin_Watts: so then you updated the version-number I assue? | 15:46.56 |
Robin_Watts | 1.1 (Build 6) | 15:47.07 |
sebras | Robin_Watts: how does the android version-number correlate with the normal mupdf one? 1-to-1 mapping? | 15:47.17 |
| oh.. a build number I see. | 15:47.32 |
Robin_Watts | The apk's have an internal version number, that the website ensures always increases. | 15:47.34 |
| so I just made that visible. Seemed the simplest way. | 15:47.47 |
sebras | ok. I'll test this on my work phone too later tonight. | 15:52.55 |
| had the intentention of doing that sunday but I ended up defrosting my freezer instead. ;) | 15:53.26 |
henrys | chrisl:we should be in freeze now right? | 16:50.48 |
chrisl | henrys: not with blockers pending, and a critical we really want done, I don't think | 16:51.23 |
henrys | I was thinking we should have a freeze announcement and the blockers are obvious exceptions. | 16:52.06 |
chrisl | henrys: okay, I'll do it tomorrow morning, if that's okay - it's nearly 5pm here | 16:52.46 |
henrys | okay sounds good - I guess we can discuss it at the meeting. | 16:53.04 |
mvrhel_laptop | I will see if I can get my item fixed today | 16:53.09 |
henrys | also | 16:53.10 |
ray_laptop | chrisl: thanks for your comment re: the pdf14 clist optimization. I'll wait 'til after the release. | 16:56.14 |
henrys | mvrhel_laptop: sorry you and ray_laptop are on the hot seats. | 16:56.57 |
chrisl | ray_laptop: that's fine. I must admit that I'm guess a little at the risk factor, which is why I thought it might warrant discussion tomorrow. | 16:57.02 |
ray_laptop | henrys: and I am working on my bugs, although why they just turned up, I don't understand. We've had nightly runs with NumRenderingThreads=4 since I put in Robin's patch. | 16:57.24 |
| I thought I had nailed bug 693590, but it only fixes the cases that were mentioned in the bug report (and about 900 others). The remaining 1,113 are in process | 16:59.24 |
henrys | so marcosw didn't report them right away? | 16:59.27 |
ray_laptop | henrys: I don't know. I just saw the bug on Sat | 17:00.09 |
| I have to run my dog over to the vet. bbiab | 17:00.35 |
Robin_Watts | That sentence is a fabulous example of the importance of punctuation. | 17:01.47 |
| I have to run my dog over. To the vet! bbiab | 17:02.22 |
ray_laptop | Robin_Watts: :-) | 17:02.22 |
Robin_Watts | ray_laptop: Hope doggy is OK. | 17:02.37 |
ray_laptop | Robin_Watts: actually just going for shots and grooming. He's fine | 17:02.59 |
Robin_Watts | ah, cool. | 17:03.16 |
henrys | and why AI is a bitch. | 17:03.18 |
| I can't wait to see these ubuntu phones - emacs on the phone - cool! | 17:09.14 |
marcosw | henrys: the multi threaded rendering test only runs once a week. And there have been several commits in the last few weeks that have changed thousands of bitmaps, so I've been a bit behind at looking at bitmaps and filing bugs. | 17:09.49 |
| Having so many commits before a release can cause the regression testing analysis to fall behind. And of course just before a release is when regression testing is most important. | 17:09.51 |
alexcher | Robin_Watts: What do you thing about #ifndef NO_MEMENTO for the bug 693284? It's included by default. Clients that define random names are on their own. | 17:10.14 |
henrys | marcosw: yeah understood. | 17:10.59 |
Robin_Watts | alexcher: JBIG_NO_MEMENTO ? | 17:12.01 |
alexcher | Robin_Watts: Fine for me. | 17:12.24 |
Robin_Watts | cool. | 17:12.57 |
marcosw | we should have a one week code freeze before release, to allow the regression testing to catch up :-) | 17:13.28 |
henrys | marcosw:well we'll probably freeze everything except blocker work tomorrow. | 17:15.28 |
marcosw | yes, but commits will continue, so we won't be testing the actual shipping 9.07. I think we discussed this 6 months ago⦠Also we tend to not freeze for an entire week. | 17:16.37 |
chrisl | marcosw: I create a release branch which only gets commits required for the release, so you can test that | 17:18.16 |
marcosw | chrisl: Historically I haven't been pointing the regression tests at the release branch, I will do it this time. | 17:19.59 |
ray_laptop | it should be easy enough for us to hold off "optional" commits for a week. If we are concerned about losing a local copy, just email the patch to yourself, or stick it up on casper | 17:20.29 |
chrisl | ray_laptop: the idea behind the release branch was to have an explicit "gate" for commits going into the release, to reduce the chance of accidentally committing during the "freeze". | 17:21.45 |
| marcosw: the release branch will be called "gs907" | 17:22.15 |
ray_laptop | we all just work on a 'during_freeze' branch and then merge it to the 'master' after the freeze | 17:22.29 |
kens | I have to go goodnight all | 17:22.50 |
ray_laptop | so that marcos' testing can use the master | 17:22.55 |
| bye, kens | 17:22.59 |
mvrhel_laptop | darn 693418 does not have the problem with any gray device. looks like I have to fool with cups with -dcupsColorSpace=0 | 17:23.05 |
| how to I get cups working in windoze again... | 17:23.17 |
chrisl | ray_laptop: that's how we used to do it, and people didn't like it, that's why I changed..... | 17:23.17 |
ray_laptop | I almost have the file downloaded for our yet to be numbered customer bug 693592 | 17:24.27 |
| oops wrong bug. should be bug 693579 | 17:25.14 |
henrys | we need a no number number ;-) | 17:26.01 |
ray_laptop | I missed marcosw to ask if he was going to see if he can reproduce it. | 17:26.03 |
| henrys: just email Joann or Miles and ask for a number | 17:26.32 |
mvrhel_laptop | aha. WITH_CUPS=1 | 17:27.37 |
| hmm that did not work | 17:29.39 |
chrisl | mvrhel_laptop: you probably need to "clean" as well | 17:30.06 |
mvrhel_laptop | yes. doing that now.. | 17:30.13 |
| still failed. | 17:34.03 |
| I have it set in the Nmake preprocessor setting | 17:34.17 |
| where all the others are set (e.g. SSE2 etc) | 17:35.01 |
chrisl | Is it on the nmake command line? | 17:35.05 |
mvrhel_laptop | no. but I had thought it would go where the other options went | 17:36.23 |
| let me stick it in the Build command line directly | 17:36.39 |
chrisl | WITH_CUPS is an nmake option, not a preprocessor directive | 17:37.22 |
mvrhel_laptop | ok | 17:37.47 |
henrys | ray_laptop:I just sent a email to them, funny I thought I had already done that but didn't see an outgoing email so I guess I didn't. | 17:46.40 |
ray_laptop | I can't reproduce bug 693579. I guess Marcos will have to find out more info from the customer. Also looking at the file, I can't see any reason it should leak. | 17:47.55 |
| marcos should get my comments since the bug is assigned to him | 17:48.20 |
| back to bug '590 | 17:48.39 |
mvrhel_laptop | finally... running | 17:50.30 |
| good grief. in my crummy linux in hyperview this is going to take all day just to get set up to view the damn files | 18:03.18 |
| so looking at the output, I am puzzled as to what the issue is | 18:11.41 |
| henrys: I am going to need someone else to see if they see any diffs with this | 18:12.37 |
| I am running the win32 build, but on my 64 bit machine | 18:13.17 |
| so this is bug 693418 | 18:13.39 |
| oh comment 1 mentions a segv | 18:14.44 |
| I guess I should run that in linux to see | 18:14.52 |
| I was looking at comment 0 | 18:15.09 |
henrys | mvrhel_laptop: hard to understand how your change would be related to that kind of crash. | 18:18.50 |
mvrhel_laptop | yes. I am trying to see if I can get the segv in linux now. | 18:19.08 |
chrisl | plauto: I have fedora up and running now, and I can see the problem. What's happening is that the link step is being called (at least) twice. The second time, it's being called as if it were linking a full executable (so if you do "file libgs.so.9.07" it lists it as an executable instead of a shared object). Obviously, when we then try to link with an object file to produce the intended executable(s) we get the multiple | 18:24.16 |
| definitions error. I currently have *no* idea why this is happening, and I need to finish for the day...... | 18:24.16 |
mvrhel_laptop | ?? is cups not included by default in the linux build | 18:35.18 |
| henrys | 18:35.22 |
| ? | 18:35.24 |
| oh shoot I have to head out to the kids school now to see my daughters presentation. back in a while | 18:35.48 |
alexcher | marcosw: Is there a way to combine 'lowres' and 'gs' regression modes? | 18:41.56 |
ray_laptop | mvrhel_laptop: I have a question (when you get back is OK). Please call me. | 18:43.13 |
plauto | chrisl: thanks | 18:46.03 |
Robin_Watts | alexcher: clusterpush.pl gs lowres ? | 18:49.53 |
ray_laptop | Robin_Watts: in mem_planar_fill_rectangle_hl_color the loop for each plane is setting up for plane_depth in the loop. Does it _really_ have to do that ? | 20:15.45 |
Robin_Watts | let me look. | 20:27.04 |
| Ghostscripts planar stuff is kinda schizophrenic. | 20:27.56 |
| Some of it allows for planes with different depths, some of it doesn't. | 20:28.11 |
| This code does, hence it has to get the mdproto each time. | 20:28.37 |
| You could potentially short circuit that if you detect that the bit depth is unchanged. | 20:29.37 |
ray_laptop | I can't imagine a device with ddifferent depths per plane | 20:29.39 |
Robin_Watts | but really, gdev_mem_device_for_bits is just an array load. | 20:30.09 |
ray_laptop | true | 20:30.23 |
mvrhel_laptop | ray_laptop: I am here now | 20:40.15 |
| ok. what magic do I need to do to have cups built in linux now to check for this segv | 20:41.45 |
Robin_Watts | Do you have cups installed on your linux box ? | 20:42.26 |
mvrhel_laptop | no | 20:42.31 |
| that there is probably the problem | 20:42.39 |
Robin_Watts | Then configure may avoid it. | 20:42.40 |
mvrhel_laptop | ok. let me start that process | 20:42.52 |
| well, I do have some cups related stuff installed. | 20:47.07 |
| I am not sure what all I need | 20:47.12 |
| what a pain | 20:47.20 |
| I have the Common Unix Printing System installed already | 20:48.08 |
Robin_Watts | ./autogen.sh --with-local-cups ? | 20:48.19 |
mvrhel_laptop | ok that may do it | 20:48.56 |
Robin_Watts | [Force using the GS supplied cups code - only useful for debugging] | 20:49.04 |
mvrhel_laptop | ok that worked. thanks Robin_Watts | 20:51.36 |
Robin_Watts | np. | 20:51.41 |
mvrhel_laptop | and the page rendered fine | 20:51.43 |
Robin_Watts | Now if you can tell me why I've lost all type3 glyphs in mupdf, we'll both be happy :) | 20:52.02 |
mvrhel_laptop | henrys: so I can't duplicate any of the issues in the bug | 20:54.03 |
| marcosw: I am going to punt this one back to you | 20:54.15 |
marcosw | uh oh. which bug? | 20:54.35 |
henrys | one of those blocker ones | 20:55.30 |
mvrhel_laptop | 693418 | 20:55.44 |
| I just changed it to WORKSFORME | 20:55.50 |
| 1/2 a day spent screwing with cups | 20:56.11 |
marcosw | which operating system where you using? | 20:56.46 |
mvrhel_laptop | linux and windows | 20:56.53 |
henrys | I thought we had this set up so it is easily worked on in windows? | 20:56.57 |
mvrhel_laptop | well I had to find the magic value to set | 20:57.08 |
| to include it | 20:57.13 |
| when I use something like that once a year I forget | 20:58.03 |
| and that all worked fine | 20:58.13 |
| so I looked for the segv that was reported on linux with the bug | 20:58.28 |
| and I could not get that to occur | 20:58.33 |
Robin_Watts | mvrhel_laptop: To build with Cups on windows, just select the "Debug-cups" configuration in visual studio. | 20:58.47 |
mvrhel_laptop | oh crap | 20:58.50 |
| I see that the comment says debug build | 20:58.57 |
| I was running a release build | 20:59.01 |
| let me try the release build | 20:59.07 |
| i mean the debug build | 20:59.11 |
| Robin_Watts: aha! | 20:59.18 |
| that is easy | 20:59.24 |
Robin_Watts | I thought you added that? :) | 20:59.34 |
mvrhel_laptop | chris told me to change the nmake command | 20:59.50 |
Robin_Watts | chris is an old school command liner :) | 21:00.05 |
mvrhel_laptop | anyway, let me try the debug version to see if it segvs | 21:00.22 |
henrys | now you can spend 2 1/2 days screwing with cups | 21:00.30 |
mvrhel_laptop | :) | 21:00.35 |
| ok. the debug build ran fine too. whew | 21:05.38 |
| marcosw: so maybe you can recheck? | 21:05.48 |
marcosw | mvrhel_laptop: yes, I'm doing that know. I'm running a clean build on peeves. | 21:06.29 |
mvrhel_laptop | ok. thanks. | 21:06.36 |
| meanwhile, I think I see how to fix my vmware hyper-v issue..... | 21:07.00 |
| brb. restarting to see if I can turn off hyperv | 21:09.43 |
| success. I am able to use vmware again | 21:15.42 |
marcosw | mvrhel_laptop: Bug 693418 appears to be fixed. I'm curious, so am doing to run a bisect. | 21:15.51 |
mvrhel_laptop | marcosw: that is good news to me | 21:16.01 |
| marcosw: it is probably a fix that Robin_Watts did | 21:16.25 |
marcosw | darn that Robin_Watts, fixing other people's bugs. | 21:16.42 |
mvrhel_laptop | it the issue is from the planar stuff that I did | 21:16.45 |
| that is my approach to bugs like that one. wait for someone else to fix their bug and mine gets fixed as a bonus | 21:17.42 |
henrys | down to 1 blocker - good news | 21:18.59 |
mvrhel_laptop | now, to set up my vmware ubuntu machine which I had unfortunately deleted when I was thinking I would do a full move over to hyperv | 21:19.07 |
henrys | we have to get this out the customers so they can test it ;-^ | 21:19.34 |
| Are we going to move to 2012 project files soon? | 21:21.14 |
mvrhel_laptop | henrys: Good question about 2012. I think I am the only one running 2012 | 21:22.59 |
henrys | I used it for a couple of fixes recently. | 21:24.09 |
mvrhel_laptop | marcosw: how did the bisect end? | 22:11.24 |
marcosw | not well, can't reproduce the seg fault at all. | 22:11.55 |
| I'm going to be at home soon, will look for the bitmap difference issue then. | 22:12.35 |
sebras | tor8: Robin_Watts_: I see that you forgot to run the text-selection feature in mupdf by your testing guy... | 23:07.00 |
| Robin_Watts: tor8: I was using my work phone and managed to first get MuPDF into a zoomy state and eventually it appears to have crashed. | 23:34.55 |
| smaller.mp4 at ~sebras/tmp and original.mp4 for the adventurous... | 23:46.35 |
| I have tried to reproduce this on my sensation, but I fail to do so. | 23:48.56 |
| so it might very well be something tied to the android version in use. | 23:49.09 |
| on my sensation: 2.3.3 on my samsung: 2.3.6 apparently. | 23:49.49 |
| my work here is done >;) good evening. | 23:50.42 |
| Forward 1 day (to 2013/01/29)>>> | |