[Vm-dev] [Pharo-dev] usage of Pharo-vm repository [was Latest Debian, Ubuntu and CentOS packages of the pharo-vm]

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Sat Aug 26 20:04:13 UTC 2017

2017-08-23 17:14 GMT+02:00 Holger Freyther <holger at freyther.de>:

> > On 18. Aug 2017, at 23:56, Nicolas Cellier <nicolas.cellier.aka.nice@
> gmail.com> wrote:
> Hi!
Hi Holger,

> > Are the packaging stuff in opensmalltalk too, or just in pharo-vm?
> > It would be great to move all to opensmalltalk.
> > What is specificity of pharo-vm repository now?
> the packaging bits are in the pharo-vm repository only. What is pharo
> specific from a technical point of view is that I re-generate the sources
> before building the source package. There is a Makefile[1] that drives
> building the source package and the actual compilation is here[2].
Ah yes,
there have been some propositions to perform this task in a specific
development branch in opensmalltalk, but so far nothing has happened...

As Eliot explained once, we currently have no guaranty to regenerate
identical sources (mostly we observe signed/unsigned type swapping).
Probably type inference depends on the order of MethodDictionary scanning
which is random.
Of course it should be fixed, but someone has to do it....
Untill then, generated sources have to be versionned, there is no
alternative way,
otherwise we don't have reproducible artefacts...
A specific build could suddenly start crashing without any easy way to
reproduce and debug, think of it twice before regenerating sources...

Porting VM to another OS without having to regenerate still is another
valuable feature.
I also find the ability to track generated-source diffs valuable:
it's a complementary check, especially when changing code-generation part.
That's why we continue to version generated source, whatever the ready-made

Once the code generation is stable, it can be done by a bot.
But don't forget that not all VMMaker commit will produce interesting C
sources, because a great deal of development happens in VM-Simulator, not
in C - at least the major features that Eliot and Clement are after.

> I don't want this to sound offensive but the non-technical part is that it
> seems easier to get changes into the PharoVM than into opensmalltalk-vm.
> One example could be the FilePlugin and my attempt to use inotify without
> periodic polling (wastes power, adds latency and increases your bill in
> cloud computing, etc).
Backporting upstream changes between squeak/newspeak vm and pharo vm was
not sustainable, and mostly one way (unfair).
That's also what motivated the switch to opensmalltalk: it's dialect

Of course, changes in opensmalltalk must be done with retro and cross
compatibility constraints which may require a little more effort, but at
worse we have dialect-specific #ifdef directives.
Remember that VM stability is valued not only because there are grumpy old
and conservative fellows here ;)
Without VM stability, how could we have a smooth and sustainable overall
development process?

That said, I hate nothing much than stale pull request and it's clearly the
next obstacle to contributions (in case vm contributions was easy enough).
If that's the case, that's regrettable. So don't hesitate to complain here.

It doesn't mean that every PR has to be accepted.
Ideally, they should be closed in a reasonnable time,
with comments telling why or what needs to be improved for inclusion...
IMO in absence of dedicated paid staff, we should start closing old PR
(exactly as Pharo is closing stale fogbugz entries). it's not satisfying,
but letting a long list of open PR is worse.

Non-technically speaking, Esteban is among the core developpers of
opensmalltalk, so it should be as easy to integrate changes as in a
pharo-vm copy, modulo cross and retro compatibility concerns.
We are supposed to have non regression tests to lower the level of heroism
of the poor human integrators that we all are.

> I am happy to answer questions about the packaging process or the
> OBS/travis-ci integration!
> holger
I hope someone will jump at the opportunity :)

> [1] https://github.com/pharo-project/pharo-vm/blob/master/Makefile.debian
> [2] https://github.com/pharo-project/pharo-vm/blob/master/
> packaging/pharo6-vm-core/debian/rules
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20170826/04dc64fd/attachment.html>

More information about the Vm-dev mailing list