On Tue, 13 Jul 1999 11:13:49 -0700 (PDT)
Matthew Dillon wrote:
> SysV was totally and utterly broken in regards to swap allocation. The
> only major operating system that used it as a base was IRIX and SGI
> found out very quickly that pre-reserving swap is a stupid idea - and
[cc list trimmed because it was getting ... insane, and it's not like
this is a critical point. It's just beating up a topic which has been
beaten up by many others.]
Matthew Dillon <[EMAIL PROTECTED]> writes:
> Thus it makes little sense to try to disallow overcommit. It gains you
> abs
:> We could have the ability to mark processes as being more or less
:> preferable as kill candidates. I'm not sure I really care anymore,
:> though... there is so much disk space available now that it is fairly
:> difficult to run the system out of swap space. I don't think I'v
"Brian F. Feldman" <[EMAIL PROTECTED]> writes:
> But I have a valid point: can we do something better than posting a SIGKILL
> to the largest process?
If I remember correctly, AIX sends a signal to all processes asking
them to free up memory. (Processes ignore this signal by default.) If
nobody
On Tue, 13 Jul 1999, Matthew Dillon wrote:
>
> :But I have a valid point: can we do something better than posting a SIGKILL
> :to the largest process?
> :
> : Brian Fundakowski Feldman _ __ ___ ___ ___ ___
> : [EMAIL PROTECTED] _ __ ___ | _ ) __| \
>
> We c
>
> We could have the ability to mark processes as being more or less
> preferable as kill candidates. I'm not sure I really care anymore,
> though... there is so much disk space available now that it is fairly
> difficult to run the system out of swap space. I don't think I've
This topic has been rehashed a thousand times.
What it comes down to is that if you want to disallow overcommit, you
have to multiply the amount of swap space in the system relative to
current levels in order to get the same performance limits as you had
before. If you don't,
:But I have a valid point: can we do something better than posting a SIGKILL
:to the largest process?
:
: Brian Fundakowski Feldman _ __ ___ ___ ___ ___
: [EMAIL PROTECTED] _ __ ___ | _ ) __| \
We could have the ability to mark processes as being more or les
On Tue, Jul 13, 1999 at 02:47:20PM -0400, Brian F. Feldman wrote:
> But I have a valid point: can we do something better than posting a SIGKILL
> to the largest process?
I think AIX sends all running processes a magic signal (SIGDANGER?)
which indicates that the system is short of resources, and
But I have a valid point: can we do something better than posting a SIGKILL
to the largest process?
Brian Fundakowski Feldman _ __ ___ ___ ___ ___
[EMAIL PROTECTED] _ __ ___ | _ ) __| \
FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
http://
On Tue, 13 Jul 1999 10:11:14 -0400 (EDT)
"Brian F. Feldman" wrote:
> > SVR4 has MAP_NORESERVE option for mmap(2) for this.
> > So, default behaivour don't have to be overcommitment.
>
> Isn't that just like mmap()ing then mlock()ing the range? That would
> keep it in core.
No, it's not t
On Tue, 13 Jul 1999 11:13:49 -0700 (PDT)
Matthew Dillon <[EMAIL PROTECTED]> wrote:
> SysV was totally and utterly broken in regards to swap allocation. The
> only major operating system that used it as a base was IRIX and SGI
> found out very quickly that pre-reserving swap is a
This topic has been rehashed a thousand times.
What it comes down to is that if you want to disallow overcommit, you
have to multiply the amount of swap space in the system relative to
current levels in order to get the same performance limits as you had
before. If you don't,
On Tue, 13 Jul 1999 10:11:14 -0400 (EDT)
"Brian F. Feldman" <[EMAIL PROTECTED]> wrote:
> > SVR4 has MAP_NORESERVE option for mmap(2) for this.
> > So, default behaivour don't have to be overcommitment.
>
> Isn't that just like mmap()ing then mlock()ing the range? That would
> keep it in c
Jon Ribbens writes:
> > Because memory (as in *real* memory, either RAM or swap) is
> > allocated on-demand. So you can allocate any amount of virtual
> > memory that the system can possibly provide you, even though you'll
> > run out of memory much earlier, because other resources are also
> > con
> On Tue, 13 Jul 1999 10:11:14 -0400 (EDT),
"Brian F. Feldman" said:
>> > you also have to consider a program wishing to make sparse use
>> > of its address space, without overcommit it becomes impossible.
>>
>> SVR4 has MAP_NORESERVE option for mmap(2) for this.
>> So, default behai
Jon Ribbens writes:
> > Because memory (as in *real* memory, either RAM or swap) is
> > allocated on-demand. So you can allocate any amount of virtual
> > memory that the system can possibly provide you, even though you'll
> > run out of memory much earlier, because other resources are also
> > co
On Tue, 13 Jul 1999, Noriyuki Soda wrote:
> > You're browsing with netscape and It hits about 32megs in size,
> > you click on a multimedia object and netscape execs a helper app.
>
> If the system has real vfork(2) like NetBSD, this is not problem.
>
> > you also have to consider a program wish
> On Tue, 13 Jul 1999 10:11:14 -0400 (EDT),
"Brian F. Feldman" <[EMAIL PROTECTED]> said:
>> > you also have to consider a program wishing to make sparse use
>> > of its address space, without overcommit it becomes impossible.
>>
>> SVR4 has MAP_NORESERVE option for mmap(2) for this.
On Tue, 13 Jul 1999, Noriyuki Soda wrote:
> > You're browsing with netscape and It hits about 32megs in size,
> > you click on a multimedia object and netscape execs a helper app.
>
> If the system has real vfork(2) like NetBSD, this is not problem.
>
> > you also have to consider a program wis
> You're browsing with netscape and It hits about 32megs in size,
> you click on a multimedia object and netscape execs a helper app.
If the system has real vfork(2) like NetBSD, this is not problem.
> you also have to consider a program wishing to make sparse use
> of its address space, without
Alfred Perlstein wrote:
> You're browsing with netscape and It hits about 32megs in size,
> you click on a multimedia object and netscape execs a helper app.
vfork()
> you also have to consider a program wishing to make sparse use
> of its address space, without overcommit it becomes impossible.
"Daniel C. Sobral" wrote:
> > I can add it to the list of reasons I don't use it then I guess ;-).
>
> Whatever. The operating system you use also does it.
How terribly tedious.
Cheers
Jon
--
\/ Jon Ribbens / j...@oaktree.co.uk
To Unsubscribe: send mail to majord...@freebsd.org
with "unsub
> You're browsing with netscape and It hits about 32megs in size,
> you click on a multimedia object and netscape execs a helper app.
If the system has real vfork(2) like NetBSD, this is not problem.
> you also have to consider a program wishing to make sparse use
> of its address space, without
Alfred Perlstein <[EMAIL PROTECTED]> wrote:
> You're browsing with netscape and It hits about 32megs in size,
> you click on a multimedia object and netscape execs a helper app.
vfork()
> you also have to consider a program wishing to make sparse use
> of its address space, without overcommit it
"Daniel C. Sobral" <[EMAIL PROTECTED]> wrote:
> > I can add it to the list of reasons I don't use it then I guess ;-).
>
> Whatever. The operating system you use also does it.
How terribly tedious.
Cheers
Jon
--
\/ Jon Ribbens / [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECT
On Tue, 13 Jul 1999, Daniel C. Sobral wrote:
> Jon Ribbens wrote:
> >
> > "Daniel C. Sobral" wrote:
> > > That's *not* abomination. How about pre-allocating over 100 Mb for X
> > > Free, for instance?
> >
> > What about it? If an application does not need 100MB, it should not
> > malloc it. If
On Tue, 13 Jul 1999, Daniel C. Sobral wrote:
> Jon Ribbens wrote:
> >
> > "Daniel C. Sobral" <[EMAIL PROTECTED]> wrote:
> > > That's *not* abomination. How about pre-allocating over 100 Mb for X
> > > Free, for instance?
> >
> > What about it? If an application does not need 100MB, it should no
Ollivier Robert wrote:
>
> Oh I forgot the one about having a veto system for I don't remember what...
Veto based locking for the fs.
--
Daniel C. Sobral(8-DCS)
d...@newsguy.com
d...@freebsd.org
I'm one of those bad things that happen to good people.
To Unsubsc
Jon Ribbens wrote:
>
> > If you're not prepared to do that, the long and the short of it is that
> > FreeBSD _does_ overcommit, we like it that way and neither of these two
> > facts is likely to change.
>
> I can add it to the list of reasons I don't use it then I guess ;-).
Whatever. The opera
Jon Ribbens wrote:
>
> "Daniel C. Sobral" wrote:
> > That's *not* abomination. How about pre-allocating over 100 Mb for X
> > Free, for instance?
>
> What about it? If an application does not need 100MB, it should not
> malloc it. If it does need it, it should malloc it and know that it
> is ava
Ollivier Robert wrote:
>
> Oh I forgot the one about having a veto system for I don't remember what...
Veto based locking for the fs.
--
Daniel C. Sobral(8-DCS)
[EMAIL PROTECTED]
[EMAIL PROTECTED]
I'm one of those bad things that happen to good people.
To Unsu
Jon Ribbens wrote:
>
> > If you're not prepared to do that, the long and the short of it is that
> > FreeBSD _does_ overcommit, we like it that way and neither of these two
> > facts is likely to change.
>
> I can add it to the list of reasons I don't use it then I guess ;-).
Whatever. The oper
Jon Ribbens wrote:
>
> "Daniel C. Sobral" <[EMAIL PROTECTED]> wrote:
> > That's *not* abomination. How about pre-allocating over 100 Mb for X
> > Free, for instance?
>
> What about it? If an application does not need 100MB, it should not
> malloc it. If it does need it, it should malloc it and k
> > Yuck. That's a complete abomination. What's the point of it? It's turning
>
> Paging Terry Lambert, Terry Lambert - do you read me? It's time for
> your annual rant on the topic of memory overcommit. :-)
It's not overcommit so much as it is what happens to a process that gets a
page fault wh
According to Warner Losh:
> I thought it was time for his annual rant about how the current
> FreeBSD development model is going to have problems scaling...
No no, I think you're thinking of the write-lock read-lock we should use on
CVS in order to have the Hamiltonian graph without cycle to solve
On Tue, 13 Jul 1999 00:20:27 +0100, Jon Ribbens wrote:
> I'd love to, could you please be more specific? I can't find anything
> relevant searching for 'malloc' or 'overcommit'.
My apologies. It was the current mailing list. Search for "malloc AND
NULL AND kill", and pick out the "swap-related
Sheldon Hearn wrote:
> You're rehashing stuff that's been discussed to death. Please look at
> the mailing list archives for this mailing list.
I'd love to, could you please be more specific? I can't find anything
relevant searching for 'malloc' or 'overcommit'.
> If you're not prepared to do th
On Mon, 12 Jul 1999 23:56:29 +0100, Jon Ribbens wrote:
> What about it? If an application does not need 100MB, it should not
> malloc it. If it does need it, it should malloc it and know that it
> is available if the malloc succeeds.
You're rehashing stuff that's been discussed to death. Please
> > Yuck. That's a complete abomination. What's the point of it? It's turning
>
> Paging Terry Lambert, Terry Lambert - do you read me? It's time for
> your annual rant on the topic of memory overcommit. :-)
It's not overcommit so much as it is what happens to a process that gets a
page fault w
"Daniel C. Sobral" wrote:
> That's *not* abomination. How about pre-allocating over 100 Mb for X
> Free, for instance?
What about it? If an application does not need 100MB, it should not
malloc it. If it does need it, it should malloc it and know that it
is available if the malloc succeeds.
> Ba
According to Warner Losh:
> I thought it was time for his annual rant about how the current
> FreeBSD development model is going to have problems scaling...
No no, I think you're thinking of the write-lock read-lock we should use on
CVS in order to have the Hamiltonian graph without cycle to solv
On Tue, 13 Jul 1999 00:20:27 +0100, Jon Ribbens wrote:
> I'd love to, could you please be more specific? I can't find anything
> relevant searching for 'malloc' or 'overcommit'.
My apologies. It was the current mailing list. Search for "malloc AND
NULL AND kill", and pick out the "swap-related
Sheldon Hearn <[EMAIL PROTECTED]> wrote:
> You're rehashing stuff that's been discussed to death. Please look at
> the mailing list archives for this mailing list.
I'd love to, could you please be more specific? I can't find anything
relevant searching for 'malloc' or 'overcommit'.
> If you're n
On Mon, 12 Jul 1999 23:56:29 +0100, Jon Ribbens wrote:
> What about it? If an application does not need 100MB, it should not
> malloc it. If it does need it, it should malloc it and know that it
> is available if the malloc succeeds.
You're rehashing stuff that's been discussed to death. Pleas
"Daniel C. Sobral" <[EMAIL PROTECTED]> wrote:
> That's *not* abomination. How about pre-allocating over 100 Mb for X
> Free, for instance?
What about it? If an application does not need 100MB, it should not
malloc it. If it does need it, it should malloc it and know that it
is available if the ma
In message <1336.931774...@zippy.cdrom.com> "Jordan K. Hubbard" writes:
: Paging Terry Lambert, Terry Lambert - do you read me? It's time for
: your annual rant on the topic of memory overcommit. :-)
I thought it was time for his annual rant about how the current
FreeBSD development model is goin
In message <[EMAIL PROTECTED]> "Jordan K. Hubbard" writes:
: Paging Terry Lambert, Terry Lambert - do you read me? It's time for
: your annual rant on the topic of memory overcommit. :-)
I thought it was time for his annual rant about how the current
FreeBSD development model is going to have pr
> Yuck. That's a complete abomination. What's the point of it? It's turning
Paging Terry Lambert, Terry Lambert - do you read me? It's time for
your annual rant on the topic of memory overcommit. :-)
- Jordan
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers"
> Yuck. That's a complete abomination. What's the point of it? It's turning
Paging Terry Lambert, Terry Lambert - do you read me? It's time for
your annual rant on the topic of memory overcommit. :-)
- Jordan
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in
Jon Ribbens wrote:
>
> Yuck. That's a complete abomination. What's the point of it? It's turning
> an out-of-memory situation from an easily-detected recoverable temporary
> resource shortage which can be worked-around or waited out, into an
> unrecoverable fatal error. Do a significant number of
Jon Ribbens wrote:
>
> Yuck. That's a complete abomination. What's the point of it? It's turning
> an out-of-memory situation from an easily-detected recoverable temporary
> resource shortage which can be worked-around or waited out, into an
> unrecoverable fatal error. Do a significant number of
In message <19990712022424.a1...@oaktree.co.uk> Jon Ribbens writes:
: No, if the *process* hits its *administrative* resource limits.
: i.e. setrlimit(2).
That should (and I believe does) make malloc fail.
Warner
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hacke
Jon Ribbens writes:
> "Daniel C. Sobral" wrote:
> > OTOH, though, FreeBSD's malloc() is very unlikely to return an out
> > of memory error.
> Why is that?
Because FreeBSD overcommits memory. You can allocate (almost) as much
memory as you want regardless of how much RAM / swap you have. You
won'
In message <[EMAIL PROTECTED]> Jon Ribbens writes:
: No, if the *process* hits its *administrative* resource limits.
: i.e. setrlimit(2).
That should (and I believe does) make malloc fail.
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of t
"Daniel C. Sobral" wrote:
> > > OTOH, though, FreeBSD's malloc() is very unlikely to return an out
> > > of memory error.
> >
> > Why is that?
>
> Because memory (as in *real* memory, either RAM or swap) is
> allocated on-demand. So you can allocate any amount of virtual
> memory that the system
Jon Ribbens <[EMAIL PROTECTED]> writes:
> "Daniel C. Sobral" <[EMAIL PROTECTED]> wrote:
> > OTOH, though, FreeBSD's malloc() is very unlikely to return an out
> > of memory error.
> Why is that?
Because FreeBSD overcommits memory. You can allocate (almost) as much
memory as you want regardless of
Jon Ribbens wrote:
>
> "Daniel C. Sobral" wrote:
> > OTOH, though, FreeBSD's malloc() is very unlikely to return an out
> > of memory error.
>
> Why is that?
Because memory (as in *real* memory, either RAM or swap) is
allocated on-demand. So you can allocate any amount of virtual
memory that th
"Daniel C. Sobral" <[EMAIL PROTECTED]> wrote:
> > > OTOH, though, FreeBSD's malloc() is very unlikely to return an out
> > > of memory error.
> >
> > Why is that?
>
> Because memory (as in *real* memory, either RAM or swap) is
> allocated on-demand. So you can allocate any amount of virtual
> me
Jon Ribbens wrote:
>
> "Daniel C. Sobral" <[EMAIL PROTECTED]> wrote:
> > OTOH, though, FreeBSD's malloc() is very unlikely to return an out
> > of memory error.
>
> Why is that?
Because memory (as in *real* memory, either RAM or swap) is
allocated on-demand. So you can allocate any amount of vi
"Daniel C. Sobral" wrote:
> OTOH, though, FreeBSD's malloc() is very unlikely to return an out
> of memory error.
Why is that?
What happens if the process hits its resource limits?
Cheers
Jon
--
\/ Jon Ribbens / j...@oaktree.co.uk
To Unsubscribe: send mail to majord...@freebsd.org
with "un
"Daniel C. Sobral" <[EMAIL PROTECTED]> wrote:
> OTOH, though, FreeBSD's malloc() is very unlikely to return an out
> of memory error.
Why is that?
What happens if the process hits its resource limits?
Cheers
Jon
--
\/ Jon Ribbens / [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROT
Assar Westerlund wrote:
>
> > > And besides, I really don't think this is a grep function but actually
> > > is useful for programs that don't have any strategy for handling out
> > > of memory errors and might as well die (with a descriptive error
> > > message, of course). Let's call it emalloc
Assar Westerlund wrote:
>
> > > And besides, I really don't think this is a grep function but actually
> > > is useful for programs that don't have any strategy for handling out
> > > of memory errors and might as well die (with a descriptive error
> > > message, of course). Let's call it emallo
Dag-Erling Smorgrav wrote:
>
> Assar Westerlund writes:
> > Dag-Erling Smorgrav writes:
> > > + realpat = grep_malloc(strlen(pattern) + sizeof("^(")
> > > + + sizeof(")$") + 1);
> > Why not just use asprintf?
>
> Doesn't matter, thsis code is gone in the latest
Dag-Erling Smorgrav wrote:
>
> Assar Westerlund <[EMAIL PROTECTED]> writes:
> > Dag-Erling Smorgrav <[EMAIL PROTECTED]> writes:
> > > + realpat = grep_malloc(strlen(pattern) + sizeof("^(")
> > > + + sizeof(")$") + 1);
> > Why not just use asprintf?
>
> Doesn't m
On Wed, 7 Jul 1999, Jamie Howard wrote:
> The FreeBSD, NetBSD, and OpenBSD manpage for grep says this:
>
> Grep understands two different versions of regular expression
> syntax: ``basic'' and ``extended.'' In GNU grep, there is
> no difference in available functionality u
On Wed, 7 Jul 1999, Jamie Howard wrote:
> The FreeBSD, NetBSD, and OpenBSD manpage for grep says this:
>
> Grep understands two different versions of regular expression
> syntax: ``basic'' and ``extended.'' In GNU grep, there is
> no difference in available functionality
Dag-Erling Smorgrav wrote:
>
>Don't use err() indiscriminately after a malloc() failure; malloc()
>doesn't set errno.
When I looked at malloc(3) I decided that it relied on sbrk(2) to set
errno if it returned 0. Is this wrong? i.e. can it return 0 without
a failed syscall?
Tony.
--
f.a.n.finch
Dag-Erling Smorgrav <[EMAIL PROTECTED]> wrote:
>
>Don't use err() indiscriminately after a malloc() failure; malloc()
>doesn't set errno.
When I looked at malloc(3) I decided that it relied on sbrk(2) to set
errno if it returned 0. Is this wrong? i.e. can it return 0 without
a failed syscall?
To
Dag-Erling Smorgrav writes:
> > And besides, I really don't think this is a grep function but actually
> > is useful for programs that don't have any strategy for handling out
> > of memory errors and might as well die (with a descriptive error
> > message, of course). Let's call it emalloc and l
Dag-Erling Smorgrav <[EMAIL PROTECTED]> writes:
> > And besides, I really don't think this is a grep function but actually
> > is useful for programs that don't have any strategy for handling out
> > of memory errors and might as well die (with a descriptive error
> > message, of course). Let's c
Assar Westerlund writes:
> Dag-Erling Smorgrav writes:
> > + realpat = grep_malloc(strlen(pattern) + sizeof("^(")
> > + + sizeof(")$") + 1);
> Why not just use asprintf?
Doesn't matter, thsis code is gone in the latest version. You though
the linux 'kernel of th
Dag-Erling Smorgrav writes:
> - if ((realpat = malloc(strlen(pattern) + sizeof("^(") +
> - sizeof(")$") + 1)) == NULL)
> - err(1, "malloc");
> + realpat = grep_malloc(strlen(pattern) + sizeof("^(")
> + + sizeof
Assar Westerlund <[EMAIL PROTECTED]> writes:
> Dag-Erling Smorgrav <[EMAIL PROTECTED]> writes:
> > + realpat = grep_malloc(strlen(pattern) + sizeof("^(")
> > + + sizeof(")$") + 1);
> Why not just use asprintf?
Doesn't matter, thsis code is gone in the latest vers
Dag-Erling Smorgrav <[EMAIL PROTECTED]> writes:
> - if ((realpat = malloc(strlen(pattern) + sizeof("^(") +
> - sizeof(")$") + 1)) == NULL)
> - err(1, "malloc");
> + realpat = grep_malloc(strlen(pattern) + sizeof("^(")
> +
Jamie Howard writes:
> On 7 Jul 1999, Dag-Erling Smorgrav wrote:
> > I see you switched to using extended regexps by default, and made -E a
> > no-op; this breaks the ports collection, so I changed it back.
>
> The FreeBSD, NetBSD, and OpenBSD manpage for grep says this:
>
> Grep understan
On 7 Jul 1999, Dag-Erling Smorgrav wrote:
> BTW, I assume you've read this:
>
>http://www.opengroup.org/onlinepubs/007908799/xcu/grep.html>
Of course, my copy of the printout is all marked up. :)
> I see you switched to using extended regexps by default, and made -E a
> no-op; this breaks
Dag-Erling Smorgrav writes:
> Jamie Howard writes:
> > I incorporated a huge patch from Dag-Erling Smorgrav [...]
> Here's more :)
Following up on myself, I introduced a bug in the previous round of
patches; here's a corrected patch against 0.3.
(the bug was that grep would always bail out if n
[accidentally b0rked the cc: line; apologies to those who get this twice]
Jason Thorpe writes:
> On 07 Jul 1999 20:57:16 +0200
> Dag-Erling Smorgrav wrote:
> > Don't use err() indiscriminately after a malloc() failure; malloc()
> > doesn't set errno.
> This is a bug in malloc(3), is it not?
On 07 Jul 1999 20:57:16 +0200
Dag-Erling Smorgrav wrote:
> Don't use err() indiscriminately after a malloc() failure; malloc()
> doesn't set errno.
This is a bug in malloc(3), is it not?
-- Jason R. Thorpe
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe free
Jamie Howard writes:
> I incorporated a huge patch from Dag-Erling Smorgrav [...]
Here's more :)
BTW, I assume you've read this:
http://www.opengroup.org/onlinepubs/007908799/xcu/grep.html>
I see you switched to using extended regexps by default, and made -E a
no-op; this breaks the ports c
Jamie Howard <[EMAIL PROTECTED]> writes:
> On 7 Jul 1999, Dag-Erling Smorgrav wrote:
> > I see you switched to using extended regexps by default, and made -E a
> > no-op; this breaks the ports collection, so I changed it back.
>
> The FreeBSD, NetBSD, and OpenBSD manpage for grep says this:
>
>
On 7 Jul 1999, Dag-Erling Smorgrav wrote:
> BTW, I assume you've read this:
>
>http://www.opengroup.org/onlinepubs/007908799/xcu/grep.html>
Of course, my copy of the printout is all marked up. :)
> I see you switched to using extended regexps by default, and made -E a
> no-op; this break
Jamie Howard writes:
> Ahh, this is a good idea. I have not yet replaced GNU grep on my system
> with this so it has not yet occurred to me that there might be issues with
> that.
I tried it; it works fine except for the lack of -w. Haven't tried 0.3
yet.
A good test is to build lots of ports,
Jamie Howard writes:
> Due to the number of fixes I have received over the past few days, I
> decided to put together a new release of grep. It was either this or
> watch _Titanic_ on Cinemax.
A clear-cut choice.
> I changed it so that even when called as grep or with -G, it treats the
> patte
Dag-Erling Smorgrav <[EMAIL PROTECTED]> writes:
> Jamie Howard <[EMAIL PROTECTED]> writes:
> > I incorporated a huge patch from Dag-Erling Smorgrav [...]
> Here's more :)
Following up on myself, I introduced a bug in the previous round of
patches; here's a corrected patch against 0.3.
(the bug w
[accidentally b0rked the cc: line; apologies to those who get this twice]
Jason Thorpe <[EMAIL PROTECTED]> writes:
> On 07 Jul 1999 20:57:16 +0200
> Dag-Erling Smorgrav <[EMAIL PROTECTED]> wrote:
> > Don't use err() indiscriminately after a malloc() failure; malloc()
> > doesn't set errno.
>
On 07 Jul 1999 20:57:16 +0200
Dag-Erling Smorgrav <[EMAIL PROTECTED]> wrote:
> Don't use err() indiscriminately after a malloc() failure; malloc()
> doesn't set errno.
This is a bug in malloc(3), is it not?
-- Jason R. Thorpe <[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAI
Jamie Howard <[EMAIL PROTECTED]> writes:
> I incorporated a huge patch from Dag-Erling Smorgrav [...]
Here's more :)
BTW, I assume you've read this:
http://www.opengroup.org/onlinepubs/007908799/xcu/grep.html>
I see you switched to using extended regexps by default, and made -E a
no-op; thi
Jamie Howard <[EMAIL PROTECTED]> writes:
> Ahh, this is a good idea. I have not yet replaced GNU grep on my system
> with this so it has not yet occurred to me that there might be issues with
> that.
I tried it; it works fine except for the lack of -w. Haven't tried 0.3
yet.
A good test is to b
Jamie Howard <[EMAIL PROTECTED]> writes:
> Due to the number of fixes I have received over the past few days, I
> decided to put together a new release of grep. It was either this or
> watch _Titanic_ on Cinemax.
A clear-cut choice.
> I changed it so that even when called as grep or with -G, i
On Tue, 6 Jul 1999, Sheldon Hearn wrote:
> The reason I'm suggesting using a port rather than having the code
> imported into the base system is that it allows people to "opt in" to
> testing it, rather than forcing it down people's throats. The idea is
> that, when it's proved itself as a port, e
On Tue, 6 Jul 1999, Sheldon Hearn wrote:
> The reason I'm suggesting using a port rather than having the code
> imported into the base system is that it allows people to "opt in" to
> testing it, rather than forcing it down people's throats. The idea is
> that, when it's proved itself as a port,
> One way to make it easier for people to test drive your software under
> FreeBSD is to create a port for the software (FreeBSD-style port, not
> NetBSD-style port).
very rough port available at http://gulf.uvic.ca/~jburkhol/grep.shar
--
To Unsubscribe: send mail to majord...@freebsd.org
wit
On Mon, 05 Jul 1999 21:14:36 -0400, Jamie Howard wrote:
> It would be really swank if someone were to go over what I have and make
> sure it is correct. I know I was blowing $ before, and I think that is
> correct now.
Hi Jamie,
One way to make it easier for people to test drive your software
> One way to make it easier for people to test drive your software under
> FreeBSD is to create a port for the software (FreeBSD-style port, not
> NetBSD-style port).
very rough port available at http://gulf.uvic.ca/~jburkhol/grep.shar
--
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "
On Mon, 05 Jul 1999 21:14:36 -0400, Jamie Howard wrote:
> It would be really swank if someone were to go over what I have and make
> sure it is correct. I know I was blowing $ before, and I think that is
> correct now.
Hi Jamie,
One way to make it easier for people to test drive your softwar
Due to the number of fixes I have received over the past few days, I
decided to put together a new release of grep. It was either this or
watch _Titanic_ on Cinemax.
I incorporated a huge patch from Dag-Erling Smorgrav which as he put it
"cleaned it up to make it conform to FreeBSD's coding styl
Due to the number of fixes I have received over the past few days, I
decided to put together a new release of grep. It was either this or
watch _Titanic_ on Cinemax.
I incorporated a huge patch from Dag-Erling Smorgrav which as he put it
"cleaned it up to make it conform to FreeBSD's coding sty
401 - 500 of 500 matches
Mail list logo
