What about a glob standard method in Ada.Command_Line ?

What about a glob standard method in Ada.Command_Line ?

[Yannick Duchêne (Hibou57)]

Hello all,

What about suggesting for Ada 2012, a Glob method as part of the standard  
Ada.Command_Line package ?

Re: What about a glob standard method in Ada.Command_Line ?

[J-P. Rosen]

Le 21/08/2010 06:47, Yannick Duchï¿œne (Hibou57) a ï¿œcrit :
> Hello all,
> 
> What about suggesting for Ada 2012, a Glob method as part of the
> standard Ada.Command_Line package ?
1) It's far too late. You can propose anything you want for Ada 2022.

2) Make a good proposal, and make sure it is compiler independent,
system independent, powerful and easy to use. Then propose it to the
ARG, and the ARG will tell you why it doesn't work ;-)

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

Re: What about a glob standard method in Ada.Command_Line ?

[Yannick Duchêne (Hibou57)]

Le Sat, 21 Aug 2010 08:41:54 +0200, J-P. Rosen <rosen@adalog.fr> a écrit:
> 2) Make a good proposal, and make sure it is compiler independent,
> system independent, powerful and easy to use. Then propose it to the
> ARG, and the ARG will tell you why it doesn't work ;-)
OK, I see, this would not be enough system independent, you are right.
I had some kind of typical usage in mind when I wrote this (though this  
may help Ada to look more attractive), and I forget about other targets  
(just at that time).

Re: What about a glob standard method in Ada.Command_Line ?

[Pascal Obry]

Jean-Pierre,

> 2) Make a good proposal, and make sure it is compiler independent,
> system independent, powerful and easy to use. Then propose it to the
> ARG, and the ARG will tell you why it doesn't work ;-)

I see the argument but there is already some APIs that cannot be
implemented in some OS (like Ada.Execution_Time.Timers on Win32 for
example). That's not a reason to dismiss it. A glob support for
Command_Line (in a child package) would be most welcomed even if not
supported (or supported but with some slight differences) on some OS I
would say.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|    http://www.obry.net  -  http://v2p.fr.eu.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver keys.gnupg.net --recv-key F949BD3B

Re: What about a glob standard method in Ada.Command_Line ?

[J-P. Rosen]

Le 21/08/2010 11:11, Pascal Obry a ï¿œcrit :
> 
> Jean-Pierre,
> 
>> 2) Make a good proposal, and make sure it is compiler independent,
>> system independent, powerful and easy to use. Then propose it to the
>> ARG, and the ARG will tell you why it doesn't work ;-)
> 
> I see the argument but there is already some APIs that cannot be
> implemented in some OS (like Ada.Execution_Time.Timers on Win32 for
> example). That's not a reason to dismiss it. A glob support for
> Command_Line (in a child package) would be most welcomed even if not
> supported (or supported but with some slight differences) on some OS I
> would say.
> 
Sure. And the whole history of Ada is full of stuff where we first said
it was not possible to define in a system independent manner, and later
we changed our mind on the name of usability. Command_Line was dismissed
for Ada 83 and provided in Ada 95. Directory_Operations was dismissed in
Ada 95 and introduced in Ada 2005.

However, it IS too late for Ada 2012, and I'm serious when I say please
propose it; a good proposal is never lost, but it may be harder than you
think.
-- 
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: What about a glob standard method in Ada.Command_Line ?

[Yannick Duchêne (Hibou57)]

Le Sun, 22 Aug 2010 21:00:02 +0200, J-P. Rosen <rosen@adalog.fr> a écrit:
> However, it IS too late for Ada 2012, and I'm serious when I say please
> propose it; a good proposal is never lost, but it may be harder than you
> think.
OK, and sorry to have missunderstand

Re: What about a glob standard method in Ada.Command_Line ?

[Yannick Duchêne (Hibou57)]

Le Sat, 21 Aug 2010 11:11:39 +0200, Pascal Obry <pascal@obry.net> a écrit:
> I see the argument but there is already some APIs that cannot be
> implemented in some OS (like Ada.Execution_Time.Timers on Win32 for
> example).
Will have to check about what Ada.Execution_Time.Timers is exactly,  
because I know there is a timer provided in the Windows API, and for long.

Re: What about a glob standard method in Ada.Command_Line ?

[Dmitry A. Kazakov]

On Sun, 22 Aug 2010 21:30:35 +0200, Yannick Duch�ne (Hibou57) wrote:

> Le Sat, 21 Aug 2010 11:11:39 +0200, Pascal Obry <pascal@obry.net> a �crit:
>> I see the argument but there is already some APIs that cannot be
>> implemented in some OS (like Ada.Execution_Time.Timers on Win32 for
>> example).
> Will have to check about what Ada.Execution_Time.Timers is exactly,  
> because I know there is a timer provided in the Windows API, and for long.

Under Windows there is no way to reliable determine the time a thread owned
CPU. Using existing APIs you can count quants, not the time. The problem is
that when the thread releases processor before it consumed the whole quant,
e.g. by entering non-busy waiting, the pending quant is not counted.
Theoretically you could have 99% CPU usage with 0% indicated in the task
manager.

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

Re: What about a glob standard method in Ada.Command_Line ?

[Randy Brukardt]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 482 bytes --]

"J-P. Rosen" <rosen@adalog.fr> wrote in message 
news:i4rs3k$t6v$1@news.eternal-september.org...
> Le 21/08/2010 11:11, Pascal Obry a �crit :
...
> However, it IS too late for Ada 2012, and I'm serious when I say please
> propose it; a good proposal is never lost, but it may be harder than you
> think.

It would surely help to have some idea of what a "glob" is! And explained in 
some way which is not specific to any particular OS.

                                Randy.

Re: What about a glob standard method in Ada.Command_Line ?

[Yannick Duchêne (Hibou57)]

Le Tue, 24 Aug 2010 01:06:37 +0200, Randy Brukardt <randy@rrsoftware.com>  
a écrit:
> It would surely help to have some idea of what a "glob" is! And  
> explained in
> some way which is not specific to any particular OS.
The old one inherited from first UNIX and which while old is still part of  
many core libraries (C, Python, Eiffel, Pascal, etc) and one of the most  
commonly used to handle command-line parameters, the one which as an  
example, from a "/directory/*.adb" returns an array of strings for all the  
files matching the pattern.

This could be implemented based on the directories package, so provided  
for platforms where this package is available. If there is no trouble to  
keep Ada.Directories, there should be no matter to have a glob method. It  
is at least as much platform independent as Ada.Directories is, as it can  
be based on it.

I though about it while I was reading something about its little variants,  
and in the while though “this is so commonly used, and this is not in Ada  
standard methods, this may make Ada look a bit more friendly to people who  
do not know it if it was there”.

Here is the story. Not a critical item, just a possibly appealing item.

-- 
* 3 lines of concise statements is readable, 10 pages of concise  
statements is unreadable ;
* 3 lines of verbose statements may looks unuseful, 10 pages of verbose  
statements will never looks too much pedantic

Re: What about a glob standard method in Ada.Command_Line ?

[Adam Beneschan]

On Aug 23, 5:02 pm, Yannick Duchêne (Hibou57)
<yannick_duch...@yahoo.fr> wrote:
> Le Tue, 24 Aug 2010 01:06:37 +0200, Randy Brukardt <ra...@rrsoftware.com>  
> a écrit:> It would surely help to have some idea of what a "glob" is! And  
> > explained in
> > some way which is not specific to any particular OS.
>
> The old one inherited from first UNIX and which while old is still part of  
> many core libraries (C, Python, Eiffel, Pascal, etc) and one of the most  
> commonly used to handle command-line parameters, the one which as an  
> example, from a "/directory/*.adb" returns an array of strings for all the  
> files matching the pattern.

Although a function like that would perhaps be useful, it would
definitely not belong in Ada.Command_Line or a child.  Some child of
Ada.Directories would be a much better place.

By the way, I was just as befuddled as Randy about the meaning of
"glob" even though I've done lots of work with Unix and C.  The shell
expands stuff on the command line, so I've never had any desire to use
the program or library function that does this.  I thought "glob"
meant a typical C program that is so impenetrable that it looks more
like a glob of random characters than like actual instructions for a
computer...... :)

                            -- Adam

Re: What about a glob standard method in Ada.Command_Line ?

[Georg Bauhaus]

On 24.08.10 02:24, Adam Beneschan wrote:

> By the way, I was just as befuddled as Randy about the meaning of
> "glob" even though I've done lots of work with Unix and C.  The shell
> expands stuff on the command line, so I've never had any desire to use
> the program or library function that does this. 

"Globbing" can turn out to be wishful thinking, anyway, when
for example, directories are prohibitively large; a generally
usable program will have sequential directory scanning.

Maybe the following change can lift Directories.Start_Search
from implementation defined to standard?  Assuming a simplified
Ada style RE package based on Strings.Maps etc., and a Pattern_Type:

procedure Start_Search
  (Search    : in out Search_Type;
   Directory : in String;
   Matcher   : access function (Pattern : Pattern_Type) return Boolean;
   Filter    : in Filter_Type := (others => True));


Georg

Re: What about a glob standard method in Ada.Command_Line ?

[Dmitry A. Kazakov]

On Tue, 24 Aug 2010 12:27:01 +0200, Georg Bauhaus wrote:

> Maybe the following change can lift Directories.Start_Search
> from implementation defined to standard?  Assuming a simplified
> Ada style RE package based on Strings.Maps etc., and a Pattern_Type:
> 
> procedure Start_Search
>   (Search    : in out Search_Type;
>    Directory : in String;
>    Matcher   : access function (Pattern : Pattern_Type) return Boolean;
>    Filter    : in Filter_Type := (others => True));

You just do not need patterns in directory search. The first reason is that
the underlying  OS does not support that arbitrary stuff anyway. Another,
more important reason is that real-life search would use filters based many
criteria, e.g. content, and patterns beyond the scope of RE, especially
when neither the name encoding nor case-sensitivity specified.

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

Re: What about a glob standard method in Ada.Command_Line ?

[Georg Bauhaus]

On 24.08.10 16:24, Dmitry A. Kazakov wrote:
> On Tue, 24 Aug 2010 12:27:01 +0200, Georg Bauhaus wrote:
>>
>> procedure Start_Search
>>   (Search    : in out Search_Type;
>>    Directory : in String;
>>    Matcher   : access function (Pattern : Pattern_Type) return Boolean;
>>    Filter    : in Filter_Type := (others => True));
>>
> You just do not need patterns in directory search. The first reason is that
> the underlying  OS does not support that arbitrary stuff anyway.

It is my program that matches file names against a pattern, not the OS.

The alternative Directories.Start_Search above does not need to known about
pattern matching.  The Boolean result of Matcher is all that
matters. It matters only after the OS has supplied a String and after
Matcher has run with that string (the file name) and Pattern as input.

> Another,
> more important reason is that real-life search would use filters based many
> criteria, e.g. content, and patterns beyond the scope of RE, especially
> when neither the name encoding nor case-sensitivity specified.

To me, directory search based on file content ("second order search")
seems rather unusual as a first step.  At least in my real world.
Do we have usage data?

Case-(in)sensitivity is easily handled by text pattern matching,
with existing Ada.


Georg

Re: What about a glob standard method in Ada.Command_Line ?

[Dmitry A. Kazakov]

On Tue, 24 Aug 2010 17:42:17 +0200, Georg Bauhaus wrote:

> On 24.08.10 16:24, Dmitry A. Kazakov wrote:
>> On Tue, 24 Aug 2010 12:27:01 +0200, Georg Bauhaus wrote:
>>>
>>> procedure Start_Search
>>>   (Search    : in out Search_Type;
>>>    Directory : in String;
>>>    Matcher   : access function (Pattern : Pattern_Type) return Boolean;
>>>    Filter    : in Filter_Type := (others => True));
>>>
>> You just do not need patterns in directory search. The first reason is that
>> the underlying  OS does not support that arbitrary stuff anyway.
> 
> It is my program that matches file names against a pattern, not the OS.

Right, this is why an argument to efficiency would be invalid. You filter
entries as you wish, no pattern or filter is needed as you get all entries
anyway. Do with them what you want.

>> Another,
>> more important reason is that real-life search would use filters based many
>> criteria, e.g. content, and patterns beyond the scope of RE, especially
>> when neither the name encoding nor case-sensitivity specified.
> 
> To me, directory search based on file content ("second order search")
> seems rather unusual as a first step.

Surely it is. Don't you look for text files, ada source files etc? Those
are called *content type*. Whether the content type is reflected by the
file path and in which form is OS-dependent. Patterns cannot work here.

> Case-(in)sensitivity is easily handled by text pattern matching,
> with existing Ada.

It cannot be handled. You don't even know if two file names are equivalent
using Ada.Directories, how then do you want to do this with pattern
matching? That is OS-dependent.

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

Re: What about a glob standard method in Ada.Command_Line ?

[Georg Bauhaus]

On 24.08.10 18:04, Dmitry A. Kazakov wrote:
> On Tue, 24 Aug 2010 17:42:17 +0200, Georg Bauhaus wrote:
> 
>> On 24.08.10 16:24, Dmitry A. Kazakov wrote:
>>> On Tue, 24 Aug 2010 12:27:01 +0200, Georg Bauhaus wrote:
>>>>
>>>> procedure Start_Search
>>>>   (Search    : in out Search_Type;
>>>>    Directory : in String;
>>>>    Matcher   : access function (Pattern : Pattern_Type) return Boolean;
>>>>    Filter    : in Filter_Type := (others => True));
>>>>
>>> You just do not need patterns in directory search. The first reason is that
>>> the underlying  OS does not support that arbitrary stuff anyway.
>>
>> It is my program that matches file names against a pattern, not the OS.
> 
> Right, this is why an argument to efficiency would be invalid.

Efficiency of glob is unpredictable.  Linear scans of a directory
are slightly different in this regard [*].
And yes, both the Pattern parameter in current Directories.Start_Search,
or Matcher above could really be dropped. Not much will be lost, if
selecting file names can be performed later.


>> To me, directory search based on file content ("second order search")
>> seems rather unusual as a first step.
> 
> Surely it is. Don't you look for text files, ada source files etc? 

No. I look at file names when I scan a directory.


> Those
> are called *content type*. Whether the content type is reflected by the
> file path and in which form is OS-dependent.

Is there an OS that reflects a file's content in its path?


> Patterns cannot work here.

Patterns are intended for names, not content.

(It is odd that most contemporary file systems and archive formats
support extended attributes, but still everyone will keep using files
as if fopen() is the only means of finding information about a file...)


>> Case-(in)sensitivity is easily handled by text pattern matching,
>> with existing Ada.
> 
> It cannot be handled.

Sure can, for file names.
But whether the names "Readme" and "README" refer to two different
files in a directory is another matter, just like the file
"Frodo.txt" may refer to the same file as "README" and "Readme",
in Unix file systems, NTFS, and others that support inodes with
multiple links.

Directories.Start_Search is not about files, I think.
It is about file names (of certain directory entries).


Georg

Re: What about a glob standard method in Ada.Command_Line ?

[Georg Bauhaus]

On 24.08.10 19:10, Georg Bauhaus wrote:

> Efficiency of glob is unpredictable.  Linear scans of a directory
> are slightly different in this regard [*].

I meant (forgetting the footnote, sorry):

ls *.foo

may just not work, since glob may hit a memory limit when building the
list of filenames.  On the other hand,

ls | while read filename
  do
    case $filename in
      *.foo)
        ...;;

does not have this problem.

Re: What about a glob standard method in Ada.Command_Line ?

[Dmitry A. Kazakov]

On Tue, 24 Aug 2010 19:10:14 +0200, Georg Bauhaus wrote:

> On 24.08.10 18:04, Dmitry A. Kazakov wrote:
>> On Tue, 24 Aug 2010 17:42:17 +0200, Georg Bauhaus wrote:
>> 
>>> To me, directory search based on file content ("second order search")
>>> seems rather unusual as a first step.
>> 
>> Surely it is. Don't you look for text files, ada source files etc? 
> 
> No. I look at file names when I scan a directory.

Really? What for anybody would scan directories? I would say that almost
any file search is content-type based, e.g. "ls *.ads". Specific names and
time stamps are not so frequent and almost always intermixed with a content
type constraint.

>> Those
>> are called *content type*. Whether the content type is reflected by the
>> file path and in which form is OS-dependent.
> 
> Is there an OS that reflects a file's content in its path?

MS-DOS, Windows, VMS, RSX-11

>>> Case-(in)sensitivity is easily handled by text pattern matching,
>>> with existing Ada.
>> 
>> It cannot be handled.
> 
> Sure can, for file names.
> But whether the names "Readme" and "README" refer to two different
> files in a directory is another matter, just like the file
> "Frodo.txt" may refer to the same file as "README" and "Readme",
> in Unix file systems, NTFS, and others that support inodes with
> multiple links.

Does the wildcard pattern "R*" match "readme"? Does it match "R�cken", when
� is (16#c3#, 16#bc#) (UTF-8)?

To make patterns work you have to abstract file paths in an OS-independent
way and then define patterns over that abstraction. Naive string patterns
will never work.

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

Re: What about a glob standard method in Ada.Command_Line ?

[Yannick Duchêne (Hibou57)]

Le Tue, 24 Aug 2010 19:24:41 +0200, Georg Bauhaus  
<rm.dash-bauhaus@futureapps.de> a écrit:
> I meant (forgetting the footnote, sorry):
>
> ls *.foo
>
> may just not work, since glob may hit a memory limit when building the
> list of filenames.  On the other hand,
>
> ls | while read filename
>   do
>     case $filename in
>       *.foo)
>         ...;;
>
> does not have this problem.
I understand that point, theoretically, not practically. Reaching memory  
limit would typically requires millions of match. This may occur in  
theory, less in practice (where you will have at most a thousand... and  
this would be not so common).

I though this was a good idea, but do not feel it is worth the reactions  
it produced, so I suggest to just forget it (unless someone feel the  
layout of Ada.Command_Line may be part of the good first feeling some new  
comers may have about Ada).


-- 
* 3 lines of concise statements is readable, 10 pages of concise  
statements is unreadable ;
* 3 lines of verbose statements may looks unuseful, 10 pages of verbose  
statements will never looks too much pedantic

Re: What about a glob standard method in Ada.Command_Line ?

[Simon Wright]

"Yannick Duchêne (Hibou57)" <yannick_duchene@yahoo.fr> writes:

> Le Tue, 24 Aug 2010 19:24:41 +0200, Georg Bauhaus
> <rm.dash-bauhaus@futureapps.de> a écrit:
>> I meant (forgetting the footnote, sorry):
>>
>> ls *.foo
>>
>> may just not work, since glob may hit a memory limit when building the
>> list of filenames.  On the other hand,
>>
>> ls | while read filename
>>   do
>>     case $filename in
>>       *.foo)
>>         ...;;
>>
>> does not have this problem.
> I understand that point, theoretically, not practically. Reaching
> memory limit would typically requires millions of match. This may
> occur in  theory, less in practice (where you will have at most a
> thousand... and  this would be not so common).

I'm pretty sure that bash has a limit on the length of a command line
which is different between Linux & Windows; I had a tool that was quite
happy with *.ad? on Linux but to make it portable I had to use a 'find'
approach, because the Windows (Cygwin) limit was considerably
smaller. This was actually a better solution anyway ...

Re: What about a glob standard method in Ada.Command_Line ?

[Georg Bauhaus]

Dmitry A. Kazakov wrote:

>> Is there an OS that reflects a file's content in its path?
> 
> MS-DOS, Windows, VMS, RSX-11

(These purport to reflect the file's content in the file name
(which by habitual formalism is also a path...),
but they don't.  Just open a file named README.DOC and be
surprised that it is plain text.  Open a file ending in .AVI
and see if this gets you anywhere.  File name extensions as
file content descriptors are technically obsolete but they are
still sold as important because some MS heads think
it gives them best returns, people are used to them, everyone
can profit from what programmers find useful, they are simple,
etc.)

This is getting OT...

When you have a GNAT installation with default naming
scheme for compilation units, finding child units is
as simple as matching a regular expression---on some
systems.  When RE matching supports grouping, the possibilities
further exceed those of "content type" indicating filename
extensions.  When your log files include an ISO calendar
date in filenames, find all log files of last week without
looking at one single line in it...

This name based processing is useful in real cases,
is isn't fully portable to 8.3 filesystems, still useful,
and most flexibly handled with REs matching filenames.



> Does the wildcard pattern "R*"

In what RE syntax?  Does it have to be another syntax
embedded in String or can we do better?  GNAT's SPITBOL
demonstrates: Integrate Strings.Maps etc. with the type
system and establish a well defined pattern type.


 > match "readme"? Does it match "R�cken", when
> � is (16#c3#, 16#bc#) (UTF-8)?

When the Pattern_Type is properly defined, there are no questions.


> Naive string patterns will never work.

Simple filename patterns do work, now, unless you want them to
replace operating systems, application configuration, program
porting, adapting a program to a given environment, etc...



Georg

Re: What about a glob standard method in Ada.Command_Line ?

[Dmitry A. Kazakov]

On Tue, 24 Aug 2010 23:32:15 +0200, Georg Bauhaus wrote:

> Dmitry A. Kazakov wrote:
> 
>>> Is there an OS that reflects a file's content in its path?
>> 
>> MS-DOS, Windows, VMS, RSX-11
> 
> (These purport to reflect the file's content in the file name
> (which by habitual formalism is also a path...),
> but they don't.  Just open a file named README.DOC and be
> surprised that it is plain text.

Weakly typed is what this means. Nevertheless it is the path which is
supposed to identify the content type.

> Open a file ending in .AVI
> and see if this gets you anywhere.  File name extensions as
> file content descriptors are technically obsolete but they are
> still sold as important because some MS heads think
> it gives them best returns, people are used to them, everyone
> can profit from what programmers find useful, they are simple,
> etc.)

They are not obsolete, in fact they won against Unix's flabby and
disordered attempts to offer anything useful instead. The problem is that
they are not enforced, so weak typing: you think it is a document?
Surprise, surprise! Another problem is that there should be no files at all
and how should look like the naming scheme in an OO OS, nobody cares. 

>> Does the wildcard pattern "R*"
> 
> In what RE syntax?

It is a wildcard pattern. Wildcards is the most frequently used pattern
language.

* matches any, maybe empty, sequence of characters. Sometimes ? or % is
introduced, to mach exactly one character. 

>  > match "readme"? Does it match "R�cken", when
>> � is (16#c3#, 16#bc#) (UTF-8)?
> 
> When the Pattern_Type is properly defined, there are no questions.

How do define it properly? Does it match Latin-1's �, UTF-8's �, UTF-16's
�, UTF-32's �? Don't you get that it cannot be done without abstracting
*encoding* away?

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

Re: What about a glob standard method in Ada.Command_Line ?

[Yannick Duchêne (Hibou57)]

Le Wed, 25 Aug 2010 09:55:14 +0200, Dmitry A. Kazakov  
<mailbox@dmitry-kazakov.de> a écrit:
> They are not obsolete, in fact they won against Unix's flabby and
> disordered attempts to offer anything useful instead.
Mac OS used to have a good technique to tag files types and applications  
to be used to open it, via meta-data... unfortunately, it drop it with OS  
X to follow DOS/Windows convention (many users was disappointed, but Apple  
did not care).


-- 
* 3 lines of concise statements is readable, 10 pages of concise  
statements is unreadable ;
* 3 lines of verbose statements may looks unuseful, 10 pages of verbose  
statements will never looks too much pedantic

Re: What about a glob standard method in Ada.Command_Line ?

[Georg Bauhaus]

On 8/25/10 9:55 AM, Dmitry A. Kazakov wrote:

>>> Does the wildcard pattern "R*"
>>
>> In what RE syntax?
>
> It is a wildcard pattern. Wildcards is the most frequently used pattern
> language.

Does "wildcard" include both Latin-xyz character � and UTF-8 �?
Yes.  Many Wildcards do. And it can be handled.

See whether or not encoding matters in the following program.



with GNAT.SPITBOL.Patterns;  use GNAT.SPITBOL.Patterns;
with Ada.Characters.Latin_1;  use Ada.Characters.Latin_1;

procedure Find_Ruecken (Text : String; Result : VString_Var) is
    In_UTF_8 : constant String := (Character'Val(16#c3#),
                                   Character'Val(16#bc#));
    Ue : Pattern;
begin
    Ue :=  (Any("Rr") & (In_UTF_8 or LC_U_Diaeresis) & "cken") ** Result;

    if not Match (Text, Ue) then
       raise Constraint_Error;
    end if;
end Find_Ruecken;

with GNAT.SPITBOL;  use GNAT.SPITBOL;
with Ada.Text_IO;
with Find_Ruecken;

procedure Test_Find_Ruecken is
    Found : VString;
begin
    Find_Ruecken(Text => "Recken, die R�cken ohne R�ckgrat dr�cken",
                 Result => Found);
    Ada.Text_IO.Put_Line ("Found """ & S(Found) & '"');
end Test_Find_Ruecken;


>>   >  match "readme"? Does it match "R�cken", when
>>> � is (16#c3#, 16#bc#) (UTF-8)?
>>
>> When the Pattern_Type is properly defined, there are no questions.
>
> How do define it properly? Does it match Latin-1's �, UTF-8's �, UTF-16's
> �, UTF-32's �? Don't you get that it cannot be done without abstracting
> *encoding* away?

When the Pattern_Type is properly defined, there are no questions.

Since I have to process a lot of text file and text streams
of unknown encoding, I'm used to REs that just find "R�cken"
in whatever encoding.  That's called programming.  Think of Google
or Yahoo or Bing searching the WWW and tons of email ...

There is no such thing as clean external data.
That  including file names.


Georg

Re: What about a glob standard method in Ada.Command_Line ?

[Dmitry A. Kazakov]

On Wed, 25 Aug 2010 10:57:45 +0200, Georg Bauhaus wrote:

> Does "wildcard" include both Latin-xyz character � and UTF-8 �?

Wildcard * matches ANY SEQUENCE OF CODE POINTS.

> Yes.  Many Wildcards do. And it can be handled.

Wrong, it cannot be implemented to work on both Latin-1 and UTF-8.

As a simple example consider the pattern

   a*�

and the string of octets

   61 C3 B6

Does the pattern match this string?

Hint:

   61 C3 B6 = aö    (in Latin-1)
   61 C3 B6 = a�      (in UTF-8)

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

Re: What about a glob standard method in Ada.Command_Line ?

[Georg Bauhaus]

On 25.08.10 11:28, Dmitry A. Kazakov wrote:
> On Wed, 25 Aug 2010 10:57:45 +0200, Georg Bauhaus wrote:
> 
>> Does "wildcard" include both Latin-xyz character ü and UTF-8 ü?
> 
> Wildcard * matches ANY SEQUENCE OF CODE POINTS.

Wildcard has no universal definition, I keep asking
for one.  ISO/IEC 8652 certainly deserves one.

Is * greedy, does it respect locale, ... But more importantly,
is a particular wildcard the crucial part at all?  No.  Again,
when the Pattern_Type is properly defined, there are no questions.

>> Yes.  Many Wildcards do. And it can be handled.
> 
> Wrong, it cannot be implemented to work on both Latin-1 and UTF-8.

Not wrong, insofar as R* typically matches anything that starts
with R which is what you asked for.  Define sets of strings:

- s ∈ S1 where s has a unique representation in any possible
 encoding (based on octets, e.g.)

- s ∈ S2 where s has a unique representation in some encoding
 to be determined by context

S1 is typically empty only if one mentions EBCDI or silly
"GIF text". (When once I had to extract numbers and names from
raw videotext, a simple RE has still been the tool of choice...)

If you now want R* to decide the encoding of:

>    61 C3 B6 = aö    (in Latin-1)
>    61 C3 B6 = aö      (in UTF-8)

then use programming, use context information with S2, or else approach
your customers with the suggestion that you can't solve the problem
because the external environment is not as ideal as it should be...
I don't think a computing device can establish an oracle?
But none is needed!

If the external environment does not specify encoding, and
your algorithm cannot work without encoding then only
normative ontology can add one. So try, add an encoding.

You can write an RE that matches in the following order:

   61 F6	-- aö in Latin-1
   61 C3 B6	-- aö in UTF-8

This is what is needed, not deciding the encoding of 61 C3 B6
without encoding.  Suppose I know the file name has a substring "Rücken".
Therefore I look for strings that have in them one string from
the set of substrings all of which can establish "Rücken" in
some expected encoding. Then I inspect the findings to see whether
one is good.
Done.

Georg

Re: What about a glob standard method in Ada.Command_Line ?

[Dmitry A. Kazakov]

On Wed, 25 Aug 2010 13:09:41 +0200, Georg Bauhaus wrote:

> If you now want R* to decide the encoding of:

No, I want match this:

   a*¶

This pattern precisely defines a language L:

   http://en.wikipedia.org/wiki/Formal_language

The alphabet Σ of L is the set of code points:

   http://en.wikipedia.org/wiki/Code_point

L = aΣ*¶

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

Re: What about a glob standard method in Ada.Command_Line ?

[Georg Bauhaus]

On 25.08.10 14:01, Dmitry A. Kazakov wrote:
> On Wed, 25 Aug 2010 13:09:41 +0200, Georg Bauhaus wrote:
> 
>> If you now want R* to decide the encoding of:
> 
> No, I want match this:
> 
>    a*¶

Fine, just do it using String; every component of a String
is well defined. Code points have nothing to do with Strings.
Let me try this in Kleene terms, with hypothetical wildcard
meaning (which I think you still have not specified explicitly):

Start with the (terminal) symbol a.
Continue with any number of (terminal) symbols
 drawn from Σ (which includes a and ¶, but not *).
End with the terminal symbol ¶.

> This pattern precisely defines a language L:

It does no such thing absent a definition of *.

The important question is what constitues Σ, not L.
If we use String, used in Directories.Start_Search,
then everything, including Σ, is well defined in Ada,
as is.


Georg

Re: What about a glob standard method in Ada.Command_Line ?

[anon]

In <op.vhrt97eexmjfy8@garhos>, =?iso-8859-15?Q?Yannick_Duch=EAne_=28Hibou57=29?= writes:
>Hello all,
>
>What about suggesting for Ada 2012, a Glob method as part of the standard  
>Ada.Command_Line package ?


If you want it, then create the package for your OS and Hardware and 
submitted to ARG aka Adacore.  Submit documentation and source code. 

Anyone can suggest a package for Ada but those who truly want it will 
design it and submit it for the board to vote on. Else it must be a prefect 
answer to a number of problems before the board will allocate time to 
design a package that a non paying ARG member suggest.

So, either design the package and submit it to the Adacore aka ARG or pay 
the ARG member fee and submit the concept. 

Re: What about a glob standard method in Ada.Command_Line ?

[Georg Bauhaus]

On 25.08.10 15:09, anon@att.net wrote:
> In <op.vhrt97eexmjfy8@garhos>, =?iso-8859-15?Q?Yannick_Duch=EAne_=28Hibou57=29?= writes:
>> Hello all,
>>
>> What about suggesting for Ada 2012, a Glob method as part of the standard  
>> Ada.Command_Line package ?
> 
> 
> If you want it, then create the package for your OS and Hardware and 
> submitted to ARG aka Adacore.

ARG:  ISO/IEC JTC 1/SC 22/WG 9 Ada Rapporteur Group (ARG)
AdaCore: Ada vendor, has members in ARG

There is no monopoly, yet.

Re: What about a glob standard method in Ada.Command_Line ?

[J-P. Rosen]

Le 25/08/2010 15:13, Georg Bauhaus a écrit :
> On 25.08.10 15:09, anon@att.net wrote:
>> If you want it, then create the package for your OS and Hardware and 
>> submitted to ARG aka Adacore.
> 
> ARG:  ISO/IEC JTC 1/SC 22/WG 9 Ada Rapporteur Group (ARG)
> AdaCore: Ada vendor, has members in ARG
> 
> There is no monopoly, yet.

>>  or pay the ARG member fee and submit the concept.
There is no fee for being an ARG member (although ARG member pay a lot
by doing the work on their spare time and by financing travels etc.).
And suggestions from anybody are welcome.

But maybe anon is confusing the ARG with the ARA? The ARA (Ada Ressource
Association) is a groupment of vendors, there is a fee to join, but the
ARA has no power on the evolution of the language.
-- 
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: What about a glob standard method in Ada.Command_Line ?

[Dmitry A. Kazakov]

On Wed, 25 Aug 2010 15:09:16 +0200, Georg Bauhaus wrote:

> On 25.08.10 14:01, Dmitry A. Kazakov wrote:
>> On Wed, 25 Aug 2010 13:09:41 +0200, Georg Bauhaus wrote:
>> 
>>> If you now want R* to decide the encoding of:
>> 
>> No, I want match this:
>> 
>>    a*¶
> 
> Fine, just do it using String; every component of a String
> is well defined. Code points have nothing to do with Strings.

If code points have nothing to do with String why do you propose to do it
with String? And how is this related to the point anyway?

>> This pattern precisely defines a language L:
> 
> It does no such thing absent a definition of *.

You have commented out the definition:

   L = aΣ*¶

Or in BNF

   L ::= a <star> ¶
   <star> ::= <empty> | <code-point> [<star>]

> The important question is what constitues Σ,

   http://en.wikipedia.org/wiki/Code_point

> If we use String, used in Directories.Start_Search,
> then everything, including Σ, is well defined in Ada,
> as is.

String as defined by RM 3.5.2 (2/2) does not represent Σ*. It could
represent some encoding of Σ*, which is the point.

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

Re: What about a glob standard method in Ada.Command_Line ?

[Jeffrey Carter]

On 08/25/2010 06:13 AM, Georg Bauhaus wrote:
> On 25.08.10 15:09, anon@att.net wrote:
>>
>> If you want it, then create the package for your OS and Hardware and
>> submitted to ARG aka Adacore.
>
> ARG:  ISO/IEC JTC 1/SC 22/WG 9 Ada Rapporteur Group (ARG)
> AdaCore: Ada vendor, has members in ARG

Yet more FUD from the "anon" FUD machine.

-- 
Jeff Carter
"What I wouldn't give for a large sock with horse manure in it."
Annie Hall
42

--- news://freenews.netfront.net/ - complaints: news@netfront.net ---

Re: What about a glob standard method in Ada.Command_Line ?

[Georg Bauhaus]

On 25.08.10 15:30, Dmitry A. Kazakov wrote:

> If code points have nothing to do with String why do you propose to do it
> with String?

Because file names as entities external to Ada have got nothing
to do with code points, from an Ada point of view: file names
have to do with Strings, though. This is in part a consequence
of how subprogram parameters in Directories.Start_Search were
chosen.

> And how is this related to the point anyway?

Directories.Start_Search exposes a programmatic interface to
names of files. String has might-work-best name components:
Standard.Character, because the outside world is under the
(full) control of the conflicting real world requirements
of users, other programs, legacy buggy programs, assumptions...
There is no completely working standard for file names.

Conclusion: there cannot be a good, portable Ada type
representing file names. No encoding will help,
no abstraction will help. But what we have, and what does
help, is a programming interface to the bare components of
file names: String.

(For me, not even file name Pattern is needed; but since
Start_Search operates on String, and since scanning a
directory
(a) with OS pattern
(b) without OS pattern
might result in the same computer operations,
I thought we might as well add another Start_Search that
makes Pattern passive: just fetch filenames one by one
as in (b) and let the programmer select based on RE
matching after the fact.)


>> The important question is what constitues Σ,
> 
>    http://en.wikipedia.org/wiki/Code_point

Start_Search is based on String; file names do not obey
the rules of ISO 10646; no hope. Practically, the Σs
established by external file names are not free of contradictions
or ambiguities.  But String can potentially remove
the contradictions, because it does not care about the meaning
of a sequence of (let's say) octets.  This is the big plus of
String: power to the programmer who assigns meaning to sequences
of octets.

And this is the big plus of String based REs: they do not
care about the meaning of a sequence of octets either, but
they can be employed to *find* meaningful sequences when
tackling real world file names.

From here, one can go on to a different type from the
collection that covers Unicode.

> It could
> represent some encoding of Σ*, which is the point.

Exactly.  And since there is no single, well defined,
portable Σ for file names, the best we can do is inspect
their encoded representations (String) and have our programs
draw their own conclusions.

Georg

Re: What about a glob standard method in Ada.Command_Line ?

[Dmitry A. Kazakov]

On Wed, 25 Aug 2010 16:20:03 +0200, Georg Bauhaus wrote:

> On 25.08.10 15:30, Dmitry A. Kazakov wrote:
> 
>> If code points have nothing to do with String why do you propose to do it
>> with String?
> 
> Because file names as entities external to Ada have got nothing
> to do with code points, from an Ada point of view: file names
> have to do with Strings, though. This is in part a consequence
> of how subprogram parameters in Directories.Start_Search were
> chosen.

Yes, that is the point: Ada.Directories is broken.

> Conclusion: there cannot be a good, portable Ada type
> representing file names.

From false premises follows anything. Certainly and without any doubt it is
possible to provide an abstraction which would work for Posix, Unix,
Windows, VMS, MacOS and name what OS.

> Start_Search is based on String; file names do not obey
> the rules of ISO 10646; no hope.

As I said it is broken. Broken things to be repaired or disposed. Since the
ARG cannot change OS they should look forward to change the RM.

> From here, one can go on to a different type from the
> collection that covers Unicode.

I am one who uses "Ada String means UTF-8 encoded string". Surely this
works. Since Ada.Directories is unusable, I deploy Glib bindings instead.
At least they cared to define file paths UTF-8. But the approach is wrong
because it mangles encoding and the contents. If I were to redesign
Ada.Directories, I would use a clone type of Wide_Wide_String for file
names. If Ada had array interfaces I would do it otherwise. But in any case
file name would not be string, file path would not be a file name etc.

>> It could
>> represent some encoding of οΏ½*, which is the point.
> 
> Exactly.  And since there is no single, well defined,
> portable οΏ½ for file names,

It is same as to say that there is no portable Integer type. Unicode code
points are portable because they are defined so.

If some name is not a valid file name you get Name_Error, likewise you get
Constraint_Error if some integer is not valid number for the given machine.

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

Re: What about a glob standard method in Ada.Command_Line ?

[Georg Bauhaus]

On 25.08.10 16:56, Dmitry A. Kazakov wrote:
> Certainly and without any doubt it is
> possible to provide an abstraction which would work for Posix, Unix,
> Windows, VMS, MacOS and name what OS.

It is not actually possible to provide a common abstraction
for *new* and *existing* file names.  While "broken", the file
names do exist.  Just a few examples illustrating a variety of file
naming fun:

- Names created in NTFS that end in a '.'

- Two names in existing ext2 directories that contain
 "mutually exclusive" characters (via incompatible encoding)

- Names containing characters that are special in Windows but
 not in POSIX.

- Names with spaces in them

To work with these, the abstraction would have to be super
fault tolerant and employ AI, or just tell the user they should
forget about working with their files because the file names
are broken. I consider this disrespectful. Raising an exception
is out of the question; it is the file contents that matter, not
their just their names, no matter how the names have arrived
in the state they are in.

Wide_Wide_String can't cure these, String can, and you
can transform from String to Wide_Wide_String after successful
file name deciphering.


>>  And since there is no single, well defined,
>> portable οΏ½ for file names,
> 
> It is same as to say that there is no portable Integer type.

If in the real word, I/O of "broken" integer values is a
reality.  I/O of integer cannot rely on a perfect
external representation.  Neither can I/O of file names.
The statistics of broken integers are just so much better.
Possibly because no one even remembers that integers
have a representation.  There are less many encodings
for them than for character sets, so there is less risk
that we run into integers of unknown encoding,
or sets of integers of different encodings.

> Unicode code
> points are portable because they are defined so.

Before the fact.  And then the facts are different,
because someone managed to inject some invalid
octet sequence... Nevertheless, this file's content
is darn important. Can't just raise an exception
because of a faulty name!

Almost all WWW documents are broken by your taxonomy.
Google is rich...

Georg

Re: What about a glob standard method in Ada.Command_Line ?

[Dmitry A. Kazakov]

On Wed, 25 Aug 2010 17:51:39 +0200, Georg Bauhaus wrote:

> On 25.08.10 16:56, Dmitry A. Kazakov wrote:
>> Certainly and without any doubt it is
>> possible to provide an abstraction which would work for Posix, Unix,
>> Windows, VMS, MacOS and name what OS.
> 
> It is not actually possible to provide a common abstraction
> for *new* and *existing* file names.  While "broken", the file
> names do exist.  Just a few examples illustrating a variety of file
> naming fun:
> 
> - Names created in NTFS that end in a '.'
>
> - Two names in existing ext2 directories that contain
>  "mutually exclusive" characters (via incompatible encoding)
> 
> - Names containing characters that are special in Windows but
>  not in POSIX.
> 
> - Names with spaces in them

You don't get the point. See A.13(9)

> Wide_Wide_String can't cure these,

It is, because any file name can be represented by Wide_Wide_String.

>>>  And since there is no single, well defined,
>>> portable οΏ½ for file names,
>> 
>> It is same as to say that there is no portable Integer type.
> 
> If in the real word, I/O of "broken" integer values is a
> reality.

What does this have to do with the point?

You seem to wish file names checked statically. Does Ada.Directories this?
Why then you pose this silly requirement?

> Can't just raise an exception
> because of a faulty name!

See A.13(9)

> Almost all WWW documents are broken by your taxonomy.
> Google is rich...

I don't understand what you are talking about.

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

Re: What about a glob standard method in Ada.Command_Line ?

[Georg Bauhaus]

On 25.08.10 18:46, Dmitry A. Kazakov wrote:

>> It is not actually possible to provide a common abstraction
>> for *new* and *existing* file names.  While "broken", the file
>> names do exist.  Just a few examples illustrating a variety of file
>> naming fun:
>>
>> - Names created in NTFS that end in a '.'
>>
>> - Two names in existing ext2 directories that contain
>>  "mutually exclusive" characters (via incompatible encoding)
>>
>> - Names containing characters that are special in Windows but
>>  not in POSIX.
>>
>> - Names with spaces in them
> 
> You don't get the point. See A.13(9)

procedure Start_Search
   (Search    : in out Search_Type;
    Directory : in String;
    Matcher   : access function (Pattern : Pattern_Type) return Boolean;
    Filter    : in Filter_Type := (others => True));


There is no  "string given for the parameter [Matcher]" that "does
not allow the identification of an external file".
The situation is reversed: The suggested overloaded procedure
Directories.Start_Search (or Search) will RECEIVE a name from the file
system via the run-time system; the name of an existing file; one
that has been identified already.
There is no identification attempt performed by the program.
It acts as if some implementation-defined all-inclusive wildcard
had been passed to Ada's Directories.Start_Search, as the
Pattern : String parameter, and then, later, some callback (Matcher
in the alternative declaration above) checks to see whether the file
identifying file name that it got from the system is fine.


  OS -> file name -> Search -> Matcher (sees file name) -> ...

Not

  file name pattern -> Search -> !! identification

But as if

  "*" -> Search -> Match (file name pattern) -> ...


>> If in the real word, I/O of "broken" integer values is a
>> reality.
> 
> What does this have to do with the point?

I expect file names to be read from the disk, as is, I do not
construct them. Whether they are broken WRT some expectation
or not is like when a program receives a valid or usable representation
or not from an integer location:

  V : Integer_Subtype;
  pramga Import (Ada, V);
  pragma Volatile (V);

As you can see, this is how I consider existing names of existing
files, too.  But I want to be able to look at the bits of V, not
just raise an exception.

> You seem to wish file names checked statically.

No.


>> Almost all WWW documents are broken by your taxonomy.
>> Google is rich...
> 
> I don't understand what you are talking about.

An analogy.
If the WWW, that is, the external environment, has valid
HTML, it is possible to use HTML grammar to describe
HTML. It isn't valid. But we can still try to extract meaningful
information even from syntactically broken pages.
The state of file names may be a little more correct
than an average WWW page.
I want to be able to use both.
How can I do that if the interesting data needs to be
in proper shape to be processed without raising exceptions?
By analogy, how can I process whatever exists in the directory
as file names if these need to be conforming to some scheme?


Georg

Re: What about a glob standard method in Ada.Command_Line ?

[Dmitry A. Kazakov]

On Wed, 25 Aug 2010 20:44:17 +0200, Georg Bauhaus wrote:

> On 25.08.10 18:46, Dmitry A. Kazakov wrote:
> 
>>> It is not actually possible to provide a common abstraction
>>> for *new* and *existing* file names.  While "broken", the file
>>> names do exist.  Just a few examples illustrating a variety of file
>>> naming fun:
>>>
>>> - Names created in NTFS that end in a '.'
>>>
>>> - Two names in existing ext2 directories that contain
>>>  "mutually exclusive" characters (via incompatible encoding)
>>>
>>> - Names containing characters that are special in Windows but
>>>  not in POSIX.
>>>
>>> - Names with spaces in them
>> 
>> You don't get the point. See A.13(9)
> 
> procedure Start_Search
>    (Search    : in out Search_Type;
>     Directory : in String;
>     Matcher   : access function (Pattern : Pattern_Type) return Boolean;
>     Filter    : in Filter_Type := (others => True));
> 
> 
> There is no  "string given for the parameter [Matcher]" that "does
> not allow the identification of an external file".
> The situation is reversed: The suggested overloaded procedure
> Directories.Start_Search (or Search) will RECEIVE a name from the file
> system via the run-time system; the name of an existing file; one
> that has been identified already.
> There is no identification attempt performed by the program.
> It acts as if some implementation-defined all-inclusive wildcard
> had been passed to Ada's Directories.Start_Search, as the
> Pattern : String parameter, and then, later, some callback (Matcher
> in the alternative declaration above) checks to see whether the file
> identifying file name that it got from the system is fine.
> 
> 
>   OS -> file name -> Search -> Matcher (sees file name) -> ...
> 
> Not
> 
>   file name pattern -> Search -> !! identification
> 
> But as if
> 
>   "*" -> Search -> Match (file name pattern) -> ...

What does this have to do with legality of names with spaces?

How could it help to implement search for all files matched by a*¶?

>>> If in the real word, I/O of "broken" integer values is a
>>> reality.
>> 
>> What does this have to do with the point?
> 
> I expect file names to be read from the disk, as is, I do not
> construct them.

I don't even know what does it mean to read anything "as-is." It just does
not make any sense. How do you know if ab¶ was read as-is or as something
else? Did you use magnifying glass to inspect the hard drive to tell how is
ab¶ there?

> Whether they are broken WRT some expectation
> or not is like when a program receives a valid or usable representation
> or not from an integer location:
> 
>   V : Integer_Subtype;
>   pramga Import (Ada, V);
>   pragma Volatile (V);

So, V was read as-is?

> As you can see, this is how I consider existing names of existing
> files, too.  But I want to be able to look at the bits of V, not
> just raise an exception.

Why on earth reading file name should raise exceptions except that when the
file system is corrupt? Where did you get it? From Ada.Directories? Well it
probably should if the file is named "это вам не Latin-1". But I bet,
GNAT's implementation does not. Anyway, this is another crack among others
in Ada.Directories.

>>> Almost all WWW documents are broken by your taxonomy.
>>> Google is rich...
>> 
>> I don't understand what you are talking about.
> 
> An analogy.
> If the WWW, that is, the external environment, has valid
> HTML, it is possible to use HTML grammar to describe
> HTML. It isn't valid. But we can still try to extract meaningful
> information even from syntactically broken pages.

This has nothing to do with file names, except that here you again are
confusing encoding and the contents.

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

Re: What about a glob standard method in Ada.Command_Line ?

[(see below)]

On 25/08/2010 09:24, in article op.vhziy8yyxmjfy8@garhos, "Yannick Duch�ne
(Hibou57)" <yannick_duchene@yahoo.fr> wrote:

> Mac OS used to have a good technique to tag files types and applications
> to be used to open it, via meta-data... unfortunately, it drop it with OS
> X to follow DOS/Windows convention (many users was disappointed, but Apple
> did not care).

This is false (or so misleading as to be false FAPP). The DOS/Windows
convention is only one of several techniques MacOS X supports for file-type
association.

See <http://en.wikipedia.org/wiki/Uniform_Type_Identifier>.

-- 
Bill Findlay
<surname><forename> chez blueyonder.co.uk

Re: What about a glob standard method in Ada.Command_Line ?

[Yannick Duchêne (Hibou57)]

Le Wed, 25 Aug 2010 15:28:09 +0200, J-P. Rosen <rosen@adalog.fr> a écrit:
> But maybe anon is confusing the ARG with the ARA? The ARA (Ada Ressource
> Association) is a groupment of vendors, there is a fee to join, but the
> ARA has no power on the evolution of the language.
I remember that name, ARA. I meet it when I was reading documents to  
understand the validation process. Feel to remember the ARA was involved  
in some manner in this (compiler validation).

Found back a page about it:
http://www.adaic.org/compilers/articles/acaa_org.html


-- 
* 3 lines of concise statements is readable, 10 pages of concise  
statements is unreadable ;
* 3 lines of verbose statements may looks unuseful, 10 pages of verbose  
statements will never looks too much pedantic

Re: What about a glob standard method in Ada.Command_Line ?

[Yannick Duchêne (Hibou57)]

Le Wed, 25 Aug 2010 22:15:56 +0200, (see below)  
<yaldnif.w@blueyonder.co.uk> a écrit:
>> Mac OS used to have a good technique to tag files types and applications
>> to be used to open it, via meta-data... unfortunately, it drop it with  
>> OS
>> X to follow DOS/Windows convention (many users was disappointed, but  
>> Apple
>> did not care).
>
> This is false (or so misleading as to be false FAPP). The DOS/Windows
> convention is only one of several techniques MacOS X supports for  
> file-type
> association.
I do not own a Mac, so may be indeed I was wrong somewhere. But I use to  
read about the Mac system and philosophy to try to figure if there is or  
not a technical solution to compile Mac applications from Windows. So I  
came to this topic, and really I read something about it, stating  
something changed there when switching from the ancient Mac 0S up to 9, to  
the new Mac OS X (completely different system in the core, while mostly  
compatible in many topics). And I am sure I have read complaints about the  
file extension à la Windows vs  the file type tag. May be both are still  
coexisting and there is just less focus on the type tag so fans of the  
original Mac way was disappointed ? (as I said, I do not own a Mac, so  
cannot figure this my self)

Any way, thanks for the possible error you noticed.

> See <http://en.wikipedia.org/wiki/Uniform_Type_Identifier>.
Oh s**t, wikipedia again. Fed-up, sorry, will try to peak another source,  
sure there must be another one.


-- 
* 3 lines of concise statements is readable, 10 pages of concise  
statements is unreadable ;
* 3 lines of verbose statements may looks unuseful, 10 pages of verbose  
statements will never looks too much pedantic

Re: What about a glob standard method in Ada.Command_Line ?

[(see below)]

On 25/08/2010 21:39, in article op.vh0gzhj0xmjfy8@garhos, "Yannick Duch�ne
(Hibou57)" <yannick_duchene@yahoo.fr> wrote:

> I do not own a Mac, so may be indeed I was wrong somewhere. But I use to
> read about the Mac system and philosophy to try to figure if there is or
> not a technical solution to compile Mac applications from Windows. So I
> came to this topic, and really I read something about it, stating
> something changed there when switching from the ancient Mac 0S up to 9, to
> the new Mac OS X (completely different system in the core, while mostly
> compatible in many topics). And I am sure I have read complaints about the
> file extension � la Windows vs  the file type tag. May be both are still
> coexisting and there is just less focus on the type tag so fans of the
> original Mac way was disappointed ? (as I said, I do not own a Mac, so
> cannot figure this my self)
> 
> Any way, thanks for the possible error you noticed.
> 
>> See <http://en.wikipedia.org/wiki/Uniform_Type_Identifier>.
> Oh s**t, wikipedia again. Fed-up, sorry, will try to peak another source,
> sure there must be another one.

 <http://developer.apple.com/mac/library/documentation/FileManagement/Concep
tual/understanding_utis/understand_utis_conc/understand_utis_conc.html#//app
le_ref/doc/uid/TP40001319-CH202-CHDHIJDE>

-- 
Bill Findlay
<surname><forename> chez blueyonder.co.uk

Re: What about a glob standard method in Ada.Command_Line ?

[Yannick Duchêne (Hibou57)]

Le Wed, 25 Aug 2010 23:05:43 +0200, (see below)  
<yaldnif.w@blueyonder.co.uk> a écrit:
>  <http://developer.apple.com/mac/library/documentation/FileManagement/Concep
> tual/understanding_utis/understand_utis_conc/understand_utis_conc.html#//app
> le_ref/doc/uid/TP40001319-CH202-CHDHIJDE>

I am quoting the above document:

    A key advantage of uniform type identifiers over other type
    identification methods is that they are declared in a conformance
    hierarchy. A conformance hierarchy is analogous to a class hierarchy
    in object-oriented programming. Instead of “type A conforms to
    type B,” you can also think of this as “all instances of type A
    are also instances of type B.”

This is indeed the most logical way to handle file types. Would be nice as  
a public standard, but would require this to be followed, which is another  
affair (what I do not enjoy with the Windows way, is the too much frequent  
clashes with file extensions, and as soon as a clash is there, this make  
the given file extension mostly unusable).

-- 
* 3 lines of concise statements is readable, 10 pages of concise  
statements is unreadable ;
* 3 lines of verbose statements may looks unuseful, 10 pages of verbose  
statements will never looks too much pedantic

Re: What about a glob standard method in Ada.Command_Line ?

[anon]

In <4c7516f7$0$7664$9b4e6d93@newsspool1.arcor-online.net>, Georg Bauhaus <rm.dash-bauhaus@futureapps.de> writes:
>On 25.08.10 15:09, anon@att.net wrote:
>> In <op.vhrt97eexmjfy8@garhos>, =?iso-8859-15?Q?Yannick_Duch=EAne_=28Hibou57=29?= writes:
>>> Hello all,
>>>
>>> What about suggesting for Ada 2012, a Glob method as part of the standard  
>>> Ada.Command_Line package ?
>> 
>> 
>> If you want it, then create the package for your OS and Hardware and 
>> submitted to ARG aka Adacore.
>
>ARG:  ISO/IEC JTC 1/SC 22/WG 9 Ada Rapporteur Group (ARG)
>AdaCore: Ada vendor, has members in ARG
>
>There is no monopoly, yet.

Better look at becoming a member, you pay Adacore !!!

Re: What about a glob standard method in Ada.Command_Line ?

[Georg Bauhaus]

On 8/25/10 9:39 PM, Dmitry A. Kazakov wrote:

>>    "*" ->  Search ->  Match (file name pattern) ->  ...
>
> What does this have to do with legality of names with spaces?
>
> How could it help to implement search for all files matched by a*¶?

I'm beginning to feel I have once again missed the proper
references for the meaning of words in our discussion.

You said, "You just do not need patterns in directory search."
Did this refer to the Pattern : String parameter of
(Start_)Search?   If so, I fully agree.

Here is what I wanted Matcher : access function (...) to be.

1. get rid of implementation-defined Pattern : String

2. do with the names what I want after they have been read:
   For example, call a function matching a name against some
    RE pattern

3. delegate the calling to (Start_)Search

(Otherwise, everything is pretty much like Search.)

Filenames "as is" means whatever the OS or run-time
passes to (Start_)Search, something that can be passed to
other operations that require a file name.

String is a most flexible data structure for file names
because it can store any kind of file name which I take to be
a sequence of bits. One could use Wide_Wide_String or
Storage_Element_Array for a file name as long as no attempt is
made to attribute meaning to file name other than an ordered
sequence of bits that identifies a file.  Anything more is
wishful thinking. Character strings are just more practical
than bit patterns or number sequences.

IOW, I simply do not care what standard meaning one might
attribute to the sequence of bytes that comes in.  If it
needs to be shown to a user, then "appropriate conversion",
in a best effort sense, is probably best, from bit string to
some other string.

When I said that case insensitivity is handled by RE pattern
matching, I did not mean that issues like moving collections of
files between case-sensitive and case-insensitive file systems
can be handled by RE pattern matching.

I still can't figure out why you have been referring to Name_Error.
The file names considered by my Start_Search variant necessarily
identify existing files.  In this sense, exceptions caused by anything
to do with existing file's names will not seem acceptable.

Here is code looking for a file named "aö" on a number of file
systems.  Source file encoding should be Latin-1.

with Ada.Text_IO;
with Ada.Directories;

procedure Filenames is

    Not_Found_Error : exception;

    procedure Show_String (S: String);
    -- tabular display of Characters in S, with hex codes

    function Find_Odd_Name return String;
    --  Look for a file named "aö" and return the characters of this name.
    --  Raises Not_Found_Error

    function Find_Odd_Name return String is
       use Ada.Directories;
       Search_For_Aö : Search_Type;
       Dir_Entry : Directory_Entry_Type;
       Aö8 : constant String :=  "aö";  -- UTF-8
       AöL : constant String :=  "aö";  -- Latin-1
       AöN : constant String :=  "ao" &
         Character'Val (16#CC#) &
         Character'Val (16#88#);  -- NFD (HFS+)
    begin
       Start_Search (Search => Search_For_Aö,
                     Directory => "News",
                     Pattern => "*");
       loop
          exit when not More_Entries (Search_For_Aö);
          Get_Next_Entry (Search_For_Aö, Dir_Entry);
          declare
             Name : constant String := Simple_Name (Dir_Entry);
          begin
             if
               Name = Aö8
               or Name = AöL
               or Name = AöN
             then
                End_Search(Search_For_Aö);
                return Name;
             end if;
          end;
       end loop;
       raise Not_Found_Error;
    end Find_Odd_Name;

    procedure Show_String (S: String) is
       package Hex_IO is new Ada.Text_IO.Integer_IO (Natural);
    begin
       Hex_IO.Default_Base := 16;
       for K in S'Range loop
          Ada.Text_IO.Put (S(K));
          Hex_IO.Put (Character'Pos(S(K)));
          Ada.Text_IO.New_Line;
       end loop;
    end Show_String;

begin
    declare
       Filename : constant String := Find_Odd_Name ;
    begin
       Show_String(Filename);
    end ;
end Filenames;


-- Georg

Re: What about a glob standard method in Ada.Command_Line ?

[J-P. Rosen]

Le 25/08/2010 23:37, anon@att.net a �crit :
>> ARG:  ISO/IEC JTC 1/SC 22/WG 9 Ada Rapporteur Group (ARG)
>> AdaCore: Ada vendor, has members in ARG
>>
>> There is no monopoly, yet.
> 
> Better look at becoming a member, you pay Adacore !!!
This is 100% PLAIN WRONG (I usually don't like to respond to anon's
absurdities, but since his messages can be found by newsgroups searches,
I can't leave it).

I am an ARG member. I never paid anything beyond the travel and meeting
costs, and certainly not to AdaCore.

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

Re: What about a glob standard method in Ada.Command_Line ?

[Dmitry A. Kazakov]

On Thu, 26 Aug 2010 02:59:25 +0200, Georg Bauhaus wrote:

> You said, "You just do not need patterns in directory search."
> Did this refer to the Pattern : String parameter of
> (Start_)Search?

There is no need in either pattern parameter or a filter call back
function. What is needed is a proper abstraction that would define file
name as sequence of code points = in an OS-independent way.

Ada.Directories shall convert OS-specific encoding (actually there are many
per OS, like in the case of Windows), when the directory entities are
enumerated. All operations requiring file name shall convert it back.

There are other self-evident requirements. But since it seems that nobody
actually uses Ada.Directories, there will be no pressure on the ARG to fix
it any soon.

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

Re: What about a glob standard method in Ada.Command_Line ?

[anon]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3608 bytes --]

In <i5586l$1q6$1@news.eternal-september.org>, "J-P. Rosen" <rosen@adalog.fr> writes:
>Le 25/08/2010 23:37, anon@att.net a �crit :
>>> ARG:  ISO/IEC JTC 1/SC 22/WG 9 Ada Rapporteur Group (ARG)
>>> AdaCore: Ada vendor, has members in ARG
>>>
>>> There is no monopoly, yet.
>> 
>> Better look at becoming a member, you pay Adacore !!!
>This is 100% PLAIN WRONG (I usually don't like to respond to anon's
>absurdities, but since his messages can be found by newsgroups searches,
>I can't leave it).
>
>I am an ARG member. I never paid anything beyond the travel and meeting
>costs, and certainly not to AdaCore.
>
>-- 
>---------------------------------------------------------
>           J-P. Rosen (rosen@adalog.fr)
>Visit Adalog's web site at http://www.adalog.fr


Monopoly:  Yes, my son Adacore has a monopoly.  The reason is that first 
Adacore is the ONLY Ada vendor that has a current standard compiler and 
is voting.  IBM just upgrades the compiler but they chose not to have a 
direct say in the design of Ada 2007 (2005) or have not made any move 
on the design of Ada 2012, its all Adacore.

Second, all other Ada vendors have decided not to upgrade their Ada 
compilers to the current standard. Some may start the upgrade but they 
are not fully Ada 2007 complaint! So, the only active Ada vendor is 
Adacore, its just like IBM, is the only active vendor for PL/1. Also, 
if you visit SGI, SUN, or others hardware/software companies who had 
there own Ada compiler back in the 1980 .. 1990s and look for a current 
version of the Ada compiler they will redirect you to Adacore's GNAT.

So, Adacore has become a Monopoly legally, because others have chosen 
not to taken an active role in the Ada language any more by maintaining a 
current standard that is usable by the current systems. Yes, Randy Brukardt 
from RRSoftware is a member of ARG but Janus Ada is Ada 95 only for Win 
95/98. It might work under Windows 7 but how many people are going to buy 
the compiler just to find out because as we all know once open installed 
there's a no returns policy.

So, you either accept Adacore's GNAT "as is" or pay $15K plus to 
Adacore for support and have the right to talk about accepting your 
package as apart of the next standard. And for others on the list of 
WG9, they may vote but when Adacore, disagree, what are they going 
to do there is no other vendor to chose. So, aka Adacore rules Ada.

And in the US to be a voting member of WG9 a sub of the ISO you must 
be a member of ANSI. Other countries have there own version of the 
standards process that sooner or later you will have to pay a annual 
fee. Also, the voting member of WG9 are chosen by the national 
delegations of that country, and in the US that is Robert Dewar of 
AdaCore.

All this means is that Adacore has too much control of Ada and the Ada 
Standards, for a language they did not create.


Some of the major member of WG9 (as of 2009):
Note: Spark Ada (Ada vendor) is not on the list.

  Ada Vendors  -- ( to most the only votes that counts )
    * Randall Brukardt  -- R.R. Software, Inc., USA
    * Robert Dewar      -- AdaCore, USA
    * Greg Gicca        -- AdaCore, USA
    * Nasser Kettani    -- Rational Software France, France ( IBM )

  Special Ada Interest
    * Clyde Roby        -- Institute for Defense Analyses, USA (DoD)

  Special Designer Interest
    * Stephen Michell   -- Maurya Software, Inc. Canada
                             (Secuity, SRG)
    * Sally Seitz       -- ANSI, USA

  12 Professors (Worldwide)
  19 Others interested parties
     *  Jean-Pierre Rosen   -- Adalog, france

Re: What about a glob standard method in Ada.Command_Line ?

[Yannick Duchêne (Hibou57)]

Le Thu, 26 Aug 2010 18:29:07 +0200, <anon@att.net> a écrit:
> The reason is that first
> Adacore is the ONLY Ada vendor that has a current standard compiler
No, there are many other. This is just there do not choose to re-run the  
validation process (I suppose for financial reasons, I do not know the  
price at all).

The validation process requires that passed an amount of time, a compiler  
must be validated again. These other providers still own the exact version  
of their compiler which successfully passed the validation process. Above  
that, users of these compilers can them self run a particular ACAT test as  
they want, as this set of testes if publicly available.

The compiler vendor may do the same as well : running CAT testes on its  
product, without formally running a real validation (I still suppose for  
economical or timing reason).

The reason which make GNAT more visible than others, is the dual license :  
there is GNAT Pro and GNAT GPL (in short). Others has only commercial  
licenses. The other reason is that GNAT was originally funded by an  
university program. Others was not (and this helped GNAT a lot).

GNAT is more visible, but not a monopoly and does not seems to me to have  
any attempt to this way.

And some vendors, like SoftCheck, are unlikely to let this kind of thing  
occurs without shouting a bit I feel.


> Second, all other Ada vendors have decided not to upgrade their Ada
> compilers to the current standard.
Client matters. Although the latest version of the standard is Ada 2005,  
and the nearly born one is Ada 2012, big projects still ask for Ada 95,  
which is the most widely used Ada standard. Think of others using Ada 2005  
or 2012, as hider testers, pioneers, little companies with more  
flexibility, standalone users, students, and so on.

Other areas has other requirements, and many Ada providers just have these  
companies as clients.

> Some may start the upgrade but they
> are not fully Ada 2007 complaint!
Ada 207 ?

> So, the only active Ada vendor is
> Adacore, its just like IBM, is the only active vendor for PL/1.
No. Have a look at this:
http://www.adaic.org/compilers/comp-tool.html
and this:
http://www.adaic.org/links/tools.html

> Also,
> if you visit SGI, SUN, or others hardware/software companies who had
> there own Ada compiler back in the 1980 .. 1990s and look for a current
> version of the Ada compiler they will redirect you to Adacore's GNAT.
Lnks to some pages please ?

> So, Adacore has become a Monopoly legally, because others have chosen
> not to taken an active role in the Ada language any more by maintaining a
> current standard that is usable by the current systems. Yes, Randy  
> Brukardt
> from RRSoftware is a member of ARG but Janus Ada is Ada 95 only for Win
> 95/98. It might work under Windows 7 but how many people are going to buy
> the compiler just to find out because as we all know once open installed
> there's a no returns policy.
Randy may reply you better, but I would like to say that if RRSoftware do  
not provide an Ada compiler for other platform, this is not due to a  
supposed monopoly, this is simply because an Ada compiler is a lot of  
work, and RRSoftware may just have less people working on this.


> So, you either accept Adacore's GNAT "as is" or pay $15K plus to
Janus Ada is far less than $15K. If you want something cheaper, you have a  
choice. If you want to target other platform, like UNIXes, BSDs, embedded  
CPUs, you also have a choice.

> Adacore for support and have the right to talk about accepting your
> package as apart of the next standard.
Silly. Look at Ada issues, these are full of submissions from various  
peoples. Recently Jean-Pierre Rosen suggested I could send a submit a tiny  
proposition for the next standard. I am not at all a member of AdaCore.

> And for others on the list of
> WG9, they may vote but when Adacore, disagree, what are they going
> to do there is no other vendor to chose. So, aka Adacore rules Ada.
Were you present at one of their meeting to state that ?

Once again, look at Ada issues, and you will see:
http://ada-auth.org/ais.html

> And in the US to be a voting member of WG9 a sub of the ISO you must
> be a member of ANSI. Other countries have there own version of the
> standards process that sooner or later you will have to pay a annual
> fee.
You may have to pay fee to be member of some local standard office member.  
That is true, but this does not imply no body else can suggest this and  
that comment about the standard.

> Also, the voting member of WG9 are chosen by the national
> delegations of that country, and in the US that is Robert Dewar of
> AdaCore.
Do not know about that, so will not tell anything.

> All this means is that Adacore has too much control of Ada and the Ada
> Standards, for a language they did not create.
No. AdaCore is not under control of the standard, you did not demonstrated  
this.

Just look at the copyrights on the Ada 2005 standard:
http://www.adaic.org/standards/05rm/html/RM-TTL.html

> Some of the major member of WG9 (as of 2009):
> Note: Spark Ada (Ada vendor) is not on the list.
SPARK, an Ada vendor ? Are serious ?

>   Ada Vendors  -- ( to most the only votes that counts )
>     * Randall Brukardt  -- R.R. Software, Inc., USA
>     * Robert Dewar      -- AdaCore, USA
>     * Greg Gicca        -- AdaCore, USA
>     * Nasser Kettani    -- Rational Software France, France ( IBM )
>
>   Special Ada Interest
>     * Clyde Roby        -- Institute for Defense Analyses, USA (DoD)
>
>   Special Designer Interest
>     * Stephen Michell   -- Maurya Software, Inc. Canada
>                              (Secuity, SRG)
>     * Sally Seitz       -- ANSI, USA
>
>   12 Professors (Worldwide)
>   19 Others interested parties
>      *  Jean-Pierre Rosen   -- Adalog, france
>
You forget the ISO!

And your forget to mention all unknown peoples, [tiny|big] compagnies,  
hobbyst, students, who sent or will send their own comment to ada-auth.


-- 
* 3 lines of concise statements is readable, 10 pages of concise  
statements is unreadable ;
* 3 lines of verbose statements may looks unuseful, 10 pages of verbose  
statements will never looks too much pedantic

Re: What about a glob standard method in Ada.Command_Line ?

[Yannick Duchêne (Hibou57)]

Le Thu, 26 Aug 2010 22:34:38 +0200, Yannick Duchêne (Hibou57)  
<yannick_duchene@yahoo.fr> a écrit:

> Le Thu, 26 Aug 2010 18:29:07 +0200, <anon@att.net> a écrit:
>> The reason is that first
>> Adacore is the ONLY Ada vendor that has a current standard compiler
> [...]
> The reason which make GNAT more visible than others, is the dual license  
> : there is GNAT Pro and GNAT GPL (in short). Others has only commercial  
> licenses.

This drive to another topic: if GNAT is so much more visible than others,  
this is *also mainly due to users and users choices*. Some can't or don't  
want (depends on people) get a commercial license. AdaCore cannot be  
stated responsible of that. A few others has other requirements and just  
want to be able to rely on a second compiler for safety, comparison, or  
any other concern. This is well is not under control of AdaCore. The main  
reason is: Users and users choices (whatever the reasons are).

Any way, I do not feel the overall comment was constructive, that is  
mainly what make me feel to at ease with it. If at least you were to  
release your own Ada compiler and were hurt by some difficulties while  
trying to make your place there, I would have understood your complaints  
about AdaCore. But this is not, and I really not see any reason why you  
complaint. Because you do not like GNAT ? You feel it does not reach the  
quality you would expected ?

Finally, you exposed complains, but you did not tell anything about why it  
matters and why it troubles you. You did not mention a single reason (may  
be because there is really not a single one).

For other: yes, I know, the previous post was plenty of grammatical and  
spelling mistakes, but it is to late to fix it now. Just apologize.

-- 
* 3 lines of concise statements is readable, 10 pages of concise  
statements is unreadable ;
* 3 lines of verbose statements may looks unuseful, 10 pages of verbose  
statements will never looks too much pedantic

Re: What about a glob standard method in Ada.Command_Line ?

[J-P. Rosen]

Le 26/08/2010 18:29, anon@att.net a �crit :

Plain wrong again:
> IBM just upgrades the compiler but they chose not to have a 
> direct say in the design of Ada 2007 (2005)
Pascal Leroy, who chaired the ARG during the making of Ada2005 was an
employee of IBM at that time
-- 
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: Ada compilers and Ada 2005 (was: What about a glob standard method in Ada.Command_Line ?)

[Georg Bauhaus]

On 8/27/10 2:10 PM, J-P. Rosen wrote:
> Le 26/08/2010 18:29, anon@att.net a �crit :
>
> Plain wrong again:
>> IBM just upgrades the compiler but they chose not to have a
>> direct say in the design of Ada 2007 (2005)
> Pascal Leroy, who chaired the ARG during the making of Ada2005 was an
> employee of IBM at that time

Just to add to the picture of compilers supporting Ada 2005,re
this is text from AI05-0096, sent in November 2007:

"... who has implemented all of the other container generics
for IBM/Rational ..."

The message is about the new Holder container, so it seems clear
that the quote is referring to Ada 2005 containers in IBM/Rational Ada.


On a related issue, the wikipedia entry has this  about Ada:

"Designed by

  Ada1983: Jean Ichbiah;
  Ada1995: Tucker Taft;
  Ada2005: Tucker Taft"

Shouldn't Pascal Leroy be listed for Ada 2005?



Georg

Re: Ada compilers and Ada 2005

[Pascal Obry]

Georg,

> On a related issue, the wikipedia entry has this  about Ada:
> 
> "Designed by
> 
>  Ada1983: Jean Ichbiah;
>  Ada1995: Tucker Taft;
>  Ada2005: Tucker Taft"
> 
> Shouldn't Pascal Leroy be listed for Ada 2005?

I think that the "Designed by" is wrong, this is a team effort and
anyone can contribute. The team leader was J. Ichbiah for 83, T. Taft
for 95, don't know for other revisions.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|    http://www.obry.net  -  http://v2p.fr.eu.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver keys.gnupg.net --recv-key F949BD3B

Re: Ada compilers and Ada 2005

[J-P. Rosen]

Le 01/09/2010 11:45, Pascal Obry a �crit :
> I think that the "Designed by" is wrong, this is a team effort and
> anyone can contribute. The team leader was J. Ichbiah for 83, T. Taft
> for 95, don't know for other revisions.
> 
For 83 and 95, this has been done on contract. The contract was awarded
to a company, with a strong team leader. 2005 was designed by the ARG,
with input from the community. Pascal was an excellent ARG chair, but
not as influential on the design as Jean was for 83 or Tuck for 95.

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

Re: What about a glob standard method in Ada.Command_Line ?

[Randy Brukardt]

"Georg Bauhaus" <rm-host.bauhaus@maps.futureapps.de> wrote in message 
news:4c75bc6d$0$6973$9b4e6d93@newsspool4.arcor-online.net...
...
> You said, "You just do not need patterns in directory search."
> Did this refer to the Pattern : String parameter of
> (Start_)Search?   If so, I fully agree.
>
> Here is what I wanted Matcher : access function (...) to be.
>
> 1. get rid of implementation-defined Pattern : String

It's not implementation-defined if it is null; that is defined to match 
everything (always).

I'm not sure why we didn't give it a null string default (that seems like 
the logical thing to have done, since you often want to return everything). 
(I thought we had given it such a default, but that is definitely not the 
case.)

> 2. do with the names what I want after they have been read:

Why is such a Matcher routine necessary? You might as well just test the 
file name returned; there is going to be more overhead in the callback 
routine than in a direct test, and there is no way for the OS to help.

The reason there is an implementation-defined pattern parameter is that some 
OSes (Windows, for instance) can take the pattern directly and only return 
matches -- in this case, the Ada runtime can potentially be more efficient 
than writing the code explicitly. If the code has to be written explicitly, 
it might as well be part of the user program. There wasn't any intent to 
support anything here that the OS doesn't support directly (on POSIX 
systems, it would make sense to only support the null string pattern, 
although I think actual implementations do more). Programs that want to be 
as portable as possible ought to only use Pattern => "" in Start_Search.

                                Randy.

Re: What about a glob standard method in Ada.Command_Line ?

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:198k7jlp1nvhi$.1mq6mu1iorkpi$.dlg@40tude.net...
...
> There are other self-evident requirements. But since it seems that nobody
> actually uses Ada.Directories, there will be no pressure on the ARG to fix
> it any soon.

This is getting silly. I use Ada.Directories heavily in all of my programs; 
and I used Claw.Directories (on which it is based) for years before that. It 
works great for what it is intended for. You seem to want to use it for 
things for which it was never intended (and indeed things that defy 
abstraction). Perhaps there is no pressure to change it much because most 
users don't see any significant problems?

The encoding of file names as Strings is less than ideal, but it is 
something that we inherited from Ada 83, and cannot change without breaking 
virtually all existing Ada programs. In order to do that, we'd need to add 
overloaded Opens that take Wide_Wide_Character file names:
             procedure Open (File : in out File_Type; Mode : in File_Mode;
                                        Name : in Wide_Wide_String; Form : 
in Wide_Wide_String := "");
But then any calls on Open using literal file names (which are very common) 
would be ambiguous and fail to compile. For instance,
            Open (My_Std_Error, Name => "err:", Mode => Out_File);

Thus, this isn't happening.

Using a private type for file names would be possible, but it would be way 
too hard to use; harder than Unbounded_Strings which is already too hard to 
use regularly.

                               Randy.

Re: Ada compilers and Ada 2005

[Randy Brukardt]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1210 bytes --]

"J-P. Rosen" <rosen@adalog.fr> wrote in message 
news:i5l9s5$4dd$1@news.eternal-september.org...
> Le 01/09/2010 11:45, Pascal Obry a �crit :
>> I think that the "Designed by" is wrong, this is a team effort and
>> anyone can contribute. The team leader was J. Ichbiah for 83, T. Taft
>> for 95, don't know for other revisions.
>>
> For 83 and 95, this has been done on contract. The contract was awarded
> to a company, with a strong team leader. 2005 was designed by the ARG,
> with input from the community. Pascal was an excellent ARG chair, but
> not as influential on the design as Jean was for 83 or Tuck for 95.

Right. Formally, I'm the project editor (and have been since 1998), along 
with the current ARG chair. The project editors are given authorship credit, 
but the work has truly been a team effort. Various people have led different 
parts of the work (Alan Burns for real-time; Matt Heaney for the containers; 
Tucker Taft for all manner of things). To a significant extent, that was 
even true for Ada 95 (most of the Annexes were written by particular 
authors, for instance). My job is mainly herding cats :-) and quality 
control.

                                          Randy.

Re: What about a glob standard method in Ada.Command_Line ?

[Dmitry A. Kazakov]

On Thu, 2 Sep 2010 14:25:46 -0500, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
> news:198k7jlp1nvhi$.1mq6mu1iorkpi$.dlg@40tude.net...
> ...
>> There are other self-evident requirements. But since it seems that nobody
>> actually uses Ada.Directories, there will be no pressure on the ARG to fix
>> it any soon.
> 
> This is getting silly. I use Ada.Directories heavily in all of my programs; 
> and I used Claw.Directories (on which it is based) for years before that.

That wonders me, because I really see no task, which could be accomplished
with Ada.Directories in a portable way. This is an important point, because
if I would not care about portability I just would use Windows or Linux API
rather than Ada.Directories. I have no idea if GNAT Ada.Directories
actually works under, say, Russian Windows with UCS-2, or for German
Windows with files named in Chinese UTF-16, but I am almost sure that
nobody even tried that.

> Perhaps there is no pressure to change it much because most 
> users don't see any significant problems?

Yes, they see no problems because they don't use it.

> Using a private type for file names would be possible, but it would be way 
> too hard to use;

I don't think so. It could be designed with an appropriate set of
operations like:

   function "/" (Directory : Relative_Path; Name : Wide_Wide_String)
      return Relative_Path;

etc. "a"/"b"/"c" is not much harder than "a/b/c". Anyway hard coded file
names appear only in sample programs. In production code a literal path
were unusable anyway, because it is non-portable. So it should be

   Create (File, My_Documents_Directory / "text" / Text_Content);

which under Windows would yield file path encoded UTF-16:

   "C:\Documents and Settings\Winnie the Pooh\My Documents\text.txt"

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

Re: What about a glob standard method in Ada.Command_Line ?

[Georg Bauhaus]

On 9/2/10 9:08 PM, Randy Brukardt wrote:

>> 2. do with the names what I want after they have been read:
>
> Why is such a Matcher routine necessary?

Not really, my overloaded subp was a quick attempt at removing
implementation-defined and replacing it with something
that allows all kinds of control over the results, i.e. the
next file name is good or not. The callback should just place
the file name testing loop inside (Start_)Search, as a way to keep
the directory searching loop free from the matching stuff
(like Pattern, only with more power).

OTOH, much of my argument in favor of full power String matching
is based on the (presumed) fact that file system names are
basically like vegetables. There will be specks, some rotten,
and molds, as mentioned. But you still want to eat them, without
exception, when you are hungry and they represent the notion
of edible food.[*]  That leaves the question why having implementation-
defined stuff isn't called for anyway.
(Any I rarely hope for the bits returned by the files system routines
to always permit 1:1 mappings to Unicode character sequences in
whatever representation. )
  
File systems capable of optimizing directory scanning when they
know part or the file name add to an argument in favor of
implementation defined.

So for me, the heated discussion boils down to a callback
(or generic formal function) that might or might not express a
file name filter well---one nesting level less if you compare  it
to a loop with a filtering conditional in it.


Georg

[*] http://www.fsis.usda.gov/factsheets/molds_on_food/#2