Re: Light humour
On 04/28/2013 12:54 PM, Adrian Chadd wrote: Yeah, the trouble is that people can/will believe this nonsense. So, question. Where's the pro-BSD blog(s) to offset it? :) A pro-BSD blog is a great idea. But let's not get into the Linux bashing the same way he bashed BSD. I personally like both OS very much, and I think they have a symbiotic relationship. Also, the ultimate freedom in licenses is the freedom to choose which version of freedom you like. I personally prefer the BSD license. But I respect those who prefer the GNU license. ___ 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
Re: Light humour
On 04/28/2013 04:35 PM, Joshua Isom wrote: There needs to be a pro-BSD blog. Regarding the licensing differences, it's simple. BSD: If you love something, set it free. If it comes back to you, it was meant to be. GPL: If you love something, set if free, but put a chain around it's neck to make sure it doesn't get out of sight. That is rather brilliant! ___ 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
Re: FORTRAN vs. Fortran (was: November 5th is Clang-Day)
On 11/02/2012 05:21 AM, Anton Shterenlikht wrote: Date: Fri, 2 Nov 2012 17:08:18 +1100 From: Greg 'groggy' Lehey g...@freebsd.org To: Erich Dollansky erichfreebsdl...@ovitrap.com Subject: FORTRAN vs. Fortran (was: November 5th is Clang-Day) On Friday, 2 November 2012 at 12:21:03 +0700, Erich Dollansky wrote: Hi, On Thu, 1 Nov 2012 21:59:17 -0700 Steve Kargl s...@troutmask.apl.washington.edu wrote: BTW, the name of the language is Fortran. It's been Fortran for the last 30-something years. I never realised the name change. It seems that I am not alone with this. Nor I. Looking at the Wikipedia page, I discover that it had been spelt Fortran as early as 1956, and there's even a copy of the 1956 Fortran manual online: http://www.fortran.com/FortranForTheIBM704.pdf Interesting reading. come on guys, fortran is not case sensitive... caNyO usti llputw hitespa cewhere ever you like in for TraN? ___ 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
Re: Use of C99 extra long double math functions after r236148
On 07/25/12 11:29, Rainer Hurling wrote:
Many thanks to you three for implementing expl() with r238722 and r238724.
I am not a C programmer, but would like to ask if the following example
is correct and suituable as a minimalistic test of this new C99 function?
//---
#include stdio.h
#include math.h
int main(void)
{
double c = 2.0;
long double d = 2.0;
double e = exp(c);
long double f = expl(d);
printf(exp(%f) is %.*f\n, c, 90, e);
printf(expl(%Lf) is %.*Lf\n, d, 90, f);
return 0;
}
//---
Compiled with 'c99 -o math_expl math_expl.c -lm' and running afterwards
it gives me:
exp(2.00) is
7.38905609893065040694182243896648287773132324218750
expl(2.00) is
7.38905609893065022739794267536694860609713941812515258789062500
Just as a point of comparison, here is the answer computed using
Mathematica:
N[Exp[2], 50]
7.3890560989306502272304274605750078131803155705518
As you can see, the expl solution has only a few digits more accuracy
that exp.
___
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
Re: Use of C99 extra long double math functions after r236148
On 07/25/12 12:31, Steve Kargl wrote: On Wed, Jul 25, 2012 at 12:27:43PM -0500, Stephen Montgomery-Smith wrote: On 07/25/12 11:29, Rainer Hurling wrote: Many thanks to you three for implementing expl() with r238722 and r238724. I am not a C programmer, but would like to ask if the following example is correct and suituable as a minimalistic test of this new C99 function? (program deleted) Compiled with 'c99 -o math_expl math_expl.c -lm' and running afterwards it gives me: exp(2.00) is 7.3890560989306504069 expl(2.00) is 7.38905609893065022739794 Just as a point of comparison, here is the answer computed using Mathematica: N[Exp[2], 50] 7.3890560989306502272304274605750078131803155705518 As you can see, the expl solution has only a few digits more accuracy that exp. Unless you are using sparc64 hardware. flame:kargl[204] ./testl -V 2 ULP = 0.2670 for x = 2.0e+00 mpfr exp: 7.389056098930650227230427460575008e+00 libm exp: 7.389056098930650227230427460575008e+00 Yes. It would be nice if long on the Intel was as long as the sparc64. ___ 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
Re: Use of C99 extra long double math functions after r236148
On 07/13/12 10:58, David Schultz wrote: On Fri, Jul 13, 2012, David Chisnall wrote: As do I. I'd also point out that the ONLY requirement for long double according to the standard is that it has at least the same precision as double. Therefore, any implementation of these functions that is no worse that the double version is compliant. Once we have something meeting a minimum standard, then I'm very happy to see it improved, but having C99 functions missing now is just embarrassing while we're working on adding C11 features. There are several things wrong with this reasoning, but pragmatically the conclusion may be right: we do have a long list of users who would prefer a dubious implementation to none at all. I propose we set a timeframe for this, on the order of a few months. A rough outline might be something like: mid-August: expl logl log2l log10l -- just need to clean up Bruce and Steve's work; Steve recently sent me patches for expl, which I hope get committed soon mid-September: acoshl asinhl atanhl coshl sinhl tanhl -- easy once expl is in; others could probably help mid-October: powl expm1l mid-November: most complex.h functions If the schedule can't be met, then we can just import Cephes as an interim solution without further ado. This provides Bruce and Steve an opportunity to commit what they have been working on, without forcing the rest of the FreeBSD community to wait indefinitely for the pie in the sky. This sounds fantastic. By the way, the trig and complex functions are areas where anyone with some calculus background could contribute. If anyone is interested in helping out, I'd be happy to coordinate things and review patches, although I will be unavailable for much of August. I would be happy to help. Just give me a sense of direction of what I should try and work on, when and as you are ready. ___ 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
Re: Use of C99 extra long double math functions after r236148
On 07/09/2012 12:02 AM, Steve Kargl wrote: Yep. Another example is the use of upward recurion to compute Bessel functions where the argument is larger than the order. The algorithm is known to be unstable. By upward recursion, do you mean equation (1) in http://mathworld.wolfram.com/BesselFunction.html? So what do people use. Maybe something like http://en.wikipedia.org/wiki/Bessel_function#Asymptotic_forms (second set of equations), but finding some asymptotics with a few extra terms in them? ___ 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
Re: Use of C99 extra long double math functions after r236148
On 07/10/2012 11:50 AM, Steve Kargl wrote: On Tue, Jul 10, 2012 at 11:39:59AM -0500, Stephen Montgomery-Smith wrote: On 07/09/2012 12:02 AM, Steve Kargl wrote: Yep. Another example is the use of upward recurion to compute Bessel functions where the argument is larger than the order. The algorithm is known to be unstable. By upward recursion, do you mean equation (1) in http://mathworld.wolfram.com/BesselFunction.html? Yes. So what do people use. Maybe something like http://en.wikipedia.org/wiki/Bessel_function#Asymptotic_forms (second set of equations), but finding some asymptotics with a few extra terms in them? They use downward recursion, which is known to be stable. NIST has revised Abramowitz and Stegun, and it is available on line. For Bessel function computations, look at http://dlmf.nist.gov/10.74 and more importantly example 1 under the following link http://dlmf.nist.gov/3.6#v These algorithms are going to be subject to the same problems as using Taylor's series to evaluate exp(x) for x0. The computation will require several floating point operations. Even if the method is not unstable, I would think getting a ULP of about 1 is next to impossible, that is, unless one performs all the computations in a higher precision, and then rounds at the end. Whereas as a scientist, having a bessel function computed to within 10 ULP would be just fine. I am looking at the man page of j0 for FreeBSD-8.3. It says in conforms to IEEE Std 1003.1-2001. Does that specify a certain ULP? I am searching around in this document, and I am finding nothing. Whereas the IEEE-754 document seems rather rigid, but on the other hand it doesn't specifically talk about math functions other than sqrt. ___ 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
Re: Use of C99 extra long double math functions after r236148
Here is a technical question. I know that people always talk about ulp's in the context of how good a function implementation is. I think the ulp is the number of base 2 digits at the end of the mantissa that we cannot rely on. So if one were to write a naive implementation of lexp(x) that used Taylor's series if x is positive, and 1/lexp(-x) is x is negative - well one could fairly easily estimate an upper bound on the ulp, but it wouldn't be low (like ulp=1 or 2), but probably rather higher (ulp of the order of 10 or 20). So do people really work hard to get that last drop of ulp out of their calculations? Would a ulp=10 be considered unacceptable? Also, looking through the source code for the FreeBSD implementation of exp, I saw that they used some rather smart rational function. (I don't know how they came up with it.) Presumably a big part of the issue is to make the functions work rather fast. And a naive implementation of Taylor's series wouldn't be fast. But if people want lexp rather than exp, they must have already decided that accuracy is more important than speed. ___ 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
Re: Use of C99 extra long double math functions after r236148
On 07/08/2012 06:58 PM, Steve Kargl wrote: On Sun, Jul 08, 2012 at 02:06:46PM -0500, Stephen Montgomery-Smith wrote: So do people really work hard to get that last drop of ulp out of their calculations? I know very few scientist who work hard to reduce the ULP. Most have little understanding of floating point. Would a ulp=10 be considered unacceptable? Yes, it is unacceptable for the math library. Remember ULPs propagate and can quickly grow if the initial ulp for a result is large. OK. But suppose I wanted ld80 precision. What would be the advantage of using an ld80 expl function with a ulp of 1 over an ld128 expl function with a ulp of 10? The error propagation in the latter case could not be worse than the error propagation in the latter case. In other words, if I were asked to write a super-fantastic expl function, where run time was not a problem, I would use mpfr, use Taylor's series with a floating point precision that had way more digits than I needed, and then just truncate away the last digits when returning the answer. And this would be guaranteed to give the correct answer to just above 0.5 ulp (which I assume is best possible). From a scientist's point of view, I would think ulp is a rather unimportant concept. The concepts of absolute and relative error are much more important to them. The only way I can see ULP errors greatly propagating is if one is performing iteration type calculations (like f(f(f(f(x). This sort of thing is done when computing Julia sets and such like. And in that case, as far as I can see, a slightly better ulp is not going to drastically change the limitations of whatever floating point precision you are using. ___ 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
Re: Use of C99 extra long double math functions after r236148
On 07/08/2012 09:01 PM, Steve Kargl wrote: Have you read Goldberg's paper? I must admit that I had not. I found it at: http://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html Not to mention, I've seen way too many examples of 'x - y' where cancellation of significant digits causes problems. Throw in rather poor estimates of function results with real poor ULP and you have problems. I think that if a program includes x-y where cancellation causes huge loss of digits, then the program should be considered highly flawed. The programmer might get lucky, and a few extra ULP might save his skin, but it would be better if the program catastrophically failed so that he would realize they need to do something smarter. I got my first scientific calculator around 1975, and I remember my surprise when I discovered that (1/3)*3-1 on my calculator did not produce zero. Years later I bought another calculator, and imagine my further surprise when (1/3)*3-1 did produce zero. They must have done something very smart, I thought. The problem is, these kinds of tricks can only help you so much. Calculations like arccos(arccos(arccos(arccos(cos(cos(cos(cos(x)-x are probably not going to be correct no matter how smart the programmer is. The paper by Goldberg has some really nice stuff. I teach a class on numerical methods. One example I present is the problem using equation (4) of Goldberg's paper to solve quadratic equations. I tell them that the smart thing to do is to use equation (4) or equation (5) depending on whether b has the same sign as sqrt(b^2-4ac). This is a very good illustration of how to overcome the x-y problem, and in my opinion it has to be understood by the programmer, not the writer of the square-root package. Trying to compensate by getting that lost drop of ULP out of square root is looking in the wrong direction. But there is other stuff in his paper I don't like, and it comes across as nit-picking rather than really thinking through why he wants the extra accuracy. I feel like he is saving the pennies, but losing the dollars. For example, computing the quadratic formula when b^2 and 4ac are roughly equal (discussed in his proof of Theorem 4). He says that roughly half the digits of the final answer will be contaminated. He recommends performing the calculation with double the precision, and then retaining what is left. The reason I don't like his solution is this. The contamination of half the digits is real, not some artifact of the computing method. Unless you know EXACTLY what a, b and c are, only half the digits of the quadratic formula are valid, no matter how you calculate it. For example, maybe a is calculated by some other part of the program as 1/3. Since 1/3 cannot be represented exactly in base 2, it will not be exactly 1/3. That part of the program doesn't know that this number is going to be used later on in the quadratic formula, so it computes it in single precision. Now the quadratic formula algorithm converts a to double precision. But a will still be 1/3 to single precision. The only way to avoid this error is to perform EVERY pertinent calculation prior to the use of quadratic formula in double precision. (And suppose instead the data comes from a scientific experiment - the programmer needs to be performing an error analysis, not hoping his implementation of quadratic formula is performed in double precision.) Similarly, I am not a fan of the Kahan Summation Formula (Theorem 8). There are two reasons why I might compute large sums. One is accounting, when I better be using high enough precision that the arithmetic is exact. The other is something like numerical integration. But in the latter case, unless the summands have a very special form, it is likely that each summand will only be accurate to within e. Thus the true sum is only known to within n*e, and so the naive method really hasn't lost any precision at all. And typically n*e will be so small compared to the true answer that it won't matter. If it does matter, the problem is that n is too big. The algorithm will take decades to run. Focus efforts on producing a different numerical integration method, instead of getting that lost drop of ULP. I cannot envision any non-contrived circumstance where the Kahan summation formula is going to give an answer that is significantly more reliable than naive summation. I can envision a circumstance when the reduction in speed of the Kahan summation formula over naive summation could be significant. I think the example I like best that illustrates floating point errors is inverting badly conditioned matrices. And any scientist who works with large matrices had better know what ill-conditioned means. The proper answer is that if your matrix is ill-conditioned, give up. You need to look at the problem where your matrix came from, and rethink how you concert
Re: Use of C99 extra long double math functions after r236148
On 05/31/12 10:45, John Baldwin wrote:
On Monday, May 28, 2012 7:02:18 pm Steve Kargl wrote:
On Tue, May 29, 2012 at 07:05:07AM +1000, Peter Jeremy wrote:
On 2012-May-28 11:01:24 -0500, Stephen Montgomery-Smith
step...@missouri.edu wrote:
One thing that could be done is to have a math/cephes port that adds
the extra C99 math functions. This is already done in the math/sage
port, using a rather clever patch due to Peter Jeremy, that applies to
the cephes code.
What it would do is to create a /usr/local/lib/libm.so that would
provide the extra functions not currently included in /lib/libm.so, and
then link in /lib/libm.so as well. It would also create its own
/usr/local/include/math.h and /usr/local/include/complex.h as well.
Basically, as long as the compiler searches /usr/local/{include,lib}
before the base include/lib thenmath.h,complex.h and -lm give
the application a complete C99 math implementation by using base
functions where they exist and cephes functions where they don't.
The patch I wrote for sage can be found at
http://trac.sagemath.org/sage_trac/ticket/9543
If there's any interest, I could produce a port for this.
Another option would be to import cephes into base and use it to
provide the missing C99 functions. Cephes includes copyright notices
but the closest I can find to a license is:
Some software in this archive may be from the book _Methods and
Programs for Mathematical Functions_ (Prentice-Hall or Simon Schuster
International, 1989) or from the Cephes Mathematical Library, a
commercial product. In either event, it is copyrighted by the author.
What you see here may be used freely but it comes with no support or
guarantee.
Please talk to das@ (although I believe he's finishing up his
dissertation). I recall that he's stated that he looked into
using cephes, and concluded that it is not suitable for libm.
Note there is also
http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/147599
which I've also objected to importing into libm.
I do think we should provide something in ports as an interim solution.
There are other 3rd party applications looking to drop FreeBSD support
because we are missing APIs that almost all other OS's have. I'm fine
if the interim lives in ports and that we don't import substandard
routines into the base. I would even be fine with calling it
/usr/local/lib/libm_inaccurate.so. However, I do think we need an option.
I think it should be called libm.so. Otherwise we have to do a serious
editing job on the Makefiles/configure scripts.
sed -E 's/[[::]]-lm[[::]]/-lm_inaccuarate/'
might have some false positives and false negatives. (Did I even get
the sed syntax correct?)
By the way, I was looking through:
http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/147599
They say they compute cosh(2y) - cos(2x) using Taylor's series. I would
agree with Steve that this is seriously low quality. Floating point
errors are likely to be truly horrible. This will fail even for
non-edge cases. (This was the same error that openoffice used to have
for computing erf(x), that gave things like erf(100) = -4353243242.)
___
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
Re: Use of C99 extra long double math functions after r236148
On 05/29/2012 11:48 AM, Rainer Hurling wrote: On 29.05.2012 08:10 (UTC+1), Steve Kargl wrote: sqrtl() is a bit special in that IEEE 754 requires that it have no more than 0.5 ULP for all arguments in all roundng modes. As to other functions, I've been trying for 10+ years to get some of these into FreeBSD. I can assure you that there has never been a rush of people volunteering to help or a rush of people willing to fund the development of the necessary code. The almost complete absence of volunteers in this case is first of all caused by the need of very special, deep knowlegdes on mathematical and informatical issues. I bet there are only a few people out there, who are really good in both (three of them are known to us ;) ). The problems with quality standards in such libraries spreaded over most OS'es and platforms support this view. (I am aware that these arguments are kown and discussed before.) The more important question to me is, how can the remaining (huge!) work on the systems libm done in a foreseeable time. As one possibility, wouldn't it be imaginable to pay some people for doing (some of) this work (FreeBSD Foundation, Sponsors from industry and science etc.)? I personally, as a private person, would be willing to pay a few hundred dollars for it. Paying people for other tasks in FreeBSD is not entirely uncommon, if I am not mistaken. If there were a freebsd-floating-po...@freebsd.org mailing list to discuss these issues, I would eagerly join. While I have never written libm-style libraries myself, I do have knowledge of both computers AND mathematics, and I do teach two university courses: Numerical Methods and Numerical Linear Algebra. And I have written quite a bit of numerical code, so I do know about the issues of testing and debugging such code. I would be happy to take on any steep learning curve, and make contributions, if only I were part of a group that would steer me in the right direction. Finally, Steve made a point that the way gcc multiplies complex numbers is wasteful in computational time. I have been bitten by this. I wrote some code that involved multiplying large numbers of complex numbers. I first wrote it using the complex C99 code. Then I rewrote it using double, writing out the complex multiplication long hand, and the program went twice as fast! (It involved multiplying numbers that were purely real or purely imaginary, so performing (x)*(I*y) by (x+0*I)*(0+y*I) really did slow it down.) Anyway, given that floating point is a big issue, and we are about a decade behind schedule, really suggests that a floating-po...@freebsd.org mailing list is needed. Or maybe there is an existing freebsd mailing list you guys already occupy. Stephen ___ 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
Re: Use of C99 extra long double math functions after r236148
On 05/28/2012 07:07 PM, Steve Kargl wrote:
On Mon, May 28, 2012 at 06:44:42PM -0500, Stephen Montgomery-Smith wrote:
On 05/28/2012 06:30 PM, Steve Kargl wrote:
From clog.c in http://www.netlib.org/cephes/c9x-complex
double complex
ccosh (z)
double complex z;
{
double complex w;
double x, y;
x = creal(z);
y = cimag(z);
w = cosh (x) * cos (y) + (sinh (x) * sin (y)) * I;
return (w);
}
See math_private.h about the above.
I looked in math_private.h - I presume you meant
lib/msun/src/math_private.h. I wasn't able to find anything about ccosh
there.
I think that for a rough and ready ccosh, this is high enough quality
for a math/cephes port.
That's the problem. It is not acceptable (imo). The comment in
math_private.h that is relevant is
/*
* Inline functions that can be used to construct complex values.
*
* The C99 standard intends x+I*y to be used for this, but x+I*y is
* currently unusable in general since gcc introduces many overflow,
* underflow, sign and efficiency bugs by rewriting I*y as
* (0.0+I)*(y+0.0*I) and laboriously computing the full complex product.
* In particular, I*Inf is corrupted to NaN+I*Inf, and I*-0 is corrupted
* to -0.0+I*0.0.
*/
Those wrong +-0 mean you may up end up on the worng riemann sheet,
and that NaN propagates.
OK, I agree with you that gcc fails to be C99 compliant. But I disagree
with you that this is a big deal.
1. By being so picky about being so precise, FreeBSD is behind the time
line in rolling out a usable set of C99 functions. The compilers and
operating systems have many bugs, and if we waited until we were totally
sure that all the bugs were gone, we wouldn't have any operating system
to work with at all. Why be more picky with floating point arithmetic
than the other aspects of FreeBSD?
2. If I was really worried about being on the correct Riemann sheet, I
would code very, very carefully, and not rely on numerical accuracy of
any kind of floating point calculation. There is a certain mathematical
inconsistency in introducing 0, -0 and Inf+I*Inf, and the number of
times programmers really want a very specific kind of behavior for
exceptions is so rare that they are better off writing their own wrapper
code than relying on any library functions. (For example, is there a
difference between 0 and +0? If not, does -(0) compute to 0 or -0? I
can see circumstances where I sometimes want one, and sometimes the other.)
3. But to counter my own argument, it highly bothers me that in C that
(-5)%3 evaluates to -2 and not to 1. That bug^H^H^H feature has
truly bitten me. And I have had lengthy arguments online with some C
experts as to why 1 should be the correct answer, without being able
to convince them. If it were up to me, the whole of the C standard
would be scrapped, and rewritten with everything exactly the same except
for this one thing. But to those I argued with, I seem just as picky as
you seem when you insist that 0 and -0 are different. So what do I do?
I live with it, just like we all live in an imperfect world.
If I had a choice between correcting the C standard for % or solving
world hunger, I would definitely settle for the second. And maybe the C
programming language, for all its imperfections, has helped push
frontiers of technology sufficiently that someone is less hungry than
they would have otherwise been. And if those resources used to feed
people had been redirected to fix the C standard, then maybe a few more
people would be hungry.
In the end, I do think it is good to ultimately settle on good C99
compliant code. But having something intermediate that mostly works is
better than nothing. Especially if it exists only in the ports, and not
in the base code.
___
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
Re: Use of C99 extra long double math functions after r236148
One thing that could be done is to have a math/cephes port that adds the extra C99 math functions. This is already done in the math/sage port, using a rather clever patch due to Peter Jeremy, that applies to the cephes code. What it would do is to create a /usr/local/lib/libm.so that would provide the extra functions not currently included in /lib/libm.so, and then link in /lib/libm.so as well. It would also create its own /usr/local/include/math.h and /usr/local/include/complex.h as well. What do you guys think? Do you want someone to start experimenting with this idea? I could do it, but probably not for a little while. Stephen ___ 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
Re: Use of C99 extra long double math functions after r236148
On 05/28/2012 03:31 PM, Steve Kargl wrote: On Mon, May 28, 2012 at 11:01:24AM -0500, Stephen Montgomery-Smith wrote: One thing that could be done is to have a math/cephes port that adds the extra C99 math functions. This is already done in the math/sage port, using a rather clever patch due to Peter Jeremy, that applies to the cephes code. What it would do is to create a /usr/local/lib/libm.so that would provide the extra functions not currently included in /lib/libm.so, and then link in /lib/libm.so as well. It would also create its own /usr/local/include/math.h and /usr/local/include/complex.h as well. What do you guys think? Do you want someone to start experimenting with this idea? I could do it, but probably not for a little while. This is a horrible, horrible, horrible idea. Have you looked at the cephes code, particularly the complex.h functions? I have only taken a very cursory look. What should I specifically look for in seeing that the code is bad? ___ 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
Re: Use of C99 extra long double math functions after r236148
On 05/28/2012 05:17 PM, Steve Kargl wrote: On Mon, May 28, 2012 at 04:19:22PM -0500, Stephen Montgomery-Smith wrote: On 05/28/2012 03:31 PM, Steve Kargl wrote: On Mon, May 28, 2012 at 11:01:24AM -0500, Stephen Montgomery-Smith wrote: One thing that could be done is to have a math/cephes port that adds the extra C99 math functions. This is already done in the math/sage port, using a rather clever patch due to Peter Jeremy, that applies to the cephes code. What it would do is to create a /usr/local/lib/libm.so that would provide the extra functions not currently included in /lib/libm.so, and then link in /lib/libm.so as well. It would also create its own /usr/local/include/math.h and /usr/local/include/complex.h as well. What do you guys think? Do you want someone to start experimenting with this idea? I could do it, but probably not for a little while. This is a horrible, horrible, horrible idea. Have you looked at the cephes code, particularly the complex.h functions? I have only taken a very cursory look. What should I specifically look for in seeing that the code is bad? Well, to start with, the extra C99 math functions that are missing in libm include a few for the long double type and many (if not most) of the complex functions for any type. Cephes at best will give you float, double, and ld80, but not ld128 versions of the functions. Then, there is fun little fact that neither (base) gcc nor clang nor gcc less than 4.6 does complex arithematic correctly; so, one needs to jump through hoops to get the correct answer (See Annex G in n1256.pdf). One item of particular importance in Annex G is the behavior of the functions for Re(z) and/or Im(z) being +-0, +-Inf, and NaN. IMHO these problems are definitely not bad enough to avoid making a math/cephes port. I for one would definitely like to have some kind of implementation of ccosh, even if it gets a few things wrong when it is fed Nan or I*Inf or such like as its input. I mean, if clang or gcc46 doesn't even get this right, how can we expect better from libm? Also, a really nice thing about Jeremy's patch is that it automatically detects which functions are already included in the base libm, and only adds functions not already in libm. And ld80 is better than nothing if ld128 isn't available. I would avoid cephes only if it got some of the answers horribly wrong (as in erf(100) being something like -14232 as the openoffice implementation of the erf function used to report). I say, lets go ahead and add a math/cephes port. By the way, do you have an opinion on the complex functions used in Linux? (I tried reading the glibc code, but I could only find chains of macros and functions calling each other, and I could never find where the actual work was performed.) ___ 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
Re: Use of C99 extra long double math functions after r236148
On 05/28/2012 06:30 PM, Steve Kargl wrote:
From clog.c in http://www.netlib.org/cephes/c9x-complex
double complex
ccosh (z)
double complex z;
{
double complex w;
double x, y;
x = creal(z);
y = cimag(z);
w = cosh (x) * cos (y) + (sinh (x) * sin (y)) * I;
return (w);
}
See math_private.h about the above.
I looked in math_private.h - I presume you meant
lib/msun/src/math_private.h. I wasn't able to find anything about ccosh
there.
I think that for a rough and ready ccosh, this is high enough quality
for a math/cephes port.
I do agree that it might not be high enough quality to make FreeBSD base.
(Although I don't think I have ever been in a situation where I would
have been tripped up by a transcendental function that responded
incorrectly to exceptional input.)
And, finally,
Yes, it is very nice.
Who's writing the code to test the implementations? That is
better much the problem. Without testing, one might get an
implementation that appears to work until it doesn't! It took
me 3+ years to get sqrtl() into libm, but bde and das (and
myself) wanted to make sure the code worked.
Fair enough if we are talking about the base system.
I haven't looked at glibc code in years, because I hack on libm
when I can. I do not want to run into questions about whether
my code is tainted by the gpl.
They had similar lists of exceptions.
___
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
Re: ports/158179: some packages do not fully honor -P dir option in pkg_add(1)
On 07/16/2011 04:26 AM, Stefan Bethke wrote:
Am 16.07.2011 um 04:43 schrieb Stephen Montgomery-Smith:
I was looking through the source code of pkg_add. Personally I don't see how the -P or -p
option could be made to work with pkg_add. Many of the installation commands involve scripts which have ${PREFIX} hard
coded into them. ${PREFIX} is often hard coded when trhe package is created by the port. In my opinion, the options
-p and -P should be removed from pkg_add.
Either that, or provide the port a way to access @cwd in any scripts it
installs. But this would require a major overhaul of the whole ports system, and
probably much of the software it installs as well.
Am I missing something?
Yes. Not honoring the prefix is a bug in the port. If you do need to do
prefix-specific things during install, use pkg-install, see
http://www.freebsd.org/doc/en/books/porters-handbook/pkg-install.html
I suspect that many ports are not well tested outside of /usr/local, but the
infrastructure is there and available.
You are correct, this needs to be done on a port by port basis. In some
ports this is going to be a big job, because in some cases the
/usr/local is hard coded into certain binaries.
For example, suppose the C source code contains something like:
char applications_dir = /usr/local/share/applications;
and this is filled in by the ./configure script.
How is that handled?
___
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
Re: ports/158179: some packages do not fully honor -P dir option in pkg_add(1)
On 07/16/2011 10:53 AM, Chris Rees wrote:
On 16 Jul 2011 16:38, Stephen Montgomery-Smith step...@missouri.edu
mailto:step...@missouri.edu wrote:
On 07/16/2011 04:26 AM, Stefan Bethke wrote:
Am 16.07.2011 um 04:43 schrieb Stephen Montgomery-Smith:
I was looking through the source code of pkg_add. Personally I
don't see how the -P or -p option could be made to work with
pkg_add. Many of the installation commands involve scripts which have
${PREFIX} hard coded into them. ${PREFIX} is often hard coded when trhe
package is created by the port. In my opinion, the options -p and
-P should be removed from pkg_add.
Either that, or provide the port a way to access @cwd in any
scripts it installs. But this would require a major overhaul of the
whole ports system, and probably much of the software it installs as well.
Am I missing something?
Yes. Not honoring the prefix is a bug in the port. If you do need
to do prefix-specific things during install, use pkg-install, see
http://www.freebsd.org/doc/en/books/porters-handbook/pkg-install.html
I suspect that many ports are not well tested outside of
/usr/local, but the infrastructure is there and available.
You are correct, this needs to be done on a port by port basis. In
some ports this is going to be a big job, because in some cases the
/usr/local is hard coded into certain binaries.
For example, suppose the C source code contains something like:
char applications_dir = /usr/local/share/applications;
and this is filled in by the ./configure script.
How is that handled?
It's not.
Remember what a package is, literally the files from the plist tarred
with some magic +FILEs and the pkg-*install files- if paths are
hardcoded in objects that's how it'll be installed.
What if some of the installation programs are binaries, and /usr/local
is hard coded into installation binaries or scripts provided by the
software itself.
Don't touch the -p option! It's only useful for um someone help
here?
I am thinking the same thing!
___
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
Re: ports/158179: some packages do not fully honor -P dir option in pkg_add(1)
I was looking through the source code of pkg_add. Personally I don't
see how the -P or -p option could be made to work with pkg_add.
Many of the installation commands involve scripts which have ${PREFIX}
hard coded into them. ${PREFIX} is often hard coded when trhe package
is created by the port. In my opinion, the options -p and -P should
be removed from pkg_add.
Either that, or provide the port a way to access @cwd in any scripts
it installs. But this would require a major overhaul of the whole ports
system, and probably much of the software it installs as well.
Am I missing something?
Stephen
___
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
Re: Problems with cvsup on FreeBSD 9, AMD64, osreldate: 900038
On 07/03/2011 03:51 PM, Stephen Montgomery-Smith wrote: On 07/02/2011 10:25 PM, jhell wrote: Use csup(1) in base. This is in 7, 8 9. cvsup has been deprecated for much longer than it really needed to be and should probably be removed from use as a client entirely and links generated for installation of cvsup - csup. Only drawback for you may be no X interface but it really was not that pretty in the first place and served no real good purpose over the functionality of the command line client. Another drawback to csup is that csup doesn't seem to recognize the .cvsup/auth file. At least not on FreeBSD 7 of a few months ago. I run CTM generation, and I need access to cvsup-master. My mistake. I found that in FreeBSD-CURRENT that csup does recognize .csup/auth. Any timetable on when this will by MFCed to FreeBSD 7 and 8? Incidentally, csup needs the following diff applied, so that I can continue to use FreeBSD in my auth file: 195c195 if (strcmp(auth-server, server) != 0) --- if (strcasecmp(auth-server, server) != 0) I'll file a PR. ___ 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
Re: Problems with cvsup on FreeBSD 9, AMD64, osreldate: 900038
On 07/02/2011 10:25 PM, jhell wrote: Use csup(1) in base. This is in 7, 8 9. cvsup has been deprecated for much longer than it really needed to be and should probably be removed from use as a client entirely and links generated for installation of cvsup - csup. Only drawback for you may be no X interface but it really was not that pretty in the first place and served no real good purpose over the functionality of the command line client. Another drawback to csup is that csup doesn't seem to recognize the .cvsup/auth file. At least not on FreeBSD 7 of a few months ago. I run CTM generation, and I need access to cvsup-master. ___ 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
Re: ACPI on Tyan Motherboard
Alexander Leidinger wrote: Stephen Montgomery-Smith schrieb: Actually the power-off button doesn't work at all under FreeBSD-current. (It is a soft power-off button that dmesg shows is detected by the OS.) Have you tried to hold the power-button a little bit longer? My power-button turn the system off when I pres it for ~4secs (but I haven't a Tyan board). I tried pressing the power button for a longer time. It does actually do something. After about 4 seconds, it has the same effect as shutdown -p now or halt -p, that is, the video card stops working, the fans keep going, and the disk access light comes fully on. I am guessing that this 4 second delay is part of how FreeBSD wants it. If that is the case, it shows that the power button is working as it should - it is the power-down process that is not working right. -- Stephen Montgomery-Smith [EMAIL PROTECTED] http://www.math.missouri.edu/~stephen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ACPI on Tyan Motherboard
John Baldwin wrote: On 19-Aug-2003 Stephen Montgomery-Smith wrote: I am guessing that this 4 second delay is part of how FreeBSD wants it. If that is the case, it shows that the power button is working as it should - it is the power-down process that is not working right. No, the 4 second countdown thing is in the BIOS/hardware and is not OS dependent at all. If the box doesn't properly shut off when you hold the power button for 4 seconds, that is a hardware or BIOS bug and something FreeBSD has no control over. FreeBSD must have some control over this process, because in FreeBSD-4.8 and RedHat 9.0 (which make no attempt to access ACPI), the power button immediately powers down the computer. The same is also true if I start FreeBSD-current with ACPI support switched off. (Windows 2000 also works fast, but the Windows 2000 OS first cleanly shuts down the file system.) But now that people are mentioning this 4 second issue, I have now also noticed that if I do halt -p under FreeBSD-current, the OS does all its shutdown stuff, prints the message Uptime x, and then waits about 4 seconds before doing its powerdown attempt. -- Stephen Montgomery-Smith [EMAIL PROTECTED] http://www.math.missouri.edu/~stephen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ACPI on Tyan Motherboard
John Baldwin wrote: Here's how it works: The BIOS/hardware monitor the power button. When an OS tells the BIOS that it is ACPI, then the BIOS doesn't do an instant turn off when the power button is pressed, but waits to do so until the power button has been held down for 4 seconds. If the power button after 4 seconds doesn't work, it's still a hardware problem. FreeBSD can not fix your hardware problem. When you press the power button with an ACPI OS running, the hardware sends an interrupt to the OS. The OS then shuts down and asks the BIOS (via ACPI) to power off the machine. If the machine doesn't physically turn off, it's because your BIOS is screwed up and didn't handle the power down command properly. The fact that the 4 second trick (which as above bypasses FreeBSD completely and has the BIOS call that power down method itself) produces the same broken results means that this bug is in your hardware. FreeBSD sleeps for a bit when it does a halt -p as a workaround for broken IDE disks which claim that writes have hit the media when they are still in the disks cache, so that is a separate issue. If you want more info on ACPI and how it works, feel free to head on over to www.acpi.info and read the spec for yourself. I took a quick look at the acpi web site, but it is a lot more reading than I have time for right now. Following up your suggestion that it is a hardware problem, I decided to try updating the BIOS from version 2.10 to 2.14. Now start up produces lots of ACPI error messages. I am not asking for you guys to fix it, but if you can help me interpret it (or can comfirm that this is indeed a hardware problem), I would appreciate it. Dmesg is included as an attachment. (In particular, it says that the BIOS version is 2.10 when I just updated it to 2.14, unless that 2.10 coincidently refers to something else.) -- Stephen Montgomery-Smith [EMAIL PROTECTED] http://www.math.missouri.edu/~stephen Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.1-CURRENT #4: Tue Aug 19 15:25:45 CDT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/HUB Preloaded elf kernel /boot/kernel/kernel at 0xc04c2000. Preloaded elf module /boot/kernel/acpi.ko at 0xc04c2244. Timecounter i8254 frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) MP 2000+ (1659.28-MHz 686-class CPU) Origin = AuthenticAMD Id = 0x662 Stepping = 2 Features=0x383fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE AMD Features=0xc048MP,AMIE,DSP,3DNow! real memory = 3221159936 (3071 MB) avail memory = 3132239872 (2987 MB) Programming 24 pins in IOAPIC #0 IOAPIC #0 intpin 2 - irq 0 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): apic id: 1, version: 0x00040010, at 0xfee0 cpu1 (AP): apic id: 0, version: 0x00040010, at 0xfee0 io0 (APIC): apic id: 2, version: 0x00170011, at 0xfec0 Pentium Pro MTRR support enabled npx0: math processor on motherboard npx0: INT 16 interface acpi0: PTLTDRSDT on motherboard pcibios: BIOS version 2.10 ACPI-0438: *** Error: Looking up [Z00Q] in namespace, AE_NOT_FOUND SearchNode 0xc93d6a80 StartNode 0xc93d6a80 ReturnNode 0 ACPI-1287: *** Error: Method execution failed [\\_SB_.PCI0.ISA_.SIO_.COM1._STA] (Node 0xc93d6a80), AE_NOT_FOUND ACPI-0438: *** Error: Looking up [Z00Q] in namespace, AE_NOT_FOUND SearchNode 0xc93d6900 StartNode 0xc93d6900 ReturnNode 0 ACPI-1287: *** Error: Method execution failed [\\_SB_.PCI0.ISA_.SIO_.COM2._STA] (Node 0xc93d6900), AE_NOT_FOUND ACPI-0438: *** Error: Looking up [Z00Q] in namespace, AE_NOT_FOUND SearchNode 0xc93d6700 StartNode 0xc93d6700 ReturnNode 0 ACPI-1287: *** Error: Method execution failed [\\_SB_.PCI0.ISA_.SIO_.LPT_._STA] (Node 0xc93d6700), AE_NOT_FOUND acpi0: power button is handled as a fixed feature programming model. acpi0: sleep button is handled as a fixed feature programming model. Timecounter ACPI-fast frequency 3579545 Hz quality 1000 ACPI-0438: *** Error: Looking up [Z00Q] in namespace, AE_NOT_FOUND SearchNode 0xc93d6a80 StartNode 0xc93d6a80 ReturnNode 0 ACPI-1287: *** Error: Method execution failed [\\_SB_.PCI0.ISA_.SIO_.COM1._STA] (Node 0xc93d6a80), AE_NOT_FOUND ACPI-0438: *** Error: Looking up [Z00Q] in namespace, AE_NOT_FOUND SearchNode 0xc93d6900 StartNode 0xc93d6900 ReturnNode 0 ACPI-1287: *** Error: Method execution failed [\\_SB_.PCI0.ISA_.SIO_.COM2._STA] (Node 0xc93d6900), AE_NOT_FOUND ACPI-0438: *** Error: Looking up [Z00Q] in namespace, AE_NOT_FOUND SearchNode 0xc93d6700 StartNode 0xc93d6700 ReturnNode 0 ACPI-1287: *** Error: Method execution failed [\\_SB_.PCI0.ISA_.SIO_.LPT_._STA] (Node 0xc93d6700), AE_NOT_FOUND acpi_timer0: 24-bit timer at 3.579545MHz port 0x8008-0x800b on acpi0 acpi_cpu0: CPU port 0x530-0x537 on acpi0 acpi_cpu1: CPU port 0x530-0x537
Re: ACPI on Tyan Motherboard
David O'Brien wrote: On Tue, Aug 19, 2003 at 06:13:19PM -0400, John Baldwin wrote: Following up your suggestion that it is a hardware problem, I decided to try updating the BIOS from version 2.10 to 2.14. Now start up produces lots of ACPI error messages. ... The 2.10 is the version of the PCI BIOS specification that your motherboard BIOS supports. It is unrelated to the version of your motherboard BIOS. NO. His 2.10 above *IS* the version of his BIOS. I know exactly what version he had and has now. He is correct about the extra ACPI error verbage. But why would FreeBSD tell me that the BIOS version is 2.10 when I just installed version 2.14? Is this something wrong with the bios update features of this motherboard? The bios update seemed to go successfully. I might add that even with this updated BIOS, that seems to be more buggy from FreeBSD-current's point of view, that power down still works fine with Windows 2000. (It would be nice to have working ACPI with FreeBSD, but I'm not going to be greatly upset if it doesn't work. From every other point of view, this motherboard seems to work very nicely, with every operating system I have tried on it. My main reason for wanting properly working powerdown is so that if a fan stops working, then the healthd program would kick in and power-down the computer. Of course it is possible that if a fan breaks, then the CPU overheats so quickly that the healthd/acpiconf -s S5 combination just isn't quick enough. In that case, ACPI is nothing more than a nicety for me.) -- Stephen Montgomery-Smith [EMAIL PROTECTED] http://www.math.missouri.edu/~stephen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
ACPI on Tyan Motherboard
I have a Tyan S2462 Thunder K7 motherboard. I was hoping to get power-down to work. So I installed FreeBSD current with ACPI enabled. When I typed shutdown -p now the computer halted, and then the video card switched off, and the fans kept running. The computer was frozen - even the power-off power-on button wouldn't work. Actually the power-off button doesn't work at all under FreeBSD-current. (It is a soft power-off button that dmesg shows is detected by the OS.) I should add that power-down works great with Windows 2000. Also, the power-off button works properly with FreeBSD-stable. I am thinking that maybe I need to wait a few more months until ACPI is fully debugged. On the other hand, maybe you guys would like to work on this. I can send all info like dmesg, and the kernel configuration (which is basically GENERIC with stuff removed, and SMP and pcm added, but actually it didn't work with the generic kernel either.) Is it possible that power is cut to the CPU's, but not to the fans? Is there anyway to tell? Will I have to program the ACPI (that is take the output of acpidump and edit it)? It does seem to me that ACPI is working in some form, just not properly. If I boot up with ACPI disabled, then it works just as in FreeBSD-stable, that is, the power-off button works well. -- Stephen Montgomery-Smith [EMAIL PROTECTED] http://www.math.missouri.edu/~stephen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ACPI on Tyan Motherboard
User Takawata wrote: Try # sysctl hw.acpi.disable_on_poweroff=0 This didn't make any difference for me. -- Stephen Montgomery-Smith [EMAIL PROTECTED] http://www.math.missouri.edu/~stephen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP! Major commits in the tree coming soon
Thorsten Futrega wrote: The most important changes I'm going to commit today: - Remove gcc and replace it with a new TenDRA snapshot. - Remove GNU tar. I really don't see a need for any version of tar to be in the base system. I mean, where does it actually get used (other than things like installation, which don't really matter). - Fix httpd.ko to make it work on buggy AMD processors. - Drop support for 386 and 486 cpus. Shouldn't we also drop support for the earlier pentium systems as well? I think that we can safely assume that everyone is running a pentium 4 or better. - Remove ext2 support (GPL encumbered). Remove ffs support also (BSD license encumbered). - Add perl 5.8 *and* python 2.2 to base. I agree - perl makes a perfect replacement for tar. - Remove Sendmail and replace it with Postfix. I prefer USPS. -- Stephen Montgomery-Smith [EMAIL PROTECTED] http://www.math.missouri.edu/~stephen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problems with md5 -p
OK, I'm going to make this into a PR so that it gets fixed soon. (The
problem in stable appeared between May 19 and June 16.)
Valentin Nechayev wrote:
Sun, Jun 24, 2001 at 09:25:22, stephen (Stephen Montgomery-Smith) wrote about
Problems with md5 -p:
I reproduce it stably on my -current. The second checksum is constant
and it is MD5 checksum of an empty stream:
root@iv:/usr/HEAD/src/sbin/md5##md5 /dev/null
d41d8cd98f00b204e9800998ecf8427e
A fix:
--- md5.c.orig Mon Jun 4 00:38:02 2001
+++ md5.c Sun Jun 24 19:37:13 2001
@@ -65,7 +65,7 @@
switch (ch) {
case 'p':
MDFilter(1);
- break;
+ exit(0);
case 'q':
qflag = 1;
break;
This avoids determination of other options, but this does not conflict
directly with man page.
Moreover such exit(0) should be applied not only with -p, but also with
-x, -t and -s: all these options should not gather any input files.
Patch is trivial.
Suppose I have a file xxx. If I type
md5 -p xxx
it should return the contents of the file followed by its md5 number:
Some junk in the file
334911f8bcde69fe8edac561197e876f
But now I get two numbers:
Some junk in the file
334911f8bcde69fe8edac561197e876f
d41d8cd98f00b204e9800998ecf8427e
This is using FreeBSD stable of June 16. (Maybe this has been fixed
more recently - please tell me of it has. It is a bit tricky for me to
update sources because I use CTM which has been out recently - probably
for just this very reason. But if I know the problem has been fixed
then I will go through the effort of using cvsup.)
/netch
--
Stephen Montgomery-Smith
[EMAIL PROTECTED]
http://www.math.missouri.edu/~stephen
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Suggestion for elf upgrade
I think that you misunderstood my message. The problems I was having were not with the final state of the machine, but with the intermediate stages. Chris Costello wrote: On Sun, Feb 14, 1999, Stephen Montgomery-Smith put this into my mailbox: ... and by this time, the code mismatch between the binary executables and the kernel made netscape unusable. Odd. Netscape runs for me. I have an ELF kernel and the new bootblocks, and obviously a new ELF world. The problem was I was stuck with 3.1 code, but an old 3.0 kernel. I needed netscape or some other browser to get to the web site to figure out how to get the new 3.1 kernel going, and the mismatch meant that I could not use netscape. My point was that if I had known about this web site BEFORE I started the make world, then it would have been much easier to extract the needed info. Now I finally got the 3.1 kernel going, netscape works fine. It told me that I needed new bootblocks. I think a paragraph explanation of what bootblocks is would have helped a very great deal. As it was it was like telling me to wear a nuffle on my head when it is cold. Like, what is a nuffle? So what is a bootblock? I did figure out enough to get it to work (I am guessing that a bootblock is some code at the beginning of each slice that is loaded by booteasy). I believe the boot blocks contain the software required to access the disk and boot the kernel. Obviously you'd need new boot blocks if you'll be trying to run a kernel that the 2.2 blocks don't understand. Yes, I did figure out that much. But without understanding bootblocks in context, I was unsure what exactly I was looking for. I think that the web page http://www.freebsd.org/~peter/elfday.html would have been better if the link to http://www.freebsd.org/~rnordier/boot.txt had been somewhere prominent at the top of http://www.freebsd.org/~peter/elfday.html , and a small paragraph explaining what bootblocks is would have helped put the whole thing in context. My issue is not with the final product, which is fantastic. Rather I am making some suggested changes to the way the information is being put out. Really, they are only suggestions. I think that the FreeBSD team do a very good job. I just wanted to offer my feedback on the technical writing aspect. -- Stephen Montgomery-Smith step...@math.missouri.edu 307 Math Science Building step...@showme.missouri.edu Department of Mathematics step...@missouri.edu University of Missouri-Columbia Columbia, MO 65211 USA Phone (573) 882 4540 Fax (573) 882 1869 http://math.missouri.edu/~stephen To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Suggestion for elf upgrade
Yesterday I did an upgrade from 3.0-Release to 3.1-beta. I did make world, then I made the kernel. At the end of the make kernel, I got a message about the kernel being elf!!! Bad timing to find out about this - I was told to look at http://www.freebsd.org/~peter/elfday.html and by this time, the code mismatch between the binary executables and the kernel made netscape unusable. Good thing I wasn't upgrading from 2.2.x, maybe then I could not have even installed lynx or Mosaic to get the info I needed. Well, I did get it figured out. But I have one suggestion for the web page http://www.freebsd.org/~peter/elfday.html It told me that I needed new bootblocks. I think a paragraph explanation of what bootblocks is would have helped a very great deal. As it was it was like telling me to wear a nuffle on my head when it is cold. Like, what is a nuffle? So what is a bootblock? I did figure out enough to get it to work (I am guessing that a bootblock is some code at the beginning of each slice that is loaded by booteasy). Second, instead of putting the warning message after making the kernel, how about putting the message at the beginning of both make world and making the kernel (and make installworld etc), so for example, to make world one has to type: make -DYES_I_REALLY_DO_KNOW_ABOUT_BOOTBLOCKS_AND_SUCH_LIKE world Maybe after a couple of years, one can get rid of this requirement. Yes, I do realise that I was out of touch not knowing about elf kernels. But there will be lots like me, and we should make it as painless as possible, since everybody who upgrades has to face this issue. Finally, I did get it all to work, and I am really pleased with what I have. It was my first experience at making FreeBSD from the source. I learned a lot. -- Stephen Montgomery-Smith step...@math.missouri.edu 307 Math Science Building step...@showme.missouri.edu Department of Mathematics step...@missouri.edu University of Missouri-Columbia Columbia, MO 65211 USA Phone (573) 882 4540 Fax (573) 882 1869 http://math.missouri.edu/~stephen To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
