EXC_BAD_ACCESS when migrating a store, but only sometimes...
Hi list, I've come across a rather perplexing problem which is driving me nuts. I'm attempting to migrate a core data SQLite store to the current model version, and most of the time it works fine. However, sometimes I get an EXC_BAD_ACCESS in the following stack: objc_assign_strongCast + 19 -[NSMigrationManager migrateStoreFromURL:type:options:withMappingModel:toDestinationURL:destinationType:destinationOptions:error :] + 2750 (My methods...) Most of the time, if I simply try and run the migration again on the same file it works fine. I'm not doing anything fancy - this is how I call -migrateStoreFromURL:... [manager migrateStoreFromURL:url type:NSSQLiteStoreType options:nil withMappingModel:mappingModel toDestinationURL:destinationStoreURL destinationType:NSSQLiteStoreType destinationOptions:nil error:error] All of my vars are correct and I have no memory leaks or overreleases. If anyone could help me start debugging what on earth is going on, I'd really appreciate it. Thanks, -- Daniel ___ dan...@kennettnet.co.uk http://www.kennettnet.co.uk Please include previous messages in any reply you send. ___ 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
[ANN] KNAppGuide - an open source in-app tutorial framework
I'm pleased to announce the first release of KNAppGuide - an in-app tutorial framework inspired by Apple Guide of the System 7 era. The framework was written because, well, Apple Guide was awesome. The ability to guide your users through specific tasks in your application actually *IN* your application is wonderful, and gives a much better user experience than following a set of screenshots or whatever. KNAppGuide intends to being this idea into the modern world of Cocoa. More information, screenshots, demo app and code are located at: http://www.kennettnet.co.uk/code/knappguide/ I'd really appreciate any feedback. Thanks, -- Daniel ___ dan...@kennettnet.co.uk http://www.kennettnet.co.uk Please include previous messages in any reply you send. ___ 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: [ANN] KNAppGuide - an open source in-app tutorial framework
Hi Mic, Thanks for your feedback. The framework does indeed highlight the UI with an animated red circle. I've gone ahead and put up a demo video on the framework's page so you can get a better feel for that it's like. I have been wondering about how to add styled content to guides, and I think a WebView is a good idea. Thanks, -- Daniel On 19 May 2009, at 14:19, Mic Pringle wrote: Hi Daniel, This looks like a great idea. Having perused the page on your site (I can't test the framework at the moment as I'm away from my Mac) it's not quite clear how the UI is highlighted (is it done by actually drawing a red circle as shown in the screenshots ?) I feel it would be much clearer if you had a video on there showing your demo app ? Also, one recommendation is to use Webkit and render HTML in the pop up rather than just text. It can be quite tiring on the eye's to read paragraph after paragraph of plain text. Allowing the developer to embed images or even videos (i.e. YouTube) would really enhance this experience. -Mic 2009/5/19 Daniel Kennett li...@kennettnet.co.uk: I'm pleased to announce the first release of KNAppGuide - an in-app tutorial framework inspired by Apple Guide of the System 7 era. The framework was written because, well, Apple Guide was awesome. The ability to guide your users through specific tasks in your application actually *IN* your application is wonderful, and gives a much better user experience than following a set of screenshots or whatever. KNAppGuide intends to being this idea into the modern world of Cocoa. More information, screenshots, demo app and code are located at: http://www.kennettnet.co.uk/code/knappguide/ I'd really appreciate any 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/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Crashing resetting or releasing an NSManagedObjectContext [SOLVED]
*Sigh*
All this effort, and it turns out to be a one-line fix. Obviously.
[NSManagedObjectContext -setRetainsRegisteredObjects:YES]
Calling that on the context solves all the problems I was having, and
everything works perfectly now!
Thanks,
-- Daniel
___
dan...@kennettnet.co.uk
http://www.kennettnet.co.uk
Please include previous messages in any reply you send.
On 5 May 2009, at 09:46, Daniel Kennett wrote:
Thank you again for your helpful replies!
On a different note, when you comment out the for (VetVisit code,
does it still crash on a VetVisit, or does it crash on a
Medication object?
It still crashes on a VetVisit object.
I don't think I've solved the problem, but I have stopped it
crashing. Putting a breakpoint on [VetVisit -release] showed me
that NSFastEnumeration was releasing the object:
for (VetVisit *visit in [self vetVisits]) { // -- Stack trace for
[VetVisit -release] comes from here
[visit className];
}
I solved the crash by doing this:
NSArray *visits = [[self vetVisits] allObjects];
for (VetVisit *visit in visits) {
[visit className];
}
... and now it works fine! The accessors for the vetVisits set are
just the ones made by the Core Data wizard thing - they're declared
like this:
@property (nonatomic, retain) NSSet* vetVisits;
... and implemented with this:
@dynamic vetVisits;
So, I've stopped the crash, but I'm thoroughly confused about what's
going on and think I'm just papering over the problem.
___
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: Crashing resetting or releasing an NSManagedObjectContext
Thank you again for your helpful replies!
On a different note, when you comment out the for (VetVisit code,
does it still crash on a VetVisit, or does it crash on a
Medication object?
It still crashes on a VetVisit object.
I don't think I've solved the problem, but I have stopped it crashing.
Putting a breakpoint on [VetVisit -release] showed me that
NSFastEnumeration was releasing the object:
for (VetVisit *visit in [self vetVisits]) { // -- Stack trace for
[VetVisit -release] comes from here
[visit className];
}
I solved the crash by doing this:
NSArray *visits = [[self vetVisits] allObjects];
for (VetVisit *visit in visits) {
[visit className];
}
... and now it works fine! The accessors for the vetVisits set are
just the ones made by the Core Data wizard thing - they're declared
like this:
@property (nonatomic, retain) NSSet* vetVisits;
... and implemented with this:
@dynamic vetVisits;
So, I've stopped the crash, but I'm thoroughly confused about what's
going on and think I'm just papering over the problem.
Thanks,
-- Daniel
___
dan...@kennettnet.co.uk
http://www.kennettnet.co.uk
Please include previous messages in any reply you send.
On 4 May 2009, at 23:44, Keary Suska wrote:
On May 1, 2009, at 2:24 AM, Daniel Kennett wrote:
Thanks for your reply. Yes, I have code that triggers relationship
faults, and removing that code solves the problem. However, I need
that code to work! :-)
When fetching the data from the object tree, I call a method on the
pet instance called -pertinentActions. This method loops through
various relationships, calling -pertinentAction on each child
object. I've ruled out the -pertinentAction method, since calling -
className on the child objects also causes the crash to happen.
I've also double and triple checked my retains and (auto)releases
and they're all balanced.
My recommendation is don't check them *prove* them. If you release
or autorelease any vetvisit object, comment it out and see if the
problem goes away. I say this because I have had, and just about any
programmer probably has, stared at the exact glaring error over and
over again and not seen it.
In any case, there is an overrelease happening, which means
somewhere retains are *not* balanced, and 99.% of the time, it's
the programmer's code. But you have to find out how it is happening,
so it's time to bring out Instruments--it can tell you who is the
culprit and where it is.
On a different note, when you comment out the for (VetVisit code,
does it still crash on a VetVisit, or does it crash on a
Medication object?
___
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: Crashing resetting or releasing an NSManagedObjectContext
Good morning all,
Thanks for your reply. Yes, I have code that triggers relationship
faults, and removing that code solves the problem. However, I need
that code to work! :-)
When fetching the data from the object tree, I call a method on the
pet instance called -pertinentActions. This method loops through
various relationships, calling -pertinentAction on each child object.
I've ruled out the -pertinentAction method, since calling -className
on the child objects also causes the crash to happen. I've also double
and triple checked my retains and (auto)releases and they're all
balanced.
Here's the code that triggers the crash:
-(NSArray *)pertinentActions {
NSMutableArray *actions = [[NSMutableArray alloc] init];
[actions addObject:[self birthdayAction]];
for (InsurancePolicy *policy in [self insurancePolicies]) {
KNClarusPertinentAction *action = [policy pertinentAction];
if (action) {
[actions addObject:action];
}
}
// If I return here, the later crash doesn't happen!
for (VetVisit *visit in [self vetVisits]) {
[visit className];
}
// Returning just after this...
for (Medication *medication in [self medications]) {
[medication className];
}
// ... or this causes the later crash.
return [actions autorelease];
}
Commenting out the for (VetVisit* and for (Medication* loops fixes the
crash. At this point, I'm doing no memory management at all - the -
pertinentActions method is being called thusly:
NSManagedObjectContext *context = [[NSManagedObjectContext alloc] init];
Pet *pet = [KNClarusQuickDocumentParser petAtURL:url inContext:context];
NSMutableDictionary *dict = [[NSMutableDictionary alloc] init];
[dict setValue:[[[pet valueForKey:@name] copy] autorelease]
forKey:@name];
[dict setValue:[[[pet valueForKey:@birthday] copy] autorelease]
forKey:@birthday];
// More copying of strings and dates
[..]
[dict setValue:[[[pet valueForKey:@pertinentActions] copy]
autorelease] forKey:@pertinentActions]; // --- Here
[context release];
return [dict autorelease];
I think I've stumbled upon a problem with the way I've set up my
model. The insurance policy collection, which doesn't crash after
being accessed, is simply a one-to-many relationship from pet.
However, the Medication and VetVisit relationships are a little more
complex. It goes:
Pet - Medication(s) - Medication Course(s) - Medication Dose(s)
Pet - Vet Visit(s)
The Medication Dose entity has an optional relationship to Vet Visit
in case the dose was given at a visit to the vet. Here's a screenshot
of that part of my model:
http://www.kennettnet.co.uk/stuff/ClarusModel.png
Right now, I'm at a dead-end. I've ruled out my memory management, and
can't see how I can work around what's happening, or what I'm doing
wrong!
Thanks,
-- Daniel
___
dan...@kennettnet.co.uk
http://www.kennettnet.co.uk
Please include previous messages in any reply you send.
Does the Pet class, or any class it has a relationship with,
release or autorelease any VetVisit object? I am assuming that the
Pet entity has a relationship to VetVisit--do you have any code
that would cause the relationship fault to fire? If so, what happens
when you comment that out?
On 29 Apr 2009, at 16:32, Alexander Spohr wrote:
Daniel,
You are trying to fetch an object and keep it - but you want to
ignore / throw away the NSManagedObjectContext. This will never
work. The NSManagedObjectContext keeps the object. Your Pet can
not exist without its NSManagedObjectContext.
You should let the caller provide a NSManagedObjectContext and
fetch your Pet into that context. Make it the callers
responsibility to get a NSManagedObjectContext not yours.
+ (Pet *)petAtURL:(NSURL *)url inContext:(NSManagedObjectContext
*)aManagedObjectContext
Or copy the pet into something like an NSDictionary and return that.
atze
Am 29.04.2009 um 10:59 schrieb Daniel Kennett:
Hi list,
I'm hoping you guys can help me. I'm loading up a Core Data
store, copying some data out and attempting to clear it all up. I
use this code for my Quicklook plugin, and in parts of my app for
previewing documents in a more advanced manner than Quicklook
provides.
This is how I set up my ManagedObjectContext:
+(Pet *)petAtURL:(NSURL *)url {
NSManagedObjectModel *managedObjectModel =
[KNClarusQuickDocumentParser managedObjectModel];
NSPersistentStoreCoordinator *coordinator =
[[[NSPersistentStoreCoordinator alloc]
initWithManagedObjectModel:managedObjectModel] autorelease];
[coordinator addPersistentStoreWithType:NSSQLiteStoreType
Re: Crashing resetting or releasing an NSManagedObjectContext
Thank you to you and Keary for your reply.
This is what the // copy out some data code does:
NSMutableDictionary *dict = [[NSMutableDictionary alloc] init];
[dict setValue:[[[pet valueForKey:@name] copy] autorelease]
forKey:@name];
[dict setValue:[[[pet valueForKey:@birthday] copy] autorelease]
forKey:@birthday];
// More of the same
I did as you suggested and now pass in my own MOC. Now I get a
different crash that I've seen before and had managed to hide with
another memory management error. This time, I get an EXC_BAD_ACCESS
when the MOC is dealloc'ing itself:
[NSManagedObjectContext(_NSInternalAdditions)
_disposeObjects:count:notifyParent:]
[NSManagedObjectContext(_NSInternalAdditions) _dispose:]
[NSManagedObjectContext dealloc]
Now, in my mind it seems that it's crashing when trying to dispose an
object that's already been released. Here's how I now get and create
my Pet object:
NSError *fetchError = nil;
NSArray *fetchResults = nil;
NSFetchRequest *fetchRequest = [[[NSFetchRequest alloc] init]
autorelease];
NSEntityDescription *entity = [NSEntityDescription entityForName:@Pet
inManagedObjectContext:context];
[fetchRequest setEntity:entity];
fetchResults = [context executeFetchRequest:fetchRequest
error:fetchError];
if ((fetchResults != nil) ([fetchResults count] == 1)
(fetchError == nil))
{
NSManagedObject *pet = [fetchResults objectAtIndex:0];
return pet;
}
I really can't see what I'm doing wrong. I'll go try NSZombieEnabled
and see what I can find.
Thanks,
-- Daniel
___
dan...@kennettnet.co.uk
http://www.kennettnet.co.uk
Please include previous messages in any reply you send.
On 29 Apr 2009, at 16:32, Alexander Spohr wrote:
Daniel,
You are trying to fetch an object and keep it - but you want to
ignore / throw away the NSManagedObjectContext. This will never
work. The NSManagedObjectContext keeps the object. Your Pet can not
exist without its NSManagedObjectContext.
You should let the caller provide a NSManagedObjectContext and fetch
your Pet into that context. Make it the callers responsibility to
get a NSManagedObjectContext not yours.
+ (Pet *)petAtURL:(NSURL *)url inContext:(NSManagedObjectContext
*)aManagedObjectContext
Or copy the pet into something like an NSDictionary and return that.
atze
Am 29.04.2009 um 10:59 schrieb Daniel Kennett:
Hi list,
I'm hoping you guys can help me. I'm loading up a Core Data store,
copying some data out and attempting to clear it all up. I use this
code for my Quicklook plugin, and in parts of my app for previewing
documents in a more advanced manner than Quicklook provides.
This is how I set up my ManagedObjectContext:
+(Pet *)petAtURL:(NSURL *)url {
NSManagedObjectModel *managedObjectModel =
[KNClarusQuickDocumentParser managedObjectModel];
NSPersistentStoreCoordinator *coordinator =
[[[NSPersistentStoreCoordinator alloc]
initWithManagedObjectModel:managedObjectModel] autorelease];
[coordinator addPersistentStoreWithType:NSSQLiteStoreType
configuration:nil
URL:url
options:nil
error:error];
NSManagedObjectContext *moc = [[NSManagedObjectContext alloc] init];
// ^ Not Autoreleasing here. It's the responsibility of the
caller to release the MOC. Autoreleasing causes crashes.
[moc setPersistentStoreCoordinator:coordinator];
[[moc undoManager] disableUndoRegistration];
NSError *fetchError = nil;
NSArray *fetchResults;
NSFetchRequest *fetchRequest = [[[NSFetchRequest alloc] init]
autorelease];
NSEntityDescription *entity = [NSEntityDescription
entityForName:@Pet
inManagedObjectContext:moc];
[fetchRequest setEntity:entity];
fetchResults = [moc executeFetchRequest:fetchRequest
error:fetchError];
if ((fetchResults != nil) ([fetchResults count] == 1)
(fetchError == nil))
{
NSManagedObject *pet = [[fetchResults objectAtIndex:0] retain];
return [pet autorelease];
}
return nil;
}
And this is how I get the data out and release it:
Pet *pet = [KNClarusQuickDocumentParser petAtURL:url];
// Copy out some data.
NSManagedObjectContext *context = [pet managedObjectContext];
if (context) {
[context reset
Re: Crashing resetting or releasing an NSManagedObjectContext
Hi again,
Well, that was quick. With NSZombieEnabled, I get this when
deallocating my context:
*** -[VetVisit_VetVisit_ _hasRetainedStoreResources]: message sent to
deallocated instance 0x16b85600
VetVisit is class that represents an Entity in my object model - the
Pet entity has a collection of VetVisit objects. I don't actually ever
manage these directly - I let Core Data NSArrayControllers handle
them. In this case, the model is never seeing any array controllers.
Is this something wrong with my model? I can't see anything wrong at
surface level - indeed, the app itself has been working perfectly with
its model for some time. I'd appreciate any pointers.
Thanks,
-- Daniel
___
dan...@kennettnet.co.uk
http://www.kennettnet.co.uk
Please include previous messages in any reply you send.
On 29 Apr 2009, at 16:32, Alexander Spohr wrote:
Daniel,
You are trying to fetch an object and keep it - but you want to
ignore / throw away the NSManagedObjectContext. This will never
work. The NSManagedObjectContext keeps the object. Your Pet can not
exist without its NSManagedObjectContext.
You should let the caller provide a NSManagedObjectContext and fetch
your Pet into that context. Make it the callers responsibility to
get a NSManagedObjectContext not yours.
+ (Pet *)petAtURL:(NSURL *)url inContext:(NSManagedObjectContext
*)aManagedObjectContext
Or copy the pet into something like an NSDictionary and return that.
atze
Am 29.04.2009 um 10:59 schrieb Daniel Kennett:
Hi list,
I'm hoping you guys can help me. I'm loading up a Core Data store,
copying some data out and attempting to clear it all up. I use this
code for my Quicklook plugin, and in parts of my app for previewing
documents in a more advanced manner than Quicklook provides.
This is how I set up my ManagedObjectContext:
+(Pet *)petAtURL:(NSURL *)url {
NSManagedObjectModel *managedObjectModel =
[KNClarusQuickDocumentParser managedObjectModel];
NSPersistentStoreCoordinator *coordinator =
[[[NSPersistentStoreCoordinator alloc]
initWithManagedObjectModel:managedObjectModel] autorelease];
[coordinator addPersistentStoreWithType:NSSQLiteStoreType
configuration:nil
URL:url
options:nil
error:error];
NSManagedObjectContext *moc = [[NSManagedObjectContext alloc] init];
// ^ Not Autoreleasing here. It's the responsibility of the
caller to release the MOC. Autoreleasing causes crashes.
[moc setPersistentStoreCoordinator:coordinator];
[[moc undoManager] disableUndoRegistration];
NSError *fetchError = nil;
NSArray *fetchResults;
NSFetchRequest *fetchRequest = [[[NSFetchRequest alloc] init]
autorelease];
NSEntityDescription *entity = [NSEntityDescription
entityForName:@Pet
inManagedObjectContext:moc];
[fetchRequest setEntity:entity];
fetchResults = [moc executeFetchRequest:fetchRequest
error:fetchError];
if ((fetchResults != nil) ([fetchResults count] == 1)
(fetchError == nil))
{
NSManagedObject *pet = [[fetchResults objectAtIndex:0] retain];
return [pet autorelease];
}
return nil;
}
And this is how I get the data out and release it:
Pet *pet = [KNClarusQuickDocumentParser petAtURL:url];
// Copy out some data.
NSManagedObjectContext *context = [pet managedObjectContext];
if (context) {
[context reset]; // This call results in EXC_BAD_ACCESS
[context setPersistentStoreCoordinator:nil];
[context release];
}
return [dict autorelease];
End code
Different combinations of trying to do this right result in crashes
at different points. Leaving out [context reset] and just releasing
it obviously gives EXC_BAD_ACCESS again. Autoreleasing the MOC in
+petAtURL: causes crashes when the autorelease pool pops. The only
way I can get it to not crash is to -init the MOC and never release
or autorelease it, but that's causing memory leaks!
Is there a good example anywhere of how to set up and tear down a
Core Data document correctly?
Thanks,
-- Daniel
___
dan...@kennettnet.co.uk
http://www.kennettnet.co.uk
Please include previous messages in any reply you send.
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list
Crashing resetting or releasing an NSManagedObjectContext
Hi list,
I'm hoping you guys can help me. I'm loading up a Core Data store,
copying some data out and attempting to clear it all up. I use this
code for my Quicklook plugin, and in parts of my app for previewing
documents in a more advanced manner than Quicklook provides.
This is how I set up my ManagedObjectContext:
+(Pet *)petAtURL:(NSURL *)url {
NSManagedObjectModel *managedObjectModel =
[KNClarusQuickDocumentParser managedObjectModel];
NSPersistentStoreCoordinator *coordinator =
[[[NSPersistentStoreCoordinator alloc]
initWithManagedObjectModel:managedObjectModel] autorelease];
[coordinator addPersistentStoreWithType:NSSQLiteStoreType
configuration:nil
URL:url
options:nil
error:error];
NSManagedObjectContext *moc = [[NSManagedObjectContext alloc] init];
// ^ Not Autoreleasing here. It's the responsibility of the
caller to release the MOC. Autoreleasing causes crashes.
[moc setPersistentStoreCoordinator:coordinator];
[[moc undoManager] disableUndoRegistration];
NSError *fetchError = nil;
NSArray *fetchResults;
NSFetchRequest *fetchRequest = [[[NSFetchRequest alloc] init]
autorelease];
NSEntityDescription *entity = [NSEntityDescription entityForName:@Pet
inManagedObjectContext:moc];
[fetchRequest setEntity:entity];
fetchResults = [moc executeFetchRequest:fetchRequest
error:fetchError];
if ((fetchResults != nil) ([fetchResults count] == 1)
(fetchError == nil))
{
NSManagedObject *pet = [[fetchResults objectAtIndex:0] retain];
return [pet autorelease];
}
return nil;
}
And this is how I get the data out and release it:
Pet *pet = [KNClarusQuickDocumentParser petAtURL:url];
// Copy out some data.
NSManagedObjectContext *context = [pet managedObjectContext];
if (context) {
[context reset]; // This call results in EXC_BAD_ACCESS
[context setPersistentStoreCoordinator:nil];
[context release];
}
return [dict autorelease];
End code
Different combinations of trying to do this right result in crashes at
different points. Leaving out [context reset] and just releasing it
obviously gives EXC_BAD_ACCESS again. Autoreleasing the MOC in
+petAtURL: causes crashes when the autorelease pool pops. The only way
I can get it to not crash is to -init the MOC and never release or
autorelease it, but that's causing memory leaks!
Is there a good example anywhere of how to set up and tear down a Core
Data document correctly?
Thanks,
-- Daniel
___
dan...@kennettnet.co.uk
http://www.kennettnet.co.uk
Please include previous messages in any reply you send.
___
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: Convert GWorldPtr into a NSImage
On 7 Jan 2009, at 15:24, Graham Cox wrote:
However if you need to flip each pixel's byte order you might not
have much choice but to iterate over the buffer and do it by hand.
It's still going to be much simpler than creating a data provider,
etc. You've already got the data, all that other stuff looks like
overkill.
To further support this theory, take a look at this NSImage where I
mistakenly only flipped half of my data - the garbled half of the
image is from data with the wrong endian-ness:
http://www.flickr.com/photos/ikenndac/2492125512/
Here's the (working) code. In my instance I know the data is Little-
Endian RGB565, so I use EndianS16_LtoN. For Big-Endian 32-bit *RGB
you'd probably use EndianS32_BtoN. Although, I'm not sure if I'm using
the correct methods, since the values represent colours rather than
signed integers.
unsigned short *src = incomingData; // Array of data
int i =0;
int end = (width*height) * 2; // * 2 as there's 2 bytes per pixel
for (i = 0; i end; i += 2) {
// This little loop converts the bits to big endian for PPC systems
*src = EndianS16_LtoN(*src);
src++;
}
After this, I convert the data to ARGB using
vImageConvert_RGB565toARGB and wrap it in an NSBitmapImageRep with
initWithBitmapDataPlanes:pixelsWide: (etc). No further processing is
needed after that.
Hope this helps,
-- 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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Serial port over Bluetooth or not?
Hey list, I'm writing a framework that'll communicate with the Lego Mindstorms NXT brick [1] over a serial port, which is created either over Bluetooth or a USB connection (using the Bluetooth serial profile and a USB-Serial driver respectively). The protocol dictates that messages sent over Bluetooth have an additional two bytes at the beginning of the message with a little endian UInt16 describing the length of the message. I can construct this just fine using EndianU16_NtoL et. al, but what I'm struggling with is finding out if the serial port is a Bluetooth one or not. The serial port has a standard BSD path like /dev/tty.NXT. Is there any way of finding out this information? [1] http://mindstorms.lego.com/ Thanks, -- Daniel ___ [EMAIL PROTECTED] http://www.kennettnet.co.uk Please include previous messages in any reply you send. ___ 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]
__memcpy crash with [NSData -getBytes:range:]
Hi list, I'm having trouble reproducing (and fixing) a rare bug that I sometimes get reports about. Here's the code that causes the crash. streamPosition and length are checked to make sure they're within the range of the NSData object: // Allocate a buffer. void *buffer = malloc(length); // Fill the buffer with the requested bytes. [_data getBytes:buffer range:NSMakeRange(streamPosition, length)]; Very occasionally, this fails with this crash: Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x Thread 6 Crashed: 0 0x0d3f __memcpy + 1439 (cpu_capabilities.h:228) 1 com.apple.Foundation 0x9282e456 -[NSConcreteData getBytes:range:] + 267 I don't think it's the file that the NSData is created from - indeed, the customer sent me a copy of the file in question and it works perfectly on my machine. Any help in debugging this would be greatly appreciated! Surrounding the code in a @try block doesn't help - it still ends up with a hard crash (which is what I was expecting, given that is a EXC_BAD_ACCESS). Thanks, -- Daniel ___ [EMAIL PROTECTED] http://www.kennettnet.co.uk Please include previous messages in any reply you send. ___ 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]
Re: GetMonitorFromWindow
Try and make DVD Player span multiple screens - it simply won't. Since DVD Player is hardware accelerated, I was going to suggest that hardware accelerating across multiple screens is hard (especially when said screens are connected to different cards), but World of Warcraft manages just fine, so who knows? (I've only just realised I'm quoting a Blizzard guy!) -- Daniel On 7 Mar 2008, at 16:38, John Stiles wrote: I'm going to jump on the bandwagon and say that your client is wrong. Mac apps do not and should not do this. ___ 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]
