| 00:36.44 | *** join/#brlcad ibot (i=ibot@pdpc/supporter/active/TimRiker/bot/apt) |
| 00:36.45 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || Channel logs at http://ibot.rikers.org/%23brlcad/ || BRL-CAD is participating in the 2008 Google Summer of Code! || Release 7.12.4 is posted (source-only release) |
| 01:04.32 | *** join/#brlcad Twingy (n=justin@74.92.144.217) |
| 01:25.30 | *** join/#brlcad archivist (n=archivis@host81-149-119-172.in-addr.btopenworld.com) [NETSPLIT VICTIM] |
| 01:25.30 | *** join/#brlcad poolio (n=poolio@bz.bzflag.bz) [NETSPLIT VICTIM] |
| 01:26.14 | yukonbob | hello, cadheads |
| 01:27.19 | *** join/#brlcad archivist (n=archivis@host81-149-119-172.in-addr.btopenworld.com) [NETSPLIT VICTIM] |
| 01:27.19 | *** join/#brlcad poolio (n=poolio@bz.bzflag.bz) [NETSPLIT VICTIM] |
| 01:31.50 | *** join/#brlcad dtidrow_ (n=dtidrow@c-69-255-182-248.hsd1.va.comcast.net) [NETSPLIT VICTIM] |
| 01:31.50 | *** join/#brlcad louipc (n=louipc@76-10-146-181.dsl.teksavvy.com) [NETSPLIT VICTIM] |
| 01:34.10 | *** join/#brlcad ChanServ (ChanServ@services.) |
| 01:34.10 | *** join/#brlcad louipc (n=louipc@76-10-146-181.dsl.teksavvy.com) [NETSPLIT VICTIM] |
| 01:34.10 | *** join/#brlcad dtidrow_ (n=dtidrow@c-69-255-182-248.hsd1.va.comcast.net) [NETSPLIT VICTIM] |
| 01:34.10 | *** join/#brlcad punkrockgirl (n=Pandora@c-69-243-244-154.hsd1.mo.comcast.net) [NETSPLIT VICTIM] |
| 01:34.10 | *** mode/#brlcad [+o ChanServ] by irc.freenode.net |
| 01:36.06 | *** join/#brlcad MinuteElectron (n=MinuteEl@silentflame/member/pdpc.base.minuteelectron) [NETSPLIT VICTIM] |
| 01:36.06 | *** join/#brlcad ``Erik (i=erik@c-68-54-174-162.hsd1.md.comcast.net) [NETSPLIT VICTIM] |
| 01:37.57 | *** join/#brlcad MinuteElectron (n=MinuteEl@silentflame/member/pdpc.base.minuteelectron) [NETSPLIT VICTIM] |
| 01:37.57 | *** join/#brlcad ``Erik (i=erik@c-68-54-174-162.hsd1.md.comcast.net) [NETSPLIT VICTIM] |
| 01:39.10 | *** join/#brlcad brlcad (n=sean@pdpc/supporter/silver/brlcad) |
| 01:39.10 | *** join/#brlcad SWPadnos (n=Me@emc/developer/SWPadnos) [NETSPLIT VICTIM] |
| 01:39.10 | *** join/#brlcad yukonbob (i=1000@s142-179-54-198.bc.hsia.telus.net) [NETSPLIT VICTIM] |
| 01:39.10 | *** join/#brlcad starseeker (n=starseek@bz.bzflag.bz) [NETSPLIT VICTIM] |
| 01:39.10 | *** join/#brlcad cosurgi (i=janek@irc.cool.waw.pl) [NETSPLIT VICTIM] |
| 01:39.10 | *** mode/#brlcad [+o brlcad] by irc.freenode.net |
| 01:41.38 | *** join/#brlcad pacman87 (n=timothy@71.170.63.120) [NETSPLIT VICTIM] |
| 01:52.20 | *** join/#brlcad Axman6 (n=Axman6@pdpc/supporter/student/Axman6) [NETSPLIT VICTIM] |
| 01:52.20 | *** join/#brlcad b0ef (n=b0ef@062016141231.customer.alfanett.no) [NETSPLIT VICTIM] |
| 03:01.47 | *** join/#brlcad geocalc (n=geocalc@dyn-91-171-218-91.ppp.tiscali.fr) |
| 03:03.37 | geocalc | ./.libs/librt.so: undefined reference to `TclReFree' |
| 03:04.58 | pacman87 | geocalc: did you do ./configure --enable-all? |
| 03:05.14 | geocalc | no |
| 03:08.35 | geocalc | same error pacman87 |
| 03:09.27 | pacman87 | what version is your system tcl/tk? |
| 03:10.07 | pacman87 | are you using svn current? |
| 03:11.06 | geocalc | 8.5.2 pacman87 no svn |
| 03:11.37 | pacman87 | what OS? |
| 03:12.09 | geocalc | paldo linux 64 bits |
| 03:13.44 | pacman87 | geocalc: i guess you'll have to stick around until someone who knows what they're doing shows up |
| 03:13.58 | pacman87 | ./configure --enable-all fixed for me |
| 03:14.35 | geocalc | hah ok thanks pacman87 |
| 03:28.44 | brlcad | geocalc: you have to make clean after the enable-all |
| 03:28.54 | brlcad | else there are still object files with the bad reference |
| 03:29.31 | brlcad | the other quick fix to that problem is to edit src/librt/regionfix.c and add "#undef regfree" after the #include's |
| 03:29.42 | geocalc | i see thanks |
| 03:33.17 | brlcad | tcl screws up a header |
| 04:09.18 | brlcad | pacman87: fyi, traced down at least one of the existing spline curve structures: struct edge_g_cnurb in nmg.h |
| 04:14.19 | *** join/#brlcad pacman87 (n=timothy@71.170.63.120) [NETSPLIT VICTIM] |
| 04:14.22 | *** part/#brlcad pacman87 (n=timothy@71.170.63.120) |
| 04:14.22 | *** join/#brlcad pacman87 (n=timothy@71.170.63.120) |
| 04:14.36 | brlcad | that would be a viable C approach, for C++ openNURBS provides a variety like ON_BezierCurve and ON_NurbsCurve |
| 04:14.50 | pacman87 | did i miss something? |
| 04:15.01 | brlcad | mebbie |
| 04:15.09 | brlcad | 00:09 <@brlcad> pacman87: fyi, traced down at least one of the existing spline curve structures: struct edge_g_cnurb in nmg.h |
| 04:19.44 | brlcad | anim and tracker were useless curves |
| 04:22.37 | brlcad | so that basically leaves you those c or c++ structures, either would be good for sweep .. probably making the curve be part of sweep (instead of sweep referring to one object for the sketch and another nmg or brep object for the curve |
| 04:23.24 | *** join/#brlcad elite01 (n=elite01@dslb-088-071-040-234.pools.arcor-ip.net) |
| 04:23.37 | pacman87 | ok, that was a question i had for sweep |
| 04:23.43 | pacman87 | whether the path would be seperate |
| 04:27.49 | brlcad | I think it can be down either way, but I see that more as being the values of the sweep |
| 04:28.17 | brlcad | it's not like we're going to sweep over anything else (although that does give rise to some interesting ideas) |
| 04:29.00 | pacman87 | well, if it's seperate, you could edit the path, or have 'parallel' sweeps using the same path and different start points |
| 04:29.14 | pacman87 | *edit the path seperately |
| 04:30.04 | brlcad | you could still conceivably edit it separately, I'm just not sure what that buys you |
| 04:30.22 | brlcad | given we *don't* presently allow editing of any non-solid geometry in 3D |
| 04:30.48 | brlcad | closest is the sketch, but that kicks off a separate 2D editor |
| 04:31.01 | pacman87 | what i meant was if you change the path, the both of your 'parallel |
| 04:31.08 | pacman87 | ' sweeps would change |
| 04:31.15 | brlcad | nods |
| 04:32.41 | brlcad | you can do it that way, I wouldn't object, but I'm just not convinced that flexibility is worth the complexity myself |
| 04:33.44 | brlcad | as you'd have to decide whether you're going to use bspline or brep objects (probably the latter if you go the object-route), and validate that it's just one curve (or maybe set of curves) |
| 04:33.57 | brlcad | if it's internal, it is what it is |
| 04:34.10 | brlcad | no chance for it to be invalid |
| 04:34.26 | pacman87 | checked on creation instead of import? |
| 04:34.41 | brlcad | que? |
| 04:35.23 | pacman87 | you're saying i could use the structure internally |
| 04:35.59 | pacman87 | if i have to limit the path to degree 2, then the internal structure could concievably be bad |
| 04:36.13 | geocalc | This probably means that tk wasn't installed properly. brlcad ? |
| 04:36.15 | brlcad | the options are a) sweep uses sketch and bspline, b) sweep uses sketch and brep, c) sweep uses sketch and internal spline |
| 04:37.02 | brlcad | geocalc: no it doesn't mean that .. it's just a bug in one of their headers, a really obscure one that only affects folks that seach them as a header search path |
| 04:37.29 | brlcad | the "problem" is that a) and b) can have a hell of a lot more in them than splines .. they're general brep containers |
| 04:37.48 | brlcad | not that the spline itself may be invalid if you have some constraints that have to be imposed |
| 04:38.03 | brlcad | the spline itself could be conceivably bad with a, b, or c |
| 04:38.09 | brlcad | that much is constant |
| 04:39.12 | brlcad | c) just gets rid of the generalized container, so you don't have to "validate" the bspline/brep |
| 04:39.48 | brlcad | it's not a huge deal, I think any of the three are perfectly viable |
| 04:40.52 | brlcad | my own inclination would probably be b) or c) leaning slightly to c) but using the nmg struct in a) internally during prep |
| 05:01.59 | geocalc | so brlcad to use mged i must recompile ? |
| 05:27.05 | *** join/#brlcad Mouette (n=root@fw1.phys.sinica.edu.tw) |
| 05:47.21 | *** join/#brlcad clock_ (n=clock@77-56-93-118.dclient.hispeed.ch) |
| 06:57.10 | *** join/#brlcad clock_ (n=clock@zux221-122-143.adsl.green.ch) |
| 08:14.57 | *** join/#brlcad dtidrow_ (n=dtidrow@c-69-255-182-248.hsd1.va.comcast.net) |
| 08:29.39 | *** join/#brlcad geocalc (n=geocalc@dyn-91-171-218-91.ppp.tiscali.fr) [NETSPLIT VICTIM] |
| 08:29.39 | *** join/#brlcad archivist (n=archivis@host81-149-119-172.in-addr.btopenworld.com) [NETSPLIT VICTIM] |
| 08:29.39 | *** join/#brlcad poolio (n=poolio@bz.bzflag.bz) [NETSPLIT VICTIM] |
| 09:49.25 | *** join/#brlcad Elperion (n=Bary@p5B14CB61.dip.t-dialin.net) |
| 10:40.51 | *** join/#brlcad mafm (n=mafm@elnet-111.lip.pt) |
| 10:41.22 | mafm | hi |
| 10:43.24 | CIA-22 | BRL-CAD: 03mafm * r31606 10/rt^3/trunk/src/g3d/ (6 files): Making the top panel visible, although not very elegantly. Cleanup of unused functions. |
| 10:44.37 | *** join/#brlcad elite01 (n=elite01@dslb-088-071-040-234.pools.arcor-ip.net) |
| 11:01.08 | *** join/#brlcad archivist (n=archivis@host81-149-119-172.in-addr.btopenworld.com) |
| 12:02.28 | CIA-22 | BRL-CAD: 03d_rossberg * r31607 10/brlcad/trunk/src/librt/Makefile.am: every file has to be mentioned here: added revolve.h |
| 12:04.11 | CIA-22 | BRL-CAD: 03d_rossberg * r31608 10/brlcad/trunk/src/librt/CMakeLists.txt: beginning of revolve primitive: added revolve.c |
| 12:04.32 | *** join/#brlcad d_rossberg (n=rossberg@bz.bzflag.bz) |
| 12:06.06 | brlcad | geocalc: yep |
| 12:32.16 | mafm | meh |
| 12:32.23 | mafm | silly ogre :P |
| 12:32.44 | mafm | g3d: ../../OgreMain/include/OgreSingleton.h:66: Ogre::Singleton<T>::Singleton() [with T = Ogre::Root]: Assertion `!ms_Singleton' failed. |
| 12:40.50 | starseeker | brlcad: Ah, now I remember why I was so baffled by the gdb backtrace on iges-g: http://paste.bzflag.bz/m6e1dc5ed |
| 12:46.48 | brlcad | starseeker: that's an optimized build, you need/want a debug build (probably not a /usr/brlcad install unless you install there yourself) |
| 12:47.47 | brlcad | mafm: looks like someone deleted a singleton |
| 12:49.08 | ``Erik | flatulates with vigor |
| 12:52.42 | mafm | apparently you can get that kind of errors also because of linking issues |
| 12:54.22 | *** join/#brlcad thing0 (n=ric@123.208.12.102) |
| 13:03.10 | CIA-22 | BRL-CAD: 03bob1961 * r31609 10/brlcad/trunk/ (include/bu.h src/libbu/bu_tcl.c src/libbu/parse.c): bu_tcl_structparse_argv has been modified to use the new bu_structparse_argv (No Tcl here. It write log messages to a vls.) |
| 13:04.51 | starseeker | odd, I didn't enable optimization |
| 13:06.04 | starseeker | explicitly enables debug |
| 13:11.37 | brlcad | starseeker: hm, then that may just be stack stompage |
| 13:11.47 | brlcad | put a break on something like bu_log |
| 13:11.51 | brlcad | then to a bt |
| 13:11.54 | brlcad | see if you see symbols |
| 13:12.12 | starseeker | is rebuilding with explicit debug support too |
| 13:12.20 | brlcad | do you install into /usr/brlcad ? |
| 13:12.24 | starseeker | yes |
| 13:12.54 | brlcad | radmind wipes that out every night if you're not exempted (and the one it puts in place is optimized) |
| 13:13.10 | starseeker | I'm on my home box right now |
| 13:13.15 | brlcad | ah, k :) |
| 13:13.27 | starseeker | If radmind is wiping THIS box, I'm scared ;-) |
| 13:13.28 | brlcad | then .. *maybe* that's not the problem *smirk* |
| 13:13.41 | brlcad | try the bt |
| 13:14.14 | brlcad | if you see a valid backtrace, then you're good and you can just try to pinpoint the crash-point |
| 13:14.47 | brlcad | e.g. put a break on the file:line that is printing "Converting NURB entities" and step from there |
| 13:15.22 | starseeker | does some quick checking and gdb 101 review... |
| 13:18.01 | brlcad | break {functionname|file:line} |
| 13:18.04 | brlcad | run |
| 13:18.13 | brlcad | bt |
| 13:18.38 | starseeker | erm. It's saying no source file named convsurv.c - does it need the full path? |
| 13:19.20 | brlcad | surv? |
| 13:19.32 | starseeker | That's the iges conversion source file with the NURB message |
| 13:19.44 | starseeker | when I try to set the break |
| 13:19.51 | starseeker | feels like such a noob... |
| 13:20.02 | brlcad | surV? |
| 13:20.28 | starseeker | ah |
| 13:20.29 | starseeker | sorry |
| 13:20.35 | starseeker | smacks self |
| 13:20.56 | brlcad | all your surv are belong to surfers |
| 13:20.59 | ``Erik | poo, src/libpc/ fails to compile |
| 13:21.26 | brlcad | yeah, I was going to smack dawn |
| 13:21.49 | brlcad | it needs CPPFLAG love in configure.ac |
| 13:22.11 | brlcad | to add src/other if it needs non-system boost |
| 13:23.00 | ``Erik | heh, removing libpc from the build dirs in Makefile works fine for my needs |
| 13:24.37 | ``Erik | hehehe "s/global warming/heated orb terror syndrom/g" |
| 13:25.19 | starseeker | ah hah - it's failing on mk_bspline |
| 13:26.39 | CIA-22 | BRL-CAD: 03brlcad * r31610 10/brlcad/trunk/src/libpc/Makefile.am: unbreak the build, it needs src/other as an include path .. temp hack that someone(tm) needs to fix. |
| 13:27.27 | starseeker | is now into libwdb's nurb.c |
| 13:32.43 | starseeker | fails at line 64 - returning the export |
| 13:50.33 | starseeker | ok, down to line 318 in wdb_put_internal... |
| 13:55.28 | mafm | hmm |
| 13:55.39 | mafm | I have an strange problem here, maybe somebody can help |
| 13:56.11 | mafm | I instantiate Ogre::Root (the mother of all the lambs), and this class has a singleton |
| 13:57.03 | mafm | when I try to get a pointer to the renderwindow, it works if I call the singleton, but not if I do it indirectly through the pointer of the created root |
| 13:57.12 | mafm | does this make any sense for you? |
| 13:57.41 | mafm | I don't know why they make a singleton when you can create the object separately, for a start... |
| 14:01.18 | starseeker | down to rt_nurb_free_snurb... |
| 14:09.28 | brlcad | mafm: it seems weird (wrong?) that you'd ever want or need to direction instantiate a base class |
| 14:09.34 | brlcad | s/direction/directly/ |
| 14:10.14 | brlcad | they could/should prevent that if it wasn't desirable, but there may have been some reason to allow it .. still seems pretty odd |
| 14:10.39 | mafm | well, OGRE allows it (i.e. the constructor is not protedted or private), and it seems to be required as the only way to pass configuration parameters |
| 14:11.11 | mafm | http://www.ogre3d.org/docs/api/html/classOgre_1_1Root.html#Ogre_1_1Roota0 |
| 14:12.32 | CIA-22 | BRL-CAD: 03brlcad * r31611 10/brlcad/trunk/sh/tracker.sh: dunno why the minuses were being escaped |
| 14:12.52 | mafm | I need that because we ship a configuration file with the plugins we need |
| 14:13.14 | mafm | so it's a system-wide file installed in /usr/local |
| 14:13.25 | starseeker | brlcad: OK, here's as far as I've been able to drill: http://paste.bzflag.bz/m81591bf |
| 14:14.08 | brlcad | mafm: *nod*, doesn't make it any less odd ;) |
| 14:14.57 | mafm | but you mean that it's odd what I'm doing or what they're doing? |
| 14:15.08 | brlcad | yes :) |
| 14:15.22 | mafm | that's not a yes-no question :P |
| 14:15.41 | starseeker | tables the problem temporarily to head in... |
| 14:15.50 | brlcad | i don't doubt that you need to, them making you need to is odd, them making an api that requires instantiating a base class is .. weird |
| 14:16.12 | mafm | I think that they make it too complex with their template and inheritance trickery is causing the problem |
| 14:16.34 | mafm | and I don't know what's the way out of the pit |
| 14:17.06 | starseeker | so I have it, here's the path from main down to the wipeout: http://paste.bzflag.bz/m5429c1a8 |
| 14:17.11 | brlcad | starseeker: mm, rt_nurb_free_snurb() being called with a null resource structure could be a problem |
| 14:17.14 | mafm | unless I start accessing directly Ogre::Root:getSingleton() in all the GUI windows/classes |
| 14:17.39 | starseeker | will try it on the mac and see if things look difference once I'm in |
| 14:18.38 | brlcad | starseeker: ever used valgrind? |
| 14:18.48 | starseeker | no, unfortunately :-( |
| 14:18.55 | brlcad | that might pinpoint the problem, it's great at finding memory issues |
| 14:19.06 | starseeker | checks to see if he has valgrind |
| 14:19.24 | brlcad | and this seems to be one, the fact that it crashes after free() just probably means it was asked to free something that it shouldn't have |
| 14:19.38 | brlcad | or that something went wrong earlier |
| 14:20.05 | brlcad | valgrind is predominantly best on x86 linux, so should be easy to get |
| 14:20.09 | brlcad | it's really easy to use |
| 14:20.14 | starseeker | cool :-) |
| 14:20.24 | brlcad | mafm: any hint from the ogre devs? |
| 14:20.27 | starseeker | is installing ebuild now |
| 14:20.36 | brlcad | it's been a long while since I played with the samples |
| 14:20.41 | mafm | nobody replies me in the IRC |
| 14:20.54 | brlcad | their devs mostly work off their forums |
| 14:21.04 | mafm | I guess that I could write them, but it'll take days |
| 14:21.07 | brlcad | steve doesn't like irc :) |
| 14:21.21 | brlcad | they're actually pretty responsive every time I've interacted |
| 14:21.36 | mafm | and they point to the linking issues in the FAQs, so I guess that they'll stick to that explanation |
| 14:21.36 | brlcad | forums are a lot different when all your core guys predominantly use it |
| 14:21.50 | mafm | http://www.ogre3d.org/wiki/index.php/CommonMistakes#Exceptions_and_Asserts |
| 14:22.53 | starseeker | considers using this experience to write up an example based "debugging for dummies" |
| 14:23.45 | brlcad | mafm: that faq entry leads me to believe that there's a plugin instantiating the root as well |
| 14:23.47 | starseeker | has valgrind now |
| 14:24.05 | mafm | http://www.ogre3d.org/docs/api/html/OgreSingleton_8h-source.html |
| 14:24.21 | mafm | starseeker: just "valgrind binary-of-the-program" |
| 14:25.03 | mafm | scared of the pointer trickey :) |
| 14:25.45 | mafm | and the compiler pragmas as well |
| 14:26.37 | CIA-22 | BRL-CAD: 03brlcad * r31612 10/brlcad/trunk/sh/news2tracker.sh: maybe a \t got stripped at some point, just leaving the slash. either way, clean up. |
| 14:27.31 | brlcad | mafm: that's a pretty basic singleton |
| 14:27.53 | brlcad | it's quite flawed for many purposes, but decent enough |
| 14:29.13 | brlcad | much better: http://bzflag.svn.sourceforge.net/viewvc/bzflag/trunk/bzflag/include/Singleton.h?revision=16429&view=markup |
| 14:30.11 | brlcad | automatic cleanup, prevents accidental instantiation, simple initialization .. and with just a couple extra params you can extend it to multithreading or other allocation mechanisms |
| 14:31.46 | brlcad | i wrote that several years ago, one of the most reused pieces of code I've ever written |
| 14:34.23 | starseeker | hmm - valgrind internal error |
| 14:34.36 | mafm | no good :) |
| 14:35.41 | mafm | <PROTECTED> |
| 14:35.41 | mafm | <PROTECTED> |
| 14:36.08 | mafm | things strange with singletons, they do :) |
| 14:36.48 | brlcad | yeah, looks like they're of the explicit creation/destruction camp |
| 14:37.11 | brlcad | silly for many reasons |
| 14:37.19 | brlcad | c'est la vie |
| 14:47.44 | starseeker | Here's what valgrind did with it: http://paste.bzflag.bz/m78e64646 |
| 14:48.01 | starseeker | REALLY needs to get going... |
| 14:51.40 | mafm | starseeker: you might try to see what the last lines before the warnings are doing |
| 14:51.46 | mafm | in example: spline (spline.c:120) |
| 14:52.02 | mafm | at that position of that file, something seems to be going wrong |
| 14:52.26 | mafm | writing to a non-allocated place of memory, or something like that |
| 14:54.48 | brlcad | yeah, there's lots of goodies/nasties in that report |
| 15:04.20 | starseeker | 's first guess based on this would be checking the various data structures and the memory allocation for said structures? |
| 15:08.14 | mafm | starseeker: http://rafb.net/p/B8SFmg93.html |
| 15:08.50 | mafm | in the first case of printf trying to read an dangling pointer, you get this: |
| 15:08.56 | mafm | Use of uninitialised value of size 8 |
| 15:09.22 | mafm | then I try to assign it a value, writing to that position: |
| 15:09.24 | mafm | Invalid write of size 4 |
| 15:10.04 | mafm | so in the lines of spline.c, you should try to see which variable you're accessing, and if was properly created (and not deleted in the meantime) |
| 15:10.08 | starseeker | Right - so in the case of valgrind it diesn't like (*b_patch)->v.knots[i] -= min_knot; |
| 15:10.19 | mafm | sometimes you get chained problems, when some memory overwrites other |
| 15:11.16 | mafm | for a simple debugging procedure, you might try to access different parts of that line, to see where's the problem |
| 15:11.19 | starseeker | looks for the structural definition of face_g_snurb |
| 15:11.50 | mafm | maybe it's that i runs too far away in the vector (trying to access beyond the created elements) |
| 15:16.25 | starseeker | is thinking this looks like pointer fun... |
| 15:21.46 | starseeker | OK, knot vector is using fastf_t for its array type and min_knot is a fastf_t, so that's OK... |
| 15:25.23 | starseeker | OK, this is interesting - the FIRST call to rt_nurb_free_snurb succeeds |
| 15:25.32 | starseeker | it's only the second that fails |
| 15:25.38 | starseeker | I wonder what the difference is... |
| 15:26.36 | CIA-22 | BRL-CAD: 03mafm * r31613 10/rt^3/trunk/src/g3d/ (Application.cxx Application.h GuiWindowManager.cxx): Miscellaneous reorganization of code and cleanup. |
| 15:29.24 | mafm | well, it's not always straightforward |
| 15:29.43 | mafm | sometimes you even get completely mad errors due to stack overruns and things like that |
| 15:37.26 | clock_ | or shooting into the memory |
| 15:37.46 | starseeker | scowls at the C programming language... |
| 15:37.50 | clock_ | running out of an array overwrites some global variables and a complex behaviour can result. |
| 15:38.10 | clock_ | starseeker: I suggest to scowl at wrongly programmed programs |
| 15:38.28 | clock_ | make sure your algorithm is correct and your program is written correctly and typed in correctly |
| 15:38.33 | clock_ | and then you won't encounter any bugs |
| 15:38.47 | starseeker | That too, but mucking at such a low level except when no alternative exists is just annoying |
| 15:39.00 | clock_ | once a colleague decreased some constant which was hard assumed to be 2 in the kernel |
| 15:39.02 | starseeker | didn't write this one anyway |
| 15:39.10 | clock_ | and a behavour resulted that emulated a faulty pipeline in the CPU |
| 15:39.24 | clock_ | since the CPU has already one instruction faulty I was investigating that |
| 15:39.34 | starseeker | nice |
| 15:39.36 | clock_ | and after a month or two of false track I managed to find the source of the problem |
| 15:40.02 | clock_ | starseeker: you can check if it's correct. The universe will collapse 3 times in between, but it's possible :) |
| 15:40.26 | starseeker | decides to eat lunch first... |
| 15:40.30 | starseeker | back later |
| 15:41.11 | clock_ | the morale of this story: do not write bad programs |
| 15:41.17 | clock_ | always make only correct ones |
| 16:43.44 | pacman87 | rt_gettree_leaf(rev): prep failure |
| 16:43.44 | pacman87 | db_walk_subtree() FAIL on '/rev' |
| 16:55.31 | ``Erik | heh, that sounds about as useful as my statemeny, clock... "don't put the bugs in the code in the first place, then you won't have to debug" ... :D |
| 16:55.50 | ``Erik | and don't scowl at C, it's a fantastic language for what it was designed for... writing kernels and drivers. |
| 16:57.03 | poolio | wanders off to implement BREP support in Matlab |
| 17:04.15 | *** join/#brlcad dtidrow (n=dtidrow@c-69-255-182-248.hsd1.va.comcast.net) [NETSPLIT VICTIM] |
| 17:04.15 | *** join/#brlcad pacman87 (n=timothy@71.170.63.120) [NETSPLIT VICTIM] |
| 17:09.16 | *** join/#brlcad archivist (n=archivis@host81-149-119-172.in-addr.btopenworld.com) [NETSPLIT VICTIM] |
| 17:09.16 | *** join/#brlcad elite01 (n=elite01@dslb-088-071-040-234.pools.arcor-ip.net) [NETSPLIT VICTIM] |
| 17:09.16 | *** join/#brlcad geocalc (n=geocalc@dyn-91-171-218-91.ppp.tiscali.fr) [NETSPLIT VICTIM] |
| 17:09.16 | *** join/#brlcad poolio (n=poolio@bz.bzflag.bz) [NETSPLIT VICTIM] |
| 17:10.19 | *** join/#brlcad brlcad (n=sean@pdpc/supporter/silver/brlcad) [NETSPLIT VICTIM] |
| 17:10.19 | *** join/#brlcad pacman87 (n=timothy@71.170.63.120) [NETSPLIT VICTIM] |
| 17:10.19 | *** join/#brlcad dtidrow (n=dtidrow@c-69-255-182-248.hsd1.va.comcast.net) [NETSPLIT VICTIM] |
| 17:10.19 | *** join/#brlcad mafm (n=mafm@elnet-111.lip.pt) [NETSPLIT VICTIM] |
| 17:10.19 | *** join/#brlcad clock_ (n=clock@zux221-122-143.adsl.green.ch) [NETSPLIT VICTIM] |
| 17:10.19 | *** join/#brlcad b0ef (n=b0ef@062016141231.customer.alfanett.no) [NETSPLIT VICTIM] |
| 17:10.19 | *** join/#brlcad Axman6 (n=Axman6@pdpc/supporter/student/Axman6) [NETSPLIT VICTIM] |
| 17:10.19 | *** join/#brlcad cosurgi (i=janek@irc.cool.waw.pl) [NETSPLIT VICTIM] |
| 17:10.20 | *** join/#brlcad starseeker (n=starseek@bz.bzflag.bz) [NETSPLIT VICTIM] |
| 17:10.20 | *** join/#brlcad yukonbob (i=1000@s142-179-54-198.bc.hsia.telus.net) [NETSPLIT VICTIM] |
| 17:10.20 | *** join/#brlcad SWPadnos (n=Me@emc/developer/SWPadnos) [NETSPLIT VICTIM] |
| 17:10.20 | *** join/#brlcad ``Erik (i=erik@c-68-54-174-162.hsd1.md.comcast.net) [NETSPLIT VICTIM] |
| 17:10.20 | *** join/#brlcad MinuteElectron (n=MinuteEl@silentflame/member/pdpc.base.minuteelectron) [NETSPLIT VICTIM] |
| 17:10.20 | *** join/#brlcad punkrockgirl (n=Pandora@c-69-243-244-154.hsd1.mo.comcast.net) [NETSPLIT VICTIM] |
| 17:10.20 | *** join/#brlcad louipc (n=louipc@76-10-146-181.dsl.teksavvy.com) [NETSPLIT VICTIM] |
| 17:10.20 | *** join/#brlcad ChanServ (ChanServ@services.) |
| 17:10.20 | *** join/#brlcad vedge (n=vedge@205-237-251-204.ilesdelamadeleine.ca) [NETSPLIT VICTIM] |
| 17:10.20 | *** join/#brlcad PrezKennedy (i=Matthew@whitecalf.net) [NETSPLIT VICTIM] |
| 17:10.20 | *** join/#brlcad CIA-22 (n=CIA@208.69.182.149) [NETSPLIT VICTIM] |
| 17:10.20 | *** join/#brlcad alex_joni (n=juve@emc/board-of-directors/alexjoni) [NETSPLIT VICTIM] |
| 17:10.20 | *** mode/#brlcad [+oo brlcad ChanServ] by irc.freenode.net |
| 17:12.14 | poolio | Gee, that was fun ;) |
| 17:13.54 | *** join/#brlcad archivist (n=archivis@host81-149-119-172.in-addr.btopenworld.com) [NETSPLIT VICTIM] |
| 17:13.54 | *** join/#brlcad elite01 (n=elite01@dslb-088-071-040-234.pools.arcor-ip.net) [NETSPLIT VICTIM] |
| 17:13.54 | *** join/#brlcad geocalc (n=geocalc@dyn-91-171-218-91.ppp.tiscali.fr) [NETSPLIT VICTIM] |
| 17:13.54 | *** join/#brlcad poolio (n=poolio@bz.bzflag.bz) [NETSPLIT VICTIM] |
| 17:26.34 | CIA-22 | BRL-CAD: 03mafm * r31614 10/rt^3/trunk/src/g3d/ (5 files): Connecting CommandOverlay with history, so both it and the console have the same effect. Also made the History a Singleton to keep this consistency. |
| 18:33.39 | CIA-22 | BRL-CAD: 03pacman87 * r31615 10/brlcad/trunk/src/librt/primitives/extrude/extrude.c: ws |
| 18:34.40 | CIA-22 | BRL-CAD: 03pacman87 * r31616 10/brlcad/trunk/ (5 files in 4 dirs): more work on revolve |
| 18:34.59 | pacman87 | probably should've used a better commit message |
| 18:38.05 | mafm | maybe :D |
| 18:43.02 | CIA-22 | BRL-CAD: 03mafm * r31617 10/rt^3/trunk/src/g3d/ (6 files): Adding listeners to History events, so in example commands entered in CommandOverlay get logged in the panel of the console. |
| 18:46.14 | mafm | I go now, take care |
| 18:46.18 | pacman87 | bye |
| 19:26.10 | *** join/#brlcad dtidrow (n=dtidrow@c-69-255-182-248.hsd1.va.comcast.net) |
| 19:32.34 | *** join/#brlcad clock_ (n=clock@77-56-95-203.dclient.hispeed.ch) |
| 20:17.13 | starseeker | Phooey. The iges-g bug does not appear on the Mac |
| 20:17.41 | starseeker | Amusingly, however, it does cause an attempted raytrace in mged to die with an abort trap error |
| 21:07.56 | ``Erik | keeps laughing at http://www.explosm.net/comics/1324/ for some reason |
| 21:16.14 | *** join/#brlcad jgay (n=jgay@fsf/staff/jgay) |
| 21:17.33 | jgay | Hey, anybody want to be attached to a really interesting discussion thread happening about the creation of a "mozilla foundation for government contractors" |
| 21:17.40 | jgay | brlcad: ^^? |
| 22:50.35 | CIA-22 | BRL-CAD: 03homovulgaris * r31618 10/brlcad/trunk/src/libpc/ (6 files): Stage 2/4 towards binary constraint solver: Constraint class definition, refinement of certain Variable and Network members and methods |
| 23:05.59 | pacman87 | how do you set the background color for a raytrace? |