[perl #61638] [PATCH] Fixed typos in docs
# New Ticket Created by Saleem A. Ansari # Please include the string: [perl #61638] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=61638 Fixed typos in docs. book/ch01_overview.pod | 10 +- book/ch03_pir_basics.pod |2 +- imcc/imcfaq.pod |4 ++-- 3 files changed, 8 insertions(+), 8 deletions(-) Index: docs/book/ch01_overview.pod === --- docs/book/ch01_overview.pod (revision 34295) +++ docs/book/ch01_overview.pod (working copy) @@ -25,7 +25,7 @@ working hard on a spec for Python 3000. The Perl 6 project started moving in two different directions at once: the underlying interpreter architecture and the language grammar and semantics. As people -realized that the two projects could become completely indepent, it +realized that the two projects could become completely independent, it was decided to create a proper language-agnostic virtual machine to support the high-level efforts. The virtual machine was later dubbed Parrot in a fitting turn of life imitating art. @@ -105,7 +105,7 @@ members of the Project Team, or may be held jointly. The Architect also works with the Release Managers to develop and maintain the release schedule. Allison RandalXRandal, Allison currently leads the Parrot -project aschief architect. +project as chief architect. =item Release Managers @@ -166,7 +166,7 @@ Contributors who submit numerous, high-quality patches may be considered to become a Committer. Committers have commit access to the full Parrot repository, but generally work only on one or more -subprojects; Committer categories are described below. Contributors may +subprojects; Committer categories are described below. Contributors may be considered for commit access either by being nominated by another Committer, or by requesting it. @@ -194,7 +194,7 @@ =item Build Manager Build Managers maintain and extend configuration and build subsystems. -They reviews smoke reports and attempt to extend platform support. +They review smoke reports and attempt to extend platform support. =item Lead Tester @@ -225,7 +225,7 @@ Parrot's cage, the development working environment, has a tendency to get messy and disorganized over time. It's the responsibility of the -aptly-named Cage Cleaners to ensure coding standards are followed, that +aptly-named Cage Cleaners to ensure that coding standards are followed, that documentation is complete and accurate, that all tests are functioning properly, and that there are plenty of coding examples for new users to learn from. A class of tickets in the RT tracking system has been created Index: docs/book/ch03_pir_basics.pod === --- docs/book/ch03_pir_basics.pod (revision 34295) +++ docs/book/ch03_pir_basics.pod (working copy) @@ -106,7 +106,7 @@ register data is held. A memory allocator unit translates register names in the form $S0 into an actual fixed memory location. This allocator can also help to optimize register usage so that existing registers are -reused instead of allocating new ones in memory. The sort version is that +reused instead of allocating new ones in memory. The short version is that the programmer should never have to worry about register allocation, and should feel free to use as many as she wants. As with any system, it's a good idea to be mindful of the things that might impact performance Index: docs/imcc/imcfaq.pod === --- docs/imcc/imcfaq.pod (revision 34295) +++ docs/imcc/imcfaq.pod (working copy) @@ -146,9 +146,9 @@ For more examples see the PIR tutorial in Fexamples/tutorial. -=head2 How do I compile and run an PIR module? +=head2 How do I compile and run a PIR module? -Parrot uses the filename extension to detect whether the file is an PIR file +Parrot uses the filename extension to detect whether the file is a PIR file (.pir), a Parrot Assembly file (.pasm) or a pre-compiled bytecode file (.pbc).
Re: Optimizing PMC-based MMD
chromatic wrote: Within the cmp op bodies, we *know* the arity and most of the types of MMD- participant arguments at compile time. We can get the types of PMC participants within the body of the op itself. Thus we could avoid most of the argument marshalling and counting and analysis if we had a way to perform cached MMD lookup without constructing a CallSignature PMC. That would clear up a third of the work. This we should open up to general discussion. The consequence of short-cutting like this is that individual PMCs will no longer be able to override 'cmp' to do something other than multi-dispatch. At the moment, developers still have the option of providing their own quick comparison, which gives an even more extreme speedup than this shortcut. So, question for language developers and other PMC developers, how important is the ability to define a 'cmp' vtable function that's called when the 'cmp' opcode is invoked? Or, is defining a 'cmp' multi for your PMC type enough? Another area for optimization is invoking a Sub from a signature PMC; I believe we're throwing away and recalculating valuable information, though we may have to wait for dramatic improvements until we can unify contexts and CallSignature. Providing a new way of invoking Subs that uses CallSignatures all the way down is already planned in the coming series of calling conventions refactors. The final opportunity for optimization is making the PMC multis defined in PMCs use PCC instead of C calling conventions. Corresponding multis written in PIR already use PCC, and we want to support that, so we should unify our approach. That would remove the NCI expense here, though that's probably minor in comparison to the CallSignature PMC expense. Changing all NCI calls to something more like PCC calls is already planned in the coming series of calling conventions refactors. Changing the Pmc2c generator to build PCC subs instead of NCI Subs is a quick change that could happen now. The calling conventions refactors are non-critical (some will likely land after 1.0), because the interface will stay the same, it's only the internals that will change. Allison
Re: Optimizing PMC-based MMD
On Wed, Dec 24, 2008 at 09:55:58AM -0600, Allison Randal wrote: Within the cmp op bodies, we *know* the arity and most of the types of MMD- participant arguments at compile time. We can get the types of PMC participants within the body of the op itself. Thus we could avoid most of the argument marshalling and counting and analysis if we had a way to perform cached MMD lookup without constructing a CallSignature PMC. That would clear up a third of the work. This we should open up to general discussion. The consequence of short-cutting like this is that individual PMCs will no longer be able to override 'cmp' to do something other than multi-dispatch. Does individual PMCs here mean PMC instance or PMC classes? I.e., are you saying that a specific PMC instance could choose to override the cmp opcode for that individual PMC? If so, do we have any examples where this is being done now? At the moment, developers still have the option of providing their own quick comparison, which gives an even more extreme speedup than this shortcut. So, question for language developers and other PMC developers, how important is the ability to define a 'cmp' vtable function that's called when the 'cmp' opcode is invoked? Or, is defining a 'cmp' multi for your PMC type enough? From a Rakudo perspective, the ability to define custom 'cmp' vtable functions doesn't appear to be at all important. Comparisons are almost invariably done by invoking :multi Sub PMCs of one form or another and letting those handle the MMD dispatch. The opcode form seems to impose too many limitations to be used directly. To turn the question around a bit: I can tell that a lot of work has gone into Parrot to make MMD possible at the vtable level, but I haven't see how vtable MMD is at all useful or usable in languages where operator overloading is possible from the HLL itself. And most dynamic languages I'm looking at seem to support that in one form or another. If someone (Allison) could make an example of how vtable MMD is intended to improve things -- i.e., taking an HLL language statement and showing how that translates to PIR that is improved by vtable MMD, that would be very helpful. The calling conventions refactors are non-critical (some will likely land after 1.0), because the interface will stay the same, it's only the internals that will change. Oh, I'm very disappointed to hear this. Named and positional argument handling still has an odd behavior [*], and Perl 6 still really needs the :lookahead option described earlier in the year. I thought that was going to be made possible by the refactor, and is partially why PDS had calling conventions schedule for the December 2008 release. [*] Currently named parameters are filled from any leftover positionals in the argument list -- there's no way to declare an argument that can _only_ be filled by name, short of defining a :slurpy array that grabs any extra positional arguments and then checking that the slurpy is empty. And, Jonathan can correct me on this if I'm mistaken, but I suspect the other big reason that calling convention refactor was scheduled for the December 2008 release is that it's likely a blocker or important component for the custom dispatcher that Jonathan will be creating for Rakudo as part of his funded grant. That's due to be completed by the end of January, IIRC. Pm
