Denis Defreyne denisdefreyne

At the moment of writing (May 4th, 2015), nanoc 4 hasn’t been significantly worked on for over a year. This is not because nanoc 4 is dead, but it does have its reasons:

The nanoc 4.0 code has diverged so much from the nanoc 3.x master branch that automatic merges are virtually impossible, and manual merges are incredibly difficult. For a while, nanoc 4 has progressed independently of nanoc 3.x, but that made them grow even further apart.
The nanoc 4.0 prototype does not solve the main issues I wanted to tackle in nanoc 4. The two goals of nanoc 4 were to havey a highly accurate dependency tracking mechanism that prevents recompilation in far more cases than currently possible, and to be scalable to at least tens of thousands of pages and assets.

Clearly, the current development approach for nanoc 4.x is not working. At the same time, work on nanoc 3.x is increasingly more difficult due to the backwards compatibility constraint (which has been kept up for nearly six years!).

My current idea for gettin

Using a glob, such as /changes/**/* or /about.*, to search for paths is O(1) without optimisations. For large collections of paths, this becomes a bottleneck for certain operations.

Constructing a prefix tree for all paths could be useful for speeding up glob matching. For instance, take the following paths:

/index.md
/changes.html
/about.md
/about/cat.md
/about/calf.md

Nanoc’s current way of writing helpers involves writing a module, and then #include-ing it in the current context. This approach works, but is limiting for the following reasons:

Once a helper is included, it is available everywhere. You can even call them as methods on @item, @config, … etc, even when they don’t make use of the object.
A helper’s methods are all available, even when they are marked as private. This makes it impossible to define internal methods on a helper.

In the file below, you’ll find a DSL for writing helpers in Nanoc. It tackles the second problem by exposing an #export method that defines which methods inside the helper are intended to be public. The call to #use later on will make these methods available; methods not marked with #export will not be available.

This is an experiment in writing an API that feels imperative, but is backed by immutable objects. It relies on Hamster, but could easily be replaced with something else.

Caution: I’m unsure about the terminology. I’m calling these zippers, but I’m not sure this is what they are.

For example, create a structure of hashes and arrays:

hash = Hamster::Hash.new({ animal: 'donkey', stuff: Hamster::Hash.new({ foo: Hamster::Vector.new([1]) }) })

	module Foo
	def bar
	123
	end
	end

	include Foo

	class Person
	def initialize

	#!/usr/bin/env zsh

	source ~/.profile
	source ~/.zshrc-local

	########## ZSH STUFF

	autoload -U colors && colors

	########## HISTORY

	# Let’s reimplement methods on arrays in Ruby in a purely functional way!
	#
	# Rules:
	#
	# 1. On a list,
	# … you can call #empty?
	# … you can call #first
	# … you can call #drop with 1
	# … you can call #+
	# … you cannot call any other method!

	check :consistent_headers do
	@items.each do \|item\|
	path = item.reps[:default].raw_path
	next if path !~ /\.html$/

	headers = Nokogiri::HTML(File.read(path)).css('h1, h2, h3, h4, h5, h6')
	depths = headers.map { \|n\| n.name.sub(/^h/, '').to_i }

	h1_count = depths.count { \|d\| d == 1 }
	if h1_count > 1

	#include <stdio.h>
	#include <string.h>
	#include <ao/ao.h>
	#include <math.h>

	#define RATE 8800

	float lfo_01(float t, float speed) {
	return (sin(t * speed) + 1.0) / 2.0;
	}