| 00:13.05 | IriX64 | now instead of e-mailing them to people, I just post them on my blog :) |
| 00:16.01 | brlcad | that actually works much better.. don't have to wade |
| 00:16.13 | brlcad | i like a few of the shots |
| 00:16.41 | brlcad | would be cool if you started actually building something |
| 00:18.00 | IriX64 | the zeus mobile |
| 00:18.13 | IriX64 | gotta plan it first |
| 00:18.36 | CIA-7 | BRL-CAD: 03brlcad * 10brlcad/src/other/libtermlib/Makefile.am: version is no longer relevant/known again |
| 00:19.17 | IriX64 | brlcads clay is bits and bytes |
| 00:21.53 | CIA-7 | BRL-CAD: 03brlcad * 10brlcad/src/other/libtermlib/termcap.c: |
| 00:21.54 | CIA-7 | BRL-CAD: make it look for our installed termcap file before it uses the one in etc, since |
| 00:21.54 | CIA-7 | BRL-CAD: enabling termlib compilation implies functioning independent. if they want |
| 00:21.54 | CIA-7 | BRL-CAD: their termcap file, they can still set TERMCAP or link against their system |
| 00:21.54 | CIA-7 | BRL-CAD: terminfo/termcap/curses |
| 00:34.56 | louipc | <PROTECTED> |
| 00:35.12 | brlcad | true |
| 00:35.16 | louipc | jove? |
| 00:35.23 | brlcad | yes? |
| 00:35.25 | brlcad | f'ing jove |
| 00:35.34 | brlcad | ~jove |
| 00:35.35 | ibot | jove is, like, njs's preferred little editor -- like emacs, but small. |
| 00:35.47 | brlcad | heh, didn't know that |
| 00:35.58 | Twingy | ~nano |
| 00:35.59 | ibot | methinks nano is at http://www.nano-editor.org/, or a DFSG-free alternative to pico, or 10^-9 |
| 00:36.14 | Twingy | ~gcam |
| 00:36.16 | ibot | hmm... gcam is the open source GNU Computer-Aided Machining project, developed by Justin Shumaker, for supporting basic CNC mills by directly exporting g-code to your favorite CNC driver application. See http://gcam.js.cx/ for details. |
| 00:36.16 | brlcad | ~jove is also "Jonathan's Own Version of Emacs" |
| 00:36.17 | ibot | brlcad: okay |
| 00:36.24 | Twingy | hah |
| 00:37.18 | IriX64 | for which horse :) (duck) |
| 00:37.30 | Twingy | your mom, oh snap! |
| 00:38.11 | IriX64 | youd prefer your sisyer my moms a crel ride. |
| 00:39.03 | Maloeran | ~universe |
| 00:39.05 | ibot | Space Strategy game. URL: http://rmi.net/~starkey/Universe/ |
| 00:39.29 | Twingy | ~42 |
| 00:39.31 | ibot | from memory, 42 is the answer to life the universe and everything, see also http://en.wikipedia.org/wiki/the_answer_to_life,_the_universe,_and_everything |
| 00:39.35 | IriX64 | 42's only half the answer 84 is the full answer :) |
| 00:40.54 | Maloeran | Especially since the universe is 404 Not found |
| 00:41.12 | IriX64 | an http universe interesting equation :) |
| 00:42.15 | Twingy | Maloeran, how long does it take you to raytrace the universe |
| 00:42.47 | IriX64 | e=mc2^c2 |
| 00:43.19 | Maloeran | Not too sure, I'm still waiting for some rays to come out of a black hole |
| 00:46.26 | IriX64 | you're raytracing in reverse then :) |
| 00:47.26 | Twingy | Maloeran, better put some rays on the event horizon to see what's going on with them |
| 00:48.22 | Maloeran | Yes, there must be a bug in my graph prep, they seem stuck in an infinite loop |
| 00:49.37 | Twingy | just rub your feet together on the carpet and touch your ram |
| 00:49.41 | Twingy | that'll get it unstuck |
| 00:59.07 | IriX64 | stray photons will too |
| 01:07.44 | ``Erik | *pout* this sucks |
| 01:07.49 | ``Erik | my laptop only has 2g ram |
| 01:07.55 | ``Erik | I can't model irix64's mom :( |
| 01:08.02 | Twingy | oh snap! |
| 01:16.11 | IriX64 | you're using the male model thats why :) |
| 01:16.22 | IriX64 | she doesn't have one of those :) |
| 01:17.02 | Twingy | she has two? |
| 01:17.19 | IriX64 | breasts yeah just like you :) |
| 01:17.20 | Twingy | irix64smom.cx |
| 01:17.31 | Twingy | don't make fun of my man bewbs |
| 01:17.45 | IriX64 | mine are a c cup :) |
| 01:17.53 | Twingy | ...or else I'll you on wendy's mailing list |
| 01:18.04 | Twingy | (dooh dooh doooooo organ music) |
| 01:18.08 | ``Erik | heh |
| 01:18.18 | IriX64 | means i have to work for a living? no thanks... :) |
| 01:18.26 | ``Erik | omfg, wendys mailing list, that's just fucking COLD |
| 01:19.00 | IriX64 | not knowing who wendy is i have to bow out but ill let gionnii know :) |
| 01:20.38 | ``Erik | irix: of the folk paid by uncle sam.. when we grouse and bitch and generally act disgruntled... that's response to our good friend miss wendy. |
| 01:21.24 | IriX64 | uncle sams wife? |
| 01:21.27 | Twingy | within 24 hours of my transfer taking effect I will be removed from the shackles of her mailing list |
| 01:21.53 | IriX64 | shows who really runs the military |
| 01:21.58 | ``Erik | heh |
| 01:22.20 | ``Erik | ehhehheh |
| 01:22.31 | ``Erik | y'know |
| 01:22.42 | ``Erik | I was doing some computation today |
| 01:23.03 | brlcad | me too! |
| 01:23.22 | ``Erik | heh |
| 01:23.59 | IriX64 | gotta go... kid needs a ride. |
| 01:24.27 | ``Erik | if I sold my house today and moved back to missouri.... |
| 01:24.54 | ``Erik | I would have like a fucking mansion and a fistful of 'extra' crash |
| 01:25.14 | ``Erik | it REALLY makes me think about moving back to hillbilly land and starting my own co |
| 01:25.17 | ``Erik | :/ |
| 01:25.49 | Twingy | have to keep in mind if you decide later in life to want to move to a pricey area you'll be dirt poor |
| 01:25.57 | Twingy | so that limits you to like mid west |
| 01:27.04 | Maloeran | Or up in Canada |
| 01:28.56 | ``Erik | parts of canuckia, I suppose |
| 01:29.28 | Maloeran | Any idea on what the company will offer, Erik? |
| 01:29.36 | ``Erik | 'the company'? |
| 01:29.52 | Maloeran | Within the context of "starting my own co" |
| 01:29.59 | ``Erik | heh |
| 01:30.05 | ``Erik | nfc |
| 01:30.12 | Maloeran | Okay :) |
| 01:32.10 | ``Erik | I can lay code like a mofo, and I can do certain administrative fucntions... |
| 01:32.10 | ``Erik | like finances, uh, I can be hardcore on the financial aspect... |
| 01:32.30 | ``Erik | but the business/marketing/sales shit seriosuly aint' up my alley... I need a face person. |
| 01:32.45 | Twingy | ah, so you are brining gillich with you |
| 01:33.00 | ``Erik | heh, I d'no about gillich |
| 01:33.15 | Twingy | I would be a bad choice, I'd get bored of ``Erik's company (whatever it was) in 3 years and he'd be screwed |
| 01:33.20 | ``Erik | with appropiate steering, lee is capable there :/ |
| 01:33.45 | Twingy | seriously though |
| 01:33.50 | Twingy | when they fire wendy, you can bring her along |
| 01:33.56 | Maloeran | Ahah |
| 01:34.08 | ``Erik | I, uh, kinda ment functional? |
| 01:34.35 | ``Erik | not th ekinda person who would bury an endeavor in unnecessary beaurocrocy... |
| 01:34.38 | ``Erik | sp |
| 01:34.52 | Twingy | I flew the twin again tonight |
| 01:35.01 | ``Erik | awesome |
| 01:35.03 | Twingy | that little toy is addictive |
| 01:35.14 | ``Erik | got someone with a radar gun to clokc you? :D |
| 01:35.17 | Twingy | I am ready to start packing electronics into it now |
| 01:35.28 | Twingy | as long as I can climb vertical that's all that matters :) |
| 01:35.40 | Twingy | will full tanks of gas |
| 01:35.51 | Twingy | *with |
| 01:36.05 | ``Erik | heh, vertical climb is an awful lot of unf |
| 01:37.51 | Twingy | figure it's got about 15 lbs of thrust |
| 01:38.16 | Twingy | probly 12 actually, fully loaded the plane is about 5-6 lbs |
| 01:38.58 | Twingy | doing an inverted dive with full throttle just rips it up |
| 01:39.16 | Twingy | a trainer would snap its wing in a heart beat |
| 01:40.33 | Maloeran | Considered a solar powered plane yet? :) |
| 01:41.14 | Twingy | already been done |
| 01:41.26 | Twingy | and those're no fun unless autonomous |
| 01:41.40 | Twingy | and I do that at work everyday |
| 01:41.40 | Maloeran | Not by amateurs flying indefinitely |
| 01:41.47 | Twingy | so no real fun |
| 01:41.59 | ``Erik | indefinitly sustainable solar autonmous aircraft would be... interesting |
| 01:42.24 | Twingy | it'd have to be huge to weather the cross winds |
| 01:42.42 | Maloeran | Then send it over the pacific to get you some pictures of Australia |
| 01:43.09 | ``Erik | like that massive nasa cruiser that flexed like a mofo in the wind |
| 01:43.22 | Twingy | if solar efficiency doubles you could charge up lipo's during the day while flying above clouds |
| 01:43.26 | ``Erik | the one that was like a 30' wingspan of solar panels |
| 01:44.18 | Twingy | heh |
| 01:44.26 | Twingy | I have an 1100maH nicad in the twin |
| 01:44.32 | Twingy | my hour and a half of flying tonight used up 200ma |
| 01:44.55 | Twingy | easily fly that all day on one charge' |
| 01:45.08 | Twingy | I need an 1100 for my xmitter |
| 01:45.23 | Twingy | the hitech sucks through that 600ma in just over 90 minutes |
| 01:45.38 | Twingy | though my triton can charge it up in about 60 |
| 01:46.55 | Twingy | I doubt that xmitter is 2W though |
| 01:47.00 | Twingy | they are usualy 500mW |
| 01:48.48 | Twingy | http://www2.towerhobbies.com/cgi-bin/wti0001p?&I=LXNKD7&P=0 |
| 02:23.56 | CIA-7 | BRL-CAD: 03brlcad * 10brlcad/misc/Makefile.am: gah, I thought I already committed this. traverse into enigma dir, don't just shove everything into the dist, else make distcheck thinks that it's already been configured and aborts. |
| 02:38.27 | IriX64 | <PROTECTED> |
| 03:15.55 | IriX64 | ill try 7.8.4 tommorrow again. |
| 03:16.07 | IriX64 | quite happy with 7.6.2 tho. |
| 03:19.12 | CIA-7 | BRL-CAD: 03brlcad * 10brlcad/src/other/tcl/generic/regex.h: tcl's regex.h header assumes that there is magic being provided by tclInt.h before it's included (for VOID and CONST among other examples) .. so just freaking include it and avoid a make dist error. |
| 03:37.47 | CIA-7 | BRL-CAD: 03brlcad * 10brlcad/include/Makefile.am: vector headers are missing, bad distcheck, no donut for you |
| 03:41.38 | CIA-7 | BRL-CAD: 03brlcad * 10brlcad/include/ (Makefile.am svfb.h svfb_global.h): remove the obsolete svfb.h and svfb_global.h headers. they are part of urtoolkit and were replaced by rle_put.h and rle.h respectively. |
| 03:41.39 | *** join/#brlcad deltazap (n=zap@pool-72-64-253-55.tampfl.fios.verizon.net) [NETSPLIT VICTIM] | |
| 03:41.40 | *** join/#brlcad louipc (n=louipc@bas8-toronto63-1096669545.dsl.bell.ca) [NETSPLIT VICTIM] | |
| 03:45.10 | CIA-7 | BRL-CAD: 03brlcad * 10brlcad/include/ (Makefile.am XtndRunsv.h): remove XtndRunsv.h as well, obsoleted in urt by rle_code.h |
| 03:53.31 | *** join/#brlcad dtidrow_work (n=dtidrow@host169.objectsciences.com) [NETSPLIT VICTIM] | |
| 03:59.57 | brlcad | dtidrow_work: workin' late? :) |
| 05:13.14 | *** join/#brlcad cad41 (n=46382e0a@bz.bzflag.bz) | |
| 05:13.25 | cad41 | hello all :) |
| 05:14.14 | cad41 | i am in search of help on my mac with brlcad |
| 05:14.23 | cad41 | i cant seem to start it |
| 05:15.49 | cad41 | anyone alive in here? |
| 05:16.37 | Maloeran | You have tried running mged? Do you get any error message? I'm no expert on Mac, but it's built on Unix so... |
| 05:16.37 | cad41 | i did,and it did not do anything |
| 05:16.48 | Maloeran | If you start it from a terminal, does it print anything? |
| 05:16.57 | cad41 | i am no expert,but can do some basic linux/unix stuff |
| 05:17.09 | cad41 | i cant get it to start at all |
| 05:17.49 | cad41 | mike-campbells-computer:~ scottcampbell$ MGED |
| 05:18.03 | brlcad | cad41: type "/usr/brlcad/bin/mged" |
| 05:18.03 | cad41 | then i get nothing |
| 05:18.07 | brlcad | without the quotes |
| 05:18.24 | brlcad | with X11 running |
| 05:19.34 | cad41 | thank you |
| 05:19.36 | cad41 | :) |
| 05:19.55 | cad41 | ooops |
| 05:20.34 | cad41 | didnt work |
| 05:20.55 | brlcad | you're running X11? |
| 05:21.00 | cad41 | yes |
| 05:21.03 | cad41 | made sure of that |
| 05:21.15 | Maloeran | Try to give more information on what isn't working, it's a bit vague |
| 05:21.25 | Maloeran | Does it print anything in your terminal? |
| 05:21.36 | brlcad | you typed /usr/brlcad/bin/mged into the xterm window that popped open? |
| 05:21.46 | cad41 | it sayd no display name and no $display envoronment variable |
| 05:22.11 | brlcad | ah, type it into the xterm window instead of Terminal |
| 05:22.30 | brlcad | or run this in Terminal: export DISPLAY=:0 |
| 05:22.34 | cad41 | Initializing and backgrounding, please wait...no display name and no $DISPLAY environment variable |
| 05:23.08 | brlcad | type the export line, then retry |
| 05:24.13 | cad41 | Initializing and backgrounding, please wait...couldn't connect to display ":0" |
| 05:27.33 | Maloeran | As an unix but non-mac guy, I would say X doesn't seem to be running |
| 05:29.10 | cad41 | ok.i shall double check.thank you for the help |
| 05:32.26 | brlcad | if X11 is running (it's in your /Applications/Utilities folder), there will be a small white window open up in the top left corner entitled "xterm" |
| 05:34.36 | cad41 | Initializing and backgrounding, please wait...X Error of failed request: BadRequest (invalid request code or no such operation) |
| 05:34.48 | cad41 | X is on |
| 05:35.15 | brlcad | ahh, Intel Mac |
| 05:35.15 | cad41 | <PROTECTED> |
| 05:35.23 | cad41 | hahhaha |
| 05:35.23 | brlcad | there's a bug in apple's X11 |
| 05:35.59 | brlcad | cad41: there's a release going up this weekend that will have a fix for that, 7.10 |
| 05:36.14 | cad41 | from X? |
| 05:36.24 | cad41 | or apple? |
| 05:36.30 | brlcad | of BRL-CAD |
| 05:36.35 | cad41 | oh LOL |
| 05:36.36 | cad41 | i see |
| 05:36.40 | brlcad | we can work around the problem |
| 05:37.22 | cad41 | ahh to be a curious student......at age 40! |
| 05:37.27 | brlcad | X11 fails to talk to Rosetta correctly, so you get that opcode error |
| 05:37.55 | brlcad | a quick recompile for Intel fixes it up, or a universal binary |
| 05:38.15 | brlcad | the other command-line apps still work, but not the gui to mged |
| 05:56.20 | *** join/#brlcad tofu (n=sean@66.111.56.50) | |
| 06:45.38 | *** join/#brlcad clock_ (i=clock@84-72-61-45.dclient.hispeed.ch) | |
| 08:27.24 | *** join/#brlcad clock_ (n=clock@zux221-122-143.adsl.green.ch) | |
| 08:27.59 | *** join/#brlcad clock_ (n=clock@zux221-122-143.adsl.green.ch) | |
| 11:20.45 | *** join/#brlcad brlcad (n=sean@bz.bzflag.bz) | |
| 12:34.41 | *** join/#brlcad Twingy (n=justin@74.92.144.217) [NETSPLIT VICTIM] | |
| 12:53.47 | *** join/#brlcad tofu (n=sean@bz.bzflag.bz) | |
| 13:17.55 | Maloeran | *nods* Sure, that was just to say that I could perhaps help with the Unix part, not anything specific to OSX |
| 13:21.48 | tofu | ``Erik: so looks like it's a no go, off the hook |
| 13:22.25 | ``Erik | um, what, the gsoc? |
| 13:26.26 | brlcad | yeah |
| 13:26.53 | ``Erik | ah well *shrug* so we don't get to spend someone elses money for grunt-work development |
| 13:27.06 | brlcad | pretty much |
| 13:27.49 | ``Erik | I think the notion of a 'junior hacker' list is good to have around anyways, so I don't believe generating the document was wasteful *shrug* |
| 13:28.46 | ``Erik | even if no one else picks up on it, I might chew on something during one of my 'brain dead' days, which seem awfully common these last couple of years :/ |
| 13:29.39 | brlcad | actually, I thought that the list of rfp was a great page to put together regardless |
| 13:32.24 | ``Erik | http://www.freebsd.org/projects/ideas/ others have done it before :D |
| 13:32.24 | ``Erik | the bsd one actually grew out of phk's "jr kernel hacker todo" list |
| 14:09.17 | brlcad | yep, nothing new, I meant more just clearing out thoughts on actual attainable projects that would make a big impact |
| 14:10.50 | brlcad | the rfp page is actually fairly well ordered towards what is most important at the moment too |
| 14:18.04 | *** mode/#brlcad [+o brlcad] by ChanServ | |
| 15:40.14 | CIA-7 | BRL-CAD: 03erikgreenwald * 10rtcmp/adrt/adrt.c: handle failed region in nmg conversion |
| 15:48.12 | CIA-7 | BRL-CAD: 03erikgreenwald * 10rtcmp/configure.ac: cvs BRL-CAD changed libtcl.so to libtcl8.5.so (on fbsd/linux... libtcl85.so on obsd and others) |
| 15:49.28 | CIA-7 | BRL-CAD: 03erikgreenwald * 10rtcmp/rtcmp.h: we cope with normals now, so don't have them marked as unused |
| 15:59.02 | *** join/#brlcad Elperion (n=Elperion@p54874E47.dip.t-dialin.net) | |
| 15:59.36 | *** join/#brlcad Elperion (n=Elperion@p54874E47.dip.t-dialin.net) | |
| 16:03.07 | CIA-7 | BRL-CAD: 03brlcad * 10brlcad/src/bwish/main.c: reorder |
| 16:29.50 | Maloeran | From BBC's history, the world's oldest person died at 114 on 29 Jan 07. On 15 March 2007, the world's oldest person turns 116. Find the error |
| 16:31.21 | clock_ | Died and then raised from the grave, a bit older (from decomposition) |
| 16:31.34 | clock_ | happens all the time, see Romeros movies |
| 16:33.32 | archivist | jurnalists are notorious for errors |
| 16:34.04 | archivist | if you want some fun email them about it see if you get it updated |
| 16:34.06 | clock_ | maybe the world's oldest person is the journalist |
| 16:34.25 | clock_ | and the brain doesn't serve as good as when he was young ;-) |
| 16:49.45 | ``Erik | clock: bug 1657171 (rtedge renders bullshit), the png file seems to be truncated? 24709 bytes, MD5 (bullshit.png) = 3ce18b1b378dd81e25c20d1a44f3f3c9 |
| 16:49.59 | ``Erik | (unless my browser is being retarded, which may very well be) |
| 16:50.43 | clock_ | ``Erik: URL? |
| 16:50.59 | ``Erik | http://sourceforge.net/tracker/index.php?func=detail&aid=1657171&group_id=105292&atid=640802 |
| 16:54.38 | CIA-7 | BRL-CAD: 03erikgreenwald * 10rtcmp/ (Makefile.am rtcmp.c dry/dry.c dry/dry.h): Add a 'dry run' engine to measure overhead and "warm up" the partition manager. Should abate worries about function call overhead. |
| 16:55.56 | CIA-7 | BRL-CAD: 03erikgreenwald * 10rtcmp/rt/rt.c: silence overlap reporting |
| 16:57.32 | clock_ | ``Erik: It's even broken on my disk. I don't know why |
| 16:58.35 | clock_ | ``Erik: But look at http://ronja.twibright.com/3d/ |
| 16:58.37 | clock_ | seach for chimney |
| 16:58.51 | ``Erik | always pimpin' your site ;) |
| 16:59.18 | clock_ | And then look at the lower left picture of the five |
| 16:59.36 | clock_ | The rtedge picture is just downscaled with image magick, and when you click you see the rt picture |
| 17:00.00 | ``Erik | the original rtedge image isn't available? |
| 17:00.04 | clock_ | ``Erik: you can see the notches on the downscaled one too |
| 17:00.12 | clock_ | I would have to generate it manually |
| 17:00.36 | ``Erik | ok, I'll just follow your instructions in the pr and see if it looks mucked up to me :) |
| 17:02.47 | clock_ | yeah try how long does it take? |
| 17:02.52 | clock_ | I'm curious :) |
| 17:03.01 | ``Erik | huh? to render on my machine? or? |
| 17:03.14 | clock_ | yes to set up the given version and download and render |
| 17:03.42 | clock_ | This is why it's good to have technology completely open |
| 17:03.58 | ``Erik | well, it's tracing now |
| 17:04.14 | clock_ | Can you imagine "Hi we are Samsung we are using BRL-CAD to model mobile phone shell but no sorry we can't give you the .g file it's strictly confidential" |
| 17:04.19 | ``Erik | 1.4 seconds |
| 17:05.07 | clock_ | proprietary == Debugging Mission Impossible |
| 17:08.38 | clock_ | ``Erik: are you getting those notches too? |
| 17:09.29 | ``Erik | no |
| 17:09.38 | clock_ | ``Erik: send me your picture |
| 17:09.42 | clock_ | what's your BRL-CAD version? |
| 17:10.07 | clock_ | 7.8.4? |
| 17:10.17 | clock_ | ``Erik: clock at twibright dot com |
| 17:10.17 | ``Erik | 7.9.0 |
| 17:10.27 | clock_ | ``Erik: can you try with 7.8.4? |
| 17:10.40 | ``Erik | lemme find a box runnign it, heh |
| 17:10.44 | clock_ | To see if it's a bug that was fixed or a bug which doesn't reproduce in your situation? |
| 17:11.11 | clock_ | Can I already download 7.9.0? |
| 17:11.18 | clock_ | The notches look ugly on the website :) |
| 17:12.24 | ``Erik | 7.9.0 is the working name for cvs HEAD |
| 17:12.31 | ``Erik | 7.10.0 should be out 'very soon now' |
| 17:12.59 | ``Erik | 7.8.0 didn't show the notches |
| 17:13.00 | clock_ | they should put the money spent on SDI into BRL-CAD ;-) |
| 17:13.09 | clock_ | yes I remember they weren't there before |
| 17:13.15 | clock_ | but I wasn't sure |
| 17:13.38 | clock_ | BRL-CAD - where the U.S. Army rulez ;-) |
| 17:14.10 | *** join/#brlcad Maloeran (n=maloeran@glvortex.net) | |
| 17:14.39 | *** join/#brlcad IriX64 (n=mario_du@bas3-sudbury98-1168056670.dsl.bell.ca) | |
| 17:15.02 | ``Erik | hrmmmm |
| 17:22.46 | IriX64 | masochist :) |
| 17:23.15 | clock_ | ``Erik: My machine is LSB first |
| 17:23.48 | ``Erik | the machines I was testing on are mostly wrong endian... opterons |
| 17:24.05 | clock_ | opterons are big endians? |
| 17:24.13 | ``Erik | no, small endian |
| 17:25.38 | clock_ | If you have a big endian machine and 32 bit number x stored in memory addresses 0,1,2,3, how much is (unsigned long)(void *)&x? |
| 17:26.22 | clock_ | Is it 0, 3, or 4? |
| 17:27.04 | ``Erik | huh? |
| 17:27.23 | ``Erik | big endian will store 0x11223344 as { 0x11, 0x22, 0x33, 0x44 } |
| 17:27.37 | clock_ | that's not exactly an answer to my question |
| 17:28.28 | clock_ | ``Erik: do you understand C? |
| 17:29.18 | ``Erik | yes, sorry, distracted at the moment |
| 17:29.29 | clock_ | ``Erik: then you should understand my question |
| 17:33.38 | Maloeran | clock_, 0x01020304 on big endian |
| 17:33.38 | clock_ | Maloeran: no I didn't say stored as values 0,1,2,3, but in memory addresses 0,1,2,3 |
| 17:33.38 | clock_ | memory address 0 is when all address bus wires are low. Memory address 1 is one byte higher etc. |
| 17:33.38 | Maloeran | I sure know C and the "in memory addresses 0,1,2,3" is not clear at all |
| 17:33.38 | IriX64 | clock_ try sizeof(unsigned long) and sizeof(void*) |
| 17:34.07 | Maloeran | clock_, there's no conversion or byte swapping between considering an integer as pointer or integer |
| 17:34.19 | Maloeran | For the processor, a pointer is always just an integer anyway |
| 17:34.39 | Maloeran | Well "always" on the majority of platforms, before Erik or brlcad gets pedantic on me :) |
| 17:34.46 | clock_ | In other words, do pointer pointing at multi-byte objects in bug endian machines point at the beginning of the object, at the last byte of the objectt, or one byte beyond the end of the object? |
| 17:35.09 | brlcad | :) |
| 17:35.54 | Maloeran | References hold the address to the beginning of the chunk of memory, the first byte of your variable |
| 17:36.12 | clock_ | Then on big endian machine if you do this |
| 17:36.13 | clock_ | long x |
| 17:36.20 | clock_ | x=37 |
| 17:36.38 | clock_ | printf("%d",*(unsigned char *)(void *)&x); |
| 17:36.41 | clock_ | it prints 0? |
| 17:37.57 | Maloeran | It will print 0, yes |
| 17:38.35 | Maloeran | ((unsigned char *)&x)[3] will give you 37 if sizeof(long)==4 of course |
| 17:38.50 | clock_ | On big endian machines if you want to cast a long object into shorter one (meaningfully), you have to perform a constant addition |
| 17:39.08 | clock_ | On little endian, you don't have to |
| 17:39.09 | Maloeran | Hum, I'm not following this statement |
| 17:39.22 | clock_ | therefore little endian machines are faster and therefore better. |
| 17:39.32 | Maloeran | Oh, you mean casting a 64 bits int to 32 bits or so |
| 17:40.01 | clock_ | Maloeran: yes, on big endian machine you have to insert one ADD instruction for the [3], so all programs that do such kind of operation run slower |
| 17:40.21 | Maloeran | Not exactly. First, all/most memory references instructions contain an "offset" |
| 17:40.46 | Maloeran | Second, accessing memory in this manner after a write will trash your cache and stall, you better use instructions for conversion |
| 17:41.20 | clock_ | depends on how the cache and pipeline is implemented |
| 17:41.26 | Maloeran | In some cases though, this could be an advantage, yes |
| 17:41.27 | clock_ | if it's implemented with this case in mind, it won't stall |
| 17:41.45 | clock_ | It won't trash and stall also in case there is no cache/pipeline, like for example the Z80 processor |
| 17:41.52 | clock_ | (which is a little endian machine) |
| 17:42.01 | Maloeran | Eheh okay. I usually have amd64 in mind |
| 17:42.13 | clock_ | Z80 is turing equivalent to AMD64 |
| 17:42.25 | clock_ | ;-) |
| 17:42.37 | clock_ | I wanted to point out the asymmetry between big and little endian machines |
| 17:42.51 | IriX64 | turing? nice language :) |
| 17:43.00 | Maloeran | Big endian also has its advantages in certain cases |
| 17:43.01 | clock_ | Some people say they are symmetric and therefore there is no inherent advantage and therefore all holy wars are pointless |
| 17:43.38 | clock_ | I just showed that there is an advantage, the big endian is theoretically more kinky and the little one smoother |
| 17:43.38 | clock_ | Maloeran: it's name being 2 bytes shorter? |
| 17:43.38 | Maloeran | With a proper instruction set, they really are equivalent |
| 17:43.39 | clock_ | 3 bytes |
| 17:44.00 | Maloeran | clock_, you could for example search a sequence of bytes while crossing int64_t boundaries |
| 17:44.01 | clock_ | To make them equivalent, one would have to define pointer to point beyond |
| 17:44.14 | Maloeran | That will stall as well but will end up faster |
| 17:44.19 | clock_ | Maloeran: what does it mean? |
| 17:44.59 | Maloeran | If you are looking for a specific sequence of 8 chars, you can just read a single int64_t by incrementing one byte at a time, single comparison to see if your 8 chars are there |
| 17:45.01 | clock_ | Maloeran: On little endian I can also seach a sequence of bytes while corssing int64_t boundaries (or any other boundaries) - in a string it really doesn't matter how it's aligned. |
| 17:45.04 | Maloeran | You can't do that with little endian |
| 17:45.29 | clock_ | Maloeran: you mean read each byte in memory 4 times? |
| 17:46.04 | clock_ | sorry 8 times for all overlapping possibly unaligned int64_t's that contain that memory byte? |
| 17:46.23 | Maloeran | Yes, the memory accesses would be very much non-aligned |
| 17:47.31 | IriX64 | brlcad: i don't know *why, but the check for opengl functionality from 7.6.2 inserted into 7.8.4's configure.ac works, the one supplied does *not work and i can't figure it out. |
| 17:47.34 | Maloeran | Anyway, these are really details. I have far bigger complains about architectures and ISAs than the endianess :) |
| 17:49.09 | clock_ | Maloeran: which? |
| 17:49.58 | Maloeran | The complete bloat of a 16 bits real mode ISA designed in 1975, extended to 32 bits, to protected mode, to 64 bits, to long mode |
| 17:50.24 | Maloeran | The SSE mess in comparison to Altivec or Itanium |
| 17:51.15 | ``Erik | (back, btw) |
| 17:52.06 | ``Erik | (and people who blindly cast/copy to smaller data sizes shouldn't be allowed to touch computers *cough*) |
| 17:52.40 | Maloeran | Darn. Don't look at my optimized SSE code :) |
| 17:53.01 | clock_ | Is there any version older than 7.8.4 publicly available? |
| 17:53.13 | ``Erik | um, all of them? |
| 17:53.28 | IriX64 | think older releases are on sf clock_ |
| 17:53.38 | clock_ | I could find only 7.8.4 |
| 17:53.51 | ``Erik | 7.8.4 64b on opteron does not exhibit the rtedge issue... |
| 17:53.51 | clock_ | oh sorry I meand newer |
| 17:53.58 | IriX64 | look for older releases of this project on the download page |
| 17:54.09 | ``Erik | (of course, I'm using /dev/Xl instead of outputting to a file... heh) |
| 17:54.24 | clock_ | ``Erik: I have OpenBSD Pentium III |
| 17:54.29 | ``Erik | 7.8.4 is the most recent official release. |
| 17:54.40 | clock_ | ``Erik: output into a file, please |
| 17:55.30 | clock_ | ``Erik: did I write into the report that the same problem occurs on Linux> |
| 17:55.31 | clock_ | ? |
| 17:56.40 | ``Erik | http://ftp.brlcad.org/~erik/chimney.png |
| 17:56.59 | ``Erik | no, you didn't mention any os/arch at all |
| 17:57.25 | IriX64 | wtf how do you get inside it? |
| 17:57.29 | clock_ | ``Erik: http://ftp.brlcad.org/~erik/chimney.png contains the bug |
| 17:57.33 | ``Erik | hmmmmmm, there is some warble at the top, yes |
| 17:57.45 | IriX64 | sorry man.. |
| 17:58.03 | clock_ | ``Erik: the 1st, 2nd and 4rd edge from the top |
| 17:58.10 | ``Erik | iiiinteresting |
| 17:58.11 | brlcad | that image has at least two bugs |
| 17:58.26 | archivist | impossible bolt head on the left of pic |
| 17:59.46 | clock_ | brlcad: rtedge in 7.8.4 produces crap |
| 17:59.53 | brlcad | the "hiccups" on the long rod and the lower ouside horizontal edge of the far beam |
| 17:59.56 | clock_ | ``Erik: show the image from the 7.9.0 |
| 18:01.07 | brlcad | the bolt heads are also flawed, but that's the depth tolerance issue |
| 18:01.08 | ``Erik | oh, now this is VERY interesting |
| 18:01.52 | brlcad | that almost looks like corrupted framebuffer on some of those edges |
| 18:02.27 | clock_ | Whistler orders U.S. Army to design their slopes and U. S. Army uses BRL-CAD to design the slopes. U. S. Army asks "and how do you want to do it?" Whistler says "we want just straight plain downhill slopes". After they prepare the slopes, Whistler gets a flood of thankful letters from snowboarders "Dear Whistler, thanks for the great snowpark!" |
| 18:02.30 | ``Erik | heh |
| 18:03.13 | ``Erik | check this out, if I write to a file and use the display framebuffer at the same time... (-F/dev/Xl), then I pix-fb the .pix file |
| 18:03.16 | ``Erik | they're quite different |
| 18:03.28 | ``Erik | the display framebuffer is correct, the saved one is not |
| 18:03.29 | brlcad | ``Erik: if you're debugging that, the -Q option is gold |
| 18:03.43 | ``Erik | to rt? or pix-fb? or? |
| 18:03.49 | brlcad | rt* |
| 18:04.24 | ``Erik | undocumented, swank :D 'query one pixel' |
| 18:04.28 | clock_ | looks like the cards get a bit shuffled on the way |
| 18:04.54 | brlcad | e.g. render to framebuffer using -F/dev/Xl, then right click on the bad pixel to get a coordinate .. then rerender with exact same params adding -Q x,y .. will turn on debugging and only shoot that single ray |
| 18:04.58 | clock_ | cause it's not pixels zeroed out or set, but they are moved around and the number of black and white ones stays in the right proportion |
| 18:05.10 | ``Erik | heh, it's all good, clock, we still have card sorters around here O.o just keep all appendages inside while moving |
| 18:05.11 | brlcad | it's documented in rt's manpage |
| 18:05.15 | clock_ | and the corruption is local |
| 18:06.10 | clock_ | aren't two processes writing into one framebuffer at once and not getting the things quite right? |
| 18:06.13 | brlcad | ahh.. so -o with -F *is* corrupting.. that's a new bug |
| 18:06.27 | ``Erik | well, -o is corrupt either way |
| 18:06.30 | ``Erik | -F is not |
| 18:06.35 | brlcad | even by itself? |
| 18:06.38 | ``Erik | yes |
| 18:06.54 | brlcad | hmm |
| 18:07.29 | clock_ | Does 7.9.0 do the bug too? |
| 18:07.30 | brlcad | looks like random off-by-1 fseek errors |
| 18:07.40 | ``Erik | yes, head still does it |
| 18:07.48 | clock_ | brlcad: but it's vertically off by 1 |
| 18:08.06 | ``Erik | it's army code, clock, it seeks up and down, not left and right :D |
| 18:08.12 | clock_ | lol :) |
| 18:08.32 | clock_ | push ups up and down? |
| 18:08.37 | ``Erik | in soviet america, buffer fseeks you |
| 18:08.56 | clock_ | soviet america == Santa Monica? |
| 18:09.01 | clock_ | Soviet Monica? |
| 18:09.06 | brlcad | ideally, there should be no fseek's with -o .. that's broken inherintly |
| 18:09.30 | brlcad | makes things like -o /dev/stdout | pix-png unhappy |
| 18:09.41 | clock_ | Maybe the tape reels are lose? |
| 18:10.34 | clock_ | I'm leaving for a gym |
| 18:11.00 | IriX64 | hi i'm gym :) |
| 18:11.02 | clock_ | have fun with broken pictures |
| 18:11.10 | clock_ | cu later |
| 18:19.41 | ``Erik | ok, uh |
| 18:21.33 | ``Erik | that ... heh, yeah, more proof that the hell project will never be scalable. what was that boy smokin' when he write this? |
| 18:51.42 | ``Erik | man, I got a fix, but I so don't want to commit it |
| 18:51.43 | brlcad | what was it? |
| 18:52.27 | ``Erik | when it writes to the FB, it uses the ap_y value to point to the right place, but the output file write doesn't check to see if things are coming in order, it locks and writes |
| 18:52.39 | ``Erik | so when scanlines came out of order, the file got out of order |
| 18:52.51 | brlcad | aha |
| 18:53.26 | ``Erik | a "po' boy" spinlock solves the output... but it's ugly and will starve some |
| 18:53.29 | brlcad | it should probably "wait" for the next line so it doesn't seek |
| 18:54.05 | brlcad | or just wait until everything is done |
| 18:55.40 | CIA-7 | BRL-CAD: 03erikgreenwald * 10brlcad/src/rt/viewedge.c: "po' boy" spinlock to avoid scanlines being written out of order (race condition). Fixes PR 1657171. |
| 18:55.41 | ``Erik | I was going to wait and write in frame_end(), but that'd require an extra buffer to hold the results (if there's no FB) |
| 18:56.06 | brlcad | hmm.. good point |
| 18:56.23 | brlcad | that would be bad for rendering massive images, though I don't think we can do that still for other reasons |
| 18:56.43 | IriX64 | ``Erik why not just a sem (block the write) to say go ahead and write. |
| 18:57.37 | IriX64 | errr its not threaded forget it :) |
| 18:57.44 | ``Erik | um, it does block the write |
| 18:57.58 | IriX64 | sorry man ill shut up. |
| 18:58.04 | ``Erik | but scanline 2 would be done and get written, then scanline 1 would finish... |
| 18:58.05 | brlcad | it can work by just seeking to the right place.. but would be nice to kill both bugs at once since they're related |
| 18:58.13 | ``Erik | there is no fseek in rtedge |
| 18:58.24 | brlcad | hmm |
| 18:58.28 | brlcad | there should be |
| 18:58.35 | brlcad | it the app back-end |
| 18:58.41 | ``Erik | there is in view.c, but not viewedge.c |
| 18:58.53 | ``Erik | both use fairly different methods to write the output :/ |
| 18:59.44 | brlcad | gah |
| 18:59.46 | brlcad | so they are |
| 18:59.59 | brlcad | bad juju, no twinkie for you |
| 19:00.33 | brlcad | and no way that'd be refactored in time for release |
| 19:00.42 | brlcad | at least and be tested |
| 19:01.15 | brlcad | just one issue left with btclsh, btw, looking at that now |
| 19:01.33 | brlcad | otherwise we build and run clean across the board it seems |
| 19:02.10 | brlcad | btclsh halts distcheck, so once that's taken care of, we should be green to go live |
| 19:05.14 | ``Erik | bad juju? huh? you disapprove of my q&d hack? :D |
| 19:06.27 | brlcad | no no, i meant "ffs ffs, more code to refactor" |
| 19:06.30 | brlcad | not your stuff |
| 19:06.41 | brlcad | all the raytracers should be using a library backend |
| 19:06.43 | ``Erik | heh, I'm not terribly keen on my hack :/ |
| 19:07.01 | ``Erik | but *shrug* yes, they should use common code to write to fb and file |
| 19:09.19 | brlcad | heh, if *you* don't like it.. how you think i'll feel? :) |
| 19:09.50 | CIA-7 | BRL-CAD: 03erikgreenwald * 10brlcad/TODO: note refactor for raytracer output |
| 19:09.53 | brlcad | but hey, one is outright flawed and problematic .. if it fixes something without causing another problem, maybe put it with a note, or keep at it ;) |
| 19:10.10 | ``Erik | heh, I d'no, some practices get me more spun up than you... this might be one of them. *shrug* look at the diff, if you have a better approach, knock yourself out :D |
| 19:10.46 | brlcad | always depends though, whatever ;) |
| 19:11.34 | ``Erik | the pathalogical case is what makes me queasy about it... |
| 19:12.53 | ``Erik | if you run n threads and every nth scanline takes longer than the next n-1, it'll tank down to single threaded performance... |
| 19:13.12 | ``Erik | or, um, 2 threaded performance |
| 19:13.16 | ``Erik | *ponder* |
| 19:13.28 | ``Erik | somewhere between 1 and 2... on a 1024 core machine, that's not so good |
| 19:13.48 | ``Erik | hrm |
| 19:14.24 | ``Erik | are multiple frame renderings broken up so the frames are serial? or can it start on the next frame before it's done with one? |
| 19:14.59 | brlcad | run it through the benchmark and see if you get a difference |
| 19:15.30 | brlcad | you can feed benchmark different tracers, just will get WRONG WRONG .. results, but should still give metrics |
| 19:15.43 | ``Erik | heh, I didn't see any difference with chimney, very few came in out of order :) |
| 19:15.50 | brlcad | RT=rtedge benchmark |
| 19:16.11 | brlcad | could try that with -P1 and -P10 on something like orthus |
| 19:16.29 | brlcad | display the buffer over X.. massive out of orders |
| 19:16.48 | brlcad | u* too |
| 19:30.09 | IriX64 | same for the tube start at 768x1024 and go up one line at a time. |
| 19:38.00 | Maloeran | The raytracer's distributed processing seems to scale reasonably well here, I saturate my home 100mbits network too fast though |
| 19:38.50 | Maloeran | Although the graph prep isn't scalling at all just because of some global mutex for memory alloc() & free() |
| 19:40.00 | ``Erik | I told you about my cache issues a while back, right? |
| 19:40.33 | Maloeran | Hum, I don't think you did |
| 19:42.05 | ``Erik | hrm, I could move cache files between machines of the same endian without issue, but to one of a different endian seemed to spin or hang or something... let a fast opteron chew on a big endian cache file overnight... |
| 19:43.24 | Maloeran | Oh. Thanks, it's supposed to work, there's a glitch somewhere then |
| 19:45.25 | Maloeran | Can you send me a big endian cache file? |
| 19:48.22 | ``Erik | lemme pull a CYA move first, heh |
| 19:49.55 | Maloeran | What's a CYA? |
| 19:49.55 | Maloeran | Oh, got it, second definition of urban dictionary |
| 19:51.26 | ``Erik | hm, lee's not in the office, since he's both the 'official' contract POC and security bitch, I want him to ok sending you a generated file... so'z if someone raises a stink I can point at him instead of getting in trouble :D |
| 19:52.31 | Maloeran | Bah. No big deal, send one from home built from any prehistoric big endian machine |
| 19:53.16 | ``Erik | heh, and see if it compiles and runs on my ancient g3 laptop? 700 mhz of ppc fury running osX.2 ? :D |
| 19:53.27 | Maloeran | Sounds like a plan :) |
| 19:53.41 | ``Erik | are things almost ready to move into the BRL-CAD cvs tree? |
| 19:54.07 | Maloeran | The "integration within BRL-CAD" part is very vague, but... |
| 19:54.20 | Maloeran | I'm thinking I would rather keep a separate CVS |
| 19:54.50 | Maloeran | And just push the updates there on a regular basis |
| 19:57.39 | Maloeran | It seems SURVICE would still like to make the code closed-source with unlimited use rights within the DoD. From what I heard, Lee was fine with the idea for a moment... and the situation changed somehow |
| 19:58.24 | Maloeran | It would allow Survice to fund, since the ARL won't pursue, so it might have been better for everyone. I really need a break from raytracing though |
| 19:59.21 | ``Erik | hrm *shrug* I'm just trying to make sure everything is buttoned up and delivered in the next couple weeks :) |
| 20:02.57 | ``Erik | brlcad: on a fbsd 4core opteron, it went from 15874 vgr's to 15750, so a 0.8% hit for correct #'s... there might be that much wiggle in just benchmarking alone *shrug* |
| 20:03.44 | ``Erik | rt.run:*vgr somemachine.arl.army.mil 25723.68 17316.87 15971.53 14880.22 21288.39 61.55 15873.70 |
| 20:03.44 | ``Erik | rtnew.run:*vgr somemachine.arl.army.mil 25149.83 17474.88 16003.12 14591.12 21216.13 64.19 15749.87 |
| 20:05.06 | ``Erik | hrm, no, wait... heh, I had naughtiness to expose the bug better still plugged in... running again... |
| 20:05.56 | ``Erik | (400 threads instead of 4) |
| 20:13.47 | CIA-7 | BRL-CAD: 03jlowenz * 10brlcad/include/ (vector_x86.h vector_fpu.h vector.h): add support for folding a vector into a single value. make the default constructor assume aligned data. |
| 20:15.47 | ``Erik | new VGR is 15563, so 2% hit for 'correctness' |
| 20:16.06 | CIA-7 | BRL-CAD: 03jlowenz * 10brlcad/include/brep.h: implement the bounding volumes in C++, and move the definition to g_nurb.cpp |
| 20:19.51 | CIA-7 | BRL-CAD: 03jlowenz * 10brlcad/src/librt/g_brep.cpp: implement the bounding volumes in C++, leaf nodes point to faces in brep model. add support for implementation of goldsmith and salmon's bvh heuristic (not completed). |
| 21:03.44 | *** join/#brlcad cad74 (n=50aba2f5@bz.bzflag.bz) | |
| 21:13.40 | CIA-7 | BRL-CAD: 03erikgreenwald * 10rtcmp/rt/rt.c: add "line of sight" depth |
| 21:15.11 | CIA-7 | BRL-CAD: 03erikgreenwald * 10rtcmp/adrt/adrt.c: Segment building (punty). Fixed "null region" error. |
| 21:24.56 | ``Erik | it commits the code or it gets the hose again |
| 21:36.53 | *** join/#brlcad IriX64 (n=mario_du@bas3-sudbury98-1168048430.dsl.bell.ca) | |
| 21:55.49 | Twingy | fig newtons |
| 21:56.16 | Twingy | they obey the first law of physics, now to test the 2nd |
| 22:20.14 | *** join/#brlcad cad67 (n=45ff7061@bz.bzflag.bz) | |
| 22:20.56 | cad67 | test, ignore. |
| 22:26.04 | IriX64 | http://www.pastebin.ca/index.php <=== anybody know whats wrong with this? |
| 22:27.14 | louipc | :D |
| 22:27.22 | IriX64 | :) |
| 22:28.03 | ``Erik | um, yeah, I know what's wrong with that |
| 22:28.08 | ``Erik | you pasted the 'submit' page, not the result page |
| 22:28.14 | ``Erik | that's what's wrong :D |
| 22:28.25 | IriX64 | ermf |
| 22:29.04 | IriX64 | http://www.pastebin.ca/396664 |
| 22:29.07 | IriX64 | try that. |
| 22:33.06 | ``Erik | usually, C macros don't have semicolons |
| 22:33.21 | ``Erik | but that looks legal to me *shrug* |
| 22:33.26 | IriX64 | trying to redefine that to a ; |
| 22:33.52 | IriX64 | haven't really exercised it. |
| 22:33.59 | ``Erik | then why are you asking what's wrong with it? heh |
| 22:34.17 | IriX64 | im patient enough to wait till this compile is done :) |
| 22:34.28 | IriX64 | just doesn't "look" right. |
| 22:35.30 | ``Erik | including semicolons looks odd |
| 22:36.07 | ``Erik | but a=3;;;;;; is legal C |
| 22:36.22 | louipc | just empty blocks eh? |
| 22:37.26 | IriX64 | all i get is a warning that bu_debug is redefined not identically so it should work. |
| 22:37.41 | IriX64 | took out the if else condition to test |
| 22:38.46 | ``Erik | if you're mucking around with BRL-CAD source code, then yes, there is a problem... if you put that in your own stuff, ... *shrug* |
| 22:38.57 | IriX64 | my stuff |
| 22:39.16 | ``Erik | then why are you using the bu_ prefix? |
| 22:39.35 | IriX64 | heh thought of you if you don't already ahve it. |
| 22:41.15 | IriX64 | anyway its probably inferior to yours but it too is yours if its useful. |
| 22:41.54 | ``Erik | I may be going out on a limb here, but I think everyone with commit access to the project has written that line of code before... |
| 22:42.25 | ``Erik | and bu_debug is an int flag, so you can switch it on and off without recompiling everything |
| 22:42.41 | IriX64 | as i said inferior to yours |
| 22:42.45 | ``Erik | line 1252 of include/bu.h |
| 22:43.06 | ``Erik | followed by the flag defines |
| 22:44.31 | IriX64 | err 1252 points me to parse.c |
| 22:44.56 | louipc | eh? |
| 22:45.05 | IriX64 | bu.h? |
| 22:45.42 | IriX64 | line 1252 says parse.c in a comment block |
| 22:46.34 | ``Erik | hm, 1252 in cvs head... |
| 22:46.51 | IriX64 | man no cvs here |
| 22:47.09 | IriX64 | source tarball |
| 22:47.10 | ``Erik | brlcad keeps mucking with it, heh |
| 22:47.14 | IriX64 | ah |
| 22:47.21 | ``Erik | it's in there, just use your editors search functionality |
| 22:47.46 | IriX64 | i will ill prollly learn something from it for which i thank in advance. |
| 23:38.24 | IriX64 | thats a debug system not an aid :) |
