Hi Julian,

I'm very excited to hear about an upcoming release! I'm speaking for a team with a handful of developers, and we've all really enjoyed learning blitz and appreciate the work you have done thus far. I just wanted to reach out with a few observations and offer any help you may need since I've been doing a lot of building/testing with the latest code in the Mercurial repository.

My team has mostly been using a version from 2009 from the CVS repository since it has been very stable for us. Recently we've been looking at getting some of the newer stuff and testing it out (great timing with the release!). So here are a few things I've noticed, and expect others might as well moving from 0.09 to 0.10. Note that we've been compiling in 64-bit Linux with gcc 4.4.5 and 4.3.3 as well as Windows VS2010 x64 and Win32.

A change since 0.09 that required a fair amount of refactoring in our code was the update to using size_t and ptrdiff_t for sizes and strides. I think this is a great change for portability and safety, and well worth the refactoring. However, I noticed a few spots where it's not quite consistent or complete. There are a lot of places where int is still used in place of ptrdiff_t (or interchangeably). Thus a lot of value truncation and "possible loss of data" occur on most 64-bit platforms. Granted, unless people are using very large arrays or doing unique indexing there aren't too many safety concerns, but I think with a little work the interfaces could be a little more robust. Since a lot of the common APIs have changed already, seems like it could be worthwhile to update them all for consistency. Also, the compiler warning list generated from an x64 Windows build is not very comforting, largely due to the amount of ptrdiff_t to int truncations. A few specific examples are in range.h an range.cc in the "length" and "operator[]" members respectively. This is one area I've specifically looked at trying to clean up. I don't know the history behind a lot of the components or the extent of such a cleanup, but if you have any direction or suggestions I'd be glad to help. 

There are a few spots where there are alignment pragmas without the BZ_USE_ALIGNMENT_PRAGMAS check around them. Specifically in tvevaluate.h, tmevalute.h, and globeval.cc. For those not using Intel compilers, the warning list can get quite large :-) 

I noticed a slight issue with the configure setup in Linux with regard to passing CXXFLAGS. If I run "autoreconf -fiv" followed by "configure --prefix=$(MY_DIR) CXXFLAGS=-DMY_FLAG CPPFLAGS=-DMY_OTHER_FLAG" the CXXFLAGS do not seem to be passed to the Makefile correctly and get overwritten by default options or are left empty. The CPPFLAGS gets passed just fine. Couldn't seem to figure this one out, maybe just a weird quirk?

I hope these issues help you gauge where some users might be coming from. I know it's hard to weigh getting releases out, not "breaking" users, and making things very clean, but let me know if I can help in any way with patches, testing, or more feedback.

Thanks,

-Matt