<html><head></head><body dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class="ApplePlainTextBody">Hi, <br><br>I’m sorry, but all of this is a mess. <br>Why not simply require that all plugins that are part of the VM lives in the same place?<br><br>In an ideal world, that unified place would be VMMaker repository itself, but if not… why not a /VMPlugins project?<br><br>cheers, <br>Esteban<br><br><blockquote type="cite">On 2 Jun 2017, at 02:59, David T. Lewis <lewis@mail.msen.com> wrote:<br><br><br>On Thu, Jun 01, 2017 at 04:50:40PM -0700, Eliot Miranda wrote:<br><blockquote type="cite">Hi David,<br><br> what would help here is if all the VMConstruction-Plugins- packages<br>lived in a single repository. So instead of<br>http://www.squeaksource.com/{AioPlugin,OSProcessPlugin,XDCP} there was<br>http://www.squeaksource.com/OSConnectivity or<br>http://www.squeaksource.com/AdditionalPlugins or some such. Checking lots<br>of different repositories for changes is tedious. If there was one I could<br>keep a repository inspector open and refresh.<br><br>Alternatively we need Update URLs instead of Update URL.<br><br></blockquote><br>Hi Eliot,<br><br>Try using update maps. There is already an update stream for VMMaker (as opposed<br>to VMMaker.oscog), so you can name your update maps "update.oscog" to<br>distinguish them from the existing "update" maps.<br><br>Then do something like this:<br><br> VMMaker class>>updateFromServer<br><br> "VMMaker updateFromServer"<br><br> (Smalltalk hasClassNamed: #MCMcmUpdater)<br> ifTrue: [ | updater |<br> updater := Smalltalk at: #MCMcmUpdater.<br> (updater respondsTo: #updateFromRepository:baseName: )<br> ifTrue: [ "newer MCMcmUpdater supports multiple update streams per repository"<br> updater perform: #updateFromRepository:baseName:<br> withArguments: { 'http://source.squeak.org/VMMaker' . 'update.oscog' } ]<br> ifFalse: [ "older versions of MCMcmUpdater"<br> updater updateFromRepositories: #('http://source.squeak.org/VMMaker') ] ]<br> ifFalse: [self notify: 'MonticelloConfigurations not installed in this image']<br><br>I don't mind moving the plugins I have written, but I would really like to<br>encourage more people to write and contribute their own VM plugins. For<br>that I think it is very helpful for someone to be able to start their own<br>small plugin experiment in squeaksource/whatever, and offer it for other<br>people to build and use, and maybe later for inclusion in supported VMs if<br>it turns out to be of general interest. I might be a little biased here<br>because that is how I got involved in this community myself, and I do think<br>that it is a good thing to encourage.<br><br>Dave<br><br><br><blockquote type="cite">On Thu, Jun 1, 2017 at 5:38 AM, Nicolas Cellier <<br>nicolas.cellier.aka.nice@gmail.com> wrote:<br><br><blockquote type="cite"><br>Hi Holger,<br>thanks for reminding this.<br>So we must regenerate source from<br>*VMConstruction-Plugins-OSProcessPlugin.oscog-dtl.56*<br>I just did that for nice.55 (for a 2nd time), a pity that I missed the<br>more recent one...<br>It's better to send such message to vm-dev as you did, I thnk audience is<br>broader for VM concerns than pharo-dev<br><br>2017-06-01 11:32 GMT+02:00 Holger Freyther <holger@freyther.de>:<br><br><blockquote type="cite"><br><br><blockquote type="cite">On 16. May 2017, at 20:57, Max Leske <maxleske@gmail.com> wrote:<br><br><br>Hi,<br></blockquote><br>Hi!<br><br><br><blockquote type="cite">We're building the pharo.cog.spur VM on Debian (32 bits, itimer, on 64<br></blockquote>with compat libs). Unfortunately, we're running into one particular problem<br>with OSProcess. Some primitives like primitiveFileStat work but forking a<br>child process (e.g. with #waitForCommand) produces a segfault. We've tried<br>to find a difference between our build and the VM downloaded from bintray<br>but we weren't very successful. One difference we do see is that our libc6<br>version is 2.19, while the one used in the travis build is 2.15 (although<br>both binaries use the 2.19 version at runtime).<br><blockquote type="cite"><br>I'm aware that OSProcess hasn't been tagged as officially ready for<br></blockquote>Pharo 6 (which is where I'm using it). However, all of my tests with the<br>prebuilt VM's have been successful.<br><br><br>I wanted to look at the issue and it seems that the compiler warning<br>about out of bound array access[1] in restoreDefaultSignalHandlers remains<br>unfixed? I reported it in February and the plugin code doesn't seem to be<br>regenerated since then. Some of my PRs are still unreviewed so does<br>somebody else want to try her or his luck?<br><br>I think this[2] and that[3] are candidates to be merged?<br><br><br>holger<br><br><br><br><br>[1] http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/<br>2017-February/127495.html<br>[2] http://www.squeaksource.com/@ZzgxlHh7fhZ1n9Zo/rdfZ1xy3<br>[3] http://www.squeaksource.com/@ZzgxlHh7fhZ1n9Zo/wVMJyP1K<br></blockquote><br><br><br><br></blockquote><br><br>-- <br>_,,,^..^,,,_<br>best, Eliot<br></blockquote></blockquote><br></div></body></html>