Sequential_IO

Sequential_IO

[Shawn Barber]

I am using Sequential_IO to read some data from a file. Why 
do I need to specify the full path of the file being read 
when I'm running the program from the directory in which the 
file resides? I'm getting the filename from the command line 
and in I continually get a Name_Error unless I specify the 
path as well. Any ideas? I didn't see anything in the LRM, 
but that doesn't mean it's not there. Thanks.

Shawn

* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!

Re: Sequential_IO

[Ted Dennison]

In article <0a0133f8.48529b21@usw-ex0102-014.remarq.com>,
  Shawn Barber <SbarberNOxvSPAM@snet.net> wrote:
> I am using Sequential_IO to read some data from a file. Why
> do I need to specify the full path of the file being read
> when I'm running the program from the directory in which the
> file resides? I'm getting the filename from the command line
> and in I continually get a Name_Error unless I specify the
> path as well. Any ideas? I didn't see anything in the LRM,
> but that doesn't mean it's not there. Thanks.

If you don't see anything in the LRM about it, that usaually means its
compiler/OS dependent. In this case it certianly is. So your question is
completely meaningless w/o knowing your compiler and OS and exactly
what you do to run the program.

If I had to take a wild stab at it, I'd say you are using a compiler
with an IDE (eg: ObjectAda for Windows) and you aren't really running
your program from where you think you are running it.

--
T.E.D.


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Sequential_IO

[Marin David Condic]

Shawn Barber wrote:

> I am using Sequential_IO to read some data from a file. Why
> do I need to specify the full path of the file being read
> when I'm running the program from the directory in which the
> file resides? I'm getting the filename from the command line
> and in I continually get a Name_Error unless I specify the
> path as well. Any ideas? I didn't see anything in the LRM,
> but that doesn't mean it's not there. Thanks.

You need to specify the compiler/version and target operating system/version.
The connection to a file is inherently dependent on the operating system and the
compiler implementation and therefore cannot be spelled out specifically as part
of the language standard.

Using GNAT 3.11p on a PC/NT platform, I seem to be able to open up files in the
default directory using Sequential_IO. If you look on my website, in the Ada
Programming page, you will find a chop file filled with small example programs -
one of which uses Sequential_IO. The URL to get there directly is:
http://www.mcondic.com/gnat_examples.txt These have also been used on Unix
platforms, but I have not done so lately & couldn't testify to the exact version
of anything there. You might look it over to see if your code is doing something
similar.

Note: You might also want to post a small example concerning exactly how you are
reading in the string with the filename and how you are passing that to the
Create/Open since there is some chance you are not correctly passing the string
around. If you aren't trimming the unread parts of the string away, you may be
passing garbage data along with the name which causes the Name_Error.

MDC
--
Marin David Condic
Real Time & Embedded Systems, Propulsion Systems Analysis
United Technologies, Pratt & Whitney, Large Military Engines
M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600
***To reply, remove "bogon" from the domain name.***

Visit my web page at: http://www.mcondic.com/

Re: Sequential_IO

[Larry Kilgallen]

In article <0a0133f8.48529b21@usw-ex0102-014.remarq.com>, Shawn Barber <SbarberNOxvSPAM@snet.net> writes:
> I am using Sequential_IO to read some data from a file. Why 
> do I need to specify the full path of the file being read 
> when I'm running the program from the directory in which the 
> file resides? I'm getting the filename from the command line 
> and in I continually get a Name_Error unless I specify the 
> path as well. Any ideas? I didn't see anything in the LRM, 
> but that doesn't mean it's not there. Thanks.

I would presume (always a bad thing with the LRM) that the
binding of file names to any sort of operating system element
such as a disk file is up to the implementor of the Ada system.
My hope would be that implementors would do what is natural for
whatever operating system (if any) is being used.  There are some
operating systems under which the behaviour you want would not
be logical, so for a better discussion you might want to name
your operating system and Ada implementation.

Larry Kilgallen

Re: Sequential_IO

[Marin David Condic]

Shawn Barber wrote:

> -----------------------------------------------------------
>       -- Get the parameters entered on the command line.
>    Get_Command_Line_Parameters
>       ( NVM_File_Name    => NVM_Input_File_Name  ,
>         NVM_Name_Length  => Length_Of_NVM_Name   ,
>         Memory_Address   => Memory_Start_Address ,
>         DBG_File_Name    => DBG_Output_File_Name ,
>         DBG_Name_Length  => Length_Of_DBG_Name   ) ;
>
>       -- Open the output file.
>    text_io.create
>       ( File => Output_File           ,
>         Mode => text_io.out_file      ,
>         Name => DBG_Output_File_Name  ) ;

Just a quick shot in the dark, because it looked wrong & may be the simple
explanation:

Try: Name => DBG_Output_File_Name (1..Length_Of_DBG_Name) ) ;

You are otherwise referencing the whole string and it may have trailing garbage
in it. AFAIK, GNAT 3.11p has no problem opening up a file in the current
directory when you execute it from the command line. (As observed elsewhere,
there *may* be problems if you are running it from an IDE such as AdaGIDE, but
I've never encountered any.)

Another helpful debugging tip: Put some "Put_Line" statements in where you read
the command line parameters and just before you open the file to be sure you are
getting what you think you are getting into the strings.  And be *real careful*
that you reference just the slice of the string which is valid, because it is a
very common error to reference the whole string - which may or may not be valid.

I like to avoid this sort of thing by getting everything into an
Unbounded_String ASAP and converting back as needed. (id est: use
To_Unbounded_String (Str (1..Last)) right away and then use To_String (UStr) to
convert back when needed as a parameter to something else.)

Hope this helps. I'll give it a more careful look later if this doesn't fix it.

MDC
--
Marin David Condic
Real Time & Embedded Systems, Propulsion Systems Analysis
United Technologies, Pratt & Whitney, Large Military Engines
M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600
***To reply, remove "bogon" from the domain name.***

Visit my web page at: http://www.mcondic.com/

Re: Sequential_IO

[Tucker Taft]

Shawn Barber wrote:
> 
> I am using Sequential_IO to read some data from a file. Why
> do I need to specify the full path of the file being read
> when I'm running the program from the directory in which the
> file resides? I'm getting the filename from the command line
> and in I continually get a Name_Error unless I specify the
> path as well. Any ideas? 

On non-Unix systems, the notion of the "current directory" is generally
more confusing than on Unix systems.  For the Mac, the concept doesn't
really exist.  On Win* systems, there are multiple "current" directories,
one for each drive letter (everyone who thinks drive letters are the
dumbest O/S idea of all time raise their hand ;-).  On VMS systems,
the current directory is defined by various environment variables, I believe.

So unless you are on Unix, knowing exactly what is the "current directory"
can be tricky.

> ..., I didn't see anything in the LRM,
> but that doesn't mean it's not there. Thanks.

The intent of the LRM is certainly that you may take advantage of
things like "current directory" or other shortcuts/links.  FWIW, the "Name"
function is supposed to always return a full, unambiguous path name,
no matter how the file was opened.  Unfortunately, all of these
concepts are O/S dependent.

> Shawn
> 
> * Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
> The fastest and easiest way to search and participate in Usenet - Free!

-- 
-Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
Technical Director, Distributed IT Solutions  (www.averstar.com/tools)
AverStar (formerly Intermetrics, Inc.)   Burlington, MA  USA

Re: Sequential_IO

[Marin David Condic]

Tucker Taft wrote:

> really exist.  On Win* systems, there are multiple "current" directories,
> one for each drive letter (everyone who thinks drive letters are the
> dumbest O/S idea of all time raise their hand ;-).  On VMS systems,

(Virtual Hand Raise!)

But in fairness, there was a powerful requirement for Win* to remain upward
compatibility with a lot of MS-DOS throwbacks. Hence, they needed to do something
and they came up with treating drive letters as a kind of logical name. It may be
butt-ugly, but it lets a lot of old software continue to run.

I'd personally like to see someone do a clean-slate development of a portable OS
and make it available in the Linux mode. There have been a lot of better ideas
developed, but they mostly get rejected out of a need to keep things looking "the
same". The wierd thing is that software was supposed to be so infinitely adaptable
in comparison to hardware and its becoming clear that it is easier to change
hardware than it is to change software. :-)

MDC
--
Marin David Condic
Real Time & Embedded Systems, Propulsion Systems Analysis
United Technologies, Pratt & Whitney, Large Military Engines
M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600
***To reply, remove "bogon" from the domain name.***

Visit my web page at: http://www.mcondic.com/

Re: Sequential_IO

[Ted Dennison]

In article <37BC277E.B17EEEFF@averstar.com>,
  Tucker Taft <stt@averstar.com> wrote:

> one for each drive letter (everyone who thinks drive letters are the
> dumbest O/S idea of all time raise their hand ;-).  On VMS systems,

Not here. My vote goes for DOS's upper memory/lower memory/extended
memory foolishness.

And in fairness to DOS, Unix's case-sensitive file names comes in at
about #5 on the list.

--
T.E.D.


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Sequential_IO

[Robert Dewar]

In article <7phfpm$78r$1@nnrp1.deja.com>,
  Ted Dennison <dennison@telepath.com> wrote:
> Not here. My vote goes for DOS's upper memory/lower
> memory/extended memory foolishness.

This is of course off-topic, but the above does need a response.
This was not an "operating system" idea, but rather a hardware
specification that is fundamental to the early x86
architectures. I don't see how an OS could somehow completely
hide the fact that you have two completely different segments
of memory.

The trick that was used to add 64K memory to the lower one
megabyte by turning off A20 was indeed kludgy, but in a battle
with a very difficult architecture, one can hardly blame the
OS for failing to mask all the fundamental difficulties in
the architecture when there really was no simple way to do so.

This kind of thing is just not type-comparable at all with the
decision to make file names case sensitive in Unix, which is
indeed a pure OS design decision.

By the way, even complaining at the kludgy memory architecture
of the early x86 is off base to some extent. The history is
interesting (read more about it in my Microprocessors book if
you want).

Intel wanted the 8086 to be a simple upgrade to the 8080 that
would retain upwards compatibility in the instruction set,
while allowing 128K of memory by dual code/data addressing
a la PDP11 (at the time, Intel thought that nearly all their
customers could manage fine with 64K, but that some really
huge applications might possibly need 128K, so, planning for
the future .... :-)

Steve Morse designed the segmented architecture of the 8086 to
provide up to a megabyte of addressing space without going to
addresses longer than 16 bits, or registers longer than 16 bits.
Intel was VERY concerned about code size so they really wanted
to stay with a 16-bit design, and avoid 32-bit addresses.
Steve's design was a clever way of meeting this requirement
while avoiding the 128K restriction. Just imagine if the
horrible 640K limit had instead been 80K :-)

Of course I suppose you could say that if the 8088 had been
that limited, IBM would have been more likely to choose the
68K architecture for the PC. Wouldn't it have made a difference
if PC's had used this much cleaner architecture from the start.

It seems amazing that most computing today is still done on an
architecture which has the amazing distinction of having no
two registers that are functionally equivalent (and only 8 of
them).


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Sequential_IO

[Shawn Barber]

Ok, I forgot this last time. I'm working on NT4 with the 
GNAT3.11p compiler. Here are the peices of code which apply 
to this problem:

   procedure Get_Command_Line_Parameters (
      
------------------------------------------------------------
---
      -- The purpose of this procedure is to get the command       
--
      -- line parameters.                                          
--
      
------------------------------------------------------------
---
      NVM_File_Name   :    out string  ;
      NVM_Name_Length :    out natural ;
      Memory_Address  :    out string  ;
      DBG_File_Name   :    out string  ;
      DBG_Name_Length :    out natural ) is
   
      -- Command Line Argument Number of the NVM file name.
   NVM_Argument            : constant natural := 1 ;
      
      -- Command Line Argument Number of the Memory Address 
argument.
   Memory_Address_Argument : constant natural := 2 ;
   
      -- Command line Argument Number of the DBG file name.
   DBG_Argument            : constant natural := 3 ;
      
      -- Holds the number of command line arguments which
      -- were suplied at run-time.
   Number_Of_Arguments   : natural ;
   
   begin

         -- Get the total number of Command Line Arguments 
supplied.
      Number_Of_Arguments := command_line.argument_count ;

         -- If there are not exactly 2 Arguments then the 
argument list is
         -- invalid.
      if Number_Of_Arguments < 2  or Number_Of_Arguments > 3 
then

            -- Incorrect number of arguments enters at the 
command prompt.
         raise Invalid_Arguments ;
      
      end if ;

         -- Calculate the length of NVM_File_Name.
      NVM_Name_Length := command_line.argument ( 
NVM_Argument )'last ;
         
         -- Get the File Name from the Argument list.
      Fixed.Move
         ( Source => command_line.argument ( NVM_Argument ) 
,
           Target => NVM_File_Name                          
) ;
         
         -- Get the starting memory address from the 
argument list.
      Fixed.Move
         ( Source => command_line.argument ( 
Memory_Address_Argument ) ,
           Target => Memory_Address                                    
) ;

      if Number_Of_Arguments = 3 then

            -- Calculate the length of DBG_File_Name.
         DBG_Name_Length := command_line.argument ( 
DBG_Argument )'last ;

            -- Get the File Name from the Argument list.
         Fixed.Move
            ( Source => command_line.argument ( DBG_Argument 
) ,
              Target => DBG_File_Name                          
) ;

      else

            -- Set the DBG File name length to the default.
         DBG_Name_Length := 11 ;
            
            -- Set the DBG File name to the default.
         Fixed.Move
            ( Source => "DEFAULT.DBG" ,
              Target => DBG_File_Name ) ;

      end if;

   end Get_Command_Line_Parameters ;

-----------------------------------------------------------
      -- Get the parameters entered on the command line.
   Get_Command_Line_Parameters
      ( NVM_File_Name    => NVM_Input_File_Name  ,
        NVM_Name_Length  => Length_Of_NVM_Name   ,
        Memory_Address   => Memory_Start_Address ,
        DBG_File_Name    => DBG_Output_File_Name ,
        DBG_Name_Length  => Length_Of_DBG_Name   ) ;

      -- Open the output file.
   text_io.create
      ( File => Output_File           ,
        Mode => text_io.out_file      ,
        Name => DBG_Output_File_Name  ) ;
        
      -- Redirect output.
   text_io.set_output ( File => Output_File ) ;

      -- Open the source file.
   One_Word_IO.Open
      ( File => Input_File           ,
        Mode => One_Word_IO.In_File  ,
        Name => NVM_Input_File_Name  ) ;
        
-----------------------------------------------------------
The first piece of code get the command line parameters. The 
second has the call to the get parameters procedure then the 
create, redirection and open. One_Word_IO is an 
instansiation of Sequential_IO. I've checked the filename 
after being passed back from the get parameters procedure. I 
hope this helps clear something up. Thanks.

Shawn

* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!

Re: Sequential_IO

[David C. Hoos, Sr.]

Shawn Barber <SbarberNOcqSPAM@snet.net> wrote in message
news:11f733ec.81e1abff@usw-ex0102-014.remarq.com...
> Ok, I forgot this last time. I'm working on NT4 with the
> GNAT3.11p compiler. Here are the peices of code which apply
> to this problem:
>
Well... actually, you did _not_ supply all of "the pieces of code which
apply to this problem."


However, I will make some assumptions (which I will state), and we'll
try to get to the bottom of this problem.

The fundamental error is that you have passed the NVM_Input_File_Name
string to One_Word_IO.Open.  Thus, the length of the filename passed
is whatever is the length of NVM_Input_File_Name (of which the declaration
is one piece of missing code).  You should have passed

NVM_Input_File_Name
  (NVM_Input_File_Name'First .. NVM_Input_File_Name'First +
Length_Of_NVM_Name - 1)

as the actual Name => parameter.

You did not supply the identification of Fixed.Move (e.g., by showing your
"use" clauses), so I assume this is Ada.Strings.Fixed.Move, -- in which case
the filename you passed has some number of trailing spaces.

A couple of other technical points:

  1.  You notice I used the 'First attribute in defining the slice of the
string
      to be passed.  This is always good practice when you don't know the
bounds
      of a string -- e.g., when inside a procedure which has a string out
mode
      (or in out mode) parameter. In other words, you _cannot_  assume the
first
      index of every string to be 1.

  2.  You assumed the equivalence of 'Last and the length of an array.  This
is
      only true if the array has a numeric index and the 'First attribute =
1.
      A better course is to actually use the 'Length attribute when what you
      want is the length.  When you deal with arrays having non-numeric
indices,
      'Last won't even be a number.  When writing a generic unit, for
example.
      in which an array index type is a generic formal parameter of type
(<>),
      whether the array index is numeric is not even known inside the
generic
      unit, so the distinction between index values and numeric attributes
such
      as 'Length is important.

One way to have avoided the use of Ada.Strings.Fixed.Move, and eliminated
altogether the need for the Get_Command_Line_Parameters procedure, yet
providing
the better readability of meaningful names for the command line parameters
would have been to use a renaming declaration, viz.:

   NVM_Input_File_Name : String renames Command_Line.Argument (1);

Then, you can pass the NVM_Input_File_Name argument directly to Open.

I realize this doesn't work with the optional debug file name, and the
supplying
of a default, but it's just another technique available in Ada.

Re: Sequential_IO

[Ted Dennison]

In article <11f733ec.81e1abff@usw-ex0102-014.remarq.com>,
  Shawn Barber <SbarberNOcqSPAM@snet.net> wrote:
> Ok, I forgot this last time. I'm working on NT4 with the
> GNAT3.11p compiler. Here are the peices of code which apply
> to this problem:

Are you running your executable from the command line, or via AdaGUIde?

--
T.E.D.


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Sequential_IO

[Simon Wright]

Ted Dennison <dennison@telepath.com> writes:

> In article <37BC277E.B17EEEFF@averstar.com>,
>   Tucker Taft <stt@averstar.com> wrote:
> 
> > one for each drive letter (everyone who thinks drive letters are the
> > dumbest O/S idea of all time raise their hand ;-).  On VMS systems,
[...]
> And in fairness to DOS, Unix's case-sensitive file names comes in at
> about #5 on the list.

I suppose it says something about me that I rather like
case-sensitivity (in fact I get a bit sensitive when people sound off
about it :-)

Goes along with a taste for vi-reference-card coffee mugs ..