summaryrefslogtreecommitdiff
path: root/web/yacco2/compiler/o2/bugs.w
diff options
context:
space:
mode:
Diffstat (limited to 'web/yacco2/compiler/o2/bugs.w')
-rw-r--r--web/yacco2/compiler/o2/bugs.w426
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
+