Subject: Re: some leftover questions

From: Omar S Juma <[email-masked]>
Date: Sun, 29 Sep 1996 00:56:13 -0400

> You may have noticed: I grabbed all sort of parsing code from fvwm & some
> modules and built them into the lib, while using only the best of each
> implementation and optimizing the whole for stability & speed.

yes, i did notice, and it's a welcome improvement.  one of the things that
has boggled my mind is the complexity of the parsing code, given the
simplicity of the supported input language.  i have been toying with the
idea of completely rewriting the parsing support in ewm, for several reasons:

 - smaller code.  yes, it's true, fvwm is compact, but it could be cut down
   in size even more if all those string comparisons, checks, handoffs, and
   traversals happened in a nice enclosed code set that would serve
   both program and modules.
 - parser/language improvements.  any changes to the input language
   would be awfully hard to implement with the "distributed" parsing
   scheme.  clarifying control over the input file(s) would shorten
   the idea-to-implementation time.
 - tokenization.  turning the input file into a token stream would
   greatly reduce the amount of immediate-tokenization code currently
   required to get the next string, chew the next whitespace, etc.
 - those ugly tabs.  using tabs as explicit tokens (at least for 1.xx)
   was an evil and homely act of coding.  this was stuff they did
   in the 70's with "sophisticated" fortran programs, and does not
   belong here.
 - full regexp support.  fvwm 1.xx only supported "*" and "?" for regexp
   processing.  [actually, the current ewm already uses regex; encapsulating
   string processing in a string class was the key].

> Never dare to change anything unless you've grepped the whole source tree !!!

i hear you.  some of those greps have required substantial and delicate
regex specification, and even then it's been a nightmare.  going to c++
has added to the difficulty, since grepping for x and y assignments can
lead to all sorts of unanticipated detours.  however, grepping an entire
source tree to learn about code structure should be relegated to the
fifth layer of hell.

also, and this is not to throw egg in anyone's face, since i've been
guilty of same, but there is code there that i can't even begin to understand,
and there is not a shred of in-code documentation to explain it.  it's taken
a lot of squinting, and several weekends, to reduce massive 600-line+ uncommented
procedures into something workable.  somebody out there either had a huge
monitor or a pretty impressive mind's eye.

as for naming "conventions", that probably was what finally drove me into
doing a rewrite, since it was quite difficult to follow different and
intermeshing coding styles.  but naming something "seekright" is, in
my opinion, quite an awful violation.

ewm notes:  [http://pangaea.engin.umich.edu/ewm/]

 - pangaea is back online as a solaris beast, and the ewm site is up
   and running once more.  watch for much new content in the next few days.
   as always, you can see exactly what the current code looks like by taking
   the code tour; once i find a decent c++-to-html translator, there will
   be a pretty html version to work with as well.
 - a beta-1 version should be available by mid october.  the purpose of this
   version will be to test base functionality and shake out any glaring bugs,
   especially on the iccc front.  however, the way-cool ewm floating palettes
   should be part of this release.
 - a beta-2 version is planned for early/mid november.  this will contain the
   personality support code, which will enable a variety of visual and
   behavioral flavors, from beos to mwm.  it will also be the last version
   to support the current module conventions.
 - an ewm<->module ipc spec document will be available for review in mid november.
   watch for more bells and whistles, as well as much simpler module-writing
   requirements; tastes great, less filling...
 - down with crappy mwm hints; ewm hints are coming...

...anon...

--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked].

---

From: [email-masked] (Albrecht Kadlec)
Date: Mon, 30 Sep 96 11:48:41 +0100

>>>>> Omar S Juma writes:

> implementation and optimizing the whole for stability & speed.

O> yes, i did notice, and it's a welcome improvement.  one of the things that
O> has boggled my mind is the complexity of the parsing code, given the
O> simplicity of the supported input language.  i have been toying with the
O> idea of completely rewriting the parsing support in ewm, for several reasons:

O>  - smaller code.  yes, it's true, fvwm is compact, but it could be cut down
O>    in size even more if all those string comparisons, checks, handoffs, and
O>    traversals happened in a nice enclosed code set that would serve
O>    both program and modules.

that's what I was trying to do:
all that page-filling if (mystrcasecmp(action, "TOKEN",5) is a huge waste
of code space (you can use a loop for the parameterless options !!!):

	while (action && (t=GetNextToken(action)))  /* != current syntax */
	{ register char *p; 
          int i=0;
		for (i=0; i < NUMOPTIONS &&
			  !(p=MatchToken(t,optiontable[i].string));
			  i++)
			;

		if (i < NUMOPTIONS)
		{
		    action=p;			/* skip token */
		    /* now do sth with a state and the 
			info provided in optiontable */
		} else
		{ /* check for special (e.g with parameter) options */
			if (p=MatchToken(t,"OPTION_WITH_PARAMETER"))
			{
				action=p; 	/* skip token */
				arg=GetNumericalArg(action);	/* NYI */
			}
		}
	}

This is generic enough to handle all, even the most special cases.
And if all parsing is done this way, it's a GOOD THING (Tm) to speed things
up.
i.e: 

	Asserting sortedness of optiontables -> use binary search with 
	tables.
	Doing the binary search in a routine of it's own (while still 
	supporting arbitrary parsetables: only the first element does have
	to be a string ptr.)
	(again out of time on this, any takers ?)

O>  - parser/language improvements.  any changes to the input language
O>    would be awfully hard to implement with the "distributed" parsing
O>    scheme.  clarifying control over the input file(s) would shorten
O>    the idea-to-implementation time.

well, but it's some kind of object-orientedness, that each object parses
its option all by himself. (I'd keep it this way!!!)

All we have to do is to supply commands which SHOULD be used to make
quoting etc. consistent.

O>  - tokenization.  turning the input file into a token stream would
O>    greatly reduce the amount of immediate-tokenization code currently
O>    required to get the next string, chew the next whitespace, etc.

use parsing tables, GetNextToken (=currently named seekright, due to old
meaning still being used), MatchToken, GetNumericalArgument (NYI),
and it's all neat.
Use of lex/yacc is neat too, but separates parsing completely from the code
and if you implement/change/remove a feature you've to tackle with the lex
& yacc scripts.
Fvwm as it is is highly modifyable, since you don't have to understand ALL
of it to make any change. Changes are very local.

(take me as an example: I changed a whole lot, and still don't know
anything of X in detail, there are great stretches of code, I didn't even
scan yet. I only did grep's to see in which forms mystrcasecmp was used.) 

O>  - those ugly tabs.  using tabs as explicit tokens (at least for 1.xx)
O>    was an evil and homely act of coding.  this was stuff they did
O>    in the 70's with "sophisticated" fortran programs, and does not
O>    belong here.
??? 

O>  - full regexp support.  fvwm 1.xx only supported "*" and "?" for regexp
O>    processing.  [actually, the current ewm already uses regex; encapsulating
O>    string processing in a string class was the key].
neat, but could also be added to GetNextToken, as it's the only way a
source string should be accessed (except for GetNumericalArgument).

> Never dare to change anything unless you've grepped the whole source tree !!!

O> i hear you.  some of those greps have required substantial and delicate
O> regex specification, and even then it's been a nightmare.  going to c++
O> has added to the difficulty, since grepping for x and y assignments can
O> lead to all sorts of unanticipated detours.  however, grepping an entire
O> source tree to learn about code structure should be relegated to the
O> fifth layer of hell.
:-)
but they're a hell of a lot practical, if you need an answer on 
"Is mystrncasecmp ever used as intended, or is it always used to match a
token?"

O> also, and this is not to throw egg in anyone's face, since i've been
O> guilty of same, but there is code there that i can't even begin to understand,
O> and there is not a shred of in-code documentation to explain it.  it's taken
O> a lot of squinting, and several weekends, to reduce massive 600-line+
O> uncommented

O> procedures into something workable.  somebody out there either had a huge
O> monitor or a pretty impressive mind's eye.

I just took a glance on the style parsing (wanted to reuse it for the 
prev/next/none parsing - might still be possible, but I'm out of time)
and just started to reprogram.

O> as for naming "conventions", that probably was what finally drove me into
O> doing a rewrite, since it was quite difficult to follow different and
O> intermeshing coding styles.  but naming something "seekright" is, in
O> my opinion, quite an awful violation.
yes, but 
	it's already been there (some module, I forget which) 
	it's a temporal: if the last reference to GetNextToken is gone,
		someone (I hope chuck) will do a global replace with
		GetNextToken, which is the ideal name.
		I didn't want to use sth similar sounding either, since
		it'd have confused things even more.
		And I didn't want to keep the current counter-intuitive
		arguments & return value.

O>  - down with crappy mwm hints; ewm hints are coming...
hopefully remaining compatible.

I'll have a look at this, when I'm back.
I like C++ it's more natural programming.
But you have to keep a close eye on efficiency:
C++ programs tend to bloat data and code (duplication).
But there're awfully nice features: use "const" consistently, and C++ will
do memcpy's for you, if you give a const object as a non const parameter.

After all, it's not that different to good written C code.
(you can even do object oriented stuff in assembler)

Well, we`ll se which way fvwm goes, and how ewm develops.
I'll re-evaluate, when I'm back.

albrecht
-- 
Night after night		     |	What's done is done
Going round and round my brain	     |	We cannot just write off his final scene
His dream is driving me insane	     |	Take heed of the dream
In the corner of some foreign field  |	Take heed
The gunner sleeps tonight		-- Pink Floyd, "The Gunners Dream"
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked].