ARM IDE

Chris H wrote:
> 
... snip ...
>
> The Perennial or Plum Hall are the tests for the C language
> conformance. BTW In some ways I think the Perennial is better
> than the Plum Hall.

You can't even say they come close to a suitable test, since you
don't have the source available.  The closest thing available,
AFAIK, is the gnu tests for gcc, which are not ideal because they
are intended to test conformance to "GNU C", which in turn is
non-standard.

-- 
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: <http://cbfalconer.home.att.net>
            Try the download section.

Stefan Reuther schreef:
> Chris H wrote:
>> In message <EtCdnXG9DbA5TbTUnZ2dnUVZ8vqdnZ2d@lyse.net>, David Brown
>>> Chris H wrote:
>>>> Your  "confident" assurances amount to what? Not a lot really? You
>>>> expect me to bet my life and the lives of others on your say so?
>>> Yes, that is *exactly* what people developing safety critical systems
>>> expect you to do.
>> Actually not.  They give the proofs.
> 
> I haven't seen one. And what can such a proof be worth if I still keep
> finding bugs in qualified & certified compilers? 

A test can at best proof there are bugs, a test can never proof the 
absence of bugs.

CBFalconer wrote:

> > The Perennial or Plum Hall are the tests for the C language
> > conformance. BTW In some ways I think the Perennial is better
> > than the Plum Hall.
>
> You can't even say they come close to a suitable test, since you
> don't have the source available.  The closest thing available,
> AFAIK, is the gnu tests for gcc, which are not ideal because they
> are intended to test conformance to "GNU C", which in turn is
> non-standard.

Most compiler companies recognize the value of tests written
by independent third parties. Good compiler tests are both
expensive and worth it in terms the value they add to a product.
Perennial and Plum Hall are in relative terms modestly priced
well written with a clear specific goal. Perennial and Plum Hall
tests (they have full source) objectively test language support
to specific standards documents.

The GNU tests are are best weak.  They lack objective testing
of either the language or code generation to a spec or standard.

The important thing about tests is they need to be automated
and repeatable. Negative tests are a lot harder to implement but
are as important to product development as positive tests


Regards

--
Walter Banks
Byte Craft Limited
http://www.bytecraft.com

Stefan Reuther wrote:

> If I bounce off 1st level, what can I do?

Repeat the request be very clear.

1) Top post
2) 10 or 15 lines (max) to describe problem
3) Use white space
4) Describe solution/requirements
5) Provide contact information with phone number
6) Tool detail: compiler version [ serial/licence number ]
7) Attach supporting material
8) CC sales@. ...

- Make it a newspaper article most import stuff first.

- Everything that is needed is seen as soon as the email opens.

- No guessing. "It is broken", is not a  technical term
   support groups understand. Be clear point to
   the failure specifically by address or phrase.

- Let support know about deadlines or other extenuating
   circumstances.

- Be polite support will likely respond in kind. It reinforces your
  objective to resolve a support problem.


Regards

--
Walter Banks
Byte Craft Limited
http://www.bytecraft.com

Walter Banks wrote:
> CBFalconer wrote:
> 
>>> The Perennial or Plum Hall are the tests for the C language
>>> conformance. BTW In some ways I think the Perennial is better
>>> than the Plum Hall.
>>
>> You can't even say they come close to a suitable test, since you
>> don't have the source available.  The closest thing available,
>> AFAIK, is the gnu tests for gcc, which are not ideal because they
>> are intended to test conformance to "GNU C", which in turn is
>> non-standard.
> 
> Most compiler companies recognize the value of tests written
> by independent third parties. Good compiler tests are both
> expensive and worth it in terms the value they add to a product.
> Perennial and Plum Hall are in relative terms modestly priced
> well written with a clear specific goal. Perennial and Plum Hall
> tests (they have full source) objectively test language support
> to specific standards documents.
> 
> The GNU tests are are best weak.  They lack objective testing
> of either the language or code generation to a spec or standard.
> 
> The important thing about tests is they need to be automated
> and repeatable. Negative tests are a lot harder to implement but
> are as important to product development as positive tests

You omitted "publishable".  

-- 
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: <http://cbfalconer.home.att.net>
            Try the download section.

Stefan Reuther wrote:

[...support quality...]

>One difference with plain OSS (i.e. not pre-packaged OSS with support
>contract and price tag) here is that there is no marketing departement
>trying to hide the developers from the users. A foo-devel or foo-support
>mailing list accepts input from almost everyone.

Ack. But "no marketing departement hiding developers from the users"
is no quarantee that things will be corrected. Even developers can be
uninterested, overloaded etc., and money (support contract) can (!)
improve your position.

There are tons of long standing bugs in OSS.

I see no clear indication that OSS is better in this respect. I have
seen any combination of good/bad support with open and closed source
software.

Oliver
-- 
Oliver Betz, Munich
despammed.com might be broken, use Reply-To:

Walter Banks wrote:

>Stefan Reuther wrote:
>
>> If I bounce off 1st level, what can I do?
>
>Repeat the request be very clear.
>
>1) Top post
>2) 10 or 15 lines (max) to describe problem
>3) Use white space
>4) Describe solution/requirements
>5) Provide contact information with phone number
>6) Tool detail: compiler version [ serial/licence number ]
>7) Attach supporting material
>8) CC sales@. ...

BTDT, no guarantee it helps. But it's frustrating if you do it
repeatedly because it's a lot of wasted work.

Slightly off-topic but similar: I have been sending so many reports
about silicon and documentation errors to a uC manufacturer. Always
hard to convince first level support that it is a bug. After being
successful there, with some luck, it's published not sooner than one
year later.

Oliver
-- 
Oliver Betz, Munich
despammed.com might be broken, use Reply-To:

In message <i5bni4pm3apmid81f1c4dpmau2kjh2imjk@z1.oliverbetz.de>, Oliver 
Betz <obetz@despammed.com> writes
>Stefan Reuther wrote:
>
>[...support quality...]
>
>>One difference with plain OSS (i.e. not pre-packaged OSS with support
>>contract and price tag) here is that there is no marketing departement
>>trying to hide the developers from the users. A foo-devel or foo-support
>>mailing list accepts input from almost everyone.
>
>Ack. But "no marketing departement hiding developers from the users"
>is no quarantee that things will be corrected. Even developers can be
>uninterested, overloaded etc.

This is true. As I have said before developers are often less interested 
in talking to users and less tolerant than the support people

>, and money (support contract) can (!)
>improve your position.
>
>There are tons of long standing bugs in OSS.

Really@ I thought OSS bugs were fixed in minutes because everyone has 
the source.  You mean it is no better than commerical software. Just a 
hell of a lot less control and lots of amended (non-standard and 
untested) versions floating around all over the place,.

>I see no clear indication that OSS is better in this respect. I have
>seen any combination of good/bad support with open and closed source
>software.

I agree. The difference is the commercial packages have more of an 
incentive to give good support.  It they give bad support they loose 
their job of the company looses sales and they loose their job etc

BTW Do remember that most of these support people are software people 
just like you are.....  Usually just as qualified and usually more 
experienced in their tools than you are.


-- 
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Chris H wrote:

[...support quality...]

>I agree. The difference is the commercial packages have more of an 
>incentive to give good support.  It they give bad support they loose 
>their job of the company looses sales and they loose their job etc

not necessarily true. There _are_ less critical customers with lots of
money and certain decision structures.

>BTW Do remember that most of these support people are software people 
>just like you are.....  Usually just as qualified and usually more 
>experienced in their tools than you are.

I don't understand the joke behind this. After all, I'm more a
hardware guy, not even "mainly digital" but also analog and power.

Oliver
-- 
Oliver Betz, Munich
despammed.com might be broken, use Reply-To:

Oliver Betz wrote:
> Walter Banks wrote:
>>Stefan Reuther wrote:
>>>If I bounce off 1st level, what can I do?
>>
>>Repeat the request be very clear.
[...]
> BTDT, no guarantee it helps. But it's frustrating if you do it
> repeatedly because it's a lot of wasted work.
> 
> Slightly off-topic but similar: I have been sending so many reports
> about silicon and documentation errors to a uC manufacturer. Always
> hard to convince first level support that it is a bug. After being
> successful there, with some luck, it's published not sooner than one
> year later.

This matches our experience surprisingly close.

Once you got through to the developers or even just the application
engineers, things get a lot easier.


  Stefan