Hello Ali,
thanks for the response.
As far as I understand, NSWindowRestoration.h is available only for Lion's
AppKit.
What could I do for Snow Leopard?
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderat
Putting this info in the document (whether or not it's in the actual document
itself, or as an extended attribute) is not ideal, since it bakes in the
display settings of the last person to view/edit that document. If I send you
that document, you should either see it in its default state, or wi
On Sep 21, 2011, at 4:34 PM, Nick wrote:
> Should I store this information in some HFS's 'file fork'? Or is it better
> to create a "shadow file" for every document that keeps this metainformation
> (wouldn't like to do so, i keep that as the last resort).
As I recall TextWrangler/BBEdit are able
On Sep 21, 2011, at 13:34 , Nick wrote:
> I am trying to implement some kind of "memory" for the documents in my
> application. For example, each document window has a position on the
> screen. So I'd like to see this position next time the user opens this saved
> document.
This is normally and
Hello
I am trying to implement some kind of "memory" for the documents in my
application. For example, each document window has a position on the
screen. So I'd like to see this position next time the user opens this saved
document.
I can't save this info in the document file itself, as documents
On Tue, 25 Jan 2011 02:17:46 -0800, Kyle Sluder said:
>For something more complicated, a simple XML format might be appropriate:
>
>
>The quick fox jumped over the lazy type="noun" />
>
>
>Especially if you want to share the resulting madlib with other
>people, who might then want to reuse the sa
On Tue, Jan 25, 2011 at 1:56 AM, Matt Neuburg wrote:
> This is madlibs; the template string comes from him, the programmer. Only the
> words that go into the blanks come from the user. You'll need to prove to me
> that performing the substitution this way is any more dangerous than
> substituti
On Jan 24, 2011, at 6:54 PM, Kyle Sluder wrote:
> On Jan 24, 2011, at 6:02 PM, Matt Neuburg wrote:
>
>>
>> (2) A common trick is make the text file a format string (i.e., containing a
>> lot of %@) and just hand it to stringWithFormat along with all the
>> s
On Jan 24, 2011, at 6:02 PM, Matt Neuburg wrote:
>
> (2) A common trick is make the text file a format string (i.e., containing a
> lot of %@) and just hand it to stringWithFormat along with all the
> substitutions. Badda bing badda boom.
This is how security vulnerabilities a
On Jan 22, 2011, at 9:37 AM, cocoa-dev-requ...@lists.apple.com wrote:
> Date: Sat, 22 Jan 2011 09:19:50 -0500
> From: Jeremy Matthews
> Subject: lots of find/replace in text file
>
> So...the app I previously mentioned, ala Mad Libs...I now have lots more text
> to repla
e a
> better way, to perform a slew of find/place operations with a text file?
>
> So far, I have an array of strings (placeholders) which get replaced by an
> array of user-determined values, and the resulting mishmash gets spewed into
> a file.
>
> I can't help but thin
Jeremy Matthews wrote:
I can't help but think there might be a better (and more efficient
way) of handling this?
How much better (and more efficient) does it have to be?
It's a simple game, right? Is it currently too slow or memory-
consuming? If not, why change it?
If you want a diffe
ith a text file?
So far, I have an array of strings (placeholders) which get replaced by an
array of user-determined values, and the resulting mishmash gets spewed into a
file.
I can't help but think there might be a better (and more efficient way) of
handling this?
Thanks,
j
smime.p7s
Desc
Thanks ... It worked (/Volumes/{name of disk as it appears in the Finder}
)RegardsAbhijeet Original message From:"Nick Zitzmann"< n...@chronosnet.com
>Date: 14 Dec 10 12:38:27Subject: Re: How to read a text file over a networkTo:
Cc: cocoa...@lists.apple.comon Dec 13, 2
using an NSUrl.
It sounds like you might have an easier time using a plist. Cocoa has good
support for parsing and simplifying access using NSDictionary.
On Dec 13, 2010, at 4:54 AM, Abhijeet Singh wrote:
> Hi,I am new to Mac. In my application I have to read a text file (say
> file1.
On Dec 13, 2010, at 10:12 PM, Abhijeet Singh wrote:
> I think the type of server is AFP. Because the file path displayed by Finder
> is: afp://PriyankaMac._afpovertcp._tcp.local/shared/file1.txt.
> But if i put the same file path in my file2.txt my program fails to open
> file1.txt file.
That'
n"< n...@chronosnet.com >Date: 13
Dec 10 21:45:28Subject: Re: How to read a text file over a networkTo: Cc:
cocoa...@lists.apple.comon Dec 13, 2010, at 5:54 AM, Abhijeet Singh wrote:>
Hi,I am new to Mac. In my application I have to read a text file (say
file1.txt) from a user defined location/path
On 13 Dec 2010, at 4:54 AM, Abhijeet Singh wrote:
> My question is if user wants to define some network file path then:How to
> define a network file path? (I tried keeping file1.txt over a network and
> define its path as given in "Get Info" panel in file2.txt)How to read a file
> over a netw
On Dec 13, 2010, at 5:54 AM, Abhijeet Singh wrote:
> Hi,I am new to Mac. In my application I have to read a text file (say
> file1.txt) from a user defined location/path. User defines this filepath in
> another text file (say file2.txt). My program first reads file2.txt and gets
>
Hi,I am new to Mac. In my application I have to read a text file (say
file1.txt) from a user defined location/path. User defines this filepath in
another text file (say file2.txt). My program first reads file2.txt and gets
the path of file1.txt from there. file2.txt always exists on my machine
That's a good idea, thank you! :)
On Sun, Apr 18, 2010 at 12:41 PM, Jens Alfke wrote:
>
> On Apr 18, 2010, at 12:40 AM, Henrietta Read wrote:
>
> > exactly the point germane, but in perusing NSString.h one is given to
> understand this method might not be as 'smart' as one could wish:
>
> I w
On Apr 18, 2010, at 12:40 AM, Henrietta Read wrote:
> exactly the point germane, but in perusing NSString.h one is given to
> understand this method might not be as 'smart' as one could wish:
I wouldn’t think it would fail with MacRoman, though. Did you check the output
NSError? Also, try insp
On Apr 18, 2010, at 3:40 AM, Henrietta Read wrote:
>>>
>>> This leaves the question of why -stringWithContentsOfFile: would fail.
> I'm not sure what heuristics that call uses, but you'd think it would be
> able to handle MacRoman, obsolete though it is.
In general, it is. For example, I just c
>> The call to -stringWithContentsOfFile: looks correct, but you're failing
to check for errors. If it fails, it will return nil, and passing nil to
setString: is illegal and will throw an exception.
right, right... most correct. I can catch the nil.
>> This leaves the question of why -stringWith
Hi,
> 0x91dc507e <+0334> call 0x91e68a50
> 0x91dc5083 <+0339> mov%esi,(%esp)
> 0x91dc5086 <+0342> call 0x91ebf566
> 0x91dc508b <+0347> lea-0x80(%ebp),%esi
> 0x91dc508e <+0350> mov%esi,(%esp)
> 0x91dc5091 <+0353> call 0x91ebfb36
> 0x91dc5096 <+0358> mov%esi,(%
On Apr 15, 2010, at 8:50 AM, Henrietta Read wrote:
> What's the correct way to open a text file? I'm using:
>
> NSError *error = nil;
> NSStringEncoding encoding;
>
> [myMutableString setString:[NSString stringWithContentsOfFile:filePath
> usedEncoding:&am
On Apr 15, 2010, at 8:50 AM, Henrietta Read wrote:
NSError *error = nil;
NSStringEncoding encoding;
[myMutableString setString:[NSString
stringWithContentsOfFile:filePath
usedEncoding:&encoding error:&error]];
The call to -stringWithContentsOfFile: looks correct, but you're
failin
Hi,
What's the correct way to open a text file? I'm using:
NSError *error = nil;
NSStringEncoding encoding;
[myMutableString setString:[NSString stringWithContentsOfFile:filePath
usedEncoding:&encoding error:&error]];
but on some files (say, Western Mac OS
On Aug 17, 2009, at 7:57 PM, Alex Kac wrote:
I'm sure there is a great way to do this, but I seem to not find it.
I have a potentially large text file that I wish to only show the
last 32k worth - it could be 200MB. So I was looking at
NSInputStream, but perhaps I'm being dense
I'm sure there is a great way to do this, but I seem to not find it. I
have a potentially large text file that I wish to only show the last
32k worth - it could be 200MB. So I was looking at NSInputStream, but
perhaps I'm being dense or its the wrong tool for the job, but I
can
On Sun, Feb 8, 2009 at 2:44 AM, Joar Wingfors wrote:
>
> On Feb 7, 2009, at 7:13 PM, Michael Ash wrote:
>
>>> What's wrong is that they won't allow you to specify the text encoding to
>>> use. The same thing is true for the *deprecated* method
>>> "+stringWithCString:" by the way.
>>
>> That is in
On Feb 7, 2009, at 7:13 PM, Michael Ash wrote:
What's wrong is that they won't allow you to specify the text
encoding to
use. The same thing is true for the *deprecated* method
"+stringWithCString:" by the way.
That is incorrect.
I don't think that what I said is incorrect, at least not
On Sat, Feb 7, 2009 at 12:46 PM, Joar Wingfors wrote:
>
> On Feb 7, 2009, at 6:55 AM, Steve Sisak wrote:
>
>> Umm, unless I'm totally missing something, what's wrong with fopen() and
>> fgets(), possibly followed with [NSString stringWithCString] on each line?
>
>
> What's wrong is that they won't
On Sat, Feb 7, 2009 at 10:27 AM, Steve Sisak wrote:
> At 9:46 AM -0800 2/7/09, Joar Wingfors wrote:
>>
>> On Feb 7, 2009, at 6:55 AM, Steve Sisak wrote:
>>>
>>> Umm, unless I'm totally missing something, what's wrong with fopen() and
>>> fgets(), possibly followed with [NSString stringWithCString]
At 9:46 AM -0800 2/7/09, Joar Wingfors wrote:
On Feb 7, 2009, at 6:55 AM, Steve Sisak wrote:
Umm, unless I'm totally missing something, what's wrong with
fopen() and fgets(), possibly followed with [NSString
stringWithCString] on each line?
What's wrong is that they won't allow you to specify
On Feb 7, 2009, at 6:55 AM, Steve Sisak wrote:
Umm, unless I'm totally missing something, what's wrong with fopen()
and fgets(), possibly followed with [NSString stringWithCString] on
each line?
What's wrong is that they won't allow you to specify the text encoding
to use. The same thin
At 1:38 PM +1100 2/3/09, Jacob Rhoden wrote:
On 3/02/2009 8:41 AM, Kenneth Bruno II wrote:
I am wondering what the best way to read a text file, line by
line, when the file size is much larger than available memory.
For very large files you probably want to use NSFileHandle. With
the method
On Sat, Feb 7, 2009 at 7:57 AM, René v Amerongen wrote:
>>
>>
>> Thus the warning: if a file disappears while you have it memory
>> mapped, and you try to access it, you will crash.
>>
>
> Does this mean that we should check every time the existence of the file
> before we try to read anything fro
Thus the warning: if a file disappears while you have it memory
mapped, and you try to access it, you will crash.
Does this mean that we should check every time the existence of the
file before we try to read anything from the memory mapped file?
RvA
_
On Sat, Feb 7, 2009 at 12:39 AM, Clark Cox wrote:
> Even if you delete the file from the filesystem, you are just deleting
> the mapping from that particular filename to the file's actual data.
> The actual "file" still there until the last process with an open
> handle closes it, so open()'ing a
On 7 Feb 2009, at 05:39, Clark Cox wrote:
On Fri, Feb 6, 2009 at 9:30 PM, Sean McBride wrote:
Joar Wingfors (j...@joar.com) on 2009-02-06 12:06 AM said:
How can you guarantee a file's existence? sudo rm -f?
How about calling open() on it?
:) But note the latter part of the sentence: "
On Fri, Feb 6, 2009 at 9:30 PM, Sean McBride wrote:
> Joar Wingfors (j...@joar.com) on 2009-02-06 12:06 AM said:
>
>>> How can you guarantee a file's existence? sudo rm -f?
>>
>>How about calling open() on it?
>
> :) But note the latter part of the sentence: "this method should only
> be used if
Joar Wingfors (j...@joar.com) on 2009-02-06 12:06 AM said:
>> How can you guarantee a file's existence? sudo rm -f?
>
>How about calling open() on it?
:) But note the latter part of the sentence: "this method should only
be used if the file is guaranteed to exist _for the duration of the data
o
On Feb 6, 2009, at 8:52 PM, Sean McBride wrote:
How can you guarantee a file's existence? sudo rm -f?
How about calling open() on it?
j o a r
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderato
Michael Ash (michael@gmail.com) on 2009-02-06 9:20 PM said:
>> Would there be a way to do this with dataWithContentsOfMappedFile?
I've long
>> wondered about that... m.
>
>Yes and no. +dataWithContentsOfMappedFile: can be used to do this kind
>of efficient parsing, as memory mapping of files m
On Fri, Feb 6, 2009 at 6:44 PM, Matt Neuburg wrote:
> On Tue, 03 Feb 2009 00:42:07 +1100, Jacob Rhoden
> said:
>>I am wondering what the best way to read a text file, line by line, when
>>the file size is much larger than available memory.
>
> Would there
On Tue, 03 Feb 2009 00:42:07 +1100, Jacob Rhoden
said:
>I am wondering what the best way to read a text file, line by line, when
>the file size is much larger than available memory.
Would there be a way to do this with dataWithContentsOfMappedFile? I've long
wondered about that... m
> Might it help to look at the source for 'more' and/or 'less' (the Unix
> utilities)?
No idea whether they handle non-native line breaks competently. (Many many
tools do not.)
--
Scott Ribe
scott_r...@killerbytes.com
http://www.killerbytes.com/
(303) 722-0567 voice
___
r the text encoding of the text files you're dealing with.
>> But aside from both being about text files, that question is unrelated
>> to the question of how to process a large text file line-by-line.
>
>
> Would a correct implementation not depend on being able to itera
On Feb 3, 2009, at 11:43 AM, Scott Ribe wrote:
Would a correct implementation not depend on being able to iterate
over characters, and not simply using a fixed step size?
Not in order to find line endings. Now, actually doing anything with
the
line of text is a different issue, dependent on
> Would a correct implementation not depend on being able to iterate
> over characters, and not simply using a fixed step size?
Not in order to find line endings. Now, actually doing anything with the
line of text is a different issue, dependent on the encoding.
--
Scott Ribe
scott_r...@killerby
bout text files, that question is unrelated
to the question of how to process a large text file line-by-line.
Would a correct implementation not depend on being able to iterate
over characters, and not simply using a fixed step size? I wanted to
call attention to this because I, perhaps incor
On Feb 2, 2009, at 11:25 PM, Seth Willits wrote:
On Feb 2, 2009, at 7:50 PM, Joar Wingfors wrote:
Before opening the file, either determine, guess, or be told what
the encoding is. With that encoding, convert your delimiter string
into raw bytes, then do byte-for-byte comparison on the fil
Am 03.02.2009 um 10:46 schrieb Jacob Rhoden:
On 3/2/09 4:55 PM, Michael Ash wrote:
It is not uncommon that I might have to deal with server logs that
go into the gigabytes. Most logs (apache, squid, etc...) are all
ascii encoded. The line ending is irrelevant, see a \n or a \r and
we kno
on at hand. Yes, you definitely need to either know or be able
to discover the text encoding of the text files you're dealing with.
But aside from both being about text files, that question is unrelated
to the question of how to process a large text file line-by-line.
Exactly, I was loo
On Mon, Feb 2, 2009 at 8:53 PM, Joar Wingfors wrote:
>
> On Feb 2, 2009, at 1:49 PM, Seth Willits wrote:
>
>>> I am wondering what the best way to read a text file, line by line, when
>>> the file size is much larger than available memory.
>>
>> Use mm
ixed data chunk sizes or a length value
stored in the file itself telling how how big a chunk is. But if
you're reading a text file, line endings are more or less the only
logical delimiter.
If you have an encoding where characters are not of fixed width, is
it generally safe to
On Feb 2, 2009, at 7:50 PM, Joar Wingfors wrote:
On Feb 2, 2009, at 6:02 PM, Seth Willits wrote:
Before opening the file, either determine, guess, or be told what
the encoding is. With that encoding, convert your delimiter string
into raw bytes, then do byte-for-byte comparison on the file to
's no general-purpose way to know for sure the character
encoding if _all_ you have is a plain old text file. You always
should provide a way for the user to specify character encoding, where
it's not known for sure what the encoding is.
For line delimiters, it's almost always go
On Feb 2, 2009, at 6:02 PM, Seth Willits wrote:
Before opening the file, either determine, guess, or be told what
the encoding is. With that encoding, convert your delimiter string
into raw bytes, then do byte-for-byte comparison on the file to find
occurrences of that delimiter.
How do
comprehensive framework.
NSString handles such things,
Not really, as I understand it, for my definition of "such things".
the only thing I'm not sure is how it will handle a truly large
multi-gigabyte text file
The point of a line-based API is so that the file can be read one l
thing I'm not sure is how it
will handle a truly large multi-gigabyte text file (not that anyone is
likely to have such a beast). With a gigantic file like that you'd
probably have to switch to using something like NSFileHandle, read
chunks, and then parse those chunks. However,
On 3/02/2009 8:41 AM, Kenneth Bruno II wrote:
I am wondering what the best way to read a text file, line by line,
when the file size is much larger than available memory.
For very large files you probably want to use NSFileHandle. With the
method readDataOfLength: you can read the file in
On Feb 2, 2009, at 6:02 PM, Seth Willits wrote:
Before opening the file, either determine, guess, or be told what
the encoding is. With that encoding, convert your delimiter string
into raw bytes, then do byte-for-byte comparison on the file to find
occurrences of that delimiter.
Is there
On Feb 2, 2009, at 5:53 PM, Joar Wingfors wrote:
I am wondering what the best way to read a text file, line by
line, when the file size is much larger than available memory.
Use mmap. Scan through the bytes to find line ranges, and create
strings from there. Make sure it's deallocated
On Feb 2, 2009, at 1:49 PM, Seth Willits wrote:
I am wondering what the best way to read a text file, line by line,
when the file size is much larger than available memory.
Use mmap. Scan through the bytes to find line ranges, and create
strings from there. Make sure it's deallocated
On Mon, Feb 2, 2009 at 3:51 PM, Jacob Rhoden wrote:
> Yea, I saw this and some posts on the apple forum saying NSInputStream is
> not the right way, hence the question, what is the right way to analyze a
> very large file line by line.
>
> cf the apple thread
> http://discussions.apple.com/thread.
I am wondering what the best way to read a text file, line by line,
when the file size is much larger than available memory.
Use mmap. Scan through the bytes to find line ranges, and create
strings from there. Make sure it's deallocated when you're done with
it, then move on t
On Feb 2, 2009, at 8:42 AM, Jacob Rhoden wrote:
I am wondering what the best way to read a text file, line by line,
when the file size is much larger than available memory.
I know there are helper functions like
stringWithContentsOfFile:encoding:error:, but this implies having to
load
line.
cf the apple thread
http://discussions.apple.com/thread.jspa?threadID=1187120&tstart=400
On 3/2/09 12:57 AM, Alexander Spohr wrote:
NSInputStream?
Am 02.02.2009 um 14:42 schrieb Jacob Rhoden:
I am wondering what the best way to read a text file, line by
line, when the file siz
I am wondering what the best way to read a text file, line by
line, when the file size is much larger than available memory.
I know there are helper functions like
stringWithContentsOfFile:encoding:error:, but this implies having
to load the entire file in memory. Google has not been of much
e
7 AM, Alexander Spohr wrote:
NSInputStream?
Am 02.02.2009 um 14:42 schrieb Jacob Rhoden:
I am wondering what the best way to read a text file, line by line,
when the file size is much larger than available memory.
I know there are helper functions like
stringWithContentsOfFile:encoding:error:, but
NSInputStream?
atze
Am 02.02.2009 um 14:42 schrieb Jacob Rhoden:
Hi Guys,
I am wondering what the best way to read a text file, line by line,
when the file size is much larger than available memory.
I know there are helper functions like
stringWithContentsOfFile:encoding:error
Hi Guys,
I am wondering what the best way to read a text file, line by line, when
the file size is much larger than available memory.
I know there are helper functions like
stringWithContentsOfFile:encoding:error:, but this implies having to
load the entire file in memory. Google has not
On Jun 9, 2008, at 2:04 PM, Abel J. Almeida wrote:
I need help parsing a large text file.
I need to examine the file one line at a time.
It's a 128MB text file.
I used the stringWithContentsOfFile method from the NSString class,
but the file is too large and it doesn't seem very
You'd need to open the file using NSStream, NSFileHandle or regular c
stdio, then read chunks out of it and break them into lines.
--Jens // via iPhone
On Jun 9, 2008, at 2:04 PM, "Abel J. Almeida" <[EMAIL PROTECTED]
> wrote:
I need help parsing a large
I need help parsing a large text file.
I need to examine the file one line at a time.
It's a 128MB text file.
I used the stringWithContentsOfFile method from the NSString class,
but the file is too large and it doesn't seem very optimized to me,
because what I need is parse one
77 matches
Mail list logo
