andrewthad

{-# language BangPatterns #-}
{-# language MagicHash #-}
{-# language UnboxedTuples #-}

{-# OPTIONS_GHC -O2 -Wall -fforce-recomp #-}

import GHC.Exts
import GHC.IO (IO(..))
import System.Mem (performMajorGC)

andrewthad

#include <stdio.h>
#include <stdint.h>
#include <unistd.h>
#include <inttypes.h>

int main () {
  FILE *file = NULL;
  uint64_t buffer[1];  // array of bytes, not pointers-to-bytes
  size_t bytesRead = 0;

andrewthad

==================== Tidy Core ====================

Result size of Tidy Core
  = {terms: 1,859, types: 3,380, coercions: 2,902, joins: 12/46}

-- RHS size: {terms: 22, types: 60, coercions: 32, joins: 0/0}
produceRequest1
produceRequest1
  = \ s1_asVO ->

andrewthad

Discerning the Zookeeper Protocol

To write a zookeeper client, it is neccessary to understand the protocol used to communicate with it. Unfortunately, this protocol is not documented. In this example, we use tcpflow to dump both the read and write channel of the TCP connection that zkCli.sh uses to connect with the zookeeper server.

Requests

andrewthad

{-# language BangPatterns #-}
{-# language MagicHash #-}
{-# language UnboxedTuples #-}

import GHC.Exts
import GHC.IO (IO(..))
import Control.Exception (SomeException,toException)
import System.IO.Error (userError)

main :: IO ()

andrewthad

Strictness in Kinds

Let's tweak GHC's RuntimeRep stuff to try adding information about strictness. This information could be helpful for avoiding evaluating thunks that are guaranteed to already be evaluated. Presently, RuntimeRep is defined as:

data RuntimeRep

= LiftedRep

andrewthad

[1 of 1] Compiling T16391a          ( T16391a.hs, T16391a.o )
checkFamInstConsistency [Data.Kind, Prelude]
Tc2 (src)
Tc3
tcExtendKindEnvList []
tcExtendKindEnvList []
---- tcTyClGroup ---- {
Decls for [Const]
tcExtendKindEnv [rs4 :-> APromotionErr TyConPE]
---- kcTyClGroup ---- {

andrewthad

I'd like to write a library kind of like sockets except that it would be used for dealing with named/unnamed unix pipes instead. The interface would be really similar. One big question is "how does the whole blocking/nonblocking thing work"? It doesn't work at all for regular files in linux but it works great for sockets. If you hook a pipe (like stdin or stdout) up to a file descriptor, does it always show it being ready, or does it work correctly? Pipes provide some kind of buffering, so maybe it works, but maybe it doesn't. I don't know. On linux, libuv always uses blocking IO when dealing with stdout. This is documented at http://nodejs.org/dist/v0.10.26/docs/api/process.html#process_process_stdout, but I do not understand why it was done. The IO manager that GHC ships with base requires some weirdness to get file descriptors to work nicely. It sometimes uses blocking IO and sometimes nonblocking IO depending on the threaded/nonthreaded runtime and on whether or not the file descriptor was created by the 

andrewthad

-- This is a hypothetical API that extends the ST with an alternative to
-- runST. The alternative can be described as a "deep freeze". It calls
-- performs an in-place freeze on many variables at once. Surprisingly,
-- this API is safer than the API provided by the existing functions
-- that unsafely freeze mutable arrays.
--
-- The first step is merging lifted and unlifted arrays into a single
-- data type. Instead of:

data FooArray# :: TYPE 'UnliftedRep

andrewthad

{-# language DataKinds #-}
{-# language GADTs #-}
{-# language KindSignatures #-}
{-# language MagicHash #-}
{-# language RankNTypes #-}
{-# language ScopedTypeVariables #-}
{-# language TypeFamilies #-}

-- | This is a module illustrating an approach to allow concurrently-running
--   client to interact with a resource that does not support concurrent