| 00:37.38 | IriX64 | 4 hrs i should have a cassie 4.1.1 :) |
| 00:50.11 | CIA-9 | BRL-CAD: 03brlcad * 10brlcad/misc/win32-msvc7/mged/mged.vcproj: don't define DM_X, should be only using DM_WGL now on Windows |
| 00:52.42 | *** join/#brlcad ``Erik (i=erik@c-69-250-155-85.hsd1.md.comcast.net) |
| 00:58.07 | CIA-9 | BRL-CAD: 03brlcad * 10brlcad/src/libdm/ (dm-generic.c dm_obj.c libdm.dsp query.c tcl.c): decouple DM_X from the other display manager interfaces, clean up the preprocessor logic so Windows does not need to declare it |
| 01:21.33 | IriX64 | how long do we wait before we can post after a CIA-9 post? |
| 01:26.11 | *** join/#brlcad PrezKennedy (n=Apathy@c-69-250-236-100.hsd1.md.comcast.net) |
| 01:26.47 | IriX64 | reboot, back later. |
| 01:37.43 | *** join/#brlcad IriX64 (n=IriX64@toronto-HSE-ppp4303834.sympatico.ca) |
| 01:39.54 | IriX64 | Did I get an answer? Time after CIA-9 posts before mere mortals can post again? |
| 02:32.15 | brlcad | IriX64: don't understand the question |
| 02:33.11 | brlcad | CIA merely posts a notification when a CVS commit is performed to the source repository, so everyone knows exactly who is doing what and when generally speaking |
| 02:35.40 | CIA-9 | BRL-CAD: 03brlcad * 10brlcad/configure.ac: check for pipe() |
| 02:43.44 | IriX64 | just thought i was interefering with development. |
| 02:44.14 | IriX64 | thought there was a protocol of some type here. |
| 02:50.46 | brlcad | only when you go on your pasting rampages |
| 02:52.20 | brlcad | if there's design or development discussions going on, off-topic and just basic "chit-chat" chatter would be frowned upon but not when we're like this |
| 02:52.40 | IriX64 | thanks for the explanation. |
| 02:52.42 | brlcad | relatively low energy in the channel, simple to manage.. nobody has to wade through to get a word in |
| 02:53.07 | IriX64 | my diff is huge :) |
| 02:53.35 | IriX64 | aieeeee patch broke ;) |
| 02:55.09 | IriX64 | 9 minuts? thought my system was faster than that. |
| 02:55.21 | CIA-9 | BRL-CAD: 03brlcad * 10brlcad/src/mged/ (10 files): decouple DM_X from the other display manager interfaces, clean up the preprocessor logic so Windows does not need to declare DM_X but also to avoid using _WIN32 where possible as well. |
| 02:55.50 | brlcad | you ever figure out why your wallclock counts are so low? |
| 02:56.04 | IriX64 | didnt want to do the math. |
| 02:56.41 | IriX64 | lets see what bench has to say. |
| 02:59.05 | brlcad | your rtfm was fine |
| 02:59.16 | brlcad | but it is WAY off your wallclock count, which isn't right |
| 02:59.57 | IriX64 | think i fixed it doing a raytrace right now. |
| 03:00.08 | brlcad | implies something systemic is abnormal with your system |
| 03:00.19 | IriX64 | hrmmph problem is bench is running too. |
| 03:00.44 | brlcad | like it's abnormally busy doing way too many other things while the benchmark is running, or you have several benchmarks running simultaneously |
| 03:01.27 | IriX64 | when are you going to use your overlap tool to fix the overlaps in havoc? |
| 03:02.58 | IriX64 | benching bldg391 whil i'm raytracing havoc, get real. |
| 03:03.41 | brlcad | fixing havoc is left as an exercise for someone in the community |
| 03:05.09 | IriX64 | 496829 rays in 12.38 secs = 40147.80 rays/sec (RTFM) and 496829 rays in 242.18 secs = 2051.49 rays/sec (Wallclock) that better? |
| 03:05.33 | IriX64 | and bench just fixished. |
| 03:06.32 | IriX64 | 2844 times faster than the 780. not bad i guess. |
| 03:08.05 | IriX64 | now how the heck did translate break (sigh) |
| 03:10.37 | IriX64 | what do you *mean its the shift key not the ctrl key? (I'm in ramble on mode) |
| 03:11.16 | IriX64 | got them backwards thats all ill just change the docs, cheap fix. :) |
| 03:11.17 | brlcad | no that's not better |
| 03:11.37 | brlcad | the rays/sec for wallclock shouldn't be more than 10% different from the RTFM rays/sec |
| 03:11.54 | IriX64 | explain why. |
| 03:12.36 | brlcad | you're currently at about 2000% different |
| 03:12.43 | Twingy | cause you aint running anything else |
| 03:12.50 | brlcad | i can't explain why without seeing what's going on |
| 03:12.52 | IriX64 | but explain how its supposed to be 10% |
| 03:12.53 | Twingy | brlcad, news on parallels licenses? |
| 03:12.57 | brlcad | does it actually take 242 seconds to raytrace? |
| 03:13.03 | IriX64 | yes |
| 03:13.17 | brlcad | Twingy: beats me, i haven't been in to the office since well before siggy |
| 03:13.29 | Twingy | are you on vacation? |
| 03:13.47 | brlcad | not really |
| 03:13.50 | brlcad | just haven't been back |
| 03:13.56 | brlcad | it's only been a day |
| 03:14.16 | Twingy | but darlene has the order right? |
| 03:15.22 | Twingy | if not I'll have her order one for me |
| 03:16.33 | IriX64 | perhaps itll help if we compare output devices? |
| 03:17.08 | brlcad | i have no idea what the status is |
| 03:19.17 | Twingy | k, if Wendy comaplains I will get Drew to order for me |
| 03:21.47 | brlcad | IriX64: 9 chances out of 10, it's not a brl-cad configuration issue |
| 03:21.59 | brlcad | it's something going on with your system |
| 03:22.10 | brlcad | run top or something to see what's eating up cpu cycles |
| 03:25.15 | IriX64 | at the moment loadavg is 0% |
| 03:25.46 | brlcad | i find that hard to believe |
| 03:25.50 | brlcad | what does uptime say? |
| 03:25.57 | IriX64 | hey irc takes nothing. |
| 03:26.04 | IriX64 | nothing else going on. |
| 03:26.20 | IriX64 | let me check taskmanager. |
| 03:26.31 | brlcad | ooh, you're on windows? |
| 03:26.31 | IriX64 | both agree 0-1% load. |
| 03:26.42 | IriX64 | sorta |
| 03:26.56 | brlcad | softa? you either are or aren't :) |
| 03:27.07 | IriX64 | do a ver on me. |
| 03:27.27 | brlcad | that doesn't tell me anything about what kernel/OS you're running |
| 03:27.27 | IriX64 | *nix high on windows. :) |
| 03:27.40 | brlcad | only you know that |
| 03:28.02 | brlcad | just by the fact that you have taskmanager though pretty much says it |
| 03:28.07 | IriX64 | all right windows xp base running cygwin_nt |
| 03:28.15 | brlcad | fair enough |
| 03:28.21 | Twingy | and your nickname is Irix64 *boggle* |
| 03:28.29 | IriX64 | you picked it. |
| 03:28.37 | brlcad | i suspect you do have hidden processes running that are hiding themselves from the taskmanager |
| 03:28.47 | brlcad | rather cpu-intensive ones |
| 03:28.47 | IriX64 | no way |
| 03:28.56 | IriX64 | i would know |
| 03:28.58 | brlcad | heh |
| 03:29.00 | IriX64 | err |
| 03:29.06 | brlcad | and how praytell would you know? |
| 03:29.13 | IriX64 | yah groaner :) |
| 03:29.22 | brlcad | you have a massive indicator right there with the performance number |
| 03:29.28 | brlcad | massive massive descrepancy |
| 03:29.44 | IriX64 | on my system *everything that runs is given a name and entered into task manager |
| 03:29.45 | brlcad | tis the nature of much spyware |
| 03:30.03 | IriX64 | no empahtically no. |
| 03:30.04 | brlcad | nah, you can run apps that are hidden from taskmanager |
| 03:30.10 | brlcad | used to do that back in the day |
| 03:30.12 | IriX64 | not *here. |
| 03:30.21 | Twingy | I think you should install parallels rather than arguing with IriX64 |
| 03:30.30 | brlcad | you're on windows, it's possible |
| 03:30.50 | IriX64 | what are parallels? |
| 03:31.06 | IriX64 | ok brlcad its possible. |
| 03:31.08 | brlcad | heck, it could even be a virus infected dll or other system-level injection |
| 03:31.21 | brlcad | that could go completely undetected |
| 03:31.29 | IriX64 | what do *you raytrace to? |
| 03:31.41 | brlcad | parallels is a virtual machine |
| 03:31.52 | IriX64 | vmware style? |
| 03:31.52 | brlcad | sort of like vmware |
| 03:31.52 | brlcad | but cheaper |
| 03:32.01 | brlcad | less developer-feature-filled |
| 03:32.11 | IriX64 | got os/2 warp 4 to run on vmware but what a slug. |
| 03:32.12 | brlcad | but capable of running multiple simultaneous OS images |
| 03:33.33 | IriX64 | i'm told brlcad can bench press three of ``Erik :) |
| 03:35.12 | brlcad | not from the looks of his belly recently :) *ahem* |
| 03:44.49 | IriX64 | you've seen my belly? *shrug* I don't hide it. |
| 03:45.00 | IriX64 | :) |
| 03:45.44 | IriX64 | you're wondering about me lets get peronal, I'm Mario and i'm class of 54. |
| 03:46.07 | IriX64 | errrr personal too. :) |
| 03:46.57 | brlcad | actually i meant erik's but good to know mario |
| 03:47.06 | IriX64 | brlcad i put you in your early 40's? |
| 03:47.32 | brlcad | nah, i'm a young whipper snapper |
| 03:47.36 | brlcad | at least that's what I tell myself |
| 03:47.47 | IriX64 | hah so do I.:) |
| 03:50.10 | *** join/#brlcad DTRemenak (n=Daniel_R@c-24-23-59-104.hsd1.ca.comcast.net) |
| 03:51.45 | *** join/#brlcad IriX64 (n=mario_du@toronto-HSE-ppp4303834.sympatico.ca) |
| 03:52.08 | IriX64_ | my night at the opera, see if you can find me. |
| 04:08.29 | *** join/#brlcad IriX64 (n=IriX64@toronto-HSE-ppp4303834.sympatico.ca) |
| 04:08.47 | IriX64 | back to shift grips :) |
| 04:16.08 | *** join/#brlcad IriX64 (n=Who@toronto-HSE-ppp4303834.sympatico.ca) |
| 04:18.14 | IriX64 | IriX64_: Doofus you said shift grips :) |
| 04:25.38 | IriX64 | we were talking about rtfm to wallclock times, whats the ratio? |
| 04:26.53 | CIA-9 | BRL-CAD: 03brlcad * 10brlcad/BUGS: debugbu 2 immediately reports a bu_vls_free() error.. apparently been a problem since 4.5 days at least (bug found in doc/html/manuals/mged/bugs) |
| 04:27.47 | IriX64 | bug i can bring up two instances of mged (or is this by design?) |
| 04:28.18 | CIA-9 | BRL-CAD: 03brlcad * 10brlcad/doc/html/manuals/mged/ (Makefile.am bugs): get rid of doc/html/manuals/mged/bugs .. the main bug in there was verified to still be a problem and was added to the BUGS file. either way, we don't need this old 'bugs' file any more. |
| 04:31.05 | IriX64 | may i send you my mged.exe? |
| 04:32.13 | IriX64 | you think only cvs people are capable of contributing? |
| 04:34.13 | brlcad | the rtfm rays/sec and the wallclock rays/sec should be within 10% of each otehr, so a ratio of .. 9:10 or thereabouts? |
| 04:34.47 | brlcad | being able to run multiple mgeds is definitely by design |
| 04:36.04 | IriX64 | 9:10? lets define this, a ray is considered finished when? |
| 04:37.18 | brlcad | there's documentation on the various values that I'd rather not describe over irc .. maybe read the benchmark.tr nroff document if you *really* want to know |
| 04:37.35 | brlcad | but suffice it to say that they should NOT be that different rays/sec if everything is "normal" |
| 04:37.51 | IriX64 | *really* yes. |
| 04:39.49 | brlcad | rtfm takes into consideration several aspects outside of your control like how long it takes a process to start up only counting the CPU time that you are actually allocated |
| 04:40.17 | brlcad | wallclock time counts the amount of actual time elapsed as measured by a clock |
| 04:41.16 | IriX64 | how do you measure cpu time what function please clock() or time()? |
| 04:41.20 | brlcad | those shouldn't only be within 10% .. they should be nearly identical .. but some systems are better than others and there's some minor variance based on how busy systems are, how long the context switches are, etc |
| 04:41.53 | IriX64 | why dont i just look in the code :) |
| 04:43.47 | brlcad | with yours as big as it is, it's pointing a big finger at there being something serious going on like something hogging the cpu or a bug in the wallclock computation code |
| 04:44.04 | brlcad | the latter isn't the case as you mentioned that's about how long it takes |
| 04:44.32 | brlcad | which is incredible as that is very very slow for the benchmark images |
| 04:44.43 | brlcad | they should just take a few seconds per frame |
| 04:47.11 | IriX64 | err brlcad: thats the output of raytraceing while actually rendering the image to the tube quite fast considering what its doing. |
| 04:47.48 | brlcad | it should just take a few seconds to fully generate the image |
| 04:48.03 | IriX64 | its a solid model brlcad think. |
| 04:49.11 | IriX64 | i should send you a screen shot of my screen with one rendered, if i knew how i would. |
| 04:49.55 | IriX64 | be back in a moment my attention is required outside. |
| 04:52.04 | brlcad | i never said it wasn't a solid model |
| 04:52.16 | brlcad | never said that I doubt it renders incorrectly either |
| 04:52.31 | brlcad | s/incorrectly/correctly/ |
| 04:52.46 | brlcad | the only thing wrong is the performance.. that is WAY too slow |
| 04:53.24 | brlcad | unless you're running XP on a 486 or something slower |
| 04:59.27 | *** join/#brlcad IriX64_ (n=IriX64@toronto-HSE-ppp4303658.sympatico.ca) |
| 05:02.04 | CIA-9 | BRL-CAD: 03brlcad * 10brlcad/doc/html/manuals/mged/ (mug mug_camo): get rid of the old path |
| 05:03.23 | CIA-9 | BRL-CAD: 03brlcad * 10brlcad/doc/mged.tr: get rid of the old path |
| 05:05.44 | IriX64_ | 486??? |
| 05:05.55 | IriX64_ | they still make those? |
| 05:05.57 | IriX64_ | :) |
| 05:07.19 | IriX64_ | ever hear of the dos game doom? |
| 05:07.47 | IriX64_ | music and all, vmware suck my arse with your face :) |
| 05:09.07 | IriX64_ | hairy virtualizing interrupt and dma and sundry hardware the game expects. |
| 05:15.55 | CIA-9 | BRL-CAD: 03brlcad * 10brlcad/src/ (14 files in 7 dirs): get rid of the old 'cad' path references/assumptions |
| 05:16.36 | IriX64_ | simple concept really, you provide a dos environment and any dos program that expects a certain environment usually probes irq's and dma's and such if you feel the probe map it to whats really there if the program doesn't probe try to provide "generic" hardware. |
| 05:30.08 | CIA-9 | BRL-CAD: 03brlcad * 10brlcad/src/libdm/dm-ogl_win.c: removed the replaced file. dm-ogl_win.c is no more, replaced by the dm-wgl.c interface file. |
| 05:42.11 | CIA-9 | BRL-CAD: 03brlcad * 10brlcad/src/libtclcad/libtclcad.dsp: take a manual stab at an initial msvc build file for libtclcad (needed for the sketch editor) |
| 05:49.10 | CIA-9 | BRL-CAD: 03brlcad * 10brlcad/src/libsysv/Makefile.am: make vers.c correctly rebuild if a source file changes |
| 05:49.29 | CIA-9 | BRL-CAD: 03brlcad * 10brlcad/src/libtclcad/Makefile.am: add the new windows build file to the dist |
| 05:51.42 | CIA-9 | BRL-CAD: 03brlcad * 10brlcad/misc/win32-msvc/brlcad.dsw: add libtclcad to the msvc brlcad dll build workspace |
| 05:55.59 | CIA-9 | BRL-CAD: 03brlcad * 10brlcad/src/mged/attach.c: looks like bezier canvas support should now be available for both windows studio build projects. libtclcad should build sans tk sources now, try enabling it. |
| 05:57.18 | CIA-9 | BRL-CAD: 03brlcad * 10brlcad/src/mged/attach.c: remove apparently dead code, 'do_2nd_attach_prompt()' |
| 06:08.50 | CIA-9 | BRL-CAD: 03brlcad * 10brlcad/src/mged/ (dm-X.c dm-ogl.c dm-wgl.c mged_dm.h): move the common_dm() decl over to mged_dm.h |
| 06:16.16 | CIA-9 | BRL-CAD: 03brlcad * 10brlcad/src/mged/ (chgview.c cmd.c vrlink.c): enable the 'pov' command, getting rid of the peculiar undocumented TCP_FILES define. move cmd_pov over to chgview.c like the comment suggests. (note that the command guts are over in librt) |
| 06:39.08 | *** join/#brlcad DTRemenak (n=DTRemena@c-24-23-59-104.hsd1.ca.comcast.net) |
| 06:46.47 | *** join/#brlcad clock_ (i=clock@84-72-88-162.dclient.hispeed.ch) |
| 06:47.37 | CIA-9 | BRL-CAD: 03brlcad * 10brlcad/src/libfb/ (26 files): get rid of the libfb-specific _LOCAL_ macro, instead using HIDDEN like everyone else (currently still provided by machine.h) |
| 08:23.25 | *** join/#brlcad clock_ (n=clock@zux221-122-143.adsl.green.ch) |
| 13:42.51 | *** join/#brlcad digitalfredy (n=digitalf@200.71.62.161) |
| 16:37.43 | CIA-9 | BRL-CAD: 03brlcad * 10brlcad/src/tclscripts/mged/callbacks.tcl: quell warnings about mged_display not being set, make sure the variables even exist |
| 16:44.11 | CIA-9 | BRL-CAD: 03brlcad * 10brlcad/src/mged/edsol.c: |
| 16:44.11 | CIA-9 | BRL-CAD: add a lot of checks for valid pointers as part of isolating a 'P' binding crash |
| 16:44.11 | CIA-9 | BRL-CAD: bug (sf bug 1375751: P shuts down mged). the crash was the result of a bus |
| 16:44.11 | CIA-9 | BRL-CAD: error inside of Tcl_AppendResult of all places, where the second |
| 16:44.11 | CIA-9 | BRL-CAD: Tcl_AppendResult() after the one inside not_state() would cause a crash. this |
| 16:44.14 | CIA-9 | BRL-CAD: may indicate some other interp initialization problem, but the fix in place does |
| 16:44.16 | CIA-9 | BRL-CAD: seem to keep things going nicely. |
| 16:56.18 | ``Erik | hm |
| 16:58.11 | CIA-9 | BRL-CAD: 03brlcad * 10brlcad/src/mged/chgtree.c: not_state() now reports the desired state too, so no need for the extra printing |
| 16:59.06 | CIA-9 | BRL-CAD: 03brlcad * 10brlcad/src/mged/buttons.c: print out the expected/desired state so the user has a clue as to what to do to resolve the problem when not in the right editing mode. |
| 17:00.16 | CIA-9 | BRL-CAD: 03brlcad * 10brlcad/src/mged/edsol.c: not_state now reports the desired state, so no need to print a message. be consistent with the printing and the command name category (sedit). |
| 17:00.36 | *** join/#brlcad DTRemenak|RDP (n=DTRemena@c-24-23-59-104.hsd1.mn.comcast.net) |
| 17:02.03 | CIA-9 | BRL-CAD: 03brlcad * 10brlcad/NEWS: fixed mged crash on P binding when not in edit mode. this fixes sf bug 1375751 (P shuts down mged) reported by bob2. |
| 18:02.52 | CIA-9 | BRL-CAD: 03brlcad * 10brlcad/ (include/light.h src/liboptical/sh_light.c): incremental update this time.. change MAX_LIGHT_SAMPLES to SOME_LIGHT_SAMPLES |
| 18:07.20 | *** join/#brlcad IriX64 (n=IriX64@toronto-HSE-ppp4303658.sympatico.ca) |
| 18:08.15 | IriX64 | what was that about a pencil tapping your teeth? |
| 18:08.42 | IriX64 | easy,easy,money and your chicks for free, right fatso :) |
| 18:09.49 | IriX64 | the doc says it's good for you ;) |
| 18:10.59 | IriX64 | should look that formula up, make some easy money, only how do i get Canada to tap their teeth with a lead pencil? |
| 18:13.53 | IriX64 | Captains mess, anyone ;) |
| 18:14.45 | IriX64 | mater and pater are here, be back in a bit. |
| 18:23.03 | CIA-9 | BRL-CAD: 03brlcad * 10brlcad/misc/Makefile.defs: be sure to delete static and other 'regular' or noinst libraries during a make noprod |
| 18:24.10 | IriX64 | visit successfull :) |
| 18:29.01 | CIA-9 | BRL-CAD: 03brlcad * 10brlcad/ (include/light.h src/liboptical/sh_light.c): next step in the incremental update, dynamically allocate the light sample points array instead of using a fixed size. |
| 18:33.47 | IriX64 | brlcad: i still can't get this math right, 2.61 secs RTFM 56.97 secs wallclock. |
| 18:34.18 | IriX64 | havoc.g |
| 18:35.13 | IriX64 | but its consistent across runs. |
| 18:37.14 | IriX64 | lets try bldg391. |
| 18:38.39 | IriX64 | 1.25 rtfm 11.91 wallclock |
| 18:39.37 | IriX64 | lets try the deuce and a 1/2 |
| 18:51.10 | IriX64 | 5.56 rtfm 93.55 wallclock |
| 18:52.13 | IriX64 | whats your e-mail, ill send you a .jpg shot of my screen. |
| 18:54.01 | IriX64 | pastebin doesn't allow jpgs. |
| 18:54.10 | brlcad | jpg of your screen isn't useful |
| 18:54.24 | IriX64 | what do you need to help out here? |
| 18:55.14 | brlcad | I'd start by installing some antivirus and antispyware software and see what all comes up |
| 18:55.26 | IriX64 | all right. |
| 18:56.29 | brlcad | clamAV is free, not sure how good their antispyware is though |
| 18:56.45 | IriX64 | truck looks good though, nice green field its sitting on. |
| 18:57.43 | IriX64 | gold tipped exhaust pipe... nothings to good for the military. :) |
| 18:57.45 | brlcad | this looks good: http://www.spywareterminator.com/ |
| 18:58.07 | IriX64 | i'll try mcaffee first. |
| 18:59.08 | brlcad | mcafee sells a separate anti-spyware product if all you have is their antivirus |
| 18:59.28 | brlcad | virus will be good to check for .. but should be sure to check for both |
| 18:59.33 | IriX64 | think i bought the full package, ill dig it out and see. |
| 19:15.24 | *** join/#brlcad IriX64 (n=IriX64@toronto-HSE-ppp4303658.sympatico.ca) |
| 19:19.08 | IriX64 | look brlcad: it takes time to draw an image on the screen, theres no way your 10% figure can apply. |
| 19:22.58 | IriX64 | ill either dcc send you a screenshot with the figures on it or ill e-mail it to you. |
| 19:23.09 | IriX64 | and the picture on it. |
| 19:24.23 | IriX64 | e-mail address? |
| 19:24.55 | IriX64 | everythings clearly visible. |
| 19:25.23 | brlcad | if it takes 20x the ray-trace time, it would imply a serious bug |
| 19:25.40 | brlcad | and I've run ray-traces on windows and don't see that sort of different |
| 19:26.17 | IriX64 | all right how long does *yours take to draw the m35 on your screen, im talking about the solid model picture, not the wire frame. |
| 19:26.46 | IriX64 | err pardon? windows? |
| 19:26.47 | brlcad | here's what moss looks like for me: 759710.95 rays/sec (RTFM) 748857.07 rays/sec (wallclock) |
| 19:27.11 | IriX64 | it renders that fast? |
| 19:27.29 | IriX64 | im not talking make benchmark here. |
| 19:27.47 | IriX64 | thats the shot summary im getting my numbers from. |
| 19:28.11 | brlcad | this has nothing to do with the model or benchmark |
| 19:28.25 | brlcad | it's just relative performance numbers |
| 19:28.32 | brlcad | doesn't matter what model either |
| 19:28.56 | IriX64 | screw its accuarate i used a stop watch. off by maybe a second or two but its accyrate. |
| 19:29.06 | IriX64 | accurate too. |
| 19:29.24 | brlcad | sure, it's accurate |
| 19:29.27 | IriX64 | the math, she's good :) |
| 19:29.39 | brlcad | it's not once been a question to ME whether the values were being computed correctly |
| 19:29.45 | brlcad | this is pretty stable code |
| 19:30.09 | IriX64 | *shrug* my code becomes stable with age too :) |
| 19:30.25 | brlcad | which is exactly why it points at something wrong with your system, why must I keep repeating this?? :) |
| 19:30.38 | brlcad | i personally don't really care |
| 19:30.42 | brlcad | it's your system |
| 19:30.49 | brlcad | but it does indicate some serious problem |
| 19:31.03 | IriX64 | all right send me the pix of moss (mario.dulisse2@sympatico.ca) |
| 19:31.04 | brlcad | not a problem with brl-cad or how the ray-trace runs |
| 19:31.14 | brlcad | or what the results look like |
| 19:31.19 | brlcad | that is ALL fine |
| 19:31.26 | brlcad | what is wrong is how slow/fast it's running for you |
| 19:31.51 | brlcad | you're not going to SEE anything related to this problem with a pix |
| 19:31.59 | brlcad | other than it rendering slow |
| 19:32.13 | brlcad | is this not clear?? |
| 19:32.18 | IriX64 | you expect the pix to just appear? |
| 19:32.36 | IriX64 | drawing an image on the tube can not be that fast. |
| 19:33.10 | brlcad | some images are pretty much immediate, others not more than a few seconds |
| 19:33.19 | brlcad | you're looking at several minutes on your system |
| 19:34.17 | brlcad | you mentioned m35 rendering - how long does it take m35 to raytrace into a 512x512 window? |
| 19:34.39 | IriX64 | yes anyway im happy thanks, ill get that mcaffee dug out. lost everything in a crash 3 months ago and am slow to getting around to restoring some things. |
| 19:35.18 | brlcad | *shrug* .. if it is systemic, it means something else basically has control of your system :) |
| 19:36.22 | IriX64 | 512x512 just a sec |
| 19:36.47 | brlcad | you mentioned cygwin, that could be causing a big performance penalty of some sort -- haven't looked at the numbers there in a while |
| 19:37.01 | IriX64 | 65.17 wallclock and 3.84 rtfm. |
| 19:37.50 | brlcad | see -- that means it only spent 4 seconds on the cpu .. but for "some" reason more than a minute elapsed from the time the ray-trace began until it completed |
| 19:38.21 | brlcad | there wasn't more than 3.84 seconds worth of work, but something slowed it down |
| 19:38.29 | IriX64 | of course because the pixels have to be lit or turned off sheesh. |
| 19:38.39 | brlcad | that could be a virus, spyware, cygwin.. something else |
| 19:39.03 | brlcad | i'd be surprised if cygwin was _that_ bad at I/O |
| 19:39.29 | IriX64 | you using a hardware x? |
| 19:40.49 | IriX64 | rember there two layers of graphics here windows and xserver althought the screens are seamless theres still graphic overhead to contend with. |
| 19:43.08 | IriX64 | need a smoke be back shortly. |
| 19:43.11 | brlcad | there's not any configuration setup that should have a discrepancy as large as yours is :) |
| 19:46.23 | ``Erik | *yawn* |
| 19:47.43 | ``Erik | heh, sean, I did an update and now libfb doesn't want to compile, it's seeing two do_event()s defined, and HIDDEN is reducing to /***/ instead of static o.O what'd you do tot he thing? |
| 19:48.26 | ``Erik | <-- hacked his if_X.c if_wgl.c and if_glx.c to change the func name to like do_X_event() or do_wgl_event depending on file.. think that would be worth a commit? |
| 19:48.46 | brlcad | ``Erik: yeah, I know .. i have a fix for that here |
| 19:49.38 | brlcad | there's a few of them |
| 19:56.00 | *** join/#brlcad dtidrow_work (n=dtidrow@host169.objectsciences.com) |
| 20:02.35 | IriX64 | brlcad: you are a very patient man, thanks for the input. |
| 20:14.55 | *** join/#brlcad clock_ (i=clock@84-72-93-187.dclient.hispeed.ch) |
| 20:47.52 | *** join/#brlcad mg` (n=mathieu@ALille-151-1-60-91.w83-198.abo.wanadoo.fr) |
| 20:54.37 | *** join/#brlcad _mathieu (n=mathieu@ALille-151-1-40-42.w83-198.abo.wanadoo.fr) |
| 21:17.58 | *** join/#brlcad mathieu_ (n=mathieu@ALille-151-1-2-169.w82-127.abo.wanadoo.fr) |
| 21:20.12 | *** join/#brlcad mathieu__ (n=mathieu@ALille-151-1-35-154.w83-198.abo.wanadoo.fr) |
| 21:33.52 | *** join/#brlcad _mathieu (n=mathieu@ALille-151-1-70-209.w86-207.abo.wanadoo.fr) |
| 21:46.07 | *** join/#brlcad mathieu_ (n=mathieu@ALille-151-1-23-29.w82-127.abo.wanadoo.fr) |
| 21:50.19 | *** join/#brlcad digitalfredy (n=digitalf@200.71.62.161) |
| 21:53.01 | *** join/#brlcad mathieu__ (n=mathieu@ALille-151-1-43-79.w83-192.abo.wanadoo.fr) |
| 21:53.38 | *** part/#brlcad digitalfredy (n=digitalf@200.71.62.161) |
| 22:07.19 | CIA-9 | BRL-CAD: 03brlcad * 10brlcad/src/liboptical/sh_light.c: final mod to allow for arbitrary counts of light point samples. the point sample array is allocated in batches of SOME_LIGHT_SAMPLES. |
| 22:16.46 | CIA-9 | BRL-CAD: 03brlcad * 10brlcad/src/liboptical/sh_stack.c: avoid debug mode namespace conflicts with libfb's stack interface (where HIDDEN becomes /**/) |
| 22:16.56 | CIA-9 | BRL-CAD: 03brlcad * 10brlcad/src/liboptical/sh_null.c: avoid debug mode namespace conflicts with libfb's null interface (where HIDDEN becomes /**/) |
| 22:17.48 | ``Erik | sean, you doing the 'week off after siggraph' thing? |
| 22:18.44 | dtidrow_work | c'mon, SIGGRAPH _is_ a week off ;-) |
| 22:18.59 | dtidrow_work | 'cept for the parties... |
| 22:19.03 | ``Erik | heh |
| 22:19.09 | ``Erik | yeah, last year, I hurt my ankle pretty bad |
| 22:19.22 | ``Erik | falling down, uh, stairs, at a nightclub, for an afterparty |
| 22:19.22 | ``Erik | heh |
| 22:19.28 | ``Erik | <-- retarded |
| 22:19.30 | dtidrow_work | which one? |
| 22:19.51 | ``Erik | hrm? which club? or which party? |
| 22:19.58 | ``Erik | it was at 'the mayan' in downtown la |
| 22:19.59 | dtidrow_work | which party |
| 22:20.08 | ``Erik | I don't remember who was throwing it |
| 22:20.19 | ``Erik | some flyers were handed out |
| 22:20.22 | ``Erik | like the acm one or something |
| 22:20.25 | dtidrow_work | that's where the chapters party was, right? |
| 22:20.32 | ``Erik | yeah, I think that was it |
| 22:20.35 | ``Erik | that sounds familiar |
| 22:20.37 | dtidrow_work | k |
| 22:20.43 | dtidrow_work | was there too :-) |
| 22:20.51 | ``Erik | with the stirppers dancing on the boxes? |
| 22:20.54 | ``Erik | 'cept they didn't strip |
| 22:20.55 | ``Erik | heh |
| 22:21.02 | dtidrow_work | yeah |
| 22:21.07 | ``Erik | and the big circular thing they were playing crap on |
| 22:21.15 | ``Erik | <-- stayed there pretty late |
| 22:21.17 | dtidrow_work | we nicknamed them the 'anime dancers' :-) |
| 22:21.27 | ``Erik | y'know the ampitheater seating on the upper level? |
| 22:21.31 | dtidrow_work | yep |
| 22:21.41 | ``Erik | I was walking down those, hit a corner of a stemp with my heal trying to get into the seating |
| 22:21.47 | dtidrow_work | ouch |
| 22:21.54 | ``Erik | black on black, smoke, dark, vodka... bad mojo |
| 22:22.07 | dtidrow_work | yep |
| 22:22.17 | ``Erik | came down on my ankle and butt, was hobbling out, coulnd't move it the next morning |
| 22:22.35 | ``Erik | when I got a 5am call to fix a diskless cluster |
| 22:22.37 | dtidrow_work | was awfully expensive this year - $7 for a Sam Adams |
| 22:22.46 | ``Erik | ew |
| 22:22.47 | dtidrow_work | that's one bottle |
| 22:22.59 | ``Erik | hah, go down the street and buy a 6 for less, hah |
| 22:23.13 | dtidrow_work | I can get a six-pack of them for $7.50 |
| 22:23.41 | ``Erik | huh, I've seen sam cheaper |
| 22:23.43 | dtidrow_work | was sorely tempted to go on the brewery tour, as the brewery was only about 5-6 miles away from my hotel |
| 22:24.02 | ``Erik | heh |
| 22:24.08 | ``Erik | this year? |
| 22:24.12 | dtidrow_work | yep |
| 22:24.18 | dtidrow_work | Boston |
| 22:24.30 | ``Erik | I wanted to go, but there was a clamp put down on all travel that I couldn't squirm out from under |
| 22:24.36 | dtidrow_work | ick |
| 22:24.36 | ``Erik | so I had to call in, cancel my hotel reservation, etc |
| 22:24.42 | ``Erik | sucked |
| 22:24.50 | dtidrow_work | indeed |
| 22:25.06 | ``Erik | now they're trying to send me to utah for some realtime raytracing convention |
| 22:25.44 | dtidrow_work | there were several papers about that this year, or maybe courses |
| 22:26.17 | ``Erik | there have been for a while |
| 22:26.20 | ``Erik | and all the same players, heh |
| 22:26.27 | ``Erik | slusallek, etc |
| 22:29.20 | dtidrow_work | lol |
| 22:35.18 | dtidrow_work | guess he's totally distracted |
| 22:36.24 | ``Erik | he must have a sexy piece of code keeping him distracted |
| 22:37.05 | dtidrow_work | heh |
| 22:47.52 | CIA-9 | BRL-CAD: 03brlcad * 10brlcad/src/libfb/ (if_X.c if_ogl.c if_wgl.c): avoid debug mode namespace conflicts when multiple interfaces are compiled and HIDDEN becomes /**/) |
| 22:49.09 | brlcad | mm.. sexy code indeed |
| 22:49.52 | brlcad | ``Erik: not the entire week |
| 22:50.10 | brlcad | i'm on a coding roll on many fronts |
| 22:50.22 | ``Erik | ah, I was hoping in your aid in something... I can wait if you'd rather not be arsed with my issues :) |
| 22:50.30 | brlcad | it'll be all over once I go in, so I'm going with the flow |
| 22:51.37 | brlcad | feel free to ask, if it's too complicated I'll defer, but not likely |
| 22:51.37 | ``Erik | (mem leak in my shot routine, I not grokin' something) |
| 22:51.59 | brlcad | set bu_debug to 2 |
| 22:52.39 | brlcad | basic bounds checks, won't catch the leak of course, but it's a start |
| 22:54.28 | ``Erik | that's a lot of info |
| 22:55.48 | ``Erik | nothing about allocations and deallocations, though |
| 23:11.28 | brlcad | hmm.. shouldn't be "a lot" .. note that one flag is for rt_debug, another for bn, and another for bu |
| 23:12.20 | brlcad | i mean, it'll be a lot of messages .. the ones that are provided during bu_malloc/bu_free/etc |
| 23:32.35 | IriX64 | try my_free(char *ptr) {free(ptr);ptr=NULL;} |
| 23:34.40 | IriX64 | or my_free(char *ptr){if(ptr){free(ptr);ptr=NULL}} |
| 23:38.11 | IriX64 | rtshot or show shot ``Erik? |
| 23:41.56 | IriX64 | in rtshot you have two allocs but no free's. kosher? |
| 23:47.36 | IriX64 | sigh my memory leaks constantly, silicon might help ;) |
| 23:49.28 | IriX64 | err my_free(char* ptr){if(ptr){free(ptr);ptr=NULL;return(ptr)}}return; |
| 23:49.44 | IriX64 | been awhile :) |
| 23:50.13 | IriX64 | err my_free(char* ptr){if(ptr){free(ptr);ptr=NULL;return(ptr)}}return(ptr); |
| 23:51.44 | IriX64 | make distclean |
| 23:52.03 | IriX64 | should have auto switching windows... sorry. |