| 00:34.57 | *** join/#brlcad cosurgi (i=janek@irc.cool.waw.pl) | |
| 00:37.42 | brlcad | andrecastelo_: I did start to look it over, there are two ahead of it, though :) |
| 00:56.44 | *** join/#brlcad cosurgi (i=janek@irc.cool.waw.pl) | |
| 01:01.05 | andrecastelo_ | hm ok then :D |
| 01:08.49 | yukonbob | hello, cadheads |
| 01:09.06 | andrecastelo_ | hey yukonbob |
| 01:09.47 | CIA-20 | BRL-CAD: 03brlcad * r30805 10/brlcad/trunk/NEWS: Bob added support to query pixels in the wgl framebuffer similar to what is available for the ogl and X framebuffers |
| 01:09.48 | brlcad | howdy yukonbob |
| 01:13.39 | CIA-20 | BRL-CAD: 03brlcad * r30806 10/brlcad/trunk/TODO: Bob implemented support to mirror across a distance along a given axis in mged. technically he implemented it in 7.12.2 but it was left out of the release notes so mentioning it here |
| 01:14.37 | CIA-20 | BRL-CAD: 03brlcad * r30807 10/brlcad/trunk/TODO: -Wfloat-equal is covered by the other todo for obliterating verbose compilation warnings |
| 01:18.19 | CIA-20 | BRL-CAD: 03brlcad * r30808 10/brlcad/trunk/NEWS: consistently refer to mged in lowercase on the individual news lines but uppercase in the english write-ups throughout the NEWS file. |
| 01:21.30 | yukonbob | nice to see lots of commit msgs, rev. bump :) |
| 01:23.14 | brlcad | likes lots of frequent commits |
| 01:23.57 | brlcad | like each commit to be "just one thing" with useful commit messages |
| 01:27.46 | yukonbob | of course, of course -- but some days have more than others -- today seems 'extra noticeable' to me... I'm always happy w/ BRL-CAD -- a bit extra-happy today, though. |
| 01:27.49 | yukonbob | <PROTECTED> |
| 01:29.05 | brlcad | too :) |
| 01:29.28 | brlcad | suspects it'll get pretty noisy in here this summer :) |
| 01:29.37 | brlcad | and leading up to |
| 01:29.53 | brlcad | and hopefully after too! ;) |
| 01:57.52 | yukonbob | Bring the Noise!! |
| 02:19.32 | andrecastelo_ | guys |
| 02:19.33 | andrecastelo_ | i'm out |
| 02:19.35 | andrecastelo_ | good night |
| 02:19.36 | andrecastelo_ | :D |
| 02:20.25 | *** join/#brlcad cosurgi (i=janek@irc.cool.waw.pl) | |
| 02:31.55 | CIA-20 | BRL-CAD: 03brlcad * r30809 10/brlcad/trunk/NEWS: reword the intro header and footer for clarity |
| 04:41.29 | *** join/#brlcad PrezzKennedy (i=Matthew@74.86.45.130) | |
| 05:50.52 | *** join/#brlcad d_rossberg (n=rossberg@bz.bzflag.bz) | |
| 06:37.23 | *** part/#brlcad jdoliner (n=jdoliner@wireless-199-123.uchicago.edu) | |
| 07:03.22 | *** join/#brlcad clock_ (n=clock@zux221-122-143.adsl.green.ch) | |
| 10:18.29 | *** join/#brlcad mafm (n=mafm@elnet-111.lip.pt) | |
| 10:22.53 | mafm | hai |
| 11:22.20 | *** join/#brlcad elite01 (n=elite01@dslc-082-082-072-071.pools.arcor-ip.net) | |
| 12:10.49 | *** join/#brlcad homovulgaris (n=thedawn@202.63.233.61) | |
| 12:35.41 | brlcad | mafm: Fernández con acento o sin? |
| 12:43.33 | brlcad | MinuteElectron: would you happen to know why the contact page won't prompt a captcha? I can't seem to get it to work :/ |
| 12:54.01 | mafm | brlcad: I tend to not use it |
| 12:58.41 | brlcad | k |
| 12:59.41 | MinuteElectron | brlcad: Not off hand, but I'll look into it later today. |
| 12:59.50 | brlcad | mafm: does "New OpenGL GUI Framework for Modeling and Visualization" sound like a reasonable summary description? |
| 13:00.07 | brlcad | MinuteElectron: okay, cool .. thanks! |
| 13:00.52 | brlcad | they're turned on and work for other drupal forms (actually they only work exactly every other time ..) but just not for the contact form |
| 13:01.03 | MinuteElectron | =\ |
| 13:01.05 | brlcad | they do work cleanly for the wiki, though |
| 13:01.06 | mafm | brlcad: what's that summary description for? |
| 13:01.08 | MinuteElectron | that's very odd |
| 13:02.00 | brlcad | wondering if it's just "somehow" misconfigured drupal plugin -- can't imagine a plugin that popular having a bug that obvious, but who knows |
| 13:02.23 | brlcad | mafm: for the masses at large |
| 13:02.44 | brlcad | announcement formulation |
| 13:03.22 | brlcad | explaining what these projects are in more layman terms |
| 13:03.53 | brlcad | pacman87: yours is "Implementing Solid of Revolution and Sweep Primitives" |
| 13:05.34 | brlcad | mafm: in fact, I think it works even better as simply "New Framework for Modeling and Visualization" |
| 13:07.12 | brlcad | hm, or not -- never mind :) |
| 13:10.38 | brlcad | mafm: oh, also as you noticed yesterday, your mentor is now the esteemed 'Bob' |
| 13:12.34 | brlcad | he's a really great guy that should be a good fit for evaluating what you're working on -- we still do group mentoring as much as possible for the technical aspects (i'm certainly always available to answer questions), but he'll be the point man for following your progress |
| 13:13.23 | brlcad | and of course, let me know if you have any questions or problems with your mentor (same goes for any of the gsocers) |
| 13:28.07 | mafm | brlcad: "New GUI Framework for [Remote?] Modeling and Visualization" is fine I guess |
| 13:34.25 | homovulgaris | hi mafm , brlcad :) |
| 13:34.41 | brlcad | howdy homovulgaris |
| 13:34.53 | brlcad | ah, right Dawn! |
| 13:35.00 | brlcad | isn't used to that nick :) |
| 13:35.09 | homovulgaris | :P |
| 13:41.06 | homovulgaris | i am pretty new to the channel :) |
| 13:41.16 | homovulgaris | so @brlcad is sean ? |
| 13:41.19 | homovulgaris | mafm is manuelo ? |
| 13:41.52 | homovulgaris | *manuel i meant |
| 13:42.19 | ``Erik | yes to both |
| 13:45.01 | brlcad | ~seen johnranderson |
| 13:45.01 | ibot | i haven't seen 'johnranderson', brlcad |
| 13:45.07 | brlcad | hm |
| 13:46.01 | ``Erik | ~seen daytona |
| 13:46.02 | ibot | daytona <n=jra@c-68-55-36-65.hsd1.md.comcast.net> was last seen on IRC in channel #brlcad, 20d 11h 39m 28s ago, saying: 'prasad_: Hey, how's it going?'. |
| 13:46.24 | ``Erik | he had another modified variant he was in with :/ grep logs O.o |
| 13:47.28 | brlcad | yeah, that's what I was hunting for |
| 13:47.34 | brlcad | daytona isn't registered to him |
| 13:47.56 | brlcad | ~seen daytonajohn |
| 13:47.57 | ibot | daytonajohn <n=jra@c-68-55-36-65.hsd1.md.comcast.net> was last seen on IRC in channel #brlcad, 14d 11h 51m 54s ago, saying: 'brlcad: good, I'll watch for it'. |
| 13:48.27 | ``Erik | heh, beat me to it |
| 13:48.59 | brlcad | 6 days ago according to nickserv |
| 13:50.33 | ``Erik | I see him last here on apr 09 |
| 13:50.42 | ``Erik | ish |
| 14:07.18 | *** join/#brlcad louipc (n=louipc@bas8-toronto63-1128544174.dsl.bell.ca) | |
| 14:09.14 | *** join/#brlcad prasad_ (n=psilva@70.108.244.218) | |
| 14:13.12 | *** join/#brlcad docelic (n=docelic@78.134.203.64) | |
| 14:13.41 | *** join/#brlcad cad81 (n=5b96544b@bz.bzflag.bz) | |
| 14:26.31 | *** join/#brlcad kwizart (n=kwizart@fedora/kwizart) | |
| 14:26.34 | kwizart | ERROR: bad pointer x7fff04c190d0: s/b bu_ptbl(x7074626c), was Unknown_Magic(x2aaaaad156e8), file ptbl.c, line 72 |
| 14:27.27 | kwizart | this error occured when doing make test - lt-rt was blocked at /bin/sh ../regress/solids.sh .. |
| 14:28.43 | kwizart | actually i send a kill -9 as the process seemed to take much time (more than one hour) - but i don't know how much time would be needed anywya |
| 14:29.35 | kwizart | -> gqa.sh succeeded |
| 14:29.36 | kwizart | +++ gqa test complete. |
| 14:29.45 | kwizart | others test seems to succeed |
| 14:30.44 | kwizart | ok, done the benchmark tests |
| 14:30.44 | kwizart | Estimated time is 9 minutes, 36 seconds |
| 14:34.54 | brlcad | that's not a good sign on the make test |
| 14:35.10 | brlcad | none of the individual tests should take more than a couple seconds |
| 14:35.37 | brlcad | where did you see the bad pointer message? |
| 14:35.57 | kwizart | just after kiling the lt-rt process |
| 14:36.04 | brlcad | ah |
| 14:36.13 | brlcad | I suspect it was waiting in the debugger |
| 14:36.25 | brlcad | and that was just pending buffered i/o |
| 14:36.34 | brlcad | do you have a bomb log in that directory? |
| 14:36.43 | kwizart | 19031 builder 35 10 105m 7652 4852 S 193 0.4 12:37.17 lt-rt |
| 14:37.13 | kwizart | 193 is the CPU used - it use the dual core on benchmark but not on test |
| 14:37.23 | kwizart | look at the log |
| 14:37.59 | brlcad | there should be a bomb.log, hopefully with a valid stack trace |
| 14:39.32 | brlcad | should be something like lt-rt-19031-bomb.log |
| 14:39.34 | kwizart | yes i have 9 lt-g_qa-????-bomb.log |
| 14:40.09 | brlcad | can you paste one of them somewhere? |
| 14:40.17 | brlcad | or all of them |
| 14:40.26 | kwizart | do you want all log in the regress directory or only the bomb one ? |
| 14:40.27 | brlcad | or post or e-mail |
| 14:40.35 | brlcad | sure, that'd help |
| 14:42.42 | kwizart | will wait if bench can finish |
| 14:44.48 | kwizart | well ok - killed |
| 14:45.33 | *** join/#brlcad thing0 (n=ric@203-59-122-121.dyn.iinet.net.au) | |
| 14:45.45 | brlcad | what was benchmark doing? it does take about 10 minutes |
| 14:45.48 | thing0 | hey |
| 14:45.50 | thing0 | hey |
| 14:45.55 | brlcad | should have been ticking by frames |
| 14:46.13 | brlcad | that get slower and slower in repetition |
| 14:46.25 | brlcad | hello thing0 |
| 14:46.52 | kwizart | ok - wasn't even moving |
| 14:47.58 | brlcad | should look something like http://pastebin.bzflag.bz/m53901717 |
| 14:49.22 | kwizart | it goes until #+++++ moss |
| 14:49.31 | kwizart | where should i email ? |
| 14:55.05 | brlcad | damn that's one huge configure line :) |
| 15:00.27 | thing0 | how u doing brlcad? |
| 15:00.41 | brlcad | busy |
| 15:08.25 | brlcad | kwizart: ... wow, something is really hosed there for a couple of the test cases -- something is tripping up our run-time corruption detection, and correctly from the looks of the logs -- "something" is wrong |
| 15:09.08 | brlcad | ponders |
| 15:16.35 | brlcad | there was at least one useful crash log (the 'unknown' one for rt) that leads be to believe there's some aliasing problem or byte offsets are being computed incorrectly |
| 15:17.43 | brlcad | can you try a simple: "./configure --enable-all && make clean && make && make benchmark" build to see if that also hangs at the +++++ moss ? |
| 15:18.18 | brlcad | presuming ssp is off by default |
| 15:18.31 | brlcad | otherwise, turning that off as well for the test |
| 15:20.48 | CIA-20 | BRL-CAD: 03bob1961 * r30810 10/brlcad/trunk/src/librt/mirror.c: Apply mirror_pt to the particle primitive. Remove old line of code from the ELL/SPH section. |
| 15:25.02 | kwizart | without doing make test ? how can i enable ssp at configure ? it would be better to have accurate configure option so I won't need to build tcl8.5 buildin |
| 15:28.29 | brlcad | this is just to test the build |
| 15:28.56 | brlcad | before turning on all the various protections and worrying about what is linking with what where, I'd like to verify that the default build even works |
| 15:29.09 | brlcad | because from that crash report, it looks like it might not be |
| 15:29.40 | brlcad | for all I know, ssp may even be causing a problem (e.g. with aliasing) |
| 15:30.47 | brlcad | make benchmark is also one of our tests, a more fundamental test that validates the representation and geometric evaluation (via ray-tracing) |
| 15:37.43 | kwizart | well, there is really low chance for the configure to rich it end if i'm just using ./configure --enable-all - but i will try |
| 15:37.56 | ``Erik | has run into unexpected weird crashes from system libs when deviating from --enable-all... like tk85 straight up crashes on amd64 if truetype fonts are enabled |
| 15:38.39 | CIA-20 | BRL-CAD: 03starseeker * r30811 10/brlcad/trunk/src/proc-db/tire.1: Add man page description of new options |
| 15:39.46 | CIA-20 | BRL-CAD: 03starseeker * r30812 10/brlcad/trunk/src/proc-db/tire.c: Break some things out into functions, put tire region creation inside tire function. |
| 15:41.43 | brlcad | ``Erik: he's getting a slew of magic check failures for the ptbl structs -- one happens during boolweave in the stack shader, another in g_qa |
| 15:42.06 | ``Erik | ugh |
| 15:42.15 | brlcad | starseeker_: now that it has docs, deserves the news line ;) |
| 15:42.18 | ``Erik | yeah, definitely revert to a simple configure line O.o :D |
| 15:42.25 | mafm | going earlier today |
| 15:42.29 | ``Erik | hehehe, it has a -h help, too! :D |
| 15:42.29 | mafm | bye |
| 15:42.41 | brlcad | cya mafm |
| 15:43.29 | ``Erik | notes that tire.1 is installed in 7.12.2 release |
| 15:45.05 | brlcad | ah, oh well close enough :) |
| 15:45.38 | starseek1r | brlcad: OK, I'll add it :-) |
| 15:46.04 | starseek1r | ``Erik : It is? oops |
| 15:47.08 | ``Erik | yeah, you added it to man_MANS instead of noinst_MANS |
| 15:47.23 | ``Erik | had to change the fbsd port pkg-plist for it :) |
| 15:47.27 | starseek1r | Sorry |
| 15:47.52 | ``Erik | it's all good, chances are that no one will notice it before 7.12.4 with a NEWS line :D |
| 15:48.02 | ``Erik | other than being there, it wasn't advertised |
| 15:48.27 | starseek1r | reflects that proc-db was a poor place to check on how to install man pages... |
| 15:49.23 | CIA-20 | BRL-CAD: 03starseeker * r30813 10/brlcad/trunk/NEWS: Add note about tire proc-db |
| 15:49.29 | starseek1r | There we go |
| 15:49.42 | ``Erik | I don't think we do a noinst_MANS anywhere :/ |
| 15:50.18 | starseek1r | Well, considering there was only one other man page in all of proc-db, it was still a bad place to check :-P |
| 15:50.39 | ``Erik | heh, uh, really? damn, proc-db needs more man pages! |
| 15:51.00 | ``Erik | though that idea I threw out the other day is more and more appealing to me |
| 15:51.03 | starseek1r | actually asked brlcad at one point if proc-dbs were supposed to be documented with man pages... |
| 15:51.16 | ``Erik | hoisting all the procdb's into a library and having a lean little binary that chooses what funcs to call |
| 15:52.31 | starseek1r | likes the idea of calling bolt functionality from a bolt proc-db inside the tire proc-db... |
| 15:52.57 | starseek1r | ``Erik - I agree, it's growing on me as well. |
| 15:53.29 | starseek1r | ``Erik: Do we have proc-dbs for bolts/gears/springs/other fun stuff? |
| 15:53.38 | ``Erik | if burly likes it, it should go into the TODO file, I'd imagine |
| 15:53.42 | ``Erik | I d'no, look in the db dir? |
| 15:53.43 | *** join/#brlcad Elperion (n=Bary@p54877B5E.dip.t-dialin.net) | |
| 15:54.44 | ``Erik | the only one in there I only have any real knowledge about is sphflake |
| 15:55.11 | starseek1r | Hmm, ducks... pyramid... tea... |
| 15:55.44 | brlcad | historically, the proc-db's are for testing geometry creation, testing new primitives or wdb routines |
| 15:56.37 | starseek1r | So is what ``Erik and I are contemplating something different? |
| 15:56.44 | brlcad | i'm not convinced they make much sense as a library.. they're not really consistent with each other |
| 15:57.00 | brlcad | other than the basic idea that they "make things" |
| 15:57.06 | starseek1r | <evil grin> yet! </evil grin> |
| 15:57.17 | brlcad | they would make nice plugins individually though |
| 15:57.44 | brlcad | i did plan to rewire then like the other 400 tools as modules |
| 15:58.09 | starseek1r | would like to be able to say "I need 5/16in bolts in this wheel" and call the bolt generation routine... |
| 15:58.40 | brlcad | that's all high-level modeling -- you could do that with them as individual plugins or in a library |
| 15:58.47 | starseek1r | after writing the bolt generation routine, apparently... <cough> |
| 15:58.55 | brlcad | there is an mk_bolt already |
| 15:59.02 | starseek1r | Ah, good :-) |
| 16:00.01 | starseek1r | Heh - libnutsandbolts would be awesome :-P |
| 16:00.08 | brlcad | i see them getting tied together at a much higher level where api consistency won't matter, nor will the backend implementation |
| 16:02.21 | starseek1r | isn't quite following - let's say, for example, I want to write a utility at some level that uses routines for nuts, bolts and curved panels to make a hull plate. The hull plate routine would depend on the nut and bolt functionality - how would it invoke them? |
| 16:02.38 | starseek1r | (sorry for being dense...) |
| 16:03.21 | brlcad | it's the "at some level" part |
| 16:03.36 | brlcad | I see that as being a pretty high level as it's almost arbitrary at the low-level |
| 16:04.05 | starseek1r | In other words, a level that doesn't exist yet? |
| 16:04.41 | brlcad | even the existing proc-db's and mk's have little to nothing to do with each other, it would take a lot of effort to make them even *able* to work with each other, and for hardly any large benefit |
| 16:04.51 | brlcad | right, it doesn't exist |
| 16:04.55 | starseek1r | ah |
| 16:04.58 | starseek1r | gotcha |
| 16:04.59 | brlcad | and making it exist is paramount to rewriting most of them |
| 16:05.36 | brlcad | so screw it and integrate them at a higher (probably scripting/plugin) level |
| 16:06.00 | brlcad | where you just need descriptor sheets for what parameters you want to allow, what the various knobs/buttons are, etc |
| 16:06.46 | starseek1r | Ah :-). And in the meantime, in the isolated and unlikely cases where it would be useful now, just throw out a .h file for the function or two needed? |
| 16:07.00 | starseek1r | sees some .h files in there already |
| 16:07.01 | brlcad | it makes a heck of a lot more sense for the images or geometry converters to be integrated into a library than it does the procedural geometry generators |
| 16:08.04 | brlcad | for most of them, "main" is the interface -- you could wrap them up so they all call some given function, but that's trivial |
| 16:09.31 | starseek1r | OK. |
| 16:09.41 | starseek1r | thinks it is making sense. |
| 16:26.25 | kwizart | Frame 0: 357882 rays in 0.81 sec = 443264.77 rays/sec (RTFM) |
| 16:26.25 | kwizart | Frame 1: 715764 rays in 1.62 sec = 441760.37 rays/sec (RTFM) |
| 16:26.40 | kwizart | moss.pix: answers are RIGHT |
| 16:27.49 | kwizart | world.pix: answers are RIGHT |
| 16:34.45 | CIA-20 | BRL-CAD: 03starseeker * r30814 10/brlcad/trunk/src/proc-db/tire.c: Switch ell in instead of eto for center wheel curve - no advantage to the eto shape for this wheel design. |
| 16:35.11 | *** join/#brlcad andrecastelo (n=chatzill@189.71.75.27) | |
| 16:35.28 | andrecastelo | good afternoon fellow cadheads :D |
| 16:35.47 | kwizart | Benchmark results indicate an approximate VGR performance metric of 2561 |
| 16:35.47 | kwizart | Logarithmic VGR metric is 3,41 (natural logarithm is 7,85) |
| 16:36.49 | kwizart | i should have told that I have disabled some CFLAGS ( and enabled ours) |
| 16:37.35 | kwizart | http://pastebin.bzflag.bz/m5b9bd8aa |
| 16:37.39 | brlcad | kwizart: okay, that's good progress .. now to narrow what causes it |
| 16:38.24 | brlcad | kwizart: -fno-strict-aliasing is needed |
| 16:39.25 | brlcad | otherwise .. problems, that would explain the validation check failures |
| 16:39.46 | brlcad | -O2 ends up doing bad things with strict aliasing on |
| 16:39.50 | kwizart | that is our CFLAGS -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic |
| 16:40.18 | brlcad | I saw that in the log |
| 16:40.29 | brlcad | is that what you used when you got the RIGHT answers? |
| 16:40.30 | kwizart | anythin that conflict with thoses need to be explicitly argued... |
| 16:40.38 | kwizart | no |
| 16:41.07 | brlcad | okay, that's making more sense then |
| 16:41.17 | kwizart | no CFLAGS where used... and i wonder if -fno-strict-aliasing remained disabled |
| 16:41.20 | brlcad | try your flags again then, but keep -fno-strict-aliasing |
| 16:41.47 | brlcad | well with just --enable-all, it would have no optimization, so it's not a problem yet |
| 16:42.00 | brlcad | if you'd added --enable-optimized or -O2 or -O3, it should have failed |
| 16:42.19 | kwizart | well i don't think i will build with optimization... what does add optim ? |
| 16:42.30 | kwizart | (other than cflags) |
| 16:42.35 | brlcad | your CFLAGS turns on optimization |
| 16:43.38 | brlcad | our optimization just adds -O3 right now |
| 16:45.25 | kwizart | we don't distribute package with -O3 for now... maybe a can add a rpm macros to ease the rebuilt of some component (not all probably) that would need -O3 to be more efficient |
| 16:46.20 | kwizart | i will need to figure out how can i split components for the brlcad rpm package.. |
| 16:46.33 | brlcad | kwizart: I'm not saying you want/need O3 :) |
| 16:46.34 | kwizart | with some sub-packages |
| 16:46.39 | brlcad | the difference from O2 is minor |
| 16:46.53 | brlcad | but either O2 or O3 without -fno-strict-aliasing is a problem |
| 16:47.03 | brlcad | any O level |
| 16:47.16 | brlcad | try your CFLAGS but also add -fno-strict-aliasing |
| 16:47.26 | kwizart | yep it build |
| 16:47.29 | brlcad | see if that results in RIGHT |
| 16:48.28 | brlcad | it could still be some odd interaction with _FORTIFY_SOURCE ssp mods, but strict aliasing is a known problem |
| 16:48.39 | kwizart | at least i will need OpenNurbs to be built externally. at least |
| 16:50.02 | brlcad | that probably won't work, we've made opennurbs modifications directly |
| 16:50.31 | brlcad | there are plans to move the changes out of opennurbs, but as it presently stands written, you can think of opennurbs as just another internal library |
| 16:50.40 | kwizart | we can disable the some cflags under certains circumstances - but we discuss that maybe that also x86_64 problem... don't know much |
| 16:50.59 | brlcad | hm? |
| 16:51.02 | kwizart | about OpenNurbs i will probably take a snapshoot from the brlcad release |
| 16:51.18 | brlcad | there shouldn't be any need to disable any of those cflags |
| 16:51.30 | brlcad | and we do work on x86_64, it's regularly tested |
| 16:51.35 | kwizart | i don't know any FOSS project other than brlcad using it for now |
| 16:51.55 | brlcad | yep, and I doubt any would .. it's pretty niche to the CAD industry |
| 16:52.44 | brlcad | maybe blender or avocado at some point, but not likely |
| 17:01.46 | CIA-20 | BRL-CAD: 03brlcad * r30815 10/brlcad/trunk/configure.ac: this has happened several times now. make a note that -fno-strict-aliasing is REQUIRED if any level of optimization is enabled (and we're using GCC as we do use and rely on aliasing and type-punning. |
| 17:01.59 | brlcad | fg |
| 17:02.14 | ``Erik | much have for bu list type punning. |
| 17:02.20 | ``Erik | punting, even |
| 17:02.28 | ``Erik | and, uh, s/have/hate/ |
| 17:02.30 | CIA-20 | BRL-CAD: 03brlcad * r30816 10/brlcad/trunk/configure.ac: leave it at that |
| 17:03.07 | ``Erik | when I was first doing the move from cake to automake, that bit me bigtime... |
| 17:03.35 | ``Erik | and I presented my argument and the point that many others have done that switch, but lbutler resisted :/ |
| 17:03.42 | brlcad | I've come to appreciate the bu_list style use, but it's the pointer tables that break with -fno-strict-aliasing iirc |
| 17:04.26 | brlcad | related to bu_list's of course |
| 17:06.26 | ``Erik | I appreciated the approach and had been sufficiently beaten down to step back and consider |
| 17:06.40 | ``Erik | there're better ways to accomplish the goal given the limitations |
| 17:06.42 | ``Erik | :/ |
| 17:06.50 | ``Erik | I could not convince lee of that |
| 17:07.46 | brlcad | such as? |
| 17:08.39 | brlcad | bu_lists are pretty damn prevalent ... |
| 17:08.41 | ``Erik | hrm? whichwhat? |
| 17:09.01 | brlcad | "better" ways to accomplish the goal |
| 17:09.03 | ``Erik | old bsd linked list used to be exactly that, new bsd linked list doesn't do that |
| 17:09.16 | ``Erik | instead using container style |
| 17:10.05 | ``Erik | when I was doing the conversion, fbsd had JUST gone through a fairly painful migration from old cast style to new LISt style |
| 17:10.40 | brlcad | it would be painful for us too, quite .. |
| 17:10.48 | brlcad | probably at least 10k instances of use |
| 17:11.08 | brlcad | non-regexable |
| 17:12.07 | ``Erik | tends to be the case |
| 17:12.17 | ``Erik | I tried to fix it back when it was easily fixable |
| 17:12.31 | brlcad | maybe as low as 877 though, if the macro wrappers are consistently used (which they're not) |
| 17:12.35 | ``Erik | lee took a moral stance on it.. I was new to the project and job, so I folded too soon :/ |
| 17:12.55 | ``Erik | "if I knew then what I know now" |
| 17:13.02 | brlcad | meh, it's rather bikeshed |
| 17:13.22 | brlcad | it's just an optimization based on a false assumption that C allows for |
| 17:13.31 | ``Erik | i'd disagree |
| 17:14.02 | brlcad | so you can feel strongly for or against it, but it's not like it's inherintly right or wrong imo |
| 17:14.20 | ``Erik | it's an optimization based on assumption that every developer is fully aware of the ugly implifications of the reprecussions that the dirty cheats C allows for |
| 17:14.47 | ``Erik | I mean, a fistful of guru C coders? SURE, bits is bits, we know how it all hammers out |
| 17:15.16 | ``Erik | the minute you throw in someone who isn't qualified to chum among the "greybeard" gurus... uh, we get little hard to track issues |
| 17:15.29 | brlcad | eh, that's not disagreeing with what I said -- except maybe that it's a "false assumption" |
| 17:15.42 | brlcad | i'm saying it's false *because* C allows for it |
| 17:15.56 | brlcad | not saying that it should or should not be used |
| 17:16.14 | brlcad | THAT is what makes it bikeshed -- if it's to be resolved otherwise, C should be modified |
| 17:16.20 | ``Erik | it's not illegal, it's dangerous :D I think we're in violent agreement |
| 17:18.22 | ``Erik | I'm a bsd junkie, I watched them expunge themselves of exactly this, I think they did the right thing in more orless the right way... *shrug* with the move from fbsd 5 to fbsd 6 iirc |
| 17:19.25 | kwizart | ok well that was my bad - it seems to work with our cflags and -fno-common -fno-strict-aliasing |
| 17:20.19 | brlcad | it's just so petty, though .. I mean say you do the whole conversion, spend the days/weeks/months refactoring hundreds to thousands of lines of code .. and *don't* actually inject new bugs .. you basically end up where you started |
| 17:20.34 | brlcad | i mean "maybe" with a percent or two optimization gain at *best* |
| 17:20.37 | ``Erik | NEEDS -fno-strict-aliasing, for exactly the thing brlcad and myself are talking about here |
| 17:20.59 | brlcad | kwizart: you shouldn't need (or care) about -fno-common on linux |
| 17:23.43 | kwizart | Elapsed compilation time: 14 hours, 56 minutes, 37 seconds |
| 17:24.01 | kwizart | ^^ what does it means: |
| 17:24.03 | kwizart | Elapsed time since configuration: 20 minutes, 22 seconds |
| 17:24.23 | brlcad | it means your clock probably recently crossed midnight |
| 17:25.29 | brlcad | or just that you started building 14 hours ago |
| 17:25.37 | kwizart | 19h25 |
| 17:25.38 | brlcad | when you first ran make |
| 17:26.10 | brlcad | it's based off of the build stamp in include/conf and if you've not ran make clean, that'll just keep getting bigger |
| 17:26.18 | kwizart | start building20min ago , unless it took distcc content... it is recreated each time... |
| 17:26.24 | kwizart | with rpmbuild -ba |
| 17:26.48 | brlcad | reiterates .. it's based off of the build stamp in include/conf and if you've not ran make clean, the compilation time will just increase |
| 17:27.34 | brlcad | *or* maybe you're pulling from a source tarball where there's a date stamp already in there |
| 17:27.58 | brlcad | cat include/conf/DATE |
| 17:29.01 | kwizart | "Wed Apr 23 04:21:07 EDT 2008" |
| 17:29.13 | kwizart | date : jeu avr 24 19:29:05 CEST 2008 |
| 17:29.19 | kwizart | get it |
| 17:29.31 | brlcad | yeah, that's a build stamp from the source tarball |
| 17:29.42 | brlcad | it doesn't know it's out of date |
| 17:36.34 | *** join/#brlcad homovulgaris (n=thedawn@202.63.233.61) | |
| 17:39.52 | ``Erik | so, brlcad,what do you think of hoisting proc-db functionality into a lib with a big wrapper executable? |
| 17:40.09 | brlcad | thinks ``Erik missed a bunch of backlog |
| 17:40.18 | ``Erik | *scroll* |
| 17:54.13 | CIA-20 | BRL-CAD: 03brlcad * r30817 10/brlcad/trunk/include/conf/Makefile.am: |
| 17:54.13 | CIA-20 | BRL-CAD: make HOST, PATH, USER, and DATE depend on brlcad_config.h so that the values |
| 17:54.13 | CIA-20 | BRL-CAD: reset every time configure is run. this way the date stamp and build system |
| 17:54.13 | CIA-20 | BRL-CAD: should match whomever is performing the build for source dist builders instead |
| 17:54.13 | CIA-20 | BRL-CAD: of the maintainer that made the distribution tarball. the downside is more |
| 17:54.16 | CIA-20 | BRL-CAD: frequent rebuilds of everything for internal devs. |
| 18:03.46 | starseek1r | In C, how do I generate the name of a function to call and then call it? (e.g., say I have draw1, draw2 and draw3 defined and I want to do a for loop for i = 1 to three call draw$i? |
| 18:05.29 | brlcad | you would usually use macros, have defined call-table mappings, or use dynamic loading |
| 18:05.40 | brlcad | what are you actually trying to do? |
| 18:07.40 | brlcad | unless you have dozens to iterate over, you'd probably should just call draw1(); draw2(); draw3(); |
| 18:10.21 | starseek1r | The idea is there may be an unknown (to tire) number of possible wheel or tread styles defined |
| 18:12.50 | starseek1r | I want to specify on the command line -t 8 and have tire attempt to draw tread pattern 8. I'd like the routine that attempts to draw different patterns to be generic, and not need editing each time a new tread is defined |
| 18:15.15 | brlcad | they're not unknown in code, though -- they have to be in there |
| 18:16.04 | brlcad | with that specific example, you could have an array of function pointers and -t 8 would give you the 8th function pointer |
| 18:16.39 | starseek1r | heh - bob suggested that too :-) Could you recommend a good tutorial/example on using function pointers in C? |
| 18:16.48 | brlcad | google? :) |
| 18:16.53 | starseek1r | k :-) |
| 18:16.56 | brlcad | i'm sure there are hundreds |
| 18:21.45 | pacman87 | finally caught up reading |
| 18:21.52 | pacman87 | been really busy this week |
| 18:22.30 | pacman87 | (08:09:24) brlcad: announcement formulation |
| 18:22.30 | pacman87 | (08:10:02) brlcad: explaining what these projects are in more layman terms |
| 18:22.30 | pacman87 | (08:10:33) brlcad: pacman87: yours is "Implementing Solid of Revolution and Sweep Primitives" |
| 18:23.47 | pacman87 | do i need to change anything? |
| 18:28.24 | starseek1r | brlcad: Would it be bad form to stick a libtread.c and libtread.h file in proc-db to hold tread definitions? |
| 18:29.02 | *** join/#brlcad d_rossberg (n=rossberg@bz.bzflag.bz) | |
| 18:32.22 | brlcad | pacman87: nope |
| 18:32.30 | brlcad | just a nod that it sounded okay with you |
| 18:32.39 | brlcad | but too late now, the announcements went out ;) |
| 18:48.06 | kwizart | http://koji.fedoraproject.org/koji/taskinfo?taskID=581443 |
| 18:48.15 | kwizart | ok still try to build ppc and ppc64 |
| 18:53.43 | brlcad | woot |
| 20:12.52 | *** join/#brlcad clock_ (n=clock@77-56-76-66.dclient.hispeed.ch) | |
| 20:41.47 | prasad_ | hates semaphores |
| 20:43.52 | CIA-20 | BRL-CAD: 03starseeker * r30818 10/brlcad/trunk/src/proc-db/tire.c: Replace lots of individual commands by a single loop for tread extrusion. |
| 20:46.57 | starseeker | loupci: Thanks, i'm good (sorry, getting the hang of irssi) |
| 20:54.20 | CIA-20 | BRL-CAD: 03starseeker * r30819 10/brlcad/trunk/src/proc-db/tire.c: Oops - fix the conditional checking for tread insertion. |
| 21:14.15 | *** join/#brlcad louipc_ (n=louipc@bas8-toronto63-1096782279.dsl.bell.ca) | |
| 21:22.33 | *** join/#brlcad hippieindamakin8 (n=hippiein@210.212.55.3) | |
| 22:05.11 | *** join/#brlcad andrecastelo (n=chatzill@189.71.75.27) | |
| 22:05.47 | andrecastelo | hey everyone |
| 23:50.54 | yukonbob | hey andrecastelo |