Project

General

Profile

Feature #1627

support for empty EXPORT statements

Added by Greg Shah over 11 years ago. Updated over 7 years ago.

Status:
Closed
Priority:
Normal
Start date:
Due date:
% Done:

100%

Estimated time:
8.00 h
billable:
No
vendor_id:
GCD

export_tests.20130218a.zip - Testcases to check the empty export statements (1.3 KB) Eugenie Lyzenko, 02/18/2013 02:55 PM

evl_upd20130224a.zip - Drop for rules to eliminate empty export (5.29 KB) Eugenie Lyzenko, 02/24/2013 01:43 PM

ExportTestConverted20130224.zip - Converted samples with eliminated exports (1.9 KB) Eugenie Lyzenko, 02/24/2013 01:43 PM

History

#1 Updated by Greg Shah over 11 years ago

  • Target version set to Milestone 7

#2 Updated by Greg Shah about 11 years ago

  • Estimated time changed from 4.00 to 8.00
  • Assignee set to Eugenie Lyzenko
  • Target version changed from Milestone 7 to Milestone 4

It is possible to have an "empty" EXPORT statement in the 4GL, as in:

EXPORT.

Normally, it would look like this (a list of expressions OR a database table follows the keyword):

EXPORT var1 (some-var2 + 54) var3.
EXPORT database-table.

There are other options too, but these are the most common forms.

I have not tested it, but I suspect that this is also possible:

EXPORT STREAM my-stream.
EXPORT DELIMITER "|".
EXPORT NO-LOBS.

If all of the above "empty" export statements are accepted, then this also may be accepted:

EXPORT STREAM my-stream DELIMITER "|" NO-LOBS.

What you should do:

1. Create testcases to determine which of the empty export statements are possible.

2. Test to see if the usage of any of these statements ever changes the output file. If not, then these would be considered a NOP.

3. Based on the findings above, we would want to detect the empty export statement cases and if they are NOPs we would want to hide them in the tree. This is probably best done during post_parse_fixups.

#3 Updated by Eugenie Lyzenko about 11 years ago

The statements
EXPORT var1 (some-var2 + 54) var3.
EXPORT database-table.
both have run-time error in 4GL:
...
EXPORT cannot be used with output to the screen. (1105)
...

The statements has the following results:
EXPORT STREAM my-stream. - export_test1.p - generates 0 output file, no errors
EXPORT DELIMITER "|". - export_test2.p - generates 0 output file, no errors
EXPORT NO-LOBS. - export_test3.p - generates 0 output file, no errors
EXPORT STREAM my-stream DELIMITER "|" NO-LOBS. - export_test4.p - generates 0 output file, no errors

The testcases uses has been uploaded here.

#4 Updated by Greg Shah about 11 years ago

EXPORT cannot be used with output to the screen. (1105)

When a stream is not explicitly used (e.g. EXPORT STREAM my-stream...) then you must first redirect the terminal like this:

OUTPUT TO my_file.txt.

EXPORT var1.

OUTPUT CLOSE.

Then there will not be any errors.

generates 0 output file

Do you mean they generate a 0 byte sized output file or that no output file is ever created?

#5 Updated by Eugenie Lyzenko about 11 years ago

When a stream is not explicitly used (e.g. EXPORT STREAM my-stream...) then you must first redirect the terminal like this:

OUTPUT TO my_file.txt.

EXPORT var1.

OUTPUT CLOSE.

Then there will not be any errors.

This redirects output to the file and produces non-empty file with real values of the variable like printing to the file. This is not NOP code.

Do you mean they generate a 0 byte sized output file or that no output file is ever created?

New file generation with 0 bites in size. Or overwrites the file with the same name with new one with 0 butes inside. This means the code like this can erase the previously written data(if stream is opening not in append mode) and can be dangerous in some cases if some important data will be overwritten.

#6 Updated by Greg Shah about 11 years ago

This redirects output to the file and produces non-empty file with real values of the variable like printing to the file. This is not NOP code.

Yes, exactly. That is a NON-empty export statement. It is the common case.

New file generation with 0 bites in size. Or overwrites the file with the same name with new one with 0 butes inside. This means the code like this can erase the previously written data(if stream is opening not in append mode) and can be dangerous in some cases if some important data will be overwritten.

Let me make sure I understand. In export_test[1-3].p, if you remove the empty EXPORT statement from those files, do you still get the 0 byte output file?

#7 Updated by Eugenie Lyzenko about 11 years ago

Let me make sure I understand. In export_test[1-3].p, if you remove the empty EXPORT statement from those files, do you still get the 0 byte output file?

Yes, all these 4 cases (1-4) and appropriate 4GL statements gives the same result with and without export statement line - 0 byte output file. So the export does nothing itself in these cases.

#8 Updated by Greg Shah about 11 years ago

Good. Then the solution is to do the following:

1. In post_parse_fixups.rules, you should add a new rule-set like this:

<rule-set name="fixups/hide_empty_exports" />

Add it near the end of the file (just after the "fixups/unspecified_undo").

2. In hide_empty_exports.rules, you must write rules to detect when we have an empty export statement. When you find one, you will hide it at the STATEMENT node. You can probably so something like this:


   <!-- detect an empty export statement (there are no expressions and there is no
        DB record reference -->
   <rule>
      relativePath("STATEMENT/KW_EXPORT") and
      !descendant(prog.export_field, 1)   and
      !descendant(prog.table, 1)          and
      !descendant(prog.buffer, 1)         and
      !descendant(prog.temp_table, 1)     and
      !descendant(prog.work_table, 1)

      <!-- hide the statement -->
      <action>copy.parent.setHidden(true)</action>
   </rule>

#9 Updated by Eugenie Lyzenko about 11 years ago

The modified post_parse_fixups.xml and new rule have been uploaded to eliminate empty export. Also the converted code to see the effect for samples has been uploaded.

#10 Updated by Greg Shah about 11 years ago

The code looks good. I will run conversion testing now.

#11 Updated by Greg Shah about 11 years ago

This has passed conversion testing. Go ahead and check it in and distribute it.

#12 Updated by Eugenie Lyzenko about 11 years ago

The evl_upd20130224a.zip has been committed in bzr as 10197.

#13 Updated by Greg Shah about 11 years ago

  • Status changed from New to Closed

#14 Updated by Eric Faulhaber about 11 years ago

  • % Done changed from 0 to 100

#15 Updated by Greg Shah over 7 years ago

  • Target version changed from Milestone 4 to Conversion Support for Server Features

Also available in: Atom PDF