| pragma solidity ^0.4.15; | |
| contract StringsAndBytes { | |
| /* --- public variables for storing tests results */ | |
| string public lastTestStringResult; // | |
| bytes32 public lastTestBytes32Result; // | |
| bytes public lastTestBytesResult; // bytes: dynamically-sized byte array | |
| bool public lastTestBoolResult; // |
Sometimes you want to have a subdirectory on the master branch be the root directory of a repository’s gh-pages branch. This is useful for things like sites developed with Yeoman, or if you have a Jekyll site contained in the master branch alongside the rest of your code.
For the sake of this example, let’s pretend the subfolder containing your site is named dist.
Remove the dist directory from the project’s .gitignore file (it’s ignored by default by Yeoman).
A Ricardian Contract can be defined as a single document that is a) a contract offered by an issuer to holders, b) for a valuable right held by holders, and managed by the issuer, c) easily readable by people (like a contract on paper), d) readable by programs (parsable like a database), e) digitally signed, f) carries the keys and server information, and g) allied with a unique and secure identifier.
- Ian Grigg
The Ricardian contract is a means of tracking the liability of one party to another when selling goods to each other in OpenBazaar. Fundamentally, a contract represents a single unit of a good or service. Ricardian contracts should be used in OpenBazaar as they are means of effectively tracking legitimately signed agreements between two parties, which cannot be forged afte
| { | |
| // Truffle tasks for Visual Studio Code | |
| // See https://go.microsoft.com/fwlink/?LinkId=733558 | |
| // for the documentation about the tasks.json format | |
| "version": "0.1.0", | |
| "command": "truffle", | |
| "isShellCommand": true, | |
| "args": [], | |
| "showOutput": "always", | |
| "echoCommand": true, |
This gist shows how formal conditions of Solidity smart contracts can be automatically verified even in the presence of potential re-entrant calls from other contracts.
Solidity already supports formal verification of some contracts that do not make calls to other contracts. This of course excludes any contract that transfers Ether or tokens.
The Solidity contract below models a crude crowdfunding contract that can hold Ether and some person can withdraw Ether according to their shares. It is missing the actual access control, but the point that wants to be made
| setBadge = function (text) { | |
| if (process.platform === "darwin") { | |
| app.dock.setBadge("" + text); | |
| } else if (process.platform === "win32") { | |
| var win = remote.getCurrentWindow(); | |
| if (text === "") { | |
| win.setOverlayIcon(null, ""); | |
| return; | |
| } |
There are a lot of ways to serve a Go HTTP application. The best choices depend on each use case. Currently nginx looks to be the standard web server for every new project even though there are other great web servers as well. However, how much is the overhead of serving a Go application behind an nginx server? Do we need some nginx features (vhosts, load balancing, cache, etc) or can you serve directly from Go? If you need nginx, what is the fastest connection mechanism? This are the kind of questions I'm intended to answer here. The purpose of this benchmark is not to tell that Go is faster or slower than nginx. That would be stupid.
So, these are the different settings we are going to compare:
This is a compilation of various open-source Unity plugins, codebases, or utility scripts that may aid in expediting the development process.
"ProbePolisher is a Unity Editor plugin for editing light probes. It works both on Unity Basic (free) and Unity Pro."
