Annoying behavior

Annoying behavior

[Laurent]

Hi

Trying to build a program which generates this type of txt files:

<- <ENQ> 28/02/2015-07:58:28
-> <ACK>
<- <STX>
<- <RS>mtrsl|pi1900123456789|p2164|pp907088|p5907088|si|s040330|ssPLAIES|s5PLAIES|ci501
<- <RS>1234|c040330|ctAERO|ta|rtAST-N264|rr10335191|t12|o1esccol|ra|a1tem|a3<=4|a4
<- <RS>S|ra|a1am|a34|a4S|ra|a1amc|a34|a4S|ra|a1tzp|a3<=4|a4S|ra|a1rox|a34|a4S|ra|a1tax|
<- <RS>a3<=1|a4S|ra|a1taz|a3<=1|a4S|ra|a1fep|a3<=1|a4S|ra|a1etp|a3<=0,5|a4S|ra|a1mem|a3
<- <RS><=0,25|a4S|ra|a1an|a3<=2|a4S|ra|a1gm|a3<=1|a4S|ra|a1cip|a3<=0,25|a4S|ra|a1lev|a3
<- <RS><=0,12|a4S|ra|a1tgc|a3<=0,5|a4S|ra|a1fos|a3<=16|a4S|ra|a1ftn|a3<=16|a4S|ra|a1sxt
<- <RS>|a3<=20|a4S|zz|
<- <GS>9c
<- <ETX>
-> <ACK>
<- <EOT> 28/02/2015-07:58:29

For the moment I try to get the part done which generates the content in the middle of the file, the results behind the a1,13 and a4th. Which correspond to the antibiotic LIS code, the MIC and the sensibility.

The annoying behavior (for me, perhaps it is absolutely normal) I get is this while I try to read in the configuration file ( too many drug names to keep entering them manually):

laurent-lutgens-mac-pro-2:Build laurent$ ./generateur_trame_vt2
Begin of reading loop
read name: Amikacine      
read code: am 
read cmi: test    
read sir: S
Begin of reading loop

raised ANTIBIOTIQUES.NAME_TOO_SHORT : antibiotiques.adb:90

So the first antibiotic is read but then something blows up. Has to to with the SIR which is an enumeration. The others are strings. If I remove the SIR's from the config file then all items are read.
I am a bit lost because I don't understand what the reading procedure is getting to fail like this. Putting a Skip_Line behind doesn't help, makes things even worse.

Another strange behavior (for me, perhaps it is absolutely normal) is this one:

laurent-lutgens-mac-pro-2:Build laurent$ ./generateur_trame_vt2
Begin of reading loop
read name: Amikacine      
read code: amk
read cmi: testtest

Begin of reading loop
read name: Augkacine  <-- should be "Aug"
read code: pmk   <-- should be "p"             
read cmi: 123ttest <-- should be "123"

Displaying configuration

Amikacine      
amk
testtest

Augkacine      
pmk
123ttest

If I put spaces behind the name, code and cmi to fill up to the max length of the fields then it doesn't happen. I have a suspicion where this could come from but I am not sure and have no clue how to solve this.

https://github.com/Chutulu/Generateur-Trame-Vitek.git

Thanks

Laurent

Re: Annoying behavior

[gautier_niouzes]

[...]
> So the first antibiotic is read but then something blows up. Has to to with the SIR which is an enumeration. The others are strings. If I remove the SIR's from the config file then all items are read.

So instead of using SIR_Type_IO it is perhaps better to read the SIR like another item, them do Temp_Record.SIR := SIR'Value(item_str). Especially, it's not sure that Enumeration_IO understands the '|'-separated parsing rule.

[...]
> Another strange behavior (for me, perhaps it is absolutely normal) is this one:
> 
> laurent-lutgens-mac-pro-2:Build laurent$ ./generateur_trame_vt2
> Begin of reading loop
> read name: Amikacine      
> read code: amk
> read cmi: testtest
> 
> Begin of reading loop
> read name: Augkacine  <-- should be "Aug"
> read code: pmk   <-- should be "p"             
> read cmi: 123ttest <-- should be "123"

What is happenning is exactly what you have programmed:
 Name (1 .. S'Length) := S;

At some point Name is "Amikacine      "
Then you have S = "Aug", so the 3 first letters are replaced and you get
"Augkacine      ". If you stuff with spaces it will solve the problem.
Either with Name:= (others => ' '); before copying S or
Name(S'Length+1..Name'Last):= (others => ' '); before or after.

HTH
_________________________
Gautier's Ada programming
http://gautiersblog.blogspot.com/search/label/Ada
NB: follow the above link for a valid e-mail address 

Re: Annoying behavior

[Niklas Holsti]

On 15-04-25 00:40 , Laurent wrote:
> Hi
>
> Trying to build a program which generates this type of txt files:

Irrelevant.

> For the moment I try to get the part done which generates the
> content in the middle of the file,

Irrelevant.

> The annoying behavior (for me, perhaps it is absolutely normal) I get
> is this while I try to read in the configuration file

The annoying behaviour (for me) is the way you are asking this 
question... half- :-)

> raised ANTIBIOTIQUES.NAME_TOO_SHORT : antibiotiques.adb:90

You should have showed the part of the program that raises this 
exception, and explained why you think it should NOT happen. Forcing us 
to download code from github is... annoying behaviour. At least, you 
should have put the github link at the start and explained why we should 
go there.

In summary, your configuration file consists of groups of lines of the form:

string Name, read with Text_IO.Get_Line
string Code_SIL, read with Text_IO.Get_Line
string CMI, read with Text_IO.Get_Line
literal SIR, read with an instance of Enumeration_IO.Get.

> So the first antibiotic is read but then something blows up.
> Has to to with the SIR which is an enumeration. The others are
> strings. If I remove the SIR's from the config file then all
> items are read.

This should have pushed you to look at (and show us) how you are reading 
in the SIR, which is with an instance of Enumeration_IO.Get.

> I am a bit lost because I don't understand what the reading
> procedure is getting to fail like this.

Text_IO.Get_Line reads the whole rest of the line, and then skips the 
line terminator.

Enumeration_IO.Get reads an enumeration literal, stops after the 
literal, and does NOT skip the line terminator.

Therefore, the next Get_Line sees only the line terminator, returns a 
null string, and then skips the line terminator. The null string leads 
to raising Name_Too_Short.

> Putting a Skip_Line behind doesn't help, makes things even worse.

Uncommenting your Skip_Line after the SIR_Type_IO.Get works perfectly 
for me, giving the output:

    Begin of reading loop
    read name: Amikacine
    read code: am
    read cmi: test
    read sir: S
    Begin of reading loop
    read name: Augmentin

and so on.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: Annoying behavior

[Laurent]

On Saturday, April 25, 2015 at 6:31:26 AM UTC+2, gautier...@hotmail.com wrote:
 
> What is happenning is exactly what you have programmed:
>  Name (1 .. S'Length) := S;
> 
> At some point Name is "Amikacine      "
> Then you have S = "Aug", so the 3 first letters are replaced and you get
> "Augkacine      ". If you stuff with spaces it will solve the problem.
> Either with Name:= (others => ' '); before copying S or
> Name(S'Length+1..Name'Last):= (others => ' '); before or after.
> 
> HTH
> _________________________
> Gautier's Ada programming
> http://gautiersblog.blogspot.com/search/label/Ada
> NB: follow the above link for a valid e-mail address

Had this type of problem  already just to tired/frustrated to see the cause especially since I got it displayed.

Thanks

Re: Annoying behavior

[Laurent]

On Saturday, April 25, 2015 at 6:50:17 AM UTC+2, Niklas Holsti wrote:
> On 15-04-25 00:40 , Laurent wrote:
> > Hi
> >
> > Trying to build a program which generates this type of txt files:
> 
> Irrelevant.

> > For the moment I try to get the part done which generates the
> > content in the middle of the file,
> 
> Irrelevant.

Point taken. Following this group for some time. Sometimes people get flamed because they don't explain what they wanted to do. 50% probability of doing the wrong thing. 

> You should have showed the part of the program that raises this 
> exception, and explained why you think it should NOT happen. Forcing us 
> to download code from github is... annoying behaviour. 

I don't like to have graffiti smeared all over the screen when I read a message. Especially because there is nothing to differentiate it. No I won't post on StackOverflow.

BTW I would perhaps have been flamed by not providing some compilable code. Again 50%...

<At least, you should have put the github link at the start and explained why we should 
> go there.

Point taken. 

> Enumeration_IO.Get reads an enumeration literal, stops after the 
>literal, and does NOT skip the line terminator. 

Sounds familiar. Had that one already. Thats why I tried the skip_line.

> Uncommenting your Skip_Line after the SIR_Type_IO.Get works perfectly 
> for me, giving the output:

Yes. No idea what I actually tried before, can't be the same I wrote in my OP. After all I am just a noob. 

Getting some sleep before posting this message would have been the easier and less wasting of your/my time. 

Thanks

Laurent

Re: Annoying behavior

[Niklas Holsti]

On 15-04-25 10:15 , Laurent wrote:
> On Saturday, April 25, 2015 at 6:50:17 AM UTC+2, Niklas Holsti wrote:
>> On 15-04-25 00:40 , Laurent wrote:
>>> Hi
>>>
>>> Trying to build a program which generates this type of txt files:
>>
>> Irrelevant.
>
>>> For the moment I try to get the part done which generates the
>>> content in the middle of the file,
>>
>> Irrelevant.
>
> Point taken.

Ok. Well, I could have been kinder, sorry.

> Following this group for some time. Sometimes people
> get flamed because they don't explain what they wanted to do.

Yes, but that usually happens when they ask how to do some particular 
thing in Ada, which is somehow against the Ada style... say, "how can I 
use printf in Ada?" and the answerers would like to know the *real* 
need, to explain how to accomplish that in the Ada way.

You had a problem with reading input, so it is irrelevant what the 
program is expected to output later on.

> I don't like to have graffiti smeared all over the screen
> when I read a message. Especially because there is nothing
> to differentiate it. No I won't post on StackOverflow.
>
> BTW I would perhaps have been flamed by not providing some
> compilable code. Again 50%...

I didn't mean to object to the provision of compilable code, I object to 
having to read your whole post and try to understand it before seeing 
that you are referring to code that is posted elsewhere.

> Sounds familiar. Had that one already. Thats why I tried the skip_line.

Good, you made the right diagnosis and correction.

>> Uncommenting your Skip_Line after the SIR_Type_IO.Get works perfectly
>> for me, giving the output:
>
> Yes. No idea what I actually tried before, can't be the same I
> wrote in my OP.

Often happens when you (or I) have a problem.

I once spent half a day inspecting the code I had written for some 
on-board software for a satellite-born instrument, because the 
validation people assured me that in a certain situation, a certain 
output was 2 and not 1. In the middle of it, having found nothing wrong 
(even in the machine code), I asked them if they were sure that their 
test procedure was correct, and they said yes, because in another 
situation the test reported 1 as expected. I told them that there were 
several variables in the program that had the value 1, at various times, 
and are they sure the were looking at the right variable? No, as it 
turned out...

> After all I am just a noob.

Your code looks pretty good to me, but using fixed-length string types 
for variable-length data needs some care.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: Annoying behavior

[Stephen Leake]

Laurent <daemon2@internet.lu> writes:

> The annoying behavior (for me, perhaps it is absolutely normal) I get
> is this while I try to read in the configuration file ( too many drug
> names to keep entering them manually):
>
> laurent-lutgens-mac-pro-2:Build laurent$ ./generateur_trame_vt2
> Begin of reading loop
> read name: Amikacine      
> read code: am 
> read cmi: test    
> read sir: S
> Begin of reading loop
>
> raised ANTIBIOTIQUES.NAME_TOO_SHORT : antibiotiques.adb:90

You already solved this problem; uncomment the "Skip_Line" on line 157.

SIR_Type_IO.Get does _not_ read the line end, so the next Get_Line on
line 87 will see it, returning a zero length string.

-- 
-- Stephe

Re: Annoying behavior

[Laurent]

On Saturday, April 25, 2015 at 10:10:40 AM UTC+2, Niklas Holsti wrote:

> Ok. Well, I could have been kinder, sorry.

Accepted

> Your code looks pretty good to me, but using fixed-length string types 
> for variable-length data needs some care.

Yes I have to change that. For the LIS it is a quite difference if it gets "am" or "am_". The first one will be accepted because it is the defined code for this drug. The second one will fail because the LIS doesn't know it.

I have found the chapter about bounded strings which looks like what I have to use.

Thanks

Laurent

Re: Annoying behavior

[Laurent]

On Saturday, April 25, 2015 at 3:54:38 PM UTC+2, Stephen Leake wrote:

> You already solved this problem; uncomment the "Skip_Line" on line 157.
> 
> SIR_Type_IO.Get does _not_ read the line end, so the next Get_Line on
> line 87 will see it, returning a zero length string.
> 
> -- 
> -- Stephe

Well not sure if the fact that I had somehow been able to see that "Get" is choking on the line ending would have helped me. Sometimes I am quit blind combined with tunnel vision. Especially frustrating that I already had this error.

Is there some text editor for Mac OS which shows more information about the text file? I am using BBEdit which makes at least the line breaks visible.
Apples Texteditor isn't even able to save the file as txt, only rtf, doc...

Thanks

Laurent

Re: Annoying behavior

[Simon Wright]

Laurent <daemon2@internet.lu> writes:

> Is there some text editor for Mac OS which shows more information
> about the text file? I am using BBEdit which makes at least the line
> breaks visible.

Emacs might do (NB, learning curve ahead!); http://emacsformacosx.com/

Re: Annoying behavior

[Niklas Holsti]

On 15-04-25 18:46 , Laurent wrote:

> Is there some text editor for Mac OS which shows more information
> about the text file? I am using BBEdit which makes at least the
> line breaks visible.

I'm very happy with TextWrangler, but sad that it seems to be available 
only on the Mac.

It has View->Text Display->Show Invisibles which should do what you want.

Get it from http://www.barebones.com/products/textwrangler/

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: Annoying behavior

[Laurent]

> I'm very happy with TextWrangler, but sad that it seems to be available 
> only on the Mac.
> 
> It has View->Text Display->Show Invisibles which should do what you want.
> 

Yes TextWrangler is the free version of BBEdit with less features. A shame that I just misuse it as simple text editor. 

The Show Invisibles isn't bad but I thought more in the direction of <eol> and not this sign which I have no idea how it is called. Probably not necessary at all but better have something you don't need than the opposite.

Which makes me wonder if it matters which line endings I use. Classic Mac is CR, Unix LF and Windows CRLF.

Just tried it. Makes indeed a difference. Which means that if I ever wanted to port my little program to an other OS, I have to think to modify the text file. Failed with a Name_too_short error either before reading the first name or just after.

Something which would make me search for hours to find the error in my code which is correct but it is the stupid text file which causes the problem.

How does the Text_IO "know" which line ending to use? Or is that hidden somewhere inside the compiler or whatever takes care of this kind of stuff. Hm quite clear that I have no idea how compilers, assemblers or all the other system libraries/frameworks work.

Thanks

Laurent

Re: Annoying behavior

[Georg Bauhaus]

On 25.04.15 20:58, Laurent wrote:

> The Show Invisibles isn't bad but I thought more in the direction of <eol> and not this sign which I have no idea how it is called. Probably not necessary at all but better have something you don't need than the opposite.

In case you are a little familiar with a command line interface
to an OS, then on a Mac, open Terminal, and cd to the directory
where your files are stored. Type the "file" command and put a name
of at least one file in question after the program's name. Then,
type ENTER (I have here two files, both having one line with the
word "Hello" on it):

$ file dos.txt unix.txt
dos.txt:  ASCII text, with CRLF line terminators
unix.txt: ASCII text
$

A closer look at what is in a file is possible using the od program
(octal dump) and its -c (character) switch:

$ od -c dos.txt
0000000    H   e   l   l   o  \r  \n
0000007
$

> Which makes me wonder if it matters which line endings I use. Classic Mac is CR, Unix LF and Windows CRLF.
>
> Just tried it. Makes indeed a difference. Which means that if I ever wanted to port my little program to an other OS, I have to think to modify the text file.

One way to distribute text files is in a ZIP: unzip programs typically
feature a switch that allows automatic translation of line endings
when unpacking. The unpacked text files then follow the OS's conventions.


> Something which would make me search for hours to find the error in my code which is correct but it is the stupid text file which causes the problem.
>
> How does the Text_IO "know" which line ending to use?

GNAT's Text_IO works better with lines that follow the OS's conventions
for EOL.

Re: Annoying behavior

[Laurent]

On Saturday, April 25, 2015 at 9:30:43 PM UTC+2, Georg Bauhaus wrote:
> On 25.04.15 20:58, Laurent wrote:
> 
> > The Show Invisibles isn't bad but I thought more in the direction of <eol> and not this sign which I have no idea how it is called. Probably not necessary at all but better have something you don't need than the opposite.
> 
> In case you are a little familiar with a command line interface
> to an OS, then on a Mac, open Terminal, and cd to the directory
> where your files are stored. Type the "file" command and put a name
> of at least one file in question after the program's name. Then,
> type ENTER (I have here two files, both having one line with the
> word "Hello" on it):
> 
> $ file dos.txt unix.txt
> dos.txt:  ASCII text, with CRLF line terminators
> unix.txt: ASCII text
> $
> 
> A closer look at what is in a file is possible using the od program
> (octal dump) and its -c (character) switch:
> 
> $ od -c dos.txt
> 0000000    H   e   l   l   o  \r  \n
> 0000007
> $
> 
> > Which makes me wonder if it matters which line endings I use. Classic Mac is CR, Unix LF and Windows CRLF.
> >
> > Just tried it. Makes indeed a difference. Which means that if I ever wanted to port my little program to an other OS, I have to think to modify the text file.
> 
> One way to distribute text files is in a ZIP: unzip programs typically
> feature a switch that allows automatic translation of line endings
> when unpacking. The unpacked text files then follow the OS's conventions.
> 
> 
> > Something which would make me search for hours to find the error in my code which is correct but it is the stupid text file which causes the problem.
> >
> > How does the Text_IO "know" which line ending to use?
> 
> GNAT's Text_IO works better with lines that follow the OS's conventions
> for EOL.

I rarely use the terminal. Changing the path in my .profile and hunting invisible
files. Running my little programs which read in txt files because otherwise the file won't be found.

The automatic translation by the unzip is good to know.

Have read the man pages for both commands. Didn't know that storing text in files is so complicated. 

Thanks for this info.

Laurent

Re: Annoying behavior

[Laurent]

I figured out how to us bounded strings. Quite a PITA!

Twisted constructions like this:

         Ada.Text_IO.Put_Line ("read code: " 
                               & Codes.To_String (Temp_Record.Code_SIL));

my favorite:

         Ada.Text_IO.Put_Line
           (File => Config_File,
            Item => Names.To_String(Get_Name (Name_Code_Array.Anti_Config (Counter))));

At least it works.

If I need/want to initialize a bounded string to some default value then I have to do this:

           Temp_Record := (Name => Names.To_Bounded_String("Test"),
                                Code_SIL => Codes.To_Bounded_String(" "),
                                        CMI  => CMIs.To_Bounded_String("<0.01"),
                                         SIR  => S);

Is that really necessary or are bounded strings null, empty or whatever by default? Because one of 
my problems was caused by the fact that I didn't reset my Temp_record in the loop.

While first experimenting I uncommented the reset part and it worked. That's why I ask. 
In John Barnes Ada I found the minimum length is 1. So the first reading is ok. But on the following ones:

 if actual string < previous string which is still stored in Temp_Record.Name
then previous str. is replaced by actual str. because it is kind of a new string.

while before with the standard string only the slice which had changed, got replaced

Is that right or complete garbage? 

Thanks

Laurent

Re: Annoying behavior

[Bob Duff]

Georg Bauhaus <bauhaus@futureapps.invalid> writes:

> GNAT's Text_IO works better with lines that follow the OS's conventions
> for EOL.

You can control that with a Form parameter.

- Bob

Re: Annoying behavior

[Jedi Tek'Unum]

On Saturday, April 25, 2015 at 10:46:05 AM UTC-5, Laurent wrote:
> Apples Texteditor isn't even able to save the file as txt, only rtf, doc...

It can. Google TextEdit and "Plain Text". That being said, it is a very very basic editor. I've used some flavor of Emacs for 30+ years.

Re: Textedit and txt

[Laurent]

Thanks for the hint. Why hide that in the preferences? Apple has sometimes strange ideas. Terminal an pico works too. Not really a fan of emacs/aquamacs. Tried once to learn mozart oz as language and they used emacs as ide. Didn't really work for me so I gave up.

Re: Textedit and txt

[brbarkstrom]

On Sunday, April 26, 2015 at 7:52:05 AM UTC-4, Laurent wrote:
> Thanks for the hint. Why hide that in the preferences? Apple has sometimes strange ideas. Terminal an pico works too. Not really a fan of emacs/aquamacs. Tried once to learn mozart oz as language and they used emacs as ide. Didn't really work for me so I gave up.

I'd suggest taking a look at the Reference Manual section on
the Bounded_Strings package.  You can create a default Bounded_String
length in a package (say named Common_Defs.ads) using

  Std_Vstring_Length  : constant :=  256;
  package VString     is new
    Ada.Strings.Bounded.Generic_Bounded_Length(Std_Vstring_Length);

Then, you just with and use Common_Defs.  When you want to create 
a new Bounded_String, you define

  S : Vstring.Bounded_String;

then, when you want to put characters into the string, you can put

  S := Vstring.To_Bounded_String("whatever");

with that, you can append, as in

  S := Vstring.Append(S, " and something else");

get the length of the string

  Length_Of_String := Natural(Vstring.Length(S));

and so on.

This isn't really complicated, although my natural coding style is
quite verbose.  If you use this approach, you should be able to stop
worrying about whether you're working with an Apple or some other kind
of machine.  It's already part of the standard Ada packages.

Bruce B.

Re: Textedit and txt

[Randy Brukardt]

<brbarkstrom@gmail.com> wrote in message 
news:51c639dd-a48c-4130-becd-750cb23094da@googlegroups.com...
On Sunday, April 26, 2015 at 7:52:05 AM UTC-4, Laurent wrote:
>> Thanks for the hint. Why hide that in the preferences? Apple has 
>> sometimes strange ideas. Terminal an pico works too. Not really a fan of 
>> emacs/aquamacs. Tried once to learn mozart oz as language and they used 
>> emacs as ide. Didn't really work for me so I gave up.

>I'd suggest taking a look at the Reference Manual section on
>the Bounded_Strings package.  You can create a default Bounded_String
>length in a package (say named Common_Defs.ads) using
>
>  Std_Vstring_Length  : constant :=  256;
>  package VString     is new
>    Ada.Strings.Bounded.Generic_Bounded_Length(Std_Vstring_Length);

On top of this suggestion, I'd suggest defining the conversion operator (AKA 
unary plus) appropriately:

   function "+" (Right : VString.Bounded_String) return String renames 
VString.To_String;
   function "+" (Right : String) return VString.Bounded_String renames 
VString.To_Bounded_String;

Then you can write:

         Ada.Text_IO.Put_Line ("read code: "
                               & (+Temp_Record.Code_SIL));

instead of:

         Ada.Text_IO.Put_Line ("read code: "
                               & Codes.To_String (Temp_Record.Code_SIL));

Note that some people hate using "+" this way, because they think it has 
something to do with numerics. We really should have something non-specific 
(say an operator "#"), but the ARG is always split between people that think 
we already have such an operator ("+") and thus we don't need another one 
and those that are repulsed by using "+" this way. (Getting these put into 
the packages themselves failed for similar reasons. Grumble.)

In any case, I think Bounded_String and Unbounded_String are unusable 
without these definitions. So you either have to swallow "+" or forget the 
packages altogether. Neither is appealing. (I'd prefer a completely 
different design for both of these packages, so we could add some mechanism 
to allow direct conversions, but that's likely too radical.)

                                   Randy.

Re: Textedit and txt

[Laurent]

On Wednesday, May 6, 2015 at 11:23:36 PM UTC+2, Randy Brukardt wrote:

Hi

I tried to put that package together but I get this error on the second function:

        14:4 no visible subprogram matches the specification for "+"
        14:4 missing specification for "Drop"


with Ada.Strings.Bounded;

package Common_Defs is

   V_String_Length  : constant :=  256;

   package V_String is new
     Ada.Strings.Bounded.Generic_Bounded_Length (V_String_Length);

   function "+" (Right : V_String.Bounded_String) return String
   renames
     V_String.To_String;

   function "+" (Right : String) return V_String.Bounded_String
   ^----- error
   renames
     V_String.To_Bounded_String;

end Common_Defs;

I have no idea what the compiler is complaining about.

> Note that some people hate using "+" this way, because they think it has 
> something to do with numerics. We really should have something non-specific 
> (say an operator "#"), but the ARG is always split between people that think 
> we already have such an operator ("+") and thus we don't need another one 
> and those that are repulsed by using "+" this way. (Getting these put into 
> the packages themselves failed for similar reasons. Grumble.)

Well if it makes life easier why not use it. And if someone does't like to use a '+' then take something else, as long as you remember what it is doing.

>I'd prefer a completely different design for both of these packages, so we could add some >mechanism to allow direct conversions, but that's likely too radical.) 

Why would that be too radical?

Thanks

Laurent

Re: Textedit and txt

[Simon Wright]

Laurent <daemon2@internet.lu> writes:

>    function "+" (Right : String) return V_String.Bounded_String
>    ^----- error
>    renames
>      V_String.To_Bounded_String;

That's because

   function To_Bounded_String (Source : in String;
                               Drop   : in Truncation := Error)
            return Bounded_String;

so you need to do something about Drop.

Unbounded_String wouldn't give you this problem.

I suppose you could write

   function "+" (Right : String) return V_String.Bounded_String
     is (V_String.To_Bounded_String (Right));

(untested)

Re: Textedit and txt

[Laurent]

On Thursday, May 7, 2015 at 11:48:34 PM UTC+2, Simon Wright wrote:
>    function "+" (Right : String) return V_String.Bounded_String
>      is (V_String.To_Bounded_String (Right));
> 
> (untested)

Thanks that works.

But now I am a bit confused:

That one works without specifying the Drop:

V_String.To_Bounded_String (Right))

Because after opening the '(' the drop appears in the parameters.

Thanks

Laurent

Re: Textedit and txt

[Simon Wright]

Laurent <daemon2@internet.lu> writes:

> On Thursday, May 7, 2015 at 11:48:34 PM UTC+2, Simon Wright wrote:
>>    function "+" (Right : String) return V_String.Bounded_String
>>      is (V_String.To_Bounded_String (Right));
>> 
>> (untested)
>
> Thanks that works.
>
> But now I am a bit confused:
>
> That one works without specifying the Drop:
>
> V_String.To_Bounded_String (Right))
>
> Because after opening the '(' the drop appears in the parameters.

It works because it's the Ada 2012 equivalent of

    function "+" (Right : String) return V_String.Bounded_String is
    begin
       return V_String.To_Bounded_String (Right);
    end "+";

in other words To_Bounded_String is called with Drop defaulted to Error.

Re: Textedit and txt

[Laurent]

On Friday, May 8, 2015 at 7:50:30 AM UTC+2, Simon Wright wrote:

Hi

> It works because it's the Ada 2012 equivalent of...

I would be happy if I understood all the possibilities of Ada 95.

> in other words To_Bounded_String is called with Drop defaulted to Error.

Thanks for clarification.

Laurent

Re: Textedit and txt

[Randy Brukardt]

"Laurent" <daemon2@internet.lu> wrote in message 
news:35aabdcd-6064-4999-9cdf-d143b0593a31@googlegroups.com...
> On Wednesday, May 6, 2015 at 11:23:36 PM UTC+2, Randy Brukardt wrote:
...
>>I'd prefer a completely different design for both of these packages, so we 
>>could add some
>>mechanism to allow direct conversions, but that's likely too radical.)
>
> Why would that be too radical?

Well, either we'd modify the existing packages (which would be very 
incompatible, so it would never happen), or we'd have to add new ones. In 
the later case, there would be a lot of opposition because we'd be 
duplicating functionality. If it happened, it would happen because of adding 
something like Root_String'Class to the language; then we'd need packages on 
that type and those would necessarily be new. But I'm not expecting much 
happening on that.

                                   Randy.

Re: Textedit and txt

[brbarkstrom]

On Thursday, May 7, 2015 at 5:12:29 PM UTC-4, Laurent wrote:
> On Wednesday, May 6, 2015 at 11:23:36 PM UTC+2, Randy Brukardt wrote:
> 
> Hi
> 
> I tried to put that package together but I get this error on the second function:
> 
>         14:4 no visible subprogram matches the specification for "+"
>         14:4 missing specification for "Drop"
> 
> 
> with Ada.Strings.Bounded;
> 
> package Common_Defs is
> 
>    V_String_Length  : constant :=  256;
> 
>    package V_String is new
>      Ada.Strings.Bounded.Generic_Bounded_Length (V_String_Length);
> 
>    function "+" (Right : V_String.Bounded_String) return String
>    renames
>      V_String.To_String;
> 
>    function "+" (Right : String) return V_String.Bounded_String
>    ^----- error
>    renames
>      V_String.To_Bounded_String;
> 
> end Common_Defs;
> 
> I have no idea what the compiler is complaining about.
> 
> > Note that some people hate using "+" this way, because they think it has 
> > something to do with numerics. We really should have something non-specific 
> > (say an operator "#"), but the ARG is always split between people that think 
> > we already have such an operator ("+") and thus we don't need another one 
> > and those that are repulsed by using "+" this way. (Getting these put into 
> > the packages themselves failed for similar reasons. Grumble.)
> 
> Well if it makes life easier why not use it. And if someone does't like to use a '+' then take something else, as long as you remember what it is doing.
> 
> >I'd prefer a completely different design for both of these packages, so we could add some >mechanism to allow direct conversions, but that's likely too radical.) 
> 
> Why would that be too radical?
> 
> Thanks
> 
> Laurent

Sorry to go back in the thread.  However, instead of creating a new
symbol '+' to indicate append, it might be easier to consult the Ada
RM.  In section A.4.4 of the Ada 2012 RM, there are a number of overloaded
functions specifically called 'Append'.  Furthermore, the second page of this 
section specifically uses '&' as an append operator.  Since these two 
constructions are already part of the package `Bounded_String', it isn't clear 
what we gain by using a variant construction.

Bruce B.

Re: Textedit and txt

[Laurent]

On Saturday, May 9, 2015 at 1:35:52 AM UTC+2, Randy Brukardt wrote:

> Well, either we'd modify the existing packages (which would be very 
> incompatible, so it would never happen), or we'd have to add new ones. In 
> the later case, there would be a lot of opposition because we'd be 
> duplicating functionality. If it happened, it would happen because of adding 
> something like Root_String'Class to the language; then we'd need packages on 
> that type and those would necessarily be new. But I'm not expecting much 
> happening on that.
> 
>                                    Randy.

I can understand that for compatibility reasons there will be no new package. But on the other side
at a certain point one has to go forward and leave some old things behind. (Apple is a great fan of that. One of the new MacBook Air models has only one USB C connection). Otherwise we would still be using computers based on vacuum tubes or programmed with punch cards or running on DOS.

Just my 2 cents

Laurent

Re: Textedit and txt

[Anh Vo]

On Saturday, May 9, 2015 at 12:25:49 PM UTC-7, Laurent wrote:
> On Saturday, May 9, 2015 at 1:35:52 AM UTC+2, Randy Brukardt wrote:
> 
> > Well, either we'd modify the existing packages (which would be very 
> > incompatible, so it would never happen), or we'd have to add new ones. In 
> > the later case, there would be a lot of opposition because we'd be 
> > duplicating functionality. If it happened, it would happen because of adding 
> > something like Root_String'Class to the language; then we'd need packages on 
> > that type and those would necessarily be new. But I'm not expecting much 
> > happening on that.
> > 
> >                                    Randy.
> 
> I can understand that for compatibility reasons there will be no new package. But on the other side
> at a certain point one has to go forward and leave some old things behind. (Apple is a great fan of that. One of the new MacBook Air models has only one USB C connection). Otherwise we would still be using computers based on vacuum tubes or programmed with punch cards or running on DOS.
> 
Another option is that users create new package. It will not take long to do it.

Anh Vo

Re: Textedit and txt

[Shark8]

On Friday, May 8, 2015 at 5:35:52 PM UTC-6, Randy Brukardt wrote:
> "Laurent" wrote in message 
> news:35aabdcd-6064-4999-9cdf-d143b0593a31 at googlegroups.com...
> > On Wednesday, May 6, 2015 at 11:23:36 PM UTC+2, Randy Brukardt wrote:
> ...
> >>I'd prefer a completely different design for both of these packages, so we 
> >>could add some
> >>mechanism to allow direct conversions, but that's likely too radical.)
> >
> > Why would that be too radical?
> 
> Well, either we'd modify the existing packages (which would be very 
> incompatible, so it would never happen), or we'd have to add new ones. In 
> the later case, there would be a lot of opposition because we'd be 
> duplicating functionality. If it happened, it would happen because of adding 
> something like Root_String'Class to the language; then we'd need packages on 
> that type and those would necessarily be new. But I'm not expecting much 
> happening on that.
> 
>                                    Randy.


Question: Why couldn't we define new string packages and allow the old ones to be placed in [e.g.] Ada.Annex_J.[old-package] with perhaps allowing compilers to rename the Annex_J children within the library as the Strings-packages?

This way we could allow the old stuff to compile with the proper "use deprecated"-flag but be free to introduce better designs in the core/standard library?

Re: Textedit and txt

[Dmitry A. Kazakov]

On Mon, 11 May 2015 10:00:38 -0700 (PDT), Shark8 wrote:

> On Friday, May 8, 2015 at 5:35:52 PM UTC-6, Randy Brukardt wrote:
>> "Laurent" wrote in message 
>> news:35aabdcd-6064-4999-9cdf-d143b0593a31 at googlegroups.com...
>>> On Wednesday, May 6, 2015 at 11:23:36 PM UTC+2, Randy Brukardt wrote:
>> ...
>>>>I'd prefer a completely different design for both of these packages, so we 
>>>>could add some
>>>>mechanism to allow direct conversions, but that's likely too radical.)
>>>
>>> Why would that be too radical?
>> 
>> Well, either we'd modify the existing packages (which would be very 
>> incompatible, so it would never happen), or we'd have to add new ones. In 
>> the later case, there would be a lot of opposition because we'd be 
>> duplicating functionality. If it happened, it would happen because of adding 
>> something like Root_String'Class to the language; then we'd need packages on 
>> that type and those would necessarily be new. But I'm not expecting much 
>> happening on that.
> 
> Question: Why couldn't we define new string packages and allow the old
> ones to be placed in [e.g.] Ada.Annex_J.[old-package] with perhaps
> allowing compilers to rename the Annex_J children within the library as
> the Strings-packages?

We could but since strings cannot be designed *reasonable* in existing Ada,
better leave it as is without introducing more mess than it is already
there.

For strings types hierarchy you need:

1. MD. Since there exist n-ary string operations, e.g. "&".

2. Non-tagged classes, since we don't want statically known strings and
slices having tags.

3. Properly designed indexing operations and abstract array interfaces.
Strings are arrays.

4. Proper MI, since strings must comprise several hierarchies, to reflect
encoding, memory management and other string aspects.

5. Constraint propagation that will remove discriminants and bounds from
statically constrained instances.

6. Parallel types hierarchies to handle convoluted hierarchies of string
types and hierarchies of character types.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Textedit and txt

[Randy Brukardt]

<brbarkstrom@gmail.com> wrote in message 
news:13a13e0e-0de4-4235-9e1e-c6e0446d3f04@googlegroups.com...
> On Thursday, May 7, 2015 at 5:12:29 PM UTC-4, Laurent wrote:
>> On Wednesday, May 6, 2015 at 11:23:36 PM UTC+2, Randy Brukardt wrote:
...

> Sorry to go back in the thread.  However, instead of creating a new
> symbol '+' to indicate append,

Sorry, but "+" here is for conversion to or from type String. It has nothing 
to do with "append".

The problem is that the conversion routine is named To_Bounded_String, which 
is way too long to use in/with complex expressions. And the other way is 
To_String, which is only a bit better. Especially if you are "use-adverse".

The existing "&" work in some cases, but not others (for instance, the call 
to Put in the OPs example). Moreover, they're the reason that the package 
has to be junked, because we cannot have proper string literals and the like 
with them around (that would make everything ambiguous). Avoiding those 
mixed things makes the packages a lot more sane (but then a conversion 
operator is required).

                                      Randy.




it might be easier to consult the Ada
> RM.  In section A.4.4 of the Ada 2012 RM, there are a number of overloaded
> functions specifically called 'Append'.  Furthermore, the second page of 
> this
> section specifically uses '&' as an append operator.  Since these two
> constructions are already part of the package `Bounded_String', it isn't 
> clear
> what we gain by using a variant construction.
>
> Bruce B. 

Re: Textedit and txt

[brbarkstrom]

> ...
> 
> > Sorry to go back in the thread.  However, instead of creating a new
> > symbol '+' to indicate append,
> 
> Sorry, but "+" here is for conversion to or from type String. It has nothing 
> to do with "append".
> 
> The problem is that the conversion routine is named To_Bounded_String, which 
> is way too long to use in/with complex expressions. And the other way is 
> To_String, which is only a bit better. Especially if you are "use-adverse".
> 
> The existing "&" work in some cases, but not others (for instance, the call 
> to Put in the OPs example). Moreover, they're the reason that the package 
> has to be junked, because we cannot have proper string literals and the like 
> with them around (that would make everything ambiguous). Avoiding those 
> mixed things makes the packages a lot more sane (but then a conversion 
> operator is required).
> 
>                                       Randy.
> 
> 
> 
> 
> it might be easier to consult the Ada
> > RM.  In section A.4.4 of the Ada 2012 RM, there are a number of overloaded
> > functions specifically called 'Append'.  Furthermore, the second page of 
> > this
> > section specifically uses '&' as an append operator.  Since these two
> > constructions are already part of the package `Bounded_String', it isn't 
> > clear
> > what we gain by using a variant construction.
> >
> > Bruce B.

"Strings" are complicated.  Sedgewick and Wayne's book on "Algorithms, 
Fourth Edition" devotes about 150 pages to the subject.  Unfortunately,
the book is written in Java and the algorithm descriptions use Java
code.  The authors note that there are at least two abstract data types
that programmers can use to represent strings and warn about "wide API's"
that include so many objects and methods that they're impractical.  Thus
(and perhaps oddly), I agree with Dimity's comments.  I don't agree with
the notion of creating a "deprecated" category of items.  Why copy Java?

Bruce B.

Re: Textedit and txt

[Randy Brukardt]

<brbarkstrom@gmail.com> wrote in message 
news:30d9ad09-ee34-4172-802a-152ab5e797f9@googlegroups.com...
...
> I don't agree with
> the notion of creating a "deprecated" category of items.

Ada has had such a category since Ada 95. See Annex J. So we'd hardly be 
creating it, just adding to it.

I'm not much interested in that; I'd just make a new set of stuff that lives 
alongside the old stuff (I don't see any practical way to get rid of type 
String itself). I'd love to take all of the Wide_Wide_ stuff and toss it 
into the garbage, as no one would ever use that if they had any reasonable 
choice (wastes too much space and time).

The problem is that we're supposed to add Wide_Wide_ support to everything 
that doesn't have it already, and if we do that, everything turns to 
madness. (Do you want to have Wide_Wide_Open in all of the I/O libraries? I 
sure as heck don't.) So the question isn't whether we add a large lump of 
new stuff (that's a given), the question is whether we try to do it sanely 
or just give up and add another thousand things no one will ever use. (The 
Wide_Wide_ stuff is already in that category.)

                                                 Randy.

Re: Textedit and txt

[brbarkstrom]

> ...
> > I don't agree with
> > the notion of creating a "deprecated" category of items.
> 
> Ada has had such a category since Ada 95. See Annex J. So we'd hardly be 
> creating it, just adding to it.
> 
> I'm not much interested in that; I'd just make a new set of stuff that lives 
> alongside the old stuff (I don't see any practical way to get rid of type 
> String itself). I'd love to take all of the Wide_Wide_ stuff and toss it 
> into the garbage, as no one would ever use that if they had any reasonable 
> choice (wastes too much space and time).
> 
> The problem is that we're supposed to add Wide_Wide_ support to everything 
> that doesn't have it already, and if we do that, everything turns to 
> madness. (Do you want to have Wide_Wide_Open in all of the I/O libraries? I 
> sure as heck don't.) So the question isn't whether we add a large lump of 
> new stuff (that's a given), the question is whether we try to do it sanely 
> or just give up and add another thousand things no one will ever use. (The 
> Wide_Wide_ stuff is already in that category.)
> 
>                                                  Randy.

Sounds sensible.

I'll note for general interest that the new Comm. of the ACM has an
article on a legal case that may come up before the Supreme Court with
an argument between Oracle and Google about whether API's can be copyrighted.
Oracle has argued that the API's that give rise to the Java libraries can
be copyrighted; Google argues that they can't [see Sprigman, C. J., 2015:
Oracle v. Google: A High-Stakes Legal Fight for the Software Industry,
CACM, 58, No. 5, 27-29].  The article points out that one of the advantages
of Java (at present) is that developers can become familiar with the libraries
of methods and quickly apply them when they want to write a new application.
If Oracle wins, Oracle will probably want to make the libraries proprietary
and license them.  I suspect that the Ada libraries, particularly those that
are part of the gcc releases, may be less prone to that kind of problem.
However, the case bears watching.

Bruce B.