On Sun, Nov 21, 2021 at 09:23:20PM +0000, Thomas Adam wrote:
> On Sun, Nov 21, 2021 at 02:38:09PM +0100, Dominik Vogt wrote:
> > The parser branch is a ready as it will be without people testing
> > it more.  The upstream branch dv/master hat the latest, merged
> > together patches with extensive debug to stderr enabled.
> >
> > Please take a look.  If there are no findings I'd like to put this
> > on master.
> I'll keep testing it here over the next few days.
> Before merging, it would be nice to:
> * Convert some/all of the printf(stderr, ...) calls to fvwm_debug() lines so
>   debugging is going through that mechanism.

Yes, no problem.  The debug printfs were meant to go away before a
real commit, but that won't be happening soon.

> * Remove/convert some remaining comments starting "!!!".

The '!!!' is my way of marking the places that are incomplete or
need work.  It will take a while to get these done.  I'd

> * Decide on the '#if 1' blocks -- are there they to stay permanently?

No.  Any block marked with !!! must go away.  I need to understand
the single one that is not, but I think it must stay without the

> * Not just related to change per se (but still present) appears to be what I
>   would class as extraneous "return;" lines at the end of void functions which
>   seems odd to me.

I always put a return at the end of a function.  So, if there is a
void function without a return, function is likely incomplete or

> I will also get some tests in place as well.

I thought we could have some litte suite:

1) A shell script that starts Xephyr on desk 99 or whatever.
2) Starts fvwm on it with "-f testconfig".
3) testconfig is a simple script that adds a bit of test
   framework like printing the a test name and providing some
   result testing command.
4) Tests that do they work in a standardised way using the

See the three attached parsing test cases for nesting, forking and
self modifying functions.

> > (Note: Produces a ton of debug output and is not suitable to the
> > general audience.  Debug output can be disabled by debug defines
> > in functions.c and cmdparser_old.c.)
> It's things like this which tell me "it's not quite ready yet to be merged".
> Which is good, because this branch is level with master so it doesn't need to
> be merged just to test it -- and it's that shift in mentality, trying to
> keep master in the most stable state it can be which helps a lot with the
> release process.

Yeah, agreed.  Still sometimes it's necessary to get some help
from the people who would test master but not obscure development

This mess of interleaving patches dealing with all kinds of topics
is not what I'd accept nowadays in a stable branch (i.e. now that
there's git).  At the moment it can hardly be avoided because
there are so many fundamental changes going on.


Dominik ^_^  ^_^


Dominik Vogt
# test nesting calls
destroyfunc ftest
addtofunc ftest
+ i ftest
# test fork bomb
destroyfunc ftest
addtofunc ftest
+ i ftest
+ i ftest
# test function growth
destroyfunc ftest
addtofunc ftest
+ i ftest2
destroyfunc ftest2
addtofunc ftest2
+ i addtofunc ftest i ftest2

Reply via email to