As a long-time anti-Microsoft person, I am somewhat ashamed to admit that I actually really like Windows 8. Here's why.
A lot of people get hung up on the tile view. I don't particularly care for it. Indeed, I have found several aspects disorienting, especially how to get to my old familiar control panels. Here's what made everything better, and indeed actually made Windows 8 superior to any other version of Windows I've used.
At the tile view, you can just type, and your computer will automatically start searching. It searches for programs, files, and settings. For example, if I want to run chrome, I simply type chrome and windows finds it. I can just hit enter, and go. No mouse involved. If I want to change my system environment variables - how the hell do I find that control panel? I don't have to find that control panel. Type in "variable" at the tile view, and under the settings results, I get a direct link to the panel for editing these variables.
So, the tile view for the purposes of being a UI sucks. It's overly customized for touchpad people. I agree. But the ability to simply type and have windows be so active in finding what I want to do is amazing. It's like they've turned the mouse experience into the touchpad experience, and enhanced the keyboard experience, which now can stand independent of the mouse experience much more strongly. It is empowerment of the keyboard for interaction with the UI. I don't want a touchpad. I like interacting with Windows 8 from my keyboard.
So, the tile view sucks. How do we work around that? Well, essentially all of the applications I use do not have "metro-style" full-screen views. They open in the desktop view, which aside from the absence of a start button, is the same as Windows 7. Thus, I have not lost my familiar experience with, say, Steam. The start screen for me serves only as a quick way to search for things to interact with on the alternate desktop view.
A lot of people (notably Gabe Newell of Valve) are upset with Microsoft for moving towards the Apple model of closed-garden software. I'm with them. If Microsoft shifts further, and begins to remove the alternate desktop environment for me to run things like Steam, I'll cry foul, too. For now, I'm enjoying the ability to utilize my keyboard for several mundane Windows interactions.
Linux still makes several things (mostly programming) easier, and the file hierarchy makes more sense, but Windows 8 gives my hugely positive experience with KDE a run for its money.
I have been generously granted a Wing IDE license for my hobby programming on Analyzarr ( http://www.github.com/msarahan/analyzarr ). It has taken me a while, but I owe this review to the generosity of WingWare.
First off, I have been programming python for several years now. I have always used only a combination of a text editor and an interactive prompt (IPython, especially). I'm writing this review as my first experience with a Python IDE.
In my new job, I have been using visual studio for C++ programming. I have gotten used to handy things like debugging tools. I'm sure there are ways to do this in Python, but Visual Studio makes it, well, visual. In IPython, I rather used the pdb magic call to turn on automatic pdb calling. It was of mixed use, probably because I didn't know how to use it. I was very excited to try Wing's debugging facilities.
Before I get ahead of myself, let me start where I should start, and that is first with a description of my system, followed shortly by the tutorial.
I have Ubuntu 12.04 x64, running on an AMD platform. I am using Enthought's EPD distribution, to which I subscribe (it is well worth it.) That gives me Python 2.7, and several up-to-date scientific libraries.
Tutorial:
- A lot of effort obviously went into this. It is very detailed, and it walks you through nicely.
- I encountered a crash when setting my python path. I repeated it twice, then gave up. I don't use pythonpath anyway. Rather, I generally install my code in development mode using something like 'pip install -e ./' from my source folder. I hope this won't be a problem down the road...
- Completion/"Source Assistant" - this thing is great! Having the docstrings right next to the editor, along with links to function declarations? This is fantastic! I'm left wishing for a way to jump back to the part I was just editing, before I clicked the link to jump to a function definition
- Debugging in the tutorial: I crashed again.
- Debugging, attempt 2: OK, now I encounter a problem with the path_example import. There's a helpful comment explaining that this won't work if you don't have the PYTHONPATH set from earlier in the tutorial. Very nice of them to not let users wonder about this!
- Well, I'd really like to set that PYTHONPATH, but again, I'm bombing out. I'm resorting to just copying the path_example.py file from subfolder into the folder with example1.py.
- OK, on with debugging. Breakpoints. Yes. This often exactly what I want when I'm trying to figure out an annoying bug. But wait, things get better
- When things go wrong in Python, you get a traceback. It tells you the locations in all of the files up the call chain where things went wrong. It's very useful for tracking down bugs, but here's the hitch - if you have a bug in your code that is messing up someone else's code, then the last error is not obvious. Wing really shines here - in its exceptions view, you can navigate that whole call stack, jumping to the source where the exception occurred. Very nice!
- Debugging just gets better! You can enter code at breakpoints, up to even redefining functions. As the tutorial states, when a bug depends on program state, you don't always want to start from the beginning. Instead, you can fix the bug, test it, and move on. All without restarting the potentially lengthy process leading up to this point.
- Lots of shortcuts for matching parentheses, jumping around, and generally getting lost in unimaginably useful ways.
Wing looks like a great environment, and I'm eager to get my feet wet. I might post again soon on my experience using it to actually replace emacs/IPython as my development platform.
HDF5 is my latest computing fad. I think it's definitely the best way to handle file I/O, and I'm using it in several projects. Most recently, I've been working to use it with QSTEM, which is my first real C++ project that I've used HDF5 in. The pre-built binaries are only available for VS2010 at the moment, so I've needed to rebuild HDF5 for VS2012.
There are directions for this here:
www.hdfgroup.org/HDF5/release/cmakebuild.html
They don't work. Not for me, anyway. I had several issues:
- I did not have svn installed on my system. Digging in the install log pointed this out to me. After installing TortoiseSVN, and making sure to enable its console tools, the ctest instructions got further. Things still didn't work though. MSBuild complained about an out-of-date project file that I needed to open in the GUI.
- I could have built SZip and ZLib separately and done a more traditional CMake build, but ZLib would not cooperate. I got some linker errors that I didn't understand, and that Google turned up nothing on.
What I discovered is that after step 1 ran to completion, it had left me with a decent CMake cache of settings. I ran the cmake gui and disabled Fortran, but kept everything else. I could now open the solution file output by CMake, and everything (including ZLib) was happy.
To save future travelers time, binaries for x64 are here:
http://t3hmikez0r.com/static/qstem/
Win 32 had problems with SZip and ZLib, even with the setup that worked for x64. Some issue with the "generator" - something going wrong with CMake. If you need 32-bit HDF5 built, sorry.
You can customize this section in