On Thu, 14 May 2015 02:02:11 +0200 Baptiste Daroussin wrote
> Hi,
>
> I plan to work in replacing GNU groff for FreeBSD 11.0 in base by heirloom
> doctools.
>
> This mostly concern documentation in share/docs and the fallback when
> mandoc(1) is not able to render a manpage.
>
> Heirloom docto
+1
Great idea.
Pedro.
___
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"
Hi,
I plan to work in replacing GNU groff for FreeBSD 11.0 in base by heirloom
doctools.
This mostly concern documentation in share/docs and the fallback when mandoc(1)
is not able to render a manpage.
Heirloom doctools has progressed a lot recently and is now able to render
correctly all the do
make delete-old can't finish off the /usr/lib/private directory due to
the presence of libssh_p.a. Manual intervention is required UFN.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe,
On Wed, 2015-05-13 at 11:13 -0700, John-Mark Gurney wrote:
> Adrian Chadd wrote this message on Wed, May 13, 2015 at 08:34 -0700:
> > The reason I ask about "why is it faster?" is because for embedded-y
> > things with low RAM we may not want that to happen due to memory
> > constraints. However, w
Adrian Chadd wrote this message on Wed, May 13, 2015 at 08:34 -0700:
> The reason I ask about "why is it faster?" is because for embedded-y
> things with low RAM we may not want that to happen due to memory
> constraints. However, we may actually want to do some form of
> autotuning on some platfor
Hans Petter Selasky wrote this message on Wed, May 13, 2015 at 10:35 +0200:
> On 05/13/15 10:27, David Chisnall wrote:
> > On 13 May 2015, at 09:03, John-Mark Gurney wrote:
> >>
> >> Poul-Henning Kamp wrote this message on Tue, May 12, 2015 at 06:31 +:
> >>>
> >>> In message <20150512
On 13 May 2015, at 17:05, Pedro Giffuni wrote:
>
> Hello;
>
> I am looking at the cdefs in other BSDs hoping to avoid adopting the
> same definitions with incompatible names and I noticed NetBSD is using
> a new __builtin_unreachable (void) function from gcc 4.6:
>
> https://gcc.gnu.org/onlined
Hello;
I am looking at the cdefs in other BSDs hoping to avoid adopting the
same definitions with incompatible names and I noticed NetBSD is using
a new __builtin_unreachable (void) function from gcc 4.6:
https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html
Apparently it was interesting enoug
[snip]
The reason I ask about "why is it faster?" is because for embedded-y
things with low RAM we may not want that to happen due to memory
constraints. However, we may actually want to do some form of
autotuning on some platforms.
So, if it's underlying block size, maybe BUFSIZ isn't the thing
On Wed, 2015-05-13 at 10:35 +0200, Hans Petter Selasky wrote:
> On 05/13/15 10:27, David Chisnall wrote:
> > On 13 May 2015, at 09:03, John-Mark Gurney wrote:
> >>
> >> Poul-Henning Kamp wrote this message on Tue, May 12, 2015 at 06:31 +:
> >>>
> >>> In message <20150512032307.gp37...
On 05/13/15 10:27, David Chisnall wrote:
On 13 May 2015, at 09:03, John-Mark Gurney wrote:
Poul-Henning Kamp wrote this message on Tue, May 12, 2015 at 06:31 +:
In message <20150512032307.gp37...@funkthat.com>, John-Mark Gurney writes:
Also, you'd probably see even better perfo
On 13 May 2015, at 09:03, John-Mark Gurney wrote:
>
> Poul-Henning Kamp wrote this message on Tue, May 12, 2015 at 06:31 +:
>>
>> In message <20150512032307.gp37...@funkthat.com>, John-Mark Gurney writes:
>>
>>> Also, you'd probably see even better performance by increasing the
>>>
Poul-Henning Kamp wrote this message on Tue, May 12, 2015 at 06:31 +:
>
> In message <20150512032307.gp37...@funkthat.com>, John-Mark Gurney writes:
>
> >Also, you'd probably see even better performance by increasing the
> >size to 64k, [...]
>
> easy:
> 8K on 32bit
> 64k
14 matches
Mail list logo
