Mail Archives: cygwin/1999/02/26/04:22:33
Hello Christopher,
Christopher Faylor <cgf AT cygnus DOT com> wrote:
>> that's not Cygwin problem - IMHO, that's GNU problem - their
>>style of writing programs is somewhat ... not as in other places %)
CF> Could you be more specific? What "style of writing programs" are you
CF> referring to? Is it just the indentation? That's surely an extremely
CF> trivial thing.
CF> Cygwin is unusual in that it's written in C++ but hopefully that's
CF> not *too* big a barrier at this time.
CF> Otherwise, given the vast popularity of GNU tools and the huge number of
CF> people contributing to them, I'm mystified as to your problems with the
CF> GNU style of writing software. There is so much GNU software available
CF> that one could easily make the case that it is actually the norm.
To try to explain it, I first quote my opinion on why DJGPP gets
more attention of contributors:
<quote>
DD> DJGPP has a much higher threshold (it's much more complicated), but
DD> there are far more people contributing to djgpp than to cygwin. If
DD> anyone can figure out *why*, let us know! ;-) I think it's social -
DD> djgpp contributors just know that they'll get a friendly reception to
DD> their contributions, good or bad, so they aren't as hesitant to send
DD> stuff in.
O, no, don't say! All perceived in comparison. I'm not quite happy
with djgpp too, but comparing with cygwin it's bless ;-) I'd call what
you do is 'GNU with human face (instead of that goat ;-E )' . I guess
you agree that there's two distinguishable types of programmers: one,
"UNIXers/GNUers/NETters", can design really complex and general
system, but when proceed to implementation, do it so unconcernly.
Other, "hobbyists" (name is deceptive, we have these on most jobs
here) hardly can design something generally useful, but quite happy
digging little wholes such as clipping algorithms for GUI or parsing
algorithms. (I was that happy type before net acquiantance). What DJGPP
did is give latter the achievements of former, in really nice, and
moreover, acceptable for latter form. So, there result. IMHO
</quote>
So, my complaints are really whining of that second type, who
raised head and look around. I don't think, however, that being second
type is bad. Not everyone can design systems, but sometimes ability to
clean up after others may be useful too. My discomfort with GNU code
not concerned with naming conventions, indentation or languages used.
All that is really trivial. I mostly complain not about complexity,
but about overcomplicatedness. There're following I might emphasize:
1. Modularization style
2. Building system style
There exist two notions of what is 'module':
1. Approach of really modular languages (Modula, LISP, Perl, Python,
etc.). Module is self-containing peace of code featuring external
interface.
2. Primitive language approach - module is single compilation unit,
containing only self-containing "single feature" implementation. It
usually takes several such modules and header (external API) to make
something equivalent to (1)
It's really awful to see first approach applied to such languages
as C and C++, imho. Winsup is example of this awful approach. DJGPP's
lib is blessing example of (2) approach. But how it relies to developing
and contribution. Suppose I want to see how something's done in
winsup, to check and probably fix it. I see several large modules,
crawl over 'em until I get frightened of it. Suppose I don't give up
and do factor out problematic module by functionality. Suppose I find
problem place and fix it. What I get? Problem how to make it
submittable back. There's only one easy solution - put my code back
into mess, for other guy to complain later.
DJGPP example: I wanted to make gawk favor my local language. The best
approach is to make DJGPP support locales to extent I need (There's
possiblity for adhoc hack to gawk, but it's worse. For DJGPP.). From my
experience I know that there's arrays which to*() and is*() use. I
just lookup their names and write single module with setlocale()
there, it reloads those arrays from files depending on LANG settings.
I compile it by direct invocation of gcc.
Locale files I did in hex editor for conversion tables and hacked
ctype.c for ctypes. I tried to export data section from object with
objcopy, but noticed taht it allows import section, never export ;-)
No prob - I crop it in same hex editor.
I link gawk with setlocale module. It works. I put it into libc
(I haven't rebuild it, I even doesn't have sources of it). What I
get in result is source which looks exactly like rest of djgpp's
lib. I just have to check exceptional conditions and move it to
net-aware computer (hardest problem) to submit. DJ may reject it,
if he really so totalitarian as he told, but that's his problems,
and I have pleasure doing it (that moving will be hard, though).
CF> cgf
Best regards,
Paul mailto:paul-ml AT is DOT lg DOT ua
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com
- Raw text -