This is the first year in which I was eligible for GSoC program and was selected by the highly esteemed open source community BRL-CAD. Before joining the project, I had just the glimpse of how large code bases are maintained, but had never got hands on experience with them. I used git version control, but that just limited to handling my college project.

I would like to rewind and fast-forward the 4 beautiful months of my life, the best in terms of experience and knowledge gaining and learning summer quickly below-

Initially, before the project submission deadline, I submitted few small and pretty code refactoring patches to BRL-CAD to get myself famaliar with svn version control system and other basics for working with gsoc project.

Upto the student selection date, I worked on an issue of github to get famaliar with github version control system, on which STEPcode is managed. In this period, I got to know abt diff tools, working with git version control in a better way, gdb debugger, doxygen and how to write comments and observed some good tactics related to coding followed in industry, like taking minute care from declaring variable names to introducing magic numbers and to see that in future there will be no false positives and bugs introduced that would create problem in long run.

In between the selection period and the actual program period, it was the community bonding period as well as time for release process of BRL-CAD 7.24.0. I helped in formatting the release notes for this major release and got some experience with release procedure.

After the actual beginning of the program I worked with open issues of github and got it merged on the mainstream. One was removing all cppcheck warnings from stepcode. There were mainly 6 types of warnings reported in STEPcode by cppcheck which included unused variables, preference for preincrement/decrement, sscanf() to prevent overflow, strncpy not '\0' terminated, C style pointer casting and reducing the scope. After clearing those, I ran cppcheck on brlcad trunk and uploaded the output to refactoring page of brlcad. Also, I made a patch for preference for preincrement/decrement from that output and cleared those warnings from cppcheck on BRL-CAD sources.

The next issue I worked on was installing the headers from the central files used in the minimal example. This included installing headers from 10 directories of stepcode. Now, anyone can just do sudo make install and start using the API's like any other library.

After that, I worked on checking the step-g importer on brlcad and wrote regression tests checking the step-g importer with 3 small and simple step models. I also read and knew about how to use anything from net with a copyright and use the license. I had never dealt with those kind of scenes before.This test will confirm the working of step-g importer and check for the geometry by checking volume > 0. I also looked upon the todo task on brlcad wiki and deleted those which were already done and added a prototype and Todo comments in the trunk to make it easily visible and more organized. These patches are still awaiting review by mentors.

I forgot to mention about my experience with STEPbot, my experiment with a bot for channel #stepcode on IRC. And one fine evening, when I logged on to IRC, I was surprised to see an infobot similar to that on #brlcad already implemented and hence the logs of that channel could be archived very easily.

A huge thanks to Mark, my mentor who has been the best mentor I could ever have. He had been by my side at every 'step' of my project guiding me and providing quick response and feedback of my work and effective guidelines throughout the project. Thank you Sean. You are the best project manager I ever saw. Along-with the help in technical aspects, I loved how you used to motivate and inspire me. Also, I liked your way of getting answers from me instead of giving solution directly,no matter if it took an hour for a simple thing. :) Thanks Cliff, Erik and all other GSoC students who had been as a support anytime in the last 4 months. I could not imagine my project being complete without you guys. Awesome, cool community, i must say. :) Thanks all once again.

Future plans - In past a week or so, I observed that a lot of people were posting queries related to STEPcode. They were asking for good tutorials or easy-to-understand links. So, I think, I would first make tutorial for beginners on STEPcode. And next, after that I am willing to get my hands on step exporter. My plans till next summer is to work and get familiar with the step-exporter and dedicate my next summer to it.

You just walked with me on my journey of past 4 months. I know, this has been too long and thanks for your precious time reading this. Hope you enjoyed the walk. Below are my daily logs and reports.

I fully confirm and accept the stated participation requirements including giving full rights to my contributions, remaining visibly active, being engaged in discussion, providing regular updates on progress, complying with the development rules, and writing excellent code.

Worked upon Issue 21: Removed 100 warnings, errors and styles shown by cppcheck from about total 455.

I ran "rm -r *" from stepcode/ instead of build/, and cloned the repo again in stepcode/ through which I lost all my progress. Thanks to git cherry-pick command, through which i recovered it back ! #sighofrelief

Done with issue 21. All genuine warnings have been successfully removed.

The ones which remain are due to bugs in cppcheck. Cppcheck says some variables unused though it has been used, says many functions have not been used, shows some warnings in generated files(generated files can't be changed obviously)

To ensure all test are running fine as before and nothing has been broken, compiled with testing enable and ran 'make test'. All test are working correctly as before. :)

Will push the change to github repo for Mark to review it once, and then it will be merged with master branch. Issue 21 can be closed now.

Next thing to work on is - STEPcode 0.7 doesn't install all required headers. All .h files need to be in /usr/lib or whatever the install prefix is.So you don't need to reinstall in order to add schemas.Then you could just sudo make install and start using the API:s like any other library.

Unused Variable-Don't just comment out unused variables. If there is no possibility of side effects (i.e. they aren't initialized via a function call), remove them. In case of doubts, delete them and then make a note on github by clicking the message bubble by the line.Oops, no point in modifying clSchemas/* either. I should probably just delete that, since it's old generated code.Other than this and the commented out variables, it looks good.

Reducing Scope-Looks good, except there are some lines that were commented out instead of being deleted.

Closing file-Closing the files doesn't hurt, but at that point the program is definitely about to exit. I'm not sure if I would put the effort in to fix the warning.

Increment/Decrement-I assume you changed these because of a message like "(performance) Prefer prefix ++/-- operators for non-primitive types."That means change 'x++' (++ is the suffix) to '++x' (++ is the prefix). I had to look this one up; the latter is more efficient due to the language spec, which affects how compilers usually implement prefix operator++.\

Strncpy NULL terminated- Looks good.

C-style pointer casting- %50c is almost certainly incorrect, and %50s may be too limiting.Adding arbitrary magic numbers like this is really bad in the long term. They're just bugs waiting to present themselves later in very hard-to-discover ways. The usual fix for insecure coding detection from static analyzers is to do manual parsing. We have a replacement in BRL-CAD (src/libbu/sscanf.c) that could be translated to stepCode string data structures, and which prevent the buffer overrun issue of sscanf().

Writing to the same buffer you are reading from qualifies as "undefined behavior", which means that the compiler/libc writers get to do whatever they please. It may or not behave as expected on various platforms and with different compiler/libc versions.

No need to worry about memory here.

Expand the size of character array assome platform might use a much larger number instead of 8k - such as 16k or 128k.

It checks for issues in 1690 files under all src/ except src/other and all include/ .

The manual claims that it supports multithread ( by option -j like -j 4 ), but when I tried, it said, "cppcheck: unusedFunction check can't be used with '-j' option, so it's disabled." So, if not checking for unusedFunction, it can also have mutithreaded checking.

While adding comments to the remanants of cppcheck on my branch, I realized there were few checks which could be merged in previous commits. I did so, but later while building it, I ran into make error.

Asked Mark about it, but Sean motivated me that I should do it myself and that would be a great learning experience and that might be difficult at first instance, but not impossible. :)

Rebased the commits related to reducing scope and figured out that it was dues to src/fedex_plus/classes.c

While trying to compile, it showed error and I figured out that applying astyle , the CMakelsit.txt had been changed, which was in pushed on github. Worked upon restoring the styling in CMakeLists.txt

Included headers for src/base in include directory of install. Checked it.

Now, when I run sudo make install after building the source, an sc-install folder is created in the same place as that of the stepcode repo and sc-install/include/base contains all headers for src/base.

The installation behaved wierdly, on one instance it installed in /home/kesha/../sc-install/include/* and running the same thing again after deleting build directory and making again installed headers in /usr/bin/include/* !

For headers in fedex_plus and fedex_python, "Headers need to be installed for libraries, so that executables that make use of the library can be compiled. It isn't possible to link one executable with another, so headers for executables do not need to be installed."

In ks/headers issue, the headers of exppp and express which were installed already was not in the correct directory, they need to be in include/stepcode/*. Change that.

There are two generated headers that should be installed; when you run CMake, they are created in build/include. Install them to include/stepcode

"pick a few of the importers, say dxf-g, 3dm-g, and stl-g.find some geometry, import them, view them. its' not just to look at it -- it's to understand what you imported, how you specified that import, what hierarchy resulted after import. grabcad.com has a ton of stuff. google can give you lots of stuff (just search for "filetype:obj truck" or "filetype:dxf boat" for example)"

"once you're comfortable and AFTER you've used three other converters, give the step-g importer a try on something 1) using 7.22.0 then 2) using trunk"

Tried with an importer dxf-g and here are the issues I came across. (asked them on IRC to Sean and Cliff, but waiting for their response)

EG-FILE Layers.jpg:

My screenshot after conversion:

In this, if you view both figures, two shapes are missing. Does it mean that the conversion is lossy and can it be corrected so that the missing two shapes also get imported correctly ?

Also, for this, the .jpg file was available, as to how it looks, but for those whose I don't get, how do I confirm that I am viewing it correctly and the hierarchy that resulted after the import is correct ?

Cleared a point of misunderstanding- all 3D models should not necessarily work. We just have to find a few that work. Previously I was thinking that each importer should work and was trying with many but Sean said, 2-3 of few types would be enough.

"To reiterate the purpose, we want to know if we made step-g worse at some point in the past. You'll have to correctly compile and run different versions of the step-g importer, test some geometry with those versions, so you can say with certainty whether a problem was introduced, whether it's better, or anything else actionable"

Got an idea how importing should be done and look like with various formats.

http://brlcad.org/wiki/Deuces#Code Remove those related to moving header comments. Had tested all of those and confirmed that they were done. Keeping in task list could probably waste some other dev's time in future.