cician

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...

katef

#!/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

xaviervia

• 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)

xaviervia

Automatically retries until all three checks are solved

It starts out with:

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

edolstra

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.

tanb

TL;DR

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

Requisites

• OSX
• Homebrew
• xhyve

oscarduignan

/*
  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!
*/

dnozay

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.

chewbranca

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.

Scheduler Collapse

shaunc

# 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