diff options
Diffstat (limited to 'web/yacco2/compiler/o2/bugs.w')
-rw-r--r-- | web/yacco2/compiler/o2/bugs.w | 426 |
1 files changed, 426 insertions, 0 deletions
diff --git a/web/yacco2/compiler/o2/bugs.w b/web/yacco2/compiler/o2/bugs.w new file mode 100644 index 0000000000..f9b70b625b --- /dev/null +++ b/web/yacco2/compiler/o2/bugs.w @@ -0,0 +1,426 @@ +@q% bugs.w@> +@q% Copyright Dave Bone 1998 - 2015@> +@q% /*@> +@q% This Source Code Form is subject to the terms of the Mozilla Public@> +@q% License, v. 2.0. If a copy of the MPL was not distributed with this@> +@q% file, You can obtain one at http://mozilla.org/MPL/2.0/.@> +@q% */@> + +@** Bugs --- ugh.\fbreak + What are they good for? Abolutely nothing! +Though i paraphrase the song, my entomology teaches and exposes my myopic shortcomings. +Ahh... the forest versus the trees of relativist processes attending to correctness. + +@*2 |Microsoft compiler| Corrupted memory heap.\fbreak +Well here's the scoop: IT IS THEIR TEMPLATE HANDLING +of a globally defined set: +The following code shows the bug:\fbreak +\let\setuplistinghook = \linenumberedlisting +\listing{"/usr/local/yacco2/diagrams/bug1.txt"} +\fbreak +\let\setuplistinghook = \relax +Debug displays the dtor winddown of the tree +when the program is exiting that gives its access violation. +It is walking the tree when it thinks there is something to delete --- +bad initialization values for their iterators within their container. +There are other heap variants but ... +Now the real stupidity: screen shots for MS to deal with +and trying to send the ``feedback'' to MS out of +Visual Studio 2005 caused another Visual Studio bug: +it experience technical difficulties ... did not register the problem with them + --- +but i had their acknowledgement reference number that i emailed +with their assurance that they would within 3 days (whose days business?) +acknowledge receipt of the to-be-investigated problem. +Well u got it i'm still waiting. +From the above code i have no pre-initialization code before it enters +the mainline but i'll not display their screen shot as this is +wasting my time. + +Again it's a sad statement regarding +how they deal with problems and lag time before +product fixes: just read their approach to voting on bugs before fixing them, +all other software companies call it a ``Bug Report'' or a variant there of +but not MS --- +their euphemism is Customer Feedback ... stop gagging Dave, +and why is it 2 years between compiler releases to correct bugs, and +have u tried obtaining their Beta compiler release? +\fbreak +There is no fix until MS fixes it in possibly their next release. +Until then at least it reguritates at the end of the program +and my patience for the deliverance day. +\fbreak +\fbreak +Early July 2006. +\fbreak +@*2 Comment no 2: Apple bug -- Problem Id: 4403453 unresolved linkages.\fbreak +Open source has it's warts whereby i was testing how +Apple deals with problems when they go thru a middle man +like gnu.org for their C++ compiler and linker. +At least they have a ``Bug Reporter'' and dialogue of receipt and +``how's it going'' followups. +Unfortunately +they flunked in their Californian way to getting the problem fixed +and in not answering how i could get their lodged reference number +when they passed the problem to the gnu.org. +My beef is how i can track my problem(s) within the open source community +thru the middleman and see how fast they correct the problem? +Voting does not count here. +This problem is still being sat on by Apple +when their last followup was ``how's it going?'' (only 10 months o/s). +It only confirmed my skepticism about this community and my middleman and how +they pass on the problem. I have not reached the next step in how gnu.org +deals with the fielded problem. +Going to gnu.org shows a genuine honesty towards publishing problems. +Microsoft is not of the same ilk. +If they were GM would people buy their cars particularly when +there are the Naders who keep them accountable? +What would it cost in litigation towards tarnished goods / services by MS? +\fbreak +\fbreak +Another beef:\fbreak +Proof of bug demonstrated with logged outputs etc +does not seem to be adequate in Apple's engineers' minds? +Boy i can't wait for the day when the software +manufacturer can under restricted access enter my computer +and see / diagnose problems without +the crap of whittle down code size, demonstrate +the bug in at most 1 line of code platitudes. +At least Apple is a bit more earnest in frontline manners... but +i'm still waiting on this problem particularly +when their engineer flubbed the initial response back to me. + +Alas what can i do? +I'm currently looking at Sun and their development team to +deliver a better comnpiler +with faster logistics in dealing with bugs. +I'm more optimistic as my people used the ``Oregon Pascal'' +compiler for 16 years. +Even though the company folded in the early nineties +some of their excellent compiler engineers +are working for Sun. +So let's see when my Sun AMD desktop running Solaris 10 +and 3 years software support with Sun comes in so that i can peddle-to-the-metal +my program against this new backdrop. +So far all portings have drawn problems be it interpretations of +the C++ compiler standard +by the compiler writers with their implementations, +past failings by C++ compilers to handle properly +class itor lists with 1998 work arounds, template tantrums +to this day and i'm not meta templating, and threading issues. +I guess i'm just stubborn in what i think will be good for the +software world: as i just keep on hanging on as the song goes... +I'm slowly regressing towards C only cuz C++ has that ++ complexity with ++ bugs. +The beguiling part of C++ is templates dealing with common containers +that makes the withdrawal process more painful... +\fbreak +\fbreak +9 Jan 2006.\fbreak + +@*2 |Sun Microsystems compiler|. Excellent!.\fbreak +Well so far the \O2 port is going well. +Their performance tools are great. +Their compiler works as it should. +Their development IDE is close to Microsoft in facilities. +The only speed bump is in the ``file mount'' when it occassionally gets lost +in not finding things even when the mounted account has been refreshed. +Also their text editor can't handle very large text files like tracings. +The odd time ``Sunstudio'' goes in tail-chasing: must exit out and sign back in but... +Overall rating between a 1 - 10 dada 11 that binary for well done even with the droppings +as what is probably happening (my musings) in their messaging / interupt facility +drops those claques --- that french for hits. +\fbreak +\fbreak +23 March 2007.\fbreak +PS: won't be going back to Microsoft. They are too arrogent without the personalized +client support. Sun's problem reporting / case followup is just excellent. With just posted +black quarter results and the flop of Vista buy-in i hope this bodes well for Sun +who are trying very hard to be Open and frank. Keep it going Sun! + +@*2 Incomplete gening of state's core items due to common prefix.\fbreak +The state being gened is determined by the elements associated to the closure +state being formed. +If there is a common prefix making up the state whereby the elements come from +different closure states, still all the elements must go into the goto state being gened. +As i walked the vector list, the elements that were of different closure state +were skipped. +This was the filtering that took place when the State was +being assessed for closure items generation. +The first item found for generation also became the starting point within the list +to gen from. Remember the ``goto symbol'' vector is a list of elements to gen. +Solution: any element in the +``goto symbol'' vector meets the filter criteria, then +the complete list must be used: not from the point found within the list. +Like any mistake --- just dumb! It was not conceptual but an implementation slippage. +|@<create a new state@>| adjusted as the element list's +``begin and end'' j and je variables are +present due to Apple's compiler's indigestion. Again quality assurance on +Open Source can be exasperating at the compiler level! Sun's compiler +is greeeeat! +\fbreak +\fbreak +July 2007.\fbreak + +@*2 Missing reduced state deposit on prefix elements + leading up to the merged state.\fbreak +Only went back 1 element to deposit the reduced state: Missing reduce deposits +for the balance of elements + thru to the beginning +of the subrule. Man there are times when u missed the boat Dave. No its links! +\fbreak +\fbreak +July 2007.\fbreak + +@*2 3rd party AdobeReader annoyances.\fbreak +|xpdf| and |gpdf| programs ain't doing too well on my Sun Solaris Operating system. +As i output pdf documents and these programs either core dump or display partial info, this +ain't good. +So i have split up the documents generated so that one can take what is wanted, and +hopefully i'll be able to get a more recent version that works as +Adobe seems to be avoiding proprietary Ops --- particularly Sun. +BTW, the generated documents work properly on my Apple iBook laptop. +\fbreak +\fbreak +Sept. 2007.\fbreak + +@*2 Missing T(s) in lookahead set due to merges.\fbreak +The problem was i use a list of closure states of merges that are state contexts +for the follow set calculation. +Remember, closure states provide the follow set contexts. +If 2 subrules of a rule are merged into the same ``closure state'' context: +u now have duplicate states in the ``merged into'' list. +So i test on membership before adding to the list. +Here's the melted down rogue grammar where ``Ra'' has the 2 subrules:\fbreak +\let\setuplistinghook = \linenumberedlisting +\listing{"/usr/local/yacco2/diagrams/1test.txt"} +\fbreak +\let\setuplistinghook = \relax +Ra's lookahead set is ``c,m,t'' but it was missing ``m'' +caused by the duplicate closure state. +Why u ask does duplicates cause a problem? i tested visited states to guard agaist +cycles so +stop going thru the balance of the list! +\fbreak +\fbreak +Nov. 2007.\fbreak + +@*2 Not testing Start State for LRness.\fbreak +The symtoms: the quality assurance non lr1 grammar caused \O2 to loop +when gening its states and more states ... +The cause came from the epsilon rule in the state state +not having its reduce\_state set to self. +When gening the |calc_la| for the reduced subrule, it exited due to the +sanity check on state address must be the same as the reduce state address. +So there was no lookahead set for the reducing and consequently +no proper santity checks of outcome. +Well why did u not thrown an error? +Don't know what my thought process was at time so enough of the conjecture. +The |TS_path7.lex| grammar did it. +So let's hear it for QA. +\fbreak +\fbreak +Jul. 2008.\fbreak + +@*2 Run run run run run away.\fbreak +The symtoms: gening of states keeps going into a right recursion loop +that never ends until ``death do us part'' with memory. +The current closure state network being gened did not detect on self +one of its states being ``not lr1'' compatible. +Please see |/yacco2/qa/knu1_sick.lex| +grammar to test this out. +This bug came about when i was gening up some of the grammars from +Knuth's paper --- ``On the translation of laguages from left to right'' +In ``Information and Control'', volume 8 of 6, pages 607--639, 1965. +The first grammar got mistyped where RB was replaced with RA +which made it not lr1. +Not too swift Dave --- ahh the Occam of self reflections. +But the detection of it strengthens \o2. +\o2 stops gening the lr states, announces the bad news, +and reguritates its states configurations to show where the +nonlr1ness was found. +\fbreak +\fbreak +Oct. 2008.\fbreak + +@*2 Ditto to above --- random monkeys throwing coconuts.\fbreak +The symtoms: occassionally not completing the gening of states +for a specific closure network. +Due to the introduction of |gening_a_state| returning a status, +i forgot to return ``a default true'' when the vector loop was completed. +This loop is normally not completed ``the normal for loop'' way +but a ``bypass this vector for the gening'' +as it is associated with another closure state network +continues with the next vector in the for loop. +So random results returned was caused by +whatever was in the memory at the time. +So it's not the sky falling only Dave's memory lapses, myopic vission, +and not paying attention to the simple code. +\fbreak +\fbreak +Oct. 2008.\fbreak + +@*2 Random VMS monkeys throwing spurious end-of-lines into streaming text.\fbreak +The symtoms: in VMS the outputted C++ source files contains spurious carriage returns. +Man u should see what it does to the C++ compiler +when trying to compile these grammar programs where variable names are +sliced-and-diced, struct defintions malformed, and + keywords being morphed. When the VMS C++ compiler hits +the streaming text's buffer-end +it takes the initiative to insert an end-of-line (carrage return). How calvalier! +\fbreak +The work-around: Use lots and lots of ``std::endl()'' +to flush out the text buffer instead of text ending with ``\\n''. +Not efficient but hey do u think HP will fix this +when their C++ compiler is probably contracted out? +Researching this problem they suggested this work-around +as the smell is still lingering and the latest compiler +dittos the same tune. +Ditto workaround to \olinker's output that manages the global thread list +and their ``first sets''. +\fbreak +\fbreak +Dec. 2008.\fbreak + +@*2 Take 2: Random VMS monkeys throwing spurious end-of-lines.\fbreak +The problem is how VMS opens a file. If it is transfered using ``ftp'' +onto the Alpha as default text, then the file attributes are variable length with carriage return. +This is the fault. By getting ``o2'' working and deleting all the ``cpp'' type files, they +get gened as ``stream-lf'' file and not as a file of variable length with carriage return. +This was discovered when ``o2linker'' was taking 60 to 100 x longer to +output the ``yacco2\_fsc.fsc'' +file from its input: ``yacco2.fsc'' file. +When the old ``yacco2\_fsc.cpp'' file was removed, +VMS operating system did not default to the previous version +with its attributes but created it as a ``stream-lf'' type file provided by ``ofstream'' type. +This stopped the heavy seeking on writing out the file as it was probably +doing this per character. +Now the file is generated in less that a second rather than 60 plus seconds. + +This led to looking at the last problem of random ``end-of-line'' inserts +being injected into the source file +when on its file buffer boundary: when +it flushes the buffer out to the disk. +Low and behold, both generating of Tes and Error definitions now work + with ``stream-lf'' file attributes and {\bf no suprious end-of-line} injections. +Yipee. +\fbreak +\fbreak +Dec. 2009.\fbreak + +@*2 Other takes on VMS port: cxxlink.\fbreak +When linking the last problem was unresolved symbols: {\sl cxxdemangle} on these symbols +showed that they were all template based. +Required was making sure the various respositories + were also present per +library: ``yacco2'', and ``o2grammars''. Without this, some of the templates from ``o2'' +were undefined due to incomplete instantiation. +For the 2 libraries, it is their type definitions used within the +templates that are required. +Here is {\sl cxxlink}'s {\bf /reportitory} parameter for ``o2'' link +to resolve their references:\fbreak +\INDENT{2cm}{/repository=([yacco2.compiler.o2.cxx\_repository]-} +\INDENT{3cm}{,[yacco2.compiler.grammars.cxx\_repository]-} +\INDENT{3cm}{,[yacco2.library.cxx\_repository])-} +This allows VMS's {\sl cxxlink} to recompile these partially instantiated templates. +The 1st repository is read/write while the others are read-only: u must follow the order as +``o2'' is still being compiled and its repository will be completed by the +{\sl cxxlink} reguritation of source templates back to {\sl cxx} compiler. + +The order of the +libraries inputted are not multipassed by {\sl cxxlink} for unresolved symbols. +This occurred with yacco2's symbol table ``add\_sym\_to\_stbl'' routine that +is in the ``o2grammars'' library. +Originally the inputted libraries was ``yacco2'' followed by ``o2grammars''. +I needed to have the ``o2grammars/lib'' +first in the list of libraries instead of ``yacco2/lib''. + +A final adjustment was ``how much stack space'' to reserve both per thread and for the process +that the threads ran under. +Parameter ``stack=1024'' for the process like ``o2'' and ``o2linker''. +``pthread'' allocation is 10$^6$ in bytes in the ``yacco2\_compile\_symbols.h'' file:\fbreak +\INDENT{2cm}{VMS\_PTHREAD\_STACK\_SIZE\_\_ 1024*4*256} +It was a bit of a hit-and-trial-by-fire to get it going. +All told now ``o2'' is ported onto VMS and it works. +\fbreak +\fbreak +Dec. 2009.\fbreak + +@*2 Evil con numbra those optimizations: lr1 compatibility check.\fbreak +Background to my stupidities in |is_state_lr1_compatible|:\fbreak +A thread grammar's la expression has only ``eolr'' in it. +So it is not exploded into all the other Tes if alone. +Now the lr1 compatibility check expected that the reducing la +had exploded it. So ... +Before it was working but with the explosion or is my implosion? +\fbreak +\fbreak +To respect the optimization, 2 checks are done:\fbreak +If there are 2 reduces taking place and ``eolr'' is present then not lr1. +On the shift / reduce check, if ``eolr'' is present then ca boom. +\fbreak +\fbreak +Jan. 2010.\fbreak + +@*2 \ALLshift{} versus ``eolr'' Evil con numbra duo: lr1 compatibility check.\fbreak +See previous stupidity. +With above eolr vs \ALLshift{} which also means all-the-terminals. +So u are shifting on all Tes and trying to reduce on all Tes. +I lean to the shift-in-the-wild until + the use \ALLshift{} facility is turned off. +This is a non lr(1) extension. +Leave alone and default to \ALLshift{} over ``eolr''. + +\fbreak +\fbreak +2 lr(1) compatability checks are done:\fbreak +If there are 2 reduces taking place and ``eolr'' is present then not lr1. +Shift / reduce check: if shift not one of the ``lr1 k terminals'' and the +eolr is present its ca boom. +\fbreak +\fbreak +Feb. 2010.\fbreak + +\fbreak +\fbreak +@*2 Closure state/vector context infinitely gening states when 1 of its own states not lr(1).\fbreak +Originally detected improperly which made a legitimate grammar declared as not lr1.\fbreak +The short of it is to test the states while being gened for lr1 compatibility. +The loop was caused when the gening closure state/vector was within itself and not lr1 +which kept adding to the states to be gened. +|gen_a_state| and |gen_transitive_states_for_closure_part_of_state| now handle +the situation properly. +The gening closure context is passed to them with these functions returning +``continue gening'' or ``stop'' status back to their callers. +The bad state is added to the gening states network so that the appropriate +state reducing context is reported to the user as not lr1 for fixing. +Also the gening of the grammar's start state loop within the main program +handles the compatibility issue while gening rather than do a post lr1 evaluation. +\fbreak + +Rewrote the ``lr states driver'' and +included tracing to {\bf{lrclog}} with the lr state decisions made +using the closure/vector gening contexts regarding states its gens, +merging of states, and non lr1ness discovery be it against proposed state merges, and ugh +a non lr1 grammar. +This log allows one to review decisions made by \O2{} to discover faulty grammars, or faulty gened grammars. +Of course its a faster way for me the author to correct implementation +foibles. +It also helps u when +the grammar is wonkie and u want to see where the ambiguous context is for the correcting. +\fbreak +\fbreak +Oct. 2014.\fbreak + +@*2 Improvement: arbitration-code procedure name added to grammar doc.\fbreak +Where did i indicate the arbritration code used or not by each \PARshift{} state? +Nada. So |mpost_output.lex| grammar now emits such indicator when present to the grammar's document +within the lr state network, + |o2_types.w| and |o2_defs.w| +were adjusted to add the |arbitration_name_| string in the state definition. +|o2_externs.w| sets the state's |arbitration_name_| +when found in the state where one of its threading subrule(s) has arbitration-code. +At least now the grammar writer can post assess when arbitration is happening. +\fbreak +\fbreak +Oct. 2014\fbreak + |