On 1/20/08, sander <email address hidden> wrote:
> 2008/1/20, Mats <email address hidden>:
> > On 1/19/08, sander <email address hidden> wrote:
> > > >
> > > > and service/sms isn't a registered disco identity. My fallbacks for
> > > > getting icons failed and I have now added more traps that will work in
> > > > more situations. However, in this case there is just no
> > > > category='service' so I return an empty image. Have no idea what
> > > > "service" is supposed to mean and it is better not to assume anything.
> > >
> > > So, another bug?
> >
> > It can as simple as a configuration error in an xml file that was made
> > by the admin.
> > In any case we must be fault tolerant which I belive we are now, at least
> here
>
> I don't agree with that. This is the mantra from WWW community and it
> *sucks*. It's the main reason why you cannot make a good browser or
> website by only looking at the available open standard specifications.
> All browsers and all websites have exceptions and this make it
> extremely hard for newcomers to enter the business as they all should
> learn the exceptions by trial and error. Not only this is a huge task
> needing more resources, but also it will make the code more ugly (also
> the HTML source of a website). Also, when you add support for these
> exceptions, the related projects and people will feel no need to fix
> their bugs. That's why I *strongly* suggest against being fair to such
> bugs. My advice:
> 1) Be strict in following the specs and give a high priority to fixing
> your own bugs in this regard.

This is also my mantra.

> 2) Make sure Coccinella does not crash due to another service or
> software being wrong

This is what I meant by being fault tolernat. In this specific case
with service/sms
there wont be an icon and I don't try to map category/type into something else.

> 3) Do not adopt to these exceptions, instead file a bug report
> yourself or give me the required information and I'll forward the bug
> to the right people.

I don't adopt such changes, just makes sure we don't crash...

> 4) If users complain something is not working because of such a bug in
> another service, tell them it's a problem in the other service *and*
> forward their complaint to the relevant project.
>

Agree.
Seems we don't have any disagreement here at all :-)

> > >
> > > > In situations like this one it can help if you provide some more debug
> > > > info like this: consider the top proc of the stack trace
> > > > ("::Rosticons::Get") and add some puts statements, at least for the
> > > > arguments since I don't always get them in the stack trace. And
> perhaps
> > > > a few other puts so I can see what is happening. 90% of my time is
> spent
> > > > trying to figure out what has happened and just a small part actually
> > > > fixing it.
> > >
> > > ...looks like Swedish to me...can you also translate it in English for
> > > me? :-)
> > >
> >
> > I can start talking machine assembly code language if you prefer that...
> > (Kidding, I don't know assembly language.)
>
> The issue is I'm too stupid to understand things like "consider the
> top proc of the stack trace"...
>

Let me explain: when there is an error popping up with something
looking like greece
to you, that's the stack trace. It displays the call sequence from the
original event (network read, button...) with names of procedures and
where called from, arguments and such. Just identify the lat such proc
name, like "::Rosticons::Get" in this case, localize it in the code,
and add a few lines like:

puts "jid=$jid"
puts "type=$type"

or whatever variable names you find interesting. The logic is normally
easy to follow.
If you do this it can greatly simplify my tracking.