On Wed, Oct 26, 2016 at 01:45:46PM +0100, Thomas Adam wrote:
> On Wed, Oct 26, 2016 at 02:21:57PM +0200, Dominik Vogt wrote:
> > First of all I hope I'll be able to find the crash caused by a free of a
> > string that is still
> > used, then experiment with it to see whether a step by step replacement of
> > the old
> > parser is feasible while keeping the old parser around for a while.
> > Disentangling the
> > builtin functions from the parser without changing their syntax is an
> > important step towards a new parser with a new syntax. As long as all the
> > functions do their own parsing, replacing the syntax is a huge amount of
> > work.
>
> But what you're describing is the biggest piece of work which would almost
> define fvwm3. Thus far, there's still an on-going discussion about how we're
> going to do that. Heck, we haven't even declared fvwm2-stable or fvwm-2.6.7
> yet. Aren't you jumping the gun a little?
Maybe, maybe not. This work only changes the inner structure of
the parser yet and has few user visible changes (some rarely
triggered quoting issues).
> I'd argue---quite strongly---that any work towards a new parser should be done
> with breaking everything completely. Sure, you can still keep some of the
> surrounding things, but trying to maintain backwards-compatibility isn't
> necessary given the measures we're putting in place for fvwm2's future.
It's not about staying compatible but about changing the parser in
steps with a useable intermediary result that can be tested.
Donig the parser from zero would mean to have nothing that works
even remotely for months.
> But at the moment, we haven't even discussed what that will look like, or what
> requirements we might have. I started to do that recently when I put out a
> proposal for a new syntax to see how that fared.
Yeah, I've seen that. The current work should be independent of
the syntax we're aiming at though. I would imagine changing the
parser in several distinct steps:
1. Restructuring the code so that different parsers can be plugged
in at run time on a per builtin basis.
[This is what the current work is about.]
2. Replace the current builtins parsing code with an abstract
syntax description and provide a parsing core that can parse
the input and provide the output the builtins need.
[This is the really big chunk of work.]
3. Replace the internal parser language (quoting, argument
passing, variable expansion, conditional syntax etc.).
4. Rewrite the builtins' syntax descriptions to a new style that
will hopefully be easier to read, write and parse.
Note that once step 1 is complete, the following steps can be
written and tested in a separate parser plugin, so the code stays
useable even while the new parser is still under construction.
You just switch to the unfinished parser for certain commands.
Once the result is stable, the duplicate code can be eliminated
(or kept around for a while to give people more time to adapt).
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
