Re: [Wesnoth-dev] Interface design of wmllint
Fair enough then. If you don't want to discuss things, I'll just consider it an uneasy truce until you attempt to adjust or restrict WML in a way that I cannot accept. BTW, I think radius upconversion does not cause any cyclical changes, so it may not violate your test. However, some valid 1.3.8 content could also be valid in 1.3.7 except with a different meaning. This is why I disabled the upconversion unless a specific version is passed. -- Sapient _ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] Interface design of wmllint
Patrick Parker <[EMAIL PROTECTED]>: > While I'm perfectly capable of maintaining wmllint, I'd rather not start > adding to my responsibilities. Honestly, I'm surprised you would resort to > such an ultimatum / threat considering it was your foresight to hedge for > this likelihood in the first place. > > I'm conviced by your argument against version stamping, but still opposed to > your second point for reasons stated. The gains just don't outweigh the > disadvantages. I'd rather have a logical discussion about it than to start > making ultimatums, though. As a long-time WML author I had hoped you'd value > my input a bit more. I value your input a lot, actually. But I could see the discussion was going to turn into a pure value conflict with no logical resolution. Neither of us has time for that, so I cut to the chase. Please think of this as showing respect for your time, as well as mine. I meant it that way. -- http://www.catb.org/~esr/";>Eric S. Raymond ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] Interface design of wmllint
> > >2. We have to be equally careful about reusing WML tag names with > > >different enclosed or enclosing tags. > > > > too restrictive IMO > >Not too restrictive, in *my* opinion. We could go down a long rathole >about this, but it's essentially a value and priority judgment. So >I'm not going to argue the point, I'm just going to say what I'll do. > >I think maintainability and preserving NTC is important enough to >justify bending WML a little. I also want to preserve the possibility >of embedding it in the campaign server and having it run completely >out of sight of the invoking user. > >Therefore: wearing my wmllint maintainer hat, I will *not* write a >transformation that violates NTC. Nor will I allow a transformation >that does so to remain part of wmllint's behavior. In fact, it is my >intention to add code that checks for NTC violations and aborts with an >error if it finds one. > >You can believe my priorities are wrong, but as long as I'm maintaining >wmllint that will be the rule. While I'm perfectly capable of maintaining wmllint, I'd rather not start adding to my responsibilities. Honestly, I'm surprised you would resort to such an ultimatum / threat considering it was your foresight to hedge for this likelihood in the first place. I'm conviced by your argument against version stamping, but still opposed to your second point for reasons stated. The gains just don't outweigh the disadvantages. I'd rather have a logical discussion about it than to start making ultimatums, though. As a long-time WML author I had hoped you'd value my input a bit more. -- Sapient _ Don't just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/ ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] Interface design of wmllint
Patrick Parker <[EMAIL PROTECTED]>: > Not quite true... radius upconversion, for example violates NTC. Aarggh. The one transformation I didn't write. Please fix the transformation to have NTC. Otherwise I'll have to make wmllint throw a warning every time it's done, or (see below) disable it entirely. The warning would become painful rather quickly as usage of the feature increases. > >1. We have to be fairly careful about reusing resource file names. > > explain? Suppose the name mappings associated with two different version transitions included both 1.4.1: foo.png -> bar.png 1.4.6: foo.png -> qux.png This could happen if a developer reused the resource file name foo.png not knowing it already had a use before 1.4.1, then *after* his reuse decided to change it. Suddenly what foo.png got transformed to would depend on --oldversion, which would be OK until somebody got the argument wrong. Then you'd have a bug that might be very tough to spot. > >2. We have to be equally careful about reusing WML tag names with > >different enclosed or enclosing tags. > > too restrictive IMO Not too restrictive, in *my* opinion. We could go down a long rathole about this, but it's essentially a value and priority judgment. So I'm not going to argue the point, I'm just going to say what I'll do. I think maintainability and preserving NTC is important enough to justify bending WML a little. I also want to preserve the possibility of embedding it in the campaign server and having it run completely out of sight of the invoking user. Therefore: wearing my wmllint maintainer hat, I will *not* write a transformation that violates NTC. Nor will I allow a transformation that does so to remain part of wmllint's behavior. In fact, it is my intention to add code that checks for NTC violations and aborts with an error if it finds one. You can believe my priorities are wrong, but as long as I'm maintaining wmllint that will be the rule. -- http://www.catb.org/~esr/";>Eric S. Raymond ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] Interface design of wmllint
Due to my typing difficulty ATM, I can't respond as verbosely as I'd like,
but I do want to weigh in on the shape of WML evolution, since it is an area
of great interest and concern.
>There are still good use cases for version numbering. Sometimes it's
>not possible to use a strategy like PNG's with neatly self-describing
>content. *But WML is not one of these cases*. WML syntax, like PNG's
>packet structure, guarantees that a WML file will be parseable even if
>it has unknown tags and/or attributes in it.
WML version is not self-evident from content, nor should we force it to be.
WML is a work in progress. While the basic parsing rules and preprocessing
rules haven't changed much over time, the conclusion that it is neatly
self-describing does not follow.
>A version number would just be a distraction. It would violate what
>database designers call the SPOT ("Single Point of Truth") rule,
>sometimes known in coding circles as the DRY (Don't Repeat Yourself)
>rule.
Here is where I agree with you. After reading your argument, I am convinced
that a version stamp would violate SPOT. Specifying version in countless
files would contradict the version that can be specified on the commandline,
which --oldversion. After weighing all the possibilities, requiring wmllint
users to specify which version they are converting from seems the safest and
most logical choice.
>I wrote wmllint, so I know that the set of transformations in it has
>the following property: *no transformation ever produces on output
>a text pattern that is any of the other transformations' inputs*.
>I'll call this the "no-transitive-chains" propety, or NTC for short.
Not quite true... radius upconversion, for example violates NTC. As will
doubtless many other future transformations, unless we go the 'warn' route,
which I think isn't that useful. Remember, WML is a work in progress. Some
bad design choices have been made in the past, and we would like to
eliminate those when possible and when relatively painless.
>Among other things, this means (in
>principle) that you could embed wmllint in the campaigns server and
>have it automatically lift submitted UMC.
Automatic content checking is a good idea, but automatic version guessing +
content checking may prove too restrictive.
>Adaptive code that automatically preserves
>the invariants you care about is better than switches that can
>break things.
>
There are already safeguards against that (diff and .bak files), and any
user smart enough to know how to run the tool in the first place is smart
enough to know what version number he is converting from.
I agree that switches for each individual transformation (as proposed by
zookeeper) are a bad idea (due to information overload).
>1. We have to be fairly careful about reusing resource file names.
explain?
>2. We have to be equally careful about reusing WML tag names with
>different enclosed or enclosing tags.
too restrictive IMO
>For example, the syntax transformation boucman has requested in
>FR #9952 could violate NTC by the way it changes the use of the
>[animation] tag. The new block will probably have to be called
>[effect_anim] or something else, otherwise I think this transformation
>could trigger on its own output.
Changing WML tags for this reason alone is bad, very bad, and I am adamantly
opposed to it.
I'm coming from the perspective of someone who was a WML author for a long
time before being a developer.
Memorization of WML tags represents a sizable human investment, and wmllint
is made to help humans.
Also, WML tags and keys and structures are designed to be as easy and
intuitive as possible.
By changing them, either you must assert that the original design choice was
flawed (in which case, the degree of flaw must be carefully weighed), or you
are admittedly degrading it.
--
Sapient
_
Express yourself instantly with MSN Messenger! Download today it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
___
Wesnoth-dev mailing list
Wesnoth-dev@gna.org
https://mail.gna.org/listinfo/wesnoth-dev
[Wesnoth-dev] Interface design of wmllint
There have been a couple of suggestions on IRC that the interface
design of wmllint should change. Specifically, it has been suggested
that:
(1) WML files should be version-stamped, and/or
(2) wmllint transformations should be explicitly invoked by
command-line switches.
I will now explain why I think both proposals are mistaken.
First, by way of explanatory analogy, a brief foray into graphics
formats and what PNG taught me. When I first encountered PNG back in
the 1990s, I wad a little disturbed that it has no version number in
its header. "What", I asked myself "do you do when the format
changes? Are old readers screwed?"
It took me some study to understand what the PNG designers had done.
PNG is written as a series of chunks. Each chunk is in the same
packet format and has a chunk ID. To change the format, you add
a new chunk type in the same format as the existing ones, and possibly
stop generating one or more of the old chunk types.
As long as the packet format itself is stable, old readers cope as well
as is possible because (by design) they ignore chunk types they don't
know how to process. (Maybe they throw a warning.)
Studying this design persuaded me that file format version numbers are a bad
thing for at least two reasons.
(1) They're not fine-grained enough. They tell you something
(possibly something incompatible) has changed, but they don't
tell you *what*.
(2) When a version number gets out of sync with the reality it's
describing, hilarity ensues. PNG neatly avoids even the possibility
of this happening -- you never look at a version number, you run
through the file's chunk structure and look at the truth.
There are still good use cases for version numbering. Sometimes it's
not possible to use a strategy like PNG's with neatly self-describing
content. *But WML is not one of these cases*. WML syntax, like PNG's
packet structure, guarantees that a WML file will be parseable even if
it has unknown tags and/or attributes in it.
This is why I think an explicit version stamp in WML would be a
mistake. Better for parsers (and wmllint) to do as PNG does;
rely on the low-level syntactic regularity of the format, look at the
truth, and throw an exception if the truth includes tags you don't
recognize.
A version number would just be a distraction. It would violate what
database designers call the SPOT ("Single Point of Truth") rule,
sometimes known in coding circles as the DRY (Don't Repeat Yourself)
rule.
Now, about invoking transformations explicitly...
I wrote wmllint, so I know that the set of transformations in it has
the following property: *no transformation ever produces on output
a text pattern that is any of the other transformations' inputs*.
I'll call this the "no-transitive-chains" propety, or NTC for short.
Because NTC is true, the --oldversion option is currently useless.
(I included it as a hedge against NTC ever being violated.) You just
run wmllint on any WML back to the beginning of time and it updates
the WML to the current version. Among other things, this means (in
principle) that you could embed wmllint in the campaigns server and
have it automatically lift submitted UMC.
As long as NTC is true, there would be no point in invoking wmllint
transformations separately. And what you can't invoke separately,
*you can't get wrong*. Adaptive code that automatically preserves
the invariants you care about is better than switches that can
break things.
So. The effort that would go into choosing and implementing
transformation switches would be better spent ensuring that NTC
is never violated. This has implications in at least three areas:
1. We have to be fairly careful about reusing resource file names.
2. We have to be equally careful about reusing WML tag names with
different enclosed or enclosing tags.
3. When Mordante's map-border stuff gets done, we'll need in the
final design an unambiguous way for wmllint to know if a map
already has a border.
For example, the syntax transformation boucman has requested in
FR #9952 could violate NTC by the way it changes the use of the
[animation] tag. The new block will probably have to be called
[effect_anim] or something else, otherwise I think this transformation
could trigger on its own output.
Up to now the NTC invariant has been maintained in my head. I think
there is at least one thing that could be done to check it; wmllint
can look for NTC violations in its tables for resource-file renaming at
its startup time. I'll look into coding that.
--
http://www.catb.org/~esr/";>Eric S. Raymond
When only cops have guns, it's called a "police state".
-- Claire Wolfe, "101 Things To Do Until The Revolution"
___
Wesnoth-dev mailing list
Wesnoth-dev@gna.org
https://mail.gna.org/listinfo/wesnoth-dev
