| 00:07.07 | IriX64 | http://www.pastebin.ca/385645 < heres last weeks effort :) |
| 00:09.53 | Maloeran | So you decided to start coding then! Nice, C language? |
| 00:10.00 | IriX64 | am i going to have to go through hoops to find the thread limit on this thing? in os2 you could set your limit up to the max 4095 in config.sys. |
| 00:10.10 | IriX64 | yes C |
| 00:11.21 | Maloeran | There might be no limit but the available system memory |
| 00:12.15 | IriX64 | true, would be nice to know for sure though ie instead of program bombing out. |
| 00:12.32 | Maloeran | You never want to get anywhere near that limit |
| 00:12.53 | Maloeran | Normally, you should have one thread per processor core, perhaps up to a few per core if doing intense socket I/O |
| 00:13.04 | IriX64 | should still know though so you can avoid getting near it. |
| 00:15.05 | *** join/#brlcad DarkMaster (n=Matthew@c-69-138-68-160.hsd1.md.comcast.net) |
| 00:15.06 | IriX64 | would be nice if the system had a threshold detewctor, saying something like goof, threads near saturation. :) |
| 00:16.03 | Maloeran | Not quite.. Get count of processors and launch the same count of threads, any piece of software with hundreds of threads is broken |
| 00:16.19 | Maloeran | ( Unless running on some Altix machine, etc. ) |
| 00:16.58 | IriX64 | 100's i opened up 1024 threads on a single core pentium 100 and it ran fine and system still responded beautifulluy. |
| 00:18.01 | Maloeran | Yes, and it's wrong |
| 00:18.10 | Maloeran | You lose performance for no reason |
| 00:18.54 | IriX64 | this was an app that was designed to use threads, there was no great system impact most of the threads were sitting in a wait for something loop. |
| 00:21.10 | IriX64 | can use semaphores to signal, here's your something if you prefer. |
| 00:47.29 | ``Erik | actually, setting the # of threads to be equal to the number of cores can seriously degredate performance on many kinds of apps.. having one more or less is often better... personally, I'm kinda down with 2n-1 for most shtuff |
| 00:47.52 | ``Erik | and there're plenty of good reasons to super-saturate a system with processes or threads... hundres of thousands, millions, even... |
| 00:48.09 | ``Erik | great way to stress the OS if you're working on improving the kernels scheduling or IPC facilities :D |
| 00:48.43 | DarkMaster | i have millions of threads in my shirt :-D |
| 00:53.48 | ``Erik | speaking of straining OS's, time to download haiku, yo |
| 00:54.21 | brlcad | muahaha.. and the fun begins |
| 00:56.11 | Maloeran | Erik, it trashes the cache of the processors, but it's of course a different business when threads are waiting for I/O |
| 00:56.30 | Maloeran | May it be disk I/O for compilation or network I/O for server software |
| 00:56.49 | Maloeran | For pure number crunching, it's really preferable to have exactly one thread per processor core |
| 00:58.49 | Maloeran | Speaking of which... If you were ever wondering, the only reason why the model graph prep isn't scaling with threads is due to the abuse of a global memory mutex for all alloc/free ; I really need to revise my memory manager to work properly with threads and NUMA |
| 00:59.48 | brlcad | if your app is a kernel (whether a userland behemouth or an actual OS kernel), it can be perfectly expected that the threads will have nothing to do with each other, yet there may be N unrelated tasks and only M cores to run them on (where N > M, and N corresponds to at least one thread or process) |
| 01:00.06 | brlcad | the same that holds true in kernel space holds for certain apps too |
| 01:01.02 | Maloeran | Right, I'm assuming that other processes are fairly light in processing time |
| 01:02.13 | Maloeran | Having processes migrate from one core to another seriously harms performance, and it doesn't work too well with proper management of NUMA |
| 01:09.11 | ``Erik | depends on the memory usage of the process... you assume a certain hw usage pattern for that statement... happens to be one appropriate for raytracing... :D |
| 01:10.24 | Maloeran | I'm assuming number crunching software, not I/O software |
| 01:15.06 | ``Erik | if the working data set is very small and pushed out to sysmem fairly often, then a migration will barely hurt... *shrug* |
| 01:17.02 | Maloeran | It's not negligeable, and the "sysmem" might be a memory bank specific to the core the thread was running on |
| 01:17.42 | Maloeran | It's terrible to have a thread running on a different core than the set of cores associated with the memory bank where the thread's stack is |
| 01:18.27 | ``Erik | that totally depends on the architecture, and is a numa specific layout... (which hypertransport is a 'mini-numa' as far as I can tell, so opterons suffer it) |
| 01:18.59 | Maloeran | Linux doesn't easily migrate threads over to a different die than the one that contains the stack memory |
| 01:19.32 | Maloeran | I think it may temporarily do that under bad stress patterns, but execution will tend to stick to the prefered processor die |
| 01:21.36 | ``Erik | slowaris is the same way... neat thing about solaris is that you have tools to attach a thread to a core forcefully (so it CANNOT migrate it off, short of a hotswap cpu being pulled) as well as dedicating a core to a process o.O |
| 01:22.02 | Maloeran | *nods* You have that on Linux as well |
| 01:23.38 | ``Erik | bsd has stronger processor and memory associativity, yes. |
| 01:23.52 | ``Erik | I've said that before :) one of these days, I'll fix fbsd... |
| 01:24.12 | DarkMaster | i was tempted to try PC BSD |
| 01:24.28 | ``Erik | (and it's fbsd, I d'no netbsd or openbsd's guts.... I do know that dragonfly was forked because matt said fbsd was being insanely retarded wrt multiprocessor shtuff |
| 01:24.29 | ``Erik | ) |
| 01:31.09 | *** join/#brlcad IriX64 (n=mario_du@bas3-sudbury98-1168050142.dsl.bell.ca) |
| 01:46.57 | ``Erik | huh, vim is in the haiku source |
| 01:51.13 | ``Erik | hum, the dude from 'make magazine' is on colbert report |
| 01:57.39 | ``Erik | no, heh |
| 01:58.05 | ``Erik | http://www.makezine.com/magazine/ |
| 01:58.49 | ``Erik | http://www.makezine.com/ hah |
| 02:01.35 | Maloeran | I think I have some cultural knowledge gaps preventing me to appreciate this |
| 02:24.42 | IriX64 | nice cat |
| 02:25.25 | ``Erik | neato, on my hackintop, everything seems to build but asc2g craps itself in the db/ dir, nifty |
| 02:26.21 | IriX64 | btw thanks for reminding me, dxf-g works, i got a hold of a shuttle dxf (not the acad one) and it converted and rt'ed |
| 02:27.12 | Twingy | I got more r/c shit than I know what to do with now |
| 02:27.55 | Twingy | I've been spending money like it's going out of style |
| 02:34.46 | ``Erik | DEY TUK R JRBS! |
| 02:34.54 | ``Erik | the 'gooback' episode is on o.O |
| 02:34.57 | ``Erik | new episode after it |
| 02:37.43 | Twingy | good episode |
| 02:37.53 | Twingy | I have the firewall on the demon plane |
| 02:38.00 | Twingy | and the t-nuts for the wing bolts |
| 02:38.22 | Twingy | all it needs is some towerkote applied and an engine mounted plus servos installed |
| 02:38.39 | Twingy | and I just happened to have a pair of OS 0.46 LA's not in use |
| 02:39.18 | Twingy | I think I'm going out saturday or sunday weather permitting and flying both planes |
| 02:40.10 | DarkMaster | hey Twingy |
| 02:40.59 | IriX64 | cd ../ |
| 02:41.07 | Twingy | directory not found |
| 02:41.26 | PrezKennedy | C:\WINDOWS> |
| 02:41.28 | IriX64 | heh |
| 02:41.37 | IriX64 | c:\os1/2 |
| 02:42.07 | PrezKennedy | i love windows |
| 02:42.24 | PrezKennedy | keeps the paycheck coming in |
| 02:42.28 | PrezKennedy | only reason |
| 02:42.29 | PrezKennedy | :-) |
| 02:43.05 | IriX64 | mmmmm signature on the check is Bill Gates? |
| 02:43.36 | Twingy | no.. just some tard that thinks windows is awesome |
| 02:43.56 | IriX64 | heh its common, just like mud :P |
| 02:44.04 | PrezKennedy | more of a necessity :( |
| 02:44.20 | PrezKennedy | construction company software BARELY runs on it |
| 02:44.40 | IriX64 | hello world barely runs on it :) |
| 02:45.10 | PrezKennedy | im apathetic long as it works when im using it |
| 02:45.43 | IriX64 | they blew it when they split with IBM. |
| 02:51.40 | IriX64 | gotta go, life calls |
| 04:57.00 | brlcad | PrezKennedy: interesting.. what kind of software? |
| 04:57.38 | brlcad | you could implement the features they need in brl-cad then get them to use that instead, then platform could be anything |
| 04:58.11 | PrezKennedy | haha i saw that coming ;-) |
| 04:58.35 | PrezKennedy | its not the CAD program thats the problem... its the accounting programs and bidding software |
| 04:59.15 | brlcad | hey, "we are borg" .. they could be assimilated too |
| 04:59.48 | PrezKennedy | sounds like emacs |
| 04:59.59 | brlcad | measily accounting programs and bidding software could be directly tied to the construction workflow in the same interface |
| 05:00.20 | brlcad | i bet they pay a pretty penny for that software too |
| 05:00.45 | PrezKennedy | youd win that bet |
| 05:01.24 | PrezKennedy | NOT cheap |
| 05:01.25 | PrezKennedy | :-) |
| 05:01.35 | brlcad | so you reinvent their workflow, save them them 100's of k's per year in overhead and process efficiency (by custom tailoring the interface to the workflow) |
| 05:01.46 | brlcad | before you know it, you'll be VP in charge of IT |
| 05:02.18 | PrezKennedy | i dont wanna be in charge of IT... WAY too stressful a job |
| 05:02.47 | brlcad | so then just be a highly-paid consultant forever ;) |
| 05:02.56 | PrezKennedy | haha |
| 06:13.02 | CIA-7 | BRL-CAD: 03brlcad * 10brlcad/src/proc-db/brep_cube.cpp: allow the procedural example to compile with or without OBJ_BREP, just provide a stubbed run-time error message. |
| 06:21.13 | CIA-7 | BRL-CAD: 03brlcad * 10brlcad/src/proc-db/Makefile.am: restructure the proc-db compilations since they all pretty much need the same libraries. also, minimize all the conditionality around brep_cube so it only toggles whether OBJ_BREP is set or not. |
| 06:54.54 | CIA-7 | BRL-CAD: 03brlcad * 10brlcad/src/librt/g_brep.cpp: |
| 06:54.54 | CIA-7 | BRL-CAD: use []'s instead of .at() for portability.. and with that minor edit, g_brep |
| 06:54.54 | CIA-7 | BRL-CAD: actually compiles under irix (gcc) now. the header b0rkage from a couple weeks |
| 06:54.54 | CIA-7 | BRL-CAD: ago is apparently /dev/null'd through all the rewrites and changes |
| 07:06.03 | CIA-7 | BRL-CAD: 03brlcad * 10brlcad/src/ (33 files in 33 dirs): (log message trimmed) |
| 07:06.03 | CIA-7 | BRL-CAD: whoosh! push BU, BN, and RT (and maybe one or two others) out of library LIBADD |
| 07:06.04 | CIA-7 | BRL-CAD: declarations down to application LDADD linkage. this means that there might be |
| 07:06.04 | CIA-7 | BRL-CAD: issues to solve again towards being able to generate fully contained/resolved |
| 07:06.04 | CIA-7 | BRL-CAD: libraries (e.g. frameworks), but solves the current problem of linking against |
| 07:06.06 | CIA-7 | BRL-CAD: static tcl/tk libraries portably. duplicate symbols become a problem at link |
| 07:06.08 | CIA-7 | BRL-CAD: time (bu, bn, and rt all use tcl). pushing the link specification all the way |
| 09:29.53 | CIA-7 | BRL-CAD: 03d_rossberg * 10brlcad/ (5 files in 3 dirs): since basename was removed from libsysv we do not need strlcpy any more |
| 11:02.54 | *** join/#brlcad docelic (n=docelic@212.15.174.135) |
| 13:44.11 | CIA-7 | BRL-CAD: 03brlcad * 10brlcad/src/conv/g-xxx.c: c89 support, declare functions first |
| 13:48.09 | CIA-7 | BRL-CAD: 03brlcad * 10brlcad/src/canon/Makefile.am: need PKG for FB |
| 14:40.55 | ``Erik | wtf |
| 15:13.51 | CIA-7 | BRL-CAD: 03erikgreenwald * 10brlcad/src/ (5 files in 5 dirs): missing libs from the "whoosh" |
| 15:26.26 | CIA-7 | BRL-CAD: 03erikgreenwald * 10brlcad/src/proc-db/Makefile.am: Missing CFLAGS (tcl/generic). Missing libs. Whoosh. |
| 15:26.41 | CIA-7 | BRL-CAD: 03erikgreenwald * 10brlcad/src/ (rttherm/Makefile.am util/Makefile.am): missing libs from the "whoosh" |
| 15:35.57 | *** join/#brlcad Twingy (n=justin@74.92.144.217) [NETSPLIT VICTIM] |
| 15:51.05 | brlcad | you realize that you added pkg twice to most of the bin's in util/ |
| 15:54.35 | CIA-7 | BRL-CAD: 03brlcad * 10brlcad/TODO: tcl/tk have been updated now |
| 15:55.41 | CIA-7 | BRL-CAD: 03brlcad * 10brlcad/TODO: mged now finds its resources more reliably at run-time with the auto_path updates in tclcadAutoPath.c |
| 16:03.01 | *** join/#brlcad Elperion (n=Elperion@p54874A0E.dip.t-dialin.net) |
| 16:04.06 | ``Erik | woops, I did? |
| 16:04.45 | brlcad | likes like a global replace on /{FB}/{FB} ${PKG}/ |
| 16:05.04 | brlcad | where most already had PKG |
| 16:05.38 | brlcad | actually, i think binfo was the only one that didn't and probably needed it |
| 16:06.07 | ``Erik | several broke, I think maybe it was ordering? |
| 16:06.58 | CIA-7 | BRL-CAD: 03erikgreenwald * 10brlcad/src/util/Makefile.am: remove dup ${PKG} entries, keeping "friendly" link order |
| 16:08.38 | ``Erik | bw-png, bw-a, that's probable where I did a s/re/rs/ |
| 16:10.07 | brlcad | mebbie, though FB is the only one that comes to mind as using PKG |
| 16:10.41 | ``Erik | libfb is the one that bitches *shrug |
| 16:10.42 | brlcad | oh yeah, and fyi .. it will link and run against a system tcl/tk now .. but there's a problem with incrTcl if the versions don't match |
| 16:11.06 | brlcad | i ran a test last night and it'll even fire up mged console (while bitching about incr) |
| 16:11.08 | ``Erik | hm, so any old tcl8.5 is groovy? |
| 16:11.15 | brlcad | it should |
| 16:11.43 | brlcad | incrTcl has a run-time check to make sure the tcl/tk loaded matches the header it finds (which is our 8.5 sources) |
| 16:49.53 | *** join/#brlcad IriX64 (n=mario_du@bas3-sudbury98-1168050142.dsl.bell.ca) |
| 16:50.33 | IriX64 | http://www.pastebin.ca/386448 <-- opening a new database and trying to create a metaball results in this, (twice) |
| 16:51.42 | IriX64 | know npot what to do here. |
| 16:51.47 | IriX64 | err not |
| 16:57.16 | IriX64 | now mi created an ars, then tried a meta ball, same result. |
| 17:01.25 | IriX64 | urf, even trying to do it in an existing database, this must be my stuff? |
| 17:50.36 | *** join/#brlcad docelic (n=docelic@212.15.174.135) |
| 18:21.10 | *** join/#brlcad clock_ (i=clock@84-72-89-40.dclient.hispeed.ch) |
| 18:37.57 | *** join/#brlcad Elperion (n=Elperion@p54874A0E.dip.t-dialin.net) |
| 18:39.06 | ``Erik | heh |
| 18:39.38 | ``Erik | <-- been working on fixing the metaball crap... needs to quit doing a cvs update, cuz he ends up having to fix stuff every freakin' time O.o |
| 18:48.46 | CIA-7 | BRL-CAD: 03brlcad * 10brlcad/src/mged/anal.c: by request from Dwayne Kregel and others, increase precision of the analyze command output from 3 or 4 points after decimal to 8. |
| 18:49.07 | IriX64 | heh |
| 18:49.35 | IriX64 | #define no_metaballs_allowed. ;) |
| 18:52.44 | CIA-7 | BRL-CAD: 03brlcad * 10brlcad/ (NEWS TODO): increased output precision on mged 'analyze' command, by request from Dwayne Kregel and friends for their modeling purposes. |
| 18:54.03 | brlcad | whine whine cheese cheese .. this is all release prep -- as soon as it's green across the board, a release is going up |
| 19:23.18 | CIA-7 | BRL-CAD: 03brlcad * 10brlcad/src/librt/Makefile.am: restructure brep compilation so that it uses the new SSE flags from configure, distinguish between cflags and cppflags. |
| 19:25.26 | CIA-7 | BRL-CAD: 03erikgreenwald * 10brlcad/src/librt/g_metaball.c: shift segment to fix method bug |
| 19:27.08 | CIA-7 | BRL-CAD: 03erikgreenwald * 10brlcad/src/mged/edsol.c: update metaball solid editing to follow pipe semantics (fixes a few crashes) |
| 19:29.34 | clock_ | brlcad: I have a .g file on which g-dxf -r 0.5 pours some internal inconsistency messages and then tries to continue and segfaults |
| 19:30.24 | clock_ | db_walk_subtree() FAIL on '/ronja1/head_holder1/head_assembled1.g/head1/flange1/ |
| 19:30.25 | clock_ | flange.s' |
| 19:30.25 | clock_ | db_walk_subtree() FAIL on '/ronja1/head_holder1/head_assembled1.g/head1/flange1/ |
| 19:30.25 | clock_ | heel_holes_upper.c/hole_6.5.s' |
| 19:30.25 | clock_ | db_walk_subtree() FAIL on '/ronja1/head_holder1/head_assembled1.g/head1/flange1/ |
| 19:30.27 | clock_ | heel_holes_upper.c/hole_6.5.s' |
| 19:30.30 | clock_ | db_walk_subtree() FAIL on '/ronja1/head_holder1/head_assembled1.g/head1/flange1/ |
| 19:30.32 | clock_ | heel_holes_upper.c/hole_6.5.s' |
| 19:30.34 | clock_ | db_walk_subtree() FAIL on '/ronja1/head_holder1/head_assembled1.g/head1/flange1/ |
| 19:30.38 | clock_ | heel_holes_upper.c/hole_6.5.s' |
| 19:30.40 | clock_ | db_walk_subtree() FAIL on '/ronja1/head_holder1/head_assembled1.g/head1/flange1/ |
| 19:30.42 | clock_ | heel_holes_upper.c/hole_6.5.s' |
| 19:30.45 | clock_ | db_walk_subtree() FAIL on '/ronja1/head_holder1/head_assembled1.g/head1/flange1/ |
| 19:30.47 | clock_ | flange.s' |
| 19:30.50 | clock_ | db_walk_subtree() FAIL on '/ronja1/head_holder1/head_assembled1.g/head1/flange1/ |
| 19:30.52 | clock_ | heel_holes_upper.c/hole_6.5.s' |
| 19:30.55 | clock_ | db_walk_subtree() FAIL on '/ronja1/head_holder1/head_assembled1.g/head1/flange1/ |
| 19:30.57 | clock_ | heel_holes_upper.c/hole_6.5.s' |
| 19:31.00 | clock_ | db_walk_subtree() FAIL on '/ronja1/head_holder1/head_assembled1.g/head1/flange1/ |
| 19:31.02 | clock_ | heel_holes_upper.c/hole_6.5.s' |
| 19:31.05 | clock_ | db_walk_subtree() FAIL on '/ronja1/head_holder1/head_assembled1.g/head1/flange1/ |
| 19:31.08 | clock_ | heel_holes_upper.c/hole_6.5.s' |
| 19:31.10 | clock_ | db_walk_subtree() FAIL on '/ronja1/head_holder1/head_assembled1.g/head1/flange1/ |
| 19:31.13 | clock_ | heel_holes_upper.c/hole_6.5.s' |
| 19:31.15 | clock_ | (then 2 pages of normal output) |
| 19:31.18 | clock_ | and finally: |
| 19:31.20 | clock_ | Segmentation fault (core dumped) |
| 19:31.32 | clock_ | #0 db_free_tree (tp=0x86386ca0, resp=0x3c0039d0) at db_tree.c:1500 |
| 19:31.32 | clock_ | 1500 db_tree.c: No such file or directory. |
| 19:31.32 | clock_ | <PROTECTED> |
| 19:31.32 | clock_ | (gdb) bt full |
| 19:31.32 | clock_ | #0 db_free_tree (tp=0x86386ca0, resp=0x3c0039d0) at db_tree.c:1500 |
| 19:31.34 | clock_ | <PROTECTED> |
| 19:31.37 | clock_ | #1 0x1c001a4b in do_region_end (tsp=0x81a4c204, pathp=0x81a4c2f8, curtree=0x86386ca0, client_data=0x0) at g-dxf.c:1004 |
| 19:31.40 | clock_ | <PROTECTED> |
| 19:31.42 | clock_ | <PROTECTED> |
| 19:31.45 | clock_ | <PROTECTED> |
| 19:31.47 | clock_ | <PROTECTED> |
| 19:31.50 | clock_ | <PROTECTED> |
| 19:31.52 | clock_ | #2 0x021a9b7d in db_walk_dispatcher (cpu=-2119908860, arg=0xcf7f9270) at db_tree.c:2198 |
| 19:31.55 | clock_ | <PROTECTED> |
| 19:31.58 | clock_ | <PROTECTED> |
| 19:32.00 | clock_ | <PROTECTED> |
| 19:32.03 | clock_ | #3 0x021aa1ec in db_walk_tree (dbip=0x89d7d000, argc=1, argv=0xcf7f9388, ncpu=1, init_state=0x3c003b80, reg_start_func=0, reg_end_func=0x7c90e060, leaf_func=0x7c90e060, client_data=0x0) |
| 19:32.07 | clock_ | <PROTECTED> |
| 19:32.10 | clock_ | <PROTECTED> |
| 19:32.12 | clock_ | <PROTECTED> |
| 19:32.15 | clock_ | <PROTECTED> |
| 19:32.19 | clock_ | <PROTECTED> |
| 19:32.23 | clock_ | <PROTECTED> |
| 19:32.26 | clock_ | <PROTECTED> |
| 19:32.29 | clock_ | <PROTECTED> |
| 19:32.31 | clock_ | <PROTECTED> |
| 19:32.34 | clock_ | <PROTECTED> |
| 19:32.37 | clock_ | <PROTECTED> |
| 19:32.39 | clock_ | <PROTECTED> |
| 19:32.42 | clock_ | <PROTECTED> |
| 19:32.44 | clock_ | <PROTECTED> |
| 19:32.47 | clock_ | <PROTECTED> |
| 19:32.49 | clock_ | <PROTECTED> |
| 19:32.53 | clock_ | <PROTECTED> |
| 19:32.56 | clock_ | <PROTECTED> |
| 19:32.58 | clock_ | #4 0x1c0014bb in main (argc=2, argv=0x89d7d000) at g-dxf.c:517 |
| 19:33.01 | clock_ | <PROTECTED> |
| 19:33.04 | clock_ | <PROTECTED> |
| 19:33.06 | clock_ | <PROTECTED> |
| 19:33.09 | clock_ | And that's BRL-CAD 7.8.4 - the latest |
| 19:33.28 | Maloeran | Hrm. Post that in rafb.net/paste, it might be more usable by brlcad/Erik |
| 19:33.59 | ``Erik | or lisp.paste.org or pastebin.ca or ... |
| 19:38.41 | IriX64 | clock_: whered the .g file come from? your creation or asc2g? or....? |
| 19:39.06 | clock_ | My creation |
| 19:39.32 | IriX64 | and you're using dxf2g? |
| 19:40.15 | IriX64 | err g2dxf? |
| 19:40.28 | *** join/#brlcad cad38 (n=803f204c@bz.bzflag.bz) |
| 19:42.02 | IriX64 | its telling you the line number, 517. |
| 19:42.19 | IriX64 | in g-dxf.c |
| 19:45.45 | clock_ | g-dxf or hows the program called |
| 19:58.11 | CIA-7 | BRL-CAD: 03erikgreenwald * 10brlcad/src/librt/g_metaball.c: tweak the point eval formula a tiny bit to allow negative points |
| 20:00.40 | IriX64 | nmg_booltree_leaf_tees, that part clock_ ? |
| 20:00.53 | IriX64 | tess. |
| 21:50.23 | *** join/#brlcad docelic (n=docelic@212.15.174.135) |
| 22:39.11 | *** join/#brlcad bjorkBSD (n=bjork@ip70-178-209-107.ks.ks.cox.net) |
| 23:24.44 | *** join/#brlcad PrezKennedy (n=Matthew@c-69-138-68-160.hsd1.md.comcast.net) |