* spurious error with GNAT 13.2.0 on Intel macOS 17.2
@ 2023-12-14 23:49 6% moi
0 siblings, 0 replies; 170+ results
From: moi @ 2023-12-14 23:49 UTC (permalink / raw)
The 17.2 update is accompanied by updated Command Line Tools,
so, having made a copy of the current CLTs, I let it update.
With GNAT 13.2.0 on Intel macOS 17.2 this happens:
/Users/wf/KDF9/emulation/Testing: chmod 444 ST0
On compiling and running the minimum test case:
with Ada.Direct_IO;
with Ada.IO_Exceptions;
procedure failure is
package my_IO is new Ada.Direct_IO(Integer);
use my_IO;
my_file : File_Type;
begin
Open(my_file, Inout_File, "ST0");
exception
when Ada.IO_Exceptions.Use_Error =>
raise program_error with "Open failed to get RW access";
end failure;
I get:
A. with ”-largs -Wl,-ld_classic” in the linker parameters:
/Users/wf/KDF9/emulation/Testing: failure
raised PROGRAM_ERROR : Open failed to get RW access
This is what should happen.
B. recompiled and relinked without ”-largs -Wl,-ld_classic”:
/Users/wf/KDF9/emulation/Testing: failure
raised CONSTRAINT_ERROR : erroneous memory access
OOPS!
Strangely, this is now the ONLY one out of dozens of regression tests
that fails in this software configuration.
Previously, they all failed at the link stage.
--
Bill F.
^ permalink raw reply [relevance 6%]
* Re: Hi! How I can make _indexed_ stream file Input/Output ? Thanks.
2021-07-05 4:06 0% ` zac brown
@ 2021-07-05 4:06 0% ` zac brown
0 siblings, 0 replies; 170+ results
From: zac brown @ 2021-07-05 4:06 UTC (permalink / raw)
On Monday, July 5, 2021 at 2:06:36 PM UTC+10, zac brown wrote:
> On Saturday, July 3, 2021 at 6:57:31 AM UTC+10, Shark8 wrote:
> > On Sunday, June 27, 2021 at 1:33:28 PM UTC-6, daniel wrote:
> > > How I can make _indexed_ stream file Input/Output ?
> > >
> > > For 'indexed' i mean manually setting file position:
> > > => 'from' in $type'input() and
> > > => 'to' in $type'output()
> > >
> > > Actually I use Ada.Streams.Stream_IO.
> > >
> > > My main need is examples.
> > >
> > > Thanks!
> > > Best Whishes,
> > > Dani.
> > Streams are a bit different than files; you see, streams are an abstraction on input/output and therefore different than files. Consider, for example, an output stream that controls a radio transmitter. There's no possible way to "unsend" the data: it's a write-only device.
> >
> > If you're using Ada's standard library, with the XXX_IO packages, I believe what you want is Ada.Direct_IO.
^ permalink raw reply [relevance 0%]
* Re: Hi! How I can make _indexed_ stream file Input/Output ? Thanks.
2021-07-02 20:57 5% ` Shark8
@ 2021-07-05 4:06 0% ` zac brown
2021-07-05 4:06 0% ` zac brown
0 siblings, 1 reply; 170+ results
From: zac brown @ 2021-07-05 4:06 UTC (permalink / raw)
On Saturday, July 3, 2021 at 6:57:31 AM UTC+10, Shark8 wrote:
> On Sunday, June 27, 2021 at 1:33:28 PM UTC-6, daniel wrote:
> > How I can make _indexed_ stream file Input/Output ?
> >
> > For 'indexed' i mean manually setting file position:
> > => 'from' in $type'input() and
> > => 'to' in $type'output()
> >
> > Actually I use Ada.Streams.Stream_IO.
> >
> > My main need is examples.
> >
> > Thanks!
> > Best Whishes,
> > Dani.
> Streams are a bit different than files; you see, streams are an abstraction on input/output and therefore different than files. Consider, for example, an output stream that controls a radio transmitter. There's no possible way to "unsend" the data: it's a write-only device.
>
> If you're using Ada's standard library, with the XXX_IO packages, I believe what you want is Ada.Direct_IO.
^ permalink raw reply [relevance 0%]
* Re: Hi! How I can make _indexed_ stream file Input/Output ? Thanks.
@ 2021-07-02 20:57 5% ` Shark8
2021-07-05 4:06 0% ` zac brown
0 siblings, 1 reply; 170+ results
From: Shark8 @ 2021-07-02 20:57 UTC (permalink / raw)
On Sunday, June 27, 2021 at 1:33:28 PM UTC-6, daniel wrote:
> How I can make _indexed_ stream file Input/Output ?
>
> For 'indexed' i mean manually setting file position:
> => 'from' in $type'input() and
> => 'to' in $type'output()
>
> Actually I use Ada.Streams.Stream_IO.
>
> My main need is examples.
>
> Thanks!
> Best Whishes,
> Dani.
Streams are a bit different than files; you see, streams are an abstraction on input/output and therefore different than files. Consider, for example, an output stream that controls a radio transmitter. There's no possible way to "unsend" the data: it's a write-only device.
If you're using Ada's standard library, with the XXX_IO packages, I believe what you want is Ada.Direct_IO.
^ permalink raw reply [relevance 5%]
* Re: surprise data from Ada.Sequential_IO
2021-03-22 20:54 8% ` Niklas Holsti
@ 2021-03-23 9:18 0% ` Jeffrey R. Carter
0 siblings, 0 replies; 170+ results
From: Jeffrey R. Carter @ 2021-03-23 9:18 UTC (permalink / raw)
On 3/22/21 9:54 PM, Niklas Holsti wrote:
>
> Not quite. From the RM:
>
> generic
> type Element_Type is private;
> package Ada.Direct_IO is
> ...
>
> and
>
> generic
> type Element_Type(<>) is private;
> package Ada.Sequential_IO is
Ah, yes. Having started with Ada 83, I sometimes forget about changes like this.
--
Jeff Carter
"[I]f you ask, 'Why does Ada do/have this?',
the answer often makes you a better programmer."
Chad R. Meiners
177
^ permalink raw reply [relevance 0%]
* Re: surprise data from Ada.Sequential_IO
@ 2021-03-22 20:54 8% ` Niklas Holsti
2021-03-23 9:18 0% ` Jeffrey R. Carter
0 siblings, 1 reply; 170+ results
From: Niklas Holsti @ 2021-03-22 20:54 UTC (permalink / raw)
On 2021-03-22 21:41, Jeffrey R. Carter wrote:
> The only differences between Direct_IO and Sequential_IO are that
> Direct_IO allows random access and mixed input and output. In both cases
> the file contains a sequence of binary representations of values of a
> single type.
>
> I don't really understand why Sequential_IO exists, since Direct_IO
> provides a superset of Sequential_IO's functionality.
Not quite. From the RM:
generic
type Element_Type is private;
package Ada.Direct_IO is
...
and
generic
type Element_Type(<>) is private;
package Ada.Sequential_IO is
...
So Sequential_IO allows unknown discriminants in the element type, in
other words elements that can vary in size, which obviously hampers
random (indexed) access to elements in the file, which Direct_IO allows.
There is also this note for Direct_IO:
RM A.8.4(19.a): Reason: The Element_Type formal of Direct_IO does not
have an unknown_discriminant_part (unlike Sequential_IO) so that the
implementation can make use of the ability to declare uninitialized
variables of the type.
^ permalink raw reply [relevance 8%]
* Re: Advent of Code
2020-12-03 17:20 5% ` Björn Lundin
@ 2020-12-03 17:36 0% ` John Perry
0 siblings, 0 replies; 170+ results
From: John Perry @ 2020-12-03 17:36 UTC (permalink / raw)
On Thursday, December 3, 2020 at 11:20:42 AM UTC-6, björn lundin wrote:
> Den 2020-12-03 kl. 15:52, skrev Wendel Wang:
> > I was wondering for example if there is a way to read the data from day 2 as a record data structure? You can read it item by item, but is there a way to do it as a record?
> >
> I guess you can use Ada.Direct_io. ...
> and its example
>
> <https://perso.telecom-paristech.fr/pautet/Ada95/e_c24_p3.ada>
That's wonderful! I wish I'd known of that.
john perry
^ permalink raw reply [relevance 0%]
* Re: Advent of Code
@ 2020-12-03 17:20 5% ` Björn Lundin
2020-12-03 17:36 0% ` John Perry
0 siblings, 1 reply; 170+ results
From: Björn Lundin @ 2020-12-03 17:20 UTC (permalink / raw)
Den 2020-12-03 kl. 15:52, skrev Wendel Wang:
> Hi.
>
> Here is result so far.I am just learning Ada, so any comments welcome.
>
> https://gitlab.com/MarcusE1W/prog/-/tree/master/ada/aoc
>
> I was wondering for example if there is a way to read the data from day 2 as a record data structure? You can read it item by item, but is there a way to do it as a record?
>
I guess you can use Ada.Direct_io.
I did not look at the inputfile, but I guess i has the same format as
the frontpage. You need to define a record that can fit the data.
Here's an old course
<https://perso.telecom-paristech.fr/pautet/Ada95/chap24.htm>
and its example
<https://perso.telecom-paristech.fr/pautet/Ada95/e_c24_p3.ada>
--
Björn
^ permalink raw reply [relevance 5%]
* Re: A little trouble with very large arrays.
@ 2018-10-05 6:17 5% ` Jacob Sparre Andersen
0 siblings, 0 replies; 170+ results
From: Jacob Sparre Andersen @ 2018-10-05 6:17 UTC (permalink / raw)
Shark8 <onewingedshark@gmail.com> writes:
> The main-problem right now is the "Primary Data Array" which can have
> a dimensionality in 1..999, each itself with some non-zero range. (In
> the files these are specified by keywords in the file like NAXIS = n,
> NAXIS1 = n_1, NAXIS2 = n_2, and so on until the NAXISn = n_n
> keyword/value pair is encountered.)
Ouch. :-(
Something like this will work, but it doesn't look nice:
package Variable_Dimensionality is
type Raw is array (Positive range <>,
Positive range <>,
Positive range <>) of Boolean;
type Nice (Dim_1, Dim_2, Dim_3 : Positive) is
record
Data : Raw (1 .. Dim_1,
1 .. Dim_2,
1 .. Dim_3);
end record;
end Variable_Dimensionality;
> (As another interesting constraint, the file-format mandates a sort of
> block-structure of 2880 bytes [23040 bits], and while I don't
> anticipate this being an issue, something that might be relevant.)
Ada.Sequential_IO and Ada.Direct_IO can both be instantiated with types
of any size, so you could simply use a 2880 character String, or a 2880
element Storage_Element_Array (remember to assert that
Storage_Element'Size = 8).
Greetings,
Jacob
--
»Verbing weirds language.« -- Calvin
^ permalink raw reply [relevance 5%]
* Re: Ada.Real_Time.Time_Last
2017-11-18 13:18 0% ` Ada.Real_Time.Time_Last Niklas Holsti
@ 2017-11-18 14:00 0% ` AdaMagica
0 siblings, 0 replies; 170+ results
From: AdaMagica @ 2017-11-18 14:00 UTC (permalink / raw)
Am Samstag, 18. November 2017 14:18:44 UTC+1 schrieb Niklas Holsti:
> On 17-11-18 15:06 , AdaMagica wrote:
> > Am Freitag, 17. November 2017 22:39:51 UTC+1 schrieb Niklas Holsti:
> >
> >> Long ago, I suggested (on c.l.a) an Ada extension by which a package
> >> could declare private types using the same classes of types that can be
> >> used for generic formal types. That would IMO not only be useful for
> >> programmers, it could formalise some of the informal text in the Ada RM.
> >> For example, RM A.4.8 defines the type Ada.Direct_IO.Count as
> >>
> >> type Count is range 0 .. implementation defined;
> >>
> >> With the suggested extension, this could be written in legal (extended)
> >> Ada as
> >>
> >> type Count is private range <>;
> >>
> >> That form still does not show that Count'First = 0, but with a little
> >> further extension one could perhaps leave only the upper bound
> >> unspecified, as in:
> >>
> >> type Count is private range 0 .. <>;
> >>
> >> Perhaps it is time for me to revive this proposal...
> >>
> > Problem with this is that private types have no predefined operators.
>
> That is a problem with private types in *current* Ada, where a private
> type is fully "opaque". This proposal is meant to remove this problem,
> by letting the programmer provide more information about the private
> type, in the same way as information can now be provided about generic
> formal types, to equip those types with predefined operators that can be
> used in the generic.
Yes - but what do we gain with this new syntax? Is it worth the effort? Which problem does it solve (to rephrase Randy)?
^ permalink raw reply [relevance 0%]
* Re: Ada.Real_Time.Time_Last
2017-11-18 13:06 0% ` Ada.Real_Time.Time_Last AdaMagica
@ 2017-11-18 13:18 0% ` Niklas Holsti
2017-11-18 14:00 0% ` Ada.Real_Time.Time_Last AdaMagica
0 siblings, 1 reply; 170+ results
From: Niklas Holsti @ 2017-11-18 13:18 UTC (permalink / raw)
On 17-11-18 15:06 , AdaMagica wrote:
> Am Freitag, 17. November 2017 22:39:51 UTC+1 schrieb Niklas Holsti:
>
>> Long ago, I suggested (on c.l.a) an Ada extension by which a package
>> could declare private types using the same classes of types that can be
>> used for generic formal types. That would IMO not only be useful for
>> programmers, it could formalise some of the informal text in the Ada RM.
>> For example, RM A.4.8 defines the type Ada.Direct_IO.Count as
>>
>> type Count is range 0 .. implementation defined;
>>
>> With the suggested extension, this could be written in legal (extended)
>> Ada as
>>
>> type Count is private range <>;
>>
>> That form still does not show that Count'First = 0, but with a little
>> further extension one could perhaps leave only the upper bound
>> unspecified, as in:
>>
>> type Count is private range 0 .. <>;
>>
>> Perhaps it is time for me to revive this proposal...
>>
> Problem with this is that private types have no predefined operators.
That is a problem with private types in *current* Ada, where a private
type is fully "opaque". This proposal is meant to remove this problem,
by letting the programmer provide more information about the private
type, in the same way as information can now be provided about generic
formal types, to equip those types with predefined operators that can be
used in the generic.
--
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
. @ .
^ permalink raw reply [relevance 0%]
* Re: Ada.Real_Time.Time_Last
2017-11-17 21:39 4% ` Ada.Real_Time.Time_Last Niklas Holsti
@ 2017-11-18 13:06 0% ` AdaMagica
2017-11-18 13:18 0% ` Ada.Real_Time.Time_Last Niklas Holsti
0 siblings, 1 reply; 170+ results
From: AdaMagica @ 2017-11-18 13:06 UTC (permalink / raw)
Am Freitag, 17. November 2017 22:39:51 UTC+1 schrieb Niklas Holsti:
> Long ago, I suggested (on c.l.a) an Ada extension by which a package
> could declare private types using the same classes of types that can be
> used for generic formal types. That would IMO not only be useful for
> programmers, it could formalise some of the informal text in the Ada RM.
> For example, RM A.4.8 defines the type Ada.Direct_IO.Count as
>
> type Count is range 0 .. implementation defined;
>
> With the suggested extension, this could be written in legal (extended)
> Ada as
>
> type Count is private range <>;
>
> That form still does not show that Count'First = 0, but with a little
> further extension one could perhaps leave only the upper bound
> unspecified, as in:
>
> type Count is private range 0 .. <>;
>
> Perhaps it is time for me to revive this proposal...
>
Problem with this is that private types have no predefined operators.
^ permalink raw reply [relevance 0%]
* Re: Ada.Real_Time.Time_Last
@ 2017-11-17 21:39 4% ` Niklas Holsti
2017-11-18 13:06 0% ` Ada.Real_Time.Time_Last AdaMagica
0 siblings, 1 reply; 170+ results
From: Niklas Holsti @ 2017-11-17 21:39 UTC (permalink / raw)
On 17-11-17 11:20 , Simon Wright wrote:
> Niklas Holsti <niklas.holsti@tidorum.invalid> writes:
>
>> On 17-11-15 16:28 , Simon Wright wrote:
>>> The only use case I can see for this is to allow us to write
>>>
>>> delay until Ada.Real_Time.Time_Last;
>>>
>>> at the end of our (Ravenscar) main program.
[snip]
>> (By the way, my Ravenscar programs always end in an eternal loop,
>> never in a delay until Time_Last.)
>
> Like
>
> loop
> null;
> end loop;
>
> ?
No, the environment task becomes one of the working application tasks
(why waste its stack space?), so more like
loop
Wait_For_Trigger_Or_Time;
Do_Something_Useful;
end loop;
> I'd have thought this would prevent the RTS from putting the processor
> to sleep, thus wasting energy.
In the only project I've done where the customer asked for sleep mode,
and we implemented it (that was in C, not Ada) the customer found,
during their system tests, that periodically entering and leaving sleep
mode caused supply-voltage transients that coupled into the analog parts
of the board and perturbed the instrument's ADC. So the SW was changed
to use an idle loop instead of sleeping. YMMV.
>> (By the further way, it is a pity that Ada does not let Ada.Real_Time
>> provide the attribute functions Time'Min and Time'Max.)
>
> I suppose there'd have to be a way of indicating that a private type was
> scalar.
Long ago, I suggested (on c.l.a) an Ada extension by which a package
could declare private types using the same classes of types that can be
used for generic formal types. That would IMO not only be useful for
programmers, it could formalise some of the informal text in the Ada RM.
For example, RM A.4.8 defines the type Ada.Direct_IO.Count as
type Count is range 0 .. implementation defined;
With the suggested extension, this could be written in legal (extended)
Ada as
type Count is private range <>;
That form still does not show that Count'First = 0, but with a little
further extension one could perhaps leave only the upper bound
unspecified, as in:
type Count is private range 0 .. <>;
Perhaps it is time for me to revive this proposal...
However, in the case of Ada.Real_Time.Time, it may be too much to
require that this type should be a scalar one, as it may need a
combination of range and precision that exceeds that of the largest
machine scalar.
--
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
. @ .
^ permalink raw reply [relevance 4%]
* An extra CR character when writing to file (in addition to CR LF)
@ 2016-06-05 23:26 5% John Smith
0 siblings, 0 replies; 170+ results
From: John Smith @ 2016-06-05 23:26 UTC (permalink / raw)
Here is my little example. The problem that I have with it is that when it comes time to writing to the output file, the newline characters for some reason are CR CR LF. I'm working in Windows, so I don't understand why I have the extra carriage return.
======================================================================
with Ada.Text_IO.Unbounded_IO;
with Ada.Strings.Unbounded;
with Ada.Command_Line;
with Ada.Directories;
with Ada.Direct_IO;
with Ada.Text_IO;
procedure stuff is
Original_File : Ada.Strings.Unbounded.Unbounded_String := Ada.Strings.Unbounded.To_Unbounded_String(
Source => "");
procedure Manipulate_Contents(
Contents : in out Ada.Strings.Unbounded.Unbounded_String) is
begin
Ada.Strings.Unbounded.Append(Contents, " A hello!");
end Manipulate_Contents;
procedure Write_File(
Contents : in out Ada.Strings.Unbounded.Unbounded_String;
File_Name : in Ada.Strings.Unbounded.Unbounded_String) is
New_File : Ada.Strings.Unbounded.Unbounded_String := Ada.Strings.Unbounded.To_Unbounded_String(
Source => "");
F_Type : Ada.Text_IO.File_Type;
begin
Ada.Text_IO.Put("Enter the name of the new file: ");
New_File := Ada.Text_IO.Unbounded_IO.Get_Line;
begin
Ada.Text_IO.Open(
File => F_Type,
Mode => Ada.Text_IO.Out_File,
Name => Ada.Strings.Unbounded.To_String(New_File));
exception
when Ada.Text_IO.Name_Error =>
Ada.Text_IO.Create(
File => F_Type,
Mode => Ada.Text_IO.Out_File,
Name => Ada.Strings.Unbounded.To_String(New_File));
end;
Ada.Text_IO.Put(
File => F_Type,
Item => Ada.Strings.Unbounded.To_String(Contents));
Ada.Text_IO.Close(
File => F_Type);
end Write_File;
begin
if Ada.Command_Line.Argument_Count = 1
then
Original_File := Ada.Strings.Unbounded.To_Unbounded_String(Ada.Command_Line.Argument(1));
else
Ada.Text_IO.Put_Line(
File => Ada.Text_IO.Standard_Error,
Item => "ERROR: Incorrect number of command line arguments passed in.");
return;
end if;
declare
File_Size : Natural := Natural(Ada.Directories.Size(Ada.Strings.Unbounded.To_String(Original_File)));
subtype File_String is String(1 .. File_Size);
package File_String_IO is new Ada.Direct_IO(File_String);
F_Type : File_String_IO.File_Type;
File_Contents : File_String;
U_File_Contents : Ada.Strings.Unbounded.Unbounded_String := Ada.Strings.Unbounded.To_Unbounded_String("");
begin
File_String_IO.Open(
File => F_Type,
Mode => File_String_IO.In_File,
Name => Ada.Strings.Unbounded.To_String(Original_File));
File_String_IO.Read(
File => F_Type,
Item => File_Contents);
File_String_IO.Close(
File => F_Type);
U_File_Contents := Ada.Strings.Unbounded.To_Unbounded_String(File_Contents);
Manipulate_Contents(
Contents => U_File_Contents);
Write_File(
Contents => U_File_Contents,
File_Name => Original_File);
exception
when Ada.Text_IO.Name_Error =>
Ada.Text_IO.Put_Line(Ada.Text_IO.Standard_Error, "ERROR:Name_Error: The file does not exist. Exiting.");
return;
when Ada.Text_IO.Status_Error =>
Ada.Text_IO.Put_Line(Ada.Text_IO.Standard_Error, "ERROR:Status_Error: The file does not exist. Exiting.");
return;
when Ada.Text_IO.Use_Error =>
Ada.Text_IO.Put_Line(Ada.Text_IO.Standard_Error, "ERROR:Use_Error: The file does not exist. Exiting.");
return;
when others =>
Ada.Text_IO.Put_Line(Ada.Text_IO.Standard_Error, "Error encountered, exiting.");
return;
end;
end stuff;
======================================================================
^ permalink raw reply [relevance 5%]
* Re: problems parse (large) json file with gnatcoll.json
2016-04-18 19:05 5% ` Björn Lundin
@ 2016-04-19 19:48 0% ` Shark8
0 siblings, 0 replies; 170+ results
From: Shark8 @ 2016-04-19 19:48 UTC (permalink / raw)
On Monday, April 18, 2016 at 1:12:49 PM UTC-6, björn lundin wrote:
>
> The loading function now looks like
>
> function Load_File(Filename : in String) return String is
> use Ada.Directories;
> File_Size : constant Natural := Natural (Size (Filename));
> subtype JSON_String is String (1 .. File_Size);
> type String_Ptr is access JSON_String;
> Content : constant String_Ptr := new JSON_String;
> package File_IO is new Ada.Direct_IO(JSON_String);
> File : File_IO.File_Type;
> begin
> File_IO.Open (File => File, Mode => File_IO.In_File,
> Name => Filename);
> File_IO.Read (File => File, Item => Content.all);
> File_IO.Close(File => File);
> return Content.all;
> end Load_File;
> --------------------------
Just replace the return w/ an extended return containing an instance of Unchecked_Deallocation; eg:
return Result : JSON_String := Content.all do
Free( Content ); -- "Free" is the instantiation of Unchecked_Deallocation.
end return;
*BUT*
You really shouldn't need it, IIRC when the type String_Ptr goes out of scope all instances should become invalid, thus allowing the compiler to reclaim it's memory from the storage pool.
^ permalink raw reply [relevance 0%]
* Re: problems parse (large) json file with gnatcoll.json
@ 2016-04-18 19:05 5% ` Björn Lundin
2016-04-19 19:48 0% ` Shark8
0 siblings, 1 reply; 170+ results
From: Björn Lundin @ 2016-04-18 19:05 UTC (permalink / raw)
On 2016-04-18 20:51, Jeffrey R. Carter wrote:
> I doubt the subtype declaration gives you Storage_Error. It should be if
> you declare an object of the subtype:
Of course you are correct.
I wonder how I misread the stacktrace that much.
Anyway your tip paid off.
> You can probably get around this by declaring an access type:
The loading function now looks like
function Load_File(Filename : in String) return String is
use Ada.Directories;
File_Size : constant Natural := Natural (Size (Filename));
subtype JSON_String is String (1 .. File_Size);
type String_Ptr is access JSON_String;
Content : constant String_Ptr := new JSON_String;
package File_IO is new Ada.Direct_IO(JSON_String);
File : File_IO.File_Type;
begin
File_IO.Open (File => File, Mode => File_IO.In_File,
Name => Filename);
File_IO.Read (File => File, Item => Content.all);
File_IO.Close(File => File);
return Content.all;
end Load_File;
--------------------------
and it works. Thanks. (I'll fix the leak later on)
The Load_File function is from
http://wiki.ada-dk.org/index.php/Handling_JSON_Using_GNATColl
--
Björn
^ permalink raw reply [relevance 5%]
* Re: most efficient method of storing records held in array
@ 2015-03-23 15:34 5% ` Jeffrey Carter
0 siblings, 0 replies; 170+ results
From: Jeffrey Carter @ 2015-03-23 15:34 UTC (permalink / raw)
On 03/23/2015 04:56 AM, tonyg wrote:
>
>
> Are there any other examples out there using this library? I was thinking of
> a generic library using direct io to save on the index whenever the values
> are changed.
I think efficiency is a poor reason to avoid a simple solution, at least until
you have tried it and found it doesn't meet your timing requirements.
However, it sounds as if, for your case, the simplest solution might be to hide
the array in a package and provide Put and Get operations, with Put writing the
new value to disk using Ada.Direct_IO.
--
Jeff Carter
"What's the amount of the insult?"
Never Give a Sucker an Even Break
104
^ permalink raw reply [relevance 5%]
* Gnat Pro Cross compiling
@ 2014-10-16 12:55 7% Nahro Nadir
0 siblings, 0 replies; 170+ results
From: Nahro Nadir @ 2014-10-16 12:55 UTC (permalink / raw)
I am trying to use gnat pro as a cross compiler which use arm-eabi toolchain, but it cannot recognize any Ada packages!!
Here is compilation result:
5:6 "ada.calendar" is not a predefined library unit
2:6 "ada.direct_io" is not a predefined library unit
8:6 "ada.float_text_io" is not a predefined library unit
7:6 "ada.integer_text_io" is not a predefined library unit
10:6 "ada.numerics" is not a predefined library unit
2:6 "ada.text_io" is not a predefined library unit
2:6 "bmp (spec)" depends on "ada.direct_io (spec)"
2:6 "bmp (spec)" depends on "ada.text_io (spec)"
3:6 "serial_net (spec)" depends on "gnat.sockets (spec)"
2:6 "stream (body)" depends on "bmp (spec)"
3:6 "stream (body)" depends on "serial_net (spec)"
3:6 file "g-socket.ads" not found
^ permalink raw reply [relevance 7%]
* Re: Ada vs SQLite3 benchmark
@ 2014-09-18 20:08 8% ` Dmitry A. Kazakov
0 siblings, 0 replies; 170+ results
From: Dmitry A. Kazakov @ 2014-09-18 20:08 UTC (permalink / raw)
On Thu, 18 Sep 2014 01:08:46 -0700 (PDT), briot.emmanuel@gmail.com wrote:
> Why did you run the benchmarks without optimization ? That seems
> inconsistent. If you are measuring performance, you should run with full
> optimization on I think.
Optimization could remove or rearrange parts of code which would not happen
in a real-life case. For example doing something like
for I in 1..1000 loop
N := I;
end loop;
could be optimized to N := 1000.
IMO, not optimized code is a better measure for algorithmic complexity.
> Also, it would be interesting to use the following pragmas (combined or
> not) in sqlite, since they can impact performance significantly:
> pragma journal_mode=WAL;
> pragma synchronous=OFF; (unless the Ada code is also running fsync() regularly)
>
> I think the latter in particular will significantly change the time measured for sqlite.
Thanks for pointing this.
Regarding Ada, it was strictly Ada.Direct_IO, nothing else. Ada.Direct_IO
does not have Flush [*]. As far as I can tell GNAT's implementation of
Ada.Direct_IO.Write is fwrite not followed by fsync. So forcing SQLite to
sync might be unfair. However, the intended use surely must sync upon
commit.
-----------
* Maybe it is worth an AI to add Flush to Direct_IO.
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
^ permalink raw reply [relevance 8%]
* Re: Ada vs SQLite3 benchmark
2014-09-17 16:51 6% Ada vs SQLite3 benchmark Dmitry A. Kazakov
` (2 preceding siblings ...)
2014-09-18 5:50 0% ` Georg Bauhaus
@ 2014-09-18 17:09 0% ` Pascal Obry
3 siblings, 0 replies; 170+ results
From: Pascal Obry @ 2014-09-18 17:09 UTC (permalink / raw)
Le mercredi 17 septembre 2014 à 18:51 +0200, Dmitry A. Kazakov a
écrit :
> I posted benchmark of Ada persistent B-tree vs. SQLite3 at Ada Programming
> blog:
>
> http://ada-programming.blogspot.de/2014/09
>
> The implementation of B-tree is based on Ada.Direct_IO with a transaction
> layer, e.g. for safety against system failure.
Ok, but you don't have the full SQL language. For my v2p application I
do have some complex SQL transaction that would be difficult to
translate in plain Direct_IO call.
But if SQL is not needed your B-tree looks quite nice.
--
Pascal Obry / Magny Les Hameaux (78)
The best way to travel is by means of imagination
http://v2p.fr.eu.org
http://www.obry.net
gpg --keyserver keys.gnupg.net --recv-key F949BD3B
^ permalink raw reply [relevance 0%]
* Re: Ada vs SQLite3 benchmark
2014-09-18 0:16 0% ` Jeffrey Carter
@ 2014-09-18 7:31 0% ` Dmitry A. Kazakov
0 siblings, 0 replies; 170+ results
From: Dmitry A. Kazakov @ 2014-09-18 7:31 UTC (permalink / raw)
On Wed, 17 Sep 2014 17:16:35 -0700, Jeffrey Carter wrote:
> On 09/17/2014 09:51 AM, Dmitry A. Kazakov wrote:
>> I posted benchmark of Ada persistent B-tree vs. SQLite3 at Ada Programming
>> blog:
>>
>> http://ada-programming.blogspot.de/2014/09
>>
>> The implementation of B-tree is based on Ada.Direct_IO with a transaction
>> layer, e.g. for safety against system failure.
>
> Is your B-tree/Direct_IO version task safe?
Yes. It uses a persistent memory pool on top of the file. The pool has a
protected object implementing a mutex and tree operations run with the
mutex taken.
> Is your version of SQLite compiled
> to be thread safe?
Should be as the SQLite DB is opened with the FULL_MUTEX option. The
documentation is somehow fuzzy about the effects of FULL_MUTEX, but I
suppose it should make it task-safe.
As far as I can tell the most time-consuming part of SQLite operations was
commit. Immutable operations are way quicker.
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
^ permalink raw reply [relevance 0%]
* Re: Ada vs SQLite3 benchmark
2014-09-18 5:50 0% ` Georg Bauhaus
@ 2014-09-18 7:27 0% ` Dmitry A. Kazakov
0 siblings, 1 reply; 170+ results
From: Dmitry A. Kazakov @ 2014-09-18 7:27 UTC (permalink / raw)
On Thu, 18 Sep 2014 07:50:09 +0200, Georg Bauhaus wrote:
> On 17.09.14 18:51, Dmitry A. Kazakov wrote:
>> http://ada-programming.blogspot.de/2014/09
>>
>> The implementation of B-tree is based on Ada.Direct_IO with a transaction
>> layer, e.g. for safety against system failure.
>
> What will the comparison look like if you let SQLite3 open the file
> ":memory:", thus an in-memory data base? Which will require to then
> occasionally .dump its contents into another, persistent SQLite3 database.
>
> http://www.sqlite.org/inmemorydb.html
In would make no sense, IMO.
Let us consider the use case when everything fits into the memory. Why not
to use plain containers then?
Even if some sort of persistency is needed in this scenario, a persistency
layer can be added to a plain Ada container at *zero* performance cost.
E.g.
http://www.dmitry-kazakov.de/ada/components.htm#persistent_objects
I can tell without any benchmarks that Ada's standard containers or any
other would easily beat memory-mapped SQLite.
P.S. I had serious problems with the Kyoto Cabinet in the past. KC is a
single-file B-tree implementation written in C. It is not fail-safe, but
that was irrelevant to me. KC did what you described by OS means, it opened
the file as memory mapped. I was unaware of that until the DB grew 2GB,
then ... I am a bit allergic to memory-mapped files since.
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
^ permalink raw reply [relevance 0%]
* Re: Ada vs SQLite3 benchmark
2014-09-17 16:51 6% Ada vs SQLite3 benchmark Dmitry A. Kazakov
2014-09-17 23:26 0% ` gdotone
2014-09-18 0:16 0% ` Jeffrey Carter
@ 2014-09-18 5:50 0% ` Georg Bauhaus
2014-09-18 7:27 0% ` Dmitry A. Kazakov
2014-09-18 17:09 0% ` Pascal Obry
3 siblings, 1 reply; 170+ results
From: Georg Bauhaus @ 2014-09-18 5:50 UTC (permalink / raw)
On 17.09.14 18:51, Dmitry A. Kazakov wrote:
> http://ada-programming.blogspot.de/2014/09
>
> The implementation of B-tree is based on Ada.Direct_IO with a transaction
> layer, e.g. for safety against system failure.
What will the comparison look like if you let SQLite3 open the file
":memory:", thus an in-memory data base? Which will require to then
occasionally .dump its contents into another, persistent SQLite3 database.
http://www.sqlite.org/inmemorydb.html
^ permalink raw reply [relevance 0%]
* Re: Ada vs SQLite3 benchmark
2014-09-17 16:51 6% Ada vs SQLite3 benchmark Dmitry A. Kazakov
2014-09-17 23:26 0% ` gdotone
@ 2014-09-18 0:16 0% ` Jeffrey Carter
2014-09-18 7:31 0% ` Dmitry A. Kazakov
2014-09-18 5:50 0% ` Georg Bauhaus
2014-09-18 17:09 0% ` Pascal Obry
3 siblings, 1 reply; 170+ results
From: Jeffrey Carter @ 2014-09-18 0:16 UTC (permalink / raw)
On 09/17/2014 09:51 AM, Dmitry A. Kazakov wrote:
> I posted benchmark of Ada persistent B-tree vs. SQLite3 at Ada Programming
> blog:
>
> http://ada-programming.blogspot.de/2014/09
>
> The implementation of B-tree is based on Ada.Direct_IO with a transaction
> layer, e.g. for safety against system failure.
Is your B-tree/Direct_IO version task safe? Is your version of SQLite compiled
to be thread safe?
--
Jeff Carter
"Perfidious English mouse-dropping hoarders."
Monty Python & the Holy Grail
10
^ permalink raw reply [relevance 0%]
* Re: Ada vs SQLite3 benchmark
2014-09-17 16:51 6% Ada vs SQLite3 benchmark Dmitry A. Kazakov
@ 2014-09-17 23:26 0% ` gdotone
2014-09-18 0:16 0% ` Jeffrey Carter
` (2 subsequent siblings)
3 siblings, 0 replies; 170+ results
From: gdotone @ 2014-09-17 23:26 UTC (permalink / raw)
On Wednesday, September 17, 2014 12:52:51 PM UTC-4, Dmitry A. Kazakov wrote:
> I posted benchmark of Ada persistent B-tree vs. SQLite3 at Ada Programming
> blog:
> http://ada-programming.blogspot.de/2014/09
> The implementation of B-tree is based on Ada.Direct_IO with a transaction
> layer, e.g. for safety against system failure.
amazing!
^ permalink raw reply [relevance 0%]
* Ada vs SQLite3 benchmark
@ 2014-09-17 16:51 6% Dmitry A. Kazakov
2014-09-17 23:26 0% ` gdotone
` (3 more replies)
0 siblings, 4 replies; 170+ results
From: Dmitry A. Kazakov @ 2014-09-17 16:51 UTC (permalink / raw)
I posted benchmark of Ada persistent B-tree vs. SQLite3 at Ada Programming
blog:
http://ada-programming.blogspot.de/2014/09
The implementation of B-tree is based on Ada.Direct_IO with a transaction
layer, e.g. for safety against system failure.
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
^ permalink raw reply [relevance 6%]
* Re: GNAT Ada.Direct_IO bug
2014-09-07 12:58 13% GNAT Ada.Direct_IO bug Dmitry A. Kazakov
@ 2014-09-07 14:28 7% ` Pascal Obry
0 siblings, 0 replies; 170+ results
From: Pascal Obry @ 2014-09-07 14:28 UTC (permalink / raw)
Le dimanche 07 septembre 2014 à 14:58 +0200, Dmitry A. Kazakov a
écrit :
> I have verified this under Windows 7 64-bit (NTFS) and 32-bit Linux and
> Fedora. It seems that the implementation of GNAT Ada.Direct_IO is limited
> to 2Gb file sizes regardless that the underlying OS has no such constraint.
> Here is the test program:
Right. And this is fixed in recent GNAT versions. Should be working with
GNAT GPL 2015.
--
Pascal Obry / Magny Les Hameaux (78)
The best way to travel is by means of imagination
http://v2p.fr.eu.org
http://www.obry.net
gpg --keyserver keys.gnupg.net --recv-key F949BD3B
^ permalink raw reply [relevance 7%]
* GNAT Ada.Direct_IO bug
@ 2014-09-07 12:58 13% Dmitry A. Kazakov
2014-09-07 14:28 7% ` Pascal Obry
0 siblings, 1 reply; 170+ results
From: Dmitry A. Kazakov @ 2014-09-07 12:58 UTC (permalink / raw)
I have verified this under Windows 7 64-bit (NTFS) and 32-bit Linux and
Fedora. It seems that the implementation of GNAT Ada.Direct_IO is limited
to 2Gb file sizes regardless that the underlying OS has no such constraint.
Here is the test program:
------------------------------------------------------------
with Ada.Direct_IO;
with Ada.Text_IO; use Ada.Text_IO;
procedure Test_DIO is
type Block is array (1..1024) of Character;
for Block'Size use 1024*8;
package DIO is new Ada.Direct_IO (Block);
File : DIO.File_Type;
Data : Block := (others => ' ');
begin
DIO.Create (File);
for Giga in 1..2 loop
for Mega in 1..1024 loop
for Kilo in 1..1024 loop
DIO.Write (File, Data);
end loop;
end loop;
Put_Line ("File size" & DIO.Count'Image (DIO.Size (File)) & "
Kbytes");
end loop;
end Test_DIO;
-------------------------------------------------------------
Under Windows [GNAT GPL gpl-2014 (20140405)] it silently wraps the file to
zero size. So the output looks like:
>test_dio.exe
File size 1048576 Kbytes
File size 0 Kbytes
32-bit Debian [4.9.1 (Debian 4.9.1-4)] exposes the same behavior as
Windows.
[64-bit Fedora and Debian work as expected]
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
^ permalink raw reply [relevance 13%]
* Re: Generating an XML DOM tree from scratch withXML/Ada 2013
@ 2014-03-21 16:12 5% ` J Kimball
0 siblings, 0 replies; 170+ results
From: J Kimball @ 2014-03-21 16:12 UTC (permalink / raw)
On 03/20/2014 12:00 PM, Marc C wrote:
> After writing up some pathfinding code to simply create a DOM document tree from scratch, add a node, and write it out, I was perplexed that the namespace data I was supplying was not showing up in the document.
>
> Imagine my surprise when looking at the Dom.Core.Create_Document() implementation and seeing that the Namespace_URI (and Qualified_Name) parameters are simply ignored. The comment in the spec simply states "Note that Namespace_URI can be the empty string if you do not want to use namespaces."
>
> Well, I *do* want (and need) to use namespaces.
>
> The implementation of various subprograms reference namespaces and qualified names, and that seems to somehow tie into the SAX Symbol_Table that can be provided to Create_Document. But it ain't clear what one would have to do in that regard, not to mention I'm not sure I'm even reading the code right about all that.
>
> I've got XML_EZ_Out for outputting XML, but in this instance I preferred to build the DOM tree and manipulate it, then write the whole thing out when I was done.
>
> Anyone used the GNAT GPL 2013 XML/Ada packages for creating DOM trees with namespaces?
>
> Thanks.
>
> Marc A. Criley
>
I have done this. The organization and documentation of XML is perplexing and I've also spent hours banging my head against a wall trying to use namespaces and validation.
Here's a result of my labor. I hope you can make some sense of it. Unfortunately, I couldn't find the input files that i was using to test.
There are two command line arguments. I think the first is the xml file and the second is a valid XSD schema.
Good luck.
--
with Ada.Command_Line;
with Ada.Directories;
with Ada.Direct_IO;
with Ada.Exceptions;
with Ada.Text_IO;
with DOM.Core.Elements;
with DOM.Core.Nodes;
with Input_Sources.File;
with Input_Sources.Strings;
with SAX.Readers;
with Schema.DOM_Readers;
with Schema.Schema_Readers;
with Schema.Validators;
with Unicode.CES.Utf8;
procedure Validate_Message is
Grammar : Schema.Validators.XML_Grammar;
Agent_NS : String := "http://example.com/schemas/agent";
function Get_Message (XML : String) return String is
Input : Input_Sources.Strings.String_Input;
Reader : Schema.DOM_Readers.Tree_Reader;
Document : DOM.Core.Document;
Elements : DOM.Core.Node_List;
begin
Input_Sources.Strings.Open (Str => XML, Encoding => Unicode.CES.Utf8.Utf8_Encoding, Input => Input);
Schema.DOM_Readers.Set_Grammar (Reader, Grammar);
Schema.DOM_Readers.Set_Feature (Reader, SAX.Readers.Namespace_Prefixes_Feature, True);
Schema.DOM_Readers.Set_Feature (Reader, SAX.Readers.Namespace_Feature, True);
-- Schema.DOM_Readers.Set_Feature (Reader, SAX.Readers.Validation_Feature, True);
Schema.DOM_Readers.Parse (Reader, Input);
Input_Sources.Strings.Close (Input);
Document := Schema.DOM_Readers.Get_Tree (Reader);
Schema.DOM_Readers.Free (Reader);
Elements := DOM.Core.Elements.Get_Elements_By_Tag_Name_NS (Elem => Document, Namespace_URI => Agent_NS, Local_Name => "message");
return DOM.Core.Nodes.Node_Value (DOM.Core.Nodes.Item (Elements, 0) );
exception
when E : others =>
Ada.Text_IO.Put_Line (Ada.Exceptions.Exception_Information (E) );
raise;
end Get_Message;
function Init_Grammar return Schema.Validators.XML_Grammar is
Reader : Schema.Schema_Readers.Schema_Reader;
Input : Input_Sources.File.File_Input;
begin
Input_Sources.File.Open (Ada.Command_Line.Argument (2), Input);
Schema.Schema_Readers.Parse (Reader, Input);
Input_Sources.File.Close (Input);
return Schema.Schema_Readers.Get_Grammar (Reader);
end Init_Grammar;
File_Size : Ada.Directories.File_Size := Ada.Directories.Size (Ada.Command_Line.Argument (1) );
subtype File_Input is String (1..Integer (File_Size) );
package File_IO is new Ada.Direct_IO (Element_Type => File_Input);
File : File_IO.File_Type;
Input : File_Input;
begin
Schema.Set_Debug_Output (True);
-- Schema.Dump_Internal_XSD := True;
File_IO.Open (File => File, Mode => File_IO.In_File, Name => Ada.Command_Line.Argument (1) );
File_IO.Read (File => File, Item => Input);
File_IO.Close (File => File);
Grammar := Init_Grammar;
Ada.Text_IO.Put_Line (Get_Message (Input) );
end Validate_Message;
^ permalink raw reply [relevance 5%]
* Re: Ada.Storage_IO: applied example?
@ 2012-10-24 14:03 7% ` Georg Bauhaus
0 siblings, 0 replies; 170+ results
From: Georg Bauhaus @ 2012-10-24 14:03 UTC (permalink / raw)
On 24.10.12 13:51, Yannick Duchêne (Hibou57) wrote:
> Le Wed, 24 Oct 2012 12:28:00 +0200, Dmitry A. Kazakov
> <mailbox@dmitry-kazakov.de> a écrit:
>
>> On Wed, 24 Oct 2012 02:49:02 -0700 (PDT), AdaMagica wrote:
>>
>>> See AARM A.9(1.a):
>>> Reason: This package exists to allow the portable construction of
>>> user-defined direct-access-oriented input-output packages.
>>
>> portable construction of X /= construction of portable X
>>
>> The package cannot be used to write files in a way that an application
>> compiled by one compiler X1 under OS Y1 could write a file readable for
>> compiler X2 under OS Y2.
>>
>> In order to be portable they should have defined the exact representation
>> of the object in the file. Yes, nobody would do that, but then they should
>> not include useless packages into the standard either.
>
> What about private persistent storage?
>
If traditional Ada I/O is good for your Ada program, you
can use Storage_IO in conventional algorithms this way. The
setup can employ static polymorphism that allows selecting
instances of Storage_IO or Direct_IO as needed.
Either at startup or later.
<rant>
The solution, using the egregious generic mechanisms of Ada,
will suffer from all the advantages of lack of an unused
tagged parameter.
The whole approach of stating requirements as generic formals
suffers from good opportunities for compilers to perform
optimization.
It suffers from the fact that stored internal program
data is not being stored in an ISO-approved form ready for
inspection by non-generic programs of an unrelated make
and purpose.
It also suffers from the problem that it still cannot make
the external world an Ada object, which could mollify the
previously argued flaw.
It suffers from lack of opportunities to control I/O of
octets algorithmically, thus preventing emulation of nice
per-program Storage_IO objects in DIY fashion.
It also suffers from not being a silver bullet.
But other than that ...</rant>
with Ada.Direct_IO;
with Ada.Storage_IO;
with Ada.Command_Line; use Ada.Command_Line;
procedure Lookahead is
use Ada;
type Sentence (Length : Positive := 100) is record
Text : Wide_String (1 .. 100);
end record;
subtype Name is Wide_String (1 .. 20);
type Big is record -- objects that will be processed
First, Last : Name;
Age : Natural;
Motto : Sentence;
end record;
generic
with procedure Store_Single_Item (Item : in Big);
with procedure Fetch_Single_Item (Item : out Big);
procedure Process_Records;
procedure Process_Records is separate;
begin
if Natural'Value (Argument(1)) = 0 then
declare
package Volatile is
procedure Store (Item : in Big);
procedure Fetch (Item : out Big);
end Volatile;
package body Volatile is
package Undo_Buffer is new Storage_IO (Big);
Storage : Undo_Buffer.Buffer_Type;
procedure Fetch (Item : out Big) is
begin
Undo_Buffer.Read (Storage, Item);
end Fetch;
procedure Store (Item : in Big) is
begin
Undo_Buffer.Write (Storage, Item);
end Store;
end Volatile;
procedure Run is new Process_Records
(Store_Single_Item => Volatile.Store,
Fetch_Single_Item => Volatile.Fetch);
begin
Run;
end;
else
declare
package Permanent is
procedure Store (Item : in Big);
procedure Fetch (Item : out Big);
end Permanent;
package body Permanent is
package Undo_Buffer is new Direct_IO (Big);
Storage : Undo_Buffer.File_Type;
procedure Fetch (Item : out Big) is
begin
Undo_Buffer.Read (Storage, Item);
end Fetch;
procedure Store (Item : in Big) is
begin
Undo_Buffer.Write (Storage, Item);
end Store;
use Undo_Buffer;
begin
open (storage, Inout_File, "item.sto");
end Permanent;
procedure Run is new Process_Records
(Store_Single_Item => Permanent.Store,
Fetch_Single_Item => Permanent.Fetch);
begin
Run;
end;
end if;
end Lookahead;
separate (Lookahead)
procedure Process_Records is
package Rec_IO is new Direct_IO (Big); use Rec_IO;
Current: Big := (Age => Natural'Last, others => <>);
input : File_Type;
output : File_Type;
begin
open (input, In_File, "records.all");
open (output, Out_File, "records.flt");
loop
Store_Single_Item (Current);
Read (input, current);
-- ... filter based on pairs ...
write (output, current);
end loop;
end Process_Records;
^ permalink raw reply [relevance 7%]
* Ada.Storage_IO: applied example?
@ 2012-10-23 19:42 5% Yannick Duchêne (Hibou57)
0 siblings, 1 reply; 170+ results
From: Yannick Duchêne (Hibou57) @ 2012-10-23 19:42 UTC (permalink / raw)
Hi all the people,
I'm seeking for a tiny use case showing `Ada.Storage_IO` in action. I also
believe the topic is worth for many people, beginners or not, as this is
the kind of stuff so typical of Ada. I always liked the clean distinction
Ada makes between streams and files. Looking for some reminder about it in
the RM, I just noticed this `Ada.Storage_IO` I've never noticed before.,
but feel surprised the buffer always contains a single element; thus the
question. The RM makes a reference from there to `Ada.Direct_IO`, but the
latter does not reciprocally mention the former.
--
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University
^ permalink raw reply [relevance 5%]
* Re: Should Inline be private in the private part of a package spec?
@ 2012-08-11 4:48 5% ` Vasiliy Molostov
2012-08-11 5:12 0% ` Shark8
0 siblings, 1 reply; 170+ results
From: Vasiliy Molostov @ 2012-08-11 4:48 UTC (permalink / raw)
Shark8 <onewingedshark@gmail.com> писал(а) в своём письме Fri, 10 Aug 2012
20:45:03 +0400:
> Indeed so. In fact, I think that's just scraping the surface of how an
> OS should handle files. It should have files [strongly-]typed, perhaps
> with a validated flag to indicate that that type is known to be true
> (perhaps the type indicator implemented as a signed 64-bit integer,
> which would have a magnitude indicating the file-type; negative values
> indicating non-validated files. [0 would be a straight-up binary file,
> as all files would be binary it makes no sense for validation thereon;
> the extra-negative value, assuming 2's complement, could indicate truly
> unknown]). Furthermore, each file-type should have a corresponding
> object which knows how to read, write & validate itself.
Perhaps you might know that ada.direct_io is a carbon copy of record
oriented files implemented in vms,
and a rest (historical sublime) of that file system is currently named as
ntfs?
--
Написано в почтовом клиенте браузера Opera: http://www.opera.com/mail/
^ permalink raw reply [relevance 5%]
* Re: Should Inline be private in the private part of a package spec?
2012-08-11 4:48 5% ` Vasiliy Molostov
@ 2012-08-11 5:12 0% ` Shark8
0 siblings, 0 replies; 170+ results
From: Shark8 @ 2012-08-11 5:12 UTC (permalink / raw)
On Friday, August 10, 2012 10:48:20 PM UTC-6, Vasiliy Molostov wrote:
> Shark8 <onewingedshark@gmail.com> писал(а) в своём письме Fri, 10 Aug 2012
> 20:45:03 +0400:
>
>
> > Indeed so. In fact, I think that's just scraping the surface of how an
> > OS should handle files. It should have files [strongly-]typed, perhaps
> > with a validated flag to indicate that that type is known to be true
> > (perhaps the type indicator implemented as a signed 64-bit integer,
> > which would have a magnitude indicating the file-type; negative values
> > indicating non-validated files. [0 would be a straight-up binary file,
> > as all files would be binary it makes no sense for validation thereon;
> > the extra-negative value, assuming 2's complement, could indicate truly
> > unknown]). Furthermore, each file-type should have a corresponding
> > object which knows how to read, write & validate itself.
>
> Perhaps you might know that ada.direct_io is a carbon copy of record
> oriented files implemented in vms,
> and a rest (historical sublime) of that file system is currently named as
> ntfs?
I didn't know that about Direct_IO; that's really interesting.
Is NTFS really that much of a decedent of VMS's file-system? I was under the impression that VMS's had quite a few more features than NTFS, though it's been a long while since I read-up on FSes.
^ permalink raw reply [relevance 0%]
* Re: xor
2012-03-29 23:41 0% ` xor Randy Brukardt
@ 2012-03-30 21:53 7% ` Niklas Holsti
0 siblings, 0 replies; 170+ results
From: Niklas Holsti @ 2012-03-30 21:53 UTC (permalink / raw)
On 12-03-30 02:41 , Randy Brukardt wrote:
> "Niklas Holsti"<niklas.holsti@tidorum.invalid> wrote in message
> news:9ti9k2FjcvU1@mid.individual.net...
>> On 12-03-29 02:25 , Randy Brukardt wrote:
>>> "Niklas Holsti"<niklas.holsti@tidorum.invalid> wrote in message
>>> news:9tgqomFflrU1@mid.individual.net...
>>>> On 12-03-28 18:23 , Michael Moeller wrote:
>>> ...
>>>>> I don't want to push your helpfulness to far, but I still don't
>>>>> know whether there is any means to determine the size of a file
>>>>> from within Ada other than using a C subroutine calling fstat.
>>>>
>>>> Two ways:
>>>>
>>>> - Ada.Directories.Size, given the file name.
>>>> - Ada.Direct_IO.Size, given an open (Direct_IO) file.
>>>
>>> Actually, three ways:
>>
>> Ok, I showed two ways, but did not mean that there aren't other ways.
>>
>>> Ada.Stream_IO.Size, given an open (Stream_IO) file.
>>
>> If "positioning is not supported" for the stream file, the result of
>> Ada.Stream_IO.Size is implementation defined. Positioning is probably
>> supported for the kinds of files the OP uses now, but it is a bit of trap
>> for possible future uses of the program, for example if the program is
>> later used in a shell pipeline. A pipe probably does not support
>> positioning.
>
> I'm pretty sure that if "positioning is not supported" for a particular
> stream file, none of the other mechanisms will provide any useful answers,
> either. That's especially true as most Ada compilers use a common I/O system
> to implement all of these packages, so the effects will be similar on all of
> them.
>
> File for which "positioning is not supported" are likely to be things like
> sockets, pipes, and devices. Those won't have a meaningful size no matter
> how they're accessed.
I agree, but I think it is much more likely that Ada.Streams will
encounter such a file, than is the case for Ada.Directories or
Ada.Direct_IO. Also, I think that Ada.Direct_IO.Open should raise
Use_Error for such files (but this does not seem to be required in the RM).
> In any case, your point is really just another argument for not depending
> upon the size at all; depending on the sort of file, it may not even be a
> meaningful concept. So depending on the size decreases the utility and
> reusability of your code.
Agreed.
> That said, the OP knows that and it surely is
> their decision how to write their code.
And now the OP has several ways to find the Size, including some
warnings about when these ways may not work (and fstat would not work
either).
--
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
. @ .
^ permalink raw reply [relevance 7%]
* Re: xor
2012-03-29 5:17 0% ` xor Niklas Holsti
@ 2012-03-29 23:41 0% ` Randy Brukardt
2012-03-30 21:53 7% ` xor Niklas Holsti
0 siblings, 1 reply; 170+ results
From: Randy Brukardt @ 2012-03-29 23:41 UTC (permalink / raw)
"Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message
news:9ti9k2FjcvU1@mid.individual.net...
> On 12-03-29 02:25 , Randy Brukardt wrote:
>> "Niklas Holsti"<niklas.holsti@tidorum.invalid> wrote in message
>> news:9tgqomFflrU1@mid.individual.net...
>>> On 12-03-28 18:23 , Michael Moeller wrote:
>> ...
>>>> I don't want to push your helpfulness to far, but I still don't
>>>> know whether there is any means to determine the size of a file
>>>> from within Ada other than using a C subroutine calling fstat.
>>>
>>> Two ways:
>>>
>>> - Ada.Directories.Size, given the file name.
>>> - Ada.Direct_IO.Size, given an open (Direct_IO) file.
>>
>> Actually, three ways:
>
> Ok, I showed two ways, but did not mean that there aren't other ways.
>
>> Ada.Stream_IO.Size, given an open (Stream_IO) file.
>
> If "positioning is not supported" for the stream file, the result of
> Ada.Stream_IO.Size is implementation defined. Positioning is probably
> supported for the kinds of files the OP uses now, but it is a bit of trap
> for possible future uses of the program, for example if the program is
> later used in a shell pipeline. A pipe probably does not support
> positioning.
I'm pretty sure that if "positioning is not supported" for a particular
stream file, none of the other mechanisms will provide any useful answers,
either. That's especially true as most Ada compilers use a common I/O system
to implement all of these packages, so the effects will be similar on all of
them.
File for which "positioning is not supported" are likely to be things like
sockets, pipes, and devices. Those won't have a meaningful size no matter
how they're accessed. I suppose an implementer could make all stream files
not support positioning and do something different for Text_IO, but as is
commonly mentioned, "implementers don't intentionally cripple their
implementations".
In any case, your point is really just another argument for not depending
upon the size at all; depending on the sort of file, it may not even be a
meaningful concept. So depending on the size decreases the utility and
reusability of your code. That said, the OP knows that and it surely is
their decision how to write their code.
Randy.
^ permalink raw reply [relevance 0%]
* Re: xor
2012-03-28 23:25 0% ` xor Randy Brukardt
@ 2012-03-29 5:17 0% ` Niklas Holsti
2012-03-29 23:41 0% ` xor Randy Brukardt
0 siblings, 1 reply; 170+ results
From: Niklas Holsti @ 2012-03-29 5:17 UTC (permalink / raw)
On 12-03-29 02:25 , Randy Brukardt wrote:
> "Niklas Holsti"<niklas.holsti@tidorum.invalid> wrote in message
> news:9tgqomFflrU1@mid.individual.net...
>> On 12-03-28 18:23 , Michael Moeller wrote:
> ...
>>> I don't want to push your helpfulness to far, but I still don't
>>> know whether there is any means to determine the size of a file
>>> from within Ada other than using a C subroutine calling fstat.
>>
>> Two ways:
>>
>> - Ada.Directories.Size, given the file name.
>> - Ada.Direct_IO.Size, given an open (Direct_IO) file.
>
> Actually, three ways:
Ok, I showed two ways, but did not mean that there aren't other ways.
> Ada.Stream_IO.Size, given an open (Stream_IO) file.
If "positioning is not supported" for the stream file, the result of
Ada.Stream_IO.Size is implementation defined. Positioning is probably
supported for the kinds of files the OP uses now, but it is a bit of
trap for possible future uses of the program, for example if the program
is later used in a shell pipeline. A pipe probably does not support
positioning.
--
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
. @ .
^ permalink raw reply [relevance 0%]
* Re: xor
2012-03-28 15:58 7% ` xor Niklas Holsti
2012-03-28 17:28 0% ` xor Michael Moeller
@ 2012-03-28 23:25 0% ` Randy Brukardt
2012-03-29 5:17 0% ` xor Niklas Holsti
1 sibling, 1 reply; 170+ results
From: Randy Brukardt @ 2012-03-28 23:25 UTC (permalink / raw)
"Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message
news:9tgqomFflrU1@mid.individual.net...
> On 12-03-28 18:23 , Michael Moeller wrote:
...
>> I don't want to push your helpfulness to far, but I still don't
>> know whether there is any means to determine the size of a file
>> from within Ada other than using a C subroutine calling fstat.
>
> Two ways:
>
> - Ada.Directories.Size, given the file name.
> - Ada.Direct_IO.Size, given an open (Direct_IO) file.
Actually, three ways:
Ada.Stream_IO.Size, given an open (Stream_IO) file.
The latter is what I'd do for the problem at hand, although the other
packages are probably easier to understand. (OTOH, Stream_IO is closest to
the underlying I/O APIs on every target I've worked with, so it may be more
familar.)
Randy.
^ permalink raw reply [relevance 0%]
* Re: xor
2012-03-28 15:58 7% ` xor Niklas Holsti
@ 2012-03-28 17:28 0% ` Michael Moeller
2012-03-28 23:25 0% ` xor Randy Brukardt
1 sibling, 0 replies; 170+ results
From: Michael Moeller @ 2012-03-28 17:28 UTC (permalink / raw)
On Wed, 28 Mar 2012, Niklas Holsti wrote:
> But, from the solution that Georg gave you, it seems that your difficulty was
> not about I/O in Ada, but about the Ada package concept, context clauses
> ("with"), and perhaps generics, none of which are specifically related to
> I/O, and all of which you need to know anyway, in order to be productive in
> Ada.
That's right. I had to start somewhere but quickly got stuck. First I
didn't find anything on byte-level I/O in my documentation, then there was
this problem with visibility.
>
> Two ways:
>
> - Ada.Directories.Size, given the file name.
> - Ada.Direct_IO.Size, given an open (Direct_IO) file.
>
Thanks.
Regards,
Michael
^ permalink raw reply [relevance 0%]
* Re: xor
@ 2012-03-28 15:58 7% ` Niklas Holsti
2012-03-28 17:28 0% ` xor Michael Moeller
2012-03-28 23:25 0% ` xor Randy Brukardt
0 siblings, 2 replies; 170+ results
From: Niklas Holsti @ 2012-03-28 15:58 UTC (permalink / raw)
On 12-03-28 18:23 , Michael Moeller wrote:
>
>
> On Wed, 28 Mar 2012, Georg Bauhaus wrote:
>
>> On 28.03.12 14:18, Michael Moeller wrote:
>>
>>> While this example compiles without complaints it
>>> doesn't work with procedures declared in my package. How can I
>>> make Sequential_IO visible there?
>>
>> Instantiate Sequential_IO where you need it:
[snip solution using packages and "with"]
>>> Its a little strange, though, how dead easy coding concurrency
>>> on a Sun machine was recently while I'm not able to write out
>>> some silly bytes using the very same language.
>>
>> This is not unusual, I think, insofar as virtually every language
>> requires some effort when I/O is more than "print". Python,
>> Java, Ada, C, C++, they all have some frowned upon simple I/O procedures,
>> and then the real thing. The latter takes time getting used to.
[snip]
> Thanks again for your quick and competent answers. This works.
>
> I agree with you on I/O. I've seen many languages and most often
> I/O is pretty peculiar.
But, from the solution that Georg gave you, it seems that your
difficulty was not about I/O in Ada, but about the Ada package concept,
context clauses ("with"), and perhaps generics, none of which are
specifically related to I/O, and all of which you need to know anyway,
in order to be productive in Ada.
> I don't want to push your helpfulness to far, but I still don't
> know whether there is any means to determine the size of a file
> from within Ada other than using a C subroutine calling fstat.
Two ways:
- Ada.Directories.Size, given the file name.
- Ada.Direct_IO.Size, given an open (Direct_IO) file.
--
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
. @ .
^ permalink raw reply [relevance 7%]
* Re: xor
@ 2012-03-27 22:01 7% ` Georg Bauhaus
0 siblings, 0 replies; 170+ results
From: Georg Bauhaus @ 2012-03-27 22:01 UTC (permalink / raw)
On 27.03.12 23:44, Michael Moeller wrote:
> dealing with ciphers
> the size of file is well known in advance and must be verified in any event.
> In addition sometimes we'll only pick certain parts of a pretty huge file
> and we never hit EOF.
Just in case you'll have to read blocks, and while Ada.Streams
should be most efficient, another convenient and also venerable
method uses an instance Direct_IO, instantiated for blocks.
You can set the file position to the block you need.
with Ada.Direct_IO;
with Interfaces;
procedure Position is
-- Read "xyz.bin", second block, where
-- $ perl -e "print 'x' x 512, 'y' x 512, 'z' x 512" > xyz.bin
subtype Byte is Interfaces.Unsigned_8;
type Block_Index is range 0 .. 511;
type Block is array (Block_Index) of Byte;
package Block_IO is new Ada.Direct_IO (Block);
-- second block should be all 'y's; in terms of Byte:
Y : constant Byte := Byte'Val (Character'Pos ('y'));
-- a virtual character not occuring in input:
Rubbish: constant Byte := Byte'Val (Character'Pos ('*'));
Input : Block_IO.File_Type;
Data : Block := Block'(Block_Index => Rubbish);
use Block_IO;
begin
Open (Input, Name => "xyz.bin", Mode => In_File);
Set_Index (Input, To => 2);
Read (Input, Item => Data);
Close (Input);
if Data /= Block'(Block_Index => Y) then
raise Program_Error;
end if;
end Position;
^ permalink raw reply [relevance 7%]
* Re: xor
2012-03-25 19:26 4% ` xor Niklas Holsti
@ 2012-03-27 20:09 0% ` Michael Moeller
0 siblings, 2 replies; 170+ results
From: Michael Moeller @ 2012-03-27 20:09 UTC (permalink / raw)
On Sun, 25 Mar 2012, Niklas Holsti wrote:
> On 12-03-25 18:16 , Michael Moeller wrote:
>> Thank you for your quick answer.
>>
>> Can I use Unsigned_Byte_T to read in a byte from a file
>> as in C? I haven't looked into this yet.
>
> C has several ways to "read in a byte from a file", depending on the type of
> the file and how you specify which byte you want to read. Can you be more
> specific?
I have to read in what in C is called an unsigned byte, which in fact is
a stream of bytes without any interpretation as a symbol. Just a number
from 0 to 255.
In addition it would be nice to call something like 'fstat' to get the
size of file in advance instead of checking every byte for EOF.
>
> If you mean reading an 8-bit octet from a "binary file" -- that is, not a
> text file -- you can use the Ada library packages Ada.Sequential_IO or
> Ada.Direct_IO, depending on your needs. These are generic packages, so you
> must instantiate them for the type of data, for example Unsigned_Byte_T.
>
> If the file contains a mixture of different kinds of "binary" data, for
> example both 8-bit data and 16-bit data, or more complex structures, you
> should use the Ada "stream" facility from Ada.Streams.Stream_IO. The stream
> facility helps you handle things like different endianness, padding, packing,
> unusual encodings, and so on.
>
> The stream facility does not use generics; instead, it uses a combination of
> tagged types and the special "stream attribute" operations T'Read, T'Write,
> et cetera, which you can define differently for each type, T, that is present
> in your file. For example, your 'Read operation for a 16-bit integer will
> specify whether the integer is stored in little-endian or big-endian order in
> the file (by reading two 8-bit integers, using 'Read for the 8-bit type, in
> the corresponding order).
>
> The stream technique takes a bit of study to understand, but it works very
> well, especially if the file has a mixture of different complex structures of
> data, or if the file is created by a different language or computer and is
> not in the "native" form for your Ada compiler.
>
> --
> Niklas Holsti
> Tidorum Ltd
> niklas holsti tidorum fi
> . @ .
>
Perhaps it will be more save to leave the C-procedures alone and to
call them from within Ada instead. I don't know whether this will be
easier. However, I'll give Sequential_IO and Direct_IO a try.
Regards,
Michael
^ permalink raw reply [relevance 0%]
* Re: xor
@ 2012-03-25 19:26 4% ` Niklas Holsti
2012-03-27 20:09 0% ` xor Michael Moeller
0 siblings, 1 reply; 170+ results
From: Niklas Holsti @ 2012-03-25 19:26 UTC (permalink / raw)
On 12-03-25 18:16 , Michael Moeller wrote:
> Thank you for your quick answer.
>
> Can I use Unsigned_Byte_T to read in a byte from a file
> as in C? I haven't looked into this yet.
C has several ways to "read in a byte from a file", depending on the
type of the file and how you specify which byte you want to read. Can
you be more specific?
If you mean reading an 8-bit octet from a "binary file" -- that is, not
a text file -- you can use the Ada library packages Ada.Sequential_IO or
Ada.Direct_IO, depending on your needs. These are generic packages, so
you must instantiate them for the type of data, for example Unsigned_Byte_T.
If the file contains a mixture of different kinds of "binary" data, for
example both 8-bit data and 16-bit data, or more complex structures, you
should use the Ada "stream" facility from Ada.Streams.Stream_IO. The
stream facility helps you handle things like different endianness,
padding, packing, unusual encodings, and so on.
The stream facility does not use generics; instead, it uses a
combination of tagged types and the special "stream attribute"
operations T'Read, T'Write, et cetera, which you can define differently
for each type, T, that is present in your file. For example, your 'Read
operation for a 16-bit integer will specify whether the integer is
stored in little-endian or big-endian order in the file (by reading two
8-bit integers, using 'Read for the 8-bit type, in the corresponding order).
The stream technique takes a bit of study to understand, but it works
very well, especially if the file has a mixture of different complex
structures of data, or if the file is created by a different language or
computer and is not in the "native" form for your Ada compiler.
--
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
. @ .
^ permalink raw reply [relevance 4%]
* Re: Encapsulating Ada.Direct_IO
2010-11-17 5:20 5% ` Adam Beneschan
@ 2010-11-26 15:31 6% ` Bryan
0 siblings, 0 replies; 170+ results
From: Bryan @ 2010-11-26 15:31 UTC (permalink / raw)
Wow, this topic sparked a lot of interesting conversation! I thought
I would report that I do have the code working now thanks to the
advice in this thread.
Adam,
Thank you for catching that my mistake, the casting did the trick.
Peter,
Thanks for the tips. I will look into Sequential_IO, I somehow missed
it and thought that is what Direct_IO was for. I need to go back and
review the different Ada file processing packges.
^ permalink raw reply [relevance 6%]
* Re: Encapsulating Ada.Direct_IO
2010-11-18 1:16 7% ` Randy Brukardt
` (3 preceding siblings ...)
2010-11-18 16:31 3% ` Adam Beneschan
@ 2010-11-24 21:31 7% ` Warren
4 siblings, 0 replies; 170+ results
From: Warren @ 2010-11-24 21:31 UTC (permalink / raw)
Randy Brukardt expounded in news:ic1uop$nhs$1@munin.nbi.dk:
> "Peter C. Chapin" <pcc482719@gmail.com> wrote in message
> news:tM6dnaTzn6shVH7RRVn_vwA@giganews.com...
> ...
>> Something I wonder about (I don't have the answer) is if
>> it necessary to use a representation clause to force the
>> size of the objects being read to be 8 bits. I'm a little
>> unclear if the standard requires Character to be stored in
>> a file in 8 bit units. That is, the language might treat
>> the type Character rather more abstractly than you want.
>> Again I'm not sure of this and I'd love to get some
>> insights from others myself.
>
> Surely not. Not all machines have 8-bits as any sort of
> native type. For instance, the Unisys U2200 (a 36-bit
> machine, with 9-bit bytes) used Character'Size = 9. (It was
> great fun for the cross-compiler.)
>
> Randy.
Heh heh, the Honeywell Level 66 and DPS-8 machines were like
that too. That extra bit in a byte sometimes came in handy.
But that made porting to "normal platforms" tricky.
Warren
^ permalink raw reply [relevance 7%]
* Re: Encapsulating Ada.Direct_IO
2010-11-19 8:24 7% ` Dmitry A. Kazakov
@ 2010-11-19 16:19 6% ` Adam Beneschan
0 siblings, 0 replies; 170+ results
From: Adam Beneschan @ 2010-11-19 16:19 UTC (permalink / raw)
On Nov 19, 12:24 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> On Thu, 18 Nov 2010 21:57:10 -0800, Dennis Lee Bieber wrote:
> > On Thu, 18 Nov 2010 18:05:49 +0100, "Dmitry A. Kazakov"
> > <mail...@dmitry-kazakov.de> declaimed the following in comp.lang.ada:
>
> >> On Thu, 18 Nov 2010 08:31:20 -0800 (PST), Adam Beneschan wrote:
>
> >>> Then there was a
> >>> DEC machine that used 36-bit words and represented strings by sticking
> >>> five 7-bit ASCII characters in each word, but I don't remember much
> >>> else.
>
> >> RADIX-50?
>
> >>http://en.wikipedia.org/wiki/DEC_Radix-50
>
> > Why bother... 5 * 7bit => 35bits, easily fits into a 36bit word with
> > one left over!
>
> Because 3*7 = 21 >> 16. Under RSX-11, RT-11 they packed 3 file name
> characters into one 16-bit word. With 64K address space that was important.
Yeah, I remember the -11. Cute little machines. The 36-bit one I was
referring to was, I think, DEC-10; my recollection is that the
instruction set contained instructions that would let you stuff
characters of any size (including 7 bits) into words until it couldn't
fit any more and then go to the next word.
-- Adam
^ permalink raw reply [relevance 6%]
* Re: Encapsulating Ada.Direct_IO
[not found] ` <ENidndoH8qoqjHvRnZ2dnUVZ_j-dnZ2d@earthlink.com>
@ 2010-11-19 8:24 7% ` Dmitry A. Kazakov
2010-11-19 16:19 6% ` Adam Beneschan
0 siblings, 1 reply; 170+ results
From: Dmitry A. Kazakov @ 2010-11-19 8:24 UTC (permalink / raw)
On Thu, 18 Nov 2010 21:57:10 -0800, Dennis Lee Bieber wrote:
> On Thu, 18 Nov 2010 18:05:49 +0100, "Dmitry A. Kazakov"
> <mailbox@dmitry-kazakov.de> declaimed the following in comp.lang.ada:
>
>> On Thu, 18 Nov 2010 08:31:20 -0800 (PST), Adam Beneschan wrote:
>>
>>> Then there was a
>>> DEC machine that used 36-bit words and represented strings by sticking
>>> five 7-bit ASCII characters in each word, but I don't remember much
>>> else.
>>
>> RADIX-50?
>>
>> http://en.wikipedia.org/wiki/DEC_Radix-50
>>
> Why bother... 5 * 7bit => 35bits, easily fits into a 36bit word with
> one left over!
Because 3*7 = 21 >> 16. Under RSX-11, RT-11 they packed 3 file name
characters into one 16-bit word. With 64K address space that was important.
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
^ permalink raw reply [relevance 7%]
* Re: Encapsulating Ada.Direct_IO
2010-11-18 19:48 7% ` Adam Beneschan
@ 2010-11-18 20:15 6% ` Dmitry A. Kazakov
0 siblings, 0 replies; 170+ results
From: Dmitry A. Kazakov @ 2010-11-18 20:15 UTC (permalink / raw)
On Thu, 18 Nov 2010 11:48:49 -0800 (PST), Adam Beneschan wrote:
> On Nov 18, 10:21�am, "Peter C. Chapin" <pcc482...@gmail.com> wrote:
>
>> I'm thinking about the very common case when one is trying to read a
>> file that has a format defined by some third party. For example the
>> specification of the format might say, "The first octet of the header
>> defines the message type and can be one of the following values... The
>> type field is followed by a 24 bit length field in big endian form. The
>> body of the message follows the length field, and finally a 32 bit CRC
>> follows the message body."
>
> The problem is that this *definition* is not sufficient to tell you
> what an OS will stick in your memory buffer if you ask to read from
> such a file.
I don't think so. I presume that the context of the definition above is the
OS. It is a reasonable presumption because files from another OS (file
system) cannot be read at all unless they are converted into the format
supported by the OS's file system. Another presumption is that the
definition describes memory layout, rather than the media layout. The
latter is inaccessible anyway. So a stream of octets is what a file reading
OS service delivers, when Ada would call it. There of course is no guaranty
that Direct_IO would use this service and not some other service.
> You need additional OS-dependent information.
The Ada compiler vendor will likely document the services used for
Direct_IO, but there is no way to verify that using the representation
clauses and/or assertions.
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
^ permalink raw reply [relevance 6%]
* Re: Encapsulating Ada.Direct_IO
2010-11-18 18:21 5% ` Peter C. Chapin
2010-11-18 18:36 5% ` Randy Brukardt
@ 2010-11-18 19:48 7% ` Adam Beneschan
2010-11-18 20:15 6% ` Dmitry A. Kazakov
1 sibling, 1 reply; 170+ results
From: Adam Beneschan @ 2010-11-18 19:48 UTC (permalink / raw)
On Nov 18, 10:21 am, "Peter C. Chapin" <pcc482...@gmail.com> wrote:
> I'm thinking about the very common case when one is trying to read a
> file that has a format defined by some third party. For example the
> specification of the format might say, "The first octet of the header
> defines the message type and can be one of the following values... The
> type field is followed by a 24 bit length field in big endian form. The
> body of the message follows the length field, and finally a 32 bit CRC
> follows the message body."
The problem is that this *definition* is not sufficient to tell you
what an OS will stick in your memory buffer if you ask to read from
such a file. You need additional OS-dependent information.
-- Adam
^ permalink raw reply [relevance 7%]
* Re: Encapsulating Ada.Direct_IO
2010-11-18 16:31 3% ` Adam Beneschan
2010-11-18 17:05 7% ` Dmitry A. Kazakov
@ 2010-11-18 18:45 4% ` Randy Brukardt
1 sibling, 0 replies; 170+ results
From: Randy Brukardt @ 2010-11-18 18:45 UTC (permalink / raw)
"Adam Beneschan" <adam@irvine.com> wrote in message
news:8bb3a7c0-c473-4c35-bc6e-3920ce80e6a8@q36g2000vbi.googlegroups.com...
...
>I did notice, though, that Peter was talking about how data was stored
>in a *file*. In the Unisys U2200 system, how were files kept,
>conceptually? Were they streams of 8-bit bytes, or were they stored
>as 36-bit words or 9-bit bytes or what? I'd assume that for a text
>file, when you read it in, four bytes would be stored in each word and
>the high bit of each 9-bit byte would be zeroed---whether that zero
>bit was actually stored on disk or not should be the OS's concern, not
>the program's, and I'd presume that the OS would also have to handle
>things correctly when text files are transferred from a different
>machine.
It stored text as streams of 9-bit characters. We were running on a Unix
emulator, and there were a bunch of conversions when you communicated to the
"normal" 8-bit world. When you think of it, it is amazing that they could
get Unix code to run in such an environment. Just imagine all of the things
C could do that would assume 8-bits. Us Ada people had it easy: the language
was designed to allow use on such machines (although I think there were only
a few such compilers built). We only ran into one language bug (for modular
types) having to do with 1's complement math.
Perhaps this is all OBE these days, and Ada could be simplified and assume
8-bit only. But I doubt it would make that much difference, so it probably
wouldn't be worth the effort.
Randy.
What I'm leading up to, though, is that I think Peter's question is
too simple. We're all spoiled in having to deal exclusively, or
almost exclusively, with machines with 8-bit byte addressability and
files that are unstructured sequences of 8-bit bytes. But there are
other systems out there. There are machines in use that are not byte-
addressable---Analog Devices 21060 series comes to mind, which uses 32-
bit words whose bytes are not individually addressable. When reading
from a file on that system, do you want each word to hold one byte, or
four? Even in VAX/VMS, which does run on a machine with 8-bit byte
addressibility, the OS is able to create files that have more
structure than just being sequences of bytes. What would it mean to
instantiate Direct_IO(Character) on a file like that? I don't think
the answer is trivial. How did the Pick operating system treat files
conceptually? How would Direct_IO work on one of that system's files?
Ada's designers have tried to design a language that could work on any
of those systems, and therefore I think the standard does not and
cannot answer Peter's question. In fact, I'm not entirely sure that
his question is meaningful on platforms that don't use 8-bit bytes and/
or use files with some structure. (It might have to be rephrased.)
In any event, I think that details like this are left up to the
implementation. And if you were trying to do something like this on a
U2200, there is no Ada answer to the question, because you would have
to know more about the particular OS's file system and how the Ada
implementation interacts with it.
-- Adam
^ permalink raw reply [relevance 4%]
* Re: Encapsulating Ada.Direct_IO
2010-11-18 7:39 7% ` AdaMagica
@ 2010-11-18 18:38 6% ` Randy Brukardt
0 siblings, 0 replies; 170+ results
From: Randy Brukardt @ 2010-11-18 18:38 UTC (permalink / raw)
"AdaMagica" <christoph.grein@eurocopter.com> wrote in message
news:946c87a9-208a-4206-b925-1c48ac621acd@a37g2000yqi.googlegroups.com...
>On 18 Nov., 02:16, "Randy Brukardt" <ra...@rrsoftware.com> wrote:
>> ... For
>> instance, the Unisys U2200 (a 36-bit machine, with 9-bit bytes) used
>> Character'Size = 9. (It was great fun for the cross-compiler.)
>
>Huh. How then is Character defined there? Accoriding to RM A.1(35),
>Character has 256 positions, so Character'Size should be still 8.
>Of course stand-alone objects would have X'Size = 9.
>
>Note that Natural'Size = Integer'Size - 1.
I suppose you are right, but Ada 95 Type'Size has no important meaning.
(It's a terrible definition, IMHO.) What matters is what AdaCore calls
Type'Object_Size, and that is what I was referring to. (Typically,
specifying Type'Size will have some effect on Type'Object_Size, but exactly
what that is will vary depending on the target.)
You could, I suppose, have packed characters into 8-bits in an array, but
the code to access them would have been unspeakably bad. And there would
have been no reason to do so anyway, since files and streams are
automatically converted when crossing into that machine's domain.
Randy.
^ permalink raw reply [relevance 6%]
* Re: Encapsulating Ada.Direct_IO
2010-11-18 18:21 5% ` Peter C. Chapin
@ 2010-11-18 18:36 5% ` Randy Brukardt
2010-11-18 19:48 7% ` Adam Beneschan
1 sibling, 0 replies; 170+ results
From: Randy Brukardt @ 2010-11-18 18:36 UTC (permalink / raw)
"Peter C. Chapin" <pcc482719@gmail.com> wrote in message
news:w6udneqaMqdi83jRRVn_vwA@giganews.com...
> On 2010-11-18 11:36, Adam Beneschan wrote:
>
>> I have a longish rant that touches on this, but the short answer is
>> that I don't think there's an Ada answer to your question. If you had
>> a file defined as using 8-bit units, and that file got put onto a
>> system that uses 36-bit words, you'd need to know just what the OS is
>> going to do with it, and how the particular Ada implementation will
>> deal with files on that OS. It may be that the native "read from
>> file" service on that OS will put each byte into a 9-bit byte and zero
>> the high bit. I don't see how to avoid implementation-dependent code
>> in a case like this.
>
> I understand what you are saying but it is less than satisfying. :)
>
> I'm thinking about the very common case when one is trying to read a
> file that has a format defined by some third party. For example the
> specification of the format might say, "The first octet of the header
> defines the message type and can be one of the following values... The
> type field is followed by a 24 bit length field in big endian form. The
> body of the message follows the length field, and finally a 32 bit CRC
> follows the message body."
>
> I want to write an Ada program that can read in a file like this and
> process it. Are you saying that it's impossible to write such a program
> in a portable manner?
>
> What I've been doing is as I showed earlier... define my own "Byte" type
> with Byte'Size set to 8 and the instantiate Sequential_IO. My program
> then interprets the individual bytes as necessary. It seems to work with
> GNAT.
>
> I suppose that C has the same issue, really. The C standard does not
> promise that char is exactly 8 bits. If it isn't I'm not sure what
> happens when you do
>
> int Ch;
>
> while ((Ch = fgetc(infile)) != EOF ) { ... }
>
> I guess that's the same point you are making. Maybe the C standard talks
> about this issue. Checking...
>
> I just took a quick look at C99's description of fgetc and it says, "the
> fgetc function returns the next character from the input stream." That
> seems to beg the question, doesn't it?
Adam is right. What we did is the same thing as the C compiler.
When you imported files from the "real world" into that system, it added a
zero bit to every byte. So there normally would not be any such thing as a
file with 8-bit characters.The same thing happened to sockets.
The real trouble came when you did the reverse, as it then *dropped* the
high bit if it thought that the files were text files. That would be bad
news for truly binary files.
Ada can only define things portably that it has control over. If you read
and write files on the same machine, then the results should be portable.
Once you start communicating to other machines, there can be translation
layers that mess things up.
The good new is that it is pretty rare that you will have to deal with any
machines that have other than 8-bit bytes these days. So I wouldn't worry
about those issues unless you happen to be working with Unisys. ;-)
Randy.
^ permalink raw reply [relevance 5%]
* Re: Encapsulating Ada.Direct_IO
2010-11-18 16:36 6% ` Adam Beneschan
@ 2010-11-18 18:21 5% ` Peter C. Chapin
2010-11-18 18:36 5% ` Randy Brukardt
2010-11-18 19:48 7% ` Adam Beneschan
0 siblings, 2 replies; 170+ results
From: Peter C. Chapin @ 2010-11-18 18:21 UTC (permalink / raw)
On 2010-11-18 11:36, Adam Beneschan wrote:
> I have a longish rant that touches on this, but the short answer is
> that I don't think there's an Ada answer to your question. If you had
> a file defined as using 8-bit units, and that file got put onto a
> system that uses 36-bit words, you'd need to know just what the OS is
> going to do with it, and how the particular Ada implementation will
> deal with files on that OS. It may be that the native "read from
> file" service on that OS will put each byte into a 9-bit byte and zero
> the high bit. I don't see how to avoid implementation-dependent code
> in a case like this.
I understand what you are saying but it is less than satisfying. :)
I'm thinking about the very common case when one is trying to read a
file that has a format defined by some third party. For example the
specification of the format might say, "The first octet of the header
defines the message type and can be one of the following values... The
type field is followed by a 24 bit length field in big endian form. The
body of the message follows the length field, and finally a 32 bit CRC
follows the message body."
I want to write an Ada program that can read in a file like this and
process it. Are you saying that it's impossible to write such a program
in a portable manner?
What I've been doing is as I showed earlier... define my own "Byte" type
with Byte'Size set to 8 and the instantiate Sequential_IO. My program
then interprets the individual bytes as necessary. It seems to work with
GNAT.
I suppose that C has the same issue, really. The C standard does not
promise that char is exactly 8 bits. If it isn't I'm not sure what
happens when you do
int Ch;
while ((Ch = fgetc(infile)) != EOF ) { ... }
I guess that's the same point you are making. Maybe the C standard talks
about this issue. Checking...
I just took a quick look at C99's description of fgetc and it says, "the
fgetc function returns the next character from the input stream." That
seems to beg the question, doesn't it?
Peter
^ permalink raw reply [relevance 5%]
* Re: Encapsulating Ada.Direct_IO
2010-11-18 16:31 3% ` Adam Beneschan
@ 2010-11-18 17:05 7% ` Dmitry A. Kazakov
[not found] ` <ENidndoH8qoqjHvRnZ2dnUVZ_j-dnZ2d@earthlink.com>
2010-11-18 18:45 4% ` Randy Brukardt
1 sibling, 1 reply; 170+ results
From: Dmitry A. Kazakov @ 2010-11-18 17:05 UTC (permalink / raw)
On Thu, 18 Nov 2010 08:31:20 -0800 (PST), Adam Beneschan wrote:
> Then there was a
> DEC machine that used 36-bit words and represented strings by sticking
> five 7-bit ASCII characters in each word, but I don't remember much
> else.
RADIX-50?
http://en.wikipedia.org/wiki/DEC_Radix-50
It was also used on 8-bit machines to encode file names in the FILES-11
file system.
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
^ permalink raw reply [relevance 7%]
* Re: Encapsulating Ada.Direct_IO
2010-11-18 2:21 6% ` Peter C. Chapin
@ 2010-11-18 16:36 6% ` Adam Beneschan
2010-11-18 18:21 5% ` Peter C. Chapin
0 siblings, 1 reply; 170+ results
From: Adam Beneschan @ 2010-11-18 16:36 UTC (permalink / raw)
On Nov 17, 6:21 pm, "Peter C. Chapin" <pcc482...@gmail.com> wrote:
> On 2010-11-17 20:16, Randy Brukardt wrote:
>
> > Surely not. Not all machines have 8-bits as any sort of native type. For
> > instance, the Unisys U2200 (a 36-bit machine, with 9-bit bytes) used
> > Character'Size = 9. (It was great fun for the cross-compiler.)
>
> So in that case if you absolutely wanted to read 8 bit units from a file
> (because the file is in some externally defined binary format that uses
> 8 bit units) it would be necessary to do something like:
>
> type My_Byte is mod 2**8;
> for My_Byte'Size use 8; -- This is important.
>
> package My_Byte_IO is new Ada.Sequential_IO(My_Byte);
>
> ... and then convert from My_Byte to Character only as appropriate
> during the file decoding process.
>
> True?
I have a longish rant that touches on this, but the short answer is
that I don't think there's an Ada answer to your question. If you had
a file defined as using 8-bit units, and that file got put onto a
system that uses 36-bit words, you'd need to know just what the OS is
going to do with it, and how the particular Ada implementation will
deal with files on that OS. It may be that the native "read from
file" service on that OS will put each byte into a 9-bit byte and zero
the high bit. I don't see how to avoid implementation-dependent code
in a case like this.
-- Adam
^ permalink raw reply [relevance 6%]
* Re: Encapsulating Ada.Direct_IO
2010-11-18 1:16 7% ` Randy Brukardt
` (2 preceding siblings ...)
2010-11-18 9:46 6% ` Maciej Sobczak
@ 2010-11-18 16:31 3% ` Adam Beneschan
2010-11-18 17:05 7% ` Dmitry A. Kazakov
2010-11-18 18:45 4% ` Randy Brukardt
2010-11-24 21:31 7% ` Warren
4 siblings, 2 replies; 170+ results
From: Adam Beneschan @ 2010-11-18 16:31 UTC (permalink / raw)
On Nov 17, 5:16 pm, "Randy Brukardt" <ra...@rrsoftware.com> wrote:
> "Peter C. Chapin" <pcc482...@gmail.com> wrote in messagenews:tM6dnaTzn6shVH7RRVn_vwA@giganews.com...
> ...
>
> > Something I wonder about (I don't have the answer) is if it necessary to
> > use a representation clause to force the size of the objects being read
> > to be 8 bits. I'm a little unclear if the standard requires Character to
> > be stored in a file in 8 bit units. That is, the language might treat
> > the type Character rather more abstractly than you want. Again I'm not
> > sure of this and I'd love to get some insights from others myself.
>
> Surely not. Not all machines have 8-bits as any sort of native type. For
> instance, the Unisys U2200 (a 36-bit machine, with 9-bit bytes) used
> Character'Size = 9. (It was great fun for the cross-compiler.)
Yeah, I was going to say something about Honeywell 600 series, which
was also a 36-bit machine and used 9-bit bytes. My dad worked for
Honeywell so I have some more useless knowledge about some of their
machine than others would. Unlike the Unisys U2200, all the Honeywell
machines were dead by the time Ada was developed, so I don't think
anyone ever tried to write an Ada compiler for it. Then there was a
DEC machine that used 36-bit words and represented strings by sticking
five 7-bit ASCII characters in each word, but I don't remember much
else. But now I'm drifting...
I did notice, though, that Peter was talking about how data was stored
in a *file*. In the Unisys U2200 system, how were files kept,
conceptually? Were they streams of 8-bit bytes, or were they stored
as 36-bit words or 9-bit bytes or what? I'd assume that for a text
file, when you read it in, four bytes would be stored in each word and
the high bit of each 9-bit byte would be zeroed---whether that zero
bit was actually stored on disk or not should be the OS's concern, not
the program's, and I'd presume that the OS would also have to handle
things correctly when text files are transferred from a different
machine.
What I'm leading up to, though, is that I think Peter's question is
too simple. We're all spoiled in having to deal exclusively, or
almost exclusively, with machines with 8-bit byte addressability and
files that are unstructured sequences of 8-bit bytes. But there are
other systems out there. There are machines in use that are not byte-
addressable---Analog Devices 21060 series comes to mind, which uses 32-
bit words whose bytes are not individually addressable. When reading
from a file on that system, do you want each word to hold one byte, or
four? Even in VAX/VMS, which does run on a machine with 8-bit byte
addressibility, the OS is able to create files that have more
structure than just being sequences of bytes. What would it mean to
instantiate Direct_IO(Character) on a file like that? I don't think
the answer is trivial. How did the Pick operating system treat files
conceptually? How would Direct_IO work on one of that system's files?
Ada's designers have tried to design a language that could work on any
of those systems, and therefore I think the standard does not and
cannot answer Peter's question. In fact, I'm not entirely sure that
his question is meaningful on platforms that don't use 8-bit bytes and/
or use files with some structure. (It might have to be rephrased.)
In any event, I think that details like this are left up to the
implementation. And if you were trying to do something like this on a
U2200, there is no Ada answer to the question, because you would have
to know more about the particular OS's file system and how the Ada
implementation interacts with it.
-- Adam
^ permalink raw reply [relevance 3%]
* Re: Encapsulating Ada.Direct_IO
2010-11-18 1:16 7% ` Randy Brukardt
2010-11-18 2:21 6% ` Peter C. Chapin
2010-11-18 7:39 7% ` AdaMagica
@ 2010-11-18 9:46 6% ` Maciej Sobczak
2010-11-18 16:31 3% ` Adam Beneschan
2010-11-24 21:31 7% ` Warren
4 siblings, 0 replies; 170+ results
From: Maciej Sobczak @ 2010-11-18 9:46 UTC (permalink / raw)
On 18 Lis, 02:16, "Randy Brukardt" <ra...@rrsoftware.com> wrote:
> Surely not. Not all machines have 8-bits as any sort of native type. For
> instance, the Unisys U2200 (a 36-bit machine, with 9-bit bytes) used
> Character'Size = 9.
You have used present for "not all machines have" and past for "Unisys
used". :-)
Now let's synchronize these statements - what is the actual *current*
status of this niche? Is it still relevant enough in the industry to
justify standardization effort at the level of programming languages
and development effort at the level of user programs?
What would happen if we just assumed 8 as a common denominator for the
granularity of storage for any type (in particular Character'Size = 8)
and just moved on?
--
Maciej Sobczak * http://www.inspirel.com
^ permalink raw reply [relevance 6%]
* Re: Encapsulating Ada.Direct_IO
2010-11-18 1:16 7% ` Randy Brukardt
2010-11-18 2:21 6% ` Peter C. Chapin
@ 2010-11-18 7:39 7% ` AdaMagica
2010-11-18 18:38 6% ` Randy Brukardt
2010-11-18 9:46 6% ` Maciej Sobczak
` (2 subsequent siblings)
4 siblings, 1 reply; 170+ results
From: AdaMagica @ 2010-11-18 7:39 UTC (permalink / raw)
Cc: randy
On 18 Nov., 02:16, "Randy Brukardt" <ra...@rrsoftware.com> wrote:
> ... For
> instance, the Unisys U2200 (a 36-bit machine, with 9-bit bytes) used
> Character'Size = 9. (It was great fun for the cross-compiler.)
>
> Randy.
Huh. How then is Character defined there? Accoriding to RM A.1(35),
Character has 256 positions, so Character'Size should be still 8.
Of course stand-alone objects would have X'Size = 9.
Note that Natural'Size = Integer'Size - 1.
^ permalink raw reply [relevance 7%]
* Re: Encapsulating Ada.Direct_IO
2010-11-18 1:16 7% ` Randy Brukardt
@ 2010-11-18 2:21 6% ` Peter C. Chapin
2010-11-18 16:36 6% ` Adam Beneschan
2010-11-18 7:39 7% ` AdaMagica
` (3 subsequent siblings)
4 siblings, 1 reply; 170+ results
From: Peter C. Chapin @ 2010-11-18 2:21 UTC (permalink / raw)
On 2010-11-17 20:16, Randy Brukardt wrote:
> Surely not. Not all machines have 8-bits as any sort of native type. For
> instance, the Unisys U2200 (a 36-bit machine, with 9-bit bytes) used
> Character'Size = 9. (It was great fun for the cross-compiler.)
So in that case if you absolutely wanted to read 8 bit units from a file
(because the file is in some externally defined binary format that uses
8 bit units) it would be necessary to do something like:
type My_Byte is mod 2**8;
for My_Byte'Size use 8; -- This is important.
package My_Byte_IO is new Ada.Sequential_IO(My_Byte);
... and then convert from My_Byte to Character only as appropriate
during the file decoding process.
True?
Peter
^ permalink raw reply [relevance 6%]
* Re: Encapsulating Ada.Direct_IO
2010-11-17 12:25 12% ` Peter C. Chapin
@ 2010-11-18 1:16 7% ` Randy Brukardt
2010-11-18 2:21 6% ` Peter C. Chapin
` (4 more replies)
0 siblings, 5 replies; 170+ results
From: Randy Brukardt @ 2010-11-18 1:16 UTC (permalink / raw)
"Peter C. Chapin" <pcc482719@gmail.com> wrote in message
news:tM6dnaTzn6shVH7RRVn_vwA@giganews.com...
...
> Something I wonder about (I don't have the answer) is if it necessary to
> use a representation clause to force the size of the objects being read
> to be 8 bits. I'm a little unclear if the standard requires Character to
> be stored in a file in 8 bit units. That is, the language might treat
> the type Character rather more abstractly than you want. Again I'm not
> sure of this and I'd love to get some insights from others myself.
Surely not. Not all machines have 8-bits as any sort of native type. For
instance, the Unisys U2200 (a 36-bit machine, with 9-bit bytes) used
Character'Size = 9. (It was great fun for the cross-compiler.)
Randy.
^ permalink raw reply [relevance 7%]
* Re: Encapsulating Ada.Direct_IO
2010-11-17 23:03 7% ` Adam Beneschan
@ 2010-11-17 23:11 7% ` Yannick Duchêne (Hibou57)
0 siblings, 0 replies; 170+ results
From: Yannick Duchêne (Hibou57) @ 2010-11-17 23:11 UTC (permalink / raw)
Le Thu, 18 Nov 2010 00:03:06 +0100, Adam Beneschan <adam@irvine.com> a
écrit:
> File_Type was declared as a private type. You cannot complete a
> private type with a subtype.
Oops, I had a bug, sorry.
--
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour
les chiens.
“I am fluent in ASCII” [Warren 2010]
^ permalink raw reply [relevance 7%]
* Re: Encapsulating Ada.Direct_IO
2010-11-17 22:32 6% ` Yannick Duchêne (Hibou57)
@ 2010-11-17 23:03 7% ` Adam Beneschan
2010-11-17 23:11 7% ` Yannick Duchêne (Hibou57)
0 siblings, 1 reply; 170+ results
From: Adam Beneschan @ 2010-11-17 23:03 UTC (permalink / raw)
On Nov 17, 2:32 pm, Yannick Duchêne (Hibou57)
<yannick_duch...@yahoo.fr> wrote:
> Le Wed, 17 Nov 2010 05:44:49 +0100, Bryan <brobinson....@gmail.com> a
> écrit:> Spec file:
> > ...
> > private
> > package Byte_IO is new Ada.Direct_IO(Character);
> > type File_Type is new Byte_IO.File_Type;
> > end Big5_Text_IO;
> > ======================
>
> Why did you used a “type new” ? Unless you give some reason, subtype is
> better better here
File_Type was declared as a private type. You cannot complete a
private type with a subtype.
-- Adam
^ permalink raw reply [relevance 7%]
* Re: Encapsulating Ada.Direct_IO
2010-11-17 4:44 13% Encapsulating Ada.Direct_IO Bryan
2010-11-17 5:20 5% ` Adam Beneschan
2010-11-17 12:25 12% ` Peter C. Chapin
@ 2010-11-17 22:32 6% ` Yannick Duchêne (Hibou57)
2010-11-17 23:03 7% ` Adam Beneschan
2 siblings, 1 reply; 170+ results
From: Yannick Duchêne (Hibou57) @ 2010-11-17 22:32 UTC (permalink / raw)
Le Wed, 17 Nov 2010 05:44:49 +0100, Bryan <brobinson.eng@gmail.com> a
écrit:
> Spec file:
> ...
> private
> package Byte_IO is new Ada.Direct_IO(Character);
> type File_Type is new Byte_IO.File_Type;
> end Big5_Text_IO;
> ======================
Why did you used a “type new” ? Unless you give some reason, subtype is
better better here, as this avoid un-meaningful conversions every where.
If the type was defined in the public part, the type-new would have make
sense, but here it is defined in the private part, so no need to use
type-new, unless you want to attach it some special invariants which are
not part of the invariants of your Byte_IO.File_Type.
When you begin with Ada, you oftenly forget to make a good choice between
type-new and subtype (probably because there is no such things with any
other language). Always balance type-new and subtype and don't
systematically use type-new all the way. Make choices with reasons.
--
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour
les chiens.
“I am fluent in ASCII” [Warren 2010]
^ permalink raw reply [relevance 6%]
* Re: Encapsulating Ada.Direct_IO
2010-11-17 4:44 13% Encapsulating Ada.Direct_IO Bryan
2010-11-17 5:20 5% ` Adam Beneschan
@ 2010-11-17 12:25 12% ` Peter C. Chapin
2010-11-18 1:16 7% ` Randy Brukardt
2010-11-17 22:32 6% ` Yannick Duchêne (Hibou57)
2 siblings, 1 reply; 170+ results
From: Peter C. Chapin @ 2010-11-17 12:25 UTC (permalink / raw)
On 2010-11-16 23:44, Bryan wrote:
> Spec file:
> ======================
> with Ada.Direct_IO;
> package Big5_Text_IO is
> type File_Type is limited private;
> procedure Close( File : in out File_Type );
> private
> package Byte_IO is new Ada.Direct_IO(Character);
> type File_Type is new Byte_IO.File_Type;
> end Big5_Text_IO;
> ======================
Direct_IO allows random access. There is nothing wrong with that, of
course, but if your intention is to read the file sequentially you might
prefer using Sequential_IO.
Something I wonder about (I don't have the answer) is if it necessary to
use a representation clause to force the size of the objects being read
to be 8 bits. I'm a little unclear if the standard requires Character to
be stored in a file in 8 bit units. That is, the language might treat
the type Character rather more abstractly than you want. Again I'm not
sure of this and I'd love to get some insights from others myself.
Thus you might want to do something like
package Big5_Text_IO is
...
type Byte is mod 2**8;
for Byte'Size use 8;
...
private
package Byte_IO is new Ada.Direct_IO(Byte);
...
end Big5_Text_IO;
This approach has the advantage of creating a separate type to represent
the raw data from the file. Thus
C : Character;
B : Big5_Text_IO.Byte;
C := B; -- Compile error. You haven't decoded B yet.
Peter
^ permalink raw reply [relevance 12%]
* Re: Encapsulating Ada.Direct_IO
2010-11-17 4:44 13% Encapsulating Ada.Direct_IO Bryan
@ 2010-11-17 5:20 5% ` Adam Beneschan
2010-11-26 15:31 6% ` Bryan
2010-11-17 12:25 12% ` Peter C. Chapin
2010-11-17 22:32 6% ` Yannick Duchêne (Hibou57)
2 siblings, 1 reply; 170+ results
From: Adam Beneschan @ 2010-11-17 5:20 UTC (permalink / raw)
On Nov 16, 8:44 pm, Bryan <brobinson....@gmail.com> wrote:
> I'm trying to port some code to Ada for dealing with Big5-encoded
> files. I realize that I might be able to use Ada.Wide_Text_IO, but I'm
> trying to learn Ada and understand the language better. I'm still
> working on wrapping my head around types and packages. My original
> code in C++ opens a file as binary and parses it byte by byte and
> breaking it into Big5 characters depending on the byte codes. I
> thought I'd try to do something similar by encapsulating Ada.Direct_IO
> into a package. I'm not having much luck, however.
>
> Spec file:
> ======================
> with Ada.Direct_IO;
> package Big5_Text_IO is
> type File_Type is limited private;
> procedure Close( File : in out File_Type );
> private
> package Byte_IO is new Ada.Direct_IO(Character);
> type File_Type is new Byte_IO.File_Type;
> end Big5_Text_IO;
> ======================
>
> Body file
> ======================
> package body Big5_Text_IO is
> procedure Close( File : in out File_Type ) is
> begin
> Byte_IO.Close(File);
> end Close;
> end Big5_Text_IO;
> ======================
>
> Test driver:
> ======================
> with Big5_Text_IO;
> with Ada.Text_IO;
> procedure Big5_Test is
> Input_File : Big5_Text_IO.File_Type;
> begin
> Ada.Text_IO.Put_Line("OK?");
> end Big5_Test;
> ======================
>
> If I leave out the Close method and remove the body file, I can build
> the test driver with no issues. Otherwise, I get the following from
> GNAT:
>
> ======================
> gcc -c big5_text_io.adb
> big5_text_io.adb:6:23: expected private type "Ada.Direct_Io.File_Type"
> from instance at big5_text_io.ads:11
> big5_text_io.adb:6:23: found private type "Big5_Text_IO.File_Type"
> defined at big5_text_io.ads:12
> gnatmake: "big5_text_io.adb" compilation error
> ======================
>
> I would *greatly* appreciate any tips in how I can better design my
> package so that it can encapsulate Ada.Direct_IO or some other method
> of binary I/O. I looked at the GNAT source and I'm hoping I won't
> have to emulate what they have done...its a bit over my head at this
> point.
You're close. Try changing
Byte_IO.Close (File);
to
Byte_IO.Close (Byte_IO.File_Type (File));
When you declare a derived type "type T2 is new T1", then T2 and T1
are not the same type, so you can't use an object of type T2 where
something of type T1 is expected. But you can use a type conversion.
Note: I'm at home so I can't try this easily. I seem to recall that
there were some issues using this paradigm with limited types
(including an incompatibility with earlier versions of the language),
but I don't recall the details and it's hard for me to look them up
right now. If it turns out the type conversion doesn't work, then you
might have to make File_Type a record in the private part:
type File_Type is record
F : Byte_IO.File_Type;
end record;
and then use File.F whenever you want to use a Byte_IO operation,
e.g.:
Byte_IO.Close (File.F);
Hope this helps,
-- Adam
^ permalink raw reply [relevance 5%]
* Encapsulating Ada.Direct_IO
@ 2010-11-17 4:44 13% Bryan
2010-11-17 5:20 5% ` Adam Beneschan
` (2 more replies)
0 siblings, 3 replies; 170+ results
From: Bryan @ 2010-11-17 4:44 UTC (permalink / raw)
I'm trying to port some code to Ada for dealing with Big5-encoded
files. I realize that I might be able to use Ada.Wide_Text_IO, but I'm
trying to learn Ada and understand the language better. I'm still
working on wrapping my head around types and packages. My original
code in C++ opens a file as binary and parses it byte by byte and
breaking it into Big5 characters depending on the byte codes. I
thought I'd try to do something similar by encapsulating Ada.Direct_IO
into a package. I'm not having much luck, however.
Spec file:
======================
with Ada.Direct_IO;
package Big5_Text_IO is
type File_Type is limited private;
procedure Close( File : in out File_Type );
private
package Byte_IO is new Ada.Direct_IO(Character);
type File_Type is new Byte_IO.File_Type;
end Big5_Text_IO;
======================
Body file
======================
package body Big5_Text_IO is
procedure Close( File : in out File_Type ) is
begin
Byte_IO.Close(File);
end Close;
end Big5_Text_IO;
======================
Test driver:
======================
with Big5_Text_IO;
with Ada.Text_IO;
procedure Big5_Test is
Input_File : Big5_Text_IO.File_Type;
begin
Ada.Text_IO.Put_Line("OK?");
end Big5_Test;
======================
If I leave out the Close method and remove the body file, I can build
the test driver with no issues. Otherwise, I get the following from
GNAT:
======================
gcc -c big5_text_io.adb
big5_text_io.adb:6:23: expected private type "Ada.Direct_Io.File_Type"
from instance at big5_text_io.ads:11
big5_text_io.adb:6:23: found private type "Big5_Text_IO.File_Type"
defined at big5_text_io.ads:12
gnatmake: "big5_text_io.adb" compilation error
======================
I would *greatly* appreciate any tips in how I can better design my
package so that it can encapsulate Ada.Direct_IO or some other method
of binary I/O. I looked at the GNAT source and I'm hoping I won't
have to emulate what they have done...its a bit over my head at this
point.
^ permalink raw reply [relevance 13%]
* Re: Binary opperations under Ada?
@ 2010-08-21 0:17 5% ` Jeffrey Carter
0 siblings, 0 replies; 170+ results
From: Jeffrey Carter @ 2010-08-21 0:17 UTC (permalink / raw)
On 08/20/2010 04:23 PM, Trogdor wrote:
>
> -) I want to read in a raw binary file and perform bit manipulation
> on the data.
>
> -) I vaguely remember seeing a post about a module package for low
> level stuff, cut han no longer find it in the group.
For I/O, you may be thinking of seqeuntial or direct I/O, or streams. You can
find the packages Ada.Sequential_IO, Ada.Direct_IO, and Ada.Streams.Stream_IO in
the ARM, Annex A, which is quite readable:
http://www.adaic.org/standards/05rm/html/RM-TOC.html
For bit manipulation, you can use (packed) arrays of Boolean or modular types.
The former existed in Ada 83 and the latter were introduced in Ada 95; both
should be covered in any good text.
But it's better to talk about what you want to do than how you think you should
do it. Sometimes you might find a better way to do something.
"I would never want to belong to any club that
would have someone like me for a member."
Annie Hall
41
--- news://freenews.netfront.net/ - complaints: news@netfront.net ---
^ permalink raw reply [relevance 5%]
* Re: Preferred way to do binray I/O on standard input/output stream
@ 2009-10-24 22:57 5% ` Jeffrey R. Carter
0 siblings, 0 replies; 170+ results
From: Jeffrey R. Carter @ 2009-10-24 22:57 UTC (permalink / raw)
Hibou57 (Yannick Duch�ne) wrote:
>
> There is no kind of binary mode vs text mode flags with Ada stream/
> file IO, as it there are with C. And then, C files are not typed,
> while Ada files/streams are, thus, this will not make any sense to
> simply talk about binary I/O with Ada. So let simply talk about non-
> text I/O from and to standard input/output.
>
> When some people need this, what is the typical preferred to do so ?
Package Ada.Text_IO.Text_Streams (ARM A.12.2) allows converting
Ada.Text_IO.File_Type to Stream_Access and reading and writing them through the
capabilities of streams. This allows converting standard input and output to
Stream_Access, since Ada.Text_IO provides the functions Standard_Input and
Standard_Output which return Ada.Text_IO.File_Type.
For general binary I/O, one can use Ada.Sequential_IO or Ada.Direct_IO
instantiated with an appropriate type, or Ada.Streams.Stream_IO. For standard
input and output, however, this can only work if you have a name for these files
that you can use to open them, and such a name is platform-dependent. The only
independent way to access these files is through streams and
Ada.Text_IO.Text_Streams.
--
Jeff Carter
"Drown in a vat of whiskey. Death, where is thy sting?"
Never Give a Sucker an Even Break
106
^ permalink raw reply [relevance 5%]
* Re: Null Range in Unconstrasined Array
2009-09-09 19:22 0% ` sjw
@ 2009-09-10 23:24 0% ` Stephen Leake
0 siblings, 0 replies; 170+ results
From: Stephen Leake @ 2009-09-10 23:24 UTC (permalink / raw)
sjw <simon.j.wright@mac.com> writes:
> On Sep 9, 9:35�am, Stephen Leake <stephen_le...@stephe-leake.org>
> wrote:
>> Adam Beneschan <a...@irvine.com> writes:
>> > To elaborate on this a bit further: Suppose you define a record type
>> > for reading a file with Ada.Direct_IO, that looks something like this:
>>
>> > � type Employee_Data is record
>> > � � � Name � � : String (1 .. 50);
>> > � � � Address1 : String (1 .. 40);
>> > � � � Address2 : String (1 .. 40);
>> > � � � City � � : String (1 .. 30);
>> > � � � State � �: String (1 .. 2);
>> > � � � ...
>> > � end record;
>
>> It _could_ depend on whether there's a pragma Pack, or a
>> representation clause, for the record. In the absence of such, I would
>> expect the compiler to treat these components the same way it treats
>> separate objects. Which means I would expect the bounds to be stored
>> with the object.
>
> After leaving out the ..., GNAT allocates 162 bytes for this record
> (no dope bytes).
Ok, my expectations are duly updated :).
> Also, if you stream it, it takes just 162 bytes on the stream.
That's not surprising: LRM 13.13.2 says:
3
S'Write
S'Write denotes a procedure with the following specification:
4/2
procedure S'Write(
Stream : not null access Ada.Streams.Root_Stream_Type'Class;
Item : in T)
5
S'Write writes the value of Item to Stream.
The value clearly does not include the bounds.
--
-- Stephe
^ permalink raw reply [relevance 0%]
* Re: Null Range in Unconstrasined Array
2009-09-09 8:35 0% ` Stephen Leake
2009-09-09 13:00 0% ` Robert A Duff
@ 2009-09-09 19:22 0% ` sjw
2009-09-10 23:24 0% ` Stephen Leake
1 sibling, 1 reply; 170+ results
From: sjw @ 2009-09-09 19:22 UTC (permalink / raw)
On Sep 9, 9:35 am, Stephen Leake <stephen_le...@stephe-leake.org>
wrote:
> Adam Beneschan <a...@irvine.com> writes:
> > To elaborate on this a bit further: Suppose you define a record type
> > for reading a file with Ada.Direct_IO, that looks something like this:
>
> > type Employee_Data is record
> > Name : String (1 .. 50);
> > Address1 : String (1 .. 40);
> > Address2 : String (1 .. 40);
> > City : String (1 .. 30);
> > State : String (1 .. 2);
> > ...
> > end record;
> It _could_ depend on whether there's a pragma Pack, or a
> representation clause, for the record. In the absence of such, I would
> expect the compiler to treat these components the same way it treats
> separate objects. Which means I would expect the bounds to be stored
> with the object.
After leaving out the ..., GNAT allocates 162 bytes for this record
(no dope bytes). Also, if you stream it, it takes just 162 bytes on
the stream.
^ permalink raw reply [relevance 0%]
* Re: Null Range in Unconstrasined Array
2009-09-09 8:35 0% ` Stephen Leake
@ 2009-09-09 13:00 0% ` Robert A Duff
2009-09-09 19:22 0% ` sjw
1 sibling, 0 replies; 170+ results
From: Robert A Duff @ 2009-09-09 13:00 UTC (permalink / raw)
Stephen Leake <stephen_leake@stephe-leake.org> writes:
> Adam Beneschan <adam@irvine.com> writes:
>
>> To elaborate on this a bit further: Suppose you define a record type
>> for reading a file with Ada.Direct_IO, that looks something like this:
>>
>> type Employee_Data is record
>> Name : String (1 .. 50);
>> Address1 : String (1 .. 40);
>> Address2 : String (1 .. 40);
>> City : String (1 .. 30);
>> State : String (1 .. 2);
>> ...
>> end record;
>>
>> (Reminds me of my COBOL programming days...) Anyway, it would be very
>> unexpected for the compiler to put two extra integers in the record
>> for each of these strings, and it would mess up your file I/O.
>
> If you expect the layout of this record to match your file, you must
> provide a representation clause.
Good idea.
> It _could_ depend on whether there's a pragma Pack, or a
> representation clause, for the record. In the absence of such, I would
> expect the compiler to treat these components the same way it treats
> separate objects.
Yes.
>...Which means I would expect the bounds to be stored
> with the object.
Most compilers, including GNAT, will not store the bounds with the
object (whether it's a component or a standalone object).
Think about an array of a million of those records:
you don't want 1,000,000 copies of the number 50 stored
at run time. That number is known to the compiler, and can
be plugged in wherever needed (e.g. when you say
"for X in A(Y).Name'Range loop", the compiler knows that's
just "for X in 1..50 loop".
> But that's just my expectations; compilers are free to do whatever they
> want, as long as it meets the standard.
Right.
- Bob
^ permalink raw reply [relevance 0%]
* Re: Null Range in Unconstrasined Array
2009-09-08 17:54 4% ` Adam Beneschan
@ 2009-09-09 8:35 0% ` Stephen Leake
2009-09-09 13:00 0% ` Robert A Duff
2009-09-09 19:22 0% ` sjw
0 siblings, 2 replies; 170+ results
From: Stephen Leake @ 2009-09-09 8:35 UTC (permalink / raw)
Adam Beneschan <adam@irvine.com> writes:
> To elaborate on this a bit further: Suppose you define a record type
> for reading a file with Ada.Direct_IO, that looks something like this:
>
> type Employee_Data is record
> Name : String (1 .. 50);
> Address1 : String (1 .. 40);
> Address2 : String (1 .. 40);
> City : String (1 .. 30);
> State : String (1 .. 2);
> ...
> end record;
>
> (Reminds me of my COBOL programming days...) Anyway, it would be very
> unexpected for the compiler to put two extra integers in the record
> for each of these strings, and it would mess up your file I/O.
If you expect the layout of this record to match your file, you must
provide a representation clause.
> But you have to have the ability to pass any of those fields to a
> subprogram with a parameter type "String", and the bounds have to be
> passed to the subprogram somehow. I think it's most likely that the
> bounds will be passed separately, as Bob suggested, either by
> passing them in separate registers, creating a three-word temporary
> structure that contains the bounds and a pointer to the data and
> passing the address of that structure (with that structure
> disappearing after the subprogram returns), creating a two-word
> structure with the bounds and passing the address of that in a
> register, etc. Something along those lines. But I'd actually be
> surprised if *any* implementation allocated extra space in an
> Employee_Data record to hold the bounds of each field.
It _could_ depend on whether there's a pragma Pack, or a
representation clause, for the record. In the absence of such, I would
expect the compiler to treat these components the same way it treats
separate objects. Which means I would expect the bounds to be stored
with the object.
But that's just my expectations; compilers are free to do whatever they
want, as long as it meets the standard.
--
-- Stephe
^ permalink raw reply [relevance 0%]
* Re: Null Range in Unconstrasined Array
@ 2009-09-08 17:54 4% ` Adam Beneschan
2009-09-09 8:35 0% ` Stephen Leake
0 siblings, 1 reply; 170+ results
From: Adam Beneschan @ 2009-09-08 17:54 UTC (permalink / raw)
On Sep 6, 5:41 am, Robert A Duff <bobd...@shell01.TheWorld.com> wrote:
> There are several ways to implement that.
> For example, the procedure could be passed the bounds as separate
> parameters, in two registers. I don't consider that to
> be "memory allocated for My_Array", because it is not
> allocated when the compiler sees My_Array -- it is allocated
> when the compiler sees a call (and separately for each call).
> In this case, My_Array'Address = X'Address is likely.
To elaborate on this a bit further: Suppose you define a record type
for reading a file with Ada.Direct_IO, that looks something like this:
type Employee_Data is record
Name : String (1 .. 50);
Address1 : String (1 .. 40);
Address2 : String (1 .. 40);
City : String (1 .. 30);
State : String (1 .. 2);
...
end record;
(Reminds me of my COBOL programming days...) Anyway, it would be very
unexpected for the compiler to put two extra integers in the record
for each of these strings, and it would mess up your file I/O. But
you have to have the ability to pass any of those fields to a
subprogram with a parameter type "String", and the bounds have to be
passed to the subprogram somehow. I think it's most likely that the
bounds will be passed separately, as Bob suggested, either by passing
them in separate registers, creating a three-word temporary structure
that contains the bounds and a pointer to the data and passing the
address of that structure (with that structure disappearing after the
subprogram returns), creating a two-word structure with the bounds and
passing the address of that in a register, etc. Something along those
lines. But I'd actually be surprised if *any* implementation
allocated extra space in an Employee_Data record to hold the bounds of
each field.
-- Adam
^ permalink raw reply [relevance 4%]
* Re: Interpretation of extensions different from Unix/Linux?
2009-08-14 4:33 5% ` Randy Brukardt
@ 2009-08-14 7:37 0% ` Dmitry A. Kazakov
0 siblings, 0 replies; 170+ results
From: Dmitry A. Kazakov @ 2009-08-14 7:37 UTC (permalink / raw)
On Thu, 13 Aug 2009 23:33:40 -0500, Randy Brukardt wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:b4dn28zky4qe$.mrr68avem08a$.dlg@40tude.net...
> ...
>> Surprising is that Ada.Directories uses plain String for file names, paths,
>> extension and patterns. This is clearly not an "Ada way" to deal with such
>> things.
>
> Why is that surprising? It has to be compatible with the file names accepted
> by the various Open routines in Ada.Text_IO, Ada.Direct_IO, etc.
>
> You could argue that String is the wrong choice for all of those things, and
> I think you'd be right, but it's irrelevant as we stuck with the Ada 83
> definitions of the file I/O routines. (Adding overloaded ones would be
> unacceptibly incompatible, you wouldn't be able to use literals.)
No, I don't see any problem here. There is no literals for private types,
(unfortunately). But if the type Fully_Qualified_File_Name (or whatever we
called it) should have literals, they would be record aggregates. So we
would write something like:
File : File_Type;
begin
Open
( File => File,
Mode => In_File,
Name =>
( Volume => "C:",
Directory => ("Documents and Settings", "me", "work"),
Name => "test",
Extension => "txt"
) );
the above is impossible due to language limitations, but we could:
File : File_Type;
begin
Open
( File => File,
Mode => In_File,
Volume => "C:",
Directory => ("Documents and Settings", "me", "work"),
Name => "test",
Extension => "txt"
);
or / and
File : File_Type;
begin
Open
( File => File,
Mode => In_File,
Name =>
Name
( Volume => "C:",
Directory => ("Documents and Settings", "me", "work"),
Name => "test",
Extension => "txt"
) );
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
^ permalink raw reply [relevance 0%]
* Re: Interpretation of extensions different from Unix/Linux?
@ 2009-08-14 4:33 5% ` Randy Brukardt
2009-08-14 7:37 0% ` Dmitry A. Kazakov
0 siblings, 1 reply; 170+ results
From: Randy Brukardt @ 2009-08-14 4:33 UTC (permalink / raw)
"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:b4dn28zky4qe$.mrr68avem08a$.dlg@40tude.net...
...
> Surprising is that Ada.Directories uses plain String for file names,
> paths,
> extension and patterns. This is clearly not an "Ada way" to deal with such
> things.
Why is that surprising? It has to be compatible with the file names accepted
by the various Open routines in Ada.Text_IO, Ada.Direct_IO, etc.
You could argue that String is the wrong choice for all of those things, and
I think you'd be right, but it's irrelevant as we stuck with the Ada 83
definitions of the file I/O routines. (Adding overloaded ones would be
unacceptibly incompatible, you wouldn't be able to use literals.)
Randy.
^ permalink raw reply [relevance 5%]
* Re: Large files on 32 and 64 bits ystem
@ 2009-05-26 0:49 5% ` anon
0 siblings, 0 replies; 170+ results
From: anon @ 2009-05-26 0:49 UTC (permalink / raw)
With GNAT:
Ada.Direct_IO uses a file indexes that has the type of Count or Positive_Count.
And these types are based on the positive range which is define as the size of a
long_Integer which is normally in a 32-bit machine set to positive value of
( 2**63 - 1 ).
So it is possible from Ada, but the interface links between Ada and the OS
may limit the size. Or in some cases it could be the OS or device-drivers
that is limiting the file size.
But in looking at the routine System.FileIO.Write_Buf where the exception
occurred and the Interfaces.C.Streams they both limit the file size to
Standard'Address_Size or in the case of GNAT 32-bit version, to a positive
range of 32-bit word aka (2GB -1).
So, the answer is: On a 64-bit machine is limited to 2**64-1 file size
and
on a 32-bit machine is limited to 2**32-1 file size.
In <4a1aedda$0$2855$ba620e4c@news.skynet.be>, Olivier Scalbert <olivier.scalbert@algosyn.com> writes:
>Hello everybody,
>
>Here is my weekly question ....
>
>
>I need to create a file that has 2540160000 bytes, that is a little more
>than 2**31 bytes.
>
>On a 64 bits linux box, it is ok, but on a 32 bits linux box, I have:
>raised ADA.IO_EXCEPTIONS.DEVICE_ERROR : s-fileio.adb:1135
>
>The file length is: 2147483647, which is 2**31 - 1
>
>Is it possible to write more than 2**31 bytes with an Ada program on a
>32 bits linux ?
>
>Thanks for your help,
>
>Olivier.
^ permalink raw reply [relevance 5%]
* Re: How to exit an Ada program with (unix shell) error code?
@ 2009-05-07 9:08 3% ` anon
0 siblings, 0 replies; 170+ results
From: anon @ 2009-05-07 9:08 UTC (permalink / raw)
There are basic three types of programs for computers.
The first, are the "Stand-Alone" programs aka OS types, which do not
return and have no needs for Ada.Command_Line routines. In order
words, there are no links for the Ada.Command_Line package and the
Set_Exit_Status routine.
The second type are "Device Drivers" or "System/Kernel" installable
"Modules". And the Ada.Command_Line package is not legal. But the
Kernel requires the "Module" to notify the kernel by using the
"exit status" so that the kernel can know if it should reclaim the
memory, etc, on errors. Using a "function" type of module install
program is the only way a "Module" can be written and have an
"exit status".
Note: Ada as a computer language should be allowed to create
these type of programs which means that Ada needs to
support main subprogram that are functions.
The third is "Applications" programs but runs under a command shell,
which contains the links for the Ada.Command_Line package. Which
allow a program to use Ada.Command_Line.Set_Exit_Status routine.
But the RM does not force a programmer to use the Set_Exit_Status
in Ada.Command_Line package to return the "exit status"
Note: In GNAT, using a function for the main subprogram, the return value
of this function will be the "exit status". And if the program
uses the Ada.Command_Line.Set_Exit_Status routine the value is
discarded.
Then you have one of the "High Priority" concepts within the Ada language
that is the "Safety and Security" concerns which make it illegal and against
the RM for any Ada program to cause the OS or an external environment to
become unstable. This includes, the execution of the Ada programs, or the
result of its exiting. Now returning a "exit status" help keep the OS
stable. Because the "exit status" can informs the OS if it needs to perform
any error recovery processes on the resources used by the Ada program before
reclaiming that resource, such as closing files that Ada can not close or
reset devices that Ada has no knowledge of how to do.
And since there are times where the Ada.Command_Line package is
not available, there has to be a way to send a "exit status" to the OS
in those case. The easiest is to use function type of "main subprograms"
which returns the program "exit status". One reason is if the Ada
programmer, is using a "close source" Ada RTL there is no way of knowing
how to perform a Set_Exit_Status for that version of Ada.
Note: Is Ada becoming like C!!!!
Ada does allow some tricks that makes it more like C's nasty little
tricks. Like using "pragma Import" and "pragma Export" within Ada to Ada
packages which bypasses Ada package design structure is one. GNAT loves
this one in the GNAT RTL. This also, can cause errors in the elaboration
order which may result in other problems.
Also, another one is in all of the GNAT programs (like gnatmake,
gnatbind, gnatlink to name three) in the GNAT package are using a
File_Descriptor type and direct to C type of IO routines which are defined
in the System.OS_LIB or the older GNAT.OS_LIB package. These are not apart
of the RM. Why did they not just use "File_Type" from either Ada.Text_IO,
Ada.Direct_IO, or Ada.Sequential_IO standard Ada packages. All source files
and the assembly translated output files can be handled by the Ada.Text_IO
package. While the ALI files could use either Ada.Text_IO or
Ada.Sequential_IO package. And as for the objects files, well in the
GNAT design, all object files are created by the gcc "as", and are linked
with either the gcc's "collect2" or "ld" be default.
Note: There are options for other version of linkers, but GNATLINK
defaufts to gcc's "collect2" or "ld".
Actually it seams that every year more and more trashy C routines
and data types are inserted in the packages that GNAT wants programmers to
use. Like the C file structure and routines in the System.OS_LIB package.
Yes, some of those have been around for years, but by now Adacore should be
rewritting then to use pure RM Ada. And provide only a limited standard
C and OS library routines, such as may be System.Sockets. Plus, every year
there are always additional C files, to be interfaces C libraries and OS to Ada.
And I notice last year the GNAT GPL 2008 had one C file that replaced a
couple of Ada routines that were in the GNAT GPL 2007. That's going away
from Ada back to C, that's just WRONG!
In <356247f9-4a83-44aa-a412-4500e6af19cf@f1g2000prb.googlegroups.com>, Adam Beneschan <adam@irvine.com> writes:
>On May 5, 8:34 am, Jean-Pierre Rosen <ro...@adalog.fr> wrote:
>> Adam Beneschan a =E9crit :> Right; and even if your Ada compiler *does* s=
>upport functions that
>> > return integers as main programs, and you're compiling for some
>> > operating system with an "x" in its name (or Solaris), this does *not*
>> > mean that the Ada compiler will treat the function result as the
>> > status code. The compiler could decide that the function result is
>> > something to be formatted and spit out onto standard output. If an
>> > Ada implementation supports parameters and/or function results on main
>> > programs, the language leaves it up to the implementation how those
>> > are interpreted. There's no rule that says that the interpretation
>> > has to mimic the behavior of the C language (thank God). So anon's
>> > solution may work on GNAT, but it can't be assumed to work anywhere
>> > else.
>>
>> That's right from a legalistic point of view, but don't forget that
>> compiler writers are not masochists.
>
>That last statement might be tautologically false. :) :) :)
>
>In any case, if you're implying that writing the extra code needed to
>get the program to display the function result on the standard output
>is an act of self-inflicted pain---trust me, it's nowhere near as
>painful as trying to understand and implement 3.10.2.
>
>
>> If an implementation supports
>> functions returning integers as main programs, I would be very surprised
>> if it was not interpreted as the return code, since this is what the
>> consumer would expect...
>
>Irvine Compiler's Ada compiler (the one I masochistically work on
>maintaining) does behave in the way I described. Main subprograms can
>be procedures or functions; they can take parameters that are scalars
>or String (which are parsed from the command line); and they can be
>functions that return scalars or String, with the result being
>formatted and displayed on the standard output. The compiler was
>originally written to run on Unix and VMS---and, by the way, I'm not
>sure that VMS supports the convention that a main program's function
>result becomes the return status (which is not a simple zero or non-
>zero as it is on Unix, if I recall correctly). The compiler also runs
>on a variety of other targets, although the parameters and function
>result aren't supported in most cases.
>
>Surprised? Well, the compiler is consistent across platforms and with
>respect to allowing various types to be used as function results. It
>wouldn't make any sense to break consistency and make integer-
>returning functions on Unix-type platforms behave differently. And
>nobody has ever complained about it. As for whether it's what I'd
>expect if I were a consumer... I'm not much of a C hack, but when I
>do use C I use exit() to set the status code, not "return", which
>seems to me to pervert the meaning of what a "function" and a function
>result should be; or as Georg said it, it's "playing tricks" with the
>language. I don't feel any particular need to expect Ada compilers to
>support the same sort of trickery C programmers are used to.
>
>But that's just my opinion.
>
> -- Adam
>
>
>
^ permalink raw reply [relevance 3%]
* Re: Ada.Directories problems, a summary
@ 2009-01-01 20:41 3% ` anon
0 siblings, 0 replies; 170+ results
From: anon @ 2009-01-01 20:41 UTC (permalink / raw)
1. OS problem. Name encoding must match OS and file system that being
used. And that may be different between locations or OSs.
2. OS problem, that all programming languages have to deal with.
3. No need. The usage is just as easy as using a Alphanumeric
directory names. And traversing the directory tree is more portable
since more current file system use "." and "..". It is also, easy
to check and skip them while going deeper within a directory tree.
Note, most file search routines understand how to deal with these
two special directories.
4. Another standards OS problem. Drives are not directories in Windows
and DOS. And this includes some embedded OS. Actually most Windows
uses wish that MS would replace the DOS drive letters with "/"
directory structure because of the internet usage of "/".
5. Windows and it's apps designs loves Popups. This is a MS problem
not Ada or GNAT.
6. Another OS problem. If a drive is not ready, is it a "drive not mounted"
or is there a problem with the drive such as a "drive crash". So, this
not useful, in Ada.Directories or any file type package ( Ada.Direct_IO,
Ada.Sequential_IO, or Ada.Text_IO ). The drive should be installed and
mounted before Ada even tries to access any file or directory routine.
Since, most current computers system have CD/DVD and USB ports
that allow Flash or external drives. Ada needs an Ada.OS_Library for
common and standard routines that can handle mounting or hardware
problems. In this package, the program could ask if a drive is
mounted or is the drive working proper. Or the program could
request for a drive aka CD/DVD to be inserted. Of course this would
mean another Windows popup screen.
7. Not a standard concept in all file systems or OSs and may be phase out
completely. For some OS, its a security option (allowing duplicate files
for simple file backup concept, etc), that should be handled by an
Security package. For Windows, the version numbers are used as one
way to allow floppies to use long file names under the MS FAT files
structure. But as flash drives (using FS which uses long file names
structure) replace floppies so it seams that MS will phase out the use
of the version numbers design. Maybe VMS should too.
So, the only thing that you have stated that may alter Ada is the one
that causes an Ada.OS_library package. To determine rather a drive is
mounted or has crashed. And another routine to mount a drive.
In <17rohiaha9ome$.1gz45no0bqro2.dlg@40tude.net>, "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>After experimenting with Ada.Directories I collected the issues I think
>must be addressed to make Ada.Directories more usable:
>
>1. Name encoding. Either String versions should be UTF-8 or else replaced
>with Wide_Wide_String ones.
>
>2. Name canonization / comparison functions. Presently it is impossible to
>compare files by names because the same file may have potentially an
>infinite number of names.
>
>3. Fake children "." and ".." should have special File_Kind
>(Virtual_Directory_File, for example). Else it is impossible to traverse
>the directory tree in a portable way.
>
>4. There should be a variant of Start_Search without the Directory
>parameter, in order to enumerate the roots of the file systems. For
>example, to find drive letters under Windows, network shares, mount points
>etc.
>
>5. The behavior of Exists must be specified for the case of mountable
>volumes. Presently GNAT implementation pops a message box under Windows.
>This should be outlawed.
>
>6. Is_Mountable / Is_Removable functions should be provided.
>
>7. Version number in addition to Containing_Directory, Base_Name and
>Extension. (Files have version numbers under VMS)
>
>Any comments?
>
>P.S. Happy New Year!
>
>--
>Regards,
>Dmitry A. Kazakov
>http://www.dmitry-kazakov.de
^ permalink raw reply [relevance 3%]
* Re: GNAT Pro for .NET
2008-11-26 7:05 3% ` Brad Moore
@ 2008-11-29 20:07 0% ` george.priv
0 siblings, 0 replies; 170+ results
From: george.priv @ 2008-11-29 20:07 UTC (permalink / raw)
On Nov 26, 2:05 am, Brad Moore <brad.mo...@shaw.ca> wrote:
> george.p...@gmail.com wrote:
> > Wonder if anyone has any experience with Ada .NET? How well it is
> > integrated and what are the major issues you had with it?
>
> I've been involved in a port of a number-crunching system originally
> written in Ada 83 from a different compiler vendor running on Unix, to
> Gnat on Windows in Ada 95, and then most recently to .NET in Ada 2005
> using Gnat Pro for .NET. I say port, but for the most part it was simply
> a matter of setting the compiler switches for Ada 95, and Ada 2005,
> and recompiling, though we have been introducing new language features
> during maintenance of the system.
>
> The original system features several tasks with rendezvous, and heavy
> use of the Ada math libraries. There is no GUI involved.
>
> My experiences from these ports are;
>
> Port 1) Ada 83 SCO Unix (non-Gnat vendor) to Win32 Gnat in Ada 95
>
> - Issues relating to compiler vendor switch:
> None come to mind
>
> _ Issues relating to language switch, Ada 83 - Ada 95
> 1) We had a generic protected queue, which had used the Ada 95
> reserved word "protected" in its variable names. We had to
> change the name of the variables to something else.
> (A very trivial change)
> 2) The generic would accept an unconstrained type as a formal
> parameter. In Ada 95, we had to add the box notation to the
> formal paramter.
>
> eg. Instead of;
>
> generic
> type Element_Type is private;
> package P is
>
> we had to write;
> generic
> type Element_Type (<>) is private;
> package P is
> ...
> Another very trivial change.
>
> 3) We had used passive tasks in a couple of places. In Ada 95, we
> replaced these library units with protected types.
> This was a bit more work, but the end result was satisfying and
> a better result.
>
> - Issues relating to operating system switch: Unix to Windows
> This was probably the biggest impact, though we had isolated OS
> routines, so changes were quite localized. The biggest challenge
> was finding a replacement for Unix's memory mapped array feature,
> which Windows didn't seem to have matching support for.
>
> - Issues relating to change from services being invoked by CORBA to
> interface accessed via a DLL.
> The use of the Interfaces.C library routines was very helpful.
> To invoke the DLL from .NET, a .NET wrapper was needed to complete
> the interface.
>
> -------------------------------------------------
>
> Port 2: Ada 95 Windows to Ada 2005 .NET
>
> - Issues relating to the language switch. (Ada 95 to Ada 2005)
> None: Or at least I don't recall there being any.
> We have now incorporated new language features including interfaces,
> Ada.Directories, containers, object prefix notation, to name a few.
> These mostly come as enhancements needed for maintenance, and are
> unrelated to the actual port.
>
> - Issues going from win32 to .NET
> For the most part we didn't need to make any significant code
> changes. There are a few libraries that weren't implemented in .NET
> Ada. The ones that
> come to mind are Ada.Direct_IO and Ada.Directories I believe, though
> there are other libraries that come with Gnat that provided suitable
> workarounds. There may have been some other minor issues, but we
> found workarounds for everything. The application runs well in .NET.
> We no longer needed the .NET wrapper around our DLL, which simplified
> things. We had to get rid of our Interfaces.C pragmas and replace
> with similar vendor specific pragmas for interfacing to .NET.
> I believe the full list of issues/differences between .NET Gnat Pro
> and Windows Gnat Pro can be obtained from Adacore.
>
> Regards,
> Brad Moore
Thanks for the info. I played a little with free version but seems
that it has some issues. Maybe it's just lack of documentation. I am
considering investing in Gnat Pro next year, so it is nice to know in
advance.
Regards,
George Privalov.
^ permalink raw reply [relevance 0%]
* Re: GNAT Pro for .NET
@ 2008-11-26 7:05 3% ` Brad Moore
2008-11-29 20:07 0% ` george.priv
0 siblings, 1 reply; 170+ results
From: Brad Moore @ 2008-11-26 7:05 UTC (permalink / raw)
george.priv@gmail.com wrote:
> Wonder if anyone has any experience with Ada .NET? How well it is
> integrated and what are the major issues you had with it?
I've been involved in a port of a number-crunching system originally
written in Ada 83 from a different compiler vendor running on Unix, to
Gnat on Windows in Ada 95, and then most recently to .NET in Ada 2005
using Gnat Pro for .NET. I say port, but for the most part it was simply
a matter of setting the compiler switches for Ada 95, and Ada 2005,
and recompiling, though we have been introducing new language features
during maintenance of the system.
The original system features several tasks with rendezvous, and heavy
use of the Ada math libraries. There is no GUI involved.
My experiences from these ports are;
Port 1) Ada 83 SCO Unix (non-Gnat vendor) to Win32 Gnat in Ada 95
- Issues relating to compiler vendor switch:
None come to mind
_ Issues relating to language switch, Ada 83 - Ada 95
1) We had a generic protected queue, which had used the Ada 95
reserved word "protected" in its variable names. We had to
change the name of the variables to something else.
(A very trivial change)
2) The generic would accept an unconstrained type as a formal
parameter. In Ada 95, we had to add the box notation to the
formal paramter.
eg. Instead of;
generic
type Element_Type is private;
package P is
we had to write;
generic
type Element_Type (<>) is private;
package P is
...
Another very trivial change.
3) We had used passive tasks in a couple of places. In Ada 95, we
replaced these library units with protected types.
This was a bit more work, but the end result was satisfying and
a better result.
- Issues relating to operating system switch: Unix to Windows
This was probably the biggest impact, though we had isolated OS
routines, so changes were quite localized. The biggest challenge
was finding a replacement for Unix's memory mapped array feature,
which Windows didn't seem to have matching support for.
- Issues relating to change from services being invoked by CORBA to
interface accessed via a DLL.
The use of the Interfaces.C library routines was very helpful.
To invoke the DLL from .NET, a .NET wrapper was needed to complete
the interface.
-------------------------------------------------
Port 2: Ada 95 Windows to Ada 2005 .NET
- Issues relating to the language switch. (Ada 95 to Ada 2005)
None: Or at least I don't recall there being any.
We have now incorporated new language features including interfaces,
Ada.Directories, containers, object prefix notation, to name a few.
These mostly come as enhancements needed for maintenance, and are
unrelated to the actual port.
- Issues going from win32 to .NET
For the most part we didn't need to make any significant code
changes. There are a few libraries that weren't implemented in .NET
Ada. The ones that
come to mind are Ada.Direct_IO and Ada.Directories I believe, though
there are other libraries that come with Gnat that provided suitable
workarounds. There may have been some other minor issues, but we
found workarounds for everything. The application runs well in .NET.
We no longer needed the .NET wrapper around our DLL, which simplified
things. We had to get rid of our Interfaces.C pragmas and replace
with similar vendor specific pragmas for interfacing to .NET.
I believe the full list of issues/differences between .NET Gnat Pro
and Windows Gnat Pro can be obtained from Adacore.
Regards,
Brad Moore
^ permalink raw reply [relevance 3%]
* Re: Stability of GNAT.Directory_Operations
2008-10-07 15:24 5% Stability of GNAT.Directory_Operations Maciej Sobczak
@ 2008-10-07 16:24 0% ` Jean-Pierre Rosen
0 siblings, 0 replies; 170+ results
From: Jean-Pierre Rosen @ 2008-10-07 16:24 UTC (permalink / raw)
Maciej Sobczak a �crit :
> Hi,
>
> Is it possible to delete a file (in terms of Ada.Direct_IO.Delete, for
> example) in the middle of a directory iteration done with
> GNAT.Directory_Operations.Read?
>
I don't know the exact answer to this question, but note that it is not
different from the file being deleted by external means (i.e. outside
the Ada program) during iteration - something that can happen at any time.
--
---------------------------------------------------------
J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr
^ permalink raw reply [relevance 0%]
* Stability of GNAT.Directory_Operations
@ 2008-10-07 15:24 5% Maciej Sobczak
2008-10-07 16:24 0% ` Jean-Pierre Rosen
0 siblings, 1 reply; 170+ results
From: Maciej Sobczak @ 2008-10-07 15:24 UTC (permalink / raw)
Hi,
Is it possible to delete a file (in terms of Ada.Direct_IO.Delete, for
example) in the middle of a directory iteration done with
GNAT.Directory_Operations.Read?
The case in question is deleting a file that has been already visited
by GNAT.Directory_Operations.Read, but deleting a file before it is
visited is also an interesting scenario.
The GNAT.Directory_Operations specification file does not document it.
--
Maciej Sobczak * www.msobczak.com * www.inspirel.com
Database Access Library for Ada: www.inspirel.com/soci-ada
^ permalink raw reply [relevance 5%]
* Re: Files and controlled types
2008-03-09 13:27 0% ` Maciej Sobczak
@ 2008-03-10 15:37 0% ` Adam Beneschan
0 siblings, 0 replies; 170+ results
From: Adam Beneschan @ 2008-03-10 15:37 UTC (permalink / raw)
On Mar 9, 6:27 am, Maciej Sobczak <see.my.homep...@gmail.com> wrote:
> On 9 Mar, 04:12, "Jeffrey R. Carter" <spam.jrcarter....@spam.acm.org>
> wrote:
>
> > > File types are not Controlled.
> > > What is the rationale for this?
>
> > What makes you think they're not controlled.
>
> a) AARM
> b) trivial test
>
> > The ARM only gives the public view,
> > which is limited private; there's nothing to prevent the full view from being
> > controlled.
>
> There is nothing that mandates it and therefore I have to assume it is
> not done. This is actually what I see in tests.
>
> > In addition, the descriptions of Ada.Sequential_IO, Ada.Direct_IO,
> > and Ada.Text_IO all include the language "The type File_Type needs finalization
> > (see 7.6)".
>
> This is very good - I haven't notice it.
> It is very good, because then instead of broken library definition we
> can talk about implementation bugs - these are easier to fix.
>
> My little test follows:
>
> with Ada.Text_IO;
> procedure A is
>
> procedure New_File (I : in Integer) is
> Name : String := "temp/" & Integer'Image (I) & ".txt";
> F : Ada.Text_IO.File_Type;
> begin
> Ada.Text_IO.Put_Line ("Opening " & Name);
> Ada.Text_IO.Create (F, Ada.Text_IO.Out_File, Name);
> -- Ada.Text_IO.Close (F);
> end New_File;
>
> begin
> for I in -1000 .. -1 loop
> New_File (I);
> end loop;
> end;
>
> This program creates 1000 files with names "temp/-1000.txt",
> "temp/-999.txt", etc. (I use negative counters because I don't want to
> waste my time with that useless space in front of the image of
> positive integer value).
> If the File_Type has finalization, then this program is expected to
> finish correctly without the Close call (uncommented above).
> On my computer it fails with USE_ERROR after creating 253 files. If we
> add the three standard I/O streams, we get a reasonable assumption
> that the program has hit an implementation limit (256?) of open file
> descriptors.
> If I uncomment the Close call, the program properly creates full 1000
> set of files.
> I expect Close to be called automatically as part of finalization.
I'm not so sure. What happens here?
procedure New_File (I : in Integer) is
Name : String := "temp/" & Integer'Image (I) & ".txt";
F : Ada.Text_IO.File_Type;
begin
Ada.Text_IO.Put_Line ("Opening " & Name);
Ada.Text_IO.Create (F, Ada.Text_IO.Out_File, Name);
Ada.Text_IO.Set_Output (F);
end New_File;
procedure Proc is
begin
New_File (-17);
Ada.Text_IO.Put_Line ("This is written to default output");
end Proc;
New_File will set the current default output file to File. When Proc
calls Put_Line, will it then write to that default output file, or
will Put_Line raise an exception or be erroneous? I'm not 100% clear
on this. Another question is, what do we (as language designers)
*want* it to do, or what should it do?
But in any case, I haven't seen anywhere in the RM that says that
finalizing a File_Type object involves closing it. And examples like
this, involving default files or File_Access, show that perhaps you
don't *want* files to be closed when File_Type objects are finalized.
(The RM phrase that says a File_Type "needs finalization" is, I'm
afraid, a smokescreen; this clause has *no* impact whatsoever unless
you have a "pragma Restrictions(No_Nested_Finalization)" in effect,
which would make it illegal to declare certain File_Type objects. See
AI95-360, http://www.ada-auth.org/cgi-bin/cvsweb.cgi/AIs/AI-00360.TXT?rev=1.11
.
This clause doesn't have any effect on the semantics.)
The bottom line is that things just aren't so simple, and it's not
obvious whether a File_Type "should" cause a Close when the File_Type
is finalized.
-- Adam
^ permalink raw reply [relevance 0%]
* Re: Files and controlled types
2008-03-09 3:12 5% ` Jeffrey R. Carter
2008-03-09 13:27 0% ` Maciej Sobczak
@ 2008-03-09 16:39 0% ` gpriv
1 sibling, 0 replies; 170+ results
From: gpriv @ 2008-03-09 16:39 UTC (permalink / raw)
On Mar 8, 11:12 pm, "Jeffrey R. Carter"
<spam.jrcarter....@spam.acm.org> wrote:
> Maciej Sobczak wrote:
>
> > File types are not Controlled.
> > What is the rationale for this?
>
> What makes you think they're not controlled. The ARM only gives the public view,
> which is limited private; there's nothing to prevent the full view from being
> controlled. In addition, the descriptions of Ada.Sequential_IO, Ada.Direct_IO,
> and Ada.Text_IO all include the language "The type File_Type needs finalization
> (see 7.6)".
Doesn't it mean that it's user responsibility to close the file?
George
>
> --
> Jeff Carter
> "No one is to stone anyone until I blow this whistle,
> do you understand? Even--and I want to make this
> absolutely clear--even if they do say, 'Jehovah.'"
> Monty Python's Life of Brian
> 74
^ permalink raw reply [relevance 0%]
* Re: Files and controlled types
2008-03-09 3:12 5% ` Jeffrey R. Carter
@ 2008-03-09 13:27 0% ` Maciej Sobczak
2008-03-10 15:37 0% ` Adam Beneschan
2008-03-09 16:39 0% ` gpriv
1 sibling, 1 reply; 170+ results
From: Maciej Sobczak @ 2008-03-09 13:27 UTC (permalink / raw)
On 9 Mar, 04:12, "Jeffrey R. Carter" <spam.jrcarter....@spam.acm.org>
wrote:
> > File types are not Controlled.
> > What is the rationale for this?
>
> What makes you think they're not controlled.
a) AARM
b) trivial test
> The ARM only gives the public view,
> which is limited private; there's nothing to prevent the full view from being
> controlled.
There is nothing that mandates it and therefore I have to assume it is
not done. This is actually what I see in tests.
> In addition, the descriptions of Ada.Sequential_IO, Ada.Direct_IO,
> and Ada.Text_IO all include the language "The type File_Type needs finalization
> (see 7.6)".
This is very good - I haven't notice it.
It is very good, because then instead of broken library definition we
can talk about implementation bugs - these are easier to fix.
My little test follows:
with Ada.Text_IO;
procedure A is
procedure New_File (I : in Integer) is
Name : String := "temp/" & Integer'Image (I) & ".txt";
F : Ada.Text_IO.File_Type;
begin
Ada.Text_IO.Put_Line ("Opening " & Name);
Ada.Text_IO.Create (F, Ada.Text_IO.Out_File, Name);
-- Ada.Text_IO.Close (F);
end New_File;
begin
for I in -1000 .. -1 loop
New_File (I);
end loop;
end;
This program creates 1000 files with names "temp/-1000.txt",
"temp/-999.txt", etc. (I use negative counters because I don't want to
waste my time with that useless space in front of the image of
positive integer value).
If the File_Type has finalization, then this program is expected to
finish correctly without the Close call (uncommented above).
On my computer it fails with USE_ERROR after creating 253 files. If we
add the three standard I/O streams, we get a reasonable assumption
that the program has hit an implementation limit (256?) of open file
descriptors.
If I uncomment the Close call, the program properly creates full 1000
set of files.
I expect Close to be called automatically as part of finalization.
So - is it the implementation (GNAT) bug?
Or maybe the finalization is concerned with memory management only
(buffers, etc.) and not with external resources? In that case I
consider it a bug in AARM.
--
Maciej Sobczak * www.msobczak.com * www.inspirel.com
^ permalink raw reply [relevance 0%]
* Re: Files and controlled types
@ 2008-03-09 3:12 5% ` Jeffrey R. Carter
2008-03-09 13:27 0% ` Maciej Sobczak
2008-03-09 16:39 0% ` gpriv
0 siblings, 2 replies; 170+ results
From: Jeffrey R. Carter @ 2008-03-09 3:12 UTC (permalink / raw)
Maciej Sobczak wrote:
>
> File types are not Controlled.
> What is the rationale for this?
What makes you think they're not controlled. The ARM only gives the public view,
which is limited private; there's nothing to prevent the full view from being
controlled. In addition, the descriptions of Ada.Sequential_IO, Ada.Direct_IO,
and Ada.Text_IO all include the language "The type File_Type needs finalization
(see 7.6)".
--
Jeff Carter
"No one is to stone anyone until I blow this whistle,
do you understand? Even--and I want to make this
absolutely clear--even if they do say, 'Jehovah.'"
Monty Python's Life of Brian
74
^ permalink raw reply [relevance 5%]
* Ada.Directories.Size wraps on over 2Gb files
@ 2007-12-10 21:38 5% gpriv
0 siblings, 0 replies; 170+ results
From: gpriv @ 2007-12-10 21:38 UTC (permalink / raw)
Couple of things that I found so far:
Ada.Directories.Size wraps on over 2Gb files returning negative
number. I saw that was mentioned in
In addition to that:
In addition to that Ada.Direct_IO.Size returns 0 on the same while
End_Of_File is permanently true. At the same time it is possible to
write files larger than 2G.
Types are all seem to be long integers, so it looks like truncation is
being made somewhere in C code (?)
Regards,
George.
^ permalink raw reply [relevance 5%]
* Ada.Directories.Size wraps on over 2Gb files
@ 2007-12-10 21:37 5% gpriv
0 siblings, 0 replies; 170+ results
From: gpriv @ 2007-12-10 21:37 UTC (permalink / raw)
Couple of things that I found so far:
Ada.Directories.Size wraps on over 2Gb files returning negative
number. I saw that was mentioned in
In addition to that:
In addition to that Ada.Direct_IO.Size returns 0 on the same while
End_Of_File is permanently true. At the same time it is possible to
write files larger than 2G.
Types are all seem to be long integers, so it looks like truncation is
being made somewhere in C code (?)
Regards,
George.
^ permalink raw reply [relevance 5%]
* Re: Concatenating files
2007-09-22 22:51 0% ` mhamel_98
@ 2007-09-23 1:45 5% ` Jeffrey R. Carter
0 siblings, 0 replies; 170+ results
From: Jeffrey R. Carter @ 2007-09-23 1:45 UTC (permalink / raw)
mhamel_98@yahoo.com wrote:
> Hi Jeff, I don't have any resources available in front of me, but I
> always thought Direct_Io was essentially the same as Sequential_Io
> save for the additional ability of retrieving, or reading, the "nth"
> record without having to start from the beginning of the file. Does
> Direct_Io allow editing, or writing, of said "nth" record without
> disrupting records written before or after? Or, does Direct_Io allow
> writing to the "nth" place? in which case I would start writing my
> data starting at 2, for instance, then when complete, write the first,
> or header record.
Ada.Direct_IO is specified in ARM A.8.4:
http://www.adaic.org/standards/05rm/html/RM-A-8-4.html
It includes the operations
procedure Read (File : in File_Type;
Item : out Element_Type;
From : in Positive_Count);
procedure Write(File : in File_Type;
Item : in Element_Type;
To : in Positive_Count);
You may read and write from any position in the file.
--
Jeff Carter
"Ada has made you lazy and careless. You can write programs in C that
are just as safe by the simple application of super-human diligence."
E. Robert Tisdale
72
^ permalink raw reply [relevance 5%]
* Re: Concatenating files
2007-09-22 20:07 5% ` Jeffrey R. Carter
@ 2007-09-22 22:51 0% ` mhamel_98
2007-09-23 1:45 5% ` Jeffrey R. Carter
0 siblings, 1 reply; 170+ results
From: mhamel_98 @ 2007-09-22 22:51 UTC (permalink / raw)
Hi Jeff, I don't have any resources available in front of me, but I
always thought Direct_Io was essentially the same as Sequential_Io
save for the additional ability of retrieving, or reading, the "nth"
record without having to start from the beginning of the file. Does
Direct_Io allow editing, or writing, of said "nth" record without
disrupting records written before or after? Or, does Direct_Io allow
writing to the "nth" place? in which case I would start writing my
data starting at 2, for instance, then when complete, write the first,
or header record.
On Sep 22, 1:07 pm, "Jeffrey R. Carter"
<spam.jrcarter....@acm.nospam.org> wrote:
> mhamel...@yahoo.com wrote:
> > Thanks for the replies! How about this, instantiating Sequential_Io
> > with a variant record? The header data can be put into a record
> > easily enough, so I would write the first sequential record as a
> > header type with the following as the original data records. The
> > problem is, some of the header data will not be known until all the
> > data records have been written. Is there a way to edit, in place, the
> > first record of a sequential file? Thanks much again c.l.a!
>
> Sounds as if Ada.Direct_IO would be better.
>
> --
> Jeff Carter
> "Ada has made you lazy and careless. You can write programs in C that
> are just as safe by the simple application of super-human diligence."
> E. Robert Tisdale
> 72
^ permalink raw reply [relevance 0%]
* Re: Concatenating files
@ 2007-09-22 20:07 5% ` Jeffrey R. Carter
2007-09-22 22:51 0% ` mhamel_98
0 siblings, 1 reply; 170+ results
From: Jeffrey R. Carter @ 2007-09-22 20:07 UTC (permalink / raw)
mhamel_98@yahoo.com wrote:
> Thanks for the replies! How about this, instantiating Sequential_Io
> with a variant record? The header data can be put into a record
> easily enough, so I would write the first sequential record as a
> header type with the following as the original data records. The
> problem is, some of the header data will not be known until all the
> data records have been written. Is there a way to edit, in place, the
> first record of a sequential file? Thanks much again c.l.a!
Sounds as if Ada.Direct_IO would be better.
--
Jeff Carter
"Ada has made you lazy and careless. You can write programs in C that
are just as safe by the simple application of super-human diligence."
E. Robert Tisdale
72
^ permalink raw reply [relevance 5%]
* Re: Data table text I/O package?
@ 2005-06-21 12:35 5% ` Jacob Sparre Andersen
0 siblings, 0 replies; 170+ results
From: Jacob Sparre Andersen @ 2005-06-21 12:35 UTC (permalink / raw)
Georg Bauhaus wrote:
> Jacob Sparre Andersen wrote:
> > Unlike Ada, XML is _not_ human-readable.
>
> First, this has been claimed many times without even an indication
> of why this might be so. Again, compare
>
> <Date year = "2006" month = "December" day = "24"/>
>
> and
>
> Date'(year => 2006, month => -"December", day => 24);
>
> Could it be that you just don't like reading angle brackets?
I definitely don't like reading _any_ brackets, when I'm looking at
data.
> Do the <...> smell like C++'s template parameter brackets?
They may. But neither of the above two notations are sensible, when I
am playing with 30 � 55k matrices.
> Again, habits? I won't say that XML *looks* nice, but it's purpose
> is not to look nice, this is not a Miss Dataformat Competition where
> you cannot win without rounded curves o.K. by the lates fashion.
> XML is supposed to support identifing data in text form.
Yes. But for tabular data XML has much too much overhead and is thus
too difficult to read.
> > And if I want an error-correcting file format which isn't
> > human-readable, there are plenty to choose from, which are faster than
> > XML.
>
> Such as...?
> ASN.1 perhaps?
I am not sure if ASN.1 includes error-correction, but it was one of
the options I had on my mind, when I wrote the sentence. A much more
effective format would be based on an instantiation of Ada.Direct_IO
with some kind of checksum included in Element_Type. My astrophysics
colleagues also have a nice format for multidimensional tables, but I
can't remember the name at the moment.
Jacob
--
CAUTION
BLADE EXTREMELY SHARP
KEEP OUT OF CHILDREN
^ permalink raw reply [relevance 5%]
* Re: Direct_IO and files of tagged types
2005-05-26 23:51 0% ` Randy Brukardt
@ 2005-05-27 8:38 0% ` Dmitry A. Kazakov
0 siblings, 0 replies; 170+ results
From: Dmitry A. Kazakov @ 2005-05-27 8:38 UTC (permalink / raw)
On Thu, 26 May 2005 18:51:47 -0500, Randy Brukardt wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:86bcmsy3e49m.yjhfcxtf7osr.dlg@40tude.net...
>> On 26 May 2005 10:20:09 -0700, John McCormick wrote:
>>
>>> When I instantiate a version of Ada.Direct_IO with an element type that
>>> is statically tagged (it is of a specific tagged type) GNAT gives me a
>>> warning that the element type contains an access value. My tagged type
>>> has three integer fields - no access types. I assume that the access
>>> type referenced in the warning is to the tag mechanism. Any suggestions
>>> for ways to create binary files of statically tagged objects?
>>
>> It is not a good idea to write tags into a file even if they are statically
>> known, because that cannot be portable. Another general question is: if the
>> tag is always known what for to have it? Without dispatching tags are just
>> useless overhead!
>
> If the object is derived from Controlled, it will be tagged even if no
> (explicit) dispatching is used. And I think that virtually all ADT types
> should be controlled and extensible
Right.
> -- so virtually all types will have
> tags. At worst the overhead is "useless" now; but that probably will change
> in the future.
What for? T'Class should have a tag. T should not.
Provided that T is not a by-reference, limited type then there is no any
good reason to put its tag into. I would really like to have *non-tagged*
controlled and extensible types for which I could have T'Class. Such types
could then be safely used in Direct_IO.
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
^ permalink raw reply [relevance 0%]
* Re: Direct_IO and files of tagged types
2005-05-26 18:22 0% ` Dmitry A. Kazakov
@ 2005-05-26 23:51 0% ` Randy Brukardt
2005-05-27 8:38 0% ` Dmitry A. Kazakov
0 siblings, 1 reply; 170+ results
From: Randy Brukardt @ 2005-05-26 23:51 UTC (permalink / raw)
"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:86bcmsy3e49m.yjhfcxtf7osr.dlg@40tude.net...
> On 26 May 2005 10:20:09 -0700, John McCormick wrote:
>
> > When I instantiate a version of Ada.Direct_IO with an element type that
> > is statically tagged (it is of a specific tagged type) GNAT gives me a
> > warning that the element type contains an access value. My tagged type
> > has three integer fields - no access types. I assume that the access
> > type referenced in the warning is to the tag mechanism. Any suggestions
> > for ways to create binary files of statically tagged objects?
>
> It is not a good idea to write tags into a file even if they are
statically
> known, because that cannot be portable. Another general question is: if
the
> tag is always known what for to have it? Without dispatching tags are just
> useless overhead!
If the object is derived from Controlled, it will be tagged even if no
(explicit) dispatching is used. And I think that virtually all ADT types
should be controlled and extensible -- so virtually all types will have
tags. At worst the overhead is "useless" now; but that probably will change
in the future.
My suggestion to John would be to abandon Direct_IO and use Streams instead;
'Write doesn't write the tag, and Stream_IO allows positioning. Once a type
is tagged, you usually want a hetrogeneous file anyway (that is, the type
probably ought to be T'Class, which isn't going to work with Direct_IO, and
is dubious with Sequential_IO).
Randy.
^ permalink raw reply [relevance 0%]
* Re: Direct_IO and files of tagged types
2005-05-26 17:20 5% Direct_IO and files of tagged types John McCormick
@ 2005-05-26 18:22 0% ` Dmitry A. Kazakov
2005-05-26 23:51 0% ` Randy Brukardt
0 siblings, 1 reply; 170+ results
From: Dmitry A. Kazakov @ 2005-05-26 18:22 UTC (permalink / raw)
On 26 May 2005 10:20:09 -0700, John McCormick wrote:
> When I instantiate a version of Ada.Direct_IO with an element type that
> is statically tagged (it is of a specific tagged type) GNAT gives me a
> warning that the element type contains an access value. My tagged type
> has three integer fields - no access types. I assume that the access
> type referenced in the warning is to the tag mechanism. Any suggestions
> for ways to create binary files of statically tagged objects?
It is not a good idea to write tags into a file even if they are statically
known, because that cannot be portable. Another general question is: if the
tag is always known what for to have it? Without dispatching tags are just
useless overhead!
Anyway what about:
1. Aggregation: you put a plain record into tagged type and do I/O with
that record.
2. A completely independent record type used for external representation of
tagged objects.
3. Handles/smart pointers: tagged objects refer to a plain record type via
an access discriminant or an access type.
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
^ permalink raw reply [relevance 0%]
* Direct_IO and files of tagged types
@ 2005-05-26 17:20 5% John McCormick
2005-05-26 18:22 0% ` Dmitry A. Kazakov
0 siblings, 1 reply; 170+ results
From: John McCormick @ 2005-05-26 17:20 UTC (permalink / raw)
When I instantiate a version of Ada.Direct_IO with an element type that
is statically tagged (it is of a specific tagged type) GNAT gives me a
warning that the element type contains an access value. My tagged type
has three integer fields - no access types. I assume that the access
type referenced in the warning is to the tag mechanism. Any suggestions
for ways to create binary files of statically tagged objects?
^ permalink raw reply [relevance 5%]
* Re: Ada bench : count words
2005-03-22 12:17 0% ` Dmitry A. Kazakov
@ 2005-03-22 13:58 0% ` Robert A Duff
0 siblings, 0 replies; 170+ results
From: Robert A Duff @ 2005-03-22 13:58 UTC (permalink / raw)
"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> On Tue, 22 Mar 2005 11:57:22 +0000, Marius Amado Alves wrote:
>
> >>> ... To implement buffering, I have resorted to
> >>> Ada.Direct_IO, which I think cannot apply to standard input.
> >>
> >> Is Text_IO that bad?
> >
> > No, if you can solve The Get_Line puzzle :-)
>
> What about Get (Item : out Character)?
>
> I wonder if calling C-lib's read would qualify! (:-))
Text_IO is pretty broken, from both a usability perspective and an
efficiency perspective. I normally avoid it, and use pragma Import on
the C routines (open, read, etc). Suitably wrapped in a clean
interface, of course.
I recently installed some third-party code into my project,
which was using Direct_IO (not Text_IO). I rewrote it to
use my I/O routines, and that part of the program sped up
by a couple orders of magnitude.
> I think Text_IO should translate it into LF. But anyway you can always
> assume LF = new line, CR = space in the FSM.
It's astonishing how much human intellectual work has been wasted on
stupid issues like CR/LF vs. LF! And endianness.
> FSM is one of that rare cases where gotos are natural. What a pity that Ada
> does not have arrays of labels! (:-))
I prefer a loop containing a case statement. This has the advantage
that you can insert extra code that happens on every state transition
(e.g. assert that you didn't forget to set the next state explicitly,
print out the state transitions for debugging, etc).
But in *this* case, I'd just use a bunch of while loops and case
statements and so forth. In my experience, most state machines have
plenty of structure, so the totally unstructured methods:
(loop-with-case or rats-nest-of-gotos or state-transition-table) seem
unnecessary.
- Bob
^ permalink raw reply [relevance 0%]
* Re: Ada bench : count words
2005-03-22 10:59 0% ` Dmitry A. Kazakov
2005-03-22 11:57 0% ` Marius Amado Alves
@ 2005-03-22 12:22 0% ` Jeff C
1 sibling, 0 replies; 170+ results
From: Jeff C @ 2005-03-22 12:22 UTC (permalink / raw)
Dmitry A. Kazakov wrote:
> On Tue, 22 Mar 2005 01:16:09 +0000, Marius Amado Alves wrote:
>
>
>>I took a shot at the count-words benchmark, a program to count lines,
>>words and characters. The Ada program currently published there is
>>broken. My program is correct and portable but:
>>
>>- the speed is circa 1/3 of the GCC C version
>>
>>- it fails to comply with the requirement that the input be taken from
>>standard input. To implement buffering, I have resorted to
>>Ada.Direct_IO, which I think cannot apply to standard input.
>
>
> Is Text_IO that bad?
It can be. It does a few things that real programs often do not need to
do (counting pages) and may not do buffering that is optimal for the job
here. The problem is of course that it is a requirement to read from
standard input and if I were running the website I would reject a
program that does not.
Perhaps this could be done by using ada.text_io.text_streams to get
access to a stream based on standard input and then use the "Read"
procedure (v.s. 'read attribute) to get 4k blocks of data (recommended
chunking size from problem definition). The Read procedure uses an
"Item" and "Last" approach so you can look for Last to see how much you
actually read.
Note since Ada 95 came out I hardly ever use direct_io anymore because
even problems that seem to line up well with direct IO over time degrade
as file formats change.
I tend to jump (perhaps to soon) to ada.streams.stream_io approaches and
or approaches like getting access to text_io streams. Note in this case
I am not saying that the text_io stream approach will be faster..I dont
really know..But at least it can be made compliant with the requirements
of the test.
with Text_IO;
with Ada.Text_IO.Text_Streams;
use Ada.Text_IO.Text_Streams;
use Text_IO;
with Ada.Streams;
use Ada.Streams;
procedure stre_test is
S : Stream_Access := Stream(Standard_Input);
Data : Stream_Element_Array(1 .. 10);
Last : Stream_Element_Offset;
begin
Read(S.all, Data, Last);
Text_IO.Put_Line(Stream_Element_Offset'image(Last));
end stre_test;
^ permalink raw reply [relevance 0%]
* Re: Ada bench : count words
2005-03-22 11:57 0% ` Marius Amado Alves
@ 2005-03-22 12:17 0% ` Dmitry A. Kazakov
2005-03-22 13:58 0% ` Robert A Duff
0 siblings, 1 reply; 170+ results
From: Dmitry A. Kazakov @ 2005-03-22 12:17 UTC (permalink / raw)
On Tue, 22 Mar 2005 11:57:22 +0000, Marius Amado Alves wrote:
>>> ... To implement buffering, I have resorted to
>>> Ada.Direct_IO, which I think cannot apply to standard input.
>>
>> Is Text_IO that bad?
>
> No, if you can solve The Get_Line puzzle :-)
What about Get (Item : out Character)?
I wonder if calling C-lib's read would qualify! (:-))
>>> procedure Process (S : in String) is
>>> begin
>>> Lines := Lines + Ada.Strings.Fixed.Count (S, EOL);
>>
>> Isn't it an extra pass? I think you should do parsing using FSM.
>> Character
>> classes are: EOL, delimiter, letter. It is either two character map
>> tests
>> or one case statement. I don't know what is faster. Probably you should
>> test both.
>>
>>> for I in S'Range loop
>>> if Is_Separator (S (I)) then
>>> if In_Word then Finish_Word; end if;
>>> else
>>> if not In_Word then Start_Word; end if;
>>> end if;
>>> end loop;
>>> end;
>
> Note EOL is not a character, but a string, because in some environments
> the thing is a combination of two characters.
I think Text_IO should translate it into LF. But anyway you can always
assume LF = new line, CR = space in the FSM.
> This one-character
> version improves speed (but still only to 1/2 of C):
>
> for I in S'Range loop
> if S (I) = EOL then Lines := Lines + 1; end if;
> if Is_Separator (S (I)) then
> if In_Word then Finish_Word; end if;
> else
> if not In_Word then Start_Word; end if;
> end if;
> end loop;
>
> I have not tried with string matching (if that's what you mean with
> "FSM") because the iteration was already there, and I doubt the
> standard library implements it more efficiently than that.
No, I meant a finite state machine:
<<Word>>
read character;
case Char is
when EOL => Inc line count; goto Blank;
when Space => goto Blank;
when Letter => goto Word;
end case;
<<Blank>>
read character;
case Char is
when EOL => Inc line count; goto Blank;
when Space => goto Blank;
when Letter => Inc word count; goto Word;
end case;
<<Word>>
read character;
case Char is
when EOL => Inc line count; goto Blank;
when Space => goto Blank;
when Letter => goto Word;
end case;
FSM is one of that rare cases where gotos are natural. What a pity that Ada
does not have arrays of labels! (:-))
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
^ permalink raw reply [relevance 0%]
* Re: Ada bench : count words
2005-03-22 10:59 0% ` Dmitry A. Kazakov
@ 2005-03-22 11:57 0% ` Marius Amado Alves
2005-03-22 12:17 0% ` Dmitry A. Kazakov
2005-03-22 12:22 0% ` Jeff C
1 sibling, 1 reply; 170+ results
From: Marius Amado Alves @ 2005-03-22 11:57 UTC (permalink / raw)
To: comp.lang.ada
>> ... To implement buffering, I have resorted to
>> Ada.Direct_IO, which I think cannot apply to standard input.
>
> Is Text_IO that bad?
No, if you can solve The Get_Line puzzle :-)
>> procedure Process (S : in String) is
>> begin
>> Lines := Lines + Ada.Strings.Fixed.Count (S, EOL);
>
> Isn't it an extra pass? I think you should do parsing using FSM.
> Character
> classes are: EOL, delimiter, letter. It is either two character map
> tests
> or one case statement. I don't know what is faster. Probably you should
> test both.
>
>> for I in S'Range loop
>> if Is_Separator (S (I)) then
>> if In_Word then Finish_Word; end if;
>> else
>> if not In_Word then Start_Word; end if;
>> end if;
>> end loop;
>> end;
Note EOL is not a character, but a string, because in some environments
the thing is a combination of two characters. This one-character
version improves speed (but still only to 1/2 of C):
for I in S'Range loop
if S (I) = EOL then Lines := Lines + 1; end if;
if Is_Separator (S (I)) then
if In_Word then Finish_Word; end if;
else
if not In_Word then Start_Word; end if;
end if;
end loop;
I have not tried with string matching (if that's what you mean with
"FSM") because the iteration was already there, and I doubt the
standard library implements it more efficiently than that.
^ permalink raw reply [relevance 0%]
* Re: Ada bench : count words
2005-03-22 1:16 7% ` Ada bench : count words Marius Amado Alves
@ 2005-03-22 10:59 0% ` Dmitry A. Kazakov
2005-03-22 11:57 0% ` Marius Amado Alves
2005-03-22 12:22 0% ` Jeff C
0 siblings, 2 replies; 170+ results
From: Dmitry A. Kazakov @ 2005-03-22 10:59 UTC (permalink / raw)
On Tue, 22 Mar 2005 01:16:09 +0000, Marius Amado Alves wrote:
> I took a shot at the count-words benchmark, a program to count lines,
> words and characters. The Ada program currently published there is
> broken. My program is correct and portable but:
>
> - the speed is circa 1/3 of the GCC C version
>
> - it fails to comply with the requirement that the input be taken from
> standard input. To implement buffering, I have resorted to
> Ada.Direct_IO, which I think cannot apply to standard input.
Is Text_IO that bad?
> Can you help with any of these points? Thanks. The complete program
> follows.
>
> -- Count words in Ada for the language shootout
> -- by Marius Amado Alves
>
> with Ada.Characters.Handling;
> with Ada.Characters.Latin_1;
> with Ada.Command_Line;
> with Ada.Direct_IO;
> with Ada.Strings.Fixed;
> with Ada.Text_IO;
>
> procedure Count_Words is
>
> use Ada.Characters.Handling;
> use Ada.Characters.Latin_1;
> use Ada.Command_Line;
>
> Filename : String := Argument (1);
> Buffer_Size : constant := 4096;
> EOF : Character := FS;
> EOL : String := (1 => LF);
> Lines : Natural := 0;
> Words : Natural := 0;
> Total : Natural := 0;
> In_Word : Boolean := False;
>
> function Is_Separator (C : Character) return Boolean is
> begin
> return Is_Control (C) or C = ' ';
> end;
Why don't you use character map here?
> procedure Start_Word is
> begin
> In_Word := True;
> end;
>
> procedure Finish_Word is
> begin
> Words := Words + 1;
> In_Word := False;
> end;
>
> procedure Process (S : in String) is
> begin
> Lines := Lines + Ada.Strings.Fixed.Count (S, EOL);
Isn't it an extra pass? I think you should do parsing using FSM. Character
classes are: EOL, delimiter, letter. It is either two character map tests
or one case statement. I don't know what is faster. Probably you should
test both.
> for I in S'Range loop
> if Is_Separator (S (I)) then
> if In_Word then Finish_Word; end if;
> else
> if not In_Word then Start_Word; end if;
> end if;
> end loop;
> end;
>
> begin
> declare
> package Character_IO is new Ada.Direct_IO (Character);
> use Character_IO;
> File : File_Type;
> begin
> Open (File, In_File, Filename);
> Total := Natural (Size (File));
> Close (File);
> end;
>
> declare
> subtype Buffer_Type is String (1 .. Buffer_Size);
> package Buffer_IO is new Ada.Direct_IO (Buffer_Type);
> use Buffer_IO;
> File : File_Type;
> S : Buffer_Type;
> begin
> Open (File, In_File, Filename);
> for I in 1 .. Total / Buffer_Size loop
> Read (File, S);
> Process (S);
> end loop;
> Close (File);
> end;
>
> declare
> subtype Rest_Type is String (1 .. Total rem Buffer_Size);
> package Character_IO is new Ada.Direct_IO (Character);
> use Character_IO;
> File : File_Type;
> S : Rest_Type;
> begin
> Open (File, In_File, Filename);
> Set_Index (File, Count (Total - S'Length));
> for I in 1 .. S'Length loop
> Read (File, S (I));
> end loop;
> Close (File);
> Process (S);
> end;
>
> if In_Word then Finish_Word; end if;
>
> Ada.Text_IO.Put_Line
> (Natural'Image (Lines) &
> Natural'Image (Words) &
> Natural'Image (Total));
> end;
P.S. For word frequencies: gcc version uses hash + sort. I wonder if binary
trees could be better here. Or even sorted arrays for simplicity, there is
no item deletion, search is more often than insert... Of course, for tree
node allocation one could use a stack pool instead of heap.
(That's one of the weaknesses of this contest. Actually the method should
have been specified)
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
^ permalink raw reply [relevance 0%]
* Ada bench : count words
@ 2005-03-22 1:16 7% ` Marius Amado Alves
2005-03-22 10:59 0% ` Dmitry A. Kazakov
0 siblings, 1 reply; 170+ results
From: Marius Amado Alves @ 2005-03-22 1:16 UTC (permalink / raw)
To: comp.lang.ada
I took a shot at the count-words benchmark, a program to count lines,
words and characters. The Ada program currently published there is
broken. My program is correct and portable but:
- the speed is circa 1/3 of the GCC C version
- it fails to comply with the requirement that the input be taken from
standard input. To implement buffering, I have resorted to
Ada.Direct_IO, which I think cannot apply to standard input.
Can you help with any of these points? Thanks. The complete program
follows.
-- Count words in Ada for the language shootout
-- by Marius Amado Alves
with Ada.Characters.Handling;
with Ada.Characters.Latin_1;
with Ada.Command_Line;
with Ada.Direct_IO;
with Ada.Strings.Fixed;
with Ada.Text_IO;
procedure Count_Words is
use Ada.Characters.Handling;
use Ada.Characters.Latin_1;
use Ada.Command_Line;
Filename : String := Argument (1);
Buffer_Size : constant := 4096;
EOF : Character := FS;
EOL : String := (1 => LF);
Lines : Natural := 0;
Words : Natural := 0;
Total : Natural := 0;
In_Word : Boolean := False;
function Is_Separator (C : Character) return Boolean is
begin
return Is_Control (C) or C = ' ';
end;
procedure Start_Word is
begin
In_Word := True;
end;
procedure Finish_Word is
begin
Words := Words + 1;
In_Word := False;
end;
procedure Process (S : in String) is
begin
Lines := Lines + Ada.Strings.Fixed.Count (S, EOL);
for I in S'Range loop
if Is_Separator (S (I)) then
if In_Word then Finish_Word; end if;
else
if not In_Word then Start_Word; end if;
end if;
end loop;
end;
begin
declare
package Character_IO is new Ada.Direct_IO (Character);
use Character_IO;
File : File_Type;
begin
Open (File, In_File, Filename);
Total := Natural (Size (File));
Close (File);
end;
declare
subtype Buffer_Type is String (1 .. Buffer_Size);
package Buffer_IO is new Ada.Direct_IO (Buffer_Type);
use Buffer_IO;
File : File_Type;
S : Buffer_Type;
begin
Open (File, In_File, Filename);
for I in 1 .. Total / Buffer_Size loop
Read (File, S);
Process (S);
end loop;
Close (File);
end;
declare
subtype Rest_Type is String (1 .. Total rem Buffer_Size);
package Character_IO is new Ada.Direct_IO (Character);
use Character_IO;
File : File_Type;
S : Rest_Type;
begin
Open (File, In_File, Filename);
Set_Index (File, Count (Total - S'Length));
for I in 1 .. S'Length loop
Read (File, S (I));
end loop;
Close (File);
Process (S);
end;
if In_Word then Finish_Word; end if;
Ada.Text_IO.Put_Line
(Natural'Image (Lines) &
Natural'Image (Words) &
Natural'Image (Total));
end;
^ permalink raw reply [relevance 7%]
* Re: Advanced file manipulation (multiple question)
2005-03-02 10:31 0% ` Steph-ADA
@ 2005-03-03 3:12 0% ` Steve
0 siblings, 0 replies; 170+ results
From: Steve @ 2005-03-03 3:12 UTC (permalink / raw)
It sounds like you have downloaded Gnat 3.15p.
To make OS calls, you'll also want to get gnatwin-3.15p.exe
You can find it here:
http://libre.act-europe.fr/GNAT/
gnatwin includes bindings to most of the Win32 API.
For example in the file win32-winbase.ads
You will find the binding for CopyFile.
function CopyFile (lpExistingFileName : Win32.LPCSTR;
lpNewFileName : Win32.LPCSTR;
bFailIfExists : Win32.BOOL)
return Win32.BOOL
renames CopyFileA; -- winbase.h :4919
It takes a little practice to get all of the right arguments set up with the
right types to make these OS calls. Fortunately you don't have to do it
very often.
Steve
(The Duck)
"Steph-ADA" <france.suisse@gmail.com> wrote in message
news:74a78c42.0503020231.1dc804b6@posting.google.com...
> Hello!
>
> Thanks for your helpful advices, and sorry for 1/my english,
> 2/abscence of details and 3/my error about Lady Lovelace name, Ada
> (and not ADA or anything else). I Hope this next post would be better
> :)
>
> So, first, my OS: Windows 2000 Pro. I use Gnat 3.15 (public).
> I started Ada as a student, with few advices and then... concurrent
> programming the next week (semaphore etc...), that was rather... hard,
> for beginners!
> So, my excuse if I don't know how call OS functions... maybe you have
> links where I can find tutorials about this ?
>
>> If you use Ada.Direct_Io, there is a nice way to read the file in one
>> read,
>> but it takes two steps.
>> First create an instance of Ada.Direct_Io of bytes.
>> Open the file as bytes.
>> Use the size function to get the size of the file.
>> Close the file
>> Create an instance of Ada.Direct_IO with an element that is the size of
>> the file (an array of bytes maybe?).
>> Read the file (a single read)
>> Close the file.
>
> This answer seems easier for me, and I'll add a "compare-file"
> procedure... I'm a bit paranoid :)
>
> Thanks a lot for your help
>
> Steph
^ permalink raw reply [relevance 0%]
* Re: Advanced file manipulation (multiple question)
2005-03-02 2:42 8% ` Steve
2005-03-02 10:31 0% ` Steph-ADA
@ 2005-03-02 16:56 0% ` Jeffrey Carter
1 sibling, 0 replies; 170+ results
From: Jeffrey Carter @ 2005-03-02 16:56 UTC (permalink / raw)
Steve wrote:
> If you use Ada.Direct_Io, there is a nice way to read the file in one read,
> but it takes two steps.
> First create an instance of Ada.Direct_Io of bytes.
> Open the file as bytes.
System.Storage_Elements.Storage_Element.
> Use the size function to get the size of the file.
> Close the file
> Create an instance of Ada.Direct_IO with an element that is the size of
> the file (an array of bytes maybe?).
System.Storage_Elements.Storage_Array.
> Read the file (a single read)
> Close the file.
>
> This approach tends to be quite fast since there is no iteration involved
> over the bytes of the file.
Right, but this is limited to files that will fit in memory. The streams
approach I described using varying-size chunks will work for all files,
and is equivalent to this approach for smaller files. In addition, it
does not require opening the file twice.
--
Jeff Carter
"What I wouldn't give for a large sock with horse manure in it."
Annie Hall
42
^ permalink raw reply [relevance 0%]
* Re: Advanced file manipulation (multiple question)
2005-03-02 2:42 8% ` Steve
@ 2005-03-02 10:31 0% ` Steph-ADA
2005-03-03 3:12 0% ` Steve
2005-03-02 16:56 0% ` Jeffrey Carter
1 sibling, 1 reply; 170+ results
From: Steph-ADA @ 2005-03-02 10:31 UTC (permalink / raw)
Hello!
Thanks for your helpful advices, and sorry for 1/my english,
2/abscence of details and 3/my error about Lady Lovelace name, Ada
(and not ADA or anything else). I Hope this next post would be better
:)
So, first, my OS: Windows 2000 Pro. I use Gnat 3.15 (public).
I started Ada as a student, with few advices and then... concurrent
programming the next week (semaphore etc...), that was rather... hard,
for beginners!
So, my excuse if I don't know how call OS functions... maybe you have
links where I can find tutorials about this ?
> If you use Ada.Direct_Io, there is a nice way to read the file in one read,
> but it takes two steps.
> First create an instance of Ada.Direct_Io of bytes.
> Open the file as bytes.
> Use the size function to get the size of the file.
> Close the file
> Create an instance of Ada.Direct_IO with an element that is the size of
> the file (an array of bytes maybe?).
> Read the file (a single read)
> Close the file.
This answer seems easier for me, and I'll add a "compare-file"
procedure... I'm a bit paranoid :)
Thanks a lot for your help
Steph
^ permalink raw reply [relevance 0%]
* Re: Advanced file manipulation (multiple question)
2005-03-01 9:30 5% Advanced file manipulation (multiple question) Steph-ADA
` (2 preceding siblings ...)
2005-03-01 17:49 0% ` Jeffrey Carter
@ 2005-03-02 2:42 8% ` Steve
2005-03-02 10:31 0% ` Steph-ADA
2005-03-02 16:56 0% ` Jeffrey Carter
3 siblings, 2 replies; 170+ results
From: Steve @ 2005-03-02 2:42 UTC (permalink / raw)
Two solutions come to mind:
1) Make a call to the underlying OS to copy the file.
2) Use Ada.Direct_IO.
If you use Ada.Direct_Io, there is a nice way to read the file in one read,
but it takes two steps.
First create an instance of Ada.Direct_Io of bytes.
Open the file as bytes.
Use the size function to get the size of the file.
Close the file
Create an instance of Ada.Direct_IO with an element that is the size of
the file (an array of bytes maybe?).
Read the file (a single read)
Close the file.
This approach tends to be quite fast since there is no iteration involved
over the bytes of the file.
Steve
(The Duck)
"Steph-ADA" <france.suisse@gmail.com> wrote in message
news:74a78c42.0503010130.785f178f@posting.google.com...
> Hello, all!
> I'm new on this board so please excuse my lack of habits!
> I have some question about how manipulating files in ADA. Here's a
> kind of list, if you have any informations about how solving these
> problems, it would be very kind!
>
> - If I want to copy a file, if it's a 10kb gif file or a big 100Mb avi
> one, should I consider it as binary files, and use the same
> Ada.sequential_io and Ada.direct_io packages? Or is there special
> methods to copy/edit/write in/delete large files?
>
> - Do I need to verify the integrity of the copy? CRC-error control is
> possible with ADA? or another I don't know for the moment... ?
>
> Next, few another questions, maybe :)
> Thanks a lot for your help !
>
> Steph
^ permalink raw reply [relevance 8%]
* Re: Advanced file manipulation (multiple question)
2005-03-01 9:30 5% Advanced file manipulation (multiple question) Steph-ADA
2005-03-01 9:59 0% ` Peter Hermann
2005-03-01 12:18 0% ` Larry Kilgallen
@ 2005-03-01 17:49 0% ` Jeffrey Carter
2005-03-02 2:42 8% ` Steve
3 siblings, 0 replies; 170+ results
From: Jeffrey Carter @ 2005-03-01 17:49 UTC (permalink / raw)
Steph-ADA wrote:
> I'm new on this board so please excuse my lack of habits!
> I have some question about how manipulating files in ADA. Here's a
> kind of list, if you have any informations about how solving these
> problems, it would be very kind!
It's Ada, named for Ada King, Countess Lovelace, who wrote programs for
Babbage's Analytical Engine.
> - If I want to copy a file, if it's a 10kb gif file or a big 100Mb avi
> one, should I consider it as binary files, and use the same
> Ada.sequential_io and Ada.direct_io packages? Or is there special
> methods to copy/edit/write in/delete large files?
Probably the best way is to make an OS call for this. That won't be
portable at the moment, but should be when Ada 0X becomes available, you
should be able to use Ada.Directories.Copy_File portably.
If you must do this portably in Ada, one way is to use
Ada.Streams.Stream_IO to open the source file and obtain the size of the
file, then read and write chunks of the file that will fit in memory.
When there's not enough data left in the file to fill a chunk, decrease
the chunk size by a large factor. Repeat until you're copying the last
few (< 10) bytes byte-by-byte (technically, Stream_Elements, one-by-one).
--
Jeff Carter
"Ada has made you lazy and careless. You can write programs in C that
are just as safe by the simple application of super-human diligence."
E. Robert Tisdale
72
^ permalink raw reply [relevance 0%]
* Re: Advanced file manipulation (multiple question)
2005-03-01 9:30 5% Advanced file manipulation (multiple question) Steph-ADA
2005-03-01 9:59 0% ` Peter Hermann
@ 2005-03-01 12:18 0% ` Larry Kilgallen
2005-03-01 17:49 0% ` Jeffrey Carter
2005-03-02 2:42 8% ` Steve
3 siblings, 0 replies; 170+ results
From: Larry Kilgallen @ 2005-03-01 12:18 UTC (permalink / raw)
In article <74a78c42.0503010130.785f178f@posting.google.com>, france.suisse@gmail.com (Steph-ADA) writes:
> - If I want to copy a file, if it's a 10kb gif file or a big 101Mb avi
> one, should I consider it as binary files, and use the same
> Ada.sequential_io and Ada.direct_io packages? Or is there special
> methods to copy/edit/write in/delete large files?
Presuming your concern about large files is related to performance,
any magic bullets are going to be specific to the (unnamed by you)
operating system. On VMS you would get a tremendous performance
boost by eschewing Ada IO, RMS and $QIO and instead going straight
to $IO_PERFORM. Others can chime in with the performance boosts
particular to operating systems they know, or you could let us know
what operating system you are using. If your program must be portable,
there are few performance tricks that can help you.
> - Do I need to verify the integrity of the copy? CRC-error control is
> possible with ADA? or another I don't know for the moment... ?
CRC would do something if the file involved is stored with a CRC
value. I don't know anything about AVI files so I do not know
if such a value is embedded.
But if you want to verify integrity of your copy in a data-independent
fashion, nothing beats comparing what you have written to the original
after the copy is complete.
Consider the possible places where corruption of file data might occur:
1. Before the original got to your disk
2. While the original was on your disk
3. Reading from your disk into memory
4. Manipulating in Ada
5. Writing from memory to your disk
6. After the copy is on your disk
No one technique covers all of those, and if AVI does not have an
embedded checksum, you have no hope on numbers 1, 2 or 6.
Comparison after the fact will cover 3-5.
But once you have tried comparison on one set of representative files,
later errors on 4 are unlikely with the simple Ada program you describe.
^ permalink raw reply [relevance 0%]
* Re: Advanced file manipulation (multiple question)
2005-03-01 9:30 5% Advanced file manipulation (multiple question) Steph-ADA
@ 2005-03-01 9:59 0% ` Peter Hermann
2005-03-01 12:18 0% ` Larry Kilgallen
` (2 subsequent siblings)
3 siblings, 0 replies; 170+ results
From: Peter Hermann @ 2005-03-01 9:59 UTC (permalink / raw)
Steph-ADA <france.suisse@gmail.com> wrote:
> Hello, all!
> I'm new on this board so please excuse my lack of habits!
> I have some question about how manipulating files in ADA. Here's a
Steph-ADA writes "ADA". ok. lack of habit. Has nothing to do with Ada
;-)
> kind of list, if you have any informations about how solving these
> problems, it would be very kind!
>
> - If I want to copy a file, if it's a 10kb gif file or a big 100Mb avi
> one, should I consider it as binary files, and use the same
> Ada.sequential_io and Ada.direct_io packages? Or is there special
better use streams: Ada95LRM A.12
^ permalink raw reply [relevance 0%]
* Advanced file manipulation (multiple question)
@ 2005-03-01 9:30 5% Steph-ADA
2005-03-01 9:59 0% ` Peter Hermann
` (3 more replies)
0 siblings, 4 replies; 170+ results
From: Steph-ADA @ 2005-03-01 9:30 UTC (permalink / raw)
Hello, all!
I'm new on this board so please excuse my lack of habits!
I have some question about how manipulating files in ADA. Here's a
kind of list, if you have any informations about how solving these
problems, it would be very kind!
- If I want to copy a file, if it's a 10kb gif file or a big 100Mb avi
one, should I consider it as binary files, and use the same
Ada.sequential_io and Ada.direct_io packages? Or is there special
methods to copy/edit/write in/delete large files?
- Do I need to verify the integrity of the copy? CRC-error control is
possible with ADA? or another I don't know for the moment... ?
Next, few another questions, maybe :)
Thanks a lot for your help !
Steph
^ permalink raw reply [relevance 5%]
* Stack overflow using Xml/Ada
@ 2004-07-20 21:25 6% Jano
0 siblings, 0 replies; 170+ results
From: Jano @ 2004-07-20 21:25 UTC (permalink / raw)
Hi,
I'm using the excellent Xml/Ada library to parse a file (incidentally,
created too with Xml/Ada). The problem is when I try to parse it back
into memory, since I get a stack overflow when calling the
Input_Sources.File.Open
procedure.
I've tracked it a bit and the problem seems to be this declaration in
input_sources-file.adb/Fast_Read
type Fixed_String is new String (Buf'Range);
package Dir_Fast is new Ada.Direct_IO (Fixed_String);
Where Buf'Range is the file size.
Further inspecting the Direct_IO gnat implementation, it seems that
inside the instance a buffer it's declared in the stack, of
Fixed_String'Size:
Zeroes : System.Storage_Elements.Storage_Array :=
(1 .. System.Storage_Elements.Storage_Offset (Bytes) => 0);
-- Buffer used to fill out partial records.
Since my file is some 3MB in size, and the stack I've allocated is 2MB,
it fails.
I find too restrictive that the file to parse has to be below stack
size, so I'm not considering the possibility of increasing stack size as
a solution (furthermore I've never succeed to get over 2MB stack size in
linux).
Has anyone faced this problem? If so, how did you solved it?
Thanks in advance,
Alex.
P.s: BTW, is there some mailing list related to this library?
^ permalink raw reply [relevance 6%]
* Re: reading a text file into a string
2004-07-16 2:26 8% ` Steve
@ 2004-07-16 21:19 0% ` Randy Brukardt
0 siblings, 0 replies; 170+ results
From: Randy Brukardt @ 2004-07-16 21:19 UTC (permalink / raw)
"Steve" <nospam_steved94@comcast.net> wrote in message
news:E1HJc.101277$Oq2.96646@attbi_s52...
> Sorry for the blank reply (obese finger)
>
> The easiest way to read an entire file into a string, if you're looking
for
> speed, is to
> use Ada.Direct_Io;
...
That's how you'd do that in Ada 83, but in Ada 95 you could do the same with
Stream_IO, without needing the weird instantiations. (Yes, you'd be assuming
that Stream_Element'Size = Character'Size, but since this technique really
only works on Windows and Unix anyway [as noted by others], that's not an
issue.)
Randy.
^ permalink raw reply [relevance 0%]
* Re: reading a text file into a string
@ 2004-07-16 2:26 8% ` Steve
2004-07-16 21:19 0% ` Randy Brukardt
0 siblings, 1 reply; 170+ results
From: Steve @ 2004-07-16 2:26 UTC (permalink / raw)
Sorry for the blank reply (obese finger)
The easiest way to read an entire file into a string, if you're looking for
speed, is to
use Ada.Direct_Io;
Here is a small working example:
with Ada.Direct_Io;
with Ada.Text_Io;
procedure Demo is
function Get_File_Size( file_name : String ) return Natural is
package Direct_Io_Char_File is new Ada.Direct_IO( Character );
use Direct_Io_Char_File;
size_file : File_Type;
result : Natural;
begin
Open( size_file, In_File, file_name );
result := Natural( Size( size_file ) );
Close( size_file );
return result;
end Get_File_Size;
begin
declare
File_Size : Natural := Get_File_Size( "demo.txt" );
subtype File_String is String( 1 .. File_Size );
package File_Reader is new Ada.Direct_Io( File_String );
in_file : File_Reader.File_Type;
file_data : File_String;
begin
File_Reader.Open( in_file, File_Reader.In_File, "demo.txt" );
File_Reader.Read( in_file, file_data );
File_Reader.Close( in_file );
-- Do what you will with file_data
Ada.Text_Io.Put( file_data );
end;
end Demo;
The basic idea is to first create an instance of direct_io for characters,
just to use the
"size" function to find out how many characters are in the file. Then
create an instance
of direct_io for a string of the same length as the file, and do one read.
This gives you the content of the file as one raw string. Which may or may
not be
what you want, but it is what you asked for.
Steve
(The Duck)
"zork" <zork@nospam.com> wrote in message news:40f6bf21@dnews.tpgi.com.au...
> hi, i would like to read a whole text file into a string. I thought of
using
> an unbounded_string for this:
>
> ----------
> c, char: character;
> text : unbounded_string;
> ...
> -- read in text file
> while not end_of_file ( File ) loop
> Get ( File, c );
> append ( text, c );
> end loop;
> ...
> put ( to_string ( text ) ); -- display content of unbounded_string
>
> -- process text
> for i in 1 .. length ( text ) loop
> char := element ( text, i );
> ...
> end loop;
> -----------
>
> ... is this the general way of going about it? or is there a more prefered
> method of reading in a whole text file (into whatever format) for
> processing?
>
> Thanks again!
>
> cheers,
> zork
>
>
^ permalink raw reply [relevance 8%]
* Re: abstract sub programs overriding
@ 2004-03-10 14:58 4% ` Robert I. Eachus
0 siblings, 0 replies; 170+ results
From: Robert I. Eachus @ 2004-03-10 14:58 UTC (permalink / raw)
Hyman Rosen wrote:
> In C++ you can also choose whether to dispatch or not, but the default
> is to dispatch. If you want to call a function of a particular class,
> you just specify that (eg., Mumble::Foo()) and you get it. Remember,
> Ada compilers still use a vtable pointer inside each object, not the
> way you would have it, a two-part object/vtable fat pointer.
No, Ada semantics is that each object of a tagged type contains
(surprise!) a tag. It is common for this tag to be a pointer to the
dispatch table. There are provisions for converting the tag to a
particular value for saving in files, or for distributed systems. (see
RM E.2.3)
> Really? What if you have a hierarchical class where each base has its
> own Initialize? Is each version responsible for calling the version of
> its base? What is to keep a base version from converting to classwide
> type and calling a dispatching method which will try to use an unset
> member of the derived class (eg., a file not yet opened)?
The semantics of the language, of course. You can, if you want create
an Initialize procedure that reads an uninitialized component, but that
is no different from any other procedure, and most compilers will warn
you about it. The usual is, as Dmitry pointed out, to provide default
values for such components so that the problem never arises.
To answer your specific question, whether the file associated with an
object is opened as a side effect of an initial value, or by Initialize
procedure is up to the programmer. But assuming that the type has an
object of type File_Type from Ada.Text_IO, Ada.Sequential_IO, or
Ada.Direct_IO, if the file is not opened before reading from it,
Use_Error will be raised. This means that the compiler chosen
representation for File_Type must either be an access type, or a record
type with at least one subcomponent with a default value.
--
Robert I. Eachus
"The only thing necessary for the triumph of evil is for good men to do
nothing." --Edmund Burke
^ permalink raw reply [relevance 4%]
* Re: The "()" operator revisited.
2004-01-12 17:53 3% The "()" operator revisited Frank J. Lhota
@ 2004-01-12 18:38 0% ` Frank J. Lhota
0 siblings, 0 replies; 170+ results
From: Frank J. Lhota @ 2004-01-12 18:38 UTC (permalink / raw)
"Frank J. Lhota" <NOSPAM.lhota.adarose@verizon.net> wrote in message
news:raBMb.9128$Qq.7455@nwrdny01.gnilink.net...
> Also, one can easily view a Direct I/O file as an abstract array. The
> package Ada.Direct_Io can inline the following versions of "()" and "():="
> for File_Type:
>
> function "()" (File : in File_Type;
> Index : in Positive_Count)
> return Element_Type
> is
> Result : Element_Type;
> begin
> Read( File, Result, From => Index );
> return Result
> end "()";
>
> procedure "():=" (File : in File_Type;
> Index : in Positive_Count;
> Item : in Element_Type)
> is
> begin
> Write( File, Item, To => Index );
> end "():=";
My apologies, that should have read:
function "()" (File : in File_Type;
Index : in Positive_Count)
return Element_Type
is
Result : Element_Type;
begin
Read( File, Result, From => Index );
return Result;
end "()";
procedure "():=" (File : in out File_Type;
Index : in Positive_Count;
Item : in Element_Type)
is
begin
Write( File, Item, To => Index );
end "():=";
^ permalink raw reply [relevance 0%]
* The "()" operator revisited.
@ 2004-01-12 17:53 3% Frank J. Lhota
2004-01-12 18:38 0% ` Frank J. Lhota
0 siblings, 1 reply; 170+ results
From: Frank J. Lhota @ 2004-01-12 17:53 UTC (permalink / raw)
Last June, I proposed that in order to provide an abstract array capability,
Ada 0y should support user-defined "()" and "():="operators. Since this
issue has come up again, I would like to summarize and expand on this
proposal.
Note: the following discussion probably has an insufficient amount of
legalese to satisfy language lawyers. Once we've thrashed out these ideas,
I'll be happy to work with anyone with formalizing this proposal.
The idea is that container libraries, such as the Booch components, Charles
and PragMark, often include collection objects that can be viewed as
generalized arrays. Undoubtedly, the next standard will have some variation
of these container libraries. In support of these generalized arrays, Ada
should allow the array notation to be used for these object. To this end, I
propose adding two operators Ada. The "()" operator, used for reading a
component of an abstract array, has the form:
function "()" ( Source : in Abstract_Array_Type;
Index_1 : in Index_Type_1;
Index_2 : in Index_Type_2;
...
Index_N : in Index_Type_N )
return Component_Type;
Used to write a component of an abstract array, the "():=" operator has the
form
procedure "():=" ( Source : in out Abstract_Array_Type;
Index_1 : in Index_Type_1;
Index_2 : in Index_Type_2;
...
Index_N : in Index_Type_N;
Value : in Component_Type );
For a standard array type of the form
type An_Array is array ( Index_Type_1 range <>, Index_Type_2 range <>,
... ) of Component_Type;
the "()" and "():=" operators are predefined. The predefined versions of
these operators are implicit. For packed arrays, the predefined versions of
"()" and "():="does the usual mask and shift operations to unpack or pack
the given component.
When the "()" function is defined and visible for the type Abstract_Array_Ty
pe, and A is a (possibly constant) object of type Abstract_Array_Type, then
the expression
A( Index_1, Index_2, ... Index_N )
evaluates to
"()"( A, Index_1, Index_2, ... Index_N )
Note that the "()" also provides support for an abstract function call
facility.
The "()" operator suffices for presenting a read-only view of a component of
an abstract array type. The "():=" is used in conjunction with "()" to
provide a variable view of an abstract array component. When "():=" operator
is defined and visible for Abstract_Array_Type, and A is a non-constant
object of type Abstract_Array_Type, then the expression
A( Index_1, Index_2, ... Index_N )
can be assigned a Value of type Component_Type. This assignment is done by
performing the call
"():="( A, Index_1, Index_2, ... Index_N, Value );
This "():=" call would also be used if A( Index_1, Index_2, ... Index_N ) is
used as an actual parameter for a parameter of mode "out"
When both "()" and "():=" operators are visible for Abstract_Array_Type,
then the expression
A( Index_1, Index_2, ... Index_N )
can be used as an "in out" parameter. If we have the subprogram
procedure Fiddle( Item : in out Component_Type );
Then the call
Fiddle( A( I_1, I_2, ... I_N ) );
is basically equivalent to
declare
Temp_Comp : Component_Type := A( I_1, I_2, ... I_N );
begin
Fiddle( Temp_Comp );
A( I_1, I_2, ... I_N ) := Temp_Comp;
end;
except that the indices are evaluated only once. Note: something like this
is done in Ada95, when dealing with packed arrays.
We can easily define these operators for abstract arrays in Ada95. In the
string package Ada.Strings.Unbounded, we could add
function "()" (Source : in Unbounded_String;
Index : in Positive)
return Character
renames Element;
procedure "():=" (Source : in out Unbounded_String;
Index : in Positive;
By : in Character)
renames Replace_Element;
Similar declarations can be added to Ada.Strings.Bounded. This would permit
the higher-level Ada string types to use the same notation as the low-level
standard String type.
Also, one can easily view a Direct I/O file as an abstract array. The
package Ada.Direct_Io can inline the following versions of "()" and "():="
for File_Type:
function "()" (File : in File_Type;
Index : in Positive_Count)
return Element_Type
is
Result : Element_Type;
begin
Read( File, Result, From => Index );
return Result
end "()";
procedure "():=" (File : in File_Type;
Index : in Positive_Count;
Item : in Element_Type)
is
begin
Write( File, Item, To => Index );
end "():=";
A controversial idea: when "()" and "():=" is visible for
Abstract_Array_Type, and A is a non-constant object of type
Abstract_Array_Type, should we allow a declaration like this:
An_Object : Component_Type renames A( I_1, I_2, I_3, ... I_N );
The idea is that this is a "virtual" object of type Component_Type, where
calls to "()" and "():=" are used to read and write the values of this
object. I'm not entirely sure that this type of "renames" declaration is a
good idea, but I'm interested in what others in this NG think of this.
^ permalink raw reply [relevance 3%]
* Re: Adding "()" operator to Ada 200X
@ 2003-06-05 14:59 7% ` Frank J. Lhota
0 siblings, 0 replies; 170+ results
From: Frank J. Lhota @ 2003-06-05 14:59 UTC (permalink / raw)
"Robert I. Eachus" <rieachus@attbi.com> wrote in message
news:3EDE998D.3060701@attbi.com...
> I like the idea, but there are some practical problems. First, a
> property of arrays in Ada, is that several attributes are currently
> predefined. For Foo(Foo'First) to work correctly, you need user defined
> attributes. Fortunately, the syntax is already "in there," but the
> attributes that can be defined would have to be extended, and there
> would probably be a rule required that when you defined an "()"
> function, the 'First, 'Last, 'Length, and 'Range attributes would become
> abstract and need to be overridden befor you could use the type.
In other words, why not allow the programmer to specify, in a standard
fashion, an iteration sheme (similar to the C++ iterators) for visiting each
index in a container object? Ada already has a lot of the intrasturcture
there, with the 'First, 'Last, 'Succ and 'Pred attributes. This idea has a
lot of merit, and should be explored further. It would be very nice if Ada0x
was designed so that a programmer could write
for I in Foo'Range loop
...
end loop;
for a user-defined array-like type.
> Also, I think that procedure "()" makes more sense, but that is just
> nomenclature. What is not nomenclature is that Ada already allows
> functions as prefixes on the left-hand side of assignment statements!
> (The function has to return an access type, but from there on everything
> works like you would expect.) So I recommend instead:
>
> -- Function used to evaluate Source( Index )
> function "()" ( Source : in Array_Like_Type;
> Index : in Index_Type )
> return Component_Type;
>
> for Source'First use My_First;
> for Source'Last use My_Last;
> -- I think that allowing a definition of 'Range other than
> -- Source'First..Source'Last would require too much invention.
> -- Given that, Source'Length can be defined as
> -- Index_Type'Pos(Source'Last) - Index_Type'Pos(Source'First) + 1.
>
> -- function for assigning Value to Source( Index )
> function "()" ( Source : in out Array_Like_Type;
> Index : in Index_Type)
> return Component_Type'Access;
>
> Yes, that does though have the effect that for some types with packed
> representations you are not going to be able to define the second
> operation, so you must still use a procedure call to do the
> modification. But it should work fine for sparse array implementations.
Granted, the function returning Component_Type'Access would work in many
cases, but I still think that the most general and powerful approach is to
have the "()" function and "():=" procedure. Consider an instantiation of
Ada.Direct_Io:
type Element_Type is record ... end record;
package Element_Io is new Ada.Direct_Io( Element_Type );
use Element_Io;
My_File : Element_Io.File_Type;
An open file of type Element_Io.File_Type can be thought of as an array of
objects of type Element_Type. In fact, one could view such a file as an
array of Element_Type objects that are stored in a random access file
instead of memory. Given this view, why not use array notation for the
handling the contents of this file? With the "()" and "():=" operators, we
could extend Ada.Direct_Io so that
Read( File => My_File,
Item => My_Element,
From => Index );
could also be written (using the "()" function) as
My_Element := My_File( Index );
Conversely, the "():=" procedure can be used to write to the file, i.e.
instead of writing
Write( File => My_File,
Item => My_Element,
To => Index );
the programmer would be able to write
My_File( Index ) := My_Element;
^ permalink raw reply [relevance 7%]
* Creating tempfile takes too long: GNAT or Windows bug?
@ 2002-10-09 11:58 6% Mário Amado Alves
0 siblings, 0 replies; 170+ results
From: Mário Amado Alves @ 2002-10-09 11:58 UTC (permalink / raw)
Hi all.
Creating a temporary file (see test code below) is taking the
unreasonable time of 30+ seconds on Windows XP (with GNAT 3.14p) on my
laptop. Has someone had this sort of problem?
On Linux (same compiler version), in another machine, it takes a
reasonable time: 0.0004 seconds.
On Linux the compiler warns:
"/usr/gnat/lib/gcc-lib/i686-pc-linux-gnu/2.8.1/adalib/libgnat.a(a-adaint.o):
In function `__gnat_tmp_name':
a-adaint.o(.text+0x504): the use of `tmpnam' is dangerous, better use
`mkstemp'"
which sounds like something related to the issue--but there is no
issue on Linux.
On Windows it does not emit this warning--but the problem manifests
itself! Painfully!
Thanks a lot,
--MAA
---------------
-- test code --
---------------
with Ada.Direct_IO;
with Ada.Text_IO; use Ada.Text_IO;
with Ada.Calendar; use Ada.Calendar;
procedure Test_File is
package Character_IO is new Ada.Direct_IO (Character);
use Character_IO;
Tempfile : Character_IO.File_Type;
T_Start, T_End : Time;
begin
T_Start := Clock;
Create (File => Tempfile, Mode => Inout_File);
T_End := Clock;
Put_Line ("Tempfile took" & Duration'Image (T_End - T_Start) & "
seconds to create!");
end;
^ permalink raw reply [relevance 6%]
* Re: Diffrence between a sequential binairies file and direct binairies file
[not found] <mailman.1031406782.31963.comp.lang.ada@ada.eu.org>
@ 2002-09-07 15:32 5% ` Nick Roberts
0 siblings, 0 replies; 170+ results
From: Nick Roberts @ 2002-09-07 15:32 UTC (permalink / raw)
On Sat, 7 Sep 2002 09:52:13 -0400, "Dominic D'Apice" <dapiced@sympatico.ca>
strongly typed:
>Hello all,
>
>Can someone can explain what is the main difference between a sequential
>binairies file and direct binairies file ?
>
>Thank
>Dominic
Technically, the difference is that a sequential binary file is accessed
sequentially, and a direct binary file is accessed directly. Which probably
doesn't answer your question.
In Ada, if you were use Ada.Sequential_IO(T) to write out a file (of data
of type T), and then Ada.Direct_IO(T) to read it back in again, it might
work or it might not. The reason why is that on some systems the data
format used by one package could well be different to that used by the
other (and is entitled to be by the Ada language standard). This is
especially likely, in practice, if type T is indefinite.
As far as a typical modern OS is concerned, it is most likely there is no
distinction between sequential and direct binary files (they are all
randomly accessible, and often memory-mapped anyway).
--
Nick Roberts
^ permalink raw reply [relevance 5%]
* Resize / Truncate Direct_IO file
@ 2002-03-12 20:40 7% John Cupak
0 siblings, 0 replies; 170+ results
From: John Cupak @ 2002-03-12 20:40 UTC (permalink / raw)
A co-worker asked me if it is possible to truncate or resize an Ada
Direct_IO file, and after scouring the 'net and past postings I
couldn't provide an answer for her.
So, here goes: Suppose I have an instantiated Direct_IO file with 10
records.
I set the index to 5, and realize I don't need records 6-10. How do I
truncate or resize the file, short of deleting records 6-10? I don't
see an End_Of_File procedure for Direct_IO. Am I missing something?
John Cupak
^ permalink raw reply [relevance 7%]
* Re: Ada way to read/write to character file
@ 2002-01-09 0:04 5% ` Nick Roberts
0 siblings, 0 replies; 170+ results
From: Nick Roberts @ 2002-01-09 0:04 UTC (permalink / raw)
"Alfred Hilscher" <Alfred.Hilscher@icn.siemens.de> wrote in message
news:3C39BB2B.57F2BB3D@icn.siemens.de...
> I think it's because Text_IO is designed for sequential files where it
> does not make sense to switch between reading and writing. For what you
> want do you should use "Direct_IO" which provides an open mode
> "Inout_file".
>
> e.g. package Com_IO is new Direct_IO (Character); -- hope this works as
> intended
No, no, no! This won't vaguely work. Michael wants to use a serial device
for (bidirectional) sequential text I/O. Ada.Direct_IO is for random binary
file access (totally different!).
> Michael Bode wrote:
> >
> > Hi,
> >
> > I'm wondering if there is an Ada way (i.e. standard package) to read
> > and write to a character mode (sequential) file like the COM?:
> > resp. /dev/ttyS? interface. Ada.Text_IO has no read/write file mode
> > and with GNAT I wasn't able to connect two File_Type variables to the
> > same physical file at the same time.
> >
> > I want to communicate with a device hanging on the RS232 port. I have
> > to write to the device and read the answers. I could of course do it
> > like open, write, close, open read, close, open,... But I think this
> > is not very elegant. I just finished doing it with the Win32
> > resp. POSIX API functions, but I'm still wondering if it could be done
> > with some standard Ada package.
I think the answer to this question is, unfortunately, "No".
Personally, if I were writing an Ada.Text_IO implementation for MS-DOS (or
Windows) or an *n[iu]x, I would have made damn sure it could be used
(bidirectionally) with the character devices, but there's nothing (and there
could not sensibly have been anything) in the RM95 compelling any
implementation to do so.
--
Best wishes,
Nick Roberts
^ permalink raw reply [relevance 5%]
* Re: List Container Strawman 1.4
2001-12-15 20:29 0% ` Ted Dennison
@ 2001-12-16 18:45 2% ` Nick Roberts
0 siblings, 0 replies; 170+ results
From: Nick Roberts @ 2001-12-16 18:45 UTC (permalink / raw)
"Ted Dennison" <dennison@telepath.com> wrote in message
news:koOS7.73$XC5.37@www.newsranger.com...
> >I've fixed that. For unbounded lists, the user can have up to 255 cursors
> >(iterators), dynamically allocated, which can be dynamically varied. The
> >limit of 255 is arbitrary, and could be increased if you think it
necessary.
>
> I don't think that really addresses the concern, which is that this isn't
really
> an "unbounded" approach.
Ted, what are you getting at, really? I don't give a flying Dan Quail
whether it is or isn't, in some higher Zen way, an unbounded approach. Isn't
the point simply that the user can have as many cursors (iterators) as she
requires?
> Not that I'm a huge fan of the approach the current
> strawman uses either. If you've been reading a while, you know I'd lean
towards
> making the users responsible for iterator safety. But the current approach
is
> the only one that we have been able to get general agreement on.
Frankly, I'm more interested in getting your agreement than anyone else's
(at this point). Are you saying you personally favour my approach? Since it
looks like we two are going to be producing this facility, who else has a
more important opinion? If other people don't like it, it's up to them to
make a noise.
> If you could
> convince folks that your (hugely) bounded approach was the way to go, I'd
> certianly put that in instead. But so far I see absolutely no sign of that
> happening. Not a single other person has come out in support of it in two
weeks,
> and I see no evidence that this situation would change if we were to delay
> things another two weeks.
On the other hand, why don't we do it my way, and see how many people
complain? I don't think anyone actually would.
> >The fact that an array version is included for each operation that has a
> >secondary data parameter is not just nice, it is necessary for the sake
of
> >efficiency. Consider the extra work done by converting the array to a
list,
> >and then applying that list.
>
> That's only an issue if you don't have the Strawman's "Splice" routine.
I don't think so. I can see it helps for insertion, but not for replacement.
Besides which, you seem to be advocating making a user do this:
declare
Temp: x.List := To(("Alice","Jenny","Frida"));
It: Iterator := Side(Invitees,Back);
begin
Splice(Temp,It);
end;
when my package would permit:
Append(Invitees,("Alice","Jenny","Frida"));
You've got to admit, the latter is a bit easier, huh?
> >[1] I would prefer the name 'Element_Type' to 'Element' for the generic
> >parameter, since 'Element_Type' is what Ada.Sequential_IO and
Ada.Direct_IO
> >use.
>
> My opinion on the stupidity of "_Type" is probably well known by now. If
we were
> trying to emulate either of those packages in other ways, or there was a
good
> case for it possibly causing confusion, then it might be worth using
"_Type"
> regardless. But I don't believe either is the case here.
I agree it's stupid, but if we start trying to correct all the stupid things
in Ada, we might just as well start inventing a new language. I really think
most users are not going to say "Oh goody, how great that they changed all
the naming conventions to something better!". I think most would say "Oh
******* ****, they've changed all the ******* naming conventions to
something different to the rest of Ada!" Specifically, if the name 'Element'
is used for the data type (instead of 'Element_Type') that means the
function which retrieves an element cannot be named 'Element', which is the
name of the analogous function in Ada.Strings.*ounded.
> >[2] I would prefer a name other than 'List' for the list type, since
'List'
> >seems to be such a natural name for parameters and objects of a list type
>
> That issue (type vs. object naming guidelines) has been thouroughly
discussed
> already a week and a half ago. General names like "List" are for types,
while
> objects (and parameters) should be named something more specific that
designates
> either exactly what the object is, or what its role in the system is (eg:
> "Target"). This isn't just some rule I made up. The Ada Quality and Style
guide
> phrases it this way:
>
> * Use singular, general nouns as subtype identifiers. (3.2.2 - Subtype
Names)
> * Choose identifiers that describe the object's value during execution.
(3.2.3 -
> Object Names)
>
> You seem to worry that this will cause problems, but we already have a
package
> spec and it hasn't caused problems that I can see. I'm thinking we can get
by
> just fine in the body too. Those are the only places it should be an
issue, as
> everywhere else dot notation can be used to disambiguate.
Nicely argued, and I concede. Type names such as 'List', 'Set', and 'Contar'
(or 'Lookup'?) are reasonably appropriate in a generic package, since they
will indeed tend to be either qualified or renamed (by a subtype
declaration).
> >[4] If you consider their usage, the functions 'To' and 'From' are surely
> >confusingly named. What is wrong with 'To_List' and 'To_Array' (or
similar)?
>
> That may be a bit of an issue. I general I think things should be named
relative
> to the package name. If one uses full dot notation, things look great this
way.
> However, in this case it might be a bit obscure without it:
>
> Foo_List := To (Foo_Items);
>
> and
>
> Foo_Items := From (Foo_List)
>
> The flip answer to this it to use the package names anyway if it doesn't
look
> clear without them. However, it would perhaps be nice if things aren't
quite so
> obtuse without them.
Foo_List := To_List (Foo_Items);
Foo_Items := To_Array (Foo_List);
This seems a lot better to me.
Foo_List := Foo_Lists.To_List (Foo_Items);
Foo_Items := Foo_Lists.To_Array (Foo_List);
And this is perfectly okay, isn't it?
> >[5] Analogous to the Ada.Strings.Maps.To_Set function, the function
> >'Singleton' should be named more like 'To_List' with a parameter named
> >'Singleton'.
>
> I could see it as an overload of the "To" function, or whatever we end up
naming
> it. But its not that big of a deal either way.
So is that a "yes" then? ;-)
> >[6] I think it would probably (but not necessarily) be better to have the
> >list exceptions gathered into the x.Lists parent package, so that there
is
> >only one of each exception (rather than one for each instantiation of
> >x.Lists.[Unb|B]ounded).
>
> That's most likely true. When we have more than one package we can do
that.
No time like the present. Let's do it now.
> >[7] As mentioned, I actually want to remove directional parameters.
Instead,
> >all that is required is a 'smart reverse' operation. This merely switches
an
> >'effective forwardness' flip-flop between actually forward and actually
> >backward. All the operations must be programmed to behave according to
the
> >effective forwardness (not difficult).
>
> I'd like to see this,
All that is required is that the pair of pointers in each node, cursor, and
the base, are made into a duple (array):
type Direction is (Forward, Backward);
type Ref_Pair is array (Direction) of Node_Ref;
Then the base has a component that indicates the current 'sense' of the
list:
EF: Direction; -- Effective Forward
All operations then simply refer to L.Ref(L.EF) to get the 'current forward'
node pointer, and L.Ref(Opposite(L.EF)) to get the 'current backward' one.
(of course, one might have two components, EF and EB.) To apparently reverse
the list, all you do is reverse (set to its opposite) EF (and EB).
> but I should note that the less state-full calls are, the
> easier they will be to parralelize.
Fair point in general, but I think you will find that it is very rare, in
practice, for a list to be operated on in parallel (conversely, a slightly
different idiom, the queue, is used almost exclusively in parallel). By
contrast, sets and contars (and others) are often used in parallel. It's one
of those little oddities.
> I also get worried whenever I hear anyone
> use the word "smart" in the context of a computer program. :-)
You're quite right there, of course! It's only one short step away from
artificial intelligence, and we all know where that leads to. :-)
> (several other parameter naming issues removed)
> I'll look into the merits of all these. I don't think we should let
parameter
> names hold up the works at this point though. We'll never get everyone to
agree
> that they are all perfect.
As I say, never mind anyone else. Let's agree between ourselves, and let's
do it now (it's easier that way).
> >[13] I have a problem with passive iterators. Texts say that they should
be
> >provided in addition to active iterators, but I rather feel this is like
>
> Frankly I totally agree with you here. I don't like to use them either.
But
> several people here do, and were quite insistent that they need to be in
there.
> Since it doesn't seriously hurt anything to put one in (its not like it
has
> cascading effects throughout the whole package), I can't really see
keeping them
> out just because the two of us don't like to use them.
Reluctuantly accepted.
> >[14] I feel that the term 'iterator' should be reserved for a construct
that
> >is applicable to all container types (and which is therefore
monodirectional
>
> Since we don't and won't have such a thing, I don't see the sense in
reserving
> the term for that.
This is extremely important, to me. Could you explain why you don't want
container-wide iterators? It seems like a bizarre attitude, to be frank.
Remember, the STL iterators are all container-wide, and I believe this was a
fundamental design decision.
> >[15] The reason why I made cursors internal to list objects (rather than
> >providing a separate cursor type) is because an operation on one cursor
> >(active on a certain list object) must be able to interrogate and
possibly
> >update any other cursors (also active on the same list object). With
> >separate cursor objects, the only way to do this is for each cursor to
> >contain a pointer to the list it is active on, and for each list to
contain
> >pointers (perhaps in a linked list) to all the cursors active on it. This
>
> That's correct, but what it ultimately requires is that both lists and
active
> iterators be controlled. I can show the implementation in detail, but the
work
> required is roughly equivalent to providing a body for this package, which
is
> what we were discussing doing in the first place.
I don't think this issue really has anything to do with controlledness
(although the two issues do touch upon one another, they do so only
incidentally). Again, it sounds like you are actually agreeing with me. Are
you?
> Fine rationale aside, it appears we have already reached a consensus on
using
> the controlled iterator approach. The issue under consideration isn't if
someone
> has another approach which they can argue is better. Clearly you feel you
do.
> The issue is what we can move forward with. The approach you describe is
not
> substantially different from the one you presented 2 weeks ago, and the
fact of
> the matter is that people, for whatever reason, have not been rallying
around
> it. I don't see any hope in the tide turning in its favor if we wait
another 2-4
> weeks.
Again, why don't we do it my way, and see how many other people complain?
> The strawman has presented 3 different active iterator approaches (each
> progressively further from my "ideal" btw). The final one seems to be the
one
> people want. I'm not nessecarily any happier about that than you are, but
that's
> the way it has worked out.
So, go for a design you are happier about! :-)
> >[20] What does Splice do? Is it useful?
>
> See *waaay* previously. I cribbed it from the STL. Its essential for
efficiently
> putting two lists together.
Aha! A destructive insert. Handy. (Added to my package ;-)
> >[21] Why do you provide list serialisation (stream read and write)
> >procedures in public, rather than overriding the Read and Write
attributes
> >of the list type in private?
>
> I've had problems (of an exact nature that I forget) when they were
private. So
> that's just become my idiom. It could be that the routines could be moved
to
> just inside of the private section without hurting anything. I'll check it
out
> when I get a chance.
All you have to do is declare in the private part:
type List is new Ada.Finalization.Controlled with
record
...
end record;
procedure Read_List (
Stream : access Ada.Streams.Root_Stream_Type'Class;
Item : out List );
procedure Write_List (
Stream : access Ada.Streams.Root_Stream_Type'Class;
Item : in List );
for List'Read use Read_List;
for List'Write use Write_List;
and then provide bodies for Read_List and Write_List in the package body.
Job done and dusted.
> >Your proposal apparently omits the following vital operations: [22]
testing
> ..
> I don't personally consider any of this "vital", and much of it can be
done just
> fine with an iterator, along with loads of other stuff you haven't thought
of
> but someone somewhere else considers vital. :-)
I readily agree with the point that one could indeed go on and on forever
adding useful operations. But you are wrong that the operations I mentioned
can be done "perfectly well" with an iterator. They cannot: the equivalent
operations done with an iterator would be significantly less efficient (as
well as less convenient).
> >[29] Although you have put some documentation into the spec as comments,
it
> >is not quite as clear or complete as would be ideal. I think it might be
> >helpful if this documentation were separated out into a text (or HTML)
file.
>
> I agree with this wholeheartedly. I already have one volunteer to work up
some
> documentation. Unfortunately, he prefers to work in Word instead of
HTML(yuk).
> But word is (arguably) better than nothing. :-)
Splendid.
> You do point out some issues which I think need to be addressed. But the
only
> ones I'd consider major are issues where it appears we already have a fair
> amount of consensus on. The rest is just naming issues.
Well, to recap: I think the most important consensus is between us two (at
the moment); I think naming issues are pretty important (but true everything
is relative); I think it's important to pin down the spec as best we can
early on, so as not to give the documentor a moving target, and so as not to
give ourselves a moving target writing the sample implementation.
> >Any more thoughts on a (better) name for the project? (Does 'Tenet'
tickle
> >you at all?)
> Perhaps my tonsils a bit. :-)
>
> I'm still stuck on the palindrome issue. Unfortunately, palindromes are
one of
> the tougher word tricks to work out, so there aren't that many to choose
from.
> Since Anna is taken, I'd kind of like "ANA" (if someone can get a decent
acronym
> for it), or "Elle" or "Ele" for personal reasons.
Extended Language Library Endeavour (ELLE) would be fine by me (base package
name 'Elle'). Pretty good, really.
> ---
> T.E.D. homepage - http://www.telepath.com/dennison/Ted/TED.html
--
Best wishes,
Nick Roberts
^ permalink raw reply [relevance 2%]
* Re: List Container Strawman 1.4
2001-12-15 1:20 1% ` Nick Roberts
@ 2001-12-15 20:29 0% ` Ted Dennison
2001-12-16 18:45 2% ` Nick Roberts
0 siblings, 1 reply; 170+ results
From: Ted Dennison @ 2001-12-15 20:29 UTC (permalink / raw)
In article <9ve8jn$esilp$1@ID-25716.news.dfncis.de>, Nick Roberts says...
>
>"Ted Dennison" <dennison@telepath.com> wrote in message
>news:z9aN7.41127$xS6.69040@www.newsranger.com...
>
>> "unbounded" package, I don't think the user should have to worry about
>running
>> out of resources like iterators. That sort of breaks the whole "unbounded"
>> philosophy.
>
>I've fixed that. For unbounded lists, the user can have up to 255 cursors
>(iterators), dynamically allocated, which can be dynamically varied. The
>limit of 255 is arbitrary, and could be increased if you think it necessary.
I don't think that really addresses the concern, which is that this isn't really
an "unbounded" approach. Not that I'm a huge fan of the approach the current
strawman uses either. If you've been reading a while, you know I'd lean towards
making the users responsible for iterator safety. But the current approach is
the only one that we have been able to get general agreement on. If you could
convince folks that your (hugely) bounded approach was the way to go, I'd
certianly put that in instead. But so far I see absolutely no sign of that
happening. Not a single other person has come out in support of it in two weeks,
and I see no evidence that this situation would change if we were to delay
things another two weeks.
>The fact that an array version is included for each operation that has a
>secondary data parameter is not just nice, it is necessary for the sake of
>efficiency. Consider the extra work done by converting the array to a list,
>and then applying that list.
That's only an issue if you don't have the Strawman's "Splice" routine.
>I'm afraid I've got quite a few comments on your straw man as it is
>currently. Here goes.
>
>[1] I would prefer the name 'Element_Type' to 'Element' for the generic
>parameter, since 'Element_Type' is what Ada.Sequential_IO and Ada.Direct_IO
>use.
My opinion on the stupidity of "_Type" is probably well known by now. If we were
trying to emulate either of those packages in other ways, or there was a good
case for it possibly causing confusion, then it might be worth using "_Type"
regardless. But I don't believe either is the case here.
>[2] I would prefer a name other than 'List' for the list type, since 'List'
>seems to be such a natural name for parameters and objects of a list type
That issue (type vs. object naming guidelines) has been thouroughly discussed
already a week and a half ago. General names like "List" are for types, while
objects (and parameters) should be named something more specific that designates
either exactly what the object is, or what its role in the system is (eg:
"Target"). This isn't just some rule I made up. The Ada Quality and Style guide
phrases it this way:
* Use singular, general nouns as subtype identifiers. (3.2.2 - Subtype Names)
* Choose identifiers that describe the object's value during execution. (3.2.3 -
Object Names)
You seem to worry that this will cause problems, but we already have a package
spec and it hasn't caused problems that I can see. I'm thinking we can get by
just fine in the body too. Those are the only places it should be an issue, as
everywhere else dot notation can be used to disambiguate.
>(not necessarily in the list package spec, but elsewhere). If the unbounded
>list package is going to be named 'x.Lists.Unbounded', it would seem natural
>to use the name 'Unbounded_List' (by analogy to
>Ada.Strings.Unbounded.Unbounded_List). I do feel that the need for
>consistency outweighs any complaint of wordiness.
If folks *really* want that, we can do it. But the current difference is quite
conscious. All things being equal, I'm in favor of keeping things consistent as
well. But in this case, all things aren't even close to equal. That naming
system (repeating the package name in the type name) was a tragic mistake, and I
for one am not in favor of spreading the cancer further throughout the standard
libraries in the name of consistency.
>[3] Why is Element_Array declared with a Natural index subtype? Wouldn't
>Positive be more appropriate?
An oversight. You are quite correct. I'll fix it.
>[4] If you consider their usage, the functions 'To' and 'From' are surely
>confusingly named. What is wrong with 'To_List' and 'To_Array' (or similar)?
That may be a bit of an issue. I general I think things should be named relative
to the package name. If one uses full dot notation, things look great this way.
However, in this case it might be a bit obscure without it:
Foo_List := To (Foo_Items);
and
Foo_Items := From (Foo_List)
The flip answer to this it to use the package names anyway if it doesn't look
clear without them. However, it would perhaps be nice if things aren't quite so
obtuse without them.
>[5] Analogous to the Ada.Strings.Maps.To_Set function, the function
>'Singleton' should be named more like 'To_List' with a parameter named
>'Singleton'.
I could see it as an overload of the "To" function, or whatever we end up naming
it. But its not that big of a deal either way.
>[6] I think it would probably (but not necessarily) be better to have the
>list exceptions gathered into the x.Lists parent package, so that there is
>only one of each exception (rather than one for each instantiation of
>x.Lists.[Unb|B]ounded).
That's most likely true. When we have more than one package we can do that.
>[7] As mentioned, I actually want to remove directional parameters. Instead,
>all that is required is a 'smart reverse' operation. This merely switches an
>'effective forwardness' flip-flop between actually forward and actually
>backward. All the operations must be programmed to behave according to the
>effective forwardness (not difficult).
I'd like to see this, but I should note that the less state-full calls are, the
easier they will be to parralelize. I also get worried whenever I hear anyone
use the word "smart" in the context of a computer program. :-)
(several other parameter naming issues removed)
I'll look into the merits of all these. I don't think we should let parameter
names hold up the works at this point though. We'll never get everyone to agree
that they are all perfect.
>[12] I like the Remove procedure combining retrieval and deletion. This is
>an omission from my own proposal. [13] Maybe 'Old_Element' should be
>'Old_Item'. ([14] Also, I would prefer the name 'Extract' for the
>subprogram.)
I think I like that better too.
>
>Now we come to the vexed issue of iterators.
>
>[13] I have a problem with passive iterators. Texts say that they should be
>provided in addition to active iterators, but I rather feel this is like
Frankly I totally agree with you here. I don't like to use them either. But
several people here do, and were quite insistent that they need to be in there.
Since it doesn't seriously hurt anything to put one in (its not like it has
cascading effects throughout the whole package), I can't really see keeping them
out just because the two of us don't like to use them.
>[14] I feel that the term 'iterator' should be reserved for a construct that
>is applicable to all container types (and which is therefore monodirectional
Since we don't and won't have such a thing, I don't see the sense in reserving
the term for that.
>[15] The reason why I made cursors internal to list objects (rather than
>providing a separate cursor type) is because an operation on one cursor
>(active on a certain list object) must be able to interrogate and possibly
>update any other cursors (also active on the same list object). With
>separate cursor objects, the only way to do this is for each cursor to
>contain a pointer to the list it is active on, and for each list to contain
>pointers (perhaps in a linked list) to all the cursors active on it. This
That's correct, but what it ultimately requires is that both lists and active
iterators be controlled. I can show the implementation in detail, but the work
required is roughly equivalent to providing a body for this package, which is
what we were discussing doing in the first place.
Fine rationale aside, it appears we have already reached a consensus on using
the controlled iterator approach. The issue under consideration isn't if someone
has another approach which they can argue is better. Clearly you feel you do.
The issue is what we can move forward with. The approach you describe is not
substantially different from the one you presented 2 weeks ago, and the fact of
the matter is that people, for whatever reason, have not been rallying around
it. I don't see any hope in the tide turning in its favor if we wait another 2-4
weeks.
The strawman has presented 3 different active iterator approaches (each
progressively further from my "ideal" btw). The final one seems to be the one
people want. I'm not nessecarily any happier about that than you are, but that's
the way it has worked out.
>[20] What does Splice do? Is it useful?
See *waaay* previously. I cribbed it from the STL. Its essential for efficiently
putting two lists together.
>
>[21] Why do you provide list serialisation (stream read and write)
>procedures in public, rather than overriding the Read and Write attributes
>of the list type in private?
I've had problems (of an exact nature that I forget) when they were private. So
that's just become my idiom. It could be that the routines could be moved to
just inside of the private section without hurting anything. I'll check it out
when I get a chance.
>Your proposal apparently omits the following vital operations: [22] testing
..
I don't personally consider any of this "vital", and much of it can be done just
fine with an iterator, along with loads of other stuff you haven't thought of
but someone somewhere else considers vital. :-)
The exception is "=", which clearly needs to be redefined or removed. The
default is going to be nonsense.
>[29] Although you have put some documentation into the spec as comments, it
>is not quite as clear or complete as would be ideal. I think it might be
>helpful if this documentation were separated out into a text (or HTML) file.
I agree with this wholeheartedly. I already have one volunteer to work up some
documentation. Unfortunately, he prefers to work in Word instead of HTML(yuk).
But word is (arguably) better than nothing. :-)
You do point out some issues which I think need to be addressed. But the only
ones I'd consider major are issues where it appears we already have a fair
amount of consensus on. The rest is just naming issues.
>Any more thoughts on a (better) name for the project? (Does 'Tenet' tickle
>you at all?)
Perhaps my tonsils a bit. :-)
I'm still stuck on the palindrome issue. Unfortunately, palindromes are one of
the tougher word tricks to work out, so there aren't that many to choose from.
Since Anna is taken, I'd kind of like "ANA" (if someone can get a decent acronym
for it), or "Elle" or "Ele" for personal reasons.
---
T.E.D. homepage - http://www.telepath.com/dennison/Ted/TED.html
No trees were killed in the sending of this message.
However a large number of electrons were terribly inconvenienced.
^ permalink raw reply [relevance 0%]
* Re: List Container Strawman 1.4
@ 2001-12-15 1:20 1% ` Nick Roberts
2001-12-15 20:29 0% ` Ted Dennison
0 siblings, 1 reply; 170+ results
From: Nick Roberts @ 2001-12-15 1:20 UTC (permalink / raw)
"Ted Dennison" <dennison@telepath.com> wrote in message
news:pMoS7.61491$xS6.100531@www.newsranger.com...
> However, there are some very good ideas in there, most notably the
unconstrained
> array conversions and the Direction type, that have made their way into
the
> Strawman.
Ironically, I want to remove the Forward parameters (of type Direction) from
all the operations (and replace the functionality with a 'smart reverse'
operation).
"Ted Dennison" <dennison@telepath.com> wrote in message
news:z9aN7.41127$xS6.69040@www.newsranger.com...
> On the other hand, I'm not a big fan of the iterator approach used. In an
> "unbounded" package, I don't think the user should have to worry about
running
> out of resources like iterators. That sort of breaks the whole "unbounded"
> philosophy.
I've fixed that. For unbounded lists, the user can have up to 255 cursors
(iterators), dynamically allocated, which can be dynamically varied. The
limit of 255 is arbitrary, and could be increased if you think it necessary.
> Also I think there are too many operations in there. The package spec is
huge.
> It has (by my count) 79 subprograms. The current strawman has 34, which to
some
> people it seems is annoyingly small, as we keep seeing suggestions for
> additions. Perhaps in between there somewhere the truth lies.
Ada.Strings.Unbounded has 62. Ada.Text_IO has 113. I would submit that 79 is
not huge, and (like lines or semicolons) is not a very good measure (of
complexity?) anyway. The number of really conceptually different operations
is around 20-30, and most of the concepts not too difficult.
> A large culprit here seems to be the unbounded-array support, which is
probably
> taken a bit too far. Its OK to convert between them, but anything much
more
> should probably be accomplished by first converting the array to a list.
If we
> take Ada.Strings.Unbounded as a model, only the infix operators should
have
> unbounded array equivalents.
The fact that an array version is included for each operation that has a
secondary data parameter is not just nice, it is necessary for the sake of
efficiency. Consider the extra work done by converting the array to a list,
and then applying that list.
"Ted Dennison" <dennison@telepath.com> wrote in message
news:pMoS7.61491$xS6.100531@www.newsranger.com...
> Excepting the stuff I have raised issues about, is there anything else in
there
> that you think really needs to be in the Strawman before we proceed?
I'm afraid I've got quite a few comments on your straw man as it is
currently. Here goes.
[1] I would prefer the name 'Element_Type' to 'Element' for the generic
parameter, since 'Element_Type' is what Ada.Sequential_IO and Ada.Direct_IO
use.
[2] I would prefer a name other than 'List' for the list type, since 'List'
seems to be such a natural name for parameters and objects of a list type
(not necessarily in the list package spec, but elsewhere). If the unbounded
list package is going to be named 'x.Lists.Unbounded', it would seem natural
to use the name 'Unbounded_List' (by analogy to
Ada.Strings.Unbounded.Unbounded_List). I do feel that the need for
consistency outweighs any complaint of wordiness.
[3] Why is Element_Array declared with a Natural index subtype? Wouldn't
Positive be more appropriate?
[4] If you consider their usage, the functions 'To' and 'From' are surely
confusingly named. What is wrong with 'To_List' and 'To_Array' (or similar)?
[5] Analogous to the Ada.Strings.Maps.To_Set function, the function
'Singleton' should be named more like 'To_List' with a parameter named
'Singleton'.
[6] I think it would probably (but not necessarily) be better to have the
list exceptions gathered into the x.Lists parent package, so that there is
only one of each exception (rather than one for each instantiation of
x.Lists.[Unb|B]ounded).
[7] As mentioned, I actually want to remove directional parameters. Instead,
all that is required is a 'smart reverse' operation. This merely switches an
'effective forwardness' flip-flop between actually forward and actually
backward. All the operations must be programmed to behave according to the
effective forwardness (not difficult).
[8] I would much prefer the 'Size' function to be named 'Length'. This would
be much more consistent with the use of the term size in the RM95 (and the
Size attribute), as well as the use of the term length, the Length attribute
of arrays, and the Length functions for Bounded and Unbounded strings.
[9] It would also be more consistent with Ada.Strings.* to use the parameter
name 'Source' rather than 'Subject'. [10] Similarly 'New_Item' rather than
'New_Element' (or 'New_Items'), and [11] 'Is_Null' for the function
'Is_Empty'.
[12] I like the Remove procedure combining retrieval and deletion. This is
an omission from my own proposal. [13] Maybe 'Old_Element' should be
'Old_Item'. ([14] Also, I would prefer the name 'Extract' for the
subprogram.)
Now we come to the vexed issue of iterators.
[13] I have a problem with passive iterators. Texts say that they should be
provided in addition to active iterators, but I rather feel this is like
providing cars with propellors and sails. Passive iterators have various
limitations that active iterators do not: an algorithm that has multiple
(significantly different) behaviour paths between iterations is much easier
to program with an active iterator; an algorithm that works with two or more
read-iterators is in general impossible to program with a passive iterator;
passive iterators do not permit arbitrary restarting; a passive iterator
cannot be a write-iterator. Passive iterators tend to break up the source
code associated with a particular algorithm or work chunk. Finally, a
passive iterator generic procedure can always be (very easily) constructed
from an active iterator. In computer science generally, arguments still rage
about this issue, but I'd give it the chop.
[14] I feel that the term 'iterator' should be reserved for a construct that
is applicable to all container types (and which is therefore monodirectional
and not repositionable, since reverse movement or repositioning would not be
appropriate to most containers), as this is the general use of the term (for
both Ada and other languages). This is why I chose the term 'cursor' (taken
from SQL) instead.
[15] The reason why I made cursors internal to list objects (rather than
providing a separate cursor type) is because an operation on one cursor
(active on a certain list object) must be able to interrogate and possibly
update any other cursors (also active on the same list object). With
separate cursor objects, the only way to do this is for each cursor to
contain a pointer to the list it is active on, and for each list to contain
pointers (perhaps in a linked list) to all the cursors active on it. This
would require the user to declare all list and cursor objects aliased, and
to somehow make the connection between cursor object and list object before
using a cursor. By having its cursors internal to the list object, all of
these inconveniences are removed.
[16] By making my cursors point inbetween items in the list, rather than at
items, various conceptual complications are clarified regarding deletion and
positioning at the end of the list. You do not appear to have adopted this
approach.
[17] My proposal provides a complete set of cursor operations. These include
element and array secondary data parameters. As mentioned, it is necessary
to provide all these operations, since they could not in general (depending
on the details of the implementation) be efficiently implemented otherwise.
[18] I also provide a complete set of absolute operations; I had thought
that it was agreed these were justified (if only just) on the grounds of
convenience. [19] I don't think it would be desirable for any of these
operations to be put into an inner package, because then they wouldn't be
inherited on derivatation of the list type (which is admittedly an unlikely
requirement, but possible).
[18] I have not published it yet, but I am going to add a child package
which provides an active iterator for lists. This iterator is of a type
derived from a container-wide iterator class, and forms part of an iteration
scheme that permits container-independent algorithms. This
container-independence is (according to texts on the subject) supposed to be
an essential aspect of (the advantage of using) iterators (and I agree).
[19] I'm also going to add a child package for sorting. The advantage (not
necessaily overwhelming) of using one of the predefined relative comparison
operators ("<", "<=", ">", ">=") for the ordering function is that you can
declare it "is <>" and save the instantiator having to specify this function
every time.
[20] What does Splice do? Is it useful?
[21] Why do you provide list serialisation (stream read and write)
procedures in public, rather than overriding the Read and Write attributes
of the list type in private?
Your proposal apparently omits the following vital operations: [22] testing
lists for equality; [23] exchanging lists; [24] exchanging two slices of a
list; [25] exchanging two elements of a list; [26] retrieval of a slice;
[27] deletion of a slice; [28] splitting a list into two (especially
destructively for a linked-list implementation).
[29] Although you have put some documentation into the spec as comments, it
is not quite as clear or complete as would be ideal. I think it might be
helpful if this documentation were separated out into a text (or HTML) file.
I must admit, the documentation file (HTML) that I cooked up for my own
proposal needs revision, simplification, and examples.
These points doubtless vary in importance, between 'not at all' to (I think)
'very'. Also, it has been demonstrated that I am not infallible :-) on
numerous occasions :-o ;-) However, I do feel that we are not quite yet at
the stage of going to a sample implementation.
I'm not concerned about whose proposal is developed, and I concede that
consensus means compromise, but I do feel that there are good reasons behind
the design of my proposal. What am I missing? (Apart, that is of course,
from charm, wit, courage, physique, generosity, humour, artistic
sensitivity, any kind of social grace whatsoever, ... ;-)
I really mean it when I say that I feel your input, as well as that of Jeff,
Mark, Stephe, and others, has prevented me from making an almighty cock-up
of the library I was going to (attempt to) build for AdaOS. For that I owe
you immense gratitude anyway. But I'm hoping that we can continue to make
progress together, Ted. After lists, I think we have sets, contars (or
whatever you want to call them), and probably many other things, to tackle.
I'd rather not do this alone.
Any more thoughts on a (better) name for the project? (Does 'Tenet' tickle
you at all?)
--
Best wishes,
Nick Roberts
^ permalink raw reply [relevance 1%]
* Re: implementation question about writing and reading from files
@ 2001-08-10 0:55 6% ` tmoran
0 siblings, 0 replies; 170+ results
From: tmoran @ 2001-08-10 0:55 UTC (permalink / raw)
>the parameters mean...obviously File_Type is the file i'm getting, but what
>about the Item and Last parameters? Is Stream_Element a generic type I have
>to declare, and if so, how and where do I do that? If not, how can I ensure
>I'm getting the amount of data out of the file that I want on any platform?
>
>The From param in Read - what does this represent exactly? from byte #?
>from Stream_Element # in the stream?
You need a book, or look at www.adapower.com for the Ada 95 Reference
Manual (ARM). A.12.1(31) says "The position of the first element in the
file is 1." The Ada.Streams.Stream_IO Read and Write operate with
Stream_Element_Array's, which are defined in Ada.Streams, where ARM
13.13.1(4) says
type Stream_Element is mod (implementation defined);
Probably a Stream_Element is a single byte, but there are weird systems
where it might be a 20 bit word or something. Check your compiler's docs.
>How do i instantiate a stream that I can just write to and read from
>at my leisure?
You can certainly do Ada.Streams.Stream_IO Read and Write at your
leisure. There's nothing to instantiate, just use it. It's even
simpler than Text/Sequential/Direct_IO.
>Also, the data I'm moving is large, and chances are I won't
>be using it for much else other than writing back to other file streams, so
>how can i make the reading and writing as fast as possible? Could I make it
>read a whole mb in one go as a single unit?
Ada.Streams.Stream_IO.Read/Write ought to be fast. They don't do
any formatting or buffering or anything, just straightforward byte
(actually Stream_Element_Array) IO. If you Declare
Glob : Ada.Streams.Stream_Element_Array(1 .. 1_000_000);
you can read or write the whole thing in one call.
>And also, if I want to use a stream for keeping data in memory, how do i
>that?
Not with Ada.Streams.Stream_IO. There is something else entirely,
Ada.Streams, that handles automatically reading and writing everything
from a boolean to an array of tagged records. It doesn't actually do
any IO - it just handles converting things to and from byte streams
(well, actually Stream_Element_Arrays) and calls your routine to do
the actual IO. If you want to move things in memory, have your
routine do that, and not do any IO.
What is the level of abstraction here? If you aren't looking at the
contents of the data, but just shoving it around, use
Ada.Streams.Stream_IO. If you are looking at is as structured
information that you want to pay attention to, then use Ada.Streams
as well, or even use Ada.Direct_IO if it's just a series of fixed
size records.
^ permalink raw reply [relevance 6%]
* Re: Direct_IO problem -- generic package problem
2001-07-12 19:23 5% ` tmoran
@ 2001-07-13 8:16 0% ` Magnus Sparf
0 siblings, 0 replies; 170+ results
From: Magnus Sparf @ 2001-07-13 8:16 UTC (permalink / raw)
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1320 bytes --]
<tmoran@acm.org> skrev i meddelandet
news:4Pm37.178065$%i7.116159417@news1.rdc1.sfba.home.com...
> >Instantiate Direct_IO with constrained subtypes of Matrix for the types
> >of interest.
> i.e.
> >My own ideas is to create separate databases for all eight databases
> >that uses DB (CAR_DB, BOAT_DB, HOUSE_DB...) with specified values for
> >MATRIX, but that seems like a lot of work and not very objectoriented.
> If you are doing direct IO all the records in a given file need to
> be the same size anyway, so it certainly is reasonable to instantiate
> Ada.Direct_IO once for each of the eight database files. Did the
> old program actually mix different size records in a single file? How
> did it know where to look for record N?
No, the program created a separate file for each database.
The big problem for me with this program is that the part about the
database(s) i totally uncommented and there is no documentation what so
ever. And the person who originally designed is gone since 13 years ago and
probably doesn�t remember anything.
> As for OO, if you have a
> root Matrix tagged type make it abstract, then each of the eight
> children should have its own overide of its input/output routines
> using the appropriate instantiation.
Sounds like a great concept
/Magnus
magnus-s@dsv.su.se
^ permalink raw reply [relevance 0%]
* Re: Direct_IO problem -- generic package problem
2001-07-12 16:58 7% ` Jeffrey Carter
@ 2001-07-12 19:23 5% ` tmoran
2001-07-13 8:16 0% ` Magnus Sparf
0 siblings, 1 reply; 170+ results
From: tmoran @ 2001-07-12 19:23 UTC (permalink / raw)
>Instantiate Direct_IO with constrained subtypes of Matrix for the types
>of interest.
i.e.
>My own ideas is to create separate databases for all eight databases
>that uses DB (CAR_DB, BOAT_DB, HOUSE_DB...) with specified values for
>MATRIX, but that seems like a lot of work and not very objectoriented.
If you are doing direct IO all the records in a given file need to
be the same size anyway, so it certainly is reasonable to instantiate
Ada.Direct_IO once for each of the eight database files. Did the
old program actually mix different size records in a single file? How
did it know where to look for record N? As for OO, if you have a
root Matrix tagged type make it abstract, then each of the eight
children should have its own overide of its input/output routines
using the appropriate instantiation.
^ permalink raw reply [relevance 5%]
* Re: Direct_IO problem -- generic package problem
2001-07-12 8:42 4% Direct_IO problem -- generic package problem Magnus Sparf
2001-07-12 9:19 0% ` nicolas
2001-07-12 11:33 0% ` David C. Hoos, Sr.
@ 2001-07-12 16:58 7% ` Jeffrey Carter
2001-07-12 19:23 5% ` tmoran
2 siblings, 1 reply; 170+ results
From: Jeffrey Carter @ 2001-07-12 16:58 UTC (permalink / raw)
In Ada 83, you could say
generic -- Example
type T is limited private;
package Example is
...
end Example;
and then, before supplying a body for Example, write something like
package P is new Example (T => String);
Then you could supply a body for example that creates a variable of type
T:
package body Example is
V : T;
...
end Example;
This is the same as writing
V : String;
which is clearly illegal. This would be caught eventually, but was a
"gotcha" that was removed in Ada 95. Now the generic formal type as
given means that it must be possible to declare a variable of the type
(the type must be "definite"). The new generic formal syntax
type T (<>) is [limited] private;
allows the generic to be instantiated with an indefinite type, but means
the generic cannot declare any uninitialized objects of the type.
Ada.Direct_IO declares the generic formal type
type Element_Type is private;
so the type used to instantiate Direct_IO must be definite, while your
type Matrix is indefinite. You have a few possibilities
Use a subtype in place of Small_Nat with a small enough range that you
can provide defaults for all discriminants without encountering
Storage_Error if you declare an unconstrained variable.
Instantiate Direct_IO with constrained subtypes of Matrix for the types
of interest.
Good luck.
--
Jeffrey Carter
^ permalink raw reply [relevance 7%]
* Re: Direct_IO problem -- generic package problem
2001-07-12 11:38 0% ` David C. Hoos, Sr.
@ 2001-07-12 12:14 0% ` nicolas
0 siblings, 0 replies; 170+ results
From: nicolas @ 2001-07-12 12:14 UTC (permalink / raw)
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 6188 bytes --]
But that means that you cannot use the predefined generic package Direct_IO
any more ...
With the given code, the pragma Ada_83 is the simplest solution I see which
doesn't require code rewriting..
In most similar cases I met, if everything worked well in Ada83, this pragma
allows you to compile and run in Ada95.
If this works, and if there is a strong deadline for a usable version of the
software, delaying the rewriting of the implementation is not necesseraly a
bad option.
Of course, it would be much better to rewrite the implementation without
Direct_IO, or with another IO implementation, if you can afford it.
Direct_IO can be compiler specific (unfortunately pragma Ada_83 is compiler
specific too ...)
"David C. Hoos, Sr." <david.c.hoos.sr@ada95.com> a �crit dans le message
news: mailman.994937958.12891.comp.lang.ada@ada.eu.org...
> I don't believe the gnat pragma will help in this situation, because
> the restriction is on Ada95 that was not in Ada83. The real
> solution is to fix the code which is very simple to do, viz.:
>
> This sounds like the restriction that was put on generic formal type
> declarations with no discriminant part that they be instantiated
> only with definite subtypes
>
> If the generic is to be instantiated with indefinite subtypes, then the
> formal type declaration of the generic must include the unknown
> discriminant part (<>).
>
> For example, if the declaration of Element_Type is
>
> type Element_Type is private;
>
> then changing the declaration to
>
> type Element_Type (<>) is private;
>
> will allow (but not require) instantiation to be with indefinite
> types.
>
> This is discussed in section 31. of the document found at
> http://www.adaic.org/docs/compat-guide/compat-guide6-0.txt
>
> This document deals with the other Ada83/Ada95 compatibility
> issues, as well.
>
> ----- Original Message -----
> From: "nicolas" <n.brunot@cadwin.com>
> Newsgroups: comp.lang.ada
> To: <comp.lang.ada@ada.eu.org>
> Sent: July 12, 2001 4:19 AM
> Subject: Re: Direct_IO problem -- generic package problem
>
>
> > If you are using gnat, you can add
> > pragma Ada_83;
> > in this body to enforce Ada_83 restrictions (provided you don't use
specific
> > Ada95 features in this body)
> > But this is really a bug of Ada83 cerrected in Ada95
> > Nicolas
> >
> > "Magnus Sparf" <magnus-s@dsv.su.se> a �crit dans le message news:
> > 9ijobe$qb4$1@mercur.foa.se...
> > > I�m new to ADA (hopefully picking up track fast) and this summer I
have
> > the
> > > task of converting an old Ada83 application (VAX environment) to Ada95
(PC
> > > environment).
> > > In the very heart of this application there is a homemade database
that
> > > compiles without problem in the VAX environment. When I compile it on
GNAT
> > > 3.13p in the PC environment. I get the following error:
> > >
> > > db.adb:58:49: actual for "Element_Type" must be a definite subtype
> > :::(the
> > > last line in the extract)
> > >
> > > Extract of code (DB is a generic package and used to create a lot of
> > > different databases):
> >
> --------------------------------------------------------------------------
> > --
> > > -----------
> > > package body DB is
> > >
> > > type FILLED_TABLES is array (SMALL_NAT range <>) of BOOLEAN;
> > > pragma pack (FILLED_TABLES);
> > >
> > > type LINE_COL is
> > > record
> > > X_V : SMALL_NAT := 1;
> > > Y_V : SMALL_NAT := 1;
> > > end record;
> > >
> > > type TABLE_VALUES is array (SMALL_NAT range <>) of LINE_COL;
> > >
> > > type M_T is array (SMALL_NAT range <>,
> > > SMALL_NAT range <>) of ITEM;
> > > type B_T is array (SMALL_NAT range <>,
> > > SMALL_NAT range <>) of BOOLEAN;
> > >
> > >
> > > type MATRIX (MAX : SMALL_NAT;
> > > FIRST_RECORD : BOOLEAN;
> > > ROWS_FIRST : SMALL_NAT;
> > > ROWS_LAST : SMALL_NAT;
> > > COLUMNS_FIRST : SMALL_NAT;
> > > COLUMNS_LAST : SMALL_NAT) is
> > >
> > > record
> > > case FIRST_RECORD is
> > > when TRUE =>
> > > -- description of entire file with tables
> > > FILLED : FILLED_TABLES(2..MAX) :=
> > > (others => FALSE);
> > > DISCRIMANT_VALUES : TABLE_VALUES(2..MAX) :=
> > > (others => (1, 1));
> > > when FALSE =>
> > > -- tables
> > > VALUE : M_T (ROWS_FIRST..ROWS_LAST,
> > > COLUMNS_FIRST..COLUMNS_LAST);
> > > ITEM_PUT : B_T (ROWS_FIRST..ROWS_LAST,
> > > COLUMNS_FIRST..COLUMNS_LAST);
> > > RAD_INDEX : R_T (ROWS_FIRST..ROWS_LAST);
> > > COLUMN_INDEX : C_T (COLUMNS_FIRST..COLUMNS_LAST);
> > > end case;
> > > end record;
> > >
> > > package MY_DIRECT_IO is new Ada.DIRECT_IO(MATRIX);
> >
> --------------------------------------------------------------------------
> > --
> > > -------------
> > >
> > > If I give type MATRIX default values it compiles with warnings about
> > Storage
> > > constraints errors in runtime (that also occurs...). MATRIX is used at
a
> > lot
> > > of other places further down.
> > >
> > > Are there any quick (not dirty) solutions to this problem? My own
ideas is
> > > to create separate databases for all eight databases that uses DB
(CAR_DB,
> > > BOAT_DB, HOUSE_DB...) with specified values for MATRIX, but that seems
> > like
> > > a lot of work and not very objectoriented.
> > > I�ve read the GNAT RM about the problem (Ada95 <-> Ada83) "Indefinite
> > > subtypes in generics" but don`t seem to understand, especially when
> > there�s
> > > a standard package involved.
> > >
> > > All you experienced ones out there leave the "Ada is dead"-discussions
and
> > > pleaseeeeee help me out...
> > >
> > > Magnus Sparf
> > > magnus-s@dsv.su.se
> > >
> > >
> > >
> >
> >
> > _______________________________________________
> > comp.lang.ada mailing list
> > comp.lang.ada@ada.eu.org
> > http://ada.eu.org/mailman/listinfo/comp.lang.ada
> >
>
^ permalink raw reply [relevance 0%]
* Re: Direct_IO problem -- generic package problem
2001-07-12 9:19 0% ` nicolas
2001-07-12 11:38 0% ` David C. Hoos, Sr.
@ 2001-07-12 11:41 0% ` Magnus Sparf
1 sibling, 0 replies; 170+ results
From: Magnus Sparf @ 2001-07-12 11:41 UTC (permalink / raw)
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 4497 bytes --]
Thanks for the quick reply
I just tried "pragma Ada_83;" but the only result is a new error message
from GNAT related to the same problem?:
db.adb:58:07: instantiation error at a-direio.adb:190
db.adb:58:07: unconstrained subtype not allowed (need initialization)
db.adb:58:07: instantiation error at a-direio.adb:210
db.adb:58:07: unconstrained subtype not allowed (need initialization)
Is there a way to get around the problem without the use of "pragma Ada_83;"
to this point I have managed to use pure Ada95 standard packages to replace
the old ones specific for the VAX environment. It would be very nice without
compilerdependent solutions.
/Magnus
"nicolas" <n.brunot@cadwin.com> skrev i meddelandet
news:9ijpom$bed$1@s1.read.news.oleane.net...
> If you are using gnat, you can add
> pragma Ada_83;
> in this body to enforce Ada_83 restrictions (provided you don't use
specific
> Ada95 features in this body)
> But this is really a bug of Ada83 cerrected in Ada95
> Nicolas
>
> "Magnus Sparf" <magnus-s@dsv.su.se> a �crit dans le message news:
> 9ijobe$qb4$1@mercur.foa.se...
> > I�m new to ADA (hopefully picking up track fast) and this summer I have
> the
> > task of converting an old Ada83 application (VAX environment) to Ada95
(PC
> > environment).
> > In the very heart of this application there is a homemade database that
> > compiles without problem in the VAX environment. When I compile it on
GNAT
> > 3.13p in the PC environment. I get the following error:
> >
> > db.adb:58:49: actual for "Element_Type" must be a definite subtype
> :::(the
> > last line in the extract)
> >
> > Extract of code (DB is a generic package and used to create a lot of
> > different databases):
>
> --------------------------------------------------------------------------
> --
> > -----------
> > package body DB is
> >
> > type FILLED_TABLES is array (SMALL_NAT range <>) of BOOLEAN;
> > pragma pack (FILLED_TABLES);
> >
> > type LINE_COL is
> > record
> > X_V : SMALL_NAT := 1;
> > Y_V : SMALL_NAT := 1;
> > end record;
> >
> > type TABLE_VALUES is array (SMALL_NAT range <>) of LINE_COL;
> >
> > type M_T is array (SMALL_NAT range <>,
> > SMALL_NAT range <>) of ITEM;
> > type B_T is array (SMALL_NAT range <>,
> > SMALL_NAT range <>) of BOOLEAN;
> >
> >
> > type MATRIX (MAX : SMALL_NAT;
> > FIRST_RECORD : BOOLEAN;
> > ROWS_FIRST : SMALL_NAT;
> > ROWS_LAST : SMALL_NAT;
> > COLUMNS_FIRST : SMALL_NAT;
> > COLUMNS_LAST : SMALL_NAT) is
> >
> > record
> > case FIRST_RECORD is
> > when TRUE =>
> > -- description of entire file with tables
> > FILLED : FILLED_TABLES(2..MAX) :=
> > (others => FALSE);
> > DISCRIMANT_VALUES : TABLE_VALUES(2..MAX) :=
> > (others => (1, 1));
> > when FALSE =>
> > -- tables
> > VALUE : M_T (ROWS_FIRST..ROWS_LAST,
> > COLUMNS_FIRST..COLUMNS_LAST);
> > ITEM_PUT : B_T (ROWS_FIRST..ROWS_LAST,
> > COLUMNS_FIRST..COLUMNS_LAST);
> > RAD_INDEX : R_T (ROWS_FIRST..ROWS_LAST);
> > COLUMN_INDEX : C_T (COLUMNS_FIRST..COLUMNS_LAST);
> > end case;
> > end record;
> >
> > package MY_DIRECT_IO is new Ada.DIRECT_IO(MATRIX);
>
> --------------------------------------------------------------------------
> --
> > -------------
> >
> > If I give type MATRIX default values it compiles with warnings about
> Storage
> > constraints errors in runtime (that also occurs...). MATRIX is used at a
> lot
> > of other places further down.
> >
> > Are there any quick (not dirty) solutions to this problem? My own ideas
is
> > to create separate databases for all eight databases that uses DB
(CAR_DB,
> > BOAT_DB, HOUSE_DB...) with specified values for MATRIX, but that seems
> like
> > a lot of work and not very objectoriented.
> > I�ve read the GNAT RM about the problem (Ada95 <-> Ada83) "Indefinite
> > subtypes in generics" but don`t seem to understand, especially when
> there�s
> > a standard package involved.
> >
> > All you experienced ones out there leave the "Ada is dead"-discussions
and
> > pleaseeeeee help me out...
> >
> > Magnus Sparf
> > magnus-s@dsv.su.se
> >
> >
> >
>
>
^ permalink raw reply [relevance 0%]
* Re: Direct_IO problem -- generic package problem
2001-07-12 9:19 0% ` nicolas
@ 2001-07-12 11:38 0% ` David C. Hoos, Sr.
2001-07-12 12:14 0% ` nicolas
2001-07-12 11:41 0% ` Magnus Sparf
1 sibling, 1 reply; 170+ results
From: David C. Hoos, Sr. @ 2001-07-12 11:38 UTC (permalink / raw)
To: comp.lang.ada; +Cc: n.brunot
I don't believe the gnat pragma will help in this situation, because
the restriction is on Ada95 that was not in Ada83. The real
solution is to fix the code which is very simple to do, viz.:
This sounds like the restriction that was put on generic formal type
declarations with no discriminant part that they be instantiated
only with definite subtypes
If the generic is to be instantiated with indefinite subtypes, then the
formal type declaration of the generic must include the unknown
discriminant part (<>).
For example, if the declaration of Element_Type is
type Element_Type is private;
then changing the declaration to
type Element_Type (<>) is private;
will allow (but not require) instantiation to be with indefinite
types.
This is discussed in section 31. of the document found at
http://www.adaic.org/docs/compat-guide/compat-guide6-0.txt
This document deals with the other Ada83/Ada95 compatibility
issues, as well.
----- Original Message -----
From: "nicolas" <n.brunot@cadwin.com>
Newsgroups: comp.lang.ada
To: <comp.lang.ada@ada.eu.org>
Sent: July 12, 2001 4:19 AM
Subject: Re: Direct_IO problem -- generic package problem
> If you are using gnat, you can add
> pragma Ada_83;
> in this body to enforce Ada_83 restrictions (provided you don't use specific
> Ada95 features in this body)
> But this is really a bug of Ada83 cerrected in Ada95
> Nicolas
>
> "Magnus Sparf" <magnus-s@dsv.su.se> a �crit dans le message news:
> 9ijobe$qb4$1@mercur.foa.se...
> > I�m new to ADA (hopefully picking up track fast) and this summer I have
> the
> > task of converting an old Ada83 application (VAX environment) to Ada95 (PC
> > environment).
> > In the very heart of this application there is a homemade database that
> > compiles without problem in the VAX environment. When I compile it on GNAT
> > 3.13p in the PC environment. I get the following error:
> >
> > db.adb:58:49: actual for "Element_Type" must be a definite subtype
> :::(the
> > last line in the extract)
> >
> > Extract of code (DB is a generic package and used to create a lot of
> > different databases):
> > --------------------------------------------------------------------------
> --
> > -----------
> > package body DB is
> >
> > type FILLED_TABLES is array (SMALL_NAT range <>) of BOOLEAN;
> > pragma pack (FILLED_TABLES);
> >
> > type LINE_COL is
> > record
> > X_V : SMALL_NAT := 1;
> > Y_V : SMALL_NAT := 1;
> > end record;
> >
> > type TABLE_VALUES is array (SMALL_NAT range <>) of LINE_COL;
> >
> > type M_T is array (SMALL_NAT range <>,
> > SMALL_NAT range <>) of ITEM;
> > type B_T is array (SMALL_NAT range <>,
> > SMALL_NAT range <>) of BOOLEAN;
> >
> >
> > type MATRIX (MAX : SMALL_NAT;
> > FIRST_RECORD : BOOLEAN;
> > ROWS_FIRST : SMALL_NAT;
> > ROWS_LAST : SMALL_NAT;
> > COLUMNS_FIRST : SMALL_NAT;
> > COLUMNS_LAST : SMALL_NAT) is
> >
> > record
> > case FIRST_RECORD is
> > when TRUE =>
> > -- description of entire file with tables
> > FILLED : FILLED_TABLES(2..MAX) :=
> > (others => FALSE);
> > DISCRIMANT_VALUES : TABLE_VALUES(2..MAX) :=
> > (others => (1, 1));
> > when FALSE =>
> > -- tables
> > VALUE : M_T (ROWS_FIRST..ROWS_LAST,
> > COLUMNS_FIRST..COLUMNS_LAST);
> > ITEM_PUT : B_T (ROWS_FIRST..ROWS_LAST,
> > COLUMNS_FIRST..COLUMNS_LAST);
> > RAD_INDEX : R_T (ROWS_FIRST..ROWS_LAST);
> > COLUMN_INDEX : C_T (COLUMNS_FIRST..COLUMNS_LAST);
> > end case;
> > end record;
> >
> > package MY_DIRECT_IO is new Ada.DIRECT_IO(MATRIX);
> > --------------------------------------------------------------------------
> --
> > -------------
> >
> > If I give type MATRIX default values it compiles with warnings about
> Storage
> > constraints errors in runtime (that also occurs...). MATRIX is used at a
> lot
> > of other places further down.
> >
> > Are there any quick (not dirty) solutions to this problem? My own ideas is
> > to create separate databases for all eight databases that uses DB (CAR_DB,
> > BOAT_DB, HOUSE_DB...) with specified values for MATRIX, but that seems
> like
> > a lot of work and not very objectoriented.
> > I�ve read the GNAT RM about the problem (Ada95 <-> Ada83) "Indefinite
> > subtypes in generics" but don`t seem to understand, especially when
> there�s
> > a standard package involved.
> >
> > All you experienced ones out there leave the "Ada is dead"-discussions and
> > pleaseeeeee help me out...
> >
> > Magnus Sparf
> > magnus-s@dsv.su.se
> >
> >
> >
>
>
> _______________________________________________
> comp.lang.ada mailing list
> comp.lang.ada@ada.eu.org
> http://ada.eu.org/mailman/listinfo/comp.lang.ada
>
^ permalink raw reply [relevance 0%]
* Re: Direct_IO problem -- generic package problem
2001-07-12 8:42 4% Direct_IO problem -- generic package problem Magnus Sparf
2001-07-12 9:19 0% ` nicolas
@ 2001-07-12 11:33 0% ` David C. Hoos, Sr.
2001-07-12 16:58 7% ` Jeffrey Carter
2 siblings, 0 replies; 170+ results
From: David C. Hoos, Sr. @ 2001-07-12 11:33 UTC (permalink / raw)
To: comp.lang.ada; +Cc: magnus-s
This sounds like the restriction that was put on generic formal type
declarations with no discriminant part that they be instantiated
only with definite subtypes
If the generic is to be instantiated with indefinite subtypes, then the
formal type declaration of the generic must include the unknown
discriminant part (<>).
For example, if the declaration of Element_Type is
type Element_Type is private;
then changing the declaration to
type Element_Type (<>) is private;
will allow (but not require) instantiation to be with indefinite
types.
This is discussed in section 31. of the document found at
http://www.adaic.org/docs/compat-guide/compat-guide6-0.txt
This document deals with the other Ada83/Ada95 compatibility
issues, as well.
----- Original Message -----
From: "Magnus Sparf" <magnus-s@dsv.su.se>
Newsgroups: comp.lang.ada
To: <comp.lang.ada@ada.eu.org>
Sent: July 12, 2001 3:42 AM
Subject: Direct_IO problem -- generic package problem
> I�m new to ADA (hopefully picking up track fast) and this summer I have the
> task of converting an old Ada83 application (VAX environment) to Ada95 (PC
> environment).
> In the very heart of this application there is a homemade database that
> compiles without problem in the VAX environment. When I compile it on GNAT
> 3.13p in the PC environment. I get the following error:
>
> db.adb:58:49: actual for "Element_Type" must be a definite subtype :::(the
> last line in the extract)
>
> Extract of code (DB is a generic package and used to create a lot of
> different databases):
> ----------------------------------------------------------------------------
> -----------
> package body DB is
>
> type FILLED_TABLES is array (SMALL_NAT range <>) of BOOLEAN;
> pragma pack (FILLED_TABLES);
>
> type LINE_COL is
> record
> X_V : SMALL_NAT := 1;
> Y_V : SMALL_NAT := 1;
> end record;
>
> type TABLE_VALUES is array (SMALL_NAT range <>) of LINE_COL;
>
> type M_T is array (SMALL_NAT range <>,
> SMALL_NAT range <>) of ITEM;
> type B_T is array (SMALL_NAT range <>,
> SMALL_NAT range <>) of BOOLEAN;
>
>
> type MATRIX (MAX : SMALL_NAT;
> FIRST_RECORD : BOOLEAN;
> ROWS_FIRST : SMALL_NAT;
> ROWS_LAST : SMALL_NAT;
> COLUMNS_FIRST : SMALL_NAT;
> COLUMNS_LAST : SMALL_NAT) is
>
> record
> case FIRST_RECORD is
> when TRUE =>
> -- description of entire file with tables
> FILLED : FILLED_TABLES(2..MAX) :=
> (others => FALSE);
> DISCRIMANT_VALUES : TABLE_VALUES(2..MAX) :=
> (others => (1, 1));
> when FALSE =>
> -- tables
> VALUE : M_T (ROWS_FIRST..ROWS_LAST,
> COLUMNS_FIRST..COLUMNS_LAST);
> ITEM_PUT : B_T (ROWS_FIRST..ROWS_LAST,
> COLUMNS_FIRST..COLUMNS_LAST);
> RAD_INDEX : R_T (ROWS_FIRST..ROWS_LAST);
> COLUMN_INDEX : C_T (COLUMNS_FIRST..COLUMNS_LAST);
> end case;
> end record;
>
> package MY_DIRECT_IO is new Ada.DIRECT_IO(MATRIX);
> ----------------------------------------------------------------------------
> -------------
>
> If I give type MATRIX default values it compiles with warnings about Storage
> constraints errors in runtime (that also occurs...). MATRIX is used at a lot
> of other places further down.
>
> Are there any quick (not dirty) solutions to this problem? My own ideas is
> to create separate databases for all eight databases that uses DB (CAR_DB,
> BOAT_DB, HOUSE_DB...) with specified values for MATRIX, but that seems like
> a lot of work and not very objectoriented.
> I�ve read the GNAT RM about the problem (Ada95 <-> Ada83) "Indefinite
> subtypes in generics" but don`t seem to understand, especially when there�s
> a standard package involved.
>
> All you experienced ones out there leave the "Ada is dead"-discussions and
> pleaseeeeee help me out...
>
> Magnus Sparf
> magnus-s@dsv.su.se
>
>
>
> _______________________________________________
> comp.lang.ada mailing list
> comp.lang.ada@ada.eu.org
> http://ada.eu.org/mailman/listinfo/comp.lang.ada
>
^ permalink raw reply [relevance 0%]
* Re: Direct_IO problem -- generic package problem
2001-07-12 8:42 4% Direct_IO problem -- generic package problem Magnus Sparf
@ 2001-07-12 9:19 0% ` nicolas
2001-07-12 11:38 0% ` David C. Hoos, Sr.
2001-07-12 11:41 0% ` Magnus Sparf
2001-07-12 11:33 0% ` David C. Hoos, Sr.
2001-07-12 16:58 7% ` Jeffrey Carter
2 siblings, 2 replies; 170+ results
From: nicolas @ 2001-07-12 9:19 UTC (permalink / raw)
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3538 bytes --]
If you are using gnat, you can add
pragma Ada_83;
in this body to enforce Ada_83 restrictions (provided you don't use specific
Ada95 features in this body)
But this is really a bug of Ada83 cerrected in Ada95
Nicolas
"Magnus Sparf" <magnus-s@dsv.su.se> a �crit dans le message news:
9ijobe$qb4$1@mercur.foa.se...
> I�m new to ADA (hopefully picking up track fast) and this summer I have
the
> task of converting an old Ada83 application (VAX environment) to Ada95 (PC
> environment).
> In the very heart of this application there is a homemade database that
> compiles without problem in the VAX environment. When I compile it on GNAT
> 3.13p in the PC environment. I get the following error:
>
> db.adb:58:49: actual for "Element_Type" must be a definite subtype
:::(the
> last line in the extract)
>
> Extract of code (DB is a generic package and used to create a lot of
> different databases):
> --------------------------------------------------------------------------
--
> -----------
> package body DB is
>
> type FILLED_TABLES is array (SMALL_NAT range <>) of BOOLEAN;
> pragma pack (FILLED_TABLES);
>
> type LINE_COL is
> record
> X_V : SMALL_NAT := 1;
> Y_V : SMALL_NAT := 1;
> end record;
>
> type TABLE_VALUES is array (SMALL_NAT range <>) of LINE_COL;
>
> type M_T is array (SMALL_NAT range <>,
> SMALL_NAT range <>) of ITEM;
> type B_T is array (SMALL_NAT range <>,
> SMALL_NAT range <>) of BOOLEAN;
>
>
> type MATRIX (MAX : SMALL_NAT;
> FIRST_RECORD : BOOLEAN;
> ROWS_FIRST : SMALL_NAT;
> ROWS_LAST : SMALL_NAT;
> COLUMNS_FIRST : SMALL_NAT;
> COLUMNS_LAST : SMALL_NAT) is
>
> record
> case FIRST_RECORD is
> when TRUE =>
> -- description of entire file with tables
> FILLED : FILLED_TABLES(2..MAX) :=
> (others => FALSE);
> DISCRIMANT_VALUES : TABLE_VALUES(2..MAX) :=
> (others => (1, 1));
> when FALSE =>
> -- tables
> VALUE : M_T (ROWS_FIRST..ROWS_LAST,
> COLUMNS_FIRST..COLUMNS_LAST);
> ITEM_PUT : B_T (ROWS_FIRST..ROWS_LAST,
> COLUMNS_FIRST..COLUMNS_LAST);
> RAD_INDEX : R_T (ROWS_FIRST..ROWS_LAST);
> COLUMN_INDEX : C_T (COLUMNS_FIRST..COLUMNS_LAST);
> end case;
> end record;
>
> package MY_DIRECT_IO is new Ada.DIRECT_IO(MATRIX);
> --------------------------------------------------------------------------
--
> -------------
>
> If I give type MATRIX default values it compiles with warnings about
Storage
> constraints errors in runtime (that also occurs...). MATRIX is used at a
lot
> of other places further down.
>
> Are there any quick (not dirty) solutions to this problem? My own ideas is
> to create separate databases for all eight databases that uses DB (CAR_DB,
> BOAT_DB, HOUSE_DB...) with specified values for MATRIX, but that seems
like
> a lot of work and not very objectoriented.
> I�ve read the GNAT RM about the problem (Ada95 <-> Ada83) "Indefinite
> subtypes in generics" but don`t seem to understand, especially when
there�s
> a standard package involved.
>
> All you experienced ones out there leave the "Ada is dead"-discussions and
> pleaseeeeee help me out...
>
> Magnus Sparf
> magnus-s@dsv.su.se
>
>
>
^ permalink raw reply [relevance 0%]
* Direct_IO problem -- generic package problem
@ 2001-07-12 8:42 4% Magnus Sparf
2001-07-12 9:19 0% ` nicolas
` (2 more replies)
0 siblings, 3 replies; 170+ results
From: Magnus Sparf @ 2001-07-12 8:42 UTC (permalink / raw)
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3069 bytes --]
I�m new to ADA (hopefully picking up track fast) and this summer I have the
task of converting an old Ada83 application (VAX environment) to Ada95 (PC
environment).
In the very heart of this application there is a homemade database that
compiles without problem in the VAX environment. When I compile it on GNAT
3.13p in the PC environment. I get the following error:
db.adb:58:49: actual for "Element_Type" must be a definite subtype :::(the
last line in the extract)
Extract of code (DB is a generic package and used to create a lot of
different databases):
----------------------------------------------------------------------------
-----------
package body DB is
type FILLED_TABLES is array (SMALL_NAT range <>) of BOOLEAN;
pragma pack (FILLED_TABLES);
type LINE_COL is
record
X_V : SMALL_NAT := 1;
Y_V : SMALL_NAT := 1;
end record;
type TABLE_VALUES is array (SMALL_NAT range <>) of LINE_COL;
type M_T is array (SMALL_NAT range <>,
SMALL_NAT range <>) of ITEM;
type B_T is array (SMALL_NAT range <>,
SMALL_NAT range <>) of BOOLEAN;
type MATRIX (MAX : SMALL_NAT;
FIRST_RECORD : BOOLEAN;
ROWS_FIRST : SMALL_NAT;
ROWS_LAST : SMALL_NAT;
COLUMNS_FIRST : SMALL_NAT;
COLUMNS_LAST : SMALL_NAT) is
record
case FIRST_RECORD is
when TRUE =>
-- description of entire file with tables
FILLED : FILLED_TABLES(2..MAX) :=
(others => FALSE);
DISCRIMANT_VALUES : TABLE_VALUES(2..MAX) :=
(others => (1, 1));
when FALSE =>
-- tables
VALUE : M_T (ROWS_FIRST..ROWS_LAST,
COLUMNS_FIRST..COLUMNS_LAST);
ITEM_PUT : B_T (ROWS_FIRST..ROWS_LAST,
COLUMNS_FIRST..COLUMNS_LAST);
RAD_INDEX : R_T (ROWS_FIRST..ROWS_LAST);
COLUMN_INDEX : C_T (COLUMNS_FIRST..COLUMNS_LAST);
end case;
end record;
package MY_DIRECT_IO is new Ada.DIRECT_IO(MATRIX);
----------------------------------------------------------------------------
-------------
If I give type MATRIX default values it compiles with warnings about Storage
constraints errors in runtime (that also occurs...). MATRIX is used at a lot
of other places further down.
Are there any quick (not dirty) solutions to this problem? My own ideas is
to create separate databases for all eight databases that uses DB (CAR_DB,
BOAT_DB, HOUSE_DB...) with specified values for MATRIX, but that seems like
a lot of work and not very objectoriented.
I�ve read the GNAT RM about the problem (Ada95 <-> Ada83) "Indefinite
subtypes in generics" but don`t seem to understand, especially when there�s
a standard package involved.
All you experienced ones out there leave the "Ada is dead"-discussions and
pleaseeeeee help me out...
Magnus Sparf
magnus-s@dsv.su.se
^ permalink raw reply [relevance 4%]
* Re: Looping over a tagged record?
@ 2001-06-21 17:08 3% ` Charles Hixson
0 siblings, 0 replies; 170+ results
From: Charles Hixson @ 2001-06-21 17:08 UTC (permalink / raw)
"M. A. Alves" <maa@liacc.up.pt> wrote in
news:mailman.993045741.6638.comp.lang.ada@ada.eu.org:
>> >. . , I was wondering if there is anyway to loop over all
>> >elements in the record, checking their type and then
>> >taking the right action...
>>
>> If you really need to do this, you probably should have put
>> the bounded strings into an array inside the record,
>> instead of just making them flat fields.
>
> Often I also want to merge record and array i.e. have named
> _and_ iteratable "components". Theoretically this comes down
> to "types as objects", which Ada doesn't have. Practically,
> a "standard" Ada idiom for this is an heterogenous array
> indexed on an enumeration e.g. (not tested):
>
> ...
> type Field_Ptr is access Field'Class;
> type Field_Names is (Field_1, Field_2, Field_3);
> type Record_Type is array(Field_Names) of Field_Ptr;
> A_Record: Record_Type := (
> Field_1 => Field_Constructor_A(...),
> Field_2 => Field_Constructor_A(...),
> Field_3 => Field_Constructor_B(...));
>
> Now we have a record-like object A_Record with "components"
> Field_1, Field_2 of "type" A and Field_3 of "type" B. This
> example assumes class-wide programming (including
> dispatching), with (tagged) type Field being the root of
> some derivation class. Iterating over A_Record's
> "components":
>
> for I in A_Record'Range loop
> Do_Something(A_Record(I).all); -- dispatching call
> end loop;
>
> Accessing "components" by name:
>
> Do_Something(A_Record(Field_1).all);
>
> This particular approach has a notorious shortcoming: field
> types are not checked (Field_Ptr values can reference _any_
> derived type in the class). The remedy for this is left as
> an exercise ;-)
>
It has the further shortcoming that one must know in advance
what kind of thing one is dealing with, rather than letting it
identify itself. (My main interest here.)
Currently what I'm thinking of as an answer it a file of fixed
size blocks, which are addressed via Ada.Direct_IO, somehow I
need to make them accessible to reading/writing via IO
statements. Perhaps this is AdaSockets? I haven't figured this
out yet. I may end up dropping into C to do this bit. What I
basically need to do is examine the incoming data and figure out
how long it is, and then read it into an appropriate Ada
structure. (And, if it's larger than one block, which
collection of blocks it is composed of.) Also I need to be able
to go the other direction. To take a (nearly) arbitrary data
structure, and write it out to a block, or collection of blocks,
perhaps not contiguous. Together with some identifying
information, so that when I read it back in I'll be able to
identify what kind of thing I'm reading. And I'll need to
maintain an index, etc., so that I'll be able to find it by key
value.
This part would be relatively straight-forward in C, but so far
I haven't figured out how to do it in Ada. So far it's looking
like everything is going to need to be descendant from some
particular tagged type (I'll probably call it persistant), which
will define a few basic methods (read, write, find, etc.) But
the answer that I can currently figure out how to do is to
implement everything but the inheritance in C. I'm finding this
quite distasteful, but I don't know what alternatives are
better. And figuring out how I can do this in a way that
doesn't make me rewrite everything whenever a new class is
described ...
This is quite annoying. Every language seems to have some
weakness in some part of the process. So far Python is the
hands-down winner for the store an object and retrieve it part
of the job. But it's relatively slow for all the rest. (Still,
it's also pretty easy to connect C to, say, SleepyCat DB, so
that isn't the determining factor.)
The family of languages that make it easy to read objects in
from disk, and have them be recognized as objects of the
appropriate type are all relatively slow (because they all use
interpreters/pseudo-machines). Once upon a time there was a
dialect of FORTH (Neon, by Kyria) that had a better choice. One
could specify which objects were bound at compile time, and
which would be determined dynamically. And in areas where
everything could be predetermined, it could be compiled
efficiently (for FORTH), where as when things were dynamic,
there was an extra layer of indirection. Unfortunately, they
killed themselves when they tried to transfer the program from
the Mac to the PC. (Too many comittments, and too few
resources.) Now I wouldn't say that FORTH was a particularly
good language in other ways, but that one flexibility almost
made up for all the deficiencies.
PyAda sounds like one step in this direction. I do need to
check into it. But it seems that this would essentially be the
same as calling C code from Ada. (In fact, I rather suspect
that it is implemented via Swig, in which case there would end
up being a quintuple language conversion, Ada-> C-> Python-> C->
Ada, and it's hard to see how that could be good.)
--
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/
^ permalink raw reply [relevance 3%]
* Re: Circular type definition problem
2001-06-11 20:16 8% ` Martin Dowie
@ 2001-06-11 21:18 8% ` Charles Hixson
0 siblings, 0 replies; 170+ results
From: Charles Hixson @ 2001-06-11 21:18 UTC (permalink / raw)
But the purpose of the Count type declared in Direct_IO is to
list record indicies, which is what I'm doing. Unfortunately, as
far as I can see, the type doesn't exist until I specialize it
with:
package Node_IO is new Ada.Direct_IO(Block);
But I want an index to the block (i.e., next_node) to be
contained within the Block.
What I'm trying to avoid is defining an excessive number of
types. This is a type that is defined by the system to mean
exactly what I want it to mean. But I don't seem to be able to
use it.
The reason that I tried the code that I did is because it is an
exact parallel with Access allocation. (And I don't think that I
can refer to System.Direct_IO.Count'Last;, as I haven't yet got
block defined.
OTOH, if I can refer to System.Direct_IO.Count'Last; ,
then could I refer to the type System.Direct_IO.Count, and thus
use my original code with only the addition of System.Dire...
instead of Ada.Dire...
But then, again, would this mean that I would be needing to use
Unchecked_Conversion when I wanted to refer to a particular
record? (This is one of the things that I wanted to avoid.)
Martin Dowie wrote:
> you could split out the implementation specifics into a seperate
> package e.g.
>
> with System.Direct_IO;
>
> package Project_Specifics is
>
> -- Specific to GNAT
> --
> Direct_IO_Count_Last : constant :=
> System.Direct_IO.Count'Last;
>
> end Project_Specifics;
>
>
> with Ada.Direct_Io;
> with Project_Specifics;
>
> package Temp is
>
> type Byte is mod 256;
>
> type Block;
>
> type Blockdata is array (0 .. 511) of Byte;
>
> type Node_Count is range 0 ..
> Project_Specifics.Direct_IO_Count_Last;
>
> type Block is
> record
> Next_Node : Node_Count;
> Data : Blockdata;
> end record; -- Block
>
> pragma Pack(Blockdata);
> pragma Pack(Block);
>
> package Node_Io is new Ada.Direct_Io(Block);
> use Node_Io;
>
> end Temp;
>
>
> "Charles Hixson" <charleshixsn@earthlink.net> wrote in message
> news:1s7V6.4021$Il5.510814@newsread1.prod.itd.earthlink.net...
>> This is what I'm trying to do:
>> type Block;
>> package Node_IO is new Ada.Direct_IO(Block);
>> use Node_IO;
>> type BlockData is array (0..511) of Byte;
>> type Block is record
>> next_node : Node_IO.Count;
>> data : BlockData;
>> end record; -- Block
>> pragma pack(BlockData);
>> pragma pack(Block);
>>
>> Not too much to my surprise, it didn't work. Node_IO needs to
>> be
>> defined with a real type. OTOH, the type Node_IO.Count is
>> defined within Node_IO, so I can't put it after the declaration
>> of Block.
>>
>> I suppose that I could just give up, and declare next_node to
>> be
>> Long_Integer, but that seems so inelegant. Node_IO.Count is,
>> essentially, an Access variable (it says where in the file to
>> find the next Block). But I'm not really sure how to approach
>> this. Any suggestions?
^ permalink raw reply [relevance 8%]
* Re: Circular type definition problem
2001-06-11 17:44 5% Circular type definition problem Charles Hixson
@ 2001-06-11 20:16 8% ` Martin Dowie
2001-06-11 21:18 8% ` Charles Hixson
0 siblings, 1 reply; 170+ results
From: Martin Dowie @ 2001-06-11 20:16 UTC (permalink / raw)
you could split out the implementation specifics into a seperate package
e.g.
with System.Direct_IO;
package Project_Specifics is
-- Specific to GNAT
--
Direct_IO_Count_Last : constant := System.Direct_IO.Count'Last;
end Project_Specifics;
with Ada.Direct_Io;
with Project_Specifics;
package Temp is
type Byte is mod 256;
type Block;
type Blockdata is array (0 .. 511) of Byte;
type Node_Count is range 0 .. Project_Specifics.Direct_IO_Count_Last;
type Block is
record
Next_Node : Node_Count;
Data : Blockdata;
end record; -- Block
pragma Pack(Blockdata);
pragma Pack(Block);
package Node_Io is new Ada.Direct_Io(Block);
use Node_Io;
end Temp;
"Charles Hixson" <charleshixsn@earthlink.net> wrote in message
news:1s7V6.4021$Il5.510814@newsread1.prod.itd.earthlink.net...
> This is what I'm trying to do:
> type Block;
> package Node_IO is new Ada.Direct_IO(Block);
> use Node_IO;
> type BlockData is array (0..511) of Byte;
> type Block is record
> next_node : Node_IO.Count;
> data : BlockData;
> end record; -- Block
> pragma pack(BlockData);
> pragma pack(Block);
>
> Not too much to my surprise, it didn't work. Node_IO needs to be
> defined with a real type. OTOH, the type Node_IO.Count is
> defined within Node_IO, so I can't put it after the declaration
> of Block.
>
> I suppose that I could just give up, and declare next_node to be
> Long_Integer, but that seems so inelegant. Node_IO.Count is,
> essentially, an Access variable (it says where in the file to
> find the next Block). But I'm not really sure how to approach
> this. Any suggestions?
^ permalink raw reply [relevance 8%]
* Circular type definition problem
@ 2001-06-11 17:44 5% Charles Hixson
2001-06-11 20:16 8% ` Martin Dowie
0 siblings, 1 reply; 170+ results
From: Charles Hixson @ 2001-06-11 17:44 UTC (permalink / raw)
This is what I'm trying to do:
type Block;
package Node_IO is new Ada.Direct_IO(Block);
use Node_IO;
type BlockData is array (0..511) of Byte;
type Block is record
next_node : Node_IO.Count;
data : BlockData;
end record; -- Block
pragma pack(BlockData);
pragma pack(Block);
Not too much to my surprise, it didn't work. Node_IO needs to be
defined with a real type. OTOH, the type Node_IO.Count is
defined within Node_IO, so I can't put it after the declaration
of Block.
I suppose that I could just give up, and declare next_node to be
Long_Integer, but that seems so inelegant. Node_IO.Count is,
essentially, an Access variable (it says where in the file to
find the next Block). But I'm not really sure how to approach
this. Any suggestions?
^ permalink raw reply [relevance 5%]
* Re: Streams in Ada
2001-03-31 20:48 5% ` James Rogers
@ 2001-04-02 14:00 0% ` Ted Dennison
0 siblings, 0 replies; 170+ results
From: Ted Dennison @ 2001-04-02 14:00 UTC (permalink / raw)
In article <3AC64324.A79AE084@worldnet.att.net>, James Rogers says...
>
>I assume from your use of the term "streams" that you want to be able
>to directly address file elements. "Streams" is the C term for such
>capability. Ada uses streams for a somewhat different capability.
>
>I believe what you want is handled by the package Ada.Direct_Io.
Actually, this sounds like the exact issue we've talked about twice in the last
couple of months already. You generally don't want to use Direct_IO instantiated
for byte-sized objects, as there will be a call for each and every byte read,
which is going to be really slow (and make your Ada code look bad). If there is
only a couple of sizes to read, you might be able to get away with a separate
Direct_IO instantiation for each, but there will still be a bit of waste closing
one instantiation's view of the file so the other can open it and reposition to
the right place.
The best way to solve the problem of reading an unstructured array of bytes from
a file in Ada is to use Ada.Streams.Stream_IO, along with a direct call to
Ada.Streams.Read with a properly-sized array of stream elements.
Didn't someone volunteer to put some example sources for doing this on AdaPower?
I can post some code I have that does this, if needed. (hmmm, assuming I didn't
delete it last week...) The speedup I observed in doing it this way vs.
Sequential_IO was nothing less than amazing.
---
T.E.D. homepage - http://www.telepath.com/dennison/Ted/TED.html
home email - mailto:dennison@telepath.com
^ permalink raw reply [relevance 0%]
* Re: Streams in Ada
@ 2001-03-31 20:48 5% ` James Rogers
2001-04-02 14:00 0% ` Ted Dennison
0 siblings, 1 reply; 170+ results
From: James Rogers @ 2001-03-31 20:48 UTC (permalink / raw)
I assume from your use of the term "streams" that you want to be able
to directly address file elements. "Streams" is the C term for such
capability. Ada uses streams for a somewhat different capability.
I believe what you want is handled by the package Ada.Direct_Io.
Look in the Ada Reference Manual, Appendix A, for details on this
package.
Jim Rogers
Colorado Springs, Colorado USA
"chris.danx" wrote:
>
> Hi,
> I've looked about for examples on streams in Ada. I'm writing an
> virtual file system as a file on disk, and want to use streams. I have to
> be able to go back and forwards and read large blocks of data from the file
> at random positions. I have tried to locate an example of using streams but
> couldn't find any that didn't deal with sequential access.
>
> the first block is 512 bytes and inodes are 64bytes. then i have a set of
> blocks which are 16bytes long. you can see now why i'm using streams, but i
> can't seem to work out from the ref manual and Barnes what i should do. I
> recall the ref manual saying index is relative to stream element but i don't
> know what it means. Anyone know of a good example?
>
> Thanks in advance,
> Chris Campbell
^ permalink raw reply [relevance 5%]
* Re: text_io is not a predefined library
@ 2001-03-13 10:47 7% ` David C. Hoos, Sr.
0 siblings, 0 replies; 170+ results
From: David C. Hoos, Sr. @ 2001-03-13 10:47 UTC (permalink / raw)
Using Text_IO in place of Ada.TextIO is not the problem.
Note the following from RM95, J.1;
The following library_unit_renaming_declarations exist:
2 with Ada.Unchecked_Conversion;
generic function Unchecked_Conversion renames Ada.Unchecked_Conversion;
3 with Ada.Unchecked_Deallocation;
generic procedure Unchecked_Deallocation renames Ada.Unchecked_Deallocation;
4 with Ada.Sequential_IO;
generic package Sequential_IO renames Ada.Sequential_IO;
5 with Ada.Direct_IO;
generic package Direct_IO renames Ada.Direct_IO;
6 with Ada.Text_IO;
package Text_IO renames Ada.Text_IO;
7 with Ada.IO_Exceptions;
package IO_Exceptions renames Ada.IO_Exceptions;
8 with Ada.Calendar;
package Calendar renames Ada.Calendar;
9 with System.Machine_Code;
package Machine_Code renames System.Machine_Code; -- If supported.
The earlier suggestion by Jeff Creem that it is a GNAT installation
problem is the correct explanation for the phenomenon.
"DuckE" <nospam_steved94@home.com> wrote in message
news:dKhr6.559748$U46.16631404@news1.sttls1.wa.home.com...
> Text_Io is a child of Ada.
>
> Try:
> with Ada.Text_Io;
> use Ada.Text_Io;
>
> SteveD
>
> "Andrew Busolin" <abusolin@chariot.net.au> wrote in message
> news:3aad6b31_5@news.chariot.net.au...
> > Hi there,
> >
> > I have written a little hello world program in an effort to test out the
> ada
> > compiler I have recently downloaded. I am able to compile it using
> > gcc -c -gnats -c hello.adb, however when I try to gnatmake it using
> > gnatmake -c hello.adb it returns "ada.text_io" is not a predefined
library
> > unit
> > compilation abandoned!!!
> >
> > Can someone please tell me why this is and how I can fix it!
> >
> > Best Regards
> >
> > Andrew Busolin
> >
> >
> > with Text_Io;
> > use Text_Io;
> >
> > procedure hello is
> > begin
> > Put("hello");
> > end hello;
> >
> >
>
>
^ permalink raw reply [relevance 7%]
* Learn Ada! - Free Ada-Belgium course starts Jan 24
@ 2001-01-21 21:30 1% Dirk Craeynest
0 siblings, 0 replies; 170+ results
From: Dirk Craeynest @ 2001-01-21 21:30 UTC (permalink / raw)
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 20792 bytes --]
------------------------------------------------------------------------
Call for Participation
Learn Ada!
Ada-Belgium presents a free course
January-March 2001
U.L.B., Brussels, Belgium
Bi-weekly on Wednesday evening
Starting January 24, 2001
http://www.cs.kuleuven.ac.be/~dirk/ada-belgium/events/local.html
------------------------------------------------------------------------
Modern society is becoming very dependent upon software. Our
transport systems, financial systems, medical systems and defense
systems all depend to a very large degree upon software. As a
consequence the safety of many human lives and much property now
depends upon the reliable functioning of software. Moreover, the
fall in the cost of hardware has now made possible the development
of large software systems.
Ada is a programming language of special value in the development
of large programs which must work reliably. [...] Ada is a modern
programming language suitable for those application areas which
benefit from the discipline of organized development, that is,
Software Engineering; it is a general purpose language with special
applicability to real-time and embedded systems. [...]
Although Ada was originally designed to provide a single flexible
yet portable language for real-time embedded systems to meet the
needs of the US DoD, its domain of application has expanded to
include many other areas, such as large-scale information systems,
distributed systems, scientific computation, and systems
programming. Furthermore, its user base has expanded to include all
major defense agencies of the Western world, the whole of the
aerospace community and increasingly many areas in civil and
private sectors such as telecommunications, process control and
monitoring systems. Indeed, the expansion in the civil sector is
such that civil applications now generate the dominant revenues of
many vendors.
(from "Ada 95 Rationale: The Language, The Standard Libraries",
John Barnes (ed.), Lecture Notes in Computer Science, vol. 1247,
Springer-Verlag, 1997, ISBN 3-540-63143-7)
Ada-Belgium is a non-profit volunteer organization whose purpose is to
promote the use in Belgium of the Ada programming language, the first
ISO standardized object-oriented language.
Early 2001, Ada-Belgium will run a course teaching Ada 95, at the
premises of the U.L.B. in Brussels, bi-weekly on Wednesday evenings
starting on January 24, 2001.
This is an updated re-run of the highly successful Ada course
organized in the fall of 1998.
------------------------------------------------------------------------
Highlights
----------
* The course will be modular: you may skip modules discussing
subjects you already know about without losing the thread of the
course. The first module will be an introduction to Ada mainly for
programmers in other languages. After this the modules will be of
interest to both newcomers to Ada and those already working in Ada
83 who wish to learn Ada 95.
* The course will take the form of evening sessions every two weeks.
There will be small exercises during the evening sessions and
larger exercises which may be completed between sessions. Ada
compilers will be available for the completion of these exercises.
* The course will be taught in English. Everyone interested is
welcome.
More information is available below and via the Ada Course Home Page
via URL
http://www.cs.kuleuven.ac.be/~dirk/ada-belgium/events/local.html
Here you will find info on:
* the full program,
* abstracts of the modules,
* free Ada CD-ROMs for Ada-Belgium members,
* documentation that will be handed out,
* the location of the course,
* registration,
* the course secretariat, and
* acknowledgements,
* a course registration form,
* an Ada-Belgium membership application form.
This free Ada course is an opportunity not to be missed! Do not delay
to register!
Looking forward to meet many of you in Brussels.
Dirk Craeynest
Ada-Belgium Board
ada-belgium-board@cs.kuleuven.ac.be
------------------------------------------------------------------------
Program
-------
Schedule:
Wed 24 Jan 2001 - Introduction to Ada - part 1
Wed 7 Feb 2001 - Introduction to Ada - part 2
Wed 21 Feb 2001 - Object-Oriented Programming in Ada - part 1
Wed 7 Mar 2001 - Object-Oriented Programming in Ada - part 2
Wed 21 Mar 2001 - Parallel Programming in Ada
Wed 28 Mar 2001 - Distributed Programming in Ada
more sessions might be scheduled.
Note: during the week of 14-18 May, 2001, Ada-Belgium co-organizes
the 6th International Conference on Reliable Software Technologies -
Ada-Europe'2001, in Leuven.
------------------------------------------------------------------------
Abstracts
---------
* "Introduction to Ada"
Raymond Devillers, U.L.B., Bruxelles
(replaces Marc Gobin, Royal Military Academy, Brussel)
(2 sessions; abstract provided by the author)
The introductory course will cover most of the core language, except
for the material covered in the subsequent modules, such as object
oriented features and tasking.
The course will essentially be taught as a sequence of simple programs
showing common aspects of programming in Ada.
We will first walk to the simple predefined types and see how
declarations are controlled.
The power of Ada conditional statements and loop statements will be
illustrated. The introduction of new types and subtypes will be
explained, including arrays, records and pointers.
Procedures and functions will than be introduced, first embedded in
the program itself and than defined outside a program ready to be used
by as many programs as needed. This means the introduction of packages
and exceptions.
The power of generic units will be shown and we will discuss the input
output possibilities of the predefined packages Ada.Text_Io,
Ada.Sequential_Io and Ada.Direct_Io.
References
- John Barnes: "Programming in Ada95, 2nd edition" (Addison Wesley)
- Michael Feldman: "Software Construction and Data structures with
Ada95" (Addison Wesley)
- Michael Feldman & Koffman: "Ada95, Problem solving and program
design" (Addison Wesley)
- Ada 95 Reference Manual (Springer Verlag)
- Ada 95 Rationale (Springer Verlag)
- Ada 95 Style Guide (Springer Verlag)
* "Object-Oriented Programming in Ada"
Luc Bernard, OFFIS nv/sa, Zaventem
(2 sessions; abstract provided by the author)
One of the major contributions of the 95 version of the Ada language
is certainly the way it addresses Object-Oriented Design and
Development.
The two sessions will present how OO concepts have been added to the
language on top of existing ones (types, derivations, etc...). No
particular knowledge of OO is required to follow these sessions since
the basic concepts will be briefly presented.
* "Parallel Programming in Ada"
Raymond Devillers, U.L.B., Bruxelles
(1 session)
Many more programmers are having to work in multi-threaded
environments today: most modern operating systems support threads (or
light-weight processes) to some extent. The problem with threads is
that they are not standard and so are not portable. Every operating
system has a differing set of application programmers' interfaces
(APIs) and frequently differing scheduling and priority rules. Thread
programming is also notoriously difficult to manage in C and difficult
to encapsulate in C++. Neither C nor C++ provides any support for
important issues in multi-threaded programming features such as
re-entrant functions and interprocess communication (IPC).
Unlike C++ Ada defines a model for concurrent programming as part of
the language itself. Few other languages (Occam and Java are examples)
provide language level concurrency; other languages (Modula-3) provide
a concurrency model through the use of standard library abstractions.
In Ada there are two base components: the task which encapsulates a
concurrent process, and the protected type, which is a data structure
that provides guarded access to its data. These features can be used
to develop responsive, high-performance applications utilizing one of
the few truly cross-platform models for concurrent processing.
The real-time systems annex provides additional facilities for
programming in either a hard or a soft real-time environment. The main
thrust of this annex is to provide programmers of real-time systems
with an environment which provides fixed, predictable scheduling of
tasks and interrupts within an application.
(from "Ada 95 for C and C++ Programmers", Simon Johnston, Addison
Wesley Longman, 1997, ISBN 0-201-40363-3)
* "Distributed Programming in Ada"
Yolande Berbers, K.U.Leuven, Leuven
(1 session)
As presented at the Ada-Belgium'97 Seminar on Developing Distributed
Applications, several different approaches are available. The most
important ones are using CORBA or the Ada 95 distributed systems annex
(or both).
The Ada 95 programming language is a powerful and flexible language
that provides a safe environment for creating reliable software. The
OMG Common Object Request Broker Architecture (CORBA) is a flexible
environment for creating potentially distributed software components.
The marriage of these two technologies results in a uniquely powerful
environment for creating high performance, reliable, distributed
software components.
(from "Ada-Belgium'97 - Call for Participation", Ada-Belgium, 1997)
Ada 95 is the first general-purpose language to provide a standard
distributed programming paradigm. By combining the distributed and
object-oriented features of Ada 95, it is possible to create an
application where objects are physically distributed over a network of
machines, without having to interface to any low-level communication
layer. Likewise, by combining the distributed and real-time
capabilities of Ada 95, it is possible to design applications which
meet real-time constraints in a distributed environment.
GNAT, and more specifically GLADE (GNAT Library for Ada Distributed
Execution), is the first commercial implementation of the distributed
Ada 95 programming model. This implementation allows a distributed
application to run on a network of heterogeneous machines, to support
different network protocols, and to provide replication and
fault-tolerance.
(from "GLADE - Distributed systems in Ada 95", ACT Europe, 1998)
Contents of this session:
- Strategies to program distributed applications
- Ada 95 distributed system annex overview
- Categorization pragmas: definitions and examples
- GNATDIST: Configuration tool and language
- GARLIC: PCS and its extended services
------------------------------------------------------------------------
Free Ada CD-ROMs for Ada-Belgium members
----------------------------------------
Copies of the full Ada and Software Engineering CD-ROM set (version 1),
provided by Ada-Belgium through an agreement with the Special Interest
Group on Ada of the ACM (ACM SIGAda) and handed out at previous
Seminars, will be freely distributed to direct Ada-Belgium members
attending the course. This CD-ROM set of 4 discs includes a.o. ports to
lots of platforms of the GNU Ada 95 compiler (GNAT), and Aonix' Ada 95
Compiler and Environment for MS Windows. More information on this Ada
and Software Engineering CD-ROM set is available separately.
Documentation
-------------
We plan to provide copies of the presentations at each course session.
In addition, we still have a small number of documentation sets of the
Ada-Belgium'98 Seminar (theme "Concurrency & Real-Time") and the
Ada-Belgium'99 Seminar (theme "Ada 95 Works!") for direct members not
attending these seminars (as availability permits). These sets contain,
a.o., printed proceedings with papers related to the presentations,
copies of slides, and additional documents and papers.
------------------------------------------------------------------------
Location
--------
The following concerns the course modules, not the conference:
* Place:
Universit� Libre de Bruxelles (ULB)
Boulevard du Triomphe
Campus de la Plaine
1050 Brussels
* Room:
"Salle des Professeurs", building NO, 9th level, room NO.9.06.
* Time:
19:00 - 22:00 (including break)
An access plan to the Campus de la Plaine of the U.L.B. is available
via the Ada Course Web-pages. Parking facilities are at access no. 2
(parking Fraiteur, the closest) or no. 4 (parking UAE, usually has free
space). You can check on-line how to get to Brussels and how to reach
the V.U.B./U.L.B. depending on the means of transport you use.
Registration
------------
Advance registration is prefered. Registration is free of charge.
Please return the attached Registration Form as soon as possible.
As mentioned above, for direct Ada-Belgium members registration
includes the option to receive a free copy of the full 4-disc Ada and
Software Engineering CD-ROM set, containing a.o. several editions of
two Ada 95 compilers: the public GNAT distribution from ACT, for lots
of platforms, and the ObjectAda Special Edition from Aonix, for
Windows 95 and NT.
A limited supply of additional material that was distributed at the
Ada-Belgium'98 and '99 Seminars is also available for direct members
on their request (see above and registration form).
Others registering for (a) course module(s) can optionally become
Ada-Belgium members, and hence also receive the free CD-ROMs and
documentation.
Course Secretariat
------------------
Ada-Belgium Secretariat
Attn. Prof. R. Devillers
c/o Universit� Libre de Bruxelles (U.L.B.)
Boulevard du Triomphe / Triomflaan
Campus de la Plaine, CP 212, B-1050 Brussels
Phone (32)-2-650.56.11, Fax (32)-2-650.56.09
E-mail: ada-belgium-board@cs.kuleuven.ac.be
------------------------------------------------------------------------
Acknowledgements
We would like to thank our sponsors for their continued support of our
activities: ACT Europe, John Robinson & Associates, Katholieke
Universiteit Leuven (K.U.Leuven), Koninklijke Militaire School / Ecole
Royale Militaire (K.M.S./E.R.M.), OFFIS nv/sa, Rational Software
Corporation, Top Graph'X, and Universit� Libre de Bruxelles (U.L.B.).
------------------------------------------------------------------------
Information on this and other Ada-Belgium events is available on the
Internet at the Ada-Belgium World-Wide-Web pages and is updated
regularly. Check out URL
http://www.cs.kuleuven.ac.be/~dirk/ada-belgium/events/local.html
-- cut here ------- >8 ------- >8 ------- >8 ------- >8 ------- >8 -----
Ada-Belgium Ada Course Registration
________________________________________________________________________
Please mail to or fax to
-------------- ---------
Ada-Belgium Secretariat + 32 (0)2 650.56.09
c/o Universite' Libre de Bruxelles
Attn. Prof. R. Devillers
Boulevard du Triomphe / Triomflaan or e-mail to
Campus de la Plaine, CP 212 ------------
B - 1050 Brussels, Belgium ada-belgium-board@cs.kuleuven.ac.be
Personal Information
--------------------
Name __________________________ First name _________________________
Job title / Occupation ________________________________________________
Company / Institution _________________________________________________
Address _______________________________________________________________
________________________________________________________________________
Zip code ______________________ City _______________________________
Country _______________________ E-mail _____________________________
Telephone _____________________ Telefax ____________________________
I want to register, free of charge, for Ada-Belgium's Ada Course
that will take place at the U.L.B. in Brussels, starting early 2001,
bi-weekly on Wednesday evenings 19:00 - 22:00.
I will attend the following sessions: (Please tick all that apply)
-------------------------------------
___ Wed 24 Jan 2001 - Introduction to Ada - part 1
___ Wed 7 Feb 2001 - Introduction to Ada - part 2
___ Wed 21 Feb 2001 - Object-Oriented Programming in Ada - part 1
___ Wed 7 Mar 2001 - Object-Oriented Programming in Ada - part 2
___ Wed 21 Mar 2001 - Parallel Programming in Ada
___ Wed 28 Mar 2001 - Distributed Programming in Ada
(more sessions might be scheduled)
Indication of interest (separate registration will be required later):
___ 14-18 May 2001 - 6th International Conference on Reliable Software
Technologies - Ada-Europe'2001, Leuven, Belgium
Membership Status for 2001 (Please tick one item)
--------------------------
___ I am an individual Ada-Belgium member
___ I am appointed contact person of a corporate Ada-Belgium member
___ I want to register as Ada-Belgium member
(please mail or fax an Ada-Belgium membership application form
and pay the appropriate fee)
___ I am not, nor do I want to register as, Ada-Belgium member
(and hence am NOT entitled to the free Ada CD-ROMs and
documention sets)
For Ada-Belgium Members Only (Please tick all that apply)
----------------------------
___ I would like to receive a copy of the Ada and Software Engineering
2 CD-ROM base set (November 1998)
___ I would like to receive a copy of the Ada and Software Engineering
2 CD-ROM update 2 set (October 1999)
___ I would like to receive a copy of the documentation set of the
Ada-Belgium'99 Seminar, theme "Ada 95 Works!"
(as availability permits)
___ I would like to receive a copy of the documentation set of the
Ada-Belgium'98 Seminar, theme "Concurrency & Real-Time"
(as availability permits)
Signature _________________________ Date ___________________________
-- cut here ------- >8 ------- >8 ------- >8 ------- >8 ------- >8 -----
2001 Ada-Belgium Membership Application
________________________________________________________________________
Please mail to or fax to
-------------- ---------
Ada-Belgium + 32 (0)2 650 56 09
c/o Universite' Libre de Bruxelles (ULB)
Boulevard du Triomphe
Campus de la Plaine, CP 212
B - 1050 Bruxelles, Belgium Page 1 of _______
Personal Information
--------------------
Name __________________________ First name _________________________
For Corporate Members: Name of Appointed Contact Person
Job title / Occupation ________________________________________________
Company / Institution _________________________________________________
Address _______________________________________________________________
________________________________________________________________________
Zip code ______________________ City _______________________________
Country _______________________ E-mail _____________________________
Telephone _____________________ Telefax ____________________________
The above address is ___ my company address
___ my private address
Membership (Includes Ada-Europe Membership & Benefits Package)
---------- (Please tick one item)
___ Individual Member (annual fee: 30 EUR = 1 210 BEF)
___ Corporate Member (annual fee: 130 EUR = 5 244 BEF)
___ Student Member (annual fee: 15 EUR = 605 BEF)
Payment information (Please tick one item)
-------------------
YES, I agree to pay the appropriate registration fee to Ada-Belgium VZW
___ to account number 979-3829669-17 (Argenta), or
___ to account number 409-9054291-64 (KBC),
mentioning "2001 Ada-Belgium Membership"
Ada-related Points of Interest
------------------------------
If you have any specific point of interest, please mention them in
attachment to this form.
Additional Addresses
--------------------
If you know other people or companies in Belgium who are interested
in Ada, please mention their names and addresses in attachment to
this form, and we will contact them with information on Ada-Belgium.
Thank you.
Signature _________________________ Date ___________________________
Attachment ____________________________________________________________
-- cut here ------- >8 ------- >8 ------- >8 ------- >8 ------- >8 -----
^ permalink raw reply [relevance 1%]
* Booch components
@ 2000-10-18 1:11 7% Alexey V. Litvinov
2000-10-18 0:00 0% ` Simon Wright
0 siblings, 1 reply; 170+ results
From: Alexey V. Litvinov @ 2000-10-18 1:11 UTC (permalink / raw)
To: comp.lang.ada
When I tried to use Booch components in my program,
I encountered some trouble with next code (It's abstraction of
database table as file of simular entities.
With little diffirent mechanism of deleting/appending of
records from Dbase-like. Because I'll have little couple
of deleted records with my application and I don't wish
make packing of table, I decide use unbounded queue for list
of deleted records and use values from it when I need to
append new records).
with Ada.Direct_IO;
generic
type RecDataType is private;
FileName : String;
package DB_Table is
type RecCountType is private;
type RecPosvCountType is private;
--.
--.
--. -- routines to read/write/append/etc...
--.
private
package Table_IO is new Ada.Direct_IO(RecDataType);
type RecCountType is new Table_IO.Count;
type RecPosvCountType is new Table_IO.Positive_Count;
type DEItem is record
Pos: Table_IO.Positive_Count;
end record;
package DE_IO is new Ada.Direct_IO(DEItem);
TableFile : Table_IO.File_Type;
DEFile : DE_IO.File_Type;
end DB_Table;
with Ada.Direct_IO;
with BC;
with BC.Containers;
with BC.Containers.Queues;
with BC.Containers.Queues.Unbounded;
with BC.Support.Unmanaged_Storage;
package body DB_Table is
package Unmanaged_Storage renames BC.Support.Unmanaged_Storage;
Storage: Unmanaged_Storage.Pool;
package Containers is new BC.Containers(Item => DEItem);
package Queues is new Containers.Queues;
package UBQueue is new Queues.Unbounded
(Unmanaged_Storage.Pool, Storage);
--.
--.
--. -- routines to read/write/append/etc...
--.
end DB_Table;
After compliling with GNAT 3.13p:
gcc -c -gnatf db_table.adb
db_table.adb:13:04: instantiation error at bc-containers.ads:132
db_table.adb:13:04: parent type must not be outside generic body
gnatmake: "db_table.adb" compilation error
But this trouble arising only if my package is generic, when I made
just simular simple package compling was saccessful.
Good Old Question: knew somebody what I'm doing wrong,
or why things are going wrong?
PS: at bc.containers.ads:132 we have
private
-- We need access to Items; but we must make sure that no actual
-- allocations occur using this type.
type Item_Ptr is access all Item;
for Item_Ptr'Storage_Size use 0;
<this>
type Container is abstract new Ada.Finalization.Controlled with null record;
</this>
-- Private primitive operations.
-- These should ideally be abstract; instead, we provide implementations,
-- but they raise Should_Have_Been_Overridden.
^ permalink raw reply [relevance 7%]
* Re: Booch components
2000-10-18 1:11 7% Booch components Alexey V. Litvinov
@ 2000-10-18 0:00 0% ` Simon Wright
0 siblings, 0 replies; 170+ results
From: Simon Wright @ 2000-10-18 0:00 UTC (permalink / raw)
To: comp.lang.ada
"Alexey V. Litvinov" <lial@khrts.khv.ru> writes:
> When I tried to use Booch components in my program,
> I encountered some trouble with next code (It's abstraction of
> database table as file of simular entities.=20
Could you possibly set your newsreader not to generate these '=20'
characters? I think it may have something to do with "quoted
printable"
> With little diffirent mechanism of deleting/appending of
> records from Dbase-like. Because I'll have little couple=20
> of deleted records with my application and I don't wish=20
> make packing of table, I decide use unbounded queue for list=20
> of deleted records and use values from it when I need to=20
> append new records).
Unless you really need the polymorphic aspects of Lists, I *strongly*
recomment that you use Collections.
> with Ada.Direct_IO;
>
> generic
> type RecDataType is private;
> FileName : String;
>
> package DB_Table is
>
> type RecCountType is private;
> type RecPosvCountType is private;
> --.
> --.
> --. -- routines to read/write/append/etc...
> --.
>
> private
>
> package Table_IO is new Ada.Direct_IO(RecDataType);
>
> type RecCountType is new Table_IO.Count;
> type RecPosvCountType is new Table_IO.Positive_Count;
> =20
> type DEItem is record
> Pos: Table_IO.Positive_Count;
> end record;
>
> package DE_IO is new Ada.Direct_IO(DEItem);
>
> TableFile : Table_IO.File_Type;
> DEFile : DE_IO.File_Type;
>
> end DB_Table;=20
>
> with Ada.Direct_IO;
> with BC;
> with BC.Containers;
> with BC.Containers.Queues;
> with BC.Containers.Queues.Unbounded;
> with BC.Support.Unmanaged_Storage;
>
> package body DB_Table is
> =20
> package Unmanaged_Storage renames BC.Support.Unmanaged_Storage;
> Storage: Unmanaged_Storage.Pool;
>
> package Containers is new BC.Containers(Item =3D> DEItem);
The problem is that the BCs are based on tagged types; and you can
only derive new tagged types in a package *spec*. Move all these
instantiations into the spec and you should be OK.
> package Queues is new Containers.Queues;
> package UBQueue is new Queues.Unbounded
> (Unmanaged_Storage.Pool, =
> Storage);
>
> --.
> --.
> --. -- routines to read/write/append/etc...
> --.
>
> end DB_Table;
>
> After compliling with GNAT 3.13p:
> gcc -c -gnatf db_table.adb
> db_table.adb:13:04: instantiation error at bc-containers.ads:132
> db_table.adb:13:04: parent type must not be outside generic body
> gnatmake: "db_table.adb" compilation error
Yes, this is a strange error message, I'll make a problem report to ACT.
> But this trouble arising only if my package is generic, when I made=20
> just simular simple package compling was saccessful.
>
> Good Old Question: knew somebody what I'm doing wrong,=20
> or why things are going wrong?
>
> PS: at bc.containers.ads:132 we have
> private
>
> -- We need access to Items; but we must make sure that no actual
> -- allocations occur using this type.
>
> type Item_Ptr is access all Item;
> for Item_Ptr'Storage_Size use 0;
>
> <this>
> type Container is abstract new Ada.Finalization.Controlled with null =
> record;
> </this>
? I don't see what you think is wrong here?
I would have posted this reply in c.l.a, but for the moment my
newsfeed is under revision :-) and I can only read.
^ permalink raw reply [relevance 0%]
* Re: File I/O
@ 2000-09-29 3:15 6% ` tmoran
0 siblings, 0 replies; 170+ results
From: tmoran @ 2000-09-29 3:15 UTC (permalink / raw)
>How can I read a file and write to a file in Ada?
What kind of file?
For text files, consisting of variable length lines separated by CR
or LF, use Ada.Text_IO
For files consisting of a homogenous series of binary records,
look at Ada.Sequential_IO
For files consisting of a homogenous set of binary records, randomly
accessible, look at Ada.Direct_IO
For files with heterogenous binary stuff, look at Ada.Streams.Stream_IO
^ permalink raw reply [relevance 6%]
* Re: Binary File Manip. - Possibly a stupid question
@ 1999-07-20 0:00 5% ` Ted Dennison
0 siblings, 0 replies; 170+ results
From: Ted Dennison @ 1999-07-20 0:00 UTC (permalink / raw)
In article <3795BF16.BCF418D6@Think.So.Com>,
Matthew <I.Dont@Think.So.Com> wrote:
> book with no mention of binary files) I came to the conclusion that I
> have to use some kind of Stream (since Stream_IO's End_Of_File
> references the file's size instead of a special character), but I have
> no idea how to use them properly.
>
..
> My compression alg. is currently running on the assumption that the
> stuff read in from the source file can be accessed in 8-bit-byte
chunks
> that can be mapped to character representations.
Streams wil work. However it is best to use them if both the writer and
the eventual reader are using the Ada stream packages. Its possible, if
rather unlikely, that the stream you are using could be playing tricks
on your data (eg: compressing it, reading in bizzarely sized chunks at a
time, byte swapping, etc). You *can* use streams to do this, you just
have to be careful.
If you have an *exact* representation that you want to see on disk
(minus what the file-system does to it, of course), then you should
probably use either Ada.Sequential_IO or Ada.Direct_IO. They are
generics, so you instantiate them with the data type you want to write
to the file.
Another wrinkle to throw on this is that your particular application may
be a good candidate for implemenation *as* a custom stream. :-)
--
T.E.D.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
^ permalink raw reply [relevance 5%]
* Re: Elimination of "use" clauses
@ 1999-07-12 0:00 5% ` Ted Dennison
0 siblings, 0 replies; 170+ results
From: Ted Dennison @ 1999-07-12 0:00 UTC (permalink / raw)
In article <7mdml7$vo4$1@nnrp1.deja.com>,
Robert Dewar <robert_dewar@my-deja.com> wrote:
> My preferred approach would be to forbid any user packages
> from duplicating the names used in the RM in Annex A and
> other standard packages, unless there is a very definite
> methodological reason for the duplication (e.g. defining
> a Put procedure for additional types).
That's a pretty hefty set of useful names you are putting off-limits!
For instance:
"Move", "Index", "Count", "Insert", "Delete" (Ada.Strings.Fixed)
"Split" (Ada.Calendar)
"Read", "Write" (Ada.Storage_IO, Ada.Streams)
"Create", "Reset", "Name" (Ada.Text_IO)
"Initialize", "Adjust" (Ada.Finalization)
"Size" (Ada.Direct_IO)
Looking over this list, its interesting how much more sense each makes
at first glance when given the context of its package name...
--
T.E.D.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
^ permalink raw reply [relevance 5%]
* Learn Ada 95! - Free Ada-Belgium course starts 98/09/23
@ 1998-09-10 0:00 1% Dirk Craeynest
0 siblings, 0 replies; 170+ results
From: Dirk Craeynest @ 1998-09-10 0:00 UTC (permalink / raw)
------------------------------------------------------------------------
Call for Participation
Learn Ada 95!
Ada-Belgium presents a free course
Bi-weekly on Wednesday evening
Starting September 23, 1998
U.L.B., Brussels, Belgium
http://www.cs.kuleuven.ac.be/~dirk/ada-belgium/events/local.html
------------------------------------------------------------------------
Modern society is becoming very dependent upon software. Our
transport systems, financial systems, medical systems and defense
systems all depend to a very large degree upon software. As a
consequence the safety of many human lives and much property now
depends upon the reliable functioning of software. Moreover, the
fall in the cost of hardware has now made possible the development
of large software systems.
Ada is a programming language of special value in the development
of large programs which must work reliably. [...] Ada is a modern
programming language suitable for those application areas which
benefit from the discipline of organized development, that is,
Software Engineering; it is a general purpose language with special
applicability to real-time and embedded systems. [...]
Although Ada was originally designed to provide a single flexible
yet portable language for real-time embedded systems to meet the
needs of the US DoD, its domain of application has expanded to
include many other areas, such as large-scale information systems,
distributed systems, scientific computation, and systems
programming. Furthermore, its user base has expanded to include all
major defense agencies of the Western world, the whole of the
aerospace community and increasingly many areas in civil and
private sectors such as telecommunications, process control and
monitoring systems. Indeed, the expansion in the civil sector is
such that civil applications now generate the dominant revenues of
many vendors.
(from "Ada 95 Rationale: The Language, The Standard Libraries",
John Barnes (ed.), Lecture Notes in Computer Science, vol. 1247,
Springer-Verlag, 1997, ISBN 3-540-63143-7)
Ada-Belgium is a non-profit volunteer organization whose purpose is to
promote the use in Belgium of the Ada programming language, the first
ISO standardized object-oriented language.
This Fall, Ada-Belgium will run a course teaching Ada 95, at the
premises of the U.L.B. in Brussels, bi-weekly on Wednesday evenings,
starting on September 23, 1998.
------------------------------------------------------------------------
Highlights
----------
* The course will be modular: you may skip modules discussing
subjects you already know about without losing the thread of the
course. The first module will be an introduction to Ada for
programmers in other languages. After this the modules will be of
interest to both newcomers to Ada and those already working in Ada
83 who wish to learn Ada 95.
* The course will take the form of evening sessions every two weeks.
There will be small exercises during the evening sessions and
larger exercises which may be completed between sessions. Ada
compilers will be available for the completion of these exercises.
* The course will be taught in English. Everyone interested is
welcome.
More information is available below and at the Ada Course Home Page
via URL
http://www.cs.kuleuven.ac.be/~dirk/ada-belgium/events/local.html
Here you will find:
* the full programme,
* abstracts of the modules,
* free Ada CD-ROMs for Ada-Belgium members,
* documentation that will be handed out,
* the location of the course,
* registration,
* the course secretariat,
* acknowledgements,
* a course registration form,
* an Ada-Belgium membership application form.
This free Ada 95 course is an opportunity not to be missed! Do not
delay to register!
Looking forward to meet many of you in Brussels.
Dirk Craeynest
Ada-Belgium Board
ada@belgium.eu.net
------------------------------------------------------------------------
Programme
---------
Preliminary schedule:
Wed 23 Sep 1998 - Introduction to Ada - part 1
Wed 7 Oct 1998 - Introduction to Ada - part 2
Wed 21 Oct 1998 - Object-Oriented Programming in Ada - part 1
Wed 4 Nov 1998 - Object-Oriented Programming in Ada - part 2
Wed 18 Nov 1998 - Parallel Programming in Ada
Fri 4 Dec 1998 - 8th Annual Ada-Belgium Seminar (tentative)
(a full day event, with a.o. invited speakers and project
presentations; theme: parallelism, tasking, real-time, etc.;
separate registration will be required later)
Wed 16 Dec 1998 - Distributed Programming in Ada
more sessions will be scheduled in 1999
------------------------------------------------------------------------
Abstracts
---------
* "Introduction to Ada"
Marc Gobin, Royal Military Academy, Brussel
(2 sessions; abstract provided by the author)
The introductory course will cover most of the core language, except
for the material covered in the subsequent modules, such as object
oriented features and tasking.
The course will essentially be taught as a sequence of simple programs
showing common aspects of programming in Ada.
We will first walk to the simple predefined types and see how
declarations are controlled.
The power of Ada conditional statements and loop statements will be
illustrated. The introduction of new types and subtypes will be
explained, including arrays, records and pointers.
Procedures and functions will than be introduced, first embedded in
the program itself and than defined outside a program ready to be used
by as many programs as needed. This means the introduction of
packages and exceptions.
The power of generic units will be shown and we will discuss the input
output possibilities of the predefined packages Ada.Text_Io,
Ada.Sequential_Io and Ada.Direct_Io.
References
- John Barnes: "Programming in Ada95, 2nd edition" (Addison Wesley)
- Michael Feldman: "Software Construction and Data structures with
Ada95" (Addison Wesley)
- Michael Feldman & Koffman: "Ada95, Problem solving and program
design" (Addison Wesley)
- Ada 95 Reference Manual (Springer Verlag)
- Ada 95 Rationale (Springer Verlag)
- Ada 95 Style Guide (Springer Verlag)
* "Object-Oriented Programming in Ada"
Luc Bernard, OFFIS nv/sa, Zaventem
(2 sessions; abstract provided by the author)
One of the major contributions of the 95 version of the Ada language
is certainly the way it addresses Object-Oriented Design and
Development.
The two sessions will present how OO concepts have been added to the
language on top of existing ones (types, derivations, etc...). No
particular knowledge of OO is required to follow these sessions since
the basic concepts will be briefly presented.
* "Parallel Programming in Ada"
Raymond Devillers, U.L.B., Bruxelles
(1 session)
Many more programmers are having to work in multi-threaded
environments today: most modern operating systems support threads (or
light-weight processes) to some extent. The problem with threads is
that they are not standard and so are not portable. Every operating
system has a differing set of application programmers' interfaces
(APIs) and frequently differing scheduling and priority rules. Thread
programming is also notoriously difficult to manage in C and difficult
to encapsulate in C++. Neither C nor C++ provides any support for
important issues in multi-threaded programming features such as
re-entrant functions and interprocess communication (IPC).
Unlike C++ Ada defines a model for concurrent programming as part of
the language itself. Few other languages (Occam and Java are
examples) provide language level concurrency; other languages
(Modula-3) provide a concurrency model through the use of standard
library abstractions. In Ada there are two base components: the task
which encapsulates a concurrent process, and the protected type, which
is a data structure that provides guarded access to its data. These
features can be used to develop responsive, high-performance
applications utilizing one of the few truly cross-platform models for
concurrent processing.
The real-time systems annex provides additional facilities for
programming in either a hard or a soft real-time environment. The
main thrust of this annex is to provide programmers of real-time
systems with an environment which provides fixed, predictable
scheduling of tasks and interrupts within an application.
(from "Ada 95 for C and C++ Programmers", Simon Johnston, Addison
Wesley Longman, 1997, ISBN 0-201-40363-3)
* "Distributed Programming in Ada"
Yolande Berbers, K.U.Leuven, Leuven
(1 session)
As presented at the Ada-Belgium'97 Seminar on Developing Distributed
Applications, several different approaches are available. The most
important ones are using CORBA or the Ada 95 distributed systems annex
(or both).
The Ada 95 programming language is a powerful and flexible language
that provides a safe environment for creating reliable software. The
OMG Common Object Request Broker Architecture (CORBA) is a flexible
environment for creating potentially distributed software components.
The marriage of these two technologies results in a uniquely powerful
environment for creating high performance, reliable, distributed
software components.
(from "Ada-Belgium'97 - Call for Participation", Ada-Belgium, 1997)
Ada 95 is the first general-purpose language to provide a standard
distributed programming paradigm. By combining the distributed and
object-oriented features of Ada 95, it is possible to create an
application where objects are physically distributed over a network of
machines, without having to interface to any low-level communication
layer. Likewise, by combining the distributed and real-time
capabilities of Ada 95, it is possible to design applications which
meet real-time constraints in a distributed environment.
GNAT, and more specifically GLADE (GNAT Library for Ada Distributed
Execution), is the first commercial implementation of the distributed
Ada 95 programming model. This implementation allows a distributed
application to run on a network of heterogeneous machines, to support
different network protocols, and to provide replication and
fault-tolerance.
(from "GLADE - Distributed systems in Ada 95", ACT Europe, 1998)
------------------------------------------------------------------------
Free Ada CD-ROMs for Ada-Belgium members
----------------------------------------
Copies of the April 1998 Edition of the Walnut Creek Ada CD-ROM set,
provided by Ada-Belgium through an agreement with the Special Interest
Group on Ada of the ACM (ACM SIGAda), will be freely distributed to
direct Ada-Belgium members attending the course. This CD-ROM set
includes a.o. ports to lots of platforms of the GNU Ada 95 compiler
(GNAT), and Aonix' Ada 95 Compiler and Environment for Windows 95. More
information on this April 1998 CD-ROM edition is available separately.
We still have a small number of another CD-ROM for those direct
Ada-Belgium members (first-come first-served) that couldn't attend the
Ada-Belgium'97 Seminar end of last year. CCI (Competence Center
Informatik GmbH) provided copies of the Ada-Tour Version 2.0i CD-ROM
for distribution at the seminar. This Ada-Tour offers an extensive
introduction to Ada 95 and is targeted to people wanting to find out
more about the language, its foundations and possibilities. More
information is available on the CCI Web-pages (in German).
Documentation
-------------
We will try to provide copies of the presentations at each course
session.
In addition, we still have a small number of documentation sets of the
Ada-Belgium'97 Seminar on Developing Distributed Applications for direct
members not attending the seminar (as availability permits). This set
contains, a.o., a printed copy of the CORBA IDL to Ada 95 mapping
document, thanks to the assistance of DG XII at the European Commission,
printed proceedings with papers related to the presentations, copies of
slides, and additional documents and papers.
------------------------------------------------------------------------
Location
--------
The following concerns the course modules, not the seminar:
* Place:
Universite' Libre de Bruxelles (ULB)
Boulevard du Triomphe
Campus de la Plaine
1050 Brussels
* Room:
"Salle des Professeurs", building NO, 9th level, room NO.9.06.
* Time:
19:00 - 22:00 (including break)
An access plan to the Campus de la Plaine of the U.L.B. is available
via the Ada Course Web-pages. Parking facilities are at access no. 2
(parking Fraiteur, the closest) or no. 4 (parking UAE). You can check
on-line how to get to Brussels and how to reach the V.U.B./U.L.B.
depending on the means of transport you use.
Registration
------------
Advance registration is prefered. Registration is free of charge.
Please return the attached Registration Form as soon as possible.
As mentioned above, for direct Ada-Belgium members registration includes
the option to receive a free copy of the latest edition of the Walnut
Creek double Ada CD-ROM (April 1998), containing a.o. the current
editions of two Ada 95 compilers: the public GNAT distribution from ACT,
for lots of platforms, and the ObjectAda Special Edition from Aonix, for
Windows 95 and NT.
A limited supply of additional material that was distributed at the
Ada-Belgium'97 Seminar is also available fro direct members on their
request (see above and registration form).
Others registering for (a) course module(s) can optionally become
Ada-Belgium members, and hence also receive the free CD-ROMs and
documentation.
Course Secretariat
------------------
Ada-Belgium Secretariat
Attn. Prof. R. Devillers
c/o Universite' Libre de Bruxelles (U.L.B.)
Boulevard du Triomphe / Triomflaan
Campus de la Plaine, CP 212
B-1050 Brussels
Belgium
Phone: (32)-2-650.56.11
Fax: (32)-2-650.56.09
E-mail: ada@belgium.eu.net
WWW: http://www.cs.kuleuven.ac.be/~dirk/ada-belgium/
------------------------------------------------------------------------
Acknowledgements
We would like to thank our sponsors for their continued support of our
activities: John Robinson & Associates, Katholieke Universiteit Leuven
(K.U.Leuven), Koninklijke Militaire School / Ecole Royale Militaire
(K.M.S./E.R.M.), OFFIS nv/sa, Rational Software Corporation, Trasys
nv/sa, and Universite' Libre de Bruxelles (U.L.B.).
------------------------------------------------------------------------
Information on this and other Ada-Belgium events is available on the
Internet at the Ada-Belgium World-Wide-Web pages and is updated
regularly. Check out URL
http://www.cs.kuleuven.ac.be/~dirk/ada-belgium/events/local.html
-- cut here ------- >8 ------- >8 ------- >8 ------- >8 ------- >8 -----
Ada-Belgium Ada Course Registration
________________________________________________________________________
Please mail to or fax to
-------------- ---------
Ada-Belgium Secretariat + 32 (0)2 650.56.09
c/o Universite' Libre de Bruxelles (ULB)
Attn. Prof. R. Devillers or e-mail to
Boulevard du Triomphe / Triomflaan ------------
Campus de la Plaine, CP 212
B - 1050 Brussels, Belgium ada@belgium.eu.net
Personal Information
--------------------
Name __________________________ First name _________________________
Job title / Occupation ________________________________________________
Company / Institution _________________________________________________
Address _______________________________________________________________
________________________________________________________________________
Zip code ______________________ City _______________________________
Country _______________________ E-mail _____________________________
Telephone _____________________ Telefax ____________________________
I want to register, free of charge, for Ada-Belgium's Ada Course that
will take place at the U.L.B. in Brussels, starting in the fall of 1998,
bi-weekly on Wednesday evenings 19:00 - 22:00.
I will attend the following sessions: (Please tick all that apply)
-------------------------------------
___ Wed 23 Sep 1998 - Introduction to Ada - part 1
___ Wed 7 Oct 1998 - Introduction to Ada - part 2
___ Wed 21 Oct 1998 - Object-Oriented Programming in Ada - part 1
___ Wed 4 Nov 1998 - Object-Oriented Programming in Ada - part 2
___ Wed 18 Nov 1998 - Parallel Programming in Ada
___ Wed 16 Dec 1998 - Distributed Programming in Ada
(more sessions will be scheduled in 1999)
Indication of interest (separate registration will be required later):
___ Fri 4 Dec 1998 - 8th Annual Ada-Belgium Seminar (tentative)
(full day event, theme: parallelism, tasking, real-time, etc.)
Membership Status for 1998 (Please tick one item)
--------------------------
___ I am an individual Ada-Belgium member
___ I am appointed contact person of a corporate Ada-Belgium member
___ I want to register as Ada-Belgium member
(please mail or fax an Ada-Belgium membership application form
and pay the appropriate fee)
___ I am not, nor do I want to register as, Ada-Belgium member
(and hence am NOT entitled to the free Ada CD-ROMs and
documention set)
For Ada-Belgium Members Only (Please tick all that apply)
----------------------------
___ I would like to receive a copy of the Walnut Creek Ada CD-ROM set
(latest edition, i.e. April 1998)
___ I would like to receive a copy of the documentation set of the
Ada-Belgium'97 Seminar on Developing Distributed Applications
(as availability permits)
___ I would like to receive a copy of the Ada-Tour CD-ROM that was
handed out at the Ada-Belgium'97 Seminar (release 2.0i, as
availability permits)
Signature _________________________ Date ___________________________
-- cut here ------- >8 ------- >8 ------- >8 ------- >8 ------- >8 -----
1998 Ada-Belgium Membership Application
________________________________________________________________________
Please mail to or fax to
-------------- ---------
Ada-Belgium + 32 (0)2 650 56 09
c/o Universite' Libre de Bruxelles (ULB)
Boulevard du Triomphe
Campus de la Plaine, CP 212
B - 1050 Bruxelles, Belgium Page 1 of _______
Personal Information
--------------------
Name __________________________ First name _________________________
For Corporate Members: Name of Appointed Contact Person
Job title / Occupation ________________________________________________
Company / Institution _________________________________________________
Address _______________________________________________________________
________________________________________________________________________
Zip code ______________________ City _______________________________
Country _______________________ E-mail _____________________________
Telephone _____________________ Telefax ____________________________
The above address is ___ my company address
___ my private address
Membership (Includes Ada-Europe Membership & Benefits Package)
---------- (Please tick one item)
___ Individual Member (annual fee: 1 000 BEF)
___ Corporate Member (annual fee: 5 000 BEF)
___ Student Member (annual fee: 400 BEF)
Payment information (Please tick one item)
-------------------
YES, I agree to pay the appropriate registration fee to Ada-Belgium VZW
___ to account number 979-3829669-17 (Argenta), or
___ to account number 409-9054291-64 (Kredietbank),
if paying from outside Belgium
mentioning "1998 Ada-Belgium Membership"
Ada-related Points of Interest
------------------------------
If you have any specific point of interest, please mention them in
attachment to this form.
Additional Addresses
--------------------
If you know other people or companies in Belgium who are interested
in Ada, please mention their names and addresses in attachment to
this form, and we will contact them with information on Ada-Belgium.
Thank you.
Signature _________________________ Date ___________________________
Attachment ____________________________________________________________
-- cut here ------- >8 ------- >8 ------- >8 ------- >8 ------- >8 -----
^ permalink raw reply [relevance 1%]
* Re: Random access.
@ 1998-08-30 0:00 5% ` Matthew Heaney
0 siblings, 0 replies; 170+ results
From: Matthew Heaney @ 1998-08-30 0:00 UTC (permalink / raw)
"BARDIN Marc" <Marc.Bardin@wanadoo.fr> writes:
> - I need to use direct access file.
> - It's ok to instantiate with static descriptor (i.e : package Dir_Es is new
> Direct_Io (1);). But my need is a dynamic access, i should want to change
> the access size dynamically to read/write exactly number of bytes i want at
> location i wish.
Package Ada.Direct_IO is for homogenous collections. You appear to need
heterogeneous collections, in which case you should look at
Ada.Streams.Stream_IO to see if it meets your needs.
^ permalink raw reply [relevance 5%]
* Re: Multiple instantiation of Ada.Direct_IO
1998-01-28 0:00 12% Multiple instantiation of Ada.Direct_IO Blake Weston
1998-01-28 0:00 7% ` Matthew Heaney
@ 1998-02-01 0:00 11% ` Robert Dewar
1 sibling, 0 replies; 170+ results
From: Robert Dewar @ 1998-02-01 0:00 UTC (permalink / raw)
Blake asks
<<I have a bit of a problem. Basically I am using Ada.Direct_IO to read /
write to a file. The problem being I wish to write records of differing
types to the file, without closing the file and re-opening it.
Ada 95 will not even let me open the same file as two different file_type
variables as this creates a Use Exception error.
Can anybody help?
Thanks
Blake
>>
GNAT fully implements file sharing, but there is a penalty involved in
the use of this feature -- you have to read the section of the manual
on file sharing, and I understand that this is too much of a burden for
many people :-)
to be fair, any approach using file sharing is NOT necessarily portable,
which is why GNAT does not allow it by default!
^ permalink raw reply [relevance 11%]
* Re: Multiple instantiation of Ada.Direct_IO
1998-01-28 0:00 7% ` Matthew Heaney
@ 1998-01-29 0:00 6% ` Nick Roberts
0 siblings, 0 replies; 170+ results
From: Nick Roberts @ 1998-01-29 0:00 UTC (permalink / raw)
Alternatively, I think (no doubt someone will swiftly correct me if I'm
wrong :-) you can get the effect you require by making the record type
discriminated, with a default for each discriminant (so that it is a
'definite' type).
The disadvantage of this method is that, in all likelihood, each record
written in the file will be the size of the biggest possible variant,
regardless of which variant is actually written (so there could be a lot of
wasted space). You may or may not consider this to be a serious problem.
Personally, I would not!
--
== Nick Roberts ================================================
== Croydon, UK ===========================
== ================
== Proprietor, ThoughtWing Software ==========
== Independent Software Development Consultant ======
== Nick.Roberts@dial.pipex.com ====
== Voicemail & Fax +44 181-405 1124 ===
== ==
== I live not in myself, but I become ==
=== Portion of that around me; and to me ==
==== High mountains are a feeling, but the hum ==
======= Of human cities torture.
=========== -- Byron [Childe Harold]
Matthew Heaney <mheaney@ni.net> wrote in article
<mheaney-ya023680002801980909240001@news.ni.net>...
> In article <886003669.3982.0.nnrp-02.9e98a25e@news.demon.co.uk>, "Blake
> Weston" <blake@dedlock.demon.co.uk> wrote:
>
> >Hi there,
> >
> >I have a bit of a problem. Basically I am using Ada.Direct_IO to read /
> >write to a file. The problem being I wish to write records of differing
> >types to the file, without closing the file and re-opening it.
> >
> >Ada 95 will not even let me open the same file as two different
file_type
> >variables as this creates a Use Exception error.
> >
> >Can anybody help?
>
> It sounds like you want to perform heterogeneous I/O. Direct_IO is for
> homogeneous I/O. Try Ada.Stream_I/O instead.
>
> --------------------------------------------------------------------
> Matthew Heaney
> Software Development Consultant
> <mailto:matthew_heaney@acm.org>
> (818) 985-1271
>
^ permalink raw reply [relevance 6%]
* Multiple instantiation of Ada.Direct_IO
@ 1998-01-28 0:00 12% Blake Weston
1998-01-28 0:00 7% ` Matthew Heaney
1998-02-01 0:00 11% ` Robert Dewar
0 siblings, 2 replies; 170+ results
From: Blake Weston @ 1998-01-28 0:00 UTC (permalink / raw)
Hi there,
I have a bit of a problem. Basically I am using Ada.Direct_IO to read /
write to a file. The problem being I wish to write records of differing
types to the file, without closing the file and re-opening it.
Ada 95 will not even let me open the same file as two different file_type
variables as this creates a Use Exception error.
Can anybody help?
Thanks
Blake
^ permalink raw reply [relevance 12%]
* Re: Multiple instantiation of Ada.Direct_IO
1998-01-28 0:00 12% Multiple instantiation of Ada.Direct_IO Blake Weston
@ 1998-01-28 0:00 7% ` Matthew Heaney
1998-01-29 0:00 6% ` Nick Roberts
1998-02-01 0:00 11% ` Robert Dewar
1 sibling, 1 reply; 170+ results
From: Matthew Heaney @ 1998-01-28 0:00 UTC (permalink / raw)
In article <886003669.3982.0.nnrp-02.9e98a25e@news.demon.co.uk>, "Blake
Weston" <blake@dedlock.demon.co.uk> wrote:
>Hi there,
>
>I have a bit of a problem. Basically I am using Ada.Direct_IO to read /
>write to a file. The problem being I wish to write records of differing
>types to the file, without closing the file and re-opening it.
>
>Ada 95 will not even let me open the same file as two different file_type
>variables as this creates a Use Exception error.
>
>Can anybody help?
It sounds like you want to perform heterogeneous I/O. Direct_IO is for
homogeneous I/O. Try Ada.Stream_I/O instead.
--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271
^ permalink raw reply [relevance 7%]
* Re: File handling
@ 1997-10-15 0:00 5% ` Matthew Heaney
0 siblings, 0 replies; 170+ results
From: Matthew Heaney @ 1997-10-15 0:00 UTC (permalink / raw)
In article <343F4BE1.F669CC82@norssi.helsinki.fi>, horn@norssi.helsinki.fi
wrote:
>Is the package Ada.Text_IO only way to handle files?
>Are there procedures like Turbo Pascal's BlockRead and
>BlockWrite in Ada 95?
I haven't done any Turbo Pascal programming in a while, so I'm not sure
what you mean by BlockRead and BlockWrite. But there are other I/O
pacakges in Ada:
Ada.Sequential_IO
Ada.Direct_IO
Ada.Streams.Stream_IO
One of the strengths of Ada is that, by a very deliberate design choice,
I/O wasn't built into the language (they didn't want to marry the language
to I/O technology that would become obsolete in a few years; see the Ada 83
Rationale for the gory details). Yes, Ada comes with predefined I/O
packages (the ones listed above), but if these don't meet your needs then
you can just roll your own I/O package that does what you exactly what you
want.
--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271
^ permalink raw reply [relevance 5%]
* Re: New ada user
@ 1997-05-11 0:00 4% ` Jacob Sparre Andersen
0 siblings, 0 replies; 170+ results
From: Jacob Sparre Andersen @ 1997-05-11 0:00 UTC (permalink / raw)
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1350 bytes --]
od (cnam05@univ-pau.fr) wrote:
| HI!I am a new ada user. I would like to create a database with
| customers adresses, etc... but i really don't know how to manage and
| above all how to start : create records, use them, search for one
| information, etc... Any help is welcome. Thanks
It sounds like you should use the package Ada.Direct_IO, if you plan to map
the database tables to a file.
It's probably a good idea to have a used/not used flag in your record. It
could be done in this way:
type File_Record (In_Use : Boolean := False) is
record
case In_Use is
when True =>
Name : Name_Type;
Address : Address_Type;
when False =>
null;
end case;
end record;
Then you overwrite a record with a File_Record'(In_Use => False) to delete
it.
When you want to insert a new record, you can first look for records, where
In_Use is False, otherwise you'll have to write the new record at the end
of the file.
Greetings,
Jacob
--
Jacob Sparre Andersen http://www.nbi.dk/%7Esparre/
Center for Chaos and Turbulence Studies Phone: (+45) 39 65 53 51
The Niels Bohr Institute (+45) 35 32 53 05
--
G�r dine X-programmer danske - p� 5 minutter: http://www.nbi.dk/~nordfalk/ovs/
^ permalink raw reply [relevance 4%]
* Re: file locking in Ada
@ 1997-03-30 0:00 5% ` Nick Roberts
0 siblings, 0 replies; 170+ results
From: Nick Roberts @ 1997-03-30 0:00 UTC (permalink / raw)
Neil Goodgame <goodganp@aston.ac.uk> wrote in article
<333BB430.BF8@aston.ac.uk>...
> How do perform mutually exclusive file locking in Ada.
>
> Neil Goodgame(goodganp@aston.ac.uk)
I would suggest that this is an operating-system issue.
Are you going to be using I/O packages supplied with your compiler (such as
Ada.Text_IO, Ada.Sequential_IO, and Ada.Direct_IO, for example), or are you
going to develop your own?
In the latter case, you will want to check to see what locking facilities
the operating system provides, and make use of them. In the former case,
you will want to check either the supplied documentation, or, failing that
the supplied source code (if it is supplied) to see: (a) whether the I/O
packages automatically do file locking; (b) whether they provide an option
for file locking; and (c) if so, whether it is adequate for your needs.
Nick.
^ permalink raw reply [relevance 5%]
* Re: How to hide instantiation of Direct_IO?
1997-02-27 0:00 5% ` Norman H. Cohen
@ 1997-03-01 0:00 0% ` Richard Kenner
0 siblings, 0 replies; 170+ results
From: Richard Kenner @ 1997-03-01 0:00 UTC (permalink / raw)
In article <3315A1BF.3C1D@watson.ibm.com> ncohen@watson.ibm.com writes:
>Who said anything about text files? The topic of this discussion is
>direct I/O, and the type Count provided by instances of Ada.Direct_IO.
>Scientific and multimedia applications with data files of potentially
>more than 2 billion items are commonplace.
Not only that, but consider writing an "fsck" in Ada. There the disk
is a single file, and many disks are larger than 2GB.
^ permalink raw reply [relevance 0%]
* Re: How to hide instantiation of Direct_IO?
@ 1997-02-27 0:00 5% ` Norman H. Cohen
1997-03-01 0:00 0% ` Richard Kenner
0 siblings, 1 reply; 170+ results
From: Norman H. Cohen @ 1997-02-27 0:00 UTC (permalink / raw)
Robert Dewar wrote:
> Norman said
>
> <<A 64-bit Count type is quite plausible: In early versions of AIX, one
> of the first needs that arose for 64-bit integers was for file offsets.>>
>
> Sure, but this is for offsets into arbitrary files. I think you are being
> quite unrealistic to assume that anyone would decide that a text file
> might have more than 2 billion lines of text, or a single line longer
> than 2 billion characters.
Who said anything about text files? The topic of this discussion is
direct I/O, and the type Count provided by instances of Ada.Direct_IO.
Scientific and multimedia applications with data files of potentially
more than 2 billion items are commonplace.
--
Norman H. Cohen
mailto:ncohen@watson.ibm.com
http://www.research.ibm.com/people/n/ncohen
^ permalink raw reply [relevance 5%]
* Re: Conceptual Ada Problems
1996-09-29 0:00 4% Conceptual Ada Problems Vasilios Tourloupis
1996-09-29 0:00 0% ` Matthew Heaney
1996-09-29 0:00 0% ` Larry Kilgallen
@ 1996-10-01 0:00 0% ` Dale Stanbrough
2 siblings, 0 replies; 170+ results
From: Dale Stanbrough @ 1996-10-01 0:00 UTC (permalink / raw)
>I have a few questions regarding Ada, which hopefully someone
>will be able to answer:
>
>* Is there some way I would be able to access key fields
> of generic data types (records)?
I presume you mean accessing the fields of a record inside a generic.
Not directly (after all the generic may be instantiated with type
integer, which has no fields!). You can supply a function to access
components of a record for your.
>* Is there some way of storing/retrieving records in an Ada.Direct_IO
> file using key fields of records rather than their location in the file?
No, you have to build up an index yourself. you could save it to disc of
course, rather than building it up each time the program runs.
>* I am not quite sure how to declare functions/procedures as formal
> parameters to a function/procedure.
Declare the subprograms at the library level, and then do...
type func_ptr is access function (required profile) required return type
you can then take the 'access of a subprogram.
>* Also, the Ada compiler complains about some subtype mark being
> required, in declaring an array comprising of generic linked lists.
> Any suggestions on how to overcome this are more than welcome, as
> I have been trying all day, to no avail!
you can't have generic linked lists, only generic packages & subprograms.
you may have a diff. problem to this, but this is all i can make out
of your description.
Dale
^ permalink raw reply [relevance 0%]
* Conceptual Ada Problems
@ 1996-09-29 0:00 4% Vasilios Tourloupis
1996-09-29 0:00 0% ` Matthew Heaney
` (2 more replies)
0 siblings, 3 replies; 170+ results
From: Vasilios Tourloupis @ 1996-09-29 0:00 UTC (permalink / raw)
Dear Ada users,
I have a few questions regarding Ada, which hopefully someone
will be able to answer:
* Is there some way I would be able to access key fields
of generic data types (records)?
* Is there some way of storing/retrieving records in an Ada.Direct_IO
file using key fields of records rather than their location in the file?
* I am not quite sure how to declare functions/procedures as formal
parameters to a function/procedure.
* Also, the Ada compiler complains about some subtype mark being
required, in declaring an array comprising of generic linked lists.
Any suggestions on how to overcome this are more than welcome, as
I have been trying all day, to no avail!
Basically, what I am trying to implement is an hash table with the
ability to save and load records to and from a direct IO file,
respectively. Any other suggestions and/or pointers are more than
welcome.
Thanx in advance,
Bill Tourloupis
+-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+
| Vasilios E. Tourloupis | vasilios@insect.sd.monash.edu.au |
| Dept. of Software Development | vasilios@hestia.sd.monash.edu.au |
| Monash University, | /\ |
| Caulfield East, Vic., 3145 |___________/\ / \_______________|
| Australia | \/ |
+-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+
| Disclaimer: There are some that call me Bill! But I don't know why? |
+-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+
^ permalink raw reply [relevance 4%]
* Re: Conceptual Ada Problems
1996-09-29 0:00 4% Conceptual Ada Problems Vasilios Tourloupis
1996-09-29 0:00 0% ` Matthew Heaney
@ 1996-09-29 0:00 0% ` Larry Kilgallen
1996-10-01 0:00 0% ` Dale Stanbrough
2 siblings, 0 replies; 170+ results
From: Larry Kilgallen @ 1996-09-29 0:00 UTC (permalink / raw)
In article <Pine.GSO.3.93.960929230049.29986A-100000@firefly.sd.monash.edu.au>, Vasilios Tourloupis <vasilios@insect.sd.monash.edu.au> writes:
> * Is there some way of storing/retrieving records in an Ada.Direct_IO
> file using key fields of records rather than their location in the file?
That sounds like an indexed file system, and Ada standards have not
included the specification of such. DEC Ada for VMS includes packages
to access the RMS indexed file system which is already present on that
operating system. I would presume that in other environments which
have an indexed file system Ada vendors likewise supply such packages
so all customers do not have to reinvent the wheel.
One could of course write a portable indexed file system in Ada,
but considering the degree of system-specific optimization generally
provided for indexed file systems, the performance of a portable
system would likely be unsatisfactory.
Larry Kilgallen
^ permalink raw reply [relevance 0%]
* Re: Conceptual Ada Problems
1996-09-29 0:00 4% Conceptual Ada Problems Vasilios Tourloupis
@ 1996-09-29 0:00 0% ` Matthew Heaney
1996-09-29 0:00 0% ` Larry Kilgallen
1996-10-01 0:00 0% ` Dale Stanbrough
2 siblings, 0 replies; 170+ results
From: Matthew Heaney @ 1996-09-29 0:00 UTC (permalink / raw)
In article
<Pine.GSO.3.93.960929230049.29986A-100000@firefly.sd.monash.edu.au>,
Vasilios Tourloupis <vasilios@insect.sd.monash.edu.au> wrote:
>* Is there some way I would be able to access key fields
> of generic data types (records)?
I'm not sure what you mean: Can you be more specific?
>* Is there some way of storing/retrieving records in an Ada.Direct_IO
> file using key fields of records rather than their location in the file?
As far as I know, the only way to retrieve records using Direct_IO all by
itself is via the Index.
Of course, you could create another abstraction the does allow you to
retrieve records via a key field, that is implemented using Direct_IO. You
could keep the key-to-index map in a (smaller) seperate file, so that your
abstraction actually comprises 2 files. When you initialize the
abstraction, it could read into memory the key-to-index file, and during
lookups, use that info to determine the index position of the record in the
direct file.
>* I am not quite sure how to declare functions/procedures as formal
> parameters to a function/procedure.
If you're using Ada 83, then make the package or the subprogram generic:
generic
with procedure P (<args here>);
procedure Generic_Op (<its args here>);
or
generic
with procedure P (...);
package Generic_Ops is
To use it, you instantiate it:
procedure P (...) is ...
procedure Op is new Generic_Op (P);
If you're using Ada 95, then you can still do that, and in addition declare
subprogram pointers:
type P_Access is access procedure (...);
procedure Op (..., P : P_Access);
Then no instantiation is required:
procedure P (...) is ...
Op (... P'Access);
Give me an example of what you want to do.
>* Also, the Ada compiler complains about some subtype mark being
> required, in declaring an array comprising of generic linked lists.
> Any suggestions on how to overcome this are more than welcome, as
> I have been trying all day, to no avail!
Show me the code that doesn't compile, and then I'll be able to tell you why.
Make sure your array comprises an actual type: you don't get a type from a
generic package directly, only from its instantiation:
generic
type T is private;
package Lists is
type List is private;
...
type List_Array is (Positive range <>) of Lists.List; -- not legal Ada
Instantiate first:
package Integer_Lists is new Lists (Integer);
type Integer_List_Array is (Positive range <>) of Integer_Lists.List; -- OK
>Basically, what I am trying to implement is an hash table with the
>ability to save and load records to and from a direct IO file,
>respectively. Any other suggestions and/or pointers are more than
>welcome.
Again, maybe you want to store off the map (hash table) in another file.
Of course, if you are using Ada 95, then you could play around with
Streams_IO. It lets you do heterogeneous storage, so maybe you wouldn't
need 2 separate (homogeneous) file.
>Bill Tourloupis
Matt
--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
mheaney@ni.net
(818) 985-1271
^ permalink raw reply [relevance 0%]
* Re: GNAT NT & Ada.Direct_IO
1995-01-13 15:43 8% CONDIC
@ 1995-01-14 2:35 6% ` David Weller
0 siblings, 0 replies; 170+ results
From: David Weller @ 1995-01-14 2:35 UTC (permalink / raw)
This entire conversation sounds like a plea for somebody to write a
GNAT-FAQ.
Also, IMHO, there is NOTHING wrong with having the last line of a
GNAT error report (just after the ubiquitous "Compilation abandoned")
say:
Problems? Bug reports and pleas for help to: gnat-report@cs.nyu.edu
Just my $0.02 -- now back to my struggle with GNAT...
--
Frustrated with C/C++, Pascal, Fortran? Ada95 _might_ be for you!
For all sorts of interesting Ada95 tidbits, run the command:
"finger dweller@starbase.neosoft.com | more" (or e-mail with "finger" as subj.)
^ permalink raw reply [relevance 6%]
* Re: GNAT NT & Ada.Direct_IO
@ 1995-01-13 15:43 8% CONDIC
1995-01-14 2:35 6% ` David Weller
0 siblings, 1 reply; 170+ results
From: CONDIC @ 1995-01-13 15:43 UTC (permalink / raw)
From: Marin David Condic, 407.796.8997, M/S 731-93
Subject: Re: GNAT NT & Ada.Direct_IO
Original_To: PROFS%"SMTP@PWAGPDB"
Original_cc: CONDIC
Robert Dewar <dewar@CS.NYU.EDU> writes:
>
>I don't want to do it always, that would be too annoying to most users
>I think ??? Of course there is a verbose option now that displays the
>
Lots of products put out copyright notices, product info, etc.
every time they fire up. It may be annoying, but I think most of
us are used to it by now. Besides, on a command line based
application, a couple of lines of output has very little, if any,
impact on your life. (Doesn't really slow anything down, eh?) It
might be better to make this the default mode and include a
-quiet switch, rather than a -verbose switch. That way, you're
sure the user has seen the notice at least once.
>
>I am a little reluctant actually to unconditionally output this on listings,
>because then all students see this message, and we already get too many
>
Well, unfortunately, you can't have it both ways. A well
publicized e-address for registering bug reports, etc. cures the
problem of people not knowing where to send the reports. It will
also have the consequence of increasing the junk-mail.
You might consider having a canned response which is
automatically sent back to every submitter - something like "We
get tons of mail, so we don't have time to answer all the
bonehead questions. Here's a FAQ which will probably point you in
the right direction and we'll ignore you if your question was
addressed in the FAQ. And oh, by the way, check out this file of
closed out bug reports periodically to see if your's was dealt
with - otherwise leave us alone. You should be glad we bothered
to give you any software at all, so bellyaching over our
unwillingness to take a deep personal interest in your piddly
little problems isn't going to do much good. So sit down, stop
your whining and get back to work!"
You might consider making the response a bit more diplomatic. I'm
not destined for an exciting new career in customer relations.
Pax,
Marin
Marin David Condic, Senior Computer Engineer ATT: 407.796.8997
M/S 731-93 Technet: 796.8997
Pratt & Whitney, GESP Internet: CONDICMA@PWFL.COM
P.O. Box 109600 Internet: MDCONDIC@AOL.COM
West Palm Beach, FL 33410-9600
===============================================================================
"If nobody else was violent, I could conquer the whole stupid
planet with a butter knife"
-- Dogbert
===============================================================================
^ permalink raw reply [relevance 8%]
* Re: GNAT NT & Ada.Direct_IO
[not found] <INFO-ADA%95011109284406@VM1.NODAK.EDU>
1995-01-12 13:57 5% ` Robert Dewar
@ 1995-01-12 15:58 5% ` Tom Griest
1 sibling, 0 replies; 170+ results
From: Tom Griest @ 1995-01-12 15:58 UTC (permalink / raw)
In article <INFO-ADA%95011109284406@VM1.NODAK.EDU> CONDIC@PSAVAX.PWFL.COM writes
>>
>[..snip...], but what would be wrong with having the compiler print out an
>identification line or two whenever it is invoked and include all
>the pertinent information about versions, etc. and include the
>"send all bug reports to..." info as well.
>
>Or have this printed out in program listings or when fatal errors
>occur, or...?
>
Most people don't like messages every time the compiler is invoked.
GNAT will print out an identification line, but you have to use the
switch -v (for gcc) and -gnatv (for gnat1). I don't understand
the comment about printing out "send all bug reports to..." on fatal
errors, because GNAT already does this if it detects a compiler bug.
As for user bugs, I don't think you want to send those in do you?
In any case, the LabTek NT release comes with on-line help in the
standard MS ".hlp" file which is invoked by typing "gcc -help"
(If you type in any unrecognized switch, gcc will tell you how
to invoke help.) In the help, there is clear information about
how to submit bug reports. On the title screen click on "What to
do if you have problems". I guess this might be another case of
RTFM?
-Tom
^ permalink raw reply [relevance 5%]
* Re: GNAT NT & Ada.Direct_IO
[not found] <INFO-ADA%95011109284406@VM1.NODAK.EDU>
@ 1995-01-12 13:57 5% ` Robert Dewar
1995-01-12 15:58 5% ` Tom Griest
1 sibling, 0 replies; 170+ results
From: Robert Dewar @ 1995-01-12 13:57 UTC (permalink / raw)
Marin Condic suggests that GNAT display version and bug information etc.
always, in listings, and on errors.
I don't want to do it always, that would be too annoying to most users
I think ??? Of course there is a verbose option now that displays the
version (-gnatv) and it is not a bad idea to make this also print the
send bug information to message. Right now, -gnatv gives:
NYU GNAT Compiler Version 2.01w (C) Copyright NYU, 1992,1993,1994
for example.
We do give full information on submitting bugs if a bomb occurs that we can
intercept. Right now we are not intercepting signals, which is unfortuate,
and we are trying to fix this obvious shortcoming.
Program listings (obtained with the -gnatl option) also contain the version
information, and could perhaps include the send bug information message.
I am a little reluctant actually to unconditionally output this on listings,
because then all students see this message, and we already get too many
messages from beginning students asking us how Ada works :-) This morning
I got a message which roughly said:
"I am very enthusiastic about Ada 9X, and I understand it has object
oriented facilities, can you please email me a complete description
of how these are used".
:-)
^ permalink raw reply [relevance 5%]
* Re: GNAT NT & Ada.Direct_IO
1995-01-09 21:43 6% ` Michael Feldman
@ 1995-01-10 4:55 12% ` Mark Riordan
0 siblings, 0 replies; 170+ results
From: Mark Riordan @ 1995-01-10 4:55 UTC (permalink / raw)
Thanks to Michael Feldman and Robert Dewar for responding to
my question on recompiling Ada.Direct_IO. I see I have some
things to learn about "instantiation".
I now know about gnat-report@cs.nyu.edu and have sent a message
to them.
Regarding the Public Ada Library: in response to email questions
I received, this is available from wuarchive.wustl.edu:/languages/ada.
It appears to be a very substantial library of Ada programs,
with good indexing.
I haven't yet figured out a way to get the "Card Catalog" program
to work under NT. There is a precompiled DOS version which would
probably run under NT, but I want to compile it myself, by golly...
Mark R
^ permalink raw reply [relevance 12%]
* Re: GNAT NT & Ada.Direct_IO
1995-01-09 4:33 14% GNAT NT & Ada.Direct_IO Mark Riordan
1995-01-09 6:07 6% ` Robert Dewar
1995-01-09 6:10 7% ` Robert Dewar
@ 1995-01-09 21:43 6% ` Michael Feldman
1995-01-10 4:55 12% ` Mark Riordan
2 siblings, 1 reply; 170+ results
From: Michael Feldman @ 1995-01-09 21:43 UTC (permalink / raw)
In article <3eqe9u$n0b@msunews.cl.msu.edu>,
Mark Riordan <mrr@scss3.cl.msu.edu> wrote:
>When I run:
>
> gcc -c a-direio.adb
>
>I am surprised to get the message:
>
>"No code generated for Ada.Direct_Io (body) in file a-direio.adb"
Perhaps NYU will answer your question more articulately than I,
but in fact GNAT does not generate code when a _generic_ (like
Direct_IO) is compiled. The syntactic and semantic checking is
done, but the code is not generated till the generic unit is
instantiated.
[snip]
>Incidentally, the reason I'm trying to recompile Ada.Direct_IO
>is that the Public Ada Library Card Catalog program doesn't
>work under GNAT NT. It appears to be choking on a control-Z
>in a binary input file; the direct I/O files are being opened
>in text mode by the Direct_IO package. I'm trying to hack
>around the problem.
Hmmm - better let NYU handle this one. But the "no code generated"
is a normal GNAT message when a generic is compiled.
Have you reported this to gnat-report@cs.nyu.edu? If not, please do.
Mike Feldman
------------------------------------------------------------------------
Michael B. Feldman - chair, SIGAda Education Working Group
Professor, Dept. of Electrical Engineering and Computer Science
The George Washington University - Washington, DC 20052 USA
202-994-5919 (voice) - 202-994-0227 (fax) - mfeldman@seas.gwu.edu (Internet)
------------------------------------------------------------------------
One, two, three ways an underdog: Ada fan, Mac fan, Old Liberal Democrat
------------------------------------------------------------------------
Ada on the World-Wide Web: http://lglwww.epfl.ch/Ada/
------------------------------------------------------------------------
^ permalink raw reply [relevance 6%]
* Re: GNAT NT & Ada.Direct_IO
1995-01-09 4:33 14% GNAT NT & Ada.Direct_IO Mark Riordan
1995-01-09 6:07 6% ` Robert Dewar
@ 1995-01-09 6:10 7% ` Robert Dewar
1995-01-09 21:43 6% ` Michael Feldman
2 siblings, 0 replies; 170+ results
From: Robert Dewar @ 1995-01-09 6:10 UTC (permalink / raw)
Note incidentally that it is generally "not permitted" to recompile
children of Ada, Interfaces and System, in accordance with the permission
in the RM.
This restriction can be bypassed by the use of the -gnatg option, but then
you must follow the GNAT style restrictions (documented in the body of
the module style.adb)
^ permalink raw reply [relevance 7%]
* Re: GNAT NT & Ada.Direct_IO
1995-01-09 4:33 14% GNAT NT & Ada.Direct_IO Mark Riordan
@ 1995-01-09 6:07 6% ` Robert Dewar
1995-01-09 6:10 7% ` Robert Dewar
1995-01-09 21:43 6% ` Michael Feldman
2 siblings, 0 replies; 170+ results
From: Robert Dewar @ 1995-01-09 6:07 UTC (permalink / raw)
Mark, please be sure to send basic questions like this to gnat-report
where they will get answered immediately.
THe answer to your question about direct_io is trivial, it is a generic unit,
and compiling generic units, like compiling specs, with GNAT does not
generate code.
It is only when a generic is instantiated that code is generated.
Actually in the case of generics, but not package specs, it is conceivable
that this will change in the future. Note also that there is a current
bug which causes a null object file to be generated for generics.
But anyway, the bottom line for the moment is use the -gnatc when
compiling generics, since no code is generated. THe only reason for
compiling a generic unit like direct_io is to check it out semantically.
P.S. the capitlization is because this particular error message always
generates mixed case output. It is too much trouble to copy the actual
capitalization from he source in this particular case.
^ permalink raw reply [relevance 6%]
* GNAT NT & Ada.Direct_IO
@ 1995-01-09 4:33 14% Mark Riordan
1995-01-09 6:07 6% ` Robert Dewar
` (2 more replies)
0 siblings, 3 replies; 170+ results
From: Mark Riordan @ 1995-01-09 4:33 UTC (permalink / raw)
I have been using GNAT NT 2.0c to try to recompile the
file a-direio.adb, which is the package body Ada.Direct_IO.
When I run:
gcc -c a-direio.adb
I am surprised to get the message:
"No code generated for Ada.Direct_Io (body) in file a-direio.adb"
[The non-capitalization of _Io is interesting, but that's just
a passing point.]
Other Ada bodies generally compile OK. I suspect that the
problem here is my trying to compile an "Ada." package, but I
don't know why that's a problem.
Incidentally, the reason I'm trying to recompile Ada.Direct_IO
is that the Public Ada Library Card Catalog program doesn't
work under GNAT NT. It appears to be choking on a control-Z
in a binary input file; the direct I/O files are being opened
in text mode by the Direct_IO package. I'm trying to hack
around the problem.
Thanks for any help,
Mark R a newcomer to Ada
^ permalink raw reply [relevance 14%]
Results 1-170 of 170 | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
1995-01-09 4:33 14% GNAT NT & Ada.Direct_IO Mark Riordan
1995-01-09 6:07 6% ` Robert Dewar
1995-01-09 6:10 7% ` Robert Dewar
1995-01-09 21:43 6% ` Michael Feldman
1995-01-10 4:55 12% ` Mark Riordan
[not found] <INFO-ADA%95011109284406@VM1.NODAK.EDU>
1995-01-12 13:57 5% ` Robert Dewar
1995-01-12 15:58 5% ` Tom Griest
1995-01-13 15:43 8% CONDIC
1995-01-14 2:35 6% ` David Weller
1996-09-29 0:00 4% Conceptual Ada Problems Vasilios Tourloupis
1996-09-29 0:00 0% ` Matthew Heaney
1996-09-29 0:00 0% ` Larry Kilgallen
1996-10-01 0:00 0% ` Dale Stanbrough
1997-02-11 0:00 How to hide instantiation of Direct_IO? Dale Stanbrough
1997-02-20 0:00 ` Norman H. Cohen
1997-02-22 0:00 ` Robert Dewar
1997-02-25 0:00 ` Norman H. Cohen
1997-02-25 0:00 ` Robert Dewar
1997-02-27 0:00 5% ` Norman H. Cohen
1997-03-01 0:00 0% ` Richard Kenner
1997-03-28 0:00 file locking in Ada Neil Goodgame
1997-03-30 0:00 5% ` Nick Roberts
1997-04-21 0:00 New ada user od
1997-05-11 0:00 4% ` Jacob Sparre Andersen
1997-10-11 0:00 File handling Hannu �rn
1997-10-15 0:00 5% ` Matthew Heaney
1998-01-28 0:00 12% Multiple instantiation of Ada.Direct_IO Blake Weston
1998-01-28 0:00 7% ` Matthew Heaney
1998-01-29 0:00 6% ` Nick Roberts
1998-02-01 0:00 11% ` Robert Dewar
1998-08-29 0:00 Random access BARDIN Marc
1998-08-30 0:00 5% ` Matthew Heaney
1998-09-10 0:00 1% Learn Ada 95! - Free Ada-Belgium course starts 98/09/23 Dirk Craeynest
1999-07-01 0:00 Elimination of "use" clauses Dr. Neil C. Audsley
1999-07-02 0:00 ` Robert Dewar
1999-07-02 0:00 ` Samuel T. Harris
1999-07-02 0:00 ` Robert Dewar
[not found] ` <7ltl2q$mog$1@nnrp1.deja.com>
1999-07-08 0:00 ` Michael F. Yoder
1999-07-09 0:00 ` Robert Dewar
1999-07-09 0:00 ` Dale Stanbrough
1999-07-12 0:00 ` Robert Dewar
1999-07-12 0:00 5% ` Ted Dennison
1999-07-21 0:00 Binary File Manip. - Possibly a stupid question Matthew
1999-07-20 0:00 5% ` Ted Dennison
2000-09-28 0:00 File I/O stiletto
2000-09-29 3:15 6% ` tmoran
2000-10-18 1:11 7% Booch components Alexey V. Litvinov
2000-10-18 0:00 0% ` Simon Wright
2001-01-21 21:30 1% Learn Ada! - Free Ada-Belgium course starts Jan 24 Dirk Craeynest
2001-03-13 0:35 text_io is not a predefined library Andrew Busolin
2001-03-13 4:54 ` DuckE
2001-03-13 10:47 7% ` David C. Hoos, Sr.
2001-03-31 14:49 Streams in Ada chris.danx
2001-03-31 20:48 5% ` James Rogers
2001-04-02 14:00 0% ` Ted Dennison
2001-06-11 17:44 5% Circular type definition problem Charles Hixson
2001-06-11 20:16 8% ` Martin Dowie
2001-06-11 21:18 8% ` Charles Hixson
2001-06-20 15:01 Looping over a tagged record? M. A. Alves
2001-06-21 17:08 3% ` Charles Hixson
2001-07-12 8:42 4% Direct_IO problem -- generic package problem Magnus Sparf
2001-07-12 9:19 0% ` nicolas
2001-07-12 11:38 0% ` David C. Hoos, Sr.
2001-07-12 12:14 0% ` nicolas
2001-07-12 11:41 0% ` Magnus Sparf
2001-07-12 11:33 0% ` David C. Hoos, Sr.
2001-07-12 16:58 7% ` Jeffrey Carter
2001-07-12 19:23 5% ` tmoran
2001-07-13 8:16 0% ` Magnus Sparf
2001-08-09 23:19 implementation question about writing and reading from files Francis Crick
2001-08-10 0:55 6% ` tmoran
2001-12-13 3:23 List Container Strawman 1.4 Ted Dennison
2001-12-13 23:02 ` Nick Roberts
2001-12-14 15:19 ` Ted Dennison
2001-12-15 1:20 1% ` Nick Roberts
2001-12-15 20:29 0% ` Ted Dennison
2001-12-16 18:45 2% ` Nick Roberts
2002-01-05 12:01 Ada way to read/write to character file Michael Bode
2002-01-07 15:13 ` Alfred Hilscher
2002-01-09 0:04 5% ` Nick Roberts
2002-03-12 20:40 7% Resize / Truncate Direct_IO file John Cupak
[not found] <mailman.1031406782.31963.comp.lang.ada@ada.eu.org>
2002-09-07 15:32 5% ` Diffrence between a sequential binairies file and direct binairies file Nick Roberts
2002-10-09 11:58 6% Creating tempfile takes too long: GNAT or Windows bug? Mário Amado Alves
2003-06-02 16:35 Adding "()" operator to Ada 200X Frank J. Lhota
2003-06-02 23:42 ` Matthew Heaney
2003-06-03 14:59 ` Frank J. Lhota
2003-06-03 16:04 ` Martin Krischik
2003-06-04 17:28 ` Matthew Heaney
2003-06-04 18:21 ` Frank J. Lhota
2003-06-05 1:15 ` Robert I. Eachus
2003-06-05 14:59 7% ` Frank J. Lhota
2004-01-12 17:53 3% The "()" operator revisited Frank J. Lhota
2004-01-12 18:38 0% ` Frank J. Lhota
2004-03-06 19:09 abstract sub programs overriding Marius Amado Alves
2004-03-07 12:35 ` Simon Wright
2004-03-08 19:08 ` Adam Beneschan
2004-03-08 20:03 ` Hyman Rosen
2004-03-09 8:51 ` Dmitry A. Kazakov
2004-03-09 13:34 ` Hyman Rosen
2004-03-09 14:49 ` Dmitry A. Kazakov
2004-03-09 15:14 ` Hyman Rosen
2004-03-09 15:56 ` Dmitry A. Kazakov
2004-03-09 16:32 ` Hyman Rosen
2004-03-10 9:32 ` Dmitry A. Kazakov
2004-03-10 13:08 ` Hyman Rosen
2004-03-10 14:58 4% ` Robert I. Eachus
2004-07-15 17:27 reading a text file into a string zork
2004-07-16 2:26 8% ` Steve
2004-07-16 21:19 0% ` Randy Brukardt
2004-07-20 21:25 6% Stack overflow using Xml/Ada Jano
2005-03-01 9:30 5% Advanced file manipulation (multiple question) Steph-ADA
2005-03-01 9:59 0% ` Peter Hermann
2005-03-01 12:18 0% ` Larry Kilgallen
2005-03-01 17:49 0% ` Jeffrey Carter
2005-03-02 2:42 8% ` Steve
2005-03-02 10:31 0% ` Steph-ADA
2005-03-03 3:12 0% ` Steve
2005-03-02 16:56 0% ` Jeffrey Carter
2005-03-19 16:22 Ada bench Pascal Obry
2005-03-19 16:55 ` Dr. Adrian Wrigley
2005-03-19 21:32 ` Michael Bode
2005-03-20 9:20 ` Pascal Obry
2005-03-21 23:27 ` Georg Bauhaus
2005-03-22 1:16 7% ` Ada bench : count words Marius Amado Alves
2005-03-22 10:59 0% ` Dmitry A. Kazakov
2005-03-22 11:57 0% ` Marius Amado Alves
2005-03-22 12:17 0% ` Dmitry A. Kazakov
2005-03-22 13:58 0% ` Robert A Duff
2005-03-22 12:22 0% ` Jeff C
2005-05-26 17:20 5% Direct_IO and files of tagged types John McCormick
2005-05-26 18:22 0% ` Dmitry A. Kazakov
2005-05-26 23:51 0% ` Randy Brukardt
2005-05-27 8:38 0% ` Dmitry A. Kazakov
2005-06-15 9:57 Data table text I/O package? Jacob Sparre Andersen
2005-06-15 11:43 ` Preben Randhol
2005-06-15 13:35 ` Jacob Sparre Andersen
2005-06-15 14:12 ` Preben Randhol
2005-06-15 15:02 ` Jacob Sparre Andersen
2005-06-15 18:58 ` Randy Brukardt
2005-06-16 9:55 ` Jacob Sparre Andersen
2005-06-16 10:53 ` Marius Amado Alves
2005-06-16 14:01 ` Georg Bauhaus
2005-06-16 12:27 ` Dmitry A. Kazakov
2005-06-16 14:46 ` Georg Bauhaus
2005-06-16 14:51 ` Dmitry A. Kazakov
2005-06-20 11:19 ` Georg Bauhaus
2005-06-20 11:39 ` Dmitry A. Kazakov
2005-06-20 18:25 ` Georg Bauhaus
2005-06-20 18:54 ` Dmitry A. Kazakov
2005-06-21 9:24 ` Georg Bauhaus
2005-06-21 9:52 ` Jacob Sparre Andersen
2005-06-21 11:10 ` Georg Bauhaus
2005-06-21 12:35 5% ` Jacob Sparre Andersen
2007-09-19 21:33 Concatenating files mhamel_98
2007-09-20 13:11 ` gautier_niouzes
2007-09-22 17:38 ` mhamel_98
2007-09-22 20:07 5% ` Jeffrey R. Carter
2007-09-22 22:51 0% ` mhamel_98
2007-09-23 1:45 5% ` Jeffrey R. Carter
2007-12-10 21:37 5% Ada.Directories.Size wraps on over 2Gb files gpriv
2007-12-10 21:38 5% gpriv
2008-03-08 21:22 Files and controlled types Maciej Sobczak
2008-03-09 3:12 5% ` Jeffrey R. Carter
2008-03-09 13:27 0% ` Maciej Sobczak
2008-03-10 15:37 0% ` Adam Beneschan
2008-03-09 16:39 0% ` gpriv
2008-10-07 15:24 5% Stability of GNAT.Directory_Operations Maciej Sobczak
2008-10-07 16:24 0% ` Jean-Pierre Rosen
2008-11-22 19:51 GNAT Pro for .NET george.priv
2008-11-26 7:05 3% ` Brad Moore
2008-11-29 20:07 0% ` george.priv
2009-01-01 11:16 Ada.Directories problems, a summary Dmitry A. Kazakov
2009-01-01 20:41 3% ` anon
2009-05-04 9:08 How to exit an Ada program with (unix shell) error code? reinkor
2009-05-06 15:28 ` Adam Beneschan
2009-05-07 9:08 3% ` anon
2009-05-25 19:13 Large files on 32 and 64 bits ystem Olivier Scalbert
2009-05-26 0:49 5% ` anon
2009-08-01 17:53 Interpretation of extensions different from Unix/Linux? vlc
2009-08-02 17:13 ` Jacob Sparre Andersen
2009-08-04 11:31 ` vlc
2009-08-04 11:44 ` Jacob Sparre Andersen
2009-08-04 11:57 ` Georg Bauhaus
2009-08-04 13:43 ` Dmitry A. Kazakov
2009-08-14 4:33 5% ` Randy Brukardt
2009-08-14 7:37 0% ` Dmitry A. Kazakov
2009-09-01 1:28 Null Range in Unconstrasined Array Rick
2009-09-01 14:50 ` Adam Beneschan
2009-09-01 15:34 ` Robert A Duff
2009-09-06 12:11 ` Peter C. Chapin
2009-09-06 12:41 ` Robert A Duff
2009-09-08 17:54 4% ` Adam Beneschan
2009-09-09 8:35 0% ` Stephen Leake
2009-09-09 13:00 0% ` Robert A Duff
2009-09-09 19:22 0% ` sjw
2009-09-10 23:24 0% ` Stephen Leake
2009-10-24 22:07 Preferred way to do binray I/O on standard input/output stream Hibou57 (Yannick Duchêne)
2009-10-24 22:57 5% ` Jeffrey R. Carter
2010-08-20 23:23 Binary opperations under Ada? Trogdor
2010-08-21 0:17 5% ` Jeffrey Carter
2010-11-17 4:44 13% Encapsulating Ada.Direct_IO Bryan
2010-11-17 5:20 5% ` Adam Beneschan
2010-11-26 15:31 6% ` Bryan
2010-11-17 12:25 12% ` Peter C. Chapin
2010-11-18 1:16 7% ` Randy Brukardt
2010-11-18 2:21 6% ` Peter C. Chapin
2010-11-18 16:36 6% ` Adam Beneschan
2010-11-18 18:21 5% ` Peter C. Chapin
2010-11-18 18:36 5% ` Randy Brukardt
2010-11-18 19:48 7% ` Adam Beneschan
2010-11-18 20:15 6% ` Dmitry A. Kazakov
2010-11-18 7:39 7% ` AdaMagica
2010-11-18 18:38 6% ` Randy Brukardt
2010-11-18 9:46 6% ` Maciej Sobczak
2010-11-18 16:31 3% ` Adam Beneschan
2010-11-18 17:05 7% ` Dmitry A. Kazakov
[not found] ` <ENidndoH8qoqjHvRnZ2dnUVZ_j-dnZ2d@earthlink.com>
2010-11-19 8:24 7% ` Dmitry A. Kazakov
2010-11-19 16:19 6% ` Adam Beneschan
2010-11-18 18:45 4% ` Randy Brukardt
2010-11-24 21:31 7% ` Warren
2010-11-17 22:32 6% ` Yannick Duchêne (Hibou57)
2010-11-17 23:03 7% ` Adam Beneschan
2010-11-17 23:11 7% ` Yannick Duchêne (Hibou57)
2012-03-25 14:28 xor Michael Moeller
2012-03-25 14:01 ` xor Niklas Holsti
2012-03-25 15:16 ` xor Michael Moeller
2012-03-25 19:26 4% ` xor Niklas Holsti
2012-03-27 20:09 0% ` xor Michael Moeller
2012-03-27 19:44 ` xor Dmitry A. Kazakov
2012-03-27 21:16 ` xor Michael Moeller
2012-03-27 22:03 ` xor Georg Bauhaus
2012-03-27 23:50 ` xor Michael Moeller
[not found] ` <bbedne9wdofZyu_SnZ2dnUVZ_hydnZ2d@earthlink.com>
2012-03-28 12:18 ` xor Michael Moeller
2012-03-28 12:48 ` xor Georg Bauhaus
2012-03-28 15:23 ` xor Michael Moeller
2012-03-28 15:58 7% ` xor Niklas Holsti
2012-03-28 17:28 0% ` xor Michael Moeller
2012-03-28 23:25 0% ` xor Randy Brukardt
2012-03-29 5:17 0% ` xor Niklas Holsti
2012-03-29 23:41 0% ` xor Randy Brukardt
2012-03-30 21:53 7% ` xor Niklas Holsti
2012-03-27 19:50 ` xor Randy Brukardt
2012-03-27 21:44 ` xor Michael Moeller
2012-03-27 22:01 7% ` xor Georg Bauhaus
2012-08-03 13:30 Should Inline be private in the private part of a package spec? Georg Bauhaus
2012-08-03 15:51 ` Adam Beneschan
2012-08-03 18:07 ` Robert A Duff
2012-08-06 3:09 ` Randy Brukardt
2012-08-06 14:33 ` Robert A Duff
2012-08-06 15:50 ` Vasiliy Molostov
2012-08-06 17:58 ` Georg Bauhaus
2012-08-06 21:01 ` Vasiliy Molostov
2012-08-06 21:52 ` Georg Bauhaus
2012-08-06 22:10 ` Georg Bauhaus
2012-08-09 21:39 ` Randy Brukardt
2012-08-10 1:49 ` Britt
2012-08-10 3:10 ` Shark8
2012-08-10 7:37 ` Dmitry A. Kazakov
2012-08-10 16:45 ` Shark8
2012-08-11 4:48 5% ` Vasiliy Molostov
2012-08-11 5:12 0% ` Shark8
2012-10-23 19:42 5% Ada.Storage_IO: applied example? Yannick Duchêne (Hibou57)
2012-10-23 20:28 ` Dmitry A. Kazakov
2012-10-24 5:03 ` J-P. Rosen
2012-10-24 7:34 ` Dmitry A. Kazakov
2012-10-24 9:49 ` AdaMagica
2012-10-24 10:28 ` Dmitry A. Kazakov
2012-10-24 11:51 ` Yannick Duchêne (Hibou57)
2012-10-24 14:03 7% ` Georg Bauhaus
2014-03-20 17:00 Generating an XML DOM tree from scratch withXML/Ada 2013 Marc C
2014-03-21 16:12 5% ` J Kimball
2014-09-07 12:58 13% GNAT Ada.Direct_IO bug Dmitry A. Kazakov
2014-09-07 14:28 7% ` Pascal Obry
2014-09-17 16:51 6% Ada vs SQLite3 benchmark Dmitry A. Kazakov
2014-09-17 23:26 0% ` gdotone
2014-09-18 0:16 0% ` Jeffrey Carter
2014-09-18 7:31 0% ` Dmitry A. Kazakov
2014-09-18 5:50 0% ` Georg Bauhaus
2014-09-18 7:27 0% ` Dmitry A. Kazakov
2014-09-18 7:56 ` Georg Bauhaus
2014-09-18 8:08 ` briot.emmanuel
2014-09-18 20:08 8% ` Dmitry A. Kazakov
2014-09-18 17:09 0% ` Pascal Obry
2014-10-16 12:55 7% Gnat Pro Cross compiling Nahro Nadir
2015-03-23 11:56 most efficient method of storing records held in array tonyg
2015-03-23 15:34 5% ` Jeffrey Carter
2016-04-18 18:21 problems parse (large) json file with gnatcoll.json Björn Lundin
2016-04-18 18:51 ` Jeffrey R. Carter
2016-04-18 19:05 5% ` Björn Lundin
2016-04-19 19:48 0% ` Shark8
2016-06-05 23:26 5% An extra CR character when writing to file (in addition to CR LF) John Smith
2017-11-15 14:28 Ada.Real_Time.Time_Last Simon Wright
2017-11-15 20:03 ` Ada.Real_Time.Time_Last Niklas Holsti
2017-11-17 9:20 ` Ada.Real_Time.Time_Last Simon Wright
2017-11-17 21:39 4% ` Ada.Real_Time.Time_Last Niklas Holsti
2017-11-18 13:06 0% ` Ada.Real_Time.Time_Last AdaMagica
2017-11-18 13:18 0% ` Ada.Real_Time.Time_Last Niklas Holsti
2017-11-18 14:00 0% ` Ada.Real_Time.Time_Last AdaMagica
2018-10-04 21:38 A little trouble with very large arrays Shark8
2018-10-05 6:17 5% ` Jacob Sparre Andersen
2020-11-28 3:12 Advent of Code John Perry
2020-12-02 20:51 ` gautier...@hotmail.com
2020-12-02 21:29 ` Max Reznik
2020-12-02 23:04 ` Stephen Leake
2020-12-03 14:52 ` Wendel Wang
2020-12-03 17:20 5% ` Björn Lundin
2020-12-03 17:36 0% ` John Perry
2021-03-22 17:13 surprise data from Ada.Sequential_IO John Perry
2021-03-22 17:40 ` Jeffrey R. Carter
2021-03-22 18:14 ` John Perry
2021-03-22 19:41 ` Jeffrey R. Carter
2021-03-22 20:54 8% ` Niklas Holsti
2021-03-23 9:18 0% ` Jeffrey R. Carter
2021-06-27 19:33 Hi! How I can make _indexed_ stream file Input/Output ? Thanks Daniel Norte Moraes
2021-07-02 20:57 5% ` Shark8
2021-07-05 4:06 0% ` zac brown
2021-07-05 4:06 0% ` zac brown
2023-12-14 23:49 6% spurious error with GNAT 13.2.0 on Intel macOS 17.2 moi
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox