Index: docs/book/ch02_getting_started.pod =================================================================== --- docs/book/ch02_getting_started.pod (revision 35914) +++ docs/book/ch02_getting_started.pod (working copy) @@ -142,7 +142,7 @@ =head1 Building Parrot -Z +Z X The first step before you start playing with Parrot's PASM and PIR @@ -192,7 +192,7 @@ =head3 Patch submission -Z +Z X Parrot development proceeds through a continuous stream of patches. @@ -324,7 +324,7 @@ =head3 Bug tracking -Z +Z X Bug reports go to the same address as patch submissions Index: docs/book/ch08_architecture.pod =================================================================== --- docs/book/ch08_architecture.pod (revision 35914) +++ docs/book/ch08_architecture.pod (working copy) @@ -2,7 +2,7 @@ =head0 Parrot Internals -Z +Z This chapter details the architecture and internal workings of Parrot, and attempts to explain how Parrot has been designed and how it operates. @@ -13,7 +13,7 @@ =head1 Core Design Principles -Z +Z X Three main principles drive the design of @@ -72,7 +72,7 @@ =head1 Parrot's Architecture -Z +Z The X X @@ -85,7 +85,7 @@ =begin figure Parrot's flow -Z +Z F =end figure @@ -113,7 +113,7 @@ =head2 Parser -Z +Z X X @@ -171,7 +171,7 @@ =head2 Compiler -Z +Z X @@ -194,7 +194,7 @@ =head2 Optimizer -Z +Z X X @@ -316,7 +316,7 @@ =head1 The Interpreter -Z +Z The X interpreter is the engine that actually runs the code emitted by the @@ -360,7 +360,7 @@ =head2 Registers -Z +Z X As we've seen in previous chapers, Parrot has four basic types of @@ -375,7 +375,7 @@ =head2 Strings -Z +Z X X @@ -455,7 +455,7 @@ =head2 Variables -Z +Z X X @@ -506,7 +506,7 @@ =head2 Bytecode -Z +Z Like any CPU, software, or hardware, Parrot needs a set of instructions to tell it what to do. For hardware, this is a stream of @@ -560,7 +560,7 @@ =head1 I/O, Events, and Threads -Z +Z Parrot has comprehensive support for I/O, threads, and events. These three systems are interrelated, so we'll treat them together. The @@ -570,7 +570,7 @@ =head2 I/O -Z +Z Parrot's base X I/O system is fully X asynchronous with callbacks and per-request private data. Since this @@ -637,7 +637,7 @@ =head2 Events -Z +Z An X event is a notification that something has happened: the user has manipulated a GUI element, an I/O request has @@ -710,7 +710,7 @@ =head2 Signals -Z +Z X Signals are a special form of event, based on the standard Unix signal @@ -771,7 +771,7 @@ =head2 Threads -Z +Z X Threads are a means of splitting a process into multiple pieces that @@ -884,7 +884,7 @@ =head1 Objects -Z +Z X Perl 5, Perl 6, Python, and Ruby are all object-oriented languages in @@ -899,7 +899,7 @@ =head2 Generic Object Interfacing -Z +Z X Parrot's object system is very simple--in fact, a PMC only has to handle @@ -924,7 +924,7 @@ =head2 Parrot Objects -Z +Z X X @@ -986,7 +986,7 @@ =head2 Mixed Class-Type Support -Z +Z X X @@ -1015,7 +1015,7 @@ =head1 Advanced Features -Z +Z Since the languages Parrot targets (like Perl and Ruby) have sophisticated concepts as core features, it's in Parrot's best @@ -1024,7 +1024,7 @@ =head2 Garbage Collection -Z +Z X It's expected that modern languages have garbage collection built in. @@ -1099,7 +1099,7 @@ =head2 Multimethod Dispatching -Z +Z X Multimethod dispatching (also known as signature-based dispatching) is @@ -1162,7 +1162,7 @@ =head2 Continuations -Z +Z X Continuations are possibly the most powerful high-level flow control @@ -1234,7 +1234,7 @@ =head2 Coroutines -Z +Z X A coroutine is a subroutine or method that can suspend itself partway @@ -1256,7 +1256,7 @@ =head1 Conclusion -Z +Z We've touched on much of Parrot's core functionality, but certainly not all. Hopefully we've given you enough of a feel for how Parrot Index: docs/book/ch12_opcodes.pod =================================================================== --- docs/book/ch12_opcodes.pod (revision 35914) +++ docs/book/ch12_opcodes.pod (working copy) @@ -2,7 +2,7 @@ =head1 Opcodes and Runcores -Z +Z The smallest executable component is not the compilation unit or even the subroutine, but is actually the opcode. Opcodes in PASM, like opcodes @@ -50,7 +50,7 @@ =over 4 -=item* Slow Core +=item * Slow Core The slow core is a basic runcore design that treats each opcode as a separate function at the C level. Each function is called, and returns @@ -71,7 +71,7 @@ UPDATE_INTERPRETER(); } -=item* Fast Core +=item * Fast Core The fast core is a bare-bones core that doesn't do any of the bounds-checking or context updating that the slow core does. The fast @@ -86,7 +86,7 @@ DISPATCH_OPCODE(pc); } -=item* Switch Core +=item * Switch Core As its name implies, the switch core uses a gigantic C C structure to execute opcodes. Here's a brief example of how this @@ -109,7 +109,7 @@ pointer, dereferencing the opcode pointer, and then a jump to the C statement for the next opcode. -=item* Computed Goto Core +=item * Computed Goto Core I is a feature of some C compilers where a label is treated as a piece of data that can be stored as a C pointer. Each @@ -167,7 +167,7 @@ presented here. However, as we shall see with the precomputed goto core, it isn't optimized as aggressively as is possible. -=item* Precomputed Goto Core +=item * Precomputed Goto Core The precomputed goto core is an amazingly fast optimized core that uses the same computed goto feature, but performs the array dereferencing @@ -208,9 +208,9 @@ available with compilers that support computed goto, such as GCC. Parrot will not have access to this core if it is built with a different compiler. -=item* Tracing Core +=item * Tracing Core -=item* Profiling Core +=item * Profiling Core The profiling core analyzes the performance of Parrot, and helps to determine where bottlenecks and trouble spots are in the programs that @@ -227,7 +227,7 @@ number of calls to each subroutine made. All this information is helpfully printed to the STDERR output for later analysis. -=item* GC Debug Core +=item * GC Debug Core Parrot's garbage collector has been known as a weakness in the system for several years. In fact, the garbage collector and memory management @@ -243,7 +243,7 @@ performance is terrible, but that's not the point: it's almost guaranteed to find problems in the memory system if they exist. -=item* Debug Core +=item * Debug Core The debug core works like a normal software debugger, such as GDB. The debug core executes each opcode, and then prompts the user to enter a @@ -361,6 +361,7 @@ =head2 Dynops +=cut ########################################################################## # PSEUDOPOD LEGEND Index: docs/book/ch09_pct.pod =================================================================== --- docs/book/ch09_pct.pod (revision 35914) +++ docs/book/ch09_pct.pod (working copy) @@ -55,7 +55,7 @@ =over 4 -=item* A main file +=item * A main file The main file should contain the C<:main> function that is the driver program for the compiler. Here, a new C object is @@ -64,14 +64,14 @@ although thankfully they tend to be very short. Most of the action happens elsewhere. -=item* A parser file +=item * A parser file The grammar for the high level language is specified using the Perl 6 grammar engine (PGE) and is stored in a C<.pg> file. This file should subclass the C class and implement all the necessary rules to successfully parse the language. -=item* An actions file +=item * An actions file Actions files are written in NQP. They take match objects generated by the grammar file and convert them into an Abstract Syntax Tree (AST) @@ -196,18 +196,18 @@ =over 4 -=item* Rules +=item * Rules Rules are the most basic grammar element. Rules may call subrules and may also contain arbitrary whitespace, which is ignored. -=item* Tokens +=item * Tokens Tokens represent basic regular expressions. They may not call subrules and whitespace is treated literally. {{I don't think this is right, but I'm adding it here anyway as a placeholder -- Whiteknight}} -=item* Protoregex +=item * Protoregex A protoregex is like a rule or a token, except it can be overloaded dynamically. Index: docs/book/ch04_pir_subroutines.pod =================================================================== --- docs/book/ch04_pir_subroutines.pod (revision 35914) +++ docs/book/ch04_pir_subroutines.pod (working copy) @@ -1,7 +1,5 @@ =pod -Z - =head1 Subroutines Z @@ -454,7 +452,7 @@ =head2 Compilation Units Revisited -Z +Z The term "compilation unit" is one that's been bandied about throughout the chapter and it's worth some amount of explanation here. A compilation unit @@ -499,7 +497,7 @@ =head3 PASM Subroutines -Z +Z X X @@ -537,7 +535,7 @@ =head3 Namespaces -Z +Z X X<.namespace> @@ -586,7 +584,7 @@ =head3 Calling Methods -Z +Z Now that we've discussed namespaces, we can start to discuss all the interesting things that namespaces enable, like object-oriented @@ -793,12 +791,12 @@ =over 4 -=item* Identifies coroutines +=item * Identifies coroutines When Parrot sees a yield, it knows to create a coroutine PMC object instead of a Subroutine one. -=item* Creates a continuation +=item * Creates a continuation Continuations, as we have already seen, allow us to continue execution at the point of the continuation later. It's like a snapshot of @@ -806,7 +804,7 @@ the coroutine and stores the continuation object in the coroutine object or later resuming from the point of the C<.yield>. -=item* Returns a value +=item * Returns a value C<.yield> can return a value N to the caller. It is basically the same as a C<.return> in this regard. Index: docs/book/ch13_reference.pod =================================================================== --- docs/book/ch13_reference.pod (revision 35914) +++ docs/book/ch13_reference.pod (working copy) @@ -2,7 +2,7 @@ =head1 Parrot Reference -Z +Z This chapter contains a condensed list of PASM opcodes, PIR directives and instructions, and Parrot command-line options, sorted alphabetically @@ -13,7 +13,7 @@ =head2 PASM Opcodes -Z +Z X For complete details on each opcode and the latest changes, read the @@ -1245,7 +1245,7 @@ =begin table picture Interpinfo flags -Z +Z =headrow @@ -2415,7 +2415,7 @@ =begin table picture Stringinfo arguments -Z +Z =headrow @@ -2812,7 +2812,7 @@ =head2 PIR Directives -Z +Z X This is a summary of PIR directives. Directives are preprocessed by the @@ -3031,7 +3031,7 @@ =head2 PIR Instructions -Z +Z X This section is a quick reference to PIR instructions. For more details @@ -3323,7 +3323,7 @@ =head2 Parrot Command-Line Options -Z +Z X X @@ -3336,7 +3336,7 @@ =head3 General Usage -Z +Z parrot [options] file [arguments] @@ -3346,7 +3346,7 @@ =head3 Assembler Options -Z +Z =over 4 @@ -3374,7 +3374,7 @@ =begin table picture Debug bits -Z +Z =headrow @@ -3513,7 +3513,7 @@ =begin table picture Optimizations -Z +Z =headrow @@ -3561,7 +3561,7 @@ =head3 Bytecode Interpreter Options -Z +Z X X Index: docs/book/ch10_hlls.pod =================================================================== --- docs/book/ch10_hlls.pod (revision 35914) +++ docs/book/ch10_hlls.pod (working copy) @@ -165,14 +165,14 @@ =over 4 -=item* VTable methods +=item * VTable methods VTable methods are the standard interface for PMC data types, and all PMCs have them. If the PMCs were written properly to satisfy this interface all the necessary information from those PMCs. Operate on the PMCs at the VTable level, and we can safely ignore the implementation details of them. -=item* Class Methods +=item * Class Methods If a library returns data in a particular format, the library reuser should know, understand, and make use of that format. Classes written in other Index: docs/book/ch11_pmcs.pod =================================================================== --- docs/book/ch11_pmcs.pod (revision 35914) +++ docs/book/ch11_pmcs.pod (working copy) @@ -2,7 +2,7 @@ =head1 PMCs -Z +Z PMCs are one of the four fundamental data types in Parrot, and definitely one of the most useful. A PMC can contain a single scalar value (integer, floating @@ -229,8 +229,8 @@ =head3 Loading dynpmcs +=cut - ########################################################################## # PSEUDOPOD LEGEND # Index: docs/book/ch07_testing_and_debugging.pod =================================================================== --- docs/book/ch07_testing_and_debugging.pod (revision 35914) +++ docs/book/ch07_testing_and_debugging.pod (working copy) @@ -2,7 +2,7 @@ =head0 Testing and Debugging -Z +Z Programming languages and the virtual machines on which they run are just one small part of the total programming ecosystem. Programmers require not @@ -15,7 +15,7 @@ =head1 Writing Tests -Z +Z X Parrot is volunteer-driven, and contributions from new users are always @@ -118,7 +118,7 @@ =head1 The Parrot Debugger -Z +Z =cut