The call-onsave often fails when building a project for the first time (after starting up Eclipse).
It also fails after generating a new entity language project, such that you need to build the project twice.
It seems to be some problem with the analysis.

call-onsave:
	[java] Calling on-save handler for: /home/oskar/repos/entity/entity/syntax/BuiltInCalls.sdf3
	[java] rewriting failed, trace:
	[java] 	editor_analyze_0_0
	[java] 	editor_analyze_0_0
	[java] 	analysis_default_editor_0_0
	[java] 	analysis_single_default_interface_0_0
	[java] 	analysis_single_default_3_1
	[java] 	analysis_single_default_4_1
	[java] 	analysis_files_spoofax_4_2
	[java] 	analysis_files_spoofax_5_2
	[java] 	analysis_spoofax_output_1_0
	[java] 	map_1_0
	[java] 	analysis_spoofax_update_file_1_0
	[java] Calling on-save handler for: /home/oskar/repos/entity/entity/syntax/Common.sdf3
	[java] Calling on-save handler for: /home/oskar/repos/entity/entity/syntax/Expressions.sdf3
	[java] Calling on-save handler for: /home/oskar/repos/entity/entity/syntax/GMQL.sdf3
	[java] Calling on-save handler for: /home/oskar/repos/entity/entity/syntax/Keywords.sdf3
	[java] Calling on-save handler for: /home/oskar/repos/entity/entity/syntax/Lexical.sdf3
	[java] Calling on-save handler for: /home/oskar/repos/entity/entity/syntax/SelectClause.sdf3
	[java] Calling on-save handler for: /home/oskar/repos/entity/entity/trans/names.nab
	[java] Calling on-save handler for: /home/oskar/repos/entity/entity/trans/types.ts
Submitted by Oskar van Rest on 8 August 2014 at 00:33

On 8 August 2014 at 00:33 Oskar van Rest tagged error

On 8 August 2014 at 00:37 Oskar van Rest commented:

It’s not always the first SDF3 file that fails:

call-onsave:
	[java] Calling on-save handler for: /home/oskar/workspaceM/asdf/syntax/Asdf.sdf3
	[java] Calling on-save handler for: /home/oskar/workspaceM/asdf/syntax/Common.sdf3
	[java] rewriting failed, trace:
	[java] 	editor_analyze_0_0
	[java] 	editor_analyze_0_0
	[java] 	analysis_default_editor_0_0
	[java] 	analysis_single_default_interface_0_0
	[java] 	analysis_single_default_3_1
	[java] 	analysis_single_default_4_1
	[java] 	analysis_files_spoofax_4_2
	[java] 	analysis_files_spoofax_5_2
	[java] 	analysis_spoofax_output_1_0
	[java] 	map_1_0
	[java] 	analysis_spoofax_update_file_1_0
	[java] Calling on-save handler for: /home/oskar/workspaceM/asdf/trans/names.nab

On 8 August 2014 at 07:42 Gabriël Konat tagged @gohla

On 8 August 2014 at 22:14 Gabriël Konat commented:

Can’t seem to reproduce this on OSX with same Spoofax and same Eclipse version as Oskar. He runs Linux so it may be a Linux issue. We’re trying on Windows as well.


On 8 August 2014 at 23:23 Gabriël Konat commented:

I’ve tried to reproduce with a Windows and Ubuntu VM, on both Eclipse Kepler and Luna, but could not do it. This only seems to happen on Oskar’s machines :S


On 13 August 2014 at 10:12 Eduardo Amorim commented:

Does the on-save handler work after the first build? Isn’t it because the analysed asts are not ready (failing to generate the signatures)?


On 13 August 2014 at 19:46 Gabriël Konat commented:

On the first build when calling the on-save handler, it will set up the index, which triggers analysis for all SDF3 files because an index does not exist yet. Full analysis is then triggered on a background thread, blocking all other Stratego analysis jobs (such as the on-save handler). However, it might be possible that the full analysis in the background thread gets priority later than the first on-save call, which will then fail. Sounds like it might be a race condition, which somehow does not happen on my laptop.


On 25 November 2014 at 22:25 Oskar van Rest commented:

With the latest nightly, I don’t have this problem anymore. Tried it with both my Linux and Windows machine.

Closing the issue.


On 25 November 2014 at 22:25 Oskar van Rest closed this issue.

On 3 December 2014 at 19:53 Oskar van Rest commented:

Somehow got the error again after generating a new language:

call-onsave:
    [java] Calling on-save handler for: /home/oskar/workspace/Abc/syntax/Abc.sdf3
    [java] generating for Abc.sdf3
    [java] Signature files could not be generated. Try Reset and Reanalyze or check for unresolved references.
    [java] rewriting failed, trace:
    [java] 	editor_save_0_0
    [java] 	generate_all_0_0
    [java] Calling on-save handler for: /home/oskar/workspace/Abc/syntax/Common.sdf3
    [java] Calling on-save handler for: /home/oskar/workspace/Abc/trans/names.nab

On 3 December 2014 at 19:53 Oskar van Rest reopened this issue.

On 3 December 2014 at 23:52 Eduardo Amorim commented:

Does it work after the first build?


On 19 December 2014 at 22:24 Volker commented:

I get the same problem on my Macbook Air:
OSX 10.10.1
Eclipse Luna 4.4.1
Spoofax 1.3.1

I’m trying to set up a live coding demo for Spoofax, so I create a new minimal project and 2 example files:

exampleSchema.sql:

CREATE TABLE EMP (
  empno NUMBER(5),
  ename VARCHAR(255)
);

example.sql:

SELECT e.ename
FROM EMP e
WHERE e.empno = e.ename
;

Then I define a simple grammar for the example schema:

Start.SQL = <{Query "\n\n"}+>
Query.TableDef = <
  CREATE TABLE <ID> (
    <{ColDef ",\n"}+>
  );
>
ColDef.ColDef = <<ID> <DataType>>
DataType.Num = <NUMBER(<INT>)>
DataType.Str = <VARCHAR(<INT>)>

When I build, exampleSchema.sql has syntax highlighting.

So then I move on to the Select query:

Query.Select = <
  SELECT <{ColRef ", "}+>
  FROM <{Fro ", "}+>
  <WhereClause?>
>
ColRef.ColRef = <<ID>.<ID>>
Fro.Fro = <<ID> <ID>>
WhereClause.Where = <WHERE <Predicate>>
Predicate.Equals = <<Operand> = <Operand>>
Operand.Col = <<ColRef>>

But then, when I save, the sdf file does not get regenerated.
And when I build I get the same message that Oskar got:
Signature files could not be generated. Try Reset and Reanalyze or check for unresolved references.


On 19 December 2014 at 22:43 Oskar van Rest commented:

@Eduardo, to answer your earlier question: it also happens after the first build, at least in the case it also failed during the first build. I’m not sure if it also happens if the first build was successful.

Also, it happens for SDF3 files that are opened in the editor, even though they must have been analyzed.


On 21 December 2014 at 15:44 Gabriël Konat commented:

I still think this is a race condition, which means it will be triggered pretty randomly. One way we could solve this in the current architecture, is to trigger analysis for all SDF3 files, and then call the on-save handlers, but this would mean all files are parsed and collected twice.


On 26 January 2015 at 17:51 Eduardo Amorim commented:

@Volker : I checked your example, and except for a typo in:

Start.SQL = <{Query "\n\n"}+>

that is missing surrounding <>, therefore producing a syntax error in the grammar, the SDF2->SDF3 transformation of these two grammars works fine in Spoofax 1.3.1.
If it happens all the time, there might be an error in the transformation rules, if not, it might be because of the analysis issue that Gabriël described before.


On 26 January 2015 at 18:57 Volker commented:

It seems to be an analysis bug.
When there is a template referring to the same sort twice, renaming this sort will trigger the bug.

This is 100% reproducible on my system, but just in case it is one of those “it works on my machine”-bugs, I created a screen capture of the problem:
http://youtu.be/JKfWDLGgmIs


On 26 January 2015 at 19:18 Eduardo Amorim commented:

Yes, I don’t think it is an SDF bug indeed. If you do reset and reanalyze after it fails, does it work?
@Gabriël: Do you still think it is the race condition you described before?


On 26 January 2015 at 19:28 Volker commented:

The problem is that there is no Analysis menu and so no “reset and reanalyze” available in the SDF3 file. So I wouldn’t know how to test that.
Changing and saving the SDF3 file does not fix the issue.


On 26 January 2015 at 19:31 Guido Wachsmuth commented:

There is a new context menu on projects called Spoofax, which allows you to reload the analysis data.


On 26 January 2015 at 19:55 Volker commented:

Reloading analysis data and saving the file makes it work.
However, if I rename the sort again, the problem arises again.
I guess that verifies that it is Analysis related.


On 26 January 2015 at 21:17 Daco Harkes commented:

Well having to “reset and reanalyze” manually is a real issue. It prevented the people in Oxford of building languages that contain SDF3.
The behaviour we had there was basically every first git checkout the build would fail because SDF3 files had analysis errors. After the first build it didn’t occur anymore.
Especially because the clean checkout didn’t work but the second build working fine was confusing.

@Eduardo, Guido: Is the analysis on SDF3 failing (in some instances, with correct code, and having to reset and reanalyze) an SDF3 bug or a NaBL/TS bug?

Log in to post comments