2010/8/16 Dag-Erling Smørgrav :
> Doug Barton writes:
>> lua too "flavor of the day," not enough track record of stability,
>> not enough installed base/proven utility
>
> You're wrong. Lua has been around for ages and is especially widely
> used as a game scripting engine. It is not int
Thanks for your reply.
2010/8/17 Mark Linimon :
> On Tue, Aug 17, 2010 at 12:21:07PM +0800, lhmwzy wrote:
>> opensolaris is gone
>
> It appears there will be a fork, but that's not particularly crucial
> to FreeBSD.
>
>> ZFS also gone.
>
> We're not going to drop ZFS because Oracle's plans are unc
On Tue, Aug 17, 2010 at 12:21:07PM +0800, lhmwzy wrote:
> opensolaris is gone
It appears there will be a fork, but that's not particularly crucial
to FreeBSD.
> ZFS also gone.
We're not going to drop ZFS because Oracle's plans are unclear. It
remains to be seen how much other community support
On 08/16/2010 03:42, Dimitry Andric wrote:
On 2010-08-15 21:49, Dimitry Andric wrote:
...I
have attached a more complete patch that:
- Replaces the horrendously inefficient grep_fgetln() with mostly the
same implementation as the libc fgetln() function.
- Uses plain file descriptors instead
opensolaris is gone,ZFS also gone.
Will FreeBSD import btrfs or other similar file system?
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...
On Mon, 16 Aug 2010 at 04:50 -, Randy Bush wrote:
> is there a better way to achieve this?
I'm not sure what ca_mode is, but I have the following in my
.Xresources file:
XTerm*tiXtraScroll: true
XTerm*titeInhibit: true
These get rid of the silly alternate screen in vi, etc. There
On 08/16/2010 00:47, sth...@nethelp.no wrote:
If I only wanted a kernel and everything else as installable packages,
I might as well use one of the Linux distributions.
That wasn't at all what I said, or what I was suggesting. There is a
middle ground between "everything is a package" and the
Is there anyone using AMD Phenom II X6 1090T?
What can you say about it's performance?
Have you any tasks that use all 6-cores?
Does it balance workload between all 6 cores properly?
I am interested how it will work specifically under 8.1-RELEASE and
9.0-CURRENT.
___
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'
On Mon, Aug 16, 2010 at 09:07:24PM +0400, pluknet wrote:
> On 16 August 2010 21:05, pluknet wrote:
> > Hi.
> >
> > Seeing on mostly idle, recently updated current, while closing a file.
> > Presumably never reported on ML.
> >
> > lock order reversal:
> > 1st 0xff00198199f8 nfs (nfs) @ /usr/s
On 16 August 2010 21:05, pluknet wrote:
> Hi.
>
> Seeing on mostly idle, recently updated current, while closing a file.
> Presumably never reported on ML.
>
> lock order reversal:
> 1st 0xff00198199f8 nfs (nfs) @ /usr/src/sys/kern/vfs_vnops.c:301
> 2nd 0xff000234a048 filedesc structure
Hi.
Seeing on mostly idle, recently updated current, while closing a file.
Presumably never reported on ML.
lock order reversal:
1st 0xff00198199f8 nfs (nfs) @ /usr/src/sys/kern/vfs_vnops.c:301
2nd 0xff000234a048 filedesc structure (filedesc structure) @
/usr/src/sys/kern/kern_descrip.c
Randy Bush writes:
> is there a better way to achieve this?
Not sure about ~/.termcap but you can just override ti/te via TERMCAP in
environment.
$ export TERM=${TERM:-xterm}
$ export TERMCAP=${TERM}:ti@:te@:tc=${TERM}:
>
> *** termcap.FCS Tue Jun 17 15:10:46 2003
> --- termcap Tue Jun
"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...
DES
--
Dag-Erling Smørgrav - d...@des.no
___
freebsd-current@freebsd
On Sun, 15 Aug 2010, Dag-Erling Smørgrav wrote:
"Sean C. Farley" writes:
This should trim some time off BSD grep.
Did you actually test your patch? It makes absolutely no measurable
difference.
Yes, I saw a reduction, using the first test script Doug provided, from
36 to 27 seconds. I
On 2010-Aug-16 10:55:18 +0200, Dag-Erling Smørgrav wrote:
>It might be worth a shot adding mmap(2) support as well, i.e. when
>processing an uncompressed regular file, try to mmap(2) it first, and if
>that fails, fall back to the plain buffered read(2) method.
Note that ZFS and mmap() don't get o
2010/8/16 Dag-Erling Smørgrav :
> Doug Barton writes:
>> lua too "flavor of the day," not enough track record of stability,
>> not enough installed base/proven utility
>
> You're wrong. Lua has been around for ages and is especially widely
> used as a game scripting engine. It is not int
> zsh less POSIX-compliant, oddly deviant from "standard"
> bourne-derived shells which makes graybeards break out in hives
> also, see ruby under user community
ZSH has a POSIX-compliant interface through emulate -L sh or by naming
(linking) zsh binary sh.
even if the man page
On 2010-08-15 21:49, Dimitry Andric wrote:
> ...I
> have attached a more complete patch that:
>
> - Replaces the horrendously inefficient grep_fgetln() with mostly the
> same implementation as the libc fgetln() function.
> - Uses plain file descriptors instead of struct FILE, since the
> buffe
Since this is now well off the original topic.
On 2010-Aug-15 12:57:23 +0200, Ivan Voras wrote:
>This is my long-term point - it really would be beneficial to have an
>alternative, richer language in base which would fall between the
>categories of "a good system language but far too complex for
Doug Barton writes:
> lua too "flavor of the day," not enough track record of stability,
> not enough installed base/proven utility
You're wrong. Lua has been around for ages and is especially widely
used as a game scripting engine. It is not intended as a standalone
language, but as an
On 16 August 2010 13:09, Doug Barton wrote:
>> Can you remember the revision number of the last
>> version of -CURRENT that didn't have these problems?
>
> It was at least a year ago, so no; I can't remember specifically.
Have you tried running software build(s) from ~ 1.5 years ago to see
wheth
Dimitry Andric writes:
> - Uses plain file descriptors instead of struct FILE, since the
> buffering is done manually anyway, and it makes it easier to support
> gzip and bzip2.
It might be worth a shot adding mmap(2) support as well, i.e. when
processing an uncompressed regular file, try to
is there a better way to achieve this?
randy
*** termcap.FCS Tue Jun 17 15:10:46 2003
--- termcap Tue Jun 17 15:14:15 2003
***
*** 299,305
adm3|3|lsi adm3:\
:do=^J:am:le=^H:bs:cl=^Z:li#24:ma=^K^P:co#80:
xterm|xterm-color|X11 terminal emulator:\
! :ti@:te@:t
On Mon, Aug 16, 2010 at 09:47:40AM +0200, sth...@nethelp.no wrote:
> > Personally, I think the whole "base" and "ports" thing is an artificial
> > divide that is rapidly losing utility. I think we're past due for
> > stripping the FreeBSD "base" down to a much more bare minimum, and
> > having a
On Mon, 16 Aug 2010, Poul-Henning Kamp wrote:
...
PS: The sickening irony is that today we have two embedded languages,
one in the kernel even, and it is the most crappy ones you can
imagine: Forth and ACPI.
Besides the syntax FORTH ist the only embeddable high level language
which has both in
> Personally, I think the whole "base" and "ports" thing is an artificial
> divide that is rapidly losing utility. I think we're past due for
> stripping the FreeBSD "base" down to a much more bare minimum, and
> having a lot more of the bells and whistles live in the ports tree.
Strongly disag
In message , Doug Barton writes:
>On Sun, 15 Aug 2010, Ivan Voras wrote:
>> This is my long-term point - [...]
Some of use were 12 years ahead of you :-)
>I sort of agree with you here, but I don't. :) ONE of the reasons that
>perl was axed [...]
Actually, let me put that stuff on the record,
On Sun, Aug 15, 2010 at 11:15:55PM -0700 I heard the voice of
Doug Barton, and lo! it spake thus:
>
> However, a bigger reason was that it was impossible to marry our
> concept of a "stable" branch with the ever-evolving world that was
> perl.
This one at least is conceptually pretty easy to solv
30 matches
Mail list logo
