1. Debug Block?
- Posted by Jeremy Cowgar <jeremy at co?gar?com>
May 11, 2008
-
Last edited May 12, 2008
I was looking through the feature requests on the SF.net page trying to clean
things up. A lot of old suggestions exist, some of which were already
implemented, so I closed them. Anyway, I ran across a feature request by CK
Lester and figured I would bring his suggestion to the forum for discussion so we
can either implement (do not think it would be hard) or clear the suggestion. No
reason to have it sit there in limbo for no reason. Keep in mind, I am just
brining this to peoples attention. It's not my idea, although, I think it's a
good one.
http://sourceforge.net/tracker/index.php?func=detail&aid=1771686&group_id=182827&atid=902785
He is basically suggesting the ability to remove debug code in the final copies
of your Euphoria source. His suggestion is instead of:
--- code
if DEBUG then
printf(1, "Loop var is %d\n", {loopVar})
end if
--- code
which would be included in your final code, therefore causing extra processing
for no reason (has to check DEBUG condition). His idea is that a debug statement
be added:
with debug
--- code
. printf(1, "Loop var is %d\n", {loopVar})
--- code
His suggestion was any line starting with a . would be debug code. Thus, when
with debug or without debug is in the source code, the lines starting with .
would not even be emitted to the final versions of your Euphoria programmer,
thus, debug code would cause no slow down in your final version of your app.
I also thought possibly instead of . you could:
with debug
debug
printf(1, "Loop var is %d\n", {loopVar})
-- more debug code
end debug
Over all I do not see any bad side effects, only benefits, but wanted to get
your input. I do think a more defined block, such as debug ... end debug would
make the source code a bit cleaner and more easily understood, but everyone can
go read CK's feature request on the SF URL listed above.
--
Jeremy Cowgar
http://jeremy.cowgar.com
2. Re: Debug Block?
Jeremy Cowgar wrote:
> I think it's a good one.
Me too. It would be similar to the D Programming Language's facility...
debug
{
... statements ...
}
Some points to consider:
If we use some 'block' syntax, the block needs to be able to span routines as
well as statements, in order to comment out routines just used for debugging.
Eg.
debug
procedure Logger(sequence text)
-- write text to logging file.
end procedure
end debug
or even ...
debug
include stddebug.e as dbg
dbg:init("My App", "/var/debug.log", "append")
end debug
If we use the line prefix style of syntax, then I suggest a double dot, which is
analogous with the double dash for comments. It also visually stands out more.
.. include stddebug.e as dbg
.. dbg:init("My App", "/var/debug.log", "append")
Also, some way of turning it off/on from the command line instead of having to
edit source code, should be considered.
e.g.
exu myapp.e --eu:debug=on
Finally, to borrow from D language, we could support debug variations.
debug(stage1)
dbg:log("Beginning Stage 1")
vLimit = 1
end debug
debug(stage2)
dbg:log("Beginning Stage 2")
vLimit = 25
end debug
and invoked by ...
ex myapp.e --eu:debug=stage1
--
Derek Parnell
Melbourne, Australia
Skype name: derek.j.parnell
3. Re: Debug Block?
I haven't read the entire proposal in detail, but wouldn't "with debug" and
"without debug" be more consistent with the way we currently do things?
It's an instruction to the interpreter, like "with trace" etc. instead of
another kind of construct.
--
A complex system that works is invariably found to have evolved from a simple
system that works.
--John Gall's 15th law of Systemantics.
"Premature optimization is the root of all evil in programming."
--C.A.R. Hoare
j.
4. Re: Debug Block?
Jeremy Cowgar wrote:
>
> I was looking through the feature requests on the SF.net page trying to clean
> things up. A lot of old suggestions exist, some of which were already
> implemented,
> so I closed them. Anyway, I ran across a feature request by CK Lester and
> figured
> I would bring his suggestion to the forum for discussion so we can either
> implement
> (do not think it would be hard) or clear the suggestion. No reason to have it
> sit there in limbo for no reason. Keep in mind, I am just brining this to
> peoples
> attention. It's not my idea, although, I think it's a good one.
>
> <a
> href="http://sourceforge.net/tracker/index.php?func=detail&aid=1771686&group_id=182827&atid=902785">http://sourceforge.net/tracker/index.php?func=detail&aid=1771686&group_id=182827&atid=902785</a>
>
> He is basically suggesting the ability to remove debug code in the final
> copies
> of your Euphoria source. His suggestion is instead of:
>
> }}}
<eucode>
> --- code
> if DEBUG then
> printf(1, "Loop var is %d\n", {loopVar})
> end if
> --- code
> </eucode>
{{{
>
> which would be included in your final code, therefore causing extra processing
> for no reason (has to check DEBUG condition). His idea is that a debug
> statement
> be added:
>
> }}}
<eucode>
> with debug
>
> --- code
> . printf(1, "Loop var is %d\n", {loopVar})
> --- code
> </eucode>
{{{
>
> His suggestion was any line starting with a . would be debug code. Thus, when
> with debug or without debug is in the source code, the lines starting with .
> would not even be emitted to the final versions of your Euphoria programmer,
> thus, debug code would cause no slow down in your final version of your app.
>
> I also thought possibly instead of . you could:
>
> }}}
<eucode>
> with debug
>
> debug
> printf(1, "Loop var is %d\n", {loopVar})
> -- more debug code
> end debug
> </eucode>
{{{
>
> Over all I do not see any bad side effects, only benefits, but wanted to get
> your input. I do think a more defined block, such as debug ... end debug would
> make the source code a bit cleaner and more easily understood, but everyone
> can go read CK's feature request on the SF URL listed above.
>
> --
> Jeremy Cowgar
> <a href="http://jeremy.cowgar.com">http://jeremy.cowgar.com</a>
I certainly vote for it, in the debug ... end debug form.
As far as I remember, there are only 4 routines in emit.e that would need to be
guarded by an "if not DEBUG then" statement. At least in the 3.1 source. So it is
definitely not hard to do.
I would expect thie sith/sithout debug directive to behave like similar ones, ie
the status flag is saved when a new include file starts being parsed, and
restored when that parsing is complete.
CChris
5. Re: Debug Block?
Jeremy Cowgar wrote:
>
> I was looking through the feature requests on the SF.net page trying to clean
> things up. A lot of old suggestions exist, some of which were already
> implemented,
> so I closed them. Anyway, I ran across a feature request by CK Lester and
> figured
> I would bring his suggestion to the forum for discussion so we can either
> implement
> (do not think it would be hard) or clear the suggestion. No reason to have it
> sit there in limbo for no reason. Keep in mind, I am just brining this to
> peoples
> attention. It's not my idea, although, I think it's a good one.
>
> <a
> href="http://sourceforge.net/tracker/index.php?func=detail&aid=1771686&group_id=182827&atid=902785">http://sourceforge.net/tracker/index.php?func=detail&aid=1771686&group_id=182827&atid=902785</a>
>
> He is basically suggesting the ability to remove debug code in the final
> copies
> of your Euphoria source. His suggestion is instead of:
>
> }}}
<eucode>
> --- code
> if DEBUG then
> printf(1, "Loop var is %d\n", {loopVar})
> end if
> --- code
> </eucode>
{{{
>
> which would be included in your final code, therefore causing extra processing
> for no reason (has to check DEBUG condition). His idea is that a debug
> statement
> be added:
>
> }}}
<eucode>
> with debug
>
> --- code
> . printf(1, "Loop var is %d\n", {loopVar})
> --- code
> </eucode>
{{{
>
> His suggestion was any line starting with a . would be debug code. Thus, when
> with debug or without debug is in the source code, the lines starting with .
> would not even be emitted to the final versions of your Euphoria programmer,
> thus, debug code would cause no slow down in your final version of your app.
>
> I also thought possibly instead of . you could:
>
> }}}
<eucode>
> with debug
>
> debug
> printf(1, "Loop var is %d\n", {loopVar})
> -- more debug code
> end debug
> </eucode>
{{{
>
> Over all I do not see any bad side effects, only benefits, but wanted to get
> your input. I do think a more defined block, such as debug ... end debug would
> make the source code a bit cleaner and more easily understood, but everyone
> can go read CK's feature request on the SF URL listed above.
>
> --
> Jeremy Cowgar
> <a href="http://jeremy.cowgar.com">http://jeremy.cowgar.com</a>
I would like to point out that this is actually a specialized form of
conditional compilation.
A general conditional compilation system would provide this behavior and a lot
more.
6. Re: Debug Block?
Daryl Border wrote:
>
> I would like to point out that this is actually a specialized form of
> conditional
> compilation.
> A general conditional compilation system would provide this behavior and a lot
> more.
Can you give an example of what you are speaking of? Are you talking in regards
to a C like preprocessor?
#ifdef DEBUG
puts(1, "Hello World\n")
#endif
#ifdef WINDOWS
puts(1, "Windows\n")
#endif
?
--
Jeremy Cowgar
http://jeremy.cowgar.com
7. Re: Debug Block?
Derek Parnell wrote:
>
> Also, some way of turning it off/on from the command line instead of having
> to edit source code, should be considered.
>
> e.g.
> exu myapp.e --eu:debug=on
Euphoria 4.0 will introduce command line switches that are supplied before
the program. There are currently only 2, which affect the directories used
as include directories, so your example would maybe look like:
$ exu --debug=on myapp.e
Matt
8. Re: Debug Block?
Jeremy Cowgar wrote:
>
> Daryl Border wrote:
> >
> > I would like to point out that this is actually a specialized form of
> > conditional
> > compilation.
> > A general conditional compilation system would provide this behavior and a
> > lot
> > more.
>
> Can you give an example of what you are speaking of? Are you talking in
> regards
> to a C like preprocessor?
>
> #ifdef DEBUG
> puts(1, "Hello World\n")
> #endif
> #ifdef WINDOWS
> puts(1, "Windows\n")
> #endif
>
> ?
>
> --
> Jeremy Cowgar
> <a href="http://jeremy.cowgar.com">http://jeremy.cowgar.com</a>
You've got it. The with debug clause is a compiler directive telling the parser
to treat any line starting with . as a comment. The #ifdef WINDOWS clause does
the same thing to lines up to the #endif, if WINDOWS is not defined.
9. Re: Debug Block?
I agree with Daryl border, I have always missed a precompiler in euphoria.
Daryl Border wrote:
>
> Jeremy Cowgar wrote:
> >
> > Daryl Border wrote:
> > >
> > > I would like to point out that this is actually a specialized form of
> > > conditional
> > > compilation.
> > > A general conditional compilation system would provide this behavior and a
> > > lot
> > > more.
> >
> > Can you give an example of what you are speaking of? Are you talking in
> > regards
> > to a C like preprocessor?
> >
> > #ifdef DEBUG
> > puts(1, "Hello World\n")
> > #endif
> > #ifdef WINDOWS
> > puts(1, "Windows\n")
> > #endif
> >
> > ?
> >
> > --
> > Jeremy Cowgar
> > <a href="http://jeremy.cowgar.com">http://jeremy.cowgar.com</a>
>
> You've got it. The with debug clause is a compiler directive telling the
> parser
> to treat any line starting with . as a comment. The #ifdef WINDOWS clause does
> the same thing to lines up to the #endif, if WINDOWS is not defined.
