[03:39:48] --- SecureEndpoints has left: Replaced by new connection [05:46:11] --- reuteras has left [06:43:08] --- dmontuori has become available [07:12:41] --- dev-zero@jabber.org has become available [07:14:08] --- SecureEndpoints has become available [07:44:55] I'm looking at some C unit testing issues -- any official preference between, say, check and cunit? (or is there something better that others have found and recommend) [08:00:47] I'd just like to see it all integrate together. That is, that it should work along side the perl unit tests that Jason's been working on. Multiple testing frameworks would rapidly become dull. [08:07:33] those are two different problem spaces, though: jason's work is in the functional space, not C level. The unit testing I'm looking at is in C components, not exposed at the user-level (e.g., working out exposing some problems in the FSYNC interfaces found in src/vol/fssync*.[ch]). [08:07:52] the problem with CUnit of course is it is GPL and so we can't commit tests to the repository that would link against the various components that we would like to test [08:08:08] I don't know anything about Check [08:08:51] secureendpoints - good point about the licensing; I hadn't considered that aspect. [08:10:02] check is LGPL..that's usable for our puposes? [08:10:10] yes [08:10:31] I'll wrestle w/check, then, and see what I get. [08:10:46] although we would prefer something bsd [08:11:11] might want to look at the test framework used by heimdal [08:11:23] if someone knows of a unit test framework for C that is BSD-based, I'm happy to use it. In my looking around, cunit and check seem to be the best choices. [08:11:32] ok; I'll look at that. tx for the suggestion. [09:01:28] --- Russ has become available [09:02:47] I have an implementation of the TAP protocol that I use for all of my packages. I've been working on releasing it as an independent package. It has the nice advantage that it uses TAP, which is the same protocol used by Perl's Test::More and related modules, so any tests written in Perl are trivial and can use all of Perl's test infrastructure. [09:03:10] The test driver is pure C and there's a basic library to speak TAP from a test case, although of course it could be enhanced considerably. [09:03:35] It's all available under a BSD license. [09:04:28] It's mostly just a test driver, unfortunately, and I'm sure CUnit would do more for you. [09:40:00] --- matt has become available [10:22:37] --- matt has left [10:40:22] russ -- can you point me to your pkg? I'll take a look. [10:45:50] I haven't gotten to the point of writing documentation or a tarball release, but what I've done so far is at http://git.eyrie.org/?p=devel/c-tap-harness.git [10:45:59] You can see how it's used in, for example, the current release of remctl. [10:47:36] I'll take a look, tx. [11:12:40] --- matt has become available [11:13:44] so, is there tkeiser? [11:27:34] I have seen one 3 times before: once in Pittsburg, once in NJ, and once in Ohio. [11:28:02] possibly even 4 times. I may have seen one in NY. [11:28:41] I'm not sure tkeiser has ever been to Pittsburg [11:28:53] (note I have seen him in Pittsburgh) [11:30:26] would have invited tkeiser to pgh this weekend but the party i intended to have didn't happen [11:36:19] that's too bad. [12:11:21] --- matt has left [12:16:19] --- Simon Wilkinson has left [12:40:43] 1.5.56 on the web site. [13:18:16] --- matt has become available [13:19:14] There is no release announcement. [13:25:31] you are mister obvious [13:25:45] there's a reason i said "it's on the web site" and not something other than that [13:27:50] IFS/redirector a supported mode of operation in 1.5.56? (thanks, mr. obvious) [13:29:06] no [13:29:57] is it included, even if not supported? [13:30:01] ok, news blurb kind of implies that, as I read it, fwiw [13:30:10] i wrote the news blurb. i may be wrong. [13:30:26] i read the ChangeLog and guessed. [13:31:22] please fix it [13:32:05] "fix it" consisting of... not mentioning ifs? if so, i can do that [13:33:08] please do not mention ifs [13:33:29] fixed. [13:33:56] (well, web page exporting) [13:42:06] --- dev-zero@jabber.org has left: Replaced by new connection [13:42:07] --- dev-zero@jabber.org has become available [14:15:31] --- dmontuori has left [14:16:27] --- dmontuori has become available [14:58:38] --- dmontuori has left [19:36:20] some interesting statistics from msft. 92% of users that msft can monitor that have oafw installed are using Vista. and 100% of the users that have problems are satisfied with the response of openafs to those problems. Which I interpret as meaning that by the time most users experience a problem and submit a problem to msft, we have already fixed it and provided an updated build that includes the fix. [19:43:20] rather off topic, but, why is it called oafw rather than oafsw? [19:43:54] kfw, oafw [19:44:07] before oafw was afw [19:44:18] hm, ok [19:44:44] before oafw was nafw, previously mafw and lafw. [19:44:58] um... [19:46:15] 100% of users that had a problem are satisfied? That sounds very suspicious. Most users don't say whether they are satisfied. [19:46:32] The "f" stands for "for" [19:46:50] msft has a survey. of the survey respondants 100% said they were satisfied [19:46:51] And nevermind Derrick. [19:47:20] I used to refer inadvertantly about lafsw, iirc, but I've given thatup [19:47:21] Yeah, 100% of users answering the survey is not the same as 100% of users who had problems. [19:47:47] agreed. I'm quoting their report [19:48:00] I also don't believe the 92% of users of oafw are on vista. [19:48:15] I think msft has a very poor method of obtaining info from xp [19:48:17] (the latter, vista, does seem suspicious) [19:51:23] --- matt has left