| 02:42.59 | elf_ | brlcad, here's the joint.c file from the libged library |
| 02:43.08 | elf_ | header http://paste.ubuntu.com/1186753/ |
| 02:43.21 | elf_ | joint.c file http://paste.ubuntu.com/1186752/ |
| 02:43.54 | elf_ | columns.c file, I had to add it to the libged library too, in order to be able to print information http://paste.ubuntu.com/1186754/ |
| 02:44.30 | elf_ | I think maybe columns.c can be added to a more general level, so that we won't have it also in the mged and libged libraries... |
| 02:45.23 | elf_ | In the joint.h header file I declared an extern global interpreter (I know that's not alright though, it is?) |
| 02:47.22 | elf_ | I still have to see how I can fix the refresh() function... though I am not sure how that it's called in libged or if it's called at all |
| 02:50.31 | elf_ | the move si mesh options are not done yet in the libged library |
| 02:51.18 | elf_ | for the mesh option I have to add the cvt_vlblock_to_solids() function to the libged library, I am thinking to add it in the joint.c file as a static function |
| 02:52.23 | elf_ | originally cvt_vlblock_to_solids() it's declared in the mged/mged.h file and it's definition is in dodraw.c file, so I don't know for sure if the static procedure is doable |
| 02:53.44 | elf_ | and for the move option I need the base2local define in the libged library, and this one I really don't know how to approach it, in mged base2local is all over the place |
| 02:58.44 | CIA-68 | BRL-CAD: 03Elf11 07http://brlcad.org * r4383 10/wiki/User:Elf11: /* Log */ |
| 03:39.48 | brlcad | elf_: referencing an extern Tcl_Interp is no good |
| 03:40.01 | brlcad | that's one of the things that HAS to change moving from mged to libged |
| 03:41.07 | brlcad | you were going so well... :) |
| 03:42.29 | brlcad | elf_: so there's a problem with your method .. you now have a deep laundry list of issues -- many unanswered questions and problems |
| 03:42.39 | brlcad | you cannot refactor code effectively this way |
| 03:43.18 | brlcad | remember back to when I had you just add an empty ged_joint() function .. you understood everything there and it was "complete" |
| 03:43.30 | brlcad | didn't do much, but there were no issues, no unanswered questions |
| 03:44.53 | brlcad | when you refactor, you should still always leave the code in a "complete" state (or at least with no more than one issue, documented) |
| 03:46.51 | brlcad | with open issues, if something doesn't work or crashes, there will be too many problems to figure out what's wrong |
| 03:47.02 | elf_ | okay so the extern Tcl_Interp should disapper |
| 03:47.13 | brlcad | elf_: so I suggest backing up or at least identifying what your current problems are and taking care of them before moving any more code over |
| 03:47.35 | elf_ | though I don't understand why |
| 03:47.52 | brlcad | also, compilation is NOT sufficient... you should run the code every time you add a line of code, exercise the code, and make sure it doesn't crash (at least if it does, it should be explainable) |
| 03:48.10 | elf_ | so far it works, I mean with the extern Tcl_Interp, there are no errors and the testing I did it looks alright |
| 03:48.33 | elf_ | so that's why I don't really understand why no Tcl_Interp references |
| 03:49.03 | brlcad | the interp "works" because mged is providing it |
| 03:49.20 | brlcad | if you wrote a small program that just called ged_joint(), it wouldn't work |
| 03:49.58 | brlcad | it's not no Tcl_Interp references, it's that you should not be using a global |
| 03:50.55 | brlcad | technically, you should be able to convert the function to not use Tcl at all |
| 03:51.16 | elf_ | hmm okay, so I should actually get rid of the Tcl calls, there might be another way to do it |
| 03:51.48 | brlcad | that is the usual way |
| 03:52.00 | brlcad | the better way at least, so there's no dependency |
| 03:52.42 | brlcad | pay attention to how some of the other commands print a message, return a result, and print debug/logging statements |
| 03:52.55 | brlcad | they don't call Tcl_AppendResult()... |
| 03:53.35 | brlcad | also, ignore src/libged/wdb*.c and src/libged/*_obj.c if I've not said it already :) |
| 03:55.03 | brlcad | also noticed that you're missing common.h ... it must always appear before any system headers |
| 03:55.36 | brlcad | any other questions or will that keep you busy for a couple days? :) |
| 03:56.31 | brlcad | as for base2local, look at the other ged commands to see how they handle it |
| 03:56.41 | elf_ | basically Tcl_AppendResult prints a message yes? I knew I found the definition somewhere but can't seem to find it out right now grr |
| 03:58.24 | brlcad | your intuition is correct |
| 03:59.21 | brlcad | you don't really need to understand exactly what Tcl_AppendResult does to realize that the call on joint.c:123 is printing some sort of error message and returning on joint.c:125 |
| 03:59.48 | brlcad | so look at any of the several hundred other commands to see if you can find any of them that print some sort of error message and return |
| 04:00.53 | brlcad | if you do, I think you'll quickly realize that the block of code you have at joint.c:100 is wrong too |
| 04:02.08 | elf_ | there's no default mged function table since we are in the libged library, right? |
| 04:03.17 | brlcad | well, that may be true but isn't what's wrong |
| 04:03.49 | brlcad | lines 101:103 do nothing useful |
| 04:04.02 | brlcad | do you see what's wrong? |
| 04:04.25 | elf_ | yeah the printing of error, I just realized it's not like that |
| 04:04.55 | brlcad | what are those three lines actually doing? |
| 04:06.16 | brlcad | or at least, what does it LOOK like they're probably doing -- don't need to know exactly what to realize what is probably the issue? |
| 04:06.23 | brlcad | s/issue?/issue./ |
| 04:07.16 | elf_ | I think they are formating a string in the vls format but then the structure is cleaned so nothing really happens |
| 04:07.48 | brlcad | good |
| 04:08.20 | brlcad | init string, print to string, free string .. we never did anything with the string |
| 04:08.29 | elf_ | so yeah they are kinda useless there, it should print an error message if the function table is not found |
| 04:08.38 | brlcad | what's the quick fix? |
| 04:09.31 | brlcad | when that was translated to libged, it should have turned into one line |
| 04:10.21 | elf_ | bu_vls_printf(gedp->ged_result_str, "error to print") ? |
| 04:10.27 | brlcad | excellent |
| 04:10.44 | brlcad | that local vls just goes away, you print to the ged_result_str vls instead |
| 04:11.03 | brlcad | that's the same for nearly all of the Tcl_AppendResult() calls too |
| 04:11.21 | brlcad | they either go to ged_result_str() or are simply bu_log()'d depending on the type of message |
| 04:11.37 | elf_ | okay so the struct ged *gedp it comes as a parameter in the function join_cmd(struct ged *gedp,...) or it's local? |
| 04:13.09 | brlcad | well good question |
| 04:13.15 | brlcad | do you already have a gedp you could pass? |
| 04:14.29 | elf_ | there's one in the ged_joint(struct ged *gedp, ...), here we call the joint_cmd() so I can pass that one |
| 04:14.36 | brlcad | there's your answer |
| 04:15.25 | elf_ | yeah, another thing, can I have the columns.c file in the libged too? there is need for it to print info about columns |
| 04:16.33 | brlcad | also note that since joint_cmd() is static and you only call it on line 217, that in_functions parameter can never be null because it's always &joint_tab[0] |
| 04:16.54 | brlcad | that means line 100 will never be true, so that problematic block shouldn't even exist any longer |
| 04:18.03 | elf_ | Got it |
| 04:19.41 | brlcad | you can copy columns.c over, but add a TODO comment that it needs to be refactored with mged's version |
| 04:19.54 | elf_ | okay |
| 04:20.02 | brlcad | really should be libbu functions, but that's a separate task |
| 04:20.30 | elf_ | oh, I see, I will add the comment |
| 08:51.49 | *** join/#brlcad stas (~stas@188.24.34.88) | |
| 09:23.03 | *** join/#brlcad archivist (~archivist@host81-149-189-98.in-addr.btopenworld.com) | |
| 10:39.28 | *** join/#brlcad stas (~stas@82.208.133.12) | |
| 11:14.18 | *** join/#brlcad Al_Da_Best (~Al_Da_Bes@5e0e1434.bb.sky.com) | |
| 13:05.01 | *** mode/#brlcad [+o brlcad] by ChanServ | |
| 14:18.33 | CIA-68 | BRL-CAD: 03starseeker * r52354 10/brlcad/trunk/src/librt/test_botpatches.cpp: |
| 14:18.34 | CIA-68 | BRL-CAD: Move vectors into structure, make threshold for patch merging a parameter. |
| 14:18.34 | CIA-68 | BRL-CAD: There are indications that large patches may need to be broken up for the sake |
| 14:18.34 | CIA-68 | BRL-CAD: of feature preservation, possibly based on mesh density... need to read up on |
| 14:18.34 | CIA-68 | BRL-CAD: the problem. |
| 14:55.56 | ``Erik | starseeker: http://research.microsoft.com/en-us/um/people/hoppe/ |
| 15:10.14 | ``Erik | http://www.geometry.caltech.edu/pubs.html seems to have some nifty stuff, 'intrinsic parameterizations of surface meshes', etc |
| 15:15.45 | starseeker | makes a note to study this code later... http://www.cs.jhu.edu/~misha/Code/PoissonRecon/Version4/ |
| 16:16.18 | CIA-68 | BRL-CAD: 03r_weiss * r52355 10/brlcad/trunk/src/libged/gqa.c: Updated function "summary_reports" in file "gqa.c" for mged command "gqa". Changed the report so that, regions with zero hits which are in the overlap list, are not reported as having zero hits. |
| 18:46.57 | *** join/#brlcad stas (~stas@188.24.34.88) | |
| 19:44.07 | brlcad | hmm, looks like autotools build is borked |
| 20:06.45 | CIA-68 | BRL-CAD: 03starseeker * r52356 10/brlcad/trunk/src/librt/test_botpatches.cpp: |
| 20:06.45 | CIA-68 | BRL-CAD: As patches are built and cross a threshold of holding 1/100th of the total bot |
| 20:06.45 | CIA-68 | BRL-CAD: count in the mesh, add additional flatness constraints. Should probably be a |
| 20:06.45 | CIA-68 | BRL-CAD: post processing step to break up larger patches to ensure consistent behavior. |
| 23:03.38 | CIA-68 | BRL-CAD: 03brlcad * r52357 10/brlcad/trunk/src/libnurbs/opennurbs_ext.cpp: if newton iteration fails, then new_uv could be accessed prior to initialization. explicitly initialize it to zero, but also handle failed iteration by simply nudging down the uv diagnoal. |
| 23:23.42 | CIA-68 | BRL-CAD: 03Jon??zm??vbrkjrqBoughner 07http://brlcad.org * r4384 10/wiki/Wideo_go: New page: Erotica (from the Greek ????, eros "desire") [http://www.pornolarvideo.com/kategori/Anal-Porno-Video anal porno] are works of art, including literature, photography, [http://www.pornolarvi... |