Hi,

I’m sorry, but all of this is a mess.
Why not simply require that all plugins that are part of the VM lives in the same place?

In an ideal world, that unified place would be VMMaker repository itself, but if not… why not a /VMPlugins project?

cheers,
Esteban

On 2 Jun 2017, at 02:59, David T. Lewis <[hidden email]> wrote:


On Thu, Jun 01, 2017 at 04:50:40PM -0700, Eliot Miranda wrote:

Hi David,

   what would help here is if all the VMConstruction-Plugins- packages
lived in a single repository.  So instead of
http://www.squeaksource.com/{AioPlugin,OSProcessPlugin,XDCP} there was
http://www.squeaksource.com/OSConnectivity or
http://www.squeaksource.com/AdditionalPlugins or some such.  Checking lots
of different repositories for changes is tedious.  If there was one I could
keep a repository inspector open and refresh.

Alternatively we need Update URLs instead of Update URL.

Hi Eliot,

Try using update maps. There is already an update stream for VMMaker (as opposed
to VMMaker.oscog), so you can name your update maps "update.oscog" to
distinguish them from the existing "update" maps.

Then do something like this:

VMMaker class>>updateFromServer

    "VMMaker updateFromServer"

    (Smalltalk hasClassNamed: #MCMcmUpdater)
        ifTrue: [ | updater |
            updater := Smalltalk at: #MCMcmUpdater.
            (updater respondsTo: #updateFromRepository:baseName: )
                ifTrue: [ "newer MCMcmUpdater supports multiple update streams per repository"
                    updater perform: #updateFromRepository:baseName:
                            withArguments: { 'http://source.squeak.org/VMMaker' . 'update.oscog' } ]
                ifFalse: [ "older versions of MCMcmUpdater"
                        updater updateFromRepositories: #('http://source.squeak.org/VMMaker') ] ]
        ifFalse: [self notify: 'MonticelloConfigurations not installed in this image']

I don't mind moving the plugins I have written, but I would really like to
encourage more people to write and contribute their own VM plugins. For
that I think it is very helpful for someone to be able to start their own
small plugin experiment in squeaksource/whatever, and offer it for other
people to build and use, and maybe later for inclusion in supported VMs if
it turns out to be of general interest. I might be a little biased here
because that is how I got involved in this community myself, and I do think
that it is a good thing to encourage.

Dave

On Thu, Jun 1, 2017 at 5:38 AM, Nicolas Cellier <
[hidden email]> wrote:

Hi Holger,
thanks for reminding this.
So we must regenerate source from
*VMConstruction-Plugins-OSProcessPlugin.oscog-dtl.56*
I just did that for nice.55 (for a 2nd time), a pity that I missed the
more recent one...
It's better to send such message to vm-dev as you did, I thnk audience is
broader for VM concerns than pharo-dev

2017-06-01 11:32 GMT+02:00 Holger Freyther <[hidden email]>:

On 16. May 2017, at 20:57, Max Leske <[hidden email]> wrote:


Hi,

Hi!

We're building the pharo.cog.spur VM on Debian (32 bits, itimer, on 64

with compat libs). Unfortunately, we're running into one particular problem
with OSProcess. Some primitives like primitiveFileStat work but forking a
child process (e.g. with #waitForCommand) produces a segfault. We've tried
to find a difference between our build and the VM downloaded from bintray
but we weren't very successful. One difference we do see is that our libc6
version is 2.19, while the one used in the travis build is 2.15 (although
both binaries use the 2.19 version at runtime).

I'm aware that OSProcess hasn't been tagged as officially ready for

Pharo 6 (which is where I'm using it). However, all of my tests with the
prebuilt VM's have been successful.


I wanted to look at the issue and it seems that the compiler warning
about out of bound array access[1] in restoreDefaultSignalHandlers remains
unfixed? I reported it in February and the plugin code doesn't seem to be
regenerated since then. Some of my PRs are still unreviewed so does
somebody else want to try her or his luck?

I think this[2] and that[3] are candidates to be merged?


holger




[1] http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/
2017-February/127495.html
[2] http://www.squeaksource.com/@ZzgxlHh7fhZ1n9Zo/rdfZ1xy3
[3] http://www.squeaksource.com/@ZzgxlHh7fhZ1n9Zo/wVMJyP1K

--
_,,,^..^,,,_
best, Eliot