Timeout after application:openFile: stalling applescript

2012-09-13 Thread George Nachman
My application implements the NSApplicationDelegate method
-application:openFile: in its app delegate. There seems to be a problem new
to OS 10.8 where after receiving the apple event to open a file, five
seconds pass before some kind of internal timeout is hit, a response is
sent to the apple event, and the calling app (e.g., applescript editor)
proceeds.

In detail, here's what I see. After application:openFile: returns YES, I
can see that -[NSAppleEventManager suspendCurrentAppleEvent] is called:

#0  0x7fff8f07b5ed in -[NSAppleEventManager *suspendCurrentAppleEvent*]
()
#1  0x7fff8f90458e in -[NSApplication(NSAppleEventHandling)
_handleAEOpenDocumentsForURLs:] ()
#2  0x7fff8f903b55 in -[NSApplication(NSScripting)
handleOpenScriptCommand:] ()
#3  0x7fff90770cac in __invoking___ ()
#4  0x7fff90770b47 in -[NSInvocation invoke] ()
#5  0x7fff90770d19 in -[NSInvocation invokeWithTarget:] ()
#6  0x7fff8f10121c in -[NSScriptCommand _sendToRemainingReceivers] ()
#7  0x7fff8f1014c6 in -[NSScriptCommand executeCommand] ()
#8  0x7fff8f11983a in -[NSScriptingAppleEventHandler
handleCommandEvent:withReplyEvent:] ()
#9  0x7fff8f00635b in -[NSAppleEventManager
dispatchRawAppleEvent:withRawReply:handlerRefCon:] ()
#10 0x7fff8f0061bd in _NSAppleEventManagerGenericHandler ()
#11 0x7fff93844f68 in aeDispatchAppleEvent ()
#12 0x7fff93844dc9 in dispatchEventAndSendReply ()
#13 0x7fff93844c89 in aeProcessAppleEvent ()
#14 0x7fff8c141e29 in AEProcessAppleEvent ()
#15 0x7fff8f6b22a6 in _DPSNextEvent ()
#16 0x7fff8f6b1862 in -[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:] ()
#17 0x7fff8f6a8c03 in -[NSApplication run] ()
#18 0x7fff8f64d656 in NSApplicationMain ()
#19 0x00011d7c in main (argc=3, argv=0x7fff5fbff7c0) at main.m:23

After five seconds, -[NSAppleEventManager resumeWithSuspensionID:] is
called:

#0  0x7fff8f07b6be in -[NSAppleEventManager *resumeWithSuspensionID*:]
()
#1  0x7fff8f90585f in __block_global_1 ()
#2  0x7fff9073a4b4 in *
__CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__* ()
#3  0x7fff90739fcd in __CFRunLoopDoTimer ()
#4  0x7fff9071f7b9 in __CFRunLoopRun ()
#5  0x7fff9071edd2 in CFRunLoopRunSpecific ()
#6  0x7fff8c137774 in RunCurrentEventLoopInMode ()
#7  0x7fff8c137512 in ReceiveNextEventCommon ()
#8  0x7fff8c1373a3 in BlockUntilNextEventMatchingListInMode ()
#9  0x7fff8f6b1fa3 in _DPSNextEvent ()
#10 0x7fff8f6b1862 in -[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:] ()
#11 0x7fff8f6a8c03 in -[NSApplication run] ()
#12 0x7fff8f64d656 in NSApplicationMain ()
#13 0x00011d7c in main (argc=3, argv=0x7fff5fbff7c0) at main.m:23

Evidently, some kind of timeout was reached since resumeWithSuspensionID:
is called from a timer and it is always very close to 5 second between my
application:openFile: method returning and resumeWithSuspensionID: being
called.

After this, things proceed normally: whatever applescript invoked open
file ... continues at the next statement. There don't appear to be any
errors--it just times out waiting for something.

I turned on AEDebugSends and AEDebugReceives. Here's what I see up to the
timeout:

Aug 23 21:26:05 George-Nachmans-MacBook-Air.local iTerm[4819] Info:
_aeMachPortCallback(), got a message, @ 0x0x7fff5fbfe1f0 size=972 info=0
(_aeMachPortCallback()/AEMach.cp #643) main
Aug 23 21:26:05 George-Nachmans-MacBook-Air.local iTerm[4819] Notice:
AE2000 (4819: Received an event:
--oo start of event oo--
aevt('aevt'\'odoc' transactionID=0 returnID=3711 sourcePSN=[0x0,6f06f
AppleScript Editor] eventSource=3 sourceUID=501 sourceGID=20
sourceEUID=501 sourceEGID=20 sourcePID=3551
auditToken=[501,501,20,501,20,3551,15,3551]{ '':obj ('obj '{
'form':enum('name'), 'want':type('file'),
'seld':utxt('utxt'(TEXT(Macintosh HD:Users:georgen:Library:Application
Support:iTerm:version.txt))), 'from':null() }), 'csig':magn(65536) })
--oo  end of event  oo--
(aeProcessIncomingEvent()/AEMach.cp #1445) main
2012-08-23 21:26:05.451 iTerm[4819:707] Command: NSCoreSuite.Open
Direct Parameter: /Users/georgen/Library/Application
Support/iTerm/version.txt
Receivers: (null)
Arguments: {
 = /Users/georgen/Library/Application Support/iTerm/version.txt;
}

Then, after the timeout I see this (which is logged because I also set
NSScriptingDebugLogLevel to 1):

2012-08-23 21:26:36.347 iTerm[4819:707] Result: null

My openFile: method doesn't do anything besides return YES. Is there
something else I need to do to make the framework happy?

Thanks,
George
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:

NSNumberFormatter erases invalid values on Lion with 10.6 SDK

2011-11-04 Thread George Nachman
I just moved to XCode 4, from the Mac OS 10.5 SDK to the 10.6 SDK, and
from Snow Leopard to Lion. A behavior that changed is that entering
invalid text into an NSTextField with an NSNumberFormatter causes the
entire field's contents to be erased rather than disallowing the bogus
character from being added.

In my example, I have an NSNumberFormatter with a min value of 1, a
max value of 1000, isLenient, and localization on. Enter a value
like 123 and it's ok. Type a letter x and the entire value is
erased.

The erasure occurs when the field's stringValue or intValue is accessed.

The text field and number formatter are defined in a XIB file. I would
like invalid input to be prevented or at worst tolerated and ignored,
but erasing the whole value is really not OK.

Another strange thing that happens is that when entering a value
larger than 10,000 the entire value is erased. The text field's
-stringValue in the delgate's -controlTextDidChange: returns
@10, and immediately after being evaluated is changed to an
empty string.

Is this behavior intentional? Can I get the old behavior back somehow?

Thanks,
George
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com


NSBeep() blocks for some users

2011-07-19 Thread George Nachman
I've had a few users complain that if my app calls NSBeep() many times in
quick succession the program blocks until each of the beeps has played
sequentially. I can't reproduce this: on my system, NSBeep() returns
immediately and a subsequent call to NSBeep() will cause the sound to stop
and restart. Is there any reason why some machines would behave differently?

Thanks!
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com


Faster text drawing with configurable stroke width

2011-03-14 Thread George Nachman
Hi cocoa-dev,

I'm currently drawing text one character at a time with -[NSAttributedString
drawWithRect:options:], and it is really slow. I'm looking for a faster
alternative.

I draw one character at a time because I need exact control over horizontal
positioning (regardless of whether the font is monospaced or not, I force
characters onto a grid--this is non-negotiable) and I'm not aware of another
way to achieve this that also supports my second requirement:

I am using  -[NSAttributedString drawWithRect:options:]
instead CGContextShowGlyphsWithAdvances() or CTLineDraw() because it
supports NSStrokeWidthAttributeName. It also does a nice (but not as nice a
NSTextView) job at rendering combining marks.

My performance troubles are significant when there is a substantial amount
of new text, so caching layouts would do me little good. I suspect there
might be something lurking in NSLayoutManager/NSTypesetter/etc. that can
help me, but I haven't found it.

Thanks for your help,
George
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com


Re: Rendering combining marks

2011-01-05 Thread George Nachman
That's exactly what I needed, thanks!

On Mon, Jan 3, 2011 at 8:34 PM, Aki Inoue a...@apple.com wrote:
 -drawInRect: variant is designed for matching the field editor layout.

 -drawWithRect: variant is the base and should be used over the other two.

 Aki Inoue


 On 2011/01/03, at 16:45, George Nachman gnach...@llamas.org wrote:

 On Mon, Jan 3, 2011 at 1:47 PM, Wim Lewis w...@omnigroup.com wrote:

 On 2 Jan 2011, at 1:23 PM, George Nachman wrote:
 I'm using CGContextShowGlyphsWithAdvances to render fixed-width text
 because it is very fast. If a glyph is missing, I use
 CTFontCreateForString() to pick a better font, and that usually works.
 I ran into a case that I just can't solve with this technique [...]

 Do you need layout+rendering to be fast, or just rendering? If the latter, 
 for example if you're drawing a fixed string multiple times, you could use 
 a higher level routine to do the layout (e.g. CTTypesetterCreateLine() or 
 CTLineCreateWithAttributedString()) and then extract the glyphs, offsets, 
 so on from the typeset line to draw with CGContextShowGlyphsWithAdvances().

 (Actually I'd be surprised if CGContextShowGlyphsWithAdvances() is much 
 faster than CTLineDraw() --- I'd guess that simply caching the typeset line 
 will get you most of the available speedup.)

 It's rare that I have text that requires layout. 99% is plain old
 ASCII. It's not fixed text but I don't mind having a slower code path
 for more complex text.

 I tried using CTLineCreateWithAttributedString() and then rendering it
 with CTLineDraw() but it still fails to draw certain glyphs. For
 example, U+23B7: RADICAL SYMBOL BOTTOM appears as a box (the missing
 glyph symbol). It exists in the Apple Symbols font, but I guess it's
 just using the font I requested. If I use -[NSAttributedString
 drawInRect:], it can render the glyph, despite my specifying
 AndaleMono as the font. I wish I could do all my text drawing with
 -[NSAttributedString drawInRect:], but it is very slow. I tried using
 that call for only problem characters and
 CGContextShowGlyphsWithAdvances for normal characters, but I can't
 get the baselines to line up correctly (the attributed string draws a
 few pixels lower for some reason). If I could get the baselines to
 match up, this would be an ideal solution.

 Another smaller issue is that CTLineCreateWithAttributedString() +
 CTLineDraw() doesn't perform layout as nicely as -[NSAttributedString
 drawInRect:] in some edge cases. For instance, the sequence U+0061
 U+20D1 (where the latter is COMBINING RIGHT HARPOON ABOVE)  draws the
 diacritic through the top of the letter, while -[NSAttributedString
 drawInRect:] places it just above the letter.
 ___

 Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

 Please do not post admin requests or moderator comments to the list.
 Contact the moderators at cocoa-dev-admins(at)lists.apple.com

 Help/Unsubscribe/Update your Subscription:
 http://lists.apple.com/mailman/options/cocoa-dev/aki%40apple.com

 This email sent to a...@apple.com

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com


Re: Rendering combining marks

2011-01-03 Thread George Nachman
On Mon, Jan 3, 2011 at 1:47 PM, Wim Lewis w...@omnigroup.com wrote:

 On 2 Jan 2011, at 1:23 PM, George Nachman wrote:
 I'm using CGContextShowGlyphsWithAdvances to render fixed-width text
 because it is very fast. If a glyph is missing, I use
 CTFontCreateForString() to pick a better font, and that usually works.
 I ran into a case that I just can't solve with this technique [...]

 Do you need layout+rendering to be fast, or just rendering? If the latter, 
 for example if you're drawing a fixed string multiple times, you could use a 
 higher level routine to do the layout (e.g. CTTypesetterCreateLine() or 
 CTLineCreateWithAttributedString()) and then extract the glyphs, offsets, so 
 on from the typeset line to draw with CGContextShowGlyphsWithAdvances().

 (Actually I'd be surprised if CGContextShowGlyphsWithAdvances() is much 
 faster than CTLineDraw() --- I'd guess that simply caching the typeset line 
 will get you most of the available speedup.)

It's rare that I have text that requires layout. 99% is plain old
ASCII. It's not fixed text but I don't mind having a slower code path
for more complex text.

I tried using CTLineCreateWithAttributedString() and then rendering it
with CTLineDraw() but it still fails to draw certain glyphs. For
example, U+23B7: RADICAL SYMBOL BOTTOM appears as a box (the missing
glyph symbol). It exists in the Apple Symbols font, but I guess it's
just using the font I requested. If I use -[NSAttributedString
drawInRect:], it can render the glyph, despite my specifying
AndaleMono as the font. I wish I could do all my text drawing with
-[NSAttributedString drawInRect:], but it is very slow. I tried using
that call for only problem characters and
CGContextShowGlyphsWithAdvances for normal characters, but I can't
get the baselines to line up correctly (the attributed string draws a
few pixels lower for some reason). If I could get the baselines to
match up, this would be an ideal solution.

Another smaller issue is that CTLineCreateWithAttributedString() +
CTLineDraw() doesn't perform layout as nicely as -[NSAttributedString
drawInRect:] in some edge cases. For instance, the sequence U+0061
U+20D1 (where the latter is COMBINING RIGHT HARPOON ABOVE)  draws the
diacritic through the top of the letter, while -[NSAttributedString
drawInRect:] places it just above the letter.
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com


Rendering combining marks

2011-01-02 Thread George Nachman
Hi cocoa-dev,

I'm using CGContextShowGlyphsWithAdvances to render fixed-width text
because it is very fast. If a glyph is missing, I use
CTFontCreateForString() to pick a better font, and that usually works.
I ran into a case that I just can't solve with this technique: the
glyph for code point U+20d1 (COMBINING RIGHT HARPOON ABOVE) exists in
only one font on my system (Arial Unicode MS) and it is apparently not
in the global cascade list. I see that Terminal.app is somehow able to
correctly render this glyph (and it also uses
CGContextShowGlyphsWithAdvances when rendering such characters, at
least in part, as I can see from Activity Monitor's sampling). So I
think the trick is in finding out which font(s) have some glyph, but I
don't see an API to do this. Any ideas?

Thanks,
George
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com


Re: Cocoa-dev Digest, Vol 7, Issue 1076

2010-12-02 Thread George Nachman

 Message: 9
 Date: Tue, 23 Nov 2010 05:16:58 -0500
 From: Bill Cheeseman wjcheese...@gmail.com
 Subject: Re: Odd problem with event taps when job is killed
 To: Cocoa-Dev Mail Cocoa-Dev cocoa-dev@lists.apple.com
 Message-ID: 80e43f4f-a032-4452-bb1f-80f7b7bf7...@gmail.com
 Content-Type: text/plain;   charset=us-ascii


 On Nov 22, 2010, at 5:14 PM, George Nachman wrote:

  I recently added an event tap to my program. Since doing that, there is a
  strange behavior: when I kill my job (usually by making a change in Xcode
  and pressing cmd-Enter, being prompted to kill the job, and selecting
 OK),
  it will repeat back the last 10-20 keypresses as or after it dies


 You have to uninstall an event tap when you're through with it. Perhaps you
 aren't uninstalling it, and it lives on?

 Apple engineer Mike Paquette explained how to do this in messages to the
 quartz-dev mailing list on 2007-03-18 and 2008-02-12:

 CFMachPortInvalidate(tapMachPortRef); // switches off the event tap;
 invalidates tapRunLoopSourceRef, too, and drops retain counts on both by 1
 so the CFRelease will release the objects and not leak
 CFRunLoopRemoveSource(CFRunLoopGetCurrent(), tapRunLoopSourceRef,
 kCFRunLoopCommonModes);
 CFRelease(tapRunLoopSourceRef);
 CFRelease(tapMachPortRef);

 --

 Bill Cheeseman - b...@cheeseman.name




Apologies for the delay, I was on vacation.
I narrowed down the problem a bit, and that solution would not work. The
problem occurs when you do this:

1. Start program in debugger
2. Program registers an event tap
3. Break the program (for example, by choosing Pause from the Run menu in
Xcode, or pressing ^C in gdb)
4. Type some stuff
5. Kill the program
6. Everything you typed after step 5 is repeated by the ghost.

My program never has a chance to remove its event tap. Luckily this won't
affect users, so I guess I will shake my fist at the universe and move on :)
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com


Odd problem with event taps when job is killed

2010-11-22 Thread George Nachman
Hi cocoa-dev,

I recently added an event tap to my program. Since doing that, there is a
strange behavior: when I kill my job (usually by making a change in Xcode
and pressing cmd-Enter, being prompted to kill the job, and selecting OK),
it will repeat back the last 10-20 keypresses as or after it dies. For
example, if I do this:

1. Start my program
2. Switch back to Xcode and type foo in some source file.
3. Cmd-enter in Xcode
4. A dialog asks if I want to kill the job, say yes.
5. A ghost types foo in whatever window the cursor happens to be in.

This is on 10.6.4 and Xcode 3.2.3. I register the event tap like this:

   machPortRef = CGEventTapCreate(kCGHIDEventTap,

   kCGHeadInsertEventTap,

   kCGEventTapOptionListenOnly,

   CGEventMaskBit(kCGEventKeyDown),

   (CGEventTapCallBack)OnTappedEvent,

   self);

if (machPortRef) {

CFRunLoopSourceRef eventSrc;


eventSrc = CFMachPortCreateRunLoopSource(NULL, machPortRef, 0);

if (eventSrc == NULL) {

DebugLog(@CFMachPortCreateRunLoopSource failed.);

} else {

// Get the CFRunLoop primitive for the Carbon Main Event
Loop, and add the new event souce

CFRunLoopAddSource(CFRunLoopGetCurrent(), eventSrc,
kCFRunLoopDefaultMode);

CFRelease(eventSrc);

}

}


Even if my handler does nothing, it still exhibits this behavior:

   static CGEventRef OnTappedEvent(CGEventTapProxy proxy, CGEventType type,
CGEventRef event, void *refcon)

{

return event;

}


I couldn't find reports of anyone else having this problem, which usually
means I did something wrong :). Any ideas on what could cause this?

Thanks,
George
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com


Re: Adding and removing menu items causes memory usage to grow

2010-10-29 Thread George Nachman
That's it all right. Thank you for helping with your DELICIOUS BRAINS.

On Thu, Oct 28, 2010 at 9:39 PM, Synthetiq Solutions
con...@synthetiqsolutions.com wrote:
 George Nachman wrote:
 In trying to figure this out, I downloaded the binary distribution of
 my program that someone else built (before I took it over). That
 version does not leak. But if I check out the code they used and build
 my own deployment build, that does leak.

 What could be different about my build environment that would cause this?

 Do you have zombies enabled by any chance?  That could explain why your
 locally built version leaks.

 --
 Conrad Shultz

 Synthetiq Solutions
 www.synthetiqsolutions.com

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com


Re: Adding and removing menu items causes memory usage to grow

2010-10-28 Thread George Nachman
Thanks for the response, Sherm. I added the code as you suggested but
the leak persists. I originally discovered this issue because my
program would grow slowly over several days; the code I originally
posted was being called once a second from the event loop, which I
guess would allow the autorelease pools to be freed.

In trying to figure this out, I downloaded the binary distribution of
my program that someone else built (before I took it over). That
version does not leak. But if I check out the code they used and build
my own deployment build, that does leak.

What could be different about my build environment that would cause this?

On Wed, Oct 27, 2010 at 9:00 PM, Sherm Pendley sherm.pend...@gmail.com wrote:
 On Wed, Oct 27, 2010 at 12:45 PM, George Nachman gnach...@llamas.org wrote:

 I was tracking down memory growth in my application and isolated it to
 the repeated adding and removing of menu items. Doing this causes a
 growth of about 1MB:

    for (int i = 0; i  1000; ++i) {

        NSAutoreleasePool *myPool = [[NSAutoreleasePool alloc] init];

        NSMenu *aMenu = [[NSMenu alloc] init];
        NSMenuItem* i = [[NSMenuItem alloc] initWithTitle: @AAA
 action:nil keyEquivalent:@];
        [aMenu addItem:i];
        [i release];
        [aMenu removeItemAtIndex:0];
        [aMenu release];

        [myPool drain];

    }

 The Leaks instrument doesn't show any leaks. Allocations shows a whole
 bunch of different objects growing, but CFBasicHash is the worst
 offender, with lots of allocations in -[NSMenu insertItem:atIndex:]
 and -[NSMenu removeItemAtIndex:].

 At a guess, I'd say that -[NSMenu removeItemAtIndex:] autoreleases the
 removed item, and since you're in a loop here that doesn't pump the
 run loop, the autorelease pool isn't being drained. Try allocating an
 AR pool at the top of your loop, and sending it a -drain at the
 bottom, like I've added above.

 sherm--

 --
 Cocoa programming in Perl:
 http://camelbones.sourceforge.net

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com


Adding and removing menu items causes memory usage to grow

2010-10-27 Thread George Nachman
Hi cocoa-dev,

I was tracking down memory growth in my application and isolated it to
the repeated adding and removing of menu items. Doing this causes a
growth of about 1MB:

for (int i = 0; i  1000; ++i) {
NSMenu *aMenu = [[NSMenu alloc] init];
NSMenuItem* i = [[NSMenuItem alloc] initWithTitle: @AAA
action:nil keyEquivalent:@];
[aMenu addItem:i];
[i release];
[aMenu removeItemAtIndex:0];
[aMenu release];
}

The Leaks instrument doesn't show any leaks. Allocations shows a whole
bunch of different objects growing, but CFBasicHash is the worst
offender, with lots of allocations in -[NSMenu insertItem:atIndex:]
and -[NSMenu removeItemAtIndex:].

This is on OS 10.6.4. Am I doing something wrong?

Thanks,
George
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com