Invasion of host erythrocytes is essential to the life cycle of Plasmodium parasites and development of the pathology of malaria. The stages of erythrocyte invasion, including initial contact, apical reorientation, junction formation, and active invagination, are directed by coordinated release of specialised apical organelles and their parasite protein contents 1 . Among these proteins, and central to invasion by all species, are two parasite protein families, the reticulocyte-binding protein homologue (RH) and erythrocyte-binding like (EBL) proteins, that mediate host-parasite interactions 2 . RH5 from Plasmodium falciparum (PfRH5) is the only member of either family demonstrated to be necessary for erythrocyte invasion in all tested strains, through its interaction with the erythrocyte surface protein basigin (CD147, EMMPRIN) 3 , 4 . Indeed, antibodies targeting PfRH5 or basigin efficiently block parasite invasion in vitro 4 - 9 , making PfRH5 an excellent vaccine candidate. Here we present crystal structures of PfRH5 in complex with basigin and two distinct inhibitory antibodies. PfRH5 adopts a novel fold in which two three-helical bundles come together in a kite-like architecture, presenting binding sites for basigin and inhibitory antibodies at one tip. This provides the first structural insight into erythrocyte binding by the Plasmodium RH protein family and identifies novel inhibitory epitopes to guide design of a new generation of vaccines against the blood-stage parasite.
Each Plasmodium species contains at least one RH protein. These are often large, of low sequence complexity and with no homology to proteins of known structure. PfRH5 is unusual in being significantly shorter than its homologues (~60kDa for PfRH5 vs 200-375kDa for other RH proteins). It lacks their C-terminal transmembrane segment, but associates peripherally with the membrane and with PfRH5 interacting protein (PfRipr) 10 . Although it shares only ~20% pairwise sequence identity with other PfRH proteins 3 , 11 , PfRH5 is remarkably conserved, with only five common non-synonymous single nucleotide polymorphisms (SNPs) 7 , 8 , 12 . Crucially, antibodies raised against one PfRH5 variant neutralise parasites of all tested heterologous strains, containing these and other less common SNPs 6 , 8 , and anti-PfRH5 monoclonal antibodies that prevent parasite growth in vitro can directly block the PfRH5:basigin interaction 5 . Moreover, acquisition of anti-PfRH5 antibodies during natural infection correlates with clinical outcome and these antibodies can inhibit parasite growth in vitro 13 . These findings have generated intense excitement about PfRH5 as a next-generation blood-stage malaria vaccine target and emphasised the need for structural information to guide rational immunogen design.
Structural studies of PfRH5 required a protein construct lacking flexible regions but still capable of binding basigin. Long disordered regions were predicted within residues 1-140 and 248-296 ( Extended Data Fig. 1a), and in cultured parasite lines, PfRH5 is processed by removal of the N-terminus to generate a ~45 kDa fragment 3 , 10 . We therefore designed PfRH5ΔNL, encompassing residues 140-526 but lacking 248-296, and showed it to bind basigin by surface plasmon resonance (SPR) with an affinity of 1.3 μM ( Fig. 1C), comparable to the affinity of full-length PfRH5 for basigin (1.1μM) 4 .
To ensure that PfRH5ΔNL contains epitopes required to elicit an inhibitory immune response, we raised rabbit polyclonal IgG and tested their ability to neutralise parasites by a growth-inhibitory activity (GIA) assay ( Fig. 1D). IgG raised against PfRH5ΔNL protein showed a potent inhibitory effect, similar to that of IgG raised by immunisation of rabbits with viral vectors expressing full-length PfRH5 6 , or full-length PfRH5 recombinant protein 8 , 9 . We also tested binding of PfRH5ΔNL to a panel of mouse monoclonal antibodies previously characterized for PfRH5 binding and growth-inhibitory activity 5 . PfRH5ΔNL bound to growth-inhibitory antibodies including QA1, QA5, and 9AD4, but not to non-inhibitory 4BA7 and RB3 ( Extended Data Fig. 2). Thus, PfRH5ΔNL induces a growth-inhibitory immune response, and contains the epitopes targeted by inhibitory antibodies.
For structural studies, PfRH5ΔNL was mixed with basigin or fragments of growth-inhibitory monoclonal antibodies, 9AD4 or QA1. The complexes were trimmed using GluC protease and lysines chemically methylated before crystallisation. Crystals formed and data were collected to 3.1Å (PfRH5ΔNL:basigin), 2.3Å (PfRH5ΔNL:9AD4) and 3.1Å resolution (PfRH5ΔNL:QA1). Structures were determined using molecular replacement ( Extended Data Table 1 ).
PfRH5 adopts a rigid, flat, ‘kite-shaped’ architecture with a pseudo-two-fold rotation symmetry and no similarity to known structures ( Fig. 1A). Each half is predominantly built from a three helical bundle, with the outermost helices containing significant kinks or breaks. The N-terminal half begins with a short, two-stranded β-sheet that crosses the long axis of the kite at its centre. This is followed by a single, short helix and two long, kinked helices connected by the truncated loop (containing 58 residues in full-length PfRH5). The C-terminal half is simpler, consisting of three long helices that span the entire length of the domain and finishing with a flexible C-terminus. One disulphide bond (C345-C351) stabilises the loop that links the two halves of the structure, while another links the second and third helices (C224-C317), leaving one unpaired cysteine (C329).
PfRH5 is predominantly rigid, with five copies in the three different crystal forms aligning with an rmsd of 0.9Å over 95% of residues ( Extended Data Fig. 1b). Only the C-terminus (residue 496-end) and the loop linking helices 4 and 5 (residues 396-406) adopt different positions in different crystal forms. A molecular envelope derived from small angle X-ray scattering (SAXS) analysis of full-length PfRH5 in solution exhibits a similar flat structure ( Fig. 1B, Extended Data Figure 3). This envelope is elongated relative to PfRH5ΔNL, most likely due to residues missing in this construct or not ordered in the crystal structure (22 residues at the C-terminus, the flexible loop, and perhaps part of the extended N-terminus).
As members of the Plasmodium RH family share little sequence identity, sequence alignments and structure-based threading were used to predict whether other members contain the PfRH5 fold. In each protein analysed ( P. falciparum RH1, RH2a, RH2b, RH3 and RH4; P. vivax RBP-1 and RBP-2; P. reichenowi RH5; and P. yoelii Py01365), N-terminal PfRH5-like domains were identified with high confidence, despite sequence identities of 14-22% and a lack of totally conserved residues or disulphide bonds ( Extended Data Fig. 4a). Similar residues are located primarily in the interior of the domain, where they may stabilise the fold ( Extended Data Fig. 4b). In PfRH4, the only other RH protein with a known erythrocyte receptor, the complement receptor 1 (CR1) binding fragment contains the putative PfRH5 fold 14 . These PfRH5-like domains are therefore excellent candidates for ligand-binding modules in other RH proteins.
Basigin binds at the tip of PfRH5, distant from the flexible loop and C-terminus, with both domains and the intervening linker directly contacting PfRH5 ( Fig. 2A,D). Most of the contact area (~1350 Å 2) occurs through hydrogen bonds between the backbone of strands A and G of the basigin N-terminal domain and loops at the tip of PfRH5 ( Extended Data Table 2a ). PfRH5 residues F350 and W447 stabilise this interaction by packing into hydrophobic pockets on basigin. The limited involvement of basigin side chains will reduce the potential for basigin escape mutants that prevent PfRH5 binding and impair parasite invasion.
The basigin C-terminal domain and H102 in the linker also directly contact PfRH5 ( Extended Data Table 2a ). The three loops at the tip of the basigin C-terminal domain (linking strands B and C, strands D and E and strands F and G) interact with the second and fourth helices of PfRH5 through hydrogen bonds and a hydrophobic patch contributed by residues VPP from the BC loop. However, flexibility of the basigin linker allows different orientations of the C-terminal domains in the two copies in the asymmetric unit of the crystal. Chain B interacts through the BC and DE loops (a ~650 Å 2 interface) while chain D interacts through the BC and FG loops (~480 Å 2) ( Fig. 2b), leading to a maximum difference of ~18Å in the position of the C-terminus in the two complexes. Flexibility is also predicted from SAXS analysis of the complex in solution ( Extended Data Fig. 3). While PfRH5 and the basigin N-terminal domain fit the SAXS envelope, the C-terminal domain only partially fits, consistent with a flexible interaction with PfRH5.
PfRH5 is highly conserved, with just twelve non-synonymous SNPs in 227 field isolates, and only five at frequencies of 10% or greater 7 , 8 , 12 . These SNPs are distributed across the structure but do not affect residues that directly contact basigin ( Extended Data Fig. 5). By contrast, in sequenced laboratory strains, eight PfRH5 SNPs are associated with increased ability to invade Aotus erythrocytes 15 , 16 . A number of these (I204, N347, Y358 and E362) are in or close to the basigin binding site, and may affect host tropism. Basigin residues which, when mutated, affect PfRH5 affinity (F27, Q100 and H102) 17 are also located at the interface.
The two PfRH5:basigin complexes in the asymmetric unit pack together through basigin-mediated contacts, including a ~911 Å 2 interface between the two basigin C-terminal domains, bringing their C-termini into close proximity ( Extended Data Fig. 6). As yet, the role of PfRH5 in invasion is uncertain, but it is tempting to speculate that this 2:2 complex assembles during invasion, mediating a signalling event in either parasite or erythrocyte to trigger an essential downstream process. This would leave one face of PfRH5 available for binding of PfRipr 10 and other, as yet unidentified, binding partners. However, in solution (at concentrations ≤24 μM) we observe no 2:2 complex, either through SAXS ( Extended Data Fig. 3) or analytical ultracentrifugation ( Fig. 2C, Extended Data Fig 7). Whether such a complex assembles at high local concentrations during invasion remains to be elucidated.
To identify inhibitory epitopes, complexes of PfRH5ΔNL with Fab fragments from three inhibitory monoclonal antibodies were studied by crystallography and SAXS. QA1 and QA5 were previously shown to block PfRH5-basigin binding and parasite growth. 9AD4 does not block PfRH5-basigin binding in vitro, but is one of the most effective antibodies currently available for inhibiting parasite growth 5 . Crystal structures of PfRH5 bound to QA1 and 9AD4 were confirmed by SAXS, while a model for PfRH5:QA5 was derived from SAXS analysis, guided by a previously identified linear epitope (residues 201-213 from helix 2) 5 .
The antibodies bind to three distinct sites, close to the vertex of PfRH5 ( Fig. 3, Extended Data Fig. 8, Extended Data Table 2b,c ). QA1 binds to loops at the PfRH5 tip, overlapping the basigin N-terminal domain binding site. QA5 predominantly interacts with PfRH5 helix 2, overlapping the basigin C-terminal domain binding site. In contrast, 9AD4 binds helices 2 and 3, close to, but not overlapping, either basigin binding site. This is likely to allow intact 9AD4 IgG to impede erythrocyte binding when PfRH5 and basigin are both membrane-tethered. This reveals inhibitory epitopes in, or close to, the basigin binding sites, that can be targeted to block parasite invasion.
In summary, PfRH5 adopts a novel architecture, formed, as in many families of parasite surface proteins 18 , from a robust α-helical scaffold. This maintains the overall fold by retaining residues required for helical packing, while allowing significant surface sequence variation. Sequence homology identifies this fold at the N-terminus of other RH proteins, where it is likely to act as a ligand-binding module.
Characterisation of the PfRH5:basigin complex prompts a range of future experiments to investigate the role of PfRH5 in erythrocyte invasion. Furthermore, monoclonal antibodies that block parasite growth bind at or close to the basigin-binding site. Immunogens containing these regions of PfRH5 will be important components of a vaccine to prevent P. falciparum erythrocyte invasion, thereby crippling the parasite responsible for the deadliest form of human malaria.
A section of the basigin gene encoding immunoglobin domains 1 and 2 of the short isoform (residues 22-205) was amplified from cDNA using primers: 5′-CCGGATCCGCTGCCGGAACCGTGTTC-3′ and CCCATATGCTAGTGTGACCGCACTCTCAGG-3′. PCR products were cloned into a modified pET15b vector (Novagen), which encodes an N-terminal hexa-histidine tag followed by a tobacco etch virus (TEV) protease cleavage site. TEV cleavage leaves an additional glycine at the N-terminus from the cleavage site.
Basigin was expressed in bacterial strain Origami B (DE3) (Novagen) by incubation overnight at 25°C after induction with 1mM IPTG. The protein was purified by nickel-nitrilotriacetic acid (Ni 2+-NTA; Qiagen) affinity chromatography, followed by buffer exchange into PBS using a PD-10 desalting column (GE Healthcare), and overnight cleavage with His-tagged TEV protease at 4°C, before a second Ni 2+-NTA column. The flow-through was concentrated using an Amicon Ultra centrifugal filter device (molecular mass cutoff, 3,000 Da). Finally, gel filtration was performed with a Superdex 200 16/60 column (GE Healthcare) in 20 mM HEPES (pH 7.5) and 150 mM NaCl.
Anti-PfRH5 monoclonal antibodies were described previously 5 . Hybridomas expressing 9AD4, QA1 and QA5 were grown in Dulbecco’s Modified Eagle’s Medium (DMEM; Sigma) supplemented with 4 mM L-glutamine (Sigma), 0.01 M HEPES (Life Technologies), 100 U penicillin and 0.1 mg/ml streptomycin (Sigma), and 20% fetal calf serum (Gibco). They were then transferred into CD Hybridoma medium (Life Technologies) with glutamine, penicillin, and streptomycin. The cells were harvested after 7-10 days. The cell culture supernatant was exchanged into 20 mM phosphate pH 7.0 with a tangential flow filtration device (Pall).
The sample was then loaded onto a HiTrap Protein G HP column (GE Healthcare), eluted in 0.1 M glycine-HCl (pH 3.0), and immediately neutralised with 0.1 M Tris (pH 8.0). The sample was exchanged into 100 mM phosphate (pH 6.4), 300 mM NaCl, 2 mM EDTA, 5 mM L-cysteine (pH 6.4), and 1.5 mM β-mercaptoethanol using PD-10 columns (GE Healthcare).
Antibody fragments were generated by addition of papain agarose (Sigma), and overnight incubation at 37°C. The papain agarose was removed by centrifugation, and the sample loaded onto a HiTrap Protein A HP column (GE Healthcare). The material that did not bind to the column was gel filtered on a Superdex 200 16/60 column (GE Healthcare) in 20 mM HEPES (pH 7.5) and 150 mM NaCl.
A synthetic gene was designed encoding full-length PfRH5 residues E26-Q526 from Plasmodium falciparum strain 7G8, codon optimised for expression in Drosophila melanogaster, with four putative glycosylation sites removed by mutation of asparagines to alanines (Life Technologies). The gene was flanked by an EcoRI site and Kozak sequence at the 5′ end, and a NotI site at the 3′ end. Long-range disorder was predicted using POODLE-L 19 . A shortened mutant, PfRH5ΔN, lacking the flexible N-terminus, was also synthesised, encompassing residues K140-Q526. A further mutant, PfRH5ΔNL, was generated by removal of a predicted disordered loop (residues N248-M296) in addition to the N-terminal truncation. All constructs contained a C-terminal hexa-histidine tag. PfRH5 constructs were subcloned into pExpreS 2-1 (ExpreS 2ion Biotechnologies, Horsholm, Denmark).
Constructs were transfected into Schneider 2 (S2) cells using ExpreS 2 Insect-TRx5 (ExpreS 2ion) transfection reagent, and a polyclonal cell line was selected over three weeks in EX-CELL 420 insect cell media with L-glutamine (Sigma) supplemented with 10% fetal calf serum (Gibco) and 1.5 mg/ml zeocin. The stable cell lines were then expanded in EX-CELL 420 media without fetal calf serum or zeocin. Four days after the final split, the cells were harvested, and the cell culture supernatant exchanged into 20 mM phosphate, pH 7.4, 250 mM NaCl, 20 mM imidazole, and 0.005% Tween-20, using a tangential flow filtration device (Pall). Protein purification from the supernatant then proceeded through Ni 2+-NTA (HisTrap FF; GE Healthcare) and ConA lectin-binding chromatography (HiTrap ConA 4B; GE Healthcare).
Full-length PfRH5, PfRH5ΔN and PfRH5ΔNL for biophysical analysis were subjected to gel filtration on a Superdex 200 16/60 column (GE Healthcare), and concentrated with an Amicon centrifugal filter device (molecular weight cut-off, 10,000 Da).
To prepare PfRH5ΔNL for crystallisation, the sample was cleaved overnight with endoproteinase GluC (Sigma) at 20°C. At this point, basigin, 9AD4, or QA1 was added to the protein. To methylate the complex, 0.02 M dimethylamine-borane complex (ABC) and 0.04 M formaldehyde were added and the reaction incubated at 4°C for 1 hour. An additional 0.02 M ABC and 0.04 M formaldehyde were added; after another 1 hour, 0.01 M ABC was added and the reaction was incubated at 4°C overnight. Finally, the complexes were gel filtered and concentrated as detailed above.
Surface plasmon resonance experiments were carried out using a BIAcore T200 instrument
(GE Healthcare). Experiments were performed at 20°C in 10 mM HEPES (pH 7.4), 150 mM
NaCl, 3 mM EDTA, 0.005% Tween 20, 2 mg/ml dextran, and 1 mg/ml salmon sperm DNA (Sigma
Aldrich). Basigin was immobilized on a CM5 chip (GE Healthcare) by amine coupling
(GE Healthcare kit) to a total of 850 RU. A concentration series of PfRH5ΔNL (8, 4,
2, 1, 0.5, 0.25, 0.125, and 0.0625 μM) was injected over the basigin-coated chip for
120 s at 30 μl/min, followed by a 300 s dissociation time. The chip surface was then
regenerated with 30 s of 2 M NaCl. Specific binding of PfRH5ΔNL was obtained by subtracting
the response from a blank surface from that of the basigin-coated surface. The kinetic
sensorgrams were fitted to a global 1:1 interaction model, allowing determination
of the dissociation constant,
K
Rabbit immunisations were carried out by Biogenes (Germany). Female ZiKa rabbits (n=4) were immunised intramuscularly (i.m.) with 20μg PfRH5ΔNL protein formulated in complete Freund’s adjuvant on day 0, followed by two booster immunisations i.m. on days 28 and 56 with the same dose of protein formulated in incomplete Freund’s adjuvant. Control rabbits received the same immunisation schedule with 50μg ovalbumin protein. Sera were collected two weeks after the final immunisation and shipped frozen.
Total IgG was purified from rabbit sera using protein G columns (Pierce). The P. falciparum 3D7 and 7G8 lines were maintained in continuous culture using fresh O + erythrocytes at 2% haematocrit and synchronised by two incubations in 5% sorbitol 6-8 h apart. Synchronised trophozoites were adjusted to 0.3% parasitaemia and then incubated for 42 h with the various IgG concentrations (tested in triplicate). Final parasitaemia was determined by biochemical determination of parasite lactate dehydrogenase 20 . Percentage growth inhibition is expressed relative to wells containing IgG from control immunised rabbits 6 . The mean of the three replicate wells was taken to obtain the final data for each individual rabbit at each tested IgG concentration. Experiments were performed twice against each strain of parasite with very similar results. A representative experiment is shown in Fig. 1D. The mean ± standard error of mean are plotted for the results obtained with the purified IgG from the four immunised rabbits.
Maxisorp plates were coated with anti-PfRH5 mouse monoclonal antibody 5 (50μL/well at 5μg/mL) and left at 4°C overnight. Following six washes in PBS with 0.05% Tween-20 (PBS-T), plates were blocked with 150 μL/well Casein block solution (Pierce) for 1 h, followed by another six PBS-T washes. PfRH5ΔNL protein was added to wells in triplicate (50 μL/well) at four dilutions in blocking buffer (800, 200, 50 and 12.5 ng/mL) and incubated at room temperature for 2 h. Following another six PBS-T washes, plates were incubated with polyclonal anti-full-length PfRH5 rabbit serum 6 diluted 1:1000 in blocking solution, 50 μL/well for 1 h. Following another PBS-T wash, plates were incubated with goat anti-rabbit IgG alkaline phosphatase diluted 1:5000 in blocking solution, 50 μL/well for 1 h. Following a final six PBS-T washes, and two PBS washes, plates were developed and optical density read at 405nm as previously described 21 .
Crystallisation was achieved using vapour diffusion in sitting drops. A TTP Labtech Mosquito LCP robot was employed to mix 100 nl of each protein complex at 8 mg/ml with 100 nl of well solutions from commercially available crystal screens. Crystals were first obtained in conditions from the Proplex (RH5ΔNL:basigin), JCSG+ (RH5ΔNL:9AD4) and Morpheus (RH5ΔNL:QA1) crystal screens (Molecular Dimensions). The well solution for PfRH5ΔNL:basigin was 0.2 M lithium sulphate, 0.1 M MES (pH 6.0), and 20% (w/v) PEG 4000. For PfRH5ΔNL:9AD4, the well solution was 24% (w/v) PEG 1500 and 20% (v/v) glycerol. PfRH5ΔNL:QA1 was crystallised in a 0.12 M mix of 1,6-hexanediol, 1-butanol, 1,2-propanediol, 2-propanol, 1,4-butanediol, 1,3-propanediol; 0.1 M MES-imidazole (pH 6.5); 20% (w/v) PEG 550 MME; and 10% (w/v) PEG 20,000. Crystals were obtained at 4°C for PfRH5ΔNL:basigin and PfRH5ΔNL:9AD4, and at 18°C for PfRH5ΔNL:QA1. Crystal seeds were generated by adding crystals in well solution to a Seed Bead (Hampton Research) and vortexing for 15 seconds. New crystal drops were then set up by mixing 100 nl of 8 mg/ml protein complex, 50 nl of well solution, 50 nl of seeds, and 50 nl of Silver Bullets or Silver Bullets Bio additives (Hampton Research). RH5ΔNL:basigin crystals were cryoprotected by transfer into well solution supplemented with 25% ethylene glycol, then cryocooled by plunging into nitrogen. PfRH5ΔNL:9AD4 crystals were directly cryocooled. PfRH5ΔNL:QA1 crystals were cryoprotected in well solution with a total of 32% (w/v) PEG 550 MME and 16% (w/v) PEG 20,000 before cryocooling.
Data were collected at the Diamond Light Source, on beamline I04-1 for the PfRH5ΔNL:basigin complex (wavelength 0.92 Å), and on beamline I04 for both PfRH5ΔNL:Fab complexes (wavelength 0.97949 Å). Data reduction was performed using iMosflm 22 , 23 and scala 24 from the CCP4 processing suite 25 . A composite of the light chain from PDB entry 3QQ9 and the heavy chain from 3HR5 was used as a molecular replacement model for 9AD4 in Phaser 26 . Density modification was performed with PARROT 27 . Buccaneer 28 was employed to build helices into initial PfRH5ΔNL density, initiating a cycle of model building and refinement using REFMAC 29 , BUSTER 30 , and Coot 31 . PfRH5ΔNL was used as a molecular replacement model in Phaser 26 , together with basigin (PDB code 3B5H) for the PfRH5ΔNL:basigin structure, or with a composite of the heavy chain from 2ZN9 and the light chain from 1I7Z for the PfRH5ΔNL:QA1 structure. Refinement was accomplished with BUSTER 30 . Ramachandran statistics, determined using PROCHECK 32 , were as follows: for PfRH5ΔNL:basigin, 93% of residues fell in the allowed regions and 7% in the additional allowed region; for PfRH5ΔNL:9AD4, 93.9% were in the allowed region, 5.8% were in the additional allowed region, and 0.2% were in the generously allowed region; and for PfRH5ΔNL:QA1, 86.0% were in the allowed region, 13.3% were in the additional allowed region, and 0.7% were in the generously allowed region. There were no residues in the disallowed region of the Ramachandran plot in any of the structures.
Sequences of P. falciparum RH1, RH4, RH2a, RH2b, and RH3; P. vivax RBP-1 and RBP-2; P. reichenowi RH5; and P. yoelii Py01365 were aligned against PfRH5 using the Clustal Omega server 33 , and an alignment figure generated with ESPript 34 . The homologous portion of each sequence was then threaded onto the PfRH5 structure using the Phyre2 server 35 .
Small-angle X-ray scattering (SAXS) data were collected at beamline BM29 at the European Synchrotron Radiation Facility (ESRF, Grenoble, France). Scattering was detected using a Pilatus image reader at 20°C.
Full-length PfRH5:basigin, PfRH5:QA1 and PfRH5:QA5 complexes were prepared by mixing the individual proteins in equimolar amounts, and gel filtering on a Superdex 200 16/60 column in 20 mM HEPES (pH 7.5), 150 mM NaCl. PfRH5:9AD4 samples were prepared by mixing PfRH5 and 9AD4 in equimolar amounts for 10 minutes. 60 μl samples were prepared in serial dilutions between 0.2-2.0 mg/ml.
Ten consecutive frames of 10 s each were recorded for each protein sample, with buffer samples measured in between. The frames were inspected for any evidence of radiation damage, and any affected images were excluded from further processing. Data were normalised to the intensity of the incident beam, images were averaged, and buffer scattering subtracted using PRIMUS 36 , 37 . Guinier plots were inspected to assess the presence of aggregation 38 . Composite curves were generated by scaling and merging appropriate data sets. The radius of gyration (R
Analytical ultracentrifugation experiments were carried out using a Beckman An-60 Ti rotor in a Beckman Optima XL-1 analytical ultracentrifuge at 20°C. Samples were prepared at concentrations of 0.5-1.0 mg/ml in 20 mM HEPES (pH 7.5), and 150 mM NaCl.
The samples for sedimentation velocity experiments were full-length PfRH5, basigin, and a PfRH5:basigin complex prepared by gel filtration. Scans were recorded using interference optics. Multiple scans were fit to a continuous size distribution using SEDFIT 44 , 45 . The buffer density and viscosity were calculated with SEDNTERP 46 . The sample partial specific volumes were estimated from the amino acid sequences, also using SEDNTERP.
During the time course of a sedimentation equilibrium experiment, degradation of full-length PfRH5 was observed. Therefore experiments were performed using PfRH5ΔN. Basigin, PfRH5ΔN and a gel filtered PfRH5ΔN:basigin complex were analysed at 22 μM, 9 μM, and 9 μM, respectively. The run proceeded for 20 hours at different speeds and scans recorded the UV absorbance at 280 nm. The buffer density and viscosity, together with sample partial specific volumes, were calculated as above 46 . The data were fit to an ideal monodisperse model using SEDPHAT 47 , with the assumption that at concentrations of ~10 times the K
a, Long-range disorder was predicted by POODLE-L 19 and was used to determine domain boundaries for the PfRH5ΔNL crystallisation construct. The disorder predictions are shown above the sequence of PfRH5, with values of >0.5 indicative of disorder. The residues visible in the PfRH5ΔNL crystal structure are shown below the PfRH5 sequence as secondary structure elements (sheets as blue arrows, and helices as tubes in rainbow coloring) linked by blue lines. The missing loop (248-296) is shown as a break in the blue line. The secretion signal sequence is indicated (black underline). b, Two copies of PfRH5 from the PfRH5:basigin structure (red and orange), two copies from the PfRH5:QA1 structure (blue and cyan), and one copy from PfRH5:9AD4 (green) structure were aligned using Coot 31 , giving an RMSD of 1.7 Å. The C-terminus and the loop between helices 4 and 5 were the only regions showing significant differences. For the remaining 95% of PfRH5, the RMSD is 0.9 Å.
Five mAbs that bind to PfRH5 were coated on a ELISA plate and probed using PfRH5ΔNL at concentrations of 12.5, 50, 200 or 800 ng/ml. Antibodies 9AD5, QA1 and QA5 interacted with PfRH5ΔNL while RB3 and 4BA7 did not. Indeed, RB3 and 4BA7 bind to the flexible N-terminus and the truncated loop, respectively, both features lacking in PfRH5ΔNL 5 . The error bars are standard error of mean (n=3).
a, The theoretical scattering calculated from the average of 20 ab initio reconstructions (continuous lines, with PfRH5 in orange and PfRH5:basigin in blue) plotted with the experimental scattering intensity curves (diamonds). The data are presented as the natural logarithm of the intensity. Guinier plots are displayed in the inset. b, The distance distribution function, P(r), of PfRH5 (orange) and PfRH5:basigin (blue). c, To the left, the crystal structure of PfRH5ΔNL (yellow) was docked into the average ab initio SAXS envelope of full-length PfRH5 (grey). Extra density corresponding to some or all of the truncated regions is visible at the bottom of the kite-like structure, near the C-terminus. To the right, the crystal structure of PfRH5ΔNL:basigin is docked into the average ab initio SAXS envelope of full-length PfRH5:basigin (grey). PfRH5ΔNL is yellow. In dark blue and cyan are basigin molecules from the two PfRH5ΔNL:basigin complexes in the asymmetric unit, superimposed based on the structure of PfRH5ΔNL. d, Summary of SAXS parameters. The radius of gyration (R
a, P. falciparum RH1, RH4, RH2b, RH2a and RH3 (a pseudogene); P. vivax RBP-1 and RBP-2; P. reichenowi RH5; and P. yoelii Py01365 were aligned using Clustal Omega 33 and were threaded using the Phyre2 server 35 , giving more than 98% confidence of fold conservation over >260 residues in each case. The secondary structure of PfRH5 is shown below the sequence in a rainbow colour scheme as in Fig. 1A. Residues from PfRH5 that interact with basigin, QA1 and 9AD4 are indicated above the sequence by blue, red or green stars respectively. Cysteine residues that make disulphide bonds are indicated by pink numbers, with residues sharing the same number forming a disulphide bond. b, PfRH5 is shown in yellow, with residues similar among RH proteins (from the alignment in extended data figure 4) highlighted as pink sticks. The majority of the similar residues appear to play a structural role stabilising the architecture of the domain.
a and b, Indicated are the locations of PfRH5 SNPs that are common (10% frequency or greater; red sticks) or uncommon (blue sticks) among 227 field isolates 7 , 8 , 12 , as well as additional SNPs observed in lab strains (green sticks) 15 , 16 . b, Basigin (blue) is shown in addition to PfRH5 (yellow). SNPs Y203, I204, N347, Y358, and E362 are localized in or near the PfRH5:basigin interface. Not visible in this orientation is lab strain polymorphism K429. c, Highlighted are basigin residues F27, Q100, and H102, which affect the affinity for PfRH5 when mutated 17 (orange sticks). Also shown are two SNPs of PfRH5, namely N347 and I204 (pink sticks), found in the PfRH5:basigin binding interface and linked to the strain’s ability to invade Aotus monkey erythrocytes 15 .
One complex, shown in yellow (PfRH5) and blue (basigin), interacts with the second, shown in silver (PfRH5) and cyan (basigin), primarily through packing between the two C-terminal domains of basigin. The two C-termini of basigin are in close proximity (top view).
a-b, Sedimentation velocity analysis. The continuous sedimentation coefficient distributions that best fit the data are shown for basigin (top), full-length PfRH5 (middle), and a gel filtered PfRH5:basigin complex (bottom). The inset shows the fitting residuals. c-d, Sedimentation equilibrium analysis. PfRH5ΔN (residues 140-526), basigin, and a gel filtered PfRH5ΔN:basigin complex were analysed. The runs lasted 20 hours at different speeds, as indicated in the inset legends. UV absorbance was monitored at 280 nm. The residuals are shown below fitted data. The calculated molecular weights are consistent with the formation of a 1:1 complex between PfRH5ΔN and basigin.
a, The theoretical scattering calculated from the average of 20 ab initio reconstructions (continuous lines, with PfRH5 in orange, PfRH5:9AD4 in green, PfRH5:QA1 in red, and PfRH5:QA5 in blue) plotted with the experimental scattering intensity curves (black diamonds). The data are presented as the natural logarithm of the intensity. The Guiner plots are displayed in the inset. b, The distance distribution function, P(r), with colours as in a. c, The crystal structures of PfRH5ΔNL:QA1(left) and PfRH5ΔNL:9AD4 (middle) were docked into the corresponding full-length PfRH5:Fab envelopes (grey). PfRH5ΔNL is shown in yellow, QA1 in red, and 9AD4 in green. PfRH5ΔNL and a Fab fragment (cyan) were docked into the PfRH5:QA5 SAXS envelope to generate a model of the PfRH5:QA5 structure (right). d, A summary of SAXS parameters. The radius of gyration (R
| PfRH5△NL:basigin | PfRH5△NL:9AD4 | PfRH5△NL:QAl | |
|---|---|---|---|
| Data collection | |||
| Space group | P2
1 2
1 2
1
|
P2
1 2
1 2
1
|
P22
1 2
1
|
| Cell dimensions | |||
| a, b, c (Å) | 75.28, 109.36, 151.95 | 39.79, 86.66, 324.04 | 65.12, 137.30, 228.58 |
| α,β,γ(°) | 90.00, 90.00, 90.00 | 90.00, 90.00, 90.00 | 90.00, 90.00, 90.00 |
| Resolution (Å) | 67.46 – 3.10(3.27-3.10) | 41.86-2.30 (2.42-2.30) | 47.24-3.10(3.27-3.10) |
|
R
pim
|
0.080 (0.297) | 0.047 (0.375) | 0.049 (0.380) |
| I/σ I | 9.4 (2.7) | 9.8 (2.0) | 9.2 (2.3) |
| Completeness (%) | 99.8 (99.8) | 96.2 (83.3) | 95.5 (96.3) |
| Redundancy | 6.1 (6.2) | 5.0 (4.4) | 4.5 (4.6) |
| Refinement | |||
| Resolution (Å) | 67.46-3.10 | 41.86-2.30 | 47.24-3.10 |
| No. reflections | 23357 | 49336 | 36259 |
|
R
work /
R
free (%)
|
21.71 / 24.45 | 22.10 / 25.83 | 23.6 / 28.1 |
| No. atoms | 7629 | 6005 | 11478 |
| Wilson B-factors | 48.0 | 41.1 | 90.1 |
| R.m.s deviations | |||
| Bond lengths (Å) | 0.010 | 0.014 | 0.013 |
| Bond angles (°) | 1.5 | 1.7 | 1.9 |
| a | ||||||
|---|---|---|---|---|---|---|
|
|
||||||
| PfRH5 | Basigin | |||||
| Chain | Residue | Group | Chain | Residue | Group | Interaction |
| N-terminal domain: | ||||||
|
|
||||||
| A/C | S197 | side chain | B/D | Q100 | side chain NH2 | hydrogen bond |
|
|
||||||
| A/C | S197 | side chain | B/D | E84 | side chain | hydrogen bond |
|
|
||||||
| A/C | F350 | side chain | B/D | hydrophobic | hydrophobic | |
|
|
||||||
| A/C | N352 | side chain CO | B/D | N98 | backbone NH | hydrogen bond |
|
|
||||||
| A/C | N354 | side chain NH2 | B/D | N98 | backbone CO | hydrogen bond |
|
|
||||||
| A/C | R357 | side chain | B/D | V26 | backbone CO | hydrogen bond |
|
|
||||||
| A/C | W447 | side chain | B/D | hydrophobic | hydrophobic | |
|
|
||||||
| A/C | W447 | backbone CO | B/D | T28 | backbone NH | hydrogen bond |
|
|
||||||
| A/C | R448 | side chain | B/D | T25 | side chain | hydrogen bond |
|
|
||||||
| A/C | T449 | side chain | B/D | V26 | backbone NH | hydrogen bond |
|
|
||||||
| A/C | T449 | backbone NH | B/D | V26 | backbone CO | hydrogen bond |
|
|
||||||
| Linker: | ||||||
|
|
||||||
| A/C | Y200 | side chain | B/D | H102 | side chain | hydrogen bond |
|
|
||||||
| C-terminal domain: | ||||||
|
|
||||||
| A/C | hydrophobic | B/D | V131 | side chain | hydrophobic | |
|
|
||||||
| A | hydrophobic | B | P133 | side chain | hydrophobic | |
|
|
||||||
| A | D207 | side chain | B | Q164 | side chain NH2 | hydrogen bond |
|
|
||||||
| C | E362 | side chain | D | K191 | side chain | hydrogen bond |
|
|
||||||
| C | E362 | side chain | D | S190 | side chain | hydrogen bond |
| b | ||||||
|---|---|---|---|---|---|---|
|
|
||||||
| PfRH5 | QA1 | |||||
| Chain | Residue | Group | Chain | Residue | Group | Interaction |
| Heavy chain: | ||||||
|
|
||||||
| A/D | K196 | side chain | B/E | N101 | side chain CO | hydrogen bond |
|
|
||||||
| A/D | K196 | side chain | B/E | D31 | backbone CO | hydrogen bond |
| A/D | S197 | backbone NH | B/E | D53 | side chain | hydrogen bond |
|
|
||||||
| A/D | Y346 | side chain | B/E | Y33 | side chain | pi stacking |
|
|
||||||
| A/D | N348 | side chain CO | B/E | G105 | backbone NH | hydrogen bond |
|
|
||||||
| A/D | N352 | side chain | B/E | Y33 | side chain | hydrogen bond |
|
|
||||||
| A/D | N352 | side chain | B/E | Y59 | side chain | hydrogen bond |
|
|
||||||
| A/D | N354 | backbone NH | B/E | Y57 | side chain | hydrogen bond |
|
|
||||||
| A/D | K452 | side chain | B/E | D104 | side chain | hydrogen bond |
|
|
||||||
| Light chain: | ||||||
|
|
||||||
| A/D | N347 | side chain NH2 | C/F | S95 | backbone CO | hydrogen bond |
|
|
||||||
| A/D | N348 | backbone NH | C/F | Y36 | side chain | hydrogen bond |
|
|
||||||
| A/D | N349 | backbone NH | C/F | Y34 | side chain | hydrogen bond |
|
|
||||||
| A/D | N349 | side chain CO | C/F | W96 | side chain | hydrogen bond |
|
|
||||||
| A/D | F350 | side chain | C/F | hydrophobic | hydrophobic | |
|
|
||||||
| A/D | Q451 | backbone CO | C/F | Y34 | side chain | hydrogen bond |
| c | ||||||
|---|---|---|---|---|---|---|
|
|
||||||
| PfRH5 | 9AD4 | |||||
| Chain | Residue | Group | Chain | Residue | Group | Interaction |
| Heavy chain: | ||||||
|
|
||||||
| A | A205 | backbone CO | B | Y103 | backbone CO | hydrogen bond (H
2 0)
|
|
|
||||||
| A | F209 | side chain | B | hydrophobic | hydrophobic | |
|
|
||||||
| A | Y335 | side chain | B | Y103 | backbone CO | hydrogen bond |
|
|
||||||
| A | N338 | side chain CO | B | W107 | side chain | hydrogen bond |
|
|
||||||
| A | L339 | side chain | B | hydrophobic | hydrophobic | |
|
|
||||||
| A | E341 | side chain | B | S52 | side chain | hydrogen bond |
|
|
||||||
| A | E341 | side chain | B | M54 | backbone CO | hydrogen bond |
|
|
||||||
| A | E341 | side chain | B | A55 | backbone CO | hydrogen bond |
|
|
||||||
| A | E341 | side chain | B | Y56 | backbone CO | hydrogen bond |
|
|
||||||
| A | Q342 | side chain CO | B | N53 | side chain NH2 | hydrogen bond |
|
|
||||||
| A | hydrophobic | B | F101 | side chain | hydrophobic | |
|
|
||||||
| Light chain: | ||||||
|
|
||||||
| A | K212 | side chain | C | Y32 | backbone CO | hydrogen bond |
|
|
||||||
| A | D331 | side chain | C | Y32 | side chain | hydrogen bond |
|
|
||||||
| A | N334 | side chain NH2 | C | Y31 | side chain | hydrogen bond (H
2 0)
|
MKH is a Wellcome Trust Investigator (101020/Z/13/Z). KEW is funded by a Wellcome Trust Ph.D. studentship. SJD holds a UK Medical Research Council (MRC) Career Development Fellowship (G1000527), is a Jenner Investigator and Lister Institute Research Prize Fellow. The project was also funded by the European Vaccine Initiative (EVI) (InnoMalVac); the UK MRC (MR/K025554/1), the European Community’s Seventh Framework Programme (FP7/2007-2013, grant agreement number 242095 – EVIMalaR); a Wellcome Trust Training Fellowship (089455/2/09/z to ADD). We thank Julie Furze and Daniel Alanine (Jenner Institute); David Staunton and Edward Lowe (Department of Biochemistry, Oxford University); Adam Round (ESRF); and Ralf Flaig and Jose Brandao-Neto (Diamond Light Source).
Atomic coordinates and structure factors are deposited at the Protein Data Bank with accession codes 4U0Q, 4U0R and 4U1G.
Reprints and permissions information is available at
The authors declare competing financial interests. ADD, JJI and SJD are named on patent applications relating to PfRH5 and/or other malaria vaccines. WAJ is named on patents relating to Drosophila S2 protein expression and is co-founder of ExpreS 2ion Biotechnologies.
a, Three views of PfRH5ΔNL (from the PfRH5ΔNL:9AD4 structure), and a schematic topology diagram, coloured in rainbow from blue (N-terminus) to red (C-terminus). Disulphide bonds are indicated on the topology diagram by red lines. b, PfRH5ΔNL structure docked into a SAXS envelope of full-length PfRH5. c, SPR analysis of the PfRH5ΔNL:basigin interaction. d, In vitro growth inhibition activity (GIA) of IgG from rabbits immunised with PfRH5ΔNL against 3D7 (red) and 7G8 (blue) P. falciparum strains. The error bars are standard error of mean (n=3).
a, The structure of PfRH5ΔNL (yellow) bound to basigin (blue). b, A top view of the PfRH5ΔNL:basigin complex showing the two conformations of basigin (blue and cyan) found in the asymmetric unit, aligned on PfRH5ΔNL. c, Equilibrium analytical ultracentrifugation analysis of PfRH5:basigin indicating a 1:1 complex. d, Close-up of the PfRH5:basigin binding site. Basigin residues in the N-terminal domain (pink), the linker (His102, orange stick), and the C-terminal domain (green) contact PfRH5 (grey surface). In the alternative basigin conformation in the asymmetric unit, the cyan loop contacts PfRH5.
a, Crystal structures of PfRH5ΔNL (yellow) bound to inhibitory antibody fragments QA1 (red) and 9AD4 (green). Close-up views of the PfRH5 epitopes (red) are shown with antibodies as grey surfaces. b, Top view of PfRH5ΔNL:9AD4 crystal structure with superimposed basigin (blue) aligned on PfRH5. c, Top view of a model of PfRH5:QA5, in a SAXS-derived envelope, with the putative QA5 epitope highlighted red 5 . d, Schematic showing binding sites for the N- and C-terminal domains of basigin (BSG-N and BSG-C; blue), QA1 (red), 9AD4 (green) and QA5 (cyan), on the structure of PfRH5ΔNL.


List of IP Addresses for target virtual machines
MAC Address
IP Address
{% for lease in leases %}
{{ lease.hardware.mac }}
{{ lease.ipaddress }}
{% endfor %}
Powered by
Python
,
Flask
,
Gunicorn
and
Bootstrap
Hacking this app is not part of the class... :(


CISC 360: Computer Architecture - Project 1
In this project, we will design a computer simulator based on the Gemini Microprocessor. The Gemini microprocessor is intentionally designed to have as few performance enhancements as possible and have limited capabilities (Note that this "Gemini" has no relation to Sun's Chip with the Ultra-SPARC). The Gemini documentation covers these topics:
- Instruction set architecture (programmer's model)
- System architecture (microprogrammer's model)
- Datapath (ALU, registers, and memory) and controller (microprogram, microaddress select, and control signals)
- Timing diagrams for latches and memory
Your assignment is to simulate Gemini. This will give you a working knowledge of a general Computer Architecture using tools that you are already very familiar with- at the same time, you get to polish your programming skills! Your first goal is to understand the following Gemini Documentation
Gemini Documentation
Programmer's Model
Gemini is an accumulator-based processor with a single bus connecting the ALU, the accumulator (ACC) and program counter (PC) registers, and main memory. The bus is used for both address and data. The accumulator is the target of the load, arithmetic and logic operations. It is the source for the store operation. It is not affected by branching. A constant ZERO is used by the load instruction, which places the value from memory into the accumulator by adding ZERO plus the value into the accumulator. ZERO is otherwise inaccessible to the programmer. To clear the accumulator to zero, if desired, the programmer must load the value zero from memory. From the programmer's view, Gemini instructions use a demultiplexer and a multiplexer to control the target of the accumulator, and to select the operand for the machine instruction (ZERO for load, the accumulator for arithmetic and logic).Instruction Set
For this Project, Gemini has 12 instructions: (Note that $val indicates a memory location #$val indicates an actual value from the text segment) - LDA $m Load the accumulator from a memory location LDA #$val Load the value into the accumulator - STA $m Store the accumulator into a memory location - ADD $m Add the value in memory to the accumulator ADD #$val Add the value to the accumulator - SUB $m Subtract the value in memory to the accumulator SUB #$val Subtract the value to the accumulator - AND $m Logical "and" of memory and accumulator AND #$val Logical "and" of value and accumulator - OR $m Logical "or" of memory and accumulator OR #$val Logical "or" or value and the accumulator - NOTA Logical "not" of accumulator - BA lbl Always branch to label (goto) - BE lbl Branch to label if operation resulted in 0 - BL lbl Branch to label if operation resulted in Negative - BG lbl Branch to label if operation resulted in Positive - NOP No Operation (Implemented by adding Zero to the ACC) The instructions have two formats: - two bytes (LDA, STA, ADD, SUB, AND, OR, B*, NOP) - one byte (NOTA) The reserved field in the first byte of the instruction would typically be used to extend the Gemini architecture with more instructions and/or addressing modes. The temptation of an architect to use these bits for unsupported instructions, and the ingenuity of users who hunted for and used the unsupported instructions, was the bane of early architects, who would drop the unsupported instructions only to have the users complain bitterly.Addressing Modes
Gemini has a single direct-addressing memory mode. Other addressing modes can be constructed by modifying the program in memory. This is known as self-modifying code, and was the only way to construct many programming constructs in the early days of computer architecture that we now take for granted. Other addressing modes can be encoded in the reserved field, and implemented in the microcode.Memory
Gemini has an eight-bit memory address field. Thus all code and data must fit into a 256 byte main memory.
Microprogrammer's Model
At the microprogrammer's level the programmer's model changes to a multiple register machine with the functions of the multiplexer and demultiplexer handled by outputing data onto the single bus, and latching it into a target register. The microcontroller and its connection to the ALU, registers, and memory are visible. The architect must write the microcode that will cause the eight machine instructions to function correctly. As we will see, the Gemini instruction set can be changed by revising or adding to the microprogram.Datapath
The Gemini datapath necessarily includes the ALU, registers, and memory because all share a common bus. Performance improvements start by separating the functions common to the bus to parallelize the operation of the processor. (This is why the MAR and MDR are included in the internal registers, even though they are not needed in this most primitive model.) For example, selecting a location in memory and reading or writing memory data could be done in parallel during a single clock cycle if: - the common bus was split into an internal CPU bus and an external memory bus, - the external memory bus was in turn split into an address bus and a data bus, and - the MAR was connected to the address bus, and the MDR to the data bus Some additional control, basically some multiplexers and select signals, would be needed to specifiy the direction of data transfer on the memory data bus, but the increase in performance because of parallel operation is worth the cost in complexity and floorspace.ALU
The ALU performs four arithmetic and logic operations: - add - sub - and - or - not The instruction set and all "support" operations, such as incrementing the PC, are constructed from these four operations by choosing the source of the ALU inputs and the destination of the accumulator (ACC) output. Some supporting operations, such as the use of the memory address register to select a location in memory, do not involve the ALU.Registers
Gemini has 11 internal registers that are implemented as latches, three in the ALU group (A, B, and ACC) and seven in the register group (ZERO, ONE, PC, MAR, MDR, TEMP, CC, and IR). Their intended purpose is listed below: - A: ALU input, target of ACC, TEMP, MAR, MDR, and PC - B: ALU input, target of ZERO or ONE - ACC: ALU output - ZERO:constant zero, used for LDA instruction - ONE: constant one, used to increment PC and MAR - PC: program counter - MAR: memory address register - MDR: memory data register - TEMP:temporary ACC storage while updating PC and MAR - IR: instruction register, the source of the starting address for each machine instruction's microprogram - CC: Condition Code Register (-1 for Negative, 0 for Zero, 1 for Positive) Each register is "addressed" directly by output (.out) and latch enable (.latch) control bits in the current microinstruction. Some registers' outputs are always enabled, such as the A and B ALU inputs, and the instruction register (IR). In these cases there is no output control bit in the microinstruction. As mentioned previously, the unoptimized version of Gemini does not need the MAR and MDR. They are included for future use (hint, hint :-)Memory
The 256 byte main memory has internal address and data latches, and address decoding. Since we are not designing the memory, we will assume an interface protocol that uses the memory address register (MAR) to select the memory location, WRITE/not_read and DATA/not_address signals to activate the selected location, and the memory data register to either provide the data for a store or receive the data during a load. The operation of the memory interface is summarized in the following table:
Microprogrammed Controller
Microcode
The microcode lies at the heart of the microprogrammed controller. Control signals for each microinstruction are generated using the clock, ø, either for the level-triggered latches in the datapath, or the edge-triggered latch in the microcontroller that holds the currently executing microinstruction. The microcode (also known as the microprogram) is a 33-bit wide array of 256 microinstructions. It is not at all unusual to have a microinstruction width that is not a power of two because there is no guarantee that the number of control signals will be a power of two, and because floorspace on the CPU is so limited that it would be foolish to implement unused bits. The organization of Gemini and other typical microprograms is given in the table below. Is START the beginning or the end of a instruction sequence? Is the glass half empty or half full? :-)Microinstruction Format
The microinstruction is composed of four groups of control signals: - ALU group - Register group - Memory group - Controller group The signals in each group cause a latch to put data onto a bus (.out), capture data from the bus (.latch), select a function or control a multiplexer, or choose the next microinstruction to execute. Most control signals are inactive during microinstruction execution, that is, most bits in the microprogram are zeros. Active signals are conditioned by the clock, ø, to produce the output and latch signals. The format of the Gemini microinstruction is called "horizontal microcode" because all control signals are represented by a bit in the microinstruction. "Vertical microcode" decodes all control signals from a microinstruction (useful if many microinstructions are repeated in machine instructions). "Diagonal microcode" encodes some fields in the microinstruction but not others, a compromise between space and time. In the Gemini microinstruction the ALU functions could be encoded as a pair of bits. A microinstruction specifies a limited form of parallelism. As many events can occur in parallel as there are functional units and buses to process and transmit data without conflict. A good microprogrammer searches for ways to reorganize the machine instruction's microcode so as to extract as much parallelism as possible from the microprogrammer's model. Experience in microprogramming can identify the bottlenecks in instruction execution that can be overcome by hardware. Pipelining is the easiest of these to see. It is possible to output data from two sources simultaneously, but because some of the same data bits will be zero and one, damaging short circuits will almost certainly occur. Sending data to two destinations at the same time is permissible if the source of the data is powerful enough (i.e., its "fan-out" is large enough).
Timing: Where Microcode Meets Hardware
The timing diagram below shows the relationship between the clock, ø, and the signals that feedback to control the microcontroller, or that are sent from the microcontroller to control the datapath.Clock Generator
The system clock provides the "heartbeat" of the microcontroller. The clock speed is determined by the time required for data to flow through the longest path in the CPU, or by the time required to execute the the most time-consuming ALU operation. This kind of design is called "synchronous" because all functions are governed by a central clock. Many instructions are slowed down because the clock cycle is the maximum necessary in the worst case. Another type of design called "asynchronous" permits the CPU to operate as fast as possible for each operation. Asynchronous operation is similar to dataflow processing, but like it, adds complexity to the CPU.Generating the Next MicroPC
First we will examine the operation of the microcontroller. The most significant function it performs is selecting the start of a sequence of microinstructions that implement the function of a machine instruction, then sequencing through the microinstructions until the machine instruction is complete.Instruction Register (IR)
The instruction register (IR) is the source of the starting address for a sequence of microinstructions. However, since there are only three bits in the machine instruction's opcode to specify the address, it is necessary to translate the 1-of-8 opcodes to one of the 256 code addresses.MicroPC Map Table
The microPC map table translates the opcode in the IR to a instruction address. Note on the timing diagram that the IR, whose output is always enabled, is translated as soon as the data is followed by the latch, but is only guaranteed to be valid after the data is latched. This is still more than enough time for the next microinstruction to be enabled out of the code, and be present at the current inst latch when the rising edge of the clock, ø, signals the end of the executing microinstruction by latching the next one.Action of Carry Flag
The BRC machine instruction uses the technique of "bit forcing" or "bit jamming" to select between one of two instruction addresses depending on the state of the carry. This is accomplished by wiring the carry into the least significant bit of the microPC map table, but ONLY for the entry that translates the BRC opcode into the BRC microinstruction address. Thus, when the carry is zero the first of two adjacent microinstructions is executed. When the carry is one, the second of the two adjacent microinstructions is executed. Since every microinstruction includes the address of the next instruction to be executed, it is easy for the microprogrammer to vector one of the microinstructions to the appropriate sequence to cause the machine program to branch or to fall through to the next instruction.Selecting the Next Address from the Instruction
As just mentioned, each microinstruction contains the address of the next microinstruction to execute. This is equivalent to having a counter register hardwired into the microcontroller. While it is space-inefficient, this is also a very fast technique. Where the program space is small, as it is in a microprogram, and speed is necessary, this is a good design choice. Larger code and more complex sequencing in code may require a microPC implemented as a register, with its own set of controller status flags.Current Microinstruction Latch
The current instruction is held in an edge-triggered latch so that all control bits are stable throughout the clock cycle. This is necessary so that the next microinstruction address will be valid when the clock rises at the end of the cycle, latching the next microinstruction (see the timing diagram shown earlier).Generating Control Signals
Most control signals are "and"ed with the clock, ø, to produce output/follow and latch signals (see the timing diagram). Some signals are unconditioned, such as the PC.sel, which is thus given as much time as possible to "steer" the correct microinstruction address into the microcode ROM.ALU Timing
The ALU is one of the critical paths in Gemini, determining the maximum clock rate by the sum of the time needed to output and latch the second input (usually to the B register), compute the function of the B register and the previously latched A register, and latch the output in the accumulator. If the ALU operates too slowly, then a single operation that performs all these actions can be split into two, and the clock rate increased, perhaps even doubled. Since there are many more data transfer operations than ALU operations, the overall result is a much faster CPU.Register and Memory Timing
External memory is up to ten times slower than internal memory, largely due to the resistance and capacitance of the I/O pads on a VLSI circuit. The Gemini architecture, as used in this assignment, ignores differences in register and memory timing, assuming that both are not only connected to the same bus, but are also on the same chip.
Assignment
Now that you understand the basic elements of the Gemini, here is the software specifications for this project:Functionality
- The software will take a file name of a file that contains Gemini Assembly constructed with newlines (Examples follow). - The software will run in a GUI. - The program will load the strings from the file and parse the strings one at a time. - If a program is invalid in any way, we should quit and tell the user the line number of the failure. - If during program execution the simulator notices any problems (namely Segmentation Faults- it should also quit and tell the user the line number of the fault. - When a string is parsed by the main programs Engine the following will happen: - Display the string in the simulator window to show the user what instruction is currently running. - Show updates to all registers in the simulator window as the line of code is run. - GUI Design: The GUI should look something like the following ascii art: ------------------------------------------------------- | Gemini Simulator [ESC to quit]| | | | Instruction Index: 1/30 (0%) | | Instruction: [ lda $10 ] | | | | Register | Value | | ------------------------ Unused (for now) | | A | [ 0x00000000 ] | | B | [ 0x00000000 ] | | Acc | [ 0x8a2871a2 ] | | Zero | [ 0x00000000 ] | | One | [ 0x00000001 ] | | PC | [ 0x00000001 ] | | MAR | [ 0x7abb7201 ] | | MDR | [ 0x7ac6cc00 ] | | TEMP | [ 0x00000000 ] | | IR | [ 0x8ff28fc2 ] | | CC | [ 0xfffffff1 ] | | | | Current Instruction Cycle: 1/9 [Operation] | | [Space - next cycle] [Enter - next Instruction] | ------------------------------------------------------- As each 'cycle' is taking place, the user is required to press the spacebar to perform the next cycle. Pressing the Enter key will bring the user to the next instruction. Pressing ESC should end the program. - When the assembly in the program has finished- we will show nothing as the next instruction- keep the register values in place and simply wait for the user to quit or load a new program.Classes
The software will be divided into the following classes: - Instruction Parser Engine This class should handle two main items: - Parse assembly files and place them into the Instruction Vector - Parse an individual instruction for the CPU to determine what to do with it. Since the Instructions are all strings, this class should be very simple (See Memory, Tests for sample asm files). Labels: Labels shall be handled a little differently than normal instructions (Recall that Labels look something like and $10\n lbl: ! Here's a label!\n or $11\n ) To handle this- we will replace any instructions that use lbl with the index number of the instruction! ble lbl should end up looking like "ble 1" in our Instruction Vector since it is the second instruction. To do this, I recommend keeping 2 lists of instructions that contain labels and labels/index numbers as you come across them (Since we may or may not know where a label exists in a program as we read it- therefore we might not know the Instruction Vector Index of that label). So, when you come across ble lbl you will ask your list, do I know what index lbl is? If not, we push this instruction into out 'unknown instruction list'. If we do know the index, we simply replace the label string name with a number. At the end of parsing a program, we re-visit each instruction in our unknown list and place the label index number there. Finally, if there are any unknown instructions left- we cannot run this program! Note that having an unused label is just fine. - Memory This class will contain 2 different 'regions' of memory - std::vector<std::string> Text; // Instruction Vector - int Stack[256]; // Main Memory The Text string vector will hold lines of Gemini Assembly This will be loaded from a file with each line of assembly delimited with a newline. Comments (!) and pointless whitespace should be ignored. Here is an example: ! Ignore this comment\n add #$10 ! Add 10 to the accumulator\n \n and $10 ! And memory address 10 with the accumulator\n nop\n lda #$10\n In this case, the instruction vector will look like this: Text.at(0) = "add #$10" Text.at(1) = "and $10" Text.at(2) = "nop" Text.at(3) = "lda #$10" Note that Main Memory (Stack[]) should handle segmentation faults As in Accessing Stack[256] should fail, but not break your program. - CPU (Held in CPU.cpp, defined in CPU.h) This class will be the master CPU class and will hold the following: ALU Registers The ALU will be the code actually performing: add (nop) sub and or not And will track the code for all memory operations: lda sta b* Registers will simply be int values for all 10 internal registers. The CPU will also record operations it has performed Addition Subtraction And Or Not Store Move And the overall number of operations it has performed. Note how each Instruction takes a certain number of operations. You will need to have the CPU determine how many operations an instruction will take. The CPU should also keep an overall counter of number of operations it has performed. * We will cover each instruction in class and discuss implementation options for them. - Main Program... (Gemini.cpp / .h) The Class Layout should be as follows: Main - Contains the GUI code - Contains the CPU Needed: - public access to all register values - int currentOperationNum() Tell the GUI what the CPU is doing currently - string currentOperation() - int getCurrentInstructionNumber() To interface with memory - int getCurrentOperationCount() How many total operations have we done? - Contains a pointer to Memory Needed: - int getInstructionCount() (for top progress info) - string getInstruction() CPU - Contains the IPR to parse Instructions - Contains Memory IPR - Contains a pointer to Memory to fill the Instruction Vector Memory - Contains the primitaves for memory accessProject Steps
Here is how I recommend building this software- you can take whatever approach you prefer as this is an open project- just remember that the final results must operate as required! Step 1: Make sure you understand how to update the GUI and process input from the user. Step 2: Create the IPR Class and make small tests to read instructions from a file and get them to the screen. Ensure that your IPR can handle invalid instructions, comments and whitespace. Step 3: Create the Memory class and make your IPR interface with it to fill the Instruction Vector with instructions- then print them out. Step 4: Create the CPU class which will contain logic for the Gemini CPU ALU and memory operations. Remember from the GUI that we need to track operations and operation counts. Your CPU class should then contain the IPR and be able to actually run code. Step 5: Link the CPU/Memory classes with your GUI to complete this project.Tests
You should create tests for your program to see how it operates throughout the build process. However, the program must pass these final tests and you will be required to answer the questions about the tests. Test 1 - Instruction Examination Download test1.smain: lda #$1 sta $0 ! 1 into Stack[0] sta $255 ! 1 into Stack[255] add $0 ! 2 in ACC lda $0 sub $0 ! 0 in ACC lda $0 and $255 ! 1 & 1 is 1 in ACC lda #$0 or $0 ! 1 | 0 is 1 in ACC lda #$0 nota ! !0 in ACC nopTest 2 - Invalid Instruction! Download test2.smain: lda $0 Hey- I forgot to put ! add #@3Test 3 - Basic for() loop Download test3.smain: lda $5 sta #$2 ! x = 5 lda #$0 ! for(int i = 0; i < 10; i++){ sta $0 ! i is in Stack[0] lda #$10 sta $1 ! constant 10 pushed to stack check: lda $1 sub $0 bl out ! 10 - i = Negative for condition to be true luup: lda #$2 ! x add $2 ! x += 2; and #$0 ! x = x & i; ba check out: lda #$2 ! X Back into ACC for examinationTest 4 - Segmentation Fault Download test4.smain: lda #$32 sta $392 ! Stack[392]???Test 5 - Convert to ASM Download test5.c Convert the following C code to Gemini ASM and run it through your simulator.int main(void){ int x = 0; int y = 4; int z = 1; for(; x <= 13; x++){ // Possible without ble or bge y = x + y - z; if(y == 9) goto rehash; goto out; } rehash: y = x & z | y; out: // Place y into the ACC to examine }Turn In
You will need to turn in the following: - Complete solution files. - Screen captures of your solutions running. - Any additional Readme/notes you feel are needed for this project.


Totnes, England
The Leechwell
A historic holy well hidden near a charming English park.
The Leechwell is a tranquil treasure well worth the small detour from visiting the market. A plaque at the site details a little of the well’s history. The easily missed Leechwell is a historic holy well appearing in records as far back as the 13th century, though its exact built date is unclear.
Threes are a theme of the well, as it’s at the meeting point of three lanes, has three streams of water, and is associated with a three-sided pool close by. The pattern of threes indicates the well’s holy nature, with the number three symbolizing the Holy Trinity.
The well itself sits in a sunken rectangular basin, where water pours into three stone troughs named “toad,” “long crippler,” (an old local word for “slow worm”), and “snake.” The water source is visible through a barred hole in the back wall; each bar is covered almost completely in ribbons tied by locals and visitors.
In the past, locals used the water for its perceived healing properties, particularly for snake bites and joint, eye, and skin conditions. Local legend also claims the water was also used in attempts to cure leprosy. Today, it still sees usage by the town’s new age and pagan communities, many of whom leave offerings around the well and collect its water. Potted plants, candles, and sea shells can often be seen left on the stone shelf above the troughs.
Farther down the hill, in Leechwell Garden, is a triangular immersion pool associated with the well. Both the well itself and the triangular pool are scheduled monuments.
Know Before You Go
The well can be accessed from three different roads; however, accessibility by the garden (Leechwell Lane) route is potentially difficult for wheelchair users due to the positioning of the metal railings. The lane next to the Kingsbridge Inn is more accessible, but still steep and narrow.
Community Discussion
-
No Comments Yet
Start the discussion.
forum Visit our forums.


Group: A B C D
Nick Clegg said no party would win an outright election victory and warned voters they face a choice between the Lib Debs, the SNP and UKIP over who holds the balance of power. Launching his manifesto, the Lib Dem leader said he would seek to form a "coalition with conscience" that would not "lurch off to the extremes".
UKIP - which also launched its election manifesto today - said it would make working people better off through a "low-tax revolution".
Working grandparents could share unpaid parental leave under plans beind launched by the Labour Party as part of its women's manifesto.
And finally, the SDLP has launched its manifesto, in which it calls for a prosperity process for Northern Ireland to expand its private sector.
Nick Clegg said no party would win an outright election victory and warned voters they face a choice between the Lib Debs, the SNP and UKIP over who holds the balance of power. Launching his manifesto, the Lib Dem leader said he would seek to form a "coalition with conscience" that would not "lurch off to the extremes".
UKIP - which also launched its election manifesto today - said it would make working people better off through a "low-tax revolution".
Working grandparents could share unpaid parental leave under plans beind launched by the Labour Party as part of its women's manifesto.
And finally, the SDLP has launched its manifesto, in which it calls for a prosperity process for Northern Ireland to expand its private sector.
Nick Clegg said no party would win an outright election victory and warned voters they face a choice between the Lib Debs, the SNP and UKIP over who holds the balance of power. Launching his manifesto, the Lib Dem leader said he would seek to form a "coalition with conscience" that would not "lurch off to the extremes".
UKIP - which also launched its election manifesto today - said it would make working people better off through a "low-tax revolution".
Working grandparents could share unpaid parental leave under plans beind launched by the Labour Party as part of its women's manifesto.
And finally, the SDLP has launched its manifesto, in which it calls for a prosperity process for Northern Ireland to expand its private sector.


| 1 | /* | |
| 2 | * Licensed to the Apache Software Foundation (ASF) under one or more | |
| 3 | * contributor license agreements. See the NOTICE file distributed with | |
| 4 | * this work for additional information regarding copyright ownership. | |
| 5 | * The ASF licenses this file to You under the Apache License, Version 2.0 | |
| 6 | * (the "License"); you may not use this file except in compliance with | |
| 7 | * the License. You may obtain a copy of the License at | |
| 8 | * | |
| 9 | * http://www.apache.org/licenses/LICENSE-2.0 | |
| 10 | * | |
| 11 | * Unless required by applicable law or agreed to in writing, software | |
| 12 | * distributed under the License is distributed on an "AS IS" BASIS, | |
| 13 | * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. | |
| 14 | * See the License for the specific language governing permissions and | |
| 15 | * limitations under the License. | |
| 16 | */ | |
| 17 | ||
| 18 | package org.apache.commons.codec.language.bm; | |
| 19 | ||
| 20 | /** | |
| 21 | * Supported types of names. Unless you are matching particular family names, use {@link #GENERIC}. The | |
| 22 | * GENERIC NameType should work reasonably well for non-name words. The other encodings are | |
| 23 | * specifically tuned to family names, and may not work well at all for general text. | |
| 24 | * | |
| 25 | * @since 1.6 | |
| 26 | * @version $Id$ | |
| 27 | */ | |
| 28 | public enum NameType { | |
| 29 | ||
| 30 | /** Ashkenazi family names */ | |
| 31 | ASHKENAZI("ash"), | |
| 32 | ||
| 33 | /** Generic names and words */ | |
| 34 | GENERIC("gen"), | |
| 35 | ||
| 36 | /** Sephardic family names */ | |
| 37 | SEPHARDIC("sep"); | |
| 38 | ||
| 39 | private final String name; | |
| 40 | ||
| 41 | NameType(final String name) { | |
| 42 |
1
1. |
this.name = name; |
| 43 | } | |
| 44 | ||
| 45 | /** | |
| 46 | * Gets the short version of the name type. | |
| 47 | * | |
| 48 | * @return the NameType short string | |
| 49 | */ | |
| 50 | public String getName() { | |
| 51 |
2
1. getName : M1: field dereference on object org/apache/commons/codec/language/bm/NameType and fieldname mutated with null check on object → SURVIVED 2. getName : mutated return of Object value for org/apache/commons/codec/language/bm/NameType::getName to ( if (x != null) null else throw new RuntimeException ) → SURVIVED |
return this.name; |
| 52 | } | |
| 53 | } | |
Mutations | ||
| 42 |
1.1 |
|
| 51 |
1.1 2.2 |


Get your profile verified from the comfort of your own home, with our at-home CleanDate Collection Kit. Self-collect your samples and get your results within 5 days.
Our complete at-home testing kit tests for the 8 most common and high risk STDs:
Kit Includes:


Sign Up
Email
Username
Password
I agree to the
Terms of Service
and
Privacy Policy
Sign up
Log In
Login
Username
Password
Log In
Sign Up


{% extends "layout.html" %} {% block body %}
first time users: see information section below
for reservations, see the calendar section below
to view usage statistics, click here NEW
| docker id | type | owner | gpus | uptime | |||
|---|---|---|---|---|---|---|---|
| no active images |
use the launch a gpu session form above to create a personal container running on the DC GPU machine. based on the image type (described below), you will be put into a development environment with one or more of the machine's four gpus exposed to you. you should be able to run any code you write with identical behavior in any environment; the only difference is the isolation of the gpus.
there are few requirements you must satisfy before this will work for you.
for help with all of the above, you need to contact the box admins. for now, direct all questions to the #gpu_users
slack channel
we have implemented the following image types
python
: a python-only, gpu-aware development environment with full access to zero or more gpus.
python+R
: the same as the above with the addition of an R
environment and a running rstudio
server. this is still in development, so may be buggy!
to make your own reservations, click the "add to google calendar" link in the bottom right


SX v2.3.11 released - changelog:
[*] Updated.
SX v2.3.12 released - changelog:
[*] Updated.
[+] Fixed 'getscriptclosure'.
SX v2.3.13 released - changelog:
[*] Updated.
[+] Fixed .Function in getconnections.
SX v2.3.14 released - changelog:
[*] Updated. (again)
SX v2.3.14c released - changelog:
[*] Fixed ping spike issues.
SX v2.3.15 released - changelog:
[*] Updated. Sorry for the delay.
SX v2.3.15b released - changelog:
[*] Fixed crashes from last update & other API issues.
SX v2.3.16 released - changelog:
[*] Updated.
SX v2.3.16b released - changelog:
[*] Fixed getconnections crashing.
[*] Fixed firesignal freezes.
SX v2.3.17 released - changelog:
[*] Fixed detection(s) for this go around.
[*] Fixed gethiddenproperty.
[*] Fixed getpcdprop.
[!] WARNING: While we did extensive testing for this update, we still recommend you take precautions for the next week or two. Use AutoLaunch and alts as you always do - sorry for the wait.
SX v2.3.19 released - changelog:
[*] Updated.
(v2.3.18 was skipped)
SX v2.3.20 released - changelog:
[*] Fixed a few decompiler issues.
Note: This update requires a UI restart - ignore any "Failed to verify UI contents" errors you get before restarting SX.
SX v2.3.24 released - changelog:
[*] Updated.
SX v2.4.2 released - changelog:
[*] Updated.
SX v2.4.3 released - changelog:
[*] Updated.
[!] Sorry about the slower then usual update today.
SX v2.4.4 released - changelog:
[*] Updated.
[!] Sorry about the short downtime there!
(if your stuck on downloading data restart the client)
SX v2.4.4b released - changelog:
[*] Fixed crashes.
SX v2.5.1 released - changelog:
[*] Updated.
SX v2.5.2 released - changelog:
[*] Updated.
SX v2.5.3 released - changelog:
[*] Updated.
SX v2.5.4 released - changelog:
[*] Updated.
SX v2.5.6 released - changelog:
[*] Updated.
SX v2.5.7 released - changelog:
[*] Updated.
Fixed.


From January 2003 to December 2015, the percentage of crimes that were solved* by the San Francisco Police has varied a lot, posibly increasing slightly until 2010, and from 2010 to 2015 it decreased from abount 44% to about 30%, with an increase in 2013 and first half of 2014.
Note: I consider a crime to be solved if it is recorded with a resolution different than None.


UO Calculator
Ratio
Mortar
Mortar Calculator
Mortar
ACE Mk6 82mm
3CB M6 60mm
Gun Grid
Target Grid
Gun Altitude
Trg. Altitude
Charge
0
1
2
Distance
ToF
ToF / 100m
Elevation
Azimuth


Select a chart type to see the chart and the JSON used to create it. Update the JSON and click "Update Chart". Learn more at our GitHub repository, or see the v0.x documentation.


Unscramble
If I am coloured, I smell, if I am burned, I smell, orange and yellow will melt me. What am I?
Think you figured it out? Click
NEXT
to reveal the answer.


readme
1 What is it?
mkaestatic is a minimalist static website generator. It is very lightweight and simple, because it merely combines the powerful standard tools make, python, Markdown and Jinja.
As a static website generator mkaestatic converts Markdown files (for instance readme.md, about.md and contact.md) into HTML files (for instance readme.html, about.html and contact.html). The Markdown to HTML conversation is controlled by a Jinja HTML template file, a configuration file and options that are integrated in the Markdown files.
mkaestatic has a simple command line interface that allows rapid local website development and testing. This interface is entirely based on make and integrates smoothly with static website hosting services based on ssh or website hosting via GitHub Pages.
Features
- Easily extensible make and python based static website generator
- Markdown content and Jinja2 HTML templates
- Purely relative URLs that means
- Websites can be copied in bulk to arbitrary subdirectories of web servers (for instance ~user/ websites) without any modification in code.
- Websites can be accessed locally or remotely without a HTTP server (i.e. using file:// instead of http://)
- Websites can just be a git repository hosted for instance via GitHub Pages
- Arbitrary deep subdirectories
- Fast build times even for large projects as changes and dependencies are managed by make
- Keeps track of static requisites (as for instance static .css and .js files) using make
- Can be easily integrated with other content generating tools (such as sass) via make
- Only about 350 documented lines of python code
Requirements
To run mkaestatic a python3 installation is required. mkaestatic additionally requires
- Mistune as its Markdown implementation (Mistune >= 2.0),
- Jinja2 as a template engine and
- PyYAML to read and write configuration files.
The extra python packages can be installed for instance with pip
pip install mistune jinja2 pyyaml
2 Quickstart
Preparation
Either clone, fork or template the repository on GitHub or copy the
- code files mkaestatic.py, Makefile and Pages.mk
- and the global configuration file Site.yml
- at least one example Markdown file readme.md, example.md, contact.md and/or index.md
Create a HTML template
To use mkaestatic a Jinja HTML template is needed. As a start you can try the one which is contained in this repository _template/default.html and adapt it to your needs. The path to the template file must either be given in the global Site.yml configuration file or in each .md file individually.
Create Markdown files
The next step is to create actual website content using Markdown (.md) files. This repository contains the example Markdown files,
- readme.md (this file)
- example.md (an example with a referenced image)
- index.md (mirrors the readme.md file)
- contact.md (another example)
- other pages (i.e. .md files) in the blog directory to illustrate how subdirectories work
which should illustrate most of the functionality of mkaestatic.
Test your website locally and deploy it
To test the resulting website you can call
make serve
This command converts all .md files into HTML files using mkaestatic and starts a local webserver with which the result can be tested. The command line output indicates how you can access the website in your browser. To immediately see something in the browser when the local webserver is accessed, you need to create an index.md file that will be compiled to an index.html file.
The other mkaestatic commands are
make
which converts (compiles) the .md files to HTML files,
make clean
which deletes all temporary files (including .html files that were generated),
make build
which copies all the deployment files into a built folder. This folder contains all the necessary files to serve the website and no other files,
make tar
which creates a tar archive built.tar.gz with the complete website and no other files,
make upload
which uploads the complete website to a folder via ssh (the ssh server information must be set in the Makefile for this to work).
make git-add-requisites
which adds all the files that are needed to serve the website to the local git repository. This command is especially useful in combination with GitHub Pages or a similar service.
3 Basic features
Local URLs and requisites
Local URLs in Markdown files
The Markdown (.md) files can include hyperlinks to other pages (i.e. other .md/.html files) using the usual Markdown syntax. For instance,
Hello this is a line of Markdown code that refers to the [readme](/readme.html) page.
will produce the text with a link to the readme.html file. The readme.html file can either be an externally provided file or a file which is also generated by mkaestatic from readme.md. The hyperlink is translated to a local relatively referenced link in the HTML-code.
You can also included links to static objects this way,
Here you can download a [fancy pdf file](/static/fancy.pdf).
which generates a link to the static PDF-file static/fancy.pdf. mkaestatic will produce an error if the file static/fancy.pdf does not exist. If it exists it will be included as a requisite. That means it is included in the set of all files that need to be deployed. It is copied together with the all the generated html files into the built folder or uploaded into an ssh server. Local URLs referenced in a Markdown file will always be correctly translated and included into the make dependency tree if they start with a slash as in the preceding to examples. The leading slash stands for the top-level directory of your mkaestatic workspace directory (i.e. the directory which contains the Makefile).
Local URLs in Jinja templates
To reference local pages (local .md/.html file pairs) in template files the Jinja filter localurl, which is provided by mkaestatic, must be used to translate the URL to the proper relative URL. For instance,
A link to the page p
will translate the URL of the page p (i.e. a local .md/.html file pair) accordingly.
The localurl filter must also be used when accessing static local files. For instance,
<link rel="stylesheet" href="{{ '/static/css/style.css' | localurl }}">
will translate the local URL '/static/css/style.css' to the respective relative URL which is valid from the currently rendered page and it will add the file /static/css/style.css as a requisite and to the make dependency tree. This way other tools such as sass can be used to compile the .css file from some source by including a respective rule to the Makefile. As in the Markdown files, local URLs used in this way must start with a slash to indicate the reference to the root directory of the mkaestatic instance.
Using actual relative URLs (discouraged)
If you actually want to specify a relative URL (for instance from a subdirectory) do not use the leading slash. The URL will be resolved with respect to the directory the current page (not the template!).
Additional static requisites
Additional requisites that might not be referenced by any website can be included in the header of the Makefile in the configuration variable REQUISITES. For instance,
REQUISITES:= robots.txt .htaccess
also includes the files robots.txt and .htaccess which are neither referenced in any Markdown file nor in a template via localurl.
Configuration of pages
Local attributes (per page)
Every Markdown file can have a three dash separated header (as in Jekyll), where attributes can be defined. These attributes can be accessed from the Jinja HTML template. For instance,
---
title : My frontpage
date : 01.01.1979
template : _templates/frontpage.html
---
*content here*
The Jinja template can now access the attributes using the variables page.title, page.date and page.template.
The template attribute has a special role as it sets the Jinja HTML template which will be used to render the HTML file from the Markdown file. A template must be given either in the source file of the page or in the global Site.yml configuration file where a default template for all pages can be specified.
Global attributes (per site, i.e. one per mkaestatic instance)
Global attributes can be set in the global Site.yml configuration file. For example,
name : "mkaestatic"
tagline : "is awesome"
template : _templates/default.html
will for instance set the global name, tagline and template attributes. These attributes can be accessed in all templates via the variables site.name, site.tagline, site.template.
The global template attribute in Site.yml again has a special role as it can be used to specify a default template for all Markdown files.
Accessing page configurations in Jinja templates
The most important variable which is passed from mkaestatic to the Jinja template is the content variable. It contains the HTML-code which was rendered from the Markdown input. For instance you can add

{{ content }}

in the middle of your template for the Markdown content to actually be rendered.
Local and strictly global attributes
All attributes can be accessed in the Jinja template with the page, site or root variables. For instance, page.title or page.date will refer to the values given in the Markdown header that was given as an example above.
Your Jinja template might contain the following line for the title tag side the HTML header:
<title>{{ site.name|e }} - {{ page.title|e }}</title>
The value of site.name, the one defined in Site.yml, is similar for all pages in the mkaestatic instance, whereas page.title will differ from page to page depending on the definition of title in the page header.
The Jinja filter |e escapes special characters in the variables to HTML.
Special attributes
Every page has three special attributes which are set internally by mkaestatic: name, url and title. The attribute name is the basename of the filename of the Markdown (.md) file. url is the URL which can be used to reference the resulting HTML-file. title is the same as name by default, but can be overwritten in the local configuration.
Optionally, the attribute mirror can be set in the local configuration of a page. mirror must be set to the filename of another page, whose content will be merely copied to the HTML of the page. This can be useful to deal with compatibility in respect to old url schemes.
Let's say for example that index.html shall have the same content as readme.html:
index.md:
---
mirror: readme.HTML
nomenu: true
---
Accessing attributes via the directory tree
With the site and page variables, global attributes or the attributes of the current Markdown page, which is about to be rendered to HTML, may be accessed. But in many cases the attributes of other pages are also needed. If for instance a menu shall be rendered on the website, the Jinja template needs to know certain attributes, as the title or date, of a bunch of source files.
mkaestatic provides a simple data structure for these situations:
In the Jinja template the variable root can be accessed. This variable mirrors the structure of the top-level directory (the one in which make is invoked and which contains the Makefile) in the mkaestatic directory tree. The root variable is iterable. If we loop over root, we iterate over the configurations of the pages in the top-level directory. For instance,
{% for p in root if not p.nomenu %}

{{ p.title|e }}

{% endfor %}
will render a menu item for every page (i.e. .md file) in the top-level directory, which was added in the top-level Pages.mk. The page will only be included if the local configuration of the page does not contain a nomenu attribute, because of the
if not p.nomenu
filter in the for-loop.
Every page has the additional attribute url, which contains the relative url of the page from the top-level directory. As in the line
{{ p.title|e }}
of the example above, the | localurl filter must be added to obtain a relative url which works for pages also in subdirectories (see "Special attributes").
The pages of subdirectories can be iterated over by accessing the respective attributes of root. For instance,
{% for p in root.blog %}
...
{% endfor %}
will loop over all pages inside the blog/ subdirectory. Such a complete subdirectory example is contained in the Pages.mk of this repository. For a working illustration you have to uncomment the respective section in the SUBDIRECTORIES part of Pages.mk (see also the next section).
4 Advanced features and further details
Under The Hood
mkaestatics non-recursive make approach is based Emile van Bergen's article Implementing non-recursive make which is itself based on the paper Recursive Make Considered Harmful.
Pages.mk files in detail
In Pages.mk the pages and subdirectories of the root directory can be configured. The file is quite long, but most of it is just recursive make management.
By default all .md files in the directory are included as pages in the ordinary Pages.mk file. The filenames of the page-files can also be added one-by-one to the Pages.mk file. To do so comment out or delete the line
PAGES_SRC_$(d):=$(wildcard $(d)*.md)
in the Pages.mk file. The make variable PAGES_SRC_$(d) must be set to the list of pages. For instance you can add use the line
PAGES_SRC_$(d):=$(d)index.md $(d)readme.md
instead. A page is a Markdown file with a .md suffix, which will eventually be compiled to a HTML-file. A prefix $(d) needs to be added filename. This adds the name of the current directory before the path of page in accordance to non-recursive make practice. The line needs to be inserted into Pages.mk in the following place:
... non recursive make stuff ...
#########################################
# LOCAL PAGES
#########################################
...
PAGES_SRC_$(d):=$(d)index.md $(d)readme.md
# Include the $(d) for reference to the local directory.
# This is the famous non-recursive-make trick!
... more non recursive make stuff ...
Two files are added as target for your project: index.html and readme.html, which will be generated from the Markdown files index.md and readme.md respectively.
Websites with subdirectories
To add subdirectories to the mkaestatic tree you need to modify (or uncomment) the following section of Pages.mk:
#########################################
# SUBDIRECTORIES
#########################################
# Load config and pages from blog/
dir := $(d)blog/
include $(dir)Pages.mk
MKCONFIGS+=$(dir)Pages.mk
# Load more subdirectories ...
#dir := $(d)blog2/
#include $(dir)Pages.mk
#MKCONFIGS+=$(dir)Pages.mk
#...
Uncommenting these lines in the present repository produces an example with a working subdirectory.
The subdirectories can be added in arbitrary order. Each subdirectory needs to contain its own Pages.mk file of the same form as above. You can add a subdirectory by adding the following lines:
dir := $(d)blog/
include $(dir)Pages.mk
MKCONFIGS+=$(dir)Pages.mk
where the folder blog/ is replaced by the respective subdirectory. Note, that you need to include the $(d) again before the directory name. In the subdirectory you can add additional pages or subdirectories recursively by modifying the Pages.mk files inside them appropriately.
ssh-server upload
You can use mkaestatic to upload your static website to a server via ssh. The necessary ssh-info must be set in the Makefile:
SSH_SERVER :=<EMAIL_ADDRESS>SSH_FOLDER := public_html
The command
make upload
will upload all the generated HTML files and all requisites of the page, which are in the dependency tree of make, to the server and put them into the ~/$SSH_FOLDER/ of the current user. Links in Markdown code and links which are filtered with the localurl Jinja will be automatically included in the upload.
If some static file is missing maybe you missed a | localurl filter in some template or a leading slash for a 'absolute' path.


Check compliance of event data from (business) processes with respect to specified rules. Rules supported are of three types: frequency (activities that should (not) happen x number of times), order (succession between activities) and exclusiveness (and and exclusive choice between activities).
| Version: | 0.1.0 |
| Imports: | dplyr, bupaR, rlang, edeaR, stringr, glue |
| Suggests: | knitr, rmarkdown, eventdataR |
| Published: | 2018-10-08 |
| Author: | Gert Janssenswillen [aut, cre] |
| Maintainer: | Gert Janssenswillen <gert.janssenswillen at uhasselt.be> |
| License: | MIT + file LICENSE |
| NeedsCompilation: | no |
| Materials: | README |
| CRAN checks: | processcheckR results |
| Reference manual: | processcheckR.pdf |
| Vignettes: |
Rule-Based Conformance Checking |
| Package source: | processcheckR_0.1.0.tar.gz |
| Windows binaries: | r-devel: processcheckR_0.1.0.zip, r-release: processcheckR_0.1.0.zip, r-oldrel: processcheckR_0.1.0.zip |
| OS X binaries: | r-release: processcheckR_0.1.0.tgz, r-oldrel: processcheckR_0.1.0.tgz |
Please use the canonical form https://CRAN.R-project.org/package=processcheckR to link to this page.


PixelBoxGen/Boxcomponents to the sprite.
Click + to add a item
Set the sprite first
Sprite needs to be open and readable
Then set up the collider
Click the new button to automatically generate a collider gameobject at the child level.
Then click generate button to generate
Generated effect