some problems for an introductory python test

Dennis Lee Bieber wlfraed at ix.netcom.com
Wed Aug 11 18:51:14 EDT 2021


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...


	But I've harangued long enough.



-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
	wlfraed at ix.netcom.com    http://wlfraed.microdiversity.freeddns.org/



More information about the Python-list mailing list