Hi guys.
It's been a while since I've done programming in C. What I'm after is a
multi-platform library (X11 and MS Windows at a minimum) which is not
C++ that will let me program GUI apps. Something simple and straight
forward to work with; ideally, open source.
Any suggestions?
--
An Aussie Looking Glass for traceroute, DNS, etc? http://lg.autons.net/ 17  2479 
Synic wrote:
Hi guys.
It's been a while since I've done programming in C. What I'm after is a
multi-platform library (X11 and MS Windows at a minimum) which is not
C++ that will let me program GUI apps. Something simple and straight
forward to work with; ideally, open source.
Any suggestions?
http://www.libsdl.org/index.php
might be one possibility...
Stephen
"Stephen L." <sd*********@cast-com.net> wrote in message news:40***************@cast-com.net... Synic wrote:
Hi guys.
It's been a while since I've done programming in C. What I'm after is a
multi-platform library (X11 and MS Windows at a minimum) which is not
C++ that will let me program GUI apps. Something simple and straight
forward to work with; ideally, open source.
Any suggestions?
http://www.libsdl.org/index.php
might be one possibility...
Stephen http://sourceforge.net/projects/dosgui/ could be another.
Emmanuel Delahaye <em**********@noos.fr> wrote: In 'comp.lang.c', Synic <fl**********@nhgbaf.arg.nh> wrote: It's been a while since I've done programming in C. What I'm after is a
multi-platform library (X11 and MS Windows at a minimum) which is not
C++ that will let me program GUI apps. Something simple and straight
forward to work with; ideally, open source.
It's off topic here. Hints:
SDL
OpenGL
Neither's really a X11/MS Windows GUI library though; more 3D graphics
libraries.
gtk+/Gnome
I was under the impression GTK's C++. I'll check on that.
Don't ask here for details.
C library questions seem to be common here, along with demands for them
to stop. I'm surprised nobody's gotten around to creating a
comp.lang.c.libs group to give people an alternative for these sort of
queries. What's been the barrier?
--
Need Australian Secondary DNS? http://secdns.autons.net/
In article <sl*************************@lark.autons.net.au> ,
fl**********@nhgbaf.arg.nh says... Emmanuel Delahaye <em**********@noos.fr> wrote: Don't ask here for details.
C library questions seem to be common here, along with demands for them
to stop. I'm surprised nobody's gotten around to creating a
comp.lang.c.libs group to give people an alternative for these sort of
queries. What's been the barrier?
The main barrier seems to be people not willing to read the FAQ, which
is common practice for those with knowledge of Usenet and its practices.
Since you seem to be unaware of its location, try this link: http://www.eskimo.com/~scs/C-faq/top.html
--
Randy Howard (2reply remove FOOBAR)
On Mon, 31 May 2004 18:38:21 +0800, Synic wrote: Hi guys.
It's been a while since I've done programming in C. What I'm after is a
multi-platform library (X11 and MS Windows at a minimum) which is not
C++ that will let me program GUI apps. Something simple and straight
forward to work with; ideally, open source.
Any suggestions?
Gtk+ 2.x www.gtk.org for downloads/tutorials.
Randy Howard <ra*********@FOOverizonBAR.net> wrote: In article <sl*************************@lark.autons.net.au> ,
fl**********@nhgbaf.arg.nh says... Emmanuel Delahaye <em**********@noos.fr> wrote: > Don't ask here for details.
C library questions seem to be common here, along with demands for them
to stop. I'm surprised nobody's gotten around to creating a
comp.lang.c.libs group to give people an alternative for these sort of
queries. What's been the barrier?
The main barrier seems to be people not willing to read the FAQ, which
is common practice for those with knowledge of Usenet and its practices.
Since you seem to be unaware of its location, try this link:
http://www.eskimo.com/~scs/C-faq/top.html
Nup. Nothing in that FAQ points me to other groups to ask C library
questions in. Perhaps that's why your group's continually beseiged by
these questions.
Since there's been no barrier to the creation of a group, I'm writing up
an RFD proposal. I've created two other groups (in the aus.* heirarchy)
with a similar formalised creation procedure to comp.*.
An early draft version of the charter is here:
2. Charter
This newsgroup is for discussion of issues relating to C libraries,
toolkits and other add-ons to the C language which may not be
considered "on-topic" for the pure C language group.
Examples of on-topic discussion includes:
* Which C library to choose for tasks,
* Changes to C structure which might affect libraries,
* Costs and benefits of different libraries on a technical basis,
* How to use common libraries,
* Porting of useful features and functions from other languages
to be used with C in libraries.
* Any other issue which is C related but unwelcome in
comp.lang.c.
Examples of off-topic discussion include:
* Which C++ library to choose for tasks.
* Which modules would be great to use with Perl, PHP or Python.
Some caveats for online behaviour exist:
* comp.lang.c.libs is a text-only discussion group. If what you
have to say absolutely requires HTML, text encoding or
binaries, posters should direct their potential readers to a
URL which contains these things.
* Advertising is not allowed in the body of messages to this
newsgroup. A standard four line .signature has more than enough
room to alert readers to your company and its services.
* Be aware that some participants will consider comp.lang.c.libs
more "real world" than others. The onus is on comp.lang.c.libs
users to recognize that libel laws exist. Ad hominem attacks
are discouraged.
* Cross-posting to flame-filled newsgroups is also discouraged.
comp.lang.c.libs explicitly welcomes the use of binary message
cancelers and anti-spam cancelers which apply a Breidbart Index
threshold of 3. Info on how the BI is calculated is in the
"Breidbart Index (BI) Definition" document currently at http:// www.stopspam.org/usenet/mmf/breidbart.html
It's been largely boiler-plated from the charter of aus.business. If
there are (useful) comments, suggestions or objections, now's the
best time to put them.
If there are good reasons why comp.lang.c.libs should not be created,
now's also the best time to put them.
--
Need Australian Mail Exchange (MX) hosting? http://mx.autons.net/
Synic <fl**********@nhgbaf.arg.nh> wrote: Randy Howard <ra*********@FOOverizonBAR.net> wrote: The main barrier seems to be people not willing to read the FAQ, which
is common practice for those with knowledge of Usenet and its practices.
Since you seem to be unaware of its location, try this link:
http://www.eskimo.com/~scs/C-faq/top.html
Nup. Nothing in that FAQ points me to other groups to ask C library
questions in. Perhaps that's why your group's continually beseiged by
these questions.
Since there's been no barrier to the creation of a group, I'm writing up
an RFD proposal. I've created two other groups (in the aus.* heirarchy)
with a similar formalised creation procedure to comp.*.
An early draft version of the charter is here:
2. Charter
This newsgroup is for discussion of issues relating to C libraries,
toolkits and other add-ons to the C language which may not be
considered "on-topic" for the pure C language group.
Examples of on-topic discussion includes:
* Which C library to choose for tasks,
* Changes to C structure which might affect libraries,
* Costs and benefits of different libraries on a technical basis,
* How to use common libraries,
* Porting of useful features and functions from other languages
to be used with C in libraries.
* Any other issue which is C related but unwelcome in
comp.lang.c.
I'd advise against this last point; you'll be inundated with POSIX- and
M$VC++-specific questions.
Examples of off-topic discussion include:
* Which C++ library to choose for tasks.
* Which modules would be great to use with Perl, PHP or Python.
I'd add strictly system-specific discussions, as well, since they're
better held on system-dedicated newsgroups. E.g.:
* How to code something using POSIX, or using the MS Windows API.
Some caveats for online behaviour exist:
* comp.lang.c.libs is a text-only discussion group. If what you
have to say absolutely requires HTML, text encoding or
binaries, posters should direct their potential readers to a
URL which contains these things.
* Advertising is not allowed in the body of messages to this
newsgroup. A standard four line .signature has more than enough
room to alert readers to your company and its services.
* Be aware that some participants will consider comp.lang.c.libs
more "real world" than others. The onus is on comp.lang.c.libs
users to recognize that libel laws exist. Ad hominem attacks
are discouraged.
* Cross-posting to flame-filled newsgroups is also discouraged.
comp.lang.c.libs explicitly welcomes the use of binary message
cancelers and anti-spam cancelers which apply a Breidbart Index
threshold of 3.
I'm not sure that this is a good idea, either; third-party canceling is
a hairy issue which should not and need not be fought on a newsgroup
level, but by the owners of news servers (for whom it is easier to
simply dump binary posts to non-binary groups anyway, as the last three
I've used all do already - I presume the same thing is true for multi-
and cross-posts).
If there are good reasons why comp.lang.c.libs should not be created,
now's also the best time to put them.
On the contrary. Unlike earlier suggestions of this ilk, this one
actually seems a good idea to me, with the few exceptions I've noted.
Richard
Richard Bos <rl*@hoekstra-uitgeverij.nl> wrote: Synic <fl**********@nhgbaf.arg.nh> wrote: * Any other issue which is C related but unwelcome in
comp.lang.c.
I'd advise against this last point; you'll be inundated with POSIX- and
M$VC++-specific questions.
M$VC++-specific questions would be out because they're C++ anyway :-).
POSIX- related questions would probably be on topic. If it's not
strictly C, then it'll likely be a library somewhere.
In this sense, I'd rather see comp.lang.c.libs be a much more
inclusive group than comp.lang.c and more open to general chat.
A very different character to complement comp.lang.c rather than
ape it.
Examples of off-topic discussion include:
* Which C++ library to choose for tasks.
* Which modules would be great to use with Perl, PHP or Python.
I'd add strictly system-specific discussions, as well, since they're
better held on system-dedicated newsgroups. E.g.:
A good point, but, there's still the argument that system specific stuff
is just another library or incompatibility ripe for discussion.
That said, I agree that it's a good idea for something like "It is
recommended that system-specific discussions are better held on
system-dedicated newsgroups. E.g.: [...]" to be added to the Caveats
section. More a sound suggestion than a dictate.
* How to code something using POSIX, or using the MS Windows API.
The MS Windows API is really just a set of libraries. If/where there
are C functions (rather than C++ ones), discussion of these would be
fine, with recommendations that other groups will have more detailed
info which is not limited to the C language. comp.lang.c.libs explicitly welcomes the use of binary message
cancelers and anti-spam cancelers which apply a Breidbart Index
threshold of 3.
I'm not sure that this is a good idea, either; third-party canceling is
a hairy issue which should not and need not be fought on a newsgroup
level, but by the owners of news servers (for whom it is easier to
simply dump binary posts to non-binary groups anyway, as the last three
I've used all do already - I presume the same thing is true for multi-
and cross-posts).
In practice, third-party canceling hasn't been done yet on aus.business.
However, it's been a great morale booster there for the recommendation
to exist. It also ensures that spammers can be duly larted since the
anti-spam stance is so clear in the charter.
Also, in practice, the kill/resurrect pattern you see where these wars
hot up also generally see crosspostings retained. So crossposted
kills/resurrects still won't be seen if you limit crossposts with your
own server software.
There's a fair bit more info on the Breidbart Index in the RFD draft for
anyone curious. If there are good reasons why comp.lang.c.libs should not be created,
now's also the best time to put them.
On the contrary. Unlike earlier suggestions of this ilk, this one
actually seems a good idea to me, with the few exceptions I've noted.
Thanks for the vote of confidence :-).
I've put up the RFD draft at http://clcl.autons.net/. It'll no doubt see
some modification as comments are made here.
--
In WA and don't trust the kids with the car? http://walp.autons.net/
Synic <fl**********@nhgbaf.arg.nh> wrote in message news:<sl*************************@lark.autons.net. au>... Richard Bos <rl*@hoekstra-uitgeverij.nl> wrote: Synic <fl**********@nhgbaf.arg.nh> wrote: * Any other issue which is C related but unwelcome in
comp.lang.c.
I'd advise against this last point; you'll be inundated with POSIX- and
M$VC++-specific questions.
M$VC++-specific questions would be out because they're C++ anyway :-).
POSIX- related questions would probably be on topic. If it's not
strictly C, then it'll likely be a library somewhere.
In this sense, I'd rather see comp.lang.c.libs be a much more
inclusive group than comp.lang.c and more open to general chat.
A very different character to complement comp.lang.c rather than
ape it.
Examples of off-topic discussion include:
* Which C++ library to choose for tasks.
* Which modules would be great to use with Perl, PHP or Python.
I'd add strictly system-specific discussions, as well, since they're
better held on system-dedicated newsgroups. E.g.:
A good point, but, there's still the argument that system specific stuff
is just another library or incompatibility ripe for discussion.
That said, I agree that it's a good idea for something like "It is
recommended that system-specific discussions are better held on
system-dedicated newsgroups. E.g.: [...]" to be added to the Caveats
section. More a sound suggestion than a dictate.
* How to code something using POSIX, or using the MS Windows API.
The MS Windows API is really just a set of libraries. If/where there
are C functions (rather than C++ ones), discussion of these would be
fine, with recommendations that other groups will have more detailed
info which is not limited to the C language.
comp.lang.c.libs explicitly welcomes the use of binary message
cancelers and anti-spam cancelers which apply a Breidbart Index
threshold of 3.
I'm not sure that this is a good idea, either; third-party canceling is
a hairy issue which should not and need not be fought on a newsgroup
level, but by the owners of news servers (for whom it is easier to
simply dump binary posts to non-binary groups anyway, as the last three
I've used all do already - I presume the same thing is true for multi-
and cross-posts).
In practice, third-party canceling hasn't been done yet on aus.business.
However, it's been a great morale booster there for the recommendation
to exist. It also ensures that spammers can be duly larted since the
anti-spam stance is so clear in the charter.
Also, in practice, the kill/resurrect pattern you see where these wars
hot up also generally see crosspostings retained. So crossposted
kills/resurrects still won't be seen if you limit crossposts with your
own server software.
There's a fair bit more info on the Breidbart Index in the RFD draft for
anyone curious.
If there are good reasons why comp.lang.c.libs should not be created,
now's also the best time to put them.
On the contrary. Unlike earlier suggestions of this ilk, this one
actually seems a good idea to me, with the few exceptions I've noted.
Thanks for the vote of confidence :-).
I've put up the RFD draft at http://clcl.autons.net/. It'll no doubt see
some modification as comments are made here.
Sounds like a good idea to me.
A possible way to stop POSIX and MS Win32 related traffic is to have
specific rules saying for example "Questions about POSIX libraries
should be directed to ...".
On Tue, 01 Jun 2004 20:44:47 +0800, Synic wrote: Richard Bos <rl*@hoekstra-uitgeverij.nl> wrote: Synic <fl**********@nhgbaf.arg.nh> wrote: * Any other issue which is C related but unwelcome in
comp.lang.c.
I'd advise against this last point; you'll be inundated with POSIX- and
M$VC++-specific questions.
M$VC++-specific questions would be out because they're C++ anyway :-).
You'd be surprised how few people can tell the difference.
POSIX- related questions would probably be on topic. If it's not
strictly C, then it'll likely be a library somewhere.
Why would you want to cover POSIX when comp.unix.programmer does such a
good job of that already?
Besides, not all POSIX stuff will be on-topic. POSIX defines the standard
command line syntax and some of the standard file locations, among other
things not related to C at all. comp.unix.programmer knows about this
stuff; will you? Will anyone in your group?
In this sense, I'd rather see comp.lang.c.libs be a much more
inclusive group than comp.lang.c and more open to general chat.
General chat devolves into pure noise, and knowledgeable people tend to
dislike pure noise. The comp.* hierarchy is usually held to a higher
standard than alt.* or soc.*.
A very different character to complement comp.lang.c rather than
ape it.
I think comp.lang.c is is the way it is for a reason, and you should
understand it before you try to make your own newsgroup.
Examples of off-topic discussion include:
* Which C++ library to choose for tasks.
* Which modules would be great to use with Perl, PHP or Python.
I'd add strictly system-specific discussions, as well, since they're
better held on system-dedicated newsgroups. E.g.:
A good point, but, there's still the argument that system specific stuff
is just another library or incompatibility ripe for discussion.
Again, most people who know about a specific system's stuff will most
likely be in newsgroups devoted to that system, not in comp.lang.c.libs.
Getting knowledgeable people to devote time to a new group will be hard.
That said, I agree that it's a good idea for something like "It is
recommended that system-specific discussions are better held on
system-dedicated newsgroups. E.g.: [...]" to be added to the Caveats
section. More a sound suggestion than a dictate.
On Usenet, you have two tools: Sound suggestions and killfiles. Until
someone writes a client that recognizes X-Kill-Reader: [method], that's
all we've got.
* How to code something using POSIX, or using the MS Windows API.
The MS Windows API is really just a set of libraries. If/where there
are C functions (rather than C++ ones), discussion of these would be
fine, with recommendations that other groups will have more detailed
info which is not limited to the C language.
All APIs are just libraries, at least as far as the userland program is
concerned. This is one reason I think clc.libs will fail: It will attract
a host of system-specific questions but not necessarily any
system-specific expertise.
comp.lang.c.libs explicitly welcomes the use of binary message
cancelers and anti-spam cancelers which apply a Breidbart Index
threshold of 3.
I'm not sure that this is a good idea, either; third-party canceling is
a hairy issue which should not and need not be fought on a newsgroup
level, but by the owners of news servers (for whom it is easier to
simply dump binary posts to non-binary groups anyway, as the last three
I've used all do already - I presume the same thing is true for multi-
and cross-posts).
In practice, third-party canceling hasn't been done yet on aus.business.
However, it's been a great morale booster there for the recommendation
to exist. It also ensures that spammers can be duly larted since the
anti-spam stance is so clear in the charter.
Third-party canceling is, in my view, Bad and Wrong. It opens the
floodgates for abuse on a simply unprecedented level. I don't want to
subscribe to servers that honor such beasts, and I certainly don't want to
read groups where it's explicitly welcomed.
Also, in practice, the kill/resurrect pattern you see where these wars
hot up also generally see crosspostings retained. So crossposted
kills/resurrects still won't be seen if you limit crossposts with your
own server software.
There's a fair bit more info on the Breidbart Index in the RFD draft for
anyone curious.
The BI is well and good for spam-control, but I think it should be up to
server admins to do it, not vigilantes with explicit liberty to cancel
posts at random. The server admins feel the financial pain from spam,
since they own the machines spam pollutes most heavily, and they should
be given the reigns when it comes to controlling it.
If there are good reasons why comp.lang.c.libs should not be created,
now's also the best time to put them.
On the contrary. Unlike earlier suggestions of this ilk, this one
actually seems a good idea to me, with the few exceptions I've noted.
Thanks for the vote of confidence :-).
I'd think it would be a good idea if I wasn't convinced of its failure.
Not exactly a vote of confidence, but you'll hear worse if this isn't
completely ignored.
I've put up the RFD draft at http://clcl.autons.net/. It'll no doubt see
some modification as comments are made here.
--
yvoregnevna gjragl-guerr gjb-gubhfnaq guerr ng lnubb qbg pbz
To email me, rot13 and convert spelled-out numbers to numeric form.
"Makes hackers smile" makes hackers smile.
August Derleth <se*@sig.now> wrote: POSIX- related questions would probably be on topic. If it's not
strictly C, then it'll likely be a library somewhere.
Why would you want to cover POSIX when comp.unix.programmer does such a
good job of that already?
However, there may be useful discussion involving libraries which
provide POSIX compatibilities to otherwise non-compliant OSes. I'm not
convinced there's a reason to explicitly recommend against discussing
these sorts of libraries because of their functionality.
Besides, not all POSIX stuff will be on-topic. POSIX defines the standard
command line syntax and some of the standard file locations, among other
things not related to C at all. comp.unix.programmer knows about this
stuff; will you? Will anyone in your group?
Thus the recommendation that system-specific queries go to system
specific groups is the good way to go. If posters follow that, great.
If they don't, they reap the reward of someone telling them they'd be
better off asking in whichever is more appropriate.
In this sense, I'd rather see comp.lang.c.libs be a much more
inclusive group than comp.lang.c and more open to general chat.
General chat devolves into pure noise, and knowledgeable people tend to
dislike pure noise. The comp.* hierarchy is usually held to a higher
standard than alt.* or soc.*.
Wasn't quite meaning alt.* or soc.* type "general chat" there.
A very different character to complement comp.lang.c rather than
ape it.
I think comp.lang.c is is the way it is for a reason, and you should
understand it before you try to make your own newsgroup.
What works with one group does not work for all. Ideally, the plan is
for the clc purists to keep clc. People who use libraries and want to
discuss getting things to work in wierd and wacky environments and
across disparate platforms, use clcl and perhaps move off to system
specific groups if discussion goes that way.
Some on clc would never be seen on clcl. I'm also of the opinion that
there may be some on clc who will welcome the chance to jump ship to a
group where every fourth article isn't someone saying "not strictly on
topic, go away" in response to questions relating to C programming :-).
Again, most people who know about a specific system's stuff will most
likely be in newsgroups devoted to that system, not in comp.lang.c.libs.
Getting knowledgeable people to devote time to a new group will be hard.
By all means, people can be refered to other groups if their discussion
will be better served there.
All APIs are just libraries, at least as far as the userland program is
concerned. This is one reason I think clc.libs will fail: It will attract
a host of system-specific questions but not necessarily any
system-specific expertise.
System specific expertise isn't required. It's not a strictly system
specific group. Want to talk about GTK? clcl. Programming with ncurses?
clcl. Which is a good cross-platform GUI library? clcl.
Third-party canceling is, in my view, Bad and Wrong. It opens the
floodgates for abuse on a simply unprecedented level. I don't want to
subscribe to servers that honor such beasts, and I certainly don't want to
read groups where it's explicitly welcomed.
The BI is strictly about repetitive postings (spam) and overly large
crossposts (spam and pests). That's pretty much it.
The BI is well and good for spam-control, but I think it should be up to
server admins to do it, not vigilantes with explicit liberty to cancel
posts at random.
Not at random.
Q: How does the Breidbart Index (BI) work?
A: The BI is defined as the sum of the square roots of n (where n is
the number of newsgroups each copy was posted to, over a 45 day
period). The standard BI threshold in protected groups on Usenet is
20. The people in the Netherlands nl.* hierarchy have apparently gone
with 8.
Example: If two copies of a posting are made, one to 9 groups,
and one to 16, the BI index is sqrt(9)+sqrt(16) = 3+4 = 7.
Example: If three copies of a posting are made, two to one group
each and the third to 3 groups, the BI index is sqrt(1)+sqrt(1)
+sqrt(3) = 1+1+1.73 = 3.73.
Example: One posting is cross-posted to 9 groups, the BI index is
sqrt(9) = 3 = 3.
Many news servers will have already culled articles cross-posted to 8
or more newsgroups just on principle :-). Recommending a BI threshold
of 3 is a very aggressive anti-spam posture. The calculation of BI
levels is discussed in more detail at http://www.stopspam.org/usenet/
mmf/breidbart.html
Genuine postings are never going to be hit by the Breidbart Index at 3.
Now clcl could easily adopt a less aggressive anti-spam posture to
aus.business if people really want. It'd be embarrassing, but hey. I'm
ready to be convinced by the hoards :-).
The server admins feel the financial pain from spam,
since they own the machines spam pollutes most heavily, and they should
be given the reigns when it comes to controlling it.
There's nothing stopping them from keeping the reigns. With most news
server software, you can happily ignore cancels and even block reposts.
Can't say any of that's been relevant or needed for aus.business up to
this point or for the Netherlands nl.* hierarchy, to my knowledge.
I'd think it would be a good idea if I wasn't convinced of its failure.
Not exactly a vote of confidence, but you'll hear worse if this isn't
completely ignored.
Thanks for the feedback. I've put up the RFD draft at http://clcl.autons.net/. It'll no doubt see
some modification as comments are made here.
--
So, you think you know your Aussie slang? http://ausslang.autons.net/
Synic <fl**********@nhgbaf.arg.nh> wrote: Richard Bos <rl*@hoekstra-uitgeverij.nl> wrote: Synic <fl**********@nhgbaf.arg.nh> wrote: * Any other issue which is C related but unwelcome in
comp.lang.c.
I'd advise against this last point; you'll be inundated with POSIX- and
M$VC++-specific questions.
M$VC++-specific questions would be out because they're C++ anyway :-).
M$VC++ can be used to compile C as well, AFAIAA. Even so, you'll get
your share of VC++ questions as much as c.l.c does.
POSIX- related questions would probably be on topic. If it's not
strictly C, then it'll likely be a library somewhere.
If it _is_ strictly C, it's also likely to be in a library somewhere:
libc, glibc, libmath, whateverVCcallsit.lib, and so forth.
In this sense, I'd rather see comp.lang.c.libs be a much more
inclusive group than comp.lang.c and more open to general chat.
In that case, your group will succumb under the weight of the POSIX-only
and M$VC-only rubble, which would be better answered on POSIX and M$
newsgroups in the first place.
* How to code something using POSIX, or using the MS Windows API.
The MS Windows API is really just a set of libraries.
That's no argument. The same thing is true of _all_ functions a C
implementation provides, whether they are Standard or not.
comp.lang.c.libs explicitly welcomes the use of binary message
cancelers and anti-spam cancelers which apply a Breidbart Index
threshold of 3.
I'm not sure that this is a good idea, either; third-party canceling is
a hairy issue which should not and need not be fought on a newsgroup
level, but by the owners of news servers (for whom it is easier to
simply dump binary posts to non-binary groups anyway, as the last three
I've used all do already - I presume the same thing is true for multi-
and cross-posts).
In practice, third-party canceling hasn't been done yet on aus.business.
However, it's been a great morale booster there for the recommendation
to exist.
Not to me, it isn't. Third-party canceling is infinitely abusable, and I
wouldn't post anywhere where I ran a serious risk of having my posts
canceled by anyone but me. Luckily, AFAIK news.individual.net does not
honour third-party cancels, and that is as it should be.
It also ensures that spammers can be duly larted since the
anti-spam stance is so clear in the charter.
If you think Usenet works like that, think again.
Also, in practice, the kill/resurrect pattern you see where these wars
hot up also generally see crosspostings retained. So crossposted
kills/resurrects still won't be seen if you limit crossposts with your
own server software.
Huh? Sorry, but that just doesn't seem to relate to anything.
There's a fair bit more info on the Breidbart Index in the RFD draft for
anyone curious.
Discussions of one person's opinions on spam canceling do not belong in
an RFD - _certainly_ not when that one person takes a stance as extreme
as yours. BI of _three_? Good grief.
Richard
In article <sl*************************@lark.autons.net.au> ,
fl**********@nhgbaf.arg.nh says... Randy Howard <ra*********@FOOverizonBAR.net> wrote: In article <sl*************************@lark.autons.net.au> ,
fl**********@nhgbaf.arg.nh says... Emmanuel Delahaye <em**********@noos.fr> wrote:
> Don't ask here for details.
C library questions seem to be common here, along with demands for them
to stop. I'm surprised nobody's gotten around to creating a
comp.lang.c.libs group to give people an alternative for these sort of
queries. What's been the barrier?
The main barrier seems to be people not willing to read the FAQ, which
is common practice for those with knowledge of Usenet and its practices.
Since you seem to be unaware of its location, try this link:
http://www.eskimo.com/~scs/C-faq/top.html
Nup. Nothing in that FAQ points me to other groups to ask C library
questions in. Perhaps that's why your group's continually beseiged by
these questions.
It does, but not by name. (See section 19 for the most applicable ones).
You'll note that newsgroup names change over time. Also, most respondents
when asked a question like "Where can I find out how to program using
multiple threads in C?" will get a brief answer such as:
"comp.programming.threads" would be a very good choice."
from one of the regulars here. I don't see a problem with that.
Problems about libraries are usually answered in a similar fashion, but
not discussed at length in this group. www.sf.net is the canonical place
to find such information anyway.
Since there's been no barrier to the creation of a group, I'm writing up
an RFD proposal.
Congratulations.
--
Randy Howard (2reply remove FOOBAR)
"The most amazing achievement of the computer software industry is its
continuing cancellation of the steady and staggering gains made by the
computer hardware industry..." - Henry Petroski
Rob Thorpe <ro***********@antenova.com> wrote: I've put up the RFD draft at http://clcl.autons.net/. It'll no doubt see
some modification as comments are made here.
Sounds like a good idea to me.
:-)
A possible way to stop POSIX and MS Win32 related traffic is to have
specific rules saying for example "Questions about POSIX libraries
should be directed to ...".
I'd rather leave that to a clcl "Welcome and Newsgroup FAQ", posted on
the 1st and the 15th of each month, rather than the charter per se. It's
much easier to update a regular Welcome posting with changes as needed.
--
So, you think you know your Aussie slang? http://ausslang.autons.net/
Richard Bos <rl*@hoekstra-uitgeverij.nl> wrote: Synic <fl**********@nhgbaf.arg.nh> wrote: Richard Bos <rl*@hoekstra-uitgeverij.nl> wrote: > Synic <fl**********@nhgbaf.arg.nh> wrote:
>> * Any other issue which is C related but unwelcome in
>> comp.lang.c.
>
> I'd advise against this last point; you'll be inundated with POSIX- and
> M$VC++-specific questions.
M$VC++-specific questions would be out because they're C++ anyway :-).
M$VC++ can be used to compile C as well, AFAIAA. Even so, you'll get
your share of VC++ questions as much as c.l.c does.
If they're compiling C, then great. Entirely on topic.
VC++ can be redirected elsewhere or ignored. Same as they would be in
any group.
POSIX- related questions would probably be on topic. If it's not
strictly C, then it'll likely be a library somewhere.
If it _is_ strictly C, it's also likely to be in a library somewhere:
libc, glibc, libmath, whateverVCcallsit.lib, and so forth.
Yup.
In this sense, I'd rather see comp.lang.c.libs be a much more
inclusive group than comp.lang.c and more open to general chat.
In that case, your group will succumb under the weight of the POSIX-only
and M$VC-only rubble, which would be better answered on POSIX and M$
newsgroups in the first place.
You seem to have made up your mind on this. Personally, I don't see the
drama. clcl isn't meant to be a clone of clc and frankly I don't see the
world coming to a grinding halt if C libraries are discussed which might
be platform specific or not.
If it's a C library, it would be on topic for clcl (not clc). We're not
talking about changes to clc at all here. If anything, clcl should help
to reduce the load for clc by providing an alternative place that allows
discussions that clc doesn't want and the purists find offensive.
> * How to code something using POSIX, or using the MS Windows API.
The MS Windows API is really just a set of libraries.
That's no argument. The same thing is true of _all_ functions a C
implementation provides, whether they are Standard or not.
Yup.
Not to me, it isn't. Third-party canceling is infinitely abusable, and I
wouldn't post anywhere where I ran a serious risk of having my posts
canceled by anyone but me. Luckily, AFAIK news.individual.net does not
honour third-party cancels, and that is as it should be.
If you're crossposting to nine groups at once or repeatedly posting the
same article, you should expect people to find this annoying. If you're
not, it's unlikely you'll be affected at all and this not at "serious
risk". It also ensures that spammers can be duly larted since the
anti-spam stance is so clear in the charter.
If you think Usenet works like that, think again.
Many ISPs out there like to have proof that advertising is "off-topic"
in a Usenet group before they'll act. An anti-spam charter demonstrates
that.
[...] There's a fair bit more info on the Breidbart Index in the RFD draft for
anyone curious.
Discussions of one person's opinions on spam canceling do not belong in
an RFD - _certainly_ not when that one person takes a stance as extreme
as yours. BI of _three_? Good grief.
A charter is where general points are made about what is acceptable on a
newsgroup. This extends to whether the group accepts advertising,
HTML formatting, binary encoding, etc. A point on the policy by which
a group welcomes message cancelling fits in there.
This is from the Welcome draft not the RFD, btw:
Q: How does the Breidbart Index (BI) work?
A: The BI is defined as the sum of the square roots of n (where n
is the number of newsgroups each copy was posted to, over a 45 day
period). The standard BI threshold in protected groups on Usenet is
20. The people in the Netherlands nl.* hierarchy have apparently
gone with 8.
Example: If two copies of a posting are made, one to 9 groups,
and one to 16, the BI index is sqrt(9)+sqrt(16) = 3+4 = 7.
Example: If three copies of a posting are made, two to one
group each and the third to 3 groups, the BI index is sqrt(1)
+sqrt(1)+sqrt(3) = 1+1+1.73 = 3.73.
Example: One posting is cross-posted to 9 groups, the BI index
is sqrt(9) = 3 = 3.
Many news servers will have already culled articles cross-posted to
8 or more newsgroups just on principle :-). Recommending a BI
threshold of 3 is a very aggressive anti-spam posture. The
calculation of BI levels is discussed in more detail at http:// www.stopspam.org/usenet/mmf/breidbart.html
If the BI issue is felt likely to trap too many posters who like to
crosspost excessively or repeatedly spam the new group, then I have no
particular objections to raising it to 8 or 20 or removing it entirely
to nullify it as an issue.
At this stage though, I can't see any technical way that a BI of 3
would inhibit someone who is posting in any normal way to a newsgroup.
If you can find any non-spam article in your current spool for clc
that matches the criteria of a BI of 3, I'll be mighty surprised.
(As always, the draft of the RFD is at http://clcl.autons.net/ for the
perusal of all interested parties. Comments and queries welcome.)
--
Need Australian Mail Exchange (MX) hosting? http://mx.autons.net/
Synic wrote:
.... snip ...
If you're crossposting to nine groups at once or repeatedly
posting the same article, you should expect people to find this
annoying. If you're not, it's unlikely you'll be affected at all
and this not at "serious risk".
If you are crossposting to three groups, and failing to set
followups to cut it back to one, you are a serious annoyance.
--
fix (vb.): 1. to paper over, obscure, hide from public view; 2.
to work around, in a way that produces unintended consequences
that are worse than the original problem. Usage: "Windows ME
fixes many of the shortcomings of Windows 98 SE". - Hutchison This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics | |
by: Cecil Westerhoff |
last post by:
I just started with programming under linux with c++. I have programmed
for years with Borland C++ Builder. So I have some experience. But I can
not find the libraries for intenet stuff. (Ping,...
|
by: Nikki Locke |
last post by:
Archive-name: C++-faq/libraries/part1
Comp-lang-c++-archive-name: C++-faq/libraries/part1
Available C++ Libraries FAQ
===========================
Introduction
~~~~~~~~~~~~
Dos and don'ts -...
|
by: fabio de francesco |
last post by:
Hello,
I have a couple of years of experience with C++. I started studying
C++ syntax, then I read the B.Stroustrup's book, and eventually I went
through the N.Josuttis' book on how to program...
|
by: Matt Kruse |
last post by:
Since this topic has come up several times in other threads, I thought I'd
make a separate thread and gather opinions from (hopefully) a more varied
range of newsgroup participants.
What are...
|
by: rajesh_krec |
last post by:
Hello Everybody,
I'm using Microsoft Visual Studio .NET 2003 (with Vc7 compiler)
I have some 15 projects each of which generate a static library when i
build the solution in release mode.
...
| | |
by: Thiru |
last post by:
I am writing an application that interacts with Oracle and Teradata.
In order to create the executable, I need to link various Oracle and
Teradata libraries. I found out that when I link the...
|
by: Jon Kneller |
last post by:
I have 2 seperate libraries, compiled to .so files (these are being loaded
into a Tcl process).
I would like to be able to share data (a linked list) between these
libraries - one needs to...
|
by: joseluismarchetti |
last post by:
Hello everybody,
Although I am sure this is an important question for this group, I
am not sure this question belongs to this group and I will be
happy to move it to the correct one after you...
|
by: Matt Silberstein |
last post by:
Are there any good qualities libraries out there, free or for
"reasonable" cost?
--
Matt Silberstein
Do something today about the Darfur Genocide
http://www.beawitness.org
|
by: g |
last post by:
Hello,
is there any library for C as Boost is for C++?
thanks in advance,
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
| | |
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new...
|
by: conductexam |
last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and...
|
by: TSSRALBI |
last post by:
Hello
I'm a network technician in training and I need your help.
I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs.
The...
|
by: adsilva |
last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
| | |
by: 6302768590 |
last post by:
Hai team
i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated ...
|
by: bsmnconsultancy |
last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence...
| |
