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 mak
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 s
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
_
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
___
freebsd-current@freebs
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
-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 th
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 you
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 the
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 fi
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
por
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 that
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-commits&m=132241713812022&w=2
I also experimented a bit with some trivial libc functions when testing
a change for memcpy (still in queue, w
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 simpli
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 i
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
showed interest in continuing this version
and he has made a very goo
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 WI
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 fixed
rting bugs.
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 right...
ut probably not
the best.
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.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 ma
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 case,
effort to give it a try.
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 mai
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
ed 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,
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 u
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 re
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 some
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.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 se
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 Paulo 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.
The reason is that
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 project
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 m
Em 2010.08.16. 16:11, Dag-Erling Smørgrav escreveu:
"Sean C. Farley" writes:
Dag-Erling Smørgrav 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 reduction by 8-30% dependin
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 fgetc'
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 i
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 tim
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 be
Em 2010.08.13. 13:33, Anonymous escreveu:
Doug Barton 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 last
time I tested
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 that
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 I
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 file_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
Em 2010.07.28. 17:48, Dag-Erling Smørgrav escreveu:
Gabor Kovesdan writes:
b. f. 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 implicitly, and (I think) the
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 dif
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 sea
`-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
http://lists.free
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
___
freebsd-current@fre
Em 2010.07.24. 6:19, Doug Barton escreveu:
There are several places in portmaster where I use '[e]grep -ql '
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 doesn'
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
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 why
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.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:
http://kovesdan.org/pa
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.
mkcsmapper/mkesd
Em 2010.06.17. 23:21, Anonymous escreveu:
Gabor Kovesdan 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: /b/bbb/usr/bin/mkcsmapper: File for
El 2010. 06. 17. 23:21, Anonymous escribió:
Gabor Kovesdan 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: /b/bbb/usr/bin/mkcsmapper: File for
to find out how ia32 compatibility works.
--
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
esn't work, how did you 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@f
rting 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-
t it. I don't know why I'm having that, tohugh, I also
have 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=&quo
some minor warnings, including 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
WE
ould support them to
maintain 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/~g
ian language:
http://www.kovesdan.org/files/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..
I also 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...@kovesd
67 matches
Mail list logo
