tfield_type_datetime$DATE      ::= DATE
tfield_type_datetime$TIME      ::= TIME
tfield_type_datetime$TIMESTAMP ::= TIMESTAMP

The text for $DATE, etc., is bright blue, which is a bit strong.

Brian Payton
SQL Tools Development
IBM Silicon Valley Laboratory

Brian Payton wrote:

Here's a minor fit'n'finish item I came across in the LPG source editor.

Thanks for the report!

In the editor, the "Toggle comment" action (Ctrl+/) adds LPG comments in a way that is kind of ugly. Let's say you have a rule like this:

col_expr_cl ::=
       col_expr_spec
     | col_expr_cl , col_expr_spec

The toggle comment action does this:

-- col_expr_cl ::=
      -- col_expr_spec
    -- | col_expr_cl , col_expr_spec

The equivalent action in the Java editor works a little differently. If you toggle comments on this:

    if (uniqueOpt != null) {
        index.setUnique(true);
    }

you get this:

//    if (uniqueOpt != null) {
//        index.setUnique(true);
//    }

which I think makes it easier to spot sections of code that are commented out.

You're right; the present heuristic - to place the line comment prefix
just before the first non-whitespace character only works well if all
the lines in question have the same indentation, e.g.:

   int x, y;
   x = 15;
   y++;

becomes:

//   int x, y;
//   x = 15;
//   y++;

But as you saw, the heuristic fails when the lines don't all have the
same indentation.

By the way, this isn't a problem just for LPG; this is what the IMP
runtime support for toggling comments does.

We can do either of two things:

 1) Just insert the line comment start at the very beginning of the
    line (as shown above).

 2) Find the common whitespace prefix of all the lines in question
    and insert just after that. That would produce instead:

   // int x, y;
   // x = 15;
   // y++;

Comments? (No pun intended)

Here's a minor fit'n'finish item I came across in the LPG source editor.

Thanks for the report!

In the editor, the "Toggle comment" action (Ctrl+/) adds LPG comments in a way that is kind of ugly. Let's say you have a rule like this:

col_expr_cl ::=
       col_expr_spec
     | col_expr_cl , col_expr_spec

The toggle comment action does this:

-- col_expr_cl ::=
      -- col_expr_spec
    -- | col_expr_cl , col_expr_spec

The equivalent action in the Java editor works a little differently. If you toggle comments on this:

    if (uniqueOpt != null) {
        index.setUnique(true);
    }

you get this:

//    if (uniqueOpt != null) {
//        index.setUnique(true);
//    }

which I think makes it easier to spot sections of code that are commented out.

You're right; the present heuristic - to place the line comment prefix
just before the first non-whitespace character only works well if all
the lines in question have the same indentation, e.g.:

   int x, y;
   x = 15;
   y++;

becomes:

//   int x, y;
//   x = 15;
//   y++;

But as you saw, the heuristic fails when the lines don't all have the
same indentation.

By the way, this isn't a problem just for LPG; this is what the IMP
runtime support for toggling comments does.

We can do either of two things:

 1) Just insert the line comment start at the very beginning of the
    line (as shown above).

 2) Find the common whitespace prefix of all the lines in question
    and insert just after that. That would produce instead:

   // int x, y;
   // x = 15;
   // y++;

Comments? (No pun intended)

--
Cheers,
  -- Bob

--------------------------------
Robert M. Fuhrer
Research Staff Member
Programming Technologies Dept.
IBM T.J. Watson Research Center

IDE Meta-tooling Platform Project Lead (http://www.eclipse.org/imp)
X10: Productive High-Performance Parallel Programming (http://x10.sf.net)

col_expr_cl ::=
       col_expr_spec
     | col_expr_cl , col_expr_spec

The toggle comment action does this:

-- col_expr_cl ::=
      -- col_expr_spec
    -- | col_expr_cl , col_expr_spec

    if (uniqueOpt != null) {
        index.setUnique(true);
    }

you get this:

//    if (uniqueOpt != null) {
//        index.setUnique(true);
//    }

I don't believe anyone has ever built a binary for 64-bit Windows;
hence the missing fragment. I don't have access to a 64-bit Windows
machine at the moment, so if anyone out there wants to volunteer to
produce (and smoke-test) such a binary, I'd be happy to create a
fragment for it and distribute it along with the rest of LPG.

Building LPG is a trivial matter for most platforms. We have built
32-bit Windows binaries in the past. There's a DOS shell script in
the project lpg.generator.cpp called make-Win32-x86-MSNET.bat which
should suffice, assuming you've set up your environment to define
the necessary environment variables (vcvars32.bat used to be
distributed with Visual Studio to do this; I don't know whether it
still exists in the current .Net Studio distribution).

Hi,

i install imp project on eclipse 3.5_X64 under vista64.

All bundles are installed correctly except lpg.generator .

no fragment containing the parser is installed. Thus, the generation of grammar is no longer.

--
Cheers,
  -- Bob

--------------------------------
Robert M. Fuhrer
Research Staff Member
Programming Technologies Dept.
IBM T.J. Watson Research Center

IDE Meta-tooling Platform Project Lead (http://www.eclipse.org/imp)
X10: Productive High-Performance Parallel Programming (http://x10.sf.net)

Hi there,

Thanks for the bug reports!

The LPG parser generator and the LPG IDE use different parsers (even slightly
different grammars), partly since the parser generator hand-rolls its scanner,
while the IDE uses LPG itself to generate the scanner. This difference shows
up particularly for the %options directives. In theory, they should be in
perfect agreement, but obviously they're not quite.

More details below...

Brian Payton wrote:

Hi,

I'm starting to use the IMP LPG source editor, and I noticed the editor shows syntax errors on certain input that LPG accepts, particularly in the %options declarations. Here's the lines showing errors, plus the error messages.

Line:
%options action=("DB2ZQueryParser.java", "/.", "./")
Error:
Multiple messages: misplaced construct(s): "ERROR_TOKEN" {0} is invalid: "%options action" {0}
expected after this token: "DISJOINTPREDECESSORSETS_KEY"

I'm looking into this.

Line:
%options ParseTable=%options ParseTable=lpg.lpgjavaruntime.ParseTable
(Note: this options line doesn't make much sense to me, so it might be an error in the source file. However LPG doesn't complain about it.)
Error:
Multiple messages: {0} unexpected token(s) ignored: "ERROR_TOKEN" {0} is invalid: "%options ParseTable=%options "

Such a line is really two ParseTable options specifications, the first
with a bogus empty value that gets overridden by the second, which has
the value "lpg.lpgjavaruntime.ParseTable". You can safely delete the
initial "%options ParseTable=" prefix.

I don't think it really makes much sense to change the IDE parser to
accept this (erroneous) options specification. If anything, I'd argue
that we should change the parser generator to flag it as an error.

Line:
  %options var=nt,automatic_ast,visitor,parent_save
Error:
  {0} is invalid: "%options var"

You're right - we missed the "var" option. I'll fix that.

Line:
  %options or_marker='|'
Error:
  {0} is invalid: "%options or_marker='"

In this case, the grammar used by the IDE doesn't seem to permit a
quoted character. As a workaround, removing the quotes should work.
Of course, I'll fix the IDE's grammar to allow the quoting.

I also noticed that the editor doesn't hilight as keywords the "no" prefix on keywords such as "noserialize", "nogoto_default", and "noerror-maps"

I'll have to look into this as well.

i install imp project on eclipse 3.5_X64 under vista64.

All bundles are installed correctly except lpg.generator .

Philippe

Hi,

I'm starting to use the IMP LPG source editor, and I noticed the editor shows syntax errors on certain input that LPG accepts, particularly in the %options declarations. Here's the lines showing errors, plus the error messages.

Line:
%options action=("DB2ZQueryParser.java", "/.", "./")
Error:
Multiple messages: misplaced construct(s): "ERROR_TOKEN" {0} is invalid: "%options action" {0}
expected after this token: "DISJOINTPREDECESSORSETS_KEY"

Ah, the problem in this case is the use of the shorthand "action" in
lieu of "action-block". The IDE should properly handle "action-block".
I'll check with Philippe to make sure that they really mean the same
thing, and if so, I'll augment the IDE's grammar to suit.

--
Cheers,
  -- Bob

--------------------------------
Robert M. Fuhrer
Research Staff Member
Programming Technologies Dept.
IBM T.J. Watson Research Center

IDE Meta-tooling Platform Project Lead (http://www.eclipse.org/imp)
X10: Productive High-Performance Parallel Programming (http://x10.sf.net)

Thanks for the bug reports!

The LPG parser generator and the LPG IDE use different parsers (even slightly
different grammars), partly since the parser generator hand-rolls its scanner,
while the IDE uses LPG itself to generate the scanner. This difference shows
up particularly for the %options directives. In theory, they should be in
perfect agreement, but obviously they're not quite.

More details below...

Hi,

I'm starting to use the IMP LPG source editor, and I noticed the editor shows syntax errors on certain input that LPG accepts, particularly in the %options declarations. Here's the lines showing errors, plus the error messages.

Line:
%options action=("DB2ZQueryParser.java", "/.", "./")
Error:
Multiple messages: misplaced construct(s): "ERROR_TOKEN" {0} is invalid: "%options action" {0}
expected after this token: "DISJOINTPREDECESSORSETS_KEY"

I'm looking into this.

Line:
%options ParseTable=%options ParseTable=lpg.lpgjavaruntime.ParseTable
(Note: this options line doesn't make much sense to me, so it might be an error in the source file. However LPG doesn't complain about it.)
Error:
Multiple messages: {0} unexpected token(s) ignored: "ERROR_TOKEN" {0} is invalid: "%options ParseTable=%options "

Such a line is really two ParseTable options specifications, the first
with a bogus empty value that gets overridden by the second, which has
the value "lpg.lpgjavaruntime.ParseTable". You can safely delete the
initial "%options ParseTable=" prefix.

I don't think it really makes much sense to change the IDE parser to
accept this (erroneous) options specification. If anything, I'd argue
that we should change the parser generator to flag it as an error.

Line:
  %options var=nt,automatic_ast,visitor,parent_save
Error:
  {0} is invalid: "%options var"

You're right - we missed the "var" option. I'll fix that.

Line:
  %options or_marker='|'
Error:
  {0} is invalid: "%options or_marker='"

In this case, the grammar used by the IDE doesn't seem to permit a
quoted character. As a workaround, removing the quotes should work.
Of course, I'll fix the IDE's grammar to allow the quoting.

I also noticed that the editor doesn't hilight as keywords the "no" prefix on keywords such as "noserialize", "nogoto_default", and "noerror-maps"

I'll have to look into this as well.

--
Cheers,
  -- Bob

--------------------------------
Robert M. Fuhrer
Research Staff Member
Programming Technologies Dept.
IBM T.J. Watson Research Center

IDE Meta-tooling Platform Project Lead (http://www.eclipse.org/imp)
X10: Productive High-Performance Parallel Programming (http://x10.sf.net)