Re: [Freedos-devel] Getting rid of kitten
Hi, I think that it sounds good! Bye Flo 2008/8/24 Gregory Pietsch [EMAIL PROTECTED]: FreeDOS maniacs, I was playing around with the implementation of edlin as it has been over a year since 2.10c, and was wondering if I could get rid of the ancient kitten.c and kitten.h files in the implementation. I am currently trying to tweak the catgets.c implementation so that it will be more Posix-like: relying on the environment variables LANG and NLSPATH for the information needed to find message catalogs. I'm trying to make the edlin implementation be at the forefront of innovation for FreeDOS. At the same time, Jim Hall might complain if I killed kitten by replacing it with something better (the files nl_types.h and catgets.c in edlin implement the catgets functionality) and I don't want to hurt his feelings. What does everyone think about this? Gregory - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel -- Florian Xaver Wien/Vienna http://www.drdos.org - http://www.flox.at.tf - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Getting rid of kitten
Hi Gregory, the problem is not that KITTEN is worse than CATGETS, the problem is that your kitten seems to be too old. You say I want to switch to catgets because catgets uses LANG and NLSPATH. That reasoning is odd if you ask me - KITTEN uses LANG and NLSPATH as well! :-) I was playing around with the implementation of edlin as it has been over a year since 2.10c, and was wondering if I could get rid of the ancient kitten.c and kitten.h files in the implementation. I am currently trying to tweak the catgets.c implementation so that it will be more Posix-like: relying on the environment variables LANG and NLSPATH for the information needed to find message catalogs. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Getting rid of kitten
On Sat, Aug 23, 2008 at 8:40 PM, Gregory Pietsch [EMAIL PROTECTED] wrote:
FreeDOS maniacs,
I was playing around with the implementation of edlin as it has been
over a year since 2.10c, and was wondering if I could get rid of the
ancient kitten.c and kitten.h files in the implementation.
I am currently trying to tweak the catgets.c implementation so that it
will be more Posix-like: relying on the environment variables LANG and
NLSPATH for the information needed to find message catalogs.
I'm trying to make the edlin implementation be at the forefront of
innovation for FreeDOS. At the same time, Jim Hall might complain if I
killed kitten by replacing it with something better (the files
nl_types.h and catgets.c in edlin implement the catgets functionality)
and I don't want to hurt his feelings.
What does everyone think about this?
Gregory
I doubt Jim would mind very much. :-) He says on his page
http://www.freedos.org/jhall/ that Kitten is not currently
maintained, so he would probably be happy for someone to take this on
and provide some updates. But that's just a guess - you might try
emailing him. ;-)
However, what version of Kitten or Cats do you have? (Kitten replaced
Cats.) Was it a locally-written version for Edlin? (I've never looked
at Edlin's i18n code.) You mentioned catgets.c, so I think Edlin must
have an old version of Cats, although Cats didn't have its own
nl_types.h.
Kitten already uses LANG and NLSPATH to find the catalog files. The
latest version of Kitten is kitten-c'.
http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/devel/libs/cats/kitten-c.zip
Like Catgets, when looking for a catalog, Kitten will scan the paths
provided in NLSPATH to look for the catalog file. In Kitten, this is a
very simple ruleset:
For each path in NLSPATH {
1. look for: NLSPATH\LANG\cat
2. look for: NLSPATH\cat.LANG
}
-jh
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Getting rid of kitten
Hi! I doubt Jim would mind very much. :-) He says on his page http://www.freedos.org/jhall/ that Kitten is not currently maintained, so he would probably be happy for someone to take this on and provide some updates. But that's just a guess - you might try emailing him. ;-) Well the core problem is: Gregory wants to move from kitten to catgets because he says kitten is not posixish enough... Yet on the other hand kitten was written because catgets is too heavy... Either catgets is a good choice for Gregory, for example if he wants to compile EDLIN for Linux, or there is some missing feature in kitten which would be good to have even in DOS (!). In the latter case, I might be interested to add that feature... I had assumed KITTEN is not maintained simply because it already did everything we want it to do :-) Eric - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Getting rid of kitten
The catgets implementation that is with FreeDOS edlin was one I wrote myself after looking at kitten and noticing that it was too DOS-specific (i.e. using low-level system calls to INT 21H to read and write to files) and tiny. It only had the ability to open one catalog at a time. I never looked at the ancient catgets. According to sysv3, the header file where catgets and friends are defined is called nl_types.h . According to the susv3 standards (available for free from the Open Group), NLSPATH contains a list of paths like printf format strings. The format strings have the following conversions: %N The value of the name parameter passed to catopen(). %L The value of the LC_MESSAGES category. %l The language element from the LC_MESSAGES category. %t The territory element from the LC_MESSAGES category. %c The codeset element from the LC_MESSAGES category. %% A single '%' character. An empty string is substituted if the specified value is not currently defined. The separators underscore ( '_' ) and period ( '.' ) are not included in the %t and %c conversion specifications. Templates defined in NLSPATH are separated by colons ( ':' ). A leading or two adjacent colons :: is equivalent to specifying %N. For example: NLSPATH=:%N.cat:/nlslib/%L/%N.cat indicates to catopen() that it should look for the requested message catalog in name, name.cat, and /nlslib/category/name.cat, where category is the value of the LC_MESSAGES category of the current locale. Users should not set the NLSPATH variable unless they have a specific reason to override the default system path. Setting NLSPATH to override the default system path produces undefined results in the standard utilities and in applications with appropriate privileges. [Option End] The environment variables LANG , LC_ALL , LC_COLLATE , LC_CTYPE , LC_MESSAGES , LC_MONETARY , LC_NUMERIC , LC_TIME , [XSI] [Option Start] and NLSPATH [Option End] provide for the support of internationalized applications. The standard utilities shall make use of these environment variables as described in this section and the individual ENVIRONMENT VARIABLES sections for the utilities. If these variables specify locale categories that are not based upon the same underlying codeset, the results are unspecified. The values of locale categories shall be determined by a precedence order; the first condition met below determines the value: 1. If the LC_ALL environment variable is defined and is not null, the value of LC_ALL shall be used. 2. If the LC_* environment variable ( LC_COLLATE , LC_CTYPE , LC_MESSAGES , LC_MONETARY , LC_NUMERIC , LC_TIME ) is defined and is not null, the value of the environment variable shall be used to initialize the category that corresponds to the environment variable. 3. If the LANG environment variable is defined and is not null, the value of the LANG environment variable shall be used. 4. If the LANG environment variable is not set or is set to the empty string, the implementation-defined default locale shall be used. If the locale value is C or POSIX, the POSIX locale shall be used and the standard utilities behave in accordance with the rules in POSIX Locale for the associated category. If the locale value begins with a slash, it shall be interpreted as the pathname of a file that was created in the output format used by the localedef utility; see OUTPUT FILES under localedef. Referencing such a pathname shall result in that locale being used for the indicated category. [XSI] [Option Start] If the locale value has the form: language[_territory][.codeset] it refers to an implementation-provided locale, where settings of language, territory, and codeset are implementation-defined. LC_COLLATE , LC_CTYPE , LC_MESSAGES , LC_MONETARY , LC_NUMERIC , and LC_TIME are defined to accept an additional field @ modifier, which allows the user to select a specific instance of localization data within a single category (for example, for selecting the dictionary as opposed to the character ordering of data). The syntax for these environment variables is thus defined as: [EMAIL PROTECTED] For example, if a user wanted to interact with the system in French, but required to sort German text files, LANG and LC_COLLATE could be defined as: LANG=Fr_FR LC_COLLATE=De_DE This could be extended to select dictionary collation (say) by use of the @ modifier field; for example: [EMAIL PROTECTED] [Option End] An implementation may support other formats. If the locale value is not recognized by the implementation, the behavior is unspecified. At runtime, these values are bound to a program's locale by calling the setlocale() function. Additional criteria for determining a valid locale name are implementation-defined. The changes to support a DOS framework would be to have a semicolon instead of a colon as
Re: [Freedos-devel] Getting rid of kitten
Hi! Given your description it definitely makes sense to keep all those features in catgets - it is good that kitten is smaller than that :-) Of course for being portable to Unix, catgets can be useful. Yet I never saw any % escape in and i18n setting on a Linux yet, so most people would not even notice if this is not supported by a version of catgets... Eric - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Getting rid of kitten
I didn't write the spec, I just have to implement it. I thought it would be easier if I started from scratch because I had a lot of low-hanging fruit to throw in. Seeing that MS-DOS was vaguely Unix-like, it makes sense to implement as much of what was in the Posix standard unless what's written in there is conflicting or unreasonable. Otherwise, we'd have a half-assed implementation, and nobody wants that. Gregory Eric Auer wrote: Hi! Given your description it definitely makes sense to keep all those features in catgets - it is good that kitten is smaller than that :-) Of course for being portable to Unix, catgets can be useful. Yet I never saw any % escape in and i18n setting on a Linux yet, so most people would not even notice if this is not supported by a version of catgets... Eric - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Getting rid of kitten
Hi Gregory, be easier if I started from scratch because I had a lot of low-hanging fruit to throw in. Seeing that MS-DOS was vaguely Unix... Otherwise, we would have a half-assed implementation, and nobody wants that. Well in that case you probably want a DJGPP style port of the original catgets library. DOS is not Unix like - it is the strength of DOS that it is NOT Unix actually - but GNUish things like DJGPP, MinGW and CygWin are available for platforms including DOS for those who do want to do things the Unix way. And they are welcome to use them, as long as they do not want the DOS kernel to implement the Linux kernel ;-) I myself will probably continue using kitten for DOS specific apps, simply because it is a small and lightweight i18n tool that fits in the style of DOS and because the small DOS specific apps need little Unix portability. Eric - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
