Fwd: Re: [squeak-dev] Using OSProcess

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

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.

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

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.

Forking PipeableOSProcess won't work when using cog.

like:

ps := PipeableOSProcess forkHeadlessSqueakAndDoThenQuit: [ ... ]

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

Best regards,

CdAB

On Fri, Nov 19, 2010 at 03:56:26PM -0200, Casimiro de Almeida Barreto wrote:
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

Hi David,

On Sat, Nov 20, 2010 at 10:52:20AM -0800, Eliot Miranda wrote:
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

On Sat, Nov 20, 2010 at 10:52:20AM -0800, Eliot Miranda wrote:
Aha, I found the first half of the problem. The X11 display control primitives
are now in the separate XDisplayControlPlugin, but I neglected to put a
check in #forkSqueak to make sure that the plugin is present. The result
is that when XDisplayControlPlugin is missing, the child Squeak VM is unable
to disconnect from the X11 server and continues reading and writing on the
same socket used by the parent. This produces X protocol errors followed
by a VM crash. Hard to believe that my quality control department let this
one get through ;)

I can reproduce this on an interpreter VM, so it is not a Cog issue. The
fix is in OSProcess on SqueakSource (OSProcess-dtl.58).

For Cog on Linux, I recommend including both AioPlugin and XDisplayControlPlugin
along with OSProcessPlugin.

I can't do a Cog build on my system at the moment, so if someone can confirm
that adding XDisplayControlPlugin and AioPlugin cures the Cog crash problem,
I'd appreciate the feedback.

Note that I still expect problems with forkSqueak on Cog related to restarting
the timer thread, but that will effect only the child process, and the above
should cure the VM crash issue.

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

On Fri, Nov 19, 2010 at 10:37 AM, Casimiro de Almeida Barreto <[hidden email]> 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

OK, clearly I should look who I'm responding to before I actually send emails. That last one was intended to go to Mike personally. However, the general invitation applies to all anyway. We're looking for interesting talks for Smalltalk Solutions, and if you think you might be interested, please go to http://www.smalltalksolutions.com and put in a submission or just email me.

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

On Fri, Nov 19, 2010 at 10:37 AM, Casimiro de Almeida Barreto <[hidden email]> 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

-- 
Alan Knight [|], Engineering Manager, Cincom Smalltalk
[hidden email]
[hidden email]
http://www.cincom.com/smalltalk