Moving

This is the 40th post. This is the last post here. I have moved.

http://tunginobi.spheredev.org/site/

This place sucks. It mangles up my code, the whitespace between paragraphs is screwed up 3/4 of the time, and the site doesn't automatically log me in. So long, I'll see you on the other side.

Git for the lazy

I just wrote a guide for git, for people who don't know what a distributed version control system is, and don't care.

git for the lazy

That will take you from zero to hero... well, zero to something, fast.

On the side, I also gave Mercurial a shot, since I wanted to use it for some *shudder* Windows development. From what I saw, it lacked the two things I liked about git:

1. Local, non-cloned repo "proper" branches (in progress though), and
2. an index cache/staging area (I heard it has something similar, but I haven't found it anywhere).

So when it came down to git and Cygwin versus Mercurial and Window's cmd.exe, the choice was somewhat one-sided.

If I'm mistaken about either of those features, and anybody wants to fill me in, you're welcome to comment. :)


::EDIT::

However, I do like Mercurial's local revision numbers. It probably works better for it than git though, since Mercurial's branches are essentially repository clones.

Non-blocking sockets and Linux

Hi.

I just got through mucking around with system calls under Linux to make the network subsystem of the Sphere RPG engine work. Very painful experience.

Anyway, I fixed it, almost totally rewrote it, and I noticed a few issues with the old code.

First, reuse of a port on a machine was a pain, because my listening ports weren't using SO_REUSEADDR (which can be set with setsockopt at the SOL_SOCKET level). By what I read online, ports relinquish themselves after about a minute. Not fun when you're debugging network apps.

It didn't help that somebody conveniently forgot to convert a port number to network byte order when packing the listening port into the address structure.

Then, there was an issue with sockets being blocking. The Sphere network API is meant to be asynchronous, so obviously that was a big problem. But it's what followed that really caused problems.

The routine for checking the state of a given socket wasn't working at all. The code wasn't terrible, it's just that it didn't do the job it advertised. You'd think it'd be simple: checking if a socket is connected or not.

What. The. Hell.

Sockets are fairly well documented, you can find a lot of info about them by entering even vaguely related terms into Google. Non-blocking sockets are a whole different ball game. It took me days of debugging and trawling through Google to find links that were even remotely helpful.

A guy who was looking at the same code had his father help with a stop-gap solution that worked under Mac OS X. Performing polling on the socket was a step on the right track. But sockets under Linux act a fair bit differently, or they must have, because the code he got didn't work for me in Linux.

I spent most of yesterday reading pages of returned event flags from the poll() system call in an effort to find out how to check if a socket was connected or not.

The solution? When a peer closes their end of a connection, your socket receives a POLLIN event. An attempt to read() or recv() will give you zero.

The link that changed it all: I was operating under the false assumption that a disconnecting peer would raise a POLLHUP or POLLERR signal. How wrong I was.

I also checked for -1 without errno == EAGAIN, since this is asynchronous sockets we're talking about. Tests seem to show that everything is working. It even works for that guy using Mac OS X.

I need some tea.

LispForum

I used to dip in and out of comp.lang.lisp all the time. Had it piped to my email account and everything. But that damn place is constantly the target of spammers, and even Google seems to lack the ability to filter it. So I gave up on it.

www.lispforum.com

This LispForum could give Common Lisp the web presence it needs. Plus it's one of the few Lisp sites that doesn't look like it comes out of the 1990s (yeah, even with its stock template design).

Gmail and aliases

Hooray for email. This is what just happened to me:

1. Received email from uni account.
2. Email was forwarded to my personal Gmail account.
3. I reply to email.
4. I discover that the reply address was the Gmail account, and not the uni account. Crap.

I was going to rant on about how retarded this was here, but I decided to do some digging instead. Surely somebody else online had this same problem. And surely enough, here it is:

"Reply from same address" enhancement requested

I already had "reply from same address" set, so I looked at the header of my received mail: lo and behold, an aliased domain.

facepalm.jpg

If your mail goes to something like:

bob@mail.ukelele.com

... and you get mail from an alias, like this:

bob@ukelele.com

... you're screwed. Until you figure out why the damn thing isn't working. Only took me half a year.

Firefox 3's file upload box

Rage. I feel it. I feel the rage.

My problem? Firefox 3's file upload box. What was once a text field for pasting in file paths, plus a button in case you wanted to browse, has changed into one big button. That's right: clicking on the file text field == button click.

First off, it's not a friggin' button. I click a text field, I expect text entry, which means all the stuff that comes with it: cutting, pasting, copying, deleting, modification, the works. No more uploading files with names so similar it's faster to just edit the file names, or tweak the paths.

Second, I can't paste files from my file manager into the box anymore. I'm forced to use the file dialog, which is still inadequate under Linux. I need thumbnails. I need them because my image file names are totally useless. They're useless because they're Unix time stamps. I have hundreds of these time stamped files, so I refuse to name them. Without useful file names they appear as tiny, useless icons under Firefox in Ubuntu, and as even more useless generic file icons with Firefox under Xubuntu. Which was fine so long as I could paste files in from my file manager. But I can't paste files in from the file manager when the text box acts like a button. Without the text box, I'm stuck with the crappy dialog instead. With no way around.

What compelled the developers to do this? Did they think that users wouldn't be able to click a button labeled "Upload"? After having clicked such buttons the whole time they've been on a computer? Did they just not care about people who are faster on the keyboard than they are on the mouse. I'd be real interested in the motivation behind this decision.

Ways to fix this design flaw also welcome, because the only remotely related thing I could find on Google about this was this guy's comments on Firefox Beta 3.

::UPDATE::

dscdood has found some pretty interesting links about this. Read the comments. Turns out this change has been the result of an issue that has been around for a long time.

I still think it's retarded though.

::DOUBLE UPDATE::

Oh, and if the path of your file is longer than the text display, good luck checking if it's right, because you can't select the text field and scroll left or right.

The spaces

After all these years, I got back to mucking around with GearHead and GearHead 2 again. Something that bugged me about those roguelikes was that the were developed on Windows: in itself, not a terrible thing.

But the problem is with the difference in the nature of the terminals versus Linux. Linux terminals are usually 80 columns by 24 rows. Windows uses 80 columns and 25 rows. That missing row causes Pascal's drawing routines to go loco-roco. Makes the games unplayable.

I wrote a shell script a while back to send terminal escape codes to resize the terminal under Linux to use 25 instead of 24 rows. I picked it up, and it still worked.

The problem is: spaces. My directories have spaces ZOMG!!1 There's a long explanation for that transgression, but long story short, I needed my home directory to be consistent.

I just spent the last hour or so updating that script to work, regardless of where the thing was launched from. Anybody who has attempted to get scripts into Linux desktop launchers will know what I'm talking about: those scripts are never launched from the right directory. Stacks of quoting and unquoting, remembering that single quotes don't allow variable substitution, and a bunch of other things.

Spaces are a pain.

Maybe I'll contribute the script back to the GearHead community once I've brought it up to quality standards. I made it this far, I may as well finish it.