======Part 1====== =====Entries===== ====Entry 1: February 3, 2012==== Today we made progress with the online assignments that are due for my UNIX/Linux Fundamentals class. As part of one of the assignments we had to draw an ASCII file tree that showed our home directory within the UNIX directory structure. we also had to show 3 folders and 3 files that are contained within our home directory. Below is the finished image I created. {{ :opus:spring2012:brobbin4:tree.gif?direct& |}} ====Entry 2: February 5, 2012==== Well the first two weeks of classes are down and already I have learned so much about the C programming language. We have already written and compiled a few simple programs and it definitely been a fun learning experience. So far in class we have been focusing on the base structure of C programming, working with "printf" and "scanf" functions along with memory allocation (malloc) and learning how to use pointers in programming. All of these are siginificant because it is the basis of the programming. Without this knowledge a person cannot properely write code and expect it to compile and work with no issues. This information is also significant because it will also be used heavly utilized durring the progression of the course. This will definitely be the most challenging course that I have taken to date due to the fact that I have never taken a programming course, so this is definitely going to be an interesting semester. * The most significant thing learned to date would be pointers. * Pointers are very siginificant because they allow us to accomplish many tasks within a program while reducing the overall ammount of code that is required to make the program function properly. * Through the use of pointers you can have several processes access and control the information that is stored in one particular memory address instead of having to allocate more memory to perform a task. ====Entry 3: February 9, 2012==== Just completed the puzzlebox challenge for my UNIX/Linux class. The first parts I thought were pretty easy. I had to figure out the file type using the "file" command in Linux and then change the filenames so I could uncompress the files using various tools such as gzip and zip. The last part was pure evil for me and took me the better part of 2 days to figure out. The message was backwards and had a bunch of erroneous characters within it that had to be removed. I used a combination of the "sed" and "rev" commands to finally decrypt the message. * Today I learned how to identify files in UNIX/Linux with the "file" command. * This is significant because a user cannot rely on file extensions alone to determine what kind of file they are dealing with. * So far all of the concepts that I am learning in class are making sense due to my previous experiences with the UNIX/Linux operating system * So far the only challenge I have been faced with was the puzzlebox challenge that I just completed, mostly because I have never had any experience with the "sed" and "rev" commands. ====Entry 4: February 16, 2012==== Today was a challenging day in my C/C++ class. We were asked to write a program that encompassed all of the things that we have learned to date. The program had to accept command line arguments, prompt a user for a number between 0 and 4, and have data stored in a 2d array that could be called on by the selected numerical option. This was challenging simply because I have never wrote any code before. After writing the program and getting a helper or two from my instructor and classmates I finally understood how 2d arrays worked in C and I also learned the proper syntax for a while loop when using the loop to verify more then one rule. ====Entry 5: February 23, 2012==== Wow, what a week! Coming back from a mini break a the second project of the semester is coming due in my C/C++ class. I have already learned that I shouldn't wait until its almost due before I do the work as I sit here pounding my head against my desk. The program I have to create needs to cipher a message using a key that is provided either as a command line argument or is provided in an external text file. The message to be ciphered needs to be read from a test file and the new, ciphered message, needs to be wrote to a new text file. The hardest part of this entire program is figuring out the process that needs to occur and what statements need to be used to properly cipher the message. As this is not already hard enough a second program needs to be created that can decipher the ciphered message using the same key file or by providing the same key as a command line argument like the cipher program. Good thing its not due until tomorrow evening, I still have some time to get help on this from the IRC, lol. ====Entry 6: February 25, 2012==== Thank god! My instructor had mercy on our souls during this current project and has graciously extended our due date by another day. On top of that he has provided us with a hint as to what needs to be included in our code to make the programs work. Well after looking at the hint and implementing it into my program I still had issues. The message would cipher, but not correctly. The program was not ciphering by the key contained within the key file. The IRC was my biggest savior this time. After bouncing ideas back and forth with a fellow classmate I was finally able to get my programs to work properly. The hint was to make the program convert all characters within the message to there ASCII values, then cipher them with the key by adding the key to the ASCII value and then writing that value to a new file in its character form. The decipher program basically did the same thing but only the math in the program was reversed. Where you added in the cipher program, you subtracted in the decipher program. The issue with the key file turned out to be a simple statement make the program accept the numerical key from the file when performing the ciphering and deciphering equations. Finally my programs and the project are done and I can sleep a little easier tonight. ====Entry 7: February 28, 2012==== Today in class we dove into functions and wrote a small program that utilized a few different functions. The program would take a two command line arguments, the first would tell how many iterations of the program would run, then the second would determine the threshold of the resulting answers. Then the program would perform modular division using the second argument and a seed from srand. As long as the quotient is below the threshold the program would determine wether the answer was even or odd and then output the results on stdout. This was a new and interesting because I learned how functions actually work and how they are utilized witin a program, how to pump information into a function and get something meaningful in return. Before I started this class I thought I didn't neew any programming expreience because I didn't want to become a programmer, but now I am happy I have the change to learn about this because it's not only interesting, but it's something I can use later. ====Entry 8: March 2, 2012==== Working on finishing up the first part of this opus as it is due tonight at midnight. Thus far I have really learned alot between both classes, but more so in the C / C++ programming class. Its definatelly interesting and something I can use. I have also realized why Matt wants all students to create an opus. It allows us to not only keep a record of what we have learned but also allows us to show off our new found knowledge through the experiments that we do. To me this also seems like a great piece of work that could be added to a resume to allow a potential employer see what has been learned while earning your degree. =====Keywords===== {{page>cprogpart1&nofooter}} {{page>unixpart1&nofooter}} =====Experiments===== ====Experiment 1==== ===Question=== A question was asked in class today. That question was, what would happen if the "break" argument inside a function was replaced with the "exit" command? Would this cause just the function embedded within a program to end or would this cause the entire program to unexpectedly exit? ===Resources=== C Programming Language Second Edition C Pocket Reference ===Hypothesis=== Based on what I have learned about the C programming language thus far, I believe that the use of the exit command within a function will only cause the function to exit and not the entire program due to the fact that the exit argument would only be in scope with the current function and not the rest of the program. ===Experiment=== To test my hypothesis I am going to modify a program that was created in class on March 1, 2012. I will first however execute the program as it was created and record the resulting output so I will have something to test against and compare data with. The program that I will be modifying is the same program that brought about this interesting question. I will modify one of the functions within the program to reflect the arguments in question, then compile the program, execute it and record the resulting output. By comparing the output from the two I will then be able to draw a conclusion about the arguments in question. ===Data=== This is the original code that I will utilize in this experiment. #include #include #include int iseven(int value) { int tmp; tmp=value % 2; return(tmp); } void add(int *list, int total, int value) { int i, s=0; for(i=0; i < total; i++) { if(*(list+i)==-1) { *(list+i)=value; s=i; break; } } } int *init(int total, int *status) { int i, *tmp; *status=0; if(total > 0) { tmp=(int*)malloc(sizeof(int)*total); for(i=0; i < total; i++) { *(tmp+i)=-1; } *status=1; } return(tmp); } int main(int argc, char **argv) { int *list, i, x=0; list=init(atoi(*(argv+1)),&x); if(x==0) { fprintf(stderr, "Error on initialization!"); exit(1); } for(i=0; i < atoi(*(argv+1)); i++) { add(list, atoi(*(argv+1)), (rand()%atoi(*(argv+2)))); } for(i=0; i < atoi(*(argv+1)); i++) { if(iseven(*(list+i))==0) { fprintf(stdout, "%d is even\n", *(list+i)); } else fprintf(stdout, "%d is odd\n", *(list+i)); } return(0); } This is the output received from the unmodified code. lab46:~/src/cprog$ ./iseven 5 30 13 is odd 16 is even 27 is odd 25 is odd 23 is odd lab46:~/src/cprog$ The following is the code that has been modified to reflect the question above. Note the change in the "add" function, the "break" statement has been changed to an "exit" statement with a return code of zero. Also note the inclusion if the new printf statements within each function. These are included so I am able to tell how far the program progresses. #include #include #include int iseven(int value) { printf("Diag 1\n"); int tmp; tmp=value % 2; return(tmp); } void add(int *list, int total, int value) { printf("Diag 2\n"); int i, s=0; for(i=0; i < total; i++) { if(*(list+i)==-1) { *(list+i)=value; s=i; exit(0); } } } int *init(int total, int *status) { printf("Diag 3\n"); int i, *tmp; *status=0; if(total > 0) { tmp=(int*)malloc(sizeof(int)*total); for(i=0; i < total; i++) { *(tmp+i)=-1; } *status=1; } return(tmp); } int main(int argc, char **argv) { printf("Diag 4A\n"); int *list, i, x=0; printf("Diag 4B\n"); list=init(atoi(*(argv+1)),&x); printf("Diag 4C\n"); if(x==0) { fprintf(stderr, "Error on initialization!"); exit(1); } printf("Diag 4D\n"); for(i=0; i < atoi(*(argv+1)); i++) { printf("Diag 4Da\n"); add(list, atoi(*(argv+1)), (rand()%atoi(*(argv+2)))); printf("Diag 4Db\n"); } for(i=0; i < atoi(*(argv+1)); i++) { if(iseven(*(list+i))==0) { fprintf(stdout, "%d is even\n", *(list+i)); } else fprintf(stdout, "%d is odd\n", *(list+i)); } return(0); } The following is the resulting output after the modifications were made to the original code, and the code was compiled and executed. lab46:~/src/cprog$ ./iseven 5 30 Diag 4A Diag 4B Diag 3 Diag 4C Diag 4D Diag 4Da Diag 2 lab46:~/src/cprog$ ===Analysis=== Based on the data collected: It turns out after reviewing the collected data that my original hypothesis appears to be incorrect. The modified program runs to the point of calling the "add" function. When the program calls the "add" function, the function is executed and the "exit" function is read which then terminates the entire program instead of terminating the parent function and returning back to the "main" function to allow the program to complete. ===Conclusions=== I have concluded that it does matter where the "exit" function is located within a program due to the fact that it will terminate whatever is happening at that point in time. Within the scope of this experiment and the above program it is best to use the "break" function to allow the program to continue its function and complete the program routine. ====Experiment 2==== ===Question=== What is the question you'd like to pose for experimentation? State it here. ===Resources=== Collect information and resources (such as URLs of web resources), and comment on knowledge obtained that you think will provide useful background information to aid in performing the experiment. ===Hypothesis=== Based on what you've read with respect to your original posed question, what do you think will be the result of your experiment (ie an educated guess based on the facts known). This is done before actually performing the experiment. State your rationale. ===Experiment=== How are you going to test your hypothesis? What is the structure of your experiment? ===Data=== Perform your experiment, and collect/document the results here. ===Analysis=== Based on the data collected: * Was your hypothesis correct? * Was your hypothesis not applicable? * Is there more going on than you originally thought? (shortcomings in hypothesis) * What shortcomings might there be in your experiment? * What shortcomings might there be in your data? ===Conclusions=== What can you ascertain based on the experiment performed and data collected? Document your findings here; make a statement as to any discoveries you've made. ====Experiment 3==== ===Question=== What is the question you'd like to pose for experimentation? State it here. ===Resources=== Collect information and resources (such as URLs of web resources), and comment on knowledge obtained that you think will provide useful background information to aid in performing the experiment. ===Hypothesis=== Based on what you've read with respect to your original posed question, what do you think will be the result of your experiment (ie an educated guess based on the facts known). This is done before actually performing the experiment. State your rationale. ===Experiment=== How are you going to test your hypothesis? What is the structure of your experiment? ===Data=== Perform your experiment, and collect/document the results here. ===Analysis=== Based on the data collected: * Was your hypothesis correct? * Was your hypothesis not applicable? * Is there more going on than you originally thought? (shortcomings in hypothesis) * What shortcomings might there be in your experiment? * What shortcomings might there be in your data? ===Conclusions=== What can you ascertain based on the experiment performed and data collected? Document your findings here; make a statement as to any discoveries you've made.