vm team mailing list archive

[Tim Cross <tcross@xxxxxxxxxxxxxxx>]

From: Uday S Reddy <u.s.reddy@xxxxxxxxxxxxx>
Subject: Re: [Vm] compilation warnings
Date: Sat, 3 Jul 2010 18:31:00 +0100

> Tim Cross writes:
> 
>> > Will it work on the supported older versions of emacsen?
>> 
>> I believe it does on emacs 22.1 onwards. 
> 
> Hmm.  But XEmacs is in version 21.  I have now incorporated the fix in
> the trunk in revision 840.  You can take a look at how it is done to
> allow for all versions of Emacsen that we support.
>

OK, I was going to install xemacs today and try some compilations with that as
well. Will look at what you have done.
 
>> I would agree, but to be honest, the caller in this case is doing a lot more
>> wrt multibyte settings and more comprehensively than vm-read-folder, including
>> taking into consideration emacs/xemacs differences in this area. Although I've
>> not looked closer, but was surprised that the top level 'vm' function was the
>> only one calling this funnction. I would have expected a function called
>> vm-read-folder would have been called whenever you visited a folder.
> 
> Yeah, the top-level vm function is a bit of a kitchen sink.
> 
> I will alert Ulrich that you are waiting for feedback.
> 
>> > In these kinds of situations, we also need to make sure that all the
>> > changed code is exercised by the tests.  That can be quite hard.  I
>> > wish we had some tools for checking the coverage of tests.
>> > 
>> 
>> Yes, test coverage would be really good. However, from experience, adding or
>> incorporating such tools into an existing package with so much legacy code is
>> extremely difficult. It could be done, but will take a massive amount of
>> time/effort. 
> 
> You are probably misunderstanding me.  My question is basically
> whether your testing has covered (i.e., executed) all the code that
> has changed.  Moreover, in the unibyte/multibyte case, we need to test
> it with multibyte text.  
>

My comment was to your reference to tools to manage test coverage. It would be
very useful to have a 'standard' collection of test messages that we could
use. We could possibly then also develop a standard set of regression tests.
My point is that it will take a lot of work to develop something like this.
However, this does not mean it isn't worthwhile. In fact, given the code base
we have, it could be argued it is essential. It would be great if we could
just run a script after a build that executed a set of tests - while this
would not be sufficient in itself, it would add to our confidence that changes
don't introduce new problems.

My tests covered most of the changes, though not yet vm-biff, which I've never
used. However, I would not claim it is fully tested yet. 
I'm not sure about the multibyte stuff. I do have a collection of spam
messages that appear to have various multibyte characters in them and they
appear to display, save, forward etc OK, but I can't say how representative
they are of possible encodings. I do find the spam messages a little useful
for testing as they are often 'malformed' or fail to comply correctly to
various mail RFCs etc. 
 
> Are you looking at other warning messages too?

Yes. I'm trying to deal with them in 'groups' of similar messages and then
commit each group so that it is easier to extract specific bunches of fixes. I
am also using my compiler-fixes branch as my current VM version as an
additional ad hoc testing process. 

I would not claim the fixes I've applied are fully tested or complete. That is
why I put them in their own branch. At this stage, I really wanted to make
them available for comment and to let you and Ulrich no they are there so that
we don't end up covering the same work. 

Tim