NSView.alphaValue without Core Animation Layer?
Hi, the documentation for -[NSView setAlphaValue:] states: Sending this message to a view that is not managing a Core Animation layer causes an exception. But experiment under 10.6 shows that not only no exception is thrown, setting the alpha value on views without Core Animation layer even works just fine. Is this a feature of Snow Leopard we can dependent upon? We were not able to find it documented, not even in the AppKit release notes for 10.6. Thanks Kai ___ 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
-[NSDateFormatter dateFormatFromTemplate:options:locale:] does not work as expected
Hi, I am having problems using -[NSDateFormatter dateFormatFromTemplate:options:locale:] (new in 10.6.). It’s a great API which makes world-savvy custom date formats possible. Unfortunately it does not seem to work. Examples of wrong results are: - Hour format templates like h a (12 Hour with AM/PM) are converted to format H (24 Hour) under US locale. Other combinations (ha , h, H under US or German locale) also always return H. - The template EEyMd is converted to format EE, -M-d under German locale. This is completely wrong, expected would be EE, d.M.. I filed a bug under rdar://7803429. Does anybody have similar experiences with this method? Any work around to make it work? - Kai - Test code: The following code: NSLocale* usLocale = [[NSLocale alloc] initWithLocaleIdentifier:@en-US]; NSLocale* germanLocale = [[NSLocale alloc] initWithLocaleIdentifier:@de-DE]; NSString* format = [NSDateFormatter dateFormatFromTemplate:@h a options:0 locale:usLocale]; NSLog (@Template “h a” with US local results in �...@”, format); format = [NSDateFormatter dateFormatFromTemplate:@H options:0 locale:usLocale]; NSLog (@Template “H” with US local results in �...@”, format); format = [NSDateFormatter dateFormatFromTemplate:@h options:0 locale:usLocale]; NSLog (@Template “h” with US local results in �...@”, format); format = [NSDateFormatter dateFormatFromTemplate:@h a options:0 locale:germanLocale]; NSLog (@Template “h a” with German local results in �...@”, format); format = [NSDateFormatter dateFormatFromTemplate:@H options:0 locale:germanLocale]; NSLog (@Template “H” with German local results in �...@”, format); format = [NSDateFormatter dateFormatFromTemplate:@EEyMd options:0 locale:germanLocale]; NSLog (@Template “EEyMd” with German local results in �...@”, format); gives me this output: Template “h a” with US local results in “H” Template “H” with US local results in “H” Template “h” with US local results in “H” Template “h a” with German local results in “H” Template “H” with German local results in “H” Template “EEyMd” with German local results in “EE, -M-d” ___ 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: #define and if statements
A tip for the next time you have problems with macros: use Xcode’s Preprocess
command (in the Build menu) to see your macros resolved. Helps a lot in such
cases.
Kai
On 27.2.2010, at 07:37, Adam Gerson wrote:
Thanks! I can't believe I missed that. Its 1:35am here and its been a long
day.
Adam
On Sat, Feb 27, 2010 at 1:24 AM, Dave DeLong davedel...@me.com wrote:
#define's are basically a simple find and replace, so if you do:
#define IsDemo NO;
and then do:
if (IsDemo) { ... }
It's going to become:
if (NO;) { ... }
See the problem? You've got a semicolon in there. Generally, you don't end
a #define with a semicolon unless you want a semicolon in the place where
the #define will be used.
Dave
On Feb 26, 2010, at 11:22 PM, Adam Gerson wrote:
I have the following constant set up. I have tried all three of these
variations and none of them work in an if statement in cocoa. I get
error: expected `)' before ';' token
#define IsDemo NO;
#define IsDemo false;
#define IsDemo 0;
if (IsDemo) {
bla...
}
Same problem, when I try:
#define FreeUpdateDaysAllowed 180;
if (daysSoFar FreeUpdateDaysAllowed)
What am I doing wrong? Whats the right way to have a bool or int constant?
Thanks,
Adam
___
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/davedelong%40me.com
This email sent to davedel...@me.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/lists%40kai-bruening.de
This email sent to li...@kai-bruening.de
___
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: -[NSBundle preferredLocalizations]
Done: rdar://7637393 Kai On Feb 10, 2010, at 5:52 AM, Kai Brüning wrote: Could somebody with insight confirm whether this is a documentation bug? This is indeed an error in the documentation. Please file a bug against the documentation with the information you have provided. Douglas Davidson ___ 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
-[NSBundle preferredLocalizations]
Hi,
Apple’s documentation states about -[NSBundle preferredLocalizations]: The
localizations in the array are not returned in any particular order.
This makes no sense, I’d expect this to be true for -[NSBundle localizations],
why I’d expect -[NSBundle preferredLocalizations] to be implemented similar to
the following:
- (NSArray*) preferredLocalizations
{
return [NSBundle preferredLocalizationsFromArray:self.localizations];
}
and the docu of -[NSBundle preferredLocalizationsFromArray:] says: These
strings are ordered in the array according to the current user's language
preferences.
Could somebody with insight confirm whether this is a documentation bug?
(Sure, I could check the actual order. But if the documentation is correct, the
result would be meaningless for the future.)
Thanks
Kai
___
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: Use NSDocument as a variable of another NSDocument
On 18.1.2010, at 23:17, Jarod Wen wrote: Good points guys! In my application the table data depends on the movie it comes from. And also, there will be several tables for one movie (for example, one is for the video information and the other is about the audio information). The reason why I want to select the document architecture is because all the table data can be edited by the user, and finally, these data should be able to save onto the disk as text for further usage. Maybe a wrapped file for both the movie and the tables will be a better choice? In this way I think a NSDocument for the movie and then a list of table controllers will be better? I’d say you are starting to approach it from the right side now: consider how your application should be structured document-wise as the user sees it. After you got a clear picture, mapping this to AppKit concepts is the second step. Concerning NSDocument, this is very much tied to what the user sees as a document: something visible in the Finder which can be double-clicked, edited, saved again and so on. So you’ll have to decide whether your tables are documents in their own right or whether the save onto the disk as text for further usage is an export. In the later case you would have a single document which is able to export tables as text files (or Excel or Numbers or HTML, you name it). Hope this helps a little Kai Thanks! On Jan 18, 2010, at 1:59 PM, Jeffrey Oleander wrote: At Mon, 2010/01/18 15:19, Quincey Morris quinceymor...@earthlink.net wrote: On 2010 Jan 18, at 10:48, Jarod Wen wrote: Is it a proper design to use a NSDocument as a variable of another NSDocument? I am now working on an application which generates some information from a movie. The information generated will be showed as a table, and the information in the table can be saved/opened. Multiple types of information are possible so for one movie there may be several tables. I used the NSDocument architecture for the movie document, and I am a little bit confused about the hierarchy... The question isn't whether one document object can contain a reference to another document object. The question is what's supposed to happen later when the derived (table) document is re-opened. If the table refers to information in the original (movie) document, you'll need to open the movie document too. That depends on what you mean by refers to. I can refer to the Encyclopedia Brittanica without opening it. I can say this is related to the movie 'Blah' whose screen- play was written by Blurp, was direced by Blorp, and produced by Bloop without having to open up that movie file. It just depends on what Jarod Wen wants to do. If he wants the extracted data which he displays in tables to be mostly independent of the original movie, then he will need that to be in a document with its own hierarchy. The original movie would be one document with its own data, and the extracted data for that movie might be a separate document with its own, independent data hierarchy. If he does that, then the 2 files can diverge, and he might have to consider how to control proliferation of related data files, each derived from the same movie file. So, his question becomes, what object owns each document type? What object owns the movie? What object owns the derived data that he displays as tables? Or, should he just keep only the movie document and extract/generate at run- time the data to display in table views as views of the movie. ___ 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/jarodwen%40gmail.com This email sent to jarod...@gmail.com -- J.W. ___ 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/lists%40kai-bruening.de This email sent to li...@kai-bruening.de ___ 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: Why is [NSArray arrayWithObjects:] failing for me?
On 4.1.2010, at 13:44, Charles Jenkins wrote: Thank you to all who offered your expertise! Whatta dumb mistake! I thought all objects were retained once when created, not auto-released. Gah! I've been programming for 20+ years--mostly with C++ and C#. Cocoa-ObjC has the steepest learning curve of any programming I have ever done. Strange that you feel so. I’d say C++ is way more complex - although I did 20+ years of C++ coding and only 2 of ObjC/Cocoa. But in any case you can take the whole retain/release problem out of your learning curve by switching to GC - unless you are targeting the iPhone. It makes me feel like an idiot, so you can certainly expect to see more of these noobish questions from me... Thanks in advance for your help and patience! Kai___ 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: Why is [NSArray arrayWithObjects:] failing for me?
On 4.1.2010, at 13:58, Charles Jenkins wrote: On 2010-01-03 00:08, Eric Smith wrote: Correct, do not release the array. If you don't create it with init, or retain it, then you should not release it. Eric, thank you for stating that rule. It should be easy enough to remember and help me avoid this problem in the future. In my defense, there seems to be a bug in the latest XCode, which make strings stored in NSArrays look like garbage when inspected during debugging. So the elements of pnl appeared to be trashed immediately upon creation. That's why I was looking for the bug in the wrong place. Yes, the data formatters in the debugger do not always work. Typing po object (e.g. po [pnl objectAtIndex:0]) normally works. po stand for print object. Does anyone else find XCode extremely buggy? Not at all. For me Xcode is extremely robust and a lot of fun to use. I use the latest version under Snow Leopard, but it was mostly the same under Leopard, too. My impression was that Xcode gained a lot of robustness when it was switched to GC. I have to continually close and reopen my editing window because the code display gets trashed and appears to scramble my code. It doesn't really change the source code file; it just makes it look as if I've randomly gone through the file deleting stuff, and when I see that happen, I immediately save, close, and reopen the window, and everything is fine. Sounds scary, i’ve never seen this. Mac software is usually first class, stable, and beautiful. How do folks write such great software when they're stuck with such a sub-par IDE? :-) They aren’t. There must be something very special with your setup. Best Kai ___ 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: Program not working under Snow Leopard
On 28.12.2009, at 13:07, Quincey Morris wrote: On Dec 27, 2009, at 07:23, insanely...@mac.com wrote: I'm working on a program that manages file downloads via NSURLConnection. I was developing under Leopard and the program was working just fine. I've switched to a new computer running Snow Leopard with the latest Xcode. My program now crashes with the ever popular EXEC_BAD_ACCESS error at seemingly random points. At first it was consistently crashing when I was attempting to reference the value in an NSDate variable (via NSLog). So I commented that line out and then it crashed with the same error on a different variable. Also, I can run the program just fine in the debugger with it set to Debug. Once it's set to Release it crashes. I've confirmed the settings are identical for Debug/Release. And as I said, this code worked fine in Leopard. No one can say the cause without further evidence. However, given the symptoms, the *high probability* is that: 1. You have a memory management bug in your code. 2. It never showed up under Leopard by pure luck. Since you switched computers together with the OS, there’s another possibility: is your old computer by chance single-core? And do you have any threading in your code? If so, threading bugs tend to be much worse under multi-core because you are introducing real parallelism. Good luck Kai ___ 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: App works when launched from Xcode, not from Finder
On 18.12.2009, at 15:54, PCWiz wrote:
Yeah I definitely need to squash this bug. But as Greg Parker said,
@synchronized (which I'm using) has nothing to do with NSRecursiveLock. And
the only other threading related classes I'm using are NSOperationQueue and
NSInvocationOperation. Would one of these classes use NSRecursiveLock?
Possibly in Leopard, but very unlikely under Snow Leopard: NSOperationQueue is
now based on Grand Central.
I am positive that I'm not directly using NSRecursiveLock or NSLock anywhere
in my project.
Have you tried to break on [NSRecursiveLock alloc]? Or on one of the init
methods?
Kai
Independent Cocoa Developer, Macatomy Software
http://macatomy.com
On 2009-12-18, at 12:07 AM, Kai Brüning wrote:
Great you found this issue.
But according to the log output, it seems that you do have a serious
threading-related problem. I wouldn’t ignore this, it may raise its head any
time in the future and bite you badly.
Good luck
Kai
On 18.12.2009, at 03:26, PCWiz wrote:
Thanks, will do.
And regarding Jeremy's note about the 2 libraries can't be loaded, those
are Input Manager plugins that have nothing to do with my app.
But I'm happy to say that I eventually found the cause of my problem. One
of the frameworks I was using was compiled using i386 ppc set as the
architecture. Setting this to Standard (32-bit/64-bit Universal) and
recompiling the framework fixed it. Xcode seems to launch the app in 32 bit
mode whether its in Debug or Release (because I have the Active
Architecture set to i386). When launched from Finder, the app launches in
64 bit mode, and since that framework was not compiled with the x86_64
architecture it screwed up the app.
Hope this helps anyone else that runs into this issue.
Independent Cocoa Developer, Macatomy Software
http://macatomy.com
On 2009-12-17, at 9:55 AM, Jens Alfke wrote:
On Dec 16, 2009, at 10:04 PM, PCWiz wrote:
I'm not using NSLock or NSRecursiveLock directly. I'm using @synchronized
on an object that multiple threads acess, to allow only one thread to
access the object at a time.
The fact that the description of the lock is NSRecursiveLock: 0x16c2340
'(null)' makes me suspect that you're synchronizing on a nil pointer,
i.e. that when you call
@synchronized(foo) { ... }
the value of foo is nil. I'm pretty sure that's illegal, and I would have
thought it would throw an exception, but maybe not. Try putting a check
above the block, something like
NSAssert(foo!=nil, @no foo);
—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:
http://lists.apple.com/mailman/options/cocoa-dev/lists%40kai-bruening.de
This email sent to li...@kai-bruening.de
___
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: App works when launched from Xcode, not from Finder
Great you found this issue.
But according to the log output, it seems that you do have a serious
threading-related problem. I wouldn’t ignore this, it may raise its head any
time in the future and bite you badly.
Good luck
Kai
On 18.12.2009, at 03:26, PCWiz wrote:
Thanks, will do.
And regarding Jeremy's note about the 2 libraries can't be loaded, those are
Input Manager plugins that have nothing to do with my app.
But I'm happy to say that I eventually found the cause of my problem. One of
the frameworks I was using was compiled using i386 ppc set as the
architecture. Setting this to Standard (32-bit/64-bit Universal) and
recompiling the framework fixed it. Xcode seems to launch the app in 32 bit
mode whether its in Debug or Release (because I have the Active Architecture
set to i386). When launched from Finder, the app launches in 64 bit mode, and
since that framework was not compiled with the x86_64 architecture it screwed
up the app.
Hope this helps anyone else that runs into this issue.
Independent Cocoa Developer, Macatomy Software
http://macatomy.com
On 2009-12-17, at 9:55 AM, Jens Alfke wrote:
On Dec 16, 2009, at 10:04 PM, PCWiz wrote:
I'm not using NSLock or NSRecursiveLock directly. I'm using @synchronized
on an object that multiple threads acess, to allow only one thread to
access the object at a time.
The fact that the description of the lock is NSRecursiveLock: 0x16c2340
'(null)' makes me suspect that you're synchronizing on a nil pointer, i.e.
that when you call
@synchronized(foo) { ... }
the value of foo is nil. I'm pretty sure that's illegal, and I would have
thought it would throw an exception, but maybe not. Try putting a check
above the block, something like
NSAssert(foo!=nil, @no foo);
—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:
http://lists.apple.com/mailman/options/cocoa-dev/lists%40kai-bruening.de
This email sent to li...@kai-bruening.de
___
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: Migrating changed objects between contexts
On 2.12.2009, at 18:27, Jim Thomason wrote: It shouldn't deadlock. The doc for -lock says: If you lock (or successfully tryLock) a managed object context, the thread in which the lock call is made must have a retain until it invokes unlock. If you do not properly retain a context in a multi-threaded environment, this will result in deadlock. Did you heed it? It didn't matter one way or the other. Incidentally, I've seen that warning too, but in this case I was sharing the [document managedObjectContext] across threads, so it was guaranteed to exist as long as the window was open. So I take it that you have code in place that postpones window closing while your background thread works with the context? What was the need to retain it in that case, anyway? To safe writing above code. Sigh. Nevermind, I'm an idiot. My worker thread that refreshes my graph does 3 different things in it. 1 is fairly old and has been around for months, the other 2 things are newly added. The original one ended up calling rearrangeObjects on an array controller, and since that's not threadsafe (right?) I dispatched the call to the main thread, and helpfully set waitUntilDone:YES. That was fine originally, since the app was guaranteed not to be looking at the context in the main thread, and basically I got lucky and could get away with it. But now, due to additional processing in the main thread, it was looking at the context. So my worker thread would happily chug along until it reached the rearrangeObjects call. It'd hand it off to the main thread and wait for it to finish. But the main thread was paused since my worker thread had the lock on the context. And blamo. Deadlock. Solution? Disturbingly easy to see now 12 hours into trying to fix it. Just do the rearrangeObjects on the main thread as before, but set waitUntilDone:NO. All problems miraculously fixed. And an important lesson learned: blocking or waiting in any way while holding a lock is a dangerous thing to do. Kai ___ 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: My try/catch block isn't catching exceptions on 10.6
On 28.11.2009, at 13:57, Gwynne Raskind wrote:
On Nov 28, 2009, at 4:25 AM, Greg Parker wrote:
Here's a fun idiom for handling both C++ and Objective-C exceptions in the
same place (on iPhone and 64-bit Mac).
@try {
// do stuff
} @catch (NSException *e) {
// NSException
} @catch (id e) {
// Other Objective-C exception
} @catch (...) {
// Non-ObjC exception
// Decode it by rethrowing it inside a C++ try/catch.
try {
@throw;
} catch (std::bad_cast e) {
// C++ failed dynamic cast to reference type
} catch (...) {
// Other C++ exception
// or non-ObjC non-C++ foreign exception
}
}
I apologize if this is a dense question, but can't you just go like this?
@try {
// do stuff
} @catch (NSException *e) {
// NSException
} @catch (id e) {
// Other Objective-C exception
} @catch (std::bad_cast e) {
// C++ failed dynamic cast to reference type
} @catch (...) {
// Other C++ exception
// or non-ObjC non-C++ foreign exception
}
No - there’s a syntactically subtle but important difference above between
@try/@catch and try/catch, the further being the Objective-C variant, the later
C++.
Kai
___
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: Should I learn CoreData for this project?
On 4.11.2009, at 11:33, Ruotger Skupin wrote: more disadvantages to mention: 1. schema updates with every model change if you use an sql store (you have to make a mapping for every single from version/ to version combination you need to support) In Snow Leopard Core Data does this automatically for simple cases. For non-simple cases you would have to write code for migration of non- Core Data documents, too. 2. multithreaded core data is very hard to get right (multiple contexts, data merges) Isn’t this true for multi threaded code in general? Seriously, the documentation explains how to structure multi threaded use of Core Data. This might even save you some pitfalls compared with a naive approach to multi-threading a model. 3. performance tuning of core data often means making your schema more complex (see also point 1) Probably irrelevant for the task at hand. 4. debugging core data can be hard (most bugs only get to the surface when you try to save your data). Sure, you have more black box behavior compared to a hand crafted model. Helps to go by the recommendations in the documentation and avoid anything which smells like a hack. 5. core data throws exceptions all over the place so you may end up with a try-catch block with every data access in your code Not my experience. As with the whole of Cocoa, exceptions in Core Data indicate programmer errors, which should be fixed before releasing. If your data set fits in memory and you don't mind loading it all at once, stay away from core data. my two cents Ruotger On 04.11.2009, at 08:54, Kai Brüning wrote: Hi David, this question is most definitely on topic :-) So, lets see, what would Core Data give you: - Scalability, fast incremental loads and saves for big data sets. I don’t think you’ll need this. Loading and saving 500 items each time will be fast enough. - A data model modeler. That’s actually more valuable then it may seem on first glance. I often look at my Core Data models when thinking about algorithms and want to recap how the object graph looks. - Automatic and semi-automatic version migration. Depends on the lifecycle of your application. When needed, it’ll save you tons of time. - Object graph consistency management. A big one. Core Data automatically updates inverse relationships as needed. A lot of work to do manually, and always a source of subtle bugs. - Automatic undo support. Big - Disadvantage: Core Data does not support ordered relationships. That is, it uses sets instead of arrays. If you need an order, you have to manage this yourself. Not hard, but sometimes an annoyance (the reason for this shortcoming are hard technical problems). That’s it out of my head. I’m sure I forgot something. The learning effort? Hard to say. Core Data is well documented and works (almost always) as advertised. So it depends on how well you learn new abstractions. One unrelated advice: by all means use garbage collection. It makes object graph management (and a lot of other things) so much easier, no matter whether you use Core Data or not. Good luck! Kai On 4.11.2009, at 05:22, David Hirsch wrote: So, I'm hearing folks sing the praises of CoreData, which I have not yet learned. It seems like a long uphill climb, but if life will be spectacular afterwards, I'll do it. I am a semi-casual programmer; I've just finished a couple of small programs that do not use CoreData, and I can see the advantage in gaining open/save and undo/redo for free, but I'm concerned about the work I'll have to put in to learn it. I've read a bunch of the CoreData intro documentation, but it doesn't give a feel for how difficult it will be to learn, nor how big the advantages are if I do. Here's the next project I'm going to work on, for which I'm considering CoreData: A simulated annealing code for class scheduling. The CoreData part would lie in managing all the lists involved: classes, rooms, instructors, preferences, conflict cost weights, etc. I estimate that I will have about 500 items spread over about 10 arrays. I would not expect to have a complex object graph (if that's the right term) - just a lot of items in lists, items that need to be managed, displayed, saved, loaded, etc. I could use NSArrays for all these, which I currently understand. Does this sound like it's worth learning CoreData for? Thanks, Dave S.A.: I hope this is on topic; I think it is. Those recent projects I mentioned: http://almandine.geol.wwu.edu/~dave/research/code/ModeMaker/ http://almandine.geol.wwu.edu/~dave/research/code/ModeQuiz/ Dave Hirsch Associate Professor Department of Geology Western Washington University persistent email: dhir...@mac.com http://www.davehirsch.com voice: (360) 389-3583 aim: dhir...@mac.com vCard: http://almandine.geol.wwu.edu/~dave/personal/DaveHirsch.vcf
Re: Should I learn CoreData for this project?
Hi David, this question is most definitely on topic :-) So, lets see, what would Core Data give you: - Scalability, fast incremental loads and saves for big data sets. I don’t think you’ll need this. Loading and saving 500 items each time will be fast enough. - A data model modeler. That’s actually more valuable then it may seem on first glance. I often look at my Core Data models when thinking about algorithms and want to recap how the object graph looks. - Automatic and semi-automatic version migration. Depends on the lifecycle of your application. When needed, it’ll save you tons of time. - Object graph consistency management. A big one. Core Data automatically updates inverse relationships as needed. A lot of work to do manually, and always a source of subtle bugs. - Automatic undo support. Big - Disadvantage: Core Data does not support ordered relationships. That is, it uses sets instead of arrays. If you need an order, you have to manage this yourself. Not hard, but sometimes an annoyance (the reason for this shortcoming are hard technical problems). That’s it out of my head. I’m sure I forgot something. The learning effort? Hard to say. Core Data is well documented and works (almost always) as advertised. So it depends on how well you learn new abstractions. One unrelated advice: by all means use garbage collection. It makes object graph management (and a lot of other things) so much easier, no matter whether you use Core Data or not. Good luck! Kai On 4.11.2009, at 05:22, David Hirsch wrote: So, I'm hearing folks sing the praises of CoreData, which I have not yet learned. It seems like a long uphill climb, but if life will be spectacular afterwards, I'll do it. I am a semi-casual programmer; I've just finished a couple of small programs that do not use CoreData, and I can see the advantage in gaining open/save and undo/ redo for free, but I'm concerned about the work I'll have to put in to learn it. I've read a bunch of the CoreData intro documentation, but it doesn't give a feel for how difficult it will be to learn, nor how big the advantages are if I do. Here's the next project I'm going to work on, for which I'm considering CoreData: A simulated annealing code for class scheduling. The CoreData part would lie in managing all the lists involved: classes, rooms, instructors, preferences, conflict cost weights, etc. I estimate that I will have about 500 items spread over about 10 arrays. I would not expect to have a complex object graph (if that's the right term) - just a lot of items in lists, items that need to be managed, displayed, saved, loaded, etc. I could use NSArrays for all these, which I currently understand. Does this sound like it's worth learning CoreData for? Thanks, Dave S.A.: I hope this is on topic; I think it is. Those recent projects I mentioned: http://almandine.geol.wwu.edu/~dave/research/code/ModeMaker/ http://almandine.geol.wwu.edu/~dave/research/code/ModeQuiz/ Dave Hirsch Associate Professor Department of Geology Western Washington University persistent email: dhir...@mac.com http://www.davehirsch.com voice: (360) 389-3583 aim: dhir...@mac.com vCard: http://almandine.geol.wwu.edu/~dave/personal/DaveHirsch.vcf ___ 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/lists%40kai-bruening.de This email sent to li...@kai-bruening.de ___ 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: how to make cocoa application run as a command line tool?
The clean solution for this is to refactor your application into a framework, a Cocoa application and a command line tool. The framework contains all the document logic (the model part of the MVC pattern). Both the Cocoa application and the command line tool use the framework. The tricky part is probably to find the right border between framework and application/tool. I haven’t done it myself yet, therefore I am for instance not sure whether NSDocument sub classes can/should be part of such a framework. Others may know whether it is possible/feasible at all to run a Cocoa application faceless. Good luck Kai On 20.10.2009, at 11:58, XiaoGang Li wrote: Greetings, I have created an document-based cocoa application, now I need to provide a command line interface for my users. for example, users input this into the terminal: ./myApplication.app/Contents/MacOS/myApplication -c --srcFolder A/B/ C --dstFolder A/B/D; I can get the argument information through [[NSProcessInfo processInfo] arguments] in the init method of the application delegate, and parse the arguments, then step by step. My question is that, I don't want the window and other document be displayed on the screen, even the menu. I want all the action be processed without user's interventio. Maybe, this feature seems odd. anyway, however, user can open my application in the Finder, and open a document to edit it. but they also can run it like a shell command utility to do some other faceless work, like convert the type the document to another type. I don't know whether I have a detailed description for my issue, but I will be very appreciated for your feedback. ___ 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/lists%40kai-bruening.de This email sent to li...@kai-bruening.de ___ 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: GC and atomic getters/setters
On 17.10.2009, at 17:38, BJ Homer wrote: In the Garbage Collection Programming Guide: Architecture [1], an example is given of a set of non-GC getters and setters which use @synchronized (self) to control the access to the ivar, and in the setter to protect the releasing of the old object and retaining of the new. Then, a GC example is given in which the getters and setters have no synchronization; the getter simply returns the value, and the setter simply assigns the new value. I understand why the setter is so much simpler under GC; no retain/ release fiddling is necessary. However, I'm confused about the lack of synchronization in the GC examples. I know there's lots of skepticism as to whether synchronization at the getter/setter level is even useful (hence the general recommendation to make properties nonatomic). But assuming that you wanted it there in the first place, why does the GC version not need the synchronization? Is it simply because the setter is doing less, and thus the getter wouldn't ever catch the setter halfway through its setting? (After releaseing the old value, but before retaining the new, for example.) Basically yes. Another way to look at it is that assignment to a GC-controlled pointer variable must be thread safe anyway (because GC is running in a separate thread and because there are things like weak references), so there is no need to put extra synchronization around it. By the way, this thread safety feature of GC is another big reason to use GC over managed memory besides the automatic memory management. Kai ___ 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: Appropriate dealloc and finalize actions
Hi Karolis,
I’d say your pattern is absolutely correct. I assume those two objects
do not retain each other, they just need to know about the other one.
And they should be allowed to die separately, while cleaning up the
otherwise dangling pointer in the other object.
The good news is that GC has support for this: weak references. Simply
declare the connection ivar as weak: __weak MyClass* connection. GC
does the rest. No dealloc, no finalizer, no dangling pointer. And it’s
even thread safe.
Best
Kai
On 12.10.2009, at 04:44, Karolis Ramanauskas wrote:
If you want to do something that doesn't break encapsulation, then
you
should simply release the one ivar connection. That will let the
receiving
object perform its own actions, by itself, on its own behalf, as
appropriate
to its own affairs.
Thanks, however, I do not see how to accomplish my purpose. I'm
confused.
Help ;)
I have object1 that has a connection to object2, (object1.connection =
object2). And at the same time object2.connection = object1:
O1 - O2
O2 - O1
If one of these objects gets deallocated how should I make sure the
other
object is not pointing to the now deallocated object without doing
what I
did:
- (void)dealloc {
if (self.connection) {
self.connection.connection = nil;
}
[super dealloc];
}
Thanks
On Sun, Oct 11, 2009 at 6:11 PM, Greg Guerin glgue...@amug.org
wrote:
Karolis Ramanauskas wrote:
- (void)dealloc {
if (self.connection) {
self.connection.connection = nil;
}
[super dealloc];
}
Why would you do this? You're making one object responsible for the
internals of another object. This is a bad idea. It breaks the
individual
encapsulation of each object.
One of the cardinal points of good object-oriented design is that an
object's responsibilities are circumscribed. It should manage
itself and
the things it directly references, nothing else. For any objects
it DOES
reference, each of those objects also has its own responsibilities,
and so
on recursively. Objects shouldn't poke their noses into another
object's
business.
If you want to do something that doesn't break encapsulation, then
you
should simply release the one ivar connection. That will let the
receiving
object perform its own actions, by itself, on its own behalf, as
appropriate
to its own affairs.
-- GG
___
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/lists%40kai-bruening.de
This email sent to li...@kai-bruening.de
___
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: Appropriate dealloc and finalize actions
On 12.10.2009, at 13:42, Roland King wrote: On 12-Oct-2009, at 7:26 PM, Karolis Ramanauskas wrote: Thanks, Kai, Greg, Jens, It's generally a bad idea to have two objects each retain the other. It produces a reference loop, which means neither object can be deallocated without manually releasing each side of the relationship. As was stated in my original email these are all weak references: @property (readwrite, assign) MyClass * connection; I am not retaining the other object. In fact I couldn't really do it because I'm pointing to the object of the SAME class. yes you could - nothing stops you in retain/release mode from retaining an object of the same class, or even yourself, multiple times. MyClass 1 MyClass 2 MyClass 2 MyClass 1 If I made a property to retain the value it would automatically mean that I get a retain cycle. indeed you would one you would have to break. So whenever either an input or output is deleted I have to nil the connection of the object pointing to the soon to be deallocated object: self.connection.connection = nil; Yes that looks like it would work, you explicitly remove the pointer to yourself as you go away. That's fine. Of course it means you aren't managing the lifetimes of the objects between each other, their lifetimes are totally dependent on external factors, but if that's what you want, that's good. Thanks, Kai, for pointing this out: The good news is that GC has support for this: weak references. Simply declare the connection ivar as weak: __weak MyClass* connection. GC does the rest. No dealloc, no finalizer, no dangling pointer. And it’s even thread safe. No. Under GC you don't have this problem at all. You don't need weak references or anything else funky, it just works. MyClass1 pointing to MyClass2 and back with ordinary object references/assign properties does create a cycle yes, however GC can manage that perfectly well. Once there are no references to either MyClass1 or MyClass2 from the *ROOT* objects, even though they point to each other, they are subject to collection. GC is able to deal with these reference loops quite happily. Of course you’re right, you do not need weak references under GC to break reference count cycles - these are a non-issue under GC. I made the implicit assumption (bad bad!) that these objects should not keep each other alive. This is what __weak is good for: it marks a reference which does not keep the target alive and is auto-niled when the target dies. Depends on what you need. And there’s no need to conditionalize __weak in any way. It’s simply ignored under non-GC. Best Kai ___ 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/lists%40kai-bruening.de This email sent to li...@kai-bruening.de ___ 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: Snow Leopard: unsupported PointerFunctions configuration was requested
On 10.10.2009, at 13:56, Chris Idou wrote:
Below is the RegexKit code that causes the Snow Leopard error. After
reading the doco, I don't feel very enlightened about what the
unsupported configuration is, or what the solution might be. Can
anyone give me a clue?
Sure: replace NSPointerFunctionsIntegerPersonality by
NSPointerFunctionsIntegerPersonality | NSPointerFunctionsOpaqueMemory.
Best
Kai
+ (void)load
{
RKAtomicMemoryBarrier(); // Extra cautious
if(RKCacheLoadInitialized== 1) { return; }
if(RKAtomicCompareAndSwapInt(0, 1, RKCacheLoadInitialized)) {
if((cacheMapKeyCallBacks= dlsym(RTLD_DEFAULT,
NSIntegerMapKeyCallBacks)) == NULL) { cacheMapKeyCallBacks= dlsym
(RTLD_DEFAULT, NSIntMapKeyCallBacks); }
#ifdef ENABLE_MACOSX_GARBAGE_COLLECTION
id garbageCollector = objc_getClass(NSGarbageCollector);
if(garbageCollector != NULL) {
if([garbageCollector defaultCollector] != NULL) {
id pointerFunctions = objc_getClass(NSPointerFunctions);
RKCacheIntegerKeyPointerFunctions = [pointerFunctions
pointerFunctionsWithOptions:NSPointerFunctionsIntegerPersonality];
RKCacheIntegerKeyPointerFunctions.acquireFunction =
intPointerFunctionsAcquire;
RKCacheIntegerKeyPointerFunctions.descriptionFunction =
intPointerFunctionsDescription;
RKCacheIntegerKeyPointerFunctions.hashFunction=
intPointerFunctionsHash;
RKCacheIntegerKeyPointerFunctions.isEqualFunction =
intPointerFunctionsIsEqual;
RKCacheIntegerKeyPointerFunctions.relinquishFunction =
intPointerFunctionsRelinquish;
RKCacheIntegerKeyPointerFunctions.sizeFunction=
intPointerFunctionsSize;
RKCacheObjectValuePointerFunctions = [pointerFunctions
pointerFunctionsWithOptions:(NSPointerFunctionsZeroingWeakMemory|
NSPointerFunctionsObjectPersonality)];
[[garbageCollector defaultCollector]
disableCollectorForPointer:RKCacheIntegerKeyPointerFunctions];
[[garbageCollector defaultCollector]
disableCollectorForPointer:RKCacheObjectValuePointerFunctions];
}
}
#endif // ENABLE_MACOSX_GARBAGE_COLLECTION
}
}
From: Bill Bumgarner b...@mac.com
To: Chris Idou idou...@yahoo.com
Cc: cocoa-dev@lists.apple.com
Sent: Thu, 24 September, 2009 12:36:04 PM
Subject: Re: Snow Leopard: unsupported PointerFunctions
configuration was requested
On Sep 23, 2009, at 7:09 PM, Chris Idou wrote:
Very early in application startup, even before main() is called, I
get the following error:
2009-09-24 12:07:11.462 MyApp[5534:a0f] *** An unsupported
PointerFunctions configuration was requested, probably for use by
NSMapTable, NSHashTable, or NSPointerArray. The requested
configuration fails due to integer personality not using opaque
memory
It happens twice on startup, and below are the stack traces when it
happens:
What does it all mean?
#00x7fff84b342f7 in NSLog
#10x7fff84ac84d1 in +[NSConcretePointerFunctions
initializeSlice:withOptions:]
#20x7fff84aea796 in -[NSConcretePointerFunctions
initWithOptions:]
#30x7fff84aea74d in +[NSPointerFunctions
pointerFunctionsWithOptions:]
#40x10004b633 in +[RKCache load]
One change to the NSPointerFunction based collection classes (which
support a number of things that NSArray the like do not) between
Leopard and Snow Leopard was to tighten up the validation of the
pointer function validation such that a handful of non-sensical
configurations are detected that weren't before.
I.e. RKCache is trying to create a set of pointer functions that
doesn't make sense (and for whose behavior is undefined).
As someone else pointed out, RK is most likely RegexKit and, thus,
the source is available and can be fixed. Given the relatively
common use of RK*, please provide a patch to the author so it can be
fixed upstream.
b.bum
__
Get more done like never before with Yahoo!7 Mail.
Learn more: http://au.overview.mail.yahoo.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/lists%40kai-bruening.de
This email sent to li...@kai-bruening.de
___
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: Undo architecture advice needed
Hello Dave, undo/redo is a model operation and should be handled inside the model. That is, I wouldn’t pick your suggestions 1) or 2), because they both do not observe (in a general case, not KVO) the model to generate undo information. If I understand you correctly, the phase objects are your model. If this is correct, the changes do go through your code: when they arrive at the phase object (typically in a setter). And this is the place to record the information needed for undoing the change. Hope this makes any sense Kai On 9.10.2009, at 19:53, David Hirsch wrote: Hello list- I have a document-based application. Each document has a NSArray of phases. Phases is an NSArrayController created in IB and bound to FIle's Owner.phases. When a given phase is selected in the NSTableView (bound to phase controller), then its properties show up in a set of text fields, check boxes, color wells, popup menus, etc., through bindings similar to Phases.selection.size. Here is my question: what is the best way to implement undo/redo here? I'd like to enable undo of changes to the settings (like size) that the user makes in the text fields, but they don't go through my code - they are just bound directly to the array. (Note that I do understand that the field editor has its own undo that operates during text editing; that is not what I'm talking about.) Here are some potential avenues I'm considering: 1) Make the document the delegate for all these fields. Then I can get a controlTextDidChange: notification, figure out the current phase, get the object and the value, and post an undo. However, this requires me to implement a whole bunch of setters in my NSDocument subclass that duplicate setters in my phases class, which seems inelegant, to say the least. Also, I don't see an obvious way to do something similar for, say checkboxes. 2) Try to set up KVO (from my document subclass, I guess?) on the NSArrayController to watch for changes, and then register undo operations in the observing method. I would have to be careful not to get into a loop when re-doing the undo operations, though, since I would observe any changes I made during undo. 3) I'm sure there are other ways, but I'm not smart enough to think of them. Thanks in advance, Dave ___ 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/lists%40kai-bruening.de This email sent to li...@kai-bruening.de ___ 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 an associated reference is memory expensive (was: Adding an observer is memory expensive)
On 12.9.2009, at 00:35, Greg Parker wrote:
We have your earlier report rdar://7212101. Thanks, Torsten. (Ken
didn't see it because the bug didn't pass through his group's hands
on its way to my group.)
This is a bug in the associated reference machinery. That code keeps
a C++ std::hash_map per augmented object, mapping associated keys to
associated values. std::hash_map uses an std::vector internally, and
the default hash_map constructor pre-allocates 100 entries for that
vector.
Which are then raised to 193 by __stl_next_prime() in hashtable.h.
Times the 64 bit pointer size makes 1544 bytes, which GC seems to
round up to the 2k seen by the OP.
This is overkill for associated objects usage. The fix is to use a
non-default constructor that specifies a much smaller initial
hash_map size.
Unfortunately constructing the std::hash_map with a small capacity
will lower the number of preallocated bucket slots only to 53 (- 424
bytes under 64 bits), because this is the smallest number returned by
__stl_next_prime(). (I deduced this from the stl source in the 10.6
sdk, so I may be mistaken.)
Still a lot for the probably predominate case of a single association.
Especially if the OP is right with his observation that this memory is
scanned by the collector, which adds time overhead to the space
overhead.
Kai
On Sep 11, 2009, at 2:25 PM, Ken Ferry wrote:
Hi Torsten,
Please file as a bug if you haven't already. That clearly needs to
be
looked into.
For your KVO issue, you can probably work around it by implementing
- (void)setObservationInfo:(id)observationInfo;
- (id)observationInfo;
on the object that you are observing. This provides the storage,
and KVO
won't have to use associated references.
Note that the observation info is typed id despite being typed void
* in the
headers. KVO needs strong storage here to implement the feature
described
in Automatic Removal of Finalized Key-Value Observers in the
release
notes. KVO assumes you are providing strong storage if the method
is typed
id, which can be introspected out of the runtime. If you aren't,
it'll have
to use an associated reference to keep things alive.
-Ken
Cocoa Frameworks
On Fri, Sep 11, 2009 at 3:13 AM, Torsten Radtke torsten.rad...@me.com
wrote:
Is this when the first observer is added to each of the 100k
objects?
Yes, it happens for the first observer I add.
But I expressed the problem not good enough. Adding an observer is
realized
by adding an associated reference (with objc_addAssociatedObject
(), new in
Snow Leopard) to the observed object. So the main problem is that
adding a
single associative reference to an object results in an allocation
of 2048
byte block. If I do this to my 100.000 objects, about 200MB are
allocated
(in comparison to about 3MB for the objects). These blocks seem to
be
scanned memory, as I also noticed significant delays as the garbage
collector scanned and collected.
This amount of memory seems to be allocated on purpose (see
the ::reserve
method on top of the stack trace shown below) but seems way too
high for the
general case of adding a single associative reference!
0 libauto.dylib
std::vector__gnu_cxx::_Hashtable_nodestd::pairvoid*
const, void* *,
Auto::AuxAllocator__gnu_cxx::_Hashtable_nodestd::pairvoid*
const, void*
* ::reserve(unsigned long)
1 libauto.dylib Auto::Zone::set_associative_ref(void*, void*, void*)
2 AssociativeReferences -[Object setName:]
3 AssociativeReferences main
4 AssociativeReferences start
The Object class is implemented as follows:
static char name_key;
@implementation Object
- (NSString*)name {
return objc_getAssociatedObject(self, name_key);
}
- (void)setName:(NSString*)aName {
objc_setAssociatedObject(self, name_key, aName,
OBJC_ASSOCIATION_COPY);
}
@end
Torsten
___
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/kenferry
%40gmail.com
This email sent to kenfe...@gmail.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/gparker%40apple.com
This email sent to gpar...@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:
Re: How to share Cocoa classes?
On 6.7.2009, at 20:30, Alexander Bokovikov wrote: Thank you for the reply, It looks like your case is just what I'd like to have, though my situation is simpler, as my shared code is the same for different projects (though different projects may include other different pieces). Therefore the problem of code stripping (which you described) should not appear for me. Nevertheless, I'd appreciate it highly, if you'll guide me through the XCode project settings adjustment, as it sounds foggy for me, how to make static library to rebuild itself when main project is built. What particular settings should I add to the main project? Also it's not clear, where to put that common header file? What is the correct location for that? Am I correct in my understanding, that placing this .h file into the right place I'll have the ability to include my classes (stored in static library) by single #importmysubdir/myincfile.h ? If yes, then it is just, what I'd like to get! The same question is about static library itseklf -- where it should be located? Should I create my own directory system or is it better to use some standard (system) directories for that? If I must use my own directories, then where should I add a path to them to avoid the necessarity to add this path to every new XCode project manually? Besides the suggestions of other, an additional method to handle this are Xcode source trees. You can define paths to source trees in Xcode preferences (that is, per machine), and then use these definitions to set paths in projects relative to a defined source tree. This frees you from the need to have the exact same directory setup on each computer which uses the project. Kai ___ 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: Short-circuit evaluation
On 23.6.2009, at 17:14, Kyle Sluder wrote: On Tue, Jun 23, 2009 at 7:47 AM, Graham Coxgraham@bigpond.com wrote: I'd like to if I could - unfortunately in this case the method in question is -validateMenuItem: which is designed to have intentional side- effects, like setting the item's state or title, as well as returning a boolean value for the enable state. The API might have been better if it returned nothing and made you handle the enable state directly also, but it wasn't so I'm stuck with it. There is no reason you can't do this: BOOL a = [foo bar]; BOOL b = [baz quux]; return a || b; Or, different style: BOOL a = NO; if ([foo bar]) a = YES; if ([baz quux]) a = YES; return a; Kai ___ 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: Drawing 1 pixel line with zoom change
On 12.5.2009, at 06:23, Graham Cox wrote: On 12/05/2009, at 12:44 AM, Sahana A wrote: We have a feature in our application wherein we have to draw a 1 pixel line. This drawing also varies relative to the zoom factor of our view. For example if we are drawing at a zoom factor of 200% we draw 0.5 pixel line. ( basically: 1/zoomfactor width of line; 1 if the zoomfactor 100 ). For most of the times we succeed in drawing the 1 pixel line. However after we change the zoom factor, our drawing fails. Our 1 pixel line is now drawn in 2 pixels. For example: On changing the zoom values from say 100% to 300% and back to 100% again, the single pixel line sometimes draw in 2 pixels. Even if the stroke width is set to 0.0 or 1.0, the stroked line will draw 2 pixels. It's not just a case of setting the line width, but also of placing the line where you want it. Strokes are placed so that they are centred on the co-ordinate, so half the line is above and half below the integral co-ordinate position. This is true even if you suppress anti-aliasing, which make matters worse since the lightening of the line is disabled and it'll draw as a solid 2 pixel line. You need to truncate the line's co-ordinates to a whole number then add or subtract 0.5 so that the line is drawn on the pixel, not on the co-ordinate. This goes into the right direction, but things are a little more involved. Basically you need to convert to device coordinates first, to the correct rounding, convert the result back and then draw. The 10.5-only NSView methods convertPointToBase: and friends are quite helpful for this. For more details see Apples Resolution Independence Guidelines. Kai --Graham ___ 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/kai%40granus.net This email sent to k...@granus.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
Re: image transition while dragging
Hi Rajesh,
as far as I know Cocoa has no provision for this at least up to
Leopard. (If I remember correctly, you could do this easily with
Carbon ;-) )
If you absolutely want this behavior, I can think of two ways to
persuade:
- Return no or an empty image from dragImageForRowsWithIndexes:, track
the mouse yourself and move a temporary window with an image of your
chosing around on the screen. Should be doable, but probably not in a
single afternoon.
- Read about Cocoa hacking and look for some private API IB might be
using for its dragging. Usual caveats apply, like Apple might break
your code with any update etc.
Best success
Kai
On 23.4.2009, at 13:23, rajesh wrote:
Hi All,
I am working on dragging table row (not for re-ordering or deleting)
onto a NSView
I am returning an processed image (for dragImage) in
- (NSImage *)dragImageForRowsWithIndexes:(NSIndexSet *)dragRows
tableColumns:(NSArray *)tableColumns
event:(NSEvent *)dragEvent offset:
(NSPointPointer)dragImageOffset
{
//
return doctoredImage;
}
I want to change the dragged image with smooth transition to another
image, whenever it reaches its destination(NSView) or when drag
moves out of the source(NSTableView) just like the effect to the
drag image in interface builder tool when items from palette are
dragged out of it.
Any pointers or ideas is appreciated.
Thanks
Rajesh.
___
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/kai%40granus.net
This email sent to k...@granus.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
