sl@van-bc.UUCP (Stuart Lynne) (02/16/88)
Weirdness abounds once again!
I can successfully generate perl on my ancient Callan (a Unisoft 5.0 system,
basically System V release level 0 with some BSD ism's), but not on my modern,
uptodate, state of the art System V release 3 for the 386 at work!!!
The problem is yacc. I get the following results when make try's to generate
perl.c from perl.y:
Expect 2 shift/reduce errors...
yacc perl.y
fatal error: out of state space, line 595
*** Error code 1
Stop.
Line 595 is:
%% /* PROGRAM */
The yacc in question is from Bell Tech's version, which seems to be
identical to Microports version.
The quick fix for anyone else who is having this problem is to get the
perl.c generated by someone else. I copied mine from my Callan and it seems
to work ok.
Has anyone else tried this. I'd love to know if this is a generic System
V/386 bug or just something weird on my system.
If this is a bug is there any better work around than getting someone else
to yacc it for you?
I'm starting to think I'd better keep the Callan running after all ....
.... it does make a decent nroff/yacc server ;-)
--
{ihnp4!alberta!ubc-vision,uunet}!van-bc!Stuart.Lynne Vancouver,BC,604-937-7532grr@cbmvax.UUCP (George Robbins) (02/17/88)
In article <1675@van-bc.UUCP> sl@van-bc.UUCP (Stuart Lynne) writes: > Weirdness abounds once again! > > I can successfully generate perl on my ancient Callan (a Unisoft 5.0 system, > basically System V release level 0 with some BSD ism's), but not on my modern, > uptodate, state of the art System V release 3 for the 386 at work!!! > > The problem is yacc. I get the following results when make try's to generate > perl.c from perl.y: ... > fatal error: out of state space, line 595 Well, I have the same problem on my creaky old Zilog system. I don't know if yacc is actually runninng out of memory, or if it's just that in a binary release, you get a version of yacc compiled with the parameters set to fit the "worst case" i.e. PDP-11 / Zilog non-segmented / 8088 small-model memory constraints... I would be helpful if Larry could include the yacc output, with the makefile set up to only redo the yacc run in the critical input files changed, but of course this would make the release bigger... -- George Robbins - now working for, uucp: {uunet|ihnp4|rutgers}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@uunet.uu.net Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)
rick@pcrat.UUCP (Rick Richardson) (02/17/88)
In article <1675@van-bc.UUCP> sl@van-bc.UUCP (Stuart Lynne) writes: >I can successfully generate perl on my ancient Callan (a Unisoft 5.0 system, >basically System V release level 0 with some BSD ism's), but not on my modern, >uptodate, state of the art System V release 3 for the 386 at work!!! > >The problem is yacc. I get the following results when make try's to generate >perl.c from perl.y: > > fatal error: out of state space, line 595 Most likely, your YACC has been compiled with the "smaller" config parameters - suitable for machines with limited addressing (e.g. 286). I'd bitch loud and long at the supplier. -- Rick Richardson, President, PC Research, Inc. (201) 542-3734 (voice, nights) OR (201) 834-1378 (voice, days) uunet!pcrat!rick
davek@heurikon.UUCP (Dave Klann) (02/18/88)
In article <1675@van-bc.UUCP> sl@van-bc.UUCP (Stuart Lynne) writes: >Weirdness abounds once again! > >I can successfully generate perl on my ancient Callan (a Unisoft 5.0 system, >basically System V release level 0 with some BSD ism's), but not on my modern, >uptodate, state of the art System V release 3 for the 386 at work!!! > >The problem is yacc. I get the following results when make try's to generate >perl.c from perl.y: > > Expect 2 shift/reduce errors... > yacc perl.y > > fatal error: out of state space, line 595 > *** Error code 1 > >{ihnp4!alberta!ubc-vision,uunet}!van-bc!Stuart.Lynne Vancouver,BC,604-937-7532 I don't know if this helps you, but... I had a similar problem at first. I'm running SVR3.0 on an MC68020 box. After looking at the source for yacc I found that it was compiled for a machine with a wordsize of something less than 32 bits. When this happens, cpp will set the number of states (NSTATES) to 600. After recompiling yacc with the proper wordsize (to set NSTATES to 750) it blew right through perl.y Might be worth a call to Bell Tech. Larry, you're a genius!! Thanks for all the wonderful tools you've provided the world. You're a real inspiration to me!! id Klann Heurikon Corporation, Madison. WI Voice: 608-271-8700 (work) Disclaimer: "Member FDIC. Substantial penalty for early withdrawl." :-)
faigin@sdcrdcf.UUCP (Daniel P Faigin) (02/18/88)
In article <3328@cbmvax.UUCP> grr@cbmvax.UUCP (George Robbins) writes: >It would be helpful if Larry could include the yacc output, with the >makefile set up to only redo the yacc run in the critical input files >changed, but of course this would make the release bigger... Actually, we discussed this with larry when perl was first being developed. The problem is that the output of yacc contains AT&T propriatary code (inserted by the yacc program), and so yacc output can only be sent to parties with a source license. This makes posting the program difficult. Hence, the input to yacc is posted. The way I understand it, you cannot compile perl if you don't have access to yacc or bison (GNU yacc). Daniel Faigin (Larry Wall's former officemate) -- W: UNiSYS/Defense Systems/System Development Group 2400 Colorado MD 91-01;Santa Monica CA 90406;213/829-7511 x6393 H: 8333 Columbus Avenue #17; Sepulveda CA 91343 Email: (uucp) faigin@sdcrdcf.UUCP (arpa) faigin@RDCF.SM.UNISYS.COM
rsalz@bbn.com (Rich Salz) (02/18/88)
>>It would be helpful if Larry could include the yacc output. >Actually, we discussed this with larry when perl was first being >developed. The problem is that the output of yacc contains AT&T >propriatary code (inserted by the yacc program), and so yacc >output can only be sent to parties with a source license. Actually, this *MIGHT* not be the case. About 12 to 24 months ago, ATT put out an announcement saying that the stuff in /lib and /usr/lib could be used in vendor code without any licensing restrictions. They obviously meant to avoid the braindamage of other vendors (usually in the PC world) that required you to license the "run-time" system before you could resell your product. That is, if I wrote a program I wanted to sell, I did not need to do anything just becuase the executable used stuff in /lib/libc.a. Now, as is standard with all licenses, they listed all the relevant files affected by this change. I am fairly sure that /usr/lib/yaccpar and yacc output were explicitly called out as being in the category I described above. HOWEVER, I don't remember all the details. I would suggest that someone with a vested interest in this call AT&T (1-800-828-UNIX can probably get you started) and find out the full details. (I don't really care because all yacc's I have access to aren't broken. :-) Note, however, that even if (as I suspect) it's perfectly okay to ship y.tab.c and y.tab.h around to any site, such postings won't appear in comp.sources.unix because the bandwidth consumed far outweighs the sites with nonexistant or bad yacc's. Follow-ups are probably not necessary, unless researched. /r$ -- For comp.sources.unix stuff, mail to sources@uunet.uu.net.
gwyn@brl-smoke.ARPA (Doug Gwyn ) (02/19/88)
In article <5096@sdcrdcf.UUCP> faigin@sdcrdcf.UUCP (Daniel P Faigin) writes: >The problem is that the output of yacc contains AT&T >propriatary code (inserted by the yacc program), and so yacc >output can only be sent to parties with a source license. At a USENIX long ago, AT&T licensing spokesmen stated the contrary, that yacc output was free of licensing restrictions. This should be checked with them...
wnp@dcs.UUCP (Wolf N. Paul) (02/19/88)
In article <5096@sdcrdcf.UUCP> faigin@sdcrdcf.UUCP (Daniel P Faigin) writes: >In article <3328@cbmvax.UUCP> grr@cbmvax.UUCP (George Robbins) writes: >>It would be helpful if Larry could include the yacc output, ... > >... . The problem is that the output of yacc contains AT&T >propriatary code (inserted by the yacc program), and so yacc >output can only be sent to parties with a source license. ... >... . The way I understand it, you cannot compile perl if you don't >have access to yacc or bison (GNU yacc). If perl can be combined using bison, why not post the bison output instead of the yacc input or output? Certainly bison output does not contain any AT&T proprietary code ?!? -- Wolf N. Paul Phone: (214) 306-9101 (h) (214) 404-8077 (w) 3387 Sam Rayburn Run UUCP: ihnp4!killer!{dcs, doulos}!wnp Carrollton, TX 75007 INTERNET: wnp@dcs.UUCP ESL: 62832882 Pat Robertson does NOT speak for all evangelical Christians--not for me, anyway!
allbery@ncoast.UUCP (Brandon Allbery) (02/23/88)
As quoted from <3328@cbmvax.UUCP> by grr@cbmvax.UUCP (George Robbins): +--------------- | In article <1675@van-bc.UUCP> sl@van-bc.UUCP (Stuart Lynne) writes: | > I can successfully generate perl on my ancient Callan (a Unisoft 5.0 system, | > basically System V release level 0 with some BSD ism's), but not on my modern, | > uptodate, state of the art System V release 3 for the 386 at work!!! | > | > The problem is yacc. I get the following results when make try's to generate | > perl.c from perl.y: | ... | > fatal error: out of state space, line 595 | | Well, I have the same problem on my creaky old Zilog system. I don't know | if yacc is actually runninng out of memory, or if it's just that in a binary | release, you get a version of yacc compiled with the parameters set to fit | the "worst case" i.e. PDP-11 / Zilog non-segmented / 8088 small-model | memory constraints... +--------------- Plexus P/35 Sys3.31 has the same problem. So I yacc'ed it on my 3B1. ;-) It does seem to be a compiled-in constant. Yacc in particular seems to be rather bad in that respect: not only are most of the table sizes fixed at compile time, so are the temporary and output file names (yacc.acts, yacc.tmp; y.tab.[ch]). I don't see any reason for this, offhand; I've written a parser generator (nothing as complex as yacc, but it works) which does all that dynamically. Maybe it's time to either (a) redesign yacc or (b) drop it in favor of bison? -- Brandon S. Allbery, moderator of comp.sources.misc {well!hoptoad,uunet!hnsurg3,cbosgd,sun!mandrill}!ncoast!allbery KABOOM!!! Worf: "I think I'm sick." LaForge: "I'm sure half the ship knows it."