Re: Cocoa-dev Digest, Vol 10, Issue 633
On Oct 3, 2013, at 1:59 PM, cocoa-dev-requ...@lists.apple.com wrote: The main thread of a Cocoa app has a runloop (of course) and also the main GCD dispatch queue. This is very handy because it means tasks on that thread can be scheduled either using the runloop (NSTimer or delayed-perform) or using GCD (dispatch_async, dispatch_sync). But background threads don’t seem to have the same property. If I create a thread using NSThread, it supports a runloop, but I don’t see any API for getting or creating a dispatch queue that runs in conjunction with the runloop. Did I miss something? —Jens I am not sure that I understand your question but have you read the Replacing Run-Loop Code section in the Concurrency Programming Guide? For instance, it suggests using dispatch_sources, and so on, rather than NSTimer methods. In my own code, I think that I have migrated completely to the use of GCD. -- Rick *- * Frederick Bartram * PGP key id: 0x63fa758 keyserver: http://keyserver.pgp.com */ signature.asc Description: Message signed with OpenPGP using GPGMail ___ 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: The cost of using objects rather than plain C variables
Is there any hope in the future to be able to store simple types like int or floats in NSArrays? Have you tried using NSData to store C-arrays? *- * Frederick Bartram * PGP key id: 0x63fa758 keyserver: http://keyserver.pgp.com */ smime.p7s Description: S/MIME cryptographic signature ___ 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: Best way to compare CGFloats (Rick B.)
I am stuck with floats (doubles, to be precise) comparison.
Machine 'real-numbers' such as floats and doubles should be thought of
as intervals or neighborhoods near the mathematical number. Tests for
'equality' of machine reals should never use machine equality '=='
operators. 'Equality' of two machine reals , in this case, means that
the two numbers are separated by a distance less than some small
number, such as '(fabs(a-b) epsilon)'. Exactly what the value of
epsilon should be gets a little tricky.
Hope that I am not being too pedantic but imo you should never test
for 'equality' ('==') when using machine real data types.
Rick B.
*-
* Stop spam before it gets to your mailbox! Support blocklists.
* I use http://www.spamcop.net/.
* my PGP key id: 0x63fa758 keyserver: http://keyserver1.pgp.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: CoreData async fetch request
Is there a way to do an asynchronous fetch request against Core data returning partial results? Try spawning the fetch in a background thread. There is an example of this in the CoreData sample project 'BackgroundFetching'. You will need to read up on the threading issues as in don't share contexts!, share coordinators. I've used it the past for handling large/slow fetch requests. gl. Rick Bartram *- * Stop spam before it gets to your mailbox! Support blocklists. * I use http://www.spamcop.net/. * my PGP key id: 0x63fa758 keyserver: http://keyserver1.pgp.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: NSMenuItem NSRuleEditor
There is very little documentation on NSRuleEditor. :( First, you need to distinguish between a 'criterion' and a 'display value' although they may be the same kind of classes. The criterion is a kind of identifier and the display value is what is actually shown. It is also helpful to think of the rule editor as displaying a tree of alternatives along each row. The left-most criterion is the root, typically a NSPopupButton. The selected NSMenuItem presents a particular branch. So if a criterion is a NSPopupButton then 'child:' might be the 'target' of the NSMenuItem at the 'index' in the criterion's menu. (criterion)NSPopUpButton = NSMenuItem target = next NSControl (the child, perhaps another NSPopUpButton) The 'child:' method returns a criterion that can be a variety objects a NSControl, a NSMenuItem, a NSString, an NSView, or nil. - (id) ruleEditor:(NSRuleEditor *)editor child:(NSInteger)index forCriterion:(id)criterion withRowType:(NSRuleEditorRowType)rowType; How you chose to chain along the criteria depends on you. The sequence of criteria represent paths through the rule tree. If the initial criterion is nil then you are at the root and your root criterion might be a function, perhaps, of the row-type. The 'displayValue' is what actually populates the rule editor and is either a NSMenuItem, NSString, an NSView, or some kind of NSControl. In some cases if the criterion happens to be a NSMenuItem then the display value may just be a copy of the criterion, or a copy of the 'title' string, but each 'display value' must be new. We cannot just return a pointer to the criterion. In any case, the 'display value' is derived from the particular criterion and must be a new value for each invocation of - (id) ruleEditor:(NSRuleEditor *)editor displayValueForCriterion: (id)criterion inRow:(NSInteger)row; Any how, what I've learned about NSRuleEditor is just the result of spending too much time building rule editors. I am sorry but I don't have a good example project to demonstrate this. In summary, the criteria represent a model or prototype of the alternative paths through the selection tree and the display values represent an instantiation of the path. Anyway, this is what I've learned just by treating a rule editor as a black box maybe someone else can provide an authoritative answer. Good luck. *- * Stop spam before it gets to your mailbox! Support blocklists. * I use http://www.spamcop.net/. * my PGP key id: 0x63fa758 keyserver: http://keyserver1.pgp.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
Core Data: relationship 'too large' when saving
Hi all, I am encountering an error that I have not seen before. While saving in a NSManagedObjectContext I am encountering an error that reports a to-many relationship as 'too large'. This relationship has ~10,000 members but each member is relatively simple consisting of a few short strings and numbers. I have no problems operating on this relation; the error only occurs while saving. Many GB of disk space are available. Error occurs independent of store type, SQLite, binary, or xml. Smaller (different) relations of ~1000 members are correctly saved. 1) Is this really a size problem? 2) can someone point me to relevant documentation? Many thanks. Frederick Bartram *- * Stop spam before it gets to your mailbox! Support blocklists. * I use http://www.spamcop.net/. * my PGP key id: 0x63fa758 keyserver: http://keyserver1.pgp.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
Core Data: relationship 'too large' when saving
My bad. I apologize for wasting bandwidth. Problem had nothing to do with relation set size. *- * Stop spam before it gets to your mailbox! Support blocklists. * I use http://www.spamcop.net/. * my PGP key id: 0x63fa758 keyserver: http://keyserver1.pgp.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: Core Data: relationship 'too large' when saving
In my embarrassment at my haste to post to the list I have compounded the error. :( For archive posterity, the 'bug' was a case of mistaken identity. As I have since learned, the 'too large' error notification was triggered by a value-violation in a bounded, 'Number'-attribute that happened to have the same name as a relation in in different entity on which I had been working. The error did not indicate the entity, only the attribute name, in which the violation had been detected so I jumped to the conclusion that the error was in the entity on which I had been working when, in fact, the application was behaving 'correctly'. No bug, No foul. Note to self: Make sure error messages contain sufficient identifying information! Frederick Bartram *- * Stop spam before it gets to your mailbox! Support blocklists. * I use http://www.spamcop.net/. * my PGP key id: 0x63fa758 keyserver: http://keyserver1.pgp.com */ On Sep 24, 2009, at 5:02 PM, Fritz Anderson wrote: On 24 Sep 2009, at 3:24 PM, Frederick Bartram wrote: My bad. I apologize for wasting bandwidth. Problem had nothing to do with relation set size. It won't have been a waste of bandwidth if you post the meaning of the error message, and the solution, for the benefit of the archives. — F -- Fritz Anderson -- Xcode 3 Unleashed: Now in its second printing -- http://x3u.manoverboard.org/ ___ 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 6, Issue 183
On Jan 31, 2009, at 5:57 PM, cocoa-dev-requ...@lists.apple.com wrote: Can anyone tell me if the maximum speedup using parallel programming on multicore processors is BOUNDED by: (A) number of processers (as on a single core processor). (B) number of processors X number cores / processor. If each processor runs numCore threads SIMULTANEOUSLY the answer would be (B). If each procssor run numCore threads non-concurrently the answer is (A). If anyone REALLY knows please help a frustrated cocoa developer out. Thanks, Ron Jurincie jurin...@eecs.utk.edu Ron, try the 'performance optimization' list ( http://lists.apple.com/mailman/listinfo/perfoptimization-dev ) for more info in this domain. ___ 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
How is image drawing rate effected by image resolution and size?
I am having difficulty understanding the issues involved in image drawing speed. I have a large, ~10K x 10K image in a scrolling view. The image is loaded as a PNG file into an NSImageView from a nib. I am getting large differences in the image drawing speed that I do not understand. The image at a resolution of 72dpi, at the default settings as loaded from the nib, draws very,very slowly. If I change the size of the image either larger or smaller, drawing rate increases dramatically. If I change the resolution from 72dpi to 96dpi, for example, but not the total pixel count then the image drawing rate also improves greatly. Can someone provide some guidance as to what is happening? Many thanks, RickB ___ 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 [EMAIL PROTECTED]
