This morning I noticed that GitX has been updated to 0.6.1 with quite a few new features from version 0.5 that I had been running. I haven't done a lot in Git, but I know that's where I'll be doing all the work I want to do, and for the little projects that I have put into Git, it's a great little tool for visualizing the repository.
I'm still a command-line guy, but old habits die hard. If only Xcode put in Git support. That would be great.
It looks like the guys at Bare Bones software have been busy working on BBEdit 9.1.1 which seems to be just a fixes release. No new features at this time, but plenty of bugs fixed - some even crashers. Nice to see that the updates are still coming.
I've just finished what I can call "Round 1" of the refactoring and updating of my Potentials application. Basically, it's a Poission's Equation solver that allows for several difference shaped objects - metals and non-metals, on a field with boundary conditions and varying dielectric constants. The solution is the potential at each point, and from there you can get the electric field - well, actually, I do in the output.
What I had originally written was the 'engine' of the simulator, and not really spent any significant time on the UI. Well, a few days ago, I decided that I needed to have a test case for the CorePlot work I'm going to be doing and so I decided to start fixing up this guy as I was going to need to sharpen my skills anyway, before diving into the CorePlot code.
The original UI had an NSTextView for the log messages from the simulation and an NSTextField for the filename to load up and run, along with a "Go" button and a status line label. Really, it worked, but it wasn't very clean at all.
The new UI has an MSTextView, but now it's for editing the source for the simulation and using menu selection and keyboard shortcuts for the running of the simulation. It's also got the File Open and File Save dialogs so that you interact with it as you would a 'real' application.
No question, I need to add a lot to make it "real". Most notably, preferences and the saveing and loading of same. That way, the font could be changed, the window's position saved and reloaded, and even the working file reloaded on restart. There's a lot that could be done, but I've been making really good progress so far, and I think now it's time to spend a little time on the CorePlot framework to see what it is that needs to be done there.
I have been having a blast refactoring the GUI of my Poission Equation solver - Potentials, using Xcode. I had a very simplistic interface in the beginning because I wanted to focus on the math involved, and then never really took the time to mess with the GUI as I realized that I didn't have access to a really good graphing package with which to display the results.
With CorePlot on the horizon, I got interested in it again and decided that the simplistic view of the app needed an update. I had a simple text field for the input file name, a "Go" button, a status label and a text field for log messages. Problem is that the solution is so fast, there's no need for the log text area as the status line will be fine for user feedback.
So I decided to make the app an editor of the source file and headed in that direction. I was very happy to see that I had already really laid down about 80% of the necessary code for this, and there were only a few things I needed to change. When I started to edit the MrBig.h header to include more outlets and actions I was stunned to see that InterfaceBuilder automatically re-parsed that header and added in the actions and outlets to it's representation.
That was a real treat. In the past, you had to manually ask for that to be done and it was always a touchy process that could get you into trouble if you didn't format the actions and outlets properly. Now, with the IDOutlet and IBAction descriptors, it's easier for IB to figure all this out.
Amazing tools, and lots of fun to work with.
OK, today I decided to get the latest Static Analyzer as I have really enjoyed the reports in the past, and I knew from the mailing list I'm on, that there have been a ton of changes. Well... I had no idea.
The first thing was that there were some old plist definitions in the Potentials project and I had to root around to find out where they were defined and then remove the bad names and let the defaults be used. That was slightly frustrating, but I really did enjoy the fact that the navigation of the compile-time parameters has become so easy in Xcode 3 that it's really not that bad a chore.
Once I had that, I needed to make an alias to make it simple to run the analyzer. I added:
alias checkit '/usr/local/checker/scan-build -k -V xcodebuild -configuration Development
(all on one line) to my .tcshrc and I was ready to hit it again and again. I like that they have incorporated the viewing right off the command-line, very nice.
The next thing I realized was that I was getting a lot of warnings of the form:
warning: dereferencing type-punned pointer will break strict-aliasing rules
After quite a bit of Googling, I found that it's related to the use of the -fstrict-aliasing optimization option that is put in place (by default) by the -Os optimization (size and speed). So... that's not great. But it shouldn't have been there - so says the Googling. There had to be something else.
And there was... in the GUI if you turn on the "Auto-Vectorization" optimization, then that's the trigger point and there's nothing you can do about it.
If you have this checked, then every time you reference super as in:
if (self = [super init]) {
in your initialization code you're going to get this kind of warning. I tried and tried to use the -Wno-strict-aliasing, but there was nothing I could do to turn off these warnings other than to build as 'Development' (where the optimizations are turned off) or turn off the Auto-vectorization. Shucks.
I read through the man page on gcc and I think the only thing I'm missing out on is the automatic vectorization of loops. It's not to say that it won't be done, but it's going to assume it can't and then see if it can. Not great, but I'm not about to re-write my init methods to skip this, and there's no amount of casting or forcing that removes this error. Calls to super are just not "OK".
I'm not the kind of guy that likes seeing 75 warnings on the build, either. So I have to settle for skipping the auto-vectorization. In the end, I added a few things to the code and cleaned up the build and I'm really rather happy about it. I do believe that Xcode is one of the best development environments that I've ever worked in. It's really quite wonderful.
I noticed this morning that one of my price injectors was hung up in a poor, sick little infinite loop when the service (vendor provided) had died and then I restarted it. I had not coded up the library to close and re-open the connection. In an attempt to make my application fault-tolerant to this service's restarts, I decided to dig in and add in all the pieces I needed to properly reconnect when the service was restarted.
If only it were easy.
The first thing I had to do was to unroll where I was in the processing so that I'd pause what I was doing (or trying to do) when an error with the service was detected. That didn't take too long, but I wanted to make sure I didn't put in the logical equivalent of the goto statement, so it took a little bit of work to handle it properly.
Once that was done I needed to have the main thread detect this condition and then close/re-open the connection. Here's where I really started to run into problems. While the code appeared to be what I needed, I would get just a few attempts and then a double free core dump. Every time. And it was always in the vendor's API code. It seemed that no matter what I did there was no way to avoid this problem. Crud.
So what if I tried to "go around the horn" and exit the app with an error condition and then have the guardian script that started the app, and restarts it in the case of a core dump would see this and restart the app. That's OK, but what if it fails right away? Well... that's the problem. So what I tried next was to put a retry loop on the creation of the connection to the service. Maybe that would work.
Better. It seems that so long as the connection isn't ever really made, you can call the open() call as many times as you need to get the job done. I'm getting a lot closer. Now that I have a way to exit the app with an error and restart it with a retry loop all I had to do was to make sure we didn't litter the directory with core files. The final problem was that trying to close a troubled connection lead to the same double frees that I was getting in the first place.
So I had to put in even more logic to the wrapper classes on the vendor's API so that I could be assured that the application could exit cleanly and then the restart would take care of waiting until the service was up again.
Finally I had something. It took a few hours, but in the end I have a system that's fault-tolerant to the vendor's service restarts and that's what I wanted to build today. It's going to make it much stronger a system. Good news.
I was reading the RSS feeds this morning when I ran across this interview of two lead developers on a C++ templated matrix library. Very interesting stuff. Their project is called Eigen and has some very interesting capabilities. First, it's self-contained. Secondly, it's all C++ and templated, so it supports both fixed and variable sized arrays and matrices.
I'm not sure I'll do anything with it, but if I get into a situation when I need matrix algebra, I'm going to give this a go. It's probably not the highest performance library in the book - face it, it's all generic templates. But for that there's a universe of decent performance at a very marginal cost. Sounds very nice.
So I'll keep it in mind. Useful if I need something like this.
I've decided this afternoon that I haven't been able to really give Python a clear chance. I've been using it for over a year as part of this vendor's application - it's the embedded language that virtually everything is done. That, in itself is not bad, as one of Python's strengths is the ability to embed it easily in C/C++ applications. No... it's what they have done to it that makes it hard to get a really good read on Python.
For example, you should be able to run a python script, and upon proper loading of libraries, get all the added functionality of the loaded module - like sybdb. Standard stuff. In fact, you should be able to use any python of the same version on the same box, and if you can load those libraries you should be good to go
The problem is, they have fiddled and monkeyed with the language to the point that this isn't really possible. You can get some things but others are only half-working and others still are completely broken. This means that you need to run their python and set up a very complex environment to get this running.
This represents a huge initial cost to running a python script. No such thing as a quickie... no sir. You have to really want to run a new python script. It's a pain. They are not really flexible. It's a system that makes python look bad. And I'm only just coming to realize what part of this train wreck is the vendor's stuff and what part is the python.
As I get more experience with the system I realize that there are a few things I'm not a fan of that are indeed python. However, they are completely overshadowed by the vendor's mistakes and limitations. It's amazing.
So I'm trying to give python the benefit of the doubt and realize that 99% of all the problems I'm seeing with this system is not the fault of python, but the implementation they slapped around it. Too bad. I'm sorry, python.
UPDATE: case in point: the difference between the '=='/'!=' and 'is'/'is not' operators in an if statement. For example, consider the two code samples:
if value == None: print 'Value is not defined.'
and:
if value is None: print 'Value is not defined.'
The difference is that the equality ('=='/'!=') operators call a method on the objects to do a value comparison, and the instance operators ('is'/'is not') do a instance comparison (pointer comparison) on the two instances. This means that the latter is significantly faster than the former, and in the case of None, it's the preferred method as well as there is one and only one None object in the python runtime. This makes the latter test preferred, and faster. That's pretty cool.
The last few days Drew has started a few threads on the CorePlot discussion Google Group and it's brought out a lot better discussion than I really expected to hear so early in the game. There are clearly a lot of folks that have done plotting work - several PhDs in the sigs. Nice. It's a group of guys like myself that have tried and had some success (or not) on different platforms, and certainly more than a little experience on the Mac platform.
All the ideas I had - preferences and strong beliefs, have been covered already so I don't yet feel the need to get into the discussion, but if I hear something that makes me nervous about what they plan, I'll be sure to chime in.
The basics are very nice:
There are a lot of things I'm looking forward to use this for: the Potientials code I have - been waiting on some nice graphing for a while. Then there's a series of "monitors" that are accessible via DO or sockets library in CKit - for example. It'd be nice to be able to have a general "strip chart recorder" for data coming out of an app. Like an interesting take on debugging. Hook this up, and bang! you have an independent plotting window that takes your data and plots it nicely. Neat ideas. Can't wait to get started.
This is certainly going to update my ObjC (2.0) skills as well as all the new classes in 10.5... going to be an exciting time.
Base 1.2 has been released with a few new additions: SQL syntax highlighting, support for views and triggers, and saving columns widths in data browser. Nice additions, but nothing earth shaking. The additions look good, and seem to work as advertised. If things keep moving in the direction I think they are going with the open source graphing toolkit I'm volunteering for, I may have more use of this than previously thought.
Nice to see the update.