* Re: [9fans] edit a huge file
[not found] <CAOEdRO0MKYpbj0gyu-gM5S1hkOCXGp+=-wnE-J5m_iqxZJWfPQ@mail.gmail.c>
@ 2011-08-24 14:50 ` erik quanstrom
2011-08-24 14:56 ` Russ Cox
[not found] ` <CADSkJJXpK-a7m+yGNu3WJgfONdoKjs99okq3eGNLw7sqbiCVOA@mail.gmail.c>
0 siblings, 2 replies; 6+ messages in thread
From: erik quanstrom @ 2011-08-24 14:50 UTC (permalink / raw)
To: 9fans
> So does acme/sam need to load the whole file into memory?
no, but the whole file is read. additionally, many 32-bit offsets are used.
(cf. Range, Block, Disk, Buffer.cqi Elog, File.ntext, Text, Expand, in acme/dat.h)
i don't think it would be that hard to modify acme to handle large files,
but you'd have to convince it to not read the entire file preemptively to
make this a useful feature. and you'll probablly have to increase the size
of STACK.
- erik
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [9fans] edit a huge file
2011-08-24 14:50 ` [9fans] edit a huge file erik quanstrom
@ 2011-08-24 14:56 ` Russ Cox
[not found] ` <CADSkJJXpK-a7m+yGNu3WJgfONdoKjs99okq3eGNLw7sqbiCVOA@mail.gmail.c>
1 sibling, 0 replies; 6+ messages in thread
From: Russ Cox @ 2011-08-24 14:56 UTC (permalink / raw)
To: Fans of the OS Plan 9 from Bell Labs
> no, but the whole file is read. additionally, many 32-bit offsets are used.
>
> (cf. Range, Block, Disk, Buffer.cqi Elog, File.ntext, Text, Expand, in acme/dat.h)
>
> i don't think it would be that hard to modify acme to handle large files,
> but you'd have to convince it to not read the entire file preemptively to
> make this a useful feature.
that's not true. it's still useful even with the temporary copy.
and the temporary copy makes sure things aren't changing
out from under acme's feet.
russ
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [9fans] edit a huge file
[not found] ` <CADSkJJXpK-a7m+yGNu3WJgfONdoKjs99okq3eGNLw7sqbiCVOA@mail.gmail.c>
@ 2011-08-24 15:04 ` erik quanstrom
2011-08-24 16:29 ` Russ Cox
0 siblings, 1 reply; 6+ messages in thread
From: erik quanstrom @ 2011-08-24 15:04 UTC (permalink / raw)
To: 9fans
> > i don't think it would be that hard to modify acme to handle large files,
> > but you'd have to convince it to not read the entire file preemptively to
> > make this a useful feature.
>
> that's not true. it's still useful even with the temporary copy.
> and the temporary copy makes sure things aren't changing
> out from under acme's feet.
i'm not sure what statement you're refuting. the reason i think
making the copy is a problem for a 7 gb file is the excessive time
it takes for big files.
does the acme temp file get entirely rewritten when one file
changes? i.e. is this the mbox problem?
- erik
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [9fans] edit a huge file
2011-08-24 15:04 ` erik quanstrom
@ 2011-08-24 16:29 ` Russ Cox
0 siblings, 0 replies; 6+ messages in thread
From: Russ Cox @ 2011-08-24 16:29 UTC (permalink / raw)
To: Fans of the OS Plan 9 from Bell Labs
>> that's not true. it's still useful even with the temporary copy.
>> and the temporary copy makes sure things aren't changing
>> out from under acme's feet.
>
> i'm not sure what statement you're refuting.
"you'd have to convince it to not read the entire file preemptively to
make this a useful feature."
> the reason i think
> making the copy is a problem for a 7 gb file is the excessive time
> it takes for big files.
copying 7gb doesn't take that long.
it certainly takes less time than rewriting
acme to remove a fundamental assumption.
if you're editing a 7gb file i think you're willing
to wait a little while.
> does the acme temp file get entirely rewritten when one file
> changes? i.e. is this the mbox problem?
no
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [9fans] edit a huge file
2011-08-24 14:38 Rudolf Sykora
@ 2011-08-24 14:51 ` Russ Cox
0 siblings, 0 replies; 6+ messages in thread
From: Russ Cox @ 2011-08-24 14:51 UTC (permalink / raw)
To: Fans of the OS Plan 9 from Bell Labs
> I needed to edit/look through a cca 7 GB log (text) file.
> Now I use p9p.
> Acme failed with a segmentation fault, was killed.
> Sam did not seg-faulted, but didn't work either.
> I finally used ed/sed.
>
> So does acme/sam need to load the whole file into memory?
neither loads the file into memory.
sam uses 32-bit file offsets in the wire protocol that
connects the gui with the back end.
acme probably uses 32-bit file offsets too.
i suspect the crash you saw was due to
a math error on wraparound.
Russ
^ permalink raw reply [flat|nested] 6+ messages in thread
* [9fans] edit a huge file
@ 2011-08-24 14:38 Rudolf Sykora
2011-08-24 14:51 ` Russ Cox
0 siblings, 1 reply; 6+ messages in thread
From: Rudolf Sykora @ 2011-08-24 14:38 UTC (permalink / raw)
To: Fans of the OS Plan 9 from Bell Labs
Hello everybody,
I needed to edit/look through a cca 7 GB log (text) file.
Now I use p9p.
Acme failed with a segmentation fault, was killed.
Sam did not seg-faulted, but didn't work either.
I finally used ed/sed.
So does acme/sam need to load the whole file into memory?
Thanks
Ruda
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2011-08-24 16:29 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <CAOEdRO0MKYpbj0gyu-gM5S1hkOCXGp+=-wnE-J5m_iqxZJWfPQ@mail.gmail.c>
2011-08-24 14:50 ` [9fans] edit a huge file erik quanstrom
2011-08-24 14:56 ` Russ Cox
[not found] ` <CADSkJJXpK-a7m+yGNu3WJgfONdoKjs99okq3eGNLw7sqbiCVOA@mail.gmail.c>
2011-08-24 15:04 ` erik quanstrom
2011-08-24 16:29 ` Russ Cox
2011-08-24 14:38 Rudolf Sykora
2011-08-24 14:51 ` Russ Cox
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).