Date: Wed, 8 Nov 2017 11:00:40 +0000 From: Dima Pasechnik <dimpase@gmail.com> To: Steve Kargl <sgk@troutmask.apl.washington.edu> Cc: Eitan Adler <lists@eitanadler.com>, "Montgomery-Smith, Stephen" <stephen@missouri.edu>, "freebsd-numerics@freebsd.org" <freebsd-numerics@freebsd.org> Subject: Re: cpow and clog Message-ID: <CAAWYfq2VHBjrczYE4cmAHgaTPqb_kKC13rut9L1isa2ZLL0WYg@mail.gmail.com> In-Reply-To: <20171108061501.GA51059@troutmask.apl.washington.edu> References: <20171106194937.GA87725@freebird> <20171106204121.GB37361@troutmask.apl.washington.edu> <20171106213308.GA73787@troutmask.apl.washington.edu> <c4448deb-8ccf-60c2-f839-cc17ca047969@missouri.edu> <CAF6rxgnWg%2Bm2fpAjy1kF6K5YkpzWF_pAC%2BqAHhu8oysEppibdw@mail.gmail.com> <20171108061501.GA51059@troutmask.apl.washington.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On 8 Nov 2017 07:15, "Steve Kargl" <sgk@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@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 case). That is, one reason for these patches to move so slowly is simply very outdated workflow. Dima 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 -- Steve _______________________________________________ freebsd-numerics@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-numerics To unsubscribe, send any mail to "freebsd-numerics-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAAWYfq2VHBjrczYE4cmAHgaTPqb_kKC13rut9L1isa2ZLL0WYg>