* Directory listings and path names @ 2002-01-17 11:21 Andreas Valdusson 2002-01-17 13:00 ` M. A. Alves 2002-01-18 13:09 ` Joachim Schröer 0 siblings, 2 replies; 31+ messages in thread From: Andreas Valdusson @ 2002-01-17 11:21 UTC (permalink / raw) If I have the name of a directory, and want ADA to get the names of all sub-directories of this one, how do I do? How do I get the contents of a specific directory (ie. the names for all subdirectories and files) and how do I know which of these that are sub-directories an which are files? /Andreas ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Directory listings and path names 2002-01-17 11:21 Directory listings and path names Andreas Valdusson @ 2002-01-17 13:00 ` M. A. Alves 2002-01-18 22:58 ` Brian Rogoff 2002-01-18 13:09 ` Joachim Schröer 1 sibling, 1 reply; 31+ messages in thread From: M. A. Alves @ 2002-01-17 13:00 UTC (permalink / raw) To: comp.lang.ada On Thu, 17 Jan 2002, Andreas Valdusson wrote: > If I have the name of a directory, and want ADA to get the names of > all sub-directories of this one, how do I do? How do I get the > contents of a specific directory (ie. the names for all subdirectories > and files) and how do I know which of these that are sub-directories > an which are files? These are services of the Operating System, not of Ada (the programming language), neither of the American Dental Association. You can call the OS services from an Ada program, thru a _binding_. I bet you can find a couple of packages implementing such bindings freely available on the Internet. If you are using GNAT, you already have it: GNAT.OS_Lib :-) -- , M A R I O data miner, LIACC, room 221 tel 351+226078830, ext 121 A M A D O Rua Campo Alegre, 823 fax 351+226003654 A L V E S P-4150-180 PORTO, Portugal mob 351+939354002 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Directory listings and path names 2002-01-17 13:00 ` M. A. Alves @ 2002-01-18 22:58 ` Brian Rogoff 2002-01-19 3:03 ` Larry Kilgallen ` (2 more replies) 0 siblings, 3 replies; 31+ messages in thread From: Brian Rogoff @ 2002-01-18 22:58 UTC (permalink / raw) On Thu, 17 Jan 2002, M. A. Alves wrote: > On Thu, 17 Jan 2002, Andreas Valdusson wrote: > > If I have the name of a directory, and want ADA to get the names of > > all sub-directories of this one, how do I do? How do I get the > > contents of a specific directory (ie. the names for all subdirectories > > and files) and how do I know which of these that are sub-directories > > an which are files? > > These are services of the Operating System, not of Ada (the programming > language), Says you! I could argue the same about tasking. IMO, it would be a good thing if there were some sort of standard directory package. I know, someone will argue that file systems are different. Oh yeah? So are the multitasking capabilities of various OSes. > I bet you can find a > couple of packages implementing such bindings freely available on the > Internet. If you are using GNAT, you already have it: GNAT.OS_Lib :-) True, but Ada should provide the support out of the box. This is one of the first things I need when I start with any programming language. -- Brian ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Directory listings and path names 2002-01-18 22:58 ` Brian Rogoff @ 2002-01-19 3:03 ` Larry Kilgallen 2002-01-19 14:28 ` Robert A Duff 2002-01-19 14:20 ` Georg Bauhaus 2002-01-22 16:36 ` Marin David Condic 2 siblings, 1 reply; 31+ messages in thread From: Larry Kilgallen @ 2002-01-19 3:03 UTC (permalink / raw) In article <Pine.BSF.4.40.0201182253560.954-100000@bpr.best.vwh.net>, Brian Rogoff <bpr@bpr.best.vwh.net> writes: > On Thu, 17 Jan 2002, M. A. Alves wrote: >> On Thu, 17 Jan 2002, Andreas Valdusson wrote: >> > If I have the name of a directory, and want ADA to get the names of >> > all sub-directories of this one, how do I do? How do I get the >> > contents of a specific directory (ie. the names for all subdirectories >> > and files) and how do I know which of these that are sub-directories >> > an which are files? >> >> These are services of the Operating System, not of Ada (the programming >> language), > > Says you! I could argue the same about tasking. > > IMO, it would be a good thing if there were some sort of standard > directory package. I know, someone will argue that file systems are > different. Oh yeah? So are the multitasking capabilities of various OSes. But a subset of multitasking capabilities has been chosen as being adequate for Ada programs. Declaring a similar subset for files is more difficult because files are used for communication with other components of the computing environment. Do I want only files that are present on the system or should shelved files in that directory be included ? How do I access only the third newest version (VMS terminology - someone else can translated it into partitioned data set terminology for IBM machines). Which of those file operations are viable on magnetic tape, and which are restricted to disk files. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Directory listings and path names 2002-01-19 3:03 ` Larry Kilgallen @ 2002-01-19 14:28 ` Robert A Duff 2002-01-19 22:45 ` Brian Rogoff 0 siblings, 1 reply; 31+ messages in thread From: Robert A Duff @ 2002-01-19 14:28 UTC (permalink / raw) Kilgallen@SpamCop.net (Larry Kilgallen) writes: > >> These are services of the Operating System, not of Ada (the programming > >> language), > > > > Says you! Well, it's true... >... I could argue the same about tasking. You can argue what you like, but it would still be false. ;-) > > IMO, it would be a good thing if there were some sort of standard > > directory package. I know, someone will argue that file systems are > > different. Oh yeah? So are the multitasking capabilities of various OSes. > > But a subset of multitasking capabilities has been chosen as being > adequate for Ada programs. Declaring a similar subset for files is > more difficult because files are used for communication with other > components of the computing environment. Nonetheless, the ARG is working on a directory operations package. > Do I want only files that are present on the system or should shelved > files in that directory be included ? How do I access only the third > newest version (VMS terminology - someone else can translated it into > partitioned data set terminology for IBM machines). Which of those > file operations are viable on magnetic tape, and which are restricted > to disk files. Well, any interface-to-OS package has to be somewhat "least-common-denominator"-ish, if it is to be portable. - Bob ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Directory listings and path names 2002-01-19 14:28 ` Robert A Duff @ 2002-01-19 22:45 ` Brian Rogoff 2002-01-19 23:02 ` Nick Roberts 2002-01-22 14:45 ` Stephen Leake 0 siblings, 2 replies; 31+ messages in thread From: Brian Rogoff @ 2002-01-19 22:45 UTC (permalink / raw) On Sat, 19 Jan 2002, Robert A Duff wrote: > Kilgallen@SpamCop.net (Larry Kilgallen) writes: > > > >> These are services of the Operating System, not of Ada (the programming > > >> language), > > > > > > Says you! > > Well, it's true... > > >... I could argue the same about tasking. > > You can argue what you like, but it would still be false. ;-) I see that postmodernism and philosophical relativism have not made great progress in c.l.a ;-) Surely, we can find many OSes which provide no tasking, some tasking, sophisticated tasking, etc. I subscribe to the view that what goes in a language versus what goes in an OS is rather arbitrary. The same is true for language and library. Library design is language design. > > > IMO, it would be a good thing if there were some sort of standard > > > directory package. I know, someone will argue that file systems are > > > different. Oh yeah? So are the multitasking capabilities of various OSes. > > > > But a subset of multitasking capabilities has been chosen as being > > adequate for Ada programs. Declaring a similar subset for files is > > more difficult because files are used for communication with other > > components of the computing environment. > > Nonetheless, the ARG is working on a directory operations package. Yes, and that is a very good thing. The fact that Ada 95 did not provide such a package has always been a bummer to me. IMO, part of the reason Ada has failed to make a huge contribution in reusability is that it never had the prerequisite usability. You can start with Python and immediately use it for the mundane file munging tasks that many of us need to do, without having to write your own bindings to the OS. Java also comes with fairly extensive libraries for this sort of thing. BTW, I'm speaking of Ada, not GNAT here. GNAT has had a lot of what I want "out of the box" for a long time, but one of the supposed virtues of Ada is supposedly portability. > > Do I want only files that are present on the system or should shelved > > files in that directory be included ? How do I access only the third > > newest version (VMS terminology - someone else can translated it into > > partitioned data set terminology for IBM machines). Well, the first thing you have to understand is that VMS is dead :-). > Well, any interface-to-OS package has to be somewhat > "least-common-denominator"-ish, if it is to be portable. Correct. It would also be nice to provide more specific packages, like, say, Windows, Unix/Posix, Mac (and also rans like VMS, BeOS, Amiga,... :). -- Brian ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Directory listings and path names 2002-01-19 22:45 ` Brian Rogoff @ 2002-01-19 23:02 ` Nick Roberts 2002-01-22 14:45 ` Stephen Leake 1 sibling, 0 replies; 31+ messages in thread From: Nick Roberts @ 2002-01-19 23:02 UTC (permalink / raw) "Brian Rogoff" <bpr@bpr.best.vwh.net> wrote in message news:Pine.BSF.4.40.0201192225200.74428-100000@bpr.best.vwh.net... > On Sat, 19 Jan 2002, Robert A Duff wrote: > > Well, any interface-to-OS package has to be somewhat > > "least-common-denominator"-ish, if it is to be portable. > > Correct. It would also be nice to provide more specific packages, like, > say, Windows, Unix/Posix, Mac (and also rans like VMS, BeOS, Amiga,... :). The proposed package will allow implementation-defined children which provide extra functionality specific to a particular OS or execution environment. -- Best wishes, Nick Roberts ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Directory listings and path names 2002-01-19 22:45 ` Brian Rogoff 2002-01-19 23:02 ` Nick Roberts @ 2002-01-22 14:45 ` Stephen Leake 2002-01-22 16:50 ` Brian Rogoff 2002-01-22 17:57 ` tmoran 1 sibling, 2 replies; 31+ messages in thread From: Stephen Leake @ 2002-01-22 14:45 UTC (permalink / raw) Brian Rogoff <bpr@bpr.best.vwh.net> writes: > Surely, we can find many OSes which provide no tasking, some tasking, > sophisticated tasking, etc. I subscribe to the view that what goes in > a language versus what goes in an OS is rather arbitrary. The same is > true for language and library. Library design is language design. I don't think this is true. The tasking constructs in Ada _cannot_ be provided by an Ada package; they require compiler support. Thus they are fundamentally different from directory operations, which clearly _can_ be provided by a package. This is separate from the question of whether a directory/file operations package should be part of the standard. I agree it would be nice, also hard. Perhaps a good compromise would be for all the Ada vendors to support the Florist POSIX bindings, on OS's where that is not too hard. -- -- Stephe ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Directory listings and path names 2002-01-22 14:45 ` Stephen Leake @ 2002-01-22 16:50 ` Brian Rogoff 2002-01-22 17:03 ` Jean-Marc Bourguet 2002-01-22 17:57 ` tmoran 1 sibling, 1 reply; 31+ messages in thread From: Brian Rogoff @ 2002-01-22 16:50 UTC (permalink / raw) On 22 Jan 2002, Stephen Leake wrote: > Brian Rogoff <bpr@bpr.best.vwh.net> writes: > > > Surely, we can find many OSes which provide no tasking, some tasking, > > sophisticated tasking, etc. I subscribe to the view that what goes in > > a language versus what goes in an OS is rather arbitrary. The same is > > true for language and library. Library design is language design. > > I don't think this is true. The tasking constructs in Ada _cannot_ be > provided by an Ada package; they require compiler support. Thus they > are fundamentally different from directory operations, which clearly > _can_ be provided by a package. Right, I was misleading. My point was simply that the services that an OS provides are not fixed in stone, so arguing that one thing or another is a language feature or an OS feature is pointless. The languages designers should simply decide what goes into the language. In any case, believe it or not, lots of people do concurrent programming in languages without built-in tasking, and rely on library packages to provide that support. > This is separate from the question of whether a directory/file > operations package should be part of the standard. I agree it would be > nice, also hard. Perhaps a good compromise would be for all the Ada > vendors to support the Florist POSIX bindings, on OS's where that is > not too hard. I think it would be very nice, and not too hard. The Python model works well enough. Besides, Ada has this wonderful package mechanism, why not use it to standardize bindings to Unix, Windows, Mac, VMS (see Larry, I didn't forget you ;), etc? This being 2002, I expect any practical programming language to have a built-in way to do this. I admit, I'm Unix/Windows centric. However, the competition is tough, and we're really talking about very basic functionality that is not being provided. -- Brian ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Directory listings and path names 2002-01-22 16:50 ` Brian Rogoff @ 2002-01-22 17:03 ` Jean-Marc Bourguet 0 siblings, 0 replies; 31+ messages in thread From: Jean-Marc Bourguet @ 2002-01-22 17:03 UTC (permalink / raw) Brian Rogoff <bpr@bpr.best.vwh.net> writes: > In any case, believe it or not, lots of people do concurrent programming > in languages without built-in tasking, and rely on library packages to > provide that support. They also rely on their compiler to behave sanely. I'd not more rely on a compiler which is not thread aware to build an application with threads at least in C++ (thinks about exception handling, this is an area where the generated code can be easily not thread save). -- Jean-Marc ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Directory listings and path names 2002-01-22 14:45 ` Stephen Leake 2002-01-22 16:50 ` Brian Rogoff @ 2002-01-22 17:57 ` tmoran 2002-01-22 18:40 ` Larry Kilgallen 1 sibling, 1 reply; 31+ messages in thread From: tmoran @ 2002-01-22 17:57 UTC (permalink / raw) >Perhaps a good compromise would be for all the Ada >vendors to support the Florist POSIX bindings, Do people prefer the POSIX directory iterator style generic with procedure Action(...) procedure For_Each(Wild_Card_Name_String : in String;...) that iterates through the directory calling Action on each file, or do people prefer the IO-ish procedure Open procedure Get_Next procedure Close ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Directory listings and path names 2002-01-22 17:57 ` tmoran @ 2002-01-22 18:40 ` Larry Kilgallen 0 siblings, 0 replies; 31+ messages in thread From: Larry Kilgallen @ 2002-01-22 18:40 UTC (permalink / raw) In article <6Kh38.35040$YM1.1631665254@newssvr21.news.prodigy.com>, tmoran@acm.org writes: >>Perhaps a good compromise would be for all the Ada >>vendors to support the Florist POSIX bindings, > Do people prefer the POSIX directory iterator style > generic > with procedure Action(...) > procedure For_Each(Wild_Card_Name_String : in String;...) > that iterates through the directory calling Action on each file, or > do people prefer the IO-ish > procedure Open > procedure Get_Next > procedure Close I find the second style better when I am doing uncommon things, such as looking for all files of which there are fewer than 3 versions. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Directory listings and path names 2002-01-18 22:58 ` Brian Rogoff 2002-01-19 3:03 ` Larry Kilgallen @ 2002-01-19 14:20 ` Georg Bauhaus 2002-01-22 16:36 ` Marin David Condic 2 siblings, 0 replies; 31+ messages in thread From: Georg Bauhaus @ 2002-01-19 14:20 UTC (permalink / raw) Brian Rogoff <bpr@bpr.best.vwh.net> wrote: : True, but Ada should provide the support out of the box. I don't believe Brian isn't are of this, but the pointer might still be useful: From http://www.ada-auth.org/AI-SUMMARY.HTML: AI95-00248-01/04 2002-01-02 -- Directory Operations Priority: Medium Difficulty: Medium Class: Amendment Status: Work Item 00-11-28 RM References: A.15 (00) ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Directory listings and path names 2002-01-18 22:58 ` Brian Rogoff 2002-01-19 3:03 ` Larry Kilgallen 2002-01-19 14:20 ` Georg Bauhaus @ 2002-01-22 16:36 ` Marin David Condic 2002-01-23 13:47 ` Jean-Pierre Rosen ` (2 more replies) 2 siblings, 3 replies; 31+ messages in thread From: Marin David Condic @ 2002-01-22 16:36 UTC (permalink / raw) Not strictly true. Accessing a file system rather implies that there *is* a file system and hence something vaguely resembling an OS that accesses it. Tasking, OTOH, can exist on a bare-silicon platform with nothing more than some sort of Ada RTK that supports the scheduling. (Unless we want to insist that anything at least as sophisticated as an Ada RTK can be considered an "Operating System".) On yet another hand, I do agree that it would be a good idea for Ada to provide a semi-standard interface to an OS file system. It would necessarily be reduced to the least common denominator, but with child packages, it would be possible to isolate interfaces for the most common OS's where there may be non-portable features in question. Could this be part of the ARM? A better place to start would be with an informal consensus & see if it might eventually be something that could migrate to a more formal standard. MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com Web: http://www.mcondic.com/ "Brian Rogoff" <bpr@bpr.best.vwh.net> wrote in message news:Pine.BSF.4.40.0201182253560.954-100000@bpr.best.vwh.net... > > Says you! I could argue the same about tasking. > > IMO, it would be a good thing if there were some sort of standard > directory package. I know, someone will argue that file systems are > different. Oh yeah? So are the multitasking capabilities of various OSes. > > > I bet you can find a > > couple of packages implementing such bindings freely available on the > > Internet. If you are using GNAT, you already have it: GNAT.OS_Lib :-) > > True, but Ada should provide the support out of the box. > > This is one of the first things I need when I start with any programming > language. > > -- Brian > ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Directory listings and path names 2002-01-22 16:36 ` Marin David Condic @ 2002-01-23 13:47 ` Jean-Pierre Rosen 2002-01-23 14:32 ` Marin David Condic 2002-01-23 17:27 ` Mark Biggar 2002-01-25 0:17 ` Brian Rogoff 2 siblings, 1 reply; 31+ messages in thread From: Jean-Pierre Rosen @ 2002-01-23 13:47 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 898 bytes --] "Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> a �crit dans le message news: > On yet another hand, I do agree that it would be a good idea for Ada to > provide a semi-standard interface to an OS file system. It would necessarily > be reduced to the least common denominator Not necessarily. Have a look at package OS_Services from Adalog's component page (http://www.adalog.fr/compo2.htm) for a system that allows a lot of flexibility. It achieves the following goal: - if functionnality XYZ is provided, it works independently of the OS - if functionnality XYZ is *not* provided (and you need it), it doesn't compile. In short, a program will work on any platform that supports the functionnalities needed by the program. -- --------------------------------------------------------- J-P. Rosen (rosen@adalog.fr) Visit Adalog's web site at http://www.adalog.fr ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Directory listings and path names 2002-01-23 13:47 ` Jean-Pierre Rosen @ 2002-01-23 14:32 ` Marin David Condic 2002-01-23 16:23 ` Jean-Pierre Rosen 0 siblings, 1 reply; 31+ messages in thread From: Marin David Condic @ 2002-01-23 14:32 UTC (permalink / raw) Thanks. I'll take a look at it. I can see value in trying to create the most flexible interface possible but I think you'd have to admit that there are some features of OS #1 that are just simply not going to exist or even make sense under OS #2. In some of those cases, you might be able to get clever and find a way to keep those features from compiling under OS #2, but I could still see it as being particularly attractive to say "Here's a set of features that make sense for (almost) any operating system under package name X and here are features that only make sense or are supported by OS #1 under package name X.OS_1, etc..." That way, you can develop code that is OS independent if you like *or* take advantage of peculiarities of a particular OS through an interface you feel comfortable will be there for (almost) any Ada implementation that targets that particular system. Clearly, whatever can be made OS independent, ought to be. But there are reasons why, sometimes, Windows is better for something than Unix or has features that won't exist in any form under Unix, etc. MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com Web: http://www.mcondic.com/ "Jean-Pierre Rosen" <rosen@adalog.fr> wrote in message news:a2mf2e$h1q$1@s1.read.news.oleane.net... > > Not necessarily. Have a look at package OS_Services from Adalog's component page (http://www.adalog.fr/compo2.htm) for a system that > allows a lot of flexibility. It achieves the following goal: > - if functionnality XYZ is provided, it works independently of the OS > - if functionnality XYZ is *not* provided (and you need it), it doesn't compile. > > In short, a program will work on any platform that supports the functionnalities needed by the program. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Directory listings and path names 2002-01-23 14:32 ` Marin David Condic @ 2002-01-23 16:23 ` Jean-Pierre Rosen 0 siblings, 0 replies; 31+ messages in thread From: Jean-Pierre Rosen @ 2002-01-23 16:23 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 1257 bytes --] "Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> a �crit dans le message news: > I can see value in trying to create the most flexible interface possible but > I think you'd have to admit that there are some features of OS #1 that are > just simply not going to exist or even make sense under OS #2. In some of > those cases, you might be able to get clever and find a way to keep those > features from compiling under OS #2, but I could still see it as being > particularly attractive to say "Here's a set of features that make sense for > (almost) any operating system under package name X and here are features > that only make sense or are supported by OS #1 under package name X.OS_1, > etc..." That way, you can develop code that is OS independent if you like > *or* take advantage of peculiarities of a particular OS through an interface > you feel comfortable will be there for (almost) any Ada implementation that > targets that particular system. Agreed. And I hope my design allows this. Have a look at it, then I'll be pleased to respond to any "How do I..." you may have. -- --------------------------------------------------------- J-P. Rosen (rosen@adalog.fr) Visit Adalog's web site at http://www.adalog.fr ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Directory listings and path names 2002-01-22 16:36 ` Marin David Condic 2002-01-23 13:47 ` Jean-Pierre Rosen @ 2002-01-23 17:27 ` Mark Biggar 2002-01-23 18:24 ` Marin David Condic 2002-01-23 23:20 ` Nick Roberts 2002-01-25 0:17 ` Brian Rogoff 2 siblings, 2 replies; 31+ messages in thread From: Mark Biggar @ 2002-01-23 17:27 UTC (permalink / raw) Marin David Condic wrote: > On yet another hand, I do agree that it would be a good idea for Ada to > provide a semi-standard interface to an OS file system. It would necessarily > be reduced to the least common denominator, but with child packages, it > would be possible to isolate interfaces for the most common OS's where there > may be non-portable features in question. Could this be part of the ARM? A > better place to start would be with an informal consensus & see if it might > eventually be something that could migrate to a more formal standard. There is already an amendment AI for this. See AI95-00248-01 on http://www.ada-auth.org/AI-SUMMARY.HTML -- Mark Biggar mark.a.biggar@attbi.com ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Directory listings and path names 2002-01-23 17:27 ` Mark Biggar @ 2002-01-23 18:24 ` Marin David Condic 2002-01-23 20:49 ` tmoran 2002-01-23 23:20 ` Nick Roberts 1 sibling, 1 reply; 31+ messages in thread From: Marin David Condic @ 2002-01-23 18:24 UTC (permalink / raw) It looks interesting - although my inspection of it was rather cursory. It seems to center on Windows/Unix which, of course, covers a lot of turf. I'm wondering how well it would fit with more niche-type OS's and/or possible future developments in the field. (Would it fit well with MacOS, for example - or manipulating URLs/URIs?) While a positive thing, it may need some broadening of scope. You get more from an OS than just directories and files & it would be nice to have a common way of getting at some of those services. Like I said, not everything could be standard because there are features that may or may not be supported, so maybe provisions for OS specific packages would still be in order. I could come up with a laundry list.... :-) MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com Web: http://www.mcondic.com/ "Mark Biggar" <mark.a.biggar@attbi.com> wrote in message news:3C4EF2AA.31A78C84@attbi.com... > > There is already an amendment AI for this. See AI95-00248-01 > on http://www.ada-auth.org/AI-SUMMARY.HTML > ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Directory listings and path names 2002-01-23 18:24 ` Marin David Condic @ 2002-01-23 20:49 ` tmoran 2002-01-23 22:02 ` Robert A Duff ` (2 more replies) 0 siblings, 3 replies; 31+ messages in thread From: tmoran @ 2002-01-23 20:49 UTC (permalink / raw) >wondering how well it would fit with more niche-type OS's and/or possible >future developments in the field. (Would it fit well with MacOS, for >example - or manipulating URLs/URIs?) The whole idea of directories and paths presumes a tree structure. URLs are more like unique names, where '/' is just another character. "a.com/b/c*.htm" is not meaningful as a URL (unless of course the server wants to give "b/c*.htm" some meaning). Tree structured directories date from the days of tree structured databases. They will eventually disappear. Then people will want standardized packages to handle URLs and organize related URLs. In the meantime, let's standardize at least the simplest, least common denominator, directory walking routines. IMHO ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Directory listings and path names 2002-01-23 20:49 ` tmoran @ 2002-01-23 22:02 ` Robert A Duff 2002-01-23 22:35 ` Darren New 2002-01-23 23:00 ` Marin David Condic 2 siblings, 0 replies; 31+ messages in thread From: Robert A Duff @ 2002-01-23 22:02 UTC (permalink / raw) tmoran@acm.org writes: >... Tree structured directories > date from the days of tree structured databases. They will eventually > disappear. I hope not! - Bob ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Directory listings and path names 2002-01-23 20:49 ` tmoran 2002-01-23 22:02 ` Robert A Duff @ 2002-01-23 22:35 ` Darren New 2002-01-23 23:00 ` Marin David Condic 2 siblings, 0 replies; 31+ messages in thread From: Darren New @ 2002-01-23 22:35 UTC (permalink / raw) tmoran@acm.org wrote: > The whole idea of directories and paths presumes a tree structure. The only reasonable way to split up a data structure that crosses administrative domain boundaries is via a tree structure. > URLs are more like unique names, where '/' is just another character. Errr, no. URLs are tree structured. > "a.com/b/c*.htm" is not meaningful as a URL (unless of course the server > wants to give "b/c*.htm" some meaning). It is, if you escape the "*". (Of course, you'll have a literal "*" in the URL then.) > Tree structured directories > date from the days of tree structured databases. They will eventually > disappear. I'm not holding my breath. ;-) -- Darren New San Diego, CA, USA (PST). Cryptokeys on demand. The opposite of always is sometimes. The opposite of never is sometimes. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Directory listings and path names 2002-01-23 20:49 ` tmoran 2002-01-23 22:02 ` Robert A Duff 2002-01-23 22:35 ` Darren New @ 2002-01-23 23:00 ` Marin David Condic 2002-01-24 15:03 ` M. A. Alves 2 siblings, 1 reply; 31+ messages in thread From: Marin David Condic @ 2002-01-23 23:00 UTC (permalink / raw) My thinking on URLs is that as a "Uniform Resource Locator" they could be used as a kind of "File System" - directory tree structured or not. Hence, there might be some desire to do things like copying resources, deleting them, etc. I don't know of an OS that specifies its files with URL syntax - but given "The Net" and similar directions in computer software, it seems like something that might come up. I don't object to getting an Ada package that deals only with more traditional tree structured directories or only a few common file systems. What I'm suggesting is that in the process of talking about such a creature that possibly some thought be given to reasonable future needs. If its useful, people will want to expand its capabilities. Obviously, unless Ada develops its own abstraction for a "File System" or a full-blown OS, (something that could be mapped to some/most existing OS's - similar to how Tasking is a kind of abstraction that can be mapped to most OS multitasking facilities) anything it does to connect to such services is going to be rather system dependend and non-portable. Trying to come up with such an abstraction would be a big job. Anything less is still more than we have now, so its not something I'd discourage. MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com Web: http://www.mcondic.com/ <tmoran@acm.org> wrote in message news:flF38.35525$%51.1922466961@newssvr21.news.prodigy.com... > The whole idea of directories and paths presumes a tree structure. > URLs are more like unique names, where '/' is just another character. > "a.com/b/c*.htm" is not meaningful as a URL (unless of course the server > wants to give "b/c*.htm" some meaning). Tree structured directories > date from the days of tree structured databases. They will eventually > disappear. Then people will want standardized packages to handle > URLs and organize related URLs. In the meantime, let's standardize at > least the simplest, least common denominator, directory walking routines. > IMHO ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Directory listings and path names 2002-01-23 23:00 ` Marin David Condic @ 2002-01-24 15:03 ` M. A. Alves 0 siblings, 0 replies; 31+ messages in thread From: M. A. Alves @ 2002-01-24 15:03 UTC (permalink / raw) On Wed, 23 Jan 2002, Marin David Condic wrote: > My thinking on URLs is that as a "Uniform Resource Locator" they could be > used as a kind of "File System" . . . Yes. I have in my "to do" list an examination of the IOS (Internet Operating System) (associated with the REBOL language I think) to see if they have acomplished that. -- , M A R I O data miner, LIACC, room 221 tel 351+226078830, ext 121 A M A D O Rua Campo Alegre, 823 fax 351+226003654 A L V E S P-4150-180 PORTO, Portugal mob 351+939354002 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Directory listings and path names 2002-01-23 17:27 ` Mark Biggar 2002-01-23 18:24 ` Marin David Condic @ 2002-01-23 23:20 ` Nick Roberts 2002-01-25 7:54 ` tgingold 1 sibling, 1 reply; 31+ messages in thread From: Nick Roberts @ 2002-01-23 23:20 UTC (permalink / raw) "Mark Biggar" <mark.a.biggar@attbi.com> wrote in message news:3C4EF2AA.31A78C84@attbi.com... > ... > There is already an amendment AI for this. See AI95-00248-01 > on http://www.ada-auth.org/AI-SUMMARY.HTML The latest version is AI95-00248-04 and this may be updated (e.g. with some of my own suggestions ;-) People reading this thread, do please take a look at this AI, and make any (reasonable) suggestions you may have. The theme of the proposal is to provide a fairly minimal, lowest common denominator, set of operations relating to files and directories. It is certainly intended to be as operating-system independent as possible; however, some weight must surely be given to the predominance of UNIX and MS-DOS/Windows, and the many variants whose file and directory facilities are based upon or similar to them. -- Best wishes, Nick Roberts ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Directory listings and path names 2002-01-23 23:20 ` Nick Roberts @ 2002-01-25 7:54 ` tgingold 2002-01-25 12:55 ` Larry Kilgallen 0 siblings, 1 reply; 31+ messages in thread From: tgingold @ 2002-01-25 7:54 UTC (permalink / raw) In article <a2nh21$125l0q$1@ID-25716.news.dfncis.de>, Nick Roberts wrote: > "Mark Biggar" <mark.a.biggar@attbi.com> wrote in message > news:3C4EF2AA.31A78C84@attbi.com... >> ... >> There is already an amendment AI for this. See AI95-00248-01 >> on http://www.ada-auth.org/AI-SUMMARY.HTML > > The latest version is AI95-00248-04 and this may be updated (e.g. with some > of my own suggestions ;-) People reading this thread, do please take a look > at this AI, and make any (reasonable) suggestions you may have. I don't know where suggestions should be made, but here is mine: function Full_Name (Name : in String) return String; Returns the full name corresponding to the file name specified by Name. [...] Should be *a* full name, since some systems (such as UNIX) doesn't have only one name for a file (links). Therefore, this function cannot be used to canonicalize a file name. Tristan. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Directory listings and path names 2002-01-25 7:54 ` tgingold @ 2002-01-25 12:55 ` Larry Kilgallen 0 siblings, 0 replies; 31+ messages in thread From: Larry Kilgallen @ 2002-01-25 12:55 UTC (permalink / raw) In article <a2r2vk$1mni$1@mo5.fr.ipricot.com>, tgingold@pc204.ipricot.fr writes: > function Full_Name (Name : in String) return String; > Returns the full name corresponding to the file name specified by Name. > [...] > > Should be *a* full name, since some systems (such as UNIX) doesn't have only > one name for a file (links). > Therefore, this function cannot be used to canonicalize a file name. Whereas on VMS there may be multiple full names, equally valid for accessing the file, but one of them is "more equal" and often used for special purposes that require a canonical name. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Directory listings and path names 2002-01-22 16:36 ` Marin David Condic 2002-01-23 13:47 ` Jean-Pierre Rosen 2002-01-23 17:27 ` Mark Biggar @ 2002-01-25 0:17 ` Brian Rogoff 2002-01-25 14:47 ` Marin David Condic 2 siblings, 1 reply; 31+ messages in thread From: Brian Rogoff @ 2002-01-25 0:17 UTC (permalink / raw) On Tue, 22 Jan 2002, Marin David Condic wrote: > Not strictly true. Accessing a file system rather implies that there *is* a > file system and hence something vaguely resembling an OS that accesses it. > Tasking, OTOH, can exist on a bare-silicon platform with nothing more than > some sort of Ada RTK that supports the scheduling. (Unless we want to insist > that anything at least as sophisticated as an Ada RTK can be considered an > "Operating System".) You're just nitpicking. The important point is not whether file system access is provided by the core language but whether it is in the standard. Ada has an Information Systems annex but no hierarchical file systems annex. I think the latter is at least as important as the former. Sure, its easy enough to come up with a package but we all understand the benefit of a standard, don't we. Anyways, I know about the AI and I'm just making noise :-). I usually make noise about things which will sadly never change about Ada. However, this is really low hanging fruit and it is a shame that we don't have it now! -- Brian ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Directory listings and path names 2002-01-25 0:17 ` Brian Rogoff @ 2002-01-25 14:47 ` Marin David Condic 0 siblings, 0 replies; 31+ messages in thread From: Marin David Condic @ 2002-01-25 14:47 UTC (permalink / raw) I agree that it is really low hanging fruit to establish a package spec and declare it to be a de facto standard. Especially for something that doesn't involve a half-million lines of code to implement and can be reasonably supported on most operating systems. There's no reason that it has to even wait for a language revision. It could be viewed this way: If the package spec outlined in the AI for file manipulation is reasonably complete and the various Ada vendors simply started shipping it with their product, then it effectively becomes an informal part of the language. Doing so allows for some experimentation and experience to be built up with it such that when the time comes to include it in a future standard, it will be well understood and reliable. I would go further to say that there are probably a large number of such packages that could be candidates for such an inclusion. And I don't think that they necessarily have to be in an annex of the ARM if the reigning view is that it is too hard to write a formal specification that can be used for validation. A reference implementation might be sufficient so long as it is widely adopted. The point being that the more things that a developer can leverage in building applications, the more useful the language becomes and the easier it is to adopt. If other languages provide libraries of useful stuff and Ada doesn't out of some sense of strict adherence to formal validation, then other languages will get used and Ada will not. Why wait for Ada0X? MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com Web: http://www.mcondic.com/ "Brian Rogoff" <bpr@bpr.best.vwh.net> wrote in message news:Pine.BSF.4.40.0201250010340.88868-100000@bpr.best.vwh.net... > > Anyways, I know about the AI and I'm just making noise :-). I usually make > noise about things which will sadly never change about Ada. However, this > is really low hanging fruit and it is a shame that we don't have it now! > ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Directory listings and path names 2002-01-17 11:21 Directory listings and path names Andreas Valdusson 2002-01-17 13:00 ` M. A. Alves @ 2002-01-18 13:09 ` Joachim Schröer 1 sibling, 0 replies; 31+ messages in thread From: Joachim Schröer @ 2002-01-18 13:09 UTC (permalink / raw) Andreas Valdusson wrote: > If I have the name of a directory, and want ADA to get the names of all > sub-directories of this one, how do I do? > How do I get the contents of a specific directory (ie. the names for all > subdirectories and files) and how do I know which of these that are > sub-directories an which are files? > > /Andreas > > > You may download http://www.adapower.com/schroer/lib-src.zip Look into package portable.operating_system, function all_entries and set the parameters as you like. The package is implemented on top of the Ada posix-binding for win32. In the body some win32 features are called directly. Simply comment them out if you need the function for another OS than win32. Best regards J. Schr�er ^ permalink raw reply [flat|nested] 31+ messages in thread
[parent not found: <Pine.LNX.4.33.0201171247440.8403-100000@lagoa.niaad.liacc.up.pt>]
* Re: Directory listings and path names [not found] <Pine.LNX.4.33.0201171247440.8403-100000@lagoa.niaad.liacc.up.pt> @ 2002-01-17 14:26 ` M. A. Alves 0 siblings, 0 replies; 31+ messages in thread From: M. A. Alves @ 2002-01-17 14:26 UTC (permalink / raw) To: comp.lang.ada On Thu, 17 Jan 2002, M. A. Alves wrote: > . . . GNAT.OS_Lib :-) See also GNAT.Directory_Operations . -- , M A R I O data miner, LIACC, room 221 tel 351+226078830, ext 121 A M A D O Rua Campo Alegre, 823 fax 351+226003654 A L V E S P-4150-180 PORTO, Portugal mob 351+939354002 ^ permalink raw reply [flat|nested] 31+ messages in thread
end of thread, other threads:[~2002-01-25 14:47 UTC | newest] Thread overview: 31+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2002-01-17 11:21 Directory listings and path names Andreas Valdusson 2002-01-17 13:00 ` M. A. Alves 2002-01-18 22:58 ` Brian Rogoff 2002-01-19 3:03 ` Larry Kilgallen 2002-01-19 14:28 ` Robert A Duff 2002-01-19 22:45 ` Brian Rogoff 2002-01-19 23:02 ` Nick Roberts 2002-01-22 14:45 ` Stephen Leake 2002-01-22 16:50 ` Brian Rogoff 2002-01-22 17:03 ` Jean-Marc Bourguet 2002-01-22 17:57 ` tmoran 2002-01-22 18:40 ` Larry Kilgallen 2002-01-19 14:20 ` Georg Bauhaus 2002-01-22 16:36 ` Marin David Condic 2002-01-23 13:47 ` Jean-Pierre Rosen 2002-01-23 14:32 ` Marin David Condic 2002-01-23 16:23 ` Jean-Pierre Rosen 2002-01-23 17:27 ` Mark Biggar 2002-01-23 18:24 ` Marin David Condic 2002-01-23 20:49 ` tmoran 2002-01-23 22:02 ` Robert A Duff 2002-01-23 22:35 ` Darren New 2002-01-23 23:00 ` Marin David Condic 2002-01-24 15:03 ` M. A. Alves 2002-01-23 23:20 ` Nick Roberts 2002-01-25 7:54 ` tgingold 2002-01-25 12:55 ` Larry Kilgallen 2002-01-25 0:17 ` Brian Rogoff 2002-01-25 14:47 ` Marin David Condic 2002-01-18 13:09 ` Joachim Schröer [not found] <Pine.LNX.4.33.0201171247440.8403-100000@lagoa.niaad.liacc.up.pt> 2002-01-17 14:26 ` M. A. Alves
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox