|
From: Bernard B. <ber...@gm...> - 2020-07-17 06:36:18
|
I fully agree with your point. We still do need an output file containg the grammar as formatted after its compilation. A message telling that there is an error on rule 47 of subgrammar 12 would be a nightmare unless subgrammars and rules have been numbered. And we can't rely on users to write these numbers by hand. In addition, the compiler inserts the "_mm(60.0000) _striated" (by default) instruction that makes it possible to store metronome settings along with the grammar. This overrides the Pclock/Qclock values stored in the ‘-se’ file. If it is too complicated, the PHP interface will be able to read values int the ‘-se’ file and insert this instruction when it is missing. I believe the solution would be an output to a Trace file (with a unique ID as discussed on a previous message). The interface will copy the content of the file to the grammar on which the user is working. In fact, BP2.9.8 only changes the content of the Grammar window. The file is changed only if you do a "save". Indeed, clients are expected to be more than GIU interfaces. But for the moment the PHP environment is sufficient and easy to program for checking basic operation of the application. Bernard Anthony Kozar wrote on 17/07/2020 03:13: > A "compile" command is on the to do list. It might be fairly easy to > implement since "produce items" ends up calling the compiler and we > know that it works ;-) (Although compiler error output has the same \r > problem as trace outputs). I probably just need to find the right > function in the code to call. > > I'm going to disagree though about writing the compiled grammar back > out to the same file. In my "vision" for BP console, I think it > should behave more like a server application. It should receive > requests from "clients" with input files and options specified and > then return output on the console or as new output files. The idea > would be that any request should be exactly repeatable. If input > files are modified, that would not be true. In my opinion, it should > be up to the client environment to make decisions about modifying the > input files. > > I understand that BP2 worked differently, automatically inserting > changes to "open files". That made sense in the GUI environment > especially since the user could decide whether to keep the changes or > not by saving or not saving the open file. I just think that as we > move towards BP becoming a tool used by various clients or user > interfaces that the approach I outlined above will be more flexible. > > In general, I have thought a lot about which parts of BP2 should > become "client" functions and which should become "library" or > "server" functions. I think the client portion should be larger than > just providing a GUI interface. Of course, I don't have all of the > details hammered out and there is plenty of room for discussion. :) > > Anthony > > > On 7/15/20, 9:55 AM, Bernard Bel wrote: >> PS Should this command mention the alphabet file, if any? It is used for >> compilation. I believe that it is not necessary because the application >> is able to pick up, load and compile the alphabet when asked to produce >> items. This means that the compiler does take care of file names at the >> top of the grammar… >> >> ---- >> >> Dear Anthony, >> >> Till now we have tried the console-driven BP using ready-made grammars. >> Indeed the machine recompiles the grammar before running it, but we no >> longer see the result in a "grammar" window. >> >> We need a command such as for instance: >> >> ./bp somepath/-gr.NotReich --compile >> >> This would pick up the “-gr.NotReich” grammar, compile it and save the >> result in the same file as the source. It would send compilation >> messages and compilation errors to stdout (unless some option instructs >> otherwise). >> > > [...] >> >> This is the process currently implemented in BP2.9.8: adding rule >> numbers and inserting the “_mm(60.0000) _striated” instruction picked up >> from timebase settings. >> >> Compilation errors should go to "stdout" which could be retrieved and >> displayed on the PHP interface. >> >> The interface would also take care of reloading the (updated) grammar >> "some time" after it has been compiled. >> >> In other words, this operation would be identical to that on BP2.9.8. >> >> I understand that you'll need to redirect display commands to the >> grammar window to writing a temp file, and thereafter copy this temp >> file over the source grammar file if computation has been successful. >> There is no emergency but this may be put on the agenda! >> >> Bernard > > > > _______________________________________________ > bolprocessor-devel mailing list > bol...@li... > https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel |
