Curses for win32 with VT100/ANSI support

[Jordan Abel]

I'm not sure what you mean. I don't know what would be required to
change the current de facto policy, but I haven't seen any consensus
to change it.

What I mean is, is there a consensus to keep it? Or, perhaps more
importantly, was there a consensus to establish it?

 

[Richard Heathfield]

Jordan Abel said:

What I mean is, is there a consensus to keep it? Or, perhaps more
importantly, was there a consensus to establish it?

Bottom line - what do you want? A newsgroup where experts on standard C
freely give of their expertise to help people to learn more about it, or
would you prefer to disband that expertise? I doubt very much whether many
of our resident experts (the Toreks, Thompsons, Ambuhls, Kleins, Pfaffs,
etc) would stick around clc if it descended into a maelstrom of questions
about C#.NET, broken sockets programs, and so on.

If we want to discuss lcc-win32, there's already a newsgroup for that. If we
want to discuss Unix programming, there's already a group for that, too. If
we want to talk about Windows or C# or sockets, there are groups for those.
If we want to talk about future directions of the language, there's
comp.std.c for that.

Other than clc, what other unmoderated group exists where C people can talk
about C without the group being cluttered up with platform-specific stuff?
I don't know of one. Do you?

 

[Al Balmer]

What I mean is, is there a consensus to keep it? Or, perhaps more
importantly, was there a consensus to establish it?

A little time spent researching the archives would show you that such
a consensus exists among those who actually answer the questions here
;-)

We have an outstanding group of experts on tap. I'm grateful that they
donate their time and expertise, and don't want this group to turn
into a place they'll avoid.

 

[Chris Hills]

curses is a screen display, correct? So, unless I'm telnetting or
SSHing onto a system without a screen, curses is useless.

wrong again...

I stand corrected.

Not too far off; a system needs to communicate with the outside world

Many systems do not need to communicate with the outside world

in almost all cases, and since many systems lack a screen, having some
sort of network would be a logical choice.

Yes.... some sort of communication but not always a network.

What sort of network library did you have in mind?

I should have said *some* embedded systems, which I thought was implied
by not stating *all* embedded systems.

SO what sort of network library were you thinking of?

No, the C Standard specifies that small systems with limited space may
use a small subset of the standard library.

Ok.... so that's all right then... meanwhile back in the real world
things are different. the vast majority of the real world has ignored
the current C standard so quoting it is pointless.

That is true for everyone, no? ;-)

No. Some are far more limited than others.

 

[Jordan Abel]

Jordan Abel said:


Bottom line - what do you want? A newsgroup where experts on standard C
freely give of their expertise to help people to learn more about it, or
would you prefer to disband that expertise? I doubt very much whether many
of our resident experts (the Toreks, Thompsons, Ambuhls, Kleins, Pfaffs,
etc) would stick around clc if it descended into a maelstrom of questions
about C#.NET, broken sockets programs, and so on.

C# is not C. By most sane definitions, the language accepted by gcc
isn't "not C."

If we want to discuss lcc-win32, there's already a newsgroup for that. If we
want to discuss Unix programming, there's already a group for that, too. If
we want to talk about Windows or C# or sockets, there are groups for those.
If we want to talk about future directions of the language, there's
comp.std.c for that.

Other than clc, what other unmoderated group exists where C people can talk
about C without the group being cluttered up with platform-specific
stuff? I don't know of one. Do you?

Where would you have someone go to hear about how to write a header that
needs to support platform-specific stuff on multiple platforms? For
example, big-endian-to-host-endian conversion, or struct packing. Any
one platform-specific group is going to just say how to do it with
_their_ platform, and if you're lucky they'll also give you a tiny piece
of the #ifdef puzzle. Even then, it might be nice to have someone chime
in with an explanation of how to make it work with some platform you
haven't heard of and so didn't have in mind in advance.

 

[Al Balmer]

C# is not C. By most sane definitions, the language accepted by gcc
isn't "not C."


Where would you have someone go to hear about how to write a header that
needs to support platform-specific stuff on multiple platforms?

"How to write a header" and how to use the preprocessor to produce
different code for different defines (platforms) is topical here. The
details of tailoring specific code to specific processors is not.

For
example, big-endian-to-host-endian conversion, or struct packing.

Any
one platform-specific group is going to just say how to do it with
_their_ platform, and if you're lucky they'll also give you a tiny piece
of the #ifdef puzzle. Even then, it might be nice to have someone chime
in with an explanation of how to make it work with some platform you
haven't heard of and so didn't have in mind in advance.

Try comp.programming.

 

[Richard Heathfield]

Al Balmer said:

Try comp.programming.

In a way, the topic of comp.programming is even more limited than that of
comp.lang.c, insofar as discussions of specific /languages/ is, strictly
speaking, off-topic, let alone specific platforms.

 

[Skarmander]

SO there will be some OS specific parts of the code. The majority will
not be. Unless this NG is ONLY for pure portable ISO C99 code. As the NG
is not for that he can post here.

The answer to the OP's original question, "am I reinventing the wheel if I
implement a networked ncurses for Win32", is best answered elsewhere. Your
bold assertion that it has "bugger all to do with Windows" seems slightly
exaggerated.

There is no question that if the OP has questions specific to C (which isn't
necessarily "pure portable ISO C99 code", if only because pointing out
portability issues is just as relevant) then those questions can be posted here.

It's written in C which is what this NG is about.

Not that old chestnut again. Any algorithm can be expressed in C. If
therefore any algorithm expressed in C becomes topical, this newsgroup would
become a whole lot less useful, since the C experts would get fed up with
the volume of chaff and leave. A newsgroup where anything expressed in C is
topical is just not half as good as a newsgroup where the C programming
language is topical.

Wrong. but you are entitled to your opinion.

Thanks. You tolerating my opinion means a lot to me.

S.

 

[Richard Heathfield]

Jordan Abel said:

C# is not C.

Indeed. And neither are sockets, or GTK+, or Win32 API, etc.

By most sane definitions, the language accepted by gcc
isn't "not C."

Actually, the language accepted by gcc by default is /not/ C. Rather, it is
"GNU C", which is a very different animal.

Where would you have someone go to hear about how to write a header that
needs to support platform-specific stuff on multiple platforms?

As Al Balmer said, the C parts of such a discussion are topical. Groups
exist that provide support for specific platforms.

For
example, big-endian-to-host-endian conversion, or struct packing.

Implementations provide this kind of information in their documentation.

Any
one platform-specific group is going to just say how to do it with
_their_ platform, and if you're lucky they'll also give you a tiny piece
of the #ifdef puzzle. Even then, it might be nice to have someone chime
in with an explanation of how to make it work with some platform you
haven't heard of and so didn't have in mind in advance.

If there is sufficient demand for such a group, no doubt one will be
created. In the meantime, the absence of a newsgroup where <foo> is topical
does not ipso facto make it a good idea to make <foo> topical in
comp.lang.c.

 

[Jordan Abel]

"How to write a header" and how to use the preprocessor to produce
different code for different defines (platforms) is topical here. The
details of tailoring specific code to specific processors is not.

Is #ifdef __GNUC__ topical here? Regardless of the topicality of
anything in it.

 

[Al Balmer]

Al Balmer said:


In a way, the topic of comp.programming is even more limited than that of
comp.lang.c, insofar as discussions of specific /languages/ is, strictly
speaking, off-topic, let alone specific platforms.

True, according to its charter. In practice, though, discussions of
problems take place with respect to specific languages and platforms
all the time, and (probably more important) the range of available
expertise is not limited to specific topics. (Re-reading that, it's
not quite what I'm struggling to say, but the audience here will
understand ...).

In any case, Jordan is talking about issues which transcend a specific
platform, and I can't think of a better place.

 

[Jordan Abel]

Jordan Abel said:


Indeed. And neither are sockets, or GTK+, or Win32 API, etc.


Actually, the language accepted by gcc by default is /not/ C. Rather, it is
"GNU C", which is a very different animal.

Yours is an example of what I would not call a "sane definition"

I didn't say it was C. I said it wasn't "not C".

As Al Balmer said, the C parts of such a discussion are topical. Groups
exist that provide support for specific platforms.

Are the #ifdefs topical? Not the directive itself, but the discussion of
what constant identifies what set of platforms.

Implementations provide this kind of information in their
documentation.


If there is sufficient demand for such a group, no doubt one will be
created. In the meantime, the absence of a newsgroup where <foo> is topical
does not ipso facto make it a good idea to make <foo> topical in
comp.lang.c.

Where would you have them go?

 

[Walter Roberson]

Is #ifdef __GNUC__ topical here? Regardless of the topicality of
anything in it.

Yes, but there is very little to say about it here: we can say
that __GNUC__ is in the namespace reserved for any use, and we can
talk generally about what #ifdef means. But any instance in
which the #ifdef does not evaluate to false is implementation-
defined behaviour that is not on topic here.

 

[Walter Roberson]

Are the #ifdefs topical? Not the directive itself, but the discussion of
what constant identifies what set of platforms.

No, that is too implementation. The pre-defined macros depend
upon hardware, OS version, compiler version, applied patches, compiler
switches, and compiler extensions (e.g., a #pragma might result in
new predefined macros coming into effect.) The only way to discuss
and catalogue the possibilities would be to get into highly platform
dependant discussions.

Any question that requires reference to platform documentation for
resolution is off-topic here beyond the extent of establishing that
it is platform dependant.

 

[Keith Thompson]

Jordan Abel said: [...]
Actually, the language accepted by gcc by default is /not/ C. Rather, it is
"GNU C", which is a very different animal.

Yours is an example of what I would not call a "sane definition"

I didn't say it was C. I said it wasn't "not C".

Perhaps you'd care to explain that. Logically, everything in the
universe is exactly one of "C" or "not C".

[...]

Where would you have them go?

To a newsgroup or other forum where it's topical. If there isn't one,
how is that our problem?

 

[CBFalconer]

.... snip ...

"How to write a header" and how to use the preprocessor to produce
different code for different defines (platforms) is topical here. The
details of tailoring specific code to specific processors is not.



Try comp.programming.

Please don't. That is more for algorithms than system specific
stuff, although the denizens are quite tolerant. Get the specific
requirements from the system specific newsgroups, and integrate
into your isolated non-portable source modules.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>

 

[Mark McIntyre]

What I mean is, is there a consensus to keep it? Or, perhaps more
importantly, was there a consensus to establish it?

Oh gawd, here we go again .

Boring, boring boring.

*threadplonk*

--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[Andrew Poelstra]

wrong again...

That curses is a screen display, or that you need a screen to use a
screen display?

Many systems do not need to communicate with the outside world

Please give an example, because if a system never communicates, it is
for all intents and purposes a rock.

Yes.... some sort of communication but not always a network.

What sort of network library did you have in mind?

Something similar to stdio.h, I suppose. Or an extension of stdio.

FILE *sh = fopen("192.168.0.100", "n");
fprintf(sh, "Hello, other machine!\n");

You might suggest that not all networks use IP, but not all systems
use the same filesystem (and indeed there is much more diversity
there), and yet fopen for files is standardized. My first
statement is just as portable as fopen("/etc/hosts", "r").

Ok.... so that's all right then... meanwhile back in the real world
things are different. the vast majority of the real world has ignored
the current C standard so quoting it is pointless.

Refuting the credibility of the C standard on clc is not a very good
idea. ;-)

No. Some are far more limited than others.

The truthhood of a statement is binary; either a person is very
limited or they are not. While your second statement is true,
the first ("No.") is not logically connected to it.

 

[Jordan Abel]

Jordan Abel said: [...]
Actually, the language accepted by gcc by default is /not/ C. Rather, it is
"GNU C", which is a very different animal.

Yours is an example of what I would not call a "sane definition"

I didn't say it was C. I said it wasn't "not C".

Perhaps you'd care to explain that. Logically, everything in the
universe is exactly one of "C" or "not C".

The phrase has a meaning which goes beyond the simple logical analysis
of the words. I'd say that for something to be "not C" it requires
a level of difference that mere addition of extra library functions,
a few extra reserved keywords, some more pre-defined macros, and
a bizarre mixture of c89 and c99, can provide. All of them (except a few
of the predefined macros in question) are permitted by the standard.

Those few predefined macros, like unix=1, are the ones that are possibly
the _most_ topical in here precisely _because_ you can run into
a problem compiling a strictly conforming program. In fact, those,
I think are actually on-topic, because

Queries on how to write something in C
Queries about why some C code behaves the way it does
Suggestions for C modifications or extensions
C coding "tricks"
Compiler bugs
Availability of compilers
etc.

I'd say that it falls under "compiler bugs" in a way that still applies
in the modern incarnation of what's appropriate.

 

[pete]

"not C"

Godwin's Law: The thread is over.