Ada.Directories.Base_Name and dot files

Ada.Directories.Base_Name and dot files

[@ 2009-10-07 12:40 UTC (permalink / raw)]

Hey all,

While working my way through the excellent Ada.Directories package, I've 
stumbled on a minor annoyance: The Base_Name function does not handle 
dot files very gracefully.

Here's an example:

++++
with Ada.Text_IO;
with Ada.Directories;

procedure Dot is
    package IO renames Ada.Text_IO;
    package D renames Ada.Directories;

begin
    IO.Put_Line (Item => "1: " & D.Base_Name (Name => "foo.txt"));
    IO.Put_Line (Item => "2: " & D.Base_Name (Name => ".foo"));
    IO.Put_Line (Item => "3: " & D.Base_Name (Name => ".foo.bar"));
end Dot;
++++

The output I get is this:

++++
1: foo
2:
3: .foo
++++

What I had hoped for, was this:

++++
1: foo
2: .foo
3: .foo
++++

With the current null string solution, you'd have to do some manual 
parsing to get to the actual basename of a dot file.

Instead of returning a null string when the first character is a dot, 
couldn't Base_Name just as well just return the basename *with* the dot, 
because that is the actual basename for a dot file. The dot is part of 
the name.

Is there a good reason for the current behavior?

There's a comment in the body of Base_Name:

++++
--  Look for the last dot in the file name and return the part of the
--  file name preceding this last dot. If the first dot is the first
--  character of the file name, the base name is the empty string.
++++

So it's not like the programmers behind this wasn't aware of dot files, 
they've just opted for a somewhat odd solution, in my humble, and not 
very expert, opinion.  :o)

-- 
Regards,
Thomas L�cke

Email: tl at ada-dk.org
Web: http:ada-dk.org
IRC nick: ThomasLocke

Re: Ada.Directories.Base_Name and dot files

[Yannick Duchêne Hibou57]

Hi Thomas,

There was somewhat similar discuss some times ago :
http://groups.google.com/group/comp.lang.ada/browse_thread/thread/31af760e939556ef?hl=fr#

It seems that your Ada implementation (the behavior is left as
implementation defined in some areas) defines base file name as
everything before the last dot (and the extension is then every thing
after the last dot).

This is something with which I fully agree.

But what about (another question) a full file name like “ my-
page.fr.html ” ? What is the base name ? Can you guess ?

Well, the UNIX basename command will give you something, the Windows
OS will tell you it is “ my-page.fr ” and a web server (not its host
OS) may tell you it is “ my-page ”, because with some convention, fr
and html are both extensions and separated unordered extensions (ex. “
my-page.html.fr ” would be interpreted as the same as“ my-page.fr.html
”). You see how it may be legitimately variable depending on
legitimate conventions ?

Did you run your tests on Windows ? I suppose most of Ada
implementation defined behavior are inspired from that of the host OS
(possibly).

I would like to say : when in any particular area, you need a
particular specification which is not of concerns with the
fundamentals of the language design, don't hesitate to design your own
dedicated package.

You have some strong requirements about what the interpretation of
file names should, and probably can't expect Ada always agree with
this kind of level of details : the best is to design your own
interpretation function.

You known, it appears that a lot of peoples do that (especially with
files by the way), and Ada designed programs are far from only made up
of Ada's standard packages

Re: Ada.Directories.Base_Name and dot files

[@ 2009-10-07 17:06 UTC (permalink / raw)]

Yannick Duch�ne Hibou57 wrote:
> Hi Thomas,
> 
> There was somewhat similar discuss some times ago :
> http://groups.google.com/group/comp.lang.ada/browse_thread/thread/31af760e939556ef?hl=fr#


Very interesting thread. Thank you.


> It seems that your Ada implementation (the behavior is left as
> implementation defined in some areas) defines base file name as
> everything before the last dot (and the extension is then every thing
> after the last dot).
> 
> This is something with which I fully agree.


I guess I had expected a Linux implementation of Ada 2005 to exhibit a 
"proper" understanding of the Unix way of handling files, dot files 
included.



> But what about (another question) a full file name like � my-
> page.fr.html � ? What is the base name ? Can you guess ?
> 
> Well, the UNIX basename command will give you something, the Windows
> OS will tell you it is � my-page.fr � and a web server (not its host
> OS) may tell you it is � my-page �, because with some convention, fr
> and html are both extensions and separated unordered extensions (ex. �
> my-page.html.fr � would be interpreted as the same as� my-page.fr.html
> �). You see how it may be legitimately variable depending on
> legitimate conventions ?


Yes, I understand that.


> Did you run your tests on Windows ? I suppose most of Ada
> implementation defined behavior are inspired from that of the host OS
> (possibly).


I did not run any tests on Windows. I use Windows for gaming, and 
nothing else.  :o)



> I would like to say : when in any particular area, you need a
> particular specification which is not of concerns with the
> fundamentals of the language design, don't hesitate to design your own
> dedicated package.
> 
> You have some strong requirements about what the interpretation of
> file names should, and probably can't expect Ada always agree with
> this kind of level of details : the best is to design your own
> interpretation function.
> 
> You known, it appears that a lot of peoples do that (especially with
> files by the way), and Ada designed programs are far from only made up
> of Ada's standard packages


Yes, as I expected. Some home-grown parsing to assist Ada.Directories 
when special cases occur.

I can live with that.

I guess it just confused me that my GNAT GPL Linux environment was not 
able to handle something as "simple" (note the quotes!) as dot files.

Thank you for your insightful post.

-- 
Regards,
Thomas L�cke

Email: tl at ada-dk.org
Web: http:ada-dk.org
IRC nick: ThomasLocke

Re: Ada.Directories.Base_Name and dot files

[Adam Beneschan]

On Oct 7, 5:40 am, Thomas Løcke <"tl at ada-dk.org"> wrote:
> Hey all,
>
> While working my way through the excellent Ada.Directories package, I've
> stumbled on a minor annoyance: The Base_Name function does not handle
> dot files very gracefully.
>
> Here's an example:
>
> ++++
> with Ada.Text_IO;
> with Ada.Directories;
>
> procedure Dot is
>     package IO renames Ada.Text_IO;
>     package D renames Ada.Directories;
>
> begin
>     IO.Put_Line (Item => "1: " & D.Base_Name (Name => "foo.txt"));
>     IO.Put_Line (Item => "2: " & D.Base_Name (Name => ".foo"));
>     IO.Put_Line (Item => "3: " & D.Base_Name (Name => ".foo.bar"));
> end Dot;
> ++++
>
> The output I get is this:
>
> ++++
> 1: foo
> 2:
> 3: .foo
> ++++
>
> What I had hoped for, was this:
>
> ++++
> 1: foo
> 2: .foo
> 3: .foo
> ++++
>
> With the current null string solution, you'd have to do some manual
> parsing to get to the actual basename of a dot file.
>
> Instead of returning a null string when the first character is a dot,
> couldn't Base_Name just as well just return the basename *with* the dot,
> because that is the actual basename for a dot file. The dot is part of
> the name.
>
> Is there a good reason for the current behavior?
>
> There's a comment in the body of Base_Name:
>
> ++++
> --  Look for the last dot in the file name and return the part of the
> --  file name preceding this last dot. If the first dot is the first
> --  character of the file name, the base name is the empty string.
> ++++
>
> So it's not like the programmers behind this wasn't aware of dot files,
> they've just opted for a somewhat odd solution, in my humble, and not
> very expert, opinion.  :o)


I'm assuming you're using Linux or some other Unix-type system?
Although the exact meanings of the Ada.Directories operations are
implementation-dependent, the AARM gives the "expected interpretation"
on Unix-type and Windows systems.  (AARM A.16(1.a))  AARM A.16(80.a)
says, 'For Unix and Windows®, the base name is the portion of the
simple name preceding the rightmost period (except for the special
directory names "." and "..", whose Base_Name is "." and "..").'

Unlike VAX/VMS, where every file has a definite, separate "base" and
"extension" name (the extension name can be blank), Unix is a lot
looser (and Windows is a little bit looser).  RM A.16(78) says, "The
extension name is a portion of a simple name (not including any
separator characters), typically used to identify the file class."  On
Unix, this is only the case sometimes.  For source files, it's often
true, and also for other files like .o (object) files.  But it's not
consistent.  Executable files don't have an extension.  Files
beginning with a dot are usually "hidden" files with some control
information, and I wouldn't expect them to fall into the "basename-dot-
extension" pattern that other file names fall into.  When I make a
backup copy of a file, I'll often just append .save to the file name,
but I wouldn't consider ".save" to be an extension, and it certainly
doesn't identify the file class.  But I wouldn't expect an application
to read my mind and know that.

So the Base_Name and Extension functions aren't going to be
appropriate for every file name on Unix, since not all Unix files have
definite base names and extensions.  Bottom line: if you know what you
want, just use the string functions and do it yourself.

                                    -- Adam

Re: Ada.Directories.Base_Name and dot files

[@ 2009-10-07 17:06 UTC (permalink / raw)]

Adam Beneschan wrote:
> I'm assuming you're using Linux or some other Unix-type system?


Yes, Slackware Linux.


> Although the exact meanings of the Ada.Directories operations are
> implementation-dependent, the AARM gives the "expected interpretation"
> on Unix-type and Windows systems.  (AARM A.16(1.a))  AARM A.16(80.a)
> says, 'For Unix and Windows�, the base name is the portion of the
> simple name preceding the rightmost period (except for the special
> directory names "." and "..", whose Base_Name is "." and "..").'


Yes, I understand that and it's that exact design decision that made me 
wonder.

If the first character of a file name is a period, why is it then better 
to return a null string as the base name, instead of, for example, the 
period plus any characters following the period, up until the last 
period, ie. ".secret" would yield ".secret" as the base name and 
".secret.conf.save" would yield ".secret.conf"

So I understand what it is doing, I just don't understand why. The null 
string design baffles me.

While writing this, I can though see that the null string sends a pretty 
clear signal to the programmer: This file is not "normal". You should 
probably take a close look at it, and figure out what you want. I guess 
that's actually a pretty good thing. Except on some systems a dot file 
might be completely normal.

Hehe, there's just no winning here!  :D


> Unlike VAX/VMS, where every file has a definite, separate "base" and
> "extension" name (the extension name can be blank), Unix is a lot
> looser (and Windows is a little bit looser).  RM A.16(78) says, "The
> extension name is a portion of a simple name (not including any
> separator characters), typically used to identify the file class."  On
> Unix, this is only the case sometimes.  For source files, it's often
> true, and also for other files like .o (object) files.  But it's not
> consistent.  Executable files don't have an extension.  Files
> beginning with a dot are usually "hidden" files with some control
> information, and I wouldn't expect them to fall into the "basename-dot-
> extension" pattern that other file names fall into.  When I make a
> backup copy of a file, I'll often just append .save to the file name,
> but I wouldn't consider ".save" to be an extension, and it certainly
> doesn't identify the file class.  But I wouldn't expect an application
> to read my mind and know that.


Gotcha!


> So the Base_Name and Extension functions aren't going to be
> appropriate for every file name on Unix, since not all Unix files have
> definite base names and extensions.  Bottom line: if you know what you
> want, just use the string functions and do it yourself.
> 
>                                     -- Adam


Yes, that was also my first thought: Some manual parsing is necessary 
for "special" cases.

Thank you for your reply Adam.  :o)

-- 
Regards,
Thomas L�cke

Email: tl at ada-dk.org
Web: http:ada-dk.org
IRC nick: ThomasLocke

Re: Ada.Directories.Base_Name and dot files

[Adam Beneschan]

On Oct 7, 5:40 am, Thomas Løcke <"tl at ada-dk.org"> wrote:
> Hey all,
>
> While working my way through the excellent Ada.Directories package, I've
> stumbled on a minor annoyance: The Base_Name function does not handle
> dot files very gracefully.
>
> Here's an example:
>
> ++++
> with Ada.Text_IO;
> with Ada.Directories;
>
> procedure Dot is
>     package IO renames Ada.Text_IO;
>     package D renames Ada.Directories;
>
> begin
>     IO.Put_Line (Item => "1: " & D.Base_Name (Name => "foo.txt"));
>     IO.Put_Line (Item => "2: " & D.Base_Name (Name => ".foo"));
>     IO.Put_Line (Item => "3: " & D.Base_Name (Name => ".foo.bar"));
> end Dot;
> ++++
>
> The output I get is this:
>
> ++++
> 1: foo
> 2:
> 3: .foo
> ++++
>
> What I had hoped for, was this:
>
> ++++
> 1: foo
> 2: .foo
> 3: .foo
> ++++
>
> With the current null string solution, you'd have to do some manual
> parsing to get to the actual basename of a dot file.
>
> Instead of returning a null string when the first character is a dot,
> couldn't Base_Name just as well just return the basename *with* the dot,
> because that is the actual basename for a dot file. The dot is part of
> the name.
>
> Is there a good reason for the current behavior?
>
> There's a comment in the body of Base_Name:
>
> ++++
> --  Look for the last dot in the file name and return the part of the
> --  file name preceding this last dot. If the first dot is the first
> --  character of the file name, the base name is the empty string.
> ++++
>
> So it's not like the programmers behind this wasn't aware of dot files,
> they've just opted for a somewhat odd solution, in my humble, and not
> very expert, opinion.  :o)

P.S. For more information, look at the discussion of AI95-248
(http://www.ada-auth.org/cgi-bin/cvsweb.cgi/ais/ai-00248.txt?rev=1.32)
starting at around November 21, 2003 (and a few earlier entries from
July of that year).  There was some discussion of what the best
behavior would be with regard to file names like that.  It was pointed
out that on Windows, a file named ".abc" is treated as any other file
with an extension of .abc---if you open it in Explorer, Windows uses
the "abc" to determine what application to try to open it with.  There
was also some feeling that the rules should be the same on Windows and
Unix, and some feeling that these are marginal cases we shouldn't
worry about, and some feeling that the Base_Name and Extension
functions shouldn't have been there at all.  The resulting solution is
a compromise.  My feeling is still that this is a somewhat "marginal"
case---i.e. many Unix file names don't fall into the base-name/
extension paradigm and it's not sensible to talk about base names or
extensions of such files, so therefore using Base_Name or Extension on
them is likely not to do what you'd expect.

                                   -- Adam

Re: Ada.Directories.Base_Name and dot files

[Yannick Duchêne Hibou57]

On 7 oct, 17:10, Adam Beneschan <a...@irvine.com> wrote:
> It was pointed
> out that on Windows, a file named ".abc" is treated as any other file
> with an extension of .abc
That's a bit less clear on Windows
Windows XP accept the file names as valid on its file system, but the
Explorer does not allow to create such file names, complaining it is
an invalid file name. But it is still able to access it.

Re: Ada.Directories.Base_Name and dot files

[Randy Brukardt]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1003 bytes --]

"Yannick Duch�ne Hibou57" <yannick_duchene@yahoo.fr> wrote in message 
news:a38fc23f-7910-4f3c-afd6-a15669953de1@r36g2000vbn.googlegroups.com...
> On 7 oct, 17:10, Adam Beneschan <a...@irvine.com> wrote:
>> It was pointed
>> out that on Windows, a file named ".abc" is treated as any other file
>> with an extension of .abc
> That's a bit less clear on Windows
> Windows XP accept the file names as valid on its file system, but the
> Explorer does not allow to create such file names, complaining it is
> an invalid file name. But it is still able to access it.

There are lots of ways to create files on Windows that have nothing to do 
with the file explorer (or the file save box). Anyone that writes an Ada 
program to create a file will surely be able to create a file ".abc" if they 
wish. The primary intent of Ada.Directories is that it can handle any file 
that the other Ada I/O packages can open or create (no discussion about 
explorer).

                                      Randy.

Re: Ada.Directories.Base_Name and dot files

[@ 2009-10-07 20:11 UTC (permalink / raw)]

Adam Beneschan wrote:
> P.S. For more information, look at the discussion of AI95-248
> (http://www.ada-auth.org/cgi-bin/cvsweb.cgi/ais/ai-00248.txt?rev=1.32)
> starting at around November 21, 2003 (and a few earlier entries from
> July of that year).  

Nice link!

Thanks a lot Adam. Very interesting reading indeed.

-- 
Regards,
Thomas L�cke

Email: tl at ada-dk.org
Web: http:ada-dk.org
IRC nick: ThomasLocke

Re: Ada.Directories.Base_Name and dot files

[Stephen Leake]

Thomas L�cke <"tl at ada-dk.org"> writes:

> begin
>    IO.Put_Line (Item => "1: " & D.Base_Name (Name => "foo.txt"));
>    IO.Put_Line (Item => "2: " & D.Base_Name (Name => ".foo"));
>    IO.Put_Line (Item => "3: " & D.Base_Name (Name => ".foo.bar"));
> end Dot;
> ++++
>
> The output I get is this:
>
> ++++
> 1: foo
> 2:
> 3: .foo
> ++++
>
> What I had hoped for, was this:
>
> ++++
> 1: foo
> 2: .foo
> 3: .foo
> ++++

Just out of curiosity, what made you hope for this? The Gnu coreutils
basename function doesn't do what you want, either:

$ basename foo.txt
foo.txt
$ basename foo.txt .txt
foo
$ basename .foo
.foo
$ basename .foo .foo
.foo
$ basename .foo.bar
.foo.bar
$ basename .foo.bar .bar
.foo
$ basename .foo.bar .foo
.foo.bar
$ basename .foo.bar .foo.bar
.foo.bar


> With the current null string solution, you'd have to do some manual
> parsing to get to the actual basename of a dot file.

What is your definition of "the actual basename"?

> Is there a good reason for the current behavior?

It's well-defined. And it does what I want :).

-- 
-- Stephe

Re: Ada.Directories.Base_Name and dot files

[@ 2009-10-08 9:58 UTC (permalink / raw)]

Stephen Leake wrote:
> Thomas L�cke <"tl at ada-dk.org"> writes:
> 
>> begin
>>    IO.Put_Line (Item => "1: " & D.Base_Name (Name => "foo.txt"));
>>    IO.Put_Line (Item => "2: " & D.Base_Name (Name => ".foo"));
>>    IO.Put_Line (Item => "3: " & D.Base_Name (Name => ".foo.bar"));
>> end Dot;
>> ++++
>>
>> The output I get is this:
>>
>> ++++
>> 1: foo
>> 2:
>> 3: .foo
>> ++++
>>
>> What I had hoped for, was this:
>>
>> ++++
>> 1: foo
>> 2: .foo
>> 3: .foo
>> ++++
> 
> Just out of curiosity, what made you hope for this? The Gnu coreutils
> basename function doesn't do what you want, either:


Yes, that was actually a typo. I was hoping for the same behavior as 
basename, as shown in your output below.

In my haste, I just forgot to add the .bar part to output line 3: .foo

I was too focused on the second line, where .foo was completely 
eliminated.


> 
> $ basename foo.txt
> foo.txt
> $ basename foo.txt .txt
> foo
> $ basename .foo
> .foo
> $ basename .foo .foo
> .foo
> $ basename .foo.bar
> .foo.bar
> $ basename .foo.bar .bar
> .foo
> $ basename .foo.bar .foo
> .foo.bar
> $ basename .foo.bar .foo.bar
> .foo.bar
> 
> 
>> With the current null string solution, you'd have to do some manual
>> parsing to get to the actual basename of a dot file.
> 
> What is your definition of "the actual basename"?


On my Linux system, my definition of the basename, is the name returned 
by basename.


> 
>> Is there a good reason for the current behavior?
> 
> It's well-defined. And it does what I want :).
> 

I've read the link posted by Adam, and it has made me a lot wiser in 
regards to this issue. I feel I now have a better understanding of why 
Ada.Directories.Base_Name does what it does.

So I guess I now also think that it is both well-defined and that it 
does what I didn't knew I wanted.  :o)

-- 
Regards,
Thomas L�cke

Email: tl at ada-dk.org
Web: http:ada-dk.org
IRC nick: ThomasLocke

Type casting

[Bruno]

Hi, 

I have a small mess with the conversion of numeric types in the
following program 

http://paste.ideaslabs.com/show/q6vOGqlyYJ 

I really do not know how to interpret the operation (E / 2) because
although the operation is composed of two numbers such as "Positive"
outcome can be of type "Float" and, of course, the "Integer" (attribute)
returns an integer but the closest to real number and what 
need my program is that it returns the integer part regardless 
the decimal part. 

I tried creating a small building under the following function 

http://paste.ideaslabs.com/show/7y97bn4G6 

but by requiring Float type parameters for the algorithm does not work 
prev. 

Can anyone shed some light on the conversion rate and the 
problem presented to me? 

Thank you. 

Re: Type casting

[Jeffrey R. Carter]

Bruno wrote:
> 
> I really do not know how to interpret the operation (E / 2) because
> although the operation is composed of two numbers such as "Positive"
> outcome can be of type "Float" and, of course, the "Integer" (attribute)
> returns an integer but the closest to real number and what 
> need my program is that it returns the integer part regardless 
> the decimal part. 

E is Positive, a subtype of Integer, so the expression "E / 2" is an Integer 
expression, and converting it to Integer has no effect. "/" for Integer 
truncates towards zero, which seems to be what you want.

The 'Truncation attribute function for floating-point types provides the integer 
part.

-- 
Jeff Carter
"We call your door-opening request a silly thing."
Monty Python & the Holy Grail
17

Re: Type casting

[Adam Beneschan]

On Oct 26, 12:26 pm, Bruno <brunomend...@gmail.com> wrote:
> Hi,
>
> I have a small mess with the conversion of numeric types in the
> following program
>
> http://paste.ideaslabs.com/show/q6vOGqlyYJ
>
> I really do not know how to interpret the operation (E / 2) because
> although the operation is composed of two numbers such as "Positive"
> outcome can be of type "Float" and, of course, the "Integer" (attribute)
> returns an integer but the closest to real number and what
> need my program is that it returns the integer part regardless
> the decimal part.

No, the outcome of E / 2 cannot be of type float.  In some other
programming languages it can.  But in Ada, if you divide two integers,
the result is an integer and is always truncated downward---the
remainder is thrown away.  In this example, the type conversion
Integer (E/2) is redundant since the result of E/2 is already an
integer.

If you say Integer (Float (E) / 2.0) then the result of the division
would be a float, and it would round *upward* when converting to an
integer (if E is odd).  But that isn't what you want for this
algorithm.

>
> I tried creating a small building under the following function
>
> http://paste.ideaslabs.com/show/7y97bn4G6
>
> but by requiring Float type parameters for the algorithm does not work
> prev.

I'm not sure what you mean.  It looks like this second example was
trying to truncate a float to an integer (toward zero), and it appears
that it works fine.  But you can do the same thing much more easily
with

   return Integer (Float'Truncation (F));

Float'Truncation truncates F to an integer, truncating toward zero,
but it leaves the result as a Float; when you convert that to an
integer, no truncation or rounding is necessary since the result of
Float'Truncation already has an integral value.

Anyway, I'm not sure what about this doesn't work.

Hope this helps,

                                 -- Adam

Conversions

[Bruno]

Hi all,

I have a little problem with a function that "convert" a date, that is a
record type, into a string. To do this I'm using "image" attribute how
can you see in the following code

http://paste.ideaslabs.com/show/5KEJUGcDF

but when run the program and the function is executed a get an
"constraint error". The compiler show me a message that say that the
size is too long but I don't know what to do.

How can I repair this error?

Thanks,

Re: Conversions

[Jeffrey R. Carter]

Bruno wrote:
> 
> I have a little problem with a function that "convert" a date, that is a
> record type, into a string. To do this I'm using "image" attribute how
> can you see in the following code
> 
> http://paste.ideaslabs.com/show/5KEJUGcDF
> 
> but when run the program and the function is executed a get an
> "constraint error". The compiler show me a message that say that the
> size is too long but I don't know what to do.

'Image for an integer type returns the shortest string necessary to represent 
the value, with ' ' added to the front for a positive value and '-' for a 
negative value.

Thus we can get

6   => " 6"
-6  => "-6"
10  => " 10"
-10 => "-10"

For your application (date image), 2-digit day and month numbers are likely; 
their 'Image will not fit in 2 characters.

You can save the 'Image and decide what to do with it:

declare
    Day_Image : constant String := Integer'Image (F.Dia);
begin
    if F.Dia < 10 then
       S (1) := '0';
       S (2) := Day_Image (Day_Image'Last);
    else
       S (1 .. 2) := Day_Image (Day_Image'Last - 1 .. Day_Image'Last);
    end if;
end;

You can also look at the operations in Ada.Text_IO.Integer_IO that write to a 
String parameter.

-- 
Jeff Carter
"We call your door-opening request a silly thing."
Monty Python & the Holy Grail
17

Re: Conversions

[Adam Beneschan]

On Oct 26, 12:27 pm, Bruno <brunomend...@gmail.com> wrote:
> Hi all,
>
> I have a little problem with a function that "convert" a date, that is a
> record type, into a string. To do this I'm using "image" attribute how
> can you see in the following code
>
> http://paste.ideaslabs.com/show/5KEJUGcDF
>
> but when run the program and the function is executed a get an
> "constraint error". The compiler show me a message that say that the
> size is too long but I don't know what to do.

'Image returns a string whose first character is a space if the
argument is not negative.  So if N = 12, then Integer'Image(N) = "
12"---i.e. 3 characters.  That won't fit in the two-character slice
you're trying to put it in, so you get a Constraint_Error.

But just getting rid of the space doesn't work either.  If N = 1, then
Integer'Image(N) = " 1", and if you were able to trim off the space,
the result would be "1", and you'd still get a Constraint_Error.  When
you assign a slice like this, the left and right sides must be the
same length.

There are a number of ways to do what you want, but I'd suggest
looking at the Ada.Strings.Fixed package, especially the Move, Trim,
and Tail routines.

Hope this helps,

                                    -- Adam

Conversions

[Karlene Johnson]

I am trying to convert an Float number to an Integer number, after a
calculation with 2 Float numbers.  Any suggesions on how to convert??

Re: Conversions

[Marin D. Condic]

Karlene Johnson wrote:
> 
> I am trying to convert an Float number to an Integer number, after a
> calculation with 2 Float numbers.  Any suggesions on how to convert??

X  : Float := 1.234 ;
Y  : Integer := 0 ;
....

Y := Integer (X) ; -- Y should now contain the value "1"

There are a number of ways of handling truncation & rounding, but this
is the plain vanilla way to do it. The type name acts as a function to
perform the conversion. However, it only works with "compatible" types.
(You can't for example, convert a String to a Float this way.)

MDC
-- 
=============================================================
Marin David Condic   - Quadrus Corporation -   1.800.555.3393
1015-116 Atlantic Boulevard, Atlantic Beach, FL 32233
http://www.quadruscorp.com/
m c o n d i c @ q u a d r u s c o r p . c o m

***PLEASE REMOVE THE "-NOSPAM" PART OF MY RETURN ADDRESS***

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

"Because that's where they keep the money."
    --  Willie Sutton when asked why he robbed banks. 
=============================================================