Re: length of file from NSFileHandle?

[R. Matthew Emerson]

> On Aug 26, 2016, at 11:32 PM, R. Matthew Emerson  
> wrote:
> 
> 
>> On Aug 26, 2016, at 11:19 PM, Graham Cox  wrote:
>> 
>> Hi all,
>> 
>> Apparently a simple task, but no obvious API for it: getting the length 
>> (size) of a file I have a NSFileHandle for. This class has no -length 
>> property, so how can I get it?
>> 
>> I need to know because I have a requirement to create a backup copy of a 
>> file once it exceeds a certain size. This backup is created when I first 
>> open the file as a NSFileHandle. I can read the content of the file and find 
>> out the size that way, but I’d rather not first read it into memory if I’m 
>> just going to create my backup copy and then start over with an empty file - 
>> reading it all in just to find the length seems a bit wrong, is all.
> 
> One way would be to read the NSFileHandle's fileDescriptor property, and then 
> use stat(2), e.g., like so:
> 
> #include 
> #include 
> 
> #include 
> 
> int main(int argc, char *argv[])
> {
>struct stat buf;
>stat("/etc/passwd", &buf);
>printf("size = %lld\n", buf.st_size);
> }

Argh, I meant fstat(2).

#include 
#include 
#include 

#include 

int main(int argc, char *argv[])
{
struct stat buf;
int fd = open("/etc/passwd", O_RDONLY);

fstat(fd, &buf);
printf("size = %lld\n", buf.st_size);
}




___

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: length of file from NSFileHandle?

[R. Matthew Emerson]

> On Aug 26, 2016, at 11:19 PM, Graham Cox  wrote:
> 
> Hi all,
> 
> Apparently a simple task, but no obvious API for it: getting the length 
> (size) of a file I have a NSFileHandle for. This class has no -length 
> property, so how can I get it?
> 
> I need to know because I have a requirement to create a backup copy of a file 
> once it exceeds a certain size. This backup is created when I first open the 
> file as a NSFileHandle. I can read the content of the file and find out the 
> size that way, but I’d rather not first read it into memory if I’m just going 
> to create my backup copy and then start over with an empty file - reading it 
> all in just to find the length seems a bit wrong, is all.

One way would be to read the NSFileHandle's fileDescriptor property, and then 
use stat(2), e.g., like so:

#include 
#include 

#include 

int main(int argc, char *argv[])
{
struct stat buf;
stat("/etc/passwd", &buf);
printf("size = %lld\n", buf.st_size);
}


___

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

Use text system or totally custom text view?

[R . Matthew Emerson]

I work on a Common Lisp system ().   
The lisp has an Objective-C bridge, and there's a more-than-a-demo  
Cocoa IDE for it, though it is pretty rough around the edges in places.


An important part of the IDE is the editor.  We're currently using an  
emacs-like editor called Hemlock.  Hemlock is written in Common Lisp,  
so an editor buffer is a rich lisp data structure.


A Hemlock buffer is represented as a linked list of lines.  A line is  
a lisp string.  A lisp string is a vector of characters (represented  
internally as UTF-32/UCS-4 code points).  This is quite different from  
the usual way Cocoa represents text.


Also, being an emacs-like editor, Hemlock runs user-definable commands  
in response to key events.


Right now, we have an NSTextStorage subclass that wraps a Hemlock  
buffer.  However, we end up maintaining a "mirror"  
NSMutableAttributedString instance containing the buffer text anyway,  
and there's a bit of hair involved in keeping the two in sync.


On the input side of things, we subclass NSTextView and override  
keyDown:.  From what I've read, this is usually the wrong thing to do,  
but we want to do our own key bindings and don't want the default key  
bindings getting in the way.  On the other hand, we still want to use  
input management.


Hemlock also has its own notion of selection, which is disjoint from  
NSTextView's.  I think we'd really like users to run (user-defined)  
commands in response to mouse events, too.  (Custom selection behavior  
in different editing modes, etc.)


So, I'm really looking for advice on whether it's reasonable to keep  
trying to use the Cocoa text system to support text display and input,  
or if it would be better to make the (nontrivial) effort to write a  
totally custom text view in a case like this.


___

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 [EMAIL PROTECTED]