I was assigned this task as my homework. I have a file which contains lines of text of varying lengths. The program is supposed to write the data onto the screen in precisely the same order in which it is written in the file, yet it fails to do so. To achieve the desired result I tried reading only one character per iteration so as to detect new line characters. What am I doing wrong?
WITH Ada.Text_IO;
WITH Ada.Characters.Latin_1;
USE Ada.Text_IO;
PROCEDURE ASCII_artwork IS
File : File_Type;
c : Character;
BEGIN
Open(File, In_File, "Winnie_The_Pooh.txt");
WHILE NOT End_Of_File(File) LOOP
Get(File, C);
IF (C = Ada.Characters.Latin_1.LF) THEN Put_Line(" "); ELSE
Put(C);
END IF;
END LOOP;
Close(File);
END ASCII_Artwork;
For each file, the Ada runtime maintains a fictitious "cursor". This is not the typical file position cursor (index), but one that indicates the position on a page, line, etc. (see also RM A.10 (7)). This is somewhat of an inheritance from the early versions of Ada.
Get stems from this same era and is expected to update the location of this cursor when some particular control characters are being read (e.g. an end-of-line mark). If Get reads such such a control character, it will only use it to update the cursor (internally) and then continue to read a next character (see also RM A.10.7 (3)). You'll therefore never detect an end-of-line mark when using Get.
This behavior, however, has some uncomfortable consequence: if a file ends with a sequence of control characters, then Get will keep reading those characters and hit the end of the file causing an End_Error exception.
You can, of course, catch this exception and handle it, but such a construct is dubious as having a sequence of control characters at the end of a file is actually not such an abnormal case (and hence dubious if worth an exception). As a programmer, however, you cannot change this behavior: it's defined by the language and the language will not be changed because it has been decided to keep Ada (highly) backwards compatible (which in itself is understandable given its field of application).
Hence, in your case, if you want stick to a character-by-character processing approach, I would suggest to move away from Get and instead use (for example) streams to perform I/O as in the example below.
main.adb
with Ada.Text_IO; use Ada.Text_IO;
with Ada.Text_IO.Text_Streams; use Ada.Text_IO.Text_Streams;
procedure ASCII_artwork IS
File : File_Type;
Input : Stream_Access;
Output : Stream_Access;
C : Character;
begin
Open (File, In_File, "Winnie_The_Pooh.txt");
Input := Stream (File);
Output := Stream (Standard_Output);
while not End_Of_File (File) loop
Character'Read (Input, C);
Character'Write (Output, C);
end loop;
Close(File);
end ASCII_Artwork;
Output is as expected (i.e. the content of this the file at ascii-art.de).
NOTE: Check the source code of the GNAT runtime to actually see how Get works internally (focus on the loop at the end).
As explained by DeeDee, text inputs are buffered linewise in Ada. The idea is to be able to read two integers on the same line. For consistency sake (the designers of Ada are picky on that...), Get(File, C) does the same. It is not practical in your case. Fortunately, Ada 95 has introduced Get_Immediate, to solve precisely that issue.
Otherwise, as suggested by Frédéric, you could use the function Get_Line to absorb Winnie_The_Pooh.txt line by line seamlessly. By the way, the Get_Line method will convert the different end-of-line conventions automatically.
Line terminators in Ada.Text_IO are a concept, not a character or sequence of characters in the file. (Although most commonly used file systems implement them as characters or sequences of characters in the file, there exist file systems that do not.) Line terminators must therefore be manipulated using the operations in the package. For reading, End_Of_Line checks to see if the cursor is at a line terminator, Skip_Line skips the next line terminator, and Get_Line may skip a line terminator. For writing, New_Line and Put_Line write line terminators.
For your problem, the canonical solution is to use the Get_Line function to read lines, and Put_Line to output the lines read.
Related
EDIT: The original question had unnecessary details
I have a source file which I do value analysis in Frama-C, some of the code is highlighted as dead code in the normalized window, no the original source code.
Can I obtain a slice of the original code that removes the dead code?
Short answer: there's nothing in the current Frama-C version that will let you do that directly. Moreover, if your original code contains macros, Frama-C will not even see the real original code, as it relies on an external preprocessor (e.g. cpp) to do macro expansion.
Longer answer: Each statement in the normalized (aka CIL) Abstract Syntax Tree (AST, the internal representation of C code within Frama-C) contains information about the location (start point and end point) of the original statement where it stems from, and this information is also available in the original AST (aka Cabs). It might thus be possible for someone with a good knowledge of Frama-C's inner workings (e.g. a reader of the developer's manual), to build a correspondance between both, and to use that to detect dead statement in Cabs. Going even further, one could bypass Cabs, and identify zones in the original text of the program which are dead code. Note however that it would be a tedious and quite error prone (notably because a single original statement can be expanded in several normalized ones) task.
Given your clarifications, I stand by #Virgile's answer; but for people interested in performing some simplistic dead code elimination within Frama-C, the script below, gifted by a colleague who has no SO account, could be helpful.
(* remove_dead_code.ml *)
let main () =
!Db.Value.compute ();
Slicing.Api.Project.reset_slicing ();
let selection = ref Slicing.Api.Select.empty_selects in
let o = object (self)
inherit Visitor.frama_c_inplace
method !vstmt_aux stmt =
if Db.Value.is_reachable_stmt stmt then
selection :=
Slicing.Api.Select.select_stmt ~spare:true
!selection
stmt
(Extlib.the self#current_kf);
Cil.DoChildren
end in
Visitor.visitFramacFileSameGlobals o (Ast.get ());
Slicing.Api.Request.add_persistent_selection !selection;
Slicing.Api.Request.apply_all_internal ();
Slicing.Api.Slice.remove_uncalled ();
ignore (Slicing.Api.Project.extract "no-dead")
let () = Db.Main.extend main
Usage:
frama-c -load-script remove_dead_code.ml file.c -then-last -print -ocode output.c
Note that this script does not work in all cases and could have further improvements (e.g. to handle initializers), but for some quick-and-dirty hacking, it can still be helpful.
I have Ada program that runs and compile perfectly using GNAT - GPS. When I run its exe file and provide user input then instead of saying "Press any key to continue", the exe closes immediately.
I have searched for it online alot but i only found info related to c/c++/visual studio console window using system('pause'); OR Console.Readline().
Is there any way around for this in Ada lanaguage?
Apart from using Get_Line or Get, you can also use Get_Immediate from the Ada.Text_IO package. The difference is that Get_Line and Get will continue to read user input until <Enter> has been hit, while Get_Immediate will block only until a single key has been pressed when standard input is connected to an interactive device (e.g. a keyboard).
Here's an example:
with Ada.Text_IO; use Ada.Text_IO;
procedure Main is
begin
-- Do some interesting stuff here...
declare
User_Response : Character;
begin
Put_Line ("Press any key to continue...");
Get_Immediate (User_Response);
end;
end Main;
NOTES
You should run the program in an interactive terminal (Bash, PowerShell, etc.) to actually see the effect of Get_Immediate. When you run the program from within GPS, then you still have to press enter to actually exit the program.
This might be too much detail, but I think that Get still waits for <Enter> to be pressed because it uses fgetc from the C standard library (libc) under the hood (see here and here). The function fgetc reads from a C stream. C streams are initially line-buffered for interactive devices (source).
The answer from #DeeDee is more portable and only Ada and the preferable way to go, so my answer is just if you are looking for a "windows" way to do it.
I think there is a linker option for it, but I couldn't find it. A more manual way is to bind the system() command from C and give it a "pause" command and place it at the end of your program:
with Ada.Text_IO; use Ada.Text_IO;
with Interfaces.C.Strings;
procedure Main is
function System(Str : Interfaces.c.strings.chars_ptr) return Interfaces.C.int
with Import,
Convention => C,
External_Name => "system";
procedure Pause is
Command : Interfaces.c.Strings.chars_ptr
:= Interfaces.C.Strings.New_String("pause");
Result : Interfaces.C.int
:= System(Command);
begin
Interfaces.C.Strings.Free(Command);
end Pause;
begin
Put_Line("Hello World");
Pause;
end Main;
I know you mentioned seeing about pause already, but just wanted to show an example.
The same way you could use Console.Readline(), you can use Get_Line from the package Ada.Text_IO.
In this case, you will have to put the result into a String that you won't use.
I try to export a file in SAS but I get "Open code statement recursion detected." error. Since I export more than one files depending on date I define as a macro variable based on the prompt date, I want to name my file to be exported with this variable but it does not work. I would really appreciate if anyone helps me.
rep_date = 30APR2015:00:00:00
Outfile = work.A042015.sas7
%let var = CATS("A",MONTH(DATEPART(&rep_date)),YEAR(DATEPART(&rep_date)));
data WORK.&var(compress=yes);
set WORK.have;
run;
Macro variables are just strings. So if you want to execute functions in macro code you need to wrap the function inside of the %SYSFUNC() macro function.
%let rep_date='01JAN2015:01:23'dt ;
%let dsname = A%sysfunc(datepart(&rep_date),monyy6);
data &dsname(compress=yes);
set have;
run;
As a more broad issue, OPEN STATEMENT RECURSION DETECTED refers to cases where you assign a macro variable to itself.
%let &mvar = &mvar;
Of course, this wouldn't normally happen on purpose (one would think). When it does happen, usually it's a sign of one of two classes of mistake.
You're missing a semicolon, end parenthesis, end quote, or something else that causes SAS to not "see" the semicolon at the end of the %let statement. Then your next statement uses the macro variable in a macro context, and SAS sees that as part of the %let statement, which causes this error message.
Something went wrong somewhere else, and you have an issue where that something-else propagates errors further down that don't make any sense. Having an unmatched quotation is a classic example of this, as is a macro that doesn't properly %mend.
1 can happen in cases as simple as this:
%let mvar=mydataset
%put &mvar;
Oops. If it's that simple, then just pop the semicolon on and you're good. It could, however, be caused by something more significant - such as an unmatched parenthesis or quotation - which might require restarting your SAS session. (Sometimes submitting a magic string, which are variations on %*;*;*';*";%*%mend;*);, will fix things, sometimes not. Restarting SAS is a reliable way to fix that).
That's also true with 2 above - if a magic string doesn't fix it, then you may simply need to restart your SAS session. Of course, you still need to find that unmatched quote/parenthesis/etc., but you first need to start SAS over so you can figure it out.
I want to declare a constant as a 16 bit integer of type Word and assign a value to it. To support portability between Big and Little Endian platforms, I can't safely use an assignment like this one:
Special_Value : Constant Word := 16#1234#;
because the byte order might be misinterpreted.
So I use a record like this:
Type Double_Byte Is Record
Byte_1 : Byte; -- most significant byte
Byte_0 : Byte; -- least significant byte
End Record;
For Double_Byte Use Record
Byte_1 At 0 Range 0..7;
Byte_0 At 0 Range 8..15;
End Record;
However, in some cases, I have a large number of pre-configuration assignments that look like this:
Value_1 : Constant Word := 15#1234#;
This is very readable by a person, but endian issues cause it to be misunderstood a number of ways (including in the debugger, for example).
Because I have many lines where I do this, I tried the following because it is fairly compact as source code. It is working, but I'm not sure why, or what part of the Ada Reference Manual covers this concept:
Value_1 : Constant Word := DByte_To_Word((Byte_1 => 16#12#,
Byte_0 => 16#34#));
where DByte_To_Word is defined as
Function DByte_To_Word Is New Unchecked_Conversion(Double_Byte, Word);
I think I have seen something in the ARM that allows me to do this, but not the way I described above. I can't find it and I don't know what I would be searching for.
There’s nothing unusual about your call to DByte_To_Word; (Byte_1 => 16#12#, Byte_0 => 16#34#) is a perfectly legitimate record aggregate of type Double_Byte, see LRM83 4.3.1.
But! But! it’s true that, on a big-endian machine, the first (lowest-addressed) byte of your Word will contain 16#12#, whereas on a little-endian machine it will contain 16#34#. The CPU takes care of all of that; if you print the value of Special_Value you will get 16#1234# (or 0x1234) no matter which endianness the computer implements.
The only time you’ll encounter endianness issues is when you’re copying binary data from one endianness to another, via the network, or a file.
If your debugger gets confused about this, you need a better debugger!
I have a little problem in using get_line to be more concret I must take a line from a file and use it. I don't know how especially if the lines aren't constitute just from characters there's also float can I use get_line in this case?
Thank you. Let's start with this little example:
with Ada.Text_Io;
use Ada.Text_Io;
procedure Getline is
A:String;
T:string;
begin
Open(File => F, Mode => In_File, Name => Nom_Fichier);
A:=Get_Line(F,In_File, T);
Put(A);
end Getline;`
It looks like you're just guessing the parameters you should pass to Get_Line. I suggest you have a look at the relevant part in the ARM: The function Get_Line only takes a File_Type and returns a String; the procedure Get_Line takes a File_Type and, as output parameters, a String and a Natural.
Then, String is an indefinite subtype, meaning that you have to assign something to A at declaration, or provide boundaries for it. Here's a working version of your example code:
with Ada.Text_IO; use Ada.Text_IO;
procedure Getline is
F : File_Type;
File_Path : constant String := "testfile.stl";
begin
Open (File => F, Mode => In_File, Name => File_Path);
declare
A : String := Get_Line (F);
begin
Put (A);
end;
Close (File => F);
end Getline;
Before you try something more complex, you should get familiar with the basics of the language. The wikibook is a good place to start. If you want to get your actual question about reading floats from the line answered, you need to provide more details about how a potential line looks like.
Get_Line simply interprets the "line" (set of characters up to the next line terminator or end of file) as text, and gives it to the caller that way. Thus if the file contains:
10.52
Then your call to Get_Line will return the string "10.52".
It may be true that if you tried to read that using Float_Text_IO you would get the float value 10.52 back. However, there's no metadata associated with text in text files, so the computer has no way of knowing that text happens to be a representable float without parsing it and seeing if it can make a float out of it. It of course isn't going to bother to do that unless you ask it to via something like a call into Float_Text_IO