[EMAIL PROTECTED] said:
:- Both of which are bugs imported from NetBSD.
Obviously a matter of opinion. I think declarative DSLs for
this kind of things are a good idea.
But I understand some people want to do everything by hand
in good-old C, and won't stop until it is ripped from their
Nik Clayton [EMAIL PROTECTED] wrote
in [EMAIL PROTECTED]:
That being the case, it wouldn't be too hard to do
commant lang="ja_JP.EUCjp".../comment
comment lang="es_ES.ISO_8859-1".../comment
and so on, would it?
If so, translated comment field can be obsolete while the
In message [EMAIL PROTECTED] Jun Kuriyama writes:
: Of course, source tree are for programmers. First thing we should
: consider is not to stress programmers for that procedure. Nik's
: suggestion is more conceptual one. We need more discussion for this
: subject.
I think that a large part of
In message [EMAIL PROTECTED] Garrett
Wollman writes:
: using XML is same process such as using src/sys/dev/usb/usbdevs. As
: you know, generation of usbdevs{,_data}.h is done by awk script. And
: same procedure is done in src/sys/dev/pccarddevs for generating
: pccarddevs{,_data}.h.
:
:
In message [EMAIL PROTECTED] Robert Withrow writes:
:
: [EMAIL PROTECTED] said:
: :- Both of which are bugs imported from NetBSD.
:
: Obviously a matter of opinion. I think declarative DSLs for
: this kind of things are a good idea.
The problem is that they are generated files that are
Warner Losh wrote:
In message [EMAIL PROTECTED] "Thomas M. Sommers" writes:
: I was thinking of something analogous to the way syscalls.master is used
: to generate several files.
This works well for syscalls.master, but I don't think it would work
well in the driver area. Call me
On Wed, Jun 28, 2000 at 06:24:01PM -0600, Warner Losh wrote:
In message [EMAIL PROTECTED] Nik Clayton writes:
: On Wed, Jun 28, 2000 at 11:27:12AM -0400, Thomas M. Sommers wrote:
: Warner Losh wrote:
:
: Any reason that the .c/.h files of the drivers couldn't be used to
: generate
In message [EMAIL PROTECTED] Nik Clayton writes:
: The .h file(s) should be generated from this XML config file, or some other
: mechanism needs to be put in place to prevent a (hardware) module from
: working if there isn't a functional entry for it in this XML config file.
:
: We've
Warner Losh wrote:
In message [EMAIL PROTECTED] "Thomas M. Sommers" writes:
: Warner Losh wrote:
:
: Any reason that the .c/.h files of the drivers couldn't be used to
: generate this information?
:
: Or perhaps the other way around.
No. I'm saying that the .c and .h files (likely
In message [EMAIL PROTECTED] "Thomas M. Sommers" writes:
: I was thinking of something analogous to the way syscalls.master is used
: to generate several files.
This works well for syscalls.master, but I don't think it would work
well in the driver area. Call me crazy.
However, I'll take an
So, this is what I worried about. :-)
At 29 Jun 2000 16:01:36 GMT,
Warner Losh [EMAIL PROTECTED] wrote:
I'd violently oppose this. I'd rather see the XML file generated from
the .h files that we already use to build the system with. You would
be making it just as hard to keep things up to
On Fri, 30 Jun 2000 12:08:50 +0900, Jun Kuriyama [EMAIL PROTECTED] said:
using XML is same process such as using src/sys/dev/usb/usbdevs. As
you know, generation of usbdevs{,_data}.h is done by awk script. And
same procedure is done in src/sys/dev/pccarddevs for generating
Any reason that the .c/.h files of the drivers couldn't be used to
generate this information? I think it would greatly enhance the
ability of the aintainer to update it.
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
On Mon, Jun 26, 2000 at 03:06:57PM -0600, Warner Losh wrote:
In message [EMAIL PROTECTED] Nik Clayton writes:
: In my world, this XML file would be a replacement for many of the files
: in src/sys/conf/. Or, at the very least, those files would be generated
: from this XML file. As a
On Mon, Jun 26, 2000 at 03:06:57PM -0600, Warner Losh wrote:
In message [EMAIL PROTECTED] Nik Clayton writes:
: In my world, this XML file would be a replacement for many of the files
: in src/sys/conf/. Or, at the very least, those files would be generated
: from this XML file. As a
On Mon, Jun 26, 2000 at 03:02:07PM -0600, Warner Losh wrote:
In message [EMAIL PROTECTED] Nik Clayton writes:
: Another script would parse the above and generate HARDWARE.TXT. And another
: could parse the above and spit out DocBook for the Handbook and FAQ.
There's some problems witht
On Mon, Jun 26, 2000 at 03:02:07PM -0600, Warner Losh wrote:
In message [EMAIL PROTECTED] Nik Clayton writes:
: Another script would parse the above and generate HARDWARE.TXT. And another
: could parse the above and spit out DocBook for the Handbook and FAQ.
There's some problems witht
Warner Losh wrote:
Any reason that the .c/.h files of the drivers couldn't be used to
generate this information?
Or perhaps the other way around.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
On Tue, Jun 27, 2000 at 11:49:34PM +0900, Hiroki Sato wrote:
Nik Clayton [EMAIL PROTECTED] wrote
in [EMAIL PROTECTED]:
[ That schema is not set in stone, and certainly requires more work. In
particular, we probably need "lang" and "encoding" options on the
comment element, to
On Wed, Jun 28, 2000 at 11:27:12AM -0400, Thomas M. Sommers wrote:
Warner Losh wrote:
Any reason that the .c/.h files of the drivers couldn't be used to
generate this information?
Or perhaps the other way around.
That's what I'd prefer. Any solution that relys on trying to parse
| I disagree. We're not Linux, where people can throw in code without thought
| to the wider consequences -- one of the commitments you should make (that's
| a generic "you" there, not you specifically) as a FreeBSD committer is to
| maintain the documentation that's affected by your changes.
| Perhaps it would be a good idea to assign someone the task of just maintaing
| the HARDWARE.TXT file, rather than expecting all developers to keep
| documentation up to date?
|
| That is what I am currently doing (at least trying to.. ;-) for
| FreeBSD/alpha. But considering that the
On Wed, Jun 28, 2000 at 02:45:25PM -0400, Dan Moschuk wrote:
| Perhaps it would be a good idea to assign someone the task of just maintaing
| the HARDWARE.TXT file, rather than expecting all developers to keep
| documentation up to date?
|
| That is what I am currently doing (at least
* From: Nik Clayton [EMAIL PROTECTED]
* Possibly. I was thinking that the only thing that would be language
* specific about each driver would be the comment section.
*
* comment.../comment
*
* All the other stuff is language independent.
*
* That being the case, it wouldn't be
In message [EMAIL PROTECTED] Dan Moschuk writes:
: Perhaps it would be a good idea to assign someone the task of just maintaing
: the HARDWARE.TXT file, rather than expecting all developers to keep
: documentation up to date?
This can be difficult to do. It will take someone with enough cycles
In message [EMAIL PROTECTED] "Thomas M. Sommers" writes:
: Warner Losh wrote:
:
: Any reason that the .c/.h files of the drivers couldn't be used to
: generate this information?
:
: Or perhaps the other way around.
No. I'm saying that the .c and .h files (likely .h) are the source to
the
In message [EMAIL PROTECTED] Nik
Clayton writes:
: Or does loading Japanese text in to a non-Japanese aware editor scramble
: the text?
It can, if the user editing the text isn't careful, or the editor
likes to do too many things automatically. Generally speaking,
however, it shouldn't be a big
On Wed, Jun 28, 2000 at 01:49:36PM -0400, Dan Moschuk wrote:
| I disagree. We're not Linux, where people can throw in code without thought
| to the wider consequences -- one of the commitments you should make (that's
| a generic "you" there, not you specifically) as a FreeBSD committer is
Nik Clayton [EMAIL PROTECTED] wrote
in [EMAIL PROTECTED]:
[ That schema is not set in stone, and certainly requires more work. In
particular, we probably need "lang" and "encoding" options on the
comment element, to support comments in more than one language. ]
LINT would then become
[ Sent to -doc, for info, -current for some expert advice on the feasability
of this approach with FreeBSD's migration to a kernel consisting only of
aggregated devices. ]
We have a problem with keeping our documentation up to date. One of the
most glaring examples of this is the hardware
At 26 Jun 2000 09:33:30 GMT,
nik wrote:
We have a problem with keeping our documentation up to date. One of the
most glaring examples of this is the hardware compatability list. We
currently list hardware information in LINT, HARDWARE.TXT, the FAQ, and the
Handbook. Any time this
On Mon, Jun 26, 2000 at 07:27:39PM +0900, Jun Kuriyama wrote:
So first of all, we (documentation project) should develop prototype
tool to achive that conversion.
And we should keep that master text simple to ease modification by
hackers. If we force to write complex markups, hackers will
Jun Kuriyama wrote:
And we should keep that master text simple to ease modification by
hackers. If we force to write complex markups, hackers will *forget*
to update that master text. :-)
I'm not sure I would *forget* it, but I my indulge in "forget"ing it.
:-)
--
Daniel C. Sobral
On Mon, Jun 26, 2000 at 08:40:44PM +0900, Daniel C. Sobral wrote:
Jun Kuriyama wrote:
And we should keep that master text simple to ease modification by
hackers. If we force to write complex markups, hackers will *forget*
to update that master text. :-)
I'm not sure I would *forget*
On Mon, Jun 26, 2000 at 08:40:44PM +0900, Daniel C. Sobral wrote:
Jun Kuriyama wrote:
And we should keep that master text simple to ease modification by
hackers. If we force to write complex markups, hackers will *forget*
to update that master text. :-)
I'm not sure I would *forget*
In message [EMAIL PROTECTED] Nik Clayton writes:
: In my world, this XML file would be a replacement for many of the files
: in src/sys/conf/. Or, at the very least, those files would be generated
: from this XML file. As a developer, if you don't update the file the
: system won't even know
In message [EMAIL PROTECTED] Nik Clayton writes:
: Another script would parse the above and generate HARDWARE.TXT. And another
: could parse the above and spit out DocBook for the Handbook and FAQ.
There's some problems witht his. the ed driver supports a whole raft
of cards, but who can list
37 matches
Mail list logo