[Vm-dev] OSProcess fork issue with Debian built VM

Eliot Miranda eliot.miranda at gmail.com
Sat Jun 3 18:05:44 UTC 2017

Hi Subbu,

> On Jun 3, 2017, at 9:47 AM, K K Subbu <kksubbu.ml at gmail.com> wrote:
>> On Saturday 03 June 2017 03:27 AM, Eliot Miranda wrote:
>> Over my dead body.  The make must *NEVER* be done like this.  The
>> problems are many:
> Ouch! :-). Please don't take my example too literally. Smalltalk does not have a concept of a file-based compilation unit like C, so I had to use an extension to denote a collection of st code that goes into generating a .c compilation unit. I may well have used a .st or .zip for source code.
>> - the VM so produced is undebuggable.  There is no source for
>> FooPlugin.c; it has been deleted
> This is not the first time C-code gets generated on the fly. This technique has been used by Lex, Yacc etc. since early 70s. Bison generates a FSM interpreter in C from a Yacc spec. My example makefile segment deleted the file, but it can also cache it for debugging.

Caching it is not good enough.  If there are bugs in generation then there's no guarantee that regenerating it at a later time produces the same source.  Since the generated source contains time and version stamps it won't be the same anyway.

The inputs to any production vm /must/ be fully versioned at the point the source is consumed by the production compilation system.

The time taken to rebuild after a change should be as short as possible to keep debugging productivity high.  Mandating a translation step defeats this.

>> - the build is slow; building a VMMaker image (the necessary
>> prerequisite for st2c) takes a long time, mush longer than the st2c step
> The image is just a smalltalk app that translates slang to C. It does not have to be regenerated in every build anymore than gcc or cmake. In earlier posts, I had floated the idea of a bootstrap VM - a st machine with a built-in image to build and launch larger VMs. It can even be a separate project.

Sure.  This is also what my work image is.

> The .st code has to be translated to C at some time. If it is done within a single VM, then we won't be able to exploit multi-cores. With an st2c app, we can translate in parallel for a quicker build.

That could be nice.

>> - unless FooPlugin.mcz is versioned then the VM so produced is
>> unversioned and if  FooPlugin.mcz /is/ versioned then there's no reason
>> why the plugin can't be produced using the normal workflow, generate C
>> source, check it in to opensmalltalk/vm, build, and that way we have a
>> versioned entity and break the dependency of builds requiring VMMaker
> Anyway, my point is that only the smalltalk "compilation unit" should be under version control. If a .c file is generated from it, there is no need to subject it to version control. It can continue to remain in a cache. Like the way we preserve .i (preprocessed) or .s (assembly) files for debugging .c code but never check-in these i. or .s files.

And my point is that input source to compilers producing the VM (e.g. .c .h .cpp .m and .s) whether generated or manually prepared /must/ be versioned, and must change only when changes are made to them (e.g. regenerated plugin source is only checked in when either the Plugin Smalltalk has changed or Slang has changed in a way that affects the plugin).

> Okay, I had no idea I was stepping into a minefield of raw nerves here ;-). I will step back from these threads and do some prototyping and come up with specific code changes. The code seems to have grown too large for a lone hobbyist but it is still worth a try.

Supporting hobby projects, or rather, keeping the system open for people to add plugins, platforms, new forms of garbage collection, new vm configurations such as packaging as a DLL, or what ever else is /absolutely/ something we should support and encourage.  But that doesn't mean throwing away reproducibility and versioning.  It probably implies much better documentation.  But things are in a good state to improve:

- anyone can clone the opensmalltalk/vm repository

- there is a script in images to build a current VMMaker image so anyone can easily produce a VMMaker image in which to simulate, author and generate.  And the generation is fine to the right place in the opensmalltalk/v clone for it to be committed when ready

- because generation and check-in are separate steps one can get all the bits together (e.g. plugin generated under src/plugins, plugins.int or plugins.ext files updated on relevant platforms, special plugin majefiles containing support library references, etc) and make one commit instead of many noisy failing intermediate steps

So perhaps take a step back and ask what is the support you need, both in terms of documentation, code and infrastructure, that will help you experiment.

> Regards .. Subbu


More information about the Vm-dev mailing list