Monday, April 25, 2016

Migration hell again. Here's what happened:

Converted a CharField into a ForeignKey field. I get errors from postgres saying the char can't be cast to an integer. Problem is, I didn't get this error on my development machine, only on the box I'm trying to deploy to. When I try to migrate backwards on my development machine so that I can tweak the migration, I get a similar error on the backward migration on a different column. One that was a ForeignKey field and is now a Char Field.

The fix for the backwards migration was to add two manual sql migrations. The first one to allow nulling fields, and the second to null the fields. Then there's no issue moving from a char field to a foreign key. This does mess with the null constraint. Hopefully that won't bite me.

Thursday, April 7, 2016

Django migrations and branching

I got myself in to django migration hell this week. Here's how.

Working on my main branch, then switched to a feature branch created by a co-worker (we'll call him Barnaby). The feature branch had some model changes, and some migrations. I ran those migrations, and viewed the feature branch.

Then I switched back to my main branch. I got errors because the database no longer matched my models. I tried (without thinking it through) to migrate backwards. This didn't work, becuase the migrations that had gotten me in to this state were no longer present. I then made the mistake of manually updating my database to its pre-migration state.

This put me in a situation where when I tried to re-run the migration, after merging in Barnaby's code, it didn't want to run, because the migration was recorded in the django_migrations table. I tried deleting the migration entry and got myself in to more trouble, with this error:

django.db.utils.ProgrammingError: relation "signage_scheduleentry_0dee419f" already exists

I don't know how deep this rabbit hole will go, so am just restoring my development database from a backup.

Friday, August 10, 2012

Setting defaults for UIView subclasses

Hey! Cool! You can set default fonts and stuff for UIView subclasses using something fancy called the appearance proxy. You ask the class for the proxy like this;

[UILabel appearance]

And then set whatever values on that you want, like


[[UILabel appearance] setFont:[UIFont fontWithName:@"Miso-Bold" size:15]];

Then any UILabel you make will be created with the font Miso Bold, instead of the default.

Wednesday, July 4, 2012

Tackling Core Audio

I've been working with Alex Wiltchko's Novocaine, which works nicely as a pain-reducing wrapper for lots of basic core audio stuff. Unfortunately, it's not idiot-proof, and I've made at least one idiot-level mistake with it.

Alex very nicely packaged up an AudioFileWriter class with the project which works great for me in the simulator, but fails unpredictably when I try to use it on a device. So for me, anyway, it seems that dream of avoiding touching core audio, and the dreaded AudioStreamBasicDescription has not arrived.

Today I'm playing around with ExtAudioFileWriteAsync, seeing which sorts of settings will work for me.

Writing to AIFF is working without too much trouble, but I'm having a heck of a time writing to m4a. It looks as if ExtAudioFileWriteAsync is sensitive about the number of frames passed when writing files of format kAudioFormatMPEG4AAC. When passing a buffer of 10,000 frames, I get a crash with this error code: -66567.

For anyone reading this who can't make sense of these error codes (like me, until yesterday), you can search the headers of whichever framework you think the error originated from for the code. Here's some explanation.

Anyway, -66567 resolves to kExtAudioFileError_MaxPacketSizeUnknown. I'm unable to find any documentation indicating just what this message means.

Now, when I reduce the number of frames I'm passing to ExtAudioFileWriteAsync to 512, the error message goes away, but the resulting file is only 28 bytes long and is unplayable. This is only in on my iPad. All works fine in the simulator.

Now I'm simplifying and trying to work with the synchronous version of ExtAudioFileWrite. This is failing immediately with kExtAudioFileError_MaxPacketSizeUnknown, even when I give it a very small number of frames (100).

This StackOverflow post indicates that there are some properties that are required to be set. I'm not sure that I read the documentation the same way this poster does, however it seems that in their case, setting kExtAudioFileProperty_CodecManufacturer solved a problem.

Monday, May 7, 2012

Spent four hours on FilePlay today. This app is going to involve quite a lot of hard work. My current status is this: FilePlay successfully streams multiple files from disk. On the iPhone it can handle about three stereo files. Not very impressive. Discovered the files Jay gave me were 24-bit. So I'll be able to stream more like 4 files easily. Still not super impressive. Next step is to be able to swap out one file for another mid-play. Tried doing this and am getting errors in fseek. Blowing off yoga in favor of programming. Went for a 25 minute walk today though.

Thursday, May 3, 2012

Cheap and Deep app progress

Spent most of the day today working on FilePlay, a class that's part of EZPlug and streams files from disk and into an EZPlug network. It's just a little bit trickier than I can easily wrap my head around. Running in to multiple problems: memory issues with no warnings in XCode, and niggly little logic bugs of the type that crop up when I work with juggly-type code. Somehow, anything involving getting to the end of something and then jumping back to the beginning always gives me trouble. I'm going back and forth a bit about whether I should just use Apple's code, because surely they know what they're doing, and surely I don't. But generally, I'm settling on the idea that FilePlay is something I'll be using again and again, and it's worth taking the time to get it right, and to make sure that any time I want to do this stuff in the future, it will be very easy. Very E-Z.

Friday, February 25, 2011

debugging C++ in XCode

I've been frustrated by how XCode's debugger seems to be easily confused by C++. Also generally annoyed that it's hard to view the contents of an array by unfolding arrows. Things are moving along much more nicely now that I've started paying more attention to the command-line interface to GDB, the debugging tool beneath xcode's debugger gui.

For example, when trying to inspect a variable, I was getting this error: "current stack frame does not contain a variable named `self'. The problem was that GDB thought it was looking at ojective-c when in fact it was C++. The fix was to manually tell GDB via the console that it's looking at C++.

set language c++

The GDB command line interface is also really nice for examining buffers. When working with audio, you get deal with huge sets of data, tens of thousands of samples. There's no obvious way to examine that data via the debugger ui. Even harder, what if you want to examine a small chunk of it somewhere in the middle. With the GDB console, I can type this:

(gdb) x/64f sample.data_ + sampleReadPosition


Where sample.data_ is my audio data and sampleReadPosition is where I want to start looking. A few more things about this command: x is the main command which inspects data. /64 means repeat 64 times, and format as a float. So this command says: look at the memory pointed to by sample.data, jump forward by sampleReadPosition step, and format it as a float.

Here's the output.

0xbd9b458: 0.0132450331 0.0792260543 0.0219122898 0.0856349394

0xbd9b468: 0.0309457686 0.0916776061 0.0396130271 0.0969878212

0xbd9b478: 0.0487075411 0.101870783 0.0573747978 0.106387526

0xbd9b488: 0.0656758323 0.110171817 0.0739768669 0.113162637

0xbd9b498: 0.0818506405 0.115421005 0.0890530124 0.116946928

0xbd9b4a8: 0.0958281234 0.117313154 0.102237009 0.117313154

0xbd9b4b8: 0.107913449 0.116214484 0.112796411 0.114322335

0xbd9b4c8: 0.116946928 0.111270487 0.119998783 0.107547231

0xbd9b4d8: 0.122623369 0.102969453 0.1241493 0.0977202654

0xbd9b4e8: 0.124515519 0.0916776061 0.1241493 0.0845362693

0xbd9b4f8: 0.122989595 0.076967679 0.120731227 0.0686666444

0xbd9b508: 0.117313154 0.0596331693 0.11358989 0.0505386516

0xbd9b518: 0.108279675 0.0404065065 0.102603227 0.0302133244

0xbd9b528: 0.0961943418 0.0200201422 0.0886867866 0.00909451582

0xbd9b538: 0.0807519779 -0.00146488845 0.0724509433 -0.0124515519

0xbd9b548: 0.0634174645 -0.0230109561 0.0539567247 -0.0335703604



If you find yourself working outside the cocoa frameworks (and perhaps even if you don't), I highly recommend digging in to GDB.