Re: Cocoa-dev Digest, Vol 9, Issue 38
Re: Cocoa-dev Digest, Vol 9, Issue 36 (lpeng...@gmail.com) 2. NSXMLParser, streams, multiple threads, and crashing (Thomas Davie) 3. Re: Strange renaming of Documents folder (Martin Hewitson) 4. Re: NSXMLParser, streams, multiple threads, and crashing (Andreas Grosam) 5. Re: NSXMLParser, streams, multiple threads, and crashing (Thomas Davie) 6. Re: Cocoa-dev Digest, Vol 9, Issue 37 (lpeng...@gmail.com) 7. Re: Versions, -windowWillClose: (Martin Hewitson) 8. Re: Strange renaming of Documents folder (Martin Hewitson) 9. Re: When in Versions browser (Martin Hewitson) 10. Re: Versions, -windowWillClose: (Dave Fernandes) Jim Lin 在 2012-1-22，23:57，cocoa-dev-requ...@lists.apple.com 写道： > Re: Cocoa-dev Digest, Vol 9, Issue 36 (lpeng...@gmail.com) > 2. NSXMLParser, streams, multiple threads, and crashing > (Thomas Davie) > 3. Re: Strange renaming of Documents folder (Martin Hewitson) > 4. Re: NSXMLParser, streams, multiple threads, and crashing > (Andreas Grosam) > 5. Re: NSXMLParser, streams, multiple threads, and crashing > (Thomas Davie) > 6. Re: Cocoa-dev Digest, Vol 9, Issue 37 (lpeng...@gmail.com) > 7. Re: Versions, -windowWillClose: (Martin Hewitson) > 8. Re: Strange renaming of Documents folder (Martin Hewitson) > 9. Re: When in Versions browser (Martin Hewitson) > 10. Re: Versions, -windowWillClose: (Dave Fernandes) ___ 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: NSOpenPanel problem
On Jan 22, 2012, at 1:24 PM, Jan E. Schotsman wrote: > Suppose I want to display a modeless choose file dialog with the > beginWithCompletionHandler method. > How can I pass some context info to the handler? Blocks capture whatever local variables you reference within them. If you reference instance variables, they capture "self" and then access the ivars from that. Just use whatever value you want, directly. That's the great thing about blocks. Cheers, Ken ___ 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
NSOpenPanel problem
Hello, Suppose I want to display a modeless choose file dialog with the beginWithCompletionHandler method. How can I pass some context info to the handler? The beginForDirectory method has a contextInfo parameter but I want to use the newer method. TIA, Jan E. ___ 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: While running our iPhone app, the screen sometimes goes white and locks up. Any idea why?
On Jan 20, 2012, at 5:54 PM, G S wrote: > This just started happening recently, but then again I've made lots of > changes to our app. It's not very frequent, and so far there's no > discernible pattern. But every once in a while, the entire phone > screen will turn white and there's no way to get rid of it in the app. > There's no status bar, nothing. The app must be killed from the task > bar to restore it. > > Our application deals with (what else) photo sharing, so there's > interaction with the stock photo picker. But again, there's no clear > relationship between the white screen and anything else just yet. > > Has anyone else seen this and have some idea what can cause it? If you're having trouble getting the debugger to work in this state, try this. At the white screen, hold down the power button until "slide to power off appears", then release the power button and hold down the home button until the app disappears. This should generate a crash log with the exception code 0xdeadfa11. The backtraces in that crash log may help show what's going on. -- Greg Parker gpar...@apple.com Runtime Wrangler ___ 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: NSTextView : Scroll top when bound-to string changes
On Jan 20, 2012, at 7:33 AM, Jerry Krinock wrote: > I've bound the 'Attributed String' of an NSTextView. This view a detail > view; its text changes whenever the user changes the selection in an > associated table. Upon changing, the text scrolls to the bottom. I want it > to stay at the top. > > I understand that I can scroll back to the top by sending -scrollPoint:, > -scrollRectToVisible:, or -scrollRangeToVisible:, but where would I do this? > Invoking -performSelector:withObject:afterDelay: at then end of the getter > would probably work, but it seems like such a simple programming requirement > should not require such a kludge. Bindings are supposed to make my life > easier! While your switch away from bindings is fine and I won't discourage it, there's a simple solution to this issue. The insight is that scrolling to the top isn't about a change in the bound key path. It's about the change in selection. For example, if the selection didn't change but the model value that the text view was showing did, would you want it to scroll to the top? What if the text view is editable? Should edits change the scroll position? I would say no. The desired scroll-to-top behavior is not tied to the value changing, it's tied to the selection changing. So, when I've had a similar GUI, I simply invoke one of the -scroll... methods in the -tableViewSelectionDidChange: table view delegate method. Regards, Ken ___ 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: NSXMLParser, streams, multiple threads, and crashing
On 22 Jan 2012, at 18:45, Jens Alfke wrote:
>
> On Jan 22, 2012, at 5:15 AM, Thomas Davie wrote:
>
>> As you can see, none of that is in my code (beyond main), so I have a real
>> problem debugging what's going on here.
>
> Cocoa debugging tip: A crash in objc_msgsend almost always implies a dangling
> reference to a deallocated object. Usually the dead object is being messaged
> directly, or sometimes a still-active instance method has accessed one of its
> instance variables that got overwritten with garbage.
>
> The best response is to go into the scheme editor and turn on zombies and
> scribbling. Zombies will give you much more detailed information if a dead
> object is messaged, and scribbling will immediately overwrite freed memory
> with a 0x55 pattern that’s easily detectable in crashes (if the crash is
> trying to read memory from address 0x, you can be pretty sure why.)
Thanks Jens,
I received the same advice from #iphonedev on freenode earlier today, and
eventually tracked it down to an object being deallocated that was still
pointed at as a delegate.
Cheers for your help :)
if (*ra4 != 0xffc78948) { return false; }
___
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: NSXMLParser, streams, multiple threads, and crashing
On Jan 22, 2012, at 5:15 AM, Thomas Davie wrote: > As you can see, none of that is in my code (beyond main), so I have a real > problem debugging what's going on here. Cocoa debugging tip: A crash in objc_msgsend almost always implies a dangling reference to a deallocated object. Usually the dead object is being messaged directly, or sometimes a still-active instance method has accessed one of its instance variables that got overwritten with garbage. The best response is to go into the scheme editor and turn on zombies and scribbling. Zombies will give you much more detailed information if a dead object is messaged, and scribbling will immediately overwrite freed memory with a 0x55 pattern that’s easily detectable in crashes (if the crash is trying to read memory from address 0x, you can be pretty sure why.) Good luck! —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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSSlider and arrangedObjects
On Jan 21, 2012, at 6:37 PM, Quincey Morris wrote: > On Jan 21, 2012, at 00:54 , Ken Thomases wrote: > >> Table columns do have special handling for array-valued bindings. It's that >> they distribute the array values among their rows. Table columns are not >> special in being able to bind through collection properties. That's a >> feature of NSArrayController. >> >> The table column's bindings still have just an observed object (often the >> array controller) and a single key path (often of the form >> "arrangedObject.propertyName"). It's just that, when they receive an array >> from [observedObject valueForKeyPath:observedKeyPath], they know to pick one >> element from that array for each row. > > I have to speak under potential correction, since I don't have the > implementations to refer to, but I don't believe this analysis. > > Typically, nothing can "bind through collection properties", because > typically a binding involves (along with other things) an observation of the > target object on a key path, and trying to set up such an observation will > throw an exception. Go ahead and try it. Instantiate an array controller and set up key-value observation on a key path which goes through its arrangedObjects property. No exception. > If the "collection property" is not really a collection but a proxy (as > you've described "arrangedObjects" to be), then the exception might be > avoided, but the resulting observation will be useless because there's no KVO > compliance. Specifically, I mean that if the key path is > "arrangedObjects.propertyName", propertyName changes to individual objects > won't propagate to an observer of the key path, at least not unless the > arrangedObjects proxy itself observes every element of the underlying array, > which is too horrendous to contemplate. It's not so horrendous. It's what one is encouraged to do with one's own code if one needs to observe properties of the elements of a collection. You observe the collection property itself to learn when elements are added or removed, and you observe the properties of the individual elements to learn when they change. What do you think the -[NSArray addObserver:toObjectsAtIndexes:forKeyPath:options:context:] method is for? > In fact, it seems to me that logic dictates that table columns bound to > something we normally write as "arrangedObjects.propertyName" do *not* > observe on that key path. Again I don't know, but my assumption has always > been that table columns observe the propertyName attributes of just the > objects for rows that are currently visible. That in itself makes table > columns "special", and their binding's so-called key path not really a key > path. Well, the actual implementation is of course hidden. However, there's nothing preventing it from using KVO on arrangedObjects.propertyName. If it does otherwise, it is just an optimization. > Furthermore, it also seems to me that logic rules against any idea of the > table column implementation *requiring* the construction of the *entire* > array of row objects, because table views are virtual in the sense that they > only reference the objects they need from moment to moment. Anything else > would imply horrendous performance penalties for table views with thousands > or millions of rows, but I don't believe there is any such penalty implicit > in NSTableView itself. It is already necessary to "construct" the entire array of objects to know a) how many objects are in the table, and b) which objects belong to which rows in the face of sorting. And, again, you're now talking about optimizations, not any requirement imposed by what can or can't be key-value observed. > Putting this another way, I find it hard to believe that table columns ever > evaluate '[observedObject valueForKeyPath:observedKeyPath]', because that > would seem to require construction of a potentially huge and costly array. > I've always assumed that, assuming a so-called key path of the form > "someArray.someProperty", table columns only ever evaluate '[[someArray > objectAtIndex: rowIndex] valueForKey: someProperty]' for specific values of > 'rowIndex', never '[[someArray valueForKey: someProperty] objectAtIndex: > rowIndex]'. Again, you're guessing at optimizations. > Finally, we already know, from discussions on this list in the past, that > (given the same key path) there *is* a semantic difference between table > column bindings and other bindings to arrays, such as those supplying arrays > of menu item titles to NSPopUpMenu. In that case, > "arrangedObjects.propertyName" fails to be useful because it indeed behaves > like a typical key path in a typical binding, rather than having the special > binding behavior of table columns. The difference with pop-up menus is just whether or not the view understands a key path which returns an array. I agreed in my earlier email that table columns are "smart"
Re: Versions, -windowWillClose:
On 22, Jan, 2012, at 04:56 PM, Dave Fernandes wrote:
> You can set a breakpoint in the normal document opening methods such as
> -[NSDocument initWithContentsOfURL:ofType:error:] to see what URL the
> versioned documents are being loaded from.
Somebody else told me the documents are stored in /.DocumentRevisions-V100.
So I was able to confirm that the transient properties are not stored in the
document versions, so my observation about the file contents being different in
the versions browser must have been incorrect. In fact, I have been unable to
reliably reproduce this. So I'm back to where I was, namely that the Versions
model doesn't fit well to an Xcode like architecture where the document only
manages the contents of other files on disk.
Thanks,
Martin
>
> On 2012-01-22, at 10:06 AM, Martin Hewitson wrote:
>
>>
>> On 21, Jan, 2012, at 07:31 PM, Mike Abdullah wrote:
>>
>>>
>>> On 3 Jan 2012, at 15:25, Martin Hewitson wrote:
>>>
Dear list,
I'm investigating getting the new 10.7 Versions stuff working on my
NSPersistentDocument app. In doing that, I've seen a couple of strange
things which I wanted to check on.
Firstly, all I've done to make it work is to return YES from
+autosavesInPlace.
Now, what I notice is the following sequence of events:
1) App starts:
windowControllerDidLoadNib
2) Enter Versions browser
NSDocumentRevisionsDebugMode=YES
: kCGErrorFailure: CGSDisplayID: App trying to enumerate [0 to
CGSGetNumberOfDisplays()] instead of using CGSGetDisplayList().
Compensating...
: kCGErrorFailure: Set a breakpoint @ CGErrorBreakpoint() to
catch errors as they are logged.
windowControllerDidLoadNib
Entered Versions: NSConcreteNotification 0x108658620 {name =
NSWindowDidEnterVersionBrowserNotification; object = >>> 0x10055d970>}
3) Exit Versions (by clicking Done button in Versions browser)
Window will close /
Open windows 1 (logged in windowWillClose:)
Exited Versions: NSConcreteNotification 0x1091a22c0 {name =
NSWindowDidExitVersionBrowserNotification; object = >>> 0x10055d970>}
4) Exit App
Window will close /
Open windows 1 (logged in windowWillClose:)
Some questions:
a) Why is it that I don't have 2 open windows in step 3)?
b) What is the first window doing while the Versions browser is open? It
seems the same document is opened again, judging by the NSWindow objects.
c) What are the Errors reported just after entering Versions?
>>>
>>> The CG errors happen in all apps; seems to be a side-effect of however
>>> Apple have implemented Versions.
>>
>> OK, good to know.
>>
Perhaps I'm not understanding how this stuff works yet, so any
enlightenment would be gratefully received.
As a side question, where are the different versions of the document kept?
I've read that they are kept in the document, but inspection of the
(XML-based) Core Data document shows that's not the case. The app is
actually a manager of other (text) files on disk, and I'm amazed to see
that the versions actually reflect the state of the managed text files,
even though the save core data document does not store the file contents.
The file contents are stored temporarily in a core data entity as a
transient property. Can I then conclude that these transient properties
are stored in the different versions? I've tried reading through the
documentation on this, and I've watched the WWDC11 session on this, but
perhaps I need to do that again.
>>>
>>> It's entirely private to the OS where and how it chooses to store the
>>> historical versions of your documents.
>>>
>>
>>
>> True, but it would be very useful in the debugging/understanding process to
>> be able to inspect the contents of the previous versions. Of course, if we
>> had decent documentation on this, that might not be necessary. Alas
>>
>> Martin
>>
>>
>> Martin Hewitson
>> Albert-Einstein-Institut
>> Max-Planck-Institut fuer
>> Gravitationsphysik und Universitaet Hannover
>> Callinstr. 38, 30167 Hannover, Germany
>> Tel: +49-511-762-17121, Fax: +49-511-762-5861
>> E-Mail: martin.hewit...@aei.mpg.de
>> WWW: http://www.aei.mpg.de/~hewitson
>>
>>
>>
>>
>>
>>
>>
>> ___
>>
>> 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/dave.fernandes%40utoronto.ca
>>
>> This email sent to dave.fernan...@utoronto.ca
>
Re: Versions, -windowWillClose:
You can set a breakpoint in the normal document opening methods such as
-[NSDocument initWithContentsOfURL:ofType:error:] to see what URL the versioned
documents are being loaded from.
On 2012-01-22, at 10:06 AM, Martin Hewitson wrote:
>
> On 21, Jan, 2012, at 07:31 PM, Mike Abdullah wrote:
>
>>
>> On 3 Jan 2012, at 15:25, Martin Hewitson wrote:
>>
>>> Dear list,
>>>
>>> I'm investigating getting the new 10.7 Versions stuff working on my
>>> NSPersistentDocument app. In doing that, I've seen a couple of strange
>>> things which I wanted to check on.
>>>
>>> Firstly, all I've done to make it work is to return YES from
>>> +autosavesInPlace.
>>>
>>> Now, what I notice is the following sequence of events:
>>>
>>>
>>> 1) App starts:
>>> windowControllerDidLoadNib
>>> 2) Enter Versions browser
>>> NSDocumentRevisionsDebugMode=YES
>>> : kCGErrorFailure: CGSDisplayID: App trying to enumerate [0 to
>>> CGSGetNumberOfDisplays()] instead of using CGSGetDisplayList().
>>> Compensating...
>>> : kCGErrorFailure: Set a breakpoint @ CGErrorBreakpoint() to
>>> catch errors as they are logged.
>>> windowControllerDidLoadNib
>>> Entered Versions: NSConcreteNotification 0x108658620 {name =
>>> NSWindowDidEnterVersionBrowserNotification; object = >> 0x10055d970>}
>>> 3) Exit Versions (by clicking Done button in Versions browser)
>>> Window will close /
>>> Open windows 1 (logged in windowWillClose:)
>>> Exited Versions: NSConcreteNotification 0x1091a22c0 {name =
>>> NSWindowDidExitVersionBrowserNotification; object = }
>>> 4) Exit App
>>> Window will close /
>>> Open windows 1 (logged in windowWillClose:)
>>>
>>> Some questions:
>>>
>>> a) Why is it that I don't have 2 open windows in step 3)?
>>> b) What is the first window doing while the Versions browser is open? It
>>> seems the same document is opened again, judging by the NSWindow objects.
>>> c) What are the Errors reported just after entering Versions?
>>
>> The CG errors happen in all apps; seems to be a side-effect of however Apple
>> have implemented Versions.
>
> OK, good to know.
>
>>>
>>> Perhaps I'm not understanding how this stuff works yet, so any
>>> enlightenment would be gratefully received.
>>>
>>> As a side question, where are the different versions of the document kept?
>>> I've read that they are kept in the document, but inspection of the
>>> (XML-based) Core Data document shows that's not the case. The app is
>>> actually a manager of other (text) files on disk, and I'm amazed to see
>>> that the versions actually reflect the state of the managed text files,
>>> even though the save core data document does not store the file contents.
>>> The file contents are stored temporarily in a core data entity as a
>>> transient property. Can I then conclude that these transient properties are
>>> stored in the different versions? I've tried reading through the
>>> documentation on this, and I've watched the WWDC11 session on this, but
>>> perhaps I need to do that again.
>>
>> It's entirely private to the OS where and how it chooses to store the
>> historical versions of your documents.
>>
>
>
> True, but it would be very useful in the debugging/understanding process to
> be able to inspect the contents of the previous versions. Of course, if we
> had decent documentation on this, that might not be necessary. Alas
>
> Martin
>
>
> Martin Hewitson
> Albert-Einstein-Institut
> Max-Planck-Institut fuer
>Gravitationsphysik und Universitaet Hannover
> Callinstr. 38, 30167 Hannover, Germany
> Tel: +49-511-762-17121, Fax: +49-511-762-5861
> E-Mail: martin.hewit...@aei.mpg.de
> WWW: http://www.aei.mpg.de/~hewitson
>
>
>
>
>
>
>
> ___
>
> 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/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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: When in Versions browser
On 21, Jan, 2012, at 02:43 PM, Mike Abdullah wrote: > > On 21 Jan 2012, at 09:33, Martin Hewitson wrote: > >> Dear list, >> >> I'm trying to get Versions and autosave working on my document app. Most >> things are working. I'm using the window delegate methods >> >> - (void)windowWillEnterVersionBrowser:(NSNotification *)notification; >> - (void)windowDidExitVersionBrowser:(NSNotification *)notification; >> >> to enable and disable some UI elements. I'm also setting a private ivar >> boolean _inVersionsBrowser to YES in >> >> - (void)windowDidEnterVersionBrowser:(NSNotification *)notification >> >> and to NO in >> >> - (void)windowDidExitVersionBrowser:(NSNotification *)notification >> >> Then in methods like -validateToolbarItem: I'm checking for this flag and >> returning NO if it's set to YES. This works for the current document window >> (all its toolbar items are disabled in the Versions browser) but not for the >> previous versions document windows. So, I need a more dynamic way to check >> if I'm in the Versions browser so that I can disable such things. Is there >> API to do that? I couldn't find it (obviously). Or is there a better way to >> do what I'm trying to do? > > -[NSDocument isInViewingMode] Thanks! Missed that one. Martin > Martin Hewitson Albert-Einstein-Institut Max-Planck-Institut fuer Gravitationsphysik und Universitaet Hannover Callinstr. 38, 30167 Hannover, Germany Tel: +49-511-762-17121, Fax: +49-511-762-5861 E-Mail: martin.hewit...@aei.mpg.de WWW: http://www.aei.mpg.de/~hewitson ___ 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: Strange renaming of Documents folder
On 22, Jan, 2012, at 01:09 AM, Ken Thomases wrote: > On Jan 21, 2012, at 7:32 AM, Martin Hewitson wrote: > >> I have a user that has been using a document based app of mine and they are >> reporting something very strange. >> >> The user is Spanish and so had a "Documentos" folder in his home directory. >> He created a new document in this app then went to save it. In the "Where" >> part of the save dialog it said "Documents". He went ahead and tried to save >> the document to this "Documents" folder. He says the result is that his >> "Documentos" folder has disappeared and there is now a "Documents" folder. >> All the files that were in "Documentos" have now disappeared. I use nothing >> special in the app. It's a very standard NSDocument app which uses and >> override of -writeToURL:ofType:error: to save the contents of a textview to >> disk. The save dialog is the standard one presented by the document >> architecture; I don't modify it. >> >> Does anyone have a clue what could have happened? > > Mac OS X doesn't localize the names of folders on disk. It only localizes > them in the standard GUI (e.g. Finder and Open and Save dialogs) and via > display name APIs such as -[NSFileManager displayNameAtPath:]. > > So, the Documents folder is always named "Documents" on disk, even for a > Spanish user. > > An important component of the localization mechanism for standard folders is > that there's an empty, hidden file named ".localized" inside of the Documents > folder. Without that special file, the display name APIs and the standard > GUI won't display the localized name. > > If every file within ~/Documents were deleted, including .localized, then > that folder's name would cease to be localized. > > Since the Save dialog was showing the folder name as "Documents" instead of > "Documentos", then I would guess that all of the files had been deleted > before the user went to save the file in your app. I can't guess what would > have deleted those files, but the evidence suggests it wasn't your app -- or, > at least, it wasn't the save process. Ken, thanks for the useful information. I'll pass some of this on to the user in case it sheds some light on the matter. In any case, I've not been able to reproduce this using a test account. Best wishes, Martin > > Regards, > Ken > Martin Hewitson Albert-Einstein-Institut Max-Planck-Institut fuer Gravitationsphysik und Universitaet Hannover Callinstr. 38, 30167 Hannover, Germany Tel: +49-511-762-17121, Fax: +49-511-762-5861 E-Mail: martin.hewit...@aei.mpg.de WWW: http://www.aei.mpg.de/~hewitson ___ 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: Versions, -windowWillClose:
On 21, Jan, 2012, at 07:31 PM, Mike Abdullah wrote:
>
> On 3 Jan 2012, at 15:25, Martin Hewitson wrote:
>
>> Dear list,
>>
>> I'm investigating getting the new 10.7 Versions stuff working on my
>> NSPersistentDocument app. In doing that, I've seen a couple of strange
>> things which I wanted to check on.
>>
>> Firstly, all I've done to make it work is to return YES from
>> +autosavesInPlace.
>>
>> Now, what I notice is the following sequence of events:
>>
>>
>> 1) App starts:
>> windowControllerDidLoadNib
>> 2) Enter Versions browser
>> NSDocumentRevisionsDebugMode=YES
>> : kCGErrorFailure: CGSDisplayID: App trying to enumerate [0 to
>> CGSGetNumberOfDisplays()] instead of using CGSGetDisplayList().
>> Compensating...
>> : kCGErrorFailure: Set a breakpoint @ CGErrorBreakpoint() to
>> catch errors as they are logged.
>> windowControllerDidLoadNib
>> Entered Versions: NSConcreteNotification 0x108658620 {name =
>> NSWindowDidEnterVersionBrowserNotification; object = }
>> 3) Exit Versions (by clicking Done button in Versions browser)
>> Window will close /
>> Open windows 1 (logged in windowWillClose:)
>> Exited Versions: NSConcreteNotification 0x1091a22c0 {name =
>> NSWindowDidExitVersionBrowserNotification; object = }
>> 4) Exit App
>> Window will close /
>> Open windows 1 (logged in windowWillClose:)
>>
>> Some questions:
>>
>> a) Why is it that I don't have 2 open windows in step 3)?
>> b) What is the first window doing while the Versions browser is open? It
>> seems the same document is opened again, judging by the NSWindow objects.
>> c) What are the Errors reported just after entering Versions?
>
> The CG errors happen in all apps; seems to be a side-effect of however Apple
> have implemented Versions.
OK, good to know.
>>
>> Perhaps I'm not understanding how this stuff works yet, so any enlightenment
>> would be gratefully received.
>>
>> As a side question, where are the different versions of the document kept?
>> I've read that they are kept in the document, but inspection of the
>> (XML-based) Core Data document shows that's not the case. The app is
>> actually a manager of other (text) files on disk, and I'm amazed to see that
>> the versions actually reflect the state of the managed text files, even
>> though the save core data document does not store the file contents. The
>> file contents are stored temporarily in a core data entity as a transient
>> property. Can I then conclude that these transient properties are stored in
>> the different versions? I've tried reading through the documentation on
>> this, and I've watched the WWDC11 session on this, but perhaps I need to do
>> that again.
>
> It's entirely private to the OS where and how it chooses to store the
> historical versions of your documents.
>
True, but it would be very useful in the debugging/understanding process to be
able to inspect the contents of the previous versions. Of course, if we had
decent documentation on this, that might not be necessary. Alas
Martin
Martin Hewitson
Albert-Einstein-Institut
Max-Planck-Institut fuer
Gravitationsphysik und Universitaet Hannover
Callinstr. 38, 30167 Hannover, Germany
Tel: +49-511-762-17121, Fax: +49-511-762-5861
E-Mail: martin.hewit...@aei.mpg.de
WWW: http://www.aei.mpg.de/~hewitson
___
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: Cocoa-dev Digest, Vol 9, Issue 37
Re: auto malloc[27012]: attempted to remove unregistered weak referrer (Sean McBride) 2. Re: Strange renaming of Documents folder (Ken Thomases) 3. Re: Strange renaming of Documents folder (John Joyce) 4. Re: NSSlider and arrangedObjects (Quincey Morris) 5. Re: Strange renaming of Documents folder (Ken Thomases) Jim Lin 在 2012-1-22，10:41，cocoa-dev-requ...@lists.apple.com 写道： > Re: auto malloc[27012]: attempted to remove unregistered weak > referrer (Sean McBride) > 2. Re: Strange renaming of Documents folder (Ken Thomases) > 3. Re: Strange renaming of Documents folder (John Joyce) > 4. Re: NSSlider and arrangedObjects (Quincey Morris) > 5. Re: Strange renaming of Documents folder (Ken Thomases) ___ 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: NSXMLParser, streams, multiple threads, and crashing
Thanks Andreas,
I am indeed using ARC, so the code should be safe enough, as ARC will retain
rec for me.
Cheers for taking a look though
Tom Davie
if (*ra4 != 0xffc78948) { return false; }
On 22 Jan 2012, at 13:35, Andreas Grosam wrote:
>
> On Jan 22, 2012, at 2:15 PM, Thomas Davie wrote:
>> OSPConnection *rec = [[self connectionQueue] objectAtIndex:0];
>> [[self connectionQueue] removeObjectAtIndex:0];
>> [[self currentConnections] addObject:rec];
>
>
> Not sure if this is related to your issue, but basically, the lines above are
> potentially dangerous. You should mention which memory management model you
> are using: GC, ARC or manual.
>
>
> Writing it the way below should be safe in all cases and doesn't hurt at all
> otherwise:
>
> OSPConnection *rec = [[self connectionQueue] objectAtIndex:0];
> [[self currentConnections] addObject:rec];
> [[self connectionQueue] removeObjectAtIndex:0];
>
>
>
> Andreas
> ___
>
> 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/tom.davie%40gmail.com
>
> This email sent to tom.da...@gmail.com
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: NSXMLParser, streams, multiple threads, and crashing
On Jan 22, 2012, at 2:15 PM, Thomas Davie wrote: >OSPConnection *rec = [[self connectionQueue] objectAtIndex:0]; >[[self connectionQueue] removeObjectAtIndex:0]; >[[self currentConnections] addObject:rec]; Not sure if this is related to your issue, but basically, the lines above are potentially dangerous. You should mention which memory management model you are using: GC, ARC or manual. Writing it the way below should be safe in all cases and doesn't hurt at all otherwise: OSPConnection *rec = [[self connectionQueue] objectAtIndex:0]; [[self currentConnections] addObject:rec]; [[self connectionQueue] removeObjectAtIndex:0]; Andreas ___ 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: Strange renaming of Documents folder
On 22, Jan, 2012, at 01:17 AM, John Joyce wrote: > > On Jan 21, 2012, at 6:09 PM, Ken Thomases wrote: > >> On Jan 21, 2012, at 7:32 AM, Martin Hewitson wrote: >> >>> I have a user that has been using a document based app of mine and they are >>> reporting something very strange. >>> >>> The user is Spanish and so had a "Documentos" folder in his home directory. >>> He created a new document in this app then went to save it. In the "Where" >>> part of the save dialog it said "Documents". He went ahead and tried to >>> save the document to this "Documents" folder. He says the result is that >>> his "Documentos" folder has disappeared and there is now a "Documents" >>> folder. All the files that were in "Documentos" have now disappeared. I use >>> nothing special in the app. It's a very standard NSDocument app which uses >>> and override of -writeToURL:ofType:error: to save the contents of a >>> textview to disk. The save dialog is the standard one presented by the >>> document architecture; I don't modify it. >>> >>> Does anyone have a clue what could have happened? >> >> Mac OS X doesn't localize the names of folders on disk. It only localizes >> them in the standard GUI (e.g. Finder and Open and Save dialogs) and via >> display name APIs such as -[NSFileManager displayNameAtPath:]. >> >> So, the Documents folder is always named "Documents" on disk, even for a >> Spanish user. >> >> An important component of the localization mechanism for standard folders is >> that there's an empty, hidden file named ".localized" inside of the >> Documents folder. Without that special file, the display name APIs and the >> standard GUI won't display the localized name. >> >> If every file within ~/Documents were deleted, including .localized, then >> that folder's name would cease to be localized. >> >> Since the Save dialog was showing the folder name as "Documents" instead of >> "Documentos", then I would guess that all of the files had been deleted >> before the user went to save the file in your app. I can't guess what would >> have deleted those files, but the evidence suggests it wasn't your app -- >> or, at least, it wasn't the save process. >> >> Regards, >> Ken >> > Hi Martin, > > To best verify this yourself, create a new user account on a Mac, set Spanish > to the top of the list of preferred languages in System Preferences > Text & > Language > Log out, log back in to that user to ensure that all apps and processes in > that user account are in Spanish. > Check the contents of the ~/Documents folder in terminal using ls > run your app to recreate the situation. > You'll find out really fast if your app is doing something nasty. > OK, good tip. I tried this but there was no way that I could convince the "Save As" dialog to point to a folder called "Documents" it only showed me "Documentos" and saving there caused no problems. The user stated that they had "Documents" in the "Where:" field of the "Save As" dialog. I've no idea how they managed to have that. Any ideas? Thanks for the input, Martin > HTH > John Martin Hewitson Albert-Einstein-Institut Max-Planck-Institut fuer Gravitationsphysik und Universitaet Hannover Callinstr. 38, 30167 Hannover, Germany Tel: +49-511-762-17121, Fax: +49-511-762-5861 E-Mail: martin.hewit...@aei.mpg.de WWW: http://www.aei.mpg.de/~hewitson ___ 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
NSXMLParser, streams, multiple threads, and crashing
Hi all,
I'm having a bit of a bizarre issue with a pair of NSXMLParsers reading out of
streams, where my main thread crashes while signalling a stream.
Every crash occurs in the main thread, with this back trace:
> #00x0175d0b0 in objc_msgSend ()
> #10x0133fb4d in _outputStreamCallbackFunc ()
> #20x0130f06d in _signalEventSync ()
> #30x0130efe6 in _cfstream_shared_signalEventSync ()
> #40x0134297f in
> __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ ()
> #50x012a5c39 in __CFRunLoopDoSources0 ()
> #60x012a5454 in __CFRunLoopRun ()
> #70x012a4db4 in CFRunLoopRunSpecific ()
> #80x012a4ccb in CFRunLoopRunInMode ()
> #90x01832879 in GSEventRunModal ()
> #10 0x0183293e in GSEventRun ()
> #11 0x003b4a9b in UIApplicationMain ()
> #12 0x2cd8 in main at
> /Users/tatd2/Documents/Personal/OpenStreetPad/OpenStreetPad/main.m:17
As you can see, none of that is in my code (beyond main), so I have a real
problem debugging what's going on here. What I have noticed is that every time
this crash occurs, another thread is currently reading from a stream with this
back trace:
> #00x92a08c22 in mach_msg_trap ()
> #10x92a081f6 in mach_msg ()
> #20x0134213a in __CFRunLoopServiceMachPort ()
> #30x012a5605 in __CFRunLoopRun ()
> #40x012a4db4 in CFRunLoopRunSpecific ()
> #50x012a4ccb in CFRunLoopRunInMode ()
> #60x01349609 in boundPairRead ()
> #70x012ab744 in CFReadStreamRead ()
> #80x0133f69f in -[__NSCFInputStream read:maxLength:] ()
> #90x00d82da6 in -[NSXMLParser parseFromStream] ()
> #10 0x00d82e2a in -[NSXMLParser parse] ()
> #11 0xea99 in __34-[OSPMapServer popConnectionQueue]_block_invoke_0 ()
> #12 0x01e43445 in _dispatch_call_block_and_release ()
> #13 0x01e44c7b in _dispatch_async_f_redirect_invoke ()
> #14 0x01e444e6 in _dispatch_worker_thread2 ()
> #15 0x98a83b24 in _pthread_wqthread ()
> #16 0x98a856fe in start_wqthread ()
As you can see, up to OSPMapServerMaxSimultaneousConnections operations are
dispatched at once to parse the output of an NSURLConnection, notably, if that
constant is set to 1, the crash no longer occurs.
> - (void)popConnectionQueue
> {
> @synchronized(self)
> {
> while ([[self currentConnections] count] <
> OSPMapServerMaxSimultaneousConnections && [[self connectionQueue] count] > 0)
> {
> OSPConnection *rec = [[self connectionQueue] objectAtIndex:0];
> [[self connectionQueue] removeObjectAtIndex:0];
> [[self currentConnections] addObject:rec];
> [rec setConnection:[NSURLConnection connectionWithRequest:[rec
> request] delegate:rec]];
> [[rec connection] start];
> CFReadStreamRef readStream;
> CFWriteStreamRef writeStream;
> CFStreamCreateBoundPair(NULL, &readStream, &writeStream, 4096);
> NSInputStream *iStream = CFBridgingRelease(readStream);
> NSOutputStream *oStream = CFBridgingRelease(writeStream);
> [oStream setDelegate:rec];
> NSRunLoop *runLoop = [NSRunLoop currentRunLoop];
> [iStream scheduleInRunLoop:runLoop forMode:NSDefaultRunLoopMode];
> [oStream scheduleInRunLoop:runLoop forMode:NSDefaultRunLoopMode];
> [iStream open];
> [oStream open];
> [rec setParserStream:oStream];
> NSXMLParser *parser = [[NSXMLParser alloc]
> initWithStream:iStream];
> [parser setDelegate:rec];
> [rec setParser:parser];
> dispatch_async(parserQueue, ^()
>{
>[parser parse];
>});
> }
> }
> }
I'm currently stuck even for ways to approach debugging this problem, if anyone
has any ideas how I could tackle this, I'd really apreciate it.
If you'd like to take a look at the full source and/or experience the crash for
yourself, the full source is at github.com/beelsebob/OpenStreetPad
Thanks all
Tom Davie
if (*ra4 != 0xffc78948) { return false; }
___
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: Cocoa-dev Digest, Vol 9, Issue 36
Re: Cocoa-dev Digest, Vol 9, Issue 33 (lpeng...@gmail.com) 8. Re: Cocoa-dev Digest, Vol 9, Issue 33 (lpeng...@gmail.com) 9. Re: Cocoa-dev Digest, Vol 9, Issue 34 (lpeng...@gmail.com) 10. Re: Cocoa-dev Digest, Vol 9, Issue 32 (lpeng...@gmail.com) Jim Lin 在 2012-1-22，2:31，cocoa-dev-requ...@lists.apple.com 写道： > Re: Cocoa-dev Digest, Vol 9, Issue 33 (lpeng...@gmail.com) > 8. Re: Cocoa-dev Digest, Vol 9, Issue 33 (lpeng...@gmail.com) > 9. Re: Cocoa-dev Digest, Vol 9, Issue 34 (lpeng...@gmail.com) > 10. Re: Cocoa-dev Digest, Vol 9, Issue 32 (lpeng...@gmail.com) ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
