| 00:42.27 | *** join/#brlcad iraytrace (n=iraytrac@c-76-100-13-240.hsd1.md.comcast.net) | |
| 00:45.35 | brlcad | smurfette: enjoy :) |
| 00:45.52 | brlcad | sells all his wordly possessions while he's away |
| 00:46.17 | brlcad | i suppose he's there by now, or will be soon |
| 00:46.48 | brlcad | homovulgaris: hmm, can you forward me the rejection? |
| 00:47.07 | brlcad | you've sent to it before... |
| 00:48.48 | homovulgaris | yeah i have .. dunno why it is rejecting this time |
| 00:48.59 | brlcad | and if you need functors (which i sorta assumed you would.. for representing a given 'compiled' constraint), that boost constraint library becomes even more interesting :) |
| 00:50.52 | homovulgaris | yeah.. basically i am very much keen on using functors ;) major on my TODO list |
| 00:51.45 | brlcad | is_tangent, is_parallel, etc |
| 00:52.08 | homovulgaris | basically binary constraints are nothing compared to the actual generic constraint problems.. so writing a generic solver is gonna be pretty tough.. |
| 00:52.21 | homovulgaris | :) nice challenge i mean ;) |
| 00:52.39 | brlcad | hm, you should document your TODO list actually in the TODO |
| 00:53.26 | homovulgaris | brlcad: have a look at this, decently simple introduction to basic concepts of constraint solution http://kti.mff.cuni.cz/~bartak/constraints/index.html |
| 00:53.38 | brlcad | it's supposed to be a basic scratch-pad file for those sorts of thoughts/plans, not rigid format nor formalized, just notes |
| 00:53.56 | homovulgaris | hmm.. the main TODO.. do i add a new section called libpc and add bullets ? |
| 00:54.38 | homovulgaris | ok.. sent the mail btw. both the original message and the rejection :) |
| 00:56.19 | brlcad | homovulgaris: mm, yeah, you could add a new section, or create either a TODO or README in src/libpc |
| 00:56.56 | brlcad | if they're "definitely going to happen" notes, then they probably belong at the top-level |
| 00:56.59 | homovulgaris | hey sean, in the TODO what do we mean by integration of BRL-CAD Overview and Industry diagrams. I was pretty impressed by the Industry diagram :) neat spanning representation |
| 00:57.20 | brlcad | integrating them into svn somehow |
| 00:57.32 | homovulgaris | hmm.. I think i will create a TODO in the libpc and refine things from there to the main :) |
| 00:57.44 | brlcad | they're not revision controllable/controlled at the moment, they were drafted up with proprietary tools |
| 00:58.04 | homovulgaris | ok.. |
| 00:58.05 | brlcad | try not to be too isolationist.. :) |
| 00:58.28 | homovulgaris | :D |
| 00:58.30 | brlcad | reduction of "stuff" to maintain is a good thing |
| 00:58.49 | homovulgaris | finally i had to return to my college due to the rains :) going home on 2nd july now.. |
| 00:59.34 | homovulgaris | and the 2200 train journey is shifted to a crappy flight |
| 00:59.38 | homovulgaris | loves trains |
| 00:59.57 | homovulgaris | sean, we don't have a problem with variadic functions right ? |
| 01:00.13 | brlcad | seriously, I smile .. but it's a natural tendancy of new devs in particular, low maintenance and integrated is key regardless of the mechanisms |
| 01:00.40 | homovulgaris | i mean we dont have to think about compilers which don't support them. I mean i dont know of any |
| 01:01.07 | brlcad | nah, varargs are fine when used appropriately |
| 01:01.14 | brlcad | typechecking them can be a bitch |
| 01:01.16 | homovulgaris | hmm.. ok.. will try to keep it as integrated as possible.. :) I don't want to end up writing code which becomes useless in a short time :D |
| 01:01.24 | brlcad | and having the right signatures if they're publicly exposed |
| 01:01.50 | homovulgaris | just for the constructor of constraint class right now |
| 01:02.34 | brlcad | that's also why a great first step is getting the primitives using the library for their simple validation needs -- if that much is easily understood and simple enough, using and extending the library for modeling purposes can more readily follow |
| 01:03.43 | brlcad | homovulgaris: I also haven't reviewed whether you're using any stl types in libpc's public API .. that's usually taboo/problematic |
| 01:04.20 | homovulgaris | hmm.. so i think i should write my own list and vector ? |
| 01:04.33 | brlcad | hells no, not if you can avoid it |
| 01:04.51 | brlcad | depends just where in the api it is |
| 01:05.20 | brlcad | i love the stl containers, they're just hell for windows binary compatibility |
| 01:05.24 | homovulgaris | hmm.. ok right now lots of transfer between objects takes place using lists |
| 01:05.58 | homovulgaris | that should be removed i guess ? i mean if it is not exposed it is not an issue ? |
| 01:06.20 | brlcad | hell => not generally portable to anything but the OS and version it was compiled for |
| 01:06.52 | brlcad | i guess it really depends how the windows build is set up |
| 01:07.13 | homovulgaris | hmm... :) grr.. so i need to do some figuring out in that direction |
| 01:07.27 | brlcad | if libpc is set up as a static lib and resolves everything in librt et al, then it won't matter (but that's a bigger pita) |
| 01:07.42 | brlcad | I wouldn't worry about it too much at this point |
| 01:08.01 | homovulgaris | hmm.. static.. k.. lets see |
| 01:08.16 | brlcad | both std lists and vectors can be easily turned into bu_lists if we need to |
| 01:08.57 | homovulgaris | bu_list is kewl.. that example was pretty explanatory |
| 01:08.58 | brlcad | make the public api call a bu-wrapper that turns them into stl on the backend |
| 01:10.47 | homovulgaris | hmm.. as i mentioned in the mail, i think i need to do the work i left of at the C part of things bridging the interface between all these C++ classes and the C structs |
| 01:10.51 | brlcad | if you want to worry about that now, great, if not we can look into it before anything is exposed to external developers |
| 01:12.05 | homovulgaris | I think mid july would be a good time. |
| 01:12.15 | homovulgaris | adding to TODO |
| 01:14.14 | homovulgaris | sean, another thing i was thinking about was, when we actually implement constraints, for supporting generic constraint evaluation, is it worth considering runtime code generation |
| 01:15.18 | homovulgaris | one way of evaluation is basically a stack parser which is relatively easy to code |
| 01:15.18 | brlcad | example? |
| 01:16.02 | brlcad | bah, sf.net lists aren't responding at the moment, I'll have to check on it later |
| 01:17.00 | homovulgaris | like any constraint involving a set of parameters and operations on them ( X^5 + YZ^3 -f(P&Q) ) or some complex expression of the sort |
| 01:17.20 | brlcad | presumably you mean some parser for tokenizing and evaluating the expression(s) |
| 01:17.39 | homovulgaris | yeah that is one solution. |
| 01:18.12 | homovulgaris | by runntime code generation, I mean actually coding and compiling the function so that we save computational time |
| 01:18.54 | homovulgaris | because that same expression will have to be evaluated for a large number of possible value sets of (X,Y,P ,Q) |
| 01:19.29 | smurfette | brlcad: no he isnt here yet, he took some obnoxiously long flight that has a 1.5 hour layover in minnesota :P |
| 01:19.49 | smurfette | minnesota isnt exactly between here and there, its WAY out of the way :( |
| 01:19.57 | brlcad | smurfette: ah |
| 01:20.26 | smurfette | so i have to pick him up at 11 cst |
| 01:20.39 | brlcad | you going to be waiting in a white summer dress in high heels with a white hat? |
| 01:20.45 | brlcad | painted in blue? |
| 01:21.04 | smurfette | haha, of course! |
| 01:21.51 | smurfette | i need to dye my hair yellow too |
| 01:22.24 | brlcad | homovulgaris: I get what it is and what it's for, but not how your actual question relates to what you were planning on doing |
| 01:23.35 | homovulgaris | hmm.. :D I am pretty fuzzy on that too .. just started thinking about it |
| 01:24.32 | brlcad | if you have expression trees/graphs, then each node is a potential function |
| 01:25.06 | brlcad | the mere nature of parsing the expression into an in-memory graph structure that is evaluated should be reasonable for most purposes |
| 01:25.43 | brlcad | turning the whole expression into some new dynamic function is probably overkill (or at least not a project for *this* summer given everything else that is needed) |
| 01:26.02 | homovulgaris | hmm.. k i was thinking that probably the graph traversal would eat up time :D and yeah :) overkill |
| 01:26.23 | brlcad | since if you *really* needed the performance for some given expression, then that would really sound like some missing pre-existing function |
| 01:26.59 | homovulgaris | and eitherways i think i should first implement the parser rather than worrying about optimization |
| 01:27.14 | brlcad | i sort of seem to think we'll end up with a set of available "precompiled" functions, similar to the excel macros if you will, that basically let you write expressions that use some syntax like TANGENT(this_sphere, that_plane), etc |
| 01:27.38 | brlcad | which amounts in code to a is_tangent() callback or somesuch |
| 01:27.55 | brlcad | just like is_odd(), is_perpendicular(), is_nonnegative, etc |
| 01:28.28 | homovulgaris | hmm.. i was thinking of macros |
| 01:29.42 | brlcad | if you're going to need an *actual* parser, I would recommend sticking to either a) lex/yacc, b) using a standard interpreter, c) using the spirit portion of boost |
| 01:30.35 | brlcad | goes to let the dog out |
| 01:31.16 | homovulgaris | grr.. workrave message .. k.. i will check out the parser options |
| 01:44.04 | brlcad | we do a) and b) in other places in brl-cad already -- and by b) I mean something like using the tcl interpreter that we already integrate with (from the C side) |
| 01:44.27 | brlcad | c) becomes an option simply because you're already using boost and it's cross-platform |
| 01:44.47 | brlcad | having a BNF for the expressions would be ideal |
| 01:45.32 | brlcad | and intentionally not some custom hand-rolled parser even if it seems more simple at the start, less maintainable |
| 01:46.40 | homovulgaris | hmm.. TODO: BNF |
| 01:48.57 | homovulgaris | let me see what boost has to offer .. i have never used tcl.. Basically the parsing would happen on the objects passed from the C side of things generating functions which would be used by the C++ solvers/ constraint evaluation .. So we can have either tcl based systems or C++ based parsers |
| 01:50.18 | homovulgaris | brlcad: john replied to the message i sent , did it come on the group ? |
| 01:53.33 | homovulgaris | and the revision controllable image would mean something xml based like svg or uml like from dia ? |
| 01:54.01 | brlcad | I haven't received anything yet |
| 01:54.31 | brlcad | homovulgaris: something like that perhaps |
| 01:58.32 | homovulgaris | hmm.. k i am off to a short nap now..hopefully backtracking would be done in 2 hours after i wake up . |
| 01:59.11 | brlcad | cheers |
| 02:02.14 | homovulgaris | maybe i will do some doxygen editing ( rt division) and wiki additions and indendation/beautification after that. one day break from coding |
| 02:03.12 | brlcad | sounds like a plan :) |
| 02:03.44 | homovulgaris | should stop sleeping at 7.40 am and follow a more regular schedule |
| 02:03.58 | homovulgaris | bye all :) |
| 02:04.34 | brlcad | it works out conveniently ;) |
| 02:45.56 | brlcad | homovulgaris: fyi, I submitted a support request for the e-mail rejection |
| 02:46.20 | brlcad | I get the same rejection -- it happens at the mail server itself before it even gets to our mailing list |
| 02:46.49 | brlcad | so your message content apparently just looks too much like pharmacological spam |
| 02:47.18 | brlcad | maybe the malformed url you embedded |
| 02:50.27 | brlcad | apparently not, just tried with it cleaned up |
| 02:53.04 | brlcad | not the url at all, tried without |
| 02:53.32 | brlcad | has to just be the code, which makes the filter even more absurd.. awaiting support request results |
| 02:58.52 | yukonbob | hello, cadheads |
| 02:58.59 | brlcad | howdy |
| 02:59.20 | brlcad | sushi time! |
| 03:03.07 | yukonbob | Mmmm sushi |
| 03:04.01 | yukonbob | orders 2 toro, 2 unagi, a tomago and a rainbow roll |
| 03:59.28 | starseeker | is going to have to crack and see Wall-E, if the reviews are right... |
| 03:59.54 | yukonbob | feh -- disney |
| 04:00.10 | yukonbob | boycots that evil empire |
| 04:04.16 | starseeker | brlcad: If svg is OK I can look a making versions of the diagrams... |
| 04:34.26 | *** join/#brlcad madant (n=homovulg@202.63.233.61) | |
| 05:38.03 | starseeker | brlcad: Well, I have a start at least: http://my.bzflag.bz/~starseeker/test.png |
| 05:47.43 | *** join/#brlcad clock_ (n=clock@77-56-92-171.dclient.hispeed.ch) | |
| 05:53.19 | *** join/#brlcad alex_jon1 (n=juve@81.196.65.201) | |
| 06:20.52 | *** join/#brlcad elite01 (n=elite01@unaffiliated/elite01) | |
| 06:58.27 | *** join/#brlcad clock_ (n=clock@zux221-122-143.adsl.green.ch) | |
| 07:25.03 | *** join/#brlcad d_rossberg (n=rossberg@bz.bzflag.bz) | |
| 07:34.55 | CIA-22 | BRL-CAD: 03d_rossberg * r31664 10/brlcad/trunk/src/librt/primitives/revolve/revolve.c: |
| 07:34.55 | CIA-22 | BRL-CAD: rt_revolve_plot: moved variable declarations on top of the (function-)block |
| 07:34.55 | CIA-22 | BRL-CAD: rt_revolve_prep: added missing return statement |
| 07:43.13 | *** join/#brlcad clock_ (n=clock@zux221-122-143.adsl.green.ch) | |
| 10:12.04 | *** join/#brlcad docelic (n=docelic@78.134.206.197) | |
| 10:17.07 | *** join/#brlcad clock_ (n=clock@zux221-122-143.adsl.green.ch) | |
| 10:21.44 | *** join/#brlcad mafm (n=mafm@elnet-111.lip.pt) | |
| 10:23.13 | mafm | hi |
| 11:54.40 | brlcad | howdy mafm, how was the weekend? |
| 11:56.21 | brlcad | starseeker: not too shabby for that quick |
| 11:57.18 | brlcad | shame we can't use the same font, picky about that |
| 11:59.03 | starseeker | Yeah, that'll be tough |
| 11:59.17 | starseeker | used Bitstream Vera, IIRC |
| 11:59.55 | brlcad | open source font options are really weak |
| 12:00.14 | starseeker | loads update with more decorative bits on the brlcad outline |
| 12:01.06 | starseeker | Is that a worthwhile starting point? If so I can upload the svg somewhere |
| 12:01.12 | starseeker | or stick it in svn |
| 12:01.44 | brlcad | mm, hold off for now |
| 12:01.49 | starseeker | k |
| 12:03.48 | starseeker | is unlikely to get too much closer to the exact colors without a lot of fiddling |
| 12:04.37 | starseeker | If you could recover rgb, alpha settings and ordering of the ellipses from the original program that can be set up here I think... |
| 12:05.33 | starseeker | anyway, enough of that for now |
| 12:05.50 | starseeker | gets ready to rumble... |
| 12:27.22 | *** join/#brlcad docelic_ (n=docelic@78.134.201.7) | |
| 12:39.38 | mafm | brlcad: hot and sunny :9 |
| 12:39.39 | mafm | :) |
| 12:43.16 | mafm | so did you have the chance to test the program yet? |
| 12:43.27 | mafm | I had to leave when homovulgaris was at it |
| 13:08.07 | *** join/#brlcad CIA-22 (n=CIA@208.69.182.149) | |
| 13:59.22 | ``Erik | *yawn* |
| 14:01.04 | mafm | agrees |
| 14:29.45 | *** join/#brlcad prasad_ (n=psilva@h-67-103-183-185.mclnva23.covad.net) | |
| 15:16.19 | PrezKennnedy | brlcad, you keeping my bro busy? |
| 16:03.30 | *** join/#brlcad pacman87 (n=timothy@71.170.63.120) | |
| 16:05.15 | *** join/#brlcad PrezKennnedy (n=Matthew@whitecalf.net) [NETSPLIT VICTIM] | |
| 16:05.15 | *** join/#brlcad ``Erik (i=erik@c-68-54-174-162.hsd1.md.comcast.net) [NETSPLIT VICTIM] | |
| 17:37.17 | mafm | bye |
| 17:47.44 | *** join/#brlcad clock_ (n=clock@77-56-93-210.dclient.hispeed.ch) | |
| 18:08.43 | brlcad | PrezKennnedy: he says yes |
| 18:10.54 | PrezKennnedy | you all upstairs in that open room? |
| 18:35.40 | *** join/#brlcad CIA-22 (n=CIA@208.69.182.149) | |
| 18:37.33 | CIA-22 | BRL-CAD: 03mafm * r31666 10/rt^3/trunk/src/g3d/ (CommandInterpreter.cxx CommandInterpreter.h): Several bugfixes and improvements, still WIP |
| 18:37.33 | CIA-22 | BRL-CAD: 03mafm * r31667 10/rt^3/trunk/src/g3d/ (GuiCommandOverlay.cxx GuiConsole.cxx): Linking Console and CommandOverlay to CommandInterpreter |
| 18:38.37 | CIA-22 | BRL-CAD: 03mafm * r31668 10/rt^3/trunk/src/g3d/Logger.h: Method to translate the log levels to strings set to public -- it's not harmful and other code can take advantage of it. |
| 19:07.21 | *** join/#brlcad andrecastelo (n=chatzill@189.71.10.110) | |
| 19:07.28 | andrecastelo | hey guys |
| 19:11.46 | poolio | andrecastelo: how was vacation? |
| 19:13.12 | andrecastelo | poolio: not so good, too cold.. and i couldn't code at all |
| 19:13.52 | poolio | ah, sorry. where'd you go? |
| 19:14.27 | andrecastelo | Rio de Janeiro |
| 19:22.08 | poolio | Sounds cool :) |
| 20:55.12 | brlcad | andrecastelo: welcome back! |
| 20:56.29 | andrecastelo | brlcad: thanks! |
| 21:10.13 | *** join/#brlcad CIA-22 (n=CIA@208.69.182.149) | |
| 21:31.20 | poolio | brlcad: I think U-V mapping just clicked in my head :D |
| 21:31.35 | poolio | The whole directional trim is in relation to the coordinates defines as control points, right? |
| 21:40.30 | brlcad | sentance does not parse :) |
| 21:40.51 | brlcad | trimmings are on surfaces |
| 21:41.55 | brlcad | surfaces are defined in terms of a UV mapping, so yeah.. the trim curves are in relation to the 3d control points used for the surface |
| 21:57.35 | poolio | yeah...the "what is the u-v direction in relation to in 3-space" was my main confusion |
| 21:57.58 | poolio | I think I've got it right in my head...let me try to implement :) |
| 21:58.43 | poolio | And in terms of defining 3d control points, is it pretty arbitrary? Like, does it have to be [0,1]? The example cubes use (0,0) (0,1) (1,0) (1,1) |
| 23:05.46 | brlcad | zero-to-one UV mappings are usually just pretty damn convenient |
| 23:06.54 | brlcad | pretty common |
| 23:32.38 | PrezKennnedy | hey brlcad! |
