Bruce (kor27) wrote,
Bruce
kor27

All Nighter

Last night, I did, eventually, make it to an OfficeMax, and got all of my needed supplies - not to mention turning in an old toner cartridge. It's only a $3 refund, but it gets rid of the cartridge.

That was around 8:00pm. I then decided on TGIFriday's for my nutritional needs (I hadn't eaten in over 15 hours, and was starting to feel a teensy bit woozy), and hung out there until nearly 11:00pm.

Then home, where I decided to do just a little bit of coding towards making a net-independent song search on the karaoke box.

After all, I'm not sure Saturday's gig will have wireless, and it would be nice to have a local and more comprehensive search, anyway.

I just set myself a simple task, really - upgrade all components (MySQL, Python, Python-MySQL, etc) to the latest versions, and then check out - and verify - how to access the database from a Python script.

Among other things, I managed to discover a little something about at least the XP installation of MySQL. Its crash recovery makes it crash.

I started with the simple thought of uninstalling both it and all Python pieces, then reinstalling the new ones - make a clean slate of it. The problem being that I didn't initially stop the MySQL service - I just uninstalled, downloaded the latest version, and installed that. And the uninstall doesn't get rid of all files. Specifically, it doesn't get rid of the InnoDB logfiles and data file, which if I understand correctly, are there to save transaction records across a crash.

They got corrupted in the process. In fact, they got corrupted later when I was forced to "reinstall" MySQL in order to turn TCP access on. I suspect they may get corrupted if I look at them too long. And if they're corrupted, InnoDB has a fainting fit, and the MySQL server won't start.

That consumed a couple of hours. And doesn't make me feel too good about MySQL crash recovery, either.

Then there was the whole TCP/named pipe bit. The default connection to a MySQL server is through the network, at a specified port. Perfectly reasonable, since in most cases, one has a large database on a network, and a cloud of clients performing operations on it.

I don't. I only need to process operations "in-box," and my database, at 12,000 records, is somewhere between tiny and small.

The MySQL installation process allows one to disable TCP access, which isn't a bad idea for a box that sits in various network environments, not all of them friendly. In that case, on an NT-based system, all access is through a named pipe. Not a completely portable solution, but whatever.

The Python MySQL package, MySQLdb, allows one to add a named pipe argument to a connection request, for just that purpose.

Which is cool, except it doesn't work. I still need to go and put in a bug report, but apparently, somewhere in the depths of the interface between the Python and compiled C wrapper part of the package, it expects the named_pipe argument to be an integer.

All I knew was that I'd get a "TypeError: an integer is required" message that pointed to a completely obscure line of code. No indication what, out of quite a number of arguments, actually needed to be an integer.

That took a few hours, too. In fact, I eventually figured it out using the "If I were a Unix snob testing a package, what would I neglect to test?" method. So I turned MySQL TCP access back on, rebooted, sighed, deleted the InnoDB files, restarted MySQL, and tried the connection through TCP. And lo, it worked without error.

Then I started playing around with actually doing stuff. Part of this burst of energy stems from figuring out, the other day, how I can do a reasonable song number based search - something I'm missing right now. It's kind of important, for a number of reasons - not the least being that I should have some ability, when I get a slip, to do a quick crosscheck that the number matches the song.

I used to do that by checking discs as I pulled them. I could, of course, still do that, but it would be just a bit counterproductive...

But I now have some core code for just that purpose. It still needs a fair amount of work, but I can access the database, and both search and manipulate the data. That's most of the job right there.

So I was up until about 10:00am, either pounding my head against a wall, or making just one more change.

In fact, it took an effort of will to stop and drag myself to bed. For which I should be happy, since it means that at least I've had five hours of sleep.

Gods, that was fun. I really can't say why, but coding, testing, fighting against a wall - especially, but not necessarily, if you get to break through it - gives me an odd kind of pleasure. I suspect something similar to electrichobbit's relationship with math, if perhaps less intense.

Anyway. Time to get clean, and get to the Hamptons.
Subscribe

  • A Few

    I have just a few new songs, mostly requests that finally got made. The track count is now 23,973, and the unique song count is 17,595.

  • The Latest Dribble

    There's a show tonight, so I thought I'd list the recent additions, which includes a few requests that became available during the hiatus. The…

  • Some More

    Just a few new songs. Some requests, a couple that looked interesting. The track count is up to 23,952 and the unique song count is now 17,574.

  • Post a new comment

    Error

    default userpic

    Your IP address will be recorded 

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.
  • 5 comments