Euphoria
Ticket #506:
Move Trace into front end, obsolete be_rterror.c and be_syncolor.c
-
Reported by
jimcbrown
Dec 06, 2010
Right now we have 4 different parsers, be_syncolor.c and euphoria/syncolor.e and euphoria/tokenize.e
be_syncolor.c is only used by be_rterror.c to implement the trace screen. If we move the trace screen into the front end (as we can already call front end code from the backend, coverage.ex implements this) then we can use euphoria/syncolor.e instead of having to manually keep the two syncolors in sync with each other.
Details
1. Comment by jimcbrown
Dec 08, 2010
The coverage branch now has be_syncolor.c reimplemented as a wrapper to the frontend (the same way that the cover_* routines are wrapped from the backend to the frontend, with a special callback). This unified syncolor.e and be_syncolor.c, and since syncolor.e was already rewritten to use tokenize.e, this completes the unification of the three parsers.
The Trace screen itself is still done in the backend, but since the bug report was about unifying the 3 parsers, I'm considering this finished.
2. Comment by jeremy
Dec 08, 2010
I'd say we leave this open until it's fixed in trunk. Marking it fixed now may result it this code being forgotten about or not merged into trunk.
3. Comment by mattlewis
Dec 28, 2010
My trace(1) screen is not usable at all.
- The top instruction line is overwritten.
- Line numbers aren't on the same line as their line.
- The variable information section gets partly overwritten
- Cannot tell which line is being executed
- There are line breaks in the middle of lines
Example lines from the console:
240:
if
unsigned_int
then
241:
return peek
( ptr )
version info:
Euphoria Interpreter v4.0.0 development
Linux, Using System Memory
Revision Date: 2010-12-27 13:27:19, Id: 4437:99b3ad82d728
4. Comment by jimcbrown
Dec 28, 2010
Conformed. I can reproduce the issue here too.
5. Comment by jimcbrown
Dec 28, 2010
I know what the cause is, but am less certain of a proper solution.
The old be_syncolor.c called directly into the routines of be_w.c
However, syncolor.e relies on puts() and M_SET_TEXT_COLOR, which are wrapped in EPuts() and machine() respectively. The wrappers force output to go to the MainScreen() instead of the trace screen image that's maintained internally.
The current be_rterror.c (or maybe it's be_w.c) has a bug such that when switching to the main screen, the background is not properly flushed out and the trace screen elements are still shown. This was present in eui before the switch from be_syncolor.c to syncolor.e - and that's the reason that we haven't noticed the MainScreen issue before now.
If I add custom machine procs to enable changing colors and writing to the screen without going through MainScreen, then this works. But this presents a bigger problem, as removing the entire Trace() code from be_rterror.c into the frontend will require the frontend to manage this bit.
6. Comment by jimcbrown
Dec 28, 2010
See: hg:euphoria/rev/7d2d3357f4a3
changeset: 4438:7d2d3357f4a3 tag: tip user: Jim C Brown date: Tue Dec 28 13:33:55 2010 -0500 files: include/euphoria/syncolor.e source/be_machine.c source/syncolor.e description:
- Add fix to ticket:506 to clean up the trace screen. More discussion may be necessary.
- Add option to handle new lines in euphoria/syncolor.e
7. Comment by mattlewis
Apr 24, 2011
The easiest way to call front end code is to supply a callback when initializing (this is how we've subsequently handled the coverage and syntax coloring). Ultimately, we could have a defined API, once we move the tracing code into the front end, and a way to override the debugger, which would make an easy way to have users build their own debuggers (see, e.g., ticket:623).
8. Comment by jimcbrown
Jan 10, 2013
See: hg:euphoria/rev/0d252d2427ce
changeset: 5908:0d252d2427ce tag: tip parent: 5905:10f7a86e5fd1 user: Jim C Brown date: Thu Jan 10 12:34:17 2013 -0500 files: source/be_machine.c description:
- Fixes ticket:673
- Fixes ticket:506
- Make sure we reset the color back to normal color after we've displayed the colorized text.
9. Comment by jimcbrown
Jan 10, 2013
The problem isn't calling front-end code from the backend, but rather that the front-end would need to delve into the backend internals and call individual functions in the backend directly.
10. Comment by mattlewis
Mar 01, 2013
There's really nothing stopping us from moving the debugger completely to the front end. Take a look at euphoria/debug/debug.e. Well, it may need some additional things to cover all functionality (been a while since I did much with it).
It's not a simple task, since we'd have to re-implement all of the screen switching stuff and the display stuff.
11. Comment by jimcbrown
Mar 01, 2013
Wow. I had no idea that existed. It does solve all the hard stuff (like accessing the routine table or symtab).
12. Comment by mattlewis
Mar 01, 2013
Also, see demo/simple_debug.e for a simple debugger. Just include it in your program.
GitHub