| 00:00.27 | starseeker | brlcad: I take it bu_cv_hton* routines are preferred? |
| 00:03.55 | starseeker | hmm... |
| 00:04.37 | ``Erik | mmm, bits and such |
| 00:07.05 | ``Erik | I'm all sad, my mac doesn't like my joystick |
| 00:07.15 | ``Erik | I might have to write a driver :( |
| 00:07.23 | starseeker | uhoh |
| 00:07.42 | ``Erik | did it to get hsi joystick working on fbsd a long time ago |
| 00:08.31 | ``Erik | oh wow, what a perfect data loss... fios commercial had a couple audio clips, "you can record sh<blib> in one room and watch it in another" |
| 00:08.44 | ``Erik | I THINK he was saying "shows" |
| 00:08.51 | starseeker | heh |
| 00:08.57 | ``Erik | but the implied variant is... probably more accurate :D |
| 00:10.47 | ``Erik | NICE, "if (Indian == IND_NOTSET) {" ... |
| 00:11.32 | ``Erik | and lee commented on it and didn't fix it O.o back in '04 |
| 00:12.11 | starseeker | where's that? |
| 00:12.36 | ``Erik | convert.c, a while back |
| 00:12.42 | ``Erik | the bu_cv_ stuff |
| 00:13.10 | ``Erik | like, 23500 vintage |
| 00:13.18 | ``Erik | ~305 or so |
| 00:13.27 | ``Erik | 315, mebbe |
| 00:14.21 | ``Erik | between cvs2svn and "big honkin' reorg", it's not worth chasing down for blame |
| 00:14.53 | brlcad | starseeker: not particularly |
| 00:18.20 | brlcad | but no problem using them either |
| 00:22.52 | CIA-85 | BRL-CAD: 03brlcad * r37864 10/brlcad/trunk/src/librt/db5_io.c: use MATER_NO_ADDR instead of -1L with rt_color_addrec(), eliminate magicness. |
| 00:23.51 | starseeker | brlcad: out of curiosity, where was that article about increased efficiencies to be had when packing data into a buffer? |
| 00:25.42 | starseeker | (for pipe read/write) |
| 00:29.09 | CIA-85 | BRL-CAD: 03brlcad * r37865 10/brlcad/trunk/src/librt/db_lookup.c: remove -1L from comment, you're not allowed to look at the spoon. |
| 00:32.06 | ``Erik | read and write are system calls, they'll automatically surrender the thread in addition to the actual memcpy overhead |
| 00:33.12 | starseeker | I'm sure this is a dumb question, but having packed everything into a buffer, how do I get it back out into typed variables? |
| 00:33.31 | ``Erik | by unpacking the variable? |
| 00:33.35 | ``Erik | er, buffer |
| 00:33.43 | starseeker | how? |
| 00:34.52 | ``Erik | well, buf[0]=CMD; buf[1]=len, sprintf(buf+2, "%s", mystr); .... and on the othe rside, CMD=buf[0]; len=buf[1]; mystr = buf+2; ... |
| 00:36.23 | starseeker | what about getting an integer array out? |
| 00:37.04 | ``Erik | exactly reverse of how ya packed it? |
| 00:37.13 | starseeker | memcpy? |
| 00:37.26 | ``Erik | if that's how ya packed it, that's how ya unpack it |
| 00:37.59 | starseeker | has never tried a memcpy onto the address of an integer, sorry for dumb questions... |
| 00:38.05 | ``Erik | memcpy(buf+offset, myints, sizeof(int)*count); -> memcpy(myints, buf+offset, sizeof(int)*count); |
| 00:38.09 | ``Erik | bits is bits |
| 00:38.21 | starseeker | ok |
| 00:38.45 | ``Erik | if there's a network dealie, ya might want to do the ntohl/htonl dealie |
| 00:39.13 | ``Erik | but local pipe can eat it without the conversion cost |
| 00:39.55 | starseeker | was advised to do the network stuff by brlcad |
| 00:40.47 | ``Erik | well, pipe(), dup2(), ... those're local, and you can usually trust a cpu not to switch endian between programs |
| 00:41.12 | starseeker | nods - with framebuffers though you can have a remote target |
| 00:41.25 | ``Erik | yeh, um, ints? not chars? |
| 00:41.40 | starseeker | uint32_t, to be specific |
| 00:42.23 | ``Erik | endian mgmt will mean doing bit shifts, ors and ands if your cpu is not the same endian as network order... |
| 00:42.39 | ``Erik | and, uh, your cpu is not the same endian as network order. :( x86 is bass ackwards |
| 00:42.47 | starseeker | the hton doesn't take care of that? |
| 00:42.55 | ``Erik | it does, but there's overhead |
| 00:43.40 | ``Erik | htonl/ntohl is a no-op on big endian cpu's like the g5, power4, sparc, arm, etc... but x86 makes it work |
| 00:44.01 | starseeker | ah |
| 00:45.44 | ``Erik | look at, uh, libbu/htonf.c for what actually goes on |
| 00:46.40 | CIA-85 | BRL-CAD: 03starseeker * r37866 10/brlcad/trunk/src/libfb/if_tk.c: Give htonl and ntohl a try - no major cleanups yet but this tests out as not changing functionality. |
| 00:46.49 | starseeker | is willing to live with a little bitty overhead for this - we're already having to pipe the data around |
| 00:47.20 | ``Erik | if the cache can be fed well enough, it should be pretty damn fast on the x86... |
| 00:47.46 | ``Erik | the killer on recent x86 is keeping enough data available, the ALU sits around waiting for data most of the time |
| 00:48.04 | ``Erik | which is where tricks like duffs device come in handy :D |
| 00:48.14 | ``Erik | loop unrolling, etc |
| 00:52.16 | starseeker | nods |
| 00:54.11 | ``Erik | gcc does some fancy loop unrolling tricks when it figures out to do it *shrug* |
| 00:55.19 | ``Erik | (the dudes doing the gcc optimization know a bit more than me... painfully obvious after writing some basic optimizations and comparing my asm performance to the gcc compiled C output... |
| 00:55.23 | ``Erik | ) |
| 01:03.46 | ``Erik | funky, the interpreter version is 5.5x faster on my laptop than my server, even though the cpu si only 3x faster O.o there might be actual architectural differences between the p3 and core duo |
| 01:04.10 | ``Erik | (brainfuck is fun!) |
| 01:26.27 | CIA-85 | BRL-CAD: 03starseeker * r37867 10/brlcad/trunk/src/libfb/if_tk.c: OK, memcpy to and from a single buffer for pipe seems to be OK - next up will be a less braindead way to handle said buffers... |
| 01:34.31 | starseeker | weird - bu_malloc doesn't seem to function if I just substitute it in for the constant definitions. |
| 01:45.46 | starseeker | ah |
| 01:48.07 | CIA-85 | BRL-CAD: 03starseeker * r37868 10/brlcad/trunk/src/libfb/if_tk.c: Don't want to hard code buffer sizes, so call in malloc and free (bu_malloc doesn't seem to work in this context.) |
| 01:56.21 | CIA-85 | BRL-CAD: 03starseeker * r37869 10/brlcad/trunk/src/libfb/if_tk.c: Chop out some dead code. |
| 02:00.12 | ``Erik | so, uh, this one time, in band camp |
| 02:04.41 | starseeker | hmm? |
| 02:06.12 | ``Erik | quietly making noise... |
| 03:08.12 | *** join/#brlcad s00p (~girI@unaffiliated/n00p) | |
| 03:10.48 | s00p | what language is brlcad written in? |
| 03:11.41 | ``Erik | mostly C, a lot of c++ and tcl |
| 03:13.59 | s00p | I'm assuming the C and C++ does not compile together, or it'd be C++ only. Correct? |
| 03:17.59 | ``Erik | c++ is slowly encroaching |
| 03:19.10 | s00p | So, unless those modules written in C++ are compiled separately from the C code, it's all C++. |
| 03:22.31 | brlcad | s00p: reason for the questions? |
| 03:23.09 | brlcad | we basically compile it all together |
| 03:23.16 | s00p | I'm curious as to what languages the project makes use of before I download it. The project page states C, C++, Java, PHP, Tcl, Unix Shell. |
| 03:23.42 | s00p | Is that correct? |
| 03:23.52 | brlcad | but conventionally, there is a separation of how c++ is integrated |
| 03:24.10 | s00p | I figured |
| 03:24.13 | brlcad | e.g., our C API has no C++ism exposed, but the C libraries make use of C++ in their implementation |
| 03:24.56 | brlcad | Java is completely optional, PHP is insignificant, Unix shell is very minor on the installed side |
| 03:25.18 | brlcad | majority is C/C++ and Tcl/Tk |
| 03:26.06 | ``Erik | we've accumulated c++ism :( |
| 03:26.08 | s00p | Wait |
| 03:26.12 | s00p | I'm confused |
| 03:26.18 | s00p | are the C libraries written in C? |
| 03:28.48 | brlcad | predominantly, yes |
| 03:29.04 | s00p | but they have -some- C++ in them? |
| 03:30.15 | brlcad | we have more than 20 libraries |
| 03:30.25 | brlcad | yes, *some* of them have C++ in them :) |
| 03:30.30 | s00p | ok |
| 03:31.03 | s00p | thankyou |
| 03:31.04 | brlcad | most don't but at least a couple do |
| 03:32.03 | brlcad | s00p, no problem, but curious about why |
| 03:32.17 | s00p | student |
| 03:32.23 | s00p | looking for a project to study |
| 03:32.41 | brlcad | what kind of project? |
| 03:32.49 | brlcad | or what kind of study? |
| 03:33.04 | s00p | C programming |
| 03:33.46 | s00p | thinking of working on UnrealIRCd. That should do it (providing I don't edge near 4.x) |
| 03:34.24 | brlcad | what led you to BRL-CAD in the first place? |
| 03:34.50 | s00p | sourceforge |
| 03:34.53 | s00p | of course |
| 03:35.39 | *** part/#brlcad s00p (~girI@unaffiliated/n00p) | |
| 03:35.42 | brlcad | ah, okay |
| 03:44.51 | brlcad | interesting.. http://www.ohloh.net/p/brlcad/analyses/latest |
| 03:45.02 | brlcad | nice balanced language graph :) |
| 03:45.19 | brlcad | shame there's still not a way to exclude directories yet |
| 04:03.58 | *** part/#brlcad cjdevlin (~devlin@99-74-181-148.lightspeed.cicril.sbcglobal.net) | |
| 04:20.09 | *** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni) | |
| 04:20.34 | CIA-85 | BRL-CAD: 03brlcad * r37870 10/brlcad/trunk/include/ (Makefile.am rtfunc.h): declare functab functions, identical to what they currently are and add to install. |
| 04:23.15 | *** join/#brlcad Nohla (~jesica@201.255.227.172) | |
| 04:23.29 | CIA-85 | BRL-CAD: 03brlcad * r37871 10/brlcad/trunk/include/brlcad.h: include rtfunc.h |
| 04:50.50 | *** join/#brlcad akafubu (~akafubu@unaffiliated/akafubu) | |
| 04:52.13 | CIA-85 | BRL-CAD: 03brlcad * r37872 10/brlcad/trunk/include/rtfunc.h: expand comments |
| 05:34.33 | CIA-85 | BRL-CAD: 03brlcad * r37873 10/brlcad/trunk/include/rtfunc.h: add _obj_ to naming convention (at least for now) to avoid conflicting with rt_prep() and add missing header ifndef wrapping. |
| 05:39.14 | *** join/#brlcad Stattrav (~Stattrav@202.3.77.161) | |
| 05:56.27 | CIA-85 | BRL-CAD: 03brlcad * r37874 10/brlcad/trunk/ (4 files in 3 dirs): add the first of functab refactorings, obj_prep.c containing rt_obj_prep(). |
| 05:58.09 | CIA-85 | BRL-CAD: 03brlcad * r37875 10/brlcad/trunk/src/librt/primitives/obj_prep.c: one more sanity, make sure not null |
| 05:58.54 | CIA-85 | BRL-CAD: 03brlcad * r37876 10/brlcad/trunk/src/librt/: comb renamed to prcomb |
| 06:00.43 | CIA-85 | BRL-CAD: 03brlcad * r37877 10/brlcad/trunk/include/rtfunc.h: remove stray unnecessary register keyword |
| 06:04.17 | CIA-85 | BRL-CAD: 03brlcad * r37878 10/brlcad/trunk/ (4 files in 3 dirs): add rt_obj_shot() interface via obj_shot.c to the build, functab hook. |
| 06:10.09 | CIA-85 | BRL-CAD: 03brlcad * r37879 10/brlcad/trunk/include/rtfunc.h: make all funcs return an int code so we can test for success, even if the funcs primary/only purpose is to cause side effects. |
| 06:10.56 | CIA-85 | BRL-CAD: 03brlcad * r37880 10/brlcad/trunk/ (4 files in 3 dirs): add rt_obj_print, rt_functab refactoring |
| 06:15.53 | CIA-85 | BRL-CAD: 03brlcad * r37881 10/brlcad/trunk/ (4 files in 3 dirs): add rt_obj_norm, rt_functab refactoring |
| 06:20.21 | CIA-85 | BRL-CAD: 03brlcad * r37882 10/brlcad/trunk/ (4 files in 3 dirs): add rt_obj_uv, rt_functab refactoring |
| 06:22.51 | CIA-85 | BRL-CAD: 03brlcad * r37883 10/brlcad/trunk/ (4 files in 3 dirs): add rt_obj_curve, rt_functab refactoring |
| 06:35.58 | CIA-85 | BRL-CAD: 03brlcad * r37884 10/brlcad/trunk/ (4 files in 3 dirs): add rt_obj_free (this may replicate rt_free_soltab(), needs review), rt_functab refactoring |
| 06:41.54 | CIA-85 | BRL-CAD: 03brlcad * r37885 10/brlcad/trunk/ (4 files in 3 dirs): add rt_obj_plot for rt_functab refactoring. looks like it's the first to use the rt_db_internal for the id.. |
| 06:46.29 | CIA-85 | BRL-CAD: 03brlcad * r37886 10/brlcad/trunk/ (3 files in 2 dirs): does not seem right at all to be returning an array of segs. looks like it should probably be a pointer to a seg instead. |
| 06:55.52 | CIA-85 | BRL-CAD: 03brlcad * r37887 10/brlcad/trunk/ (4 files in 3 dirs): added rt_obj_vshot for rt_functab refactoring. definitely needs some work as the segp is indeed an array of segs but should be an array of pointers to segs or something else entirely. |
| 07:16.23 | CIA-85 | BRL-CAD: 03brlcad * r37892 10/brlcad/trunk/ (4 files in 3 dirs): provide rt_obj_export supporting both v4 and v5 callbacks, rt_functab refactoring |
| 07:16.27 | CIA-85 | BRL-CAD: 03brlcad * r37891 10/brlcad/trunk/ (4 files in 3 dirs): provide rt_obj_import() supporting both v4 and v5 callbacks, rt_functab refactoring |
| 07:16.28 | CIA-85 | BRL-CAD: 03brlcad * r37889 10/brlcad/trunk/ (4 files in 3 dirs): add rt_obj_tnurb, rt_functab refactoring |
| 07:16.30 | CIA-85 | BRL-CAD: 03brlcad * r37888 10/brlcad/trunk/ (4 files in 3 dirs): add rt_obj_tess, rt_functab refactoring |
| 07:16.31 | CIA-85 | BRL-CAD: 03brlcad * r37890 10/brlcad/trunk/include/rtfunc.h: remove version specialization for v4/v5. just have one import/export routine. |
| 07:19.59 | CIA-85 | BRL-CAD: 03brlcad * r37893 10/brlcad/trunk/ (4 files in 3 dirs): provide rt_obj_ifree although need to make sure it's not basically a duplicate of rt_db_free_internal() |
| 07:26.47 | CIA-85 | BRL-CAD: 03brlcad * r37894 10/brlcad/trunk/ (5 files in 3 dirs): add rt_obj_get and rt_obj_adjust, for rt_functab refactoring |
| 07:27.01 | CIA-85 | BRL-CAD: 03brlcad * r37895 10/brlcad/trunk/include/rtfunc.h: intern vs ip consistency. |
| 07:30.31 | CIA-85 | BRL-CAD: 03brlcad * r37896 10/brlcad/trunk/include/rtfunc.h: dbip instead of db_i for consistency |
| 07:30.54 | CIA-85 | BRL-CAD: 03brlcad * r37897 10/brlcad/trunk/ (4 files in 3 dirs): add rt_obj_describe, for rt_functab refactoring |
| 07:31.51 | CIA-85 | BRL-CAD: 03brlcad * r37898 10/brlcad/trunk/include/rtfunc.h: geez, ip too |
| 07:42.59 | CIA-85 | BRL-CAD: 03brlcad * r37899 10/brlcad/trunk/ (6 files in 3 dirs): |
| 07:42.59 | CIA-85 | BRL-CAD: add rt_obj_make, rt_obj_params, and rt_obj_xform, finishing off the bulk of the |
| 07:42.59 | CIA-85 | BRL-CAD: rt_functab refactoring task. now just leaves updating our own code to use the |
| 07:42.59 | CIA-85 | BRL-CAD: new interface and deprecation of rt_functab itself before next point release. |
| 07:53.38 | CIA-85 | BRL-CAD: 03brlcad * r37900 10/brlcad/trunk/ (4 files in 3 dirs): go ahead and stub in rt_obj_mirror() too just for completeness, even though there is some negotation that needs to happen wrt rt_mirror(). |
| 08:01.58 | CIA-85 | BRL-CAD: 03brlcad * r37901 10/brlcad/trunk/src/libfb/if_tk.c: remove a bunch of unused vars from the quick hack testing of fork/pipe. add a comment whenever malloc is used (since doing so disobeys HACKING, the motivation should be explicit). ws cleanup too |
| 08:13.37 | CIA-85 | BRL-CAD: 03brlcad * r37902 10/brlcad/trunk/src/libfb/if_tk.c: reduce the scope depths from six or seven to four.. shouldn't go that deep. also functions have to be declared at the top to make msvc's non-99ness happy. |
| 08:14.51 | CIA-85 | BRL-CAD: 03brlcad * r37903 10/brlcad/trunk/src/libfb/if_tk.c: ws consistency |
| 08:27.32 | CIA-85 | BRL-CAD: 03brlcad * r37904 10/brlcad/trunk/src/libfb/if_tk.c: quell warnings about unused vars, missing header and unused params. warning free now |
| 08:29.09 | CIA-85 | BRL-CAD: 03brlcad * r37905 10/brlcad/trunk/include/fb.h: quell warnings about type conversions. make sure to pass the magic numbers through uintptr_t and uint64_t to get not conversion warnings. |
| 11:36.05 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 12:19.59 | d-lo | brlcad: on the ohloh lisence summary... I see GPL! Any ideas what files those are? |
| 12:34.26 | ``Erik | notes to self: immediately after a low altitude loopdeloop, a cessna 172 does not have enough energy to pull off a barrel roll. The goal of flightgear is not to go dirt torpedo in downtown sanfracisco. the goal of flightgear is not to taxi into a parked canadian air jumbo. O.o where's the effin' fun??? |
| 12:35.29 | ``Erik | sucks that most of the fgfs controls expect a joystick and emulate that on a part of the keyboard I simply do not have :/ |
| 12:35.40 | starseeker | ``Erik: you're not enjoying it? or complaining that crashing is not the goal? |
| 12:36.04 | starseeker | wonders how much a joystick that fgfs supports would run... |
| 12:36.10 | *** join/#brlcad Stattrav (~Stattrav@202.3.77.161) | |
| 12:36.58 | ``Erik | it's not the fgfs part, after I did the driver for my logitech digital wingman extreme it was just dandy... but that was on fbsd, and my bsd machine isn't configured for a gui... I naively assumed it'd "just work" on my mac, since everything else does |
| 12:37.35 | ``Erik | if I buy an input device for fgfs, it'd be a yoke and pedal set, I thi |
| 12:37.37 | ``Erik | think |
| 12:41.00 | ``Erik | (dang annoying, it's a nice joystick, 4 axis, 7 or 8 regular buttons, plus a hat for another 4 buttons) |
| 12:42.42 | ``Erik | also unfortunate that the launcher for the mac doesn't have any kinda fetch ability, ya gotta manually install different aircraft and airports |
| 12:43.25 | ``Erik | 172 is a nifty little plane, but lighting up the afterburners and doing a scramble launch with the f4 is much more... messy :D |
| 12:43.48 | ``Erik | (f4 is impossibly to control, though... "lead sled" is too forgiving a term) |
| 12:44.25 | ``Erik | and last time I did any real dorking around with flightgear, the p51 would torque itself so hard, it'd try to barrel roll before it got off the ground |
| 12:44.57 | ``Erik | <-- lacks finesse, goes all cliff style on the throttle in flightgear... it's just a sim, right? :D |
| 12:49.49 | ``Erik | finds some pants and heads in O.o |
| 12:58.43 | d-lo | hopefully in that order :P |
| 13:51.23 | brlcad | he never said he was going to put them on |
| 13:51.35 | d-lo | *gasp* true! |
| 14:27.02 | starseeker | ``Erik: yeah, the few times I've tried fgfs I usually end up crashing quick |
| 15:11.27 | d_rossberg | the uint*_t stuff (bu.h) breaks my non-BRLCADBUILD builds; couldn't this be moved in a non-API header which wont't be installed? |
| 15:47.10 | CIA-85 | BRL-CAD: 03d_rossberg * r37906 10/brlcad/trunk/include/bu.h: |
| 15:47.10 | CIA-85 | BRL-CAD: protect the sections with uint*_t with the corresponding defines |
| 15:47.10 | CIA-85 | BRL-CAD: these defines are undefined e.g. in MSVS outside an BRLCADBUILD |
| 16:10.38 | starseeker | that commit appears to break the build on OSX |
| 16:22.43 | starseeker | isn't sure what the right answer is here... |
| 16:24.34 | d_rossberg | are there some C99 defines as UINT32_MAX? |
| 16:25.35 | d_rossberg | if yes they could be ||-ed with the HAVE_UINT*_T defines |
| 16:26.25 | d_rossberg | btw, configure should set the HAVE_UINT*_T |
| 16:29.22 | starseeker | tries a clean checkout and rebuilds |
| 16:38.13 | *** join/#brlcad Elrohir (~kvirc@p5B14A22A.dip.t-dialin.net) | |
| 16:46.18 | CIA-85 | BRL-CAD: 03brlcad * r37907 10/brlcad/trunk/include/bu.h: |
| 16:46.18 | CIA-85 | BRL-CAD: we need a different solution, these defines can't just be conditional or the |
| 16:46.18 | CIA-85 | BRL-CAD: compile is broken (the API is missing) for non-uint32_t systems. common.h needs |
| 16:46.18 | CIA-85 | BRL-CAD: to guarantee that the c99 types are provided so they can be used |
| 16:46.18 | CIA-85 | BRL-CAD: unconditionally. not quite sure how that's not happening now even for |
| 16:46.18 | CIA-85 | BRL-CAD: non-BRLCADBUILD systems, so can't try a fix. at worse, we can provide our own |
| 16:46.19 | CIA-85 | BRL-CAD: stdint.h for systems missing the types. |
| 17:45.51 | brlcad | for anyone (since i'm on the road) the fix is to replicate the section in common.h for uintptr_t for all 8 of the stdint types in common.h |
| 17:45.59 | brlcad | so that common.h guarantees those types |
| 17:46.08 | d-lo | both hands on the wheel man! |
| 17:46.26 | brlcad | heh, I'm already home, about to head out now |
| 17:46.44 | d-lo | oh, I thought you had an IRC iPhone app er somethin. |
| 17:48.34 | brlcad | yeah, I wish.. |
| 17:49.01 | brlcad | had a web ssh client that would work, but it rarely works across cell towers |
| 17:49.37 | d-lo | is there an IRC to im application bridge? Like AOL or MSN IM? |
| 17:53.11 | brlcad | dunno |
| 17:53.18 | brlcad | cyall! |
| 17:53.21 | d-lo | lata |
| 18:39.22 | Jonimus | There is a IRC to XMPP bridge that works fairly well |
| 18:49.57 | *** join/#brlcad Ralith (~ralith@69.90.48.97) | |
| 19:02.34 | CIA-85 | BRL-CAD: 03starseeker * r37908 10/brlcad/trunk/include/fb.h: Revert r37905 for the moment - appears to be causing bad magic errors. |
| 19:08.56 | CIA-85 | BRL-CAD: 03starseeker * r37909 10/brlcad/trunk/src/libfb/if_tk.c: Exit if someone closes a window mid-raytrace. |
| 19:18.53 | ``Erik | there're programs that do 'em all, like, uh, trillian, pidgin, etc |
| 19:25.52 | starseeker | isn't quite sure how to go about what FB_CKMAG is trying to do... hmm... |
| 19:30.57 | *** join/#brlcad Ralith (~ralith@69.90.48.97) | |
| 19:33.58 | CIA-85 | BRL-CAD: 03starseeker * r37910 10/brlcad/trunk/include/fb.h: Take a stab at fb.h FB_CKMAG - this seems to function on the Mac, although not totally sure it is 'correct' |
| 19:48.12 | *** join/#brlcad Ralith (~ralith@69.90.48.97) | |
| 20:24.58 | *** join/#brlcad Ralith (~ralith@69.90.48.97) | |
| 20:29.24 | ``Erik | heh |
| 20:38.48 | louipc | d-lo: http://www.bitlbee.org |
| 20:39.50 | CIA-85 | BRL-CAD: 03starseeker * r37911 10/brlcad/trunk/src/libfb/if_tk.c: Kill the child pid if stopping framebuffer in mid-raytrace. (need to check if bu_exit does this automatically...) |
| 20:40.27 | d-lo | lol http://failbooking.com/2010/02/28/funny-facebook-failsestoy-crepusculo/ |
| 20:40.49 | d-lo | thanks louipc, but I was wondering if there was a way to get IRC on an iPhone. |
| 20:42.12 | louipc | no irc app for iphone? |
| 20:42.44 | d-lo | dunno, was just wondering how brlcad managed to post while he was driving, but he was actually at home |
| 20:43.09 | louipc | ah.. yeah that's probably not a great idea to chat while driving hah |
| 20:45.00 | d-lo | omg I'm crying here: |
| 20:45.04 | d-lo | http://failbooking.com/2010/02/24/funny-facebook-fails-anal-fantasy-7-ftw/ |
| 20:51.45 | ``Erik | encouraging irc while driving might be... a bad thing |
| 21:07.09 | starseeker | http://www.gearlive.com/news/article/q307-how-to-use-irc-on-the-iphone/ |
| 21:08.51 | *** join/#brlcad R0b0t1 (~Enigma@64-136-216-213.dyn.everestkc.net) | |
| 21:08.55 | *** join/#brlcad R0b0t1 (~Enigma@unaffiliated/r0b0t1) | |
| 21:47.26 | *** join/#brlcad Ralith (~ralith@69.90.48.97) | |
| 21:56.08 | *** join/#brlcad ibot (ibot@rikers.org) | |
| 21:56.08 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD is now available on Gentoo! (20100225) | |
| 22:08.45 | *** join/#brlcad Ralith (~ralith@69.90.48.97) | |
| 22:39.27 | CIA-85 | BRL-CAD: 03starseeker * r37913 10/brlcad/trunk/src/libfb/if_tk.c: Remove earlier kill, teach the left mouse button to close the window. |
| 23:22.25 | CIA-85 | BRL-CAD: 03starseeker * r37914 10/brlcad/trunk/src/libfb/if_tk.c: Get the middle mouse button reporting RGB at image coordiates - needs testing. |
| 23:42.27 | ``Erik | tries to think of a good gui hello world to try doing with qt O.o |
| 23:43.01 | *** join/#brlcad Ralith (~ralith@69.90.48.97) | |
| 23:44.12 | ``Erik | mebbe another dice thingymajigger like I did 15 yrs ago |
| 23:47.57 | ``Erik | ponders making http://laughingsquid.com/wp-content/uploads/donut-seeds-20091111-222834.jpg |
