[Info-vax] Suggestion: Adding a /SORT option to DIRECTORY and F$SEARCH ?

[John Reagan]

On Thursday, January 27, 2022 at 2:02:21 PM UTC-5, Dave Froble wrote:
> On 1/27/2022 11:59 AM, Arne Vajhøj wrote: 
> > On 1/27/2022 11:25 AM, John Reagan wrote: 
> >> On Thursday, January 27, 2022 at 3:39:38 AM UTC-5, Dave Froble wrote: 
> >>> On 1/26/2022 9:51 PM, dthi... at gmail.com wrote: 
> >>>> 
> >>>>> It would be nice to be able to see the output from a DIRECTORY command 
> >>>>> optionally sorted by one of largest size, smallest size, oldest date, 
> >>>>> newest date, etc. 
> >>>> 
> >>>> This sounds like a good opportunity for some community-contributed software 
> >>>> (like the old DECUS Library). :-)) 
> >>>> IIRC, there have been modified directory-like program submissions in the past. 
> >>> Nah, today's users want the vendor to do all the work ... 
> >>>> Write a new program, DIRECTORY2 and a CLD file to do what you'd like the 
> >>>> modified DIRECTORY to do, either using: 
> >>>> 1) Existing DIRECTORY source code from VSI, in whatever language it's 
> >>>> written in, and enhance it the way you want, OR 
> >>>> 2) Create new program code in C, calling system routines to do the work. 
> >>> Why C, when there are better languages? 
> >> 
> >> If you are about to use the B-word, better is relative. 
> > 
> > Obviously. 
> > 
> > But not everybody is in love with C. 
> > 
> > Personally I consider C a fine language for OS kernel development 
> > but not so great a language for more regular applications. And 
> > DIR is really an application. 
> > 
> > I am not good at VMS Basic, so I would prefer VMS Pascal. 
> > 
> > :-) 
> > 
> >> And if there was such an important tool in BASIC, would have needed 
> >> Macro, C, BLISS AND BASIC compilers (and their nightmare RTLs) in the 
> >> development path. I don't want another critical, proprietary tool in 
> >> the system. 
> > Is that current VSI policy: VMS build should only depend on Macro-32, 
> > Macro-native, Bliss and C?
> How I read it is that John doesn't like anything in that list. But perhaps my 
> reading comprehension is lacking. Would not be the first time. 
> 
> :-) 
> 
> I believe that the VSI policy is to use only the custom version of C they have 
> for all new VMS work. I also agree with this concept, regardless of my feelings 
> about C. VSI needs things to be as simple as possible. 
> 
> Macro-32 and Bliss already exist, no sense in re-implementing the wheel, or that 
> code, as long as it works. But I've seen multiple references to VSI re-writing 
> parts of VMS in C where continuing to use the MAcro-32 and Bliss becomes an issue. 
> 
> I agree with that policy. Anything outside what VSI provides is better in a 
> DECUS library or FreeWare library.
> -- 
> David Froble Tel: 724-529-0450 
> Dave Froble Enterprises, Inc. E-Mail: da... at tsoft-inc.com 
> DFE Ultralights, Inc. 
> 170 Grimplin Road 
> Vanderbilt, PA 15486

1) The shear number of compiler toolchain pieces needed to build (or port) the system

2) Engineer portability.  It is difficult enough for an engineer to bounce around and find 
C code, BLISS code, and Macro-32 code.  Somebody people are not familiar with all of
the languages and end up asking me questions about each.  Adding another language
like BASIC (or Pascal or Ada) simply makes it more difficult to find and train engineers
to be productive and independent.

3) Languages like BASIC which is very dependent on heap storage would be difficult to
use in the kernel (yes, I know we started talking about DIRECTORY) since memory allocation
and stack usage are difficult.  We recently had an issue with some kernel code (written
in C) wanting to turn an integer into a character string.  A C program says "I'll use sprintf".
Of course sprintf() may do things like "open a locale file", "write an errno back into your
thread's errno variable", malloc() some temporary storage and even if free()'d you'd now
have kernel-owned pages in your LIB$VM's cache, etc.  [All you Macro/BLISS users know
that $FAO is a nice, low-overhead, safe to use anywhere service to convert an integer into
a string.]

4) As we've discussed the BASIC cross-compiler is still not available due to G2L not being
able to totally handle how the BASIC MAP statement is described to GEM.  The GEM to
LLVM module for common blocks is radically different.  Could you write a DIRECTORY
replacement in BASIC without using MAP?