J-Space.dk

Spending the weekend with a laptop without the necessary Python distro and modules, I’ve kept myself at work with a console-based approach to the visitation project. The shell simulation still lies as an excellent basis and has no problems running as a small self-contained command vessel. Right now I’m taking a break whilst looking at different approaches to option parsing. I think I’ve mentioned earlier that the OptionParser module in Python suits very well in principle, but I’ve discovered several innate implementation choices that makes it a bad choice for direct inclusion. One of the primary difficulties is the fact that if a user passes bad parameters to the parse, it will alert the user directly of the error (a formatting issue related to the rest of the script) and exit Python execution (a massive error, as it should continue running internally, allowing the user to attempt another call without having to call the superscript once more).

I could make a subclass, but there are so many unknown variables I’m afraid of handling with it, that I might just as well make my own implementation, albeit far simpler in structure (not much is required, really).

Well, back to work. Coheed and Cambria running in the background. Not bad.

After messing around with MySQLdb for Python for a night and a half, trying to figure out what I was doing wrong since I couldn’t connect to the remote server, I started wondering why “‘localhost” worked while running the script on the remote server and “<server-ip>” didn’t. Well, hardly for me to know, but it seems the default configuration of MySQL on some systems restrict connections to local ones.

Imagine that.

With that fixed I’ve come upon a couple of IDE’s I’ll put to the test. A current conundrum is laziness. I’m not in the mood to sit down with squared paper and calculate the intricate details of a perfected GUI design. I like the notion of wxPython’s FlexGridSizer which I’ll mess around with. I haven’t found a proper GUI designer I could easily get into (wxGlade seems like a hassle to work with, the Python-specific IDE’s each use some annoyingly specific bindings and IronPython can’t directly imported C extension modules), so I’ll go with that for the time being. Well, either that or implement it entirely through the functioning console. This hurts my head as well, though. I’ve never made a full-blown text app, and I’m not liable to complete the CLI any time soon.

Work is progressing smoothly, money is being saved as I garner more achievements in old games (working up a few New Game plus saves in Mass Effect, finishing off the last in Mirror’s Edge, Arkham Asylum and Fallout 3), and everything is just… so smooth.

Except for an annoying case of sinusitis. Then again, of all the bitter things that could hit me, I’ll take this as a blessing

Take care.

~T

Learned about Python decorators today. Now my head hurts.

Seemed for a while I had finally found a programming language that wasn’t capable of blowing my cranial arteries, sending my neurons to a screeching halt all the while the very fabric of my soul attempted to escape the now-ravaged innards of my mind. Then decorators come along. So far I’ve come to the conclusion that they’re either overrated, unnecessary or meant for a train of thought not even Daedalus would attempt to achieve. In all cases I hope they aren’t what I’ll be needing when dynamically introducing new commands to fakeCLI (with the current design, this should not be the case).

Good news, as well. After fighting against Trac for about a fortnight I’ve stumbled upon the holy grail of my desires. Fossil. It contains exactly what I need (versioning, Wiki, tickets), with the amount of trouble I can handle (compile, install, host) and the perfect amount of targeted users (less than a shitload). Perfect. It should be running on this host, http://www.j-space.dk:8080/, right now. I’ve solved the issues I had with a proper system here, I think. I’ll still need to streamline local cloning and syncing, but that’s a non-issue, I’m sure.

Anyway, Boondock Saints running in repeat, Tellus/T-Chip crashing. Have a good one.

I’ve been hung up on work the past few days – or rather, I’ve been out of town and my netbook’s busted so the only Linux box I’ve had on hand was my iPhone (and I hate typing code on the small keyboard).

I’ve been thinking about how to implement an extensible model for calling applications. The design is painfully simple for Python (the called file in the virtual file system contains a function reference that gets called – done, and the proggy will have some form of access to the underlying virtual system), but I’d like to make a few considerations as to how to implement this further on a more flashier platform – say for example SDL (C/C++) or GameStudio (C#/VB.NET). The references to functions aren’t as straight forward, and to some degree the called functions must have something they can refer to or make callbacks at to make sure they have an outlet for output.

Anyway, just a few random thoughts while gaming E.V.O. on a SNES emulator for the PSP, reading Bearing an Hourglass.