[00:30:56] --- haba has left [01:00:04] --- Simon Wilkinson has become available [01:16:49] --- brantgurga has left [01:43:43] --- dev-zero@jabber.org has left [02:43:47] --- dev-zero@jabber.org has become available [02:50:02] --- haba has become available [05:15:37] --- brantgurga has become available [05:22:19] --- brantgurga has left [05:32:16] --- Jeffrey Altman has left: Replaced by new connection [05:36:37] --- Jeffrey Altman has become available [06:54:04] > Simon Wilkinson: Does anyone have any comments they'd like to make on http://www.dementia.org/twiki/bin/view/AFSLore/GitDevelopers ? [06:54:10] mind if I make some edits? [06:54:21] oh, and 'looks great!' [06:54:38] --- brantgurga has become available [06:54:54] what do you plan to edit? [06:55:01] git branch -r [06:55:06] vs git branch -a [06:55:20] -r only shows local branches, and the wiki wording says otherwise. [06:55:44] err, -r only shows remote, not local. [06:56:24] well, it's a complete list of (our) branches, not yours. [06:56:38] but the wording could probably be made better [06:56:45] right, so s/all/all the official/ would be sufficient. [06:57:20] and maybe put a '(but not your local branches)' w/it as well. [06:57:21] explaining how to get at your own branches may be interesting but there's a balance to strike versus making the document bloated [06:57:26] * stevenjenkins nods. [06:57:37] I wasn't going to explain that difference, just tighten up the wording [06:57:39] i don't know what that balancing point is. it's not my document, either [06:59:10] --- reuteras has left [06:59:16] --- haba has left [06:59:19] also, 'delta', 'changeset', and 'commit' are used, but could benefit from some clarification. [06:59:38] --- haba has become available [06:59:41] --- reuteras has become available [07:04:04] --- deason has become available [07:06:38] I'd rather (at this point) that people didn't edit the document, but instead fed commits through me. I'm really keen that the document remain focussed on a particular way of using git, rather than a general 'this is how git works' document. There are lots of general git guides at the end. [07:07:13] not a problem. I'll email you some stuff. [07:07:24] Cool. Thanks. [07:38:47] would it hurt to have a 'mechanics' repo that people could practice the workflow on? [07:39:21] I'd be happy to watch over that and help people deal w/basic issues. [08:14:16] --- deason has left [08:15:36] I think I'm happy with people experimenting in gerrit. Nothing broken is ever going to actually make it into the tree, because we'll block it at review. [08:15:58] that's reasonable. [08:16:09] And if anyone goes really insane, we can always manually delete contributions from the gerrit repository (providing they haven't been pushed into a real branch) [08:17:45] --- deason has become available [08:18:21] I think the danger of saying to people "Here's a sandbox, please play there until you're ready for the bigger world" is that you make the bigger world seem unnecessarily scary. And gerrit works best for all of us if people aren't scared of it, and use it, and stop submitting patches via RT or email. [08:21:51] there are other tradeoffs -- e.g., division of labor can be beneficial. [08:22:04] (not that I disagree strongly w/you, btw) [08:23:28] --- reuteras has left [09:05:53] git blame is now enabled on git.openafs.org, although the formatting looks kind of weird to me. [09:06:38] It looks like gitweb has a screwed up table definition that doesn't have enough columns. [09:10:32] yup, looks that way [09:13:17] it looks good in opera [09:40:10] Fine in Safari when I checked it. [09:42:10] --- haba has left [09:43:08] http://git.openafs.org/?p=openafs.git;a=blame;f=src/afs/LINUX/osi_probe.c;h=02bd9fd5259f0b20b6c81d15f2b97a5e6590fbfd;hb=HEAD Is broken in Firefox 3 [09:43:54] I have no interest in patching gitweb. [09:44:34] --- sxw has become available [09:45:02] It also seems to work fine in Firefox 3.5 [09:48:32] spacing is weird in Firefox 3.5, compared to Chrome (OS X alpha) or Safari 4 [09:48:39] fwiw [09:52:53] scroll down to around line 200 or so [09:53:27] I'm not sure what the problem is here, btw. The HTML looks fine. [09:53:54] Looks fine here on a Mac, with 3.5. [09:54:18] Essentially, we have 2 options a) We live with it, until Debian gets a newer version of git in 'stable' b) I disable blame again [09:54:23] What would people prefer? [09:54:49] Oh, we can live with it. [09:54:53] I was just noting it was weird. [09:55:53] simon /afs/tproa.net/users/s/u/summatusmentis/firefox_screencap.tiff is what I'm seeing [09:56:13] yeah, I don't care enough for it to need to change, just providing info [10:10:40] --- mmeffie has become available [10:49:53] anyone have some time to discuss the rxi_ComputeRoundTripTime() calcuations? What is there seems wrong to me. [10:50:57] I'm not familiar with that code, but if you want someone to bounce ideas off ... [10:51:23] the "struct rx_peer" there are two values that I am focused on. rtt and rtt_dev [10:51:33] int rtt; /* Round trip time, measured in milliseconds/8 */ int rtt_dev; /* rtt smoothed error, in milliseconds/4 */ [10:51:52] rtt is in units of 1/8 ms and rtt_dev is in units of 1/4 ms [10:52:29] rtt_dev is poorly named but what it stores is a smoothed RTT value [10:53:29] in rxi_ComputeRoundTripTime() a "struct clock" is used to store the measured time. { secs, usecs } [10:53:33] (The fact that they're scaled differently seems like a disaster waiting to happen, but go on ...) [10:53:54] the macro MSEC() takes a "struct clock" and returns the number of ms [10:54:42] Now, if a previous peer->rtt is known (non-zero), a delta value is computed as such. delta = MSEC(rttp) - (peer->rtt >> 3); peer->rtt += delta; [10:55:02] delta is now in ms [10:55:25] detla is then added to peer->rtt which is supposed to be 1/8 ms [10:55:33] Yeh. That's broken. [10:56:06] it then tries to compute the smoothed rtt value by: if (delta < 0) delta = -delta; delta -= (peer->rtt_dev >> 2); peer->rtt_dev += delta; [10:56:42] except again delta is in ms and rtt_dev is in 1/4 ms [10:56:54] --- abo has left [10:57:32] Those shifts go the wrong way too, don't they? [10:57:37] I thought it was just decreasing the weight of the previous value [10:57:49] not converting from e.g. 1/4ms to ms [10:57:50] --- abo has become available [10:58:11] /* * srtt (peer->rtt) is in units of one-eighth-milliseconds. * srtt is stored as fixed point with 3 bits after the binary * point (i.e., scaled by 8). The following magic is * equivalent to the smoothing algorithm in rfc793 with an * alpha of .875 (srtt = rtt/8 + srtt*7/8 in fixed point). * srtt*8 = srtt*8 + rtt - srtt * srtt = srtt + rtt/8 - srtt/8 */ [11:00:04] /* * We accumulate a smoothed rtt variance (actually, a smoothed * mean difference), then set the retransmit timer to smoothed * rtt + 4 times the smoothed variance (was 2x in van's original * paper, but 4x works better for me, and apparently for him as * well). * rttvar is stored as * fixed point with 2 bits after the binary point (scaled by * 4). The following is equivalent to rfc793 smoothing with * an alpha of .75 (rttvar = rttvar*3/4 + |delta| / 4). This * replaces rfc793's wired-in beta. * dev*4 = dev*4 + (|actual - expected| - dev) */ [11:02:12] So, I'm pretty convinced that code doesn't do what the comment implies it does. [11:02:51] For what it is worth, I think the comment is right [11:03:01] but the code isn't [11:03:13] Yes, from the quick bit of reading I've just done, I think the comment is correct. [11:03:14] I'm pretty sure the comment is right also [11:03:21] But the code doesn't implement the comment. [11:04:29] The comments on the field declarations are incorrect. "rtt" is the smoothed value. "rtt_dev" is supposed to be a deviation value [11:05:01] As the name suggests :) [11:05:12] yes. [11:05:25] now to fix this [11:05:55] which means that all of the dynamic timeouts based upon these values are wrong [11:06:49] I guess the question is whether there's anything that relies upon these values being wrong ... [11:07:33] the only place they are exposed is in the rxdebug -peer output [11:07:46] they are entirely internal to the rx library at the moment. [11:07:58] Yeh - I meant internally, really. [11:08:09] I noticed the problem while trying to help Jake since he is going to be exporting these values to the cache managers [11:08:44] It looks like this dates back to IBM. Surprise, surprise ... [11:08:49] --- brantgurga has left [11:08:59] I suspect the periodic long timeout on very fast networks might be related to these calculations being wrong [11:09:17] did git blame tell you that? :-) [11:09:49] Well, me and git blame are having a little bit of a disagreement at the moment. [11:09:56] The command line tools told me that :) [11:28:23] --- brantgurga has become available [11:36:32] --- dev-zero@jabber.org has left [12:40:49] --- dev-zero@jabber.org has become available [13:17:52] --- haba has become available [13:34:46] --- dev-zero@jabber.org has left [13:55:18] --- mdionne has become available [14:00:38] if someone feels like patching gitweb to fix the blame formatting: http://pastebin.ca/1488834 [14:01:49] Do you know if that's already fixed upstream? [14:04:09] No, just something I tried myself - really looks like a Firefox bug, that's just a workaround [14:07:29] Oh, okay. Thanks! [14:10:26] might do weird things to non-XML-aware browsers; I'd use . [14:10:35] Does the same problem exist with other gitwebs? The git on openafs.stanford.edu is pretty old. [14:11:00] I think I've seen this on most gitwebs I visit [14:11:37] rowspan gets ignored for some reason. the HTML looks correct [14:14:38] http://kerneltrap.org/mailarchive/git/2008/4/22/1556774 [14:21:07] interesting discussion - we're seeing this now in the 3.5 release version, so putting a workaround in doesn't sound like such a bad idea [14:21:57] Makes me wonder if it's just an unfixed rendering bug or if the Firefox developers have a different understanding of the standard. [14:26:01] it behaves really strangely. If I save the HTML file locally, it usually displays OK, or with only a few messed up lines. If i highlight tables with a development plugin, it displays OK. smells more like a bug [14:28:03] Being able to commit proposed doc patches in 30 seconds: big win. :) [14:28:42] Just need to get deltas working, and you won't need a shell for anything :) [14:29:28] css? [14:29:35] Yeah, just add Tinderbox and a way to load each file into a giant text entry form and I can do all OpenAFS development in my browser! :P [14:31:21] hmm, speaking of rendering oddities, gerrit comments are looking wonky in opera [14:31:46] specifically, comment author and date are squished together, but only sometimes [14:33:47] this seems related: https://bugzilla.mozilla.org/show_bug.cgi?id=425498 [14:35:02] Yeah, that looks like it. [15:38:34] --- deason has left [15:57:04] --- dev-zero@jabber.org has become available [16:02:48] --- deason has become available [16:41:58] --- haba has left [16:42:56] --- Simon Wilkinson has left [16:48:44] Proposed replacement for wdelta is at http://git.openafs.org/deltas/ [16:53:45] Are future commits going to be labelled as deltas, too, or is this only for pre-Git? [16:55:03] sxw: Does this have the interface for tagging new deltas already? The viewing part looks great to me. [16:55:10] Future commits will be labelled as deltas too, until 002363adb9526f4c0bc2937b0b6589fae0e5334e becomes as catchy as man-page-vos-zap-typo-20090706 [16:56:19] Git accepts abbreviated SHA1s (002363a). But okay. [16:56:19] It does have the new tagging interface, yes. [16:57:00] The old wdelta sorts in reverse order by date, which is somewhat more usable. [16:57:06] The plan is to add support to gerrit for accepting a reference name with each submit action. But we're not there yet, so there's a little web interface to do it for us. [16:57:39] andersk: Fixed [16:58:03] (More work is needed on the sorting and grouping options - at present they're all no-ops) [16:59:35] The search form goes to /cgi-bin/wdelta which doesn’t exist. [16:59:58] Gah. Okay. [17:01:24] I see the STABLE14- got chopped off all the openafs-stable-1_4_x delta names. [17:01:49] Yes. All of the branch signifiers got chopped as part of the the conversion. [17:02:49] The Download link gives you a leading newline before the patch. [17:03:27] git gives you a leading new line. I just share it :) [17:03:52] (That's just git log --pretty=format: -p ) [17:04:34] Hmm. Do you actually want the commit information stripped off? [17:04:56] I was trying to be vaguely consistent with what wdelta spat out. [17:05:08] The thing is there can be multiple ones of these concatenated together. [17:05:25] (For the deltas that aren't single changesets) [17:06:00] Ah, I see. Will the extra newlines cause problems for those concatenated patches? [17:06:32] They shouldn't - patch should just throw them away and continue working. [17:07:04] But I guess what I really need is either a way of getting git to give me just the patch, or to strip off that leading newline. [17:08:53] Old wdelta linkified FIXES nnnnnn headers and various other things. Though I suppose you probably know about missing features. [17:09:40] `git diff COMMIT^ COMMIT` is one way. [17:09:50] It's useful to hear about missing features. [17:10:36] But my intention with this wdelta replacement was to do the bare minimum in the hope that everyone will just use gitweb in the long run. [17:10:54] It's really just there to serve the 200 ish 'bad' deltas that can't be represented via gitweb. [17:11:08] But, if people find it useful, I'm happy to add stuff to it. [17:11:44] Delta pages no longer have links back to the branch index and the delta list. You also can’t just chop off the end of the URL to get there like you could with wdelta. [17:12:33] Yeh. There's no breadcrumbs. I should probably add that back in. [17:12:45] Maybe linking each delta to the corresponding commit on gitweb would be useful? [17:13:00] I thought I had. [17:13:25] Ah, no, just each file. [17:14:09] I didn't do each delta, because there isn't a guaranteed 1->1 relationship. But I guess we could just have [ part 1] [ part 2] and so on. [17:15:51] --- deason has left [17:19:06] --- deason has become available [17:43:23] --- Russ has left: Disconnected [18:00:40] --- Russ has become available [18:16:51] after spending a bit more time working through the math, rxi_ComputeRoundTripTime is in fact doing the right thing. The only things that are questionable are: 1. precision below 1ms is needlessly lost 2. it is unclear that alpha values of .875 and .75 respectively are the best choice. [18:21:42] apparently i missed something. i could have told you, at least, that the math in rxi_ComputeRoundTripTime was correct, as i had to look at it once before in detail [18:22:13] i can, however, offer no defense of .875, .75 [18:22:13] I've fixed the precision loss [18:22:42] I'm researching the values for alpha. [18:23:51] I think the RTO calculation wants to be MIN(RTO, 350ms) instead of adding 350ms onto each timeout value [18:25:50] So, did you actually fix the lack of precision, such that converting from a struct clock gives you sub-millisecond values, or did you just fix the shifts so we do more persistent math with values that are only ever whole milliseconds to begin with/ [18:26:10] s/persistent/precise/ [18:26:58] Note that in any case, you need to be careful that keeping more precision doesn't mean shifting away nonzero high-order bits. But presumably you considered that. [18:27:08] there are now struct clock conversion macros for USEC, _8THMSEC, and _4THMSEC [18:29:01] I did consider the loss of nonzero high-bits. If we limit ourselves to the use of 32-bit integers then the USEC macro only works for values up to about 12 minutes [18:31:40] Regarding wdelta... Note that it's fairly important to me that existing URL's work as-is, which means the new thing needs to accept deltas in the form used by the old wdelta. Of course, it needn't obey all of the options, but it should at least do something reasonable. We may be able to deal by having some redirects. [18:32:02] the old wdelta urls *could* be served by the old wdelta [18:32:54] But 4THMSEC should work up to about a million seconds, and 8THMSEC to half that, which I suppose is plenty. But we should handle the corner case rather than losing. [18:33:21] of course I only need the _8thMSEC macro for my modification [18:33:40] 12 minutes? Shouldn't it be at least twice that? About 2K seconds, in fact? [18:33:55] something around there [18:34:36] They could, I suppose. [18:35:25] Jeff, while you appear to have a moment in time, could you add a redirect for www.openafs.org/docs/ -> docs.openafs.org ? [18:37:52] I haven't dealt yet because it will take me more than a moment to wade through the mess that is the httpd.conf for that and make sure everything is right. [18:39:27] /docs or /doc ? ISTR one of those exists already And I suppose I should do the frameless and pages versions, too. That's standalone, right? It wants to not be frame-wrapped? [18:41:14] the point is the one that exists should point elsewhere [18:41:48] Yeah, I understand that. What about what does't exist? [18:42:52] Particularly, both doc.openafs.org and docs.openafs.org exist and serve the same content, to avoid people losing if they type the wrong one. Do we need to do the same with /doc{,s} ? [18:43:56] what I want is for the old IBM docs to become inaccessible. that is www.openafs.org/doc/ [18:44:07] Yeah, OK [18:44:16] I would not be opposed to both www.openafs.org/docs/ being redirected as well [19:08:27] --- mdionne has left [21:16:35] --- deason has left [21:49:30] --- Russ has left: Disconnected [22:47:00] --- stevenjenkins has left [22:47:50] --- stevenjenkins has become available [22:53:40] --- dev-zero@jabber.org has left: Replaced by new connection [22:53:41] --- dev-zero@jabber.org has become available [23:00:40] --- reuteras has become available [23:14:53] --- brantgurga has left [23:55:27] --- brantgurga has become available