Monday, November 26, 2018

Goblin Camp Continued

Travis continued

This pr addressed that after a lot of trial and error our travis.yml got quite out of hand. My job was to clean it up and make it look like it was made by someone who knows what they're doing. It was kinda hard to implement since every change I was unsure of I had to commit it and push it just so I can see if it worked. Needless to say this made it take a lot longer than I thought. I also moved the depenencies that were being installed from source and put it into a shell script. This removed the clutter in the .travis.yml and the script could be used by people who also want to build them.

The future

What I spent most of my time on was trying to get an actual playable version of goblin camp running. The boost library it needed was out of date and couldn't be installed through my package manager and when I tried to install it from source it couldn't be found by my makefile. Trying to preserve my sanity I just started a ubuntu 14.04 vm and used their package manager to get all the old packages I needed, and surprisingly it worked.

In a way it is slightly terrifying since now I have no excuse but to work on the code...

Sunday, November 18, 2018

First PR

First Internal PR

Goblin Camp has been classified internal so I've been working on that trying to get travis ci working with it. Travis is an automated build system that when you create a branch or a pull request will build the project to check for errors. This makes development easier since people who can't build the project or forget to will still have it built. This is useful to me as a maintainer since its a quick way to see if it is safe to merge into master or just test things without having to go through the trouble of setting up the environment.

Travis CI

All of the build configuration is done in the .travis.yml file in the root of the project. I gave it commands to pull packages that were required from the Goblin Camp as well as try to run the build script. Of course it didn't build since the Boost.Build was horribly outdated and trying to find out how to make it build would required a blood sacrifice or something along those lines. Thankfully it was not in the scope of my issue to get the project to build. I just had to make a .travis.yml that tried to build it. It was pretty simple but I learned a lot about travis, like its free and kinda slow and our build script kinda sucks. It finished off this pull request even through right now it's kinda of useless but I have a feeling that trying to get Goblin Camp to build will be a whole different story.

Arcane Knowledge

Goblin Camp

Goblin camp has recently taken a large set of real estate in my head. Its a perfect storm of challenges and things I understand. The first big challenge was getting this beast to build and spoiler warning, we did. It took us a lot longer than I'd like to admit but what I would like to admit is that I didn't do this alone. A good friend of mine, Tony Sim trudged through the perils with me on our journey to compilation. Which unlike most open-source we worked on it in the same room, using the same computer(mine for the record). This encapsules what I think opensource has the capability for, collaborating locally or globally. This very local open source has its own advantages and disadvantages than over the net. First off you can bounce ideas and try things very rapidly as well as tag out when you're head is going under water. This was especially useful since the only dev environment we had that had the potential to run this was my laptop and all the changes we made were instantly visible to both of us.

Hacking through

To try and get it compiled we mostly just threw commands around and installed packages with no regard. Exporting environment variables, reading posts, trying not to give up were all things that we did. Every time we went through this we would gain maybe 1-10% extra compilation then it would crash again. Telling us errors about not being able to locate packages that we're removed from the libraries it uses, saying it can't find packages we have, that our packages are out of date, our compiler is out of date, it can't find headers from our packages, it just went on and ooon. So we hacked away at it for a good few hours or days, I couldn't tell, when you've fallen into the rabbit hole time gets distorted.

Success?

After the whole ordeal we had it at 100% compilation and we thought this was it!!!... then it failed at linking. I have never been more discouraged by a single program. The problem was in a cmake script. It was an easy fix, but hard to find. After it compiles AND links I thought the build script didn't work, in the instructions it says it would put it in the build folder, but I found it in the src or root I can't remember. The moment of truth was finally upon us. We have slain all the enemies the compiler threw at us. We found the sacred texts that allowed us to build every dependency. We shacked the objects together. We were victorious! Our prize? "Segmentation Fault". No GUI no nothing, just "Segmentation Fault".

Pull Request

For my pull request I updated the travis.yml with all the environment magic we struggled to find to get some automated building for it, even if it seg faults. On our journey we found a lot of issues that were made into bugs and then into pr's. Even though we both worked on it, it was easier for one of use to commit the changes to a branch and merge it. My issue was updating travis which is something I was familiar with and I also had a pull request that compiled a package from source. On the horizon we're probably going to faze out the outdated libaries and try to get it to not seg fault, who knows maybe this project is cursed but now I bear the mark of the curse and I've dived too deep to come up for air now. Not when I've gotten this far.

Wednesday, November 7, 2018

Diving Deeper Into Open Source

Recovery

After the frantic nature of finding projects, finding bugs, building projects, and making pull requests I needed a little break. So I have been looking into projects that might find interesting. A few that caught my interest were Dark Chatter, Creative Collab and supernova from fellow students.

Dark Chatter

Dark chatter is interesting to me since seems like it will rely on low level stuff like constructing packets and it will help me understand more on how wifi works.

Creative Collab

Creative collab also expressed interest in doing the project in mostly as a backend server that has public end points. It would be neat to learn how to create a server to host an api that anyone can use.

supernova

Super nova caught my interest not because of the idea but more of the language choice. I have never used rust and learning it through open source seems like a good way to find out about the language.

External Projects

Goblin Camp

Goblin camp is kind of like a open source dwarf fortress and it was forked by a class mate with the intention of parallelizing it, since the original is still running on a single thread. As of right now I am stuck in the same slog that kept me from trying other projects, getting it to build. But since I have a little more leeway with this due date being more lenient than the hacktoberfest one I think I will try to push through to get it to work. The project is also been abandoned for a couple years so it might take some time to get it all working.

Path Forward

Now I'm going to try to dedicate some time to building the projects I'm interested as well as seeing what I can contribute. Maybe even make some issues, who knows, I feel more confident after hacktoberfest and excited to apply all that I learned going forward.

Creating Releases