On Wed, Aug 18, 2010 at 12:48:53PM +0200, Ed Schouten wrote:
Hi Daichi,
I think Keith Packard of Xorg once wrote a commit message along the
lines of 5000 lines of code removed, feature added This seems to be
similar, albeit on a smaller scale. ;-)
Apart from this issue with unionfs, I am
Gabor PALI p...@freebsd.org writes:
Dag-Erling Smørgrav d...@des.no writes:
Gabor PALI p...@freebsd.org writes:
Sorry for chiming in, just a quick idea. If you find the get a
high-level language that compiled to C idea good,
I don't think it's a good idea
Could you be more specific on
Randi Harper sek...@gmail.com writes:
Rui Paulo rpa...@freebsd.org writes:
You are correct. We should not be ejecting the CD without a
prompt. If the commit is reverted, it should be explicitly noted in
the code so that we don't do this mistake again.
That's a judgement call, not an
gahn ipfr...@yahoo.com writes:
I am running 8.1. under /dev, I don't see /dev/md0,
/dev/md0 won't show up until you actually run mdconfig.
so i am trying to add following lines in kernel file and got error
messages:
options MFS #Memory Filesystem
The correct line is
Mike Haertel m...@ducky.net writes:
GNU grep uses the well-known Boyer-Moore algorithm, which looks
first for the final letter of the target string, and uses a lookup
table to tell it how far ahead it can skip in the input whenever
it finds a non-matching character.
Boyer-Moore is for fixed
Nathan Whitehorn nwhiteh...@freebsd.org writes:
Dag-Erling Smørgrav d...@des.no writes:
I'm not sure I understand what you mean (or rather, how it would
help the tinderbox). What *would* help would be an easy way to
determine, *before* trying to build it, whether a specific kernel
config
Am 22.08.2010 13:21, schrieb Dag-Erling Smørgrav:
Gabor PALI p...@freebsd.org writes:
Dag-Erling Smørgrav d...@des.no writes:
Gabor PALI p...@freebsd.org writes:
Sorry for chiming in, just a quick idea. If you find the get a
high-level language that compiled to C idea good,
I don't think
TB --- 2010-08-22 11:13:56 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2010-08-22 11:13:56 - starting HEAD tinderbox run for powerpc64/powerpc
TB --- 2010-08-22 11:13:56 - cleaning the object tree
TB --- 2010-08-22 11:14:44 - cvsupping the source tree
TB --- 2010-08-22 11:14:44 -
On Sat, Aug 21, 2010 at 01:49:45PM -0400, Michael Butler wrote:
While updating sysutils/coreutils port on -current as of this morning
(SVN r211550), I noted a panic during the directory rename config test.
Your problem seems identical to this report:
Dear FreeBSD community,
many of our [2] (and Solaris [3]) users today are complaining about slow
ZFS writes. One of the causes for these writes is the selection of the
proper allocation method for allocation of new blocks [3] [4]. Another
issue a write slowdown during TXG sync times.
Solaris 10
Matthias Andree mand...@freebsd.org writes:
Looks a bit like a swing. First we remove Perl from the base system
(years ago) and move to sed/awk, now we discuss using a scripting
language in the base system...
Read the discussion from the beginning. We are discussing introducing a
In article 86k4nikglg@ds4.des.no you write:
Mike Haertel m...@ducky.net writes:
GNU grep uses the well-known Boyer-Moore algorithm, which looks
first for the final letter of the target string, and uses a lookup
table to tell it how far ahead it can skip in the input whenever
it finds a
2010/8/22 Martin Matuska m...@freebsd.org:
Dear FreeBSD community,
many of our [2] (and Solaris [3]) users today are complaining about slow
ZFS writes. One of the causes for these writes is the selection of the
proper allocation method for allocation of new blocks [3] [4]. Another
issue a
2010/8/22 Dag-Erling Smørgrav d...@des.no:
Amen. The current bottleneck in BSD grep is the memchr() that looks for
'\n' in the input buffer.
FYI I actually have a rewritten memchr() which is faster than the
current one here:
http://people.freebsd.org/~delphij/for_review/memchr.c
Thank you, I have updated the v15 patch for 8-STABLE.
Dňa 22. 8. 2010 17:44, Olivier Smedts wrote / napísal(a):
2010/8/22 Martin Matuska m...@freebsd.org:
Dear FreeBSD community,
many of our [2] (and Solaris [3]) users today are complaining about slow
ZFS writes. One of the causes for these
On Sun, 22 Aug 2010, Dag-Erling Smørgrav wrote:
Mike Haertel m...@ducky.net writes:
GNU grep uses the well-known Boyer-Moore algorithm, which looks first
for the final letter of the target string, and uses a lookup table to
tell it how far ahead it can skip in the input whenever it finds a
* Mike Haertel m...@ducky.net wrote:
Moreover, GNU grep AVOIDS BREAKING THE INPUT INTO LINES. Looking
for newlines would slow grep down by a factor of several times,
because to find the newlines it would have to look at every byte!
I think that implementing a simple fgrep boils down to
On Aug 22, 2010, at 8:02 AM, Garrett Wollman wrote:
In article 86k4nikglg@ds4.des.no you write:
Mike Haertel m...@ducky.net writes:
GNU grep uses the well-known Boyer-Moore algorithm, which looks
first for the final letter of the target string, and uses a lookup
table to tell it how far
In article 20100822163644.gu2...@hoeg.nl you write:
I think that implementing a simple fgrep boils down to mmap()ing a file
and calling memmem() on the mapping to search for the input string. Of
course this relies on having an efficient memmem() implementation, for
example using one of the
On 08/22/10 07:10, Dag-Erling Smørgrav wrote:
Nathan Whitehornnwhiteh...@freebsd.org writes:
Dag-Erling Smørgravd...@des.no writes:
I'm not sure I understand what you mean (or rather, how it would
help the tinderbox). What *would* help would be an easy way to
determine, *before*
On Aug 22, 2010, at 9:30 AM, Sean C. Farley wrote:
On Sun, 22 Aug 2010, Dag-Erling Smørgrav wrote:
Mike Haertel m...@ducky.net writes:
GNU grep uses the well-known Boyer-Moore algorithm, which looks first for
the final letter of the target string, and uses a lookup table to tell it
how far
Dag-Erling Sm�rgrav d...@des.no writes:
Mike Haertel m...@ducky.net writes:
GNU grep uses the well-known Boyer-Moore algorithm, which looks
first for the final letter of the target string, and uses a lookup
table to tell it how far ahead it can skip in the input whenever
it finds a
Sean C. Farley s...@freebsd.org writes:
Some algorithms:
1. http://en.wikipedia.org/wiki/Aho-Corasick_string_matching_algorithm
Aho-Corasick is not really a search algorithm, but an algorithm for
constructing a table-driven finite state machine that will match either
of the search strings you
Mike Haertel m...@ducky.net writes:
For example if your regex is /foo.*bar/, the initial Boyer-Moore search
is (probably) searching for foo.
If the initial search succeeds, GNU grep isolates the containing line,
and then runs the full regex matcher on that line to make sure.
You don't really
Dag-Erling Smørgrav d...@des.no writes:
Mike Haertel m...@ducky.net writes:
For example if your regex is /foo.*bar/, the initial Boyer-Moore search
is (probably) searching for foo.
If the initial search succeeds, GNU grep isolates the containing line,
and then runs the full regex
On Sun, 22 Aug 2010, Dag-Erling Smørgrav wrote:
Sean C. Farley s...@freebsd.org writes:
Some algorithms:
1. http://en.wikipedia.org/wiki/Aho-Corasick_string_matching_algorithm
Aho-Corasick is not really a search algorithm, but an algorithm for
constructing a table-driven finite state
On Sun, 22 Aug 2010, Tim Kientzle wrote:
On Aug 22, 2010, at 9:30 AM, Sean C. Farley wrote:
On Sun, 22 Aug 2010, Dag-Erling Smørgrav wrote:
Mike Haertel m...@ducky.net writes:
GNU grep uses the well-known Boyer-Moore algorithm, which looks
first for the final letter of the target string, and
Thanks to help from Andriy I've been working on narrowing down the cause
of my runaway intr problems and we've found some interesting things.
First, if I use neither powerd nor set hw.acpi.cpu.cx_lowest less than
C1 things seem to work fine. Using one or the other sort of works, but
between
28 matches
Mail list logo
