Re: [9fans] edit a huge file

Re: [9fans] edit a huge file

[erik quanstrom]

> 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

Re: [9fans] edit a huge file

[Russ Cox]

> 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

Re: [9fans] edit a huge file

[erik quanstrom]

> > 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

Re: [9fans] edit a huge file

[Russ Cox]

>> 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

Re: [9fans] edit a huge file

[Russ Cox]

> 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

[9fans] edit a huge file

[Rudolf Sykora]

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