cpow and clog

Dima Pasechnik dimpase at gmail.com
Wed Nov 8 11:00:45 UTC 2017

On 8 Nov 2017 07:15, "Steve Kargl" <sgk at troutmask.apl.washington.edu> wrote:

On Tue, Nov 07, 2017 at 09:18:11PM -0800, Eitan Adler wrote:
> On 7 November 2017 at 17:50, Montgomery-Smith, Stephen
> <stephen at missouri.edu> wrote:
> >> Note, I packaged Bruce's code with manpages here
> >>
> >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216863
> >
> > Please, someone should commit it.
> :(

Well, yes, a patch that sits in bugzilla tends to rot.

A patch not tagged by a version control system surely  rots very quickly,
as noone except the submitter knows the exact state of the source tree it
is made against, especially if the tree is also not under a revision
control system.
And surely the submitter's memory is not perfect, either.

If your patches were made on a version control system, rebasing them would
have been mist probably trivial, too (assuming it is just some permutation
of commuting chunks of code causing patch to fail, as it most often the

That is, one reason for these patches to move so slowly is simply very
outdated workflow.


PS. The current freebsd workflow,  using svn instead of git (as basically
everyone else does nowadays)  is also oudated, but by a much smaller
margin. Still, at least if used properly, patches are perfectly traceable
to the state of the source tree they are created at.

PPS. yes, in case you may wonder, I have learnt to program using punch
cards, almost 40 years ago  :-)

> patching file include/complex.h
> Hunk #1 succeeded at 99 (offset 12 lines).
> patching file lib/libc/softfloat/bits64/softfloat-macros
> patching file lib/msun/Makefile
> Hunk #2 succeeded at 134 (offset 3 lines).
> Hunk #3 succeeded at 171 (offset 7 lines).
> patching file lib/msun/Symbol.map
> Hunk #1 FAILED at 294.

Probably a trivial edit to deal with clog[fl] placed
in different order of Symbol.map.

> 1 out of 1 hunk FAILED -- saving rejects to file lib/msun/Symbol.map.rej
> patching file lib/msun/man/clog.3
> patching file lib/msun/man/complex.3
> Hunk #1 succeeded at 24 with fuzz 2.
> patching file lib/msun/src/math_private.h
> Hunk #2 FAILED at 309.
> 1 out of 2 hunks FAILED -- saving rejects to file
> lib/msun/src/math_private.h.rej

Don't know if someone has made change sot math_private.h.

I guess I'll have to rebase my patch

freebsd-numerics at freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-numerics-unsubscribe at freebsd.org"

More information about the freebsd-numerics mailing list