1. Variables address (Reformulated)
- Posted by André Drummond <andre_drummond at bol.com.br> Sep 16, 2005
- 534 views
Sorry everyone, I found a message from Robert Craig that repudiate the idea of getting a euphoria variable address, as he say: "I firmly believe this would be a very bad thing to do" So, considering that, I want to reformulate my question. Can anyone give me an idea of an efficient method to create something like the ex.err file in a C translated program? My current solution is to set a global variable with the values of some relevant variables. I do that in many parts of the code where I "feel" that a crash may occur, let´s put in another way... any critical block in the code is preceded by a call to a routine that set my global variable with some values passed as parameters, usually variables used in the "critical block". So, when a crash occur, another routine, designated by crash_routine(), takes control and just prints out the values from my global variable. What about that? Watch out SUN J2EE... just kidding, I know it is a "very" amateur approach. So, any creative ideas. Thank you all, André Drummond
2. Re: Variables address (Reformulated)
- Posted by DB James <larch at adelphia.net> Sep 16, 2005
- 544 views
André Drummond wrote: > > Sorry everyone, > > I found a message from Robert Craig that repudiate the idea of > getting a euphoria variable address, as he say: > > "I firmly believe this would be a very bad thing to do" > > So, considering that, I want to reformulate my question. > > Can anyone give me an idea of an efficient method to create something > like the ex.err file in a C translated program? > > My current solution is to set a global variable with the > values of some relevant variables. I do that in many parts of the code > where I "feel" that a crash may occur, let´s put in another way... > any critical block in the code is preceded by a call to a routine that > set my global variable with some values passed as parameters, > usually variables used in the "critical block". > > So, when a crash occur, another routine, designated by crash_routine(), > takes control and just prints out the values from my global variable. > > What about that? Watch out SUN J2EE... just kidding, > I know it is a "very" amateur approach. > > So, any creative ideas. > > Thank you all, > André Drummond > Hello André, I usually pass by answering this general kind of thing because I always imagine others have more sophisticated techniques. However, I'll dive in with an idea: what about not waiting for a crash to record what your program is doing? When I am developing a program I set the constant DEBUG=1, and pepper my code with some version of the code below: if DEBUG then state=AppendFile(DEBUGFILE,relevantData,"Current Prg Report-Section X") CheckState(state,"DEBUG:File problem: AppendFile() failed on Report X") end if The constant DEBUGFILE is set to the fullpath of the debug file and AppendFile() does what it says. Obviously if the program fails at a certain point, the previously saved info is readily available. If you use a program similar to Edita, you would just click the debug file's tab and re-open it. And if some sections are working fine, just delete or comment-out the DEBUG stuff. If you have no access to setting DEBUG, then set up a way to turn debugging on and off. --Quark
3. Re: Variables address (Reformulated)
- Posted by Greg Haberek <ghaberek at gmail.com> Sep 16, 2005
- 557 views
> I found a message from Robert Craig that repudiate the idea of > getting a euphoria variable address, as he say: > > "I firmly believe this would be a very bad thing to do" I once hacked a dll function to return the address of a Euphoria object passed to it. I lost the code, but I may be able to recreate it. The problem is that you have to use an external source to "tell" you what the address is, I don't really think there's a way to do it from the interpreter. The reason Rob thinks its a bad idea, I believe, is because of reference counting, and by altering the variable via its address in memory, you could cause a memory leak. ~Greg