Re: Proper way to set up constants when building an iOS framework

[Uli Kusterer]

On 12 Apr 2016, at 19:30, Alex Zavatone  wrote:
> On Apr 12, 2016, at 12:43 PM, Charles Jenkins wrote:
> 
>> I imagine you’re already doing this, but your message wasn’t clear, so 
>> forgive me if I sound patronizing.
>> 
>> The constants should be declared extern in the header file, but not assigned 
>> any values. The value assignments should appear inside a single .m file in 
>> your framework.
> 
> I am not doing that.  But it's what I'm going to be doing now.
> 
> So, define them like this:
> 
> SecurityDefaults.h
> 
> extern NSString * const ABC_MY_IMPORTANT_CONSTANT;

NB - Just to save you some pain in the future, this is called a "declaration", 
not a definition. It is like a function or method prototype. It just tells the 
compiler "trust me, when it comes time to linking, there will be a variable 
with this name and type". The "definition" is what you then write in the .m 
file, and is the one, canonical definition of your constant.

Also, if this is a Cocoa project, I recommend you stick to the AppKit 
convention and use neither all-upercase nor the 'k' prefix, and instead just 
use inter-caps and your prefix. Like 
NSApplicationDidFinishLaunchingNotificationName. Less surprise for new people 
coming on the project that way.

Alex wrote:
> One thing though.  I did do a #import of "Constants.h" into my framework's 
> header file and that's not filling the role of what a .pch would fill in a 
> standalone app, even though I thought that someone said it would.

 A precompiled prefix header is a compile-time construct that only applies to 
the interior of your framework. You can't really tell people linking to your 
framework to add a certain prefix header. So you can use a pch for actually 
writing the framework implementation, but have to be careful to not require 
that someone has a certain PCH in the headers that you expose via your 
framework's headers folder (copied by the build phase). However, since clients 
usually #import your framework's umbrella header anyway, you could just put all 
important includes into the umbrella header (or headers included by your 
umbrella header) and then put your umbrella header into your framework's PCH. 
That way, you can write code without having to manually include stuff and any 
client gets the same combination of headers. If they want, they can then put 
the framework include into *their* PCH (i.e. usually the host app's).

 That said, having everything in your prefix header invites people to add 
dependencies to their code across all module boundaries, so I would recommend 
manually including only the very headers the code in a particular location 
needs. It's a bit more typing, but it makes for more honest code, as modules 
who acquire too many includes are immediately visible and invite you to split 
them up or re-arrange them, that way restoring loose coupling and making your 
code more maintainable, and more reusable.

Alex wrote:
> If I put the #import there, the app immediately gets build errors.
> 
> Am I missing something on where I should import the constants' header?

Do you have a "Copy Headers" build phase to copy your headers into the built 
product's package?

You may also want to read up on the C concept of "compilation units". Basically 
it means that (Objective)C(++) can only compile source files, not headers. So 
what it does is it goes through the list of sources in your project, compile 
each separately by taking a copy of it, replacing all #include and #import 
statements with the contents of the corresponding header file, and then taking 
that one huge source file and compiling it, making a note of all symbols it 
defines.

This means for one that including an ObjC header from a C file loses the 
information that this header was ObjC, as it all gets "pasted" into the .c file 
currently being compiled. So if your header gets included by a different 
language source file, you'll get all sorts of funny errors because the C 
compiler does not understand what '@interface' means etc. This could be one 
reason for the errors you're getting.

Charles wrote:
> Also, because of my C++ background, I’d see if the compiler would accept 
> NSString const * const, because you want a constant pointer to an NSString 
> that is constant; but I recognize that may not be the way things are done in 
> Obj-C.

Yeah, while in general that would be true, there currently is no such thing as 
a NSString const as far as the ObjC compiler is concerned. ObjC's constants are 
still sort of a runtime construct ... in some ways, AFAIR. 

Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
http://stacksmith.org





___

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

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

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

Creating a series of sequenced files

[Carl Hoefs]

I have a daemon process that needs to generate a series of sequenced files 
(named sequentially, such as "file_01944576_1.dat", "file_01944576_2.dat", 
etc.) in the same directory. Does Cocoa provide a way to do this?

NSFileManager's -createFileAtPath:contents:attributes: method states:
 "If a file already exists at path, this method overwrites the contents of that 
file..."

I would hate to do this blindly, such as with fstat() in a loop, because there 
will potentially be many sequences, and each can grow to an arbitrary number. 
How do Finder and other OS X agents accomplish this?
-Carl


___

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: Creating a series of sequenced files

[Alex Zavatone]

The easy route is to use the file manager to see if the filename exists, then 
use NSString to separate the file name from the file extension, then use a 
string method creating an NSArray from the file name with items separated by 
the underscore, then take the last item in the array as an NSUinteger, 
increment by 1, make a new file name and if that file doesn’t exist, increment 
it by 1, keep doing that until it finds a file that hasn’t yet been created and 
then write the file.

On Apr 16, 2016, at 5:36 PM, Carl Hoefs  wrote:

> I have a daemon process that needs to generate a series of sequenced files 
> (named sequentially, such as "file_01944576_1.dat", "file_01944576_2.dat", 
> etc.) in the same directory. Does Cocoa provide a way to do this?
> 
> NSFileManager's -createFileAtPath:contents:attributes: method states:
> "If a file already exists at path, this method overwrites the contents of 
> that file..."
> 
> I would hate to do this blindly, such as with fstat() in a loop, because 
> there will potentially be many sequences, and each can grow to an arbitrary 
> number. How do Finder and other OS X agents accomplish this?
> -Carl
> 
> 
> ___
> 
> 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/zav%40mac.com
> 
> This email sent to z...@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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Creating a series of sequenced files

[Quincey Morris]

On Apr 16, 2016, at 14:36 , Carl Hoefs  wrote:
> 
> I have a daemon process that needs to generate a series of sequenced files 
> (named sequentially, such as "file_01944576_1.dat", "file_01944576_2.dat", 
> etc.) in the same directory. Does Cocoa provide a way to do this?

Not that I know of. But surely it’s only 2 lines of code, apart from error 
checking and recovery?

> NSFileManager's -createFileAtPath:contents:attributes: method states:
> "If a file already exists at path, this method overwrites the contents of 
> that file…"

Do not use this method: it’s obsolete. Use NSData.writeToURL:options: instead, 
with the NSDataWritingWithoutOverwriting option.

> I would hate to do this blindly, such as with fstat() in a loop, because 
> there will potentially be many sequences, and each can grow to an arbitrary 
> number. How do Finder and other OS X agents accomplish this?

Blindly in what sense? Even you have a lot of files, those are the files you 
want. There’s nothing inherently dangerous in creating them. If you mean, 
because of the possibility of conflicts with existing files, you should follow 
the normal best practices inside your ‘writeToFile’ loop:

— (Optional) Preflight the loop to ensure that conflicting files don’t exist. 
This is only an approximate safety measure, since conflicting files can be 
created after you check, but provides a better user experience if there is some 
reasonable expectation of conflict.

— Detect any actual conflict by the failure of ‘writeToFile’ and offer user 
recovery options at that 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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Creating a series of sequenced files

[Carl Hoefs]

> Not that I know of. But surely it’s only 2 lines of code, apart from error 
> checking and recovery?


I'd love to see those 2 lines of code! :-)

But I'm concerned mainly with efficiency, as determining the next number in the 
naming sequence potentially can be extremely inefficient - trying 1000s of 
times until the next available number every time a new file needs to be 
written, and also every time the latest-written file needs to be retrieved. 

But I'm hearing this is the only way?
-Carl


> On Apr 16, 2016, at 2:58 PM, Quincey Morris 
>  wrote:
> 
> On Apr 16, 2016, at 14:36 , Carl Hoefs  > wrote:
>> 
>> I have a daemon process that needs to generate a series of sequenced files 
>> (named sequentially, such as "file_01944576_1.dat", "file_01944576_2.dat", 
>> etc.) in the same directory. Does Cocoa provide a way to do this?
> 
> Not that I know of. But surely it’s only 2 lines of code, apart from error 
> checking and recovery?
> 
>> NSFileManager's -createFileAtPath:contents:attributes: method states:
>> "If a file already exists at path, this method overwrites the contents of 
>> that file…"
> 
> Do not use this method: it’s obsolete. Use NSData.writeToURL:options: 
> instead, with the NSDataWritingWithoutOverwriting option.
> 
>> I would hate to do this blindly, such as with fstat() in a loop, because 
>> there will potentially be many sequences, and each can grow to an arbitrary 
>> number. How do Finder and other OS X agents accomplish this?
> 
> Blindly in what sense? Even you have a lot of files, those are the files you 
> want. There’s nothing inherently dangerous in creating them. If you mean, 
> because of the possibility of conflicts with existing files, you should 
> follow the normal best practices inside your ‘writeToFile’ loop:
> 
> — (Optional) Preflight the loop to ensure that conflicting files don’t exist. 
> This is only an approximate safety measure, since conflicting files can be 
> created after you check, but provides a better user experience if there is 
> some reasonable expectation of conflict.
> 
> — Detect any actual conflict by the failure of ‘writeToFile’ and offer user 
> recovery options at that 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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Creating a series of sequenced files

[Quincey Morris]

On Apr 16, 2016, at 14:36 , Carl Hoefs  wrote:
> 
> I have a daemon process that needs to generate a series of sequenced files

Oh, sorry, I think I misunderstood the question. I thought you wanted to 
generate all the files at once. Alex’s interpretation sounds more plausible.

If you’re looking to *resume* creating files at the end of an existing 
sequence, I would just do the simplest thing:

1. When your process starts, initialize a “nextInSequence” number to 0 or 1.

2. When you need to create a new file, construct its name using the 
“nextInSequence” variable, and increment it.

3. Try creating a new file with that name. If it fails due to conflict with an 
existing file, repeat step 2.

Anything “cleverer” that tries to find the last-used sequence is subject to 
race conditions, and multiple iterations of step 2 (to get past the files you 
previously created) aren’t going to take long. Still, I’d suggest you set a 
hard limit (e.g. 1000 attempts) on iterations, and if you hit the limit, tell 
the user to remove or otherwise deal with old files. The idea is that if old 
files are building up without limit, something needs to be done with them 
anyway, so you may as well be proactive about it.

___

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: Creating a series of sequenced files

[Quincey Morris]

On Apr 16, 2016, at 15:10 , Carl Hoefs  wrote:
> 
> But I'm concerned mainly with efficiency, as determining the next number in 
> the naming sequence potentially can be extremely inefficient - trying 1000s 
> of times until the next available number every time a new file needs to be 
> written, and also every time the latest-written file needs to be retrieved. 

If you really need to examine the existing files, then I suggest you start your 
process with a one-time directory enumeration, and find the file that you 
regard as "last". However I foresee that there are actually two things you 
might want to find:

1. The next sequence number to use.

2. The most recently-written file.

There’s really nothing you can do to guarantee that these are the same, in all 
scenarios, so you may as well treat them as separate results.

This would only get complicated if there’s another process creating files in 
your sequence. Otherwise an initial directory enumeration will get you sync-ed 
up, and after that you can just do the simple nextInSequence-incrementing thing.

___

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: Creating a series of sequenced files

[Carl Hoefs]

> On Apr 16, 2016, at 3:20 PM, Quincey Morris 
>  wrote:
> 
> On Apr 16, 2016, at 15:10 , Carl Hoefs  > wrote:
>> 
>> But I'm concerned mainly with efficiency, as determining the next number in 
>> the naming sequence potentially can be extremely inefficient - trying 1000s 
>> of times until the next available number every time a new file needs to be 
>> written, and also every time the latest-written file needs to be retrieved. 
> 
> If you really need to examine the existing files, then I suggest you start 
> your process with a one-time directory enumeration, and find the file that 
> you regard as "last". However I foresee that there are actually two things 
> you might want to find:
> 
> 1. The next sequence number to use.
> 
> 2. The most recently-written file.
> 
> There’s really nothing you can do to guarantee that these are the same, in 
> all scenarios, so you may as well treat them as separate results.
> 
> This would only get complicated if there’s another process creating files in 
> your sequence. Otherwise an initial directory enumeration will get you 
> sync-ed up, and after that you can just do the simple 
> nextInSequence-incrementing thing.
> 


For a single sequence, it wouldn't be so bad, but I have potentially n 
different ongoing sequences, so it seems like this approach could end up 
hitting the filesystem really hard. I'll code it up and see how inefficient it 
becomes. 
-Carl

___

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: Creating a series of sequenced files

[Quincey Morris]

On Apr 16, 2016, at 15:29 , Carl Hoefs  wrote:
> 
> I have potentially n different ongoing sequences, so it seems like this 
> approach could end up hitting the filesystem really hard


One enumeration per candidate directory shouldn’t be inefficient. That’s the 
order of magnitude of what the Finder does to open a window.

If necessary, you can do a single directory enumeration hierarchically from the 
common ancestor directory of all the files, skipping subdirectories that don’t 
contain possible sequences. That’s the minimum setup you can do, if the 
per-enumeration setup is too expensive.
___

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

SASL on OS X

[Daryle Walker]

I found out that SASL, through the CMU Cyrus library, is on OS X. Is there a 
high-level API, like the Keychain, that wraps it?  Or do I have to use the 
UNIX-level functions to use SASL in my Cocoa apps?

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT 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: Creating a series of sequenced files

[Jens Alfke]

> On Apr 16, 2016, at 2:56 PM, Alex Zavatone  wrote:
> 
> The easy route is to use the file manager to see if the filename exists, then 
> […] keep doing that until it finds a file that hasn’t yet been created and 
> then write the file.

This is generally considered a bad approach, because it’s subject to race 
conditions: aanother process might create the file after you determine that it 
doesn’t exist yet, but before you open it. This will at the least cause 
unexpected failures, but at worst it can be (and has been) abused for security 
exploits — if a process running as root has this bug, it can be abused to gain 
root privileges.

The right way to do this is to try to open the file with the current filename, 
but using a mode that will fail if the file already exists. If it fails, you 
increment the filename and try again. In the Unix `open` system call you’d use 
mode O_CREAT | O_EXCL. You can also use `fopen` with mode “wx”, but the man 
page says this is not part of the C standard. I’m not sure how to do this using 
NSData, but it sounds as though NSDataWritingWithoutOverwriting would be the 
right flag to use.


> On Apr 16, 2016, at 2:36 PM, Carl Hoefs  
> wrote:
> 
> I would hate to do this blindly, such as with fstat() in a loop, because 
> there will potentially be many sequences, and each can grow to an arbitrary 
> number. How do Finder and other OS X agents accomplish this?


You mean like how every time you duplicate a file in the Finder it appends 
“copy _n_” to the name? I’d be surprised if the Finder wasn’t doing this by 
just looping and retrying. You’d have to have an awfully long sequence of 
copies (thousands? Tens of thousands?) for this to start being noticeably slow.

If performance really is a problem, it’s probably best to enumerate the 
directory and find the highest existing filename with that pattern, then start 
your loop at the next filename.

—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

Can a table insert be implemented with an exclusive "addition row"?

[Daryle Walker]

I haven’t done this; I’m just wondering if it’s possible.

Imagine a NSTableView with an extra row at the bottom.  (If there are no 
records, the extra row would be the table’s sole row.)  One of the columns has 
a grey-out string of “Add new name…” or something similar.  If the user 
confirms new text in that cell, the row will become a real one in the table (in 
the last position) and a new extra row will appear below it ready for new 
input.  (If the row was at the bottom of the view, the view will scroll the new 
extra row up into visibility.)  It seems like a cooler alternative to having a 
“+” button lying around somewhere in the window.  But would implementing it 
require too many heroic measures over using a button?

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT 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

Asynchronous compatibility of NSDocument read/write methods

[Daryle Walker]

The NSDocument class has some core methods for you to override to read and 
write data from/to disk.  Are those called from the main thread?  If so, can 
you defer the actual work to an NSOperation or something?  If you do so, what 
is your GUI supposed to do/show?  Or will the window not be shown yet?

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT 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

Does NSString's "- initWithContentsOfURL:usedEncoding:error:" use the tightest encoding possible?

[Daryle Walker]

If the given method is used to read in a pure ASCII file, will the encoding be 
set to ASCII?  Or could the method return a superset encoding (like Latin-1, 
MacRoman, or UTF-8)?

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT 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: Does NSString's "- initWithContentsOfURL:usedEncoding:error:" use the tightest encoding possible?

[Jens Alfke]

> On Apr 16, 2016, at 7:35 PM, Daryle Walker  wrote:
> 
> If the given method is used to read in a pure ASCII file, will the encoding 
> be set to ASCII?  Or could the method return a superset encoding (like 
> Latin-1, MacRoman, or UTF-8)?

I don’t know; you could try it out, of course, but it sounds like the sort of 
undefined behavior you shouldn’t rely on.

If you’re trying to determine if the string is pure ASCII, you can use 
-rangeOfCharactersInSet: to look for anything above 127.

—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