OSProcessPlugin and AioPlugin for OS-X

I've build a new OSProcessPlugin  (4.2.4)

http://wiki.squeak.org/squeak/3349  and

a newly generated AioPlugin V2.2

http://wiki.squeak.org/squeak/3384

for testing purposes. If someone can test them on os-x 10.3, 10.4 on  
macintel and powerpc, that would be helpful.


This means the CommandShell Sunits now mostly run (1 failure) on the  
macintosh carbon based VM, well
at least on os-x 10.5.1 on macintel.


Please note not all of the OSProcess tests will run, some cause the VM  
to crash when they attempt to fork the VM since
forking the carbon based VM is not allowable.  Corrupts memory and  
crashes really fast.


--
=
=
=
========================================================================
John M. McIntosh <[hidden email]>
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
=
=
=
========================================================================

Hi John,

how much do you depend on Carbon in the Mac VM ? Do you use it for
stuff besides the Displaying and UI ?

On 24/12/2007, John M McIntosh <[hidden email]> wrote:

--
Damien Pollet
type less, do more [ | ] http://typo.cdlm.fasmz.org

(a) Carbon is going away...
(b) Cocoa is 32/64bit
(c) Ian and I have been talking a bit about what to do, nothing  
decided yet.


The carbon part is used for:

1) the 1/60 timer
2) file path name encoding/translation
3) apple events
4) clipboard interaction
5) Display
6) keyboard/mouse
7) menu bar
8) openGL
9) drag/drop
10) internet configuration information
11) alias support for os-9 file aliases

Other items shared by the unix os-x vm and use core foundation logic  
or BSD calls, but aren't 64 bit aware would be

12) Midi support
13) joystick support
14) sound support
15) UUID generation
16) Socket support

On Dec 25, 2007, at 9:32 AM, Damien Pollet wrote:

> Hi John,
>
> how much do you depend on Carbon in the Mac VM ? Do you use it for
> stuff besides the Displaying and UI ?

--
=
=
=
========================================================================
John M. McIntosh <[hidden email]>
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
=
=
=
========================================================================

I'm confused.  Do I need to build these plugins myself, or are there
binaries available somewhere?

Thanks,
Wilkes

On Dec 24, 2007 1:12 AM, John M McIntosh
<[hidden email]> wrote:

I've uploaded these to my idisk and ftp site found via

http://www.smalltalkconsulting.com/squeak.html

they are in the experimental folder.

I know they work on powerpc/macintel based 10.5.1 (Leopard) machines.

untested is powerpc/macintel 10.4 or powerpc 10.3


On Dec 25, 2007, at 1:29 PM, Wilkes Joiner wrote:

--
=
=
=
========================================================================
John M. McIntosh <[hidden email]>
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
=
=
=
========================================================================

Thanks.  I can do some poking around on 10.4 PPC.

On Dec 25, 2007 4:45 PM, John M McIntosh
<[hidden email]> wrote:

Thanks for this summary. BTW are there still plans for adding the ft2
and biblt plugins in the main svn repository?

On 25/12/2007, John M McIntosh <[hidden email]> wrote:

--
Damien Pollet
type less, do more [ | ] http://typo.cdlm.fasmz.org

On Sun, Dec 23, 2007 at 11:12:38PM -0800, John M McIntosh wrote:
Hi John,
Thanks for doing this. I've borrowed a Mac laptop - very nice machine
BTW - and downloaded your test bundles. I fumbled around enough to get
Squeak running (all of this user friendly stuff is rather jarring at
first). Imagine my surprise when CommandShell just up and worked.

I'm not sure how to identify this machine, but it's Intel-based and
according to 'uname -a' it is this:

Darwin colleen-moynihans-computer.local 8.10.1 Darwin Kernel Version 8.10.1: Wed May 23 16:33:00 PDT 2007; root:xnu-792.22.5~1/RELEASE_I386 i386 i386

> This means the CommandShell Sunits now mostly run (1 failure) on the  
> macintosh carbon based VM, well
> at least on os-x 10.5.1 on macintel.

I've made updates to the CommandShell and OSProcess tests cases to address
problems with OS X path name and file protection conventions versus
vanilla Unix/Linux. The updates are on SqueakSource (but not SqueakMap
or Universes yet). At this point we have:

Tests-CommandShell all pass (!)
  CommandShellTestCase => green
  ExpressionEvaluatorTestCase => green
  InternalPipeTestCase => green
  PipelineEventsTestCase => green
  ShellSyntaxTestCase => green

Tests-OSProcess, some pass:
  AioEventHandlerTestCase => green
  OSPipeTestCase => green
  UnixProcessAccessorTestCase => green after fixes, see SqueakSource
  UnixProcessFileLockTestCase => green

The following crash the VM due to #forkSqueak issues on OS X:
  UnixProcessUnixFileLockingTestCase
  UnixProcessWin32FileLockingTestCase
  UnixProcessTestCase

> Please note not all of the OSProcess tests will run, some cause the VM  
> to crash when they attempt to fork the VM since
> forking the carbon based VM is not allowable.  Corrupts memory and  
> crashes really fast.

The #forkSqueak problem is nasty and unfortunate. At the very least we
don't want it crashing the VM. I haven't figured out how to compile
things on a Mac yet, but if I get some more time with this OS X laptop
I'd like to figure it out and maybe inject some more sensible behavior
into #forkSqueak.

Dave

> Darwin colleen-moynihans-computer.local 8.10.1 Darwin Kernel Version  
> 8.10.1: Wed May 23 16:33:00 PDT 2007; root:xnu-792.22.5~1/
> RELEASE_I386 i386 i386


That would be an macIntel  machine.

10.5.1 is
Darwin Otter.local 9.1.0 Darwin Kernel Version 9.1.0: Wed Oct 31  
17:46:22 PDT 2007; root:xnu 1228.0.2~1/RELEASE_I386 i386

a powerpc 10.4.11 machine shows as
Darwin Kernel version 8.11.0: Wed Oct 10


So likely that is a macintel machine running 10.4.10

This morning I borrowed the kid's old powerbook which is 10.4.11  
powerpc.

Unfortunately after loading all the changes from squeakmap I find the  
pipeline tests don't run. So let me drag an os-x
developer environment to that machine and see if I can figure out why  
it doesn't work

--
=
=
=
========================================================================
John M. McIntosh <[hidden email]>
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
=
=
=
========================================================================

Ok, I did a bit more poking at this yesterday and find all the  
pipeline tests fail on powerpc 10.4.11. I'm not sure why, oddly it  
sometimes works so there must be some timing issue? In cross checking  
I can occasionally get the macintel 10.5.1 version to crash the VM

However i'll note running the powerpc version under gdb works fine.  
Could it be that running as a double-clicked application stdin/stdout  
isn't opened and causing issues?


On Dec 26, 2007, at 1:07 PM, David T. Lewis wrote:

--
=
=
=
========================================================================
John M. McIntosh <[hidden email]>
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
=
=
=
========================================================================

On Thu, Dec 27, 2007 at 11:38:31AM -0800, John M McIntosh wrote:
> Ok, I did a bit more poking at this yesterday and find all the  
> pipeline tests fail on powerpc 10.4.11. I'm not sure why, oddly it  
> sometimes works so there must be some timing issue? In cross checking  
> I can occasionally get the macintel 10.5.1 version to crash the VM

It's entirely possible that there are timing issues. The
CommandShellTestCase tests (and CommandShell in general) use
lots of Processes both in the command pipelines themselves, and
in the buffered async I/O streams that are used for the pipes.
It took quite a while to get this running reliably, and even
now I will occasionally get test failures when running the full
test suite even though the individual tests run without problems.
So I would not be entirely surprised if a different combination
of hardware speed and VM were to flush out one or two more glitches.
Also, there has been a fair amount of discussion about patches
to Delay and friends on the Seaside list, and I would not be
surprised if the CommandShell test suite is vulnerable to some
of those same issues.

> However i'll note running the powerpc version under gdb works fine.  
> Could it be that running as a double-clicked application stdin/stdout  
> isn't opened and causing issues?

I guess it's possible. I don't know where those streams get redirected
when running as a "normal" Mac application, but anything that affects
timing and overall performance of the VM might have an effect.

One other thing that I use as an overall torture test for CommandShell
is to open two or three command shell windows, and in each of them
run the command "$ ls -lR /". This generates tons of I/O and window
updating. If you leave these running to completion without getting
a red window of death then things are looking pretty good.

Note: Use <ctl>C in the command window to interrupt the "ls -lR /"
process when you get tired of watching it. Also with respect to
<ctl>C events, note Mantis <http://bugs.squeak.org/view.php?id=6827>.
My current workaround for this in CommandShell causes the copy
text shortcut to be broken in a command shell, but does ensure
that you can use <ctl>C to interrupt long running external processes
from the command shell.

Dave