| 00:00.21 | Flash | my point was merely to ask if this principle was understood and applied as a general practice |
| 00:00.53 | randomparticle | i want maximum separation of renderer and geometry handler |
| 00:00.58 | Flash | randomparticle: do you mean objective-C or object? |
| 00:01.05 | brlcad | Flash: pretty sure *all* of the core devs are aware of or have heard of the principle at some point |
| 00:01.06 | randomparticle | objective-C |
| 00:02.15 | brlcad | other contributors, i'm sure the exposure varies.. that's a into to programming c++ topic |
| 00:02.15 | randomparticle | but the situation may arise in C++ too, though i'm not sure about that |
| 00:02.15 | Flash | randomparticle: memory management must be diligently applied |
| 00:02.15 | brlcad | whether it's upheld in a production code environment like bz depends on many many factors (some frankly don't care, especially if one of the others is actually NOT needed yet) |
| 00:02.18 | randomparticle | the problem with that malloc approach is that the caller needs to know implementation details about the instance |
| 00:02.28 | Flash | if a function returns an allocated resource, the caller must know his responsibility to release the resource |
| 00:02.46 | Flash | what implementation details? |
| 00:03.27 | randomparticle | well, it needs to know that the memory has been malloc'd. you wouldn't want it to try and free something it shouldn't |
| 00:03.39 | Flash | that's part of the interface contract |
| 00:03.39 | brlcad | Flash: as for applying the practice, I think you'll see some code that does and plenty that doesn't -- feel free to clean up if that's you're cup of tea |
| 00:03.48 | brlcad | refactoring for clean code is almost always a good thing |
| 00:03.59 | randomparticle | i guess so, but it's not something that is seen in the interface/header files |
| 00:04.04 | Flash | brlcad: yes, cleaning up code is a pet peeve of mine; just not sure how to partition for patches |
| 00:04.35 | brlcad | probably don't |
| 00:04.44 | randomparticle | i could ask for a vertex count first, and then get the caller to malloc an array of sufficient size |
| 00:04.46 | brlcad | code cleanup really needs commit access |
| 00:04.57 | Flash | randomparticle: one of the problems of dealing with pointers is knowing who owns them |
| 00:05.02 | brlcad | so just pester the folks that can to review your code ;) |
| 00:05.05 | randomparticle | but that's messy, because now there's one call for the count, and one to get the array |
| 00:05.37 | brlcad | mm.. enough trance music for now .. gah |
| 00:06.14 | randomparticle | i'm beginnning to wonder if i ever should have started it. the program worked perfectly fine before, but then i started worrying the code was not cleanly designed |
| 00:06.40 | Flash | randomparticle: does objective-C have something comparable to a C++ std::vector ? |
| 00:06.55 | randomparticle | i don't know enough C++ to answer that |
| 00:07.12 | Flash | does it have a container that has dynamic length? |
| 00:07.14 | randomparticle | it has something called an NSMutableArray |
| 00:07.39 | Flash | if you don't want to return, consider an out-argument |
| 00:07.58 | Flash | pass in the array, let your function populate it with the vertices |
| 00:08.08 | randomparticle | that's an array to contain arbitary objects and you don't have to worry about keeping track of its size |
| 00:08.51 | randomparticle | another approach, although inelegant, is to create a huge array, one that is never likely to be overfilled, and use that :) |
| 00:09.10 | Flash | inelegant and inefficient. That's what dynamic containers are for |
| 00:09.42 | brlcad | woot, asian pop |
| 00:09.57 | Flash | another approach (which I eschew) is to provide an iterator to a list of vertices maintained internally to your object |
| 00:10.11 | Flash | it exposes too much of your internals for my taste |
| 00:10.32 | randomparticle | yes, sounds a bit horrid |
| 00:10.40 | brlcad | Flash: sorry to repeat if someone already asked, but you have already read devinfo in full? |
| 00:10.51 | Flash | yes I have |
| 00:11.06 | randomparticle | i guess i might use one of these objc array objects. another layer of inefficiency :) |
| 00:12.41 | randomparticle | i worry a bit about the objective-c runtime overhead |
| 00:13.49 | randomparticle | a function call which is just a handful of machine instructions balloons into something like 50-200 executed instructions |
| 00:16.56 | brlcad | Flash: are you Linuxx0r |
| 00:17.03 | Flash | not really. I do Solaris for a living and have MacOS at home |
| 00:17.13 | Flash | oh... nickname... nope |
| 00:17.16 | brlcad | heh |
| 00:17.35 | brlcad | have you uploaded any patches yet? |
| 00:19.09 | Flash | yes... jwmelto |
| 00:19.24 | Flash | http://sourceforge.net/tracker/index.php?func=detail&aid=1619817&group_id=3248&atid=303248 |
| 00:19.27 | Guu` | Patch #1619817: Remove /ghost; Resolution: None; Date Submitted: 2006-12-20 17:00; Submitted By: Flash; Assigned To: Nobody/Anonymous; Priority: 5; Status: Open |
| 00:19.43 | brlcad | thanks |
| 00:20.49 | blast007 | heh, didn't know Guu could do that :) |
| 00:21.45 | brlcad | Guu` rocks |
| 00:21.46 | Guu` | Wish I knew, brlcad. |
| 00:21.51 | *** join/#bzflag master_tux (n=will@pool-71-99-7-205.tampfl.dsl-w.verizon.net) |
| 00:22.02 | Flash | lol |
| 00:26.34 | randomparticle | would i be mad to buy a mac pro now? :) |
| 00:26.52 | randomparticle | i know, leopard out soon.. maybe a mac pro update too |
| 00:27.25 | randomparticle | but.. i've been lusting after one of those machines for weeks now |
| 00:28.01 | CBG | randomparticle: how much would you spend on the mac pro if you bought one right now? |
| 00:28.28 | randomparticle | well, i'd probably go for the base spec + an extra 1gb ram |
| 00:28.31 | CBG | like... £2000 ? |
| 00:28.37 | randomparticle | ish |
| 00:28.45 | brlcad | Flash: interesting unrelated edits in the ghost patch.. |
| 00:28.57 | CBG | So, paying another £150 or whatever an OS upgrade is, in a few months, is nothing in comparison. |
| 00:28.58 | Flash | unrelated? |
| 00:29.11 | brlcad | they really should be separated |
| 00:29.19 | brlcad | yeah, you refactored the composition prompt |
| 00:29.20 | CBG | If you waited till 10.5 was out, you'd save what...? less than 10%... |
| 00:29.23 | randomparticle | i guess not. still, it's a bit of a waste |
| 00:29.52 | randomparticle | i'd be kicking myself if they brought out an octothingy soon after :) |
| 00:30.24 | CBG | Well, how much is the extra time with the mac pro worth ? |
| 00:30.26 | CBG | Oh, you're thinking about upcoming hardware upgrades too..? |
| 00:30.55 | Flash | I suppose... to me it was more straightforward (to make sure I didn't screw anything up) |
| 00:30.56 | randomparticle | if someone upgrades to leopard, will most of their old apps still work? e.g., ilife etc |
| 00:31.20 | Flash | there used to be a loop that depended on enum values as bounds (and ghost was the upper bound) |
| 00:31.27 | randomparticle | what happened in the past with other upgrades? |
| 00:31.28 | Flash | it was inherently brittle |
| 00:31.57 | randomparticle | i notice those apps don't come on the OS X installation disks that are sold separately |
| 00:31.58 | brlcad | you have a similar unrelated (major) chunk of code related to the message relay |
| 00:32.08 | a_meteorite | randomparticle: I still have apps from 10.2 and I'm on 10.4 |
| 00:32.27 | a_meteorite | I just transfer all my stuff over when a new Mac OS X comes out... :) |
| 00:32.30 | randomparticle | sounds promising then, if things work as before |
| 00:32.47 | brlcad | and i have to say that i'm not entirely fond of the .assign().append().. that's not exactly any cleaner by itself imho |
| 00:33.03 | a_meteorite | 10.2->10.3->10.4 |
| 00:33.11 | a_meteorite | mind you, I got them they day they were released |
| 00:33.13 | brlcad | the other aspect is, but that seems a bit unnecessary just to save lines |
| 00:33.19 | a_meteorite | I didn't wait for a .1 or .2 release |
| 00:33.20 | brlcad | at expense of readability |
| 00:33.22 | Flash | I'm not wedded to it... removing named temporaries reduces the cyclomatic complexity |
| 00:34.08 | brlcad | heh, you changed keybinding code too ... |
| 00:34.15 | Flash | the way it was introduced a bunch of temporaries |
| 00:34.50 | brlcad | i'm not saying any of these aren't good changes.. but as *one* patch.. they make for a patch that can't be just applied |
| 00:35.07 | Flash | sorry... it was all one logical step to me |
| 00:35.26 | brlcad | that says something about your sense of logic ;) |
| 00:35.36 | Flash | or completeness ;-) |
| 00:36.25 | brlcad | it's like stream of consciousness.. it's only distantly related in that it perhaps happened while you were making the other change |
| 00:36.40 | randomparticle | hmm.. can't find the logical negation symbol on the keyboard |
| 00:36.48 | brlcad | feature-wise to removing identify/deregister/ghost, it was entirely unrelated :) |
| 00:37.13 | Flash | well, the refactoring was necessary to ensure that removing /ghost (and /register and /identify and /deregister) didn't break anything |
| 00:38.06 | brlcad | necessary to you perhaps -- but now I effectively have to "refactor" your patch to ensure you don't break anything |
| 00:39.16 | Tupone | Actually I prefer having the temporary :/ |
| 00:39.22 | Flash | hmmm. isn't that a fundamental issue with refactoring? |
| 00:39.28 | brlcad | any one of the core devs could have rather easily recognized whether the 20 or so odd lines that would ultimately need to be removed would have broken anything ;) |
| 00:39.46 | randomparticle | i guess it doesn't matter because i use latex, but i'm surprised i can't see that symbol |
| 00:40.10 | brlcad | Flash: not really -- it's a fundamental issue without someone learning a new codebase |
| 00:40.29 | Tupone | ~brlcad++ |
| 00:40.49 | Flash | fair enough (I guess)... |
| 00:41.23 | brlcad | Flash: the ideas and "most" of the changes aren't bad by themselves, but together they make for too much (for a patch at least, or for a single commit for that matter too) |
| 00:41.47 | Flash | and I have been in your shoes, so I am not unsympathetic |
| 00:42.36 | randomparticle | not intuitionist logic then :) |
| 00:42.40 | brlcad | i mean, damn.. the patch is almost a thousand lines of change just to remove three commands :) |
| 00:43.20 | Flash | true; the humongous if/else/case constructs that I refactored will inflate the line count |
| 00:44.08 | brlcad | better to first remove the commands, then refactor each of those sections individually (patch-wise) |
| 00:44.37 | brlcad | yes, quite inflated, which is the point of not including them.. the actual removal amounts to about 20 lines |
| 00:45.45 | Flash | on the other hand, I'll argue that the result (standing on its own) is less complex than the original |
| 00:45.45 | Flash | and much easier to add/remove new commands |
| 00:45.54 | brlcad | I'm also saying that I can't apply/accept the patch as-is -- the work is mostly good, but it'll be too much work to break it up on my end so it can be properly reviewed -- can't just take it on good faith, not that big a change |
| 00:46.08 | Flash | also fair enough |
| 00:46.09 | brlcad | maybe DTRemenak will, or Tupone :) |
| 00:47.21 | brlcad | see and all that to also say that I'm one of the few devs that opposed the change in the first place, though I was willing to conceed :) |
| 00:47.32 | brlcad | I don't think local auth should go away |
| 00:47.38 | brlcad | at least until global is better |
| 00:47.45 | brlcad | but especially given current state of affairs |
| 00:48.15 | brlcad | Flash: seriously, that sounds like a great change.. but just make a few smaller patches first, get commit access |
| 00:50.10 | Flash | like I said earlier, cleaning up bad code is a pet peeve of mine... perhaps a downfall for this particular process |
| 00:50.27 | Flash | I've trained myself NOT to hack and slash ;-) |
| 00:50.50 | Flash | (except when I amputate and refactor) |
| 00:51.20 | brlcad | you're not alone in that regard |
| 00:52.59 | Flash | but I appreciate your dillema.. you have to validate that my refactoring is valid ;-) |
| 00:53.03 | brlcad | tupone, dtr, and myself in particular have spent massive amounts of time refactoring .. but only the tip of the iceberg really |
| 00:54.12 | brlcad | and it always has to be careful to *some* degree |
| 00:54.49 | brlcad | maybe less so for head when it's a dev minor, but still not wonton sweeping changes .. else it will end up like 1.8 :) (dead) |
| 00:55.22 | Flash | remember when I asked about automated unit testing a while back? |
| 00:55.37 | Flash | a useful tool to validate that the refactoring doesn't break anything |
| 00:56.08 | brlcad | Flash: also have to "validate" that you're not going to piss off the other existing core devs, your style has to mesh especially with respect to refactoring |
| 00:56.18 | Flash | of course |
| 00:56.22 | brlcad | there's academic purity, and there's practical purity |
| 00:56.40 | brlcad | some changes just aren't worth it if it's going to alienate or start a heated debate |
| 00:57.09 | Flash | as a general comment, I have to agree. are you suggesting that my change is in that category? |
| 00:57.13 | brlcad | the good refactoring proves itself without the argument |
| 00:57.46 | brlcad | no, I'm not suggesting it is or isn't.. I couldn't get to that point given all the other concenrs |
| 00:57.53 | Flash | I agree (again, in general) |
| 00:57.55 | brlcad | s/nrs/rns/ |
| 01:01.26 | *** part/#bzflag Tupone (n=Tupone@pdpc/supporter/active/Tupone) |
| 01:03.06 | *** part/#bzflag randomparticle (n=randompa@about/essy/snick/randomparticle) |
| 01:08.35 | Flash | so one stylistic change (that I think you questioned) is the removing of unnamed temporaries in string assignments |
| 01:09.10 | Flash | e.g., sendMsg = sendMsg + " " + message --> sendMsg.append(" ").append(message) |
| 01:09.49 | Flash | which could be written as sendMsg += " "; sendMsg += message if the java-style chaining is disliked |
| 01:11.07 | Flash | the first version compiles into: tmp1 = sendMsg + " "; tmp2 = tmp1 + message; sendMsg = tmp2 |
| 01:11.22 | Flash | which is inherently less efficient |
| 01:12.13 | brlcad | more concerned about readability and debuggability, unless you show a profile that performance matters in the least |
| 01:13.02 | brlcad | conjectured performance impact isn't much worth discussing, especially for something like those infrequent string processing chunks |
| 01:13.11 | Flash | debugability is a draw (perhaps a nod toward the latter style) |
| 01:13.35 | brlcad | being able to watch named variables usually wins over chained temporaries |
| 01:13.57 | Flash | readability definitely goes to the original, but C++ programmers should move away from that idiom until the language has better intrinsic string support |
| 01:14.17 | brlcad | it's not really going to get any better than std::string :) |
| 01:14.39 | Flash | actually, the new style has BETTER watch support |
| 01:14.50 | Flash | because all changes are directly to the named variable |
| 01:16.32 | brlcad | that's still arguable since with a temporary being watched, I only get notifications when it changes, not when anything happens to the other value |
| 01:16.35 | brlcad | i.e. it's localized |
| 01:16.52 | Flash | ?? you can't watch unnamed temporaries |
| 01:16.59 | brlcad | exactly |
| 01:17.09 | Flash | my version eliminated unnamed temporaries |
| 01:18.05 | brlcad | i'm referring to the section where you changed a switch from being "case SuperKill: sendMsg = "/superkill"; break;" |
| 01:18.30 | brlcad | to lines like: case LagWarn: sendMsg.assign("/lagwarn ").append(message); break; |
| 01:19.08 | Flash | the original code uses the unnamed temps |
| 01:19.19 | Flash | still no temporaries |
| 01:19.20 | brlcad | combining them, sendMsg is no longer really a temporary/container like it was before, it's the message (which by itself is fine) |
| 01:19.51 | Flash | at the bottom of the case statement message was appended to sendMsg |
| 01:20.46 | brlcad | so if I needed to set a breakpoint before message is appended -- easy with one, not so easy with the other |
| 01:20.52 | Flash | (diregard that) |
| 01:21.13 | Flash | the original was: case LagWarn: sendMsg = "/lagwarn " + message; |
| 01:21.31 | Flash | changed to: sendMsg.assign("/lagwarn ").append(message); |
| 01:22.05 | Flash | if you wanted a break before "message" was appended, you couldn't do that in the original |
| 01:22.17 | brlcad | ah, yes true in that case |
| 01:23.19 | Flash | if you feel a strong need to be able to set individual break points, I'm not opposed to: sendMsg = "/lagwarn "; sendMsg += message;" |
| 01:23.48 | Flash | it compiles to the same thing (probably) |
| 01:24.09 | brlcad | actually the point was in general -- for this section of code, it's simple string processing |
| 01:24.17 | brlcad | which doesn't really warrant the need |
| 01:24.25 | brlcad | so readability becomes more important imo |
| 01:25.03 | *** join/#bzflag spldart (n=troublem@cpe-24-28-107-184.houston.res.rr.com) |
| 01:25.07 | brlcad | "/lagwarn " + message is pretty simple to read even for a non-coder, the other two variants do the same thing but add more foo -- what's the motivation for the change then? |
| 01:25.27 | Flash | it has to do with C++ sub-optimal string processing |
| 01:26.08 | brlcad | you mean you're optimizing a section of code (at the sake of readability) for performance where performance means absolutely squat? :-) |
| 01:26.20 | Flash | "/lagwarn " has to be converted to a temporary string; that temp is combined with 'message' to create another temp and then assigned to sendMsg |
| 01:26.33 | Flash | not just performance, but complexity |
| 01:27.01 | Flash | I think you were the one who made the case against using inefficient constructs in general |
| 01:27.10 | Flash | a while back |
| 01:27.15 | brlcad | there's complexity that the code gets turned into, and complexity of the code written |
| 01:27.42 | Flash | when it comes to debugging, the complexity of the compiled code is what really matters |
| 01:28.10 | Flash | however, this is certainly one of those areas where it's not worth pissing off the devs ;-) |
| 01:28.16 | brlcad | for this section, it doesn't really matter what it gets turned into -- and the complexity as written.. well ["/lagwarn " + message] is shorter, has fewer symbols, less punctuation... ;) |
| 01:28.54 | Flash | ... but greater cycolomatic complexity |
| 01:29.34 | brlcad | i certainly wouldn't be pissed off by the change, but i also don't see the value with it sacrificing a rather plain readability for nothing of tangible value |
| 01:30.10 | brlcad | there is no complexity of relevance involved |
| 01:30.43 | brlcad | its just a string adding another string -- and that's what the code has written explicitly |
| 01:32.04 | Flash | (for purely philosophical reasons) you would look askance at code the new'd a string for this temp and delete'd it at the end, right? |
| 01:32.16 | brlcad | normally, I actually would agree to what you're saying, but there are some portions of code that really just need to be easy to read and grok because they are otherwise non-impacting code |
| 01:33.12 | BenUrban | wow, a dispute about C++ |
| 01:33.24 | Flash | I accept that I'm introducing a new style here (and that is hard to win) |
| 01:33.32 | Flash | and I'll surrender the style issue |
| 01:33.35 | blast007 | BenUrban: my eyes started to glaze over long ago ;) |
| 01:33.38 | BenUrban | hehe |
| 01:33.40 | brlcad | if there was no purpose for the new/delete, sure -- adds to the complexity |
| 01:33.48 | brlcad | but it's not explicit |
| 01:33.56 | brlcad | so point is moot |
| 01:34.08 | Flash | but the reason behind the style change is valid and not that hard to understand (for the willing) |
| 01:35.22 | Flash | the ONLY reason I used the chained dot notation was to keep previously single line statements on a single line |
| 01:35.36 | Flash | or else the line count would have been even higher ;-) |
| 01:35.41 | brlcad | I wouldn't I frown upon the new/delete for performance and/or run-time reasons -- only frowned upon for maintenance reasons of someone accidentally inserting new code later, accidentally getting rid of a delete that was needed etc |
| 01:35.48 | BenUrban | how about making a function whose sole purpose is to maximize readability without compromising efficiency? |
| 01:35.56 | brlcad | performance-wise, it only matters once you have a profile that shows it matters |
| 01:36.03 | BenUrban | or is that what is used now? |
| 01:36.13 | Flash | you are singing my song... anti-premature optimization |
| 01:36.14 | brlcad | this section of code has no performance impact |
| 01:36.25 | BenUrban | sorry i'm just kinda jumping into the discussion very late here |
| 01:36.39 | Flash | no worries, we are deep into philosophical territory |
| 01:36.58 | BenUrban | what does that code look like now? |
| 01:37.14 | Flash | after the change? |
| 01:37.21 | BenUrban | before the change |
| 01:37.34 | Flash | case LagStats: sendMsg = "/lagstats"; break; |
| 01:37.40 | Flash | bad choice |
| 01:37.53 | Flash | case LagWarn: sendMsg = "/lagwarn " + message; break |
| 01:38.12 | Flash | after: |
| 01:38.13 | brlcad | i actually don't disagree, just depends on the context of the code -- for *this* context, you loose more than is gained -- sacrificing readability and simplicity in order to compensate for an implementation detail |
| 01:38.16 | Flash | case LagWarn: sendMsg.assign("/lagwarn ").append(message); break; |
| 01:38.24 | BenUrban | where message is a char* or a c++ string or what? |
| 01:38.33 | Flash | message is std::string |
| 01:38.38 | Flash | as is sendMsg |
| 01:38.38 | BenUrban | hmm |
| 01:38.49 | BenUrban | so the literal is converted to a temp string |
| 01:38.57 | brlcad | yep |
| 01:39.06 | brlcad | message is appened, then assigned to sendMsg |
| 01:39.08 | BenUrban | then a new concatenated string is created, then the temp string is deleted |
| 01:40.40 | BenUrban | heh, every void function was set up to instead return this |
| 01:40.55 | Flash | BenUrban: the change is unquestionably better C++, just questioning the human readability |
| 01:41.01 | BenUrban | everything became one-liners, etc |
| 01:41.05 | brlcad | you should at least conceed that [sendMsg = "/lagwarn " + message;] is lexically shorter and simpler than [sendMsg.assign("/lagwarn ").append(message);] |
| 01:41.14 | Flash | yep |
| 01:41.18 | BenUrban | indeed it is |
| 01:41.25 | BenUrban | and more obvious |
| 01:41.33 | Flash | (sorry to bow out, but I have to go to dinner.... bbl) |
| 01:41.36 | brlcad | easier to comprehend as well to an arbitrary audience |
| 01:41.59 | brlcad | cya |
| 01:43.05 | BenUrban | in theory, one could use (sendMsg = "/lagwarn ") += message |
| 01:43.07 | BenUrban | i suppose |
| 01:43.15 | BenUrban | right? |
| 01:43.35 | BenUrban | slightly more readable than the . version |
| 01:43.40 | BenUrban | far less obvious |
| 01:43.50 | BenUrban | and a bit shorter |
| 01:44.03 | BenUrban | at least from my perspective |
| 01:44.04 | brlcad | the entire point was that given performance is absolutely irrelevant here, the shorter, simpler, more obvious, concise version wins -- you lose that simplicity and readability for a performance and implementation complexity that do not matter |
| 01:44.11 | BenUrban | oh |
| 01:44.25 | BenUrban | this is only executed a few times? |
| 01:44.32 | brlcad | heh, rarely ever |
| 01:44.40 | BenUrban | then yeah, it doesn't matter |
| 01:44.41 | brlcad | like.. when someone types a command ;) |
| 01:45.03 | BenUrban | unless you're doing it entirely for consistency's sake |
| 01:45.12 | brlcad | consistency of what? |
| 01:45.13 | BenUrban | in which case the rest of that select statement should be changed too |
| 01:45.30 | BenUrban | uhh not sure |
| 01:45.32 | BenUrban | ol |
| 01:45.34 | BenUrban | *lol |
| 01:45.39 | brlcad | ah, actually he updated entire chunks, which is what started the discussion |
| 01:45.46 | BenUrban | who did? |
| 01:45.52 | brlcad | updating the entire select statement from one to the other |
| 01:45.56 | BenUrban | ah |
| 01:46.00 | brlcad | Flash did, in a patch of his |
| 01:46.05 | BenUrban | i see |
| 01:47.01 | BenUrban | if the code is rarely executed, the performance difference is negligible |
| 01:47.06 | brlcad | the whole discussion spawned from the fact that his patch is about 880 lines of changes like that |
| 01:47.10 | BenUrban | thus readability is more important |
| 01:47.14 | BenUrban | ah |
| 01:47.15 | brlcad | and about 20 lines that actually do what the patch says it does |
| 01:47.35 | BenUrban | yeah that's bad patch etiquette, i think |
| 01:47.39 | brlcad | majority was refactoring three different sections |
| 01:48.00 | brlcad | with dubious refactoring benefit to the one section in question |
| 01:48.02 | BenUrban | not that i haven't been known to do that kind of patch, but at least i didn't include some functionality changes in that kind of patch |
| 01:48.22 | brlcad | there was another that was refactored completely reasonably, overall improvement to say the least |
| 01:48.31 | brlcad | in readability alone |
| 01:48.52 | BenUrban | i would think refactoring should be in a separate patch from functionality |
| 01:49.04 | brlcad | ~(20.0 / 880.0) * 100.0 |
| 01:49.06 | ibot | 2.272727272727 |
| 01:49.17 | BenUrban | hehe |
| 01:49.30 | BenUrban | that's the % of functionality lines in the patch? |
| 01:49.35 | brlcad | :) |
| 01:50.07 | brlcad | yeah, each section that was refactored really belong in a patch by itself -- especially the one that changed input key processing |
| 01:50.08 | BenUrban | must be horribly annoying to get a patch like that and try to find the buried functionality changes |
| 01:50.37 | brlcad | i was going to apply it as he's been rather active and interested |
| 01:51.13 | brlcad | only to find that I really can't apply that -- I'd have to break it up on my end in order to validate his changes and make sure nothing is broken |
| 01:51.32 | BenUrban | yep |
| 01:51.49 | brlcad | maybe dtr or jeff or tupy want to do that, but the *hope* was just that he'd make a few smaller patches |
| 01:51.58 | brlcad | so we can be comfortable about giving him access |
| 01:52.01 | BenUrban | did you tell him that? |
| 01:52.12 | BenUrban | maybe he never thought about it... |
| 01:52.33 | brlcad | which just goes to show why patches are usually requested.. better we have this discussion now than *after* he has commit access and is arguing with one of the invested core devs |
| 01:52.44 | brlcad | he said it was all related to him.. :) |
| 01:53.19 | brlcad | related to his understanding of how the code works, sure.. but not to the functional patch change :) |
| 01:53.20 | brlcad | doesn't take 900 lines to remove three commands |
| 01:53.30 | BenUrban | hmm |
| 01:53.31 | BenUrban | well |
| 01:53.34 | brlcad | and I don't even agree that those three commands should be removed :) |
| 01:53.51 | BenUrban | i can actually understand his point of view, to an extent |
| 01:54.51 | BenUrban | some projects i've done some work on were horribly coded, from my point of view |
| 01:55.17 | BenUrban | they were in python, but they were written as if by someone who doesn't know python |
| 01:55.21 | BenUrban | probably still are |
| 01:56.05 | BenUrban | i had to convert entire modules to the python way of thinking (at least the way i know of) just to figure out how it works |
| 01:56.16 | brlcad | and in general, I agree with the point |
| 01:56.27 | brlcad | but the argument here was based on a performance benefit |
| 01:56.38 | brlcad | where performance doesn't matter at all |
| 01:56.48 | brlcad | and sacrifices simplicity and readability to boot |
| 01:57.37 | brlcad | and in terms of making a patch that "someone (tm)" is going to have to eventually review and try to validate and test and apply ... ? |
| 01:58.26 | brlcad | i mean, sure if you don't actually care about reviewing/testing/etc .. but then if you don't care about that, just give them commit access and stop slowing them down |
| 01:58.39 | BenUrban | yep |
| 02:36.53 | *** join/#bzflag Theme97 (n=Theme97@about/essy/phpwriter/Theme97) |
| 02:43.03 | Flash | brlcad: back from dinner briefly, but have to relinquish the lappy to a persistent daughter... |
| 02:43.22 | Flash | I take it you want the patch re-submitted with fewer stylistic changes ;-) |
| 02:51.44 | Flash | (to be continued).... |
| 03:17.43 | *** join/#bzflag master_tux (n=will@pool-71-99-7-205.tampfl.dsl-w.verizon.net) |
| 03:18.00 | master_tux | ok quick please, how can i find how much space is on my drive in linux from bash? |
| 03:20.22 | a_meteorite | you can fdisk your drive and then read the specs sheet |
| 03:20.26 | a_meteorite | lol, j/k ;) |
| 03:20.49 | master_tux | please |
| 03:20.55 | master_tux | theres something wrong |
| 03:21.05 | master_tux | i think a file is duplicating |
| 03:23.48 | master_tux | :( |
| 03:27.46 | *** join/#bzflag bryjen (n=bryjen@2002:4cb1:b973:0:0:0:0:1) |
| 03:27.47 | *** mode/#bzflag [+v bryjen] by ChanServ |
| 03:28.45 | blast007 | master_tux: df |
| 03:29.04 | master_tux | thanks |
| 03:29.09 | blast007 | and you can use 'du' for determine disk usage of a particular directory |
| 03:29.14 | master_tux | 9.2 GB out of 9.2 GB :( |
| 03:29.16 | master_tux | im screwed |
| 03:29.37 | a_meteorite | :o |
| 03:30.02 | blast007 | I have more space free on my 3GB linux box |
| 03:30.18 | master_tux | i think my system is crashing |
| 03:30.30 | master_tux | it wont empty the recycling bin! |
| 03:30.57 | a_meteorite | ran out of swap? |
| 03:31.13 | blast007 | wait, linux has a recycling bin? is that a sign I need to use a GUI once in a while? |
| 03:33.10 | master_tux | ... |
| 03:33.14 | master_tux | i dont have a swap |
| 03:33.21 | a_meteorite | ...... |
| 03:33.36 | master_tux | it wont write to the trash.info thing because ive ran out of space |
| 03:33.37 | a_meteorite | what happens when you run out of ram? |
| 03:33.47 | a_meteorite | use rm |
| 03:33.48 | master_tux | your processor fries |
| 03:34.05 | a_meteorite | lol |
| 03:34.15 | master_tux | how do i empty the trash! |
| 03:34.18 | a_meteorite | open a terminal and rm your trash folder... |
| 03:34.19 | master_tux | i cant delete it |
| 03:34.23 | master_tux | wth |
| 03:34.33 | a_meteorite | wherever your gui places it |
| 03:34.43 | a_meteorite | what window manager do you use? gnome? kde? |
| 03:35.09 | master_tux | kde |
| 03:35.24 | master_tux | its in Desktop/trash.desktop i think |
| 03:35.39 | master_tux | thing is i deleted it from the desktop |
| 03:35.42 | master_tux | and its still there |
| 03:35.52 | a_meteorite | open a terminal |
| 03:36.15 | master_tux | did that |
| 03:36.19 | a_meteorite | rm -rf ~/.local/share/Trash/ |
| 03:36.26 | a_meteorite | that's according to a gnome kde thread |
| 03:36.43 | master_tux | gnome and kde should never be used in the same sentence |
| 03:37.02 | a_meteorite | oh, wait, rofl |
| 03:37.08 | master_tux | too late |
| 03:37.08 | a_meteorite | *ubuntu kde |
| 03:37.12 | master_tux | ah |
| 03:37.12 | master_tux | ok |
| 03:37.29 | master_tux | hey! |
| 03:37.33 | a_meteorite | then you should just mkdir ~/.local/share/Trash when it's done. cause it'll delete the Trash folder |
| 03:37.40 | master_tux | i freed up 700 MB! |
| 03:37.46 | a_meteorite | lol |
| 03:40.31 | master_tux | Fear me, for I am root |
| 03:40.57 | master_tux | i suppose keeping the source of every program was a bad idea... |
| 03:41.04 | a_meteorite | probably |
| 03:41.08 | master_tux | but how am I supposed to uninstall it later? |
| 03:41.16 | master_tux | i dont think its possible |
| 03:41.19 | a_meteorite | using your package mananger |
| 03:41.30 | master_tux | my package manager deals with .tgz files |
| 03:41.35 | a_meteorite | ... |
| 03:41.39 | a_meteorite | what's your distro? |
| 03:41.42 | master_tux | the source directories are dirs |
| 03:41.44 | master_tux | lmao |
| 03:41.46 | master_tux | slackware |
| 03:41.54 | a_meteorite | um, I have no idea then |
| 03:42.19 | a_meteorite | oh |
| 03:42.24 | a_meteorite | http://www.justlinux.com/nhf/Distribution_Specific/Slackware_Linux/Slackware__The_Quick_and_Dirty_Quide_to_Packages.html |
| 03:42.33 | a_meteorite | you can use removepkg nameofpackage |
| 03:42.52 | a_meteorite | you have to cd to /var/log/packages first |
| 03:43.04 | master_tux | yea |
| 03:43.10 | master_tux | the source of the programs though |
| 03:43.18 | master_tux | are .tar.gz |
| 03:43.21 | a_meteorite | ahh... |
| 03:43.22 | master_tux | not .tgz |
| 03:43.30 | a_meteorite | you can rename it |
| 03:43.36 | a_meteorite | .tgz == .tar.gz |
| 03:43.42 | master_tux | it wouldnt be a valid package file :p |
| 03:43.46 | a_meteorite | oh |
| 03:43.57 | a_meteorite | I know nothing how slackware's packages work |
| 03:44.54 | master_tux | what distro do you use? |
| 03:45.12 | a_meteorite | debian |
| 03:58.44 | *** join/#bzflag A-Delusion (n=A-Delusi@pool-151-201-122-253.pitt.east.verizon.net) |
| 03:59.42 | *** join/#bzflag tannerld (n=tanner@adsl-068-209-251-067.sip.asm.bellsouth.net) |
| 04:05.36 | a_meteorite | ok... wtf? two tanks advocate comes into boxy war with a bazillion bots that says they have better laser sniping |
| 04:06.41 | a_meteorite | so not cool |
| 04:08.31 | bryjen | you don't have to be in /var/log/packages to uninstall packages. it may help since that directory is a list of installed packages though |
| 04:09.48 | bryjen | and unless your going to be customizing and/or recompiling stuff, you don't need the /source/ trees and all those archives |
| 04:10.37 | master_tux | umm |
| 04:11.00 | master_tux | bryjen:well, sometimes some programs can only be installed from source |
| 04:11.10 | master_tux | how am I supposed to uninstall them without it |
| 04:12.00 | bryjen | then you're not talking about things that came as slackware packages. the package tools take care of those. |
| 04:12.22 | master_tux | how do i uninstall the source programs without the source? |
| 04:13.15 | bryjen | if you downloaded something else as source code and configure/make/install-ed them yourself, then yeah, you'd need to keep at least the archive you downloaded around to "make uninstall" later |
| 04:13.48 | master_tux | meh |
| 04:19.58 | *** join/#bzflag tannerld (n=tanner@adsl-068-209-251-067.sip.asm.bellsouth.net) |
| 04:43.49 | *** part/#bzflag A-Delusion (n=A-Delusi@pool-151-201-122-253.pitt.east.verizon.net) |
| 05:25.56 | *** join/#bzflag Pommes_ (n=Pommes@pD9547172.dip0.t-ipconnect.de) |
| 05:33.27 | *** join/#bzflag Flash (n=jwmelto@c-24-9-8-185.hsd1.co.comcast.net) |
| 05:40.51 | *** join/#bzflag short_circuit (n=short_ci@cpe-24-28-107-184.houston.res.rr.com) |
| 06:15.12 | *** join/#bzflag twitch_ (n=gort242z@cpe-75-82-228-143.socal.res.rr.com) |
| 06:15.14 | *** part/#bzflag twitch_ (n=gort242z@cpe-75-82-228-143.socal.res.rr.com) |
| 06:28.44 | Flash | time for the night shift |
| 06:32.20 | *** join/#bzflag zee386 (i=3e4de48a@gateway/web/cgi-irc/zeebrothers.net/x-7fa77257b92200e0) |
| 07:45.37 | *** join/#bzflag plasma_kaz (n=Evan@about/essy/MeanieBeanie/plasmakaz) |
| 07:45.47 | plasma_kaz | ~seen brad |
| 07:46.13 | ibot | brad is currently on #bzflag (2d 9h 26m 18s) #pillbox (2d 9h 26m 18s) #silvercat (2d 9h 26m 18s) #guleague (2d 9h 26m 18s). Has said a total of 104 messages. Is idling for 2d 1h 37m 43s, last said: '~seen menotume'. |
| 07:46.13 | plasma_kaz | :( |
| 07:47.08 | plasma_kaz | ~seen menotume |
| 07:47.13 | ibot | menotume <n=George@71.225.151.82> was last seen on IRC in channel #kierra, 67d 15h 22m 11s ago, saying: 'i hope to have my old 400Mhz pc in good shape by tomorrow'. |
| 07:50.07 | PuMpErNiCkLe | heh, I think he broke it |
| 08:29.22 | plasma_kaz | lol |
| 08:43.50 | *** join/#bzflag ts (n=ts@p54B02AD2.dip0.t-ipconnect.de) |
| 10:12.13 | *** join/#bzflag |zongo| (n=zongo@int-34-35.mobile.unibas.ch) |
| 11:23.37 | *** join/#bzflag Thonolan (n=Thonolan@unaffiliated/thonolan) |
| 12:07.01 | *** join/#bzflag Thonolan (n=Thonolan@unaffiliated/thonolan) |
| 12:07.40 | Thonolan | any ducati admin arround ? |
| 12:08.47 | |zongo| | Thonolan, i might help |
| 12:09.13 | Thonolan | can you check pls IP ? |
| 12:15.10 | *** part/#bzflag Thonolan (n=Thonolan@unaffiliated/thonolan) |
| 12:31.59 | *** join/#bzflag L4m3r_ (n=l4m3r@pool-71-118-51-14.lsanca.dsl-w.verizon.net) |
| 13:19.39 | *** join/#bzflag moriah (i=44c04d6a@gateway/web/cgi-irc/zeebrothers.net/x-f7cdbfec1034830d) |
| 13:20.04 | *** part/#bzflag moriah (i=44c04d6a@gateway/web/cgi-irc/zeebrothers.net/x-f7cdbfec1034830d) |
| 13:24.00 | *** join/#bzflag Birdie (n=Birdie__@d54C12302.access.telenet.be) |
| 13:24.12 | *** join/#bzflag NotWorthy (i=c344c04d@gateway/web/cgi-irc/zeebrothers.net/x-0ba412ae55eba940) |
| 13:33.35 | *** join/#bzflag donny_baker (n=donny_ba@mse1.bowencenter.org) |
| 14:06.33 | *** join/#bzflag Guest752 (i=5495c11c@gateway/web/cgi-irc/zeebrothers.net/x-525fa2cc64dc8a38) |
| 14:06.41 | Guest752 | was geht |
| 14:19.12 | *** join/#bzflag A-Delusion (n=A-Delusi@pool-151-201-122-253.pitt.east.verizon.net) |
| 14:41.18 | *** join/#bzflag CIA-3 (i=cia@cia.navi.cx) |
| 15:25.25 | *** join/#bzflag Tupone (n=Tupone@pdpc/supporter/active/Tupone) |
| 15:25.25 | *** mode/#bzflag [+v Tupone] by ChanServ |
| 15:40.55 | *** join/#bzflag bz40 (n=c7b4110a@bz.bzflag.bz) |
| 15:43.40 | *** join/#bzflag bz30 (n=46770802@bz.bzflag.bz) |
| 15:43.53 | bz30 | I have a question about BZ install - anyone? |
| 15:44.10 | donny_baker | fire away |
| 15:44.55 | bz30 | i had to wipe my drive and re-install XP - I seem to remember that there was a Source Forge file I needed to install first but can't remember what is was.... |
| 15:45.28 | bz30 | when I install BZ the graphics are whacked |
| 15:45.42 | donny_baker | that sounds like a video driver issue |
| 15:45.53 | bz30 | it worked fine before?? |
| 15:45.57 | donny_baker | get the latest driver for your video card |
| 15:46.14 | bz30 | ok - I'll try that - thanks |
| 15:46.15 | donny_baker | yes, wiping the HD will wipe out the video driver too |
| 15:49.03 | *** join/#bzflag Thonolan (n=Thonolan@unaffiliated/thonolan) |
| 15:49.38 | Thonolan | Chestal: ping |
| 15:57.13 | *** part/#bzflag Thonolan (n=Thonolan@unaffiliated/thonolan) |
| 16:08.47 | *** join/#bzflag Gnurdux (n=gnurdux@c-69-251-233-242.hsd1.md.comcast.net) |
| 16:24.04 | *** join/#bzflag Pimpi (n=frank@gondolin.pimpi.org) |
| 17:03.02 | brlcad | http://home.tiscali.nl/annejan/swf/timeline.swf |
| 17:11.03 | Tupone | :) |
| 17:12.32 | donny_baker | so is that the official BZFlag development timeline :p |
| 17:14.04 | blast007 | heh |
| 17:24.02 | *** join/#bzflag [NP]Tangent (n=hyperdev@65.167.130.12) |
| 17:25.26 | *** join/#bzflag bz14 (n=d1e2b4a2@bz.bzflag.bz) |
| 17:25.49 | bz14 | i though the BZ stood for Battlezone |
| 17:25.49 | bz14 | :) |
| 17:26.06 | bz14 | apparently not |
| 17:26.41 | bz14 | http://relicnews.com/yearbook/2006/373/ |
| 17:27.57 | [NP]Tangent | yes, bz stands for battle zone |
| 17:28.09 | [NP]Tangent | Battle Zone capture the FLAG |
| 17:28.19 | bz14 | and are these what is left of the BZ players? |
| 17:28.22 | CBG | ~donny_baker++ |
| 17:28.39 | bz14 | you talking about Battlezone by Activision? |
| 17:29.03 | [NP]Tangent | no |
| 17:29.07 | bz14 | ahhh |
| 17:29.11 | bz14 | i see the wiki |
| 17:29.12 | bz14 | nm |
| 17:29.51 | bz14 | coincidence... the last patch for acti's BZ was 1.4 |
| 17:29.58 | bz14 | <-- |
| 17:30.40 | bz14 | well this is me: http://relicnews.com/yearbook/2006/373/ <-- a vet BZer |
| 17:56.47 | *** join/#bzflag ts (n=ts@p54B007EB.dip0.t-ipconnect.de) |
| 18:08.44 | *** join/#bzflag Gnurdux (n=gnurdux@c-69-251-233-242.hsd1.md.comcast.net) |
| 18:22.35 | *** join/#bzflag tannerld (n=tanner@adsl-068-209-251-067.sip.asm.bellsouth.net) |
| 18:40.53 | *** join/#bzflag SpazzyMcGee (n=SpazzyMc@fordend.demon.co.uk) |
| 18:46.23 | *** join/#bzflag one90 (n=bigknox4@cpe-24-58-106-179.twcny.res.rr.com) |
| 18:48.33 | one90 | #bzflagchat |
| 18:48.49 | *** part/#bzflag one90 (n=bigknox4@cpe-24-58-106-179.twcny.res.rr.com) |
| 18:50.18 | *** join/#bzflag gsnedders (n=gsnedder@host86-139-123-225.range86-139.btcentralplus.com) |
| 18:51.42 | *** join/#bzflag gsnedders (n=gsnedder@host86-139-123-225.range86-139.btcentralplus.com) |
| 19:12.30 | ts | brlcad: ping |
| 19:14.59 | *** join/#bzflag Gnurdux (n=gnurdux@c-69-251-233-242.hsd1.md.comcast.net) |
| 19:15.04 | ts | brlcad: If I remember correct it was you who tried to make the getting unsealed from sealed thingy non frameratre dependent. Don't get me wrong, it is now framerate independent but not the way I like. I'm never getting unsealed now. |
| 19:18.56 | *** join/#bzflag plasma_kaz (n=Evan@ip70-171-170-13.om.om.cox.net) |
| 19:22.40 | Tupone | ts :) |
| 19:22.56 | Tupone | I think It deserve a better coding |
| 19:26.07 | *** join/#bzflag Flash (n=jwmelto@c-24-9-8-185.hsd1.co.comcast.net) |
| 19:33.36 | *** join/#bzflag CBG (n=CBG@cpc4-stme1-0-0-cust103.cdif.cable.ntl.com) |
| 19:34.23 | *** join/#bzflag CBG (n=CBG@cpc4-stme1-0-0-cust103.cdif.cable.ntl.com) |
| 19:57.17 | ts | Tupone: Heh, lots of things deserve better coding |
| 19:58.30 | Tupone | Referring to that, has that was partially my fault. I wrote the code to unstuck, as I was stucked a lot of time before |
| 19:58.36 | Tupone | s/has/as/ |
| 19:59.00 | ts | Tupone: Actually I think my new /countdown resume code is a bit too complicated. I'm looking at a way to do it easier, though |
| 20:08.19 | *** join/#bzflag qw4 (n=5499a8cb@bz.bzflag.bz) |
| 20:33.12 | *** join/#bzflag CBG (n=CBG@cpc4-stme1-0-0-cust103.cdif.cable.ntl.com) |
| 20:53.36 | *** join/#bzflag MPS (n=MPS@87.193.39.10) |
| 20:56.35 | brlcad | ts: I think there's a <= that needs to be a >= in the code |
| 20:57.07 | brlcad | i.e. a bug, which is why you stack stuck |
| 21:17.26 | *** join/#bzflag QuantumBeep (n=QuantumB@doc-72-47-46-111.leesville.la.cebridge.net) |
| 21:17.30 | *** join/#bzflag a_temp_dist (n=ATD@mn-69-34-51-32.dyn.embarqhsd.net) |
| 21:17.36 | QuantumBeep | Any Perl people here? |
| 21:18.24 | *** join/#bzflag mwr25 (i=mwr25@pip.srcf.societies.cam.ac.uk) |
| 21:18.55 | ts | Eeek perl :/ |
| 21:29.24 | ts | brlcad: I know it is a a bug, I don't believe it is intentional |
| 21:29.51 | *** join/#bzflag Birdie (n=Birdie__@d54C12302.access.telenet.be) |
| 21:30.20 | ts | Tupone: Well, in some situations a tank gets stuck and it can not being prevented |
| 21:31.11 | ts | Tupone: I don't think framerate independent unstuck code is as important for gameplay as jumping and driving on ground is.. |
| 21:32.18 | *** join/#bzflag Theme97 (n=Theme97@about/essy/phpwriter/Theme97) |
| 21:34.53 | *** join/#bzflag Theme97_ (n=Theme97@about/essy/phpwriter/Theme97) |
| 21:38.34 | *** join/#bzflag [NP]Tangent (n=hyperdev@65.167.130.12) |
| 21:45.19 | *** join/#bzflag spldart (n=short_ci@cpe-24-28-107-184.houston.res.rr.com) |
| 21:55.35 | [NP]Tangent | ugh |
| 21:55.36 | [NP]Tangent | here we go again |
| 21:55.37 | [NP]Tangent | http://my.bzflag.org/bb/viewtopic.php?t=9828&start=0&postdays=0&postorder=asc&highlight= |
| 21:59.13 | L4m3r | already working on it |
| 21:59.17 | *** join/#bzflag Tupone (n=Tupone@pdpc/supporter/active/Tupone) |
| 21:59.17 | *** mode/#bzflag [+v Tupone] by ChanServ |
| 22:02.28 | CBG | [NP]Tangent: hint, use /msg :) |
| 22:04.27 | [NP]Tangent | CBG, but I did PRIVMSG |
| 22:04.29 | [NP]Tangent | :D |
| 22:04.36 | [NP]Tangent | just to #bzflag |
| 22:04.37 | [NP]Tangent | :P |
| 22:04.52 | CBG | Yeah, so that the whole channel can click the link... :) |
| 22:05.06 | [NP]Tangent | well, if I did send a pm |
| 22:05.12 | [NP]Tangent | who would I be sending it to? |
| 22:05.50 | CBG | Someone who can remove it... L4m3r can and is active atm. |
| 22:06.28 | blast007 | [NP]Tangent: I can remove spam, for future reference |
| 22:06.34 | [NP]Tangent | k |
| 22:06.35 | [NP]Tangent | thanks |
| 22:07.29 | CBG | As can JeffM2501 (away over the holiday period), DTRemenak (also away?), brlcad, and - in some forums - SportChick. |
| 22:10.40 | *** join/#bzflag QBeep (n=QuantumB@adsl-33-213-91.lft.bellsouth.net) |
| 22:13.45 | spldart | Fn geez |
| 22:28.34 | *** join/#bzflag Blue_Eyes (n=Blue@82.60.137.86) |
| 23:10.25 | *** join/#bzflag [dmp] (n=dennis@koderen.dk) |
| 23:14.36 | *** join/#bzflag ruskie (i=ruskie@sourcemage/mage/ruskie) |
| 23:19.28 | brlcad | blast007: was this after the registration customization was added? |
| 23:19.45 | brlcad | or is that not enabled yet? |
| 23:20.51 | brlcad | seems like the problem has almost gone away, one per week is easily manageable :) |
| 23:30.53 | *** join/#bzflag kierra (i=44c04d6a@gateway/web/cgi-irc/zeebrothers.net/x-d0c87b81fa9d4dd8) |
| 23:38.12 | *** join/#bzflag kierra (i=44c04d6a@gateway/web/cgi-irc/zeebrothers.net/x-c320f7d46a59c02e) |
| 23:38.35 | *** part/#bzflag kierra (i=44c04d6a@gateway/web/cgi-irc/zeebrothers.net/x-c320f7d46a59c02e) |
| 23:41.50 | a_meteorite | ~seen JeffM2501 |
| 23:42.08 | ibot | jeffm2501 <n=jeffm@pdpc/supporter/sustaining/JeffM2501> was last seen on IRC in channel ##essy, 5d 5h 25m 22s ago, saying: 'but vegas and San Diego with Dana will be quite nice'. |
| 23:55.43 | blast007 | brlcad: afaik now this last one was just a very recent registration |
| 23:55.50 | blast007 | probably registered today |
| 23:56.09 | blast007 | I didn't look at it, since L4m3r was taking care of it |
| 23:57.44 | *** join/#bzflag SpazzyMcGee (n=SpazzyMc@fordend.demon.co.uk) |