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

Holger Freyther holger at freyther.de
Sun Jun 4 16:40:07 UTC 2017


> On 2. Jun 2017, at 22:40, Eliot Miranda <eliot.miranda at gmail.com> wrote:
> 
> 
> Hi Holger,

Hey Eliot!


>    I have no disagreement with your time lines, but I do disagree with the black magic accusation, and you introduce your own piece of magic (see below).

in the end it is a word and a very subjective thing. I used to spend a lot of time working on OpenEmbedded to build Linux distributions. If one didn't understand what needs to be done to build a distribution and didn't know how the system worked, it seemed like black magic.


> and then checks in the new sources.  David should have been able to do this.  The process is not documented.

Let's say I saw the code was not regenerated, what could I have done? Figure out the not documented process, make a PR and hope it is being reviewed within a month or two? It might not be black magic but quite a high barrier and maybe higher than necessary?



>> My preferred option
>> 
>> * I compile with a new compiler, look at the compiler warning and agree with it
>> * David Lewis agrees with my analysis and commits/pushes the fix to mc/ directory
> 
> You're glossing over some steps here.  Note that the fix is in the Smalltalk source, upstream of the C source.

I commit my Smalltalk code to the mc/ directory and the CI will build a VMMaker image and generate the C sources.


> The missing step is that the plugin source is regenerated .  As a Smalltalk-side-of-the-business person David knows how to regenerate source. David, why didn't you regenerate? [honest Q, not an accusation]

Done by the CI in pharo-vm. And besides being done by the CI, the script that builds the VMMaker image and generates the C sources provide an executable documentation of the process. So anyone capable of committing Smalltalk code to the mc/ directory can generate new sources.


> One *mustn't* manually fix the generated source because doing so means

I didn't argue about that. That would be the beginning of the end.



> One *must* regenerate from an unmodified checked in Monticello package because doing so means
> - the C source is version stamped as originating from that package and so one can locate the correct version of the Smalltalk from which it derived 

* The CI works by definition from an unmodified checked in Monticello package.
* tags, source uploads, debian source packages can provide as 1:1 mapping from version to archived source

skipping stuff here to keep the answer short.




>> * New VM will be build and regenerates sources on the fly
> 
> How does this work? Seems like magic to me.  Source has to be generated from a VMMaker image.  We need to regenerate source only for that which has changed, not for the entire generated source.  But right now that's problematic because of the time issues I mention above.

We are in the phase of computing where human time is (once again) more expensive that computing time. So the magic is that  some labor can be outsourced to a shell script. The nice thing with a shell script is one can observe each step (set -x) it is doing. For "stable" code generation review one can still check-in and compare the generated code.

I do my deployments on Debian with debian packages. Since a couple of weeks commits to the pharo-vm will generate a debian source package with generated C source and upload it. At the place below one can see the uploads and the difference in generated code from one version to another.

https://build.opensuse.org/package/revisions/devel:languages:pharo:latest/pharo5

have a nice day

	holger


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20170605/8d068e69/attachment.html>


More information about the Vm-dev mailing list