Alexander Best arun...@freebsd.org writes:
so how about forgetting about expand_number() and simply introducing a
maximum buffer size of 1 megabyte?
so how about just leaving the code alone? :)
DES
--
Dag-Erling Smørgrav - d...@des.no
___
On Wed Sep 8 10, Dag-Erling Smørgrav wrote:
Alexander Best arun...@freebsd.org writes:
so how about forgetting about expand_number() and simply introducing a
maximum buffer size of 1 megabyte?
so how about just leaving the code alone? :)
i thought you wanted to have a maximum buffer
Alexander Best arun...@freebsd.org writes:
Dag-Erling Smørgrav d...@des.no writes:
Alexander Best arun...@freebsd.org writes:
so how about forgetting about expand_number() and simply
introducing a maximum buffer size of 1 megabyte?
so how about just leaving the code alone? :)
i
On Wed Sep 8 10, Dag-Erling Smørgrav wrote:
Alexander Best arun...@freebsd.org writes:
Dag-Erling Smørgrav d...@des.no writes:
Alexander Best arun...@freebsd.org writes:
so how about forgetting about expand_number() and simply
introducing a maximum buffer size of 1 megabyte?
so
On Thu Sep 2 10, Dag-Erling Smørgrav wrote:
Alexander Best arun...@freebsd.org writes:
the current maximum buffer limit of fetch(1) actually is around 1G. i
think 1M is not enough, because if people are pulling data over fast
lines they'll have almost constant disk writes. how about 100M
Alexander Best arun...@freebsd.org writes:
since you're the originator of fetch(1): should i send you a patch to add
expand_numer() to the -B switch or do you think fetch is better off as it is
now without humanised numbers?
Sure, but we need to commit the expand_number() patch first.
i'm
On Thu Sep 2 10, Dag-Erling Smørgrav wrote:
Alexander Best arun...@freebsd.org writes:
since you're the originator of fetch(1): should i send you a patch to add
expand_numer() to the -B switch or do you think fetch is better off as it is
now without humanised numbers?
Sure, but we need
Alexander Best arun...@freebsd.org writes:
so how about something like this? the fetch(1) manual would have to be changed
a bit to state that if '-B val' 1G it silently gets set to 1G.
1 GB is ridiculously large. 1 MB should be plenty.
DES
--
Dag-Erling Smørgrav - d...@des.no
On Thu Sep 2 10, Dag-Erling Smørgrav wrote:
Alexander Best arun...@freebsd.org writes:
so how about something like this? the fetch(1) manual would have to be
changed
a bit to state that if '-B val' 1G it silently gets set to 1G.
1 GB is ridiculously large. 1 MB should be plenty.
the
Alexander Best arun...@freebsd.org writes:
the current maximum buffer limit of fetch(1) actually is around 1G. i
think 1M is not enough, because if people are pulling data over fast
lines they'll have almost constant disk writes. how about 100M then?
;)
Large buffer sizes are *not* better,
Alexander Best arun...@freebsd.org writes:
just having a quick look around to see, if anybody would be interested in
fetch -B and fetch -S accepting humanized numbers using expand_number()?
I can understand it for -B, but not for -S, since in the common case (by
1023 to 1, assuming a random
On Wed Sep 1 10, Dag-Erling Smørgrav wrote:
Alexander Best arun...@freebsd.org writes:
just having a quick look around to see, if anybody would be interested in
fetch -B and fetch -S accepting humanized numbers using expand_number()?
I can understand it for -B, but not for -S, since in
hi there,
just having a quick look around to see, if anybody would be interested in
fetch -B and fetch -S accepting humanized numbers using expand_number()?
cheers.
alex
--
a13x
___
freebsd-hackers@freebsd.org mailing list
13 matches
Mail list logo