text:
# ssb-ebt

Adapter for [epidemic-broadcast-trees](https://github.com/dominictarr/epidemic-broadcast-trees)
to [secure-scuttlebutt](http://scuttlebutt.nz/)

## testing/debugging

There are several scripts in `./debug` which I used for testing
ebt replicaiton.

use `./debug/remote.js <address>` to connect to an sbot running
ebt and replicate. Running this won't store anything locally,
it will just download everything drop it on the floor. This
is used to test performance of ebt on a server.

I normally see values between 2k and 3k messages per second,
that replicates 100k messages in under a minute.

## api

### ebt.block (from, to, blocking)

blocks a peer and disallows them from connecting.
They are also removed from peers, so there is no connecting to them.
Also disallows peers to pass on data to them.

### ebt.replicate (opts)

creates a duplex replication stream to the remote peer.
when two peers connect, the peer who initiated the call
(the client) should call this. It is not intended to
be called by the user.

### ebt.request (feedId, toReplicate)

request that `feedId` be replicated. `toReplicate` is
a boolean, replicate feed if true. If set to false,
replication is immediately stopped.

### ebt.peerStatus (id, cb)

query the status of replication for a given feed id.
returns a small data structure showing the replication
state for all peers we are currently connected to.

output looks like this:
``` js
{
  "id"<EMAIL_ADDRESS>  "seq": 13293, //the sequence we have locally.
  "peers": {
    //where each of these peers are up to:
<EMAIL_ADDRESS>{
      "seq": 13293, //the sequence this peer has acknowledged, we definitely know they have this number.
      "replicating": {
        "tx": true,
        "rx": true,
        "sent": 13293, //the sequence we have sent to this peer. They _probably_ have this, but not gauranteed.
        "requested": 13293 //the sequence we requested from this peer
      }
    },
<EMAIL_ADDRESS>{
      "seq": 13293,
      "replicating": {
        "tx": true,
        "rx": false,
        "sent": 13293,
        "requested": 13293
      }
    }
  }
}
```

## License

MIT

repository: jedahan/ssb-ebt

repo_name: jedahan/ssb-ebt


text:
What is DecNet?
---------------

DecNet is a decentralized social network.

License
-------

DecNet is released under the MIT license. See [COPYING](COPYING) for more information.

Development Process
-------------------

The `master` branch is main branch. Tags are created to indicate new official release.

TODO Contribution

TODO mailing list

Developer IRC can be found on Freenode at `#rikarin`

license: MIT

repository: pedroalvesbatista/DecNet

branch_name: refs/heads/master

extension: md

license_type: permissive

repo_name: pedroalvesbatista/DecNet


text:
[![build status][travis-image]][travis-url]

JavaScript Algorithms & Data Structures
========================================

This is a collection of algorithms and data structures implemented in JavaScript. The code isn't overly-optimized but is written to be correct and readable. The algorithms and data structures are well tested and, unless noted, are believe to be 100% correct.

# What's been implemented

## Data Structures
* Binary Search Tree
* Linked List

## Searching
* Binary Search

## Sorting
* Bubble Sort
* Insertion Sort
* Merge Sort
* Odd-even Sort
* Quick Sort
* Selection Sort

## Mathematics
* Combinatorics
    + Permutations
    + Variations
* Primes
    + Is Prime
    + Sieve of Eratosthenes
    + Sieve of Sundaram
    + Sieve of Atkin
* Numbers
    + Greatest Common Divisor
        - Euclid's algorithm
	+ Lowest Common Multiple
	+ Factorial

[travis-image]: https://img.shields.io/travis/svil4ok/javascript-algorithms/master.svg?style=flat-square
[travis-url]: https://travis-ci.org/svil4ok/javascript-algorithms

repository: sgpopov/javascript-algorithms

repo_name: sgpopov/javascript-algorithms


text:
Karma is essentially a tool which spawns a web server that executes source code against test code for each of the browsers connected.
The results of each test against each browser are examined and displayed via the command line to the developer
such that they can see which browsers and tests passed or failed.

A browser can be captured either
- manually, by visiting the URL where the Karma server is listening (typically `http://localhost:9876/`),
- or automatically by letting Karma know which browsers to start when Karma is run (see [browsers]).

Karma also watches all the files, specified within the configuration file, and whenever any file changes, it triggers the test run by
sending a signal to the testing server to inform all of the captured browsers to run the test code again.
Each browser then loads the source files inside an IFrame, executes the tests and reports the results back to the server.

The server collects the results from all of the captured browsers and presents them to the developer.

This is only a very brief overview, as the internals of how Karma works aren't entirely necessary when using Karma.

## Outline of workflow.

Here is roughly how Karma works:

After starting up, Karma loads plugins and the configuration file, then starts its local web server which listens for connections.
Any browser already waiting on websockets from the server will reconnect immediately. As part of loading the plugins, test reporters
register for 'browser' events so they are ready for test results.

Then karma launches zero, one, or more browsers, setting their start page the Karma server URL.

When the browsers connect, Karma serves a 'client.html' page; when this page runs in the browser it connects back to the server via websockets.

Once the server sees the websocket connection, it instructs the client -- over the websocket -- to execute tests.  The client page opens an iframe with a 'context.html' page from the server. The server generates this context.html page using the configuration. This page includes the test framework adapter, the code to be tested, and the test code.

When the browser loads this context page, the onload event handler connects the context page to the client page via postMessage. The framework adapter is in charge at this point: it runs the test, reporting errors or success by messaging through the client page.

Messages sent to the client page are forwarded through the websocket to the Karma server. The server re-dispatches these messages as 'browser' events.  The reporters listening to 'browser' events get the data; they may print it, save it to files, or forward the data to another service.
Since the data is sent by the test framework adapter to the reporter, adapters and reporters almost always come in pairs, like karma-jasmine and karma-jasmine-reporter.  The detailed content of test-result data is of no concern to other parts of karma: only the reporter needs to know its format.

Karma has many variations and options that may cause different workflow with different configurations.

If you are interested in learning more about the design, Karma itself originates from a university thesis, which goes into detail about the design
and implementation, and it is available to read [right here].

[right here]: https://github.com/karma-runner/karma/raw/master/thesis.pdf
[browsers]: ../config/browsers.html

repository: classicvalues/karma

gha_license_id: MIT

repo_name: classicvalues/karma


text:
## Mcms_authentication

Mcms_authentication is a flexible and most updated authentication solution for Rails 3 .

* Is Rack based;
* Integrated with authentication and authorization modules based on devise and cancan gem;
* Allows you to have multiple roles (or models/scopes) signed in at the same time;

## Information

### The Mcms installation

Installation of Mcms_authentication is crazy simple.

Here is how:

* Create your rails applications

```console
rails new my_great_app
```

Now,in your Gemfile

```ruby
gem 'mcms_authentication'
```

Run the bundle command to install it.

```console
rails g mcms_authentication install
```

and navigate

```ruby
/mcms/users
```

### Note

This has most of the features required in a good authentication solution but it requires further testing to make it more robust and feature rich. So please pass on you valuable feedback
to help us make this better.

## License

MIT License. Copyright 2012 Mindfire Solutions Pvt Ltd. http://www.mindfiresolutions.com


text:
# wildfly-hibernate5-error
Simple Web Application using native Hibernate 5 and JTA on WildFly 10.

To run this on WildFly `10.0.0.Beta2`, just do `mvn clean package` and copy `target/wildfly-hibernate5-error.war` to `$WILDFLY_HOME/standalone/deployment directory`.

To run this on WildFly `9.0.1.Final` you can do the same as for WildFly 10, however, following modificaitons must be done first:

* replace `hibernate5` with `hibernate4` in `./src/main/webapp/WEB-INF/flowers-service.xml`
* replace `10.0.0.Beta2` with `9.0.1.Final` in `./pom.xml`


text:
---
layout: post
category: work
type: Regular
permalink: /architecting-for-growth/

# Home
company: Raken
title: Architecting for Growth
summary: Building a foundation for the future of Raken.
thumbnail: /images/thumbnails/ia-thumbnail.png
thumbnailDesc: Architecting For Growth

---

When I first joined Raken, features in our web application were painfully fragmented.

Through customer feedback and event tracking, the team had come to learn that existing features beyond our daily reporting tools were not being adopted by our users.

Engineering teams were spending months on new features only to find that adoption was incredibly low even though these were highly asked-for features.

This was partially symptomatic of where Raken found product market fit initially: people knew us as a daily reporting solution and nothing more.
{: .post-paragraph-embedded-last}

![Mixpanel data showing feature usage](../assets/img/raken/mixpanel.png){:.img-120 .mb .mt .zoom-image}

From production tracking, timecards, and safety talks, to checklists. Users had to navigate away from the daily report in order to discover them.

My role was to work with stakeholders across the organization in order to understand how changes to the navigation might affect operations and to envision how we might improve the experience.

We knew from research that user’s who were taught about our extended features were much more likely to continue using them after their training period ended. We also knew that the needs of companies using these features was highly variable; there was no single flow that could work for everyone.

All of this highlighted the fundamental problem with how Raken’s information architecture was set up: having a highly nested navigation hierarchy meant that user’s rarely ventured out of the features that they were familiar with.
{: .post-paragraph-embedded-last}

We asked: what would happen if we consolidated the project feature navigation into a single menu?

<video autoplay loop width="100%">
  <source src="../assets/img/raken/information-architecture.mp4" type="video/mp4">
  <source src="../assets/img/raken/information-architecture.webm" type="video/webm">

Your browser doesn't support HTML5 video. Here is
     a link to the video instead.

</video>{:.img-post .mb .mt}

Due to the nature of the application, there was a need to distinguish between Company level and Project level features. This duality presented an opportunity to organize features according to whether or not the user is inside a project.
{: .post-paragraph-embedded-last}

<video autoplay loop width="100%">
  <source src="../assets/img/raken/project-and-company.mp4" type="video/mp4">
  <source src="../assets/img/raken/project-and-company.webm" type="video/webm">

Your browser doesn't support HTML5 video. Here is
     a link to the video instead.

</video>{:.img-120 .mb .mt}

In order to flatten the navigation we needed to surface features and settings that had long been buried deep within settings. Not only did the change create more visibility for these features but it also provided an opportunity for new feature announcements and upgrade prompts when the user was on a basic plan. Check out the [Web](https://www.sketch.com/s/99011ff7-74b8-40fe-9053-45e867580ab6/v/ZWj8j5/a/kwMv79/play) experience.
{: .post-paragraph-embedded-last}

![New feature announcements](../assets/img/raken/upgrade-mega-menu.png){:.img-120 .mt .mb .zoom-image}

Even though this project was primarily an improvement to the Raken web experience, our mobile apps also needed to be updated to follow the same patterns.

Since Raken’s native mobile apps act as a bridge between office admins and workers out in the field, we needed to make sure that the new architecture would continue to be intuitive for those users while matching the new pattern.
{: .post-paragraph-embedded-last}

![Project tools on iOS](../assets/img/raken/mobile-tools.png){:.img-50 .mt .mb .zoom-image}

I needed a layout that was straight-forward and easy to understand: I landed on the layout above because it offered simplicity and the flexibility to add or remove features based on plan type, user type, or company customization.

Early signals have been promising: internal stakeholders and customers like being able to navigate their project settings all from a single menu. For our users, having a reliable app to perform their work activities is a must and though the app has confusing layouts and poor interactions, they had become accustomed to them. Our strategy is to slowly release the redesign in chunks.

This project is ongoing and slated to be completed June 2021.

repository: zackgemmell/zali

branch_name: refs/heads/main

repo_name: zackgemmell/zali


text:
# setMinVideoBitrate

## Description

Set a minimum video bitrate reachable through adaptive streaming.

When the bitrate is chosen through adaptive streaming (i.e., not enforced
manually through APIs such as `setVideoBitrate`), the player will never switch
to a video quality with a bitrate lower than that value.

The exception being when no quality has a higher bitrate, in which case the
maximum quality will always be chosen instead.

For example, if you want that video qualities chosen automatically never have
a bitrate below 100 kilobits per second you can call:

```js
player.setMinVideoBitrate(100000);
```

Any limit can be removed just by setting that value to `0`:

```js
// remove video bitrate lower limit
player.setMinVideoBitrate(0);
```

The effect of this method is persisted from content to content. As such, it can
even be called when no content is currently loaded.

Note that this only affects adaptive strategies. Forcing the bitrate manually
(for example by calling `setVideoBitrate`) bypass this limit completely.

In DirectFile mode (see loadVideo options),
this method has no effect.

## Syntax

```js
player.setMinVideoBitrate(minBitrate);
```

  - **arguments**:

    1. _minBitrate_ `number`: Lower video bitrate limit when adaptive streaming
       is enabled.

repository: canalplus/rx-player

gha_language: TypeScript

repo_name: canalplus/rx-player


text:
# SuperNova-Weather
This Project contains source code of Weather Android Application, designed similar to [Yahoo Weather App](https://play.google.com/store/apps/details?id=com.yahoo.mobile.client.android.weather), Based on [World Weather Online](https://developer.worldweatheronline.com/api/).

**You need to Change the API key in the *[Constants]( https://github.com/hani-momanii/SuperNova-Weather/blob/2c1eef77fb09984fc76ce18292a1cb2f61022988/app/src/main/java/hani/weather/utils/Constants.java )* class **, get your API key from [World Weather Online](https://developer.worldweatheronline.com/api/).

# Introduction:
 - This application allow users to view the weather forecast for one
   week.
 - The weather forecast by default available for the four cities
   mentioned in the assignment.
 - This application allow the user to search for city using city name or
   zip code, so the user can add cities as many as he want , also he can
   remove any unwanted city easily .
 - This application store the weather forecast for 7 days from the last
   time the user open the application while the internet available , The
   application need internet access for the first open at least.
 - This application is user friendly, easy to use and simple.

#Application design :
The application use three activities, the SplashActivity with handle the application initialising to add the default cities if the user open the application for the first time then redirect the user to the MainActivity which has a view pager that provide a fragment for every city to display its weather forecast.

Inside the **[WeatherFragment]( https://github.com/hani-momanii/SuperNova-Weather/blob/2c1eef77fb09984fc76ce18292a1cb2f61022988/app/src/main/java/hani/weather/fragments/WeatherFragment.java )** all the main operations happen, it send the request to ApiHelper class and receive the response from it using WeatherForeCastCallBacks then update the views.

The user can add or remove cities from **[CitiesActivity]( https://github.com/hani-momanii/SuperNova-Weather/blob/c84fa6fcf0e4c9df2c421d8dbf1af2365ad727f7/app/src/main/java/hani/weather/activities/CitiesActivity.java )**.

**[ApiHelper]( https://github.com/hani-momanii/SuperNova-Weather/blob/2c1eef77fb09984fc76ce18292a1cb2f61022988/app/src/main/java/hani/weather/apimanger/ApiHelper.java )** mange the API requests, send request data for the ApiInterface and receive the response then store the result if needed then send the data via callbacks.

**[DatabaseController]( https://github.com/hani-momanii/SuperNova-Weather/blob/c84fa6fcf0e4c9df2c421d8dbf1af2365ad727f7/app/src/main/java/hani/weather/utils/DatabaseController.java )** used to mange the data store operations in simple way to use.

**[Utility class]( https://github.com/hani-momanii/SuperNova-Weather/blob/c84fa6fcf0e4c9df2c421d8dbf1af2365ad727f7/app/src/main/java/hani/weather/utils/Utility.java )** provide the common operations, which used in many classes.

**[Constants]( https://github.com/hani-momanii/SuperNova-Weather/blob/2c1eef77fb09984fc76ce18292a1cb2f61022988/app/src/main/java/hani/weather/utils/Constants.java )** provide the needed constants to config the app functionality, for example **if you want to change the days of forecast just change the NUMBER_OF_DAYS_TO_GET value for the needed days number+1 , the 1 is for the current day**.

#Application UX/UI design:

The application design similar to [Yahoo Weather App](https://play.google.com/store/apps/details?id=com.yahoo.mobile.client.android.weather), easy to use and simple, few clicks or actions needed from the user.

All the icons used on the app is from [Material Icon Generator](https://github.com/konifar/android-material-design-icon-generator-plugin).

#Used 3rd party Libraries:
 - [Retrofit]( http://square.github.io/retrofit/) for API calls.
 - [Realm]( https://realm.io/products/java/ ) for storing the cities and weather forecast.
 - [Glide]( https://github.com/bumptech/glide ) for image loading.

## Contact
[![alt text][1.1]][1]
[![alt text][2.1]][2]
[![alt text][6.1]][6]

[1.1]: http://i.imgur.com/tXSoThF.png (twitter icon with padding)
[2.1]: http://i.imgur.com/P3YfQoD.png (facebook icon with padding)
[6.1]: http://i.imgur.com/0o48UoR.png (github icon with padding)

[1]: https://twitter.com/hani_momanii
[2]: https://www.facebook.com/hani.momanii
[6]: https://github.com/hani-momanii

## License

* [Apache Version 2.0](http://www.apache.org/licenses/LICENSE-2.0.html)

```
Copyright 2017 Hani Al-Momani

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: warchibald/SuperNova-Weather

repo_name: warchibald/SuperNova-Weather


text:
# grunt-cmv-git-subtree

> A grunt task to work with git subtrees

## Getting Started
This plugin requires Grunt `~0.4.5`

If you haven't used [Grunt](http://gruntjs.com/) before, be sure to check out the [Getting Started](http://gruntjs.com/getting-started) guide, as it explains how to create a [Gruntfile](http://gruntjs.com/sample-gruntfile) as well as install and use Grunt plugins. Once you're familiar with that process, you may install this plugin with this command:

```shell
npm install grunt-cmv-git-subtree --save-dev
```

Once the plugin has been installed, it may be enabled inside your Gruntfile with this line of JavaScript:

```js
grunt.loadNpmTasks('grunt-cmv-git-subtree');
```

## The "cmv_git_subtree" task

### Overview
In your project's Gruntfile, add a section named `cmv_git_subtree` to the data object passed into `grunt.initConfig()`.

```js
grunt.initConfig({
    git_subtree_add: {
			subtree: {
				options: {
					source: "https://github.com/liaodrake/subtree-for-grunt-subtree-testing.git",
					branch: "master",
					target: "test-tree"
				}
			}
    },
		git_subtree_pull: {
			subtree: {
				options: {
					source: "https://github.com/liaodrake/subtree-for-grunt-subtree-testing.git",
					branch: "master",
					target: "test-tree"
				}
			}
		},
		git_subtree_push: {
			subtree: {
				options: {
					source: "https://github.com/liaodrake/subtree-for-grunt-subtree-testing.git",
					branch: "master",
					target: "test-tree"
				}
			}
		}
});
```

### Options

#### options.source
Type: `String`
Default value: ``

A string value that is used to represent the remote repository.

#### options.branch
Type: `String`
Default value: `master`

A string value that is used to represent the remote branch to pull from.

#### options.target
Type: `String`
Default value: ``

A string value that is used to represent the target local directory.

#### options.squash
Type: `Boolean`
Default value: `true`

A boolean value that is used to represent the option to squash the commits into one pull.

### Usage Examples

#### Default Options
In this example, the default options are used to do something with whatever. So if the `testing` file has the content `Testing` and the `123` file had the content `1 2 3`, the generated result would be `Testing, 1 2 3.`

```js
grunt.initConfig({
  git_subtree_add: {
    subtree: {
      options: {
        source: "https://github.com/liaodrake/subtree-for-grunt-subtree-testing.git",
        target: "test-tree"
      }
    }
  },
  git_subtree_pull: {
    subtree: {
      options: {
        source: "https://github.com/liaodrake/subtree-for-grunt-subtree-testing.git",
        target: "test-tree"
      }
    }
  },
  git_subtree_push: {
    subtree: {
      options: {
        source: "https://github.com/liaodrake/subtree-for-grunt-subtree-testing.git",
        target: "test-tree"
      }
    }
  }
});
```

#### Custom Options
In this example, custom options are used to do something else with whatever else. So if the `testing` file has the content `Testing` and the `123` file had the content `1 2 3`, the generated result in this case would be `Testing: 1 2 3 !!!`

```js
grunt.initConfig({
  git_subtree_add: {
    subtree: {
      options: {
        source: "https://github.com/liaodrake/subtree-for-grunt-subtree-testing.git",
        branch: "master",
        target: "test-tree"
      }
    }
  },
  git_subtree_pull: {
    subtree: {
      options: {
        source: "https://github.com/liaodrake/subtree-for-grunt-subtree-testing.git",
        branch: "master",
        target: "test-tree"
      }
    }
  },
  git_subtree_push: {
    subtree: {
      options: {
        source: "https://github.com/liaodrake/subtree-for-grunt-subtree-testing.git",
        branch: "master",
        target: "test-tree"
      }
    }
  }
});
```

## Contributing
In lieu of a formal styleguide, take care to maintain the existing coding style. Add unit tests for any new or changed functionality. Lint and test your code using [Grunt](http://gruntjs.com/).

## Release History
_(Nothing yet)_

repository: CodeVachon/grunt-cmv-git-subtree

repo_name: CodeVachon/grunt-cmv-git-subtree


text:
# Issue Submissions
If you would like to submit a question, raise a bug or suggest an enhancement,
you should start by creating an issue on the repository's issue page. From there,
a discussion will take place on the validity of the issue and whether or not
it should be worked on.

Before raising an issue, please do search through previously raised issues
to see if it has already been addressed.

# Development
If an issue has been planned for development and you would like to contribute
to this repository, start by creating your own fork.

## Setup
To setup your environment you can run either `yarn install` or npm `install`
This will install all libraries run time and dev dependencies.

## Testing
This library will not accept any PR that does not have a test corresponding
to the feature changes/additions. Ensure that you place the correct tests and
that the build is not broken. You can check this by running `yarn test` or
`npm test`

## Scaffolds
If you are adding in a validator function that has been accepted, then you
can take advantage of our Plop scaffolds. You can run `yarn plop` in your
terminal and you will get a interactive scaffold generator.

## Commit Messages
All commits to be contributed to this repository should abide to our standards.
Use Gitmojis (follow  standards at https://gitmoji.carloscuesta.me/)
to make it easier for us to go through our commit history.
Also, we try to associate commits to raised issues. Please use the following
commit message syntax: `EMOJI MESSAGE (#ISSUE_NUMBER)`. For example
`:sparkles: Added new isGreaterThanValidator (#123)`

repository: alaboudi/golden-validator

repo_name: alaboudi/golden-validator


text:
# Kaomoji Discord Bot `\(^ヮ^)/`

This bot is created using TypeScript and Discord.js. It was originally meant for the University of Manitoba chapter of IEEE Discord server as a test project for the new slash commands feature. It was developed by Mahyar Mirrashed (Chair 2021-2022) as part of his incoming role during the summer.

## Generating new Kaomoji Data

To generate new data to enter as a Kaomoji in a Discord issue, please use the following Python script:

```py
emojis = '''
'''.split('\n')

from json import dump
with open('out.txt', mode='w') as f:
  dump(emojis, f)
```

#### Credits & Attributions

I would like to thank SmileX from [kaomoji.ru](http://kaomoji.ru/en/) who provided most of the Kaomojis available with this bot.

repository: mahyarmirrashed/bot-kaomoji

repo_name: mahyarmirrashed/bot-kaomoji


text:
---
layout: default
---

# 1997-05-19 - Forgery detection

## Header Data

From<EMAIL_ADDRESS>(Anonymous)

To<EMAIL_ADDRESS>Message Hash: da75b98b36fa0104f5812f880c77ded109a902426dce7c2fa4aa8f916ba7a754

Message ID<EMAIL_ADDRESS>Reply To: _N/A_

UTC Datetime: 1997-05-19 18:12:34 UTC

Raw Date: Tue, 20 May 1997 02:12:34 +0800

## Raw message

```
{% raw  %}From<EMAIL_ADDRESS>(Anonymous)
Date: Tue, 20 May 1997 02:12:34 +0800
To<EMAIL_ADDRESS>Subject: Forgery detection
Message-ID<EMAIL_ADDRESS>MIME-Version: 1.0
Content-Type: text/plain

Tim C. May is just another garden variety Intel pansy that has been misusing its
`manhole' so badly that the overstretched sphincter cannot hold back the shit that
all Intellers are full of and it spills out onto this mailing list.

            /\_/\
           ( x x )
       -oo0-(o o)-0oo- Tim C. May

{% endraw %}
```

## Thread

+ Return to [May 1997](/archive/1997/05)

+ Return to "[Graham-John Bullers <real@freenet.edmonton.ab.ca>](/authors/grahamjohn_bullers_real_at_freenet_edmonton_ab_ca_)"
+ Return to<EMAIL_ADDRESS>(Anonymous)](/authors/nobody_at_replay_com_anonymous_)"

+ 1997-05-19 (Tue, 20 May 1997 02:12:34 +0800) - Forgery detection -<EMAIL_ADDRESS>(Anonymous)_
  + 1997-05-19 (Tue, 20 May 1997 04:56:12 +0800) - [Re: Forgery detection](/archive/1997/05/545212514cc15091bbeb3d4a6276d2b4f935c187867f55595cf739085f8b2eb0) - _Graham-John Bullers<EMAIL_ADDRESS>


text:
### [CVE-2023-32380](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-32380)
![](https://img.shields.io/static/v1?label=Product&message=macOS&color=blue)
![](https://img.shields.io/static/v1?label=Version&message=unspecified%3C%2013.4%20&color=brighgreen)
![](https://img.shields.io/static/v1?label=Vulnerability&message=Processing%20a%203D%20model%20may%20lead%20to%20arbitrary%20code%20execution&color=brighgreen)

### Description

An out-of-bounds write issue was addressed with improved bounds checking. This issue is fixed in macOS Big Sur 11.7.7, macOS Monterey 12.6.6, macOS Ventura 13.4. Processing a 3D model may lead to arbitrary code execution.

### POC

#### Reference
No PoCs from references.

#### Github
- https://github.com/ARPSyndicate/cvemon

repository: trickest/cve

gha_language: HTML

repo_name: trickest/cve


text:
+++
title = "Userspace"
weight = 350
sort_by = "weight"
template = "sections/docs/chapters.html"
insert_anchor_links = "right"
+++

Urbit's userspace is managed by Arvo's Gall vane.

## [Overview](/docs/userspace/overview)

An overview of userspace in Urbit.

## [Gall Guide](/docs/userspace/gall-guide/intro)

Learn how to develop Gall agents.

## [Threads](/docs/userspace/threads/)

Resources on threads - monadic functions useful for complex IO.

## [Graph Store](/docs/userspace/graph-store/)

Resources on Graph Store, a non-relational database specialized for social media applications.

## [Distribution](/docs/userspace/dist/dist)

Resources on distribution and management of desks/apps.


text:
globejs
=======

web-gl based globe application inspired by the web-gl globe of the google arts team.

## Requirements
Currently [google chrome](http://www.google.com/chrome), [firefox](http://www.mozilla.org/firefox/) as well
as [safari](https://www.apple.com/safari/) browsers are supported.

The build process, which generates textures and javascript index files, requires a running [golang](http://golang.org) and perl environment with a working [Perl Image::Magick](http://www.imagemagick.org/) module.

## External content and references.
This globe was inspired by [dataarts/webgl-globe](https://github.com/dataarts/webgl-globe)
and makes heavy use of the [Three.js](https://github.com/mrdoob/three.js/) and [Tween.js](https://github.com/sole/tween.js) libraries.
Country flag images are fetched from [geognos api](http://www.geognos.com).

## Features
- country hovering
- country heatmap
- particle system based on geo coordinates (lat/long)
- data pillars based on geo coordinates (lat/long,country)
- connections based on geo coordinates (lat/long,country)

## Examples

Currently a few sample applications are part of the repo. Please also review the **requirements** section for build process requirements.

In order to start an example please follow the following instructions:

### Step 1) Build textures and generate javascript index files.
The build process could take some time because the textures are currently generated in a very inefficient way. Feel free to improve this by submitting a pull request ;)

```
% make
```

### Step 2) Install required go packages:

To run the examples make sure that the corresponding golang packages are installed:
```
% go get github.com/sebkl/gotojs
% go get github.com/sebkl/gopenflights
```

### Step 3) Run the example server application:
*Basic example:*

```
% cd HTDOCS/examples/basic && go run server.go
2016/02/10 21:10:34 Registering converter for type string
2016/02/10 21:10:34 Registering converter for type time.Time
2016/02/10 21:10:34 FileServer enabled at '/p'
2016/02/10 21:10:34 GotojsEngine enabled at '/gotojs/'
2016/02/10 21:10:34 Starting server at ":8080".
```

*Openflights example:*

```
% cd HTDOCS/examples/basic && go run server.go
...
```

*Twitter example:*

```
% cd HTDOCS/examples/twitter/
% cp witter_account.json.sample twitter_account.json
% vim HTDOCS/examples/twitter/twitter_account.json
% # Adjust your twitter account details to initiate a tweet stream.
% ./twitter
...
```

### Step 4) Open the browser
Open your browser and browser the page [localhost:8080](http://localhost:8080).

![screenshot](https://raw.github.com/sebkl/globejs/master/screenshots/sample_plain.png)
![screenshot](https://raw.github.com/sebkl/globejs/master/screenshots/sample_openflights.png)
![screenshot](https://raw.github.com/sebkl/globejs/master/screenshots/sample.png)

repository: sebkl/globejs

gha_language: JavaScript

repo_name: sebkl/globejs


text:
#  Using FHIR Store

## What is it?

**Fast Healthcare Interoperability Resources (FHIR)** is a healthcare data standard with an application programming interface (API) for representing and exchanging electronic health records (EHR). FHIR is an information network that lets you link data across systems and a communication network that lets you exchange data between systems.

In GCP, there are the following services:
- A **FHIR store** is a data store in the Cloud Healthcare API that holds FHIR resources. FHIR stores exist inside datasets.
- **FHIR resources** which organize data formats and elements. Each resource has the following properties:
  - A shared method for defining and representing data, built upon data types consisting of reusable clusters of elements.
  - A common set of metadata, providing technical and structural context.
  - A human-readable text representation that uses HTML as a fallback display option for clinical safety.
  - Designed to support most clinical and billing use cases - you can extend to meet your requirements
- **FHIR Profiles** are a set of instructions in addition to the existing core specification for resources that fall under a specific use and context
  - The Cloud Healthcare API enforces profiles by validating resources against the constraints in the relevant profile.

## Why and How to use it?

Interoperability of patient records.  Steps from the GCP Quickstart - [link](https://cloud.google.com/healthcare-api/docs/store-healthcare-data-console)

### Step 0 - Prepare
 - ENABLE the Cloud Healthcare and Billing APIs
 - CREATE a new (empty) healthcare dataset

### Step 1 - Setup and Load
 - CREATE a FHIR store instance
 - LOAD data
   - IMPORT public data `gs://gcp-public-data--synthea-fhir-data-10-patients/fhir_r4_ndjson/*.ndjson`

### Step 2 - View and Validate
 - VIEW data (select `patient`) resource type

## Learn More
 - 📓 Article: "Step-by-step setup for FHIR Store on GCP" - [link](https://kellrott.medium.com/using-google-fhir-to-support-research-8f726834d77)
 - 📗 Use the de-identification sensitive data service for FHIR store - [link](https://cloud.google.com/healthcare-api/docs/how-tos/deidentify)
 - 📘 Use the 'how-to' guide for FHIR store - [link](https://cloud.google.com/healthcare-api/docs/how-tos#fhir-guide)
 - 📓 Article: "Analyzing FHIR data in BigQuery" - [link](https://cloud.google.com/architecture/analyzing-fhir-data-in-bigquery)

repository: lynnlangit/gcp-for-bioinformatics

gha_language: Jupyter Notebook

repo_name: lynnlangit/gcp-for-bioinformatics


text:
---
title: Two Factor Auth in Web Apps
date: '2019-04-22'
spoiler: Comparing different Options to implement Two Factor Auth in Web Applications
image: 2fa-web-apps/social.png
---

![Two Factor Auth in Web Apps](./2fa-web-apps.png)

Two Factor or Multi Factor Authentication (2FA / MFA) Schemes are a way to improve the security of applications. Usally these factors are grouped in to the following three groups:

![Three Different Types of Auth Factors. Something you know, have or are.](./types-of-factors.png)

For an authentication scheme to be considered "two factor" the user has to prove their identity by at least two factors of different categories.

For example: Authentication using a *password* and a *fingerprint* is considered two factor as *passwords* are something you know while your *fingerprint* is something you are.

Contrary to that, authentication using *password* and a *security question* is **not** 2FA, as both *password* and *security questions* are something you know.

gha_license_id: NOASSERTION


text:
# Functional MRI for Neural Networks

An attempt to create real-time in depth visualisation for neural
networks.

## Requirements

The following programs/libraries need to be installed on your system:

- CMake (at least 3.8)
- Caffe
- Google log (glog)
- OpenCV (at least 2.6, 3.x works fine.)
- Boost System

Note that most of these are dependencies of Caffe, and thus will
probably already be on your system. For OS-specific instructions, see
below.

### Arch Linux

1. Install either `caffe` or `caffe-cpu` from the AUR.
2. Install other dependencies:
    - `cmake`
    - `freeglut`
    - `gtkmm3`
3. Do the build as normal

### Ubuntu

Caffe is available from the Ubuntu repositories from version 17.10
(Artful Aardvark) onwards, and can be used to simplify the installation
process. The commands required are as follows:

    # Install dependencies
    sudo apt install libcaffe-cpu-dev freeglut3-dev libgtkmm-3.0-dev \
        build-essential cmake libopencv-dev libboost-system-dev \
        libgoogle-glog-dev libblas-dev libprotobuf-dev \
        libboost-filesystem-dev libboost-program-options-dev

    # Replace libcaffe-cpu-dev with libcaffe-cuda-dev for CUDA support
    # Do the build normally

These commands were tested on Ubuntu 18.04. Versions as old as 16.04
will work, but can be very painful and labor intesnive to set up.

Older versions of Ubuntu need some help, as the `caffe` package does not
exist, and the supplied `cmake` version is too old.

1. First, install a recent version of [cmake](https://cmake.org/). Any
   version from 3.8 onwards will do.
2. Then, install caffe from source. Installation instructions can be
   found [on the Caffe
   website](http://caffe.berkeleyvision.org/install_apt.html). Be sure
   to also install the development headers.
3. Run the build as normal.

## Building

The build process is based on CMake. This means you can easily create a
build as follows. Starting from the project root:

    mkdir build && cd build
    cmake ..
    make

Compilation is a little slow due to the inclusion of Boost.

## Usage

This program can operate on most Caffe models, provided they don't
split/merge the input, since the visualisers cannot handle more than
one input.

There are a few valid models provided. It can be downloaded by
running `./download-models.sh` from the data folder.

After that, you can, for example, run the program as follows
(assuming you are in the build directory)

    ./fmri -n ../data/models/caffenet/model-dedup.prototxt \
        -w ../data/models/caffenet/bvlc_reference_caffenet.caffemodel \
        -l ../data/ilsvrc12/synset_words.txt \
        ../data/samples/*.jpg

This will run the network on the deduplicated caffenet (see: [limitations](#limitations))
with the correct weights file and the labels file supplied, on all jpegs
located in the samples folder. More advanced usage can be discovered using
the `-h` option of the executable.

Additionally, a graphical launcher is included, called `fmri-launcher`.
It is built by default unless disabled at compile time. The interface
contains a button or a chooser for every option in the program.

### Controls

You can move around with the WASD keys, and look around using the mouse.
Arrow keys change the currently loaded input. F1 brings up an overlay
that tells you all other options.

## Limitations

The following documents the limitations currently present in the program,
including possible workarounds. Note that these may change at any time.

### No in-place layers

Due to the way Caffe works, this program cannot properly extract state
data from networks that use in-place computation, since it cannot observe
the input- and output state of each layer.

To work around this, a simple program `deinplace` is included as a tool,
which will rewrite an existing network to not use in-place computation.
Its options are documented with its `-h` flag.

### Single input/output

The visualisation structuree only supports linear networks. That is: network
where each layer only ever reads from one input layer and only produces one
output. This is not a fundamental limitation, and could be reworked in future
versions.

### Data input layer only

The program only supports reading input from image files, rather than using
LLDB or LevelDB sources. Render your inputs to an image format of choice to
use the program.

repository: bertptrs/fmri

repo_name: bertptrs/fmri


text:
# Pikchr.js - Generate technical diagrams from markup

What is Pikchr? From the [official documentation](https://pikchr.org/home/doc/trunk/homepage.md):

> Pikchr (pronounced "picture") is a [PIC](https://en.wikipedia.org/wiki/Pic_language)-like markup language for diagrams in technical documentation.

`Pikchr.js` allows you to generate Pikchr diagrams directly from Javascript using Emscripten.

repository: graeme-lockley/pikchr-js

repo_name: graeme-lockley/pikchr-js


text:
# A repository of CocoaPods specifications.

This repository contains specifications of open-source Objective-C libraries, which are used by [CocoaPods](https://github.com/CocoaPods/CocoaPods) to manage library dependencies for your Xcode project.

## Use this repo

pod repo add  pokermania https://github.com/pokermania/CocoaPods.git

## License

These specifications and CocoaPods are available under the [MIT license](http://www.opensource.org/licenses/mit-license.php).

repository: pokermania/CocoaPods

repo_name: pokermania/CocoaPods


text:
# detect-increment

![Created with ](https://img.shields.io/badge/Created%20with-@programmerraj/create-3cb371?style=flat)
[![TS-Standard - Typescript Standard Style Guide](https://badgen.net/badge/code%20style/ts-standard/blue?icon=typescript)](https://github.com/standard/ts-standard)

## What This Does
Uses [`parse-commit-message`](https://www.npmjs.com/package/parse-commit-message#plugins) to detect if the version should be incremented to `major` (breaking change), `minor` (feature without breaking change), `patch` (bug fix), or `none` (no new release). If the commit message is a pull request merge message, that commit will be `none`.

This works by getting all the commit messages. It works on the `push` event, and on pull request events.

## Usage

### Pnpm
This project uses [Pnpm](https://pnpm.io/) to install dependencies. Use `pnpm/action-setup` before using this action.

### Environment Variables

#### `GITHUB_TOKEN`
This variable is needed for getting commits of a pull request. If running on the `push` event, this variable is not used.

### Outputs

#### `increment`
Will be either `none`, `patch`, `minor`, or `major`.

#### `increments_by_scope`
Will be a JSON object where the keys are the scopes, and the values are the increments.

## Examples
```yaml
# ...
jobs:
  release:
    runs-on: ubuntu-latest
    steps:
    # ...
    - name: Setup Pnpm
      uses<EMAIL_ADDRESS>      with:
        version: 6.4
        run_install: true
    - id: get_increment
      name: Get Increment
      uses<EMAIL_ADDRESS>    - run: |
        echo ${{ steps.get_increment.outputs.increment }}
        echo ${{ steps.get_increment.outputs.increments_by_scopes }}
```
The example above will echo the increment. The output can be used with other steps, like automatically releasing a new version of a package.

Note that it says uses<EMAIL_ADDRESS>`v1.2` is a tag that will be updated to have the latest patch release. By using this tag, you can get a version with bug fixes without having to change any files.

repository: ChocolateLoverRaj/detect-increment

repo_name: ChocolateLoverRaj/detect-increment


text:
---
title: Modules
template: chapter.html
---

# Modules

When using **jide.js**, you'll notice that almost everything is a module of its own. If you're not that familiar
with words like _AMD_ or _Browserify_ and have no experience with _node.js_, you'll probably feel a bit overwhelmed by
their use throughout the **jide.js** documentation. This guide intends to help you understand those tools.

## What are modules?

In **jide.js** a module is often a control or class that you'll want to use in your own code. Each modules has its own
file. When you create your application, the concept of modules helps you to use only those parts of **jide.js** that you
need. If you don't intend to use the layouts provided by **jide.js**, there is no need for your users to download those
extra KB.

If you come from _jQuery_ or similar frameworks, you'll notice that this is similar to using _jQuery_ plugins, where your
application includes the core _jQuery_ framework and all plugins you need.

## What is a module loader?

The downside to using separate files for modules usually is that you need to manually include them as `script` elements
in your HTML. With a project such as **jide.js**, which consists of so many tiny modules that depend on other
modules, that'd not be productive. Worse yet, it'd be highly error prone. What if you missed an include or used an
incorrect order?  We don't want that.

That's why we use a module loader. The module loader is responsible for giving you the modules you want and to make sure
that these modules get all their dependencies, too.

Currently, there are three dominant choices for loading modules in this manner:

Build your own and force everyone to recreate his code so that its compatible

AMD

Browserify

Unlike other projects, we have decided that we want to be compatible with the rest of the world and that we do not
want to reinvent the wheel. That's why we haven't build our own module loader and instead opted to support the existing
ones. Once native Javascript modules become a reality, we will also support those. For now, you can use jide.js with any
AMD compatible module loader and with Browserify.

AMD, unlike Browserify, isn't a tool. It's more like a standard way to define modules. There are many implementations of
AMD loaders, such as [require.js](http://www.requirejs.org). [Browserify](http://browserify.org), on the other hand, is
a tool to transform module files into a single file that contains all of your code.

## Understanding AMD

The AMD standard is based on two innocently looking functions that you will use in your code: `define` and `require`.
With AMD, you need to wrap your own modules in a `define` call and start your application in a `require` call. Let's take
a look at that:

```javascript
// in your main.js file
require(['jidejs/ui/control/Button', 'app/mylib'], function(Button, mylib) {
    // inside of this function you can use the Button constructor to create a new button for your application
});

// in your app/mylib.js file
define(['jidejs/base/Observable'], function(Observable) {
    var mylib = {
        createCoolObservable: function() {
            return new Observable('cool');
        }
    };

    return mylib;
});
```

The `require` expects two parameters: An array of dependencies (defined as Strings) and a function that is invoked
with all of those dependencies in the order in which they were defined. For the purpose of this introduction, you can
assume that `define` has the same signature and expects you to return an object or function that will be passed
to other modules that need it.
`require` and `define` will load the dependencies you specified asynchronously from your server. Since there are many
implementations of AMD, there are many ways to configure how exactly it will resolve those dependencies. In this guide,
we focus mostly on the [require.js](http://www.requirejs.org) implementation of AMD, so let's take a look at how to
configure it for usage with **jide.js**.

```javascript
// this should be placed before your require() call
require.config({
    // path to your script files
   "baseUrl": '.',

   "packages": [{
       // configure a package to let require.js know where to find modules that start with 'jidejs':
       name: 'jidejs',
       location: './bower_components/jidejs'
   }, {
       // and also let it know where to find modules that start with 'app'
       name: 'app',
       location: './app'
   }],
   // and tell it where to find the 'text' plugin (needs to be downloaded in addition to require.js
   paths: {
       text: './bower_components/requirejs-text/text'
   }
});
```

The easiest way to get started with **jide.js** and AMD is to use the
[Yeoman Quickstart Guide](../00-installation/03-with-yeoman.html) which takes care of installing all of the required
dependencies, configures require.js for you and provides the tools to create an optimized build of your application.

## Understanding Browserify

Browserify, unlike AMD, is not a standard for defining modules. Instead, it's a tool that allows you to transform and
bundle your script files into a single application file. You can do the same with AMD (using the require.js optimizer)
but Browserify is a valid and good option in a few cases.

When using Browserify, there is no way around including a build step, even while developing your application. On the
other hand, you gain really easy access to most [npm](http://npmjs.org) modules and, perhaps even better, you can share
your code between your Web Application and your Node.js Server implementation.

If you intend to use Browserify, you should be familiar with build tools like [Grunt](http://gruntjs.org) or
[Gulp](http://gulpjs.org) or something else. The [With npm & Browserify Guide](../00-installation/021-with-npm.html)
explains how to setup and use **jide.js** with Browserify.

When you install a package, such as **jide.js**, using _npm_, it will be placed in the *node_modules* directory of your
project. Let's say you did install **jide.js** using _npm_, then you could easily access it in your code with the
`require` function that is provided by Browserify for you. Unlike AMD, there is no `define` function. Instead, you can
specify which parts of your file you want to export as a module by assigning them to the `exports` object.
If you intend to export a constructor function, you would probably want to assign it to `module.exports` instead.

Let's take a look at what this might look like:

```javascript
// in your main.js file
var Button = require('jide/ui/control/Button'),
    mylib = require('./app/mylib');

// For the rest of this file, you have access to the Button constructor and mylib.
```

```javascript
// in your app/mylib.js file
var Observable = require('jide/base/Observable');

var mylib = {
    createCoolObservable: function() {
        return new Observable('cool');
    }
};

module.exports = mylib;
```

Unlike AMD, Browserify provides a synchronous `require` function, so you don't need to wrap your code in a callback
function. As far as **jide.js** is concerned, the most important difference is the name of the modules. When you
use **jide.js** with Browserify, every **jide.js** module starts with **jide**, not **jidejs**, so the module
`jidejs/ui/control/Button` becomes `jide/ui/control/Button`.

repository: modulexcite/jidejs

repo_name: modulexcite/jidejs


text:
## Firesign to VRA Core mapping

This mapping is intended to aid in the process of copying/pasting VRA Core data into Firesign for the 2015 exhibits.

Example metadata in the table below comes from \Metadata\1941\The_Holy_Bible-1613.xml.

| Firesign       | VRA Core                        | Example from VRA XML |
|----------------|---------------------------------|----------------------|
| artist_name                         | work > titleSet > title         | The Holy Bible, Containing the Old testament and the New...Appointed To Be Read in Churches |
| active_dates                        | work > agentSet > agent > name (repeatable)  | Barker, Robert |
| title                               | ---  | |
| release_date                        | work > dateSet > date[@type="publication"] > earliestDate, work > dateSet > date[@type="publication"] > latestDate (if different)   | 1613 |
| format                              | work > worktypeSet > worktype   | Bibles |
| dimensions                          | ---  |
| donor                               | work > locationSet > location > refid   | Memorabilia Collection/BS185 1613 .L6 |
| location                            | work > locationSet > location > name   | Vanderbilt University. Special Collections |
| description                         | work > descriptionSet > description   | Commissioned by King James I in 1604 for the Church of England, this is the third translation of the Christian Bible into English. Robert Barker, the King's Printer, first published the book in 1611; this edition contains printing errors that were eventually eliminated in a later edition of 1613. This folio depicts the offspring of Adam and Eve as a tree form, with text, "As by one man’s disobedience many were made sinners, so by the obedience of one shall many also be made righteous." |
| entry_title **(audio/video only)**  | ---   |  |
| media_type  **(audio/video only)**  | ---   |  |
| length **(audio/video only)**       | ---   |  |
| genre **(audio/video only)**        | ---   |  |
| catalognum **(audio/video only)**   | ---   |  |

#### Questions
* Rights (rightsSet in VRA) and Subjects (subjectSet in VRA) have not been input into Firesign in the past. Will they be now? *No, we will likely continue to keep Firesign simple and not add these fields.*
* Do we need to do any further cleanup on any of the fields to aid in copy/paste?
    - invert agent names to Firstname Lastname (from Lastname, Firstname) -- maybe?
    - ~~names with birth/death dates~~
    - ~~dates in different formats~~
    - [done 6/25/15 jg] capitalize first word of all Format entries
    - ~~remove call numbers from Donor entries~~
    - [done 6/25/15 jg] add Creation Date field and relabel current date field to Publication Date (so that both dates are available to choose from)
    - [done 6/25/15 jg] add Image Filename field
    - [done--none found 6/25/15 jg] check for other VRA fields that might state the manuscript collection/source and add the field(s) if applicable

repository: HeardLibrary/exhibitions

gha_language: XQuery

repo_name: HeardLibrary/exhibitions


text:
# Sidewinder daemon

This project provides support for gaming peripherals under Linux. It was
originally designed for the Microsoft SideWinder X4, but we have extended
support for more keyboards. Our goal is to create a framework-like environment
for rapid driver development under Linux.

## Supported devices

  * Microsoft SideWinder X4
  * Microsoft SideWinder X6
  * Logitech G103
  * Logitech G105
  * Logitech G710
  * Logitech G710+

## Install

Please check, if this project has already been packaged for your specific Linux
distribution. Currently maintained packages:

  * Arch Linux: https://aur.archlinux.org/packages/sidewinderd/

If there are no packages available for your Linux distribution, please proceed
with the manual installation from source:

1. Install the following dependencies. Please refer to your specific Linux
distribution, as package names might differ.

  * cmake 2.8.8 (make)
  * libconfig 1.4.9
  * tinyxml2 2.2.0
  * libudev 210

2. Create a build directory in the toplevel directory:

    ```
    mkdir build
    ```

3. Run cmake from within the new build directory:

    ```
    cd build
    cmake ..
    ```

4. Compile and install:

    ```
    make
    make install
    ```

## Usage

Enable and start Sidewinder daemon:

    systemctl enable sidewinderd.service
    systemctl start sidewinderd.service

Configure `/etc/sidewinderd.conf` according to your needs. Please change the
user, as the default user is root.

You can now use your gaming peripheral! Please note, that there is no graphical
user interface. Some LEDs might light up, letting you know, that Sidewinder
daemon has successfully recognized your keyboard.

## Record macros

The macro keys are fully programmable, but there is no default event. You can
add functions to them, by recording macros or key combinations:

1. Choose a profile. The profile LED on the device will show you, which profile
is active.
2. Press record key. The record LED will light up.
3. Now, choose and press a macro key. On some devices, the record LED will begin
to blink. You're now in macro mode. Please note, that existing macros may get
overwritten.
4. Everything you type on the keyboard will get recorded. You can either record
a single key combination or a long series of keypresses. Please note, that
keypresses still send events to your operating system and your programs.
5. When done, press the record key again. This will stop recording and save the
macro.
6. You've now created a macro. Use it by setting the chosen profile and pressing
the chosen macro key.

## Contribution

In order to contribute to this project, you need to read and agree the Developer
Certificate of Origin, which can be found in the CONTRIBUTING file. Therefore,
commits need to be signed-off. You can do this by adding the `-s` flag when
commiting: `git commit -s`. Pseudonyms and anonymous contributions will not be
accepted.

## License

This project is made available under the MIT License. For more information,
please refer to the LICENSE file.

repository: luziferius/sidewinderd

repo_name: luziferius/sidewinderd


text:
# simple-ev-charging

This is a simple CPS example using a "made up" ev charging station example with a sinusoidal price curve and sinusoidal demand.

The controller has only a single output, which is to choose what the battery should do, either charge or discharge.

## Notes for WCET analysis
- Ensure all loops are bounded by constant bounds.
- Ensure no structs are passed as function parameters and accessed. Only memory may be pointed to.
- Ensure that the correct project and function are chosen in the makefile.
- No trigonometric functions from <math.h> allowed!
- No functions from <string.h> allowed!
- No FILE functions allowed!

## Usage
To start the WCET process
1) Call "make esterel" to create the .c file from the Esterel file.
2) Ensure, in the .c file, that the char arrays have a max size of your choosing, since Esterel limits this to 81. Check STRLEN at top of <prog.c>.
3) Call "make build" to prepare the build files for a WCET analysis.
4) Call "make wcet" to start the WCET analysis.

To build and run the Esterel implementation
1)

repository: PRETgroup/sann

repo_name: PRETgroup/sann


text:
batsignal - Simple battery monitor
==================================
batsignal is a lightweight battery daemon written in C that notifies the user
about various battery states. It is intended for minimal window managers, but
can be used in any environment that supports desktop notifications via
libnotify.

Features
--------
Customizable messages via libnotify on three configurable battery levels. A
fourth configurable battery level will execute an arbitrary system command. In
order to use as few system resources as possible, fewer battery checks are
performed while the battery is discharging and the level of charge is not near a
warning level.

By default, batsignal will attempt to detect the correct battery to monitor.

Requirements
------------
Batsignal requires the following software to build:

  * C compiler
  * libnotify
  * make
  * pkg-config

Installation
------------
Run the following command to build and install batsignal:

    $ make
    $ sudo make install

Usage
-----
See `man batsignal` for details.

Configuration
-------------
`batsignal` is configured using command options - see `man batsignal` for a
complete list. these options can be passed manually from the terminal, added
to the command invocation in shell profile scripts, or during window manager
initialization.

### Systemd
A systemd user service can be installed by running:

    $ make install-service

And can be enabled and started with:

    $ sudo systemctl daemon-reload
    $ systemctl --user enable batsignal.service
    $ systemctl --user start batsignal.service

The service unit starts `batsignal` with default options. To customize the
options used by the service, create a drop-in file that overrides `ExecStart`.
For example:

    $ mkdir -p ~/.config/systemd/user/batsignal.service.d
    $ printf '[Service]\nExecStart=\nExecStart=batsignal -c 10 -w 30 -f 97' > ~/.config/systemd/user/batsignal.service.d/options.conf

Authors
-------
batsignal is written by Corey Hinshaw. It was originally forked from juiced by
Aaron Marcher.

License and Copyright
---------------------
Copyright (c) 2018-2022 Corey Hinshaw
Copyright (c) 2016-2017 Aaron Marcher

Permission to use, copy, modify, and/or distribute this software for any
purpose with or without fee is hereby granted, provided that the above
copyright notice and this permission notice appear in all copies.

 IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY
SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR
IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.

license: ISC

repository: electrickite/batsignal

gha_language: C

gha_license_id: ISC

repo_name: electrickite/batsignal


text:
Ok! Your very first tasks are to **clone this repository** into your own account and **update the README.md** file.

But before moving on, let's be sure you know all the basics we use daily here.

# Step 1 - Warming up - Mastering the Basics

We use [git](https://git-scm.com/)... a lot. If you don't feel confident in your skills using git, here are some recommendations:

- https://try.github.io/
- https://www.atlassian.com/git/tutorials
- https://learngitbranching.js.org/

BTW, we highly encourage training using the terminal.

On the end of every task of this onboard, comment the word `Finish` on the issue to receive your next task (you can try reloading the page if it's taking too long).
You can also comment the word `next`, in case you had to skip the current task.

repository: indigotech/taq-github-bot

branch_name: refs/heads/develop

repo_name: indigotech/taq-github-bot


text:
# {#guide-parallelReduce} parallelReduce Guide
The purpose of this guide is to bring together all of the information we have about the parallelReduce and to provide additional clarity on how it works and why we use it.

## Description
There are layers of abstraction to the `{!rsh} parallelReduce` structure that we should understand first.

Generally speaking it is an abbreviation of a `{!rsh} while` loop pattern.

The variables you set are repeatedly updated uniquely by each one of your participants until the loop condition no longer holds.
Values are updated via `{!rsh} return` statements, while `{!rsh} continue` is implicit.

If some thing or many things can be done by many different people, you use a `{!rsh} parallelReduce` to handle the `{!rsh} fork` and cases.

A `{!rsh} fork` is a `{!rsh} race` between API members where we are unsure who exactly is performing the next consensus operation, this is why they are common with API members – which offer functionality to many different participants.

`{!rsh} fork` ends in the execution of a `{!rsh} switch` structure, executing the appropriate case (if `Bob1` wins do this, if `Bob2` wins do that). Read more about `{!rsh} fork`, including the underlying code that makes up the `{!rsh} fork` keyword.

:::note
Learn more about `{!rsh} race` in the [race guide](##guide-race).
:::

Read through the [guide about when to use what kind of consensus transfer](##guide-ctransfers).

After you understand that you can examine the structure of `{!rsh} parallelReduce` components and their definitions.

Let's start by looking at the most simple `{!rsh} parallelReduce` that we could implement.
```
load: /examples/parallelReduce-api_-counter/index.rsh
md5: 5a60138c737baf125f0cdccec40fec3e
range: 8-10
```
Here we declare one API member function `countUp` for the API on line 9, then define its functionality below.
```
load: /examples/parallelReduce-api_-counter/index.rsh
md5: 5a60138c737baf125f0cdccec40fec3e
range: 18-26
```
- Line 18 declares one loop variable `count` and initializes it to zero, starting the `{!rsh} parallelReduce`.
- Line 19 sets the `{!rsh} invariant`, this contract will accept no tokens.
- Line 20 is a standard `{!rsh} while` loop condition, it runs until the condition breaks.
- Line 21 is the definition of our API member function `countUp`
`API.functionName` and takes zero arguments.
- Line 22 starts the outer `{!rsh} return` and zero is in the pay expression. This function takes no payment from the user. You can specify any number to be paid by the user here. You can also omit the zero and Reach will synthesize this to zero. `ret` is the `{!rsh} return` function to return the function signature value to the caller. Here we have said that the `{!rsh} return` value is a `{!rsh} UInt` on line 8. More information on this below.
- Line 23 invokes that `{!rsh} return` function and returns the `count`.
- Line 24 updates the `count` loop variable to `newCount`.

### API Inputs and Returns
All API member functions must rely only on consensus state and the function inputs.

The API member function has a consensus reduction specification function that takes an argument. Here that function is called `ret`.

You can name this function anything you like, traditionally `ret` or `k` is used to denote return or continuation, respectively.
```
load: /examples/rsvp-6-vevt/index.rsh
md5: ed7d96413f2f23224d5ea6081ae4cc78
range: 52-62
```
`ret` must be called inside the API member function to provide the `{!rsh} return` value to the API caller. Below on line 17 is the function signature for the API member function `register`. It takes no arguments and returns `{!rsh} null`.
```
load: /examples/rsvp-6-vevt/index.rsh
md5: ed7d96413f2f23224d5ea6081ae4cc78
range: 16-18
```
And here again is the implementation of the `register` function, this time pointing to the inputs and outputs.

Remember, it takes no arguments and returns `{!rsh} null`.
```
load: /examples/rsvp-6-vevt/index.rsh
md5: ed7d96413f2f23224d5ea6081ae4cc78
range: 52-62
```
- Line 52 specifies the API and which function we are referencing `Guest.register`. The empty parenthesis denotes that it takes no parameters.
- Line 59 invokes our `ret` function and returns a `{!rsh} null` value to the caller.

::::testQ
As an exercise -- bring the `index.rsh` file to your machine and change the `ret(null)` on line 59 to `ret(true)` and see what error comes up.

:::testA
You should get a type mismatch error, because the return does not match the function signature. @{seclink("RE0088")}
:::
::::

Now that we understand our loop, how to update values, and how to structure function inputs and outputs -- let's look at the difference in syntax between `{!rsh} .api` and `{!rsh} .api_`.

### .api_ vs .api Syntax

#### .api_

We will demonstrate our `countUp` function with both `{!rsh} .api` and `{!rsh} .api_`.

In the following examples these two functions have the same funtionality, to increase the count by one each time a user calls our function.

First, the `{!rsh} .api_` that you have seen already.
```
load: /examples/parallelReduce-api_-counter/index.rsh
md5: 5a60138c737baf125f0cdccec40fec3e
range: 21-26
```
- Line 21 denotes the start of our API member function `B.countUp`. The empty parenthesis means it takes no arguments.
- Line 22 starts the outer `{!rsh} return`. Zero denotes the amount to be paid and we declare our `ret` function.
- Line 23 invokes our `ret` function and returns the value of `count` to the caller.
- Line 24 updates the loop variable `count` increasing it by one.

Any checks performed before the `{!rsh} return` statement will be applied in the local step, during payment and the consensus step of the API call. You should use `{!rsh} .api_` when this check is the same for these steps.

#### .api

Now notice the difference in syntax for `{!rsh} .api`. Remember, this function does the same thing as the one above.
```
load: /examples/parallelReduce-api-counter/index.rsh
md5: 0fee750111780031c4fb176b431e862e
range: 21-27
```
- Line 21 denotes the start of our API member function `B.countUp`.
- Line 22 is for the `ASSUME_EXPR`. The empty parenthesis means it takes no arguments. These will be evaluated in a local step, so you may use it to add things you `{!rsh} assume` about the values given by the API caller.
- Line 23 is the pay expression, it is set to zero, matching our previous function.
- Line 24 declares our `{!rsh} return` function `ret`.
- Line 25 invokes that `{!rsh} return`, sending `count` back to the caller.
- Line 26 updates our loop variable `count`.

A key difference now is the ability to specify different verification checks for the different Reach modes your function will go through.

You could have an `{!rsh} assume` expression that evaluates in the users local step and a different expression to `{!rsh} require` in a consensus step.

Read through both of these functions again, this time comparing syntax for the same operation in each function.

You see that `{!rsh} .api_` is an abstraction of `{!rsh} .api` with more compact syntax and `{!rsh} .api` allows you to specify different verification checks at different steps of the function.

Now that we are comfortable with the syntax -- let's look at accessing some values.

### .define your Views

The `{!rsh} parallelReduce` operates in a consensus step and the values that we are tracking are already publicly accessible.

To easily view any of our values, we should declare them as `{!rsh} Views` and include them in the `{!rsh} .define` block of our `{!rsh} parallelReduce`.

In the following examples from [rsvp-6-vevt](https://github.com/reach-sh/reach-lang/blob/master/examples/rsvp-6-vevt/index.rsh) we are tracking `howMany` users have called our `register` function.
```
load: /examples/rsvp-6-vevt/index.rsh
md5: ed7d96413f2f23224d5ea6081ae4cc78
range: 44-51
```
- Line 44 declares our loop variables.
- Line 45 initializes values for those variables inside our `{!rsh} parallelReduce`.
- Line 46 starts the `{!rsh} .define` block.
- Line 47 is where we set the `{!rsh} View` related to our value. In this case, `howMany` users have registered.
- Lines 49-50 are for our [loop invariants](##guide-loop-invs).
- Line 51 is our loop condition.

The `{!rsh} parallelReduce` is going to leave our DApp in a state where API members can call our function and update the values, but also allow `howMany` to be accesible in the frontend with a call to the `{!rsh} View`.

More information on accessing `{!rsh} Views` from the frontend can be found at `{!js} ctc.views`.

Now, what if we want the user to pay some amount to access this function?

## Pay the Pied ParallelReduce

For network tokens, we can just change the zero from our counter program to some amount.

In the following example from [ticket-sales](https://github.com/reach-sh/reach-lang/blob/master/examples/ticket-sales/index.rsh), the seller first sets some `cost` for the ticket and we include this for the `PAY_EXPR`.
```
load: /examples/ticket-sales/index.rsh
md5: 61303f7ea78ef9c44f41cb0a4e6e48a7
range: 29-36
```
- Line 31 is the outer `{!rsh} return` and will prompt the user to pay `cost` at their wallet interface to execute the consensus code.

In the [rsvp-6-vevt](https://github.com/reach-sh/reach-lang/blob/master/examples/rsvp-6-vevt/index.rsh) example, we ask the user to pay `reservation`.
```
load: /examples/rsvp-6-vevt/index.rsh
md5: ed7d96413f2f23224d5ea6081ae4cc78
range: 52-62
```
- Line 55 starts the outer `{!rsh} return` and asks the user to pay `reservation` before executing the consesus step.

All of our examples have so far demonstrated using network tokens. But what if you need the user to pay the contract in a non-network token?

#### Non-network Tokens

Any token that is not the native token of a protocol is considered a non-network token.

The gas or txn fees, are paid in network tokens.

Examples of non-network tokens include all Contract Tokens  on ETH (ERC20, ERC721, etc..) and all ASA Tokens on Algorand based networks.
@{seclink("guide-nntoks")}

First, we need to teach the Smart Contract about our non-network `{!rsh} Token`. This means providing it from the frontend (usually the Admin does this) -- and `{!rsh} publish`ing this token ID.

:::note
On ETH the token ID is an Address.
On Algorand it is a unique ID number.
:::

We will examine the [point-of-sale](https://github.com/reach-sh/reach-lang/blob/master/examples/point-of-sale/index.rsh) example for this.
```
load: /examples/point-of-sale/index.rsh
md5: 2d9202924ee606ab47726038fbde05a3
range: 19-24
```
- Line 19 starts a local step for `A`.
- Line 20 unpacks values from the frontend `params` object.
- Line 22 `{!rsh} publish`es these values to the blockchain.

:::note
We cannot attach the `{!rsh} A.pay([[supply, tok]])` to the first `{!rsh} publish` of the DApp. This is because the Smart Contract doesn't yet know of our token. We first need to complete a `{!rsh} publish` of the token ID.

Reach supports network tokens by default, which is why this constraint does not exist when paying network tokens.
:::

You may have noticed the syntactic Tuple in the `{!rsh} .pay`.

`{!rsh} Token` IDs and the amounts to be paid need to be specified in `{!rsh} Tuples`.

The first argument is the default network token and is synthesized for you, just specify the quantity -- if you leave the quantity out it will be synthesized to zero for you.

This means `{!rsh} A.pay([[supply, tok]])` is equal to `{!rsh} A.pay([0, [supply, tok]])`. Where zero specifies the number of network tokens.

This syntax will come up again.

This particular program sells these as loyalty tokens, but also allows the user to return the token in the event of a refund.

This means that our `{!rsh} parallelReduce` will need to *accept* these non-network tokens as payment in our API member function.
```
load: /examples/point-of-sale/index.rsh
md5: 2d9202924ee606ab47726038fbde05a3
range: 28-33
```
- Line 28 starts our `{!rsh} parallelReduce`.
- Line 29 is new. `{!rsh} .paySpec([tok])` tells our `{!rsh} parallelReduce` that it can also accept payment in this non-network token.

:::note
This is structured as an array, so you can just list out the other tokens seperated by a comma.

`{!rsh} .paySpec([tok1, tok2])`

Just be sure they have been `{!rsh} publish`ed and you have Reach `{!rsh} assume(tok1 != tok2)` for each token.
:::

```
load: /examples/point-of-sale/index.rsh
md5: 2d9202924ee606ab47726038fbde05a3
range: 34-45
```
- Line 34 specifies the `API_EXPR` and takes an input `purchasePrice` from the caller.
- Lines 35-37 perform various verification checks.
- Line 38 starts our outer `{!rsh} return`. This is where we need to specify the `PAY_EXPR`, but it also needs to account for our non-network token syntax. `[purchasePrice, [0, tok]]` has the user pay the `purchasePrice` in network tokens and zero of our non-network token.

Now let's accept our non-network token from the user in the event of a refund.
```
load: /examples/point-of-sale/index.rsh
md5: 2d9202924ee606ab47726038fbde05a3
range: 46-55
```
- Line 48 is our outer `{!rsh} return`. Notice the same syntax as the `purchase` function, but with different amounts. Now one `tok` is coming into the contract upon approval of the transaction.

Hopefully this guide has helped you better understand the `{!rsh} parallelReduce`.

If you still have questions, Reach out to us in [Discord](https://discord.gg/kbfNkdaMhD)!

repository: reach-sh/reach-lang

gha_language: Haskell

repo_name: reach-sh/reach-lang


text:
# A compatibility layer for `base`
[![Hackage](https://img.shields.io/hackage/v/base-compat.svg)][Hackage: base-compat]
[![Hackage Dependencies](https://img.shields.io/hackage-deps/v/base-compat.svg)](http://packdeps.haskellers.com/reverse/base-compat)
[![Haskell Programming Language](https://img.shields.io/badge/language-Haskell-blue.svg)][Haskell.org]
[![BSD3 License](http://img.shields.io/badge/license-MIT-brightgreen.svg)][tl;dr Legal: MIT]

[Hackage: base-compat]:
  http://hackage.haskell.org/package/base-compat
  "base-compat package on Hackage"
[Haskell.org]:
  http://www.haskell.org
  "The Haskell Programming Language"
[tl;dr Legal: MIT]:
  https://tldrlegal.com/license/mit-license
  "MIT License"

## Scope

The scope of `base-compat` is to provide functions available in later versions
of base to a wider (older) range of compilers.

In addition, successful library proposals that have been accepted to be part of
upcoming versions of `base` are also included.  This package is not intended to
replace `base`, but to complement it.

Note that `base-compat` does not add any orphan instances.  There is a separate
package [`base-orphans`](https://github.com/haskell-compat/base-orphans) for
that.

In addition, `base-compat` only backports functions. In particular, we
purposefully do not backport data types or type classes introduced in newer
versions of `base`. For more info, see the
[Data types and type classes](#data-types-and-type-classes)
section.

`base-compat` is intentionally designed to have zero dependencies. As a
consequence, there are some modules that can only be backported up to certain
versions of `base`. If an even wider support window is desired in these
scenarios, there also exists a `base-compat-batteries` package which augments
`base-compat` with certain compatibility package dependencies. For more info,
see the [Dependencies](#dependencies) section.

## Basic usage

In your cabal file, you should have something like this:

```
  build-depends:      base              >= 4.3
                    , base-compat       >= 0.9.0
```

Then, lets say you want to use the `isRight` function introduced with
`base-<IP_ADDRESS>`.  Replace:

```
import Data.Either
```

with

```
import Data.Either.Compat
```

_Note (1)_: There is no need to import both unqualified.  The `.Compat` modules
re-exports the original module.

_Note (2)_: If a given module `.Compat` version is not defined, that either
means that:

* The module has not changed in recent base versions, thus no `.Compat` is
  needed.
* The module has changed, but the changes depend on newer versions of GHC, and
  thus are not portable.
* The module has changed, but those changes have not yet been merged in
  `base-compat`: patches are welcomed!

## Using `Prelude.Compat`

If you want to use `Prelude.Compat` (which provides all the
AMP/Traversable/Foldable changes from `base-<IP_ADDRESS>`), it's best to hide
`Prelude`, e.g.:

    import Prelude ()
    import Prelude.Compat

    main :: IO ()
    main = mapM_ print (Just 23)

Alternatively, you can use the `NoImplicitPrelude` language extension:

    {-# LANGUAGE NoImplicitPrelude #-}
    import Prelude.Compat

    main :: IO ()
    main = mapM_ print (Just 23)

Note that we use

    mapM_ :: (Foldable t, Monad m) => (a -> m b) -> t a -> m ()

from `Data.Foldable` here, which is only exposed from `Prelude` since
`base-<IP_ADDRESS>`.

Using this approach allows you to write code that works seamlessly with all
versions of GHC that are supported by `base-compat`.

## What is covered
So far the following is covered.

### For compatibility with the latest released version of `base`

 * `Prelude.Compat` incorporates the AMP/Foldable/Traversable changes and
   exposes the same interface as `Prelude` from `base-<IP_ADDRESS>`
 * `System.IO.Error.catch` is not re-exported from `Prelude.Compat` for older
   versions of `base`
 * `Text.Read.Compat.readMaybe`
 * `Text.Read.Compat.readEither`
 * `Data.Monoid.Compat.<>`
 * Added `bitDefault`, `testBitDefault`, `popCountDefault`, `(.^.)`, `(.>>.)`,
   `(.<<.)`, `(!>>.)`, and `(!<<.)` to `Data.Bits.Compat`
 * Added `toIntegralSized` and `oneBits` to `Data.Bits.Compat` (if using `base-4.7` or later)
 * Added `bool` function to `Data.Bool.Compat`
 * Added `isLeft`, `isRight`, `fromLeft`, and `fromRight` to `Data.Either.Compat`
 * Added `forkFinally` to `Control.Concurrent.Compat`
 * Added `withMVarMasked` function to `Control.Concurrent.MVar.Compat`
 * Added `(<$!>)` function to `Control.Monad.Compat`
 * Weakened `RealFloat` constraints on `realPart`, `imagPart`, `conjugate`, `mkPolar`,
   and `cis` in `Data.Complex.Compat`
 * Added more efficient `maximumBy`/`minimumBy` to `Data.Foldable.Compat`
 * Added `($>)` and `void` functions to `Data.Functor.Compat`
 * `(&)` and `applyWhen` functions to `Data.Function.Compat`
 * `($>)` and `void` functions to `Data.Functor.Compat`
 * `modifyIORef'`, `atomicModifyIORef'` and `atomicWriteIORef` to `Data.IORef.Compat`
 * `dropWhileEnd`, `isSubsequenceOf`, `sortOn`, and `uncons` functions to `Data.List.Compat`
 * Correct versions of `nub`, `nubBy`, `union`, and `unionBy` to `Data.List.Compat`
 * `asProxyTypeOf` with a generalized type signature to `Data.Proxy.Compat`
 * `modifySTRef'` to `Data.STRef.Compat`
 * `String`, `lines`, `words`, `unlines`, and `unwords` to `Data.String.Compat`
 * `gcoerceWith` to `Data.Type.Coercion.Compat`
 * `makeVersion` function to `Data.Version.Compat`
 * `traceId`, `traceShowId`, `traceM`, `traceShowM`, `traceWith`,
   `traceShowWith`, and `traceEventWith` functions to `Debug.Trace.Compat`
 * `byteSwap16`, `byteSwap32`, and `byteSwap64` to `Data.Word.Compat`
 * `plusForeignPtr` to `Foreign.ForeignPtr.Compat`
 * `calloc` and `callocBytes` functions to `Foreign.Marshal.Alloc.Compat`
 * `callocArray` and `callocArray0` functions to `Foreign.Marshal.Array.Compat`
 * `fillBytes` to `Foreign.Marshal.Utils.Compat`
 * Added `Data.List.Compat.scanl'`
 * `showFFloatAlt`, `showGFloatAlt`, `readBin`, and `showBin` to `Numeric.Compat`
 * `lookupEnv`, `setEnv` and `unsetEnv` to `System.Environment.Compat`
 * `unsafeFixIO` and `unsafeDupablePerformIO` to `System.IO.Unsafe.IO`
 * `RuntimeRep`-polymorphic `($!)` to `Prelude.Compat`
 * `liftA2` is re-exported from `Prelude.Compat`
 * `RuntimeRep`-polymorphic `throw` to `Control.Exception.Compat`
 * `isResourceVanishedError`, `resourceVanishedErrorType`, and
   `isResourceVanishedErrorType` to `System.IO.Error.Compat`
 * `singleton` to `Data.List.Compat` and `Data.List.NonEmpty.Compat`
 * `inits1` and `tails1` to `Data.List.NonEmpty.Compat`
 * `hGetContents'`, `getContents'`, and `readFile'` to `System.IO.Compat`
 * `readBinP` to `Text.Read.Lex.Compat`
 * `withTypeable` and `pattern TypeRep` to `Type.Reflection.Compat`
 * `minusNaturalMaybe` to `Numeric.Natural.Compat`
 * `mapAccumM` and `forAccumM` to `Data.Traversable.Compat`
 * `heqT` to `Data.Typeable.Compat`

## What is not covered

### Data types and type classes
`base-compat` purposefully does not export any data types or type classes that
were introduced in more recent versions of `base`. The main reasoning for this
policy is that it is not some data types and type classes have had their APIs
change in different versions of `base`, which makes having a consistent
compatibility API for them practically impossible.

As an example, consider the `FiniteBits` type class. It was introduced in
[`base-<IP_ADDRESS>`](http://hackage.haskell.org/package/base-<IP_ADDRESS>/docs/Data-Bits.html#t:FiniteBits)
with the following API:

```haskell
class Bits b => FiniteBits b where
    finiteBitSize :: b -> Int
```

However, in [`base-<IP_ADDRESS>`](http://hackage.haskell.org/package/base-<IP_ADDRESS>/docs/Data-Bits.html#t:FiniteBits),
`FiniteBits` gained additional functions:

```haskell
class Bits b => FiniteBits b where
    finiteBitSize :: b -> Int
    countLeadingZeros :: b -> Int   -- ^ @since <IP_ADDRESS>
    countTrailingZeros :: b -> Int  -- ^ @since <IP_ADDRESS>
```

This raises the question: how can `FiniteBits` be backported consistently
across all versions of `base`? One approach is to backport the API exposed in
`base-<IP_ADDRESS>` on versions prior to `<IP_ADDRESS>`.  The problem with this is that
`countLeadingZeros` and `countTrailingZeros` are not exposed in `base-<IP_ADDRESS>`,
so instances of `FiniteBits` would have to be declared like this:

```haskell
instance FiniteBits Foo where
    finiteBitSize = ...
#if MIN_VERSION_base(4,8,0) || !(MIN_VERSION_base(4,7,0))
    countLeadingZeros = ...
    countTrailingZeros = ...
#endif
```

Another approach is to backport the API from `base-<IP_ADDRESS>` and to declare
additional methods outside of the class:

```haskell
#if MIN_VERSION_base(4,7,0) && !(MIN_VERSION_base(4,8,0))
countLeadingZeros :: FiniteBits b => b -> Int
countLeadingZeros = {- default implementation #-}
#endif
```

The situation is only slightly better for classes which exist across all versions of `base`,
but have grown their API. For example, it's tempting to define

```haskell
#if !(MIN_VERSION_base(4,8,0))
displayException :: Exception e => e -> String
displayException = show
#endif
```

As with the previous approach, you won't be able to define new members of the type
class without CPP guards. In other words, the non-CPP approach would limit
uses to the lowest common denominator.

As neither approach is a very satisfactory solution, and to embrace
consistency, we do not pursue either approach. For similar reasons, we do not
backport data types.

### Dependencies

`base-compat` is designed to have zero dependencies (besides libraries that
ship with GHC itself). A consequence of this choice is that there are certain
modules that have a "limited" support window. An important example of this is
`Prelude.Compat`, which backports the `Semigroup` class to versions of `base`
older than 4.11 (when it was added to the `Prelude`). Because `Semigroup` was
not added to `base` until `base-4.9`, `base-compat` cannot backport it to
any earlier version of `base` than this.

If you would instead desire to be able to use a version of `Prelude.Compat`
that _does_ backport `Semigroup` to even older versions of `base`, even if it
means pulling in other dependencies, then you are in luck. There also exists
a `base-compat-batteries` package, which exposes a strict superset of the API
in `base-compat`. `base-compat-batteries` has all the same modules as
`base-compat`, but exposes more functionality on more versions of `base` by
reexporting things from compatibility libraries whenever necessary. (For
instance, `base-compat-batteries` exports the `Semigroup` class from the
`semigroups` library when built against versions of `base` older than 4.9.)

Because `base-compat` and `base-compat-batteries` have the same module names,
they are quite easy to switch out for one another in library projects, at the
expense of having clashing names if one tries to import them in GHCi. To
work around this issue, `base-compat` and `base-compat-batteries` also provide
copies of each module with the suffix `.Repl` (for `base-compat`) and
`.Repl.Batteries` (for `base-compat-batteries`) to give them globally unique
namespaces in the event one wants to import them into GHCi.

Here is a list of compatibility libraries that `base-compat-batteries` depends
on, paired with the things that each library backports:

* [`bifunctor-classes-compat`](http://hackage.haskell.org/package/bifunctor-classes-compat)
  for:
  * The [`Bifunctor`](http://hackage.haskell.org/package/base-<IP_ADDRESS>/docs/Data-Bifunctor.html#t:Bifunctor)
    type class, introduced in `base-<IP_ADDRESS>`
  * The [`Bifoldable`](http://hackage.haskell.org/package/base-<IP_ADDRESS>/docs/Data-Bifoldable.html#t:Bifoldable)
    and [`Bitraversable`](http://hackage.haskell.org/package/base-<IP_ADDRESS>/docs/Data-Bitraversable.html#t:Bitraversable)
    type classes, introduced in `base-<IP_ADDRESS>`
* [`contravariant`](http://hackage.haskell.org/package/contravariant)
  for the [`Contravariant`](http://hackage.haskell.org/package/base-<IP_ADDRESS>/docs/Data-Functor-Contravariant.html#t:Contravariant)
  type class, introduced in `base-<IP_ADDRESS>`.
* [`fail`](http://hackage.haskell.org/package/fail)
  for the [`MonadFail`](http://hackage.haskell.org/package/base-<IP_ADDRESS>/docs/Control-Monad-Fail.html#t:MonadFail)
  type class, introduced in `base-<IP_ADDRESS>`
* [`foldable1-classes-compat`](https://hackage.haskell.org/package/foldable1-classes-compat)
  for the [`Foldable1`](https://hackage.haskell.org/package/foldable1-classes-compat-0.1/docs/Data-Foldable1.html#t:Foldable1)
  and [`Bifoldable1`](https://hackage.haskell.org/package/foldable1-classes-compat-0.1/docs/Data-Bifoldable1.html#t:Bifoldable1)
  type classes, introduced in `base-<IP_ADDRESS>`
* [`nats`](http://hackage.haskell.org/package/nats)
  for the [`Natural`](http://hackage.haskell.org/package/base-<IP_ADDRESS>/docs/Numeric-Natural.html)
  data type, introduced in `base-<IP_ADDRESS>`
* [`OneTuple`](http://hackage.haskell.org/package/OneTuple)
  for the [`Solo`](https://hackage.haskell.org/package/base-<IP_ADDRESS>/docs/Data-Tuple.html#t:Solo)
  data type, introduced in `ghc-prim-0.7.0`
* [`semigroups`](http://hackage.haskell.org/package/semigroups)
  for the [`Semigroup`](http://hackage.haskell.org/package/base-<IP_ADDRESS>/docs/Data-Semigroup.html#t:Semigroup)
  typeclass and the
  [`NonEmpty`](http://hackage.haskell.org/package/base-<IP_ADDRESS>/docs/Data-List-NonEmpty.html#t:NonEmpty),
  [`Min`](http://hackage.haskell.org/package/base-<IP_ADDRESS>/docs/Data-Semigroup.html#t:Min),
  [`Max`](http://hackage.haskell.org/package/base-<IP_ADDRESS>/docs/Data-Semigroup.html#t:Max),
  [`First`](http://hackage.haskell.org/package/base-<IP_ADDRESS>/docs/Data-Semigroup.html#t:First),
  [`Last`](http://hackage.haskell.org/package/base-<IP_ADDRESS>/docs/Data-Semigroup.html#t:Last),
  [`WrappedMonoid`](http://hackage.haskell.org/package/base-<IP_ADDRESS>/docs/Data-Semigroup.html#t:WrappedMonoid),
  [`Option`](http://hackage.haskell.org/package/base-<IP_ADDRESS>/docs/Data-Semigroup.html#t:Option),
  and
  [`Arg`](http://hackage.haskell.org/package/base-<IP_ADDRESS>/docs/Data-Semigroup.html#t:Arg)
  data types, introduced in `base-<IP_ADDRESS>`
* [`tagged`](http://hackage.haskell.org/package/tagged)
  for the [`Proxy`](http://hackage.haskell.org/package/base-<IP_ADDRESS>/docs/Data-Proxy.html#t:Proxy)
  data type, introduced in `base-<IP_ADDRESS>`
* [`transformers`](http://hackage.haskell.org/package/transformers)
  for:
  * The [`Identity`](http://hackage.haskell.org/package/base-<IP_ADDRESS>/docs/Data-Functor-Identity.html#t:Identity)
    data type, introduced in `base-<IP_ADDRESS>`
  * The [`MonadIO`](http://hackage.haskell.org/package/base-<IP_ADDRESS>/docs/Control-Monad-IO-Class.html#t:MonadIO)
    type class; and the
    [`Compose`](http://hackage.haskell.org/package/base-<IP_ADDRESS>/docs/Data-Functor-Compose.html#t:Compose),
    [`Product`](http://hackage.haskell.org/package/base-<IP_ADDRESS>/docs/Data-Functor-Product.html#t:Product),
    and
    [`Sum`](http://hackage.haskell.org/package/base-<IP_ADDRESS>/docs/Data-Functor-Sum.html#t:Sum)
    data types, introduced in `base-<IP_ADDRESS>`
* [`void`](http://hackage.haskell.org/package/void)
  for the [`Void`](http://hackage.haskell.org/package/base-<IP_ADDRESS>/docs/Data-Void.html#t:Void)
  data type, introduced in `base-<IP_ADDRESS>`

## Version policy

This package follows the [Haskell Package Versioning
Policy](https://pvp.haskell.org/). As such, if a new `base-compat` release only
adds new exports, then as a general rule, we will release it with a minor
version bump. Moreover, since `base-compat` does not backport data type or
class definitions (see the "What is not covered" section above), `base-compat`
usually has fewer major version bumps than `base` itself.

An exception to the general rule about adding new exports is the
`Prelude.Compat` module. If a new `base-compat` release adds any new exports,
then it will _always_ be accompanied by a major version bump, even if there are
no other API changes. This is because of the special nature of
`Prelude.Compat`, which is designed to be imported unqualified. Pre-emptively
bumping the major version number is meant to signal to downstream libraries
that they should check to see if the new `Prelude.Compat` additions will clash
with identifiers of the same names in their code.

## Supported versions of GHC/`base`

 * `ghc-9.6.*`  / `base-4.18.*`
 * `ghc-9.4.*`  / `base-4.17.*`
 * `ghc-9.2.*`  / `base-4.16.*`
 * `ghc-9.0.*`  / `base-4.15.*`
 * `ghc-8.10.*` / `base-4.14.*`
 * `ghc-8.8.*`  / `base-4.13.*`
 * `ghc-8.6.*`  / `base-4.12.*`
 * `ghc-8.4.*`  / `base-4.11.*`
 * `ghc-8.2.*`  / `base-4.10.*`
 * `ghc-8.0.*`  / `base-4.9.*`
 * `ghc-7.10.*` / `base-4.8.*`
 * `ghc-7.8.*`  / `base-4.7.*`
 * `ghc-7.6.*`  / `base-4.6.*`
 * `ghc-7.4.*`  / `base-4.5.*`
 * `ghc-7.2.*`  / `base-4.4.*`
 * `ghc-7.0.*`  / `base-4.3.*`

We also make an attempt to keep `base-compat` building with GHC HEAD, but due
to its volatility, it may not work at any given point in time. If it doesn't,
please report it!

Patches are welcome; add tests for new code!

repository: haskell-compat/base-compat

extension: markdown

repo_name: haskell-compat/base-compat


text:
---
title: New Kern Lab Publication
author: Renee Otten
layout: post
group: news
---

Congratulations to shared first-authors John Stiller and Jordan Kerns (and all others involved) with their publication entitled Probing the Transition State in Enzyme Catalysis by High-Pressure NMR Dynamics. Available today, ahead of print, at the website of *Nature Catalysis* - unfortunately Brandeis University does not provide access to this masterpiece.....