Date: Wed, 22 Jan 1997 22:33:00 +0900 (JST) From: hosokawa@mt.cs.keio.ac.jp (HOSOKAWA Tatsumi) To: msmith@atrad.adelaide.edu.au Cc: davidn@unique.usn.blaze.net.au, jkh@time.cdrom.com, keithl@wakko.gil.net, config@freebsd.org, hosokawa@mt.cs.keio.ac.jp Subject: Re: Kernel configuration Message-ID: <199701221333.WAA24186@lenlen.mt.cs.keio.ac.jp> In-Reply-To: Your message of Wed, 22 Jan 1997 17:23:24 %2B1030 (CST). <199701220653.RAA14007@genesis.atrad.adelaide.edu.au>
next in thread | previous in thread | raw e-mail | index | archive | help
Removed -chat....
In article <199701220653.RAA14007@genesis.atrad.adelaide.edu.au>
msmith@atrad.adelaide.edu.au writes:
>> Thankyou 8) I've been using that style of syntax in our current software
>> for about 18 months now (in case you were wondering whether I'm just
>> making this up as I go along 8), and it's proven to be very useful.
At first, I thought that using SGML is better for maintaining this
system's extensibility because we can easily and intuitively extend
the syntax by modifying DTD, but now I think there're no apparent
difference in maintainance cost between SGML, Lex/YACC, Tcl, Perl,
etc. because we also have to extend the system not only in syntax
level but also in semantic level.
>> You could group based on the file the options are defined in, or you
>> could add a 'group' attribute, perhaps even with a heirachial syntax
>> if you thought it was worth it.
I'm sorry if I'm misunderstanding your statement, but I think that
heirachical syntax introduces the same problem we have experienced in
Pascal :-). For example, If A relys upon B:
B {
A {
}
}
.... it seems to have no problem, but if A relys upon B and C, and the
relationship between B and C is peer, it's impossible to be expressed
in this syntax.
I think that the relationship between options and devices should be
acyclic graph, not tree.
>> That actually sounds fairly reasonable. In situations where
>> only english text was available, the tool could fall back
>> on that as a default. (eg. I distribute a new driver with a .ki
>> file but not a .kim (message translation) file)
I implemented I18N extention to sysinstall (currently supports
Japanese and Traditional Chinese (Hong Kong and Taiwan)). This system
uses English message if there are no corresponding I18N messages. If
somebody wants to extned the sysinstall, s/he don't have to worry
about I18N support.
There's another problem to support I18N in such file is editors'
capability to mix many encoding system in single file. For example
most editor that can edit ISO-8859-1, can't edit ja_JP.EUC or
zh_TW.big5 text in the same file.
I think this problem can be avoided in the following ways:
1. Separate DESC files for each languages
It's easy (and I used this way for I18N sysinstall), but
readablity of files is poor, and it's hard to maintainance the
consistency between languages. If we take this way, we must
introduce the semiautomatic version management system that can
evaluate the version of each message (by using MD5 or
something) and mark "dirty bit" on unmodified I18N messages
whose original English message has been updated.
2. Use Unicode
Aside from the evaluation of Unicode system (this system is
not loved, or even hated by many Asian people), there're no
good editor that can edit Unicode documents.
3. Use MIME (or other encoding system that can map any charsets into
7-bit ascii code)
This also requires supporting system to encode/decode messages
in single file.
Sorry I'll think about requirement and formal definition of this
metacofig system this weekend because this week I'm too busy until
weekend :-). If you have any good idea, please tell me.
--
HOSOKAWA, Tatsumi
hosokawa@mt.cs.keio.ac.jp
hosokawa@jp.FreeBSD.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199701221333.WAA24186>