Damir, >1) Because there were bugs in her code, she was forced to leave ROOT >many times without explanation (seg faults, floating point errors, >etc...). Can somebody explain why is it impossible for the interpreter >to say > >"there is a seg violation in the line xxx of file yyy.C" > >instead of just " ***** Break segmentation violation ****" ? > >i.e. behave like a debugger, at least for the interpreted part. This is possible. Bare CINT has a error handler which does exactly what you want. ROOT has different error handler. It should be easy to implement the same think there. Fons, G__printlinenum() will print 'FILE:xxx LINE:yyy'. Please add above message. >Is there a way to set a "debug level" in CINT or a "security level" that >would check the variables before using them ? >Does removing the bytecode (.O0) give more security ? There is a security level control command #pragma security level[0-5] However, this command will not give you what you want. The security is at the cost of severe syntax limitation. It is likely that most of your code will not run anymore with higher security level. >2) Furthermore, it looks like the interpreter environment is messed up >by such events. In that case, nothing helps. One has sometimes to kill >the root.exe process. Not very handy ! For a simple class, we had to do >it quite a few (maybe 10) times. I think the problem is combination of ROOT and CINT. Using bare CINT, SEGV or Bus error does not occur very often. Many of the obvious C/C++ errors are detected by CINT. In my experiece, such problem often happens when error checking is library dependent. >3) Is there a way to have something similar to the core file produced by >gdb in case of a fatal error, that one would be able to look at to see >where was the error ? Fons, do you have idea? >4) When using the step mode, there are a few features from the ROOT >readline missing (last command with up-arrow for example) Will you elaborate this problem? Concerned about the debugger interface, ROOT and bare CINT has different command line interface. Bare CINT focuses more toward debugging capability and ROOT focuses on command line interpreting. Will you try bare CINT's debugger interface which is more resemble to gdb and tell me how you feel. To get bare CINT you need to compile from cint.tar.gz. >5) I was advertising ROOT as "use the interpreter, build there your code >and compile it if it's not fast enough". This remains true but every >user has to balance the various options, interpreting or compiling, in >particular from the ease of debugging point of view. > >We concluded that, for the time being, the best thing would be to compile >the code, use gdb, and use the interpreter only for real scripting, that is >being able to change script very easily, etc... without trying to make >complicated C++ code . This is why a scripting language is used for, >after all... > >What are your advices ? Is there a path to improve cint, or perhaps the >root-cint interface, in the future ? I agree with you to some extent. For complicated C++ code, it is better to use compiler directly. For simple C++ code, however, CINT can be a handy solution. After all, CINT is designed to be a TCL in C++ syntax. As I described above, there are a couple of things which can be improved on ROOT. I also would like to comment that this problem is dependent on ROOT library too. Bare CINT does not crash as often as ROOT/CINT. Masaharu Goto
This archive was generated by hypermail 2b29 : Tue Jan 04 2000 - 00:43:29 MET