Re: NSMapTable with C strings as keys
On 5/29/13, Charles Srstka cocoa...@charlessoft.com wrote: On May 29, 2013, at 10:29 PM, Eric Wing ewmail...@gmail.com wrote: But I did do hash table benchmarks a few months back: http://playcontrol.net/opensource/LuaHashMap/benchmarks.html Perhaps off topic, but I wonder if it would be possible to alter your line charts so that those circles that appear periodically along the lines are actually a different shape for each line instead of always being circles. This wouldn't alter the visual appearance of the charts too much, and would make them much easier to read for those who suffer from colorblindness and thus have trouble differentiating using color alone (I particularly find it difficult to distinguish the Tcl line from the Python line in the chart at the top of the linked page without the use of Digital ColorMeter). I think it should be possible, but I didn't really understand the chart generation code. I was reusing tools from the original benchmark and tried not to spend as much time on it as I did. All the chart generation is done in HTML and the raw data points are actually embedded in the pages (they are not bitmap images). So all the original data is accessible/scrape-able from the page. -Eric -- Beginning iPhone Games Development http://playcontrol.net/iphonegamebook/ ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSMapTable with C strings as keys
On 5/29/13, Jens Alfke j...@mooseyard.com wrote: On May 29, 2013, at 8:29 PM, Eric Wing ewmail...@gmail.com wrote: CFDictionary I did not formally do in the benchmark, but I did run on the side for curiosity. I found that the C-string to CFString conversion ended up putting it at the bottom of the list in terms of performance. It seems unfair to include the C-string-to-object conversion time in the benchmark, if what you’re trying to measure is hash-table performance. Did you include that in the benchmarks for the other languages too? (And using real Unicode-savvy string objects — I know Python has both types)? —jens In my introduction, I was fairly adamant that time lost to impedance mis-match should be measured because my interest was real performance in using these libraries for projects based in C. That conversion time is non-trivial. And yes, all languages I benchmarked had to go through the same rules (i.e. deal with const char*). This is why C++ std::string actually did not fare so well compared to some of the other languages. (And the magical optimizer did not come to the rescue.) For Python, I was not aware of Unicode vs. other APIs. Since the focus was C, I wasn't really thinking about Unicode. I used PyDict_SetItemString to insert a string (the source code is linked on that page somewhere). Since I also did integer hash benchmarks, you can get an idea of pure hashing performance from those benchmarks since there is little conversion overhead in most of those cases. (The exception is Perl which seems to convert everything to strings which I did not expect.) -Eric -- Beginning iPhone Games Development http://playcontrol.net/iphonegamebook/ ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSMapTable with C strings as keys
Le 30 mai 2013 à 08:35, Eric Wing ewmail...@gmail.com a écrit : On 5/29/13, Jens Alfke j...@mooseyard.com wrote: On May 29, 2013, at 8:29 PM, Eric Wing ewmail...@gmail.com wrote: CFDictionary I did not formally do in the benchmark, but I did run on the side for curiosity. I found that the C-string to CFString conversion ended up putting it at the bottom of the list in terms of performance. It seems unfair to include the C-string-to-object conversion time in the benchmark, if what you’re trying to measure is hash-table performance. Did you include that in the benchmarks for the other languages too? (And using real Unicode-savvy string objects — I know Python has both types)? —jens In my introduction, I was fairly adamant that time lost to impedance mis-match should be measured because my interest was real performance in using these libraries for projects based in C. That conversion time is non-trivial. And yes, all languages I benchmarked had to go through the same rules (i.e. deal with const char*). This is why C++ std::string actually did not fare so well compared to some of the other languages. (And the magical optimizer did not come to the rescue.) For Python, I was not aware of Unicode vs. other APIs. Since the focus was C, I wasn't really thinking about Unicode. I used PyDict_SetItemString to insert a string (the source code is linked on that page somewhere). I follow Jens on this one. Nothing prevent you to use CFDictionary with a C string directly or any other type. You don't have to create CFString. -- Jean-Daniel ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSMapTable with C strings as keys
On 30 May 2013, at 12:33, Jens Alfke j...@mooseyard.com wrote: On May 29, 2013, at 6:30 PM, Ian Joyner ianjoy...@me.com wrote: That seems to come out of a belief that well-structured code is code that runs poorly No, it’s a paraphrase of a famous quote by Don Knuth (We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.”[1]) He later attributed this to C.A.R. Hoare. OK, thanks, it was badly put on my part. I have Knuth's paper and will give it another read (after rereading Structured Programming (Dahl, Dijkstra, Hoare) which Knuth says will change your life). What I am trying to point out though is that there is a misapprehension that premature optimization means writing structured code early on so don't structure it because you can always go and clean it up later. Rather I think we should write well-structured code as we go. Often that will result in efficient code (invariant statements not being in loops, etc), but that is not what is meant by premature optimization. This kind of optimization is more about changing the algorithm than the code. We should beware not to lump well-structured code writing with premature optimization just because well-structured code usually ends up being optimized code. Well-structured code also ends up being more correct and more easily changed and refactored. ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Dismissing menu from menu item that uses custom view
I previously assumed I could simply draw my view a couple times with a delay
between, to simulate the quick flash that a menu item does when you choose it.
Of course, so many things have to be difficult in the world of Cocoa. I assume
drawing can't get flushed to the screen until control is returned to the
tracking event loop? What I came up with works, but seems ridiculously
inelegant. Is there some better way to give the current event loop time so I
can have the drawing and canceling done right in my mouseUp handler?
-(void) mouseUp:(NSEvent*)event
{
UNUSED_VAR(event);
NSMenuItem* item = [self enclosingMenuItem];
NSMenu* menu = [item menu];
// Flash the menu item off and back on just like real ones:
[self performSelector:@selector(flashOff:) withObject:menu
afterDelay:0.05 inModes:[NSArray arrayWithObject:NSEventTrackingRunLoopMode]];
}
-(void) flashOff:(NSMenu*)menu
{
isHilited = NO;
[self display];
[self performSelector:@selector(flashOn:) withObject:menu
afterDelay:0.05 inModes:[NSArray arrayWithObject:NSEventTrackingRunLoopMode]];
}
-(void) flashOn:(NSMenu*)menu
{
isHilited = YES;
[self display];
[self performSelector:@selector(cancelMenu:) withObject:menu
afterDelay:0.05 inModes:[NSArray arrayWithObject:NSEventTrackingRunLoopMode]];
}
-(void) cancelMenu:(NSMenu*)menu
{
[menu cancelTracking];
[self performSelector:@selector(delayedSendAction:) withObject:nil
afterDelay:0 inModes:[NSArray arrayWithObjects:NSEventTrackingRunLoopMode,
NSDefaultRunLoopMode, nil]];
}
-(void) delayedSendAction:(id)obj
{
UNUSED_VAR(obj);
// Then send the action to the target:
NSMenuItem* item = [self enclosingMenuItem];
SEL act = [item action];
id targ = [item target];
if(act != nil targ != nil)
[NSApp sendAction:act to:targ from:item];
}
--
Steve Mills
office: 952-818-3871
home: 952-401-6255
cell: 612-803-6157
___
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: NSMapTable with C strings as keys
On May 30, 2013, at 3:52 AM, Ian Joyner ianjoy...@me.com wrote: What I am trying to point out though is that there is a misapprehension that premature optimization means writing structured code early on so don't structure it because you can always go and clean it up later. Rather I think we should write well-structured code as we go. I agree 100% with that. Structured code is easier to benchmark and optimize later on, anyway — as I said, if you repeat a piece of code ten times, none of the ten instances may show up individually as hot spots, whereas if you called a common function/method in ten places, it may show up and then be easy to fix. I would add, though, that the perfect structure (class hierarchy, API, factoring…) may not be apparent right away, especially since you’ll often end up refactoring as you go along. So trying too hard to structure code as you’re initially writing it can end up being a rathole. —Jens ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSMapTable with C strings as keys
On May 29, 2013, at 11:35 PM, Eric Wing ewmail...@gmail.com wrote: In my introduction, I was fairly adamant that time lost to impedance mis-match should be measured because my interest was real performance in using these libraries for projects based in C. That conversion time is non-trivial. If you’re coding in C, I don’t think it makes sense to consider other languages (except maybe C++) just for their hashtable implementations! There’s inevitably going to be impedance mismatch: not just with data conversion but also memory management, since most of the languages you tested are garbage collected. That means you now have two heaps (a GC heap embedded inside your malloc heap) and extra memory usage and cost for running the GC. Not to mention the bloat on your app’s code size. Surely there are enough reusable C-based hashtable libraries that you don’t need to embed a whole Lua or Python interpreter just for that purpose. (And if not, it’s really easy to write one.) —Jens ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSMapTable with C strings as keys
On May 30, 2013, at 3:52 AM, Ian Joyner ianjoy...@me.com wrote: What I am trying to point out though is that there is a misapprehension that premature optimization means writing structured code early on so don't structure it because you can always go and clean it up later. Rather I think we should write well-structured code as we go. I agree 100% with that. Structured code is easier to benchmark and optimize later on, anyway — as I said, if you repeat a piece of code ten times, none of the ten instances may show up individually as hot spots, whereas if you called a common function/method in ten places, it may show up and then be easy to fix. I would add, though, that the perfect structure (class hierarchy, API, factoring…) may not be apparent right away, especially since you’ll often end up refactoring as you go along. So trying too hard to structure code as you’re initially writing it can end up being a rathole. —Jens ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSMapTable with C strings as keys
On 5/30/13, Jens Alfke j...@mooseyard.com wrote: On May 29, 2013, at 11:35 PM, Eric Wing ewmail...@gmail.com wrote: In my introduction, I was fairly adamant that time lost to impedance mis-match should be measured because my interest was real performance in using these libraries for projects based in C. That conversion time is non-trivial. If you’re coding in C, I don’t think it makes sense to consider other languages (except maybe C++) just for their hashtable implementations! There’s inevitably going to be impedance mismatch: not just with data conversion but also memory management, since most of the languages you tested are garbage collected. That means you now have two heaps (a GC heap embedded inside your malloc heap) and extra memory usage and cost for running the GC. Not to mention the bloat on your app’s code size. Surely there are enough reusable C-based hashtable libraries that you don’t need to embed a whole Lua or Python interpreter just for that purpose. (And if not, it’s really easy to write one.) —Jens So that's all in the introduction too. But that's all conjecture. Performance tuning requires actual measurement/benchmarking. The question was to put it to the test. The results most people found surprising because a lot of conventional wisdom did not hold up. -Eric -- Beginning iPhone Games Development http://playcontrol.net/iphonegamebook/ ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
App store reject on asl log. How else do I get at the log messages?
Hi, My app was rejected from the store because I wanted the entitlement: com.apple.security.temporary-exception.files.absolute-path.read-only - /private/var/log/asl/ I need this so I can use the asl_new, asl_set_query, asl_search, aslresponse_next, asl_get, and aslresponse_free to be able to get the log messages for my application when people submit a bug report. The app store rejection told me that I need to investigate other ways of implementing the desired functionality. Are there other ways of getting at the console log entries for my app so I can get them sent to me with bug reports? Regards Gideon ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: App store reject on asl log. How else do I get at the log messages?
Not sure if this meets sandboxing requirements, but you can redirect the
console log in main.c:
freopen([APP_LOG_PATH fileSystemRepresentation], a, stderr);
Surround this in @autoreleasepool{} if you need ARC memory management to create
your path string.
On 2013-05-30, at 5:46 PM, Gideon King gid...@novamind.com wrote:
Hi,
My app was rejected from the store because I wanted the entitlement:
com.apple.security.temporary-exception.files.absolute-path.read-only -
/private/var/log/asl/
I need this so I can use the asl_new, asl_set_query, asl_search,
aslresponse_next, asl_get, and aslresponse_free to be able to get the log
messages for my application when people submit a bug report.
The app store rejection told me that I need to investigate other ways of
implementing the desired functionality.
Are there other ways of getting at the console log entries for my app so I
can get them sent to me with bug reports?
Regards
Gideon
___
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:
https://lists.apple.com/mailman/options/cocoa-dev/dave.fernandes%40utoronto.ca
This email sent to dave.fernan...@utoronto.ca
___
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Dismissing menu from menu item that uses custom view
On 30/05/2013, at 11:49 PM, Steve Mills smi...@makemusic.com wrote:
Is there some better way to give the current event loop time so I can have
the drawing and canceling done right in my mouseUp handler?
Have you looked at -nextEventMatchingMask:untilDate:inMode:dequeue:? As in:
NSEvent *event;
while ((event = [NSApp nextEventMatchingMask:NSAnyEventMask
untilDate:nil inMode:NSDefaultRunLoopMode dequeue:YES]))
{
[NSApp sendEvent: event];
event = nil;
}
--
Shane Stanley sstan...@myriad-com.com.au
'AppleScriptObjC Explored' www.macosxautomation.com/applescript/apps/
___
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Dismissing menu from menu item that uses custom view
On Thu, May 30, 2013, at 06:49 AM, Steve Mills wrote: I assume drawing can't get flushed to the screen until control is returned to the tracking event loop? What I came up with works, but seems ridiculously inelegant. Is there some better way to give the current event loop time so I can have the drawing and canceling done right in my mouseUp handler? I would argue that attempting to flush the screen yourself is the far more inelegant approach. Screen flushing and compositing is handled by an external process; the system drives repainting, not your app. Yes, -performSelector:afterDelay: is slightly smelly, but much less so that trying to force the compositing engine to fake drawing menu selection. --Kyle Sluder ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSMapTable with C strings as keys
On 31 May 2013, at 01:43, Jens Alfke j...@mooseyard.com wrote: On May 30, 2013, at 3:52 AM, Ian Joyner ianjoy...@me.com wrote: What I am trying to point out though is that there is a misapprehension that premature optimization means writing structured code early on so don't structure it because you can always go and clean it up later. Rather I think we should write well-structured code as we go. I agree 100% with that. Structured code is easier to benchmark and optimize later on, anyway — as I said, if you repeat a piece of code ten times, none of the ten instances may show up individually as hot spots, whereas if you called a common function/method in ten places, it may show up and then be easy to fix. I would add, though, that the perfect structure (class hierarchy, API, factoring…) may not be apparent right away, especially since you’ll often end up refactoring as you go along. So trying too hard to structure code as you’re initially writing it can end up being a rathole. Absolutely. It's often the case that we try to get everything ultra-structured before writing any code. This can be a writer's block. We often have to use the process of coding as an exploratory process. That is the very essence of software. It also means that software can be refined as we go. But often we need to know when to stop. Structured (and OO) languages directly support the paradigms. This seems not well understood since we attempt to structure code (code is a term I don't like) by the use of diagrams because we treat the act of programming as translating this into a machine-oriented artefact. But in fact a text-based programming language is often more malleable than such diagrams (in terms of both tool and mental attitudes that a diagram is fixed, even if a programmer comes up with better designs). ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Dismissing menu from menu item that uses custom view
On May 30, 2013, at 18:44:46, Shane Stanley sstan...@myriad-com.com.au wrote:
Have you looked at -nextEventMatchingMask:untilDate:inMode:dequeue:? As in:
NSEvent *event;
while ((event = [NSApp nextEventMatchingMask:NSAnyEventMask
untilDate:nil inMode:NSDefaultRunLoopMode dequeue:YES]))
{
[NSApp sendEvent: event];
event = nil;
}
Just tried it. Didn't work. I also used NSEventTrackingRunLoopMode, since
that's the current run loop when tracking a menu. I wish Apple had more people
on these lists that can give definitive answers to our questions. It sure would
help to know how Apple does it, or even better, be able to call something like
[menuItem flashAndCancelTracking].
--
Steve Mills
office: 952-818-3871
home: 952-401-6255
cell: 612-803-6157
___
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Dismissing menu from menu item that uses custom view
On Thu, May 30, 2013, at 08:30 PM, Steve Mills wrote: Just tried it. Didn't work. I also used NSEventTrackingRunLoopMode, since that's the current run loop when tracking a menu. I wish Apple had more people on these lists that can give definitive answers to our questions. It sure would help to know how Apple does it, or even better, be able to call something like [menuItem flashAndCancelTracking]. It's done in a private 64-bit reimplementation of the Carbon Menu Manager that spins its own nested event loop (which you can see in a backtrace) and then sends the action. Seriously. Just use -performSelector:afterDelay:. --Kyle Sluder ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
