The latest version is always available at http://www.tuxedo.org/~esr/cml2/
Release 1.1.1: Sat Apr 14 23:41:34 EDT 2001
* Synchronized with 2.4.4-pre1.
* Adam Lackorzynski's patch to make install-cml2 do the right thing
with relative installation paths.
* The old menuconfig shortcut that 'm' in a boolean entry field
sets 'y' is now implemented.
* Simplified color scheme.
* Added fast-mode command to suppress side-effect computation
on slow machines.
I'd appreciate it if some of you with slow machines would try running
with fast mode on and seeing if that addresses the sluggishness.
--
<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
"Eric S. Raymond" wrote:
> Release 1.1.1: Sat Apr 14 23:41:34 EDT 2001
> * Synchronized with 2.4.4-pre1.
pre3 is out ;-)
> * Added fast-mode command to suppress side-effect computation
> on slow machines.
>
> I'd appreciate it if some of you with slow machines would try running
> with fast mode on and seeing if that addresses the sluggishness.
I assume that, eventually there will be no slow mode or fast mode
distinction... just a single fast mode. Right? :)
--
Jeff Garzik | "Give a man a fish, and he eats for a day. Teach a
Building 1024 | man to fish, and a US Navy submarine will make sure
MandrakeSoft | he's never hungry again." -- Chris Neufeld
At 04:45 15/04/2001, Eric S. Raymond wrote:
>Release 1.1.1: Sat Apr 14 23:41:34 EDT 2001
> * The old menuconfig shortcut that 'm' in a boolean entry field
> sets 'y' is now implemented.
> * Simplified color scheme.
Much better now! make xconfig still seems to be the old way (hadn't tried
it before)? - At least I get two shades of green. The lighter one is
completely unreadable on the silver background. Could I suggest to get rid
of the light/dark green distinction altogether, do it like the new
menuconfig colors, they are much improved now. - Also removing the N and
replacing M by m has improved readability by a long way. (-:
> * Added fast-mode command to suppress side-effect computation
> on slow machines.
>
>I'd appreciate it if some of you with slow machines would try running
>with fast mode on and seeing if that addresses the sluggishness.
On my Pentium 133S with fastmode I get a more than 2 fold increase in speed
and it feels a lot more usable. Still have to wait between key presses but
it is better than before.
I also tried this on a Dual Celeron 450. Speed is fine but you can still
feel that something is happening in between the key press and it taking
effect. fastmode doesn't make much difference that I could feel there.
One general note: scrolling between entries (up/down arrow) seems slower
than it should be. It is noticeable when you want to scroll several entries
at once and hit an arrow key quickly several times in succession. Perhaps
the action taken after reaching an entry could be delayed until the next
key press and only then when it is not one of the move to next/prev option
ones? That should make moving up/down instantaneous like in the old (cml1)
menuconfig. But then I have no idea how cml2 works so maybe my suggestion
is bogus...
Keep up the good work. You are on the right track. (-:
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/
Jeff Garzik <[email protected]>:
> I assume that, eventually there will be no slow mode or fast mode
> distinction... just a single fast mode. Right? :)
That's an interesting question to which I do not yet know the answer.
I am continuing to speed-tune.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
The Constitution is not neutral. It was designed to take the
government off the backs of the people.
-- Justice William O. Douglas
Anton Altaparmakov <[email protected]>:
> Much better now! make xconfig still seems to be the old way (hadn't tried
> it before)? - At least I get two shades of green. The lighter one is
> completely unreadable on the silver background. Could I suggest to get rid
> of the light/dark green distinction altogether, do it like the new
> menuconfig colors, they are much improved now.
Yeah, that was a typo. It will work this way in 1.1.2.
> On my Pentium 133S with fastmode I get a more than 2 fold increase in speed
> and it feels a lot more usable. Still have to wait between key presses but
> it is better than before.
Uh oh.
If you still have to wait I'd better make fastmode disable more stuff :-(.
> One general note: scrolling between entries (up/down arrow) seems slower
> than it should be.
That should be fixed now. I found a way to recode menuconfig's screen refresh
that will be faster and eliminate the screen flicker.
> Keep up the good work. You are on the right track. (-:
Thanks!
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
"Rightful liberty is unobstructed action, according to our will, within limits
drawn around us by the equal rights of others."
-- Thomas Jefferson
[Warning: historical reference ahead.]
> > I'd appreciate it if some of you with slow machines would try running
> > with fast mode on and seeing if that addresses the sluggishness.
>
> I assume that, eventually there will be no slow mode or fast mode
> distinction... just a single fast mode. Right? :)
Perhaps not, if fast mode won't display on the screen while running,
or such things... ;-)
Olaf
> * Added fast-mode command to suppress side-effect computation
> on slow machines.
You could put the computation in a low-priority thread, so that it
still gets done but doesn't mess up responsiveness.
Albert D. Cahalan <[email protected]>:
> > * Added fast-mode command to suppress side-effect computation
> > on slow machines.
>
> You could put the computation in a low-priority thread, so that it
> still gets done but doesn't mess up responsiveness.
Yes, I've thought about doing exactly this. It's a huge nasty can of
worms, though, because it would mean that the side effects from
setting a symbol could manifest some unpredictable amount of time
after they were triggered. And what if the user has taken actions
that set variables during that window? What if the side-effects
conflict?
Clearly, that way lies madness. I think my effort would be better spent
speed-tuning the deduction algorithms so fastmode can go away.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
The men and women who founded our country knew, by experience, that there
are times when the free person's answer to oppressive government has to be
delivered with a bullet. Thus, the right to bear arms is not just *a*
freedom; it's the mother of all freedoms. Don't let them disarm you!