* Image attribute (yet again) @ 2020-04-20 15:24 Stephen Davies 2020-04-25 22:35 ` Stephen Davies 0 siblings, 1 reply; 21+ messages in thread From: Stephen Davies @ 2020-04-20 15:24 UTC (permalink / raw) Whilst looking at the new features for Ada 2020, I spotted: An implementation may transform the image generated by the default implementation of S'Put_Image for a composite subtype S in the following ways: - If S is a composite subtype, the leading character of the image of a component value or index value is a space, and the immediately preceding character is an open parenthesis, then the space may be omitted. The same transformation is also permitted if the leading character of the component image is a space (in which case one of the two spaces may be omitted). [AARM note: This means that it is permitted to generate "(1 => 123, 2 => 456)" instead of "( 1 => 123, 2 => 456)".] Whilst it is nice that those in charge of the language are finally acknowledging how annoying the leading space on numeric images is, that just makes it more galling that they appear to still be doing about it for scalar numeric types. I understand that the default behaviour of "'Image" cannot possibly be changed as it would cause massive incompatibility. But there are other, simple solutions, e.g. new attribute, optional parameters, ... One justification that might be given for doing nothing is that "Trim(S'Image, Left)" can be used instead, but I disagree because: - It requires adding with/use clauses for Ada.Strings and Ada.Strings.Fixed. - "S'Trim_Image" would still be nicer (just as "First_Element(C)" can be used instead of "Element(First(C))". ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Image attribute (yet again) 2020-04-20 15:24 Image attribute (yet again) Stephen Davies @ 2020-04-25 22:35 ` Stephen Davies 2020-04-26 6:05 ` J-P. Rosen 0 siblings, 1 reply; 21+ messages in thread From: Stephen Davies @ 2020-04-25 22:35 UTC (permalink / raw) On Monday, 20 April 2020 16:24:19 UTC+1, Stephen Davies wrote: > [yet another request for S'Trim_Image or Integer'Image(Arg,Width) > & Real'Image(Arg,Fore,Aft,Exp) or ...] I guess people are sick of talking about this long-standing problem. Personally, I'm more sick of its continued existence after 37yrs! One observation: Since the introduction of Object'Image, which cannot have optional integer parameters because I'Image(3) would be ambiguous, I guess something like Trim_Image would be the simpler solution. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Image attribute (yet again) 2020-04-25 22:35 ` Stephen Davies @ 2020-04-26 6:05 ` J-P. Rosen 2020-04-26 14:16 ` Jere 2020-04-26 18:57 ` Stephen Davies 0 siblings, 2 replies; 21+ messages in thread From: J-P. Rosen @ 2020-04-26 6:05 UTC (permalink / raw) Le 26/04/2020 à 00:35, Stephen Davies a écrit : > I guess people are sick of talking about this long-standing problem. > Personally, I'm more sick of its continued existence after 37yrs! > Personnaly, I am sick of people wanting to change the language just to save having to write a three-line function. 'Image is not intending for elaborate formatting, it's a quick debugging help. Text_IO has all formatting features for proper IO. Since every program has different formatting needs, you have to write you own function. -- J-P. Rosen Adalog 2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00 http://www.adalog.fr ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Image attribute (yet again) 2020-04-26 6:05 ` J-P. Rosen @ 2020-04-26 14:16 ` Jere 2020-04-26 17:09 ` Jeffrey R. Carter ` (2 more replies) 2020-04-26 18:57 ` Stephen Davies 1 sibling, 3 replies; 21+ messages in thread From: Jere @ 2020-04-26 14:16 UTC (permalink / raw) On Sunday, April 26, 2020 at 2:05:59 AM UTC-4, J-P. Rosen wrote: > Le 26/04/2020 à 00:35, Stephen Davies a écrit : > 'Image is not intending for elaborate formatting, it's a quick debugging > help. Text_IO has all formatting features for proper IO. Since every > program has different formatting needs, you have to write you own function. > This might be a good time to ask since this comes up all the time for me, but where are the formatting options for hexadecimal to String. All I have found so far is the Put operation in the various "_IO" packages and generics, but it isn't useful at all for formatting hexadecimal values in real world scenarios. I pretty much reinvent the wheel each time I have some variant of needing this functionality. One of these days I'll get around to making my own generic version of it, but if the Ada standard provides a means to do it, that would be optimal. The only option I have found is the Put operation, but it is pretty abysmal to use. Are there any solutions to this that I am missing from within the Ada standard? ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Image attribute (yet again) 2020-04-26 14:16 ` Jere @ 2020-04-26 17:09 ` Jeffrey R. Carter 2020-04-26 17:33 ` Jere 2020-04-26 18:40 ` Oliver Kellogg 2020-05-20 1:52 ` Shark8 2 siblings, 1 reply; 21+ messages in thread From: Jeffrey R. Carter @ 2020-04-26 17:09 UTC (permalink / raw) On 4/26/20 4:16 PM, Jere wrote: >> > This might be a good time to ask since this comes up all the time > for me, but where are the formatting options for hexadecimal > to String. All I have found so far is the Put operation > in the various "_IO" packages and generics, but it isn't > useful at all for formatting hexadecimal values in real world > scenarios. I pretty much reinvent the wheel each time > I have some variant of needing this functionality. One of > these days I'll get around to making my own generic > version of it, but if the Ada standard provides a means > to do it, that would be optimal. The only option I have > found is the Put operation, but it is pretty abysmal to > use. Are there any solutions to this that I am missing > from within the Ada standard? I can't tell what problem you're talking about. Ada.Text_IO's numeric-I/O pkgs, sometimes combined with String-handling functions and basic 1-D array operations seem to provide everything one could want. Pkg PragmARC.Images has been around for a long time and provides generic Image functions for numeric types with width, zero-fill, and base options. https://github.com/jrcarter/PragmARC -- Jeff Carter "I'm a kike, a yid, a heebie, a hook nose! I'm Kosher, Mum! I'm a Red Sea pedestrian, and proud of it!" Monty Python's Life of Brian 77 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Image attribute (yet again) 2020-04-26 17:09 ` Jeffrey R. Carter @ 2020-04-26 17:33 ` Jere 2020-04-27 12:33 ` J-P. Rosen 0 siblings, 1 reply; 21+ messages in thread From: Jere @ 2020-04-26 17:33 UTC (permalink / raw) On Sunday, April 26, 2020 at 1:09:12 PM UTC-4, Jeffrey R. Carter wrote: > On 4/26/20 4:16 PM, Jere wrote: > >> > > This might be a good time to ask since this comes up all the time > > for me, but where are the formatting options for hexadecimal > > to String. All I have found so far is the Put operation > > in the various "_IO" packages and generics, but it isn't > > useful at all for formatting hexadecimal values in real world > > scenarios. I pretty much reinvent the wheel each time > > I have some variant of needing this functionality. One of > > these days I'll get around to making my own generic > > version of it, but if the Ada standard provides a means > > to do it, that would be optimal. The only option I have > > found is the Put operation, but it is pretty abysmal to > > use. Are there any solutions to this that I am missing > > from within the Ada standard? > > I can't tell what problem you're talking about. Ada.Text_IO's numeric-I/O pkgs, > sometimes combined with String-handling functions and basic 1-D array operations > seem to provide everything one could want. > I'm not saying it can't be done. I'm saying by the time I go through all the processing needed, I might as well wrote my own function. It makes the existing operation mostly useless (unless I just want a temporary debug print that I don't care how it looks). For example, if I want to print to a 16x2 character LCD screen and I want to print 0 padded 4 digit hex values with no "16#" prefix or "#" ending, then I need to call Put with an 8 character string, search for the first occurrence of '#' (it can be in multiple locations), then overwrite a variable number of those characters with 0's (based on the location of '#'), and then extract the 4 digits I actually need. All doable (not saying it cannot be done), but at that point, I am better off just doing my own custom operation instead instead of even using the Put operation. It feels like the Put operation wasn't designed with usability in mind. Just the presence of the "16#" and "#" around the value makes using the operation more clunky than it should be. If that had been left out or if the operation at least allowed for padding the actual numeric value inside the result, then it would have been much more usable. I was hoping that there was a better formatting operation for non base 10 number formatting that I wasn't aware of as it was alluded that Text_IO had all the necessary formatting features. I am still finding new stuff in the Ada standard each day, so I was hoping I had just missed something. J.P. Rosen has a much better experience and knowledge of the standard than me, so I was hoping he could point me to something that was better than what I currently knew of. If there isn't, then no biggie, I'll just keep writing custom functions. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Image attribute (yet again) 2020-04-26 17:33 ` Jere @ 2020-04-27 12:33 ` J-P. Rosen 2020-04-27 12:50 ` Jere 2020-04-27 14:10 ` Jere 0 siblings, 2 replies; 21+ messages in thread From: J-P. Rosen @ 2020-04-27 12:33 UTC (permalink / raw) Le 26/04/2020 à 19:33, Jere a écrit : > I'm not saying it can't be done. I'm saying by the time I go through > all the processing needed, I might as well wrote my own function. It > makes the existing operation mostly useless (unless I just want a > temporary debug print that I don't care how it looks). For example, > if I want to print to a 16x2 character LCD screen and I want to print > 0 padded 4 digit hex values with no "16#" prefix or "#" ending, then > I need to call Put with an 8 character string, search for the first > occurrence of '#' (it can be in multiple locations), then overwrite > a variable number of those characters with 0's (based on the location > of '#'), and then extract the 4 digits I actually need. All doable > (not saying it cannot be done), but at that point, I am better off > just doing my own custom operation instead instead of even using the > Put operation. Right. If you want you own format, write it. It will take you less time than writing this message. For the benefit of everybody, here it is: Hex_Digits : constant array (Bits_16 range 0..15) of Character := "0123456789ABCDEF"; function Hex_Image (Value : Bits_16) return String is Result : String (1 .. 4); Current : Bits_16 := Value; begin for I in reverse Result'Range loop Result (I) := Hex_Digits (Current mod 16); Current := Current / 16; end loop; return Result; end Hex_Image; > It feels like the Put operation wasn't designed > with usability in mind. Just the presence of the "16#" and "#" > around the value makes using the operation more clunky than it > should be. If that had been left out or if the operation at least > allowed for padding the actual numeric value inside the result, > then it would have been much more usable. Text_IO was designed for file operations, not so much for interactive IO. And there is an important feature of Text_IO which is rarely mentioned: If you use only the appropriate operations from Text_IO (no 'Image), and your program writes into a file, you can take the sequence of code that writes the file, replace every Put_* operation by the symetric Get_* operation, and you will read the file without error. This feature requires that if you write a number in a certain base, then you need to recognize the base when reading. So it's not an error, but a design decision. Of course, like any design decision, you may agree with it or not. -- J-P. Rosen Adalog 2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00 http://www.adalog.fr ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Image attribute (yet again) 2020-04-27 12:33 ` J-P. Rosen @ 2020-04-27 12:50 ` Jere 2020-04-27 13:42 ` J-P. Rosen 2020-04-27 14:10 ` Jere 1 sibling, 1 reply; 21+ messages in thread From: Jere @ 2020-04-27 12:50 UTC (permalink / raw) On Monday, April 27, 2020 at 8:33:31 AM UTC-4, J-P. Rosen wrote: > Le 26/04/2020 à 19:33, Jere a écrit : > > I'm not saying it can't be done. I'm saying by the time I go through > > all the processing needed, I might as well wrote my own function. It > > makes the existing operation mostly useless (unless I just want a > > temporary debug print that I don't care how it looks). For example, > > if I want to print to a 16x2 character LCD screen and I want to print > > 0 padded 4 digit hex values with no "16#" prefix or "#" ending, then > > I need to call Put with an 8 character string, search for the first > > occurrence of '#' (it can be in multiple locations), then overwrite > > a variable number of those characters with 0's (based on the location > > of '#'), and then extract the 4 digits I actually need. All doable > > (not saying it cannot be done), but at that point, I am better off > > just doing my own custom operation instead instead of even using the > > Put operation. > Right. If you want you own format, write it. It will take you less time > than writing this message. For the benefit of everybody, here it is: > > Yep, I do something similar to what you posted. I was just asking if the standard provided something more than what Put provided as it wasn't quite adequate for the general case. It sounds like from your answer that I didn't miss it (I was hoping!). As I said earlier, for stuff like this I have generally rolled my own in Ada. > > > It feels like the Put operation wasn't designed > > with usability in mind. Just the presence of the "16#" and "#" > > around the value makes using the operation more clunky than it > > should be. If that had been left out or if the operation at least > > allowed for padding the actual numeric value inside the result, > > then it would have been much more usable. > > Text_IO was designed for file operations, not so much for interactive > IO. And there is an important feature of Text_IO which is rarely > mentioned: If you use only the appropriate operations from Text_IO (no > 'Image), and your program writes into a file, you can take the sequence > of code that writes the file, replace every Put_* operation by the > symetric Get_* operation, and you will read the file without error. > > This feature requires that if you write a number in a certain base, then > you need to recognize the base when reading. So it's not an error, but a > design decision. Of course, like any design decision, you may agree with > it or not. Conceptionally that makes sense. I do wish they had followed other languages in at least providing some of the basic formatting options for stuff like this. Even if it was a different package (String_IO?). ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Image attribute (yet again) 2020-04-27 12:50 ` Jere @ 2020-04-27 13:42 ` J-P. Rosen 2020-04-27 14:05 ` Jere 2020-04-27 14:55 ` Jeffrey R. Carter 0 siblings, 2 replies; 21+ messages in thread From: J-P. Rosen @ 2020-04-27 13:42 UTC (permalink / raw) Le 27/04/2020 à 14:50, Jere a écrit : > Conceptionally that makes sense. I do wish they had followed other > languages in at least providing some of the basic formatting options > for stuff like this. Even if it was a different package (String_IO?). There are plenty of packages that you can download that provide very useful stuff. The difference with other languages is that Ada people disregard anything which is not blessed by the standard. Many other in-fashion languages have not standard at all, so users consider that anything on the web is "available for the language". If you look at any of the sites that provide Ada resources links, you'll see that Ada's situation is not that bad... Talking about reuse vs. redesign, I recommend the paper "What price reusability", old but fortunately available from ACM: https://dl.acm.org/doi/10.1145/112629.112643 It compares the cost of rewriting with the cost of searching for something already available, and the number of reuses necessary to break even. It shows that for simple things (like the one we discussed above), rewriting can be more cost-effective than searching the web for existing stuff... -- J-P. Rosen Adalog 2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00 http://www.adalog.fr ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Image attribute (yet again) 2020-04-27 13:42 ` J-P. Rosen @ 2020-04-27 14:05 ` Jere 2020-04-27 14:55 ` Jeffrey R. Carter 1 sibling, 0 replies; 21+ messages in thread From: Jere @ 2020-04-27 14:05 UTC (permalink / raw) On Monday, April 27, 2020 at 9:42:39 AM UTC-4, J-P. Rosen wrote: > Le 27/04/2020 à 14:50, Jere a écrit : > > Conceptionally that makes sense. I do wish they had followed other > > languages in at least providing some of the basic formatting options > > for stuff like this. Even if it was a different package (String_IO?). > > There are plenty of packages that you can download that provide very > useful stuff. The difference with other languages is that Ada people > disregard anything which is not blessed by the standard. Many other > in-fashion languages have not standard at all, so users consider that > anything on the web is "available for the language". I was more referring to things that are considered part of the standard language (text formatting of numbers is standard in many languages). > If you look at any of the sites that provide Ada resources links, you'll > see that Ada's situation is not that bad... It depends on what your use case is. In some areas, the situation is quite bad, in others it is not. I am hoping that as some more mainstream companies like Nvidia take up Ada, the landscape will improve even more. > > Talking about reuse vs. redesign, I recommend the paper "What price > reusability", old but fortunately available from ACM: > https://dl.acm.org/doi/10.1145/112629.112643 > > It compares the cost of rewriting with the cost of searching for > something already available, and the number of reuses necessary to break > even. It shows that for simple things (like the one we discussed above), > rewriting can be more cost-effective than searching the web for existing > stuff... > Thanks! I'll take a look. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Image attribute (yet again) 2020-04-27 13:42 ` J-P. Rosen 2020-04-27 14:05 ` Jere @ 2020-04-27 14:55 ` Jeffrey R. Carter 2020-04-28 6:04 ` J-P. Rosen 1 sibling, 1 reply; 21+ messages in thread From: Jeffrey R. Carter @ 2020-04-27 14:55 UTC (permalink / raw) On 4/27/20 3:42 PM, J-P. Rosen wrote: > > It compares the cost of rewriting with the cost of searching for > something already available, and the number of reuses necessary to break > even. It shows that for simple things (like the one we discussed above), > rewriting can be more cost-effective than searching the web for existing > stuff... That's a mischaracterization of the paper. It actually compares the cost of implementing and using an application-specific component to implementing and using a reusable component. Going to adaic.org and finding a library you like takes longer than writing a little subprogram like the one under discussion, but a lot less time than writing such subprograms repeatedly. -- Jeff Carter "This school was here before you came, and it'll be here before you go." Horse Feathers 48 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Image attribute (yet again) 2020-04-27 14:55 ` Jeffrey R. Carter @ 2020-04-28 6:04 ` J-P. Rosen 0 siblings, 0 replies; 21+ messages in thread From: J-P. Rosen @ 2020-04-28 6:04 UTC (permalink / raw) Le 27/04/2020 à 16:55, Jeffrey R. Carter a écrit : > That's a mischaracterization of the paper. It actually compares the cost > of implementing and using an application-specific component to > implementing and using a reusable component. > > Going to adaic.org and finding a library you like takes longer than > writing a little subprogram like the one under discussion, but a lot > less time than writing such subprograms repeatedly. Well, the "break even" is measured in terms of number of reuses vs. effort to find an existing component. Of course, it assumes that once you have written something yourself, you don't keep rewriting it all the time! -- J-P. Rosen Adalog 2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00 http://www.adalog.fr ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Image attribute (yet again) 2020-04-27 12:33 ` J-P. Rosen 2020-04-27 12:50 ` Jere @ 2020-04-27 14:10 ` Jere 2020-04-28 6:02 ` J-P. Rosen 1 sibling, 1 reply; 21+ messages in thread From: Jere @ 2020-04-27 14:10 UTC (permalink / raw) On Monday, April 27, 2020 at 8:33:31 AM UTC-4, J-P. Rosen wrote: > Le 26/04/2020 à 19:33, Jere a écrit : > > I'm not saying it can't be done. I'm saying by the time I go through > > all the processing needed, I might as well wrote my own function. It > > makes the existing operation mostly useless (unless I just want a > > temporary debug print that I don't care how it looks). For example, > > if I want to print to a 16x2 character LCD screen and I want to print > > 0 padded 4 digit hex values with no "16#" prefix or "#" ending, then > > I need to call Put with an 8 character string, search for the first > > occurrence of '#' (it can be in multiple locations), then overwrite > > a variable number of those characters with 0's (based on the location > > of '#'), and then extract the 4 digits I actually need. All doable > > (not saying it cannot be done), but at that point, I am better off > > just doing my own custom operation instead instead of even using the > > Put operation. > > This feature requires that if you write a number in a certain base, then > you need to recognize the base when reading. So it's not an error, but a > design decision. Of course, like any design decision, you may agree with > it or not. As I have thought about this more, I don't think I see the need for the "16#" and associated for this functionality to work. If you are using the reflective Get to the Put, that knows the base. The text doesn't need to specify it. If you want something more runtime adaptive, then sure, but for pure reflective Get/Put it isn't needed that I can tell. In the case where a more runtime adaptive strategy is desired, that is where I would have expected the language to want you to roll one's own logic. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Image attribute (yet again) 2020-04-27 14:10 ` Jere @ 2020-04-28 6:02 ` J-P. Rosen 2020-04-28 13:03 ` Jere 0 siblings, 1 reply; 21+ messages in thread From: J-P. Rosen @ 2020-04-28 6:02 UTC (permalink / raw) Le 27/04/2020 à 16:10, Jere a écrit : >> This feature requires that if you write a number in a certain base, then >> you need to recognize the base when reading. So it's not an error, but a >> design decision. Of course, like any design decision, you may agree with >> it or not. > As I have thought about this more, I don't think I see the need > for the "16#" and associated for this functionality to work. If you > are using the reflective Get to the Put, that knows the base. The > text doesn't need to specify it. If you want something more runtime > adaptive, then sure, but for pure reflective Get/Put it isn't needed > that I can tell. In the case where a more runtime adaptive strategy > is desired, that is where I would have expected the language to want Huh? The Get procedure has no parameter for the base, it accepts whatever is in the file. The design principle is that you are precise on output, and tolerant on input. Same idea with 'Image (required to be upper case) and 'Value (accepts any case). -- J-P. Rosen Adalog 2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00 http://www.adalog.fr ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Image attribute (yet again) 2020-04-28 6:02 ` J-P. Rosen @ 2020-04-28 13:03 ` Jere 0 siblings, 0 replies; 21+ messages in thread From: Jere @ 2020-04-28 13:03 UTC (permalink / raw) On Tuesday, April 28, 2020 at 2:02:20 AM UTC-4, J-P. Rosen wrote: > Le 27/04/2020 à 16:10, Jere a écrit : > >> This feature requires that if you write a number in a certain base, then > >> you need to recognize the base when reading. So it's not an error, but a > >> design decision. Of course, like any design decision, you may agree with > >> it or not. > > As I have thought about this more, I don't think I see the need > > for the "16#" and associated for this functionality to work. If you > > are using the reflective Get to the Put, that knows the base. The > > text doesn't need to specify it. If you want something more runtime > > adaptive, then sure, but for pure reflective Get/Put it isn't needed > > that I can tell. In the case where a more runtime adaptive strategy > > is desired, that is where I would have expected the language to want > > Huh? The Get procedure has no parameter for the base, it accepts > whatever is in the file. > > The design principle is that you are precise on output, and tolerant on > input. Same idea with 'Image (required to be upper case) and 'Value > (accepts any case). > > -- > J-P. Rosen > Adalog > 2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX > Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00 > http://www.adalog.fr Yeah, I misread the RM as having the base on Get as well. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Image attribute (yet again) 2020-04-26 14:16 ` Jere 2020-04-26 17:09 ` Jeffrey R. Carter @ 2020-04-26 18:40 ` Oliver Kellogg 2020-04-26 18:42 ` Oliver Kellogg 2020-04-27 12:52 ` Jere 2020-05-20 1:52 ` Shark8 2 siblings, 2 replies; 21+ messages in thread From: Oliver Kellogg @ 2020-04-26 18:40 UTC (permalink / raw) On Sunday, April 26, 2020 at 4:16:46 PM UTC+2, Jere wrote: > This might be a good time to ask since this comes up all the time > for me, but where are the formatting options for hexadecimal > to String. All I have found so far is the Put operation > in the various "_IO" packages and generics, but it isn't > useful at all for formatting hexadecimal values in real world > scenarios. I pretty much reinvent the wheel each time > I have some variant of needing this functionality. +1 for me - e.g. see function Hex_Str_To_Unsigned at https://github.com/persan/auto-io-gen/blob/28e8e57c18dfd328a5abc97f3e6e12ceacd5b3c9/auto_text_io.src/auto_text_io-access_io.adb - Oliver ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Image attribute (yet again) 2020-04-26 18:40 ` Oliver Kellogg @ 2020-04-26 18:42 ` Oliver Kellogg 2020-04-26 18:43 ` Oliver Kellogg 2020-04-27 12:52 ` Jere 1 sibling, 1 reply; 21+ messages in thread From: Oliver Kellogg @ 2020-04-26 18:42 UTC (permalink / raw) On Sunday, April 26, 2020 at 8:40:05 PM UTC+2, Oliver Kellogg wrote: > On Sunday, April 26, 2020 at 4:16:46 PM UTC+2, Jere wrote: > > This might be a good time to ask since this comes up all the time > > for me, but where are the formatting options for hexadecimal > > to String. All I have found so far is the Put operation > > in the various "_IO" packages and generics, but it isn't > > useful at all for formatting hexadecimal values in real world > > scenarios. I pretty much reinvent the wheel each time > > I have some variant of needing this functionality. > > +1 for me - e.g. see function Hex_Str_To_Unsigned at > https://github.com/persan/auto-io-gen/blob/28e8e57c18dfd328a5abc97f3e6e12ceacd5b3c9/auto_text_io.src/auto_text_io-access_io.adb > > - Oliver Oops, I meant Hex_Str_to_Unsigned ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Image attribute (yet again) 2020-04-26 18:42 ` Oliver Kellogg @ 2020-04-26 18:43 ` Oliver Kellogg 0 siblings, 0 replies; 21+ messages in thread From: Oliver Kellogg @ 2020-04-26 18:43 UTC (permalink / raw) On Sunday, April 26, 2020 at 8:42:09 PM UTC+2, Oliver Kellogg wrote: > On Sunday, April 26, 2020 at 8:40:05 PM UTC+2, Oliver Kellogg wrote: > > On Sunday, April 26, 2020 at 4:16:46 PM UTC+2, Jere wrote: > > > This might be a good time to ask since this comes up all the time > > > for me, but where are the formatting options for hexadecimal > > > to String. All I have found so far is the Put operation > > > in the various "_IO" packages and generics, but it isn't > > > useful at all for formatting hexadecimal values in real world > > > scenarios. I pretty much reinvent the wheel each time > > > I have some variant of needing this functionality. > > > > +1 for me - e.g. see function Hex_Str_To_Unsigned at > > https://github.com/persan/auto-io-gen/blob/28e8e57c18dfd328a5abc97f3e6e12ceacd5b3c9/auto_text_io.src/auto_text_io-access_io.adb > > > > - Oliver > > Oops, I meant Hex_Str_to_Unsigned not my day! Unsigned_to_Hex_Str ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Image attribute (yet again) 2020-04-26 18:40 ` Oliver Kellogg 2020-04-26 18:42 ` Oliver Kellogg @ 2020-04-27 12:52 ` Jere 1 sibling, 0 replies; 21+ messages in thread From: Jere @ 2020-04-27 12:52 UTC (permalink / raw) On Sunday, April 26, 2020 at 2:40:05 PM UTC-4, Oliver Kellogg wrote: > On Sunday, April 26, 2020 at 4:16:46 PM UTC+2, Jere wrote: > > This might be a good time to ask since this comes up all the time > > for me, but where are the formatting options for hexadecimal > > to String. All I have found so far is the Put operation > > in the various "_IO" packages and generics, but it isn't > > useful at all for formatting hexadecimal values in real world > > scenarios. I pretty much reinvent the wheel each time > > I have some variant of needing this functionality. > > +1 for me - e.g. see function Hex_Str_To_Unsigned at > https://github.com/persan/auto-io-gen/blob/28e8e57c18dfd328a5abc97f3e6e12ceacd5b3c9/auto_text_io.src/auto_text_io-access_io.adb > > - Oliver Thanks! I do have a method I use (more similar to the one J.P. Rosen had posted later on), but I'll take a look at this. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Image attribute (yet again) 2020-04-26 14:16 ` Jere 2020-04-26 17:09 ` Jeffrey R. Carter 2020-04-26 18:40 ` Oliver Kellogg @ 2020-05-20 1:52 ` Shark8 2 siblings, 0 replies; 21+ messages in thread From: Shark8 @ 2020-05-20 1:52 UTC (permalink / raw) On Sunday, April 26, 2020 at 8:16:46 AM UTC-6, Jere wrote: > On Sunday, April 26, 2020 at 2:05:59 AM UTC-4, J-P. Rosen wrote: > > Le 26/04/2020 à 00:35, Stephen Davies a écrit : > > 'Image is not intending for elaborate formatting, it's a quick debugging > > help. Text_IO has all formatting features for proper IO. Since every > > program has different formatting needs, you have to write you own function. > > > This might be a good time to ask since this comes up all the time > for me, but where are the formatting options for hexadecimal > to String. The method that I typically go with is something like: Subtype Hex_Character is Character with Static_Predicate => Hex_Character in '0'..'9'|'A'..'F'; Type Nybble is range 0..15 with Size => 4; Type Byte is record High, Low : Nybble; end record with Size => 8; -- Rep Clause. Function To_Nybble( Input : Hex_Character ) return Nybble is (case Input is when '0' => 16#0#, when '1' => 16#1#, --... when 'F' => 16#F# ); Function To_Hex_Character( Input : Nybble ) return Hex_Character is (case Input is when 16#0# => '0', when 16#1# => '1', --... when 16#F# => 'F' ); Function Byte_to_Hex( Input : Byte ) return String is ( HexChar( Input.High ) & HexChar( Input.High ) ); Though for one application I made a proper Hex_Character character-type and used the 'pos/'val/'image/'value attributes. You can also get easy string conversions with 'Value, especially: Subtype Hex_String is String with Dynamic_Predicate => (for all C of Hex_String => C in Hex_Character); Function Hex_to_Integer( Input : Hex_String ) return Integer is ( Integer'Image("16#"& Input &'#') ); ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Image attribute (yet again) 2020-04-26 6:05 ` J-P. Rosen 2020-04-26 14:16 ` Jere @ 2020-04-26 18:57 ` Stephen Davies 1 sibling, 0 replies; 21+ messages in thread From: Stephen Davies @ 2020-04-26 18:57 UTC (permalink / raw) On Sunday, 26 April 2020 07:05:59 UTC+1, J-P. Rosen wrote: > Personnaly, I am sick of people wanting to change the language just to > save having to write a three-line function. I could write a three-line function to do 'Min but I appreciate it being party of the language. > 'Image is not intending for elaborate formatting Displaying numbers without extraneous spaces is hardly elaborate. > it's a quick debugging help. I have used 'Image in delivered code and I doubt I'm alone. Furthermore, it's useful when first learning Ada, and the leading space is not a good advert for students. > Text_IO has all formatting features for proper IO. Text_IO is somewhat lacking when it comes to formatting (e.g. see Jere's and Oliver's replies). A couple of additional thoughts:- 1. If Trim_Image were added then Trim_Width should also be added, which could be useful even when Integer_IO.Put is being used. 2. If the language won't change (and maybe even if it does change) perhaps if would be nice if Gnat added S'Trmg (c.f. S'Img). ^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2020-05-20 1:52 UTC | newest] Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-04-20 15:24 Image attribute (yet again) Stephen Davies 2020-04-25 22:35 ` Stephen Davies 2020-04-26 6:05 ` J-P. Rosen 2020-04-26 14:16 ` Jere 2020-04-26 17:09 ` Jeffrey R. Carter 2020-04-26 17:33 ` Jere 2020-04-27 12:33 ` J-P. Rosen 2020-04-27 12:50 ` Jere 2020-04-27 13:42 ` J-P. Rosen 2020-04-27 14:05 ` Jere 2020-04-27 14:55 ` Jeffrey R. Carter 2020-04-28 6:04 ` J-P. Rosen 2020-04-27 14:10 ` Jere 2020-04-28 6:02 ` J-P. Rosen 2020-04-28 13:03 ` Jere 2020-04-26 18:40 ` Oliver Kellogg 2020-04-26 18:42 ` Oliver Kellogg 2020-04-26 18:43 ` Oliver Kellogg 2020-04-27 12:52 ` Jere 2020-05-20 1:52 ` Shark8 2020-04-26 18:57 ` Stephen Davies
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox