With the more urgent "it doesn't work with blah" stuff mostly solved now, one of the big remaining issues is around error clarity and excessive magic.

For example, some random author that is trying to checkout a Catalyst project needs:

1. To have Module::Install installed.
2. To have Module::Install::Catalyst installed.

In the case of the former, you get the semi-cryptic but at least standard "Can't find inc/Module/Install.pm in @INC" message, so the error is resolvable.

But in the latter case, you're likely to get something like "Unknown command 'catalyst_ignore'", with no real obvious resolution mechanism.

I think this idea of automatic plugin discovery is starting to hit it's limits in terms of clarity.

And so I'd like to do something counter to my natural instincts here, and make M:I more verbose.

I'm thinking of something like the following for explicitly declaring the use of a non-core Module::Install extension.

use inc::Module::Install qw{ Catalyst XSUtil };

This would both allow M:I to error with a much more meaningful error when you don't have a plugin, and also prevent the loading of unused plugins which should prevent accidental plugin collisions (some of which I've seen occurring in the CPAN Testers machines).

Thoughts?

The app can be found in its project page here.

Please comments, forks, jokes, donations or awards welcome!

#!/usr/bin/env python3
 
class Egg:
 
    _next_id = 1
 
    def __init__(self):
        self.id = self._next_id
        self._next_id += 1
        assert Egg._next_id is self._next_id
 
 
if __name__ == '__main__':
    f = Egg()

Fails the assertion. It’s decomposing the assignment-update into its constituent tmp = self._next_id + 1; self._next_id = tmp components, but a programmer could reasonably expect a Lookup/Update hash map ADT operation to occur instead — get the slot by lookup, mutate the value found, and store back in an atomic sense, clobbering the class member with the updated value — but that’s not how it works.

This goes with the prototypal territory:

function Egg() {
    this.id = this.next_id;
    this.next_id += 1;
    assertEq(this.next_id, Egg.prototype.next_id);
}
 
Egg.prototype.next_id = 1;
var e = new Egg(); // Error: Assertion failed: got 2, expected 1

Fortunately, note that this behavior definitely has the semantics you want when you add inheritance to the mix. Is the self.viscosity that this class implementation is referring to a class member or an instance member in the base class?

#!/usr/bin/env python3
 
import sauce
 
class AwesomeSauce(sauce.Sauce):
 
    def __init__(self):
        super().__init__()
        self.viscosity += 12 # Deca-viscoses per milliliter.

The answer is that you don’t care — it’s being rebound on the AwesomeSauce instance no matter what.

Moral of the story is to be mindful when using update operations on class members — if you want to rebind a class member within an instance method, you’ve got to use the class name instead of self.

Read more...

1. Cleaning up the bugs.
   - Fix the incorrect menu related message that appears in the top telnet window shown in the screenshot.
   - When a player quits the game, the display of other observing players does not update to reflect it.
   - When an object moves, observing players are defined as those who have visited the tile the object moved to and currently have it on their display. Instead only observing players who have the object in their field of vision should see the movement.
2. Polish the field of vision support.
   - The tiles that are in the field of vision should be distinct from those that are not (Smart Kobold uses this approach to good effect).
3. Widen the corridors so players can pass each other.
4. Add entities controlled by AI that move around of their own volition.

if y in self.drawRangesNew:
    minX, maxX = self.drawRangesNew[y]
    if x >= minX or x = maxX:
        return True

1. Clean up the FoV emphasis to be row-based, rather than tile-based.
2. Add some objects and entities to the world, that can be interacted with. Entities should move to add life to the world.

1. Add bursts of fire, using different tiles and colours to make use of a wide range of colours than the basic eight through dithering. It might be a good idea to write the tile/colour choosing logic in a way that can optionally use the xterm 256 colour mode, if the client can be detected as supporting it.
2. Add option for NPCs to choose to attack, rather than move, when they are ticked.
3. Add option for players to attack, rather than move.
4. At the moment, player keypresses are executed as they come in from the client. They should instead be queued and executed at a fixed rate.

Ran into a bug yesterday, where http://pecl.php.net/uuid in combination with http://pecl.php.net/imagick yielded a segfault when using uuid_create(). GDB backtrace looks like this (without the exact place where it happens in libuuid, as there is unfortunatly no libuuid1-dbg-package in current Ubuntu versions):

gdb --silent --ex run --args php -r "var_dump(uuid_create());"
#0  0xb6e85321 in ?? () from /lib/libuuid.so.1
#1  0xb6e862bf in uuid_generate () from /lib/libuuid.so.1
#2  0xb6bcc67a in zif_uuid_create (ht=0, return_value=0xbffff1e8, return_value_ptr=0x0, this_ptr=0x0, return_value_used=1) at /usr/src/pecl-uuid-trunk/uuid.c:182
#3  0x0835d26a in zend_do_fcall_common_helper_SPEC (execute_data=0x894ed4c) at /build/buildd/php5-5.3.2/Zend/zend_vm_execute.h:313
#4  0x08333d8e in execute (op_array=0x891c464) at /build/buildd/php5-5.3.2/Zend/zend_vm_execute.h:104
#5  0x082fe283 in zend_eval_stringl (str=0xbffff998 "var_dump(uuid_create());", str_len=24, retval_ptr=0x0, string_name=0x871f2fc "Command line code")
    at /build/buildd/php5-5.3.2/Zend/zend_execute_API.c:1172
#6  0x082fe422 in zend_eval_stringl_ex (str=0xbffff998 "var_dump(uuid_create());", str_len=24, retval_ptr=0x0, string_name=0x871f2fc "Command line code", handle_exceptions=1)
    at /build/buildd/php5-5.3.2/Zend/zend_execute_API.c:1214
#7  0x082fe4a3 in zend_eval_string_ex (str=0xbffff998 "var_dump(uuid_create());", retval_ptr=0x0, string_name=0x871f2fc "Command line code", handle_exceptions=1)
    at /build/buildd/php5-5.3.2/Zend/zend_execute_API.c:1225
#8  0x083a0579 in main (argc=3, argv=0xbffff854) at /build/buildd/php5-5.3.2/sapi/cli/php_cli.c:1235

The interesting thing is, the crash happens in libuuid, but only if imagick is enabled. Let’s see what Valgrind says:

valgrind -q  php -r "var_dump(uuid_create());"
==25103== Invalid write of size 2
==25103==    at 0x5517321: ??? (in /lib/libuuid.so.1.3.0)
==25103==    by 0x55182BE: uuid_generate (in /lib/libuuid.so.1.3.0)
==25103==    by 0x57D0679: zif_uuid_create (uuid.c:182)
==25103==    by 0x835D269: zend_do_fcall_common_helper_SPEC (in /usr/bin/php5)
==25103==    by 0x8333D8D: execute (/build/buildd/php5-5.3.2/Zend/zend_vm_execute.h:104)
==25103==    by 0x82FE282: zend_eval_stringl (/build/buildd/php5-5.3.2/Zend/zend_execute_API.c:1172)
==25103==    by 0x82FE421: zend_eval_stringl_ex (/build/buildd/php5-5.3.2/Zend/zend_execute_API.c:1214)
==25103==    by 0x82FE4A2: zend_eval_string_ex (/build/buildd/php5-5.3.2/Zend/zend_execute_API.c:1225)
==25103==    by 0x83A0578: main (/build/buildd/php5-5.3.2/sapi/cli/php_cli.c:1235)
==25103==  Address 0x30 is not stack'd, malloc'd or (recently) free'd
==25103== 
==25103== 
==25103== Process terminating with default action of signal 11 (SIGSEGV)
==25103==  Access not within mapped region at address 0x30
==25103==    at 0x5517321: ??? (in /lib/libuuid.so.1.3.0)
==25103==    by 0x55182BE: uuid_generate (in /lib/libuuid.so.1.3.0)
==25103==    by 0x57D0679: zif_uuid_create (uuid.c:182)
==25103==    by 0x835D269: zend_do_fcall_common_helper_SPEC (in /usr/bin/php5)
==25103==    by 0x8333D8D: execute (/build/buildd/php5-5.3.2/Zend/zend_vm_execute.h:104)
==25103==    by 0x82FE282: zend_eval_stringl (/build/buildd/php5-5.3.2/Zend/zend_execute_API.c:1172)
==25103==    by 0x82FE421: zend_eval_stringl_ex (/build/buildd/php5-5.3.2/Zend/zend_execute_API.c:1214)
==25103==    by 0x82FE4A2: zend_eval_string_ex (/build/buildd/php5-5.3.2/Zend/zend_execute_API.c:1225)
==25103==    by 0x83A0578: main (/build/buildd/php5-5.3.2/sapi/cli/php_cli.c:1235)
==25103==  If you believe this happened as a result of a stack
==25103==  overflow in your program's main thread (unlikely but
==25103==  possible), you can try to increase the size of the
==25103==  main thread stack using the --main-stacksize= flag.
==25103==  The main thread stack size used in this run was 8388608.
Segmentation fault

Not really any more helpful. After two hours debugging the issue with the help of Mikko and Pierre we found out, that pecl/imagick is linked against libuuid too:

ldd /usr/lib/php5/20090626+lfs/imagick.so
    (...)
    libuuid.so.1 => /lib/libuuid.so.1 (0xb7086000)
    (...)

For whatever reason this is happening, this is most likely the root cause of the issue.

Solution (sort of)

pecl/uuid was loaded by /etc/php5/conf.d/uuid.ini and pecl/imagick by /etc/php5/conf.d/imagick.ini. As they are loaded in there alphabetical order, imagick initialized before uuid. Renaming /etc/php5/conf.d/uuid.ini to /etc/php5/conf.d/00-uuid.ini fixed the issue, as uuid is than initialized before imagick and the segmentation fault was gone.

Not sure about that, but maybe it would be a good idea to check in PHP_MINIT(uuid) in pecl/uuid if pecl/imagick has been initialized before and warn the user about it?

The problem is that Windows doesn't know how to make tar files that look native on Unix: the permission bits aren't right, they come out as 0700:

drwx------ batcheln/100      0 2010-08-21 14:13 coverage-3.4b1/
-rwx------ batcheln/100    516 2010-08-08 09:36 coverage-3.4b1/AUTHORS.txt
...

The tar command let me set the mode bits in a command-line switch, which means I could set them in an environment variable, but that would make all the files have the same permission bits, and directories and files should be different.

To fix this problem, I wrote a distutils extension command. It turned out to be not difficult, distutils has good extensibility.

To make a new command, create a new package directory somewhere, I called my "distcmd". To make a command called "fixtar", you you derive a class from distutils.core.Command, name it fixtar, and put it in a file called fixtar.py. You have to provide three methods:

from distutils.core import Command
import shutil, tarfile

class fixtar(Command):
    """A new setup.py command to fix tar file permissions."""

    description = "Re-pack the tar file to have correct permissions."

    user_options = []

    def initialize_options(self):
        """Required by Command, even though I have nothing to add."""
        pass

    def finalize_options(self):
        """Required by Command, even though I have nothing to add."""
        pass

    def run(self):
        """The body of the command."""
        # Put something useful here!

The initialize_options and finalize_options methods are required. It's too bad distutils didn't allow them to be omitted in cases like mine where there are no options to specify. The run() method is the interesting one, that's where all the work will happen. In mine, I read the tar file distutils made, and I create a new tar file just like it, but with the permissions and owner info that I want:

    def run(self):
        """The body of the command."""
        for _, _, filename in self.distribution.dist_files:
            if filename.endswith(".tar.gz"):
                self.repack_tar(filename, "temp.tar.gz")
                shutil.move("temp.tar.gz", filename)

    def repack_tar(self, infilename, outfilename):
        """Re-pack `infilename` as `outfilename`.

        Permissions and owners are set the way we like them.

        """
        itar = tarfile.open(infilename, "r:gz")
        otar = tarfile.open(outfilename, "w:gz")
        for itarinfo in itar:
            otarinfo = otar.gettarinfo(itarinfo.name)
            if itarinfo.isfile():
                otarinfo.mode = 0644
            else:
                otarinfo.mode = 0755
            otarinfo.uid = 100
            otarinfo.gid = 100
            otarinfo.uname = "ned"
            otarinfo.gname = "coverage"
            otar.addfile(otarinfo, itar.extractfile(itarinfo))
        itar.close()
        otar.close()

To invoke my new command, I have to tell setup.py to pull it in with the --command-packages=distcmd switch. Then I can simply use "fixtar" as a command on the line just like any other:

python setup.py --command-packages=distcmd sdist --keep-temp --formats=gztar fixtar

Now I get a tar file that looks right:

drwxr-xr-x ned/coverage      0 2010-09-04 19:44 coverage-3.4b2/
-rw-r--r-- ned/coverage    516 2010-08-08 09:36 coverage-3.4b2/AUTHORS.txt
...

There's a bit more complication to it, because of the --keep-temp switch that I needed to keep the original tarred files around so they could be re-tarred. The real fixtar.py also cleans up that directory.

This was more than I wanted to do to get the right permissions in a tar file, but it was a chance to see how distutils extensions work, and it lets me make all my kits in one place.