| | <<<Back 1 day (to 2012/05/08) | 2012/05/09 |
| naveen_ | Hi Robin, Morning... | 09:58.07 |
| | I have written methods that read data from socket and copy to the char *buf to serve data to the pdf renderer....I'm getting stack corruption detected error... | 10:01.01 |
| tor8 | Robin_Watts: ah, I see you found the missing character bug with the texture space calculations! good job spotting that. | 10:07.20 |
| Robin_Watts | tor8: yeah, I cut the file down and down and ended up with a single image that wasn't appearing :) | 11:12.25 |
| henrys | chrisl was right about the memory problem and separatate allocators - was that the only issue? | 12:17.52 |
| Robin_Watts | henrys: So what time did you manage to sleep to today? | 12:18.16 |
| henrys | around 6 am getting better. | 12:23.30 |
| Robin_Watts | How was bath/the cotswolds, btw? | 12:23.52 |
| henrys | I really enjoyed it - very beautiful place. | 12:25.32 |
| | the cotswolds that is. | 12:25.37 |
| | I am something of a history buff so I really liked bath too. | 12:25.55 |
| | I'm pretty sure sabrina took pictures of every single hillside in the cotswolds ;-) | 12:26.27 |
| Robin_Watts | I'm sure we'll see them reproduced in oils soon :) | 12:26.42 |
| henrys | I did finally to running in bath - love that oxygen. | 12:27.15 |
| Robin_Watts | How badly did you get rained on? What was Stonehenge like when you visited? | 12:27.55 |
| henrys | thanks for everything you really made it a great trip for us. | 12:27.56 |
| Robin_Watts | No problem at all. Was lovely to see you. | 12:28.09 |
| henrys | I kind of like avesbury site better but yes it was fascinating. | 12:29.04 |
| | I bought Sabrina a locket for her birthday from a local artist in the cotwald's and she lost it likely at Stonehenge we have a lost and found request in but I doubt we'll recover it. | 12:30.14 |
| Robin_Watts | oh, ass. | 12:30.35 |
| henrys | she says she is expecting to get some paintings out after she cleans up after my son Hal. 19 year olds are poor choices to house sit if not obvious. | 12:31.42 |
| Robin_Watts | men are poor choices to house sit, regardless of age, I fear. | 12:32.56 |
| henrys | sure I didn't notice anything wrong as usual. | 12:33.18 |
| | hey kens was that the only memory issue or is there more - great to see that one fixed. | 12:37.29 |
| kens | hi henrys | 12:37.41 |
| | That's not the end of it | 12:37.46 |
| | I cna now get to page 244 with teh PLRM | 12:37.53 |
| | and page 40 something with the PDF reference | 12:38.01 |
| | Then I get a different seg fault | 12:38.13 |
| | There seems to be a problem with the free list in the memory manager | 12:38.27 |
| | I was about to get back to it. | 12:38.37 |
| | I didn't have time to run a Memento test before going riding this morning and -z? didn't show any problems | 12:39.04 |
| henrys | Well that's progress there is a compiler option that may show something useful but it hasn't been used in a while IGC_PTR_STABILITY_CHECK. | 12:41.01 |
| kens | Ah, I'll look into that one thanks. I may be back begging more advice later, btu I want to rerun the -Z@, -Z? and Memento tests just to be sure there isn't something there that will help me. | 12:41.44 |
| | The free list problem seems to be that the 'num_block[i]' which seems to be a count of free blocks is non-zero, but the pointer to the chain of blocks is 0x000 | 12:42.34 |
| henrys | I wish something more usefult than "poor kens" came to mind but it doesn't. | 12:46.28 |
| kens | :-) I guess its an 'opportunity' to learn more about the GS memory manager.... | 12:46.53 |
| | Its interesting that both files fail in the same way though | 12:47.20 |
| henrys | but I suspect memory is being corrupted earlier on and hopefully using the tools will find it. | 12:47.32 |
| kens | I'll comment back if I find anything more, Memento is running at the moment. | 12:47.58 |
| | I can run a couple more tests at the sme time | 12:48.17 |
| henrys | the memory leak I took from ray never should have shipped in a release it is quite obvious sigh. | 12:49.46 |
| kens | Oh, well at least you found it ? | 12:50.02 |
| | BTW I assume you are still jet-lagged henrys, hence the early start | 12:50.37 |
| henrys | I feel fine - just awake. | 12:51.17 |
| Robin_Watts | feels he probably ought to have lunch despite the chapter in the PDF spec on linearized pdf having killed his appetite. | 12:54.31 |
| henrys | I am beginning to favor some sort of code review as Robin_Watts suggested but I certainly don't want to do it if everyone isn't okay with it. | 12:57.23 |
| | I think we would have caught this one. | 12:57.42 |
| Robin_Watts | Having it there as an option is a good thing. | 12:57.54 |
| | At picsel we had a workflow where we pushed the patch to the review system, cluster tested it from there, and then someone else reviewed it - which caused the commit. | 12:58.42 |
| | It solved the problem of "oops, I've committed the wrong thing", and it meant that at least 1 other person had at least a superficial look through the code. | 12:59.22 |
| | I was dead set against it when it was introduced, but really miss it now. | 12:59.48 |
| | We can kind of achieve the same thing now by us having our own repos on casper. | 13:00.37 |
| kens | Hmm, running the PLRM with -Z? causes GS to close without a seg fault, I wonder what I'm doign wrong.... | 13:01.14 |
| Robin_Watts | Push commits to that, test them, and then get someone else to look over them before pushing them on to the central repo. | 13:01.17 |
| | but it's not as automated. | 13:01.27 |
| kens | Ah, reference to free object error. | 13:02.03 |
| tor8 | henrys: I (and sebras) are in favor of having a code review system for mupdf. automated or not, I think we can at least start with a staging area branch where commits go until they have been okayed by someone other than the author. | 13:02.11 |
| kens | I guess that's where I go to look next | 13:02.18 |
| tor8 | Robin_Watts: how about a branch where we can push to, but someone *else* has to take that commit and push it to master so we're not allowed to push our own commits to master? | 13:02.41 |
| kens | I'm not in favour, for all the reasons already covered. | 13:02.56 |
| Robin_Watts | tor8: That sounds reasonable. | 13:02.57 |
| tor8 | I'd really like to see something like gerrit, but that's probably more trouble to set up than it's worth | 13:03.53 |
| Robin_Watts | but it means that people have to be consiencious about doing reviews. | 13:03.56 |
| | Is Gerrit like ReviewBoard ? | 13:04.06 |
| tor8 | Robin_Watts: yeah. but if the waiting-for-review branch is publicly available, we could close bugs at least | 13:04.33 |
| | Robin_Watts: I haven't used reviewboard | 13:04.53 |
| Robin_Watts | tor8: We should never close bugs until the patches are pushed to the public repo. | 13:04.56 |
| | Gerrit sounds interesting. | 13:05.01 |
| | The fact it's git based is a good thing. | 13:05.12 |
| sebras | Robin_Watts: gerrit is better than reviewboard. | 13:05.13 |
| | Robin_Watts: we use reviewboard at work and I must say that gerrit works better as a reviewtool. | 13:05.43 |
| | Robin_Watts: basically what you get in gerrit is a staging area for patches. depending on how gerrit is configured people can review the patch and comment on a line-by-line basis. | 13:06.40 |
| Robin_Watts | sebras: OK. I don't know ReviewBoard well enough to comment. When I last looked at this it was the obvious thing, but I'm quite prepared to believe Gerrit is a better bet now. | 13:07.36 |
| sebras | Robin_Watts: once the patch is approved you can click submit which means that the patch is actually applied on the branch it was pushed towards. | 13:07.49 |
| | Robin_Watts: at this point the author may need to rebase his patch (as the intended destination branch may have had other patches merged). | 13:08.38 |
| tor8 | Robin_Watts: http://code.google.com/p/rietveld/ is the other one I know of, but that one is tied to mercurial and google app engine so not at all good for us | 13:08.58 |
| sebras | Robin_Watts: as I understand reviewboard it is normally not tied to merging a patch once it has been reviewed/approved. | 13:09.29 |
| | Robin_Watts: https://android-review.googlesource.com here you can have a look at gerrit. | 13:10.29 |
| Robin_Watts | I'm sold on using gerrit rather than reviewboard. Looking at the docs now. | 13:10.42 |
| | So, we could hook the cluster into the 'Verifying' stage, maybe. | 13:13.01 |
| sebras | there is one drawback with gerrit -- in every commit message you must have a line mentioning a change-id as gerrit indexes its patches using this rather than sha1s (since you may want to upload a new fixed patch (with a new sha1) to fix your review comments but both relate to the same review). | 13:13.06 |
| tor8 | sebras: ugh. | 13:14.22 |
| Robin_Watts | Hmm. Can't we have git commit add a "Change-Id: hash" to every commit where there isn't one already? | 13:15.04 |
| | That way when you "git commit --amend" the change-id wouldn't change. | 13:15.20 |
| | and so uploading a new patch would work fine ? | 13:15.33 |
| | Do we need to move our repo from git to gerrit? Or can gerrit just wrap the normal git repo ? | 13:18.11 |
| sebras | Robin_Watts: as I remember it I never put a change id in there when I pushed a patch for the first time. | 13:18.20 |
| Robin_Watts | sebras: Right, but then you need to add it back when you prepare your updated version, right ? | 13:19.02 |
| sebras | Robin_Watts: yes, but then you probably do git pull or git fetch to get that updated one... hm... my memory is hazy about the details here. :-/ | 13:19.33 |
| Robin_Watts | Oh, god, it's written in java. | 13:20.25 |
| sebras | I seem to recall that the change id appeared automagically when you pushed and then you probably did git add ...; git commit --amend; git push when you uploaded the fixed patch. | 13:20.38 |
| | it is? oh.. I didn't know. :) | 13:20.54 |
| Robin_Watts | sebras: Well, if that's true (the change id) then it's doing what I wanted anyway :) | 13:21.19 |
| tor8 | kens: any thoughts on bug 693031? | 13:21.34 |
| Robin_Watts | The main thing is that I can just git commit --amend and repush. | 13:21.37 |
| | but I do need to have lunch. bbs. | 13:21.49 |
| sebras | tor8 Robin_Watts: but yeah, to be honest I think just asking people to review patches sitting on your personal git repo on casper catches most problem and requires no new infrastructure. ;) | 13:23.26 |
| kens | tor8 I'll look, I don't recall it | 13:23.46 |
| | ah, I meant to have a go at that tor8 | 13:24.13 |
| | most likely problem would be transparency | 13:24.23 |
| | rendering at 720 dpi takes time | 13:24.30 |
| | tor8 do you have a copy of the test file for that bug ? | 13:26.47 |
| | I don't think I have the MS XPS docs | 13:27.01 |
| tor8 | kens: not sure which xps docs he is referring to | 13:27.27 |
| kens | Oh, tehn I gues we need him to be specific | 13:27.47 |
| | You want to request teh file in teh bug thread ? | 13:28.07 |
| tor8 | but it could be the spec (or any file really) | 13:28.09 |
| kens | We test xps with ps2write don't we ? | 13:28.30 |
| tor8 | I don't know :) | 13:30.10 |
| | kens: I tried running one of the sample files and the text comes out all garbled | 13:34.09 |
| kens | That's not the bug report though | 13:34.30 |
| tor8 | except when it's fallen back to rendered bitmaps | 13:34.31 |
| kens | well feel free to make a new report on that one for me | 13:34.57 |
| tor8 | it's similar to his last sentence in the original report | 13:35.15 |
| | no output after 3 hours is probably just because it's dog slow and ps2write doesn't output anything until it's all done | 13:35.33 |
| | and having all or most of the pages dumped as bitmaps due to the transparency would do that | 13:35.53 |
| kens | Hmm. OK well in that case attach a file that shows the problem you do see, and assign it to me with a comment to that effect. | 13:36.17 |
| | I suppose I may even work on it one day | 13:36.27 |
| | Is this a customer ? | 13:36.35 |
| tor8 | no idea about customer. attached sample file which shows both issues (turning into bitmap, and garbage text) | 13:41.57 |
| | kens^ | 13:42.17 |
| kens | thanks tor8 | 13:42.28 |
| | Chasing memory problems today | 13:42.40 |
| tor8 | shall I reassign it to you? | 13:42.54 |
| | I think we can just close the first bit as 'yeah, what do you expect, it's got transparency' but the second one is more worrying. | 13:43.19 |
| | alternatively disable the device for xps? | 13:43.26 |
| | since you won't get anything reasonable out of it | 13:43.37 |
| kens | tor8 yes assign it to me | 13:43.52 |
| | if pdfwrite works then ps2write should (modulo transparency) | 13:44.14 |
| tor8 | right. reassigned. | 13:44.36 |
| kens | OK thanks | 13:44.40 |
| | Like I said, I may look at it one day | 13:44.48 |
| Robin_Watts | tor8: pdfwrite.c line 612 | 14:06.47 |
| | /* Do not renumber objects if encryption is in use, as the object | 14:06.56 |
| | * numbers are baked into the streams/strings, and we can't currently | 14:06.58 |
| | * cope with moving them. See bug 692627. */ | 14:07.00 |
| | I don't believe that bug number. | 14:07.03 |
| | henrys: bug 693001. | 14:13.05 |
| | We could do an overnight test run of files with memento, to track the leaks, and spot whether total number/size of leaks get bigger/smaller after each commit. | 14:13.43 |
| | (or each day, rather) | 14:13.52 |
| | To avoid memento taking ages, we can use MEMENTO_LEAKONLY which tells it not to do the paranoid checking, and makes it MUCH faster. | 14:14.20 |
| | sebras: Was removeduplicateobjs yours ? | 15:06.27 |
| | lines 107: match = (pdf_is_stream(xref, num, 0) || pdf_is_stream(xref, other, 0)); | 15:06.53 |
| | so match = 1 if either thing is a stream. and a bit later: if (match) continue; | 15:07.23 |
| | i.e. if either thing is a stream, then we can't say that they match. | 15:07.38 |
| | so "match" is really "differ". | 15:08.01 |
| | And the fz_catch(ctx) that says "/* Assume different */ match = 0;" should really be match = 1 ? | 15:08.37 |
| henrys | Robin_Watts:I thought we were running with a reasonable -K which should have caused failures ... this is a big leak. | 15:22.42 |
| Robin_Watts | -K1000000 ? | 15:24.10 |
| | So 1Gig ? | 15:24.28 |
| henrys | I think that is very high at least for pcl, I'll talk to marcosw | 15:28.26 |
| Robin_Watts | I don't think an overnight test for leaks is unreasonable. | 15:29.44 |
| | We can't expect to introduce such a test and have us come up with no leaks, but we can reasonably expect to track what leaks we have and make sure we don't significantly increase in any given commit. | 15:30.21 |
| henrys | I agree with that too, and I guess that would not necessitate changing the -K value. | 15:30.32 |
| Robin_Watts | (or on any given day, at least) | 15:30.37 |
| henrys | memento is slow though you can't do everyting, which jobs? | 15:31.32 |
| | it also requires a debug build if you want the client name stuff yes? | 15:32.24 |
| chrisl | henrys, Robin_Watts: Ray talked about adding an option to track and dump maximum use numbers - should be possible with sufficiently low impact, normal cluster runs could use it. | 15:35.58 |
| henrys | -Z: seems to be broken with PCL and I haven't bothered to fix it but I imagine it is trivially fixed. | 15:37.14 |
| | I assume that is what you mean using? | 15:37.28 |
| chrisl | Erm, I thought not, because that also needs a debug build. | 15:38.45 |
| henrys | no I thought -Z: was handled in regular builds | 15:40.13 |
| chrisl | I had the impression it was to add an accumulator the the lowest level allocator, and print out the result | 15:41.11 |
| henrys | It seems like what robin_watts said is best though - that way we just get a warning that says the "client_name" leaked and didn't before, that's easy for us. | 15:41.16 |
| | what's easy for us is hard for marcosw ;-) | 15:42.52 |
| | chrisl we could also use the time max resident number as you do often. | 15:50.51 |
| Robin_Watts | henrys: That would watch for peak usage, rather than leaks, right ? | 15:51.40 |
| chrisl | henrys: it doesn't work, it's been broken for some time :-( | 15:51.59 |
| Robin_Watts | Memento gives us peak usage too, FWIW. | 15:52.14 |
| chrisl | Robin_Watts: the only thing is, I'd prefer a test that didn't require a special build | 15:53.12 |
| Robin_Watts | chrisl: right, I understand that - and if we can get it, great. | 15:53.44 |
| henrys | and Memento can't test all the files like an accumulator could. | 15:53.45 |
| Robin_Watts | Why not ? | 15:53.52 |
| | Using the MEMENTO_LEAKCHECKONLY (or whatever it is) flag means Memento runs don't take much longer than normal ones. | 15:54.49 |
| | (and I can fix it if they do) | 15:55.09 |
| henrys | oh okay I didn't know about that. | 15:55.10 |
| Robin_Watts | But having the ability to track peak memory and leaked memory in a normal build certainly shouldn't be impossible, and does have it's attractions, yes. | 15:56.24 |
| chrisl | I'm not sure about leaked memory being tracked in a regular build | 16:00.03 |
| henrys | if the MEMENTO_LEAKCHECKONLY is fast I really like a script to be run each night and we get a diff email. | 16:01.25 |
| Robin_Watts | chrisl: You need an accumulator for "how much memory have I got allocated", right ? | 16:01.32 |
| | So atexit that accumulator = how much has been leaked. | 16:02.10 |
| | henrys: If it isn't fast enough, I can make it so (it may still do filling of blocks with special values). | 16:03.16 |
| chrisl | Robin_Watts: Yeh, I was thinking about tracking "leaks", rather than just a single number | 16:03.17 |
| Robin_Watts | chrisl: For that there would be an overhead - and we'd be better off with the special memento run, IMHO. | 16:03.39 |
| chrisl | Robin_Watts: in truth, I'm more interested in peak memory use - a significant increase in peak memory use is a good hint that *something* needs looked at | 16:04.40 |
| henrys | chrisl:that's just a couple lines of code where the -K variable is updated | 16:05.21 |
| ray_laptop | henrys: so the removal of the gs_imager_state_release in gstate_free_contents is probably the source of the leak, | 16:07.16 |
| chrisl | henrys: the thing is, I've seen a couple of occasions where a change I made caused a *big* (and pointless) increase in memory use, but wasn't a leak. I'd prefer feedback on that kind of thing fairly quickly | 16:07.51 |
| ray_laptop | and, it's been long enough that I don't recall why that line was removed | 16:07.53 |
| sebras | Robin_Watts: eh... I need to look at the code to sort that out. | 16:07.54 |
| henrys | ray_laptop:yes definitely. | 16:08.37 |
| | mvrhel, ray_laptop:it seems we do need a closer look at the memory management of the device profile related stuff. | 16:10.34 |
| Robin_Watts | sebras: I'm playing in that area now. | 16:11.18 |
| | sebras: I just wanted to confirm with you that it looked wrong. | 16:11.28 |
| henrys | mvrhel we are talking about 693001 | 16:11.28 |
| mvrhel | ok | 16:11.32 |
| | so the device profile should live for the life of the device | 16:12.52 |
| sebras | Robin_Watts: ok. there are known problems with mupdfclean -dggg (but it works with -dgg) that I think may be triggered by something in that area. I have never nailed it down though. | 16:13.38 |
| mvrhel | is anyone able to open comparefiles/Testform.v1.0.2.pdf with Acrobat? | 16:15.21 |
| ray_laptop | henrys: the problem I was seeing was not with the device profile stuff, but with many other elements of the graphics state that are supposed to be reference counted that were not correctly maintained. Their ref counts were screwy | 16:15.39 |
| henrys | yes the caches and manager. | 16:17.00 |
| ray_laptop | mvrhel: I get "Invalid Colorspace" with Acrobat 9 | 16:17.00 |
| | mvrhel: it looks like the 'lop_planar' stuff in gsropt.h is defined but never used. Is this something that you or Robin_Watts put in, then decided not to use ? | 16:18.43 |
| henrys | ray_laptop:it isn't clear why your changes to decrement the rc of those resources would require removing the procedure to release the imager state. | 16:19.10 |
| Robin_Watts | ray_laptop: Urm... let me check. | 16:19.21 |
| | ray_laptop: Right. That was required when I was doing copy_plane, but when I finally twigged that was impossible and changed to doing copy_planes, it became unnecessary, I think. | 16:20.27 |
| | I should remove it. | 16:20.31 |
| ray_laptop | henrys: the problem is that imager_state_release decrements the rc's and we don't want to do that twice (i.e. in the finalize) | 16:20.34 |
| kens | mvrhel acrobat 10 also gives incvlaid colorspace | 16:20.41 |
| ray_laptop | henrys: but my change to set the 'pis->element = NULL' in the RCDECR macro _should_ prevent that -- if the imager state contents has been released, the pointers will be NULL, so won't be decremented a second time if the imager_state_finalize is subsequently called. | 16:22.14 |
| henrys | ray_laptop, mvrhel:why is your new finalize needed at all, why can't these things be handled like everything else - joint caches etc.? | 16:22.30 |
| ray_laptop | henrys: the problem was that there was an imager state being freed by the final 'alloc_restore_all' and it didn't do the 'free_contents' or imager_state_release and left the icc_ stuff (which had semaphores) dangling | 16:23.51 |
| | thinking about it, we could instead add finalization to the icc structures that have semaphores so they can free the semaphore when the icc struct is freed. | 16:24.56 |
| | henrys: but since the semaphore usage only shows up on windows, testing it needs windows (with some extra downloaded utils) | 16:26.12 |
| | (or adding debug counters to the gp_semaphore_open and gp_semaphore_close | 16:28.02 |
| henrys | leaving that all aside the code screws up the basic reference counting model of the graphics state - I don't see anyway these values can be decremented properely withouth the gs_imager_state_release(), so can we pull this out open the old bug and start again? | 16:28.25 |
| ray_laptop | henrys: I agree that we should revert that change and instead add the finalization to the icc structs | 16:29.12 |
| | henrys: do you want to do that or should I. I can (probably) do it pretty quickly (since I am already thinking about it) | 16:29.55 |
| henrys | no go ahead. | 16:30.19 |
| ray_laptop | henrys: OK -- I'll assign the bug back to me. | 16:30.55 |
| kens | Time for me to go, goodnight all | 16:31.01 |
| henrys | ray_laptop:I didn't change it. | 16:31.06 |
| ray_laptop | nite, kens | 16:31.09 |
| | henrys: Oh, OK. | 16:31.18 |
| mvrhel | ok. I am back. stepped out for a minute sorry | 16:31.26 |
| henrys | Robin_Watts:I think we really only need to run the memento stuff on PCL and maybe XPS - I don't think with GC you are going to get any results but I haven't looked. | 16:31.31 |
| Robin_Watts | Not everything is in gc able memory. | 16:33.13 |
| | so we can still get leaks. | 16:33.19 |
| henrys | fair enough | 16:33.39 |
| | do you want me to request this marcosw or would you like to. | 16:33.55 |
| | ? | 16:33.56 |
| Robin_Watts | When I first came to an Artifex staff meeting we had an agenda item about garbage collection, and we decided that we'd do our best to minimise what was put into gcable memory. | 16:34.01 |
| | I'll talk to marcosw if you want. | 16:34.37 |
| henrys | thanks. | 16:34.43 |
| ray_laptop | Robin_Watts: (or anyone else). I am getting a problem when I try and switch branches (to or from master): | 16:38.46 |
| | error: The following untracked working tree files would be overwritten by checkout: | 16:38.48 |
| | gs/jbig2dec/libtool | 16:38.49 |
| | gs/jbig2dec/stamp-h1 | 16:38.51 |
| | Please move or remove them before you can switch branches. | 16:38.52 |
| | Aborting | 16:38.54 |
| | could not detach HEAD | 16:38.55 |
| | I have to rm -f jbig2dec ; git reset --hard master | 16:39.28 |
| Robin_Watts | Right, so you have some files that are included in the branch you are going to, but not in the one you are in. | 16:39.32 |
| ray_laptop | before I can do a pull with rebase | 16:39.45 |
| Robin_Watts | ray_laptop: That will throw away all your changes, and make whatever branch you are currently on point to master. | 16:40.36 |
| ray_laptop | Robin_Watts: the branch rebases on the master, and git diff of the branch only shows the file I actually modified | 16:40.50 |
| Robin_Watts | ray_laptop: So, you've done the above, and you're now on master, right? | 16:41.30 |
| | and now you want to swap back to your branch? and you're getting the error ? | 16:41.51 |
| ray_laptop | Robin_Watts: i only do the "git reset --hard master" when I am on the master branch | 16:41.52 |
| Robin_Watts | Right. So where exactly are you now, and what's the problem you are seeing? | 16:42.21 |
| ray_laptop | Robin_Watts: I got that error after I switched from my branch to master, and tried to "git up" | 16:42.26 |
| Robin_Watts | Right, so the problem isn't when you switch branches then ? | 16:42.55 |
| | The problem is on a "git up" ? | 16:43.43 |
| ray_laptop | Robin_Watts: let me try switching branches ... | 16:44.09 |
| chrisl | ray_laptop: sorry, that was my fault when I merged the jbig2dec code - you can delete those files (I've removed them from master already) | 16:45.08 |
| ray_laptop | Robin_Watts: problem doesn't happen now -- I switched to the branch, did the git up, then swtiched back and git up just says 'up to date' | 16:45.33 |
| Robin_Watts | ray_laptop: Right. As chrisl says, the problem was he checked those files in by accident, so when you try to pull, it was trying to bring in new copies of them. | 16:46.08 |
| ray_laptop | chrisl: OK. might have been that I had old files laying around in the branch and they came back. | 16:46.26 |
| chrisl | ray_laptop: so depending on when you created/update your branch, you might want to update it now, so those files don't appear in your repos | 16:47.16 |
| ray_laptop | I worry when git starts throwing errors that seem unrelated to anything I did | 16:47.22 |
| Robin_Watts | Yeah, rebase your branch onto master post 0ee6bd4 and you'll be fine. | 16:47.44 |
| ray_laptop | chrisl: right. | 16:47.46 |
| | while I have already distracted you, is there an easy way to revert a patch ? | 16:48.55 |
| Robin_Watts | ray_laptop: To revert a previous git commit? | 16:49.13 |
| ray_laptop | other than doing the diff backwards and applying i as a patch ? | 16:49.26 |
| Robin_Watts | You want a 'reverse cherry-pick', right? | 16:49.33 |
| | git revert <hash> | 16:49.53 |
| | That will add a new commit in that reverses the old one. | 16:50.04 |
| ray_laptop | Robin_Watts: yes, specifically fe8d7b | 16:50.27 |
| | Robin_Watts: OK. here goes ... | 16:50.43 |
| Robin_Watts | Well, either it worked, or ray_laptops laptop exploded again. | 17:12.46 |
| mvrhel | hehe | 17:15.06 |
| ray_laptop | hates it when the gsstruct.h is missing the particular variant I need (basic list of pointers, but with finaliation) | 17:33.57 |
| Robin_Watts | add more macros! | 17:34.50 |
| ray_laptop | I always struggle with just adding the ones I need vs. "doing the right thing" and adding all the N (in this case 7) variants | 17:35.10 |
| Robin_Watts | is not sure that adding to macro hell can ever be classed as "doing the right thing" | 17:35.40 |
| ray_laptop | Peter must have done this set of macros after reading Dante's Inferno (there are at least 9 levels of "underworld") | 17:36.06 |
| | oh my, there are 'basic' structure macros for up to 11 pointers !!!! | 18:03.41 |
| | of course, no use for beyond 7 :-( | 18:05.22 |
| | Peter probably wrote an emacs script to populate them | 18:05.54 |
| | (I did a vim "map" sequence to add the _final cases) | 18:06.25 |
| Robin_Watts | C-x ( blah blah blah RET C-x ) C-u 1 1 C-x e | 18:06.47 |
| ray_laptop | if I need anything more than I can easily do with vim 'map' I just do it in awk | 18:08.39 |
| | can't believe it. I managed to change the macros correctly the first time. :-) | 18:11.11 |
| Robin_Watts | At that point, I check I'm building the right source tree :) | 18:11.35 |
| | Hey marcosw, got a few minutes to talk ? | 18:15.08 |
| marcosw | I just got in, so yes. | 18:15.17 |
| Robin_Watts | Henrys was suggesting earlier that we need some automated way of spotting when leaks are introduced to the code. | 18:15.43 |
| marcosw | make sense, I see from the irc history that MEMENTO_LEAKONLY is the answer. | 18:16.24 |
| Robin_Watts | I suggested that we have an overnight task that runs a modified memento build on every file, and collects the memento output... | 18:16.38 |
| | yeah :) | 18:16.43 |
| | I suspect some cunning grepping of the memento output is required (to ignore the addresses) | 18:17.37 |
| | and the block numbers. | 18:17.43 |
| marcosw | Clearly I'll need to write some perl code :-) (If your only tool is a hammer, every problem looks like a nail). | 18:18.45 |
| Robin_Watts | but then we can spot when there are changes in the number/size/makeup of the leaked blocks and give informative reports. | 18:18.59 |
| marcosw | instead of make memento I define MEMENTO_LEAKONLY as part of XCFLAGS (or whatever it's called)? | 18:19.16 |
| Robin_Watts | You define both MEMENTO and MEMENTO_LEAKONLY. | 18:19.48 |
| | (actually, I'll need to tweak the source a bit, cos currently there is a #undef MEMENTO_LEAKONLY at the top of memento.c) | 18:20.11 |
| marcosw | sounds easy enough. Something for me to work on during the flight tomorrow (I'm on one of the new cabin United 777s, which have 110v in coach). | 18:21.19 |
| Robin_Watts | Ah, I flew that configuration on Jet to Delhi, I think. | 18:21.46 |
| marcosw | I was on one from SFO->LHR last week, they in flight entertainment is much nicer, 50 movies and a bunch of television shows. | 18:22.33 |
| Robin_Watts | Virgin have had that for ages. It's one of the reasons we fly virgin. | 18:22.58 |
| | I'd defect to another airline for that + seatback power though. | 18:23.31 |
| | Who did you fly SFO -> LHR with ? | 18:23.55 |
| mvrhel | I had the pile of movies + 110V + USB power on my flights | 18:24.08 |
| | on air canada from vancouver to LHR | 18:24.29 |
| ray_laptop | the Air New Zealand had all of that as well (a 777-300E) | 18:24.53 |
| Robin_Watts | aircanada don't fly direct SFO->LHR though. | 18:25.38 |
| | ray_laptop made Air New Zealand sound very tempting. | 18:25.55 |
| mvrhel | thats not a problem for me | 18:25.57 |
| ray_laptop | OK, I've changed the code to do the finalize for the icc structs that have monitor and/or semaphore. Now to test it ... | 18:28.23 |
| | first a lunch break and run a quick errand. | 18:29.05 |
| | bbiaw | 18:29.08 |
| marcosw | I flew on United. The I have platinum status with them, which gets me free domestic upgrades and lounge access when traveling internationally. United is by far the major carrier out of SFO. And they partner with Lufthansa, so if I'm flying to Germany I can connect to any city for the same cost as flying to Frankfurt. | 18:29.09 |
| | so what changed with the git repository in the last few days? I keep getting: Cannot pull with rebase: You have unstaged changes. | 18:29.52 |
| | with these files listed as having been modified: | 18:29.59 |
| | #modified: gs/jbig2dec/config.h | 18:30.05 |
| | #modified: gs/jbig2dec/libtool | 18:30.05 |
| mvrhel | I was getting that issue too | 18:30.23 |
| Robin_Watts | marcosw: remove gs/jbig2dec | 18:30.31 |
| | then git checkout gs/jbig2dec | 18:30.41 |
| | then pull, and you shouldn't have the problem again. | 18:30.51 |
| | chrisl accidentally checked in some files he shouldn't have, but they've gone again in the latest version. | 18:31.14 |
| marcosw | that seems to have worked, thx. | 18:32.00 |
| | I wonder what happened to i7 and x6. They are both at my house but so is inches; if the cable modem fell over or there was a power issue all three should be affected. | 18:34.24 |
| Robin_Watts | tor8, sebras: ping | 18:37.04 |
| | tor8, sebras: I've pushed a change to my casper repo for your consideration. It lifts the restriction on us being able to renumber encrypted objects when writing a file. | 18:38.01 |
| | We need to be able to renumber at will or we'll never be able to write linear pdf. | 18:38.33 |
| sebras | Robin_Watts: cool. I'll have a look shortly. | 19:09.11 |
| henrys | marcosw:I think it suffices to awk/perl away everything except the client name column and send out the diff of that - if there is a diff. | 19:20.19 |
| marcosw | henrys: okay. I'll have something running in the next day or two. The obvious question, do I want to enter bug(s) for all the memory leaks that are currently in the code? | 19:21.30 |
| henrys | perhaps semantics but to me a leak is not just something left behind but caauses growth. | 19:24.39 |
| | the latter (to me) is a bug. | 19:24.54 |
| | marcosw:are you going to run everything as one job? | 19:32.13 |
| sebras | Robin_Watts: yes, you're right about match = pdf_is_stream() stuff is incorrect. | 19:32.26 |
| henrys | I think that will catch more stuff. | 19:33.03 |
| sebras | Robin_Watts: ah, now I see what you are doing, basically you are retaining the original num/gen and feed that to the filters when decrypting stream data. | 20:22.38 |
| | Robin_Watts: looks ok to me. | 20:24.29 |
| | Robin_Watts: btw, you have a patch waiting on sebras/master. | 20:46.56 |
| Robin_Watts | sebras: Thanks. I'll review that tomorrow, sorry for not having done it before. | 22:42.12 |
| | Forward 1 day (to 2012/05/10)>>> | |
IRC Logs