| 01:46.58 | *** join/#brlcad starseeker (n=user@ip70-161-120-182.hr.hr.cox.net) | |
| 02:05.13 | starseeker | anybody here? |
| 02:08.41 | brlcad | sometimes :) |
| 02:08.47 | brlcad | howdy starseeker .. been a while |
| 02:09.02 | starseeker | Yes indeed. Just got internet back after many months |
| 02:09.09 | starseeker | good to be back! |
| 02:09.36 | starseeker | I see brl-cad has made some strides. Anybody working on a 7.8.0 ebuild yet, to your knowledge? |
| 02:09.51 | brlcad | not to my knowledge! |
| 02:10.05 | starseeker | Hmm. A situation requiring attention :-) |
| 02:10.13 | brlcad | there have been a couple new gentooers interested in the ebuild, but nobody jumping in hard |
| 02:10.41 | brlcad | there was still one remaining issue iirc, but I hadn't been back to the ebuild to see what it was to get a fix in for it |
| 02:10.54 | starseeker | letsee... I was just looking at that... |
| 02:10.56 | brlcad | btw 7.8.2 is posted ;) |
| 02:11.02 | starseeker | sweet! |
| 02:11.20 | brlcad | brb |
| 02:14.19 | starseeker | Well, I've got the gentoo-sci overlay here, which I think has it... yes. Let's see how 7.8.2 does. |
| 02:21.30 | starseeker | OK, here we go... |
| 02:22.37 | starseeker | Ah, fudge. Ebuild wants a patch. |
| 02:22.55 | starseeker | Would it be better for testing purposes to try it with no patches? |
| 02:33.06 | starseeker | OK... it didn't like it when I tried to eautoconf, but I"m trying it with just removing all that and going with the default ./configure... |
| 02:35.22 | starseeker | They disabled something subesequently not found on the system - re-enabling it... |
| 02:35.31 | starseeker | URT, I think... |
| 02:37.13 | starseeker | Grr - itcl must need a patch. Darn it, why can't they just use the internal stuff... |
| 02:39.54 | starseeker | Well, I'm almost getting it to finish ./configure so far :-) |
| 02:40.49 | brlcad | for ebuild it should be using either the --enable-everything or --disable-everything option so that it consistently builds or doesn't build the external dependencies itself |
| 02:41.35 | starseeker | Hmm. Well, they seem to be pretty stubborn about wanting the disable-everything route, but that never seems to work properly. |
| 02:41.44 | starseeker | OK, it's at least building now. |
| 02:41.47 | brlcad | probably --disable-everything .. that will turn off brl-cad's compilation of almost everything in src/other |
| 02:42.14 | brlcad | shouldn't be any more violations any more |
| 02:42.22 | starseeker | OK, cool :-) |
| 02:42.33 | brlcad | the biggest issue that I can think of is that it still requires our tcl/tk |
| 02:42.37 | starseeker | I think it's about a 20 minute build (or it was) |
| 02:42.49 | brlcad | more specifically, it needs our tk |
| 02:43.07 | starseeker | actually, tcl/tk was ok, at least so far - it was itcl it didn't seem to like |
| 02:43.13 | brlcad | though I haven't tried piecemealing it with some on and some off |
| 02:43.29 | starseeker | 'course, I haven't actually gotten to the tk compile yet... |
| 02:44.17 | brlcad | no? what fails? |
| 02:44.24 | brlcad | everything in brl-cad should compile without a hitch |
| 02:44.49 | brlcad | i.e. if you ./configure --enable-everything .. that 'should' always work .. if it doesn't, that's a serious build bug |
| 02:44.50 | starseeker | I think it will. The configure was a little odd but I'm not convinced that's brlcads fault |
| 02:45.12 | starseeker | OK. I was doing it wrong - I tried to use internal stuff only when I had to |
| 02:45.26 | brlcad | you can actually --enable-everything and then --disable specific packages too .. that might be easier for testing |
| 02:46.19 | starseeker | If enable-everything works we should get an ebuild out there that does that, and follow up with the more finicky one when we can make it work. |
| 02:46.53 | brlcad | we're really really close to being able to disable everything, it's the tcl/tk itcl/itk/iwidgets stuff that causes serious problems still due to the way they search for script 'packages' at run-time |
| 02:47.35 | brlcad | that can come to closure and get fixed pretty quickly, but since you weren't around and others weren't nearly as motivated, the priority slowly decreases ;) |
| 02:47.41 | brlcad | priority follows interest ;) |
| 02:47.48 | brlcad | and involvement |
| 02:47.55 | starseeker | I thought there were some customizations that were made just for brl-cad? |
| 02:47.57 | starseeker | Heh |
| 02:48.10 | starseeker | Yes, I see the ebuild comments are rather stale |
| 02:48.33 | brlcad | there were some customizations make to tk and repairs made throughout their build for minor issues like 64bit bugs and type warnings |
| 02:48.46 | starseeker | I was hoping when that guy came in making fun of my 1st ebuild he would get it completely working. Maybe it's time to repeat that strategy :-) |
| 02:48.52 | brlcad | but I removed those shortly after the last time I was testing with either you or one of the debian guys |
| 02:49.08 | brlcad | our tk mods are now in a different library (one of ours) instead of in tk |
| 02:49.15 | starseeker | The upstream tk maintainers weren't interested? |
| 02:49.17 | starseeker | cool |
| 02:49.41 | brlcad | but.. that code still uses tk internal headers and has to get fixed still.. so until it's fixed it still requires a copy of tk sources from somewhere |
| 02:49.55 | starseeker | Seldom a problem on gentoo ;-) |
| 02:50.11 | brlcad | true |
| 02:50.13 | starseeker | Oh, is -march=athlon-xp going to get me in trouble? |
| 02:50.49 | brlcad | but it means that you can't just assume because tk 8.4 is installed that it will compile, it won't.. because it's using internal tk headers as if it was tk itself.. which tk doesn't install |
| 02:50.56 | brlcad | no, that should be just fine |
| 02:51.14 | brlcad | the veritable test of functionality after everything is installed is to run 'benchmark' |
| 02:51.35 | starseeker | Is that a brlcad binary? |
| 02:51.47 | starseeker | (it's been a while :/) |
| 02:51.50 | brlcad | yes |
| 02:52.03 | brlcad | technically not a binary, but it is a core brl-cad application |
| 02:52.09 | starseeker | OK, if I get away with this compile I'll give it a go. |
| 02:52.35 | brlcad | that ends up exercising all of the core libraries testing performance and verifying that the ray-trace library is computing results correctly within tolerance |
| 02:52.55 | brlcad | it will tell you a metric of how your machine compares performance-wise |
| 02:53.49 | starseeker | OK. |
| 02:54.07 | brlcad | the BRL-CAD Benchmark has also been around for a couple decades so you can use the number it gives you to see how you compare to systems like a VAX 11/780 and a Cray 2, etc |
| 02:54.14 | starseeker | Cool! |
| 02:54.45 | brlcad | or a 512 process SGI Origin 2000 or a Mac G5, etc.. any system |
| 02:55.12 | starseeker | Might be depressing though - when we benchmarked our compaq pcs agains our years old dec alphas, our new (expensive) pcs got killed on floating point |
| 02:55.47 | starseeker | We should have scrounged up a buch of old alphas - more bang for the buck ;-) |
| 02:56.06 | brlcad | it's an excellent direct comparison of "real world" computation power for cpu-intensive applications since it exercises how well your cpu performs, cache levels, access to memory, coherency, compiler optimization options, etc |
| 02:56.26 | starseeker | Nice. Who's the current leader in the AMD/Intel comparison? |
| 02:56.53 | brlcad | e.g. it would be a great way to quantifiably compare how much boost gentoo gives to a system by simply compiling with the same compiler and same compiler options on a box with gentoo and then on that same box with a different os |
| 02:57.12 | starseeker | Hmm. That would be interesting. |
| 02:57.27 | brlcad | AMD has been beating in the numerics realm for many years now for general performance computing |
| 02:57.28 | starseeker | Has anybody tried it inside a virtualization environment (e.g. Xen?) |
| 02:58.41 | starseeker | That might be a good heavy duty test for them |
| 02:58.58 | starseeker | Although I guess the CPUs with the proper support for that aren't generally available yet? |
| 02:59.05 | brlcad | Intel's been good in some niche computing areas, e.g. taking advantage of perfectly aligned caches with extensive coherencey, but when it comes to real world application performance, it pays more penalties and AMD has come out on top for most chips for over 5 years now |
| 02:59.21 | starseeker | Wow! |
| 02:59.24 | brlcad | inside a virtualization environment? |
| 02:59.48 | brlcad | it's been run inside Mingw on windows and on virtual pc |
| 03:00.10 | starseeker | Apparently they are working on creating processors that will allow things like running Windows and Linux side by side at a rather low level (for performance gains) |
| 03:00.13 | brlcad | shows pretty well the sorts of penalties you pay |
| 03:00.25 | starseeker | Yes, I'm sure mingw is horrible |
| 03:00.30 | brlcad | :) |
| 03:00.44 | starseeker | Maxima has used mingw, and I think Axiom did too |
| 03:00.51 | starseeker | When it's the only game in town... |
| 03:01.19 | starseeker | Ah - here's Xen: http://www.cl.cam.ac.uk/Research/SRG/netos/xen/ |
| 03:02.21 | brlcad | ahh |
| 03:02.29 | starseeker | They claim "close to native" performance :-). Sounds like it's begging for benchmark to take a crack at it ;-) |
| 03:02.34 | brlcad | it'd be interested to see just what that penalty is |
| 03:02.54 | brlcad | that's what I've always loved about the BRL-CAD Benchmark |
| 03:03.12 | starseeker | I'm hoping to wait on my next PC until I can have Xen allow things like running WIndows and Linux at the same time, seamlessly |
| 03:03.52 | brlcad | it's a real world metric better than the subjective ones you usually see like Photoshop and Maya, and not tied to hardware to specifically beyond the processor like the game FPS benchmarks |
| 03:04.05 | starseeker | Right. |
| 03:04.07 | brlcad | nor is it insanely operation specific like the SPEC ratings |
| 03:04.23 | brlcad | where you simply do a billion floating point divides etc |
| 03:04.56 | starseeker | I think some of those tests were intended for very specific numerical simulation optimization, and got perverted into marketing tools. |
| 03:05.33 | starseeker | OK, compiled... Will it install... |
| 03:06.28 | starseeker | I saw a warning about relinking libfb.a or something similar - is that expected? |
| 03:06.39 | *** join/#brlcad DTRemenak (n=DTRemena@c-24-23-59-104.hsd1.ca.comcast.net) | |
| 03:08.35 | starseeker | One problem I might have is that my nvidia drivers aren't working with the new Xorg release, so I"m on the basic nv driver |
| 03:09.06 | starseeker | Appears to have installed!!! |
| 03:09.58 | starseeker | Let's see what benchmark does... |
| 03:10.38 | starseeker | It estimates a little under 10 minutes |
| 03:11.22 | brlcad | they do get perverted into marketing tools |
| 03:12.07 | brlcad | and if you talk to some of the chip makers.. some of the chips (in particular intel ones) are actually specifically designed to perform very well on the SPEC benchmarks even though their real-world performance is nowhere near as ideal |
| 03:12.27 | starseeker | ouch. That must smart to an engineer |
| 03:12.35 | brlcad | benchmark default timeframe is 10 minutes, it can be changed to pretty much any length of time |
| 03:13.08 | starseeker | lets see - where does brlcad put its examples? |
| 03:13.18 | brlcad | e.g. "TIMEFRAME=10 benchmark" will run it really fast to give a real quick estimate |
| 03:13.34 | brlcad | did it error? |
| 03:13.41 | starseeker | not so far |
| 03:14.05 | brlcad | each one of those frames is actually a ray-trace rendering of some geometry |
| 03:14.36 | brlcad | simple models, but the stress specific types of access and different portions of the BRL-CAD libraries |
| 03:14.48 | brlcad | 6 tests in all today |
| 03:15.18 | starseeker | Ah, OK. Well, it is giving answers are RIGHT and 0 off by 1, 0 off by many |
| 03:15.29 | brlcad | good |
| 03:15.29 | starseeker | Oh, it sends them in to the site? |
| 03:15.33 | brlcad | RIGHT answers are good |
| 03:15.36 | starseeker | :-) |
| 03:15.46 | brlcad | no, it doesn't .. would be a sweet feature I'd like to add |
| 03:16.09 | brlcad | but i'm a bit uneasy myself about how to prompt the user as to whether they want to submit results to a database |
| 03:17.02 | brlcad | plus I need more details to really make sense of the number (cpu type, number of cpus, amount of memory, l1/l2/l3 cache levels, compiler, compiler options, type of memory, version of brl-cad) |
| 03:17.05 | starseeker | Maybe something like: "Tests completed successfully. Would you like to submit these results to the central brlcad performance benchmarking database? (y|n) |
| 03:17.52 | brlcad | something like that could work |
| 03:18.03 | starseeker | Most computers can tell you cpu type and # of cpus I think, and probably amount of memory. Not sure about the others - does brlcad itself record the options used to build it? |
| 03:18.23 | starseeker | type of memory might be tough. I'd love to know how to tell what kind of memory I've got. |
| 03:18.47 | brlcad | i can programmatically get most of the details, and it does know how it was built.. but the tool that describes all that to the benchmark suite would need to get written |
| 03:19.10 | starseeker | Ugh. |
| 03:19.34 | starseeker | OK, got the results : These numbers seem to indicate that this machine is approximately 1347 times |
| 03:19.34 | starseeker | faster than the reference machine being used for comparison, a VAX 11/780 |
| 03:19.34 | starseeker | running 4.3 BSD named VGR. These results are in fact approximately 3.13 |
| 03:19.34 | starseeker | orders of magnitude faster than the reference. |
| 03:20.04 | brlcad | not too shabby for a single cpu result |
| 03:20.25 | brlcad | seems slightly low if that's a new chip, did you use --enable-optimized? |
| 03:20.36 | starseeker | No. It's an old chip though. |
| 03:20.39 | starseeker | let's see... |
| 03:21.05 | brlcad | ahh, without --enable-optimized, the numbers are going to be considerably lower |
| 03:21.19 | starseeker | Fudge - how do I check my cpu type |
| 03:21.32 | brlcad | compiler difference between -O0 and -O3 with additional optimizations is going to be about 2X performance usually |
| 03:21.41 | starseeker | I should say I didn't turn it on - I need to check the ebuild |
| 03:21.42 | brlcad | cat /proc/cpuinfo |
| 03:21.57 | starseeker | <PROTECTED> |
| 03:22.09 | starseeker | cache size : 256 KB |
| 03:22.22 | starseeker | cpu MHz : 1533.236 |
| 03:23.18 | starseeker | Opps - it's in the ebuild, but I don't think I used that flag. OK, one more build... |
| 03:23.24 | starseeker | should I bother sending in this result? |
| 03:23.34 | brlcad | nah |
| 03:23.58 | brlcad | make sure it's --enable-optimized and --disable-debug for the best results and maybe even add your march flag |
| 03:24.16 | brlcad | (disable-debug isn't that important, but might give 1-2%) |
| 03:24.28 | starseeker | OK - the march flag was in there, I saw it during the build |
| 03:25.49 | starseeker | Is --enable-everything compatible with the above two options? |
| 03:25.50 | brlcad | that VGR number (1347 in your case) is the bread and butter |
| 03:25.56 | brlcad | yes |
| 03:26.17 | brlcad | enable-everything only affects the --enable-*-build options |
| 03:26.24 | starseeker | All rightie, let's see if this will build |
| 03:26.29 | brlcad | so has nothing to do with optimized or debug |
| 03:27.13 | starseeker | does an athlon xp 1800 still count as a new chip? |
| 03:27.24 | brlcad | the VGR number is a linear metric, meaning that a machine with a VGR of 2000 is twice as fast as one with a VGR of 1000 |
| 03:27.42 | brlcad | 1800 is from 5 years ago, no? |
| 03:27.48 | brlcad | maybe 6 |
| 03:27.51 | starseeker | I think - I don't remember now |
| 03:28.17 | brlcad | doesn't matter, i've been slowly attempting to build a database of performance numbers |
| 03:28.48 | brlcad | hoping to get a website wrapped around it all at some point so people can see just how systems perform under various configurations |
| 03:28.49 | starseeker | Cool. I'll have a somewhat better one for you in half an hour or so ;-) |
| 03:29.27 | brlcad | so you know it.. when you run benchmark, it's dumping out a lot of files into your current directory ... :-) |
| 03:29.50 | starseeker | woo-doggy |
| 03:30.09 | brlcad | easy enough to rm -f *.pix *.log summary to get rid of them all |
| 03:30.30 | brlcad | assuming you don't have other pix and log files of importance |
| 03:30.47 | starseeker | not any more ;-) |
| 03:31.05 | starseeker | I don't usually use log files much |
| 03:31.21 | starseeker | bad habit though - I really should keep a closer eye on things |
| 03:31.50 | brlcad | meh, there's only so many hours in the day to keep an eye on things ;) |
| 03:32.10 | starseeker | exactly. Maybe I should hire a sysadmin :) |
| 03:32.15 | brlcad | so you said you were offline? off to school? in jail? :) |
| 03:32.43 | starseeker | Nah (though the office does feel like the latter sometimes) - I turned off the internet for a while to conserve on both time and $$ |
| 03:33.01 | brlcad | gotya |
| 03:33.21 | starseeker | So I had the bright idea of re-installing my system to get all the latest goodies |
| 03:33.28 | starseeker | and ran smack into the expat upgrade |
| 03:33.40 | brlcad | though heck, I probably would have paid for your internet if it meant getting more brl-cad work out of you ;-) |
| 03:34.21 | starseeker | Heh :-). Didn't think of that. The real problem was my girlfriend was 5 hours away up in Delaware and most of my weekends were spent driving up there. |
| 03:34.37 | brlcad | ahh, that's just up the road |
| 03:34.37 | starseeker | Even brl-cad doesn't compete with girlfriend ;-) |
| 03:35.10 | starseeker | Now she's in Pittsburgh, which is 10 hours. So now it's down to once a month, due to travel time and costs |
| 03:35.19 | brlcad | you probably drove within 5 minutes of my house if you took the I95 corridor |
| 03:35.39 | starseeker | I've only done that once or twice - usually I come up 13 |
| 03:35.50 | starseeker | Bay bridge costs, but it's a nice drive |
| 03:36.14 | starseeker | You in Delaware? |
| 03:36.21 | brlcad | it is a nice drive.. |
| 03:36.24 | brlcad | no no.. |
| 03:36.31 | brlcad | god that'd drive me nut |
| 03:36.36 | brlcad | nuts |
| 03:36.43 | starseeker | Hehe. No sales tax was nice. |
| 03:36.53 | brlcad | yeah.. but .. it's .. deleware ;) |
| 03:37.10 | starseeker | Well, at least it has the virtue of not being NJ :-) |
| 03:37.18 | brlcad | there's nothing there except a couple beaches and tax free shopping |
| 03:37.27 | brlcad | that's true |
| 03:37.31 | starseeker | the only state I am aware of which collects money from you to let you out is NJ ;-) |
| 03:37.41 | brlcad | hehe |
| 03:38.08 | starseeker | Well, they do have some solar research at Delaware, but thanks to the current administration the $$ kinda dried up |
| 03:38.33 | starseeker | Cool. We went down to MD for dinner once in a while |
| 03:39.00 | starseeker | Got my only speeding ticket to date in MD |
| 03:39.06 | brlcad | heh |
| 03:39.18 | starseeker | Never drive fast after midnight on Superbowl sunday - the cops are all bored |
| 03:40.33 | brlcad | 95 is heavily patrolled most of the time through MD, have to know their camping spots but even then it's still a big gamble |
| 03:40.59 | brlcad | they make a lot of their funding on it |
| 03:41.22 | starseeker | Yep. If we suddenly all slowed to legal speeds I think there would be a financial crisis in law enforcement |
| 03:41.23 | brlcad | with a particular affinity for out-of-state cars ;) |
| 03:41.27 | starseeker | heh |
| 03:41.45 | starseeker | That night I think I was the ONLY car. |
| 03:42.40 | starseeker | I think the most fun I had doing that drive was when NASCAR was getting out in Dover and I was going the other way - there's something immensely satisfying about doing 60 down the road watching a 17 mile backup on the other side :-) |
| 03:43.15 | brlcad | the one nice thing is that since 95 is so heavily traveled and it feeds through baltimore/washington that the average speeds are conveniently high |
| 03:43.27 | starseeker | True. |
| 03:43.38 | brlcad | but it also means the cops can pretty much pull over anyone they want depending on how much quota they have to fill that month .. |
| 03:44.07 | starseeker | I think I"ve seen as many as 4 cars stationed in once spot on 95, come to think of it. |
| 03:44.10 | starseeker | and it was in MD |
| 03:45.32 | brlcad | coworker and I that used to travel 50+ miles a day at usually 80-100 mph most of the way and we used to joke about how cars that got "selected" was like them simply choosing a sacrificial lamb |
| 03:46.11 | brlcad | a form of random taxation for the 'privilege' to drive fast if you will |
| 03:46.22 | starseeker | Yep. |
| 03:46.50 | starseeker | I think if they would raise the driving license age by another 5 years or so they could up the speeds another 10 miles. |
| 03:47.36 | starseeker | 50+ miles a day is a mean commute |
| 03:47.42 | brlcad | they could already do that pretty safely, half of the neighboring states already did without a problem |
| 03:48.01 | starseeker | Yep, then it's the $$, pure and simple |
| 03:48.11 | brlcad | pretty much |
| 03:48.41 | starseeker | How has BRLCAD been doing now that it's open source - have there been real, substantial contributions to the code base yet? |
| 03:48.48 | brlcad | and a lot of conservatives wanting to keep it how it is |
| 03:48.57 | starseeker | that figures |
| 03:50.23 | brlcad | there have been some substantial contributions, more so in the last couple months has been growing involvement from a handful of guys learning what's there and making mods |
| 03:51.09 | brlcad | nobody up to speed of what i'd call a core dev yet, but the contributions have been significant |
| 03:51.44 | brlcad | one guy working on converting the major documentation into docbook (long desired task) and he's made great progress pretty much doing exactly what I would have done had I done it myself |
| 03:52.04 | starseeker | That's handy :-) |
| 03:52.11 | brlcad | another guy worked on mged fixing a handful of issues and implementing full vi-mode command line editing capabilities |
| 03:52.46 | brlcad | another windows dev went hog wild making litterally hundred of fixes throughout shortly after it was released for windows |
| 03:53.00 | starseeker | Heh - I see May 23 was a banner day for downloads |
| 03:53.06 | brlcad | that was just astounding, though I haven't been able to get him onto irc yet to get him integrating better |
| 03:53.24 | starseeker | Windows specific fixes, or general? |
| 03:53.31 | brlcad | both |
| 03:53.35 | starseeker | Wow |
| 03:53.39 | brlcad | more general then specific actually |
| 03:53.54 | brlcad | though he also fixed a lot of windows build system issues too |
| 03:54.21 | starseeker | A good windows release is always a major undertaking. Which installer did you opt for? |
| 03:54.58 | brlcad | it was.. the windows release held up our normal release schedule for several months |
| 03:56.05 | brlcad | my time was completely taxed trying to integrate the ton of changes that had been made for the windows port over a couple months, then took a couple more of testing and fixing and validating, etc and I'm still trying to catch up and get back to regular monthly releases now |
| 03:56.29 | brlcad | i forget the exact installer, I think it's an installshield right now |
| 03:56.43 | starseeker | Really. Wow. I thought that was commercial only |
| 03:56.53 | brlcad | though I'll likely see if I can someone playing with the windows stuff to look at nsis |
| 03:57.07 | starseeker | Yep, I was going to suggest that :-) |
| 03:57.20 | starseeker | If for any reason that won't work, InnoSetup is the other major one. |
| 03:57.38 | brlcad | i think nsis is actually probably better regardless.. :) |
| 03:57.41 | starseeker | I think NSIS is the more sophisticated of the two though |
| 03:57.45 | starseeker | er, yeah :-) |
| 03:58.19 | starseeker | Axiom used NSIS, and I'm sure it will again when someone gets gutsy enough to try it again. |
| 03:58.31 | brlcad | installshield isn't available to anyone but bob (the current 'primary' windows dev) |
| 03:58.35 | starseeker | Ah. |
| 03:59.21 | brlcad | i'm not too thrilled with the current state of the windows build myself but i'm just waiting to see how it all settles down |
| 03:59.47 | starseeker | Are y'all using mingw and msys or the Microsoft tools? |
| 04:00.16 | brlcad | there are now like 3 ways build on windows, cygwin/mingw or vc6 studio build files or vc7 build files |
| 04:00.35 | starseeker | mingw is always a trip because it never steadies down. |
| 04:00.40 | starseeker | Wow |
| 04:00.47 | starseeker | no wonder it took months |
| 04:00.51 | brlcad | cygwin/mingw is actually the most comprehensive.. it builds the entire package, all libraries, all binaries |
| 04:01.08 | brlcad | i had that working a couple years ago in just a day |
| 04:01.46 | brlcad | the vc6 files on the other hand dont' include any of the binaries, but build all of the libraries "best" |
| 04:02.15 | brlcad | the vc7 files build all of the libraries 'ok' and about 1/4th of the binaries (most of the core ones that people care about) |
| 04:02.30 | starseeker | Hmm. How are the relative benchmark numbers for the different methods? |
| 04:03.00 | brlcad | the problem with the studio files is that they have to be separately maintained and that's a burden without a really highly active windows dev |
| 04:03.41 | starseeker | Yes. Plus, you need a studio license to even get started |
| 04:03.47 | brlcad | hmm.. i hadn't bothered testing extensively, just quick tests to make sure things were working correctly and get a feel |
| 04:04.08 | starseeker | Auuuuuuuuuuuuuugh |
| 04:04.30 | starseeker | --------------------------- ACCESS VIOLATION SUMMARY --------------------------- |
| 04:04.30 | starseeker | LOG FILE = "/var/log/sandbox/sandbox-sci-misc_-_brlcad-7.8.2-13421.log" |
| 04:04.30 | starseeker | open_wr: /usr/lib/describe.com |
| 04:04.30 | starseeker | -------------------------------------------------------------------------------- |
| 04:04.31 | brlcad | studio builds are definitely faster -- the compiler is considerably better at optimizing over what gcc was doing in mingw |
| 04:04.45 | brlcad | hmm.. decribe.com? |
| 04:05.12 | starseeker | Yep. |
| 04:05.22 | brlcad | that sounds familiar |
| 04:05.30 | starseeker | That didn't happen before - but I'm not sure if it was the enable-everything or the optimized flag |
| 04:05.40 | brlcad | sounds like jove |
| 04:05.58 | brlcad | yep, sure enough.. |
| 04:06.04 | brlcad | problem in the jove Makefile.am |
| 04:06.09 | brlcad | --disable-jove :) |
| 04:06.19 | starseeker | I'll run the benchmark from the /var/tmp/portage directory - it did compile. |
| 04:07.42 | starseeker | I think that sandbox feature is responsible for more Makefile cleanups... |
| 04:07.55 | brlcad | that was a 1-char typo :) |
| 04:08.00 | starseeker | Hehehe |
| 04:08.07 | CIA-7 | BRL-CAD: 03brlcad * 10brlcad/src/other/jove/Makefile.am: ACK, typo.. DESDIR != DESTDIR, fix sandbox error |
| 04:08.23 | starseeker | maybe slip in a new 7.8.2 tarball unnoticed? ;-) |
| 04:08.30 | brlcad | heh |
| 04:08.59 | brlcad | nah, ebuild should use --disable-jove |
| 04:09.09 | starseeker | jove isn't essential? |
| 04:09.15 | brlcad | heck no |
| 04:09.25 | starseeker | ok, updating... |
| 04:09.39 | brlcad | it would have been removed from the package a long time ago, but it's an editor.. |
| 04:09.50 | brlcad | and brl-cad has provided it for a very long time.. |
| 04:10.05 | brlcad | ever try to get some unix guy to use a different editor? :-) |
| 04:10.40 | starseeker | It's a little like trying to reason with an Middle Eastern fanatic, actually |
| 04:10.47 | brlcad | let the vi vs emacs vs nano vs pico vs ed wars commence! |
| 04:11.32 | starseeker | OK, one more time (as soon as the benchmark is done) |
| 04:11.35 | brlcad | not so important for "external" or "new" users .. especially packaging systems like portage |
| 04:12.10 | starseeker | OK. Shouldn't be a problem. |
| 04:12.43 | starseeker | They're unlikely to include my ebuild anyway, since I"m content to go with the use everything option and ignore trying to get it working with external tcl/tk |
| 04:13.08 | starseeker | I'll post it, so that one guy can insult it and write a better one again ;-) |
| 04:13.15 | brlcad | heh |
| 04:14.08 | brlcad | well the external tcl/tk thing really isn't going to work until some source mods are made at least to that tk component that requires the private headers but probably also to the package search rules for mged, btclsh, and bwish |
| 04:15.04 | starseeker | Any thought to using something other than tcl/tk? (I know that's a lot of needless work, I just had to ask ;-) |
| 04:15.16 | brlcad | of course |
| 04:15.50 | starseeker | Benchmark results indicate an approximate VGR performance metric of 1510 |
| 04:15.56 | brlcad | it would be a monumental effort to actually replace tcl/tk (several man-years of works) entirely |
| 04:16.08 | starseeker | Eeeeep. |
| 04:16.42 | brlcad | the 'plan' though is to leave the tools that use it as-is (i.e. leave mged alone) and develop new tools that don't have the dependency |
| 04:16.51 | starseeker | We'll schedule that for when Tim Daly begins turning BRL-CAD into a literate programming project ;-) |
| 04:16.57 | starseeker | Ah, OK. |
| 04:17.16 | brlcad | more to the point, a new modeler -- it's actually one of the utmost highest priority development items |
| 04:17.40 | starseeker | Solidworks type UI, or something totally new? |
| 04:19.15 | starseeker | Actually, I guess Solidworks is actually a different kind of CAD? |
| 04:19.46 | brlcad | <PROTECTED> |
| 04:19.52 | starseeker | Cool :-) |
| 04:20.07 | brlcad | solidworks is a different kind of cad slightly, but they do overlap somewhat with the domain |
| 04:20.22 | brlcad | others would be unigraphics, pro/engineer, catia |
| 04:20.56 | starseeker | are they capable of different things, or is it more a "different design philosophy" sort of difference? |
| 04:21.07 | starseeker | (sorry for the dorky questions) |
| 04:21.11 | brlcad | both actually |
| 04:21.16 | brlcad | nah, fine questions |
| 04:21.55 | brlcad | if you get into the research, there was a big debate 15+ years ago regarding geometric representations, implicit vs explicit, brep vs csg, etc |
| 04:22.16 | starseeker | From what little I have seen of solidworks, it seems to have some fairly good tools for taking a solid and "cutting and shaping" the geometry in precise ways, but that's about all I know about it. |
| 04:22.16 | brlcad | most of the commercial systems went explicit and brep, brl-cad went implicit and csg |
| 04:22.24 | starseeker | Ah :-) |
| 04:22.38 | brlcad | since then, both realized the benefits of having both and have moved towards hybrid systems |
| 04:22.54 | starseeker | Heh - that must have upset a lot of academics :-) |
| 04:23.05 | starseeker | nobody wins the total victory ;-) |
| 04:23.10 | brlcad | the commercial guys have invested a lot more time/money into being hybrid, brl-cad to a lesser extent though it is something that needs to continue |
| 04:24.13 | brlcad | i.e. brl-cad actually has pretty extensive support for breps and explicit representations, it's just not well exposed by the modeling tools to say the least and not well developed/debugged/etc |
| 04:24.52 | brlcad | the other big difference is feature-wise -- the big names in the industry have massive purses, massive dev teams |
| 04:24.53 | starseeker | Ah. So the 1st 90% is done, there's just that last 10% that takes 90% of the time? ;-) |
| 04:24.57 | starseeker | true |
| 04:25.00 | brlcad | implementing a "full" CAD system is incredibly expensive |
| 04:25.21 | brlcad | it's the only reason that no open source project has even come close to touching the domain before brl-cad was released as open source |
| 04:25.43 | brlcad | and brl-cad has 20 years investment with some pretty top-notch mathematical talent and programming teams behind it |
| 04:25.52 | starseeker | I suspected something of the sort when I started looking around for one |
| 04:26.08 | starseeker | Mike Myers was involved, IIRC? |
| 04:26.27 | brlcad | and we're dwarfed by the big names when it comes to domains we don't regularly deal with |
| 04:26.40 | starseeker | only natural |
| 04:27.28 | brlcad | drafting, machining, part designing, finite element analyses .. all things we don't "do" well and with each one of those is a long associated feature list |
| 04:27.54 | brlcad | Mike Muuss was the primary brains behind brl-cad's origins |
| 04:28.01 | starseeker | Oh, sorry :-) |
| 04:28.09 | starseeker | wrong MIke |
| 04:28.22 | brlcad | mike myers is a comedian actor ;) |
| 04:28.49 | starseeker | or coffee |
| 04:29.11 | brlcad | i actually have to head off for a bit myself too |
| 04:29.25 | starseeker | OK - did you want the optimized results? |
| 04:29.26 | brlcad | good talking with you again as always |
| 04:29.30 | starseeker | same here |
| 04:29.37 | brlcad | sure |
| 04:29.50 | starseeker | Righto - do I copy the terminal output or is there a file? |
| 04:29.55 | brlcad | send me your 'summary' file |
| 04:30.10 | brlcad | along with the details of your system and compilation options |
| 04:30.20 | starseeker | OK, I'll see what I can dig up. |
| 04:30.30 | brlcad | /proc/cpuinfo, uname -a, and gcc optimization flags |
| 04:30.49 | starseeker | OK. I've got them defined in make.conf - does brlcad add any on its own? |
| 04:31.26 | brlcad | with --enable-optimized it does |
| 04:31.34 | brlcad | here we go |
| 04:31.38 | brlcad | # 0) Operating system type and version (e.g. uname -a) |
| 04:31.41 | brlcad | # 1) Compiler name and version (e.g. gcc --version) |
| 04:31.44 | brlcad | # 2) CPU configuration (e.g. cat /proc/cpuinfo or hinv or sysctl -a) |
| 04:31.48 | brlcad | # 3) Cache (data and/or instruction) details for L1/L2/L3 and system |
| 04:31.51 | brlcad | # (e.g. cat /proc/cpuinfo or hinv or sysctl -a) |
| 04:31.54 | brlcad | # 4) Output from this script (e.g. ./run.sh > run.sh.log 2>&1) |
| 04:31.57 | brlcad | # 5) All generated log files (e.g. *.log* after running run.sh) |
| 04:32.00 | brlcad | # 6) Anything else you think might be relevant to performance |
| 04:32.24 | starseeker | Where is run.sh? |
| 04:32.25 | brlcad | forget 4 and 5, the 'summary' file will do just fine ;) |
| 04:32.29 | starseeker | ah :-) |
| 04:32.37 | starseeker | OK, will do. |
| 04:32.52 | starseeker | the benchmark email is still the one to use? |
| 04:33.03 | brlcad | yeah, that's perfect |
| 04:33.29 | starseeker | OK. Watch the ebuild bug report - I'll post something once it actually builds and start the fight again :-) Have a good one! |
| 04:34.29 | brlcad | sounds good |
| 04:34.35 | brlcad | thanks again, good stuff |
| 04:34.41 | brlcad | already found one bug/typo :) |
| 04:35.20 | starseeker | I've done worse for an evening ;-) |
| 04:36.01 | starseeker | I'll probably wait on the ebuild until I'm sure my system is stable - I'm still trying to recover from that expat upgrade |
| 04:36.25 | starseeker | I think another two days or so |
| 04:36.34 | brlcad | cool |
| 04:37.17 | starseeker | Thanks for all the work you've put in on this - great stuff! |
| 04:37.46 | brlcad | it'll be awesome to finally have it in portage stable |
| 04:37.48 | starseeker | (nosy question I can't resist) what are the schedule plans for the modeler? |
| 04:39.36 | brlcad | it's on-going development as time permits .. when I'm not dealing with issues/releases/support I work on it, working towards a streamlined 'demo' or 'alpha' so devs can jump in and get involved easily |
| 04:40.23 | brlcad | hoping by this fall to have something that will actually run and maybe show geometry with some basic functionality |
| 04:40.30 | starseeker | neat. What language are you looking at? |
| 04:41.09 | brlcad | the overarching design criteria is that it's being treated as if it were a commercial cross-platform game |
| 04:41.38 | starseeker | "Run well everywhere effortlessly?" |
| 04:41.49 | brlcad | C++ is the primary language, built on top of BRL-CAD's existing C libraries and binaries |
| 04:42.46 | starseeker | Hmm. QT4 or WxWidgets sound like logical matches, although I have to admit a preference for QT4. Is VTK usable for modeling display? |
| 04:43.24 | brlcad | there is a fundamental plugin/scripting interface that will provide bindings for several languages at runtime including python, tcl, and bash for starters (and maybe perl and lisp) |
| 04:43.36 | starseeker | Lisp? COOOOL! |
| 04:44.14 | starseeker | (ok, benchmark sent, I think.) |
| 04:44.18 | brlcad | vtk is viable, though it's got a plethora of issues (would you expect any game to use vtk? :) |
| 04:44.45 | starseeker | I must admit that's one thing I haven't seen it do yet ;-) |
| 04:44.57 | starseeker | I think blender can develop games though |
| 04:45.01 | brlcad | similar issue with wxwidgets |
| 04:46.39 | brlcad | blender basically has a python runtime engine driving that game engine |
| 04:46.47 | starseeker | Eeep. |
| 04:47.42 | starseeker | So much for that then... does the c++ code in blender have anything useful? |
| 04:48.06 | brlcad | some aspects potentially |
| 04:49.06 | starseeker | http://www.blender.org/cms/typo3temp/pics/2123f2bd80.jpg is impressive enough, I guess |
| 04:50.30 | brlcad | that's actually not that complex of a model |
| 04:50.55 | starseeker | Wow. |
| 04:51.13 | starseeker | I guess that stands to reason though - assembly lines and such have thousands of parts |
| 04:51.25 | brlcad | they also don't deal at all with solid modeling really, there's no geometric guarantees, no ability to analyse the geometry correctly with guarantees |
| 04:51.38 | starseeker | Ah. |
| 04:51.56 | brlcad | just a bunch of surfaces |
| 04:52.14 | brlcad | "mostly" connected, no insides, no concept of "material" |
| 04:52.38 | starseeker | Ouch. |
| 04:52.46 | brlcad | interferences, geometric construction for an analytic purpose |
| 04:53.00 | starseeker | that all happens at the UI level? |
| 04:53.24 | brlcad | there is some folks looking into adding CAD and solid modeling capabilities into blender, but the approach is rather fundamentally flawed |
| 04:53.26 | starseeker | Well, I guess at a minimum you'd need the UI to be aware of it |
| 04:53.40 | brlcad | what blender does have is a pretty mature UI |
| 04:54.05 | brlcad | their target market though is more in line with products like maya and lightwave |
| 04:54.20 | brlcad | you'd never think of using maya or lightwave in place of unigraphics or pro/engineer :) |
| 04:54.29 | brlcad | though all four are "modelers" |
| 04:55.00 | starseeker | So are unigraphics and pro/engineer kind of a "superset" of the maya/lightwave world? |
| 04:55.12 | brlcad | not really |
| 04:55.45 | brlcad | there are things that maya, lightwave and the sort do very very well that are practially not possible with a solid modeling system and vice versa |
| 04:56.23 | brlcad | the focus is on easily making things that "look" good when rendered (e.g. for a movie) |
| 04:56.45 | brlcad | so it doesn't matter if it's physically correct beyond basic behaviors and appaearance |
| 04:56.54 | starseeker | Oh, so they have different optimizations in their design (the emphasis on surfaces) |
| 04:57.06 | brlcad | solid modelers have the entirely opposite focus -- physical representation is paramount |
| 04:57.50 | starseeker | so solid modelers don't handle things like surface reflectivity? |
| 04:57.53 | brlcad | as the purpose is rarely just to make it look good -- usually the primary purpose is a simulation/analysis, or machining, or designing something that will be manufactured, etc |
| 04:58.09 | starseeker | right |
| 04:58.41 | brlcad | they can and most do as that's pretty based (brl-cad does for example), but it's not a major feature |
| 04:58.57 | starseeker | OK. |
| 04:59.46 | starseeker | Well, I've got a 6:30am meeting, so I'd better hit the hay :-) Thanks a lot for the help with basic ideas! |
| 05:00.11 | brlcad | no problem, cheers! |
| 13:56.20 | CIA-7 | BRL-CAD: 03brlcad * 10brlcad/BUGS: usage of lt says 'lt object' yet if you actually type that you get a bus error.. nice. |
| 13:57.11 | CIA-7 | BRL-CAD: 03brlcad * 10brlcad/NEWS: fixed asc-nmg manual page usage examples |
| 13:58.14 | CIA-7 | BRL-CAD: 03brlcad * 10brlcad/src/conv/asc-nmg.1: fixed asc-nmg manual page usage examples, it doesn't take stdin and output to stdout, but if you provide both file names it works (it will take stdin, but then you can't specify output file) |
| 13:59.10 | CIA-7 | BRL-CAD: 03brlcad * 10brlcad/src/libbu/bitv.c: ws |
| 14:21.03 | CIA-7 | BRL-CAD: 03brlcad * 10brlcad/src/rt/do.c: |
| 14:21.03 | CIA-7 | BRL-CAD: gah, don't reset the view scale.. it might have been specifically set to |
| 14:21.03 | CIA-7 | BRL-CAD: something else. instead call do_ae() now instead of waiting for end. this |
| 14:21.03 | CIA-7 | BRL-CAD: still doesn't work right as do_ae does its own autoview on the geometry and |
| 14:21.03 | CIA-7 | BRL-CAD: resizes, but at least ae command doesn't override now |
| 14:23.35 | CIA-7 | BRL-CAD: 03brlcad * 10brlcad/NEWS: rt command script 'ae' no longer resets view scale |
| 14:52.38 | CIA-7 | BRL-CAD: 03brlcad * 10brlcad/ (5 files in 3 dirs): |
| 14:52.38 | CIA-7 | BRL-CAD: bigger, better vi command line editing in mged provided by james (swcto). this |
| 14:52.38 | CIA-7 | BRL-CAD: adds command history searching as well as pretty much full vi-mode command |
| 14:52.38 | CIA-7 | BRL-CAD: editing. (sf patch 1377410 - Bigger, Better vi command line editing) |
| 14:54.07 | CIA-7 | BRL-CAD: 03brlcad * 10brlcad/NEWS: james made it command edit history searching |
| 15:17.59 | *** join/#brlcad IriX64 (n=IriX64@toronto-HSE-ppp4302514.sympatico.ca) | |
| 15:43.22 | *** join/#brlcad denton (n=anonymou@6532233hfc181.tampabay.res.rr.com) | |
| 15:52.22 | CIA-7 | BRL-CAD: 03brlcad * 10brlcad/src/mged/ged.c: add support for the Mac delete key (backwards and forwards should work now). also fix vi command line editing mode history, quell warnings, pass null parameter. |
| 15:53.54 | CIA-7 | BRL-CAD: 03brlcad * 10brlcad/NEWS: improved support for Mac 'delete' keys in mged |
| 15:56.42 | CIA-7 | BRL-CAD: 03brlcad * 10brlcad/src/mged/ged.c: prevent a bus error if read() returns -1 when reading from the provided file descriptor |
| 16:01.11 | CIA-7 | BRL-CAD: 03brlcad * 10brlcad/src/tclscripts/mged/openw.tcl: set the default number of scrollback lines in mged to 10k instead of 1k |
| 16:04.20 | CIA-7 | BRL-CAD: 03brlcad * 10brlcad/NEWS: |
| 16:04.21 | CIA-7 | BRL-CAD: increase default mged line scrollback to 10,000 lines instead of the previous |
| 16:04.21 | CIA-7 | BRL-CAD: 1000.. too many commands and listings fill up the 1000 count. users can still |
| 16:04.21 | CIA-7 | BRL-CAD: override that default on the fly in their .mgedrc or on the command line. |
| 16:07.10 | CIA-7 | BRL-CAD: 03brlcad * 10brlcad/src/other/jove/jove_term.c: |
| 16:07.10 | CIA-7 | BRL-CAD: prevent jove from crashing on SGI Altix due to clamping the tgetstr pointer to |
| 16:07.10 | CIA-7 | BRL-CAD: 32-bit when it needs to be 64-bit. this requires actually including the right |
| 16:07.10 | CIA-7 | BRL-CAD: headers so that tgetstr is properly declared, but declare it to what it should |
| 16:07.10 | CIA-7 | BRL-CAD: be regardless since.. this is jove. |
| 16:08.52 | CIA-7 | BRL-CAD: 03brlcad * 10brlcad/NEWS: ported jove to SGI Altix platform, fixed crash bug. |
| 16:11.54 | CIA-7 | BRL-CAD: 03brlcad * 10brlcad/src/rt/opt.c: initialize a slew of uninitialized values using proper casts for the fastf_t types. uninitialized garbage was causing debug and runtime problems on altix |
| 16:18.09 | CIA-7 | BRL-CAD: 03brlcad * 10brlcad/src/rt/do.c: check and see if the eye point was set to something different than the look at point, otherwise choose a default 'front' view just to pick a direction. also, make sure rtip is valid before checking lists |
| 17:08.39 | CIA-7 | BRL-CAD: 03brlcad * 10brlcad/regress/Makefile.am: additional testing files that need to get cleaned up |
| 19:40.30 | IriX64 | guys whats am-refresh and does it matter if it didn't get built? |
| 19:50.57 | brlcad | am-refresh is an internal automake rule that checks/updates the Makefiles if a dependency is updated (like editing a Makefile.am) |
| 19:51.51 | brlcad | it shouldn't be necessary at all |
| 19:54.30 | IriX64 | thankyou |
| 20:22.38 | IriX64 | brb |
| 20:25.24 | *** join/#brlcad IriX64 (n=IriX64@toronto-HSE-ppp4302514.sympatico.ca) | |
| 20:28.52 | *** join/#brlcad CIA-9 (i=cia@cia.navi.cx) | |
| 21:53.53 | *** join/#brlcad ChanServ (ChanServ@services.) | |
| 21:53.53 | *** mode/#brlcad [+o ChanServ] by irc.freenode.net | |
| 23:08.58 | CIA-9 | BRL-CAD: 03johnranderson * 10brlcad/src/mged/grid.c: |
| 23:08.58 | CIA-9 | BRL-CAD: Fix for bug #1233930 (grid zoom out hangs) |
| 23:08.58 | CIA-9 | BRL-CAD: Problem was integer overflow. |
| 23:08.58 | CIA-9 | BRL-CAD: Fix was to check for negative integer. A better algorithm for deciding when |
| 23:08.58 | CIA-9 | BRL-CAD: the grid should not be drawn is needed here. |
| 23:12.36 | brlcad | and john continues to rock |
| 23:38.10 | ``Erik | the man is an artist |
| 23:41.18 | ``Erik | I wish he woulda taken his vsip and had a little fun :/ |
| 23:51.22 | ``Erik | he coulda bought that solstace he wanted outright, heh |
