On Fri, Nov 19, 2010 at 03:56:26PM -0200, Casimiro de Almeida Barreto wrote:

Em 19-11-2010 15:39, Mike Hales escreveu:

...

Thanks, that's just want I wanted. And thanks Sean for the tip on the http://forum.world.st/ index. That's pretty handy having all the lists together in one spot.

Mike

Mike Hales Engineering Manager KnowledgeScape www.kscape.com http://www.kscape.com

BTW, if you're running squeak over CogVM it wont work... there are incompatibilities between OSProcess, CommandShell and OSProcessPlugin and cog.

Interesting enough, if I do:

| str |

str := (PipeableOSProcess command: 'ls -l') upToEnd.

It will return and empty ByteString but will fail to read output from stdOut.

This is just a timing glitch. Try this instead and I think you will get the results you want. This works on both Cog and the interpreter VM:

(PipeableOSProcess command: 'ls -l') upToEndOfFile

Piping to and from an external process can be a bit tricky. A program like /bin/ls will exit only after you close the pipe to its standard input (the #command: method does this for you). After that pipe closes, the /bin/ls program will flush its standard output stream to the pipe that is connected back to Squeak. Some time after that, the data will become available for Squeak to read. When you do #upToEnd, you are reading all available data on that pipe, and if you happen to read it before it is all available, you get an empty string. The #upToEndOfFile keeps trying to read until the pipe is actually closed (when /bin/ls exits), so this makes sure you get all of the output data even when you are running on a really fast Cog VM :)

Forking PipeableOSProcess won't work when using cog.

like:

ps := PipeableOSProcess forkHeadlessSqueakAndDoThenQuit: [ ... ]

will fail crashing cog (memory fault). At least under linux.

As far as I know, then only part of OSProcess/CommandShell that does not work in Cog is the #forkSqueak methods. Unfortunately, #forkSqueak is used extensively in the unit tests, so be careful about running those under Cog. But all other OSProcess and CommandShell functions seem to work fine in Cog.

You may get a warning dialog about AioPlugin not present. This is because the plugin was not included in the Cog VM, and you can safely ignore the warning.

Dave

On Sat, Nov 20, 2010 at 10:52:20AM -0800, Eliot Miranda wrote:

On Sat, Nov 20, 2010 at 9:07 AM, David T. Lewis lewis@mail.msen.com wrote:

...

As far as I know, then only part of OSProcess/CommandShell that does not work in Cog is the #forkSqueak methods. Unfortunately, #forkSqueak is used extensively in the unit tests, so be careful about running those under Cog. But all other OSProcess and CommandShell functions seem to work fine in Cog.

Any idea what it is about forkSqueak that breaks Cog?

First, I need to be clear in saying that the Cog VM is not crashing, the OSPP plugin is doing something that is *causing* the VM to crash. The #forkSqueak method in the primitive turns off the interval timer prior to doing the fork() and reestablishes if afterwards. This is to prevent the child Squeak process from crashing on a timer interrupt. Timers are reestablished in both the parent and child after the fork(), and both processes carry on happily afterwards. Presumably this is doing something nasty to the Cog VM, but I'm not sure exactly where the problem is (oddly, it shows up as a X protocol error, but that's clearly not the root cause).

Aside from the VM crash problem, which clearly needs to be fixed in OSPP, there is the secondary issue of making #forkSqueak actually work properly on a Cog VM. I have not really looked into this, but I expect it to be non-trivial because Cog requires pthreads to perform timer functions for the VM, and I don't think that pthreads survive a fork(). So I expect at minimum we would need some function callable from a primitive that will initialize a new timer thread in a newly forked Cog VM. But I need to emphasize that I have not actually looked at this, I'm just speculating as to what would need to be done.

To be prefectly honest I have been stumped by libtool, which so far has been unwilling to permit me to build a 32 bit Cog VM on my 64 bit Linux system. I suspect that this may be part of the reason that Ian dumped the old build system in favor of CMake. I'm sure I'm doing something dumb here, but for the moment I can't debug OSPP because I can't built a 32-bit Cog VM with the old build system on my 64-bit Linux system.

FWIW, I am feeding this to the configure script, which is enough to get the interpreter to build, but the plugins (including vm-display-X11) are still barfing on 32/64 bit build issues:

../../platforms/unix/config/configure LDPATH="/lib:/usr/lib" LDFLAGS="-m32" CFLAGS="-g -O2 -m32 -msse2 -D_GNU_SOURCE -DNDEBUG -DITIMER_HEARTBEAT=1 -DNO_VM_PROFILE=1 -DCOGMTVM=0 -DDEBUGVM=0" LIBS=-lpthread

Dave

Hi Mike, Writing to you in my Smalltalk Solutions organizing capacity. I'm looking around for possible talks, and just scrolling back through recent mailing list postings I saw your name, and remembered you as doing some pretty interesting work, but I don't think we've ever had you speak at Smalltalk Solutions. Is that something you might be interested in doing? OK, I'm casting about because the submission deadline is actually tomorrow, but if you're interested, we can put you down as possible and you don't have to get things together quite that quickly. Thanks, Alan

On 2010-11-19 12:39 PM, Mike Hales wrote:

Thanks, that's just want I wanted. And thanks Sean for the tip on the http://forum.world.st/ index. That's pretty handy having all the lists together in one spot.

Mike

Mike Hales Engineering Manager KnowledgeScape www.kscape.com http://www.kscape.com

On Fri, Nov 19, 2010 at 10:37 AM, Casimiro de Almeida Barreto <casimiro.barreto@gmail.com mailto:casimiro.barreto@gmail.com> wrote:

Em 19-11-2010 15:22, Casimiro de Almeida Barreto escreveu:

...

Em 19-11-2010 15:00, Mike Hales escreveu:

...

I must be missing something obvious, but how can I get the
results of executing an external command.

OSProcess command: 'ls /etc'

Try:

| pc1 |

    pc1 := (PipeableOSProcess command: 'ls -l' ) output.

    Transcript show: pc1.

Oooopsss... error:

    Transcript show: pc1 upToEnd.

Or else:

    Transcript show: (PipeableOSProcess command: 'ls -l') upToEnd;
cr.

...

...

returns me an ExternalUnixProcess. I just want a string of the
command results. This seems to basic to be hard, but I'm
stumped. In VisualWorks and GemStone this is just a one liner.

Thanks,

Mike