Ada.Directories problems, a summary

Ada.Directories problems, a summary

[Dmitry A. Kazakov]

After experimenting with Ada.Directories I collected the issues I think
must be addressed to make Ada.Directories more usable:

1. Name encoding. Either String versions should be UTF-8 or else replaced
with Wide_Wide_String ones.

2. Name canonization / comparison functions. Presently it is impossible to
compare files by names because the same file may have potentially an
infinite number of names.

3. Fake children "." and ".." should have special File_Kind
(Virtual_Directory_File, for example). Else it is impossible to traverse
the directory tree in a portable way.

4. There should be a variant of Start_Search without the Directory
parameter, in order to enumerate the roots of the file systems. For
example, to find drive letters under Windows, network shares, mount points
etc.

5. The behavior of Exists must be specified for the case of mountable
volumes. Presently GNAT implementation pops a message box under Windows.
This should be outlawed.

6. Is_Mountable / Is_Removable functions should be provided.

7. Version number in addition to Containing_Directory, Base_Name and
Extension. (Files have version numbers under VMS)

Any comments?

P.S. Happy New Year!

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada.Directories problems, a summary

[Ivan Levashew]

Dmitry A. Kazakov wrote:

> After experimenting with Ada.Directories I collected the issues I think
> must be addressed to make Ada.Directories more usable:

Ada RTL isn't enough (and wasn't ever) to do anything serious.

I think a replacement library should be designed, with
OS-specific and fallback (relying on Ada RTL) implementations.

There are many efforts like AdaCL, but I don't know if
any of these were to replace Ada RTL.

Your problems are not the only ones. For example, with Ada and
GNAT RTL, I can't easily:
Read word by word a file,
which is stored in a zip file,
which itself is hosted on an FTP server,
which is being accessed through a SOCKS5 proxy,
which is being accessed through an HTTPS proxy (CONNECT method),
which is being accessed directly.

Every part of Ada RTL and GNAT RTL is locked down to immediate
filesystem/immediate network connectivity.

I can't see any option other than another library.

Re: Ada.Directories problems, a summary

[Dmitry A. Kazakov]

On Thu, 1 Jan 2009 12:16:55 +0100, Dmitry A. Kazakov wrote:

> After experimenting with Ada.Directories I collected the issues I think
> must be addressed to make Ada.Directories more usable:
> 
> 1. Name encoding. Either String versions should be UTF-8 or else replaced
> with Wide_Wide_String ones.
> 
> 2. Name canonization / comparison functions. Presently it is impossible to
> compare files by names because the same file may have potentially an
> infinite number of names.
> 
> 3. Fake children "." and ".." should have special File_Kind
> (Virtual_Directory_File, for example). Else it is impossible to traverse
> the directory tree in a portable way.
> 
> 4. There should be a variant of Start_Search without the Directory
> parameter, in order to enumerate the roots of the file systems. For
> example, to find drive letters under Windows, network shares, mount points
> etc.
> 
> 5. The behavior of Exists must be specified for the case of mountable
> volumes. Presently GNAT implementation pops a message box under Windows.
> This should be outlawed.
> 
> 6. Is_Mountable / Is_Removable functions should be provided.
> 
> 7. Version number in addition to Containing_Directory, Base_Name and
> Extension. (Files have version numbers under VMS)

8. Containing_Directory need to be clarified / refined. RM A.16 76/2 and
A.16 127/2 seem to contradict each other.

The GNAT implementation of Containing_Directory returns for "foo.txt" the
current folder. A.16 127/2, in my understanding, says that the result
should be Name_Error, since as a path "foo.txt" has no any [= including
"containing"] directory specified. As an external file it surely has one.

Ergo, is Containing_Directory a path operation or an operation on the
external file? [Clearly there should be two operations.]

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada.Directories problems, a summary

[Colin Paul Gloster]

On Thu, 1 Jan 2009, Dmitry A. Kazakov wrote:

|--------------------------------------------------------------------------|
|"After experimenting with Ada.Directories I collected the issues I think  |
|must be addressed to make Ada.Directories more usable:                    |
|                                                                          |
|1. Name encoding. Either String versions should be UTF-8 or else replaced |
|with Wide_Wide_String ones.                                               |
|                                                                          |
|[..]                                                                      |
|                                                                          |
|7. Version number in addition to Containing_Directory, Base_Name and      |
|Extension. (Files have version numbers under VMS)"                        |
|--------------------------------------------------------------------------|

Hello,

A different name encoding scheme might suit some other file system
type better, but may be such peculiarities would be better dealt with
libraries specific to those platforms instead of a fairly general
Ada standard.

|--------------------------------------------------------------------------|
|"Any comments?"                                                           |
|--------------------------------------------------------------------------|

Thank you for compiling the list.

|--------------------------------------------------------------------------|
|"P.S. Happy New Year!"                                                    |
|--------------------------------------------------------------------------|

One can hope. Happy new year.

With kind regards,
Colin Paul Gloster

Re: Ada.Directories problems, a summary

[Dmitry A. Kazakov]

On Thu, 1 Jan 2009 05:47:13 -0800 (PST), Ivan Levashew wrote:

> Dmitry A. Kazakov wrote:
> 
>> After experimenting with Ada.Directories I collected the issues I think
>> must be addressed to make Ada.Directories more usable:
> 
> Ada RTL isn't enough (and wasn't ever) to do anything serious.

I hope running Ada programs qualifies as serious. (:-))

> I think a replacement library should be designed, with
> OS-specific and fallback (relying on Ada RTL) implementations.

Nope, Ada RTL must support design of platform-independent applications. Any
OS-specific library has no use in my eyes. I think there is a broad
understanding of this beyond Ada community. As an example consider GTK
introducing GIO library which tries to abstract the I/O OS layer. [GIO does
not work, but that is another story...]

> Your problems are not the only ones. For example, with Ada and
> GNAT RTL, I can't easily:
> Read word by word a file,

I don't see any problem with that. Ada.Streams.Stream_IO should do it.

> which is stored in a zip file,
> which itself is hosted on an FTP server,
> which is being accessed through a SOCKS5 proxy,
> which is being accessed through an HTTPS proxy (CONNECT method),
> which is being accessed directly.

All these are just not files. It is a UNIX-world aberration that everything
must be a file. Everything is nothing.

> Every part of Ada RTL and GNAT RTL is locked down to immediate
> filesystem/immediate network connectivity.

Which is good, because your list has no end. What about CORBA, DB
connections etc?

> I can't see any option other than another library.

The option is to limit it to files. Later on URI schemes could added in a
set of separate packages and so on.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada.Directories problems, a summary

[Dmitry A. Kazakov]

On Thu, 1 Jan 2009 14:05:07 +0000, Colin Paul Gloster wrote:

> A different name encoding scheme might suit some other file system
> type better, but may be such peculiarities would be better dealt with
> libraries specific to those platforms instead of a fairly general
> Ada standard.

But Ada is already Unicode, which incorporates all possible schemes. I
don't see why there should be any platform dependence here. When a file
name is illegal there is already Name_Error exception here.

Applications practically never generate file names from scratch. They
compose them out of existing elements, such as directory path, simple name,
extension, user input. They just do not need to know anything about how
file names get ultimately encoded on the disk.

(Ada.Directories could provide some Character_Set (Wide_Wide_Character)
constants for valid file name characters etc.)

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada.Directories problems, a summary

[anon]

    1. OS problem. Name encoding must match OS and file system that being 
       used. And that may be different between locations or OSs.

    2. OS problem, that all programming languages have to deal with.

    3. No need. The usage is just as easy as using a Alphanumeric 
       directory names. And traversing the directory tree is more portable
       since more current file system use "." and "..". It is also, easy
       to check and skip them while going deeper within a directory tree.
       Note, most file search routines understand how to deal with these 
       two special directories.

    4. Another standards OS problem. Drives are not directories in Windows 
       and DOS. And this includes some embedded OS. Actually most Windows 
       uses wish that MS would replace the DOS drive letters with "/" 
       directory structure because of the internet usage of "/".

    5. Windows and it's apps designs loves Popups. This is a MS problem 
       not Ada or GNAT.

    6. Another OS problem. If a drive is not ready, is it a "drive not mounted"
       or is there a problem with the drive such as a "drive crash".  So, this 
       not useful, in Ada.Directories or any file type package ( Ada.Direct_IO, 
       Ada.Sequential_IO, or Ada.Text_IO ). The drive should be installed and 
       mounted before Ada even tries to access any file or directory routine. 

       Since, most current computers system have CD/DVD and USB ports 
       that allow Flash or external drives. Ada needs an Ada.OS_Library for 
       common and standard routines that can handle mounting or hardware
       problems. In this package, the program could ask if a drive is 
       mounted or is the drive working proper.  Or the program could 
       request for a drive aka CD/DVD to be inserted. Of course this would 
       mean another Windows popup screen.

    7. Not a standard concept in all file systems or OSs and may be phase out
       completely. For some OS, its a security option (allowing duplicate files 
       for simple file backup concept, etc), that should be handled by an 
       Security package. For Windows, the version numbers are used as one 
       way to allow floppies to use long file names under the MS FAT files 
       structure.  But as flash drives (using FS which uses long file names 
       structure) replace floppies so it seams that MS will phase out the use 
       of the version numbers design. Maybe VMS should too.

       So, the only thing that you have stated that may alter Ada is the one 
that causes an Ada.OS_library package. To determine rather a drive is 
mounted or has crashed. And another routine to mount a drive.


In <17rohiaha9ome$.1gz45no0bqro2.dlg@40tude.net>, "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>After experimenting with Ada.Directories I collected the issues I think
>must be addressed to make Ada.Directories more usable:
>
>1. Name encoding. Either String versions should be UTF-8 or else replaced
>with Wide_Wide_String ones.
>
>2. Name canonization / comparison functions. Presently it is impossible to
>compare files by names because the same file may have potentially an
>infinite number of names.
>
>3. Fake children "." and ".." should have special File_Kind
>(Virtual_Directory_File, for example). Else it is impossible to traverse
>the directory tree in a portable way.
>
>4. There should be a variant of Start_Search without the Directory
>parameter, in order to enumerate the roots of the file systems. For
>example, to find drive letters under Windows, network shares, mount points
>etc.
>
>5. The behavior of Exists must be specified for the case of mountable
>volumes. Presently GNAT implementation pops a message box under Windows.
>This should be outlawed.
>
>6. Is_Mountable / Is_Removable functions should be provided.
>
>7. Version number in addition to Containing_Directory, Base_Name and
>Extension. (Files have version numbers under VMS)
>
>Any comments?
>
>P.S. Happy New Year!
>
>-- 
>Regards,
>Dmitry A. Kazakov
>http://www.dmitry-kazakov.de

Re: Ada.Directories problems, a summary

[Georg Bauhaus]

Dmitry A. Kazakov wrote:
> After experimenting with Ada.Directories I collected the issues I think
> must be addressed to make Ada.Directories more usable:
> 
> 1. Name encoding. Either String versions should be UTF-8 or else replaced
> with Wide_Wide_String ones.

Just for clarification, do you want ISO 10646 names to be used
in Ada program texts so that Ada.Directories can map the Ada
string names to file system names? (The file system using whichever
encoding seems fit?)


> 2. Name canonization / comparison functions. Presently it is impossible to
> compare files by names because the same file may have potentially an
> infinite number of names.

I suppose this refers to paths, such as full names, and includes 1.?
(E.g., if the OSs do not make unique ids available to the computer
user (such as i-nodes) it is unlikely that an application program could.
Does Apple have copyright on iNode?)


> 4. There should be a variant of Start_Search without the Directory
> parameter, in order to enumerate the roots of the file systems. For
> example, to find drive letters under Windows, network shares, mount points
> etc.

OTOH, if you know where to start strolling along that file system
grove, you have virtually named a virtual root...

> 5. The behavior of Exists must be specified for the case of mountable
> volumes. Presently GNAT implementation pops a message box under Windows.
> This should be outlawed.

What about "dynamic" behavior? An NFS server going away during
the mount operation, ...
IOW, what is special of this "availability property" when compared
to others such as a file being removed from the file system
after the program has opened the file?


> 7. Version number in addition to Containing_Directory, Base_Name and
> Extension. (Files have version numbers under VMS)

Not widespread.  A Child package maybe, provided by implementations?

Re: Ada.Directories problems, a summary

[Dmitry A. Kazakov]

On Fri, 02 Jan 2009 11:22:10 +0100, Georg Bauhaus wrote:

> Dmitry A. Kazakov wrote:
>> After experimenting with Ada.Directories I collected the issues I think
>> must be addressed to make Ada.Directories more usable:
>> 
>> 1. Name encoding. Either String versions should be UTF-8 or else replaced
>> with Wide_Wide_String ones.
> 
> Just for clarification, do you want ISO 10646 names to be used
> in Ada program texts so that Ada.Directories can map the Ada
> string names to file system names? (The file system using whichever
> encoding seems fit?)

I mean, that you use Unicode names in the program and Ada RTL maps these
names onto the OS scheme.

If the file name contains code points unsupported by OS, you get
Name_Error, as expected. Implementation cost of this is about zero.

>> 2. Name canonization / comparison functions. Presently it is impossible to
>> compare files by names because the same file may have potentially an
>> infinite number of names.
> 
> I suppose this refers to paths, such as full names, and includes 1.?
> (E.g., if the OSs do not make unique ids available to the computer
> user (such as i-nodes) it is unlikely that an application program could.
> Does Apple have copyright on iNode?)

It refers to the issues like:

1. Canonize ("d:/foo.txt") = "D:\Foo.txt"
    -- under Windows where names are case insensitive,
    -- but the case is stored. / is replaced with \ etc.

2. Canonize ("/a/../a/../a") = "/a"  -- removed indirections

>> 4. There should be a variant of Start_Search without the Directory
>> parameter, in order to enumerate the roots of the file systems. For
>> example, to find drive letters under Windows, network shares, mount points
>> etc.
> 
> OTOH, if you know where to start strolling along that file system
> grove, you have virtually named a virtual root...

Right. This is another way to achieve the same effect, by providing a
Directory_Entry_Type constant Root, which would be "/" under UNIX and
something virtual under other systems.

>> 5. The behavior of Exists must be specified for the case of mountable
>> volumes. Presently GNAT implementation pops a message box under Windows.
>> This should be outlawed.
> 
> What about "dynamic" behavior? An NFS server going away during
> the mount operation, ...

This is another issue. GTK for instance provides so-called monitors for
volumes, directories and files. This functionality is beyond
Ada.Directories, IMO.

The issue merely is that Exists must have no side effects beyond the its
result. It might raise Use_Error or Data_Error, but it may not pop up
messages, reboot the computer, send SMS etc.

> IOW, what is special of this "availability property" when compared
> to others such as a file being removed from the file system
> after the program has opened the file?

Nothing special, Exists returns False, end of story.

>> 7. Version number in addition to Containing_Directory, Base_Name and
>> Extension. (Files have version numbers under VMS)
> 
> Not widespread.

It is a more general model which implementation cost is almost zero (in its
simplest form).

Furthermore, think about source code management systems like ClearCase,
Subversion etc. These could be viewed as directory trees with nodes having
version numbers.

> A Child package maybe, provided by implementations?

Bad idea. That would make applications using it non-portable.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada.Directories problems, a summary

[Colin Paul Gloster]

On Thu, 1 Jan 2009, anon wrote:

|-----------------------------------------------------------|
|"       [..]                                               |
|                                                           |
|       [..]                                                |
|       [..] it seams that MS will phase out the use        |
|       of the version numbers design. Maybe VMS should too.|
|                                                           |
|       [..]"                                               |
|-----------------------------------------------------------|

Why should VMS cease to have version numbers?

Regards,
Colin Paul Gloster

Re: Ada.Directories problems, a summary

[Ivan Levashew]

Dmitry A. Kazakov wrote:
>
> > Ada RTL isn't enough (and wasn't ever) to do anything serious.
>
> I hope running Ada programs qualifies as serious. (:-))
>
Serious Ada programs use big amount of non-RTL libraries.

>
> Nope, Ada RTL must support design of platform-independent applications. Any
> OS-specific library has no use in my eyes. I think there is a broad
> understanding of this beyond Ada community.

I was talking about OS-specific implementation. Existence of
fallback implementation makes library 100% portable.

> As an example consider GTK
> introducing GIO library which tries to abstract the I/O OS layer.

Yes, I meant something like this (more precisely, I had NSPR
in mind).

> > Read word by word a file,
>
> I don't see any problem with that. Ada.Streams.Stream_IO should do it.

I was thinking Modula-2's text API vs. Ada's one. Both
are advanced, but I can hardly remember when was the last
time I needed Ada's Page, Set_Line, etc. stuff.

> > which is stored in a zip file,
> > which itself is hosted on an FTP server,
> > which is being accessed through a SOCKS5 proxy,
> > which is being accessed through an HTTPS proxy (CONNECT method),
> > which is being accessed directly.
>
> All these are just not files. It is a UNIX-world aberration that everything
> must be a file. Everything is nothing.
I don't care about UNIX convention. There are abstraction like
"sequence of octets", "ability to establish connection with",
etc., and I'd like to deal with these abstractions and not with
what particular cases OS designers gave me instead.

> > Every part of Ada RTL and GNAT RTL is locked down to immediate
> > filesystem/immediate network connectivity.
>
> Which is good, because your list has no end. What about CORBA, DB
> connections etc?
The point isn't about CORBA and FTP. The point is about
indirection. As soon as one has libraries for FTP/ZIP/SOCKS5,
one should have opportunity to do what I've said.

Currently, Ada RTL is designed in a way that one has to write
text API implementation from scratch.

> The option is to limit it to files.
A programming language of software engineers shouldn't
have stupid limitations like this.

> Later on URI schemes could added in a set of separate
> packages and so on.

URI scheme parser is not a major part. URI is bad for accessing
multivolume archives, cryptography-enabled SFTPs and so on.

Re: Ada.Directories problems, a summary

[Dmitry A. Kazakov]

On Fri, 2 Jan 2009 06:22:14 -0800 (PST), Ivan Levashew wrote:

> Dmitry A. Kazakov wrote:
>>
>> I don't see any problem with that. Ada.Streams.Stream_IO should do it.
> 
> I was thinking Modula-2's text API vs. Ada's one. Both
> are advanced, but I can hardly remember when was the last
> time I needed Ada's Page, Set_Line, etc. stuff.

I don't see your point.
 
>>> which is stored in a zip file,
>>> which itself is hosted on an FTP server,
>>> which is being accessed through a SOCKS5 proxy,
>>> which is being accessed through an HTTPS proxy (CONNECT method),
>>> which is being accessed directly.
>>
>> All these are just not files. It is a UNIX-world aberration that everything
>> must be a file. Everything is nothing.
>
> I don't care about UNIX convention. There are abstraction like
> "sequence of octets", "ability to establish connection with",
> etc., and I'd like to deal with these abstractions and not with
> what particular cases OS designers gave me instead.

But directories have nothing to do with streams of octets. It is
Ada.Streams' business?
 
>>> Every part of Ada RTL and GNAT RTL is locked down to immediate
>>> filesystem/immediate network connectivity.
>>
>> Which is good, because your list has no end. What about CORBA, DB
>> connections etc?

> The point isn't about CORBA and FTP. The point is about
> indirection. As soon as one has libraries for FTP/ZIP/SOCKS5,
> one should have opportunity to do what I've said.

There are millions of libraries. I really don't see your point. Further
there is nothing in common in FTP/ZIP/SOCKS5.

If this is about providing an octet stream interface to everything in the
world, then it is a reincarnation of the old UNIX's stupidity "everyting is
a file."  In software design this sort of stupidity is called abstraction
inversion.

> Currently, Ada RTL is designed in a way that one has to write
> text API implementation from scratch.

I don't know what you understand under "text API implementation."

>> The option is to limit it to files.

> A programming language of software engineers shouldn't
> have stupid limitations like this.

First you said that this were impossible. I don't find stupid limiting
portable Ada.Directories to files. Stupid were to have OS-dependent
interface of. Presently it has, which is a problem.

Ada may have a lot of weaknesses, but it is unbeatable when you need to
write a portable application.
 
>> Later on URI schemes could added in a set of separate
>> packages and so on.
> 
> URI scheme parser is not a major part. URI is bad for accessing
> multivolume archives, cryptography-enabled SFTPs and so on.

Yes, this is what I meant.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada.Directories problems, a summary

[Colin Paul Gloster]

On Fri, 2 Jan 2009, Dmitry A. Kazakov wrote:

|---------------------------------------------|
|"[..]                                        |
|                                             |
|[..] Further                                 |
|there is nothing in common in FTP/ZIP/SOCKS5.|
|                                             |
|[..]"                                        |
|---------------------------------------------|

Data could be obtained from a number of sources, including via FTP or
zipped or tunneling through a firewall with Socks (or from a
compressed file in a zip archive on an SFTP server accessed through
Socks.

You could say that there is nothing in common in a compact disc and a
hard disk and a floppy disk and a Flash stick (which people call a
Flash disk due to habit because disks have been so commonly used for
data storage).

Re: Ada.Directories problems, a summary

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote

> After experimenting with Ada.Directories I collected the issues I think
> must be addressed to make Ada.Directories more usable:

You should send your suggestions to Ada-Comment as a comment on AI05-0049 
(which is about various additions to Ada.Directories). I'm supposed to 
working on that in the next month or so, and I wouldn't mind a discussion on 
it. But not here...it should be done in the context of the AI so it can be 
recorded there.

                                     Randy.

Re: Ada.Directories problems, a summary

[Dmitry A. Kazakov]

On Fri, 2 Jan 2009 22:33:27 +0000, Colin Paul Gloster wrote:

> On Fri, 2 Jan 2009, Dmitry A. Kazakov wrote:
> 
>|---------------------------------------------|
>|"[..]                                        |
>|                                             |
>|[..] Further                                 |
>|there is nothing in common in FTP/ZIP/SOCKS5.|
>|                                             |
>|[..]"                                        |
>|---------------------------------------------|
> 
> Data could be obtained from a number of sources, including via FTP or
> zipped or tunneling through a firewall with Socks (or from a
> compressed file in a zip archive on an SFTP server accessed through
> Socks.

Data sources is vague, because "data" can mean anything. Without behavior
data is nothing. Semantically FTP/ZIP/SOCKS5 and HDD/CD/Flash represent
very different cases.

FTP is a file transfer protocol. ZIP is a content conversion format. SOCKS5
is a tunneling stuff. I don't see a common abstraction for them, unless see
below.

> You could say that there is nothing in common in a compact disc and a
> hard disk and a floppy disk and a Flash stick (which people call a
> Flash disk due to habit because disks have been so commonly used for
> data storage).

All these serve as media to various file systems. The file systems (all)
are abstracted in Ada.Text_IO, Ada.Directories etc.

One could talk about a file system with, say, a ZIP compressed file is a
medium. If the target OS supported this, then Ada.Text_IO, Ada.Directories
would certainly do, for free. But that is not what the Ivan meant.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada.Directories problems, a summary

[Dmitry A. Kazakov]

On Fri, 2 Jan 2009 16:57:07 -0600, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote
> 
>> After experimenting with Ada.Directories I collected the issues I think
>> must be addressed to make Ada.Directories more usable:
> 
> You should send your suggestions to Ada-Comment as a comment on AI05-0049 
> (which is about various additions to Ada.Directories). I'm supposed to 
> working on that in the next month or so, and I wouldn't mind a discussion on 
> it. But not here...it should be done in the context of the AI so it can be 
> recorded there.

I don't have a concrete proposal, it was merely complains than something
constructive. So I wished to hear what other people think about it. At
least to grope after the range of changes felt necessary/desired. For
example, I would like to have different string types for simple name,
directory name, full (absolute) name. There are other general design
issues. Like a clean separation of physical and path/name-only file
operations. Desired? Possible? (in the context of case-insensitive issue
under Windows)

Thank you for the AI number. 

BTW, can Ada-Comment become a news group rather than a mailing list?

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada.Directories problems, a summary

[Jean-Pierre Rosen]

Ivan Levashew a �crit :
> I don't care about UNIX convention. There are abstraction like
> "sequence of octets", "ability to establish connection with",
> etc., and I'd like to deal with these abstractions and not with
> what particular cases OS designers gave me instead.
> 
Believing that a file is a "sequence of octets" is a serious DOS/Unix 
bias. In serious operating systems (i.e. VMS), a file is a higher level, 
structured entity.

-- 
---------------------------------------------------------
            J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: Ada.Directories problems, a summary

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:d6mq43hiz19n$.1x02dgs0h5862$.dlg@40tude.net...
> On Fri, 2 Jan 2009 16:57:07 -0600, Randy Brukardt wrote:
>
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote
>>
>>> After experimenting with Ada.Directories I collected the issues I think
>>> must be addressed to make Ada.Directories more usable:
>>
>> You should send your suggestions to Ada-Comment as a comment on AI05-0049
>> (which is about various additions to Ada.Directories). I'm supposed to
>> working on that in the next month or so, and I wouldn't mind a discussion 
>> on
>> it. But not here...it should be done in the context of the AI so it can 
>> be
>> recorded there.
>
> I don't have a concrete proposal, it was merely complains than something
> constructive. So I wished to hear what other people think about it. At
> least to grope after the range of changes felt necessary/desired. For
> example, I would like to have different string types for simple name,
> directory name, full (absolute) name. There are other general design
> issues. Like a clean separation of physical and path/name-only file
> operations. Desired? Possible? (in the context of case-insensitive issue
> under Windows)

They're already completely separated (the AARM makes this clearer), so I'm 
not quite sure what you mean. The operations on strings are completely 
logical, never physical; they make no use of the machine state (other than 
the name of the current directory). If the wording doesn't make that clear, 
that's probably my fault, but it surely is the intent.

(I would have preferred that those operations were in a totally separate 
package from Ada.Directories, but I lost that argument.)

> Thank you for the AI number.
>
> BTW, can Ada-Comment become a news group rather than a mailing list?

Why would we want to go from one stone-age technology to another? Besides, 
the point of Ada-Comment is to be all-inclusive -- everybody has access to 
e-mail. Access to newsfeeds has been getting harder to come by, and lots of 
people don't have good access (my ISP doesn't offer any, for instance). I 
could see going to some web-based format (perhaps a blog), but that would 
imply a need for more filtering than now, not less (link spammers are a 
major problem for blogs). Not sure what we'd gain other than prettier text.

                                          Randy.

Re: Ada.Directories problems, a summary

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:d6mq43hiz19n$.1x02dgs0h5862$.dlg@40tude.net...
> On Fri, 2 Jan 2009 16:57:07 -0600, Randy Brukardt wrote:
>
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote
>>
>>> After experimenting with Ada.Directories I collected the issues I think
>>> must be addressed to make Ada.Directories more usable:
>>
>> You should send your suggestions to Ada-Comment as a comment on AI05-0049
>> (which is about various additions to Ada.Directories). I'm supposed to
>> working on that in the next month or so, and I wouldn't mind a discussion 
>> on
>> it. But not here...it should be done in the context of the AI so it can 
>> be
>> recorded there.
>
> I don't have a concrete proposal, it was merely complains than something
> constructive. So I wished to hear what other people think about it. At
> least to grope after the range of changes felt necessary/desired. For
> example, I would like to have different string types for simple name,
> directory name, full (absolute) name. There are other general design
> issues. Like a clean separation of physical and path/name-only file
> operations. Desired? Possible? (in the context of case-insensitive issue
> under Windows)

They're already completely separated (the AARM makes this clearer), so I'm 
not quite sure what you mean. The operations on strings are completely 
logical, never physical; they make no use of the machine state (other than 
the name of the current directory). If the wording doesn't make that clear, 
that's probably my fault, but it surely is the intent.

(I would have preferred that those operations were in a totally separate 
package from Ada.Directories, but I lost that argument.)

> Thank you for the AI number.
>
> BTW, can Ada-Comment become a news group rather than a mailing list?

Why would we want to go from one stone-age technology to another? Besides, 
the point of Ada-Comment is to be all-inclusive -- everybody has access to 
e-mail. Access to newsfeeds has been getting harder to come by, and lots of 
people don't have good access (my ISP doesn't offer any, for instance). I 
could see going to some web-based format (perhaps a blog), but that would 
imply a need for more filtering than now, not less (link spammers are a 
major problem for blogs). Not sure what we'd gain other than prettier text.

                                          Randy.

Re: Ada.Directories problems, a summary

[Dmitry A. Kazakov]

On Mon, 5 Jan 2009 19:23:27 -0600, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
> news:d6mq43hiz19n$.1x02dgs0h5862$.dlg@40tude.net...
>> On Fri, 2 Jan 2009 16:57:07 -0600, Randy Brukardt wrote:
>>
>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote
>>>
>>>> After experimenting with Ada.Directories I collected the issues I think
>>>> must be addressed to make Ada.Directories more usable:
>>>
>>> You should send your suggestions to Ada-Comment as a comment on AI05-0049
>>> (which is about various additions to Ada.Directories). I'm supposed to
>>> working on that in the next month or so, and I wouldn't mind a discussion 
>>> on
>>> it. But not here...it should be done in the context of the AI so it can 
>>> be
>>> recorded there.
>>
>> I don't have a concrete proposal, it was merely complains than something
>> constructive. So I wished to hear what other people think about it. At
>> least to grope after the range of changes felt necessary/desired. For
>> example, I would like to have different string types for simple name,
>> directory name, full (absolute) name. There are other general design
>> issues. Like a clean separation of physical and path/name-only file
>> operations. Desired? Possible? (in the context of case-insensitive issue
>> under Windows)
> 
> They're already completely separated (the AARM makes this clearer), so I'm 
> not quite sure what you mean. The operations on strings are completely 
> logical, never physical; they make no use of the machine state (other than 
> the name of the current directory). If the wording doesn't make that clear, 
> that's probably my fault, but it surely is the intent.

I see. Never read RM, do AARM! (:-))

(The problem with Containing_Directory is when there is no containing
directory in the path (relative name) AARM instructs to return ".". This is
non-portable.)

But what about different types? It is really not an Ada style to mix
everything into one type. With different types the controversies absolute
vs. relative, partial vs. full names could be easier to solve. Ugly Compose
could become a set of "&" functions, etc.

Open, Create etc operations in other packets would have overloaded
counterparts with absolute and relative file names, but this is not a big
deal. And one should do this anyway, because the name encoding issue must
be solved.

> (I would have preferred that those operations were in a totally separate 
> package from Ada.Directories, but I lost that argument.)

Yes, Ada.Directories is a too large.

>> Thank you for the AI number.
>>
>> BTW, can Ada-Comment become a news group rather than a mailing list?
> 
> Why would we want to go from one stone-age technology to another?

Bronze-age was the best time. (:-))

News group is IMO superior to the modish "iron-age" wiki. It is
irreversible, supports treaded views and reasonable search.

> Besides, 
> the point of Ada-Comment is to be all-inclusive -- everybody has access to 
> e-mail. Access to newsfeeds has been getting harder to come by, and lots of 
> people don't have good access (my ISP doesn't offer any, for instance). I 
> could see going to some web-based format (perhaps a blog), but that would 
> imply a need for more filtering than now, not less (link spammers are a 
> major problem for blogs). Not sure what we'd gain other than prettier text.

A news server with a web interface under http://www.adaic.org/?

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de