| 01:09.28 | *** join/#brlcad andrecastelo_ (n=chatzill@189.71.62.158) | |
| 02:06.15 | brlcad | starseeker: I uploaded the solaris dist, so forget about it |
| 02:08.55 | starseeker | Ah - thanks! |
| 02:10.15 | CIA-24 | BRL-CAD: 03brlcad * r32499 10/brlcad/trunk/include/ged.h: ws |
| 02:12.04 | CIA-24 | BRL-CAD: 03brlcad * r32500 10/brlcad/trunk/include/ged.h: doxygenify the macros |
| 03:03.57 | *** join/#brlcad Twingy (n=justin@74.92.144.217) | |
| 03:48.43 | *** join/#brlcad andrecastelo__ (n=chatzill@189.71.43.146) | |
| 04:25.51 | CIA-24 | BRL-CAD: 03brlcad * r32501 10/brlcad/trunk/include/ged.h: add a GED_CHECK_ARGC_GT_0 macro to make sure argc is > 0 on all commands. this really belongs in a wrapper function for categories of commands, but it'll do fo r now and is better than having the replication throughout. |
| 04:27.12 | brlcad | ~botmail send mafm curious that you only added the argc < 1 check to some commands but not others -- was that intentional? |
| 04:28.06 | brlcad | ~botmail for mafm: curious that you only added the argc < 1 check to some commands but not others -- was that intentional? |
| 04:28.11 | brlcad | there we go |
| 04:28.19 | brlcad | stupid syntax |
| 04:30.30 | CIA-24 | BRL-CAD: 03brlcad * r32502 10/brlcad/trunk/src/mged/ (chgmodel.c chgtree.c cmd.c muves.c utility2.c): quell constness warnings |
| 04:30.44 | CIA-24 | BRL-CAD: 03brlcad * r32503 10/brlcad/trunk/src/mged/setup.c: fix/update the function sig |
| 04:31.14 | CIA-24 | BRL-CAD: 03brlcad * r32504 10/brlcad/trunk/src/libged/ (154 files): use the new GED_CHECK_ARGC_GT_0 macro throughout to elimiate the 'invalid command name' block. really belongs in a wrapper, but good enough until there are command categories. |
| 07:42.35 | *** join/#brlcad thing0 (n=ric@123.208.46.243) | |
| 07:58.46 | *** join/#brlcad cad18 (n=5b422263@bz.bzflag.bz) | |
| 08:19.48 | *** join/#brlcad alex_joni (n=juve@emc/board-of-directors/alexjoni) | |
| 08:32.19 | *** join/#brlcad geocalc (n=geocalc@91-171-217-174.rev.libertysurf.net) | |
| 08:38.30 | brlcad | yawns and wanders on home |
| 09:08.35 | brlcad | yawns and arrives home, ponders foodage |
| 09:34.15 | *** join/#brlcad clock_ (n=clock@84-72-91-240.dclient.hispeed.ch) | |
| 09:57.10 | Axman6 | hands brlcad some corn chips |
| 10:00.23 | brlcad | :) |
| 10:00.30 | brlcad | munches happily |
| 10:04.49 | *** join/#brlcad elite01 (n=elite01@unaffiliated/elite01) | |
| 10:07.52 | *** join/#brlcad mafm (n=mafm@elnet-111.lip.pt) | |
| 10:08.50 | mafm | hi cadheaddies :P |
| 10:19.45 | *** join/#brlcad thing0 (n=ric@123.208.42.135) | |
| 12:30.31 | *** join/#brlcad thing0 (n=ric@124-169-89-189.dyn.iinet.net.au) | |
| 13:06.12 | *** join/#brlcad d_rossberg (n=rossberg@bz.bzflag.bz) | |
| 13:36.17 | starseeker | brlcad: Am I correct that the issue with the libpng/dyld confusion on OSX 10.5 is something that will require a fix from Apple? |
| 13:52.20 | starseeker | glares at nmgs and iges-g |
| 13:54.15 | *** join/#brlcad thing0 (n=ric@124-169-28-44.dyn.iinet.net.au) | |
| 14:00.42 | *** join/#brlcad thing1 (n=ric@124-169-28-44.dyn.iinet.net.au) | |
| 14:01.42 | brlcad | starseeker: nah, I think there's a way to work around it |
| 14:01.58 | brlcad | but I haven't had my hands on a 10.5 to even try |
| 14:05.33 | starseeker | mmm. So the bug stays open then. |
| 14:05.35 | starseeker | k |
| 14:07.48 | starseeker | heads in |
| 14:28.12 | *** join/#brlcad clock_ (n=clock@84-72-91-240.dclient.hispeed.ch) | |
| 14:39.10 | CIA-24 | BRL-CAD: 03d_rossberg * r32505 10/brlcad/trunk/src/libged/autoview.c: "small" is already defined in MS Windows SDK, renamed it to sqrt_small |
| 14:59.39 | prasad1 | usain bolt is the man |
| 14:59.41 | prasad1 | lol |
| 14:59.46 | prasad1 | Bolt tears down the track after Powell and actually finishes in front of the Netherlands. |
| 15:00.31 | clock_ | tightens the kingpin bolt on his skateboard and inserts brand new Powell bearings |
| 15:00.56 | clock_ | USA in bolt |
| 15:09.54 | *** join/#brlcad elite01 (n=elite01@unaffiliated/elite01) | |
| 15:17.02 | *** join/#brlcad mas3773 (n=mas3773@75-13-4-215.lightspeed.kscyks.sbcglobal.net) | |
| 16:31.54 | *** join/#brlcad elite01_ (n=elite01@unaffiliated/elite01) | |
| 17:17.31 | *** join/#brlcad andrecastelo (n=chatzill@189.71.43.146) | |
| 17:44.31 | mafm | bye bye |
| 17:50.27 | brlcad | looks like he finished the apt packaing: http://groups.google.com/group/linux.debian.bugs.dist/browse_thread/thread/983e8306acd1c080?hl=en |
| 18:27.06 | *** join/#brlcad pacman87 (i=127@resnet-45-219.dorm.utexas.edu) | |
| 18:27.11 | brlcad | andrecastelo: it'd be good to have a couple nice high-quality renderings of where your ray-tracer currently sits for a write-up |
| 18:27.16 | brlcad | ooh, there he be |
| 18:27.20 | brlcad | same for you pacman87 :) |
| 18:27.30 | pacman87 | hmmm? |
| 18:27.43 | brlcad | did you happen to see the guy's comment on the mailing list? |
| 18:28.00 | pacman87 | i've been out of it for the past 24ish hours |
| 18:28.07 | brlcad | it was a few days ago |
| 18:28.17 | pacman87 | checks |
| 18:28.45 | brlcad | it might have been on the forums |
| 18:28.49 | pacman87 | i need to pack to leave in half an hour |
| 18:28.53 | pacman87 | grandmother's funeral |
| 18:28.56 | pacman87 | back sunday |
| 18:29.02 | brlcad | aww, sorry to hear that |
| 18:29.18 | brlcad | forget about it then |
| 18:29.22 | pacman87 | when do i need to finish the final gsoc survey by? |
| 18:29.35 | brlcad | looks |
| 18:30.12 | brlcad | pacman87: looks like the end of the monthh |
| 18:30.26 | brlcad | sept 1st being the eval deadline |
| 18:30.37 | pacman87 | ok, it can wait til i get back |
| 18:32.29 | brlcad | yeah, and what I mentioned isn't for the eval -- it's for a report I'm putting together |
| 18:32.35 | brlcad | for our community and for other gsocers |
| 18:32.51 | pacman87 | ah, ok |
| 18:59.16 | andrecastelo | brlcad: ok, will do! |
| 19:01.45 | brlcad | thx |
| 19:15.21 | andrecastelo | truck rendering: http://img176.imageshack.us/img176/169/truckks2.jpg |
| 19:16.28 | andrecastelo | and this is what happens when shadow was supposed to occur: http://img147.imageshack.us/img147/3701/greycornellra2.jpg and http://img141.imageshack.us/my.php?image=bluecornelllp7.jpg (blue was set as the 'shadow') |
| 19:16.36 | brlcad | was more thinking something at 2048x2048, lot more detailed :) |
| 19:17.07 | andrecastelo | and the mlib errors: http://img296.imageshack.us/img296/2043/mliberrorseh9.jpg |
| 19:17.09 | andrecastelo | hm i see |
| 19:18.20 | brlcad | mm, looks like you're going through liboptical now? |
| 19:19.33 | andrecastelo | ``Erik thinks it sets one material for every one |
| 19:20.16 | andrecastelo | i mean, the same material for every region |
| 19:20.35 | brlcad | materials only matter to liboptical, so I take that's a yes? :) |
| 19:21.16 | brlcad | render onto a white background too, that'll print better |
| 19:22.23 | andrecastelo | still, the material set up is similar to rt o.O |
| 19:23.04 | brlcad | yeah, something clearly is amiss there |
| 19:28.41 | ``Erik | more important, it spews mlib errors about missing material with several 'should be there' mats, so yeah, something missing with liboptical interface |
| 19:30.03 | ``Erik | notes that the "parallel issue" is still there and may possibly be a contributing factor? |
| 19:32.31 | andrecastelo | ``Erik: could be, I'll try expanding it |
| 19:37.53 | andrecastelo | notices issues with the file output in rtmlt |
| 19:41.14 | andrecastelo | it may also have something to do with the parallel issue |
| 19:50.42 | andrecastelo | ``Erik: what is that parameter to use more threads? |
| 19:57.27 | ``Erik | -P |
| 19:57.46 | ``Erik | -P8 for example |
| 20:09.14 | brlcad | man rt or brlman rt will list a slew of options that you're getting for free by being an rtui app |
| 20:09.34 | starseeker | brlcad: well, it looks like the region_id bug wasn't a bug after all |
| 20:09.50 | brlcad | what was it? |
| 20:10.30 | starseeker | they had a model that did a nasty subtraction of an entire assembly (tree with multiple regions below the top level) and also included the tree they subtracted - using reid on that tree cause multiple renamings of regions |
| 20:11.02 | starseeker | Dwayne was getting second hand info, apparently - once I got a direct look at it it made sense |
| 20:11.33 | andrecastelo | ``Erik: can you do rtmlt -P4 truck.g g4 and tell me what happens? I've added the bufmode options, and it's drawing nicely with -PX |
| 20:11.49 | starseeker | the correct thing to do would be to fix the model, but since that's unlikely running reid on the individual subtrees should work just fine |
| 20:12.35 | starseeker | if we wanted to we could make reid smart about not changing the region_id of a region more than once in an assignment, but that may or may not satisfy expectations |
| 20:13.30 | brlcad | mm, interesting |
| 20:13.47 | starseeker | they REALLY need to fix their subtractions |
| 20:13.48 | brlcad | reid does just do a simple recursive walk |
| 20:14.07 | starseeker | nods |
| 20:14.19 | brlcad | iirc it builds up a region list before applying changes |
| 20:14.49 | starseeker | hmm. Did its behavior change since 7.10.4? |
| 20:15.02 | starseeker | (they've got an old version linked to stable for some reason) |
| 20:15.20 | brlcad | nope |
| 20:15.24 | starseeker | huh. |
| 20:16.03 | brlcad | yeah, looks like it builds up a final list of regions for all specified tree(s) and then incrementally sets each |
| 20:16.14 | brlcad | in order encountered |
| 20:16.20 | starseeker | does it check for duplicate entries? |
| 20:16.22 | brlcad | so hm, if listed multiple times.. |
| 20:16.36 | starseeker | is 99% sure that's where the trouble is |
| 20:16.52 | starseeker | it did just fine until multiple references crept in |
| 20:17.08 | brlcad | no, it definitely does not |
| 20:17.10 | brlcad | runs a test |
| 20:17.46 | starseeker | Do we want to? it might slow things down on big models |
| 20:20.13 | brlcad | hm, that still doesn't fully explain the 32k limit |
| 20:20.25 | starseeker | I didn't see the 32k limit |
| 20:20.35 | starseeker | I think we were getting confused reporting |
| 20:20.41 | brlcad | so then what was the actual problem? |
| 20:20.47 | brlcad | id's that were larger than they expected? |
| 20:21.08 | brlcad | because my tests are working and are doing what I'd expect -- they just get incremented multiple times |
| 20:21.14 | starseeker | right - or when they looked at a tree and expected 301, 302, 303... and didn't always get it |
| 20:21.37 | starseeker | They might get 301, 302, 311, 304, 322, ... |
| 20:21.38 | brlcad | they'd get 301, 305, 306, 309 etc |
| 20:21.42 | brlcad | sure |
| 20:21.53 | starseeker | I think that's what was doing it |
| 20:22.08 | starseeker | I successfully assigned numbers WAY over 32k |
| 20:22.21 | brlcad | *shrug*, that's not supposed to be a big deal .. the 32k was what sounded like a problem |
| 20:22.36 | starseeker | agreed |
| 20:22.41 | brlcad | there was a 32k limit in one of the fastgen tools, maybe that's what they were getting confused with |
| 20:23.12 | starseeker | could be. When I went over the behavior they presented me with as a problem was as described above |
| 20:24.21 | starseeker | I think up until now they've always had well behaved (or at least xpushed) models that did increment in order |
| 20:26.32 | brlcad | negatives above the region level are usually evil |
| 20:26.55 | andrecastelo | ``Erik: i'll commit, apparently it works. Didn't fix shadow or file output issues |
| 20:27.04 | brlcad | but pretty prevalent unfortunately |
| 20:27.27 | starseeker | was tempted to call the orca guys and offer to fix the model to make the problem go away... |
| 20:30.59 | CIA-24 | BRL-CAD: 03andrecastelo * r32506 10/brlcad/trunk/src/rt/viewmlt.c: Added BUFMODE support to rtmlt: modified view_pixel() and view_2init(). Added reproject_worker() and reproject_splat(). |
| 20:33.45 | starseeker | closes bug... yay! |
| 20:38.03 | andrecastelo | brlcad: output to file is a little weird. The bigger the image, the bigger the artifacts and problems (more like, the longer the scanlines are shifted to the right) |
| 20:39.05 | brlcad | ~starseeker++ |
| 20:39.07 | andrecastelo | s/scanlines/lines of pixels |
| 20:39.44 | brlcad | andrecastelo: sounds like you either have a multithreading I/O bug or you're writing the wrong number of pixels per scanline |
| 20:51.47 | CIA-24 | BRL-CAD: 03starseeker * r32507 10/brlcad/trunk/doc/docbook/system/mged/mged_commands.xml: Add note about correction to VOLII example - error is in pdf so will need to be caught/changed when that command is eventually docbooked. |
| 20:53.10 | starseeker | closes VolumeII arced bug |
| 21:19.10 | CIA-24 | BRL-CAD: 03brlcad * r32508 10/brlcad/trunk/ (NEWS src/tclscripts/mged/reid.tcl): (log message trimmed) |
| 21:19.10 | CIA-24 | BRL-CAD: add support to get_regions to ignore duplicate regions in the hierarchy so that |
| 21:19.10 | CIA-24 | BRL-CAD: get_regions only lists all regions once. this makes it so that reid will |
| 21:19.10 | CIA-24 | BRL-CAD: similarly only set the regionID on a region once instead of incrementing it |
| 21:19.12 | CIA-24 | BRL-CAD: multiple times (if it was, say, subtracted at an assembly level as well as used |
| 21:19.14 | CIA-24 | BRL-CAD: elsewhere as a positive region). this fixes an unexpected behavior reported by |
| 21:19.16 | CIA-24 | BRL-CAD: dwayne et al. also made get_regions work on single regions where the only |
| 21:19.51 | starseeker | brlcad: thanks! |
| 21:28.57 | CIA-24 | BRL-CAD: 03brlcad * r32509 10/brlcad/trunk/src/tclscripts/mged/remat.tcl: refactor remat to use get_regions so that it gets the same benefits of only setting the materialID once per region (even if it doesn't change anything). simplifies the implementation a bit anyways. |
| 21:35.05 | CIA-24 | BRL-CAD: 03brlcad * r32510 10/brlcad/trunk/src/tclscripts/mged/remat.tcl: sort the commands by order of use and add db |
| 21:37.18 | CIA-24 | BRL-CAD: 03brlcad * r32511 10/brlcad/trunk/src/tclscripts/mged/ (Makefile.am get_regions.tcl): separate out get_regions into its own file since even though it's an under-the-hood devish command, it's useful stand-alone |
| 21:38.06 | CIA-24 | BRL-CAD: 03brlcad * r32512 10/brlcad/trunk/src/tclscripts/mged/reid.tcl: remove get_regions from here since it's used in other places now, remove authorship, list all deps |
| 21:44.43 | CIA-24 | BRL-CAD: 03brlcad * r32513 10/brlcad/trunk/src/tclscripts/mged/ (help.tcl helpdevel.tcl): move get_regions from being a user command to being a developer command. minor rewordings |
| 21:45.52 | brlcad | gets bored poking on Tcl, looks for some C code to play with |
| 21:46.10 | starseeker | heh |
| 21:46.42 | CIA-24 | BRL-CAD: 03brlcad * r32514 10/brlcad/trunk/src/tclscripts/mged/help.tcl: oops, save the file first |
| 21:48.11 | *** join/#brlcad clock__ (n=clock@217-162-111-77.dclient.hispeed.ch) | |
| 22:21.02 | starseeker | brlcad: Looking at the report about attr set region not resulting in attr show printing a region type identification, I think it's because the dp->d_flags type is not changed when attr sets the region attribute. Should attr be automatically spotting the setting of region and changing the flag to DIR_REGION as well? |
| 22:22.08 | starseeker | from what I can tell, it almost looks like MGED is creating a new region combination to replace the old combination when the flag is toggled there, but I'm not sure yet |
| 22:22.34 | starseeker | looks at clock and decides he'd better get a move on |
| 22:54.03 | CIA-24 | BRL-CAD: 03homovulgaris * r32515 10/brlcad/trunk/src/libpc/pcVariable.h: stopping the usage of VarDomain class so as to begin support for non-unique solutions |
| 23:06.25 | CIA-24 | BRL-CAD: 03homovulgaris * r32516 10/brlcad/trunk/src/libpc/ (pcSolver.h pcVariable.h): removal of VarDomain code, testing addSolution method : only Var pointers transfered between solver and solution |
| 23:30.27 | *** join/#brlcad archivist_ub (n=archivis@host81-149-119-172.in-addr.btopenworld.com) | |
| 23:35.17 | CIA-24 | BRL-CAD: 03homovulgaris * r32517 10/brlcad/trunk/src/libpc/ (pcParameter.cpp pcSolver.h solver_test.cpp): passing multiple messages to solution class by modification of the solver, adding numSolutions() method to PCSolver to return the number of solutions found, coding style edits |
| 23:50.49 | *** join/#brlcad ChanServ (ChanServ@services.) | |
| 23:50.49 | *** join/#brlcad archivist_ub (n=archivis@host81-149-119-172.in-addr.btopenworld.com) [NETSPLIT VICTIM] | |
| 23:50.49 | *** join/#brlcad alex_joni (n=juve@emc/board-of-directors/alexjoni) [NETSPLIT VICTIM] | |
| 23:50.49 | *** mode/#brlcad [+o ChanServ] by irc.freenode.net | |
| 23:52.58 | *** join/#brlcad ChanServ (ChanServ@services.) | |
| 23:52.58 | *** join/#brlcad archivist_ub (n=archivis@host81-149-119-172.in-addr.btopenworld.com) [NETSPLIT VICTIM] | |
| 23:52.58 | *** join/#brlcad alex_joni (n=juve@emc/board-of-directors/alexjoni) [NETSPLIT VICTIM] | |
| 23:52.58 | *** mode/#brlcad [+o ChanServ] by irc.freenode.net | |
