int* array going astray
I have a couple of int* arrays I'm using as instance variables - they're declared in my @interface section, and inited using malloc when I init the object (and free()'d in the dealloc). I can set them, using standard array notation (i.e., number[i] = 7) while I'm in a given method, but the values reset to zeros as soon as I try to read them from another method - that is, they don't seem to be retained by the object. I really don't get what's up. I have other 2D float* arrays inited in the same way, and these work as expected, with their contents being retained by the class (and thus accessible from other methods). Does anyone have any explanation as to why this might be happening? thanks in advance, J.___ 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: int* array going astray
Hey Folks, Thanks for the responses. I'm doing some testing to specifically isolate the instance that's giving me the problem, so "self" should definitely be the right one. There's no persistence stuff written at all yet, so it can't be initWithCoder. I'm using a totally vanilla synthesized accessor, without any options (i.e., @property int* array), but that shouldn't be a problem, should it? And, as I said, I've got float* arrays/matrices that are created exactly the same way, and work without problems. I'll poke around a little bit more, and perhaps try to confirm the problem in a bogus class. If the problem isn't reproducible there, then I'll post some code. I just thought maybe someone might have come up against similar weirdness. thanks, J. (ps - sorry for replying directly to you, Michael. I always forget that the reply to isn't the list itself!) On 2009-11-24, at 4:30 PM, Michael Babin wrote: > On Nov 24, 2009, at 6:20 PM, James Maxwell wrote: > >> I have a couple of int* arrays I'm using as instance variables - they're >> declared in my @interface section, and inited using malloc when I init the >> object (and free()'d in the dealloc). I can set them, using standard array >> notation (i.e., number[i] = 7) while I'm in a given method, but the values >> reset to zeros as soon as I try to read them from another method - that is, >> they don't seem to be retained by the object. I really don't get what's up. >> I have other 2D float* arrays inited in the same way, and these work as >> expected, with their contents being retained by the class (and thus >> accessible from other methods). Does anyone have any explanation as to why >> this might be happening? > > Are you sure that you're looking at the same object in the method where you > set the values vs. the method where you read the values? That is, is self the > same? > ___ 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: int* array going astray
how do you spell total frustration and stupidity? how about writing: if(_state[i] = 0) when you really mean: if(_state[i] == 0) how many hours did I waste trying to find that?. ugh Certainly a simple enough way to make sure a vector isn't retained! (funny that I didn't get a warning, actually... Is there any build setting that will protect me from a similar bought of blindness in the future?) J. On 2009-11-24, at 6:40 PM, James Maxwell wrote: > Hey Folks, > > Thanks for the responses. I'm doing some testing to specifically isolate the > instance that's giving me the problem, so "self" should definitely be the > right one. There's no persistence stuff written at all yet, so it can't be > initWithCoder. I'm using a totally vanilla synthesized accessor, without any > options (i.e., @property int* array), but that shouldn't be a problem, should > it? And, as I said, I've got float* arrays/matrices that are created exactly > the same way, and work without problems. > I'll poke around a little bit more, and perhaps try to confirm the problem in > a bogus class. If the problem isn't reproducible there, then I'll post some > code. I just thought maybe someone might have come up against similar > weirdness. > > thanks, > > J. > > (ps - sorry for replying directly to you, Michael. I always forget that the > reply to isn't the list itself!) > > On 2009-11-24, at 4:30 PM, Michael Babin wrote: > >> On Nov 24, 2009, at 6:20 PM, James Maxwell wrote: >> >>> I have a couple of int* arrays I'm using as instance variables - they're >>> declared in my @interface section, and inited using malloc when I init the >>> object (and free()'d in the dealloc). I can set them, using standard array >>> notation (i.e., number[i] = 7) while I'm in a given method, but the values >>> reset to zeros as soon as I try to read them from another method - that is, >>> they don't seem to be retained by the object. I really don't get what's up. >>> I have other 2D float* arrays inited in the same way, and these work as >>> expected, with their contents being retained by the class (and thus >>> accessible from other methods). Does anyone have any explanation as to why >>> this might be happening? >> >> Are you sure that you're looking at the same object in the method where you >> set the values vs. the method where you read the values? That is, is self >> the same? >> > > ___ > > 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/jbmaxwell%40rubato-music.com > > This email sent to jbmaxw...@rubato-music.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: int* array going astray
oh, thanks! I didn't know that "people" did that. But now I do! Certainly makes sense. cheers, J. On 2009-11-24, at 8:39 PM, Luke the Hiesterman wrote: > This is why some people write if (0 == _state[i]). A mistake there will > definitely generate a compiler error. > > Luke > > On Nov 24, 2009, at 8:35 PM, James Maxwell wrote: > >> how do you spell total frustration and stupidity? >> how about writing: >> if(_state[i] = 0) >> >> when you really mean: >> >> if(_state[i] == 0) >> >> how many hours did I waste trying to find that?. ugh >> Certainly a simple enough way to make sure a vector isn't retained! >> >> (funny that I didn't get a warning, actually... Is there any build setting >> that will protect me from a similar bought of blindness in the future?) >> >> J. >> >> >> On 2009-11-24, at 6:40 PM, James Maxwell wrote: >> >>> Hey Folks, >>> >>> Thanks for the responses. I'm doing some testing to specifically isolate >>> the instance that's giving me the problem, so "self" should definitely be >>> the right one. There's no persistence stuff written at all yet, so it can't >>> be initWithCoder. I'm using a totally vanilla synthesized accessor, without >>> any options (i.e., @property int* array), but that shouldn't be a problem, >>> should it? And, as I said, I've got float* arrays/matrices that are created >>> exactly the same way, and work without problems. >>> I'll poke around a little bit more, and perhaps try to confirm the problem >>> in a bogus class. If the problem isn't reproducible there, then I'll post >>> some code. I just thought maybe someone might have come up against similar >>> weirdness. >>> >>> thanks, >>> >>> J. >>> >>> (ps - sorry for replying directly to you, Michael. I always forget that the >>> reply to isn't the list itself!) >>> >>> On 2009-11-24, at 4:30 PM, Michael Babin wrote: >>> >>>> On Nov 24, 2009, at 6:20 PM, James Maxwell wrote: >>>> >>>>> I have a couple of int* arrays I'm using as instance variables - they're >>>>> declared in my @interface section, and inited using malloc when I init >>>>> the object (and free()'d in the dealloc). I can set them, using standard >>>>> array notation (i.e., number[i] = 7) while I'm in a given method, but the >>>>> values reset to zeros as soon as I try to read them from another method - >>>>> that is, they don't seem to be retained by the object. I really don't get >>>>> what's up. I have other 2D float* arrays inited in the same way, and >>>>> these work as expected, with their contents being retained by the class >>>>> (and thus accessible from other methods). Does anyone have any >>>>> explanation as to why this might be happening? >>>> >>>> Are you sure that you're looking at the same object in the method where >>>> you set the values vs. the method where you read the values? That is, is >>>> self the same? >>>> >>> >>> ___ >>> >>> 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/jbmaxwell%40rubato-music.com >>> >>> This email sent to jbmaxw...@rubato-music.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/luketheh%40apple.com >> >> This email sent to luket...@apple.com > ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: int* array going astray
Thanks again, folks. Will definitely enable those checks. cheers, J. On 2009-11-24, at 9:44 PM, Jens Alfke wrote: > > On Nov 24, 2009, at 8:56 PM, Graham Cox wrote: > >> The warning you want is 'possible unwanted assignment', and I think it comes >> with the -Wall flag. > > Yup. I vehemently assert that all projects should be built with -Wall and > -Werror. It will save you so much time and frustration. > > —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/archive%40mail-archive.com This email sent to arch...@mail-archive.com
recursion anxiety
Hi Folks,
I've had problems with recursive functions before, but this one's making me
crazy.
I have a trie (tree) data structure and I'm trying to find a sequence of ints
in the trie.
- (HSMM_TrieNode*) getTrieNodeFromContextSequence:(NSMutableArray *)aSequence
withNode:(HSMM_TrieNode*) aNode
{
int coincidence;
BOOL found = NO;
HSMM_TrieNode* endNode = nil;
NSMutableArray* mutableSeq = [[NSMutableArray alloc]
initWithArray:aSequence copyItems:YES];
for(HSMM_TrieNode* child in [aNode children])
{
coincidence = [[mutableSeq objectAtIndex:0] intValue];
if([child coincidenceID] == coincidence)
{
endNode = child;
found = YES;
break;
}
}
if(([endNode depth] < ([self contextDepth] - 1)) && ([mutableSeq count]
> 1) && (found == YES))
{
[mutableSeq removeObjectAtIndex:0];
[self getTrieNodeFromContextSequence:mutableSeq
withNode:endNode];
}
[mutableSeq release];
return endNode;
}
The caller sends the sequence of ints (NSNumbers) and the root node of the trie
to search. If I NSLog the guts of this method, I can see that it is, in fact,
recursing down the trie, and correctly following the branch with the matching
ints (coincidenceID numbers), and reaching the point I need to reach. The
problem is that it's not returning the last node in the trie (i.e., the last
match), but rather is returning the first match. And I have no idea why...
Those last few tests before recursing are just checking that 1) I haven't gone
too deep in the trie (I actually want the last node *before* the leaf --
"contextDepth" is the max depth of the trie), 2) that I haven't run out of ints
in the sequence, and 3) that I actually found branch to continue searching
down. If trie doesn't have a match for the start of the sequence, the nil
return is handled by the caller.
Can anyone see why the caller is getting the first match, rather than the last?
Immense thanks to anyone who can see what's up.
J.
James B Maxwell
Composer/Doctoral Student
School for the Contemporary Arts (SCA)
School for Interactive Arts + Technology (SIAT)
Simon Fraser University
jbmaxw...@rubato-music.com
jbmax...@sfu.ca
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: recursion anxiety
LOL!!!
Yipes, how embarrassed am I
So clever, yet so stupid...
thanks a million.
J.
On 2010-03-25, at 9:58 AM, Howard Siegel wrote:
> You never seem to be capturing the result of the recursive calls for return
> to the caller.
>
> You final if block should look like this:
>
>if(([endNode depth] < ([self contextDepth] - 1)) && ([mutableSeq
> count] > 1) && (found == YES))
>{
>[mutableSeq removeObjectAtIndex:0];
>endNode = [self getTrieNodeFromContextSequence:mutableSeq
> withNode:endNode];
> }
>
> - h
>
> On Thu, Mar 25, 2010 at 09:45, James Maxwell
> wrote:
> Hi Folks,
>
> I've had problems with recursive functions before, but this one's making me
> crazy.
> I have a trie (tree) data structure and I'm trying to find a sequence of ints
> in the trie.
>
> - (HSMM_TrieNode*) getTrieNodeFromContextSequence:(NSMutableArray *)aSequence
> withNode:(HSMM_TrieNode*) aNode
> {
>int coincidence;
>BOOL found = NO;
>HSMM_TrieNode* endNode = nil;
>NSMutableArray* mutableSeq = [[NSMutableArray alloc]
> initWithArray:aSequence copyItems:YES];
>for(HSMM_TrieNode* child in [aNode children])
>{
>coincidence = [[mutableSeq objectAtIndex:0] intValue];
>if([child coincidenceID] == coincidence)
>{
>endNode = child;
>found = YES;
>break;
>}
>}
>if(([endNode depth] < ([self contextDepth] - 1)) && ([mutableSeq
> count] > 1) && (found == YES))
>{
>[mutableSeq removeObjectAtIndex:0];
>[self getTrieNodeFromContextSequence:mutableSeq
> withNode:endNode];
>}
>[mutableSeq release];
>return endNode;
> }
>
> The caller sends the sequence of ints (NSNumbers) and the root node of the
> trie to search. If I NSLog the guts of this method, I can see that it is, in
> fact, recursing down the trie, and correctly following the branch with the
> matching ints (coincidenceID numbers), and reaching the point I need to
> reach. The problem is that it's not returning the last node in the trie
> (i.e., the last match), but rather is returning the first match. And I have
> no idea why...
> Those last few tests before recursing are just checking that 1) I haven't
> gone too deep in the trie (I actually want the last node *before* the leaf --
> "contextDepth" is the max depth of the trie), 2) that I haven't run out of
> ints in the sequence, and 3) that I actually found branch to continue
> searching down. If trie doesn't have a match for the start of the sequence,
> the nil return is handled by the caller.
>
> Can anyone see why the caller is getting the first match, rather than the
> last?
> Immense thanks to anyone who can see what's up.
>
> J.
>
>
> James B Maxwell
> Composer/Doctoral Student
> School for the Contemporary Arts (SCA)
> School for Interactive Arts + Technology (SIAT)
> Simon Fraser University
> jbmaxw...@rubato-music.com
> jbmax...@sfu.ca
>
> ___
>
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>
> Help/Unsubscribe/Update your Subscription:
> http://lists.apple.com/mailman/options/cocoa-dev/hsiegel%40gmail.com
>
> This email sent to hsie...@gmail.com
>
James B Maxwell
Composer/Doctoral Student
School for the Contemporary Arts (SCA)
School for Interactive Arts + Technology (SIAT)
Simon Fraser University
jbmaxw...@rubato-music.com
jbmax...@sfu.ca
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
method caller mixup
I have a couple of node-based classes, one to build a Lempel-Ziv tree (Incremental Parsing) and one to build a Trie. Both of these classes have an -initWithParent: method. Should be fine, I would think, but I'm getting a compiler error that a Trie node's initWithParent is expecting the Lempel-Ziv node as input. I can't see any reason why this would happen. Is there any tricky cause for a matching method name, in a totally different class, to get called? I tried cleaning the project, to no avail. It would be too complicated to post the code, but the context of the error is something like this: HSMM_TrieNode* newNode = [[HSMM_TrieNode alloc] initWithParent:aNode]; And yes, "aNode" is very definitely an HSMM_TrieNode, not a Lempel-Ziv node. The HSMM_TrieNode class has no idea that the Lempel-Ziv node class even exists... Has anyone seen this kind of mixup? thanks, J. James B Maxwell Composer/Doctoral Student School for the Contemporary Arts (SCA) School for Interactive Arts + Technology (SIAT) Simon Fraser University jbmaxw...@rubato-music.com jbmax...@sfu.ca ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: method caller mixup
Thanks folks,
I actually did wind up type casting the alloc, as recommended. Sorry I didn't
post when I found the solution.
I guess I've just never come across this before, which seems kind of strange...
but true.
cheers,
J.
On 2010-04-17, at 12:42 PM, Paul Sanders wrote:
> > It's not particularly tricky. +alloc returns an id, and Objective-C doesn't
> > have operand-overloaded methods.
> > There is nothing in your alloc/init expression that tells the _compiler_
> > which of the differently-defined initWithParent:
> > methods you intend to use, so it picks one in some undefined way. In this
> > case, it picked the one you didn't intend.
> >
> > You can force the choice by casting the result of +alloc to the intended
> > type:
> >
> > [ (HSMM_TrieNode *)[HSMM_TrieNode alloc] initWithParent: aNode ]
>
> -Wstrict-selector-match would have reported the ambiguity. Otherwise, the
> following code compiles without complaint (this is on gcc 4.0; on gcc 4.2 the
> warning flag might be on by default):
>
> @interface Class1 : NSObject
> - (id) initWithScalar: (int) i;
> @end
>
> @interface Class2 : NSObject
> - (id) initWithScalar: (float) f;
> @end
>
> void test (void)
> {
> Class1 *o1 = [[Class1 alloc] initWithScalar: 1];
> Class1 *o2 = [[Class1 alloc] initWithScalar: 1.0f];
> Class2 *o3 = [[Class2 alloc] initWithScalar: 1];
> Class2 *o4 = [[Class2 alloc] initWithScalar: 1.0f];
> }
>
> However, two of these four init method invocations will get a parameter in a
> form (int vs float) they don't expect since the compiler doesn't have enough
> information to perform the expected implicit type conversion across the call,
> and that is not good.
> As for the scope and interpretation of method names, this might be worth a
> look if you haven't already:
>
> http://developer.apple.com/Mac/library/documentation/Cocoa/Conceptual/ObjectiveC/Articles/ocSelectors.html#//apple_ref/doc/uid/TP30001163-CH23-SW1
>
> Paul Sanders.
>
James B Maxwell
Composer/Doctoral Student
School for the Contemporary Arts (SCA)
School for Interactive Arts + Technology (SIAT)
Simon Fraser University
jbmaxw...@rubato-music.com
jbmax...@sfu.ca
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: method caller mixup
yes, good point. That would certainly make things simpler. J. On 2010-04-17, at 1:31 PM, Uli Kusterer wrote: > On 17.04.10 22:24, James Maxwell wrote: >> I actually did wind up type casting the alloc, as recommended. Sorry I >> didn't post when I found the solution. >> I guess I've just never come across this before, which seems kind of >> strange... but true. > > By the way: An even better idea is to just change the name, i.e. instead of > -initWithParent: call it -initWithParentTrieNode:. > > -- > Cheers, > -- Uli Kusterer > "The Witnesses of TeachText are everywhere..." > http://www.zathras.de James B Maxwell Composer/Doctoral Student School for the Contemporary Arts (SCA) School for Interactive Arts + Technology (SIAT) Simon Fraser University jbmaxw...@rubato-music.com jbmax...@sfu.ca ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
crash on altering NSMutableArray
I'm having a crash when trying to remove the last item in an NSMutableArray. The app is a pretty complex system, and runs its two main processes in consecutively executed blocks. The blocks are run using dispatch_apply, on the global queue. The operation that's trying to access the NSArray is, I think, within the first block... but honestly, I can't be totally sure, as I don't know exactly why the app is crashing. I guess what I'm wondering is whether there's some fool-proof way of protecting that NSArray from being read and changed simultaneously? I tried making the array nonatomic, but that didn't solve the problem. Of note is the fact that this is directly related to processing load, so I'm assuming it has to do with some timing thing -- as the app gets more loaded down, things get sketchy. I know this isn't a great description of the problem, but hopefully someone has some thoughts to share. Thanks in advance, J. James B Maxwell Composer/Doctoral Student School for the Contemporary Arts (SCA) School for Interactive Arts + Technology (SIAT) Simon Fraser University jbmaxw...@rubato-music.com jbmax...@sfu.ca ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: crash on altering NSMutableArray
[aNode
setInputCounter:([aNode inputCounter] + 1)];
[aNode
run:nil];
}
}
});
}
for(i=numLevels - 1;i >= 0;--i) // run
back down the network
{
NSMutableArray* level = [[[self network] hierarchy]
objectAtIndex:i];
dispatch_apply([level count],
hsmm_queue,
^(size_t index) {
HSMM_Node* aNode;
aNode = [level
objectAtIndex:index];
[aNode
getEvidenceFromParents];
[aNode topDown:[aNode
parentEvidence]];
if([aNode nodeLevel] == 1)
[[aNode sequencer]
predictForward:NO];
});
}
}
On 2010-05-01, at 5:17 PM, Kyle Sluder wrote:
> On May 1, 2010, at 5:04 PM, James Maxwell wrote:
>
>> I'm having a crash when trying to remove the last item in an NSMutableArray.
>> The app is a pretty complex system, and runs its two main processes in
>> consecutively executed blocks.
>> The blocks are run using dispatch_apply, on the global queue. The operation
>> that's trying to
>> access the NSArray is, I think, within the first block... but honestly, I
>> can't be totally sure, as
>> I don't know exactly why the app is crashing.
>
> Yes you do. You have a debugger and a stack trace.
>
>> I guess what I'm wondering is whether there's some fool-proof way of
>> protecting that NSArray from being read and changed simultaneously?
>> I tried making the array nonatomic, but that didn't solve the problem.
>> Of note is the fact that this is directly related to processing load, so I'm
>> assuming it has to do
>> with some timing thing -- as the app gets more loaded down, things get
>> sketchy.
>
> The concept you're looking for is thread safety. It is, in general, a Very
> Hard Problem.
>
>
>> I know this isn't a great description of the problem, but hopefully someone
>> has some thoughts to share.
>
> If you have a crash, the only two useful pieces of information are the source
> code and the stack trace. Anything else risks misinterpretation and therefore
> wasted time.
>
> --Kyle Sluder
James B Maxwell
Composer/Doctoral Student
School for the Contemporary Arts (SCA)
School for Interactive Arts + Technology (SIAT)
Simon Fraser University
jbmaxw...@rubato-music.com
jbmax...@sfu.ca
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: crash on altering NSMutableArray
just to call off the dogs, in case there are any, I solved the crash by
re-working the logic a little.
It's cleaner the new way anyway, though I don't know whether the concurrency
stuff is really fixed
(or whether it was "really" broken!)
It works, and I'm a tight deadline, so that's all that matters!
J.
On 2010-05-01, at 5:54 PM, James Maxwell wrote:
> Okay, so let me give a little more info.
>
> Here's the stack trace.
>
> #00x7fff8578693c in __CFTypeCollectionRelease
> #10x7fff85783e43 in __CFArrayReleaseValues
> #20x7fff85764bc8 in _CFArrayReplaceValues
> #30x1000183ad in -[HSMM_Node addCoincidenceToBeliefMemory:] at
> HSMM_Node.m:229
> #40x100017803 in -[HSMM_Node topDown:] at HSMM_Node.m:121
> #50x100012a94 in __-[HSMM_NetworkController
> runNetworkOnInput:]_block_invoke_555 at HSMM_NetworkController.m:225
> #60x7fff804f3e68 in _dispatch_apply2
> #70x7fff804eb487 in dispatch_apply_f
> #80x10001232e in -[HSMM_NetworkController runNetworkOnInput:] at
> HSMM_NetworkController.m:218
> #90x15050 in __-[OSC_Controller receivedOSCMessage:]_block_invoke_876
> at OSC_Controller.m:252
> #10 0x7fff804a1e63 in dispatch_sync_f
> #11 0x14155 in -[OSC_Controller receivedOSCMessage:] at
> OSC_Controller.m:251
> #12 0x10008a2bc in -[OSCManager receivedOSCMessage:] at OSCManager.m:232
> #13 0x10008af82 in -[OSCInPort handleScratchArray:] at OSCInPort.m:262
> #14 0x10008bc5f in -[OSCInPort OSCThreadProc] at OSCInPort.m:240
> #15 0x100054797 in -[VVThreadLoop threadCallback] at VVThreadLoop.m:76
> #16 0x7fff81943e99 in __NSThread__main__
> #17 0x7fff804a5f8e in _pthread_start
> #18 0x7fff804a5e41 in thread_start
>
> And the source for the method does does all the work is below. This wraps
> everything up in a couple of blocks.
> The second loop is the one that's causing the crash and the only way I think
> this could happen would be if the
> first loop hadn't completed. My, possibly totally misinformed, opinion was
> that this method would run the
> first loop to completion, then run the second. That is, all "aNode" objects
> would do their thing in the first loop
> **before** the second loop could start. But maybe I'm wrong about that. I
> have to admit that my grasp
> of GCD is pretty sketchy. If this isn't the case, and the second loop could,
> in fact, start running before all
> the aNode objects in the first loop had finished their processing, then I can
> totally understand why it would
> crash. Is there some way to ensure that? How would I make sure that
> *everything* started in the first
> loop finished before moving on to the second. If I do that, then my crash
> should be solved.
>
> - (void) runNetworkOnInput:(float *)inputPattern
> {
> printf("\n\n* Start Run \n\n");
> int i, numLevels;
> numLevels = [[[self network] hierarchy] count];
>
> dispatch_queue_t hsmm_queue;
> hsmm_queue = dispatch_get_global_queue(0, 0);
>
> [self setPlaybackPossible:YES];
>
> for(i=0;i < numLevels;i++)
> // run up the network
> {
> NSMutableArray* level = [[[self network] hierarchy]
> objectAtIndex:i];
> dispatch_apply([level count],
> hsmm_queue,
> ^(size_t index) {
> HSMM_Node* aNode = [level
> objectAtIndex:index];
> [aNode setIsPassive:NO];
> if([aNode nodeLevel] == 1)
> {
> [aNode
> setPredictionRequestsLocked:NO];
> [aNode
> setInputCounter:([aNode inputCounter] + 1)];
> [aNode run:nil];
> } else {
> BOOL readyToLearn =
> YES;
> for(HSMM_Node* child
> in [aNode childNodes])
> {
> if([child
> nodeLevel] == 1 && [[child sequencer] predictionAccuracy] < 0.3)
> {
>
Re: crash on altering NSMutableArray
ugh... okay, so changing the logic cured the crashes, but also negatively
impacted the system (it's a machine-learning thing, and the old logic was
crucial to the predictive power of the system).
So, I'm back to the crash.
So, looking more closely at the NSArray itself in the debugger, the items in
the array come up as
0 NSCFNumber*
1 NSCFNumber*
2 NSObject*
3 _NSZombie_CFNumber*
4 NSObject*
I have to confess, I have no idea why they aren't all NSCFNumbers, as that's
all I'm putting in the array.
In particular, I'm curious about the _NSZombie one, as I'm assuming that's the
one that's probably causing the problems, yes?
help!
J.
On 2010-05-01, at 7:19 PM, James Maxwell wrote:
> just to call off the dogs, in case there are any, I solved the crash by
> re-working the logic a little.
> It's cleaner the new way anyway, though I don't know whether the concurrency
> stuff is really fixed
> (or whether it was "really" broken!)
>
> It works, and I'm a tight deadline, so that's all that matters!
>
> J.
>
>
>
> On 2010-05-01, at 5:54 PM, James Maxwell wrote:
>
>> Okay, so let me give a little more info.
>>
>> Here's the stack trace.
>>
>> #0 0x7fff8578693c in __CFTypeCollectionRelease
>> #1 0x7fff85783e43 in __CFArrayReleaseValues
>> #2 0x7fff85764bc8 in _CFArrayReplaceValues
>> #3 0x1000183ad in -[HSMM_Node addCoincidenceToBeliefMemory:] at
>> HSMM_Node.m:229
>> #4 0x100017803 in -[HSMM_Node topDown:] at HSMM_Node.m:121
>> #5 0x100012a94 in __-[HSMM_NetworkController
>> runNetworkOnInput:]_block_invoke_555 at HSMM_NetworkController.m:225
>> #6 0x7fff804f3e68 in _dispatch_apply2
>> #7 0x7fff804eb487 in dispatch_apply_f
>> #8 0x10001232e in -[HSMM_NetworkController runNetworkOnInput:] at
>> HSMM_NetworkController.m:218
>> #9 0x15050 in __-[OSC_Controller receivedOSCMessage:]_block_invoke_876
>> at OSC_Controller.m:252
>> #10 0x7fff804a1e63 in dispatch_sync_f
>> #11 0x14155 in -[OSC_Controller receivedOSCMessage:] at
>> OSC_Controller.m:251
>> #12 0x10008a2bc in -[OSCManager receivedOSCMessage:] at OSCManager.m:232
>> #13 0x10008af82 in -[OSCInPort handleScratchArray:] at OSCInPort.m:262
>> #14 0x10008bc5f in -[OSCInPort OSCThreadProc] at OSCInPort.m:240
>> #15 0x100054797 in -[VVThreadLoop threadCallback] at VVThreadLoop.m:76
>> #16 0x7fff81943e99 in __NSThread__main__
>> #17 0x7fff804a5f8e in _pthread_start
>> #18 0x7fff804a5e41 in thread_start
>>
>> And the source for the method does does all the work is below. This wraps
>> everything up in a couple of blocks.
>> The second loop is the one that's causing the crash and the only way I think
>> this could happen would be if the
>> first loop hadn't completed. My, possibly totally misinformed, opinion was
>> that this method would run the
>> first loop to completion, then run the second. That is, all "aNode" objects
>> would do their thing in the first loop
>> **before** the second loop could start. But maybe I'm wrong about that. I
>> have to admit that my grasp
>> of GCD is pretty sketchy. If this isn't the case, and the second loop could,
>> in fact, start running before all
>> the aNode objects in the first loop had finished their processing, then I
>> can totally understand why it would
>> crash. Is there some way to ensure that? How would I make sure that
>> *everything* started in the first
>> loop finished before moving on to the second. If I do that, then my crash
>> should be solved.
>>
>> - (void) runNetworkOnInput:(float *)inputPattern
>> {
>> printf("\n\n* Start Run \n\n");
>> int i, numLevels;
>> numLevels = [[[self network] hierarchy] count];
>>
>> dispatch_queue_t hsmm_queue;
>> hsmm_queue = dispatch_get_global_queue(0, 0);
>>
>> [self setPlaybackPossible:YES];
>>
>> for(i=0;i < numLevels;i++)
>> // run up the network
>> {
>> NSMutableArray* level = [[[self network] hierarchy]
>> objectAtIndex:i];
>> dispatch_apply([level count],
>> hsmm_queue,
>> ^(size_t index) {
>> HSMM_Node* aNode = [level
>> objectAtIndex:index];
>> [aNode setIs
Re: crash on altering NSMutableArray
Poking around some more...
If I drop into the debugger arbitrarily, before the crash, and check this same
array, I noticed that it is nicely filled with NSCFNumbers. But, strangely,
there are too many. The code that fills this array, is this:
- (void)
addCoincidenceToBeliefMemory:(int)coincidence
{
if(coincidence == 0)
return;
int memDepth = [[self sequencer] memoryDepth] - 1;
NSMutableArray* beliefMem = [self beliefMemory];
NSNumber* memCoinc = [[NSNumber alloc] initWithInt:coincidence];
[beliefMem insertObject:memCoinc atIndex:0];
UInt memCount = [beliefMem count];
if(memCount > memDepth)
[beliefMem removeLastObject];
[memCoinc release];
}
It's set up as a stack, so I can just grab the latest number from index 0. I
know the memDepth, is **always** 5, because this is set elsewhere, and is never
changed -- it's accessed by [[self sequencer] memoryDepth]. But I'm looking at
the array right now, and it has 7 objects in it. How is that even possible?
Getting very confused... Help appreciated.
J.
On 2010-05-01, at 8:42 PM, James Maxwell wrote:
> ugh... okay, so changing the logic cured the crashes, but also negatively
> impacted the system (it's a machine-learning thing, and the old logic was
> crucial to the predictive power of the system).
> So, I'm back to the crash.
>
> So, looking more closely at the NSArray itself in the debugger, the items in
> the array come up as
>
> 0 NSCFNumber*
> 1 NSCFNumber*
> 2 NSObject*
> 3 _NSZombie_CFNumber*
> 4 NSObject*
>
> I have to confess, I have no idea why they aren't all NSCFNumbers, as that's
> all I'm putting in the array.
> In particular, I'm curious about the _NSZombie one, as I'm assuming that's
> the one that's probably causing the problems, yes?
>
> help!
>
> J.
>
>
> On 2010-05-01, at 7:19 PM, James Maxwell wrote:
>
>> just to call off the dogs, in case there are any, I solved the crash by
>> re-working the logic a little.
>> It's cleaner the new way anyway, though I don't know whether the concurrency
>> stuff is really fixed
>> (or whether it was "really" broken!)
>>
>> It works, and I'm a tight deadline, so that's all that matters!
>>
>> J.
>>
>>
>>
>> On 2010-05-01, at 5:54 PM, James Maxwell wrote:
>>
>>> Okay, so let me give a little more info.
>>>
>>> Here's the stack trace.
>>>
>>> #0 0x7fff8578693c in __CFTypeCollectionRelease
>>> #1 0x7fff85783e43 in __CFArrayReleaseValues
>>> #2 0x7fff85764bc8 in _CFArrayReplaceValues
>>> #3 0x1000183ad in -[HSMM_Node addCoincidenceToBeliefMemory:] at
>>> HSMM_Node.m:229
>>> #4 0x100017803 in -[HSMM_Node topDown:] at HSMM_Node.m:121
>>> #5 0x100012a94 in __-[HSMM_NetworkController
>>> runNetworkOnInput:]_block_invoke_555 at HSMM_NetworkController.m:225
>>> #6 0x7fff804f3e68 in _dispatch_apply2
>>> #7 0x7fff804eb487 in dispatch_apply_f
>>> #8 0x10001232e in -[HSMM_NetworkController runNetworkOnInput:] at
>>> HSMM_NetworkController.m:218
>>> #9 0x15050 in __-[OSC_Controller receivedOSCMessage:]_block_invoke_876
>>> at OSC_Controller.m:252
>>> #10 0x7fff804a1e63 in dispatch_sync_f
>>> #11 0x14155 in -[OSC_Controller receivedOSCMessage:] at
>>> OSC_Controller.m:251
>>> #12 0x10008a2bc in -[OSCManager receivedOSCMessage:] at OSCManager.m:232
>>> #13 0x10008af82 in -[OSCInPort handleScratchArray:] at OSCInPort.m:262
>>> #14 0x10008bc5f in -[OSCInPort OSCThreadProc] at OSCInPort.m:240
>>> #15 0x100054797 in -[VVThreadLoop threadCallback] at VVThreadLoop.m:76
>>> #16 0x7fff81943e99 in __NSThread__main__
>>> #17 0x7fff804a5f8e in _pthread_start
>>> #18 0x7fff804a5e41 in thread_start
>>>
>>> And the source for the method does does all the work is below. This wraps
>>> everything up in a couple of blocks.
>>> The second loop is the one that's causing the crash and the only way I
>>> think this could happen would be if the
>>> first loop hadn't completed. My, possibly totally misinformed, opinion was
>>> that this method would run the
>>> first loop to completion, then run the second. That is, all "aNode"
>>> objects would do their thing in the first loop
>>> **before** the second loop could start. But maybe I'm wrong about that. I
>>> have to admit that my grasp
>>> of GCD is pretty sketchy
Re: crash on altering NSMutableArray
>>
>
> This strongly suggests a memory management problem -- something is
> over-releasing the items in the array.
>
okay, this is what I figured, but I can't see anywhere where this could be
happening.
> On May 1, 2010, at 21:22, James Maxwell wrote:
>
>> If I drop into the debugger arbitrarily, before the crash, and check this
>> same array, I noticed that it is nicely filled with NSCFNumbers. But,
>> strangely, there are too many.
>
> My guess is that you've still got multiple threads accessing the mutable
> array simultaneously, and that's not thread-safe if one of the accesses is
> changing the array.
Well, there's only one object that "changes" the array, so I don't know how
this could happen.
I would like to know, though, whether this:
for(i=numLevels - 1;i >= 0;--i) // run
back down the network
{
NSMutableArray* level = [[[self network] hierarchy]
objectAtIndex:i];
dispatch_apply([level count],
hsmm_queue,
^(size_t index) {
HSMM_Node* aNode;
aNode = [level
objectAtIndex:index];
[aNode
getEvidenceFromParents];
[aNode topDown:[aNode
parentEvidence]];
if([aNode nodeLevel] == 1)
[[aNode sequencer]
predictForward:NO];
});
}
will process all of the "aNode" objects on the current "level", before moving
on to the next "level"?
My intention with the above code is to process each level in parallel, but to
finish processing a level before moving to the next level. If this is not the
proper way to do that, I'd really appreciate any help in correcting this code.
thanks,
J.
___
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: crash on altering NSMutableArray
Yes, this all makes sense to me. I'm not super advanced, but I do at least understand the idea of keeping reads/writes temporally distinct. Anyway, it looks like I found the problem. There was a somewhat unnecessary (or at least easily avoidable call) happening to a method that **does** tamper with that array. I worked around it and it hasn't crashed so far. Fingers crossed. I really only need this to work for about the next hour, while I run some tests and finish my paper! ;-) thanks for your trouble. J. On 2010-05-01, at 10:55 PM, Michael Ash wrote: > On Sun, May 2, 2010 at 1:50 AM, James Maxwell > wrote: >>> On May 1, 2010, at 21:22, James Maxwell wrote: >>> >>>> If I drop into the debugger arbitrarily, before the crash, and check this >>>> same array, I noticed that it is nicely filled with NSCFNumbers. But, >>>> strangely, there are too many. >>> >>> My guess is that you've still got multiple threads accessing the mutable >>> array simultaneously, and that's not thread-safe if one of the accesses is >>> changing the array. >> >> Well, there's only one object that "changes" the array, so I don't know how >> this could happen. > > It's a common misconception that the only worry with thread safety is > avoiding multiple writers. > > All it takes to crash is a single write, happening simultaneous with a > read. A class that's not thread safe will not tolerate this, and can > crash. In general, multiple readers is fine, but the moment you make > any changes, you MUST not have ANY reads occurring for the duration of > the write. > > Basically, unless you know enough about multithreading to start doing > really advanced things (and when I say "really advanced", I mean the > sort of level which most people never even reach), you MUST lock (or > otherwise protect, e.g. funneling through a single thread, GCD serial > queue, etc.) ALL accesses to any shared objects. > > Mike > ___ > > 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/jbmaxwell%40rubato-music.com > > This email sent to jbmaxw...@rubato-music.com James B Maxwell Composer/Doctoral Student School for the Contemporary Arts (SCA) School for Interactive Arts + Technology (SIAT) Simon Fraser University jbmaxw...@rubato-music.com jbmax...@sfu.ca ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Get controller from nib
Hello All, I'm working on MIDI set-up customization for my music app. I have a main controller object, called Central_MIDI_Controller, that uses the VVMIDI framework to detect MIDI ports, and handle low-level MIDI stuff. I have an object called MIDIInstrument, which is a simple wrapper-type object, intended to bundle together a name string with a MIDI port, channel, and some program change "presets", defined by the user. I've put the Central_MIDI_Controller in my MainMenu.nib, and it's settings are stored in the UserDefaults. I put it there because I want it to persist across different documents. What I'm wondering about is how to get the list of available MIDI ports to the MIDIInstrument objects, which will be created dynamically, as the user creates customized instances of MIDIInstrument. What I'm not understanding is how to allow newly created MIDIInstrument objects to read the available/enabled ports from Central_MIDI_Controller. I know this is probably really simple, but how do I grab a reference to a controller object loaded only in the MainMenu.nib file? thanks in advance, J. James B Maxwell Composer/Doctoral Student School for the Contemporary Arts (SCA) School for Interactive Arts + Technology (SIAT) Simon Fraser University jbmaxw...@rubato-music.com jbmax...@sfu.ca ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Get controller from nib
okay, so I kind of hacked around it. I gave my AppController (which is a delegate of File's Owner) an outlet for the Central_MIDI_Controller, and hooked that up in IB. Then I also gave the AppController an accessor for "midiController", that returns the reference to Central_MIDI_Controller connected in IB. From the MIDIInstrument init, I can run [[NSApp delegate] midiController] and get the instance of Central_MIDI_Controller loaded in the nib. As I say, it feels a bit hackish. Though it does work, and advice is still welcome. cheers, J. On 2010-05-18, at 4:28 PM, James Maxwell wrote: > > Hello All, > > I'm working on MIDI set-up customization for my music app. I have a main > controller object, called Central_MIDI_Controller, that uses the VVMIDI > framework to detect MIDI ports, and handle low-level MIDI stuff. I have an > object called MIDIInstrument, which is a simple wrapper-type object, intended > to bundle together a name string with a MIDI port, channel, and some program > change "presets", defined by the user. > I've put the Central_MIDI_Controller in my MainMenu.nib, and it's settings > are stored in the UserDefaults. I put it there because I want it to persist > across different documents. What I'm wondering about is how to get the list > of available MIDI ports to the MIDIInstrument objects, which will be created > dynamically, as the user creates customized instances of MIDIInstrument. > What I'm not understanding is how to allow newly created MIDIInstrument > objects to read the available/enabled ports from Central_MIDI_Controller. I > know this is probably really simple, but how do I grab a reference to a > controller object loaded only in the MainMenu.nib file? > > thanks in advance, > > J. > > > > James B Maxwell > Composer/Doctoral Student > School for the Contemporary Arts (SCA) > School for Interactive Arts + Technology (SIAT) > Simon Fraser University > jbmaxw...@rubato-music.com > jbmax...@sfu.ca > > ___ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > Please do not post admin requests or moderator comments to the list. > Contact the moderators at cocoa-dev-admins(at)lists.apple.com > > Help/Unsubscribe/Update your Subscription: > http://lists.apple.com/mailman/options/cocoa-dev/jbmaxwell%40rubato-music.com > > This email sent to jbmaxw...@rubato-music.com James B Maxwell Composer/Doctoral Student School for the Contemporary Arts (SCA) School for Interactive Arts + Technology (SIAT) Simon Fraser University jbmaxw...@rubato-music.com jbmax...@sfu.ca ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Get controller from nib
Hey Mark, Thanks for this, but it points out one confusion i have. If I thought it would be fine to just have MIDIInstrument in the nib, everything would be simple. But my (mis)understanding was that putting the MIDIInstrument in the nib would only apply to that single instance. Is that not correct? I need to be able to create an arbitrary number of MIDIInstrument objects, programmatically (actually, in a kind of "Instrument set-up" NSTableView), and for that reason I've avoided putting an instance of MIDIInstrument in the nib... So, currently, the nib doesn't contain any MIDIInstrument object at all. I load MIDIInstrument objects using a "+" button connected to "add" in an NSArrayController for MIDIInstruments, which adds rows to an NSTableView. The table gives the name, port, channel of the new MIDIInstrument, with default values, which the user can then set as desired (just double-click for name, and PopUpButtonCells for port and channel). Anyway, I do like the sound of your design... So, does the instance loaded in IB become a one-off, or does it somehow "alias" (for lack of a better word) all future instances? I was under the impression that the instance in IB was just a single instance, and that it wouldn't have any effect on future instances. thanks a lot. J. On 2010-05-18, at 5:06 PM, Mark Ritchie wrote: > On 18/May/2010, at 4:28 PM, James Maxwell wrote: >> What I'm not understanding is how to allow newly created MIDIInstrument >> objects to read the available/enabled ports from Central_MIDI_Controller. I >> know this is probably really simple, but how do I grab a reference to a >> controller object loaded only in the MainMenu.nib file? > > Hey James, > I would do it this way: > Modify the nib file containing the MIDIInstrument so that FilesOwner is class > Central_MIDI_Controller. > Create an outlet on MIDIInstrument which would point to > Central_MIDI_Controller. > In IB, wire up the outlet from MIDIInstrument to FilesOwner. > Finally change the code which loads the nib containing MIDIInstrument to pass > the one instance of Central_MIDI_Controller as the FilesOwner. > The unarchiving process will handle connecting up the bits at runtime. > HTH, > M. James B Maxwell Composer/Doctoral Student School for the Contemporary Arts (SCA) School for Interactive Arts + Technology (SIAT) Simon Fraser University jbmaxw...@rubato-music.com jbmax...@sfu.ca ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Get controller from nib
Yes, this is basically what I've done, and it does seem to work...
On 2010-05-18, at 4:49 PM, Jens Alfke wrote:
>
> On May 18, 2010, at 4:28 PM, James Maxwell wrote:
>
>> I know this is probably really simple, but how do I grab a reference to a
>> controller object loaded only in the MainMenu.nib file?
>
> You can add an outlet to your app controller object pointing to that
> controller object, and then add an accessor method that returns it.
>
> @interface MyAppController : NSObject
> {
> IBOutlet Central_MIDI_Controller* _midiController;
> }
> @property Central_MIDI_Controller* midiController;
> @end
>
>
> @implementation MyAppController
> @synthesize midiController = _midiController
> @end
>
> Then just wire up _midiController in IB.
>
> —Jens
James B Maxwell
Composer/Doctoral Student
School for the Contemporary Arts (SCA)
School for Interactive Arts + Technology (SIAT)
Simon Fraser University
jbmaxw...@rubato-music.com
jbmax...@sfu.ca
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Get controller from nib
ugh...
Okay, getting a bit deeper into this, I realize I'm still "in the woods", so to
speak. I'm going to have to hook up my NSTableView to set the *selected* port
and channel for the MIDIInstruments, which means it's pretty much going to have
to be loaded in the nib after all (since the MIDIInstrument has to respond to
the selection made in the table). So, if I do that, and make the connections to
Central_MIDI_Controller, as recommended, will the NSArrayController be able to
add new instances of MIDIInstrument (and new rows to my table), which also have
these connections? As I mentioned, I need an arbitrary number of
MIDIInstruments.
Kind of confused about this...
thanks in advance.
J.
On 2010-05-18, at 5:26 PM, James Maxwell wrote:
> Yes, this is basically what I've done, and it does seem to work...
>
> On 2010-05-18, at 4:49 PM, Jens Alfke wrote:
>
>>
>> On May 18, 2010, at 4:28 PM, James Maxwell wrote:
>>
>>> I know this is probably really simple, but how do I grab a reference to a
>>> controller object loaded only in the MainMenu.nib file?
>>
>> You can add an outlet to your app controller object pointing to that
>> controller object, and then add an accessor method that returns it.
>>
>> @interface MyAppController : NSObject
>> {
>> IBOutlet Central_MIDI_Controller* _midiController;
>> }
>> @property Central_MIDI_Controller* midiController;
>> @end
>>
>>
>> @implementation MyAppController
>> @synthesize midiController = _midiController
>> @end
>>
>> Then just wire up _midiController in IB.
>>
>> —Jens
>
> James B Maxwell
> Composer/Doctoral Student
> School for the Contemporary Arts (SCA)
> School for Interactive Arts + Technology (SIAT)
> Simon Fraser University
> jbmaxw...@rubato-music.com
> jbmax...@sfu.ca
>
> ___
>
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>
> Help/Unsubscribe/Update your Subscription:
> http://lists.apple.com/mailman/options/cocoa-dev/jbmaxwell%40rubato-music.com
>
> This email sent to jbmaxw...@rubato-music.com
James B Maxwell
Composer/Doctoral Student
School for the Contemporary Arts (SCA)
School for Interactive Arts + Technology (SIAT)
Simon Fraser University
jbmaxw...@rubato-music.com
jbmax...@sfu.ca
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Get controller from nib
okay, there seems to be a big design flaw here... I think this will all be
simpler if I have a separate MIDI_Instrument_Controller, loaded in the nib,
which can deal with the table and the Central_MIDI_Controller. Then I'll let
the NSArrayController deal with instances of the MIDIInstrument itself. I'm
going to poke away at this for a bit. Sorry for the spam.
J.
On 2010-05-18, at 5:42 PM, James Maxwell wrote:
> ugh...
>
> Okay, getting a bit deeper into this, I realize I'm still "in the woods", so
> to speak. I'm going to have to hook up my NSTableView to set the *selected*
> port and channel for the MIDIInstruments, which means it's pretty much going
> to have to be loaded in the nib after all (since the MIDIInstrument has to
> respond to the selection made in the table). So, if I do that, and make the
> connections to Central_MIDI_Controller, as recommended, will the
> NSArrayController be able to add new instances of MIDIInstrument (and new
> rows to my table), which also have these connections? As I mentioned, I need
> an arbitrary number of MIDIInstruments.
>
> Kind of confused about this...
>
> thanks in advance.
>
> J.
>
>
> On 2010-05-18, at 5:26 PM, James Maxwell wrote:
>
>> Yes, this is basically what I've done, and it does seem to work...
>>
>> On 2010-05-18, at 4:49 PM, Jens Alfke wrote:
>>
>>>
>>> On May 18, 2010, at 4:28 PM, James Maxwell wrote:
>>>
>>>> I know this is probably really simple, but how do I grab a reference to a
>>>> controller object loaded only in the MainMenu.nib file?
>>>
>>> You can add an outlet to your app controller object pointing to that
>>> controller object, and then add an accessor method that returns it.
>>>
>>> @interface MyAppController : NSObject
>>> {
>>> IBOutlet Central_MIDI_Controller* _midiController;
>>> }
>>> @property Central_MIDI_Controller* midiController;
>>> @end
>>>
>>>
>>> @implementation MyAppController
>>> @synthesize midiController = _midiController
>>> @end
>>>
>>> Then just wire up _midiController in IB.
>>>
>>> —Jens
>>
>> James B Maxwell
>> Composer/Doctoral Student
>> School for the Contemporary Arts (SCA)
>> School for Interactive Arts + Technology (SIAT)
>> Simon Fraser University
>> jbmaxw...@rubato-music.com
>> jbmax...@sfu.ca
>>
>> ___
>>
>> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>>
>> Please do not post admin requests or moderator comments to the list.
>> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>>
>> Help/Unsubscribe/Update your Subscription:
>> http://lists.apple.com/mailman/options/cocoa-dev/jbmaxwell%40rubato-music.com
>>
>> This email sent to jbmaxw...@rubato-music.com
>
> James B Maxwell
> Composer/Doctoral Student
> School for the Contemporary Arts (SCA)
> School for Interactive Arts + Technology (SIAT)
> Simon Fraser University
> jbmaxw...@rubato-music.com
> jbmax...@sfu.ca
>
> ___
>
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>
> Help/Unsubscribe/Update your Subscription:
> http://lists.apple.com/mailman/options/cocoa-dev/jbmaxwell%40rubato-music.com
>
> This email sent to jbmaxw...@rubato-music.com
James B Maxwell
Composer/Doctoral Student
School for the Contemporary Arts (SCA)
School for Interactive Arts + Technology (SIAT)
Simon Fraser University
jbmaxw...@rubato-music.com
jbmax...@sfu.ca
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Get controller from nib
okay, going slightly nuts. I've implemented my MIDI_Instrument_Controller object, and hooked it up to my table view, but it's complaining about implementing numberOrRowsInTableView and tableView:objectValueForTableColumn:row:. Fine, except that I very definitely have implemented them. I tried cleaning, and reloading classes in IB, to no avail. Has anyone seen this? Any solutions? J. On 2010-05-18, at 6:27 PM, Mark Ritchie wrote: > Hey James! > > On 18/May/2010, at 5:42 PM, James Maxwell wrote: >> Okay, getting a bit deeper into this, I realize I'm still "in the woods", so >> to speak. I'm going to have to hook up my NSTableView to set the *selected* >> port and channel for the MIDIInstruments, which means it's pretty much going >> to have to be loaded in the nib after all (since the MIDIInstrument has to >> respond to the selection made in the table). So, if I do that, and make the >> connections to Central_MIDI_Controller, as recommended, will the >> NSArrayController be able to add new instances of MIDIInstrument (and new >> rows to my table), which also have these connections? As I mentioned, I need >> an arbitrary number of MIDIInstruments. > > It seems to me that you are not separating the model, view and controller > bits. > To me, MIDIInstrument sounds like it's part of the Model (the internal state > of things) and it should not be talking directly to the TableView. The > controller in the middle should be tracking and co-ordinating things. > I hope that helps! > M. James B Maxwell Composer/Doctoral Student School for the Contemporary Arts (SCA) School for Interactive Arts + Technology (SIAT) Simon Fraser University jbmaxw...@rubato-music.com jbmax...@sfu.ca ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Get controller from nib
oh jeez... This is making me crazy. For some reason, my NSArrayController appears to be calling "count" on MIDIInstrument objects. No idea why. I could see it calling count on the array it's controlling, but not an object in that array. Has anyone come across this problem? I have a MIDI_Instrument_Controller class/object that holds an array of MIDIInstrument objects called "instrumentLibrary", then in my NSArrayController bindings I set: Content Array --> MIDI_Instrument_Controller.instrumentLibrary As I say, there's no good reason (that I can think of) why "count" would be called on a MIDIInstrument object... whassup? J. On 2010-05-19, at 8:20 AM, Mark Ritchie wrote: > On 18/May/2010, at 8:49 PM, James Maxwell wrote: >> Yes, this is absolutely right, as my last post suggests -- MIDIInstrument >> was getting a bit blurred MVC-wise. As I properly wrap my head around table >> views, as well, I think it's becoming clearer what I have to do. I may post >> again when I've got a better plan worked out, just to see if you have any >> thoughts. >> Thanks for your time. > > You're welcome! > Good luck! > M. ___ 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: Get controller from nib
So, I decided to get rid of the NSArrayController, since it was driving me
slightly crazy, and just do this manually. I've got the table **appearing** as
I'd like it to, but I can't change the selection. There are 3 columns: 1)
string, 2) NSPopUpButtonCell for MIDI ports, and 3) NSPopUpButtonCell for MIDI
channels. Basically, nothing can be changed. It comes up as 1) "default" (set
in the init of MIDIInstrument), 2) as item 2 in column 2's popup, and 3) as
item 2 in column 3's popup.
I don't know if maybe I have the functions of these two methods reversed
somehow, or what. The naming of the methods is a bit unclear. I'm assuming that
"objectValueForTableColumn" would mean what I want to "give" to the table for
display, whereas "setObjectValue:forTableColumn" would be what I want to "give"
to my object, from the table. Mind you, the latter would be clearer as
"setObjectValue:fromTableColumn", if that was the case... dunno...
Here's my manual code for updating the table:
- (id) tableView:(NSTableView *)tv objectValueForTableColumn:(NSTableColumn
*)tc row:(NSInteger)row
{
if(tv == midiInstrumentsTable)
{
id inst = [[self instrumentLibrary] objectAtIndex:row];
if(inst == nil)
return nil;
if(tc == midiInstNamesColumn)
{
// give the name for the associated MIDIInstrument
return [inst MIDI_Inst_Name];
}
else if(tc == midiPortsColumn)
{
// list the ports for the associated MIDIInstrument
NSPopUpButtonCell* ports = [tc dataCell];
[ports removeAllItems];
int i;
for(i=0;i < [[inst MIDI_Inst_Ports] count];i++)
[ports addItemWithTitle:[[inst MIDI_Inst_Ports]
objectAtIndex:i]];
return ports;
}
else if(tc == midiChannelsColumn)
{
// list the channels for the associated MIDIInstrument
(just 16 numbers)
NSPopUpButtonCell* channels = [tc dataCell];
[channels removeAllItems];
int i;
for(i=0;i < 16;i++)
[channels addItemWithTitle:[NSString
stringWithFormat:@"%i", i+1]];
return channels;
}
}
return nil;
}
- (void) tableView:(NSTableView *)tv setObjectValue:(id)v
forTableColumn:(NSTableColumn *)tc row:(NSInteger)row
{
if (tv == midiInstrumentsTable)
{
id inst = [[self instrumentLibrary] objectAtIndex:row];
if(inst == nil)
return;
if (tc == midiInstNamesColumn)
{
// set the given name
[inst setMIDI_Inst_Name:[[tc dataCell] title]];
}
else if(tc == midiPortsColumn)
{
// set the selected port
[inst setMIDI_Inst_Port:[[[tc dataCell] selectedItem]
title]];
}
else if(tc == midiChannelsColumn)
{
// set the selected channel
[inst setMIDI_Inst_Channel:[NSNumber
numberWithInt:tc dataCell] selectedItem] title] integerValue]]];
}
}
}
Any help very much appreciated.
J.
On 2010-05-19, at 2:19 PM, James Maxwell wrote:
> okay, going slightly nuts. I've implemented my MIDI_Instrument_Controller
> object, and hooked it up to my table view, but it's complaining about
> implementing numberOrRowsInTableView and
> tableView:objectValueForTableColumn:row:. Fine, except that I very definitely
> have implemented them. I tried cleaning, and reloading classes in IB, to no
> avail. Has anyone seen this? Any solutions?
>
> J.
>
>
>
> On 2010-05-18, at 6:27 PM, Mark Ritchie wrote:
>
>> Hey James!
>>
>> On 18/May/2010, at 5:42 PM, James Maxwell wrote:
>>> Okay, getting a bit deeper into this, I realize I'm still "in the woods",
>>> so to speak. I'm going to have to hook up my NSTableView to set the
>>> *selected* port and channel for the MIDIInstruments, which means it's
>>> pretty much going to have to be loaded in the nib after all (since the
>>> MIDIInstrument has to respond to the selection made in the table). So, if I
>>> do that, and make the connections to Central_MIDI_Controller, as
>>> recommended, will the NSArrayController be able to a
Displaying NSPopUpButtonCells in NSTableView
I thought I'd change the topic on this, since the content really has changed.
I have an table for setting up MIDI instruments with a name, port, and channel.
I've got the initial display of options for the table row displaying correctly,
and when I make changes to the name, port, and channel, the data object is
updated correctly. The only thing left is that the popups in columns 2 and 3
are not holding the selected value. I understand that this is probably because
I'm reloading the menu in tableView:objectValueForTableColumn:row, but I'm not
sure how to get around it.
Here's the code I've got so far. I'm not using an NSArrayController, because
that approach was driving me absolutely mental...
I've copied all the code (except imports) to be thorough. Logging "Edited
MIDIInstrument" at the end shows that the instrument is set up correctly, with
the desire name, port, and channel. It's just that the popups always display
the 2nd item.
thanks,
J.
@implementation MIDI_Instrument_Controller
@synthesize instrumentLibrary;
@synthesize selectedInstrument;
- (id) init
{
self = [super init];
if(self)
{
NSMutableArray* inst = [[NSMutableArray alloc] init];
[self setInstrumentLibrary:inst];
[inst release];
}
return self;
}
- (IBAction)addInstrumentToLibrary: (id)sender
{
MIDIInstrument* newInst = [[MIDIInstrument alloc] init];
[[self instrumentLibrary] addObject:newInst];
[self setSelectedInstrument:newInst];
[newInst release];
[midiInstrumentsTable reloadData];
NSIndexSet* idxs = [NSIndexSet
indexSetWithIndexesInRange:NSMakeRange(([[self instrumentLibrary] count] - 1),
1)];
[midiInstrumentsTable selectRowIndexes:idxs byExtendingSelection:NO];
[midiInstrumentsTable editColumn:0 row:([[self instrumentLibrary] count] -
1) withEvent:nil select:YES];
}
- (IBAction)removeInstrumentFromLibrary: (id)sender
{
if([self selectedInstrument] != nil)
{
[[self instrumentLibrary] removeObject:[self
selectedInstrument]];
[midiInstrumentsTable reloadData];
}
}
- (void)tableViewSelectionDidChange:
(NSNotification*)notification
{
int row = [midiInstrumentsTable selectedRow];
if(row >= 0)
[self setSelectedInstrument:[[self instrumentLibrary]
objectAtIndex:row]];
}
- (NSInteger) numberOfRowsInTableView:(NSTableView*)tv
{
if(tv == midiInstrumentsTable)
return [[self instrumentLibrary] count];
return 0;
}
- (id) tableView:(NSTableView *)tv objectValueForTableColumn:(NSTableColumn
*)tc row:(NSInteger)row
{
NSLog(@"Updating instruments table...");
if(tv == midiInstrumentsTable)
{
id inst = [[self instrumentLibrary] objectAtIndex:row];
if(inst == nil)
return nil;
if(tc == midiInstNamesColumn)
{
// give the name for the associated MIDIInstrument
[tc setEditable:YES];
return [inst MIDI_Inst_Name];
}
else if(tc == midiPortsColumn)
{
// list the ports for the associated MIDIInstrument
[tc setEditable:YES];
NSPopUpButtonCell* ports = [tc dataCell];
[ports removeAllItems];
int i;
for(i=0;i < [[inst MIDI_Inst_Ports] count];i++)
[ports addItemWithTitle:[[inst MIDI_Inst_Ports]
objectAtIndex:i]];
return ports;
}
else if(tc == midiChannelsColumn)
{
// list the channels for the associated MIDIInstrument
(just 16 numbers)
[tc setEditable:YES];
NSPopUpButtonCell* channels = [tc dataCell];
[channels removeAllItems];
int i;
for(i=0;i < 16;i++)
[channels addItemWithTitle:[NSString
stringWithFormat:@"%i", i+1]];
return channels;
}
}
return nil;
}
- (void) tableView:(NSTableView *)tv setObjectValue:(id)v
forTableColumn:(NSTableColumn *)tc row:(NSInteger)row
{
NSLog(@"Updating instruments...");
if (tv == midiInstrumentsTable)
{
MIDIInstrument* inst = [[self instrumentLibrary]
objectAtIndex:row];
if(inst == nil)
return;
if (tc == midiInstNamesColumn)
{
// set the given name
[inst setMIDI_Inst_Name:v];
Re: Displaying NSPopUpButtonCells in NSTableView
ah, that makes sense. I'll make the change and see if that fixes it. thanks, Peter. J. On 2010-05-20, at 1:28 PM, Peter Ammon wrote: > > On May 20, 2010, at 1:14 PM, James Maxwell wrote: > >> I thought I'd change the topic on this, since the content really has changed. >> >> I have an table for setting up MIDI instruments with a name, port, and >> channel. I've got the initial display of options for the table row >> displaying correctly, and when I make changes to the name, port, and >> channel, the data object is updated correctly. The only thing left is that >> the popups in columns 2 and 3 are not holding the selected value. I >> understand that this is probably because I'm reloading the menu in >> tableView:objectValueForTableColumn:row, but I'm not sure how to get around >> it. >> >> Here's the code I've got so far. I'm not using an NSArrayController, because >> that approach was driving me absolutely mental... >> I've copied all the code (except imports) to be thorough. Logging "Edited >> MIDIInstrument" at the end shows that the instrument is set up correctly, >> with the desire name, port, and channel. It's just that the popups always >> display the 2nd item. > > Hi James, > > If you have a table view containing an NSPopUpButtonCell, the object value > returned by your objectValueForTableColumn: method should be an NSNumber, > which contains the index of the item that should be selected. It looks like > the attached code is returning the cell itself, which is strange, and I think > that's causing the problem. > > Hope this helps, > -Peter > James B Maxwell Composer/Doctoral Student School for the Contemporary Arts (SCA) School for Interactive Arts + Technology (SIAT) Simon Fraser University jbmaxw...@rubato-music.com jbmax...@sfu.ca ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Displaying NSPopUpButtonCells in NSTableView
hmm... Well, I've tried returning the cell's selectedItem, indexOfSelectedItem, and also: [[inst MIDI_Inst_Ports] objectAtIndex:[ports indexOfSelectedItem]] (that is, the port name at indexOfSelectedItem). If I NSLog the [ports indexOfSelectedItem] it's always zero. So I'm obviously not understanding how (or when) the cell gets selected. Maybe the menu/cell selection is a separate process? Do I need to control the popup separately? I'll look into NSPopUpButtonCell again, but if anyone see's what I'm missing, please pop me a note. thanks, J. On 2010-05-20, at 2:04 PM, James Maxwell wrote: > ah, that makes sense. I'll make the change and see if that fixes it. > > thanks, Peter. > > J. > > > On 2010-05-20, at 1:28 PM, Peter Ammon wrote: > >> >> On May 20, 2010, at 1:14 PM, James Maxwell wrote: >> >>> I thought I'd change the topic on this, since the content really has >>> changed. >>> >>> I have an table for setting up MIDI instruments with a name, port, and >>> channel. I've got the initial display of options for the table row >>> displaying correctly, and when I make changes to the name, port, and >>> channel, the data object is updated correctly. The only thing left is that >>> the popups in columns 2 and 3 are not holding the selected value. I >>> understand that this is probably because I'm reloading the menu in >>> tableView:objectValueForTableColumn:row, but I'm not sure how to get around >>> it. >>> >>> Here's the code I've got so far. I'm not using an NSArrayController, >>> because that approach was driving me absolutely mental... >>> I've copied all the code (except imports) to be thorough. Logging "Edited >>> MIDIInstrument" at the end shows that the instrument is set up correctly, >>> with the desire name, port, and channel. It's just that the popups always >>> display the 2nd item. >> >> Hi James, >> >> If you have a table view containing an NSPopUpButtonCell, the object value >> returned by your objectValueForTableColumn: method should be an NSNumber, >> which contains the index of the item that should be selected. It looks like >> the attached code is returning the cell itself, which is strange, and I >> think that's causing the problem. >> >> Hope this helps, >> -Peter >> > > James B Maxwell > Composer/Doctoral Student > School for the Contemporary Arts (SCA) > School for Interactive Arts + Technology (SIAT) > Simon Fraser University > jbmaxw...@rubato-music.com > jbmax...@sfu.ca > > ___ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > Please do not post admin requests or moderator comments to the list. > Contact the moderators at cocoa-dev-admins(at)lists.apple.com > > Help/Unsubscribe/Update your Subscription: > http://lists.apple.com/mailman/options/cocoa-dev/jbmaxwell%40rubato-music.com > > This email sent to jbmaxw...@rubato-music.com James B Maxwell Composer/Doctoral Student School for the Contemporary Arts (SCA) School for Interactive Arts + Technology (SIAT) Simon Fraser University jbmaxw...@rubato-music.com jbmax...@sfu.ca ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Core data model persistence, independent of document
Looking over the type of model I want to build for my music app, I realized that perhaps Core Data would be a good way to manage it. The reason being that I want an arbitrary number of "Instruments", each of which has a MIDI port, channel, and an arbitrary number of "Articulations." The total set of user-defined Articulations is stored in an "Articulation Library", so that the user can create articulations, and assign them to whatever instruments they desire. Given these relationships, Core Data seemed reasonable... I built a model that seems about right, to me, but I can't seem to bind it to anything without getting the "this class is not key value coding-compliant for the key managedObjectContext" error. I've been looking around at various Core Data tutorials, and I noticed that they're either for document-based apps, or they're created from a template, which I guess must provide the appropriate AppDelegate (at least, that's implied by one of the tutorials, at mactech.com). My app is document-based, but I don't want this data stored with the document -- it should persist across all documents, pretty much like a user default (and besides, I'm subclassing GCDrawKit's "DKDrawingDocument" already). I get the same error when binding to Shared User Defaults, so I'm kinda stumped... thanks, J. James B Maxwell Composer/Doctoral Student School for the Contemporary Arts (SCA) School for Interactive Arts + Technology (SIAT) Simon Fraser University jbmaxw...@rubato-music.com jbmax...@sfu.ca ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Core Data NSPopUpButtonCell and NSNumber
This shouldn't be a difficult problem, but how do I make a NSPopUpButtonCell load a list of numbers, and return the value of the number when selected? Originally I used a ComboBox, with pre-programmed values from IB, but it returned strings, not NSNumbers. This really should be simple, and maybe it is, but I can't find a simple way to do it. I'm using Core Data, and the object I'm trying to set in my model is type Integer 16. J.___ 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 NSPopUpButtonCell and NSNumber
ah, okay. I got it. Just in case anyone has the same problem in future (probably not, I suppose!), here's what I did: 1) instantiate the desired NSArray of NSNumbers in your controller class 2) create a NSArrayController with the Attribute set to NSNumber and a key for intValue (not sure if the key was necessary...) 3) put an NSPopUpButtonCell in your table's column 4) bind the content of your NSArrayController to your controller, with the path set to point to the array created in 1) 5) bind the content of the table column to the NSArrayController 6) bind the Selected Object for the NSArrayController to the desired object (in my case, it was the "channel" key in the NSArrayController for my Core Data model) Not certain that this is right, but it works. Hope it saves someone else the trouble later on. J. On 2010-05-23, at 10:11 AM, James Maxwell wrote: > This shouldn't be a difficult problem, but how do I make a NSPopUpButtonCell > load a list of numbers, and return the value of the number when selected? > Originally I used a ComboBox, with pre-programmed values from IB, but it > returned strings, not NSNumbers. This really should be simple, and maybe it > is, but I can't find a simple way to do it. I'm using Core Data, and the > object I'm trying to set in my model is type Integer 16. > > J.___ > > 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/jbmaxwell%40rubato-music.com > > This email sent to jbmaxw...@rubato-music.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 NSPopUpButtonCell and NSNumber
Thanks Fritz, But I'm doing this directly from the entities. I could generate the classes, and add the changes you've suggested, though. I might do that down the road, but what I did seems to be working. cheers, J. On 2010-05-23, at 10:39 AM, Fritz Anderson wrote: > On 23 May 2010, at 12:11 PM, James Maxwell wrote: > >> This shouldn't be a difficult problem, but how do I make a NSPopUpButtonCell >> load a list of numbers, and return the value of the number when selected? >> Originally I used a ComboBox, with pre-programmed values from IB, but it >> returned strings, not NSNumbers. This really should be simple, and maybe it >> is, but I can't find a simple way to do it. I'm using Core Data, and the >> object I'm trying to set in my model is type Integer 16. > > Shortest answer: [aString integerValue]. > > > Your controller (or something it owns) could have a property that's an > NSArray of objects that in turn have an NSString property for the item title > and an NSNumber property for the item value, and bind the two to the popup > button bindings, and bind your model property to the selected value. > (Considerable hand-waving; sorry.) > > Or, if the menu doesn't vary, use setTag: on each item, using the desired > integer. On selection, theNSNumber = [NSNumber numberWithInt: > cell.selectedITem.tag]. > > Or, if the item titles all begin with the integers you're interested in > (untested, typed in Mail)... > >NSString * title = cell.selectedItem.title; >NSInteger titleAsInt = title.integerValue; >NSNumber * theNSNumber = [NSNumber numberWithInteger: titleAsInt]; > > > — F > ___ 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
font glyphs on different hardware
I'm having a problem where fonts are mapping differently on different hardware. I have a Mac Pro (early 2008) and a Core i5 Macbook Pro. The Mac Pro handles fonts as expected (it's my main development computer) but the Macbook Pro maps differently. My app doesn't give any errors about missing fonts, it's just that the font glyphs seem to have different values. Just to be clear, I'm not using the fonts as text, per se, but am using the glyphs themselves, rendered as bezier paths (appendBezierPathWithGlyph:inFont:). It's a music app, and the two fonts in question are the free/shareware Sonora and Toccata fonts. Any thoughts on how to go about ensuring that mapping is hardware-agnostic would be appreciated. J. James B Maxwell Composer/Doctoral Student School for the Contemporary Arts (SCA) School for Interactive Arts + Technology (SIAT) Simon Fraser University jbmaxw...@rubato-music.com jbmax...@sfu.ca ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: font glyphs on different hardware
I'm sure many here know all this, but just in case anyone's confused about it, in future, I'll post what I've found. Opening the font on each machine, using Font Examiner (handy software... might have to buy a copy!), I can see that the offset of all the glpyhs on my Macbook is less than on the Mac Pro -- Full Stop is 17 on the Macbook and 46 on the Mac Pro. Weird. The names, however, are consistent, so I guess the idea is to use the names to get the IDs (kind of funny, since the names have nothing to do with the actual characters, in my case). I can run this as an init routine, so no big deal. J. On 2010-05-31, at 12:44 PM, James Maxwell wrote: > I'm having a problem where fonts are mapping differently on different > hardware. I have a Mac Pro (early 2008) and a Core i5 Macbook Pro. The Mac > Pro handles fonts as expected (it's my main development computer) but the > Macbook Pro maps differently. My app doesn't give any errors about missing > fonts, it's just that the font glyphs seem to have different values. > > Just to be clear, I'm not using the fonts as text, per se, but am using the > glyphs themselves, rendered as bezier paths > (appendBezierPathWithGlyph:inFont:). It's a music app, and the two fonts in > question are the free/shareware Sonora and Toccata fonts. > > Any thoughts on how to go about ensuring that mapping is hardware-agnostic > would be appreciated. > > J. > > James B Maxwell > Composer/Doctoral Student > School for the Contemporary Arts (SCA) > School for Interactive Arts + Technology (SIAT) > Simon Fraser University > jbmaxw...@rubato-music.com > jbmax...@sfu.ca > > ___ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > Please do not post admin requests or moderator comments to the list. > Contact the moderators at cocoa-dev-admins(at)lists.apple.com > > Help/Unsubscribe/Update your Subscription: > http://lists.apple.com/mailman/options/cocoa-dev/jbmaxwell%40rubato-music.com > > This email sent to jbmaxw...@rubato-music.com James B Maxwell Composer/Doctoral Student School for the Contemporary Arts (SCA) School for Interactive Arts + Technology (SIAT) Simon Fraser University jbmaxw...@rubato-music.com jbmax...@sfu.ca ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: font glyphs on different hardware
Okay, so the simple solution isn't simple. this: NSFont* artFont_2 = [NSFont fontWithName:@"Sonara" size:30.0]; NSLog(@"what's up? %i", [artFont_1 glyphWithName:@"FULL STOP"]); prints the glyph as "0" (which is NOT the glyph ID) So what gives? In fact, all of my glyphs return zero... mmm... yum. I love it when methods don't work... Looking around, I found posts from as long ago as 2001 indicating that glyphWithName is broken. What's going on? Using the Glyph view in the Character Viewer I can see that the name is "FULL STOP", so what can I do? Simple question: since using the Glyph ID (i.e., from the Character viewer) directly at least **works**, is there any real reason why the same font, on different systems, would have different Glyph IDs for the same character? Or was this possibly just some form of font corruption? If looking up the Glyph ID and using it directly is supposed to be safe across machines, I'll just go back to that, as this glyphWithName business is way too annoying... J. On 2010-05-31, at 1:44 PM, James Maxwell wrote: > I'm sure many here know all this, but just in case anyone's confused about > it, in future, I'll post what I've found. > > Opening the font on each machine, using Font Examiner (handy software... > might have to buy a copy!), I can see that the offset of all the glpyhs on my > Macbook is less than on the Mac Pro -- Full Stop is 17 on the Macbook and 46 > on the Mac Pro. Weird. The names, however, are consistent, so I guess the > idea is to use the names to get the IDs (kind of funny, since the names have > nothing to do with the actual characters, in my case). I can run this as an > init routine, so no big deal. > > J. > > > On 2010-05-31, at 12:44 PM, James Maxwell wrote: > >> I'm having a problem where fonts are mapping differently on different >> hardware. I have a Mac Pro (early 2008) and a Core i5 Macbook Pro. The Mac >> Pro handles fonts as expected (it's my main development computer) but the >> Macbook Pro maps differently. My app doesn't give any errors about missing >> fonts, it's just that the font glyphs seem to have different values. >> >> Just to be clear, I'm not using the fonts as text, per se, but am using the >> glyphs themselves, rendered as bezier paths >> (appendBezierPathWithGlyph:inFont:). It's a music app, and the two fonts in >> question are the free/shareware Sonora and Toccata fonts. >> >> Any thoughts on how to go about ensuring that mapping is hardware-agnostic >> would be appreciated. >> >> J. >> >> James B Maxwell >> Composer/Doctoral Student >> School for the Contemporary Arts (SCA) >> School for Interactive Arts + Technology (SIAT) >> Simon Fraser University >> jbmaxw...@rubato-music.com >> jbmax...@sfu.ca >> >> ___ >> >> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) >> >> Please do not post admin requests or moderator comments to the list. >> Contact the moderators at cocoa-dev-admins(at)lists.apple.com >> >> Help/Unsubscribe/Update your Subscription: >> http://lists.apple.com/mailman/options/cocoa-dev/jbmaxwell%40rubato-music.com >> >> This email sent to jbmaxw...@rubato-music.com > > James B Maxwell > Composer/Doctoral Student > School for the Contemporary Arts (SCA) > School for Interactive Arts + Technology (SIAT) > Simon Fraser University > jbmaxw...@rubato-music.com > jbmax...@sfu.ca > > ___ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > Please do not post admin requests or moderator comments to the list. > Contact the moderators at cocoa-dev-admins(at)lists.apple.com > > Help/Unsubscribe/Update your Subscription: > http://lists.apple.com/mailman/options/cocoa-dev/jbmaxwell%40rubato-music.com > > This email sent to jbmaxw...@rubato-music.com James B Maxwell Composer/Doctoral Student School for the Contemporary Arts (SCA) School for Interactive Arts + Technology (SIAT) Simon Fraser University jbmaxw...@rubato-music.com jbmax...@sfu.ca ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: font glyphs on different hardware
Ah, sorry I didn't see these posts until now. Sound like good recommendations. For the time being, I don't mind relying on a specific font, but I'll look over the SpeedometerView example, and see about implementing this at a higher level. Thanks for the tips. J. On 2010-06-01, at 9:10 AM, Douglas Davidson wrote: > Let me second Alastair's recommendations. Our standard developer example for > this sort of thing is in the SpeedometerView example code, in the > SpeedyCategories.m file; take a look at the BezierConversions category on > NSString, and the associated BezierNSLayoutManager. > > Douglas Davidson > > > On Jun 1, 2010, at 2:11 AM, Alastair Houghton wrote: > >> Normally you'd be drawing using higher-level APIs that take Unicode code >> points/units rather than glyph indices; in that case, if you *really* needed >> a glyph ID for some reason, you could get NSLayoutManager or Core Text to >> map your Unicode data to glyphs for you. >> >> Mapping glyphs yourself is a little on the painful side; it *is* possible to >> do it, but you'd have to grab the font's tables and parse them yourself... I >> wouldn't recommend it if you can get something else to do glyph mapping for >> you. Further, if you want to support advanced layout features like OpenType >> or AAT, it will rapidly become an *extremely* unpleasant and complicated >> exercise. >> >>> Simple question: since using the Glyph ID (i.e., from the Character viewer) >>> directly at least **works**, is there any real reason why the same font, on >>> different systems, would have different Glyph IDs for the same character? >>> Or was this possibly just some form of font corruption? >> >> The glyph IDs are generally speaking up to the font; there are a few >> predefined ones - 0 is reserved for the undefined/missing character glyph, >> and index 1 is the null glyph. >> >>> If looking up the Glyph ID and using it directly is supposed to be safe >>> across machines, I'll just go back to that, as this glyphWithName business >>> is way too annoying... >> >> If you can guarantee that you're always using the same version of the font, >> and nobody is going to change the glyph IDs, then you can use them directly >> if you must. However, if the font you're using supports it, you'd be better >> off using the Unicode "Musical Symbols" block at U+1D100, because that frees >> you from relying on knowing specific glyph IDs; it also means you can use >> the higher-level rendering machinery, which gets you all kinds of advantages >> like automatic support for kerning, ligatures, positioning and so on. > James B Maxwell Composer/Doctoral Student School for the Contemporary Arts (SCA) School for Interactive Arts + Technology (SIAT) Simon Fraser University jbmaxw...@rubato-music.com jbmax...@sfu.ca ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
changing NSTextView text colour
I have a NSTextView that's displaying MIDI info from my app's current MIDI input device. I show this info in a couple of places - one is in a "MIDI Setup" type window, and the other is in an Inspector window. I want the Inspector window to show this data in light grey text against a dark background (whereas the MIDI Setup window shows it in black on white). I'm doing this from my MIDI controller class, which is instantiated as a nib in IB. The controller has an IBOutlet to the desired text view. In the controller's init I tried just setting the foreground colour of my text view's textStorage, but that didn't work -- it still displays as black text. It does work to do this: [[mainWindowMIDIMonitor textStorage] setForegroundColor:[NSColor lightGrayColor]]; [mainWindowMIDIMonitor performSelectorOnMainThread:@selector(setString:) withObject:monitorInfo waitUntilDone:NO]; But it doesn't display the first input in light grey. It starts out as black, than changes after the first entry... go figure... Is there no way to just permanently set the text colour to light grey once? Do I have to have the controller hold a reference to the text view, rather than just using an outlet? J. James B Maxwell Composer/Doctoral Student School for the Contemporary Arts (SCA) School for Interactive Arts + Technology (SIAT) Simon Fraser University jbmaxw...@rubato-music.com jbmax...@sfu.ca ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: changing NSTextView text colour
Well, yes, I figured as much... just grasping at straws, really. What I don't get is why using the "Text" colour panel in IB doesn't actually set the text colour for the text view. Strange. Seems wildly counter-intuitive, to me. Anyway, I am able to get the text colour changed, it's just this annoying little thing that the text changes only *after* the first line has been shown -- once the first line of black text has been rendered, everything after that comes up in the desired light grey. I'll fix it at some point, but it's not a huge priority, at the moment. If anyone has any thoughts, let me know. J. On 2010-06-06, at 3:50 PM, Graham Cox wrote: > > On 07/06/2010, at 3:21 AM, James Maxwell wrote: > >> Do I have to have the controller hold a reference to the text view, rather >> than just using an outlet? > > > I don't know the answer to the problem, but just to pick up on this one - an > outlet IS a reference to the object it's connected to, nothing more or less. > > --Graham > > James B Maxwell Composer/Doctoral Student School for the Contemporary Arts (SCA) School for Interactive Arts + Technology (SIAT) Simon Fraser University jbmaxw...@rubato-music.com jbmax...@sfu.ca ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: changing NSTextView text colour
hmm... okay. I get what you're saying about range, and I did wonder about that,
but it seems strange to be required to always set it by range, for each line.
Shouldn't there just be a single, persistent setting -- a default, as it were?
I'll look at the typingAttributes, but this text is being set programmatically,
not by the user. Don't know if that makes a difference... ("Typing" certainly
sounds like user input to me.)
As I say, I would have expected the IB Attributes panel to be able to set it,
but it's not working, for whatever reason.
J.
On 2010-06-06, at 5:29 PM, Ross Carter wrote:
> On Jun 6, 2010, at 1:21 PM, James Maxwell wrote:
>
>> I have a NSTextView that's displaying MIDI info from my app's current MIDI
>> input device. I show this info in a couple of places - one is in a "MIDI
>> Setup" type window, and the other is in an Inspector window. I want the
>> Inspector window to show this data in light grey text against a dark
>> background (whereas the MIDI Setup window shows it in black on white).
>> I'm doing this from my MIDI controller class, which is instantiated as a nib
>> in IB. The controller has an IBOutlet to the desired text view. In the
>> controller's init I tried just setting the foreground colour of my text
>> view's textStorage, but that didn't work -- it still displays as black text.
>> It does work to do this:
>>
>> [[mainWindowMIDIMonitor textStorage] setForegroundColor:[NSColor
>> lightGrayColor]];
>> [mainWindowMIDIMonitor performSelectorOnMainThread:@selector(setString:)
>> withObject:monitorInfo waitUntilDone:NO];
>>
>> But it doesn't display the first input in light grey. It starts out as
>> black, than changes after the first entry... go figure...
>> Is there no way to just permanently set the text colour to light grey once?
>> Do I have to have the controller hold a reference to the text view, rather
>> than just using an outlet?
>
> This might help; forgive me if it doesn't address your situation. In an
> NSTextStorage object, text attributes are values that apply to some range of
> text in the object. If the object has no text, then setting attributes is
> meaningless. If a textStorage length is 0, and you set a foreground color
> attribute, and subsequently add some text, the text does not necessarily show
> up with that foreground color.
>
> When plain text without attributes is added to a textStorage object--as, for
> example, with input from the keyboard--the NSTextView uses its
> typingAttributes dictionary to apply attributes to the new text. So, if
> you've got a new NSTextView whose NSTextStorage length is 0, and you are
> going to add some plain text to it, you must first set the typingAttributes
> of the NSTextView to the desired attributes.
>
> -setForegroundColor: is one of the scriptability methods of NSTextStorage.
> Those methods are not recommended for use in non-scripting situations.
> ___
>
> 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/jbmaxwell%40rubato-music.com
>
> This email sent to jbmaxw...@rubato-music.com
James B Maxwell
Composer/Doctoral Student
School for the Contemporary Arts (SCA)
School for Interactive Arts + Technology (SIAT)
Simon Fraser University
jbmaxw...@rubato-music.com
jbmax...@sfu.ca
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Locking an object's location to the scroll view (not the document)
I'm using GCDrawKit, which has been an amazing help in getting my app's
interface together. However, I've run into a problem that's making me slightly
crazy...
My main view is a zooming scroll view. Thanks to drawKit, I generally have no
problems at all; it handles the zooming beautifully, so I don't even think
about it. However, what I need to do now is to have certain objects remain in a
fixed position, relative to the viewable area -- so if, for example, an object
is in the upper-left corner, it will remain there during scrolling and zooming
(I DO want it to zoom, but it should stay in the upper-left corner). I managed
to get this working (or I thought I did), by telling my enclosingScrollView to
post frame changed notifications, then using those to update the position of
the object.
- (void)updateWithScroll
{
NSPoint selfOrigin = [self location];
DKDrawingView* view = [(DKDrawingDocument*)[[self drawing] owner] mainView];
NSRect bounds = [[[view enclosingScrollView] contentView] bounds];
NSPoint origin = bounds.origin;
if(self.lockXPositionToContentRect)
{
selfOrigin.x = origin.x + scrollOffset.x;
}
if(self.lockYPositionToContentRect)
{
selfOrigin.y = origin.y + scrollOffset.y;
}
[self setLocation:selfOrigin];
}
But unfortunately I forgot about zooming, so my objects only stay in their
correct positions if I'm either: A) at a zoom scale of 1.0, or B) the scroll
view is at the document's origin (i.e., 0,0 for both document and view). How do
I do this for both scrolling and zooming?
(I tried multiplying the location coordinates by the scaling amount, but that
doesn't quite do it -- it's closer, but not correct.)
Any help appreciated.
J.
--
James B. Maxwell
Composer/Researcher/PhD Candidate
jbmaxw...@rubato-music.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: Locking an object's location to the scroll view (not the document)
Holy smokes!
Okay, just used the wrong Rect. Needed to use documentVisibleRect instead of
the contentView's bounds. Ugh... Working fine now.
J.
On 2011-10-12, at 12:24 PM, James Maxwell wrote:
> I'm using GCDrawKit, which has been an amazing help in getting my app's
> interface together. However, I've run into a problem that's making me
> slightly crazy...
>
> My main view is a zooming scroll view. Thanks to drawKit, I generally have no
> problems at all; it handles the zooming beautifully, so I don't even think
> about it. However, what I need to do now is to have certain objects remain in
> a fixed position, relative to the viewable area -- so if, for example, an
> object is in the upper-left corner, it will remain there during scrolling and
> zooming (I DO want it to zoom, but it should stay in the upper-left corner).
> I managed to get this working (or I thought I did), by telling my
> enclosingScrollView to post frame changed notifications, then using those to
> update the position of the object.
>
> - (void)updateWithScroll
> {
>NSPoint selfOrigin = [self location];
>DKDrawingView* view = [(DKDrawingDocument*)[[self drawing] owner]
> mainView];
>NSRect bounds = [[[view enclosingScrollView] contentView] bounds];
>NSPoint origin = bounds.origin;
>if(self.lockXPositionToContentRect)
>{
>selfOrigin.x = origin.x + scrollOffset.x;
>}
>if(self.lockYPositionToContentRect)
>{
>selfOrigin.y = origin.y + scrollOffset.y;
>}
>[self setLocation:selfOrigin];
> }
>
> But unfortunately I forgot about zooming, so my objects only stay in their
> correct positions if I'm either: A) at a zoom scale of 1.0, or B) the scroll
> view is at the document's origin (i.e., 0,0 for both document and view). How
> do I do this for both scrolling and zooming?
> (I tried multiplying the location coordinates by the scaling amount, but that
> doesn't quite do it -- it's closer, but not correct.)
>
> Any help appreciated.
>
> J.
>
> --
> James B. Maxwell
> Composer/Researcher/PhD Candidate
> jbmaxw...@rubato-music.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/jbmaxwell%40rubato-music.com
>
> This email sent to jbmaxw...@rubato-music.com
--
James B. Maxwell
Composer/Researcher/PhD Candidate
jbmaxw...@rubato-music.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
Crash and dispatch queue
I have a method that's crashing with EXC_BAD_ACCESS. I'm running a fairly
lengthy, iterative process in a distpatch_async block and at the end of it
saving a file. Originally, I had included the file save in the block...
dispatch_async(queue,^{
[myObject doSomeHorrificCrunching];
[myObject saveDataToFile];
});
...and was getting a crash in certain situations -- it seemed to be related to
the size of the file (which also indicates the length/complexity of the
iterative process). So, I tried pulling the file save out of the block:
dispatch_async(queue,^{
[myObject doSomeHorrificCrunching];
});
[myObject saveDataToFile];
This also crashed (which is not surprising). So, just to check my theory that
perhaps the data was still being modified when the file save method was run, I
used dispatch_sync:
dispatch_sync(queue,^{
[myObject doSomeHorrificCrunching];
});
[myObject saveDataToFile];
This didn't crash, but of course I had to enjoy the glorious beach ball.
So, finally, I tried using a group (and going back to dispatch_async)...
dispatch_group_async(group, queue,^{
[myObject doSomeHorrificCrunching];
});
dispatch_group_notify(group, queue, ^{
[myObject saveDataToFile];
});
...but to my dismay, the crash came back.
I'm wondering: does this last step actually prove that my crash is _not_ being
caused by trying to save while the data is being modified?
Unfortunately, I haven't been able to get any info on the state of the object
when the crash happens. I have Zombies enabled, but I don't get any zombie
action in the console.
Confused...
J.
--
James B. Maxwell
Composer/Researcher/PhD Candidate
___
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
Saving/Restoring NSScrollView's position
This may have a simple answer, but I can't seem to find it.
I want my document's scroll view to restore the scroll position when opening
from a file. The default behaviour seems to be to set it back to {0, 0} (i.e.,
so that my document's view always returns to the upper-left corner). Is there a
simple way (a flag, maybe) to tell it to restore to the last scroll position?
If not, how do I add this behaviour?
Thanks in advance for any help.
J.
--
James B. Maxwell
Composer/Researcher/PhD Candidate
___
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: Saving/Restoring NSScrollView's position
Thanks for the detailed reply, Conrad.
I may reconsider my plan of restoring the scroll position. It seemed like a
nice function for my app, but maybe not essential.
J.
On 2011-12-03, at 11:26 AM, Conrad Shultz wrote:
> On 12/3/11 10:31 AM, James Maxwell wrote:
>> This may have a simple answer, but I can't seem to find it. I want my
>> document's scroll view to restore the scroll position when opening
>> from a file. The default behaviour seems to be to set it back to {0,
>> 0} (i.e., so that my document's view always returns to the upper-left
>> corner). Is there a simple way (a flag, maybe) to tell it to restore
>> to the last scroll position? If not, how do I add this behaviour?
>
> NSScrollView will automatically encode and restore its scroll position
> as part of Lion window restoration. I don't know of a way to do the
> same for file save/open.
>
> To determine the "scroll position" manually you examine the bounds
> origin of the enclosed clip view; see the Scroll View Programming Guide
> (http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/NSScrollViewGuide/Articles/Scrolling.html)
> for details.
>
> However, be sure to consider various issues before you set about
> implementing this:
>
> 1) For most documents the scroll position is more of a view property
> than a model property, so it would likely be inappropriate to encode
> into the document. Locally caching (by some means) the scroll position
> addresses this, but might lead the users to erroneously expect scroll
> position to be preserved if the document is opened elsewhere. (Notably,
> Lion window restoration stores the view metadata in a separate location
> the local disk.)
>
> 2) If the document is modified via a mechanism that is scroll position
> unaware (e.g. you are saving in a file format for which other editors
> are available), the cached scroll position can become out of sync with
> the underlying model.
>
> 3) Scroll position can be window size dependent. Suppose you are on a
> laptop with your app displayed on a large external display. You save
> the document and cache the scroll position, then close the app. Later,
> without the external display, you reopen the document. OS X will
> automatically downscale the application window frame to fit the smaller
> screen, and resizing masks or auto-layout will kick in to shrink your
> scroll view. This invalidates the cached scroll position, and could
> land the scroller in an inappropriate (or even invalid) location.
>
> There are probably other "gotchas" that one could think of too. So take
> care when making the decision whether to implement this feature, and if
> you choose to do so, consider the edge cases.
>
> --
> Conrad Shultz
>
> Synthetiq Solutions
> www.synthetiqsolutions.com
James B Maxwell
Composer/Doctoral Candidate
School for the Contemporary Arts (SCA)
School for Interactive Arts + Technology (SIAT)
Simon Fraser University
___
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
copy & isEqual nightmares
Okay, so I'm officially confused. I have an object with isEqual set up to help me limit the number of "unique" objects I can put in a Dictionary. Basically, the object has a few properties which account for "equality", and some properties that don't matter. For example, propA and propB are used in isEqual, but propC isn't. The point is that I can create a set with objects where only propA and propB are different, and propC just is irrelevant. Maybe that seems weird, but it's what I need. But what I don't get is how hash plays into all this. I've always read that I have to override hash when I override isEqual, but I don't exactly understand what that means or does. What I've done is to make a hash that is equal when two objects have the same values for propA and propB (ignoring propC). That's how I interpreted the few threads I've read about overriding hash... But what I need to do in my code, right now, is to copy an object, then alter some properties of the copy, but not the original -- a typical reason for wanting a copy. But I'm seeing that the copy has the same hash and appears to be the same object, since changing properties of the copy changes the original. So does the system see the matching hashes as identical objects, not just the collection classes? Do I have to manually implement some sort of deepCopy method? Or, can I just change hash, so that the copy is a different instance, without losing the functionality I need for collections? I don't understand why I'd need to make a deepCopy, since that's what copy is for... Any help greatly appreciated. J. -- James B. Maxwell Composer/Researcher/PhD Candidate ___ 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: copy & isEqual nightmares
Okay, just saw an interesting post on this: http://stackoverflow.com/questions/1459598/how-to-copy-an-object-in-objective-c This is quite different from what I've generally seen, which just does: MyClass* copy = [[self class] allocWithZone:zone]; then uses accessors to assign all the properties, and returns the copy. But does that just give me a shallow copy? Do I really have to implement the version in the post -- that is, do I have to "call copyWithZone on all of [my] fields" to get a true, mutable copy, that doesn't muck with the original? I guess it makes sense, but I'm kind of surprised that the normal copy (i.e., the one I see everywhere) doesn't do that already, since that's what a "copy" seems to be, in the most general sense. (If I "copy" a paper document, I can burn the copy, write all over it, or whatever I want, without touching the original.) J. On 2012-02-12, at 4:25 PM, James Maxwell wrote: > Okay, so I'm officially confused. > > I have an object with isEqual set up to help me limit the number of "unique" > objects I can put in a Dictionary. Basically, the object has a few properties > which account for "equality", and some properties that don't matter. For > example, propA and propB are used in isEqual, but propC isn't. The point is > that I can create a set with objects where only propA and propB are > different, and propC just is irrelevant. Maybe that seems weird, but it's > what I need. > > But what I don't get is how hash plays into all this. I've always read that I > have to override hash when I override isEqual, but I don't exactly understand > what that means or does. What I've done is to make a hash that is equal when > two objects have the same values for propA and propB (ignoring propC). That's > how I interpreted the few threads I've read about overriding hash... > > But what I need to do in my code, right now, is to copy an object, then alter > some properties of the copy, but not the original -- a typical reason for > wanting a copy. But I'm seeing that the copy has the same hash and appears to > be the same object, since changing properties of the copy changes the > original. So does the system see the matching hashes as identical objects, > not just the collection classes? Do I have to manually implement some sort of > deepCopy method? Or, can I just change hash, so that the copy is a different > instance, without losing the functionality I need for collections? I don't > understand why I'd need to make a deepCopy, since that's what copy is for... > > Any help greatly appreciated. > > J. > > > -- > James B. Maxwell > Composer/Researcher/PhD Candidate > > > > > > > ___ > > 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/jbmaxwell%40rubato-music.com > > This email sent to jbmaxw...@rubato-music.com -- James B. Maxwell Composer/Researcher/PhD Candidate ___ 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: copy & isEqual nightmares
Yes, thanks Ken. I've sorted out the copying issue I **thought** I was having. Turned out not to be a copying issue (and my isEqual and hash were fine, which I kind of suspected)... my data was getting pooched somewhere else. I was just confused because I had naively placed an NSLog(@"%@", [obj hash]) in my code to test whether the object was a copy Doh!!! I knew, from my own implementation that the object could be a copy but still have the same hash! But it does beg the question: is there an easy way to test the **identity** of an object? That is, to NSLog the identity of an object, to see if (and how) it's different to a copy that returns YES to isEqual and has the same hash? I guess I could put something in -description: that would tell me (i.e., include info on the data that I'm NOT comparing in my isEqual method)... Anyway, I was just curious about that. J. On 2012-02-12, at 5:37 PM, Ken Thomases wrote: > Both of the code snippets on that StackOverflow thread have bugs if you're > manually managing memory (as opposed to using GC or ARC). Since they use the > dot syntax to set the property of the copy, they are invoking the setter. In > all probability, the setter does memory management. It takes ownership of > the object returned by the [obj copyWithZone: zone] expression, but that > expression already returned ownership, and nobody balanced or will balance > that. > > There shouldn't be much mystery about how to implement object copying since > Apple documents it pretty clearly... Er, holy crap! I went to find the > article titled "Implementing Object Copy" and Apple seems to have deleted it > from the reference library. That's a big problem. I've filed documentation > feedback and everybody else interested should, too. > > I still have it in Xcode 3.2.x in the Mac OS X 10.6 Core Library. You should > be able to add that docset to Xcode 4.x, too. If it's not offered directly, > you should be able to add it using its URL > <http://developer.apple.com/rss/com.apple.adc.documentation.AppleSnowLeopard.atom>. > In there, it's in the Memory Management Programming Guide. > > If somebody knows an easier place to find it, please post. > > Anyway, with respect to your original post, neither -isEqual: nor -hash has > any influence on copying, unless you deliberately inject such concerns into > your own implementation of copying. On the other hand, it would be quite > common for a copy to compare equal to the original and thus have the same > hash, but you seem clear on that. > > Regards, > Ken > > On Feb 12, 2012, at 6:44 PM, James Maxwell wrote: > >> Okay, just saw an interesting post on this: >> >> http://stackoverflow.com/questions/1459598/how-to-copy-an-object-in-objective-c >> >> This is quite different from what I've generally seen, which just does: >> >> MyClass* copy = [[self class] allocWithZone:zone]; >> >> then uses accessors to assign all the properties, and returns the copy. >> >> But does that just give me a shallow copy? Do I really have to implement >> the version in the post -- that is, do I have to "call copyWithZone on all >> of [my] fields" to get a true, mutable copy, that doesn't muck with the >> original? I guess it makes sense, but I'm kind of surprised that the normal >> copy (i.e., the one I see everywhere) doesn't do that already, since that's >> what a "copy" seems to be, in the most general sense. (If I "copy" a paper >> document, I can burn the copy, write all over it, or whatever I want, >> without touching the original.) >> >> J. >> >> >> On 2012-02-12, at 4:25 PM, James Maxwell wrote: >> >>> Okay, so I'm officially confused. >>> >>> I have an object with isEqual set up to help me limit the number of >>> "unique" objects I can put in a Dictionary. Basically, the object has a few >>> properties which account for "equality", and some properties that don't >>> matter. For example, propA and propB are used in isEqual, but propC isn't. >>> The point is that I can create a set with objects where only propA and >>> propB are different, and propC just is irrelevant. Maybe that seems weird, >>> but it's what I need. >>> >>> But what I don't get is how hash plays into all this. I've always read that >>> I have to override hash when I override isEqual, but I don't exactly >>> understand what that means or does. What I've done is to make a hash that >>>
Re: copy & isEqual nightmares
okay, that's getting to the root of the problem. Never knew about %p... yikes! Good to know. Thanks! J. On 2012-02-12, at 6:22 PM, Graham Cox wrote: > > On 13/02/2012, at 12:54 PM, James Maxwell wrote: > >> But it does beg the question: is there an easy way to test the **identity** >> of an object? That is, to NSLog the identity of an object, to see if (and >> how) it's different to a copy that returns YES to isEqual and has the same >> hash? > > > Look at its address? > > --Graham > > -- James B. Maxwell Composer/Researcher/PhD Candidate ___ 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: copy & isEqual nightmares
oops, yes. typo (0x%X) J. On 2012-02-13, at 1:21 AM, Uli Kusterer wrote: > On 13.02.2012, at 02:54, James Maxwell wrote: >> NSLog(@"%@", [obj hash]) > > I hope this is a typo. %@ expects an object, while -hash returns an integer. > If you're lucky, this will crash, or just output garbage. Your compiler > should be warning you about that line. > > Cheers, > -- Uli Kusterer > "The Witnesses of TeachText are everywhere..." > > > -- James B. Maxwell Composer/Researcher/PhD Candidate ___ 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
crash in initWithCoder
I'm getting a crash in initWithCoder, which seems related to decoding a property called "value", which is of type id. Sometimes this object is an NSString, sometimes it's an NSNumber, and sometimes it's an NSArray. The crash only occurs in cases where "value" is an NSArray. The last few lines in my backtrace are: #0 0x963c4206 in szone_malloc_should_clear () #1 0x963c41a8 in malloc_zone_malloc () #2 0x94920a13 in _CFRuntimeCreateInstance () #3 0x94943482 in CFNumberCreate () #4 0x949586f2 in __CFBinaryPlistCreateObject2 () #5 0x94985fe0 in __CFBinaryPlistCreateObject () #6 0x9823eb11 in _decodeObjectBinary () #7 0x98240314 in -[NSKeyedUnarchiver _decodeArrayOfObjectsForKey:] () #8 0x98240981 in -[NSArray(NSArray) initWithCoder:] () #9 0x9823f508 in _decodeObjectBinary () #10 0x9823e800 in _decodeObject () #11 0x000cdf05 in -[CbCM_Node initWithCoder:] (self=0x4098770, _cmd=0x9433805c, aDecoder=0x410f1c0) at /Volumes/Wheet-Docs/jamesmaxwell/Documents/xcode/rubato/ManuScore+MusiCOG/ManuScore Test Build/ManuScore/CbCM_Node.m:573 From this, I'm guessing that the problem is happening with one of the members of the "value" array. Does that seem right? (I should mention, though, that the trace isn't always the same...) I am retaining "value" when I decode it, so it's not a simple memory bug. I have also run the code with Zombies (NSZombieEnabled=YES), which doesn't indicate any Zombied objects. Finally, the analyzer sees no memory errors (there are a number of "dead stores" - mostly unused variables - but these aren't likely to be real problems, are they?), so I'm stumped. I'm running Xcode 4, btw. Any thoughts appreciated. J. James B Maxwell Composer/Doctoral Student School for the Contemporary Arts (SCA) School for Interactive Arts + Technology (SIAT) Simon Fraser University jbmaxw...@rubato-music.com jbmax...@sfu.ca ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: crash in initWithCoder
Thanks Greg. The initWithCoder is indeed at launch, so Guard Malloc shouldn't be a huge problem. I'll give it a try. cheers, J. On 2011-03-15, at 6:45 PM, Greg Parker wrote: > On Mar 15, 2011, at 4:10 PM, James Maxwell wrote: >> I'm getting a crash in initWithCoder, which seems related to decoding a >> property called "value", which is of type id. Sometimes this object is an >> NSString, sometimes it's an NSNumber, and sometimes it's an NSArray. The >> crash only occurs in cases where "value" is an NSArray. The last few lines >> in my backtrace are: >> >> #0 0x963c4206 in szone_malloc_should_clear () >> #1 0x963c41a8 in malloc_zone_malloc () >> #2 0x94920a13 in _CFRuntimeCreateInstance () >> #3 0x94943482 in CFNumberCreate () >> #4 0x949586f2 in __CFBinaryPlistCreateObject2 () >> #5 0x94985fe0 in __CFBinaryPlistCreateObject () >> #6 0x9823eb11 in _decodeObjectBinary () >> #7 0x98240314 in -[NSKeyedUnarchiver _decodeArrayOfObjectsForKey:] () >> #8 0x98240981 in -[NSArray(NSArray) initWithCoder:] () >> #9 0x9823f508 in _decodeObjectBinary () >> #10 0x9823e800 in _decodeObject () >> #11 0x000cdf05 in -[CbCM_Node initWithCoder:] (self=0x4098770, >> _cmd=0x9433805c, aDecoder=0x410f1c0) at >> /Volumes/Wheet-Docs/jamesmaxwell/Documents/xcode/rubato/ManuScore+MusiCOG/ManuScore >> Test Build/ManuScore/CbCM_Node.m:573 >> >> From this, I'm guessing that the problem is happening with one of the >> members of the "value" array. Does that seem right? (I should mention, >> though, that the trace isn't always the same...) >> I am retaining "value" when I decode it, so it's not a simple memory bug. I >> have also run the code with Zombies (NSZombieEnabled=YES), which doesn't >> indicate any Zombied objects. Finally, the analyzer sees no memory errors >> (there are a number of "dead stores" - mostly unused variables - but these >> aren't likely to be real problems, are they?), so I'm stumped. I'm running >> Xcode 4, btw. > > A crash inside malloc generally means that there's a memory error elsewhere > that corrupted malloc's data structures. (Actual bugs in malloc are rare.) > malloc may store information before or after each allocation, and inside > freed allocations. > > The usual bugs are: > * writing data before or after the bounds of an allocation. Usually this > comes from bounds errors in C arrays. > * writing data into an allocation after freeing it. > > NSZombie catches the latter for Objective-C objects. But if the problem is a > non-object allocation, or a bounds error, then NSZombie won't help. > > The next tool to try is Guard Malloc. It catches both of the above errors for > any malloc allocation. On the down side, it is slow and memory intensive, but > if this -initWithCoder: is running early in app launch then you won't have > any trouble with it. > > http://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man3/guardmalloc.3.html > > > -- > Greg Parker gpar...@apple.com Runtime Wrangler > > James B Maxwell Composer/Doctoral Student School for the Contemporary Arts (SCA) School for Interactive Arts + Technology (SIAT) Simon Fraser University jbmaxw...@rubato-music.com jbmax...@sfu.ca ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: crash in initWithCoder
oops... How do I enable Guard Malloc in Xcode 4? J. On 2011-03-15, at 6:45 PM, Greg Parker wrote: > On Mar 15, 2011, at 4:10 PM, James Maxwell wrote: >> I'm getting a crash in initWithCoder, which seems related to decoding a >> property called "value", which is of type id. Sometimes this object is an >> NSString, sometimes it's an NSNumber, and sometimes it's an NSArray. The >> crash only occurs in cases where "value" is an NSArray. The last few lines >> in my backtrace are: >> >> #0 0x963c4206 in szone_malloc_should_clear () >> #1 0x963c41a8 in malloc_zone_malloc () >> #2 0x94920a13 in _CFRuntimeCreateInstance () >> #3 0x94943482 in CFNumberCreate () >> #4 0x949586f2 in __CFBinaryPlistCreateObject2 () >> #5 0x94985fe0 in __CFBinaryPlistCreateObject () >> #6 0x9823eb11 in _decodeObjectBinary () >> #7 0x98240314 in -[NSKeyedUnarchiver _decodeArrayOfObjectsForKey:] () >> #8 0x98240981 in -[NSArray(NSArray) initWithCoder:] () >> #9 0x9823f508 in _decodeObjectBinary () >> #10 0x9823e800 in _decodeObject () >> #11 0x000cdf05 in -[CbCM_Node initWithCoder:] (self=0x4098770, >> _cmd=0x9433805c, aDecoder=0x410f1c0) at >> /Volumes/Wheet-Docs/jamesmaxwell/Documents/xcode/rubato/ManuScore+MusiCOG/ManuScore >> Test Build/ManuScore/CbCM_Node.m:573 >> >> From this, I'm guessing that the problem is happening with one of the >> members of the "value" array. Does that seem right? (I should mention, >> though, that the trace isn't always the same...) >> I am retaining "value" when I decode it, so it's not a simple memory bug. I >> have also run the code with Zombies (NSZombieEnabled=YES), which doesn't >> indicate any Zombied objects. Finally, the analyzer sees no memory errors >> (there are a number of "dead stores" - mostly unused variables - but these >> aren't likely to be real problems, are they?), so I'm stumped. I'm running >> Xcode 4, btw. > > A crash inside malloc generally means that there's a memory error elsewhere > that corrupted malloc's data structures. (Actual bugs in malloc are rare.) > malloc may store information before or after each allocation, and inside > freed allocations. > > The usual bugs are: > * writing data before or after the bounds of an allocation. Usually this > comes from bounds errors in C arrays. > * writing data into an allocation after freeing it. > > NSZombie catches the latter for Objective-C objects. But if the problem is a > non-object allocation, or a bounds error, then NSZombie won't help. > > The next tool to try is Guard Malloc. It catches both of the above errors for > any malloc allocation. On the down side, it is slow and memory intensive, but > if this -initWithCoder: is running early in app launch then you won't have > any trouble with it. > > http://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man3/guardmalloc.3.html > > > -- > Greg Parker gpar...@apple.com Runtime Wrangler > > James B Maxwell Composer/Doctoral Student School for the Contemporary Arts (SCA) School for Interactive Arts + Technology (SIAT) Simon Fraser University jbmaxw...@rubato-music.com jbmax...@sfu.ca ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: crash in initWithCoder
Okay, strange discovery. I wasn't sure how to enable Guard Malloc in Xcode 4, so I just ran it with the Allocations Instrument. Lo and behold, it doesn't crash. This didn't make much sense to me, so I tried running the release build, rather than the debug build. No crash. Switch back to debug boom. Any thoughts on what this might mean? J. On 2011-03-16, at 10:00 AM, James Maxwell wrote: > oops... How do I enable Guard Malloc in Xcode 4? > > J. > > > On 2011-03-15, at 6:45 PM, Greg Parker wrote: > >> On Mar 15, 2011, at 4:10 PM, James Maxwell wrote: >>> I'm getting a crash in initWithCoder, which seems related to decoding a >>> property called "value", which is of type id. Sometimes this object is an >>> NSString, sometimes it's an NSNumber, and sometimes it's an NSArray. The >>> crash only occurs in cases where "value" is an NSArray. The last few lines >>> in my backtrace are: >>> >>> #0 0x963c4206 in szone_malloc_should_clear () >>> #1 0x963c41a8 in malloc_zone_malloc () >>> #2 0x94920a13 in _CFRuntimeCreateInstance () >>> #3 0x94943482 in CFNumberCreate () >>> #4 0x949586f2 in __CFBinaryPlistCreateObject2 () >>> #5 0x94985fe0 in __CFBinaryPlistCreateObject () >>> #6 0x9823eb11 in _decodeObjectBinary () >>> #7 0x98240314 in -[NSKeyedUnarchiver _decodeArrayOfObjectsForKey:] () >>> #8 0x98240981 in -[NSArray(NSArray) initWithCoder:] () >>> #9 0x9823f508 in _decodeObjectBinary () >>> #10 0x9823e800 in _decodeObject () >>> #11 0x000cdf05 in -[CbCM_Node initWithCoder:] (self=0x4098770, >>> _cmd=0x9433805c, aDecoder=0x410f1c0) at >>> /Volumes/Wheet-Docs/jamesmaxwell/Documents/xcode/rubato/ManuScore+MusiCOG/ManuScore >>> Test Build/ManuScore/CbCM_Node.m:573 >>> >>> From this, I'm guessing that the problem is happening with one of the >>> members of the "value" array. Does that seem right? (I should mention, >>> though, that the trace isn't always the same...) >>> I am retaining "value" when I decode it, so it's not a simple memory bug. I >>> have also run the code with Zombies (NSZombieEnabled=YES), which doesn't >>> indicate any Zombied objects. Finally, the analyzer sees no memory errors >>> (there are a number of "dead stores" - mostly unused variables - but these >>> aren't likely to be real problems, are they?), so I'm stumped. I'm running >>> Xcode 4, btw. >> >> A crash inside malloc generally means that there's a memory error elsewhere >> that corrupted malloc's data structures. (Actual bugs in malloc are rare.) >> malloc may store information before or after each allocation, and inside >> freed allocations. >> >> The usual bugs are: >> * writing data before or after the bounds of an allocation. Usually this >> comes from bounds errors in C arrays. >> * writing data into an allocation after freeing it. >> >> NSZombie catches the latter for Objective-C objects. But if the problem is a >> non-object allocation, or a bounds error, then NSZombie won't help. >> >> The next tool to try is Guard Malloc. It catches both of the above errors >> for any malloc allocation. On the down side, it is slow and memory >> intensive, but if this -initWithCoder: is running early in app launch then >> you won't have any trouble with it. >> >> http://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man3/guardmalloc.3.html >> >> >> -- >> Greg Parker gpar...@apple.com Runtime Wrangler >> >> > > James B Maxwell > Composer/Doctoral Student > School for the Contemporary Arts (SCA) > School for Interactive Arts + Technology (SIAT) > Simon Fraser University > jbmaxw...@rubato-music.com > jbmax...@sfu.ca > > ___ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > Please do not post admin requests or moderator comments to the list. > Contact the moderators at cocoa-dev-admins(at)lists.apple.com > > Help/Unsubscribe/Update your Subscription: > http://lists.apple.com/mailman/options/cocoa-dev/jbmaxwell%40rubato-music.com > > This email sent to jbmaxw...@rubato-music.com James B Maxwell Composer/Doctoral Student School for the Contemporary Arts (SCA) School for Interactive Arts + Technology (SIAT) Simon Fraser University jbmaxw...@rubato-music.com jbmax...@sfu.ca ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: crash in initWithCoder
Ah, got it. Thanks! Unfortunately, Guard Malloc doesn't appear to reveal anything special. Here's the top several lines of my log: GuardMalloc: Allocations will be placed on 16 byte boundaries. GuardMalloc: - Some buffer overruns may not be noticed. GuardMalloc: - Applications using vector instructions (e.g., SSE or Altivec) should work. GuardMalloc: GuardMalloc version 23 2011-03-16 11:03:49.011 ManuScore[80074:903] Starting unarchive of CbCM hierarchy file... warning: Unable to restore previously selected frame. (gdb) bt bt #0 0x001648be in GMmalloc_zone_malloc_internal () #1 0x94920a13 in _CFRuntimeCreateInstance () #2 0x94943482 in CFNumberCreate () #3 0x949586f2 in __CFBinaryPlistCreateObject2 () #4 0x94985fe0 in __CFBinaryPlistCreateObject () #5 0x9823eb11 in _decodeObjectBinary () #6 0x98240314 in -[NSKeyedUnarchiver _decodeArrayOfObjectsForKey:] () #7 0x98240981 in -[NSArray(NSArray) initWithCoder:] () #8 0x9823f508 in _decodeObjectBinary () #9 0x9823e800 in _decodeObject () #10 0x000ced15 in -[CbCM_Node initWithCoder:] (self=0xc1f0ffa0, _cmd=0x9433805c, aDecoder=0x1d279fb0) at /Volumes/Wheet-Docs/jamesmaxwell/Documents/xcode/rubato/ManuScore+MusiCOG/ManuScore Test Build/ManuScore/CbCM_Node.m:552 J. On 2011-03-16, at 10:43 AM, Alex Kac wrote: > Edit your Scheme and go to the "Run" section. Then go to the Diagnostics tab. > > On Mar 16, 2011, at 12:35 PM, Sean McBride wrote: > >> On Wed, 16 Mar 2011 10:31:26 -0700, James Maxwell said: >> >>> Okay, strange discovery. >>> >>> I wasn't sure how to enable Guard Malloc in Xcode 4 >> >> Someone on the Xcode list could probably help there... >> >>> , so I just ran it >>> with the Allocations Instrument. Lo and behold, it doesn't crash. This >>> didn't make much sense to me, so I tried running the release build, >>> rather than the debug build. No crash. Switch back to debug boom. >>> >>> Any thoughts on what this might mean? >> >> Have you looked at the Debugging Magic technote? It's well worth >> reading in its entirety. >> >> <http://developer.apple.com/library/mac/#technotes/tn2004/tn2124.html> >> >> All the bits about memory management should help you debug this. >> >> -- >> >> Sean McBride, B. Eng s...@rogue-research.com >> Rogue Researchwww.rogue-research.com >> Mac Software Developer Montréal, Québec, Canada >> >> >> ___ >> >> 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/alex%40webis.net >> >> This email sent to a...@webis.net > > Alex Kac - President and Founder > Web Information Solutions, Inc. > > "It is useless for sheep to pass a resolution in favor of vegetarianism while > wolves remain of a different opinion." > -- William Randolph Inge > > > > > > ___ > > 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/jbmaxwell%40rubato-music.com > > This email sent to jbmaxw...@rubato-music.com James B Maxwell Composer/Doctoral Student School for the Contemporary Arts (SCA) School for Interactive Arts + Technology (SIAT) Simon Fraser University jbmaxw...@rubato-music.com jbmax...@sfu.ca ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
problem encoding large float* matrix
I'm trying to save the state of my app. It chews up a lot of memory, most of which is in large float* matrices. I'm getting an EXC_BAD_ACCESS error in -encodeBytes:length:forKey: and I'm just wondering what might be happening. The float* "coincidences" is a malloced array. NSUInteger coincsSize = maxCoincs * inputSize * sizeof(float); NSData* coincData = [NSData dataWithBytesNoCopy:&coincidences length:coincsSize]; [aCoder encodeBytes:[coincData bytes] length:coincsSize forKey:@"coincidences"]; The app runs fine, but when I try to save, boom... EXC_BAD_ACCESS. Is this a decent way to save a float* array? J.___ 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: problem encoding large float* matrix
Wow! I'd forgotten how helpful this list is - and how quickly! Everyone pointing out my use of &coincidences is obviously right. I figured it out soon after getting my first reply. I already made an @property accessor for coincidences, so I just used that and the crashes went away. As far as the NSData goes, I'm glad you pointed the redundancy of it out. I'll just encode the bytes themselves. Just a note to Sherm that coincidences is malloced as (maxCoincs * inputSize * sizeof(float)), because it's a 2D float array with dimensions maxCoincs x inputSize. The software is just a research project, for now, so no worries about portability (I'll cross that bridge if I ever get there!). Now onto the crash that's happening when I try to actually *use* the app after loading from a saved file! ugh... ;-) thanks all, J. On 2009-12-01, at 11:40 AM, Sherm Pendley wrote: > On Tue, Dec 1, 2009 at 1:47 PM, James Maxwell > wrote: >> I'm trying to save the state of my app. It chews up a lot of memory, most of >> which is in large float* matrices. I'm getting an EXC_BAD_ACCESS error in >> -encodeBytes:length:forKey: and I'm just wondering what might be happening. >> The float* "coincidences" is a malloced array. >> >> NSUInteger coincsSize = maxCoincs * inputSize * sizeof(float); > > This looks suspicious to me. Based on the variable names, it looks > like you malloc(maxCoincs * sizeof(float)), then store the actual > number of floats in the buffer in inputSize. If that's what you're > doing, you only need to multiply by maxCoincs (to get the size of the > whole buffer) or by inputSize (to find out how much of the buffer is > actually in use) - not by both of them. > >> NSData* coincData = [NSData dataWithBytesNoCopy:&coincidences >> length:coincsSize]; >> [aCoder encodeBytes:[coincData bytes] length:coincsSize >> forKey:@"coincidences"]; > > As someone else said, if you created the buffer with "coincidences = > malloc(...)", then you don't need to dereference it here; doing so > will give you the address of the pointer variable, not the address of > the buffer to which it points. > > What's the point of creating the NSData object here? Wouldn't this be > just as good? > >[aCoder encodeBytes:coincidences length:coincsSize forKey:@"coincidences"]; > > sherm-- > > -- > Cocoa programming in Perl: > http://www.camelbones.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: problem encoding large float* matrix
> > As far as the NSData goes, I'm glad you pointed the redundancy of it out. > I'll just encode the bytes themselves. > erm... actually, just using: [aCoder encodeBytes:coincidences length:coincsSize forKey:@"coincidences"]; fails with a complaint about getting a float* when it expects a uint8_t const. In fact, I know remember that's why I used the NSData in the first place... any thoughts? This is on 10.6.2, if that means anything. J. > Just a note to Sherm that coincidences is malloced as (maxCoincs * inputSize > * sizeof(float)), because it's a 2D float array with dimensions maxCoincs x > inputSize. > > The software is just a research project, for now, so no worries about > portability (I'll cross that bridge if I ever get there!). > > Now onto the crash that's happening when I try to actually *use* the app > after loading from a saved file! ugh... ;-) > > thanks all, > > J. > > > On 2009-12-01, at 11:40 AM, Sherm Pendley wrote: > >> On Tue, Dec 1, 2009 at 1:47 PM, James Maxwell >> wrote: >>> I'm trying to save the state of my app. It chews up a lot of memory, most >>> of which is in large float* matrices. I'm getting an EXC_BAD_ACCESS error >>> in -encodeBytes:length:forKey: and I'm just wondering what might be >>> happening. The float* "coincidences" is a malloced array. >>> >>> NSUInteger coincsSize = maxCoincs * inputSize * sizeof(float); >> >> This looks suspicious to me. Based on the variable names, it looks >> like you malloc(maxCoincs * sizeof(float)), then store the actual >> number of floats in the buffer in inputSize. If that's what you're >> doing, you only need to multiply by maxCoincs (to get the size of the >> whole buffer) or by inputSize (to find out how much of the buffer is >> actually in use) - not by both of them. >> >>> NSData* coincData = [NSData dataWithBytesNoCopy:&coincidences >>> length:coincsSize]; >>> [aCoder encodeBytes:[coincData bytes] length:coincsSize >>> forKey:@"coincidences"]; >> >> As someone else said, if you created the buffer with "coincidences = >> malloc(...)", then you don't need to dereference it here; doing so >> will give you the address of the pointer variable, not the address of >> the buffer to which it points. >> >> What's the point of creating the NSData object here? Wouldn't this be >> just as good? >> >> [aCoder encodeBytes:coincidences length:coincsSize forKey:@"coincidences"]; >> >> sherm-- >> >> -- >> Cocoa programming in Perl: >> http://www.camelbones.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/jbmaxwell%40rubato-music.com > > This email sent to jbmaxw...@rubato-music.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: problem encoding large float* matrix
Okay, I got everything working using the NSData objects. I'll try encoding the bytes again with the unint8_t* cast. I don't know why I didn't try that... I'm really not very comfortable when it gets down to this low-level stuff. I'm a musician, and my programming experience came from MaxMSP, to Java, to Objective-C, and now to this basic C stuff. In other words, totally backwards! ;-) But I can make stuff work most of the time (really, I swear!). thanks again. J. On 2009-12-01, at 12:25 PM, Greg Guerin wrote: > James Maxwell wrote: > >> erm... actually, just using: >> >> [aCoder encodeBytes:coincidences length:coincsSize forKey:@"coincidences"]; >> >> fails with a complaint about getting a float* when it expects a uint8_t >> const. >> In fact, I know remember that's why I used the NSData in the first place... >> any thoughts? > > > Type-casting is a basic language feature. (const uint8_t *)coincidences > > It's NOT expecting a uint8_t const. It's expecting a pointer to const > uint8_t. > > -- 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/jbmaxwell%40rubato-music.com > > This email sent to jbmaxw...@rubato-music.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
NSCoder with network
Hello All, I've got a potentially tricky problem here. My app is backed by a network-like data structure based on three objects: a Network_Controller, a Network, and a set of Nodes. The network is arranged in a hierarchy of levels, with each level having at least one node. The Network object stores this as a 2D NSArray; each level is an NSArray, which holds an NSArray of Nodes for the given level. The Nodes, obviously, also have parent/child relationships. Now, the problem has been in reading files saved using NSCoder. I'm reading/writing these files in a fairly typical manner, at this stage, by having the Network_Controller initiate the save, which tells the Network to encode its 2D array of Nodes, each of which encodes its necessary data, in turn (as per the typical way of using encodeWithCoder/initWithCoder). A single Node's data, however, includes references to parent/child Nodes. So the question is, how to best decode this from the file? Ideally, I suppose, it should start at the top level, decode the single top-level Node first, then work its way down. I'm not doing that, at this point, as I'm just letting the Network decode its 2D array of Nodes, and crossing my fingers. It loads, but the behaviour of the whole thing after loading is not what it should be - it's a complex system, so it's hard to identify exactly why, but it isn't doing what it should be doing. Any thoughts on how to manage this sort of decoding? And should I also approach the encoding in a particular way? Thanks in advance. J.___ 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: NSCoder with network
Brilliant. Thanks! J. On 2009-12-13, at 11:50 AM, A.M. wrote: > > On Dec 13, 2009, at 12:29 PM, James Maxwell wrote: > >> Hello All, >> >> I've got a potentially tricky problem here. My app is backed by a >> network-like data structure based on three objects: a Network_Controller, a >> Network, and a set of Nodes. The network is arranged in a hierarchy of >> levels, with each level having at least one node. The Network object stores >> this as a 2D NSArray; each level is an NSArray, which holds an NSArray of >> Nodes for the given level. The Nodes, obviously, also have parent/child >> relationships. >> Now, the problem has been in reading files saved using NSCoder. I'm >> reading/writing these files in a fairly typical manner, at this stage, by >> having the Network_Controller initiate the save, which tells the Network to >> encode its 2D array of Nodes, each of which encodes its necessary data, in >> turn (as per the typical way of using encodeWithCoder/initWithCoder). A >> single Node's data, however, includes references to parent/child Nodes. So >> the question is, how to best decode this from the file? Ideally, I suppose, >> it should start at the top level, decode the single top-level Node first, >> then work its way down. I'm not doing that, at this point, as I'm just >> letting the Network decode its 2D array of Nodes, and crossing my fingers. >> It loads, but the behaviour of the whole thing after loading is not what it >> should be - it's a complex system, so it's hard to identify exactly why, but >> it isn't doing what it should be doing. >> Any thoughts on how to manage this sort of decoding? And should I also >> approach the encoding in a particular way? > > NSCoder already handles pointer loops in data structures and repoints decoded > object pointers. Just encode both parent and child objects as you would any > other objects. > > Cheers, > M ___ 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: NSCoder with network
Thanks Graham. Good info to have. cheers, J. On 2009-12-13, at 3:02 PM, Graham Cox wrote: > > On 14/12/2009, at 4:29 AM, James Maxwell wrote: > >> I've got a potentially tricky problem here. My app is backed by a >> network-like data structure based on three objects: a Network_Controller, a >> Network, and a set of Nodes. The network is arranged in a hierarchy of >> levels, with each level having at least one node. The Network object stores >> this as a 2D NSArray; each level is an NSArray, which holds an NSArray of >> Nodes for the given level. The Nodes, obviously, also have parent/child >> relationships. >> Now, the problem has been in reading files saved using NSCoder. I'm >> reading/writing these files in a fairly typical manner, at this stage, by >> having the Network_Controller initiate the save, which tells the Network to >> encode its 2D array of Nodes, each of which encodes its necessary data, in >> turn (as per the typical way of using encodeWithCoder/initWithCoder). A >> single Node's data, however, includes references to parent/child Nodes. So >> the question is, how to best decode this from the file? Ideally, I suppose, >> it should start at the top level, decode the single top-level Node first, >> then work its way down. I'm not doing that, at this point, as I'm just >> letting the Network decode its 2D array of Nodes, and crossing my fingers. >> It loads, but the behaviour of the whole thing after loading is not what it >> should be - it's a complex system, so it's hard to identify exactly why, but >> it isn't doing what it should be doing. >> Any thoughts on how to manage this sort of decoding? And should I also >> approach the encoding in a particular way? > > > Hi James, > > You don't necessarily have to do anything special. Just encode & decode the > parent as normal. Naturally you don't want to retain the parent - that would > be a retain cycle. > > But you might also want to consider what would happen if you wanted to > archive a node independently of the rest of the network (perhaps for > cut/paste or something else). In that case you wouldn't want to drag in the > entire network when archiving, as it would if you just encoded the parent > unconditionally. In that case you would want to use > -encodeConditionalObject:forKey: which encodes the parent only if it has > already been encoded. > > That then leaves the final problem of dearchiving an independently archived > node and inserting it back into a network. That's usually just a case of > having the parent pass itself to a setParent: method of the node when you add > the node. But if there's also a chance of setting a whole bunch of nodes at > once, then the -makeObjectsPerformSelector: withObject: method is an easy way > to call -setParent: on all the inserted nodes at once. > > So a complete tree archiving/dearchiving solution typically combines all of > these. > > > --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/archive%40mail-archive.com This email sent to arch...@mail-archive.com
valueForUndefinedKey confusion
Hello All,
I have an NSMutableDictionary I'm trying to read from, but it's giving me
valueForUndefinedKey errors. I can NSLog the key successfully, so I'm very
confused as to what's going on.
NSLog(@"Total number of components in work: %i", [AllComponents count]);
for(NSString* cKey in AllComponents)
{
NSLog(@"key? %@", cKey);
MnSComponent *comp = (MnSComponent*)[AllComponents valueForKey:cKey];
[comp buildPitchMatrix];
[comp calculateTension];
}
The NSLog prints the expected key, then the code gags on the next line. ???
-
James B Maxwell
Composer/Doctoral Student
School for the Contemporary Arts (SCA)
School for Interactive Arts + Technology (SIAT)
Simon Fraser University
jbmaxw...@rubato-music.com
jbmax...@sfu.ca
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: valueForUndefinedKey confusion
Ha - that did it!
As expected, you are a rock star, Graham.
(and no, the following methods don't muck with the dictionary - it's obviously
some "subtlety" in KVC... There is an underscore in the key string, so that
probably borked it.)
cheers,
J.
On 2010-02-15, at 2:09 PM, Graham Cox wrote:
>
> On 16/02/2010, at 8:56 AM, James Maxwell wrote:
>
>> I have an NSMutableDictionary I'm trying to read from, but it's giving me
>> valueForUndefinedKey errors. I can NSLog the key successfully, so I'm very
>> confused as to what's going on.
>>
>> NSLog(@"Total number of components in work: %i", [AllComponents count]);
>> for(NSString* cKey in AllComponents)
>> {
>> NSLog(@"key? %@", cKey);
>> MnSComponent *comp = (MnSComponent*)[AllComponents valueForKey:cKey];
>> [comp buildPitchMatrix];
>> [comp calculateTension];
>> }
>>
>> The NSLog prints the expected key, then the code gags on the next line. ???
>
> Try -objectForKey: instead of -valueForKey: there might be some subtlety of
> use KVC versus direct access that's screwing things up here. The key might
> contain characters that can be misinterpreted by KVC - containing '@' or '.'
> characters for example.
>
> Also, are you certain that buildPitchMatrix and calculateTension are not
> mutating the dictionary? If they do the iteration will fail.
>
> --Graham
>
>
James B Maxwell
Composer/Doctoral Student
School for the Contemporary Arts (SCA)
School for Interactive Arts + Technology (SIAT)
Simon Fraser University
jbmaxw...@rubato-music.com
jbmax...@sfu.ca
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
strange crash in NSAccessibility
Hello All,
I have a strange crash happening while trying load an open file window/sheet
(NSOpenPanel).
I've got a simple AppController class, which is set as the Application's
delegate. This is all there is to the controller, at this point:
#import "AppController.h"
@implementation AppController
- (void) openPanelDidEnd:(NSOpenPanel*)openPanel returnCode:(int)returnCode
contextInfo:(void*)x
{
if(returnCode == NSOKButton)
{
NSString* path = [openPanel filename];
// do smart stuff here...
NSLog(@"Tried to import midi file %@", path);
}
}
- (IBAction) showMIDIImportPanel:(id)sender
{
NSOpenPanel* panel = [NSOpenPanel openPanel];
[panel beginSheetForDirectory:nil file:nil types:[NSSound
soundUnfilteredTypes] modalForWindow:[NSApp mainWindow] modalDelegate:self
didEndSelector:@selector(openPanelDidEnd:returnCode:contextInfo:)
contextInfo:NULL];
}
@end
I actually have no idea why the NSAccessibility stuff is coming up, and the
docs didn't shed much light for me. The bt is below.
It loads the sheet, then lists the files in the selected directory, then
crashes. It works fine if I disable access for assistive devices on the system,
but is there some legit way around this? Some exception I should be handling?
This is the first time I've run into any accessibility stuff.
Also, just in case anyone knows, when it does work (with assistive devices
disabled), it doesn't actually recognize midi files. Does anyone know what, if
not [NSSound soundUnfilteredTypes], what "types" I would indicate for opening
midi files?
Thanks in advance for any thoughts.
J.
#0 0x97c54a16 in -[NSException raise] ()
#1 0x931ac55c in NSAccessibilityAttributeValue ()
#2 0x933c443f in CopyAppKitUIElementAttributeValueNoCatch ()
#3 0x933c69d7 in CopyAttributeValue ()
#4 0x90461ad3 in _AXXMIGCopyAttributeValue ()
#5 0x9046bb96 in _XCopyAttributeValue ()
#6 0x9043dc39 in mshMIGPerform ()
#7 0x97b758db in __CFRunLoopRun ()
#8 0x97b73864 in CFRunLoopRunSpecific ()
#9 0x97b73691 in CFRunLoopRunInMode ()
#10 0x91a39f0c in RunCurrentEventLoopInMode ()
#11 0x91a39cc3 in ReceiveNextEventCommon ()
#12 0x91a39b48 in BlockUntilNextEventMatchingListInMode ()
#13 0x93160ac5 in _DPSNextEvent ()
#14 0x93160306 in -[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:] ()
#15 0x9312249f in -[NSApplication run] ()
#16 0x9311a535 in NSApplicationMain ()
#17 0x2828 in main () at main.m:13
---
James B Maxwell
Composer/Doctoral Student
School for the Contemporary Arts (SCA)
School for Interactive Arts + Technology (SIAT)
Simon Fraser University
jbmaxw...@rubato-music.com
jbmax...@sfu.ca
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: strange crash in NSAccessibility
okay, thanks Greg. Good to know that assistive devices isn't supposed to gate crash just any old cocoa party! I'll look for the memory bug. cheers, J. On 2010-02-19, at 10:53 AM, Greg Parker wrote: > On Feb 19, 2010, at 10:41 AM, James Maxwell wrote: >> I have a strange crash happening while trying load an open file window/sheet >> (NSOpenPanel). >> I've got a simple AppController class, which is set as the Application's >> delegate. This is all there is to the controller, at this point: >> >> I actually have no idea why the NSAccessibility stuff is coming up, and the >> docs didn't shed much light for me. The bt is below. >> It loads the sheet, then lists the files in the selected directory, then >> crashes. It works fine if I disable access for assistive devices on the >> system, but is there some legit way around this? Some exception I should be >> handling? This is the first time I've run into any accessibility stuff. >> >> #0 0x97c54a16 in -[NSException raise] () >> #1 0x931ac55c in NSAccessibilityAttributeValue () >> #2 0x933c443f in CopyAppKitUIElementAttributeValueNoCatch () >> #3 0x933c69d7 in CopyAttributeValue () >> #4 0x90461ad3 in _AXXMIGCopyAttributeValue () >> #5 0x9046bb96 in _XCopyAttributeValue () >> #6 0x9043dc39 in mshMIGPerform () >> #7 0x97b758db in __CFRunLoopRun () >> #8 0x97b73864 in CFRunLoopRunSpecific () >> #9 0x97b73691 in CFRunLoopRunInMode () >> #10 0x91a39f0c in RunCurrentEventLoopInMode () >> #11 0x91a39cc3 in ReceiveNextEventCommon () >> #12 0x91a39b48 in BlockUntilNextEventMatchingListInMode () >> #13 0x93160ac5 in _DPSNextEvent () >> #14 0x93160306 in -[NSApplication >> nextEventMatchingMask:untilDate:inMode:dequeue:] () >> #15 0x9312249f in -[NSApplication run] () >> #16 0x9311a535 in NSApplicationMain () >> #17 0x2828 in main () at main.m:13 > > This sort of backtrace is what happens when the assistive device machinery > interrogates your process. If you don't write any accessibility code then > assistive devices might not work well with your program, but it's not > expected to crash. > > The first thing to do is to look in the console for an error message printed > by that exception. My guess is that you have a memory error elsewhere, and > the exception is "unrecognized selector" because your memory error mangled > the accessibility data structures. If that's the case then the Zombie > Instrument should help find the bug. > > > -- > Greg Parker gpar...@apple.com Runtime Wrangler > > James B Maxwell Composer/Doctoral Student School for the Contemporary Arts (SCA) School for Interactive Arts + Technology (SIAT) Simon Fraser University jbmaxw...@rubato-music.com jbmax...@sfu.ca ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Unarchiving issues
Hello All, I have a strange problem with NSKeyedArchiver/Unarchiver. I have a very complex object graph that I want to be persistent, independently of my document objects, so I'm archiving it into the user's application support folder. The root object for the archive is a class called Network, which basically stores very little, but does store the "Hierarchy" for the object graph, which is basically just a 2D NSMutableArray (though it's a pretty big one). When I unarchive my Network root object, and initWithCoder gets called in the Network class, the Hierarchy seems fine -- I can iterate over the objects, posting relevant data, and everything looks good. However, once the Network is loaded into the application, iterating over the loaded Network Hierarchy gives an exc_bad_access error. I'm using the same routine to post the data, so nothing's changed there. The data that's causing the problem is a float* array, saved using encodeBytes:length:forKey, and decoded using decodeBytesForKey:returnedLength:, which is how I've saved a number of similar float* arrays in the Hierarchy. What I don't understand is how the Hierarchy can be fine at the end of the Network's initWithCoder method, but then get banjaxed somehow after that. Any thoughts greatly appreciated. J. James B Maxwell Composer/Doctoral Student School for the Contemporary Arts (SCA) School for Interactive Arts + Technology (SIAT) Simon Fraser University jbmaxw...@rubato-music.com jbmax...@sfu.ca ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Unarchiving issues
heh... yeah, that's true. But the thing is I haven't done anything different with this particular float* array. It's the same type of archiving I've used at many points in the app. But I hadn't thought to look for weak references could this be as simple as making sure to type cast objects when adding them to mutable arrays? J. On 2010-08-01, at 1:19 PM, Quincey Morris wrote: > On Aug 1, 2010, at 12:30, James Maxwell wrote: > >> What I don't understand is how the Hierarchy can be fine at the end of the >> Network's initWithCoder method, but then get banjaxed somehow after that. > > Sure you do. Things disappear suddenly when not retained or strongly > referenced. You're describing one of the classic manifestations of a memory > management error. > > > ___ > > 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/jbmaxwell%40rubato-music.com > > This email sent to jbmaxw...@rubato-music.com James B Maxwell Composer/Doctoral Student School for the Contemporary Arts (SCA) School for Interactive Arts + Technology (SIAT) Simon Fraser University jbmaxw...@rubato-music.com jbmax...@sfu.ca ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Unarchiving issues
Okay, so here's the initWithCoder from the object that's giving me grief. The
variable "continuations" is a float* array, and appears to load fine from here,
but disappears once the root object is unarchived and set. I've since
discovered that, through a mistake I made at another place in the code, I've
been shielded from noticing that all of my encoded float* arrays appear to be
doing the same disappearing act. So, I assume I'm doing something really wrong
here:
- (void)encodeWithCoder:(NSCoder
*)aCoder
{
// the size for the saved vector
NSUInteger size = ([self continuationsSize] * sizeof(float));
// save the length variable
[aCoder encodeInt:[self continuationsSize] forKey:@"continuationsSize"];
// encode the float* bytes
[aCoder encodeBytes:(uint8_t*)continuations length:size
forKey:@"continuations"];
}
- (id) initWithCoder:(NSCoder *)aDecoder
{
if(self = [super init])
{
NSUInteger size;
// init a bunch of other stuff
// set the size of the array (the accessor does the malloc)
[self setContinuationsSize:[aDecoder
decodeIntForKey:@"continuationsSize"]];
// set the contents of the array
continuations = (float*)[aDecoder
decodeBytesForKey:@"continuations" returnedLength:&size];
}
return self;
}
Thanks in advance,
J.
On 2010-08-01, at 8:34 PM, Michael Ash wrote:
> On Sun, Aug 1, 2010 at 3:30 PM, James Maxwell
> wrote:
>> Hello All,
>>
>> I have a strange problem with NSKeyedArchiver/Unarchiver. I have a very
>> complex object graph that I want to be persistent, independently of my
>> document objects, so I'm archiving it into the user's application support
>> folder. The root object for the archive is a class called Network, which
>> basically stores very little, but does store the "Hierarchy" for the object
>> graph, which is basically just a 2D NSMutableArray (though it's a pretty big
>> one). When I unarchive my Network root object, and initWithCoder gets called
>> in the Network class, the Hierarchy seems fine -- I can iterate over the
>> objects, posting relevant data, and everything looks good. However, once the
>> Network is loaded into the application, iterating over the loaded Network
>> Hierarchy gives an exc_bad_access error. I'm using the same routine to post
>> the data, so nothing's changed there.
>> The data that's causing the problem is a float* array, saved using
>> encodeBytes:length:forKey, and decoded using
>> decodeBytesForKey:returnedLength:, which is how I've saved a number of
>> similar float* arrays in the Hierarchy.
>> What I don't understand is how the Hierarchy can be fine at the end of the
>> Network's initWithCoder method, but then get banjaxed somehow after that.
>
> Post your code. It's *much* easier to debug code than a loose
> description of code.
>
> Mike
> ___
>
> 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/jbmaxwell%40rubato-music.com
>
> This email sent to jbmaxw...@rubato-music.com
James B Maxwell
Composer/Doctoral Student
School for the Contemporary Arts (SCA)
School for Interactive Arts + Technology (SIAT)
Simon Fraser University
jbmaxw...@rubato-music.com
jbmax...@sfu.ca
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Unarchiving issues
Thanks, everybody. Of course, you're all absolutely right, the buffer from decodeBytesForKey is temporary. I'd just assumed the bytes would be written to my malloced buffer, not realizing I needed to explicitly copy them. Problem solved. cheers, J. On 2010-08-02, at 10:56 AM, Graham Cox wrote: > > On 03/08/2010, at 3:46 AM, James Maxwell wrote: > >> continuations = (float*)[aDecoder >> decodeBytesForKey:@"continuations" returnedLength:&size]; > > > I expect the returned bytes are autoreleased. The docs don't state this > explicitly, but the similar method -decodeBytesWithReturnedLength: states "If > you need the bytes beyond the scope of the current autorelease pool, you must > copy them.". > > Try it and see if it solves the issue, sounds like a straightforward memory > bug. > > --Graham > James B Maxwell Composer/Doctoral Student School for the Contemporary Arts (SCA) School for Interactive Arts + Technology (SIAT) Simon Fraser University jbmaxw...@rubato-music.com jbmax...@sfu.ca ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Core Data bindings: add entity to relationship
I have a problem with Core Data and bindings that I can't work out. Here's the data model: <> It's a music app, and I'm trying to set up MIDI instrument customization for the user. The interface let's the user create new Instruments (MnS_Instrument entities) which map a name to a port and channel, new Articulations (Articulations entities) which map a name to a set of MIDI messages (controller changes, program changes, etc.), and then to assign the Articulations to Instruments. I have an array controller for each entity in the model. The AssignedArticulation controller gets its contentSet from [MnS_Instrument_controller selection].articulations, and the MIDIMessage controller gets its contentSet from [Articulation_controller selection].messages. (Note that I'm not hosting AUs yet, so virtualInstrument isn't used.) Everything works as expected, up to the assignment of articulations to instruments. I have a window with two tables: one showing the available instruments, and one for adding articulations to the selected instrument. The selection in the first table is bound to the [MnS_Instrument_Controller arrangedObjects].name, so that clicking a name selects a particular MnS_Instrument. The second table uses combo boxes for choosing which articulation to add; "+" and "-" buttons below the table are bound to the add: and remove: methods of AssignedArticulation_Controller. The available articulations, listed as choices in the combo boxes, are supplied by Articulation_controller, and they show up as expected. The value of the table selection is bound to [AssignedArticulation_Controller selection].articulation.name, the idea being that the AssignedArticulation will grab a named articulation from the set of stored Articulations, and assign it to the instrument. But when I release the combo box, it reverts back to "No Value" and won't make the assignment. Any ideas? J.___ 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
PropertyLocks?: strange exc_bad_access crash
I'm getting a crash with this trace: #0 0x99535ed7 in objc_msgSend #1 0xa0bf5224 in PropertyLocks #2 0x0001b792 in -[HSMM_Sequencer inputMemory] at HSMM_Sequencer.m:664 #3 0x0001903b in -[HSMM_Sequencer predictForward:] at HSMM_Sequencer.m:262 #4 0x00010253 in __-[HSMM_NetworkController runNetworkPrediction]_block_invoke_ at HSMM_NetworkController.m:256 #5 0x97762aa0 in _dispatch_apply2 #6 0x976332b2 in _dispatch_worker_thread2 #7 0x97632d41 in _pthread_wqthread #8 0x97632b86 in start_wqthread It only happens when running a particular function from its saved state (i.e., from initWithCoder). I've looked for the usual suspects, in terms of zombies and such, but I can't see anything obvious. The same algorithm runs fine from its newly created state (i.e., using init, rather than initWithCoder), so decoding must be somehow involved. Does this trace indicate anything special? Snooping into the objc_msgSend in gdb I see that the selector is a retain, which I'm assuming would only cause a crash if it was sent to a released object. I've not been able to find any info on "PropertyLocks", but it certainly sounds as though it's related to locking atomic properties... don't know though. What's strange, to me, is that if this is a threading problem, why does it only happen from a decoded state, not from a clean inited state? J.___ 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: PropertyLocks?: strange exc_bad_access crash
Yes, so I always use accessors in my initWithCoder routines. Is that a bad idea? My assumption was that the accessor would take care of the retain (most of these are synthesized, retaining accessors, though some are hand-written accessors -- but they should all be retaining). I'll double-check everything again, but I'm pretty sure all the initWithCoders should be retaining. J. On 2010-08-09, at 10:20 AM, Graham Cox wrote: > > On 10/08/2010, at 3:07 AM, James Maxwell wrote: > >> What's strange, to me, is that if this is a threading problem, why does it >> only happen from a decoded state, not from a clean inited state? > > > More likely to be a memory management problem. You're aware that objects > returned by -decodeObjectForKey: are autoreleased? > > Set a breakpoint at the start of -inputMemory and step until it crashes. Then > you know the errant line. Perhaps the property you're setting from the result > of the decode is incorrectly specified. Dunno - show your code. > > --Graham > > James B Maxwell Composer/Doctoral Student School for the Contemporary Arts (SCA) School for Interactive Arts + Technology (SIAT) Simon Fraser University jbmaxw...@rubato-music.com jbmax...@sfu.ca ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Core Data bindings: add entity to relationship
Thanks Quincy, But looking at the IB file, I've noticed that it already is a NSPopUpButtonCell, not a combo -- I got it wrong in my question, sorry. However, your description of my mistake sounds right; i.e., that I'm trying to change the name rather than assign the relationship. The other mistake in my original description is that the Value of the pop-up is bound to [AssignedArticulation_controller arrangedObjects].articulation.name (i.e., not "selection"), which does seem correct, since we don't know the selection yet... (I also tried binding it to the Index, rather than the Value, and this seemed a little closer, since it got rid of "No Value", and actually listed one of the created articulations. But I'm guessing this is just because the default index is assumed to be zero.) I got this design from a Core Data book, though it doesn't seem to work in the sample project from the book either, so I wish I hadn't used it. (Interestingly, that code does use a ComboBox, but switching it to a popup didn't fix it there either.) Mind you, the design does seem totally logical, to me, so I'm not sure how I would do it differently... How should I assign an entity to the relationship of another entity? The way I pictured it working was that the user builds an array of Articulation entities in one window/tab (which works). Then, in a second window/tab, s/he clicks one of the listed instruments in the left table, and then clicks the "+" at the bottom of the right table to create a new articulation mapping. This adds an object to the AssignedArticulation entity's articulations relationship - this is an Articulation entity. Picking a name from the popup then chooses the assigned articulation by name. Seems reasonable... J. On 2010-08-09, at 10:05 AM, Quincey Morris wrote: > On Aug 9, 2010, at 08:52, James Maxwell wrote: > >> I have a window with two tables: one showing the available instruments, and >> one for adding articulations to the selected instrument. The selection in >> the first table is bound to the [MnS_Instrument_Controller >> arrangedObjects].name, so that clicking a name selects a particular >> MnS_Instrument. The second table uses combo boxes for choosing which >> articulation to add; "+" and "-" buttons below the table are bound to the >> add: and remove: methods of AssignedArticulation_Controller. The available >> articulations, listed as choices in the combo boxes, are supplied by >> Articulation_controller, and they show up as expected. The value of the >> table selection is bound to [AssignedArticulation_Controller >> selection].articulation.name, the idea being that the AssignedArticulation >> will grab a named articulation from the set of stored Articulations, and >> assign it to the instrument. But when I release the combo box, it reverts >> back to "No Value" and won't make the assignment. >> >> Any ideas? > > Yup. (I need to make this response a macro, I think.) > > A combo box is a kind of text field, not a kind of menu, so it's the wrong > control to use in the circumstances described above. What you're doing by > making a "choice" from the combo box is trying to change the > Articulation.name string property, *not* the > AssignedArticulation.articulation relationship. > > Use a menu or a NSPopUpButton in your interface, instead of NSComboBox. > > > ___ > > 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/jbmaxwell%40rubato-music.com > > This email sent to jbmaxw...@rubato-music.com James B Maxwell Composer/Doctoral Student School for the Contemporary Arts (SCA) School for Interactive Arts + Technology (SIAT) Simon Fraser University jbmaxw...@rubato-music.com jbmax...@sfu.ca ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: PropertyLocks?: strange exc_bad_access crash
Sorry, no, the initWithCoder happens at program launch, in the main thread -
nothing fancy there.
It's just this method (the crashing one) that's running in its own thread, and
this is the same when creating the data structure from scratch (i.e. in init),
where it doesn't crash.
Also, the inputMemory array isn't actually decoded - I only need it at runtime,
so it's just inited manually in initWithCoder.
- (id) initWithCoder:(NSCoder *)aDecoder
{
if(self = [super init])
{
[self setHsmmNode_s:[aDecoder
decodeObjectForKey:@"hsmmNode_s"]];
[self setMaxSeqs:[aDecoder decodeIntForKey:@"maxSeqs"]];
[self setMaxSeqLength:[aDecoder
decodeIntForKey:@"maxSeqLength"]];
[self setTimeScale:[aDecoder decodeIntForKey:@"timeScale"]];
[self setLZTree:[aDecoder decodeObjectForKey:@"LZTree"]];
NSMutableArray* mem = [[NSMutableArray alloc] init];
[self setInputMemory:mem];
[mem release];
[self setDefaults];
}
return self;
}
This is from HSMM_Sequencer's initWithCoder, where the accessor for inputMemory
synthesized and retaining.
As a detail, when the program crashes, and drops into the debugger, clicking on
line #2 of the trace (below) doesn't actually take me to the line in the code
where inputMemory is accessed. It just takes me to the end of HSMM_Sequencer's
implementation section. I'm guessing the memory's banjaxed enough that it just
doesn't know where to put me, but maybe that's significant?
J.
On 2010-08-09, at 11:03 AM, Quincey Morris wrote:
> On Aug 9, 2010, at 10:07, James Maxwell wrote:
>
>> I'm getting a crash with this trace:
>>
>> #0 0x99535ed7 in objc_msgSend
>> #1 0xa0bf5224 in PropertyLocks
>> #2 0x0001b792 in -[HSMM_Sequencer inputMemory] at HSMM_Sequencer.m:664
>> #3 0x0001903b in -[HSMM_Sequencer predictForward:] at HSMM_Sequencer.m:262
>> #4 0x00010253 in __-[HSMM_NetworkController
>> runNetworkPrediction]_block_invoke_ at HSMM_NetworkController.m:256
>> #5 0x97762aa0 in _dispatch_apply2
>> #6 0x976332b2 in _dispatch_worker_thread2
>> #7 0x97632d41 in _pthread_wqthread
>> #8 0x97632b86 in start_wqthread
>>
>>
>> It only happens when running a particular function from its saved state
>> (i.e., from initWithCoder). I've looked for the usual suspects, in terms of
>> zombies and such, but I can't see anything obvious. The same algorithm runs
>> fine from its newly created state (i.e., using init, rather than
>> initWithCoder), so decoding must be somehow involved.
>> Does this trace indicate anything special? Snooping into the objc_msgSend in
>> gdb I see that the selector is a retain, which I'm assuming would only cause
>> a crash if it was sent to a released object. I've not been able to find any
>> info on "PropertyLocks", but it certainly sounds as though it's related to
>> locking atomic properties... don't know though. What's strange, to me, is
>> that if this is a threading problem, why does it only happen from a decoded
>> state, not from a clean inited state?
>
> Where is initWithCoder? Are you saying that you spun off a background thread
> that uses just-decoded objects from within initWithCoder in a different
> thread? In that case, how do you ensure that the decoding is complete first?
>
> Unless you do something special, the original decoding path is going to
> continue in parallel with the background operation. That means a mutable and
> possibly changing object graph is actively being used by 2 threads, which
> could be a recipe for disaster, even if only one of the threads is changing
> anything. It could even mean that the decoding itself proceeds simultaneously
> in multiple threads, which is likely an even bigger disaster.
>
> Or your problem could easily be a memory management error, as Graham
> suggests, but the conjunction of initWithCoder: and multithreading set off
> very loud alarm bells in my head.
>
>
> ___
>
> 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/jbmaxwell%40rubato-music.com
>
> This email sent to jbmaxw...@rubato-music.com
James B Maxwell
Composer/Doctoral Student
School for the Contempo
Re: Core Data bindings: add entity to relationship
Yes, you're right. The Content for the menu is bound to [Articulations_controller arrangedObjects], and Content Values is bound to [Articulations_controller arrangedObjects].name. This works as expected, in that I see the correct set of choices (Articulations_controller manages all the stored articulations, not the assigned ones). In terms of the popup, I'm not binding to the cell directly, but rather to the table column -- could that be the problem? I'm binding the Selected Value to [AssignedArticulations_controller arrangedObjects].articulation.name. And that just reverts to "No Value". I tried binding the column to Selected Object [AssignedArticulations_controller arrangedObjects].articulation and this at least **appeared** to work, since the chosen articulation stuck in the menu. But when I ran the assignment in the app it crashed on Articulation valueUndefinedForKey "name", which seemed a bit weird. So, I haven't been binding the cell itself. I've been under the impression that it's the column that gets bound, not the cell -- so, yes, I meant "Selected Value"... J. On 2010-08-09, at 12:16 PM, Quincey Morris wrote: > On Aug 9, 2010, at 11:47, James Maxwell wrote: > >> The other mistake in my original description is that the Value of the pop-up >> is bound to [AssignedArticulation_controller >> arrangedObjects].articulation.name (i.e., not "selection"), which does seem >> correct, since we don't know the selection yet... (I also tried binding it >> to the Index, rather than the Value, and this seemed a little closer, since >> it got rid of "No Value", and actually listed one of the created >> articulations. But I'm guessing this is just because the default index is >> assumed to be zero.) > > This doesn't sound right. NSPopUpButtonCell doesn't have a "Value" binding. > Do you mean "selectedValue"? > > NSPopupButton/Cell is hard to configure by bindings simply because you have > to very carefully keep track of the correct binding to use. There's content, > contentValues and contentObject. And selectedIndex, selectedValue and > selectedObject. Using some of the bindings affects the validity of others. > > Also, consider what [AssignedArticulation_controller > arrangedObjects].articulation.name means. [AssignedArticulation_controller > arrangedObjects] is an array, so sending the 'articulation' message to it > returns (because of NSArray behavior, nothing directly to do with KVO or > bindings) an array containing the result of sending 'articulation' to each of > its members. Sending that the 'name' message returns an array of the names of > the Articulation objects in it. > > That is, it builds a list of names of Articulations that have already been > assigned -- likely an empty list when your application starts. > > It seems like the content of the menu from which articulations are chosen > needs needs to be an array of Articulation.name strings, and has nothing to > do with AssignedArticulation.articulation, unless you're doing something a > whole lot more obscure. > > > ___ > > 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/jbmaxwell%40rubato-music.com > > This email sent to jbmaxw...@rubato-music.com James B Maxwell Composer/Doctoral Student School for the Contemporary Arts (SCA) School for Interactive Arts + Technology (SIAT) Simon Fraser University jbmaxw...@rubato-music.com jbmax...@sfu.ca ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: PropertyLocks?: strange exc_bad_access crash
ah, good to know. Thanks. J. On 2010-08-09, at 11:04 AM, Kyle Sluder wrote: > On Mon, Aug 9, 2010 at 10:42 AM, James Maxwell > wrote: >> Yes, so I always use accessors in my initWithCoder routines. Is that a bad >> idea? > > Yes, this is a bad idea. You should access instance variables directly > from within initializers and -dealloc. > > --Kyle Sluder ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Core Data bindings: add entity to relationship
> > > As to the rest of it, I'm lost as to what you're talking about. What does > "ran the assignment in the app" mean? Yeah, I just mean when I try to access the data programmatically from another part of the app -- when I iterate over the object hierarchy. > What's the exact text of the reported error? There is no such error as > "valueUndefinedForKey". Maybe you're referring to "valueForUndefinedKey"? Sorry, yes, that's correct. > > It sounds like your popup button selection is getting bound to the 'name' > property of the Articulation object, and you run into an exception because > there's no setter for that property. As I said before, configuring > NSPopUpButton bindings is hard. > hard it is. Cold comfort, I suppose. Thanks for your help. J. > > > ___ > > 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/jbmaxwell%40rubato-music.com > > This email sent to jbmaxw...@rubato-music.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: [ SOLVED ] Core Data bindings: add entity to relationship
Yikes... I finally figured out what I'd done. In fact, my model and bindings were correct. The problem was in trying to access the object hierarchy elsewhere in my code. I had it in mind that I wanted something like Instrument.articulation.name, when in fact my data structure demanded that it be Instrument.articulations.articulation.name. The only reason I was getting the valueForUndefinedKey is because I was leaving out one link in the chain. Ugh... Just in case anybody followed this little fiasco of mine, and was disappointed to reach the end without resolution, the only difference in IB was to assign my table's Selected Object (not Value) to [AssignedArticulation_controller arrangedObjects].articulation (not articulation.name). Of course, this makes sense, because it's a question of specifying a relationship to an Articulation entity, not just that entity's name. Thanks again for your help. J. On 2010-08-09, at 2:00 PM, James Maxwell wrote: >> >> >> As to the rest of it, I'm lost as to what you're talking about. What does >> "ran the assignment in the app" mean? > > Yeah, I just mean when I try to access the data programmatically from another > part of the app -- when I iterate over the object hierarchy. > >> What's the exact text of the reported error? There is no such error as >> "valueUndefinedForKey". Maybe you're referring to "valueForUndefinedKey"? > > Sorry, yes, that's correct. >> >> It sounds like your popup button selection is getting bound to the 'name' >> property of the Articulation object, and you run into an exception because >> there's no setter for that property. As I said before, configuring >> NSPopUpButton bindings is hard. >> > > hard it is. Cold comfort, I suppose. > Thanks for your help. > > J. > > > > >> >> >> ___ >> >> 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/jbmaxwell%40rubato-music.com >> >> This email sent to jbmaxw...@rubato-music.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/jbmaxwell%40rubato-music.com > > This email sent to jbmaxw...@rubato-music.com James B Maxwell Composer/Doctoral Student School for the Contemporary Arts (SCA) School for Interactive Arts + Technology (SIAT) Simon Fraser University jbmaxw...@rubato-music.com jbmax...@sfu.ca ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Weird scrolling thing in Lion
No, not the reversed scrolling which is really great, now that I'm used to it. I have a graphical music interface, created using DrawKit. I use command-shift-click (then drag) as a special command to export a MIDI file from the selected object (it's a musical staff object). It behaved properly in 10.6, but in 10.7, for no reason I can see, the interface pauses for a second, then suddenly starts scrolling left like mad. It happens without moving the mouse, so it's somehow automated. Does this make sense to anybody? Autoscrolling is enabled in the app, but as I say, the mouse hasn't moved in this case. Thanks in advance. J. James B Maxwell Composer/Doctoral Candidate School for the Contemporary Arts (SCA) School for Interactive Arts + Technology (SIAT) Simon Fraser University ___ 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: Weird scrolling thing in Lion
Ah, found it in DrawKit -- DKViewController, [view stopAutoScrolling]. Thanks Graham! ;-) (weird that I didn't need this before…) J. On 2012-04-03, at 4:21 PM, James Maxwell wrote: > No, not the reversed scrolling which is really great, now that I'm used to it. > > I have a graphical music interface, created using DrawKit. I use > command-shift-click (then drag) as a special command to export a MIDI file > from the selected object (it's a musical staff object). It behaved properly > in 10.6, but in 10.7, for no reason I can see, the interface pauses for a > second, then suddenly starts scrolling left like mad. It happens without > moving the mouse, so it's somehow automated. Does this make sense to anybody? > Autoscrolling is enabled in the app, but as I say, the mouse hasn't moved in > this case. > > Thanks in advance. > > J. > > > James B Maxwell > Composer/Doctoral Candidate > School for the Contemporary Arts (SCA) > School for Interactive Arts + Technology (SIAT) > Simon Fraser University > > > ___ > > 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/jbmaxwell%40rubato-music.com > > This email sent to jbmaxw...@rubato-music.com James B Maxwell Composer/Doctoral Candidate School for the Contemporary Arts (SCA) School for Interactive Arts + Technology (SIAT) Simon Fraser University ___ 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
crashes loading saved file
I've been having problems with my app crashing with an EXC_BAD_ACCESS while unarchiving a saved data file. The file is a graph representation of musical structure, created by a machine learning algorithm. When the file/graph is small there are no problems, but as I add more training material, and the file increases in size, at a certain point it starts crashing during unarchiving. Strangely, it has no problems saving the file, only unarchiving. The file is saved using: [NSKeyedArchiver archiveRootObject:model toFile:filePath]; Pretty straightforward. NSZombieEnabled gives no info, and code analysis reveals no memory warnings. I've been over the code many, many times, and haven't been able to track down a reasonable cause. The graph does have circular references/loops in some cases (i.e., node B points to a "parent" node A, which holds a reference to node B as a "child"), but I doubt that's the problem, since smaller files would have the same basic structure -- I used the archiveRootObject, which is supposed to deal with this situation (in my understanding). The last 30 frames of the backtrace: * thread #1: tid = 0x2603, 0x959f115c CoreFoundation`__CFStringEncodeByteStream + 12, stop reason = EXC_BAD_ACCESS (code=2, address=0xbf81acfc) frame #0: 0x959f115c CoreFoundation`__CFStringEncodeByteStream + 12 frame #1: 0x95a27a0a CoreFoundation`CFStringGetCString + 922 frame #2: 0x95a683d7 CoreFoundation`-[__NSCFString getCString:maxLength:encoding:] + 119 frame #3: 0x9b693190 Foundation`NSClassFromString + 82 frame #4: 0x9b6cb4bf Foundation`_decodeObjectBinary + 2191 frame #5: 0x9b6ccec9 Foundation`-[NSKeyedUnarchiver _decodeArrayOfObjectsForKey:] + 1533 frame #6: 0x9b6a06e7 Foundation`-[NSArray(NSArray) initWithCoder:] + 693 frame #7: 0x9b6cb9c0 Foundation`_decodeObjectBinary + 3472 frame #8: 0x9b6caa66 Foundation`_decodeObject + 197 frame #9: 0x0014c017 ManuScore`-[CbCMNode initWithCoder:] + 663 at CbCMNode.m:1176 frame #10: 0x9b6cb9c0 Foundation`_decodeObjectBinary + 3472 frame #11: 0x9b6ccec9 Foundation`-[NSKeyedUnarchiver _decodeArrayOfObjectsForKey:] + 1533 frame #12: 0x9b6a06e7 Foundation`-[NSArray(NSArray) initWithCoder:] + 693 frame #13: 0x9b6cb9c0 Foundation`_decodeObjectBinary + 3472 frame #14: 0x9b6caa66 Foundation`_decodeObject + 197 frame #15: 0x0014c017 ManuScore`-[CbCMNode initWithCoder:] + 663 at CbCMNode.m:1176 frame #16: 0x9b6cb9c0 Foundation`_decodeObjectBinary + 3472 frame #17: 0x9b6ccec9 Foundation`-[NSKeyedUnarchiver _decodeArrayOfObjectsForKey:] + 1533 frame #18: 0x9b6a06e7 Foundation`-[NSArray(NSArray) initWithCoder:] + 693 frame #19: 0x9b6cb9c0 Foundation`_decodeObjectBinary + 3472 frame #20: 0x9b6caa66 Foundation`_decodeObject + 197 frame #21: 0x0014c017 ManuScore`-[CbCMNode initWithCoder:] + 663 at CbCMNode.m:1176 frame #22: 0x9b6cb9c0 Foundation`_decodeObjectBinary + 3472 frame #23: 0x9b6ccec9 Foundation`-[NSKeyedUnarchiver _decodeArrayOfObjectsForKey:] + 1533 frame #24: 0x9b6a06e7 Foundation`-[NSArray(NSArray) initWithCoder:] + 693 frame #25: 0x9b6cb9c0 Foundation`_decodeObjectBinary + 3472 frame #26: 0x9b6caa66 Foundation`_decodeObject + 197 frame #27: 0x0014c017 ManuScore`-[CbCMNode initWithCoder:] + 663 at CbCMNode.m:1176 frame #28: 0x9b6cb9c0 Foundation`_decodeObjectBinary + 3472 frame #29: 0x9b6ccec9 Foundation`-[NSKeyedUnarchiver _decodeArrayOfObjectsForKey:] + 1533 frame #30: 0x9b6a06e7 Foundation`-[NSArray(NSArray) initWithCoder:] + 693 This morning, I tried enabling Guard Malloc (on its own, without zombies), and was surprised to see the app crash during training, with the following error: GuardMalloc[ManuScore-2438]: Failed to VM allocate 1864016 bytes GuardMalloc[ManuScore-2438]: Explicitly trapping into debugger!!! Is it simply running out of VM while trying to build the graph? If so, why doesn't this happen with Guard Malloc off? Also, with zombies and guard malloc off, why is it only when reading the file that the app crashes, not during training (i.e., while the graph is being built)? One thing I have noticed, that seems pretty weird, is that the complete backtrace when it crashes during unarchiving is 25962 frames long! Could it simply be that it's running out of memory while trying to unarchive (i.e., on the stack)? If so, how can I get around that? Some sort of caching, perhaps? The file is only 9.6 MB, so it's not a massive file... Any thoughts appreciated. J. -- James B. Maxwell Composer/Researcher/PhD Candidate ___ 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/archiv
Re: crashes loading saved file
Thanks All,
I'm just using retain-release, so I'll look into converting a version to ARC.
Unfortunately, I can't go 64-bit as I'm using DrawKit heavily, which doesn't
seem to support 64-bit builds. I'll also look into @autoreleasepool in certain
places. I do have a tendency to use the factory methods from NSNumber quite
often, so there may be cases where I'm creating lots of autoreleased NSNumber
objects.
However, I have to admit that I'm not sure how to fix the unarchiving process,
since the code runs fine while all the learning is happening and the graph is
being built. It seems to be the unarchiving process in particular that's a
problem. Is there some other way of periodically draining the pool during the
unarchiving process?
J.
On 2012-05-09, at 12:55 PM, Fritz Anderson wrote:
> On 9 May 2012, at 1:58 PM, James Maxwell wrote:
>
>> This morning, I tried enabling Guard Malloc (on its own, without zombies),
>> and was surprised to see the app crash during training, with the following
>> error:
>>
>> GuardMalloc[ManuScore-2438]: Failed to VM allocate 1864016 bytes
>> GuardMalloc[ManuScore-2438]: Explicitly trapping into debugger!!!
>>
>>
>> Is it simply running out of VM while trying to build the graph? If so, why
>> doesn't this happen with Guard Malloc off? Also, with zombies and guard
>> malloc off, why is it only when reading the file that the app crashes, not
>> during training (i.e., while the graph is being built)?
>>
>> One thing I have noticed, that seems pretty weird, is that the complete
>> backtrace when it crashes during unarchiving is 25962 frames long! Could it
>> simply be that it's running out of memory while trying to unarchive (i.e.,
>> on the stack)? If so, how can I get around that? Some sort of caching,
>> perhaps?
>> The file is only 9.6 MB, so it's not a massive file...
>
> 1. What kind of memory-management scheme are you using? Garbage collection,
> ARC, or retain-release?
>
> 2. Assuming (praying) that you're on a version-control system, consider
> creating a branch and converting the project to ARC. It will make better
> memory-management choices than you will. See if that helps.
>
> 3. Are you accumulating lots of temporary (autoreleased) objects? Can you
> investigate embedding code inside loops in @autoreleasepool{...} blocks?
> @autoreleasepool is not an ARC feature. It's usable in any OS target, and ARC
> / ARC conversion don't create local autorelease pools for you.
>
> 4. What does the Allocations template in Instruments tell you?
>
> 5. Failing all of that, would you be comfortable posting your -initWithCoder:
> methods?
>
> — F
>
>
> --
> Fritz Anderson -- Xcode 4 Unleashed: Due 21 May 2012 --
> <http://x4u.manoverboard.org/>
>
--
James B. Maxwell
Composer/Researcher/PhD Candidate
___
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: crashes loading saved file
Yes, I agree about 25k frames being pretty big. It's possible though, because the structure being unarchived is pretty complex... I decided to put an NSLog(@"Unarchiving %p", self) at the line where the crash finally occurs in initWithCoder of my CbCMNode class. Pasting the output into TextWrangler and searching for any given object returns only a single match, so I'm guessing there's no actual looping going on (but maybe there's a better way to check?). Interestingly, I just ran the Allocations instrument and it opened the file just fine. Poking a little more I noticed that profiling was running the release build, which is on -O2 optimization, and seems to be able to load... Of course, this will probably break as well, if I do more training. Unfortunately, ARC is going to be awkward with this project, as I'm getting loads of complaints from the ARC migration macro (not so many in my own code, but a few from DrawKit, which is used heavily in my app). But, either way, I think I have to figure out how to get the memory down. What seems strange to me is that, once the app is open, it's only taking 50 MB in real memory -- less than Mail, the Finder, Safari... So it's not a huge amount of memory. I think it's just the fact that the stack gets filled **during** the unarchiving process. But surely there must be a way around this. No? J. On 2012-05-09, at 7:11 PM, Roland King wrote: > 25,962 frames on the stack seems to me rather a lot. Yes unarchiving is a > very recursive process but that seems pretty deep. > > I missed the start of this thread so I don't know what mechanism you are > using to archive and unarchive things, but is it possible you've tripped it > up and it's going around a loop in the object graph and creating the same > things over and over again (I know the standard archiver/unarchiver classes > are coded to avoid that but if you have some code of your own, or have found > a bug in them .. ). I think the best advice there was to look at the > allocations screen on instruments, sort it by number of objects, it should be > very clear very quickly if you expect to have made a few hundred of something > whilst unarchiving and you have 20,000 of them. > > You could take a look at the stack trace as well, see if it looks like it's > repeating itself, if it does and goes through any of your code then that > gives you a place to look. > > On May 10, 2012, at 8:40 AM, James Maxwell wrote: > >> Thanks All, >> >> I'm just using retain-release, so I'll look into converting a version to >> ARC. Unfortunately, I can't go 64-bit as I'm using DrawKit heavily, which >> doesn't seem to support 64-bit builds. I'll also look into @autoreleasepool >> in certain places. I do have a tendency to use the factory methods from >> NSNumber quite often, so there may be cases where I'm creating lots of >> autoreleased NSNumber objects. >> However, I have to admit that I'm not sure how to fix the unarchiving >> process, since the code runs fine while all the learning is happening and >> the graph is being built. It seems to be the unarchiving process in >> particular that's a problem. Is there some other way of periodically >> draining the pool during the unarchiving process? >> >> J. >> >> >> On 2012-05-09, at 12:55 PM, Fritz Anderson wrote: >> >>> On 9 May 2012, at 1:58 PM, James Maxwell wrote: >>> >>>> This morning, I tried enabling Guard Malloc (on its own, without zombies), >>>> and was surprised to see the app crash during training, with the following >>>> error: >>>> >>>> GuardMalloc[ManuScore-2438]: Failed to VM allocate 1864016 bytes >>>> GuardMalloc[ManuScore-2438]: Explicitly trapping into debugger!!! >>>> >>>> >>>> Is it simply running out of VM while trying to build the graph? If so, why >>>> doesn't this happen with Guard Malloc off? Also, with zombies and guard >>>> malloc off, why is it only when reading the file that the app crashes, not >>>> during training (i.e., while the graph is being built)? >>>> >>>> One thing I have noticed, that seems pretty weird, is that the complete >>>> backtrace when it crashes during unarchiving is 25962 frames long! Could >>>> it simply be that it's running out of memory while trying to unarchive >>>> (i.e., on the stack)? If so, how can I get around that? Some sort of >>>> caching, perhaps? >>>> The file is only 9.6 MB, so it's not a massive file... >>> >
Re: crashes loading saved file
Okay, so I'm back to trying to tackle this annoying unarchiving crash… Just to recap the problem: I get a exc_bad_access crash when unarchiving certain files from disk. The file is a keyed archive, which contains a fairly complex custom object graph, with plenty of circular references (i.e., parentNode <---> childNode stuff). When this graph is relatively small I have no problems. But when it gets larger, it crashes. As mentioned previously, one seemingly significant thing about the crash is that the backtrace is >25,000 frames long. I've taken this to suggest that perhaps: A) some circular reference is getting stuck in a loop, or B) the graph is large enough that, while the unarchiver is trying to keep track of circular references, the stack overflows. I don't know if either of these possibilities makes sense, so I'm wondering how I might test for each? Partly because the massive backtrace isn't just a list of identical calls, and partly because the unarchiver is supposed to handle circular references, I kind of suspect B. But, if this is the case, how can I get around it? I already use archiveRootObject:toFile for archiving, so I would think I should be exploiting the built-in recursion checking stuff… Accordingly, I use unarchiveObjectWithFile to unarchive the graph. Everything I've done is pretty basic stuff, so perhaps my structure calls for a more advanced approach(??) I did include @autoreleasepool blocks in a couple of places, where temporary objects could be created during initialization. But that didn't help… So, I guess I'm wondering whether anyone else has had similar problems, and how you went about solving them. I should also mention that the file itself is very big - even a 13 MB file will cause the crash. By the way, it's not the super common failure to retain the unarchived object… Also, NSZombies and Guard Malloc don't show any obvious problems, and the static analyzer shows no memory errors. Any further thoughts greatly appreciated. J. James B Maxwell Composer/Doctoral Candidate School for the Contemporary Arts (SCA) School for Interactive Arts + Technology (SIAT) Simon Fraser University ___ 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: crashes loading saved file
Hi Charlie, Thanks for the reply. Hmm… I wonder if it would be enough to just copy the objects that lead to circular references? I'll think about it… I agree that it would be worth a try, if only to determine whether the problem really is related to circular references. thanks, J. On 2012-05-28, at 6:29 PM, Charlie Dickman wrote: > J, > > If it were my problem, even though keyed archiving is supposed to handle > circular references, I would try eliminating the circular references and see > if it made a difference (even if you have to duplicate objects multiple times > as this would only, at this time, be a test). > > I have no credentials to validate this approach other than 35 years of > professional programming experience. > > On May 28, 2012, at 6:14 PM, James Maxwell wrote: > >> Okay, so I'm back to trying to tackle this annoying unarchiving crash… >> >> Just to recap the problem: I get a exc_bad_access crash when unarchiving >> certain files from disk. The file is a keyed archive, which contains a >> fairly complex custom object graph, with plenty of circular references >> (i.e., parentNode <---> childNode stuff). When this graph is relatively >> small I have no problems. But when it gets larger, it crashes. As mentioned >> previously, one seemingly significant thing about the crash is that the >> backtrace is >25,000 frames long. I've taken this to suggest that perhaps: >> A) some circular reference is getting stuck in a loop, or B) the graph is >> large enough that, while the unarchiver is trying to keep track of circular >> references, the stack overflows. I don't know if either of these >> possibilities makes sense, so I'm wondering how I might test for each? >> >> Partly because the massive backtrace isn't just a list of identical calls, >> and partly because the unarchiver is supposed to handle circular references, >> I kind of suspect B. But, if this is the case, how can I get around it? I >> already use archiveRootObject:toFile for archiving, so I would think I >> should be exploiting the built-in recursion checking stuff… Accordingly, I >> use unarchiveObjectWithFile to unarchive the graph. Everything I've done is >> pretty basic stuff, so perhaps my structure calls for a more advanced >> approach(??) I did include @autoreleasepool blocks in a couple of places, >> where temporary objects could be created during initialization. But that >> didn't help… >> >> So, I guess I'm wondering whether anyone else has had similar problems, and >> how you went about solving them. I should also mention that the file itself >> is very big - even a 13 MB file will cause the crash. >> >> By the way, it's not the super common failure to retain the unarchived >> object… Also, NSZombies and Guard Malloc don't show any obvious problems, >> and the static analyzer shows no memory errors. >> >> Any further thoughts greatly appreciated. >> >> J. >> >> >> >> >> >> James B Maxwell >> Composer/Doctoral Candidate >> School for the Contemporary Arts (SCA) >> School for Interactive Arts + Technology (SIAT) >> Simon Fraser University >> >> >> ___ >> >> 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/3tothe4th%40comcast.net >> >> This email sent to 3tothe...@comcast.net > > Charlie Dickman > 3tothe...@comcast.net > > > James B Maxwell Composer/Doctoral Candidate School for the Contemporary Arts (SCA) School for Interactive Arts + Technology (SIAT) Simon Fraser University ___ 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: crashes loading saved file
Thanks, Quincey.
Well, I've revisited this problem many times over the past year, or so
(obviously, not on a daily, or even weekly basis, but the problem has been
lurking for a long time, unresolved). I've gone over the code in detail
literally hundreds of times looking for the kind of problem you describe. In
the parent/child relationships, the CbCMNode class has methods for "addChild"
and addParent" which specifically test for identity between the node being
added and self, so that a node's "childNodes" array, for example, can never
contain the node itself. Nevertheless, for the sake of thoroughness, I did just
place the NSAsserts you recommended in encodeWithCoder, but to no avail.
The only reason I've begun to even vaguely questioned the framework --
honestly, for the first time today -- is because I've read a number of threads
today that talked about potential problems in NSKeyedUnarchiver when dealing
with large, circular graphs -- one of which was actually posted by a developer
from Apple (can't recall who now). Also, Mike Ash's discussions on the subject
didn't help my confidence particularly...
Further, the fact that the size of the archive is a reproducible factor in the
crashes seems odd. The nature of the graphs is such that size shouldn't
influence the topology in any significant way (at least not considering the
size and complexity of some of the graphs that do load without problems). There
may be more nodes in the larger graphs, but their connectivity is fundamentally
the same as with small graphs. So any obvious problem, like adding "self" to a
"childNodes" array, would almost certainly show up in a smaller graph as well.
Having said that, it is a complex structure, so I'll go over it again…
But in response to your general suggestion that I'm somehow immediately jumping
to blaming the frameworks as a first course of action, that honestly couldn't
be further from the truth.
Again, if anybody has had a similar experience, or has any further thoughts,
any help would be appreciated.
J.
On 2012-05-28, at 7:58 PM, Quincey Morris wrote:
> On May 28, 2012, at 15:14 , James Maxwell wrote:
>
>> Just to recap the problem: I get a exc_bad_access crash when unarchiving
>> certain files from disk. The file is a keyed archive, which contains a
>> fairly complex custom object graph, with plenty of circular references
>> (i.e., parentNode <---> childNode stuff). When this graph is relatively
>> small I have no problems. But when it gets larger, it crashes. As mentioned
>> previously, one seemingly significant thing about the crash is that the
>> backtrace is >25,000 frames long. I've taken this to suggest that perhaps:
>> A) some circular reference is getting stuck in a loop, or B) the graph is
>> large enough that, while the unarchiver is trying to keep track of circular
>> references, the stack overflows. I don't know if either of these
>> possibilities makes sense, so I'm wondering how I might test for each?
>>
>> Partly because the massive backtrace isn't just a list of identical calls,
>> and partly because the unarchiver is supposed to handle circular references,
>> I kind of suspect B. But, if this is the case, how can I get around it? I
>> already use archiveRootObject:toFile for archiving, so I would think I
>> should be exploiting the built-in recursion checking stuff… Accordingly, I
>> use unarchiveObjectWithFile to unarchive the graph. Everything I've done is
>> pretty basic stuff, so perhaps my structure calls for a more advanced
>> approach(??) I did include @autoreleasepool blocks in a couple of places,
>> where temporary objects could be created during initialization. But that
>> didn't help…
>
> I think you're approaching this incorrectly.
>
> At best, you're stating the problem neutrally ("is getting stuck in a loop")
> as if uncertain whether to blame the frameworks (NSKeyedUnarchiver
> specifically) or your own code. This is a mistake. You *must* assume that
> you're doing something wrong, *until and unless* you find specific evidence
> that the frameworks are at fault.
>
> It's not that there can't be bugs in Cocoa frameworks. There are plenty.
> Rather, the rationale is that classes like NSKeyedUnarchiver have been used
> innumerable times, while your code has been used successfully -- how many
> times?
>
> Next, it's not remotely credible that NSKeyedUnarchiver is designed to
> recurse in a way that could put 25,000 frame on the stack. This would mean,
> for example, that NSKeyedUnarchiver wasn't usable in background threads,
> which by de
Re: crashes loading saved file
>
> I think I was referring to that inner voice that *tempts* you to blame, not
> any actual blaming. :)
Sure, understood.
>
> We're probably at the point where you need to start showing code, at least in
> a reduced version, for encodeWithCoder and initWithCoder.
>
- (void)encodeWithCoder:(NSCoder *)aCoder
{
[aCoder encodeObject:eventKey forKey:@"eventKey"];
[aCoder encodeObject:value forKey:@"value"];
[aCoder encodeInt:type forKey:@"type"];
[aCoder encodeInt:state forKey:@"state"];
[aCoder encodeFloat:closure forKey:@"closure"];
[aCoder encodeInt:depth forKey:@"depth"];
[aCoder encodeInt:count forKey:@"count"];
[aCoder encodeFloat:probability forKey:@"probability"];
[aCoder encodeObject:schemaNode forKey:@"schemaNode"];
[aCoder encodeObject:parentNodes forKey:@"parentNodes"];
[aCoder encodeObject:childNodes forKey:@"childNodes"];
[aCoder encodeObject:targetNodes forKey:@"targetNodes"];
[aCoder encodeObject:targetEdgeCounts forKey:@"targetEdgeCounts"];
[aCoder encodeObject:sourceNodes forKey:@"sourceNodes"];
[aCoder encodeObject:superState forKey:@"superState"];
[aCoder encodeObject:subStates forKey:@"subStates"];
}
- (id) initWithCoder:(NSCoder *)aDecoder
{
if((self = [super init]))
{
eventKey = [[aDecoder decodeObjectForKey:@"eventKey"] retain];
value = [[aDecoder decodeObjectForKey:@"value"] retain];
type = [aDecoder decodeIntForKey:@"type"];
state = [aDecoder decodeIntForKey:@"state"];
closure = [aDecoder decodeFloatForKey:@"closure"];
depth = [aDecoder decodeIntForKey:@"depth"];
count = [aDecoder decodeIntForKey:@"count"];
probability = [aDecoder decodeFloatForKey:@"probability"];
schemaNode = [[aDecoder decodeObjectForKey:@"schemaNode"] retain];
parentNodes = [[aDecoder decodeObjectForKey:@"parentNodes"] retain];
childNodes = [[aDecoder decodeObjectForKey:@"childNodes"] retain];
targetNodes = [[aDecoder decodeObjectForKey:@"targetNodes"] retain];
targetEdgeCounts = [[aDecoder decodeObjectForKey:@"targetEdgeCounts"]
retain];
sourceNodes = [[aDecoder decodeObjectForKey:@"sourceNodes"] retain];
superState = [[aDecoder decodeObjectForKey:@"superState"] retain];
subStates = [[aDecoder decodeObjectForKey:@"subStates"] retain];
}
return self;
}
CbCMNode is a NSObject subclass, btw.
> Incidentally, assuming each CbCMNode instance has a child array and a parent
> pointer, you aren't trying to to archive both, are you? I wouldn't expect
> that to work.
Well, yes, that's what happens. In fact, it's much hairier than that! There's
actually an array of parentNodes, not just one. It's a complex graph, as I
mentioned, not a straightforward tree (which would already contain mutual
parent/child references, it seems to me). In my structure, there are about
three dimensions of this kind of referencing, allowing me to move around the
graph in useful ways… It's encoding hierarchical musical structure, for a music
learning/generation algorithm, so there's a lot of complexity involved. As I
say, it loads fine with smaller files, and testing the structure after loading
indicates that it has been reconstructed properly. This is why I suspect
there's a problem with trying to keep track of all these relationships during
unarchiving, which NSKeyedUnarchiver does on the stack, afaik. There's an
interesting discussion on this here:
http://forum.soft32.com/mac/Archiving-large-graphs-part-II-ftopict44343.html
It's a very old thread, from 2004, but it does seem to be addressing similar
problems. And I think these cases are rare enough that Apple wouldn't
necessarily put a bunch of time into improving them… besides, Michael Ash's
comments seem to suggest that they really couldn't improve matters anyway,
within the overall design of the NSCoder model. I just wondered if, perhaps,
there was a way to get the whole thing to happen on the heap, rather than the
stack, so that it could complete successfully. It would be slow, but I could
deal with that for the time being (i.e., until I get my doctorate finished,
after which time I could rip it apart and try a different approach!).
I did try, btw, using encodeConditionalObject for parentNodes, sourceNodes, and
superState, all of which are CbCMNodes. But the structure was no longer intact
after trying this (parent connections gone), so I think I misunderstood how
conditional objects are supposed to work...
J.
James B Maxwell
Composer/Doctoral Candidate
School for the Contemporary Arts (SCA)
School for Interactive Arts + Technology (SIAT)
Simon Fraser University
___
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 S
Re: crashes loading saved file
> > That sounds like it could be a big clue, to me. > > encodeConditionalObject only encodes the object reference if it has been > seen by the archiver already. If it hasn't, nil is encoded. So if things are > breaking when you use it, it means that parts of the object graph you think > you encoded were not. > > It's pretty useful for archiving backpointers (though I agree that recreating > these rather than archiving them is probably safer). > > Assuming that your graph has a root node, archiving from root to leaves > should be OK, but you should use encodeConditionalObject for any object you > think you should have already archived (like parent nodes). > > Another issue could be that if you are storing your parent and child nodes in > an array, you probably have pretty solid retain cycles all over the place. > Backpointers should almost always be weak (nonretained) references, which > calls for special treatment if you want to put them in an array (use > [NSPointerArray pointerArrayWithWeakObjects]). Thanks, Graham. This is a good thought. I've not heard of NSPointerArray before… I'll look into it. It sounds like exactly the kind of structure I should be using. J. ___ 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: crashes loading saved file
Hi All, Yes, I think this general approach of trying to find a way of making reciprocal connections in initWithCoder, rather than archiving all connections, makes a great deal of sense. Quite honestly, this is an implementation of a theoretical model that is, in every conceivable way, a prototype. The priority was to figure out how to build the data structure and get it working as a musical representation. And it hasn't been easy by any stretch of the imagination. Improving and optimizing the implementation is a secondary goal and, while important, is not the focus of my research. That said, I do need to get it working for larger data sets, so I'm going to have to find some way around the current problem. The other option of reading all the nodes as UUIDs, loading them, and making the connections later is also a good option, and quite possibly the safest. As I say, the last thing I want to do is break the structure, which has taken a long time to get right (and by "right" I mean as a music representation, not a software implementation). Since the structure is learned from musical examples, I'd rather work with it as it is, and just figure out a way of encoding/decoding it that works. Thanks for your help, everybody. J. On 2012-05-28, at 11:39 PM, Quincey Morris wrote: > On May 28, 2012, at 22:08 , James Maxwell wrote: > >> Well, yes, that's what happens. In fact, it's much hairier than that! >> There's actually an array of parentNodes, not just one. It's a complex >> graph, as I mentioned, not a straightforward tree (which would already >> contain mutual parent/child references, it seems to me). In my structure, >> there are about three dimensions of this kind of referencing, allowing me to >> move around the graph in useful ways… It's encoding hierarchical musical >> structure, for a music learning/generation algorithm, so there's a lot of >> complexity involved. As I say, it loads fine with smaller files, and testing >> the structure after loading indicates that it has been reconstructed >> properly. This is why I suspect there's a problem with trying to keep track >> of all these relationships during unarchiving, which NSKeyedUnarchiver does >> on the stack, afaik. There's an interesting discussion on this here: > > I think have been stupid and still am stupid. > > (Still stupid because I don't understand how unarchiving can *validly* > resolve mutual references without returning an incompletely-initialized -- in > the sense of not yet having "returned self" -- object to at least one of the > referrers. But perhaps there's an inherent/implied/undocumented restriction > on the kinds of shenanigans that 'initWithCoder:' is allowed to get up to.) > > That aside, I have a suspicion, or perhaps it's just wild speculation, that > NSKeyedUnarchiver has some built-in safeguards that mean it can't just (in > effect) walk your object graph visiting each node once, but needs (in effect) > to walk every path through the graph, so that it actually visits nodes more > than once. And it does this through recursion. For a strictly hierarchical > object graph, there's no difference between the two strategies, but certain > other kinds of object graphs will take a lot of stack space and (even if it > doesn't overflow the stack) will perform very badly. > > Whatever the explanation, I think the solution is still not to archive both > parent and child pointers. Instead of this: > >>[aCoder encodeObject:parentNodes forKey:@"parentNodes"]; >>[aCoder encodeObject:childNodes forKey:@"childNodes"]; > > just this: > >>[aCoder encodeObject:childNodes forKey:@"childNodes"]; > > and instead of this: > >>parentNodes = [[aDecoder decodeObjectForKey:@"parentNodes"] retain]; >>childNodes = [[aDecoder decodeObjectForKey:@"childNodes"] retain]; > > something like this: > >>parentNodes = [[NSMutableArray alloc] init]; >>childNodes = [[aDecoder decodeObjectForKey:@"childNodes"] retain]; >>for (CbCMNode* node in childNodes) >> [node->parentNodes addObject: node]; > > If that's not satisfactory, then I think what you need to do is something > like what I imagine Core Data does. Instead of archiving object pointers (at > least for the potentially mutual references such as parents and children), > assign and archive UUIDs, and archive a global dictionary whose keys are the > UUIDs and whose objects are the CbCMNode instances. After you've finished > unarchiving the object graph,
properties and subclasses
I have a situation where I've created a subclass that overrides a number of
synthesized property accessors in its superclass. What I'm wondering is whether
the overridden methods will get called when using dot syntax, or if this will
just return the (inherited) synthesized properties?
So the "Thing" class has a property:
@property thingProp* aProp;
which is synthesized:
@synthesize aProp;
then the subclass "SubclassThing" has a hand-coded accessor to modify precisely
what aProp returns:
- (thingProp*)aProp
{
thingProp* somethingDifferent = notTheSameAsSuper;
return somethingDifferent;
}
With this setup, when I call mySubclassThing.aProp, do I get the synthesized
property (inherited) or the overridden method return? That is, do I have to
deliberately call [mySubclassThing aProp] to get the method return (i.e., not
using dot syntax)? Or, saying it another way, does a subclass' hand-coded
accessor override the superclass' synthesized accessor?
Strange question, I suppose, but it isn't totally clear to me what actually
happens.
J.
James B Maxwell
Composer/Doctoral Candidate
School for the Contemporary Arts (SCA)
School for Interactive Arts + Technology (SIAT)
Simon Fraser University
___
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: properties and subclasses
Okay, thanks. That seems reasonable, but I wanted to double-check. I remember reading some discussion a while ago that seemed to suggest that dot syntax was only for calling synthesized properties, not methods… Though precisely what a synthesized property would be, other than an accessor method (operative word being "method"), was never really explained! ;-) Thanks again. J. On 2012-07-05, at 8:40 AM, Jens Alfke wrote: > > On Jul 5, 2012, at 8:25 AM, James Maxwell wrote: > >> I have a situation where I've created a subclass that overrides a number of >> synthesized property accessors in its superclass. What I'm wondering is >> whether the overridden methods will get called when using dot syntax, or if >> this will just return the (inherited) synthesized properties? > > The overridden methods. Properties are just syntactic shorthand for getter > and setter methods, so the usual Objective-C rules of inheritance work. (In > Objective-C all methods are 'virtual' in C++ terminology; if a method is > overridden in a subclass, the only way to call the inherited method is via > 'super' from inside a subclass method.) > > —Jens James B Maxwell Composer/Doctoral Candidate School for the Contemporary Arts (SCA) School for Interactive Arts + Technology (SIAT) Simon Fraser University ___ 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
slow first context menu
Hello All, I'm finding that the first time I ask for a context menu (i.e., control-click or two-finger tap) it takes several seconds to come up. After that it responds normally. Has anybody seen this and, if so, do you recall what the problem was? (It only happens on my laptop, not my desktop... strange. Same Xcode version, same Scheme and build settings.) Cleaning and rebuilding doesn't help. thanks, J. James B Maxwell Composer/Doctoral Candidate School for the Contemporary Arts (SCA) School for Interactive Arts + Technology (SIAT) Simon Fraser University ___ 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: slow first context menu
Ah, thanks for the tip. I'll take a loot at that tomorrow. J. On 2012-07-07, at 6:00 PM, Jens Alfke wrote: > > On Jul 7, 2012, at 5:40 PM, James Maxwell wrote: > >> I'm finding that the first time I ask for a context menu (i.e., >> control-click or two-finger tap) it takes several seconds to come up. After >> that it responds normally. Has anybody seen this and, if so, do you recall >> what the problem was? (It only happens on my laptop, not my desktop... >> strange. Same Xcode version, same Scheme and build settings.) Cleaning and >> rebuilding doesn't help. > > I've had this too. It's caused by external services adding their items to the > menu. When it happened to me, it turned out to be Dropbox that was for some > reason really slow to add its items, but it might be something different for > you. > > Try pausing your app in the debugger during the hang (or sampling it), and > see what the top of the stack looks like. > > —Jens James B Maxwell Composer/Doctoral Candidate School for the Contemporary Arts (SCA) School for Interactive Arts + Technology (SIAT) Simon Fraser University ___ 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
NSPointerArray compact
Hi All, I'm using NSPointerArrays to store references for a complex object graph. The nodes themselves are stored in an NSDictionary for archiving, and the pointer arrays are just used to record the interconnectivity of the nodes (it's loopy and complex, which has been causing problems with NSKeyedUnarchiver). What I'm finding is that I'm getting nil references in my pointer arrays after unarchiving (which is a mystery I still have to solve), so I'd like to get rid of the nils before using the graph. However, calling -compact on them doesn't seem to work. No matter what I do, the nils are still in the arrays, and I'm really not sure what else I can do to get rid of them. The objects are instances of a custom class (i.e., not primitives) and I'm initializing with -pointerArrayWithWeakObjects. Any thoughts appreciated. J. James B Maxwell Composer/Doctoral Candidate School for the Contemporary Arts (SCA) School for Interactive Arts + Technology (SIAT) Simon Fraser University ___ 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
compile DrawKit in 10.8
Hello All, Has anyone had problems compiling drawkit on 10.8? I can't seem to build it. I tried downloading a fresh copy from apptree.net, but I still get errors. I'm using "Latest" base sdk and the "default" LLVM compiler. I'm trying to build the 32-bit version, for now, and getting these 4 errors: Undefined symbols for architecture i386: "_partcodeForElement", referenced from: -[DKDrawablePath pathCreateLoop:] in DKDrawablePath.o -[DKDrawablePath lineCreateLoop:] in DKDrawablePath.o -[DKDrawablePath polyCreateLoop:] in DKDrawablePath.o -[DKDrawablePath arcCreateLoop:] in DKDrawablePath.o -[DKDrawablePath isOpenEndPoint:] in DKDrawablePath.o -[NSBezierPath(DKEditing) moveControlPointPartcode:toPoint:colinear:coradial:constrainAngle:] in NSBezierPath+Editing.o "_partcodeForElementControlPoint", referenced from: -[DKDrawablePath pathCreateLoop:] in DKDrawablePath.o -[NSBezierPath(DKEditing) partcodeHitByPoint:tolerance:startingFromElement:prioritiseOnPathPoints:] in NSBezierPath+Editing.o -[NSBezierPath(DKEditing) partcodeForLastPoint] in NSBezierPath+Editing.o -[NSBezierPath(DKEditing) moveControlPointPartcode:toPoint:colinear:coradial:constrainAngle:] in NSBezierPath+Editing.o "_subdivideBezierAtT", referenced from: -[NSBezierPath(DKEditing) insertControlPointAtPoint:tolerance:type:] in NSBezierPath+Editing.o -[NSBezierPath(Geometry) distanceFromStartOfPathAtPoint:tolerance:] in NSBezierPath+Geometry.o _subdivideBezierAtLength in NSBezierPath+Geometry.o ld: symbol(s) not found for architecture i386 clang: error: linker command failed with exit code 1 (use -v to see invocation) Any thoughts appreciated. J. -- James B. Maxwell Composer/Researcher/PhD Candidate ___ 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
Framework methods not recognized
Hello All, I've created a framework to pull together a bunch of code I'm using regularly. When I include this framework in another project the project builds, and the methods do appear to get called, but I get "instance method <…> not found" warnings all over the place. The headers are all imported in my framework's master header, and they're all public (as is the master). So, basically it works, but Xcode is warning me that it might not… Any idea why? Something in the project configuration? J. ___ 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: Framework methods not recognized
Hi Fritz, Thanks for the reply. The tricky thing about this "application" is that it's actually a Max 6 external object, so it's not officially an application, and doesn't have a .pch file (at last not in the Xcode project). They do have a config file that points to one of their support files, which in turn has a .pch file… But I tried adding my framework's master header there, without success... Anyway, it seems like this will be a detail specific to writing Max externals, so I'll post on their forum. On a different, but related note, I want my framework to be useable for Max externals, but not limited to that use. To work in Max I need to link against their MaxAPI.framework. What I'm wondering is how I might be able to NOT load the MaxAPI.framework for Cocoa application writing, and load it only for writing Max externals. I managed to get a normal Cocoa app to **build** by making the MaxAPI.framework "optional" in the build settings, but this only delayed the crash until runtime, when the code tried to make a call to the MaxAPI. Obviously what I need to do, in addition to not loading the MaxAPI, is to avoid making calls to its methods/functions. I'm guessing I could do that in a preprocessor routine, by checking whether the MaxAPI is being loaded, then setting some sort of "will_use_Max" flag that my framework can use to turn on/off certain blocks of code… But how can I check whether a framework is being loaded? J. On 2013-02-06, at 10:09 AM, Fritz Anderson wrote: > On 6 Feb 2013, at 10:46 AM, James Maxwell wrote: > >> I've created a framework to pull together a bunch of code I'm using >> regularly. When I include this framework in another project the project >> builds, and the methods do appear to get called, but I get "instance method >> <…> not found" warnings all over the place. The headers are all imported in >> my framework's master header, and they're all public (as is the master). > > "in my _framework's_ master header" - and is that header #imported in your > application code, for instance in the .pch file? > >> >> So, basically it works, but Xcode is warning me that it might not… Any idea >> why? Something in the project configuration? > > -- > Fritz Anderson > Xcode 4 Unleashed: 4.5 supplement for free! > http://www.informit.com/store/xcode-4-unleashed-9780672333279 > ___ 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
faster deep copies?
I've run into a situation where I really need a deep copy of an object. I've implemented this using Apple's recommended approach with NSKeyedArchiver/Unarchiver, and it's nice, simple, and functional. But it's also pretty darn slow -- as in a clear, subjectively apparent performance hit. Has anybody had to find a way around this, and if so, what did you do? Or if anybody just has a nice, creative thought about another way of doing it, I'd love to hear about it. The object(s) being copied are custom classes, and there's a chance I may be able to get away with copying only certain properties (i.e., rather than archiving the entire graph from the root object), so I'll look into making a "deepCopy" method that's more selective. But I'd appreciate any thoughts in the meantime. Thanks in advance. J. ___ 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: faster deep copies?
Well, yes, that's a good question. But I spent a good deal of time trying to find a way around it and couldn't. However, in the meantime I discovered that by using a home-spun -deepCopy method on just a couple of classes I was able to solve my mutation problem, without resorting to the wholesale NSKeyedArchiver approach of grabbing the entire object graph. So, problem solved. If I ever feel inclined to discover a deeper fix I will, but it won't be any time soon! J. On 2013-02-14, at 4:01 PM, Graham Cox wrote: > > On 14/02/2013, at 1:07 PM, James Maxwell wrote: > >> I've run into a situation where I really need a deep copy of an object. > > > > My question would be: are you really sure? > > Yes, there are times you need a deep copy, but surprisingly few. Often you > can redesign your code not to need one > > --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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
