Now that we live in the Big Data, Web 3.14159 era, lots of people want to build databases that are too big to fit on a single machine. But there's a problem in the form of the CAP theorem, which states that if your network ever partitions (a machine goes down, or part of the network loses its connection to the rest) then you can keep consistency (all machines return the same answer to
{-# LANGUAGE BangPatterns, ScopedTypeVariables #-} | |
-- Stuff taken from the RSA module for now | |
module Primes where | |
import Data.Bits | |
import Data.Int | |
import Data.Word | |
import Data.ByteString.Lazy (ByteString) |
# Assumes you have a np.array((height,width,3), dtype=float) as your HDR image | |
import numpy as np | |
f = open("xxx.hdr", "wb") | |
f.write("#?RADIANCE\n# Made with Python & Numpy\nFORMAT=32-bit_rle_rgbe\n\n") | |
f.write("-Y {0} +X {1}\n".format(image.shape[0], image.shape[1])) | |
brightest = np.maximum(np.maximum(image[...,0], image[...,1]), image[...,2]) | |
mantissa = np.zeros_like(brightest) |
-- | |
-- Hello-World of the cordova/phonegap application using Haskell. | |
-- | |
-- here is the screenshoot | |
-- | |
-- https://twitter.com/AGoCorona/status/532948528621178880 | |
-- | |
-- So that Haste-Haskell can be used to create hybrid smartphone applications | |
-- | |
-- The original cordova JavaScript hello world is installed following the instructions of this page |
{-# LANGUAGE ConstraintKinds #-} | |
{-# LANGUAGE DataKinds #-} | |
{-# LANGUAGE PolyKinds #-} | |
{-# LANGUAGE FlexibleContexts #-} | |
{-# LANGUAGE FlexibleInstances #-} | |
{-# LANGUAGE GADTs #-} | |
{-# LANGUAGE KindSignatures #-} | |
{-# LANGUAGE MultiParamTypeClasses #-} | |
{-# LANGUAGE OverloadedStrings #-} | |
{-# LANGUAGE RankNTypes #-} |
Disclaimer 1: Type classes are great but they are not the right tool for every job. Enjoy some balance and balance to your balance.
Disclaimer 2: I should tidy this up but probably won’t.
Disclaimer 3: Yeah called it, better to be realistic.
Type classes are a language of their own, this is an attempt to document features and give a name to them.
Having seen @pirapira's sketch of Bamboo ( https://github.com/pirapira/bamboo/ ), which proposed to add better control about the "smart contract program flow", even across calls, I thought that this should certainly be added to Solidity, and actually, it might even be possible now to a certain degree using inline assembly.
The problem is that with many functions in a contract, it is not always clear which can be called at which stage in the contract's lifetime. Certain smart contracts would be easier to understand if written as follows:
pragma solidity ^0.4.2; | |
contract ethernalSale { | |
struct order { | |
uint amount; | |
address buyer; | |
} | |
mapping (uint => order) orderBook; | |
mapping (address => uint) balanceOf; |
{-# LANGUAGE TypeOperators #-} | |
{-# LANGUAGE GeneralizedNewtypeDeriving #-} | |
import Control.Applicative | |
import Data.Char | |
import Data.List (intersperse) | |
import Data.Monoid hiding (All, Any) | |
import Data.Foldable hiding (all, any) | |
import Prelude hiding (all, any) |