Re: My baby text to HTML paragraph converter

Hi All,My two cents to this is that bison can be used with C++ as well :) S=
ee:https://www.gnu.org/software/bison/manual/bison.html#A-Simple-C_002b_002=
b-ExampleBR,r0ller-------- Eredeti lev=C3=A9l --------Felad=C3=B3: Aryeh Fr=
iedman <[email protected]>D=C3=A1tum: 2023 december 17 00:39:13T=C3=
=A1rgy: Re: My baby text to HTML paragraph converterC=C3=ADmzett: Steve Lit=
t <[email protected]>On Sat, Dec 16, 2023 at 5:47=E2=80=AFPM Steve =
Litt <[email protected]> wrote: > > Piotr Siupa said on Sat, 16 Dec=
 2023 02:47:52 +0100 > > >Hi Steve, > > > >Sorry if I'm reading too far int=
o it but from the fact you're using a > >shell script for building this, I'=
m assuming that you're pretty new to > >work with bigger programming projec=
ts. > >Because of that, I'm going to give you some homework. Specifically, =
I > >think you should research two things: > >- Build automation tools - Th=
ey (similarly to your script) build the > > I use make on big projects that=
 take more than 30 seconds to compile > via a "compile and link everything"=
 script, but at compile times below > that, I just use "compile and link ev=
erything". I make lots of > mistakes, and find "compile and link everything=
" makes me less > mistake prone than make.  If you have problems with Make =
often repeating steps unnecessarily it is due to the fact it does not view =
the entire build process as one big DAG (directed acyclic graph).   For mor=
e information see the following older but still very relevant paper: https:=
//aegis.sourceforge.net/auug97.pdf ("Recursive Make Considered Harmful", Pe=
ter Miller 1997).    If you find the paper helpful you might want to look i=
nto the build system Peter made in response to his own paper: cook (https:/=
/petermiller.work/pmiller/software/cook/).... Disclaimer: I wrote the offic=
ial tutorial for it.   > I've never authored anything requiring autoconf, a=
nd hope I never have > to. One of my fundamental beliefs is that I should u=
se as few > dependancies (especially Other People's Code) as possible, beca=
use every > layer of abstraction complexifies the code and makes troublesho=
oting > more difficult. My low use of dependencies lessens the need for > a=
utoconf. As far as portability, I'd rather #ifdef that into my code > than =
use autoconf. > > Another thing about me: I try very hard to write my C cod=
e such that > gcc -Wall is silent. Even "harmless" warnings are harmful bec=
ause they > disguise the genuinely harmful ones. I also make sure my HTML5 =
is well > formed XML and passes an XML parser, and validates via the W3C > =
validator. The Troubleshooters.Com web pages I've written in the past 3 > y=
ears look identical on all reasonably standards compliant browsers > that a=
llow Javascript.  Have you considered a language that is more conducive to =
good software engineering like Java.   I switched from C to Java about 10 y=
ears ago after using C for 20 years and one too many bugs caused by stray p=
ointers.   Also C is very hard to unit test except in the most trivial case=
s.   If you do switch, the equivalent of Bison in Java is ANTLR.   As an ad=
ded bonus there is no need for #ifdef's and other weirdness needed to make =
it portable since all implementations of the JVM follow the same language/s=
tandard library standard (unlike C and the various OS combos).  As far as t=
esting goes see below  > > > >- Version control - It tracks all changes you=
 do to your project, > > I don't know how you found out I don't use version=
 control, but your > right, I'm lousy at git and that has to change. I'm OK=
 with git until I > have to deal with branches, and then I go to pieces. Th=
is, and the fact > that the only human language I speak is English are two =
of my worst > flaws. > > I'll re-remind myself to try learning more about g=
it. Thanks for your > reminder.  One of the weakest aspects of traditional =
mainstream version control (git, cvs, svn, etc.) is it does not force you t=
o prove that your code works before it enters the baseline (i.e. pass all o=
f it's own tests).  Peter Miller's aegis (https://aegis.sourceforge.net/) d=
oes this and thus the combo of cook and aegis is the only thing I trust in =
my larger projects like a soft life critical web portal for medical IoT (re=
mote cardiac monitoring).  This is because any other combo either breaks or=
 makes it easy to break one of Peter Miller's laws of software construction=
 (https://en.wikipedia.org/wiki/Peter_Miller_(software_engineer)) which are=
:  1. The number of interactions within a development team is O(n!) without=
 controlled access to the baseline. If the development team does have contr=
olled access to the baseline, interactions can be reduced to near O(n), whe=
re n is the number of developers and/or files in the source tree, whichever=
 is larger. 2. The baseline MUST always be in working order. 3. The softwar=
e build/construction process can be reduced to a directed, acyclical graph =
(DAG). 4. It is necessary to build a rigid framework of selected components=
 (aka the top level aegis design). 5. The framework should not do any real =
work, and should instead delegate everything to external components. The ex=
ternal components should be as interchangeable as possible. 6. The framewor=
k should use the Strategy pattern for most complex tasks.   > > > SteveT > =
> Steve Litt > > Autumn 2023 featured book: Rapid Learning for the 21st Cen=
tury > http://www.troubleshooters.com/rl21 >   -- Aryeh M. Friedman, Lead D=
eveloper, http://www.PetiteCloud.org =20