Re: Persistence.... iOS

[Jens Alfke]

On Feb 25, 2012, at 6:50 PM, R wrote:

> I would like to archive the file in pieces update the file rather
> than write an entire new file each time.
> Is there a good way to just write "object for key" to a file?

Yes: Use a database. That’s literally exactly what you’re describing. You have 
several choices, such as

CoreData — Integrated into the OS, lots of documentation, very powerful. 
Complex and has a steep learning curve IMHO.
SQLite — Built-in, lightweight. But the API is low-level and awkward, esp. if 
you don’t already know SQL. You’ll probably want to use it with an Obj-C 
wrapper like FMDB .
Nanostore  — A Cocoa API based on SQLite 
that provides a higher-level interface similar to property lists.
TouchDB  — Also a Cocoa API, also 
based on SQLite. Compatible with the CouchDB database. Very strong 
replication/synchronization features, should you ever want to sync your data to 
a server or another device. Written by me :)

—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

Persistence.... iOS

[R]

I have a large NSMutableDictionary that houses UIImages for memberID
keys.

I'm unArchiving the file using blocks and queues to bring to the data
out off of the main thread.

I would like to archive the file in pieces update the file rather
than write an entire new file each time.

Is there a good way to just write "object for key" to a file?

R
___

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

NSStepper

[Dale Miller]

On Thu, Feb 23, 2012 at 6:16 AM, William Squires  
 wrote:
From what I've read, the NSStepper has a bug (though practically,  
you'll never see it); if one were to click the up or down arrow on the  
control 2^32 times (assuming it's value is a 4-byte signed int,and is  
initialized to 0), it would wrap around (or raise an exception for  
integer overflow).


I don't think so, unless it's a bug introduced in 10.6 or 10.7.  
NSStepper has the instance methods setMinValue: and setMaxValue:. If  
one clicks the up or down arrow repeatedly (or holds it down if the  
stepper is set for Autorepeat) the value does not increase above the  
max or decrease below the min, although it may be defined to  
wraparound from the max to the min or vice-versa.


Dale Miller





___

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: [Obj-C] if (self) vs. if (self != nil)

[Eric Wing]

On 2/24/12, Sean McBride  wrote:
> On Fri, 24 Feb 2012 10:36:51 -0700, Keary Suska said:
>
>>I don't believe this is the case. There can be funny issues with BOOL
>>types, such that BOOL == YES is an inadvisable construct, since your
>>BOOL could be an integer of any value.
>
> Indeed, and it's extremely frustrating.  I encourage you to file bugs on
> this, or maybe add a comment here:
>
> 
>

Small tangent, but I think it's unlikely that Apple will change the
definition of BOOL of signed char to C99 _Bool. They already missed
ripe opportunities to do this with x86_64, iOS armv6 and armv7.
Perhaps the new enhancement request we should be filing is to
encourage the use of _Bool in all new APIs moving forward, especially
in new frameworks. (It's not completely unprecedented; I've seen some
other bool types used in the other Apple frameworks, plus we had that
whole int->NSInteger change not too long ago.)

-Eric
-- 
Beginning iPhone Games Development
http://playcontrol.net/iphonegamebook/
___

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: [Obj-C] if (self) vs. if (self != nil)

[Gary L. Wade]

On Feb 25, 2012, at 6:29 AM, Scott Ribe  wrote:

> (!0) evaluates to 1.

I've seen it evaluate to -1 in one compiler some time back when stored in a 
signed integer bit field variable.
--
Gary L. Wade (Sent from my iPhone)
http://www.garywade.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: [Obj-C] if (self) vs. if (self != nil)

[Gary L. Wade]

On Feb 25, 2012, at 7:56 AM, Kyle Sluder  wrote:

> …converting a pointer to integer is not guaranteed to result in a 
> representation that fits in any size of integer…

You can use uintptr_t for such purposes, which is supposed to be defined in 
stdint.h.
--
Gary L. Wade (Sent from my iPhone)
http://www.garywade.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: NSColorWell - controlling opacity

[Fritz Anderson]

On 25 Feb 2012, at 7:10 AM, Graham Cox wrote:

> I was surprised to find I couldn't set whether the color panel displayed the 
> opacity slider depending on which colour well was selected. Can anyone think 
> of a way I could achieve that? Seems to me that the color well/color panel 
> communication is a totally closed book - I've already got various workarounds 
> to overcome other issues with this communication, but with this one it's 
> looking like I'm going to have to throw out NSColorWell and just do it myself 
> from scratch. I thought frameworks were supposed to help, not hinder?

What I'd try next would be to subclass NSColorWell and override -activate: and 
-deactivate, and send the shared color panel -setShowsAlpha: accordingly.

If you have a lot of wells, that may be a lot of work. It might reduce the work 
if your subclass had a property controlling whether to ask for the alpha 
slider, and use User Defined Runtime Attributes (Identity inspector) to set it 
at load time.

— F


___

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

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

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

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

Re: [Obj-C] if (self) vs. if (self != nil)

[Kyle Sluder]

On Feb 25, 2012, at 7:45 AM, Scott Ribe  wrote:

> On Feb 25, 2012, at 8:38 AM, Kyle Sluder wrote:
> 
>> Does Harbison & Steele say that pointers converted to integer have the value 
>> zero, or does it say that if(ptr) is identical to if(ptr != 0)?
> 
> It explicitly states that null pointers converted to int are 0, and that 
> other conversions are implementation-defined but round-trip conversions 
> through a large-enough int type produce the original pointer.

Yeah, that's all kinds of wrong. As the standard also explicitly states, 
converting a pointer to integer is not guaranteed to result in a representation 
that fits in any size of integer, and it might be a trap representation. The 
conversion from integer to pointer is similarly implementation-defined. The 
only round-trip guaranteed by the standard is pointer-type to pointer-type, and 
then only if the pointer value is correctly aligned for the second pointee 
type, or the second pointer type is pointer-to-void.

> I have a suspicion that this is a normalization in behavior introduced in the 
> standardization process--note that I still have K&R 2nd edition here, and as 
> far as I can tell it simply does not specify what happens when a null pointer 
> is converted to int.

K&R 2nd Ed. was updated for C89, I believe. But regardless, K&R is notoriously 
light on specifics like this. Which is great when you're teaching a language, 
but not nearly as great when you're implementing a compiler that intends to 
support most of the code in the modern world.

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

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

Re: [Obj-C] if (self) vs. if (self != nil)

[Scott Ribe]

On Feb 25, 2012, at 8:38 AM, Kyle Sluder wrote:

> Does Harbison & Steele say that pointers converted to integer have the value 
> zero, or does it say that if(ptr) is identical to if(ptr != 0)?

It explicitly states that null pointers converted to int are 0, and that other 
conversions are implementation-defined but round-trip conversions through a 
large-enough int type produce the original pointer.

I have a suspicion that this is a normalization in behavior introduced in the 
standardization process--note that I still have K&R 2nd edition here, and as 
far as I can tell it simply does not specify what happens when a null pointer 
is converted to int.

-- 
Scott Ribe
scott_r...@elevated-dev.com
http://www.elevated-dev.com/
(303) 722-0567 voice





___

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: [Obj-C] if (self) vs. if (self != nil)

[Kyle Sluder]

On Feb 25, 2012, at 7:38 AM, Kyle Sluder  wrote:

> compared to an nether constant expression with the value 0

"Integer," not nether. Silly autocorrect.

--Kyle Sluder
(Sent from my uPas)
___

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: [Obj-C] if (self) vs. if (self != nil)

[Kyle Sluder]

On Feb 25, 2012, at 7:26 AM, Scott Ribe  wrote:

> On Feb 25, 2012, at 8:23 AM, Kyle Sluder wrote:
> 
>> And then show how that jives with footnote 56, which says that the intent of 
>> the standard is that null pointers become whatever integer is most similar 
>> to the bit pattern used for null pointers, which may or may not be the same 
>> as that used for integer zero depending on the platform.
> 
> Hmm. So Harbison & Steele (5th Edition) is wrong??? That's a surprise to me.

Does Harbison & Steele say that pointers converted to integer have the value 
zero, or does it say that if(ptr) is identical to if(ptr != 0)?

The first is an error. That is plain black and white in the standard. The 
second is quite possible, even likely. But because the standard just says 
"compared to 0" rather than "compared to an nether constant expression with the 
value 0," I don't know if it's guaranteed by the standard.

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

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

Re: [Obj-C] if (self) vs. if (self != nil)

[Scott Ribe]

On Feb 25, 2012, at 8:23 AM, Kyle Sluder wrote:

> And then show how that jives with footnote 56, which says that the intent of 
> the standard is that null pointers become whatever integer is most similar to 
> the bit pattern used for null pointers, which may or may not be the same as 
> that used for integer zero depending on the platform.

Hmm. So Harbison & Steele (5th Edition) is wrong??? That's a surprise to me.

-- 
Scott Ribe
scott_r...@elevated-dev.com
http://www.elevated-dev.com/
(303) 722-0567 voice





___

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: [Obj-C] if (self) vs. if (self != nil)

[Kyle Sluder]

On Feb 25, 2012, at 6:22 AM, Scott Ribe  wrote:

> I saw your citations. You're ignoring the "Except as previously specified" 
> clause at the beginning of the sentence you quote. Null pointers converted to 
> int become 0; other pointers are implementation defined.

Please cite where the standard says null pointers become zero when converted to 
integer.

And then show how that jives with footnote 56, which says that the intent of 
the standard is that null pointers become whatever integer is most similar to 
the bit pattern used for null pointers, which may or may not be the same as 
that used for integer zero depending on the platform.

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

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

Re: NSColorWell - controlling opacity

[John Joyce]

> 
> 
> 
>> I use numerous colour wells all over my app. Mostly, I want the user to be 
>> able to use different alpha values, so I have enabled the opacity control 
>> for NSColorPanel globally for the app. But there are one or two places where 
>> I don't want that - these are associated with specific colour wells. 
>> 
>> I was surprised to find I couldn't set whether the color panel displayed the 
>> opacity slider depending on which colour well was selected. Can anyone think 
>> of a way I could achieve that? Seems to me that the color well/color panel 
>> communication is a totally closed book - I've already got various 
>> workarounds to overcome other issues with this communication, but with this 
>> one it's looking like I'm going to have to throw out NSColorWell and just do 
>> it myself from scratch. I thought frameworks were supposed to help, not 
>> hinder?
>> 
>> --Graham
>> ___
>> 
> Configure the panel with...
> setShowsAlpha: NO
> 
> 
NSColor itself also has 
setIgnoresAlpha:NO
To override when you don't have the panel configured. But of course the panel 
configuration is the more user-friendly approach. 


___

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: NSColorWell - controlling opacity

[John Joyce]

> I use numerous colour wells all over my app. Mostly, I want the user to be 
> able to use different alpha values, so I have enabled the opacity control for 
> NSColorPanel globally for the app. But there are one or two places where I 
> don't want that - these are associated with specific colour wells. 
> 
> I was surprised to find I couldn't set whether the color panel displayed the 
> opacity slider depending on which colour well was selected. Can anyone think 
> of a way I could achieve that? Seems to me that the color well/color panel 
> communication is a totally closed book - I've already got various workarounds 
> to overcome other issues with this communication, but with this one it's 
> looking like I'm going to have to throw out NSColorWell and just do it myself 
> from scratch. I thought frameworks were supposed to help, not hinder?
> 
> --Graham
> ___
> 
Configure the panel with...
setShowsAlpha: NO


___

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: [Obj-C] if (self) vs. if (self != nil)

[David Mirabito]

On 25/02/2012, at 2:29 PM, Scott Ribe wrote:

> On Feb 25, 2012, at 2:29 AM, David Mirabito wrote:
> 
>> Not terribly helpful since the cocoa headers are what they are, but in other 
>> codebases I sneak around issue this by setting up the defines:
>> 
>> #define FALSE 0
>> #define TRUE (!FALSE)
>> 
>> Then something like "if (mybool == TRUE)" acts as expected across all 
>> non-zero values. 
> 
> (!0) evaluates to 1.

Ha! Well there you go. I guess I just  saw that and accepted that it did what I 
looked like it was trying to do. Thanks for the correction.
That's my learned item for today, and sorry for the misinformation.

-David


___

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: [Obj-C] if (self) vs. if (self != nil)

[Scott Ribe]

On Feb 25, 2012, at 2:29 AM, David Mirabito wrote:

> Not terribly helpful since the cocoa headers are what they are, but in other 
> codebases I sneak around issue this by setting up the defines:
> 
> #define FALSE 0
> #define TRUE (!FALSE)
> 
> Then something like "if (mybool == TRUE)" acts as expected across all 
> non-zero values. 

(!0) evaluates to 1.

-- 
Scott Ribe
scott_r...@elevated-dev.com
http://www.elevated-dev.com/
(303) 722-0567 voice





___

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: [Obj-C] if (self) vs. if (self != nil)

[Scott Ribe]

On Feb 24, 2012, at 10:53 PM, Kyle Sluder wrote:

> On Feb 24, 2012, at 2:07 PM, Scott Ribe  wrote:
> 
>> On Feb 24, 2012, at 10:52 AM, Wade Tregaskis wrote:
>> 
>>> Though technically speaking it's true, and is thus an argument for actually 
>>> using NULL rather than 0
>> 
>> No, it's not such an argument at all. The compiler guarantees that null 
>> pointers converted to int become 0,
> 
> No it very much doesn't. See my citations.

I saw your citations. You're ignoring the "Except as previously specified" 
clause at the beginning of the sentence you quote. Null pointers converted to 
int become 0; other pointers are implementation defined.

-- 
Scott Ribe
scott_r...@elevated-dev.com
http://www.elevated-dev.com/
(303) 722-0567 voice





___

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

NSColorWell - controlling opacity

[Graham Cox]

I use numerous colour wells all over my app. Mostly, I want the user to be able 
to use different alpha values, so I have enabled the opacity control for 
NSColorPanel globally for the app. But there are one or two places where I 
don't want that - these are associated with specific colour wells. 

I was surprised to find I couldn't set whether the color panel displayed the 
opacity slider depending on which colour well was selected. Can anyone think of 
a way I could achieve that? Seems to me that the color well/color panel 
communication is a totally closed book - I've already got various workarounds 
to overcome other issues with this communication, but with this one it's 
looking like I'm going to have to throw out NSColorWell and just do it myself 
from scratch. I thought frameworks were supposed to help, not hinder?

--Graham
___

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

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

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

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

Re: NSFileWrapper Role

[Mike Abdullah]

As an added advantage on top of that it can avoid loading existing files into 
memory until needed. This is particularly handy when writing document packages 
as those files can be written quickly as hard links, rather than loading into 
memory and writing out afresh.

Sent from my iPad

On 25 Feb 2012, at 12:27 PM, Graham Cox  wrote:

> 
> On 25/02/2012, at 2:47 PM, -Sergei G- wrote:
> 
>> I don't quite get the role of NSFileWrapper. It appears to provide a subset 
>> of NSFileManager functionality.  Some of the Apple samples use NSFileWrapper 
>> to implement bundle support, but it is not clear if that's a requirement or 
>> just a choice of the developer.
>> 
>> Can someone elaborate beyond the official
>> The NSFileWrapper class provides access to the attributes and contents of 
>> file-system nodes. A file-system node is a file, directory, or symbolic 
>> link. Instances of this class are known as file wrappers.
> 
> 
> It allows you to represent a file that doesn't yet exist, even if it has a 
> complex structure. You can construct its contents at your leisure, then, it 
> can be written to a real file in one go.
> 
> --Graham
> 
> 
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/cocoadev%40mikeabdullah.net
> 
> This email sent to cocoa...@mikeabdullah.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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: NSFileWrapper Role

[Graham Cox]

On 25/02/2012, at 2:47 PM, -Sergei G- wrote:

> I don't quite get the role of NSFileWrapper. It appears to provide a subset 
> of NSFileManager functionality.  Some of the Apple samples use NSFileWrapper 
> to implement bundle support, but it is not clear if that's a requirement or 
> just a choice of the developer.
> 
> Can someone elaborate beyond the official
> The NSFileWrapper class provides access to the attributes and contents of 
> file-system nodes. A file-system node is a file, directory, or symbolic link. 
> Instances of this class are known as file wrappers.


It allows you to represent a file that doesn't yet exist, even if it has a 
complex structure. You can construct its contents at your leisure, then, it can 
be written to a real file in one go.

--Graham



___

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

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

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

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

Re: [Obj-C] if (self) vs. if (self != nil)

[David Mirabito]

Not terribly helpful since the cocoa headers are what they are, but in other 
codebases I sneak around issue this by setting up the defines:

#define FALSE 0
#define TRUE (!FALSE)

Then something like "if (mybool == TRUE)" acts as expected across all non-zero 
values. 

Also, IIRC, static analysis tools can enforce all boolean expressions in your 
code is a bolean logical operator or resolves to a 'typedef int mybool_t', but 
I'm less than convinced of the usefulness of this.

-DavidM


On 24/02/2012, at 8:36 PM, Sean McBride wrote:

> On Fri, 24 Feb 2012 10:36:51 -0700, Keary Suska said:
> 
>> I don't believe this is the case. There can be funny issues with BOOL
>> types, such that BOOL == YES is an inadvisable construct, since your
>> BOOL could be an integer of any value.
> 
> Indeed, and it's extremely frustrating.  I encourage you to file bugs on 
> this, or maybe add a comment here:
> 
> 
> 
> -- 
> 
> Sean McBride, B. Eng s...@rogue-research.com
> Rogue Researchwww.rogue-research.com 
> Mac Software Developer  Montréal, Québec, Canada
> 
> 
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/david.mirabito%40gmail.com
> 
> This email sent to david.mirab...@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: [Obj-C] if (self) vs. if (self != nil)

[James Montgomerie]

On 24 Feb 2012, at 20:36, Sean McBride  wrote:

> On Fri, 24 Feb 2012 10:36:51 -0700, Keary Suska said:
> 
>> I don't believe this is the case. There can be funny issues with BOOL
>> types, such that BOOL == YES is an inadvisable construct, since your
>> BOOL could be an integer of any value.
> 
> Indeed, and it's extremely frustrating.  I encourage you to file bugs on 
> this, or maybe add a comment here:
> 
> 

Danger!  The code in that bug report is unsafe in another unintended manner too.

BOOL isOK = someBitField & someFlag;

Is equivalent to

signed char isOK = (signed char)(someBitField & someFlag);

If someFlag is > 256, the bit that's left set after the '&' is executed will be 
truncated off by the assign converting down to 8 bits.

It's safer to do:
BOOL isOK = (someBitField & someFlag) == someFlag;

Or simply our controversial friend:
if(someBitField & someFlag);

Although I'd do:
if((someBitField & someFlag) == someFlag)

If only to silence compiler warnings about the naked single '&' in the if.

Slight tangent: I find the safest way, always, to approach 'if' is not to 
pretend that it's doing anything other than checking for non-zero values.  Once 
you accept that, lots of 'what's clearer' questions go away, because neither 
way is 'clearer', they're just more or less verbose.

Jamie.

[Apologies for formatting, edited on my phone.]
___

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: [Obj-C] if (self) vs. if (self != nil)

[Thomas Davie]

To me, it breaks one of my golden rules, and exposes one of the things I 
dislike about C.  Expressions, at least in my mind, should not involve state 
change – that's what statements are for.

My rationale behind this is that it makes it easier to read expressions – you 
get one more guarantee about what they're doing – they're computing a value, 
not changing some state behind your back.

This has a few implications for how I write code:
• I don't use the increment/decrement operators in expressions.
• I don't use the result value of assignments within expressions.
• Functions I try to keep as much as possible mathematical functions – they 
don't change state, they just return the result of a computation.
• If I need to return something from a subroutine that does change state, I 
tend to use a pointer argument rather than the result.

More specifically
• I don't use assignments in an if's condition, as below.

Bob
if (*ra4 != 0xffc78948) { return false; }

On 25 Feb 2012, at 01:12, Wade Tregaskis wrote:

>>   if(nil != (self = [super init]))
>> 
>> Myself I find it elegantly brief and imminently readable.
> 
> I don't mind it, but to me it begs the question of what it offers over:
> 
>   self = [super init];
>   if (self) {
> 
> My rationale is, generally you avoid assignments within conditionals because 
> it's just plain awkward.  The if (self = [super init]) pattern is a rare 
> exception, that is justified purely by convention at this point.  If you're 
> going to break that convention, and increase the verbosity to boot, you 
> should probably just revert to fundamentals - i.e. treat it like any other 
> assignment and test.
> ___
> 
> 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: [Obj-C] if (self) vs. if (self != nil)

[Quincey Morris]

On Feb 24, 2012, at 15:26 , Scott Ribe wrote:

> Thing is: if(foo) is equivalent to if(foo != 0), which I think results in 0 
> being treated as a pointer, not the pointer being cast to int, anyway if 
> if(foo) could fail, so could if(foo != 0)... Also I think "Except as 
> previously specified..." covers the case that NULL pointers convert to int 
> 0...

The following two source code patterns are *exactly* identical to the C 
compiler, *regardless of the type of 'foo'*:

1. if (foo)
2. if (foo != 0)

Additionally, if 'foo' is any kind of pointer, then a third pattern is 
*exactly* identical to the first two:

3. if (foo != (void*) 0)

In Obj-C, the following are *exactly* identical to the third one (again, 
assuming 'foo' is a pointer):

4. if (foo != nil)
5. if (foo != NULL)

Thus, there's absolutely no technical reason not to use all 5 of these 
interchangeably for pointers. It's just a question of coding preference 
(including putting the constant on the left of the operator, which was 
discussed earlier in the thread, making a total of 9 equivalent coding 
patterns).

These equivalences [under the restrictions stated above] have *nothing* to do 
with the internal bit-pattern representation of a null pointer. There are *no* 
implementation dependencies in any of them, assuming a compliant C compiler 
like GCC or clang.

The *only* place where the internal bit-pattern matters, and where there might 
be implementation dependent behavior, is source code where a pointer 
sub-expression is mixed with a non-constant-evaluating-to-zero arithmetic 
sub-expression. So all of this angst is wasted effort. :)


___

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: [Obj-C] if (self) vs. if (self != nil)

[Kyle Sluder]

On Feb 24, 2012, at 2:07 PM, Scott Ribe  wrote:

> On Feb 24, 2012, at 10:52 AM, Wade Tregaskis wrote:
> 
>> Though technically speaking it's true, and is thus an argument for actually 
>> using NULL rather than 0
> 
> No, it's not such an argument at all. The compiler guarantees that null 
> pointers converted to int become 0,

No it very much doesn't. See my citations.

> that constant 0 assigned to a pointer makes it null,

This is true, but emphasis on the "constant." Assigning a non-constant integer 
expression to a pointer is implementation-defined, regardless of the value of 
the integer expression.

> and that null pointer compared to 0 is true

Again, this is dependent on context. Hence the doubt I expressed in my initial 
post. There is no direct comparison defined between pointer types and integers.

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

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

[Moderator] List is apparently slow relaying messages

[Scott Anguish]

I’ve heard from various subscribers that the list is a slow in propagating 
messages.

I believe this is indicative of the number of subscribers at this point. I’ll 
let the powers that be know and see what might be done.

In the meantime, cc the poster and they’ll get the answer right away. the list 
will be the ongoing archive and public view. But I will look into it.

Moderator *scott=[[Moderator alloc] init];
___

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

NSFileWrapper Role

[-Sergei G-]

I don't quite get the role of NSFileWrapper. It appears to provide a subset of 
NSFileManager functionality.  Some of the Apple samples use NSFileWrapper to 
implement bundle support, but it is not clear if that's a requirement or just a 
choice of the developer.

Can someone elaborate beyond the official
The NSFileWrapper class provides access to the attributes and contents of 
file-system nodes. A file-system node is a file, directory, or symbolic link. 
Instances of this class are known as file wrappers.

Thanks
___

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: iCal Integration

[John Maisey]

I also don't think this is in the API. 

The relevant information is stored in the Info.plist file for each calendar. 
The keys are 'EventContainer' and 'TaskContainer', both boolean.

Best wishes

John Maisey

www.nhoj.co.uk
www.twitter.com/johnmaisey
www.facebook.com/nhojcouk





On 23 Feb 2012, at 23:04, cocoa-dev-requ...@lists.apple.com wrote:

> Message: 10
> Date: Fri, 24 Feb 2012 08:49:33 +1000
> From: Gideon King 
> To: Jeremy Matthews 
> Cc: list-cocoa-dev Development 
> Subject: Re: iCal Integration
> Message-ID: <4ad9e40b-977e-4901-a1cb-a068efd8f...@novamind.com>
> Content-Type: text/plain; charset=windows-1252
> 
> I don't see anything in the API to detect it - I have encountered calendars 
> that don't support tasks, and if I try to save a task to them, I get an error 
> with code 1025 (CalCalendarNotEditableError), and deal with that in my code. 
> 
> isEditable returns YES for a calendar which only supports events, so you 
> still have to try to save a task to it before you know it won't store tasks.
> 
> I haven't come across one that can't save events yet. Do you know what error 
> code you get back when you try to save an event to a calendar which doesn't 
> support events? I'm assuming it's the same code?
> 
> I haven't looked at the "type" property to see if the values there bear any 
> relationship to what can be saved to it, but that seems like the only other 
> property that could potentially be relevant…
> 
> 
> HTH
> 
> Gideon
> 
> 
> On 23/02/2012, at 1:19 PM, Jeremy Matthews wrote:
> 
>> I have a simple app which, as a byproduct, creates tasks and events in iCal. 
>> Prior to 10.7, the user would choose from a popup list populated by all 
>> calendars within the [CalCalendarStore defaultstore], which worked great and 
>> created both events and tasks perfectly fine.
>> 
>> Now, in 10.7, it seems as if a CalDAV (alal iCloud) or Exchange calendar is 
>> separated into two separate objects - one for events and one for tasks, and 
>> the result is the user is shown a list of calendars...and in many cases 
>> users appear to see duplicates, when in reality there are those two separate 
>> "calendars".
>> 
>> So now, when a user selects the calendar, they might get an event created, 
>> but not tasks, and vice-versa. 
>> 
>> Is there any known way of dealing with this, or any way to easily find out 
>> which "calendar" supports events vs tasks, instead of firing off a "test" 
>> tasks and finding out the hard way? Or perhaps, a better solution altogether?
>> 
>> Thanks,
>> jeremy
> 


___

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: text field question

[Rick C.]

Great thanks everyone I think I got it! :-)

rc



On Feb 25, 2012, at 12:06 AM, Kyle Sluder wrote:

> On Feb 23, 2012, at 5:38 PM, "Rick C."  wrote:
> 
>> Thanks Jan.  What method do you call to make it accept the text?  That's 
>> maybe what I'm looking for...
> 
> As I mentioned before, and is explained in the documentation, you use 
> -[NSWindow makeFirstResponder:] or -[NSObject(NSEditor) commitEditing].
> 
> --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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: [Obj-C] if (self) vs. if (self != nil)

[Scott Ribe]

On Feb 24, 2012, at 1:08 PM, Nick Zitzmann wrote:

>> I also heard that generally speaking NULL is not necessarily always
>> equal to 0 on all architectures.
>> 
>> Thoughts?
> 
> Where in the world did you hear that? From the C99 standard, 6.3.2.3 
> paragraph 3:
> 
> "An integer constant expression with the value 0, or such an expression cast 
> to type void *, is called a null pointer constant. If a null pointer constant 
> is converted to a pointer type, the resulting pointer, called a null pointer, 
> is guaranteed to compare unequal to a pointer to any object or function."
> 
> I suppose some compilers can ignore the standard and do their own thing, but 
> the compilers that come with Xcode are pretty good with standards compliance.

People just get confused by the point that the "null" or "illegal" pointer 
value is not all 0 bits on all architectures, but C makes reasonable efforts to 
treat NULL pointers and 0 as equivalent, regardless of what the underlying 
value might be, and this equivalence is transparent in most common cases. The 
word "null" is overloaded, so some people read the warning about the underlying 
bit representation of a null pointer, and confuse that with the representation 
at the source code level. 

The only places where they're not completely equivalent (in other words not 
equivalent on weird old architectures) have to do with things like 
converting/comparing non-constant integers to pointers, where a 0 becomes all 
0s regardless of what the null pointer is (which cases are the reason the 
warning about non-0 null pointers cannot be removed)... Basically, mixing 
pointers and constant integer 0 expressions to represent NULL works in all 
expressions on all architectures for all time (ahem, assuming you declare 
functions new style--if you pass an integer constant to a function that takes a 
pointer but does not have a declaration visible, on an architecture where where 
an int is smaller than the pointer, well you deserve what you get for turning 
off or ignoring compiler warnings in order to use an ancient obsolete style 
without understanding how to use that style).

-- 
Scott Ribe
scott_r...@elevated-dev.com
http://www.elevated-dev.com/
(303) 722-0567 voice





___

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: [Obj-C] if (self) vs. if (self != nil)

[Wade Tregaskis]

>if(nil != (self = [super init]))
> 
> Myself I find it elegantly brief and imminently readable.

I don't mind it, but to me it begs the question of what it offers over:

self = [super init];
if (self) {

My rationale is, generally you avoid assignments within conditionals because 
it's just plain awkward.  The if (self = [super init]) pattern is a rare 
exception, that is justified purely by convention at this point.  If you're 
going to break that convention, and increase the verbosity to boot, you should 
probably just revert to fundamentals - i.e. treat it like any other assignment 
and test.
___

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