Re-establishing KVO in Managed objects after undo
Hi, I have some places in my code where I have managed objects that need to observe various key paths. If one of these objects has been deleted by the user, and then they undo, I need to re-establish the KVO. As undo doesn't call awakeFromFetch, I need to do this somewhere else. I have awakeFromSnapshotEvents: implemented for 10.6+ users, and it works fine, but is only available in 10.6, whereas I need to also have something that will work on 10.5. How did you accomplish this before 10.6? TIA Gideon ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: the case of the missing scroll bar
hi all, i figured this one out. when you initially create a scroll bar, that is when the horizontal or vertical aspect of the bar is determined. if you resize it later, that does not change the horizontal or vertical setting. so i was initializing my scroll bars with a square rectangle and calling the resize routine right after that. that is why one of the bars was hidden -- it was a horizontal bar in a vertical slot, or vice verse. best, bill appleton On Fri, Apr 30, 2010 at 12:04 PM, Bill Appleton billapple...@dreamfactory.com wrote: hi anyone out there, i am having trouble using NSScroller by itself, not in a scroll view, etc. if i open more and more text windows a scroll bar will appear on the right or bottom of each one each window has 2 scroll bars, i have verified there are 2 sub views, but only one appears at a time i can't find any graphics clipping problems or something like that i have looked for something that tells the scroll bar to be vertical or horizontal but can't find it, i assume it looks at the width or height just does that automatically i think i can see a horizontal bar stuck in a little piece of the vertical slot, and a vertical bar stuck in the horizontal slot the slots are correct in size, but maybe the bar hasn't re-jiggered to fit the slot does anyone know what is going on? thanks, bill appleton ___ 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: Re-establishing KVO in Managed objects after undo
There's no easy way to do this. But if you are observing other managed objects, you might be able to use +(NSSet*)keyPathsForValuesAffectingKey instead. (Search for registering dependent keys in the docs.) If you are observing something that is not part of your data model, you might try using mechanisms other than KVO to keep your data model updated. KVO can be a world of hurt when used the way you are using it. There are old threads on this topic. See, for example, Strange NSManagedObjectContextObjectsDidChangeNotification behavior. Dave On 2010-05-01, at 9:42 AM, Gideon King wrote: Hi, I have some places in my code where I have managed objects that need to observe various key paths. If one of these objects has been deleted by the user, and then they undo, I need to re-establish the KVO. As undo doesn't call awakeFromFetch, I need to do this somewhere else. I have awakeFromSnapshotEvents: implemented for 10.6+ users, and it works fine, but is only available in 10.6, whereas I need to also have something that will work on 10.5. How did you accomplish this before 10.6? TIA Gideon ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/dave.fernandes%40utoronto.ca This email sent to dave.fernan...@utoronto.ca ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: How to get tapped text from UITextView
It would be simpler to save the CGRect you calculate per word in an array and just enumerate the rects for the point tapped. -- Alex Kac On my mobile device so please excuse the brevity. On May 1, 2010, at 12:19 AM, Sasikumar JP jps...@gmail.com wrote: Alex, I can draw the text using NSString's drawing method. But I am not clear how to get the tapped String using touch point or GCRect. I don't any direct method to get the String by passing CGPoint or CGRect. I was able to successfully implement this feature by creating CATextLayer for each word and put all the layers as a sublayer of UIView's layer object. When user tapped on this View, hitTest method would return the Layer which was tapped. Using the Layer Object i was able to get the tapped string. Does this approach cause any performance or memory related issue. since i am creating CATextLayer object for each word. Thanks Sasikumar On 30-Apr-2010, at 8:44 PM, Alex Kac wrote: You are going to have to draw the text yourself using NSString's drawing methods and then use the regular touch events and CGRects to do that. Or use a UIWebView with links to each word that you recognize. -- Alex Kac On my mobile device so please excuse the brevity. On Apr 30, 2010, at 12:38 AM, Sasikumar JP jps...@gmail.com wrote: Hi, I am working on a iPhone Application. I want to implement the following feature in my app, but i don't know how to implement it. I want to display the read-only text content in UITextView, where user can tap any word in the text. It should take the user to next screen to display more detail about the tapped word. I dont know how to get tapped word from the UITextView. I have set the UITextView as a read-only to avoid the popping key-board and I have subclassed the UITextView to override the canPerformAction: withSender to disable the cut paste feature. I have overridden touchesBegan method to get the touch/tap Event. But i am not sure how to get only the tapped word from the complete text. Any help is highly appreciated. Thanks Sasikumar___ 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 ___ 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: Re-establishing KVO in Managed objects after undo
On Sat, May 1, 2010 at 9:34 AM, Dave Fernandes dave.fernan...@utoronto.ca wrote: If you are observing something that is not part of your data model, you might try using mechanisms other than KVO to keep your data model updated. KVO can be a world of hurt when used the way you are using it. There are old threads on this topic. See, for example, Strange NSManagedObjectContextObjectsDidChangeNotification behavior. Agreed. Your controller should listen for MOC notifications to find out when to start and stop observing objects. After all, that's what NSArrayController does. --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: Re-establishing KVO in Managed objects after undo
Thanks guys - will look into that. On 02/05/2010, at 3:11 AM, Kyle Sluder wrote: On Sat, May 1, 2010 at 9:34 AM, Dave Fernandes dave.fernan...@utoronto.ca wrote: If you are observing something that is not part of your data model, you might try using mechanisms other than KVO to keep your data model updated. KVO can be a world of hurt when used the way you are using it. There are old threads on this topic. See, for example, Strange NSManagedObjectContextObjectsDidChangeNotification behavior. Agreed. Your controller should listen for MOC notifications to find out when to start and stop observing objects. After all, that's what NSArrayController does. --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: Re-establishing KVO in Managed objects after undo
Gideon King (gid...@novamind.com) on 2010-05-01 09:42 said: Hi, I have some places in my code where I have managed objects that need to observe various key paths. Why? (I'm curious... I've never used such a pattern.) Perhaps instead you could override setters so that they perform other actions in addition to just changing the attribute/relationship. Sean ___ 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: Re-establishing KVO in Managed objects after undo
It's inherited code from someone else, and am trying to work that out myself too...luckily there are only 5-6 of them, so I should be able to sort it out. Just looking at it now, I think a little refactoring should sort it out, and remove the need for KVO. On 02/05/2010, at 5:23 AM, Sean McBride wrote: Gideon King (gid...@novamind.com) on 2010-05-01 09:42 said: Hi, I have some places in my code where I have managed objects that need to observe various key paths. Why? (I'm curious... I've never used such a pattern.) Perhaps instead you could override setters so that they perform other actions in addition to just changing the attribute/relationship. Sean ___ 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: Matching the style of a HUD?
On Apr 30, 2010, at 5:50 PM, cocoa-dev-requ...@lists.apple.com wrote: Date: Fri, 30 Apr 2010 16:52:56 -0400 From: Izak van Langevelde eezac...@xs4all.nl Subject: Re: Matching the style of a HUD? To: Murat Konar mu...@pixar.com Cc: list-cocoa-dev List cocoa-dev@lists.apple.com Message-ID: 09e1717e-7378-4704-99c3-6366c295e...@xs4all.nl Content-Type: text/plain; charset=us-ascii On 2010-04-30, at 3:22 PM, Murat Konar wrote: On Apr 30, 2010, at 12:02 PM, Izak van Langevelde wrote: Maybe I'm overlooking something trivial, but an NSPanel with HUD style is still an NSPanel, and not a window: I cannot seem to get the minimize and maximize buttons in the title bar? Are you really making a HUD or do you just want your windows to look like Pixelmators? If the latter, you should - reconsider if that's really the best thing for your users (if your windows looks like HUDs, how will you distinguish a HUD from a garden variety window?) A HUD is slightly transparent, while the garden variety windows I have in mind are not... - if so, roll your own That brings me back to my question: how do I create matching black windows? You normally don't. Pixelmator did this for an image editor app. That is a place where it *might* make sense. Even though, it has long been more of a tradition to do the following for image editing: use a neutral gray or dark gray background or give the user a choice (color theory is real here) The UI of Apple's pro apps (Final Cut, Logic, etc...) tend to have darker interfaces. In general you'll find the Mac landscape going all the way back has tried to make a nice interface that also gets out of the way and becomes background. The primary focus is on the content that the user should care about. The secondary focus is on the UI implicitly showing the user what they need to do / know. This means making something that is thoughtful and intuitive. A text document editor with a non-standard black UI is generally against this. There are always exceptions in the world of design. But seriously consider whether it is in the users' best interest or if it is an I think it looks cool choice. If you are creating a text editing app of some sort, please, please, please, read the HIG. Stick to the HIG. Don't pollute the user space with apps that don't act like or look like mac apps. That's the windows world. But before you decide what to do, be sure to read the HIG. It is full of years (decades even) of thought and experience. It is pretty smart. Consistency helps users, reduces support costs and needs.___ 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: Matching the style of a HUD?
Izak, On 30/04/2010, at 17:48, Izak van Langevelde wrote: My problem is the difference in style between HUDS and 'normal' windows: I don't want my document windows to be transparent, I just want them to be black to match the style of a HUD. White and bright document windows really don't match black and dark HUDs... I know I'm not really helping you achieve your objective, but... White and bright document windows don't match HUD panels because they are not the same. They don't serve the same purpose and were created different to state that, visually. I know Apple violates the Human Interface Guidelines that they created themselves, but I don't think anyone should go for it just because they did. Clarifying what I mean: Apple's Pro Apps use differently-styled windows, which don't follow the HIG, at least IMHO. Another example is Pixelmator. I, for one, don't like Pixelmator's windows. I don't think it helps to have black opaque windows that match the HUD panels just for the sake of matching styles. After all, Photoshop and Illustrator, for example, used standard (light-colored) panels for quite a long time, before adopting the current gray style. I like the apps I use to be consistent in their interfaces and think most users also do. I think that's why Apple created the HIG in the first place. So, I ask you to think about your app and consider if even the HUD panels are needed. From the Apple Human Interface Guidelines: In general, therefore, you should use transparent panels only when at least one of the following statements is true: • Your application is media-centric, that is, focused on movies, photos, or slides. • Users use your application in a dark environment or in an immersion mode. • A standard panel would distract users from the main window. • Users make only quick adjustments in the panel and dismiss it quickly. I would assume (from guessing) that your case is very similar to the standard panel would distract users above. Is the main window distracting users from the panels? If it is, then your panels are being use constantly, not momentarily, which violates only quick adjustments in the panel above. Please, forgive the long text and don't take it as a lecture. I am really trying to help. Cheers, Flavio___ 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: Matching the style of a HUD?
On 2010-05-01, at 6:04 PM, Flavio Donadio wrote: So, I ask you to think about your app and consider if even the HUD panels are needed. From the Apple Human Interface Guidelines: In general, therefore, you should use transparent panels only when at least one of the following statements is true: • Your application is media-centric, that is, focused on movies, photos, or slides. • Users use your application in a dark environment or in an immersion mode. • A standard panel would distract users from the main window. • Users make only quick adjustments in the panel and dismiss it quickly. I would assume (from guessing) that your case is very similar to the standard panel would distract users above. Is the main window distracting users from the panels? If it is, then your panels are being use constantly, not momentarily, which violates only quick adjustments in the panel above. I'm working on software for animation linetesting. That is, users edit a so-called 'exposure sheet', which is essentially a table of images, which specifies which pictures goes into what movie frame. The exposure sheet is layered, so I need a panel which specifies which layers exist/are visible. The main window consists of a movie player. It is essentially media-centric, I like the look and feel of black and white drawings against a dark background. Please, forgive the long text and don't take it as a lecture. I am really trying to help. Your response is appreciated! The main motivation for writing this application, is that existing linetesting software is typically buggy or awkward to use, so user friendliness is a huge point for me. Although I really would love to write something that matches Apples Quicktime player, everything in Cocoa and everyone with a strong opinion on user interface design seems to scream DON'T even think about it, unless you are absolutely sure you know what you're doing, and even then, think twice' So, any input is welcome... Thanks, Izak --- Grinnikend door het leven... ___ 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: Matching the style of a HUD?
On May 1, 2010, at 15:57, Izak van Langevelde wrote: Although I really would love to write something that matches Apples Quicktime player, everything in Cocoa and everyone with a strong opinion on user interface design seems to scream DON'T even think about it, unless you are absolutely sure you know what you're doing, and even then, think twice' So, any input is welcome... FWIW ... I think the screaming DON'T part is a sort of shortcut -- the reality is a bit more nuanced. There's nothing intrinsically wrong with the idea of a dark interface, if you've decided it's appropriate to the application you're writing. But then you should design your *own* dark interface so that: a. it doesn't try to match the design details of the Cocoa HUD windows, but nevertheless isn't in glaring conflict with them b. it doesn't try to match the design details of any of the standard windows, but nevertheless isn't in glaring conflict with them c. it doesn't try to be pointlessly quirky, but maintains as neutral a set of design values as is consistent with pleasing design My point is that if you try to match an existing design, when Apple changes its standard designs (which it does to some degree with every Mac OS X release), you app will look out-of-date. You want a design that stands up to Mac OS changes. If you take this seriously, your application design process is *much* harder than than if you go with standard window appearance -- you really need to come up with something lasting. Plus, you're probably going to have to write some difficult code to implement your design. (Adobe flagship software products might be a good case study in the difficulties of this kind of design process.) That difficulty is what the screamers are warning you about, even if they don't express it that way. ___ 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: Matching the style of a HUD?
Your response is appreciated! The main motivation for writing this application, is that existing linetesting software is typically buggy or awkward to use, so user friendliness is a huge point for me. Although I really would love to write something that matches Apples Quicktime player, everything in Cocoa and everyone with a strong opinion on user interface design seems to scream DON'T even think about it, unless you are absolutely sure you know what you're doing, and even then, think twice' So, any input is welcome... This is the traditional stance of this list, but I would take such advice with a grain of salt. I often wonder what Apple's apps (Time Machine, Front Row, iMovie, iDVD, 10.6 Quicktime Player, etc.) would look like if Apple came to this list for design advice. Granted, if you're making Calculator 3000 or another TextEdit, it's probably best to stick to the presets. But it's Apple's UI tinkering that brings us new OS-supported widgets and controls, and it's what keeps the HIG fresh. If you genuinely care about a first-class UI and user experience, why leave the innovation to them? ___ 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
On May 1, 2010, at 5:04 PM, James Maxwell jbmaxw...@rubato-music.com 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 ___ 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
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 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)
{
readyToLearn = NO;
break;
}
}
if(readyToLearn ==
YES [aNode predictionRequestsLocked] == YES) // the child is asking for
help! the parent needs to learn
{
[aNode
setPredictionRequestsLocked:NO];
[aNode
setInputCounter:([aNode inputCounter] + 1)];
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)
{
readyToLearn = NO;
break;
}
}
if(readyToLearn ==
YES [aNode predictionRequestsLocked] == YES) // the child is asking for
help! the parent needs to learn
[iPhone] How to scroll to UITableView footer view
Hi, How can I scroll to a UITableView footer all the time, while adding cells to table view content. Is there some way similar to scrollToRowAtIndexPath: , to scroll directly into my bottom footer view after adding new cells ? Thank you and Kind Regards, Tharindu Madushanak ___ 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: [iPhone] How to scroll to UITableView footer view
UITableView is a subclass of UIScrollView. So, you can ask for its contentSize and then call scrollRectToVisible:animated: with a rect that lies at the end of the contentSize. Luke On May 1, 2010, at 7:52 PM, Tharindu Madushanka wrote: Hi, How can I scroll to a UITableView footer all the time, while adding cells to table view content. Is there some way similar to scrollToRowAtIndexPath: , to scroll directly into my bottom footer view after adding new cells ? Thank you and Kind Regards, Tharindu Madushanak ___ 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: [iPhone] How to scroll to UITableView footer view
On 1 May 2010, at 9:52 PM, Tharindu Madushanka wrote: How can I scroll to a UITableView footer all the time, while adding cells to table view content. Is there some way similar to scrollToRowAtIndexPath: , to scroll directly into my bottom footer view after adding new cells ? What success do you have with -[UIScrollView scrollRectToVisible:animated:], using a CGRect calculated from the scroll view's contentSize? UITableView is a UIScrollView. Always look for the properties and methods of the superclasses. — 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
Re: [iPhone] How to scroll to UITableView footer view
Actually this doesn't seem to scroll to footer view :( Following is the code I have, i am continuously adding cells. Now I want to scroll to bottom footer view. Following code doesn't seem to scroll to the most bottom footer view. [tableview beginUpdates]; [tableview insertRowsAtIndexPaths:[NSArray arrayWithObject:[NSIndexPath indexPathForRow:(chatMessages.count - 1) inSection:0]] withRowAnimation:UITableViewRowAnimationLeft]; [tableview endUpdates]; if (tableview.tableFooterView) [tableview scrollRectToVisible:CGRectMake(0, tableview.contentSize.height+64, 320, 44) animated:YES]; Tharindu Madushanka ___ 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
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 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])
{
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. 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
Re: crash on altering NSMutableArray
On May 1, 2010, at 20:42, James Maxwell wrote: 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* This strongly suggests a memory management problem -- something is over-releasing the items in the array. 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. You're fighting this battle on too many fronts. You've got a sketchy grasp of GCD, you're uncertain whether you're actually multithreading or not, and this sort of let-everything-poke-every-object-from-every-direction application design really makes it to determine correctness. Probably you should pick one thing, and comment everything else out, until you're sure that small part is working. Then add the complexity back in slowly, checking correctness at each step. FWIW. ___ 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
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
On Sun, May 2, 2010 at 1:50 AM, James Maxwell jbmaxw...@rubato-music.com 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/archive%40mail-archive.com This email sent to arch...@mail-archive.com
