@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