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: rename missing in Text_IO

[Beard, Frank]

-----Original Message-----
From: Fraser Wilson [mailto:blancolioni@blancolioni.org]

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

So what?  If I need to move it to another disk, then I need to move
it to another disk.  I don't think the cost would be the issue in that
case.  If cost is the issue, which would be determined either by 
prototyping or performance testing, then keep it on the same disk.

> I think the implementation detail line is quite fuzzy here.

POSIX figured it out in some reasonable manner.

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

You wouldn't be using the move/rename in this case anyway, would you?
Probably an RPC command, which is another Annex for discussion.

Frank

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]

>"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: rename missing in Text_IO

[Stephen Leake]

"Marin David Condic" <marin.condic.auntie.spam@pacemicro.com> writes:

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

That was the original philosophy of Windex. I may have gone beyond
that some in developing whole new controls.

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

It would be interesting to hear which parts of Claw you think are "too
thick". My nomination for that category is its use of a hidden task to
serialize access to the GUI. On the other hand, I have not yet
succeeded in building a multi-tasking Windex app, so I can't really
complain! 

> 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! :-)

Windex is _not_ built on top of the Win32Ada binding, and neither is
Claw. Part of the reason is licensing; the Win32Ada binding is
actually copyright by Microsoft, since it was built by automatic
translation from their C source. It is _not_ "freely distributable";
the license terms state that you must own a Microsoft development
environment to use Win32Ada. Windex is GMGPL.

The other part of the reason is that there is lots of stuff in Win32
that should not be used; either because it is superceded by other
parts of Win32, or there is a better Ada way.

I haven't worked on Windex in quite a while. I'll probably make
another release when GNAT 3.14p comes out, but I don't anticipate much
beyond that. I just don't seem to have the urge to write Win32 apps
any more; I may do something for my latest toy, a Palm handheld.

-- 
-- Stephe

Re: rename missing in Text_IO

[Marin David Condic]

"Stephen Leake" <stephen.a.leake.1@gsfc.nasa.gov> wrote in message
news:uheyuzn0y.fsf@gsfc.nasa.gov...
> It would be interesting to hear which parts of Claw you think are "too
> thick". My nomination for that category is its use of a hidden task to
> serialize access to the GUI. On the other hand, I have not yet
> succeeded in building a multi-tasking Windex app, so I can't really
> complain!
>
Never said Claw was "too thick". What I said was that it didn't meet the
specification of being simply an Ada equivalent to the Win32api. I think
we'd both agree that Claw provides a bit more than what you would see from
Win32ada. It does a bit more than just wrap Ada-isms around the Win32api. I
don't object to that at all - far from it. I just don't think it is the
answer to having a slightly more than "thin" binding to the Win32api. (Also,
it isn't likely to end up distributed with all of the Ada/PC targeted
compilers.)

I wish I had a correct term for this kind of binding. "Thick" kind of
implies you've packaged something up to provide similar {rather than
identical} services, but in a more friendly way. "Thin" kind of implies that
it is just a set of hooks to the routines to provide absolutely identical
services from another language - right down to matching data types, etc.
There ought to be a word for a binding that provides identical services, but
smooths over the things that don't translate well from C to Ada. (A thin
binding with "software spackle"? :-) Arguably, that ought to be a "thick"
binding with something like Claw becoming a "subsystem" - it provides
similar and *extended* services.

> Windex is _not_ built on top of the Win32Ada binding, and neither is
> Claw. Part of the reason is licensing; the Win32Ada binding is
> actually copyright by Microsoft, since it was built by automatic
> translation from their C source. It is _not_ "freely distributable";
> the license terms state that you must own a Microsoft development
> environment to use Win32Ada. Windex is GMGPL.
>
Fair enough. My casual attitude towards precise writing may once again have
me in trouble! :-) Let me say this: The Ada compilers that I've seen
targeted to Windows/PCs have all come with the Win32ada bindings. I don't
know of any that don't - maybe you know of one? Hence (even if it isn't a
"standard") I could go off and develop a Spackle Binding (tm) that "withed"
the Win32ada stuff and pretty much be asured it would work any place I
needed it to.

One could develop a Spackle Binding (tm) that had in the package body all of
the same sorts of pragmas, etc. one finds in the Win32ada binding and sort
of reverse engineer the Win32api. That would probably not infringe on
anyone's copyright or license. But if Win32ada exists everywhere I'd want to
compile my stuff, is that really necessary?

> The other part of the reason is that there is lots of stuff in Win32
> that should not be used; either because it is superceded by other
> parts of Win32, or there is a better Ada way.
>
Yes - many aspects of Win32api are Morally Evil and should be avoided like
cigarettes, whisky & wild women. Still, if one wants to make a binding to
it, one ought to be thorough so that Joe Programmer who is familiar with
Win32api can find whatever he might be used to using. Tough call. At some
point you're no longer making a binding - but a subsystem. Its not a *bad*
thing to make a subsystem, but I'd probably do it in layers -the binding is
the binding and the simplification of services rides on top of that.

> I haven't worked on Windex in quite a while. I'll probably make
> another release when GNAT 3.14p comes out, but I don't anticipate much
> beyond that. I just don't seem to have the urge to write Win32 apps
> any more; I may do something for my latest toy, a Palm handheld.
>
Perhaps Windex fits the bill. I've not looked it over. The rest of it comes
down to how freely available it is for use. That starts moving from
technical questions to business & legal questions.

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: rename missing in Text_IO

[tmoran]

>... that ought to be a "thick" binding with something like Claw
>becoming a "subsystem" - it provides similar and *extended* services.
  I'm not used to using the word "subsystem" that way.  e.g, in
Orbitals (www.adapower.com) there is a child of a window type where
the additional data is 3D graphic stuff which is displayed in user
selectable mono or stereo and can be rotated by mouse movements,
quite independently of the data generating program.  I would call
that a "subsystem" since it is a system in itself, and clearly a
distinct separate part of the entire app-system.  It is an extension
of a simple "window", but not an extension of Windows.  But that
does leave me with no simple word connoting a certain thickness
layer of a binding.

RE: rename missing in Text_IO

[Beard, Frank]

Yes, I realize that, but you're talking about a system dependency
which is a separate issue from the logical operations.  I don't
remember that limitation on VMS, but I haven't been on that OS in
twelve years.

But, if that is the case, then the operation would simply raise 
something like USE_ERROR to indicate a problem.  The developer on that
OS would need to know the system well enough to know that limitation.

And just because it varies doesn't mean it shouldn't be done.  The
Posix binding for VMS had a rename in it.  I hate to keep going back
to the same example, but the same argument can be made, and was made,
for Ada.Command_Line.  It varies from system to system, and doesn't
even exist on some.


-----Original Message-----
From: Kilgallen@eisner.decus.org.nospam

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.

_______________________________________________
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

[Beard, Frank]

I totally agree!
Frank

-----Original Message-----
From: Pascal Obry [mailto:p.obry@wanadoo.fr]
Sent: Friday, May 04, 2001 5:08 PM
To: comp.lang.ada@ada.eu.org
Subject: Re: rename missing in Text_IO



"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"
_______________________________________________
comp.lang.ada mailing list
comp.lang.ada@ada.eu.org
http://ada.eu.org/mailman/listinfo/comp.lang.ada

rename missing in Text_IO

[Noam Kloos]

Hi,

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

Noam Kloos.

Re: rename missing in Text_IO

[Ted Dennison]

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

Re: rename missing in Text_IO

[Noam Kloos]

>That's right. There's no function to delete a file, or list a directory either.

In Ada.Text_IO on my GNAT compilers on linux and win98 there is a call
Delete(<filehandle>) and you use it instead of close(<filehandle)

Noam.

Re: rename missing in Text_IO

[Ted Dennison]

In article <3af2b3e1.22898679@news.nl.uu.net>, Noam Kloos says...
>
>
>>That's right. There's no function to delete a file, or list a directory either.
>
>In Ada.Text_IO on my GNAT compilers on linux and win98 there is a call
>Delete(<filehandle>) and you use it instead of close(<filehandle)


Dooooh! You're right. There is indeed a Delete. It was even there back in the
Ada83 days. (sigh)

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

Re: rename missing in Text_IO

[Noam Kloos]

On Fri, 04 May 2001 13:43:27 GMT, Ted Dennison<dennison@telepath.com>
wrote:

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

I did a workaround for the rename effect.
see my zip file http://www.noam.nl/download/stripit.zip
I read  a file into a new one, then delete the sourcefile and close
the destinationfile with the different name.

Noam.

Re: rename missing in Text_IO

[Florian Weimer]

serious@clerk.com (Noam Kloos) writes:

> I did a workaround for the rename effect.
> see my zip file http://www.noam.nl/download/stripit.zip
> I read  a file into a new one, then delete the sourcefile and close
> the destinationfile with the different name.

This works only on some platforms.  I don't think it will give the
expected result on MacOS or VMS.