| 00:00.08 | tc-rucho | oh |
| 00:00.08 | brlcad | help view opendb closedb tra |
| 00:00.11 | brlcad | it'll give help on command(s) |
| 00:00.15 | tc-rucho | I see |
| 00:00.17 | brlcad | like man a b c |
| 00:00.23 | tc-rucho | but how to get help about suboptions of a command? |
| 00:00.45 | brlcad | there is no suboption help for that command |
| 00:00.50 | brlcad | but all is not lost |
| 00:00.56 | brlcad | notice the get/set |
| 00:01.07 | brlcad | run any one of those without arguments and it'll get the current value |
| 00:01.15 | brlcad | run with args and it'll set |
| 00:02.04 | tc-rucho | got it |
| 00:02.06 | tc-rucho | one more thing |
| 00:02.08 | brlcad | now the kicker, the 'ae' command does exactly the same |
| 00:02.20 | brlcad | if you run ae, how many numbers you see? |
| 00:02.34 | brlcad | guess which one is twist ;) |
| 00:03.01 | tc-rucho | how am I supposed to guess what do {eye, ypr, quat, aet} stand for? I know aet now, but how about the others? |
| 00:03.26 | brlcad | those are documented in the mged tutorial series |
| 00:03.36 | brlcad | one of the appendices |
| 00:03.41 | tc-rucho | mged> ae 45 45 0 |
| 00:03.43 | tc-rucho | mged> ae |
| 00:03.45 | tc-rucho | 45 45 -4.07111e-15 |
| 00:03.48 | tc-rucho | ^ wtf? lol |
| 00:03.58 | brlcad | they are also on the mged help menu somewhere |
| 00:04.02 | tc-rucho | I would expect it to return 45 45 0 |
| 00:04.30 | brlcad | that's basic x86 floating point unit behavior |
| 00:05.07 | brlcad | it can't exactly represent most integer values, that was the closest approximation |
| 00:05.26 | brlcad | far beyond numerical computation tolerance, mged just lets you know what the hardware did |
| 00:05.56 | tc-rucho | ok, I think I'm done asking stuff for now. Just one more thing. When I raytrace something it stays as a background image and no clue how to erase it, tried the 'fbclear' button in the raytrace menu but got an ugly 'command not found'. Any hint? |
| 00:06.05 | tc-rucho | maybe I have to check something in my path |
| 00:06.22 | brlcad | another place you can find more help on some of the commands, there's an mged quick reference card on the website under docs |
| 00:06.26 | ``Erik | export PATH=$PATH:/usr/brlcad/bin |
| 00:07.04 | brlcad | yeah, run that before you run mged and it should fix it - what version are you using? |
| 00:10.38 | ``Erik | wow... just... wow... http://www.collegehumor.com/picture:1900391 |
| 00:13.20 | tc-rucho | 7.10.4 |
| 00:17.53 | tc-rucho | it would be really cool if brlcad had something like 'man' for a detailed explanation of every option available for a command (does it have it and I didn't notice?) |
| 00:18.58 | tc-rucho | oh yeah |
| 00:19.14 | tc-rucho | it does have a manpage for each command |
| 00:19.24 | brlcad | there are manpages for most of the external commands |
| 00:19.26 | tc-rucho | just that doesn't seem to be accessible from the mged |
| 00:19.30 | brlcad | yeah |
| 00:19.31 | tc-rucho | yeah, just noticed |
| 00:19.40 | brlcad | brlman will search the /usr/brlcad manpath |
| 00:19.54 | brlcad | but you'll get better results if you just set your MANPATH |
| 00:20.18 | brlcad | we're working on having more detailed "manpages" for all of the mged commands too, that's just a hell of a lot of work |
| 00:21.39 | tc-rucho | I know, maybe I will help with that in the future, but I first need to get the hang of brlcad, it's like drawing using assembly language |
| 00:21.48 | tc-rucho | no fancy mouse thing |
| 00:21.58 | brlcad | at least not until you're a lot more proficient |
| 00:22.17 | brlcad | there are lots of various shortcuts for most tasks, but it's way too much to get into for new users |
| 00:22.24 | brlcad | just gets confusing before you learn the basics |
| 00:22.30 | ``Erik | for a in `mged -c blah.g 'echo $MGED_CMDS'` ; do echo "Things and stuff" > $a.help ; done |
| 00:22.40 | ``Erik | :D *duck* |
| 00:23.10 | ``Erik | sorry, I'll behave :) |
| 00:23.36 | brlcad | tc-rucho: if you do get interested in helping out with the docs, there are about 100 external commands that don't have manpages yet (listed in the TODO file iirc), and pretty much most/all of the mged commands need to be expanded for manpage format |
| 00:25.00 | tc-rucho | yeah, but first I need to decide whether or not brlcad is a good solution for my needs. |
| 00:25.07 | brlcad | sure |
| 00:25.22 | brlcad | if it's not a good solution, always looking for good hands to help make it one ;) |
| 00:25.27 | brlcad | open dev team |
| 00:25.47 | tc-rucho | good (: |
| 00:27.40 | tc-rucho | would love brlcad if it had some lisp dialect [instead of tcl] (what's between brackets it's optional) |
| 00:28.14 | *** join/#brlcad ChanServ (ChanServ@services.) |
| 00:28.14 | *** mode/#brlcad [+o ChanServ] by irc.freenode.net |
| 00:28.19 | CIA-40 | BRL-CAD: 03brlcad * r33885 10/brlcad/trunk/src/libbn/tcl.c: clamp all floating point values being printed to a string to a corresponding integer value if the number is within hardware computational tolerance. the user probably wanted and expects 42 instead of 41.9999999999997. |
| 00:31.09 | CIA-40 | BRL-CAD: 03brlcad * r33886 10/brlcad/trunk/NEWS: |
| 00:31.09 | CIA-40 | BRL-CAD: clamp even more values to the closest corresponding integer if they're within |
| 00:31.09 | CIA-40 | BRL-CAD: hardware tolerance. this change was made in response to unexpected behavior |
| 00:31.09 | CIA-40 | BRL-CAD: reported by a new user (tc-rucho) learning to use various view manipulation |
| 00:31.10 | CIA-40 | BRL-CAD: commands. the effect of this change should be pretty pervasive to most mged |
| 00:31.12 | CIA-40 | BRL-CAD: commands that utilize the libbn routines for printing numbers to strings (ae |
| 00:31.14 | CIA-40 | BRL-CAD: being one example). |
| 00:32.56 | tc-rucho | brlcad: I think using fractions for internal calcs and then converting to float for UI output would avoid a lot of float weirdness |
| 00:33.29 | brlcad | heh |
| 00:33.48 | brlcad | it sure would |
| 00:33.55 | tc-rucho | (: |
| 00:34.28 | brlcad | it'd also be approximately three orders of magnitude slower for most operations :) |
| 00:34.49 | brlcad | not to mention require a pretty pervasive data type change throughout |
| 00:35.18 | tc-rucho | it's always like this T_T |
| 00:35.33 | tc-rucho | friggin floats |
| 00:35.36 | brlcad | (we're talking about affecting something on the order of a quarter-million lines of code) |
| 00:36.07 | tc-rucho | ugh |
| 00:36.17 | brlcad | it's much easier to just test the number and print it cleanly, and account for floating point fuzz in the calculations |
| 00:36.42 | brlcad | that last change should make what you just saw go away |
| 00:37.44 | brlcad | I've toyed with using something like gmp behind our fastf_t number type to get exact calculations -- that'd be an interesting gsoc project for someone to take on |
| 00:41.47 | tc-rucho | brlcad: is there a way to _lock_ tw to a certain value when using the mouse to rotate the view? |
| 00:42.49 | brlcad | ooof, I believe so, but I don't have the mouse keybindings memorized -- maybe check the shift-grips table on the docs? |
| 01:11.42 | tc-rucho | when trying to modify just 1 element from a parameter array, is there a way to tell mged to reuse existing value in that position? I mean something like 'view aet . . 0' which would reuse the current az and el, and set tw to 0 |
| 01:15.48 | tc-rucho | it's not really that cool to retype everything to change just 1 element |
| 01:16.27 | *** join/#brlcad tc-rucho (n=tc-rucho@190.191.172.28) |
| 01:17.00 | Ralith | not_so_fastf_t |
| 01:20.11 | tc-rucho | oops, seems my last 2 lines were sent to /dev/null |
| 01:20.26 | tc-rucho | when trying to modify just 1 element from a parameter array, is there a way to tell mged to reuse existing value in that position? I mean something like 'view aet . . 0' which would reuse the current az and el, and set tw to 0 |
| 01:20.26 | tc-rucho | it's not really that cool to retype everything to change just 1 element |
| 01:22.59 | Ralith | brlcad: how would you drop in gmp in an elegant way? I can't see a method cleaner than replacing every single arithmetic operation with a preprocessor macro or similar. |
| 01:23.55 | tc-rucho | sed -i ? |
| 01:24.59 | Ralith | tc-rucho: even if it was that simple, which it's not, the end result would still be very ugly |
| 01:27.35 | tc-rucho | anyway, Ralith, is there a way to tell mged to reuse a current value instead typing it again over and over? |
| 01:27.53 | Ralith | no, but try the up arrow |
| 01:27.56 | Ralith | not afaik* |
| 01:30.24 | brlcad | tc-rucho: hm, can't say that need has actually ever come up to only change twist -- at least no requests for it |
| 01:30.48 | brlcad | you can just up-arrow and change a previous line if it's a need to repeatedly test new values |
| 01:31.03 | brlcad | there is command history |
| 01:31.24 | tc-rucho | brlcad: no, if there was no previous line regarding those values there's nothing to do but to retype the whole thing |
| 01:31.25 | brlcad | Ralith: via compilation with a c++ compiler |
| 01:31.36 | Ralith | brlcad: huh? |
| 01:31.51 | Ralith | does GCC have some special gmp support or something? |
| 01:32.11 | brlcad | tc-rucho: you said retype -- but I think you mean type ;) |
| 01:32.11 | Ralith | oh right |
| 01:32.12 | Ralith | C++. |
| 01:32.17 | Ralith | operator overloading. |
| 01:32.19 | brlcad | operator overlaoding |
| 01:32.20 | brlcad | right |
| 01:32.22 | tc-rucho | brlcad: right (: |
| 01:32.24 | Ralith | I thought all that code was in C, though |
| 01:32.32 | brlcad | it is |
| 01:32.42 | Ralith | moving it to C++ is acceptable? |
| 01:32.50 | Ralith | thought he recalled some reluctance to do that |
| 01:33.12 | brlcad | doesn't mean that it can't be compiled with a c++ compiler -- we don't hit the problem cases |
| 01:33.24 | Ralith | hm, good point |
| 01:33.34 | brlcad | oh hell, wouldn't move to that -- it would destroy performance for real-world use |
| 01:33.51 | brlcad | literally, it is two-to-three *orders* slower .. |
| 01:34.08 | Ralith | really? I didn't know C++ impaired performance that much. |
| 01:34.14 | brlcad | no |
| 01:34.16 | Ralith | assuming you're just doing C things in it |
| 01:34.17 | brlcad | you're missing something :) |
| 01:34.40 | Ralith | what'm I missing, then? |
| 01:34.41 | brlcad | talking about replacing fastf_t's with a fixed-precision numeric class type |
| 01:34.44 | Ralith | oh, yes |
| 01:34.50 | Ralith | of course |
| 01:35.01 | Ralith | I thought you were responding to my question about moving to C++. |
| 01:35.11 | brlcad | I was also responding to that |
| 01:35.16 | brlcad | we wouldn't "move" to C++ |
| 01:35.56 | brlcad | if we wanted to make a fixed-precision compile, we'd would make it work through the c++ compiler and use the fixed-precision math pervasively |
| 01:36.52 | brlcad | it would be a compile-time toggle that could be used for various purposes where the performance hit was acceptible, like regression testing, certain analyses, certain geometric transformations, etc |
| 01:36.53 | Ralith | and the way you'd keep that in the same codebase would be by ifdef-ing out the GMP bits, which would be the only part requiring C++ features? |
| 01:36.56 | tc-rucho | brlcad: in a normal bash session I would do => view aet `view aet | awk '{print $1 $2 "0"}'` However, if you think it makes sense to add something like => view aet @ @ 0 where '@' would reuse the current value for that field, then I will gladly contribute a patch adding it (: |
| 01:37.09 | brlcad | Ralith: right |
| 01:37.18 | Ralith | part of me thinks that's a hack |
| 01:37.25 | Ralith | and part of me thing that's a wonderfully effective solution |
| 01:37.50 | Ralith | hm. |
| 01:37.54 | brlcad | it's not a hack if it works, rather elegant imho |
| 01:38.05 | brlcad | still a lot of work, though |
| 01:38.16 | Ralith | yeah, I guess I just have an innate aversion to the preprocessor. |
| 01:38.31 | Ralith | comes from too much playing with higher level languages |
| 01:38.36 | brlcad | have to make fastf_t's fully pervasive, have to have a whole buffet of operator functions |
| 01:38.45 | brlcad | tc-rucho: hmmm |
| 01:39.46 | tc-rucho | because I don't think aet will be the only command that will benefice from a value-reuser |
| 01:40.42 | brlcad | command-parsing like that is still command-specific, though, as args are vastly different from command to command |
| 01:41.01 | brlcad | so either start a new convention.. or add new subcommands |
| 01:41.06 | Ralith | considers finding himself a GSoC project to sign on to |
| 01:41.07 | brlcad | view tw 12 |
| 01:41.22 | brlcad | view az 10 |
| 01:42.09 | tc-rucho | yeah |
| 01:42.13 | brlcad | tc-rucho: how about the latter, a lot more isolated to just add new view subcommands |
| 01:42.37 | tc-rucho | brlcad: would they be included in brlcad if I make them? |
| 01:42.45 | brlcad | and goes well with the aim to make the commands more stateless |
| 01:42.50 | brlcad | tc-rucho: absolutely |
| 01:42.55 | tc-rucho | good (: |
| 01:43.13 | brlcad | good to have all three, az|el|tw |
| 01:43.52 | tc-rucho | I think it would be nice to be able to do something like => view tw 0 el 30 |
| 01:44.07 | tc-rucho | being 'view' the main command and the rest options with values |
| 01:44.14 | brlcad | sure, gang up sets of commands on view |
| 01:44.28 | brlcad | view ypr 10 200 0 tw 10 |
| 01:44.45 | brlcad | similar to what you ran into for help ;) |
| 01:45.40 | brlcad | src/libged/view.c is where the view command lives |
| 01:45.42 | tc-rucho | yeah, I strongly believe changing the commands model a bit would improve mged's usability a _LOT_ |
| 01:45.46 | brlcad | it calls out to various other commands |
| 01:45.58 | brlcad | we're working on that |
| 01:46.42 | tc-rucho | I'm your man then (: but I will be able to get my hands on the commands code in april |
| 01:46.42 | brlcad | first step was getting all the commands out of the application front-end and in one place in a library (libged) |
| 01:47.01 | brlcad | next step is/was making all the commands modeless (ugh, lots to do) |
| 01:47.10 | brlcad | there's still a lot more that has to happen |
| 01:48.22 | tc-rucho | sure |
| 01:48.24 | brlcad | next step after that is command reduction and consolidation |
| 01:49.06 | tc-rucho | I'd love some tw lock for mouse orbit |
| 01:49.10 | brlcad | e.g. instead of a dozen bot_* commands, there's one bot command with various subcommands |
| 01:49.34 | brlcad | hey, if you make the mod, there's no reason to not put features like that in |
| 01:49.58 | tc-rucho | I like that |
| 01:49.59 | tc-rucho | (: |
| 01:50.33 | *** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-71.sbndin.btas.verizon.net) |
| 01:50.36 | brlcad | make more than a couple useful patches and you'd end up working directly on the code |
| 01:51.11 | brlcad | Ralith: are you applying? |
| 01:51.42 | Ralith | brlcad: well, student applications aren't for a month or so, right? |
| 01:51.48 | Ralith | I certainly like the idea. |
| 01:52.07 | brlcad | yeah |
| 01:52.15 | brlcad | the problem here will be slots |
| 01:52.42 | brlcad | if we participate, I'm planning to probably have even fewer students than last year |
| 01:53.23 | brlcad | just 2 or 3, so it'll be even more competitive |
| 01:53.42 | tc-rucho | brlcad: what do you mean? svn access? |
| 01:53.46 | brlcad | tc-rucho: sure |
| 01:53.48 | Ralith | aw. Perhaps I'll find myself a less high profile mentoring organization. |
| 01:53.54 | Ralith | tc-rucho: happened to me. |
| 01:54.00 | tc-rucho | brlcad: oh, nice (: |
| 01:54.25 | brlcad | Ralith: i'm not saying you don't have a chance, you have a leg up just by already being part of the community with a history :) |
| 01:54.41 | brlcad | some of last year's students have leverage too in that regard |
| 01:54.59 | Ralith | brlcad: fair. Are you allowed to apply to multiple organizations and take your pick of the acceptors? |
| 01:55.18 | brlcad | doesn't work that way exactly, but yes you can apply to multiple orgs |
| 01:55.31 | Ralith | will read up on it |
| 01:55.38 | brlcad | if you are accepted by multiple orgs, though, the orgs sort it out (and maybe or maybe not involve you) |
| 01:55.43 | Ralith | O.o |
| 01:55.50 | Ralith | that's... weird |
| 01:55.56 | brlcad | all happens behind the scenes |
| 01:56.09 | brlcad | there's a big conflict resolution meeting |
| 01:56.18 | brlcad | if it's not resolved beforehand |
| 01:57.03 | Ralith | is there a list of SoCables anywhere? Perhaps some subset of that wanted features page of yours? |
| 01:57.12 | Ralith | (within BRL-CAD, that is) |
| 01:57.39 | brlcad | it works out well because many acceptances are contingent on a lot of factors .. like if the project you proposed to one org is considerably more valuable than it was to another org, or maybe you're right on the cutoff and they haven't decided on whether to accept you as N+1 |
| 01:58.04 | brlcad | Ralith: yeah, you can see the materials for last year up on the website |
| 01:58.04 | Ralith | hm, I guess that is pretty reasonable. |
| 01:58.13 | brlcad | has a list of a dozen or so projects |
| 01:58.19 | Ralith | nothing new since then? |
| 01:58.33 | brlcad | I'll probably cull that down to about a half-dozen this year to focus applications |
| 01:58.43 | brlcad | plenty new |
| 01:58.47 | brlcad | but nothing that needs to be added |
| 01:59.02 | Ralith | 'kay then |
| 01:59.20 | brlcad | and students are always welcome to submit ideas not on the list |
| 01:59.29 | brlcad | some of the best ideas for bz haven't been on our list |
| 02:00.34 | Ralith | bzflag is on SoC? I didn't know they did games. |
| 02:00.45 | brlcad | we were their first game two years ago |
| 02:00.49 | Ralith | neat! |
| 02:00.52 | brlcad | this will be year three if we accept |
| 02:00.56 | ``Erik | wow, europeans take their winter sports seriously http://www.collegehumor.com/video:1901384 |
| 02:02.13 | brlcad | ``Erik: do you just wander through video, joke, and comic forums for hours on end?? |
| 02:02.27 | brlcad | sounds like a bigger brain-rotting waste of time than watching tv all day |
| 02:02.31 | brlcad | :) |
| 02:02.40 | tc-rucho | agrees |
| 02:03.31 | Ralith | I dunno, at least it's interactive |
| 02:04.06 | ``Erik | yes, yes I do |
| 02:04.12 | ``Erik | at least until I'm caught up |
| 02:04.23 | brlcad | shakes head |
| 02:04.31 | ``Erik | eventually, I'll make it to the end of the internet, get the highscore and finally beat it |
| 02:05.49 | brlcad | tc-rucho: if you go diving in, keep in mind that libged is the start of a pretty big refactoring effort -- and is subject to change |
| 02:06.19 | brlcad | not so much the commands themselves and how they behave but the ged struct and how data makes it in and out |
| 02:06.41 | brlcad | and there's still a lot more to go to decouple tcl |
| 02:06.44 | tc-rucho | brlcad: I was already considering in getting latest svn sources of BRLCAD to start diving into it's code |
| 02:07.29 | brlcad | also, you mentioned other languages -- for what it's worth if you've not seen it, mged can be pretty readily scripted and batched from any language |
| 02:07.42 | brlcad | e.g., http://brlcad.org/wiki/SGI_Cube |
| 02:07.42 | tc-rucho | brlcad: by the way, you just mentioned decoupling tcl, what are you implying? getting rid of it and adopting something else or what? |
| 02:08.09 | tc-rucho | yeah, noted that from the very beginning |
| 02:08.39 | tc-rucho | it's just that having a nice language within mged itself would be nice for batch stuff |
| 02:09.05 | Ralith | tc-rucho: making the system scripting language independent |
| 02:09.14 | brlcad | we're not getting "rid" of tcl for various reasons, but certainly want to allow other interpreter environments |
| 02:09.18 | Ralith | i.e. make it straightforward to slot in w/e |
| 02:09.35 | brlcad | exactly |
| 02:09.59 | tc-rucho | well, in that case it would be nice to have some lisp dialect as an interpreter too |
| 02:10.05 | brlcad | part of the libged framework is to make it a generalized command functionality library that could be tied into any interpreter environment |
| 02:11.07 | tc-rucho | I like that, so a couple of bindings here and there and one could almost use BF as a command interpreter (just kidding) |
| 02:11.11 | brlcad | initial goal will be to support tcl and bash, and then python and lisp, at least as a starting point |
| 02:11.33 | brlcad | that should generalize the interface sufficiently to support most languages we'd care to bind to |
| 02:11.43 | tc-rucho | sure |
| 02:12.16 | brlcad | plus it covers procedural, functional, and OO as well as interactive and non-interactive parsing |
| 02:12.54 | brlcad | (in terms of a flexible api) |
| 02:13.04 | tc-rucho | you have any dialect in mind for the lisp environment? |
| 02:13.16 | brlcad | not presently |
| 02:13.29 | brlcad | clisp, elisp |
| 02:14.07 | tc-rucho | In terms of implementation quality, I'd stick to SBCL (common lisp) on unixoid systems, and maybe clisp for winblows |
| 02:15.17 | tc-rucho | anyway, seems this could get pretty interesting. I'd say I'm in (: |
| 02:15.24 | brlcad | one of the main points of picking up a lisp environment would be to provide something similar to autolisp |
| 02:15.40 | brlcad | awesome, glad to hear it! |
| 02:15.58 | brlcad | hope you stick to it even after you see how much work is involved ;) |
| 02:16.26 | brlcad | good stuff, though, lots of fun and one of the best code bases to make a big impact |
| 02:17.15 | tc-rucho | as soon as I can get a lisp environment things will get really nice 9In 9My 9Opinion |
| 02:17.55 | tc-rucho | however, I'm definitely not enforcing OO in the lisp environment, it's... ugly |
| 02:21.34 | brlcad | no no, I meant supporting OO semantics for languages like python/ruby/etc |
| 02:21.48 | brlcad | wouldn't sully lisp with that |
| 02:22.07 | brlcad | might not even sully the other langs with that, depends on how the bindings happen |
| 02:23.16 | brlcad | ultimately could just wrap everything in a ged object and do a pass through with a method for every function if it's a strict OO language |
| 02:25.47 | tc-rucho | anyway, I have some proposals for the lisp environment, but bindings come first |
| 02:26.12 | tc-rucho | more specifically, a slight GUI change |
| 02:27.16 | tc-rucho | that would allow keybindings and access to the command prompt in the same window without any extra hassle |
| 02:27.51 | tc-rucho | anyway, I should continue with my studies, I have a huge exam in a pair of days |
| 02:30.09 | brlcad | heh, actually we're looking at a rather major GUI change, but that's a ways down the road |
| 02:30.57 | brlcad | have to do a variety of mged refactorings first, libged cleanup, tcl decoupling, finish implementing BREP support, geometry engine support, geometry service support, then the gui has something solid to talk to |
| 02:31.14 | brlcad | there is a prototype interface hooked in already that a gsoc student worked on last summer |
| 02:31.37 | brlcad | good luck with your exam tc-rucho ! |
| 02:33.40 | tc-rucho | nods |
| 02:34.14 | tc-rucho | brlcad: what text editor do you use? |
| 02:34.33 | brlcad | depends what I'm doing, but usually emacs |
| 02:36.03 | tc-rucho | well, some _wild_ idea for a GUI would be to have most used commands as single letter commands, and then have some stuff like C-x and C-c |
| 02:36.26 | tc-rucho | but maybe people would not feel that comfortable with it |
| 02:36.43 | tc-rucho | anyway, was just a quick wild thought |
| 02:37.18 | brlcad | there's a whole design philosophy about making the interface pervasively modeless, only allowing quasimodalities for context-specific actions |
| 02:37.46 | brlcad | there's a prototype interaction video that one of the devs worked on that I'm using as a sort of "starting point" goal |
| 02:38.00 | tc-rucho | link? |
| 02:38.33 | brlcad | http://brlcad.org/design/gui/ |
| 02:38.44 | brlcad | ioe_proto_final.mov is a good starting point |
| 02:39.23 | brlcad | takes about 5 minutes |
| 02:39.52 | brlcad | it was intionally made non-CAD-centric, but the basic design philosophies still apply |
| 02:42.12 | brlcad | ~ioe |
| 02:42.19 | tc-rucho | I think about brlcad as a rough diamond. It has an awesome 3d framework and all, but it lacks a good GUI 9In 9My 9Humble 9Opinion |
| 02:46.05 | brlcad | agreed |
| 02:46.30 | brlcad | that's why it's one of our four top project priorities |
| 02:46.40 | brlcad | http://brlcad.org/BRL-CAD_Priorities.png |
| 02:46.59 | brlcad | with the other three priorities directly and indirectly supporting it |
| 02:49.05 | brlcad | starseeker: I think I must recall my victory claim.. I'm getting the Tcl_Init error again, so there must be more needed (and my test earlier must not have been a clean test) |
| 03:00.07 | *** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-71.sbndin.btas.verizon.net) |
| 04:00.10 | yukonbob | hello, cadheads |
| 05:04.44 | starseeker | brlcad: arrrgh. Is it something to do with the tcl upgrade? |
| 05:05.33 | starseeker | tried to step through all the changes, but may have missed something... |
| 05:27.34 | brlcad | starseeker: that's when it started, and it's a problem I recall needing to be patched the past couple times we've done a tcl upgrade |
| 05:30.35 | brlcad | can't say for certain without dishing through a whole debugging session, and trying to avoid spending the time to do that frankly |
| 05:30.52 | starseeker | brlcad: arrrgh |
| 05:30.56 | starseeker | ``Erik: help |
| 05:31.06 | starseeker | you recall what was needed in the last couple tcl upgrades? |
| 05:33.14 | brlcad | i'll go through a clean rebuild here to see if maybe the failure earlier today was a false positive |
| 05:33.30 | starseeker | ]it's distcheck that's failing? |
| 05:33.42 | brlcad | test fails |
| 05:34.22 | brlcad | specific to doing a make test prior to (ever) doing a make install -- it'll look in /usr/brlcad so have to make sure there isn't an install there already |
| 05:34.28 | starseeker | Is it MacOSX only? It seems to work here |
| 05:34.32 | starseeker | oh |
| 05:34.36 | starseeker | did a make install |
| 05:34.59 | brlcad | one of the sanity checks to make sure in-tree execution works cleanly pulling the right files |
| 05:35.30 | starseeker | Oh, I see it now |
| 05:35.49 | brlcad | it's not a release stopper |
| 05:36.02 | brlcad | but it shouldn't linger (assuming it is new/returned) |
| 05:36.58 | brlcad | could try a 7.14.0 to see if it has the problem |
| 05:37.06 | starseeker | ok |
| 05:37.23 | brlcad | maybe it was broken during the prior upgrade and just coincidentally noticed |
| 05:38.08 | starseeker | is bothered he didn't get it patched with that last effort |
| 05:38.53 | brlcad | you fixed a whole slew of other issues that would have come up, though |
| 05:38.59 | brlcad | so good you did anyways |
| 05:39.13 | starseeker | thanks, but it makes this one all the more vexing |
| 05:39.27 | brlcad | 1/10th the time to find/fix now than to have someone else spend all day rehunting each one ;) |
| 05:39.35 | starseeker | :-) |
| 05:39.51 | starseeker | makes a note to join the tcl dev email lists and start making some noise |
| 05:40.00 | starseeker | grumble |
| 05:40.15 | starseeker | not that I had a lot of luck with gentoo |
| 05:40.43 | brlcad | gentoo is so close, should be able to finish it up now |
| 05:41.16 | starseeker | assuming they don't just leave it to the gentoo-science overlay |
| 05:41.26 | brlcad | nods |
| 05:41.51 | brlcad | haven't seen a build log in a while to know if there's anything else that needs changed |
| 05:42.05 | brlcad | I took care of most of the issues I knew about |
| 05:42.11 | starseeker | I haven't tried to do a system build in a long while - it might work now |
| 05:42.43 | brlcad | it should work as a --disable-all now without a problem |
| 05:42.50 | starseeker | cool :-) |
| 05:43.05 | starseeker | will test that once the make test bug is hunted down |
| 05:43.15 | brlcad | incrTcl init was the last straggler, and that should be taken care of |
| 05:43.23 | starseeker | awesome |
| 05:43.31 | brlcad | there are still the naming conflicts, but that's for later to allow subdir relinking |
| 05:43.55 | starseeker | brlcad: Oh, that reminds me - bob said you wrote the libtclcad auto_path command |
| 05:44.10 | starseeker | did that change I made cause any trouble? |
| 05:44.16 | brlcad | the function, yeah |
| 05:44.45 | brlcad | what change? |
| 05:44.57 | starseeker | let me check |
| 05:45.21 | starseeker | r33845 |
| 05:46.00 | brlcad | oh yeah, that one.. |
| 05:48.09 | brlcad | "probably" only because tclcadAutoPath() is mostly supposed to allow relocation overrides and source-dir executions to work, not serve as install defaults |
| 05:48.29 | brlcad | if it works, it'll be because of how it searches for relocation execution |
| 05:49.12 | brlcad | can't say for sure, though .. |
| 05:50.16 | starseeker | ok. If it breaks anything I'll revert it - it sidestepped what I was running into, but it's still not clear to my why auto_path had the system paths in the first place |
| 05:50.32 | starseeker | maybe it's related to why make test isn't working, for that matter... |
| 05:50.44 | brlcad | I think the latter is a different problem, and the one that needed fixing -- why it got system paths in the first place |
| 05:51.15 | brlcad | think that implies that it didn't load the right init.tcl to start with or didn't link the right lib to start with |
| 05:51.24 | brlcad | which are different problems |
| 05:51.51 | starseeker | Is that our build system or the tcl/tk level logic? |
| 05:52.47 | brlcad | wouldn't be the build system -- could be run-time ld paths or tcl init logic |
| 05:53.53 | brlcad | you can check the ld linkage easily enough (otool -L or ldd) |
| 05:54.23 | brlcad | can check the init logic by breaking in Tcl_Init() and seeing which init.tcl is loaded |
| 05:57.06 | starseeker | ldd looks OK |
| 06:04.37 | brlcad | notes that Bob cheated horribly in src/mged/setup.c |
| 06:11.30 | starseeker | brlcad: did we need to explicitly set tcl_library? |
| 06:11.35 | starseeker | was that the patch? |
| 06:19.03 | starseeker | ummm.... 7.14.0 on my machine is trying to use /usr/include/tk.h when compiling bombardier.c |
| 06:28.17 | brlcad | different issue |
| 06:28.37 | brlcad | src/util/Makefile.am, add TK_CPPFLAGS to bombardier |
| 06:37.08 | CIA-40 | BRL-CAD: 03brlcad * r33887 10/brlcad/trunk/configure.ac: default the ogl interface to off until the various bugs are all fixed. it's unusable as-is due to said bugs and is just complicating the support questions. |
| 06:37.08 | CIA-40 | BRL-CAD: 03brlcad * r33890 10/brlcad/trunk/NEWS: |
| 06:37.08 | CIA-40 | BRL-CAD: Bob added a new 'gqa' command to mged that runs the formerly command-line-only |
| 06:37.08 | CIA-40 | BRL-CAD: 'g_qa' command including the addition of a new -Ap option that will visualize |
| 06:37.10 | CIA-40 | BRL-CAD: the overlaps encountered as a series of wireframe edges similar to rtcheck. |
| 06:37.12 | CIA-40 | BRL-CAD: should rename one of the two to make running the tool self-consistent inside and |
| 06:37.14 | CIA-40 | BRL-CAD: outside of mged. |
| 06:37.20 | CIA-40 | BRL-CAD: 03brlcad * r33888 10/brlcad/trunk/ (NEWS TODO): bob fixed the mged view initialization bugs where it was starting up under a top view instead of 3525 with no faceplate initialization. should be mostly all better now. |
| 07:05.18 | brlcad | notes warnings on nmg_fix_normals |
| 07:13.05 | CIA-40 | BRL-CAD: 03brlcad * r33891 10/brlcad/trunk/src/libged/ (178 files): |
| 07:13.05 | CIA-40 | BRL-CAD: whew, that is brutal.. tedius header cleanup to denote private headers as |
| 07:13.05 | CIA-40 | BRL-CAD: private (and in the own section) using relative path syntax. also make sure |
| 07:13.05 | CIA-40 | BRL-CAD: bio.h comes after the system headers but is listed with system headers (it's |
| 07:13.06 | CIA-40 | BRL-CAD: sort of a wrapper around stdio). |
| 08:07.55 | *** join/#brlcad ``Erik (i=erik@c-76-111-12-116.hsd1.md.comcast.net) |
| 10:11.20 | *** join/#brlcad mafm (n=mafm@223.Red-83-49-86.dynamicIP.rima-tde.net) |
| 10:44.10 | *** join/#brlcad _sushi_ (n=_sushi_@84-72-93-63.dclient.hispeed.ch) |
| 10:54.28 | *** join/#brlcad ChanServ (ChanServ@services.) |
| 10:54.28 | *** mode/#brlcad [+o ChanServ] by irc.freenode.net |
| 11:05.29 | *** join/#brlcad ChanServ (ChanServ@services.) |
| 11:05.29 | *** mode/#brlcad [+o ChanServ] by irc.freenode.net |
| 11:08.20 | d-lo | yawns |
| 11:08.23 | d-lo | Mornin |
| 11:41.15 | *** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-71.sbndin.btas.verizon.net) |
| 11:43.43 | *** join/#brlcad Elrohir (n=kvirc@91.20.246.241) |
| 12:00.51 | *** join/#brlcad ``Erik (i=erik@c-76-111-12-116.hsd1.md.comcast.net) |
| 13:11.46 | *** join/#brlcad mafm_ (n=mafm@223.Red-83-49-86.dynamicIP.rima-tde.net) |
| 13:13.44 | starseeker | brlcad: I'll be out one more day, I'm afraid :-( |
| 13:15.51 | starseeker | d-lo: I can't find the email addresses - could you do me a favor and send out an email again? |
| 13:17.49 | d-lo | starseeker: shore thang. |
| 13:17.55 | starseeker | thanks :-) |
| 13:27.23 | d-lo | np |
| 13:55.52 | brlcad | starseeker: okay, np |
| 14:07.21 | ``Erik | starseeker: the only caveat with tcl and tk was that one line in tcl/generic/tclInt.h iirc, tk "just worked". incr is a bit of a different story |
| 14:08.32 | ``Erik | was under the impression that elisp had grevious differences to cl (stuff like scope handling, basic function names, etc), but kinda remembers reading that autolisp was weird, too *shrug* |
| 14:09.06 | ``Erik | supposedly, CLOS can do all t he oo type things that ruby and python can, plus a slew of other neat stuff like generic funcs |
| 14:11.32 | *** join/#brlcad samrose (n=samrose@c-24-11-214-181.hsd1.mi.comcast.net) |
| 14:20.11 | tc-rucho | ``Erik: CLOS is an awesome OO system, it does not use messages, it uses generic functions. However, I find OO rather ugly in Lisp. It's like jailing/restricting oneself rather than liberating |
| 14:20.36 | tc-rucho | OO in lisp usually leads to code that's really difficult to track |
| 14:21.07 | ``Erik | hm, I'm more of a scheme weenie, I've only used clos just enough to get a basic ucw thingy working :) |
| 14:22.47 | tc-rucho | well, I use common lisp as my main lisp dialect, and I really never needed CLOS, it made things more difficult actually, and heavily OO code made using CLOS was hell to figure out. |
| 14:23.13 | tc-rucho | not even the original authors were able to keep track of it in order to fix some stuff, blame CLOS |
| 14:23.36 | tc-rucho | so I would be happier if we stick to just lists for the bindings and all |
| 14:23.38 | tc-rucho | . |
| 14:25.16 | ``Erik | *shrug* I still plan on learning it, I've heard arguments both ways so mebbe I'll find it a handy tool for certain problems, mebbe not |
| 14:26.02 | tc-rucho | points to the second alternative |
| 14:26.09 | tc-rucho | anyway |
| 14:26.28 | ``Erik | but yeah, with scheme I felt like the combination of lists, vectors, and assocs is probably 'sufficient' |
| 14:27.37 | tc-rucho | have it your way, give it a try, try to code something complex, then archive it and look at it again in about 2 months, and if by any chance you can follow the CLOS code easier than if it used just lists, I would like some good argument about why use it |
| 14:27.46 | tc-rucho | right |
| 14:28.01 | ``Erik | we'll see *shrug* :) |
| 14:28.04 | tc-rucho | lists and assocs are all one needs |
| 14:28.06 | tc-rucho | (: |
| 14:28.07 | starseeker | brlcad: I'm seeing failures in the test script that appear to be caused by the messing "Using Tcl library at..." being printed |
| 14:28.19 | brlcad | starseeker: yeah, I know about those |
| 14:28.24 | brlcad | it's benign |
| 14:28.38 | starseeker | but otherwise, the MGED tests seem to run |
| 14:28.43 | brlcad | it's because the script just takes the output of ? and help as-is |
| 14:29.11 | brlcad | and there are a variety of debug and output messages that can appear before the command list |
| 14:29.32 | starseeker | OK - so the failure you're worried about is something different then |
| 14:29.45 | brlcad | if there was consistent stderr/stdout separation, could handle it, but there's not so it is what it is |
| 14:29.45 | tc-rucho | ``Erik: by the way, what scheme implementation do you prefer? I really haven't toyed with scheme (mainly because fucken scsh needs some scheme implementation for 32bit only) |
| 14:30.27 | ``Erik | gauche usually, used to use guile but it's performance was ... poor. have toyed with chicken and bigloo a little, and mzscheme isn't too bad |
| 14:30.39 | brlcad | starseeker: yeah, the error is something different -- Tcl_Init failure |
| 14:30.55 | starseeker | so far I can't reproduce that here |
| 14:31.08 | brlcad | on old or new or both? |
| 14:31.15 | starseeker | anywhere |
| 14:31.16 | tc-rucho | ``Erik: I find mzscheme (drscheme?) kind of bloated. Wasn't gauche a scheme -> C implementation? |
| 14:31.20 | starseeker | er, either |
| 14:31.25 | brlcad | thought you encountered it yesterday? |
| 14:31.31 | brlcad | when you removed the installed version |
| 14:31.42 | ``Erik | no, gauche is an interpreter, um, shiro.dreamhost.com or something |
| 14:31.46 | starseeker | no, that was the complaint I just mentioned |
| 14:32.01 | ``Erik | the interpreter is "gosh" |
| 14:32.33 | starseeker | ``Erik: then the compiler had better be "darnit" ;-) |
| 14:33.13 | ``Erik | no, there's no straight compiler component, I don't know if it can save bytecode images, either :/ I used it for q&d scripty type thangs mostly |
| 14:33.41 | tc-rucho | hohoho, awesome name for a lisp-family interpreter |
| 14:34.56 | brlcad | starseeker: i'm giving it a clean retry now |
| 14:35.17 | brlcad | see what you get with this on a clean tree, it'll .. take a while |
| 14:35.38 | brlcad | rm -rf /usr/brlcad && sh autogen.sh && ./configure --enable-all && make distclean && sh autogen.sh && ./configure --enable-all && make -j4 && make test |
| 14:35.45 | brlcad | notice the rm -rf in case you need it.. |
| 14:36.31 | brlcad | if that works for you, then we can call it a closed issue |
| 14:36.52 | ``Erik | hm, rm -rf /usr/brlcad/* would be better, so the /usr/brlcad directory stays and doens't need rootage to recreate it :D |
| 14:37.52 | brlcad | meh |
| 14:39.54 | starseeker | ``Erik: on my home box, no matter |
| 14:39.56 | tc-rucho | ``Erik: although it's not a really big problem, I've always felt more comfortable with false being just nil and true being T, instead of #t and #f. Also SBCL is a kick-ass implementation that compiles to native code (not to mention that CL uses different spaces for functions and data so a var and a function can share the same name) |
| 14:41.55 | starseeker | tc-rucho: Oh, he's an SBCL fan :-) |
| 14:42.09 | starseeker | so am I |
| 14:42.20 | tc-rucho | starseeker: good (: |
| 14:42.21 | ``Erik | is using sbcl on fbsd for ucw :) |
| 14:43.02 | tc-rucho | then it's going to be Common Lisp (SBCL), right? |
| 14:43.14 | tc-rucho | I thought that had not been decided yet |
| 14:43.30 | ``Erik | for BRL-CAD, it's not |
| 14:43.35 | ``Erik | not decided, that is |
| 14:43.44 | ``Erik | this is for a private project |
| 14:43.57 | starseeker | ucw = UnCommon Web |
| 14:44.22 | starseeker | ucw is... odd |
| 14:44.33 | starseeker | at least as far as getting it working |
| 14:44.59 | d-lo | no no no no....ucw = http://www.ultimatechristianwrestling.com/ |
| 14:45.04 | ``Erik | YOU'RE odd! :D naw, the continuation based web framework model seems neato to me |
| 14:45.34 | ``Erik | you may've spent a little TOO long in the navy, d-lo. |
| 14:45.46 | starseeker | d-lo: that's gotta be in the top five "URLs I never thought I'd see" list |
| 14:47.47 | d-lo | lol, blame google. #2 on the list. |
| 14:47.58 | starseeker | brlcad: no point in my doing -j4 on a 2 core machine, yes? |
| 14:48.18 | brlcad | whomever works on making the lisp interface actually work will probably be the main deciding factor on which lisp is used ;) |
| 14:48.26 | ``Erik | best bang is probably -j3, I'd guess |
| 14:48.36 | brlcad | so if you want sbcl, someone needs to get busy ;) |
| 14:49.02 | starseeker | alrightie, the clean test is running |
| 14:49.04 | brlcad | starseeker: yeah, j3 is probably best, but doesn't matter much |
| 14:49.23 | brlcad | distclean or clean? |
| 14:49.40 | starseeker | the sequence you gave above |
| 14:50.01 | starseeker | autogen, distclean, etc. |
| 14:50.31 | starseeker | could still be a mac specific issue though |
| 14:50.50 | starseeker | ``Erik: Did you see any major patches to tcl that I missed in that big roundup? |
| 14:51.32 | ``Erik | I didn't see your big roundup... :D the only trick was the line in tclInt.h or something |
| 14:51.46 | ``Erik | last I did it, anyways... they may've made things more interesting |
| 14:52.26 | starseeker | erm |
| 14:52.44 | starseeker | Bob had some Windows specific tweaks in there, and there was some SGI/IRIX makefile logic |
| 14:52.57 | starseeker | or tweaks at least |
| 14:53.20 | starseeker | plus the fix for doc install paths from the gentoo bug |
| 14:53.44 | starseeker | oh well, no matter |
| 14:54.05 | starseeker | it could very well be that 8.5.6 itself introduced a new quirk all on its own |
| 15:08.39 | *** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-71.sbndin.btas.verizon.net) |
| 15:37.16 | starseeker | brlcad: OK, I see it now |
| 15:45.20 | CIA-40 | BRL-CAD: 03erikgreenwald * r33892 10/brlcad/trunk/ (69 files in 3 dirs): Upgraded libpng to 1.2.35. |
| 15:45.32 | starseeker | It looks like we need to set tcl_library somewhere |
| 15:45.52 | starseeker | or set the TCL_LIBRARY environment variable |
| 15:49.30 | starseeker | based on svn diff, offhand I don't see any change pertaining to tcl_library that could have an impact |
| 16:03.00 | ``Erik | hrm |
| 16:08.23 | starseeker | grr: http://pastebin.bzflag.bz/m3037d4dd |
| 16:11.48 | starseeker | export TCL_LIBRARY=../src/other/tcl/library prior to make test does succeed |
| 16:19.14 | starseeker | the difficulty is where should it be set, and how to conditionalize its setting on BUILD_TCL being true |
| 16:27.10 | ``Erik | sweet, I done broke the libpng stuff :D |
| 16:27.29 | d-lo | awesome! The dishes are done man! |
| 16:34.42 | *** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-71.sbndin.btas.verizon.net) |
| 16:57.13 | *** join/#brlcad docelic (n=docelic@78.134.207.11) |
| 17:01.37 | brlcad | starseeker: additionally, tclcadAutoPath() tries to set tcl_library too, could be some interplay going on |
| 17:01.54 | brlcad | good to see that the problem can be reproduced, though |
| 17:02.09 | brlcad | starseeker: did you test that with 7.14.0 too? |
| 17:02.41 | brlcad | if it fails for 7.14.0, then it's not nearly as important to address now .. just don't want to take steps backwards if it's new |
| 17:09.59 | *** join/#brlcad ChanServ (ChanServ@services.) |
| 17:09.59 | *** mode/#brlcad [+o ChanServ] by irc.freenode.net |
| 17:40.08 | *** join/#brlcad mafm (n=mafm@223.Red-83-49-86.dynamicIP.rima-tde.net) |
| 17:56.14 | brlcad | ``Erik: build failures in libpng's Makefile.am |
| 17:56.40 | ``Erik | hm, cia is being slow |
| 17:56.44 | ``Erik | I fixed it a few minutes ago |
| 17:56.54 | brlcad | cool, k |
| 17:58.30 | ``Erik | jabs cia a few times |
| 17:58.34 | CIA-40 | BRL-CAD: 03erikgreenwald * r33893 10/brlcad/trunk/src/other/libpng/ (Makefile.am autogen.sh config.h.in configure.ac): revert back to our Makefile.am and remove the leftover autoconf crud. |
| 17:58.38 | ``Erik | there it goes heh |
| 18:39.29 | *** join/#brlcad elite01 (n=omg@unaffiliated/elite01) |
| 18:42.12 | CIA-40 | BRL-CAD: 03erikgreenwald * r33894 10/brlcad/trunk/src/libged/gqa.c: ', ' doesn't make a lot of sense, hope it's supposed to be ',' |
| 18:44.34 | brlcad | ``Erik possible to get an isst screenshot today? |
| 18:44.52 | brlcad | could use something glitzy to show off |
| 18:45.10 | ``Erik | show off for what? |
| 18:45.34 | brlcad | presentation putting together |
| 18:46.26 | ``Erik | sure, gimme a few to back out a change |
| 18:46.39 | ``Erik | the, uh, |
| 18:48.22 | ``Erik | heh, I blew up my BRL-CAD |
| 18:49.39 | brlcad | starseeker: similarly, do you have access to a copy of what you brought to the ccb that you could send my way? |
| 19:02.33 | *** join/#brlcad _sushi_ (n=_sushi_@77-58-245-189.dclient.hispeed.ch) |
| 19:54.18 | *** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-71.sbndin.btas.verizon.net) |
| 20:21.08 | brlcad | starseeker: never mind, I pulled images from elsewhere |
| 20:22.22 | ``Erik | is half interested in how his images will be used if'n there's time to show the slides off |
| 20:23.01 | brlcad | used two of them |
| 20:23.53 | ``Erik | assumes the t62 and the depth render went away? |
| 20:25.05 | brlcad | good guess |
| 20:25.59 | ``Erik | but but but the old tank had the dropdown menu showing the modes, and the depth render looks, y'know, all futuristic! :D |
| 20:28.40 | brlcad | only have a 15 min total, there are already two min slotted to adrt .. if I put more, it'll lose effect |
| 20:28.47 | ``Erik | ok |
| 20:28.50 | brlcad | two is pushing it, really needs to be one, but I think I can talk to it |
| 20:28.54 | brlcad | as two |
| 20:29.10 | ``Erik | lemme know if you need info |
| 20:31.35 | brlcad | k |
| 20:31.45 | brlcad | going with data from last quarter |
| 20:33.17 | ``Erik | hm, almost everything has been internal, though my current activity is to make it can run in 'local' mode (just run a binary and go, single process with 2 threads) |
| 21:34.22 | CIA-40 | BRL-CAD: 03bob1961 * r33896 10/brlcad/trunk/include/ged.h: Added a declaration for ged_build_tops. |
| 21:35.19 | CIA-40 | BRL-CAD: 03erikgreenwald * r33895 10/brlcad/trunk/src/adrt/libtienet/load_MySQL.c: temporarily disable the converter ... |
| 21:37.23 | CIA-40 | BRL-CAD: 03bob1961 * r33897 10/brlcad/trunk/misc/win32-msvc8/libged/libged.vcproj: Added nmg_fix_normals.c to libged's windows build. |
| 21:37.41 | CIA-40 | BRL-CAD: 03bob1961 * r33898 10/brlcad/trunk/src/other/tcl/generic/tclInt.h: Move include for common.h after Tcl includes. This gets rid of warnings about redefining O_BINARY and O_TEMPORARY. |
| 21:58.13 | *** join/#brlcad user___ (n=chatzill@170.Red-88-26-76.staticIP.rima-tde.net) |
| 22:04.23 | *** join/#brlcad Elrohir (n=kvirc@p5B14F6F1.dip.t-dialin.net) |
| 22:04.42 | brlcad | hm, distcheck is still busted |
| 22:11.00 | *** join/#brlcad BigAToo (n=BigAToo@c-67-163-45-187.hsd1.in.comcast.net) |
| 22:33.38 | brlcad | good catch on the ',' |
| 22:33.54 | brlcad | automated cleanup went afoul |
| 22:34.03 | ``Erik | make -s makes it really easy |
| 22:34.46 | ``Erik | there're others I skipped, they looked less odd (like const char *argv[] ... char *blah = argv[1]; ) |
| 22:35.09 | ``Erik | my distcheck breaks on not knowing how to aclocal heh |
| 22:39.14 | brlcad | I looked and was mistaken on the export5 for bot's using nmg_fix_normals |
| 22:39.57 | ``Erik | yeh, *shrug* I implemented what was discussed, I saw no easy way to do a fix_normals on an arbitrary bot, I think ed was right |
| 22:40.21 | ``Erik | I don't think bot strongly enforces being a closed solid, it's just all our conversions to bot happen to come from solids |
| 22:40.32 | ``Erik | via nmg topology testing |
| 22:41.00 | ``Erik | at least from something like facetize :) |
| 22:41.14 | brlcad | it's not strongly enforced but it is enforced |
| 22:41.27 | ``Erik | at the bot level, or the nmg level? |
| 22:41.29 | brlcad | the bot mode |
| 22:41.33 | brlcad | as a bot |
| 22:41.37 | ``Erik | ah, hum |
| 22:41.39 | brlcad | RT_BOT_SURFACE |
| 22:41.47 | brlcad | RT_BOT_SOLID |
| 22:41.51 | brlcad | RT_BOT_PLATE, etc |
| 22:41.55 | ``Erik | aight |
| 22:42.14 | ``Erik | I knew we had plate, I was fairly certain we could have abitrary bots as well (surface, I guess) |
| 22:42.15 | brlcad | if it's a solid, it should convert directly to an nmg |
| 22:42.42 | brlcad | there is an nmg-bot converter, could turn that into a routine and make a bot-nmg routine |
| 22:42.53 | brlcad | then turn bot into nmg, fix normals, then back to bot |
| 22:43.07 | brlcad | or make a bot_fix_normals that just does the same algorithm on the bot structure |
| 22:43.13 | ``Erik | guess that depends on the pro-e and iges converter shtuff, d-lo seemed to have opinions as he just recently went through the pain and suffering with that little pickup |
| 22:43.14 | brlcad | fairly simple algo |
| 22:43.39 | ``Erik | has to hammer out the adrt/isst stuff yesterday :/ |
| 22:44.43 | brlcad | true dat |
| 22:58.26 | CIA-40 | BRL-CAD: 03brlcad * r33899 10/brlcad/trunk/regress/mged.sh: |
| 22:58.26 | CIA-40 | BRL-CAD: quell the false-positive ERROR lines about "Using Tcl library at |
| 22:58.26 | CIA-40 | BRL-CAD: /path/to/something" since it's just diagnostic output. that message is only |
| 22:58.26 | CIA-40 | BRL-CAD: printed in debug builds and is one of a variety of diagnostic messages that |
| 22:58.26 | CIA-40 | BRL-CAD: could get displayed. still, quell the one we know will be shown. |
| 23:00.31 | brlcad | starseeker: I think I found the problem |
| 23:00.39 | brlcad | and I think it's new |
| 23:01.03 | brlcad | mged isn't failing with that message, g_diff is |
| 23:01.45 | starseeker | is impressed |
| 23:01.50 | starseeker | and groggy |
| 23:01.55 | starseeker | you got the pics you need? |
| 23:04.37 | brlcad | yep |
| 23:08.48 | *** join/#brlcad IriX64 (n=IriX64@bas2-sudbury98-1177680864.dsl.bell.ca) |
| 23:10.37 | brlcad | IriX64: you're voiceless until you do something constructive, sorry |
| 23:10.54 | brlcad | send me a PM if you'd like to discuss it |
| 23:11.13 | brlcad | otherwise, welcome to lurk and listen |
| 23:24.18 | *** join/#brlcad Dr_Phreakenstein (n=phreak@216.151.24.198) |
| 23:50.28 | ``Erik | guess he didn't like that |
| 23:55.12 | brlcad | he was talking to me in private |
| 23:55.16 | brlcad | he's okay with it |
| 23:56.05 | ``Erik | but is he going to wrap up, say, the version thing on mged? i'ts what, 4 lines of code, he was almost done, still no patch? :) |
| 23:56.31 | ``Erik | or at least start writing up docs, we have an awful lot that need to be written at least in draft form |
| 23:59.42 | brlcad | probably not, he'd need a lot more hand-holding and someone telling him exactly what to do next |
