Em 05-02-2013 03:48, Eitan Adler escreveu:
Is the following page still useful?
Yes.
Gabor
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr
Em 27-10-2012 23:17, hiren panchasara escreveu:
> Hi Pedro / List,
>
> I am not part of google summer of code but I've tried to port patch(1) from
> NetBSD into FreeBSD head. I hope that is okay.
>
> Patching was trivial and It _seems_ to be working fine.
>
> I would appreciate any ideas around
On 2012.07.08. 1:17, Doug Barton wrote:
Other than authoritative DNS, what features does unbound lack that you want?
[Picking up a random mail from the thread.]
Other than the functionality, when we replace something, it is also
important to do some benchmarks and assure that the performance i
On 2012.04.17. 23:03, Matthew Story wrote:
Just wondering what the current status is on a BSD diff replacement.
The IdeasPage suggests that a goodly amount of work was done on this
for GSoC 2010
(http://wiki.freebsd.org/IdeasPage#BSD-licensed_Text-Processing_Tools), but
the GPLinBase page say
On 2012.01.19. 3:06, Igor Mozolevsky wrote:
You mean something like:http://people.freebsd.org/~edwin/gnats/ ?
It is not up to date. I have not closed too many PRs in the last 3
months and I'm still on the top PR closers list.
Gabor
___
freebsd-hacke
Em 08-07-2011 13:23, Ivan Voras escreveu:
On 08/07/2011 05:42, Ilya Bakulin wrote:
Hi hackers,
As a part of ongoing effort to enhance usage of Capsicum in FreeBSD base
system, I want to ask you, which applications in the base system should
receive sandboxing support.
How about a small descript
Thanks to all for the valuable comments.
I've decided to continue the work with TRE because
- Many people don't like the idea of adding C++ code into libc
- I'm not very skilled in C++
However, in a later phase of development, I think re2 may be a good
source of ideas in optimizing the performan
Em 09-05-2011 06:44, Tim Kientzle escreveu:
Have you asked the TRE maintainers if they would accept this change?
If they would, then getting this change into TRE would benefit a lot more
people than just FreeBSD's libc.
This is a longer term goal. First, I prefer having something to talk
about
Em 09-05-2011 02:17, Bakul Shah escreveu:
As per the following URLs re2 is much faster than TRE (on the
benchmarks they ran):
http://lh3lh3.users.sourceforge.net/reb.shtml
http://sljit.sourceforge.net/regex_perf.html
re2 is in C++& has a PCRE API, while TRE is in C& has a
POSIX API. Both hav
Hi Folks,
I've been given the opportunity to work in GSoC 2011 to replace our base
regex library with a more modern one and given that the regex code is
something essential probably there are lots of interested parties so I
decided to open a thread here about my plans and the approach that I
Em 2010.07.16. 12:17, pluknet escreveu:
Almost the same (#__jid_t#jid_t#).
Did you have to include any header for that? IIRC, I used __jid_t
because it didn't compile with jid_t.
The difference (and probably a trigger of bug elsewhere) might be in
that this lives
on amd64 arch (while yours
Em 2010.07.13. 16:05, pluknet escreveu:
#ifndef _SYS_SYSPROTO_H_
struct setjlimit_args {
jid_t jid;
int resource;
struct rlimit *rlp;
};
#endif
int
setjlimit(td, uap)
struct thread *td;
struct setjlimit_args /* {
jid_t jid;
Em 2010.07.12. 9:00, pluknet escreveu:
Looking at getjid() impl, I see you're trying to put jid_t into the
one register_t
which are 64-bit vs 32-bit capable respectively.
You need to cast so you put 64-bit into two 32-bit as done for e.g. lseek().
Thanks for pointing this out, probably this w
Em 2010.07.11. 17:33, m...@freebsd.org escreveu:
What does struct killjob_args look like?
It's just what make sysent generated:
+struct killjob_args {
+ char jid_l_[PADL_(__jid_t)]; __jid_t jid; char jid_r_[PADR_(__jid_t)];
+ char signal_l_[PADL_(int)]; int signal; char signal_r
Em 2010.07.11. 16:54, Dimitry Andric escreveu:
On 2010-07-11 16:46, Gabor Kovesdan wrote:
I have two int64_t variables in kernel code, first is stored internally
and the second one is passed from a syscall argument. When I print them
with printf %lld modifier, the internal one behaves
Hi,
I have two int64_t variables in kernel code, first is stored internally
and the second one is passed from a syscall argument. When I print them
with printf %lld modifier, the internal one behaves correctly but the
other one I pass from a syscall has a corrupted value. If I pass 1, it
prin
as a standalone lib. Now it works, thanks!
--
Gabor Kovesdan
FreeBSD Volunteer
EMAIL: ga...@freebsd.org .:|:. ga...@kovesdan.org
WEB: http://people.FreeBSD.org/~gabor .:|:. http://kovesdan.org
___
freebsd-hackers@freebsd.org mailing list
http
Patch is here: http://kovesdan.org/patches/iconv-libc.diff
Thanks,
--
Gabor Kovesdan
FreeBSD Volunteer
EMAIL: ga...@freebsd.org .:|:. ga...@kovesdan.org
WEB: http://people.FreeBSD.org/~gabor .:|:. http://kovesdan.org
___
freebsd-hackers@freebsd.o
Hi Alfred,
Hello,
Where is diff/sdiff projects?
there's an incomplete version of diff in my perforce branch. I added
wchar support but it introduced some regresssions. No progress since
then. As for sdiff, Steven Kreuzer did some progress there but I don't
know details.
Gabor
___
On 30/03/2010 20:00, Mark nesterovych wrote:
Hi all.
Decided to write BSD licensed grep and provide it to FreeBSD project if
success.
Dear Mark,
this project is already completed and is going to be integrated to the
base system once portmgr can run an experimental build to make sure it
Gabor Kovesdan escribió:
Alexander Best escribió:
any thoughts on these small changes to burncd?
-int nogap = 0, speed = 4 * 177, test_write = 0, force = 0;
+int nogap = 0, speed = 0, test_write = 0, force = 0;
int block_size = 0, block_type = 0, cdopen = 0, dvdrw = 0;
const
t;SPEED") to a char *
variable and if it isn't NULL then you should convert it to int or fall
back to the default value otherwise.
--
Gabor Kovesdan
FreeBSD Volunteer
EMAIL: ga...@freebsd.org .:|:. ga...@kovesdan.org
WEB: http://people
issue. You can declare
extern char *__progname;
and use it to parse the command line arguments in a different way. Of
course, it only makes sense if pkill/pgrep has some inner functionality
you can make use of to avoid duplication.
--
Gabor Kovesdan
FreeBSD Volunteer
EMAIL: ga...@freebsd.or
old, slow and doesn't support wchar, at all.
Btw, do you mind if I include your script into the BSD grep
distribution? I already planned to write something like this for future
testing.
--
Gabor Kovesdan
FreeBSD Volunteer
EMAIL: ga...@freebsd.org .:|:. ga...@kovesdan.org
WEB: http://peop
you will find it way too
difficult and you won't enjoy. Anyway, the book of Marshall K. McKusick
and George V. Neville-Neil is a good source of learning kernel stuff:
http://www.amazon.com/Design-Implementation-FreeBSD-Operating-System/dp/0201702452
Regards,
--
Gabor Kovesdan
FreeBSD
Dag-Erling Smørgrav escribió:
Gabor Kovesdan writes:
What I noticed is that the patch sets WARNS?=0 for a lot of utilities,
which actually have higher WARNS-compliance.
WARNS level 0 is the current default. All Ulrich's patch does is
reverse the logic so that WARNS is 6 by de
I'm sure it will
compile with at least WARNS=3.
--
Gabor Kovesdan
FreeBSD Volunteer
EMAIL: ga...@freebsd.org .:|:. ga...@kovesdan.org
WEB: http://people.FreeBSD.org/~gabor .:|:. http://kovesdan.org
___
freebsd-hackers@freebsd.org mailing list
ht
terated
output and it has some more advanced mappings to do this. Apart from
this, almost all encodings are supported, that we have in locale(1)
charmaps but the Big5 module segfaults. I hope I'll be able to solve
these issues and check performance as part of my BSc thesis.
Regards,
--
G
duce this but only in the jail.
Regards,
--
Gabor Kovesdan
FreeBSD Volunteer
EMAIL: ga...@freebsd.org .:|:. ga...@kovesdan.org
WEB: http://people.FreeBSD.org/~gabor .:|:. http://kovesdan.org
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebs
is a bad
assumption, but something Americans and Europeans naturally don't have
to care about.
Cheers,
--
Gabor Kovesdan
FreeBSD Volunteer
EMAIL: ga...@freebsd.org .:|:. ga...@kovesdan.org
WEB: http://people.FreeBSD.org/~gabor .:|:. http://kovesdan.org
__
bout POSIX if it has something related?
Personally, I think that these are more important questions than support
of some extremely rare languages. It's worth to consider how to deal
with them later but the basic problems need a higher priority.
[1] http://en.wikipedia.org/wiki/Tengwar#Unic
t is
whether it would make more sense to standardize on something like
UCS-4 for the internal representation.
I haven't got to such details yet, so I didn't know this. But UCS-4
seems to be reasonable for me.
Cheers,
--
Gabor Kovesdan
FreeBSD Volunteer
EMAIL: ga...@freebsd.org .:|:. g
Andrey Chernov ha scritto:
Just from quick looking at the sources...
This code looks suspicious:
wend = sscanf(&l->dat[pmatch.rm_eo], "%lc", &wend);
Perhaps it should be
if (sscanf(&l->dat[pmatch.rm_eo], "%lc", &wend) != 1)
r = REG_NOMATCH;
The next thing is that perhaps each r = REG
Hello all,
I've reviewed BSD grep based on your comments and the bug reports I
received. The new version is committed to the ports tree as
textproc/bsdgrep and there is a base patch available:
http://kovesdan.org/patches/grep-base.diff
I've asked portmgr to test my patch on pointyhat if they
Sean C. Farley ha scritto:
On Thu, 7 Aug 2008, Gabor Kovesdan wrote:
Sean C. Farley ha scritto:
You are testing c which has not been set. It works OK if you set c
then do the test:
+ c = fgetc(f);
if (c != EOF)
- printf("%c\n", fgetc(f));
+
Sean C. Farley ha scritto:
You are testing c which has not been set. It works OK if you set c then
do the test:
+ c = fgetc(f);
if (c != EOF)
- printf("%c\n", fgetc(f));
+ printf("%c\n", c);
Yes, you are right, this is what I meant, I'm just a bit diso
Hello,
I'm wondering why fgetc() returns 0xff if called with /dev/null:
#include
#include
int
main(void)
{
int c;
FILE*f;
f = fopen("/dev/null", "r");
if (c != EOF)
printf("%c\n", fgetc(f));
}
> gcc foo.c
> ./a.out
ÿ
This causes a bug in
Kris Kennaway escribió:
Andrey Chernov wrote:
On Mon, Jul 07, 2008 at 10:06:31PM +0200, Kris Kennaway wrote:
What regression suites do other implementations have? e.g. the GNU
textutils.
They basically have regex tests, but nothing locale specific, since
locale ordering is different from pl
1) You can't convert just whole buffer after fread() since it can be
ended in the middle of multibyte sequence on BUFSIZ edge. Look how GNU
utils do it.
OK, now I haven't thought of this aspect. What about this?
#define iswbinary(ch) (!iswspace((ch)) && iswcntrl((ch)))
int
bin_file(FI
Andrey Chernov escribió:
On Wed, Jun 18, 2008 at 12:40:24PM +0200, Dag-Erling Sm??rgrav wrote:
For grep, I believe it should simply be a matter of calling setlocale(),
using wide strings, and using a multibyte regex engine (for appropriate
values of "simply").
See my prev reply telling
Jaakko Heinonen escribió:
On 2008-06-17, Gabor Kovesdan wrote:
egrep: empty (sub)expression
I've looked at this and I have a patch with a workaround:
http://kovesdan.org/patches/grep.dougb.diff
Unfortunately this breaks things. For example:
$ grep -E '(test||test)&
Doug Barton escribió:
I use the following construct in portmaster, where pdb=/var/db/pkg,
origin is set to the origin of a given port, and ro_opd is usually
empty, but can be another origin directory or the same one. To
guarantee that you should get some kind of results you can test with
origi
Doug Barton escribió:
I use the following construct in portmaster, where pdb=/var/db/pkg,
origin is set to the origin of a given port, and ro_opd is usually
empty, but can be another origin directory or the same one. To
guarantee that you should get some kind of results you can test with
origi
Andrey Chernov escribió:
On Tue, Jun 17, 2008 at 10:54:42AM +0200, Konrad Jankowski wrote:
Diomidis Spinellis wrote:
Gabor Kovesdan wrote:
In case of sort, I understarnd that it should explicitly handle wide
characters due to the different alphabet of the different languages
Andrey Chernov escribió:
On Tue, Jun 17, 2008 at 04:28:10AM +0400, Andrey Chernov wrote:
BSD grep is even not bothering to call setlocale(). I can't say is it can
be simple healed by adding that call, some test suite run is needed.
Quick source inspection reveals that BSD grep operates
u response! I'll look at this issue.
Regards,
--
Gabor Kovesdan
EMAIL: [EMAIL PROTECTED]
WWW: http://www.kovesdan.org
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any
Hello All,
Today I've basically terminated te feature-completion of the
BSD-licensed grep from OpenBSD. It means, that I've accomplished the
following tasks:
- Implement --label
- Implement --null
- Implement --color / --colour
- Implement -D / --devices
- Implement -H / --with-filename
- Impl
Hello all,
as you might have already known, I'm working on the BSD-licensed
versions of these utilities, porting them from OpenBSD and complete the
functionality. Still, I have a lot to do, but here's a little bit of
status report:
grep:
- Implemented --label
- Implemented --null
- Implemented -
Hello all,
as you might have already known, I'm working on the BSD-licensed
versions of these utilities, porting them from OpenBSD and complete the
functionality. Still, I have a lot to do, but here's a little bit of
status report:
grep:
- Implemented --label
- Implemented --null
- Implemented -
Hello all,
as you might have already known, I'm working on the BSD-licensed
versions of these utilities, porting them from OpenBSD and complete the
functionality. Still, I have a lot to do, but here's a little bit of
status report:
grep:
- Implemented --label
- Implemented --null
- Implement
ce.freebsd.org/depotTreeBrowser.cgi?FSPC=//depot/projects/soc2008/gabor%5ftextproc&HIDEDEL=NO
Comments are welcome!
Regards,
--
Gabor Kovesdan
EMAIL: [EMAIL PROTECTED]
WWW: http://www.kovesdan.org
___
freebsd-hackers@freebsd.org mailing li
s. So if you are listed on the page
and your project status is updated and no longer matches what's
written on the page, please respond to this thread. Also, if a feature
won't be ready for 7.0 but will be sometime during 7.x, please state so.
Read-only XFS support? Afaik it is only
Rene Ladan schrieb:
[...]
Added Gavin Atkinson to the CC list, he is working on a wpi(4) clone
which I'm using at the moment. It has some memory corruption error, but
is otherwise behaving quite good.
Regards,
Rene
I did a quick try with this driver and unfortunately it suffers from the
53 matches
Mail list logo
