| | <<<Back 1 day (to 2012/07/11) | 2012/07/12 |
| saper | which git repository contains ghostscript's base/ ? | 10:25.27 |
| | ah, gs/base in ghostpcl... sorry | 10:26.02 |
| Robin_Watts | saper: ghostpcl? No. | 10:38.10 |
| | You want to be looking at gs/base in ghostpdl.git | 10:38.25 |
| | tor8: ping? | 12:47.21 |
| tor8 | Robin_Watts: hi | 12:47.38 |
| Robin_Watts | Have you been following the emails between me and Christophe? | 12:47.55 |
| tor8 | is this the display list bug you mentioned the other week? | 12:50.13 |
| Robin_Watts | the other week, no. | 12:51.02 |
| | These emails came in last night. | 12:51.12 |
| | As far as I can see, there are 2 issues. | 12:51.41 |
| tor8 | the "invalid" rect [-1 -1 1 1] is our way to indicate "infinite rect" | 12:52.00 |
| Robin_Watts | Ah, ok. | 12:52.15 |
| tor8 | so union rect with [-1 -1 1 1] will return the infinite rect, as expected | 12:52.20 |
| | I haven't looked at the sample file yet, but is it possible that the shading uses the Extends thing? | 12:52.38 |
| Robin_Watts | (sorry, phone) | 12:55.37 |
| tor8 | yeah, I don't see any problem with the bbox given this input. it has /Extend [ true true ] on the shadings, so they are infinite in size | 12:56.22 |
| | we only pass the bbox to pdf_show_pattern for the tiling machinery to stamp out the right number of tiles | 12:57.24 |
| | the shading code draws triangles and looks at the scissor, so doesn't care about the bounding box | 12:57.48 |
| Robin_Watts | The problem that he was reporting, AIUI, was that the display list node gets an infinite rectangle. | 12:58.51 |
| tor8 | right. because everything else works as expected as far as I can tell | 12:59.28 |
| Robin_Watts | When in fact, the node should have a rectangle clipped by the path. | 12:59.42 |
| tor8 | the shade drawing code intersects the infinite rectangle with the scissor, so does not do excessive work there | 12:59.54 |
| Robin_Watts | and that's because we first push a clip group, then draw the shading, then pops the clip group. | 13:00.10 |
| | so the 'draw the shading' node, ends up with an infinite rectangle. | 13:00.22 |
| tor8 | right. we ought to keep track of the scissored/intersected bboxes from the clipping stack when inserting display list nodes. I guess this goes for all nodes, not just shading ones, but the shading ones are I think the only ones that can be infinitely sized (due to the extends thing) | 13:00.57 |
| Robin_Watts | One possibility would be to be to have the list writer keep a list of the clipped... yes, what you just said. | 13:01.08 |
| | Ok. I'll send him a message back explaining the infinite bbox thing after lunch. | 13:01.34 |
| | Thanks. | 13:01.38 |
| tor8 | the draw device intersects the infinite rectangle with the scissor region, but that misses out the opportunity to elide the whole thing early if it's outside the scissor region | 13:01.52 |
| | which we should be able to do with the display list | 13:02.06 |
| henrys | at some point the time to run the cluster has doubled and marcosw cluster time changes have been reverted. | 14:19.32 |
| kens | I htought the cluster was taking a long time | 14:20.08 |
| Robin_Watts | henrys: he said he made some changes yesterday, but... | 14:20.30 |
| | Looks like he's added an extra directory to the xps stuf. | 14:21.21 |
| | stuff. | 14:21.23 |
| henrys | glad it isn't a performance regression | 14:23.17 |
| Robin_Watts | The total time stuff should still be there. | 14:23.31 |
| | what exact job are you running ? | 14:23.44 |
| henrys | I'm lookin at the recent emails. | 14:24.01 |
| Robin_Watts | The ones for git commits? | 14:24.11 |
| henrys | oh I see the time stuff is at the bottom of this nvm. | 14:24.49 |
| Robin_Watts | It looks to me like some xps files might now be being tested twice. | 14:25.13 |
| henrys | looking at the openjpeg patch - 55 min. | 14:26.11 |
| kens | Its taking a very long time | 14:26.34 |
| Robin_Watts | the slowdown was alexcher's patch to move the gc_signal | 14:28.09 |
| | From 32 mins to 78mins. | 14:28.17 |
| kens | Not good | 14:28.29 |
| | Too much gc ? | 14:28.48 |
| Robin_Watts | We should revert the patch, I guess? | 14:29.56 |
| kens | I =would think so | 14:30.20 |
| | can't have a doubling of time | 14:30.28 |
| henrys | alexcher:are you about? | 14:30.37 |
| kens | halving of performance | 14:30.42 |
| henrys | certainly needs to come out. | 14:30.57 |
| Robin_Watts | If people want me to revert the patch, just say. | 14:31.07 |
| | Last night, I had the interpolation stuff veguely behaving. | 14:32.06 |
| | Then windows rebooted with updates overnight, I've rebuilt... and it's now now drawing anything. | 14:32.24 |
| henrys | Robin_Watts:I guess give alexcher 5 minutes or so then revert. | 14:32.25 |
| | well marcosw1 timing figures make the performance drop obvious now we just have to read it ;-) | 14:39.03 |
| kens | Its certainly useful | 14:39.37 |
| | THough there is a lot of volatility in the numbers | 14:39.57 |
| Robin_Watts | D'Oh. Forgot -dNOTRANSPARENCY | 14:43.42 |
| henrys | nothing obvious in his patch, it could be correct and we have some killer slow CET gc tests that are now working. | 14:47.46 |
| Robin_Watts | His patch is directly to do with the counters that say "do a gc every n ticks". | 14:48.23 |
| | If we're now doing gc's more often, that would explain the slowdown. | 14:48.39 |
| kens | Yes, gc is very expensive | 14:48.51 |
| Robin_Watts | I have just pushed the reverted patch. | 14:49.30 |
| kens | THanks. | 14:49.54 |
| | Having the cluster take > 1 hour would make it much less useful to me | 14:50.06 |
| henrys | okay | 14:50.07 |
| Robin_Watts | henrys: "nothing obvious in his patch, it could be correct and we have some killer slow CET gc tests that are now working." - it's just dawned on me, this can't be the case. | 15:03.20 |
| ray_laptop | Robin_Watts: did you put a bp counter on the GC (to confirm that it's doing it more often) ? | 15:03.33 |
| Robin_Watts | cos those tests would just time out, and the overall runtime would only be slightly increased. | 15:03.44 |
| | ray_laptop: No, I just backed it out. | 15:03.51 |
| ray_laptop | Robin_Watts: that makes sense. It is more likely that EVERY test is running longer | 15:04.13 |
| henrys | Robin_Watts:good point | 15:04.35 |
| ray_laptop | at least those that run long enough to trigger automatic GC's (some don't). | 15:04.51 |
| Robin_Watts | I have a less invasive change than alexcher's I think - just testing it now. I may be barking up the wrong tree though.... | 15:07.17 |
| ray_laptop | Robin_Watts: what's the approach you are trying ? | 15:08.15 |
| Robin_Watts | Rather than every mem space having a pointer to the same int, I just have a single pointer to an int in the lib_ctx. | 15:08.53 |
| chrisl | ray_laptop: do you have any thoughts on how we can end up with stale pointers in the memory spaces? It seems like that shouldn't be possible, to me..... | 15:10.01 |
| Robin_Watts | Hmm. I get an /invalidaccess in /startjob error when I try to run 34_all.PS | 15:11.30 |
| | Is there some special incantation needed for this job ? | 15:11.42 |
| chrisl | Yes, it needs a server loop | 15:11.51 |
| ray_laptop | chrisl: I wasn't following this bug | 15:12.07 |
| Robin_Watts | chrisl: Why don't you assume I'm a complete muppet and tell me what that means? :) | 15:12.22 |
| kens | Tricky to explain | 15:12.34 |
| ray_laptop | Robin_Watts: you probably need to run -dJOBSERVER - < 34_all.ps | 15:12.37 |
| | i.e. pipe from stdin | 15:12.46 |
| Robin_Watts | ray_laptop: Gotcha, thanks. | 15:12.50 |
| chrisl | Ah, thanks ray_laptop that's the option I was searching for...... | 15:13.10 |
| Robin_Watts | ok, well, no SEGV. | 15:13.11 |
| ray_laptop | some of the CET's set things outside the server loop and expect them to remain after the end of job restore | 15:13.41 |
| kens | Robin_Watts : it only used to SEG on the macpro | 15:14.43 |
| Robin_Watts | I'll tidy the patch up a bit, and put it somewhere you call all look at it. | 15:15.20 |
| ray_laptop | kens: oh, great. Which bug was this ? I'd like to catch up (while my bmpcmp is running) | 15:15.26 |
| kens | ray_laptop : its the *_all.ps problems, where they SEGV on the macpro | 15:15.46 |
| | Alex's patch fixes this, at the cost of halving performance | 15:15.58 |
| chrisl | ray_laptop: I think Bug 692684 tracked it | 15:16.11 |
| ray_laptop | oops. my attempted bmpcmp didn't start: | 15:17.26 |
| | remote: You're not allowed to run 'rsync --server -vlogDtprcxze.iLsf --max-size 10000000 --delete . /home/regression/cluster/users/toolbin/localcluster/gitpush.sh/ghostpdl' | 15:17.28 |
| | nm. command line typo confused it. | 15:18.11 |
| | chrisl: thanks for the bug # | 15:18.49 |
| chrisl | np | 15:19.00 |
| Robin_Watts | http://ghostscript.com/~robin/patch.txt | 15:19.42 |
| chrisl | FWIW, 34_all.PS crashes for me quite easily..... | 15:20.57 |
| ray_laptop | hmm... that bug's comments are somewhat confusing. moved from 33_all.ps to 34_all.ps | 15:21.11 |
| Robin_Watts | chrisl: Can you give my patch a whirl then please? | 15:21.12 |
| ray_laptop | chrisl: thanks. I want to try peeves. | 15:21.22 |
| chrisl | Robin_Watts: just doing it now..... | 15:21.29 |
| Robin_Watts | Thanks. | 15:21.35 |
| Robin_Watts | forages for sustenance while tests run. | 15:21.46 |
| kens | Robin_Watts : I've looked at the patch, but I don't really have any useful opinion, it would take me a while to understand what's going on | 15:22.38 |
| chrisl | Robin_Watts: that seems to run fine, and valgrind likes it (on 34_all.PS). What I don't understand is how your change won't suffer the same performance issue that alexcher's did....... | 15:28.47 |
| alexcher | I'm back. | 15:29.16 |
| Robin_Watts | chrisl: Well, it may - I got lost in the details of alexes. | 15:29.39 |
| | I have queued a cluster test now so we'll see. | 15:29.49 |
| ray_laptop | chrisl: didn't fail for me (without Robin_Watts' patch) | 15:30.09 |
| | chrisl: what's your command line that fails for you ? | 15:30.55 |
| chrisl | ray_laptop: I had to used: -sOutputFile='| md5sum >>./tests_private__comparefiles__Bug687614.ps.plank.72.0.md5' -dMaxBitmap=30000000 -sDEVICE=plank -r200 -sDEFAULTPAPERSIZE=letter -dNOPAUSE -dBATCH -K1000000 -dClusterJob -dJOBSERVER - < 34_all.PS | 15:30.56 |
| alexcher | Robin_Watts: my patch does 2 thinds (1) revert an old attempt, (2) move the flag. | 15:31.01 |
| Robin_Watts | Right. | 15:31.17 |
| | So it's not clear which part of that is causing the slowdown. | 15:31.29 |
| ray_laptop | Robin_Watts: the splitting of init2 can't cause slowdown | 15:31.54 |
| | chrisl: thanks. trying that now... | 15:32.17 |
| Robin_Watts | Either my test will come back as slower (in which case we can just abandon it) or it'll come back as faster (in which case it's useful). | 15:32.27 |
| alexcher | Robin_Watts: Moving the flag. Perhaps, an allocatot triggers GC but not collected. | 15:32.28 |
| ray_laptop | chrisl: that still doesn't fail for me :-( | 15:33.42 |
| chrisl | ray_laptop: well, it is indeterminate, so...... | 15:34.06 |
| saper | are there bounties for improving svgwriter? | 15:37.45 |
| ray_laptop | chrisl: I notice you aren't running gs_cet.ps -- does it fail the same way if you add %rom%Resource/Init/gs_cet.ps ?? | 15:38.15 |
| saper | how can I submit a patch (it's a commit against git master) | 15:38.15 |
| Robin_Watts | saper: Is it a patch for a bug? | 15:38.48 |
| | or is it adding a new feature? | 15:38.57 |
| ray_laptop | saper: if it's a bountiable bug, then there we pay a bounty. | 15:38.57 |
| Robin_Watts | If the former, then you put the patch on the bug. | 15:39.06 |
| | If the latter, create an an enhancement bug requesting the feature, then see my previous answer :) | 15:39.29 |
| ray_laptop | saper: as far as giving us a patch to review, you can email it or attach it to a bug | 15:39.46 |
| | what Robin_Watts said | 15:40.04 |
| saper | Robin_Watts: no, it seems that SVG CSS is completely broken in master | 15:40.06 |
| Robin_Watts | Adding it to a bug is better, because that way it gets tracked/doesn't get forgotten etc. | 15:40.11 |
| chrisl | ray_laptop: no it doesn't crash when using gs_set.ps | 15:40.17 |
| saper | Robin_Watts: ok so I open a bug then, thanks! | 15:40.27 |
| Robin_Watts | saper: Thanks for the patch! | 15:40.41 |
| ray_laptop | chrisl: yuck -- one of those 'where it is in memory' problems :-( | 15:41.26 |
| | chrisl: can you valgrind the command line that does fail ? | 15:41.55 |
| chrisl | ray_laptop: yeh, I'm just checking for the valgrind option I want...... | 15:42.31 |
| ray_laptop | chrisl: BTW, is your failure with a debug or release build ? | 15:42.39 |
| chrisl | ray_laptop: debug | 15:42.57 |
| ray_laptop | chrisl: just the default does memcheck -- that's probably all you need. | 15:43.04 |
| | chrisl: well, at least that's good. | 15:43.13 |
| chrisl | ray_laptop: I want the option that traces where memory failures started | 15:43.29 |
| ray_laptop | chrisl: does it segv under gdb as well | 15:43.34 |
| alexcher | ray_laptop: The bug is about writing at a wrong (but valid) address. Valgrind cannot catch this. | 15:43.36 |
| chrisl | ray_laptop: yes, but it doesn't fail in a place that's obviously connected to gc :-( | 15:44.08 |
| ray_laptop | alexcher: if it's writing at a valid address, why does this cause a SEGV ? | 15:44.12 |
| Robin_Watts | It's writing through a pointer that points to the stack. It's just the thing that the pointer points to might not be there any more. | 15:44.37 |
| alexcher | ray_laptop: a variable that is located at this address is late used to calculate an address. | 15:45.02 |
| ray_laptop | Robin_Watts: OK. so the stack segment is still valid, but then the stack becomes corrupted ? | 15:45.24 |
| Robin_Watts | Right. | 15:45.29 |
| | And as alex says, that corrupted value is then used elsewhere, causing a SEGV. | 15:45.51 |
| | AIUI, alex's patch and mine work in different ways. | 15:46.35 |
| ray_laptop | so I see why it's fairly indeterminate | 15:46.49 |
| | and also why testing ANY patch is inconclusive | 15:47.15 |
| Robin_Watts | alex changes it so that the pointers instead point to a value in an allocated block (rather than a value on the stack). | 15:47.27 |
| | which still means that things might suffer from stale pointer writing - just hopefully it won't matter. | 15:48.10 |
| | My patch changes it so that we only have 1 pointer (still pointing to the thing on the stack). We should never get stale pointer writing at all with mine. | 15:48.42 |
| ray_laptop | Robin_Watts: right. you have the pointer in the lib_ctx | 15:48.46 |
| | Robin_Watts: why named gc_signal instead of pgc_signal ? | 15:49.12 |
| Robin_Watts | I think. possibly. I am not a lawyer. objects in the mirror may be closer than they appear etc. | 15:49.16 |
| | because my hungarian is poor. | 15:49.40 |
| chrisl | Well, that's impressing: we just made valgrind core dump! | 15:50.22 |
| Robin_Watts | chrisl: Does that all the time on the mac :( | 15:50.43 |
| ray_laptop | I don't see how the pointer in the lib_ctx is better than the pointer in the mem stuct. both are in non-gc memory | 15:50.45 |
| | isn't the problem is that the thing it is pointing to is in the stack area ?? | 15:51.21 |
| Robin_Watts | ray_laptop: The problem with the existing code is that we set the pointer in every space, then unset the pointer in every space when we finish. | 15:51.22 |
| ray_laptop | what am I missing | 15:51.24 |
| Robin_Watts | only some times, for some reason I don't understand we fail to unset it in some spaces. | 15:51.39 |
| chrisl | I still wonder *how* we end up with stale pointer(s) in one or more mem structs..... | 15:51.48 |
| ray_laptop | Robin_Watts: 'finish' is vague. finish what ? | 15:51.54 |
| Robin_Watts | When we enter gs_interp we set the pointer, when we exit it, we clear it. | 15:52.21 |
| | gs_interpret, sorry. | 15:52.46 |
| ray_laptop | right, so the problem is that sometimes it is not cleared ? | 15:53.11 |
| Robin_Watts | The problem is that sometimes, at least one of the pointers is not cleared. | 15:53.34 |
| ray_laptop | so why does having it in the lib_ctx guarantee that it is cleared if there is a path out of gs_interpret that is leaving it set ? | 15:53.48 |
| Robin_Watts | I reduce the number of pointers we have to just 1 - hence hopefully avoiding the case where we drop one. | 15:54.05 |
| | There IS no path out that doesn't clear it. | 15:54.17 |
| | It's just that the clearing function is... complex. | 15:54.24 |
| | It only clears 'current' spaces, or something, so if a space ceases to be current, it doesn't get cleared. | 15:54.56 |
| | (treat that last line with suspicion - my understanding here is vague at best) | 15:55.16 |
| alexcher | We can make a debug version that validates the pointer after every operator in the main loop. | 15:56.46 |
| ray_laptop | Robin_Watts: each space has it's own signal because we can selectively reclaim | 15:57.13 |
| Robin_Watts | ray_laptop: But they are all set/unset as one. | 15:57.38 |
| | i.e. they all end up prodding the same thing. | 15:57.49 |
| | So they might as well share the same stick to prod with. | 15:58.02 |
| ray_laptop | Robin_Watts: OK. | 15:58.05 |
| | so the theory makes sense (as long as we never leave a stale pointer in the lib_ctx) | 15:59.26 |
| Robin_Watts | indeed. | 15:59.33 |
| | my cluster test is running now, so we should see whether it causes a slowdown or not fairly soon. | 16:00.16 |
| ray_laptop | Robin_Watts: which of the bmpcmp windows is the 'reference' vs. the 'test' ? (and why doesn't it say above the columns?) | 16:03.10 |
| Robin_Watts | CRD. | 16:03.17 |
| | Candidate, Reference, Diff | 16:03.21 |
| | It could say, but that would take valuable screen real estate. | 16:03.45 |
| ray_laptop | right. BTW I _detest_ the mousover action. I always have to be careful to keep my mouse away or it messes up | 16:04.48 |
| | but if everyone else likes it, I'll just tolerate it | 16:05.13 |
| Robin_Watts | ray_laptop: The mouse over for blink test is really useful at times; I'd be loathe to remove it. | 16:05.36 |
| kens | Its good if your browser works wiht it, annoying if it doesn't | 16:05.57 |
| Robin_Watts | The blink test works on all browsers. | 16:06.10 |
| | The zoom is broken on some. | 16:06.18 |
| kens | No, the blink fails for me on Firefox | 16:06.27 |
| | All three windows goblank | 16:06.33 |
| Robin_Watts | (or rather some browsers have broken the zoom - it used to work on all) | 16:06.36 |
| ray_laptop | kens: me too | 16:06.44 |
| Robin_Watts | kens: No, that's the zoom going wrong. | 16:06.44 |
| | blink is on the left hand image only. | 16:06.51 |
| kens | Robin_Watts : maybe I misunderstand you | 16:06.54 |
| Robin_Watts | you put your mouse into the left hand image, and it swaps with the middle image. take it out and it swaps back. | 16:07.20 |
| kens | Hmm, I thought it used to work (blink) on both | 16:07.26 |
| Robin_Watts | If you put your mouse into the middle image, it should display a zoomed in magnifier. | 16:07.35 |
| | but that's broken currently. | 16:07.43 |
| | The script hasn't changed, the browsers have. It's very annoying, and I've not had time to debug it. | 16:08.01 |
| | I could be persuaded to remove the zoom thing until it's fixed. | 16:08.24 |
| ray_laptop | for me the 'blink test' flip of the windows works only on the leftmost window. | 16:08.41 |
| Robin_Watts | ray_laptop: Right. That's what it's supposed to do. | 16:08.56 |
| kens | removing the zoom would be helpful for now | 16:09.01 |
| alexcher | On Firefox 13.0.1 on Linux blink works but zoom doesn't. | 16:09.08 |
| Robin_Watts | I could also be persuaded to make the blink thing only work if you hold 'ctrl' down on something. | 16:09.12 |
| | yeah, blink works on everything. | 16:09.19 |
| | Zoom used to work on everything, but then it's gradually stopped working on different browsers as they have updated their js engines. | 16:09.51 |
| | it's really annoying. | 16:09.55 |
| ray_laptop | the problem is that if the mouse is laying over a window when paging down, it reverses the windows from CRD to RCD and I have to remember to move the mouse away | 16:09.57 |
| Robin_Watts | ray_laptop: Right. | 16:10.06 |
| | I'll look into making the blink thing only happen if CTRL is held down or something. | 16:10.19 |
| ray_laptop | Robin_Watts: that would be good for me (and it sounds like kens too) | 16:11.09 |
| | what's the 'zoom' supposed to do ? | 16:11.33 |
| Robin_Watts | http://valid.tjp.hu/tjpzoom/ | 16:11.56 |
| | Like that. | 16:11.59 |
| ray_laptop | oops. I was playing with it and didn't read above | 16:12.07 |
| | can we make the zoom also conditional on CTRL as well | 16:12.29 |
| Robin_Watts | I'll disable it until I've fixed it. | 16:12.50 |
| ray_laptop | Robin_Watts: BTW, that URL (tjpzoom) works for me, but not with the bmpcmp window | 16:14.08 |
| kens | I'm happy with the blink, the broken zoom is painful | 16:14.12 |
| Robin_Watts | ray_laptop: Yes, it's probably something stupid I broke when converting the script. | 16:14.30 |
| ray_laptop | Robin_Watts: I see. | 16:14.38 |
| | making the mouseover conditional on a modifier key would help me since the image sizes are different the mouse position has to be over on the scroll bar or I get different actions as I scroll down the page | 16:16.34 |
| Robin_Watts | My cluster test failed with "too many timeouts" :( | 16:17.19 |
| | so I'm guessing there must be something wrong with the theory. | 16:17.46 |
| | So, I'll butt out and leave it to alexcher. | 16:18.25 |
| alexcher | Robin_Watts: OK, at least now we understand the problem better. | 16:20.01 |
| kens | OK finally finished the broken fonts problem, off ro the night now. | 16:23.07 |
| ray_laptop | alexcher: I'm not sure about that, since not only don't we know why we _sometimes_ have a stale pointer to the stack based variable, but we also don't understand why having the variable in the lib_ctx make the GC more frequent (as your patch did) | 16:31.50 |
| | or at least we are assuming that the regressions slowed down because the GC was more frequent -- even that wasn't verified | 16:32.35 |
| | Robin_Watts: BTW, the tjpzoom is _really_ funky w.r.t. trying to change the window size and zoom factor. IMHO, rather than a 'cliick' to change state a modifier key might have been nicer. | 16:34.28 |
| | Robin_Watts: the problem is with a touchpad I get a click when touching the pad so the state changes at unexpected times | 16:35.23 |
| | Robin_Watts: so if you re-enable the zoom in the future, please consider that. | 16:36.36 |
| henrys | alexcher:let's have a code review before the next change on this particular problem. I think it is difficult enough that it needs more than one set of eyes before a change. | 16:38.12 |
| saper | Robin_Watts: submitted http://bugs.ghostscript.com/show_bug.cgi?id=692527#c6, I think it's trivial | 16:48.58 |
| Robin_Watts | gentlemen, start your browsers: http://ghostscript.com/~regression/robin/ | 17:39.58 |
| | The zoom thing should work now. | 17:40.08 |
| | and the zoom thing should only react to clicks if ctrl is pressed. | 17:40.31 |
| sebras | Robin_Watts: sshfs magic! | 17:41.09 |
| Robin_Watts | There are slight edge effects with the zoom on the right/bottom, as the script wasn't used to dealing with images with borders. | 17:42.28 |
| tor8 | windows users may find this handy: http://code.google.com/p/win-sshfs/ | 17:45.00 |
| Robin_Watts | ray_laptop: See the logs. | 17:47.01 |
| ray_laptop | tor8: I saw that sshfs -- I downloaded it and the setup fails. Check failed -2.... (-2G) | 17:53.17 |
| | Robin_Watts: OK. | 17:53.23 |
| tor8 | ray_laptop: I installed the Dokan package first, and then there's the .NET 4 dependency but that one was installed automatically | 17:54.01 |
| ray_laptop | Robin_Watts: I see the logs -- I'll try it when my bmpcmp finishes | 17:58.54 |
| Robin_Watts | ray_laptop: OK. I've updated it so that the swapping should only happen for the blink test with the ctrl key held down. | 18:09.46 |
| | hopefully at least - we'll see as your test ends :) | 18:10.02 |
| | Also, if you hover your mouse pointer over the left hand image a tooltip pops up to tell you it's the candidate. | 18:13.51 |
| | Hmm. Zoom still seems broken in Chrome. | 18:17.51 |
| | Ah, no, my bad. | 18:18.22 |
| | So, people can look at rays bmpcmp page - if anyone has any more suggestions, let me know. | 18:19.44 |
| dogmatic69 | hi all | 23:21.22 |
| | i have been having some issues for two days now with pdfs rendered in tcpd through php | 23:21.42 |
| | it works on a server with gs 9.04 but not 9.05 with an error along the lines of "Warning: File has unbalanced q/Q operators (too many q's)" | 23:22.23 |
| | anyone know why this is? | 23:22.34 |
| | Forward 1 day (to 2012/07/13)>>> | |
IRC Logs