vm team mailing list archive

[Uday S Reddy <u.s.reddy@xxxxxxxxxxxxx>]

Hi Tim,  Thanks for looking at the warnings.

> Can I have some clarity on exactly what level of bacwards version
> compatibility we want? 

I think we have been through this before, and I added a note to the
README file about the version compatibility that we have in effect for
the 8.2.x releases.  

I defer to Ulrich on deciding version compatibility issues.

> I think this is relevant because it can impact on how
> we 'fix' some of the warnings. For example, if the warning is for something
> that is now obsolete in versions we support, we can just remove it or change
> it to whatever it should now be. However, if it is something that is still
> part of a version we want to support, then we probably need to put some
> version branching, i.e. use eval-and-compile etc. 

What I normally do is to create a "vm-" version of the primitive where
version-based branching is contained.  See the revision 836 and its
internal revisions, especially the primitives added to vm-misc.el, for
how we do this.

> Secondly, if we do need to put version dependent code in, can we assume VM is
> always run as a compiled binary i.e. can use eval-when-compile rather than
> eval-and-compile or would it be preferrable to just use eval-and-compile? We
> currently have both in the code. For this situation, I would tend to go with
> eval-and-compile as it is sometimes useful when debugging/developing to run
> interpreted and not byte compiled code. 

I don't think we can assume that VM is run as a compiled binary.  Some
users prefer to use it uncompiled.  Plus, we use it uncompiled during
the development itself, to enable tracing and all that.

> Is using these two macros the correct way to handle version dependent code?

We would like to avoid version-dependent binaries if at all possible,
because it is a pain to maintain multiple binaries.  If something is
really needed at comiple-time for performance, then yes, but otherwise
it is best to postpone the checks to run-time.

> PPPS. I find this encoding stuff complex and confusing and really
> don't understand it that well, though I've been lazy and an arrogant
> english speaker!

Fortunately, we have Ulrich who knows this stuff well.

Cheers,
Uday