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 "if". > * 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 buggy. > 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 framework. 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 branches. 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. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
# test nesting calls destroyfunc ftest addtofunc ftest + i ftest ftest ftest
# test fork bomb destroyfunc ftest addtofunc ftest + i ftest + i ftest ftest ftest
# test function growth destroyfunc ftest addtofunc ftest + i ftest2 destroyfunc ftest2 addtofunc ftest2 + i addtofunc ftest i ftest2 ftest ftest
