your %a problems

vern%lbl-csam at sri-unix.UUCP vern%lbl-csam at sri-unix.UUCP
Thu Dec 22 16:31:42 AEST 1983


From:  Vern Paxson [rtsg] <vern at lbl-csam>


Re:

    Subject: LEX wizard needed. %a problems
    Newsgroups: net.unix-wizards net.unix

    I am having some serious problems with lex that involve messages that
    say "too many transitions, try %a num" when I add a few more translations
    ({} constructs) to a working lex script.  For the sake of brevity, I
    won't include the details here, so if you feel you know something about
    lex, please write to me personally and I'll send you a detailed listing
    of the trouble.

		    Thanks in advance for help to a desperate
		    programmer in the New Hampshire wilderness,


		    Lorien Y. Pratt
		    Dartmouth College Library
		    Hanover, NH  03755

		    decvax!dartvax!dartlib!rlorien


This is one of several cryptic error messages that Lex is capable of.
It is trying to tell you that your Lex input is too complicated for
the default values of certain Lex internal structures used to translate
the input into a scanner.  Lines of the form:

    %letter number

may be put in Lex sources to instruct Lex to use alternative internal
values in order to permit processing of bigger-than-the-default-maximum
sources.  The various letters and what they correspond are:

    e  -  nodes  
    p  -  positions  
    n  -  nfa states  
    k  -  packed char classes  
    a  -  packed transitions  
    o  -  output slots  

This information can be gleaned by studying the output of the verbose
flag ("lex -v").  The problem you have is that the default number of
packed transitions (2000) is too low.  So a line like

    %a 3000

at the beginning of your Lex source should fix it.  In general, you can
find out the default values of various %letter parameters and how close
you are to using all of the resource by using Lex's "-v" flag.

I would appreciate if possible having a copy of your Lex input - I am
analyzing the performance of a new Lex tool (written in Ratfor) which on
most large Lex inputs accomplishes considerably more table compaction
than Unix Lex, and as such I am especially interested in large Lex inputs.

Good luck, and let me know if this doesn't clear up the problem for you.

		Vern Paxson
		Real Time Systems Group
		Bldg. 46A
		Lawrence Berkeley Laboratory
		1 Cyclotron Rd.
		Berkeley, CA 94720

                vern at lbl-csam   on milnet



More information about the Comp.unix.wizards mailing list