The start of this course is showing us why C is such a powerful language, with regards to the problems we are attempting to solve. At this point, it seems that both languages can be used for our requirements. Although I am sure we will get closer to the machine, and we will see why C is such a versatile language.

So far, we are recreating the cat command on the unix command line. The logic behind doing so is similar to logic we have previously had to employ throughout our CS experience. But for me, instead of just including stdio.h like I usually do, we included other header files, that stdio.h includes and uses, giving us specific functionality instead of blanket including everything. Understanding what tools are required specifically for any problem, and being able to identify them, is a skill I soon hope to excel at.

After making a simple version of the cat command in C, we were challenged to come up with an addition to it that allowed the user to view line numbers given the argument. Through this simple version, we introduced command line arguments to our command. However, I could not seem to get the line numbers to show up properly. I could get the loop to spit out every line number, starting with the second line. It would display that line with the number properly, all the way through the last line.. plus two more lines for some reason. I could not get the first line number to effectively match with the first line of the “cat'd” file. I will have to look into that a bit more.

Next, we started our own implementation of the who command. So far, we have gotten it to print out the current user info, one at a time. It cycles through current user information when the desired key is pressed. I am interested to see where we can take this program. I am also interested in getting our first project so that I can take what we are learning and apply it more.

This week we completed implementing the who command in class. Our version is almost identical to the shells version of this command now. I am learning a lot about reading manual pages and the useful information they provide to us. As of now it is a little daunting, but I am sure that I will grasp it relatively soon.

We also implemented the list command, after finishing the who command. We got it to work properly in class, but I must have missed something as mine gets a seg fault when I attempt to run it. I will just have to comb through it more in order to figure out what is causing this issue.

Our first project was also assigned this week. We have to apply the change mode command in C. Luckily for us there is a function in the manual page that does this, given the correct parameters. So far, I can get mine to work properly so long as I tell it what modifications to make, and what file to change the permissions of before I run the program. I enter string literals into character arrays because you cannot initially an array with a variable. I need to figure out how to get the command line arguments I need into character arrays for the function to read. Once I can do this, most of my work will be done. If I can complete this relatively soon, I should be in good shape to complete the first project on time.

I found that our implementation of ls requires additional arguments to scan certain directories. It does not default to the current directory as the unix version does. So that takes care of that issue that I was having. We worked on it a little bit more last week.

I also finished my project. I got the command line arguments to process correctly as strings. I found a way to effectively store input from the command line into character arrays for the program to read from, in order to modify file permissions. After that, getting the verbose argument to work was the most difficult. the help and version were simple enough. I pretty much had to double the size of the program when I added in that argument. At the end of the day though, The program works as intended. I also feel a lot more comfortable browsing manual pages and looking for specific solutions to problems that I encounter.

This week we have to come up with a way to efficiently find the prime numbers up to a certain value. We were given two methods to use and had to come up with out own method to use after that. Our interpretation is supposed to be optimal as the other two are more rudimentary. The first implementation is using a brute force method in order to determine if a number is prime. The only efficient part is that if a number is determined to be not prime, it will cycle to the next one. It does this for an amount of times equal to the input number. After that implementation, I implemented the square root method. This is similar to the previous one, except for the fact that instead of going until the number you’re checking the primality of, you go to its square root. This method appeared to be a lot faster.

With my own interpretation, I decided to use the Sieve of Eratosthenes. With this approach, you find a prime number to start, say two, and eliminate every number in your list of generated numbers that are a multiple of that number. This method is by far the fastest. However it is the only one that uses arrays, so with that it is giving me problems. After a certain limit, I get segmentation faults and I am currently trying to figure out why. I refuse to go to a more straight forward method because now I don’t want to lose time when it comes to efficiency. I’ll keep having to mess with array sizes and the way in which the data is stored and parsed.

I have solved the implementation of Sieve of Eratosthenes with a little bit of help. After learning I had a few of redundant logical sequences, and two massive arrays of which I only needed one, I shortened the solution significantly. But I could not seem to get it to work, it would not allow me to assess values of certain limits. To fix this, I had to allocate memory rather than declare an array in order for it to work properly. After doing this, everything worked as planned. The run time of the Sieve was significantly faster than any of the previous implementations.

This week we started to take a look at forking our programs. We have to take the brute force methods and the square root methods that we had implemented last week, and make them much more efficient through the process of forking, allowing two or more algorithms, or multiple implementations of the same one to run simultaneously. This will in turn reduce the run time of the program by 40ish percent. At this point, I am still trying to wrap my head around how exactly to do this. In class we had an implementation that I mostly understand, but running an algorithm, especially parsing information from the command line to do it, it a little more tricky. I think that I have to just look at it a bit longer in order to grasp fully what is going on.

I have gotten a good grasp on how to implement a program that utilizing threading when finding prime numbers. So far I have finished the brute force method, aside from putting the thread outputs back in order. I am thinking that I can put them in strings like I did when running them under different processes. I am just not completely sure how it is managing memory so I would like to get confirmation that I attempt to implement the solution to that problem. I know implementing the square root threading program will be simple as I have the core concepts down. I am much more comfortable using structs as well as the arrow operator in my programs now too.

I think a big mental hurdle for me occurred last week when implementing multiple child processes. Wrapping my head around what goes on in a program that you write without explicitly seeing it was new for me. I couldn’t look at my program from the top down and analyze what was happening, I had to think about multiple things happening at the same time. Threading takes the same mental approach and since I have, at least in my opinion, gained a new perspective when approaching problems, the solution came a bit easier. After looking at it for a while and studying what threading is and the syntax to accomplish it, I surprisingly had no logical errors on my first compile. I can’t remember the last time that has happened. I am confident that going forward with this project I can finish it without rushing last minute.

Last week we also started to take a look at sockets. I have a feeling that sockets are going to throw me for another mental curve ball. We only started getting it set up, and I can’t even recall what exactly we did in class. I can definitely wait for that project to come around.

It seems that I made a recurring mistake with regards to the threading project. I assumed that after I had printed out the prime numbers, although not in order, that printing them in order would be relatively simple. I was wrong. Getting the threading to work went faster than I expected. It was recommended to me that I use a 2d array in order to organize the output of the primes back in order so that it would pass the primerun test, and run correctly. This was the first time that I had ever used a 2d array to solve a problem. After looking online for a while, and having it explained to me, I got it implemented. This part of the project took longer than actually implementing threading. Picking up the pieces you put down is no joke.

We are looking at sockets now and there is a lot to them. I have a hard time gathering everything that we do in class, because it is so much information. I can see it being done, but if I had to recreate it, or half the time even explain what the program did, it would not be as easy as anything has been so far this semester. It is fascinating though. It is the hardest but most interesting thing that we have done. I am just glad that I have gotten the grasp of everything so far. The fact that if you want a server to receive data from more than one client, threading is needed, or could be utilized, is cool. How things build off of each other out of necessity.

I started attempting to create my own client server model at home. I started running virtual machines so that I can play with systems programming outside of lab46. I am also reading Beej's guide to systems programming and while helpful, there is so much information in there that saying read through is a gross understatement.

Hopefully by next week I will be writing about how I have set up my first client server model using virtualization and systems programming.

So after having a week off and many aspirations of accomplishing side projects and enhancing my learning experience, it turns out laziness won the day. Or week. I didn't manage to get anything I had planned done. I am okay with that though because I guess they give us break weeks for a reason. I feel like actually utilizing a break week to take a break from school related activities. I think it will be beneficial for me going forward into the last month of the semester and finals.

I'm not sure if I wrote about finishing the project that was last due outright, just that I had implemented a 2d array to store the results and print them back out in order upon request. When I was running the program at home, and even on a pod, it wasn't seeming to work. After getting help and looking at the top command, it appeared that when I ran the program it was taking up much more memory than it was supposed to. That sounds weird, but something is going on where it balloons out of control and hits the systems limits when it runs. This messes up the execution, and makes it fail the tests in primerun. After moving it to a system that has no memory restrictions, and when the restrictions were removed on lab46, the program ran perfectly fine. I am not sure if I will be able to figure out why my program seems to be taking up so much memory.

The Friday before break we didn't continue on sockets, but instead we starting looking at kernel commands and reading the bit patterns that have them set to active or not active. We specifically did the with echo. We didn't get too much deeper than that but it was certainly interesting seeing how direct bit patterns can dictate commands in the kernel.

It looks like we have diverged from looking at sockets for now. We have learned a lot about them recently, and their uses are really interesting to me. Now we are looking at something else that seems like it is pretty interesting in signals. At this point we have just learned that certain programs can and will block signals, in certain kill commands.

We starting by running a loop that counts and prints the integer it is currently at. When a kill command is issued, or a signal is sent. Depending on the signal, the program will react differently. This is based completely on what we decide to have it do. Using the signal function, we are able to block the original signal, and react how we choose to that attempted command.

The intricacies that happen “under the hood” of our program and kernel, and how the commands are not actually interfaces with the program itself, but the CPU are still sort of mysterious to me. The more we look at it, the more I am sure I will understand it.

Last week we continued to work on shared memory. We are doing it in the form of a basic sort of chat room. Since everything is a file in unix, we are writing to files that others access. When one person writes to a file, everyone else reads from it. After messing with in class for a few days we seem to have gotten it working on a basic level. When one person writes a message to their screen, it ends up displaying that onto the screen of anyone else running the same program.

Were looking into shared memory on a very basic level. I am excited to look deeper into it to see where we can go with it. There is talk of using ncurses to make a paceman like game and have other users control the ghosts or something of that nature while one player controls pacman. We talked in class about how this was capable of being done on a closed network, and that if you were to open it up to other networks that it would be easy for somebody to do something malicious.

This past week we got our end of course experience. I can't wait to get started on that. It brings back such great memories from C programming and Unix. In all seriousness, I am excited to work on it and see how much I have retained throughout the semester. It seems like we have covered so much, and at the same time, it feels like we have barely scratched the surface. I know going forward that there is always much more to be learned. Now I feel like I have a basic understanding of how to find the information I need.

This week we have also started looking at and playing with ncurses. This is the first time I have ever looked at this library. In class we basically did fancy things with a hello world version of ncurses. It turns out that it is pretty fun to mess with. After messing with it in class we were asked to create a program that would move a cursor type character, in the variations of V, around the screen in a spiral, where the V would face whichever direction the cursor was going. There was something else we were asked to look at but I honestly can't remember what it was. I think we're going to go over it in class tomorrow though so I think I will be okay.

As far as the cursor program, when I first started working on it I assumed it would be a giant headache figuring out how to plot where to print to, because thats all that it requires. It turns out after looking at it and playing around with it for an hour or two, that you only need four sequential for loops embedded within a standard i counter loop, with some variation on conditions based on the i value to get it to function properly. The only thing that is a little annoying about ncurses is that when you test your program to see if it runs properly, you're just staring at a blinking moving cursor around the screen. It almost strains your eyes after a while. Hopefully I don't have the tetris effect of that animation when I go to sleep.

This week starts the last week of the semester. It seems like it has gone by really fast. The fastest of the three semesters I have been attending college. I have taken a deeper look into the end of course experience and am comfortable that I will be able to maintain a solid pace to finish it on time. Especially since my finals week isn't too rigorous this semester.

In class we're continuing to look at ncurses and are creating an ncurses pacman game. This project branches out further in my opinion than any we have done thus far. We're getting into multi file implementations, which is always nice to gain experience with. So far we are working on getting the attributes of what we are going to print to the screen finished. Hopefully tomorrow in class we can finish creating the game field at the very least. I feel like we can get further than that for sure.

So this is going to be my last opus entry for the standard opus outside of the eoce. I am working through the end of course experience now and it seems to be going smoothly. We have covered so much but it is nice that I have so many examples, and can reliably find information on my own to figure things out now in a manner that is more efficient previous to me taking this class. I am confident I will finish on time.

Whether or not I will need to come in to class to clear some things up is still up in the air, but hopefully I don't have to make an extra trip up to the college to finish it up. Going forward I am looking forward to taking data structures. I feel that systems programming is a nice gap class to have taken to learn a lot of new things, that I will be able to apply during data structures.

As an aid, feel free to use the following questions to help you generate content for your entries:

• What action or concept of significance, as related to the course, did you experience on this date?
• Why was this significant?
• What concepts are you dealing with that may not make perfect sense?
• What challenges are you facing with respect to the course?