Em 11-10-2012 19:09, Ian Lepore escreveu:
I want to build grep without the gnu regex library. The makefile for
usr.bin/grep contains
.if !defined(WITHOUT_GNU_COMPAT)
And man src.conf documents WITHOUT_GNU_SUPPORT but doesn't mention
WITHOUT_GNU_COMPAT. Is this a typo in the makefile,
Hi,
it has been more than 3 months ago that BSD sort became default in HEAD
and no serious complaints have been raised against it since then so I
plan to permanently remove GNU sort from head in the next days. If you
have any objection, please raise it now.
Gabor
Em 04-10-2012 16:50, Dennis Glatting escreveu:
On Thu, 2012-10-04 at 12:53 +0200, Gabor Kovesdan wrote:
Hi,
it has been more than 3 months ago that BSD sort became default in HEAD
and no serious complaints have been raised against it since then so I
plan to permanently remove GNU sort
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Folks,
as I announced before, the default sort in -CURRENT has been changed
to BSD sort. Since the import, the reported minor bugs have been
fixed and BSD sort has passed the portbuild test. If you encounter any
problems or incompatibility with
On 2012.06.27. 10:34, Doug Barton wrote:
Great, can you post the results somewhere? I understand what you're
saying below that there are situations where worse performance may need
explanation, but it would be helpful if we had the data to look at.
If something is buggy than it is not comparable
On 2012.06.27. 8:11, O. Hartmann wrote:
... so, can I delete the entry
WITH_BSD_SORT=yes
in /etc/src.conf then?
Yes. BSD sort will still be the default. And if you want default GNU
sort, you can add WITH_GNU_SORT=yes.
Gabor
___
On 2012.05.29. 5:44, 山谷崇史 wrote:
I had same problem, but I resolved it.
Maybe, your sort (/usr/bin/sort) is broken.
cd /usr/src
make update
cd usr.bin/sort
make obj depend all install
Then, sort is changed.
make cleandir cleandir
make buildworld
Could you please elaborate it a bit? From
On 2012.05.08. 17:51, Gabor Kovesdan wrote:
Hi Folks,
Oleg Moskalenko has been working very hard on BSD sort and by now we
think it is compatible with the base version (and has even more
features, the ideas mostly taken from the latest GNU sort) and it is
efficient. I just updated
On 2012.05.09. 1:21, Oleg Moskalenko wrote:
Michael,
The situation is actually more complex than I described in my email, but the
good news is that we already have a fix that supports all older syntax forms. I
tested it with ispell ports and it builds just fine. We will update the bsdsort
On 2012.05.09. 13:01, Hartmann, O. wrote:
On 05/09/12 12:44, Gabor Kovesdan wrote:
On 2012.05.09. 1:21, Oleg Moskalenko wrote:
Michael,
The situation is actually more complex than I described in my email,
but the good news is that we already have a fix that supports all
older syntax forms. I
Hi Folks,
Oleg Moskalenko has been working very hard on BSD sort and by now we
think it is compatible with the base version (and has even more
features, the ideas mostly taken from the latest GNU sort) and it is
efficient. I just updated the textproc/bsdsort port to the latest
version so
Em 03-05-2012 12:28, Steven Atreju escreveu:
Yes, of course.
Though i was kinda, even shocked, once i've seen this first:
http://marc.info/?l=dragonfly-commitsm=132241713812022w=2
I also experimented a bit with some trivial libc functions when testing
a change for memcpy (still in queue,
On 2012.03.14. 19:01, Mark Felder wrote:
Would it be appropriate to perhaps have a port option to
OVERWRITE_BASE and then people could just install that port, build
world and kernel... build a ton of ports. See if anything that might
possibly use it breaks?
Yes, I'm working on the update and
On 2012.03.14. 22:10, Adrian Chadd wrote:
So you could intall gnusort, bsdsort, and then some config file would
determine which was used.
'sort' would then be a symlink to said magic program, that'd look at
its argv[0], look at the contents of that file, and exec() the right
one.
I prefer
Hi Folks,
some time ago I started writing a BSDL sort variant from scratch since
the OpenBSD version did not support multibyte locales and was hard to
modify. The development was a bit stalled but recently, Oleg Moskalenko
oleg.moskale...@citrix.com showed interest in continuing this version
On 2012.01.05. 21:04, O. Hartmann wrote:
In FreeBSD 9 and 10, src.conf could be populated with those two knobs
WITH_ICONV
and
WITH_BSD_GREP
For some testing purposes, I switched them both to enabled, so I could
test ports and software against these.
I didn't realize any serious issue with
On 2011.09.19. 3:40, poyop...@puripuri.plala.or.jp wrote:
Hi,
I found another issue, this time in bsdgrep-20110912 in port.
Thanks for using BSD grep and reporting bugs! I've checked and confirmed
these issues. In my development branch I have already committed a
partial fix. It will be
Em 2011.08.09. 14:43, Test Rat escreveu:
It seems fnmatch(3) args were accidentally swapped. Try
$ bsdgrep -Fr --exclude-dir '*.svn*' grep_ usr.bin/grep | bsdgrep -c svn
72
Thanks! I'll commit this, too.
Gabor
___
freebsd-current@freebsd.org
.
Gabor Kovesdan
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Em 2011.08.10. 22:09, Alexander Best escreveu:
well i'd like to help the author of bsdgrep to improve it. testing it and
then going back to gnu grep, because bsdgrep still has bugs isn't going to help
much. by using it i'd like to trip over these kind of bugs and report them.
but you're
.
Gabor Kovesdan
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
.
The patch is here: http://kovesdan.org/patches/tre-20110724.diff
Regards,
Gabor Kovesdan
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr
Forgive me if I'm patronizing, but is there any surprise that a POSIX
NFA implementation is slower than grep's DFA?
Oh, of course an NFA implementation will always be slightly slower but
the memory footprint will also be smaller, which is a big advantage for
embedded systems. But in this
Hi Alexander,
for whatever historic reason I had WITH_ICONV in /etc/make.conf on my
desktop, so I got to be your guinea pig without conscious consent for
that role on my part. I did hit several issues so far:
thanks for your valuable comments about iconv and I'm sorry that you had
to try it out
by
setting the WITH_ICONV knob but whoever does it will take into account
that it may break some ports from being built. However, this change will
help me with future work and will also help interested people in getting
involved in the testing. The rather big changeset is coming soon.
Regards,
Gabor
Em 2010.08.19. 8:41, Doug Barton escreveu:
The performance is now almost comparable to GNU grep.
I think you're using a very liberal definition of comparable.
Ok, comparable for the casual cases but not generally comparable.
I think with this, BSD grep may remain default if no other
Em 2010.08.19. 23:42, b. f. escreveu:
Gabor:
One more thing to look into, in addition to the context problems,
ndisgen breakage, and problems on certain file systems:
At r211506, 'grep -wq' does not seem to work properly (in the very
least, it is not the same as with GNU grep), and has broken
Em 2010.08.21. 4:31, Mike Haertel escreveu:
Hi Gabor,
I am the original author of GNU grep. I am also a FreeBSD user,
although I live on -stable (and older) and rarely pay attention
to -current.
However, while searching the -current mailing list for an unrelated
reason, I stumbled across
Later on, he summarizes some of the existing implementations,
including comments about the Plan 9 implementation and his own RE2,
both of which efficiently handle international text (which seems to
be a major concern of Gabor's).
I believe Gabor is considering TRE for a good replacement
Hi all,
there are some consequences that we can see from the grep case. Here I'd
like to add a summary, which raises some questions. All comments are
welcome.
1, When grep entered -CURRENT and bugs were found I immediately got kind
bug reports and sharp criticism, as well. According to my
Em 2010.08.18. 7:42, poyop...@puripuri.plala.or.jp escreveu:
Hi Gabor and others,
As Gabor committed r211364, bsdgrep now works nicely with tail -f.
http://svn.freebsd.org/changeset/base/211364
Thank you very much.
Acknowledgements also go to you and other users. Without quality
feedback I
Em 2010.08.13. 10:43, Doug Barton escreveu:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Gabor,
I hope at this point it goes without saying that I have a lot of respect
for the work you've done on BSD grep, and I've already told you that I
think you're very courageous for taking the
Em 2010.08.18. 19:37, Rui Paulo escreveu:
On 18 Aug 2010, at 18:18, Garrett Cooper wrote:
On Wed, Aug 18, 2010 at 9:23 AM, Rui Paulorpa...@gmail.com wrote:
Hi,
I've been chatting with the ICC ex-users and they seem to be ok with the
removal of the ICC bits from share/mk and other places.
Em 2010.08.15. 21:49, Dimitry Andric escreveu:
GNU grep
Elapsed time: 57 seconds
BSD grep (original)
Elapsed time: 820 seconds (~14.4x slower than GNU grep)
BSD grep (quickfixed)
Elapsed time: 115 seconds (~2.0x slower than GNU grep)
It proves that getting rid of the
Em 2010.08.16. 16:11, Dag-Erling Smørgrav escreveu:
Sean C. Farleys...@freebsd.org writes:
Dag-Erling Smørgravd...@des.no writes:
Did you actually test your patch? It makes absolutely no measurable
difference.
Yes, I saw a reduction,
I didn't...
I also saw a
Em 2010.08.15. 21:07, Dag-Erling Smørgrav escreveu:
Ignore the first two lines (that's the profiling code itself). Note
that the top five lines are all in stdio, and nothing else even shows up
on the radar. I only included enough output to show where the regexp
code ranks; the complete output
Em 2010.08.13. 10:52, Roman Divacky escreveu:
what about optimizing BSD grep instead?
[... picking one mail from the many that suggest this ...]
The problem is that optimization is not that trivial. I think the
bottleneck is the regex library because:
1, BSD grep is so simple. There may
Em 2010.08.14. 17:53, Andrey Chernov escreveu:
On Fri, Aug 13, 2010 at 01:43:16AM -0700, Doug Barton wrote:
Gabor,
I hope at this point it goes without saying that I have a lot of respect
I am Nth on this. Although I do a lot of l10n work in the beautefull less
bureocracy FreeBSD
Em 2010.08.13. 10:43, Doug Barton escreveu:
My reason is simple, performance. While doing some portmaster work
recently I was regression testing some changes I made to the --index*
options and noticed that things were dramatically slower than the last
time I tested those features. Thinking that
Em 2010.08.13. 13:09, Matthias Andree escreveu:
Gabor Kovesdan wrote on 2010-08-13:
Em 2010.08.13. 10:43, Doug Barton escreveu:
My reason is simple, performance. While doing some portmaster work
recently I was regression testing some changes I made to the --index*
options and noticed
Em 2010.08.13. 13:33, Anonymous escreveu:
Doug Bartondo...@freebsd.org writes:
[...]
My reason is simple, performance. While doing some portmaster work
recently I was regression testing some changes I made to the --index*
options and noticed that things were dramatically slower than the
Em 2010.08.10. 19:45, Anonymous escreveu:
Seems like APACHE_MODULES is incorrectly populated.
$ make -V APACHE_MODULES BATCH= GREP=${LOCALBASE-/usr/local}/bin/grep |
fgrep cache
...cache disk_cache file_cache...
$ make -V APACHE_MODULES BATCH= | fgrep cache
...disk_cache
Em 2010.08.09. 21:34, Gennady Proskurin escreveu:
I see misbehaviour of new bsd grep in freebsd on tmpfs when grepping dirs.
For example (on tmpfs /tmp):
mkdir /tmp/qwe
grep something /tmp/qwe
(grep hangs)
Thank you for the report, I'm already aware of the issue and preparing a
fix for it.
Em 2010.08.04. 20:06, Xin LI escreveu:
I'm able to reproduce the GNU behavior on 9.0-CURRENT which is IMO right.
I think we need to break at the line end to provide better interactivity
(the current code seems to do it (buffer is not full !eof), while
what we wanted is (buffer is not full
Em 2010.08.03. 19:25, poyop...@puripuri.plala.or.jp escreveu:
Hi,
It seems bsdgrep does not work when piped from tail -f.
I'm running r210728.
term0$ jot 10 /tmp/1
term0$ tail -f /tmp/1 | grep 0
[no output]
otherterm$ jot 10 /tmp/1
[no output to term0]
=
with GNU grep:
term0$ tail -f
Em 2010.07.27. 5:59, b. f. escreveu:
Other important differences between bsdgrep and GNU grep:
The --include option in bsdgrep does not have the same effect as the
corresponding option in GNU grep -- in GNU grep, that option causes
_only_ those files matching the file inclusion pattern to be
Em 2010.07.28. 17:26, b. f. escreveu:
I don't think that the current behavior of bsdgrep is necessarily bad
-- in fact it seems to me to be simple and intuitive: nothing is
excluded or included implicitly, and (I think) the last match wins,
unlike in gnu grep. I mention it only because it is
Em 2010.07.28. 17:48, Dag-Erling Smørgrav escreveu:
Gabor Kovesdanga...@freebsd.org writes:
b. f.bf1...@gmail.com writes:
I don't think that the current behavior of bsdgrep is necessarily bad
-- in fact it seems to me to be simple and intuitive: nothing is
excluded or included
`-l' option is not supposed to show the matching line at all, only filename.
Thanks. Fix is ready and waiting for my mentor's approval.
http://kovesdan.org/patches/grep-lL.diff
Gabor
___
freebsd-current@freebsd.org mailing list
I think it should behave like ls(1) and gnu grep(1) and strip color
sequences if stdout is not associated with terminal.
Thanks for letting me know about this. The fix is being worked on just
like for the -q/-l bug.
Gabor
___
Em 2010.07.24. 6:19, Doug Barton escreveu:
There are several places in portmaster where I use '[e]grep -ql foo'
to signal existence of something without having to deal with the
output of grep. In oldgrep this worked as advertised. In bsdgrep it
doesn't.
Furthermore, looking at the code it
Hi folks,
Steven Kreuzer wrote a periodic script to run csup updates with periodic
daily. I've reviewed it and added support for multiple supfiles. I'd
like to commit this to head.
http://kovesdan.org/files/600.csup
Is there any objection?
Gabor
Em 2010.07.16. 16:15, Jilles Tjoelker escreveu:
Hmm, /usr/src/Makefile has an 'update' target that can run csup and
other updating tools. Perhaps it should call that instead?
It is not just for updating your src tree but your ports tree, doc tree
or eventually your local CVS repo. That's
Em 2010.07.16. 16:23, Alex Kozlov escreveu:
On Fri, Jul 16, 2010 at 03:58:33PM +0200, Gabor Kovesdan wrote:
Thousands pc simultaneously try to access cvsup servers?
Sound like a ddos to me.
Yes, this was the only concern and that's why I started this discussion.
Btw, if You have time
Em 2010.07.06. 17:54, Anonymous escreveu:
BTW, I think there is regression in iconv(1). It wasn't there in
iconv_base_integrate2.diff.
(gdb) r
Starting program: /usr/bin/iconv
During symbol reading, DW_AT_name missing from DW_TAG_base_type.
During symbol reading, cannot get low and
Em 2010.07.04. 17:58, Anonymous escreveu:
Do you create /usr/lib32/i18n directory before installing into it?
Oh, I'm sorry I just tested cross-building but not normal building on
amd64. This patch seems to fix the issue, I've added the necessary
directories to mtree:
Em 2010.06.17. 23:21, Anonymous escreveu:
If cross-compiling doesn't work, how did you build the former one that
gave you that error?
Here is my guess
libiconv_modules compiles fine but installs both normal and lib32 objdir
into /usr/lib when lib32 should use /usr/lib32.
Em 2010.06.17. 23:21, Anonymous escreveu:
Gabor Kovesdanga...@freebsd.org writes:
[...]
$ make installworld TARGET=i386 DESTDIR=/b/bbb
...
=== usr.bin/mkcsmapper (install)
install -s -o root -g wheel -m 555 mkcsmapper /b/bbb/usr/bin
strip:
build the former one that
gave you that error?
--
Gabor Kovesdan
FreeBSD Volunteer
EMAIL: ga...@freebsd.org .:|:. ga...@kovesdan.org
WEB: http://people.FreeBSD.org/~gabor .:|:. http://kovesdan.org
___
freebsd-current@freebsd.org mailing list
http
.
--
Gabor Kovesdan
FreeBSD Volunteer
EMAIL: ga...@freebsd.org .:|:. ga...@kovesdan.org
WEB: http://people.FreeBSD.org/~gabor .:|:. http://kovesdan.org
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
for your comments.
--
Gabor Kovesdan
FreeBSD Volunteer
EMAIL: ga...@freebsd.org .:|:. ga...@kovesdan.org
WEB: http://people.FreeBSD.org/~gabor .:|:. http://kovesdan.org
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman
this.
--
Gabor Kovesdan
FreeBSD Volunteer
EMAIL: ga...@freebsd.org .:|:. ga...@kovesdan.org
WEB: http://people.FreeBSD.org/~gabor .:|:. http://kovesdan.org
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
compatibility. This will be important for ports. This is also
the reason why BSD grep is linked to GNU regex instead of libc-regex.
--
Gabor Kovesdan
FreeBSD Volunteer
EMAIL: ga...@freebsd.org .:|:. ga...@kovesdan.org
WEB: http://people.FreeBSD.org/~gabor .:|:. http://kovesdan.org
this one. The new patch
is here:
http://www.kovesdan.org/patches/iconv_base_integrate2.diff
And a gzipped version:
http://www.kovesdan.org/patches/iconv_base_integrate2.diff.gz
--
Gabor Kovesdan
FreeBSD Volunteer
EMAIL: ga...@freebsd.org .:|:. ga...@kovesdan.org
WEB: http://people.FreeBSD.org
that with a clean unpatched src tree and I'm not using any CFLAGS
tweak or such.
If you haven't done make clean yet, you can resume the build with:
make buildworld -DNO_CLEAN WERROR= CWARNFLAGS=
--
Gabor Kovesdan
FreeBSD Volunteer
EMAIL: ga...@freebsd.org .:|:. ga...@kovesdan.org
WEB: http
/bsc_iconv.pdf
The rather big patch (42,5M) is available here:
http://www.kovesdan.org/patches/iconv_base_integrate.diff
Any comments, suggestions or bugreports are very welcome.
--
Gabor Kovesdan
FreeBSD Volunteer
EMAIL:ga...@freebsd.org .:|:.ga...@kovesdan.org
WEB:http://people.FreeBSD.org/~gabor
have an Atom-based netbook and it takes quite long but not that
long. I usually compile kernel/world directly there. One battery charge
(which make it last~4 hours) is enough for me to do a complete upgrade.
--
Gabor Kovesdan
FreeBSD Volunteer
EMAIL: ga...@freebsd.org .:|:. ga...@kovesdan.org
WEB
67 matches
Mail list logo
