[Vm-dev] Support for reading and writing JPEGs to/from -32, -16, -8 and 8 bit deep forms on V3

[David T. Lewis]

On Wed, May 18, 2016 at 03:56:11PM -0700, Eliot Miranda wrote:
> 
> Hi Laura,
> 
> > On May 18, 2016, at 1:04 PM, Laura Perez Cerrato <lauraperezcerrato at gmail.com> wrote:
> > 
> > 
> > Hello, everyone,
> > 
> > During the past few days I've been working on adding support for
> > reading and writing reading and writing JPEGs to/from -32, -16, -8
> > grayscale and 8 grayscale bit deep forms to JPEGReadWriter2Plugin for
> > the Squeak Cog V3 VM. Just chiming in to tell you that the work is
> > done and I'd like to share it with you all. :) I believe this changes
> > should work on Spur VMs too, but haven't tested thoroughly enough to
> > ensure that.
> > 
> > How do you handle contributions to the codebase? I assume I'd have to
> > upload the corresponding changeset to the repository but I'm not sure
> > if there's anything I should do before.
> > 
> > I have also been working on a few changes to the latest non-Spur
> > version of Squeak in order to take advantage of the changes to the
> > plugin but, since I added a primitive to it and these changes use it,
> > I think it's prudent to ask you too how those contributions are
> > handled. Should I refer to the Squeak-dev mailing list?
> 
> This is indeed a problem.  Talking for myself, until VMs have been built that include the code and are generally available one can't really deploy the behaviour to trunk.  But again waiting for the next release feels far too slow.
> 
> One approach is to make the behaviour optional, depending on what the VM provides, eg checking for primitive failure or a plugin version number, or simply making the code fail gracefully.
> 
> Another approach is to provide the functionality in an extension package, and merging that extension into trunk at the next release.
> 
> Other suggestions folks?
> 

We should take a look at the image side code too. Laura, perhaps you can
post a change set for that also?

Very often a new optional primitive can be handled simply by providing
some suitable fallback code. That provides a smooth transition, because
the new feature is immediately available and the system continues to work
for people who do not yet have the new primitive in their VM.

Dave