some problems for an introductory python test

[Hope Rouselle]

Dennis Lee Bieber <wlfraed at ix.netcom.com> writes:

> On Thu, 12 Aug 2021 06:15:28 +1000, Chris Angelico <rosuav at gmail.com>
> declaimed the following:
>
>>The default command interpreter and shell on OS/2 was fairly primitive
>>by today's standards, and was highly compatible with the MS-DOS one,
>>but it also had the ability to run REXX scripts. REXX was *way* ahead
>>of its time. It's a shell language but remarkably well suited to
>>building GUIs and other tools (seriously, can you imagine designing a
>>GUI entirely in a bash script??). It had features that we'd consider
>>fairly normal or even primitive by Python's standards, but back then,
>>Python was extremely new and didn't really have very much mindshare.
>>REXX offered arbitrary-precision arithmetic, good databasing support,
>>a solid C API that made it easy to extend, integrations with a variety
>>of other systems... this was good stuff for its day. (REXX is still
>>around, but these days, I'd rather use Python.)
>>
> 	I was spoiled by the Amiga variant of REXX. Most current
> implementations (well, Regina is the only one I've looked at) can just pass
> command to the default shell. The Amiga version took advantage of Intuition
> Message Ports (OS supported IPC). That allowed it to "address
> <application>" any application that defined an ARexx port, allowing ARexx
> to be used as a scripting language for that application (and with multiple
> applications, one could easily fetch data from app1 and feed it to app2).
> ARexx did not, to my memory, implement arbitrary precision math.
>
> 	Any statement in a REXX script that was not parsable as REXX would be
> passed on the currently "addressed" command host.
>
> 	Granted, the fact that the Amiga used a shared common address space for
> all running applications made IPC quite easy -- one looked up the
> application message port, then added a small packet to the linked list
> associated with the port. That small packet basically held the address of
> the message port for returning data, and the address of the data being
> passed. The closet thing I've seen to that capability on systems with
> process-isolated virtual memory is (Open)VMS "mailbox" structures. The
> difference being that the entire data had to be written (QIO) to the
> mailbox, and the receiver had to read (another QIO call) the message --
> this allowed the address space to change.
>
> 	I've not seen anything equivalent in my light perusal of the Win32 API
> (the various guide books aren't layed out in any way to be a reference),
> and Linux seems to use UNIX sockets for IPC... No way to search for a
> connection point by name...

I don't know anything about Amiga, REXX et cetera, so I might be totall
off here. But since you spoke of your perusal of the Win32 API, let me
add a tiny bit.  I gave myself a quick tour through the Win32 API using
Pavel Yosifovich's book ``Windows 10 System Programming''.  It's a two
volume work.  The thing that impressed me the most was the many ways to
do the IPC.  The purpose the work is clearly to show what is available
and it it probably does the job well.  (I ignored Windows for most of my
life and now I decided to take a look at it.  I don't feel it has much
of the elegance of UNIX.  It's what it is.)