Re: preventing bad memory access

2011-10-20 Thread Don Quixote de la Mancha 
On Tue, Oct 18, 2011 at 9:22 AM, Jens Alfke  wrote:
> On Oct 17, 2011, at 9:26 PM, Wilker wrote:
> if the user is acessing a
>> file from an external drive, and the file has 8gb, I only wanna read 64kb,
>> so, I don't wanna read it all just for 64kb.
>
> Just use fopen/fseek/fread/fclose. Mapping in the entire file just so you can 
> read 64kb is overkill.

Specifically, if you fseek to the beginning of where you want to read,
then fread what you want, the only part that will get cached is what
you read.  It will be faster than not caching.

mapping the file then reading from memory also caches parts of the
file, but only what you read.

If you're going to read your file in large chunks then it will be
faster to use the open(), lseek(), read() and close() system calls.
The "f" calls from stdio use an in-process cache which is faster for
small accesses but slower for large ones.


-- 
Don Quixote de la Mancha
Dulcinea Technologies Corporation
Software of Elegance and Beauty
http://www.dulcineatech.com
quix...@dulcineatech.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: Enter/exit full screen notification

2011-10-20 Thread lowell 
Yup. Here are two different ways:

/System/Library/Frameworks/AppKit.framework/Versions/C/Headers/NSWindow.h @757:
- (void)windowWillEnterFullScreen:(NSNotification *)notification   
NS_AVAILABLE_MAC(10_7);
- (void)windowDidEnterFullScreen:(NSNotification *)notification   
NS_AVAILABLE_MAC(10_7);
- (void)windowWillExitFullScreen:(NSNotification *)notification   
NS_AVAILABLE_MAC(10_7);
- (void)windowDidExitFullScreen:(NSNotification *)notification   
NS_AVAILABLE_MAC(10_7);

/System/Library/Frameworks/AppKit.framework/Versions/C/Headers/NSWindow.h @791:
APPKIT_EXTERN NSString * const NSWindowWillEnterFullScreenNotification 
NS_AVAILABLE_MAC(10_7);
APPKIT_EXTERN NSString * const NSWindowDidEnterFullScreenNotification 
NS_AVAILABLE_MAC(10_7);
APPKIT_EXTERN NSString * const NSWindowWillExitFullScreenNotification 
NS_AVAILABLE_MAC(10_7);
APPKIT_EXTERN NSString * const NSWindowDidExitFullScreenNotification 
NS_AVAILABLE_MAC(10_7);

--lowell

On Oct 19, 2011, at 10:01 PM, Ryan Joseph wrote:

> Is there an effective way to be notified when the system goes into full 
> screen mode (on 10.6 and 10.7)? The only information I found on Google was 
> from 2005 and earlier including Carbon event handlers which are deprecated 
> now.
> 
> I ask because I have a user agent app (which floats above all windows) that 
> needs to be hidden when any app goes into full screen, otherwise my window 
> will cover the full screen app.
> 
> Thanks for any ideas.
> 
> Regards,
>   Ryan Joseph
>   thealchemistguild.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/lowellv%40me.com
> 
> This email sent to lowe...@me.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: Enter/exit full screen notification

2011-10-20 Thread Ryan Joseph 
Thanks. those are what I was looking for, but unfortunately this is in only in 
10.7. What were people using prior to 10.7?

Does anyone know anything about kEventMenuBarShown and if this is the correct 
Carbon event to handle pre-10.7? The information I found is from 2005 so I 
don't know if this is supported anymore and Apple has totally deprecated the 
Carbon Event Manager, even though it seems there is still crucial functionality 
they haven't made Cocoa equivalents of.

On Oct 20, 2011, at 2:22 PM, lowell wrote:

> Yup. Here are two different ways:
> 
> /System/Library/Frameworks/AppKit.framework/Versions/C/Headers/NSWindow.h 
> @757:
> - (void)windowWillEnterFullScreen:(NSNotification *)notification   
> NS_AVAILABLE_MAC(10_7);
> - (void)windowDidEnterFullScreen:(NSNotification *)notification   
> NS_AVAILABLE_MAC(10_7);
> - (void)windowWillExitFullScreen:(NSNotification *)notification   
> NS_AVAILABLE_MAC(10_7);
> - (void)windowDidExitFullScreen:(NSNotification *)notification   
> NS_AVAILABLE_MAC(10_7);
> 
> /System/Library/Frameworks/AppKit.framework/Versions/C/Headers/NSWindow.h 
> @791:
> APPKIT_EXTERN NSString * const NSWindowWillEnterFullScreenNotification 
> NS_AVAILABLE_MAC(10_7);
> APPKIT_EXTERN NSString * const NSWindowDidEnterFullScreenNotification 
> NS_AVAILABLE_MAC(10_7);
> APPKIT_EXTERN NSString * const NSWindowWillExitFullScreenNotification 
> NS_AVAILABLE_MAC(10_7);
> APPKIT_EXTERN NSString * const NSWindowDidExitFullScreenNotification 
> NS_AVAILABLE_MAC(10_7);

Regards,
Ryan Joseph
thealchemistguild.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: Enter/exit full screen notification

2011-10-20 Thread Lee Ann Rucker 
You're trying to see changes made by other apps, right? I don't think you're 
going to see these notifications, then, and also Lion's fullscreen moves the 
window into its own special Mission Control Space, so I'd think your window 
would be left behind on the original Space.

In 10.6 (and 10.7) it's NSApplication presentationOptions. I've never tried to 
detect another app's changes to them, though.

- Original Message -
From: "Ryan Joseph" 
To: cocoa-dev@lists.apple.com
Sent: Thursday, October 20, 2011 12:34:02 AM
Subject: Re: Enter/exit full screen notification

Thanks. those are what I was looking for, but unfortunately this is in only in 
10.7. What were people using prior to 10.7?

Does anyone know anything about kEventMenuBarShown and if this is the correct 
Carbon event to handle pre-10.7? The information I found is from 2005 so I 
don't know if this is supported anymore and Apple has totally deprecated the 
Carbon Event Manager, even though it seems there is still crucial functionality 
they haven't made Cocoa equivalents of.

On Oct 20, 2011, at 2:22 PM, lowell wrote:

> Yup. Here are two different ways:
> 
> /System/Library/Frameworks/AppKit.framework/Versions/C/Headers/NSWindow.h 
> @757:
> - (void)windowWillEnterFullScreen:(NSNotification *)notification   
> NS_AVAILABLE_MAC(10_7);
> - (void)windowDidEnterFullScreen:(NSNotification *)notification   
> NS_AVAILABLE_MAC(10_7);
> - (void)windowWillExitFullScreen:(NSNotification *)notification   
> NS_AVAILABLE_MAC(10_7);
> - (void)windowDidExitFullScreen:(NSNotification *)notification   
> NS_AVAILABLE_MAC(10_7);
> 
> /System/Library/Frameworks/AppKit.framework/Versions/C/Headers/NSWindow.h 
> @791:
> APPKIT_EXTERN NSString * const NSWindowWillEnterFullScreenNotification 
> NS_AVAILABLE_MAC(10_7);
> APPKIT_EXTERN NSString * const NSWindowDidEnterFullScreenNotification 
> NS_AVAILABLE_MAC(10_7);
> APPKIT_EXTERN NSString * const NSWindowWillExitFullScreenNotification 
> NS_AVAILABLE_MAC(10_7);
> APPKIT_EXTERN NSString * const NSWindowDidExitFullScreenNotification 
> NS_AVAILABLE_MAC(10_7);

Regards,
Ryan Joseph
thealchemistguild.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/lrucker%40vmware.com

This email sent to lruc...@vmware.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: Enter/exit full screen notification

2011-10-20 Thread Ryan Joseph 

On Oct 20, 2011, at 2:45 PM, Lee Ann Rucker wrote:

> You're trying to see changes made by other apps, right? I don't think you're 
> going to see these notifications, then, and also Lion's fullscreen moves the 
> window into its own special Mission Control Space, so I'd think your window 
> would be left behind on the original Space.

In that case maybe it's not necessary to do anything in 10.7 (at least for apps 
that implement the new full screen mode). I haven't even tested on 10.7 yet 
which I'll do soon.

> 
> In 10.6 (and 10.7) it's NSApplication presentationOptions. I've never tried 
> to detect another app's changes to them, though.


I did actually read about this. I'm new to Cocoa so I wasn't sure if I was 
doing it right but the NSApplication docs suggest I can observe the value of 
currentSystemPresentationOptions. My tests didn't get the method invoked I set 
to observe but I like I said this could be because the app I was testing 
(QuickTime Player) didn't enter full screen via NSApplication's 
presentationOptions. I posted what the docs say at the end. But how to do I 
know if the app in full screen mode actually uses this API? It doesn't seem 
reliable even if I did figure out the KVO system in Cocoa correctly.

One other idea is getting a notification if the menu bar was hidden since this 
usually means an app went into full screen mode but I can't find that 
notification either.

---

These are the presentation options that have been put into effect by the 
currently active application.

This method is key-value observable.

A client that observes currentSystemPresentationOptions will receive 
notifications when

• The client is the active application, and makes a change itself using 
either setPresentationOptions: or SetSystemUIMode.
• Another application is active, and makes presentation changes of its 
own.
• Another application becomes active and causes the active set of 
presentation options to change.
Key-value observing notifications are not sent when one of the above conditions 
occur, but has the same set of presentation options as the previously active 
application.




Regards,
Ryan Joseph
thealchemistguild.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

Get my NSDocument-based application out from "Open With" menu?

2011-10-20 Thread Nick 
Hello
I have an application that is able to process .txt files, which can be
opened using File->Open and saved with File->Save, File->Save As.
The problem is that Finder thinks that my application is an app that the
user may want to open by double clicking a text file. How does it do it? And
how could I prevent OS X from adding my application to the list "Open With"
of the context menu of txt files?
Thank you
___

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: IBOutlet getter/setter pattern question

2011-10-20 Thread Matt Neuburg 
On Tue, 18 Oct 2011 11:00:49 -0700, Eeyore  said:
>When I declare something as an IBOutlet, am I exposing it to others?

IBOutlet is not a "declaration" in any meaningful sense. It's just a bit of 
internal fluff with Xcode; the compiler never sees it. It makes no difference 
whatever to the status of your ivars / properties.

Since ivars are private, they are not "exposed to others" in any case. In iOS 5 
you can even put the ivar declarations in the @implementation section to keep 
them out of the header file (assuming you're not synthesizing them, in which 
case there are no ivar declarations) - this, however, is a purely stylistic 
matter, having nothing to do with what is *actually* exposed (i.e. it doesn't 
alter their privacy status).

Properties are public if they're declared in the header, but they can be 
declared in the implementation file instead (using e.g. a class extension 
block), thus making them private as well, in the sense that any other class 
trying to use these properties will be warned by the compiler.

It seems to me, then, that the only problem you're really having is related not 
to exposure but to the time-sequence. You know you're going to use the ivar to 
set some features of nib-loaded instances *once*, during viewDidLoad, and never 
again. You're feeling like having a pointer to these instances after that 
moment makes no sense, since you're never going to use it for anything. But:

(1) These can be assign (weak) properties, because the instances are retained 
by the view hierarchy. Thus these ivars are mere pointers. There really is no 
overhead involved. There was never any need to retain them, release them in 
viewDidUnload, release them in dealloc, etc. (If you use ARC there's no visible 
overhead / buttressing even if you do happen to retain them.)

(2) If it really really bothers you that you're pointing to them needlessly, 
you could nilify the pointers at the end of viewDidLoad. Now you're not 
pointing to them any more. I don't quite see what good this would accomplish, 
but there's no harm in it.

However, it does seem to me that the real key to happiness for you is probably 
using the numeric tags. :)

m.

--
matt neuburg, phd = m...@tidbits.com, 
A fool + a tool + an autorelease pool = cool!
Programming iOS 4!
http://www.apeth.net/matt/default.html#iosbook___

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: ARC + return of autoreleased CFType

2011-10-20 Thread Matt Neuburg 
On Wed, 19 Oct 2011 11:47:22 -0600, John Pannell  
said:

>- (CGColorRef)CGColorCopy

The CG prefix is not yours to use at the start of a method name. Start with 
your own prefix.

Also, follow the convention that if you're handing back a newly created 
retained object, the word Create appears early in the title. You know there's a 
rule that Create means a retained ref is returned, so use that rule in your own 
name, so that when you come back to this code in a year you'll know what's 
happening.

Also, be descriptive as to what this method does. "Copy" doesn't really cut it. 
So, maybe call this something like MyCGColorCreateWithCalibratedSpace (or 
something - I'm not entirely clear on the purpose of the method).

m.

--
matt neuburg, phd = m...@tidbits.com, 
A fool + a tool + an autorelease pool = cool!
Programming iOS 4!
http://www.apeth.net/matt/default.html#iosbook___

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

CD database breaks after lightweight migration?

2011-10-20 Thread Fritz Anderson 
Xcode 4.2, iOS 5.0 SDK, iOS Simulator for 4.3.

I'll do the short version of this, in case there's a well-known answer. If we 
need to get into code, I'll be glad to supply it.

I added a version to my data model* and added an attribute to one of my 
entities. It is Boolean, non-optional, and defaulted to NO.

When I create my NSPersistentStoreCoordinator, I pass 
NSMigratePersistentStoresAutomaticallyOption and 
NSInferMappingModelAutomaticallyOption, both NSNumber YES, as options to 
addPersistentStoreWithType:

With assertions, I verified that my new attribute is present in the model. The 
"~" file appears. I used a third-party SQLite viewer to verify that in the old 
database, the attribute is absent, in the new one, it is present.

I do a fetch in the MOC. As it happens, it's on a different entity, but it has 
a relationship to the changed entity, and prefetches the relationship. I 
verified with that SQLite viewer that an object matching the query is present 
in the DB.

The fetch succeeds, but the result is a fault. Attempting to fire the fault by 
sending it a valueForKey: simply produces a no-such-key exception (meaning it's 
still a fault).

My impression had been that adding an attribute with a default was the 
canonical case in which lightweight migration should work. The SQLite tables do 
in fact migrate (though I can't speak for the metadata).

Does it in fact not work? Or is there something else I should be frobbing?

— F


* (Hint for Xcode 4 users: The CD documents are obsolete on how to make your 
new version the current one. Select the .xcdatamodel_d_ in the Project 
navigator, and use the File inspector to select your new version as current. I 
haven't found this documented anywhere.)

___

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: Enter/exit full screen notification

2011-10-20 Thread Lee Ann Rucker 

On Oct 20, 2011, at 2:21 AM, Ryan Joseph wrote:

> 
> On Oct 20, 2011, at 2:45 PM, Lee Ann Rucker wrote:
> 
>> You're trying to see changes made by other apps, right? I don't think you're 
>> going to see these notifications, then, and also Lion's fullscreen moves the 
>> window into its own special Mission Control Space, so I'd think your window 
>> would be left behind on the original Space.
> 
> In that case maybe it's not necessary to do anything in 10.7 (at least for 
> apps that implement the new full screen mode). I haven't even tested on 10.7 
> yet which I'll do soon.
> 
>> 
>> In 10.6 (and 10.7) it's NSApplication presentationOptions. I've never tried 
>> to detect another app's changes to them, though.
> 
> 
> I did actually read about this. I'm new to Cocoa so I wasn't sure if I was 
> doing it right but the NSApplication docs suggest I can observe the value of 
> currentSystemPresentationOptions. My tests didn't get the method invoked I 
> set to observe but I like I said this could be because the app I was testing 
> (QuickTime Player) didn't enter full screen via NSApplication's 
> presentationOptions. I posted what the docs say at the end. But how to do I 
> know if the app in full screen mode actually uses this API? It doesn't seem 
> reliable even if I did figure out the KVO system in Cocoa correctly.
> 
> One other idea is getting a notification if the menu bar was hidden since 
> this usually means an app went into full screen mode but I can't find that 
> notification either.

Pre-Lion, fullscreen just meant making a borderless window that covered a 
screen; changing the presentationOptions was optional. On Macs with multiple 
monitors, if the screen being used didn't have the menu or dock there'd be no 
need to change anything. There's also an NSView fullScreenMode - it wasn't 
useful for my purposes so I don't know what it affects.

And then an app might have been written pre-10.5 and use SystemUIMode, or even 
just raise the window level so it was above the 
menubar.___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Get my NSDocument-based application out from "Open With" menu?

2011-10-20 Thread Lee Ann Rucker 

On Oct 20, 2011, at 4:51 AM, Nick wrote:

> Hello
> I have an application that is able to process .txt files, which can be
> opened using File->Open and saved with File->Save, File->Save As.
> The problem is that Finder thinks that my application is an app that the
> user may want to open by double clicking a text file. How does it do it? And
> how could I prevent OS X from adding my application to the list "Open With"
> of the context menu of txt files?
> Thank you

Take .txt out of your plist, subclass [NSDocumentController 
runModalOpenPanel:forTypes:] to add "txt" to the types it can open, and (I 
think; I haven't done this) [NSDocument 
fileNameExtensionForType:saveOperation:] for save - if not, that's a starting 
point.___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Get my NSDocument-based application out from "Open With" menu?

2011-10-20 Thread Conrad Shultz 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 10/20/11 12:25 PM, Lee Ann Rucker wrote:
> 
> On Oct 20, 2011, at 4:51 AM, Nick wrote:
> 
>> Hello I have an application that is able to process .txt files, 
>> which can be opened using File->Open and saved with File->Save, 
>> File->Save As. The problem is that Finder thinks that my 
>> application is an app that the user may want to open by double 
>> clicking a text file. How does it do it? And how could I prevent
>> OS X from adding my application to the list "Open With" of the
>> context menu of txt files? Thank you
> 
> Take .txt out of your plist, subclass [NSDocumentController 
> runModalOpenPanel:forTypes:] to add "txt" to the types it can
> open, and (I think; I haven't done this) [NSDocument 
> fileNameExtensionForType:saveOperation:] for save - if not, that's
> a starting point.___

May I also ask why you would want to do this?  I would generally expect
that if an application lets me open and save a format via the menus that
I would also be able to open it through Finder.


- -- 
Conrad Shultz

Synthetiq Solutions
www.synthetiqsolutions.com

-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.14 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk6geIoACgkQaOlrz5+0JdV2/QCfXV2WNQenIKih3GVsnrOW+QO1
ObQAn2ZlJ3xcrc3dVgLFKjyYvUGjohK+
=GGSw
-END PGP SIGNATURE-
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Scripting Bridge warning: 'no class for scripting class "iTunesBrowserWindow"'

2011-10-20 Thread Gabriel Roth 
Hello all:

The Scripting Bridge header file for iTunes identifies
iTunesBrowserWindow as a subclass of iTunesWindow. But when I run the
following code:

iTunesApplication *iTunes = [SBApplication
applicationWithBundleIdentifier:@"com.apple.iTunes"];
SBElementArray *windows = [iTunes windows];
for (iTunesWindow *theWindow in windows)
{
if ( [theWindow isKindOfClass:[iTunes
classForScriptingClass:@"iTunesBrowserWindow"]] )
{
NSLog(@"Browser!");
}
}

I get the following warning: warning:  has no class for scripting class
"iTunesBrowserWindow".
(The warning is logged once for each open iTunes window.)

Can anyone understand why this happens? Thanks for any help.

Gabe Roth
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Get my NSDocument-based application out from "Open With" menu?

2011-10-20 Thread Lee Ann Rucker 

On Oct 20, 2011, at 12:37 PM, Conrad Shultz wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On 10/20/11 12:25 PM, Lee Ann Rucker wrote:
>> 
>> On Oct 20, 2011, at 4:51 AM, Nick wrote:
>> 
>>> Hello I have an application that is able to process .txt files, 
>>> which can be opened using File->Open and saved with File->Save, 
>>> File->Save As. The problem is that Finder thinks that my 
>>> application is an app that the user may want to open by double 
>>> clicking a text file. How does it do it? And how could I prevent
>>> OS X from adding my application to the list "Open With" of the
>>> context menu of txt files? Thank you
>> 
>> Take .txt out of your plist, subclass [NSDocumentController 
>> runModalOpenPanel:forTypes:] to add "txt" to the types it can
>> open, and (I think; I haven't done this) [NSDocument 
>> fileNameExtensionForType:saveOperation:] for save - if not, that's
>> a starting point.___
> 
> May I also ask why you would want to do this?  I would generally expect
> that if an application lets me open and save a format via the menus that
> I would also be able to open it through Finder.

In our case, long ago we used an extension - "cfg" - that's unfortunately very 
common. We changed it before we ever had a Mac app, so the only "cfg" files on 
a Mac are either very old and copied from another OS, or should be opened by 
some other app. The handful of people who do have old files are happy enough 
with having to go through File->Open and the vast number of other people are 
happy that double-clicking their "cfg" files doesn't open our app.

That's why I don't know about the save options - we don't save this format  
:)___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Get my NSDocument-based application out from "Open With" menu?

2011-10-20 Thread John Joyce 
>>> 
 Hello I have an application that is able to process .txt files, 
 which can be opened using File->Open and saved with File->Save, 
 File->Save As. The problem is that Finder thinks that my 
 application is an app that the user may want to open by double 
 clicking a text file. How does it do it? And how could I prevent
 OS X from adding my application to the list "Open With" of the
 context menu of txt files? Thank you
>>> 
>>> Take .txt out of your plist, subclass [NSDocumentController 
>>> runModalOpenPanel:forTypes:] to add "txt" to the types it can
>>> open, and (I think; I haven't done this) [NSDocument 
>>> fileNameExtensionForType:saveOperation:] for save - if not, that's
>>> a starting point.___
>> 
>> May I also ask why you would want to do this?  I would generally expect
>> that if an application lets me open and save a format via the menus that
>> I would also be able to open it through Finder.
> 
> In our case, long ago we used an extension - "cfg" - that's unfortunately 
> very common. We changed it before we ever had a Mac app, so the only "cfg" 
> files on a Mac are either very old and copied from another OS, or should be 
> opened by some other app. The handful of people who do have old files are 
> happy enough with having to go through File->Open and the vast number of 
> other people are happy that double-clicking their "cfg" files doesn't open 
> our app.
> 
> That's why I don't know about the save options - we don't save this format  
> :)___

You might want to look at implementing an "import" function and not declaring 
this file type as a document you open.
That will be the most graceful way and will guid your customers into converting 
the file to the modern types you prefer them to use.
All you really need to do is implement the logic under that to identify the 
file type is correct and read it in, without declaring a UTI or anything at an 
app level.___

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: ARC + return of autoreleased CFType

2011-10-20 Thread Greg Parker 
On Oct 20, 2011, at 10:11 AM, Matt Neuburg wrote:
> You know there's a rule that Create means a retained ref is returned

There is no such rule in the Cocoa memory management conventions. 

http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/MemoryMgmt/Articles/mmRules.html

There is a "Create" rule in the convention for CoreFoundation functions, but 
that convention does not apply to Objective-C methods.


-- 
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Get my NSDocument-based application out from "Open With" menu?

2011-10-20 Thread Lee Ann Rucker 

On Oct 20, 2011, at 12:58 PM, John Joyce wrote:

 
> Hello I have an application that is able to process .txt files, 
> which can be opened using File->Open and saved with File->Save, 
> File->Save As. The problem is that Finder thinks that my 
> application is an app that the user may want to open by double 
> clicking a text file. How does it do it? And how could I prevent
> OS X from adding my application to the list "Open With" of the
> context menu of txt files? Thank you
 
 Take .txt out of your plist, subclass [NSDocumentController 
 runModalOpenPanel:forTypes:] to add "txt" to the types it can
 open, and (I think; I haven't done this) [NSDocument 
 fileNameExtensionForType:saveOperation:] for save - if not, that's
 a starting point.___
>>> 
>>> May I also ask why you would want to do this?  I would generally expect
>>> that if an application lets me open and save a format via the menus that
>>> I would also be able to open it through Finder.
>> 
>> In our case, long ago we used an extension - "cfg" - that's unfortunately 
>> very common. We changed it before we ever had a Mac app, so the only "cfg" 
>> files on a Mac are either very old and copied from another OS, or should be 
>> opened by some other app. The handful of people who do have old files are 
>> happy enough with having to go through File->Open and the vast number of 
>> other people are happy that double-clicking their "cfg" files doesn't open 
>> our app.
>> 
>> That's why I don't know about the save options - we don't save this format  
>> :)___
> 
> You might want to look at implementing an "import" function and not declaring 
> this file type as a document you open.
> That will be the most graceful way and will guid your customers into 
> converting the file to the modern types you prefer them to use.
> All you really need to do is implement the logic under that to identify the 
> file type is correct and read it in, without declaring a UTI or anything at 
> an app level.

"Import" has a different meaning in our app that is not applicable to this 
particular file type, but that's pretty much what we do - it's a file that we 
can open, but we don't declare that and have no UTI for it to avoid conflicts 
with other apps; the only thing that can open it is 
"File->Open".___

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

WebView doesn't scroll

2011-10-20 Thread Vladimir Pouzanov 
Hi all,

I have an issue with WebView and scrolling the content. Using even the simplest 
code (xib with webView on top of it and [[webView mainFrame] 
loadRequest:[NSURLRequest requestWithURL:[NSURL 
URLWithString:@"http://any.site.with.long.content";]]]) I still fail to make the 
webView scrollable (i.e. it does not respond to scroll taps, mouse wheel, 
keyboard arrows, but otherwise works fine). The target system is 10.7. Is there 
anything big that I'm missing?

-- 
Vladimir Pouzanov
http://www.farcaller.net/




smime.p7s
Description: S/MIME cryptographic signature
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: ARC + return of autoreleased CFType

2011-10-20 Thread Matt Neuburg 

On Oct 20, 2011, at 1:20 PM, Greg Parker wrote:

> On Oct 20, 2011, at 10:11 AM, Matt Neuburg wrote:
>> You know there's a rule that Create means a retained ref is returned
> 
> There is no such rule in the Cocoa memory management conventions. 
> 
> http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/MemoryMgmt/Articles/mmRules.html
> 
> There is a "Create" rule in the convention for CoreFoundation functions, but 
> that convention does not apply to Objective-C methods.

Sure, but still, he's returning a retained CGColorRef. And CGColor participates 
in this convention (CGColorRelease, CGColorRetain, CGColorCreate etc.). I'm not 
saying he has to do it; I'm merely suggesting that the magic word "Create" will 
help him remember what he's trying to remember, namely that he's returning a 
retained CGColorRef and the caller will need to call CGColorRelease on it 
later. m.___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Get my NSDocument-based application out from "Open With" menu?

2011-10-20 Thread John Joyce 
>> Hello I have an application that is able to process .txt files, 
>> which can be opened using File->Open and saved with File->Save, 
>> File->Save As. The problem is that Finder thinks that my 
>> application is an app that the user may want to open by double 
>> clicking a text file. How does it do it? And how could I prevent
>> OS X from adding my application to the list "Open With" of the
>> context menu of txt files? Thank you
> 
> Take .txt out of your plist, subclass [NSDocumentController 
> runModalOpenPanel:forTypes:] to add "txt" to the types it can
> open, and (I think; I haven't done this) [NSDocument 
> fileNameExtensionForType:saveOperation:] for save - if not, that's
> a starting point.___
 
 May I also ask why you would want to do this?  I would generally expect
 that if an application lets me open and save a format via the menus that
 I would also be able to open it through Finder.
>>> 
>>> In our case, long ago we used an extension - "cfg" - that's unfortunately 
>>> very common. We changed it before we ever had a Mac app, so the only "cfg" 
>>> files on a Mac are either very old and copied from another OS, or should be 
>>> opened by some other app. The handful of people who do have old files are 
>>> happy enough with having to go through File->Open and the vast number of 
>>> other people are happy that double-clicking their "cfg" files doesn't open 
>>> our app.
>>> 
>>> That's why I don't know about the save options - we don't save this format  
>>> :)___
>> 
>> You might want to look at implementing an "import" function and not 
>> declaring this file type as a document you open.
>> That will be the most graceful way and will guid your customers into 
>> converting the file to the modern types you prefer them to use.
>> All you really need to do is implement the logic under that to identify the 
>> file type is correct and read it in, without declaring a UTI or anything at 
>> an app level.
> 
> "Import" has a different meaning in our app that is not applicable to this 
> particular file type, but that's pretty much what we do - it's a file that we 
> can open, but we don't declare that and have no UTI for it to avoid conflicts 
> with other apps; the only thing that can open it is "File->Open".

How about the concept of "convert" rather than "import" being that it is legacy 
and all that?

___

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: ARC + return of autoreleased CFType

2011-10-20 Thread Charles Srstka 
On Oct 20, 2011, at 3:43 PM, Matt Neuburg wrote:

> 
> On Oct 20, 2011, at 1:20 PM, Greg Parker wrote:
> 
>> On Oct 20, 2011, at 10:11 AM, Matt Neuburg wrote:
>>> You know there's a rule that Create means a retained ref is returned
>> 
>> There is no such rule in the Cocoa memory management conventions. 
>> 
>> http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/MemoryMgmt/Articles/mmRules.html
>> 
>> There is a "Create" rule in the convention for CoreFoundation functions, but 
>> that convention does not apply to Objective-C methods.
> 
> Sure, but still, he's returning a retained CGColorRef. And CGColor 
> participates in this convention (CGColorRelease, CGColorRetain, CGColorCreate 
> etc.). I'm not saying he has to do it; I'm merely suggesting that the magic 
> word "Create" will help him remember what he's trying to remember, namely 
> that he's returning a retained CGColorRef and the caller will need to call 
> CGColorRelease on it later. m.___

Yeah, but CGColorRelease, etc. are functions. He’s writing an Objective-C 
method, where the conventions are different.

Myself, I’d prefix that method’s name with “new”, but that’s me.

Charles___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Get my NSDocument-based application out from "Open With" menu?

2011-10-20 Thread Lee Ann Rucker 

On Oct 20, 2011, at 2:04 PM, John Joyce wrote:

>>> Hello I have an application that is able to process .txt files, 
>>> which can be opened using File->Open and saved with File->Save, 
>>> File->Save As. The problem is that Finder thinks that my 
>>> application is an app that the user may want to open by double 
>>> clicking a text file. How does it do it? And how could I prevent
>>> OS X from adding my application to the list "Open With" of the
>>> context menu of txt files? Thank you
>> 
>> Take .txt out of your plist, subclass [NSDocumentController 
>> runModalOpenPanel:forTypes:] to add "txt" to the types it can
>> open, and (I think; I haven't done this) [NSDocument 
>> fileNameExtensionForType:saveOperation:] for save - if not, that's
>> a starting point.___
> 
> May I also ask why you would want to do this?  I would generally expect
> that if an application lets me open and save a format via the menus that
> I would also be able to open it through Finder.
 
 In our case, long ago we used an extension - "cfg" - that's unfortunately 
 very common. We changed it before we ever had a Mac app, so the only "cfg" 
 files on a Mac are either very old and copied from another OS, or should 
 be opened by some other app. The handful of people who do have old files 
 are happy enough with having to go through File->Open and the vast number 
 of other people are happy that double-clicking their "cfg" files doesn't 
 open our app.
 
 That's why I don't know about the save options - we don't save this format 
  :)___
>>> 
>>> You might want to look at implementing an "import" function and not 
>>> declaring this file type as a document you open.
>>> That will be the most graceful way and will guid your customers into 
>>> converting the file to the modern types you prefer them to use.
>>> All you really need to do is implement the logic under that to identify the 
>>> file type is correct and read it in, without declaring a UTI or anything at 
>>> an app level.
>> 
>> "Import" has a different meaning in our app that is not applicable to this 
>> particular file type, but that's pretty much what we do - it's a file that 
>> we can open, but we don't declare that and have no UTI for it to avoid 
>> conflicts with other apps; the only thing that can open it is "File->Open".
> 
> How about the concept of "convert" rather than "import" being that it is 
> legacy and all that?

These are all good ideas in general; in this specific case it's just not that 
important. The only difference is the extension and "Save As" will fix that 
up.___

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: ARC + return of autoreleased CFType

2011-10-20 Thread Bill Cheeseman 

On Oct 20, 2011, at 4:43 PM, Matt Neuburg wrote:

> Sure, but still, he's returning a retained CGColorRef. And CGColor 
> participates in this convention (CGColorRelease, CGColorRetain, CGColorCreate 
> etc.). I'm not saying he has to do it; I'm merely suggesting that the magic 
> word "Create" will help him remember what he's trying to remember, namely 
> that he's returning a retained CGColorRef and the caller will need to call 
> CGColorRelease on it later. 


You're absolutely right, Matt. But it's actually more fundamental than that, 
now that Xcode 4 has the Analyze command. I don't believe this is documented, 
but I found out by trial and error that the Core Foundation "create rule" 
should be followed in Cocoa methods that return Core Foundation CFTypeRef 
objects, if you want to get optimum results from Analyze.

Specifically, if your Cocoa method returns a CFTypeRef object retained, and you 
don't put "Copy" or "Create" in the method name, Analyze reports a "potential" 
memory leak. Go back and insert "Copy" or "Create" into the method name, and 
Analyze no longer reports a potential memory leak. To me, it makes all the 
sense in the world to apply the "create rule" to Cocoa methods that return Core 
Foundation CFTypeRef objects.

I found this discovery extraordinarily helpful in using Analyze to kill memory 
issues in a couple of frameworks I distribute. The frameworks make heavy use of 
CFTypeRef objects. I would love to hear from anybody at Apple who can confirm 
that this is the way Analyze is meant to work.

-- 

Bill Cheeseman - b...@cheeseman.name

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Core Data: Determine if managed object is deleted

2011-10-20 Thread Jerry Krinock 
When I need to know whether or not a managed object is deleted, often I fall 
into the trap of trying -[NSManagedObject isDeleted], forgetting that its 
documentation states …

  "… It may return NO at other times, particularly after the object has been 
deleted. …"

In other words, they should have named that method -isDeletedForSure, to 
indicate that the NO result is not reliable.

Anyhow, today I fixed a problem by using this instead …

   BOOL isDeleted ;
   isDeleted = [object isDeleted] || ([object managedObjectContext] == nil) ;

I'm not sure if it will work in all situations.  I suppose that sending the 
magical -processPendingChanges would be another workaround.

___

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: ARC + return of autoreleased CFType

2011-10-20 Thread Jean-Daniel Dupas 

Le 20 oct. 2011 à 23:38, Bill Cheeseman a écrit :

> 
> On Oct 20, 2011, at 4:43 PM, Matt Neuburg wrote:
> 
>> Sure, but still, he's returning a retained CGColorRef. And CGColor 
>> participates in this convention (CGColorRelease, CGColorRetain, 
>> CGColorCreate etc.). I'm not saying he has to do it; I'm merely suggesting 
>> that the magic word "Create" will help him remember what he's trying to 
>> remember, namely that he's returning a retained CGColorRef and the caller 
>> will need to call CGColorRelease on it later. 
> 
> 
> You're absolutely right, Matt. But it's actually more fundamental than that, 
> now that Xcode 4 has the Analyze command. I don't believe this is documented, 
> but I found out by trial and error that the Core Foundation "create rule" 
> should be followed in Cocoa methods that return Core Foundation CFTypeRef 
> objects, if you want to get optimum results from Analyze.
> 
> Specifically, if your Cocoa method returns a CFTypeRef object retained, and 
> you don't put "Copy" or "Create" in the method name, Analyze reports a 
> "potential" memory leak. Go back and insert "Copy" or "Create" into the 
> method name, and Analyze no longer reports a potential memory leak. To me, it 
> makes all the sense in the world to apply the "create rule" to Cocoa methods 
> that return Core Foundation CFTypeRef objects.
> 
> I found this discovery extraordinarily helpful in using Analyze to kill 
> memory issues in a couple of frameworks I distribute. The frameworks make 
> heavy use of CFTypeRef objects. I would love to hear from anybody at Apple 
> who can confirm that this is the way Analyze is meant to work.
> 

If you want to avoid ambiguity, just add a CF_RETURNS_RETAINED annotation 
attribute to your method.

-- Jean-Daniel




___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Core Data: Determine if managed object is deleted

2011-10-20 Thread Gideon King 
Ooh, I had never noticed that - I just assumed that the method did what you 
would think. That may be the cause of an issue in my code. Thanks for the heads 
up.

I would tend to try to avoid processPendingChanges if possible since it appears 
to be a rather expensive operation.

Regards

Gideon

On 21/10/2011, at 8:37 AM, Jerry Krinock wrote:

> When I need to know whether or not a managed object is deleted, often I fall 
> into the trap of trying -[NSManagedObject isDeleted], forgetting that its 
> documentation states …
> 
>  "… It may return NO at other times, particularly after the object has been 
> deleted. …"
> 
> In other words, they should have named that method -isDeletedForSure, to 
> indicate that the NO result is not reliable.
> 
> Anyhow, today I fixed a problem by using this instead …
> 
>   BOOL isDeleted ;
>   isDeleted = [object isDeleted] || ([object managedObjectContext] == nil) ;
> 
> I'm not sure if it will work in all situations.  I suppose that sending the 
> magical -processPendingChanges would be another workaround.
> 

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Core Data: Determine if managed object is deleted

2011-10-20 Thread Quincey Morris 
On Oct 20, 2011, at 15:37 , Jerry Krinock wrote:

> When I need to know whether or not a managed object is deleted, often I fall 
> into the trap of trying -[NSManagedObject isDeleted], forgetting that its 
> documentation states …
> 
>  "… It may return NO at other times, particularly after the object has been 
> deleted. …"
> 
> In other words, they should have named that method -isDeletedForSure, to 
> indicate that the NO result is not reliable.
> 
> Anyhow, today I fixed a problem by using this instead …
> 
>   BOOL isDeleted ;
>   isDeleted = [object isDeleted] || ([object managedObjectContext] == nil) ;
> 
> I'm not sure if it will work in all situations.  I suppose that sending the 
> magical -processPendingChanges would be another workaround.

FWIW, I also wonder if this ("Is it deleted?") is the right question to ask. As 
you've documented here, the technical question is largely a housekeeping one -- 
about how the object is represented in terms of the in-memory object graph vs 
the persistent store, faulting, etc.

Functionally, isn't the question likely to be whether the object is … I dunno … 
*reachable* any more? From that point of view, the criterion may well be 
whether a key relationship of the object is null or not.

IOW, it's a question of the object's role, not its representation, and the Core 
Data representation isn't conclusive as to the role.

It's just a thought. You seem to have been chasing these representation-related 
deletion issues for months now, or longer.


___

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: ARC + return of autoreleased CFType

2011-10-20 Thread Quincey Morris 
On Oct 20, 2011, at 15:38 , Jean-Daniel Dupas wrote:

> Le 20 oct. 2011 à 23:38, Bill Cheeseman a écrit :
> 
>> I found this discovery extraordinarily helpful in using Analyze to kill 
>> memory issues in a couple of frameworks I distribute. The frameworks make 
>> heavy use of CFTypeRef objects. I would love to hear from anybody at Apple 
>> who can confirm that this is the way Analyze is meant to work.
>> 
> 
> If you want to avoid ambiguity, just add a CF_RETURNS_RETAINED annotation 
> attribute to your method.

And I'll just throw in this reference:

http://clang-analyzer.llvm.org/annotations.html

which I found to be a good overview of what the analyzer is trying to do, 
though it doesn't address Bill's question directly.


___

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: WebView doesn't scroll

2011-10-20 Thread Andy Lee 
Works fine for me on 10.7.2 and Xcode 3.2.6.

If you want to zip up your project and send it to me I'd be glad to see if I 
can reproduce the problem. (Just remember to remove the build directory before 
zipping.)

--Andy

On Oct 20, 2011, at 4:37 PM, Vladimir Pouzanov wrote:

> Hi all,
> 
> I have an issue with WebView and scrolling the content. Using even the 
> simplest code (xib with webView on top of it and [[webView mainFrame] 
> loadRequest:[NSURLRequest requestWithURL:[NSURL 
> URLWithString:@"http://any.site.with.long.content";]]]) I still fail to make 
> the webView scrollable (i.e. it does not respond to scroll taps, mouse wheel, 
> keyboard arrows, but otherwise works fine). The target system is 10.7. Is 
> there anything big that I'm missing?
> 
> -- 
> Vladimir Pouzanov
> http://www.farcaller.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/aglee%40mac.com
> 
> This email sent to ag...@mac.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: preventing bad memory access

2011-10-20 Thread Wilker 
Thanks for the answers guys.

I mean I will use the f* operations.

But they are really safe? There is anything that I can do for extreme
situations in case to avoid bad memory access?
---
Wilker Lúcio
http://about.me/wilkerlucio/bio
Kajabi Consultant
+55 81 82556600



On Thu, Oct 20, 2011 at 12:09 AM, Don Quixote de la Mancha <
quix...@dulcineatech.com> wrote:

> On Tue, Oct 18, 2011 at 9:22 AM, Jens Alfke  wrote:
> > On Oct 17, 2011, at 9:26 PM, Wilker wrote:
> > if the user is acessing a
> >> file from an external drive, and the file has 8gb, I only wanna read
> 64kb,
> >> so, I don't wanna read it all just for 64kb.
> >
> > Just use fopen/fseek/fread/fclose. Mapping in the entire file just so you
> can read 64kb is overkill.
>
> Specifically, if you fseek to the beginning of where you want to read,
> then fread what you want, the only part that will get cached is what
> you read.  It will be faster than not caching.
>
> mapping the file then reading from memory also caches parts of the
> file, but only what you read.
>
> If you're going to read your file in large chunks then it will be
> faster to use the open(), lseek(), read() and close() system calls.
> The "f" calls from stdio use an in-process cache which is faster for
> small accesses but slower for large ones.
>
>
> --
> Don Quixote de la Mancha
> Dulcinea Technologies Corporation
> Software of Elegance and Beauty
> http://www.dulcineatech.com
> quix...@dulcineatech.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/wilkerlucio%40gmail.com
>
> This email sent to wilkerlu...@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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: preventing bad memory access

2011-10-20 Thread Jens Alfke 

On Oct 20, 2011, at 8:19 PM, Wilker wrote:

> I mean I will use the f* operations.
> But they are really safe? There is anything that I can do for extreme
> situations in case to avoid bad memory access?

What’s unsafe is accessing file-mapped memory after the file becomes 
unavailable.

If you use fread (or read), you’re not doing that. You're allocating your own 
memory from the heap first, then copying data from the file into it. There’s 
nothing dangerous about that. The memory will be available until you explicitly 
free it.

—Jens___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: preventing bad memory access

2011-10-20 Thread Don Quixote de la Mancha 
On Thu, Oct 20, 2011 at 8:19 PM, Wilker  wrote:
> But they are really safe? There is anything that I can do for extreme
> situations in case to avoid bad memory access?

Yes they are safe.  The "f" I/O calls go back to the very beginnings
of the C standard library in the late 1960s.  I myself have been using
them since 1988, on many different platforms.

By "bad memory access" are you concerned about excessive file block
storage caching, or crashes due to bad memory accesses such as stray
pointers?

If you're concerned about the performance hit of caching, the best
thing you can do is to get your application at least mostly working,
then profile it with Instruments.

 If this is on Mac OS X, at the same time you are testing your app,
run the top command in the Terminal - see "man top" for what the
fields mean.  Run top for a little while on a system  with a normal
load, then test your app, then check to see how many more buffers
there are in the kernel page cache.  "man top" explains what all the
fields are.

If you're concerned about crashing due to bad memory access, and your
application is on Mac OS X, run it with Guard Malloc enabled.  This
use the hardware memory management unit to catch bad memory
references.

Guard Malloc is not supported on the iOS but you can use it in the iOS
Simulator.

You can also enable malloc() diagnostics in Xcode, such as pre-filling
new memory with garbage, as well as post-filling free blocks.

In the same place where you enable malloc() diagnostics you can have
stack traces recorded whenever a malloc is done, to track down what
parts of your code do the most allocation.

If you are not using garbage collection, a very powerful tool is the
Valgrind Memory Debugger.  It not only validates all memory
references, but it also checks the input parameters to most OS X API
calls.

Unfortunately I understand Valgrind does not yet support garbage
collection.  I don't see why it couldn't support ARC but I really
don't know whether it does.

Finally, use assert(), what I call "The Test That Keeps On Testing".
Whenever your functions or methods have particular requirements of
their input parameters, use assert() to validate them.  Whenever any
of your functions or methods make any particular guarantee about the
state of your data upon their return, again use assert() to validate
that the guarantee holds.

For example, if I were writing my own implementation of the C standard
library, the strlen() function cannot take a NULL char pointer.  So I
would write it something like this:

int strlen( const char *inStr )
{
int result = 0;

assert( NULL != inStr && "inStr must not be NULL" );

while ( *inStr++ )
++result;

return result;
}


Assert() is a macro that is stripped out when NDEBUG is #define'd,
which is done for you in release or profile builds.  If you use it
properly, it does not slow your debug builds down much at all, and
because it is stripped out for release builds, there is no slow-down
for the end-user.

Class invariants are a form of assertions that depend on the fact that
many classes have a condition that always holds true.  This condition
may temporarily be broken within class member functions or methods,
but is always restored before they return.

Not every class has a sensible invariant, but many of them do.  If you
design your classes so they definitely have some manner of invariant,
they will likely be easier for you and your colleagues to understand.

You would use them like this, in C++:

// MyInvariant.h
//
// We need the semicolons to go away when NDEBUG is #defined
#ifndef NDEBUG
#define Invariant() bool invariant();
#else
#define Invariant()
#endif

class Foo{
public:
   Foo();
   virtual ~Foo();

   Invariant() // NOTE: No Semicolon!

   virtual int bar();
};

int Foo::bar()
{
assert( Invariant() );

// Do some real computation here that messes up the invariant
//
// But only temporarily.
//
// Just before the member function exits, restore the invariant

assert( Invariant() );

return 0;
}

The above macro is not quite right because you want to get rid of the
semicolon in the class declaration (I think so anyway), but you don't
want the semicolon appearing between the parentheses of the assert
call when NDEBUG is not defined (that is, in a debug build).

You also want other classes to be able to check any class' invariant
at any time, from outside that class' member functions or methods:

void Baz::boo()
{
Foo *theFoo = new Foo();

assert( theFoo->Invariant() );

return;
}

There are some considerations of thread safety.  You need the
Invariant to be thread safe, or you need to ensure that you don't
check it when multiple thread accesses make the invariant invalid.

Class invariants, asserting preconditions and asserting postconditions
are all together known as "Programming by Contract".  Programming by
Contract is built into the Eiffel programming language, which
unfortu

Re: preventing bad memory access

2011-10-20 Thread Don Quixote de la Mancha 
On Thu, Oct 20, 2011 at 8:48 PM, Jens Alfke  wrote:

> What’s unsafe is accessing file-mapped memory after the file becomes
> unavailable.
> If you use fread (or read), you’re not doing that. You're allocating your
> own memory from the heap first, then copying data from the file into it.
> There’s nothing dangerous about that. The memory will be available until you
> explicitly free it.

All the "f" Standard I/O calls return result codes.  The calls will
fail if your I/O fails for some reason, for example a disk being
ejected after you've opened it but before you've had a chance to read
it, or if you attempt to open a file only to find it missing.

While Mac OS X discourages the user from dismounting filesystems that
have open files on them, the user can forcibly dismount them.  If
nothing else, they can pull out a USB key, or disconnect a FireWire
cable or ethernet cable over which one is getting data from a file
server.

Use "man fopen", "man fread", "man fwrite", "man fseek" and "man
fclose" to see what the error codes are.

To be robust in the face of I/O error, you will need to design your
application well.  This is not a trivial task for a novice.  It takes
some experience to learn how to do it.

For C++, you would need to throw an exception on I/O error, then write
exception-safe code.  I have not yet really figured out the right way
to do the equivalent for Objective-C, because Objective-C exceptions
don't work like C++ exceptions do.

You can pass result codes back to calling functions, but you have to
be quite diligent about always doing so, always checking for results
from the functions you call, then doing something sensible no matter
what results your functions or methods or member functions return.


-- 
Don Quixote de la Mancha
Dulcinea Technologies Corporation
Software of Elegance and Beauty
http://www.dulcineatech.com
quix...@dulcineatech.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: preventing bad memory access

2011-10-20 Thread Kyle Sluder 
On Oct 20, 2011, at 8:56 PM, Don Quixote de la Mancha 
 wrote:

> For C++, you would need to throw an exception on I/O error, then write
> exception-safe code.  I have not yet really figured out the right way
> to do the equivalent for Objective-C, because Objective-C exceptions
> don't work like C++ exceptions do.

This is what NSError is for. You would return NO (or some other similar value 
indicating unsuccessful completion) and return an NSError by reference.

FWIW, Objective-C exceptions do behave like C++ exceptions (the exception 
machinery is the same on modern runtimes), but are not _used_ like C++ 
exceptions. Throwing an exception from Objective-C code is used to signal 
programmer error, not general failure to complete an operation.

--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: WebView doesn't scroll

2011-10-20 Thread Vladimir Pouzanov 
On 21 окт. 2011, at 03:50, Andy Lee wrote:
> Works fine for me on 10.7.2 and Xcode 3.2.6.
> 
> If you want to zip up your project and send it to me I'd be glad to see if I 
> can reproduce the problem. (Just remember to remove the build directory 
> before zipping.)


Somehow it was related to "identifier" field in IB. After filling it everything 
works as expected.

-- 
Vladimir Pouzanov
http://www.farcaller.net/




smime.p7s
Description: S/MIME cryptographic signature
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com