September 1, 2010

When in -mouseEntered: don't use NSPointInRect for checking which tracking area is hit

Do not assume that the mouse location of any mouse tracking NSEvent is necessarily inside or outside of the tracking rectangle as specified by the NSTrackingArea. Use the -trackingArea method of NSEvent instead of NSPointInRect to check, which trackingArea has triggered the event.

Bad code

- (void) syncInsideWithEvent:(NSEvent *) event
{
   NSPoint       point;
   unsigned int  i;
   
   point = [self convertPoint:[event locationInWindow] 
                     fromView:nil];
   for( i = 0; i < N_AREAS; i++)
      inside_[ i] = NSPointInRect( point, area_[ i]);

   [self setNeedsDisplay:YES];
}


- (void) mouseEntered:(NSEvent *) event 
{ 
   [self syncInsideWithEvent:event];
}


- (void) mouseExited:(NSEvent *) event 
{ 
   [self syncInsideWithEvent:event];
}

Better code

- (void) syncInsideWithEvent:(NSEvent *) event
                      invert:(BOOL) invert
{
   NSTrackingArea   *hit;
   NSTrackingArea   *area;
   unsigned int     i;
   
   hit = [event trackingArea];
   
   for( i = 0; i < N_AREAS; i++)
   {
      area        = [[self trackingAreas] objectAtIndex:i];
      inside_[ i] = (area == hit) ^ invert;
   }
   [self setNeedsDisplay:YES];
}


- (void) mouseEntered:(NSEvent *) event
{
   [self syncInsideWithEvent:event
                      invert:NO];
}


- (void) mouseExited:(NSEvent *) event
{
   [self syncInsideWithEvent:event
                      invert:YES];
}

Posted by Nat! on September 1, 2010 11:48 PM | | Comments (0)

August 2, 2010

MulleSybaseEOAdaptor 2.12 released

Although I am not actively using Sybase anymore (unfortunately), there are occasional tweaks and improvements made to the adaptor. So version 2.12 should be better than 2.7 in any case, if not please tell me. I need to port the code to Intel some time, but I am occupied with other stuff

Here are the releasenotes of the unpublished versions.

Version 2.12

  1. Changed hash algorithm of mulleSybaseRowDictionary optimization done in 2.7 for even better performance

Version 2.11

  1. Reverted a supposedly harmless change in datetime handling since there were troubles in GMT apparently.

Version 2.10

  1. Use slower but more compatible code to produce the inital SELECT statement for text/image writes
  2. Experimental fix for writetext, when size is evenly divisible by 512

Version 2.9

  1. I am really pedantic on +formatValue not being nil. It shouldn't happen when using MulleEOF and you should be passing in [EONull null] anyway
  2. Removed a leak involving error messages
  3. Fixed a special Sybase type handling of LONGCHAR types
  4. Avoided a leak when returning factory produced values

Version 2.8

  1. You may pass in "nil" as a value for -[EOAdaptor fetchedValueForValue:attribute:]
  2. Finally in version 2.8 "expressionClass" will not be overridden, but "defaultExpressionClass", which is correct.
  3. If an image attibute has value null, the adaptor will not write a serialized [EONull null] into the DB.
  4. Image/text is written with a simpler qualifier, that is just qualifying the primary key.
  5. -[MulleSybaseSQLExpression primaryKeyConstraintStatementsForEntityGroup]produces proper SQL code now
  6. Versioning information should be correct (thx to patrick@onestep.co.uk for noting that).
  7. Fixed Void and In/out parameters sql generation to produce syntactically correct SQL
  8. JDBC compatibility port number hack
  9. Fixed creation of primary key constraints generation (or rather their declaration, the statement issued is not a true constraint, which I might fix with MulleEOF 2.0)
  10. If _debug flag is set, the adaptor now writes the number of bytes read (along with the SQL) in completeFetch

Posted by Nat! on August 2, 2010 12:48 PM | | Comments (0)

July 14, 2010

EXC_BAD_ACCESS and no stack trace == more quality time lost in Xcode

DISCLAIMER: THIS IS FOR i386 ONLY

And as things are wont to do, Xcode debugging just went from bad to worse for me. To figure out some other problems (see previous posts) I enabled some debug code, which led to this crasher in middle of nowhere^h^h^h^h^h^h^hobjc_msgSend. There is this tendency of debug code to create more bugs and henceforth more debug code, but I disgress...

With no clue in the console log and no stack trace (see picture) I was stumped.

Obviously the crash occurs at 0x986ceed7, where you see the red instruction pointer arrow.

Recovering the Stacktrace

You can help Xcode along a little ways to display the correct stack trace, and only god and apple know, why it can't do this on its own, but I guess syntax coloring is way more important...

Move the instruction pointer to a ret instruction. In the screenshot the address of a known ret instruction is marked green. If you see a different hexadecimal number in your disassembly there, by all means use that. Now go into the gdb debugger console to recover the stack trace: 

(gdb) set $eip = 0x986cef35
(gdb) stepi
(gdb) where
#0  0x00000000 in ?? ()
#1  0x9842e5a4 in _NSDescriptionWithLocaleFunc ()
#2  0x92b04322 in _CFStringAppendFormatAndArgumentsAux ()
#3  0x92b036a9 in _CFStringCreateWithFormatAndArgumentsAux ()
#4  0x92babf2e in _CFLogvEx ()
#5  0x984bf7e8 in NSLogv ()
#6  0x984bf757 in NSLog ()
...

Voilà! Or Viola as it's commonly misspelled.

Continue reading "EXC_BAD_ACCESS and no stack trace == more quality time lost in Xcode" »

Posted by Nat! on July 14, 2010 5:25 PM | | Comments (0)

July 13, 2010

Betcha can't debug that

Along the lines of those guitar videos here is an Xcode Project, that crashes in the Xcode debugger but not stand alone. I bet you can't debug that!

The expected output of the debugger is:

Running...
memory_pressure: 0memory_pressure: 02010-07-13 21:51:44.114 MoreTroubleInXcode[13281:a0f] I don't blame you.
Program received signal: "SIGABRT".
sharedlibrary apply-load-rules all
Cannot access memory at address 0x0
Cannot access memory at address 0x0
(gdb)

Continue reading "Betcha can't debug that" »

Posted by Nat! on July 13, 2010 8:43 PM | | Comments (0)

MoreTroubleInXcode.zip