Hi,
I've checked in the proposed bytecode PDD and also most of the changes
that I discussed with Allison earlier today. Feedback on it would be
greatly appreciated.
One of the areas that it would good to have some input on, even if it's
just a "yes, that's sane", is versioning. The current implementation
versions the packfile based up the current version of Parrot and the
opcode fingerprint. However, between versions of Parrot it is feasible
that there will be no packfile format changes, and we'd like an easy way
for a particular Parrot version to assess whether it can read and run a
certain packfile (as well as being able to write packfiles that are
readable by previous Parrots). These things matter once Parrot is
deployed in production use - new versions must be able to read older
bytecode files.
Therefore, a bytecode file version number has been introduced, with a
major and a minor part. This is independent of the Parrot version
number, and replaces the opcode fingerprint. See the proposed PDD for
details.
A couple of open questions on this are:
1) Is keeping the Parrot version number around sensible and if so, is
having it as the version of Parrot that wrote the packfile useful? I
guess it's helpful if we need workarounds for bugs in previous versions
of Parrot in later versions to know this. Other thoughts?
2) How should we handle changes to the core Parrot library (mostly PMCs,
but also consider anything we promise is available)? Should this bump
the packfile version number too? Or do we want some other mechanism to
handle this?
Again, comments and/or suggestions on anything else in the proposal are
very welcome! :-)
Thanks,
Jonathan
