The biggest change in this release was the switch from Phobos to Tango. In the process, the List and Map classes were changed to implement Tango container interfaces. Unfortunately, some of that code isn’t yet well tested and well documented, so please report any bugs you may find. You can find the release in the SourceForge.net file release system.
Posted by randomz on July 11, 2007
I just commited the changes to Sofud that make it work with Tango instead of Phobos. As expected, it wasn’t really difficult, just annoying. Writing I/O code is pretty error prone if you’re working on the level of Tango conduits and trying to support all Unicode encodings. Debugging was the really tough part of it; most of the conversion was done with a couple of find & replaces.
I shall release this version as 1.0.alpha.2 as soon as I feel like it. Right now, I’m too exhausted from bug fixing. :o)
By the way, I finally found a nice text editor that can correctly handle any Unicode encoding. It’s a small freeware called BabelPad. To my puzzlement, most editors out there can only handle UTF-8 and UTF-16, even though UTF-32 has been around for a long time now.
Posted by randomz on July 8, 2007
I’ve finally had an opportunity to try out Tango. As it seems like I’ll be using it for my game project (details to come… maybe), I’ll switch Sofud over to Tango.
As I don’t have the energy to create and maintain a dual version, there will be no Phobos support. I think this is better than the other way round, because I already feel that Tango, although the documentation isn’t complete yet, is more complete and better designed than Phobos.
I hope moving to Tango won’t be a big problem, so I plan to do it within the next week or so. After that, an alpha.2 release may be due.
Posted by randomz on July 4, 2007
I went ahead and released Sofud 1.0.alpha.1, even though the web site doesn’t say anything about it yet. (This has to do with me having restructured the web site, but not having the time to move all the content to the new site.)
(Almost complete) code documentation is included, but pretty much no other documentation. So if you try to use this version, you’re in for an adventure. 😉
Of course, you’re welcome to send me email (email@example.com) if you have any questions. Still, if you’re not willing to experiment, I advise you to wait for a better documented version.
I put this version together mainly so I can focus on getting more stability before starting on the few features that are still missing from a “real” 1.0. This is because I needed a version of Sofu I can really use in my projects.
Posted by randomz on June 17, 2007
Lists in Sofud are implemented as arrays internally. This is perfectly sensible, as we mostly need fast random access to the element. However, this also means that any modification operations take O(n) time.
Not so bad, as we don’t expect lists to change a lot. But in one situation, performance could be improved: During parsing. The parser should look ahead how many items are going to be in the list, then create an array of the right size, and then insert the elements into that.
Not that big of a change maybe, but it might require some parser restructuring. And the speed drawback of the current method shouldn’t be noticeable with normal sized Sofu files, so this isn’t going to be in alpha1, but probably in 1.0.
Posted by randomz on May 30, 2007
Interesting how much effect this blog has on the download rates of Sofu. They go up every time I publish a post here. You’d think that an obscure, unknown library written for an almost as unknown language wouldn’t find many people stopping by just because they saw the post on the “most recent posts” list on WordPress.com. But there seem to be some: Observe this statistics page, which claims I had some 50 page views within about two hours just when I published my last blog post.
I just finished the new system for building the source code documentation for Sofud. It now works without bud (if you haven’t noticed, bud is “out” in the D community), but first uses rebuild to generate a modules.ddoc file for use with candydoc, and then uses dmd to build the actual docs. Yes, this means the whole source code is processed twice… so maybe I should just build the modules.ddoc from my own code instead of letting rebuild do it. But still, dmd is fast enough, so I don’t see the point in optimizing.
Posted by randomz on May 26, 2007
I recently took it on me to convert all the module names in Sofud to lower case, following a small remark in the D documentation: “By convention, package and module names are all lower case. This is because those names have a one-to-one correspondence with the operating system’s directory and file names, and many file systems are not case sensitive. All lower case package and module names will minimize problems moving projects between dissimilar file systems.”
Actually, I never had any problems with this, but to prevent any problems that might occur, I decided to do the conversion.
As had to be expected, it was a pain. The procedure was pretty straightforward: Change all the file names, then change all imports of all files, and then sift through the remaining compiler errors. But even though Sofud is still not huge in code size, there were a *lot* of compiler errors. So the whole procedure cost me some 4 hours I could have better invested if I had used lower case module names from the start, but you never stop learning.
I also started switching the Sofud build process to DSSS. DSSS looks pretty promising in that, if Sofud was to reside on the DSSS server, other DSSS packages could automatically pull it if they needed it. Also, a standardized way to distribute libraries and such is probably a good thing.
Using rebuild (an advancement of Bud which is part of the DSSS project) for the parts of my coding where I can’t apply DSSS has mysteriously solved all the troubles I ever had with bud, i.e. with using derelict under Linux. It just works. I like it. 🙂
The 1.0alpha1 release of Sofud could be drawing nearer. There are only a couple of points on my release todo list left:
- Produce more usable error messages, i.e. improve the exception classes.
- Make it work on Linux.
- Find a (preferably automated) way to create the documentation without using Bud.
- Complete 90% of source code documentation.
- Write at least one or two chapters of the manual.
Posted by randomz on April 28, 2007
I’m currently looking for a way to print the “path” of the relevant Sofu object with every Sofud error message. However, this is not quite as simple, because the hierarchy can be edited in memory, so I can’t simply create the paths at load time.
So I need a way to create those paths at any time. Since I save a map’s attributes inside an associative array, this means I have to do a linear search (yuck) over its keys. The same in the case of a list: it’s not sorted, so I can’t use any kind of smart search algorithms.
Still, this situation should mostly only occur in error situations, so it’s okay if it’s inefficient.
Posted by randomz on April 25, 2007
I’ve decided to put together a first Alpha version of Sofud 1.0. The basic parts are all in place, so it should be usable without problems. Still missing are a couple of medium-level features listed below, and a lot of documentation. This is also the reason why I’m not planning to announce this release anywhere except the Sofu web site: It would be pretty hard for anyone new to get to know the library.
Missing features, pasted from the todo.txt:
- FEATURE: Implement SofuString class to reduce Unicode conversions
- FEATURE: Implement transparent GZIP compression
Neither of those should do much to the existing interface, though.
Before releasing 1.0alpha, though, I want to do two things:
- Drastically improve the quality of the error messages. Sofud 0.2’s error messages were quite good if you were only dealing with Sofud objects created from files, but I stripped most of them out, so I have to redo them. And I want to come up with a better way to show error messages that refer to objects created in memory.
- Get at least a little bit of documentation done.
The biggest reason for me to release this version possibly prematurely is so that I at least have an official version to use myself. The interface should not change much from now on, so I guess it’s OK to release soon.
Posted by randomz on April 6, 2007
I spent too much time today trying to get Bud to work with GDC under windows. GDC works fine, and installing it was actually pretty straightforward: Installing MinGW, installing GDC via the installer, and then installing ActivePerl in order to be able to use the ‘gdmd.bat’ perl wrapper script for dmd command line compatibility.
What followed then was a bud error and reading through the (terribly unorganized) bud docs in order to find something. Having found nothing, I tried the bud forums, which promised to be at least of some help. I created a build.cfg file and spent about two hours trying various settings, finally managing to compile my source files. But I still haven’t moved bud to link the resulting objects to an exe file.
Actually, this isn’t my first time fighting with bud (formerly build). My recent attempts to use bud on linux (with DMD at that time) also have been only partly successful. However, there seem to be people who have accomplished using bud on linux.
I think build is a wonderful tool. But it’s a shame that development seems to have stalled (the SVN repository hasn’t been touched in almost half a year) at a phase where there still are many unresolved problems. I think the build tool is pretty central to the D community, so maybe it would be good to have a larger (non-one-man) team to make it a more mature, better-working tool (and to improve the documentation!!!).
In fact, I feel I would like to contribute to the project. Still, I’m afraid it will eat more of my time than I can bear, so I will give it some more thought.