On 1/27/2022 6:26 AM, Chris Townley wrote:
> On 27/01/2022 08:39, Dave Froble wrote:
>> On 1/26/2022 9:51 PM, dthi...@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?
>>
>>> Submit the new code to VSI.
>>>
>>> They can either use it as part of their new DIRECTORY baseline, or it can be
>>> put into the community source program.
>>
>> I have a subroutine that acquires file information. Limited at this time, but
>> easily modified to acquire additional information. Such could be a good
>> beginning to a more general utility. Available to all who ask.
>>
>>
>
> I would be interested to look at it
>

My contact info is below. Send me valid contact info and an email will be on
it's way.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

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

John ...

If I understand what you've written, you've just deplored most all of VMS ...

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

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

Arne

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...@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: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 2022-01-27, Dave Froble <davef@tsoft-inc.com> 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:
>>> Why C, when there are better languages?
>>
>> If you are about to use the B-word, better is relative. 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.
>>
>
> John ...
>
> If I understand what you've written, you've just deplored most all of VMS ...
>

There are application programming languages and then there are system
programming languages.

Much of VMS is written in Macro-32 and BLISS and could well do with
being rewritten in a higher level system language (DEC BASIC is not
such a language based on what I have seen mentioned about it.)

DEC was very much on the right path with Pillar 35 years ago and its
a pity that never came to completion. If it had become established,
today's world might look very different. (After all, C was originally
a Unix-only language until it rapidly took off elsewhere).

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

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

On 1/28/2022 12:31 PM, John Reagan wrote:

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

Yep, I now consider myself incompetent to work with Macro-32, due to
insufficient recent use.

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

Just to be clear, the current implementation of VSI Basic is not useful for
such. But, another implementation could be.

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

Why, yes, I'm rather sure I could. For example, from one of my routines:

RECORD FABBLK !
RECORD NAMBLK !
RECORD FIBBLK ! FIB structure

And now I'm waiting for you to say that the Basic RECORD statement has the same
problems as MAP.

:-(

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

In article <sspht9$20h$1@dont-email.me>, Simon Clubley
<clubley@remove_me.eisner.decus.org-Earth.UFP> writes:

> 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.
>
> Likewise, it would be nice to be able to optionally specify the sort
> order in which filenames are returned by f$search().
>
> Does anyone agree ?

Yes, would be nice.

----------8<--------------------------------------------------------------------

1 SDIR

The Sorted DIRectory command produces a directory listing sorted by either
creation date or size. The default is date. If no filespec is specified,
the current directory is listed.

Note that none of the system DIRECTORY command qualifiers work.

SDIR [qualifiers] [filespec]

/Descending

Causes the output to be printed in descending order instead of ascending
order. By default, the most recent files (or largest) are produced at
the end of the list. /Descned will reverse the order.

/Size

Causes the listing to be sorted by file size instead of date.

PROGRAM SDIR
C*
C* *******************************
C* *******************************
C* ** **
C* ** SDIR **
C* ** **
C* *******************************
C* *******************************
C*
C* AUTHOR :
C* Arthur E. Ragosta
C* RAGOSTA@MERLIN.ARC.NASA.GOV
C*
C* MS 219-1
C* NASA Ames Research Center
C* Moffett Field, Ca. 94035-1000
C* (415) 604-5558
C*
C* DESCRIPTION :
C* SORTED DIRECTORY
C* PRODUCE A SIMPLE DIRECTORY LISTING SORTED BY DATE or SIZE
C*
C* /DESCENDING = OLDEST DATES FIRST, ELSE NEWEST FIRST
C* /SIZE = sort by size instead of date
C*
C* SUBPROGRAM REFERENCES :
C*
C* ASSUMPTIONS AND RESTRICTIONS :
C* NOT TRANSPORTABLE.
C* DIRECTORY TRUNCATED AT 'max_files' FILE NAMES.
C*
C* LANGUAGE AND COMPILER :
C* ANSI FORTRAN 77
C*
C* CHANGE HISTORY :
C* 22 MAR 1993 - INITIAL VERSION
C* 14 SEP 1995 - Converted to alpha
C* 30 OCT 1995 - Bug fixed in USEROPEN
C*
C***********************************************************************
C*
PARAMETER (MAX_FILES=1000)
common /data/
$ date(max_files), direc(max_files), size(max_files),
$ names(max_files), num_files
logical direc
integer size
integer *8 date
character *80 names
c
integer indx(max_files)
c CHARACTER *127 P(2), PATH, next_file
CHARACTER *20 Q(2)
character *23 adate
CHARACTER *4 ON, OFF
LOGICAL D_FLAG, S_FLAG
external my_open
C ON = CHAR(27) // '[1m' ! Bold on
OFF = CHAR(27) // '[0m' ! Bold off
D_FLAG = .FALSE.
S_FLAG = .FALSE.
CALL GETFOR (NQ, Q, NP, P)
DO 1 I = 1, NQ
IF (Q(I)(1:1) .EQ. 'D') THEN ! Just in case he said /DATE
IF ((LENGTH(Q(I)) .LE. 1) .OR. (Q(I)(2:2) .NE. 'A'))
$ D_FLAG = .TRUE.
ENDIF
IF (Q(I)(1:1) .EQ. 'S') S_FLAG = .TRUE.
1 CONTINUE
C C --- Defaults to current directory
C IF (NP .EQ. 0) THEN
CALL DEFAULT ( PATH )
ELSE
PATH = P(1)
ENDIF
CALL PARSE ( PATH, '*.*;*', 'FULL', PATH )
num_files = 0
c c --- loop over wildcards for each file; "MYOPEN" does all the work
c 10 call getfile ( path, next_file )
if (next_file .ne. ' ') then
call parse (next_file, ' ', 'LO', names(num_files+1))
OPEN (UNIT=0, FILE=next_file(1:length(next_file)),
$ STATUS='OLD', ERR=10, useropen=my_open)
30 close(unit=0)
if (num_files .le. max_files) go to 10
endif
C C --- sort file list by date or size
C IF (S_FLAG) THEN
call isorti (size, num_files, indx) ! by File SIZE !!!
ELSE
call isorti8 (date, num_files, indx) ! by DATES !!!
ENDIF
C C --- In descending order ?
C IF (D_FLAG) THEN
ISTART = NUM_FILES
IEND = 1
INCR = -1
ELSE
ISTART = 1
IEND = NUM_FILES
INCR = 1
ENDIF
C C -- Note that directory files are bolded on output
c DO 100 I = ISTART, IEND, INCR
ln = length(names(indx(i)))
c c ----- Sorted by size
c if (s_flag) then
if (direc(indx(i))) then
if (ln .le. 30) then
write (6,900) on,
$ names(indx(i))(1:ln), off, size(i)
else
write (6,901) on,
$ names(indx(i))(1:ln), off, size(i)
endif
else
if (ln .le. 30) then
write (6,910) names(indx(i))(1:ln), size(i)
else
write (6,911) names(indx(i))(1:ln), size(i)
endif
endif
c c ----- Sorted by date
c else
call sys$asctim ( , adate, date(i) ,)
if (direc(indx(i))) then
if (ln .le. 30) then
write (6,920) on,
$ names(indx(i))(1:ln), off, adate(1:17)
else
write (6,921) on,
$ names(indx(i))(1:ln), off, adate(1:17)
endif
else
if (ln .le. 30) then
write (6,930) names(indx(i))(1:ln), adate(1:17)
else
write (6,931) names(indx(i))(1:ln), adate(1:17)
endif
endif
endif
100 CONTINUE
C
CALL EXIT
900 format(' ',3a,t38,i5)
901 format(' ',3a/,t38,i5)
910 format(' ',a,t30,i5)
911 format(' ',a/,t30,i5)
920 format(' ',3a,t38,a)
921 format(' ',3a/,t30,a)
930 format(' ',a,t30,a)
931 format(' ',a/,t30,a)
END
C C---END SDIR
C integer function my_open (fab, rab, lun)
c*
c* This routine is called by the FORTRAN OPEN statement to extract the
c* file size, date, and directory flag for each file.
c*
PARAMETER (MAX_FILES=1000)
common /data/
$ date(2,max_files), direc(max_files), size(max_files),
$ names(max_files), num_files
logical direc
integer size
integer *4 date ! Fudge to make it easier to move quadword
character *80 names
c include '($fabdef)'
c include '($rabdef)'
include '($xabdef)'
include '($xabdatdef)'
include '($xabfhcdef)'
include '($xabitmdef)'
c c --- is this complicated, or what?
c structure /bigxab/
union
map
record/xabdef/ xab
endmap
map
record /xabdatdef/ xabdat
endmap
endunion
endstructure
c structure /bigxab1/
union
map
record/xabdef/ xaba
endmap
map
record /xabfhcdef/ xabfhc
endmap
endunion
endstructure
c structure /bigxab2/
union
map
record/xabdef/ xabb
endmap
map
record /xabitmdef/ xabitm
endmap
endunion
endstructure
c record /fabdef/ fab
c record /rabdef/ rab
record /bigxab/ xab0
record /bigxab1/ xab1
record /bigxab2/ xab2
c structure /itmlst/
integer *2 buflen
integer *2 itemcode
integer *4 bufadr
integer *4 retlen
end structure
record /itmlst/ items(3)
c logical is_dir
integer sys$open, sys$connect
c c --- WARNING !!! The following is not strictly accurate as it should
c scan the XAB list and resolve any differences between my XABs
c and any passed by the USEROPEN routine, but this was a pain
c and (not being a file system expert) I couldn't get it to work
c right. This SEEMS to work.
c isave = fab.fab$l_xab
fab.fab$b_fac = fab$m_get ! readonly
fab.fab$l_xab = %loc(xab0)
c xab0.xab.xab$b_cod = xab$c_dat ! This is a DATE XAB
xab0.xab.xab$b_bln = xab$c_datlen
xab0.xab.xab$l_nxt = %loc(xab1)
c xab1.xaba.xab$b_cod = xab$c_fhc ! size XAB
xab1.xaba.xab$b_bln = xab$c_fhclen
xab1.xaba.xab$l_nxt = %loc(xab2)
c xab2.xabb.xab$b_cod = xab$c_itm ! Item code XAB
xab2.xabb.xab$b_bln = xab$c_itmlen
xab2.xabitm.xab$b_mode= xab$k_sensemode
xab2.xabitm.xab$l_itemlist = %loc(items)
c
Click here to read the complete article

On 1/31/2022 7:17 AM, Phillip Helbig (undress to reply) wrote:
> In article <sspht9$20h$1@dont-email.me>, Simon Clubley
> <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>
>> 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.
>>
>> Likewise, it would be nice to be able to optionally specify the sort
>> order in which filenames are returned by f$search().
>>
>> Does anyone agree ?
>
> Yes, would be nice.
>
> ----------8<--------------------------------------------------------------------
>
> 1 SDIR
>
> The Sorted DIRectory command produces a directory listing sorted by either
> creation date or size. The default is date. If no filespec is specified,
> the current directory is listed.
>
> Note that none of the system DIRECTORY command qualifiers work.
>
> SDIR [qualifiers] [filespec]
>
> /Descending
>
> Causes the output to be printed in descending order instead of ascending
> order. By default, the most recent files (or largest) are produced at
> the end of the list. /Descned will reverse the order.
>
> /Size
>
> Causes the listing to be sorted by file size instead of date.
>
> PROGRAM SDIR

Fortran

:-)

But try and compare number of lines with the Python code.

Arne

On 1/31/2022 9:58 AM, Arne Vajhøj wrote:
> On 1/31/2022 7:17 AM, Phillip Helbig (undress to reply) wrote:
>> In article <sspht9$20h$1@dont-email.me>, Simon Clubley
>> <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>>
>>> 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.
>>>
>>> Likewise, it would be nice to be able to optionally specify the sort
>>> order in which filenames are returned by f$search().
>>>
>>> Does anyone agree ?
>>
>> Yes, would be nice.
>>
>> ----------8<--------------------------------------------------------------------
>>
>> 1 SDIR
>>
>> The Sorted DIRectory command produces a directory listing sorted by either
>> creation date or size. The default is date. If no filespec is specified,
>> the current directory is listed.
>>
>> Note that none of the system DIRECTORY command qualifiers work.
>>
>> SDIR [qualifiers] [filespec]
>>
>> /Descending
>>
>> Causes the output to be printed in descending order instead of ascending
>> order. By default, the most recent files (or largest) are produced at
>> the end of the list. /Descned will reverse the order.
>>
>> /Size
>>
>> Causes the listing to be sorted by file size instead of date.
>>
>> PROGRAM SDIR
>
> Fortran
>
> :-)
>
> But try and compare number of lines with the Python code.
>
> Arne
>

No, try and compare actual code to perform the task. Python has libraries of
extensive code to perform selected tasks. Just because invoking those library
routines appears to be simple doesn't make the actual code small. Usually when
generic code attempts to perform a task, the code size will be larger than task
specific code.

There ain't no magic. You just don't see it.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 1/31/2022 11:26 AM, Dave Froble wrote:
> On 1/31/2022 9:58 AM, Arne Vajhøj wrote:
>> On 1/31/2022 7:17 AM, Phillip Helbig (undress to reply) wrote:
>>>        PROGRAM SDIR
>>
>> Fortran
>>
>> :-)
>>
>> But try and compare number of lines with the Python code.
>
> No, try and compare actual code to perform the task.  Python has
> libraries of extensive code to perform selected tasks.  Just because
> invoking those library routines appears to be simple doesn't make the
> actual code small.  Usually when generic code attempts to perform a
> task, the code size will be larger than task specific code.
>
> There ain't no magic.  You just don't see it.

It is true that there are two separate reasons behind
the difference:
- Python using less lines than Fortran for processing
- Python having a more powerful RTL than Fortran

But I would not discard the second point.

It is not something the user has to write. It not something VMS
specific. It is not something special that only make sense for
one specific use case.

Having a powerful RTL is a benefit of the language.

Which is why newer languages tend to have crazy huge
RTL's.

Arne

PS: The posted code does not seem to be complete. It seems
to rely on some library. :-)

On 1/31/22 09:58, Arne Vajhøj wrote:
> On 1/31/2022 7:17 AM, Phillip Helbig (undress to reply) wrote:
>> In article <sspht9$20h$1@dont-email.me>, Simon Clubley
>> <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>>
>>> 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.
>>>
>>> Likewise, it would be nice to be able to optionally specify the sort
>>> order in which filenames are returned by f$search().
>>>
>>> Does anyone agree ?
>>
>> Yes, would be nice.
>>
>> ----------8<--------------------------------------------------------------------
>>
>>
>> 1 SDIR
>>
>> The Sorted DIRectory command produces a directory listing sorted by
>> either
>> creation date or size.  The default is date.  If no filespec is
>> specified,
>> the current directory is listed.
>>
>> Note that none of the system DIRECTORY command qualifiers work.
>>
>>      SDIR [qualifiers] [filespec]
>>
>> /Descending
>>
>> Causes the output to be printed in descending order instead of ascending
>> order.  By default, the most recent files (or largest) are produced at
>> the end of the list.  /Descned will reverse the order.
>>
>> /Size
>>
>> Causes the listing to be sorted by file size instead of date.
>>
>>        PROGRAM SDIR
>
> Fortran
>
> :-)
>
> But try and compare number of lines with the Python code.
>

The point being?

bill

On 1/31/2022 12:12 PM, Bill Gunshannon wrote:
> On 1/31/22 09:58, Arne Vajhøj wrote:
>> On 1/31/2022 7:17 AM, Phillip Helbig (undress to reply) wrote:
>>> In article <sspht9$20h$1@dont-email.me>, Simon Clubley
>>> <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>>>
>>>> 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.
>>>>
>>>> Likewise, it would be nice to be able to optionally specify the sort
>>>> order in which filenames are returned by f$search().
>>>>
>>>> Does anyone agree ?
>>>
>>> Yes, would be nice.
>>>
>>> ----------8<--------------------------------------------------------------------
>>>
>>>
>>> 1 SDIR
>>>
>>> The Sorted DIRectory command produces a directory listing sorted by
>>> either
>>> creation date or size.  The default is date.  If no filespec is
>>> specified,
>>> the current directory is listed.
>>>
>>> Note that none of the system DIRECTORY command qualifiers work.
>>>
>>>      SDIR [qualifiers] [filespec]
>>>
>>> /Descending
>>>
>>> Causes the output to be printed in descending order instead of ascending
>>> order.  By default, the most recent files (or largest) are produced at
>>> the end of the list.  /Descned will reverse the order.
>>>
>>> /Size
>>>
>>> Causes the listing to be sorted by file size instead of date.
>>>
>>>        PROGRAM SDIR
>>
>> Fortran
>>
>> :-)
>>
>> But try and compare number of lines with the Python code.
>
> The point being?

That Fortran may not be the right language for the task.

And just for the record: Python is a good choice for
a user solution, but not for a VSI solution.

Arne

On 2022-01-31, Dave Froble <davef@tsoft-inc.com> wrote:
>
> No, try and compare actual code to perform the task. Python has libraries of
> extensive code to perform selected tasks. Just because invoking those library
> routines appears to be simple doesn't make the actual code small. Usually when
> generic code attempts to perform a task, the code size will be larger than task
> specific code.
>
> There ain't no magic. You just don't see it.
>

Fine. So how many RTL lines of code are behind those DEC Basic statements
that you like to use and should all those lines of RTL code be counted
in the program total ? :-) :-)

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 1/31/2022 2:29 PM, Simon Clubley wrote:
> On 2022-01-31, Dave Froble <davef@tsoft-inc.com> wrote:
>>
>> No, try and compare actual code to perform the task. Python has libraries of
>> extensive code to perform selected tasks. Just because invoking those library
>> routines appears to be simple doesn't make the actual code small. Usually when
>> generic code attempts to perform a task, the code size will be larger than task
>> specific code.
>>
>> There ain't no magic. You just don't see it.
>>
>
> Fine. So how many RTL lines of code are behind those DEC Basic statements
> that you like to use and should all those lines of RTL code be counted
> in the program total ? :-) :-)
>
> Simon.
>

As I wrote, there ain't no magic, you just don't see it.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

> How do y'all handle multiple versions of files when sorting by date or
> size and such?

Personally, I'd tend to do what the user requested. Think about it.

> Do you let them just fall where they may based on what you're sorting
> by? [...]

If that's what the user requested.

> [...] Group them together? [...]

And _not_ sort them as the user requested?

> [...] Only process the current version of each file?

Define "current version". And _not_ show all the files requested by
the user?

If the user wants only the highest version (which might not be the
latest), then there's a syntax for that: ";0" (or ";"). So far as I
know, there's no way to specify "latest".

Den 2022-02-09 kl. 02:45, skrev alanfe...@gmail.com:
> On Monday, January 31, 2022 at 2:56:26 PM UTC-5, Dave Froble wrote:
>
> [...]
>
> Not intending to reply here to anyone specifically. Just a question.
>
> How do y'all handle multiple versions of files when sorting by date or size and such?
>
> Do you let them just fall where they may based on what you're sorting by? Group them together? Only process the current version of each file?
>
> Just curious.

As Steven also implied, this question is probably to general
to be abel to respond to in a clear way.

In 99.9% of the cases "sorting by version" and "sorting by date"
is the same thing. It is (at least here) *very* uncommon that
file vesions are not in timestamp order.

For sorting (or rather searching) by date, I use the /sin and /bef
switches to "zoom in" to what I'm looking for.

But yes, in most cases, it is the highest/latest version that is used.

> As Steven also implied, this question is probably to general
> to be abel to respond to in a clear way.

Did he imply it, or did you infer it?

It's not too "general"; it's too confused. If you have one sort
criterion (say, modification date+time), then you have one sort
criterion. And a sort criterion should be a sort criterion, and, as
such, should not change content selection.

Everything's complicated, but contradiction/nonsense is often
avoidable. If you expect a program to guess what you'd really like to
see when that's different from what you requested (or ambiguous, or
worse), then you should get used to disappointment.

> But yes, in most cases, it is the highest/latest version that is used.

What to do with versions in some /REVERSE sort scheme might be worth
some thought, but "in most cases" generally means "not always", and
"highest" and "latest" are spelled differently for a reason.

Den 2022-02-09 kl. 14:26, skrev Steven Schweda:
>> As Steven also implied, this question is probably to general
>> to be abel to respond to in a clear way.
>
> Did he imply it, or did you infer it?

Yes, probably one of them. I have another main language...

On 2022-02-09, Steven Schweda <sms.antinode@gmail.com> wrote:
>
> What to do with versions in some /REVERSE sort scheme might be worth
> some thought, but "in most cases" generally means "not always", and
> "highest" and "latest" are spelled differently for a reason.

In this case, the version is just another component of a unique filename
that is unconnected to any other filenames that have the same filename
and filetype but a different version number.

Showing versions of a filename strictly in the requested sort order,
without regard to any other versions, is the correct thing to do.

For example, a reverse sort by date (with the most recent first) would
be output as:

A.A;22 1-Jan-2022 13:03:00
B.B;5 1-Jan-2022 13:02:30
A.A;21 1-Jan-2022 13:01:00

Likewise, for a forward sort:

A.A;21 1-Jan-2022 13:01:00
B.B;5 1-Jan-2022 13:02:30
A.A;22 1-Jan-2022 13:03:00

Simon.

PS: Steven, is it possible for you to use a NNTP client which includes
the name of who you are replying to when you quote a posting ?

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

In article <0fc2fca8-4ab4-46aa-bf51-a3ee070b5bd5n@googlegroups.com>,
Steven Schweda <sms.antinode@gmail.com> writes:

> It's not too "general"; it's too confused. If you have one sort
> criterion (say, modification date+time), then you have one sort
> criterion. And a sort criterion should be a sort criterion, and, as
> such, should not change content selection.

Ideally, one could have several sort criteria, and items would be sorted
in order of the first one, then the second one, and so on, like
SORT/KEY:

You can specify up to 255 key fields in a sorting operation. If
you do specify multiple keys, decide which is primary, which is
secondary, and so on; then, in the command string, list them in
the order of their priority.

By default, Sort assigns 1 to the first key specified in the
command line, 2 to the second key, and so on. If you do not list
the keys in the order of their priority, specify the order of
each with the parameter NUMBER:n.

On 2022-02-09, Phillip Helbig (undress to reply) <helbig@asclothestro.multivax.de> wrote:
> In article <0fc2fca8-4ab4-46aa-bf51-a3ee070b5bd5n@googlegroups.com>,
> Steven Schweda <sms.antinode@gmail.com> writes:
>
>> It's not too "general"; it's too confused. If you have one sort
>> criterion (say, modification date+time), then you have one sort
>> criterion. And a sort criterion should be a sort criterion, and, as
>> such, should not change content selection.
>
> Ideally, one could have several sort criteria, and items would be sorted
> in order of the first one, then the second one, and so on, like
> SORT/KEY:
>

Sorting is based on metadata about the file (size, creation date/time, etc).

It makes no real sense to sort on anything other than just one key
as you would need multiple entries to have _exactly_ the same metadata
(exact same file size, exact same creation date/time) in order to make a
difference.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On Wednesday, February 9, 2022 at 2:02:34 AM UTC-5, Steven Schweda wrote:
> > How do y'all handle multiple versions of files when sorting by date or
> > size and such?
> Personally, I'd tend to do what the user requested. Think about it.
> > Do you let them just fall where they may based on what you're sorting
> > by? [...]
>
> If that's what the user requested.

I, as an OpenVMS user for many years, have many requests. DEC/Compaq/hp/VSI have fulfilled none of them. I use what they give me.

>
> > [...] Group them together? [...]
>
> And _not_ sort them as the user requested?

Who is this all powerful user you refer to? It is quite rare that a company gives me what I ask for. But it does happen from time to time.

>
> > [...] Only process the current version of each file?
>
> Define "current version". And _not_ show all the files requested by
> the user?

Hmmm. I thought this would be clear. I guess not. I will give an example:

file.fil;4
file.fil;2
file.fil;1

If this is the full listing of this file in a given directory, the ;4 is the current version.

>
> If the user wants only the highest version (which might not be the
> latest), then there's a syntax for that: ";0" (or ";"). So far as I
> know, there's no way to specify "latest".

Many users here in cov have requested many things. Have any of them come to pass?

A semicolon that is not followed by a number is secret code for "the latest."

AEF

On 2/8/2022 8:45 PM, alanfe...@gmail.com wrote:
> Not intending to reply here to anyone specifically. Just a question.
>
> How do y'all handle multiple versions of files when sorting by date or size and such?
>
> Do you let them just fall where they may based on what you're sorting by? Group them together? Only process the current version of each file?

File version is part of file name, so I think the least surprising
when sorting after something that is not file name to let them fall
whereever.

Arne

On Wednesday, February 9, 2022 at 5:06:51 AM UTC-5, Jan-Erik Söderholm wrote:
> Den 2022-02-09 kl. 02:45, skrev alanfe...@gmail.com:
> > On Monday, January 31, 2022 at 2:56:26 PM UTC-5, Dave Froble wrote:
> >
> > [...]
> >
> > Not intending to reply here to anyone specifically. Just a question.
> >
> > How do y'all handle multiple versions of files when sorting by date or size and such?
> >
> > Do you let them just fall where they may based on what you're sorting by? Group them together? Only process the current version of each file?
> >
> > Just curious.
> As Steven also implied, this question is probably to general
> to be abel to respond to in a clear way.
>
> In 99.9% of the cases "sorting by version" and "sorting by date"
> is the same thing. It is (at least here) *very* uncommon that
> file vesions are not in timestamp order.

Suppose you have the following:

a.a;2 3-feb-2022
a.a;1 1-feb-2022
b.b;2 4-feb-2022
b.b;1 2-feb-2022

In order by date:

b.b;2
a.a;2
b.b;1
a.a;1

The two versions of a.a are mixed with the two versions of b.b. But in a long, more complex list, you would have a hard time coming across a file somewhere in the middle and being able to easily deduce if it is the current version, or highest version, or latest version, or whatever you want to call it, or not. (To be precise, the version with the largest version number.)

When I sort by date on the mac, the Finder groups files by folder, or type, or whatever you select, and sorts by date individually for each group. That's different from the above. One could skip all but the highest-number version or one could list them strictly in order ignoring file names
>
> For sorting (or rather searching) by date, I use the /sin and /bef
> switches to "zoom in" to what I'm looking for.
>
> But yes, in most cases, it is the highest/latest version that is used.

Thank you.