* GNAT user-specified (via Raise_Exception) warning message size limit @ 2018-02-16 18:44 marciant 2018-02-16 18:59 ` Per Sandberg 2018-02-17 0:03 ` Randy Brukardt 0 siblings, 2 replies; 19+ messages in thread From: marciant @ 2018-02-16 18:44 UTC (permalink / raw) Hello, Before I see about asking AdaCore directly via GNAT Tracker, I thought that I'd ask here first: Is there a way to increase the default size limit of the exception message that is specified when calling Ada.Exceptions.Raise_Exception? It seems that although quite long messages are accepted at calls to it, the message then retrieved and printed within a handler that uses Ada.Exceptions.Exception_Message on the occurrence only returns a truncated part of the original message - around the first 200 characters are returned and the rest is truncated. Vincent Marciante ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: GNAT user-specified (via Raise_Exception) warning message size limit 2018-02-16 18:44 GNAT user-specified (via Raise_Exception) warning message size limit marciant @ 2018-02-16 18:59 ` Per Sandberg 2018-02-16 19:11 ` marciant 2018-02-17 0:03 ` Randy Brukardt 1 sibling, 1 reply; 19+ messages in thread From: Per Sandberg @ 2018-02-16 18:59 UTC (permalink / raw) Well From a quick glance i would expect the answer to be: In package System.Parameters update the value of "Default_Exception_Msg_Max_Length" to a new value. And recompile the run-times. /P Den 2018-02-16 kl. 19:44, skrev marciant@earthlink.net: > Hello, > > Before I see about asking AdaCore directly via GNAT Tracker, I thought that I'd ask here first: > > Is there a way to increase the default size limit of the exception message that is specified when calling Ada.Exceptions.Raise_Exception? > > It seems that although quite long messages are accepted at calls to it, the message then retrieved and printed within a handler that uses Ada.Exceptions.Exception_Message on the occurrence only returns a truncated part of the original message - around the first 200 characters are returned and the rest is truncated. > > Vincent Marciante > ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: GNAT user-specified (via Raise_Exception) warning message size limit 2018-02-16 18:59 ` Per Sandberg @ 2018-02-16 19:11 ` marciant 2018-02-16 20:58 ` Anh Vo 2018-02-18 22:33 ` Mark Lorenzen 0 siblings, 2 replies; 19+ messages in thread From: marciant @ 2018-02-16 19:11 UTC (permalink / raw) On Friday, February 16, 2018 at 1:59:17 PM UTC-5, Per Sandberg wrote: > Well > From a quick glance i would expect the answer to be: > > In package System.Parameters update the value of > "Default_Exception_Msg_Max_Length" to a new value. > And recompile the run-times. > > /P Thanks. I was hoping that there might be some "configuration" switch/pragma to do it. However, if that ends up being the only way I guess that we would as for step by step from AdaCore or ask for a wavefront release. (I'll have to read some more looking for a less "drastic" way before I ask to have the contact person ask Adacore.) Vincent Marciante ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: GNAT user-specified (via Raise_Exception) warning message size limit 2018-02-16 19:11 ` marciant @ 2018-02-16 20:58 ` Anh Vo 2018-02-16 23:22 ` marciant 2018-02-18 22:33 ` Mark Lorenzen 1 sibling, 1 reply; 19+ messages in thread From: Anh Vo @ 2018-02-16 20:58 UTC (permalink / raw) On Friday, February 16, 2018 at 11:11:26 AM UTC-8, marc...@earthlink.net wrote: > On Friday, February 16, 2018 at 1:59:17 PM UTC-5, Per Sandberg wrote: > > Well > > From a quick glance i would expect the answer to be: > > > > In package System.Parameters update the value of > > "Default_Exception_Msg_Max_Length" to a new value. > > And recompile the run-times. > > > > /P > > Thanks. I was hoping that there might be some "configuration" switch/pragma to do it. However, if that ends up being the only way I guess that we would as for step by step from AdaCore or ask for a wavefront release. > > (I'll have to read some more looking for a less "drastic" way before I ask to have the contact person ask Adacore.) I am curious to know the rationale for using pretty long exception message. I have not had a situation to use exception message this long in my software career. Anh Vo ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: GNAT user-specified (via Raise_Exception) warning message size limit 2018-02-16 20:58 ` Anh Vo @ 2018-02-16 23:22 ` marciant 2018-02-17 7:15 ` J-P. Rosen 0 siblings, 1 reply; 19+ messages in thread From: marciant @ 2018-02-16 23:22 UTC (permalink / raw) > I am curious to know the rationale for using pretty long exception message. I have not had a situation to use exception message this long in my software career. Some XML text messages are being parsed "deep" down in a subsystem and when a problem is encountered a specific exception is raised and the problematic XML text is included in the exception message and propagated up a "level" or two of code where it is sometimes parsed again and repropagated with additional debugging information. I know: "That is abuse of exceptions!" :) However, it seemed to be (and proved to be) an easy and robust way to debug and provide forensic logs of problems that occurred in the fielded systems. The project had been frozen as ObjectAda 7.2.2 however we are investigating the feasibility of moving to GNAT. The ObjectAda compiler either did not have a size restriction or we luckily had not ever reached it! Anyway, this seems to be the last sticking point before a simple proof-of-possibility can be demonstrated. (I might first have to try to design some addition mechanism that can be utilized very much "under the covers" that allows the current architecture to remain mostly intact.) ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: GNAT user-specified (via Raise_Exception) warning message size limit 2018-02-16 23:22 ` marciant @ 2018-02-17 7:15 ` J-P. Rosen 2018-02-17 16:38 ` marciant 0 siblings, 1 reply; 19+ messages in thread From: J-P. Rosen @ 2018-02-17 7:15 UTC (permalink / raw) Le 17/02/2018 à 00:22, marciant@earthlink.net a écrit : > Some XML text messages are being parsed "deep" down in a subsystem > and when a problem is encountered a specific exception is raised and > the problematic XML text is included in the exception message and > propagated up a "level" or two of code where it is sometimes parsed > again and repropagated with additional debugging information. But why do you put all the message in the exception message? Store it in some global structure, where you can handle it any way you want. Note that it's what you'd do if you wanted to keep information other than string (assuming you have no issue with concurrency, but then you could use a task attribute) -- 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] 19+ messages in thread
* Re: GNAT user-specified (via Raise_Exception) warning message size limit 2018-02-17 7:15 ` J-P. Rosen @ 2018-02-17 16:38 ` marciant 0 siblings, 0 replies; 19+ messages in thread From: marciant @ 2018-02-17 16:38 UTC (permalink / raw) On Saturday, February 17, 2018 at 3:08:35 AM UTC-5, J-P. Rosen wrote: > Le 17/02/2018 à 00:22, marc...@earthlink.net a écrit : > > Some XML text messages are being parsed "deep" down in a subsystem > > and when a problem is encountered a specific exception is raised and > > the problematic XML text is included in the exception message and > > propagated up a "level" or two of code where it is sometimes parsed > > again and repropagated with additional debugging information. > But why do you put all the message in the exception message? > > Store it in some global structure, where you can handle it any way you > want. Note that it's what you'd do if you wanted to keep information > other than string (assuming you have no issue with concurrency, but then > you could use a task attribute) In the exception message for a few reasons: - The information was always all text (an externally produced structured message) - The final length was always unknown - All debugging/logging "machinery" was originally designed to expect to only have to simply print out Exception_Information. - For years it had all fit (including full/deep, explicit ObjectAda call trace back debugging information) - Design for portability was never a requirement: The project was supposed to have been superseded a few times already by (non-Ada) projects that themselves ended up being cancelled. However, like you suggested, I understand that using a global area (possibly indictated by "place-holder" text that is put in the exception message instead of the actual text) might be made to work with minimal disruption to the existing code. Thanks, Vincent Marciante ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: GNAT user-specified (via Raise_Exception) warning message size limit 2018-02-16 19:11 ` marciant 2018-02-16 20:58 ` Anh Vo @ 2018-02-18 22:33 ` Mark Lorenzen 2018-02-18 23:09 ` Simon Wright 2018-02-19 15:31 ` marciant 1 sibling, 2 replies; 19+ messages in thread From: Mark Lorenzen @ 2018-02-18 22:33 UTC (permalink / raw) On Friday, February 16, 2018 at 8:11:26 PM UTC+1, marc...@earthlink.net wrote: > On Friday, February 16, 2018 at 1:59:17 PM UTC-5, Per Sandberg wrote: > > Well > > From a quick glance i would expect the answer to be: > > > > In package System.Parameters update the value of > > "Default_Exception_Msg_Max_Length" to a new value. > > And recompile the run-times. > > > > /P > > Thanks. I was hoping that there might be some "configuration" switch/pragma to do it. However, if that ends up being the only way I guess that we would as for step by step from AdaCore or ask for a wavefront release. > > (I'll have to read some more looking for a less "drastic" way before I ask to have the contact person ask Adacore.) > > Vincent Marciante Don't hesitate to contact AdaCore with questions. They are very helpful and can also help you include the run-time in your own project, such that the run-time library is automatically rebuilt when you change it. I don't think a wavefront is the way forward for you - I think that learning to configure/change the run-time yourself and rebuilding it is very helpful. We do that ourselves and it's no big deal. But again, ask AdaCore. Regards, Mark L ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: GNAT user-specified (via Raise_Exception) warning message size limit 2018-02-18 22:33 ` Mark Lorenzen @ 2018-02-18 23:09 ` Simon Wright 2018-02-19 7:24 ` briot.emmanuel 2018-02-19 15:31 ` marciant 1 sibling, 1 reply; 19+ messages in thread From: Simon Wright @ 2018-02-18 23:09 UTC (permalink / raw) Mark Lorenzen <mark.lorenzen@gmail.com> writes: > Don't hesitate to contact AdaCore with questions That's what your organisation is paying for! and they like to get your questions! ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: GNAT user-specified (via Raise_Exception) warning message size limit 2018-02-18 23:09 ` Simon Wright @ 2018-02-19 7:24 ` briot.emmanuel 0 siblings, 0 replies; 19+ messages in thread From: briot.emmanuel @ 2018-02-19 7:24 UTC (permalink / raw) > That's what your organisation is paying for! and they like to get your > questions! As a former AdaCore employee, I confirm they like to get questions from supported customers. After all, that's what helps contract renewal at the end of the year ! AdaCore has not always done a great job with unsupported customers, though. This is mostly because they already get so many new tickets every day (including the internally generated one, I think that must be around 60 a day or something -- given the relatively small size of the company and the time it takes to properly answer them, that's a lot). But no report gets ignored in the end. For customer ones, there are plenty of scripts in place to catch unanswered requested. For unsupported customers, the initial reply might be of the kind "already fixed", in which case you can only wait for the next release, or "can't reproduce, we're closing", in which case it falls back to you to provide more details (this kind of message is in theory not sent to supported customers where a long dialog might take place to help AdaCore reproduce with the specific version of the compiler you use). Once AdaCore has been able to reproduce the issue, bugs are generally fixed pretty fast, especially in the compiler (and I like to think in GNATCOLL and GPS while I was there :-) Enhancement requests are another story, since there's a fine balance between adding new features, and having to maintain them forever afterwards. Sometimes it takes a few similar reports until a general solution can be found, for instance. Emmanuel ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: GNAT user-specified (via Raise_Exception) warning message size limit 2018-02-18 22:33 ` Mark Lorenzen 2018-02-18 23:09 ` Simon Wright @ 2018-02-19 15:31 ` marciant 2018-02-22 15:08 ` marciant 1 sibling, 1 reply; 19+ messages in thread From: marciant @ 2018-02-19 15:31 UTC (permalink / raw) > Don't hesitate to contact AdaCore with questions. They are very helpful and can also help you include the run-time in your own project, such that the run-time library is automatically rebuilt when you change it. I don't think a wavefront is the way forward for you - I think that learning to configure/change the run-time yourself and rebuilding it is very helpful. We do that ourselves and it's no big deal. But again, ask AdaCore. > > Regards, > > Mark L Thanks for the information regarding the ease of recompiling the the runtime. I'll forward this to my manager. He wanted me to ask here before asking AdaCore. Vincent Marciante ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: GNAT user-specified (via Raise_Exception) warning message size limit 2018-02-19 15:31 ` marciant @ 2018-02-22 15:08 ` marciant 2018-02-22 19:48 ` marciant 0 siblings, 1 reply; 19+ messages in thread From: marciant @ 2018-02-22 15:08 UTC (permalink / raw) > Thanks for the information regarding the ease of recompiling the the runtime. I'll forward this to my manager. He wanted me to ask here before asking AdaCore. We contacted AdaCore and I'll eventually post the end result. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: GNAT user-specified (via Raise_Exception) warning message size limit 2018-02-22 15:08 ` marciant @ 2018-02-22 19:48 ` marciant 2018-02-22 20:27 ` Simon Wright 0 siblings, 1 reply; 19+ messages in thread From: marciant @ 2018-02-22 19:48 UTC (permalink / raw) On Thursday, February 22, 2018 at 10:08:35 AM UTC-5, Vincent Marciante wrote: > > Thanks for the information regarding the ease of recompiling the the runtime. I'll forward this to my manager. He wanted me to ask here before asking AdaCore. > > > We contacted AdaCore and I'll eventually post the end result. The response was essentially: Not trivial on Windows; find a workaround instead. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: GNAT user-specified (via Raise_Exception) warning message size limit 2018-02-22 19:48 ` marciant @ 2018-02-22 20:27 ` Simon Wright 2018-02-22 21:43 ` Mark Lorenzen ` (2 more replies) 0 siblings, 3 replies; 19+ messages in thread From: Simon Wright @ 2018-02-22 20:27 UTC (permalink / raw) marciant@earthlink.net writes: > On Thursday, February 22, 2018 at 10:08:35 AM UTC-5, Vincent Marciante wrote: >> > Thanks for the information regarding the ease of recompiling the >> the runtime. I'll forward this to my manager. He wanted me to ask >> here before asking AdaCore. >> >> >> We contacted AdaCore and I'll eventually post the end result. > > The response was essentially: Not trivial on Windows; find a > workaround instead. When (~2005) we had a problem with the runtime - we wanted to arrange matters so that we could stream from our big-endian PowerPC target (without changing the deliverable runtime) to our little-endian Windows host machines - we were able to do the following (simple version): * Copy the supplied s-strxdr.adb (now I see named s-stratt_xdr.adb) as s-stratt.adb to our own directory. This version streams data using eXternal Data Representation forms. * Rebuild (with gnatmake) with the -a switch, which rebuilds the changed runtime unit(s) and any units which depend on them. I don't remember asking AdaCore about this (though we were supported). However, this cunning wheeze doesn't work with gprbuild. As I recall, the Pro RTS came with a Makefile and instructions for rebuilding the RTS. Perhaps things have changed. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: GNAT user-specified (via Raise_Exception) warning message size limit 2018-02-22 20:27 ` Simon Wright @ 2018-02-22 21:43 ` Mark Lorenzen 2018-02-22 22:09 ` marciant 2018-02-23 8:25 ` briot.emmanuel 2 siblings, 0 replies; 19+ messages in thread From: Mark Lorenzen @ 2018-02-22 21:43 UTC (permalink / raw) On Thursday, February 22, 2018 at 9:27:31 PM UTC+1, Simon Wright wrote: > > However, this cunning wheeze doesn't work with gprbuild. > > As I recall, the Pro RTS came with a Makefile and instructions for > rebuilding the RTS. Perhaps things have changed. I don't know about the native run-times, but things have changed for bare-board targets. Now you make a copy of the RTS, 'with' the copied RTS's project file in your own project file and point to the copied RTS using the project attribute Runtime (see http://docs.adacore.com/live/wave/gnat_ugx/html/gnat_ugx/gnat_ugx/specifying_the_run-time_library_and_target.html#selecting-the-run-time-library) When you modify the copied RTS, it is automatically re-built as part of building your project as any other with'ed project. It's really easy. Regards, Mark L ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: GNAT user-specified (via Raise_Exception) warning message size limit 2018-02-22 20:27 ` Simon Wright 2018-02-22 21:43 ` Mark Lorenzen @ 2018-02-22 22:09 ` marciant 2018-02-23 8:25 ` briot.emmanuel 2 siblings, 0 replies; 19+ messages in thread From: marciant @ 2018-02-22 22:09 UTC (permalink / raw) On Thursday, February 22, 2018 at 3:27:31 PM UTC-5, Simon Wright wrote: >... Thanks for the detailed instructions. However, having thought about how to do what you said, a detail that I had not realize was critical came to mind: The project actually depends on a precompiled library from another organization _that_we_can_not_recompiled_by_us_! So - probably obviously - the "adjust the runtime" "solution" almost definitely would not be a possible solution at all! :-( Right? Therefore, as of now, I think that the only possible solution is to adjust our code along the lines of the previous suggestions. Thank you all for effort and help. Vincent Marciante ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: GNAT user-specified (via Raise_Exception) warning message size limit 2018-02-22 20:27 ` Simon Wright 2018-02-22 21:43 ` Mark Lorenzen 2018-02-22 22:09 ` marciant @ 2018-02-23 8:25 ` briot.emmanuel 2018-02-23 8:56 ` Simon Wright 2 siblings, 1 reply; 19+ messages in thread From: briot.emmanuel @ 2018-02-23 8:25 UTC (permalink / raw) > * Rebuild (with gnatmake) with the -a switch, which rebuilds the changed > runtime unit(s) and any units which depend on them. > > However, this cunning wheeze doesn't work with gprbuild. As I am sure Simon already knows, but might be useful for others (it doesn't solve the problem highlighted by Simon, though): You can actually use gprbuild to recompile locally the bodies of runtime files. You just have to put them in your source directories, and change the project file to make sure the file is compiled with -gnatg. I have done that quite often for System.Memory project Default is package Compiler is for Switches ("s-memory.adb") use ("-gnatg"); end Compiler; end Default; This trick however doesn't work for specs, since it doesn't recompile all runtime units that depend on them unless they are part of the project. You might get away with creating a "runtime.gpr" project that uses for source dirs the runtime location, and forces the -gnatg switch. Emmanuel ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: GNAT user-specified (via Raise_Exception) warning message size limit 2018-02-23 8:25 ` briot.emmanuel @ 2018-02-23 8:56 ` Simon Wright 0 siblings, 0 replies; 19+ messages in thread From: Simon Wright @ 2018-02-23 8:56 UTC (permalink / raw) briot.emmanuel@gmail.com writes: > As I am sure Simon already knows, but might be useful for others (it > doesn't solve the problem highlighted by Simon, though): > > You can actually use gprbuild to recompile locally the bodies of > runtime files. You just have to put them in your source directories, > and change the project file to make sure the file is compiled with > -gnatg. I have done that quite often for System.Memory > > project Default is > package Compiler is > for Switches ("s-memory.adb") use ("-gnatg"); > end Compiler; > end Default; I don't think I've ever done this - failing to do it would explain why, even after precompiling s-stratt.adb with -gnatpg (which gnatmake -a did), gprbuild with the default .gpr wouldn't build. > This trick however doesn't work for specs, since it doesn't recompile > all runtime units that depend on them unless they are part of the > project. You might get away with creating a "runtime.gpr" project > that uses for source dirs the runtime location, and forces the -gnatg > switch. I suppose other runtime units would need recompiling if any part of this body was inlined. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: GNAT user-specified (via Raise_Exception) warning message size limit 2018-02-16 18:44 GNAT user-specified (via Raise_Exception) warning message size limit marciant 2018-02-16 18:59 ` Per Sandberg @ 2018-02-17 0:03 ` Randy Brukardt 1 sibling, 0 replies; 19+ messages in thread From: Randy Brukardt @ 2018-02-17 0:03 UTC (permalink / raw) <marciant@earthlink.net> wrote in message news:789f6417-5e6f-4d5f-8abb-80246f4f405a@googlegroups.com... ... >It seems that although quite long messages are accepted at calls to it, the >message then retrieved and printed within a handler that uses >Ada.Exceptions.Exception_Message on the occurrence only returns a >truncated part of the original message - around the first 200 characters >are returned and the rest is truncated. For what it's worth, portable Ada code should not depend on exception messages longer than 200 characters, see RM 11.4.1(18). For Janus/Ada, the truncation happens because an exception occurrence only has space for 200 characters. One could change the limited, but recompilation of the runtime clearly would be needed since it would change the definition/representation of the Exception_Occurrence type. It sounds like GNAT is similar. Randy. ^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2018-02-23 8:56 UTC | newest] Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-02-16 18:44 GNAT user-specified (via Raise_Exception) warning message size limit marciant 2018-02-16 18:59 ` Per Sandberg 2018-02-16 19:11 ` marciant 2018-02-16 20:58 ` Anh Vo 2018-02-16 23:22 ` marciant 2018-02-17 7:15 ` J-P. Rosen 2018-02-17 16:38 ` marciant 2018-02-18 22:33 ` Mark Lorenzen 2018-02-18 23:09 ` Simon Wright 2018-02-19 7:24 ` briot.emmanuel 2018-02-19 15:31 ` marciant 2018-02-22 15:08 ` marciant 2018-02-22 19:48 ` marciant 2018-02-22 20:27 ` Simon Wright 2018-02-22 21:43 ` Mark Lorenzen 2018-02-22 22:09 ` marciant 2018-02-23 8:25 ` briot.emmanuel 2018-02-23 8:56 ` Simon Wright 2018-02-17 0:03 ` Randy Brukardt
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox