Computer Old Farts Forum
 help / color / mirror / Atom feed
* [COFF] fmt Strings.  (Was: A few comments on porting the Bourne shell)
       [not found]           ` <20221231044049.GI5825@mcvoy.com>
@ 2022-12-31 11:57             ` Ralph Corderoy
  0 siblings, 0 replies; 4+ messages in thread
From: Ralph Corderoy @ 2022-12-31 11:57 UTC (permalink / raw)
  To: coff

Hi Larry,

> I hate Python because there is no printf in the base language.

There's print() with the format-string part being promoted into the
language as the ‘%’ operator when the left operand is a string.
It returns a string.

    >>> '%10d' % (6*7)
    '        42'
    >>> '%s %s!\n' % ('hello', 'world')
    'hello world!\n'
    >>> '%10d' % 6*7
    '         6         6         6         6         6         6         6'
    >>> print('foo')
    foo
    >>> print('%.3s' % 'barxyzzy')
    bar
    >>> 

So similar to AWK or Perl's sprintf() and Go's fmt.Sprintf() in that it
returns a dynamically-allocated string.

-- 
Cheers, Ralph.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* [COFF] Re: [TUHS] Re: A few comments on porting the Bourne shell
       [not found]                         ` <CAEoi9W7A==NC+W+H+kZbUZ6AK2O-cUjwjUz_Gx_HY_BKfeeBqA@mail.gmail.com>
@ 2023-01-02 18:48                           ` Dan Cross
  2023-01-02 19:53                             ` [COFF] Re: [TUHS] " Adam Thornton
  0 siblings, 1 reply; 4+ messages in thread
From: Dan Cross @ 2023-01-02 18:48 UTC (permalink / raw)
  To: Clem Cole; +Cc: COFF

[Apologies for resending; I messed up and used the old Minnie address
for COFF in the Cc]

On Mon, Jan 2, 2023 at 1:36 PM Dan Cross <crossd@gmail.com> wrote:
>
> On Mon, Jan 2, 2023 at 1:13 PM Clem Cole <clemc@ccc.com> wrote:
> > Maybe this should go to COFF but Adam I fear you are falling into a tap that is easy to fall into - old == unused
> >
> > One of my favorite stores in the computer restoration community is from 5-10 years ago and the LCM+L in Seatle was restoring their CDC-6000 that they got From Purdue.   Core memory is difficult to get, so they made a card and physical module that could plug into their system that is both electrically and mechanically equivalent using modern semiconductors.   A few weeks later they announced that they had the system running and had built this module. They got approached by the USAF asking if they could get a copy of the design.  Seems, there was still a least one CDC-6600 running a particular critical application somewhere.
> >
> > This is similar to the PDP-11s and Vaxen that are supposed to be still in the hydroelectric grid [a few years ago the was an ad for an RSX and VMS programmer to go to Canada running in the Boston newspapers - I know someone that did a small amount of consulting on that one].
>
> One of my favorite stories along these lines is the train signalling
> system in Melbourne, running on a "PDP-11". I quote PDP-11 because
> that is now virtualized:
> https://www.equicon.de/images/Virtualisierung/LegacyTrainControlSystemStabilization.pdf
>
> Indeed older systems show up in surprising places. I was once on the
> bridge of a US Naval vessel in the late '00s and saw a SPARCstaton 20
> running Solaris (with the CDE login screen). I don't recall what it
> was doing, but it was a tad surprising.
>
> I do worry about legacy systems in critical situations, but then, I've
> been in a firefight when the damned tactical computer with the satcomm
> link rebooted and we didn't have VHF comms with the battlespace owner.
> That was not particularly fun.
>
>         - Dan C.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* [COFF] Re: [TUHS] A few comments on porting the Bourne shell
  2023-01-02 18:48                           ` [COFF] Re: [TUHS] Re: A few comments on porting the Bourne shell Dan Cross
@ 2023-01-02 19:53                             ` Adam Thornton
  0 siblings, 0 replies; 4+ messages in thread
From: Adam Thornton @ 2023-01-02 19:53 UTC (permalink / raw)
  To: COFF



> On Jan 2, 2023, at 11:48 AM, Dan Cross <crossd@gmail.com> wrote:
> 
> [Apologies for resending; I messed up and used the old Minnie address
> for COFF in the Cc]
> 
> On Mon, Jan 2, 2023 at 1:36 PM Dan Cross <crossd@gmail.com> wrote:
>> 
>> On Mon, Jan 2, 2023 at 1:13 PM Clem Cole <clemc@ccc.com> wrote:
>>> Maybe this should go to COFF but Adam I fear you are falling into a tap that is easy to fall into - old == unused
>>> 
>>> One of my favorite stores in the computer restoration community is from 5-10 years ago and the LCM+L in Seatle was restoring their CDC-6000 that they got From Purdue.   Core memory is difficult to get, so they made a card and physical module that could plug into their system that is both electrically and mechanically equivalent using modern semiconductors.   A few weeks later they announced that they had the system running and had built this module. They got approached by the USAF asking if they could get a copy of the design.  Seems, there was still a least one CDC-6600 running a particular critical application somewhere.
>>> 
>>> This is similar to the PDP-11s and Vaxen that are supposed to be still in the hydroelectric grid [a few years ago the was an ad for an RSX and VMS programmer to go to Canada running in the Boston newspapers - I know someone that did a small amount of consulting on that one].
>> 
>> One of my favorite stories along these lines is the train signalling
>> system in Melbourne, running on a "PDP-11". I quote PDP-11 because
>> that is now virtualized:
>> https://www.equicon.de/images/Virtualisierung/LegacyTrainControlSystemStabilization.pdf
>> 
>> Indeed older systems show up in surprising places. I was once on the
>> bridge of a US Naval vessel in the late '00s and saw a SPARCstaton 20
>> running Solaris (with the CDE login screen). I don't recall what it
>> was doing, but it was a tad surprising.
>> 
>> I do worry about legacy systems in critical situations, but then, I've
>> been in a firefight when the damned tactical computer with the satcomm
>> link rebooted and we didn't have VHF comms with the battlespace owner.
>> That was not particularly fun.

And there is certainly no simple relationship between age and likeliness-to-still-work.

A couple years ago now, I helped inventory the business space and warehouse of a man who had had a stroke and would thus not be able to continue running his direct mail business.  But in 2017, he was running a direct-mail advertising business off an honest-to-god PDP-11/70 and a bunch of ADM-3A terminals.  He also had several Vaxen out in his warehouse, a dozen or so TI Silent 700s, and even an 029 card punch. I think his basic philosophy was to buy these machines as they were surplussed and use them for parts, and apparently it worked fine for him until his health failed.  I've got what looks to be a pretty pristine VAX-11/730 from the collection, which someday I will get a beefy enough 110V-220V transformer to run (sure, I have 220 to my dryer, but I'm not going to pay to have it run to my office), and an RM-80, which is now a nightstand.  I would be very surprised if the VAX wouldn't work with no more than minor capacitor work.  I also snagged a Sun 9-track tape drive which came from NOAO and is back home in the correct building, if not the correct office.  It's a coffee table now, because I have no half-inch tapes I want to read.  If someone does, well, it still powers up and spins the reels.  Someone else can sacrifice the goats to get whichever flavor of SCSI it speaks talking to something modern.

My annual Elvis' Birthday Party is coming up, which is really a boardgaming and retrogaming party, so I'm going through my stuff trying to figure out what I want to have in Display Mode as guests arrive.  A lot of my mid-90s-through-mid-2000s stuff doesn't work anymore, like the original Xbox, and the G5 powermac that suffered from the capacitor plague.  But my 80s consoles and 8-bit computers are mostly basically working fine.  The blue electron gun on my Bondi Blue iMac has failed, which is sad, the better-built 90s workstations are OK, although the CMOS battery on the SparcStation 10 is long-dead, and the power supplies on pretty much all the Microvax 3000-series need rework (but the VAK4kVLC is running fine, so there is a real VAX to play with).  But in general: both machines and magnetic storage prior to 1995 have a good chance of still working (for very occasional duty, anyway), and then there's a decade or so where it's probably dead, and then newer than that is OK again.

These things are all extremely fun to play with, but honestly I only ever dust them off a couple times a year.  For more-routine retrocomputing jobs (like porting Frotz to TOPS-20), well, emulation doesn't cost me nearly so much electricity, I don't have to deal with fan noise, and I'm not worried about some capacitor somewhere giving up its magic smoke, or just old solder joints finally cracking apart.  Because of the magic of Moore's Law, I can run several 36-bit systems at once on a (back in the good old days, when you could actually get them) $50 Raspberry Pi.

Note that MetroTrainsMelbourne ended up with PDP-11-on-a-board plugged into Windows XP systems, and some sort of ISA-bus-to-Unibus converter.  I wonder what they're doing now?   It's always the peripheral support that keeps you running on the original hardware, and from the description and the age of the system I bet the VDU serial links were pretty tightly coupled to the rest of the timetable generator, and I bet that's the hard part to reengineer with equivalent functionality.  Me, I would have spent the second 5 years of the extension project paying someone to implement an equivalent (but not necessarily bug-compatible) scheduler and some sort of message-bus-over-TCP/IP-to-small-form-factor-PCs-hidden-behind-HDMI-TVs for the display units, in parallel with the existing system, with particular attention to decoupling production of the schedule data from delivering it to the remote users, so when that 10 years was up, I'd have had something I was confident in switching to that would be cheaply maintainable for a while, and where I could upgrade the display and compute tech individually.  But I also suspect management didn't agree to spend their money that way.

Adam

^ permalink raw reply	[flat|nested] 4+ messages in thread

* [COFF] Re: [TUHS] Re: Command Line Editing in the Terminal Driver (Was: A few comments on porting the Bourne shell)
       [not found]         ` <CAK0pxsH6bWTLVApE_vDhATmMgaF+nwc5D3pSz4srtwGS-8Ux_A@mail.gmail.com>
@ 2023-01-03 23:02           ` Adam Thornton
  0 siblings, 0 replies; 4+ messages in thread
From: Adam Thornton @ 2023-01-03 23:02 UTC (permalink / raw)
  To: Computer Old Farts Followers

[-- Attachment #1: Type: text/plain, Size: 5218 bytes --]

(moving to COFF)

On Tue, Jan 3, 2023 at 9:55 AM Marshall Conover <marzhall.o@gmail.com>
wrote:

> Along these lines but not quite, Jupyter Notebooks have stood out to me as
> another approach to this concept, with behavior I'd like to see implemented
> in a shell.
>
>
Well, you know, if you're OK with bash:
https://github.com/takluyver/bash_kernel

Or zsh: https://pypi.org/project/zsh-jupyter-kernel/

One of the big things I do is work on the Notebook Aspect of the Rubin
Science Platform.  Each JupyterLab notebook session is tied to a "kernel"
which is a specific language-and-extension environment.  At the Rubin
Observatory, we support a Python 3.10 environment with our processing
pipeline included.  Although JupyterLab itself is capable of doing other
languages (notably Julia and R, which are the other two from which the name
"Jupyter" came), many others have been adapted to the notebook environment
(including at least the two shells above).  And while researchers are
welcome to write their own code and work with raw images, we work under the
presumption that almost everyone is going to use the software tools the
Rubin Observatory provides to work with the data it collects, because
writing your own data processing pipeline from scratch is a pretty
monumental project.

Most astronomers are perfectly happy with what we provide, which is Python
plus our processing pipelines, which are all Python from the
scientist-facing perspective (much of the pipeline code is implemented in
C++ for speed, but it then gets Python bindings, so unless you're actually
working very deep down in the image processing code, it's Python as far as
you're concerned).  However, a certain class of astronomers still loves
their FORTRAN.  This class, unfortunately, tends to be the older ones,
which means the ones who have societal stature, tenure, can relatively
easily get big grants, and wield a lot of power within their institutions.

I know that it is *possible* to run gfortran as a Jupyter kernel.  I've
seen it done.  I was impressed.

Fortunately, no one with the power to make it stick has demanded we provide
a kernel like that.  The initial provision of the service wouldn't be the
problem.  It's that the support would be a nightmare.  No one on my team is
great at FORTRAN; I'm probably the closest to fluent, and I'm not very, and
I really don't enjoy working in FORTRAN, and because FORTRAN really doesn't
lend itself easily to the kind of Python REPL exploration that notebooks
are all about, and because someone who loves FORTRAN and hates Python
probably has a very different concept of what good software engineering
practices look like than I do, trying to support someone working in a
notebook environment in a FORTRAN kernel would very likely be exquisitely
painful.  And fortunately, since there are not FORTRAN bindings to the C++
classes providing the core algorithms, much less FORTRAN bindings to the
Python implementations (because all the things that don't particularly need
to be fast are just written in Python in the first place), a gfortran
kernel wouldn't be nearly as useful as our Python-plus-our-tools.

Now, sure, if we had paying customers who were willing to throw enough
money at us to make it worth the pain and both bring a FORTRAN
implementation to feature-parity with the reference environment and make a
gfortran kernel available, then we would do it.  But I get paid a salary
that is not directly tied to my support burden, and I get to spend a lot
more of my time working on fun things and providing features for
astronomers who are not mired in 1978 if I can avoid spending my time
supporting huge time sinks that aren't in widespread use.  We are scoped to
provide Python.  We are not scoped to provide FORTRAN.  We are not making
money off of sales: we're employed to provide stable infrastructure
services so the scientists using our platform and observatory can get their
research done.  And thus far we've been successful in saying "hey, we've
got finite resources, we're not swimming in spare cycles, no, we can't
support [ x for x in
things-someone-wants-but-are-not-in-the-documented-scope ]".  (To be fair,
this has more often been things like additional visualization libraries
than whole new languages, but the principle is the same.)  We have a
process for proposing items for inclusion, and it's not at all rare that we
add them, but it's generally a considered decision about how generally
useful the proposed item will be for the project as a whole and how much
time it's likely to consume to support.

So this gave me a little satori about why I think POSIX.2 is a perfectly
reasonable spec to support and why I'm not wild about making all my shell
scripts instead compatible with the subset of v7 sh that works (almost)
everywhere.  It's not all that much more work up front, but odds are that a
customer that wants to run new software, but who can't guarantee a POSIX
/bin/sh, will be a much more costly customer to support than one who can,
just as someone who wants a notebook environment but insists on FORTRAN in
it is very likely going to be much harder to support than someone who's
happy with the Python environment we already supply.

Adam

[-- Attachment #2: Type: text/html, Size: 6154 bytes --]

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2023-01-03 23:04 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <52FB6638-AEFF-4A4F-8C2E-32089D577BA0@planet.nl>
     [not found] ` <464819f0-d2f6-2a60-6481-a194f4428b4d@case.edu>
     [not found]   ` <20221230200246.GW5825@mcvoy.com>
     [not found]     ` <88f83b4c-b3f9-ed87-b2fa-560fb369742a@makerlisp.com>
     [not found]       ` <20221231035931.GG5825@mcvoy.com>
     [not found]         ` <BD716565-29A2-4959-AA20-339E91DBF789@iitbombay.org>
     [not found]           ` <20221231044049.GI5825@mcvoy.com>
2022-12-31 11:57             ` [COFF] fmt Strings. (Was: A few comments on porting the Bourne shell) Ralph Corderoy
     [not found]         ` <alpine.BSF.2.21.9999.2212311516330.69068@aneurin.horsfall.org>
     [not found]           ` <528f0c53-ccc2-88a1-5a7b-120362c648dd@mhorton.net>
     [not found]             ` <CAC20D2NZbBa9PK_F50iWVn+t7m8=_mcw4mR2mKcTgDbdqxJi=w@mail.gmail.com>
     [not found]               ` <20230102165120.GK25547@mcvoy.com>
     [not found]                 ` <E977D385-604F-49A9-83FD-8C5270623066@gmail.com>
     [not found]                   ` <20230102174304.GM25547@mcvoy.com>
     [not found]                     ` <E4339ED1-73F4-4BBB-92EF-B9D5A92C5096@gmail.com>
     [not found]                       ` <CAC20D2Pf-rLL8NqoJ7RcXHjrq4crQKC=K25218fuM0yd0rQNDA@mail.gmail.com>
     [not found]                         ` <CAEoi9W7A==NC+W+H+kZbUZ6AK2O-cUjwjUz_Gx_HY_BKfeeBqA@mail.gmail.com>
2023-01-02 18:48                           ` [COFF] Re: [TUHS] Re: A few comments on porting the Bourne shell Dan Cross
2023-01-02 19:53                             ` [COFF] Re: [TUHS] " Adam Thornton
     [not found]     ` <8ca17d52-a25a-dbbf-e1f0-d743b8884cfa@in-ulm.de>
     [not found]       ` <b689c244-3ea9-4fd6-bb45-a59d131071d6@app.fastmail.com>
     [not found]         ` <CAK0pxsH6bWTLVApE_vDhATmMgaF+nwc5D3pSz4srtwGS-8Ux_A@mail.gmail.com>
2023-01-03 23:02           ` [COFF] Re: [TUHS] Re: Command Line Editing in the Terminal Driver (Was: A few comments on porting the Bourne shell) Adam Thornton

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).