[00:24:53] --- Dan has become available [00:29:33] --- Dan has left [00:29:33] --- Dan has become available [02:28:06] --- kula has left [02:28:55] --- kula has become available [02:32:32] --- kula has left [02:33:37] --- kula has become available [02:39:11] --- kula has left [02:40:18] --- kula has become available [05:18:23] --- Dan has left: Replaced by new connection [05:18:23] --- Dan has become available [05:18:47] --- Dan has left [05:20:48] --- Dan has become available [05:51:26] --- mvitale has become available [06:01:34] --- meffie has become available [06:21:36] --- Brandon Allbery has become available [06:55:39] --- Dan has left [06:57:47] --- Dan has become available [07:03:21] --- deason has become available [07:07:43] --- Dan has left [07:07:48] --- Dan has become available [07:51:30] --- meffie has left [08:04:30] --- deason has left [08:04:30] --- deason has become available [08:31:44] I guess it looks like our Makefile style is to use @VAR@ directly instead of setting _VAR=@VAR@ and using ${_VAR}. [08:34:39] Hmm, though we do use the latter form for ENABLE_KERNEL_MODULE. [08:44:03] Well, we set it but never use it, it looks like. [10:09:27] --- stephan.wiesand has become available [11:11:02] --- meffie has become available [11:14:11] --- shadow@gmail.com/barnowl0E4B2EC9 has left [11:14:34] --- shadow@gmail.com/barnowlB40E86E5 has become available [11:17:03] --- shadow@gmail.com/barnowlB40E86E5 has left [11:18:58] --- shadow@gmail.com/barnowlCA9FC336 has become available [11:27:43] --- Simon Wilkinson has become available [11:32:36] --- Dan has left [12:00:20] --- Simon Wilkinson has left [12:03:53] --- Simon Wilkinson has become available [12:29:21] --- meffie has left [12:42:29] we use VAR=@VAR@ in several places... like the Makefile.config.in stuff [12:42:56] --- stephan.wiesand has left [12:44:41] I'm thinking of use as the dependency of a target in particular. I guess I did see those (RXDEBUG, XCFLAGS, etc.) but dismissed them as "not what I'm thinking of". [12:52:09] I think it makes some sense to just use it bare for something that's readonly and only used in one place or two [12:54:43] I'm used to seeing the intermediate variable used from the freebsd build system, where it is used for optional features. Though, those are controlled by values in ~make.conf, and use make conditionals not shell/autoconf ones. [13:01:10] --- meffie has become available [13:19:54] Simon: yup, rxgen -b does help. [13:20:13] --- deason has left [13:20:13] --- deason has become available [13:20:36] -b also makes writing code much less tedious. I got very bored of token.token_len [13:21:06] And it means that you can assign an opaque to another opaque without type casting. Which I suspect you will find comes in handy. [13:21:24] I almost broke down and wrote a man page for rxgen when I was looking at how to invoke it. I guess I would have known this, then. [13:21:40] Yeah, a man page for rxgen would be nice [13:25:27] Now for the part where rxgen doesn't support 'hyper'. Though I guess I should be using customized structs and fixed-width afs types when we do this for real. [13:28:10] hyper => afs_int64 [13:29:43] > customized structs do you mean that as in the 'customized' keyword? [13:29:50] Yes. [13:29:50] istr seeing that before, but I didn't look into what it actually meant [13:29:54] what does it mean? [13:29:56] "Me, too!" [13:30:24] it doesn't generate the en/decoder [13:30:25] From memory, it lets you define your own marshalling rules for structures, rather than having rxgen produce them automatically [13:30:56] Hmm. So I should not be using that. [13:31:08] see e.g. src/fsint/afsaux.c [13:32:10] ah okay, that makes sense [13:33:00] You can also just not define structures at all in rxgen, and import C headers which define them. Then you can define your own marshalling, and structure formats. [13:33:20] That lets you use rxgen types that match existing C types [13:34:23] but that means what's on the xdr stream is no longer defined by what's in the .xg files, right? [13:35:00] Yes [13:35:02] e.g. a protocol spec would need the C codec for it [13:35:08] correct [13:35:21] But that's already true of, for example the UUID type [13:35:54] yeah yeah, it's useful for what I'd consider extensions to xdr [13:36:07] not something you'd probably want to use for an application on top [13:36:49] Yeah. I'd say it's useful for "core" types, where letting rxgen have its own way means that you end up casting everything into, and out of, rxgen. [13:46:25] --- meffie has left [15:42:52] --- Simon Wilkinson has left [15:46:53] --- mdionne has become available [16:00:02] --- mvitale has left [17:06:58] --- deason has left [19:16:17] --- mdionne has left [20:27:26] --- andersk has left [20:27:29] --- andersk has become available [20:37:24] --- kula has left: Lost connection [20:52:44] --- kula has become available [20:54:58] --- jaltman/FrogsLeap has left: Disconnected [21:03:34] --- jaltman/FrogsLeap has become available [23:41:45] --- Dan has become available