you could find implementation of the GF interpreter in JavaScript that is compatible with GF 3.1. For a long time the JavaScript implementation was using representation of the grammar that is different from the one used in the Haskell implementation. Now they are in synchronized again.
The package is bundled with the Foods grammar compiled to JavaScript. If you want to use another grammar then you have to compile the grammar with option -output-format=js and then you need to modify the page editor.html to point to the new grammar.
Since now the JavaScript implementation uses the same parsing algorithm as the GF shell it is possible to parse even with the resource grammar. For most languages the speed is reasonable. For Finnish the browser will probably give you a warning that the page is too slow and you have to click on "Continue" once or twice.
This seems to work very well! I tested it with a set of four Attempto grammars, and got a smoothly working editor. The exact steps to do are the following:
- make a copy of runtime system (from Krasimir's link) - compile js by 'gf -make -output-format=js grammar1 grammar2 ...' - replace grammar.js in the runtime system by the resulting file - in editor.html, line 13, replace the abstract syntax name Food by TestAttempto
Then just open editor.html in a web browser!
A couple of questions:
- I expected to find the runtime system in the directory GF/src/ runtime/javascript/, but this is not exactly the same as the files behind the link now - it would be nice to have incremental parsing of course. Would it be an easy solution to call an external parser server from the editor?
Regards
Aarne. On Jan 4, 3:16 pm, Krasimir Angelov <kr.ange...@gmail.com> wrote:
> you could find implementation of the GF interpreter in JavaScript that > is compatible with GF 3.1. For a long time the JavaScript > implementation was using representation of the grammar that is > different from the one used in the Haskell implementation. Now they > are in synchronized again.
> The package is bundled with the Foods grammar compiled to JavaScript. > If you want to use another grammar then you have to compile the > grammar with option -output-format=js and then you need to modify the > page editor.html to point to the new grammar.
> Since now the JavaScript implementation uses the same parsing > algorithm as the GF shell it is possible to parse even with the > resource grammar. For most languages the speed is reasonable. For > Finnish the browser will probably give you a warning that the page is > too slow and you have to click on "Continue" once or twice.
On Tue, Jan 5, 2010 at 4:08 PM, Aarne <aarne.ra...@gmail.com> wrote: > A couple of questions:
> - I expected to find the runtime system in the directory GF/src/ > runtime/javascript/, but this is not exactly the same as the files > behind the link now
What is different? I pushed all local changes to darcs.
> - it would be nice to have incremental parsing of course. Would it be > an easy solution to call an external parser server from the editor?
It is trivial to add completion in the JavaScript runtime. What requires more work is to update the user interface. For example the dialog that currently pops up when the user selects "Parse a string" cannot be altered from the JavaScript code. We need to replace it with something else. It would be nice if the user could alter the text in the right-up panel directly rather than in a popup dialog.
About an external server I think that it makes sense to use the JavaScript parser for the syntax but keep the lexicon on the server if it is too long.
The editor still doesn't work in the Android's Web Browser and it is hard to debug there. There also some problems with the rendering on old versions of IE.
Yes it works well! Thanks. but there is a minor issue: The file EditorGrammar.js is named "editorGrammar.js" in editor.html which may create some inconvenience.
Secondly, the function sym2js of src/GF/Compile/GFCCtoJS.hs, is underspecified. e.g. for my grammar, I encounter the following error while compiling to js:
Writing Unif.pgf... Writing Unif.js...gf: src/GF/Compile/GFCCtoJS.hs:(130,0)-(132,48): Non-exhaustive patterns in function sym2js
On Tue, Jan 5, 2010 at 4:08 PM, Aarne <aarne.ra...@gmail.com> wrote: > This seems to work very well! I tested it with a set of four Attempto > grammars, and got a smoothly working editor. The exact steps to do are > the following:
> - make a copy of runtime system (from Krasimir's link) > - compile js by 'gf -make -output-format=js grammar1 grammar2 ...' > - replace grammar.js in the runtime system by the resulting file > - in editor.html, line 13, replace the abstract syntax name Food by > TestAttempto
> Then just open editor.html in a web browser!
> A couple of questions:
> - I expected to find the runtime system in the directory GF/src/ > runtime/javascript/, but this is not exactly the same as the files > behind the link now > - it would be nice to have incremental parsing of course. Would it be > an easy solution to call an external parser server from the editor?
> Regards
> Aarne. > On Jan 4, 3:16 pm, Krasimir Angelov <kr.ange...@gmail.com> wrote: >> Hi,
>> you could find implementation of the GF interpreter in JavaScript that >> is compatible with GF 3.1. For a long time the JavaScript >> implementation was using representation of the grammar that is >> different from the one used in the Haskell implementation. Now they >> are in synchronized again.
>> The package is bundled with the Foods grammar compiled to JavaScript. >> If you want to use another grammar then you have to compile the >> grammar with option -output-format=js and then you need to modify the >> page editor.html to point to the new grammar.
>> Since now the JavaScript implementation uses the same parsing >> algorithm as the GF shell it is possible to parse even with the >> resource grammar. For most languages the speed is reasonable. For >> Finnish the browser will probably give you a warning that the page is >> too slow and you have to click on "Continue" once or twice.
On Tue, Jan 5, 2010 at 4:54 PM, Muhammad Humayoun <humay...@gmail.com> wrote: > Yes it works well! Thanks. but there is a minor issue: > The file EditorGrammar.js is named "editorGrammar.js" in editor.html > which may create some inconvenience.
Actually the original name was editorGrammar.js. This is also the name in darcs. I change the name on my computer by mistake and since Windows doesn't make case distinction I didn't notice. I will update the Zip package.
> Secondly, the function sym2js of src/GF/Compile/GFCCtoJS.hs, is > underspecified. e.g. for my grammar, I encounter the following error > while compiling to js:
> Writing Unif.pgf... > Writing Unif.js...gf: src/GF/Compile/GFCCtoJS.hs:(130,0)-(132,48): > Non-exhaustive patterns in function sym2js
This shows that you have old version of GF. The syntax editor works with GF 3.1 and there GFCCtoJS is renamed to PGFtoJS.
> On Tue, Jan 5, 2010 at 4:08 PM, Aarne <aarne.ra...@gmail.com> wrote: > > A couple of questions:
> > - I expected to find the runtime system in the directory GF/src/ > > runtime/javascript/, but this is not exactly the same as the files > > behind the link now
> What is different? I pushed all local changes to darcs.
> The names of some files (as mentioned by Humayoun) and the absence of some
files, such as the translator interface. But it's good to know the most relevant files are the same.
> > - it would be nice to have incremental parsing of course. Would it be > > an easy solution to call an external parser server from the editor?
> It is trivial to add completion in the JavaScript runtime. What > requires more work is to update the user interface. For example the > dialog that currently pops up when the user selects "Parse a string" > cannot be altered from the JavaScript code. We need to replace it with > something else. It would be nice if the user could alter the text in > the right-up panel directly rather than in a popup dialog.
Yes, indeed.
> About an external server I think that it makes sense to use the > JavaScript parser for the syntax but keep the lexicon on the server if > it is too long.
> As soon as the JS parser has completion, perhaps. > The editor still doesn't work in the Android's Web Browser and it is > hard to debug there. There also some problems with the rendering on > old versions of IE.
Maybe it's easy to make the translator app work on the Android - as it was on the iPhone: just set the size of the screen so that no scrolling is needed. Also the editor must of course have a more compact layout on a small screen, and this needs some design and experiments.
>> On Tue, Jan 5, 2010 at 4:08 PM, Aarne <aarne.ra...@gmail.com> wrote: >> > A couple of questions:
>> > - I expected to find the runtime system in the directory GF/src/ >> > runtime/javascript/, but this is not exactly the same as the files >> > behind the link now
>> What is different? I pushed all local changes to darcs.
> The names of some files (as mentioned by Humayoun) and the absence of some > files, such as the translator interface. But it's good to know the most > relevant files are the same.
>> > - it would be nice to have incremental parsing of course. Would it be >> > an easy solution to call an external parser server from the editor?
>> It is trivial to add completion in the JavaScript runtime. What >> requires more work is to update the user interface. For example the >> dialog that currently pops up when the user selects "Parse a string" >> cannot be altered from the JavaScript code. We need to replace it with >> something else. It would be nice if the user could alter the text in >> the right-up panel directly rather than in a popup dialog.
> Yes, indeed.
>> About an external server I think that it makes sense to use the >> JavaScript parser for the syntax but keep the lexicon on the server if >> it is too long.
> As soon as the JS parser has completion, perhaps.
>> The editor still doesn't work in the Android's Web Browser and it is >> hard to debug there. There also some problems with the rendering on >> old versions of IE.
> Maybe it's easy to make the translator app work on the Android - as it was > on the iPhone: just set the size of the screen so that no scrolling is > needed. Also the editor must of course have a more compact layout on a small > screen, and this needs some design and experiments. > Regards > Aarne.
