Page 62 of 800
| Page 62 of 800 | Search internet |
The terminal output from the compilation may look thus:
GRD-2009-11-09.UTC:20:02:56.859191 Reading file:base.lgs Parsing Codifying 1st reading 2nd reading 3rd reading 4th reading 5th reading 6th reading 7th reading 8th reading 9th reading Rendering Verifying The page is correct Dumping to cache User rendering Goodbye
This is what it means:
Lgc just wants to tell you what time it is, expressed as a Gregorian Date and in Universal Coordinated Time.
Lgc tells you what it is about to do. If something goes really wrong and you get e.g. a Unix error message, then it can be helpful to know what lgc was doing. You can control the verbosity of lgc(1) if you like.
This tells you that the frontend of lgc tries to parse your source text based on your grammar. Grammar as well as source text is in base.lgs.
This tells you that the backend of lgc tries to make sense of your page (i.e. the page defined in base.lgs).
Lgc 'reads' your page several times. Lgc only parses your page once but keeps reading it until it has understood it.
Lgc has to read a page several times because the lgs language allows to state definitions in arbitrary order. As an example, you may define a macro at the end of a page and use it at the beginning.
The base page is particularly difficult. It not only defines lots of macros. It also defines a macro engine which is the macro expansion machinery itself. It takes lgc nine readings to understand the base page. Most pages take less readings to understand.
The concept of a 'reading' is equivalent to a run of 
or 
. If you run or it may write something like Label(s) may have changed. Rerun to get cross-references right. The lgc compiler is very similar, but instead of saying Definition(s) may have changed. Rerun to get everything right, it just does one more reading.
You can easily write a page which requires an infinite number of readings. If that happens, Ctrl-C is your friend.
This tells you that lgc has understood your page and is about to write information about it to a rendering directory. More on this later.
This tells you that lgc checks your page for correctness. That can take a long time e.g. if your page contains lots of formal proofs.
The notion of 'correctness' is not hardwired into Logiweb. Rather, each page specifies in which sense the page thinks it should be correct. The base page specifies that all test cases must evaluate to 
where denotes 'truth'. In other words, the base specifies that it is itself correct if all tests in its own testsuite succeed.
So the base page is correct according to its own criterion. Logiweb does not really care whether or not a page is correct and happily publishes incorrect pages. But it notes the correctness criterion and whether or not the page was correct according to the criterion.
Each time the base page is referenced from some other page and that other page is compiled, the base page has to 'loaded'. To speed up loading, a compiled version of the base page is stored in a cache in the file system.
This tells you that lgc renders your page according to your prescription.
The base page does not prescribe any particular user rendering, so it is user rendered using default user rendering. More on this later.
A page can specify how it should be macro expanded (by defining a macro engine), how it should be verified (by defining a correctness criterion), and how it should be user rendered. A page can also specify how it should be unpacked, i.e. how the bytes of its most compact 'vector' version should be read.
The is lgc's polite way of saying that it is not going to do any more for you. If 'Goodbye' occurs at the end of an error message, it means you are on your own.
| Page 62 of 800 | Search logiweb.eu |