FWD » Core Development » Conversion Tools

I have some questions regarding this one:

1. Which source do we debug: the original 4gl file or the preprocessed cache file?
2. Do we debug only the 4GL, or should the converted Java also be visible? For example, a mixed call stack, or a "show Java" link to the companion view
3. May the conversion be changed to produce a 4GL line to Java line map? Today the generated Java carries no line info. If so, in which form, for example a .dbgmap would be a good fit?
4. Should the map be produced always, or only behind a setting in p2j.cfg.xml?
5. Should the debugger control the code from outside, attaching to the server's JVM like a Java debugger (JDI/JDWP)? That means no runtime changes and no cost when not debugging, but 4GL state has to be read out of FWD's Java objects. Or should it control it from inside, through hooks in the FWD runtime?
6. Attach to a running server only, or should the extension also launch the server and client and run a chosen program?
7. OpenEdge compatibility: should DEBUGGER:SET-BREAK and the other DEBUGGER handle features work?
8. What are your expectations for the very first phase of DAP?

1. Which source do we debug: the original 4gl file or the preprocessed cache file?

The cache file is the most obvious mapping. It makes the most sense to me. As long as we provide mechanisms (keyboard shortcuts and popup menu items) to navigate to the original sources (we need the ability to jump to the corresponding location in the editable file from which the code came).

2. Do we debug only the 4GL, or should the converted Java also be visible? For example, a mixed call stack, or a "show Java" link to the companion view

Optimally, we would be able to switch back and forth between either the 4GL or the Java debug views. The actual debugging should be a common session. The views just show the correct language and provide the UI for interaction.

3. May the conversion be changed to produce a 4GL line to Java line map? Today the generated Java carries no line info. If so, in which form, for example a .dbgmap would be a good fit?

Yes, we will need something like this. It needs to be bidirectional.

4. Should the map be produced always, or only behind a setting in p2j.cfg.xml?

It should always be produced. I think it can go into the same ./cvt/ directory structure with our other intermediate artifacts.

5. Should the debugger control the code from outside, attaching to the server's JVM like a Java debugger (JDI/JDWP)?

Yes.

That means no runtime changes and no cost when not debugging, but 4GL state has to be read out of FWD's Java objects.

Yes

Or should it control it from inside, through hooks in the FWD runtime?

No

6. Attach to a running server only, or should the extension also launch the server and client and run a chosen program?

As noted in Phase 1 IDE Support, we need the ability to launch servers, agents and clients etc.

7. OpenEdge compatibility: should DEBUGGER:SET-BREAK and the other DEBUGGER handle features work?

Evaluate the effort for this and create a task with some details about the idea and approach. I don't think we need this feature in this task, we will defer it.

8. What are your expectations for the very first phase of DAP?

Proper step-level debugging of 4GL source code with full variable support. It is OK if this must connect to an already running server/clients. Jumping back and forth between Java and 4GL is also pretty important.