Debugging modular grammar (segmentation fault)

[christina]

Dear all,

I have a grammar that is composed of several parts:

  abstract ReceptionDialog = Reception, Dialog; 

  concrete ReceptionDialogEng of ReceptionDialog = ReceptionEng, DialogEng; 

Compiling and loading these grammars works perfectly fine, as does generating trees, parsing and linearizing for the parts (ReceptionEng and for DialogEng). Generating trees and linearization also works for the composed grammar (ReceptionDialogEng); however, when I try to parse an expression, I get a segmentation fault:

> i ReceptionDialogEng.gf

linking ... OK

ReceptionDialog> gr | l

thank you

ReceptionDialog> parse "thank you"

Segmentation fault (core dumped)

Now I don't have any idea where to look for the cause. Is there something I could test to get a hint about what is wrong with my grammars or where things go wrong? 

Did somebody maybe have a similar problem once?

Best regards, 

Christina

[Krasimir Angelov]

Hi Christina,

If you can send me the grammar in compiled form, then I will try to debug it. The GF runtime is using some unsafe features in Haskell for performacy issues and the segmentation fault comes from there. This should not happen, however, unless if there is something suspecious in the grammar itself.

Regards,

  Krasimir

 

2013/5/7 christina <f06...@gmail.com>

Christina

--
 
---
You received this message because you are subscribed to the Google Groups "Grammatical Framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gf-dev+un...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[christina]

Thanks a lot for the offer! I found the reason now: There were conflicting --# -path=... in the two grammar parts (one specifying present and one specifying alltenses). Beginner's mistake, I guess ;).

Best regards,

Christina 

[Aarne Ranta]

Hello Christina,

No, this is not a beginner's mistake but rather a bad feature (a.k.a. a bug) in GF :-)  

A typical application grammar looks as follows:

  --# -path=.:alltenses

  concrete AppChi of App = open SyntaxChi in ....

or as follows:

  --# -path=.:present

  concrete AppFre of App = open SyntaxFre in ...

If the abstract syntax App is the same in both of them, you ought to be able to compile with

  gf -make AppChi.gf AppFre.gf

However, this may cause a linking error, because there can be a module such as TenseX, which has different versions in present/ and alltenses/, but only one of these is accessed by the linker. The remedy is to build the two pgf's separately and combine them afterwards:

  gf -make -name=AppChi AppChi.gf

  gf -make -name=AppFre AppFre.gf

  gf -make AppChi.pgf AppFre.pgf

The problematic feature of GF is that modules are identified by their plain module names, with no reference to directories. Thus the library modules present/TenseX and alltenses/TenseX are really two different modules, but they cannot be distinguished since they have the same base name.

What adds to the risk of confusion is that we have the present/ and alltenses/ versions of the RGL. This is for practical reasons, which we have wanted to eliminate, but haven't succeeded yet. Thus Fre is often too heavy to be used in its alltenses/ version, in the intermediate stages of compilation. On the other hand, Chi is no problem, and it does not even have a present/ version, because the omitted functions are not marked in its RGL source. 

We have two long-term goals related to these problems:

1. Eliminate the need of present/ libraries. This was prepared in the latest version of GF, where alltenses is automatically included as the last item of a path, and thus need not even be indicated by the user. But it is overridden if present is explicitly included in the path.

2. Introduce hierarchical module names. This would be a reform similar to what Haskell did a few years ago. But this will be a big task, with some open design questions, and has never had the highest priority so far.

With best regards

  Aarne.

Best regards,

Christina