Leandro Ostera leostera

Following is my mental journey and interaction with ocaml tooling as a newb. It's not meant as a negative criticism, but a form of constructive feedback. Part of the confusion may be caused by my own skill issues. Hopefully this serves as a case study of areas that could be streamlined or better documented.

Esy

So it appears I can make an ocaml/reason project with npm. Great! It's kind confusing. Dependencies are not really npm dependencies, but are in the package.json? Npm install doesn't work with them inside? Ah. It kinda just executes esy via npm, which runs opam under the hood? Maybe I'll try the "native" way with opam/dune directly...

Blockchain of blockchains with RSA public keys for resource registry (domain + intents/messages accepted)
Go down from HTTP/WS to have a simpler/more essential protocol for communication. Protocol not based on simple human analogies (verb, noun)
Protocol is (hopefully) implementation of Real OOP.
External resources in the language are represented with URLs
Discovery/caching decisions (URL resolution) is delegated to the runtime
Runtime should eventually be a hypervisor that only manages resource allocation. Or dedicated hardware, programs for FPGA. High level functional language for FPGA programming.
Language is expressed in an AST. AST can be formatted in different transport encodings (JSON for example).
Language is just representation of category theory operations between the resources, assuming they fulfillthe expected types.
Language is lazy and asynchonous by default. Tagline: "sync is just async that works very fast"
Under the hood, operations are Real OOP (messages)

Automatically retries until all three checks are solved

It starts out with:

const initialState = {
  checks: {
    one: undefined,
    two: undefined,
 three: undefined

General notes

nix-channel and ~/.nix-defexpr are gone. We'll use $NIX_PATH (or user environment specific overrides configured via nix set-path) to look up packages. Since $NIX_PATH supports URLs nowadays, this removes the need for channels: you can just set $NIX_PATH to e.g. https://nixos.org/channels/nixos-15.09/nixexprs.tar.xz and stay up to date automatically.
By default, packages are selected by attribute name, rather than the name attribute. Thus nix install hello is basically equivalent to nix-env -iA hello. The attribute name is recorded in the user environment manifest and used in upgrades. Thus (at least by default) hello won't be upgraded to helloVariant.

@vcunat suggested making this an arbitrary Nix expression rather than an attrpath, e.g. firefox.override { enableFoo = true; }. However, such an expression would not have a key in the user environment, unlike an attrpath. Better to require an explicit flag for this.

TBD: How to deal with search path clashes.

TL;DR

Create 5GB FreeBSD image.
Install FreeBSD on xhyve.
Mount host directory.

Requisites

Simple collection of Groovy scripts to help me maintain some Jenkins systems.

See also https://wiki.jenkins-ci.org/display/JENKINS/Jenkins+Script+Console

Please comment & let me know if you have a fork / fixes you'd like to include.

On the Viability of Erlang Releases and CouchDB

There has been some discussion on what versions of Erlang CouchDB should support, and what versions of Erlang are detrimental to use. Sadly there were some pretty substantial problems in the R15 line and even parts of R16 that are landmines for CouchDB. This post will describe the current state of things and make some potential recommendations on approach.

	#!/usr/bin/awk -f

	# This program is a copy of guff, a plot device. https://github.com/silentbicycle/guff
	# My copy here is written in awk instead of C, has no compelling benefit.
	# Public domain. @thingskatedid

	# Run as awk -v x=xyz ... or env variables for stuff?
	# Assumptions: the data is evenly spaced along the x-axis

	# TODO: moving average

	/*
	OUTLINE FOR AN APP BUILT WITH RXJS AND REACT, USING AN ELASTICSEARCH FACETED SEARCH
	MODULE AS AN EXAMPLE, READ FROM BOTTOM UP IF YOU WANT TO GO OUTSIDE IN, START FROM
	TOP TO SEE HOW THE SEARCH MODULE IS COMPOSED.

	If you find this I would love to hear some feedback - it's not designed to work without
	any modification though, it's just supposed to outline the architecture off-the-top-of-
	my-head-pretty-close-to-working psuedocode of something that you might actually need to
	build to drive out if the pattern is any good!
	*/

	# The idea is that (even for an async relationship) we have available either
	# the related object, or the as-of-yet not unserialized reference to that
	# object. In the latter case, we can use directly.
	#
	# This avoids possible generation of more server requests for related
	# objects while saving a given object.
	#
	# Issues:
	#
	# 1) Potentially, the not-unserialized reference could be in a different

Leandro Ostera leostera

Esy

General notes

TL;DR

Requisites

On the Viability of Erlang Releases and CouchDB

Scheduler Collapse