2. Re: debugging
On 6 Dec 2001, at 16:53, tone.skoda at siol.net wrote:
>
> is there a way i can tell interperer which routine should it call when program
> crashes?
>
> i thought about re-defining crash_message () but i dont think it would work
>
> i want to open with notepad my debug.txt file in which i was writing debug
> info
> at program crash
If you use a text editor like TextPad, just keep it open, and when you click
the debug.txt tab in the editor, TextPad will go get the new crash file for you.
So will ConText.
Kat
3. Re: debugging
- Posted by tone.skoda at siol.net
Dec 06, 2001
David, unfortunately I don't have the source code of interpreter.
By the way, how does the source of Euphoria look? Any surprises?
Rob: What I would like to know is: If David or anyone else adds that
function set_crash_routine (), can he put compiled exw.exe (I hardly use
ex.ex) on the net for anyone to download?
----- Original Message -----
From: "David Cuny" <euphoria_coder at HOTMAIL.COM>
To: "EUforum" <EUforum at topica.com>
Subject: RE: debugging
>
> tone skoda wrote:
>
> >is there a way i can tell interperer which routine should it call when
> >[the] program crashes?
>
> First, I hope this complies with the Euphoria source license:
>
> You can publicly discuss the algorithms used by our source
> code in open forums, and you can mention the names of C
> routines, variables and other identifiers in the code, but
> you must not reveal actual lines of source code.
>
>
> Anyway, if you had the interpreter source, I'd guess it would not be too
> difficult to add in. The external definition might look like:
>
> global sub set_crash_routine( int id )
> machine_proc( M_CRASH_ROUTINE, call_back(id) )
> end sub
>
> Define M_CRASH_ROUTINE in execute.h, and add it to the case statement in
> machine.c. It would just have to assign the value to some global variable,
> crash_routine.
>
> Look in rterror.c for CleanUpError, which handles most of the errors.
Before
> handling crash_message, add something like this:
>
> /* did the user set a crash routine? */
> if (crash_routine != NULL && crash_called == 0) {
>
> /* clear flag - love that name! */
> gameover = 0;
>
> /* prevent from being called multiple times */
> crash_called++;
>
> /* call the function pointer */
> (void crash_routine)(void);
>
> /* restore flag */
> gameover = 1;
> }
>
> Something like that, anyway. No doubt, there's bound to be a nasty
> side-effect here I didn't take into account...
>
> If I figure out the correct cast for the function pointer, I might give it
a
> try.
>
> -- David Cuny
>
>
>
>
4. Re: debugging
Tone Skoda writes:
> Rob: What I would like to know is: If David or anyone else adds that
> function set_crash_routine (), can he put compiled exw.exe (I hardly use
> ex.ex) on the net for anyone to download?
Yes he can.
If you look at the source license, I only ask that you not
try to emulate the features that I am selling in the
Complete Edition - binding, tracing, profiling.
The source for these has been removed.
Anything else you want to do is fair game.
You can even sell your version if you want.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
5. debugging
It would be good if we could be able to find out if type_check is on or off,
like a debug variable.
something like:
if type_check then
... do debugging checks
end if
Also, assert() statement would be usefull:
assert (debug_function ())
if type_check would would be on above statement would be evaluated
else it would get skipped and also debug_function () wouldnt be executed.
I use my own assert () procedure but will have to write preprocessor to
remove assert() calls if I want maximal speed.
6. Re: debugging
10963508 at europeonline.com wrote:
> It would be good if we could be able to find out if type_check is on
> or off, like a debug variable. something like:
>
> if type_check then
> ... do debugging checks
> end if
That might be a useful construct, but only in terms of debugging. If you're
debugging you may as well assign a sequence to an atom and see if the
program crashes. If not, type_checking is off. ;)
> Also, assert() statement would be usefull:
>
> assert (debug_function ())
This isn't quite as informative as the C/C++ equivalent, but it serves its
purpose...
type bool(object b)
if integer(b) and b = 1 or b = 0
then return 1 end if return 0
end type
global bool ASSERT
ASSERT = 1 -- set to 0 to turn assert()s off
global type assert(bool x)
if ASSERT then return x = 1 end if return 1
end type
with trace
atom b
integer a
a = 5
b = 2.2 * sqrt(a)
trace(3) -- check the manual
assert(a > b) -- passes
b *= 1.1
assert(a > b) -- fails
Carl
7. Re: debugging
----- Original Message -----
From: "Carl W." <euphoria at cyreksoft.yorks.com>
> This isn't quite as informative as the C/C++ equivalent, but it serves its
> purpose...
>
> type bool(object b)
> if integer(b) and b = 1 or b = 0
> then return 1 end if return 0
> end type
>
> global bool ASSERT
> ASSERT = 1 -- set to 0 to turn assert()s off
> global type assert(bool x)
> if ASSERT then return x = 1 end if return 1
> end type
>
> with trace
>
> atom b
> integer a
>
> a = 5
> b = 2.2 * sqrt(a)
>
> trace(3) -- check the manual
>
> assert(a > b) -- passes
>
> b *= 1.1
> assert(a > b) -- fails
Here is problem that a > b expression gets evaluates if debugging is on or
off and that slows down program. even worse is if you execute expensive
debuggin function inside assert () that function is allways executed,
debugging on or off.
