CML2 1.3.1, aka "I stick my neck out a mile..."

CML2 1.3.1, aka "I stick my neck out a mile..."

[Eric S. Raymond]

Release 1.3.1: Fri Apr 27 19:02:31 EDT 2001
	* kxref.py can now replace the unmaintained checkhelp.pl,  
	  checkconfig.pl, and checkincludes.pl scripts.

I'm going to stick my neck out a mile and say that I think this is a
stable release.  Doing so, of course, is in reality a clever plan which
ensures that at least three embarrassing bugs will be discovered within
the next 24 hours...

Seriously, I am now out of stuff to do on the CML2 code itself.  The
code now seems to be up to acceptable speed even on slow machines, the
UI feature requests have petered out, and this release seems to be
feature-complete with respect to everything that can be done before
the 2.5 cutover.

There is one 1.3.0 bug report pending from jeff millar, but I have 
not been able to reproduce it with 1.3.1.  I will, of course, continue
to process CML2 bug reports and rulesfile fixes.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

"The bearing of arms is the essential medium through which the
individual asserts both his social power and his participation in
politics as a responsible moral being..."
        -- J.G.A. Pocock, describing the beliefs of the founders of the U.S.

Re: CML2 1.3.1, aka "I stick my neck out a mile..."

[John Stoffel]

Eric> I'm going to stick my neck out a mile and say that I think this
Eric> is a stable release.  Doing so, of course, is in reality a
Eric> clever plan which ensures that at least three embarrassing bugs
Eric> will be discovered within the next 24 hours...

I've just downloaded and installed cml-1.3.2 on my Dual processor PPro
200mhz, 128mb system.  Unfortunately, I set it up into a 2.4.4-pre7 +
patches tree, and it's now giving me the following when I do a 'make
config':

  [root@jfs linux]# make config
  rm -f include/asm
  ( cd include ; ln -sf asm-i386 asm)
  python -O scripts/cmlconfigure.py -DX86 -B 2.4.4-pre7 -W -i config.out
  rules.out
  ISA=y (deduced from X86)
  Side effects from config.out:
  NETDEVICES=m (deduced from ATALK)
  SOUND_OSS=m (deduced from SOUND_VIA82CXXX)
  SOUND_OSS=y (deduced from SOUND_YMFPCI_LEGACY)
  SOUND=y (deduced from SOUND_OSS)
  This configuration violates the following constraints:
  '((X86 and SMP) implies (RTC != n))'
  python -O scripts/configtrans.py -h include/linux/autoconf.h -s
  .config config.out


Which is a real PITA because now I have to edit my .config file to
have:

   CONFIG_RTC=y

in there.  Now when I do a 'make config' it comes up properly.  I
think this is a poor interface setup.  It should either

a.  Give more info on what to correct, such as the configuration line
    to edit and in which file.

b.  Print a warning, startup the configuration tool and put you at the
    problematic line, with the help section showing.  Or highlight this
    choice in some manner as being wrong and showing you how to ffix it.

This is a minor, but annoying problem and should be fixed ASAP before
public use.  

In general, I like what I do see, it's more interface issues that I
have so far. 

Now for some comments on the X interface.  

At the top-level, most stuff cannot be selected on/off, but you can
enter it.  But you also do have some y/m/n choices which seems wierd
and out of place.  For example, "SCSI disk support" is a menu, but
"HAMRADIO: Amateur Radio support (NEW)" is a y/n choice.  It would
make more sense to me to have it down a level, with a simple entry to
"Hamradio support".  Once you go into that level, you would be asked
to have it turned on/off there.

This would remove some of the clutter at the top level.  

As a contrast, the USB entry doesn't ask Y/N for USB support, and when
I enter the directory, it has all these options listed.  I thought
that CML would suppres stuff (children, drivers, etc) if I didn't have
the top level selected.  In this case, I can't turn off USB support in
any manner, so I see all the children when I could care less about
them.

Also, the buttons on the right hand side for HELP, are wider when they
have text in them, but slightly narrower when they are blank.  They
should be the same width no matter what.  It looks ragged and ugly.

I don't like how it keeps changing the window size whenever you go
into a sub-level.  It should not re-size the main window at all, it
should just update the contents and give scroll bars if needed for
both up/down scolling and side to side.  Once the user has setup their
prefs, the CML code shouldn't keep it jumping all over the screen.

John

   John Stoffel - Senior Unix Systems Administrator - Lucent Technologies
	 stoffel@lucent.com - http://www.lucent.com - 978-952-7548

Re: CML2 1.3.1, aka "I stick my neck out a mile..."

[Eric S. Raymond]

John Stoffel <stoffel@casc.com>:
> Which is a real PITA because now I have to edit my .config file to
> have:
> 
>    CONFIG_RTC=y

The correct fix for this PITA is for Linus not to ship a broken defconfig.

>               Now when I do a 'make config' it comes up properly.  I
> think this is a poor interface setup.  It should either
> 
> a.  Give more info on what to correct, such as the configuration line
>     to edit and in which file.
> 
> b.  Print a warning, startup the configuration tool and put you at the
>     problematic line, with the help section showing.  Or highlight this
>     choice in some manner as being wrong and showing you how to ffix it.
> 
> This is a minor, but annoying problem and should be fixed ASAP before
> public use.  

I hear you.  The problem is that "what's wrong" is not as well-defined
as one might like.  In this case the error could be in the setting of
X86, SMP, or RTC.  CML2 has no way to know which of these is mis-set, so
it can't know which one to pop up..
 
> At the top-level, most stuff cannot be selected on/off, but you can
> enter it.  But you also do have some y/m/n choices which seems wierd
> and out of place.  For example, "SCSI disk support" is a menu, but
> "HAMRADIO: Amateur Radio support (NEW)" is a y/n choice.  It would
> make more sense to me to have it down a level, with a simple entry to
> "Hamradio support".  Once you go into that level, you would be asked
> to have it turned on/off there.
> 
> This would remove some of the clutter at the top level.  
> 
> As a contrast, the USB entry doesn't ask Y/N for USB support, and when
> I enter the directory, it has all these options listed.  I thought
> that CML would suppres stuff (children, drivers, etc) if I didn't have
> the top level selected.  In this case, I can't turn off USB support in
> any manner, so I see all the children when I could care less about
> them.

USB and SCSI are both enabled/disabled in the system buses menu.  The
apparent confusion 

> Also, the buttons on the right hand side for HELP, are wider when they
> have text in them, but slightly narrower when they are blank.  They
> should be the same width no matter what.  It looks ragged and ugly.

I know.  Sadly, I couldn't find a way to coerce Tcl into doing this right.

> I don't like how it keeps changing the window size whenever you go
> into a sub-level.  It should not re-size the main window at all, it
> should just update the contents and give scroll bars if needed for
> both up/down scolling and side to side.  Once the user has setup their
> prefs, the CML code shouldn't keep it jumping all over the screen.

That's on my to-do list.  It's low-priority, though, since I figure 
most people will use menuconfig.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

"Today, we need a nation of Minutemen, citizens who are not only prepared to
take arms, but citizens who regard the preservation of freedom as the basic
purpose of their daily life and who are willing to consciously work and
sacrifice for that freedom."
	-- John F. Kennedy

Re: CML2 1.3.1, aka "I stick my neck out a mile..."

[Eric S. Raymond]

John Stoffel <stoffel@casc.com>:
> Before on startup it would give:
> 
>     [root@jfs linux]# make config
>     rm -f include/asm
>     ( cd include ; ln -sf asm-i386 asm)
>     python -O scripts/cmlconfigure.py -DX86 -B 2.4.4-pre7 -W -i config.out
>     rules.out
>     ISA=y (deduced from X86)
>     Side effects from config.out:
>     NETDEVICES=m (deduced from ATALK)
>     SOUND_OSS=m (deduced from SOUND_VIA82CXXX)
>     SOUND_OSS=y (deduced from SOUND_YMFPCI_LEGACY)
>     SOUND=y (deduced from SOUND_OSS)
>     python -O scripts/configtrans.py -h include/linux/autoconf.h -s
>     .config config.out
> 
> 
> So I poked around, found the RTC setting, read the help and now I
> understand why I should have had it enabled all along.  No problem.
> So saved my changes and exited.  
> 
> I then restarted, and it came up properly, but I'm now getting the
> following output:
> 
>     [root@jfs linux]# make config
>     rm -f include/asm
>     ( cd include ; ln -sf asm-i386 asm)
>     python -O scripts/cmlconfigure.py -DX86 -B 2.4.4-pre7 -W -i config.out
>     rules.out
>     ISA=y (deduced from X86)
> 
> 
> Notice that it's still setting the ISA=y flag, but not the rest it was
> complaining about.  I think it should have either updated this setting
> by default for the ISA bus, or warned on exit that it still needed to
> be set.
> 
> I think this is a true bug somewhere.

Nope, it's a benign side-effect of the order of evaluation of command-line
switches.  Here's what's happening:

1. X86=y is being set and frozen.
2. ISA=y is deduced from X86
3. config.out is read in.  

In step 3, you don't see any side effects from config.out because they
were calculated last time and wruitten into the saved configuration. 

You still see the ISA=y message because your config.out has not yet been
read in at the time that side effect is computed.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

"Among the many misdeeds of British rule in India, history will look
upon the Act depriving a whole nation of arms as the blackest."
        -- Mohandas Ghandhi, An Autobiography, pg 446

Re: [kbuild-devel] Re: CML2 1.3.1, aka "I stick my neck out a mile..."

[Eric S. Raymond]

Eric S. Raymond <esr@thyrsus.com>:
> USB and SCSI are both enabled/disabled in the system buses menu.  The
> apparent confusion 

Sorry, I typoed...

USB and SCSI are both enabled/disabled in the system buses menu.  The
apparent confusion happens because of their defaults.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Society in every state is a blessing, but government even in its best
state is but a necessary evil; in its worst state an intolerable one;
for when we suffer, or are exposed to the same miseries *by a
government*, which we might expect in a country *without government*,
our calamities is heightened by reflecting that we furnish the means
by which we suffer."
	-- Thomas Paine

Re: CML2 1.3.1, aka "I stick my neck out a mile..."

[Anton Altaparmakov]

At 23:35 29/04/2001, Eric S. Raymond wrote:
>John Stoffel <stoffel@casc.com>:
> > Also, the buttons on the right hand side for HELP, are wider when they
> > have text in them, but slightly narrower when they are blank.  They
> > should be the same width no matter what.  It looks ragged and ugly.
>
>I know.  Sadly, I couldn't find a way to coerce Tcl into doing this right.

I don't know about whether this is possible with Tcl but have you tried A) 
invisible text and/or B) white space character text (e.g. one or more 
spaces)? That's the kind of thing I usually try in this situation... Just 
an idea...

Best regards,

         Anton


-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Linux NTFS Maintainer / WWW: http://sourceforge.net/projects/linux-ntfs/
ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/

Re: CML2 1.3.1, aka "I stick my neck out a mile..."

[Eric S. Raymond]

Anton Altaparmakov <aia21@cam.ac.uk>:
> I don't know about whether this is possible with Tcl but have you tried A) 
> invisible text and/or B) white space character text (e.g. one or more 
> spaces)? That's the kind of thing I usually try in this situation... Just 
> an idea...

I tried whitespace, but the default Tkinter font isn't fixed-width.  How
do you do invisible text?
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

..every Man has a Property in his own Person. This no Body has any
Right to but himself.  The Labour of his Body, and the Work of his
Hands, we may say, are properly his. .... The great and chief end
therefore, of Mens uniting into Commonwealths, and putting themselves
under Government, is the Preservation of their Property.
	-- John Locke, "A Treatise Concerning Civil Government"

Re: [kbuild-devel] Re: CML2 1.3.1, aka "I stick my neck out a mile..."

[John Cowan]

Eric S. Raymond scripsit:

> I tried whitespace, but the default Tkinter font isn't fixed-width.  How
> do you do invisible text?

Set the background color and the foreground color to be the same.

-- 
John Cowan                                   cowan@ccil.org
One art/there is/no less/no more/All things/to do/with sparks/galore
	--Douglas Hofstadter

Re: CML2 1.3.1, aka "I stick my neck out a mile..."

[Alexander Viro]

On Sun, 29 Apr 2001, Eric S. Raymond quoted:

> Anton Altaparmakov <aia21@cam.ac.uk>:
> > I don't know about whether this is possible with Tcl but have you tried A) 
> > invisible text and/or B) white space character text (e.g. one or more 
> > spaces)? That's the kind of thing I usually try in this situation... Just 
> > an idea...

wrote

> I tried whitespace, but the default Tkinter font isn't fixed-width.  How
> do you do invisible text?

and sigged
> -- 
> 		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
> 
> ..every Man has a Property in his own Person. This no Body has any
> Right to but himself.  The Labour of his Body, and the Work of his
> Hands, we may say, are properly his. .... The great and chief end
> therefore, of Mens uniting into Commonwealths, and putting themselves
> under Government, is the Preservation of their Property.
> 	-- John Locke, "A Treatise Concerning Civil Government"

Eric, it's getting tiresome.  Kindly learn what the fsck McQ is, OK?

/me abstains from attaching Kibo's .sig - 1Mb of PDF is unfortunately
over the top for l-k...

Re: CML2 1.3.1, aka "I stick my neck out a mile..."

[volodya]

On Sun, 29 Apr 2001, Eric S. Raymond wrote:

> Anton Altaparmakov <aia21@cam.ac.uk>:
> > I don't know about whether this is possible with Tcl but have you tried A) 
> > invisible text and/or B) white space character text (e.g. one or more 
> > spaces)? That's the kind of thing I usually try in this situation... Just 
> > an idea...
> 
> I tried whitespace, but the default Tkinter font isn't fixed-width.  How
> do you do invisible text?

Make it the same color as the background.

                        Vladimir Dergachev


> -- 
> 		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
> 
> ..every Man has a Property in his own Person. This no Body has any
> Right to but himself.  The Labour of his Body, and the Work of his
> Hands, we may say, are properly his. .... The great and chief end
> therefore, of Mens uniting into Commonwealths, and putting themselves
> under Government, is the Preservation of their Property.
> 	-- John Locke, "A Treatise Concerning Civil Government"
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Re: CML2 1.3.1, aka "I stick my neck out a mile..."

[David Emory Watson]

Al,

I really don't know why you must complain about Eric's sig.  I
personally like them just as they are, but thats strictly besides the
point.  IMHO, it is just not very intresting to hear you say:

> Eric, it's getting tiresome.  Kindly learn what the fsck McQ is, OK?

Especially after all of the brilliant things I have heard you say.  It
really seems like a childish move.  Let the man have his freakin sig for
crying out loud!!  At any rate, I'm just throwin' in my 2 cents.  OK,
now can we get back on  topic?  Good.

I hope no offense is taken and no reply necessary..  But if I mistaken,
then I look forward to your, in all probablity, entertaining reply
(maybe off this list though).  :)

Regards,
David

On 29 Apr 2001 22:24:58 -0400, Alexander Viro wrote:
> 
> 
> On Sun, 29 Apr 2001, Eric S. Raymond quoted:
> 
> > Anton Altaparmakov <aia21@cam.ac.uk>:
> > > I don't know about whether this is possible with Tcl but have you tried A) 
> > > invisible text and/or B) white space character text (e.g. one or more 
> > > spaces)? That's the kind of thing I usually try in this situation... Just 
> > > an idea...
> 
> wrote
> 
> > I tried whitespace, but the default Tkinter font isn't fixed-width.  How
> > do you do invisible text?
> 
> and sigged
> > -- 
> >             <a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
> > 
> > ..every Man has a Property in his own Person. This no Body has any
> > Right to but himself.  The Labour of his Body, and the Work of his
> > Hands, we may say, are properly his. .... The great and chief end
> > therefore, of Mens uniting into Commonwealths, and putting themselves
> > under Government, is the Preservation of their Property.
> >     -- John Locke, "A Treatise Concerning Civil Government"
> 
> Eric, it's getting tiresome.  Kindly learn what the fsck McQ is, OK?
> 
> /me abstains from attaching Kibo's .sig - 1Mb of PDF is unfortunately
> over the top for l-k...
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: CML2 1.3.1, aka "I stick my neck out a mile..."

[Alexander Viro]

On Sun, 29 Apr 2001, David Emory Watson wrote:

> Al,
> 
> I really don't know why you must complain about Eric's sig.  I

Because violating the common standards is a bad thing?  You know, like
4-lines limit on sig size...  And no, I don't care how many AOL and
WebTV lusers do the same thing. 

Re: CML2 1.3.1, aka "I stick my neck out a mile..."

[David Emory Watson]

Oh.  Well in hindsight, I guess your are right.  After all I wouldn't
want to be a luser, much less associated with AOL.  Gosh  I never
realized.  Maybe I just didn't read the right standards manual when I
started using the internet.  Where did you learn all of this?  No,
nevermind I don't care.  I'm sorry for contributing to this silly flame
war.

I think my points been made.  Sorry Al, but this is a bit too silly....

On 30 Apr 2001 01:50:49 -0400, Alexander Viro wrote:
> 
> 
> On Sun, 29 Apr 2001, David Emory Watson wrote:
> 
> > Al,
> > 
> > I really don't know why you must complain about Eric's sig.  I
> 
> Because violating the common standards is a bad thing?  You know, like
> 4-lines limit on sig size...  And no, I don't care how many AOL and
> WebTV lusers do the same thing. 
> 

Re: CML2 1.3.1, aka "I stick my neck out a mile..."

[Eric S. Raymond]

David Emory Watson <demoryw@pacbell.net>:
> Oh.  Well in hindsight, I guess your are right.  After all I wouldn't
> want to be a luser, much less associated with AOL.  Gosh  I never
> realized.  Maybe I just didn't read the right standards manual when I
> started using the internet.  Where did you learn all of this?  No,
> nevermind I don't care.  I'm sorry for contributing to this silly flame
> war.

Time for me to put on my hacker-folklorist hat...

Actually, Al is sort of half-right here.  There used to be a 4-lines-or-less
convention on USENET, back in the days when bandwidth was expensive.  I
adhered to it then, because it mattered.

Nowadays it doesn't -- at least not at that level.  Huge sigs with
embedded ASCII graphics and the like are still best avoided, but merely
because they're tasteless and distracting.

I don't think I've heard anyone invoke the 4-line rule since about
1992, though.  I didn't start generating short random quotes into my sig
until about 1996, well after the "standard" was effectively dead.

Despite the demise of the 4-line standard, I have a pretty definite
impression that the average size of sigs actually dropped in the 1990s.
The main thing that formerly inflated a lot of them was the need to
list multiple bang-path addresses and other forms of contact info.
Reliable @-addressing pretty much eliminated that pressure.

Even back in its day this "rule" was frequently abused as a socially
acceptable way to attack people whose opinions or style one disliked.
This is doubtless one reason it failed to survive the bandwidth boom.

Hmmm.  Maybe this should be a Jargon File entry...
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

The politician attempts to remedy the evil by increasing the very thing
that caused the evil in the first place: legal plunder.
	-- Frederick Bastiat

Re: CML2 1.3.1, aka "I stick my neck out a mile..."

[volodya]

> 
> Eric, it's getting tiresome.  Kindly learn what the fsck McQ is, OK?

 Just out of curiousity - what is McQ ?

                              Vladimir Dergachev

PS And no, I am very sure there is no such thing in Star Trek.

> 
> /me abstains from attaching Kibo's .sig - 1Mb of PDF is unfortunately
> over the top for l-k...
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

[OT] Re: CML2 1.3.1, aka "I stick my neck out a mile..."

[Jeff Garzik]

"Eric S. Raymond" wrote:
> Actually, Al is sort of half-right here.  There used to be a 4-lines-or-less
> convention on USENET, back in the days when bandwidth was expensive.  I
> adhered to it then, because it mattered.
> 
> Nowadays it doesn't -- at least not at that level.  Huge sigs with
> embedded ASCII graphics and the like are still best avoided, but merely
> because they're tasteless and distracting.
> 
> I don't think I've heard anyone invoke the 4-line rule since about
> 1992, though.  I didn't start generating short random quotes into my sig
> until about 1996, well after the "standard" was effectively dead.

The 4-line rule is still being invoked all the time, and written into
college netiquette guides for students, things like that.  The standard
has never been "effectively dead" except in the sense that it always has
been:  clueless AOLers ignore it, clueful netiquette followers follow
it.

Read item #15:
http://www.xs4all.nl/~js/gnksa/gnksa.txt


> Despite the demise of the 4-line standard, I have a pretty definite
> impression that the average size of sigs actually dropped in the 1990s.
> The main thing that formerly inflated a lot of them was the need to
> list multiple bang-path addresses and other forms of contact info.
> Reliable @-addressing pretty much eliminated that pressure.
> 
> Even back in its day this "rule" was frequently abused as a socially
> acceptable way to attack people whose opinions or style one disliked.

frequently abused, yes.  socially acceptable?  doubtful.

-- 
Jeff Garzik      | Game called on account of naked chick
Building 1024    |
MandrakeSoft     |

Re: CML2 1.3.1, aka "I stick my neck out a mile..."

[Alexander Viro]

On Mon, 30 Apr 2001, Eric S. Raymond wrote:

> I don't think I've heard anyone invoke the 4-line rule since about
> 1992, though.  I didn't start generating short random quotes into my sig
> until about 1996, well after the "standard" was effectively dead.

<wry> We hang in different parts of USENET </wry>

Last time I've seen it invoked was probably a couple of weeks ago.
 
> Even back in its day this "rule" was frequently abused as a socially
> acceptable way to attack people whose opinions or style one disliked.
> This is doubtless one reason it failed to survive the bandwidth boom.
> 
> Hmmm.  Maybe this should be a Jargon File entry...

ISTR that you had an entry on AFW - it would more or less fit there.

Stuff generating random quotes (aka. sigmonsters) is pretty common,
indeed, but fitting said quotes into McQ is a part of fun. I suspect
that strong dislike to excessive sigs goes back to the beginning of
Endless September - like it or not, "why would I give a fuck for
conventions" attitude correlates with particulary obnoxious breed
of lusers. Same as with HTML postings, or quoted-printable crap.

Seeing that from folks who should know better... Ugh.

And no, I really don't care for the contents - if anything, I find
both sides of holy war around g*n* c**t**l moderately amusing, but
for all I care it could be 6-7 lines of PARRY vs. ELIZA dialog (or
vi macros, or just a line noise).

BTW, there's one more jarring thing about use of sigs on l-k - you are
getting _two_ sigs that way (look at the unsubscribe instructions).

Re: CML2 1.3.1, aka "I stick my neck out a mile..."

[Alexander Viro]

On Mon, 30 Apr 2001 volodya@mindspring.com wrote:

> > 
> > Eric, it's getting tiresome.  Kindly learn what the fsck McQ is, OK?
> 
>  Just out of curiousity - what is McQ ?
> 
>                               Vladimir Dergachev
> 
> PS And no, I am very sure there is no such thing in Star Trek.

McQ: (from George McQuary) Conventional limit on signature size.

>From AFW FAQ:

Q11. What is the McQuary limit?
A11. "There once was a man from Nantucket,
     who lost his .sig in a bucket.
     Five lines was too long,
     columns 80 just strong,
     so he didn't know where to tuck it."
A11. The limit on signature size:  "4x80".

Re: CML2 1.3.1, aka "I stick my neck out a mile..."

[Eric S. Raymond]

Alexander Viro <viro@math.psu.edu>:
> >From AFW FAQ:
> 
> Q11. What is the McQuary limit?
> A11. "There once was a man from Nantucket,
>      who lost his .sig in a bucket.
>      Five lines was too long,
>      columns 80 just strong,
>      so he didn't know where to tuck it."
> A11. The limit on signature size:  "4x80".

I just added the following to the Jargon File masters:

@hd{McQuary limit} @p{} 4 lines of at most 80 characters each,
   sometimes still cited on Usenet as the maximum acceptable size of a
   @es{sig block}.  Before the great bandwidth explosion of the early
   1990s, long sigs actually cost people running Usenet servers
   significant amounts of money.  Nowadays social pressure against
   long sigs is intended to avoid waste of human attention rather
   than machine bandwidth.  Accordingly, the McQuary limit should 
   be considered a rule of thumb rather than a hard limit; it's
   best to avoid sigs that are large, repetitive, and distracting.
   See also @es{warlording}.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

What, then is law [government]? It is the collective organization of
the individual right to lawful defense."
	-- Frederic Bastiat, "The Law"

Re: CML2 1.3.1, aka "I stick my neck out a mile..."

[Anton Altaparmakov]

At 02:41 30/04/2001, Eric S. Raymond wrote:
>Anton Altaparmakov <aia21@cam.ac.uk>:
> > I don't know about whether this is possible with Tcl but have you tried A)
> > invisible text and/or B) white space character text (e.g. one or more
> > spaces)? That's the kind of thing I usually try in this situation... Just
> > an idea...
>
>I tried whitespace, but the default Tkinter font isn't fixed-width.  How
>do you do invisible text?

Text colour = background colour -> invisible

Anton


-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Linux NTFS Maintainer / WWW: http://sourceforge.net/projects/linux-ntfs/
ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/

Re: CML2 1.3.1, aka "I stick my neck out a mile..."

[Eric S. Raymond]

Anton Altaparmakov <aia21@cam.ac.uk>:
> >I tried whitespace, but the default Tkinter font isn't fixed-width.  How
> >do you do invisible text?
> 
> Text colour = background colour -> invisible

Well, duh.  Unfortunately, it doesn't seem to have occured to the dozen or
so people who suggested this that:

(a) Background color can vary depending on how Tk's X resources are set, and

(b) Tk doesn't give me, AFAIK, any way to query either that background color
    or those resources.

Fer cripes' sake.  If it were that easy I'd have *done* it already, people!

Anyway my attempts to set a foreground color on an inactive button widget 
failed.  I don't know why.  Tk is full of weird little corners like that.

What I've done is just disabled inactive help buttons without trying to
hack the text or color. That makes them all the same width, though the 
legend "Help" does show up in gray on the inacive ones.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

"The state calls its own violence `law', but that of the individual `crime'"
	-- Max Stirner

Re: CML2 1.3.1, aka "I stick my neck out a mile..."

[Anton Altaparmakov]

At 09:03 30/04/2001, Eric S. Raymond wrote:
>Anton Altaparmakov <aia21@cam.ac.uk>:
> > >I tried whitespace, but the default Tkinter font isn't fixed-width.  How
> > >do you do invisible text?
> >
> > Text colour = background colour -> invisible
>
>Well, duh.  Unfortunately, it doesn't seem to have occured to the dozen or
>so people who suggested this that:
>
>(a) Background color can vary depending on how Tk's X resources are set, and
>
>(b) Tk doesn't give me, AFAIK, any way to query either that background color
>     or those resources.

Well, that's a problem with Tk. I did say I know nothing about Tcl and this 
extends to Tcl/Tk...

>Fer cripes' sake.  If it were that easy I'd have *done* it already, people!

Well, you asked a generic question and not one of "how do you do this in 
Tcl/Tk?" so you got a generic reply...

>Anyway my attempts to set a foreground color on an inactive button widget
>failed.  I don't know why.  Tk is full of weird little corners like that.
>
>What I've done is just disabled inactive help buttons without trying to
>hack the text or color. That makes them all the same width, though the
>legend "Help" does show up in gray on the inacive ones.

Cool.

Best regards,

Anton


-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Linux NTFS Maintainer / WWW: http://sourceforge.net/projects/linux-ntfs/
ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/

[Moving rapidly offtopic] Re: CML2 1.3.1, aka "I stick my neck out a mile..."

[Henning P. Schmiedehausen]

"Eric S. Raymond" <esr@thyrsus.com> writes:

>@hd{McQuary limit} @p{} 4 lines of at most 80 characters each,
>   sometimes still cited on Usenet as the maximum acceptable size of a
>   @es{sig block}.  Before the great bandwidth explosion of the early
>   1990s, long sigs actually cost people running Usenet servers
>   significant amounts of money.  Nowadays social pressure against
>   long sigs is intended to avoid waste of human attention rather
>   than machine bandwidth.  Accordingly, the McQuary limit should 
>   be considered a rule of thumb rather than a hard limit; it's
>   best to avoid sigs that are large, repetitive, and distracting.
>   See also @es{warlording}.

Don't tell me how to live my life
Don't tell me what to do
Repression is always brought about
By people with politics
and attitudes like you

 -- Anne Clark, The power game, 1982


	Regards
		Henning



-- 
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen       -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH     hps@intermeta.de

Am Schwabachgrund 22  Fon.: 09131 / 50654-0   info@intermeta.de
D-91054 Buckenhof     Fax.: 09131 / 50654-20   

Re: [kbuild-devel] Re: CML2 1.3.1, aka "I stick my neck out a mile..."

[John Cowan]

Eric S. Raymond scripsit:

> I don't think I've heard anyone invoke the 4-line rule since about
> 1992, though.  I didn't start generating short random quotes into my sig
> until about 1996, well after the "standard" was effectively dead.

I have always obeyed it.

-- 
John Cowan                                   cowan@ccil.org
One art/there is/no less/no more/All things/to do/with sparks/galore
	--Douglas Hofstadter

Re: CML2 1.3.1, aka "I stick my neck out a mile..."

[David Woodhouse]

demoryw@pacbell.net said:
>   Maybe I just didn't read the right standards manual when I started
> using the internet.

Then read it now. http://www.ietf.org/rfc/rfc1855.txt

--
dwmw2

Re: CML2 1.3.1, aka "I stick my neck out a mile..."

[David Woodhouse]

esr@thyrsus.com said:
>  I don't think I've heard anyone invoke the 4-line rule since about
> 1992, though.  I didn't start generating short random quotes into my
> sig until about 1996, well after the "standard" was effectively dead. 

RFC 1855 is dated October 1995.

 - If you include a signature keep it short.  Rule of thumb
      is no longer than 4 lines.  Remember that many people pay for
      connectivity by the minute, and the longer your message is,
      the more they pay.


--
dwmw2

Re: CML2 1.3.1, aka "I stick my neck out a mile..."

[Kai Henningsen]

viro@math.psu.edu (Alexander Viro)  wrote on 30.04.01 in <Pine.GSO.4.21.0104300255530.4113-100000@weyl.math.psu.edu>:

> On Mon, 30 Apr 2001, Eric S. Raymond wrote:
>
> > I don't think I've heard anyone invoke the 4-line rule since about
> > 1992, though.  I didn't start generating short random quotes into my sig
> > until about 1996, well after the "standard" was effectively dead.
>
> <wry> We hang in different parts of USENET </wry>
>
> Last time I've seen it invoked was probably a couple of weeks ago.

I think I see it at least once a week on average. And that's gone *up*  
from earlier; in my first Usenet days (pre-Deja), I saw much less of it.


MfG Kai

Re: [kbuild-devel] Re: CML2 1.3.1, aka "I stick my neck out a mile..."

[Eric S. Raymond]

Alexander Viro <viro@math.psu.edu>:
> <wry> We hang in different parts of USENET </wry>
 
I don't hang in Usenet at all, any more.  Gave up on it about '98.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

You know why there's a Second Amendment?  In case the government fails to
follow the first one.
         -- Rush Limbaugh, in a moment of unaccustomed profundity 17 Aug 1993

Re: CML2 1.3.1, aka "I stick my neck out a mile..."

[nick]

I think ppl are recommending you BZ2 all your sigs......
	Nick

On Mon, 30 Apr 2001, Eric S. Raymond wrote:

> Alexander Viro <viro@math.psu.edu>:
> > >From AFW FAQ:
> > 
> > Q11. What is the McQuary limit?
> > A11. "There once was a man from Nantucket,
> >      who lost his .sig in a bucket.
> >      Five lines was too long,
> >      columns 80 just strong,
> >      so he didn't know where to tuck it."
> > A11. The limit on signature size:  "4x80".
> 
> I just added the following to the Jargon File masters:
> 
> @hd{McQuary limit} @p{} 4 lines of at most 80 characters each,
>    sometimes still cited on Usenet as the maximum acceptable size of a
>    @es{sig block}.  Before the great bandwidth explosion of the early
>    1990s, long sigs actually cost people running Usenet servers
>    significant amounts of money.  Nowadays social pressure against
>    long sigs is intended to avoid waste of human attention rather
>    than machine bandwidth.  Accordingly, the McQuary limit should 
>    be considered a rule of thumb rather than a hard limit; it's
>    best to avoid sigs that are large, repetitive, and distracting.
>    See also @es{warlording}.
> -- 
> 		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
> 
> What, then is law [government]? It is the collective organization of
> the individual right to lawful defense."
> 	-- Frederic Bastiat, "The Law"
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Re: CML2 1.3.1, aka "I stick my neck out a mile..."

[volodya]

On Mon, 30 Apr 2001, Eric S. Raymond wrote:

> Anton Altaparmakov <aia21@cam.ac.uk>:
> > >I tried whitespace, but the default Tkinter font isn't fixed-width.  How
> > >do you do invisible text?
> > 
> > Text colour = background colour -> invisible
> 
> Well, duh.  Unfortunately, it doesn't seem to have occured to the dozen or
> so people who suggested this that:
> 
> (a) Background color can vary depending on how Tk's X resources are set, and
> 
> (b) Tk doesn't give me, AFAIK, any way to query either that background color
>     or those resources.

button .x
.x cget -background

                 Vladimir Dergachev


> 
> Fer cripes' sake.  If it were that easy I'd have *done* it already, people!
> 
> Anyway my attempts to set a foreground color on an inactive button widget 
> failed.  I don't know why.  Tk is full of weird little corners like that.
> 
> What I've done is just disabled inactive help buttons without trying to
> hack the text or color. That makes them all the same width, though the 
> legend "Help" does show up in gray on the inacive ones.
> -- 
> 		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
> 
> "The state calls its own violence `law', but that of the individual `crime'"
> 	-- Max Stirner
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Re: CML2 1.3.1, aka "I stick my neck out a mile..."

[John Stoffel]

Eric> John Stoffel <stoffel@casc.com>:
>> Which is a real PITA because now I have to edit my .config file to
>> have:
>> 
>> CONFIG_RTC=y

Eric> The correct fix for this PITA is for Linus not to ship a broken
Eric> defconfig.

While I can sympathize with this comment, I still feel that CML2 needs
to be more robust and handle corner cases like this more gracefully.  

Eric> I hear you.  The problem is that "what's wrong" is not as
Eric> well-defined as one might like.  In this case the error could be
Eric> in the setting of X86, SMP, or RTC.  CML2 has no way to know
Eric> which of these is mis-set, so it can't know which one to pop
Eric> up..

It should then highlight *all* of the potential problem config
setting(s) and let the user deal.  But they should never be forced to
hand edit their config file because a dependency is broken somewhere.
CML2 should enforce the *writing* of compliant files, but should deal
gracefully with non-compliant ones.  Within reason of course.  
 
Eric> USB and SCSI are both enabled/disabled in the system buses menu.
Eric> The apparent confusion

Then they should be pushed down a level to be under those buses.  They
don't belong on the top level.

More correctly, *any* configuration setting on an upper level should
not depend on a lower level setting.  I know, this is probably not
possible for a variety of reasons, but I feel pretty strongly that we
should try to keep common options near/next to each other.

I can see where this would be a problem, using just SCSI as an
example, since you could have ISA, PCI or some other system bus SCSI
controller(s) on the system.  So where do you allow users to choose
whether to enable SCSI or not?  At the top level?  Only under the
"System Busses" menu item?

On the other hand, I really do like the search feature for config
stuff, it seems pretty powerful.

Thanks,
John
   John Stoffel - Senior Unix Systems Administrator - Lucent Technologies
	 stoffel@lucent.com - http://www.lucent.com - 978-952-7548

Re: [kbuild-devel] Re: CML2 1.3.1, aka "I stick my neck out a mile..."

[Eric S. Raymond]

nick@snowman.net <nick@snowman.net>:
> I think ppl are recommending you BZ2 all your sigs......

Yes, I got that.  Except for the people saying they like them as-is.

In the absence of a clear consensus on the matter, I'm going to do
as I please.  Especially since I have a strong suspicion that neither
camp would change their evaluation of my sigs if I did compress them.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

"The bearing of arms is the essential medium through which the
individual asserts both his social power and his participation in
politics as a responsible moral being..."
        -- J.G.A. Pocock, describing the beliefs of the founders of the U.S.

[OT] Re: CML2 1.3.1, aka "I stick my neck out a mile..."

[Jeff Garzik]

Does anybody have a procmail recipe that filters out e-mail to
linux-kernel that contain ridiculously long .sigs?
-- 
Jeff Garzik      | Game called on account of naked chick
Building 1024    |
MandrakeSoft     |

Re: [OT] Re: CML2 1.3.1, aka "I stick my neck out a mile..."

[Rik van Riel]

On Mon, 30 Apr 2001, Jeff Garzik wrote:

> Does anybody have a procmail recipe that filters out e-mail to
> linux-kernel that contain ridiculously long .sigs?
> --
> Jeff Garzik      | Game called on account of naked chick 
                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Why that? I see you too support the right to bare arms ;)

Rik
--
Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...

http://www.surriel.com/		http://distro.conectiva.com/

Send all your spam to aardvark@nl.linux.org (spam digging piggy)

Re: CML2 1.3.1, aka "I stick my neck out a mile..."

[Eric S. Raymond]

John Stoffel <stoffel@casc.com>:
> It should then highlight *all* of the potential problem config
> setting(s) and let the user deal.  But they should never be forced to
> hand edit their config file because a dependency is broken somewhere.
> CML2 should enforce the *writing* of compliant files, but should deal
> gracefully with non-compliant ones.  Within reason of course.  

The "within reason" is the problem.  It's very easy to construct
simple cases of invalid configs that blow the number of `tainted'
symbols up much larger than the number of violated constraints.  An
interface of the kind you suggest would deluge the user with possible
things to be corrected without actually revealing the nature of the
problem.

Besides, right now the configurator has a simple invariant.  It will
only accept consistent configurations and it will only write
consistent configurations -- in fact, your configuration is guaranteed
correct after ever attempt to change a symbol with the configurator
itself.  I'm very, very reluctant to do anything that will go near
breaking that invariant.

I believe the the right fix is to go through the one-time transition
necessary to be in a world where inconsistent configurations never get
written, rather than to be overly accomodating to yesterday's bugs.

> Eric> USB and SCSI are both enabled/disabled in the system buses menu.
> Eric> The apparent confusion
> 
> Then they should be pushed down a level to be under those buses.  They
> don't belong on the top level.

That doesn't work either.  See the "Good style in rulebase design"
section in the CML2 paper for discussion.  The last paragraph is
especially relevant.
 
> More correctly, *any* configuration setting on an upper level should
> not depend on a lower level setting.

Sorry, that's dreadfully bad advice and is not going to happen.  If I did
as you suggest, I'd be throwing out the ability to do consistency
checks and deduce side effects.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

"Those who make peaceful revolution impossible 
will make violent revolution inevitable."
	-- John F. Kennedy

Re: CML2 1.3.1, aka "I stick my neck out a mile..."

[Peter Samuelson]

[esr]
> Besides, right now the configurator has a simple invariant.  It will
> only accept consistent configurations

So you are saying that the old 'vi .config; make oldconfig' trick is
officially unsupported?  That's too bad, it was quite handy.

Peter

Re: CML2 1.3.1, aka "I stick my neck out a mile..."

[Eric S. Raymond]

Peter Samuelson <peter@cadcamlab.org>:
> [esr]
> > Besides, right now the configurator has a simple invariant.  It will
> > only accept consistent configurations
> 
> So you are saying that the old 'vi .config; make oldconfig' trick is
> officially unsupported?  That's too bad, it was quite handy.

Depends on how you define `unsupported'.  Make oldconfig will tell you 
exactly and unambiguously what was wrong with the configuration.  I think 
if you're hard-core enough to vi your config, you're hard-core enough to
interpret and act on

    This configuration violates the following constraints:
    (X86 and SMP==y) implies RTC!=n

without needing some wussy GUI holding your hand :-).
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

The end move in politics is always to pick up a gun.
	-- R. Buckminster Fuller

Re: [kbuild-devel] Re: CML2 1.3.1, aka "I stick my neck out a mile..."

[Gerhard Mack]

On Mon, 30 Apr 2001, Eric S. Raymond wrote:

> nick@snowman.net <nick@snowman.net>:
> > I think ppl are recommending you BZ2 all your sigs......
> 
> Yes, I got that.  Except for the people saying they like them as-is.
> 
> In the absence of a clear consensus on the matter, I'm going to do
> as I please.  Especially since I have a strong suspicion that neither
> camp would change their evaluation of my sigs if I did compress them.

Put them all on one long line and you can piss off a third camp.

	Gerhard

PS I have a long rant on the topics your sigs cover but I would hate to
see the resulting flamewar.


--
Gerhard Mack

gmack@innerfire.net

<>< As a computer I find your faith in technology amusing.

Re: [kbuild-devel] Re: CML2 1.3.1, aka "I stick my neck out a mile..."

[nick]

I'm fairly sure if he attached the BZ2'd sigs (exact same sigs, just bz2'd
and tacked on like they are currently) would offend at least three camps,
and have the benifit of showing up many broken mailers, filters, and
various other mail related items.
	Nick

On Mon, 30 Apr 2001, Gerhard Mack wrote:

> On Mon, 30 Apr 2001, Eric S. Raymond wrote:
> 
> > nick@snowman.net <nick@snowman.net>:
> > > I think ppl are recommending you BZ2 all your sigs......
> > 
> > Yes, I got that.  Except for the people saying they like them as-is.
> > 
> > In the absence of a clear consensus on the matter, I'm going to do
> > as I please.  Especially since I have a strong suspicion that neither
> > camp would change their evaluation of my sigs if I did compress them.
> 
> Put them all on one long line and you can piss off a third camp.
> 
> 	Gerhard
> 
> PS I have a long rant on the topics your sigs cover but I would hate to
> see the resulting flamewar.
> 
> 
> --
> Gerhard Mack
> 
> gmack@innerfire.net
> 
> <>< As a computer I find your faith in technology amusing.
> 

Requirement of make oldconfig [was: Re: [kbuild-devel] Re: CML2 1.3.1, aka ...]

[Giacomo A. Catenazzi]

"Eric S. Raymond" wrote:
> 
> Peter Samuelson <peter@cadcamlab.org>:
> > [esr]
> > > Besides, right now the configurator has a simple invariant.  It will
> > > only accept consistent configurations
> >
> > So you are saying that the old 'vi .config; make oldconfig' trick is
> > officially unsupported?  That's too bad, it was quite handy.
> 
> Depends on how you define `unsupported'.  Make oldconfig will tell you
> exactly and unambiguously what was wrong with the configuration.  I think
> if you're hard-core enough to vi your config, you're hard-core enough to
> interpret and act on
> 
>     This configuration violates the following constraints:
>     (X86 and SMP==y) implies RTC!=n
> 
> without needing some wussy GUI holding your hand :-).

I think that a fundamental requirment is that 'make oldconfig' should
validate any configurations (also the wrong conf).
(If you correct your rules, our old .config can be invalid on a new
kernel, and we don't want regualary edit our .config).

My proposal is instaed of complain about configuration violatation,
you just wrote the possible correct configuration and prompt user to
select the correct configuration.
In the case you cite, e.g. oldconfig shoud prompt:
  1) SMP=n
  2) RTC=m
  3) RTC=y
(assuming the ARCH is invariant).

To simplify your life you can require only tty (or ev. also menu mode)
for
there question. User normally use oldconfig in tty mode for simplicity
(there
are normally only few questions, thus is simple to have the question
already
in order, without to perse nearly empy menus).

	giacomo

Re: Requirement of make oldconfig [was: Re: [kbuild-devel] Re: CML2 1.3.1, aka ...]

[Eric S. Raymond]

Giacomo A. Catenazzi <cate@dplanet.ch>:
> I think that a fundamental requirment is that 'make oldconfig' should
> validate any configurations (also the wrong conf).
> (If you correct your rules, our old .config can be invalid on a new
> kernel, and we don't want regualary edit our .config).

Validating is exactly what it's doing now.  What you really want is for it to
semi-automatically *correct* broken configurations, which is very
different and much harder.

> My proposal is instaed of complain about configuration violatation,
> you just wrote the possible correct configuration and prompt user to
> select the correct configuration.
> In the case you cite, e.g. oldconfig shoud prompt:
>   1) SMP=n
>   2) RTC=m
>   3) RTC=y
> (assuming the ARCH is invariant).

You, and the other person who proposed this previously, are getting
way too hung up on this particular easy case and not thinking about
the general problem.

The number of prompts goes up with the number of variables in the constraint. 
But the number of possible correct configurations goes up as 2**n -- actually,
3**n because we have trits.

What you're saying, in effect, is that if f is number of frozen variables
in the constraint then the configurator ought to generate 3 ** (n - f)
possible correct models and prompt for one of them.  Since f typically 
equals just 1 that number goes up really fast with n.

And what if one of the variables in the constraint is of integer or
string type?  In that case the number of possible models to be
prompted for is effectively infinite.  (Finite but very very large).

You are proposing an interface that will handle easy cases but blow
up in the user's face in any hard one.  That's poor design, frustrating
the user exactly when he/she most needs help.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

"The bearing of arms is the essential medium through which the
individual asserts both his social power and his participation in
politics as a responsible moral being..."
        -- J.G.A. Pocock, describing the beliefs of the founders of the U.S.

Re: Requirement of make oldconfig [was: Re: [kbuild-devel] Re: CML2 1.3.1, aka ...]

[Olivier Galibert]

On Tue, May 01, 2001 at 12:31:12PM -0400, Eric S. Raymond wrote:
> You are proposing an interface that will handle easy cases but blow
> up in the user's face in any hard one.  That's poor design, frustrating
> the user exactly when he/she most needs help.

Yeah, but what is the current method, vi?

  OG.

Re: Requirement of make oldconfig [was: Re: [kbuild-devel] Re: CML2 1.3.1, aka ...]

[Tom Rini]

On Tue, May 01, 2001 at 05:35:12PM -0400, Olivier Galibert wrote:
> On Tue, May 01, 2001 at 12:31:12PM -0400, Eric S. Raymond wrote:
> > You are proposing an interface that will handle easy cases but blow
> > up in the user's face in any hard one.  That's poor design, frustrating
> > the user exactly when he/she most needs help.
> 
> Yeah, but what is the current method, vi?

If you edit a .config (current or CML2'ed) and fix a problem, it works.
What was the question again?  (And, if you edit an old .config, %s/^# CONFIG/CONFIG and %s/ is not set/=n, oldconfig works like you would expect, and can help
point out places where CML2 is slightly off).

-- 
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

Re: Requirement of make oldconfig [was: Re: [kbuild-devel] Re: CML2 1.3.1, aka ...]

[Giacomo Catenazzi]

"Eric S. Raymond" wrote:
> 
> Giacomo A. Catenazzi <cate@dplanet.ch>:
> > My proposal is instaed of complain about configuration violatation,
> > you just wrote the possible correct configuration and prompt user to
> > select the correct configuration.
> > In the case you cite, e.g. oldconfig shoud prompt:
> >   1) SMP=n
> >   2) RTC=m
> >   3) RTC=y
> > (assuming the ARCH is invariant).
> 
> You, and the other person who proposed this previously, are getting
> way too hung up on this particular easy case and not thinking about
> the general problem.
> 
> The number of prompts goes up with the number of variables in the constraint.
> But the number of possible correct configurations goes up as 2**n -- actually,
> 3**n because we have trits.
> 

???
No. You propmt only one invalid assertion.
After you this prompt you continue to validate rules and you
will
maybe prompt for another invalid rules. But these invalid
rules
are generally infrequent.

Thus in my proposal the number of questions on the *worste*
case
are equal to your proposal (rm configuration an reconfigure it
again, the vi methods is not serious).


> What you're saying, in effect, is that if f is number of frozen variables
> in the constraint then the configurator ought to generate 3 ** (n - f)
> possible correct models and prompt for one of them.  Since f typically
> equals just 1 that number goes up really fast with n.
>
> And what if one of the variables in the constraint is of integer or
> string type?  In that case the number of possible models to be
> prompted for is effectively infinite.  (Finite but very very large).

It is very unlikely to have constraint on string or on
integer.
But anyway, where is the problem?
You simple ask the new value of this symbol.

> 
> You are proposing an interface that will handle easy cases but blow
> up in the user's face in any hard one.  That's poor design, frustrating
> the user exactly when he/she most needs help.

But how do you help such users? Telling them to use vi?

Broken configuration will always exist (with generally few
errors).
Surelly also you produce incorrect configuration. (You can
garantee
that configuration for CML2 for kernel 2.4.3 is fully
compatible
with rules you use for 2.4.4? and for the 2.5.x?

We make always error. But if you don't correct the behaviour
of
oldconfig we will tend not to correct CML2 rules, because it
can
broke our configuration (and we will prefer a incorrect but
working
configuration that a correct configuration (but that requires
a complete reconfiguration, or some luck with vi)


	giacomo


PS: I think you missundestood my previous email.
No autimatic recovery of broken configuration, but it is need
a 
usefull tool to produce a valid configuration from an (maybe)
invalid or old configuration. In a manual manner.

Re: Requirement of make oldconfig [was: Re: [kbuild-devel] Re: CML2 1.3.1, aka ...]

[Eric S. Raymond]

Giacomo Catenazzi <cate@math.ethz.ch>:
> No. You propmt only one invalid assertion.  After you this prompt
> you continue to validate rules and you will maybe prompt for another
> invalid rules. But these invalid rules are generally infrequent.

I may be having problems with your English.  I don't think I understand this.
 
> It is very unlikely to have constraint on string or on integer.  But
> anyway, where is the problem?  You simple ask the new value of this
> symbol.

The problem is that you're now, in effect, telling me to invent a 
new interactive configurator with different rules than the normal one!

This is a horrible swamp to wander into just to avoid making oldconfig
users fire up vi occasionally.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

  "You have taught us much. Come with us and join the movement."
  "This movement of yours, does it have slogans?" inquired the Chink.
  "Right on!" they cried. And they quoted him some.
  "Your movement, does it have a flag?" asked the Chink.
  "You bet!" and they described their emblem.
  "And does your movement have leaders?"
  "Great leaders."
  "Then shove it up your butts," said the Chink. "I have taught you nothing."

	-- Tom Robbins, "Even Cowgirls Get The Blues"

Re: Requirement of make oldconfig [was: Re: [kbuild-devel] Re: CML2 1.3.1, aka ...]

[John Stoffel]

Eric> Giacomo Catenazzi <cate@math.ethz.ch>:

>> No. You propmt only one invalid assertion.  After you this prompt
>> you continue to validate rules and you will maybe prompt for another
>> invalid rules. But these invalid rules are generally infrequent.

Eric> I may be having problems with your English.  I don't think I
Eric> understand this.

He's saying that when you find the first invalid assertion, such as
not having CONFIG_RTC defined, when reading the .config file, you
should prompt for a fix.  Then once the input is taken, continue your
checks, prompting for each following problem as needed. 
 
>> It is very unlikely to have constraint on string or on integer.  But
>> anyway, where is the problem?  You simple ask the new value of this
>> symbol.

Eric> The problem is that you're now, in effect, telling me to invent
Eric> a new interactive configurator with different rules than the
Eric> normal one!

Eric> This is a horrible swamp to wander into just to avoid making oldconfig
Eric> users fire up vi occasionally.

No, we're just asking you to make the CML2 parser more tolerant of old
and possibly broken configs.

I haven't looked at the parser in any detail, but I assume that there
are heirarchal configuration settings.  When there is a mis-match,
where a sub-option conflicts with an upper option, how hard would it
be to print a warning, and just reset the sub-option to an acceptable
state?

Going back to the original CONFIG_RTC bug report I filed, all I had to
do was fire up vi and edit the .config file to turn on CONFIG_RTC,
which I think is completely bogus.

CML2 should be able to say "Hey, you need RTC turned on since you've
got SMP on, but it's not.  Should I do this for you?  Yes/No"

For trully broken .configs, maybe it makes sense to just give up and
say "Hey!  This .config is totally bogus, can I just ignore it and
have you redo your config in a sane manner?"

Make the computer do the work, not the user.

John

Hierarchy doesn't solve the problem

[Eric S. Raymond]

John Stoffel <stoffel@casc.com>:
> He's saying that when you find the first invalid assertion, such as
> not having CONFIG_RTC defined, when reading the .config file, you
> should prompt for a fix.  Then once the input is taken, continue your
> checks, prompting for each following problem as needed. 

The problem lies in that innocent-sounding phrase "prompt for a fix".
Generating such a prompt is a far deeper problem than you seem to realize.
  
> No, we're just asking you to make the CML2 parser more tolerant of old
> and possibly broken configs.

The parser is not the problem.  The parser tolerates old, broken
configs quite happily.  Gives you a nice pop-up message when it hits
an invalid symbol.  No, the problem is that y*ou're asking me to make
the deduction machinery solve a problem that is (a) ill-defined and
(b) subject to a 3^n combinatorial explosion.
 
> I haven't looked at the parser in any detail, but I assume that there
> are heirarchal configuration settings.  When there is a mis-match,
> where a sub-option conflicts with an upper option, how hard would it
> be to print a warning, and just reset the sub-option to an acceptable
> state?

Clever idea -- not so clever that stupid me didn't think of it six months
ago, but clever.  Might even work if the constraints always obeyed a neat
hierarchy.  They don't. The constraints can reach across the tree.

In many cases there is no way to define "upper" or "lower".  (X86 and
SMP) implies RTC!=n is actually a good example.  Here's where they fit
in the tree:

 main                   'Linux Kernel Configuration System'
     arch               'Processor type'
         X86            'Intel or compatible 80x86 processor'
     generic            'Architecture-independent feature selections'
         SMP            'Symmetric Multi-Processing support'
     archihacks         'Architecture-specific hardware hacks'
         RTC            'Enhanced Real Time Clock Support'

Yes, that's right -- they're all at the same level.  OK, X86 is frozen
by hypothesis.  So now give me a rule for telling which of SMP and RTC
is "superior".  Note that in order to make the rule usable by the
deducer, it can't know anything about the semantics of the symbols.

Do you sense an abyss yawning beneath you yet?  If not, hold on.
You'll see it shortly.

I started to write up a full explanation but I think I'm going to post
that separately.  It's long.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Never could an increase of comfort or security be a sufficient good to be
bought at the price of liberty.
	-- Hillaire Belloc

Re: Hierarchy doesn't solve the problem

[Urban Widmark]

On Thu, 3 May 2001, Eric S. Raymond wrote:

> In many cases there is no way to define "upper" or "lower".  (X86 and
> SMP) implies RTC!=n is actually a good example.  Here's where they fit
> in the tree:
> 
>  main                   'Linux Kernel Configuration System'
>      arch               'Processor type'
>          X86            'Intel or compatible 80x86 processor'
>      generic            'Architecture-independent feature selections'
>          SMP            'Symmetric Multi-Processing support'
>      archihacks         'Architecture-specific hardware hacks'
>          RTC            'Enhanced Real Time Clock Support'
> 
> Yes, that's right -- they're all at the same level.  OK, X86 is frozen
> by hypothesis.  So now give me a rule for telling which of SMP and RTC
> is "superior".  Note that in order to make the rule usable by the
> deducer, it can't know anything about the semantics of the symbols.

Doesn't 'make config' still ask the user about config options one-by-one?
(If not you can ignore the rest of this, I'd test it but I don't have time
 to mess with python2 right now).

Then it must somehow handle me trying to (incorrectly) answer X86=Y,
SMP=Y, RTC=N in some order?

The old oldconfig uses the existing .config as default answers, not as
initial state (right?). If an answer is missing or invalid then the user
gets a question. It never looks at all options at once. Doesn't that work
here?


When running make config I am guessing that this would happen:

The first symbol hit may be X86. The config-input has Y here, so it is
answered Y (I assume that is valid, otherwise do whatever the tty version
would normally do).

The second symbol would be SMP, the config-input says Y so it is set.
Since this requires RTC also I don't know what the tty version does, but
it must allow me to set it somehow.

The third symbol is RTC, the config-input has no defined value but it is
required by other settings so we ask. Possibly this is done automatically
right after setting SMP to Y.


There would be no 3^n problem as there is a defined order between the
symbols (whatever order 'make config' wants answers on an empty initial
state).

Perhaps I have missed something, but I really prefer the old oldconfig
over the new oldconfig.

/Urban

Re: Hierarchy doesn't solve the problem

[Eric S. Raymond]

Urban Widmark <urban@teststation.com>:
> Then it must somehow handle me trying to (incorrectly) answer X86=Y,
> SMP=Y, RTC=N in some order?

What it does is (a) always start with a valid config, and (b) not permit
any change that would make it invalid.

So, you froze X86 at startup.  SMP gets asked early.  If you specify 
SMP=y, and then later try to set RTC=n, the configurator will not let
you do it and will explain why.  At that point if you want you can go
back and change SMP.
 
> Perhaps I have missed something, but I really prefer the old oldconfig
> over the new oldconfig.

What's to prefer?  You get essentially the same behavior unless you start
with a broken config.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

This would be the best of all possible worlds, if there were
no religion in it.
	-- John Adams, in a letter to Thomas Jefferson.

Re: Requirement of make oldconfig [was: Re: [kbuild-devel] Re: CML2 1.3.1, aka ...]

[Horst von Brand]

John Stoffel <stoffel@casc.com> said:

[...]

> No, we're just asking you to make the CML2 parser more tolerant of old
> and possibly broken configs.

It is _much_ easier on everybody involved to just bail out and ask the user
(once!) to rebuild the configuration from scratch starting from the defaults.

If you support broken configurations in any way, your program is just
wildly guessing what they did mean. The exact (and very probably not in any
way cleanly thought out) behaviour in corner cases then becomes "the way
things work", and we end up in an unmaintainable mess yet again.

Please don't.
-- 
Dr. Horst H. von Brand                       mailto:vonbrand@inf.utfsm.cl
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

Re: Requirement of make oldconfig [was: Re: [kbuild-devel] Re: CML2 1.3.1, aka ...]

[Alan Cox]

> > No, we're just asking you to make the CML2 parser more tolerant of old
> > and possibly broken configs.
> 
> It is _much_ easier on everybody involved to just bail out and ask the user
> (once!) to rebuild the configuration from scratch starting from the defaults.

No. Every new kernel changes the constraints so every new kernel you have
to reconfigure from scratch. That also makes it very hard to be sure you got
the results right.

oldconfig has a simple algorithm that works well for current cases

Start at the top of the symbols in file order. If a symbol is new ask the
user. If a symbol is now violating a constraint it gets set according to 
existing constraints if not it gets set to its old value.

Alan

Re: Requirement of make oldconfig [was: Re: [kbuild-devel] Re: CML2 1.3.1, aka ...]

[Horst von Brand]

Alan Cox <alan@lxorguk.ukuu.org.uk> said:
> In-Reply-To: <200105031232.f43CW7aA009990@pincoya.inf.utfsm.cl> from "Horst von
>      *** Brand" at May 03, 2001 08:32:07 AM
> > > No, we're just asking you to make the CML2 parser more tolerant of old
> > > and possibly broken configs.

> > It is _much_ easier on everybody involved to just bail out and ask the
> > user (once!) to rebuild the configuration from scratch starting from
> > the defaults.

> No. Every new kernel changes the constraints so every new kernel you have
> to reconfigure from scratch. That also makes it very hard to be sure you got
> the results right.

Really? I've mostly seen symbols added, very rarely did I see constraints
changed. But that might be just my narrow view on the matter...

> oldconfig has a simple algorithm that works well for current cases
> 
> Start at the top of the symbols in file order. If a symbol is new ask the
> user. If a symbol is now violating a constraint it gets set according to 
> existing constraints if not it gets set to its old value.

I understand that to mean: "If it is new and (at least somewhat)
unconstrained, ask the user.  If fully constrained, take that value
unconditionally." This is a _very_ different case from a broken
configuration as a starting point, in which constraints are violated with
the values as set.

Hell, I had to rebuild my .config files from scratch a few times already
because of wild changes in the hardware on which the resulting kernels
would have to run, its not _that_ big a deal to have to perhaps have to do
it once each time a new stable kernel series starts or so.

People, remember that doing certain things in software is just not worth
the effort.
-- 
Dr. Horst H. von Brand                       mailto:vonbrand@inf.utfsm.cl
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

Re: Hierarchy doesn't solve the problem

[Juan Quintela]

>>>>> "eric" == Eric S Raymond <esr@thyrsus.com> writes:

eric> Urban Widmark <urban@teststation.com>:
>> Then it must somehow handle me trying to (incorrectly) answer X86=Y,
>> SMP=Y, RTC=N in some order?

eric> What it does is (a) always start with a valid config, and (b) not permit
eric> any change that would make it invalid.

eric> So, you froze X86 at startup.  SMP gets asked early.  If you specify 
eric> SMP=y, and then later try to set RTC=n, the configurator will not let
eric> you do it and will explain why.  At that point if you want you can go
eric> back and change SMP.
 
>> Perhaps I have missed something, but I really prefer the old oldconfig
>> over the new oldconfig.

eric> What's to prefer?  You get essentially the same behavior unless you start
eric> with a broken config.

Here is what I prefer (and need).

There are two cases that I need to solve, and that actually this are
the two uses that I had for make oldconfig (I never use xconfig nor
menuconfig).

1st scenary:

I have the .config of linux-2.4.x
Linus release linux-2.4.(x+1)

linux 2.4.(x+1) has more drivers/options/whatever that linux-2.4.x.  I
want to be prompted only for the new drivers/options/whatever it
chooses the old ones from the .config file.  Note that my old .config
file is not a valid configuration because it misses symbols (or I am
wrong and this is a valid configuration ?).

2nd scenery:

I have found a bug in my actual kernel and then I decided to turn some
feature off.  I don't want to surf over all the menus in make
{menu,x}config, because I _know_ the name of the feature.  I go to the
.config file and remove the needed line.  I can remove a line that
has no dependencies, or a line that has a lot of dependencies
(i.e. CONFIG_SCSI).  The actual menuconfig will do exactly what I
expect, it will ask only CONFIG_SCSI, and nothing else.

Notice that I am putting the .config in an invalid state, but it is
the easier way to change that feature.  Otherwise I will be happy if
you provide me something like:

    make "CONFIG_SCSI=n" oldconfig

or similar, i.e. _I_ know what I want to change, and I want to change
only that.  Notice that I want also be able to do the other way
around:

    make "CONFIG_SCSI=m" oldconfig

and then be prompted for all the SCSI drivers (because they was not in
the .config before).

Later, Juan.

-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

Re: Requirement of make oldconfig [was: Re: [kbuild-devel] Re: CML2 1.3.1, aka ...]

[Juan Quintela]

>>>>> "horst" == Horst von Brand <vonbrand@inf.utfsm.cl> writes:

Hi

horst> Hell, I had to rebuild my .config files from scratch a few times already
horst> because of wild changes in the hardware on which the resulting kernels
horst> would have to run, its not _that_ big a deal to have to perhaps have to do
horst> it once each time a new stable kernel series starts or so.

Not a option.  You can have to had _several_ configurations around
(here at MandrakeSoft we have normal/smp/enterprise) and we have
basically everything that can be compiled as modules compiled as
modules.  Add to that that we build the alpha (normal&smp) from the
same package.  We want to add more architectures to the rpm.  Are you
really serious that _answering_ all the options for several kernels is
an option?  I don't think so.  And the actual olconfig target works
well for me (tm).  I don't see the point to rewrote the configuration
language and made it _less_ powerfull for no good reason.

Later, Juan.

-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

Re: Requirement of make oldconfig [was: Re: [kbuild-devel] Re: CML2 1.3.1, aka ...]

[Eric S. Raymond]

Horst von Brand <vonbrand@inf.utfsm.cl>:
> If you support broken configurations in any way, your program is just
> wildly guessing what they did mean. The exact (and very probably not in any
> way cleanly thought out) behaviour in corner cases then becomes "the way
> things work", and we end up in an unmaintainable mess yet again.

Yes, this is precisely what I fear.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Rapists just *love* unarmed women.  And the politicians who disarm them.

Re: Requirement of make oldconfig [was: Re: [kbuild-devel] Re: CML2 1.3.1, aka ...]

[Eric S. Raymond]

Horst von Brand <vonbrand@inf.utfsm.cl>:
>> No. Every new kernel changes the constraints so every new kernel you have
>> to reconfigure from scratch. That also makes it very hard to be sure you got
>> the results right.
> 
> Really? I've mostly seen symbols added, very rarely did I see constraints
> changed. But that might be just my narrow view on the matter...

It's mine as well.  And I have been paying careful attention to this issue.
 
> > oldconfig has a simple algorithm that works well for current cases
> > 
> > Start at the top of the symbols in file order. If a symbol is new ask the
> > user. If a symbol is now violating a constraint it gets set according to 
> > existing constraints if not it gets set to its old value.
> 
> I understand that to mean: "If it is new and (at least somewhat)
> unconstrained, ask the user.  If fully constrained, take that value
> unconditionally." This is a _very_ different case from a broken
> configuration as a starting point, in which constraints are violated with
> the values as set.

Exactly!  And in fact, my oldconfig already does what Alan prescribes.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

To make inexpensive guns impossible to get is to say that you're
putting a money test on getting a gun.  It's racism in its worst form.
        -- Roy Innis, president of the Congress of Racial Equality (CORE), 1988

Re: Hierarchy doesn't solve the problem

[Eric S. Raymond]

Juan Quintela <quintela@mandrakesoft.com>:
> linux 2.4.(x+1) has more drivers/options/whatever that linux-2.4.x.  I
> want to be prompted only for the new drivers/options/whatever it
> chooses the old ones from the .config file.  Note that my old .config
> file is not a valid configuration because it misses symbols (or I am
> wrong and this is a valid configuration ?).

Yes, you're wrong.  This is a valid configuration.  If any of the
missing values have to be non-N, CML2 will deduce this and tell 
you what it's changing them to and why.

In CML2's world "symbol not set" is different from "symbol set to n".
When a symbol is not set, the deducer can force it to value that 
satisfies constraints.

Your second scenario is addressed by the samne correction.

>                                Otherwise I will be happy if
> you provide me something like:
> 
>     make "CONFIG_SCSI=n" oldconfig
> 
> or similar, i.e. _I_ know what I want to change, and I want to change
> only that.  Notice that I want also be able to do the other way
> around:
> 
>     make "CONFIG_SCSI=m" oldconfig
> 
> and then be prompted for all the SCSI drivers (because they was not in
> the .config before).

There is such an option.  It's -d, which sets a symbol from the
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Love your country, but never trust its government.
	-- Robert A. Heinlein.

Re: Requirement of make oldconfig [was: Re: [kbuild-devel] Re: CML2 1.3.1, aka ...]

[Alan Cox]

> Horst von Brand <vonbrand@inf.utfsm.cl>:
> > If you support broken configurations in any way, your program is just
> > wildly guessing what they did mean. The exact (and very probably not in any
> > way cleanly thought out) behaviour in corner cases then becomes "the way
> > things work", and we end up in an unmaintainable mess yet again.
> 
> Yes, this is precisely what I fear.

I have been thinking about this in more detail. In a sense oldconfig does do
stuff you dont see and can cause suprises but its better than 'fix it yourself
tough' which is the other approach.

If that aspect of it worries you collect a list of the symbols that were 
changed by the oldconfig process and colour them differently and/or offer
a view of them as part of the navigation

Re: Hierarchy doesn't solve the problem

[Mike Castle]

On Thu, May 03, 2001 at 03:46:20AM -0400, Eric S. Raymond wrote:
> What's to prefer?  You get essentially the same behavior unless you start
> with a broken config.

What's going to happen when this interconnected behavior results in a
previously acceptable config becomes broken (by definition) with a later
kernel version?

We're going to have hundreds of people complaining about this.  Not just
one or two.

mrc
-- 
       Mike Castle       Life is like a clock:  You can work constantly
  dalgoda@ix.netcom.com  and be right all the time, or not work at all
www.netcom.com/~dalgoda/ and be right at least twice a day.  -- mrc
    We are all of us living in the shadow of Manhattan.  -- Watchmen