On 11/08/2021 19:10, MRAB wrote:
> On 2021-08-11 18:10, Wolfram Hinderer via Python-list wrote:
>>
>>
>> Am 11.08.2021 um 05:22 schrieb Terry Reedy:
>>> Python is a little looser about whitespace than one might expect
>>> from reading 'normal' code when the result is unambiguous in that it
>>> cannot really mean anything other than what it does.  Two other
>>> examples:
>>>
>>> >>> if3: print('yes!')
>>> yes!
>>> >>> [0]  [0]
>>> 0
>>
>> Not sure what you mean here - is it a joke? The first looks like an if
>> statement, but isn't. The missing space *does* make a difference. (Try
>> "if0" instead.)
>>
> I see what you mean. It's a type annotation:
>
>     var: type
>
> where the "type" is a print statement!
>
>> The second is normal indexing, which allows white space. I wouldn't
>> consider that surprising, but maybe I should? (Honest question, I really
>> don't know.)
>>
I looked at the if3 example, and I was gobsmacked.  I momentarily
assumed that "if3" was parsed as "if 3", although that clearly makes no
sense ("if3" is a valid identifier).
Then I saw the "if0" example and I was even more gobsmacked, because it
showed that my assumption was wrong.
I've never used type annotations, I've never planned to used them. And
now that all is revealed, I'm afraid that my reaction is: I'm even more
inclined never to use them, because these examples are (to me) so confusing.
Rob Cliffe

This conversation has, of course, veered away from the original question so
I am starting afresh.

My memory of the original question is about how one sets up a test for
material covered in class or associated materials for what sounds like a
beginner class. I am not sure whether this would be the place for anyone to
ask such a question, especially as we have no real idea what was taught and
expected. Python is too rich a language and can be taught all kinds of ways
including many that largely ignore object-orientedness or other ways that
professionals use and appreciate.

There are lots of others who have taught such classes and plenty of books.
One can look to see what kinds of questions they use, and, where allowed,
borrow some, suitably adjusted. Any textbooks actually used for a course may
be an excellent place to start.

When I have taught, I like to do things incrementally. Tests are made up
based on what is talked about and stressed, perhaps with harder questions
asking for some innovation. So you may end up teaching how to do some things
without loops such as the example where you largely repeat some code in-line
five times. You might show how to do the same thing using dreaded
GOTO-statements in the OLD days but rarely now. Nowadays you might introduce
while loops or their repeat/do/for variants. In Python, you may well
introduce abbreviated variants such as list comprehensions.

So if testing the above, it is fair to specify in a question what NOT to
use. You can ask for no use of loops, or you can specify you want them to
use nothing but methods X or Y and so on. And since there are so many
modules out there, you might specify that no importing is allowed as that
defeats the purpose. I mean, if the purpose is to teach them how to
logically write a program that implements an algorithm as compared to just
calling a function already made.

As noted, some very decent projects are simply asking the student to create
something others have already done and one way to test how well they did it
is to compare the output of their work with a debugged solution.

Real programmers may at some point shift to using all kinds of constructs
that help them write lots of code faster and with fewer errors but beginner
students need something not very low level (like assembler?) but also not
very high level, I would think.

But debates about object oriented are fine for us philosophers but not
really of much use for the question I thought was asked.

On Thu, Aug 12, 2021 at 7:25 AM Rob Cliffe via Python-list
<python-list@python.org> wrote:
>
> On 11/08/2021 19:10, MRAB wrote:
> > On 2021-08-11 18:10, Wolfram Hinderer via Python-list wrote:
> >>
> >>
> >> Am 11.08.2021 um 05:22 schrieb Terry Reedy:
> >>> Python is a little looser about whitespace than one might expect
> >>> from reading 'normal' code when the result is unambiguous in that it
> >>> cannot really mean anything other than what it does. Two other
> >>> examples:
> >>>
> >>> >>> if3: print('yes!')
> >>> yes!
> >>> >>> [0] [0]
> >>> 0
> >>
> >> Not sure what you mean here - is it a joke? The first looks like an if
> >> statement, but isn't. The missing space *does* make a difference. (Try
> >> "if0" instead.)
> >>
> > I see what you mean. It's a type annotation:
> >
> > var: type
> >
> > where the "type" is a print statement!
> >
> >> The second is normal indexing, which allows white space. I wouldn't
> >> consider that surprising, but maybe I should? (Honest question, I really
> >> don't know.)
> >>
> I looked at the if3 example, and I was gobsmacked. I momentarily
> assumed that "if3" was parsed as "if 3", although that clearly makes no
> sense ("if3" is a valid identifier).
> Then I saw the "if0" example and I was even more gobsmacked, because it
> showed that my assumption was wrong.
> I've never used type annotations, I've never planned to used them. And
> now that all is revealed, I'm afraid that my reaction is: I'm even more
> inclined never to use them, because these examples are (to me) so confusing.

Don't judge a feature based on its weirdest example. Based on this
example, you should avoid ever using the len() built-in function:

>>> def show_count(n, word):
.... return "{{}} {{:{0}.{0}}}".format(len(word)-(n==1)).format(n, word)
....
>>> show_count(0, "things")
'0 things'
>>> show_count(1, "things")
'1 thing'
>>> show_count(5, "things")
'5 things'
>>> show_count(2, "widgets")
'2 widgets'
>>> show_count(1, "widgets")
'1 widget'

Any syntax can be abused. And the same thing would happen in any other
context. The only difference is that, in a declaration like "if3:
print()", the name if3 doesn't have to have been assigned already,
avoiding this problem:

>>> {
.... if3: print("Hello")
.... }
Traceback (most recent call last):
File "<stdin>", line 2, in <module>
NameError: name 'if3' is not defined

ChrisA

On Thu, 12 Aug 2021 06:15:28 +1000, Chris Angelico <rosuav@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@ix.netcom.com http://wlfraed.microdiversity.freeddns.org/

On Wed, 11 Aug 2021 09:27:38 -0300, Hope Rouselle <hrouselle@jevedi.com>
declaimed the following:

>
>I wouldn't. This is all Python-stuff. The course chooses a language
>like Python, but it is not trying to teach Python --- it is trying to
>teach computer programming, that is, strategies in high-precision.
>

Then I would posit you are teaching the wrong level... What you
describe is what would be found a "data structures" and/or "algorithms"
course -- which is a second year, if not third year course in my (ancient)
history. Such a course presumes one already knows at least on programming
language well enough that they can take description of an algorithm (or
even more detailed, pseudo-code) and translate it into the language they
know. This means the students /must/ know basic if/then/else, iterative
looping (which may, at common core, mean coding with a numerical index,
rather than pulling objects themselves out of the indexable structure --
since not all languages support object iteration), conditional looping
(including how to turn a "repeat/until" into the equivalent "while" (I was
tempted to say "while/wend" but that is specific to languages that need
block terminators). Slicing with a stride isn't really useful to most
algorithm development -- it's more of trick in normal Python.

So... The first thing I would drop is the RESTRICTION to only use what
you've covered in prior sessions... Let the students read the language
reference manual, peruse the library reference manual, and allow them to
use whatever "advanced" techniques they are able to understand on their
own. Granted you may have to restrict some features if discussing a
"common" data structure (queue, stack, maybe even advanced list
manipulation -- allow pop() and del, as those are how one would implement
queue and stack). Same for sorting -- if covering bubble, insertion, heap,
and (horrors) multipass sort/merge using working files, obviously the
Python sort()/sorted() are off-limits.

For my Algorithm/Data Structure course (circa 1978), the instructor
allowed us to use any language /he/ could understand (so no SNOBOL). At the
time I'd gone through intro/advanced FORTRAN-4, intro/advanced COBOL, Sigma
Assembly, UCSD Pascal (not on the campus main computer, just a pair of
LSI-11s), and BASIC. The assignment was a "Hashed Head, Multiply-Linked
List". I chose to do that assignment using BASIC! In nearly 45 years, I've
only seen ONE real-world implementation of the HHMLL -- The file system
used by the Commodore Amiga. (Hash the first component of the path/name,
that maps to one of 64 entries in the root directory block; each entry
points the start of a linked list, follow the list until you reach the
block with the component name; if it is a directory block, hash the next
component and repeat; if it is a file block, the "entries" point to data
blocks instead of lists)

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

On Thu, Aug 12, 2021 at 9:23 AM Dennis Lee Bieber <wlfraed@ix.netcom.com> wrote:
>
> On Thu, 12 Aug 2021 06:15:28 +1000, Chris Angelico <rosuav@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.

The same functionality was available in OS/2, but not heavily used.
You could 'address cmd commandname' to force something to be
interpreted as a shell command, but that was about it. However, I
built a MUD that used REXX as its scripting language, and the default
destination was sending text back to the person who sent the command;
and you could, of course, still 'address cmd' to run a shell command.

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

Win32 doesn't really have it. Unix sockets are kinda there but you
identify something by a path to the socket, not the name of the
application. But I think dbus is probably the closest to what you're
thinking of.

ChrisA

Chris Angelico <rosuav@gmail.com> writes:

[...]

>> > [1] And boy oh boy was that good fun. The OS/2 Presentation Manager
>> > had a wealth of power available. Good times, sad that's history now.
>>
>> I know OS/2 only by name. I never had the pleasure of using it. In
>> fact, I don't even know how it looks. I must be a little younger than
>> you are. But not too younger because I kinda remember its name. Was it
>> a system that might have thought of competing against Microsoft Windows?
>> :-) That's what my memory tells me about it.
>
> History lesson!
>
> Once upon a time, IBM and Microsoft looked at what Intel was
> producing, and went, hey, we need to design an operating system that
> can take advantage of the fancy features of this 80286 thing. So they
> collaborate on this plan to make a 16-bit protected mode OS.
> Unfortunately, things didn't work out too well, partly because this
> was when Microsoft was at its most monopolistic, and they ended up
> parting company. IBM continued to make OS/2, but Microsoft took their
> part of the code and made Windows NT out of it.

How is it possible that Microsoft would take part of the code of OS/2?
Did IBM just hand it to them?

> (Aside: Windows NT's 16-bit applications and OS/2's 16-bit
> applications were actually identical and compatible. Unfortunately,
> Win32 introduced a very new API, so as soon as everyone moved to
> 32-bit everything, the schism became problematic. But it was actually
> possible to package up a single .EXE file with a 16-bit MS-DOS loader,
> a Win32 loader, and an OS/2 32-bit loader, all happily coexisting.

Beautiful. :-) So if all libraries were around in each system, they had
perfect compatibility?

> In the latter half of the 1990s, Windows came in three broad flavours:
> the 16-bit Windows 3.x line, which ran purely on top of DOS; the
> 32-bit Windows 95 line, which was the "home" OS and had to be heavily
> compatible with Windows 3, but still doing more things; and the
> Windows NT line, which was aimed at businesses. OS/2 was a viable
> option for businesses, but almost nobody took it seriously as a home
> OS. And Microsoft was using its marketing machine to push Windows
> fairly hard, so most people went that way.
>
> OS/2 had all kinds of amazing features (for its time). The default
> file system, HPFS ("High Performance File System"... IBM was good at
> many things, but imaginative naming wasn't one of them), did a
> spectacular job of maintaining reliability and performance on the
> ever-growing hard disks of the time. Yes, it coped remarkably well,
> even on *gigantic* drives that could carry, ooh, an entire gigabyte of
> data! I'm not kidding! We even had a drive that had TWO gigabytes of
> space, and HPFS managed it beautifully! Plus, it had this fancy
> concept of "extended attributes"; on older systems (like MS-DOS's
> "FAT" family), a file might be Read-Only, Hidden, a System file, or
> needing to be Archived, and that was it - but on HPFS, you could
> attach arbitrary data like "File type: DeScribe Word Processor" or
> "Double click action: Run CASMake.cmd". This allowed the GUI to store
> all kinds of information *on the file itself* instead of needing
> hidden files (or, in Windows' case, the registry) to track that kind
> of thing.

Yeah, that's kinda nice. Isn't that a UNIX design? A file is a
sequence of bytes? Users decide what to put in them? So OS/2 was
taking advantage of that to integrate it well with the system. Windows
was doing the same, but integrating the system with files in odd ways
--- such as a registry record to inform the system which programs open
which files? (That does sound more messy.)

UNIX's execve() is able to read the first line of an executable and
invoke its interpreter. I guess OS/2 was doing precisely that in a
different way?

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

I cannot imagine. I always wondered what REXX was about --- I saw
programs sometimes written in some website whose name is something like
Rosetta Code. REXX looked so weird. (``Who would program in that?'')
But I see now there is a context to it.

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

Yeah, REXX looks horrible at first. But arbitrary-precision is
definitely very attractive. I never liked to deal with floating-point.

> I mentioned the Presentation Manager, because it was one of the best
> parts of running OS/2. The kernel was decent, but it was the graphical
> shell that was the real pleasure to work with. Probably the most
> notable feature, by today's standards, was that it had a single input
> queue. If you press a series of keys, they'd go into a global queue,
> and the application that has focus would get the first one. When that
> key has been handled, the application that has focus would get the
> next key from the queue. This means that, if the response to a
> keystroke is to change focus, then *even in a slow and lagged out
> system*, subsequent keys WOULD be sent to the new target window. That
> was AWESOME, and I really miss it. Except that I also don't. Because
> if a single application is having issues, now your entire keyboard and
> mouse is locked up... which kinda slightly sucks. Good luck resolving
> that problem. (We had some neat tools like WatchCat that could get
> around the single input queue via interrupt signals, and regain
> control. But it was still problematic.)

Wow, I kinda feel the same as you here. I think this justifies perhaps
using a hardware solution. (Crazy idea?! Lol.) Maybe machine and OS
could have a desktop-version that would have a hardware that could
effectively be like a second keyboard --- a button. So our keywords
would have a button that we press it, we could interrupt the OS to
handle such lock-up more gracefully. I suppose this is expensive,
complex and so on. But at the same time, it could be worth it.

> So, yeah. It was spectacular in its day.... but it kinda got left
> behind as the world moved on. These days, instead of running REXX code
> on OS/2 in a system that uses eight-bit text for most things, I use
> Python on Linux and full Unicode. But OS/2 was an important part of
> history, both my own personal journey, and the history of the world of
> PCs.

Very nice. Thanks a lot for sharing. I care a lot about such
histories. In fact, if you could point out from the top of your head
the best reference on the facts you mentioned here, I would love to
write it down for future reference. (You probably read books that
perhaps explained how the queue of windows messages worked et cetera.)

Thank you!

On Fri, Aug 13, 2021 at 2:15 AM Hope Rouselle <hrouselle@jevedi.com> wrote:
>
> Chris Angelico <rosuav@gmail.com> writes:
>
> > History lesson!
> >
> > Once upon a time, IBM and Microsoft looked at what Intel was
> > producing, and went, hey, we need to design an operating system that
> > can take advantage of the fancy features of this 80286 thing. So they
> > collaborate on this plan to make a 16-bit protected mode OS.
> > Unfortunately, things didn't work out too well, partly because this
> > was when Microsoft was at its most monopolistic, and they ended up
> > parting company. IBM continued to make OS/2, but Microsoft took their
> > part of the code and made Windows NT out of it.
>
> How is it possible that Microsoft would take part of the code of OS/2?
> Did IBM just hand it to them?

I presume both companies had all of the code. It was a matter of
licensing, though. There were a few components that were saddled with
awkward restrictions due to the dual ownership (for instance, HPFS386
was Microsoft-controlled, but vanilla HPFS was fine - kinda like the
difference between LZW and LZ77).

> > (Aside: Windows NT's 16-bit applications and OS/2's 16-bit
> > applications were actually identical and compatible. Unfortunately,
> > Win32 introduced a very new API, so as soon as everyone moved to
> > 32-bit everything, the schism became problematic. But it was actually
> > possible to package up a single .EXE file with a 16-bit MS-DOS loader,
> > a Win32 loader, and an OS/2 32-bit loader, all happily coexisting.
>
> Beautiful. :-) So if all libraries were around in each system, they had
> perfect compatibility?

The 16-bit loaders were fine, but the 32-bit loaders were different,
so this trick basically meant having three different copies of the
code wrapped up in a single executable.

> > Plus, it had this fancy
> > concept of "extended attributes"; on older systems (like MS-DOS's
> > "FAT" family), a file might be Read-Only, Hidden, a System file, or
> > needing to be Archived, and that was it - but on HPFS, you could
> > attach arbitrary data like "File type: DeScribe Word Processor" or
> > "Double click action: Run CASMake.cmd". This allowed the GUI to store
> > all kinds of information *on the file itself* instead of needing
> > hidden files (or, in Windows' case, the registry) to track that kind
> > of thing.
>
> Yeah, that's kinda nice. Isn't that a UNIX design? A file is a
> sequence of bytes? Users decide what to put in them? So OS/2 was
> taking advantage of that to integrate it well with the system. Windows
> was doing the same, but integrating the system with files in odd ways
> --- such as a registry record to inform the system which programs open
> which files? (That does sound more messy.)

Something like that, but with a lot more metadata. Modern OSes don't
seem to work that way any more.

> UNIX's execve() is able to read the first line of an executable and
> invoke its interpreter. I guess OS/2 was doing precisely that in a
> different way?

Kinda, but instead of having the choice of interpreter be inside the
file contents itself, the choice was in the file's metadata. Still
part of the file, but if you open and read the file, it isn't any
different.

> > 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??).
>
> I cannot imagine. I always wondered what REXX was about --- I saw
> programs sometimes written in some website whose name is something like
> Rosetta Code. REXX looked so weird. (``Who would program in that?'')
> But I see now there is a context to it.

Yeah. It was a strange choice by today's standards, but back then,
most of my GUI programs were written in REXX.

https://en.wikipedia.org/wiki/VX-REXX
http://www.edm2.com/0206/vrexx.html

(There were other tools too - VisPro REXX, VREXX, DrDialog, and
various others - but VX-REXX was where most of my dev work happened.)

> > Probably the most
> > notable feature, by today's standards, was that it had a single input
> > queue. ... This means that, if the response to a
> > keystroke is to change focus, then *even in a slow and lagged out
> > system*, subsequent keys WOULD be sent to the new target window. That
> > was AWESOME, and I really miss it. Except that I also don't. Because
> > if a single application is having issues, now your entire keyboard and
> > mouse is locked up... which kinda slightly sucks. Good luck resolving
> > that problem. (We had some neat tools like WatchCat that could get
> > around the single input queue via interrupt signals, and regain
> > control. But it was still problematic.)
>
> Wow, I kinda feel the same as you here. I think this justifies perhaps
> using a hardware solution. (Crazy idea?! Lol.)

uhhh........ Yes. Very crazy idea. Can't imagine why anyone would ever
think about doing that.

Certainly nobody in his right mind would have WatchCat listening on
the serial port's Ring Indicator interrupt, and then grab a paperclip
to bridge the DTR and RI pins on an otherwise-unoccupied serial port
on the back of the PC. (The DTR pin was kept high by the PC, and could
therefore be used as an open power pin to bring the RI high.)

If you're curious, it's pins 4 and 9 - diagonally up and in from the
short corner. http://www.usconverters.com/index.php?main_page=page&id=61&chapter=0

And of COURSE nobody would ever take an old serial mouse, take the
ball out of it, and turn it into a foot-controlled signal... although
that wasn't for WatchCat, that was for clipboard management between my
app and a Windows accounting package that we used. But that's a
separate story.

> Maybe machine and OS
> could have a desktop-version that would have a hardware that could
> effectively be like a second keyboard --- a button. So our keywords
> would have a button that we press it, we could interrupt the OS to
> handle such lock-up more gracefully. I suppose this is expensive,
> complex and so on. But at the same time, it could be worth it.

SysRq should theoretically be that. (That's Alt+PrtSc on a lot of
keyboards.) I'm not sure how it could best be handled though. It might
be that today's GUI systems (X11, Wayland, Cocoa, Win32, etc) just
wouldn't work with a single input queue. Would be curious to see if
any modern OS/GUI pair has a synchronous input queue like that.

> > So, yeah. It was spectacular in its day.... but it kinda got left
> > behind as the world moved on. These days, instead of running REXX code
> > on OS/2 in a system that uses eight-bit text for most things, I use
> > Python on Linux and full Unicode. But OS/2 was an important part of
> > history, both my own personal journey, and the history of the world of
> > PCs.
>
> Very nice. Thanks a lot for sharing. I care a lot about such
> histories. In fact, if you could point out from the top of your head
> the best reference on the facts you mentioned here, I would love to
> write it down for future reference. (You probably read books that
> perhaps explained how the queue of windows messages worked et cetera.)
>
> Thank you!

Thank you for asking questions about it! Aside from making me feel old
(which, let's face it, is kinda inevitable), it's great to dig through
some of the history and a few of the very different ways things have
been done.

References, unfortunately, are a bit hard to share, since they're
mostly dead-tree books, plus a small number of IPF documents (a format
kinda like man pages, but they get compiled) which have probably been
lost by now. Oh, plus a lot of "My dad told me", which is a bit hard
to point anyone else to :)

But if you want to delve into things today, I would recommend using
Wikipedia or whatever the almighty Google shows up, neither of which
was available back then, but both of which have vast information
available to you. Some useful topics:

* Single (or Synchronous) Input Queue
* CORBA (the system for cross-language subclassing of PM classes)
* The OS/2 Presentation Manager
* 80386 Protected Mode
* DBCS (early multilanguage support - appallingly inferior to Unicode,
but better than nothing)
* REXX, VX-REXX, VPREXX, VREXX
* DB2 (IBM's flagship database both then and now; spectacular even
back then, although slow at times)

Python *was* available on OS/2 back then, but not heavily supported.
It might be interesting to compare the early versions of Python to the
other tools available, but probably more useful to compare the 1990s
tools to modern Python on modern OSes and see how far the world has
come.

On 2021-08-12, Hope Rouselle <hrouselle@jevedi.com> wrote:

>> OS/2 had all kinds of amazing features (for its time). [...] Plus,
>> it had this fancy concept of "extended attributes"; on older
>> systems (like MS-DOS's "FAT" family), a file might be Read-Only,
>> Hidden, a System file, or needing to be Archived, and that was it -
>> but on HPFS, you could attach arbitrary data like "File type:
>> DeScribe Word Processor" or "Double click action: Run
>> CASMake.cmd". This allowed the GUI to store all kinds of
>> information *on the file itself* instead of needing hidden files
>> (or, in Windows' case, the registry) to track that kind of thing.
>
> Yeah, that's kinda nice. Isn't that a UNIX design? A file is a
> sequence of bytes? Users decide what to put in them?

I think what he's talking about is allowing the user to attach
arbitrary _metadata_ to the file -- metadata that exists separately
and independently from the normal data that's just a "sequence of
bytes". IOW, something similar to the "resource fork" that MacOS used
to have. https://en.wikipedia.org/wiki/Resource_fork

> So OS/2 was taking advantage of that to integrate it well with the
> system. Windows was doing the same, but integrating the system with
> files in odd ways --- such as a registry record to inform the system
> which programs open which files? (That does sound more messy.)

Windows never had filesystems that supported metadata like OS/2 and
MacOS did. The registry was an ugly hack that attempted (very poorly)
to make up for that lack of metadata.

> UNIX's execve() is able to read the first line of an executable and
> invoke its interpreter. I guess OS/2 was doing precisely that in a
> different way?

No, that's not at all the same thing. The #! line is part of the
normal file data. It's part of the 'sequence of bytes'. Metadata
maintained by Unix filesystems comprises a very limited and
pre-defined set of attributes present in the inode.

--
Grant

On Fri, Aug 13, 2021 at 5:03 AM Grant Edwards <grant.b.edwards@gmail.com> wrote:
>
> On 2021-08-12, Hope Rouselle <hrouselle@jevedi.com> wrote:
>
> >> OS/2 had all kinds of amazing features (for its time). [...] Plus,
> >> it had this fancy concept of "extended attributes"; on older
> >> systems (like MS-DOS's "FAT" family), a file might be Read-Only,
> >> Hidden, a System file, or needing to be Archived, and that was it -
> >> but on HPFS, you could attach arbitrary data like "File type:
> >> DeScribe Word Processor" or "Double click action: Run
> >> CASMake.cmd". This allowed the GUI to store all kinds of
> >> information *on the file itself* instead of needing hidden files
> >> (or, in Windows' case, the registry) to track that kind of thing.
> >
> > Yeah, that's kinda nice. Isn't that a UNIX design? A file is a
> > sequence of bytes? Users decide what to put in them?
>
> I think what he's talking about is allowing the user to attach
> arbitrary _metadata_ to the file -- metadata that exists separately
> and independently from the normal data that's just a "sequence of
> bytes". IOW, something similar to the "resource fork" that MacOS used
> to have. https://en.wikipedia.org/wiki/Resource_fork

Correct. OS/2's EAs are name/value pairs (with the value potentially
being a set of values - think how a Python dict maps keys to values,
but the values could be lists), with a few names having significance
to the system, like .TYPE and .LONGNAME (used on file systems that
didn't support longnames - yes, that's possible, since EAs could be
stored in a hidden file on a FAT disk).

> > So OS/2 was taking advantage of that to integrate it well with the
> > system. Windows was doing the same, but integrating the system with
> > files in odd ways --- such as a registry record to inform the system
> > which programs open which files? (That does sound more messy.)
>
> Windows never had filesystems that supported metadata like OS/2 and
> MacOS did. The registry was an ugly hack that attempted (very poorly)
> to make up for that lack of metadata.

Very poor indeed - it was very very common back then for Windows
programs to blat themselves all over the registry and then leave it
all behind when you nuke that thing. With EAs, it's all part of the
file itself and will be cleaned up by a simple directory removal.

ChrisA

On 2021-08-12 18:52, Grant Edwards wrote:
> On 2021-08-12, Hope Rouselle <hrouselle@jevedi.com> wrote:
>
>>> OS/2 had all kinds of amazing features (for its time). [...] Plus,
>>> it had this fancy concept of "extended attributes"; on older
>>> systems (like MS-DOS's "FAT" family), a file might be Read-Only,
>>> Hidden, a System file, or needing to be Archived, and that was it -
>>> but on HPFS, you could attach arbitrary data like "File type:
>>> DeScribe Word Processor" or "Double click action: Run
>>> CASMake.cmd". This allowed the GUI to store all kinds of
>>> information *on the file itself* instead of needing hidden files
>>> (or, in Windows' case, the registry) to track that kind of thing.
>>
>> Yeah, that's kinda nice. Isn't that a UNIX design? A file is a
>> sequence of bytes? Users decide what to put in them?
>
> I think what he's talking about is allowing the user to attach
> arbitrary _metadata_ to the file -- metadata that exists separately
> and independently from the normal data that's just a "sequence of
> bytes". IOW, something similar to the "resource fork" that MacOS used
> to have. https://en.wikipedia.org/wiki/Resource_fork
>
>> So OS/2 was taking advantage of that to integrate it well with the
>> system. Windows was doing the same, but integrating the system with
>> files in odd ways --- such as a registry record to inform the system
>> which programs open which files? (That does sound more messy.)
>
> Windows never had filesystems that supported metadata like OS/2 and
> MacOS did. The registry was an ugly hack that attempted (very poorly)
> to make up for that lack of metadata.
>
FYI, NTFS does support Alternate Data Streams.

>> UNIX's execve() is able to read the first line of an executable and
>> invoke its interpreter. I guess OS/2 was doing precisely that in a
>> different way?
>
> No, that's not at all the same thing. The #! line is part of the
> normal file data. It's part of the 'sequence of bytes'. Metadata
> maintained by Unix filesystems comprises a very limited and
> pre-defined set of attributes present in the inode.
>

On Thu, 12 Aug 2021 12:09:58 -0300, Hope Rouselle <hrouselle@jevedi.com>
declaimed the following:

>How is it possible that Microsoft would take part of the code of OS/2?
>Did IBM just hand it to them?
>

Because IBM subcontracted (IE: "paid") M$ to create an OS with XYZ
features for their latest PC (under supervision of IBM design team)..

https://en.wikipedia.org/wiki/OS/2

IBM owned the rights to OS/2, but it was written, for the most part, by
M$ in parallel with M$ own "Windows" 16-bit OS.

>
>Yeah, that's kinda nice. Isn't that a UNIX design? A file is a
>sequence of bytes? Users decide what to put in them? So OS/2 was
>taking advantage of that to integrate it well with the system. Windows
>was doing the same, but integrating the system with files in odd ways
>--- such as a registry record to inform the system which programs open
>which files? (That does sound more messy.)
>

Not really -- Have you looked at what a hash Linux graphical interfaces
require to associate file types with how to open said files?

On my Debian (VirtualBox) there is:

wulfraed@debian:~$ cat ~/.config/mimeapps.list
[Added Associations]
text/html=firefox-esr.desktop;
text/plain=gvim.desktop;
x-scheme-handler/http=exo-web-browser.desktop
x-scheme-handler/https=exo-web-browser.desktop
x-scheme-handler/mailto=exo-mail-reader.desktop
application/xml=gvim.desktop;
text/x-scheme=gvim.desktop;
application/vnd.kde.kxmlguirc=gvim.desktop;
text/x-python=gvim.desktop;
application/x-shellscript=gvim.desktop;

[Default Applications]
wulfraed@debian:~$

.... and all these

wulfraed@debian:~$ ls /usr/share/applications
atril.desktop panel-desktop-handler.desktop
claws-mail.desktop panel-preferences.desktop
...
debian-uxterm.desktop python3.7.desktop

...
org.thonny.Thonny.desktop xsane.desktop
org.xfce.Parole.desktop
wulfraed@debian:~$

wulfraed@debian:~$ cat /usr/share/applications/python3.7.desktop
[Desktop Entry]
Name=Python (v3.7)
Comment=Python Interpreter (v3.7)
Exec=/usr/bin/python3.7
Icon=/usr/share/pixmaps/python3.7.xpm
Terminal=true
Type=Application
Categories=Development;
StartupNotify=true
NoDisplay=true
wulfraed@debian:~$

wulfraed@debian:~$ cat /etc/mime.types
###############################################################################
# # MIME media types and the extensions that represent them.
# # The format of this file is a media type on the left and zero or more
# filename extensions on the right. Programs using this file will map
# files ending with those extensions to the associated type.
# # This file is part of the "mime-support" package. Please report a bug
using
# the "reportbug" command of the "reportbug" package if you would like new
# types or extensions to be added.
# # The reason that all types are managed by the mime-support package
instead
# allowing individual packages to install types in much the same way as
they
# add entries in to the mailcap file is so these types can be referenced
by
# other programs (such as a web server) even if the specific support
package
# for that type is not installed.
# # Users can add their own types if they wish by creating a ".mime.types"
# file in their home directory. Definitions included there will take
# precedence over those listed here.
# ###############################################################################

application/activemessage
application/andrew-inset ez
application/annodex anx
application/applefile
application/atom+xml atom
...
application/x-python-code pyc pyo
...
text/x-python py
...

wulfraed@debian:~$ cat /usr/share/applications/gvim.desktop
[Desktop Entry]
Name=gVim
GenericName=Text Editor
...
TryExec=gvim
Exec=gvim -f %F
Terminal=false
Type=Application
Keywords=Text;editor;
Icon=gvim
Categories=Utility;TextEditor;Development;
StartupNotify=true
MimeType=text/english;text/plain;text/x-makefile;text/x-c++hdr;text/x-c++src;text/x-chdr;text/x-csrc;text/x-java;text/x-moc;text/x-pascal;text/x-tcl;text/x-tex;application/x-shellscript;text/x-c;text/x-c++;text/x-python;text/x-python3
wulfraed@debian:~$

ALL of that is needed to link a Python source code file (.py) to GVIM
editor, when clicked on from the desktop.

>UNIX's execve() is able to read the first line of an executable and
>invoke its interpreter. I guess OS/2 was doing precisely that in a
>different way?
>
No... the UNIX/Linux shebang (and binary file equivalent magic-number)
is a deliberately written part of a file's "data" content (granted, the
linker writes it for executable binaries).

The description for OS/2 is close to the little used Windows STREAMS
feature.
https://docs.microsoft.com/en-us/windows/win32/fileio/file-streams
https://docs.microsoft.com/en-us/windows/win32/fileio/using-streams

>
>I cannot imagine. I always wondered what REXX was about --- I saw
>programs sometimes written in some website whose name is something like
>Rosetta Code. REXX looked so weird. (``Who would program in that?'')

REXX was created by an IBM researcher who wanted something better than
mainframe JCL (Job Control Language).
https://en.wikipedia.org/wiki/Rexx

>Yeah, REXX looks horrible at first. But arbitrary-precision is
>definitely very attractive. I never liked to deal with floating-point.
>
Unfortunately, the most commonly available is Regina REXX, and to my
knowledge it did not implement the arbitrary precision feature. Softrware
emulation of multprecision floating point is slooooooooooooooooooowwww!

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

On 2021-08-12, MRAB <python@mrabarnett.plus.com> wrote:
>
>> Windows never had filesystems that supported metadata like OS/2 and
>> MacOS did. The registry was an ugly hack that attempted (very poorly)
>> to make up for that lack of metadata.
>>
> FYI, NTFS does support Alternate Data Streams.

That is interesting -- and it was apparently intended to provide some
sort of compatibility with MacOS data fork and resource
fork. According to one article I found, nobody ever seems to have put
that NTFS feature to use for anything other than hiding malware.

--
Grant

On Fri, 13 Aug 2021 04:41:42 +1000, Chris Angelico <rosuav@gmail.com>
declaimed the following:

>Yeah. It was a strange choice by today's standards, but back then,
>most of my GUI programs were written in REXX.
>
>https://en.wikipedia.org/wiki/VX-REXX
>http://www.edm2.com/0206/vrexx.html
>
There was a library for the Amiga ARexx that supported basic GUI
implementation too...
>And of COURSE nobody would ever take an old serial mouse, take the
>ball out of it, and turn it into a foot-controlled signal... although

Of course not -- you'd want an old joyboard for that <G>
https://en.wikipedia.org/wiki/Joyboard

>
>SysRq should theoretically be that. (That's Alt+PrtSc on a lot of
>keyboards.) I'm not sure how it could best be handled though. It might

While so marked, Windows, at least, interprets <alt><prt sc> as "grab
image of current Window", whereas <prt sc> is "grab image of entire
display".

>be that today's GUI systems (X11, Wayland, Cocoa, Win32, etc) just
>wouldn't work with a single input queue. Would be curious to see if
>any modern OS/GUI pair has a synchronous input queue like that.
>

Not "modern" in this era, but I'm fairly certain the Amiga used a
single stream queue. But that stream was fed to every application running,
leaving it up to the application to determine if the event was something it
had to handle, or pass on further. It was also fairly easy to inject events
into the stream (which could help finding some of the easter eggs in the OS
-- rather difficult to hold down <lshift>, <lamiga>, <ramiga>, <rshift>,
<f10> AND, while holding them down, eject and insert a floppy disk.
[without the floppy, <f1> to <f9> put up a credits display for the people
who had worked on parts of the OS... The <f10> floppy mess then brought up
a display with approximately "we created Amiga, CBM messed it up"])

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

On 11Aug2021 09:11, Hope Rouselle <hrouselle@jevedi.com> wrote:
>Greg Ewing <greg.ewing@canterbury.ac.nz> writes:
>> That may not be doing what you think it's doing. Consider also
>>
>>>>> if0: print('yes!')
>> yes!
>
>So, yes, that's puzzling.
>
>>>> 0 == False
>True
>>>> if0: print("yes")
>yes
>>>> if(0): print("yes")
>
>>>>
>
>What's going on there?

1: "if0" does not mean "if 0"; "if0" is a valid identifier. Like "x0", "x1".

2: It took me a while to see, but this is a type annotiation.

This line:

if0: print('yes!')

says that the name "if0" should contain a value described by the return
value of the expression "print('yes!')". Like this:

label : str

says that we expect a string in the variable "label".

Remember that Python is strongly typed, but variables may reference
objects of any type. Type annotations are optional things reflecting
that in practice most variables are expected to reference specific
types. This lets is run static linters against programmes to catch
mistakes exposed by the type descriptions.

Also, type annotations have _no_ runtime effect. So if that expression
returns an invalid type description, nobody cares!

However, if you hand this code to a type aware linter such as mypy you
might get bitter complaints about nonsense. (Or, since print() returns
None, no complaint - it just means you expect this variable to hold the
value None. You'd get complaints about unused variables etc.)

Cheers,
Cameron Simpson <cs@cskk.id.au>

On 12Aug2021 12:09, Hope Rouselle <hrouselle@jevedi.com> wrote:
>Chris Angelico <rosuav@gmail.com> writes:
>> [...] Plus, it had this fancy
>> concept of "extended attributes"; on older systems (like MS-DOS's
>> "FAT" family), a file might be Read-Only, Hidden, a System file, or
>> needing to be Archived, and that was it - but on HPFS, you could
>> attach arbitrary data like "File type: DeScribe Word Processor" or
>> "Double click action: Run CASMake.cmd". This allowed the GUI to store
>> all kinds of information *on the file itself* instead of needing
>> hidden files (or, in Windows' case, the registry) to track that kind
>> of thing.
>
>Yeah, that's kinda nice. Isn't that a UNIX design? A file is a
>sequence of bytes? Users decide what to put in them?

Yes, but extended attributes are outside the file data. They're very
common on UNIX platforms these days. You can label arbitrary files with
a file type or whatever else. (There are platform specific limitations,
and even the OS API to deal with them is platform specific - Linux is
different to FreeBSD is different to MacOS.)

Also, Python has support for accessing these off-to-the-side data:

https://docs.python.org/3/library/os.html#linux-extended-attributes

Labelled "Linux" but also available for FreeBSD and IIRC OpenBSD. You do
of course need filesystem support - FAT32 for example would not work
with this - the filesystem needs a way to store these things. But ext4
and XFS on Linux, HFS+ on MacOS etc all support this.

I've even got a CPython branch where I'm implementing the MacOS backend
for these calls, a little stalled.

Cheers,
Cameron Simpson <cs@cskk.id.au>

On 13/08/21 11:42 am, Cameron Simpson wrote:
> 2: It took me a while to see, but this is a type annotiation.

Interestingly, it seems to be parsed as a form of assignment with
a missing RHS.

>>> from ast import parse, dump
>>> dump(parse("if0: print('yes!')"))
"Module(body=[AnnAssign(target=Name(id='if0', ctx=Store()),
annotation=Call(func=Name(id='print', ctx=Load()),
args=[Constant(value='yes!', kind=None)], keywords=[]), value=None,
simple=1)], type_ignores=[])"

"An annotated assignment without the assignment? Eeuurgh!"

--
Greg

On 13/08/21 5:52 am, Grant Edwards wrote:
> I think what he's talking about is allowing the user to attach
> arbitrary _metadata_ to the file ... IOW, something similar to the > "resource fork" that MacOS used to have.

The resource fork was used for more than just metadata, it was
often the entire contents of the file. Applications had all the
code in there, for example -- the data fork of an application
was usually empty.

--
Greg

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

> On Thu, 12 Aug 2021 06:15:28 +1000, Chris Angelico <rosuav@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.)

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

> On Wed, 11 Aug 2021 09:27:38 -0300, Hope Rouselle <hrouselle@jevedi.com>
> declaimed the following:
>>
>>I wouldn't. This is all Python-stuff. The course chooses a language
>>like Python, but it is not trying to teach Python --- it is trying to
>>teach computer programming, that is, strategies in high-precision.
>
> Then I would posit you are teaching the wrong level... What you
> describe is what would be found a "data structures" and/or "algorithms"
> course -- which is a second year, if not third year course in my (ancient)
> history. [...] Slicing with a stride isn't really useful to most
> algorithm development -- it's more of trick in normal Python.

I didn't express myself very well. And it's hard to make sense of the
course. I say it's interested in teaching computer programming because
it is not allowing the students to dive into the Python language. It's
very restrictive. Students will finish the course after learning to use
the loop contructs while and for. The course calls them ``structures
for repetition''. I think it's safe to say that the course is designed
by people concerned with education, but not well-versed in programming
languages, so not even the terminology seems quite correct.

So if they're not letting students embrace the whole of the language,
they must be concerned with other things? They sloppily emphasize
documentation and put in some concerns for procedure signatures. I have
some trouble defending it. I see the good intentions, though, and the
job is not easy.

But this course is definitely not teaching any data structures or any
algorithms. Zero. Students are using tuples, lists and dictionaries,
strings and numbers, but they're not studying any strategies whatsoever.
The exercises make students use a few basic facts of mathematics, but
there is pretty much no investigation into the strategies behind some of
these facts. It's not very intelligible.

I *kinda* like that it's restrictive because it allows us to show
students at least a few idioms: otherwise there's so much syntax to
digest that there is no time to show a few useful applications of them.
But then I read your next paragraph and it brings me to a very important
point, which I think it's at the back of your mind too. Let's see.

> So... The first thing I would drop is the RESTRICTION to only use what
> you've covered in prior sessions... Let the students read the language
> reference manual, peruse the library reference manual, and allow them to
> use whatever "advanced" techniques they are able to understand on their
> own.

Precisely. We kill the spirit of investigation by saying --- don't do
anything I don't allow you to. This is pretty dangerous. I have a much
better idea, I think.

You have to give people a tool and say --- use however you want. If we
don't want them to use things not introduced in previous lessons, we
should give them a precisely-limited tool. But that's not done.

The much better idea is to use such a limited language. There are such
languages, made precisely for teaching. It comes with very little
syntax and lesson after lesson it gets immensely powerful with very
little syntax.

> Granted you may have to restrict some features if [...]

To let students use the entire language feels a bit weird in the sense
that the group goes in so many different directions. It definitely put
teachers in a position they have to be --- I don't know the answer. It
is not my case. But I do think that holding a class with wildly
different backgrounds, each going about in their own weird ways is kinda
odd. It doesn't seem to bring people together --- on average.

The better-idea brings people together by leveling everyone out.
Unpopular languages give us this feature. Students hardly ever master
them. It's a game nobody played. The rules are very simple. The
implications are far-fetching. Sometimes even the programmer-expert in
class realizes he is less skilled than the total-novice that never
handled a compiler: his tricks don't work in the new game. (It's not
that we don't allow him to use them. They're not there. They don't
compile.) (We take Ghess players, Backgammon and Checkers players [the
students], we teach them a new game, say, Go, and suddenly everyone is
learning together. Assume Go is unpopular. It's very simple. Everyone
learns the rules quickly and we spend the semester looking into
strategies. Much better idea.)

> For my Algorithm/Data Structure course (circa 1978), the instructor
> allowed us to use any language /he/ could understand (so no SNOBOL). At the
> time I'd gone through intro/advanced FORTRAN-4, intro/advanced COBOL, Sigma
> Assembly, UCSD Pascal (not on the campus main computer, just a pair of
> LSI-11s), and BASIC. The assignment was a "Hashed Head, Multiply-Linked
> List". I chose to do that assignment using BASIC! In nearly 45 years, I've
> only seen ONE real-world implementation of the HHMLL -- The file system
> used by the Commodore Amiga. (Hash the first component of the path/name,
> that maps to one of 64 entries in the root directory block; each entry
> points the start of a linked list, follow the list until you reach the
> block with the component name; if it is a directory block, hash the next
> component and repeat; if it is a file block, the "entries" point to data
> blocks instead of lists)

Repeating my criticism with one more illustration. When ``there's
always more than one way to do it'', students can't even count on their
classmates to help each other --- because each one is doing a different
thing. This is good in science, but what I like the most in schooling
is working together and too much freedom like seems not very helpful in
this direction.

But both worlds is possible. Use a limited tool (which is not
computationally limited, quite the contrary) and tell them --- you can
do anything you want with this. The effect is that everyone, although
everyone is more or less original, the different solutions are never too
far apart, so all the exchange is quite possible.

Chris Angelico <rosuav@gmail.com> writes:

> On Thu, Aug 12, 2021 at 9:23 AM Dennis Lee Bieber <wlfraed@ix.netcom.com> wrote:

[...]

>> 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.
>
> The same functionality was available in OS/2, but not heavily used.
> You could 'address cmd commandname' to force something to be
> interpreted as a shell command, but that was about it. However, I
> built a MUD that used REXX as its scripting language, and the default
> destination was sending text back to the person who sent the command;
> and you could, of course, still 'address cmd' to run a shell command.
>
>> 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...
>
> Win32 doesn't really have it. Unix sockets are kinda there but you
> identify something by a path to the socket, not the name of the
> application. But I think dbus is probably the closest to what you're
> thinking of.

Win32 offers some APIs that sound like it could be what you guys are
talking about here that I'm not too clear what it is. There are some
shared memory you can reference by name, so it's as easy to use: both
applications invoke a procedure with a string-argument and exchange
information that way. (And Win32 does support named pipes as well.) I
mean I'm sure you know it all better than I do. (Perhaps I'm too
clueless here.) I could look up the Win32 APIs I'm thinking of if that
would clarify things.

Chris Angelico <rosuav@gmail.com> writes:

> On Fri, Aug 13, 2021 at 2:15 AM Hope Rouselle <hrouselle@jevedi.com> wrote:
>>
>> Chris Angelico <rosuav@gmail.com> writes:
>>
>> > History lesson!
>> >
>> > Once upon a time, IBM and Microsoft looked at what Intel was
>> > producing, and went, hey, we need to design an operating system that
>> > can take advantage of the fancy features of this 80286 thing. So they
>> > collaborate on this plan to make a 16-bit protected mode OS.
>> > Unfortunately, things didn't work out too well, partly because this
>> > was when Microsoft was at its most monopolistic, and they ended up
>> > parting company. IBM continued to make OS/2, but Microsoft took their
>> > part of the code and made Windows NT out of it.
>>
>> How is it possible that Microsoft would take part of the code of OS/2?
>> Did IBM just hand it to them?
>
> I presume both companies had all of the code. It was a matter of
> licensing, though. There were a few components that were saddled with
> awkward restrictions due to the dual ownership (for instance, HPFS386
> was Microsoft-controlled, but vanilla HPFS was fine - kinda like the
> difference between LZW and LZ77).
>
>> > (Aside: Windows NT's 16-bit applications and OS/2's 16-bit
>> > applications were actually identical and compatible. Unfortunately,
>> > Win32 introduced a very new API, so as soon as everyone moved to
>> > 32-bit everything, the schism became problematic. But it was actually
>> > possible to package up a single .EXE file with a 16-bit MS-DOS loader,
>> > a Win32 loader, and an OS/2 32-bit loader, all happily coexisting.
>>
>> Beautiful. :-) So if all libraries were around in each system, they had
>> perfect compatibility?
>
> The 16-bit loaders were fine, but the 32-bit loaders were different,
> so this trick basically meant having three different copies of the
> code wrapped up in a single executable.
>
>> > Plus, it had this fancy
>> > concept of "extended attributes"; on older systems (like MS-DOS's
>> > "FAT" family), a file might be Read-Only, Hidden, a System file, or
>> > needing to be Archived, and that was it - but on HPFS, you could
>> > attach arbitrary data like "File type: DeScribe Word Processor" or
>> > "Double click action: Run CASMake.cmd". This allowed the GUI to store
>> > all kinds of information *on the file itself* instead of needing
>> > hidden files (or, in Windows' case, the registry) to track that kind
>> > of thing.
>>
>> Yeah, that's kinda nice. Isn't that a UNIX design? A file is a
>> sequence of bytes? Users decide what to put in them? So OS/2 was
>> taking advantage of that to integrate it well with the system. Windows
>> was doing the same, but integrating the system with files in odd ways
>> --- such as a registry record to inform the system which programs open
>> which files? (That does sound more messy.)
>
> Something like that, but with a lot more metadata. Modern OSes don't
> seem to work that way any more.
>
>> UNIX's execve() is able to read the first line of an executable and
>> invoke its interpreter. I guess OS/2 was doing precisely that in a
>> different way?
>
> Kinda, but instead of having the choice of interpreter be inside the
> file contents itself, the choice was in the file's metadata. Still
> part of the file, but if you open and read the file, it isn't any
> different.

Speaking of which, NTFS supports something called file streams. That's
essentially a way to have files inside files. Streams are not shown by
tools such as file explorer. Applications could definitely use that as
metadata. (End of tangent.)

I think UNIX people would say and I'd agree --- we have that already.
But instead of hiding the stream, which is obscurantism, we let the user
see. (Just create two files in a directory, one with the extension
..metadata. And, oh, if you don't like that extension, you can change it
to whatever you like. Lol.) I like that.

>> > 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??).
>>
>> I cannot imagine. I always wondered what REXX was about --- I saw
>> programs sometimes written in some website whose name is something like
>> Rosetta Code. REXX looked so weird. (``Who would program in that?'')
>> But I see now there is a context to it.
>
> Yeah. It was a strange choice by today's standards, but back then,
> most of my GUI programs were written in REXX.
>
> https://en.wikipedia.org/wiki/VX-REXX
> http://www.edm2.com/0206/vrexx.html
>
> (There were other tools too - VisPro REXX, VREXX, DrDialog, and
> various others - but VX-REXX was where most of my dev work happened.)

I like that kind of simpler GUI interface. Cleaner. Fast! You know,
the so-called ``modern world'' is totally overrated.

>> > Probably the most
>> > notable feature, by today's standards, was that it had a single input
>> > queue. ... This means that, if the response to a
>> > keystroke is to change focus, then *even in a slow and lagged out
>> > system*, subsequent keys WOULD be sent to the new target window. That
>> > was AWESOME, and I really miss it. Except that I also don't. Because
>> > if a single application is having issues, now your entire keyboard and
>> > mouse is locked up... which kinda slightly sucks. Good luck resolving
>> > that problem. (We had some neat tools like WatchCat that could get
>> > around the single input queue via interrupt signals, and regain
>> > control. But it was still problematic.)
>>
>> Wow, I kinda feel the same as you here. I think this justifies perhaps
>> using a hardware solution. (Crazy idea?! Lol.)
>
> uhhh........ Yes. Very crazy idea. Can't imagine why anyone would ever
> think about doing that.

Lol. Really? I mean a certain panic button. You know the GNU Emacs.
It has this queue with the implications you mentioned --- as much as it
can. (It must of course get the messages from the system, otherwise it
can't do anything about it.) And it has the panic button C-g. The
keyboard has one the highest precedences in hardware interrupts, doesn't
it not? A certain very important system could have a panic button that
invokes a certain debugger, say, for a crisis-moment.

But then this could be a lousy engineering strategy. I am not an expert
at all in any of this. But I'm surprised with your quick dismissal. :-)

> Certainly nobody in his right mind would have WatchCat listening on
> the serial port's Ring Indicator interrupt, and then grab a paperclip
> to bridge the DTR and RI pins on an otherwise-unoccupied serial port
> on the back of the PC. (The DTR pin was kept high by the PC, and could
> therefore be used as an open power pin to bring the RI high.)

Why not? Misuse of hardware? Too precious of a resource?

> If you're curious, it's pins 4 and 9 - diagonally up and in from the
> short
> corner. http://www.usconverters.com/index.php?main_page=page&id=61&chapter=0

You know your pins! That's impressive. I thought the OS itself could
use something like that. The fact that they never do... Says something,
doesn't it? But it's not too obvious to me.

> And of COURSE nobody would ever take an old serial mouse, take the
> ball out of it, and turn it into a foot-controlled signal... although
> that wasn't for WatchCat, that was for clipboard management between my
> app and a Windows accounting package that we used. But that's a
> separate story.

Lol. I feel you're saying you would. :-)

>> Maybe machine and OS
>> could have a desktop-version that would have a hardware that could
>> effectively be like a second keyboard --- a button. So our keywords
>> would have a button that we press it, we could interrupt the OS to
>> handle such lock-up more gracefully. I suppose this is expensive,
>> complex and so on. But at the same time, it could be worth it.
>
> SysRq should theoretically be that. (That's Alt+PrtSc on a lot of
> keyboards.) I'm not sure how it could best be handled though. It might
> be that today's GUI systems (X11, Wayland, Cocoa, Win32, etc) just
> wouldn't work with a single input queue. Would be curious to see if
> any modern OS/GUI pair has a synchronous input queue like that.

Grant Edwards <grant.b.edwards@gmail.com> writes:

> On 2021-08-12, Hope Rouselle <hrouselle@jevedi.com> wrote:
>
>>> OS/2 had all kinds of amazing features (for its time). [...] Plus,
>>> it had this fancy concept of "extended attributes"; on older
>>> systems (like MS-DOS's "FAT" family), a file might be Read-Only,
>>> Hidden, a System file, or needing to be Archived, and that was it -
>>> but on HPFS, you could attach arbitrary data like "File type:
>>> DeScribe Word Processor" or "Double click action: Run
>>> CASMake.cmd". This allowed the GUI to store all kinds of
>>> information *on the file itself* instead of needing hidden files
>>> (or, in Windows' case, the registry) to track that kind of thing.
>>
>> Yeah, that's kinda nice. Isn't that a UNIX design? A file is a
>> sequence of bytes? Users decide what to put in them?
>
> I think what he's talking about is allowing the user to attach
> arbitrary _metadata_ to the file -- metadata that exists separately
> and independently from the normal data that's just a "sequence of
> bytes". IOW, something similar to the "resource fork" that MacOS used
> to have. https://en.wikipedia.org/wiki/Resource_fork

Got ya.

>> So OS/2 was taking advantage of that to integrate it well with the
>> system. Windows was doing the same, but integrating the system with
>> files in odd ways --- such as a registry record to inform the system
>> which programs open which files? (That does sound more messy.)
>
> Windows never had filesystems that supported metadata like OS/2 and
> MacOS did. The registry was an ugly hack that attempted (very poorly)
> to make up for that lack of metadata.

Take a look at NTFS streams. Maybe you would consider that as a way to
store metadata in Windows. Pavel Yosifovich talks about them briefly in
chapter 11, page 555, part 1. Windows 10 System Programming. Here's
the first paragraph:

--8<---------------cut here---------------start------------->8---
The NTFS filesystem supports /file streams/, which are essentially files
within a file. Normally, we use the default data stream, but others can
be created and used. These are essentially hidden from normal view and
don’t show up in standard tools such as Windows Explorer.
--8<---------------cut here---------------end--------------->8---

Pavel Yosifovich wrote a tool to let us see these streams:

https://github.com/zodiacon/NtfsStreams

>> UNIX's execve() is able to read the first line of an executable and
>> invoke its interpreter. I guess OS/2 was doing precisely that in a
>> different way?
>
> No, that's not at all the same thing. The #! line is part of the
> normal file data. It's part of the 'sequence of bytes'. Metadata
> maintained by Unix filesystems comprises a very limited and
> pre-defined set of attributes present in the inode.

Well said.

Hope Rouselle <hrouselle@jevedi.com> writes:

[...]

>> Granted you may have to restrict some features if [...]
>
> To let students use the entire language feels a bit weird in the sense
> that the group goes in so many different directions. It definitely put
> teachers in a position they have to be --- I don't know the answer.
^^^^^^^^^^
Sorry. I meant ``they [hate] to be [in] --- I don't know the answer.''

And, alas, I also find many more typos, grammar and cosmetic
incoherences below, which I fix with brackets. (Not that they were
needed. Only this bit above seemed to lose the meaning of the author,
Your Truly.)

> It is not my case. But I do think that holding a class with wildly
> different backgrounds, each going about in their own weird ways[,] is
> kinda odd. It doesn't seem to bring people together --- on average.
>
> The better-idea brings people together by leveling everyone out.
> Unpopular languages give us this feature. Students hardly ever master
> them. It's a game nobody played. The rules are very simple. The
> implications are far-fetching. Sometimes even the programmer-expert in
> class realizes he is less skilled than the total-novice that never
> handled a compiler: his tricks don't work in the new game. (It's not
> that we don't allow him to use them. They're not there. They don't
> compile.) (We take [Chess] players, Backgammon and Checkers players [the
> students], we teach them a new game, say, Go, and suddenly everyone is
> learning together. Assume Go is unpopular. It's very simple. Everyone
> learns the rules quickly and we spend the semester looking into
> strategies. Much better idea.)
>
>> For my Algorithm/Data Structure course (circa 1978), the instructor
>> allowed us to use any language /he/ could understand (so no SNOBOL). At the
>> time I'd gone through intro/advanced FORTRAN-4, intro/advanced COBOL, Sigma
>> Assembly, UCSD Pascal (not on the campus main computer, just a pair of
>> LSI-11s), and BASIC. The assignment was a "Hashed Head, Multiply-Linked
>> List". I chose to do that assignment using BASIC! In nearly 45 years, I've
>> only seen ONE real-world implementation of the HHMLL -- The file system
>> used by the Commodore Amiga. (Hash the first component of the path/name,
>> that maps to one of 64 entries in the root directory block; each entry
>> points the start of a linked list, follow the list until you reach the
>> block with the component name; if it is a directory block, hash the next
>> component and repeat; if it is a file block, the "entries" point to data
>> blocks instead of lists)
>
> Repeating my criticism with one more illustration. When ``there's
> always more than one way to do it'', students can't even count on their
> classmates to help each other --- because each one is doing a different
> thing. This is good in science, but what I like the most in schooling
> is working together and too much freedom like seems not very helpful in
> this direction.
>
> But both worlds [are] possible. Use a limited tool (which is not
> computationally limited, quite the contrary) and tell them --- you can
> do anything you want with this. [...] [Although] everyone is more or
> less original, the different solutions are never too far apart, so all
> the exchange is quite possible.

On Tue, Aug 17, 2021 at 3:51 AM Hope Rouselle <hrouselle@jevedi.com> wrote:
>
> Chris Angelico <rosuav@gmail.com> writes:
> >> Wow, I kinda feel the same as you here. I think this justifies perhaps
> >> using a hardware solution. (Crazy idea?! Lol.)
> >
> > uhhh........ Yes. Very crazy idea. Can't imagine why anyone would ever
> > think about doing that.
>
> Lol. Really? I mean a certain panic button. You know the GNU Emacs.
> It has this queue with the implications you mentioned --- as much as it
> can. (It must of course get the messages from the system, otherwise it
> can't do anything about it.) And it has the panic button C-g. The
> keyboard has one the highest precedences in hardware interrupts, doesn't
> it not? A certain very important system could have a panic button that
> invokes a certain debugger, say, for a crisis-moment.
>
> But then this could be a lousy engineering strategy. I am not an expert
> at all in any of this. But I'm surprised with your quick dismissal. :-)
>
> > Certainly nobody in his right mind would have WatchCat listening on
> > the serial port's Ring Indicator interrupt, and then grab a paperclip
> > to bridge the DTR and RI pins on an otherwise-unoccupied serial port
> > on the back of the PC. (The DTR pin was kept high by the PC, and could
> > therefore be used as an open power pin to bring the RI high.)
>
> Why not? Misuse of hardware? Too precious of a resource?
>
> > If you're curious, it's pins 4 and 9 - diagonally up and in from the
> > short
> > corner. http://www.usconverters.com/index.php?main_page=page&id=61&chapter=0
>
> You know your pins! That's impressive. I thought the OS itself could
> use something like that. The fact that they never do... Says something,
> doesn't it? But it's not too obvious to me.
>
> > And of COURSE nobody would ever take an old serial mouse, take the
> > ball out of it, and turn it into a foot-controlled signal... although
> > that wasn't for WatchCat, that was for clipboard management between my
> > app and a Windows accounting package that we used. But that's a
> > separate story.
>
> Lol. I feel you're saying you would. :-)

This was all a figure of speech, and the denials were all tongue in
cheek. Not only am I saying we would, but we *did*. All of the above.
The Ring Indicator trick was one of the best, since we had very little
other use for serial ports, and it didn't significantly impact the
system during good times, but was always reliable when things went
wrong.

(And when I posted it, I could visualize the port and knew which pins
to bridge, but had to go look up a pinout to be able to say their pin
numbers and descriptions.)

> I heard of Python for the first time in the 90s. I worked at an ISP.
> Only one guy was really programming there, Allaire ColdFusion. But, odd
> enough, we used to say we would ``write a script in Python'' when we
> meant to say we were going out for a smoke. I think that was precisely
> because nobody knew that ``Python'' really was. I never expected it to
> be a great language. I imagined it was something like Tcl. (Lol, no
> offense at all towards Tcl.)

Haha, that's a weird idiom!

Funny you should mention Tcl.

https://docs.python.org/3/library/tkinter.html

ChrisA