On 16/08/2010, at 4:15 PM, Doug Barton wrote:
> On Sun, 15 Aug 2010, 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
On Sun, 15 Aug 2010, 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 simple
string-parsing stuff" which is C and "a good glue la
On Mon, 16 Aug 2010, Peter Jeremy wrote:
On 2010-Aug-14 20:30:44 -0700, Doug Barton wrote:
It DOESN'T happen with loads that produce a lot more heat than my
typical desktop workloads (like say, make -j2 buildworld).
Whilst I also doubt it's hardware, it's worth noting that flash
(or other mu
On Sun, 15 Aug 2010, b. f. wrote:
What were you doing when you triggered the interrupt problem without
running X?
I'm afraid to say, lest I am once again labeled a bad programmer. :)
Was there a lot of network, audio device, or disk activity
at the time?
Disk, lots and lots of disk. No net
On Aug 15, 2010, at 12:49 PM, Dimitry Andric wrote:
> So my first quick fix attempt was to replace the home-grown grep_fgetln
> with fgetln(3), which is in libc. This does not support gzip and bzip2
> files, but just to prove the point, it is enough. It gave the following
> profiling result:
FYI
In message: <894c8953-7f2f-486f-8701-a3dff65d7...@kientzle.com>
Tim Kientzle writes:
:
: On Aug 15, 2010, at 1:56 AM, Alban Hertroys wrote:
:
: > On 15 Aug 2010, at 3:12, Doug Barton wrote:
: >
: >> (And before anyone bothers to reply saying "Use pkg_info -O for that"
: >> I'll save
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
On 2010-Aug-14 20:30:44 -0700, Doug Barton wrote:
>It DOESN'T happen with loads that produce a lot more heat than my
>typical desktop workloads (like say, make -j2 buildworld).
Whilst I also doubt it's hardware, it's worth noting that flash
(or other multimedia workload) is likely to stress diffe
On 2010-08-15 21:07, Dag-Erling Smørgrav wrote:
> I built a profiling version of BSD grep and ran it with a regexp that
> matches only the very last line in (my copy of) INDEX-9. The results
> are pretty clear:
[I also did precisely that, and I just read your mail when I was
composing the followi
"Sean C. Farley" writes:
> This should trim some time off BSD grep.
Did you actually test your patch? It makes absolutely no measurable
difference.
DES
--
Dag-Erling Smørgrav - d...@des.no
___
freebsd-current@freebsd.org mailing list
http://lists.fre
On Aug 15, 2010, at 1:56 AM, Alban Hertroys wrote:
> On 15 Aug 2010, at 3:12, Doug Barton wrote:
>
>> (And before anyone bothers to reply saying "Use pkg_info -O for that"
>> I'll save you the trouble. My version is from 10-20% faster. Not sure
>> why, don't really care.) :)
>
>
> Congrats for
On Sun, Aug 15, 2010 at 12:10 PM, Steven Hartland
wrote:
> - Original Message - From: "Andrew Thompson"
>>
>> On 15 August 2010 13:55, Doug Barton wrote:
>>>
>>> Our default grep should be significantly slower than the old grep
>>> because:
>>>
>>> I think that new grep which is tim
- Original Message -
From: "Andrew Thompson"
On 15 August 2010 13:55, Doug Barton wrote:
Our default grep should be significantly slower than the old grep because:
I think that new grep which is times slower than the old grep is still
in the acceptable range.
I think that new
- Original Message -
From: "Steve Kargl"
Whereas switching the default back to GNU grep *guarantees*
neither unsophisticated nor sophosticated user will test
BSD grep.
It seems that you are letting a poor design decision with
respect to portmaster impair others contribution to FreeBSD.
On 15 August 2010 02:45, Doug Barton wrote:
> Ivan,
>
> I know that you mean this at least semi-humorously, however I'm going to
> provide a dead-serious reply below.
Thank you for your level-headed response - it's actually better than
continuing less seriously or explosively :) Also, sorry for
r
On Sun, 15 Aug 2010 02:35:02 +0100
__lvaro Castillo wrote:
> I dont understand this -> Dump failed. Partition too small. -> My root
> partition has got a 435GB only ocupated 17GB and swap 512MB
>
You have 4GB of memory and only 512MB of swap - too small to dump the
contents of memory. Crash du
В Sun, 15 Aug 2010 02:35:02 +0100
Álvaro Castillo пишет:
> This is my kernel
>
> http://pastebin.com/1NpvzNp6
>
try the following:
Delete: AGP device from the kernel config
rebuild new kernel
and boot into single user mode,
mount -u /
mount -a
and reinstall the NVIDIA driver port ...
cd /usr/p
On 15 Aug 2010, at 3:12, Doug Barton wrote:
> (And before anyone bothers to reply saying "Use pkg_info -O for that"
> I'll save you the trouble. My version is from 10-20% faster. Not sure
> why, don't really care.) :)
Congrats for beating the performance of a(nother) utility in base, but -
rega
On Sat, 14 Aug 2010, Doug Barton wrote:
...
http://people.freebsd.org/~dougb/grep-time-trial-2.sh.txt
Typical times for me, with 489 ports:
GNU grep
Elapsed time: 3 seconds
BSD grep
Elapsed time: 17 seconds
Which version of GNU grep is this that you have in /usr/local?
/bz
--
Bjoern A. Ze
19 matches
Mail list logo
