Planet OsDrawer.net

For those unaware, Haiku applications have certain information stored in resources. This includes the version, short and long descriptions, and a duplicate of the signature specified in the application object's constructor. You can easily set this information quickly by adding an .rdef file, which is a text-format resource file.

To quickly create and edit this information, add a new file by pressing Alt+N or choosing Add New File from the menu and enter the name of the .rdef file, such as Resources.rdef. Double click the file's entry and when it opens, you will be greeted with a text file where you can fill in the information for your application with a minimum of fuss.

Editing .rdefs not to your liking? Make a Resources.rsrc file instead, right-click on it, and choose "Edit Program Settings" to do the same thing with the FileTypes app. Either way, simple and fast. That's the way we like it. ;-)

August 27, 2010

Downloadable from BeBits and Haikuware.

August 25, 2010

Paladin has grown quite a lot since its inception. In fact, it has a lot more features than BeIDE now. I worked extensively with the venerable tool when I was reverse engineering the .proj file format. Having gotten accustomed to Paladin, BeIDE seems kind of sparse. Some of Paladin's features aren't necessarily as obvious as others, so from time to time, I'll be posting tips on making your use of the IDE better, faster, and more convenient. What better way to work more effectively than from the author himself. :)

The Symbol Finder tool was introduced in version 1.3. It's a search engine for libraries. Did you ever have a time when you were receiving linker errors for a symbol that was missing, but you couldn't figure out which library it was in? Symbol Finder to the rescue. It's kept in the Tools menu, but it's also a separate application, too. Once started, enter the name of the symbol and hit Enter and it will search all of the libraries in the system library folders for it. Any hits will pop up in the search results.

August 18, 2010

After yesterday's release fiasco, I quickly reinstalled Haiku using the alpha 2 branch in the source tree and while the version number hasn't changed, the Paladin 1.3 packages available via the links in my previous release post will work on alpha 2. My apologies for any inconvenience this oversight has caused. We now return to our regularly scheduled program. ;-)

August 15, 2010

It never dawned on me that people might want to install Alpha 2 and continue to use it. Personally, I can't fathom not using a nightly. I'm big on stability, but considering that Haiku is very much in an alpha state, I expect problems. Some revisions are better than others. Right now, one of my machines is running r38082, which is a nice, reasonably stable build, but it apparently has some symbols that Alpha 2 lacks. Looks like I'll be putting out an Alpha2 build tomorrow. ;-)

Using development builds of Paladin are not normally what you might expect of a development build for other projects. I don't use release builds of Paladin -- I use the bleeding edge. If something breaks, I un-break it because otherwise I can do any further Paladin development. Using a development build of Paladin also tends to have newer features and fixes than can be found in the releases.

If you want to continue to run Alpha 2, that's fine. I'll be posting an Alpha 2 build soon. Here's how to build Paladin from source. You'll need Mercurial installed to do so.

From the Terminal run these commands:

hg clone http://paladin.hg.sourceforge.net:8000/hgroot/paladin/paladin
cd paladin
buildsuite.sh

This will actually build Paladin, PalEdit, and parts of the as-yet-unreleased packaging system and create a package on your Desktop. Open it and it will install Paladin on your system. If you want to use ccache or fastdep, copy them from the Paladin install folder to /boot/common/bin. The bug causing them to be installed in the wrong place is the reason why the packaging system isn't officially released yet.

August 14, 2010

It is my pleasure to announce the next version of Paladin, now available from Haikuware and DarkWyrm's Library. Although it has only been about four months since 1.2.1, a lot of work has gone into this release. Probably the single most noteworthy feature in this release is source control integration. Although it is just at a basic level at the moment, commits, diffs, and other common tasks are either a keypress or a couple of clicks away. Subversion and Mercurial are supported with Git support in development. BeIDE projects can now be imported. ccache has been updated to 3.0.1 and now dependency checking can be done with fastdep -- much faster than gcc's dependency checker. Some (accidentally) broken features, such as Run in Debugger and the Program Settings item for resource files have been fixed. Projects in the Start Window can be opened from the list using Alt + a number key, so Alt+1 opens the first project in the Recent Projects list -- this little feature has made a big difference in my own ease-of-use while using Paladin.

Some features didn't make this release, which I'm kind of bummed about, but I'd much rather get a stable release out now than a buggy one or a stable one 6+ months from now when I sort-of have time during the school year. The release doesn't use the new packaging system because I just couldn't get it stable enough in time, but Paladin 1.4 should use the new system. I can't wait for that because with it I can literally build the entire Paladin suite from source and package it with one command using a shell script -- truly One Command to Rule Them All.

As always, bug reports are genuinely appreciated. Enjoy!

Update: The binaries require at least Haiku r38082 because of some of the bugfixes that Paladin depends on.

August 14, 2010

It almost sounds like I'm eating Lucky Charms, but it's true. 1.5 weeks until school starts and already I'm getting my mind into that mode. I've gone into testing mode for Paladin so that, hopefully, it will be ready to ship by the time that school time hits. I've found a few weird things, but there's just a lot of stuff to test and use day-to-day. I had plenty of chance to break things in this weekend. How?

I spent Friday night in a daze, just playing around with unzip, curious if there is a way to create self-extracting zip files in Haiku and Linux. It turns out that it is. Literally it is just a matter of tacking on a zipfile to the end of an stub program which more or less runs unzip on itself. This led to a realization that hit me like a lightning bolt while I lay in bed early yesterday morning. For a while I've had code that I wrote for a packaging system for BeOS / Zeta / Haiku sitting on my hard drive, collecting proverbial dust because I couldn't figure out the best way to store the files. It was a large percentage of the way to completion, too. This connection put me into coding overdrive yesterday and I spent a generous amount of time on it tonight, too. The result? PSfx. Of course, this isn't news if you subscribe to the checkin RSS feed for Paladin. Natch.

PSfx is a package building app which works very much like the PackageBuilder app which is bundled in the BeOS 5 Development Tools. The difference is that, when finished, it will work *much* better than PackageBuilder and won't require any extra tools. The new format uses ZIP compression leading to smaller file sizes than the equivalent for SoftwareValet packages. Like Paladin, it has a scripting-friendly command line interface, perfect for integrating into other build systems or hacking together a quick shell script to automate the building and packaging of a project. The build scripts that it uses are a similar format to the Paladin project files, which makes them friendly toward source control and also easy to read and write even with just a regular text editor. Also, even though the executables will run only on certain OSes, it will be possible to build, say, a Haiku GCC4 package from my Zeta install.

All of this is not to say that it's finished, however. While the install engine and command-line interface are mostly finished, the GUI still needs more work. There are some bugs I need to fix and some other miscellaneous stuff needs done. While PSfx certainly won't be ready for the Paladin 1.3 release, Paladin's next release, in theory, will use this new install system. While these self-extracting packages probably won't be as elegant a solution as what the other Haiku developers will be coming up with at the proper time, it sure beats waiting a few more years for decent software distribution tools.

August 8, 2010

I spent a great deal of time today doing more hacking on Paladin, a trend I've had the last week or so when I wasn't working on getting my book out the door. The Code Library feature, for now, has been withdrawn until I can get it working well, which it just doesn't right now -- everything works the right way except for synchronization, which is the entire point behind the feature. The code for it is still there, but it won't be enabled for the next release. I fixed several really annoying bugs, including workarounds for two bugs in Haiku which took a lot of effort to find but were trivial to work around once found. One of them is project files being mistakenly identified as plain text files.

Source control is the star feature for the next release. I intend to make it about as easy as possible to integrate source control into a developer's workflow as possible. It took me a long time to really "get it," but now that I do, I want others to have an easy time using it without having to learn command line syntax until they're ready to do so. The only thing that I currently have on the to-do list before the release is to polish and test the different ways that source control is used. Once that's done, I'll be putting out a release. I really love this project -- the rewards are incredibly satisfying. :)

July 28, 2010

First of all, thank a lot for your generous donations! It was really stunning to see how much money could be raised in such a short time. And since it's been some time since my last commit, I thought it would be a good idea to report what I'm currently up to. But first, let's have a look at what I did last week for the most part:

• I started to fix some annoying bugs in the FreeBSD compatibility layer. Now it's possible to unload the networking stack completely again, and the "callout" implementation should provide more accurate timing. Oh, and booting over the network didn't work either anymore with FreeBSD drivers. Originally, I wanted to find out why Haiku would instantly reboot on one of my machines, but the problem mysteriously vanished once I started looking into it.
• Next on the list were some minor bugs, mostly having to do with routing, some could crash the system, others would just render your network unaccessible. Most of those bugs were reported by Atis Elsts, one of our current GSoC students that works on implementing IPv6. I've recently committed his work in progress to our repository in order to ease reviewing his patches, and give what he has done so far a bit more exposure.
• Then I started to integrate the ICMP patches that two former students (Ivo Vachkov GSoC 2007, and Yin Qiu HCD 2008) produced by pretty much rewriting it. Looking back, it was not well spent money: neither student joined the project, nor was the quality of their work really acceptable. It took me 3 days to rework it, and it still has some issues like introducing an IPv4 specific error mechanism to the protocol agnostic stack. I doubt it would have taken much more time to write it from scratch. I will continue to work on this later, though, and address its remaining shortcomings. The current state is that we can produce ICMP error messages (and will in most appropriate places), and also forward those errors to userland applications. For example, if you send a UDP packet (through a connected socket) to a port that is not served, the server will answer with an ICMP port unreachable error (even if that server would be Haiku), and your application would retrieve the appropriate error code from its next socket interaction.

Since the last three days, I'm working on changing some stack internals that caused a bit more work than I originally anticipated: the network stack that is currently in Haiku only allows a single address per interface. This is something that was quite okay with IPv4, but starts to be problematic with the adoption of IPv6, since it's common there for an interface to have more than a single address (this feature is also requested by the RFCs that cover it). Originally, I had thought that simple aliasing of interfaces would do it (the plan was that several interfaces could use the same driver, but had different names that would only be joined for displaying them through ipconfig), but even though other systems seem to actually do that, it's quite a limited approach. Besides, the network stack support for this was utterly broken. That's probably what you get when you don't consider a feature important.

Now that I learned that aliasing the way it was planned and implemented won't do it, and since Atis would welcome the ability to have several addresses per interface, as this would ease (or rather, due to the brokenness of the current solution, make possible) implementing Neighbor Discovery for IPv6 (a.k.a. NDP, see RFC 4861), I thought it would be a good idea to spend my contract time to implement this.

The rest of this blog entry will detail the technical details of this, so if you're not interested in those, feel free to skip the rest.

Each net_interface can now have any number of net_interface_address items, each of which stores a local interface address, as well as its network mask, and broadcast address (if any). Therefore, a net_buffer, and a net_route can no longer point directly to the net_interface. Instead, they now have a pointer to the net_interface_address structure which also features the pointers to its net_interface, as well to its net_domain so that no information is lost. The net_protocols (the transport, and network layer in OSI speech) were therefore very easy to port to the new architecture, besides the little annoyance that the datalink layer can no longer figure out the interface address a buffer belongs to.

The meaty bits were hidden in the data link layer, and the stack internals. Before, the net_datalink_protocols were instantiated for each interface. Since an interface had one address, and one specific domain (like IPv4), this worked out nicely. However, now, an interface is domain agnostic, so this nice and simple model was not adequate anymore. Furthermore, modules like ARP have to know and maintain the local addresses of the interfaces so that they can be used for outgoing ARP requests, and replies. This requires a more flexible approach, and the net_datalink_protocols are now instantiated per domain per interface. That means, whenever the first address of a specific domain is added to an interface, the protocol chain is created, and attached to the interface for that domain only. I've currently implemented this with a simple array lookup per interface, but it will do the job. I've also taken the opportunity to slightly introduce a bit more C++ into the stack internals, there is now an Interface class that takes over the private parts of a net_interface. I've also changed interfaces, and their addresses to a reference count based solution, which was still on my TODO list from when I originally implemented the stack. Furthermore, the datalink module needed a number of new methods in order to give the other layers enough information to deal with the new situation.

The next problem was the ioctl interface that is used to configure the stack. With more than a single address per interface, it's no longer adequate. In FreeBSD, for example, there is no direct way to iterate over the addresses of an interface due to this. You can collect the information by looking at the routing table, though, and that's what each application interested in this data has to do (luckily, they provide a non-POSIX extension getifaddrs() that does the job for you). I haven't decided yet what I will do in Haiku, but I guess I will add some dedicated ioctls for this issue.

I'm still kind of in the middle of the changes, but I hope that I can start to commit the first bits later today, or tomorrow. Likely, those commits will break the network stack, Haiku in general, and introduce severe regressions. I will then start looking into WPA, and see if I can make enough time to apply for the WiFi bounty at Haikuware, leaving the regressions in place to prepare for my future contracts. You know the deal :-)

Once I'm done with the current rework (currently I need to adapt the routing code to the other changes), I would continue completing the error mechanism, and introduce a nice C++ API to access the stack internals in order to hide the ioctl interface to those that really want it. I will probably do the latter only after having had a look at WPA, though, since that might bring further API needs to the table.

July 27, 2010

The book is finally done! Getting through the proof copy took *so* much longer than I ever expected. Luckily, right now I'm out of town with a lot more time on my hands, so I had a lot more time to be able to sit down and get through it. It has been published through Lulu.com so that a great deal more of the profit from the book goes to me instead of the pockets of a book retailer. Here is the link to the book and e-book.

Learning to Program with Haiku at Lulu.com

The regular price is $25 USD, but as part of the launch of the book, it is on sale for 15% off the regular price through August 15 when you use the coupon code BEACHREAD305 at Lulu. It will also be available through online book retailers like Amazon.com, Barnes and Noble, and others, but it will be a couple of months before it appears on those sites.

July 22, 2010

I wish that when I started the project for Paladin over at Sourceforge that I had been able to choose Subversion for source control using the client for Zeta. Because of an outdated client, I was forced to use CVS. While CVS is (barely) adequate for legacy work, anyone who knows the importance of source control knows better than to use it when far better tools exist. Subversion is CVS done right, but it certainly isn't perfect, either.

Distributed source control tools are the current fashion, it seems, and rightly so. After a lengthy discussion of Mercurial vs git which to choose over Subversion, I decided to do some looking into both of them. It's another one of those Coke vs Pepsi, KDE vs GNOME kind of controversies. Long story short: I haven't looked into git very much, but I've learned enough about Mercurial to say that I like it a lot.

Just a few moments ago I checked in the current development snapshot to Paladin's new Mercurial tree. It's official: I'm no longer using Zeta for development. I am still supporting source compatibility for the platform, but now my focus for Paladin is solely Haiku. This change in perspective will bring in some features not possible for R5 or Zeta.

One new feature for Paladin 1.3 is integrated source control on a basic level. The inspiration comes from The Joel Test: 12 Steps to Better Code. One of the steps is using source control -- yes, even CVS. In all the years that I've been flinging C++, I never used source control locally. I didn't see the point in doing so locally and didn't think all that much about source control to begin with. I didn't want to put in the effort to learn more, either. Lazy developer, I know. git and Mercurial make it foolish to not use it. It's a different workflow, but only slightly.

Paladin's integrated source control will be simple and about as unobtrusive as possible. It creates a repository when you make a new project. Click a menu item or press a shortcut on the keyboard, type in the check in message, and it will check in your work locally. Click another menu item and it will push your changes to another repository somewhere. It's about as painless as it can get. Mess something up? Revert to the last known good revision. You will be able to even choose from Mercurial, git, and Subversion for your work. Only the basics will be covered in 1.3 to avoid pushing the release off too much. Gotta get back to hacking. TTFN

July 15, 2010

Six more icons have been added to the HBBI collection:

Downloadable from BeBits and Haikuware.

July 13, 2010

Those of us who run Haiku under a multicore machine can finally breathe a sigh of relief. For about as long as I can remember -- probably as long as it's had multithreaded builds -- Paladin has suffered from problems with locking up under Haiku. There never was a problem with it when I was developing Paladin from within R5 or Zeta, though.

July 10, 2010

Operating systems are funny things. They take FOREVER to develop, for example, and I don't just mean Haiku. Look at the development time for Vista. It took a multi-billion dollar corporation for than five years to write the upgrades for XP.

There's also a chicken-and-egg problem that fledgeling OSes have: how to get an OS without applications and how to get applications without an OS. Luckily for Haiku, a lot of that problem has been mitigated by BeOS' startup history. The QT4 port just saw a 4.7 release. I'm really thankful for the efforts of those guys. Other people like Michael de Vincius Oliviera and the HaikuPorts team have been hacking away at porting stuff from other platforms. While they certainly don't have all of the BeOS goodness of a native app, at least we have some of these apps and games. KOffice takes a team of dedicated developers that is IIRC larger than our OS team alone. We're really starting to get a lot of useful apps.

Stability has always been my sticking point for coding under Haiku, but at least in my experience of late, Haiku's been pretty stable, all things considered. I'm typing this from a GCC4 hybrid build that I installed from sources. So far Paladin hasn't been plagued by deadlocks like it has been in the past, which has led me to believe that it was never Paladin's problem in the first place, but the jury's still out on that one. I'm even working on more features that will only work under Haiku and fixes for the platform, like using rsync to properly synchronize modules for the code library. In the last couple of days I worked with a couple guys on the team to nail down a bug in Terminal which was preventing Paladin from running applications in the debugger. After patching both Paladin and Terminal, it works beautifully now.

Feature-wise, Haiku is even now doing an admirable job of playing catch-up. People in the past have mentioned that R2 would be the release where Haiku would implement all the features that BeOS was missing that all the other OSes have, but more and more I don't think it'll take that long. OpenGL stuff might, but the Google Summer of Code has been good for that. There have been other people who couldn't wait that long for stuff like WiFi, so even now that partially works. Simple amazing, if you ask me. Then again, even though it's been slow, Haiku's progress from the outset has been that way, too.

July 8, 2010

After about a week of what felt like futzing around with my book, Learning to Program with Haiku is just about published. I ordered the proof copy this morning, so in about a week I'll have a hard copy of my work, and barring major problems, it will be available for the general public, both in dead tree format and as an e-book. I'm really excited!

June 30, 2010

For those who didn't know, I've been finally getting around to cleaning up PalEdit, Paladin's text editor. It is based on Pe and in its current publicly-available state, isn't all that different from Pe. I'm in the process of fixing that. On the surface Pe is a great all-purpose text editor. I'm not that fond of it personally just because I only write code in C++ under Zeta and Haiku with rare stints into Python land under Ubuntu.

June 26, 2010

This lesson finishes up the project that the last two have been about: HaikuFortune, a program which randomly chooses and displays a fortune in a window. It's not a very complicated one, but it exemplifies a reasonably well-coded real-world project. Although it was code complete as of the end of Lesson 22, it was not finished, missing icons and other resources. This concludes the project with adding resources, a basic discussion on source code licensing, and packaging a program for Haiku.

June 22, 2010

Usability is one of my pet topics. Although less so now that in years past, it is all-too-often ignored or not given enough priority. This lesson scratches the surface from a developer's point of view. I'm no usability expert, but I do know a thing or two. This lesson is a must-read for any budding developer, and by the end of it, we will have a good real-world program to show off which is just shy of being ready for a release.

June 14, 2010

This lesson continues with delving into the Storage Kit, reading and writing files. We also start writing code for the final project of the Learning to Program With Haiku series which will be developed over the course of several lessons.

June 11, 2010

I just won Haikuware's 17th along with Pier Luigi Fiorini for my work on Paladin and all of the programming lessons that I've been publishing. My Haiku golf shirt came yesterday and it looks really nice. I didn't start either one to achieve any recognition, but it's really nice to be appreciated. Thanks everyone!

June 6, 2010

June 5, 2010

Moving on from exploring the Interface Kit, we turn our attention to the Storage Kit in this lesson. We take a look at the kit from a broad perspective and also begin using some of its many of the classes. We take a break from writing GUI applications and, instead, write a console directory-listing program using C++.

June 1, 2010

Ten years ago when I first started to learn to write code using BeOS, I had a lot of questions that I couldn't any documentation to give me the answers. Luckily, there was the Be Code Talk mailing list and kindhearted members of the community, like David Sowsy (Animaxo, Vesa Accepted). Resources are one of those things that eluded me. Eventually I figured them out, but Lesson 19 lays some of it out in plain conversation.

May 25, 2010

All over my floor.... or something like that. I spent most of the weekend ripping apart and putting back together pieces of PalEdit in a separate folder -- code that hasn't made it into the tree yet. Yesterday afternoon I had successfully refactored the code for the text editing view. It's possible to type and delete text, but that's about it -- even little things like the arrow keys don't work yet. Syntax highlighting is disabled for the moment, too. That's OK, though. Those features will get their turn, too. The big accomplishment is that I'm pretty sure that the hardest part is over: reducing dependencies until all I have left is a BView which I can type code into. This will enable all sorts of nice things like the possibility of a tabbed interface, properly-implemented split views, and more. I'm getting a better handle on how most of the code works, too, so I *might* be able to implement my #1 most wanted feature: code completion. We'll see. :)

May 24, 2010

We're starting to get closer to the end of this Learning to Program series. After toying with menus and interface colors in the last lesson, we apply some of the concepts used with menus to get the hang of using list boxes and discover along the way a few bizarre sports that really exist. Games people play. Sheesh.

May 19, 2010