The problems in comp.lang.c

[Morris Dovey]

google me. You will see I am myself alone and no ones puppet.

Consider yourself googled.

I, on the other hand [!!] am my /own/ sock puppet.

(That's how I can look so much alike.)

8-D

 

[Richard Heathfield]

Jeff P. Bailey said:

I haven't found any to date.

You can't have looked very hard.

I have to say that jacob navia has written
a popular and well-respected C compiler.

I am prepared to accept that it is popular.

To me, this is pretty strong
evidence that he's knowledgeable about C, and if you want to argue that
he's incompetent at C then the onus should be on you to provide evidence
for that.

I don't think he's truly incompetent. I do think he is less concerned with
the minutiae of C than he should be. I have provided plenty of evidence
for this in the past. You can either trust me on that (because I'm not
about to go digging about for old articles for your sake), or not. I don't
really care either way.

In the absence of such evidence, I can only conclude that you
have a personal bias against him.

Just because the evidence hasn't been posted in the last few days, that
doesn't mean it's absent. A few days' newsfeed is not of any particular
statistical significance.

Of course you are right that my contributions to this group are
currently non-existent. I have to say that I'd be more inclined to
change that if the atmosphere round here was a bit more positive.

Surely that's the wrong way round? If you want the atmosphere around here
to be more positive, *make* it so by posting positive articles.

<snip>

 

[Mark McIntyre]

Oh god, not another bloody thread where Navia tries to hijack CLC to his
own personal taste and platform.

I do wish he'd get some medical help. His paranoia becomes quite annoying.

 

[user923005]

google me. You will see I am myself alone and no ones puppet.

Consider yourself googled.

I, on the other hand [!!] am my /own/ sock puppet.

(That's how I can look so much alike.)

8-D

Dann Corbit is the sock-puppet of the evil User923005 (as everyone
knows).
And the evil User923005 is also the sock puppet of the evil User923005
(defined recursively).
Since there is no terminating condition, the army of them is infinite.

 

[user923005]

... snip ...



That is not C code, within the meaning of this newsgroup.

OK, let's consider a legal C99 construct that is not a legal C95
construct.
A C99 compiler will create very different diagnostics than a C95
compiler.

 

[Kenny McCormack]

Oh god, not another bloody thread where Navia tries to hijack CLC to his
own personal taste and platform.

I do wish he'd get some medical help. His paranoia becomes quite annoying.

You're the one who needs to see a psychiatrist.

Seriously.

 

[CBFalconer]

(e-mail address removed) (Kenny McCormack) wrote:
.... snip nonsense ...

Meanwhile, do you have some justification for thread discussion
here instead of comp.programming .threads? If you have a good
one, you can persuade me. but I haven't seen a good justification
for it being here yet.

Bear in mind that McCormack is a notorious troll, normally plonked.

 

[CBFalconer]

.... snip ...

I've only seen a small cross-section of what seems to be a long
and acrimonious posting history between these two, but the picture
from what I've seen is of jacob navia posting interesting articles
likely to be of wide interest to new C programmers, while he is
roundly condemned for this by everyone for being off-topic.

Mr Heathfield doesn't content himself with saying jacob's posts
are off-topic, but also adds personal insults to the effect that
jacob is incompetent at C. These accusations are quite implausible
given that jacob has authored a successful C compiler, and I can't
blame jacob for getting irritated by it.

Of course, as I said, I'm willing to believe that I haven't seen
the whole picture in this.

You haven't. Topicality here is guided by the C standard. Things
specific to an installation are off-topic. Jacob has been advised
of this time and again, and insists on posting off-topic junk that
belongs in entirely different news-groups. In the process he often
demonstrates a sad non-familiarity with the C standard. This is
not good in someone attempting to build a C compiler.

For example, comp.compilers.lcc exists. Jacob occasionally posts
there, where he is not limited by topicality. However he prefers
to create the off-topic messes here.

Incidentally, stacks and linkers are installation specific. The
final action of a linker ONLY is mentioned in the C standard.
Stacks are not mentioned at all.

 

[Antoninus Twink]

It is impossible to persuade the trolls that they are in a vanishingly
small minority here,

because we're not.

Mud-slinging is their stock-in-trade. They offer no evidence to
support their views for the simple reason that there isn't any.

Pot, kettle, black?

Harking back to the Subject line, the problems in comp.lang.c are, in fact,
the trolls,

Wrong. Maybe there is no solution to the deep-seated problems in clc,
but if there is any last hope of sanity returning, then we're it.

All they *can* do is sling mud.

Wrong. Our criticisms are always constructive. You, on the other hand,
devote more and more of your posts to your stupid personal vendetta with
Jacob.

 

[Antoninus Twink]

That is not C code, within the meaning of this newsgroup.

You mean, within the meaning of CBF.

And fix your damn sig.

 

[Antoninus Twink]

Jeff P. Bailey said:

I am prepared to accept that it is popular.

Accepting the objective fact that it's well-respected would obviously
stick in your throat.

I don't think he's truly incompetent. I do think he is less concerned with
the minutiae of C than he should be. I have provided plenty of evidence
for this in the past. You can either trust me on that (because I'm not
about to go digging about for old articles for your sake), or not. I don't
really care either way.

The classic resort of the liar - when he can't produce any evidence to
support his false claims, he turns to bluster instead.

 

[Antoninus Twink]

Oh god, not another bloody thread where Navia tries to hijack CLC to his
own personal taste and platform.

I do wish he'd get some medical help. His paranoia becomes quite annoying.

I knew Psycho Mackintyre wouldn't be able to resist for long when he saw
everyone piling into Jacob yet again...

 

[Antoninus Twink]

Bear in mind that McCormack is a notorious troll, normally plonked.
s/McCormack/Falconer/

And fix your damn sig.


--

 

[broli]

I have certainly gained a lot of knowledge from Richard Heathfield's
posts. That's all I got to say!

 

[Antoninus Twink]

I have certainly gained a lot of knowledge from Richard Heathfield's
posts. That's all I got to say!

Well done, your loyalty will not go unrewarded. Now kiss your
Godfather's hand.

 

[Kenny McCormack]

I have certainly gained a lot of knowledge from Richard Heathfield's
posts. That's all I got to say!

I've learned a lot, too. It has certainly been an eye-opener.

Probably not the same kind of learning to which you are referring,
however.

 

[santosh]

Now consider that 'threaded' program running on a single processor
that is time shared between processes. That means that
periodically one process is interrupted, the time and effort spent
to switch processes, the new process finds it has nothing to do,
and the interruption time etc. is spent all over. In this case
things can be more efficient running in an unthreaded system.

Er no. If a thread has nothing to do, it blocks, so the OS will not
schedule it until it's blocking condition is fullfiled.

The point is that things are not open-endedly improvements.

I didn't say they were.

They may improve the apparent organizational complexity (which is an
advantage) without gaining any performance.

That's true. Multithreading isn't for all programs, but many do
increasingly benefit from it. That was my point.

When the two processes
are effectively separate programs, and you just start both, things
are logically simple. The complexity is hidden in the mechanisms
that wake processes. Now some of the standard systems come into
place - producer/consumer, for example.

For many tasks the overhead involved in communication would be too much.
That was why threads were created.

 

[broli]

Well done, your loyalty will not go unrewarded. Now kiss your
Godfather's hand.

I don't know what made you assume that but yeah whatever floats your
boat.

 

[Kenny McCormack]

I don't know what made you assume that but yeah whatever floats your
boat.

Ooooh! Major comeback!

 

[Paulo Jorge de O. C. de Matos]

Paulo Jorge de O. C. de Matos wrote:

I guess these are in fact, the things I use the most from C99. The
other stuff might be useful to others. I even inquired the gcc people
why C99 is so poorly [in ~10 years they still miss a couple of
features] implemented. Their reply was ... interesting but
not as clear as one would wish:
http://gcc.gnu.org/ml/gcc-help/2008-03/msg00221.html

Interesting.

And to follow up, Paulo's respondent seems to be implying pretty
strongly that a reason for gcc's slow implementation of C99 (and for
many other implementations as well) is that C is proving to be an
ill-designed language to extend easily.

Although I don't know much about compilers, I've had the opportunity
of implementing a software verifier based on SAT techniques inside
gcc. From what I have seen gcc is a pretty big beast and quite
complex. I would even go to the point of saying that the problem might
not be [only] C as a language but GCC that was not prepared to be
extended to this point and many things start to conflict with each
other resulting in bugs and missing features. For an example, check:
http://www.nabble.com/Inline-functions-in-C99-td15789469.html

This is however, just my intuition. I have no concrete information or
proof that the problem with the C99 implementation lies with GCC.

[snip]