On Tue, Dec 22, 2009 at 12:12:07PM +0530, K. K. Subramaniam wrote:
> On Monday 21 December 2009 11:06:51 am David T. Lewis wrote:
> > > Currently, the *Plugin.c file is generated from Slang code which is
> > > pre-loaded  into the vmm image and not distributed with the plugins/
> > > directory. The first line in such generated files is a cryptic:
> > >  /* Automatically generated from Squeak on #(7 March 2007 2:25:53 pm) */
> > > 
> > > This line contains no clue about the version of the slang code or the
> > > vmm  which translated it to C.
> > 
> > Are you using an up to date VMMaker from SqueakSource? If so, you should
> > be seeing comments that look like this:
> > 
> > /* Automatically generated from Squeak on 20 December 2009 11:41:57 pm
> >    by VMMaker 3.11.10
> >  */
> I picked the header from 
> ./unix/plugins/VideoForLinuxPlugin/VideoForLinuxPlugin.c randomly from the 
> unix*vmm.tar.gz sources distributed from squeakvm.org/unix.

Ha! Interesting "random" choice. I don't know why this C source is being
kept in the platforms tree, but it does illustrate the sort of confusion
that arises from allowing generated C files to be mixed in with the platforms
source tree. I think that Video4Linux comes from Etoys, see
  http://wiki.squeak.org/squeak/3765

I'm not sure where the real master copy of the source code is, possibly
it's this change set:
  http://wiki.squeak.org/squeak/uploads/3765/VideoForSqueak-dgd.cs.gz
or (hopefully) it's being maintained in a Monticello repository somewhere.

In any case, I suspect that at some point (as needed for the OLPC project),
a C file was generated from the Smalltalk source, and this was added to
unix/plugins/VideoForLinuxPlugin. That would be the file you are looking
at. It is *not* the real source code for this plugin.

IMO this is an error and should be fixed.

> Even the new style 
> header only includes the VM version and not the plugin source (cs) version. 
> Shouldn't this appear in the intermediate .c or .so file for traceability?

This is a good idea. Unfortunately I don't know any way to do it in an
automated fashion. That leaves it up to the author of the plugin to make
it happen. For example, in OSProcessPlugin you will see something like
this about 30 lines into the generated source:

/* D T Lewis - UnixOSProcessPlugin.c translated from class
   UnixOSProcessPlugin of OSProcessPlugin version 4.3.3 */

There is also a primitive that answers the plugin version string at
runtime. But this is a manual process that relies on the author of
the plugin writing the necessary code and keeping the version string
up to date.

If anyone can think of a better way to do this, I'd be all for it!

Dave