| 00:07.58 | *** join/#brlcad smurfette (i=Pandora@c-69-247-220-102.hsd1.mo.comcast.net) | |
| 00:08.17 | CIA-23 | BRL-CAD: 03brlcad * r32468 10/brlcad/trunk/m4/ (compiler.m4 epsilon.m4 stage.m4): list the required BC dependencies |
| 00:09.38 | *** join/#brlcad Twingy (n=justin@74.92.144.217) | |
| 00:29.40 | *** join/#brlcad punkrockgirl (i=Pandora@c-69-247-220-102.hsd1.mo.comcast.net) | |
| 00:47.16 | *** join/#brlcad andrecastelo (n=chatzill@189.71.11.154) | |
| 01:03.54 | pacman87 | success! |
| 01:05.11 | pacman87 | https://webspace.utexas.edu/trv82/www/rev_rt22.png |
| 01:05.25 | pacman87 | uv mapping |
| 01:08.13 | Ralith | yay! |
| 01:08.27 | Ralith | wait, how do you uvmap a non-mesh object? O.o |
| 01:10.47 | pacman87 | each face has its own uv-space |
| 01:12.13 | Ralith | so faces are tesselated? |
| 01:12.46 | CIA-23 | BRL-CAD: 03pacman87 * r32469 10/brlcad/trunk/src/librt/primitives/revolve/revolve.c: rt_revolve_uv() now works, several changes made to how data from the hit is stored in order to calculate (u,v) |
| 01:13.39 | pacman87 | well, for the start/end faces, the u/v coords are just the 2d hitpoint scaled by the bounds of the sketch |
| 01:14.25 | Ralith | I suppose it doesn't help that I'm not really familiar with UV |
| 01:14.31 | *** join/#brlcad smurfette (i=Pandora@c-69-247-220-102.hsd1.mo.comcast.net) | |
| 01:17.06 | CIA-23 | BRL-CAD: 03pacman87 * r32470 10/brlcad/trunk/include/rtgeom.h: vect_t v is no longer needed by revolve, remove it from rt_revolve_internal |
| 01:36.13 | *** join/#brlcad punkrockgirl (i=Pandora@c-69-247-220-102.hsd1.mo.comcast.net) | |
| 01:36.57 | brlcad | howdy punkrockgirl |
| 01:37.13 | brlcad | pacman87: awesome :-) |
| 01:57.01 | *** join/#brlcad smurfette (i=Pandora@c-69-247-220-102.hsd1.mo.comcast.net) | |
| 02:04.01 | andrecastelo | hey guys |
| 02:04.26 | brlcad | howdies |
| 02:04.45 | andrecastelo | howdy brlcad |
| 02:04.53 | andrecastelo | how are things? |
| 02:05.35 | brlcad | still decompressing |
| 02:05.46 | andrecastelo | decompressing? |
| 02:05.55 | brlcad | decompressing after siggraph |
| 02:06.31 | brlcad | letting my brain relax all of the ideas that have built up |
| 02:07.06 | andrecastelo | wishes to go next year |
| 02:08.06 | brlcad | tis good stuff |
| 02:08.45 | brlcad | make your path tracer kick arse, get a paper accepted on it -- then it's much cheaper ;) |
| 02:09.30 | andrecastelo | is it possible to write a paper about mlt? |
| 02:09.54 | andrecastelo | i mean, the algorithm is already done and stuff |
| 02:10.22 | brlcad | there's always ways to improve upon algorithms |
| 02:10.28 | brlcad | make it faster, better |
| 02:11.47 | andrecastelo | ponders |
| 02:27.39 | yukonbob | waves in |
| 02:27.43 | yukonbob | hello, cadheads |
| 02:29.52 | Ralith | don't forget prettier |
| 02:36.18 | CIA-23 | BRL-CAD: 03brlcad * r32471 10/brlcad/trunk/m4/prefix.m4: break the BRLCAD_ROOT and BRLCAD_DATA checks into BC macros so configure.ac can be trimmed down some more. add a pausing statement in order to emphasize the warnings. |
| 02:36.47 | *** join/#brlcad cad82 (n=4646a08c@bz.bzflag.bz) | |
| 02:37.06 | CIA-23 | BRL-CAD: 03brlcad * r32472 10/brlcad/trunk/configure.ac: use the new BC_BRLCAD_ROOT and BC_BRLCAD_DATA macros so we can trim down configure.ac closer to 4k. devs will have to run autogen.sh in order to pick up the update. |
| 02:41.59 | *** join/#brlcad punkrockgirl (i=Pandora@c-69-247-220-102.hsd1.mo.comcast.net) | |
| 03:04.05 | *** join/#brlcad smurfette (i=Pandora@c-69-247-220-102.hsd1.mo.comcast.net) | |
| 03:25.00 | *** join/#brlcad punkrockgirl (i=Pandora@c-69-247-220-102.hsd1.mo.comcast.net) | |
| 03:28.49 | CIA-23 | BRL-CAD: 03homovulgaris * r32473 10/brlcad/trunk/src/libpc/ (NOTES pcVariable.cpp pcVariable.h): adding iterator methods to Domain using boost indirect iterator, :) 1st post-gsoc commit |
| 03:48.48 | *** join/#brlcad smurfette (i=Pandora@c-69-247-220-102.hsd1.mo.comcast.net) | |
| 03:56.52 | *** join/#brlcad csanyipal (n=csanyipa@91.102.231.33) | |
| 03:57.24 | csanyipal | Hi |
| 04:09.48 | *** join/#brlcad punkrockgirl (i=Pandora@c-69-247-220-102.hsd1.mo.comcast.net) | |
| 05:24.05 | CIA-23 | BRL-CAD: 03brlcad * r32474 10/brlcad/trunk/m4/epsilon.m4: BC_TRY_RUN_OUTPUT wasn't set up to take no arguments. fix that so it works with AC_REQUIRE. |
| 05:38.52 | CIA-23 | BRL-CAD: 03brlcad * r32475 10/brlcad/trunk/src/other/tcl/generic/ (tcl.h tclInt.decls tclInt.h tclIntDecls.h tclIntPlatDecls.h): argh, quell the fracking warnings even if they will be clobbered. |
| 06:18.38 | CIA-23 | BRL-CAD: 03brlcad * r32476 10/brlcad/trunk/doc/IDEAS: |
| 06:18.38 | CIA-23 | BRL-CAD: make it a little more practical. make it a general 'how to get started' guide |
| 06:18.38 | CIA-23 | BRL-CAD: for new contributors instead of a smattering of development ideas. the ideas it |
| 06:18.38 | CIA-23 | BRL-CAD: used to have were all already included in on http://brlcad.org/~sean/ideas.html |
| 06:18.39 | CIA-23 | BRL-CAD: anyways |
| 06:20.23 | Ralith | brlcad: so did you get that vmath switch into svn? |
| 06:25.03 | brlcad | Ralith: ah! that was pushed back into the recesses of my mind during siggraph |
| 06:25.24 | brlcad | ran into a regression test failure before leaving so I couldn't just commit it |
| 06:26.14 | brlcad | I'll have to see where I left off |
| 06:27.26 | Ralith | aw. |
| 06:29.21 | brlcad | shouldn't take long |
| 06:44.46 | *** join/#brlcad cad47 (n=5ae34c4f@bz.bzflag.bz) | |
| 06:49.34 | *** join/#brlcad csanyipal (n=csanyipa@91.102.231.33) | |
| 07:03.49 | *** join/#brlcad tofu (n=sean@bz.bzflag.bz) | |
| 07:31.31 | *** join/#brlcad clock_ (n=clock@84-72-91-240.dclient.hispeed.ch) | |
| 08:00.40 | *** join/#brlcad Axman6 (n=Axman6@pdpc/supporter/student/Axman6) | |
| 10:26.25 | *** join/#brlcad mafm (n=mafm@elnet-111.lip.pt) | |
| 10:26.36 | mafm | hi |
| 11:01.52 | *** join/#brlcad elite01 (n=elite01@unaffiliated/elite01) | |
| 11:46.08 | *** join/#brlcad Elperion (n=Bary@p5B14F076.dip.t-dialin.net) | |
| 11:48.59 | *** join/#brlcad thing0 (n=ric@123.208.18.82) | |
| 12:55.54 | *** join/#brlcad prasad_ (n=psilva@static-70-108-244-218.res.east.verizon.net) | |
| 13:11.34 | *** join/#brlcad mafm (n=mafm@elnet-111.lip.pt) | |
| 13:11.42 | mafm | :P |
| 13:11.51 | mafm | my lab is hiring new network admins |
| 13:12.05 | tofu | is that a good thing? |
| 13:12.16 | mafm | :D |
| 13:12.33 | mafm | just complaining about them |
| 13:12.41 | mafm | I think that I won't spend much more time here anyway |
| 13:13.03 | brlcad | :( |
| 13:13.31 | mafm | why the sad face? |
| 13:13.33 | brlcad | you were just getting started, doing so well! |
| 13:13.43 | mafm | oh |
| 13:13.48 | mafm | I mean working for the lab |
| 13:13.53 | brlcad | ah |
| 13:13.58 | brlcad | then :) |
| 13:14.18 | mafm | I got a new tempting job offer that probably I'll accept |
| 13:15.05 | brlcad | doing what? |
| 13:15.27 | mafm | programming communication modules of Galileo satellites |
| 13:15.50 | mafm | outsourcing :( |
| 13:16.19 | brlcad | could be fun |
| 13:16.42 | brlcad | could be tedious as hell and not fun too |
| 13:16.58 | mafm | it might be a start as developer, nobody takes me seriously with my foss experience |
| 13:17.13 | mafm | and I'm tired of grid/sysadmin things |
| 13:19.03 | mafm | (go out for a bit) |
| 13:20.24 | brlcad | I highly doubt it's so much your "foss experience" as it is just your experience to date |
| 13:20.39 | brlcad | you're just getting started in many respects |
| 13:21.35 | brlcad | there's plenty of people I know that I'd hire in an instant even though they *only* have foss experience |
| 13:31.26 | andrecastelo | good morning everyone |
| 13:31.28 | andrecastelo | :D |
| 13:31.46 | brlcad | morning andrecastelo |
| 13:31.51 | andrecastelo | brlcad: that's good to know, very good hehe |
| 13:32.06 | andrecastelo | (about hiring) |
| 13:32.12 | andrecastelo | morning brlcad |
| 13:32.23 | andrecastelo | how goes things? |
| 13:32.42 | brlcad | about ready to get back into the swing of things |
| 13:32.57 | andrecastelo | morning (although in your timezone it's more like afternoon) mafm :D |
| 13:34.04 | andrecastelo | sounds good brlcad :D |
| 13:34.51 | PrezKennedy | hey brlcad |
| 13:34.58 | PrezKennedy | how was siggraph? |
| 13:34.59 | brlcad | howdy PrezKennedy |
| 13:35.08 | brlcad | was pretty good |
| 13:35.21 | brlcad | lots of good stuff to be implemented |
| 14:01.32 | mafm | andrecastelo: full afternoon, 15h :) |
| 14:02.31 | mafm | brlcad: ohloh lists more than 2 years for me, and it's missing some important parts |
| 14:02.42 | mafm | and they don't even like me for junior positions |
| 14:03.48 | mafm | or well, getting only crappy Java/C# financial things, or webservices |
| 14:05.26 | mafm | (new network outage announced...) |
| 14:41.59 | *** join/#brlcad ``Erik_ (i=erik@c-68-54-174-162.hsd1.md.comcast.net) | |
| 15:00.01 | *** join/#brlcad cad20 (n=50489d56@bz.bzflag.bz) | |
| 15:51.27 | brlcad | mafm: like I said, just getting started ;) |
| 15:52.27 | brlcad | not that ohloh stats are any useful basis to hire or put on a resume |
| 15:53.12 | brlcad | I just mean overall quality/quantity of work -- major contributions in oss are just as recognized as having some big-name company on your resume |
| 15:53.25 | brlcad | presuming you put the effort into it and make it shine |
| 15:53.36 | brlcad | the new gui has that potential for impact and then some |
| 15:53.54 | mafm | well, ohloh is just an example, and not just about statistics |
| 15:54.11 | mafm | it also has links for things that you've coded |
| 15:54.41 | mafm | which in general is a better idea to look at than making random idiotic tests/questions about pieces of code or what-if questions, I think |
| 15:56.11 | brlcad | sometimes |
| 16:05.07 | mafm | anyway |
| 16:05.46 | mafm | for initialiting GED_INIT, you have to pass a valid rt_wdb? I'm getting error strings when passing zero |
| 16:06.14 | brlcad | I would expect so |
| 16:07.13 | mafm | wdb_init? |
| 16:07.27 | brlcad | remember what I said earlier, the ged struct is a container for your application state which includes things like pointers to an open geometry file, loaded geometry, etc |
| 16:08.07 | brlcad | so you're basically getting into the librt and libwdb apis now since you're trying to manage that state directly |
| 16:11.36 | mafm | I see |
| 16:13.04 | brlcad | you'll have to do what mged does in some respects, which for read/write geometry will probably amount to something like wdb_dbopen() |
| 16:13.27 | brlcad | which takes a database instance (a db_i) obtained after db_open |
| 16:15.52 | mafm | does mged already use libged? |
| 16:16.03 | brlcad | yes |
| 16:16.22 | brlcad | about 80% migrated |
| 16:16.24 | mafm | oh, I thought that it was independent at this point |
| 16:16.37 | brlcad | nope, it's been hooked into mged from the start |
| 16:16.49 | brlcad | hence all the instability on trunk lately |
| 16:17.40 | brlcad | bob's been refactoring and cleaning up functionality in mged while he performs the migration, decoupling the implementation from tcl, keeping it hooked into mged using the new ged routines, etc |
| 16:29.27 | mafm | I see |
| 16:29.45 | mafm | a bit intricated process, but I'll manage :) |
| 16:30.48 | brlcad | yeah, the geometry engine and geometry service are meant to clean up that interface to make it much more simple, but you're ahead of the curve |
| 16:31.53 | *** join/#brlcad CIA-23 (i=cia@208.69.182.149) | |
| 16:34.56 | mafm | sooo BRL-CAD always puts the data on disk? |
| 16:35.00 | brlcad | no, you can create an in-memory db |
| 16:36.03 | brlcad | mged manages in-memory db access when you're in an edit state, gtransfer maintains an in-memory db for ray-tracing objects received over the network |
| 16:37.17 | brlcad | db_open_inmem() instead of db_open() |
| 16:38.19 | brlcad | see src/gtools/g_transfer.c for sample code |
| 16:50.31 | CIA-23 | BRL-CAD: 03mafm * r32477 10/brlcad/trunk/src/gtools/g_transfer.c: Typos |
| 16:52.55 | mafm | so brlcad, I have to use brl-cad specific stuff in the base classes, right? |
| 16:53.12 | brlcad | what do you mean? |
| 16:53.30 | brlcad | which base classes |
| 16:53.42 | mafm | like storing database references in the main classes, Application, or something to that effect |
| 16:53.58 | mafm | base as in main, basic |
| 16:55.22 | brlcad | it'll obviously have to be stored somewhere -- if you want to do it "right", you could help develop the GE OO layer |
| 16:55.46 | brlcad | otherwise yeah, I'd think you'd have to store them somewhere |
| 16:56.01 | brlcad | either in a base class or a simple wrapper/container that you write |
| 16:56.11 | brlcad | s/base/main data/ |
| 16:56.17 | mafm | just checking that we're in the same page, obviously in this aspect the thin client has to be a bit dependent :) |
| 16:58.09 | mafm | maybe I should use a class to store GED-related data? it could be a start for GE OO layer (I don't have idea on how to contribute to that at this point, before grasping the details of how it works) |
| 16:58.48 | brlcad | yeah, that's probably a good idea |
| 17:03.49 | mafm | should I program the communication protocol myself? |
| 17:12.58 | brlcad | no, there's a guy working on the protocol already -- that would be almost entirely wasted effort |
| 17:13.25 | mafm | where's that? |
| 17:13.39 | brlcad | it's already in the rt^3 module |
| 17:13.48 | brlcad | dave's working on that part |
| 17:14.59 | mafm | stractNet ? |
| 17:15.55 | brlcad | yes |
| 17:16.24 | mafm | so I shouldn't use libpkg directly? |
| 17:16.59 | CIA-23 | BRL-CAD: 03brlcad * r32478 10/brlcad/trunk/src/gtools/g_transfer.c: ttcp wasn't a typo ;) |
| 17:17.53 | brlcad | mafm: you should and eventually will -- just a question of whether you want to do it sooner or later, and what you're trying to accomplish :) |
| 17:18.01 | mafm | it was referring to the command ttcp? |
| 17:18.56 | mafm | well, I don't have a clear view of the whole picture |
| 17:19.07 | brlcad | stractNet (which shall be renamed, I swear) can be thought of as the communication portion of the GS .. which has to be hooked into the GE as it comes into existence .. which hooks into libged |
| 17:19.33 | mafm | when you tell me that the protocol is stractNet, I understand that it's an upper layer above libpkg, so I shouldn't use it directly |
| 17:21.09 | brlcad | you shouldn't need to use it directly -- the client only indirectly will be interfaced with it through the Geometry Service |
| 17:22.19 | brlcad | but the point is that those portions aren't yet ready, there's a lot of functionality still be written -- how the front-end actually talks with the back-end, how the GS uses the GE, how GE uses libged, migration of libged from mged itself ... |
| 17:22.44 | mafm | seesh :) |
| 17:22.52 | brlcad | so if you want geometry to visualize, your best bet for the near time (i.e. sometime this month) is to use libged directly since that's where it starts |
| 17:23.13 | mafm | so I probably should do that, yep |
| 17:23.15 | brlcad | you're working on a task that has several manyears of effort associated with it |
| 17:23.30 | brlcad | all part of making a powerful new gui |
| 17:23.40 | brlcad | in a scalable fashion |
| 17:24.02 | mafm | FTW-GUI :) |
| 17:24.31 | mafm | well, so I prefer to be conservative at this point |
| 17:24.41 | prasad_ | so the marketing guy dropped by the office |
| 17:24.44 | brlcad | and yes, ttcp refers to the old unix ttcp command used for raw tcp transfers or for "testing tcp" |
| 17:24.50 | prasad_ | said a hulk of a man dropped by and mentioned me |
| 17:24.51 | prasad_ | ;) |
| 17:24.57 | brlcad | prasad_: heh |
| 17:25.24 | brlcad | feel puny in the muscles atm |
| 17:25.38 | brlcad | haven't been to the gym in a long while |
| 17:34.46 | mafm | btw, is there going to be some people working on g3d from this point onwards? |
| 17:34.56 | mafm | I mean, "officially" |
| 17:35.25 | brlcad | all those pieces I talked about directly relate to the editor |
| 17:35.39 | brlcad | just working on it from the bottom up instead of top down |
| 17:36.19 | brlcad | so as those pieces get finished (later this year is expected for some of them), then the attention is towards the editor |
| 17:36.20 | mafm | I'm talking in the g3d/ dir |
| 17:37.07 | brlcad | it's highly likely that folks will be rummaging around the g3d dir, yes :) |
| 17:37.15 | brlcad | myself for one :) |
| 17:37.17 | starseeker | just can't get into this new sourceforge interface |
| 17:37.27 | brlcad | funky, eh? |
| 17:37.35 | starseeker | wants to figure out why he doesn't have fonts in g3d... |
| 17:37.55 | brlcad | starseeker: if you have some feedback, I'd be glad to send it forward -- they're asking me how I feel about it |
| 17:38.01 | starseeker | I keep looking at the "at a glance" window sf puts up by default and wanting to shout "I have more screen space, USE IT" |
| 17:38.26 | mafm | never experienced much of sf's new look yet |
| 17:38.54 | brlcad | which reminds me that I have a half dozen e-mails from sf staffers that I *really* should respond to soon |
| 17:39.15 | mafm | so brlcad, is there a need for organized efforts/communication, or just ml/irc channel as usual? |
| 17:39.33 | starseeker | stretches fingers and gets ready to put up some source tarballs |
| 17:40.01 | brlcad | mafm: there is a strong need for that, but that'd still be over ml/irc no? |
| 17:40.41 | brlcad | some of it is getting some of the big-picture documents up on the site, details into the wiki, a running list of what needs to be worked on |
| 17:40.55 | mafm | starseeker: about fonts, maybe you could try to compile Ogre (from trunk) yourself |
| 17:41.05 | mafm | and see whether it works better |
| 17:41.48 | starseeker | mafm: That's a thought. I can compile the one in the rt^3 trunk, although I'm getting a complaint about missing bio.h when I try building g3d |
| 17:43.00 | mafm | I think that it's a missing include in ged.h, I defined a var to 0 to not include Windows things |
| 17:44.45 | mafm | brlcad: well, my life for the following weeks is more or less like this: |
| 17:44.50 | mafm | - laptop dying at home |
| 17:45.20 | brlcad | heh, ouch |
| 17:45.21 | mafm | I can use it only for 1h30 or so |
| 17:45.42 | mafm | I ordered a new one, but it's going to get to my parent's home by the beginning of september |
| 17:47.42 | mafm | in the meantime I have to find a new flat to live, preferably before the end of the month, and probably it won't have internet |
| 17:47.49 | brlcad | a new laptop or a new battery? |
| 17:48.08 | mafm | I think that the problem is the circuit charging the battery, because it won't boot without it |
| 17:48.35 | mafm | and the led for charging battery is intermitent (without regularity) |
| 17:50.04 | mafm | if I start a new job during next week, I don't know if I'm going to be able to connect from there (so at least I can participate a bit in IRC) |
| 17:50.27 | brlcad | there is the web irc interface if you're blocked ;) |
| 17:50.35 | brlcad | and the mailing list of course |
| 17:51.18 | mafm | and I still hope to visit turkey with the lab in a conference in mid-end september |
| 17:51.36 | brlcad | it's odd that the laptop itself would have a problem charging -- do you have another battery to test? |
| 17:51.42 | brlcad | or is that what you're sending to your parents? |
| 17:52.12 | mafm | so I wanted to tell you about this in the case that you want to start participating actively in g3d/ :) |
| 17:52.42 | mafm | nope I don't have batteries, and they cost 100 euros or so in Portugal :S |
| 17:52.52 | mafm | I ordered a new laptop from Dell |
| 17:53.02 | mafm | does not recommend to buy Asus laptops :PPP |
| 17:53.46 | mafm | I send it over to there because it's free shipping and I'll be visiting them shortly after shipping it |
| 17:53.54 | brlcad | i'd never buy an asus laptop regardless :) |
| 17:53.59 | mafm | send it -> asked them to send it there :) |
| 17:54.46 | brlcad | 100 eu isn't so bad if the laptop isn't too old |
| 17:55.25 | mafm | 2+ years old, half the memory (512 module went away a couple of months ago) :D |
| 17:55.35 | mafm | and I'm not even sure if it's the battery or what |
| 17:55.48 | mafm | theoretically it should work with the battery removed |
| 17:55.58 | brlcad | yeah, it should, doesn't? |
| 17:56.06 | mafm | and when it's only on battery it works for 1h30, a bit short but "normal" |
| 17:56.13 | mafm | nope, it doesn't |
| 17:56.20 | brlcad | yikes, that's f'd up |
| 17:56.27 | mafm | yep, it's very strange |
| 17:57.06 | mafm | so when I have it connected (with battery + ac), it runs on battery and recharges, but only at 1/5th the speed of discharging |
| 17:57.14 | brlcad | debates .. hours in gym or hours writing e-mails |
| 17:57.21 | mafm | then spends all night and next day to recharge to 100% :) |
| 17:58.22 | mafm | I'd say gym if there's some nice girl around :P |
| 17:59.32 | brlcad | there are always nice girls at one of the gyms I go to :) |
| 17:59.48 | PrezKennedy | signs up for brlcad's gym |
| 18:00.01 | brlcad | not that I go there for that reason, but eye candy is always a plus |
| 18:02.32 | mafm | would only go to the gym for the eye candy :P |
| 18:10.50 | brlcad | thinks e-mail may win today |
| 18:20.28 | mafm | :S |
| 18:20.47 | mafm | I think that I got which is the error with ged.h and my libs |
| 18:23.44 | mafm | /* Element names in homogeneous vector (4-tuple) */ |
| 18:23.46 | mafm | #define X 0 |
| 18:23.47 | mafm | ... |
| 18:24.22 | CIA-23 | BRL-CAD: 03homovulgaris * r32479 10/brlcad/trunk/src/libpc/ (pcVariable.cpp pcVariable.h): storeValue() and restoreValue()methods added to Variable, adding methods to check the position of the present variable value in the domain |
| 18:24.27 | mafm | (in vmath.h) |
| 18:24.36 | mafm | is there a possible way that these can go away? |
| 18:26.50 | mafm | or well, to be undefined by the end of the file? :) |
| 18:45.32 | CIA-23 | BRL-CAD: 03homovulgaris * r32480 10/brlcad/trunk/src/libpc/ (pcSolver.h pcVariable.h): code for atUpperBoundary, atCriticalAbove and similar functions, modifying the PCSolver to use these methods for the constraint solution |
| 18:48.42 | brlcad | starseeker: looks good to me |
| 18:48.51 | starseeker | cool :-) |
| 18:49.00 | starseeker | does happy dance - 1st release! |
| 18:51.02 | *** topic/#brlcad by brlcad -> BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || Channel logs at http://ibot.rikers.org/%23brlcad/ || The 2008 Google Summer of Code is complete! *sniff* -- Congratulations deserved all around to our students for their efforts || (Source) Release 7.12.6 posted 2008-08-19 | |
| 18:54.40 | CIA-23 | BRL-CAD: 03homovulgaris * r32481 10/brlcad/trunk/src/libpc/pcVariable.h: correction to last revision, getStep() defined for Variable |
| 18:55.12 | brlcad | mafm: I was talking about those with ralith just a week ago |
| 18:55.16 | *** join/#brlcad csanyipal (n=csanyipa@91.102.231.33) | |
| 18:55.24 | brlcad | I have a possible fix, but it's still being tested |
| 18:55.49 | brlcad | it's usually been easy enough to work around the problem or undef in the places that cause problems |
| 18:59.14 | *** part/#brlcad csanyipal (n=csanyipa@91.102.231.33) | |
| 18:59.39 | brlcad | there's not much point in having them if they're undefined as they're meant to be convenience indices so that the code is more readable |
| 18:59.50 | brlcad | still, looking into a possible fix, tbd |
| 19:00.55 | *** join/#brlcad csanyipal (n=csanyipa@91.102.231.33) | |
| 19:01.04 | csanyipal | Hi, |
| 19:34.23 | mafm | brlcad: I cannot use more libged until it's removed, conflicts with OIS and other Ogre things |
| 19:34.27 | mafm | hi csanyipal |
| 19:36.30 | brlcad | mafm: que? |
| 19:36.35 | brlcad | just undef them and you're fine |
| 19:36.54 | brlcad | howdy csanyipal |
| 19:36.59 | mafm | in the .cxx? |
| 19:37.04 | brlcad | after the #include |
| 19:37.11 | brlcad | before including the other headers |
| 19:37.17 | mafm | also: /usr/brlcad/include/brlcad/ged.h:36:17: error: bio.h: No such file or directory |
| 19:37.43 | mafm | #define GED_USE_RUN_RT 1 |
| 19:37.45 | mafm | #if GED_USE_RUN_RT |
| 19:37.46 | mafm | /* Seems to be needed on windows if using ged_run_rt */ |
| 19:37.48 | mafm | #include "bio.h" |
| 19:37.49 | mafm | #endif |
| 19:37.51 | brlcad | ah, bio.h isn't installed |
| 19:37.57 | brlcad | ged.h shouldn't be using it |
| 19:38.17 | mafm | that's the error that starseeker was talking about, a while ago |
| 19:38.18 | brlcad | that's a hack bob put in apparently to make windows work |
| 19:39.11 | brlcad | will have to ask him what the actual error was, could be as simple as a missing io.h |
| 19:40.08 | brlcad | yeah, that was just a hack so he could move on |
| 19:40.30 | brlcad | he has 300 commands, over 100k lines of code to rework so he doesn't stop to figure out every little issue |
| 19:40.40 | brlcad | which ends up leaving turds like that one |
| 19:40.52 | mafm | :) |
| 19:42.30 | PrezKennedy | advantage of arriving early: leaving early! woooo! |
| 19:42.37 | PrezKennedy | runs home to slack off |
| 19:53.29 | *** join/#brlcad prasad_ (n=psilva@h-67-103-183-185.mclnva23.covad.net) | |
| 19:56.58 | CIA-23 | BRL-CAD: 03brlcad * r32482 10/brlcad/trunk/ (5 files in 2 dirs): |
| 19:56.58 | CIA-23 | BRL-CAD: make GED_USE_RUN_RT go away. bio.h is a private header and is not installed so |
| 19:56.58 | CIA-23 | BRL-CAD: it can't be used in ged.h (which is a public header that is installed). the |
| 19:56.58 | CIA-23 | BRL-CAD: ged.h header simply needs to declare and include the headers it uses like any |
| 19:56.58 | CIA-23 | BRL-CAD: other interface which includes the ged_run_rt struct if it's a public struct |
| 19:57.01 | CIA-23 | BRL-CAD: (and does seem out of place). remove all the associated conditionals that |
| 19:57.03 | CIA-23 | BRL-CAD: relate to GED_USE_RUN_RT while we're at it. |
| 20:05.10 | brlcad | mafm: that should do the trick, albeit untested on windows |
| 20:07.55 | starseeker | brlcad: What was the name of that book publisher you liked? |
| 20:08.23 | mafm | starseeker: so one error less for you, I guess |
| 20:08.37 | starseeker | mafm :-) |
| 20:08.48 | CIA-23 | BRL-CAD: 03brlcad * r32483 10/brlcad/trunk/src/libged/rt.c: merge the two ged_rt_output_handler functions into just one since the _WIN32 sections are relatively small. |
| 20:08.54 | brlcad | starseeker: blurb and lulu depending on the type of book |
| 20:09.42 | starseeker | brlcad: Ah, blurb - that was it |
| 20:10.17 | starseeker | wonders if the owners will start up a company named "blob" as well, just for the heck of it :-P |
| 20:10.56 | brlcad | neat quote |
| 20:10.59 | brlcad | "Good engineering accommodates the errors and omissions of users. Bad engineering relies on laws and conventions to overcome inherent systemic flaws. Laws and conventions are, therefore, indicative of bad engineering." |
| 20:11.32 | starseeker | interesting, but true only when the laws apply to engineering |
| 20:12.06 | starseeker | can see anarchists wanting no laws at all |
| 20:13.03 | starseeker | humans just need to be engineered better :-P |
| 20:13.10 | CIA-23 | BRL-CAD: 03mafm * r32484 10/rt^3/trunk/src/g3d/ (GedData.cxx GedData.h): Adding class to store libged-related data |
| 20:14.35 | brlcad | starseeker: 13! |
| 20:14.56 | starseeker | ? |
| 20:15.05 | starseeker | is missing context |
| 20:15.11 | brlcad | commits :) |
| 20:15.51 | brlcad | mafm and dawn are quickly rising up through the ranks too |
| 20:16.01 | starseeker | ah :-) |
| 20:16.02 | CIA-23 | BRL-CAD: 03mafm * r32485 10/rt^3/trunk/src/g3d/ (GeometryConversion.cxx GeometryConversion.h): Fixing doxygen/plain comments |
| 20:16.15 | starseeker | mafm: heh, good timing |
| 20:16.27 | mafm | meh, I just want to get home :) |
| 20:16.30 | mafm | 21h16 here |
| 20:16.50 | starseeker | drools at blurb printing quality |
| 20:16.53 | brlcad | mafm is exactly 100 commits away from entering the top ten :) |
| 20:17.31 | brlcad | their new large-format book is awesome |
| 20:17.51 | brlcad | starseeker: keep "catalog" in mind for sometime next year ;) |
| 20:18.12 | starseeker | catalog format? |
| 20:18.21 | brlcad | I really want to show them how it should be done |
| 20:18.44 | brlcad | the arl tdc |
| 20:18.51 | starseeker | Ah :-) |
| 20:18.52 | mafm | top ten of brl-cad contributors? |
| 20:19.03 | brlcad | mafm: yes |
| 20:19.33 | starseeker | brlcad: The tdc is less fun though - not public |
| 20:19.35 | brlcad | getting into the top ten isn't so hard, though it gets (almost exponentially) harder to break into each position after that |
| 20:19.41 | brlcad | starseeker: yes it is |
| 20:19.54 | starseeker | does double take |
| 20:19.58 | brlcad | at least we can make one that is |
| 20:20.04 | starseeker | ah |
| 20:20.25 | starseeker | Heh - Large format Landscape tdc with high quality rendering... drool |
| 20:20.37 | brlcad | yes, I LOVE that new book format |
| 20:20.49 | brlcad | it came out a couple months after I published mine |
| 20:21.14 | starseeker | would probably end up replacing the tires on everything for the new book ;-) |
| 20:21.23 | *** join/#brlcad prasad1 (n=psilva@static-70-108-244-218.res.east.verizon.net) | |
| 20:21.40 | brlcad | would work on getting path tracing working for a new book |
| 20:22.02 | starseeker | boy would that turn some heads |
| 20:22.07 | brlcad | global illumination, soft shadows, ambient occlusion, edge overlay |
| 20:22.27 | brlcad | two page spread per vehicle |
| 20:22.36 | brlcad | so you can show rendered and hidden-line |
| 20:22.53 | starseeker | we'd have to juice up rtedge too |
| 20:23.00 | starseeker | rummages for SIGGRAPH dvd |
| 20:23.42 | brlcad | it's a good 90% solution as it is -- there's a few things it could do better but for vehicle size, it'll catch most of the detail needed |
| 20:23.43 | mafm | brlcad: but I guess that only a small portion of the developers get accounted? |
| 20:24.23 | brlcad | mafm: no, that accounts for most |
| 20:24.39 | mafm | for all BRL-CAD's history? |
| 20:24.48 | brlcad | doesn't account for branch development and older contributors that committed via proxy, but that's otherwise nearly everyone |
| 20:25.11 | brlcad | search the commits, they go all the way back to 1983 |
| 20:25.20 | mafm | huh |
| 20:25.39 | brlcad | http://www.ohloh.net/projects/3996/commits?page=3112 |
| 20:25.48 | brlcad | not enough for you? :) |
| 20:26.17 | mafm | but if devels don't get registered and claim their account, they are listed as contributors anyway? |
| 20:26.48 | *** join/#brlcad Elperion (n=Bary@p5B14F076.dip.t-dialin.net) | |
| 20:27.31 | mafm | oh, it seems so |
| 20:28.28 | mafm | #17 atm :) |
| 20:28.49 | mafm | I would have think that the team was much bigger |
| 20:28.52 | CIA-23 | BRL-CAD: 03brlcad * r32486 10/brlcad/trunk/AUTHORS: credit nicholas reed for his summer coding efforts developing a new point primitive. |
| 20:29.18 | brlcad | nope, the team has been about 5-10 guys for most of its history |
| 20:29.28 | brlcad | there are 52 or so contributors |
| 20:29.36 | poolio | brlcad: was that point primitive stuff ever committed? |
| 20:29.44 | brlcad | lots of those are folks that work for a year really hard but then are off on other projects |
| 20:29.50 | brlcad | poolio: yes |
| 20:30.03 | poolio | does it work? |
| 20:30.13 | brlcad | it's incomplete and untested (peer-wise), but it's there and at least worked in demo :) |
| 20:30.28 | brlcad | I believe it actually does work |
| 20:30.32 | poolio | oh cool cool. so the summer students presented? |
| 20:30.33 | brlcad | he was pretty methodical |
| 20:30.52 | brlcad | I've not been back in yet since my trip |
| 20:30.55 | starseeker | brlcad: Does Blurb accept pdfs or do you have to use their software? |
| 20:31.19 | brlcad | starseeker: you have to use their software, though if you have a pdf it's really easy |
| 20:31.26 | brlcad | that's what I started with for mine |
| 20:31.32 | starseeker | meh. Sucks for Linux then |
| 20:31.41 | brlcad | why? |
| 20:32.02 | starseeker | Hard to submit it when they don't have a Linux version of the software |
| 20:32.11 | brlcad | it's pretty well-designed java software iirc (and suprisingly good/stable esp. for java software) |
| 20:32.20 | starseeker | Ah. |
| 20:33.09 | brlcad | it's not like you don't have access to other operating system(s) if needed :) |
| 20:33.40 | starseeker | He |
| 20:33.42 | starseeker | h |
| 20:33.47 | starseeker | true |
| 20:34.39 | CIA-23 | BRL-CAD: 03mafm * r32487 10/rt^3/trunk/src/g3d/Commands.h: Using program-wide data structures instead of testing on-demand ones |
| 20:35.27 | brlcad | 99! ;) |
| 20:36.16 | mafm | it's a moving target anyway :D |
| 20:36.35 | brlcad | only if starseeker gets there first |
| 20:36.46 | brlcad | cjohnson isn't likely to increase his count anytime soon |
| 20:37.01 | brlcad | ~seen cjohnson |
| 20:37.02 | ibot | cjohnson <n=cjohnson@71.5.32.3.ptr.us.xo.net> was last seen on IRC in channel #maemo, 25d 2h 49m 8s ago, saying: 'Is it possible to link the n800 up with a phone, via bluetooth or other, and send text messages?'. |
| 20:37.09 | brlcad | hm, that's not him |
| 20:38.29 | brlcad | oh well, it's been over a year |
| 20:39.17 | mafm | :) |
| 20:40.29 | brlcad | d_rossberg is the other one that might make it there first |
| 20:42.21 | brlcad | if pacman87 would make more succint commits, he'd be nearing the top ten too :) |
| 20:43.14 | mafm | brlcad: how to print bu_vls? vls_str[vls_offset] ? |
| 20:44.37 | mafm | or esoteric calls like init, bu_vls_addr(&vls), etc? |
| 20:49.26 | brlcad | you shouldn't access their internal structure |
| 20:49.47 | brlcad | if you want to print one, there are a variety of bu_vls_*() functions related |
| 20:50.13 | brlcad | that match usual string manipulation and stream printing |
| 20:51.04 | mafm | mmm |
| 20:51.18 | brlcad | bu_vls_addr() will give you a char* suitable for most uses if you need to pass it to something expecting a C string |
| 20:51.40 | brlcad | if you just want to print it, though, you can use bu_log() and the %S will print a bu_vls |
| 20:52.03 | brlcad | what are you trying to do with it? |
| 20:52.41 | mafm | bu_vls_addr() to print it in "%s"? |
| 20:52.48 | brlcad | yep |
| 20:52.51 | mafm | (ok, I just read what you said) |
| 20:54.42 | brlcad | if it's a string op, there is almost guaranteed a more suitable/optimized bu_vls_*() routine (e.g. better than calling strlen or strcmp, etc) |
| 20:55.59 | mafm | it's to append it to the output |
| 20:56.10 | mafm | e.g. to print the version string, from ged_version() |
| 20:56.19 | brlcad | output as in stdout? |
| 20:56.24 | brlcad | or some other stream? |
| 20:57.39 | mafm | some other stream -- to print in console |
| 20:57.47 | mafm | (gui console) |
| 20:59.24 | mafm | anyway, the main problem is taht I'm getting either no results (empty strings) or segfaults :) |
| 20:59.46 | mafm | it's 22h here, I guess that I'll have to leave the quest for top 10 for tomorrow :) |
| 20:59.53 | brlcad | heh |
| 21:00.56 | mafm | anyway, this looks about right, isn't it? |
| 21:00.59 | mafm | <PROTECTED> |
| 21:01.01 | mafm | <PROTECTED> |
| 21:01.02 | mafm | <PROTECTED> |
| 21:01.35 | brlcad | no |
| 21:01.48 | brlcad | bu_vls_addr is guaranteed to not return null |
| 21:01.58 | brlcad | presuming it has been initialized (which is required) |
| 21:02.30 | mafm | I see |
| 21:02.33 | brlcad | which ged_result_str has iirc |
| 21:02.35 | mafm | and the other part? |
| 21:02.37 | brlcad | so you can just use it |
| 21:03.34 | mafm | I mean, it's in there where the output of ged_version is put? |
| 21:04.25 | brlcad | yes |
| 21:04.46 | *** join/#brlcad thing0 (n=ric@123.208.124.191) | |
| 21:04.47 | brlcad | though you do realize that ged_version() is related to the version of a given .g file (e.g. '4' or '5') |
| 21:04.54 | brlcad | not the version of the library |
| 21:05.13 | brlcad | akin to typing 'version' inside mged |
| 21:05.44 | brlcad | so the gedp that you pass ged_version() needs to have a valid/opened geometry database |
| 21:06.28 | mafm | oh sheet :) |
| 21:07.22 | brlcad | hm, that is an unfortunate point of confusion |
| 21:07.33 | brlcad | the other libs do have a lib_version() routine that identifies them |
| 21:07.47 | mafm | I'm just trying to get simple commands, to know whether basic things work |
| 21:08.15 | brlcad | version is a good basic thing |
| 21:08.28 | brlcad | title and units are also good |
| 21:09.25 | mafm | I have also title, and it doesn't segfault but doesn't show anything |
| 21:10.31 | brlcad | did you open something with a title? :) |
| 21:10.39 | brlcad | mged -c db/moss.g title |
| 21:10.45 | CIA-23 | BRL-CAD: 03brlcad * r32488 10/brlcad/trunk/src/libged/wdb_obj.c: reword dbversion comment |
| 21:11.27 | mafm | haven't open anything, but I think that when you provide a parameter it should set it as title |
| 21:12.14 | mafm | http://img107.imageshack.us/my.php?image=brlcadtestkw5.png |
| 21:13.14 | brlcad | yes it should/does if you provide a title |
| 21:13.26 | brlcad | but not if you don't have a db open |
| 21:13.31 | brlcad | it should bitch at you |
| 21:13.42 | brlcad | no messages on your console? |
| 21:13.51 | brlcad | er, onto stdout |
| 21:14.00 | mafm | nope, and I print ged_log |
| 21:14.26 | mafm | (just after trying to print the title) |
| 21:14.37 | brlcad | yeah, it's calling GED_CHECK_DATABASE_OPEN |
| 21:14.40 | mafm | and no results either |
| 21:14.56 | mafm | and I open a inmem DB, not one on disk |
| 21:15.16 | mafm | <PROTECTED> |
| 21:15.18 | mafm | <PROTECTED> |
| 21:15.19 | mafm | <PROTECTED> |
| 21:15.21 | mafm | <PROTECTED> |
| 21:15.26 | brlcad | what happens if you just bu_log("testing\n"); |
| 21:15.49 | brlcad | sounds like it's just going into a void if stderr is gone |
| 21:16.17 | brlcad | ah, so you do that first .. that'll pass the test |
| 21:16.31 | brlcad | that's a valid (albeit empty) database |
| 21:17.37 | mafm | pre-testing |
| 21:17.38 | mafm | post-testing |
| 21:17.40 | mafm | :) |
| 21:17.44 | mafm | what prints in stdout |
| 21:17.57 | brlcad | bu_log will go to stderr |
| 21:18.02 | mafm | (which respectively wrap around the result and ged_log calls) |
| 21:18.20 | mafm | well, stderr -- I mean the xterm |
| 21:18.31 | brlcad | okay, so bu_logging is working |
| 21:20.03 | brlcad | bu_log("result: [%s]\n", bu_vls_addr(&g->ged_result_str)); |
| 21:20.54 | brlcad | after your three ged_title calls |
| 21:21.01 | mafm | http://img49.imageshack.us/my.php?image=brlcadtest2hy2.png -- for reference |
| 21:24.07 | mafm | brlcad: http://rafb.net/p/YKSlS986.html |
| 21:24.42 | mafm | so it should print that in the gui console, I'd say |
| 21:25.03 | mafm | anyway, almost 22h30 here, I really have to go now |
| 21:25.03 | brlcad | AH! |
| 21:25.09 | brlcad | you're not reading *which* result |
| 21:25.16 | mafm | hmm? |
| 21:25.16 | brlcad | there are non-valid result codes |
| 21:25.24 | brlcad | g->ged_result |
| 21:25.35 | mafm | isn't a kind of bool? |
| 21:25.51 | brlcad | no |
| 21:25.55 | brlcad | it's a bitmask |
| 21:25.55 | mafm | grr |
| 21:26.04 | mafm | joins C-haters |
| 21:26.06 | mafm | :P |
| 21:26.24 | brlcad | heh, it would be the same in C++ |
| 21:26.49 | brlcad | er, misspoke |
| 21:27.01 | brlcad | ged_result is a result object |
| 21:27.17 | brlcad | that just means that there is some response returned |
| 21:27.42 | brlcad | ged_result_flags tells you what to do |
| 21:27.46 | mafm | well, you can do that in C++, but you usually have better encapsulation to avoid some errors |
| 21:28.15 | mafm | so I have to apply GED_CHECK_* every time? |
| 21:29.03 | brlcad | for now, can probably just check if !ged_result_flags instead of if !ged_result |
| 21:29.15 | brlcad | no flags is expected result |
| 21:30.21 | brlcad | my bad (yet again) |
| 21:30.29 | brlcad | just check the return code! |
| 21:31.19 | brlcad | result = ged_title(..); .. if (result == BRLCAD_OK) .. |
| 21:32.02 | mafm | what about outputting logs? |
| 21:32.26 | mafm | they're only produced when !BRLCAD_OK, or under other conditions? |
| 21:32.49 | brlcad | what do you mean? |
| 21:32.52 | brlcad | like the READ_ONLY? |
| 21:32.58 | brlcad | that's a BRLCAD_ERROR return |
| 21:33.55 | mafm | <PROTECTED> |
| 21:33.56 | mafm | <PROTECTED> |
| 21:33.57 | brlcad | also, remember that you're working on "pre-alpha interface", an interface that can change |
| 21:33.58 | mafm | <PROTECTED> |
| 21:33.59 | mafm | <PROTECTED> |
| 21:34.01 | mafm | <PROTECTED> |
| 21:34.02 | mafm | so like this? |
| 21:35.02 | mafm | hmm, it looks like it uses &g->ged_result_str anyway, not &g->ged_log) |
| 21:35.19 | brlcad | yeah, ged_log doesn't make any sense to me |
| 21:35.24 | brlcad | don't think it's really needed |
| 21:35.32 | brlcad | should probably go away |
| 21:35.51 | brlcad | it's a log hook needed by the 'log' command so it can capture logging |
| 21:35.51 | mafm | and what about accumulating error strings? |
| 21:36.03 | mafm | result: [Sorry, this database is READ-ONLYSorry, this database is READ-ONLYSorry, this database is READ-ONLY] |
| 21:36.52 | brlcad | that's a bug in title, it should bu_vls_trunc(&gedp->ged_result_str, 0); |
| 21:37.03 | brlcad | i'm sure there are a LOT of those |
| 21:37.23 | brlcad | don't presently see it because the caller (i.e. mged) always truncs it itself presently |
| 21:37.59 | mafm | I see |
| 21:38.07 | mafm | well so, it's a start :) |
| 21:38.37 | brlcad | yeah, if you set the right mode on wdb_dbopen, it should work |
| 21:40.21 | brlcad | should be calling db_open_inmem(); |
| 21:40.31 | brlcad | ah, you are, never mind |
| 21:40.38 | mafm | yay, ged_version at least doesn't segfault! |
| 21:41.03 | mafm | but it's not very robust, ged_version() in libged doesn't check for missing argument (argv == 0) |
| 21:42.34 | mafm | w00t |
| 21:42.38 | mafm | and summary also works |
| 21:44.41 | mafm | keey, so almost 23h, enough is enough ;) |
| 21:44.43 | mafm | see you |
| 21:44.43 | CIA-23 | BRL-CAD: 03mafm * r32489 10/rt^3/trunk/src/g3d/Commands.h: Fixing libged commands, now they at least give some result and mostly work |
| 21:45.07 | brlcad | see ya! |
| 22:45.58 | *** join/#brlcad andrecastelo_ (n=chatzill@189.71.64.30) | |
| 23:41.16 | *** join/#brlcad Twingy (n=justin@74.92.144.217) | |
| 23:55.50 | *** join/#brlcad andrecastelo (n=chatzill@189.71.64.30) | |
