| 01:02.47 | brlcad | what exactly was the breakage? |
| 01:03.07 | ``Erik | width differences on 64b fbsd |
| 01:03.28 | ``Erik | mostly just -Wall -W -Werror -ansi -pedantic hunting *shrug* |
| 01:03.43 | ``Erik | admin -o 'em if you want *shrug* |
| 01:04.07 | brlcad | cvs admin is the devil |
| 01:04.18 | ``Erik | (everyone else who read that cmd, forget it now. seriously. flush it out of your brain. it's a nuclear command.) |
| 01:04.38 | brlcad | no kidding |
| 01:05.06 | brlcad | if I have to restore a cvs backup, i'd be removing commit access at the same time |
| 01:05.14 | brlcad | admin is baaad |
| 01:05.25 | brlcad | anyways, the actual error though? |
| 01:05.53 | brlcad | was it on the cast on the malloc() link in bu_malloc()? |
| 01:05.54 | ``Erik | meh, I don't remember off the top of my head, I actually modified my checkout in december... |
| 01:06.09 | brlcad | or on a caller to bu_malloc() |
| 01:06.22 | ``Erik | the bu_malloc<->malloc relationship |
| 01:06.35 | brlcad | heh, well that's true with either |
| 01:08.00 | ``Erik | <-- got a hair up his arse to do the anal flags thing, got that far and got busy with other things *shrug* |
| 01:18.03 | brlcad | hmm, I'll have to let it simmer a bit .. the biggest impact is adding another dep to the bu interface (even though there are a few others that sprinkle in size_t too) |
| 01:18.49 | brlcad | given the move to allow anything that is strict ansi 89 complaint, I think most of the old reasons vanish |
| 01:19.23 | brlcad | not sure if size_t is 89, but it's at least 99 so it just adds a header dep on stddefs.h |
| 01:31.20 | Maloeran | size_t is C89 |
| 01:38.51 | ``Erik | when we merge rayforce in, it'll induce c99 as a requirement (for that part) |
| 01:39.33 | Maloeran | Ah yes, it's all pretty much C99 |
| 01:41.39 | ``Erik | what, c89 vs c99 vs, uh, vax k&r? |
| 01:41.58 | ``Erik | emacs vs vim vs alltheothercrap? |
| 01:42.06 | Maloeran | Oh, no :). Old good religious debates, you know... Reason versus absurd theories |
| 01:42.12 | ``Erik | hum |
| 01:42.21 | ``Erik | reason vs absurity... so... vim vs emacs... |
| 01:42.22 | ``Erik | O:-) |
| 02:01.49 | brlcad | out of curiosity, what c99isms? |
| 02:03.18 | brlcad | i recall seeing a lot of GNUisms, but not so much c99isms |
| 02:04.55 | brlcad | nothing wrong with making c99 allowable too, it was on the plate for next year -- just strict c89 was the "next step" and a lot of cleanup in itself |
| 02:14.31 | Maloeran | C99 data types, restrict keyword, variable-length arrays... I think the rest is gnu99 |
| 02:15.43 | ``Erik | scoped functions? (function definitions inside of functions) |
| 02:16.07 | Maloeran | No nested functions, that was in the old code |
| 02:16.07 | ``Erik | or didja not go that route? |
| 02:16.13 | ``Erik | aight |
| 02:18.18 | brlcad | why do I get the feeling the code has never been compiled with anything but gcc? :) |
| 02:19.17 | Maloeran | Ahaha. I'm not sure, can you answer that Erik? :) |
| 02:20.25 | brlcad | heh |
| 02:31.41 | Maloeran | It should be reasonably portable ; 32, 64 or X bits, IEEE or non-IEEE floats, GNU'isms with alternative paths... It still needs testing in other environments |
| 02:36.04 | ``Erik | I'm sure mipspro or sunpro would puke |
| 02:36.33 | Maloeran | They are C99, right? |
| 02:36.41 | ``Erik | don't think so... |
| 02:36.52 | ``Erik | d'no if tendra is |
| 02:37.27 | brlcad | they both support c99 .. it's more what exact headers are allowed and what mode you tell the compile in by default |
| 02:37.27 | ``Erik | huh, cool |
| 02:37.47 | brlcad | default behavior (akin to gcc's gnu99 mixed default) is a hybrid that might turn off some c99 stuff |
| 02:38.13 | brlcad | my faith in sunpro's capacity to compile c99 strict is weak |
| 02:38.48 | brlcad | last time I was working on sunpro, if you told the compiler to go strict, it would puke on its own system headers being non-compliant and abort |
| 02:38.57 | ``Erik | hehehe, sweet |
| 02:41.44 | brlcad | yeah, i was amused |
| 08:21.19 | *** join/#brlcad clock_ (n=clock@zux221-122-143.adsl.green.ch) |
| 08:36.20 | *** join/#brlcad clock_ (n=clock@zux221-122-143.adsl.green.ch) |
| 11:48.15 | *** join/#brlcad clock_ (n=clock@zux221-122-143.adsl.green.ch) |
| 13:54.36 | *** join/#brlcad rossberg (n=rossberg@bz.bzflag.bz) |
| 14:02.27 | rossberg | question from yesterday: what's the problem with vers.c on Windows? |
| 14:37.35 | clock_ | And, what's the assumed for the pix files when rendering textures? |
| 14:37.45 | clock_ | assumed -> assumed gamma |
| 15:00.07 | *** join/#brlcad archivist (n=archivis@host217-35-76-52.in-addr.btopenworld.com) |
| 15:09.23 | brlcad | dout! |
| 15:10.40 | brlcad | clock_: i don't know if there's another language barrier coming into play, but i answered yesterday that it entirely depends on the shader(s) being used |
| 15:11.09 | brlcad | there's no "gamma value" that will answer that question that covers all the various shaders |
| 15:12.07 | clock_ | What are the shaders that can map pixmaps? |
| 15:12.26 | brlcad | what do you mean by map pixmaps? |
| 15:12.36 | clock_ | cause pixmaps to appear on objects |
| 15:12.37 | brlcad | you can stack *any* shader on top of any other |
| 15:12.54 | brlcad | each layer is effectively a filter |
| 15:13.06 | clock_ | subtractive or multiplicative filter? |
| 15:13.21 | brlcad | arbitrary, depends on the shader |
| 15:13.30 | brlcad | that's the whole point |
| 15:13.45 | clock_ | How do I make a cube which is painted with a pixmap? |
| 15:13.53 | clock_ | plastic + bitmap shader? |
| 15:14.05 | brlcad | that's one way |
| 15:14.17 | clock_ | and what will be the assumed gamma of the pixmap in that case? |
| 15:14.57 | brlcad | what answer will make you happy? |
| 15:15.05 | clock_ | the correct one |
| 15:15.50 | clock_ | Or - if you don't understand the question - |
| 15:16.04 | clock_ | what happens with the pixmap when it enters the shader? |
| 15:16.12 | clock_ | How is it interpreted, or for what is it used? |
| 15:16.43 | brlcad | i actually just get the feeling that you're not understanding my answer |
| 15:18.15 | clock_ | I want to know with what gamma I should generate the pixfiles |
| 15:18.15 | brlcad | it doesn't boil down to the same gamma metric you have with the display, you have the values in the image file that are parsed directly |
| 15:18.16 | clock_ | where do I figure this out or how do I figure this out? |
| 15:18.16 | brlcad | i suppose you could "say" that they're linearly looked up |
| 15:18.25 | brlcad | but that isn't entirely true in itself as it still depends on the light |
| 15:19.13 | clock_ | linearly looked up == gamma is 1.0? |
| 15:19.53 | brlcad | probably the closest corrollary, but again, that's not entirely valid mapping |
| 15:20.08 | clock_ | what is a corollary and what is a valid mapping? |
| 15:20.19 | clock_ | I want to know the gamma I should encode it with! |
| 15:20.33 | clock_ | Or at least tell me how it's calculated inside |
| 15:21.11 | clock_ | In the worst cause if I don't manage to pry the answer from you, I can try putting pixels with values of 64 and 128 and look at ratio of the resulting values ;-) |
| 15:21.24 | clock_ | determine by an experiment ;-) |
| 15:22.48 | brlcad | ray is fired at scene, intersection is found with an object, that object has a texture shader and a phong shader, texture value is looked up and combined with light visibility from that position in 3-space, that intensity is combined with the phong shader's intensity lookup that is similarly based on light intensity at that point, but also takes into account shadowing, specularity/diffusion parameters based on object curvature |
| 15:23.01 | brlcad | that's the jist of "how it's calculated" |
| 15:23.42 | clock_ | texture value is looked up that means we take a value triplet from the input pixfile, right? |
| 15:24.45 | clock_ | like if there is say 0x80 0x80 0x40 in the pixfile, then we take 0x80, 0x80, 0x40... |
| 15:24.51 | brlcad | and on top of all of that, the resulting image map is then mapped to a framebuffer which can apply a gamma adjustment, which is then displayed in a display manager window which can also perform a gamma adjustment |
| 15:25.53 | clock_ | What I am interested in is "texture value is looked up and combined with light visibility from that position in 3-space, that intensity is |
| 15:25.56 | clock_ | ..." |
| 15:26.16 | clock_ | What does the "combined" exacly comprise? multiplying the pixmap triplet with the light triplex? |
| 15:26.28 | clock_ | triplet |
| 15:27.42 | brlcad | basically yes, through a settable weighting factor that is part of the phong shader |
| 15:28.25 | clock_ | is there some exponential function applied to the pixfile before it is multiplied with the ray? |
| 15:28.52 | clock_ | So if I understand it correctly, the pixmap value defines directly (with some scaling) how much the object reflects light at that point? |
| 15:29.08 | brlcad | not that comes to mind |
| 15:29.32 | brlcad | no, it doesn't determine how much is actually reflected -- phong does that |
| 15:29.56 | clock_ | OK lemme express more precisely |
| 15:30.06 | clock_ | if you have some pixel value in the pix file say 10 |
| 15:30.18 | clock_ | and the pixel happens to reflect 10% light |
| 15:30.35 | brlcad | ok |
| 15:30.39 | clock_ | and you increase the value in the pix file to 20, now the pixel will reflect 20% of light? |
| 15:31.25 | brlcad | you mean 20% of that 20 intensity? |
| 15:31.39 | clock_ | no I mean that the number of photons will double |
| 15:31.49 | clock_ | if you imagine the scene like a pinball with photons |
| 15:31.57 | clock_ | a photon == a pingpong ball |
| 15:32.34 | brlcad | if the pix file has 10 and phong determines reflectance of 10%, the pixel will be intensity 1 -- increase the pix file to 20 and with that same reflectance of 10% will result in a pixel intensity of 2 |
| 15:33.00 | clock_ | yes that makes sense |
| 15:33.04 | clock_ | this is what I wanted to know |
| 15:33.12 | clock_ | in other word, the gamma of the input pixfile is 1.0 |
| 15:33.49 | brlcad | that is where we diverge |
| 15:34.31 | brlcad | maybe to say that "when combined with phong paraameters that give a gamma of 1.0", yes the gamma of the input pixfile is 1.0 |
| 15:34.40 | clock_ | For me, "double the value in the pixfile and the pixel intensity doubles" is enough for me |
| 15:35.14 | archivist | reflection is linear |
| 15:36.01 | brlcad | that it is |
| 15:36.13 | clock_ | The other possible meaningful implementation would be that someone would realize that the 8-bit values in the input pix file cause a banding near 0 because of insufficient colour depth |
| 15:36.29 | clock_ | and would insert a power-to-2.2 function between loading the pixfile and sending it into the shader |
| 15:37.08 | clock_ | but according to what you are saying, it's not this way |
| 15:37.17 | brlcad | you could leave the pix file unmodified and make a non-linear light too, or a non-linear shader, or in the display manager too |
| 15:38.02 | clock_ | no that would produce corrupted image |
| 15:38.06 | brlcad | banding is a visual artifact of the end result -- the math occurs in floating point |
| 15:38.19 | clock_ | the pixfile isn't in floating point |
| 15:38.39 | brlcad | i didn't say it is |
| 15:46.32 | clock_ | can I imagine the bitmap shader like there is an image printed on the object and the pixfile gives reflectivities in the individual places? |
| 15:47.25 | brlcad | like a bump map? |
| 15:47.30 | brlcad | there is a bump map shader |
| 15:47.39 | clock_ | no |
| 15:47.58 | clock_ | bump map is something where the shape of the surface is supposed to be distorted, isn't it? |
| 15:48.09 | brlcad | only visually distorted |
| 15:48.25 | brlcad | by changing reflectivities at various places based on the image |
| 15:48.48 | dtidrow | a displacement map would actually distort the surface |
| 15:48.49 | clock_ | I always saw the bump map for something that modulates the normal vector |
| 15:48.55 | clock_ | like embossed relief |
| 15:49.08 | dtidrow | basically, yes |
| 15:49.16 | clock_ | no I don't mean bummap |
| 15:49.48 | clock_ | I mean like if I want to render say a soda can |
| 15:49.58 | brlcad | clock_: yes, and if you look at the edge of something that has a bump map, it's got a nice non-bumpy smooth edge |
| 15:50.00 | clock_ | the soda can is cylinder and they printed something on that using offset print |
| 15:50.11 | clock_ | the soda can is not wrinkled in any way |
| 15:50.49 | clock_ | or I want to render a room that has a mural (painting) on a wall |
| 15:51.00 | clock_ | then I want pixmap and not bumpmap, right? |
| 15:51.24 | brlcad | you'd generally want both for the visual effect |
| 15:51.51 | brlcad | or actually model the paint if you're going to do it "right" in a solid modeling realm |
| 15:52.12 | clock_ | you mean like simulating the fact that the paint adds thickness to the object? |
| 15:53.08 | clock_ | That's how I modeled a smoke flue that is painted black inside and white outside |
| 15:53.09 | brlcad | shaders are just visual effects, mostly "fake" per-se .. if you care about the actual material properties of even something like paint, you'd give it a physical representation and model it |
| 15:53.15 | clock_ | 0.5mm thin and 0.1mm paint inside |
| 15:53.19 | clock_ | thin -> tin |
| 15:54.05 | clock_ | but that's a bit tedious process when it's not just a whole surface painted but I want a Ronja logo on it |
| 15:54.13 | clock_ | then I could use the pixmap instead, couldn't I? |
| 15:54.27 | brlcad | you can generate geometry from pixmaps |
| 15:54.48 | brlcad | similar to how the circuitry was modeled in the principles book |
| 15:55.24 | brlcad | at least I think it covered the circuitry modeling.. that was how it was done regardless |
| 15:55.46 | brlcad | in general, solid modeling is tedious ;) |
| 15:56.26 | clock_ | I wouldn't say |
| 15:56.38 | clock_ | after I learned the meaning of the matrix |
| 15:57.01 | brlcad | the tool(s) hopefully make it less tedious, but the goal of getting something that is physically accurate (instead of just visually accurate or "close enough") generally requires providing a lot of detail that you wouldn't intuitively think you'd need sometimes but you do |
| 15:57.15 | clock_ | cxsx cxsy cxsz cx+= cysx cysy cysz cy+= czsx czsy czsz cz+= 0 0 0 1 |
| 15:57.45 | clock_ | I don't use the click-click rotations and shifts anymore, I enter the matrices directly in vi and it's fast to model |
| 15:58.36 | brlcad | that's good, but is that more the efficiency of vi or the deficiency of mged? I'd say it's more the latter |
| 15:58.59 | clock_ | I use mged only for rotations that are not multiple of 90deg |
| 15:59.04 | brlcad | although that particular feature of using an external text editor to modify matrices is in mged too |
| 15:59.06 | clock_ | which is say 1% of the model |
| 15:59.19 | clock_ | I would appreciate if I didn |
| 15:59.24 | clock_ | t have to type the trailing 0 0 0 1 |
| 15:59.47 | clock_ | I made a file /home/clock/m containing 1 0 0 0 0 1 0 0 0 0 1 0 0 0 0 1 and that's a highly valuable tool :) |
| 16:00.05 | clock_ | in vi I type :r ~/m and I have a matrix and then I edit one number and I am happy :) |
| 16:00.48 | clock_ | Is it allowed to use tabs instead of spaced in red? |
| 16:01.35 | brlcad | clock_: if you have your EDITOR var set before running mged, give 'red object.r' a try |
| 16:01.51 | clock_ | I am using red object.r |
| 16:02.03 | brlcad | ah, okay |
| 16:02.37 | brlcad | tabs should work fine, I think it's any whitespace |
| 16:02.37 | clock_ | plus the green axes are also invaluable :) |
| 16:02.50 | brlcad | if not that'd be stupid and would be trivial to fix |
| 16:03.05 | clock_ | can I even split the line into multiple ones - using \n as whitespace? |
| 16:03.20 | brlcad | that's what I mean, I believe so .. |
| 16:03.28 | clock_ | wow that's cool :) |
| 16:03.36 | brlcad | if it doesn't work, let me know and I'll fix it |
| 16:03.41 | brlcad | but it certainly "should" |
| 16:04.04 | brlcad | pretty sure it used to work that way |
| 16:04.07 | clock_ | Then I put the matrix tab-separated on 4 lines |
| 16:04.40 | clock_ | is it possible to easily patch the red so it puts the matrix there even if it's a unit matrix? |
| 16:16.19 | clock_ | brlcad: I think with your information I will be able to generate a picture correctly where the colours of the pixmap are not deformed |
| 16:16.41 | clock_ | so it would look like the assumed physical reality |
| 16:25.29 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/src/mged/red.c: even if the matrix is an identity matrix, print it so that the user has a starting point. add a comment about using red with a read-only db. |
| 16:25.55 | clock_ | wow :) |
| 16:26.19 | clock_ | can you make the matrix to be formatted with tabs and spread over 4 lines and indented by 1 tab? |
| 16:26.24 | clock_ | Then it would be even easier to edit |
| 16:26.38 | clock_ | and now when can I downloaded this CVS brlcad? |
| 16:26.45 | clock_ | when -> where? |
| 16:37.26 | brlcad | have to make sure multiline works first |
| 16:37.37 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/src/mged/red.c: massive ws cleanup, make braces consistently match hacking style |
| 16:41.27 | clock_ | I have a complicated model of almost whole Ronja installation |
| 16:41.31 | clock_ | http://ronja.twibright.com/3d/ |
| 16:41.47 | clock_ | some of the files can be termporarily incomplete/empty/absent because I am rsyncing at the moment |
| 16:42.19 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/TODO: libbu routine to make a temp file reliably/consistently |
| 16:42.39 | clock_ | look for "ronja" keyword |
| 16:42.51 | clock_ | actually the manpage of rsync suggests that rsync should be pretty atomic. |
| 16:43.07 | clock_ | so don't worry :) |
| 16:53.12 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/src/mged/red.c: restructure file so that the function declarations can go away. |
| 17:35.32 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/src/librt/Makefile.am: |
| 17:35.32 | CIA-5 | BRL-CAD: while convenient and would otherwise be usefule, you can't reliably use '+=' |
| 17:35.32 | CIA-5 | BRL-CAD: operator on automake variables without requiring more current versions of |
| 17:35.32 | CIA-5 | BRL-CAD: automake be installed (which we don't) so instead set a var and use accordingly |
| 17:40.08 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/TODO: add configure support for enabling/disabling framebuffers, display managers, image converters, and geometry converters |
| 18:11.27 | ``Erik | "download this cvs brlcad"? |
| 18:11.43 | ``Erik | read the cvs instructions at http://sourceforge.net/projects/brlcad |
| 18:12.02 | ``Erik | namely, http://sourceforge.net/cvs/?group_id=105292 |
| 18:13.49 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/src/other/openNURBS/Makefile.am: |
| 18:13.49 | CIA-5 | BRL-CAD: also do not need the openNURBS wrapper functions zcalloc() and zcfree() since |
| 18:13.49 | CIA-5 | BRL-CAD: we're just letting zlib do it's own thing. compiling them in results in |
| 18:13.49 | CIA-5 | BRL-CAD: multiple symbol definitions (and link errors) on os x at link time. now links. |
| 18:27.34 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/autogen.sh: remove more previous build products, now including aclocal.m4 too |
| 18:59.23 | *** join/#brlcad clock_ (i=clock@84-72-61-62.dclient.hispeed.ch) |
| 19:40.19 | CIA-5 | BRL-CAD: 03erikgreenwald * 10brlcad/ (configure.ac include/common.h): only include brlcad_config.h if actually building BRL-CAD. Prevents preprocessor redefinition warnings for things like PACKAGE. (this is the first step towards a cleaning activity). |
| 19:55.13 | ``Erik | 'thoom' |
| 19:56.22 | clock_ | We have a wind here in Europe |
| 19:56.30 | clock_ | with an online bodycount |
| 19:58.08 | CIA-5 | BRL-CAD: 03erikgreenwald * 10brlcad/misc/ (32 files in 32 dirs): define the BRLCADBUILD preprocessor symbol |
| 20:27.37 | Maloeran | http://news.bbc.co.uk/2/hi/technology/6270657.stm Good news, but I especially like the picture :) |
| 20:36.39 | ``Erik | hm, yeah, gccisms |
| 20:36.44 | ``Erik | __attribute__ is very gcc |
| 20:37.33 | ``Erik | -std=c99, too |
| 20:38.16 | Maloeran | If you disable SSE support, I don't think there will be many __attribute__ left |
| 20:38.39 | ``Erik | heh, the notion is hardly gcc specific... gcc's implementation is just radically unlike everyone elses... |
| 20:38.46 | ``Erik | very... linuxy, that way... kinda microsofty |
| 20:39.38 | ``Erik | (though much cleaner than the usual #pragma mechanism) |
| 20:41.59 | Maloeran | It's clean enough, it could be abstracted through some #define ALIGNED __attribute__((aligned(16))) if you want |
| 20:43.01 | ``Erik | blows up good on gcc2.95 heh |
| 20:43.20 | Maloeran | Really? Surprising |
| 20:44.36 | ``Erik | 'const restrict' seems to confuse it |
| 20:44.58 | Maloeran | Non-sense, restrict is c99 and that's perfectly valid |
| 20:46.37 | ``Erik | ... gcc 4.2 probably doesn't implement c99 perfectly, and this irix box has gcc 2.95 on it... |
| 20:46.43 | ``Erik | ./RF/graph.h:47: parse error before `elem' |
| 20:47.19 | Maloeran | Then it doesn't understand "restrict", perhaps it just doesn't support C99 |
| 20:47.49 | ``Erik | oh, wait, there it is, hah |
| 20:47.53 | ``Erik | cc1: unknown C standard `gnu99' |
| 20:48.22 | Maloeran | Woohoo. Okay, gcc >=3.x is required |
| 21:04.59 | *** join/#brlcad iday (n=iday@c-68-50-191-200.hsd1.md.comcast.net) |
| 21:09.42 | CIA-5 | BRL-CAD: 03lbutler * 10brlcad/src/gtools/g_qa.1: Added documentation for -t option. |
| 21:10.19 | ``Erik | it's just gettin' to be that time of day |
| 21:12.38 | iday | finally got the $%^& pro-e converter running under linux |
| 21:13.15 | dtidrow_work | hehy |
| 21:13.24 | dtidrow_work | heh, rather... |
| 21:14.45 | iday | 'course now I need to remove the inappropriate debugging comments... |
| 21:16.34 | brlcad | sorted out the makefile crap in src/external/ProEngineer/mk.in ? |
| 21:16.43 | iday | heh - not exactly |
| 21:16.44 | iday | :-) |
| 21:16.58 | iday | but I should - to make it easier to repeat ;-) |
| 21:17.49 | brlcad | really needs a --with-proe flag so you can specify where ptc's junk is installed |
| 21:18.46 | iday | yes - I'd like to get it automake-ified - but that's more work than I'm gonna do today... |
| 21:19.13 | iday | pro/e has eaten up my supply of patience (around 0900 this morning) |
| 21:19.38 | brlcad | woke up at 5am for some reason today |
| 21:19.42 | brlcad | i'm starting to pay for it |
| 21:19.46 | iday | ewwww |
| 21:23.52 | brlcad | iday: something weird about your sf account .. it doesn't send e-mails for you when you commit |
| 21:23.59 | brlcad | does it dump any errors? |
| 21:24.30 | ``Erik | iday == jay-lo? |
| 21:36.03 | *** join/#brlcad clock_ (i=clock@84-72-61-62.dclient.hispeed.ch) |
| 22:18.28 | CIA-5 | BRL-CAD: 03erikgreenwald * 10brlcad/src/adrt/ (24 files in 6 dirs): uppercase all #define symbols |
| 22:50.00 | *** join/#brlcad rusito (n=c9e627f4@bz.bzflag.bz) |
| 22:51.55 | *** join/#brlcad IriX64 (n=IriX64@bas3-sudbury98-1168050276.dsl.bell.ca) |
| 23:33.47 | *** join/#brlcad IriX64 (n=IriX64@bas3-sudbury98-1168050276.dsl.bell.ca) |