Posted by Holger Freyther on Jun 02, 2017; 11:06am
URL: https://forum.world.st/OSProcess-fork-issue-with-Debian-built-VM-tp4947326p4948954.html

 

> On 2. Jun 2017, at 18:43, K K Subbu <[hidden email]> wrote:
>

Hey!


> +1. I would go further and propose that plugins, other than those which are integral to VM[1], be moved into separate projects and built in their own tree with no references to vm source paths. They should be free to organize their platform-specific and platform-independent code and makefiles.

why? How many plugins are used that don't ship with the pharo-vm (or squeakvm)? I have to say I like the pharo-vm approach a lot where the VMMaker* packages and generated sources sit next to each other.

Let's compare two options with the OSProcess timeline at hand


What happened:

* I compile with a new compiler, look at the compiler warning and agree with it
* David Lewis agrees with my analysis and fixes it
...
* Max runs into a crash
* Max debugs a crash.. hours? days?
* Max involves others
...
* I have to debug the crash myself..
* I notice that the fix is not there yet
* I have to wait for someone privileged to regenerate the source (black magic?)


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
* New VM will be build and regenerates sources on the fly
* Max never runs into the problem

Let's do it the Smalltalk way? Make simple things simple and complex (allow externally maintained plugins) possible?

have a nice weekend

        holger