text:
---
title: 'Automated Management of AWS Instances for Training'
tags:
  - Bash scripts
  - AWS instances
  - automated management
  - teaching assistance
authors:
  - name: Jorge Buenabad-Chavez
    orcid: 0009-0003-1751-653X
    affiliation: 1             # "1, 2" # (Multiple affiliations must be quoted)
  - name: Emma Rand
    orcid: 0000-0002-1358-8275
    affiliation: 1
  - name: James P.J. Chong
    orcid: 0000-0001-9447-7421
    affiliation: 1
affiliations:
 - name: Biology Department, University of York
   index: 1
date: 5 June 2023
bibliography: paper.bib
# Optional fields if submitting to a AAS journal too, see this blog post:
# https://blog.joss.theoj.org/2018/12/a-new-collaboration-with-aas-publishing
# aas-doi: 10.3847/xxxxx <- update this with the DOI from AAS once you know it.
# aas-journal: Astrophysical Journal <- The name of the AAS journal.
---

# Summary

We present a set of Bash scripts that make it quick and easy to manage [AWS](https://aws.amazon.com/) instances for training delivery. We use the scripts to automate the creation of instances (which are Linux virtual machines) for genomics and metagenomics workshops. Instances are created before a workshop with ‘omics data and software analysis tools required for the workshop. Each student is granted exclusive access to an instance through the use of an encrypted login key with the ``ssh`` program:

```
   ssh -i login-key-instance01.pem<EMAIL_ADDRESS>```

Running the scripts requires only the path of the file that contains the names of the instances to create, stop, start or delete — login keys, IP addresses and domain names used by the instances are created or deleted automatically, see the screenshot below which shows the script `csinstance_create.sh` being run in a Linux *terminal* to create three instances whose names are specfied in the inputs file `courses/instances-management/inputs/instancesNames.txt`.  Creating over 30 instances takes 10-15 minutes.

![Output of running the script **csinstances_create.sh** — first part. The output last part (not shown) includes these steps: (**4**) creating the instance domain names as mapped to the relevant IP addresses, (**5**) associating IP addresses to instances, (**6**) accessing each instance with **ssh** as shown above but with the **ubuntu** user (AWS default) to configure the csuser as to being accessed with the same login key, and (**7**) accessing each instance with the csuser (as above) to validate such configuration was successful. Running the script **csinstances_delete.sh** with the same input file will delete those instances and related login keys, IP addresses, and domain names from the AWS account.](fig01-csinstances_create-output-first-part.png)

# Statement of need
Genomics and metagenomics typically require analyzing gigabyte to terabyte sized data sets with packages that have multiple dependencies. This creates a steep learning curve that can be off putting for biologists. 'Omics training can be made more accessible if participants do not need to manage complex software installation or large datasets by following the Data Carpentries approach to using cloud resources to provide each participant with a properly configured AWS instance.

However, managing multiple instances through a graphical user interface (GUI), such as the AWS Console, is cumbersome and error-prone especially as the number of participants increases. Our scripts automate the creation and deletion of AWS instances and related resources to access them: login keys, IP addresses and domain names.

The scripts are supported by an accompanying online course: [Automated Management of AWS Instances](https://cloud-span.github.io/cloud-admin-guide-0-overview/) [@buenabad23].

# The scripts
The scripts are listed below. The scripts "`csinstances_*.sh`" are to be run by the user of the scripts, the person in charge of managing instances for workshops.

```
aws_domainNames_create.sh        aws_instances_configure.sh  csinstances_create.sh
aws_domainNames_delete.sh        aws_instances_launch.sh     csinstances_delete.sh
aws_elasticIPs_allocate.sh       aws_instances_terminate.sh  csinstances_start.sh
aws_elasticIPs_associate2ins.sh  aws_loginKeyPair_create.sh  csinstances_stop.sh
aws_elasticIPs_deallocate.sh     aws_loginKeyPair_delete.sh
aws_elasticIPs_disassociate.sh   colour_utils_functions.sh
```

The scripts "`aws_*.sh`" are invoked by the scripts `csinstances_create.sh` or `csinstances_delete.sh` to either create or delete instances and *related resources* (login keys, IP addresses and domain names used by instances). However, the scripts "`aws_*.sh`" can also be run directly by the user in the same way (passing as parameter the path of a file "*instancesNames.txt*"). This may be useful to improve the scripts or to fix a failed step in creating instances.  The file `colours_utils_functions.sh` provides (is “sourced” by) the other scripts with text colouring functions and other utility functions.

## The scripts design — overview
AWS services can be managed using the AWS Console, the AWS CLI (command line interface), SDKs (libraries) with programming languages, or infrastructure as code (IaC) blueprints — the level of automation increases from the former to the latter [@wittig23].

The scripts make use of the AWS CLI to manage instances and *related resources*, invoking the AWS CLI repeatedly for each instance name specified in the input file provided to a script. The scripts communicate through shared files.

When **creating** instances and related resources, the results returned by each AWS CLI invocation include the **resource-id** assigned by AWS to each instance or resource. As a resource-id is needed to further manage the corresponding resource, for example, to delete it, the scripts store the results of each AWS invocation to a file. The name of each file has, as a sub-string, the name of the relevant instance, so that the scripts can later recover the resource-id of the resources to  delete, stop, etc.

The names of login key files and domain names are managed similarly: including the relevant instance name as a substring, as exemplified in the `ssh` example above: the instance name ``instance01`` was made part of both the login key file name and the domain name.

# Configuring the scripts
How to configure and use the scripts is described in detail in the online course [Automated Management of AWS Instances](https://cloud-span.github.io/cloud-admin-guide-0-overview/)  [@buenabad23] which covers the following main topics:

- how to open an AWS account and how to configure it both with programmatic access with the AWS CLI (as required by the scritps) and with a base domain name (cloud-span.aws.york.ac.uk in the example above) from which to create each instance domain name.

- how to configure a *terminal* environment with the scripts and the AWS CLI — in Linux, Mac, Windows (Git Bash), or the AWS CloudShell.

- how to configure and run the scripts to manage instances for a workshop, manage late registrations and cancellations, and some troubleshooting.

- how to create and manage Amazon Machine Images (AMIs) which serve as templates to create AWS instances.

- the organisation and workings of the scripts.

## Managing instances for workshops
Once an AWS account and a terminal environment have been configured, configuring the scripts to create and manage instances for a workshop involves creating three files:

- **tags.txt** contains a set of key-value pairs to tag instances and related resources on creating them.

- **resourcesIDs.txt** contains the AWS resources to use in creating intances and related resources, namely: the id of the AMI from which instances will be created, the AWS instance type (number of processors and memory) to use for each instance, security group id, subnet id, the base domain name, and the host zone id.

- *instancesNames.txt* — contains the name of the instances to be created. Only this file can be named differently to your choice.

The three files must be placed inside a directory called **inputs**, and the inputs directory must be placed within at least other directory whose name you can choose. We use this directory structure:

```
courses                       ### you can omit this directory or use other name
   genomics01                 ### course/workshop name; you can use other name
      inputs                  ### you **cannot** use other name
         instancesNames.txt   ### you can use other name
         resourcesIDs.txt     ### you **cannot** use other name
         tags.txt             ### you **cannot** use other name
      outputs                 ### created automatically - do not modify it at all
   genomics02                 ### another course: inputs and outputs dirs. inside
   metagenomics01             ### another course: inputs and outputs dirs. inside
```

# Conclusions
Using the scripts is rather easy and most convenient once the scripts environment has been configured. We have saved a lot of time in managing the instances for our workshops for over a year. Most of the time we only need to configure the file "*instancesNames.txt*" with the names of the instances to manage for a workshop. The file **tags.txt** has to be configured only once and we copy it to manage instances for other workshops. Similary, the file **resourcesIDs.txt** needs to be configured only once for workshops that use a different instance type (t3.small, t3.medium, etc.) or a different AMI template. We handle only two `resourcesIDs.txt` files, one for our genomics workshops and the other for our metagenomics workshops. They differ on both the instance type and the AMI template id, but are the same in all other entries: subnet-id, base domatin name, etc.

Configuring the scripts environment is somewhat involved but it has to be made only once and the online course covers all the details. It should take 2 to 4 hours depending on experience to cover the course along with configuring the scripts environment.

We used the scripts to support delivery of 'omics training, but the scripts will work equally well for Linux instances configured for other purposes.

# Acknowledgements

We acknowledge funding from the UKRI innovation scholars award, project reference: MR/V038680/1 and the Natural Environment Research Council, project reference: NE/X006999/1.

# References

repository: Cloud-SPAN/aws-instances

gha_language: Shell

repo_name: Cloud-SPAN/aws-instances


text:
---
title: "Support vector machines for forest fire prediction"
author: matt_gregory
comments: yes
date: '2016-03-15'
modified: 2016-03-21
layout: post
excerpt: "Predicting forest fire scale using support vector machines"
published: true
status: publish
tags:
- R
- machine learning
- weather
- forest fires
categories: Rstats
---

{% include _toc.html %}

## Introduction
This post is based on a paper by Cortez & Morais (2007). Forest fires are a major environmental issue, creating economical and ecological damage while endangering human lives. Fast detection is a key element for controlling such phenomenon. To achieve this, one alternative is to use automatic tools based on local sensors, such as microclimate and weather data provided by meteorological stations.

All this data holds valuable information, such as trends and patterns, which can be used to improve decision making. Yet, human experts are limited and may overlook important details. Moreover, classical statistical analysis breaks down when such vast and/or complex data is present. Hence, the alternative is to use automated machine learning tools to analyze the raw data and extract high-level information for the decision-maker.

This is a very difficult regression task. We got the forest fire data from the UCI machine [learning repository](http://archive.ics.uci.edu/ml/datasets/Forest+Fires). Specifically we want to predict the burned area or size of the forest fires in the northeast region of Portugal. We demonstrate the proposed solution of Cortez which includes only four weather variables (i.e. rain, wind, temperature and humidity) in conjunctionwith a support vector machines (SVM) and it is capable of predicting the burned area of small fires, which constitute the majority of the fire occurrences.

{% highlight r %}
set.seed(1337)

#PACKAGES
library(dplyr)
library(kernlab)
library(ROCR)
library(caret)
library(e1071)

#INPUT
mydata <- "data/2016-03-21-fires_cortez.csv"
mydata <- read.table(mydata, sep = ",",
                     header = TRUE)
mydata <- tbl_df(mydata)  # observed data set
{% endhighlight %}

A SVM uses a nonlinear mapping to transform the original training data into a higher dimension. Within this new dimension, it searches for the linear optimal separating hyperplane.

## Objective
* Perform a support vector regression.
* Assess the accuracy of the model.
* Demonstrate the work flow for fitting a SVM for classification in R.

## The data

Upon `glimpse()`ing the data, we notice the `area` of the burn has a lot of zeroes. We investigate further with a histogram. We may want to `log(area+1)` transform the area due to the heavy skew and many zeroes (fires that burnt less than a hectare). The variables are fully explained in the original paper.

{% highlight r %}
hist(mydata$area)
rug(mydata$area)
{% endhighlight %}

![plot of chunk 2016-03-21_hist2](/figures/2016-03-21_hist2-1.svg)

We transform `area` into the new response variable `y`, this would be useful if we wanted to use the SVM for regression.

{% highlight r %}
mydata <- mutate(mydata, y = log(area + 1))  # default is to the base e, y is lower case
hist(mydata$y)
{% endhighlight %}

![plot of chunk 2016-03-21_hist1](/figures/2016-03-21_hist1-1.svg)

We start at an advantage, as we know what model structure for the SVM was most effective for prediction based on the findings of the paper. Thus we can limit our data preparation to a few variables.The proposed solution, which is based in a SVM and requires only four direct
weather inputs (i.e. temperature, rain, relative humidity and wind speed) is capable of predicting small fires, which constitute the majority of the fire occurrences.

We also need to normalise the continuous variables between zero and one to control for different ranges. However, the function we use does this for us! We show what it would look like if we wanted to set this up manually but we don't evaluate it.

{% highlight r %}
normalise <- function(x) {
  return((x - min(x)) / (max(x) - min(x)))  # subtract the min value in x and divide by the range of values in x.
}

mydata$temp <- normalise(mydata$temp)
mydata$rain <- normalise(mydata$rain)
mydata$RH <- normalise(mydata$RH)
mydata$wind <- normalise(mydata$wind)
{% endhighlight %}

## Classification
SVM is better suited to a classification problem. Let's pretend we're interested in the weather conditions that give rise to small fires (arbitary set to < 5 hectares), compared to larger fires. Can we classify the type of fire we might expect to see if we send a fireman out with remote meterological data? This may help them bring the right gear.

{% highlight r %}
# note, our earlier transformation was redundant, $area gives the same results
sum(mydata$area < 5)  # ln(0 + 1) = 0
{% endhighlight %}

{% highlight text %}
## [1] 366
{% endhighlight %}

{% highlight r %}
sum(mydata$area >= 5)
{% endhighlight %}

{% highlight text %}
## [1] 151
{% endhighlight %}

These fires are split unevenly.

{% highlight r %}
mydata$size <- NULL
mydata$size <- factor(ifelse(mydata$area < 5, 1, 0),
                       labels = c("small", "large"))
#tail(mydata[, c("size", "area")])  #  checks out
{% endhighlight %}

## Splitting the data
As usual, we need a training and testing data set to assess how well the model predicts data it hasn't seen before.

{% highlight r %}
train <- sample(x = nrow(mydata), size = 400, replace = FALSE)  # sample takes place from 1:x, convenience
#test, not train, use - selection
{% endhighlight %}

## Method
We use the `kernlab` package and the `ksvm()` function therein to fit an SVM using a non-linear kernel. We can use the argument `kernel = "polydot"` to set it to polynomial or `"rbfdot"` for a radial basis and `"tanhdot"` for the complicated sounding hyperbolic tangentsigmoid. Note the hugh amount of parameter customisation that is possible at this stage. For simplicity we use the default settings which will be far from optimal.

{% highlight r %}
m.poly <- ksvm(size ~ temp + RH + wind + rain,
          data = mydata[train, ],
          kernel = "polydot", C = 1)
{% endhighlight %}

{% highlight text %}
##  Setting default kernel parameters
{% endhighlight %}

{% highlight r %}
m.poly
{% endhighlight %}

{% highlight text %}
## Support Vector Machine object of class "ksvm"
##
## SV type: C-svc  (classification)
##  parameter : cost C = 1
##
## Polynomial kernel function.
##  Hyperparameters : degree =  1  scale =  1  offset =  1
##
## Number of Support Vectors : 253
##
## Objective Function Value : -233.2554
## Training error : 0.29
{% endhighlight %}

{% highlight r %}
m.rad <- ksvm(size ~ temp + RH + wind + rain,
          data = mydata[train, ],
          kernel = "rbfdot", C = 1)
m.rad
{% endhighlight %}

{% highlight text %}
## Support Vector Machine object of class "ksvm"
##
## SV type: C-svc  (classification)
##  parameter : cost C = 1
##
## Gaussian Radial Basis kernel function.
##  Hyperparameter : sigma =  0.707154731369717
##
## Number of Support Vectors : 277
##
## Objective Function Value : -221.0374
## Training error : 0.265
{% endhighlight %}

{% highlight r %}
m.tan <- ksvm(size ~ temp + RH + wind + rain,
          data = mydata[train, ],
          kernel = "tanhdot", C = 1)
{% endhighlight %}

{% highlight text %}
##  Setting default kernel parameters
{% endhighlight %}

{% highlight r %}
m.tan
{% endhighlight %}

{% highlight text %}
## Support Vector Machine object of class "ksvm"
##
## SV type: C-svc  (classification)
##  parameter : cost C = 1
##
## Hyperbolic Tangent kernel function.
##  Hyperparameters : scale =  1  offset =  1
##
## Number of Support Vectors : 189
##
## Objective Function Value : -1746.213
## Training error : 0.4675
{% endhighlight %}

Using the simple defaults, the radial basis non-linear mapping for the SVM appears equivalent to the polynomial, based on the lower training error; with the polynomial slightly better. We should evaulate the model performance using the `predict()` function. In order to examine how well our classifier performed we need to compare our predicted `size` of the fire with the actual size in the test dataset.

## Test with training data

{% highlight r %}
pred <- predict(m.rad, newdata = mydata[-train, ], type = "response")

table(pred, mydata[-train, "size"][[1]])  #  [[]] gives the contents of a list
{% endhighlight %}

{% highlight text %}
##
## pred    small large
##   small     1     2
##   large    33    81
{% endhighlight %}

{% highlight r %}
confusionMatrix(table(pred, mydata[-train, "size"][[1]]), positive = "small")  # from the caret package, also need e1071 package
{% endhighlight %}

{% highlight text %}
## Confusion Matrix and Statistics
##
##
## pred    small large
##   small     1     2
##   large    33    81
##
##                Accuracy : 0.7009
##                  95% CI : (0.6093, 0.782)
##     No Information Rate : 0.7094
##     P-Value [Acc > NIR] : 0.6248
##
##                   Kappa : 0.0073
##  Mcnemar's Test P-Value : 3.959e-07
##
##             Sensitivity : 0.029412
##             Specificity : 0.975904
##          Pos Pred Value : 0.333333
##          Neg Pred Value : 0.710526
##              Prevalence : 0.290598
##          Detection Rate : 0.008547
##    Detection Prevalence : 0.025641
##       Balanced Accuracy : 0.502658
##
##        'Positive' Class : small
##
{% endhighlight %}

## Conclusion
A basic introduciton to SVM in R showing the workflow. Bear in mind we have some way to go in optimising and validating this model! Changing parameters is likely to improve our 70% accuracy achieved with the default settings.

## References
* Cortez, P., & Morais, A. (2007). A Data Mining Approach to Predict Forest Fires using Meteorological Data. New Trends in Artificial Intelligence, 512-523. Retrieved from http://www.dsi.uminho.pt/~pcortez/fires.pdf
* Crawley (2004). Statistics an introduction using R.
* James et al., (2014). An introduction to statistical learning with applications in R.

{% highlight r %}
sessionInfo()
{% endhighlight %}

{% highlight text %}
## R version 3.2.3 (2015-12-10)
## Platform: x86_64-w64-mingw32/x64 (64-bit)
## Running under: Windows >= 8 x64 (build 9200)
##
## locale:
## [1] LC_COLLATE=English_United Kingdom.1252
## [2] LC_CTYPE=English_United Kingdom.1252
## [3] LC_MONETARY=English_United Kingdom.1252
## [4] LC_NUMERIC=C
## [5] LC_TIME=English_United Kingdom.1252
##
## attached base packages:
## [1] stats     graphics  grDevices utils     datasets  methods   base
##
## other attached packages:
##  [1] kernlab_0.9-23  boot_1.3-17     e1071_1.6-7     caret_6.0-64
##  [5] ggplot2_2.0.0   lattice_0.20-33 ROCR_1.0-7      gplots_2.17.0
##  [9] dplyr_0.4.3     testthat_0.11.0 knitr_1.12
##
## loaded via a namespace (and not attached):
##  [1] Rcpp_0.12.3        nloptr_1.0.4       formatR_1.2.1
##  [4] plyr_1.8.3         class_7.3-14       bitops_1.0-6
##  [7] iterators_1.0.8    tools_3.2.3        lme4_1.1-10
## [10] digest_0.6.9       evaluate_0.8       memoise_0.2.1
## [13] gtable_0.1.2       nlme_3.1-122       mgcv_1.8-9
## [16] Matrix_1.2-3       foreach_1.4.3      DBI_0.3.1
## [19] yaml_2.1.13        parallel_3.2.3     SparseM_1.7
## [22] stringr_1.0.0      MatrixModels_0.4-1 gtools_3.5.0
## [25] caTools_1.17.1     stats4_3.2.3       nnet_7.3-11
## [28] grid_3.2.3         R6_2.1.1           rmarkdown_0.9.2
## [31] minqa_1.2.4        gdata_2.17.0       reshape2_1.4.1
## [34] car_2.1-1          magrittr_1.5       splines_3.2.3
## [37] scales_0.3.0       codetools_0.2-14   htmltools_0.3
## [40] MASS_7.3-45        pbkrtest_0.4-4     rsconnect_<IP_ADDRESS>
## [43] assertthat_0.1     colorspace_1.2-6   quantreg_5.19
## [46] KernSmooth_2.23-15 stringi_1.0-1      lazyeval_0.1.10
## [49] munsell_0.4.2      crayon_1.3.1
{% endhighlight %}

license: MIT

branch_name: refs/heads/master

extension: md

gha_language: JavaScript

gha_license_id: MIT

license_type: permissive


text:
# 2021-06-09 WG Release Meeting

topic: Salt Release Coordination Community Meeting
date: 2021-06-09
time: 17:00 CEST (UTC+2)
where: zoom online meeting, hosted by VMware

# Attendees (8x)

* Bengamin Drung (Debian DD Salt packager)
* Fede Grau (Debian community member Salt team) @donfede
*  Alexander Graul (SUSE)
* Patrick McLean (Gentoo)
* Sage Robins (VMware Salt) @sagetherage
* Pablo Suárez Hernández (SUSE; led the meeting) @meaksh
* Randy Thompson (GoDaddy; salt/Tiamat)
* Victor Zhestkov @vzhestkov

# Agenda
 - walkthrough of how doing releases of Salt at SUSE
 - goals to do the same with other distros, aiming to learn and improve
 - maybe Tiamat review

# Notes
 - (PSH) reviewed agenda
    [see slide 02;
        https://github.com/saltstack/community/projects/60
        https://github.com/saltstack/community/issues/143 ]
 - (AG screenshare) walkthrough of SUSE Salt release process
    [see slide 03;
        https://github.com/openSUSE/salt/wiki#opensuse-salt-packaging ]
    - SUSE supports multiple distributions, including openSUSE and SUSE Linux Enterprise
    - use "OBS" (Open Build Service; [not Open Broadcast Software]) to build
    - new Salt releases amounts to creating new branch on openSUSE
    [see slide 04;
        https://github.com/openSUSE/salt-packaging/tree/3000/salt ]
    - helper tool generates patches, in a different repo (Git on github)
    - SUSE uses upstream tarball as is, with patches on top
    - Git commit messages, often a single line, are used to autogenerate Changelog
    - OBS can build containers and OS images
    [see slide 05:
        https://build.opensuse.org/project/show/systemsmanagement:saltstack:products ]
    - due to "political reasons", SUSE does not change the version number
    - RPM spec file quick review
    - "MU branches are complicated" [seem ok to ignore initially]
    - OBS follows a similar process to Git with "branches"
    - OBS uses a "service" file
    [see slide 06]
    - OBS also builds for different distributions, including CentOS, Fedora, Ubuntu
    - "nothing from pip is used directly; only SUSE's own validated RPMs"

 - Q/A for walkthrough of SUSE Salt release process
    - BD Q - "version number review"
        "upstream version-release.rebuild"

    - FG Q - "do you package full Salt or just minion client for other distros,
      and why? are Windows builds included?"
        [answered in part by OBS screenshare; full Salt is built if possible]
        "SUSE builds various Salt packages for another software product they
        support 'uyuni' (spacewalk successor)
        [ https://www.uyuni-project.org/ ]
        "no current support for Windows"

    - FG Q - "are repos accessed only by SUSE employees, or also community?"
        "SUSE uses open development model hosted on github, and are open to
        community contributions; though few are received"
        "in OBS members have 'submit' and 'review' process, much like Git and github"
     [see slide 07
        https://build.opensuse.org/package/requests/systemsmanagement:saltstack:products:testing/salt ]

 - (17:30) (Randy) impromptu review of "tiamat"
    [ ? https://gitlab.com/saltstack/pop/tiamat ]
    - overview "pop wrapper to pi-installer"; helps build any codebase
    - pulls in all deps via requriments, source package
    - also includes shared libraries (optional)
    - creates a dynamic binary, "staticx"
    [ ? https://pypi.org/project/staticx/ ]
    - still in beta; systemd bug starting
    - tiamat is used at GoDadddy
    - BD Q - purpose?
        "easier deployment of Salt, via a single binary for master, minion"
        "lower entry to deploy code"
    - unclear if a Salt Project priority, but GoDaddy is using it
    - shared library security patches can optionally be used
    - pip security updates, "pip install within binary"
    - RT has some ideas to support SUSE model of using RPMs instead of pip
    - regular tiamat contributors include "Pedro, RT, and ?'karl'"

 - (17:45) Open Table
   - BD "patches" and getting all patches upstream
     - Debian has ~15-20 currently; SUSE has hundreds
     - ideally upstream patches have open MR/PR
     - AG "SUSE tries to present patches upstream" "some patches are SUSE specific"
     - PSH "SUSE procedures require upstream PR with patches"
   - PSH review next meeting action items [see below]
     - check if there is interest in OBS quick intro?
   - next meeting in 1 month [FIXME: actual date]

# Action Items
 - ?Debian (or Gentoo) prepare presentation of Salt release flow
   - (FG) could be open to drafting some slides for Debian Salt Team review

 - (17:56) close call

repository: saltstack/community

repo_name: saltstack/community


text:
## Description

<!-- Describe technically what your patch does. -->

<!-- Why is this change required? What problem does it solve? -->

<!-- Why is this patch will make a better world? -->

<!-- How does this look? Add a screenshot if you can -->

<!-- Annotate your PR with label proper labels (architecture impacted, type of improvement,
etc.) ->

## Checklist

<!-- N.B.: Your patch won't be reviewed unless fulfilling the following base requirements: -->
<!--- Put an `x` in all the boxes that are complete, or that don't apply -->
-  [ ] My code follows the code style of this project.
-  [ ] My change includes a change to the documentation, if required.
-  [ ] If my change adds new code, [adequate tests](docs/testing.md) have been added.
-  [ ] I have read and agree to the **CONTRIBUTING** document.

repository: hugsy/gef

branch_name: refs/heads/main

gha_language: Python

repo_name: hugsy/gef


text:
Plant Nursery Module
====================

This module is a simple usecase to present the Odoo framework during the
Odoodays 2019.

See the [commit history](https://github.com/tivisse/odoodays-2019/commits/master/)
to follow the evolution of the module.

See the full presentation at InsertLink


text:
### [CVE-2022-41800](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-41800)
![](https://img.shields.io/static/v1?label=Product&message=BIG-IP&color=blue)
![](https://img.shields.io/static/v1?label=Version&message=%3D%2017.0.x%20&color=brighgreen)
![](https://img.shields.io/static/v1?label=Vulnerability&message=CWE-77%20Improper%20Neutralization%20of%20Special%20Elements%20used%20in%20a%20Command%20('Command%20Injection')&color=brighgreen)

### Description

In all versions of BIG-IP, when running in Appliance mode, an authenticated user assigned the Administrator role may be able to bypass Appliance mode restrictions, utilizing an undisclosed iControl REST endpoint. A successful exploit can allow the attacker to cross a security boundary. Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated.

### POC

#### Reference
No PoCs from references.

#### Github
- https://github.com/ARPSyndicate/cvemon
- https://github.com/f0cus77/awesome-iot-security-resource
- https://github.com/f1tao/awesome-iot-security-resource
- https://github.com/fardeen-ahmed/Bug-bounty-Writeups
- https://github.com/j-baines/tippa-my-tongue

repository: trickest/cve

gha_language: HTML

repo_name: trickest/cve


text:
# Code Quiz
This application is a timed multiple-choice code quiz designed to test basic JavaScript knowledge.

To begin the quiz, click the "Start Quiz" button. A multiple choice question will appear. Click the correct answer. If the incorrect answer is clicked, then 10 seconds is subtracted from the game timer.

When all the questions have been answered or when the game timer is 0, the user will be asked to enter their initials.

  * High scores are stored and can be viewed by clicking the "View High Scores" button.
  * High scores can be cleared by clicking the "Clear High Scores" button.
  * The quiz can be played again by clicking the "Go Back" button.

# Link to Application
https://jasminekay505.github.io/Code-Quiz/

# Technologies Used
  * HTML
  * CSS (Bootstrap)
  * JavaScript
  * WebAPIs

# Screenshots of Application
![image](https://user-images.githubusercontent.com/74380703/105537722-31385000-5ca7-11eb-8efe-17e48061d061.png)
![image](https://user-images.githubusercontent.com/74380703/108395441-a164c380-71ca-11eb-93ba-5fcb3b8e0da1.png)
![image](https://user-images.githubusercontent.com/74380703/108395504-b3defd00-71ca-11eb-81f5-5acdaaf2884b.png)
![image](https://user-images.githubusercontent.com/74380703/108395539-be999200-71ca-11eb-8795-74cf04bddfb9.png)

# License
MIT

# Author Contact Info
<EMAIL_ADDRESS>


text:
# Poppy Rails

[![Gem Version](https://badge.fury.io/rb/poppy-rails.svg)](http://rubygems.org/gems/poppy)
[![Build Status](https://travis-ci.org/damienadermann/poppy-rails.svg?branch=master)](http://travis-ci.org/damienadermann/poppy-rails)
[![Code Climate](https://codeclimate.com/github/damienadermann/poppy-rails/badges/gpa.svg)](https://codeclimate.com/github/damienadermann/poppy-rails)

A simple and flexible enumeration implementation for ActiveRecord using [poppy](https://github.com/damienadermann/poppy).

## Description

Inspired by [enumerate_it](https://github.com/cassiomarques/enumerate_it), Poppy is a simple implementation of enumerations with minimal goodies. Poppy offers a few nice features:

- Enumeration values are objects and can respond to any defined methods
- Works with postreSQL arrays with validations
- Simple

## Installation

Add this line to your application's Gemfile:

```ruby
gem 'poppy-rails'
```

And then execute:

    $ bundle

Or install it yourself as:

    $ gem install poppy-rails

**optional**

Add an initializer that calls

```ruby
ActiveRecord::Base.include(Poppy::ActiveRecord)
```

this can be omitted by manually including the adapter in each model that uses Poppy

```ruby
class Sandwhich < ActiveRecord::Base
  include Poppy::ActiveRecord

  enumeration :bread, of: Bread
  #...
end
```

## Usage

### Enumeration

```ruby
#app/enumerations/bread.rb
class Bread < Poppy::Enum
  values :white, :multigrain, :gluten_free
end

```

### Model
```ruby
class Sandwhich < ActiveRecord::Base
  enumeration :bread, of: Bread
end
```
Adding an enumeration to an active_record model will add an inclusion validation. There is no support for nullable enumerations. This is an intended design decision. If you would like this functionality you will need to add a null value
E.g. ` Bread::None `

### Migrations

Just regular rails migrations, however the because enumerations are objects we can't just persist the enumeration value directly. We need to convert it to the appropriate database value using the EnumType class

```ruby
> Poppy::ActiveRecord::EnumType.new(enum: Bread).type_cast_for_database(Bread::WHITE)
=> :white
```

As you can see this code is rather verbose and its pretty obvious what its returning, we can just pass in the symbol associated with the enum value. (This works because there is currently only one way to persist enumerations, as a string. If integer based enumerations are implemented then the more verbose option is required).

```ruby
class AddJobKindsToJob < ActiveRecord::Migration
  def change
    add_column :sandwhiches, :bread, :string, default: :white
  end
end
```

Database persistence has been designed to use string based persistence. This gives two main advantages.
1. Its clear what value is used when looking at the database row directly.
2. Integer based enumerations require explicitly setting an integer value, which has no relation to the data itself. Integers can be implicitly assigned to an enumeration but this breaks once an enumeration is deleted or the order that they are defined is changed.

### In the wild

```ruby
> sandwhich = Sandwhich.new(bread: Bread::WHITE, cheeses: [Cheese::CHEDDAR])
> sandwhich.bread
=> Bread::WHITE
```

### HTML forms

Rails form helpers

```erb
<%= simple_form_for @bread do |f| %>
  <%= f.select :bread, Bread.collection %>
<% end %>
```

SimpleForm

```erb
<%= simple_form_for @sandwhich do |f| %>
  <%= f.input :bread, collection: Bread.collection %>
<% end %>
```

### Postgres Array Support

```ruby
#app/enuerations/cheese.rb
class Cheese < Poppy::Enum
  values :cheddar, :swiss, :mozzarella
end
```

```ruby
class Sandwhich < ActiveRecord::Base
  enumeration :cheeses, as: :array, of: Cheese
end
```

If the enumeration is an array then all values in the array must be of that enumeration. If they aren't validation will fail just like any other ActiveModel validation.

```ruby
class AddJobKindsToJob < ActiveRecord::Migration
  def change
    add_column :sandwhiches, :cheeses, :string, array: true, default: []
  end
end
```

```ruby
> sandwhich = Sandwhich.new(cheeses: [Cheese::CHEDDAR])

> sandwhich.cheeses
=> [Cheese::CHEDDAR]
```

## Development

After checking out the repo, run `bin/setup` to install dependencies. Then, run `rake spec` to run the tests. You can also run `bin/console` for an interactive prompt that will allow you to experiment.

To install this gem onto your local machine, run `bundle exec rake install`. To release a new version, update the version number in `version.rb`, and then run `bundle exec rake release`, which will create a git tag for the version, push git commits and tags, and push the `.gem` file to [rubygems.org](https://rubygems.org).

Specs depend rely on a postgres database running to test the array support.

```bash
$ createdb poppy_rails_test
```

## Contributing

Bug reports and pull requests are welcome on GitHub at https://github.com/damienadermann/poppy-rails. This project is intended to be a safe, welcoming space for collaboration, and contributors are expected to adhere to the [Contributor Covenant](contributor-covenant.org) code of conduct.

## License

The gem is available as open source under the terms of the [MIT License](http://opensource.org/licenses/MIT).

##TODO
- Add AR initializer
- Add docs

repository: damienadermann/poppy-rails

gha_language: Ruby

repo_name: damienadermann/poppy-rails


text:
# ServerCloud
University project for Distributed Systems

## What is it?
Provides a server allocation service in the cloud and cost accounting for users, such as Google Cloud and Amazon EC2.

## Built With
* [Maven](https://maven.apache.org/) - Dependency Management

## Contributors
Made by:

[Ana Ribeiro](https://github.com/anaribeiro142)

[Jéssica Lemos](https://github.com/jessicalemos)

[Filipa Pereira](https://github.com/FilipaPereira)

[Carla Cruz](https://github.com/CarlaCruz146)

repository: jessicalemos/ServerCloud

repo_name: jessicalemos/ServerCloud


text:
# wait-for-it.sh

[wait-for-it.sh](https://github.com/vishnubob/wait-for-it) in a image

Use this image with Drone by using this `.drone.yml`:

```yml
pipeline:
  wait-for-it:
    image: ghcr.io/alexislefebvre/alpine-wait-for-it
    commands:
      - mysql:3306 --timeout=60
```

repository: alexislefebvre/docker-images

gha_language: Dockerfile

repo_name: alexislefebvre/docker-images


text:
# HWI bridge

A small web interface to communicate to your hardware wallets.

Run `server.py` from `src/` folder to start the server.

Run `gui.py` to spawn a window (Chrome required?).

repository: stepansnigirev/hwibridge

repo_name: stepansnigirev/hwibridge


text:
myproducts
==========

Grease/Tampermonkey script which makes some minor enhancements for the new My Products interface.

1. Uses full width of browser.
2. Shows full product name/sku (as long as there is room)
3. Changes "50" to "100" in products per page

Install
=======
Ensure you have the Greasemonkey or Tampermonkey extension installed in your browser.

Then just click the link below and it should prompt you to install the script.

https://github.com/sleemanj/myproducts/raw/master/myproducts.user.js

repository: sleemanj/myproducts

repo_name: sleemanj/myproducts


text:
[![Build Status](https://travis-ci.org/straightdave/arion.svg?branch=master)](https://travis-ci.org/straightdave/arion)

Arion is a gRPC tool to:
- get service / endpoint / data-entity information
- debug endpoints
- do the performance test against endpoints

## Get Arion
```bash
$ go get -u github.com/straightdave/arion
```

## Usage of Arion
```bash
$ ./arion -h
Usage of ./arion:
  -c  to clear temp folder after Postgal is generated
      *NOTE*: use -o to generate Postgal out of temp folder
  -cross string
      Cross-platform building flags. e.g 'GOOS=linux GOARCH=amd64'
  -l  list Postgals in current folder or all ./temp* folders
  -o string
      output executable binary file
  -src string
      source pb.go file
  -u  update dependencies when building Postgal
  -verbose
      print verbose information when building postgals
```

## Use Arion to generate PostGal
```bash
$ ./arion -src <your.any.pb.go> -u
2018/05/24 22:52:46 generating new pb file: temp342770882/pb.go
2018/05/24 22:52:46 generating meta source file: temp342770882/meta.go
2018/05/24 22:52:46 creating new source file: temp342770882/main.go
2018/05/24 22:52:46 creating new source file: temp342770882/static.go
2018/05/24 22:52:46 change dir to ./temp342770882
2018/05/24 22:52:46 force-update all dependencies...
2018/05/24 22:52:49 change dir back to ...
2018/05/24 22:52:49 SUCCESS
```

> Using `-u` to force-update local dependencies. It's required (once) if some underlying packages are not up-to-date.

Then by default Arion will generate a temporary folder containing source files and compile those files into an executable binary called *Postgal*. You can use `-o` to specify other path/name for this executable file. Also you can use `-c` to clear temp folder after *Postgal* is generated.

*NOTE*
When using Arion, your machine should have internet access if you don't have packages listed below. Arion will `go get` some official gRPC related packages including:
* github.com/golang/protobuf/jsonpb
* golang.org/x/net/context
* google.golang.org/grpc

Besides, some packages provide code analyzing and performance testing:
* github.com/straightdave/lesphina
* github.com/straightdave/trunks
>If you find strange panic when using Arion or Postgals, you can manually update those packages by `go get -u -f <package>` and re-generate Postgals to see if this can solve the problems or not.

### Cross-build
If you want Arion to build a postgal working on another platform (e.g linux/amd64), you can use `-cross` flag:
```
$ ./arion -src <your.any.pb.go> -cross 'GOOS=linux GOARCH=amd64'
```
> CAUTION:
> - There are only several valid pairs like linux/amd64, etc.
> - Experimental. Sometimes it fails :smile:. In that case, you can go to source code folder and do the cross-build yourself.

## List *Postgals*
```bash
$ ./arion -l
[-] ./postgal-xxx
Service:  Myapp
Generated:  Wed Jun 20 23:40:59 CST 2018
Checksum: 5de493383a0ec6ad79a7a655ae8aecbf

[-] temp080184789/postgal
Service:  Myapp
Generated:  Wed Jun 20 23:40:39 CST 2018
Checksum: 5de493383a0ec6ad79a7a655ae8aecbf

[-] temp252099608/postgal
Service:  Myapp
Generated:  Wed Jun 20 23:40:51 CST 2018
Checksum: 5de493383a0ec6ad79a7a655ae8aecbf

```
> At the moment Arion looks for Postgals in current and all `./temp*` folders

## Use PostGal

```
Usage of ./postgal:
  -at string
      address to host PostGal in browser mode (default ":9999")
  -d string
      request data
  -debug
      print some debug info (for dev purpose)
  -df string
      request data file
      Data in the file will be read line by line
  -dumpto string
      dump massive call responses to file
  -duration duration
      execution duration like 10s, 20m (default 10s)
  -e string
      endpoint name (<svc_name>#<end_name> or just <end_name>) to execute
  -h string
      hosts of target service (commas to seperate multiple hosts) (default ":8087")
  -i  show info
  -json
      response in JSON format
  -loop
      repeat all requests in loops
  -rate uint
      execution frequency per second (default 1)
  -serve
      use PostGal in browser mode
  -t string
      data type name
  -v  print version info
  -worker uint
      workers (concurrent goroutines) (default 10)
  -x  massive call endpoint (needs -rate and -duration)
```

`TL;DR`: please read some examples below.

### Console Mode
In console mode, PostGal can list simple endpoints of gRPC services defined in your pb.go file.
You can use `-i` simply to see whether your PostGal is ok or not:
```bash
$ ./postgal -i
Myapp
> Hello
```

To see some details about one endpoint:
```bash
$ ./postgal -i -e Hello
Myapp#Hello
- Request entity:
--- Name string (json field name: Name)
- Response entity:
--- Message string (json field name: Message)
```

To see some details about one entity structure:
```bash
$ ./postgal -i -t HelloRequest
- Name string (json field name: Name)
```

Also you can call one endpoint:
```bash
$ ./postgal -e Hello -d '{"Name": "Dave"}'
Message: Hello Dave
```
> **NOTE**
> - If `-h` option is not specified, postgal uses '<IP_ADDRESS>:8087' by default.
> - You can compose the JSON request data based on the knowledge you get by using `-i -t` or `-i -e`
>If the type of request object is `protobuf.Empty`, the data given by `-d` option would be ignored

Using `-json` to have JSON format output:
```bash
$ ./postgal -e Hello -d '{"Name": "Dave"}' -json
{
    "Message": "Hello Dave"
}
```

### Performance test with Postgal

To execute performance tests against one endpoint:
```bash
$ ./postgal -e Hello -d '{"Name": "Dave"}' -x
Massive Call...
... (report)
```
> **NOTE**
> * Again, if omit `-h` option, the default target host is `<IP_ADDRESS>:8087`
> * When `-x` is specified, it also implies `-rate 1 -duration 10s` by default

You can use `-df` to specify a data file which consists of multiple request data to conduct the massive call:
```bash
$ ./postgal -e Hello -df ./myreqs.txt -x -rate 10 -duration 30s -loop
```

>If you don't use the option `-loop` when using a data file, the massive call will stop after all requests are sent once.

To specify number of workers (maximum concurrent goroutines; default is 10) in performance testing:
```bash
$ ./postgal -e Hello -d '{"Name":"dave"}' -x -rate 10 -duration 30s -worker 16
```

You can specify a list of IP addresses to execute preformance test against a cluster.
In this case, `postgal` would send requests to those hosts in a simple round-robin way.

```bash
$ ./postgal -h <address>,<address> -e <endpoint> -d 'test data' -x
```

To dump responses to a file:
```bash
$ ./postgal -e Hello -d '{"Name":"daveeeeee"}' -x -dumpto responses.dump
```
So `postgal` would serialize successful responses into _json_ and write them to the file, line by line.

#### auto-generated value
Currently Postgal supports generating unique values when doing the performance test:
```bash
$ ./postgal -e Hello -d '{"Name":"Ultraman-<<arion:unique:string>>"}' -x -rate 5 -duration 10s
```
It will generate requests like:
```
{"Name":"Ultraman-0"}
{"Name":"Ultraman-1"}
...
{"Name":"Ultraman-49"}
```
> __NOTE__ for now it's an experimental feature and being improved

### Browser Mode
Browser mode is the graphic way to use Postgals. You can use is just like Postman.

```bash
$ ./postgal -serve
```
Then you can open browser (by default PostGal hosts on port 9999)

In the PostGal web page, you can easily:
1. see detailed information about endpoints and definitions about each request/response
2. call endpoints
3. change endpoint locations (gRPC server, IP:port)

You can use this page to play with gRPC services as you do the similar thing against HTTP with Postman.

## Development

### build
```bash
> go run ./_build/build.go
```
or
```bash
> ./build.sh
```

### start dev server

```bash
> ./dev.sh
```

>The developing web server will serve all static files in `web/` folder.
This is helpful for developing web pages before compiling them into binary.

## License

MIT © [Dave Wu](https://github.com/straightdave)

repository: golint-fixer/arion

repo_name: golint-fixer/arion


text:
# gt

[![lifecycle](https://img.shields.io/badge/lifecycle-maturing-blue.svg)](https://www.tidyverse.org/lifecycle/#maturing)
[![CRAN
status](https://www.r-pkg.org/badges/version/gt)](https://cran.r-project.org/package=gt)
[![Travis build
status](https://travis-ci.com/rstudio/gt.svg?token=P7T9dzi5RLEq9j2Yepx5&branch=master)](https://travis-ci.com/rstudio/gt)
[![AppVeyor Build
Status](https://ci.appveyor.com/api/projects/status/github/rstudio/gt?branch=master&svg=true)](https://ci.appveyor.com/project/rstudio/gt)
[![Coverage
status](https://codecov.io/gh/rstudio/gt/branch/master/graph/badge.svg)](https://codecov.io/github/rstudio/gt?branch=master)

With the **gt** package, anyone can make wonderful-looking tables using
the **R** programming language. The **gt** philosophy: we can construct
a wide variety of useful tables with a cohesive set of table parts.
These include the *table header*, the *stub*, the *column labels* and
*spanner column labels*, the *table body*, and the *table footer*.

It all begins with preprocessed **table data** (be it a tibble or a data
frame). You then decide how to compose your **gt table** with the
elements and formatting you need for the task at hand. Finally, the
table is rendered by printing it at the console, including it in an R
Markdown document, or exporting to a file using `gtsave()`. Currently,
**gt** supports **HTML** output, with **LaTeX** and **RTF** planned for
the future.

The **gt** package is designed to be both straightforward yet powerful.
The emphasis is on simple functions for the everyday display table
needs. Here is a brief example of how to use **gt** to create a table
from the included `sp500` dataset:

``` r
library(gt)
library(tidyverse)
library(glue)

# Define the start and end dates for the data range
start_date <- "2010-06-07"
end_date <- "2010-06-14"

# Create a gt table based on preprocessed
# `sp500` table data
sp500 %>%
  dplyr::filter(date >= start_date & date <= end_date) %>%
  dplyr::select(-adj_close) %>%
  gt() %>%
  tab_header(
    title = "S&P 500",
    subtitle = glue::glue("{start_date} to {end_date}")
  ) %>%
  fmt_date(
    columns = vars(date),
    date_style = 3
  ) %>%
  fmt_currency(
    columns = vars(open, high, low, close),
    currency = "USD"
  ) %>%
  fmt_number(
    columns = vars(volume),
    suffixing = TRUE
  )
```

There are six datasets included in **gt**: `countrypops`, `sza`,
`gtcars`, `sp500`, `pizzaplace`, and `exibble`. All of them are useful
for experimenting with the package functions.

Beyond this simple example, there are many functions available in **gt**
for creating super-customized tables.

Want to try this out? Take the **gt** Test Drive on **RStudio Cloud**.
It’s full of ready-to-run examples.

You can install the development version of **gt** from **GitHub**:

``` r
remotes::install_github("rstudio/gt")
```

If you encounter a bug, have usage questions, or want to share ideas to
make this package better, feel free to file an
[issue](https://github.com/rstudio/gt/issues).

-----

-----

#### Code of Conduct

Please note that this project is released with a [Contributor Code of
Conduct](CODE_OF_CONDUCT.md).
By participating in this project you
agree to abide by its terms.

#### License

MIT © RStudio, Inc.

repository: marinamerlo/gt

gha_license_id: NOASSERTION

repo_name: marinamerlo/gt


text:
# Generate certificate and channel artifact

1. Clone repository fabric-samples check out version needed
2. Execute ./scripts/bootstrap to prepare binary file for cryptogen, cryptoconfig, cryptotxgen, etc.
3. Go to basic-network
4. Copy configtx.yaml and replace the old one
5. Copy crypto-config.yaml and replace the old one
6. Execute `./generate.yaml` - If got an error when create new `mkdir config` first

Generate file will modify follow configtx.yaml and crypto-config.yaml

```sh
#!/bin/sh
#
# Copyright IBM Corp All Rights Reserved
#
# SPDX-License-Identifier: Apache-2.0
#
export PATH=$GOPATH/src/github.com/hyperledger/fabric/build/bin:${PWD}/../bin:${PWD}:$PATH
export FABRIC_CFG_PATH=${PWD}
CHANNEL_NAME=mychannel

# remove previous crypto material and config transactions
rm -fr config/*
rm -fr crypto-config/*

# generate crypto material
cryptogen generate --config=./crypto-config.yaml
if [ "$?" -ne 0 ]; then
  echo "Failed to generate crypto material..."
  exit 1
fi

# generate genesis block for orderer
configtxgen -profile TwoOrgsOrdererGenesis -outputBlock ./config/genesis.block
if [ "$?" -ne 0 ]; then
  echo "Failed to generate orderer genesis block..."
  exit 1
fi

# generate channel configuration transaction
configtxgen -profile TwoOrgChannel -outputCreateChannelTx ./config/channel.tx -channelID $CHANNEL_NAME
if [ "$?" -ne 0 ]; then
  echo "Failed to generate channel configuration transaction..."
  exit 1
fi

# generate anchor peer transaction
configtxgen -profile TwoOrgChannel -outputAnchorPeersUpdate ./config/Org1MSPanchors.tx -channelID $CHANNEL_NAME -asOrg Org1MSP
if [ "$?" -ne 0 ]; then
  echo "Failed to generate anchor peer update for Org1MSP..."
  exit 1
fi

```

**Note**: Ensure that all file in the place. Check by see persistent volume config.
**Note2**: Do not forget to export PATH to binary file like `export PATH=$PATH:$PWD/bin`

## After make change configs

Update ca k8s file to use correct private key

## If want to change dind to hostPath

Remove dind components and change `tcp://localhost:2375` to `unix:///host/var/run/docker.sock`


text:
goNotification
==============

goNotification is a simple and lightweight jQuery plugin inspired by the design of Ghost.org notifications.

Check the complete demo and available options on the dedicated GitHub Project Page
http://tiagoitsme.github.io/goNotification

repository: jsdelivrbot/j-plugin

repo_name: jsdelivrbot/j-plugin


text:
EduSense Openpose
=================
This is a repository for the openpose component of Edusense.
## Getting Started
This instruction is for manually setting up openpose pipeline. For those who are new to Edusense, we recommend to take a look at
automated multi-container setup provided [here](/compose/README.md) or use an automated script provided [here](/scripts).

Note-:  Openpose pipeline processes the video, extracts the keypoints and sends them to the video pipeline via either local unix socket (demonstrated below, remember to use the same log directory for both openpose and video pipeline) or TCP socket

#### Build image
```
docker build .
```

You may also want to name the image like below:
```
docker build . -t <tag_name>
```
#### Running Container
Make a log directory (log_dir) and pass the path to the docker run command. Make sure, to have a video in a video directory,pass the directory path and the video name to the docker run command.
```
nvidia-docker run \
--name <unique name for container> \
--rm \
-e LOCAL_USER_ID=$(id -u) \
-v <log_dir: path of the log dir>:/tmp \
-v <video_dir: path of the video directory>:/app/video \
<image name for the container/tag_name with which the image is built>\
--video /app/video/<videoname = name of the video> \
--num_gpu_start <GPU number to be assigned to the container>  \
--num_gpu <Number of GPU assigned to the container(preferred 1)> \
--use_unix_socket \
--unix_socket /tmp/unix.front.sock \
--display 0 \
--render_pose 0 \
--raw_image \
--process_real_time \
```
Note-: For real-time processing, pass the RTSP URL to ip_camera argument

## Developer Guide

### Keeping up with OpenPose Releases

When compiling, we inject our EduSense code into OpenPose code base. OpenPose is
a library under active development; our code often fails to compile because of
code changes (e.g., API and data structure) in newer versions of OpenPose. We need
to update our code whenever we integrate newer OpenPose into EduSense.

We release our EduSense code as patch diff files. The original source code we derive
the current patch files from is /openpose/examples/tutorial_api_cpp/16_synchronous_custom_output.cpp .
The file names of the code changes time to time, so we need to track file changes
across OpenPose versions.

To generate a diff patch file,

```
diff <original file> <new edusense file> > edusense/edusense.cpp.patch
```

Once the patch file is ready, we also need to modify Dockerfile to update the path
to the original source file. A new patch file lacks license notices, so
we need to update the patch file also.

To apply a patch to a file:

```
patch <original file> -i examples/edusense/edusense.cpp.patch -o examples/edusense/edusense.cpp
```

If a developer also wants to update CMakefile, he/she can follow the same instructions
noted above.

repository: edusense/edusense

repo_name: edusense/edusense


text:
# Parable

Parable is a programming language and collection of development tools.

## Language

This is a small language, built over a compact, byte coded virtual machine. It is concatenative, but unlike Forth it provides data types (characters, strings, numbers, pointers, comments, function calls, and flags). The syntax is much more rigidly defined with all functionality being built around reverse Polish notation and the data stack. The compiler is an integral piece of the language and all code is compiled before being executed.

It draws from Toka and Retro, making extensive use of anonymous, nestable functions (called quotations) for function definition and control structure. The language also depends heavily on prefixes to help the compiler decide how to handle tokens. (These are a lot like colors in ColorForth, but are represented as single characters rather than color or stylistic elements).

One other major difference is the memory model. Parable divides memory into distinct regions called slices. These grow and shrink as needed, and memory accesses are done by referencing a slice and an offset. Each memory cell in a slice is tagged with the data type stored in it, allowing Parable to treat code and data interchangeably. The use of slices has allowed for some interesting things, including a simple garbage collector, and much simpler decompilation back to usable source code.

## Interfaces

The core Parable language does not provide a user interface. Various interface layers are available. The following are included with the standard Parable distribution:

*Listener* provides a simple interactive terminal.

*Legend* is a full screen terminal based interface.

*Allegory* provides an interactive interpreter and support for command line scripts. It also  extends the core language with I/O functions, further system integration, and and the ability to save and restore snapshots.

*Punga* is a CGI based interface.

Additional interfaces are available separately:

*Cyanide* is a command line and CGI capable scripting environment with additional functions for file and terminal I/O as well as CGI form processing and dispatch.

*Apologue* is a development environment for iOS. It uses a CGI backend for processing code, and includes browsers for results, documentation, and a memory browser (with integral decompiler).

## License

Parable is open source under the ISC License. See the LICENSE file for full details.

license: ISC

repository: hermetique/parable

repo_name: hermetique/parable


text:
# Hasura Backend Plus

## Next release

### Bug fixes and improvements

(Add entries here in the order of: server, docs, others)

- server: Updated change password routes for concistency with change email (#235)
- docs: Added API documentation (#235)
- other: Added CHANGELOG.md file (#235)
- refactor(auth): change token endpoint from HTTP POST to GET
- ci(docs): trigger publish docs when changes are done to the examples directory
- docs(auth): login, mfa, jwt
- server: Added support for multiple default allowed user roles (#246)


text:
# DCGAN-Tensorflow
Tensorflow inplementation of a Deep Convolutional Generative Adversarial Network
## Prerequisites
Python 3
## Setup
Clone this repo with `git clone https://github.com/philipxjm/DCGAN-Tensorflow.git`

Install required packages with `pip install -r requirements.txt`

Run with `python cnn.py`


text:
##  Work Order Completion Entry (ST.E3)

<PageHeader />

**Form Details**
[ Move Instructions ](ST-E3-1/README.md)
[ Materials Used ](ST-E3-2/README.md)

**Purpose**
The ST.E3 procedure is used to enter individual work order completion
transactions from an operation in the routing to another work order or
inventory location. The operator enters the work order number and quantity
being completed, the operation the assemblies are moving from, and the
inventory location they are moving to. If they are being moved into a work in
process inventory location the operator also enters the work order number the
items are being sent to.

When the operator's entry is filed the system creates a record in the shop
transaction file (ST) which records the pertinent information about the
transaction. At the same time it updates the current balance for the from
operation in the work order routing stored in the work order record (WO) along
with the dollar value of the items completed. The inventory file (INV) is also
updated to reflect the quantity moved into the location specified unless the
target location is another work order in which case the work order inventory
file (WOINV) is updated, and material dollars added to the associated work
order record.

If the balance on hand in the from operation will go negative as a result of
processing the transaction a message will appear to warn the operator of this
situation. The operator may still proceed with the transaction if appropriate.

**Frequency of Use**
As required.

**Prerequisites**
None.

<badge text= "Version 8.10.57" vertical="middle" />

<PageFooter />

repository: zumasys/docs

repo_name: zumasys/docs


text:
			Live Blog

		  A simple, decoupled React app for live blogging in WordPress using the REST API

			A Human Made project.

This React app allows for Live Blogging on a WordPress site using the REST API.

## Requirements
Locally, this requires Node with npm.

The server you are connecting to requires the WP REST API v2 plugin to be active, and the OAuth 1.0a and Broker plugins to authenticate and use write methods.

## Installation
This repository is a static site that connects to a REST API-powered site.

To run the application, clone the repository, install dependencies with `npm install`, then run `npm start` to run a local development server. This will start the application on port 3000, so access http://localhost:3000/ to view the application.

## Contributing
Please feel free to fork and use this app on your own

## License
This app is licensed under the MIT or later.

## Credits
Created by Human Made for a Week of REST Conference.

Written by [Ryan McCue](https://github.com/rmccue) & [Joe Hoyle](https://github.com/joehoyle).

---

Interested in joining in on the fun? [Join us, and become human!](https://hmn.md/is/hiring/)

repository: humanmade/liveblog

repo_name: humanmade/liveblog


text:
# Welcome to the CurrencyConverter App!
## Basic Android App
The App involves 2 activities
* First Activity has Simple USD to INR conversion
* Second Activity has Multiple Currency Conversion like USD, GBP, CNY, EUR, INR


text:
# Authentication with Docker

Sometimes the Docker images you use live in a private Docker registry. For that reason, _Testcontainers for Go_ gives you the ability to read the Docker configuration
and retrieve the authentication for a given registry. To achieve it, _Testcontainers for Go_ will internally check, in this particular order:

1. the `DOCKER_AUTH_CONFIG` environment variable, unmarshalling the string value from its JSON representation and using it as the Docker config.
2. the `DOCKER_CONFIG` environment variable, as an alternative path to the Docker config file.
3. else it will load the default Docker config file, which lives in the user's home, e.g. `~/.docker/config.json`
4. it will use the right Docker credential helper to retrieve the authentication (user, password and base64 representation) for the given registry.

To understand how the Docker credential helpers work, please refer to the [official documentation](https://docs.docker.com/engine/reference/commandline/login/#credential-helpers).

!!! info
	_Testcontainers for Go_ uses [https://github.com/cpuguy83/dockercfg](https://github.com/cpuguy83/dockercfg) to retrieve the authentication from the credential helpers.

_Testcontainers for Go_ will automatically discover the credentials for a given Docker image from the Docker config, as described above. For that, it will extract the Docker registry from the image name, and for that registry will try to locate the authentication in the Docker config, returning an empty string if the registry is not found. As a consequence, all the fields to pass credentials to the container request will be deprecated.

```go
req := ContainerRequest{
	Image: "myregistry.com/myimage:latest",
}
```

In the case you are building an image from the Dockerfile, the authentication will be automatically retrieved from the Docker config, so you don't need to pass it explicitly:

<!--codeinclude-->
[Building From a Dockerfile does not need Auth credentials anymore](../../docker_test.go) inside_block:fromDockerfile
<!--/codeinclude-->

repository: testcontainers/testcontainers-go

gha_language: Go

repo_name: testcontainers/testcontainers-go


text:
deskbot
-------

Started as a desktop bot. I'm trying to make it as complete as spoonbot, then work from there.

**Note:** [pylast](https://github.com/pylast/pylast "pylast") needs to be installed for the last.fm command module to work. Delete `modules/command_modules/lastfm.py` if you don't want the command.

**Note 2:** In case you choose to use the last.fm command module, you'll need to make an account for your version of the bot on [last.fm](http://www.last.fm/api/account/create) to get an API key and secret. Store them in `api-keys/lastfm` in plain text. The API key should be the first line, while the API secret should be second, in the file. Example output of `more api-keys/lastfm`:

```
34hasd3498apikeyhereW00ew
oi3nosAPIsecretHeRe34sdad
```

To start the bot:
```
./deskbot.py [-P password] [-b botnick] [-a admin_nick] [-p port] [-t timeout] [--log] [--log-file filepath] server

Alternatively:
python deskbot.py [-P password] [-b botnick] [-a admin_nick] [-p port] [-t timeout] [--log] [--log-file filepath] server
```

Log files will go into the `log/` directory.

I'm using argparse for the flags. Check `python deskbot.py -h` to learn how to use them.

Default port is 6667.
Default botnick is deskbot.

**There is no default admin nickname or NickServ password.**

repository: lxcyp/deskbot

repo_name: lxcyp/deskbot


text:
Enforces that mailer names end with `Mailer` suffix.

Without the `Mailer` suffix it isn't immediately apparent what's a mailer
and which views are related to the mailer.

# Examples

```ruby
# bad
class User < ActionMailer::Base
end

class User < ApplicationMailer
end

# good
class UserMailer < ActionMailer::Base
end

class UserMailer < ApplicationMailer
end
```

[Source](http://www.rubydoc.info/gems/rubocop/RuboCop/Cop/Rails/MailerName)

repository: codacy/codacy-rubocop

repo_name: codacy/codacy-rubocop


text:
# Game Mechanics Part III - Rewards

## Leaderboard Rewards

Both incentive approaches (see part IIa and IIb) give each user a score tied to each genre (credit points for that specific genre). This results in an overall leaderboard per genre displaying the highest ranking users. To incentivize the community of doing the work, the highest ranking users will unlock special permissions or achievements.

The leaderboards could be updated once every 24 hours or in real-time.

**Possible User Rewards:**
* Able to create a new genre
>_Challenger high_
* Able to vote to change one or several governance parameters
>_Defender mid - Top 20 after minimum genre score of X_
* Able to change certain part of the artwork: add a picture or banner
>_Defender high - Top 10_
* Able to create public custom playlists
>_Defender low_
* Your personal heatmap (user data) and avatar become bumped to higher tier
>_Challenger low_
* Able to edit wiki
>_Challenger mid_
* Able to vote on the super-genre labels
>_Challenger mid_
* Able to vote on relationship links concerning the genre
>_Defender mid_

## End-2-End Scenario (based on IIb)

Alice opens the user interface of a specific genre (e.g. Psychobilly) and sees all currently listed Psychobilly songs. The songs are ranked automatically by their score which is determined by the total amount of users vouching for that song.
Alice can search for any keyword, filter the playlist by artist, title, album, or year or just scroll and swipe through it casually.
While browsing the playlist, she might notice that a certain song does not belong there, i.e. it is not Psychobilly. Alice can then press the “reject” button next to the song and confirm her choice. Now, whenever another user also agrees with Alice and votes reject, that vote will count as one credit point towards Alice’s score. So Alice stakes her belief that a song is incorrect. The more users agree, not only the higher Alice’s score will be (which in turn will grant her rewards) but also the lower the song will be ranked, until the point of complete removal from the playlist.
On the other hand, Alice can also help curate the ranking by voting “vouch” for the songs that are definitely Psychobilly. Whenever another user also votes “vouch” for the same song, Alice will gain one credit point.
The mechanics go like this: Alice will vote for whatever song she thinks will attract the most users. These will be the most well-known, quintessential songs of the genre, and therefore automatically will appear at the top based on their score. But Alice will also vote on lesser-known songs as these will have a lot more potential to gather votes than songs where almost the entire community has already cast their vote.
Obtaining a high user score thanks to lots of good (or lucky) vouching will yield Alice rewards (albeit different ones to incentivize practicing both votes).
Of course, Alice can cheat by blindly spamming vouch to gain a high score or reject to troll the list. But the game mechanics will punish such behaviour while also limiting the amount of votes per day.

## From Web 2.5 to Web 3.0

After mass adoption, the sidechain can be changed to a main net and user credits can be swapped for real tokens. Each credit point equals one token. This will change the incentive mechanics completely, because now users will have a financial motivation. This requires further investigation later.


text:
# Control Panel
Control used used for managing the whole system.

# Roles
 * Let customers create new websites from their fanpages.
 * Let managers create new websites from a fanpage link.
 * Let authorised users manage their websites:
     - Bills.
     - Domains.
     - Statistics.

# License
Apache 2.0.


text:
# utn-db

[![Latest Version on Packagist][ico-version]][link-packagist]
[![Software License][ico-license]](LICENSE.md)
[![Build Status][ico-travis]][link-travis]
[![Coverage Status][ico-scrutinizer]][link-scrutinizer]
[![Quality Score][ico-code-quality]][link-code-quality]
[![Total Downloads][ico-downloads]][link-downloads]

This is where your description should go. Try and limit it to a paragraph or two, and maybe throw in a mention of what
PSRs you support to avoid any confusion with users and contributors.

## Structure

If any of the following are applicable to your project, then the directory structure should follow industry best practices by being named the following.

```
bin/
build/
docs/
config/
src/
tests/
vendor/
```

## Install

Via Composer

``` bash
$ composer require crojasaragonez/utn-db
```

## Usage

``` php
require_once 'vendor/autoload.php';

use crojasaragonez\UtnDb\PgConnection;

$con = new PgConnection('postgres', '12345', 'pmo', 5432, 'localhost');
$con->connect();
$sql = "INSERT INTO projects(name, description, start_date, end_date) VALUES ($1, $2, $3, $4)";
$con->runStatement($sql, ['Project 1', 'project description', '2020-01-01', '2020-01-02']);

$results = $con->runQuery('SELECT * FROM projects WHERE id >= $1', [1]);

var_dump($results);

$con->disconnect();
```

## Change log

Please see [CHANGELOG](CHANGELOG.md) for more information on what has changed recently.

## Testing

``` bash
$ composer test
```

## Contributing

Please see [CONTRIBUTING](CONTRIBUTING.md) and [CODE_OF_CONDUCT](CODE_OF_CONDUCT.md) for details.

## Security

If you discover any security related issues, please email<EMAIL_ADDRESS>instead of using the issue tracker.

## Credits

- [Carlos Luis Rojas Aragonés][link-author]
- [All Contributors][link-contributors]

## License

The MIT License (MIT). Please see [License File](LICENSE.md) for more information.

[ico-version]: https://img.shields.io/packagist/v/crojasaragonez/utn-db.svg?style=flat-square
[ico-license]: https://img.shields.io/badge/license-MIT-brightgreen.svg?style=flat-square
[ico-travis]: https://img.shields.io/travis/crojasaragonez/utn-db/master.svg?style=flat-square
[ico-scrutinizer]: https://img.shields.io/scrutinizer/coverage/g/crojasaragonez/utn-db.svg?style=flat-square
[ico-code-quality]: https://img.shields.io/scrutinizer/g/crojasaragonez/utn-db.svg?style=flat-square
[ico-downloads]: https://img.shields.io/packagist/dt/crojasaragonez/utn-db.svg?style=flat-square

[link-packagist]: https://packagist.org/packages/crojasaragonez/utn-db
[link-travis]: https://travis-ci.org/crojasaragonez/utn-db
[link-scrutinizer]: https://scrutinizer-ci.com/g/crojasaragonez/utn-db/code-structure
[link-code-quality]: https://scrutinizer-ci.com/g/crojasaragonez/utn-db
[link-downloads]: https://packagist.org/packages/crojasaragonez/utn-db
[link-author]: https://github.com/crojasaragonez
[link-contributors]: ../../contributors

gha_language: PHP


text:
# DRIVERS.md

This document comprises two sections, the first for users of an existing device
driver and the second for writers of device drivers.

# User Documentation: the Writer class

This class facilitates rendering characters from Python font files to a device,
assuming the device has a driver conforming to the specification below. Typical
use is as follows:

```python
from writer import Writer
from device_driver import Display
import freeserif
import freesans20
display = Display(args_required_by_driver)
wri_serif = Writer(display, freeserif)
wri_sans = Writer(display, freesans20)
Writer.set_clip(True, True)
wri_serif.printstring('Tuesday\n')
wri_sans.printstring('8 Nov 2016\n')
wri_sans.printstring('10.30am')

display.show()  # Display the result
```

The file ``driver_test.py`` illustrates the use of font files with an SSD1306
display and a complete example of an SSD1306 driver may be found
[here](https://github.com/peterhinch/micropython-samples/tree/master/SSD1306).

## Class Methods

The ``Writer`` class exposes the following class methods:

 1. ``set_textpos`` Args: ``row``, ``col``. This determines where on screen any
 subsequent text is to be rendered. The initial value is (0, 0) - the top left
 corner. Arguments are in pixels with positive values representing down and
 right respectively. They reference the top left hand corner of the first
 character to be output.
 2. ``set_clip`` Args: boolean ``row_clip``, ``col_clip``. If these are
 ``True``, characters will be clipped if they extend beyond the boundaries of
 the physical display. If ``col_clip`` is ``False`` characters will wrap onto
 the next line. If ``row_clip`` is ``False`` the display will, where necessary,
 scroll up to ensure the line is rendered.

As class methods these settings apply to all font objects. The insertion point
of characters is maintained regardless of the font in use.

## Method

 1. ``printstring`` Arg: a text string. Outputs a text string at the current
 insertion point. Newline characters are honoured.

## Note on the Writer class

This is more a proof of concept than a final implementation. Obvious
enhancements include rendering to a rectangular area, support for proper word
wrap and support for format control characters such as tabs.

# Device Driver Implementation

Display devices comprise two varieties, depending on whether the framebuffer is
located on the controlling system or on the physical display device. In the
former case the ``Writer`` class simplifies the design of the driver. It merely
has to expose certin attributes and methods with ``Writer`` instances taking
care of text rendering. It is strongly recommended that such device drivers use
the oficial ``framebuf`` module, as per the official SSD1306 driver which
exposes the required components.

Where the buffer is located on the display device the means of controlling the
text insertion point will be device dependent. The driver will need to
implement the functionality of the ``Writer`` class itself.

## Fixed width fonts

If a Python font file is created with the ``-f`` argument, all characters will
be saved with the width of the widest. In general it is not necessary to
specify this option. The driver can perform fixed pich rendering by rendering
the character as variable pitch, then advancing the pixel column by the value
returned by ``font.max_width()``.

## Drivers with local buffers

The writer of a device driver need not be concerned with the structure of a
Python font file so long as the driver exposes certain attributes and methods
required by the ``Writer`` class. These are as follows:

Attributes:

 1. ``buffer`` The underlying ``bytearray`` instance holding the display
 buffer.
 2. ``height`` The screen height in pixels.
 3. ``width`` The screen width in pixels.

Methods:

 1. ``show`` Display the current buffer contents.
 2. ``scroll`` Arguments ``x``, ``y`` amount to scroll horizontal and vertical.
 3. ``fill`` Argument ``col`` colour 1 == fill 0 == clear.

An example of such a driver, using the official ``framebuf`` module, is the
SSD1306 driver (drivers/display/ssd1306.py in the source tree).

The driver documentation should specify the arguments for font_to_py.py to
ensure users create font files with a layout corresponding to that of the
buffer/device.

## Drivers for remote buffers

### Specifying the font file

Each font file has a ``get_ch()`` function accepting an ASCII character as its
argument. It returns a memoryview instance providing access to a bytearray
corresponding to the individual glyph. The layout of this data is determined by
the command line arguments presented to the ``font_to_py.py`` utility. It is
the responsibility of the driver to copy that data to the physical device.

The purpose of the ``font_to_py.py`` command line arguments specified to the
user is to ensure that the data layout is optimised for the device so that this
copy operation is a fast bytewise copy or SPI/I2C transfer. The driver
documentation should therefore specify these arguments to ensure the layout is
optimal. Mapping may be horizontal or vertical, and the bit order of individual
bytes may be defined. These are detailed below.

In the case of devices with their own frame buffer the ``Writer`` class will need
to be re-written or adapted to match the hardware's method of tracking such
things as the text insertion point. Consideration should be given to employing
the same interface as the ``Writer`` class to simplify the porting of user code
between displays with differing hardware.

## Python Font files

Assume the user has run the utility to produce a file ``myfont.py`` This then
has the following outline definition (in practice the bytes objects are large):

```python
 # Code generated by font-to-py.py.
 # Font: FreeSerif.ttf
version = '0.2'

def height():
    return 21

def max_width():
    return 22

def hmap():
    return False

def reverse():
    return False

def monospaced():
    return False

def min_ch():
    return 32

def max_ch():
    return 126

_font =\
b'\x06\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'\
b'\x00\x00\x00\x00\x08\x00\xfe\xc7\x00\x7e\xc0\x00\x00\x00\x00\x00'\

_index =\
b'\x00\x00\x14\x00\x2e\x00\x4b\x00\x71\x00\x97\x00\xd2\x00\x0a\x01'\
b'\x1b\x01\x35\x01\x4f\x01\x75\x01\x9e\x01\xb2\x01\xcc\x01\xe0\x01'\

_mvfont = memoryview(_font)
    # Boilerplate code omitted

def get_ch(ch):
    # validate ch, if out of range use '?'
    # get offsets into _font and retrieve char width
    # Return: memoryview of bitmap, height and width
    return mvfont[offset + 2, next_offset], height, width
```

``height`` and ``width`` are specified in bits (pixels).

In the case of monospaced fonts the ``max_width`` function returns the width of
every character. For variable pitch fonts it returns the width of the widest
character. Device drivers can use this to rapidly determine whether a string
will fit the available space. If it will fit on the assumption that all chars
are maximum width, it can be rendered rapidly without doing a character by
character check.

``get_ch()`` returns a memoryview of an individual glyph with its dimensions
and contains all the bytes required to render the character including trailing
space.

## Binary font files

These are unlikely to find application beyond the e-paper driver, but for
completeness the format is as follows. They are binary files with a four byte
header and 126 fixed length records. The header consists of two file identifiers
enabling the file format to be checked, followed by bytes specifying the width
and height. The length of each record is (width + 1) bytes.

The file indentifiers depend on the -x and -r arguments specified to ``font_to_py.py``
and are as follows:

hmap reverse byte
-x   -r      0    1
0    0       0x3f 0xe7
1    0       0x40 0xe7
0    1       0x41 0xe7
1    1       0x42 0xe7

Each record starts with a width byte specifying the x dimension of the glyph if
rendered proportionally spaced, followed by the glyph data. This data includes
trailing space ensuring that all records have the size specified in the header.

## Mapping

A character occupies a space where (0, 0) represents the coordinates of the top
left hand corner of the bitmap. It comprises a set of pixels where increasing x
values represent locations to the right of the origin and increasing y values
represent downward positions. Mapping defines the relationship between this
abstract two dimensional array of bits and the physical linear sequence of bytes.

Vertical mapping means that the LSB of first byte is pixel (0,0), MSB of first
byte is (0, 7). The second byte (assuming the height is greater than 8 pixels)
is (0, 8) to (0, 15). Once the column is complete the next byte represents
(1, 0) to (1, 7).

Horizontal mapping means that the MSB of byte 0 is pixel (0,0) with LSB at
(7,0), with the second byte covering (8, 0) to (15, 0) if the width is greater
than 8.

Bit reversal provides for the case where the bit order of each byte is reversed
i.e. a byte comprising bits [b7b6b5b4b3b2b1b0] becomes [b0b1b2b3b4b5b6b7].

# Specification and Project Notes

The design aims primarily to minimise RAM usage. Minimising the size of the
bytecode is a secondary aim. Indexed addressing is used to reduce this in
the case of proportional fonts, at a small cost in performance. The size of the
Python source file is a lesser consideration, with readability being prioritised
over size. Hence they are "pretty formatted" with the large bytes objects
split over multiple lines for readability.

The approach has been tested on SSD1306 devices using both the pseudo-horizontal
and true vertical mapping.

The ``font_to_py`` utility has been extensively tested with each of the mapping
options. It has been used with drivers for SSD1306 OLEDs, SSD1963 LCD displays,
and the e-paper display.

repository: briancappello/micropython-font-to-py

repo_name: briancappello/micropython-font-to-py


text:
---
code: true
type: page
title: scan | API | Core
---

# scan

Iterates incrementally over the set of keys in the database using a cursor.

An iteration starts when the cursor is set to 0.
To get the next page of results, simply re-send the request with the updated cursor position provided in the result set.

The scan ends when the cursor returned by the server is 0.

[[_Redis documentation_]](https://redis.io/commands/scan)

---

## Query Syntax

### HTTP

```http
URL: http://kuzzle:7512/ms/_scan?cursor=<cursor>[&match=<pattern>][&count=<count>]
Method: GET
```

### Other protocols

```js
{
  "controller": "ms",
  "action": "scan",
  "cursor": 0,
  // optional
  "match": "foo*bar",
  "count": 20
}
```

---

## Arguments

- `cursor`: cursor offset (set it to `0` to start a new scan)

### Optional:

- `count`: return an _approximate_ number of items per result set (the default is 10)
- `match`: search only keys matching the provided pattern

---

## Response

Returns an array containing the following two elements:

- a new cursor position, to be used to get the next page of results (or `0` when at the end of the cursor)
- an array of found keys

### Example

```js
{
  "requestId": "<unique request identifier>",
  "status": 200,
  "error": null,
  "controller": "ms",
  "action": "hscan",
  "collection": null,
  "index": null,
  "result": [
    13,
    [
      "key1",
      "key2",
      "..."
    ]
  ]
}
```

repository: kuzzleio/kuzzle

repo_name: kuzzleio/kuzzle


text:
# HTML Pages for tests

This pages come from php-webdriver functionnal tests.

[You can see them here](https://github.com/php-webdriver/php-webdriver/tree/main/tests/functional/web)

repository: JuGid/AutoMate

repo_name: JuGid/AutoMate


text:
# Protein Atlas Screen Saver
Shows immunofluorescence confocal microscopy images from [Human Protein Atlas project](https://www.proteinatlas.org)

## Features
* Whole content of HPAv18 atlas database
* Multi-monitor support
* Offline work (uses previously cached images)

## Installation
Follow [wiki page](https://github.com/dgrechka/ProteinAtlasScreenSaver/wiki/Home#Installation)

## Demo preview
![ScreenSaver screen shot](https://dgrechka.github.io/ProteinAtlasScreenSaver/Hpa_screensaver_demo.png)

repository: dgrechka/ProteinAtlasScreenSaver

repo_name: dgrechka/ProteinAtlasScreenSaver


text:
# XBOS(2)

- [Issues](https://todo.sr.ht/%7Egabe/xbos)
- [Docs](https://man.sr.ht/%7Egabe/xbos/)

## Ingester

Requirements:
1. go: https://golang.org/doc/install
2. bzr
    ```
    sudo apt-get install bzr
    ```

How do get started:

1. Install [BtrDB dev machine](https://docs.smartgrid.store/development-environment.html) OR [InfluxDB](https://docs.influxdata.com/influxdb/v1.7/introduction/)
2. Install [WAVEMQ](https://github.com/immesys/wavemq):
    - can use ansible:
    1. [Install ansible](https://docs.ansible.com/ansible/2.7/installation_guide/intro_installation.html#installing-the-control-machine)
    2. Clone this repo
    3. Go to `ansible/`
    4. Run the playbook:
        ```
        ansible-playbook -K wavemq-playbook.yml
        ```
3. Create entity (docs coming)
    - read [wave docs](https://github.com/immesys/wave) for now
4. Give perms
    - read [wave docs](https://github.com/immesys/wave) for now
5. Build and run ingester:
    ```
    cd ingester
    make run
    ```

repository: akshephard/xboswave

repo_name: akshephard/xboswave