| | <<<Back 1 day (to 2011/08/01) | 2011/08/02 |
| kens | Robin_Watts : you up yet ? | 08:14.17 |
| Robin_Watts | I am. | 08:19.37 |
| kens | Silly Git question | 08:19.51 |
| | I used Git to rewind to an earlier commit. | 08:20.01 |
| | Now I want to go back to the head, but it won't let me, what am I doign wrong ? | 08:20.18 |
| | I've tried every combination of git reset I can think of | 08:20.28 |
| Robin_Watts | What command did you use ? | 08:20.33 |
| kens | git reset, git reset <commit> with or without --hard | 08:20.46 |
| | <commit> being the current head | 08:21.00 |
| Robin_Watts | And in what way won't it let you ? | 08:21.16 |
| kens | "error: The following untracked working tree files would be overwritten by checkout: | 08:22.21 |
| | ... | 08:22.22 |
| | Please move or remove them before you can switch branches | 08:22.22 |
| | Aborting | 08:22.22 |
| | could not detach HEAD" | 08:22.22 |
| | However git status says words like 'can be fast=-tracked' | 08:22.46 |
| Robin_Watts | Right. So you have files in your working directory that have been created between where you are in history, and where you want to go. | 08:23.18 |
| kens | "Your branch is behind origin/master by 146 commits, and can be fast-forwarded." | 08:23.26 |
| Robin_Watts | If git went ahead and zoomed through the history, it would overwrite them and you might lose work. | 08:23.48 |
| kens | Robin_Watts : THey were created by later commits | 08:24.00 |
| Robin_Watts | Right. | 08:24.07 |
| | So you need to delete them from your working tree before you can move forwards. | 08:24.22 |
| kens | So you're saying I need to manually delete them ? | 08:24.38 |
| Robin_Watts | yes. | 08:24.47 |
| kens | Well that's pretty crap, there are dozens. | 08:24.56 |
| Robin_Watts | Well, there is a magic 'git clean' command that may help. | 08:25.07 |
| kens | i sunimpressed, this is much harder than I expected | 08:25.21 |
| Robin_Watts | but that deletes all files that git doesn't know about. | 08:25.23 |
| kens | I don't think I care, I'll try it. | 08:25.35 |
| | Hmm, presumably including all my object files and executables ? | 08:26.02 |
| Robin_Watts | No, they might be OK, cos there are .gitignored. | 08:26.15 |
| kens | For future reference, is there a better way of zomming backwards and forwards through revisions ? | 08:26.28 |
| Robin_Watts | Always use --hard if you can, because it deletes files in the working set. | 08:26.57 |
| kens | fatal: clean.requiresForce defaults to true and neigher -n nor -f given; refusing to clean | 08:27.03 |
| Robin_Watts | git clean -f then. | 08:27.15 |
| | Maybe git clean -n will list the files it will clean or something. | 08:27.35 |
| kens | -f listed them. | 08:27.42 |
| | It looks OK its about right. | 08:27.47 |
| | SO now how to go back to head ? | 08:27.54 |
| Robin_Watts | git reset --hard <commit> | 08:29.15 |
| kens | git up seems to work | 08:29.20 |
| | Hmm, I wonder what I'd changed in the text device :-( | 08:30.03 |
| | Well, it seems to be building, thanks Robin | 08:32.45 |
| Robin_Watts | np. | 08:32.51 |
| | kens: How do you do the editing thing in acrobat? | 10:42.15 |
| | I want to remove everything except one thing on a page. | 10:42.41 |
| | but selection doesn't appear to work. | 10:42.47 |
| kens | It doesn't for some things, forms especially | 10:43.31 |
| Robin_Watts | The caret will move through the text, but I can't delete it. | 10:43.50 |
| chrisl | You can probably only delete the entire text object, rather than individual characters | 10:44.59 |
| Robin_Watts | Can't even delete that :( | 10:45.11 |
| kens | Yes, later versions of Acrobat won't delete subset fonts. | 10:45.20 |
| chrisl | Using the object touch up tool? | 10:45.29 |
| kens | You can usually delete teh entire text block as chrisl suggests | 10:45.48 |
| Robin_Watts | I can't delete anything. Here, let me show you the file... | 10:46.05 |
| | http://ghostscript.com/~robin/VOX.pdf | 10:46.35 |
| | All I want left is the image in the top right, with the shadow. | 10:46.52 |
| chrisl | I can delete various things, including the text. | 10:48.19 |
| kens | Me too. I don't see the shadow htough | 10:48.29 |
| chrisl | Tools->Advanced Editing->TouchUp Object Tool | 10:49.06 |
| Robin_Watts | I've done it by hand now. | 10:50.13 |
| | but thanks. I'll look at the Touchup tool in future. | 10:50.27 |
| Robin_Watts | runs errand. back soon. | 10:55.58 |
| | Ah, tor8. | 11:38.01 |
| | I've been testing out my mupdf changes from yesterday. | 11:38.21 |
| | and I'm seeing differences in VOX.pdf | 11:38.37 |
| | The 'glows' around objects are less obvious than they were before. | 11:38.59 |
| tor8 | improvements? | 11:39.48 |
| Robin_Watts | Unsure. | 11:39.54 |
| tor8 | the VOX pdf is troublesome, to say the least | 11:40.01 |
| Robin_Watts | No isolated or knockout groups used, only softmasks. | 11:40.15 |
| | Does mupdf support softmasks ? | 11:40.25 |
| | I'm tempted to say go with it until we find evidence that it's obviously wrong. | 11:41.30 |
| tor8 | yeah, but there are so many layers of cruft in the VOX file that any change always make it look a bit different from last time :) | 11:49.01 |
| | want me to push the patch you have on casper now? | 11:50.23 |
| Robin_Watts | yes please. | 11:50.49 |
| tor8 | done. | 11:51.18 |
| Robin_Watts | Thanks. | 11:57.45 |
| | tor8: Any other mupdf bugs that come down to groups or bitmap scaling ? | 12:00.19 |
| | looks like zeniko has bounced 691629 back again. | 12:07.17 |
| tor8 | Robin_Watts: I ran into a segfault on a PDF locally yesterday | 12:13.21 |
| | or was that friday | 12:13.28 |
| | let me dig it out, I think it was image scaling with size 0 that triggered it | 12:13.43 |
| Robin_Watts | tor8: Another patch. Just saning it now. | 13:11.49 |
| | why has freetype suddenly started to fail to build on macosx... | 13:17.25 |
| | ok, was macosx installer redefining TMPDIR | 13:21.39 |
| | OK, 2 patches on casper for you tor8. | 13:31.01 |
| | http://bugs.ghostscript.com/show_bug.cgi?id=691983 seems partly fixed. text now appears, but the boxes themselves are lost at higher res. | 13:37.01 |
| tor8 | Robin_Watts: fitz/res_pixmap.c:207: warning: pointer targets in initialization differ in signedness | 13:52.31 |
| Robin_Watts | Another one ? | 13:52.52 |
| tor8 | you seem to have forgotten one in the last patch, yes | 13:53.28 |
| Robin_Watts | let me roll that into the last one. | 13:56.47 |
| | unless you've pushed already ? | 13:56.54 |
| | OK. new version online. | 13:57.44 |
| tor8 | Robin_Watts: pushed. | 14:03.10 |
| Robin_Watts | tor8: Thanks. | 14:03.20 |
| | kens, chrisl_away: OK, trying the touchup tool now. | 14:06.02 |
| | It seems to want to select everything on my page, or nothing. | 14:06.11 |
| kens | Let us know if it works OK for you | 14:06.14 |
| | just click on the object | 14:06.20 |
| Robin_Watts | D'Oh. | 14:06.38 |
| | Thanks. | 14:06.39 |
| kens | No Problem | 14:06.43 |
| | You can do a marquee select as well | 14:06.57 |
| | But its harder | 14:07.01 |
| Robin_Watts | Bah. I thought it was to good to be true. | 14:11.22 |
| | It now won't save the document, saying "There was a problem reading the document" | 14:11.41 |
| kens | Sounds like the original was broken | 14:11.51 |
| | But its true that it doesn't always work, and can sometimes cause the pbolem to go away. | 14:13.19 |
| marcosw | mvrhel2: are you around? | 15:59.00 |
| mvrhel2 | yes | 15:59.17 |
| marcosw | your rev. d3302b1176683dc9e4cb5cb8ed9f42bffa0888ee changed the pkmraw output for gray-to-cmyk-with-transfer.ps to all black, is this a bug? | 15:59.47 |
| kens | meeting time ? | 16:00.05 |
| mvrhel2 | marcosw: Sounds like a bug to me | 16:00.11 |
| henrys | yes we should start | 16:00.13 |
| marcosw | okay, I'll open a bug for the issue. | 16:00.22 |
| henrys | I'll start with a nit to marcos - can we use a link to the git repo instead of hashes to reference commits | 16:00.49 |
| | ? | 16:00.50 |
| mvrhel2 | marcosw: ok thanks. I will take a look at that today | 16:00.51 |
| Robin_Watts | henrys: where ? | 16:01.11 |
| kens | Reminder: I'll be on vacation from tomorrow till a week Thursday | 16:01.12 |
| henrys | kens:so we'll just tell Raed he's out of luck for a week ;-) | 16:02.09 |
| kens | Suits me :-) | 16:02.15 |
| henrys | release discussion seems needed | 16:02.35 |
| | chrisl:how are we doing? | 16:02.48 |
| kens | says 'good luck' and waves | 16:02.59 |
| henrys | did you get enough info from rayjj to do the commercial release? | 16:03.15 |
| chrisl | I've had only one respondent about the rc and that was confirming his fix was in it (so I assume he built it okay) | 16:03.25 |
| | yes, I'm good for the commercial release, too. | 16:03.36 |
| Robin_Watts | Are there any blockers left? | 16:03.51 |
| henrys | I encourage *everyone* to download the code and beat on it. | 16:04.01 |
| kens | Ray and I won't be here.... | 16:04.14 |
| | Nor Robin soon | 16:04.26 |
| henrys | sorry everyone "on duty" | 16:04.37 |
| kens | :-) | 16:04.43 |
| chrisl | There are no open bugs *marked* as blockers | 16:04.56 |
| mvrhel2 | I think ray is out today isnt he? | 16:05.06 |
| alexcher | Do we care about legacy UNIX platforms? | 16:05.09 |
| kens | Yes, ray is already on vacation | 16:05.19 |
| henrys | mvrhel2:yes | 16:05.22 |
| chrisl | alexcher: how legacy? | 16:05.30 |
| mvrhel2 | next week I am going to be on east coast time zone, in North Carolina, Virgina and Michigan | 16:05.46 |
| henrys | mvrhel2:I had a question for you can Freek (sic) printer print isolated dots? | 16:05.53 |
| | it seems you and ray are pushing him to FM screening and I'm not sure he "wants" that. | 16:06.28 |
| mvrhel2 | that is a good question henrys: one that i assumed was true. if not, the genpatt screen from ray will not work | 16:06.28 |
| alexcher | chrisl: I can't define them exactly. HP-UX, AIX, Solars, etc. | 16:06.31 |
| mvrhel2 | henrys: if not, then he will need to wait until I finish my screen solution | 16:06.49 |
| henrys | mvrhel2:well I guess you'll find out soon enough. | 16:06.52 |
| chrisl | alexcher: well, I've built and tested (a little) on Solaris, I no longer have AIX nor Irix to try | 16:07.15 |
| mvrhel2 | I will check with him today to make sure. I am playing around a bit with genpatt before I give it to him | 16:07.22 |
| henrys | alexcher:I guess I don't feel really good that we got to the underlying issue with the shading. Do you? | 16:07.36 |
| | mvrhel2:okay. | 16:07.47 |
| mvrhel2 | but if he can't print single dots, then he will need to do my solutino | 16:07.50 |
| | solution | 16:07.54 |
| henrys | marcosw, Robin_Watts:I was referring to marcosw bug reports that just give the full hash of the regression. | 16:09.19 |
| | it would just be faster for all to have a link. | 16:09.38 |
| Robin_Watts | henrys: on irc? or by mail? | 16:09.44 |
| alexcher | henrys: Yes, there's a problem in the memory management but I was unable to figure it out yet. The proposed patch wors around it. | 16:09.44 |
| marcosw | henrys: you mean a link to git.ghostscript.com? | 16:10.11 |
| alexcher | henrys: the patch is good enough for the release. | 16:10.35 |
| Robin_Watts | chatzilla has a funky feature whereby 'bug 690456' is instantly transformed into a clickable link. | 16:10.38 |
| henrys | marcosw:yes - you only need the first 7 I believe | 16:10.39 |
| Robin_Watts | I guess it'd be possible to do the same thing with 'rev hash'. | 16:11.19 |
| henrys | Robin_Watts:I was referring to his bug reports there was a recent regression for michael but I think the links should be used everywhere. | 16:11.30 |
| | suppose a customer wants to see the code that fixed something and doesn't have git? | 16:12.20 |
| Robin_Watts | In autogenerated mails, that seems sensible. | 16:12.26 |
| | In bug reports, I don't think we can expect people to use links all the time. | 16:12.50 |
| | It should be something that bugzilla does automatically. | 16:12.59 |
| henrys | kens, Robin_Watts:do you have anything before you leave on vacation - do you want somebody to look at something or can everything wait until you get back? | 16:13.38 |
| kens | It caused me trouble this morning. Finding the code required using git bash. git web doesn't search for commit by SHA | 16:13.46 |
| | henrys I'm pretty up to date. | 16:13.59 |
| | No urgent bugs outstanding. | 16:14.06 |
| chrisl | henrys: note that I changed the changelog so commits are linked to git.ghostscript.com | 16:14.06 |
| Robin_Watts | kens: If you know the sha, you can generate a git web link from it trivially. | 16:14.31 |
| | henrys: I believe I have nothing urgent pending. | 16:14.45 |
| kens | Well, I don't know how to do that ;-) I had to use git log -p. If its trivially easy, then why not have Marcos put it in the bug report ? He already has the SHA, that's what he's gving us. | 16:15.12 |
| henrys | It is pretty easy to go to the git commit on the web and copy paste the link - until we have an automated solution in bugzilla - only the first 7 need be copied afaik | 16:15.20 |
| marcosw | is http://bugs.ghostscript.com/show_bug.cgi?id=692392 an example of how I should be putting URLs in bugs? | 16:15.33 |
| kens | henrys which git commit, I couldn't get to the one Marcos put in the bug report | 16:15.45 |
| Robin_Watts | kens: http://git.ghostscript.com/?p=ghostpdl.git;a=commit;h= and paste your hash on the end. | 16:15.52 |
| kens | OK, but why not just put the URI in the bug report so I can click it ? | 16:16.16 |
| | marcosw yes, I like that much better | 16:16.33 |
| Robin_Watts | kens: I'm saying that bugzilla should do that for us. | 16:16.36 |
| henrys | kens:I was asking marcosw to do that and put the entire url in the bug report. | 16:16.38 |
| Robin_Watts | When bugzilla seems a string of hash numbers in a comment it should make it a clickable link. | 16:16.59 |
| chrisl | marcosw: I usually put the first 6 digits in the hash, but yes, that's basically what I do. | 16:17.07 |
| kens | henrys I know, I was arguing with Robin. I'd be happy if Bugzilla did it automagically, but it doesn't right now and it took me quite a hile this morning because I didn't twig the GitWeb thing. | 16:17.24 |
| Robin_Watts | Otherwise it's a pain in the bum to have to manually make the link every time you want to comment. | 16:17.35 |
| kens | Jus tin the initial report is all I'm asking for. | 16:17.54 |
| henrys | marcosw: so has the weekly run against 9.04? | 16:18.29 |
| marcosw | I'm happy to put git urls in the bug reports; I don't use the web interface to git very much, so didn't realize it was problematic. | 16:18.36 |
| kens | hello ray_laptop thought you were on vacation | 16:18.39 |
| henrys | hi ray_laptop aren't you on vacation? | 16:18.54 |
| kens | marcosw I use a variety of tools, but git bash is my least favourite. | 16:19.03 |
| ray_laptop | over southeastern CO at 37k feet | 16:19.14 |
| kens | Hmm, are you allowed to be talking to us from there ? | 16:19.32 |
| ray_laptop | it's only $5 for onboard wi-fi | 16:19.33 |
| kens | For how long ? | 16:19.43 |
| marcosw | henrys: no. and in fact it's a bit of an issue since the weekly pulls master from git which has moved past the gs9.04rc. | 16:19.44 |
| ray_laptop | however long we are in the air | 16:20.02 |
| kens | That's not bad. | 16:20.12 |
| | On a long-hail flight anyway | 16:20.18 |
| chrisl | marcosw: the 9.04 rc was never on master | 16:20.20 |
| kens | err long haul | 16:20.23 |
| henrys | ray_laptop:well I asked the others if they wanted anyone to look at anything while they are away do you have anything - who is tending to to your needy customer while you're away? | 16:20.39 |
| ray_laptop | oops. My wife saw me chatting here. I better not do any work ;-) | 16:20.51 |
| marcosw | ray_laptop: better get back to download pron. | 16:21.06 |
| ray_laptop | they may have a question for mvrhel2 about CRD's (pre-icc) | 16:21.23 |
| henrys | marcosw, chrisl:so how are we doing the weekly? | 16:21.35 |
| | I guess if the master passes the weekly we are going to assume we're in good shape, is that the idea? | 16:22.30 |
| marcosw | I can run the 904rc1 through the weekly regression suite manually, but will take a week (actually half a week, since I can use inches and the other new machine). | 16:23.12 |
| mvrhel2 | ray_laptop: another CRD question? I thought they had that issue figured out | 16:23.35 |
| | last time I waited long enough and they solved it themselves ;) | 16:23.52 |
| henrys | chrisl:your call on weekly testing of the rc. | 16:24.28 |
| kens | hey marcosw, if I ever host a regression suite there is a unit of measurement in Japan called kens :-) Its approximately 6 feet. | 16:24.35 |
| henrys | is it enough to just test master? | 16:24.38 |
| ray_laptop | mvrhel2: they said that their rigged CRD wasn't giving as good as the default sRGB CRD + default to gray :-/ | 16:24.42 |
| mvrhel2 | hehe. | 16:25.07 |
| ray_laptop | mvrhel2: I told them to collect data using -Zc and send logs to you with detailed questions. | 16:25.09 |
| marcosw | kens: based on a famous ken? I was googling for weird units of measure and a lot of of them seem to be based on people's height or the length of various body parts. | 16:25.41 |
| mvrhel2 | ok. I will do what I can. | 16:25.52 |
| kens | marcosw No idea what its historical basis is. | 16:25.56 |
| Robin_Watts | kens: I reckon he should generalise to just units. Then I can have watts. | 16:25.58 |
| kens | Sounds good to me. | 16:26.06 |
| | henrys are OK too. | 16:26.28 |
| henrys | tor8:mupdf port to gs? | 16:26.40 |
| chrisl | henrys, marcosw: I've been doing clusterpush's whenever I pull a change onto the 9.04 branch, so we shouldn't have diverged significantly. If it takes a week to do a "weekly" regression run, we'd be starting to push the 11 Aug date pretty hard | 16:26.49 |
| henrys | chrisl:weekly testing master only is good for me. | 16:28.02 |
| chrisl | marcosw: what's your take on this? | 16:28.34 |
| henrys | the final thing I had from my notes this week is testing error recovery. I see this coming up more often. We should think about a sound way of testing ghostscript for error returning particularly low memory conditions. | 16:29.41 |
| marcosw | chrisl: I don't think the 904rc1 code and master have diverged very much, so it should be okay. otoh, seems a shame to do all this regression testing and not test the release candidates. | 16:29.52 |
| Robin_Watts | henrys: Memento does exactly that. | 16:29.56 |
| | We build with -DMEMENTO, then set MEMENTO_FAILAFTER=1 then run a gs job. | 16:30.41 |
| chrisl | marcosw: is it possible to run only the tests *not* done by a clusterpush? And would that save time? | 16:30.59 |
| Robin_Watts | MEMENTO_FAILAT, sorry. | 16:31.24 |
| henrys | Robin_Watts:FAILAFTER is count of mallocs or count of chunk allocator allocations? | 16:31.36 |
| Robin_Watts | It's a count of 'memory events' as kept by Memento. | 16:32.15 |
| henrys | my understanding is memeno is hooked up to the heap allocator not the chunk allocator. | 16:32.29 |
| Robin_Watts | So, indeed the chunk allocator ones won't be tested. | 16:32.42 |
| henrys | though I guess that would be a good start. | 16:32.45 |
| Robin_Watts | BUT... I could (fairly) easily expose an API from memento where the chunk allocator would count for events too. | 16:33.16 |
| | and then make the chunk allocator 'fail' in the same way. | 16:33.33 |
| henrys | I think doing memory events would be a very good start and might even be enough. | 16:33.56 |
| marcosw | chrisl: it would save time, but it's not practical. | 16:34.07 |
| henrys | anyway 5 minutes past end of meeting - anybody have anything else for the meeting? | 16:34.21 |
| Robin_Watts | so, yes, we should start testing with MEMENTO_FAILAT and I'll try to fix that to work with the chunk allocator before I go. | 16:34.28 |
| henrys | Robin_Watts:no board yet? | 16:34.34 |
| Robin_Watts | Nope. | 16:34.38 |
| marcosw | I could in theory use all the cluster nodes to run a weekly regression in one day, but I'd have to downloads the bitmaps to look at them and that's not practical. | 16:34.38 |
| henrys | Robin_Watts:what will happen to the package if it arrives while you are on vacation - can a neighbor sign for it? | 16:35.33 |
| Robin_Watts | henrys: Generally the parcel delivery companies are pretty good about getting neighbours to sign. | 16:36.04 |
| marcosw | I'm still trying to deal with the Lion building issues (http://bugs.ghostscript.com/show_bug.cgi?id=692375) but am not getting anywhere (tried to compile valgrind for Lion, which didn't work). | 16:36.08 |
| Robin_Watts | Of course, cos I work from home, I am usually that neighbour :) | 16:36.19 |
| chrisl | marcosw: ah, shame. I guess you could go ahead and run the weekly on the 9.04 branch, and we'll hope it gets done in time - I'd really hoped to release this week, oh well :-( | 16:36.25 |
| henrys | marcosw:the lion issue could probably be exposed by running with -ZL and comparing the output. | 16:36.57 |
| marcosw | henrys: thanks for the suggestion, I'll try that. | 16:37.12 |
| henrys | sometimes you have to regexp out hex addresses or you are overwhelmed with diffs. | 16:37.53 |
| marcosw | chrisl: I think we should release based on the testing of master and next time we'll figure out how to test the release candidates. | 16:37.53 |
| | henrys: I've run into that before :-) | 16:38.30 |
| chrisl | marcosw: okay, fair enough. I'm pretty confident in how the 9.04 branch compares to master. | 16:38.57 |
| henrys | alexcher:can you prepare a simple shading example that shows the garbage collector not working - I wonder if it is because they are in different roots - I thought I saw shading allocations in the ref root and another root. | 16:40.19 |
| marcosw | chrisl: it does mean we need at least a week between packaging the release candidate and the release. it also means that regression testing of master will be offline for that week, but presumably that's not a big deal since there are some weeks I don't even look at the weekly regression output (primarily when mvrhel2 changes every bitmap md5sum). | 16:40.21 |
| mvrhel2 | marcosw: I think I am done with those types of commits for awhile | 16:40.49 |
| marcosw | yea! | 16:40.58 |
| mvrhel2 | at last not for another 6 months until a week before the release ;) | 16:41.04 |
| chrisl | marcosw: a whole week between rc and release! That gives *way* too much time for people to find problems...... | 16:41.28 |
| alexcher | henrys: I'll try to make it simple. | 16:41.32 |
| tkamppeter | mvrhel2, chrisl, Robin_Watts, I have found a new segfault, bug report is on its way ... | 16:41.53 |
| Robin_Watts | marcosw, henrys: These memento failed allocation tests; who will be running them? on what machines? and on what set of files ? | 16:42.47 |
| henrys | alexcher:thanks | 16:43.11 |
| | Robin_Watts:I'll try it out first. | 16:43.59 |
| Robin_Watts | henrys: OK. Gimme a yell if you need anything. | 16:44.14 |
| henrys | marcosw:so what file do we use to test all the devices? | 16:45.00 |
| | tiger.eps is not a great choice, something like michael's new test file would probably be more challenging. | 16:45.53 |
| | something that does "get_bits" would be good. | 16:46.23 |
| marcosw | henrys: we aren't routinely testing all devices. I run a script occasionally which does it, but haven't in a while. | 16:46.29 |
| ray_laptop | chrisl: I saw your 'faq' comment on gs-devel. I really think we should have a (bountiable) enhancement bug against the pngalpha. It's pretty easy to do a 'proper' put_image in pngalpha | 16:46.54 |
| henrys | marcosw_:can we do that as part of the weekly? | 16:47.37 |
| | or marcosw | 16:47.46 |
| marcosw | if we are only running a small number of files we could do daily. Are we just checking for run time errors or making sure the output is correct (at least for those output formats that we can read)? | 16:48.49 |
| henrys | marcosw:just checking that output exists. | 16:49.14 |
| tkamppeter | mvrhel2, chrisl, Robin_Watts, it is http://bugs.ghostscript.com/show_bug.cgi?id=692393 | 16:51.01 |
| marcosw | as I recall one of the ouput devices locks up, hold on and I'll find the bug number | 16:51.03 |
| | http://bugs.ghostscript.com/show_bug.cgi?id=691820 | 16:51.38 |
| | though based on last weeks bug report it's not doing it anymore... | 16:51.50 |
| henrys | right chrisl said he couldn't reproduce it, if it comes back we remove that device. | 16:52.27 |
| | maybe we should just remove it anyway sounds like it is probably not functioning properly. | 16:53.16 |
| marcosw | do we have a list of files to test with? I was using tiger.eps previously. | 16:53.22 |
| henrys | I recommend all files in examples/ | 16:53.51 |
| chrisl | tkamppeter: bug 692393 works fine for me | 16:54.00 |
| tkamppeter | chrisl, exactly that command line? Up-to-date GS? | 16:55.05 |
| chrisl | tkamppeter: using the current head of the 9.04 branch, and using exactly your command line. | 16:55.34 |
| tkamppeter | chrisl, also with the PPD downloaded and set as PPD env variable so that GS can use it? | 16:56.34 |
| chrisl | tkamppeter: ah, no, I was missing the PDD, sorry - for some reason I thought it was the same one as before.... | 16:58.12 |
| | tkamppeter: can the PPD file be specified as a device parameter, rather than an environment variable? | 16:59.02 |
| tkamppeter | chrisl, you are on Windows and so the env variable concept is not available for you? | 16:59.59 |
| kens | Windows supports environment variables | 17:00.18 |
| | But chrisl uses Linux | 17:00.22 |
| chrisl | tkamppeter: I'm on Linux, but it's a pain setting it for the debugger | 17:00.34 |
| henrys | you can set env vars in the debugger. | 17:01.54 |
| | set environment ... | 17:02.04 |
| chrisl | henrys: yes, but why should I have to? Why does devcups always have to be "special"? :-( | 17:02.40 |
| henrys | oh sorry I thought you didn't know about gdb's set env... I don't know about cups ... | 17:04.28 |
| chrisl | tkamppeter: anyway, the problem is in clist writing, and unfortunately, that's really Ray's province :-( | 17:05.07 |
| henrys | chrisl:can you put a backtrace in the bug? | 17:05.53 |
| chrisl | henrys: will do..... | 17:06.15 |
| tkamppeter | chrisl, I have found a minimum command line to reproduce the segfault and posted it into the bug. Can you also post a backtrace for that one? Thanks. | 17:07.12 |
| chrisl | tkamppeter, henrys: it doesn't go wrong in the debugger, which suggests that I'm not setting the environment correctly | 17:09.34 |
| | Ah, that's better.... got it! | 17:10.14 |
| tkamppeter | chrisl, henrys, another interesting thing: Removing the -dSAFER or -dPARANOIDSAFER from the sample command lines lets the segfault go away. | 17:11.00 |
| kens | OK I'm off now, be back online in 8 days (Thursday 11th). Have a good holiday when its your turn Robin :-) | 17:12.26 |
| Robin_Watts | kens: You too. | 17:12.38 |
| henrys | bye kens have a good time. | 17:12.38 |
| Robin_Watts | tkamppeter: Does it also fail with a debug ghostscript? | 17:13.03 |
| chrisl | Robin_Watts: yes, it does | 17:13.15 |
| Robin_Watts | Running that through valgrind may be useful. | 17:13.18 |
| chrisl | tkamppeter, Robin_Watts, henrys: the simpler command line goes bang in a quite different place. zsetcolor() | 17:16.50 |
| tkamppeter | chrisl, so it needs fixing two completely different bugs? | 17:17.45 |
| chrisl | tkamppeter: no, I think it's probably memory corruption, and the different options just move the corruption around | 17:18.24 |
| tkamppeter | chrisl, the full command line would be more important, as this is how Ghostscript gets usually called when printing. | 17:18.34 |
| Robin_Watts | hence the valgrind suggestion. | 17:18.43 |
| chrisl | Robin_Watts: hmm, seems to crash valgrind....... | 17:21.37 |
| Robin_Watts | -DMEMENTO then ? | 17:22.20 |
| chrisl | Robin_Watts: I don't have time to try it just now, but if no one else looks at it, I'll do so tomorrow. | 17:23.27 |
| Robin_Watts | I doubt I'll look at it. the mention of the clist has put me off. | 17:24.41 |
| chrisl | From what valgrind said, it looks to me as though the fillpage operation is writing off the end of the buffer | 17:24.45 |
| tkamppeter | Robin_Watts, what is -DMEMENTO? If I add this, the segfault goes away? | 17:25.00 |
| | s/\?$/./ | 17:25.20 |
| Robin_Watts | tkamppeter: No. Memento is a library I've written for doing simple memory checking of allocations etc. | 17:25.24 |
| henrys | chrisl:I'll look at it a bit today. | 17:25.38 |
| Robin_Watts | If you build gs with -DMEMENTO then it tracks leaks/checks for memory overwrites/can do memory squeezing/other funky things. | 17:26.07 |
| henrys | after lunch if tkamppeter doesn't solve it first. | 17:26.23 |
| chrisl | henrys: okay, thanks. FWIW, valgrind is reporting an invalid write at line 120 in gsbitops.c (bits_fill_rectangle()) during the fillpage operation. | 17:27.03 |
| tkamppeter | Robin_Watts, sorry, -DMEMENTO does not eliminate the segfault, I accidentally picked a command line without -dPARANOIDSAFER. | 17:27.18 |
| Robin_Watts | tkamppeter: -DMEMENTO is a build time option, not a runtime option. | 17:27.50 |
| tkamppeter | Robin_Watts, henrys, the strange thing is that removing -dPARANOIDSAFER or -dSAFER eliminates the segfault. | 17:27.56 |
| Robin_Watts | And if you use it, it will move memory around. | 17:28.02 |
| | tkamppeter: A side effect of that is just that things go to slightly different addresses in memory, and you get away with it by luck. | 17:28.31 |
| tkamppeter | Robin_Watts, now I see also that it has a capital "D". | 17:28.32 |
| henrys | tkamppeter:well it just shifts memory around a bit so the invalid write doesn't result in a segv | 17:28.33 |
| chrisl | Robin_Watts, henrys: memento does report some guard byte corruption, and crash (still) happens quickly, so that's a good sign....... | 17:30.50 |
| | I gotta go - I'll check back later....... | 17:33.43 |
| Robin_Watts | chrisl: Excellent news. | 17:33.50 |
| chrisl_away | hopes Robin_Watts means what I said about memento and not the fact I'm going..... ;-) | 17:34.29 |
| Robin_Watts | :) | 17:34.41 |
| | henrys: OK. I meant MEMENTO_SQUEEZEAT, not MEMENTO_FAILAT, sorry. | 17:55.26 |
| | MEMENTO_FAILAT just tries one and then stops. MEMENTO_SQUEEZEAT tries repeatedly. | 17:55.49 |
| | I have it working on peeves at the moment, with the chunk allocator joining in. | 17:56.50 |
| | The autoconf on lion is giving me warnings. | 17:59.13 |
| | warning: AC_LANG_CONFTEST: no AC+LANG_SOURCE call detected in body. | 17:59.45 |
| | henrys: OK. so if you: make debug XCFLAGS="-DMEMENTO" | 20:26.10 |
| | then you can: MEMENTO_SQUEEZEAT=1 debugbin/gs -sDEVICE=png16m -o /dev/null examples/tiger.eps | 20:26.41 |
| | That should work on macosx and linux (Ubuntu at least) out of the box now. | 20:27.14 |
| malc_ | tor8: http://pastebin.com/raw.php?i=N9MH6dW8 | 21:51.09 |
| tor8 | malc_: looks like you've compiled against one set of header and linked against another library :/ | 21:56.08 |
| malc_ | nope.. the issue is MUCH more compilcated than that.. still SEGFAULT is probably not an intended outcome | 21:56.41 |
| tor8 | well, it expects a decoding error, not a library mismatch | 21:57.33 |
| | it's a problem that jpeg_decompress_struct is allocated by the client, but cleaning it up with the wrong version library bombs | 21:58.36 |
| malc_ | i'm trying to figure things out with gcc maintainer, he's lost too.. the issue is this.. my C code is compiled with gcc 4.6.0 mupdf was built with 4.5.2.. and that's when it happens | 21:58.38 |
| tor8 | malc_: it couldn't be struct alignment mismatch? | 22:03.17 |
| malc_ | tor8: i'm affraid i don't understand the question.. | 22:03.51 |
| tor8 | different gcc versions maybe layout the struct fields differently, with different padding | 22:04.34 |
| | it'd be hard to believe, but weirder bugs in gcc have been found :) | 22:04.58 |
| malc_ | hah, yeah | 22:05.06 |
| | thing is.. mupdf.a is always compiled with the same compiler | 22:05.17 |
| tor8 | same compiler as libjpeg? | 22:05.32 |
| malc_ | furthermore, this thing only happens when particular version of _MY_ code is built with 4.6.0 | 22:05.38 |
| | yep | 22:05.42 |
| tor8 | well, that is definitely odd! | 22:05.52 |
| malc_ | tor8: btw. i've cut v5 of my insanely cool application.. it has panning support now! | 22:06.27 |
| malc_ | is so darn excited he just can | 22:06.36 |
| | 't hide it | 22:06.39 |
| tor8 | Robin_Watts: lots of feedback from zeniko today | 22:09.00 |
| malc_ | tor8: sigh.. it also depends on what file i'm opening.. this is gettng insaner every minute | 22:18.55 |
| Robin_Watts | 692377 ? | 22:47.32 |
| | tor8^ | 22:47.36 |
| tor8 | 692388 | 22:55.44 |
| | Robin_Watts^ | 22:55.49 |
| Robin_Watts | Ah, ok. | 22:56.36 |
| | colored type 3 glyphs have never worked before though. | 22:56.47 |
| | so we get it right in that they are now colored, but wrong in that they aren't rotated. | 22:57.03 |
| | Looks like I have stuff to do tomorrow :) | 22:57.51 |
| tor8 | :) | 23:02.50 |
| | I'm still banging my head on the idea of how to speed up this flood fill-based algorithm for grouping text into paragraphs. some sort of spatial search structure. have you got a link to that paper you mentioned last meeting? | 23:03.44 |
| Robin_Watts | http://www.win.tue.nl/~mdberg/Papers/prtree.pdf | 23:05.20 |
| | If that's the answer, then you'll regret having asked the question :) | 23:05.53 |
| tor8 | well, at least it can distract me for a while :) | 23:06.57 |
| | even if I decide to not use it | 23:07.04 |
| Robin_Watts | If you decide to implement it, do it as a stand alone library. | 23:07.28 |
| | cos it could be reused in several places I bet. | 23:07.42 |
| tor8 | right | 23:07.55 |
| malc_ | tor8: btw. in text branch block is what exactly? collection of lines sorted by y? | 23:10.51 |
| tor8 | malc_: contiguous chunk of lines | 23:11.36 |
| | typically a paragraph of column of text | 23:11.45 |
| | s/of/or/ | 23:11.50 |
| malc_ | but lines can all be randomly distributed along the blocks' bbox? | 23:12.44 |
| tor8 | all the lines in a block will be sorted and be contiguous | 23:14.03 |
| malc_ | aha. | 23:14.24 |
| tor8 | so no gaps, a gap will split the text into multiple blocks | 23:14.30 |
| malc_ | define gap | 23:14.42 |
| tor8 | blank line :) | 23:14.57 |
| | there are problems with the algorithm as in the text branch of now | 23:15.15 |
| | it's better than what came before, but it still has issues | 23:15.24 |
| | I've got an algorithm sitting on my hard drive that works quite well, but it's dog slow | 23:15.44 |
| | takes a second or two to sort the text for one newspaper-like page | 23:16.01 |
| malc_ | it certainly does weird things for http://www.kanji.org/cjk/arabic/arannana.pdf block ordering wise | 23:16.14 |
| tor8 | thanks for the test file :) | 23:16.48 |
| | it fails on big inter-word gaps, since it believes those are new columns :( | 23:17.08 |
| | and the blocks are sorted x-y | 23:17.19 |
| Robin_Watts | tor8: 2 new patches on casper for you. Some debug code, and a bit of tidying. | 23:18.35 |
| | will look into the bugs tomorrow. | 23:18.40 |
| | Night all. | 23:18.46 |
| malc_ | tor8: not sure what you mean by sorted x-y, first by x then by y? | 23:22.00 |
| tor8 | y | 23:22.32 |
| | it's not a final solution, but I'm still working on the getting all the characters and lines sorted into blocks correctly first | 23:23.15 |
| | Forward 1 day (to 2011/08/03)>>> | |
IRC Logs