text:
Plugin
------

### [YouCompleteMe](https://github.com/Valloric/YouCompleteMe)

#### General Semantic Completion

You can use Ctrl+Space to trigger the completion suggestions anywhere,
even without a string prefix. This is useful to see which top-level
functions are available for use.

#### C-family Semantic Completion

1.  `F8`: For those code needs special C lib, run `:YcmGenerateConfig`
    (has mapped to `F8`) to create `.ycm_extra_conf.py` in the root
    directory of this project. In this case, you need a Makefile to
    identify C flags. Please restart vim after running `F8`.
2.  You can type `F4` to see to see if any errors or warnings were
    detected in your file, and `,ff` try to fix it.
3.  Notely, for python, you should

repository: POFK/VimTX

gha_language: Vim script

repo_name: POFK/VimTX


text:
Change Log for GHG Monitoring Tower Program
===========================================

v1.2.2 (2015-09-14)
-------------------

### Issues Fixed

* Report correct value for IRGA CO2 signal. Had been reporting untracked value,
  standard deviation of CO2 mass concentration, mistakenly instead.

v1.2.1 (2015-09-14)
-------------------

### Enhancements

* Add telemetry reporting via HTTP to ScadaBR instance for most things in the
  `stats5` table. A few variables are reported as grab-samples instead of
  averages to avoid significant back-end modifications.
* Also report self-diagnostics: system voltage input & logger panel temperature

v1.2 (2015-07-28)
-----------------

### Issues Fixed

* Correct multiplier used to determine total PAR flux:
    * Only total flux, not flux density was affected
    * Multiplier was 10x too small
    * Issue has existed since initial deployment (surfaced in fc4c5d446c)
* Correct regression introduced by 1176377a2d (introduced in v1.0):
  variable `skipped_5s_scans` reflects reporting scan, not soil (5sec) scan
* ScadaBR reports are no longer malformed (caused by incorrect parameter type)
* Correctly detect success of ScadaBR reports - O/S (CR3000.Std.27) has bug
  whereby HTTP GET responses with empty payloads are wrongly interpreted as
  failures
* ScadaBR test-trigger variable is relocated to end of Public table

### Data Table Changes

* New column `LI190R_mult` after `LI190SB_sens` in table `site_info`. The old
  column is retained to distinguish the values and for backward-compatibility
  with REACCH processing scripts

### Instrumentation Changes

* PAR sensor (LI190SB) with faults in cable is replaced with equivalent model
  equipped with different shunt resistor (LI190R-SMV); now, settings specify
  sensor multiplier (mmol/s/m^2/mV) instead of sensitivity.

### Enhancements

* ScadaBR test-trigger variable is not reset until test request is completed

### Other Changes

* Destination test variable in ScadaBR renamed `testlisten` -> `testing`

v1.1 (2015-06-19)
-----------------

### Issues Fixed

* Update email settings file instructions to reflect f11ee6a626 [Encrypt email
  settings before deployment]

### Enhancements

* Trigger test emails via Public table by changing `test_email` to "true";
  SMTP server responses can be viewed in `debug` table. Same functionality as
  provided by debug menu

v1.0.1 (2015-05-09)
-------------------

### Issues Fixed

* Use min/max battery & temperature data from `site_daily` table, as intended,
  instead of -7999/PanelTemp/Battery values in daily update email

### Data Table Changes

* New column `GitRepoTag` in the `site_info` table, after `ProgSig`

v1.0 (2015-05-08)
-----------------

>
**Security advisement**
> A minimum of level 1 datalogger security is **required** for safe operation
> of this program. If no security level is set, potentially catastropohic
> changes can be made by anonymous users![^1]

  [^1]: In reality, seriously damaging changes can be made by anonymous users
        even in previous versions; however, with this release *only* settings
        and debug values are exposed in the Public table and the risk of
        unintentional changes is higher.

>
**New include file**
> Before deployment, an encrypted version of the email include file **must**
> be stored on the logger's `CPU` drive.

>
**Incompatible settings file**
> After deployment, program settings must be **completely reset** before
> reprogramming with site-specific values.

### Known Issues

* *Required actions before deployment*
    * Enable datalogger security at Level 1 or higher
    * Update template `email-template.cr3` as appropriate, then use CRBasic
      Editor's 'Save and Encrypt...' option to save as `email_Enc.cr3`
    * Send `email_Enc.cr3` to the datalogger's CPU drive. Do **not** set
      'Run now' or 'Run on startup' options when pushing this file
* *Required actions after deployment*
    * Reset program settings (or delete settings file from CPU drive) and
      re-program with correct site-specific values

### Enhancements

* Transition back to conditional compilation for auxiliary sensors:
  Decagon NDVI/PRI radiometers, Los Gatos N2O/CO, Picarro CO2/CH4, Huskeflux
  soil heat flux plate
    * No longer produces empty tables if sensors are not used (solves problem
      with CardConvert halting for user interaction when empty tables are
      encountered, improving automation scripts)
    * Increase available recording time by not allocating space for sensors
      which are not used
    * Can only be changed via 'Initial setup' menu or ConstTable; triggers
      recompilation
* Use boolean settings to enable/disable: cup and vane wind set, rain gage,
  soil moisture probes
    * Data tables are unchanged but if disabled, only NANs are recorded
    * Can be modified via 'Settings' menu or Public table; made effective
      by changing `save_changes` to True
* Expose program settings ("Settings" logger menu) values in Public table
  along with variable to save/apply settings
    * Allows remote modification of settings via LoggerNet Connect screen
    * Reduces memory consumption because of fewer variables being cached
      for public display
* Notify by email when program starts up or whenever test email is sent
* Exclude known-bad data from PAR sensor (0 or negative voltages)

### Other Changes

* Variables can no longer be monitored in the Public since it's repurposed for
  remote settings access
* New datalogger menu structure
    * previous top-level menu items are now under 'System Menu' submenu
    * previous 'Sensor Setup' submenu is now 'Settings' submenu
    * new submenu 'Initial Setup' contains options to enable/disable auxiliary
      sensors (described under *Enhancements* above)

20140616_MMTN
-------------

### Other Changes

* Revert PAR sensor signal input location back: DF 6 -> DF 5
* Update MMTN datalogger serial number to reflect fact physical datalogger
  unit (S/N 6504) was exchanged with current spare (S/N 6506)

20140610_MMTN
-------------

### Issues Fixed

* Update sensitivity value for PAR sensor, which was exchanged May 6, 2014:
  previous sensor (Q45241) value 6.69 -> 6.03 of current sensor (Q45933)

### Other Changes

* Change input channel of PAR sensor (LI190SB) DF 5 -> DF 6; also add to
  ConstTable to facilitate in-field investigation/troubleshooting

20140217_XXXX
-------------

### Other Changes

* Remove reviewer-flag from program source code comments

20131018_XXXX
-------------

### Issues Fixed

* Remove duplicate suffix from column 'CO2_ppm_Avg_Avg' -> 'CO2_ppm_Avg'

### Other Changes

* Internally, change handling of sonic & IRGA diagnostic flags
* Discard temperature and do not calculate volumetric water content if
  dielectric value from soil moisture probes is null ("NAN")

20131012_CFNT
-------------

### Known Issues

* Duplicate suffix column remains ('CO2_ppm_Avg_Avg')

### Other Changes

* Attempt to enable Los Gatos N2O/CO by editing default value within subroutine
  `set_default_choices()`

20130711_MSLK
-------------

### Issues Fixed

* Correct sonic azimuth 245 -> 254

### Known Issues

* Duplicate suffix column remains ('CO2_ppm_Avg_Avg')

20130619_MSLK
-------------

### Issues Fixed

* Correct array length declaration  (4 -> 2) for variable `dec_ndvi_up`; this
  is a cosmetic fix

### Known Issues

* Sonic azimmuth is incorrectly specified as 245 instead of 254
* Duplicate suffix column remains ('CO2_ppm_Avg_Avg')

### Enhancements

* Add site-specific values for new monitoring site in Moses Lake, WA
* Move save confirmation within 'Sensor Setup' menu into submenu

### Other Changes

* When Decagon NDVI/PRI sensors are inactive, set data destinations to null
  values ("NAN") only once instead of each scan

20130507_XXXX
-------------

### Issues Fixed

* Increase number of records retained for 'site_info' table 1 -> 1000

### Known Issues

* Column has duplicated suffix ('CO2_ppm_Avg_Avg') in 'stats5/stats30' tables

### Enhancements

* New durable settings file used to track activation flags for Los Gatos N2O/CO,
  Picarro CO2/CH4, and new Decagon NDVI/PRI sensors, as well as scaling offsets
  and multipliers for Los Gatos & Picarro signals
* Support for new Decagon NDVI/PRI light sensors

### Wiring Changes

* Remove Decagon 6-band radiometers from C5/G/12V
* Add Decagon NDVI/PRI sensors to C5/G/12V

### Data Table Changes

* Removed tables:
    * stats5_6rad/stats30_6rad
    * tsdata_lgrn2oco/tsdata_picco2ch4
* New tables:
    * tsdata_extra
        * output at 10 Hz
        * contains both LGR N2O/CO/H2O and Picarro CO2/CH4/H2O; if either is
          missing, associated columns will be null values ("NAN")
        * units for all columns are "scale-dependent"
    * stats5_ui/stats30_ui
        * output on 5- and 30-min intervals
        * contains 9 columns (averages of ndvi/pri|up/down and total # of calls
          to tables)
    * extra_info
        * output whenever settings change, up to 1000 records
        * tracks presence of Decagon NDVI/PRI, LGR N2O/CO and Picarro CO2/CH4
          sensors, also multipliers/offsets for LGR & Picarro
    * diagnostics
        * output on 5-min intervals
        * contains number of total scans, skipped scans and watchdog errors
* Changes to 'stats5/stats30'
    * Add soil heat flux and plate sensitivity (4 columns total), after soil
      moisture probes
* Changes to 'site_daily'
    * Modify size from auto-allocate -> 60
    * Add min/max battery voltage and min/max temperature from T/RH probe
* Changes to 'site_info'
    * FIX: increase number of records retained 1 -> 1000
    * Remove columns tracking presence of Decagon 6-band radiometers, LGR
      N2O/CO and Picarro CO2/CH4

### Other Changes

* Return fast & slow scan buffers 2 -> 1 min
* Modify soil heat flux plate calibration interval 3 -> 6 hours
* Acquire data from GPS receiver & soil moisture probes within soil heat flux
  plate scan (1/5 Hz) instead of 'slow' scan (1 Hz)
* New menu "Sensor Setup" contains options to enable/disable Decagon NDVI/PRI,
  LGR N2O/CO, and Picarro CO2/CH4 sensors
* Internally, fieldnames are promoted upwards to become variable names
* Restore copyright notice

20130416_MMTN
-------------

This version has the Los Gatos analyzer channels enabled; it expects analog
voltage signals for N2O, CO and H2O.

### Known Issues

* In 'stats5/stats30' data tables, `rslt_wnd_dir` is not adjusted for sonic's
  orientation; add the sonic azimuth value to recorded WD for correct WD
    * HOW FAR BACK DOES THIS GO
    * since now recording `rslt_wnd_dir` instead of saving `wnd_dir_compass` as
      that name, the lack of compensation is important, also it means previous
      program versions are unaffected

### Enhancements

* Add support H2O signal from Los Gatos (LGR) N2O/CO analyzer
    * Analog voltage input on DIFF 10
    * Units are mV, must be post-scaled to engineering units

### Data Table Changes

* Enable 'tsdata_lgrn2oco' table
* Increase data type size of Obukhov length `L` from FP2 -> IEEE4

### Other Changes

* **Activate** the Los Gatos N2O/CO analyzer inputs
    * Current implentation requires program operate in `SequentialMode` instead
      of `PipeLineMode`
* Increase flux (high-freq) scan and met (slow) scan buffers 1 -> 2 minutes
* Revert secondary, slow scan interval 3 -> 1 sec
* Simplify processing of resultant wind direction
    * Introduces error mentioned under Known Issues
    * Calculate directly into geo-compass (left-handed) instead of sensor
      (right-handed) coordinates
* Soil heat flux related
    * Comment out data tables, measurement code & processing
    * Add framework for automatic activation based on logger serial number
    * Decrease scan frequency from 4 -> 5 seconds
    * Set sensitivity values to 0 if sensors are deactivated

20130123_CFNT
-------------

### Issues Fixed

* Change some variables' units:
    * `rho_d_mean_hmp`: kg/m^3 -> g/m^3
      *Was introduced in version tagged 20120627_CFCT but never saved to data
      tables*
    * `nmbr_clock_change`: samples -> occurrences
      *Represents number of clock changes*

### Data Table Changes

* Re-activated globally: **stats5_hfp/stats30_hfp**
* Within **site_daily**, change units of nmbr_clock_change (see above)

### Other Changes

* Modify some scan intervals:
    * secondary, slow sensor scan: 1 -> 3 sec
    * heat flux plate scan: 4 -> 5 sec

20120827_XXXX
-------------

### Data Table Changes

* Deactivated globally: **stats5_hfp/stats30_hfp**
* Split **tsdata_gases** into **tsdata_lgrn2oco** and **tsdata_picco2ch4**

### Other Changes

* Globally deactivate soil heat flux plate

20120824_LIND
-------------

### Data Table Changes

* Within **stats5/stats30**, change dielectric value column names and units
    * soil_5TM_ID*_epsilon -> soil_5TM_ID*_E
    * dimensionless -> dimless
* Add columns to **stats5_hfp/stats30_hfp**: hfp1_samples_Tot, hfp2_samples_Tot,
  tblcalls_Tot
* Add columns to **stats5_6rad/stats30_6rad**: tblcalls_Tot

### Other Changes

* Move soil heat flux plate to an independent secondary scan at 1/4 Hz
* Reduce other slow scan buffer from 2 -> 1 min

20120810_LIND
-------------

### Enhancements

* Add support for measuring H2O from Picarro CH4/CO2/H2O analyzer on DIFF 13
* Filter null values ("NAN") from data recorded to 'stats5_6rad/stats30_6rad'
* Auxilary sensors 6-band radiometer (Decagon) and soil heat flux plate
  (Huskeflux) are now set on/off automatically based on site (logger S/N)

### Wiring Changes

* Optional Los Gatos Analyzer N2O/CO move from DF 10/11 to DF 8/9 respectively
* RESERVED FUTURE Optional Los Gatos Analyzer H2O input on DF 10
* Optional Picarro Analyzer CO2/CH4 move from DF 12/13 to 11/12 respectively
* NEW Optional Picarro Analyser H2O input on DF 13

### Data Table Changes

* Remove data tables:
    * tsdata_n2o_co
    * stats5_n2o_co
    * stats30_n2o_co
    * tsdata_co2_ch4
    * stats5_co2_ch4
    * stats30_co2_ch4
* Create data table: tsdata_gases
    * Records 10 Hz time series of N2O, CO from LGR analyzer & CO2, CH4, H2O
      from Picarro analyzer
* Move columns from **stats5_soil/stats30_soil** to **stats5/stats30**:
  dielectric value, temperature, and volumetric water content from each of the
  five soil moisture probes
* Rename data tables:
    * stats5_soil -> stats5_hfp
    * stats30_soil -> stats30_hfp
* Remove column from **site_info** table: SENSOR_DEC_5TM
* Rename columns in **site_info** table:
    * SENSOR_DEC_6RAD -> Dec_6rad_installed
    * SENSOR_LGR_N2OCO -> LGR_n2o_co_installed
    * SENSOR_PIC_CO2CH4 -> Pic_co2_ch4_installed
    * SENSOR_HFP01SC -> hfp_installed

* Units changes
    * irga_uptime: ratio -> unity

### Other Changes

* Processing for 5- and 30-min data tables is substantially simplified
    * Processing based on 'min_uptime' values is removed entirely
    * Data tables are consolidated and inter-scan triggers used instead
    * No stats created for auxilary trace gas analyzers (LGR, Picarro)

20120727_LIND
-------------

> **This version is a stub branch of 20120220_CFNT**

### Data Table Changes

* Increase size of 'site_info' table 1 -> 20 to allow to unintended restarts

### Other Changes

* Update auxilary sensors to match site
    * Deactivate Decagon 6-band radiometers
    * Deactivate Los Gatos N2O/CO
    * Activate soil heat flux plate
* Add duplicate statements to end soil heat flux calibration interval

20120720_CFNT
-------------

* Activate Los Gatos N2O/CO analyzer

20120720_CFCT
-------------

* Activate Decagon 6-band radiometers

20120720_MMTN
-------------

* Revert some soil heat flux plate calibration routine schedule changes
    * Increase routine interval 2 -> 3 hr
    * Increase start time into interval delay 10 -> 120 sec
    * Increase total routine runtime to 380 sec
* Increase slow scan buffer 1 -> 2 min

20120711_MMTN
-------------

### Other Changes

* NEW monitoring site: Moscow Mountain Road (MMTN)
    * Sensor sensitivity values, sonic orientation, etc added
    * Soil heat flux plate (active at LIND) deactivated
* Slow scan buffer increased from 3 -> 60 sec

20120705_LIND
-------------

### Issues Fixed

* Fix problem preventing soil heat flux plate data from being recorded if soil
  moisture probes were not activated

### Data Table Changes

* In table site_info, change data type of soil heat flux plate sensitivity
  from FP2 to IEEE4

### Other Changes

* Modify schedule of self-calibration routine of soil heat flux plates
    * Increase routine interval 3->2 hr
    * Reduce starting time into interval 60 -> 10 sec
    * Reduce heat-on time after start time 180 -> 20 sec
    * Change duration from heat-on+180s to start-time+190s

20120628_CFNT
-------------

### Issues Fixed

* Record null values ("NAN") instead of 0 if soil heat flux plates are not used

### Other changes

* Activate Los Gatos N2O/CO analyzer

20120627_CFCT
-------------

This version represents a lot of changes which means this entry is more likely
than others to be less than comprehensive.

### Enhancements

* Site-specific sensitivity values for certain sensors are now automatically
  selected using datalogger's serial number when program is compiled.
* Support for new auxilary sensors (not enabled by default)
    * Los Gatos N2O/CO analyzer, 2 analog voltage inputs, high-freq. sampling
    * Picarro CH4/CO2 analyzer, 2 analog voltage inputs, high-freq. sampling
    * Decagon soil moisture probes (5TM), 5 sensors
    * Huskeflux soil heat flux plates, 2 sensors

### Known Issues

* Disable flag for Picarro CO2/CH4 analyzer only checked for CO2=NAN, checked
  twice

### Wiring Changes

Consult the reference sheet `wiring_details.ods` for details.

* Cup & vane wind direction signal: SE 11 -> SE 1
* NEW Picarro Fast CO2/CH4/H2O analyzer
    * CO2: DIFF 12
    * CH4: DIFF 13
* SDI sensors including Decagon soil moisture probes and Decagon 6-band
  radiometers: C5, 12V, G
* Soil heat flux plates (used in pairs) on: DF 6/7, SE 27/28, VX1, SW12-1, G

### Data Table Changes

* NEW data tables
    * **site_info**
        * Includes sonic_azimuth, RunSig, and ProgSig, moved from **site_daily**
        * Also contains site-specific metadata like clock offset from UTC,
          sensor sensitivity values, and flags indicating presence of auxilary
          instruments
    * **stats5_soil/stats30_soil**
        * For each probe measure: **epsilon**, dielectric permittivity;
          **T**, soil temperature; and **VWC**, volumetric water content calculated
          using the Topp equation
        * If soil heat flux plates are present, then soil heat flux and current
          sensitivity values
    * **tsdata_co2_ch4**, **stats5_co2_ch4**, **stats30_co2_ch4**
        * Analagous to tsdata_n2o_co, stats5_n2o_co, stats30_n2o_co
        * 5- and 30-min tables have mean and standard deviation of each scalar
        * Has "uptime" value too, which is # of non-NAN values over # scans

### Other Changes

* Remove base sensor set-related code from conditional compilation blocks
* Remove code related to sensors not deployed at any REACCH site
* Revise cup & vane WS sensor multiplier/offset: 0.799/0.2811 -> 0.7989/0.28
* Add conditional so wind-speed adjustment is only applied when WS > 5 m/s
    * If no refererence is found for this, it may be tagged a 'known issue'

### References

* Decagon Devices. *Dr. Topp.* <http://www.decagon.com/micro/dr-topp/>.
    * Topp, G.C., J.L. David, and A.P. Annan 1980. Electromagnetic,
      Determination of Soil Water Content: Measurement in Coaxial Transmission
      Lines. Water Resources Research 16:3. p. 574-582.

20120601_LIND
-------------

### Data Table Changes

* Drop data tables tsdata_n2o_co, stats5_n2o_co and stats30_n2o_co since
  Los Gatos N2O/CO analyzer completely disabled

### Other Changes

* Comment out Los Gatos N2O/CO analyzer code

20120504_LIND
-------------

### Issues Fixed

* Corrected net radiometer and PAR sensor sensitivity values

### Data Table Changes

* Rename data tables
    * tsdata_extra -> tsdata_n2o_co
    * stats5_extra -> stats5_n2o_co
    * stats30_extra -> stats30_n2o_co
* Changed units within tsdata_n2o_co table
    * lgr_n2o: ppm, dMR -> ppm
    * lgr_co: ppm, dMR -> ppm
* Remove covariance terms from stats5_n2o_co and stats30_n2o_co tables

20120427_CFNT
-------------

### Data Table Changes

* NEW data tables **stats5_6rad** and **stats30_6rad** for Decagon radiometers

### Other Changes

* Add support for Decagon 6-band radiometers
    * Swapped sensor SDI addresses: up-facing is now 2, down-facing is 0
* Disable Los Gatos N2O/CO analyzer
* Verify net rad, PAR sensor sensitivity values are correct for CFNT site

20120420_LIND
-------------

### Known Issues

* Sensitivity values used for net radiometer and PAR sensor were incorrect,
  actually for CFNT sensor set, not LIND sensor set

### Data Table Changes

* New data tables
    * tsdata_extra: 10 Hz samples of N2O & CO
    * stats5_extra/stats30_extra: summary stats on 5- & 30-min intervals
        * Includes covariance between vertical wind speed & species conc but
          delay through sampling tube is not compensated for, therefore
          covariance values should be ignored

### Other Changes

* Add support for Los Gatos N2O/CO analyzer
    * Analog voltage input: N2O/DF 10, CO/DF 11
* Reduce analog input voltage measurement integration time: _60Hz -> 250

20120330_CFNT
-------------

Incorporate changes from 20120323_LIND

20120323_LIND
-------------

Manually incorporates changes from 20120316_CFNT

### Issues Fixed

* Add missing type code suffix "_Med" to `latitude` and `longitude`

### Data Table Changes

* In daily data table,
    * Add missing type code suffix "_Med" to `latitude` and `longitude`
    * Remove average latitude, longitude, and magnetic_variation
    * Add median altitude (in addition to mean) since it presents more
      variance apparently

20120316_CFNT
-------------

### Data Table Changes

* In 5- & 30-min data tables rename `Met1_wnd_dir` to `Met1_rslt_wnd_dir`
* In daily table
    * Change units for latitude/longitude from 'decimal degrees N/E' to
      'decDegreesN/E' respectively
    * Add two columns `RunSig` and `ProgSig`

### Other Changes

* Specified sensitivity values for net radiometer, PAR sensor at CFNT site

20120309_LIND
-------------

This vesion was manually (imperfectly) merged against **20120215_CFNT**.

### Issues Fixed

* Removed site code prefix from data tables
* Correct data table reference; before this fix, since 20120215_CFNT, values
  from the T/RH probe recorded in 30-min data table were mistakenly duplicates
  of most recent 5-min period values.
* Add missing units to CO2/H2O signal strength values in table 'tsdata'
* Remove slowsequence disable flags from daily table to restore output

### Data Tables

* Renamed data tables:
    * CFNT_stats5 -> stats5
    * CFNT_stats30 -> stats30
    * CFNT_site_daily -> site_daily
    * CFNT_tsdata -> tsdata
* Changed units for variables:
    * `latitude_a`: degrees -> degreesN
    * `latitude_b`: minutes -> minutesN
    * `longitude_a`: degrees -> degreesE
    * `longitude_b`: minutes -> minutesE
    * `magnetic_variation`: unitless -> degreesEofN
    * `diag_sonic`: arb -> bitmap
    * `diag_irga`: arb -> bitmap
* Modify 5- & 30-min data tables:
    * Remove columns: Tc_Std, CO2_ppm_Std, H2O_g_kg_Std, hmp_uptime, Met1_uptime
    * Rename `wnd_dir_compass` to `rslt_wnd_dir` and move upward one column
* Add median values to daily table of GPS-related data
    * `latitude`: decimal_degrees_N
    * `longitude`: decimal_degrees_E
    * `magnetic_variation_Med`: degreesEofN

### Other Changes

* Revert many tables & variables back to hidden
* Simplify significantly the evaluation of sonic anemometer diagnostic word
* Also simplify the evaluation of IRGA diagnostic word
* Exclude negative values from PAR sensor

20120309_CFNT
-------------

> **This version is a stub branch of 20120224_LIND**

### Issues Fixed

* Correct data table reference; before this fix, since 20120215_CFNT, values
  from the T/RH probe recorded in 30-min data table were mistakenly duplicates
  of most recent 5-min period values.

20120224_LIND
-------------

This version diverged from an earlier, unretained draft of **20120215_CFNT**.

### Known Issues

* New `sonic_uptime` name incorrectly attached to `wnd_dir_compass` values
  while `wnd_dir_compass` name incorrectly reflects `sonic_uptime` values
* Implementation of `*_uptime` variables may have been flawed, always
  indicating "1"

### Issues Fixed

* Update constant `SITE_PRESS` to 93.5 kPa (based on Dec 2011 - Feb 2012)
* Fix cause of `T_hmp` being 0 and `RH_hmp_Avg` being "NAN",
  which was a missing `GetRecord` statement
* In some instances, standard deviation of wind direction is reported zero, or
  site azimuth is recorded as wind direction because period lacked data and
  mean wind direction was reported zero. To resolve both, new value
  `sonic_uptime` tracks ratio (0-1) of good sonic records out of queries; when
  value < 0.5 then null values ("NAN") are recorded for wind stats
* Use an `irga_uptime` analagous to sonic_uptime to set `Xc`/`Xv` to null
  value ("NAN") when irga_uptime < 0.5

### Data Table Changes

* Units are changed for several columns:
    * diag_sonic: arb -> bitmap
    * diag_irga: arb -> bitmap
    * CO2_sig_strgth: arb -> unity
    * H2O_sig_strgth: arb -> unity
* Modify both 5- and 30-min tables by
    * Adding columns: sonic_uptime, CO2_ppm_Std, H2O_g_kg_Avg, H2O_g_kg_Std,
      amb_tmpr_Avg, irga_samples_Tot, irga_uptime, e_hmp_Avg, e_sat_hmp_Avg,
      hmp_uptime, Met1_uptime

### Other Changes

* Updated calibration constants to reflect LIND-specific sensors
    * net radiometer (NR-Lite2): 12.6
    * PAR sensor (LI190SB): 6.84
* Modify multiplier used to value specified in user manual (0.799 -> 0.7989)
* Redefine several variables as Public to facilitate troubleshooting
* Modify behavior for cup & vane measurement QC
    * Change `If WS=0.2811 Then WS=0` to `If WS<=0.2811 Then WS=NAN`
    * Change `If WD>=360 Then WD=0` to `If WD>=360 OR WD<0 Then WD=NAN`

20120215_CFNT
-------------

### Issues Fixed

* Update constant `SITE_PRESS` to 93.5 kPa (based on Dec 2011 - Feb 2012)
* Fix cause of `T_hmp` being 0 and `RH_hmp_Avg` being "NAN",
  which was a missing `GetRecord` statement
* In some instances, standard deviation of wind direction is reported zero, or
  site azimuth is recorded as wind direction because period lacked data and
  mean wind direction was reported zero. To resolve both, new value
  `sonic_uptime` tracks ratio (0-1) of good sonic records out of queries; when
  value < 0.5 then null values ("NAN") are recorded for wind stats
* Use an `irga_uptime` analagous to sonic_uptime to set `Xc`/`Xv` to null
  value ("NAN") when irga_uptime < 0.5

### Data Table Changes

* Units are changed for several columns:
    * diag_sonic: arb -> bitmap
    * diag_irga: arb -> bitmap
    * CO2_sig_strgth: arb -> unity
    * H2O_sig_strgth: arb -> unity
* Change both "CFNT_stats5" and "CFNT_stats30" tables by
    * Adding columns: sonic_uptime, CO2_ppm_Avg, H2O_g_kg_Avg, amb_tmpr_Avg,
      irga_uptime, e_hmp_Avg, e_sat_hmp_Avg
    * Removing columns: Tc_Std, sonic_samples_Tot
* Simplify daily GPS-related data table by removing standard deviation values

### Other Changes

* Modify multiplier used to value specified in user manual (0.799 -> 0.7989)
* Redefine several variables as Public to facilitate troubleshooting
* Modify behavior for cup & vane measurement QC
    * Change `If WS=0.2811 Then WS=0` to `If WS<=0.2811 Then WS=NAN`
    * Change `If WD>=360 Then WD=0` to `If WD>=360 OR WD<0 Then WD=NAN`

20120210_CFNT
-------------

### Issues Fixed

* Change cup & vane wind statistic output type set from 0->2 to match the type
  set output using sonic anemometer data
* Use correct temperature when calculating Monin-Obukhov Length
* Add back-end required for correct 5-min data table calculations
* Remove erroreous mixing ratio values co2_mix_ratio and h2o_mix_ratio,
  use Xc and Xv instead, respectively

### Data Table Changes

* Rename data tables:
    * "CFNT_met_5min" to "CFNT_stats5"
    * "flux" to "CFNT_stats30"
    * "ts_data" to "CFNT_tsdata"
* NEW data table "CFNT_site_daily" with GPS-related data, on 24hr output
* Modify 10 Hz table by removing columns: co2_molar_density, h2o_molar_density
* Modify both 5- & 30-min summary table structure
    * Column order changes significantly, see `data_table_key.ods` for details
    * Remove columns: Hs, latitude_a, latitude_b, longitue_a, longitude_b,
      magnetic_variation, altitude, max_clock_change, nmbr_clock_change
    * Add columns: tau, Xc as CO2_ppm_Avg
    * Rename columns: Ts_stdev to Ts_Std, Tc_mean to Tc_Avg,
      Tc_stdev to Tc_Std, Uz_stdev to Uz_Std, CO2_mean to CO2_mg_m3_Avg,
      H2O_mean to H2O_g_m3_Avg, CO2_stdev to CO2_mg_m3_Std,
      H2O_stdev to H2O_g_m3_Std, CO2_sig_srgth to CO2_signal_Avg,
      H2O_sig_strgth to H2O_signal_Avg, amb_press_mean to amb_press_Avg,
      T_hmp_mean to T_hmp_Avg, RH_hmp_mean to RH_hmp_Avg
    * Change data types of `Rn` and `Rn_meas` from IEEE4 to FP2
    * Explicitly exclude null values ("NAN") when evaluating PAR sensor,
      cup & vane, and rain tipping bucket data
* Further modify the 30-min table by
    * Removing these columns:
        * covariance values
        * ambient air density, rho_a_mean
        * component parts of flux calculations (raw covariance and both WPL terms)
        * diagnostic bits for IRGA (EC150)
        * some values from T/RH probe: e_hmp_mean, e_sat_hmp_mean,
          H2O_hmp_mean, rho_a_mean_hmp
        * GPS-related values
    * And renaming these: l to L, par_totflx to PAR_totflx, par_flxdens to PAR_flxdens,
    * Additionally, change wind stat calculation type for cup & vane
        * mean horizontal wind speed: 034b_ws renamed to Met1_wnd_spd
        * unit vector mean wind direction: 034b_wd, removed
        * standard deviation of wind direction via Yamartino algorithm:
          034b_stdwd, removed
        * mean wind vector magnitude: Met1_rslt_wnd_spd, added
        * resultant mean wind direction: Met1_wnd_dir, added
        * standard deviation of wind direction via Campbell Scientific
          algorithm: Met1_std_wnd_dir, added

### Other Changes

* Auto-allocate space on memory cards, effectively use all available space
* Disable the 'System Control' menu since instrument suite is static
* Save processing time by changing net rad. measurement from AutoRange to 20mV
* Disable both Los Gatos N2O/CO and Picarro CH4/CO2 analyzers
* Comment out superfluous code

20120204_CFNT
-------------

### Issues Fixed

* Add units "m" for meter to Monin-Obukhov Length (`L`)

### Known Issues

* New 5-min data table lacks back-end infrastructure to yield correct results

### Data Table Changes

* NEW data table "CFNT_met_5min" with select subset of values in the "flux"
  table on a 5-min instead of half-hour basis.
* Change variable names:
    * `l` to `L`
    * `par_mV` to `PAR_mV`
    * `par_flxdens` to `PAR_flxdens`
    * `par_totflx` to `PAR_totflx`

20111121_LIND
-------------

> **This is a stub branch of 20111101_CFNT**

This is the first release deployed at the Lind, WA site.

### Site-specific Changes

* Update net radiometer sensitivity value
* Update PAR sensor sensitivity value

20111101_CFNT
-------------

**This release aggregates change made over three distinct deployed versions.
The intermediate work is unrecoverable.**

### Other Changes

* Add support for Los Gatos N2O/CO analyzer and Picarro CH4/CO2 analyzer but
  leave not enabled
* Remove support for ATI sonic anemometer, which had been disabled anyway
* Remove cruft associated with unused sensors

20111011_CFNT
-------------

**This release aggregates changes made over three distinct deployed versions.
The intermediate work is unrecoverable.**

### Issues fixed

* Change UTC offset from Central Standard (-6) to Pacific Standard (-8)
  *The precise time this change occurred has not been determined, though
  it may possibly be deduced from collected data.*
* Introduce 4 diagnostic flags for ATI sonic anemometer, one per data value
  Previous parsing method only retained final flag (`Ts` value)
* Temperature is now treated correctly in calculation of `Xc` and `Xv`

### Known Issues

* Variable `ati_azimuth` is declared twice and units are misspelled ("degress")
* Monin-Obukhov Length (`L`) is calculated using the variable `Tc_mean`, which
  is the mean "corrected" temperature from the CSAT3 sonic anemometer during
  the *last processed* half-hour period (30-60m prior), not the most recent
  half-hour period.
* Incorrect temperature is used when calculating `CO2_li_um_m`, `H2O_li_um_m`.
  *This mimics an earlier fix which, in this context, is an error.*

### Data Table Changes

* Fast time series: ts_data
    * Add inst. molar density and mixing ratio of CO2 & H2O
      (co2_molar_density, h2o_molar_density)
      (present but commented out: CO2_mix_ratio, H2O_mix ratio)
    * Added but not enabled:
        * Instantaneous U/V/W/Ts from ATI sonic (atiUx, atiUy, atiUz, atiTs)
* Half-hour statistics: flux
    * Add Monin-Obukhov length (L) *See note under Known Issues*
    * Remove naive mean of WS for cup & vane (WS_ms)
    * Add field names and units to mean WS/WD, WD stdev for cup & vane
      (034b_ws, 034b_wd, 034b_stdwd)
    * Added but not enabled:
        * ATI sonic azimuth (ati_azimuth)
        * mean WS, mean WD, WD stdev, mean U/V/W/Ts for ATI sonic
          (ati_ws, ati_wd, ati_stdwd, atiUavg, atiVavg, atiWavg, atitmpavg)

### Other Changes

* ATI sonic anemometer
    * Do not open com port at start-up (no real change since not enabled)
    * Move input from COM1 to COM3
    * Calculate instanteous WS/WD for use in half-hour table stats
* Soil heat flux plates
    * Reduce number of soil heat flux plates from 4 -> 2
    * Add actual sensor-specific sensitivity values
* Cup & vane wind sensor
    * Change wind speed units from "meters/second" -> "m/s"

20110819_CFNT
-------------

* Initial version deployed
* Modified from original work by Campbell Scientific to also record data from
  Applied Technology Inc (ATI) sonic anemometer

### Known Issues

* Wrong time zone specified: Central Standard (-6) not Pacific Standard (-8)
* Only final ATI diagnostic word retained, first three are discarded
* Temperature incorrectly subjected to unit conversion in calculation of `Xc`
  and `Xv`

license: MIT

branch_name: refs/heads/master

extension: md

license_type: permissive


text:
# ToDoList_Flutter [![License: MIT](https://img.shields.io/badge/License-MIT-yellow.svg)](https://opensource.org/licenses/MIT)

A TodoList app that uses SQLite Database to save todos. It uses Future and async for asynchronous programming.

# Demo

<img src="demo/demo.gif" width="500" height="500"/>


text:
# MiniMemoListWidget

Elegantly simple widget that holds 5 to 9 lines of easily editable texts.

The widget is operated by tapping:
- Single tap opens text editor.
- Double tap sorts texts by name, by time edited or restore original order.

The widget is resizable in horizontal direction.

The app is a widget and it should be added to the Home screen to fulfill its main purpose.
Tap screen and hold a finger for a while at empty space on the home screen, then
from Widgets select “Mini Memo List Widget”.

Mini Memo List Widget Promo Video

The app is availaible on Google Play:

repository: mabrosim/MiniMemoListWidget

gha_language: Java

repo_name: mabrosim/MiniMemoListWidget


text:
[![CircleCI](https://img.shields.io/circleci/project/github/Firesphere/silverstripe-googlemapsfield.svg)](https://circleci.com/gh/Firesphere/silverstripe-googlemapsfield)
[![codecov](https://codecov.io/gh/Firesphere/silverstripe-googlemapsfield/branch/master/graph/badge.svg)](https://codecov.io/gh/Firesphere/silverstripe-googlemapsfield)
[![Scrutinizer Code Quality](https://scrutinizer-ci.com/g/Firesphere/silverstripe-googlemapsfield/badges/quality-score.png?b=master)](https://scrutinizer-ci.com/g/Firesphere/silverstripe-googlemapsfield/?branch=master)

# Google Places field

Play with Google Places in your forms in SilverStripe

# Installation

`composer require firesphere/googlemapsfield`

# Usage

Add the form field to your form and enter your keys in the SiteConfig.

All the information from Google Places is automatically populated in hidden fields. You will have to map these to your own
DataObject storage on saving the form.

The fields given from places are:

- GoogleMapsLatField
- GoogleMapsLngField
- subpremise
- street_number
- route
- sublocality_level_1
- locality
- administrative_area_level_1
- country
- postal_code

If you want to change the fields, add custom hidden fields or remove some fields, you can do so via the `getExtraFields` and `setExtraFields` methods.

You can only use this field _once_ per form, due to restrictions of the ID's of fields.

## Custom options

https://developers.google.com/maps/documentation/javascript/places-autocomplete#add_autocomplete

Any options you want to add, can be set on the field as an array:
```php
$field = GoogleMapsField::create('MyField');
$field->setCustomOptions(['componentRestrictions' => ['country' => 'nz']]);
```

# Actual license

This module is published under BSD 3-clause license, although these are not in the actual classes, the license does apply:

http://www.opensource.org/licenses/BSD-3-Clause

Copyright (c) 2012-NOW(), Simon "Firesphere" Erkelens

All rights reserved.

Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:

    Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
    Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.

# Did you read this entire readme? You rock!

Pictured below is a cow, just for you.
```

               /( ,,,,, )\
              _\,;;;;;;;,/_
           .-"; ;;;;;;;;; ;"-.
           '.__/`_ / \ _`\__.'
              | (')| |(') |
              | .--' '--. |
              |/ o     o \|
              |           |
             / \ _..=.._ / \
            /:. '._____.'   \
           ;::'    / \      .;
           |     _|_ _|_   ::|
         .-|     '==o=='    '|-.
        /  |  . /       \    |  \
        |  | ::|         |   | .|
        |  (  ')         (.  )::|
        |: |   |;  U U  ;|:: | `|
        |' |   | \ U U / |'  |  |
        ##V|   |_/`"""`\_|   |V##
           ##V##         ##V##
```

repository: Firesphere/silverstripe-googlemapsfield

gha_language: PHP

repo_name: Firesphere/silverstripe-googlemapsfield


text:
# BucketsCanFly
A Raspberry Pi-powered quadcopter with a camera and a WebSockets-based control interface. GPLv3-licenced.

## Software
* [The Brain](https://github.com/cie6868/BCF_Brain) - Controls the BCF, serves up a web interface and listens to WebSockets.
* [Web UI](https://github.com/cie6868/BCF_WebControlUI) - JavaScript, gamepads and WebSockets to guide the BCF.
* [Firmware for the ESCs](https://github.com/cie6868/Neewer-I2C-bluerobotics-tgy) - SimonK firmware with I2C-based communication for tgy-compatible ESC units.

## Hardware
* Motor Mounts - 3D designs to hold a motor in place.

## History
1. Summer 2013 - RC-plane engines powered by methanol with servos to adjust fuel intake. Controlled by an Arduino. Failed miserably.
2. Summer 2014 - Electric motors with generic ESCs that responded too slow for decent stabilisation. Heavy aluminium frame. Still using an Arduino.
3. Winter 2017 to present - Newly flashed firmware drives ESCs to great response rates. Stabilisation in progress. Switched to a Raspberry Pi with an attached camera. WiFi for transmission. Published on GitHub.

## Credits
A very Sri Lankan project.
* Gamini Obeyesekere
* Chamath Ellawala
* Kavindha Ratwatte
* Vinu Abeygunawardene


text:
---
layout: feature
title: 'Polite'
shortdef: 'politeness'
udver: '2'
---

  Values:
  Form

### `Form`: formal register

In Spanish, the pronouns _usted_ and _ustedes_ are used when addressing someone in a formal or respectful manner. This
is usually done when communicating with people of higher social status, older age, or in situations that require
a certain degree of formality (e.g., a business meeting, a formal event, or when speaking to a stranger).

#### Examples

* _¿Usted desea algo más?_ "Do you [formal] want anything else?"
* _Ustedes deben completar el trabajo._ "You [plural, formal] must complete the work."
* _¿Cómo está usted?_ "How are you [formal]?"

However, it's worth noting that the use of _usted_ and _ustedes_ can vary greatly across different Spanish-speaking
regions. In some dialects, _ustedes_ is used as the standard second person plural pronoun, replacing the more informal
_vosotros_. Also, while _usted_ and _ustedes_ are traditionally associated with formality and respect, their usage can
also be common in everyday conversation in certain regions, without necessarily implying a higher level of formality.

Therefore, in the UD Spanish treebanks, _usted_ and _ustedes_ are tagged with the feature `Polite=Form` to indicate
their typical association with formal register, but the interpretation of this feature in a specific context may depend
on regional usage and sociolinguistic factors.

repository: UniversalDependencies/docs

branch_name: refs/heads/pages-source

gha_language: HTML

repo_name: UniversalDependencies/docs


text:
# subwallet

A simple Command Line Interface Wallet for Polkadot/Substrate.

<img src="https://raw.githubusercontent.com/w3f/Open-Grants-Program/master/src/web3%20foundation%20grants_black.jpg" width="300px">

## Installation

#### Install Binary

You can go to the [latest release](https://github.com/yxf/subwallet/releases) and download the binary.

#### Install via Cargo

If you are a Rust developer, you can install via cargo:
```bash
cargo install subwallet
```

## Usage

```bash
$ ./subwallet -h
subwallet 0.1.0
yxf<EMAIL_ADDRESS>A simple Command Line Interface wallet for Polkadot/Substrate.

USAGE:
    subwallet [SUBCOMMAND]

FLAGS:
    -h, --help       Prints help information
    -V, --version    Prints version information

SUBCOMMANDS:
    backup           Backup specified address to local json file
    getnewaddress    Generate a new address associated with label, deafult cryptography is sr25519
    help             Prints this message or the help of the given subcommand(s)
    listaddresses    Prints the list of addresses
    restore          Restore address from json file
```

### Subcommands

`./subwallet help [SUBCOMMAND]` to prints help information of subcommand.

#### `getnewaddress`

Generate a new random address

Example:

```bash
$ ./subwallet getnewaddress demo
1c1AVSCrrhtakya7LSm2hXHJUmBFdXV2KmCgEgDDaTWUQK3
```

#### `listaddresses`

List all generated addresses

Example:
``` bash
$ ./subwallet listaddresses
ec              1EE8Q6nt4x3x3Cm9eevvtCBesEUfwTJ4bw4ocQUkNrd42Z1j        ecdsa
demo            15FarxkDPL7LPvBPd1RDMGugGFs8be2ijuHEuLJd9z67PdNm        sr25519
ed              16Q55taKB1ggt3VgQ8EFTRkmYTgtNKb9xka8hqMqXMPLCNxU        ed25519
```

#### `restore`

Restore address from json file. It is compatible with keystore file generated on [`https://polkadot.js.org/apps`](https://polkadot.js.org/apps).

Example:
``` bash
./subwallet restore ~/1EE8Q6nt4x3x3Cm9eevvtCBesEUfwTJ4bw4ocQUkNrd42Z1j.json
Password: #Type password to decode seed
1EE8Q6nt4x3x3Cm9eevvtCBesEUfwTJ4bw4ocQUkNrd42Z1j is restored
```
#### `backup`

Backup address to local json file. The backed file can be restored on [`https://polkadot.js.org/apps`](https://polkadot.js.org/apps).

Example:
``` bash
./subwallet backup demo ~/demo.json
Type password to encrypt seed: # password
Address `15FarxkDPL7LPvBPd1RDMGugGFs8be2ijuHEuLJd9z67PdNm` is backed up to file `~/demo.json`
```

## Contributing
Bug reports and pull requests are welcome on GitHub at https://github.com/yxf/subwallet

## License
MIT

repository: GeekLabX/subwallet

repo_name: GeekLabX/subwallet


text:
# Payload examples

Examples of using Payload in different situations. All of these examples are compiled and run as part of the test suite.

* [hello](./hello): A simple hello world
* [basic](./basic): A larger example showing hierarchical routes
* [files](./files): Serving files
* [movies](./movies): A larger example based on the [Movie Database API](https://developers.themoviedb.org)
* [GitHub client](./client-github): Example client for the GitHub API

repository: hoodunit/purescript-payload

gha_language: PureScript

repo_name: hoodunit/purescript-payload


text:
# EnoLib

[![CI Status](http://img.shields.io/travis/Rahul Rathod/EnoLib.svg?style=flat)](https://travis-ci.org/Rahul Rathod/EnoLib)
[![Version](https://img.shields.io/cocoapods/v/EnoLib.svg?style=flat)](http://cocoapods.org/pods/EnoLib)
[![License](https://img.shields.io/cocoapods/l/EnoLib.svg?style=flat)](http://cocoapods.org/pods/EnoLib)
[![Platform](https://img.shields.io/cocoapods/p/EnoLib.svg?style=flat)](http://cocoapods.org/pods/EnoLib)

## Example

To run the example project, clone the repo, and run `pod install` from the Example directory first.

## Requirements

## Installation

EnoLib is available through [CocoaPods](http://cocoapods.org). To install
it, simply add the following line to your Podfile:

```ruby
pod "EnoLib"
```

## Author

Rahul Rathod<EMAIL_ADDRESS>
## License

EnoLib is available under the MIT license. See the LICENSE file for more info.


text:
# Salesforce Webhook Creator

This is a simple web app that makes it easy to create Webhooks on Salesforce.  For usage info see: http://www.jamesward.com/2014/06/30/create-webhooks-on-salesforce-com

Either use a shared instance of this app: https://salesforce-webhook-creator.herokuapp.com/

Or deploy your own instance on Heroku:

1. Create a new Connected App in Salesforce:

    1. [Create a Connected App](https://login.salesforce.com/app/mgmt/forceconnectedapps/forceAppEdit.apexp)
    1. Check `Enable OAuth Settings`
    1. Set the `Callback URL` to `http://localhost:9000/_oauth_callback`
    1. In `Available OAuth Scopes` select `Full access (full)` and click `Add`
    1. Save the new Connected App and keep track of the Consumer Key & Consumer Secret for later use

1. Deploy this app on Heroku: [![Deploy](https://www.herokucdn.com/deploy/button.svg)](https://heroku.com/deploy)
1. Edit the Connected App on Salesforce and update the `Callback URL` to be `https://YOUR_APP_NAME.herokuapp.com/_oauth_callback`

## Local Dev

Run Locally:
```
export FORCE_CONSUMER_KEY=YOUR_CONSUMER_KEY
export FORCE_CONSUMER_SECRET=YOUR_CONSUMER_SECRET

./sbt run
```

Test:
```
export FORCE_CONSUMER_KEY=YOUR_CONSUMER_KEY
export FORCE_CONSUMER_SECRET=YOUR_CONSUMER_SECRET
export FORCE_USERNAME=YOUR_SALESFORCE_USERNAME
export FORCE_PASSWORD=YOUR_SALESFORCE_PASSWORD

./sbt test
```

repository: jamesward/salesforce-webhook-creator

repo_name: jamesward/salesforce-webhook-creator


text:
---
title: app.view
collection: docs
category: api
description: >
  This document describes the `app.view` method.
related:
  docs:
    - view-collections
    - collection.view
    - class.View
    -
      title: View API # custom title
      key: class.View # may use `key`, `name`, or `url`
---

Create an un-cached [view](View.md) that is directly returned and is not added to a collection.

**Example**

```js
var assemble = require('assemble');
var app = assemble();

var view = app.view('home', {content: 'This is a random view'});
console.log(view);
```

repository: assemble/assemble

gha_language: CSS

gha_license_id: MIT

repo_name: assemble/assemble


text:
---
layout: post
title: "SwiftUI: Spacers and Dividers"
tags:
  - Swift Evolution
  - SwiftUI
  - swift 5
  - tutorial
  - guide
  - ios
  - macOS
  - uikit
  - watchkit
  - tvos
  - watchos
  - guide
  - iphone
  - architecture
  - guide
  - apple
  - dreamcraft
  - spacer
  - divider
  - spacer vs divider
  - delimiters
hero: https://dreamcraft.io/assets/img/whiteRectangle.png
overlay: blue
published: true
---

**Spacer** and **divider** are used to separate content. They may have the same purpose, but under the same circumstances, they may behave differently. Let's figure it out.
{: .lead}
<!–-break-–>
## Spacer

A flexible space that expands along the **major axis** of its containing stack layout, or on **both axes** if not contained in a stack.

```swift
struct SpacerExample: View {

    var body: some View {
        HStack{
            VStack{
                Color.red
                Spacer()
                Color.green
            }
            HStack{
                Color.red
                Spacer()
                Color.green
            }

        }
    }
}
```
## Divider

A visual element that can be used to separate other content. When contained in a stack, the divider extends across the **minor axis** of the stack, or **horizontally** when not in a stack. In the following example, we might see that he also offer some out of the box view that has a light gray color and height of 1 pixel (if it extends horizontally) or width  (if it extends vertically).

```swift
struct DividerExample: View {

    var body: some View {
        HStack{
            VStack{
                Color.orange
                Divider()
                Color.blue
            }
            HStack{
                Color.red
                Divider()
                Color.green
            }
        }
    }
}
```

## Same circumstances, different behaviour.

In the following example, we have a **divider**(between orange and blue) and a **spacer**(between red and green) with a fixed frame and embedded in VStacks. We can see that even with zero width and zero height applied on the divider between orange and blue color, we have a space with height of 10 pixels.

```swift
struct Example: View {

    var body: some View {
        HStack{
            VStack{
                Color.orange
                Divider().frame(width: 0, height: 0, alignment: .center)
                Color.blue
            }
            VStack{
                Color.red
                Spacer().frame(width: 0, height: 0, alignment: .center)
                Color.green
            }
        }
    }
}
```
## Conclusion

As we saw from the previous two examples, spacer and divider do the same job but with few differences. Starting from the way they extend in different circumstances and ending with that extra gray line provided in the divider. In coclusion: as with alcohol, use them responsible.


text:
# NodeJS Environment settings [![Build Status](https://secure.travis-ci.org/cladera/generator-config.png?branch=master)](https://travis-ci.org/cladera/generator-config)

Yeoman generator for creating simple environment configuration for NodeJS applications.

This project was inspired and actually extracted from the excellent work of @DaftMonk in [generator-angular-fullstack](https://github.com/DaftMonk/generator-angular-fullstack)

## Usage

Install generator:

```bash
$ npm install -g generator-config
```

Open project root folder and execute:

```bash
$ yo config
```

**IMPORTANT:** You will need to install and add underscore dependency to your package.json:

```bash
$ npm install underscore --save
```

## License

MIT

repository: cladera/generator-config

repo_name: cladera/generator-config


text:
---
title: "Compute native contacts ratio from a dcd trajectory file with MD-Analysis"
layout: default
date: 2015-10-23
tags:
- mdanalysis
- python
- science
---

# Compute native contacts ratio from a dcd trajectory file with MD-Analysis

Usage:

    native_contacts.py file.dcd file.pdb file.psf [any valid selection string]

The selection string is optional and can be any valid selection string for
selectAtoms() that produces identical selections in mobile and reference. e.g.
`"resid 6-91"`

I don't know why but the number of native contacts for the last frame is not
computed, for the version of MDAnalyis I use (0.7.3).

{% gist cc8415df4102becceede %}

extension: markdown

gha_language: TeX


text:
---
layout: post
title: Elasticsearch Intro
---

ElasticSearch is an open source, RESTful search engine built on top of Apache Lucene and released under an Apache license. It is Java-based and can search and index document files in diverse formats.

ElasticSearch has been compared to Apache Solr and offers several notable features:

 - Provides a scalable search solution.
 - Performs near-real-time searches.
 - Provides support for multi-tenancy.
 - An index can be easily recovered in a case of a server crash.
 - Uses Javascript Object Notation (JSON) and Java application program interfaces (APIs).
 - Automatically indexes JSON documents.
 - Each index can have its own settings.
 - Searches can be done with Lucene-based querystrings.

Indices and types
-------
Every time you store data in _Elasticsearch_ it gets saved inside an **index** which has a **type**. compared to _MongoDB_ an index is similar to a database, and a type similar to a collection. Compared to _SQL_ an index would be like a database, and a type like a table.

convention:
```
localhost:9200/{index}/{type}/
```

**Important note** different types living in the same index cannot have the same field name with different config or field type

For example the following two documents can't co-exist since they share the same index, and both have a _city_ attribute of different types, _string_ and _object_ respectively

```
localhost:9200/test/users/1
```
```
{
    "city": "cityID123"
}
```
```
localhost:9200/test/city/1
```
```
{
    "city": {
        "name": "Toronto"
    }
}
```

When developing with elasticsearch there are 3 main steps we have to consider. **Mapping**, **Indexing**, and **Searching** data

### 1. Mapping

Mapping is used to define how elastic should store and index a particular document and it's fields.

However if no mapping was introduced to a specific field on pre-index time, elastic will [dynamically](https://www.elastic.co/guide/en/elasticsearch/guide/current/dynamic-mapping.html) add a **generic** type to that field. Although this may sound tempting, it is NOT! since generic types are very basic and do not meet the query expectations most of the time.

Moving forward with this tutorial we will base our examples on the following data schema:

```
{
    "first_name": "bam",
    "last_name": "margera",
    "gender": "male",
    "age": 36
}
```

So to make things more efficient we're gonna create the index, type and mapping for the schema in one request. Something that looks like the following:

```
PUT localhost:9200/test/

{
    "mappings": {
        "users": {
            "properties": {
                "age": {
                    "type": "long"
                },
                "first_name": {
                    "type": "string"
                },
                "gender": {
                    "type": "string"
                },
                "level": {
		            "type": "string"
		        },
                "last_name": {
                    "type": "string"
                }
            }
        }
    }
}

```
so creating an _Index_ called test, a _type_ called users with 5 fields that it contains.

note that field types can have the following values: _string_, _date_, _long_, _double_, _boolean_, _ip_, _object_, _nested_, _geo_point_, _geo_shape_

If everything goes well, we should get the following response:

```
{
  "acknowledged": true
}
```

Now that we told elasticsearch what kind of data we want to insert, let's go ahead and index/store it.

### 2. Indexing

Indexing/storing is the process of inserting data to ES to make it **searchable** using the _Index API_.

So let's  index 3 simple documents:

```
POST localhost:9200/test/users/
{
    "first_name": "Bam",
    "last_name": "Margera",
    "gender": "male",
    "level": "super awesome",
    "age": 36
}

POST localhost:9200/test/users/

{
    "first_name": "Stephanie",
    "last_name": "Hodge",
    "gender": "female",
    "level": "awesome",
    "age": 34
}

POST localhost:9200/test/users/

{
    "first_name": "Johnny",
    "last_name": "Knoxville",
    "gender": "male",
    "level": "awesome",
    "age": 45
}

```

on success of any of the following docs, we should see a response like this:

```
{
  "_index": "test",
  "_type": "users",
  "_id": "AVRQDOka0YBBUjDwpzQQ",
  "_version": 1,
  "_shards": {
    "total": 2,
    "successful": 1,
    "failed": 0
  },
  "created": true
}
```

where __id_ is a generated id by ES that is 20 character long, URL-safe, Base64-encoded GUID string.

we can also specify our own id after the type like this:

```
POST localhost:9200/test/users/MyID123
{
    "first_name": "Bam",
    "last_name": "Margera",
    "gender": "male",
    "level": "super awesome",
    "age": 36
}
```

Now what we have our data indexed let's move forward to query it.

### 3. Searching

In this section we will cover ES _Queries_, _Filters_, and _Aggregations_ for search

To search in a specific _index_ and _type_ the following convention is used:

```
POST localhost:9200/test/users/_search
```

so now by hitting this request, the response will look like:

```
{
  "took": 4,
  "timed_out": false,
  "_shards": {
    "total": 5,
    "successful": 5,
    "failed": 0
  },
  "hits": {
    "total": 3,
    "max_score": 1,
    "hits": [
      {
        "_index": "test",
        "_type": "users",
        "_id": "AVRQQlCE0YBBUjDwpzQZ",
        "_score": 1,
        "_source": {
          "first_name": "Bam",
          "last_name": "Margera",
          "gender": "male",
          "level": "super awesome",
          "age": 36
        }
      },
      **... the other 2 docs go here**
    ]
  }
}
```

By looking at this response we can see that the data that we inserted is found inside the hits.hits _array_ included inside the __source_ _object_

and since we didn't actually specify anything to search for we'll get a __score_ of 1 for all docs.

on the top level hits.total is the total number of the docs we using an empty search query. and max_score is the maximum score a document can take is a specific query. in out case it's 1 since no query was specified.

in the __shards.total_ value is the number of lucene Indexed that elasticsearch created for that index. The default number is always 5 unless we specify otherwise on index creation time. more about shards is explained [here](https://www.elastic.co/guide/en/elasticsearch/guide/current/_add_an_index.html)

#### a. Queries

Queries is what we use to get results with **scoring** (relevance)

To ask a question like

 - level = "super awesome"

Using the _match_ query for **full-text** that is used on analyzed fields, we would write:

```
POST localhost:9200/test/users/_search

{
    "query": {
        "match": {
            "level": "super awesome"
        }
    }
}
```

the response will be:

```
{
  "took": 19,
  "timed_out": false,
  "_shards": {
    "total": 5,
    "successful": 5,
    "failed": 0
  },
  "hits": {
    "total": 3,
    "max_score": 0.2712221,
    "hits": [
      {
        "_index": "test",
        "_type": "users",
        "_id": "AVRQQlCE0YBBUjDwpzQZ",
        "_score": 0.2712221,
        "_source": {
          "first_name": "Bam",
          "level": "super awesome",
          ...
        }
      },
      {
        "_index": "test",
        "_type": "users",
        "_id": "AVRQRtYW0YBBUjDwpzQa",
        "_score": 0.09848769,
        "_source": {
          "first_name": "Stephanie",
          "level": "awesome",
          ...
        }
      },
      {
        "_index": "test",
        "_type": "users",
        "_id": "AVRQRx-E0YBBUjDwpzQf",
        "_score": 0.09848769,
        "_source": {
          "first_name": "Johnny",
          "level": "awesome",
          ...
        }
      }
    ]
  }
}
```

As we can see that the user _Bam_ scored the highest of 0.2712221 since his level was "super awesome ", whereas _Stephanie_ &  _Johnny_ scored an equal 0.09848769 for their level was just "awesome"

where as for **exact values** on _non-analyzed_ fields, _numbers_, _dates_, and _Booleans_, it's better to use the _Term Query_ :

 - age = 36

```
POST localhost:9200/test/users/_search

{
     "query": {
        "term": {
            "age": 36
        }
    }
}
```

this query will return **only** Bam

To combine more than one query together we can use the _Query clause_  to find:

 - level = "super awesome" AND "age" < 40

```
POST localhost:9200/test/users/_search

{
     "query": {
        "bool": {
            "must": [
                {
                    "match": {
                        "level": "super awesome"
                    }
                },
                {
                    "range": {
                        "age": {
                            "lt": 40
                        }
                    }
                }
            ]
        }
    }
}
```

Where _must_ is and array that implies **AND**. _bool_ also supports _should_ implying **OR**, and must_not.

Moreover we used the _range_ query with age "lt" **less than** 40. where _range_ also supports "lte", "gt", and "gte"

#### b. Filters

Filters are **non-scoring** queries that can be used if the score has no importance. It's returns a _boolean_ that answers with yes or no **where the score is always = 1**

so executing the following filter has no significance on the score, but will return only 2 docs:

```
POST localhost:9200/test/users/_search

{
    "filter": {
       "match": {
            "gender": "male"
        }
    }
}
```

Whereas combining this with a previous query:

 - level = "super awesome" AND only return gender = "male"

```
POST localhost:9200/test/users/_search

{
     "query": {
        "match": {
            "level": "super awesome"
        }
    },
     "filter": {
        "match": {
            "gender": "male"
        }
    }
}
```

This will return only 2 users Bam and Johnny **scoring** 0.2712221 and 0.09848769 respectively. Where Bam has a more relevant level than Johnny.

Although this works fine but it is **bad for performance** since it will execute the query first then apply the filter returned results.

To force ES to apply the filter before in order limit the number of docs then apply the query we should wrap everything in a bool clause then add the filter next to **must**:

```
POST localhost:9200/test/users/_search

{
    "query": {
        "bool": {
            "must": [
                {
                    "match": {
                        "level": "super awesome"
                    }
                }
            ],
            "filter": {
                "match": {
                    "gender": "male"
                }
            }
        }
    }
}
```

<br>
**more more more...**

 - level = "super awesome", and age < 40 but only return gender = "male"

we would write:

```
POST localhost:9200/test/users/_search

{
    "query": {
        "bool": {
            "must": [
                {
                    "match": {
                        "level": "super awesome"
                    }
                },
                {
                    "range": {
                        "age": {
                            "lt": 40
                        }
                    }
                }
            ],
            "filter": {
                "match": {
                    "gender": "male"
                }
            }
        }
    }
}
```

This will return only 1 user Bam **scoring**  1.0253175.

**Important note** we can also combine more than 1 filter using the bool

So as ES states it: "As a general rule, use query clauses for full-text search or for any condition that should affect the relevance score, and use filters for everything else."

#### c. Aggregations

[Aggregations](https://www.elastic.co/guide/en/elasticsearch/reference/current/search-aggregations.html) is a big part of elasticseach it is used to calculate stats about our data. Divided into 3 different types:

 - Metrics Aggregations
 - Bucket Aggregations
 - Pipeline Aggregations

 In this tutorial I'm gonna cover the _Term Aggregations_ which is a part of the Bucket Aggregations.

 - how many females and males We,v got in our Index/type ?

we can write the following:

```
POST localhost:9200/test/users/_search

{
    "size": 0,
    "aggs" : {
        "genders" : {
            "terms" : { "field" : "gender" }
        }
    }
}
```

We set "size" = 0 since we don't want to see any search results. just the aggs results. "aggs" is a predefined ES property, followed by "genders" which is a property that we can freely name. We can call it "xyz" if we want.

"terms" implies that that we are performing a term aggregation which specifies the field name that we want to agg > genders.

response:

```
{
  "took": 7,
  "timed_out": false,
  "_shards": {
    "total": 5,
    "successful": 5,
    "failed": 0
  },
  "hits": {
    "total": 3,
    "max_score": 0,
    "hits": []
  },
  "aggregations": {
    "genders": {
      "doc_count_error_upper_bound": 0,
      "sum_other_doc_count": 0,
      "buckets": [
        {
          "key": "male",
          "doc_count": 2
        },
        {
          "key": "female",
          "doc_count": 1
        }
      ]
    }
  }
}
```

what we want is every thing inside the bucket array which tells us that we have, 1 female and 2 males.

The power off aggs is that it can be combines with any filter/query.

so using the last filter we did, we can simply say:

```
{
    "query": {
        "bool": {
            "must": [
                {
                    "match": {
                        "level": "super awesome"
                    }
                },
                {
                    "range": {
                        "age": {
                            "lt": 40
                        }
                    }
                }
            ],
            "filter": {
                "match": {
                    "gender": "male"
                }
            }
        }
    },
    "aggs" : {
        "genders" : {
            "terms" : { "field" : "gender" }
        }
    }
}
```

This will return Bam with a male count = 1 : )

TADAH!


text:
---
description: The GoCD Helm Chart page explains how to get started with GoCD for kubernetes using Helm.
keywords: gocd helm chart, cd pipeline
---

# Install the GoCD Helm chart

> Helm is a package manager for Kubernetes. Kubernetes packages are called charts. Charts are curated applications for Kubernetes.

Install the GoCD Helm chart with these commands:

```bash
$ helm repo add stable https://kubernetes-charts.storage.googleapis.com
$ helm install stable/gocd --name gocd --namespace gocd
```

## Access the GoCD server

After you’ve installed the GoCD helm chart, you should be able to access the GoCD server from the Ingress IP.

The Ingress IP address can be obtained by using:
```bash
$ ip=$(kubectl get ingress --namespace gocd gocd-server -o jsonpath="{.status.loadBalancer.ingress[0].ip}")
$ echo "http://$ip"
```

On minikube, the IP address can be obtained by running the command

```bash
$ minikube ip
```

It might take a few minutes for the GoCD server to come up for the first time. You can check if the GoCD server is up with this command:

```bash
$ kubectl get deployments --namespace gocd
```

The GoCD server on startup will look like this.
![](../../resources/images/gocd-helm-chart/first_screen.png)

Now that you have accessed the GoCD server successfully, you will need to configure the Kubernetes elastic agent plugin.


text:
# Connecting to a URL

After you've successfully created a `URL` object, you can call the `URL` object's `openConnection` method to get a `URLConnection` object, or one of its protocol specific subclasses, e.g.
[`java.net.HttpURLConnection`](https://docs.oracle.com/javase/8/docs/api/java/net/HttpURLConnection.html)

You can use this `URLConnection` object to setup parameters and general request properties that you may need before connecting. Connection to the remote object represented by the URL is only initiated when the `URLConnection.connect` method is called. When you do this you are initializing a communication link between your Java program and the URL over the network. For example, the following code opens a connection to the site `example.com`:

```

try {
    URL myURL = new URL("http://example.com/");
    URLConnection myURLConnection = myURL.openConnection();
    myURLConnection.connect();
}
catch (MalformedURLException e) {
    // new URL() failed
    // ...
}
catch (IOException e) {
    // openConnection() failed
    // ...
}

```

A new `URLConnection` object is created every time by calling the `openConnection` method of the protocol handler for this URL.

You are not always required to explicitly call the `connect` method to initiate the connection. Operations that depend on being connected, like `getInputStream`, `getOutputStream`, etc, will implicitly perform the connection, if necessary.

 The next section shows you how.

url: https://raw.githubusercontent.com/li-jiabao/li-jiabao.github.io/f42a68eeeb57e54b6b628030379255d9ac00b131/_drafts/BigJava/Custom Networking/Reading Directly from a URL.md

filename: Reading Directly from a URL.md


text:
# Private, firstprivate and lastprivate clauses

Check the following program:

	#include <stdio.h>
	#include <unistd.h>
	#include <omp.h>

	int main(void)
	{
		int var = 100;

		printf("Before parallelism, var's address is %p\n", &var);

		#pragma omp parallel for
		for (int i = 0; i < 4; i++)
		{
			printf("var's address in thread %d is %p\n", omp_get_thread_num(), &var);
			var = i;
		}

		printf("After parallelism, var's address is %p, and value is %d\n", &var, var);
		return 0;
	}

Build and run it:

	# gcc -fopenmp parallel.c
	# ./a.out
	Before parallelism, var's address is 0x7ffe993d79fc
	var's address in thread 1 is 0x7ffe993d79fc
	var's address in thread 2 is 0x7ffe993d79fc
	var's address in thread 3 is 0x7ffe993d79fc
	var's address in thread 0 is 0x7ffe993d79fc
	After parallelism, var's address is 0x7ffe993d79fc, and value is 0
	# ./a.out
	Before parallelism, var's address is 0x7ffc13c7cd8c
	var's address in thread 3 is 0x7ffc13c7cd8c
	var's address in thread 2 is 0x7ffc13c7cd8c
	var's address in thread 0 is 0x7ffc13c7cd8c
	var's address in thread 1 is 0x7ffc13c7cd8c
	After parallelism, var's address is 0x7ffc13c7cd8c, and value is 1
	# ./a.out
	Before parallelism, var's address is 0x7ffd72be3bbc
	var's address in thread 3 is 0x7ffd72be3bbc
	var's address in thread 2 is 0x7ffd72be3bbc
	var's address in thread 0 is 0x7ffd72be3bbc
	var's address in thread 1 is 0x7ffd72be3bbc
	After parallelism, var's address is 0x7ffd72be3bbc, and value is 1

Every thread prints the same address value of `var` variable, the `var` variable is shared in all threads. Because there is no protection of accessing shared variable, the final value of `var` is undefined.

Use `private` clause can let every thread get its own copy of shared variable, but the initial value is still unspecified:

	#include <stdio.h>
	#include <unistd.h>
	#include <omp.h>

	int main(void)
	{
		int var = 100;

		printf("Before parallelism, var's address is %p\n", &var);

		#pragma omp parallel for private(var)
		for (int i = 0; i < 4; i++)
		{
			printf("var's address in thread %d is %p, value is %d\n", omp_get_thread_num(), &var, var);
			var = i;
		}

		printf("After parallelism, var's address is %p, and value is %d\n", &var, var);
		return 0;
	}
Build and run it:

	# gcc -fopenmp parallel.c
	# ./a.out
	Before parallelism, var's address is 0x7ffde0e4c124
	var's address in thread 3 is 0x7f0fe9bf0e20, value is 0
	var's address in thread 1 is 0x7f0feabf2e20, value is 0
	var's address in thread 2 is 0x7f0fea3f1e20, value is 0
	var's address in thread 0 is 0x7ffde0e4c0c0, value is 24
	After parallelism, var's address is 0x7ffde0e4c124, and value is 100

From the printed address of `var` variable in every thread, we can see every thread gets a local copy of `var`, but the initial value is random. The local `var` variable in `main` function is no affected.

`firstprivate` clause makes a copy from the shared variable:

	#include <stdio.h>
	#include <unistd.h>
	#include <omp.h>

	int main(void)
	{
		int var = 100;

		printf("Before parallelism, var's address is %p\n", &var);

		#pragma omp parallel for firstprivate(var)
		for (int i = 0; i < 4; i++)
		{
			printf("var's address in thread %d is %p, value is %d\n", omp_get_thread_num(), &var, var);
			var = i;
		}

		printf("After parallelism, var's address is %p, and value is %d\n", &var, var);
		return 0;
	}

Build and run it:

	# gcc -fopenmp parallel.c
	# ./a.out
	Before parallelism, var's address is 0x7ffe3ae46e00
	var's address in thread 0 is 0x7ffe3ae46da0, value is 100
	var's address in thread 3 is 0x7ff6870ede20, value is 100
	var's address in thread 2 is 0x7ff6878eee20, value is 100
	var's address in thread 1 is 0x7ff6880efe20, value is 100
	After parallelism, var's address is 0x7ffe3ae46e00, and value is 100

The `var` in every thread is initialized as `100`.

`lastprivate` clause makes the value in last sequential iteration assigned back to the shared variable:

	#include <stdio.h>
	#include <unistd.h>
	#include <omp.h>

	int main(void)
	{
		int var = 100;

		printf("Before parallelism, var's address is %p\n", &var);

		#pragma omp parallel for lastprivate(var)
		for (int i = 0; i < 4; i++)
		{
			printf("var's address in thread %d is %p, value is %d\n", omp_get_thread_num(), &var, var);
			var = i;
		}

		printf("After parallelism, var's address is %p, and value is %d\n", &var, var);
		return 0;
	}

Build and run it:

	# gcc -fopenmp parallel.c
	# ./a.out
	Before parallelism, var's address is 0x7ffd53ea3fb0
	var's address in thread 0 is 0x7ffd53ea3f50, value is 24
	var's address in thread 3 is 0x7fd70584fe20, value is 0
	var's address in thread 2 is 0x7fd706050e20, value is 0
	var's address in thread 1 is 0x7fd706851e20, value is 0
	After parallelism, var's address is 0x7ffd53ea3fb0, and value is 3
	# ./a.out
	Before parallelism, var's address is 0x7fff72604380
	var's address in thread 0 is 0x7fff72604320, value is 24
	var's address in thread 2 is 0x7f6f3ac49e20, value is 0
	var's address in thread 1 is 0x7f6f3b44ae20, value is 0
	var's address in thread 3 is 0x7f6f3a448e20, value is 0
	After parallelism, var's address is 0x7fff72604380, and value is 3

Since in following loop:

	for (int i = 0; i < 4; i++)
	{
		......
	}

`i = 3` is the last sequential iteration, the shared variable `var` is always updated to `3`.

repository: john-tsang/openmp-little-book

repo_name: john-tsang/openmp-little-book


text:
# Battery Historian

Battery Historian is a tool to inspect battery related information and events on an Android device running Android 5.0 Lollipop (API level 21) and later, while the device was not plugged in. It allows application developers to visualize system and application level events on a timeline with panning and zooming functionality, easily see various aggregated statistics since the device was last fully charged, and select an application and inspect the metrics that impact battery specific to the chosen application. It also allows an A/B comparison of two bugreports, highlighting differences in key battery related metrics.

## Getting Started

#### Using Docker

Install [Docker](<https://docs.docker.com/engine/installation/>).

Run the Battery Historian image. Choose a port number and replace `<port>` with
that number in the commands below:

```
docker -- run -p <port>:9999 gcr.io/android-battery-historian/stable:3.0 --port 9999
```

For Linux and Mac OS X:

* That's it, you're done! Historian will be available at
  `http://localhost:<port>`.

For Windows:

* You may have to [enable Virtualization in your
  BIOS](<http://www.itworld.com/article/2981515/virtualization/virtualbox-diagnose-and-fix-vt-xamd-v-hardware-acceleration-errors.html>).

* Once you start Docker, it should tell you the IP address of the machine it is
using. If, for example, the IP address is 123.456.78.90, Historian will be
available at `http://123.456.78.90:<port>`.

For more information about the port forwarding, see the [Docker
documentation](<https://docs.docker.com/engine/reference/run/#/expose-incoming-ports>).

#### Building from source code

Make sure you have at least Golang version 1.8.1:

* Follow the instructions available at <http://golang.org/doc/install> for downloading and installing the Go compilers, tools, and libraries.
* Create a workspace directory according to the instructions at
  <http://golang.org/doc/code.html#Organization>.
* Ensure that `GOPATH` and `GOBIN` environment variables are appropriately set and added to your `$PATH`
  environment variable. `$GOBIN should be set to $GOPATH/bin`.
  * For Windows, you may set environment variables through the "Environment Variables" button on the
  "Advanced" tab of the "System" control panel. Some versions of Windows provide this control panel
  through the "Advanced System Settings" option inside the "System" control panel.
  * For Linux and Mac OS X, you can add the following lines to your ~/.bashrc or
    ~/.profile files (assuming your workspace is $HOME/work):

      ```
      export GOPATH=$HOME/work
      export GOBIN=$GOPATH/bin
      export PATH=$PATH:$GOBIN
      ```

Next, install Git from <https://git-scm.com/downloads> if it's not already installed.

Next, make sure Python 2.7 (NOT Python 3!) is installed. See <https://python.org/downloads>
if it isn't, and ensure that python is added to your `$PATH` environment variable.

Next, install Java from <http://www.oracle.com/technetwork/java/javase/downloads/index.html>.

Next, download the Battery Historian code and its dependencies:

```
$ go get -d -u github.com/google/battery-historian/...
```

Finally, run Battery Historian!

```
$ cd $GOPATH/src/github.com/google/battery-historian

# Compile Javascript files using the Closure compiler
$ go run setup.go

# Run Historian on your machine (make sure $PATH contains $GOBIN)
$ go run cmd/battery-historian/battery-historian.go [--port <default:9999>]
```

Remember, you must always run battery-historian from inside the `$GOPATH/src/github.com/google/battery-historian` directory:

```
cd $GOPATH/src/github.com/google/battery-historian
go run cmd/battery-historian/battery-historian.go [--port <default:9999>]
```

#### How to take a bug report

To take a bug report from your Android device, you will need to enable USB debugging under `Settings > System > Developer Options`. On Android 4.2 and higher, the Developer options screen is hidden by default. You can enable this by following the instructions [here](<http://developer.android.com/tools/help/adb.html#Enabling>).

To obtain a bug report from your development device running Android 7.0 and
higher:

```
$ adb bugreport bugreport.zip
```

For devices 6.0 and lower:

```
$ adb bugreport > bugreport.txt
```

### Start analyzing!

You are all set now. Run `historian` and visit <http://localhost:9999> and
upload the `bugreport.txt` file to start analyzing.

## Screenshots

##### Timeline:

![Timeline](/screenshots/timeline.png "Timeline Visualization")

##### System stats:

![System](/screenshots/system.png "Aggregated System statistics since the device was last fully charged")

##### App stats:

![App](/screenshots/app.png "Application specific statistics")

## Advanced

To reset aggregated battery stats and history:

```
adb shell dumpsys batterystats --reset
```

##### Wakelock analysis

By default, Android does not record timestamps for application-specific
userspace wakelock transitions even though aggregate statistics are maintained
on a running basis. If you want Historian to display detailed information about
each individual wakelock on the timeline, you should enable full wakelock
reporting using the following command before starting your experiment:

```
adb shell dumpsys batterystats --enable full-wake-history
```

Note that by enabling full wakelock reporting the battery history log overflows
in a few hours. Use this option for short test runs (3-4 hrs).

##### Kernel trace analysis

To generate a trace file which logs kernel wakeup source and kernel wakelock
activities:

First, connect the device to the desktop/laptop and enable kernel trace logging:

```
$ adb root
$ adb shell

# Set the events to trace.
$ echo "power:wakeup_source_activate" >> /d/tracing/set_event
$ echo "power:wakeup_source_deactivate" >> /d/tracing/set_event

# The default trace size for most devices is 1MB, which is relatively low and might cause the logs to overflow.
# 8MB to 10MB should be a decent size for 5-6 hours of logging.

$ echo 8192 > /d/tracing/buffer_size_kb

$ echo 1 > /d/tracing/tracing_on
```

Then, use the device for intended test case.

Finally, extract the logs:

```
$ echo 0 > /d/tracing/tracing_on
$ adb pull /d/tracing/trace <some path>

# Take a bug report at this time.
$ adb bugreport > bugreport.txt
```

Note:

Historian plots and relates events in real time (PST or UTC), whereas kernel
trace files logs events in jiffies (seconds since boot time). In order to relate
these events there is a script which approximates the jiffies to utc time. The
script reads the UTC times logged in the dmesg when the system suspends and
resumes. The scope of the script is limited to the amount of timestamps present
in the dmesg. Since the script uses the dmesg log when the system suspends,
there are different scripts for each device, with the only difference being
the device-specific dmesg log it tries to find. These scripts have been
integrated into the Battery Historian tool itself.

##### Power monitor analysis

Lines in power monitor files should have one of the following formats, and the
format should be consistent throughout the entire file:

```
<timestamp in epoch seconds, with a fractional component> <amps> <optional_volts>
```

OR

```
<timestamp in epoch milliseconds> <milliamps> <optional_millivolts>
```

Entries from the power monitor file will be overlaid on top of the timeline
plot.

To ensure the power monitor and bug report timelines are somewhat aligned,
please reset the batterystats before running any power monitor logging:

```
adb shell dumpsys batterystats --reset
```

And take a bug report soon after stopping power monitor logging.

If using a Monsoon:

Download the AOSP Monsoon Python script from <https://android.googlesource.com/platform/cts/+/master/tools/utils/monsoon.py>

```
# Run the script.
$ monsoon.py --serialno 2294 --hz 1 --samples 100000 -timestamp | tee monsoon.out

# ...let device run a while...

$ stop monsoon.py
```

##### Modifying the proto files

If you want to modify the proto files (pb/\*/\*.proto), first download the
additional tools necessary:

Install the standard C++ implementation of protocol buffers from <https://github.com/google/protobuf/blob/master/src/README.md>

Download the Go proto compiler:

```
$ go get -u github.com/golang/protobuf/protoc-gen-go
```

The compiler plugin, protoc-gen-go, will be installed in $GOBIN, which must be
in your $PATH for the protocol compiler, protoc, to find it.

Make your changes to the proto files.

Finally, regenerate the compiled Go proto output files using `regen_proto.sh`.

##### Other command line tools

```
# System stats
$ go run cmd/checkin-parse/local_checkin_parse.go --input=bugreport.txt

# Timeline analysis
$ go run cmd/history-parse/local_history_parse.go --summary=totalTime --input=bugreport.txt

# Diff two bug reports
$ go run cmd/checkin-delta/local_checkin_delta.go --input=bugreport_1.txt,bugreport_2.txt
```

## Support

- G+ Community (Discussion Thread: Battery Historian): https://plus.google.com/b/108967384991768947849/communities/114791428968349268860

If you've found an error in this project, please file an issue:
<https://github.com/google/battery-historian/issues>

## License

Copyright 2016 Google, Inc.

Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at

  <http://www.apache.org/licenses/LICENSE-2.0>

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.  See the
License for the specific language governing permissions and limitations under
the License.

repository: lilydjwg/battery-historian

gha_license_id: NOASSERTION

repo_name: lilydjwg/battery-historian


text:
# InterPlanetary Container Registry

*Disclaimer: this project is in the early prototype stage.*

The ultimate goal of this project is to build a fully decentralised version of [Docker Hub](https://hub.docker.com) with the following features:
* Images and their metadata are stored on p2p storage.
* Private images are encrypted.
* Decentralised identification.
* Web frontend is running on p2p network.

You can check a prototype of the web frontend in [ipcr/web](https://github.com/ipcr/web). It looks like an extremely simplified version of Docker Hub. Live demo is running [on Fleek](https://ipcr.on.fleek.co).

The project was started at [HackFS](https://hackfs.com). HackFS is a virtual Hackathon by ETHGlobal and Protocol Labs.

The following sections of the document describe how to build a rudimentary public container registry using [IPFS](https://ipfs.io), [IPNS](https://docs.ipfs.io/concepts/ipns/) and [DNSLink](https://dnslink.io).

In the future a tool called `ipcr` will be built.
So that you can simply `ipcr push image:tag` to publish an image.
And `ipcr pull some.domain/image:tag` to pull an image.

## Prerequisites

All commands below were tested on macOS version 10.15.5 running Docker Desktop <IP_ADDRESS>.

### Install IPFS

You can follow the [official guide](https://docs.ipfs.io/install/command-line-quick-start/#install-ipfs).
But, using Homebrew is quicker:

	$ brew install ipfs

### Initialize IPFS repository

To initialize the repository, run the following command:

	$ ipfs init

For more details, see [IPFS documentation](https://docs.ipfs.io/install/command-line-quick-start/#initialize-the-repository).

### Take IPFS node online

To join your node to the public network, run the ipfs daemon:

	$ ipfs daemon

## Initialize container registry

To create an empty container registry and enable [IPNS](https://docs.ipfs.io/concepts/ipns/#example-ipns-setup) for it, run the following commands:

```console
$ mkdir .ipcr
$ ipfs add -Qr .ipcr
QmUNLLsPACCz1vLxQVkXqqLX5R1X345qqfHbsf67hvA3Nn
$ ipfs name publish QmUNLLsPACCz1vLxQVkXqqLX5R1X345qqfHbsf67hvA3Nn
Published to QmTw9u8R3FCh2DR1t6PvkWibVnZXJfujzEKV2o4SRrTPLV: /ipfs/QmUNLLsPACCz1vLxQVkXqqLX5R1X345qqfHbsf67hvA3Nn
```

Note, that publishing to IPNS takes some time.

The last hash, next to the folder CID, is the one to remember, call it `$PEER_ID` for now:

	$ PEER_ID=QmTw9u8R3FCh2DR1t6PvkWibVnZXJfujzEKV2o4SRrTPLV

## Edit your DNS records

Assume you have the domain name `your.domain` and can access your registrar's control panel to manage DNS entries for it.

Create a DNS TXT record ([DNSLink](https://docs.ipfs.io/concepts/dnslink/)), with the key `your.domain`. and the value `dnslink=/ipns/$PEER_ID` where `$PEER_ID` is the value from the section above.

Once you've created that record, and it has propagated you should be able to find it.

```console
$ dig +noall +answer TXT your.domain
your.domain.            60      IN      TXT     "dnslink=/ipns/$PEER_ID"
```

You can now list registry contents using `your.domain`:

	$ ipfs ls /ipns/your.domain

Note, that the registry is still empty.
Time to add some images!

## Push Docker image to IPFS

First, you should pull some image from [Docker Hub](https://hub.docker.com):

	$ docker pull -q ipfs/go-ipfs:v0.6.0

Next, save this image to your registry directory:

	$ mkdir -p .ipcr/go-ipfs/tags/v0.6.0
	$ echo 'Go implementation of IPFS, the InterPlanetary FileSystem' > .ipcr/go-ipfs/README-short.txt
	$ docker save ipfs/go-ipfs:v0.6.0 | tar -xf - -C .ipcr/go-ipfs/tags/v0.6.0

Finally, publish the updated version of your container registry to IPFS:

```console
$ ipfs add -Qr .ipcr
QmcZqjtj3QhYEAr8a9Uu1A3vThtn5uee9iMjVJEzMYaY4p
$ ipfs name publish /ipfs/QmcZqjtj3QhYEAr8a9Uu1A3vThtn5uee9iMjVJEzMYaY4p
Published to QmTw9u8R3FCh2DR1t6PvkWibVnZXJfujzEKV2o4SRrTPLV: /ipfs/QmcZqjtj3QhYEAr8a9Uu1A3vThtn5uee9iMjVJEzMYaY4p
```

## Pull Docker image from IPFS

To pull an image you download it from IPFS and then load using Docker:

	$ ipfs get -o go-ipfs:v0.6.0 /ipns/your.domain/go-ipfs/tags/v0.6.0
	$ tar --strip-components 1 -cf - go-ipfs:v0.6.0 | docker load

Note, that downloading the image as a TAR archive from IPFS using `--archive` and loading this archive using Docker doesn't work.
Because the leading path element of the archive will be `v0.6.0` in that case.
This is not expected by Docker and you'll get a non obvious error saying `open /var/lib/docker/tmp/docker-import-787571586/v0.6.0/json: no such file or directory` when loading the image.
Therefore, the image directory is archived with `--strip-components 1` before loading.

## Prior art

The following list contains a few projects that implement a [Docker Registry](https://docs.docker.com/registry) on top of IPFS:

* [Storage Driver: Add an IPFS driver](https://github.com/docker/distribution/pull/2906)
* [IPDR: InterPlanetary Docker Registry](https://github.com/miguelmota/ipdr)
* [Docker Registry for IPFS](https://blog.bonner.is/docker-registry-for-ipfs)

## License

This project is licensed under the MIT License–see the [LICENSE](LICENSE) file for details.

repository: ipcr/ipcr

repo_name: ipcr/ipcr


text:
# V1beta2Subject

Subject matches the originator of a request, as identified by the request authentication system. There are three ways of matching an originator; by user, group, or service account.
## Properties

Name | Type | Description | Notes
------------ | ------------- | ------------- | -------------
**group** | [**V1beta2GroupSubject**](V1beta2GroupSubject.md) |  |  [optional]
**kind** | **String** | `kind` indicates which one of the other fields is non-empty. Required |
**serviceAccount** | [**V1beta2ServiceAccountSubject**](V1beta2ServiceAccountSubject.md) |  |  [optional]
**user** | [**V1beta2UserSubject**](V1beta2UserSubject.md) |  |  [optional]

repository: kubernetes-client/java

repo_name: kubernetes-client/java


text:
# aspnet-webapi-starter

A starter template for development of ASP .NET Core Web API inside Docker containers with Visual Studio Code

## Try it on your Dev Machine

1. Install the prerequisites
    - [Docker for Desktop](https://www.docker.com/products/docker-desktop)
    - [Visual Studio Code](https://code.visualstudio.com/)
      - install extention [Remote Development](https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.vscode-remote-extensionpack)
    - [git](https://git-scm.com/downloads)
2. Clone the repo
    ```
    git clone https://github.com/vtrifonov-esfiddle/aspnet-webapi-starter.git
    ```
3. Open the repo root directory in VS Code
4. Press F1 in VS Code
5. type `>Remote-Containers: Reopen in Container`
6. Press F5 in VS Code to start debugging
7. On your dev machine navigate to http://localhost:5000/

### Environment Variables

The following environment variables are available for `aspnet-webapi-starter` container

- WORKSPACE_DIR_DOCKER_MOUNT
  - this is the repository workspace root directory docker mount
  - e.g `/host_mnt/c/GithubRepos/aspnet-webapi-starter`
  - necessary for bind mounts because you cannot start nested docker container from `aspnet-webapi-starter` on non-linux host machine
    - [see bind mounts propagation](https://docs.docker.com/storage/bind-mounts/#configure-bind-propagation)
- DOCKER_REGISTRY
  - your github docker registry
  - allows you to tag/push/pull images to your docker registry without hardcoding it
    - you need to [login to the registry](#-Push/Pull-from-your-aspnet-webapi-starter-Docker-Registry) to use it
  - e.g: `docker.pkg.github.com/vtrifonov-esfiddle/aspnet-webapi-starter`
    - this matches `docker.pkg.github.com/${{ github.repository }}` from the github workflow `CI`
- GITHUB_USERNAME
  - your github username

## Push/Pull from your aspnet-webapi-starter Docker Registry

To work locally with your docker registry you need read and write access. Performs the steps once you have generated your repo from the template

1. create `PAT` (personal access token) with the following permissions via https://github.com/settings/tokens
    - read:packages
    - repo, write:packages
2. on the dev container login to the registry using `PAT`
   - the username is provided via an environment variable available on the dev container
```
docker login docker.pkg.github.com -u $GITHUB_USERNAME
```


text:
# rustils

[![Latest Stable Version](https://img.shields.io/npm/v/rustils.svg)](https://www.npmjs.com/package/rustils)
[![License](https://img.shields.io/npm/l/rustils.svg)](./LICENSE)
[![Build Status](https://img.shields.io/travis/Lodin/rustils/master.svg)](https://travis-ci.org/Lodin/rustils)

[![Test Coverage](https://img.shields.io/codecov/c/github/Lodin/rustils/master.svg)](https://codecov.io/gh/Lodin/rustils)

A port of some powerful Rust abstractions to JavaScript. By now it contains following modules:
* **[Option](https://lodin.github.io/rustils/modules/option.html)** ([rust doc](https://doc.rust-lang.org/std/option/index.html)) - an abstraction designed to
handle operations with `null` in the functional style, an implementation of functional monad
`Maybe`.
* **[Result](https://lodin.github.io/rustils/modules/result.html)** ([rust doc](https://doc.rust-lang.org/std/result/)) - an abstraction that is able to
supplement - or even replace, - the standard exception scheme. Depending on function result it
may wrap success or error value and is able to be processed in accordance with this result.

## Documentation
Complete project documentation can be found [here](https://lodin.github.io/rustils/).

## Installation
To install `rustils` run the following command in the console:
```bash
$ npm i --save rustils
```
## Usage
Import package in your code and you are ready:
```typescript
import {Some, Option} from 'rustils';

const option: Option<number> = Some(10);
assert.equal(option.map(v => v + 50).unwrap(), 60);
```
You can see detailed using in [API reference](https://lodin.github.io/rustils/).

### JavaScript usage
As you can see, all examples is written in Typescript here. But if you want to use this library
with JavaScript, there is no problem. Just throw out all the types and use the package.
```javascript
var rustils = require('rustils');
var Some = rustils.Some;
var None = rustils.None;

var option = Some(10);
assert.equal(option.map(function(v) { return v + 50; }).unwrap(), 60);
```

## About project
This project is highly inspired by [r-result](https://github.com/Havvy/result). `r-result` is a
nice project, but it lacks typescript support and implements only `Result` type, without `Option`.
So I decided to create my own rust-port project. Hope it will be useful for anyone.

The `rustils` type system is made as close as it can to the Rust original. Some function like
`take` or `as_ref` that has it's use in Rust, in JavaScript does not make sense, so they are not
implemented.

## License
Information about license can be found [here](./LICENSE).

repository: Lodin/rustils

repo_name: Lodin/rustils