Editing User:Cprecup/GSoC2012 progress


Warning: You are not logged in. Your IP address will be publicly visible if you make any edits. If you log in or create an account, your edits will be attributed to your username, along with other benefits.

The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then save the changes below to finish undoing the edit.
Latest revision Your text
Line 1: Line 1:
=Coding period=
=Coding period=
===''Week 14''===
====Firm pencils down day: 20/08/2012====
* Adjusted the ''doc/docbook/system/mann/en/graph.xml'' according to the changes made on the subcommands and added a brief documentation for the '''igraph''' command.
===''Week 13''===
* Added two subcommands for the '''graph''' command: '''show''' and '''positions'''.
* Removed the previous ''graph_objects_positions'' and ''graph_structure'' commands.
* Renamed the previously named Tcl ''graph'' procedure into '''igraph''' - this command launches the interactive graph; along with this procedure, the ''src/tclscripts/graph'' was renamed into ''src/tclscripts/'''igraph''''', and the file ''src/tclscripts/graph/graph.tcl'' was renamed into ''src/tclscripts/'''igraph/igraph.tcl'''''.
* The '''igraph''' command works in MGED; when launched in Archer, an error message in outputted saying that the command is not available yet.
* Took care of some command error cases (C and Tcl).
* Again tried to integrate the previously mentioned command in Archer - Didn't find an example that would suit me. I found commands that would have procedures that use C wrapped commands but they were either working strictly for Archer or for MGED, not for both.
* Introduced a '''graph''' command and its '''show''' subcommand.
* Tried to get rid of an ''"invalid command name "graph" while executing "graph show""'' error but didn't find a solution - this appears when I run my procedure in Archer. When running this procedure in MGED, no such error appears and the graph is generated correctly.
* Enabled error message in MGED for the '''graph''' command in case the Adaptagrams library isn't available.
* Started reorganizing the '''graph''' command in subcommands.
* Added a basic brlman documentation for the '''graph''' command.
* Grouped top-level commands under a single '''graph''' command. Came up with an approach on how to tackle the following problem:  there would exist a C implemented "graph" command and also a Tcl procedure named "graph" and when ran in MGED the C one is ran instead of the Tcl one. Waiting for a response before committing the changes.
* Fixed a bug that appeared when launching Archer due to the '''graph_objects_positions''' command.
* Started work on integrating the '''graph''' command in Archer. Encountered some problems due to the fact that there isn't a corresponding ''ged_graph'' C routine that can be used. The procedure is simply defined in Tcl.
===''Week 12''===
* Cleaned up the layout source code that was about to be committed.
* Replaced the connection lines that existed between two nodes with polylines and added arrows at the end of each connection line.
* Finished creating the routines that provide a decent layout for the graph.
* Added vertices between the nodes.
:Here is how the graph for the ''share/db/axis.g'' database looks like now:
:Commit will be made as soon as the source code is cleaned up.
* Continued working on the layout part.
* Started research and work for solving the layout issue of a graph.
* Added the '''decorate_object(struct _ged_dag_data *, char *, int)''' routine in ''src/libged/dag.cpp''. This creates a new entry into a hash table for each newly detected object and sets the entry's value depending on the type of object: ''primitive'', ''combination'', or ''something else''.
* Used these types to differently colour the rectangles in the graph editor.
* Introduced a text widget with the name of the object within each rectangle.
:Here is the window that the '''graph''' command launches for the ''share/db/axis.g'' database:
* Looked for a method to store object's colour and name related information within an Adaptagrams graph structure.
:This is needed for implementing the decorative routines for each type of object. Couldn't find a method. Worked on an alternative method to store this information.
===''Week 11''===
* Updated the '''ged_graph_objects_positions''' routine; it now passes the objects and positions within the graph to the Tcl field.
* Used this command in the ''src/tclscripts/graph/GraphEditor.tcl''. The objects are now drawn at the specified positions using a Tk Canvas widget inside a window.
* The '''ged_graph_objects_positions''' can now be used as a command within the Tcl field to retrieve objects' positions within the graph.
* Made sure that the commands '''graph_structure''', and '''graph_objects_positions''' always exist so that the user is informed that he/she invoked a valid command, although the Adaptagrams library is not available.
* Again tried to figure out the logic between the data processed in the ''C'' implementation of a command and the data received in the ''tcl'' file when running this command.
* Finally got the idea after having a talk with '''starseeker'''.
* Looked for a pattern to follow in the implementation of ''C'' commands that are to be used in the Tcl land. Found the files that need to be modified according to the existence of a new command.
* It's not clear to me how the data used in a ''tcl'' file where a command is ran is passed on to this ''tcl'' file.
===''Week 10''===
Developed a first version of a routine (''ged_graph_objects_positions'') that returns the positions for each object from the database. This is supposed to be used by a GUI component that draws the objects using Tk Canvas inside a window.
* Had trouble with a ''make distcheck'' error.
* Ran tests for the two commands that were implemented: "graph_structure" and "graph".
:The name of "graph_structure" might be adjusted. Subcommands need to be added. So far, there is a view command but what it actually does is traverse the database and define its corresponding graph. The steps for this need to be split in smaller routines that would eventually be called as subcommands.
* Managed to pop up the window in MGED by simply running the "graph" command.
* Worked on popping up a new window when running the ''graph'' command. With starseeker's help I found out that one of my script wasn't "loaded". Eventually I tackled this. However, the window still doesn't pop up when running the command; it shows up only when running ''<tcl_script_name> .window1''.
===''Week 9''===
* Created the command "'''graph'''". For now, it can be ran in MGED like this: "'''graph view'''" and it calls a routine in src/libged/dag.cpp: ''ged_graph()''.
* Worked on creating a new window when running this command.
There is no commit because the code might need some restructuring.
* Implemented the '''put_me_in_a_bucket''' routine that figures out the type of an object, adds its name to a vector and defines a corresponding shape in the graph.
*Replaced the 3 hash tables (solids, regions, and groups) with 3 vectors of names (primitives, combimations, and non_geometries).
* Discussed about modifications for the current src/libged/dag.cpp file: use a single hash table that stores the names and IDs of all the objects and lists of names for each type of an object: primitive, combination, non-geometry.
* Worked on the above modification. So far:
**created a new master hash table called "objects" with the names and IDs of all the objects;
**worked on switching from the hash tables to simple lists of names for each type of an object.
===''Week 8''===
* Summarized the progress made so far
* Updated the future milestones for this project
* Currently figuring out a plan for a user-visible feature in Archer/MGED, i.e., a command that would open a window displaying the graph corresponding to the displayed geometry.
* Allocated space for each ''value'' of an entry of a hash table outside the hash table. In the ''value'' field of an entry I've just copied the pointer to this memory space.
* Implemented a method that frees the space allocated for these values.
* Removed entries from the ''solids'' hash table whenever an object is discovered to be a ''region'' or a ''group''. Switched to working with pointers for ''bu_hash_tbl'' structures. Freed memory for each allocation.
* Made some small modifications on the ''src/libged/dag.cpp'' related to memory allocation.
* Tried to deallocate memory for a certain entry in a hash table but didn't find a proper solution to this. In the ''hash.c'' I've only found the function '''bu_hash_tbl_free(struct bu_hash_tbl *hsh_tbl)''' which is not what I need because I don't want to deallocate the memory for the whole table but, instead, just for one entry. Need to find out how it's supposed to be done.
===''Week 7''===
* Introduced id's for each object in the database and finished memorizing the data.
* Taking into account what hash table it belongs to, each object has now a corresponding shape and (if needed) links to the nodes of its 'subtree' in the graph.
* Duplication is now avoided because each shape of the router has a corresponding id.
:Here's the graphical output for the ''share/brlcad/7.22.1/db/axis.g'' (that was put in a .svg file, for now): [[Image:Graph_link_nodes_no_duplications.png]]
:Compared to the one mentioned on ''01/07/2012'', one can observe that the number of nodes has been reduced to a single one in case of duplications. The links between the nodes are overlapping for now. This needs to be taken care of.
* Continued working on the code that is meant to memorize data related to each object in a database into the three below mentioned hash tables.
* Replaced the '''bu_ptbl''' structures with '''bu_hash_tbl''' for the three kinds of tables: ''regions'', ''groups'' and ''solids''.
* Implemented code for adding '''bu_hash_entry'''s into the hash tables. Encountered some problems on this part as well as where I have to establish the size of each ''lists'' field in a hash table.
* Found a way to eliminate node duplications depending on their names - use the '''struct bu_hash_tbl'''.
* Fixed the representation of solid objects: instead of dashed line they are represented by rectangles now.
* Introduced a temporary method for positioning the nodes into the graph.
* Cleaned up the code and committed the changes.
===''Week 6''===
===''Week 6''===
* Managed to link each COMB node with the nodes of its subtree.
:Here's the graphical output (that was put in a .svg file, for now): [[Image:Graph_link_nodes.png]]
:One can observe that for some nodes there are branches that link to other nodes. As a helper, [http://pastebin.mozilla.org/1687225 here] is the listed output of what the algorithm is doing in the background.
:The order in which they were outputted is the one in which the directory was traversed. The alignment is due to a linear function that I used for the coordinates of the rectangles that represent each node. This needs to be modified as well as the duplicated nodes and the representation of solids (here, they appear as a single dash line instead of a rectangle).
* Looked for an example that would give me hints on how to find and traverse a subtree of a combination in order to create actual links between the nodes. Decided that ''src/conv/g-dot.c'' is a good starting point.
* Worked on the implementation of a method called ''dag_comb'' that is meant to create links between the COMB node and the ones from its subtree. Didn't commit anything because it's not finished and the code needs to be cleaned up eventually.
* Looked in the ''src/tclscripts/geometree'' folder with the purpose of understanding how the MVC (model, view, controller) pattern is applied there.
* Looked in the ''src/tclscripts/geometree'' folder with the purpose of understanding how the MVC (model, view, controller) pattern is applied there.

Please note that all contributions to BRL-CAD may be edited, altered, or removed by other contributors. If you do not want your writing to be edited mercilessly, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource (see BRL-CAD:Copyrights for details). Do not submit copyrighted work without permission!

To edit this page, please answer the question that appears below (more info):

Cancel Editing help (opens in new window)