Hello. Aside from my cut project, I decided to see if I could use pcc to compile my own version of hoc(1) (http://www.andlabs.com/ hoc_p9.tgz) and just after calling yacc, pcc has given me a whirlwind of incomprehensible error messages that I just won't work on putting here (I'm also running Plan 9 in QEMU and I haven't set up email there). Does anyone know what's going on? My hoc, which derives directly from the original THE UNIX PROGRAMMING ENVIRONMENT version, adds a ton of features. Some of them: for loops, as in c, except middle part must be given the syntax "func n() = expression" adds functional programming more logic operators (exclusive or and some wacky ones that do exist) even more functions modulus - both in relation to the dividend and divisor more built-ins and constants $# returns number of arguments shift (like in shell), unshift, and $## returns number started with $+, $-, $* do operation on all arguments # comment Amazing string handling Arrays (though not that great a deal yet) It doesn't have Plan 9 hoc's named arguments (you still use $1, $3, ...)
> Hello. Aside from my cut project, I decided to see if I could use pcc
> to compile my own version of hoc(1) (http://www.andlabs.com/
> hoc_p9.tgz) and just after calling yacc, pcc has given me a whirlwind
> of incomprehensible error messages that I just won't work on putting
> here (I'm also running Plan 9 in QEMU and I haven't set up email
> there). Does anyone know what's going on?
hoc comes with plan 9.
- erik
i've put an updated copy on sources in contrib/forsyth/hocplus.tgz . just diff against the original to see the small changes (including mkfile). ape doesn't provide gamma or cbrt, but if they're in c99 i suppose it could. just add a local copy temporarily. gamma isn't in my copy of c99 though: it defines lgamma and tgamma. (the old gamma actually computed lgamma, i think.)
; mk yacc -d -S hoc.y conflicts: 184 shift/reduce pcc -c -D_RESEARCH_SOURCE -FVw y.tab.c warning: /usr/quanstro/src/hocplus/hoc.y:1192[stdin:925] param declared and not used: sig warning: /usr/quanstro/src/hocplus/hoc.y:1201[stdin:934] auto declared and not used: i warning: /usr/quanstro/src/hocplus/hoc.y:1247[stdin:1060] param declared and not used: sig warning: /usr/quanstro/src/hocplus/hoc.y:1984[stdin:1797] label declared and not used "yyerrlab" pcc -c -D_RESEARCH_SOURCE -FVw code.c warning: /usr/quanstro/src/hocplus/code.c:122[stdin:818] result of operation not used warning: /usr/quanstro/src/hocplus/code.c:132[stdin:828] result of operation not used warning: /usr/quanstro/src/hocplus/code.c:245[stdin:941] result of operation not used /usr/quanstro/src/hocplus/code.c:1101[stdin:1797] function args not checked: gamma warning: /usr/quanstro/src/hocplus/code.c:1271[stdin:1967] auto declared and not used: count warning: /usr/quanstro/src/hocplus/code.c:1271[stdin:1967] auto declared and not used: start pcc -c -D_RESEARCH_SOURCE -FVw init.c /usr/quanstro/src/hocplus/init.c:130[stdin:649] name not declared: gamma /usr/quanstro/src/hocplus/init.c:135[stdin:654] name not declared: cbrt pcc: cpp: 8c 3295: error mk: pcc -c -D_RESEARCH_SOURCE ... : exit status=rc 3292: pcc 3294: cpp: 8c 3295: error ; cd /sys/src/cmd/hoc ; mk yacc -d hoc.y conflicts: 19 shift/reduce 8c -FVw y.tab.c 8c -FVw code.c 8c -FVw init.c 8c -FVw math.c 8c -FVw symbol.c 8l -o 8.out y.tab.8 code.8 init.8 math.8 symbol.8
>mk: pcc -c -D_RESEARCH_SOURCE ... : exit status=rc 3292: pcc 3294: cpp: 8c 3295: error
you possibly missed the bit where i explained that he'd have to
add some functions missing from ape, one of which probably shouldn't be
added, but several of which might be
no. i misunderstood. i thought you had fixed that. why the interest in this version of hoc when one comes with the distribution that compiles without problems? - erik
[-- Attachment #1: Type: text/plain, Size: 19 bytes --] he'd extended it. [-- Attachment #2: Type: message/rfc822, Size: 2261 bytes --] From: erik quanstrom <quanstro@quanstro.net> To: 9fans@cse.psu.edu Subject: Re: [9fans] Problems with pcc Date: Mon, 12 Nov 2007 10:06:11 -0500 Message-ID: <bcdddd44985e0c4e1587c648fd81db86@quanstro.net> no. i misunderstood. i thought you had fixed that. why the interest in this version of hoc when one comes with the distribution that compiles without problems? - erik
mkfile
What is _RESEARCH_SOURCE?
hoc.y
You caught me there. I didn't even know I was breaking declarator
rules!
hoc.h
See hoc.y above
init.c, math.c, symbol.c - no difference
code.c
I didn't know at the time that in a?b:c, both b and c have to be the
same type
Anyways, I tested it and it works now (making dummy gamma()/cbrt())
but there were still warnings. I'll diff these changes back into the
main source. Thanks.
On Nov 12, 2007, at 9:17 AM, Charles Forsyth wrote:
> i've put an updated copy on sources in contrib/forsyth/hocplus.tgz .
> just diff against the original to see the small changes (including
> mkfile).
>
> ape doesn't provide gamma or cbrt, but if they're in c99 i suppose
> it could.
> just add a local copy temporarily.
> gamma isn't in my copy of c99 though: it defines lgamma and tgamma.
> (the old gamma actually computed lgamma, i think.)
> mkfile > What is _RESEARCH_SOURCE? see /sys/doc/ape.ms (or pdf versions of it) for details and other things you might need anyway > hoc.y > You caught me there. I didn't even know I was breaking declarator > rules! > hoc.h > See hoc.y above C standards still insist on the annoying need for forward declarations. if it has compiled on other compilers without fuss you should use better compilers (or more likely many of the right -W options for gcc, but not too many or it will moan about purely stylistic things!) > init.c, math.c, symbol.c - no difference > code.c > I didn't know at the time that in a?b:c, both b and c have to be the > same type the usual arithmetic conversions apply (because the expression evaluates to a single value of which ever type encompasses both true and false arms, not values or non-values of two completely different types, such as a struct and an int, or a void and anything else)
I've been maintaining our own version of "hoc" for many years now. One feature that I noticed the need for is: hoc [-e expression] [file ...] The expression, if present, is evaluated; then the named files are read and interpreted in order. If no file or expression is given or if a filename is "-", hoc interprets the standard input.
Charles Forsyth wrote:
> ape doesn't provide gamma or cbrt, but if they're in c99 i suppose it could.
> just add a local copy temporarily.
> gamma isn't in my copy of c99 though: it defines lgamma and tgamma.
> (the old gamma actually computed lgamma, i think.)
Yes, the name "gamma" had been used for both the gamma function
and its logarithm, on different platforms, so the C standard uses
other names for each of them. My version looks like:
/* hoc/math.c */
#include <math.h>
#if defined(__STDC__) && !defined(gamma)
#define gamma(x) lgamma(x) /* new name */
#endif
extern int signgam;
...
double
Gamma(x)
double x;
{
double y;
y = errcheck((double)gamma(x), "gamma");
#if 0 /* DAG -- not needed with following check on exp(y) */
if (y > 88.0)
execerror("gamma result out of range", (char *)0);
#endif
y = errcheck((double)exp(y), "gamma"); /* DAG -- added check */
return signgam * y;
}
...
cbrt is in the 1999 C standard. However, my version of "hoc" doesn't have a "cbrt" function, and I've never felt the need for one.
double cbrt(double x) { return pow(x, 1.0 / 3.0); }
I'm trying to find an intuitive implementation of gamma().
On Nov 16, 2007, at 5:19 AM, Douglas A. Gwyn wrote:
> cbrt is in the 1999 C standard.
> However, my version of "hoc" doesn't have a "cbrt" function,
> and I've never felt the need for one.
On Nov 12, 2007, at 9:17 AM, Charles Forsyth wrote:
> i've put an updated copy on sources in contrib/forsyth/hocplus.tgz .
> just diff against the original to see the small changes (including
> mkfile).
>
> ape doesn't provide gamma or cbrt, but if they're in c99 i suppose
> it could.
>
double cbrt(double x) { return pow(x, 1.0 / 3.0); }
APE does provide the log of gamma: /sys/src/ape/lib/ap/math/gamma.c.
The function is not referenced in any header file, and is called gamma
(). I changed its name to logofgamma and defined gamma as gammafunc
(to avoid name collisions with C99 compilers):
double gammafunc(double x)
{
double y;
y = exp(logofgamma(x));
return y * signgam; /* a global variable declared in the gamma.c */
}
On Nov 12, 2007, at 9:17 AM, Charles Forsyth wrote:
> gamma isn't in my copy of c99 though: it defines lgamma and tgamma.
> (the old gamma actually computed lgamma, i think.)
PS - tgamma == gamma
Pietro Gagliardi wrote: > double cbrt(double x) { return pow(x, 1.0 / 3.0); } Yeah, that's why I never felt the need to build it into the language. > I'm trying to find an intuitive implementation of gamma(). ? Gamma isn't very intuitive. It is essentially the factorial function "!" (with argument offset by 1) for the counting numbers, so you can think of the real part as the "natural" interpolating function for factorial.
>>>>> "Pietro" == Pietro Gagliardi <pietro10@mac.com> writes: Pietro> I'm trying to find an intuitive implementation of gamma(). Hello, have you seen this page http://www.rskey.org/gamma.htm which has the neat formula gamma(x) \approx sqrt(2 * pi / x) * ((x/e) * sqrt(x * sinh(1/x)))^x ? hope this helps Roland
Pietro Gagliardi wrote:
> APE does provide the log of gamma: /sys/src/ape/lib/ap/math/gamma.c.
> The function is not referenced in any header file, and is called gamma
> (). I changed its name to logofgamma ...
Since APE is supposed to emulate the *standard* POSIX environment,
I suggest restoring the original name in APE (for compatibility with
preexisting practice) and duplicating it as lgamma (tracking the C
standard, which POSIX references). You could add tgamma as an
implementation of the (not log of) Gamma function, again tracking
the standard name.
Pietro Gagliardi wrote:
> PS - tgamma == gamma
Actually, the name "gamma" has been used for functions that
computed both Gamma and log_of_Gamma. (Not at the same time!)
On most systems I have used, "gamma" computed (an approximation
to) the log of Gamma of its argument ("lgamma" is the Standard
C name for such a function, "tgamma" being used for the not-log
version; we decided not to use the name "gamma" for either,
because of the conflict with some of the existing practice).