Mailing List Archive

> For the record (as I've told Eric before), I don't think freeze.py is
> any substitute for usable source code. If it is determined that Python
> is an absolutely onerous requirement and that the system must build
> with gcc only, it's not reasonable to expect Linus to run `freeze'
> every time someone patches the Python source.
Is maintaining a bunch of broken tcl any better? Why would it
be hard for Linus to run freeze, particularly if it were part of a Makefile?
Requiring everyone to have python is not reasonable, requiring Linus
to have python probably _is_ reasonable. Why is patching python code any
harder than patching C?
> Nor is it practical to
> require every CML2 patch submitter to include the patch to frozen C.
This is certainly impractical, but no one is suggesting it.
>
> So I think "there is a freeze.py available" is something of a red
> herring. Either we accept Python as a build requirement or we don't.
> (And if not, Eric or someone like him can go rewrite it all in C or
> *gasp* Perl.)
>
I disagree. Neither I nor most people will have interest in monkeying
with that portion of the code. If we do, then OK, we get python. Don't we have
to have tcl to monkey with the Tk source now?
> > I don't run X, think it's evil as hell, and love my
> > faster-than-a-bat-out-of-hell curses stuff, and would hate to have to
> > butcher the hell out of this stuff so that it doesn't look for the X
> > libraries at startup...
Perhaps a little discussion on the default behavior would be in order.
Austin
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

Ed Carp <erc@pobox.com>:
> Can it be compiled so that it doesn't even need the X libraries to even run?
> That would be nice. I don't run X, think it's evil as hell, and love my
> faster-than-a-bat-out-of-hell curses stuff, and would hate to have to butcher
> the hell out of this stuff so that it doesn't look for the X libraries at
> startup...
It doesn't need the X libraries to run. But it will use them if it finds them.
--
<a href="http://www.tuxedo.org/~esr">Eric S. Raymond
The day will come when the mystical generation of Jesus by the Supreme
Being as his father, in the womb of a virgin, will be classed with the
fable of the generation of Minerva in the brain of Jupiter.
-- Thomas Jefferson, 1823
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

Jeff Garzik <jgarzik@mandrakesoft.com>:
> You're rewriting kernel-doc in Python too?
Not yet. Hm. I hadn't noticed that one. No. I'll stick to making
configuration work right, for now anyway.

> Let's be realistic here. Very few will go to the trouble of doing the
> Python-to-C thing, because it requires Python in the first place.
> Python becomes an additional build requirement. Admit it and move on
> ;-)
Yes, Jeff, I know freezing is kind of a disingenuous answer. But it's
good enough, because the question was silly ;-).
--
<a href="http://www.tuxedo.org/~esr">Eric S. Raymond
The end move in politics is always to pick up a gun.
-- R. Buckminster Fuller
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

Dominik Kubla <dominik.kubla@uni-mainz.de>:
> > I'm aware of the problem :-). Python programs can be compiled to
> > portable C sources using the `freeze' tool. The translation is
>
> So we are back a C sources. Let me ask you one thing: why not simply
> use ISO-C and be done with it?
Basically, because managing memory by hand for this kind of application is more
pain than I want to go through. And the resulting program in C would be far
more complex and bug-prone.
A wise craftsman uses the right tool for the right job. I actually made
a run at coding one of the early versions in C; it was a bad idea.
Python is the right tool for this job.
I'll supply make productions to freeze C sources from the Python. They
can, if Linus so decides, be part of the release mechanics.
--
<a href="http://www.tuxedo.org/~esr">Eric S. Raymond
He that would make his own liberty secure must guard even his enemy from
oppression: for if he violates this duty, he establishes a precedent that
will reach unto himself.
-- Thomas Paine
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

Ed Carp wrote:
>
> Eric S. Raymond (esr@thyrsus.com) writes:
>
> > You'll like its behavior, then. It wakes up, looks around, says
> > "Can I do X and do I have Tkinter?". If so, it launches the Tk
> > interface (in my version; the one I posted doesn't have this code).
> >
> > If either DISPLAY is unset or Tkinter isn't importable, it then says
> > "Can I do screen graphics and do I have curses?" If so, it launches the curses
> > interface.
> >
> > If TERM is unset or the curses import fails, it falls back to glass-tty mode.
> >
> > Curses or glass-tty mode can be forced with command-line options.
>
> Can it be compiled so that it doesn't even need the X libraries to even run?
> That would be nice. I don't run X, think it's evil as hell, and love my
> faster-than-a-bat-out-of-hell curses stuff, and would hate to have to butcher
> the hell out of this stuff so that it doesn't look for the X libraries at
> startup...
Where does he say or even imply it needs any X libraries ?
If you have no X, then you are not running X. If you are not running X then
you have no $DISPLAY set. If you are not running X and yet have a $DISPLAY
set, then you have deliberately or ignorantly subverted such a common
standard that neither cml nor any of the hundreds of other programs that
will train-wreck in this environment should be held responsible.
--
Brian K. White http://www.squonk.net/users/linut
+++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
filePro BBx Linux SCO Prosper/FACTS AutoCAD #callahans Satriani
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

Jeff Garzik <jgarzik@mandrakesoft.com>:
> IMNSHO this attitude is wrong. If building the kernel is tough for
> newbies, make a userland utility with all these policy questions and
> features. We are talking about an interface on the KERNEL DEVELOPER
> side of the line.
We'll have to disagree on this. I am just as firmly of the opinion that
a well-designed tool can serve both populations well.
> I am all for making the kernel build and config process more flexible,
> but I am NOT at all for "dumbing down" the interface just so to make it
> easier for newbies to build a kernel.
Fine. You choose EXPERT or WIZARD on the policy menu, then.
> huh? compared to what ? It is simple to read, simple to modify. The
> major nasty issue right now is dependencies not readability.
It's pretty nasty -- mec himself, the CML1 maintainer, thinks so and
strongly encouraged me to shoot CML1 through the head if I could
possibly manage it. Perhaps you're too close to it to see how ugly it is.
> This definitely needs to be cleaned up, since some of the arch config.in
> code exists solely to work around problems which [presumeably] don't
> exist in yournew system.
>
> However I think that getting rid of the top-level arch files entirely
> will make for administrative headaches. Make sure you communicate
> thoroughly with the port maintainers on this one...
I'm aware that the One Big Tree design will entail some coordination
problems among the port maintainers. I'm pretty sure that, on net,
they'll be less than the friction costs of the present mess.
> You drop the CONFIG_xxx prefix? That's not something you do lightly,
> nor is it something you toss off as an aside. CONFIG_xxx is an
> important namespace convention and exists in a lot of existing kernel
> code.
You misunderstand. CML2 generates the CONFIG_ prefix into the config
files; I'm not changing the actual config-symbol namespace. it just
doesn't use the prefix in the ruleset declarations. Without it, the
symbols I'm requesting changes to look like malformed numbers.
> > Also, I had to change the KEYBOARD and MOUSE symbols used in the MIPS branch
> > to MIPS_KEYBOARD and MIPS_MOUSE. This is because the MOUSE symbol
> > seems to be used in different ways on different architectures (notably
> > in the Intel branch).
>
> An example of where merging completely independent config.in paths (Mips
> and Intel) causes a conflict :/
Yes. But this is a good conflict to be forced to resolve. The
multi-apex system has led to unnecessary complications and
duplications in the configuration-symbol namespace -- complications
which percolate up through the config tool to make kernel building
unnecessarily difficult. There is a particularly nasty case of this
near math emulation, for example.
> > Port maintainers and others with a continuing interest in the development
> > of CML2 should probably join the kbuild list -- subscribe in the usual
> > way via linux-kbuild-request@torque.net
>
> You should CC maintainers when their code is being discussed or
> updated. The onus of effort is on YOU to make your changes known.
> Otherwise you imply an unscalable model where maintainers must track
> every mailing list that could potentially discuss and affect their code.
I'm willing to make this effort. How do I go from a symbol to identifying
the relevant maintainer?

> Overall, I think it is high time that the config system was rewritten.
> While you are doing so, please consider two suggestions:
I think these are both fine ideas for later in the process. Right now
I want to stay focused on managing the transition to a clean language
and toolkit. That will position us to attack the larger problems --
which I *will* cheerfully take on, as they involve kinds of problems I
enjoy solving and am correspondingly good at.
--
<a href="http://www.tuxedo.org/~esr">Eric S. Raymond
Americans have the right and advantage of being armed - unlike the citizens
of other countries whose governments are afraid to trust the people with arms.
-- James Madison, The Federalist Papers
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

John Cowan <cowan@locke.ccil.org>:
> Peter Samuelson scripsit:
>
> > If it is determined that Python
> > is an absolutely onerous requirement and that the system must build
> > with gcc only, it's not reasonable to expect Linus to run `freeze'
> > every time someone patches the Python source. Nor is it practical to
> > require every CML2 patch submitter to include the patch to frozen C.
>
> Patches *to* cmlcompile and cmlconfig would presumably be in Python,
> and the Makefile for these programs would include a freeze step.
> Changes to the CML itself would not require refreezing anything,
> as they only change the pickled rulebase.
Couldn't have put it better myself.

> Are you under the impression that CML2 is a subset of Python, or
> that it's interpreted by the Python interpreter directly, or something?
> Not so. It is a distinct language, implemented with a compiler and a VM,
> both of which happen in turn to be implemented in Python. Since it
> is possible to compile Python to C, both compiler and VM
> can be supplied in either C-source or executable form.
I wouldn't describe the configurator as a VM exactly, but this is
otherwise correct.
--
<a href="http://www.tuxedo.org/~esr">Eric S. Raymond
"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.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

[esr]
> > Basically, because managing memory by hand for this kind of
> > application is more pain than I want to go through. And the
> > resulting program in C would be far more complex and bug-prone.
[willy@thepuffingroup.com <willy@thepuffingroup.com>]
> why even bother keeping track of memory? this is a run-and-exit
> program; the memory you used gets freed at exit.
If it really turns out to be that simple, someone can go and rewrite
the whole business in C. (You know, like ksymoops.) When Eric first
brought his proposal to linux-kbuild a few months ago, we made him
promise to draft a full language spec (as opposed to just a RTSL spec).
This is one reason -- so it can be reimplemented accurately.
In fact, depending on how well I end up liking his language (haven't
downloaded it yet, but I remember roughly what it looked like in
earlier design stages -- it did seem sane) I might take this on myself.
Because I don't know if I want to see the extra tool requirement. And
I *really* don't think I want to see "freeze" files in Linus's patches.
(Precompiled files are, unfortunately, *necessary* with SCSI firmware
... they shouldn't be necessary in the config system.)
Peter
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

On Wed, 24 May 2000, Brian K. White wrote:
>Ed Carp wrote:
>>
>> Eric S. Raymond (esr@thyrsus.com) writes:
>>
>> > You'll like its behavior, then. It wakes up, looks around, says
>> > "Can I do X and do I have Tkinter?". If so, it launches the Tk
>> > interface (in my version; the one I posted doesn't have this code).
>> >
>> > If either DISPLAY is unset or Tkinter isn't importable, it then says
>> > "Can I do screen graphics and do I have curses?" If so, it launches the curses
>> > interface.
>> >
>> > If TERM is unset or the curses import fails, it falls back to glass-tty mode.
>> >
>> > Curses or glass-tty mode can be forced with command-line options.
>>
>> Can it be compiled so that it doesn't even need the X libraries to even run?
>> That would be nice. I don't run X, think it's evil as hell, and love my
>> faster-than-a-bat-out-of-hell curses stuff, and would hate to have to butcher
>> the hell out of this stuff so that it doesn't look for the X libraries at
>> startup...
>
>Where does he say or even imply it needs any X libraries ?
>
>If you have no X, then you are not running X. If you are not running X then
>you have no $DISPLAY set. If you are not running X and yet have a $DISPLAY
>set, then you have deliberately or ignorantly subverted such a common
>standard that neither cml nor any of the hundreds of other programs that
>will train-wreck in this environment should be held responsible.
I do configuration over a SSL connection, with X display, but no X server
other than the SSL X. Does that mean I have the X development libraries?
NO. I do have the applications though. I do have the compiler (for building
the kernel mostly), and base libraries. I do not have the X libraries.
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@cats-chateau.net
Any opinions expressed are solely my own.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

[John Cowan <cowan@locke.ccil.org>]
> Patches *to* cmlcompile and cmlconfig would presumably be in Python,
> and the Makefile for these programs would include a freeze step.
I know, I still don't like it. Including generated files in a source
distribution is just wrong, when avoidable. (I even dislike seeing
files generated by lex, yacc and autoconf, although I fully understand
the practical reasons why so much software ships with them.)
It bloats Linus's tarballs, bloats Linus's patches, and (depending on
whether Linus wants to take responsibility for generating the freeze
files) could bloat people's patches to Linus.
> Are you under the impression that CML2 is a subset of Python, or that
> it's interpreted by the Python interpreter directly, or something?
No, I understand what CML2 is. Eric first brought it up on
linux-kbuild a few months ago. I even agree with most of where he's
going with it. My main objection is the Python tool dependency -- and
the attempt to deflate it by saying "but if you must, you can also ship
basically-binary-equivalent C code". To me that's not a very practical
answer.
Peter
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
"Eric S. Raymond" wrote:
> The project is not yet complete, but it has reached a beta stage at
> which it is usable and in significant ways functionally superior to the
> present system. I am confident that it will complete. I am announcing
> now rather than holding off until I'm completely done because there
> are some preparations which, if begun now, will significantly reduce
> total transition costs. These preparations will *not* break the
> present kbuild system.
>
> Why this project at all? It all started when I realized that building
> kernels is way too hard. I wanted to simplify the configuration task
> enough to make configuration accessible to non-gurus. It needs to
> have more policy options. Rather than hundreds of questions like
> "Include FOOBAR2317 driver?", the novice should see stuff like
> "Compile in all modular drivers as modules without prompting?"
Jeff Garzik <jgarzik@mandrakesoft.com> responded:
IMNSHO this attitude is wrong. If building the kernel is tough for
newbies, make a userland utility with all these policy questions and
features. We are talking about an interface on the KERNEL DEVELOPER
side of the line.
I am all for making the kernel build and config process more flexible,
but I am NOT at all for "dumbing down" the interface just so to make it
easier for newbies to build a kernel. If a person does not understand
the issues related with building a kernel, they should get someone else
to do it for them. That's why distributions and vendors exist.
Hi Folks,
I've spent 40 years being a newbie. It's that or passé. I was
programming before assemblers were invented. Today's "newbies" are often
more advanced than yesterday's programmers. I now have octagenerians
asking me to help them install linux. Note the word help. The general
computer user population is tons more sophisticated than it was even 5
years ago. Worry about functionality. The newbies will learn. What I
would like to see is for Configure.help to become a nice readable doc or
the information source for one. This would give people an advance look
at the questions that will be presented.
Garst
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

On Wed, May 24, 2000 at 08:45:50PM -0400, Eric S. Raymond wrote:
> Basically, because managing memory by hand for this kind of application is more
> pain than I want to go through. And the resulting program in C would be far
> more complex and bug-prone.
why even bother keeping track of memory? this is a run-and-exit program;
the memory you used gets freed at exit.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

willy@thepuffingroup.com <willy@thepuffingroup.com>:
> On Wed, May 24, 2000 at 08:45:50PM -0400, Eric S. Raymond wrote:
> > Basically, because managing memory by hand for this kind of application is
> > more pain than I want to go through. And the resulting program in C would
> > be far more complex and bug-prone.
>
> why even bother keeping track of memory? this is a run-and-exit program;
> the memory you used gets freed at exit.
That's not anywhere near a complete solution. Please trust me on
this, because otherwise I'd have to give you a longer brain dump on
the engineering of compilers and interpreters and the shortcomings of
C than I have time for right now.
I've written more of these than I can easily remember, it's my specialty.
It can be done in C (and about half of my projects demonstrate that I know
both the words and the music of that tune) but you sure don't want to unless
the production speed of the compiler/interpreter is a drop-dead issue.
Barring the mythical portable-LISP-dialect-with-good-OS-bindings that
has never existed, Python is about the most reasonable alternative
there is for this kind of work.
--
<a href="http://www.tuxedo.org/~esr">Eric S. Raymond
Every election is a sort of advance auction sale of stolen goods.
-- H.L. Mencken
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

Peter Samuelson <peter@cadcamlab.org>:
> If it really turns out to be that simple, someone can go and rewrite
> the whole business in C. (You know, like ksymoops.) When Eric first
> brought his proposal to linux-kbuild a few months ago, we made him
> promise to draft a full language spec (as opposed to just a RTSL spec).
> This is one reason -- so it can be reimplemented accurately.
I feel impelled to note that the kbuild guys didn't "make" me promise
that -- I would have written a careful language description anyway
because I just *do* things that way. It's called professionalism, or
something.
--
<a href="http://www.tuxedo.org/~esr">Eric S. Raymond
A human being should be able to change a diaper, plan an invasion,
butcher a hog, conn a ship, design a building, write a sonnet, balance
accounts, build a wall, set a bone, comfort the dying, take orders, give
orders, cooperate, act alone, solve equations, analyze a new problem,
pitch manure, program a computer, cook a tasty meal, fight efficiently,
die gallantly. Specialization is for insects.
-- Robert A. Heinlein Time Enough for Love
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

Peter Samuelson (peter@cadcamlab.org) writes:
> > I don't run X, think it's evil as hell, and love my
> > faster-than-a-bat-out-of-hell curses stuff, and would hate to have to
> > butcher the hell out of this stuff so that it doesn't look for the X
> > libraries at startup...
>
> Me too but I do have X libraries installed -- it's just too handy to
> use distribution binaries and a lot of Debian is linked against xlib
> even where X is optional. (It's Debian policy in fact -- if you *can*
> configure with X support, you should, and if you expect that to be a
> problem, you can provide a secondary package without X.)
That's *stupid*. What about all those cool linux-router-in-a-box-boot-off-a-folppy
sort of distributions? They sure can't use Debian...
I've got an old 486/50 laptop that's got a couple of PCMCIA network cards in
it, doing routing/NAT stuff between my home LAN and an ADSL line, and it works
perfectly. It all boots off of floppies, and I'm working on getting it to
boot off of one. It would be impossible if all my stuff were linked against
xlib.
--
Ed Carp, N7EKG erc@pobox.com 940/367-2744 cell phone
http://www.pobox.com/~erc
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

> > When Eric first brought his proposal to linux-kbuild a few months
> > ago, we made him promise to draft a full language spec (as opposed
> > to just a RTSL spec).
[esr]
> I feel impelled to note that the kbuild guys didn't "make" me promise
> that -- I would have written a careful language description anyway
> because I just *do* things that way. It's called professionalism, or
> something.
I know, sorry for implying otherwise. MEC asked you to, as I recall,
and you said you had already planned on it.
Peter
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

[Ed Carp <erc@pobox.com>]
> That's *stupid*. What about all those cool
> linux-router-in-a-box-boot-off-a-folppy sort of distributions? They
> sure can't use Debian...
Sure, they just have to recompile packages. Debian was never meant to
be one-size-fits-all, and recompiling isn't all that hard.
I actually ran into this problem once. I had an old Debian install on
a laptop and it was nowhere near an Internet connection or a Debian CD,
and the install was somewhat broken, and xlib was nowhere to be found,
and I wanted to run Emacs. I ended up compiling a lib full of stubs
and relying on Emacs not to try calling them. It worked.
This approach could be taken by the router-on-a-floppy types. Debian
already has a "svgalib-dummy" package similar to what I did above, so
that you can run svgalib-capable packages like ghostscript without
needing svgalib. I've often wondered what has prevented any Debian
developers for doing the same with xlib.
Peter
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

On Wed, May 24, 2000 at 11:57:34PM +0200, Dominik Kubla wrote:
> Hi Eric,
>
> now i know why we haven't heard of you for some time: you have
> been very busy... ;-)
>
> On Wed, May 24, 2000 at 04:37:47PM -0400, Eric S. Raymond wrote:
>
> > I'm aware of the problem :-). Python programs can be compiled to
> > portable C sources using the `freeze' tool. The translation is
>
> So we are back a C sources. Let me ask you one thing: why not simply
> use ISO-C and be done with it? There are excelllent tools like yacc
> and lex for building parsers, why don't you use them to generate C
> code instead on an obscure script language. I know you really like
> Python, but face it: 90% of the folks on this list probaly don't.
As much as I hate Python you would have to be masochistic to try
and code something like this in straight C. The string and regex
capabilities in Python/Perl/Tcl make things a lot simpler plus a
lot easier to maintain.
Python can generate C source code output so it is not a delivery
problem. If you don't like Python that's OK too, because I don't
particularly like the spaghetti mess of Perl/Tcl/Tk/C/Bash we're
suffering with either.
Eric's thing sounds like an overall win. Complaints about Python
are really missing the point.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

On Wed, May 24, 2000 at 09:27:57PM -0500, Peter Samuelson wrote:
> It bloats Linus's tarballs, bloats Linus's patches, and (depending on
> whether Linus wants to take responsibility for generating the freeze
> files) could bloat people's patches to Linus.
Especially since freeze requires the entire source for the Python
interpreter (unless freeze has been significantly since I last
looked at it). Forget freeze and just install Python. The
interpreter and standard library is not all that large. Besides,
Python is super cool. :)
Neil
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

On Wed, May 24, 2000 at 08:45:50PM -0400, Eric S. Raymond wrote:
>
> Basically, because managing memory by hand for this kind of application is more
> pain than I want to go through. And the resulting program in C would be far
> more complex and bug-prone.
>
> A wise craftsman uses the right tool for the right job. I actually made
> a run at coding one of the early versions in C; it was a bad idea.
> Python is the right tool for this job.
>
> I'll supply make productions to freeze C sources from the Python. They
> can, if Linus so decides, be part of the release mechanics.
This thread is turning nasty.
Could people please keep in mind that the real work Eric has given
us here is a language specification for CML2. The Python script is
simply a reference implementation and it is entirely irrelevant in
considering the actual merits of CML2.
If CML2 looks like a winner then it would be no real effort to get
a C version up and running. In the meantime, complaining about the
reference implementation is like complaining about the size of the
cup holders in a revolutionary new electric car.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

On Wed, 24 May 2000, Ed Carp wrote:
>Peter Samuelson (peter@cadcamlab.org) writes:
>
>> > I don't run X, think it's evil as hell, and love my
>> > faster-than-a-bat-out-of-hell curses stuff, and would hate to have to
>> > butcher the hell out of this stuff so that it doesn't look for the X
>> > libraries at startup...
>>
>> Me too but I do have X libraries installed -- it's just too handy to
>> use distribution binaries and a lot of Debian is linked against xlib
>> even where X is optional. (It's Debian policy in fact -- if you *can*
>> configure with X support, you should, and if you expect that to be a
>> problem, you can provide a secondary package without X.)
>
>That's *stupid*. What about all those cool linux-router-in-a-box-boot-off-a-folppy
>sort of distributions? They sure can't use Debian...
>
>I've got an old 486/50 laptop that's got a couple of PCMCIA network cards in
>it, doing routing/NAT stuff between my home LAN and an ADSL line, and it works
>perfectly. It all boots off of floppies, and I'm working on getting it to
>boot off of one. It would be impossible if all my stuff were linked against
>xlib.
Do you build kernels on your router?
If not, then your point is moot.
-George Greer
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

Eric S. Raymond (esr@thyrsus.com) writes:
> willy@thepuffingroup.com <willy@thepuffingroup.com>:
> > On Wed, May 24, 2000 at 08:45:50PM -0400, Eric S. Raymond wrote:
> > > Basically, because managing memory by hand for this kind of application is
> > > more pain than I want to go through. And the resulting program in C would
> > > be far more complex and bug-prone.
> >
> > why even bother keeping track of memory? this is a run-and-exit program;
> > the memory you used gets freed at exit.
>
> That's not anywhere near a complete solution. Please trust me on
> this, because otherwise I'd have to give you a longer brain dump on
> the engineering of compilers and interpreters and the shortcomings of
> C than I have time for right now.
Why should we? What "shortcomings"? You mean, like you have to free
what you malloc? That's not a "shortcoming", that's just laziness. On the
other hand, you are right - *not* keeping track of memory necause it's just
a "run-and-exit" program is also programmer laziness.
It's easy enough to write routines that will do the memory management stuff
for you, and the C program would *not* be much more complex, nor would it
be much more error prone. Just because you don't want to, or don't have the
time, is no reason to try and trash C.
> I've written more of these than I can easily remember, it's my specialty.
> It can be done in C (and about half of my projects demonstrate that I know
> both the words and the music of that tune) but you sure don't want to unless
> the production speed of the compiler/interpreter is a drop-dead issue.
Oh, stop it before it becomes a religious issue. You are right, but only from
your own perspective. From my perspective, from someone who has written
literally thousands of lines of production C, it's *always* an issue. People
who ignore performance or memory issues are fools who assume that everyone
is going to be running their code on the latest PIII with a gig of RAM.
--
Ed Carp, N7EKG erc@pobox.com 940/367-2744 cell phone
http://www.pobox.com/~erc
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

Peter Samuelson scripsit:
> If it is determined that Python
> is an absolutely onerous requirement and that the system must build
> with gcc only, it's not reasonable to expect Linus to run `freeze'
> every time someone patches the Python source. Nor is it practical to
> require every CML2 patch submitter to include the patch to frozen C.
Patches *to* cmlcompile and cmlconfig would presumably be in Python,
and the Makefile for these programs would include a freeze step.
Changes to the CML itself would not require refreezing anything,
as they only change the pickled rulebase.
Are you under the impression that CML2 is a subset of Python, or
that it's interpreted by the Python interpreter directly, or something?
Not so. It is a distinct language, implemented with a compiler and a VM,
both of which happen in turn to be implemented in Python. Since it
is possible to compile Python to C, both compiler and VM
can be supplied in either C-source or executable form.
--
John Cowan cowan@ccil.org
Yes, I know the message date is bogus. I can't help it.
--me, on far too many occasions
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

George (greerga@nidhogg.ham.muohio.edu) writes:
> >I've got an old 486/50 laptop that's got a couple of PCMCIA network cards in
> >it, doing routing/NAT stuff between my home LAN and an ADSL line, and it works
> >perfectly. It all boots off of floppies, and I'm working on getting it to
> >boot off of one. It would be impossible if all my stuff were linked against
> >xlib.
>
> Do you build kernels on your router?
>
> If not, then your point is moot.
That statement is insane. Whether or not I build kernels on my router has
absolutely nothing to do with the issue. And if you can't see the point,
what are you doing here?
--
Ed Carp, N7EKG erc@pobox.com 940/367-2744 cell phone
http://www.pobox.com/~erc
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

Eric S. Raymond (esr@thyrsus.com) writes:
[lotso stuff about some coding]
I'm not about to jump into the religious war about programming languages
et al (if I did, I'd be squarely in the do-it-C camp, supporting BitKeeper
has taught me that if you care about maintaining something you don't
depend on scripting languages which keep getting "better" and breaking
old scripts - but I really don't see it as a big issue in this case).
I'd just like to welcome Eric back to programming. I personally think that
you lead by example, and what better way to lead a bunch of programmers than
by programming? Welcome back, Eric, it's good to see you doing what you do
so well.
We now return you to your regularly scheduled religious war about programming
languages. Tune in next week for our discussion of licensing models :-)
--
---
Larry McVoy lm@bitmover.com http://www.bitmover.com/lm
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/