RE: rename missing in Text_IO

RE: rename missing in Text_IO

[Beard, Frank]

But why not be part of the standard, maybe in an Annex.  I
almost sympathize with what Ted's saying.  But by his reasoning,
Ada.Command_Line shouldn't be provided either, because the OS
has an interface to do it.  For that matter, none of the IO should
be there because we could pragma interface to all those routines.

I would love to see file handling expanded.  Renaming a file
should be there just as the Delete is there.  Why not have all
the common file operations available.  I think you should be able
to do locking, file or record, from within the language standard.
Getting a directory list should be there too.

Frank

-----Original Message-----
From: Ted Dennison [mailto:dennison@telepath.com]
Sent: Friday, May 04, 2001 9:43 AM
To: comp.lang.ada@ada.eu.org
Subject: Re: rename missing in Text_IO


In article <3af28c5a.12778070@news.nl.uu.net>, Noam Kloos says...

>I just played with filtering some textfiles and found there is no
>function to rename a file;

That's right. There's no function to delete a file, or list a directory
either.
That's all stuff that's considered part of the OS, and thus you are expected
to
make the appropriate OS calls for your platform. Most of the time, your Ada
vendor will have supplied a package that has bindings to those OS calls, but
what it is depends on your vendor and platform.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com
_______________________________________________
comp.lang.ada mailing list
comp.lang.ada@ada.eu.org
http://ada.eu.org/mailman/listinfo/comp.lang.ada

Re: rename missing in Text_IO

[Pascal Obry]

"Beard, Frank" <beardf@spawar.navy.mil> writes:

> I would love to see file handling expanded.  Renaming a file
> should be there just as the Delete is there.  Why not have all

Note that Delate is there but taking a File_Type as argument. Do you really
want to open the file to be able to delete it ? I would say no in the general
case and we really need a Delete/Rename with a string argument.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|         http://perso.wanadoo.fr/pascal.obry
--|
--| "The best way to travel is by means of imagination"

Re: RE: rename missing in Text_IO

[Ted Dennison]

In article <mailman.989009524.30396.comp.lang.ada@ada.eu.org>, Beard, Frank
says...
>But why not be part of the standard, maybe in an Annex.  I
>almost sympathize with what Ted's saying.  But by his reasoning,
>Ada.Command_Line shouldn't be provided either, because the OS
>has an interface to do it.  For that matter, none of the IO should
>be there because we could pragma interface to all those routines.
..
>From: Ted Dennison [mailto:dennison@telepath.com]
>That's all stuff that's considered part of the OS, and thus you are expected
>to make the appropriate OS calls for your platform. Most of the time, your Ada
>vendor will have supplied a package that has bindings to those OS calls, but
>what it is depends on your vendor and platform.

Hey, I never said it was a Good Thing. I just said that this is the way it is.
For a beginner, that's the main issue.

I actually think it may well be a good thing to have some kind of Ada.C_Library
package hierarchy in an annex in some future version of the language for stuff
like that, since the C library realisticly is going to be available on most Ada
platforms. Perhaps an Ada.Directory_Operations would be a good idea too. Heck,
I'd even like to see a GUI in the standard, if its possible to agree on a good
one.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: RE: rename missing in Text_IO

[Keith Thompson]

Ted Dennison<dennison@telepath.com> writes:
[...]
> I actually think it may well be a good thing to have some kind of
> Ada.C_Library package hierarchy in an annex in some future version
> of the language for stuff like that, since the C library realisticly
> is going to be available on most Ada platforms. Perhaps an
> Ada.Directory_Operations would be a good idea too.

I think the Ada/POSIX binding covers most of that.

>                                                    Heck, I'd even
> like to see a GUI in the standard, if its possible to agree on a
> good one.

I don't think it is.  8-)}

-- 
Keith Thompson (The_Other_Keith) kst@cts.com  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center           <*>  <http://www.sdsc.edu/~kst>
Cxiuj via bazo apartenas ni.

Re: rename missing in Text_IO

[Noam Kloos]

On Fri, 04 May 2001 21:21:35 GMT, Ted Dennison<dennison@telepath.com>
wrote:

>In article <mailman.989009524.30396.comp.lang.ada@ada.eu.org>, Beard, Frank

>I actually think it may well be a good thing to have some kind of Ada.C_Library
>package hierarchy in an annex in some future version of the language for stuff
>like that, since the C library realisticly is going to be available on most Ada
>platforms. Perhaps an Ada.Directory_Operations would be a good idea too. Heck,
>I'd even like to see a GUI in the standard, if its possible to agree on a good
>one.
>
>---
>T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
>          home email - mailto:dennison@telepath.com

There is for the gnat ada compiler the g-dirop.ads
gnat.directory_operations

Noam.

RE: rename missing in Text_IO

[Larry Kilgallen]

In article <mailman.989009524.30396.comp.lang.ada@ada.eu.org>, "Beard, Frank" <beardf@spawar.navy.mil> writes:
> But why not be part of the standard, maybe in an Annex.  I
> almost sympathize with what Ted's saying.  But by his reasoning,
> Ada.Command_Line shouldn't be provided either, because the OS
> has an interface to do it.  For that matter, none of the IO should
> be there because we could pragma interface to all those routines.
> 
> I would love to see file handling expanded.  Renaming a file
> should be there just as the Delete is there.

Unlike Delete, the legality of Rename is going to vary from operating
system to operating system.  If you rename into a different directory
on VMS, that directory must be on the same physical disk.  With rooted
directories, begin on the same disk is not obvious by comparing the old
and new filespecs.

Re: rename missing in Text_IO

[David Starner]

On 4 May 2001 18:38:04 -0500, Larry Kilgallen <Kilgallen@eisner.decus.org.nospam> wrote:
> Unlike Delete, the legality of Rename is going to vary from operating
> system to operating system.  If you rename into a different directory
> on VMS, that directory must be on the same physical disk.  With rooted
> directories, begin on the same disk is not obvious by comparing the old
> and new filespecs.

This is true on Unix too. 

-- 
David Starner - dstarner98@aasaa.ofe.org
Pointless website: http://dvdeug.dhis.org
"I don't care if Bill personally has my name and reads my email and 
laughs at me. In fact, I'd be rather honored." - Joseph_Greg

Re: rename missing in Text_IO

[Charles Hixson]

dvdeug@x8b4e53cd.dhcp.okstate.edu (David Starner) wrote in
<9cvdav$8q61@news.cis.okstate.edu>: 

>On 4 May 2001 18:38:04 -0500, Larry Kilgallen
><Kilgallen@eisner.decus.org.nospam> wrote: 
>> Unlike Delete, the legality of Rename is going to vary from
>> operating system to operating system.  If you rename into a
>> different directory on VMS, that directory must be on the
>> same physical disk.  With rooted directories, begin on the
>> same disk is not obvious by comparing the old and new
>> filespecs. 
>
>This is true on Unix too. 
>

I thought that the *nix rename command was mv ... if so, then it 
will move between disks, and I think it just renames within the 
same disk (it's been years since I looked into the details, but 
that's the way that I remember).  Of course, that's at the 
command level.  I suppose that there are system calls 
implemented at a lower level, but what's wrong with making a 
move/rename command available in a Ada.File.Stdoperations 
package in Annex F as a defined part of the standard.  It 
probably shouldn't be mandatory, but there's no particular 
reason not to define "the standard approach", and let those 
implement it who will.

Actually, I feel that most of the truly standard library 
functions should be defined as a part of the standard.  The 
fragmentation that Eiffel has experienced due to incompatible 
libraries between differnet versions is a large part of this 
reason.  The strengthening that C++ has received from the 
standard template library is another part.  (I don't use C++, 
but I certainly hear about it... and the STL has been receiving 
plaudits as an enabler, even from those who don't like some 
feature or other of it.)

It's not as if most of the work hasn't already been done.  There 
are lists in several forms, and red-black trees, and B-Trees, 
and... well, lots.  Most of the truely basic structures.  
Perhaps the problem is that they've all been done by different 
people, or that the Booch components seem to be all that's 
needed or ..., whatever.  

I'm not used to the Booch components, so perhaps they are all 
that's needed.  But if so then I think that they ought to be 
specified at least to the API level as a part of the standard.  
Personally, when I looked at them, I couldn't see how to get 
back an element after I had stored it in a container.  But I'm 
sure that there must be a way, and if that's the best structure 
design, then that's what it is.


-- 
Charles Hixson

Copy software legally, the GNU way!
Use GNU software, and legally make and share copies of software.
See http://www.gnu.org
    http://www.redhat.com
    http://www.linux-mandrake.com
    http://www.calderasystems.com/
    http://www.linuxapps.com/

Re: rename missing in Text_IO

[David Starner]

On Tue, 08 May 2001 22:03:54 GMT, Charles Hixson <charleshixson@earthling.net> wrote:
> dvdeug@x8b4e53cd.dhcp.okstate.edu (David Starner) wrote in
><9cvdav$8q61@news.cis.okstate.edu>: 
> 
>>On 4 May 2001 18:38:04 -0500, Larry Kilgallen
>><Kilgallen@eisner.decus.org.nospam> wrote: 
>>> Unlike Delete, the legality of Rename is going to vary from
>>> operating system to operating system.  If you rename into a
>>> different directory on VMS, that directory must be on the
>>> same physical disk.  With rooted directories, begin on the
>>> same disk is not obvious by comparing the old and new
>>> filespecs. 
>>
>>This is true on Unix too. 
> 
> I thought that the *nix rename command was mv ... 
[...]
> Of course, that's at the 
> command level.  I suppose that there are system calls 
> implemented at a lower level, 

I understood him to be talking about system calls, and the unix
system call 'rename' works the same way he was describing VMS
Rename to work.

-- 
David Starner - dstarner98@aasaa.ofe.org
Pointless website: http://dvdeug.dhis.org
"I don't care if Bill personally has my name and reads my email and 
laughs at me. In fact, I'd be rather honored." - Joseph_Greg

Re: rename missing in Text_IO

[Charles Hixson]

dvdeug@x8b4e53cd.dhcp.okstate.edu (David Starner) wrote in
<9da0p9$7hu2@news.cis.okstate.edu>: 

>On Tue, 08 May 2001 22:03:54 GMT, Charles Hixson
>...
>I understood him to be talking about system calls, and the
>unix system call 'rename' works the same way he was
>describing VMS Rename to work.
>

But if what we are considering is what an Ada Library Package 
should look like, then there's no reason to copy the low level 
features of an operating system.  And the semantics of the mv 
command is generally superior.  A program should not need to 
know the details of the disk layout.  In fact, I'm not sure that 
on all systems the normal user (as opposed to a superuser) is 
even able to determine those details.  So I definitely don't 
think that the standard library should assume that this can be 
determined when there is no real need.  Of course, if the source 
were on a CD, then neither approach would work, but that's what 
one would expect if the file/volume were read/only.

-- 
Charles Hixson

Copy software legally, the GNU way!
Use GNU software, and legally make and share copies of software.
See http://www.gnu.org
    http://www.redhat.com
    http://www.linux-mandrake.com
    http://www.calderasystems.com/
    http://www.linuxapps.com/

Re: rename missing in Text_IO

[Fraser Wilson]

charleshixson@earthling.net (Charles Hixson) writes:

> But if what we are considering is what an Ada Library Package 
> should look like, then there's no reason to copy the low level 
> features of an operating system.  And the semantics of the mv 
> command is generally superior.  A program should not need to 
> know the details of the disk layout. 

The problem is that a rename or move on the same disk is significantly
cheaper than one that crosses disks.  It's also a much safer
operation.  I think the implementation detail line is quite fuzzy
here.

More generally, the destination might not even be a disk filesystem;
it could be a remote ftp site or /proc on Linux.  Does a move/rename
even make sense in those cases?

Fraser.

Re: rename missing in Text_IO

[Charles Hixson]

Fraser Wilson <blancolioni@blancolioni.org> wrote in
<fy73daefabm.fsf@blancolioni.org>: 

>charleshixson@earthling.net (Charles Hixson) writes:
>
>> But if what we are considering is what an Ada Library
>> Package should look like, then there's no reason to copy
>> the low level features of an operating system.  And the
>> semantics of the mv command is generally superior.  A
>> program should not need to know the details of the disk
>> layout. 
>
>The problem is that a rename or move on the same disk is
>significantly cheaper than one that crosses disks.  It's also
>a much safer operation.  I think the implementation detail
>line is quite fuzzy here.
>
>More generally, the destination might not even be a disk
>filesystem; it could be a remote ftp site or /proc on Linux. 
>Does a move/rename even make sense in those cases?
>
>Fraser.
>

It makes as much sense in those cases as in other read-only 
cases (unless you have read/write access to the ftp site, in 
which case I would say, "Yes, it makes sense, but wouldn't copy 
be a better choice?")  I do think that basic characteristics of 
the file are reasonable to be able to determine, I just don't 
think that they should be mandatory.  Among these 
characteristics I would include "Is it a local file?", "How big 
is it?", "Can you write to it?",  "Can you seek within it?", 
"Can you write within it, without destroying everything that 
follows the write location?", "Who is the owner?", "When was it 
last changed?", etc.  All the standard file status questions.

The thing is, to each of these questions, "I don't know." has to 
be a valid answer.  Perhaps it would be an unusual answer, but 
it needs to be possible.  This is what would make a really 
portable package possible.  (It would be trivial to port a 
package that just answered "I don't know." whatever you asked 
it.  Not particularly useful, but trivial.)  What your program 
should do in response to "I don't know" is less clear.  Perhaps 
it should ask the user?

-- 
Charles Hixson

Copy software legally, the GNU way!
Use GNU software, and legally make and share copies of software.
See http://www.gnu.org
    http://www.redhat.com
    http://www.linux-mandrake.com
    http://www.calderasystems.com/
    http://www.linuxapps.com/

Re: rename missing in Text_IO

[Ted Dennison]

In article <fy73daefabm.fsf@blancolioni.org>, Fraser Wilson says...
>The problem is that a rename or move on the same disk is significantly
>cheaper than one that crosses disks.  It's also a much safer
>operation.  I think the implementation detail line is quite fuzzy
>here.
>
>More generally, the destination might not even be a disk filesystem;
>it could be a remote ftp site or /proc on Linux.  Does a move/rename
>even make sense in those cases?

I think its probably OK to leave that on the user's head. After all, they're the
one who *asked* for a move to that location. We already have a similar issue
with Open. It may or may not work if another program or another task has already
opened the file (and it may depend on the mode they opened it with). All that is
OS dependant. Also, the user could try to Create a file on "/proc" as it stands
today, so "Move" would introduce no new issues there either. The fact is that
the user of file I/O operations already has to understand a fair bit about their
OS to have any hope of it working properly.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

RE: RE: rename missing in Text_IO

[Beard, Frank]

I'm apologize if I misunderstood you, but I've heard similar things from
others, including some vendors, and assumed that's what you meant.  One of
the vendors told me (highly paraphrased) they basically wait to see where
the market goes and then make bindings to the interfaces.  So, they're
always in a state of catch-up.

As far as Ada.C_Library, I wasn't thinking along those lines.  As a
matter of fact, I wouldn't really even want to make the connection
between the things I want provided in the language and their C counter
parts.  I was thinking more along the lines of your other suggestion,
such as Ada.Directory_Operations, Ada.File_Operations, etc.

Even if the C version is there first, hide that from me.  Take a good
idea and make it better with Ada.  

Frank

-----Original Message-----
From: Ted Dennison [mailto:dennison@telepath.com]
Sent: Friday, May 04, 2001 5:22 PM
To: comp.lang.ada@ada.eu.org
Subject: Re: RE: rename missing in Text_IO


In article <mailman.989009524.30396.comp.lang.ada@ada.eu.org>, Beard, Frank
says...
>But why not be part of the standard, maybe in an Annex.  I
>almost sympathize with what Ted's saying.  But by his reasoning,
>Ada.Command_Line shouldn't be provided either, because the OS
>has an interface to do it.  For that matter, none of the IO should
>be there because we could pragma interface to all those routines.
..
>From: Ted Dennison [mailto:dennison@telepath.com]
>That's all stuff that's considered part of the OS, and thus you are
expected
>to make the appropriate OS calls for your platform. Most of the time, your
Ada
>vendor will have supplied a package that has bindings to those OS calls,
but
>what it is depends on your vendor and platform.

Hey, I never said it was a Good Thing. I just said that this is the way it
is.
For a beginner, that's the main issue.

I actually think it may well be a good thing to have some kind of
Ada.C_Library
package hierarchy in an annex in some future version of the language for
stuff
like that, since the C library realisticly is going to be available on most
Ada
platforms. Perhaps an Ada.Directory_Operations would be a good idea too.
Heck,
I'd even like to see a GUI in the standard, if its possible to agree on a
good
one.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com
_______________________________________________
comp.lang.ada mailing list
comp.lang.ada@ada.eu.org
http://ada.eu.org/mailman/listinfo/comp.lang.ada

Re: RE: rename missing in Text_IO

[Marin David Condic]

Yes sir! Very much so sir!

Every time I have to dip into the Win32ada interfaces to get at Windoze, I
wish I had an ever-so-slightly thicker binding that simply had its own
parameter passing and data typing and all that so I don't have to deal with
all the long chains of types & subtypes and ridiculous parameters that the C
calls impose. Just clean it up and make it Ada-ish.

Above that, one can always build a thicker binding such as what one might
find in Claw. But at least let me connect to the bare OS using The Ada Way
rather than C. Typically, I roll my own, but I only do so for the packages I
need at the moment. It would be nice to have one for the whole interface -
especially when it gets hard to understand what the C functions are doing
with the parameters. (Ada is ***SOOOOO*** much nicer in the way it passes
parameters!)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Beard, Frank" <beardf@spawar.navy.mil> wrote in message
news:mailman.989012885.31301.comp.lang.ada@ada.eu.org...
> Even if the C version is there first, hide that from me.  Take a good
> idea and make it better with Ada.
>

Re: RE: rename missing in Text_IO

[Ted Dennison]

In article <9d6ahn$157$1@nh.pace.co.uk>, Marin David Condic says...
>Every time I have to dip into the Win32ada interfaces to get at Windoze, I
>wish I had an ever-so-slightly thicker binding that simply had its own
>parameter passing and data typing and all that so I don't have to deal with
>all the long chains of types & subtypes and ridiculous parameters that the C

I just flat out don't do it. The only thing (IMHO) the Win32Ada bindings (or any
other "thin bindings") are good for is a reference to the correct type sizes and
calling convention for a pragma Interface, which I will hide down in the body of
my own package. Even there, you're often better going to the C API's docs, as
they give much more detail about how an object is used and what is expected of
it. If you try to use the C types and error return values that a thin binding
provides you directly, they often end up spreading themselves (and the C style
their use requires) throughout your code like a cancer.

I'd like to take this opportunity to volunteer my services as a Win32 "thick
binding coordinator", since I can't seem to con anyone else into taking the job.
:-)  Anyone who has developed their own thick Win32 binding for some particular
Win32 facility, and has the legal right to allow their redistribution under the
GMGPL, feel free to email what you have to me. As mentioned before, I already
have bindings developed for WinNT/2K "services", process creation/control,
registry operations, and I am working on NT/2K's registry based "performance
data". They are currently only available under the GPL as part of the SETI@Home
Service (see the link on my website), but that will change soon.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: RE: rename missing in Text_IO

[Marin David Condic]

"Ted Dennison" <dennison@telepath.com> wrote in message
news:WazJ6.4532$vg1.353081@www.newsranger.com...
> I just flat out don't do it. The only thing (IMHO) the Win32Ada bindings
(or any
> other "thin bindings") are good for is a reference to the correct type
sizes and
> calling convention for a pragma Interface, which I will hide down in the
body of
> my own package. Even there, you're often better going to the C API's docs,
as
> they give much more detail about how an object is used and what is
expected of
> it. If you try to use the C types and error return values that a thin
binding
> provides you directly, they often end up spreading themselves (and the C
style
> their use requires) throughout your code like a cancer.
>
Its that cancer - as well as the simple, flat-out pain - that makes me hate
to use the Win32Ada bindings. There's just this huge and nasty collection of
subtypes, etc, that are needed to line up with the Win32api and they are a
ROYAL pain! I typically hide them in the bowels of a coresponding package
that has Ada strings, characters, integers, enumerations, etc., as
parameters. And yes, I too hate the error-code returns and usually resort to
either a set of enumerals for the statuses or exceptions or some combination
thereof.


> I'd like to take this opportunity to volunteer my services as a Win32
"thick
> binding coordinator", since I can't seem to con anyone else into taking
the job.
> :-)  Anyone who has developed their own thick Win32 binding for some
particular
> Win32 facility, and has the legal right to allow their redistribution
under the
> GMGPL, feel free to email what you have to me. As mentioned before, I
already
> have bindings developed for WinNT/2K "services", process creation/control,
> registry operations, and I am working on NT/2K's registry based
"performance
> data". They are currently only available under the GPL as part of the
SETI@Home
> Service (see the link on my website), but that will change soon.
>

I might be willing to help out here, but I'm wondering about proper
guidelines. It wouldn't help much to have a dozen guys each developing
package specs that look substantially different to cover the various parts
of the Win32api. The intelligent thing to do would probably be to parallel
the Win32ada packages. Maybe there's a "Ada_Win32ada" for every "Win32ada"
where the sole job is to Ada-ize the types, parameters, return statuses,
etc. There would need to be some guidelines & examples of how to translate
to something that at least looks fairly regular across all the packages.
Otherwise, we'd just end up with our own proliferation of Ada types,
subtypes, etc.

Ideas?

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/

Re: RE: rename missing in Text_IO

[Ted Dennison]

In article <9d6h07$3b3$1@nh.pace.co.uk>, Marin David Condic says...
>parameters. And yes, I too hate the error-code returns and usually resort to
>either a set of enumerals for the statuses or exceptions or some combination
>thereof.

My current favorite trick is to just raise a single "Foo.Error" exception for
any C error condition in each package. There are obviously some situations where
this would be undesirable, but you'd be suprised how often its sufficient.
Sometimes when extra info might be in order for diagnosis, it can just be put
into the execption message.

>I might be willing to help out here, but I'm wondering about proper
>guidelines. It wouldn't help much to have a dozen guys each developing
>package specs that look substantially different to cover the various parts

Yeah, it would all need to interoperate. That's part of why I wanted to fob the
job off on someone else. My bindings aren't really that good for a base right
now, since a lot of basic Win32 stuff that everyone is liable to use isn't there
(with the notable exception of process id's).

>of the Win32api. The intelligent thing to do would probably be to parallel
>the Win32ada packages. Maybe there's a "Ada_Win32ada" for every "Win32ada"
>where the sole job is to Ada-ize the types, parameters, return statuses,

Nearly all of that crap in Gnat's Win32 package is special String and Void
pointer types that I never pass back to the user anyway. :-)

The problem with doing things this way is that when you abstract away some of
the C cruft, a lot of that organization doesn't make any sense. For instance,
the Windows NT/2K "performance data" that you need to parse to get stuff like a
what executable a process is using, is entirely accomplished using registry
calls. But if abstracted down to something like 
Get_Executable_Name (Process.ID)

Then it doesn't make much sense to put this call in a "Registry" package.

Another issue is that a lot of times the original C libraries aren't very well
organized in the first place. For instance, the Win32 process and thread stuff
is stuck into a huge 8 thousand line header file along with basic File I/O,
serial I/O, process syncronization stuff like pipes and mailslots and
semaphores, object priveleges and ACLs, computer and user names, etc. My current
bindings just have a single "Process" package for Win32 processes. I don't think
I'd want to make a Win32.Base_Services package and put all that crap into it.

>etc. There would need to be some guidelines & examples of how to translate
>to something that at least looks fairly regular across all the packages.
>Otherwise, we'd just end up with our own proliferation of Ada types,
>subtypes, etc.

Generally I try to stick to Strings, Integers, private types, and the odd
enumeration here or there. But some specific guidlines would indeed be required,
or I'm afraid I'd spend all my time redesigning submissions. Ick.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: RE: rename missing in Text_IO

[Marin David Condic]

"Ted Dennison" <dennison@telepath.com> wrote in message
news:BrBJ6.4787$vg1.374667@www.newsranger.com...
> My current favorite trick is to just raise a single "Foo.Error" exception
for
> any C error condition in each package. There are obviously some situations
where
> this would be undesirable, but you'd be suprised how often its sufficient.
> Sometimes when extra info might be in order for diagnosis, it can just be
put
> into the execption message.
>
It might work nicely enough to get the job done. If a function was provided
to return a more detailed error code (the actual return status of the C
function?) that might be enough to get the job done cleanly.


> Yeah, it would all need to interoperate. That's part of why I wanted to
fob the
> job off on someone else. My bindings aren't really that good for a base
right
> now, since a lot of basic Win32 stuff that everyone is liable to use isn't
there
> (with the notable exception of process id's).
>
Its always nicer if you can get someone else to do all the work! :-) I don't
have an easy answer for this other than possibly someone has/had a corporate
need to build the bindings anyway & are willing to give it away.


> Nearly all of that crap in Gnat's Win32 package is special String and Void
> pointer types that I never pass back to the user anyway. :-)
>
> The problem with doing things this way is that when you abstract away some
of
> the C cruft, a lot of that organization doesn't make any sense. For
instance,
> the Windows NT/2K "performance data" that you need to parse to get stuff
like a
> what executable a process is using, is entirely accomplished using
registry
> calls. But if abstracted down to something like
> Get_Executable_Name (Process.ID)
>
Two issues: One is that the Win32ada bindings are not specific to Gnat. They
exist in Aonix as well (& Maybe RR?) & I think they were originally a
product of Averstar - so they're pretty much a common thing. I'm sure you
know this, but given the way you phrased the statement above, it might not
have been clear to someone just now approaching it. (It wouldn't be fair to
blame Gnat for the fact that the Win32api is a turd that no matter how long
you polish it will always remain a turd!)

The other thing is to remember that the whole Win32api was organically grown
at Micro$oft (probably in a damp basement with no light) so it is enormously
internally inconsistent. No getting around that - its someone else's dirty
work. I like abstracting things and have done so with the Winsock calls in
particular. The only problem is that then you're heading off into a much
thicker binding and where do you stop? I'd rather just go with something
like Claw if I wanted to get further away from the absurdities of Win32api.
For some uses, it may be fine just to get a step away from the C-isms of the
Win32api.


> Then it doesn't make much sense to put this call in a "Registry" package.
>
> Another issue is that a lot of times the original C libraries aren't very
well
> organized in the first place. For instance, the Win32 process and thread
stuff
> is stuck into a huge 8 thousand line header file along with basic File
I/O,
> serial I/O, process syncronization stuff like pipes and mailslots and
> semaphores, object priveleges and ACLs, computer and user names, etc. My
current
> bindings just have a single "Process" package for Win32 processes. I don't
think
> I'd want to make a Win32.Base_Services package and put all that crap into
it.
>
As I said - Win32api is a turd. However, your your proposal of consolidating
some of this stuff (wise as it may be) leaves open the question of how thick
a binding do you want to construct? I'd reiterate that it might make sense
to simply have something that was one-step away from the really crappy
C-isms in the Win32ada collection. (At least it would be familiar & would
parallel existing Win32api documentation.) Beyond that another layer of
abstraction may be in order to simplify things in some manner. But that's
just rebuilding Claw. Where do you want to draw the line and say "This far
and no farther?"

> Generally I try to stick to Strings, Integers, private types, and the odd
> enumeration here or there. But some specific guidlines would indeed be
required,
> or I'm afraid I'd spend all my time redesigning submissions. Ick.
>
I agree. Where possible, use the standard types insofar as they align with
the sizes required by the actual calls. Usage of Integer, Float,
(Long_Integer, Long_Float, etc.) Character & String should handle 99% of
everything - probably with some enumerations & exceptions to cover return
statuses. Maybe some hiding of structs within private types makes sense. One
might want to construct some primitive types (Integer_32, Float_64?) just to
guarantee sizes and the overridability of operations.

Maybe an example or two would suffice as a guideline? "Make it look like
this!"

MDC


--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/

Re: RE: rename missing in Text_IO

[tmoran]

> I like abstracting things and have done so with the Winsock calls in
> particular.
  This may be key.  Too thick a binding, no matter how good it might
be, may just not be attractive.  Most people have their own styles
and preferences, and just aren't as comfortable using something
right out of the box.  It's standard marketing that nobody wants
to feel their input consists of putting tab A in slot B.  People
want instead pieces that can be helpful in creating the final product.
Your comment
> managing programmers is like hearding cats... :-)
is relevant here.

Re: RE: rename missing in Text_IO

[tmoran]

>"Ted Dennison" <dennison@telepath.com> wrote in message
>news:BrBJ6.4787$vg1.374667@www.newsranger.com...
>> My current favorite trick is to just raise a single "Foo.Error" exception
>for
>> any C error condition in each package. There are obviously some situations
>where
>> this would be undesirable, but you'd be suprised how often its sufficient.
>> Sometimes when extra info might be in order for diagnosis, it can just be
>put
>> into the execption message.
>>
>It might work nicely enough to get the job done. If a function was provided
>to return a more detailed error code (the actual return status of the C
>function?) that might be enough to get the job done cleanly.
  In Claw we have a very few exceptions, Already_Valid_Error for
instance, plus
    Windows_Error : Exception;  -- An (unusual) error occurred in Windows.
                                -- The exception message for this exception
                                -- always includes the Windows error code.
But in Claw.Sockets, for instance, the windows error code is often
uninteresting, so there is a specific
  procedure Get_Error_Code(Socket     : in out Root_Socket_Type;
                           Error_Code :    out Error_Codes);
  -- Call this after a Windows_Error exception on an operation on Socket.
to get the winsock error code.


>Maybe an example or two would suffice as a guideline? "Make it look like
>this!"
  I'll modestly suggest perusing the Claw docs, an early, incomplete,
but still showing a flavor, work version of which is still posted at
http://members.home.net/twmoran/H1.htm

>Where do you want to draw the line and say "This far and no farther?"
  Perhaps Claw defines what's beyond the line?

Re: RE: rename missing in Text_IO

[Marin David Condic]

Since the discussion started concerning Win32ada simply having way too many
types and way too much C-ish feeling to the parameter lists, etc., my
original idea was to put a relatively simple layer on top of Win32ada. Just
enough so that when a string was called for, you used an Ada string - not
some 2nd or 3rd layer subtype of a pointer to a char - or other equally
unfriendly examples. I wouldn't want to consolidate multiple calls into
single calls or significantly change anything about the interface - so far
as it could be avoided. Just Ada-ize what one sees when one uses the
Win32api. (Some compromises are in order - you'd want to change all the
numeric return statuses into something more Ada-ish like enumerations.
Again, its a question of where does one stop?)

To that end, I'd think that Claw exceeds the spec. Claw is a perfectly fine
tool and one might be quite happy to develop on top of it. I'd think that
there would remain times when one would simply want to get at a single
Win32api call without any other layers of abstraction beyond making the
thing not quite so agonizing to use from an Ada perspective.

Claw may be a better answer for overall development, but I was kind of
thinking along the lines of something that would be freely available as a
blanket over the Win32ada binding. Sort of a "binding to a binding". (Now we
could start the GPL vs LGPL vs GMGPL debate along a whole new thread! :-)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


<tmoran@acm.org> wrote in message
news:mLKJ6.43239$Jh5.41288199@news1.rdc1.sfba.home.com...
> >Where do you want to draw the line and say "This far and no farther?"
>   Perhaps Claw defines what's beyond the line?

Re: RE: rename missing in Text_IO

[tmoran]

>I'd like to take this opportunity to volunteer my services as a Win32
>"thick binding coordinator", ...
>... As mentioned before, I already have bindings developed for ...
  www.adapower.com also lists:
Claw       2.7 MB (free for non-commerical use)
           5.8 MB + examples, docs, and GUI Builder, $>0
Windex     2.4 MB
GWindows   1.3 MB
Jewl        .9 MB
  Perhaps "thick binding coordination" would fit nicely in the
Ada Bindings Working Group?

I suspect it is currently difficult to mix different parts of these
bindings.  Maybe part of "coordination" should be development of
ways to switch between, or mix and match, instead of being locked in
to one particular binding.

BTW, one of the major, but rarely mentioned, advantages of a thick
binding is that someone else has tracked down the obscurities,
ambiguities, MS doc errors, etc to find out what the various API
calls actually do, and how they need to hang together.  The thinner
the binding, the more of that you get to do yourself.  ;)

Re: RE: rename missing in Text_IO

[Ted Dennison]

In article <mLKJ6.43240$Jh5.41288728@news1.rdc1.sfba.home.com>, tmoran@acm.org
says...
>  Perhaps "thick binding coordination" would fit nicely in the
>Ada Bindings Working Group?

I'd go for that. As I said, my main interest is in fobbing this job off on
someone else. :-)

>BTW, one of the major, but rarely mentioned, advantages of a thick
>binding is that someone else has tracked down the obscurities,
>ambiguities, MS doc errors, etc to find out what the various API
>calls actually do, and how they need to hang together.  The thinner

Likewise, one of the major, but rarely mentioned, advantages to *writing* a
thick binding is that you become quite well acquainted with the API in question.
:-)

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: RE: rename missing in Text_IO

[Randy Brukardt]

In article <9d6ahn$157$1@nh.pace.co.uk>, Marin David Condic says...
>Every time I have to dip into the Win32ada interfaces to get at
Windoze, I
>wish I had an ever-so-slightly thicker binding that simply had its own
>parameter passing and data typing and all that so I don't have to deal
with
>all the long chains of types & subtypes and ridiculous parameters that
the C

R.R.'s Win32 bindings (which predate Win32Ada) were designed exactly
that way, and for exactly that reason. There even was a project to
create a public version of them ("just thick enough" - named "MAWB" for
Medium Ada Windows Binding), but that ended up going nowhere when people
adopted Win32Ada instead.

We ended up stopping development on it in favor of a thicker binding
(which now is Claw). (Claw includes lots of stuff outside of pure GUI
functions, including sockets, registry operations [including
common-high-level operations such as registering a file extension], and
directory operations.

            Randy.

(P.S. I posted this message last week, but I don't think it ever got
posted. Apologies to anyone that sees it twice.)