text:
Parrot Virtual Machine/Introduction

What Is Parrot?
Parrot is a virtual machine (VM), similar to the Java VM and the .NET VM. However, unlike these two which are designed for statically-typed languages like Java or C#, Parrot is designed for use with dynamically typed languages such as Perl, Python, Ruby, or PHP.

The Parrot VM itself is written in the C programming language, which means that—in theory—it will be portable to a large number of different computer architectures and operating systems. It is written to be easily modular and extensible.

Programmers can write in any of the languages for which a Parrot-capable compiler exists. Modules written in one language, such as Perl, can transparently interoperate with modules which have originally been written in any of the other languages supported by Parrot. This easy interoperability and native support for cutting-edge dynamic programming features makes Parrot an important tool for next-generation language designers and implementers.

It is precisely because Parrot is intended to support so many diverse high level languages that Parrot has developed a very general and feature-rich architecture. Much of the Parrot architecture is still under active development, so those parts will not be able to be properly discussed here in this book quite yet. Once Parrot reaches a stable release, and more details are set in stone, this book will be able to provide a more comprehensive coverage.

History of Parrot
The Parrot project was born from the Perl 6 development project. As such, the history of Parrot, at least the early history of it, is closely tied to the history of Perl 6. In fact, understanding just how large and ambitious Perl 6 is, you'll start to understand why Parrot must have all the features it has.

It was famously quoted about version 5 of the Perl programming language that "nothing can parse Perl but perl". The implication was that the perl executable was the only program that could reliably parse the Perl programming language. There were two reasons for this. First, the Perl language didn't follow any formal specification; The behavior of the perl interpreter was the definitive documentation for the actions of Perl. Second, the Perl programming language allowed the use of source filters, programs which could modify their own source code prior to execution. This means that to reliably parse and understand a Perl program, you needed to be able to execute the source filters reliably. The only program that could do both was perl.

The next planned version of Perl, Perl 6, was supposed to be a major rewrite of the language. In addition to standardizing and bringing sanity to all the features which had slowly entered the language grammar, it was decided that Perl 6 would be a formal specification first, and implementations of that specification later.

The name "Parrot" was first used as an April Fool's joke. The story claimed that the Perl and Python languages (which are competitors, and which were both undergoing major redesigns) were going to merge together into a single language named Parrot. This was, of course, a hoax, but the idea was a powerful one. When the project was started to create a virtual machine that would be capable of running not only Perl 6, but also Python and other dynamic languages, the name Parrot was a perfect fit.

The first release of Parrot, 0.0.1, was released in September 2001. The development team has prepared a stable point release on the third Tuesday of every month.

The Parrot Foundation
The Parrot Foundation was established in mid 2008 to serve as an advocate for Parrot. The Parrot Foundation is a non-profit charity organization in the United States, and donations to the foundation are tax-deductable.

Prior to the creation of the Parrot Foundation, Parrot was managed and overseen by the Perl Foundation. This relationship was historical in nature, due to the fact that Parrot was originally intended just to be the backend for the Perl 6 programming language. Since Parrot has grown beyond that, and is attempting to deal equally with all high-level dynamic programming languages, it was decided to become separate from the Perl Foundation.

Parrot's website is http://www.parrot.org

Who Is This Book For?
This book is for readers at the intermediate to advanced level with a solid background in computer programming. Perl Programming would be a good start, although a background in any dynamic language would be helpful. Having a background in Compiler Construction, Regular Expressions, or the compiler-building tools Lex and Yacc would also be a benefit.

For the sections about Parrot hacking, a background knowledge of C Programming is required.

What Will We Cover?
This book is going to serve as, at least, a basic introduction to the Parrot Virtual Machine. We will cover basic programming for Parrot in the lowest-level languages that it supports: PIR and PASM. We will also discuss one of the greatest strengths of the Parrot platform, the Parrot Compiler Tools (PCT), which enables compilers to be written easily for higher-level languages like Perl and Python.

Later sections will actually delve into the Parrot internals, and discuss how Parrot works and how to contribute code for the Parrot development project. Extensive reference materials at the end of the book will try to keep track of the information that is most necessary for developers.

Where To Get More Information
The definitive source for Parrot information and documentation is the Parrot project website, http://www.parrot.org. Parrot programmers, hackers, and enthusiasts also chat in the Parrot IRC chatroom.

How To Get Involved In Parrot Development
The Parrot development process is large and varied. Depending on skill level, there are many opportunities for a person to get involved in Parrot development. Here are some examples:
 * If you are good at C programming:If you know C programming, help is always needed to work on Parrot. In addition to normal development tasks, there are bug reports to resolve, compile errors to fix, new platforms to port to, and optimizations to perform. Parrot needs to be ported to many different systems, and it needs to be properly tested on all of them.
 * If you are good with Perl programming:Much of the Parrot build tools are written in Perl 5. However, there is also a massive development effort to support the Perl 6 project. An intermediate language which is similar to Perl 6 but with many missing features called Not Quite Perl (NQP) is used to implement compilers for higher-level languages. If you are good with Perl and are willing to learn Perl 6 and NQP, there is a lot of compiler-implementation work that needs to be done.
 * If you are good with system administration:Parrot needs to be built and tested regularly. People are always needed who are willing to perform regular builds and tests of Parrot. If you are willing to set up automated build bot to perform regular builds and tests, that's even better.
 * If you can write:This book needs your help, and anybody can edit it. Also, there are a number of other book-writing projects concerning Parrot that are looking for active authors and editors. The more is written about Parrot, the more new users will be able to learn about it.

If you don't fall cleanly into any of these categories, there are other opportunities to help as well. This might be a good opportunity for you to learn a new skill, like programming Perl 6, PIR, or NQP. If you are interested in writing or editing, you can help with this wikibook too!

Parrot Developers
There are several different roles that people have taken up in Parrot development, even though there is no centralized management hierarchy. Volunteers tend to fulfill certain roles that they enjoy and that they have skill at.

 * Architect: The Parrot Architect, currently Allison Randal, is in charge with laying out the overall design specifications for Parrot. The architect has the final say in important decisions and is responsible to ensure that design documents are up to date. By laying out the overall requirements of the system, other volunteers are able to contribute to areas where they are most interested.
 * Pumpking:The Pumpking has oversight of the Parrot source repository, and is also the lead developer. The Pumpking defines coding standards that all contributors must follow, and helps to coordinate other contributors.
 * Release Managers: Parrot has a schedule of making releases approximately once a month. The release manager oversees this process, and ensures that releases are high quality. Release managers will control when new features can be added, and when code should be frozen for debugging. Pre-release debugging sessions are very productive and important periods for Parrot development, and ensure that many bugs get fixed between each release.
 * Committer: A committer is a person with write access to the Parrot SVN repository. Committers typically have submitted several patches and participated in Parrot-related discussions.
 * Metacommitter: A metacommitter is a person who has write access to the Parrot SVN repository and is also capable of promoting new committers. The architect and the Pumpking are automatically metacommitters, but there are several others too.

Among the above groups, there are other designations as well. This is because many committers tend to focus their efforts on a relatively small portion of the Parrot development effort.
 * Core Developer: A person who works on Parrot internals, typically one or two subsystems. Core developers need to be skilled in C programming, and also need to work with many development utilities written in Perl.
 * Compiler Developer: These developers, like the Core Developers are working on the internals of Parrot, typically by writing lots of C code. In contrast, Compiler Developers focus their effort on the various compiler front-ends such as IMCC, PIRC, PGE, or TGE.
 * High-Level Language Developer: A high-level language developer is a person who is working to implement a high-level language on Parrot. Even though they have commit access to the whole repository, many high-level language developers will focus only on a single language implementation. High-level language developers need to be skilled in PCT and many of the Perl 6-based development tools for HLLs.
 * Build Managers:Build managers help to create and maintain tools that other developers rely on.
 * Testers: Testers create and maintain a suite of hundreds and thousands of tests to verify the operations of Parrot, its subsystems, its compilers and the high-level languages that run on it.
 * Platform Porters: A platform porter ensures that Parrot can be built on multiple platforms. Porters must build and test Parrot on different platforms, and also create and distribute pre-compiled installation packages for different platforms.

This certainly isn't an exhaustive list of possible roles either. If you have programming skills, but don't know if you fit in well to any of the designations above, your help is still needed.

Resources

 * http://www.parrotcode.org/docs/intro.html
 * http://www.parrotcode.org/docs/roadmap.html
 * http://www.parrotcode.org/docs/parrothist.html

title: Parrot Virtual Machine/Introduction


text:
Parrot Virtual Machine/Parrot Assembly Language

Parrot Assembly Language
The Parrot Virtual Machine (PVM) operates on a special-purpose bytecode format. All instructions in PVM are converted into bytecode instructions to be operated on by the virtual machine. In the same way that ordinary assembly languages share a one-to-one correspondence to the underlying machine code words, so too do the Parrot bytecode words have a similar correspondence to a Parrot Assembly Language (PASM).

The PASM is very similar to traditional assembly languages, except that the instructions provide access to many of the dynamic and high-level features of the Parrot system.

Instruction Types and Operands
Internally to parrot, there are many many different instructions. Some instructions are just variations of each other with the same behavior, but different arguments. For instance, there are instructions for:

add_n_n_n

add_i_i_i

add_i_i_ic

add_n_n_nc

The letters after the name of the instruction specify what kinds of operands that instruction requires. takes an integer (i) and an integer constant (ic) and returns an integer (i). takes two floating point numbers and returns a floating point number.

In PASM, when you write the following statement:

add $I0, $I1, $I2

Parrot looks up the appropriate instruction from the list,  and calls it. The user sees 1 instruction, "add", but Parrot actually has multiple instructions and decides which to use automatically for you. If you type the following into Parrot:

add $P0, $I1, $I2

You will get an error message that there is no such instruction. This should help you debug your programs.

Parrot Assembly Basics
Parrot is a register-based virtual machine. There are an undetermined number of registers that do not need to be instantiated before they are called. The virtual machine will make certain to create registers as they are needed, and rearrange them as makes sense to do so. Register names are lexically scoped, so register "$P0" in one function is not necessarily the same data location as register "$P0" in another function.

All registers start with a "$" sign. Following the "$", called the "sigil", there is a letter that denotes the data type of the register, followed by the register number. There are 4 types of data items, each with a unique register character identifier. These are:

 * String: String registers start with an "S". String registers can be named things like "$S0" or "$S100".
 * Integer: Integer registers start with an "I". Integer registers can be named things like "$I0" or "$I56".
 * Number: Floating point number registers, registers which can hold a floating point number, start with a letter "N". These registers can be named things like "$N0" or "$N354".
 * PMC: PMCs are advanced object-oriented data types, and a PMC register can be used to hold many different kinds of data. PMC registers start with a "P" identifier, and can be named things like "$P0" or "$P35".

Basic Statements
A basic PASM statement contains an optional label, an instruction mnemonic, and a series of comma-separated arguments. Here is an example:

my_label: add_n $P0, $P1, $I1

In this example the add_n instruction performs addition on two registers and stores the result in a third. The values from $P1 and $I1 are added together, and the result is stored in $P0. Notice that the operands are different types. One of the arguments, and the result are both PMC registers, but the second operand is an integer and the add_n instruction is an integer instruction. Parrot will automatically handle data type conversions as necessary when performing instructions like this. The only thing that is required is that it is possible to convert between two data types. If it is possible, Parrot will handle the details. In some cases, however, automatic type conversions are not possible and in these cases Parrot will raise an exception.

Directives
PASM has few available directives.

 * .pcc_sub: This directive defines the start of a new subroutine.

Resources

 * http://www.parrotcode.org/docs/pdd/pdd06_pasm.html

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/


text:
Starting A Website

{| class="toccolours" style="float:right; margin: 0 0 0 0; width:222px; text-align:left; clear:right;"
 * style="background:#dddddd; text-align:center;"|

Contents

 * /Understanding the Internet/
 * /Basic Web Terminology/
 * /Server-Side Services/
 * /Client-Side Services/
 * /Creating a Website/
 * /Choosing a Hosting Service/
 * /Uploading Files/
 * /Setting Up E-mail/
 * /Content Management Systems/
 * /Resources On Programming/
 * /Gathering Information About Visitors/
 * /Effective online strategies/
 * /Banner ads/
 * /Link development/
 * /External resources/
 * }
 * /External resources/
 * }
 * }

Création de site web

title: Starting A Website


text:
Parrot Virtual Machine/Parrot Programming

Parrot Programming
The Parrot Virtual Machine (PVM) can be programmed using a variety of languages, scripts, and techniques. This versatility can be confusing at first. Here are some ways that Parrot can be programmed:

 * 1) Parrot Assembly Language (PASM). This is the lowest human-readable way to program Parrot, and is very similar to traditional assembly languages.
 * 2) Parrot Intermediate Representation (PIR). This is a higher-level language which is easier to program in than PASM, and significantly more common.
 * 3) Not Quite Perl (NQP). This is a bare-bones partial implementation of the Perl 6 language, which is designed for bootstrapping. It is higher-level than PIR and has many of the features and the capabilities of Perl 6. At the moment NQP is not fully-featured and must be compiled separately into bytecode before it can be run on Parrot.
 * 4) Custom Languages. Using the Parrot Compiler tools (PCT), new dynamic languages can easily be implemented on Parrot. Once a parser and libraries have been created for a language, that language can be used to program for Parrot. Many common programming languages, including Perl 6, Python, and JavaScript (ECMAScript) are being implemented on Parrot. We will discuss more languages in a later section.

Programming Steps
There are a number of different methods to program Parrot, as we see in the list above. However, different programming methods require different steps. Here, we will give a very brief overview of some of the ways you program Parrot.

 * PASM and PIR:A program written in PASM or PIR, such as  or , can be run in one of two different ways. They can be interpreted directly by typing (on most Windows and Unix/Linux systems):

./parrot Foo.pasm

 * or

./parrot Bar.pir

 * This will run Parrot in interpreter mode. However, we can compile these programs down to Parrot Bytecode (PBC) using the following flags:

./parrot -o Foo.pbc Foo.pir ./parrot -o Bar.pbc Bar.pir

 * Of course, you can name the output files anything you want. Once you have a PBC file, you can run it like this:

./parrot Foo.pbc

 * NQP:NQP must be compiled down to PIR using the NQP compiler. This is located in the compilers/nqp directory of the Parrot repository
 * High Level Languages:To program parrot in a higher-level language than NQP or PIR—such as Perl 6, Python, or Ruby—there must first be a compiler available for that language. To run file  for example (".pl" is the file extension for Perl programs), you would type:

./parrot languages/perl6/perl6.pbc Foo.pl

 * This runs the Perl 6 compiler on Parrot, and passes the file name  to the compiler. To output a file into PIR or PBC, you would use the   option to specify an output format.

Virtual Machines?
One term that we are going to be using frequently in this book is "Virtual Machine", or VM for short. It's worth discussing now what exactly a VM is.

Before talking about virtual machines, let's consider actual computer hardware first. In an ordinary computer system, a native machine, there is a microprocessor which takes instructions and performs the necessary actions. Those instructions are written in a high level language and compiled into the binary machine code that the processor uses. The problem with this is that different types of processors use a different machine code, and to get a program to run on different platforms it needs to be recompiled for each.

A virtual machine, unlike a regular computer processor, is built using software, not hardware. The virtual machine is written in a high level language, and compiled to machine code as usual. However, programs that run on the virtual machine are compiled into bytecode instead of machine code. This bytecode runs on top of the virtual machine, and the virtual machine converts it into processor instructions.

Here is a table that summarizes some of the important differences between a virtual machine and a native machine:


text:
Parrot Virtual Machine/Parrot Intermediate Representation

Parrot Intermediate Representation
The Parrot Intermediate Representation (PIR) is similar in many respects to the C programming language: It's higher-level than assembly language but it is still very close to the underlying machine. The benefit to using PIR is that it's easier to program in than PASM, but at the same time it exposes all of the low-level functionality of Parrot.

PIR has two purposes in the world of Parrot. The first is to be used as a target for automatic code generators from high-level languages. Compilers for high-level languages emit PIR code, which can then be interpreted and executed. The second purpose is to be a low-level human-readable programming language in which basic components and Parrot libraries can be written. In practice, PASM exists only as a human-readable direct translation of Parrot's bytecode, and is rarely used to program by humans directly. PIR is used almost exclusively to write low-level software for Parrot.

PIR Syntax
PIR syntax is similar in many respects to older programming languages such as C or BASIC. In addition to PASM-like operations, there are control structures and arithmetic operations which simplify the syntax for human readers. All PASM is legal PIR code, PIR is almost little more then an overlay of fancy syntax over the raw PASM instructions. When available, you should always use PIR's syntax instead of PASM's for ease.

Even though PIR has more features and better syntax than PASM, it is not itself a high-level language. PIR is still very low-level and is not really intended for use building large systems. There are many other tools available to language and application designers on Parrot that PIR only really needs to be used in a small subset of areas. Eventually, enough tools might be created that PIR is never needed to be used directly.

PIR and High-Level Languages
PIR is designed to help implement higher-level languages such as Perl, TCL, Python, Ruby, and PHP. As we've discussed before, high-level languages (HLL) are related to PIR in two possible ways:

 * 1) We write a compiler for the HLL using the language NQP and the Parrot Compiler Tools (PCT). This compiler is then converted to PIR, and then to Parrot bytecode.
 * 2) We write code in the HLL and compile it. The compiler converts the code into a tree-like intermediate representation called PAST, to another representation called POST, and finally to PIR code. From here, the PIR can be interpreted directly, or else it can be further compiled to Parrot bytecode.

PIR, therefore, has features that help to enable writing compilers, and it also has features that support the HLLs that are written using those compilers.

Comments
Similarly to Perl, PIR uses the " " symbol to start comments. Comments run from the  until the end of the current line. PIR also allows the use of POD documentation in files. We'll talk about POD in more detail later.

Subroutines
Subroutines start with the  directive, and end with the   directive. We can return values from a subroutine using the  directive. Here is a short example of a function that takes no parameters and returns an approximation of π:

.sub 'GetPi' $N0 = 3.14159 .return($N0) .end

Notice that the subroutine name is written in single quotes. This isn't a requirement, but it's very helpful and should be done whenever possible. We'll discuss the reasons for this below.

Subroutine Calls
There are two methods to call a subroutine: Direct and Indirect. In a direct call, we call a specific subroutine by name:

$N1 = 'GetPi'

In an indirect call, however, we call a subroutine using a string that contains the name of that subroutine:

$S0 = 'GetPi' $N1 = $S0

The problem arises when we start to use named variables (which we will discuss in more detail below). Consider the following snippet where we have a local variable called "GetPi":

GetPi = 'MyOtherFunction' $N0 = GetPi

In this snippet here, do we call the function "GetPi" (since we made the call ) or do we call the function "MyOtherFunction" (since the variable GetPi contains the value 'MyOtherFunction')? The short answer is that we would call the function "MyOtherFunction" because local variable names take precidence over function names in these situations. However, this is a little confusing, isn't it? To avoid this confusion, there are some standards that people use to make this easier:

By sticking with this convention, we avoid all possible confusions later on.

Subroutine Parameters
Parameters to a subroutine can be declared using the  directive. Here are some examples:

.sub 'MySub' .param int myint .param string mystring .param num mynum .param pmc mypmc

In a parameter declaration, the  directives must be at the top of the function. You may not put comments or other code between the  and   directives. Here is the same example above:

Named Parameters
Parameters that are passed in a strict order like we've seen above are called positional arguments. Positional arguments are differentiated from one another by their position in the function call. Putting positional arguments in a different order will produce different effects, or may cause errors. Parrot supports a second type of parameter, a named parameter. Instead of passing parameters by their position in the string, parameters are passed by name and can be in any order. Here's an example:

.sub 'MySub' .param int yrs :named("age") .param string call :named("name") $S0 = "Hello ". call $S1 = "You are ". yrs $S1 = $S1. " years old   print $S0    print $S1 .end .sub main :main    'MySub'("age" => 42, "name" => "Bob") .end

In the example above, we could have easily reversed the order too:

.sub main :main 'MySub'("name" => "Bob", "age" => 42)   # Same! .end

Named arguments can be a big help because you don't have to worry about the exact order of variables, especially as argument lists get very long.

Optional Parameters
Functions may declare optional parameters, which the caller may or may not specify. To do this, we use the  and   modifiers:

.sub 'Foo' .param int bar :optional .param int has_bar :opt_flag

In this example, the parameter  will be set to 1 if   was supplied by the caller, and will be 0 otherwise. Here is some example code that takes two numbers and adds them together. If the second argument is not supplied, the first number is doubled:

.sub 'AddTogether' .param num x .param num y :optional .param int has_y :opt_flag

if has_y goto ive_got_y y = x ive_got_y: $N0 = x + y .return($N0) .end

And we will call this function with

'AddTogether'(1.0, 1.5) #returns 2.5 'AddTogether'(3.0)      #returns 6.0

Slurpy Parameters
A subroutine can take any number of arguments, which can be loaded into an array. Parameters which can accept a variable number of input arguments are called  parameters. Slurpy arguments are loaded into an array PMC, and you can loop over them inside your function if you wish. Here is a short example:

.sub 'PrintList' .param list :slurpy print list .end

.sub 'PrintOne' .param item print item .end

.sub main :main PrintList(1, 2, 3) # Prints "1 2 3" PrintOne(1, 2, 3) # Prints "1" .end

Slurpy parameters absorb the remainder of all function arguments. Therefore, slurpy parameters should only be the last argument to a function. Any parameters after a slurpy parameter will never take any values, because all arguments passed for them will get absorbed by the slurpy parameter instead.

Flat Argument Arrays
If you have an array PMC that contains data for a function, you can pass in the array PMC. The array itself will become a single parameter which will be loaded into a single array PMC in the function. However, if you use the  keyword when calling a function with an array, till will pass each element of the array into a different parameter. Here is an example function:

.sub 'ExampleFunction' .param pmc a .param pmc b  .param pmc c  .param pmc d :slurpy

We have an array called x that contains three Integer PMCs: [1, 2, 3]. Here are two examples:

Local Variables
Local variables can be defined using the  directive, using a similar syntax as is used with parameters:

.local int myint .local string mystring .local num mynum .local pmc mypmc

In addition to local variables, in PIR you can use the registers for data storage as well.

Namespaces
Namespaces are constructs that allow the reuse of function and variable names without causing conflicts with previous incarnations. Namespaces are also used to keep the methods of a class together, without causing naming conflicts with functions of the same names in other namespaces. They are a valuable tool in promoting code reuse and decreasing naming pollution.

In PIR, namespaces are specified with the  directive. Namespaces may be nested using a key structure:

.namespace ["Foo"] .namespace ["Foo";"Bar"] .namespace ["Foo";"Bar";"Baz"]

The root namespace can be specified with an empty pair of brackets:

.namespace [] #Right! Enters the root namespace .namespace    #WRONG! Brackets are required!

Strings
Strings are a fundamental datatype in PIR, and are incredibly flexible. Strings can be specified as quoted literals, or as "Heredoc" literals in the code.

Heredocs
Heredoc string literals have become a common tool in modern programming languages to specify very long multi-line string literals. Perl programmers will be familiar with them, but so will most shell programmers and even modern .NET programmers too. Here is how a Heredoc works in PIR:

$S0 = << "TAG"

This is part of the Heredoc string. Everything between the '<< "TAG"' is treated as a literal string constant. This string ends when the parser finds the end marker.

TAG

Heredocs allow long multi-line strings to be entered without having to use lots of messy quotes and concatenation operations.

Encodings and Charsets
Quoted string literals can be specified to be encoded in a specific characterset or encoding

File Includes
You can include an external PIR file into your current file using the  directive. For example, if we wanted to include the file "MyLibrary.pir" into our current file, we would write:

.include "MyLibrary.pir"

Notice that the  directive is a raw text-substitution function. A file of PIR code is not self contained the way you might expect from some other languages. For instance, one problem that occurs relatively commonly among new users is the concept of namespace overflow. Consider two files, A.pir and B.pir:

The  directive from file A overflows into file B, which is counter intuitive for most programmers.

Classes and Methods
We'll devote a lot of time talking about classes and object-oriented programming later on in this book. However, since we've already talked about namespaces and subroutines a little bit, we can lay some ground work for those later discussions.

A class in PIR consists of a namespace for that class, an initializer, a constructor, and a series of methods. A "method" is exactly the same as an ordinary subroutine except for three differences:

 * 1) It has the  flag
 * 2) It is called using "dot notation":
 * 3) The object that is used to call the method (on the left side of the dot) is stored in the "self" variable in the method.

To create a class, we first need to create a namespace for that class. In the most simple classes, we create the methods. We will talk about initializers and constructors later, but for now we'll stick to a simple class that uses neither of these:

.namespace ["MathConstants"]

.sub 'GetPi' :method $N0 = 3.14159 .return($N0) .end

.sub 'GetE' :method $N0 = 2.71828 .return($N0) .end

With this class (which we probably store in "MathConstants.pir" and include into our main file), we can write the following things:

.local pmc mathconst mathconst = new 'MathConstants' $N0 = mathconst.'GetPi'    #$N0 contains the value 3.14159 $N1 = mathconst.'GetE'     #$N1 contains the value 2.71828

We'll explain more of the messy details later, but this should be enough to get you started.

Control Statements
PIR is a low-level language and so it doesn't support any of the high-level control structures that programmers may be used to. PIR supports two types of control structures: conditional and unconditional branches.

Unconditional Branches are handled by the goto instruction.

Conditional Branches use the goto command also, but accompany it with an if or unless statement. The jump is only taken if the if-condition is true or the unless-condition is false.

HLL Namespace
Each HLL compiler has a namespace that is the same as the name of that HLL. For instance, if we were programming a compiler for Perl, we would create the namespace. If we are not writing a compiler, but instead writing a program in pure PIR, we would be in the default namespace. To create a new HLL compiler, we would use the  directive to create the current default HLL namespace:

.HLL "mylanguage", "mylanguage_group"

Everything that is in the HLL namespace is visible to programs written in that HLL. For example, if we have a PIR function "Foo" that is in the "PHP" namespace, a program written in PHP can call the Foo function as if it were a regular PHP function. This may sound a little bit complicated. Here is a short example:

To simplify, we can write simply  (without the brackets) to return to the current HLL namespace.

Multimethods
Multimethods are groups of subroutines which share the same name. For instance, the subroutine "Add" might have different behavior depending on whether it is passed a Perl 5 Floating point value, a Parrot BigNum PMC, or a Lisp Ratio. Multiple dispatch subroutines are declared like any other subroutine in PIR, except they also have the  flag. When a Multi is invoked, Parrot loads the MultiSub PMC object with the same name, and starts to compare parameters. Whichever subroutine has the best match to the accepted parameter list gets invoked. The "best match" routine is relatively advanced. Parrot uses a Manhattan distance to order subroutines by their closeness to the given list, and then invokes the subroutine at the top of the list.

When sorting, Parrot takes into account roles and multiple inheritance. This makes it incredibly powerful and versatile.

MultiMethods, MultiSubs, and other key words
The vocabulary on this page might start to get a little bit complicated. Here, we will list a few terms which are used to describe things in Parrot.

 * Subroutine: A basic block of code with a name and a parameter list.
 * Method: A basic block of code which belongs to a particular class and can be called on an object of that class. Methods are just subroutines with an extra implicit  parameter.
 * Multi Dispatch:Where multiple subroutines have the same name, and Parrot selects the best one to invoke.
 * Single Dispatch: Where there is only one subroutine with the given name, and Parrot does not need to do any fancy sorting or selecting.
 * MultiSub: a PMC type that stores a collection of subroutines which can be invoked by name and sorted/searched by Parrot.
 * MultiMethod: Same as a MultiSub, except it is called as a method instead of a subroutine.

PIR Macros and Constants
PIR allows a text-replacement macro functionality, similar in concept (but not in implementation) to those used by C's preprocessor. PIR does not have preprocessor directives that support conditional compilation.

Macro Constants
Constant values can be defined with the  keyword. Here is an example:

.macro_const PI 3.14

.sub main :main print .PI     #Prints "3.14" .end

A  can be an integer constant, a floating point constant, a string literal, or a register name. Here's another example:

.macro_const MyReg S0 .macro_const HelloMessage "hello world!"

.sub main :main .MyReg = .HelloMessage print .MyReg .end

This allows you to give names to common constants, strings, or registers.

Macros
Basic text-substitution macros can be created using the  and   keywords to mark the start and end of the macro respectively. Here is a quick example:

.macro SayHello print "Hello!" .endm

.sub main :main .SayHello .SayHello .SayHello .end

This example, as should be obvious, prints out the word "Hello!" three times. We can also give our macros parameters, to be included in the text substitution:

.macro CircleCircumference(r) $N0 = r * 3.1.4 $N0 = $N0 * 2 print $N0 .endm

.sub main :main .CircleCircumference(5) .CircleCircumference(10) .end

Macro Local Variables
What if we want to define a temporary variable inside the macro? Here's an idea:

.macro PrintSomething .local string something something = "This is a message" print something .endm

.sub main :main .PrintSomething .PrintSomething .end

After we do the text substitution, we get this:

.sub main :main .local string something something = "This is a message" print something .local string something something = "This is a message" print something .end

After the substitution, we've declared the variable  twice! Instead of that, we can use the  declaration to create a variable with a unique name that is local to the macro:

.macro PrintSomething .macro_local something something = "This is a message" print something

Now, the same function translates to this after the text substitution:

.sub main :main .local string main_PrintSomething_something_1 main_PrintSomething_something_1 = "This is a message" print main_PrintSomething_something_1 .local string main_PrintSomething_something_2 main_PrintSomething_something_2 = "This is a message" print main_PrintSomething_something_2 .end

Notice how the local variable declarations now are unique? They depend on the name of the parameter, the name of the macro, and other information from the file? This is a reusable approach that doesn't cause any problems.

Resources

 * http://docs.parrot.org/parrot/latest/html/docs/pdds/pdd19_pir.pod.html


text:
Parrot Virtual Machine/Polymorphic Containers (PMCs)

Polymorphic Containers (PMCs)
Polymorphic Containers (PMCs) -- which were previously known as 'Parrot Magic Cookies' -- are one of the fundamental data types of Parrot, and are one of the most powerful and flexible data types available. A PMC is very much like a class object, with data storage and associated class methods. PMCs include all aggregate data types including arrays, associative arrays (Hashes), Exceptions, Structures, and Objects. Parrot comes with a core set of PMCs, but new PMCs can be added for use with specific programs or languages.

PMCs are written in a C-like language that we will call "PMC Script" and compiled. PMCs can be built-in to Parrot directly, or they can be written separately and loaded in later. PMCs which are loaded at runtime are called "dynamic PMCs", or DYNPMCs for short.

Writing PMCs in C
PMC definitions are written in a C-like language that is translated to C code using a special PMC compiler program called. Once converted to C code, the PMCs are included in the Parrot build process.

The PMC Compiler
The PMC Compiler,  has a number of tasks to perform. It converts the PMC into legal C syntax, inserts the function names in the appropriate tables, and exports information about the PMC and its methods to the rest of the Parrot system.

PMC Script
The script language used to write a PMC is based on C. In fact, it's mostly C with a few additional keywords and constructs. The PMC compiler converts PMC files into C code for compilation. All standard ANSI C 89 code is acceptable for use in PMC files. Here we will list some of the additions.

PMC Class Definition
All the methods and vtables of the PMC must be enclosed in a PMC class declaration:

pmclass NAME { }

In addition to just giving the name of the PMC, you can specify single-inheritance too:

pmclass NAME is SUPERNAME { }

Where SUPERNAME is the name of the parent PMC class. In your PMC vtable methods you can use the SUPER keyword to access the vtable methods of the parent class.

You can also allocate an additional storage area called a PMC_EXT using the needs_ext keyword. PMC_EXT is an additional structure that can be allocated to help with special operations, such as sharing between multiple interpreters. If the PMC is not automatically thread safe, you should add a PMC_EXT.

Helper Functions
Like ordinary C, you can define addtional functions to help with your calculations. These functions should be written in ordinary C (without any special keywords or values) and should be defined outside of the C definition.

Defining PMC Attributes
PMCs can be given a custom set of data field attributes using the  keyword. ATTR allows the PMC to be extended to contain custom data structures that are automatically managed by Parrot's memory subsystem. Here's an example:

pmclass Foo { ATTR INTVAL bar; ATTR PMC baz; ... }

The attributes are stored in a custom data structure that can be accessed using a macro with the same name as the PMC, but all upper-case:

Parrot_Foo_attributes * attrs = PARROT_FOO(SELF); attrs->bar = 7;                /* it's an INTVAL */ attrs->baz = pmc_new( ... )    /* It's a PMC */

Notice how the type name of the attributes structure is, followed by the name of the PMC with the same capitalization as is used in the   definition, followed by. The macro to return this structure is  followed by the name of the PMC in all caps.

VTABLEs and Methods
PMCs can supply definitions for any number of VTABLE interfaces. Any interfaces not defined will fall back to a default implementation which throws an error. VTABLE interfaces must all follow a pre-defined format, and attempting to define a VTABLE interface that is not one of the normal interfaces or does not use the same parameter list and return value as the normal interfaces will throw an error.

The parameters for all VTABLE and METHOD declarations may be either INTVAL, FLOATVAL, STRING, or PMC, as these are the only values which can be passed from PIR code. VTABLE Interfaces are defined with the VTABLE keyword, and Methods on the PMC can be defined with the METHOD keyword.

VTABLES
All PMCs have a standard API, an interface that they share in common with all other PMCs. This standard interface is called a VTABLE. A VTABLE is a list of about 150 standard functions, called "VTABLE Interfaces" that implement basic, common, behavior for PMCs. All PMCs implement all these interfaces, although if one is not explicitly provided it can inherit from a parent PMC class, or it can default to throwing an exception.

VTABLE methods can be defined in one of two ways, in the  using the C-like PMC language, or in PIR using the   function qualifier. VTABLEs correspond to some basic operations that can be performed on any object, such as arithmetic, class operations, casting operations (to INTVAL, FLOATVAL, STRING, or PMC), and other common operations. Regardless of how the VTABLE method is defined, they must have very specific names.

Writing VTABLE Interfaces
VTABLE functions all have fixed names and parameter lists. When implementing a new VTABLE method, you must strictly conform to this, or there could be several compilation errors and warnings. For a list of all vtable methods and their expected function signatures, you can check out the header file.

Inside a VTABLE method there are several available keywords that can be used:
 * SELF: the current PMC
 * INTERP: the parrot interpreter
 * SUPER: The parent PMC class.

You can also reference other methods or vtable methods of the current PMC using a standard dot notation such as:

SELF.VTABLE_OR_METHOD_NAME

If you want to default all or part of your processing to the super class (if you have a superclass), you can use the SUPER function to do that. Any vtable method that you do not implement will be automatically defaulted to the super class (if any) or to te default parent class.

Methods
In addition to VTABLEs, a PMC may supply a series of custom interface functions called methods to supply additional functionality. Notice that methods are not integrated into the PIR operators or PASM opcodes in the same way that VTABLE methods are. Methods can be written in the C-like PMC script for individual PMCs, or they can be written in PIR for user-defined PMC subclasses.

Invoking Methods
Once a method has been defined, it can be accessed in a PMC file using the  command.

VTABLE List
A complete list of all vtable methods is located in the appendix.

Resources

 * Built-In PMC Appendix
 * http://www.parrotcode.org/docs/pdd/pdd04_datatypes.html
 * http://www.parrotcode.org/docs/pdd/pdd17_pmc.html
 * http://www.parrotcode.org/docs/pmc2c.html
 * http://www.parrotcode.org/docs/pmc.html


text:
Parrot Virtual Machine/Building Parrot

Obtaining Parrot
The most recent development release of Parrot can be downloaded from CPAN.

Development of Parrot is controlled through the SVN repository at http://svn.parrot.org/parrot/. The most up-to-date version of Parrot can be obtained from https://svn.parrot.org/parrot/trunk/ via.

Building Parrot From Source
Parrot is currently available as a source code download, although some people are trying to maintain precompiled versions for download as well. These versions are typically available for Windows, Cygwin, Debian, and Red Hat. Other binary distributions may be added in the future. Instructions for installing a precompiled binary distribution of Parrot for your system vary depending on the particular platform and the method in which it was bundled. Consult the accompanying documentation for any distribution you download for more details. This page will not discuss these particular distributions, only the method of building Parrot from the original source code.

Currently the Parrot build process requires the use of, a working C compiler, and a working Perl 5 installation. Perl should be version 5.8 or higher. Without these things, it will not be possible for you to build Parrot. Automated testing is performed on a variety of systems with various combinations of these tools, and any particular revision should be able to be compiled properly. If you have problems compiling Parrot on your system, send an email to the Parrot Porters mailing list with details of the problems, and one of the Parrot developers will try to help fix it.

Configure.pl
The first step in building Parrot is to run the  script which will perform some basic tests on your system and produce a makefile. To automatically invoke  with the most common options, run the program   instead. The configuration process performs a number of tests on your system to determine some important parameters. These tests may make several minutes on some systems, so be patient. In addition, configuration creates a number of platform-specific code files for your system. Without these generated files in place, the build process cannot procede.

After  is finished executing, you should have a file named   (with no suffix). From the shell, go to the Parrot directory and type the command " " or " " on Windows. This will start the process to build Parrot. The Parrot build process could take several minutes because there are a number of steps. We will discuss some of these steps in a later section.

MANIFEST
The root directory of Parrot contains a file called MANIFEST. MANIFEST contains a list of all necessary files in the Parrot repository. If you add a new file to the Parrot source tree, make sure to add that file to MANIFEST. Configure.pl checks MANIFEST to ensure all files exist properly before attempting to build.

Configure.pl Options
Depending on what tasks you want to perform, or how you are using Parrot, there are a number of options that can be specified to Configure.pl. These options may change the makeup of several generated files, including the Makefile. Here, we will list some of these options:

Parrot Executable
After the build process you should have, among other things, an executable file for Parrot. This will be, on Windows systems, named. On other systems, it may be named slightly differently, such as with no suffix.

Two other programs of interest are created,  and. These files will be named something different if you are not on a Windows system.

Make Targets
For readers who are not familiar with the  program, it is a program which can be used to automatically determine how to build a software project from source code files. In a makefile, you specify a list of dependencies, and the method for producing one file from others. then determines the order and method to build your project.

has targets, which means a single makefile can have multiple goals. For Parrot, a number of targets have been defined which can help with building, debugging, and testing. Here are a list of some of the make targets:

Submitting Bugs and Patches
As we mentioned above, smoke testing is an easy way for you to help submit information about Parrot on your system. Since Parrot is supposed to support so many different computer architectures and operating systems, it can be difficult to know how Parrot is performing on all of them.

Besides smoke testing, there are a number of ways that you can submit a bug report to Parrot. If you are a capable programmer, you may be interested in trying to make fixes and submit patches as well.

Resources

 * http://www.parrotcode.org/docs/gettingstarted.html

title: Parrot Virtual Machine/Building Parrot


text:
Parrot Virtual Machine/Parrot Compiler Tools

Parrot Compiler Tools
The first section of this book covered some of the basics of the Parrot platform, and the various features that Parrot provides for use with other high level languages. It is important to notice that Parrot provides more features and capabilities than most individual languages require. This is because Parrot aims to be a platform to support multiple high-level dynamic programming languages, each of which have diverse feature sets. Some of the most recent versions of these programming languages, such as Perl 6 and Python 3000 have very interesting feature sets planned that cannot be supported well by any other existing interpreter or virtual machine platform.

PIR and Parrot programming so far has been relatively low-level, but the goal of Parrot is to support high-level languages. To facilitate this goal, Parrot provides tools that compiler-designers can use to quickly and easily create the advanced language features that next-generation languages like Python 3000 and Perl 6 need. These are, collectively, known as the Parrot Compiler Tools (PCT). The PCT are a set of tools that people can use to quickly and easily implement new programming languages on the Parrot platform. We will talk about them in this chapter and some of the following chapters too.

Parsing and Compiling: How Parrot Works
Parrot is designed to be a highly modular system. This means that many components can be interchanged as needed. Some of these changes need to be specified at compile time, but others can be performed at runtime.

Inputting a program to Parrot goes through multiple steps. Here is a brief overview of these:
 * Parser and Lexer: The first stage to Parrot is the Parser and Lexer (Lexer is short for "Lexical Analyzer"). We will discuss the operations of these components in more detail later in this chapter, and in future chapters. The parser and lexer read input code in PIR or PASM and convert it into a data representation called an abstract syntax tree (AST). An AST is a way to represent program instructions in a way that is very easy for a computer to work with.
 * Compiler: The compiler unit converts information in the AST into Parrot Bytecode format. Bytecode is a set of instructions in binary machine language. From here, Parrot can execute the bytecode directly, or it can save the bytecode to disk and execute it later.
 * Optimizer: The optimizer takes the generated bytecode and attempts to make it smaller, faster, and more efficient. Bytecode that has been properly optimized will typically execute faster then non-optimized bytecode.
 * JIT Compiler: Short for "Just In Time", the JIT compiler attempts to convert Parrot bytecode into native machine code. This will typically bring large speed increases, but is highly platform-dependent and does not yet work on any systems.
 * Interpreter: Once a program has been converted into bytecode, that bytecode is loaded into the interpreter where it is executed.

This is just a very brief overview of these components, we will discuss them in more detail in later chapters. It is worth nothing here, however, that many of these components are modular and can be swapped out if you would like to use a different one. For instance, if you already have a parser written for a particular language, instead of having to rewrite the parser using PCT, you can load your existing parser into Parrot. Of course, you will probably need to make modifications to ensure that your custom parser outputs a proper AST, but that's a small price to pay to avoid having to completely rewrite your language parser from the ground up.

PCT Design Process
PCT includes a number of tools and design steps necessary to create a compiler for a new programming language. Here is a brief look at some of the steps required to create a new compiler:

 * 1) Create a language shell
 * 2) Create a Grammar file
 * 3) Create a grammar actions file
 * 4) Create necessary classes, built-in functions, and PMCs
 * 5) Create the driver program

Once you have your compiler, you can use it to run programs written in your high-level language. Here are some steps involved in running your compiler:

 * 1) Compile your grammar into a Parrot Abstract Syntax Tree (PAST)
 * 2) Compile the PAST into a Parrot Optimized Syntax Tree (POST)
 * 3) Compile the POST into Parrot Bytecode (PBC) or PIR
 * 4) Run the PBC or PIR on Parrot

This should give you a rough idea of what needs to be done to create a compiler, and how a compiler operates. We'll elaborate on each of these steps in this chapter and the next few chapters in this section.

Creating a Language Shell
A new language shell has a number of components. There are the grammar and action files that we've mentioned, but you also need a driver program to create the HLLCompiler object and start the compilation. Also, if you want to have any built-in functions or classes, you will need to write them. To simplify the whole process, you will want to have a makefile to handle all the build steps for writing your language.

Luckily, there is a tool available to simplify this process,. is a Perl 5 program that creates all the necessary files for creating a new language compiler, and fills those files with some helpful default code. It is located, from the Parrot root folder in the  folder. To run this program from your shell, go to the Parrot root folder and type:

tools/dev/mk_language_shell.pl

Here,  is the name of your new language, and   is the directory where you want it to be stored. By convention, all language projects are stored in the  directory. Using this directory makes it more easy for other build tools to find it.

For example, if we wanted to create a new language called "mylanguage", we could write

tools/dev/mk_language_shell.pl mylanguage languages/mylanguage

This will create all the necessary files, including a makefile for your language project. Notice that many of these default files, including the makefile, will need to be edited or modified as time goes on. You may want to, as practice, open the makefile and see how things are being built. If you've never seen a makefile before, this is your opportunity to learn about what they are and how they work.

Grammars and Actions
Grammars, typically files with a ".pg" file extension, are compiled using the Parrot Grammar Engine (PGE). PGE is an implementation of the Perl 6 rules engine for Parrot. PGE uses a Recursive Descent parser, although certain components such as expressions can be parsed using a bottom-up parser for efficiency. If you have read the book on Compiler Construction this should make some sense to you. If not, the details about the parser are not particularly important at this point.

Unfortunately, there is a little bit of terminology that we need to cover before we can go any further into this. People who are familiar with grammars and parsers can skip this section. Everybody else should try to read through it because it's valuable and pertinent information.

A tool called a lexical analyzer reads the input file and converts chunks of text into things called "tokens". Tokens are then arranged into particular patterns called "rules" by the parser. When a rule is successfully applied to a set of input tokens, the rule is said to "match" the input. Think of a token as a word in a sentence. Alone, a single word might not have much meaning. But if you put multiple words together into a sentence, the intended meaning becomes clear. A parser takes a group of tokens together and tries to form them into a "sentence", or a known pattern. If a valid pattern of tokens is found, the parser succeeds.

At each step of the parsing process, the parser receives a token from the lexical analyzer. If the parser has enough tokens to make a valid pattern, it succeeds. If it doesn't have enough information to form a valid pattern, it requests the next token and tries again. Large patterns are divided up into smaller patterns. Tokens are combined together into small patterns, and small patterns are combined together into larger tokens. Eventually, the whole code file is reduced to a single pattern and the parser exits.

At each step the parser may optionally perform an action using information in the token. The parser will associate particular actions with different token types. The action performed on an open-parenthesis token is not going to be the same as the action performed on a close-parenthesis token. In the case of PGE, actions are functions, typically written in PIR or NQP, that create a PAST node. PAST nodes are stored into a large tree that represents the input. This is called the parse tree. When the parser reaches its final match and succeeds, the parse tree is passed to the next stages of the toolkit for processing and eventual conversion into Parrot bytecode.

Implementing a new language on Parrot, as we mentioned earlier, is broken into a number of parts:

 * Write a grammar file using Perl 6 Grammar rules
 * Write a grammar actions file using NQP
 * Write a driver program in PIR
 * Write built-in functions, classes, and PMCs, using PIR (or C, for the PMCs)

Once you create your language shell, all of these files will be produced for you. All you need to do is fill in your grammar and actions into the necessary files, write the rest of the necessary built-in code, and you should have a working compiler. Once you have modified these files to do what you need them to, there is an additional optional step that you should take:

 * Write a series of test modules to verify that your language operates properly.

We will discuss testing and test harnesses later. We will discuss writing parsers and action files in the next few chapters.

The Driver Program
The driver program, which is the main entry point to your compiler has a number of tasks to perform. The first and most important job for your driver program is to create a compiler object for the high-level language in question, and pass the command-line arguments to that compiler object. The compiler object is an HLLCompiler object, and the HLLCompiler class contains all the necessary methods for parsing command-line arguments and initializing the compiler. For more information about the HLLCompiler class, see the Appendix.

A driver program has a number of tasks. Here they are, in no particular order:
 * 1) Specify a  function, which starts the program
 * 2) Create an HLLCompiler object for the given High-Level Language(HLL)
 * 3) Specify any additional details to the HLLCompiler object, to change the operation of the compiler prior to the parsing stage.
 * 4) Include the necessary libraries of classes and built-in functions that the language needs to operate. For most language, this will include at least one library loading routine capable of loading additional libraries into Parrot for use with the HLL and programs written in it.
 * 5) Declare any global variables that will be used with the parser, or will be used by HLL programs.

In addition to these, there may be other tasks which the language designer might wish to perform inside the main driver program.

Getting Help
When you are writing your new language compiler, there are a number of places that you can go to get help. The Parrot repository contains all the current Parrot documentation, in POD format. Perl 5 programmers will be familiar with POD, but other users might not be. POD is a simple documentation format that is treated like multi-line comments in Perl code. Special programs like pod2html can be used to convert POD files into other file types for presentation, such as HTML.

There are many languages in the  directory. If you are trying to implement a particular feature for your language, chances are good that you can find an existing example of how another language has implemented that feature. One excellent tool to use, especially when you are constructing PAST node trees, or writing functions in PIR is the  directive to Parrot. This directive lets you specify an output dump format. For instance, if you go to the  directory, you can type the following

../../parrot perl6.pbc --target=pir

This command will output the PIR of any Perl 6 instructions that you type in. These options work for Parrot, so all the languages will use them, not just Perl 6. Here are some of the other targets you may want to try:

 * pir: prints out the result PIR from the code
 * pasm: Prints out the result PASM code
 * past: Prints out the past node tree that is generated from the code
 * parse: prints out a parse tree of the code

Try all these, and see what kinds of results you get using different languages.

If you have looked for help in the POD documentation and in the existing code examples, it might be time to find a real human to ask. Parrot developers and enthusiasts congregate in the #parrot (irc.perl.org) chatroom. Perl 6 developers and enthusiasts congregate in the #perl6 (freenode) chatroom.

Other resources and methods of contact are available at http://www.parrotcode.org/resources.html

Resources

 * http://www.parrotcode.org/docs/compiler_faq.html


text:
Wikijunior:Famous Inventors/Inventors in Transportation

Inventors in Transportation

 * /Thomas Telford/
 * /George Stephenson/
 * /James Starley/
 * /Werner von Siemens/
 * /Frank J. Sprague/
 * /Henry Ford/
 * /Wilber and Orville Wright/
 * /Robert H. Goddard/
 * /Clive Sinclair/


text:
Wikijunior:Famous Inventors/Inventors in Agriculture

Inventors in Agriculture

 * /George Washington Carver/
 * /Cyrus McCormick/


text: User talk:64.8.83.13

title: User talk:64.8.83.13


text: User talk:64.8.83.9

title: User talk:64.8.83.9


text:
Wikijunior:Famous Inventors/Inventors in Everyday Uses

Inventors in Everyday Uses

 * 1) /Thomas Edison/
 * 2) /Nikola Tesla/
 * 3) /Benjamin Franklin/
 * 4) /Lewis Howard Latimer/
 * 5) /George Westinghouse/


text:
Parrot Virtual Machine/Not Quite Perl

Not Quite Perl
Not Quite Perl (NQP) is an implementation of a subset of the Perl 6 language which was originally intended to help bootstrap the implementation of Perl 6. In other words, the Perl 6 developers are writing the Perl 6 compiler in a subset of the Perl 6 language itself. This bootstrapping was accomplished by first writing a small NQP compiler using PIR. After the NQP compiler was completed, programs could then be written in NQP instead of having to write them entirely in PIR.

NQP is not just a tool reserved for use with Perl 6, however. Other languages are using NQP as a light-weight implementation language. A major benefit to NQP is that it does not rely on any external code libraries which would be subject to change over time. Because of its small footprint, however, NQP tends to lack many features of higher-level programming languages, and learning to program without using some common constructs can be challenging at first.

Variables in NQP
Here we are going to discuss some of the basics of NQP programming. Experienced Perl programmers, even programmers who are familiar with Perl 5 but not necessarily Perl 6, will find most of this to be a simple review.

NQP is not perl5 or perl 6. This point cannot be stressed enough. There are a lot of features from Perl that are missing in NQP. Sometimes, this means you need to do some tasks the hard way. In NQP, we use the  operator, which is called the bind operator. Unlike normal variable assignment, bind does not copy the value from one "container" to another. Instead, it creates a link between the two variables, and they are, from that point forward, aliases of the same container. This is similar to the way copying a pointer in C does not copy the data being pointed to.

Variables in NQP typically have one of three basic types: scalars, arrays, and hashes. Scalars are single values, like an integer, a floating point number, or a string. Arrays are lists of scalars that are accessed with an integer index. A hash is a list of scalars that use a string, called a key, for indexing. All variable names have a sigil in front of them. A sigil is a punctuation symbol like "$", "@", or "%" that tells the type of the variable.

Scalar variables have a "$" sigil. The following are examples of scalar values:

$x := 5; $mystring := "string"; $pi := 3.1415;

Arrays use the "@" sigil. We can use arrays like this:

@myarray[1] := 5; @b[2] := @a[3];

Notice that NQP does not have a list context like Perl6 has. This means you can't do a list-assignment, like:

@b := (1, 2, 3); # WRONG! $b := (1, 2, 3); # CORRECT

NQP is designed to be bare-bones, as little as is needed to support development of Perl6. The above line could be written also:

@b[0] := 1; @b[1] := 2; @b[2] := 3;

We'll discuss this in more detail a little bit further down the page. Hashes are prefixed with the "%" sigil:

%myhash{'mykey'} := 7 %mathconstants{'pi'} := 3.1415; %mathconstants{'2pi'} := 2 * %mathconstants{'pi'};

Hashes, for people who aren't familiar with Perl, are also known as Dictionaries (in Python) or associative arrays. Basically, they are like arrays but with string indices instead of integer indices.

Where's My List Context?
As we mentioned before, there is no such thing in NQP as "array context", which Perl 5 programmer might have expected. One of the big features of the Perl language is that it's context-aware, and it treats things differently depending on whether you are in scalar or array context. Without this, it really isn't perl. That's why they call it NQP, because it's perl-ish, but isn't quite perl. In NQP you cannot write either of the following:

Lexical And Global Variables
All variables (hashes, scalars, and arrays) can be declared to be lexical with the keyword "my", or global with the keyword "our". For those readers who have read the sections on PIR, "my" variables correspond to the  directive, and the instructions , and. "our" variables correspond to the  and   instructions. Here's an example:

Likewise, for "our":

NQP Control Constructs
NQP has all the high-level control constructs that are missing in PIR. We have loops and If/Then/Else branches in a way that PIR does not have. Because this is a Perl-like language, the loops that NQP does have are varied and relatively high-level.

Branching Constructs
In terms of branches, we have:

if ($key eq 'foo') { THEN DO SOME FOO STUFF } elsif ($key eq 'bar') { THEN DO THE BAR-RELATED STUFF } else { OTHERWISE DO THIS }
 * If/Then/Else:

 * Unless/Then/Else:

Looping Constructs

 * For:A "For" loop iterates over a list and sets   to the current index, as in perl5. There's no c-style loop with STARTING_POINT and STEP_ACTION in NQP, although there is a similar construct in both Perl 5 and Perl 6. Here is a basic for loop:

for (1,2,3) { Do something with $_ }

 * Translated exactly into this PIR code:

.sub 'for_statement' .param pmc match .local pmc block, past $P0 = match['EXPR'] $P0 = $P0.'item' $P1 = match['block'] block = $P1.'item' block.'blocktype'('sub') .local pmc params, topic_var params = block[0] $P3 = get_hll_global ['PAST'], 'Var' topic_var = $P3.'new'('name'=>'$_', 'scope'=>'parameter') params.'push'(topic_var) block.'symbol'('$_', 'scope'=>'lexical') $P2 = get_hll_global ['PAST'], 'Op' $S1 = match['sym'] past = $P2.'new'($P0, block, 'pasttype'=>$S1, 'node'=>match) match.'result_object'(past) .end

You can also iterate over the keys of a hash like so:

for (keys %your_hash) { DO SOMETHING WITH %your_hash{$_} }

where   creates a list of all of the keys in  , and iterates through this list setting   to hold the current key.

 * While: "While" loops are similar to for loops. In NQP, a while loop looks like this:

while(EXIT_CONDITION) { LOOP_CONTENTS }

 * Which roughly becomes in PIR:

loop_top: if(!EXIT_CONDITION) goto loop_end LOOP_CONTENTS goto loop_top loop_end:

 * Do/While:A "do/while" loop is similar to a while loop except that the condition is tested at the end of the loop and not at the beginning. This means that the loop is always executed at least once, and possibly more times if the condition is not satisfied. In NQP:

do { LOOP_CONTENTS } while(EXIT_CONDITION);

 * In PIR:

loop_top: LOOP_CONTENTS if(!EXIT_CONDITION) goto loop_end goto loop_top loop_end:

Operators
NQP supports a small set of operators for manipulating variables.

The Match Object, Defaults, and Hashes
When a grammar rule matches and the  rule is performed, a special type of hash object called the match object is generated and passed to the associated NQP method. This match object is given the special name. You can name it something different if you like, but you would lose a lot of the power that makes the  variable so special.

Ordinarily when you reference an object in a hash, you would use  curly brackets. For example:

my %hash; %hash{'key'} = "value";

When you want to call a value from a hash reference, you would have to do something even more complex:

$hashref->{'key'} = "value";

However, with the special default match object, you can use  angle brackets instead. So, instead of writing

$/->{'key'}

We can write the less-verbose:

$

The keys of the hash object correspond to the names of the subrules used in the grammar. So, if we had the grammar rule:

rule my_rule { }

Our match object would have the fields:

$ $  $  $

If we have multiples of any one field, such as:

rule my_rule { }

Now,  and   are both two-item arrays. Also, we can extend this behavior to repetition operators in the grammar:

rule my_rule { + * }

Now, both  and   are arrays whose length indicate how many items were matched by each. You can use the + operator or the  function to get the number of items matched.

PIR Actions
NQP isn't the only way for writing action methods to accompany a grammar. It's an attractive tool for a number of reasons, but it isn't the only option. Action methods can also be written in PIR or PASM. This is how the NQP compiler itself is implemented. Here is an example of how a PIR action might look:

.sub 'block' :method .param pmc match .param string key .local pmc past $P0 = get_hll_global ['PAST'], 'Stmts' past = $P0.'new'('node' => match) ...   match.'result_object'(past)  # make $past; .end

title: Parrot Virtual Machine/Not Quite Perl


text:
User talk:204.185.110.227

Join Us!
-- – Mike.lifeguard  | talk 15:25, 26 March 2008 (UTC)

title: User talk:204.185.110.227


text: User talk:70.137.128.44

title: User talk:70.137.128.44


text: Muggles' Guide to Harry Potter/Magic/Nogtail


text: Muggles' Guide to Harry Potter/Magic/Nudu


text:
Muggles' Guide to Harry Potter/Magic/Occamy

Overview
A beautiful, carnivorous creature native to India and the Far East, resembling a winged snake, but plumed, having two legs, and reaching up to fifteen feet in length. As occamy eggshells are formed from pure soft silver, the occamy's reputation for aggression may be overstated, as most of its interaction with humans probably has consisted of defense of its eggs


text: Muggles' Guide to Harry Potter/Magic/Pogrebin


text:
Muggles' Guide to Harry Potter/Magic/Porlock

Overview
Porlocks are magical beasts that guard horses. They are mistrustful of humans.


text:
User:S1

-> w:de:Benutzer:S1

title: User:S1


text:
User talk:S1

-> w:de:Benutzer Diskussion:S1

title: User talk:S1


text:
User talk:Vsj 67gr

Welcome to Wikibooks, Vsj 67gr! – Mike.lifeguard  | talk 11:41, 8 April 2008 (UTC)

title: User talk:Vsj 67gr


text:
User:Vsj 67gr

The theme of the practical lesson is: Walking along the resistive film The first thing we did on this practical lesson was to reproduce Ohm's experiment, because Ohm's law is the base of the electronics we study. The idea of our practical and theoretical lessons in our course of electronics is to invent everything, every single element (even the resistor). So we started imagining how Ohm did his famous experiment and found the fundamental relationship between the current, voltage and resistance. He did his experiment in the beginning of the 19th century. This means only thing he could use as a power supply was the forerunner of the electrical battery, created by Alessandro Volta. Unfortunately this experiment failed, because Ohm used a wire with very low resistance so the power source was loaded. For reproducing Ohm's experiment we used a resistive wire. In the lab we used a power supply (maximum current 2.5A, maximum voltage 10V), voltmeter and ammeter. So we started the experiments.

Experiment N1:  The scheme we were examining is shown on fig.4 in the main module. We move the voltmeter in this way: one of its ends is connected with the ground and the other is walking on the resistive film by a crocodile clip as a slider. Apparently the measured voltage is 10V no matter where the crocodile clip is along the resistive film.

Experiment N2: The scheme we were examining is shown on fig.5 in the main module. Now we have a change in the measurement of the voltmeter. We can see change is linear.

So now is appropriate to make the hydraulic analog: the tapped pipe and the opened pipe. The illustrations are shown at the main module.

We slide the crocodile clip along the resistive film. This is equal to using a potentiometer. The potentiometer is practically a movement-to-voltage converter. According to the fact that the resistance is distributed linearly along the wire, we can conclude that this converter is linear. So there was a new idea: why don't we stop moving the crocodile slider, leaving it in a certain point on the resistive wire and start changing the input voltage?

Experiment N3: We have 2 voltage sources. One of them (the left one) varies and the other is constant. We see the results on the screen of the computer. You can see the illustration attached it the subtopic in the main module: V1 varies: a left-controlled voltage-to-voltage converter.

$$\ Vout = \frac{r2}{r1+r2}.Vin1 $$

Experiment N4: Now the right one varies and the left one is constant. We see the results on the screen of the computer. You can see the illustration attached it the subtopic in the main module: V2 varies: a right-controlled voltage-to-voltage converter.

$$\ Vout = \frac{r1}{r1+r2}.Vin2 $$

Experiment N5: Now both of the voltage sources vary. We see the results on the screen of the computer. You can see the illustration attached in the subtopic in the main module: Both V1 and V2 vary: a resistive summer.

$$\ Vout = \ \frac{r2}{r1+r2}.Vin1\ + \frac{r1}{r1+r2}.Vin2 $$

As we can see this is a summer with coefficients:

$$\ a = \frac{r2}{r1+r2} $$

$$\ b = \frac{r1}{r1+r2} $$ Since now we have seen the results only when the input voltages are positive. Now we change the polarity.

'''We can see that there is one point we can see on the screen on the computer with zero-potential. This is the famous virtual ground. This point moves on the horizontal axis. So there was a new question – can we make this moving point a fixed one? The answer is yes. There is one element that controls its output in according with the input voltage. This is the operational amplifier. This element keeps the virtual ground at point A. See the illustration: a passive resistive subtractor and of course the negative feedback game.'''

emitter follower

We are getting started with an explanation of the negative feedback. The first thing we ask each other is if there is such phenomenon in the real life. The first example we think of is the human speech. You have to listen to your voice in order to control it. So we have a current state X and we want to achieve other state Y.

Another example is when you get in a car and you want to achieve the goal to drive with 50km/h. You are in state X and you want to achieve state Y. But what do you need? The first thing you need is ENERGY. It's necessary but not enough. You have to have a visualization of your speed in order to control it. In other words you need a REGULATOR.

'''But what is the regulator doing? It compares the difference between the purpose state and the current state. When this difference is equal to zero, we have equilibrium.'''

The simplest regulator is the follower. Now we have to think about how we can realize a follower. An obvious follower is a wire. But is it a perfect follower? The answer is “no”. We prove it with the next example. The wire has resistance. When we have a resistor (1ohm), we have a wire (1ohm), and a voltage source (10V) and they are connected like it is shown on the figure.

So we use another (perfect) regulator – the emitter follower. We make the analogue of scheme? And a scheme with the transistor. The transistor is the voltage follower. The main idea is that the transistor observes the potential in point A and changes the potential in point B (by changing its resistance). And because this is a follower the voltage in point B should be equal to the voltage in point A. In fact it is almost equal, because we have the BASE-EMITTER VOLTAGE (which is approximately 0.6V).

Now we will test this scheme with Microlab.

title: User:Vsj 67gr


text:
User:Lafcadio~enwikibooks

I have lived in New Orleans since 1966, and enjoy creole cooking. I take my user name from Lafcadio Hearn, the journalist who moved to New Orleans in the 19th century, where he remained for more than a decade. Of Irish-Greek heritage, he grew up in Ireland before working in Cincinnati, New Orleans, and Martinique. Subsequently he moved to Japan, where he is well known for his books on Japanese folklore; many Japanese come to New Orleans in search of his house and the cafe he owned here. Hearn wrote one of the first Creole cookbooks while he lived here, and the book is still in print.

I plan to enter recipes I have actually used, including family recipes. My family is from Napoleonville, Louisiana, between Baton Rouge and New Orleans.

title: User:Lafcadio~enwikibooks


text:
User:Aholtman1

This account is a (non active) account of User:Aholtman generated for usurpation issues when the single user login was introduced for sysops on wikimedia projects and not needed anymore.

--Aholtman1 (talk) 17:13, 26 March 2008 (UTC)

title: User:Aholtman1


text:
Cookbook:Louisiana Creole cuisine

| U.S. Cuisine | Southern U.S. cuisine

Louisiana Creole cuisine is a style of cooking originating in Louisiana, originating mainly in the Creole area of the state (the Greater New Orleans and river plantation areas) that blends African, French, Spanish, French Caribbean and American influences. While it is similar to Cajun cuisine in that it has adapted to local ingredients, and despite the overlaps, it differs in its cooking style -- Creole tends to use classical French cooking techniques, whereas Cajun tends to use rustic, provincial French cooking techniques.

The term "Creole" is used differently by different populations in New Orleans and other parts of Louisiana. The original meaning of the word, as it was used during the time that Louisiana was a colony first of France and then of Spain, referred specifically to the descendants of colonial settlers. The word "Cajun" refers to people of French heritage who arrived in Louisiana via Canada after the Cajun diaspora from Nova Scotia.

According to the English Wikipedia, Louisiana Creole cuisine is a style of cooking originating in Louisiana (centered on the Greater New Orleans area) that blends French, Spanish, French Caribbean, African, Italian, and American influences. It is similar to Cajun cuisine in ingredients (such as the "holy trinity" of chopped onions, celery, and green peppers), but Cajun cuisine arose from the more rustic, provincial French cooking adapted by the Acadians to Louisiana ingredients. On the other hand, the cooking of the Louisiana Creoles tended more toward classical European styles adapted to local foodstuffs. Broadly speaking, the French influence in Cajun cuisine is descended from various French Provincial cuisines of the peasantry, while Creole cuisine evolved in the homes of well-to-do aristocrats, or those who imitated their lifestyle. Although the Creole cuisine is closely identified with New Orleans culture today, much of it evolved in country plantation estates before the American Civil War.

The Spanish influences on Creole cuisine were in the supreme importance of rice and the introduction of beans and tomatoes. Pasta and tomato sauces arrived during the period when New Orleans was a popular destination for Italian immigrants (roughly, 1815 to 1925). Many Italians became grocers, bakers, cheese makers and orchard farmers, and so influenced the Creole cuisine in New Orleans and its suburbs. The extensive African influence originated with African-Americans who were cooks in restaurants and cafes and servants in prosperous households.

The first French and Spanish Creole cookbooks date back to the era before the Louisiana Purchase. The first Creole cookbook in English was La Cuisine Creole: A Collection of Culinary Recipes, From Leading Chefs and Noted Creole Housewives, Who Have Made New Orleans Famous For Its Cuisine, written by Lafcadio Hearn and published in 1885. The full text and page images can be found at Feeding America: The Historic American Cookbook Project.

River Road Recipes is a classic Creole reference by the Junior League of Baton Rouge; it has been in print continuously since 1958. In addition, The Plantation Cookbook by the Junior League of New Orleans has been in print since 1972. The Picayune's Creole Cookbook was compiled at the turn of the century to assure a cuisine of Creole heritage for future generations; it was reprinted and re-designed on the occasion of the 150th anniversary of The New Orleans Times-Picayune newspaper in 1987. The New Orleans Cookbook, by Rima and Richard H. Collin, was originally published in 1975 and still in print; it has been part of every New Orleans cook's library since it was first published.

Older restaurants of New Orleans continue to influence Creole cooking; for example, Antoine's, Galatoire's, and Arnaud's.

Starting in the 1980s, Cajun influence became important to Creole cuisine, spurred by the popular restaurant of Chef Paul Prudhomme. A national interest in Cajun cooking developed, and many tourists went to New Orleans expecting to find Cajun food there (being unaware that the city was culturally and geographically separate from Acadiana), so entrepreneurs opened or rebranded restaurants to meet this demand. The "New New Orleans Cooking" of celebrity chef Emeril Lagasse includes both Cajun and Creole dishes. In his writings and TV shows, Lagasse both draws the distinction between Cajun and Creole and explains where they overlap.

With the rise of Modern American Cooking in the 1980s, a New Creole (also known as Nouvelle Creole or Neo-American Creole Fusion) strain began to emerge. This movement is characterized in part by a renewed emphasis on fresh ingredients and lighter preparations, and in part by an outreach to other culinary traditions, including Cajun, Southern, Southwestern, and to a lesser degree Vietnamese. While the Cajun food craze eventually passed, Contemporary Creole has remained as a predominant force in most major New Orleans restaurants.

For a complete, automatically generated, list of recipes which have been categorized, on their individual pages, as being Louisiana recipes (in general, rather than a list of only Louisiana Creole recipes) see Category:Louisiana recipes.

Also, below is a list of a few selected Louisiana Creole recipes contributors have manually added to this page:

Examples

 * Beignet
 * Béchamel_Sauce_Louisiannaise
 * Bread pudding
 * Café au lait
 * Crab_Meat_Canapé
 * Doberge
 * Gumbo
 * Seafood Gumbo
 * Muffuletta
 * Po Boy

title: Cookbook:Louisiana Creole cuisine


text:
User:Aholtman

Note: This account was usurped by Aholtman@dewikinews when the single user login was introduced for sysops on wikimedia projects.

--Angela H. (talk) 17:20, 26 March 2008 (UTC)

title: User:Aholtman


text:
Cookbook:Cajun Cuisine

| North American cuisines | Cuisine of the United States

Cajun cuisine is a style of cooking originating in Louisiana, mainly from the Acadian (Cajun) area of the state (the "Acadian triangle", ranging from western Texas to eastern Mississippi, with the north point being mid-Louisiana). While it is similar to Louisiana Creole cuisine in that it has adapted to local ingredients, and while there are many overlapping dishes, such as gumbo, it differs in its cooking style -- Creole tends to use classical French cooking techniques, whereas Cajun tends to use rustic, provincial French cooking techniques.

Starting in the 1980s, Cajun influence became important, spurred by the popular restaurant of Chef Paul Prudhomme. A national interest in Cajun cooking developed, and many tourists went to New Orleans expecting to find Cajun food there (being unaware that the city was culturally and geographically separate from Acadiana). Entrepreneurs opened or rebranded restaurants to meet this demand. The "New New Orleans Cooking" of celebrity chef Emeril Lagasse includes both Cajun and Creole dishes. In his writings and TV shows, Lagasse both draws the distinction between Cajun and Creole and explains where they overlap.

However, authentic Cajun cuisine is centered around Lafayette, Louisiana. Cochon de lait and Boudin Blanc are examples of Louisiana Cajun Cuisine.

 * Boiled crawfish
 * Boudin
 * Cush-cush
 * Dirty rice
 * Fried frog legs
 * Gumbo
 * Seafood Gumbo
 * Hogs head cheese
 * Jambalaya
 * Mirliton casserole
 * Smothered okra
 * Stuffed mirliton

title: Cookbook:Cajun Cuisine


text:
User:MuradWiki

It is estimated that 14 million Americans have Rosacea and don’t even know it! Many confuse the symptoms with Acne or other conditions or go undiagnosed. Symptoms include: •	Rough, red irritated skin •	Prominent veins on the face •	Breakouts •	Red, dry patches •	Inflamed, sensitive skin •	Skin that feels hot and flushes easily The symptoms of Acne and Rosacea are sometimes so similar that it is hard to tell the difference between them. This can make diagnosis difficult. Both conditions involve inflammation and damage at a cellular level, and can cause uneven skin tone and even blemish-like symptoms. Rosacea can be differentiated from acne by the following factors: •	Pervasive overall redness and stinging (particularly in the cheeks area) •	Food sensitivities that aggravate irritation (such as alcohol or spicy foods) •	Heat and tightness associated with facial redness Skin that suffers from Rosacea-like redness is influenced by outside factors called triggers. These triggers determine when redness occurs and/or how severe the symptoms are. Triggers include sun exposure or extreme weather, genetics and spicy foods. To reduce the severity or occurrences of these triggers, fragile skin requires vital nutrients that will create a healthier environment for the skin, enabling it to strengthen cell function, reduce inflammation and avoid future irritation. What is most important is helping to reduce and control the redness and associated concerns is to provide skin with agents that will help to claim and soothe current symptoms and treat and prevent future occurrences. While the cause of Rosacea is unknown and there is no cure, today help is available that can control the signs and symptoms. Dr. Murad has created a new line to help soothe rosacea-like symptoms called Redness Therapy R (Registered). This line will help calm inflamed skin, strengthen the skins barrier function, cool the skin on contact and restore hydration and suppleness. Each of the products in the line which includes, Soothing Gel Cleanser, Recovery Treatment Gel and Correcting Moisturizer SPF 15, were specifically formulated to address sensitive red, inflamed skin. The Soothing Gel Cleanser will leave the skin feeling soft and hydrated while removing impurities with out drying the skin. Goji Berry Extract provides maximum protection against inflamed skin; moisture-enriched beads soften rough, dry skin and essential fatty acids help lock in vital moisture The Recovery Treatment Gel cools and soothes on contact. This weightless gel formula absorbs quickly to reduce redness immediately. Azeleic acid improves hydration, Goji Berry Extract super hydrates & rejuvenates dry, flaky skin, Zinc Oxide and Peppermint Leaf Extract soothes & helps reduce stinging and sensitivity The Correcting Moisturizer SPF 15 provides superior hydration with full spectrum UVA/UVB sun protection. The Sheer green tint will counteract redness while the Goji Berry Extract reduces inflamed skin and free radical damage. Peppermint Leaf Extract will relieve discomfort and stinging.

title: User:MuradWiki


text: User talk:137.88.146.4

title: User talk:137.88.146.4


text:
User talk:72.10.101.2

--ЗAНИA talk 19:20, 4 April 2008 (UTC)

title: User talk:72.10.101.2


text:
Rosacea/Causes, Symptoms, and Treatments by Dr. Murad

It is estimated that 14 million Americans have Rosacea and don’t even know it! Many confuse the symptoms with Acne or other conditions or go undiagnosed. Symptoms include:

•	Rough, red irritated skin •	Prominent veins on the face •	Breakouts •	Red, dry patches •	Inflamed, sensitive skin •	Skin that feels hot and flushes easily The symptoms of Acne and Rosacea are sometimes so similar that it is hard to tell the difference between them. This can make diagnosis difficult. Both conditions involve inflammation and damage at a cellular level, and can cause uneven skin tone and even blemish-like symptoms. Rosacea can be differentiated from acne by the following factors:

•	Pervasive overall redness and stinging (particularly in the cheeks area) •	Food sensitivities that aggravate irritation (such as alcohol or spicy foods) •	Heat and tightness associated with facial redness Skin that suffers from Rosacea-like redness is influenced by outside factors called triggers. These triggers determine when redness occurs and/or how severe the symptoms are. Triggers include sun exposure or extreme weather, genetics and spicy foods. To reduce the severity or occurrences of these triggers, fragile skin requires vital nutrients that will create a healthier environment for the skin, enabling it to strengthen cell function, reduce inflammation and avoid future irritation. What is most important is helping to reduce and control the redness and associated concerns is to provide skin with agents that will help to claim and soothe current symptoms and treat and prevent future occurrences. While the cause of Rosacea is unknown and there is no cure, today help is available that can control the signs and symptoms. Dr. Murad has created a new line to help soothe rosacea-like symptoms called Redness Therapy R (Registered). This line will help calm inflamed skin, strengthen the skins barrier function, cool the skin on contact and restore hydration and suppleness. Each of the products in the line which includes, Soothing Gel Cleanser, Recovery Treatment Gel and Correcting Moisturizer SPF 15, were specifically formulated to address sensitive red, inflamed skin. The Soothing Gel Cleanser will leave the skin feeling soft and hydrated while removing impurities with out drying the skin. Goji Berry Extract provides maximum protection against inflamed skin; moisture-enriched beads soften rough, dry skin and essential fatty acids help lock in vital moisture The Recovery Treatment Gel cools and soothes on contact. This weightless gel formula absorbs quickly to reduce redness immediately. Azeleic acid improves hydration, Goji Berry Extract super hydrates & rejuvenates dry, flaky skin, Zinc Oxide and Peppermint Leaf Extract soothes & helps reduce stinging and sensitivity The Correcting Moisturizer SPF 15 provides superior hydration with full spectrum UVA/UVB sun protection. The Sheer green tint will counteract redness while the Goji Berry Extract reduces inflamed skin and free radical damage. Peppermint Leaf Extract will relieve discomfort and stinging.


text:
User:Jwwicks

Who I Am
My name is John Wm. Wicks. I'm a computer programmer in the Sacramento, Ca area. You can contact me through SourceForge http://www.sf.net at no_spam!j_wicks@users.sourceforge.net

What I'm Doing
I'm currently going back to college to get a Bachelors Degree in CSIS at Sacramento City College and I hope to transfer to Sacramento State University in 2009.

C Programming
Category:C Programming

The Resume
April 2001 - Present Freelance Consultant - Sacramento Ca. Lead Internet Application Developer Develop dynamic websites utilizing NT, Linux, IIS, Apache, SQL Server, MySQL, ASP, PHP, JavaScript, VBScript, HTML, XML, CSS, Flash and Photoshop.

August 1999 - April 2001 SacWeb, Inc. - Sacramento Ca. Lead Internet Application Developer Develop dynamic websites from concept to release including requirements analysis and deployment procedures. Perform development tasks utilizing IIS 4/5, MTS, SQL Server 6/7/2000, Access 97/2000, ADO/DAO/OLEDB, VBScript, JavaScript, HTML, DHTML, CSS, Interdev, MSVC++ 6.x, VB 6.x, COM and Homesite on NT 4/2000 Servers. Design solutions for content     management, e-commerce, security, auction/award tracking. Write training aids using Word, PowerPoint and Visio. Author User Guides with Word and PaintShop Pro. Create, maintain and report schedule of tasks using Project 2000.

January 1999 - June 1999 Network Associates - Santa Clara, Ca. Release/Installation Developer (Contract) Redesign Network Informant 3.0 installation using InstallShield, SQL Server 6.5, Sybase 10.x and MSVC++ 4.2 to allow easier maintenance. Develop build and release procedures using PERL and OpusMake. Create and administer SourceSafe and StarTeam. Create uninstall/maintenance utility DLL using MSVC++ 6.0. Generate software defect reports using StarTeam and Track32. Setup, administer and maintain setup QA equipment as needed.

July 1998 - January 1999 Agile Software, LLC - San Jose, Ca. Installation Developer (Contract) Create Agile Workplace 4.x setup using InstallShield 5.5 and MSVC++ 5.x. Design web update DLL using MSVC++ 5.x. Migrate InstallShield setup to MFC framework using MSVC++ 5.0 and Exemplar Setup Toolkit. Create DemoShield CD Browser application. Evaluate, debug and correct existing software defects. Create maintenance releases using RTPatch. Install and maintain QA lab software and hardware.

November 1997 - June 1998 Netscape - Mountain View, Ca. Localization Programmer (Contract) Create multi-lingual installations for Windows NT, Solaris, HP-UX, IRIX and AIX operating systems using InstallShield 3. Maintain source code using VCS/RCS and PERL. Write scripts for nightly builds using PERL. Install, configure and test localized Enterprise, Messaging and Directory Server 3.x on multiple platforms. Author documentation for the release and build process using HTML and JavaScript for intranet site. Provide translation vendors with L10N kit including requirements document in HTML. Setup and configure QA test equipment for L10N vendor.

January 1997 - November 1997 Adaptec, Inc. - Milpitas, Ca. Lead Internationalization Programmer (Contract) Modify SCSI/RAID adapter BIOS to support I18N features using MASM 6.11. Create localized UI, help and installations for EZ-SCSI 4.0, ARO 1130, 2940UW, 7800, CD Creator and DirectCD products. Perform QA on localized products to identify and debug defects. Setup and maintain QA lab equipment. Install and administer QA test equipment for L10N vendor. Modify PVCS scripts to build/create multilingual releases.

February 1992 - January 1997 Lucent - Monterey, Ca. Senior Localization/Internationalization Programmer Develop L10N utilities using Borland C++ 3.x/4.5, AWK, PERL and VBA. Document functional specification in Word and author WinHelp training aid using RoboHelp. Internationalize software in C/C++, Delphi and MASM. Author multi-lingual installation programs using InstallShield. Localize websites and database content using HTML, JavaScript and Oracle. Instrumental in developing L10N process for IS0-9000 certification. Create QA test scripts for the L10N process using Visual Test. Setup and administer Bulletin Board System (BBS) using Wildcat 4.0/5.0. Create and maintain HTML and RipScript interface for Internet user access to BBS.

title: User:Jwwicks


text:
User:Canderson7

I'm currently inactive here on Wikibooks, but you can send me an email or contact me on Wikipedia.

title: User:Canderson7


text:
User talk:Jwwicks

Welcome!
Welcome, Jwwicks!

Come introduce yourself at the new users page. If you have any questions, you can ask there or contact me personally.-- – Mike.lifeguard  | talk 18:24, 26 March 2008 (UTC)

Welcome to my talk page!

title: User talk:Jwwicks