[Vm-dev] The code in the src folders in the repository

[Eliot Miranda]

Hi Fabio,

> On Jun 22, 2016, at 12:51 AM, Fabio Niephaus <lists at fniephaus.com> wrote:
> 
> AFAIK the pharo-vm projects generates the sources from the VMMaker package during a build.
> Wouldn't it be better if the OpenSmalltalk vm does the same? Then no one needs to generate source manually anymore and we don't have millions of lines [2] of generated code in the repository.

For me this is a very very bad idea.  There are two main objections.  The main problem is that it means there is no versioning of the key source of the VM.

- one cannot ever guarantee generating exactly the same source that was fed to the compiler in a particular build
-- elements of the type inferrence code are affected by hash computations since they use dictionaries etc, and so there are small variations from run to run.  These shouldn't exist and I work to stabilize the type inferrencer but it isn't yet perfect
-- the VMMaker and Cog packages make use of the underlying system and it's conceivable that differences in the generated source, in inessentials like white space, could bubble up into the generated source, especially considering the differences between Pharo and Squeak, which are only widening.

This is disastrous for VM debugging.  One /must/ have a versioned artifact to be able to attach a debugger and set of sources to an already-built production VM and be able to be debugging the VM that corresponds with that source.

This is disastrous for spitting problems with the type inferrencer.  If source is generated and sent to the computer there's no point at which the VM developer gets to check that the difference between one version of the sources and another are as expected.  Often bugs introduced into the type inferrencer are noticed and understood by looking at the changes to the generated source before checking in that source.  Remove this stage and these bugs will only be found much further down stream at much greater cost and at enormous cost to examine because one will have to set up two different images to generate the two versions and manually duff them.

Note that the type inferrencer is key to being able to write clean Smalltalk code for the VM with minimal duplication that works for both 32- and 64- but Spur, and in general.  It allows one to omit C type declaration pragmas from much of the VM source, which is key to a particular method working in 32- and 64-bit versions.  I'm sure that if we ever wanted to try and merge in SqueakJS it would be even more important.


The second problem is performance.  Generating one of the sources takes a substantial fraction of a minute on a fast machine.  On an ARM it takes more than a minute.  Add to that the time taken to download a VM and image and that's more time.  Add to that the loading of VMMaker, Cog and prerequisite packages and now one is in a position where Travis time limits could prevent a buff on google's ARM infrastructure.

So please, no.  This may seem like a pure approach but it is, in fact, insane.  It means that anyone doing serious VM development has to work a lot harder and wait a lot longer to get their work done.  It destroys their productivity.

> Fabio
> 
> [1] https://github.com/pharo-project/pharo-vm
> [2] see Eliot's stats at https://github.com/OpenSmalltalk/vm/graphs/contributors
> 
> -- 
> 
>> On Wed, Jun 22, 2016 at 4:02 AM David T. Lewis <lewis at mail.msen.com> wrote:
>> 
>> On Tue, Jun 21, 2016 at 11:11:28AM -0300, Laura Perez Cerrato wrote:
>> >
>> > Hi everyone,
>> >
>> > Excuse me if this has been asked already or it's documented somewhere and I
>> > missed it, but what's the criteria to update the code in /src, /stacksrc,
>> > /spursrc and other similar folders in the repository?
>> >
>> > -Laura Perez Cerrato
>> 
>> Good question. Traditionally, Eliot generates these sources periodically and
>> commits them to the repository (and in recent years I have done that chore for
>> the old trunk interpreter VM). At this point, unless Eliot advises otherwise,
>> I would suggest that no one other than Eliot should commit to the /src trees.
>> 
>> Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160622/73cc6d35/attachment.htm