Planet SoC

It looks like the rent is due on our developers’ suits. It was fun while it lasted, right? :B

I looked into the server var problem a bit more, but no dice. It doesn’t seem to be a problem with my code, but there are a few things that I still haven’t looked at, like the values in the POST request. So, today was effectively just code cleanup, to make it presentable to the fine folks at Google.

Now, just because my primary obligation is gone, I won’t abandon my project yet. I’ve spent enough time on it to have an interest in seeing it finished, and quite frankly, I don’t want anything else to hurt my image in the eyes of the BZFlag team after my admittedly unimpressive performance.* So, I’ll probably keep posting for a week or two, and maybe more afterward but less frequently, as I fit this into my school schedule.

Ta for now!

Today I got a few parts of the codebase that are under my control up to date with the rest of it, and I also found a few good leads as to the source of the BZDB problems: firstly, there is in fact no API method to actually grant permissions, and the one I was using was only to check if they were set. I’ve also found that a few of the server variables are being set correctly, which means that it could easily be a problem in my own code, and idea that I’ll investigate tomorrow.

I’m fully aware that my performance has not been stellar, and that webadmin will not be fully functional before final evaluation. With the deadline very close, it’s therefore imperative that I focus on making as much of it usable as possible. Also, recently I’ve been spending too much time on these problems without asking for much help, which will change immediately.

Amazingly, I was able to uncover a bit more of my own stupidity: I noticed that the API wasn’t even being called for allowing group permissions, which was because I was using a completely different data-passing scheme in my groupPageCallback than the one in the interface I’d designed. With that fixed, permissions still aren’t properly granted, but the error message works! Now I must poke deeper.

Again I was forced to abandon my work for some time today, because of a poorly scheduled dentist appointment, the excursion for which ended up taking more time than it should have. However, I was able to take a deeper look into the BZFS API and discovered that yet more of my error checks were not doing anything useful. The plan is still to find what is keeping server variables and group permissions from being saved to the BZDB.

I was out of town for most of today, but I was able to fix a compiler warning that was preventing my build (since the configure script threw in -Werror for some reason). I also took a quick peek with gdb at the parts of the BZFS API that relate to the BZDB, and it looks like something in the API itself could be the source of my problems. Not unlikely, either, as the only other thing that uses the API functions for setting server variables and the like is the python plugin, which may or may not have been tested in that area. Next week I’ll find whatever it is that has disabled my interface so badly, then move on to filling in the API where it doesn’t fit my needs.

Well, JeffM explained to me that permissions shouldn’t be an issue for my plugin at all, but it turns out that at least one of my error checks was checking for a status that wasn’t useful, which caused the false alarm. There was also a bit of confusion around the type of markup I was using (thanks blast007). I still wasn’t able to find why nothing is being saved to the database, but at least everything is being displayed correctly now. I’ll continue to pursue this problem, after which I should be able to test kicks/bans in conjunction with the client.

I was able to produce my own “can’t save server vars” error message, which is helpful. No such luck with the group permissions, though, which is how I came upon the theory that it just wasn’t displaying them correctly. It hadn’t struck me as odd that all of the checkboxes were blank until recently, when I remembered that a few of the groups get some basic permissions automatically. It took me quite long enough to then realize that my template did not even have the conditional check to determine whether each checkbox should be checked. However, trying to change the permissions doesn’t seem to save anything, and no error is given. I have a hunch that nothing is being saved because the plugin doesn’t have the proper privileges, an idea that I’ll have to go over with Jeff, along with parts of the API.

I’ve upgraded my OS over the weekend, so it’s taken me a while to get back up to speed. Today I fixed a few obvious semantic bugs and added more error checking, which hasn’t yet revealed any problems as far as manipulating the BZDB goes. So, I’ll have to dig a bit deeper tomorrow with gdb to see if, for example, setting group permissions is working fine, but displaying them isn’t. Once those issues are out of the way, there are a few API functions yet to be implemented, especially for the help system.

Flash was so nice as to clean up the dangerous pointer usage in HTTPServer, so no more SIGABRTs. Also, a few more bugs down, a few more found. After today’s work, I’m at a point at which I can start focusing on the functionality of the web forms. I started by adding a bit of error checking, which should help me know when I’m doing it wrong.

A few pointer errors down (this time not in my code :). I had issues getting valgrind running, but with brlcad and Flash’s help, I was able to get somewhere. Interestingly, though, something “impossible” caused valgrind to crash horribly. I have a hunch that this is because the version I’m using is outdated. This will be sorted through tomorrow, while the bug hunt continues until further notice.