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

K K Subbu kksubbu.ml at gmail.com
Sat Jun 3 16:47:00 UTC 2017


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.

> - 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.

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.

> - 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.

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.

Regards .. Subbu


More information about the Vm-dev mailing list