| 00:32.55 | *** join/#brlcad bsder (n=andrewl@cpe-66-75-155-122.san.res.rr.com) | |
| 01:31.15 | CIA-7 | BRL-CAD: 03brlcad * 10brlcad/src/tclscripts/ampi.tcl: abort with a clean message if a pkgIndex.tcl file does not exist since open's failure message is less than ideal |
| 01:32.51 | CIA-7 | BRL-CAD: 03brlcad * 10brlcad/src/tclscripts/ampi.tcl: oop, remove debug print |
| 01:33.35 | CIA-7 | BRL-CAD: 03brlcad * 10brlcad/src/tclscripts/ami.tcl: abort with a clean message if a tclIndex file does not exist since open's failure message is less than ideal |
| 01:41.50 | IriX64 | should report an error yes, but to abort? |
| 01:43.55 | CIA-7 | BRL-CAD: 03brlcad * 10brlcad/src/tclscripts/ (ami.tcl ampi.tcl): heh, there's quality control for ya.. check for existance of variable name so we actually do some work.. |
| 01:43.57 | brlcad | aborting is just a rude way of error'ing |
| 01:44.31 | brlcad | it should be more graceful about it though, yeah |
| 01:44.39 | IriX64 | agreed |
| 01:44.46 | brlcad | to fix it, look at the file dsp loading code |
| 01:44.59 | brlcad | src/librt/g_dsp.c .. match it to the abort error message you get |
| 01:45.36 | IriX64 | g_dsp.c line 3134 ive looked. |
| 01:49.37 | brlcad | if you "cd db" from inside the source tree, it should find its data file |
| 01:51.00 | IriX64 | after i bring up mged you mean, and load it from within "db"? |
| 01:52.06 | Maloeran | brlcad, Erik, can I assume zlib is not an unreasonable required dependency? |
| 01:52.30 | brlcad | Maloeran: it's already one |
| 01:52.34 | brlcad | (to brl-cad) |
| 01:52.44 | brlcad | so no, not at all ;) |
| 01:52.52 | Maloeran | Oh. :) |
| 01:53.16 | brlcad | pretty much anything like zlib that has zero dependencies of it's own are usually unreasonable |
| 01:53.51 | brlcad | or if the dep is just something like zlib with no deps of it's own |
| 01:55.55 | Maloeran | Usually unreasonable? |
| 01:55.56 | Maloeran | Just making sure you didn't intend to type "reasonable" instead |
| 01:55.56 | brlcad | other similar deps we currently already have, libpng, zlib, libregex, and termlib (not full-blown curses) |
| 01:55.56 | brlcad | er, yeah .. reasonable |
| 01:56.04 | IriX64 | will try it soon as this make install is done brlcad. |
| 01:56.24 | Maloeran | I can keep it optional, but if won't go nicely if processing nodes are compiled with/without it, without further handshake tests anyway |
| 01:56.36 | brlcad | something like gtk sit at the other extreme .. dependency hell |
| 01:56.51 | *** join/#brlcad louipc (n=louipc@bas8-toronto63-1177707015.dsl.bell.ca) | |
| 01:57.03 | brlcad | zlib is trivial to use, no reason not to other than technical benefit |
| 01:57.09 | Maloeran | Nevermind actually, I'll keep it optional, I really prefer to keep dependencies to a minimum |
| 01:57.20 | brlcad | what are your deps currently? |
| 01:57.26 | louipc | Maloeran: cool vids ;) |
| 01:57.31 | brlcad | sdl's a fairly heavy one for keeping them to a minimum :) |
| 01:57.42 | Twingy | on my system I take make; make install and gtk isn't much of an issue :) |
| 01:57.52 | Maloeran | The engine : nothing but C99 and pthreads. The demos : SDL |
| 01:58.03 | Maloeran | Thanks louipc :) |
| 01:58.04 | brlcad | that's not too shabby |
| 01:58.05 | Twingy | I suppose anything is dependency hell if you have a crappy package system |
| 01:58.23 | Twingy | i.e. irix freeware |
| 01:58.30 | Twingy | i.e. redhat rpms |
| 01:59.05 | Maloeran | The video recording demo doesn't require SDL clearly, but I prefer some visible interactive output ;) |
| 01:59.06 | brlcad | which is the reality of being and caring about cross-platform |
| 01:59.16 | brlcad | if you don't care about that, then .. sure, not an issue |
| 02:01.46 | Maloeran | By the way brlcad, I found how to add proper N buffering support in SDL, but I don't think my patch would be accepted. It would be a mess to require a patched SDL too |
| 02:02.56 | brlcad | never know till you submit ;) |
| 02:03.07 | brlcad | i'd like that feature myself |
| 02:03.38 | brlcad | probably more of doing the patch in a way that is clean to the API |
| 02:04.42 | Maloeran | Easy : just provide a function to replace the "shadow" surface of any screen surface with another identical in size and format. The previous shadow surface becomes an independent surface |
| 02:06.45 | IriX64 | brlcad: tops reports mapped file open failed twice but it did do the list. |
| 02:07.15 | brlcad | so replace shadow with a pointer into an array, and add an API function to attach additional SDL_Surfaces (which just add to the array) like SDL_AddFlipSurface() |
| 02:07.41 | brlcad | then SDL_Flip just rotates the pointer through the array |
| 02:08.00 | brlcad | should be neat n clean enough to accept unless someone has moral objections to it |
| 02:08.01 | Maloeran | Rotation is not good enough, I must be able to hop erratically |
| 02:08.22 | Maloeran | Replacing the shadow surface is clean really, just changing one little pointer |
| 02:08.41 | brlcad | so add another that is SDL_SetFlipSurface() too, but let default just rotate or somesuch |
| 02:09.01 | brlcad | yeah, but that exposes an internal .. I can't see them accepting that |
| 02:09.48 | Maloeran | There's a function around it. SDL_SetShadowSurface( SDL_surface *shadow ); |
| 02:10.06 | Maloeran | The previous shadow/screen surface becomes a regular surface at that point, very simple |
| 02:10.18 | brlcad | so they already have the func |
| 02:10.25 | Maloeran | No :), that's mine |
| 02:10.33 | brlcad | ah.. hmm |
| 02:11.37 | brlcad | maybe they'll take it just like that, though they might not like the name if "Shadow" surfaces aren't exposed anywhere else |
| 02:12.01 | Maloeran | SDL_SetScreenSurface() might be more appropriate |
| 02:12.03 | brlcad | but that's easy enough to change if that's their only gripe |
| 02:12.16 | brlcad | go for it ;) |
| 02:12.37 | Maloeran | Now, I need to learn how to make a patch! :) I think it involves diff |
| 02:12.41 | brlcad | talked to any of the devs about making the change? |
| 02:12.42 | brlcad | hah |
| 02:12.45 | brlcad | serious? :) |
| 02:13.19 | Maloeran | Initial reply from dev was "I don't think it would be something we'd add to SDL itself" |
| 02:13.35 | brlcad | diff -u file > mymod.patch |
| 02:13.50 | brlcad | er diff -u fileold filenew > mymod.patch |
| 02:14.52 | Maloeran | Thanks |
| 02:15.51 | Maloeran | If multiple files were modified, can I append all the "diff" to the same patch? |
| 02:16.06 | louipc | :O |
| 02:16.09 | IriX64 | brlcad: aclocal-1.8.5/automake-1.8.5 fixes that syntax error in config bug. |
| 02:16.27 | louipc | Maloeran: yep |
| 02:16.29 | brlcad | diff -r -u dirold dirnew if you have entire directory differences, or even better ... cvs diff -u > mod.patch |
| 02:17.30 | brlcad | might want to add -b -B if you inadvertently changed whitespace too .. that's usually annoying to include with feature patches |
| 02:17.57 | brlcad | (never hurts, just means ignore differences in whitespace) |
| 02:18.03 | Maloeran | All right, thanks |
| 02:26.19 | CIA-7 | BRL-CAD: 03brlcad * 10brlcad/src/tclscripts/ (ami.tcl ampi.tcl): aha! enlightenment hath arrived. creating the index files actually sources the file args provided so when it ends up running the other amp?i.tcl script, it was choking on the error. just return 0 to indicate success. |
| 02:27.29 | CIA-7 | BRL-CAD: 03brlcad * 10brlcad/src/tclscripts/ (7 files in 7 dirs): ws |
| 02:51.09 | IriX64 | ``Erik, have you forgiven me yet for that wallpaper joke? |
| 02:57.49 | IriX64 | :) |
| 02:58.54 | IriX64 | video magnification = 101 11111111110000000000111111111 right ? :) |
| 02:59.30 | IriX64 | the ten 1's and ten 0's are stored in the fram buffer. |
| 02:59.38 | IriX64 | frame too. |
| 03:00.49 | IriX64 | ive used this, top half of the screen is normal, bottom half is x10. |
| 04:16.48 | louipc | should variable names be that long? :P |
| 04:19.28 | Maloeran | Probably not :) |
| 04:21.20 | louipc | I know it's tough to juggle descriptiveness between brevity |
| 12:57.26 | *** join/#brlcad docelic (n=docelic@212.91.113.246) | |
| 13:53.57 | *** join/#brlcad Elperion (n=Elperion@p548762CA.dip.t-dialin.net) | |
| 14:12.17 | brlcad | *yawn* |
| 14:48.00 | ``Erik | indeed. |
| 14:53.13 | Maloeran | Argh no, not another 30cm of snow |
| 14:59.38 | ``Erik | hmmmm, the 'btree' I'm supposed to look at, is that the balanced binary tree in RF/mm.c ? |
| 15:00.00 | ``Erik | (and a btree is a fairly specific data structure that is not binary) |
| 15:00.41 | Maloeran | Yes, the btree functions in mm.c. mmBinaryTree* was a bit too long |
| 15:01.15 | Maloeran | It's not of much importance, I'm just curious to identify the kind of balanced binary tree |
| 16:00.15 | Maloeran | What a blizzard. I won't be riding a bicycle again anytime soon |
| 16:03.38 | ``Erik | weeee, I got to stomp around the boonies doing "geocaching" tomorrow :D |
| 16:03.41 | ``Erik | get to |
| 16:04.30 | Maloeran | stomp boonies, geocaching? |
| 16:05.05 | ``Erik | http://www.geocaching.com/ |
| 16:09.27 | Maloeran | Cool, weird stuff |
| 16:10.07 | brlcad | for the first time? |
| 16:10.34 | Maloeran | Of course not, but rock climbing is not very practical here during winter |
| 16:23.57 | brlcad | so, everything seems to be working at least under os x now with the upgraded tcl/tk |
| 16:24.45 | brlcad | actually, can't check tk so easily just yet, but everything seems to be behaving as it should so far and all tests run/pass |
| 16:26.43 | ``Erik | sweet |
| 16:33.12 | Maloeran | Neat, Survice crashed their email server by "exceeding disk space", for 3 days now |
| 16:43.14 | ``Erik | explains why my mail to eric didn't work |
| 17:30.09 | ``Erik | heh |
| 17:30.13 | ``Erik | mal... |
| 17:30.33 | ``Erik | it looks like an attempt at an AVL tree |
| 17:30.35 | ``Erik | but it's not balanced. |
| 17:33.38 | ``Erik | (that woulda been MUCH faster if it were commented) |
| 17:41.47 | Maloeran | Of course it's balanced |
| 17:42.15 | Maloeran | Well kind of, it maintains the tree balance within good limits |
| 17:42.43 | ``Erik | 'within good limits'? :D |
| 17:43.02 | Maloeran | The most expensive branch can never be twice longuer than the shortest |
| 17:43.09 | Maloeran | And typically, the average is fairly good |
| 17:44.24 | Maloeran | I'm impressed you managed to make sense of the code :) |
| 17:46.46 | ``Erik | heh, it was rough and I still don't grok parts of it :) |
| 17:47.11 | ``Erik | some notional comment of what MM_BTREE_FLAGS_STEP is would make it a lot easier to read |
| 17:47.44 | ``Erik | and the naming convention makes things rough... 'anode' where I may've used 'ancestor_n' |
| 17:47.49 | Maloeran | It's a marker to recognize patterns in the tree structure |
| 17:49.27 | ``Erik | yeah, but that's one that's highlighted all through the insert ufnction on my printout as I was trying to 'solve' it :) |
| 17:50.02 | Maloeran | :) I think it's kind of elegant, very efficient |
| 17:50.36 | Maloeran | And the worst, rare case ( longuest twice as long as shortest ) is not too bad |
| 17:51.11 | Maloeran | So anyway, it's surely nothing new, but putting a name on the balanced binary tree could be nice |
| 17:51.57 | ``Erik | it's not really balanced, though, the min and max tree dpeth differ by more than 1 in cases |
| 17:52.35 | Maloeran | Of course. The point is high performance with a very much acceptable "worst case", it's not a perfect balance |
| 17:52.54 | Maloeran | Getting a perfect balance constantly is way too expensive, performance is the objective here |
| 17:53.55 | ``Erik | *shrug* well done avl's and rb trees are pretty fast, there was another one that stored dpeth at each node and rotated on the way down to maintain balance, I forget its name, though |
| 17:54.06 | ``Erik | I know it had lightening bolts on the diagrams in the MIT book :D |
| 17:54.51 | Maloeran | I think it's a weird rb tree. Anyhow, I was mostly looking for critisism on the rest of the code :) |
| 17:55.08 | ``Erik | rb trees are weird avl trees *shrug* |
| 17:55.52 | Maloeran | If you have a good rb implementation nearby, we could benchmark one day |
| 17:57.18 | ``Erik | hm |
| 17:57.18 | ``Erik | glib implements a couple balanced trees iirc, and libbu in BRL-CAD has an rb tree |
| 17:57.18 | ``Erik | bah, stupid linux |
| 18:02.44 | *** join/#brlcad Maloeran (n=maloeran@glvortex.net) | |
| 18:03.32 | Maloeran | Woah. Erik, these harsh words wounded my Linux kernel so deeply that it commited suicide |
| 18:04.16 | ``Erik | heh, yes, such a fickle and unstable OS |
| 18:04.19 | ``Erik | emo software |
| 18:04.20 | ``Erik | :D |
| 18:04.43 | Maloeran | An instant reboot, I can't blame overclocking on that box |
| 18:06.00 | Maloeran | Seriously, this is weird.. |
| 18:10.17 | *** join/#brlcad IriX64 (n=mario_du@bas3-sudbury98-1168050967.dsl.bell.ca) | |
| 18:16.26 | IriX64 | http://www.pastebin.ca/378697 |
| 18:20.00 | IriX64 | http://www.pastebin.ca/378701 |
| 18:20.07 | IriX64 | shouldn't these .... |
| 18:20.18 | IriX64 | be restored by autoconf? |
| 18:20.32 | IriX64 | i mean your script generates them somehow but... |
| 18:26.05 | IriX64 | after running, autogen.sh aclocal still complains, but the missing files are now there :) |
| 18:35.26 | IriX64 | ``Erik thought you people were interested. |
| 18:36.49 | ``Erik | um, libtool, actually |
| 18:36.55 | ``Erik | from the libtoolize command |
| 18:37.03 | ``Erik | and automake, I think, if running in the -a mode |
| 18:37.13 | ``Erik | just use autogen.sh |
| 18:37.34 | ``Erik | on windows, automake might require -ca |
| 18:37.50 | IriX64 | no it runs successfully. |
| 18:37.56 | IriX64 | with no options. |
| 18:38.12 | ``Erik | uh, that second paste says that it does NO run successfully |
| 18:38.27 | IriX64 | urf thats after a distclean. |
| 18:38.43 | IriX64 | after autogen.sh if run standalone it does. |
| 18:47.06 | brlcad | IriX64: for the third time, that's because you're running the wrong manual steps and missing arguments |
| 18:47.57 | brlcad | if you're not going to read autogen.sh to figure out what those steps should be, don't waste (our and your) time with reports that individual steps aren't doing what you expect them to do |
| 18:51.44 | CIA-7 | BRL-CAD: 03erikgreenwald * 10brlcad/src/libsysv/basename.c: include appropriate headers (cygwin fix) |
| 18:57.55 | ``Erik | fucking goddamn mother fucking!~#!~@!~ |
| 18:58.25 | ``Erik | in the middle of a build, a dialog on the windows machine pops up saying that it's downloaded updates and will automatically restart in 3 minutes... and the only button on the thing was 'restart now' |
| 18:58.47 | brlcad | hehehe |
| 19:02.53 | IriX64 | turn off automatic updates i hate that #%^$#%#% thing. |
| 19:04.23 | ``Erik | 'corporate' computer, I have no control of that machine |
| 19:04.38 | IriX64 | heh you're a marine ;) |
| 19:04.43 | ``Erik | shit, I probably need a triple signed memo to move an icon on the desktop |
| 19:04.55 | IriX64 | see above. |
| 19:04.58 | IriX64 | :) |
| 19:05.08 | *** join/#brlcad cad95 (n=58751fe0@bz.bzflag.bz) | |
| 19:09.04 | IriX64 | http://www.pastebin.ca/378754 <---- your steps. |
| 19:11.34 | brlcad | yes, that's better |
| 19:12.05 | brlcad | aside from a few additional sanity checks that autogen.sh does for you |
| 19:12.31 | brlcad | like restoring clobbered files, making sure there's no buggy versions doing bad things |
| 19:13.04 | brlcad | the aclocal warnings are benign and not our problem, you 'll notice they are for different projects |
| 19:27.09 | ``Erik | also; sweet. my little single threaded program took an 8 core opteron linux box to a load of 6 and ugly system consumption |
| 19:28.02 | IriX64 | brlcad: was just trying to help. |
| 19:28.28 | ``Erik | hehehehe but it made it to 17 gigs before puking, neat |
| 19:30.37 | IriX64 | try void main(void) { for(i=0i;1000000000000;i++) fputs(outfile,"Hello there"); } |
| 19:31.20 | IriX64 | ermf comma missing, oh well. |
| 19:32.08 | ``Erik | this was straining mal's semi-balanced tree routine |
| 19:33.46 | IriX64 | reminds me of OS/2 and trying to see how well the swap file worked :) |
| 19:34.19 | IriX64 | maybe ugly but it works. |
| 19:34.20 | CIA-7 | BRL-CAD: 03erikgreenwald * 10brlcad/src/ (Makefile.am librt/Makefile.am): wire in libsysv as a librt dep (cygwin) |
| 19:34.40 | IriX64 | heh |
| 19:38.32 | IriX64 | where's that answer to life, the universe, and everythin? |
| 19:38.56 | brlcad | IriX64: I understand.. but insisting on going down a faulty route isn't helpful.. now investigating g_dsp.. that's helpful ;) |
| 19:39.20 | IriX64 | don't remind me, btw i am still looking at it. |
| 19:39.49 | brlcad | actually.. IriX64, since you seem intent on finding faults.. there is one particular area that you could help with |
| 19:40.10 | IriX64 | where? |
| 19:40.33 | brlcad | and all it really involves is running the converter on the example geometry databases |
| 19:40.50 | IriX64 | which converter you have several. |
| 19:41.02 | IriX64 | or do you mean asc2g? |
| 19:41.49 | brlcad | yeah, sry .. i mean picking one of them that facetizes, like g-stl or g-dxf |
| 19:41.59 | ``Erik | hm |
| 19:42.03 | brlcad | g-something where "something" is some format that you can actually evaluate |
| 19:42.34 | IriX64 | ill see what i can do. |
| 19:43.22 | brlcad | then basically just ending up with a list/table of the geometry files in db/ and for each top level object, reporting whether g-whatever succeeded fully, partially, aborted abnormally, or outright crashed |
| 19:43.42 | brlcad | heck, if you did it for all the converters, that would be freaking sweet |
| 19:54.35 | IriX64 | tell you right now somethings wonky with g-dxf or dxf-g i translated to dxf and then used dxf-g and something got lost in the translation. |
| 19:55.40 | brlcad | which is why it would be useful to have a list of the geometry files and the behavior |
| 19:55.55 | brlcad | that would be a case for it was a partial conversion |
| 19:56.04 | brlcad | s/for/where/ |
| 19:56.18 | IriX64 | think its the file? I'll try another. |
| 19:56.39 | brlcad | sure, something like moss.g should be almost guaranteed to complete successfully |
| 19:59.24 | ``Erik | feck |
| 19:59.32 | IriX64 | says there no such thing in moss, guess i could bring mged up and verify that but you probably know. |
| 19:59.39 | IriX64 | as all i mean. |
| 20:00.13 | brlcad | each file has a different set of top-level objects |
| 20:00.24 | brlcad | run "mged -c file.g tops" to get the list |
| 20:00.39 | brlcad | each top-level object should be tested individually |
| 20:02.19 | IriX64 | got it found my problem with all |
| 20:02.33 | IriX64 | forgot the .g (goof that I am.) |
| 20:05.01 | ``Erik | (also keep in mind, _GLOBAL is not an object, it's a container for some file wide things like db title and default unit) |
| 20:05.24 | ``Erik | so moss.g will show _GLOBAL and all.g, you only care about all.g in that file |
| 20:05.50 | IriX64 | ty maybe ill tackle it obviously you're in no rush for it. |
| 20:06.14 | ``Erik | heh, we all have 8 zillion things to do |
| 20:06.17 | brlcad | not a "rush", but highly useful |
| 20:06.22 | IriX64 | ty |
| 20:06.42 | ``Erik | and only three people really 'work' on the project, with other competing time consumers :/ |
| 20:07.22 | brlcad | more than three, but the % of their time is definitely shared |
| 20:07.26 | ``Erik | hey, brlcad, is 'egf' done, or are you still mucking with it? |
| 20:07.37 | brlcad | egf? |
| 20:07.41 | ``Erik | 3 'primary' ones, I think... I haven't seen anything from bob in a while |
| 20:07.46 | ``Erik | endgame |
| 20:07.49 | brlcad | ahh |
| 20:08.15 | brlcad | no, it's not "done" .. and is going to continue through a follow-on project over the upcoming months |
| 20:08.27 | brlcad | the converter effort is just about done |
| 20:08.31 | ``Erik | ah |
| 20:09.03 | brlcad | the follow-up should lead towards an improved C++ api to the geometry engine, as well as testing infrastructure improvements |
| 20:09.45 | brlcad | among other goodies, like helping with the brep improvements |
| 20:10.02 | brlcad | damn it's awesome outside right now |
| 20:12.09 | ``Erik | wahhh, I wanna be out playing geocache, wwwaaaahhhhhh |
| 20:12.52 | ``Erik | be a fun sailing day ;/ |
| 20:21.28 | Maloeran | Urgh Erik, 17gb of balanced binary trees? Are you trying to find a bug in my code or what? :) |
| 20:21.58 | ``Erik | um |
| 20:21.59 | ``Erik | yes? |
| 20:22.16 | Maloeran | Good, keep at it :) |
| 20:22.26 | ``Erik | Failed to malloc: 37748736000 |
| 20:22.41 | ``Erik | depth: 29 -> 56 (4) |
| 20:22.41 | ``Erik | 800.000000 : 307.289077 seconds |
| 20:23.02 | ``Erik | aand actually I'm mucking with nmg facetization right now :) |
| 20:23.20 | ``Erik | waiting for the widnows people to quit dicking with my computer so I can continue cygwin efforts |
| 20:24.30 | Maloeran | You had to call a windows sysadmin to be authorized to open a .c file, or perhaps to execute vim? |
| 20:25.11 | ``Erik | heh |
| 20:25.17 | ``Erik | no, they asked me ot get off of it so they could patch it |
| 20:25.26 | Maloeran | I looked into nmg quite a bit too, but it wasn't very clear how to proceed to make triangles face the proper way |
| 20:25.36 | Maloeran | I would have kept going if I had more time to spare |
| 20:25.52 | Maloeran | That too |
| 20:27.09 | ``Erik | since nmg solves closed volumes, you can do a surface walk and orient winding or normals with two easy distinct possibilities: either they're all correct or all incorrect... and if they're ALL incorrect, just flip them all and it's done :) |
| 20:28.10 | ``Erik | but if it pukes on dangling faces or unclosed volumes, you don't get jack shit *shrug* |
| 20:28.32 | Maloeran | Yes, it's all part of the same problem really. Making it work properly |
| 20:29.32 | ``Erik | but I have my winderz machine back *sigh* |
| 20:29.55 | Maloeran | Why are you doing this on windows? |
| 20:30.15 | ``Erik | fixing nmg is on fbsd, but I'm trying to get it to build on cygwin... different effort |
| 20:31.48 | CIA-7 | BRL-CAD: 03brlcad * 10brlcad/src/other/jove/ (6 files): restructure and simplify the jove tutorial/teaching stuff. |
| 20:43.10 | CIA-7 | BRL-CAD: 03erikgreenwald * 10brlcad/src/conv/ (7 files in 6 dirs): add SYSV where needed (cygwin) |
| 20:43.52 | IriX64 | of BRL-CAD i mean. |
| 20:44.43 | IriX64 | how do I get it to you, it's huge. |
| 20:46.44 | brlcad | i doubt he needs it |
| 20:46.48 | brlcad | he installed cygwin |
| 20:46.52 | Maloeran | I don't think Erik will accept any .dll file |
| 20:47.01 | IriX64 | ahhh we can compare notes. |
| 20:47.18 | IriX64 | the dll he has if he installed cygwin. |
| 20:47.38 | IriX64 | its in /bin . |
| 20:48.59 | IriX64 | 212,296kbyte bz2 file. |
| 20:50.29 | brlcad | louipc: does archlinux have a shorthand name? |
| 20:50.38 | brlcad | what does gnu call it? |
| 20:51.40 | CIA-7 | BRL-CAD: 03erikgreenwald * 10brlcad/src/libpkg/pkg.c: don't use winsock if building on cygwin, stick with UNIX style |
| 20:52.54 | IriX64 | ``Erik it's photon mapping my favorite wall candy. |
| 20:53.34 | ``Erik | if you can get 'rise' to build, it's niftier... src/adrt/rise |
| 20:53.52 | ``Erik | figuring out how to USE it will keep ya busy for a while, tho |
| 20:53.52 | IriX64 | ermf SDL issues still, working on it. |
| 20:54.03 | IriX64 | heh no doubt. |
| 20:54.18 | ``Erik | (but once you figure it out, you can tell us, so we can use it, too ;) |
| 20:55.38 | IriX64 | Jean-Luc picard, says to his Singer sewing machine repairman, "make it sew" :) |
| 20:55.47 | IriX64 | thats not mine tho. |
| 20:58.41 | IriX64 | hah nobody looked at the binaries in incoming? |
| 21:00.20 | ``Erik | http://www.tribeam.com/product.html#QC15 |
| 21:00.32 | IriX64 | tried to put wincad in there, permission denied (shrug) |
| 21:00.32 | ``Erik | just in case you NEED to charge 15 at a time |
| 21:01.19 | Maloeran | iPods are like duct tape, one never has quite enough |
| 21:03.45 | IriX64 | The novelty of this picture never wears off for m. |
| 21:03.49 | IriX64 | +e |
| 21:06.29 | *** join/#brlcad IriX64 (n=mario_du@bas3-sudbury98-1168050967.dsl.bell.ca) | |
| 21:07.39 | IriX64 | apologies my own darn fault that denied thing. |
| 21:13.41 | CIA-7 | BRL-CAD: 03brlcad * 10brlcad/src/libtclcad/tclcadAutoPath.c: (log message trimmed) |
| 21:13.41 | CIA-7 | BRL-CAD: complete rewrite of the auto_path handling code in support of the forthcoming |
| 21:13.42 | CIA-7 | BRL-CAD: tcl/tk upgrade (8.5a5). the logic is entirely changed so that less arbitrary |
| 21:13.42 | CIA-7 | BRL-CAD: searching is performed. now the routine attempts to detect whether it's being |
| 21:13.42 | CIA-7 | BRL-CAD: run from a source directory or from an installed location, and allowing |
| 21:13.44 | CIA-7 | BRL-CAD: TCLCAD_LIBRARY_PATH to be obeyed for additional paths. this needs |
| 21:13.46 | CIA-7 | BRL-CAD: tweaking/testing on other platforms, but the overall approach is a vast |
| 21:17.45 | CIA-7 | BRL-CAD: 03brlcad * 10brlcad/src/mged/setup.c: call TclInitEncodingSubsystem() before Tcl_FindExecutable() in order to avoid what seems to be a race-condition bug inside Tcl_FindExecutable() (bizarre and unknown cause, but this works around the issue) |
| 21:25.06 | CIA-7 | BRL-CAD: 03brlcad * 10brlcad/src/gtools/g_diff.c: use bu_file_exists() instead of stat() to see if the file exists |
| 21:25.39 | brlcad | the big one is just about ready |
| 21:33.18 | brlcad | given how big and different the build system changes are, it's almost guaranteed to break somewhere |
| 21:33.57 | brlcad | i already know that irix is currently busted due to the opennurbs stuff (and a busted mipspro c++ install), but even for linux, this might take some tweaking |
| 21:34.19 | brlcad | but might as well shove it in so the testing and fixing can occur in parallel a little better |
| 21:34.46 | ``Erik | *nod* |
| 21:36.00 | brlcad | and here I bet 8.5x6 will come out within a week or two |
| 21:36.13 | brlcad | s/x6/a6/ |
| 21:47.08 | CIA-7 | BRL-CAD: 03brlcad * 10brlcad/ (352 files in 19 dirs): (log message trimmed) |
| 21:47.08 | CIA-7 | BRL-CAD: upgrade tcl/tk from 8.4.6 to 8.5a5; also move to a recursive configure, using |
| 21:47.08 | CIA-7 | BRL-CAD: AC_CONFIG_SUBDIRS to call upon tcl, tk, and enigma's configure scripts as needed |
| 21:47.08 | CIA-7 | BRL-CAD: instead of redoing their build systems for our purpose. this has a rather |
| 21:47.08 | CIA-7 | BRL-CAD: drastic impact on the way the libraries are linked together, including the need |
| 21:47.08 | CIA-7 | BRL-CAD: to compile tcl/tk static so as to avoid libtool portability issues as well as |
| 21:47.08 | CIA-7 | BRL-CAD: letting us take advantage of their build system for reduced maintenance and |
| 21:47.31 | CIA-7 | BRL-CAD: 03brlcad * 10brlcad/src/other/ (563 files in 20 dirs): (log message trimmed) |
| 21:47.31 | CIA-7 | BRL-CAD: upgrade tcl/tk from 8.4.6 to 8.5a5; also move to a recursive configure, using |
| 21:47.31 | CIA-7 | BRL-CAD: AC_CONFIG_SUBDIRS to call upon tcl, tk, and enigma's configure scripts as needed |
| 21:47.31 | CIA-7 | BRL-CAD: instead of redoing their build systems for our purpose. this has a rather |
| 21:47.31 | CIA-7 | BRL-CAD: drastic impact on the way the libraries are linked together, including the need |
| 21:47.33 | CIA-7 | BRL-CAD: to compile tcl/tk static so as to avoid libtool portability issues as well as |
| 21:47.35 | CIA-7 | BRL-CAD: letting us take advantage of their build system for reduced maintenance and |
| 21:48.21 | CIA-7 | BRL-CAD: 03brlcad * 10brlcad/src/other/ (661 files in 17 dirs): (log message trimmed) |
| 21:48.21 | CIA-7 | BRL-CAD: upgrade tcl/tk from 8.4.6 to 8.5a5; also move to a recursive configure, using |
| 21:48.22 | CIA-7 | BRL-CAD: AC_CONFIG_SUBDIRS to call upon tcl, tk, and enigma's configure scripts as needed |
| 21:48.22 | CIA-7 | BRL-CAD: instead of redoing their build systems for our purpose. this has a rather |
| 21:48.22 | CIA-7 | BRL-CAD: drastic impact on the way the libraries are linked together, including the need |
| 21:48.22 | CIA-7 | BRL-CAD: to compile tcl/tk static so as to avoid libtool portability issues as well as |
| 21:48.22 | CIA-7 | BRL-CAD: letting us take advantage of their build system for reduced maintenance and |
| 21:48.43 | CIA-7 | BRL-CAD: 03brlcad * 10brlcad/src/other/tcl/ (764 files in 15 dirs): (log message trimmed) |
| 21:48.43 | CIA-7 | BRL-CAD: upgrade tcl/tk from 8.4.6 to 8.5a5; also move to a recursive configure, using |
| 21:48.43 | CIA-7 | BRL-CAD: AC_CONFIG_SUBDIRS to call upon tcl, tk, and enigma's configure scripts as needed |
| 21:48.43 | CIA-7 | BRL-CAD: instead of redoing their build systems for our purpose. this has a rather |
| 21:48.43 | CIA-7 | BRL-CAD: drastic impact on the way the libraries are linked together, including the need |
| 21:48.45 | CIA-7 | BRL-CAD: to compile tcl/tk static so as to avoid libtool portability issues as well as |
| 21:48.47 | CIA-7 | BRL-CAD: letting us take advantage of their build system for reduced maintenance and |
| 21:49.12 | CIA-7 | BRL-CAD: 03brlcad * 10brlcad/src/other/tcl/library/tzdata/ (270 files in 16 dirs): (log message trimmed) |
| 21:49.12 | CIA-7 | BRL-CAD: upgrade tcl/tk from 8.4.6 to 8.5a5; also move to a recursive configure, using |
| 21:49.12 | CIA-7 | BRL-CAD: AC_CONFIG_SUBDIRS to call upon tcl, tk, and enigma's configure scripts as needed |
| 21:49.13 | CIA-7 | BRL-CAD: instead of redoing their build systems for our purpose. this has a rather |
| 21:49.13 | CIA-7 | BRL-CAD: drastic impact on the way the libraries are linked together, including the need |
| 21:49.15 | CIA-7 | BRL-CAD: to compile tcl/tk static so as to avoid libtool portability issues as well as |
| 21:49.17 | CIA-7 | BRL-CAD: letting us take advantage of their build system for reduced maintenance and |
| 21:49.52 | CIA-7 | BRL-CAD: 03brlcad * 10brlcad/src/other/ (569 files in 17 dirs): (log message trimmed) |
| 21:49.52 | CIA-7 | BRL-CAD: upgrade tcl/tk from 8.4.6 to 8.5a5; also move to a recursive configure, using |
| 21:49.52 | CIA-7 | BRL-CAD: AC_CONFIG_SUBDIRS to call upon tcl, tk, and enigma's configure scripts as needed |
| 21:49.52 | CIA-7 | BRL-CAD: instead of redoing their build systems for our purpose. this has a rather |
| 21:49.52 | CIA-7 | BRL-CAD: drastic impact on the way the libraries are linked together, including the need |
| 21:49.54 | CIA-7 | BRL-CAD: to compile tcl/tk static so as to avoid libtool portability issues as well as |
| 21:49.56 | CIA-7 | BRL-CAD: letting us take advantage of their build system for reduced maintenance and |
| 21:50.23 | CIA-7 | BRL-CAD: 03brlcad * 10brlcad/src/other/ (592 files in 21 dirs): (log message trimmed) |
| 21:50.23 | CIA-7 | BRL-CAD: upgrade tcl/tk from 8.4.6 to 8.5a5; also move to a recursive configure, using |
| 21:50.23 | CIA-7 | BRL-CAD: AC_CONFIG_SUBDIRS to call upon tcl, tk, and enigma's configure scripts as needed |
| 21:50.23 | CIA-7 | BRL-CAD: instead of redoing their build systems for our purpose. this has a rather |
| 21:50.23 | CIA-7 | BRL-CAD: drastic impact on the way the libraries are linked together, including the need |
| 21:50.26 | CIA-7 | BRL-CAD: to compile tcl/tk static so as to avoid libtool portability issues as well as |
| 21:50.27 | CIA-7 | BRL-CAD: letting us take advantage of their build system for reduced maintenance and |
| 22:02.12 | Maloeran | Oh my, you are being very productive today Sean! |
| 22:03.19 | brlcad | that's a couple weeks of effort actually |
| 22:03.54 | brlcad | it is one "changeset", though it does feel good to finally get it into CVS |
| 22:04.38 | brlcad | that's one of those exceedingly rare examples where it can't be incremental, entire dependency upgrade |
| 22:06.48 | ``Erik | *cough* branch *cough* *cough* O:-) |
| 22:07.36 | brlcad | that would have just delayed it another day overall |
| 22:07.45 | brlcad | and then been dead |
| 22:08.19 | brlcad | iiinteresting, http://code.google.com/p/google-gtags/ |
| 22:10.46 | brlcad | what we should have, however, is a STABLE branch .. for folks like Dan and Lee that need it |
| 22:10.52 | IriX64 | ``Erik checkout ftp://ftp.cygwin.com |
| 22:10.55 | brlcad | not just a tag, but an actual branch |
| 22:14.25 | Maloeran | Cool. Interacting with xmms with the command line interface can pop up error windows on the remote box, but it doesn't say a thing on the command line |
| 22:15.19 | CIA-7 | BRL-CAD: 03brlcad * 10brlcad/NEWS: upgrade of bundled tcl/tk from 8.4.6 to 8.5a5 |
| 22:16.03 | brlcad | or make it one of the highlights of the next release? |
| 22:17.12 | louipc | brlcad: you can refer to archlinux as arch |
| 22:17.20 | brlcad | too late :) |
| 22:17.25 | brlcad | already referring to it as "archlinux" ;) |
| 22:17.34 | louipc | haha that's fine |
| 22:17.55 | louipc | arch is kind of ambiguous too. could be talking about cpu 'architecture' |
| 22:18.34 | brlcad | right, that's part why I didn't like that |
| 22:18.43 | brlcad | what does config.guess say for archlinux? |
| 22:19.57 | ``Erik | tesselation and tnurb stuff isn't done, it's not documented, ... *shrug* |
| 22:20.04 | brlcad | k |
| 22:20.30 | brlcad | you did wireframe and mged edit hooks iirc? |
| 22:20.38 | brlcad | (gui hooks) |
| 22:20.42 | ``Erik | yeah, those're working |
| 22:20.50 | ``Erik | dave just started dorking with it this morning |
| 22:25.50 | CIA-7 | BRL-CAD: 03brlcad * 10brlcad/misc/archlinux/ (Makefile.am PKGBUILD.in brlcad.install.in brlcad.sh.in): |
| 22:25.50 | CIA-7 | BRL-CAD: initial import of packaging files used by Arch Linux, provided by Loui Chang |
| 22:25.50 | CIA-7 | BRL-CAD: (louipc). I took his files and modified them a little so that they are |
| 22:25.50 | CIA-7 | BRL-CAD: auto-populated with configure details, so there are fewer assumptions (cept |
| 22:25.50 | CIA-7 | BRL-CAD: there's no good way to populate the md5 checksum field without tying this to |
| 22:25.54 | CIA-7 | BRL-CAD: 'make dist' somehow; might just be best to remove them). |
| 22:26.23 | CIA-7 | BRL-CAD: 03brlcad * 10brlcad/misc/Makefile.am: traverse into the archlinux directory |
| 22:28.40 | CIA-7 | BRL-CAD: 03brlcad * 10brlcad/configure.ac: create the archlinux files: Makefile, PKGBUILD, brlcad.install, brlcad.sh |
| 22:28.47 | louipc | brlcad: where's config.guess? |
| 22:30.43 | brlcad | louipc: any package that compiles using configure should have a config.guess stashed somewhere |
| 22:30.52 | brlcad | brl-cad's is in misc/config.guess |
| 22:31.07 | brlcad | just run it, and it should give the classic gnu monikers for your system |
| 22:31.20 | brlcad | e.g. $ brlcad/misc/config.guess |
| 22:31.21 | brlcad | i386-apple-darwin8.8.1 |
| 22:31.53 | louipc | oh alright I'm looking from fresh source 'didn't run ./configure' |
| 22:32.25 | brlcad | you probably have a half-dozen config.guess files on your system ;) |
| 22:33.37 | CIA-7 | BRL-CAD: 03brlcad * 10brlcad/ (NEWS AUTHORS): credit Loui Chang (louipc) with integration of BRL-CAD into the Arch Linux packaging system with special thanks for the effort |
| 22:33.59 | louipc | hehe it's very vague i686-pc-linux-gnu |
| 22:34.09 | brlcad | ah, generic linux |
| 22:35.19 | louipc | I'm pretty sure the stock archlinux kernel is tweaked a bit |
| 22:35.43 | louipc | from vanilla |
| 22:36.11 | brlcad | hm, redhat's coming up similarly generic too .. probably just doesn't matter |
| 22:41.48 | *** join/#brlcad Elperion (n=Elperion@p548762CA.dip.t-dialin.net) | |
| 23:07.16 | ``Erik | home at last |
| 23:07.45 | ``Erik | config.guess only sticks around if you ask for something like AC_CANONICAL_SYSTEM |
| 23:09.40 | ``Erik | if you wanna announce meaty-metaballs, knock yourself out... they may change drastically in the next month or two now that the 'customer' is finally putting hands on it |
| 23:10.33 | brlcad | the announcement corresponds to the feature not the user |
| 23:11.08 | ``Erik | <-- just noting that the feature may have major impetus to change very soon |
| 23:11.10 | brlcad | meaning if it was done in a usable state, it's probably worth announcing |
| 23:11.26 | ``Erik | it works, mostly |
| 23:11.43 | ``Erik | um, crank up mged and 'make blah.s metaball' |
| 23:11.43 | brlcad | though missing those two critical pieces |
| 23:11.50 | ``Erik | rt it and two some editing on it |
| 23:12.03 | ``Erik | it's there... can't tesselate and can't convert to nurbs |
| 23:12.19 | brlcad | actually just the first really |
| 23:12.26 | brlcad | the latter isn't critical |
| 23:12.33 | ``Erik | probably needs a proc-db or two entry, and docs *shrug* |
| 23:12.41 | ``Erik | but the evalution formula may change |
| 23:12.47 | ``Erik | evaluation |
| 23:13.07 | brlcad | implementation detail ;) |
| 23:13.10 | ``Erik | but *shrug* if you wanna toss a line in the announce, :D |
| 23:13.27 | brlcad | nah, I was going to give it a couple paragraphs writeup, not just a line |
| 23:13.36 | brlcad | but best to have the tessellation for that really |
| 23:14.27 | brlcad | and some image examples for the few announcement channels that handle rich announcements |
| 23:15.17 | ``Erik | hm, I have a couple images |
| 23:15.36 | brlcad | i'd just as well hold off until next release or after since there's already a writeup with the license changes |
| 23:15.56 | ``Erik | http://math.missouristate.edu/~erik/niceballs.png |
| 23:16.06 | ``Erik | and a couple that were form 1'd for rt06 |
| 23:17.02 | brlcad | i would have just made some up on the fly, spell out brl-cad or somesuch, with texture and bump mapping |
| 23:17.30 | ``Erik | hrm |
| 23:17.39 | ``Erik | well, the code is in cvs, if you wanna *shurg* :D |
| 23:18.30 | brlcad | the code? |
| 23:18.53 | brlcad | oh, well yeah |
| 23:19.03 | brlcad | but again, not if it's still incomplete |
| 23:19.53 | brlcad | (i.e. needing tess) |
| 23:21.39 | IriX64 | http://www.pastebin.ca/379059 |
| 23:24.37 | IriX64 | ermf... |
| 23:26.19 | IriX64 | found where the error message is coming from. |
| 23:26.53 | brlcad | yes, so it's checking if the mapped file is valid, and aborting |
| 23:27.14 | IriX64 | looks like it. |
| 23:27.23 | brlcad | it should recognize earlier that the mapped file is invalid and terminate more gracefully |
| 23:27.33 | brlcad | the trick is where in g_dsp does it abort? |
| 23:27.41 | IriX64 | does that routine get called on every file, it must no? |
| 23:28.42 | IriX64 | dude? whats the proper return for error encountered? |
| 23:29.37 | brlcad | ``Erik: don't know how many papers you have on the subject, but there were some great ones last year on tessellation of arbitrary implicit surfaces using particles that is impressive |
| 23:31.17 | brlcad | it would work exceptionally well for tessellation of metaballs in particular |
| 23:32.18 | brlcad | hmm.. here's one of the main guy's papers from a couple years ago: http://graphics.cs.uiuc.edu/~jch/papers/complex.pdf |
| 23:35.34 | brlcad | ahh, and more recently : http://graphics.cs.uiuc.edu/~jch/papers/voronoi.pdf |
| 23:38.19 | IriX64 | wonder if that'll actually work, oh well. |
| 23:38.40 | IriX64 | had to start this build i'll develop required patience yet. |
| 23:38.46 | brlcad | if you can pinpoint where it aborts, I can probably fix it |
| 23:39.03 | IriX64 | man bu.h no error return on it. |
| 23:39.13 | IriX64 | ck_mag |
| 23:40.03 | IriX64 | err bu_ck_mag i think. |
| 23:41.32 | IriX64 | if you're patient, i can let you know if that cheezy fix fixes it. |
| 23:41.59 | brlcad | avoiding the check isn't interesting .. it aborts there correctly |
| 23:42.21 | brlcad | the point is to find where in g_dsp that it is aborting, detecting that situation beforehand and just returning a failure instead |
| 23:42.28 | brlcad | if you know where in g_dsp, I'll take a loot |
| 23:42.29 | IriX64 | not avoiding the check. |
| 23:42.47 | brlcad | edits to bu.h are wrong |
| 23:42.49 | IriX64 | line? i posted it... 1334 i think. |
| 23:43.03 | brlcad | in g_dsp.c ? |
| 23:43.07 | IriX64 | yes |
| 23:43.14 | IriX64 | lemme verify. |
| 23:43.21 | ``Erik | particles? hrm, I just outlined 3 "classic" approaches in a project plan a couple weeks ago... marching cubes, ray shot hack (lee's idea, go figure) and using tnurbs as an intermediate |
| 23:44.08 | brlcad | marching cubes is the classic |
| 23:44.08 | IriX64 | 3134 |
| 23:44.13 | ``Erik | ancient, even |
| 23:44.18 | ``Erik | so old that the patent has expired. |
| 23:44.24 | brlcad | ray shot hack is undoubtedly a variation of marching cubes to make it work |
| 23:44.40 | ``Erik | kinda sorta almost, I suppose |
| 23:44.45 | IriX64 | got that line 3134 in dsp_g.c |
| 23:44.50 | ``Erik | lee's answer to every geometry problem is to shoot rays through it and approximate |
| 23:44.54 | brlcad | the particles stuff is impressive |
| 23:44.58 | brlcad | and instant |
| 23:45.17 | IriX64 | err g_dsp.c |
| 23:45.24 | ``Erik | I grabbed the newer paper you pasted |
| 23:45.28 | ``Erik | is it worth grabbing the older one? |
| 23:45.42 | brlcad | IriX64: ah, hm, interesting |
| 23:45.58 | brlcad | yeah, the older is the basis for the newer |
| 23:46.09 | brlcad | hart is like the main implicit surfaces guy in the field |
| 23:46.12 | ``Erik | ok, wgot. |
| 23:46.22 | brlcad | http://graphics.cs.uiuc.edu/~jch/papers/ |
| 23:46.33 | brlcad | he's got tons of interesting stuff of relevance |
| 23:47.05 | brlcad | but those two are probably the most relevant for metaballs as they outline an exact approach |
| 23:47.07 | ``Erik | hm, uni of illinois is consistantly a name that pops up in graphics |
| 23:47.27 | ``Erik | all cs things, really :/ mebbe moreso than north carolina |
| 23:48.02 | ``Erik | perhaps an odd twist of the midwest mentality... "ain't nothin' to do but drink and fuck"... and those who can't get tail or booze... code? :D *duck* |
| 23:49.03 | brlcad | you've seen hart before, he's almost always presenting or organizing at siggraph |
| 23:51.17 | ``Erik | if I say in a session he's spoken at before... I've only been to one siggraph |
| 23:51.37 | ``Erik | and I was pretty heavy on fluid dynamics at that one |
| 23:51.43 | ``Erik | a bit on high perf rt |
| 23:51.46 | brlcad | ahh, that's right |
