FWD » Core Development » Conversion Tools

The estimate for this is ~1 to 1.5 weeks of work, assuming #3699 is already worked (i.e. webcola is implemented already in the callgraph, so we know how to use it).

To access the diagram chart, use the icon on the left-side of the i.e. external program block's text.

Hmm, the com/goldencode/p2j/report/web/res/3pl/ folder is excluded by the build process, and I use 3pl/ folder to (temporarily) hold the cola.js sources. I'll change to (temporarily) use the report/web/res/cola folder, until I have the cola.zip archive (uploaded the GCD artifacts folder) and the change to build.xml.

It's easy for me to update the artifacts, so if you want to implement that part now go ahead.

Done.

Greg, please check rev 11284.

In the flow chart, clicking on the specific node should take you to the source code view with that node highlighted.

Greg Shah wrote:

2. Inner blocks/loops (REPEAT,FOR,DO,EDITING) should be be a container that groups the stuff inside.

Yes, I'm considering this, but I haven't implemented yet it because the cola.js's powergraph support (which allows routing the edges so that they do not overlap) doesn't support explicitly specified groups. I'm still trying to use at least the edge routing part (which might allow me to define my own groups), but it doesn't seem to be working yet.

Greg, for the IF, WHILE, FOR, expressions, I need a way to anti-parse the expression (to show it in the chart). At this time I have something simple which works with basic binary expressions and functions calls, but I'd like to have a Java method which gets a generic EXPRESSION node and produces the 4GL counterpart (maybe part of the #3696 task).

As soon as #2110 is done, I will work start work on this task. I will make sure we have a method that can output an arbitrary subtree.

It's a good idea that you had.

• var = expr1 to expr2 [by k]
  

  [v = expr1]
      |
      |    /------------------------------------------------------\
      v    V                                                       |
    /-----------\                                                  |
   | v <= expr2  | -- yes -> [the block's code] --> [ v = v + k ] /
    \-----------/
         |
         no
         v 
      [next statement after the block]
  

• WHILE expr
  

           /-------------------------------------\
           V                                      |
    /-----------\                                 |
   |    expr    | -- yes -> [the block's code] --/
    \-----------/
         |
         no
         v 
      [next statement after the block]
  

  
  This has impact on how NEXT statement behaves, which would i.e. skip to v = v + k instead of the i.e. REPEAT block.

Otherwise, I can leave them as plain text in the SVG element associated with this block.

I think that when the block is expanded, it is better to have it broken out explicitly like you do here. This seems easier to understand and more in line with the idea of the flow chart.

Perhaps we use the "plain text in the SVG element associated with this block" for the "collapsed" state?

I've rebased 3701a from trunk rev 11284. Also, I've committed some other improvements for the flow chart - see rev 11289.

• done I plan to have multiple EXIT nodes (at least one for each block) - these will mark program termination. Otherwise, if there are multiple ways to terminate and only a single EXIT node, the links don't look so good. I think the links to END nodes can be routed cleanly.
• done there are some issues with routing links for WHILE/TO loops - working on this
• I need to fix fill colors and borders for blocks/statements, plus link lengths so that nodes are closer together.
• discarded when multiple links converge to the same target, currently they overlap (closer they get to the target). I'm not sure yet how to route them without overlapping, this is low priority for now.
• discarded for longer flows, I think we could 'fold them', i.e. if the flow reaches a certain width, go to another line, still from left-to-right, but with the outgoing links from the top flow properly routed to the first node in the flow bellow it. Again, this is low priority, I want to have a good version first.
• OO flow test

• done the support for collapse/expand block

Greg Shah wrote:

• There are 2 RUN statements that don't appear in the flow chart.
• I think the WAIT-FOR statements should appear too.

I haven't considered explicitly including these - should all call-sites appear, and if so, should they link somewhere or just as code snippets?

• The APPLY would be better if it had some details of the event and target (of available).

This doesn't appear intentionally in the flow chart, it appears just because the code looks like IF ... THEN APPLY, and not IF ... THEN DO: APPLY - the idea is, if the THEN doesn't have a child block, the single statement will be shown. This will be fixed when I have a routine to anti-parse some generic AST. But again, there is nothing hard-coding APPLY to be included in the flow chart.

• The labels on the arrows are pretty hard to read. I think they may need to be larger.
• It probably makes sense to put TRUE/FALSE labels on the exit points from an IF "diamond".
• The arrowheads probably should be a bit larger (not too much), so they are easier to see.

Thanks, will improve it.

• We may need to bias blocks to be vertical instead of horizontal so that the brain can more easily process the similarity to the top to bottom ordering of the code.

OK, unfortunately until now I worked on the left-to-right flow and I have some assumptions (like IF) which hard-code the border 'pin' of the source and target links; but shouldn't be hard to change (and keep the left-to-right, too).

Greg, I need some input for #3701-22.

should all call-sites appear, and if so, should they link somewhere or just as code snippets

By definition, most call sites invoke targets that are outside of the scope of the current top-level block. Where some specific call/return is occurring, I think we should indicate that in some way.

An APPLY exits the local scope and then returns, possibly having executed some event logic. For this, it probably makes sense to have some exit terminator (possibly labeled with the event name) and then an arrow to and an arrow from to show that the control flow exits and returns.

A RUN statement does the same thing but with a procedure target.

On the other hand, a WAIT-FOR doesn't need to link to anything specific because there is no specific call/return and no specific target. I do think we might want something on the WAIT-FOR block to indicate an internal event processing loop, but otherwise that is it.

Does that make sense? If there is a specific target, provide some linkage and handle any call/return flow. If no specific target, then just show it.

Greg Shah wrote:

Does that make sense? If there is a specific target, provide some linkage and handle any call/return flow. If no specific target, then just show it.

OK, so any statement which can affects the flow should be enhanced, to provide details about the call target.

OK, so any statement which can affects the flow should be enhanced, to provide details about the call target.

Yes, I think so. This is an opportunity for the individual symbols in the flow chart to be augmented so that the viewer gets a powerful amount of information at a glance.

Greg Shah wrote:

Yes, I think so. This is an opportunity for the individual symbols in the flow chart to be augmented so that the viewer gets a powerful amount of information at a glance.

What about this: we output the entire 4GL code for such statements, and add a way to show to the target AST for i.e. external program, internal procedure, etc (if is not missing)?

For the block header (i.e. loop, ON phrases, etc) I've added a way to show them in the lower-left corner, with the AST details - do we need more, at the actual block?

What about this: we output the entire 4GL code for such statements, and add a way to show to the target AST for i.e. external program, internal procedure, etc (if is not missing)?

I'll have to see this to know how well it will work.

Are you trying to avoid statement-specific nodes?

For the block header (i.e. loop, ON phrases, etc) I've added a way to show them in the lower-left corner, with the AST details - do we need more, at the actual block?

This sounds like what I was asking for, though I would probably prefer the text at the top-left. Let me see how this looks and we will go from there.

Greg Shah wrote:

Are you trying to avoid statement-specific nodes?

Yes, I want to avoid adding other nodes, and just rely on augmenting/showing info for the node.
Please see rev 11296 - I think is close to be done.

This sounds like what I was asking for, though I would probably prefer the text at the top-left. Let me see how this looks and we will go from there.

Please see rev 11296.

Greg, please see 3701a rev 11299. You may want to check ./abl/fwd-embedded-driver.p.ast, it contains more complex code.

At this time, the chart is stable - I couldn't find any more mishaps on terms of computing the constraints for the flow levels, and left/right separation for conditional branches. I'm cleaning up the code and see how the callgraph can be improved next.

The result is really impressive! I love the extra controls to expand all blocks and choose horizontal/vertical. It is working quite well. I also like the ability to drill in to RUN targets. Very cool.

By the way, the flow generally seems best in vertical mode. The overall approach will work in its current form. I did find some places where there is some crossing of links, but we can leave it alone for now.

I should start the anti-parser this week. I'll let you know when that is ready.

One thing to mention is that the link text still sometimes is upside-down. It would be good to fix that.

Great work!

Constantin Asofiei wrote:

One thing to mention is that the link text still sometimes is upside-down. It would be good to fix that.

If you are talking about a middle link text (and not a start link text), then I don't think I can fix that.

Yes, I was talking about the middle link text. We won't worry about it for now.

3701a was merged to trunk rev 11285 and archived.