* Annoying behavior @ 2015-04-24 21:40 Laurent 2015-04-25 4:31 ` gautier_niouzes ` (2 more replies) 0 siblings, 3 replies; 35+ messages in thread From: Laurent @ 2015-04-24 21:40 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Annoying behavior 2015-04-24 21:40 Annoying behavior Laurent @ 2015-04-25 4:31 ` gautier_niouzes 2015-04-25 6:51 ` Laurent 2015-04-25 4:50 ` Niklas Holsti 2015-04-25 13:54 ` Stephen Leake 2 siblings, 1 reply; 35+ messages in thread From: gautier_niouzes @ 2015-04-25 4:31 UTC (permalink / raw) [...] > 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Annoying behavior 2015-04-25 4:31 ` gautier_niouzes @ 2015-04-25 6:51 ` Laurent 0 siblings, 0 replies; 35+ messages in thread From: Laurent @ 2015-04-25 6:51 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Annoying behavior 2015-04-24 21:40 Annoying behavior Laurent 2015-04-25 4:31 ` gautier_niouzes @ 2015-04-25 4:50 ` Niklas Holsti 2015-04-25 7:15 ` Laurent 2015-04-25 13:54 ` Stephen Leake 2 siblings, 1 reply; 35+ messages in thread From: Niklas Holsti @ 2015-04-25 4:50 UTC (permalink / raw) 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 . @ . ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Annoying behavior 2015-04-25 4:50 ` Niklas Holsti @ 2015-04-25 7:15 ` Laurent 2015-04-25 8:10 ` Niklas Holsti 0 siblings, 1 reply; 35+ messages in thread From: Laurent @ 2015-04-25 7:15 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Annoying behavior 2015-04-25 7:15 ` Laurent @ 2015-04-25 8:10 ` Niklas Holsti 2015-04-25 15:37 ` Laurent 0 siblings, 1 reply; 35+ messages in thread From: Niklas Holsti @ 2015-04-25 8:10 UTC (permalink / raw) 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 . @ . ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Annoying behavior 2015-04-25 8:10 ` Niklas Holsti @ 2015-04-25 15:37 ` Laurent 0 siblings, 0 replies; 35+ messages in thread From: Laurent @ 2015-04-25 15:37 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Annoying behavior 2015-04-24 21:40 Annoying behavior Laurent 2015-04-25 4:31 ` gautier_niouzes 2015-04-25 4:50 ` Niklas Holsti @ 2015-04-25 13:54 ` Stephen Leake 2015-04-25 15:46 ` Laurent 2 siblings, 1 reply; 35+ messages in thread From: Stephen Leake @ 2015-04-25 13:54 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Annoying behavior 2015-04-25 13:54 ` Stephen Leake @ 2015-04-25 15:46 ` Laurent 2015-04-25 17:02 ` Simon Wright ` (2 more replies) 0 siblings, 3 replies; 35+ messages in thread From: Laurent @ 2015-04-25 15:46 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Annoying behavior 2015-04-25 15:46 ` Laurent @ 2015-04-25 17:02 ` Simon Wright 2015-04-25 17:41 ` Niklas Holsti 2015-04-26 10:38 ` Jedi Tek'Unum 2 siblings, 0 replies; 35+ messages in thread From: Simon Wright @ 2015-04-25 17:02 UTC (permalink / raw) 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/ ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Annoying behavior 2015-04-25 15:46 ` Laurent 2015-04-25 17:02 ` Simon Wright @ 2015-04-25 17:41 ` Niklas Holsti 2015-04-25 18:58 ` Laurent 2015-04-26 10:38 ` Jedi Tek'Unum 2 siblings, 1 reply; 35+ messages in thread From: Niklas Holsti @ 2015-04-25 17:41 UTC (permalink / raw) 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 . @ . ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Annoying behavior 2015-04-25 17:41 ` Niklas Holsti @ 2015-04-25 18:58 ` Laurent 2015-04-25 19:30 ` Georg Bauhaus 0 siblings, 1 reply; 35+ messages in thread From: Laurent @ 2015-04-25 18:58 UTC (permalink / raw) > 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Annoying behavior 2015-04-25 18:58 ` Laurent @ 2015-04-25 19:30 ` Georg Bauhaus 2015-04-25 20:13 ` Laurent 2015-04-25 23:16 ` Bob Duff 0 siblings, 2 replies; 35+ messages in thread From: Georg Bauhaus @ 2015-04-25 19:30 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Annoying behavior 2015-04-25 19:30 ` Georg Bauhaus @ 2015-04-25 20:13 ` Laurent 2015-04-25 21:46 ` Laurent 2015-04-25 23:16 ` Bob Duff 1 sibling, 1 reply; 35+ messages in thread From: Laurent @ 2015-04-25 20:13 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Annoying behavior 2015-04-25 20:13 ` Laurent @ 2015-04-25 21:46 ` Laurent 0 siblings, 0 replies; 35+ messages in thread From: Laurent @ 2015-04-25 21:46 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Annoying behavior 2015-04-25 19:30 ` Georg Bauhaus 2015-04-25 20:13 ` Laurent @ 2015-04-25 23:16 ` Bob Duff 1 sibling, 0 replies; 35+ messages in thread From: Bob Duff @ 2015-04-25 23:16 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Annoying behavior 2015-04-25 15:46 ` Laurent 2015-04-25 17:02 ` Simon Wright 2015-04-25 17:41 ` Niklas Holsti @ 2015-04-26 10:38 ` Jedi Tek'Unum 2015-04-26 11:52 ` Textedit and txt Laurent 2 siblings, 1 reply; 35+ messages in thread From: Jedi Tek'Unum @ 2015-04-26 10:38 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Textedit and txt 2015-04-26 10:38 ` Jedi Tek'Unum @ 2015-04-26 11:52 ` Laurent 2015-04-26 13:21 ` brbarkstrom 0 siblings, 1 reply; 35+ messages in thread From: Laurent @ 2015-04-26 11:52 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Textedit and txt 2015-04-26 11:52 ` Textedit and txt Laurent @ 2015-04-26 13:21 ` brbarkstrom 2015-05-06 21:23 ` Randy Brukardt 0 siblings, 1 reply; 35+ messages in thread From: brbarkstrom @ 2015-04-26 13:21 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Textedit and txt 2015-04-26 13:21 ` brbarkstrom @ 2015-05-06 21:23 ` Randy Brukardt 2015-05-07 21:12 ` Laurent 0 siblings, 1 reply; 35+ messages in thread From: Randy Brukardt @ 2015-05-06 21:23 UTC (permalink / raw) <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. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Textedit and txt 2015-05-06 21:23 ` Randy Brukardt @ 2015-05-07 21:12 ` Laurent 2015-05-07 21:48 ` Simon Wright ` (2 more replies) 0 siblings, 3 replies; 35+ messages in thread From: Laurent @ 2015-05-07 21:12 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Textedit and txt 2015-05-07 21:12 ` Laurent @ 2015-05-07 21:48 ` Simon Wright 2015-05-07 22:24 ` Laurent 2015-05-08 23:35 ` Randy Brukardt 2015-05-09 15:23 ` brbarkstrom 2 siblings, 1 reply; 35+ messages in thread From: Simon Wright @ 2015-05-07 21:48 UTC (permalink / raw) 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) ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Textedit and txt 2015-05-07 21:48 ` Simon Wright @ 2015-05-07 22:24 ` Laurent 2015-05-08 5:50 ` Simon Wright 0 siblings, 1 reply; 35+ messages in thread From: Laurent @ 2015-05-07 22:24 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Textedit and txt 2015-05-07 22:24 ` Laurent @ 2015-05-08 5:50 ` Simon Wright 2015-05-08 7:35 ` Laurent 0 siblings, 1 reply; 35+ messages in thread From: Simon Wright @ 2015-05-08 5:50 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Textedit and txt 2015-05-08 5:50 ` Simon Wright @ 2015-05-08 7:35 ` Laurent 0 siblings, 0 replies; 35+ messages in thread From: Laurent @ 2015-05-08 7:35 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Textedit and txt 2015-05-07 21:12 ` Laurent 2015-05-07 21:48 ` Simon Wright @ 2015-05-08 23:35 ` Randy Brukardt 2015-05-09 19:25 ` Laurent 2015-05-11 17:00 ` Shark8 2015-05-09 15:23 ` brbarkstrom 2 siblings, 2 replies; 35+ messages in thread From: Randy Brukardt @ 2015-05-08 23:35 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Textedit and txt 2015-05-08 23:35 ` Randy Brukardt @ 2015-05-09 19:25 ` Laurent 2015-05-09 21:36 ` Anh Vo 2015-05-11 17:00 ` Shark8 1 sibling, 1 reply; 35+ messages in thread From: Laurent @ 2015-05-09 19:25 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Textedit and txt 2015-05-09 19:25 ` Laurent @ 2015-05-09 21:36 ` Anh Vo 0 siblings, 0 replies; 35+ messages in thread From: Anh Vo @ 2015-05-09 21:36 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Textedit and txt 2015-05-08 23:35 ` Randy Brukardt 2015-05-09 19:25 ` Laurent @ 2015-05-11 17:00 ` Shark8 2015-05-11 17:49 ` Dmitry A. Kazakov 1 sibling, 1 reply; 35+ messages in thread From: Shark8 @ 2015-05-11 17:00 UTC (permalink / raw) 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? ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Textedit and txt 2015-05-11 17:00 ` Shark8 @ 2015-05-11 17:49 ` Dmitry A. Kazakov 0 siblings, 0 replies; 35+ messages in thread From: Dmitry A. Kazakov @ 2015-05-11 17:49 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Textedit and txt 2015-05-07 21:12 ` Laurent 2015-05-07 21:48 ` Simon Wright 2015-05-08 23:35 ` Randy Brukardt @ 2015-05-09 15:23 ` brbarkstrom 2015-05-12 1:10 ` Randy Brukardt 2 siblings, 1 reply; 35+ messages in thread From: brbarkstrom @ 2015-05-09 15:23 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Textedit and txt 2015-05-09 15:23 ` brbarkstrom @ 2015-05-12 1:10 ` Randy Brukardt 2015-05-12 12:44 ` brbarkstrom 0 siblings, 1 reply; 35+ messages in thread From: Randy Brukardt @ 2015-05-12 1:10 UTC (permalink / raw) <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. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Textedit and txt 2015-05-12 1:10 ` Randy Brukardt @ 2015-05-12 12:44 ` brbarkstrom 2015-05-12 21:57 ` Randy Brukardt 0 siblings, 1 reply; 35+ messages in thread From: brbarkstrom @ 2015-05-12 12:44 UTC (permalink / raw) > ... > > > 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. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Textedit and txt 2015-05-12 12:44 ` brbarkstrom @ 2015-05-12 21:57 ` Randy Brukardt 2015-05-13 12:07 ` brbarkstrom 0 siblings, 1 reply; 35+ messages in thread From: Randy Brukardt @ 2015-05-12 21:57 UTC (permalink / raw) <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. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Textedit and txt 2015-05-12 21:57 ` Randy Brukardt @ 2015-05-13 12:07 ` brbarkstrom 0 siblings, 0 replies; 35+ messages in thread From: brbarkstrom @ 2015-05-13 12:07 UTC (permalink / raw) > ... > > 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. ^ permalink raw reply [flat|nested] 35+ messages in thread
end of thread, other threads:[~2015-05-13 12:07 UTC | newest] Thread overview: 35+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-04-24 21:40 Annoying behavior Laurent 2015-04-25 4:31 ` gautier_niouzes 2015-04-25 6:51 ` Laurent 2015-04-25 4:50 ` Niklas Holsti 2015-04-25 7:15 ` Laurent 2015-04-25 8:10 ` Niklas Holsti 2015-04-25 15:37 ` Laurent 2015-04-25 13:54 ` Stephen Leake 2015-04-25 15:46 ` Laurent 2015-04-25 17:02 ` Simon Wright 2015-04-25 17:41 ` Niklas Holsti 2015-04-25 18:58 ` Laurent 2015-04-25 19:30 ` Georg Bauhaus 2015-04-25 20:13 ` Laurent 2015-04-25 21:46 ` Laurent 2015-04-25 23:16 ` Bob Duff 2015-04-26 10:38 ` Jedi Tek'Unum 2015-04-26 11:52 ` Textedit and txt Laurent 2015-04-26 13:21 ` brbarkstrom 2015-05-06 21:23 ` Randy Brukardt 2015-05-07 21:12 ` Laurent 2015-05-07 21:48 ` Simon Wright 2015-05-07 22:24 ` Laurent 2015-05-08 5:50 ` Simon Wright 2015-05-08 7:35 ` Laurent 2015-05-08 23:35 ` Randy Brukardt 2015-05-09 19:25 ` Laurent 2015-05-09 21:36 ` Anh Vo 2015-05-11 17:00 ` Shark8 2015-05-11 17:49 ` Dmitry A. Kazakov 2015-05-09 15:23 ` brbarkstrom 2015-05-12 1:10 ` Randy Brukardt 2015-05-12 12:44 ` brbarkstrom 2015-05-12 21:57 ` Randy Brukardt 2015-05-13 12:07 ` brbarkstrom
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox