On 18 Jul 2016, at 10:28 , tim Rowledge <tim@rowledge.org> wrote:

On 17-07-2016, at 9:52 AM, David T. Lewis <lewis@mail.msen.com> wrote:

On Wed, Jun 08, 2016 at 11:42:57AM -0700, tim Rowledge wrote:

I finally got a moment to look at this - not that I really have much clue about the whole unix process thing - and it appears that something is odd with the compiled code in the plugin.

My test is very simple - run the UnixProcess class>listDirectory example. It exits with a segfault and the forkAndExec??? method as the last thing on the stack.

I build a debug vm (and had some fun with asserts and the ARM fp offset in the process, all fixed now) and??? it doesn???t fail. I???ve tried compiling the plugin with varying levels of optimisation, since we???ve fairly regularly seen problems there, and even at -O0 it fails. So debug -> OK, no-debug -> boom. Nice.

Ideas?

Hi Tim,

It looks like the oscog branch of OSPP is broken. I tried OSProcess on
my new Raspberry Pi, and it fails as you describe. I recompiled using
source from my unaltered main branch of the plugin, and it works fine.

A quick fix is to just copy the generated source from the interpreter VM
(src/plugins/UnixOSProcessPlugin/UnixOSProcessPlugin.c) and use it in your
Spur VM build.

I finally got a copy in the right place and built it with no problems.

#forkSqueak is still broken (no display opens for the child Squeak) but
that seems to be a problem elsewhere in the platforms code. It used to work
in Cog, but I have not hunted down the regression.

listDirectory works, forkSqueakAndDo: worked, spawnTenHeadlessChildren worked, catAFile worked … all pretty good news. Now all we have to do is get that file integrated.

Oh, I noticed the startSwiki… method, which looks very out of date. Do we have working swiki package(s) these days? It must be a decade or more since I had reason to look! The one on SM seems about that old...

tim
--
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim
"Wibble" said Pooh the stress beginning to show.