| Latest revision |
Your text |
| Line 193: |
Line 193: |
| | *Once I have determined that, how do I know what new size it needs to be? | | *Once I have determined that, how do I know what new size it needs to be? |
| | *Why does the group_head array in fast4-g's commit 56495 hold 11 elements in particular and not some other number of them? | | *Why does the group_head array in fast4-g's commit 56495 hold 11 elements in particular and not some other number of them? |
| − |
| |
| − |
| |
| − | '''Thursday, June 19'''
| |
| − |
| |
| − | Today I continued working on my fast4g task. This included further attempts to answer the questions I listed in yesterday's log entry.
| |
| − |
| |
| − | Understanding the way pointers work is an important part of this endeavor. I thought my familiarity with them was adequate, but I later realized that I was mistaken. For example, I did not understand the concept of pointer dereferencing as well as I should. Before continuing to code, I read some information about pointers that was appropriate for my skill level in order to improve my understanding of them.
| |
| − |
| |
| − | Also, I began going back through fast4-g.c to look for clues to the answers to my questions, but then I thought of a better idea. Since I knew that the wmember variable called group_head was an important part of the solution, I decided that I needed to focus on learning more about that element in particular. In order to accomplish this, I examined the functions and macros that are associated with it. It was a process that I found worthwhile.
| |
| − |
| |
| − | Incidentally, an additional question I now have is about the meaning of the Ws in the variable name wmember and the header name wdb.h. I looked for the answer but could not find it.
| |
| − |
| |
| − | Near the end of the night, I read a BRL-CAD tutorial pdf called "Converting Geometry Between BRL-CAD and Other Formats." It included a section about FASTGEN-to-BRL-CAD conversion that helped me to better understand the fast4-g task.
| |
| − |
| |
| − |
| |
| − | '''Friday, June 20'''
| |
| − |
| |
| − | I worked again on the fast4-g task. One interesting thing is that last night's research improved my understanding of the differences between CSG and BREP. While FASTGEN4 is a BREP format, BRL-CAD is oriented more toward CSG. Fast4-g.c's purpose is to convert FASTGEN4 to BRL-CAD.
| |
| − |
| |
| − | Andrei_, a fellow GSoC student who has helped me before, offered me an answer to one of the questions I had posted. Also, he gave me feedback on the code I had written. It was kind of him.
| |
| − |
| |
| − | Incidentally, I posted a new draft of my corrections. It is here: http://paste.lisp.org/+32AW
| |
| − |
| |
| − | I read some great information about structs and pointers. It will help me to understand the parts of fast4-g.c that I am having trouble with and to write high-quality code for my patch.
| |
| − |
| |
| − | I have a new question: when I allocate memory for the group_head wmember list in fast4-g.c, should I use bu_*alloc() or bu_get()? I researched this, but I could not find a clear answer.
| |
| − |
| |
| − | I do know that bu_*alloc() is right for items that are large or infrequently needed. In contrast, bu_get() is suitable for small pointers and is faster. Sean said that he would like fast4-g.c to be faster, but maybe group_head is too large for bu_get() to handle.
| |
| − |
| |
| − |
| |
| − | '''Saturday, June 21'''
| |
| − |
| |
| − | Today was another day devoted to fast4-g. I went back through the program and traced the flow of all of the modules that involve the variable group_head. My understanding of the code has never been better; now I need to figure out exactly what form these stack-allocated instances of group_head will take upon becoming dynamically allocated.
| |
| − |
| |
| − | A question that I asked earlier this month in the #brlcad IRC channel is this: with what number do I replace 11, the subscript of the stack-allocated version of group_head, once I make group_head dynamically allocated? I think that I now have the answer.
| |
| − |
| |
| − | Also, interestingly enough, I am realizing that understanding fast4-g.c involves learning about the way linked lists function. There is a macro called BU_LIST_INSERT in the program that works with group_head. The comments accompanying the macro definition say, "To put [a] new item at the tail of [a] list, insert [the new item] before the head."
| |
| − |
| |
| − | This does not make sense to me. I thought that placing something at the end of a list meant placing it after the list's head. I attempted to find information that would clarify this, but I could not. I asked a question about it in the channel to see whether anyone would be willing to explain it.
| |
| − |
| |
| − |
| |
| − | '''Sunday, June 22'''
| |
| − |
| |
| − | I made further progress toward my objective of converting elements of BRL-CAD's fast4-g.c from stack allocated to dynamically allocated. I finished and posted another draft of my code, asking for feedback as always. This is a link to it: http://paste.lisp.org/+32BJ
| |
| − |
| |
| − | The fact that I am more familiar with the program's features and its flow than in the past has been beneficial. I might now be close to creating a usable patch. By the way, the comments in BRL-CAD header files such as list.h and wdb.h have helped me determine what to include in my fast4-g.c corrections.
| |
| − |
| |
| − | I would also like to mention something I found puzzling. The code in lines 2943 and 2944 of fast4-g.c commit 56495 will always run because it is in the main function, yet similar code in commit 56641 is restricted by an if statement. I studied the program in order to understand why, but I was unable to answer this question.
| |
| − |
| |
| − | In the evening, I did some additional reading about pointers. Moreover, I looked at some other information to refresh my memory on how to make patches, and then I created a fast4-g.c patch.
| |
| − |
| |
| − | The patch that I produced might not be acceptable because I based it on commit 56495 and will probably need to use commit 60592 instead. At least I know that I am able to make a patch. My best guess is that in my final version of fast4-g.c, I will need to comment out the other developer's corrections that Sean disliked; however, I must confirm this.
| |
