Hello! If you've looked at the code page at all, I'm sure you've noticed that it is often slower than it should be. One of the major issues, I think, is the rather low persistence of cached data. I think there may be some kernel option (some cat 0 > /proc/) that is doing this. I'm not entirely sure. Anyway, currently the page searches through all available repositories, finds out when their recent commits were and decides what three to display at the top. I decided that it would be neat to have some sort of API, and to use it in javascript to fill in this information dynamically.
There have been a number of commits to the code for this site over the last day or so. The /api URL has come into existence, and has had several features implemented. At the moment, there are:
- status: to get various feed-like status updates I may start making. At this point it only ever returns the hard coded status above ;)
- cat: to list repositories, branches, files/directories and to actually cat out the files within. The encoding of the returned files is a little funky (\n and \t have been escaped, among others) to have it be proper JSON.
- clang: to list the repositories using a specific language, or all of them if no argument is given. This is just so that it is easier for me to have features without proper thinking out cat
- commit: to list commits to a repository/branch, and to get the actual diff from a commit. This is the main thing I need to fix up the code page.
If you want, feel free to play around with the various functions. If you specify no arguments when it needs one, it will hopefully tell you. However, there is no real documentation besides the source, hehe. Perhaps there needs to be a help function added. Edit: I have added the page I was using in testing to the static directory. Check it out.
Some neat structural changes to the site have been made, such as automatically included javascript per directory, if it exists. So, if you request the dgi.d source file from dsrv , there might be several javascript files included. First and foremost, there is js/_.js which is included in all URLs (if it exists). Then, the next possible includes would be:
- js/code.js
- js/code/dsrv.js
- js/code/dsrv/files.js
- js/code/dsrv/files/master.js
- js/code/dsrv/files/master/src.js
- js/code/dsrv/files/master/src/dgi.d.js
and then finally, the old js/main.js file. Now, most of these will never be used, but the first level there might be used. For instance, the about page currently uses javascript that is defined in js/main.js. In the future, this will probably move to js/about.js file.
We now finally get to the glaringly ugly status box :) Essentially, I need some quick test of the API and of the module function system. The module function system is really just an array of functions defined in _.js which can be added to from the other included js files. The window.onload event is then hooked up to a function that calls them all in order. Now, why does the status box look so ugly? Well, I hear the entire site is ugly, without users overriding the CSS with their own (which is what I do). The current setup isn't the easiest to adjust the style with, and it doesn't look completely horrid. In essence, it looks ugly because it will anyway, but I do plan on getting it at least less horrid.