Vim's quickfix and GCC 4.5
I’ve been using Vim more and more as my primary editor both at home and at work. Recently I’ve started using its quickfix support too to run make and then navigate to the errors.
I hit a problem where in the version of Vim in Ubuntu doesn’t have support for the
newer format error messages in gcc 4.5, misinterpreting the “In file XX at line YY:ZZ” message. The most recent Vim has a fix, but if, like
me, you don’t have much appetite for installing non-system versions of things like
Vim, then you can fix up the error parsing by putting this in your .vimrc:
set errorformat=%*[^"]"%f"%*\D%l:\ %m,"%f"%*\D%l:\ %m,%-G%f:%l:\ (Each\ undeclared\ identifier\ is\ reported\ only\ once,%-G%f:%l:\ for\ each\ function\ it\ appears\ in.),%-GIn\ file\ included\ from\ %f:%l:%c:,%-GIn\ file\ included\ from\ %f:%l:%c,%-GIn\ file\ included\ from\ %f:%l,%-Gfrom\ %f:%l:%c,%-Gfrom\ %f:%l,%f:%l:%c:%m,%f(%l):%m,%f:%l:%m,"%f"\,\ line\ %l%*\D%c%*[^\ ]\ %m,%D%*\a[%*\d]:\ Entering\ directory\ `%f’,%X%*\a[%*\d]:\ Leaving\ directory\ `%f’,%D%*\a:\ Entering\ directory\ `%f’,%X%*\a:\ Leaving\ directory\ `%f’,%DMaking\ %*\a\ in\ %f,%f\|%l\|\ %m
I’m also experimenting with some alternative bindings to replace me typing :make. So far I’m using control-F10 to build and show errors, and F3, F4 to navigate between errors with:
function Make()
silent make
redraw!
cw 8
echo getqflist()[-1].text
endfunction
nnoremap <c-F10> :call Make()<CR>
nnoremap <F4> :cnext<CR>
nnoremap <F3> :cprev<CR>
It’s by no means perfect as you get no feedback during the make process itself (which is rubbish), but it’s a start.
Filed under: Coding
Posted at 20:30:30 BST on 27th August 2011.
An update to Miracle
Again I find my blog has fallen into disrepair due to lack of updates…but I have my excuses!
Firstly, I’ve been incredibly busy at work, continuing to enjoy learning lots about how trading systems work. I’ve ended up travelling quite a lot to our satellite office in Greenwich, Connecticut too, which eats into my time.
I’ve also moved house since the last update, now living opposite Lake Michigan in the town of Winnetka. Ness, the boys and I are all really enjoying our new suburban living. Both boys have had birthdays too — Isaac is now 1, and William is 3.
So anyway, to the other time sink in my life: Miracle. Since the last update I’ve added a lot of bug fixes, optimized it a load, integrated a debugger (complete with persistent labelling of memory addresses), and most importantly of all, have added early sound support.
It requires an up-to-date browser (bleeding edge Chrome, for example), and probably needs you to fiddle with enabling alpha settings (see here), but you can now enjoy Sonic with sound!
Take it for a spin here, or check the code out on Github.
Filed under: Coding
Posted at 23:30:30 BST on 8th July 2011.
Introducing Miracle
This weekend was a long weekend in the US (Presidents’ Day, apparently). As well as spending some time with my family, I set myself the goal of doing something “cool”, programming-wise.
Inspired by JSNES and JSSpeccy, I decided to port Richard Talbot-Watkins and my old Sega Master System emulator, !Miracle, to JavaScript.
I borrowed the Z80 emulator from JSSpeccy and thankfully Richard’s Master System documentation is still on the web, so I had a great head-start.
Sonic wags his fingers at me.
You can take it for a spin here (I’ll hack it later to allow me to embed it here). Keys are W, S, A and D for movement, Enter and Space for the fire buttons. I’ve rather cheekily embedded two ROMs that work quite well, Sonic and Teddy Boy.
The source code is on github if you want to take a peek.
There’s a ton of bugs and things to implement (most notably sound), but I’m pretty damn pleased with the results.
Next up, fix some bugs and then perhaps think about a BBC Micro emulator…
Filed under: Coding
Posted at 05:00:00 GMT on 24th February 2011.
Solving the threading problem in WinInet
In my previous post, I introduced a simple asynchronous HTTP request API which suffered from a quite major problem: it was impossible to cancel an in-progress request in a thread-safe manner. As it happens, the Windows Internet library suffers the same problem: though it’s hidden as desktop Windows doesn’t re-use handle values. However, Windows CE and Windows Mobile do; and so this problem does affect these embedded OSes.
Take a look at this code snippet, designed to show up the problem:
volatile int handle = -1;
void ThreadA() {
handle = StartRequest("http://google.com/");
int result = WaitForRequest(handle);
if (result >= 0) {
// We got the request ok. Process it here...
CloseRequest(handle);
handle = -1;
}
void ThreadB() {
Sleep(); // Wait a bit (gives Thread A a chance to run)
CloseRequest(handle); // Cancel Thread A's request
handle = StartRequest("http://yahoo.com/");
// ... process this request instead ...
CloseRequest(handle);
}
It’s pretty clear that the two threads will race on handle. As discussed
before, with the interface we have to work with, there’s no way of introducing a
mutex that protects handle without making it impossible to cancel an
in-progress request.
However, assuming that the API reliably gives an error if an invalid handle is passed to it or an invalid operation is carried out on an existing handle, there’s a workaround:
using std::set;
set<int> active_handles;
// Tries to register a handle as being in-use. Returns true
// if the handle is safe to use, and false if the handle is
// already in use by another thread.
bool TryRegisterHandle(int handle) {
LockMutex();
if (active_handles.find(handle) != active_handles.end()) {
// Although the system has given us 'handle' as a valid
// new handle to use, another thread currently believes
// it owns this handle. It is not safe for the current
// thread to use the handle.
UnlockMutex();
return false;
}
// It's safe to use this handle: prevent any other threads
// from using it for the duration this thread believes it
// has ownership by keeping a note of this handle in the
// active set.
active_handles.insert(handle);
UnlockMutex();
return true;
}
void UnregisterHandle(int handle) {
LockMutex();
active_handles.remove(handle);
UnlockMutex();
}
The idea here is that we keep track of which handles we think we own and can safely use, regardless of the handle the system gives us. If we get a handle that another thread of ours is already using, we back off and try again. Writing a couple of utility functions to hide this gives something like:
void SafeStartRequest(const char* url) {
int new_handle = -1;
// Loop forever until we get a handle we can use.
for (;;) {
new_handle = StartRequest(url);
if (TryRegisterRequest(handle)) {
// Safe to use; break out of the loop.
break;
}
// Another thread thinks it owns this handle even though
// we got it fair and square from the system. It's not
// safe to use it! Do not close the request - the thread
// that thinks it owns it will close it. Sleep a bit to
// give other threads a chance to run, then loop around
// and get a fresh new handle, hopefully not one another
// thread thinks it owns.
Sleep();
}
return new_handle;
}
// Close the handle, then mark it as available to other
// threads. Should only be called by the owner of the handle.
void SafeCloseRequest(int handle) {
CloseRequest(handle);
UnregisterRequest(handle);
}
It’s certainly not elegant, and is non-obvious. It doesn’t even save you from all possible problems — what if the handles are system-wide and another program which doesn’t know about your registration system is running? What if the first thread has just created a new handle when the cancellation happens? If it gets caught at just the right time, the firstthread gets the second thread’s handle and uses it without error, oblivious to the fact that it should have been cancelled1.
Experience has shown that this is usually “good enough”. The original code becomes:
volatile int handle = -1;
void ThreadA() {
handle = SafeStartRequest("http://google.com/");
int result = WaitForRequest(handle);
if (result >= 0) {
// We got the request ok. Process it here...
SafeCloseRequest(handle);
handle = -1;
}
}
void ThreadB() {
Sleep();
// Cancel thread A's request.
// NB this does not use SafeCloseRequest as we don't "own"
// the handle.
CloseRequest(handle); // Cancel Thread A's request
handle = SafeStartRequest("http://yahoo.com/");
// ... process this request instead ...
SafeCloseRequest(handle);
}
Ideally though, you’d go back to the drawing board with your design and separate the cancellation from the closing of handles. Unfortunately, if you’re using the Windows Internet library on a mobile device, you’re stuck with this workaround.
-
This eventuality (and similar ones) can be covered with judicious use of a thread-safe variable storing “am I cancelled”, checked and acted upon before any handle usage. But this article is already long enough! ↩
Filed under: Coding
Posted at 17:55:00 BST on 7th July 2009.
