| 01:02.47 | *** join/#brlcad sydneysider (792c923d@gateway/web/freenode/ip.121.44.146.61) | |
| 01:02.56 | *** part/#brlcad sydneysider (792c923d@gateway/web/freenode/ip.121.44.146.61) | |
| 01:26.57 | *** join/#brlcad velociostrich (~nicholas@c-24-0-153-224.hsd1.pa.comcast.net) | |
| 02:27.24 | CIA-48 | BRL-CAD: 03abhi2011 * r47262 10/brlcad/trunk/src/libged/simulate/ (simcollisionalgo.cpp simrt.c simrt.h simulate.h simutils.h): Added logic to generate contact pairs, need to still find a way to properly generalize it to all cases |
| 02:38.12 | starseeker | brlcad: symlink... you mean my check in archer? |
| 02:39.05 | starseeker | it seems to be resolving the directory paths, but not switching the path to the final location - i.e. the behavior I would have hoped for, although I wasn't sure I would get it until I actually tried it |
| 02:47.07 | CIA-48 | BRL-CAD: 03starseeker * r47263 10/brlcad/trunk/src/tclscripts/hv3_man_browser_test.tcl: Shouldn't hurt anything and may make testing easier, go ahead and commit - the shell stuff... |
| 02:55.34 | starseeker | i.e. if the file itself is a symlink, it normalizes the path to that symlink but doesn't follow the symlink itself |
| 02:57.06 | starseeker | so if /usr/brlcad is a symlink to /usr/brlcad/rel-7.20.2, /usr/brlcad/bin/archer resolves to /usr/brlcad/rel-7.20.2/bin/archer |
| 02:57.17 | *** join/#brlcad velociostrich (~nicholas@c-24-0-153-224.hsd1.pa.comcast.net) | |
| 02:58.04 | starseeker | but if I symlink (say) /tmp/archer to /usr/brlcad/rel-7.20.2/bin/archer, tcl will normalize /tmp/archer to /tmp/archer and not follow the file symlink to /usr/brlcad/rel... |
| 02:59.06 | starseeker | at least, that's the behavior I'm observing here |
| 03:13.23 | CIA-48 | BRL-CAD: 03starseeker * r47264 10/brlcad/trunk/src/ (other/CMakeLists.txt tclscripts/hv3/hv3.tcl): |
| 03:13.23 | CIA-48 | BRL-CAD: Until the more powerful help browser has been worked out, let's go with a |
| 03:13.23 | CIA-48 | BRL-CAD: solution that at least avoids printing the error messages - there doesn't seem |
| 03:13.23 | CIA-48 | BRL-CAD: to be any actual regression in functionality due to *not* reading the css (not |
| 03:13.23 | CIA-48 | BRL-CAD: too surprising since it wasn't originally there at all) so turn off the full hv3 |
| 03:13.24 | CIA-48 | BRL-CAD: and quell the warning message in our local hv3 subset. Should let things |
| 03:13.25 | CIA-48 | BRL-CAD: proceed until the full-powered system gets sorted out. |
| 03:15.03 | starseeker | probably what I should have done in the first place... |
| 08:35.08 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 11:06.31 | *** join/#brlcad kaushikG (Kaushik@122.178.17.110) | |
| 11:06.47 | kaushikG | Hello |
| 11:08.14 | kaushikG | I'm interested in developing for BRL-CAD as my undergraduate final year project. Who would help me in this regard? |
| 16:16.37 | brlcad | left too quick! |
| 16:19.47 | brlcad | starseeker: so if perl isn't being used by cmake, it'd be great to not introduce it into the mix |
| 16:20.29 | brlcad | even if the cpan module is small, which I suspect it's not, it's pretty complicated for anything more than a one-shot processing (which WOULD be fine) |
| 16:25.29 | brlcad | but then like I mentioned, I think the best long-term goal is to get the docs for each command colocated with the commands so they can more easily stay in sync .. specifically with usage coming from the source code itself since it has to be there already |
| 16:47.13 | *** join/#brlcad yiyus (~124271242@je.je.je) | |
| 17:05.38 | abhi2011 | yes, could have gotten some one to work on the GUI for the simulation stuff :P |
| 17:42.23 | abhi2011 | is there a standard way to temporarily quell unused function variables |
| 17:42.50 | abhi2011 | i currently simply print there values so that they get used somewhere |
| 18:05.16 | starseeker | brlcad: that sounds like a step toward literate programming :-) |
| 18:05.52 | starseeker | one issue I see is if we put the "short help" statements in the code, there will be a tendency to just update those and not review the man page for that command (which may also need to be updated) |
| 18:06.30 | starseeker | that was my thought with the usage being extracted from the docbook - if we go that route, it *doesn't* have to be in the source code |
| 18:07.55 | starseeker | then 1) update the source 2) update the help statements in the code 3) review and update the docbook man page becomes just 1) update the source 2) review and update the docbook man page |
| 18:08.31 | starseeker | I didn't want (and don't want) to use perl to extract bits from the xml - my hope was xsl + xsltproc alone would be sufficient |
| 18:08.44 | starseeker | not convinced it isn't, for that matter |
| 18:52.13 | brlcad | abhi2011: you can wrap them in UNUSED() though printing them is good too since it's a reminder that you still need to use or lose them |
| 18:53.06 | brlcad | starseeker: the case of extended docs not getting update will always be an issue -- moving the synopsis to the code ensures that at least the usage is always correct |
| 18:54.38 | brlcad | 1 and 2 (updating sort and help statements) are effectively one in the same -- to add a new option means adding new code, which self-documents |
| 18:54.59 | brlcad | there would be no extended documentation for any new option, but then we could script that into a regression test |
| 18:55.18 | brlcad | checking the usage is much harder though |
| 18:55.32 | brlcad | not something that can be reliably tested for given the variety of synposes |
| 18:59.18 | starseeker | brlcad: but moving usage to the code doesn't really ensure it's always correct - it puts the usage "closer" to the coding action, but that doesn't necessarily mean anything |
| 18:59.54 | starseeker | and I sometimes wonder how useful the usage statements are without the full man page - they often don't help me much in isolation |
| 19:06.51 | starseeker | if we can script a check on the extended documentation in Docbook based on the command, couldn't we also do the same thing for a usage statement defined in docbook, once extracted to a txt file? |
| 19:40.56 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 20:05.42 | CIA-48 | BRL-CAD: 03abhi2011 * r47265 10/brlcad/trunk/src/libged/simulate/ (simcollisionalgo.cpp simrt.c): Generated the manifold, trying to inject them correctly into the bullet collision pipeline |
| 20:27.59 | CIA-48 | BRL-CAD: 03abhi2011 * r47266 10/brlcad/trunk/src/libged/simulate/simrt.c: Floating point issues, had to increase the limit of a loop by TOLerance to ensure rays are shot from edge to edge in overlap volume, strangely NEAR_EQUAL() doesnt seem to work |
| 20:57.27 | brlcad | starseeker: I wasn't talking about "moving" usage to the code -- that usage is actually derived from the code |
| 20:58.44 | brlcad | part of a bu_opt interface, supporting long and short options and their dependencies, working with bu_getopt() but also having a helper routine(s) to auto-generate usage statements |
| 20:58.55 | brlcad | or output xml or whatever really at that point |
| 20:59.07 | starseeker | oh, I see |
| 20:59.26 | brlcad | started getting into it with the libged zoom template, is a clear need |
| 20:59.39 | brlcad | so that's actually what I've been working on next |
| 21:00.07 | brlcad | just a little stalled by the nurbs and release review taking so long |
| 21:41.18 | CIA-48 | BRL-CAD: 03abhi2011 * r47267 10/brlcad/trunk/src/libged/simulate/ (simcollisionalgo.cpp simphysics.cpp simrt.c simulate.c): Bullet seems to be deleting the contact pairs, added some more callbacks to investigate |
| 21:46.48 | CIA-48 | BRL-CAD: 03abhi2011 * r47268 10/brlcad/trunk/src/libged/simulate/simulate.c: Manfold generation cant happen before the physics is run, otherwise the list of manifolds are cleared, it has to happen later |
| 22:49.46 | abhi2011 | i was wondering how bu_free knows how many bytes to free as there is size paramter to it : bu_free(current_manifold, "simulate : current_manifold"); |
| 22:51.15 | abhi2011 | *there is no size |
| 22:52.46 | abhi2011 | probably the C runtime keeps track of allocated chunks |
| 22:54.03 | brlcad | abhi2011: same way free() knows how to release memory from malloc() |
| 22:54.08 | brlcad | keeps track of the pointer |
| 22:54.20 | abhi2011 | yes, ok |