text:
Parrot Virtual Machine/Parrot Internals

Parrot Development Process
The Parrot development project is a large and complex project with multiple facets. Here is an overview of some key points about the Parrot build process. Some of the points here have not been discussed before, but we will covert them in this or later chapters:

 * The build environment is configured using the Configure.pl program. This program is written, like many of the build tools for Parrot, in Perl 5. Configure.pl determines options on your system including which compiler you are using, which Make program (if any) you are using, what platform-specific libraries are required, etc.
 * PMCs are written in a C-like script which is compiled into C code using the PMC Compiler. The PMC Compiler will produce C code and associated header files for all PMCs, and will register the PMCs into the Parrot PMC table.
 * Opcodes are written in a C-like script which is compiled into C, just like PMCs are. The syntax of Opcode files is similar in some respects to that used for PMCs, but is different in many ways too. Ops files are converted into C before being compiled into machine code.
 * Native Call Interface (NCI) function signatures must be converted into C functions prior to compilation using the NCI compiler
 * Just-In-Time operations must be converted into C code for compilation into native code.
 * The parsers for PASM and PIR are written in Lex/Bison. These need to be compiled into C files for compilation.
 * The constant string converter converts CONST_STRING declarations into string constants at compile time. This saves a lot of time at execution.
 * The Makefile automates the build process by compiling all the PMCs, Compiling all the C files, building the executables and libraries, etc.

In this chapter we are going to give an overview of some of the components of the Parrot Virtual Machine, later chapters will discuss the various Parrot subsystems including many of the processes that we've described above. The chapters in this section are all going to discuss Parrot hacking and development. If you aren't interesting in helping with Parrot development, you can skip these chapters.

Parrot Repository
Here is the general structure of the Parrot Repository, as far as source code is concerned:

PASM and PIR Parsers
There are two parsers for PIR available. The first is IMCC, which is used currently but is inefficient, and the other is PIRC which is more efficient but not stable yet. The long-term plan is for PIRC to become the predominant PIR parser by the time the 1.0 version of Parrot is released.

Both IMCC and PIRC are written in the C programming language with parsers written in Lex and Yacc.

PIRC and IMCC act as front-ends to two other Parrot components: the bytecode compiler and the interpreter.

Bytecode Compiler and Optimizer
The bytecode compiler is the portion of Parrot which is responsible for converting input symbols (in the form of PASM or PIR) into Parrot bytecode. This bytecode, once compiled, can be run on Parrot quickly and efficiently.

Another related Parrot component is the bytecode optimizer which is responsible for low-level optimizations of Parrot bytecode.

Interpreter
While the bytecode compiler takes input symbols from PIRC or IMCC and converts them into a bytecode for storage and later execution, the interpreter uses these symbols to execute the program directly. This means that there is no intermediate step of compilation, and a script can be execute quickly without having to be compiled.

I/O Subsystem
The I/O subsystem controls reading and writing operations to the console, to files, and to the operating system. Much of this functionality is being performed in special PMCs.

Regular Expression Engine
The regular expression engine is used to provide fast regular expressions for Parrot programs. The functionality of this engine is most obviously expressed in PGE, but is also available in other places as well. Perl 6 regular expressions, on which this engine is based, differ significantly from Perl 5 regular expressions and their variants.

Garbage Collector and Memory Management
The memory management subsystem is designed to allocate and organize memory for use with Parrot and programs which run on top of Parrot. The garbage collector detects when allocated memory is no longer being used and returns that memory to the pool for later allocation.

Embedding API
Parrot is not just an executable program, it's also a linkable library called libparrot. libparrot can be linked to other programs, and a Parrot interpreter object can be called from inside that program. An entire embedding API has been created to allow libparrot to communicate with other programs.

Extensions API
Parrot can be extended by using dynamic libraries, such as linux  files, or Windows   files. These extensions must interact with Parrot in a safe and controlled way. For this, the Extensions API was written to given extensions a communications channel into the heart of Parrot.

Parrot Hacking
The next several chapters are going to look at the individual components of Parrot. We will discuss the software architectures and operations of each component. As we have already seen, Parrot itself is written using the C programming language, although individual components (such as the opcodes, PMCs, and other features) are written in special domain-specific languages and later translated into C code. Some higher-level functionality, such as PCT is written in PASM and PIR too. Parsers for PIR are written using a combination of Lex and Yacc.

Programming for Parrot is typically going to require a good knowledge of the C programming language, but also a good understanding of Perl 5. this is because Perl 5 is used to write all the development tools which control the build process for Parrot.

Resources

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

title: Parrot Virtual Machine/Parrot Internals


text:
Parrot Virtual Machine/Parrot Embedding

Embedding Parrot
Because the Parrot Virtual Machine is modular, we can link the libparrot library into other executables, creating programs which contain a Parrot interpreter object. One simple use for such a technology would be to create an executable file which contains data in the form of precompiled bytecode and a simple instantiation of the Parrot interpreter to create a standalone executable for a particular programming language. This is called Native Execution, and we will discuss it in more detail below.

Resources

 * http://www.parrotcode.org/docs/pdd/pdd10_embedding.html
 * http://www.parrotcode.org/docs/native_exec.html

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

title: Parrot Virtual Machine/Parrot Embedding


text:
Parrot Virtual Machine/Command Line Options

Resources

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


text:
User talk:198.163.212.16

April 2011
We welcome and appreciate your contributions, but your recent edits to Wikijunior:Bugs/Walking Stick had to be undone. Please see What is Wikibooks? to learn more about what contributions are beneficial to Wikibooks. Please be aware that some edits can be considered vandalism, use the sandbox for any test edits you would like to make, and read the welcome page to learn more about contributing constructively to this project. Thank you. QU TalkQu 15:02, 14 April 2011 (UTC)

title: User talk:198.163.212.16


text: Category:Book:MIRC Scripting

title: Category:Book:MIRC Scripting


text:
User talk:198.203.136.200

Welcome!
Welcome to Wikibooks, a collection of open-content textbooks! You don't have to log in to read or edit articles on Wikibooks, but creating an account is quick, free and non-intrusive, requires no personal information, and gives you many benefits, including:
 * The use of a username of your choice
 * The ability to view all your contributions via a "My contributions" link
 * Your own user page
 * Your own talk page which, if you choose, also allows users to send you messages without knowing your e-mail address
 * The use of your own personal watchlist to which you can add articles that interest you
 * The ability to rename pages.
 * The ability to upload images
 * The ability to customize the appearance and behavior of the website
 * The eligibility to become an administrator
 * The right to be heard in votes and elections
 * Your IP address will no longer be visible to other users.

We hope that you choose to become a Wikibookian and create an account. Feel free to ask me any questions you may have on my talk page. By the way, make sure to sign your posts and comments with four tildes (~~~~), which will let others know who left it.

Νεοπτόλεμος ( talk | email | contribs ) 20:19, 26 March 2008 (UTC)

title: User talk:198.203.136.200


text: User talk:86.150.73.137

title: User talk:86.150.73.137


text:
User:Dark Sunshine~enwikibooks

Hi and welcome to my page

What i do?
I have made a novel called Fallout feel free to continue it

title: User:Dark Sunshine~enwikibooks


text:
Clock and Data Recovery/Structures and types of CDRs/Examples

Examples
To fix the concepts introduced in the previous section, and to better understand them, let’s see a few examples of linear models. Amongst them, just three will be further developed in the remainder of the book, because they represent the three really useful structure models of CDRs. They are:
 * The phase aligner (based on a 1st order loop)
 * The regenerator CDR (based on a 2nd order type 1 loop)
 * The monolithic CDR (based on a 2nd order type 2 loop)

The other examples are useful just as theory exercises and not so much as models of how practical CDRs should be made. Notes:
 * 1) A CDR shall be called "a slave CDR" if its recovered clock is also used to output the recovered data.
 * 2) A slave CDR may simply deliver the recovered data to a buffer memory (end point CDR) or may extend the clock domain -mastered by the remote transmit clock- by sending forward the recovered data using the recovered clock (regenerator CDR).
 * 3) In some cases the characteristic of certain individual blocks in the block diagram (like the gain of the phase comparator, or the oscillator gain, or other characteristics) are not explicitly considered. More abstract quantities, like the natural frequency $$\omega$$n, or the damping ratio $$\zeta$$, are used instead for the formulas and for the time or frequency diagrams. This is done for two reasons:
 * the characteristics of the blocks that operate at the (high) frequency of the data stream (phase comparator and local oscillator ) are frequently imposed by technology choices and are not for the designers to play with;
 * the general behavior of the CDR is more generally represented and more easily understood.

1st order, type 0
and 0th order, type 0 as a special case.

(For definitions of order and type, see: Order and type of a CDR )

This list could have started with the simplest example possible, where the output of the phase comparator drives directly the ( phase of the) local oscillator, without any low pass filter in between.

That would have been a loop of 0th order (with just constants in its closed-loop transfer function and no dependence on the complex variable s) and of type 0 (because there are -of course as it is of 0th order- no poles in the origin, i.e. no factors 1/s in its open-loop transfer function).

As there is always some sort of filtering of the output of the phase comparator, the 0th order type 0 loop can be seen as a limit case of the 1st order, type 0 loop described here below. The model of the 0th order type 0 loop can be useful when a high loop gain makes the (closed loop cut-off) frequency (of the of 1st order, type 0 loop) so high to be negligible. In such case it is enough to put τ = 0 in following equations to obtain its model.

The only practical block diagram that corresponds to a PLL of 1st order and of type 0 shows (see figure below) a local oscillator controlled in phase by the low pass version of the phase comparator output. The simplest example of CDR architecture. The PLL in this CDR is of unity feedback, of the first order and of type 0. The relation of the output to the input (= the closed loop transfer function), is: $$\tfrac{Y(s)}{X(s)}=\tfrac{G}{\left ( 1 + G + s\tau \right ) }$$ where G, the "open loop gain", is Gφ Gf GVCO. The unit step response can be obtained from the (jitter) transfer function multiplying the closed loop trasfer function by 1/s, and reverse transforming the result: $$ \tfrac{G}{G+1}(1 - e^{-\omega_n t}) $$  where ωn = (G + 1)/τ Some points can be remarked:
 * that there remains a steady state error, which is minimised if G is >> 1. In fact a type 0 loop like this one needs a small phase error Φx(j0)/G to track a phase difference Φx(j0) between input and the phase of the free running oscillator. In other words, if the local oscillator is synchronous with the received signal (i.e. both are within a single clock domain), this circuit provides a strong reduction of the phase difference between the two, that is reduced from Φx(j0) to  Φx(j0)/G.
 * that the cut-off frequency of the loop, ωn, is 1+G times higher than the cut-off frequency of the filter block ωf = 1/τf [rad/sec]; as G is large to render negligible the steady state phase error, this loop reacts very fast to any input phase change.
 * that the loop tracks the jitter frequencies below ωn = $$\tfrac{\left( 1 + G \right)}{\tau_f}$$, and is unable to follow higher jitter frequencies (in all examples of PLLs there exists a natural frequency ωn that depends closely on the open loop gain, and the jitter frequencies below ωn are tracked, while those above ωn elude the tracking ability of the loop); in this case of a type 0 loop, ωn is pushed very high if the gain G is high, to the point that this loop cannot be used in CDRs.

A circuit of this architecture may find application, but never inside a CDR. It can be used to implement a DLL, (although DLLs can also be made with a 1st order, type 1 architecture). As long as the residual phase error is kept small enough by a large loop gain, it can fit a DLL application. The unconditional stability and the fast response are useful, while the lack of input jitter filtering at high frequencies (mandatory for CDRs) is not important when the reference clock is sufficiently immune from high frequency noise.

1st order, type 1
This fundamental architecture is often used and also is, because it contains all the fundamental features of the PLLs used in practice, useful to fix concepts and to better understand the more sophisticated architectures of higher order.

It may present itself under different guises (three examples are given in the figure below), but the mathematical model remains the same.

It is maybe easier to derive the model equations from the first example in the following figure (the "slave"), although the third example (the "phase aligner") is the one most frequently found in actuality. [[File:1st order type 1 loop.png|thumb|center|700px| 3 block diagrams of PLLs of 1st order and type 1.

The first is the simplest to understand and the derivation of the model equations is easiest from it.

The third (the phase aligner) is of fundamental importance for the communication engineer. ]]

Oscillator controlled in frequency ("first order slave CDR")
The relation of the output to the input (= the closed loop transfer function), is: $$\tfrac{Y(s)}{X(s)}=\tfrac{1}{\left ( 1 + s/G \right ) }$$ where G, the "open loop gain", is defined as Gφ Gf GVCO.

The unit step response can be obtained from the (jitter) transfer function multiplying the closed loop trasfer function by 1/s, and reverse transforming the result: $$ (1 - e^{-\omega_n t}) $$  where ωn = G and τ = 1/ωn

The model is described in detail in a page dedicated to the 1st order, type 1 architectures later on in this book, owing to the practical importance of its phase-aligner variant.

To be able and contrast this architecture with the others in this page of examples, the magnitude of the jitter transfer function, the response to a unit (= 1 radian) step variation of the input signal phase and the magnitude of the jitter tolerance function ( The jitter tolerance function ) are shown in the figure below.

The relevant equations are:
 * Magnitude of the transfer function: $$\left |\tfrac{Y(s)}{X(s)}\right | = \left |\tfrac{1}{(1 + j\omega/G)}\right | = \tfrac{1}{\sqrt{1+(\omega/G)^2}} $$
 * Unit step response: $$ {\color{Black}1 - e^{-\omega_n t}} $$
 * Magnitude of the jitter tolerance: $$\left |X(j\omega)\right |_{\left |\Epsilon(j\omega)\right | = \Phi_{leo} }$$ = $$\Phi_{leo} \sqrt{\tfrac{( 1 + \omega^2/\omega_n^2)}{\left ( \omega^2/\omega_n^2\right )}}$$,  ( where Φleo is the lateral eye opening expressed in radian) .

This architecture clearly shows:
 * a medium (20 dB/decade) jitter filtering towards high frequencies;
 * a medium jitter tolerance, with the 20 dB/decade asymptote towards zero frequency. It comes from the pole 1/s present in the forward path of the control loop. This is a minimum characteristic when the CDR must operate as a slave and track frequencies that can wander around their nominal value;
 * only one degree of liberty for the designer (that is G in the figures above, i.e. the open loop d.c. gain).

All these characteristics together make this architecture not preferred in actual designs of slave CDRs. For these, the second order, type 1 or type 2, architectures are chosen instead, depending on the requirements and on the technology available for the specific application.

Addition of the complementary delay ("phase aligner")
1st order type 1 = the CDR with good acquisition characteristics.

Adding the complementary delay it becomes: the phase aligner.

This is the first architecture of three that must be remembered. Another example of unity feedback, 1st order and type 1.

The local oscillator is fixed and an adder compensates the phase deviations of the incoming signal before its regeneration with the local clock.

This example (its architecture is shown on the bottom left in the Figure above) has value in that it it is widely used in practice wherever this function is required in a network.

This example is of particular interest because:
 * - a clock independent from the PLL operation (i.e. $$\Phi$$ in the Figure above) is used for the regeneration, while it is -y(s) instead that represents the output of the PLL system.
 * - as a consequence of the point above, the CDR incorporates an "elastic buffer" function, located in the processing of the input signal through the adder block and through the subsequent re-sampling by the local clock ($$\Phi$$).

This example in fact describes the abstract model of the phase aligner. The CDRs that match this model are found in network points where a signal (jittered and possibly regenerated by slave CDRs one or more times along a transmission path) is brought back in phase with the clock that was used to generate it

For sake of simplicity in the following calculations - and without loss of generality in the results- the local clock $$\Phi$$ is used as reference for the phase of all the signals.

''Therefore its jitter is identically zero. Additionally it is assumed that the initial phase value $$\Phi_{t=0} = 0$$.''

 * The only function (the only one that is not a transfer function) which does not belong to the linear model is -obviously- the one that depends on non-linearities for its definition.
 * The jitter tolerance function depends in the case of the phase aligner on two hard non-linearities (phase comparator and phase adder), instead of on just one (the phase comparator) as in the case above.
 * Jitter transfer and Unit Step Response are identical functions to those derived in the previous example, and not repeated here.
 * The jitter transfer function in this case would describe a characteristic of the PLL as usual, but becomes meaningless for the whole CDR, because of the phase alignment resulting from the elastic buffer of this CDR.
 *  The Unit step response, in this particular case, as already pointed out for the transfer function, only describes the PLL operation, while it is meaningless for the whole CDR.
 * It can be seen as the waveform at the output of the phase adder ( $$ X - Y $$ signal in the Figure above ) resulting from a phase step of the input ($$ X(s)$$ in the Figure above ).

 *  Jitter tolerance function  ( The jitter tolerance function )

The phase jitter tolerance of this circuit is limited both by the range of linearity of the phase adder and by the range of linearity of the phase comparator.

Let's see each one separately. Then, the tolerance function at any frequency will simply be the lower of the two, because the signal in either of the two circuit blocks does not influence the characteristic of the other block.

 * Adder tolerance function ( Tolerance of phase adders )
 * The adder is normally made by a delay line, that adds a delay to the input signal ($$ X(s)$$ in the Figure above ) equal to the signal present on the control input ($$- Y(s) $$ in the Figure above ).
 * - Defining as D (measured in radian - if D is in seconds, then use Dω), the total phase delay that the delay line can add, and
 * - defining as zero the phase delay added when the control signal is set at the mid point of its control range,
 * then the tolerance of the adder inserted in the CDR circuit of the above Figure is:

(-D/2 + π) <  Magnitude of $$ Y(j \omega) $$ <  (+D/2 - π)
 * using the relation (see the relevant subsection on the jitter transfer function of this example)

$$Y(s)=\tfrac{X(s)}{s/G + 1}$$
 * then

Magnitude of $$ X(j \omega) $$ = (D/2 - π)*(s/G + 1)
 * Comparator tolerance function ( Tolerance of phase comparators )
 * The tolerance limit is reached when the phase difference between $$\Phi$$ and X-Y (again on the right part of the Figure above) exceeds an error $$\pm \theta_0$$:

Magnitude of $$\bigl( X(j \omega) $$ − $$ Y(j \omega) \bigr)$$ = θ0
 * using the relation (see the relevant subsection on the jitter transfer function of this example)

$$Y(s)=\tfrac{X(s)}{s/G + 1}$$
 * then

Magnitude of $$ X(j \omega) $$ = $$\theta_0\tfrac{\left |s/G + 1\right |}{\left|s/G\right|}$$ The relevant diagram of the jitter tolerance function is shown in the Figure here below. [[File:Jitter tolerance phase aligners.png|thumb|center|800px| Three magnitude functions of jitter tolerance obtained by simulation for the three main loop models. For each the lateral eye opening is the same, as is the same the length of the elastic buffer (=phase adder).

The two important 2nd order PLLs are plotted as well, in the under-damped but significant condition of ζ = 0.5.

The natural frequency is 500 KHz (ωn= 3.14 e6 rad/sec) and is the same for each of the three loops (yellow marker). ]] The figure above contrasts the case of the 1 - 1 loop (in blue) with the case of the other two important loops (2-1 and 2-2) only to better understand the former. The other two loops in fact are not used for phase-aligners, as explained in the following subsections.

As stated above, the unit step response and the jitter transfer function of this CDR do not differ from those of other 1st order, type 1 CDRs.

The jitter tolerance of this CDR shows a new example. It is limited at low frequencies by the jitter tolerance of the adder and, at medium and high frequencies, by the jitter tolerance of the phase comparator. In fact the actual design choices always assure that (-D/2 + $$\pi$$) >>  $$\theta_0$$. In conclusion, this example shows a CDR that:
 * is not able to tolerate a wander of the input signal frequency. There is no increasing jitter tolerance with a 6 dB/oct asymptote towards zero frequency, but just the flat tolerance limited by the adder range. This CDR can only phase align a signal (jittering but) synchronous with its local clock;
 * can lock in quickly into a signal burst after a period of loss of signal;
 * offers the inherent elastic buffer feature typical of phase aligners.

2nd order, type 1
[[File:2nd order type 1 loop, 3 examples.pdf|thumb|center|600px|alt=Three block diagrams of PLLs of 2nd order and type 1. Each block is identified and its transfer function is written beside it. All three are described by the same mathematical model as long as their blocks are considered linear.| 3 block diagrams of PLLs of 2nd order and type 1, described by the same mathematical model as long as their blocks are considered linear.

The first is the simplest to understand and the derivation of the model equations is easiest from it. It models a typical regenerator and is of fundamental importance for the communication engineer. ]]

Oscillator controlled in frequency ("regenerator CDR") 2 - 1
(Another example of a tracking system based on a second order, type 1 loop can be found in Wikibooks, at: Control Systems/Examples/Second Order Systems).

Some of the characteristics of the first architecture in the figure above make it ideal for the regenerator application. 2nd order type 1, slave: the regenerator CDR.

= the CDR with good de-jittering characteristics.

This is the second architecture of three that must be remembered.

It is presented as the first example in the figure here above.
 * The oscillator is controlled in frequency. It converts an input signal into a frequency, that is into the integral of a phase: its transfer function in the s domain is in fact V0/s.
 * Between the output of the phase comparator and the input of the oscillator, a single pole low pass circuit filters the higher frequencies of the error signal. (Combined with the oscillator, this low pass in the forward path makes the loop a second order, unity feedback, system).
 * The presence of an independent block to perform the low pass with a precise cut-off frequency (represented by $$\tau$$ in the figure above) gives the designer one more degree of freedom to find the best performance compromise.

The figures that follow, as in the previous examples, plot the unit step response, the jitter transfer function and the jitter tolerance function of this architecture. In order to appreciate some of the peculiarities of this new example (that is further developed in in a dedicated page further down in this book), also the corresponding curves for the fist order ( 1 - 1 ) slave have been plotted as well.
 *  Unit step response

The increased complexity of this architecture versus the first order one is responsible for the delayed reaction to an input phase step.

In fact this architecture is inferior to the first order alternative (no matter how smartly the design parameters are adjusted) when the lock-in phase of the system is of prime importance.

 *  Jitter transfer function

The ability to filter out the high frequency components of the incoming jitter is the strong point of this architecture.

When a series of regenerations takes place along a chain of telecom links, the jitter accumulation must be avoided, and the low pass action must have a (relatively) abrupt cut off.

This second order type 1 model (see the relevant figure) has a jitter transfer with a 40 dB/decade roll-off, while the first order type 1 model only offers a 20 dB/decade performance.

 *  Jitter tolerance function

The advantages offered for the jitter filtering are partially offset by some weakness in presence of strong jitter components concentrated around the corner frequency of the PLL (fortunately not very likely in practice).

While the first order loop presents a tolerance larger than 1 Unit Interval at all frequencies, this second order loop always has a frequency range where its tolerance is lower than 1 UI.

This dip of the tolerance is more evident for lower values of the damping ratio ζ, and the above figure uses the two curves to give evidence of that.

The importance of this architecture is such that an entire chapter is devoted to it further down in the book, where all time and frequency functions of the previous diagrams are described in detail and further developed. At this stage it is sufficient to have understood in which ways this architecture is different from the other architectures presented in this series of examples.

A modified representation of the same architecture
The second example in the figure above is essentially the same architecture as the first.

It helps introduce the concept that the equations and the behavior of a VCO can be separated into an integrator and a phase controlled element, that is typical of phase aligners.

Linear modeling is the same as the case above, while tolerance -obviously- depends on the linear range of the new blocks.

It is not an important example for practical applications.

Addition of the complementary delay ("2nd order type 1 phase aligner")
This architecture, the third in the figure of the 2 - 1 loops above, is another interesting example for didactic purposes, but has no value for a real CDR application.

The fundamental blocks are very similar to those of the previous example.
 * The last integrator block (an up/down counter in a digital implementation) corresponds to the oscillator controlled in frequency. It converts an input signal into a frequency, that is into the integral of a phase: its transfer function in the s domain is in fact Gf/s. (As there is no other 1/s factor in the open loop transfer function, this is a type 1 system).
 * Between the output of the phase comparator and the input of the oscillator, a single pole low pass filters the higher frequencies of the error signal. (Combined with the oscillator, this low pass in the forward path makes the loop a second order, unity feedback, system).

The functions that belong to the linear model (like the USR and the jitter transfer function) are exactly the same as in previous example of the slave 2 - 1 just above.

 *  Jitter transfer function

For instance, the jitter transfer function can be derived with the same steps used for the first order phase aligner: Y(s) = ($$\Phi$$ - X(s) + Y(s)) = (G / (s * (1 + s($$\tau$$)) * (- X(s) + Y(s)) -Y(s) s (1 + s$$\tau$$) = - G X(s) + G Y(s) G X(s) = Y(s) (G + s + s2$$\tau$$) $$\tfrac{Y(s)}{X(s)} =\tfrac{1}{\left ( 1 + s/G + s^2\tau /G\right)}$$ $$\tfrac{Y(s)}{X(s)}=\tfrac{1}{\left ( \tfrac{s^2}{\omega_n^2}+\tfrac{2s\zeta}{\omega_n}+1\right ) }$$ $$\omega$$n = $$\sqrt{\tfrac{G}{\tau}}$$ $$\zeta$$  =1 / 2$$ \sqrt{G\tau}$$ and it coincides with the jitter transfer function of the 2 - 1 slave of the previous example.

The ability to filter out the high frequency components of the incoming jitter is the strong point of the 2 - 1 architectures. This type of performance is valuable as long as the CDR is a regenerator and sends the regenerated clock with the data stream to another CDR downstream. In this example of a phase aligner however, this performance is not useful at all, because the phase aligner uses the PLL output only for its internal operation, and does not use it for its output data stream.

 *  Unit Step Response

The USR and its time diagram figure are identical to the ones of the previous 2 - 1 example.

 *  Jitter tolerance function

The jitter tolerance function of this architecture is different because it does not depend on the non-linearity of the phase comparator only, but also on the non linearity of the phase adder.

Whenever non-linearities are considered for architectures of the same order and type, a linear model -that is in fact the same for all architectures of the same order and type- cannot be used. The functions that describe the operation of these architectures (like jitter tolerance, ..) are different if different non-linearities are considered.

Following the approach of the first order phase aligner, the tolerance due to the adder must be combined with the tolerance due to the phase comparator.

The circuit tolerance, at any frequency, is the lower of the two.
 * Tolerance of the phase adder ( Tolerance of phase adders )
 * The adder is normally made by a delay line, that adds a delay to the input signal (X(s) in the figure above ) equal to the signal present on the control input (- Y(s) in the figure above ).
 * - Defining as D (measured in radian - if D is in seconds, then use D ω) the total phase delay that the delay line can add, and
 * - defining as zero the phase delay added when the control signal is set at the mid point of its control range,
 * then the tolerance of the adder inserted in the PLL circuit is:
 * then the tolerance of the adder inserted in the PLL circuit is:

(-D/2 + π) <  |Y(jω)|  <  (+D/2 - π).
 * using the relation found for the jitter transfer function of this example)

$$Y(s)=\tfrac{X(s)}{1 + 2\zeta s/\omega_n + s^2/\omega_n^2}$$
 * then

Tolerance(jω) = |X(jω)| = $$(\tfrac{D}{2}-\pi)\left |1 + 2\zeta \omega/\omega_n -\omega^2/\omega_n^2\right |$$

[[File:Jitter tolerance phase aligners.png|thumb|center|660 px|alt=Three magnitude functions of jitter tolerance obtained by simulation for the three main loop models. For each the lateral eye opening is the same, as is the same the length of the elastic buffer (=phase adder).| Three magnitude functions of jitter tolerance obtained by simulation for the three main CDR model architectures. For each the lateral eye opening is the same, as is the same the length of the elastic buffer (=phase adder).

The two important 2nd order PLLs are plotted as well, in the under-damped but significant condition of ζ = 0.5.

The natural frequency is 500 KHz (ωn= 3.14 e6 rad/sec) and is the same for each of the three loops (yellow marker). ]]

 * Tolerance of the phase comparator ( Tolerance of phase comparators )
 * The tolerance limit is reached when the phase difference between $$\Phi$$ and x-y (again on the Figure above) exceeds an error $$\pm \theta_0$$:

|X(jω) − Y(jω)| =$$\theta_0$$
 * using the relation (see the relevant subsection on the jitter transfer function of this example):

$$Y(s)=\tfrac{X(s)}{1 + 2\zeta s/\omega_n + s^2/\omega_n^2}$$
 * then:

|X(jω)| = |$$\theta_0|\tfrac{\left |1 + 2\zeta j\omega/\omega_n -\omega^2/\omega_n^2\right |}{\left|2\zeta j\omega/\omega_n -\omega^2/\omega_n^2\right|}$$ It is easy to see that the tolerance is equal (for $$\zeta$$ > 0.707) to the tolerance of the first order phase aligner, or inferior for lower values of $$\zeta$$.

The inherent weakness of this type of architecture (undershoot below 1 U.I. of the tolerance at frequencies around $$\omega$$n ) remains, and it can not be offset by the corresponding jitter transfer advantages that are meaningless for a phase aligner system.

As a result this architecture is inferior to the first order alternative (no matter how smartly the design parameters are adjusted) during the lock-in phase for a phase aligner application.

(On the other hand, it has the disadvantage of limited tolerance at low jitter frequencies, when compared to the classic 2nd order circuit for slave CDR applications, as it will be shown in the following paragraphs.)

In conclusion, the importance of this architecture is limited to its use as example for didactic purposes. Its first order alternative, simpler and more efficient, is preferred in practice for phase aligners.

2nd order type 2
If a 2nd order CDR PLL incorporates a single zero low-pass filter (instead of a single pole low-pass as in the examples above of the 2 – 1 PLL), then

the pole at frequency zero (that is implicit in the filter) makes the PLL change from type 1 to type 2. [[File:2nd order type 2 loop, 3 examples.pdf|thumb|center|600px|alt=Three block diagrams of PLLs of 2nd order and type 2. Each block is identified and its transfer function is written beside it. All three are described by the same mathematical model as long as their blocks are considered linear.| 3 block diagrams of PLLs of 2nd order and type 2, with the same mathematical model as long as their operation is linear.

The first is the simplest and the derivation of the model equations is easiest from it. It models a typical PLL for a slave CDR and is of fundamental importance for the communication engineer. ]].

The first example, in the figure of 2 - 2 PLLs just above, is the important one.

The other two are good exercises, but are not important for practical applications.

The model is described in detail in a page dedicated to the 2nd order, type 2 architectures later on in this book, owing to the practical importance of this first case (see figure above).

Oscillator controlled in frequency ("monolithic slave CDR") 2 - 2
The first of the three examples in the figure above is the third common PLL architecture for a (slave) CDR.

Important non-linearities are inevitably associated with a monolythic implementation, and the characteristic of robustness against them the have made this architecture the preferred choice for monolythic slave CDRs. 2nd order type 2, slave: the monolithic CDR.

= the CDR with good rejection of generated noise.

This is the third architecture of three that must be remembered.

It is presented as the first example in the figure here above. In the linear model it can be remarked that the loop filter provides a very high gain at very low frequencies.

This corrects any steady state error (squeezes the steady state error to zero) that may otherwise result from a difference between the frequency of the input signal and the free-running frequency of the local oscillator.

This also strongly attenuates the low frequency noise generated inside the PLL itself.

The loop filter does not attenuate the high frequencies, though. This makes this 2 - 2 loop less efficient (than the 2 - 1 loop) in rejecting the high frequency input noise (i.e. the part of the input jitter spectrum that does not carry any useful information about the sending clock and its phase). On the other hand, this makes this loop inherently faster in acquisition than the 2 - 1 loop.

This loop always overshoots in the lock-in phase, as the unit step response shows (see figure below).

The jitter transfer function
The transfer function can be derived, like for all other CDR PLLs that are unity feedback loops, using the two equations:

 * E(s) = X(s) - Y(s)

 * Y(s) = E(s) (gain of the loop forward chain)

and eliminating E(s) by substitution. In this case the result is: $$\tfrac{Y(s)}{X(s)} = \tfrac{(s\tau_z + 1)}{(s^2\tfrac{\tau_z}{G}+s\tau_z + 1)} $$ and the relation between the circuit parameters and the loop parameters ωn2 and ζ with respect to G and τz can be obtained from: $$\tfrac{Y(s)}{X(s)} = \tfrac{( 1 + \tfrac{s}{\omega_z})}{(1+\tfrac{2 \zeta s}{\omega_{n2}} +  \tfrac{s^2}{\omega_{n2}^2 })} =  \tfrac{(s\tau_z +1)}{(\tfrac{s^{2}\tau_z}{G} + s\tau_z + 1)} $$ Its magnitude is: $$|\tfrac{Y(j\omega)}{X(j\omega)}|$$ = 20 log10 $$\tfrac{( \omega^2\tau_z^2 + 1)^\tfrac{1}{2} } {(\omega^2\tau_z^2 + (1-(\tfrac{\omega^2\tau_z}{G})^2 )^\tfrac{1}{2}} $$ [[File:Jitter transfer functions 1 1, 2 1 , 2 2.png|thumb|center|550px|alt=Jitter transfer functions of the PLLs of order 1 type 1, order 2 type 1 and order 2 type 2, as well as the transfer functions of the two filter blocks for the two order 2 loops.| Magnitudes of the jitter transfer functions of the loops of  order 1 type 1, order 2 type 1 and order 2 type 2.

Filter cut-off frequencies, damping ratios and natural undamped frequencies are chosen for a meaningful comparison. ]]  Note:  1/$ω$z = $τ$z ; $ω$n2 = undamped natural frequency; $ζ$ = damping ratio

The unit step response
The unit step response can be obtained from the (jitter) transfer function multiplying the closed loop trasfer function by 1/s, and reverse transforming the result: $$ {1 +\tfrac{  e^{-\zeta\omega_{n2}t}\left ( \zeta\sin{\sqrt{1-\zeta^2}\omega_{n2}t}-\sqrt{1-\zeta^2}\cos{\sqrt{1-\zeta^2}\omega_{n2}t}  \right )}{\sqrt{1-\zeta^2}}}  $$  where ωn22 = G/τz and ζ  = G τz / 4 [[File:USR 2.2.png|thumb|center|760px| The amplitude of the output phase [rad] as a result of a (unit) step variation of the input phase, for different values of the damping ratio. Natural frequency = 1 GHz.

The output phase catches up quickly and overtakes the input (even if ζ ≥ 1), and then settles in good tracking with residual damped oscillations. ]]

The jitter tolerance
$$ |{X(j\omega)}|_{{\Epsilon(j\omega)}=1} = 1 / 20log_{10} \tfrac{(\tfrac{\omega^4}{\omega_{n2}^4}+\omega^2(\tfrac{2\zeta}{\omega_{n2}}-\tfrac{1}{\omega_z})^2)^\tfrac{1}{2}}{(\tfrac{\omega^2}{\omega_{z}^2}+(1-\tfrac{\omega^2}{\omega_{n2}^2})^2)^{\tfrac{1}{2}  } }$$

The asintote towards low frequencies (in the log-log plot) has a slope of 40 dB/ decade (as opposite to the slope of 20 dB/ decade  of the type 1 systems).

This is typical of all type 2 systems, that are more tolerant ( 20 dB/ decade more) of low frequency jitter than type 1 systems.

In the 2 - 2 loop, bandwidth and damping ratio increase when the gain increases
ωn222 = G / τz

ζ222 = G τz / 4

This is important for a monolithic implementation with a bang-bang phase detector (and sometimes also a bang-bang VCO) because the gain of those non-linear elements is very high when their input signal deviates very little from its center point.

Instability may occur at high gain conditions if the damping ratio decreased with increasing gain (like in a 2-1 loop), but luckily a 2-2 loop becomes more damped at high loop gain. Its bandwidth widens at the same time, and this is associated with more rejection of internally generated noise but also with less rejection of incoming line noise.

A modified representation of the same architecture
The second example in the figure above is essentially the same architecture as the first.

It helps introduce the concept that the equations and the behavior of a VCO can be separated into an integrator and a phase controlled element, that is typical of phase aligners.

Linear modeling is the same as the case above, while tolerance -obviously- depends on the linear range of the new blocks.

It is not an important example for practical applications.

The example of the 2 -2 phase aligner
The figure presented earlier in this page for the case of the 2 -1 phase aligner shows also the magnitude of the jitter tolerance for this example (Jitter transfer and unit step response remain in this case the same as for the 2 - 2 slave, because they do not depend on circuit non-linearities).

[[File:Jitter tolerance phase aligners.png|thumb|center|660 px|alt=Three magnitude functions of jitter tolerance obtained by simulation for the three main loop models. For each the lateral eye opening is the same, as is the same the length of the elastic buffer (=phase adder).| Three magnitude functions of jitter tolerance obtained by simulation for the three main CDR model architectures. For each the lateral eye opening is the same, as is the same the length of the elastic buffer (=phase adder).

The two important 2nd order PLLs are plotted as well, in the under-damped but significant condition of ζ = 0.5.

The natural frequency is 500 KHz (ωn= 3.14 e6 rad/sec) and is the same for each of the three loops (yellow marker). ]]

In this figure, the green curve represents the jitter tolerance function for the 2 - 2 phase aligner.

Note that the jitter tolerance function is the same as the one derived for the 2 - 2 slave until the half depth of the delay line becomes a horizontal limit at low jitter frequencies.

This 2 -2 phase aligner has no practical use, for reasons similar to the ones that make also the 2 -1 phase aligner a non preferred option. The 1 - 1 phase aligner is the preferred choice.

The 2 -2 phase aligner has a slightly better tolerance in a small region of frequencies, but this is a negligible advantage in practice and is offset by its risky behavior close to the natural undamped frequency. The loop ability to reduce strongly the low frequency noise of the local oscillator and its ability to reduce to zero the steady state frequency error make no sense for a phase aligner.

The three structures that cover all the actual CDRs
Many problems can be solved better, or quicker –if not avoided altogether-, if the engineer is familiar with, and uses three simple mathematical models, because the fundamental behavior of every CDR can be referred to one of them:
 * 1) The phase aligner (modeled by a 1 - 1 structure)
 * 2) The regenerator (modeled by a 2 - 1 structure)
 * 3) The robust, tolerant monolithic implementation with bang-bang detector and ring VCO (modeled by a 2 - 2 structure).

These three structures (1-1, 2-1, 2-2) out of two architectures (1st order and 2nd order) are the ones used in practice. The phase comparator (and/or the VCO) may or may not be linear

ωn1 = ωn21 / 2 ζ21 ; ωn1 =  2 ζ22 ωn22 e.g. if ωn2 = ωn1, then,  ζ = ½.
 * For the 2nd order loops, ωn1 can be expressed as a function of the other two parameters. For the 2-1 and 2-2 loops :
 * If the filtering caracteristics ( τf or   τz ) are kept fixed, and just the open loop gain is varied , then the behaviour of the two 2 nd order loops is different, almost "opposite" :
 * 2-1	 ωn212 = G / τf and ζ212 =1 / ( 4 G τf)
 * the 2-1 gets less damped with more gain, i.e. more damped with less gain.
 * 2-2	 ωn222 = G / τz and ζ222 = G τz / 4
 * the 2-2 gets more damped with more gain, i.e.less damped with less gain !
 * This opposite behavior of ζ21 and of  ζ22 with respect to the loop gain G explains why
 * 2-1 is not used with bang-bang phase detectors nor VCOs, while
 * 2-2 (not preferred with phase comparator and VCO of linear type) becomes the preferred choice with bang-bang phase detectors (and VCOs).

 * The interesting characteristics of the 2-1 (rejection of the signal jitter, that make it preferred for regenerator applications) depends on a good control of the damping ratio, ζ21 . ζ21, in turn, depends on the loop gain G and decreases when G increases (risk of jitter peaking!): ζ212 =1 / ( 4 G τf).
 * The gain of the non linear blocks (bang bang detector and bang-bang VCO) is not constant, but varies with the signal amplitude. In particular, the bang-bang gain is maximum when the signal at the input of the blocks is very close to its center value. The gain is minimum instead when the signal deviates most from its center value.

As a result, the three fundamental structures find their best fit as follows:
 * 1)  1.1
 * linear or non-linear blocks; Preferred when the acquisition time shall be minimum (burst-mode transmission), and even more so when Es is zero by definition (= for phase aligners). Furthermore, it is a good choice in many cases when there are no specific requirements that suggest a 2nd order loop.

 * 1)  2
 * 2) 2.1 (filter with flat gain at low freq.): preferred for regenerator applications when linear blocks are used.
 * 3) 2.2 (filter with very high gain at low freq.): preferred for  applications where non-linear (= widely variable gain) blocks are used and in particular for high performance monolithic implementations.


text:
User talk:80.0.103.19

Νεοπτόλεμος ( talk | email | contribs ) 20:59, 26 March 2008 (UTC)

title: User talk:80.0.103.19


text:
User talk:Laura---x

Νεοπτόλεμος ( talk | email | contribs ) 20:59, 26 March 2008 (UTC)

title: User talk:Laura---x


text:
User talk:86.152.5.78

Νεοπτόλεμος ( talk | email | contribs ) 20:59, 26 March 2008 (UTC)

title: User talk:86.152.5.78


text:
Parrot Virtual Machine/Languages on Parrot

Languages on Parrot
There are a number of programming languages being implemented on Parrot, some of which are nearing functional completion, some which are still in active development, and some which have been started but are now abandoned. Interested developers may want to help join in the development effort with some of these languages, adopt an abandoned language project, or start a new language project entirely.

As of the 1.0.0 release, all language implementations except toy and example languages will be developed and maintained outside of the central Parrot repository. Where available, locations to external project pages will be provided.

Rakudo (Perl 6)
Rakudo is the name of the Perl6 implementation on Parrot. This is not the only implementation of Perl6, however.

Rakudo development is test-driven. There is a gigantic suite of tests for the Perl6 language that have been developed over the years. The progress of the Rakudo interpreter is measured by the number of specification tests, or "spectests" that pass. There is not a straight-forward way to measure the percentage progress of the project, because the total number of tests is changing regularly as well.

Rakudo is under active development by several volunteers. Some developers have even received funding to work on Rakudo more regularly.

abc
A basic calculator language.

C99
The implementation of the C programming language, following the C99 specification, has a number of purposes. C is a strongly-typed language, so it isn't necessarily the best candidate for implementation on the dynamically-typed Parrot. However, there are a number of benefits to the Parrot project to having a C parser available.

The C99 language parser is being used, at least in part, to help automate the process of generating NCI function signatures for new libraries and extensions. This is under active development by volunteers, some of which have been funded.

Cardinal (Ruby)
An implementation of Ruby

Jako
A language derived from C and Perl

Pipp (PHP)
Pipp is a recursive acronym for Pipp is Parrot's PHP. This language implementation was previously named "Plumhead", shorthand for the name "Plum-headed Parakeet". Pipp is being maintained on github at pipp. The project seems halted: the website is down/missing and the last commit was at 2009-07-22.

Partcl (TCL)
ParTCL is the TCL compiler for Parrot. The ParTCL project lives at http://code.google.com/p/partcl/

Translator Projects
Projects to translate to or from Parrot Bytecode.

Resources

 * http://www.parrot.org/languages/


text:
User talk:Dark Sunshine~enwikibooks

Welcome!
Welcome, Dark Sunshine!

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

Inclusion policy
Please read our project scope before beginning new books or modules. Wikibooks is for textbooks, not fiction. Thanks! – Mike.lifeguard  | talk 21:29, 26 March 2008 (UTC)

Your account will be renamed
Hello,

The developer team at Wikimedia is making some changes to how accounts work, as part of our on-going efforts to provide new and better tools for our users like cross-wiki notifications. These changes will mean you have the same account name everywhere. This will let us give you new features that will help you edit and discuss better, and allow more flexible user permissions for tools. One of the side-effects of this is that user accounts will now have to be unique across all 900 Wikimedia wikis. See the announcement for more information.

Unfortunately, your account clashes with another account also called Dark Sunshine. To make sure that both of you can use all Wikimedia projects in future, we have reserved the name Dark Sunshine~enwikibooks that only you will have. If you like it, you don't have to do anything. If you do not like it, you can pick out a different name.

Your account will still work as before, and you will be credited for all your edits made so far, but you will have to use the new account name when you log in.

Sorry for the inconvenience.

Yours, Keegan Peterzell Community Liaison, Wikimedia Foundation 23:08, 17 March 2015 (UTC)

Renamed
 This account has been renamed as part of single-user login finalisation. If you own this account you can |log in using your previous username and password for more information. If you do not like this account's new name, you can choose your own using this form after logging in: . -- Keegan (WMF) (talk) 04:51, 19 April 2015 (UTC)

title: User talk:Dark Sunshine~enwikibooks


text:
Mewa User's Guide

Mewa User's Guide was the official user's guide for Mewa, a video creator and compositor. It aims to provide all the information needed to use the latest version of Mewa, as well usage techniques to get the best out of it. Download the latest Mewa from the official website www.mewatools.com.

This documentation was made for all Mewa community, and we appreciate all the help on improving this documentation.

Contents

 * /Getting started/
 * /Main window/
 * /Import footage/
 * /Using the Node Graph/
 * /Animating parameters with Curve Editor/
 * Nodes Reference
 * /Footage node/
 * /Move2D node/
 * /ColorWheel node/
 * /Mewa Script Programming/

Other documentation

 * /Extending Mewa with custom shaders/

title: Mewa User's Guide


text:
Mewa Film User's Guide/Introduction

Introduction
Now days with technologic advance of desktop graphics hardware you no longer need to purchase expensive post-production suites to do movie editing and create 3D visual effects. Mewa Film is an innovative Editorial, Effects and Finishing software application, that takes advantage of desktop graphics hardware to provide the performance found in professional post-production suites.

With a simple set of editorial tools Mewa Film provides a wealth of functionality. This functionality can be easily and quickly extended with MFX files.

Mewa Film is also multi platform, this means it can run on Windows, Linux or MacOS platforms.

Still under development, Mewa Film aims to provide visual effects tools, keying, color correction, multilayer compositing, rotoscope, retouching, motion tracking, and many more.

Back to contents page

title: Mewa Film User's Guide/Introduction


text: Category:Book:MIRC Scripting/Templates

title: Category:Book:MIRC Scripting/Templates


text:
User talk:216.15.63.107

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

title: User talk:216.15.63.107


text: Category:Book:MIRC Scripting/Images

title: Category:Book:MIRC Scripting/Images


text: Wikibooks:Requests for deletion/IPA

title: Wikibooks:Requests for deletion/IPA


text:
User talk:Goulart

Welcome, Goulart!

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

Image:Mewafilm logo.png is missing license or source information

 * This looks to be a logo of a film company? If so, the logo will be copyrighted, and the only way you can use this is with a claim of fair use. Please provide a source, and update the licensing (adding a if required) for this image. If you have questions, please ask on my talk page.  – Mike.lifeguard  | talk 22:38, 26 March 2008 (UTC)

I think I fixed it. Thanks. Hugo

Image:MontageTabs.png is missing license or source information

 * Same as the above; this is a fair use image. Please be very careful to provide accurate license information. Do not upload images with false information please. The fair use template is available in the dropdown, and you must provide a rationale as well. Thanks for taking care of the first one so quickly! – Mike.lifeguard  | talk 15:11, 27 March 2008 (UTC)
 * Image:SaveDialog.png too. – Mike.lifeguard  | talk 15:12, 27 March 2008 (UTC)
 * Image:FileMenu.png needs a fair use template and rationale please. – Mike.lifeguard  | talk 16:10, 27 March 2008 (UTC)

Subject doesnt work
I added at the end of the main page, and it appears in red. How should I add a subject to my wikibook ??
 * You want to use (a pipe, not a colon). But are you sure you want to categorize it that way? All pages in that category should be pages of Movie Making Manual. Each book should have it's own category, so you should have one for that book, which contains all pages of the book. As well,  automatically adds the book category (the same name as the book), so you should use the template instead to categorize the book's content. 03:09, 1 April 2008 (UTC)

Delete a page
How can I delete a page ? How do I get sysops permissions ??
 * You can simply add at the top of the page, and an admin will come along and take care of it. For information about sysop permissions, see WB:ADMIN.  – Mike.lifeguard  | talk 03:09, 1 April 2008 (UTC)

Image:MewaFilm WinInstaller.png is missing license or source information
OK, so a bunch of your images still have problems. Here's how to fix them: If you need clarification on this, please ask. It's important that we have accurate information on every piece of media, so please double-check every file you've uploaded, and be careful about this in the future. Thanks! – Mike.lifeguard  | talk 15:24, 5 April 2008 (UTC)
 * 1) Screenshots must have and a  - not GFDL or some other license - it is a fair use image!
 * 2) All images need filled out
 * Note that for Image:MontageSelectedFrames.png and anything else that incorporates another person's content (ie the frames from the video) you'll need an additional license tag or fair use tag + rationale, as you're using that persons' content too. If it's the standard starter video file that comes with the software, then you can ignore that as it's covered by the same license as the software itself, and you've already got the fair use claim.

Done! Thanks, Hugo
 * Please check your recent uploads - they all need source and license info. (And if they are fair use images they need a rationale). – Mike.lifeguard  | talk 19:24, 16 May 2008 (UTC)

File:UndoButton.png is unused
The non-free file is unused. Please properly use it within 48 hours, or it will be deleted.--Jusjih (discuss • contribs) 21:43, 19 August 2023 (UTC)

title: User talk:Goulart


text: User talk:74.94.41.245

title: User talk:74.94.41.245


text:
User:Seraphim Whipp/Sandbox

I did not make this edit... before the unified log in, I had never registered an account here and only tried logging in today when I checked if anyone else had used my username on other projects. Hmm.

title: User:Seraphim Whipp/Sandbox


text: User talk:75.106.192.37

title: User talk:75.106.192.37


text:
User talk:Seraphim Whipp

Welcome!
Welcome, Seraphim Whipp!

Come introduce yourself at the new users page. If you have any questions, you can ask there or contact me personally.--Whiteknight (Page) (Talk) 00:48, 27 March 2008 (UTC)

title: User talk:Seraphim Whipp


text:
Parrot Virtual Machine/Multithreading and Concurrency

Multithreading Requirements
Multithreading is an area where interpreted languages such as Perl 5 have had some problems in the past. Perl 5, as a prime example, had a very buggy and non-robust implementation of threads that was not scalable.

In contrast to Perl 5, Perl 6 is including advanced multithreading and concurrency features in the core language. To support all these advanced features of the Perl 6 language, Parrot must provide those same features as well.

Coroutines
While not technically "multithreading", coroutines represent a simple form of concurrency that will find many interesting uses as they catch on with mainstream programmers. Coroutines are like subroutines which use a yield statement instead of a return statement. The  statement causes the coroutine to return a value to the caller. However,  does not cause the coroutine to exit, disappear, or lose its current state. The next time the caller calls the coroutine, the coroutine will pick up where it left off the last time. Here is an example:

.sub 'MyCoroutine' .yield(1) .yield(2) .return(3) .end

.sub 'MyCaller' $I0 = 'MyCoroutine' say($I0) $I0 = 'MyCoroutine' say($I0) $I0 = 'MyCoroutine' say($I0) .return

The output of the function  will be:

1 2 3

Coroutines are immediately useful in places where a persistent state needs to be maintained, but where it might be difficult to coordinate that state between multiple callers, or multiple threads. One such example is in file or database access where a coroutine can serialize accesses, and maintain persistent state information about the size of the file and locations of certain features in the file.

Coroutines are also called "continuations" in other places, or even "continuation sandwich" in others.

Coroutine Parameters
Parameters to a coroutine are only passed the first time the coroutine is called, or any time the coroutine is called after having a  statement. Here is an example:

.sub 'MyCoroutine' .param int a   .yield(a) .yield(a) .yield(a) .return(a) .end .sub 'main' :main $I0 = 'MyCoroutine'(1) # the "call" say $I0 $I0 = 'MyCoroutine'(2) # "continuation" say $I0 $I0 = 'MyCoroutine'(3) # "continuation" say $I0 $I0 = 'MyCoroutine'(4) # "continuation" say $I0 .end

This code will print the following result, even though the parameter to the  function changes with each call:

1 1 1 1

This is because only the first call to  is actually a function call that creates the local parameters. The other calls to  are simply continuations, not calls. A continuation does not create new parameter variables.

Returning and Yielding
A return call in a coroutine causes it to return a value to the caller and to destroy its current lexical scope, as usual. A yield call, however, will return a value without destroying the current lexical scope. Yielding then will allow the coroutine to maintain its current state and resume its execution the next time it is called.

Continuation and Coroutine PMCs
This is where the heart of the coroutine system is located, the coroutine PMC. The coroutine PMC is an object that stores the state of the coroutine so that it can be called multiple times in a row. A continuation PMC, which is a superclass of the coroutine, is a stored interpreter state. The coroutine operates by storing a continuation when a  directive is called, and invoking that continuation when the coroutine is called again.

Threads
Internally, Parrot supports multiple different methods to perform threading. Luckily, all of these different methods are abstracted and the details are hidden from the HLL programmer. Parrot's concurrency system is modular, so new multithreading technologies can be added to Parrot later, and HLL programmers will be able to benefit from these changes and additions without having to make any changes to their code.

Managing Threads
There are four basic operations that can be used to create and manage a new thread. In Parrot, threads are all abstracted in the Task PMC. To create a new thread, you first create a new Task PMC, and then you add it to the scheduler.

Resources

 * http://www.parrotcode.org/docs/pdd/pdd25_concurrency.html
 * Synopsis 17


text:
Parrot Virtual Machine/Exception Handling

Exceptions
Exceptions are errors that are caused in a program. However, unlike an ordinary error which causes the program to terminate unexpectedly, exceptions are controlled and can be recovered from without having to restart the program.

In Parrot, exceptions are objects. This means you create an exception using the  keyword, and manipulate an exception using methods on that object. Before we discuss exceptions any further, we need to discuss some terminology. Readers who are familiar with exceptions in other programming languages can probably skip these definitions.

 * Throw: To throw an exception means to create an exception object. Once an exception has been created, the system enters a kind of "panic state" where it attempts to fix the exception. If the exception cannot be fixed, the program terminates.
 * Raise: To raise an exception is the same as to throw one.
 * Handler: A handler is a routine which can fix an exception. When an exception is raised and the system enters panic mode, it looks for a handler. If there is a handler available, the exception is sent to that handler. If no handlers are available to handle the exception, the system will terminate.
 * Catch: A handler that receives an exception object is said to "catch" it. Whenever an exception is thrown, a handler should be available to catch it. Again, if no handlers are available to catch an exception, Parrot will exit.
 * Rethrow: All handlers are not equipped to handle all exceptions. If a handler catches an exception that it cannot fix, it can optionally rethrow that exception. Rethrowing causes the system to search for a different handler.

Creating an Exception
Creating a new exception object in PIR is deceptively simple:

$P0 = new 'Exception'

Exceptions are hash-like, which means they have named fields. One such field is the  field, which contains the name of the exception. Exception handlers will check the name to determine if they can handle a particular exception, or if it needs to be rethrown.

Creating a Handler
In Parrot, a handler is a label that the system jumps to in the event of an exception. These labels are stored in a stack structure. The exception handler on the top receives the instruction, but if it rethrows, the exception will be propagated down through the exception stack until it is finally handled.

Resources

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


text:
Parrot Virtual Machine/Classes and Objects

Classes and Objects
We briefly discussed some class and object PIR code earlier, and in this chapter we are going to go into more detail about it. As we mentioned before, classes have 4 basic components: A namespace, an initializer, a constructor, and methods. A namespace is important because it tells the virtual machine where to look for the methods of the object when they are called. If I have an object of class "Foo", and I call the "Bar" method on it:

.local pmc myobject myobject = new "Foo" myobject.'Bar'

The virtual machine will see that  is a PMC object of type Foo, and then will look for the method 'Bar' in the namespace 'Foo'. In short, the namespace helps to keep everything together.

Initializers
An initializer is a function that is called at the beginning of the program to set up the class. PIR doesn't have a syntax for declaring information about the class directly, you have to use a series of opcodes and statements to tell Parrot what your class looks like. This means that you need to create the various data fields in your class (called "attributes" here), and set up relationships with other classes.

Initializer functions tend to follow this format:

.namespace

.sub 'onload' :anon :init :load .end

The  flag means that the name of the function will not be stored in the namespace, so you don't end up with all sorts of name pollution. Of course, if the name of the function isn't stored, it can be difficult to make additional calls to this function, although that doesn't matter if we only want to call it once. The  flag causes the function to run as soon as parrot initializes the file, and the   flag causes the function to run as soon as the file is loaded, if it is loaded as an external library. In short: We want this function to run as soon as possible and we only want it to run once.

Notice also that we want the initializer to be declared in the HLL namespace.

Making a New Class
We can make a new class with the keyword. To create a class called "MyClass", we would write an initializer that does the following:

.sub 'initmyclass' :init :load :anon newclass $P0, 'MyClass' .end Also, we can simplify this using PIR syntax:

.sub 'initmyclass' :init :load :anon $P0 = newclass 'MyClass .end

In the initializer, the register $P0 contains a reference to the class object. Any changes or additions that we want to make to the class need to be made to this class reference variable.

Creating new class objects
Once we have a class object, the output of the newclass opcode, we can create or "instantiate" objects of that class. We do this with the new keyword:

.local PMC myobject myobject = new $P0

Or, if we know the name of the class, we can write:

.local PMC myobject myobject = new 'MyClass'

Subclassing
We can set up a subclass/superclass relationship using the  command. For instance, if we want to create a class that is a subclass of the builtin PMC type "ResizablePMCArray", and if we want to call this subclass "List", we would write:

.sub 'onload' :anon :load :init subclass $P0, "ResizablePMCArray", "List" .end

This creates a class called "List" which is a subclass of the "ResizablePMCArray" class. Notice that like the  instruction above, we store a reference to the class in the PMC register $P0. We'll use this reference to modify the class in the sections below.

Adding Attributes
Attributes can be added to the class by using the  keyword with the class reference that we received from the   or   keywords. Here, we create a new class 'MyClass', and add two data fields to it: 'name' and 'value':

.sub 'initmyclass' :init :load :anon newclass $P0, 'MyClass' add_attribute $P0, 'name' add_attribute $P0, 'value' .end

We'll talk about accessing these attributes below.

Methods
Methods, as we mentioned earlier, have three major differences from subroutines: The way they are flagged, the way they are called, and the fact that they have a special  variable. We know already that methods should use the  flag. indicates to Parrot that the other two differences (dot-based calling convention and "self" variable) need to be implemented for the method. Some methods will also use the  flag as well, and we will discuss that below.

We want to create a class for a stack class. The stack has "push" and "pop" methods. Luckily, Parrot has  and   instructions available that can operate on array-like PMCs (like the "ResizablePMCArray" PMC class). However, we need to wrap these PIR instructions into functions or methods so that they can be used from our high-level language (HLL). Here is how we can do that:

.namespace

.sub 'onload' :anon :load :init subclass $P0, "ResizeablePMCArray", "Stack" .end

.namespace ["Stack"]

.sub 'push' :method .param pmc arg push self, arg .end

.sub 'pop' :method pop $P0, self .return($P0) .end

Now, if we had a language compiler for Java on Parrot, we could write something similar to this:

Stack mystack = new Stack; mystack.push(5); System.out.println(mystack.pop);

The example above would print the value "5" at the end. If we look at the same example in a language like Perl 5, we would have:

my $stack = Stack::new; $stack->push(5); print $stack->pop;

This, again, would print out the number "5".

Accessing Attributes
If our class has attributes, we can use the  and   instructions to write and read those attributes, respectively. If we have a class 'MyClass' with data attributes 'name' and 'value', we can write accessors and setter methods for these:

.sub 'set_name' :method .param pmc newname $S0 = 'name' setattribute self, $S0, newname .end

.sub 'set_data' :method .param pmc newdata $S0 = 'data' setattribute self, $S0, newdata .end

.sub 'get_name' :method $S0 = 'name' $P0 = getattribute self, $S0 .return($P0) .end

.sub 'get_value' :method $S0 = 'value' $P0 = getattribute self, $S0 .return($P0) .end

Constructors
The constructor is the function that we call when we use the  keyword. The constructor initializes the data object attributes, and maybe performs some other bookkeeping tasks as well. A constructor must be a method named 'new'. Besides the special name, the constructor is like any other method, and can get or set attributes on the  variable as needed.

Resources

 * http://www.parrotcode.org/docs/pdd/pdd15_objects.html
 * http://www.parrotcode.org/docs/pdd/pdd21_namespaces.html


text:
Parrot Virtual Machine/The Parrot Debugger

The Parrot Debugger
Parrot's debugger used to be a separate program that was not always built by default. However, work is under way to add a debugging runloop directly to the Parrot executable itself. As work progresses on this project, more information will be included here.

Resources

 * http://www.parrotcode.org/docs/debug.html
 * http://www.parrotcode.org/docs/debugger.html


text:
Parrot Virtual Machine/Memory and Garbage Collection

Arenas and Pools
Parrot allocates memory in large blocks called arenas. Each arena has enough space to hold exactly N items of size M, typically tightly packed together in consecutive memory locations. Some collectors may also store additional metadata in the arena as well. Multiple arenas of the same type are stored as a linked list inside a pool. A pool may no arenas, one arena, or multiple arenas, but arenas in a given pool all contain objects of the same size. However, each arena may hold a different number of objects.

The parrot interpreter structure, which maintains state for the entire virtual machine, contains a pointer to the arena_base structure. The arena base structure contains pointers to all the various pools, and a few other important data items that are used for memory management.

Garbage Collectors
Parrot has a number of garbage collectors available, which can be selected at compile time using compiler directives. The most mature and robust collector at this time is a simple mark & sweep collector, GC_MS. The different collectors can be activated or deactivated prior to compilation in the file. That file contains a number of options that you can set to customize the behavior of Parrot.

Mark & Sweep Collector
The Mark & Sweep (MS) collector is the only collector for Parrot that is currently mature and stable enough for regular use. However, this collector is the cause of several performance problems in Parrot, and there are active efforts under way to replace it. The mark & sweep collector will likely be deprecated or removed entirely from Parrot by the 1.0.0 release.

Incremental Tricolor Collector
Development is currently under way on a new garbage collection scheme which uses a tricolor marking algorithm to mark data objects. The tricolor algorithm will enable an incremental behavior in the collector so that the "stop the world" behavior of the MS collector can be avoided for large memory pools.

Writing new Collectors
Writing a new collector is as simple as implementing a particular interface. This interface is defined in detail in PDD 09, but we will cover some of the basics here.

Resources

 * http://www.parrotcode.org/docs/memory_internals.html
 * http://www.parrotcode.org/docs/pdd/pdd09_gc.html


text:
Parrot Virtual Machine/Bytecode File Format

Packfile Header Format
Packfiles start with a standard header that give some information about how Parrot was configured when it wrote the file. This configuration information is used to determine how the reading Parrot must translate the incoming packfile.

Resources

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


text:
Parrot Virtual Machine/PIR Reference

Resources

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

title: Parrot Virtual Machine/PIR Reference


text:
Parrot Virtual Machine/PASM Reference

Resources

 * http://docs.parrot.org/parrot/latest/html/docs/pdds/draft/pdd06_pasm.pod.html
 * http://docs.parrot.org/parrot/latest/html/docs/pdds/draft/pdd05_opfunc.pod.html
 * http://docs.parrot.org/parrot/latest/html/ops.html

title: Parrot Virtual Machine/PASM Reference


text:
Parrot Virtual Machine/PAST Node Reference

Resources

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


text:
Parrot Virtual Machine/PMC System

PMCs
We've discussed PMCs already -- in the Parrot Virtual Machine/Polymorphic Containers (PMCs) chapter -- including how to define new PMC types using the PMC compiler, and how to use them in PIR programs. This chapter is going to go into more detail about how PMCs are actually used in Parrot, including memory management of PMCs, morphing PMCs, and interfacing with PMCs.

PMC System Overview
The PMC data structure is deceptively simple, and is designed to be extensible enough for general purpose data and functionality use. Here is the definition of the PMC structure and the associated PMC_EXT structure:

As we can see in these definitions, the PMC is actually very small. Much of the information about a PMC, including all it's various methods and VTABLE interfaces is stored in the  pointer. The VTABLE structure is a very large structure that contains function pointers for all the various VTABLE interfaces.

PMC Data
Every PMC type also contains a pointer for a data structure that's specific to that PMC. These data structures are defined based upon the inheritance hierarchy of the PMC and the various attributes that it has been defined with. For instance, this PMC definition:

will turn into this C data structure definition:

This structure is supposed to be contained in the  pointer, which should always be accessed using the   macro. This way if the PMC structure definition changes eventually, all code that uses the macros properly will be automatically updated because the macro will be updated. Here is an example of an initialization VTABLE that uses these attributes:

There is another macro which uses the word PARROT and the name of the PMC in all capital letters to retrieve the data structure again and properly cast it (so your compiler doesn't give warnings about using pointers without a cast):

PObjects
C isn't a class-based (or "object oriented") language, but many lessons from OO programming methodologies have been adapted for use in Parrot's code base. PMCs, STRINGs, and a few other data types are based off the definition of a "PObj", also known as a "Buffer":

Notice how the first two entries in the Buffer are the same as in the PMC? All objects that start off with these two data items are said to be "PObject isomorphic". For short, we say that all pobject isomorphic are simply "PObjects", and there are many types of PObjects. The memory management system, for example, can test the flags of all pobjects to determine what type of PObject a memory object is.

A PMC may optionally contain a PMC_EXT structure, which adds additional functionality. PMC_EXT allows a PMC to be shared between multiple threads, or multiple Parrot interpreters without introducing data contention. PMC_EXT also allows a PMC to contain a hash of metadata (attribute value pairs), which are typically added as attributes in PIR.

PMC Management
PMCs are allocated from two special pools, a PMC pool and a constant PMC pool. Constant PMCs are considered to be immutable and everlasting, and so are never modified nor collected by the garbage collector. STRINGS are allocated in either a string pool or a constant string pool. The same relationship applies, constant strings are never modified and never collected. PMC_EXT structures are not currently managed by the memory management subsystem. However, since PMC_EXTs are assigned to PMCs in a one-to-one relationship, we always know we can free it when it's PMC is freed.

In terms of garbage collection, PMCs are one of the only aggregate data types in Parrot. STRINGS do not contain pointers to other data items of interest to the garbage collector. Stack chunks, which are used internally in some structures are PObjs and are also aggregates, but are marked separately by the collector and are not treated as aggregates directly.

VTables
VTables represent a standard interface to PMCs of all types. For every single PMC, there are a series of standard operations that you can perform (or attempt). Not all PMCs support all Vtable operations

VTable Types
VTables are complicated data items that contain, in addition to a large series of function pointers, a number of data items to support PMCs. One of the data items is a class PMC, a PMC that represents a particular PMC class. Another item is an enum that differentiates between all PMC classes.

Resources

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

title: Parrot Virtual Machine/PMC System


text: User talk:24.17.213.119

title: User talk:24.17.213.119


text: User talk:125.60.134.6

title: User talk:125.60.134.6


text: User talk:63.26.148.13

title: User talk:63.26.148.13


text:
Talk:ANSI C with Unix

This is useless. Better to delete it than have no content at all
Um. Whatever. If it were deleted, someone would simply redo the whole thing and leave it here again. Why waste that time? The structure is fine, it just needs contributions to the reference sections. Anyway... a lot of the content for the lower sections is already up, for free (CC or the like). It could be aggregated here easily. My concern is more with the "with UNIX" part of the title. Clearly the present content reflects it to mean "using a POSIX shell, common command line tools, and the GNU compiler toolchain. This is only a tiny part of the picture. I suggest all shell script examples not be necessarily Bourne-again, or even Bourne compatible, but rather, use straight POSIX shell syntax only. This is not a scripting book, it's a C programming book. Further, the only C programming section title I really see so far that even have a hint of Unix is IPC (inter-process comms).
 * I agree

If you really want to make this a useful study reference, then the sections following C syntax should break down POSIX calls into categories. This does two things; first, it frees you from having GNU/Linux-only examples, and second, it provides a LOT more useful content to the user. Certainly, they can learn how to open, fprintf, and close files. Why not learn about fstat and stat? How big are files, regardless of their OS or filesystem? Why not learn symlink and unlink, this is Unix, right? One could cover twenty-five of the most commonly used POSIX system calls and increase the book's usefulness a hundredfold. Please do not simply re-invent KR, but with a bash & GCC primer.
 * I agree, there many of those!

One could learn, on GNU/Linux, with this book, and then immediately apply 100% of what they learn directly to an embedded distro, or 85% directly to a Mac OS X machine. Just a suggestion :) ...   65.112.197.16 (talk) 18:09, 5 June 2008 (UTC)
 * I agree that this can be deleted! Because it is 13 years old with just one person wrote something.
 * This book should not be initiated here, because it was conceived as part of a particular course in programming, in addition to other programming courses and is compared to Java. I suppose that the course is outdated or the students are not motivated to write this book. I started to help this project but cancelled my changes because I noticed that this is really a project for that course.
 * Also because there are many free books covering the topics.
 * maybe just to be polite and ask agreement of the original poster of this book.

title: Talk:ANSI C with Unix


text:
User talk:Jbrave~enwikibooks

Welcome!
Welcome, Jbrave!

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

Your account will be renamed
Hello,

The developer team at Wikimedia is making some changes to how accounts work, as part of our on-going efforts to provide new and better tools for our users like cross-wiki notifications. These changes will mean you have the same account name everywhere. This will let us give you new features that will help you edit and discuss better, and allow more flexible user permissions for tools. One of the side-effects of this is that user accounts will now have to be unique across all 900 Wikimedia wikis. See the announcement for more information.

Unfortunately, your account clashes with another account also called Jbrave. To make sure that both of you can use all Wikimedia projects in future, we have reserved the name Jbrave~enwikibooks that only you will have. If you like it, you don't have to do anything. If you do not like it, you can pick out a different name.

Your account will still work as before, and you will be credited for all your edits made so far, but you will have to use the new account name when you log in.

Sorry for the inconvenience.

Yours, Keegan Peterzell Community Liaison, Wikimedia Foundation 23:16, 17 March 2015 (UTC)

Renamed
 This account has been renamed as part of single-user login finalisation. If you own this account you can |log in using your previous username and password for more information. If you do not like this account's new name, you can choose your own using this form after logging in: . -- Keegan (WMF) (talk) 05:04, 19 April 2015 (UTC)

title: User talk:Jbrave~enwikibooks


text:
User talk:209.121.58.186

Join Us!
-- – Mike.lifeguard  | talk 02:24, 27 March 2008 (UTC)

title: User talk:209.121.58.186


text:
Wikijunior:Famous Inventors/Inventors in Medicine

Inventors in Medicine

 * /Marie Curie/


text:
Wikijunior talk:Famous Inventors

Should the names of the inventors be moved to the individual chapter pages?--Jsigler (talk) 03:51, 27 March 2008 (UTC)

What do we do with inventors that have major inventions in more than one chapter? The biographical information will be the same, but the story about how they created the invention will differ.-- Jsigler (talk) 03:57, 27 March 2008 (UTC)

title: Wikijunior talk:Famous Inventors


text:
Wikijunior:Famous Inventors/Title Page

Wikijunior

Famous Inventors

Written by

Mr. Jsigler's class

along with

The Volunteers and Editors at

Wikibooks.org

A Wikimedia Foundation Project

title: Wikijunior:Famous Inventors/Title Page


text:
Wikijunior talk:Famous Inventors/Title Page

Does this need a different picture?--Jsigler (talk) 15:53, 3 April 2008 (UTC)


text:
User:Kaustubh

Greetings to all!

I am Kaustubh Samudra.

I basically work on Marathi Language Wikipedia, wiktionary & wikibooks.

All my accounts are listed here

Thank you.

Kaustubh Samudra

title: User:Kaustubh


text:
User talk:Engmohd

Welcome!
Welcome, Engmohd!

Come introduce yourself at the new users page. If you have any questions, you can ask there or contact me personally.-- Herby talk thyme 08:01, 27 March 2008 (UTC)

title: User talk:Engmohd


text:
A-level Physics (Advancing Physics)/Kinematics

Kinematics is the study of how objects move. One needs to understand a situation in which an object changes speed, accelerating or decelerating, and travelling a certain distance. There are four equations you need to be able to use which relate these quantities.

Variables
Before we can understand the kinematic equations, we need to understand the variables involved. They are as follows:
 * t is the length of the interval of time being considered, in seconds.
 * v is the speed of the object at the end of the time interval, in ms−1.
 * u is the speed of the object at the beginning of the time interval, in ms−1.
 * a is the acceleration of the object during the time interval, in ms−2. Has to be a constant.
 * s is the displacement (distance traveled) of the object during the time interval, in meters.

Equations
The four equations are as follows:

1. $$v = u + at\,$$

2. $$s = \frac{u + v}{2} t$$

3. $$s = ut + \frac{at^2}{2}$$

4. $$v^2 = u^2 + 2as\,$$

Derivations
It is also useful to know where the above equations come from. We know that acceleration is equal to change in speed per. unit time, so:

$$a = \frac{v-u}{t}$$ (*)

$$at = v - u\,$$

$$v = u + at\,$$ (1)

We also know that the average speed over the time interval is equal to displacement per. unit time, so:

$$\frac{u + v}{2} = \frac{s}{t}$$

$$s = \frac{u + v}{2} t$$ (2)

If we substitute the value of v from equation 1 into equation 2, we get:

$$s = \frac{u + (u + at)}{2}t = \frac{2u + at}{2}t = t(u + \frac{at}{2}) = ut + \frac{at^2}{2}$$ (3)

If we take the equation for acceleration (*), we can rearrange it to get:

$$at = v - u\,$$

$$t = \frac{v - u}{a}$$

If we substitute this equation for t into equation 2, we obtain:

$$s = \frac{u + v}{2}\frac{v - u}{a} = \frac{(v + u)(v - u)}{2a} = \frac{v^2 - u^2}{2a}$$

$$2as = v^2 - u^2\,$$

$$v^2 = u^2 + 2as\,$$ (4)

Questions
1. A person accelerates from a speed of 1 ms−1 to 1.7 ms−1 in 25 seconds. How far has he travelled in this time?

2. A car accelerates at a rate of 18 kmh−2 to a speed of 60 kmh−1, travelling 1 km in the process. How fast was the car travelling before it travelled this distance?

3. A goose in flight is travelling at 4 ms−1. It accelerates at a rate of 1.5 ms−2 for 7 seconds. What is its new speed?

4. How far does an aeroplane travel if it accelerates from 400 kmh−1 at a rate of 40 kmh−2 for 1 hour?

/Worked Solutions/


text:
User:Starvinghog~enwikibooks

English Major from Auburn University. Working for Peace Corps in Azerbaijan. Enjoy reading fiction. Would like to make more study guides.

Favorites include: Faulkner, Hemmingway

title: User:Starvinghog~enwikibooks


text:
User:Riana

Hi, I'm Riana from Commons and the English Wikipedia. Mostly my contributions here will be in my capacity as a Commons administrator.

title: User:Riana


text:
A-level Physics (Advancing Physics)/Kinematics/Worked Solutions

'''1. A person accelerates from a speed of 1 ms−1 to 1.7 ms−1 in 25 seconds. How far has he travelled in this time?'''

u = 1, v = 1.7, t = 25

$$s = \frac{u + v}{2}t = \frac{1 + 1.7}{2} \times 25 = 1.35 \times 25 = 33.75\mbox{m}$$

'''2. A car accelerates at a rate of 18 kmh−2 to a speed of 60 kmh−1, travelling 1 km in the process. How fast was the car travelling before it travelled this distance?'''

a = 18, v = 60, s = 1

v2 = u2 + 2as

602 = u2 + (2 x 18 x 1)

3600 = u2 + 36

u2 = 3564

u = 59.7kmh−1 (to 3 significant figures)

'''3. A goose in flight is travelling at 4 ms−1. It accelerates at a rate of 1.5 ms−2 for 7 seconds. What is its new speed?'''

u = 4, a = 1.5, t = 7

v = u + at = 4 + (1.5 x 7) = 14.5 ms−1

4. How far does an aeroplane travel if it accelerates from 400 kmh−1 at a rate of 40 kmh−2 for 1 hour?

u = 400, a = 40, t = 1

$$s = ut + \frac{at^2}{2} = (400 \times 1) + \frac{40 \times 1^2}{2} = 420\mbox{km}$$


text:
User talk:Riana

Welcome!
Welcome, Riana!

Come introduce yourself at the new users page. If you have any questions, you can ask there or contact me personally.-- Herby talk thyme 10:40, 27 March 2008 (UTC)

title: User talk:Riana


text:
User talk:Starvinghog~enwikibooks

Welcome message
Welcome, Starvinghog!

Come introduce yourself at the new users page. If you have any questions, you can ask there or contact me personally. Webaware talk 11:21, 27 March 2008 (UTC)

Your account will be renamed
Hello,

The developer team at Wikimedia is making some changes to how accounts work, as part of our on-going efforts to provide new and better tools for our users like cross-wiki notifications. These changes will mean you have the same account name everywhere. This will let us give you new features that will help you edit and discuss better, and allow more flexible user permissions for tools. One of the side-effects of this is that user accounts will now have to be unique across all 900 Wikimedia wikis. See the announcement for more information.

Unfortunately, your account clashes with another account also called Starvinghog. To make sure that both of you can use all Wikimedia projects in future, we have reserved the name Starvinghog~enwikibooks that only you will have. If you like it, you don't have to do anything. If you do not like it, you can pick out a different name.

Your account will still work as before, and you will be credited for all your edits made so far, but you will have to use the new account name when you log in.

Sorry for the inconvenience.

Yours, Keegan Peterzell Community Liaison, Wikimedia Foundation 23:47, 17 March 2015 (UTC)

Renamed
 This account has been renamed as part of single-user login finalisation. If you own this account you can |log in using your previous username and password for more information. If you do not like this account's new name, you can choose your own using this form after logging in: . -- Keegan (WMF) (talk) 05:32, 19 April 2015 (UTC)

title: User talk:Starvinghog~enwikibooks


text:
Mewa User's Guide/Getting started

Overview

At the center of the UI is a node-graph. In the screenshot above the node-graph has 2 nodes connected to each other through a curved line. The connection represents the data flow. Data flowing through the nodes are video or images. Each node applies some processing to the input data.

Each node has 2 buttons, a squared button on the left and a circled button on the right. Note that left button is green when toggled and the right button is blue when toggled. The same green and blue is used together with the node name at the top left of the screenshot.

Understanding the Node-graph
In the explanation below we will use sketch images instead of Mewa screenshots to bring to attention only the graphical features necessary to understand Mewa.

In the node-graph data flows from top down. If the top most node is a video, the nodes below, connected to it, apply a filter to all frames of the video.

The sketches below show a node-graph with 3 nodes. The top most node represents a video. The node below adds a star on top of the video, and the last node adds a circle on top of the video+star.

When toggling the node left button (green button), the output of the respective node is shown on the output window (window at the left).

When toggling the “Add Star” node parameters (blue button), the parameters window appears, as the controls that allow resizing the star appear in the output window.

Understanding the Time-view
The node-graph, as seen above, behaves the same for all frames. To change the node-graph behaviour for different frames, through time, we use the time-view

The sketches below show a node-graph with 2 nodes. The video node at the top represents a video file, and the Move2D node below applies a resize/scaling to the video file.

The scale values are shown in the node window (also called node parameters window).

The user can change the scale values by changing the values on the parameters window and/or resizing the image in the output window.

To animate the image size we create a curve. The curve holds the scale values for each frame. The user navigates through frames dragging the play head.

Installing Mewa
Although Mewa is currently only available for Linux and Windows, it aims to run across all platforms, including iOS and Android tablets, MacOS and chromebooks.

On Linux
To install Mewa on Linux, for the first time, just run the following command:

sudo snap install mewa --edge --devmode

That's it, now just type mewa on your command window to start the application.

Update
If Mewa is already installed on your machine, type instead:

sudo snap refresh mewa --devmode

On Windows
There are 2 ways of installing Mewa on windows
 * 1) Through the Microsoft Store
 * 2) Through Mewatools.com
 * 3) * Note that installing Mewa from Mewatools requires installing a certificate. Download and open the file certificate.cer. Click on "Install Certificate" to local machine (not Current User) and then choose "Place all certificates in the following store" option. Choose "Trusted Root Certification Authorities" to complete the installation.

Troubleshooting
Mewa is an OpenGL application and in some windows machines the OpenGL driver needs to be updated. If nothing is shown when you start Mewa application that's because you need to update the OpenGL drivers.

One way to update the OpenGL graphics driver is:

 * 1) Open Device Manager
 * 2) Expand Display adapters and then right click the graphics driver to Update driver
 * 3) Try to Search automatically for the updated driver software

If the above method doesn't work the drivers needs to be updated manually:
 * 1) Navigate to your graphics card manufacturer official website. (Intel, AMD or NVIDIA)
 * 2) On the official site, navigate to the graphics driver and choose your operating system. Download the latest drivers for your graphics card and install it to your computer. This will also update the OpenGL on your computer.

First run
Now that we have installed Mewa, let's try it.

Install Nodes
Mewa comes with very few nodes by default, so, lets extend Mewa with some nodes. Click on to open the Mewa Store. Below is a screenshot of the Mewa Store window.

Scroll through the list of available addons and click install to the addons of your choice. Mewa addons are scripts that are copied to the scripts directory. You can modify/customize any node by modifying the reespective script in the scripts directory.

All available scripts are listed in the nodes list.

Importing footage
Mewa performs operations over images, and these can be still images or videos. For a more generic term we will call it footage.

Let's start importing footage by clicking in the action bar. This will open the File Browser.

Below is a screenshot of Mewa with the File Browser open.

With the File Browser it's possible to load video files and image sequences as well. An image sequence is a group of files which are consecutively numbered.

Press ok after selecting the footage you wish to import.

Once the footage has been imported it appears as a new node in the node graph.

Add nodes to build a node-graph
We have now our first node in the node graph, a footage node.

Let's view how the footage node is layed out in the time-view. Click on to expand the time-view and see the curve editor. At the top of the curve editor there is the curve or bar switch. This switch button offers the choice to see curves as curves or horizontal tracks. The horizontal tracks are nothing more than the same curves constrained within a track. The track scale allows changing curves frames/times without affecting it's y value.

Every footage node has a frame index parameter initialized with a linear curve that goes from 0 to N, where N is the number of frames. The frame index curve tells which image of the footage node is outputed for every given input frame number. Horizontally shifting the footage curve changes the frame at wich the footage node starts. The footage length can be trimmed by dragging the right end of the curve.

Now let's add an effect to our footage node. In the action bar, at the top, click on the node library button to see the list of available nodes.

Select the HexPixelate option. A new node called HexPixelate is shown next to the footage button.

Nodes can be dragged and moved anywhere inside the nodegraph window. Drag the hexagonalPixelate0 node below the footage node. To apply the HexPixelate effect on the footage node connect the footage node output to the input of hexPixelate as shown in the spicture below. Connections describe the workflow execution. The workflow is executed in a top down order, from outputs to inputs.

Inside the nodes there are 2 buttons. On the left side, with a rectangular shape is the output button. On the right side, with a circular shape is the parameters button. With the node buttons we can inspect the output of nodes. The parameter button opens the node's parameters window containing all the modifiable parameters of the node.

Inspect the Output
Clicking on the output button of HexPixelate node (the square button on the left side of the node) the output window opens showing the output of HexPixelate node.

The output window shows the output image of the last clicked output button.

Notice that the output image has a red rectangle around it. The red rectangle represents the output size. Processing operations are preformed inside the red rectangle only.

That size is set in the bottom right corner of the output window. The output size determines the output image size of all nodes.

Final note
The node graph provides a top down "schematic" view of operations applied over images. With an image (footage node) as the top most node, image processing operations are performed by the connected nodes below. Image data is passed top-down, from one node to the next node connected to it. This structure of nodes illustrates the operations and the order of operations applied.

The advantage of using a node graph is it makes possible to edit the parameters of any node while visualising the output of any node simultaneously.

Back to contents page

title: Mewa User's Guide/Getting started