Recursiveness

En route from Ottawa to Montreal, I spent about 20 minutes working on a Java assignment. Usually these assignments are quite boring, and this one was no exception. The basic assignment is to create a class that represents a single variable polynomial of given degree. Anyways, the polynomial needed a function to evaluate it for a given value, and eventually I coded up this:

    private double evalCoeff(int deg, double x)
    {
        if (deg == this.getDegree())
            return this.coefficients[deg];

        return evalCoeff(deg + 1, x) * x + this.coefficients[deg];
    }

    /**
     * Evaluate the polynomial for a given x value.
     *
     * @param x         The value.
     * @returns         The evaulated value.
     */
    public double evaluate(double x)
    {
        // Very, very slick.
        return evalCoeff(0, x);
    }

Isn’t that beautiful recursiveness? 🙂

I Love Python

I really love Python. I mean, it’s as slick and clean as programming languages come, and both easy to learn and powerful.

Pythons libraries are often rather pathetic next to the language itself. For example, I ran into a problem when working on this weblog which it seems should have come up earlier: reading an XML file using xml.dom.pulldom does not create DOM CDATA sections, but rather text sections which happen to have the right data in them. This is great until you go to write the XML file, and it writes it as text and doesn’t include it as a CDATA section, thereby loosing the original content. Oops.

Well, I worked around this by using my own SAX handler to create a DOM tree, which kind or randomly guesses at whether the text should be CDATA or just plain text, because that’s the best the SAX interface seems to let me do. … well, damn, ye olde deprecated xmllib let me do this right…

zeroconf MOO

Continuing yesterday’s zeroconf work, I began coding a browse function for the MOO server. So in addition to being able to advertise its open TCP ports with zeroconf service names, the MOO server is now capable of browsing for zeroconf services. The implementation from inside the MOO is similar to how listen() functions.

The zeroconf_browse() builtin function takes two arguments: an object representing what object will be ‘listening’ for browse finds, and an string which will be the name of the service. The given object has a verb zeroconf_browse_add called on it when a new service is located, with the arguments {server's name, server's address, TCP port}. zeroconf_browse_remove is called whenever a service drops off the network, but I haven’t yet hammered out details of what arguments will be given to it.

And finally, the zeroconf_unbrowse() function takes a service name and stops browsing for that service.

The browsing is all done asynchronously in the current implementation, and a hook has been put in the main server loop to allow this to occur. The current implementation of zeroconf is highly MacOS X specific, but it can be re-written or extended to support multiple operating systems, especially by embedding Apple’s mDNSResponder daemon inside the MOO server. I haven’t even touched this yet, though.

I started looking into a Mozilla bug, bug #63895, but after some smashing at it with a hammer, I decided that a more informed and subtle approach is needed. It may indeed be a significant amount of work to fix even. The code in nsCSSFrameConstructor is a bit too complex for me to sink into it enough to find out what the problem is, so I think I’ll just ignore it…

I’m considering adding a locking system of some kind to Growlmurrdurr so I could write selectively private entries… but I don’t know what the point of a weblog that people can’t read is. 😛

1 13 14 15