| 00:03.04 | CIA-23 | BRL-CAD: 03starseeker * r51985 10/brlcad/trunk/ (4 files in 4 dirs): Move some more functions/functionality into libnurbs. This is just to deal with compilation issues - needs some serious API consideration. |
| 00:03.42 | starseeker | ``Erik: that may deal with the compilation issue you were seeing - let me know |
| 00:09.10 | CIA-23 | BRL-CAD: 03starseeker * r51986 10/brlcad/trunk/include/CMakeLists.txt: Add nurbs.h to distcheck logic. |
| 00:59.38 | cristina | starseeker: I've been looking to where the "man" command is refered to. It is defined in ArcherCore.tcl as well. Does that suffice? I've put my command there but it isn't recognized. |
| 01:20.43 | CIA-23 | BRL-CAD: 03Cprecup 07http://brlcad.org * r4323 10/wiki/User:Cprecup/GSoC2012_progress: 13/08/2012 - fixed bug + started "graph" command integration in Archer |
| 01:33.37 | CIA-23 | BRL-CAD: 03starseeker * r51987 10/brlcad/trunk/src/ (libtclcad/tclcadAutoPath.c tclscripts/archer/ArcherCore.tcl): Put bare bones of Archer graph command in place. |
| 01:34.11 | starseeker | cristina: that makes the graph command in Archer "do something", but based on the error messages I'm guessing some MGED window structures are assumed? |
| 01:34.20 | starseeker | anyway, that should be enough to get you started |
| 01:37.10 | cristina | starseeker: ok, thank you. I didn't add this line: "exit facetize fracture g graph group hide human i \" |
| 01:47.50 | cristina | starseeker: as for your question, the graph procedure does determine the framebuffer window id and check if a window with that id is already opened before calling the constructor of GraphEditor class. |
| 02:06.14 | cristina | starseeker: regarding your last commit for the libtclcad/tclcadAutoPath.c file: when running the command "graph" in MGED I get now an empty window. I left the #ifdef #endif there because I couldn't handle this in case Adaptagrams wasn't available |
| 02:30.41 | starseeker | cristina: Ideally, "graph" should report something like "Adaptagrams not available" when you try to run it... |
| 02:31.24 | starseeker | maybe ged_graph could support some sort of query option that would let you detect this from Tcl land? |
| 02:32.24 | cristina | this is reported when wrapped C commands are trying to be ran ( graph_objects_positions, for example). For this Tcl procedure that doesn't have a corresponding C routine I couldn't do this. |
| 02:33.14 | cristina | Hm, so I should implement a ged_graph routine that is simply called when the graph command is ran, as I've done with graph_objects_positions? |
| 02:41.15 | starseeker | that's one possibility |
| 02:41.58 | starseeker | or you could just try using graph_objects_positions to find out what you need to know |
| 03:12.56 | brlcad | model repository is fixed |
| 03:27.41 | brlcad | cristina: one design issue I've been meaning to mention, it'd be good to group your top-level commands together under just one 'graph' command |
| 03:27.48 | brlcad | instead of a set of new commands |
| 03:31.49 | cristina | brlcad: Hello. Could you give me an example of such a command? I assume the C implementation for ged_graph_objects_positions will stay the same, as a separate routine. Am I wrong? Modifications should be done outside the dag.cpp file, right? |
| 03:32.14 | brlcad | it can be nearly identical if not identical, just grouped together |
| 03:32.25 | brlcad | source code can be organized however, identical even |
| 03:32.33 | brlcad | the change is just to the top-level command |
| 03:32.38 | brlcad | e.g., "graph" |
| 03:35.16 | cristina | Ok, I will work on it. The "graph" command corresponds just to a Tcl procedure for now. It has no back end C implementation. Is this alright? |
| 03:38.20 | brlcad | hm? |
| 03:40.50 | cristina | I was wondering if I can group the commands into the "graph" command just within the Tcl script or C/C++ implementation is needed. |
| 03:40.55 | cristina | I will study the issue |
| 03:41.08 | brlcad | ideally in C |
| 03:41.29 | brlcad | we want to be able to bind that as the single libged interface (even if that interface calls into other functions) |
| 03:43.16 | cristina | I understand, thank you |
| 03:47.53 | brlcad | cristina: it's a bit of overkill for what you need but src/libged/edit.c is a similarly grouped command that has subcommands |
| 03:51.06 | brlcad | select.c is a similar sub-command grouping, but less obvious |
| 03:54.51 | brlcad | ah, starseeker beat me to it .. also moved plane_ray and friends over due to compilation issues |
| 03:54.57 | brlcad | fortunately, nearly the same |
| 03:59.25 | CIA-23 | BRL-CAD: 03brlcad * r51988 10/brlcad/trunk/include/nurbs.h: header cleanup, remove unnecessary forward decl |
| 04:00.16 | CIA-23 | BRL-CAD: 03brlcad * r51989 10/brlcad/trunk/include/brep.h: heh, NRUBS! Non-uniform, not non-rational |
| 04:02.33 | CIA-23 | BRL-CAD: 03brlcad * r51990 10/brlcad/trunk/src/conv/g-nff.c: reorder to avoid forward decls |
| 04:03.31 | CIA-23 | BRL-CAD: 03brlcad * r51991 10/brlcad/trunk/src/conv/g-nff.1: v and i are separate options. be consistent with usage. |
| 04:04.07 | CIA-23 | BRL-CAD: 03brlcad * r51992 10/brlcad/trunk/TODO: looks like g-nff is in sync now |
| 04:06.55 | CIA-23 | BRL-CAD: 03brlcad * r51993 10/brlcad/trunk/src/librt/primitives/brep/brep.cpp: declare nurbs.h functions for us |
| 04:19.33 | CIA-23 | BRL-CAD: 03brlcad * r51994 10/brlcad/trunk/src/libbn/tri_tri.c: ws |
| 04:26.37 | CIA-23 | BRL-CAD: 03brlcad * r51995 10/brlcad/trunk/src/libbu/tests/bu_basename.c: this should but doesn't halt on failure |
| 04:50.02 | *** join/#brlcad andrei (andrei@79.119.91.74) |
| 05:05.31 | *** join/#brlcad starseeker (~starseeke@BZ.BZFLAG.BZ) |
| 05:08.43 | CIA-23 | BRL-CAD: 03phoenixyjll * r51996 10/brlcad/trunk/src/librt/primitives/brep/brep.cpp: Try the ON_Surface::Pushup() method first. |
| 05:25.07 | CIA-23 | BRL-CAD: 03phoenixyjll * r51997 10/brlcad/trunk/src/librt/primitives/dsp/dsp_brep.cpp: Some clean up: modify comments, rename a variable with typo, eliminate the debug output, and reduce using dynamic allocated pointers. |
| 05:53.26 | *** join/#brlcad brlcad (~sean@BZ.BZFLAG.BZ) |
| 05:54.14 | *** join/#brlcad starseeker (~starseeke@BZ.BZFLAG.BZ) |
| 05:56.03 | CIA-23 | BRL-CAD: 03phoenixyjll * r51998 10/brlcad/trunk/include/nurbs.h: Add comment before surface_surface_intersection() to describe the algorithm used in SSI. |
| 07:13.06 | *** join/#brlcad ksuzee (~ksu@193.151.105.83) |
| 08:56.59 | CIA-23 | BRL-CAD: 03Phoenix 07http://brlcad.org * r4324 10/wiki/User:Phoenix/GSoc2012/Reports: /* Week 13 */ |
| 09:01.17 | *** join/#brlcad stas (~stas@188.24.33.151) |
| 09:16.10 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) |
| 09:26.37 | kanzure | another bzflag player working on brlcad? |
| 09:26.41 | kanzure | that seems unlikely? |
| 10:47.46 | *** join/#brlcad stas (~stas@82.208.133.12) |
| 11:11.44 | *** join/#brlcad ``Erik_ (~erik@pool-108-3-186-191.bltmmd.fios.verizon.net) |
| 11:25.22 | *** join/#brlcad archivist (~archivist@host81-149-189-98.in-addr.btopenworld.com) |
| 12:56.49 | brlcad | kanzure: that's the RDNS that many connect from with a persistent connection |
| 12:59.20 | ksuzee | ``Erik, starseeker: hello! Has Sean answered you anything? |
| 12:59.53 | brlcad | good morning ksuzee |
| 13:00.09 | ksuzee | brlcad: hello, Sean! |
| 13:03.27 | ksuzee | brlcad: Erik and Cliff wanted to ask you about my patch yesterday |
| 13:03.56 | brlcad | the need to ask is not a good sign ;) |
| 13:04.24 | ksuzee | :) |
| 13:04.27 | brlcad | patches should be "obvious" to apply, usually some simple obvious benefit with no downsides |
| 13:04.30 | brlcad | which patch? |
| 13:05.05 | brlcad | 3536116? |
| 13:05.13 | brlcad | looks like your oldest |
| 13:05.23 | ksuzee | 3549356 |
| 13:05.26 | ksuzee | this one |
| 13:06.08 | ksuzee | 3536116 wasn't commented at all |
| 13:07.45 | *** join/#brlcad elf_ (~elf@p22.eregie.pub.ro) |
| 13:07.56 | ksuzee | Cliff's words: <starseek1r> brlcad: can 3549356 be applied to consolidate code without resolving why there are separate state5 and state6 functions in the first place? |
| 13:09.31 | brlcad | summarize the patch to me |
| 13:09.51 | brlcad | (quickly, gotta run soon) :) |
| 13:10.19 | ksuzee | Details: |
| 13:10.20 | ksuzee | The most body of functions state5() and state6() was united at function state56(). Duplications was removed. |
| 13:10.28 | ksuzee | :) |
| 13:11.52 | brlcad | so you say most of the body |
| 13:11.56 | brlcad | most is not all? |
| 13:12.01 | brlcad | what's different |
| 13:12.25 | ksuzee | sorry |
| 13:12.32 | ksuzee | I'm not right |
| 13:12.35 | ksuzee | all the body |
| 13:12.44 | ksuzee | only one parameter is added |
| 13:12.45 | brlcad | critical detail |
| 13:13.16 | brlcad | so the body to both functions were completely identical except for that return value? |
| 13:13.32 | ksuzee | yes |
| 13:13.37 | brlcad | are you sure? :) |
| 13:13.41 | ksuzee | yes))) |
| 13:14.04 | ksuzee | I checked it in Meld |
| 13:14.36 | brlcad | so IF (and only if) that is true, then the refactoring is fine except you choose a terrible function name and have a misleading summary |
| 13:14.47 | brlcad | state56 doesn't say semantically what that new function does |
| 13:14.51 | brlcad | it should |
| 13:15.07 | brlcad | moreover, could just as easily think there are 55 other states |
| 13:15.28 | ksuzee | yes, understand :) |
| 13:15.49 | andrei | Hello ! |
| 13:15.52 | ksuzee | so what name would be better? |
| 13:17.02 | andrei | brlcad, I finished test units for libpkg API but I figured out that some cases that I tested are covered by PKC_CK, should I remove those cases? |
| 13:17.10 | andrei | otherwise tests never get past that point. |
| 13:17.15 | brlcad | i don't know what a better name would be without reading the function in detail to know what the semantic purpose of each was |
| 13:17.53 | CIA-23 | BRL-CAD: 03brlcad * r51999 10/brlcad/trunk/src/librt/primitives/nmg/nmg_rt_segs.c: apply sf patch 3549356 from ksuzee (Reduction in src/librt/primitives/nmg/nmg_rt_segs.c). the body of functions state5() and state6() were united, put into a common 'state5and6' (slightly patch mod) function. |
| 13:18.29 | brlcad | andrei: leave them in, but comment them out and leave a note why |
| 13:18.50 | andrei | ok |
| 13:20.41 | *** join/#brlcad andrei (~andrei@79.119.91.74) |
| 13:21.18 | ksuzee | I see, you've alredy applyed. Thanks! |
| 13:21.21 | brlcad | ksuzee: so that was a useful patch, but had those two problems -- might want to make sure you don't have any other misleading summaries, and confusing function names |
| 13:22.04 | brlcad | getting better, but really the point is to have absolutely NO questions when applying the patch, that is just completely obvious because you've gone over every detail |
| 13:23.32 | ksuzee | brlcad: ok, I understand. In my other patches I usually add "extra_" to the names of new functions |
| 13:23.56 | ksuzee | If they are used only in situations like this |
| 13:24.01 | brlcad | so that's not a good name |
| 13:24.16 | brlcad | doesn't really say what's different |
| 13:26.31 | brlcad | just adding some vague word or a number (e.g., common3()) are not helpful, and don't scale |
| 13:26.46 | brlcad | I just reviewed 3536116 |
| 13:26.49 | brlcad | it's no good |
| 13:27.03 | brlcad | you left off the build system files that would make it compile |
| 13:27.22 | brlcad | more importantly, you introduce a major bug breaking one of the two tools you refactored |
| 13:27.36 | brlcad | d-i and f-i read doubles and floats respectively -- you made both read doubles |
| 13:31.50 | ksuzee | I've just checked. It lookes like I put there previous patch file |
| 13:32.08 | ksuzee | in the last one there're makefiles |
| 13:33.41 | kanzure | why do you all wake up at the same time? |
| 13:34.15 | brlcad | like I said, "more importantly, you introduce a major bug breaking one of the two tools you refactored" |
| 13:34.57 | brlcad | several of your other patch files have build system changes, but you should make sure |
| 13:35.13 | brlcad | I just reviewed 3533010 and it too has problems |
| 13:35.21 | brlcad | refers to files that don't exist |
| 13:36.04 | andrei | brlcad : there is something I don't really understand regarding my unit tests. have a function which has only pkg_conn as parameter. I wrote an unit test to check each field from pkg_conn. If pkc_magic isn't correct, each function call( parameter test) is discared. If I change the pkc_magic to the valid one at start I get segmentation fault on each call. |
| 13:36.59 | andrei | Does this need to be repaired ? I mean, should I take into consideration that it can be a "bad "pkg_conn with correct magic number? |
| 13:38.08 | ksuzee | brlcad: I see. But all about this situation I've discussed with Cliff...And there's a comment about it...That pacth must go together with another one |
| 13:40.32 | brlcad | ksuzee: ah, i missed the discussion, but my main comment still applies |
| 13:41.08 | brlcad | just adding some vague word or a number is not good |
| 13:41.21 | brlcad | having util.c and util1.c is not good |
| 13:41.22 | ksuzee | About float - double is really my fail, I'll correct it now |
| 13:41.38 | brlcad | that's completely ambiguous |
| 13:42.16 | brlcad | if they can't be combined, then they're probably not utility functions |
| 13:42.34 | brlcad | if they can, then they shouldn't be separate files |
| 13:43.05 | ksuzee | no, I tryed to combine them and it was impossible |
| 13:43.10 | ksuzee | *tried |
| 13:43.46 | ksuzee | ok, I will rename |
| 13:44.09 | brlcad | why was it impossible? |
| 13:47.06 | ksuzee | As I remember, because of global variables |
| 13:49.53 | ksuzee | and If I correct float-double, shall I put to the new patch file Makefile and CMakeFiles? |
| 13:50.09 | ksuzee | Or it's not necessary with another patch? |
| 13:50.51 | ksuzee | which goes together with this one |
| 13:53.46 | brlcad | ksuzee: the proper fix for f-i/d-i is not easy |
| 13:55.01 | brlcad | the fix would be to eliminate the static global buffers, passing only the element size and having it return a buffer |
| 13:55.25 | brlcad | that's not as simple as moving code around, though, and requires solid understanding of pointers and data |
| 13:55.49 | brlcad | I wouldn't suggest attempting it at this point given you have a dozen other patches pending, all with potentially similar problems |
| 13:57.14 | brlcad | I just reviewed three, and all three had a problem .. problems you could have found yourself and fixed before they were reviewed |
| 13:57.29 | brlcad | I suggest reviewing the others |
| 13:58.08 | brlcad | making sure you haven't just added a number to a function or file name to make it different, making sure it doesn't have some vauge name added to make something compile |
| 13:59.52 | brlcad | you can start with the util1.c/util1.h files giving them a better name or combining with util.c/util.h if possible |
| 14:00.07 | brlcad | if you rename, ask yourself what kind of utility functions -- that might help name the files |
| 14:00.37 | ksuzee | brlcad: ok, thank you. |
| 14:00.49 | ksuzee | And before checking I'd like to ask |
| 14:01.24 | ksuzee | I have a few patches, where functions take place in different directories |
| 14:01.51 | ksuzee | for example: 3556191 |
| 14:02.18 | ksuzee | Common functions are situated in libbn library |
| 14:03.37 | ksuzee | And I include new files like this - #include "../libbn/clip.h" |
| 14:03.42 | ksuzee | Is it possible? |
| 14:22.06 | brlcad | relative linking is usually bad |
| 14:22.21 | brlcad | that breaks library scoping |
| 14:22.45 | brlcad | duplication is preferred over breaking library scope |
| 14:23.27 | brlcad | if it's truely common, it might be a useful new libbn function or even a new libbu function, but that really depends what the function is/does |
| 14:32.49 | *** join/#brlcad CIA-55 (~CIA@204.152.223.100) |
| 14:33.20 | ksuzee | so it's better to put these functions into existing file, not in the new one? |
| 15:12.13 | CIA-55 | BRL-CAD: 03starseeker * r52000 10/brlcad/trunk/regress/nirt.sh: Don't strip spaces from the NIRT sample output unless/until nirt output also strips all spaces. |
| 15:17.06 | CIA-55 | BRL-CAD: 03carlmoore * r52001 10/brlcad/trunk/configure.cmake.sh: remove trailing blank |
| 15:19.18 | CIA-55 | BRL-CAD: 03carlmoore * r52002 10/brlcad/trunk/INSTALL: remove trailing blanks/tabs and fix a spelling |
| 15:20.56 | CIA-55 | BRL-CAD: 03starseeker * r52003 10/brlcad/trunk/regress/red.sh: red now rejects unsafe color - update regression test. |
| 15:35.00 | CIA-55 | BRL-CAD: 03carlmoore * r52004 10/brlcad/trunk/TODO: fix spelling |
| 15:35.33 | CIA-55 | BRL-CAD: 03starseeker * r52005 10/brlcad/trunk/ (4 files in 3 dirs): INSTALL and configure.cmake.sh are (partially) autogenerated - clean up the ws in the source contents, rather than the generated output. |
| 15:55.55 | CIA-55 | BRL-CAD: 03starseeker * r52006 10/brlcad/trunk/ (CMakeLists.txt src/other/step/cmake/sync_generated.cmake.in): Update documentation on handling of INSTALL.new, configure.new, and perplex/re2c/lemon cached files. |
| 16:57.38 | CIA-55 | BRL-CAD: 03starseeker * r52007 10/brlcad/trunk/CMakeLists.txt: sp |
| 17:06.37 | CIA-55 | BRL-CAD: 03carlmoore * r52008 10/brlcad/trunk/ChangeLog: fix spellings |
| 17:09.19 | CIA-55 | BRL-CAD: 03carlmoore * r52009 10/brlcad/trunk/ChangeLog: fix spelling of 'reported' |
| 17:50.47 | *** join/#brlcad andrei (~andrei@86.123.127.119) |
| 17:50.48 | andrei | hello |
| 17:51.12 | andrei | brlcad : sorry my internet connection broke down could you ( or someone else ) repeat what you said, if you answered? |
| 18:04.49 | CIA-55 | BRL-CAD: 03carlmoore * r52010 10/brlcad/trunk/include/nurbs.h: remove trailing blank and fix spellings |
| 18:08.35 | CIA-55 | BRL-CAD: 03carlmoore * r52011 10/brlcad/trunk/include/vmath.h: fix spellings |
| 18:23.35 | CIA-55 | BRL-CAD: 03anrgmrty * r52012 10/brlcad/trunk/src/libged/voxelize.c: voxelize with command line options, regions defined |
| 18:30.26 | CIA-55 | BRL-CAD: 03carlmoore * r52013 10/brlcad/trunk/include/raytrace.h: fix spellings |
| 18:33.46 | *** join/#brlcad andrei (andrei@86.123.127.119) |
| 18:45.00 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) |
| 18:48.48 | jordisayol | starseeker: how developed is the new packaging system for Linux? |
| 19:01.27 | jordisayol | is archer still in pre-alpha state? |
| 19:03.58 | *** join/#brlcad merzo (~merzo@51-114-133-95.pool.ukrtel.net) |
| 19:09.09 | CIA-55 | BRL-CAD: 03anrgmrty * r52014 10/brlcad/trunk/src/tclscripts/lib/tclIndex: position of voxelize changed so it is in alphabetical order |
| 19:13.46 | CIA-55 | BRL-CAD: 03anrgmrty * r52015 10/brlcad/trunk/src/tclscripts/lib/ (Db.tcl Mged.tcl): position of method voxelize changed so it is in alphabetical order |
| 19:18.48 | *** join/#brlcad stas (~stas@188.24.33.151) |
| 19:22.33 | CIA-55 | BRL-CAD: 03anrgmrty * r52016 10/brlcad/trunk/src/tclscripts/lib/Ged.tcl: position of method voxelize changed so it is in alphabetical order |
| 19:34.53 | *** join/#brlcad merzo (~merzo@51-114-133-95.pool.ukrtel.net) |
| 19:39.02 | cristina | brlcad: I was checking the structure of the libged/edit.c file. What should the expected subcommands of the "graph" command be, at this point? |
| 19:39.13 | cristina | "Graph" should launch a new window with the graph already outputted, right? I don't think there's a need for a "view" subcommand in this case. |
| 19:39.28 | cristina | Is the user curious in finding out the coordinates of the rectangles and edges between the nodes within the graph? If not, then the "graph_objects_positions" subcommand doesn't need to be created either. |
| 19:40.53 | andrei | ``Erik, what should I do regarding the matter I asked brlcad earlier ? |
| 19:43.59 | cristina | One more question: If I wrap a "ged_graph" C function in a command named "graph" can I have a Tcl procedure that is called "graph" as well? And when running "graph" in the interpreter to call the Tcl procedure and launch the window? |
| 20:06.09 | *** join/#brlcad ksuzee (~ksu@193.151.105.83) |
| 21:28.55 | *** join/#brlcad DarkCalf (~DarkCalf@173.231.40.99) |
| 21:29.19 | DarkCalf | waves to #brlcad |
| 21:45.20 | CIA-55 | BRL-CAD: 03r_weiss * r52017 10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri.c: |
| 21:45.22 | CIA-55 | BRL-CAD: Added new function "nmg_isect_pt_facet" to file "nmg_tri.c". This function |
| 21:45.22 | CIA-55 | BRL-CAD: handles more special cases when testing if a point is within a facet. Changed |
| 21:45.22 | CIA-55 | BRL-CAD: function "cut_unimonotone" to use this new function. This is a work in process. |
| 22:04.54 | *** join/#brlcad louipc (~louipc@archlinux/fellow/louipc) |
| 22:42.02 | *** join/#brlcad Yoshi47 (~jan@d24-204-236-81.home4.cgocable.net) |
| 23:17.40 | CIA-55 | BRL-CAD: 03Stattrav 07http://brlcad.org * r0 10/wiki/Special:Log/upload: uploaded "[[Image:Absavgperf.png]]" |
| 23:19.19 | CIA-55 | BRL-CAD: 03Stattrav 07http://brlcad.org * r0 10/wiki/Special:Log/upload: uploaded "[[Image:Perfvsimages.png]]" |
| 23:20.24 | CIA-55 | BRL-CAD: 03Stattrav 07http://brlcad.org * r0 10/wiki/Special:Log/upload: uploaded "[[Image:Absavgperfpermhz.png]]" |
| 23:22.42 | CIA-55 | BRL-CAD: 03r_weiss * r52018 10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri.c: Update to "cut_unimonotone" in file "nmg_tri.c" to fix some compile errors. |
| 23:26.45 | Yoshi47 | anyone know the status of Archer? |
| 23:26.54 | Yoshi47 | or where I can find out about that status |
| 23:27.54 | louipc | as far as I know it's actively developed and is intended as the successor to mged |
| 23:28.45 | louipc | but doesn't have full functionality yet |
| 23:34.26 | Yoshi47 | louipc, so you don't use it? |
| 23:35.00 | louipc | no I haven't used it much |
| 23:41.30 | ``Erik | still "pre-alpha", a test run a couple weeks ago cropped up a bunch of bugs and usability issues |
| 23:43.26 | CIA-55 | BRL-CAD: 03Stattrav 07http://brlcad.org * r4328 10/wiki/User:Stattrav/GSoC2012_log: Updation of the logs. Sample plots added to the page. |