Archive

Posts Tagged ‘error’

Eclipse Development Lossitude

May 28th, 2010
1 comment

Here are two things about Eclipse which recently annoyed me. (I imagine it’s Eclipse’s fault, I guess It may be Java’s.)

1) When you reach an exceptional condition, the correct response in debug mode is to freeze the program and allow the developer a chance to inspect the current state. Stack, Heap, location, all that good stuff.

Throwing your arms in the air, screaming bloody murder and throwing away all the useful information when an error occurs is not useful. It turns debugging java into a game of “How close can you get to an error, without actually reaching the error.”

If you reach the error you lose the game, along with any useful data that might help you fix it.

2) You only seem to allow me to put breakpoints on lines on code. This implies that I already know where an error is. If I did, I’d probably fix it.

Why can’t you let me break on more useful things like when a particular variable has a particular value. This is similar to the previous point where I don’t want the program to drop everything and run away before I can look into it.

3) In 2010, the best way to debug a Java program is to pepper it with Print statements. This is sad.

Self , , ,

WordPress Lossage

May 14th, 2010
No comments

The latest update seems to have screwed up some plug-ins. Most notably the collapsible archives and source code highlighting.

Hopefully this is only temporary.

Self, Uncategorized , ,

Snow Leopard can DIAF

September 16th, 2009
2 comments

Hurray! Apple fanboys should be pleased with the release of OS X, version 10.6. Snow Leopard panders to their desire for an all Apple platform. For the rest of us sensible users, Apple have screwed the pooch.

Okay, we have new shiny toys like Quicktime X and – well, that’s about the height of noticeable changes. I’m all for enhancing the user experience, but in this case, in my opinion, it has come at the expense of developer comfort.

What I’m referring to here is the lack of Java support in the new XCode 3.2. I’ve always felt that XCode was a fairly elegant environment for writing all C/C++, Java and Objective-C projects. So- why, Apple, would you arbitrarily drop support for a language? Out of spite? You didn’t even drop support – you just made it frigging irritating to use. Do you enjoy kicking your users in the nuts with each new release?

I’m not even surprised at this stage. I guess I could add the XCode templates back in manually but I’m more in favour of adopting a more portable command line build process… It seems the best way to get away from Apple’s user abuse.

Programming , , , ,

Windows updates

September 10th, 2009
2 comments

I am forced to use a Windows based laptop in work and one of the more frustrating features is the updates that get pushed out by the IT ‘services’ group. Of course, updates are a good thing, but we do them during downtime when it won’t disrupt actual work. Here are the things I most hate about these Windows updates:

Do it now, or else.

There are updates available for your computer. You can install them now or they will automatically be installed in 15 minutes. After installation your computer will be restarted.

I’m sorry, were you busy?

As if point 1 didn’t irritate me enough (which is most certainly does), updates frequently occur right in the middle of a large task. Copying a large file or set of files is doomed to failure. In other cases the updates will simply interrupt anything you happened to be doing, forcing you to break your concentration.

Update Dependencies

OK, I’ll install your updates already! Tick, tick, tick… *reboot*
Your updates have been installed. There are new updates to install.

Yes, some updates rely on the presence of previous updates so it takes a couple of runs to get them all installed. which also means a couple of reboots; a couple more minutes of your precious day.

And one of my personal favourites: The “Your computer must be restarted dialog” which always stays on top of other windows. In case you forget.

Software , ,

Protecting Code from Uncertainty

February 3rd, 2009
1 comment

if (2 > 5) {
fprintf( stderr, "This shouldn't happen!\n" );
} else {
//continue as normal
}

It really amuses me when I see code sections commented as “This shouldn’t happen” … It usually means that the programmer is about 98% certain that no condition will occur in which the code is executed. However, just in case the fundamental laws of the universe suddenly collapse, that particularly obscure error will be correctly handled.

Programmers care about the correctness of programs even under the most unlikely scenarios.

Programming , ,

GLUT on Mac OS X

January 30th, 2009
1 comment

I was having a problem using Glut (GL Utility Toolkit) on my Mac today – despite the number of sites saying that it was a snap to set up:  ”Just add the GLUT.Framework to your project and compile.”  – Well, my program was compiling OK, but running it would always result in a “bus error” and drop into the debugger.  I tried various combinations of compiling from command line, running under X11, trying port and fink for different libraries – What could this weird problem be?

I eventually came across the root of the problem and since I haven’t seen it posted anywhere on the web I decided to add my own contribution to the “GLUT on OS X” billboard.  I’ll try to give the complete setup I used to start a Glut project in XCode.

Setup XCode Project

Like many others will suggest, open XCode (or project builder) and create a Standard Tool (or C++ Application or whatever). I recommend a Standard Tool because you just get a basic main.c file and that’s enough. Add the GL.Framework and GLUT.Framework files from /System/Library/Frameworks.  (This is where they are on my Mac)

Rename the file main.cpp/m to main.c for a basic C application.  (I’ll stick with this for now as it is sufficient)

Modifying the standard code

Headers need to be changed from gl/ to OpenGL/ and GLUT/ in order to correctly locate the headers in OS X’s frameworks.  The top of main.c should read as follows:

  1. #include <OpenGL/gl.h>
  2. #include <OpenGL/glu.h>
  3. #include <GLUT/glut.h>

And here’s the bit that was killing me.  Most of my glut code is based on the skeleton provided from NeHe’s tutorials which initialise glut then initialise opengl then sets up glut’s window properties. like so:

  1. int main ( int argc, char** argv ){
  2.     glutInit ( &amp;argc, argv );
  3.     initGL ( );
  4.     glutInitDisplayMode ( GLUT_RGBA | GLUT_DOUBLE );
  5.     glutInitWindowSize ( 500, 500 );
  6.     glutCreateWindow ( "NeHe’s OpenGL Framework" );
  7.     glutDisplayFunc ( display );
  8.     glutReshapeFunc ( reshape );
  9.     glutKeyboardFunc ( keyboard );
  10.     glutSpecialFunc ( arrow_keys );
  11.     glutMainLoop ( );
  12.     return 0;
  13. }

OK, everything looks good right?  Not for OS X apparently.  Maybe this is obvious for some people but I had to trace a bit to see what was causing my problem.  As it turns out I was able to fix it by moving the initGL call after all the glutInit*/glutCreate* calls.  Thus, my new main looks as follows:

  1. int main ( int argc, char** argv ){
  2.     glutInit ( &amp;argc, argv );
  3.     glutInitDisplayMode ( GLUT_RGBA | GLUT_DOUBLE );
  4.     glutInitWindowSize ( 500, 500 );
  5.     glutCreateWindow ( "NeHe’s OpenGL Framework" );
  6.     initGL ( );
  7.     glutDisplayFunc ( display );
  8.     glutReshapeFunc ( reshape );
  9.     glutKeyboardFunc ( keyboard );
  10.     glutSpecialFunc ( arrow_keys );
  11.     glutMainLoop ( );
  12.     return 0;
  13. }

I hope this is helpful to someone else since it seems to be a rather obscure error (that only affects Mac OS?).  I’m glad I caught it though – as much as I intend to use Cocoa in the future, it’s nice to know a simple framework is still available. :-)

Programming , , , , ,