| 00:04.09 | IriX64 | mines up but you'll never get to it, i'm behind a router. |
| 01:31.46 | CIA-9 | BRL-CAD: 03johnranderson * 10brlcad/src/conv/ (dxf-g.c dxf-g.1): Added support for SPLINE entities |
| 01:50.56 | brlcad | yay, splines |
| 01:53.56 | IriX64 | spliffs too? ;) |
| 01:56.58 | Twingy | I used a spline once |
| 02:03.23 | *** join/#brlcad Twingy (n=justin@c-69-250-236-111.hsd1.md.comcast.net) |
| 02:03.37 | IriX64 | short trip? |
| 02:26.49 | *** join/#brlcad digitalfredy (n=digitalf@200.71.62.161) |
| 02:34.24 | *** join/#brlcad digitalfredy (n=digitalf@200.71.62.161) |
| 02:36.46 | Twingy | to your moms house, yea |
| 03:00.00 | IriX64 | hahaha my sister's better looking. |
| 05:13.22 | *** join/#brlcad Twingy (n=justin@c-69-250-236-111.hsd1.md.comcast.net) |
| 06:31.24 | *** join/#brlcad digitalfredy (n=digitalf@200.71.62.161) |
| 07:57.50 | *** join/#brlcad Twingy (n=justin@c-69-250-236-111.hsd1.md.comcast.net) |
| 08:25.52 | *** join/#brlcad clock_ (i=clock@84-72-91-57.dclient.hispeed.ch) |
| 09:39.20 | b0ef | it would be nice (and correct) if nurb.h was named nurbs.h;) |
| 09:48.52 | clock_ | non uniform rational b-something splines |
| 11:22.47 | b0ef | eh, no |
| 11:23.11 | b0ef | clock_: it's non uniform rational basis splines |
| 14:02.10 | brlcad | b0ef: that it would |
| 14:03.01 | brlcad | perhaps at the next minor update |
| 14:13.21 | ``Erik | what happened to the monthly cycle? O.o |
| 14:16.31 | brlcad | it's still on |
| 14:16.54 | brlcad | but next update is patch update, not minor |
| 14:17.06 | brlcad | which will be like today or tomorrow |
| 14:27.04 | Maloeran | Eh. How are your balls doing, Erik? :) |
| 14:27.44 | ``Erik | uhmmmmm, if you mean the metaball implementation, I haven't touched them lately |
| 14:28.21 | brlcad | heh |
| 14:28.28 | ``Erik | if you don't, I'm backing away now... |
| 14:28.34 | brlcad | but the others he has, of course |
| 14:29.18 | Maloeran | Eheh, I was wondering about the metaballs of course, seems like a tricky problem to get decent performance |
| 14:30.27 | ``Erik | I did a little performance oriented effort, but most of the work is wiring into mged correctly, it'd seem |
| 14:33.30 | ``Erik | once it all works, I'll look into making it fast :) |
| 14:34.02 | Maloeran | I was wondering, is the acceleration structure built for a particular treshold point or you can smoothly change that? |
| 14:34.34 | ``Erik | there is no acceleration structure. |
| 14:35.00 | Maloeran | I see, okay |
| 14:35.19 | ``Erik | at the moment, it does a fairly coarse walk down the ray, once it changes sign, it begins doing a crude binary search until the fine resolution is met |
| 14:35.44 | ``Erik | sorta |
| 14:38.42 | ``Erik | but I need to get the primitive editing capability completed, some crap like the tesselation capability in, etc... before I worry about that stuff |
| 14:39.09 | Maloeran | How do you expect not to miss some hits near the edge of a ball? Unless I misunderstood how you do it |
| 14:39.18 | ``Erik | oh, I miss 'em |
| 14:39.30 | Maloeran | Oh :), makes sense then |
| 14:39.41 | ``Erik | I just hope that my coarse step is small enough so it's not really visible |
| 14:40.01 | ``Erik | it LOOKS ok to my naked eye *shrug* :) |
| 14:40.02 | Maloeran | Now, that is slow |
| 14:40.16 | brlcad | yeah, crazy newtonian walking :P |
| 14:40.20 | ``Erik | surprisingly, not too terribly slow |
| 14:40.39 | ``Erik | within an order of magnitude of a straight sphere |
| 14:40.52 | ``Erik | for a single control point metaball (which produces.. a straight sphere) |
| 14:41.07 | ``Erik | and the speed is linear with regard tot he number of control points |
| 14:42.03 | Maloeran | I dreamed of that problem last night ( don't ask why, I'm weird like that ) ; I think I got some ideas for acceleration structure for large numbers of balls, though I'm sure you do as well |
| 14:42.16 | ``Erik | well, it depends on the field accuracy and formula |
| 14:42.37 | ``Erik | a common one is to use an approximation formula so you can generate bounding sphere heirarchies |
| 14:43.16 | ``Erik | <-- not there, yet... some people want to use the primitive yesterday, so I gotta get the primitive editing abilities finished first |
| 14:43.25 | ``Erik | and they can throw big hardware at it and wait a bit :) |
| 14:43.30 | Maloeran | *nods* Let's talk about it later then |
| 15:14.48 | CIA-9 | BRL-CAD: 03lbutler * 10brlcad/src/libbu/ (22 files): Doxygen updates |
| 15:15.47 | CIA-9 | BRL-CAD: 03lbutler * 10brlcad/src/libbn/ (font.c list.c marker.c msr.c): Doxygen updates |
| 15:17.01 | CIA-9 | BRL-CAD: 03lbutler * 10brlcad/include/ (bn.h bu.h vmath.h): Doxygen updates |
| 15:17.59 | Maloeran | Seems I know where to find good examples of the desired Doxygen format now |
| 15:18.06 | CIA-9 | BRL-CAD: 03lbutler * 10brlcad/misc/doxygen_structure: Doxygen updates |
| 15:18.38 | brlcad | he's been on a binge lately |
| 15:18.46 | brlcad | probably after talking to you |
| 15:20.06 | brlcad | heh, barely a single commit for like 6 months and then a slew of these |
| 15:20.20 | brlcad | the extra doxygen organization is pretty cool though, I must say |
| 15:20.32 | Maloeran | I'm not familiar with the "on a binge" expression, can you express the same idea in other words? |
| 15:20.42 | brlcad | ~dict binge |
| 15:21.19 | Maloeran | I read that, it just didn't seem excessively clear |
| 15:21.24 | brlcad | ahh |
| 15:21.35 | brlcad | it's just doing something "excessive" |
| 15:21.42 | Maloeran | Right, thanks |
| 15:21.46 | brlcad | like not commiting hardly at all in a year |
| 15:21.59 | brlcad | and now suddenly committing a lot in the span of a week |
| 15:22.14 | brlcad | then he'll probably be back to no more coding soon enouch ;) |
| 15:23.13 | Maloeran | :) He also wrote code to ease extracting BRL-CAD geometry for me |
| 15:28.51 | brlcad | that's code already written ;) |
| 15:28.58 | ``Erik | binge&purge |
| 15:29.07 | ``Erik | he copied and gutted code, he didn't really write anything :) |
| 15:29.16 | brlcad | just pulling from the 50+ examples in the converters/ray-tracers/examples, etc ;) |
| 15:29.18 | ``Erik | g-stl.c I'd imagine |
| 15:30.12 | brlcad | though nice to "trim it out" of course |
| 15:30.28 | Maloeran | Aw, don't try to ruin my illusions of a both zealous and competent manager :) |
| 15:30.41 | brlcad | i'm baffled why someone hasn't made the standard "convert from implicit to poly" into a function yet |
| 15:30.56 | brlcad | there's like 10 converters that do the exact same code |
| 15:31.06 | ``Erik | I mentioned it, he said it was all already written, just copy and edit |
| 15:31.06 | ``Erik | ... |
| 15:31.42 | brlcad | exposed? |
| 15:31.57 | ``Erik | opposed to static |
| 15:32.03 | brlcad | the calls are exposed.. the glue function just doesn't exist |
| 15:32.14 | brlcad | what's static that you need? |
| 15:32.23 | brlcad | s/need/use/ |
| 15:32.39 | Maloeran | The chunks of BRL-CAD I read were fairly good code, but I'm clearly missing most of the big picture |
| 15:34.15 | ``Erik | erm, nothing to my knowledge, I just meant that I should be able to grab one function on a tree and get a tree of polygon crap and the info I might need in the structs *shrug* :) |
| 15:35.10 | brlcad | you can go from nmg to triangle with just one cal |
| 15:35.45 | brlcad | but it's just odd that you can't go from code to triangle or even node to nmg -- all the converters do the same walk_tree |
| 15:36.11 | brlcad | Maloeran: most of the code is actually relatively exceptionally well given it's size |
| 15:36.54 | Maloeran | Quite true brlcad, I was surprised |
| 15:36.56 | brlcad | it's just "given it's size", you *will* find loads of feature creep and a need for refactoring where it hasn't yet happened |
| 15:37.14 | ``Erik | and archaic ways of doing things and syntax |
| 15:37.32 | brlcad | and the "oh, this tool does what I need" .. copy, edit, done |
| 15:37.45 | brlcad | sans refactoring into a function/library call |
| 15:37.51 | Maloeran | Yes, I read code that could break nicely on 64 bits when accessing over 4gb... Simple flaws, such as conversions between pointers and int |
| 15:38.34 | ``Erik | hrmmm, on most of the 64b arch's we deal with, int is 8byte, same as pointer, iirc |
| 15:38.40 | ``Erik | amd64 and ia64 are "weird" |
| 15:39.02 | Maloeran | Hence why ptrdiff_t and intptr_t exist |
| 15:39.35 | Maloeran | On amd64 on windows, even long is 32 bits ( or it would break backwards compatibility in their headers ) |
| 15:42.08 | ``Erik | hum, irix/r12k with -64 shows int as 32 and long as 64, funky, I thought both were 64b |
| 15:42.14 | brlcad | yeah, there's a general lack of std types since most of the code well predates stdint and family |
| 15:42.59 | Maloeran | *nods* They couldn't really do better back then, and their assumptions on data types made sense |
| 15:47.40 | brlcad | it would be nice to assume stdint/stddef availability, that would take care of some of the issues |
| 15:47.54 | brlcad | though machine.h still needs to be decommisioned before that could happen |
| 15:48.35 | brlcad | and I don't think they were c89, so it'd require a jump to c99 iirc too |
| 15:48.46 | brlcad | and that's a different ball of wax altogether |
| 15:49.48 | brlcad | and in the big scheme of things, just not nearly as important as many other things that need to be worked on |
| 15:52.59 | Maloeran | Right, it will be required at some point to handle big datasets |
| 15:54.35 | brlcad | well it does handle big datasets now, at least in the ray-tracer and db layer |
| 15:54.46 | brlcad | just maybe not on amd64 on windows |
| 15:55.09 | brlcad | and maybe not for a particular tool or few |
| 15:55.35 | brlcad | that's the problem with large codebases.. you can almost always find an exception that doesn't "comply" ;) |
| 16:02.11 | IriX64 | the c2, a true 128 bit machine :) |
| 16:02.48 | Maloeran | 128 bits memory addressing? |
| 16:02.56 | IriX64 | cpu |
| 16:03.29 | IriX64 | thats for spewing nonsense :) |
| 16:04.48 | IriX64 | whats this? building 64-bit was requested but the build seems to be non 64bit. |
| 16:05.41 | IriX64 | what do you care what its running on eh? |
| 16:05.57 | IriX64 | let me cross it will you. :) |
| 16:06.22 | IriX64 | want to use your 64 bit code... wait i see the problem. |
| 16:06.37 | IriX64 | you need to know don't you? |
| 16:06.59 | IriX64 | ill cross it from the generic code. |
| 16:07.15 | IriX64 | heh thanks for the compliment. |
| 16:07.50 | Maloeran | Seriously, what are you babbling about? :) |
| 16:08.04 | IriX64 | --ignore the machine specific 64 bit code. |
| 16:08.19 | IriX64 | im trying to cross compoile BRLCAD. |
| 16:08.24 | IriX64 | compile too. |
| 16:08.44 | Maloeran | Ah, right |
| 16:09.15 | IriX64 | when my c2 comes in ill be able to runtime test this thing ;) |
| 16:10.06 | brlcad | babbling is quite appropriate.. I sometimes have NO idea what it is you go on about, incoherent statements |
| 16:10.22 | brlcad | you really shouldn't |
| 16:10.29 | brlcad | it does get distracting/annoying |
| 16:10.37 | IriX64 | you have to read from top left at an angle to bottom right :) |
| 16:10.58 | brlcad | see, just what the hell does that mean? :) |
| 16:11.48 | IriX64 | never read codes and secert writings, im just making my brand of humor jokes hoping someone will catch them. |
| 16:12.26 | brlcad | the jokes are a bit too think sometimes I think, or out of context |
| 16:12.48 | IriX64 | if im serious about something ill preface it with seriously.... (probably never happen) |
| 16:12.49 | ``Erik | sorry, none of us smoke pot, especially not in the quantities required to get your brand of humor ;) |
| 16:13.00 | IriX64 | biggest doobies you've ever seen :) |
| 16:13.30 | IriX64 | and its early. |
| 16:13.53 | IriX64 | wine tipped? Try wine dipped. :) |
| 16:15.05 | IriX64 | seriously... im trying out my CFLAGS='-DWITHOUTCYGWIN' flag, see if you can figure out what it's supposed to do. |
| 16:15.23 | brlcad | again another example of a statement that just doesn't compile .. i've never heard of wine tipped doobies if that's what you meant, so wine dipped doobie means nothing.. :) |
| 16:15.32 | IriX64 | :) |
| 16:16.05 | Maloeran | Tried -mno-cygwin? You should never need a define for that |
| 16:16.34 | IriX64 | that doesn't exist (yet but it might, thanks) |
| 16:17.04 | IriX64 | -m is taken tho theres a lot already there. |
| 16:17.45 | brlcad | cross-compilation for different bit lengths won't likely work very well fwiw |
| 16:17.55 | IriX64 | maybe i erred, you saying your compiler supports -mno-cygwin? |
| 16:18.17 | brlcad | gcc under cygwin should support that option |
| 16:18.21 | IriX64 | brlcad: true attack from generic code wherever possible. |
| 16:18.58 | IriX64 | brlcad now whos being obtusde. |
| 16:19.04 | IriX64 | obtuse too. |
| 16:19.48 | brlcad | er, still you -- what do you mean? |
| 16:20.01 | IriX64 | if these binaries crash on my system ill be ever so happy. |
| 16:20.17 | IriX64 | explain -mno-cygwin. |
| 16:21.08 | brlcad | it's just a compiler option, see http://www.delorie.com/howto/cygwin/mno-cygwin-howto.html |
| 16:21.45 | brlcad | basically, drops you down to just the core, i.e. what's in mingw |
| 16:22.18 | IriX64 | brlcad: i don't give a *shit about windows binaries. |
| 16:23.11 | IriX64 | ill visit windoze at a later date. |
| 16:24.38 | brlcad | has less to do with windows binaries than it does to do with that compiler in that environment |
| 16:24.56 | IriX64 | i like my approach better. |
| 16:25.50 | IriX64 | $ CFLAGS='-DWITHOUTCYGWIN' ./configure --enable-almost-everything --with-x --wi |
| 16:25.50 | IriX64 | th-math --enable-optimizations --disable-shared --prefix=/usr/craycad --host=c2 |
| 16:25.50 | IriX64 | -cray-unicos |
| 16:26.02 | IriX64 | will taht configure and compile? |
| 16:27.13 | IriX64 | i know, i know, i was told about pasting, mea culpa.. |
| 16:27.21 | brlcad | it probably will, but it's not going to give you a cross-compiled binary |
| 16:27.28 | IriX64 | bets? |
| 16:28.16 | brlcad | heh, not one that'll work |
| 16:28.30 | IriX64 | a bet that will work? :) |
| 16:29.08 | IriX64 | you're right i'll get *many binaries, not just one ;) |
| 16:29.17 | brlcad | machine.h is hard-coded for detected compilation environments, cross-compiling isn't going to provide all the right flags it needs |
| 16:29.51 | brlcad | ergo *crash* is what you're going to get if it's not cross-compiled for a platform with matching specs |
| 16:30.29 | brlcad | specs being bit depths, byte orders, byte offsets, etc |
| 16:30.41 | IriX64 | my compiler supports different machines, i run configure and parse it on the fly to configure my compilers and linkers accordingly. |
| 16:30.53 | brlcad | not to mention the configure checks for sanity on the bit depths (which is what you ran into earlier) |
| 16:31.08 | IriX64 | thats why i like a clean generic code line whereever possible. |
| 16:31.52 | ``Erik | stave it off, 1 2 3, now you can count to three... |
| 16:31.58 | brlcad | well, this is optimized and mostly pretty compiler generic code, but that doesn't mean it'll cross-compile and work ;) |
| 16:32.33 | IriX64 | traditional cross compile you're right you guys bail at a simple check of setpgrp. :) |
| 16:32.59 | IriX64 | my way it does produce appropriate code. |
| 16:33.12 | brlcad | and you've verified this how? |
| 16:33.13 | IriX64 | people coming in ill be back in 15. |
| 16:33.44 | brlcad | i'm betting "appropriate" means that the compile simply didn't fail for you |
| 16:34.02 | brlcad | which is far from appropriate, and even farther from functional on that cross-compile platform |
| 16:34.06 | Twingy | along with bert n' ernie |
| 16:34.20 | ``Erik | sean, didja get a build on that vax11/780 simh image? |
| 16:35.10 | Twingy | 21.1 jigavgr's |
| 16:35.10 | brlcad | i did, barley, but that was years ago.. not recent |
| 16:35.28 | ``Erik | ah, just recently you were installing netbsd on a simh image, I thought |
| 16:37.16 | brlcad | no no.. i was saying it'd be cool because I did install netbsd pretty easily a couple years ago |
| 16:37.45 | ``Erik | ah |
| 16:37.54 | brlcad | the compile gave a bit of a hassle then, but the autotools stuff wasn't all sorted out back then |
| 16:37.56 | ``Erik | <-- was too busy playing with lisp on a pdp1 |
| 16:38.52 | brlcad | hmm.. i could toss up simh into parallels here.. that would save some of the setup time i had to do on os x for it last time |
| 16:39.31 | ``Erik | hm, attaching all the devices and stuff? |
| 16:40.36 | brlcad | well that and just getting simh to compile wasn't clean either |
| 16:41.10 | brlcad | had to write some code to get it to compile, and I don't recall all the details .. |
| 16:41.34 | brlcad | looks like there was a guy that provided a slew of pdp11 and vax bug fixes this summer.. swett |
| 16:42.03 | ``Erik | http://www.homestarrunner.com/disk4of12.html |
| 16:42.23 | ``Erik | hrm, I was doing it on fbsd, so "make install" was all I had to do |
| 16:43.46 | IriX64 | may i give you a superficial look at project cassandra? this'll take a moment to type in. |
| 16:46.11 | brlcad | heh |
| 16:46.21 | IriX64 | when configure runs i trap the checks and based on either the build switch or the hhost switc (not both) i either provide the build environmnment as accuratly as possible providing things that are needed if i have them or providing a generic if i dont (if i have neither im dead ) and for the host i try to provide as nearly as possible what is requried to actually cross-compile for that machine in much the same way, the results are stored |
| 16:46.44 | IriX64 | and the compiler reads that file in so it and the linker knows what ist doing. |
| 16:46.53 | IriX64 | ipc at its best. |
| 16:47.38 | brlcad | (on freebsd) |
| 16:47.56 | brlcad | *trying to ignore the peasant distraction |
| 16:48.02 | Twingy | remember the sparc ipc's those things were crap |
| 16:48.59 | IriX64 | peasants quest???? |
| 16:49.24 | IriX64 | err twingy? define ipc. |
| 16:50.10 | IriX64 | my ipc is inter-process communication (cheap variety) |
| 17:27.14 | ValarQ | STM! |
| 17:27.43 | ValarQ | http://en.wikipedia.org/wiki/Software_transactional_memory |
| 17:31.09 | ``Erik | "chad vader", awesome |
| 17:31.19 | ``Erik | http://youtube.com/watch?v=4wGR4-SeuJ0 |
| 18:47.53 | brlcad | heh pretty funny |
| 18:48.02 | brlcad | ahh, yes, stdint is c99 |
| 18:48.13 | brlcad | tough nuggies |
| 19:14.40 | IriX64 | shouldn't that be noogies :) |
| 19:25.09 | brlcad | in some contexts |
| 19:27.13 | ``Erik | heh, klingons? |
| 19:27.20 | IriX64 | for(i=0;i<strlen(string);i++){if((string[i]) == 'x');puts("End of the world has been found\n");} |
| 19:27.38 | IriX64 | err -; |
| 19:28.37 | ``Erik | (for-each (lambda (x) (if (= 'x' x) (display "End of world"))) (string-chars string)) |
| 19:28.38 | ``Erik | ptbtbbtt |
| 19:28.41 | IriX64 | can use *string+i too |
| 19:29.13 | IriX64 | thought we spoke c here not lisp :) |
| 19:29.21 | ``Erik | that would be scheme, not lisp |
| 19:29.28 | IriX64 | my mistake |
| 19:29.42 | IriX64 | boot me this deserves a kick but not the ban. |
| 19:30.05 | ``Erik | /kill IriX64 learn your languages |
| 19:30.14 | IriX64 | heh |
| 19:30.23 | IriX64 | im language challenged. |
| 19:30.29 | ``Erik | no? k: perhaps? or possibly g:? |
| 19:30.42 | IriX64 | y rather thann x. |
| 19:31.01 | IriX64 | back to klingonese. |
| 19:33.27 | IriX64 | ``Erik you thought the end of world thing is what i was trying to do? |
| 19:33.47 | IriX64 | im searching for x. |
| 19:33.54 | IriX64 | in a string. |
| 19:34.55 | IriX64 | lst line should read return(printf("end of world not found\n")); |
| 19:34.59 | IriX64 | last too. |
| 19:35.57 | brlcad | and stating |
| 19:36.01 | brlcad | the obvious about |
| 19:36.12 | IriX64 | that means what? |
| 19:36.15 | brlcad | one line of code with 8 lines of explanation |
| 19:36.31 | ``Erik | char *s = string; while(*s++)if(*s=='x')printf("end world here"); |
| 19:36.36 | ``Erik | learn pointers :D |
| 19:36.59 | IriX64 | you forgot the alloca :) |
| 19:37.13 | ``Erik | why? I don't want to duplicate the string o.O |
| 19:37.35 | IriX64 | allocation on initialization then ? |
| 19:38.03 | IriX64 | char * mystring="end of world here \0"; |
| 19:38.42 | ``Erik | sure |
| 19:38.48 | ``Erik | or argv[1] for all I care |
| 19:38.49 | ``Erik | :D |
| 19:38.56 | IriX64 | few people realize mystring should be freed. |
| 19:39.19 | ``Erik | uh, char *blah="cow"; free(blah); should not compile. |
| 19:39.30 | IriX64 | bets? |
| 19:39.50 | ``Erik | the string will be retained in bss, which should not have any allocation/deallocation inside of main |
| 19:40.05 | brlcad | er, it'll compile |
| 19:40.10 | ``Erik | hrm, it compiled on my mac |
| 19:40.20 | ``Erik | but, naturally, fails horribly when ran |
| 19:40.27 | brlcad | yeah, can't free a static |
| 19:40.38 | IriX64 | you didnt say static. |
| 19:41.10 | IriX64 | autoallocas *should be freed. |
| 19:41.16 | brlcad | s/static/string literal/ |
| 19:41.23 | brlcad | same difference |
| 19:41.23 | ``Erik | that you explained it as a "string" says it's bss, resides in static program data space |
| 19:41.27 | IriX64 | except for alloca apil foolf running hard..... |
| 19:41.41 | IriX64 | april too. :) |
| 19:41.47 | ``Erik | and should NOT have any memory ops happen on it inside of main() |
| 19:42.03 | IriX64 | its the return ``Erik |
| 19:42.17 | IriX64 | a lot of times the system knows what its doing. |
| 19:43.23 | IriX64 | cow ``Erik :) |
| 19:43.29 | IriX64 | ? |
| 19:43.57 | ``Erik | copy on write is unrelated |
| 19:44.14 | IriX64 | thought that was ValarQ's specialty she drew such a pretty one. |
| 19:44.58 | ``Erik | aaannndddd back out to left field. |
| 19:45.06 | IriX64 | right!!!!!!! |
| 19:45.22 | IriX64 | blargh it smoke break time. |
| 21:21.24 | *** join/#brlcad PrezKennedy (n=Apathy@c-68-55-177-2.hsd1.md.comcast.net) |
| 22:39.17 | *** join/#brlcad digitalfredy (n=digitalf@200.71.62.161) |