library(tidyverse)
library(cowplot)
library(broom)
library(modelr)
library(viridis)
library(lubridate)
library(hms)
knitr::opts_chunk$set(tidy.opts=list(width.cutoff=60),tidy=TRUE, echo = TRUE, message=FALSE, warning=FALSE, fig.align="center")
source("../../tools/echem_processing_tools.R")
source("../../tools/plotting_tools.R")
theme_set(theme_1())
This is the third replicate of the psoralen IDA experiment. Please see the processing notebook for the quantification of the raw echem scans. See the README for the project folder for the protocol and details about the data.
Let’s look at the data quantified from the electrode 1 SWVs.
df_all <- read_csv("../Processing/01_23_19_processed_swv_gc_all.csv")
#ignore rep 0, because it is not paired with a GC measurement, ignore soak datapoints
ggplot(df_all %>% filter(electrode_from_swv=='i1' & reactor=='transfer' & rep>0), aes(x = signal_from_swv, y = signal_from_gc, color = factor(run))) +
geom_line()+
geom_point()+
facet_wrap(~treatment,scales='free') +
xlim(0,NA) +
scale_color_viridis(discrete = T)
Ok,the most obvious thing we can see is that there’s some craziness that happened in the quantitation of the psoralen data. This is to be expected from some of the weird echem behavior described in the processing notebook. Psoralen runs 2 and 3 look unsalvagable, but you can see that run 1 and 4 look pretty ok, except that psoralen run 1 has 2 points that seem to be outliers.
Apparently those two outlier datapoints for psoralen run 1 are reps 14 and 15, when the SWVs randomly had very high noise. I believe we could smooth the data and get nice quantification for those scans, but for now let’s exclude all of the reps >= 14.
ggplot(df_all %>% filter(electrode_from_swv=='i1' & reactor=='transfer' & rep>0 & rep<14), aes(x = signal_from_swv, y = signal_from_gc, color = factor(run))) +
geom_line()+
geom_point()+
facet_wrap(~treatment,scales='free') +
xlim(0,NA) +
scale_color_viridis(discrete = T)
Now you can see that runs 1 and 4 in both the control and psoralen treatments look pretty nicely behaved and quite linear. Thankfully, those runs were taken at the same scan rates for the two biofilms, so they are directly comparable. See more detail below.
The other thing to notice, is that the control data takes on a different shape from runs 1-3. Run 1 seems very linear, Run 2 maybe has a slight curve, but Run 3 is obviously nonlinear. I do not know what causes this change, but it is interesting that this trend also appeared in other replicates of this experiment. In general I can think of three reasons why the nonlinear trend might appear:
Let’s focus on run 1, which may be the most reliable subset of the data. All of the SWVs were taken with fast settings.
df_1 <- read_csv("../Processing/01_23_19_processed_swv_gc_run_1.csv")
ggplot(df_1 %>% filter(rep>0), aes(x = signal_from_swv, y = signal_from_gc, color = treatment)) + geom_point() +
geom_smooth(method='lm', se=F)
Here you can see that the linear trend is very nice. It is also clear that the psoralen dataset has a higher slope than the control.
Recall that: \[ D_{ap} = \frac{(m A \psi)^2 }{S^2 \pi t_p }\] So, the higher the slope the higher \(D_{ap}\). Let’s directly calculate \(D_{ap}\) from the slopes of the fitted lines:
dap_calc <- function(m, t_p=1/(2*300)){
psi <- 0.91
A <- 0.013 #cm^2
S <- 18.4 #cm
d_ap <- (m*A*psi)^2 / (S^2 * pi * t_p)
d_ap
}
swv_gc_lms <- df_1 %>%
filter(rep>0 ) %>%
group_by(treatment) %>%
do(tidy(lm(signal_from_gc~signal_from_swv,.)))
(swv_gc_dap <- swv_gc_lms %>%
filter(term=='signal_from_swv') %>%
mutate(dap=dap_calc(m = estimate)))
## # A tibble: 2 x 7
## # Groups: treatment [2]
## treatment term estimate std.error statistic p.value dap
## <chr> <chr> <dbl> <dbl> <dbl> <dbl> <dbl>
## 1 control signal_from_swv 0.151 0.00399 38.0 1.06e-14 1.81e-6
## 2 psoralen signal_from_swv 0.238 0.00324 73.5 3.70e-16 4.47e-6
As was clear from the plot, the psoralen titration actually has a higher \(D_{ap}\) estimate than the control, which is the exact opposite of what we would expect from the DNA CT hypothesis. Let’s look at run 4, before we draw our final conclusions.
\(D_{ap}\) Parameter Notes:
So, apparently \(t_p\) should be one half of the sample period (inverse of frequency). Therefore \(t_p = \frac{1}{2} * \frac{1}{300\text{Hz}}\).
Also, the surface area was measured to be ~0.025 \(\text{cm}^2\), but in terms of the dimensions of the actual IDA, there are 65 pairs of electrodes that are 2mm long and 10um wide. Therefore for just the i1 channel \(65 * 0.2 * 0.001 = 0.013 \text{cm}^2\). The estimate therefore seems high, and could be one reason why the blank IDA PYO \(D_{ap}\) measurements seem quite high.
Here’s the Run 4 data. Note that these SWVs were taken with slow parameters. Note that the psoralen SWVslows did have a slightly weird shape (see processing).
df_4 <- read_csv("../Processing/01_23_19_processed_swv_gc_run_4.csv")
ggplot(df_4 %>% filter(rep>0), aes(x = signal_from_swv, y = signal_from_gc, color = treatment)) + geom_point() +
geom_smooth(method='lm', se=F)
The first thing I notice is that the highest control datapoint seems to be an outlier. Looking back at the processing notebook, shows that GC scan actually has a strange extra peak at the reductive end of the scan (where we quantify), so let’s ignore that datapoint for now:
df_4_outlier <- df_4 %>%
filter(treatment!='control' | rep!=1)
ggplot(df_4_outlier %>% filter(rep>0), aes(x = signal_from_swv, y = signal_from_gc, color = treatment)) + geom_point() +
geom_smooth(method='lm', se=F)
Now the linear trends look reasonably clear. It looks like the slopes are quite similar now, let’s calculate \(D_{ap}\):
swv_gc_4_lms <- df_4_outlier %>%
filter(rep>0 ) %>%
group_by(treatment) %>%
do(tidy(lm(signal_from_gc~signal_from_swv,.)))
(swv_gc_4_dap <- swv_gc_4_lms %>%
filter(term=='signal_from_swv') %>%
mutate(dap=dap_calc(m = estimate, t_p = (1 / 30) ))
)
## # A tibble: 2 x 7
## # Groups: treatment [2]
## treatment term estimate std.error statistic p.value dap
## <chr> <chr> <dbl> <dbl> <dbl> <dbl> <dbl>
## 1 control signal_from… 0.254 0.0156 16.3 5.33e-8 2.55e-7
## 2 psoralen signal_from… 0.191 0.00999 19.2 3.25e-9 1.45e-7
You can see from slope (“estimate” column), that the two datasets are pretty close. The \(D_{ap}\) estimate enhances the difference a little, because \(D_{ap}\) scales with the square of \(m\), but I’m not sure these datasets are distinguishable given the small difference, and relatively poor quality of the psoralen dataset peaks…
Let’s look at all four \(D_{ap}\) estimates on one plot.
dap_agg <- rbind(swv_gc_dap %>% mutate(run='1'),swv_gc_4_dap %>% mutate(run='4'))
ggplot(dap_agg, aes(x = treatment, y = dap, color = treatment, shape = run)) +
geom_point(size=3) +
ylim(0,NA)
This just summarizes what we already learned…at this stage there is not obvious difference between the estimates for the control vs. psoralen treated biofilm \(D_{ap}\). Further, the estimates obtained from the SWVslow trials are significantly lower than the SWVfast…that’s not the end of the world, but it is a little concerning. Perhaps it is worth looking again to make sure the parameters we are inputing into the equation \(\psi, A, S, t_p\) are correct.
For this replicate, runs 1 and 4 seemed to be the most reliable. Only run 4 weakly suggests that the psoralen biofilm has a lower \(D_{ap}\) than the control. Therefore, this replicate does not strongly support the idea that psoralen treatment disrupts DNA CT and or that DNA CT is a major component of \(D_{ap}\).
That said, the control dataset actually looks pretty good, and I think we can trust the quantification of run 1. It is also very interesting that the control dataset becomes more nonlinear throughout the runs.
Further, if we trust the slope based estimates, all of the datasets almost converge within an order of magnitude for \(D_{ap}\): the estimates are all between \(1.4 * 10^{-7} \text{cm}^2 / \text{sec}\) to \(5 * 10^{-6} \text{cm}^2 / \text{sec}\). That’s not perfect, but perhaps we can just look at the SWVfast datasets. I believe they are of higher quality, partly because they were always the first runs taken during every experiment.


Jose Mourinho strolls through Chelsea in full Tottenham kit after Premier League return
Jose Mourinho has been spotted walking around Chelsea for the first time since his shock appointment as the new Tottenham manager, replacing Mauricio Pochettino
by Rich Jones, https://www.mirror.co.uk/authors/rich-jones/New Tottenham boss Jose Mourinho has been pictured strolling around London for the first time since securing his Premier League return.
Mourinho was unveiled as the new Spurs boss on Wednesday morning, less than 24 hours after the sacking of Mauricio Pochettino.
He took his first training session on Wednesday afternoon and held his first press conference on Friday.

Mourinho's appointment has not gone down well with Chelsea fans after he had previously said he would never manage their rivals.
But he had no qualms with walking around the area in the gear of his new club after a whirlwind few days as he took time out to sign a shirt for a fan.
Four years ago, Mourinho said: ‘I would not take the job because I love Chelsea supporters too much.’
But he addressed those comments directly in his first press conference, claiming things changed due to his second sacking at Stamford Bridge.
"Four years ago when you were at Chelsea you were asked whether you would come to Spurs and you said: 'Never, I love the Chelsea fans too much'. What’s changed?" he was asked.
With a smirk on his face, Mourinho replied: "[That was] before I was sacked!"
Mourinho also appeared to aim a subtle dig at Chelsea and Manchester United in an introductory video released by Spurs.
Discussing his desire to bring through young players - something he has been accused of not doing enough of in the past - he said: "There is not one manager in the world that doesn't like to play young players and to help young players to develop - not one.
"The problem is that sometimes you get into clubs where the work that is below you is not good enough to produce these players.
"So I look to our history and you see that the academy is always giving talents the first team need. Of course I always look forward to working with that profile."


King had decided to return to Atlanta, becoming the co-pastor of Ebenezer Baptist Church. King’s return to Atlanta would transform the city into the headquarters of the civil rights movement.
Four black freshmen from North Carolina A&T sat at the whites-only lunch counter at Woolworth’s in Greensboro, NC.
This “sit-in” movement quickly took flight and moved across the South…The AUC students had watched the Greensboro events closely. Lonnie C. King, a student at Morehouse college, began to organize a similar demonstration in Atlanta.
March 8
After the news spreaded out that a protest was on plan, student leaders were asked to meet with Presidents.
March 9
After hearing students’ plan to stage sit-in efforts, the Presidents of the six black colleges in Atlanta initiated a meeting with the student representatives trying to dissuade their efforts. Students agreed to adopt a more tactic act to publish their intentions followed by the suggestion of Rufus Clement, the President of Atlanta University, who also raised the $1,500 necessary to publish the appeal in the local papers.
March 15
Nearly two hundred black students staged sit-ins at nine cafeterias and restaurants at City Hall, the State Capitol, the Fulton County courthouse and at the train stations. The students were largely middle class; for demonstrations they dressed handsomely, the women in dresses and the men in crisp shirts and sometimes even suits. Atlanta police made seventy-seven arrests that day.
May 17
On the sixth anniversary of Brown vs. Board of Education, more than 3,000 students marched downtown-the largest gathering of black students in Atlanta’s history. Their destination was the State Capitol, where, only four years before, defiant Georgia legislators had redesigned the Georgia State flag to place upon it the markings of the Confederate battle flag.
Mid-June
After staging a sit-in at Rich's - the largest department store at the time in Atlanta, students were arranged to meet with the store's owner, Richard Rich. But the outcome wasn't desirable.
Late Spring
While the AUC students were planning a widescale purchasing boycott of segregated downtown department stores, the chamber’s board refused to have a meeting with the students except Ivan Allen Jr. and Mill B. Lane.
Oct. 18
Lonnie King Jr. asked Martin Luther King Jr. to join the protest with the students.
Oct. 19
Black students mounted more protests, and Atlanta discovered its own vulnerability.” Lonnie King Jr. had asked Martin Luther King Jr. to join the sit-in.
On that day, Richard Rich, a chamber stalwart, sat down and wept after Martin Luther king., Jr., was arrested at Rich’s and led away in handcuffs. His crime: violating an anti-trepass law by refusing to leave Rich’s when he was denied service at a restaurant inside the store. Fifty-one students were arrested…Most students had agreed to remain in jail rather than post the $500 bail, a tactic they hoped would increase pressure on white merchants, including Martin Luther King, Jr.
Oct.20
As black protests mounted, Bill Hartsfield attempted to manage the final crisis of his twenty-three years as mayor..Hartsfield called a meeting with sixty black leaders..
After hours of intensive negotiations, Hartsfield agreed to drop the charges and to secure the release of the students from the city jail, and pledged to continue to negotiate with merchants for the desegregation of all downtown lunch counters.
He also promised to lobby for the release of those held in the county jail. In return, the students gave assurances that their demonstrations would cease for thirty days, which Hartsfield believed, was ample time for him to broker an agreement between the two sides.


UPTET 2020 registration process to end soon, how to apply UPTET 2020 will be conducted on December 22, 2019. The recruitment examination will be conducted in Hindi, English, Sanskrit and Urdu 19 Nov 2019, 17:12 UPTET 2020 registration process: The application process for the Uttar Pradesh Teachers’ Eligibility Test (UPTET 2020) will be closed on November 21, while the last date to pay fees is November 22, 2019. READ UPTET 2020 application process to end soon Interested candidates can apply through the official website- upbasiceduboard.gov.in. READ UPTET 2020 application process to end soon The recruitment examination will be conducted on December 22, 2019. READ UPTET 2020 application process to end soon The UPTET will be conducted in Hindi, English, Sanskrit and Urdu. READ UPTET 2020 application process to end soon The reserved category candidates belonging to the SC/ ST will get an age relaxation of 5 years, 3 years for the other backward class (OBC) category candidates. READ CISF Head Constable recruitment 2019: Female candidates can apply for 300 posts The applicants from the general and OBC categories will have to pay Rs 600 as application fees while the SC/ST category candidates will have to shell out Rs 400. READ UPTET 2020 application process to end soon The payment should be made through credit card, debit card, net banking. READ UPTET 2020 application process to end soon The application process will be closed on December 17. The interested candidates from North East region can apply till December 24, 2019 (5 pm). READ CISF Head Constable recruitment 2019: Female candidates can apply for 300 posts Those aspirants who meet the eligibility for both papers can submit options for both the papers. The exam will consist of objective type questions. READ UPTET 2020 application process to end soon UPTET is held to determine the eligibility for teaching posts in government schools in the state from class 1 to class 8. READ UPTET 2020 application process to end soon The exam comprises two papers — Paper 1 and 2. READ UPTET 2020 application process to end soon Paper 1 will be attempted by those candidates who wish to teach from class 1 to class 5 and paper 2 is meant for those candidates who intend to teach from class 6 to class 8. READ UPTET 2020 application process to end soon


Projects
About Me
<EMAIL_ADDRESS>Contact Me
Facebook Twitter Linkedin
My Blogs
MY BLOGS
Insert Blog Title
Date
This is where the content for the blog will go.
This is where the second paragraph will go.


Contents
function [sys,x0,str,ts] = ArticulatedVehicleSFunction(t,x,u,flag)
TireModel = VehicleDynamicsLateral.TirePacejka();
TireModel.a0 = 1;
TireModel.a1 = 2;
TireModel.a2 = 700;
TireModel.a3 = 5000;
TireModel.a4 = 80;
TireModel.a5 = 0;
TireModel.a6 = 0;
TireModel.a7 = 0.6;
TireModel.a8 = 0;
TireModel.a9 = 0;
TireModel.a10 = 0;
TireModel.a11 = 0;
TireModel.a12 = 0;
TireModel.a13 = 0;
VehicleModel = VehicleDynamicsLateral.VehicleArticulatedNonlinear();
VehicleModel.mF0 = 5200;
VehicleModel.mR0 = 2400;
VehicleModel.mF = 6000;
VehicleModel.mR = 10000;
VehicleModel.mM = 17000;
VehicleModel.IT = 46000;
VehicleModel.IS = 450000;
VehicleModel.lT = 3.5;
VehicleModel.lS = 7.7;
VehicleModel.c = -0.3;
VehicleModel.nF = 2;
VehicleModel.nR = 4;
VehicleModel.nM = 8;
VehicleModel.wT = 2.6;
VehicleModel.wS = 2.4;
VehicleModel.muy = 0.8;
VehicleModel.deltaf = 0;
VehicleModel.Fxf = 0;
VehicleModel.Fxr = 0;
VehicleModel.Fxm = 0;
VehicleModel.tire = TireModel;
switch flag,
case 0,
[sys,x0,str,ts]=mdlInitializeSizes();
case 1,
sys=mdlDerivatives(t,x,u,VehicleModel);
case 3,
sys=mdlOutputs(t,x,u,VehicleModel);
case { 2, 4, 9 },
sys = [];
otherwise
DAStudio.error('Simulink:blocks:unhandledFlag', num2str(flag));
end
function [sys,x0,str,ts]=mdlInitializeSizes()
sizes = simsizes;
sizes.NumContStates = 8;
sizes.NumDiscStates = 0;
sizes.NumOutputs = 8;
sizes.NumInputs = 4;
sizes.DirFeedthrough = 1;
sizes.NumSampleTimes = 1;
sys = simsizes(sizes);
x0 = [0 0 0 0 15 0 0 0];
str = [];
ts = [0 0];
function sys = mdlDerivatives(t,x,u,vehicle)
vehicle.deltaf = u(1);
vehicle.Fxf = u(2);
vehicle.Fxr = u(3);
vehicle.Fxm = u(4);
ModelFunction = @vehicle.Model;
MassMatrixFunction = @vehicle.MassMatrix;
sys = MassMatrixFunction(t,x)\ModelFunction(t,x,0);
function sys=mdlOutputs(~,x,~,~)
sys = x;
[Home] | [Template Articulated Simulink]


{% extends "2016-base.html" %} {% block body %}
Please contact the organizers for registration or other bootcamp related issues:
<EMAIL_ADDRESS><EMAIL_ADDRESS>Exercise: add your name to this list!
Use the information in the lectures on version control and documentation to expand this list. Fork the repository, make the changes then create a pull request.
This file is located in share/participants.md. Use the following format:
What should be cover during day 5:
Suggestions go here
First of all note that you don't actually need to fully generate this site yourself during the bootcamp. These instructions are here just to explain the process. But even if you don't generate the site itself you may still contribute to it via the GitHub web interface or after cloning locally.
The website
is generated from the files in the web directory of the bootcamp-central repository
via the pyblue python package.
For it work you would need to have both Python
and the pip package manager installed.
Clone the repository:
git clone https://github.com/biostars/bootcamp-central
Install pyblue from last year:
pip install pyblue==2016.6.2
You can now view the site as HTML with:
cd bootcamp-central
the default Makefile
action is to run the server:
make
or
pyblue -r web/2016
This will start a web server on your computer and you can use the browser to view the contents of the site. This is used while developing the site.
http://localhost:8080
To generate a published version of the site add the -o
parameter
with a directory name that is meant to store the output destination
pyblue -r web/2016 -o /final/directory
{% endblock %}


This module contains the parameters of the dashboard that have to be defined by the developer in order to tailor the tool to the specific needs of the future users. In the following we will look at the parameters needed to:
- get the medical and geometry data,
- check the medical and geometry data,
- define the charts and maps, feed them with the correct data and define specific interaction,
dev/dev-defined.js
and are stored in the global variable g
.
g
stores other Objects as well that are not defined by the developer but that are the results of the processing and interactions. g
can be accessed through your developer browser interface.As a reminder, two other files are crucial when setting up a new version of the Dashboard which are:
- the 'index.html' file which defines the divs and the positions of the charts and maps, and
- the module:module-lang ('lang/module-lang.js') which contains all the text that have to be displayed and its various translations.
- Since:
- 1.0
- TODO
-
- Limit list of parameters in g.
- Implement 'module_list' check to run or not the modules.
Requires
- module:lang/lang.js
Members
-
static,constantmodule:g.geometry_dataObject
main-loadfiles -
Stores geometry data parsed from the files in g.geometry_filelist and by the function module:main_loadfiles~queue_geometry.
-
static,constantmodule:g.geometry_filelistObject
dev-defined -
Lists the geojson files when provided locally and gives their address. For each
admN
X in module:g.medical_headerlist there must be a corresponding geometry file listed here.
Each element in the object is coded in the following way:admNX: './data/admnx.geojson',
- TODO
-
- Should be rethought via a data parser that can take either files or request files via APIs such as ArcGIS Online or other geoservers.
-
static,constantmodule:g.geometry_keylistArray.<String>
main-loadfiles -
Stores keys of each administrative level extracted from the module:g.geometry_filelist.
Processing triggered in module:main_loadfiles~read_commons. -
static,constantmodule:g.geometry_levellistObject
main-loadfiles -
Stores a number associate with administrative level (0 is the wider, and the bigger is the lowest/smaller).
Processing triggered in module:main_loadfiles~read_commons. -
static,constantmodule:g.geometry_loclistsObject.<Array.<String>>
main-loadfiles -
Stores the name of the administrative elements extracted from module:g.geometry_data by module:main_loadfiles~queue_geometry. Names are formatted in the following way:
'AdmN0', 'AdmN1',...
in order to manage efficiently pyramids and possible duplicates at lowest administrative levels.
Each administrative level is stored in a different Object.
Processing triggered in module:main_loadfiles~read_commons. -
static,constantmodule:g.geometry_subnumObject
main-loadfiles -
Stores the number of lowest administrative level within a given administrative level (eg. number of AdmN3 in AdmN2, AdmN1 and AdmN0). This is used to compute completeness module:g.medical_completeness in module:module_datacheck~dataprocessing > module:module_datacheck~completenessCheck.
Processing triggered in module:main_loadfiles~read_commons. -
static,constantmodule:g.mask_bypassObject
main-loadfiles -
Checks whether module:g.mask_filelist has been defined or not, and thus decide whether necessary to bypass the extra layers parsing step.
-
static,constantmodule:g.mask_dataObject
main-loadfiles -
Stores mask data parsed from the files in g.mask_filelist and by the function module:main_loadfiles~queue_mask.
-
static,constantmodule:g.mask_filelistObject
dev-defined -
Other layers can be parsed here to be displayed on the map (masks, admin divisions, labels...).
The elements are coded in the following way:layer_key: './data/layer.geojson'
- TODO
-
- Should be rethought via a data parser that can take either files or request files via APIs.
-
staticmodule:g.medical_completenessObject
module-datacheck -
Stores a percentage of completeness for each combination of administrative level and epiweek. All the module:g.medical_data is browsed in module:module_datacheck~dataprocessing. Percentage calculation is performed by module:module_datacheck~completenessCheck, combining records counting and numbers of lowest administrative division per administrative division stored in module:g.geometry_subnum.
Each combination of administrative level and epiweek is stored in a different Object.
Processing triggered in module:module_datacheck~dataprocessing. -
staticmodule:g.medical_currentdiseaseString
main-core -
-
static,constantmodule:g.medical_dataObject
main-loadfiles -
Stores medical data parsed from module:g.medical_filecurrent by module:main_loadfiles~queue_medical and processed via module:main_loadfiles~read_medical.
-
static,constantmodule:g.medical_datatypeString
dev-defined -
Defines the type of medical data parsed in the dashboard.
Currently accepted values are:surveillance
(aggregated) oroutbreak
(linelist).
-
static,constantmodule:g.medical_diseaseslistArray.<String>
dev-defined -
Defines an array of Disease to be used as an
inlist
check in module:module_datacheck~dataprocessing. In case the list of disease to follow is not predefined, an empty array must be parsed and the list of diseases will be created in module:module_datacheck~dataprocessing. -
static,constantmodule:g.medical_filecurrentString
main-loadfiles -
Stores the name of the file currently being read. Starts with the first file in the module:g.medical_filelist and then module:main_loadfiles~generate_display gives the user the option to choose between all the available files.
-
static,constantmodule:g.medical_filelistArray.<String>
main-loadfiles -
Lists files in the datafolder that matches the extension criteria (currently .txt | .TXT | .csv | .CSV) in the module:g.medical_filelist_raw.
-
static,constantmodule:g.medical_filelist_rawArray.<String>
main-loadfiles -
Lists the medical data files in the module:g.medical_folder folder path (uses Node server-side capability).
-
static,constantmodule:g.medical_filetypecurrentString
main-loadfiles -
Stores the type of the file about to be read from module:g.medical_filecurrent in order to use the correct parsing method in module:main_loadfiles~queue_medical.
-
static,constantmodule:g.medical_folderString
main-loadfiles -
Gets the medical data folder path (uses Node server-side capability).
-
static,constantmodule:g.medical_headerlistObject
dev-defined -
Lists the keys used to refer to specific module:g.medical_data fields. It makes the link between headers in the data files and unambiguous keys used in the code.
Each element in the object is coded in the following way:key_in_dashboard: 'header_in_datafile',
Currently implemented keys are:- General keys
epiweek
for epidemiological week: format YYYY-WW,admN
X for names of administrative/health division levels (X being replaced by 0, 1, 2...). Multiple instances allowed.pop
for absolute population figures.
- Outbreak keys (not limited to
outbreak
module:g.medical_datatype but generally observed in this context)age
for patient age in years,sex
for patient sex (eg. 1 = Male, 2 = Female),preg
for pregnant patient (eg. 1 = Pregnant, 2 = Not Pregnant or N/A),sev
for patient dehydration severity (eg. A = Light, B = Moderate, C = Severe),dur
for patient stay duration in days,out
for patient stay outcome (eg. 1 = Cured, 2 = Dead, 3 = Interrupted F/U, 4 = Transfered).
- Surveillance keys (not limited to
surveillance
module:g.medical_datatype but generally observed in this context)disease
for disease name,fyo
for under or over Five Year Old indicator (eg. u = Under, o = Over),case
for number of cases overall,mcase
for number of male cases,fcase
for number of female cases,death
for number of deaths overall,mdeath
for number of male deaths,fdeath
for number of female deaths,
Example
g.medical_headerlist = { epiwk: 'epiweek', admN1: 'ZS', disease: 'disease', case: 'nb_cases' };
- General keys
-
static,constantmodule:g.medical_keylistArray.<String>
main-loadfiles -
Lists from module:g.medical_headerlist the keys used to refer to specific module:g.medical_data fields. Defined in the Dashboard (might be different from the headers in the data files) in user-defined module:g.medical_headerlist.
-
static,constantmodule:g.medical_loclistsObject.<Array.<String>>
module-datacheck -
Stores the name of the administrative elements extracted from module:g.medical_data by module:module_datacheck~testvalue. Names are formatted in the following way:
'AdmN0', 'AdmN1',...
in order to manage efficiently pyramids and possible duplicates at lowest administrative levels. They are matched against names in module:g.geometry_loclists and names not corresponding are discarded.
Each administrative level is stored in a different Object.
Processing triggered in module:module_datacheck~dataprocessing. -
static,constantmodule:g.medical_readObject.<String, Object>
dev-defined -
Lists the keys from module:g.medical_headerlist that require custom parsing (eg. translate numbers into words).
Each element in the object is coded in the following way:key_in_dashboard: {category1_in_medicaldata: 'user-readable_output1', category2_in_medicaldata: 'user-readable_output2', ...},
Currently implemented keys are:sexpreg
which is a combination ofsex
andpreg
from the key list,sev
,dur
,out
,fyo
,
- TODO
-
- Why is it in a function?
-
staticmodule:g.medical_weeklistArray
module-datacheck -
Stores the list of weeks from
epiwk
fields of module:g.medical_data.
Processing triggered in module:module_datacheck~dataprocessing. -
staticmodule:g.medical_yearlistArray
module-datacheck -
Stores the list of years from
epiwk
fields of module:g.medical_data.
Processing triggered in module:module_datacheck~dataprocessing. -
staticmodule:g.module_chartwarperObject
module-chartwarper -
Stores all the global variables used by the module:module_chartwarper. To simplify, variables in the 'sub-module' domain will only appear there.
-
staticmodule:g.module_colorscaleObject
module-colorscale -
Stores all the global variables used by the module:module_colorscale. To simplify, variables in the 'sub-module' domain will only appear there.
-
staticmodule:g.module_datatableObject
module-datatable -
Stores all the global variables used by the module:module_datatable. To simplify, variables in the 'sub-module' domain will only appear there.
-
staticmodule:g.module_interfaceObject
module-interface -
Stores all the global variables used by the module:module_interface. To simplify, variables in the 'sub-module' domain will only appear there.
-
staticmodule:g.module_introObject
module-intro -
Stores all the global variables used by the module:module_intro. To simplify, variables in the 'sub-module' domain will only appear there.
-
staticmodule:g.module_langObject
module-lang -
Stores all the global variables used by the module:module_lang. To simplify, variables in the 'sub-module' domain will only appear there.
-
staticmodule:g.module_multiadmObject
module-multiadm -
Stores all the global variables used by the module:module_multiadm. To simplify, variables in the 'sub-module' domain will only appear there.
-
static,constantmodule:g.population_bypassObject
main-loadfiles -
Checks whether module:g.population_filelist has been defined or not, and thus decide whether necessary to bypass the population data parsing step.
-
static,constantmodule:g.population_dataObject
main-loadfiles -
Stores population data parsed from the files in g.population_filelist and by the function module:main_loadfiles~queue_population.
-
static,constantmodule:g.population_filelistObject
dev-defined -
Gives the population file when provided locally and give its address. If
pop
is included in module:g.medical_headerlist there must be a corresponding population file here.
The element is coded in the following way:pop: './data/pop.csv'
- TODO
-
- Should be rethought via a data parser that can take either files or request files via APIs.
-
static,constantmodule:g.population_headerlistObject
dev-defined -
Lists the keys used to refer to specific module:g.population_data fields. It makes the link between headers in the data files and unambiguous keys used in the code.
Each element in the object is coded in the following way:key_in_dashboard: 'header_in_datafile',
Currently implemented keys are:admNx
for administrative or medical division name, format:Adm1_name, Adm2_name...
,pop
for population.
-
static,constantmodule:g.population_keylistObject.<Array.<String>>
main-loadfiles -
Stores keys of each administrative level extracted from the module:g.population_filelist.
Processing triggered in module:main_loadfiles~read_commons. -
static,constantmodule:g.population_loclistsObject.<Array.<String>>
main-loadfiles -
Stores the name of the administrative elements extracted from module:g.population_data. Names should already be formatted in the following way:
'AdmN0', 'AdmN1',...
in the source file in order to manage efficiently pyramids and possible duplicates at lowest administrative levels.
Each administrative level is stored in a different Object.
Processing triggered in module:main_loadfiles~read_commons. -
static,constantmodule:g.population_popdataObject.<Array.<String>>
main-loadfiles -
Restores population figures from module:g.population_data in order that each administrative level is stored in a different Object.
Processing triggered in module:main_loadfiles~read_commons. -
staticmodule:g.viz_currentvaluesObject
main-core -
Stores values currently displayed on the map. One object per administrative division.
Defined in module:main_core~chartBuilder >multiadm
and populated by module:main_core~valueAccessor. -
static,constantmodule:g.viz_definitionObject.<Object>
dev-defined -
Lists the charts and maps to be produced by module:main-core as well as defines their main characteristics.
Each element in the object contains the following sub-elements:chart_id: { // Defined by the developer: domain_type: {String}, // 'custom_ordinal' or 'custom_linear' or 'none', chart_type: {String}, // 'bar' or 'multiadm' or 'row' or 'stackedbar' or 'pie' or 'series' or 'table', dimension_type: {String}, // 'auto' or 'custom' or 'shared', dimension_setup: {Array}, // [chart_id or dimkey,'auto' ot 'custom'] (mandatory if 'shared'), group_type: {String}, // 'auto' or 'custom' or 'none', group_setup: {Array}, // [datakey,datakeyopt] ('datakey' mandatory if 'surveillance', 'datakeyopt' if 'stackedbar'), display_axis: {Object}, // {x:'labelx',y:'labely'} (for x/y-type charts), display_colors: {Array.<Integer>}, // Refers to colors in g.color_domain, display_intro: {String}, // 'top' or 'bottom' or 'right' or 'left' or 'none', display_idcontainer: {String}, // To display buttons on a div different from: chart-'chart_id' buttons_list: {Array.<String>}, // ['reset','help'] - any, all or none of the two for most of charts plus 'expand','lockcolor' and 'parameters' for 'multiadm' charts, sync_to: {Array.<String>}, // ['chart_id's] - sync filtering with other charts // Processed by the dashboard: chart: {Object}, // module:main\_core~chartInstancer & module:main\_core~chartBuilder dimension: {Object}, // module:main\_core~dimensionBuilder domain: {Array}, // module:main\_core~domainBuilder group: {Object}, // module:main\_core~groupBuilder }
Each element is detailed in the following.chart_id
, 'chart-'chart_id
must match adiv id
in the index.html file (the dashboard layout).domain_type
Definitions in: module:main_core~domainBuilder.
If =/='none'
, a custom domain is built. Thechart_id
is used to select the domain building method.chart_type
Definitions in: module:main_core~chartInstancer and module:main_core~chartBuilder (neither of these are properly declared as a method...).dimension_type
Can be: 'auto' or 'custom' or 'shared' - Definitions in module:main_core~dimensionBuilder.- If ==
'auto'
- the dimension is assumed not to be shared - that means that'auto'
is the dimension building method andchart_id
is used to select the field to filter in module:g.medical_data. - If ==
'custom'
- the dimension is assumed not to be shared - that means that'chart_id'
is the dimension building method and it is used as well to select the field to filter in module:g.medical_data (when not overridden by the dimension builder definition). - If ==
'shared'
-dimension_setup
parameter is compulsory.dimension_setup[0]
is thechart_id
of the chart with which the dimension is shared or the common identifier for the dimensiondimension_setup[1]
can be'auto'
or'custom'
(just like a non-'shared' dimension...)- If ==
'auto'
that means that'auto'
is the dimension building method anddimension_setup[0]
is used to select the field to filter in module:g.medical_data. - If ==
'custom'
that means thatdimension_setup[0]
is the dimension building method and it is used as well to select the field to filter in module:g.medical_data (when not overridden by the dimension builder definition).
- If ==
[chart_id].dimension
in the module:g.viz_definition object. Whereas shared dimensions are stored under[dimension_setup[0]].dimension
.- If ==
group_type
Can be: 'auto' or 'custom' or 'shared' (or 'none' for the data table) - Definitions in module:main_core~groupBuilder.
- If ==
'auto'
, that means that'auto'
is the group building method. - If ==
'custom'
, that means that'chart_type'
is the group building method.
'surveillance'
-group_setup
parameter is compulsory. It is an Array where:group_setup[0]
is used to select the field to count or sum in module:g.medical_data. NB: In a'outbreak'
setting, records are counted from the patient list without a reference to a field.group_setup[1]
is used to select the field to create categories for stacked charts (chart_type == stackedbar
. NB: Stacked chart have not been used yet in a'outbreak'
setting.
- If ==
Example
g.viz_definition = { multiadm: { domain_type: 'none', chart_type: 'multiadm', dimension_type: 'custom', group_type: 'custom', group_setup: ['case'], display_colors: [0,1,2,3,4,5], display_intro: 'bottom', buttons_list: ['reset','help','expand','lockcolor','parameters'], }, disease: { domain_type: 'none', chart_type: 'row', dimension_type: 'custom', group_type: 'custom', group_setup: ['case'], display_axis: { x:g.module_lang.text[g.module_lang.current].chart_disease_labelx, y:g.module_lang.text[g.module_lang.current].chart_disease_labely }, display_colors: [2], display_intro: 'right', buttons_list: ['help'], }, case_bar: { domain_type: 'custom_ordinal', chart_type: 'bar', dimension_type: 'custom', dimension_setup: ['epiwk','auto','case'], group_type: 'auto', group_setup: ['case'], display_axis: { x:g.module_lang.text[g.module_lang.current].chart_case_labelx, y:g.module_lang.text[g.module_lang.current].chart_case_labely }, display_colors: [4,2], display_intro: 'top', display_idcontainer: 'chart-case_bar', buttons_list: ['reset','help'], }, case_lin: { domain_type: 'custom_linear', chart_type: 'series', dimension_type: 'shared', dimension_setup: ['epiwk_lin','custom','case'], group_type: 'auto', group_setup: ['case'], display_axis: { x:g.module_lang.text[g.module_lang.current].chart_case_labelx, y:g.module_lang.text[g.module_lang.current].chart_case_labely }, display_colors: [4,2], display_intro: 'top', display_idcontainer: 'chart-case_lin', buttons_list: ['help'], }, year: { domain_type: 'none', chart_type: 'pie', dimension_type: 'custom', group_setup: ['case'], group_type: 'auto', display_intro: 'left', display_idcontainer: 'chart-year', buttons_list: ['reset','help'], }, table: { domain_type: 'none', chart_type: 'table', dimension_type: 'custom', group_type: 'none', display_intro: 'top', buttons_list: ['help'], } };
-
staticmodule:g.viz_keylistArray
main-core -
Lists
id_chart
from module:g.viz_definition (defined in de/dev-defined.js). -
static,constantmodule:g.viz_timelineString
dev-defined -
Defines the chart used as a reference for time-related interactions.
-
static,constantmodule:g.viz_timeshareArray.<String>
dev-defined -
Defines the charts that are using time dimensions and that should be synchronized with the reference defined with module:g.viz_timeline.


1. I love to laugh.
2. I like cheese.
3. Building things gives me joy.
4. I like red.
5. I'm usually laid-back.
6. Hard work doesn't phase me.
7. When you make a typo, the errorists win.
8. I love being outside.
9. Coding is fun.
10. Coding is challenging.


Psalms 85:3
Thou hast taken away all thy wrath: thou hast turned thyself from the fierceness of thine anger.


JAKOB THE LIAR *** (out of five stars) A review by Jamey Hughton
Starring-Robin Williams, Alan Arkin, Bob Balaban, Hannah Taylor-Gordon, Liev Schreiber and Armin Mueller-Stahl Director-Peter Kassovitz Rated PG Sony
MOVIE VIEWS by Jamey Hughton http://Welcome.to/MovieViews
The Holocaust. A caring soul trying to improve morale around him. And certain comic undertones during a tragic time. All of these themes are found in the Oscar-winning Foreign film Life is Beautiful, which put gifted Italian clown Roberto Benigni in the American spotlight. Fresh off the heels of Benigni's triumph, another film rolls into theaters with very similar messages - and a big-name star to guide it.
The title character in Jakob the Liar is Jakob Heym (Robin Williams), a Polish Jew living in a desolate ghetto in 1944. One night, Jakob hears a radio transmission that could bring his fellow ghetto-dwellers some hope: Russians are only 400 kilometers away, and the war could soon come to an end. Jakob tries to contain his secret, but soon it has leaked out and gotten terribly blown out of proportion by the other Jewish residents. He sees that this one little news bulletin has substantially lifted the group's spirit. And so, he begins to give them hope by telling false stories about the approaching Russians. All of it is basically hooey, but the suicide rate is down, and everyone seems to be more optimistic about the future.
I might as well come out of the closet: I was that guy who liked Patch Adams. Audiences sure did love the film, but it got some of the worst critical reception of the year. With Jakob the Liar, moviegoers may be turned off by the unappealing premise (not to mention the fact that the subject has already been thoroughly explored). While full of mixed messages and meaty flaws, this film does manage to balance itself quite admirably - especially with all of the post-Life is Beautiful pressure. The atmosphere, as envisioned by director Peter Kassovitz, is successfully portrays the horror of the Holocaust in an effective and subtle manner. It's too bad that often during the 2nd act, he doesn't allow the audience room enough to appreciate all that.
Williams, in a well rounded and laid-back performance, manages to contain his usual goofiness with style for virtually every minute of the running time. The few moments in which he truly addresses his funny side are shared with a 10-year old runaway Jewish girl named Lina (Hannah Taylor-Gordon). Williams improvises a radio transmission with Winston Churchill with restrained but hilarious success. The supporting cast, full of veteran character actors, is easily one of the aspects to marvel at in Jakob the Liar. Alan Arkin plays the pessimistic Frankfurter, Bob Balaban is Jakob's timid friend Kowalsky, and Armin Mueller-Stahl is the wise Professor Kirschbaum. While all of the actors are perfect in their roles, the surprise stand-out is Liev Schreiber (Scream 2), who plays the feisty boxer Mischa with spot-on accuracy.
At first, Jakob the Liar moves at such a blistering pace that it becomes exceedingly difficult to properly accept the surroundings. The gritty, unattractive look of the Polish ghetto makes it a substantial problem for any comedy to work. But Kassovitz knows this, and his period dramedy is certainly filled with more dramatic moments. This is not a Holocaust comedy with a light touch. If that was the goal in mind, the environment for Jakob and his companions would be much less bleak & somber and far more warm & fuzzy. The mood finally starts working in the film's favor toward the end, when the real issues are dealt with. During these glorious moments, Kassovitz reaches a degree prosperity that rivals and even surpasses a few of Benigni's achievements in his film.
Unfortunately, much of Jakob the Liar is too messy and undefined to match the success of Life is Beautiful. Still, this determined piece of work is highly respectable. And Williams will return to family comedy this Christmas when he stars in Bicentennial Man. Hopefully, that familiar formula will set the talented comedian back on track, with audiences and critics alike.
(C) 1999, Jamey Hughton
* * * * * * * * * * * * * * * MOVIE VIEWS by Jamey Hughton http://Welcome.to/MovieViews <<<<<<<<<<<<<<<>>>>>>>>>>>>>>>
Contact Jamey at<EMAIL_ADDRESS>The review above was posted to the
rec.arts.movies.reviews newsgroup (de.rec.film.kritiken for German reviews).
The Internet Movie Database accepts no responsibility for the contents of the
review and has no editorial control. Unless stated otherwise, the copyright
belongs to the author.
Please direct comments/criticisms of the review to relevant newsgroups.
Broken URLs inthe reviews are the responsibility of the author.
The formatting of the review is likely to differ from the original due
to ASCII to HTML conversion.
Related links: index of all rec.arts.movies.reviews reviews


Nyzo version 537 (commit on GitHub) improves the consensus process and prepares for the transition from version 0 to version 1 of the blockchain.
This version only modifies verifier behavior significantly. While the code involved also affects other run modes of Nyzo, only verifiers will benefit from upgrading to this version.
Please note that this version does not attempt to correct the memory-pressure issues that initially caused verifiers to become unresponsive and slow down cycle processing. It does attempt to correct, from multiple angles, the stalls and ultimate one-block fork that caused so many verifiers and sentinels to fail. While slowdowns in block processing are undesirable, they are of little consequence as long as they do not lead to full stalls. These memory-pressure issues will be addressed in the near future.
BalanceListManager adds three fields: blockchainVersion, unlockThreshold, and unlockTransferSum. The blockchain version is currently 0. The changes necessary to lock the block-1 wallets will move the blockchain to version 1.
Accessors have been added for the three new fields.
So that the version can be used to guide further reading of the balance-list data structure, it has been placed as the very first field in the serialized binary structure. While this field was not actually present in the initial balance-list data structure, the layout of the serialized form allows us to pretend that it was present. The ShortLong class is used to encapsulate this behavior. 2 bytes of the space initially allocated for block height have been reallocated to store the blockchain version. As these bytes were the most-significant bytes of the block height (representing the largest powers of 2 in the binary representation), they have all represented values of 0 for all blocks produced so far, so this representation is naturally backward-compatible. The unlockThreshold and unlockTransferSum are at the end of the serialized data structure, and they are only read for version-1 or later balance lists.
The changes to the serialization method mirror the changes to the deserialization method.
The cycleAccountIdentifier has been added to BalanceListItem. This location was chosen because the transferIdentifier was already defined in this class.
In BalanceManager, the seedAccountIdentifier has been exposed as a public variable. It was exposed to allow its use in a script to calculate total coins in circulation.
In approvedTransactionsForBlock(), the balance list is fetched slightly earlier to allow its use in enforcing locked-wallet restrictions.
The enforceLockingRules() method removes transactions that do not comply with the rules for locked accounts. In any block, if the sum of transactions from locked accounts exceeds the allowable amount, then all such transactions are removed from the block. This logic is important. If it does not operate properly, we might be able to transfer coins out of these wallets more quickly than we should be able to transfer them.
In the Block class, constants have been added for minimumBlockchainVersion and maximumBlockchainVersion. Currently, the only supported blockchain version is 0, so it is both the minimum and maximum.
The blockchainVersion field has been added to the Block data structure, and all 3 constructors now require the blockchain version.
The limitBlockchainVersion() method ensures that the blockchain version is always a version that this software knows how to process.
An accessor has been added for blockchain version.
In getByteSize(), FieldByteSize.blockHeight has been replaced with FieldByteSize.combinedVersionAndHeight. Both of these constants have a value of 8, but this change improves the readability of the code.
In serialization of blocks, the space previously occupied by the height is now occupied by the combined version and height. This is the same pattern used for balance lists.
In getMinimumVoteTimestamp(), two blocks are reserved specifically for new verifiers in each span of 50 blocks. In these blocks, a significant delay is added to voting for all current verifiers. The final block of the span, with a 40-second delay, will be used to allow sentinel broadcast of new-verifier blocks to mitigate denial-of-service attacks against verifiers trying to enter the cycle. The sentinel will be modified in the near future to complete this functionality.
Deserialization of blocks also accounts for the new blockchainVersion field.
The conditions in balanceListForNextBlock() have been restructured to make the logic easier to follow. Also, the previousUnlockThreshold and previousUnlockTransferSum have been added and are calculated for blockchain version 1.
In the vast majority of cases, the blockchain version will not change from one block to the next. The BlockchainVersionManager will handle all transitions to higher-numbered blockchain versions. Currently, the blockchain version is always fetched from the previous balance list, which will keep the blockchain at version 0 until the upgrade is implemented. Also, the unlock threshold and transfer sum are obtained from the previous block. These are both cumulative values.
In the transaction loop that adjusts balances and determines block fees, separate sums of organic transaction fees and transactions from locked accounts are now calculated. The organic transaction fees will be added to the unlock threshold, and the transactions from locked accounts will be added to the transfer sum.
Transfer of some fees to the seed account will be implemented in another update. This update is being released with incomplete functionality for blockchain version 1. This is being done to allow more time for community code review before the changes take effect, and it is being done to allow for continued release of bug fixes.
The version-1 account fee modifications have been implemented. This will eliminate account fees for most accounts while promoting faster removal of accounts with very low balances.
For version 1 of the blockchain, the unlock threshold and transfer sum are accumulated. For version 0, they are both kept at 0.
Two options have been added to BlockFileConsolidator. These options will be implemented in a future version to allow operators of verifiers more choice in how storage and compute resources are utilized for maintaining historical blockchain data. While decentralized storage of a full history of the blockchain is important for the cycle as a whole, it is not necessarily important for each individual verifier to maintain a full history.
In BlockManager, lastVerifierJoinHeight is now stored. This follows the same pattern as lastVerifierRemovalHeight, and it is used to provide a rough idea of when the cycle might be accepting new verifiers.
In BlockVoteManager.registerVote(), better checking of the Message argument has been added to avoid a null-pointer exception.
BlockchainVersionManager will manage the upgrade from version 0 to version 1 of the blockchain. CycleTransactionManager will track all proposed cycle transactions.
In FieldByteSize, combinedVersionAndHeight has been added to represent the combined space that blockchain version and block height now occupy in the serialized forms of blocks and balance lists.
LockedAccountManager catalogs all accounts publicly known to be controlled by the Nyzo team. This includes the official Nyzo verifiers, some "anonymous" verifiers that have been mentioned on Discord, the Genesis account, and all block-1 distribution accounts. The comments in the code provide a more detailed explanation.
To improve lookup efficiency, the locked accounts are stored in a Set.
The main() method of LockedAccountManager is a script that provides information about Nyzo circulation at the local frozen edge.
The script output appears as follows.
The isSubjectToLock() method indicates whether a transaction must comply with the locking rules in version 1 of the blockchain. Seed transactions are not subject to locking, and transactions to the cycle account are not subject to locking. All other transactions from locked accounts are subject to locking.
The id() method exists to make the hard-coded locked-account list more succinct.
The maximum_conncurrent_connections_per_ip can now be specified in the preferences file. This is a constant that we modified manually several times on the official Nyzo verifiers, and we are committed to running exactly the same code that we release to the community.
The ShortLong class provides structure for the blockchain version and block height for blocks and balance lists. For the blockchain version, it uses the top two bytes that were previously allocated to block height. This leaves 6 bytes for the block height, which still allows for over 60 million years of blocks.
TestnetGenesisBlockCreator now specifies a blockchain version of 0 for the first block. We plan to test the upgrade from version 0 to version 1 on several testnets before its scheduled deployment on the production blockchain. Also, a multiplication by 1L has been eliminated to silence an IDE warning.
Several modifications have been made to the Transaction class to prepare for transactions from the cycle wallet. Cycle transactions will require a list of signatures — more than 75% of the current cycle — to be approved. Several other pieces still need to be implemented to support cycle transactions.
The signatureIsValid() method has been modified to ensure that single signatures are only accepted for seed and standard transactions. This is not an actual security concern for the cycle wallet, as the 0000...0002 wallet is obviously a wallet for which a private key is not available, but it is still a reasonable precaution to reduce the potential for problems if other multi-signature transactions are added in the future.
In UnfrozenBlockManager, the current vote is now persisted to disk. This ensures that the verifier will not cast an arbitrary vote when it restarts that contradicts a previous vote.
In the updateVote() method, the newVoteBlock variable has been eliminated. This variable was only used as a temporary store of the hash of the vote, and its use was confusing and unwieldy. Now, the hash of the vote is immediately stored in the newVoteHash variable in all cases.
When this verifier does not yet have enough information to attempt to reach consensus, it now falls back to its previous vote before attempting to calculate a vote independently. Most of the time, this logic is totally unnecessary. If many verifiers restart while the blockchain is stalled, this will help to ensure that the verifiers do not inadvertently reach consensus on a new block when consensus has already been reached on a different block. While this is not the only safeguard that will be put in place in response to the recent consensus issues, this safeguard, on its own, would have easily avoided the recent issues that caused so many verifiers to be dropped from the cycle.
Whenever the vote changes, it is written to a file so that it will be available if the verifier restarts.
In Verifier, a small block-vote-request process has been reintroduced. This old block-vote-request process was eliminated previously because it added significant additional strain to the cycle. This is a much lower-intensity process than the previous process, querying no more than 10 votes every 4 seconds. Block-vote requests are especially useful for one specific reason: if a group of verifiers have frozen a block and have moved on to working on the next block, they will no longer proactively send votes for the block that they think the cycle has already frozen. These requests allow the verifiers stuck on the previous block to re-involve the verifiers in the next block in the previous block's consensus process, giving the verifiers on the next block the opportunity to encourage the other verifiers to move forward to the correct block. This safeguard, on its own, would also have avoided the recent issues that caused so many verifiers to be dropped from the cycle. This vote-request process also helps to reestablish lost connections to verifiers that have suffered temporary outages, and it will enable faster recovery in many cases for verifiers that suffer tracking issues.
The actual vote requests are made to random in-cycle verifiers. As the comment explains, this random process is less efficient than a targeted process would be, but it also provides a simple robustness that is desirable.
Blocks are currently created with the same blockchain version as their predecessors. When BlockchainVersionManager is complete, it will handle the transition from version 0 to version 1.
The last join height is displayed just before the last removal height in the status response.
The sentinel does not attempt to upgrade the blockchain version, and it will never need to do so. This will be explained further when the upgrade process is fully implemented.
ShortLongTest stores and retrieves 40,000 combinations of values in ShortLong objects to ensure no loss of information occurs due to this data structure.
For backward compatibility with version-0 blocks, the ShortLong encoding is also checked for equality against raw long values.
A new method for printing Nyzo amounts has been introduced to PrintUtil. This method is used in the LockedAccountManager script that shows how many coins are currently in circulation.


Landing Page
Special Projects
This story is part of a series of specially designed stories that represents some of the best journalism The Post has to offer. Check out the rest of the special projects here.
05.31.18
I walked across the stage at Green High School, was handed my diploma and gave a hug to my then-girlfriend who handed me a graduation rose on stage. It was a cute moment, the crowd “aww-ed” and that was that. I was officially a high school graduate, just like you. The next morning at 6 a.m., my dad and I got into his car and made our way to Athens for orientation.
After getting to Athens at about 9:30 a.m., I had forgotten three papers I needed. I forgot my driver’s license and what I wanted to change my major to (It was communications studies. I changed my major four times freshman year. I ended up back in communications studies, my dad was so mad).
My collegiate career was off to a great start. My dad, understandably vexed with my forgetfulness, huffed and puffed until everything was sorted out. I started biting my nails, as I always do when I am a little bit anxious, and then everything ended up being OK right as blood started to make its way through the cuticles of my thumb.
If you’re reading this I assume you might be a little anxious too.
Orientation is scary. For roughly 30 hours, you get a whiff of what the next four years may be. Here’s the catch: It isn’t at all what it will be. Not in the slightest. Your hand isn’t held after your loved ones drive away from helping you move in this August, and there isn’t a tight schedule you’re on. It’s just you. I spent my first night of college alone in Tanaka 325 watching cat videos. I wouldn’t have done any other way.
But that’s a few months from now. Right now you’re just worried about what orientation is. And it’s great that you decided to pick up a copy of The Post or visit our website. So as someone who is a cynical senior, I just want to let you know what to expect over your first 30 hours here.
You’ll get lost. It’s cool to do that, though. Get lost, and you will end up finding something cool by accident. You will also probably have an existential crisis while you’re here. That’s totally OK, and it’s completely normal. Your first few months here are super confusing and weird – c’est la vie. Try to make friends, too. I can’t remember a single person from my orientation group. I think I see this one person from time to time who I sat next to through the whole thing, but we never spoke.
He is the closest friend I have made here.
Jokes aside, as you are confused and trying to figure out how to read a DARS, just remember that this whole college thing gets easier, and it also gets harder. That’s the whole point of why you’re here. This isn’t an easy time, it’s confusing and sweaty and dumb sometimes, but as cliché as it is, it’s the best time of your life. So please, enjoy it.
Landing Page
This story is part of a series of specially designed stories that represents some of the best journalism The Post has to offer. Check out the rest of the special projects here.