I7: A cool debugging trick, offered in exchange for pointers on inline I6 phrases
Erik Temple
inclusions, but I'll ask after presenting a quick (and related) trick for
writing debugging statements, because I think some might find it useful:
If you use debugging messages to keep track of what code is firing when,
or the state of things, you may find it annoying to comment it out, delete
it, or otherwise remove it from your code before releasing it. These two
say phrases make this unnecessary:
<code>
To say debug:
(- #ifdef DEBUG; -)
To say end debug:
(- #endif; -)
</code>
Now, you can write things along these lines:
say "[debug]Begin attack routine.[end debug]".
Everything between the debug tokens will be printed only in debugging
builds, not released builds. (The text also won't appear at all in the
final game file, meaning that it won't be seen by decompilers.) You can
also include a debug phrase within a larger say phrase, e.g.:
say "The count sweeps his cape back with a flourish, exposing a large
knife at his belt.[debug]The count is angry.[end debug]".
You can also define your own use option--e.g., "Use special debuggers
translates as (- Constant SP_DEBUG; -)"--and replace the "DEBUG" in the
"to say debug" inline I6 code with SP_DEBUG to see the debuggers only when
you want them by including "Use special debuggers" somewhere in your
source.
Inspired by the GWindows console window, I am expanding on this by having
the inline phrases redirect to a different window (the console-window),
print the text between them, and then switch back to the main-window. It
would look like this:
<code>
To say debug:
(- #ifdef SP_DEBUGGING; if ( (+ console-window +) hasnt g_present)
rfalse; glk_set_window( (+ console-window +).ref_number); -)
To say end debug:
(- glk_set_window( gg_mainwin ); #endif; -)
</code>
...except that you can't refer to an I7 object in an inline I6 phrase
using the (+ +) brackets--Inform misinterprets the + as an arithmetic
operator. Is there another way to refer to an I7 object from an inline
phrase, or is this simply a feature that is left out of Inform?
(Please note that I do have a workaround for this, but I'd like to do it
simply and cleanly, i.e. using the I7 object name in the inline phrase if
possible. The code of the workaround is after my signature--in case you
have a more elegant workaround.)
Thanks,
Erik
----
Include (-
Global CONSOLE_ALIAS = 0;
[ AliasWindow win;
CONSOLE_ALIAS = win;
];
-) after "Definitions.i6t".
To get alias for (win - a g-window):
(- AliasWindow ({win}); -)
When play begins:
get alias for console-window.
To say debug:
(- #ifdef SP_CONSOLE; if ( CONSOLE_ALIAS hasnt g_present) rfalse;
glk_set_window( CONSOLE_ALIAS.ref_number); -)
To say end debug:
(- glk_set_window( gg_mainwin ); #endif; -)
Andrew Plotkin
>
> Inspired by the GWindows console window, I am expanding on this by having
> the inline phrases redirect to a different window (the console-window),
> print the text between them, and then switch back to the main-window. It
> would look like this:
>
> <code>
>
> To say debug:
> (- #ifdef SP_DEBUGGING; if ( (+ console-window +) hasnt g_present)
> rfalse; glk_set_window( (+ console-window +).ref_number); -)
>
> To say end debug:
> (- glk_set_window( gg_mainwin ); #endif; -)
>
> </code>
>
> ...except that you can't refer to an I7 object in an inline I6 phrase
> using the (+ +) brackets--Inform misinterprets the + as an arithmetic
> operator. Is there another way to refer to an I7 object from an inline
> phrase, or is this simply a feature that is left out of Inform?
You can't do it in general, but you can refer to the arguments of the
phrase. This leads to the following, possibly equally icky workaround:
To say debug:
debug with console console-window;
To debug with console (win - a g-window):
(- #ifdef SP_DEBUGGING; if ( {win} hasnt g_present)
rfalse; glk_set_window( {win}.ref_number); -)
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
Erik Temple
wrote:
That may be a little icky, but I don't think it's as icky as the
workaround I was using--I'm definitely willing to use it! Thanks!
(Actually, in the context of an extension, which this will be, it's an
improvement in another way in that it allows the user to redirect output
to a different window if desired.)
Just out of curiosity, is there a technical reason why (+ I7 entity +)
doesn't work in inline inclusions?
--Erik
Andrew Plotkin
>
> Just out of curiosity, is there a technical reason why (+ I7 entity +)
> doesn't work in inline inclusions?
I don't know. Maybe the I7 source parsing requires too much awareness
of the context.
Erik Temple
wrote:
> You can't do it in general, but you can refer to the arguments of the
> phrase. This leads to the following, possibly equally icky workaround:
>
> To say debug:
> debug with console console-window;
>
> To debug with console (win - a g-window):
> (- #ifdef SP_DEBUGGING; if ( {win} hasnt g_present)
> rfalse; glk_set_window( {win}.ref_number); -)
Darn, this doesn't work after all. Because the #ifdef is displaced to
another routine, called from the original say routine, it is no longer
part of the original routine. The result doesn't compile, because the
#endif is seen as not having a corresponding #ifdef. Here's compiled I6:
say__p=1;ParaContent(); (PHR_910());ParaContent(); print (PrintText)
SC_63; new_line;ParaContent(); glk_set_window( gg_mainwin ); #endif;
.L_Say24; .L_SayX24;
rfalse;
PHR_910() is the "say debug with console" routine.
Too bad. It looked promising... I think I can streamline my original
workaround so that it's a little easier to use and (especially) maintain,
and I'll do that. Thanks again!
--Erik
vaporware
No, there isn't, but there are a couple workarounds that you might
find less ugly.
One would be to manually assign console-window an I6 name:
<code>
The console-window object translates into I6 as "console_window_obj".
To say debug:
(- #ifdef SP_DEBUGGING; if (console_window_obj hasnt
g_present)
rfalse; glk_set_window(console_window_obj.ref_number); -)
</code>
Another would be to move the code into a larger I6 inclusion where (+
+) is allowed:
<code>
To say debug:
(- #ifdef SP_DEBUGGING; if (~~InitDebugOutput()) rfalse; -)
Include (-
[ InitDebugOutput;
if ( (+ console-window +) hasnt g_present) rfalse;
glk_set_window( (+ console-window +).ref_number);
rtrue;
];
-).
</code>
vw
JDC
> Here, Erik Temple <ek.tem...@gmail.com> wrote:
>
> > Just out of curiosity, is there a technical reason why (+ I7 entity +)
> > doesn't work in inline inclusions?
>
> I don't know. Maybe the I7 source parsing requires too much awareness
> of the context.
I think this actually has to do with the order that I6 code is
generated, since I6 globals must be declared before use. So inline
code may be generated before the I7 entities it references are
defined, whereas new I6 routines you define with "Include (- ... -)"
are included after all of the I7 code is compiled. I've encountered
this issue also when trying to inline an I6 global for debugging
purposes; you generally have to define a routine to return the global
and then call this routine with inline code.
-JDC
Erik Temple
> No, there isn't, but there are a couple workarounds that you might
> find less ugly.
Thanks--both of these are helpful!
> One would be to manually assign console-window an I6 name:
>
> <code>
> The console-window object translates into I6 as "console_window_obj".
>
> To say debug:
> (- #ifdef SP_DEBUGGING; if (console_window_obj hasnt
> g_present)
> rfalse; glk_set_window(console_window_obj.ref_number); -)
> </code>
Ah yes--this is a much more elegant version of the original workaround. (I
actually looked this up this way of doing it in the manual, but I should
have just tried it! The manual indicates that you can do "translates into
I6 as" with constants, variables, properties, actions, and attributes, but
is silent about objects.)
> Another would be to move the code into a larger I6 inclusion where (+
> +) is allowed:
>
> <code>
> To say debug:
> (- #ifdef SP_DEBUGGING; if (~~InitDebugOutput()) rfalse; -)
>
> Include (-
> [ InitDebugOutput;
> if ( (+ console-window +) hasnt g_present) rfalse;
> glk_set_window( (+ console-window +).ref_number);
> rtrue;
> ];
> -).
> </code>
>
> vw
Cool, this is also a good workaround. Thanks!
On Sat, 17 Oct 2009 23:49:18 -0500, JDC <jd...@psu.edu> wrote:
> I think this actually has to do with the order that I6 code is
> generated, since I6 globals must be declared before use. So inline
> code may be generated before the I7 entities it references are
> defined, whereas new I6 routines you define with "Include (- ... -)"
> are included after all of the I7 code is compiled. I've encountered
> this issue also when trying to inline an I6 global for debugging
> purposes; you generally have to define a routine to return the global
> and then call this routine with inline code.
>
> -JDC
This makes sense. I didn't think the absence of this feature could be an
oversight, but I still held out hope...
Thanks,
Erik
Erik Temple
wrote:
> If you use debugging messages to keep track of what code is firing when,
> or the state of things, you may find it annoying to comment it out,
> delete it, or otherwise remove it from your code before releasing it.
> These two say phrases make this unnecessary:
>
> <code>
>
> To say debug:
> (- #ifdef DEBUG; -)
>
> To say end debug:
> (- #endif; -)
>
> </code>
>
> Now, you can write things along these lines:
>
> say "[debug]Begin attack routine.[end debug]".
On the off chance that anyone is playing around with this:
You need to write the "end debug" phrase so that it ends with a "run
paragraph on"; this will prevent the printing of spurious line breaks:
To say end debug:
(- #endif; RunParagraphOn(); -)
--Erik
Jim Aikin
>
> On the off chance that anyone is playing around with this:
>
> You need to write the "end debug" phrase so that it ends with a "run
> paragraph on"; this will prevent the printing of spurious line breaks:
>
>
> To say end debug:
> (- #endif; RunParagraphOn(); -)
I'm planning to include it as a tip in the next version of the Handbook,
so I've been playing with it. But I think the appearance of line breaks
depends on the way the phrases are used. For instance:
say "[debug]This is some additional output. [end debug]This is the
inevitable output.";
There's no problem there, that I can see. Can you give an example in
which using these macros will result in spurious line breaks in the
release version?
--JA
Erik Temple
Ah, you're right. It looks like the problem comes in when you are moving
between different windows using Flexible Windows (which is the context in
which I'm actually using this). Selecting a new output stream seems to be
the proximate cause of the line breaks I was seeing, though only in some
cases. I haven't quite worked out why this--perhaps it's the standard
behavior. Two text-buffer windows (including the main window) plus at
least one graphics window seems to cause a new line to be printed when the
output stream is shifted between the windows--again, usually only one per
turn except during the "window calibration" routine.
In any case, this issue doesn't affect the simpler usage--I just tested it
in multiple configurations (as I'm sure you've also done), with no issues
with line breaks whatsoever. Thanks for taking the time to clarify this!
--Erik