It's been a little while since I really updated anyone on anything. I have so many projects, so many things going on so what have I been working on? Well besides a super huge project at work ;), what I've been doing. Well GIM is fairly stable and has had no complaints (and perhaps no users ;) ). The new sparemint site seems to have a lot more interest and that's been consuming my time. Lately the most time has been spent on adding an automatic build system and completely revamping the package upload process. Now there's build farm functionality provided by simplistic shell scripts so other users can contribute. Make sure to read more ;)
A Christmas release of GEM Instant Messenger has arrived. GEM Instant Messenger is an AOL instant messenger compatible IM client for Atari systems running MiNT. This version has fixes of iconification, font selection issues fixed, it's built with Windom 2.0, buddylist size/position is saved in the configuration file, debug text has been isolated and removed, bug causing buddylist to redraw over everything fixed, and restructuring and beautification of all dialogs.
Just a note to let everyone know there's new builds available under the MinT/XaAES snapshots section. The freemint builds include a lot of stuff like the latest Toswin2, kernels, drivers, etc. The development packages section has a new binutils which so far seems pretty stable. libiberty goes with it. Additionally the sqlite package there works really well and could be fun. If you're curious, you can also download "sum-0.1a.tar.gz" which is an alpha version of the eventual standard GEM/CLI sparemint system updater client. It's getting more mature and a real release will be done quite soo
Sparemint Dev Site: I suppose some people around here really don't know me. There's not too much to me really. I suppose there's one thing that can really sum up my complete lack of *professional* programming skills - poor planning. The sparemint site was pretty decent but due to some serious errors in the database schema things were pretty limited. An RPM package consists of the following parts. A source rpm, which when built generates one or more binary rpms. I made several assumptions in the code which were very bad. 1. The binary name will always be a derivative of the source name.
I managed to pry myself away from Anarchy Online tonight to work on GEM. I've been getting somewhat obsessed with this online game which is probably a bad thing ;) Anyway, tonight I did 99% of the code for updating via the GUI interface. This puts the sparemint updater ready for a 0.1 release, and it'll make it functional and ready to switch the dev website to live. Pretty cool.
I noticed today that atari-source.org was delisted from Ataritoday.com. That's a shame. I'll really miss the hits, but it was a proper decision as Ataritoday is focused 100% on news headlines rather than my own interests, blogging and personal projects. I just didn't have the motivation to keep up with news when other community members do it much better than I do. There's way too much duplicated effort - we need no more.
Maybe my life is boring, but I encountered what I feel to be a major problem. The new sparemint site is designed to be 100% community controlled, perhaps with a web administrator to handle db emergencies and such, but it's designed such that so long as a few people are around, sparemint can progress. Not to say Frank Naumann will disappear at any point in time, but I firmly believe bringing the community into the process will help to germinate a growth in MiNT. Because of this, one of the most complex parts of the website is the package upload section. The way this works is that a user will upload a package to a specific dir on the atari-source.com ftp server. Once they do, they will show up in a directory listing provided for the user when he hits "upload a package". Now just to make sure it picks the right ones, it asks the user to select his packages residing in this folder (rather than guessing). All packages have at least a source and binary rpm. Some packages have multiple binary rpm's. This creates an interesting management issue. Do you allow users to vote for whether or not individual portions of an upload are correct or the entire thing? I chose the entire thing, and as such, when a user uploads for instance curl, curl-devel and curl.src.rpm, the site has to make heads or tails of what the user is providing to it. The source is easy to figure out, but how do you figure out the "primary" binary package. Well that's easy just use "curl" .. the base name. "curl-devel" and "curl-docs" will be "child" packages. Simple enough until today. libungif has two binary packges. libungif-devel and libungif-progs. Do you see the problem? ;) No primary package was selected due to no package having the name "libungif" and hence two primary packages were shown! I decided that what will work best is to simply use the first package in a db return as the "primary" package and make any other packages dependent. The effect that making this kind of decision provides is that when a user logs in and sees packages to approve or disapprove, he will see one approve/disapprove option for "python", and it will show all the child packages "python-devel", "python-libs" etc.
Well today I worked a lot on SUM and during the last few days I've been attempting to get GCC compiled. Now a lot of people have succeeded in "compiling" the gcc 3.3x branch but as far as I know, nobody has produced a working g++ compiler. Now, we can't move on in sparemint without it in my opinion because there's almost certainly a few package in our current repository that are C++ or have C++ in them. In addition, this is a pretty basic foundational package - we can't move on without it.
Thus we're stuck with gcc 2.95.3 right now, and all we could really do is compile a sparemint for -m68020-60, however the gcc 2.95.3 optimizations for this are somewhat minimal I think.
Well, since SQLite3 is now compiled I started building support for it into SUM. Then I started moving some old data storage to sqlite and this started happening at a blinding pace. Before the end of the night I had client side update resolution and information displays complete. A few more days work is all it will take. Once completed, all that will really be necessary is conflict/dependency resolution but such things are not currently important to sparemint users. (Right now, they use a clever but inherently dumb perl script). This is completely important because once SUM is in a useable state I'll be able to begin the push to replace the sparemint site. Once that is done, we'll be able to build a version of sparemint specifically for gcc3.x and m68020-60. In theory, this should result in a substantial speed boost. In addition, the full recompile will work any statically linked bugs out. I also managed to cross build gcc 3.3.6 today and compile mintlib and freemint with it, which is pretty slick. We're on our way :) The lesson to be learned here is that C, without help from supporting libraries is a rather poor language to program high level applications in. I was spending all my time creating comparison functions, linked list handling, data structures, etc. In fact, it got so bad that I started looking for a way to do dependency resolution on the server via a nicer high level language, PHP. Now I can in what took me weeks before and 50+ lines of code get done with 1 single SQL statement. That's important to pushing it out the door.
Hello all, as you can see some things are changing in the layout and all articles and helpguides have been moved over for your enjoyment. The next thing to come are the reviews and after that we'll have for the most part all of the content moved over.