Research shaders for compositor ops

This reverts commit 618f09689d.

.gitignore

@@ -1 +1,13 @@
-scratchpad/
+build
+compile_commands.json
+.vscode
+*.dSYM
+assets/shaders
+scratchpad/**
+!scratchpad/**/
+!scratchpad/**/*.h
+!scratchpad/**/*.hh
+!scratchpad/**/*.hpp
+!scratchpad/**/*.c
+!scratchpad/**/*.cc
+!scratchpad/**/*.cpp

.gitmodules

@@ -0,0 +1,3 @@
+[submodule "src/vendor/ktx"]
+	path = src/vendor/ktx
+	url = https://github.com/KhronosGroup/KTX-Software

.opencode/skills/prism-dag/SKILL.md

@@ -0,0 +1,56 @@
+---
+name: prism-dag
+description: DAG / graph patterns for Prism — adjacency list rules, arena allocation, Kahn's algorithm, flat buffer layout
+license: MIT
+compatibility: opencode
+metadata:
+  domain: core
+---
+## What I do
+
+Captures the conventions for Prism's directed acyclic graph (DAG) implementation: how edges are stored, how the graph is validated, and how to avoid common pitfalls.
+
+## When to use me
+
+Use this when working on graph/DAG structures (`pr_graph.h`, `pr_graph.c`, or `scratchpad/dag.c`), adding new node types, or modifying the topological sort / cycle detection logic.
+
+## Conventions
+
+### Adjacency lists — separate edge nodes
+
+Adjacency list nodes must be **separately allocated from the vertex array**. Never use the vertex struct itself as a linked-list node in another vertex's adjacency chain — that shares the `next` pointer between two roles and corrupts the graph.
+
+```c
+// correct — per-edge copy on the arena
+static void addEdge(PrGraph *g, const WpAllocator *alloc, u64 from, u64 to) {
+	PrVertex *src = &g->vertices[from];
+	PrVertex *dst = wpMemAllocatorAlloc(alloc, sizeof(PrVertex));
+	if (!dst) { /* handle OOM */ return; }
+	dst->id    = g->vertices[to].id;
+	dst->value = g->vertices[to].value;
+	dst->next  = src->next;
+	src->next  = dst;
+}
+
+// wrong — reuses the destination vertex as the list node
+static void addEdge_bad(PrGraph *g, u64 from, u64 to) {
+	PrVertex *src  = &g->vertices[from];
+	PrVertex *dest = &g->vertices[to];
+	dest->next = src->next;
+	src->next  = dest;   // overwrites dest->next used elsewhere
+}
+```
+
+Arena bump allocation (`wpMemAllocatorAlloc`) is the natural fit for edge nodes. Always NULL-check the result — arena allocators can fail if the backing buffer is exhausted.
+
+### Flat buffer layout
+
+For hot-path graph evaluation, prefer SoA layouts and keep the DAG in contiguous arrays rather than individually allocated linked structures.
+
+### Cycle detection
+
+Use Kahn's algorithm integrated into `prGraphAddEdge` for cycle detection with rollback. When an edge would create a cycle, the edge is not added and the function returns an error.
+
+### Memory management
+
+Stack-allocate where possible; pass `WpAllocator *` explicitly for heap allocations.

.opencode/skills/prism-rhi/SKILL.md

@@ -0,0 +1,163 @@
+---
+name: prism-rhi
+description: RHI (Rendering Hardware Interface) patterns — compile-time dispatch, by-value desc structs, wapp array aliases, backend file layout
+license: MIT
+compatibility: opencode
+metadata:
+  domain: rendering
+---
+## What I do
+
+Captures the RHI conventions for Prism: how backends are dispatched, how descriptor structs and arrays are handled, and how the files are organized.
+
+## When to use me
+
+Use this when working on any file in `src/prism/rhi/`, or when creating a new backend (Vulkan, D3D12, Metal).
+
+## Conventions
+
+### Global context
+
+RHI functions do **not** take allocator parameters. A global `PrRhiContext` provides two allocators:
+- `allocator` — for user-facing objects (buffers, textures, pipelines, etc.)
+- `tmp` — for short-lived internal temporaries
+
+```c
+extern PrRhiContext _G_RHI_CONTEXT;
+
+void prRhiInit(void);   // sets up both allocators
+void prRhiDestroy(void); // tears down context
+```
+
+All RHI functions access `_G_RHI_CONTEXT` directly. Do not pass allocators to RHI API calls.
+
+### Backend dispatch
+
+Backend selection is compile-time via `-D PR_RHI_VULKAN` / `-D PR_RHI_D3D12` / `-D PR_RHI_METAL`. The umbrella header `pr_rhi.h` includes the appropriate alias file:
+
+```c
+#if defined(PR_RHI_VULKAN)
+#  include "vulkan/pr_rhi_vk_aliases.h"
+#elif defined(PR_RHI_D3D12)
+#  include "d3d12/pr_rhi_d3d12_aliases.h"
+#elif defined(PR_RHI_METAL)
+#  include "metal/pr_rhi_metal_aliases.h"
+#else
+#  error "Define one of: PR_RHI_VULKAN, PR_RHI_D3D12, PR_RHI_METAL"
+#endif
+```
+
+Each `_aliases.h` file maps generic names to backend-specific names:
+
+```c
+#define prRhiCreateDevice       prRhiCreateDeviceVk
+#define prRhiCreateSwapchain    prRhiCreateSwapchainVk
+#define prRhiCreateBuffer       prRhiCreateBufferVk
+// …
+```
+
+Backend implementations are suffixed with the backend name: `pr_rhi_vk_device.c`, `pr_rhi_vk_swapchain.c`, etc.
+
+### Desc structs
+
+All descriptor structs are passed **by value**, not `const *`:
+
+```c
+// correct
+PrRhiDevice *prRhiCreateDevice(PrRhiPhysicalDevice *pdev, PrRhiSurface *surface, PrRhiDeviceDesc desc);
+
+// wrong
+PrRhiDevice *prRhiCreateDevice(PrRhiPhysicalDevice *pdev, PrRhiSurface *surface, const PrRhiDeviceDesc *desc);
+```
+
+### Frame-by-frame command batching
+
+Commands that run every frame must avoid arena allocation. Use stack arrays with a while-loop to batch operations:
+
+```c
+// correct — stack array, batched submission
+void prRhiCmdBindDescriptorSetsVk(PrRhiCommandBuffer *cb, PrRhiPipelineBindPoint bind_point,
+                                  PrRhiPipelineLayout *layout, u32 first_set,
+                                  PrRhiDescriptorSetArray sets) {
+	u32 set_count = sets ? (u32)wpArrayCount(sets) : 0;
+	while (set_count > 0) {
+		VkDescriptorSetArray vk_sets = wpArrayWithCapacity(VkDescriptorSet, 16, WP_ARRAY_INIT_FILLED);
+		u32 total_capacity = (u32)wpArrayCapacity(vk_sets);
+		u32 real_count = set_count < total_capacity ? set_count : total_capacity;
+		for (u32 i = 0; i < real_count; ++i) {
+			vk_sets[i] = sets[i]->handle;
+		}
+		vkCmdBindDescriptorSets(cb->handle, vk_bp, vk_layout, first_set, real_count, vk_sets, 0, NULL);
+		set_count -= real_count;
+		first_set += real_count;
+	}
+}
+
+// wrong — allocates from arena on every call
+void prRhiCmdBindDescriptorSetsBad(PrRhiCommandBuffer *cb, ...) {
+	VkDescriptorSetArray vk_sets = wpArrayAllocCapacity(VkDescriptorSet, &_G_RHI_CONTEXT.allocator, count, ...);
+	// ... this leaks every frame
+}
+```
+
+Apply this pattern to: `prRhiCmdBindDescriptorSets`, `prRhiCmdBindVertexBuffers`, `prRhiCmdCopyBufferToImage`, and any other command that processes user-provided arrays.
+
+### Opaque struct handles — no casts
+
+Handle types in opaque structs are already the correct Vulkan type. Do not cast:
+
+```c
+// correct
+vk_device = device->handle;
+vk_buffer = buffer->handle;
+
+// wrong
+vk_device = (VkDevice)device->handle;
+vk_buffer = (VkBuffer)buffer->handle;
+```
+
+### Vulkan struct initialisation — designated initializers
+
+Always use C99 designated initializers for Vulkan info structs:
+
+```c
+// correct
+VkBufferCreateInfo buf_info = {
+    .sType = VK_STRUCTURE_TYPE_BUFFER_CREATE_INFO,
+    .size  = desc.size,
+    .usage = _toVkBufferUsage(desc.usage),
+};
+
+// wrong
+VkBufferCreateInfo buf_info = {};
+buf_info.sType = VK_STRUCTURE_TYPE_BUFFER_CREATE_INFO;
+buf_info.size  = desc.size;
+buf_info.usage = _toVkBufferUsage(desc.usage);
+```
+
+### API patterns
+
+- **`prRhiCreateCommandPool`**: Takes only `PrRhiDevice *device` (uses `device->queue_family_index` internally)
+- **`prRhiFreeCommandBuffers`**: Takes `PrRhiCommandBufferArray buffers` (count derived from `wpArrayCount`)
+- **`prRhiAllocateDescriptorSet`**: Takes `WpU32Array variable_descriptor_counts` for variable descriptor support
+- **`prRhiCmdBindVertexBuffers`**: Takes `WpU64Array offsets` (count matched to buffers internally)
+- **Shader entry points**: Configurable via `vertex_shader_entry_point` / `fragment_shader_entry_point` in pipeline desc (not hardcoded to "main")
+
+### File layout
+
+```
+src/prism/rhi/
+├── pr_rhi.h              ← umbrella header (API declarations + backend dispatch)
+├── pr_rhi.c              ← global context definition (prRhiInit, prRhiDestroy)
+├── pr_rhi_types.h        ← shared types (enums, element types, array aliases, desc structs, opaque handles)
+├── vulkan/
+│   ├── pr_rhi_vk.h       ← Vulkan backend header (opaque struct defs + Vk-suffixed decls)
+│   ├── pr_rhi_vk.c       ← Vulkan backend implementation
+│   ├── pr_rhi_vk_aliases.h ← #define alias mapping
+│   └── profiles/          ← generated Vulkan Profiles library
+├── d3d12/
+│   └── …
+└── metal/
+    └── …
+```
+

AGENTS.md

@@ -9,7 +9,7 @@ are rendered via GPU shaders.
 - **Language**: C11 / C++11 (dual-mode, like `src/wapp/`)
 - **GPU API**: Vulkan, abstracted behind a Rendering Hardware Interface (RHI)
 - **Shading language**: Slang, stored in external `.slang` files under `src/shaders/`
-- **Build**: TBD — either a standalone shell build script or a `justfile` (Just)
+- **Build**: `justfile` (Just) as a task runner
 - **Dependencies**: `src/wapp/` (local utility library, already vendored)
 
 ## Coding Conventions
@@ -28,28 +28,37 @@ All code follows the patterns established in `src/wapp/`. The project prefix is
 | Internal/static funcs | `_` + camelCase        | `_resolveTopology`, `_execCmd`  |
 | File-scope globals    | `_` + camelCase        | `_default_allocator`            |
 | File-scope constants  | SCREAMING_SNAKE        | `MAX_NODE_NAME`                 |
+| Variables             | snake_case             | `vertex_count`, `edge_node`     |
+
+- **Variable names**: Prefer descriptive names (e.g. `vertex_count` over `vc`, `edge_node` over `en`). Short names (`i`, `j`, `n`) are acceptable only in tight loop counters or trivial index variables. Avoid single-letter names in non-trivial scopes, and avoid abbreviated names that require the reader to hold a mental dictionary.
 
 ### Formatting
 
-- **Indentation**: tabs (no spaces). Tab width is a viewer preference.
+- **Tabs for indentation**, 8-column tab width.
-- **Braces**: always required after `if`, `else`, `for`, `while`, `do` — even
+- **Braces** on the same line as control statements (Attach style).
-  when the body is a single statement. This avoids ambiguity and makes diffs
+- **Braces on single-line if statements**: Always use braces, even for single-line bodies:
-  cleaner.
+  ```c
+  // correct
+  if (!buffer) { return; }
+  if (!texture) { _abort("alloc failed"); }
 
-```c
+  // wrong
-// correct
+  if (!buffer) return;
-if (condition) {
+  if (!texture) _abort("alloc failed");
-	do_thing();
+  ```
-}
+- **Pointers**: `*` against the name, not the type (`PrRhiBuffer *buf`, not `PrRhiBuffer* buf`).
-
+- **Line width**: 120 columns.
-for (int i = 0; i < n; i++) {
+- **Continuation lines** align to the opening parenthesis.
-	process(i);
+- **Return-type alignment**: Within each `// =====` section, align function
-}
+  declaration names so the first letter of every function occupies the same
-
+  column. For pointer return types, place `*` directly against the function
-// wrong — no braces, spaces instead of tabs
+  name (no space) and put all alignment padding between the type name and `*`.
-if (condition)
+  ```c
-	do_thing();
+  // correct — * against fn name, padding before *
-```
+  PrRhiSwapchain      *prRhiCreateSwapchain(…);
+  void                 prRhiDestroySwapchain(…);
+  PrRhiSwapchainResult prRhiAcquireNextImage(…);
+  ```
 
 ### Storage qualifiers
 
@@ -85,6 +94,12 @@ void prNodeDestroy(PrNode *n, PrAllocator *alloc);
 Use wapp allocators (`WpAllocator`, arena-based). Stack-allocate where
 possible; pass allocators explicitly.
 
+**Never use libc for memory or file I/O.** wapp always takes precedence:
+- `wpMemAllocatorAlloc` / `wpMemAllocatorFree` instead of `malloc` / `free`
+- `wpFileOpen` / `wpFileRead` / `wpFileClose` instead of `fopen` / `fread` / `fclose`
+
+For one-shot loads (e.g. SPIR-V at init), use `&_G_RHI_CONTEXT.allocator`.
+
 ```c
 PrGraph *prGraphCreate(PrAllocator *alloc);
 void     prGraphDestroy(PrGraph *g, PrAllocator *alloc);
@@ -118,9 +133,108 @@ prefer SoA layouts, batch processing, and minimise pointer chasing. Keep
 the DAG in contiguous arrays (e.g. adjacency lists packed in flat buffers)
 rather than individually allocated linked structures.
 
+### Frame-by-frame command batching
+
+Commands that execute every frame must avoid arena allocation. Use stack
+arrays with a while-loop to batch operations in fixed-size chunks:
+
+```c
+while (count > 0) {
+	VkTypeArray batch = wpArrayWithCapacity(VkType, 16, WP_ARRAY_INIT_FILLED);
+	u32 batch_size = count < wpArrayCapacity(batch) ? count : (u32)wpArrayCapacity(batch);
+	// ... process batch ...
+	vkCmd*(cb->handle, ...);
+	count -= batch_size;
+	first += batch_size;
+}
+```
+
+This avoids per-frame arena churn while handling arbitrarily large inputs.
+
+### Graph / adjacency lists
+
+Adjacency list nodes must be **separately allocated from the vertex array**.
+Never use the vertex struct itself as a linked-list node in another vertex's
+adjacency chain — that shares the `next` pointer between two roles (vertex state
+vs. edge linking) and causes edges to splice into unintended chains.
+
+```c
+// correct — per-edge copy on the arena
+static void addEdge(PrGraph *g, const WpAllocator *alloc, u64 from, u64 to) {
+	PrVertex *src = &g->vertices[from];
+	PrVertex *dst = wpMemAllocatorAlloc(alloc, sizeof(PrVertex));
+	if (!dst) { /* handle OOM */ return; }
+	dst->id    = g->vertices[to].id;
+	dst->value = g->vertices[to].value;
+	dst->next  = src->next;
+	src->next  = dst;
+}
+
+// wrong — reuses the destination vertex as the list node
+static void addEdge_bad(PrGraph *g, u64 from, u64 to) {
+	PrVertex *src  = &g->vertices[from];
+	PrVertex *dest = &g->vertices[to];
+	dest->next = src->next;
+	src->next  = dest;   // overwrites dest->next used elsewhere
+}
+```
+
+Arena bump allocation (`wpMemAllocatorAlloc`) is the natural fit for building
+graph structures: per-edge nodes live in the arena and are freed in one shot
+when the arena is destroyed.
+
+Always NULL-check the result of `wpMemAllocatorAlloc` — even arena allocators
+can fail if the backing buffer is exhausted.
+
+### WpArray usage
+
+| Scenario | API | Size must be… |
+|----------|-----|---------------|
+| Stack (local, short-lived) | `wpArrayWithCapacity` | compile-time constant |
+| Heap (arena-backed) | `wpArrayAllocCapacity` | runtime value |
+
+`wpArrayWithCapacity` creates a VLA-like compound literal on the stack —
+passing a runtime variable triggers undefined behaviour and compiler warnings.
+Use `wpArrayAllocCapacity` with an arena allocator for runtime sizes.
+
+Always use typed array aliases (`WpU64Array`, `PrNodeIdArray`, etc.) rather
+than raw pointers when declaring array variables. Follow the existing typedef
+pattern in the module (`typedef Type *TypeArray`).
+
+Typedef pattern:
+- Opaque handles use `**` (pointer-to-pointer)
+- Value types use `*` (contiguous block)
+```c
+typedef PrRhiBuffer         **PrRhiBufferArray;           // opaque handles → **
+typedef PrRhiColorAttachment *PrRhiColorAttachmentArray;  // value types → *
+```
+Group opaque handle arrays first, value type arrays second, separated by a
+blank line.
+
+Use named init flags (`WP_ARRAY_INIT_NONE`, `WP_ARRAY_INIT_FILLED`) instead of
+bare `0` — they make the initialisation policy explicit.
+
+- `WP_ARRAY_INIT_FILLED`: sets `count = capacity` on allocation. Required when
+  you plan to index into the array directly (not via append/push), since the
+  array's `count` must reflect valid elements for any downstream use.
+- `WP_ARRAY_INIT_NONE`: leaves `count = 0`. Use when you'll fill the array
+  incrementally via `wpArrayAppendCapped` / `wpArrayAppendAlloc`.
+
+Use `wpArrayCapacity(arr)`, `wpArrayCount(arr)`, `wpArraySetCount(arr, n)` to
+query and control array state rather than computing sizes manually.
+
+### Local/scratch arenas
+
+For function-local scratch allocations, use `wpMemArenaAllocatorInitZero` with a
+fixed size rather than a stack buffer + `InitWithBuffer`:
+
+```c
+WpAllocator scratch = wpMemArenaAllocatorInitZero(KiB(16));
+```
+
 ## Documentation
 
-Save research notes and implementation plans as markdown in `documents/`:
+Save research notes, implementation plans and session logs as markdown in `documents/`:
 
 ```
 documents/
@@ -128,10 +242,24 @@ documents/
 ├── RENDERING_HARDWARE_INTERFACE.md
 ├── NODE_SYSTEM.md
 ├── ROADMAP.md
-└── research/
+├── research/
-    └── vulkan-baseline.md
+│   └── <topic>.md
+└── session-logs/
+    └── YYYY-MM-DD.md
 ```
 
+At the start of each new session, read the previous session logs to understand what
+we've implemented so far
+
+## Skills
+
+Domain-specific conventions are stored as skills in `.opencode/skills/<name>/SKILL.md`.
+These are loaded on-demand by the AI agent when a task matches their description,
+keeping AGENTS.md lean.
+
+- **`prism-rhi`** — RHI backend dispatch, by-value descs, file layout
+- **`prism-dag`** — DAG adjacency lists, arena allocation, Kahn's algorithm
+
 ## Workflows for AI agents
 
 ### Research / planning
@@ -141,12 +269,12 @@ documents/
    a summary; iterate on the plan before writing any code.
 3. Only start implementing after the plan is approved.
 
-### Learning from edits
+### Skill maintenance
 
-The user may edit code produced by AI agents. When this happens, infer the
+When you observe the user correcting your output (e.g. formatting, conventions),
-reason for the change and update AGENTS.md with any new conventions, patterns,
+infer the rule and add it to the relevant skill's `SKILL.md`. If no skill
-or constraints that the edit reveals. This keeps the guide aligned with the
+matches, add a new one. This keeps AGENTS.md focused on project identity and
-user's evolving preferences.
+critical workflow rules rather than accumulating domain details.
 
 ### Committing
 

README.md

@@ -0,0 +1,35 @@
+# Prism
+
+A node-based image compositing tool. Images flow through a directed acyclic
+graph (DAG) of processing nodes (read, blend, colour-grade, etc.) and are
+rendered via GPU shaders.
+
+## Status
+
+Early development. Scaffolding and exploratory scratchpad work.
+
+## Language & Tooling
+
+- **Language**: C11 / C++11 (dual-mode), following conventions in `src/wapp/`
+- **GPU API**: Vulkan, abstracted behind a Rendering Hardware Interface (RHI)
+- **Shading language**: Slang (`src/shaders/`)
+- **Build**: TBD
+
+## Dependencies
+
+- `src/wapp/` — local utility library (vendored, provides allocators, arrays,
+  strings, platform abstractions, etc.)
+
+## Project layout
+
+```
+src/prism/prism.h        umbrella include
+src/prism/core/          graph, node types, DAG
+src/prism/rhi/           rendering hardware interface
+src/prism/node/          node implementations
+src/prism/app/           entry point, window, main loop
+src/shaders/             Slang shader sources
+src/wapp/                vendored utility library
+documents/               research notes and plans
+references/              third-party reference implementations
+```

assets/blit.slang

@@ -0,0 +1,41 @@
+// Prism fullscreen texture blit shader.
+//
+// Draws a selected texture from the bindless array as a fullscreen quad that
+// is letterboxed/pillarboxed to preserve aspect ratio (contain-fit). The NDC
+// content rect is supplied via push constants so the texture is never
+// stretched, squashed, or cropped.
+
+struct BlitData {
+	float4 rect;   // NDC fit rect: x0, y0, x1, y1
+	uint   selected;
+	uint   mode;   // 0 = sample texture, 1 = solid background
+	uint   pad[2];
+};
+
+[[vk::push_constant]]
+BlitData blit;
+
+Sampler2D textures[];
+
+struct VSOutput {
+	float4 Pos : SV_POSITION;
+	float2 UV;
+};
+
+[shader("vertex")]
+VSOutput main(uint vertexIndex : SV_VertexID) {
+	VSOutput output;
+	float2 uv = float2(float(vertexIndex & 1), float((vertexIndex >> 1) & 1));
+	output.UV = uv;
+	float2 pos = lerp(blit.rect.xy, blit.rect.zw, uv);
+	output.Pos = float4(pos, 0.0, 1.0);
+	return output;
+}
+
+[shader("fragment")]
+float4 main(VSOutput input) {
+	if (blit.mode == 1) {
+		return float4(0.18, 0.18, 0.18, 1.0);
+	}
+	return textures[NonUniformResourceIndex(blit.selected)].Sample(input.UV);
+}

documents/TEXTURE_POOL_AND_NODE_EVAL.md

@@ -0,0 +1,554 @@
+# Plan: Texture Pool + Node Evaluation
+
+## Goal
+
+Design the texture pool and node-to-shader dispatch so the node DAG doubles as the
+frame graph. Each node type maps to a single Slang shader (no fusion). The texture
+pool enables concurrent branches by allowing multiple intermediate textures to
+coexist.
+
+---
+
+## 1. Pool Allocator
+
+### 1.1 Purpose
+
+A reusable pool allocator for fixed-size blocks. This replaces the ad-hoc
+`PrPool` in scratchpad/dag.c and can be used for any fixed-size allocation
+throughout the project: node structs, edge structs, texture slots, descriptor
+sets, etc.
+
+Lives in `src/prism/allocators/`, **not** in wapp. wapp is vendored and may be
+replaced — the pool allocator must not be part of it.
+
+The pool owns its memory. No external allocator is passed — the pool allocates
+blocks internally via wapp OS allocation and grows on demand when free slots
+run out.
+
+### 1.2 Design
+
+The pool manages fixed-size slots arranged in contiguous blocks. Free slots are
+tracked via an intrusive free list (first `sizeof(void*)` bytes of each free
+slot hold a pointer to the next free slot). When the free list is empty, the
+pool allocates a new block of `block_slots` slots and carves them into the
+free list.
+
+```c
+typedef struct PrPool PrPool;
+
+struct PrPool {
+    void **blocks;      // array of allocated block pointers (for destroy)
+    u64    block_count; // number of allocated blocks
+    u64    block_cap;   // capacity of blocks array
+    void  *free_list;   // intrusive free list head
+    u64    slot_size;   // user-requested slot size
+    u64    alloc_size;  // actual slot size used internally (>= slot_size, >= sizeof(void*))
+    u64    block_slots; // slots per block
+    u64    total;       // total slots ever allocated (diagnostics)
+    u64    active;      // currently in use (diagnostics)
+};
+```
+
+### 1.3 API
+
+```c
+// Initialise a pool.
+//   slot_size:     fixed size of each slot
+//   initial_slots: starting capacity in slots (also used as block size)
+void prPoolInit(PrPool *pool, u64 slot_size, u64 initial_slots);
+
+// Allocate one slot. Grows by a new block if the free list is empty.
+// Returns NULL only on allocation failure.
+void *prPoolAlloc(PrPool *pool);
+
+// Return a slot to the pool's free list. Safe no-op on NULL.
+void prPoolFree(PrPool *pool, void *slot);
+
+// Free all blocks and zero the pool.
+void prPoolDestroy(PrPool *pool);
+
+// Diagnostics
+u64 prPoolTotalSlots(const PrPool *pool);
+u64 prPoolActiveSlots(const PrPool *pool);
+```
+
+### 1.4 Behavior
+
+| Operation | Implementation |
+|-----------|---------------|
+| `prPoolAlloc` | Pop from free list if non-empty, otherwise allocate a new block of `block_slots` slots via wapp OS allocation, link it into the `blocks` array, carve it into the free list, and pop. |
+| `prPoolFree` | Push slot onto the intrusive free list. Safe no-op on NULL. |
+| `prPoolDestroy` | Free every block in the `blocks` array, free the array itself, zero the struct. |
+
+Block growth: each new block has `block_slots` slots (same size as the initial
+block). The minimum block size is 4096 bytes — if `slot_size * initial_slots`
+is smaller, `block_slots` is rounded up to the nearest multiple of `slot_size`
+that meets the minimum. The `blocks` array starts at capacity 4 and doubles
+when full.
+
+### 1.5 Usage examples
+
+```c
+// Edge pool (replaces PrPool in scratchpad/dag.c):
+PrPool edge_pool;
+prPoolInit(&edge_pool, sizeof(PrGraphEdge), 64);
+PrGraphEdge *edge = prPoolAlloc(&edge_pool);
+prPoolFree(&edge_pool, edge);
+prPoolDestroy(&edge_pool);
+
+// Texture slot pool:
+PrPool tex_pool;
+prPoolInit(&tex_pool, sizeof(PrTextureSlot), 16);
+PrTextureSlot *slot = prPoolAlloc(&tex_pool);
+prPoolDestroy(&tex_pool);
+```
+
+---
+
+## 2. Texture Pool
+
+### 2.1 Purpose
+
+Intermediate textures (node outputs) need GPU resources. The texture pool manages
+a set of textures that are reused across graph evaluations. Without a pool, a
+linear chain of N nodes would need N textures. With refcount-based reuse,
+textures are returned to the pool as soon as all their consumers have executed,
+keeping the peak live count low.
+
+### 2.2 Data structures
+
+```c
+typedef struct PrTextureSlot {
+    PrRhiTexture *texture;     // the GPU texture (SAMPLED | COLOR_ATTACHMENT)
+    u32           refcount;    // how many downstream nodes still need to read this
+    b8            in_use;      // currently assigned to a node's output
+} PrTextureSlot;
+
+typedef struct PrTexturePool {
+    PrPool         slot_pool;  // pool allocator for PrTextureSlot structs
+    PrTextureSlot *slots;      // flat array for iteration (backed by slot_pool)
+    u32            count;      // number of allocated slots
+    u32            max;        // hard cap (never allocate beyond this)
+    u32            width;      // texture width (matches window)
+    u32            height;     // texture height (matches window)
+} PrTexturePool;
+```
+
+All pool textures are **RGBA16F, SAMPLED | COLOR_ATTACHMENT**. Any free slot works
+for any node — no format/dimension matching needed.
+
+The `slot_pool` is a `PrPool` allocator for `PrTextureSlot` structs. The `slots`
+pointer provides flat-array access for iteration during evaluation. When the pool
+grows, a new batch of slots is allocated via the pool allocator and the flat
+array is extended.
+
+### 2.3 Lifecycle
+
+```
+prTexturePoolInit(pool, device, initial_capacity, max, width, height)
+    → creates pool allocator, allocates initial slot array
+
+prTexturePoolReset(pool)
+    → marks all slots as free, zeroes refcounts (called once per frame)
+
+prTexturePoolAcquire(pool, device) -> PrTextureSlot*
+    → returns a free slot (in_use = true)
+    → if no free slot: allocate new slot + GPU texture, grow array
+    → if max reached: abort with diagnostic message
+
+prTexturePoolRelease(pool, slot)
+    → marks slot as free (in_use = false)
+    → called when refcount hits 0
+
+prTexturePoolDestroy(pool, device)
+    → destroys all GPU textures, destroys pool allocator
+```
+
+### 2.4 Allocation strategy (growth)
+
+The pool does **not** pre-allocate all textures upfront. Instead:
+
+1. Start with `initial_capacity` textures (e.g., 16)
+2. When all slots are occupied and a new one is needed, allocate a batch of
+   `GROWTH_BATCH` (e.g., 8) additional textures
+3. Never exceed `max` (e.g., 128)
+4. If `max` is reached, abort with: `"texture pool exhausted: N in use, max M"`
+
+Growth is amortized (batch allocation) and the pool never shrinks. The `count`
+monotonically increases as textures are allocated on demand.
+
+**Why growth instead of fixed pre-allocation:**
+- Small graphs don't pay for 64 unused textures
+- Complex graphs can grow beyond the initial allocation
+- The hard cap prevents unbounded memory use
+- vkCreateImage is only called when actually needed
+
+### 2.5 Refcount management
+
+Before evaluation, compute the **initial refcount** for each node's output:
+
+```
+refcount[node] = out_degree(node)   // number of outgoing edges
+```
+
+During evaluation, when a node executes and reads an input texture:
+```
+input_slot->refcount -= 1
+if (input_slot->refcount == 0):
+    prTexturePoolRelease(pool, input_slot)
+```
+
+This naturally handles:
+- **Linear chains**: A→B→C. A's output refcount=1, freed after B executes.
+- **Fan-out**: A→B, A→C. A's output refcount=2, freed after both B and C execute.
+- **Fan-in**: B→D, C→D. B and C have independent refcounts, freed independently.
+
+### 2.6 Texture dimensions
+
+Pool textures are created at the **window/swapchain resolution**. All nodes
+operate at this resolution. If a node needs a different resolution (e.g., a
+half-resolution blur), it would need a separate mechanism — out of scope for V1.
+
+---
+
+## 3. Node-to-Shader Mapping
+
+### 3.1 Type registry
+
+A static table maps `PrNodeType` → shader modules + pipeline + resource
+signatures:
+
+```c
+typedef enum PrShaderType {
+    PR_SHADER_TYPE_FRAGMENT,    // fullscreen triangle, per-pixel
+    PR_SHADER_TYPE_COMPUTE,     // dispatch, shared memory
+} PrShaderType;
+
+typedef struct PrNodeTypeEntry {
+    PrNodeType       type;
+    PrShaderType     shader_type;
+
+    // shaders (pre-compiled SPIR-V, built from .slang via slangc)
+    const char      *vertex_shader_path;   // NULL for compute
+    const char      *fragment_shader_path; // NULL for compute
+    const char      *compute_shader_path;  // NULL for fragment
+
+    // pipeline (created at init, cached here)
+    PrRhiPipeline   *pipeline;
+
+    // resource signature
+    u32              input_count;   // number of texture inputs (1 for blur, 2 for blend)
+    u32              output_count;  // always 1 for V1
+
+    // descriptor set layout (created at init)
+    PrRhiDescriptorSetLayout *set_layout;
+
+    // push constant size (bytes)
+    u32              push_constant_size;
+} PrNodeTypeEntry;
+```
+
+### 3.2 Registry instance
+
+```c
+wp_persist PrNodeTypeEntry _node_type_table[COUNT_NODE_TYPES] = {
+    [PR_NODE_TYPE_READ] = {
+        .type                = PR_NODE_TYPE_READ,
+        .shader_type         = PR_SHADER_TYPE_FRAGMENT,
+        .vertex_shader_path  = "assets/shaders/blit.vert.spv",
+        .fragment_shader_path= "assets/shaders/read.frag.spv",
+        .input_count         = 0,
+        .output_count        = 1,
+        .push_constant_size  = 0,
+    },
+    [PR_NODE_TYPE_BLUR] = {
+        .type                = PR_NODE_TYPE_BLUR,
+        .shader_type         = PR_SHADER_TYPE_FRAGMENT,
+        .vertex_shader_path  = "assets/shaders/blit.vert.spv",
+        .fragment_shader_path= "assets/shaders/blur.frag.spv",
+        .input_count         = 1,
+        .output_count        = 1,
+        .push_constant_size  = sizeof(PrBlurPushConstants),
+    },
+    [PR_NODE_TYPE_GRADE] = {
+        .type                = PR_NODE_TYPE_GRADE,
+        .shader_type         = PR_SHADER_TYPE_FRAGMENT,
+        .vertex_shader_path  = "assets/shaders/blit.vert.spv",
+        .fragment_shader_path= "assets/shaders/grade.frag.spv",
+        .input_count         = 1,
+        .output_count        = 1,
+        .push_constant_size  = sizeof(PrGradePushConstants),
+    },
+    [PR_NODE_TYPE_BLEND] = {
+        .type                = PR_NODE_TYPE_BLEND,
+        .shader_type         = PR_SHADER_TYPE_FRAGMENT,
+        .vertex_shader_path  = "assets/shaders/blit.vert.spv",
+        .fragment_shader_path= "assets/shaders/blend.frag.spv",
+        .input_count         = 2,
+        .output_count        = 1,
+        .push_constant_size  = sizeof(PrBlendPushConstants),
+    },
+};
+```
+
+### 3.3 Shader loading
+
+Shaders are written in Slang (`src/shaders/*.slang`) and compiled to SPIR-V as
+a build step via `slangc`. The `.spv` files are output to `assets/shaders/`. At
+init, the application loads pre-compiled SPIR-V directly:
+
+```
+for each entry in _node_type_table:
+    load vertex shader SPIR-V from .spv file
+    load fragment/compute shader SPIR-V from .spv file
+    create PrRhiShader handles
+    create descriptor set layout (input_count combined image samplers)
+    create pipeline layout (set layout + push constant range)
+    create pipeline (vertex + fragment stages, dynamic rendering)
+    cache everything in the entry
+```
+
+### 3.4 Shaders per node type
+
+| Node | Shader | Inputs | Push constants |
+|------|--------|--------|----------------|
+| READ | `read.frag.spv` | 0 (samples from KTX texture loaded separately) | — |
+| BLUR | `blur.frag.spv` | 1 input texture | `f32 radius` |
+| GRADE | `grade.frag.spv` | 1 input texture | `f32 gain, f32 lift, f32 gamma` |
+| BLEND | `blend.frag.spv` | 2 input textures | `u32 mode` (over/under/add) |
+
+All share `blit.vert.spv` (fullscreen triangle, no vertex buffer needed).
+
+---
+
+## 4. Evaluation Loop
+
+### 4.1 Per-frame sequence
+
+```
+prGraphEvaluate(graph, device, pool, cb, swapchain_texture):
+    1. topo_order = prGraphTopologicalSort(graph)
+
+    2. // compute initial refcounts
+    for each node in graph:
+        node.output_refcount = out_degree(node)
+
+    3. prTexturePoolReset(pool)
+
+    4. // reset per-frame descriptor pool (allocated once at init, reset each frame)
+       prRhiResetDescriptorPool(device, desc_pool)
+
+    5. for each node_id in topo_order:
+        node = &nodes[node_id]
+        entry = &_node_type_table[node->type]
+
+        // acquire output texture from pool
+        output_slot = prTexturePoolAcquire(pool, device)
+
+        // gather input textures (from upstream nodes' output slots)
+        input_count = 0
+        input_slots[4]  // max 4 inputs
+        for each upstream edge (upstream → node):
+            input_slots[input_count++] = upstream.output_slot
+
+        // allocate and update descriptor set
+        desc_set = prRhiAllocateDescriptorSet(device, desc_pool, entry->set_layout)
+
+        writes = stack_array(input_count)
+        for i in 0..input_count:
+            writes[i] = {
+                .dst_set         = desc_set,
+                .dst_binding     = i,
+                .dst_array_element = 0,
+                .type            = PR_RHI_DESCRIPTOR_TYPE_COMBINED_IMAGE_SAMPLER,
+                .image_info      = &(PrRhiDescriptorImageInfo){
+                    .texture = input_slots[i]->texture,
+                    .sampler = shared_sampler,
+                    .layout  = PR_RHI_IMAGE_LAYOUT_SHADER_READ_ONLY_OPTIMAL,
+                },
+            }
+        prRhiUpdateDescriptorSet(device, writes)
+
+        // record commands
+        prRhiCmdBeginRendering(cb, output_slot->texture, ...)
+        prRhiCmdBindPipeline(cb, GRAPHICS, entry->pipeline)
+        prRhiCmdBindDescriptorSets(cb, GRAPHICS, entry->pipeline_layout, 0, 1, &desc_set, 0, NULL)
+        prRhiCmdPushConstants(cb, ..., node->params)
+        prRhiCmdDraw(cb, 3, 1, 0, 0)  // fullscreen triangle
+        prRhiCmdEndRendering(cb)
+
+        // release input textures whose refcount hit 0
+        for each input_slot:
+            input_slot->refcount -= 1
+            if input_slot->refcount == 0:
+                prTexturePoolRelease(pool, input_slot)
+
+        // store output slot on node for downstream consumers
+        node->output_slot = output_slot
+
+    6. // final blit to swapchain
+        final_slot = last_node.output_slot
+        blit final_slot->texture → swapchain_texture
+
+    7. prRhiQueueSubmit(cb)
+```
+
+### 4.2 READ node special case
+
+READ nodes load a texture from disk (KTX) via `prRhiCreateTextureFromKtx`.
+The loaded texture is stored directly on the node (persistent, lives across
+frames). Unlike other nodes, READ's input comes from this persistent texture
+rather than from an upstream node's output slot.
+
+READ nodes still render a fullscreen triangle that samples from the loaded
+texture and writes to the output pool texture. This allows the user to view
+the raw texture before any modifications, and ensures READ nodes participate
+uniformly in the evaluation pipeline.
+
+READ nodes participate in refcount tracking like any other node: their output
+slot's refcount is set to `out_degree(READ)`, and downstream consumers
+decrement it normally.
+
+### 4.3 Barrier insertion
+
+Between nodes that share a texture (one writes, next reads), a pipeline barrier
+is needed to transition the texture layout:
+
+```
+after node A executes (writes to texture T):
+    barrier: T from COLOR_ATTACHMENT → SHADER_READ_ONLY
+
+before node B executes (reads texture T):
+    (barrier already inserted above)
+```
+
+In practice, the barrier is inserted **after** each node's render pass:
+- Transition the output texture from `COLOR_ATTACHMENT_OPTIMAL` to
+  `SHADER_READ_ONLY_OPTIMAL`
+
+The **first** node in a chain (READ) needs a transition from `TRANSFER_DST` to
+`SHADER_READ_ONLY` after loading from disk. This is already handled by
+`prRhiCreateTextureFromKtx`.
+
+Layout transitions per node:
+```
+READ:     UNDEFINED → TRANSFER_DST → SHADER_READ_ONLY  (done by KTX loader)
+BLUR:     SHADER_READ_ONLY (input) → COLOR_ATTACHMENT (output, during render)
+          output transitions to SHADER_READ_ONLY after render pass
+GRADE:    same as BLUR
+BLEND:    same as BLUR (two inputs)
+```
+
+### 4.4 Descriptor management
+
+Each node needs a descriptor set binding its input textures. The flow:
+
+**Init (once):**
+- Create a **per-node-type descriptor set layout** with `input_count` combined
+  image sampler bindings. Stored in `PrNodeTypeEntry.set_layout`.
+- Create a **persistent descriptor pool** large enough for the worst-case node
+  count (e.g., 128 sets). Created once, reused every frame.
+
+**Per frame:**
+1. Reset the descriptor pool via `prRhiResetDescriptorPool`. This is much
+   cheaper than create/destroy — it reuses the pool's internal memory.
+2. For each node during evaluation:
+   - Allocate a descriptor set from the pool using the node type's layout.
+   - Write each input texture into the set via `prRhiUpdateDescriptorSet`.
+     Each write specifies:
+     - `dst_set` / `dst_binding` — which set and binding index
+     - `type` — `PR_RHI_DESCRIPTOR_TYPE_COMBINED_IMAGE_SAMPLER`
+     - `image_info` — texture handle, shared sampler, layout
+   - Bind the set during rendering via `prRhiCmdBindDescriptorSets`.
+
+The pool lives for the lifetime of the application. Only its contents are
+reset each frame.
+
+---
+
+## 5. File layout
+
+```
+src/prism/allocators/
+└── pr_pool_allocator.h / .c   ← pool allocator (self-managing, wapp OS allocation)
+
+src/prism/core/
+├── pr_graph.h / .c          ← promoted from scratchpad/dag.c
+├── pr_node.h / .c           ← PrNode, PrNodeType, PrNodeManager
+├── pr_texture_pool.h / .c   ← PrTexturePool
+└── pr_node_eval.h / .c      ← evaluation loop, type registry
+
+src/shaders/                   ← Slang source (compiled to assets/shaders/ via slangc)
+├── blit.vert.slang            ← fullscreen triangle (shared by all fragment nodes)
+├── read.frag.slang            ← passthrough (samples loaded texture)
+├── blur.frag.slang            ← gaussian blur
+├── grade.frag.slang           ← colour grading
+└── blend.frag.slang           ← alpha compositing
+
+assets/shaders/                 ← compiled SPIR-V output (loaded at runtime)
+├── blit.vert.spv
+├── read.frag.spv
+├── blur.frag.spv
+├── grade.frag.spv
+└── blend.frag.spv
+```
+
+---
+
+## 6. Implementation order
+
+1. **Pool allocator**: Implement `PrPool` in `src/prism/allocators/`.
+   `prPoolInit`, `prPoolAlloc`, `prPoolFree`, `prPoolDestroy`. Self-managing
+   growth via wapp OS allocation. Replace the ad-hoc `PrPool` in scratchpad/dag.c.
+
+2. **Promote graph to production**: Move `PrGraph`, `PrNodeManager`, topology
+   ops from `scratchpad/dag.c` to `src/prism/core/pr_graph.h/.c` and
+   `pr_node.h/.c`. Clean up — remove the `main()` test harness.
+
+3. **Define node type registry**: Create `PrNodeTypeEntry` table with resource
+   signatures (input_count, output_count, push_constant_size). No shaders yet.
+
+4. **Implement PrTexturePool**: Growth-based pool with refcount tracking.
+   `prTexturePoolInit`, `prTexturePoolReset`, `prTexturePoolAcquire`,
+   `prTexturePoolRelease`, `prTexturePoolDestroy`.
+
+5. **Write blit.vert.slang**: Fullscreen triangle, no vertex buffer. Shared by
+   all fragment-shader nodes. Compile to SPIR-V via `slangc`.
+
+6. **Write initial frag shaders**: `read.frag.slang`, `blur.frag.slang`,
+   `grade.frag.slang`, `blend.frag.slang`. Simple per-pixel operations.
+   Compile to SPIR-V via `slangc`.
+
+7. **Wire up shader loading + pipeline creation**: At init, load pre-compiled
+   SPIR-V from `assets/shaders/`, create descriptor set layouts, pipeline
+   layouts, pipelines. Cache in the type registry.
+
+8. **Implement evaluation loop**: `prGraphEvaluate` — topo sort, refcount
+   compute, pool reset, per-node dispatch, barrier insertion, final blit to
+   swapchain.
+
+9. **Integrate with main loop**: Replace the current mesh-rendering demo with
+   a node graph evaluation. Create a test graph (Read→Blur→Blend) and render
+   it to the swapchain.
+
+---
+
+## 7. Decisions
+
+- **Pool allocator**: Self-contained `PrPool` with standalone API. No external
+  allocator parameter — pool allocates blocks via wapp OS allocation (`wpOsMemAlloc`
+  / `wpOsMemFree`) and grows on demand. Handles slot sizes smaller than
+  `sizeof(void*)` transparently via an internal `alloc_size`. Lives in
+  `src/prism/allocators/`, outside vendored wapp.
+
+- **READ node texture lifetime**: READ nodes hold a persistent `PrRhiTexture`
+  (loaded via `prRhiCreateTextureFromKtx`) outside the pool. The pool slot's
+  `texture` pointer references this persistent texture. This means READ nodes
+  don't consume pool slots — they just participate in refcount tracking.
+
+- **Sampler**: Single shared sampler (linear filtering, clamp-to-edge) for all
+  nodes in V1. Created once at init.
+
+- **Push constant layout**: Each node type defines its own push constant struct.
+  The evaluation loop reads the node's params union and passes it via
+  `prRhiCmdPushConstants`. The shader declares matching layout.

documents/plans/fullscreen-blit.md

@@ -0,0 +1,150 @@
+# Plan — Fullscreen Texture Blit with Contain-Fit
+
+## Goal
+
+Render a texture fullscreen with aspect-ratio preservation. If the texture's
+aspect ratio does not match the window's, draw it to fit within the window —
+never stretched, squashed, or cropped. Tall/narrow textures pillarbox (bars on
+left/right); wide textures letterbox (bars on top/bottom).
+
+This replaces the Suzanne mesh demo in `main.cpp`, which was for testing the RHI.
+
+## Fit semantics (contain — never crop)
+
+```
+scale       = min(win_w / tex_w, win_h / tex_h)
+content_w   = tex_w * scale
+content_h   = tex_h * scale
+rect        = centered: left = (win_w - content_w)/2, top = (win_h - content_h)/2
+```
+
+| Texture vs window aspect | Limiting dim | Result            |
+|--------------------------|--------------|-------------------|
+| equal                    | —            | fills exactly     |
+| wider (e.g. 2048x512)    | width        | letterbox (T/B)   |
+| taller (e.g. 512x2048)   | height       | pillarbox (L/R)   |
+
+The fit rect is recomputed per frame from the selected texture's dimensions and
+the current window size, so window resize works without extra handling.
+
+## Changes
+
+### 1. RHI — texture size accessor
+
+Add a value struct and a by-value getter (matches `prRhiGetSurfaceCapabilities`
+pattern):
+
+```c
+typedef struct PrRhiTextureSize {
+	u32 width;
+	u32 height;
+} PrRhiTextureSize;
+
+PrRhiTextureSize prRhiGetTextureSize(PrRhiTexture *texture);
+```
+
+Files: `pr_rhi_types.h`, `pr_rhi.h`, `vulkan/pr_rhi_vk.h`,
+`vulkan/pr_rhi_vk.c`, `vulkan/pr_rhi_vk_aliases.h`.
+
+### 2. Offline shader compilation (drop Slang runtime)
+
+- New `justfile` `shaders` recipe:
+  `slangc -target spirv -profile spirv_1_4 -o build/shaders/blit.spv assets/blit.slang`
+  (entry points auto-detected from `[shader(...)]` attributes).
+  `build` depends on it.
+- `main.cpp` loads `build/shaders/blit.spv` via wapp file I/O
+  (`wpFileOpen` / `wpFileGetLength` / `wpFileRead`) into an arena buffer, then
+  `prRhiCreateShader`. No `slang.h` includes, no runtime compilation.
+- Drop `-lslang` and the `-I .../slang` include from the build.
+
+### 3. `assets/blit.slang`
+
+Push constant block (32 bytes — Slang pads structs to 16-byte alignment, so the
+C++ struct carries explicit `pad[3]` to match):
+
+```hlsl
+struct BlitData {
+	float4 rect;   // NDC fit rect: x0, y0, x1, y1
+	uint   selected;
+	uint   pad[3];
+};
+```
+
+- **VS**: generates a 4-vertex triangle-strip quad from `SV_VertexID` (no vertex
+  buffer), maps UV 0–1 into the NDC rect.
+- **FS**: `textures[NonUniformResourceIndex(selected)].Sample(uv)` — reuses the
+  existing bindless descriptor array.
+
+### 4. `main.cpp` — clean texture viewer
+
+Remove everything mesh-related: tinyobj loading, vertex/index buffers,
+`ShaderData` storage buffers / device addresses, the mesh shader + pipeline,
+mouse orbit, and the mesh draw. Drop `-ltinyobjloader -lglm` from the link.
+Remove unused `assets/shader.slang`, `suzanne.obj`, `suzanne.mtl`.
+
+New flow: RHI init → window/instance/pdev/surface/device/swapchain → load 7
+textures → bindless descriptor set (variable count 7) → load `blit.spv` →
+blit pipeline layout (`VERTEX|FRAGMENT` 32-byte push range) → blit pipeline
+(no vertex input, `TRIANGLE_STRIP`, swapchain color format, no depth,
+`cull NONE`, dynamic viewport/scissor).
+
+Render loop per frame:
+- `compute_fit_rect()` from the selected texture's dims + window size
+- bind blit pipeline + descriptor set, push `BlitData{ rect, selected }`,
+  `prRhiCmdDraw(cb, 4, 1, 0, 0)`
+- `+/-` cycles the selected texture; resize recomputes fit automatically
+
+### 5. Test textures (PIL + `build/bin/toktx`)
+
+Four generated KTX files in `assets/`, loaded alongside the 3 Suzanne textures
+(`texture_count = 7`, explicit path array):
+
+| File            | Size      | Shows                    |
+|-----------------|-----------|--------------------------|
+| `test_square.ktx` | 1024x1024 | bars on both axes        |
+| `test_fill.ktx`   | 1920x1080 | fills the 16:9 window    |
+| `test_wide.ktx`   | 2048x512  | letterbox (T/B)          |
+| `test_tall.ktx`   | 512x2048  | pillarbox (L/R)          |
+
+Each with distinct gradients + a border grid so any stretch/squash is visible.
+Generated with `--genmipmap` for mip-aware sampling.
+
+## Verification
+
+`just build && just run` — each texture fits without crop/stretch, `+/-` cycles,
+window resize keeps fit, no Slang runtime in the binary.
+
+## Verification results (2026-08-08)
+
+Fit behavior confirmed by capturing the window (X11 driver) and sampling pixels:
+
+| Texture             | Window        | Result verified                                |
+|---------------------|---------------|------------------------------------------------|
+| square 1024x1024    | 16:9 wide     | pillarbox — pure-black L/R bars, full height   |
+| test_wide 2048x512  | 16:9 wide     | letterbox — pure-black T/B bars, full width    |
+| test_tall 512x2048  | 16:9 wide     | pillarbox — pure-black L/R bars, full height   |
+| test_fill 1920x1080 | 16:9 wide     | fills exactly — no bars anywhere               |
+| square (resized)    | portrait      | fit recomputed per frame — flips to letterbox  |
+
+Texture cycling (`+/-`, `SDLK_PLUS/KP_PLUS/EQUALS`, `SDLK_MINUS/KP_MINUS`) is a
+straightforward `selected` bump in the key handler; it was reviewed but not
+exercise-tested in the headless verification env (KWin/XWayland drops XTEST
+synthesised keys). The other fit cases were verified by temporarily launching
+each texture as the initial selection.
+
+### Bugs found and fixed during verification
+
+1. **`VK_SUBOPTIMAL_KHR` aborted the app.** `prRhiAcquireNextImageVk` /
+   `prRhiPresentVk` routed `SUBOPTIMAL` into `_checkVk` → `__builtin_trap()`.
+   Both now treat it like `OUT_OF_DATE` (return `PR_RHI_SWAPCHAIN_OUT_OF_DATE`).
+   Triggered immediately under X11/XWayland.
+2. **Swapchain recreate ignored surface extent.** `prRhiRecreateSwapchainVk`
+   hard-coded the passed width/height; on surfaces whose `currentExtent` is
+   meaningful (X11) that mismatched the drawable and re-looped on SUBOPTIMAL.
+   Now queries `vkGetPhysicalDeviceSurfaceCapabilitiesKHR` and falls back to the
+   passed size only when `currentExtent == 0xFFFFFFFF`.
+3. **App used logical window size for the swapchain.** Under HiDPI the drawable
+   differs from `SDL_GetWindowSize` (1920x1080 logical → 2400x1350 drawable at
+   1.25x scale), which is the root cause of #1 under XWayland. main.cpp now uses
+   `SDL_GetWindowSizeInPixels` for swapchain width/height, fit math, viewport
+   and scissor.

documents/research/dags.md

@@ -0,0 +1,184 @@
+# DAGs for Node-Based Compositing
+
+## What is a DAG?
+
+A **Directed Acyclic Graph (DAG)** is a graph where:
+
+- **Directed** — every edge has a direction (A → B means "A feeds into B")
+- **Acyclic** — no path forms a cycle; you cannot loop back to a node you've already visited
+
+In compositing, nodes are the vertices and image/data flow defines the edges. A **Read** node feeds into a **Blur** node, which feeds into a **Merge** node, etc.
+
+## Why DAGs for Compositing
+
+| Property | Benefit |
+|---|---|
+| Non-linear | Any node can be tweaked without rebuilding the whole comp |
+| Dependency-driven | Only re-evaluate nodes whose inputs changed ("dirty propagation") |
+| Parallelism | Independent branches can run concurrently |
+| Modular | Nodes are self-contained; easy to add new types |
+
+### Real-world examples
+
+- **Nuke** (Foundry) — the industry standard; everything is a DAG
+- **Fusion** (Blackmagic) — same concept, node graph as the primary interface
+- **Blender Compositor** — uses a dependency graph internally
+- **Shadertoy / MaterialX** — similar DAG concepts for shader/node graphs
+
+## Core Algorithms
+
+**BFS** (Breadth-First Search) explores a graph level by level — you visit all neighbours of a node before moving to their neighbours. Useful for shortest paths and spreading outward.
+
+**DFS** (Depth-First Search) goes deep first — you follow one path as far as it goes, then backtrack. Useful for cycle detection, pathfinding, and topological sort.
+
+### Topological Sort
+
+A **topological ordering** of a DAG is a linear sequence of all vertices such that for every edge u → v, u appears before v. This is the evaluation order for a node graph — you must process a node's inputs before processing the node itself.
+
+There are two standard approaches, one based on each traversal strategy:
+
+### 1. Kahn's Algorithm (BFS-based)
+
+Uses **in-degree** (number of incoming edges) to determine which nodes are ready to execute.
+
+```
+1. Compute in-degree for every node
+2. Queue all nodes with in-degree == 0 (no dependencies)
+3. While queue is not empty:
+   a. Dequeue node n, add to result order
+   b. For each downstream node m of n:
+      - Decrement m's in-degree
+      - If m's in-degree reaches 0, enqueue m
+4. If result count != node count → there is a cycle
+```
+
+**Why Kahn's for compositing:**
+- Naturally detects cycles (a graph editor must prevent the user from creating cycles)
+- Gives you ready-to-evaluate layers (all in-degree-0 nodes at a given step can run in parallel)
+- O(V + E) time, O(V) space
+- Easy to implement with arrays
+
+### 2. DFS-based (Post-order)
+
+```
+1. For each unvisited node, run DFS
+2. After visiting all descendants of a node, prepend it to the result
+```
+
+Simpler to code but less practical for incremental / parallel evaluation. Used more for DAG verification in build systems.
+
+## Data Structures for a DAG
+
+### Adjacency List (recommended for Prism)
+
+Store the graph as two flat arrays:
+
+```c
+// Node i's outgoing edges are adjacency[i] .. adjacency[i + 1]
+u32 *adjacency;       // flat list of edge destinations
+u32 *adjacency_begin; // start index into adjacency for each node
+u32  node_count;
+u32  edge_count;
+```
+
+Or simpler: each node stores its outputs:
+
+```c
+typedef struct PrNode PrNode;
+struct PrNode {
+    u32          id;
+    PrNodeType   type;
+    u32          input_count;     // number of inputs (incoming edges)
+    u32          input_nodes[4];  // fixed-size or pointer to array
+    u32          output_count;    // number of downstream nodes
+    u32         *output_nodes;    // allocated with arena
+    // ... data for this node type
+};
+```
+
+For a **data-oriented** approach in hot paths (graph evaluation), pack fields into parallel arrays:
+
+```c
+// SoA layout for evaluation
+u8          *node_types;     // PrNodeType for each node
+u32         *in_degrees;     // current in-degree (Kahn's state)
+u32         *topo_order;     // result of topological sort
+```
+
+### Struct-of-Arrays (SoA) Layout
+
+For the graph evaluation hot path, you can use parallel arrays instead of an array of structs:
+
+```c
+struct PrGraphEvalState {
+    u32   node_count;
+    u32  *topo_order;        // [0..node_count-1] in eval order
+    u32  *in_degrees;        // temp space for Kahn's
+    u8   *dirty_flags;       // per-node dirty bit
+    u32  *output_counts;
+    u32 **output_lists;      // adjacency
+};
+```
+
+This keeps only the data needed for traversal in cache-friendly contiguous memory.
+
+## Incremental / Dirty Evaluation
+
+For interactive use, re-running the full topological sort every frame is wasteful. Instead:
+
+1. When a node's parameter changes, mark it **dirty**
+2. Propagate the dirty flag downstream (BFS along edges)
+3. Only re-evaluate dirty nodes in topological order
+
+Alternatively, skip dirty propagation and just always eval in topo order — each node checks if its inputs are dirty or if its own parameters changed. Simpler, but does more work.
+
+## Cycles in a Graph Editor
+
+A graph editor must **prevent** the user from creating cycles in real time. Approaches:
+
+1. **Check on each edge creation:** before adding edge A → B, check if there's already a path from B to A (DFS from B). O(V + E) per edge add.
+2. **Incremental cycle detection:** more sophisticated data structures for dynamic graphs. Probably overkill for V1.
+3. **Kahn's validation:** Run Kahn's after every edit; if it doesn't produce a full ordering, reject the edit.
+
+Approach 1 (DFS reachability test) is the simplest for V1.
+
+## Evaluation Pipeline
+
+```
+User edits graph
+        │
+        ▼
+Validate no cycles  ← (reject edit if cycle detected)
+        │
+        ▼
+Topological sort    ← (Kahn's algorithm → list of node IDs)
+        │
+        ▼
+Mark dirty nodes    ← (only nodes downstream of changes)
+        │
+        ▼
+For each node in topo order:
+    If node is dirty:
+        Gather input images (from upstream node outputs)
+        Execute node (CPU or dispatch GPU shader)
+        Store output image
+        │
+        ▼
+Render final output → display
+```
+
+## Key Takeaways for Prism
+
+1. **Kahn's algorithm** is the right choice — simple, O(V+E), built-in cycle detection, parallel-layer grouping
+2. **Adjacency list** with flat arrays for the graph structure
+3. **Evaluate in topological order**; skip clean nodes for efficiency
+4. **Cycle check on edge creation** via DFS from the target node
+5. **SoA layout** for evaluation state if profiling shows cache misses on the hot path
+6. Node types (Read, Blur, Merge, etc.) can use a `PrNodeType` enum with a function dispatch table, or a union of type-specific data in the node struct
+
+## References
+
+- Kahn, A. B. (1962). "Topological sorting of large networks." *Communications of the ACM*
+- Cormen et al., *Introduction to Algorithms*, 3rd ed., Ch. 22.4 (Topological Sort)
+- Foundry Nuke documentation: [https://learn.foundry.com/nuke](https://learn.foundry.com/nuke)
+- Taskflow C++ library: [https://taskflow.github.io](https://taskflow.github.io)

documents/research/node-graph-ui-with-imgui.md

@@ -0,0 +1,212 @@
+# Node Graph UI with DearImGui — Research
+
+## Overview
+
+Three main approaches exist for building a node graph UI with DearImGui:
+1. Use a standalone library like **ImNodes** or **imgui-node-editor**
+2. Build from scratch using ImGui's draw list API
+3. Use a hybrid — custom canvas with ImGui widgets
+
+---
+
+## 1. Existing Libraries
+
+### 1.1 imnodes (Nelarius)
+
+- **Stars**: ~2.4k | **License**: MIT | **Status**: Active (last push 2024)
+- **Files**: `imnodes.h`, `imnodes_internal.h`, `imnodes.cpp` — drop-in, no deps beyond ImGui
+- **API style**: Immediate-mode, mirrors ImGui idioms
+
+```cpp
+imnodes::BeginNodeEditor();
+imnodes::BeginNode(node_id);
+imnodes::BeginNodeTitleBar();
+ImGui::Text("Node Name");
+imnodes::EndNodeTitleBar();
+imnodes::BeginInputAttribute(pin_id);
+ImGui::Text("input");
+imnodes::EndAttribute();
+imnodes::BeginOutputAttribute(pin_id);
+ImGui::Text("output");
+imnodes::EndAttribute();
+imnodes::EndNode();
+imnodes::EndNodeEditor();
+```
+
+**Strengths:**
+- Minimal, dependency-free, easy to vendor
+- True immediate-mode — user owns all state
+- Pins auto-align with embedded ImGui widgets
+- Simple `ImNodes::Link(id, from, to)` API
+
+**Weaknesses:**
+- Less feature-rich (no built-in minimap, no grouping, limited theming)
+- No built-in serialization of layout
+- Slower development velocity
+
+**Under the hood:**
+- Uses `ImDrawList::ChannelsSplit()` to layer node backgrounds behind UI
+- Pins are detected via `ImGui::BeginGroup` bounding box capture
+- Link picking uses hierarchical bezier subdivision
+
+### 1.2 imgui-node-editor (thedmd / Michal Cichon)
+
+- **Stars**: ~4.4k | **License**: MIT | **Status**: Active
+- **Files**: `imgui_node_editor.h/.cpp` + `imgui_canvas.h/.cpp` — also drop-in
+- **API style**: retained-state editor context, user draws content
+
+```cpp
+ax::NodeEditor::Begin("Editor");
+ax::NodeEditor::BeginNode(node_id);
+ax::NodeEditor::BeginPin(pin_id, ax::NodeEditor::PinKind::Input);
+ImGui::Text("input");
+ax::NodeEditor::EndPin();
+ax::NodeEditor::EndNode();
+ax::NodeEditor::End();
+```
+
+**Strengths:**
+- Rich feature set: zoom/pan, minimap, selection, context menus, copy/paste
+- Blueprint-UE4-inspired default theme
+- Bézier curve links with flow animation
+- Configurable zoom levels, drag/navigate/select button mapping
+- `ImGuiEx::Canvas` can be used independently for custom infinite-workspace UIs
+- Built-in serialization callbacks (`SaveSettings`/`LoadSettings`)
+
+**Weaknesses:**
+- Heavier than imnodes — more code, larger API surface
+- Editor context is a retained object (less "pure" immediate mode)
+- Can conflict with ImGui's own ID stack during complex widget embedding
+
+**Key API patterns:**
+
+| Concern | API |
+|---|---|
+| Create link | `BeginCreate()` / `QueryNewLink()` / `AcceptNewItem()` / `EndCreate()` |
+| Delete | `BeginDelete()` / `QueryDeletedLink()` / `AcceptDeletedItem()` / `EndDelete()` |
+| Suspend for popups | `Suspend()` / `Resume()` — pops out of canvas coordinate space |
+| Styling | `PushStyleColor()` / `PushStyleVar()` — 20+ style variables |
+
+### 1.3 ImNodeFlow (Fattorino)
+
+- **Stars**: Newer (2024–2025) | **License**: MIT
+- Even more feature-packed: node categories, commenting, layout algorithms
+- Still maturing; less battle-tested than the two above
+
+> **Recommendation for Prism**: start with **imgui-node-editor** if we want a polished editor quickly, or **imnodes** if we want minimal deps and full state control. The custom approach (next section) is best if we have very specific rendering needs.
+
+---
+
+## 2. Custom Node Graph from Scratch
+
+Building a node graph manually using `ImDrawList` gives maximum control but requires handling:
+
+### 2.1 Canvas / Coordinate System
+
+An infinite-zoom canvas requires:
+- An offset (`ImVec2`) and scale (`float`) transform
+- Conversion functions between screen ↔ canvas space
+- Clipping to the parent ImGui window
+
+The `imgui-node-editor` library includes an `ImGuiEx::Canvas` utility that handles this standalone — it can be extracted and reused.
+
+### 2.2 Rendering Nodes (DrawList)
+
+Nodes are typically rendered in layers:
+1. **Background layer**: grid dots/lines, selection rectangle
+2. **Node bodies**: rounded rectangles (`AddRectFilled`)
+3. **Node borders**: rect strokes, optionally thicker on hover/select
+4. **Pins**: small circles or squares on left/right edges
+5. **Links**: cubic Bézier curves between pin centers
+6. **UI overlay**: selection handles, context menus
+
+Use `ImDrawList::ChannelsSplit()` for correct z-ordering when mixing drawn shapes with ImGui widgets.
+
+### 2.3 Interaction Handling
+
+| Interaction | Implementation |
+|---|---|
+| Pan | Track middle-mouse drag → modify canvas offset |
+| Zoom | Mouse wheel → modify scale (clamp to range, center on cursor) |
+| Drag node | Hit-test node bodies (invis buttons or rect test), track delta → update node position |
+| Select | Rectangular marquee — track shift+drag → compute selection rect → test intersection with node rects |
+| Create link | Detect drag from pin, draw preview bezier, test against other pins on release |
+| Delete | Keyboard shortcut, query selection, or context menu |
+
+### 2.4 Link-Picking (Bezier Hit Test)
+
+Cubic Bézier curves require a hierarchical hit test:
+1. Subdivide curve into N segments
+2. Find segment closest to mouse cursor
+3. Recursively subdivide that segment
+4. Return hit if distance < threshold
+
+## 3. Architecture Patterns
+
+### 3.1 Data Model vs. View Separation
+
+From Guillaume Boissé's RogueEngine post:
+- Define a **data model** independent of UI: `PrNode`, `PrGraph`, `PrPin`
+- The data model is used both by the runtime (graph evaluation) and the editor (UI rendering)
+- This enables easy serialization, undo/redo, and multi-context editing
+
+### 3.2 Immediate-Mode Node Rendering Loop
+
+```
+For each node in graph:
+    BeginNode(node.id)
+        Render node title bar (colored rect + text)
+        For each input pin:
+            BeginInputPin(pin.id)
+            Render ImGui widget (e.g. DragFloat, ColorEdit)
+            EndInputPin()
+        For each output pin:
+            BeginOutputPin(pin.id)
+            Render ImGui widget
+            EndOutputPin()
+    EndNode()
+
+For each link in graph:
+    DrawBezierLink(from_pos, to_pos, color, thickness)
+```
+
+Positions are stored per-node in user state and updated on drag.
+
+### 3.3 DrawList Channels (Z-Order)
+
+```cpp
+draw_list->ChannelsSplit(3);
+draw_list->ChannelsSetCurrent(0); // Background: grid, selection rect
+// ... draw nodes, pins, links
+draw_list->ChannelsSetCurrent(1); // UI: ImGui widgets inside nodes
+// ... BeginNode/EndNode calls
+draw_list->ChannelsSetCurrent(2); // Foreground: tooltips, drag previews
+draw_list->ChannelsMerge();
+```
+
+### 3.4 Undo/Redo
+
+Simplest viable approach (from RogueEngine / @voxagonlabs): serialize the entire project state on every change. Store snapshots in an undo stack. Works well for small-to-medium projects (node graphs are typically small data).
+
+## 4. Summary Comparison
+
+| Criteria | imnodes | imgui-node-editor | Custom |
+|---|---|---|---|
+| Integration effort | Copy 3 files | Copy 6-8 files | Full implementation |
+| Feature depth | Basic | Rich (minimap, flow, groups, copy/paste) | Whatever you build |
+| Immediate mode | Yes | Partial (retained context) | Yes |
+| Performance | High | High | Depends on impl |
+| Styling control | Minimal | Extensive | Full control |
+| Serialization | None | Built-in callbacks | Build your own |
+| Community / maturity | Mature, stable | Mature, active | N/A |
+
+## 5. References
+
+- **imnodes**: https://github.com/Nelarius/imnodes
+- **imgui-node-editor**: https://github.com/thedmd/imgui-node-editor
+- **ImNodeFlow**: https://github.com/Fattorino/ImNodeFlow
+- **Blog post — Visual node graph with ImGui**: https://gboisse.github.io/posts/node-graph/
+- **Blog post — Writing imnodes**: https://nelari.us/post/imnodes
+- **ImGui issue #306** (node editor discussion): https://github.com/ocornut/imgui/issues/306
+- **ImGui useful extensions wiki**: https://github.com/ocornut/imgui/wiki/Useful-Extensions
+- **Voxagon undo/redo**: https://blog.voxagon.se/2018/07/10/undo-for-lazy-programmers.html

documents/research/rendering-hardware-interface.md

@@ -0,0 +1,612 @@
+# Rendering Hardware Interface (RHI) — Research
+
+## 1. What is an RHI
+
+A Render(ing) Hardware Interface (RHI) is the abstraction layer between a
+renderer and the platform-specific graphics API (Vulkan, DirectX 12, Metal,
+etc.). It allows the renderer to be completely API-independent while providing
+a simpler, more explicit interface than the raw API.
+
+**Key goals:**
+- API portability (write once, run on Vulkan, D3D12, Metal)
+- Clean separation: renderer talks to RHI, RHI talks to driver
+- Zero/low overhead over the native API
+- Explicit control over GPU resources, synchronisation, and memory
+
+**What an RHI is NOT:**
+- A high-level rendering engine or framework
+- An automatic resource manager
+- A scene graph or render graph
+
+---
+
+## 2. Common Architecture Patterns (from real-world RHIs)
+
+### 2.1 Object-Based RHI (orhi, SnapRHI, tobyc11/RHI)
+
+Each GPU concept maps to an explicit object with a create/destroy lifecycle.
+Objects are passed by handle/pointer to command recording functions.
+
+```
+RHI Instance  →  PhysicalDevice  →  Device  →  Queue
+Device  →  CommandPool  →  CommandBuffer
+Device  →  Buffer, Texture, Sampler
+Device  →  ShaderModule, PipelineLayout, Pipeline
+Device  →  DescriptorPool, DescriptorSetLayout, DescriptorSet
+Device  →  Fence, Semaphore, SwapChain
+```
+
+**Examples:**
+- [orhi](https://github.com/adriengivry/orhi) — C++20, Vulkan/D3D12/Metal, MIT
+- [SnapRHI](https://github.com/Snapchat/SnapRHI) — C++20, Metal/Vulkan/OpenGL, Apache 2.0
+- [NVRHI](https://github.com/NVIDIAGameWorks/nvrhi) — C++14, Vulkan/D3D12, NVIDIA
+- [RGL](https://github.com/RavEngine/RGL) — C++20, Vulkan/D3D12/Metal
+
+**Pros:**
+- Familiar mapping to Vulkan/D3D12 concepts
+- Easy to add new backends
+- Each object owns its lifetime explicitly
+
+**Cons:**
+- Boilerplate-heavy
+- API surface grows with each backend quirk exposed
+
+### 2.2 Command-List-Oriented RHI (Adept Engine, Unreal Engine)
+
+Commands are recorded into command-list objects. The renderer records draws,
+bindings, and state changes into command lists which are then submitted to the
+GPU. The RHI thread translates these into API-specific calls.
+
+```
+Renderer → RHI Command List → RHI Thread → Backend (VkCmdBuf / ID3D12GraphicsCommandList)
+```
+
+**Pros:**
+- Natural threading model (record in parallel, submit once)
+- Easy to defer and reorder commands
+- Close to D3D12/Vulkan command buffer semantics
+
+**Cons:**
+- More indirection
+- State shadowing complexity
+
+### 2.3 Immediate-Mode RHI (VRHI, NVRHI immediate mode)
+
+Functions execute synchronously. No command list abstraction — the API is
+called directly. Simpler but less performant for multi-threaded recording.
+
+**Prism choice:** Object-based + command-list-oriented. For a compositing
+application the graph evaluation can record node commands into per-frame
+command buffers.
+
+---
+
+## 3. Core API Surface (what every RHI needs)
+
+| Category | Objects | Notes |
+|---|---|---|
+| **Instance/Device** | `PrRhiInstance`, `PrRhiDevice`, `PrRhiPhysicalDevice` | Instance owns debug + layers; Device owns queues + memory |
+| **Swap chain** | `PrRhiSwapChain` | Presentation surface + frame sync |
+| **Resources** | `PrRhiBuffer`, `PrRhiTexture`, `PrRhiSampler` | GPU memory, sub-allocated via VMA-like pattern |
+| **Shaders** | `PrRhiShader` | Slang → SPIR-V → `VkShaderModule` |
+| **Pipeline** | `PrRhiPipelineLayout`, `PrRhiPipeline`, `PrRhiComputePipeline` | Compiled shader + vertex layout + state |
+| **Descriptors** | `PrRhiDescriptorPool`, `PrRhiDescriptorSetLayout`, `PrRhiDescriptorSet` | Bindless or bindful |
+| **Commands** | `PrRhiCommandPool`, `PrRhiCommandBuffer` | Per-frame recording |
+| **Sync** | `PrRhiFence`, `PrRhiSemaphore` | CPU-GPU and GPU-GPU sync |
+| **Query** | `PrRhiQueryPool` | Timestamps, occlusion |
+
+### Minimal surface for Prism MVP
+
+For a node-based compositor that renders images via shader passes, the minimum
+API surface is:
+
+```
+Device
+├── CommandPool → CommandBuffer
+├── Buffer (vertex, index, uniform/staging)
+├── Texture (read, write, render-target)
+├── Sampler
+├── Shader (from SPIR-V)
+├── PipelineLayout + Pipeline (graphics)
+├── DescriptorSetLayout + DescriptorSet (or push descriptors)
+├── Fence
+└── SwapChain (for output display)
+```
+
+---
+
+## 4. Design Decisions for Prism
+
+### 4.1 C11 / C++11 with wapp allocators
+
+The project follows C11/C++11 dual-mode from `src/wapp/`. The RHI should:
+
+- Use `WpAllocator *` for all allocations (no `new`/`delete` or raw malloc)
+- Expose opaque handle types (`PrRhiBuffer` as struct, not `VkBuffer`)
+- Keep the backend implementation in separate `.c` files per API
+- Use `wp_extern`/`wp_intern`/`wp_persist` conventions
+
+All existing wapp infrastructure (arena allocators, arrays, queues, string
+types) should be used throughout.
+
+### 4.2 Vulkan-only for now, but design for multi-backend
+
+The AGENTS.md says "Vulkan, abstracted behind an RHI". The interface should be
+designed so that a D3D12 or Metal backend could be added later without changing
+the renderer. This means:
+
+- Backend-agnostic types in the public header (`pr_rhi.h`)
+- Backend-specific implementations in `rhi/vulkan/`, `rhi/d3d12/` etc.
+- A factory pattern or compile-time dispatch for backend selection
+- No Vulkan types in the public RHI API
+
+API objects that need per-backend variance:
+- **Object creation/teardown** (always differs)
+- **Shader compilation** (SPIR-V is universal, but creation paths differ)
+- **Pipeline state** (VkPipeline vs ID3D12PipelineState)
+- **Command recording** (VkCmdBuf vs ID3D12GraphicsCommandList)
+- **Memory management** (VkDeviceMemory vs ID3D12Heap)
+
+### 4.3 Explicit over implicit
+
+The RHI should not hide Vulkan's explicit nature. If the renderer needs to
+manage descriptor sets, layout transitions, and fences, the RHI should expose
+those operations — not paper over them with OpenGL-style "bind and forget."
+
+### 4.4 Memory management: use VMA
+
+Vulkan Memory Allocator (VMA) from AMD is the de-facto standard for Vulkan
+memory management. Rather than writing our own sub-allocator, we should:
+
+- Use VMA for host+device memory allocation
+- Wrap it behind the RHI so backends can swap it out
+- Expose `PrRhiAllocation` as an opaque handle
+
+### 4.5 Descriptor management
+
+For a compositor, the number of unique descriptors per frame is bounded by the
+node graph size. Two approaches:
+
+**A) Push descriptors** (Vulkan 1.0+, no pool needed)
+- Limited to `maxPushDescriptors` (typically 32-256)
+- Simple — inline with command recording
+- Good for small numbers of parameters per node
+
+**B) Descriptor sets with per-frame pools**
+- More flexible for many resources
+- Requires pool management and reset
+- Better for texture-heavy graphs
+
+**Recommendation:** Use push descriptors for uniforms, small descriptor set
+pools for sampled textures (images). Start with descriptor set approach since
+it scales better.
+
+### 4.6 Pipeline management
+
+Pipelines in Vulkan are expensive to create. Strategy:
+
+- Hash pipeline state (shaders, blend mode, depth, etc.) → cache
+- Create pipelines lazily on first use
+- Store in a lock-free hash table (or arena-backed sorted array for
+  single-threaded graph eval)
+- Use pipeline libraries (`VK_EXT_graphics_pipeline_library`) for faster
+  creation when available
+
+For a compositor, the number of distinct pipeline configurations is small
+(blend modes, colour-grade LUTs, blit, etc.), so a simple hash map suffices.
+
+---
+
+## 5. Vulkan-Specific Considerations
+
+### 5.1 Queue selection
+
+| Queue type | Usage in compositor |
+|---|---|
+| Graphics | Main rendering (draw calls) |
+| Compute | Image processing, convolution, colour-grade |
+| Transfer | Image upload from disk, staging |
+
+The device should expose at least one graphics queue. If separate compute
+queues are available, use them for async processing. Transfer queue is
+desirable for texture loading without stalling the render loop.
+
+### 5.2 Command buffer strategy
+
+Two-level approach:
+- **Per-frame primary command buffers**: one per swap-chain image, filled by
+  graph evaluation
+- **One-shot secondary command buffers**: for transient operations (texture
+  upload, blits) using `immediate_submit` pattern
+
+Command pools should be per-frame to allow reset without synchronisation.
+
+### 5.3 Synchronisation
+
+- `VkSemaphore` for swap-chain acquire/present
+- `VkFence` for CPU-GPU sync (frame completion, upload completion)
+- Timeline semaphores (`VK_KHR_timeline_semaphore`) if compute queue is used
+  async
+
+### 5.4 Image layouts
+
+For a compositor where images flow through nodes:
+- `VK_IMAGE_LAYOUT_SHADER_READ_ONLY_OPTIMAL` — node inputs
+- `VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL` — node render targets
+- `VK_IMAGE_LAYOUT_GENERAL` — storage images (compute nodes)
+- `VK_IMAGE_LAYOUT_PRESENT_SRC_KHR` — final output
+
+Transitions happen via explicit barriers in the command buffer (or via
+`VK_KHR_synchronization2`). The RHI should expose barrier helpers.
+
+### 5.5 Debug / validation layers
+
+- Load `VK_LAYER_KHRONOS_validation` in debug builds
+- Use `VK_EXT_debug_utils` for object naming
+- Enable GPU-assisted validation for shader issues
+- Consider RenderDoc for frame debugging
+
+---
+
+## 6. Slang Shader Integration
+
+### 6.1 Why Slang
+
+- HLSL/GLSL compatible syntax
+- Module system for shared shading code (colour science, maths)
+- Single source for multiple stages (vertex+fragment in one file)
+- SPIR-V output (directly consumable by Vulkan)
+- Rich reflection API (bindings, buffer layouts, entry points)
+- Active development, Khronos exploratory forum
+
+### 6.2 Compilation pipeline
+
+```
+.slang file
+  → slangc (offline) or libslang (runtime)
+    → SPIR-V binary
+      → vkCreateShaderModule
+        → PrRhiShader
+```
+
+Options:
+- **Offline**: Pre-compile `.slang` → `.spv` at build time. Simpler, no runtime
+  compiler dependency. Good for shipped shaders.
+- **Runtime**: Use libslang to compile at app startup (or on first use).
+  Enables shader hot-reload during development.
+
+**Recommendation:** Offline for release, runtime for debug/dev. The
+nvpro-samples `vk_slang_editor` demonstrates both approaches.
+
+### 6.3 Reflection-driven pipeline creation
+
+Slang's reflection API (`slang::ProgramLayout`) provides:
+- Binding locations (set, binding, space)
+- Buffer member offsets and sizes
+- Entry point names and stage types
+- Specialisation constant info
+
+The RHI can use this to automatically build:
+- `VkDescriptorSetLayout` from declared bindings
+- `VkPipelineLayout` from descriptor set layouts + push constants
+- Push constant ranges from reflected constant buffers
+
+See the [Slang Reflection API docs](https://shader-slang.com/slang/user-guide/reflection)
+and the [vk_slang_editor](https://github.com/nvpro-samples/vk_slang_editor)
+source for concrete patterns.
+
+### 6.4 Shader organisation for a compositor
+
+```
+src/shaders/
+├── common/
+│   ├── math.slang         — Matrix/vector utilities
+│   ├── colour.slang       — Colour space conversions
+│   └── compositing.slang  — Blend equations, alpha handling
+├── blit.slang             — Full-screen quad draw
+├── blend.slang            — Over/under/add blend modes
+├── grade.slang            — Colour grading (lift/gamma/gain)
+├── blur.slang             — Separable gaussian blur
+└── read.slang             — Simple texture passthrough
+```
+
+Each shader file contains both vertex and fragment stages:
+
+```slang
+// blit.slang
+[shader("vertex")]
+void vs_main(...) { ... }
+
+[shader("fragment")]
+void fs_main(...) { ... }
+```
+
+---
+
+## 7. Reference Projects
+
+| Project | Language | APIs | Notable features |
+|---|---|---|---|
+| **[orhi](https://github.com/adriengivry/orhi)** | C++20 | Vulkan, D3D12, Metal (planned) | Clean object hierarchy, CMake, MIT |
+| **[SnapRHI](https://github.com/Snapchat/SnapRHI)** | C++20 | Metal, Vulkan, OpenGL/ES | Compile-switchable validation (if constexpr), aggressive pooling |
+| **[tobyc11/RHI](https://github.com/tobyc11/RHI)** | C++ | Vulkan, D3D11 | SPIR-V as common shader format, SPIRV-Cross for translation |
+| **[NVRHI](https://github.com/NVIDIAGameWorks/nvrhi)** | C++14 | Vulkan, D3D12 | Production-grade, NVIDIA maintained, header-only-ish API |
+| **[RGL](https://github.com/RavEngine/RGL)** | C++20 | Vulkan, D3D12, Metal | Thin wrapper, focuses on simplicity |
+| **[The Forge](https://github.com/ConfettiFX/The-Forge)** | C99/C++11 | All major APIs | Cross-platform, used in shipping games, FS |
+| **[O3DE Atom RHI](https://docs.o3de.org/docs/atom-guide/dev-guide/rhi/rhi/)** | C++17 | Vulkan, D3D12, Metal | Full-featured engine RHI, frame scheduler, multi-threaded |
+| **[Magma](https://github.com/vcoda/magma)** | C++17 | Vulkan | C++ abstraction, uses VMA, SPIR-V reflection |
+| **[rafx](https://github.com/zeozeozeo/rafx)** | C/C++ | Vulkan, D3D12 | C API (good FFI), explicit design |
+
+### What to borrow from each
+
+| Project | Lesson |
+|---|---|
+| **orhi** | Object hierarchy + backend-agnostic headers pattern |
+| **SnapRHI** | Compile-switchable validation; per-frame resource pooling |
+| **NVRHI** | Header-only-ish API with implementation in .cpp |
+| **The Forge** | C99-friendly, explicit API with minimal hidden state |
+| **O3DE Atom** | Frame scheduler concept (render passes as graph nodes) |
+| **RGL** | Simplicity — don't over-abstract |
+| **Magma** | VMA integration pattern + SPIR-V reflection |
+| **rafx** | C API design (relevant since Prism is C11) |
+
+---
+
+## 8. Proposed Architecture for Prism
+
+### 8.1 Directory layout
+
+```
+src/prism/
+├── rhi/
+│   ├── pr_rhi.h                ← Umbrella header: canonical API + dispatch
+│   ├── pr_rhi_types.h          ← Shared types (PrRhiBufferDesc, etc.)
+│   ├── vulkan/
+│   │   ├── pr_rhi_vk.h         ← Declares prRhiCreateDeviceVk, etc.
+│   │   ├── pr_rhi_vk_aliases.h ← #define prRhiCreateDevice prRhiCreateDeviceVk
+│   │   ├── pr_rhi_vk_device.c
+│   │   ├── pr_rhi_vk_buffer.c
+│   │   ├── pr_rhi_vk_texture.c
+│   │   ├── pr_rhi_vk_shader.c
+│   │   ├── pr_rhi_vk_pipeline.c
+│   │   ├── pr_rhi_vk_descriptor.c
+│   │   ├── pr_rhi_vk_command.c
+│   │   └── pr_rhi_vk_swapchain.c
+│   ├── d3d12/                  ← (future)
+│   └── metal/                  ← (future)
+└── ...
+```
+
+### 8.2 Object lifecycle pattern
+
+```c
+// Creation: takes an allocator + device + desc, returns handle
+PrRhiBuffer *prRhiCreateBuffer(PrRhiDevice *device, const PrRhiBufferDesc *desc,
+                                WpAllocator *alloc);
+
+// Destruction: frees all GPU resources + backing memory
+void prRhiDestroyBuffer(PrRhiBuffer *buffer, WpAllocator *alloc);
+
+// Usage: command buffer records operations on handles
+void prRhiCmdCopyBuffer(PrRhiCommandBuffer *cb,
+                         PrRhiBuffer *src, PrRhiBuffer *dst);
+```
+
+### 8.3 Backend dispatch (compile-time via preprocessor aliases)
+
+Backend selection happens at compile time via preprocessor aliases — no vtbl,
+no runtime dispatch overhead. Each backend is a set of standalone `.c` files;
+the build system compiles only the selected backend's sources.
+
+```
+src/prism/rhi/
+├── pr_rhi.h                     ← umbrella: canonical API + dispatch
+├── pr_rhi_types.h               ← shared types (all backends include this)
+├── vulkan/
+│   ├── pr_rhi_vk.h              ← declares prRhiCreateDeviceVk, etc.
+│   ├── pr_rhi_vk_aliases.h      ← #define prRhiCreateDevice prRhiCreateDeviceVk
+│   ├── pr_rhi_vk_device.c
+│   └── pr_rhi_vk_buffer.c
+├── d3d12/
+│   ├── pr_rhi_d3d12.h           ← declares prRhiCreateDeviceD3D12, etc.
+│   ├── pr_rhi_d3d12_aliases.h   ← #define prRhiCreateDevice prRhiCreateDeviceD3D12
+│   └── pr_rhi_d3d12_device.c
+└── metal/
+    ├── pr_rhi_metal.h
+    ├── pr_rhi_metal_aliases.h
+    └── pr_rhi_metal_device.c
+```
+
+The umbrella header documents the public API and conditionally includes the
+selected backend's aliases:
+
+```c
+// pr_rhi.h
+#ifndef PR_RHI_H
+#define PR_RHI_H
+
+#include "pr_rhi_types.h"
+
+// ── Public API (documented here) ────────────────────────────────────
+PrRhiDevice *prRhiCreateDevice(const PrRhiDeviceDesc *desc, WpAllocator *alloc);
+void         prRhiDestroyDevice(PrRhiDevice *device, WpAllocator *alloc);
+PrRhiBuffer *prRhiCreateBuffer(PrRhiDevice *d, const PrRhiBufferDesc *desc, WpAllocator *a);
+void         prRhiDestroyBuffer(PrRhiBuffer *b, WpAllocator *a);
+// ... etc
+
+// ── Backend dispatch ──────────────────────────────────────────────
+#if defined(PR_RHI_VULKAN)
+#  include "vulkan/pr_rhi_vk_aliases.h"
+#elif defined(PR_RHI_D3D12)
+#  include "d3d12/pr_rhi_d3d12_aliases.h"
+#elif defined(PR_RHI_METAL)
+#  include "metal/pr_rhi_metal_aliases.h"
+#else
+#  error "Define one of: PR_RHI_VULKAN, PR_RHI_D3D12, PR_RHI_METAL"
+#endif
+
+#endif
+```
+
+Each aliases header maps the generic names to the backend's concrete names:
+
+```c
+// vulkan/pr_rhi_vk_aliases.h
+#ifndef PR_RHI_VK_ALIASES_H
+#define PR_RHI_VK_ALIASES_H
+
+#include "pr_rhi_vk.h"
+
+#define prRhiCreateDevice   prRhiCreateDeviceVk
+#define prRhiDestroyDevice  prRhiDestroyDeviceVk
+#define prRhiCreateBuffer   prRhiCreateBufferVk
+#define prRhiDestroyBuffer  prRhiDestroyBufferVk
+
+#endif
+```
+
+The backend implementation headers declare only their own real names:
+
+```c
+// vulkan/pr_rhi_vk.h
+#ifndef PR_RHI_VK_H
+#define PR_RHI_VK_H
+
+#include "../pr_rhi_types.h"
+
+PrRhiDevice *prRhiCreateDeviceVk(const PrRhiDeviceDesc *desc, WpAllocator *alloc);
+void         prRhiDestroyDeviceVk(PrRhiDevice *device, WpAllocator *alloc);
+// ...
+
+#endif
+```
+
+Backend `.c` files are normal standalone translation units — no `.c` inclusion:
+
+```c
+// vulkan/pr_rhi_vk_device.c
+#include "pr_rhi_vk.h"
+
+PrRhiDevice *prRhiCreateDeviceVk(const PrRhiDeviceDesc *desc, WpAllocator *alloc) {
+    // ...
+}
+```
+
+Render code uses the generic names via the umbrella:
+
+```c
+#include "prism/rhi/pr_rhi.h"
+
+int main(void) {
+    PrRhiDevice *dev = prRhiCreateDevice(&desc, &scratch);  // → prRhiCreateDeviceVk
+    // ...
+}
+```
+
+Or explicitly selects a backend by including its header directly:
+
+```c
+#include "prism/rhi/vulkan/pr_rhi_vk.h"
+
+int main(void) {
+    PrRhiDevice *dev = prRhiCreateDeviceVk(&desc, &scratch); // real name, no alias
+    // ...
+}
+```
+
+The build system controls selection by defining the preprocessor macro and
+listing only the chosen backend's `.c` files:
+
+```sh
+# Vulkan build
+clang -DPR_RHI_VULKAN \
+    main.c \
+    src/prism/rhi/vulkan/pr_rhi_vk_device.c \
+    src/prism/rhi/vulkan/pr_rhi_vk_buffer.c \
+    src/wapp/wapp.c \
+    -o compositor
+```
+
+**Properties:**
+- Zero runtime overhead (macro expansion is a text substitution)
+- Dead code elimination is automatic — unselected backends are never compiled
+- Transparent debugging — stack traces show `prRhiCreateDeviceVk` directly
+- Documentation lives in one place — the umbrella `pr_rhi.h`
+- Each backend is a proper compilation unit — no `#include` of `.c` files
+- Explicit override path for single-backend builds or testing
+
+### 8.4 Frame lifecycle
+
+```
+Loop:
+  1. prRhiAcquireNextImage(swapchain)          → image index, semaphore
+  2. prRhiResetCommandPool(pool, frame_idx)     → recycles command buffers
+  3. For each node in topo-sorted graph:
+     a. prRhiCmdBindPipeline(cb, pipeline)
+     b. prRhiCmdBindDescriptorSets(cb, ...)
+     c. prRhiCmdPushConstants(cb, ...)
+     d. prRhiCmdDraw(cb, ...)
+  4. prRhiQueueSubmit(queue, cb, wait_sem, signal_sem, fence)
+  5. prRhiPresent(swapchain, signal_sem)
+  6. prRhiWaitForFence(fence)                  → CPU-GPU sync
+```
+
+### 8.5 Static allocation strategy
+
+Following wapp conventions and the project's data-oriented design principles:
+
+- **Command pools**: one per swap-chain image (2-3), allocated once
+- **Descriptor pools**: one per frame, reset each frame
+- **Upload buffers**: ring buffer for staging data, bumped each frame
+- **Pipeline cache**: arena-backed hash table, populated lazily
+- **Scratch buffers**: arena-allocated in the per-frame scratch space
+
+No dynamic allocation on the hot path — all per-frame memory comes from
+frame-local arena allocators that are reset at the start of each frame.
+
+---
+
+## 9. Open Questions
+
+1. **Multi-queue**: Should the RHI expose separate compute/transfer queues, or
+   keep everything on a single graphics queue and serialise? For an MVP, single
+   queue is simpler and likely sufficient.
+
+2. **Bindless vs bindful**: Bindless descriptors (VK_EXT_descriptor_indexing)
+   simplify shader resource access but require higher Vulkan version. For
+   maximum compatibility, start with bindful descriptor sets.
+
+3. **Shader compilation**: Use `slangc` at build time and ship SPIR-V, or link
+   libslang for runtime compilation + reflection? Runtime enables hot-reload
+   but adds ~15MB to binary size. Recommendation: both — offline for release,
+   runtime for debug.
+
+4. **Swap chain**: Headless mode (no window) for batch/compute-only operation?
+   Useful for a compositor that renders to a file. The RHI should support
+   both windowed and headless modes.
+
+5. **Vulkan version**: Target Vulkan 1.3 (widely available on desktop, adds
+   timeline semaphores, dynamic rendering, and sync2) with fallback to 1.2.
+
+---
+
+## References
+
+- [O3DE Atom RHI Overview](https://docs.o3de.org/docs/atom-guide/dev-guide/rhi/rhi/)
+- [Adept Engine RHI Design](https://andrewcjp.wordpress.com/2019/11/09/designing-a-render-hardware-interface-for-explicit-multi-gpu-programming/)
+- [Unreal Engine RHI Architecture](https://dev.epicgames.com/documentation/unreal-engine/parallel-rendering-overview-for-unreal-engine)
+- [orhi — OpenRHI](https://github.com/adriengivry/orhi)
+- [SnapRHI](https://github.com/Snapchat/SnapRHI)
+- [NVRHI](https://github.com/NVIDIAGameWorks/nvrhi)
+- [The Forge](https://github.com/ConfettiFX/The-Forge)
+- [RGL](https://github.com/RavEngine/RGL)
+- [tobyc11/RHI](https://github.com/tobyc11/RHI)
+- [rafx](https://github.com/zeozeozeo/rafx)
+- [Magma](https://github.com/vcoda/magma)
+- [Vulkan Memory Allocator](https://github.com/GPUOpen-LibrariesAndSDKs/VulkanMemoryAllocator)
+- [Slang Shading Language](https://github.com/shader-slang/slang)
+- [Slang Reflection API](https://shader-slang.com/slang/user-guide/reflection)
+- [vk_slang_editor](https://github.com/nvpro-samples/vk_slang_editor)
+- [Vulkan in 30 minutes](https://renderdoc.org/vulkan-in-30-minutes.html)
+- [Vulkan Memory Management Guide](https://docs.vulkan.org/guide/latest/memory_allocation.html)
+- [Khronos Vulkan Spec — Command Buffers](https://docs.vulkan.org/spec/latest/chapters/cmdbuffers.html)

documents/research/shader-architecture-patterns.md

@@ -0,0 +1,346 @@
+# Shader Architecture Patterns for Node-Based Image Compositing
+
+Research conducted 2026-07-13.
+
+---
+
+## 1. Single Shader vs Multiple Shaders
+
+### How Professional Compositors Handle It
+
+**Blender Compositor (GPU backend)** — The most relevant case study:
+- Blender's GPU compositor collapses multiple connected nodes into a **"compile unit"** and generates a **single compute shader** per unit.
+- The `ShaderOperation` class iterates through a `compile_unit_` (a set of nodes) and links their GLSL logic into one shader: `source/blender/compositor/intern/shader_operation.cc:122-135`.
+- Simple per-pixel operations (Math, Color Mix, Invert, etc.) are fused into a single pass. Operations that can't be expressed as shaders fall back to `MultiFunctionProcedureOperation` on CPU.
+- **Key insight**: Blender uses a **hybrid approach** — fuse what you can into single shaders, fall back to separate passes for complex operations (blur, glare, convolution).
+
+**Natron** — CPU-based compositor using OpenFX plugins:
+- Each node is a separate processing unit (separate plugin call).
+- Multi-threaded tile-based processing per node.
+- Not GPU-accelerated; no shader fusion.
+
+**DaVinci Resolve / Fusion** — Proprietary:
+- Uses a node graph where each node can have internal multi-pass processing.
+- Fusion's "Flow Region" system groups nodes for optimization.
+- Effectively separate shaders per node, with internal optimization.
+
+### Recommended Approach for Prism
+
+**Use separate shaders per node, with optional fusion of simple nodes.** Rationale:
+- Nodes in a compositing graph have diverse operations (blur vs. blend vs. color grade). An uber-shader would have massive register pressure and poor occupancy.
+- Simple per-pixel operations (math, color mix, gamma) can be fused into chains as an optimization.
+- Complex operations (blur, convolutions, warps) need their own shader passes anyway.
+
+---
+
+## 2. Texture Ping-Ponging
+
+### The Pattern
+
+Texture ping-ponging is the fundamental technique for chaining GPU image operations:
+
+1. Allocate two textures (A and B) at the target resolution.
+2. Bind texture A as input, render to texture B.
+3. Swap: bind texture B as input, render to texture A.
+4. Repeat for as many passes as needed.
+
+```
+Pass 1: Read(A) → Write(B)   [e.g., blur]
+Pass 2: Read(B) → Write(A)   [e.g., color grade]
+Pass 3: Read(A) → Write(B)   [e.g., blend]
+Final:  Display(B)
+```
+
+### How It Works in Practice
+
+**WebGL/Fragment Shader approach** (from multiple sources):
+- Create Framebuffer Objects (FBOs) with texture attachments.
+- Bind FBO → render fullscreen quad → output goes to texture.
+- Bind different FBO or default framebuffer → read from that texture.
+
+**Vulkan approach**:
+- Use `VkImage` objects as both sampler inputs and render targets.
+- Between passes, issue a pipeline barrier (`VK_PIPELINE_STAGE_FRAGMENT_SHADER_BIT → VK_PIPELINE_STAGE_COLOR_ATTACHMENT_OUTPUT_BIT`).
+- Manage image layouts: `SHADER_READ_ONLY_OPTIMAL` → `COLOR_ATTACHMENT_OPTIMAL` → `SHADER_READ_ONLY_OPTIMAL`.
+
+**Metal approach** (from Kosikowski's article):
+- Compute shaders read from `inTexture` and write to `outTexture`.
+- Swap the texture references between passes.
+
+### Important Considerations
+
+- **Image layout transitions** are critical in Vulkan. Each pass requires the texture to be in the correct layout.
+- **Load/store ops**: For intermediate textures, use `VK_ATTACHMENT_LOAD_OP_DONT_CARE` and `VK_ATTACHMENT_STORE_OP_DONT_CARE` when contents aren't needed — saves bandwidth.
+- **Resolution management**: Different nodes may operate at different resolutions. The compositor must manage a texture pool and handle up/downsampling.
+- **On tile-based GPUs (mobile)**: Multiple passes that write/read intermediate textures to external memory is expensive. Use Vulkan subpasses or `VK_KHR_dynamic_rendering_local_read` to keep data on-chip.
+
+---
+
+## 3. Shader Composition Strategies
+
+### 3a. Runtime Shader Generation
+
+**Blender's approach** (most relevant):
+- The compositor has a `gpu_shader_compositor_code_generation.glsl` library.
+- `ShaderOperation` generates GLSL code by iterating through a compile unit's nodes and concatenating their shader code contributions.
+- The generated code is compiled via Blender's `GPUMaterial` system.
+- Node settings are passed as UBOs; images are bound as `image2D`/`sampler2D`.
+
+**Godot's compositor approach**:
+- Uses a **template + injection** pattern:
+  ```
+  const template_shader = """
+  #version 450
+  layout(local_size_x = 8, local_size_y = 8, local_size_z = 1) in;
+  layout(rgba16f, set = 0, binding = 0) uniform image2D color_image;
+  void main() {
+      // ... boilerplate ...
+      vec4 color = imageLoad(color_image, uv);
+      #COMPUTE_CODE
+      imageStore(color_image, uv, color);
+  }
+  """
+  ```
+- User shader code replaces `#COMPUTE_CODE` at runtime.
+- Compiled via `rd.shader_create_from_spirv()` at runtime.
+
+**OGRE's RTSS (Run Time Shader System)**:
+- Not an uber-shader. Manages a set of opaque `SubRenderState` components.
+- Each component implements a specific effect.
+- Components are composed and code-generated at runtime.
+- Avoids the "exploding `#ifdef`" problem of uber-shaders.
+
+### 3b. Shader Permutations vs Branching
+
+**The permutation problem** (from MJP's detailed analysis):
+- Each feature combination = separate compiled shader.
+- Exponential growth: N binary features = 2^N permutations.
+- Costs: compilation time, memory, PSO creation, binding overhead, instruction cache pressure.
+- **Register pressure**: Uber-shaders with many features need more registers, reducing occupancy even for materials that don't use all features.
+
+**Branching rules for GPUs**:
+- **Uniform branches** (same path for all pixels in a warp): Essentially free. The driver compiles both paths and selects one.
+- **Divergent branches** (different paths within a warp): Both paths execute serially, wasting cycles.
+- **Branches on uniforms/constant data**: OK and performant.
+- **Branches based on per-pixel data**: Expensive when pixels in the same warp diverge.
+
+**Best practice**: Use **Vulkan specialization constants** for compile-time branching (uber-shader with static branching). This gives you permutation-like performance with fewer actual shader binaries. The driver can optimize away dead code paths.
+
+### 3c. Compute Shaders vs Fragment Shaders
+
+**Fragment shaders are generally faster for simple image processing:**
+- Fragment shaders benefit from hardware texture prefetch and caching optimized for 2D spatial locality.
+- For simple per-pixel operations (passthrough, basic color transforms): fragment shaders ~30% faster than compute (Leadwerks benchmarks: 770 FPS vs 600 FPS).
+- For multi-pass chained operations: fragment shaders maintain advantage (670 FPS vs 180 FPS at 10 passes).
+
+**Compute shaders are better when:**
+- You need **shared memory** access within workgroups (e.g., local convolution, shared reductions).
+- You need **read-write access** to the same texture (e.g., iterative algorithms like Jump Flood).
+- You're doing operations that aren't naturally per-pixel (histogram, reduction, sorting).
+- You want explicit control over workgroup dispatch.
+
+**On tile-based GPUs (mobile)**: Arm documentation explicitly warns: "Compute shaders can be slower and less energy-efficient than fragment shaders for simple post-processing workloads."
+
+**For compositing**: Use fragment shaders for per-pixel operations (blend, color grade, transform). Use compute for multi-pass algorithms that need shared memory (blur separable passes, glare FFT, flood fill).
+
+### 3d. Bindless Textures and Descriptor Arrays
+
+**The concept**: Instead of binding one texture per descriptor set, bind a large array of descriptors once. Access textures by integer index in shaders.
+
+**Vulkan implementation** (from `VK_EXT_descriptor_indexing`, core since Vulkan 1.2):
+```glsl
+// GLSL
+#extension GL_EXT_nonuniform_qualifier : enable
+layout(set = 1, binding = 10) uniform sampler2D textures[];
+vec4 color = texture(textures[albedo_id], uv);
+```
+
+**Key features**:
+- `VK_DESCRIPTOR_BINDING_UPDATE_AFTER_BIND_BIT`: Update descriptors after binding.
+- `VK_DESCRIPTOR_BINDING_PARTIALLY_BOUND_BIT`: Not all slots need valid descriptors.
+- `NonUniformResourceIndex`: For divergent indexing within a warp.
+
+**For a compositor**: Bindless is extremely useful. All input textures from the graph can live in one descriptor set. Each node shader indexes into the set by texture ID. This avoids re-binding descriptor sets per node.
+
+**Trade-off**: Indirect memory loads can be slower on some mobile GPUs. Desktop GPUs handle this well.
+
+---
+
+## 4. Slang-Specific Patterns
+
+### Overview
+
+Slang is a Khronos-hosted, open-source shading language. HLSL-like syntax with modern features:
+- Targets: SPIR-V (Vulkan), DXIL (D3D12), Metal, CUDA, WGSL, CPU.
+- Hosted by Khronos with broad industry governance.
+- Based on years of NVIDIA/CMU/Stanford/MIT research.
+
+### Key Features Relevant to Compositing
+
+**Modules**: Slang supports `module` and `import` for separate compilation. Modules compile to a custom IR and can be linked at runtime to produce SPIR-V or DXIL. This is **exactly what a node compositor needs** — each node type can be a module, and compositions are linked at runtime.
+
+**Generics and Interfaces**: Instead of #ifdef permutations, use generics:
+```slang
+interface IImageOp {
+    float4 evaluate(float4 input, PixelContext ctx);
+}
+
+struct BlendOp : IImageOp {
+    float4 evaluate(float4 input, PixelContext ctx) { ... }
+}
+
+// Generic function specialized at compile time
+T evaluateGraph<T : IImageOp>(T op, float4 input) {
+    return op.evaluate(input, ctx);
+}
+```
+
+**Runtime code generation**: Slang supports **runtime compilation and linking**. From the docs: "Slang modules can be independently compiled offline to a custom IR and then linked at runtime to generate code in formats such as DXIL or SPIR-V." This means you can:
+1. Compile each node's shader as a Slang module.
+2. At graph edit time, link modules together.
+3. Generate the final SPIR-V/DXIL for the composed graph.
+
+**Reflection API**: `TypeReflection`, `VariableReflection`, `getLayout()` allow querying shader structure at runtime — useful for automatically creating descriptor layouts.
+
+**Automatic Differentiation**: `fwd_diff` and `bwd_diff` for gradient-based operations (relevant for differentiable compositing or learned operations).
+
+### Slang vs GLSL/HLSL for Compositing
+
+| Feature | Slang | GLSL | HLSL |
+|---------|-------|------|------|
+| Separate compilation | ✅ Modules | ❌ Single TU | ⚠️ Limited |
+| Runtime linking | ✅ | ❌ | ❌ |
+| Generics/interfaces | ✅ | ❌ | ⚠️ Templates (limited) |
+| Cross-platform | ✅ (Vulkan/Metal/DX/CUDA) | ⚠️ (OpenGL/Vulkan) | ⚠️ (DX only) |
+| Vulkan SPIR-V | ✅ First-class | ✅ via glslc | ⚠️ via dxc |
+| Runtime compilation | ✅ | ❌ | ❌ |
+| HLSL compatibility | ✅ Most HLSL compiles out-of-box | ❌ | ✅ |
+
+### Recommendation
+
+**Slang is the ideal choice for a Vulkan-based compositor.** Its module system directly solves the "runtime shader composition" problem. Each node type = a Slang module. Graph composition = module linking. No need for runtime string-based code generation.
+
+---
+
+## 5. Vulkan-Specific Considerations
+
+### Multi-Pass Image Processing
+
+**Render Pass approach** (traditional):
+```c
+// Pass 1: Blur
+VkRenderPassBeginInfo rp1 = { .renderPass = blurPass, .framebuffer = blurFBO };
+vkCmdBeginRenderPass(cmd, &rp1, VK_SUBPASS_CONTENTS_INLINE);
+vkCmdBindPipeline(cmd, VK_PIPELINE_BIND_POINT_GRAPHICS, blurPipeline);
+vkCmdDraw(cmd, 4, 1, 0, 0); // fullscreen quad
+vkCmdEndRenderPass(cmd);
+
+// Barrier between passes
+VkImageMemoryBarrier barrier = {
+    .srcAccessMask = VK_ACCESS_COLOR_ATTACHMENT_WRITE_BIT,
+    .dstAccessMask = VK_ACCESS_SHADER_READ_BIT,
+    .oldLayout = VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL,
+    .newLayout = VK_IMAGE_LAYOUT_SHADER_READ_ONLY_OPTIMAL,
+};
+vkCmdPipelineBarrier(cmd, ...);
+
+// Pass 2: Color grade
+VkRenderPassBeginInfo rp2 = { .renderPass = gradePass, .framebuffer = gradeFBO };
+vkCmdBeginRenderPass(cmd, &rp2, VK_SUBPASS_CONTENTS_INLINE);
+vkCmdBindDescriptorSets(cmd, ..., gradeDescriptorSet); // binds blur result as texture
+vkCmdBindPipeline(cmd, VK_PIPELINE_BIND_POINT_GRAPHICS, gradePipeline);
+vkCmdDraw(cmd, 4, 1, 0, 0);
+vkCmdEndRenderPass(cmd);
+```
+
+**Dynamic Rendering approach** (Vulkan 1.3 / `VK_KHR_dynamic_rendering`):
+- Skip `VkRenderPass` and `VkFramebuffer` objects entirely.
+- Use `vkCmdBeginRendering` with `VkRenderingInfo` specifying attachments directly.
+- Simpler API, fewer objects to manage.
+
+### Descriptor Management Best Practices
+
+From ARM and NVIDIA guidelines:
+- **Don't allocate descriptor sets on hot paths.** Pre-allocate pools.
+- **Use `VK_DESCRIPTOR_TYPE_UNIFORM_BUFFER_DYNAMIC` / `VK_DESCRIPTOR_TYPE_STORAGE_BUFFER_DYNAMIC`** for per-draw offsets instead of new descriptor sets.
+- **Pack descriptor bindings** as tightly as possible. No holes.
+- **Reuse descriptor sets** — update them rather than reallocating.
+- For a compositor with bindless: create ONE large descriptor set with all textures. Bind once, index by ID.
+
+### Pipeline Layout Optimization
+
+- Keep pipeline layouts consistent across similar shaders to reduce pipeline switches.
+- Use **push constants** for small, per-pass data (resolution, time, parameters) — cheaper than UBOs for small data.
+- Pre-create pipeline cache and use `VkPipelineCache` to speed up PSO creation.
+
+### Synchronization for Multi-Pass
+
+- Use **pipeline barriers** between passes that read/write the same images.
+- For independent passes (operating on different textures), no barrier needed — can even record in parallel.
+- Use **events** for fine-grained synchronization within a command buffer.
+- **Timeline semaphores** (Vulkan 1.2+) for more flexible GPU-GPU synchronization.
+
+### Tile-Based GPU Optimization (Mobile)
+
+- Use **subpasses** to keep intermediate data in tile memory (on-chip).
+- `VK_KHR_dynamic_rendering_local_read` allows subpass-like behavior with dynamic rendering.
+- Set `loadOp = VK_ATTACHMENT_LOAD_OP_DONT_CARE` and `storeOp = VK_ATTACHMENT_STORE_OP_DONT_CARE` for transient intermediates.
+- Merge subpasses when they share attachments (ARM: ≤8 unique attachments).
+
+---
+
+## 6. Industry Best Practices
+
+### The Render Graph Pattern
+
+Modern engines use a **frame graph** / **render graph** (DAG) for multi-pass rendering:
+1. **Declare passes** and their resource inputs/outputs.
+2. **Analyze dependencies** — build execution order automatically.
+3. **Infer synchronization** — barriers are generated from resource usage.
+4. **Alias resources** — textures with non-overlapping lifetimes can share memory.
+5. **Cull unused passes** — if an output isn't used, skip the pass.
+
+This is the most mature pattern for managing multi-pass image processing. Referenced in:
+- Vulkan Tutorial: "Engine Architecture: Rendering Pipeline"
+- Cat Game's "Advanced Vulkan Rendering: Building a Modern Frame Graph"
+- Frostbite's "FrameGraph" (EA/DICE)
+
+### Fusing Operations
+
+From TFLite GPU and Blender compositor:
+- **Fuse element-wise operations** with computationally expensive ones (activations + convolution, color transforms + blend).
+- **Inline parameters** directly into shader code instead of passing via uniforms (bakes constants, reduces memory I/O).
+- **Bake uniforms into source code** when they don't change per-pixel.
+
+### Texture Pool Management
+
+For a compositor with potentially many intermediate textures:
+- Pre-allocate a pool of textures at common resolutions.
+- Reference-count or track lifetime of each texture.
+- Reuse textures with matching format/resolution once their producer is done.
+- On mobile, prefer smaller intermediate formats (RGBA16F over RGBA32F when precision allows).
+
+### Papers and References
+
+1. **"Performance Implications of Node Graph Complexity in Real-Time Compositing"** (IEEE, 2024) — Studies Blender EEVEE's node graph rendering performance vs. structural complexity.
+2. **"Compute Shader in Image Processing Development"** (CEUR Workshop, 2020) — Compares CPU, fragment, compute, and Vulkan fragment for image processing. Found compute shader overhead makes it slower for simple operations.
+3. **Blender Real-time Compositor** (code.blender.org, 2022) — GPU-accelerated compositor architecture with operation graph, domain system, and shader-based execution.
+4. **"The Shader Permutation Problem"** (MJP, 2021) — Comprehensive analysis of uber-shader vs. permutation trade-offs.
+5. **"GPU Rendering Pipeline: Blend Modes, Porter-Duff Compositing"** (Lucio Durán, 2025) — Browser rendering pipeline compositing patterns.
+6. **"High-Performance Software Rasterization on GPUs"** (NVIDIA Research, 2011) — Software GPU pipeline, relevant for understanding GPU architecture.
+7. **Vulkan Samples** (Khronos) — Descriptor management, subpasses, async compute, tile-based rendering best practices.
+
+### Recommended Architecture for Prism
+
+Based on all research:
+
+1. **DAG-based execution**: Topological sort the node graph. Execute in dependency order.
+2. **Separate shaders per node type**: Each node type (Blend, ColorGrade, Blur, etc.) has a dedicated Slang shader module.
+3. **Runtime composition via Slang modules**: Simple chains of per-pixel operations can be fused into single compute/fragment passes by linking their Slang modules.
+4. **Texture pool**: Pre-allocated RGBA16F textures. Reference-counted. Reuse when possible.
+5. **Ping-pong for chains**: Two textures alternating for sequential per-pixel chains.
+6. **Fragment shaders for per-pixel ops**, compute shaders for operations needing shared memory (blur, convolution, reduction).
+7. **Bindless descriptors**: One large descriptor set with all input textures. Node shaders index by texture ID.
+8. **Push constants** for per-pass uniforms (resolution, parameters).
+9. **Pipeline barriers** between passes on the same texture. No barriers for independent passes.
+10. **Render graph** for automatic dependency tracking and synchronization.

documents/resources.md

@@ -0,0 +1,17 @@
+# Useful resources
+
+## Graphs
+
+- [The Algorithm Design Manual](https://sureshcseit.wordpress.com/wp-content/uploads/2021/04/skienathealgorithmdesignmanual.pdf)
+- [Topological Sorting using BFS (Kahn's Algorithm)](https://www.geeksforgeeks.org/topological-sorting-indegree-based-solution/)
+- [Kahn's Algorithm Explained with Code & Examples](https://dev.to/rui_jiang/kahns-algorithm-for-topological-sorting-explained-with-code-examples-2if5)
+- [Understanding Kahn's Algorithm for Topological Sorting](https://blog.devgenius.io/dsa-kahns-algorithm-for-topological-sorting-33c8587985a1)
+- [Detect a Cycle in Directed Graph](https://takeuforward.org/data-structure/detect-a-cycle-in-directed-graph-topological-sort-kahns-algorithm-g-23)
+- [Kahn's Algorithm](https://leetcodethehardway.com/tutorials/graph-theory/kahns-algorithm)
+
+## Rendering Hardware Interface (RHI)
+
+- [O3DE Atom RHI Overview](https://docs.o3de.org/docs/atom-guide/dev-guide/rhi/rhi/)
+- [Adept Engine RHI Design](https://andrewcjp.wordpress.com/2019/11/09/designing-a-render-hardware-interface-for-explicit-multi-gpu-programming/)
+- [Unreal Engine RHI Architecture](https://dev.epicgames.com/documentation/unreal-engine/parallel-rendering-overview-for-unreal-engine)
+- [NVRHI](https://github.com/NVIDIAGameWorks/nvrhi) — NVIDIA's production RHI (Vulkan/D3D12), reference API design

documents/rhi-global-context.md

@@ -0,0 +1,115 @@
+# Plan: RHI Global Context
+
+## Goal
+
+Replace per-call `WpAllocator *allocator` parameters with a global `PrRhiContext`
+managed by the RHI. The RHI owns the lifetime of all objects it creates.
+
+## Changes
+
+### 1. `src/prism/rhi/pr_rhi_types.h` — Add context struct
+
+Add after the existing typedefs:
+
+```c
+typedef struct PrRhiContext {
+	WpAllocator main;     // objects returned to the user
+	WpAllocator scratch;  // internal temporaries within functions
+} PrRhiContext;
+```
+
+### 2. `src/prism/rhi/pr_rhi.h` — Public API changes
+
+- Add `wp_extern PrRhiContext _G_RHI_CONTEXT;` declaration (near top, after includes)
+- Add `wp_extern b8 prRhiInit(void);` and `wp_extern void prRhiDestroy(void);`
+- Remove `WpAllocator *allocator` (and `const WpAllocator *allocator`) from **all** function signatures
+
+### 3. `src/prism/rhi/pr_rhi.c` — New file (shared across backends)
+
+```c
+#include "pr_rhi.h"
+
+PrRhiContext _G_RHI_CONTEXT;
+
+b8 prRhiInit(void) {
+	_G_RHI_CONTEXT.main    = wpMemArenaAllocatorInit(MiB(64));
+	_G_RHI_CONTEXT.scratch = wpMemArenaAllocatorInit(MiB(32));
+	return true;
+}
+
+void prRhiDestroy(void) {
+	wpMemAllocatorFree(&_G_RHI_CONTEXT.scratch, ...);
+	wpMemAllocatorFree(&_G_RHI_CONTEXT.main, ...);
+}
+```
+
+### 4. `src/prism/rhi/vulkan/pr_rhi_vk.h` — Remove allocator from Vk declarations
+
+Remove `WpAllocator *allocator` from all function declarations.
+
+### 5. `src/prism/rhi/vulkan/pr_rhi_vk.c` — Implementation changes
+
+For every function that previously took `WpAllocator *allocator`:
+
+- Remove the parameter from the signature
+- Replace `allocator` with `_G_RHI_CONTEXT.main` for:
+  - `wpMemAllocatorAlloc(allocator, sizeof(...))` for user-facing objects (returned to caller)
+  - `wpArrayAllocCapacity(...)` for arrays that are stored in user-facing structs
+- Replace `allocator` with `_G_RHI_CONTEXT.scratch` for:
+  - `wpArrayAllocCapacity(...)` for internal temporary arrays
+  - `wpArrayDealloc(...)` for internal temporaries
+- Replace `wpMemAllocatorFree(allocator, ...)` with `wpMemAllocatorFree(&_G_RHI_CONTEXT.main, ...)` for destroy functions
+- Update internal calls (e.g. `prRhiCreateBufferVk` called from `prRhiCreateTextureFromKtxVk`)
+
+**Specific internal/helper changes:**
+- `_createSwapchainTexture` — remove `allocator` param, use `_G_RHI_CONTEXT.main`
+- `prRhiCreateTextureFromKtxVk` — staging buffer uses `_G_RHI_CONTEXT.main` (it's a user-facing object destroyed by the user)
+- `prRhiAllocateCommandBuffersVk` — VkCommandBuffer temp array uses scratch, PrRhiCommandBuffer array + structs use main
+- `prRhiCreatePipelineLayoutVk` — VkDescriptorSetLayout/VkPushConstantRange overflow arrays use scratch
+- `prRhiCreateDeviceVk` — VkQueueFamilyProperties2 array uses scratch
+
+### 6. `src/prism/rhi/vulkan/pr_rhi_vk_aliases.h` — No changes needed
+
+Aliases only map function names, not parameters.
+
+## Allocator usage per function
+
+| Function | Returned object | Allocator |
+|----------|----------------|-----------|
+| `prRhiCreateInstance` | PrRhiInstance | main |
+| `prRhiDestroyInstance` | — | free from main |
+| `prRhiGetPhysicalDevices` | PrRhiPhysicalDeviceArray + PrRhiPhysicalDevice structs | main |
+| `prRhiCreateSurfaceFromWindow` | PrRhiSurface | main |
+| `prRhiDestroySurface` | — | free from main |
+| `prRhiCreateDevice` | PrRhiDevice | main (internal VkQueueFamilyProperties2 array → scratch) |
+| `prRhiDestroyDevice` | — | free from main |
+| `prRhiCreateSwapchain` | PrRhiSwapchain + images + depth | main (internal VkImage array → scratch) |
+| `prRhiDestroySwapchain` | — | free from main |
+| `prRhiRecreateSwapchain` | updates existing struct | main for new images/depth, scratch for temp arrays |
+| `prRhiCreateBuffer` | PrRhiBuffer | main |
+| `prRhiDestroyBuffer` | — | free from main |
+| `prRhiCreateTexture` | PrRhiTexture | main |
+| `prRhiCreateTextureFromKtx` | PrRhiTexture (staging buffer too) | main |
+| `prRhiDestroyTexture` | — | free from main |
+| `prRhiCreateSampler` | PrRhiSampler | main |
+| `prRhiDestroySampler` | — | free from main |
+| `prRhiCreateShader` | PrRhiShader | main |
+| `prRhiDestroyShader` | — | free from main |
+| `prRhiCreatePipelineLayout` | PrRhiPipelineLayout | main (internal overflow arrays → scratch) |
+| `prRhiDestroyPipelineLayout` | — | free from main |
+| `prRhiCreateGraphicsPipeline` | PrRhiPipeline | main |
+| `prRhiCreateComputePipeline` | PrRhiPipeline | main |
+| `prRhiDestroyPipeline` | — | free from main |
+| `prRhiCreateDescriptorSetLayout` | PrRhiDescriptorSetLayout | main |
+| `prRhiDestroyDescriptorSetLayout` | — | free from main |
+| `prRhiCreateDescriptorPool` | PrRhiDescriptorPool | main |
+| `prRhiDestroyDescriptorPool` | — | free from main |
+| `prRhiAllocateDescriptorSet` | PrRhiDescriptorSet | main |
+| `prRhiFreeDescriptorSet` | — | free from main |
+| `prRhiCreateFence` | PrRhiFence | main |
+| `prRhiDestroyFence` | — | free from main |
+| `prRhiCreateSemaphore` | PrRhiSemaphore | main |
+| `prRhiDestroySemaphore` | — | free from main |
+| `prRhiCreateCommandPool` | PrRhiCommandPool | main |
+| `prRhiDestroyCommandPool` | — | free from main |
+| `prRhiAllocateCommandBuffers` | PrRhiCommandBufferArray + structs | main (internal VkCommandBuffer array → scratch) |

documents/session-logs/2026-07-05.md

@@ -0,0 +1,36 @@
+# Session Log — 2026-07-05
+
+## Completed
+- **DAG refactoring** (`scratchpad/dag.c`): Decoupled PrGraph from PrNodeManager.
+  Graph tracks its own active vertices (`vertex_count`, `max_vertex_ever`, `b8 active`).
+  `prGraphAddEdge`, `prGraphTopologicalSort` no longer take `PrNodeManager*`.
+  Kahn's algorithm integrated into `prGraphAddEdge` for cycle detection with rollback.
+  Output verified matching baseline.
+- **RHI research document** written to `documents/research/rendering-hardware-interface.md`.
+  Covers 8 reference RHIs, architecture patterns, core API surface, Vulkan-specific
+  considerations, Slang integration, and proposed directory layout / lifecycle design.
+- Added NVRHI to `documents/resources.md`.
+- **RHI API surface** (`scratchpad/rhi/pr_rhi.h`, `pr_rhi_types.h`): Full RHI API
+  designed with compile-time alias dispatch, by-value desc structs, wapp array types
+  for pointer+count replacement, `PrRhiSwapchainResult` enum, surface capabilities,
+  compute pipeline support, all primitive topologies, and aligned function declarations
+  grouped by subsystem section.
+- **Initial opencode setup** (opencode.json, justfile, skills, trimmed AGENTS.md).
+
+## Key Decisions
+- Graph API is self-contained — no graphics or node-manager dependencies.
+- RHI will use compile-time alias dispatch (`#define prRhiCreateDevice prRhiCreateDeviceVk`)
+  over vtbl — zero runtime overhead, dead-stripping, separate builds per backend.
+- `justfile` (Just) as task runner.
+- Object lifecycle: `prRhiCreate*` / `prRhiDestroy*` with explicit `WpAllocator*`.
+- All GPU state explicit (no hidden pipeline state).
+- Per-frame command pools and descriptor pools, arena-allocated scratch.
+- `#version-macro` convention removed from Slang files; `__slang` define used instead.
+- Desc structs passed by value (not `const *`) for simpler caller ergonomics.
+- Array aliases grouped: opaque handles (`**`) first, value types (`*`) second, separated
+  by blank line — element types before array aliases before desc structs.
+
+## Next Steps
+- Begin Vulkan backend implementation starting with `pr_rhi_vk_device.c` (instance/device/surface/swapchain creation).
+- Implement Slang shader compilation + reflection integration.
+- Wire up per-frame lifecycle (command pool reset, descriptor pool reset, scratch reset).

documents/session-logs/2026-07-06.md

@@ -0,0 +1,52 @@
+# Session Log — 2026-07-06
+
+## Completed
+- **Build system**: Fixed Just 1.55.1 `[working-directory]` bug (literal paths required).
+  Set up `just build` for 6 object files: volk.c, wapp.c, pr_rhi_vk.c, pr_rhi_vk_vma.cpp,
+  vulkan_profiles.cpp, main.cpp. Linked with `-lSDL3 -lglm -ltinyobjloader -lktx -lslang -lvulkan`.
+- **RHI backend completeness**: Filled in all missing functions (profiles validation,
+  swapchain/recreate, dynamic rendering, copy, queue submit, barriers, descriptor,
+  pipeline, sync) — 68 functions total in single `pr_rhi_vk.c`.
+- **Bugfix — `prRhiPresentVk`**: Used `current_image_index` from acquire instead of
+  hardcoded `0`.
+- **Bugfix — `extern "C"` linkage**: Added `extern "C"` guards in `pr_rhi.h` so C++
+  callers (main.cpp) can link C-compiled backend symbols.
+- **Bugfix — GPU name dangling pointers**: Added `device_name[256]`/`driver_info[256]`
+  to `PrRhiPhysicalDevice` struct, populated during enumeration. Getters return pointers
+  to these persistent buffers.
+- **Bugfix — `volkInitialize()`**: Added call at start of `prRhiCreateInstanceVk` —
+  `vpGetInstanceProfileSupport` crashed because volk hadn't loaded the Vulkan loader.
+- **Bugfix — scratch arena OOM**: Changed initial 128KB → 64MB _and_ the line-320
+  reinit override 8MB → 64MB. Prevents OOM during mesh building.
+- **Bugfix — stale mesh array pointers**: Captured return values of `wpArrayAppendAlloc`
+  in mesh-building loop — original code ignored the pointer, so `vertices`/`indices`
+  pointed to stale initial array after regrowth.
+- **Bugfix — uninitialised Vulkan stack arrays**: Zero-initialised all 18 local Vulkan
+  struct array declarations (`VkImageMemoryBarrier2[16]`, `VkBufferMemoryBarrier2[16]`,
+  `VkRenderingAttachmentInfo[8]`, `VkBufferImageCopy[16]`, plus `VkDescriptorSetLayout[8]`,
+  `VkPushConstantRange[8]`, `VkVertexInputBindingDescription[8]`,
+  `VkVertexInputAttributeDescription[16]`, `VkDynamicState[2]`, `VkFormat[8]`,
+  `VkPipelineColorBlendAttachmentState[8]`, `VkDescriptorSetLayoutBinding[16]`,
+  `VkDescriptorBindingFlags[16]`, `VkDescriptorPoolSize[8]`, `VkDescriptorImageInfo[16]`,
+  `VkDescriptorBufferInfo[16]`, `VkFence[16]` (×2), `VkCommandBuffer[16]` (×2),
+  `VkDescriptorSet[16]`, `VkBuffer[16]`). Uninitialised `pNext`/`imageOffset` fields
+  caused GPU-side device-lost crashes.
+- **Bugfix — `render_completed_semaphores` zero-length array**: `prRhiAcquireNextImage`
+  returns swapchain image INDEX (0 on first call), not image count. Used as array capacity,
+  this allocated 0 semaphores, causing out-of-bounds access in render loop → SIGSEGV.
+  Fixed by reading `app.swapchain->image_count` instead.
+- **Demo renders**: `build/prism` now launches a window, loads `suzanne0.ktx` / `suzanne1.ktx`,
+  renders textured Suzanne mesh with mouse orbit + keyboard mesh selection.
+
+## Key Decisions
+- Just 1.55.1 bug: `[working-directory: '{{BUILDDIR}}']` causes "could not find the shell `sh`"
+  — literal paths or no `[working-directory]` attribute required.
+- VMA implementation in separate `pr_rhi_vk_vma.cpp` (compiled as C++).
+- `PrRhiPhysicalDevice` stores `device_name[256]`/`driver_info[256]` to avoid dangling pointers.
+- All stack Vulkan struct arrays must be `= {0}` initialised — C backend does not zero
+  auto vars, and uninitialised `pNext`/offset fields cause GPU driver crashes.
+
+## Next Steps
+1. Review code for structural/design quality issues the user already noticed.
+2. Add `wpMemArenaAllocatorTempBegin`/`TempEnd` markers around scratch allocations.
+3. Consider adding `prRhiGetSwapchainImageCount` accessor for encapsulation.

documents/session-logs/2026-07-12.md

@@ -0,0 +1,43 @@
+# Session Log — 2026-07-12
+
+## RHI Global Context Refactor
+
+Reviewed the user's staged changes to the Vulkan RHI backend. The changes encompassed:
+
+### Global Context Adoption
+- RHI functions no longer take allocator parameters
+- `_G_RHI_CONTEXT` provides `allocator` (user-facing objects) and `tmp` (short-lived temporaries)
+- `prRhiInit(void)` / `prRhiDestroy(void)` manage the global context
+
+### KTX Texture Bug Fix
+- Original implementation only copied mip level 0
+- Fixed to iterate all mip levels using `ktxTexture_GetImageOffset()`
+- Final layout changed from `VK_IMAGE_LAYOUT_SHADER_READ_ONLY_OPTIMAL` to `VK_IMAGE_LAYOUT_READ_ONLY_OPTIMAL`
+
+### Frame-by-Frame Command Batching Pattern
+- Commands that run every frame avoid arena allocation
+- Use stack arrays with while-loop to batch operations in fixed-size chunks
+- Applied to: `prRhiCmdBindDescriptorSets`, `prRhiCmdBindVertexBuffers`, `prRhiCmdCopyBufferToImage`
+
+### API Simplifications
+- `prRhiCreateCommandPool`: removed desc parameter, uses `device->queue_family_index`
+- `prRhiFreeCommandBuffers`: removed count parameter, uses `wpArrayCount`
+- `prRhiAllocateDescriptorSet`: changed `u32 variable_count` to `WpU32Array variable_descriptor_counts`
+- `prRhiCmdBindVertexBuffers`: changed raw pointer + count to `WpU64Array`
+
+### New Pipeline Configuration
+- Added `polygon_mode`, `cull_mode`, `front_face` to rasterization
+- Added `depth_test_enable`, `depth_write_enable`, `depth_compare_op`
+- Added `vertex_shader_entry_point`, `fragment_shader_entry_point` (not hardcoded to "main")
+- Added `line_width`, `multisample_count`
+
+### Code Style Updates
+- All Vulkan info structs use C99 designated initializers
+- Removed unnecessary type casts on opaque struct handles
+- Added braces to all single-line if statements
+- Braces rule moved from prism-rhi skill to AGENTS.md formatting section
+
+## Documentation Updates
+- Updated `prism-rhi` skill with all new conventions
+- Updated `AGENTS.md` with frame-by-frame batching pattern
+- Moved braces rule to `AGENTS.md` (not RHI-specific)

documents/session-logs/2026-08-08.md

@@ -0,0 +1,60 @@
+# Session Log — 2026-08-08
+
+## Fullscreen Texture Viewer — Verification and RHI Fixes
+
+Continuation of the fullscreen-blit plan (`documents/plans/fullscreen-blit.md`),
+which rewrote `main.cpp` from the Suzanne mesh demo into a bindless texture
+viewer with contain-fit. This session visually verified the renderer and fixed
+three real bugs uncovered by that verification.
+
+### Verification method
+
+- Ran the app under the X11 SDL driver (`SDL_VIDEODRIVER=x11`) and captured the
+  window with `xwd -id <window>`, then sampled pixels with ImageMagick
+  (`magick -format "%[pixel:p{x,y}]" info:`). The model cannot view images, so
+  all render checks were programmatic (pure-black bars, centered content).
+- XTEST synthesised keys (`XTestFakeKeyEvent`) are silently dropped by
+  KWin/XWayland (confirmed with `xev`: FocusIn arrives via `_NET_ACTIVE_WINDOW`,
+  KeyPress never does). So texture cycling could not be driven headlessly; fit
+  cases were verified by temporarily making each texture the initial selection.
+
+### Contain-fit verified (pixel-sampled)
+
+| Texture             | Window    | Result                                |
+|---------------------|-----------|---------------------------------------|
+| square 1024x1024    | 16:9      | pillarbox (black L/R bars)            |
+| test_wide 2048x512  | 16:9      | letterbox (black T/B bars)            |
+| test_tall 512x2048  | 16:9      | pillarbox (black L/R bars)            |
+| test_fill 1920x1080 | 16:9      | fills exactly (no bars)               |
+| square, then resized to portrait | portrait | fit recomputed per frame → flips to letterbox |
+
+### Bugs found and fixed
+
+1. **`VK_SUBOPTIMAL_KHR` crashed the app.** `prRhiAcquireNextImageVk` and
+   `prRhiPresentVk` routed SUBOPTIMAL into `_checkVk` → `__builtin_trap()`
+   (SIGILL, caught under X11 immediately). Both now return
+   `PR_RHI_SWAPCHAIN_OUT_OF_DATE` for SUBOPTIMAL, same as OUT_OF_DATE
+   (`pr_rhi_vk.c`).
+2. **Swapchain recreate ignored surface extent.** `prRhiRecreateSwapchainVk`
+   hard-coded the passed width/height. Now queries
+   `vkGetPhysicalDeviceSurfaceCapabilitiesKHR` and falls back to the passed
+   size only when `currentExtent == 0xFFFFFFFF` (matches the initial-create
+   logic).
+3. **App used logical window size for the swapchain.** Under HiDPI the drawable
+   differs from `SDL_GetWindowSize` (1920x1080 logical vs 2400x1350 drawable at
+   1.25x scale on XWayland) — the root cause of #1. main.cpp now uses
+   `SDL_GetWindowSizeInPixels` for swapchain width/height, the fit rect, the
+   viewport, and the scissor.
+
+### CLI arg considered and removed
+
+Added a `--texture N` startup arg to drive the verification, then removed it at
+the user's request (`main()` is back to no-args, `app.selected = 0`). If
+headless key injection is ever needed again, revisit (e.g. `ydotool`/`wtype` on
+Wayland, or a WM on a real X server).
+
+### Notes
+
+- `main.cpp` header comment, `<cstdlib>` include, and plan doc all updated to
+  reflect the removed arg.
+- Native Wayland run still clean after all fixes; `just build` passes.

documents/session-logs/2026-08-09.md

@@ -0,0 +1,59 @@
+# Session Log — 2026-08-09
+
+## Background colour change (blit shader)
+
+- User requested changing the letterbox/pillarbox background from black to neutral grey.
+- Initial attempt: changed the render pass clear color to `(0.5, 0.5, 0.5, 1.0)`. This
+  triggered the NVIDIA validation layer warning
+  `BestPractices-NVIDIA-ClearColor-NotCompressed` — SRGB fast clears only work
+  with 0.0 or 1.0 on NVIDIA tile-based GPUs.
+- Reverted the clear color and implemented the proper solution: draw a fullscreen
+  grey quad in the fragment shader before the texture quad. The render pass clear
+  stays at 0.0 (fast-compressed).
+- Added `mode` field to `BlitData` push constant. Mode 0 samples the texture, mode
+  1 outputs solid grey.
+- User noted that a branch in the shader is free (no warp divergence since `mode`
+  is uniform per draw call). Agreed — no need for a separate clear pipeline.
+- Changed grey from 0.5 to 0.18 (18% grey card, standard in photography/compositing).
+- Fixed a Slang compilation warning by updating the profile from `spirv_1_4` to
+  `spirv_1_6` and explicitly declaring the required capabilities.
+
+## Shader filter node research
+
+- User requested research on: Gaussian blur, CDL, Laplacian, Sobel, sharpen,
+  posterize, pixelize, Kuwahara.
+- Launched a research agent that produced `documents/research/shader-filters.md`
+  covering all filters with formulas, Slang pseudocode, parameter tables, and
+  performance notes.
+
+## Design decisions made during review
+
+1. **Colour space**: all intermediate textures are linear float
+   (`R16G16B16A16_SFLOAT`, `R32G32B32A32_SFLOAT` for Kuwahara tensor). sRGB images
+   are linearized once at load by the Read node. Final blit to sRGB swapchain
+   handles display encoding.
+
+2. **Alpha**: premultiplied everywhere by default. Explicit Unpremult/Premult
+   nodes for operations that need unpremultiplied values (Nuke model).
+
+3. **Edge handling**: per-node parameter, clamp-to-edge default, clamp-to-border
+   option. Affects sampler state, not shader branches.
+
+4. **Premult has no parameters**: removed the empty push constant struct.
+
+## Research document fixes
+
+- Fixed a contradictory sentence about push constant sizes and CDL block size.
+- Added Unpremult (§9) and Premult (§10) sections with full implementations.
+- Added `edge_mode` field to all 5 spatial filter push constant blocks (Gaussian,
+  Laplacian, Sobel, Sharpen, Kuwahara).
+- Restructured the implications section (§12) into open items vs resolved decisions.
+- Expanded all mathematics sections with plain-language explanations suitable for
+  someone without a strong math background.
+
+## Open items for next session
+
+- Begin implementing the actual shader nodes in Prism
+- Node system needs: per-pass resource signatures, scratch texture hooks, per-node
+  sampler choice, compile-time-bounded loop limits
+- Classic Kuwahara is the recommended first implementation (single pass)

justfile

@@ -0,0 +1,86 @@
+# Prism — Build tasks
+# See https://just.systems
+
+default: build
+
+CC       := "clang"
+CXX      := "clang++"
+BUILDDIR := "build"
+
+# Resolve VULKAN_SDK once via backtick
+VK_SDK := `echo $VULKAN_SDK`
+VENDOR_INC := BUILDDIR + "/include"
+VENDOR_LIB := BUILDDIR + "/lib"
+
+VK_FLAGS := "-DPR_RHI_VULKAN -DVK_NO_PROTOTYPES -I" + VK_SDK + "/include -I" + VK_SDK + "/include/vma -I" + VENDOR_INC
+APP_INC  := "-I" + VK_SDK + "/include -I" + VK_SDK + "/include/vma -I" + VENDOR_INC + " -Isrc"
+
+# Build KTX from source
+vendor:
+	mkdir -p {{BUILDDIR}}/ktx
+	cmake src/vendor/ktx -B {{BUILDDIR}}/ktx \
+		-D KTX_FEATURE_LOADTEST_APPS=OFF \
+		-D KTX_FEATURE_DOC=OFF \
+		-D CMAKE_EXPORT_COMPILE_COMMANDS=1 \
+		-D CMAKE_BUILD_TYPE=Release \
+		-D CMAKE_INSTALL_PREFIX=$(pwd)/{{BUILDDIR}} \
+		-D CMAKE_CXX_STANDARD=17 \
+		-D CMAKE_CXX_FLAGS="-msse4.1" \
+		-G Ninja
+	cmake --build {{BUILDDIR}}/ktx --config Release
+	cmake --install {{BUILDDIR}}/ktx
+
+# Compile shaders from .slang to SPIR-V
+shaders:
+	mkdir -p {{BUILDDIR}}/shaders
+	{{VK_SDK}}/bin/slangc -target spirv \
+		-profile spirv_1_6+\
+			SPV_GOOGLE_user_type+\
+			spvFragmentFullyCoveredEXT+\
+			spvDerivativeControl+\
+			spvImageQuery+\
+			spvImageGatherExtended+\
+			spvSparseResidency+\
+			spvMinLod \
+		-o {{BUILDDIR}}/shaders/blit.spv assets/blit.slang
+
+# Build all objects, then link
+build: vendor shaders
+	mkdir -p {{BUILDDIR}}/bin
+	bear -- {{CXX}} -g -c -Wno-nullability-completeness {{VK_FLAGS}} \
+		src/prism/rhi/vulkan/profiles/vulkan_profiles.cpp \
+		-o {{BUILDDIR}}/vulkan_profiles.o
+	bear -a -- {{CXX}} -g -c -Wno-nullability-completeness {{VK_FLAGS}} \
+		src/prism/rhi/vulkan/pr_rhi_vk_vma.cpp \
+		-o {{BUILDDIR}}/pr_rhi_vk_vma.o
+	bear -a -- {{CC}} -g -c {{VK_FLAGS}} {{VK_SDK}}/include/volk/volk.c -o {{BUILDDIR}}/volk.o
+	bear -a -- {{CC}} -g -c {{VK_FLAGS}} src/prism/rhi/pr_rhi.c -o {{BUILDDIR}}/pr_rhi.o
+	bear -a -- {{CC}} -g -c {{VK_FLAGS}} src/prism/rhi/vulkan/pr_rhi_vk.c -o {{BUILDDIR}}/pr_rhi_vk.o
+	bear -a -- {{CC}} -g -c src/vendor/wapp/wapp.c -o {{BUILDDIR}}/wapp.o
+	bear -a -- {{CXX}} -g -c {{VK_FLAGS}} -Wno-nullability-completeness -DVK_NO_PROTOTYPES \
+		{{APP_INC}} \
+		src/main.cpp \
+		-o {{BUILDDIR}}/main.o
+	bear -a -- {{CXX}} -g {{VK_FLAGS}} \
+		-L{{VK_SDK}}/lib -L{{VENDOR_LIB}} \
+		build/*.o \
+		-lSDL3 -lktx -lvulkan \
+		-Wl,-rpath,{{VENDOR_LIB}} -Wl,-rpath,{{VK_SDK}}/lib \
+		-o {{BUILDDIR}}/bin/prism
+	@echo "--- build done: {{BUILDDIR}}/bin/prism ---"
+	@rm {{BUILDDIR}}/*.o
+
+run:
+	./{{BUILDDIR}}/bin/prism
+
+# Clean
+clean:
+	rm -rf {{BUILDDIR}}
+
+# Run linter
+lint:
+	@echo "TODO: implement linter"
+
+# Run tests
+test:
+	@echo "TODO: implement tests"

opencode.json

@@ -0,0 +1,22 @@
+{
+  "$schema": "https://opencode.ai/config.json",
+  "command": {
+    "build": {
+      "template": "!just build",
+      "description": "Build the project"
+    },
+    "lint": {
+      "template": "!just lint",
+      "description": "Run linter / typecheck"
+    },
+    "test": {
+      "template": "!just test",
+      "description": "Run tests"
+    }
+  },
+  "permission": {
+    "edit": {
+      "src/wapp/**": "deny"
+    }
+  }
+}

references/SkienaBook/graph.c

@@ -0,0 +1,152 @@
+// vim:fileencoding=utf-8:foldmethod=marker
+
+/*	graph.c         
+
+	A generic adjacency list graph data type.
+*/
+
+/* Copyright 2003-2020 by Steven S. Skiena; all rights reserved.
+Permission is granted for use in non-commerical applications
+provided this copyright notice remains intact and unchanged.
+
+These programs appear in my books:
+
+"The Algorithm Design Manual" by Steven Skiena, second edition, Springer,
+London 2008.  See out website www.algorist.com for additional information
+or https://www.amazon.com/exec/obidos/ASIN/1848000693/thealgorith01-20
+
+"Programming Challenges: The Programming Contest Training Manual"
+by Steven Skiena and Miguel Revilla, Springer-Verlag, New York 2003.
+See our website www.programming-challenges.com for additional information,
+or https://www.amazon.com/exec/obidos/ASIN/0387001638/thealgorithmrepo/
+*/
+
+#include <stdio.h>
+#include <stdlib.h>
+
+#include "queue.h"
+#include "graph.h"
+
+/* [[[ init_graph_c */
+void initialize_graph(graph *g, bool directed) {
+    int i;    /* counter */
+
+    g->nvertices = 0;
+    g->nedges = 0;
+    g->directed = directed;
+
+    for (i = 1; i <= MAXV; i++) {
+        g->degree[i] = 0;
+    }
+
+    for (i = 1; i <= MAXV; i++) {
+        g->edges[i] = NULL;
+    }
+}
+/* ]]] */
+
+/* [[[ insert_edge_cut */
+void insert_edge(graph *g, int x, int y, bool directed) {
+    edgenode *p;        /* temporary pointer */
+
+    p = malloc(sizeof(edgenode));    /* allocate edgenode storage */
+
+    p->weight = 0;
+    p->y = y;
+    p->next = g->edges[x];
+
+    g->edges[x] = p;    /* insert at head of list */
+
+    g->degree[x]++;
+
+    if (!directed) {
+        insert_edge(g, y, x, true);
+    } else {
+        g->nedges++;
+    }
+}
+/* ]]] */
+
+/* [[[ read_graph_cut */
+void read_graph(graph *g, bool directed) {
+    int i;              /* counter */
+    int m;              /* number of edges */
+    int x, y;           /* vertices in edge (x,y) */
+
+    initialize_graph(g, directed);
+
+    scanf("%d %d", &(g->nvertices), &m);
+
+    for (i = 1; i <= m; i++) {
+        scanf("%d %d", &x, &y);
+        insert_edge(g, x, y, directed);
+    }
+}
+/* ]]] */
+
+void delete_edge(graph *g, int x, int y, bool directed) {
+    edgenode *p, *p_back; /* temporary pointers */
+
+    p = g->edges[x];
+    p_back = NULL;
+
+    while (p != NULL) {
+        if (p->y == y) {
+            g->degree[x]--;
+            if (p_back != NULL) {
+                p_back->next = p->next;
+            } else {
+                g->edges[x] = p->next;
+            }
+            free(p);
+            if (!directed) {
+                delete_edge(g, y, x, true);
+            } else {
+                g->nedges--;
+            }
+            return;
+        } else {
+            p = p->next;
+        }
+    }
+    printf("Warning: deletion(%d,%d) not found in g.\n",x,y);
+}
+
+/* [[[ print_graph_cut */
+void print_graph(graph *g) {
+    int i;        /* counter */
+    edgenode *p;  /* temporary pointer */
+
+    for (i = 1; i <= g->nvertices; i++) {
+        printf("%d: ", i);
+        p = g->edges[i];
+        while (p != NULL) {
+            printf(" %d", p->y);
+            p = p->next;
+        }
+        printf("\n");
+    }
+}
+/* ]]] */
+
+/* [[[ graph_transpose_cut */
+graph *transpose(graph *g) {
+    graph *gt;    /* transpose of graph g */
+    int x;        /* counter */
+    edgenode *p;  /* temporary pointer */
+
+    gt = (graph *) malloc(sizeof(graph));
+    initialize_graph(gt, true);       /* initialize directed graph */
+    gt->nvertices = g->nvertices;
+
+    for (x = 1; x <= g->nvertices; x++) {
+        p = g->edges[x];
+        while (p != NULL) {
+            insert_edge(gt, p->y, x, true);
+            p = p->next;
+        }
+    }
+
+    return(gt);
+}
+/* ]]] */

references/SkienaBook/graph.h

@@ -0,0 +1,71 @@
+// vim:fileencoding=utf-8:foldmethod=marker
+
+#ifndef GRAPH_H
+#define GRAPH_H
+
+/*	graph.h
+
+	Header file for pointer-based graph data type
+*/
+
+/* Copyright 2003-2020 by Steven S. Skiena; all rights reserved.
+Permission is granted for use in non-commerical applications
+provided this copyright notice remains intact and unchanged.
+
+These programs appear in my books:
+
+"The Algorithm Design Manual" by Steven Skiena, second edition, Springer,
+London 2008.  See out website www.algorist.com for additional information
+or https://www.amazon.com/exec/obidos/ASIN/1848000693/thealgorith01-20
+
+"Programming Challenges: The Programming Contest Training Manual"
+by Steven Skiena and Miguel Revilla, Springer-Verlag, New York 2003.
+See our website www.programming-challenges.com for additional information,
+or https://www.amazon.com/exec/obidos/ASIN/0387001638/thealgorithmrepo/
+*/
+
+#include <stdbool.h>
+
+/* #define _NULL       0       null pointer */
+
+/*	DFS edge types		*/
+
+#define TREE        0       /* tree edge */
+#define BACK        1       /* back edge */
+#define CROSS       2       /* cross edge */
+#define FORWARD     3       /* forward edge */
+
+/* [[[ graph_struct_cut */
+/* [[[ maxv_cut */
+#define MAXV        100     /* maximum number of vertices */
+/* ]]] */
+
+/* [[[ edge_struct_only_cut */
+typedef struct edgenode {
+    int y;                   /* adjacency info */
+    int weight;              /* edge weight, if any */
+    struct edgenode *next;   /* next edge in list */
+} edgenode;
+/* ]]] */
+
+/* [[[ graph_struct_only_cut */
+typedef struct {
+    edgenode *edges[MAXV+1];  /* adjacency info */
+    int degree[MAXV+1];       /* outdegree of each vertex */
+    int nvertices;            /* number of vertices in the graph */
+    int nedges;               /* number of edges in the graph */
+    int directed;             /* is the graph directed? */
+} graph;
+/* ]]] */
+/* ]]] */
+
+void process_vertex_early(int v);
+void process_vertex_late(int v);
+void process_edge(int x, int y);
+
+void initialize_graph(graph *g, bool directed);
+void read_graph(graph *g, bool directed);
+void print_graph(graph *g);
+graph *transpose(graph *g);
+
+#endif // !GRAPH_H

references/SkienaBook/item.h

@@ -0,0 +1,29 @@
+// vim:fileencoding=utf-8:foldmethod=marker
+
+#ifndef ITEM_H
+#define ITEM_H
+
+/*	item.h
+
+	Header file for linked implementation
+*/
+
+/* Copyright 2003-2020 by Steven S. Skiena; all rights reserved.
+Permission is granted for use in non-commerical applications
+provided this copyright notice remains intact and unchanged.
+
+These programs appear in my books:
+
+"The Algorithm Design Manual" by Steven Skiena, second edition, Springer,
+London 2008.  See out website www.algorist.com for additional information
+or https://www.amazon.com/exec/obidos/ASIN/1848000693/thealgorith01-20
+
+"Programming Challenges: The Programming Contest Training Manual"
+by Steven Skiena and Miguel Revilla, Springer-Verlag, New York 2003.
+See our website www.programming-challenges.com for additional information,
+or https://www.amazon.com/exec/obidos/ASIN/0387001638/thealgorithmrepo/
+*/
+
+typedef int item_type;
+
+#endif // !ITEM_H

references/SkienaBook/queue.c

@@ -0,0 +1,80 @@
+// vim:fileencoding=utf-8:foldmethod=marker
+
+/*    queue.c
+
+    Implementation of a FIFO queue abstract data type.
+*/
+
+/* Copyright 2003-2020 by Steven S. Skiena; all rights reserved.
+Permission is granted for use in non-commerical applications
+provided this copyright notice remains intact and unchanged.
+
+These programs appear in my books:
+
+"The Algorithm Design Manual" by Steven Skiena, second edition, Springer,
+London 2008.  See out website www.algorist.com for additional information
+or https://www.amazon.com/exec/obidos/ASIN/1848000693/thealgorith01-20
+
+"Programming Challenges: The Programming Contest Training Manual"
+by Steven Skiena and Miguel Revilla, Springer-Verlag, New York 2003.
+See our website www.programming-challenges.com for additional information,
+or https://www.amazon.com/exec/obidos/ASIN/0387001638/thealgorithmrepo/
+*/
+
+#include <stdio.h>
+#include <stdbool.h>
+
+#include "queue.h"
+
+void init_queue(queue *q) {
+    q->first = 0;
+    q->last = QUEUESIZE - 1;
+    q->count = 0;
+}
+
+void enqueue(queue *q, item_type x) {
+    if (q->count >= QUEUESIZE) {
+        printf("Warning: queue overflow enqueue x=%d\n", x);
+    } else {
+        q->last = (q->last + 1) % QUEUESIZE;
+        q->q[q->last] = x;    
+        q->count = q->count + 1;
+    }
+}
+
+item_type dequeue(queue *q) {
+    item_type x;
+
+    if (q->count <= 0) printf("Warning: empty queue dequeue.\n");
+
+    x = q->q[q->first];
+    q->first = (q->first + 1) % QUEUESIZE;
+    q->count = q->count - 1;
+
+    return(x);
+}
+
+item_type headq(queue *q) {
+    return(q->q[q->first]);
+}
+
+int empty_queue(queue *q) {
+    if (q->count <= 0) {
+        return (true);
+    }
+    return (false);
+}
+
+void print_queue(queue *q) {
+    int i;
+
+    i = q->first; 
+        
+    while (i != q->last) {
+        printf("%d ", q->q[i]);
+        i = (i + 1) % QUEUESIZE;
+    }
+
+    printf("%2d ", q->q[i]);
+    printf("\n");
+}

references/SkienaBook/queue.h

@@ -0,0 +1,45 @@
+// vim:fileencoding=utf-8:foldmethod=marker
+
+#ifndef QUEUE_H
+#define QUEUE_H
+
+/*	queue.h
+
+	Header file for queue implementation
+*/
+
+/* Copyright 2003-2020 by Steven S. Skiena; all rights reserved.
+Permission is granted for use in non-commerical applications
+provided this copyright notice remains intact and unchanged.
+
+These programs appear in my books:
+
+"The Algorithm Design Manual" by Steven Skiena, second edition, Springer,
+London 2008.  See out website www.algorist.com for additional information
+or https://www.amazon.com/exec/obidos/ASIN/1848000693/thealgorith01-20
+
+"Programming Challenges: The Programming Contest Training Manual"
+by Steven Skiena and Miguel Revilla, Springer-Verlag, New York 2003.
+See our website www.programming-challenges.com for additional information,
+or https://www.amazon.com/exec/obidos/ASIN/0387001638/thealgorithmrepo/
+*/
+
+#include "item.h"
+
+#define QUEUESIZE 1000
+
+typedef struct {
+    item_type q[QUEUESIZE+1];           /* body of queue */
+    int first;                          /* position of first element */
+    int last;                           /* position of last element */
+    int count;                          /* number of queue elements */
+} queue;
+
+void init_queue(queue *q);
+void enqueue(queue *q, item_type x);
+item_type dequeue(queue *q);
+item_type headq(queue *q);
+int empty_queue(queue *q);
+void print_queue(queue *q);
+
+#endif // !QUEUE_H

references/igraph-1.0.1/ACKNOWLEDGEMENTS.md

@@ -0,0 +1,293 @@
+# Acknowledgements
+
+[igraph](https://igraph.org) includes or links to code from the following sources.
+
+
+#### [ARPACK-NG 3.7.0](https://github.com/opencollab/arpack-ng)
+
+BSD Software License
+
+Pertains to ARPACK and P_ARPACK
+
+Copyright (c) 1996-2008 Rice University.
+Developed by D.C. Sorensen, R.B. Lehoucq, C. Yang, and K. Maschhoff.
+All rights reserved.
+
+Arpack has been renamed to arpack-ng.
+
+Copyright (c) 2001-2011 - Scilab Enterprises
+Updated by Allan Cornet, Sylvestre Ledru.
+
+Copyright (c) 2010 - Jordi Gutiérrez Hermoso (Octave patch)
+
+Copyright (c) 2007 - Sébastien Fabbro (gentoo patch)
+
+Redistribution and use in source and binary forms, with or without
+modification, are permitted provided that the following conditions are
+met:
+
+- Redistributions of source code must retain the above copyright
+  notice, this list of conditions and the following disclaimer.
+
+- Redistributions in binary form must reproduce the above copyright
+  notice, this list of conditions and the following disclaimer listed
+  in this license in the documentation and/or other materials
+  provided with the distribution.
+
+- Neither the name of the copyright holders nor the names of its
+  contributors may be used to endorse or promote products derived from
+  this software without specific prior written permission.
+
+THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+
+#### [bliss 0.75](https://users.aalto.fi/~tjunttil/bliss/)
+
+Copyright (c) 2003-2021 Tommi Junttila.
+
+License: [GNU LGPLv3][lgpl3]
+
+
+#### [Cliquer 1.21](https://users.aalto.fi/~pat/cliquer.html)
+
+Copyright (C) 2002 Sampo Niskanen, Patric Östergård.
+
+License: [GNU GPLv2][gpl2] or later
+
+
+#### [PRPACK](https://github.com/dgleich/prpack)
+
+Copyright (C) David Kurokawa, David Gleich, Chen Greif.
+
+
+#### [gengraph](https://www-complexnetworks.lip6.fr/~latapy/FV/generation.html)
+
+Algorithm by Fabien Viger and Matthieu Latapy.
+
+Implementation Copyright (C) Fabien Viger.
+
+License: [GNU GPLv2][gpl2] or later
+
+
+#### [Walktrap 0.2](https://www-complexnetworks.lip6.fr/~latapy/PP/walktrap.html)
+
+Algorithm by Pascal Pons and Matthieu Latapy.
+
+Implementation Copyright (C) 2004-2005 Pascal Pons.
+
+License: [GNU GPLv2][gpl2] or later
+
+
+#### [plfit](https://github.com/ntamas/plfit)
+
+Copyright (C) 2010-2011 Tamás Nepusz.
+
+License: [GNU GPLv2][gpl2] or later
+
+
+#### DrL
+
+Copyright 2007 Sandia Corporation. Under the terms of Contract
+DE-AC04-94AL85000 with Sandia Corporation, the U.S. Government retains
+certain rights in this software.
+
+All rights reserved.
+
+Redistribution and use in source and binary forms, with or without
+modification, are permitted provided that the following conditions are
+met:
+
+  * Redistributions of source code must retain the above copyright
+notice, this list of conditions and the following disclaimer.
+  * Redistributions in binary form must reproduce the above copyright
+notice, this list of conditions and the following disclaimer in the
+documentation and/or other materials provided with the distribution.
+  * Neither the name of Sandia National Laboratories nor the names of
+its contributors may be used to endorse or promote products derived from
+this software without specific prior written permission.
+
+THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED
+TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
+PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
+LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
+NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
+SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+
+#### [Hierarchical Random Graphs](https://aaronclauset.github.io/hierarchy/)
+
+Copyright (C) 2006-2008 Aaron Clauset.
+
+License: [GNU GPLv2][gpl2] or later
+
+
+#### Spinglass community detection
+
+Copyright (C) 2004 by Joerg Reichardt.
+
+License: [GNU GPLv2][gpl2] or later
+
+
+#### [LAD version 1](http://liris.cnrs.fr/csolnon/LAD.html)
+
+Copyright (C) Christine Solnon.
+
+License: [CeCILL-B license](https://cecill.info/licences.en.html)
+
+
+#### [LAPACK 3.5.0](http://www.netlib.org/lapack/) and [BLAS 3.12.0](http://www.netlib.org/blas/)
+
+Copyright (c) 1992-2013 The University of Tennessee and The University of Tennessee Research Foundation.  All rights reserved.
+
+Copyright (c) 2000-2013 The University of California Berkeley. All rights reserved.
+
+Copyright (c) 2006-2013 The University of Colorado Denver.  All rights reserved.
+
+License: [New BSD license](http://www.netlib.org/lapack/LICENSE.txt)
+
+Redistribution and use in source and binary forms, with or without
+modification, are permitted provided that the following conditions are
+met:
+
+- Redistributions of source code must retain the above copyright
+  notice, this list of conditions and the following disclaimer.
+
+- Redistributions in binary form must reproduce the above copyright
+  notice, this list of conditions and the following disclaimer listed
+  in this license in the documentation and/or other materials
+  provided with the distribution.
+
+- Neither the name of the copyright holders nor the names of its
+  contributors may be used to endorse or promote products derived from
+  this software without specific prior written permission.
+
+The copyright holders provide no reassurances that the source code
+provided does not infringe any patent, copyright, or any other
+intellectual property rights of third parties.  The copyright holders
+disclaim any liability to any recipient for claims brought against
+recipient by any third party for infringement of that parties
+intellectual property rights.
+
+THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+
+#### [f2c](http://www.netlib.org/f2c/)
+
+Copyright 1990 - 1997 by AT&T, Lucent Technologies and Bellcore.
+
+Permission to use, copy, modify, and distribute this software
+and its documentation for any purpose and without fee is hereby
+granted, provided that the above copyright notice appear in all
+copies and that both that the copyright notice and this
+permission notice and warranty disclaimer appear in supporting
+documentation, and that the names of AT&T, Bell Laboratories,
+Lucent or Bellcore or any of their entities not be used in
+advertising or publicity pertaining to distribution of the
+software without specific, written prior permission.
+
+AT&T, Lucent and Bellcore disclaim all warranties with regard to
+this software, including all implied warranties of
+merchantability and fitness.  In no event shall AT&T, Lucent or
+Bellcore be liable for any special, indirect or consequential
+damages or any damages whatsoever resulting from loss of use,
+data or profits, whether in an action of contract, negligence or
+other tortious action, arising out of or in connection with the
+use or performance of this software.
+
+
+#### [SuiteSparse](http://www.suitesparse.com)
+
+CXSPARSE: a Concise Sparse Matrix package - Extended. Copyright (c) 2006-2017, Timothy A. Davis.
+
+License: [GNU LGPLv2.1][lgpl2] or later
+
+
+#### [Infomap](https://www.mapequation.org/)
+
+Infomap software package for multi-level network clustering
+Copyright (c) 2013, 2014 Daniel Edler, Anton Holmgren, Martin Rosvall
+
+License: [GNU GPLv3][gpl3] or later
+
+
+#### [GLPK (GNU Linear Programming Kit) Version 5.0](https://www.gnu.org/software/glpk/)
+
+Copyright (C) 2000-2020 Free Software Foundation, Inc.
+
+Written by Andrew Makhorin, Department for Applied Informatics,
+Moscow Aviation Institute, Moscow, Russia. E-mail: <mao@gnu.org>.
+
+License: [GNU GPLv3][gpl3] or later
+
+
+#### [GMP (GNU Multiple Precision Arithmetic Library) and mini-gmp](https://gmplib.org/)
+
+Copyright (C) Free Software Foundation, Inc.
+
+License: [GNU LGPLv3][lgpl3] or later; or [GNU GPLv2][gpl2] or later
+
+
+#### [libxml2](http://xmlsoft.org/)
+
+Copyright (C) 1998-2012 Daniel Veillard.
+
+License: [MIT license][mit]
+
+
+#### [nanoflann](https://github.com/jlblancoc/nanoflann)
+
+Copyright 2008-2009  Marius Muja (mariusm@cs.ubc.ca).
+Copyright 2008-2009  David G. Lowe (lowe@cs.ubc.ca).
+Copyright 2011 Jose L. Blanco (joseluisblancoc@gmail.com).
+
+License: [BSD license][bsd]
+
+
+#### [Qhull](http://www.qhull.org/)
+
+Qhull, Copyright (c) 1993-2020
+
+C.B. Barber, Arlington, MA
+
+and
+
+The National Science and Technology Research Center for
+Computation and Visualization of Geometric Structures
+(The Geometry Center)
+University of Minnesota
+
+License: [Qhull license][qhull]
+
+
+ [bsd]:   https://opensource.org/license/BSD-2-Clause
+ [mit]:   https://opensource.org/licenses/mit-license.html
+ [qhull]: http://www.qhull.org/COPYING.txt
+ [gpl2]:  https://www.gnu.org/licenses/gpl-2.0.html
+ [lgpl2]: https://www.gnu.org/licenses/lgpl-2.1.html
+ [gpl3]:  https://www.gnu.org/licenses/gpl-3.0.html
+ [lgpl3]: https://www.gnu.org/licenses/lgpl-3.0.html

references/igraph-1.0.1/AUTHORS

@@ -0,0 +1,6 @@
+Gabor Csardi <csardi.gabor@gmail.com>
+Tamas Nepusz <ntamas@gmail.com>
+Szabolcs Horvat <szhorvat@gmail.com>
+Vincent Traag <v.a.traag@cwts.leidenuniv.nl>
+Fabio Zanini <fabio.zanini@unsw.edu.au>
+Daniel Noom <ggatw@outlook.com>

references/igraph-1.0.1/CMakeLists.txt

@@ -0,0 +1,195 @@
+# Minimum CMake that we require is 3.18.
+# Some of the recent features we use:
+#  * --ignore-eol when comparing unit test results with expected outcomes (3.14)
+#  * CROSSCOMPILING_EMULATOR can be a semicolon-separated list to pass arguments (3.15)
+#  * SKIP_REGULAR_EXPRESSION to handle skipped tests properly (3.16)
+#  * CheckLinkerFlag for HAVE_NEW_DTAGS test (3.18)
+#  * cmake -E cat (3.18)
+cmake_minimum_required(VERSION 3.18...3.31)
+
+# CMake 3.31.0 issues warnings due to the following bug:
+# https://gitlab.kitware.com/cmake/cmake/-/issues/26449
+# Setting policy CMP0175 to OLD avoids the warnings.
+if(CMAKE_VERSION VERSION_EQUAL "3.31.0")
+  cmake_policy(SET CMP0175 OLD)
+endif()
+
+# Add etc/cmake to CMake's search path so we can put our private stuff there
+list(APPEND CMAKE_MODULE_PATH ${CMAKE_CURRENT_LIST_DIR}/etc/cmake)
+
+# Set a default build type if none was specified
+# This must precede the project() line, which would set the CMAKE_BUILD_TYPE
+# to 'Debug' with single-config generators on Windows.
+# Note that we must do this only if PROJECT_NAME is not set at this point. If
+# it is set, it means that igraph is being used as a subproject of another
+# project.
+if(NOT PROJECT_NAME)
+  include(BuildType)
+endif()
+
+# Prevent in-source builds
+include(PreventInSourceBuilds)
+
+# Make use of ccache if it is present on the host system -- unless explicitly
+# asked to disable it
+include(UseCCacheWhenInstalled)
+
+# Figure out the version number from Git
+include(version)
+
+# Declare the project, its version number and language
+project(
+  igraph
+  VERSION ${PACKAGE_VERSION_BASE}
+  DESCRIPTION "A library for creating and manipulating graphs"
+  HOMEPAGE_URL https://igraph.org
+  LANGUAGES C CXX
+)
+
+# Include some compiler-related helpers and set global compiler options
+include(compilers)
+
+# Detect is certain attributes are supported by the compiler
+include(attribute_support)
+
+# Set default symbol visibility to hidden
+set(CMAKE_C_VISIBILITY_PRESET hidden)
+set(CMAKE_CXX_VISIBILITY_PRESET hidden)
+
+# Set C and C++ standard version
+set(CMAKE_C_STANDARD 99)
+set(CMAKE_C_STANDARD_REQUIRED True)
+set(CMAKE_CXX_STANDARD 14)
+set(CMAKE_CXX_STANDARD_REQUIRED True)
+
+# Expose the BUILD_SHARED_LIBS option in the ccmake UI
+option(BUILD_SHARED_LIBS "Build shared libraries" OFF)
+
+# Add switches to use sanitizers and debugging helpers if needed
+include(debugging)
+include(sanitizers)
+
+# Enable fuzzer instrumentation if needed
+# FUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION is a conventional
+# macro used to adapt code for fuzzability, for example by
+# reducing largest allowed graph sizes when reading various
+# file formats.
+if(BUILD_FUZZING)
+  add_compile_options(-fsanitize=fuzzer-no-link)
+  add_compile_definitions(FUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION)
+endif()
+
+# Add version information
+configure_file(
+  ${CMAKE_CURRENT_SOURCE_DIR}/include/igraph_version.h.in
+  ${CMAKE_CURRENT_BINARY_DIR}/include/igraph_version.h
+)
+
+# Create configuration options for optional features
+include(features)
+
+# Handle dependencies and dependency-related configuration options
+include(dependencies)
+find_dependencies()
+
+# Run compile-time checks, generate config.h and igraph_threading.h
+include(CheckSymbolExists)
+include(CheckIncludeFiles)
+include(CMakePushCheckState)
+
+# First we check for some functions and symbols
+cmake_push_check_state()
+if(NEED_LINKING_AGAINST_LIBM)
+  list(APPEND CMAKE_REQUIRED_LIBRARIES m)
+endif()
+check_symbol_exists(strcasecmp strings.h HAVE_STRCASECMP)
+check_symbol_exists(strncasecmp strings.h HAVE_STRNCASECMP)
+check_symbol_exists(_stricmp string.h HAVE__STRICMP)
+check_symbol_exists(_strnicmp string.h HAVE__STRNICMP)
+check_symbol_exists(strdup string.h HAVE_STRDUP)
+check_symbol_exists(strndup string.h HAVE_STRNDUP)
+check_include_files(xlocale.h HAVE_XLOCALE)
+if(HAVE_XLOCALE)
+  # On BSD, uselocale() is in xlocale.h instead of locale.h.
+  # Some systems provide xlocale.h, but uselocale() is still in locale.h,
+  # thus we try both.
+  check_symbol_exists(uselocale "xlocale.h;locale.h" HAVE_USELOCALE)
+else()
+  check_symbol_exists(uselocale locale.h HAVE_USELOCALE)
+endif()
+check_symbol_exists(_configthreadlocale locale.h HAVE__CONFIGTHREADLOCALE)
+cmake_pop_check_state()
+
+# Check for 128-bit integer multiplication support, floating-point endianness,
+# support for built-in overflow detection and fast bit operation support.
+include(ieee754_endianness)
+include(uint128_support)
+include(bit_operations_support)
+include(safe_math_support)
+
+if(NOT HAVE_USELOCALE AND NOT HAVE__CONFIGTHREADLOCALE)
+  message(WARNING "igraph cannot set per-thread locale on this platform. igraph_enter_safelocale() and igraph_exit_safelocale() will not be safe to use in multithreaded programs.")
+endif()
+
+# Check for code coverage support
+option(IGRAPH_ENABLE_CODE_COVERAGE "Enable code coverage calculation" OFF)
+if(CMAKE_PROJECT_NAME STREQUAL PROJECT_NAME AND IGRAPH_ENABLE_CODE_COVERAGE)
+  include(CodeCoverage)
+  append_coverage_compiler_flags()
+  setup_target_for_coverage_lcov(
+    NAME coverage
+    EXECUTABLE "${CMAKE_COMMAND}" "--build" "${PROJECT_BINARY_DIR}" "--target" "check"
+    # The base directory is changed to allow finding the generated parser sources.
+    # The following works with 'Ninja'. For 'Unix Makefiles', this requires ${PROJECT_BINARY_DIR}/src.
+    BASE_DIRECTORY "${PROJECT_BINARY_DIR}"
+    # /Applications and /Library/Developer are for macOS -- they exclude files from the macOS SDK.
+    EXCLUDE "/Applications/Xcode*" "/Library/Developer/*" "examples/*" "interfaces/*" "tests/*" "vendor/infomap/*" "vendor/pcg/*"
+    # These errors, present with lcov 2.x, are likely due to incompatibility with llvm-cov on macOS.
+    LCOV_ARGS --ignore-errors inconsistent,format,unused
+    GENHTML_ARGS --ignore-errors inconsistent,corrupt,category,unmapped
+  )
+endif()
+
+# Generate configuration headers
+configure_file(
+  ${CMAKE_CURRENT_SOURCE_DIR}/src/config.h.in
+  ${CMAKE_CURRENT_BINARY_DIR}/src/config.h
+)
+configure_file(
+  ${CMAKE_CURRENT_SOURCE_DIR}/include/igraph_config.h.in
+  ${CMAKE_CURRENT_BINARY_DIR}/include/igraph_config.h
+)
+configure_file(
+  ${CMAKE_CURRENT_SOURCE_DIR}/include/igraph_threading.h.in
+  ${CMAKE_CURRENT_BINARY_DIR}/include/igraph_threading.h
+)
+
+# Enable unit tests. Behave nicely and do this only if we are not being
+# included as a sub-project in another CMake project
+if(CMAKE_PROJECT_NAME STREQUAL PROJECT_NAME)
+  include(CTest)
+endif()
+
+# Traverse subdirectories. vendor/ should come first because code in
+# src/CMakeLists.txt depends on targets in vendor/
+add_subdirectory(vendor)
+add_subdirectory(src)
+add_subdirectory(interfaces)
+if(CMAKE_PROJECT_NAME STREQUAL PROJECT_NAME AND BUILD_TESTING)
+  add_subdirectory(tests)
+endif()
+if(CMAKE_PROJECT_NAME STREQUAL PROJECT_NAME AND BUILD_FUZZING)
+  add_subdirectory(fuzzing)
+endif()
+if(CMAKE_PROJECT_NAME STREQUAL PROJECT_NAME)
+  add_subdirectory(doc)
+endif()
+
+# Configure packaging -- only if igraph is the top-level project and not a
+# subproject
+if(CMAKE_PROJECT_NAME STREQUAL PROJECT_NAME)
+  include(packaging)
+endif()
+
+# Show result of configuration
+include(summary)

references/igraph-1.0.1/CONTRIBUTING.md

@@ -0,0 +1,246 @@
+# Contributing to this project
+
+Thank you for being interested in contributing to `igraph`! We need the help of
+volunteers to keep the package going, so every little bit is welcome. You can help out
+the project in several different ways.
+
+This repository only hosts the C code of the `igraph` project. Even if you are not so
+experienced with C, you can contribute in a number of ways:
+
+1. Respond to user questions on our [support forum](https://igraph.discourse.group/).
+2. Correct or improve our [documentation](https://igraph.org/c/html/latest/).
+3. Go over [open issues](https://github.com/igraph/igraph/issues):
+   - Are some older issues still relevant in the most recent version? If not, write a
+     comment to the issue stating that you feel that the issue is not relevant any more.
+   - Can you reproduce some of the bugs that are reported? If so, write a comment to
+     the issue stating that this is still a problem in version X.
+   - Some [issues point out problems with the documentation](https://github.com/igraph/igraph/labels/documentation);
+     perhaps you could help correct these?
+   - Some [issues require clarifying a mathematical problem, or some literature research](https://github.com/igraph/igraph/labels/theory),
+     before any programming can begin. Can you contribute through your theoretical expertise?
+   - Looking to contribute code? Take a look at some [good first issues](https://github.com/igraph/igraph/labels/good%20first%20issue).
+
+## Using the issue tracker
+
+- The issue tracker is the preferred channel for [bug reports](#bugs),
+  [feature requests](#features) and [submitting pull requests](#pull-requests).
+
+- Do you have a question? Please use our [igraph support forum](https://igraph.discourse.group)
+  for support requests.
+
+- Please keep the discussion on topic and respect the opinions of others, and
+  adhere to our [Code of Conduct](https://igraph.org/code-of-conduct.html).
+
+<a name="bugs"></a>
+
+## Bug reports
+
+A bug is a _demonstrable problem_ that is caused by the code in the repository.
+Good bug reports are extremely helpful &mdash; thank you for reporting!
+
+Guidelines for bug reports:
+
+1. **Make sure that the bug is in the C code of igraph and not in one of the
+   higher level interfaces** &mdash; if you are using igraph from R, Python
+   or Mathematica, consider submitting your issue in
+   [igraph/rigraph](https://github.com/igraph/rigraph/issues/new),
+   [igraph/python-igraph](https://github.com/igraph/python-igraph/issues/new)
+   or [szhorvat/IGraphM](https://github.com/szhorvat/IGraphM/issues/new)
+   instead. If you are unsure whether your issue is in the C layer, submit
+   a bug report in the repository of the higher level interface &mdash;
+   we will transfer the issue here if it indeed affects the C layer.
+
+2. **Use the GitHub issue search** &mdash; check if the issue has already been
+   reported.
+
+3. **Check if the issue has been fixed** &mdash; try to reproduce it using the
+   latest `main` or development branch in the repository.
+
+4. **Isolate the problem** &mdash; create a [short, self-contained, correct
+   example](http://sscce.org/).
+
+Please try to be as detailed as possible in your report and provide all
+necessary information. What is your environment? What steps will reproduce the
+issue? What would you expect to be the outcome? All these details will help us
+to fix any potential bugs.
+
+Example:
+
+> Short and descriptive example bug report title
+>
+> A summary of the issue and the compiler/OS environment in which it occurs. If
+> suitable, include the steps required to reproduce the bug.
+>
+> 1. This is the first step
+> 2. This is the second step
+> 3. Further steps, etc.
+>
+> `<url>` - a link to the reduced test case
+>
+> Any other information you want to share that is relevant to the issue being
+> reported. This might include the lines of code that you have identified as
+> causing the bug, and potential solutions (and your opinions on their
+> merits).
+
+
+<a name="features"></a>
+## Feature requests
+
+Feature requests are always welcome. First, take a moment to find out whether your
+idea fits with the scope and aims of the project. Please provide as much detail
+and context as possible, and where possible, references to relevant literature.
+Having said that, implementing new features can be quite time consuming, and as
+such they might not be implemented quickly. In addition, the development team
+might decide not to implement a certain feature. It is up to you to make a case
+to convince the project's developers of the merits of this feature.
+
+<a name="pull-requests"></a>
+## Pull requests
+
+_**Note:** The wiki has a lot of useful information for newcomers, as well as a
+[quick start guide](https://github.com/igraph/igraph/wiki/Quickstart-for-new-contributors)!_
+
+Good pull requests—patches, improvements, new features—are a fantastic help.
+They should remain focused in scope and avoid containing unrelated commits.
+Please also take a look at our [tips on writing igraph code](#tips) before
+getting your hands dirty.
+
+**Please ask first before embarking on any significant pull request** (e.g.
+implementing features, refactoring code, porting to a different language),
+otherwise you risk spending a lot of time working on something that the
+project's developers might not want to merge into the project.
+
+Please adhere to the coding conventions used throughout a project (indentation,
+accurate comments, etc.) and any other requirements (such as test coverage).
+
+Follow the following steps if you would like to make a new pull request:
+
+1. [Fork](http://help.github.com/fork-a-repo/) the project, clone your fork,
+   and configure the remotes:
+
+   ```bash
+   # Clone your fork of the repo into the current directory
+   git clone https://github.com/<your-username>/<repo-name>
+   # Navigate to the newly cloned directory
+   cd <repo-name>
+   # Assign the original repo to a remote called "upstream"
+   git remote add upstream https://github.com/<upstream-owner>/<repo-name>
+   ```
+
+2. Please checkout the section on [branching](#branching) to see whether you
+   need to branch off from the `main` branch or the `develop` branch.
+
+   If you cloned a while ago, get the latest changes from upstream:
+
+   ```bash
+   git checkout <dev-branch>
+   git pull --rebase upstream <dev-branch>
+   ```
+
+3. Create a new topic branch (off the targeted branch, see
+   [branching](#branching) section) to contain your feature, change, or fix:
+
+   ```bash
+   git checkout -b <topic-branch-name>
+   ```
+
+4. Please commit your changes in logical chunks, and try to provide clear commit
+   messages. It helps us during the review process if we can follow your thought
+   process during the implementation. If you hit a dead end, use `git revert`
+   to revert your commits or just go back to an earlier commit with `git checkout`
+   and continue your work from there.
+
+5. We have a [checklist for new igraph functions](https://github.com/igraph/igraph/wiki/Checklist-for-new-(and-old)-functions).
+   If you have added any new functions to igraph, please go through the
+   checklist to ensure that your functions play nicely with the rest of the
+   library.
+
+6. Make sure that your PR is based off the latest code and locally merge (or
+   rebase) the upstream development branch into your topic branch:
+
+   ```bash
+   git pull [--rebase] upstream <dev-branch>
+   ```
+
+   Rebasing is preferable over merging as you do not need to deal with merge
+   conflicts; however, if you already have many commits, merging the upstream
+   development branch may be faster.
+
+7. When your topic branch is up-to-date with the upstream development branch, you can
+   push your topic branch up to your fork:
+
+   ```bash
+   git push origin <topic-branch-name>
+   ```
+
+8. [Open a pull request](https://help.github.com/articles/using-pull-requests/)
+    with a clear title and description.
+
+**IMPORTANT**: By submitting a pull request, you agree to allow the project
+owner to license your work under the same license as that used by the project,
+see also [Legal Stuff](#legal).
+
+<a name="branching"></a>
+
+### Branching
+
+In short, always ask whether your contribution should target the `main` or
+`develop` branch _before_ starting any work. Read on for more details on how
+this is decided.
+
+`igraph` is committed to [semantic versioning](https://semver.org/). We are
+currently still in the development release (0.x), which in principle is a mark
+that the public API is not yet stable. Regardless, we try to maintain semantic
+versioning also for the development releases. We do so as follows. Any released
+minor version (0.x.z) will be API backwards-compatible with any previous release
+of the _same_ minor version (0.x.y, with y < z). This means that _if_ there is
+an API incompatible change, we will increase the minor version. For example,
+release 0.8.1 is API backwards-compatible with release 0.8.0, while release
+0.9.0 might be API incompatible with version 0.8.1. Note that this only concerns
+the _public_ API, internal functions may change also within a minor version.
+
+There will always be two versions of `igraph`: the most recent released version,
+and the next upcoming minor release, which is by definition not yet released.
+The most recent release version is in the `main` branch, while the next
+upcoming minor release is in the `develop` branch. If you make a change that is
+API incompatible with the most recent release, it **must** be merged to
+the `develop` branch. If the change is API backwards-compatible, it **can** be
+merged to the `main` branch. It is possible that you build on recent
+improvements in the `develop` branch, in which case your change should of course
+target the `develop` branch. If you only add new functionality, but do not
+change anything of the existing API, this should be backwards-compatible, and
+can be merged in the `main` branch.
+
+When you make a new pull request, please specify the correct target branch. The
+maintainers of `igraph` may decide to retarget your pull request to the correct
+branch. Retargeting you pull request may result in merge conflicts, so it is
+always good to decide **before** starting to work on something whether you
+should start from the `main` branch or from the `develop` branch. In most
+cases, changes in the `main` branch will also be merged to the `develop`
+branch by the maintainers.
+
+<a name="tips"></a>
+## Writing igraph Code
+
+[Some tips on writing igraph code](https://github.com/igraph/igraph/wiki/Tips-on-writing-igraph-code).
+
+## Ask Us!
+
+In general, if you are not sure about something, please ask! You can
+open an issue on GitHub, open a thread in our
+[igraph support forum](https://igraph.discourse.group), or write to
+[@ntamas](https://github.com/ntamas), [@vtraag](https://github.com/vtraag),
+[@szhorvat](https://github.com/szhorvat), [@iosonofabio](https://github.com/iosonofabio) or
+[@gaborcsardi](https://github.com/gaborcsardi).
+We prefer open communication channels, because others can then learn from it
+too.
+
+<a name="legal"></a>
+## Legal Stuff
+
+This is a pain to deal with, but we can't avoid it, unfortunately.
+
+`igraph` is licensed under the "General Public License (GPL) version 2, or
+later". The igraph manual is licensed under the "GNU Free Documentation
+License". By submitting a patch or pull request, you agree to allow the project
+owner to license your work under the same license as that used by the project.

references/igraph-1.0.1/CONTRIBUTORS.md

@@ -0,0 +1,121 @@
+# Contributors ✨
+
+Thanks goes to these wonderful people ([emoji key](https://allcontributors.org/docs/en/emoji-key)):
+
+<!-- ALL-CONTRIBUTORS-LIST:START - Do not remove or modify this section -->
+<!-- prettier-ignore-start -->
+<!-- markdownlint-disable -->
+<table>
+  <tbody>
+    <tr>
+      <td align="center" valign="top" width="14.28%"><a href="https://github.com/gaborcsardi"><img src="https://avatars.githubusercontent.com/u/660288?v=4?s=100" width="100px;" alt="Gábor Csárdi"/><br /><sub><b>Gábor Csárdi</b></sub></a><br /><a href="https://github.com/igraph/igraph/commits?author=gaborcsardi" title="Code">💻</a></td>
+      <td align="center" valign="top" width="14.28%"><a href="https://collmot.com/"><img src="https://avatars.githubusercontent.com/u/195637?v=4?s=100" width="100px;" alt="Tamás Nepusz"/><br /><sub><b>Tamás Nepusz</b></sub></a><br /><a href="https://github.com/igraph/igraph/commits?author=ntamas" title="Code">💻</a></td>
+      <td align="center" valign="top" width="14.28%"><a href="http://szhorvat.net/"><img src="https://avatars.githubusercontent.com/u/1212871?v=4?s=100" width="100px;" alt="Szabolcs Horvát"/><br /><sub><b>Szabolcs Horvát</b></sub></a><br /><a href="https://github.com/igraph/igraph/commits?author=szhorvat" title="Code">💻</a></td>
+      <td align="center" valign="top" width="14.28%"><a href="http://www.traag.net/"><img src="https://avatars.githubusercontent.com/u/6057804?v=4?s=100" width="100px;" alt="Vincent Traag"/><br /><sub><b>Vincent Traag</b></sub></a><br /><a href="https://github.com/igraph/igraph/commits?author=vtraag" title="Code">💻</a></td>
+      <td align="center" valign="top" width="14.28%"><a href="https://github.com/GroteGnoom"><img src="https://avatars.githubusercontent.com/u/8137208?v=4?s=100" width="100px;" alt="GroteGnoom"/><br /><sub><b>GroteGnoom</b></sub></a><br /><a href="https://github.com/igraph/igraph/commits?author=GroteGnoom" title="Code">💻</a></td>
+      <td align="center" valign="top" width="14.28%"><a href="https://fabilab.org/"><img src="https://avatars.githubusercontent.com/u/1200640?v=4?s=100" width="100px;" alt="Fabio Zanini"/><br /><sub><b>Fabio Zanini</b></sub></a><br /><a href="https://github.com/igraph/igraph/commits?author=iosonofabio" title="Code">💻</a></td>
+      <td align="center" valign="top" width="14.28%"><a href="http://www.katzien.de/"><img src="https://avatars.githubusercontent.com/u/890156?v=4?s=100" width="100px;" alt="Jan Katins"/><br /><sub><b>Jan Katins</b></sub></a><br /><a href="https://github.com/igraph/igraph/commits?author=jankatins" title="Code">💻</a></td>
+    </tr>
+    <tr>
+      <td align="center" valign="top" width="14.28%"><a href="https://github.com/adalisan"><img src="https://avatars.githubusercontent.com/u/1790714?v=4?s=100" width="100px;" alt="Sancar Adali"/><br /><sub><b>Sancar Adali</b></sub></a><br /><a href="https://github.com/igraph/igraph/commits?author=adalisan" title="Code">💻</a></td>
+      <td align="center" valign="top" width="14.28%"><a href="https://github.com/FerranPares"><img src="https://avatars.githubusercontent.com/u/9196604?v=4?s=100" width="100px;" alt="Ferran Parés"/><br /><sub><b>Ferran Parés</b></sub></a><br /><a href="https://github.com/igraph/igraph/commits?author=FerranPares" title="Code">💻</a></td>
+      <td align="center" valign="top" width="14.28%"><a href="https://github.com/mvngu"><img src="https://avatars.githubusercontent.com/u/362259?v=4?s=100" width="100px;" alt="mvngu"/><br /><sub><b>mvngu</b></sub></a><br /><a href="https://github.com/igraph/igraph/commits?author=mvngu" title="Code">💻</a></td>
+      <td align="center" valign="top" width="14.28%"><a href="https://github.com/das-intensity"><img src="https://avatars.githubusercontent.com/u/12521554?v=4?s=100" width="100px;" alt="Dr. Nick"/><br /><sub><b>Dr. Nick</b></sub></a><br /><a href="https://github.com/igraph/igraph/commits?author=das-intensity" title="Code">💻</a></td>
+      <td align="center" valign="top" width="14.28%"><a href="https://github.com/jannick0"><img src="https://avatars.githubusercontent.com/u/6295579?v=4?s=100" width="100px;" alt="jannick0"/><br /><sub><b>jannick0</b></sub></a><br /><a href="https://github.com/igraph/igraph/commits?author=jannick0" title="Code">💻</a></td>
+      <td align="center" valign="top" width="14.28%"><a href="https://www.rezozer.net/"><img src="https://avatars.githubusercontent.com/u/8476716?v=4?s=100" width="100px;" alt="Jérôme Benoit"/><br /><sub><b>Jérôme Benoit</b></sub></a><br /><a href="https://github.com/igraph/igraph/commits?author=jgmbenoit" title="Code">💻</a></td>
+      <td align="center" valign="top" width="14.28%"><a href="https://github.com/frederik-h"><img src="https://avatars.githubusercontent.com/u/22046314?v=4?s=100" width="100px;" alt="Frederik Harwath"/><br /><sub><b>Frederik Harwath</b></sub></a><br /><a href="https://github.com/igraph/igraph/commits?author=frederik-h" title="Code">💻</a></td>
+    </tr>
+    <tr>
+      <td align="center" valign="top" width="14.28%"><a href="https://adalogics.com/"><img src="https://avatars.githubusercontent.com/u/44787359?v=4?s=100" width="100px;" alt="AdamKorcz"/><br /><sub><b>AdamKorcz</b></sub></a><br /><a href="https://github.com/igraph/igraph/commits?author=AdamKorcz" title="Code">💻</a></td>
+      <td align="center" valign="top" width="14.28%"><a href="https://github.com/antonio-rojas"><img src="https://avatars.githubusercontent.com/u/11243355?v=4?s=100" width="100px;" alt="Antonio Rojas"/><br /><sub><b>Antonio Rojas</b></sub></a><br /><a href="https://github.com/igraph/igraph/commits?author=antonio-rojas" title="Code">💻</a></td>
+      <td align="center" valign="top" width="14.28%"><a href="https://pyedu.hu/arpad/"><img src="https://avatars.githubusercontent.com/u/951303?v=4?s=100" width="100px;" alt="Árpád Horváth"/><br /><sub><b>Árpád Horváth</b></sub></a><br /><a href="https://github.com/igraph/igraph/commits?author=horvatha" title="Code">💻</a></td>
+      <td align="center" valign="top" width="14.28%"><a href="http://finger-tree.blogspot.com/"><img src="https://avatars.githubusercontent.com/u/406445?v=4?s=100" width="100px;" alt="Peter Scott"/><br /><sub><b>Peter Scott</b></sub></a><br /><a href="https://github.com/igraph/igraph/commits?author=PeterScott" title="Code">💻</a></td>
+      <td align="center" valign="top" width="14.28%"><a href="https://github.com/naviddianati"><img src="https://avatars.githubusercontent.com/u/5558232?v=4?s=100" width="100px;" alt="Navid Dianati"/><br /><sub><b>Navid Dianati</b></sub></a><br /><a href="https://github.com/igraph/igraph/commits?author=naviddianati" title="Code">💻</a></td>
+      <td align="center" valign="top" width="14.28%"><a href="https://github.com/YasirKusay"><img src="https://avatars.githubusercontent.com/u/59812220?v=4?s=100" width="100px;" alt="YasirKusay"/><br /><sub><b>YasirKusay</b></sub></a><br /><a href="https://github.com/igraph/igraph/commits?author=YasirKusay" title="Code">💻</a></td>
+      <td align="center" valign="top" width="14.28%"><a href="http://heal.heuristiclab.com/team/beham"><img src="https://avatars.githubusercontent.com/u/5585242?v=4?s=100" width="100px;" alt="Andreas Beham"/><br /><sub><b>Andreas Beham</b></sub></a><br /><a href="https://github.com/igraph/igraph/commits?author=abeham" title="Code">💻</a></td>
+    </tr>
+    <tr>
+      <td align="center" valign="top" width="14.28%"><a href="http://kasterma.net/"><img src="https://avatars.githubusercontent.com/u/421437?v=4?s=100" width="100px;" alt="Bart Kastermans"/><br /><sub><b>Bart Kastermans</b></sub></a><br /><a href="https://github.com/igraph/igraph/commits?author=kasterma" title="Code">💻</a></td>
+      <td align="center" valign="top" width="14.28%"><a href="https://twitter.com/eriknwelch"><img src="https://avatars.githubusercontent.com/u/2058401?v=4?s=100" width="100px;" alt="Erik Welch"/><br /><sub><b>Erik Welch</b></sub></a><br /><a href="https://github.com/igraph/igraph/commits?author=eriknw" title="Code">💻</a></td>
+      <td align="center" valign="top" width="14.28%"><a href="https://www.topbug.net/"><img src="https://avatars.githubusercontent.com/u/325476?v=4?s=100" width="100px;" alt="Hong Xu"/><br /><sub><b>Hong Xu</b></sub></a><br /><a href="https://github.com/igraph/igraph/commits?author=xuhdev" title="Code">💻</a></td>
+      <td align="center" valign="top" width="14.28%"><a href="https://github.com/Hosseinazari"><img src="https://avatars.githubusercontent.com/u/971459?v=4?s=100" width="100px;" alt="Hosseinazari"/><br /><sub><b>Hosseinazari</b></sub></a><br /><a href="https://github.com/igraph/igraph/commits?author=Hosseinazari" title="Code">💻</a></td>
+      <td align="center" valign="top" width="14.28%"><a href="https://jmonlong.github.io/"><img src="https://avatars.githubusercontent.com/u/5704457?v=4?s=100" width="100px;" alt="Jean Monlong"/><br /><sub><b>Jean Monlong</b></sub></a><br /><a href="https://github.com/igraph/igraph/commits?author=jmonlong" title="Code">💻</a></td>
+      <td align="center" valign="top" width="14.28%"><a href="https://github.com/Keivin98"><img src="https://avatars.githubusercontent.com/u/31882637?v=4?s=100" width="100px;" alt="Keivin98"/><br /><sub><b>Keivin98</b></sub></a><br /><a href="https://github.com/igraph/igraph/commits?author=Keivin98" title="Code">💻</a></td>
+      <td align="center" valign="top" width="14.28%"><a href="https://medium.com/@leo88"><img src="https://avatars.githubusercontent.com/u/46436462?v=4?s=100" width="100px;" alt="Leonardo"/><br /><sub><b>Leonardo</b></sub></a><br /><a href="https://github.com/igraph/igraph/commits?author=leo-aa88" title="Code">💻</a></td>
+    </tr>
+    <tr>
+      <td align="center" valign="top" width="14.28%"><a href="https://github.com/msk"><img src="https://avatars.githubusercontent.com/u/19195?v=4?s=100" width="100px;" alt="Min Kim"/><br /><sub><b>Min Kim</b></sub></a><br /><a href="https://github.com/igraph/igraph/commits?author=msk" title="Code">💻</a></td>
+      <td align="center" valign="top" width="14.28%"><a href="https://github.com/khitrin"><img src="https://avatars.githubusercontent.com/u/25713847?v=4?s=100" width="100px;" alt="Nikolay Khitrin"/><br /><sub><b>Nikolay Khitrin</b></sub></a><br /><a href="https://github.com/igraph/igraph/commits?author=khitrin" title="Code">💻</a></td>
+      <td align="center" valign="top" width="14.28%"><a href="https://github.com/pschmied"><img src="https://avatars.githubusercontent.com/u/1065905?v=4?s=100" width="100px;" alt="Peter Schmiedeskamp"/><br /><sub><b>Peter Schmiedeskamp</b></sub></a><br /><a href="https://github.com/igraph/igraph/commits?author=pschmied" title="Code">💻</a></td>
+      <td align="center" valign="top" width="14.28%"><a href="https://phil.red/"><img src="https://avatars.githubusercontent.com/u/291575?v=4?s=100" width="100px;" alt="Philipp A."/><br /><sub><b>Philipp A.</b></sub></a><br /><a href="https://github.com/igraph/igraph/commits?author=flying-sheep" title="Code">💻</a></td>
+      <td align="center" valign="top" width="14.28%"><a href="https://www.linkedin.com/in/ramy-saied-0415b810b/"><img src="https://avatars.githubusercontent.com/u/22375919?v=4?s=100" width="100px;" alt="Ramy Saied"/><br /><sub><b>Ramy Saied</b></sub></a><br /><a href="https://github.com/igraph/igraph/commits?author=RamySaied1" title="Code">💻</a></td>
+      <td align="center" valign="top" width="14.28%"><a href="https://github.com/dotlambda"><img src="https://avatars.githubusercontent.com/u/6806011?v=4?s=100" width="100px;" alt="Robert Schütz"/><br /><sub><b>Robert Schütz</b></sub></a><br /><a href="https://github.com/igraph/igraph/commits?author=dotlambda" title="Code">💻</a></td>
+      <td align="center" valign="top" width="14.28%"><a href="https://github.com/ryanduffin"><img src="https://avatars.githubusercontent.com/u/5711508?v=4?s=100" width="100px;" alt="Ryan Duffin"/><br /><sub><b>Ryan Duffin</b></sub></a><br /><a href="https://github.com/igraph/igraph/commits?author=ryanduffin" title="Code">💻</a></td>
+    </tr>
+    <tr>
+      <td align="center" valign="top" width="14.28%"><a href="http://www.shlomifish.org/"><img src="https://avatars.githubusercontent.com/u/3150?v=4?s=100" width="100px;" alt="Shlomi Fish"/><br /><sub><b>Shlomi Fish</b></sub></a><br /><a href="https://github.com/igraph/igraph/commits?author=shlomif" title="Code">💻</a></td>
+      <td align="center" valign="top" width="14.28%"><a href="https://github.com/kloczek"><img src="https://avatars.githubusercontent.com/u/31284574?v=4?s=100" width="100px;" alt="Tomasz Kłoczko"/><br /><sub><b>Tomasz Kłoczko</b></sub></a><br /><a href="https://github.com/igraph/igraph/commits?author=kloczek" title="Code">💻</a></td>
+      <td align="center" valign="top" width="14.28%"><a href="https://heavywatal.github.io/"><img src="https://avatars.githubusercontent.com/u/1431267?v=4?s=100" width="100px;" alt="Watal M. Iwasaki"/><br /><sub><b>Watal M. Iwasaki</b></sub></a><br /><a href="https://github.com/igraph/igraph/commits?author=heavywatal" title="Code">💻</a></td>
+      <td align="center" valign="top" width="14.28%"><a href="https://github.com/nograpes"><img src="https://avatars.githubusercontent.com/u/2967973?v=4?s=100" width="100px;" alt="Aman Verma"/><br /><sub><b>Aman Verma</b></sub></a><br /><a href="https://github.com/igraph/igraph/commits?author=nograpes" title="Code">💻</a></td>
+      <td align="center" valign="top" width="14.28%"><a href="https://github.com/guyroznb"><img src="https://avatars.githubusercontent.com/u/55619320?v=4?s=100" width="100px;" alt="guy rozenberg"/><br /><sub><b>guy rozenberg</b></sub></a><br /><a href="https://github.com/igraph/igraph/commits?author=guyroznb" title="Code">💻</a></td>
+      <td align="center" valign="top" width="14.28%"><a href="http://linkedin.com/in/artemvl"><img src="https://avatars.githubusercontent.com/u/6162969?v=4?s=100" width="100px;" alt="Artem V L"/><br /><sub><b>Artem V L</b></sub></a><br /><a href="https://github.com/igraph/igraph/commits?author=luav" title="Code">💻</a></td>
+      <td align="center" valign="top" width="14.28%"><a href="https://github.com/Katterrina"><img src="https://avatars.githubusercontent.com/u/31630249?v=4?s=100" width="100px;" alt="Kateřina Č."/><br /><sub><b>Kateřina Č.</b></sub></a><br /><a href="https://github.com/igraph/igraph/commits?author=Katterrina" title="Code">💻</a></td>
+    </tr>
+    <tr>
+      <td align="center" valign="top" width="14.28%"><a href="https://github.com/valdaarhun"><img src="https://avatars.githubusercontent.com/u/39989901?v=4?s=100" width="100px;" alt="valdaarhun"/><br /><sub><b>valdaarhun</b></sub></a><br /><a href="https://github.com/igraph/igraph/commits?author=valdaarhun" title="Code">💻</a></td>
+      <td align="center" valign="top" width="14.28%"><a href="https://github.com/YuliYudith"><img src="https://avatars.githubusercontent.com/u/54366258?v=4?s=100" width="100px;" alt="YuliYudith"/><br /><sub><b>YuliYudith</b></sub></a><br /><a href="https://github.com/igraph/igraph/commits?author=YuliYudith" title="Code">💻</a></td>
+      <td align="center" valign="top" width="14.28%"><a href="https://github.com/alexsyou"><img src="https://avatars.githubusercontent.com/u/54590871?v=4?s=100" width="100px;" alt="alexsyou"/><br /><sub><b>alexsyou</b></sub></a><br /><a href="https://github.com/igraph/igraph/commits?author=alexsyou" title="Code">💻</a></td>
+      <td align="center" valign="top" width="14.28%"><a href="https://github.com/rohitt28"><img src="https://avatars.githubusercontent.com/u/67415747?v=4?s=100" width="100px;" alt="Rohit Tawde"/><br /><sub><b>Rohit Tawde</b></sub></a><br /><a href="https://github.com/igraph/igraph/commits?author=rohitt28" title="Code">💻</a></td>
+      <td align="center" valign="top" width="14.28%"><a href="https://github.com/alexperrone"><img src="https://avatars.githubusercontent.com/u/4990236?v=4?s=100" width="100px;" alt="alexperrone"/><br /><sub><b>alexperrone</b></sub></a><br /><a href="https://github.com/igraph/igraph/commits?author=alexperrone" title="Code">💻</a></td>
+      <td align="center" valign="top" width="14.28%"><a href="https://github.com/borsgeorgica"><img src="https://avatars.githubusercontent.com/u/15649138?v=4?s=100" width="100px;" alt="Georgica Bors"/><br /><sub><b>Georgica Bors</b></sub></a><br /><a href="https://github.com/igraph/igraph/commits?author=borsgeorgica" title="Code">💻</a></td>
+      <td align="center" valign="top" width="14.28%"><a href="https://www.linkedin.com/in/meet-patel-b1329a16b/"><img src="https://avatars.githubusercontent.com/u/63169740?v=4?s=100" width="100px;" alt="MEET PATEL"/><br /><sub><b>MEET PATEL</b></sub></a><br /><a href="https://github.com/igraph/igraph/commits?author=meetpatel0963" title="Code">💻</a></td>
+    </tr>
+    <tr>
+      <td align="center" valign="top" width="14.28%"><a href="https://github.com/kwofach"><img src="https://avatars.githubusercontent.com/u/97578264?v=4?s=100" width="100px;" alt="kwofach"/><br /><sub><b>kwofach</b></sub></a><br /><a href="https://github.com/igraph/igraph/commits?author=kwofach" title="Code">💻</a></td>
+      <td align="center" valign="top" width="14.28%"><a href="https://github.com/Gomango999"><img src="https://avatars.githubusercontent.com/u/37771462?v=4?s=100" width="100px;" alt="Kevin Zhu"/><br /><sub><b>Kevin Zhu</b></sub></a><br /><a href="https://github.com/igraph/igraph/commits?author=Gomango999" title="Code">💻</a></td>
+      <td align="center" valign="top" width="14.28%"><a href="https://github.com/pradkrish"><img src="https://avatars.githubusercontent.com/u/47261443?v=4?s=100" width="100px;" alt="Pradeep Krishnamurthy"/><br /><sub><b>Pradeep Krishnamurthy</b></sub></a><br /><a href="https://github.com/igraph/igraph/commits?author=pradkrish" title="Code">💻</a></td>
+      <td align="center" valign="top" width="14.28%"><a href="https://github.com/flange-ipb"><img src="https://avatars.githubusercontent.com/u/34936695?v=4?s=100" width="100px;" alt="flange-ipb"/><br /><sub><b>flange-ipb</b></sub></a><br /><a href="https://github.com/igraph/igraph/commits?author=flange-ipb" title="Code">💻</a></td>
+      <td align="center" valign="top" width="14.28%"><a href="http://goo.gl/IlWG8U"><img src="https://avatars.githubusercontent.com/u/500?v=4?s=100" width="100px;" alt="Juan Julián Merelo Guervós"/><br /><sub><b>Juan Julián Merelo Guervós</b></sub></a><br /><a href="https://github.com/igraph/igraph/commits?author=JJ" title="Code">💻</a></td>
+      <td align="center" valign="top" width="14.28%"><a href="https://github.com/rfulekjames"><img src="https://avatars.githubusercontent.com/u/54232342?v=4?s=100" width="100px;" alt="Radoslav Fulek"/><br /><sub><b>Radoslav Fulek</b></sub></a><br /><a href="https://github.com/igraph/igraph/commits?author=rfulekjames" title="Code">💻</a></td>
+      <td align="center" valign="top" width="14.28%"><a href="https://github.com/professorcode1"><img src="https://avatars.githubusercontent.com/u/42749164?v=4?s=100" width="100px;" alt="professorcode1"/><br /><sub><b>professorcode1</b></sub></a><br /><a href="https://github.com/igraph/igraph/commits?author=professorcode1" title="Code">💻</a></td>
+    </tr>
+    <tr>
+      <td align="center" valign="top" width="14.28%"><a href="https://github.com/larah19"><img src="https://avatars.githubusercontent.com/u/54937363?v=4?s=100" width="100px;" alt="larah19"/><br /><sub><b>larah19</b></sub></a><br /><a href="https://github.com/igraph/igraph/commits?author=larah19" title="Code">💻</a></td>
+      <td align="center" valign="top" width="14.28%"><a href="https://github.com/Biswa96"><img src="https://avatars.githubusercontent.com/u/31443074?v=4?s=100" width="100px;" alt="Biswapriyo Nath"/><br /><sub><b>Biswapriyo Nath</b></sub></a><br /><a href="https://github.com/igraph/igraph/commits?author=Biswa96" title="Code">💻</a></td>
+      <td align="center" valign="top" width="14.28%"><a href="http://cecinestpasunefromage.wordpress.com/"><img src="https://avatars.githubusercontent.com/u/2363820?v=4?s=100" width="100px;" alt="Gwyn Ciesla"/><br /><sub><b>Gwyn Ciesla</b></sub></a><br /><a href="https://github.com/igraph/igraph/commits?author=limburgher" title="Code">💻</a></td>
+      <td align="center" valign="top" width="14.28%"><a href="https://github.com/aagon"><img src="https://avatars.githubusercontent.com/u/10883752?v=4?s=100" width="100px;" alt="aagon"/><br /><sub><b>aagon</b></sub></a><br /><a href="https://github.com/igraph/igraph/commits?author=aagon" title="Code">💻</a></td>
+      <td align="center" valign="top" width="14.28%"><a href="https://github.com/GanzuraTheConsumer"><img src="https://avatars.githubusercontent.com/u/19657136?v=4?s=100" width="100px;" alt="Quinn Buratynski"/><br /><sub><b>Quinn Buratynski</b></sub></a><br /><a href="https://github.com/igraph/igraph/commits?author=GanzuraTheConsumer" title="Code">💻</a></td>
+      <td align="center" valign="top" width="14.28%"><a href="https://github.com/Tagl"><img src="https://avatars.githubusercontent.com/u/7704746?v=4?s=100" width="100px;" alt="Arnar Bjarni Arnarson"/><br /><sub><b>Arnar Bjarni Arnarson</b></sub></a><br /><a href="https://github.com/igraph/igraph/commits?author=Tagl" title="Code">💻</a></td>
+      <td align="center" valign="top" width="14.28%"><a href="https://github.com/SoapGentoo"><img src="https://avatars.githubusercontent.com/u/16636962?v=4?s=100" width="100px;" alt="David Seifert"/><br /><sub><b>David Seifert</b></sub></a><br /><a href="https://github.com/igraph/igraph/commits?author=SoapGentoo" title="Code">💻</a></td>
+    </tr>
+    <tr>
+      <td align="center" valign="top" width="14.28%"><a href="https://fosstodon.org/@kirill"><img src="https://avatars.githubusercontent.com/u/1741643?v=4?s=100" width="100px;" alt="Kirill Müller"/><br /><sub><b>Kirill Müller</b></sub></a><br /><a href="https://github.com/igraph/igraph/commits?author=krlmlr" title="Code">💻</a></td>
+      <td align="center" valign="top" width="14.28%"><a href="https://github.com/gendelpiekel"><img src="https://avatars.githubusercontent.com/u/14215028?v=4?s=100" width="100px;" alt="Michael"/><br /><sub><b>Michael</b></sub></a><br /><a href="https://github.com/igraph/igraph/commits?author=gendelpiekel" title="Code">💻</a></td>
+      <td align="center" valign="top" width="14.28%"><a href="https://github.com/GenieTim"><img src="https://avatars.githubusercontent.com/u/8596965?v=4?s=100" width="100px;" alt="Tim Bernhard"/><br /><sub><b>Tim Bernhard</b></sub></a><br /><a href="https://github.com/igraph/igraph/commits?author=GenieTim" title="Code">💻</a></td>
+      <td align="center" valign="top" width="14.28%"><a href="https://masalmon.eu/"><img src="https://avatars.githubusercontent.com/u/8360597?v=4?s=100" width="100px;" alt="Maëlle Salmon"/><br /><sub><b>Maëlle Salmon</b></sub></a><br /><a href="https://github.com/igraph/igraph/commits?author=maelle" title="Code">💻</a></td>
+      <td align="center" valign="top" width="14.28%"><a href="https://github.com/gulshan-123"><img src="https://avatars.githubusercontent.com/u/72340125?v=4?s=100" width="100px;" alt="Gulshan Kumar"/><br /><sub><b>Gulshan Kumar</b></sub></a><br /><a href="https://github.com/igraph/igraph/commits?author=gulshan-123" title="Code">💻</a></td>
+      <td align="center" valign="top" width="14.28%"><a href="https://github.com/carlos-planelles"><img src="https://avatars.githubusercontent.com/u/132953755?v=4?s=100" width="100px;" alt="Carlos Planelles"/><br /><sub><b>Carlos Planelles</b></sub></a><br /><a href="https://github.com/igraph/igraph/commits?author=carlos-planelles" title="Code">💻</a></td>
+      <td align="center" valign="top" width="14.28%"><a href="https://github.com/devlohani99"><img src="https://avatars.githubusercontent.com/u/142163543?v=4?s=100" width="100px;" alt="Dev_Lohani"/><br /><sub><b>Dev_Lohani</b></sub></a><br /><a href="https://github.com/igraph/igraph/commits?author=devlohani99" title="Code">💻</a></td>
+    </tr>
+    <tr>
+      <td align="center" valign="top" width="14.28%"><a href="https://lucaslopes.me/"><img src="https://avatars.githubusercontent.com/u/8731439?v=4?s=100" width="100px;" alt="Lucas Lopes Felipe"/><br /><sub><b>Lucas Lopes Felipe</b></sub></a><br /><a href="https://github.com/igraph/igraph/commits?author=lucaslopes" title="Code">💻</a></td>
+      <td align="center" valign="top" width="14.28%"><a href="https://github.com/its-serah"><img src="https://avatars.githubusercontent.com/u/153510021?v=4?s=100" width="100px;" alt="Sarah Rashidi"/><br /><sub><b>Sarah Rashidi</b></sub></a><br /><a href="https://github.com/igraph/igraph/commits?author=its-serah" title="Code">💻</a></td>
+      <td align="center" valign="top" width="14.28%"><a href="https://github.com/minifinity"><img src="https://avatars.githubusercontent.com/u/124811507?v=4?s=100" width="100px;" alt="Zara Zong"/><br /><sub><b>Zara Zong</b></sub></a><br /><a href="https://github.com/igraph/igraph/commits?author=minifinity" title="Code">💻</a></td>
+      <td align="center" valign="top" width="14.28%"><a href="https://github.com/Zepeacedust"><img src="https://avatars.githubusercontent.com/u/41028225?v=4?s=100" width="100px;" alt="Arnór Friðriksson"/><br /><sub><b>Arnór Friðriksson</b></sub></a><br /><a href="https://github.com/igraph/igraph/commits?author=Zepeacedust" title="Code">💻</a></td>
+      <td align="center" valign="top" width="14.28%"><a href="https://github.com/VRajesh7649"><img src="https://avatars.githubusercontent.com/u/56133137?v=4?s=100" width="100px;" alt="Varun Rajesh"/><br /><sub><b>Varun Rajesh</b></sub></a><br /><a href="https://github.com/igraph/igraph/commits?author=VRajesh7649" title="Code">💻</a></td>
+      <td align="center" valign="top" width="14.28%"><a href="https://github.com/stevesajeev1"><img src="https://avatars.githubusercontent.com/u/76565057?v=4?s=100" width="100px;" alt="Steve Sajeev"/><br /><sub><b>Steve Sajeev</b></sub></a><br /><a href="https://github.com/igraph/igraph/commits?author=stevesajeev1" title="Code">💻</a></td>
+      <td align="center" valign="top" width="14.28%"><a href="https://github.com/RohithS98"><img src="https://avatars.githubusercontent.com/u/36558130?v=4?s=100" width="100px;" alt="Rohith Sudheer"/><br /><sub><b>Rohith Sudheer</b></sub></a><br /><a href="https://github.com/igraph/igraph/commits?author=RohithS98" title="Code">💻</a></td>
+    </tr>
+    <tr>
+      <td align="center" valign="top" width="14.28%"><a href="https://github.com/GrishaVar"><img src="https://avatars.githubusercontent.com/u/33952698?v=4?s=100" width="100px;" alt="Grisha"/><br /><sub><b>Grisha</b></sub></a><br /><a href="https://github.com/igraph/igraph/commits?author=GrishaVar" title="Code">💻</a></td>
+      <td align="center" valign="top" width="14.28%"><a href="https://github.com/Antonov548"><img src="https://avatars.githubusercontent.com/u/22891541?v=4?s=100" width="100px;" alt="Michael Antonov"/><br /><sub><b>Michael Antonov</b></sub></a><br /><a href="https://github.com/igraph/igraph/commits?author=Antonov548" title="Code">💻</a></td>
+    </tr>
+  </tbody>
+</table>
+
+<!-- markdownlint-restore -->
+<!-- prettier-ignore-end -->
+
+<!-- ALL-CONTRIBUTORS-LIST:END -->
+
+This project follows the [all-contributors](https://github.com/all-contributors/all-contributors) specification. Contributions of any kind welcome!

references/igraph-1.0.1/CONTRIBUTORS.txt

@@ -0,0 +1,87 @@
+Thanks goes to these wonderful people:
+
+Gábor Csárdi (@gaborcsardi)
+Tamás Nepusz (@ntamas)
+Szabolcs Horvát (@szhorvat)
+Vincent Traag (@vtraag)
+GroteGnoom (@GroteGnoom)
+Fabio Zanini (@iosonofabio)
+Jan Katins (@jankatins)
+Sancar Adali (@adalisan)
+Ferran Parés (@FerranPares)
+mvngu (@mvngu)
+Dr. Nick (@das-intensity)
+jannick0 (@jannick0)
+Jérôme Benoit (@jgmbenoit)
+Frederik Harwath (@frederik-h)
+AdamKorcz (@AdamKorcz)
+Antonio Rojas (@antonio-rojas)
+Árpád Horváth (@horvatha)
+Peter Scott (@PeterScott)
+Navid Dianati (@naviddianati)
+YasirKusay (@YasirKusay)
+Andreas Beham (@abeham)
+Bart Kastermans (@kasterma)
+Erik Welch (@eriknw)
+Hong Xu (@xuhdev)
+Hosseinazari (@Hosseinazari)
+Jean Monlong (@jmonlong)
+Keivin98 (@Keivin98)
+Leonardo (@leo-aa88)
+Min Kim (@msk)
+Nikolay Khitrin (@khitrin)
+Peter Schmiedeskamp (@pschmied)
+Philipp A. (@flying-sheep)
+Ramy Saied (@RamySaied1)
+Robert Schütz (@dotlambda)
+Ryan Duffin (@ryanduffin)
+Shlomi Fish (@shlomif)
+Tomasz Kłoczko (@kloczek)
+Watal M. Iwasaki (@heavywatal)
+Aman Verma (@nograpes)
+guy rozenberg (@guyroznb)
+Artem V L (@luav)
+Kateřina Č. (@Katterrina)
+valdaarhun (@valdaarhun)
+YuliYudith (@YuliYudith)
+alexsyou (@alexsyou)
+Rohit Tawde (@rohitt28)
+alexperrone (@alexperrone)
+Georgica Bors (@borsgeorgica)
+MEET PATEL (@meetpatel0963)
+kwofach (@kwofach)
+Kevin Zhu (@Gomango999)
+Pradeep Krishnamurthy (@pradkrish)
+flange-ipb (@flange-ipb)
+Juan Julián Merelo Guervós (@JJ)
+Radoslav Fulek (@rfulekjames)
+professorcode1 (@professorcode1)
+larah19 (@larah19)
+Biswapriyo Nath (@Biswa96)
+Gwyn Ciesla (@limburgher)
+aagon (@aagon)
+Quinn Buratynski (@GanzuraTheConsumer)
+Arnar Bjarni Arnarson (@Tagl)
+David Seifert (@SoapGentoo)
+Kirill Müller (@krlmlr)
+Michael (@gendelpiekel)
+Tim Bernhard (@GenieTim)
+Maëlle Salmon (@maelle)
+Gulshan Kumar (@gulshan-123)
+Carlos Planelles (@carlos-planelles)
+Dev_Lohani (@devlohani99)
+Lucas Lopes Felipe (@lucaslopes)
+Sarah Rashidi (@its-serah)
+Zara Zong (@minifinity)
+Arnór Friðriksson (@Zepeacedust)
+Varun Rajesh (@VRajesh7649)
+Steve Sajeev (@stevesajeev1)
+Rohith Sudheer (@RohithS98)
+Grisha (@GrishaVar)
+Michael Antonov (@Antonov548)
+
+This project follows the [all-contributors][1] specification. Contributions of any kind welcome!
+
+This file is an automatically generated, plain-text version of CONTRIBUTORS.md.
+
+[1]: https://github.com/all-contributors/all-contributors

references/igraph-1.0.1/COPYING

@@ -0,0 +1,340 @@
+		    GNU GENERAL PUBLIC LICENSE
+		       Version 2, June 1991
+
+ Copyright (C) 1989, 1991 Free Software Foundation, Inc.
+                       51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
+ Everyone is permitted to copy and distribute verbatim copies
+ of this license document, but changing it is not allowed.
+
+			    Preamble
+
+  The licenses for most software are designed to take away your
+freedom to share and change it.  By contrast, the GNU General Public
+License is intended to guarantee your freedom to share and change free
+software--to make sure the software is free for all its users.  This
+General Public License applies to most of the Free Software
+Foundation's software and to any other program whose authors commit to
+using it.  (Some other Free Software Foundation software is covered by
+the GNU Library General Public License instead.)  You can apply it to
+your programs, too.
+
+  When we speak of free software, we are referring to freedom, not
+price.  Our General Public Licenses are designed to make sure that you
+have the freedom to distribute copies of free software (and charge for
+this service if you wish), that you receive source code or can get it
+if you want it, that you can change the software or use pieces of it
+in new free programs; and that you know you can do these things.
+
+  To protect your rights, we need to make restrictions that forbid
+anyone to deny you these rights or to ask you to surrender the rights.
+These restrictions translate to certain responsibilities for you if you
+distribute copies of the software, or if you modify it.
+
+  For example, if you distribute copies of such a program, whether
+gratis or for a fee, you must give the recipients all the rights that
+you have.  You must make sure that they, too, receive or can get the
+source code.  And you must show them these terms so they know their
+rights.
+
+  We protect your rights with two steps: (1) copyright the software, and
+(2) offer you this license which gives you legal permission to copy,
+distribute and/or modify the software.
+
+  Also, for each author's protection and ours, we want to make certain
+that everyone understands that there is no warranty for this free
+software.  If the software is modified by someone else and passed on, we
+want its recipients to know that what they have is not the original, so
+that any problems introduced by others will not reflect on the original
+authors' reputations.
+
+  Finally, any free program is threatened constantly by software
+patents.  We wish to avoid the danger that redistributors of a free
+program will individually obtain patent licenses, in effect making the
+program proprietary.  To prevent this, we have made it clear that any
+patent must be licensed for everyone's free use or not licensed at all.
+
+  The precise terms and conditions for copying, distribution and
+modification follow.
+
+		    GNU GENERAL PUBLIC LICENSE
+   TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
+
+  0. This License applies to any program or other work which contains
+a notice placed by the copyright holder saying it may be distributed
+under the terms of this General Public License.  The "Program", below,
+refers to any such program or work, and a "work based on the Program"
+means either the Program or any derivative work under copyright law:
+that is to say, a work containing the Program or a portion of it,
+either verbatim or with modifications and/or translated into another
+language.  (Hereinafter, translation is included without limitation in
+the term "modification".)  Each licensee is addressed as "you".
+
+Activities other than copying, distribution and modification are not
+covered by this License; they are outside its scope.  The act of
+running the Program is not restricted, and the output from the Program
+is covered only if its contents constitute a work based on the
+Program (independent of having been made by running the Program).
+Whether that is true depends on what the Program does.
+
+  1. You may copy and distribute verbatim copies of the Program's
+source code as you receive it, in any medium, provided that you
+conspicuously and appropriately publish on each copy an appropriate
+copyright notice and disclaimer of warranty; keep intact all the
+notices that refer to this License and to the absence of any warranty;
+and give any other recipients of the Program a copy of this License
+along with the Program.
+
+You may charge a fee for the physical act of transferring a copy, and
+you may at your option offer warranty protection in exchange for a fee.
+
+  2. You may modify your copy or copies of the Program or any portion
+of it, thus forming a work based on the Program, and copy and
+distribute such modifications or work under the terms of Section 1
+above, provided that you also meet all of these conditions:
+
+    a) You must cause the modified files to carry prominent notices
+    stating that you changed the files and the date of any change.
+
+    b) You must cause any work that you distribute or publish, that in
+    whole or in part contains or is derived from the Program or any
+    part thereof, to be licensed as a whole at no charge to all third
+    parties under the terms of this License.
+
+    c) If the modified program normally reads commands interactively
+    when run, you must cause it, when started running for such
+    interactive use in the most ordinary way, to print or display an
+    announcement including an appropriate copyright notice and a
+    notice that there is no warranty (or else, saying that you provide
+    a warranty) and that users may redistribute the program under
+    these conditions, and telling the user how to view a copy of this
+    License.  (Exception: if the Program itself is interactive but
+    does not normally print such an announcement, your work based on
+    the Program is not required to print an announcement.)
+
+These requirements apply to the modified work as a whole.  If
+identifiable sections of that work are not derived from the Program,
+and can be reasonably considered independent and separate works in
+themselves, then this License, and its terms, do not apply to those
+sections when you distribute them as separate works.  But when you
+distribute the same sections as part of a whole which is a work based
+on the Program, the distribution of the whole must be on the terms of
+this License, whose permissions for other licensees extend to the
+entire whole, and thus to each and every part regardless of who wrote it.
+
+Thus, it is not the intent of this section to claim rights or contest
+your rights to work written entirely by you; rather, the intent is to
+exercise the right to control the distribution of derivative or
+collective works based on the Program.
+
+In addition, mere aggregation of another work not based on the Program
+with the Program (or with a work based on the Program) on a volume of
+a storage or distribution medium does not bring the other work under
+the scope of this License.
+
+  3. You may copy and distribute the Program (or a work based on it,
+under Section 2) in object code or executable form under the terms of
+Sections 1 and 2 above provided that you also do one of the following:
+
+    a) Accompany it with the complete corresponding machine-readable
+    source code, which must be distributed under the terms of Sections
+    1 and 2 above on a medium customarily used for software interchange; or,
+
+    b) Accompany it with a written offer, valid for at least three
+    years, to give any third party, for a charge no more than your
+    cost of physically performing source distribution, a complete
+    machine-readable copy of the corresponding source code, to be
+    distributed under the terms of Sections 1 and 2 above on a medium
+    customarily used for software interchange; or,
+
+    c) Accompany it with the information you received as to the offer
+    to distribute corresponding source code.  (This alternative is
+    allowed only for noncommercial distribution and only if you
+    received the program in object code or executable form with such
+    an offer, in accord with Subsection b above.)
+
+The source code for a work means the preferred form of the work for
+making modifications to it.  For an executable work, complete source
+code means all the source code for all modules it contains, plus any
+associated interface definition files, plus the scripts used to
+control compilation and installation of the executable.  However, as a
+special exception, the source code distributed need not include
+anything that is normally distributed (in either source or binary
+form) with the major components (compiler, kernel, and so on) of the
+operating system on which the executable runs, unless that component
+itself accompanies the executable.
+
+If distribution of executable or object code is made by offering
+access to copy from a designated place, then offering equivalent
+access to copy the source code from the same place counts as
+distribution of the source code, even though third parties are not
+compelled to copy the source along with the object code.
+
+  4. You may not copy, modify, sublicense, or distribute the Program
+except as expressly provided under this License.  Any attempt
+otherwise to copy, modify, sublicense or distribute the Program is
+void, and will automatically terminate your rights under this License.
+However, parties who have received copies, or rights, from you under
+this License will not have their licenses terminated so long as such
+parties remain in full compliance.
+
+  5. You are not required to accept this License, since you have not
+signed it.  However, nothing else grants you permission to modify or
+distribute the Program or its derivative works.  These actions are
+prohibited by law if you do not accept this License.  Therefore, by
+modifying or distributing the Program (or any work based on the
+Program), you indicate your acceptance of this License to do so, and
+all its terms and conditions for copying, distributing or modifying
+the Program or works based on it.
+
+  6. Each time you redistribute the Program (or any work based on the
+Program), the recipient automatically receives a license from the
+original licensor to copy, distribute or modify the Program subject to
+these terms and conditions.  You may not impose any further
+restrictions on the recipients' exercise of the rights granted herein.
+You are not responsible for enforcing compliance by third parties to
+this License.
+
+  7. If, as a consequence of a court judgment or allegation of patent
+infringement or for any other reason (not limited to patent issues),
+conditions are imposed on you (whether by court order, agreement or
+otherwise) that contradict the conditions of this License, they do not
+excuse you from the conditions of this License.  If you cannot
+distribute so as to satisfy simultaneously your obligations under this
+License and any other pertinent obligations, then as a consequence you
+may not distribute the Program at all.  For example, if a patent
+license would not permit royalty-free redistribution of the Program by
+all those who receive copies directly or indirectly through you, then
+the only way you could satisfy both it and this License would be to
+refrain entirely from distribution of the Program.
+
+If any portion of this section is held invalid or unenforceable under
+any particular circumstance, the balance of the section is intended to
+apply and the section as a whole is intended to apply in other
+circumstances.
+
+It is not the purpose of this section to induce you to infringe any
+patents or other property right claims or to contest validity of any
+such claims; this section has the sole purpose of protecting the
+integrity of the free software distribution system, which is
+implemented by public license practices.  Many people have made
+generous contributions to the wide range of software distributed
+through that system in reliance on consistent application of that
+system; it is up to the author/donor to decide if he or she is willing
+to distribute software through any other system and a licensee cannot
+impose that choice.
+
+This section is intended to make thoroughly clear what is believed to
+be a consequence of the rest of this License.
+
+  8. If the distribution and/or use of the Program is restricted in
+certain countries either by patents or by copyrighted interfaces, the
+original copyright holder who places the Program under this License
+may add an explicit geographical distribution limitation excluding
+those countries, so that distribution is permitted only in or among
+countries not thus excluded.  In such case, this License incorporates
+the limitation as if written in the body of this License.
+
+  9. The Free Software Foundation may publish revised and/or new versions
+of the General Public License from time to time.  Such new versions will
+be similar in spirit to the present version, but may differ in detail to
+address new problems or concerns.
+
+Each version is given a distinguishing version number.  If the Program
+specifies a version number of this License which applies to it and "any
+later version", you have the option of following the terms and conditions
+either of that version or of any later version published by the Free
+Software Foundation.  If the Program does not specify a version number of
+this License, you may choose any version ever published by the Free Software
+Foundation.
+
+  10. If you wish to incorporate parts of the Program into other free
+programs whose distribution conditions are different, write to the author
+to ask for permission.  For software which is copyrighted by the Free
+Software Foundation, write to the Free Software Foundation; we sometimes
+make exceptions for this.  Our decision will be guided by the two goals
+of preserving the free status of all derivatives of our free software and
+of promoting the sharing and reuse of software generally.
+
+			    NO WARRANTY
+
+  11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY
+FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW.  EXCEPT WHEN
+OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES
+PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED
+OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.  THE ENTIRE RISK AS
+TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU.  SHOULD THE
+PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING,
+REPAIR OR CORRECTION.
+
+  12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
+WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR
+REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES,
+INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING
+OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED
+TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY
+YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER
+PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE
+POSSIBILITY OF SUCH DAMAGES.
+
+		     END OF TERMS AND CONDITIONS
+
+	    How to Apply These Terms to Your New Programs
+
+  If you develop a new program, and you want it to be of the greatest
+possible use to the public, the best way to achieve this is to make it
+free software which everyone can redistribute and change under these terms.
+
+  To do so, attach the following notices to the program.  It is safest
+to attach them to the start of each source file to most effectively
+convey the exclusion of warranty; and each file should have at least
+the "copyright" line and a pointer to where the full notice is found.
+
+    <one line to give the program's name and a brief idea of what it does.>
+    Copyright (C) <year>  <name of author>
+
+    This program is free software; you can redistribute it and/or modify
+    it under the terms of the GNU General Public License as published by
+    the Free Software Foundation; either version 2 of the License, or
+    (at your option) any later version.
+
+    This program is distributed in the hope that it will be useful,
+    but WITHOUT ANY WARRANTY; without even the implied warranty of
+    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+    GNU General Public License for more details.
+
+    You should have received a copy of the GNU General Public License
+    along with this program; if not, write to the Free Software
+    Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
+
+
+Also add information on how to contact you by electronic and paper mail.
+
+If the program is interactive, make it output a short notice like this
+when it starts in an interactive mode:
+
+    Gnomovision version 69, Copyright (C) year name of author
+    Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'.
+    This is free software, and you are welcome to redistribute it
+    under certain conditions; type `show c' for details.
+
+The hypothetical commands `show w' and `show c' should show the appropriate
+parts of the General Public License.  Of course, the commands you use may
+be called something other than `show w' and `show c'; they could even be
+mouse-clicks or menu items--whatever suits your program.
+
+You should also get your employer (if you work as a programmer) or your
+school, if any, to sign a "copyright disclaimer" for the program, if
+necessary.  Here is a sample; alter the names:
+
+  Yoyodyne, Inc., hereby disclaims all copyright interest in the program
+  `Gnomovision' (which makes passes at compilers) written by James Hacker.
+
+  <signature of Ty Coon>, 1 April 1989
+  Ty Coon, President of Vice
+
+This General Public License does not permit incorporating your program into
+proprietary programs.  If your program is a subroutine library, you may
+consider it more useful to permit linking proprietary applications with the
+library.  If this is what you want to do, use the GNU Library General
+Public License instead of this License.

references/igraph-1.0.1/ChangeLog

@@ -0,0 +1 @@
+See CHANGELOG.md for a list of changes between versions.

references/igraph-1.0.1/IGRAPH_VERSION

@@ -0,0 +1 @@
+1.0.1

references/igraph-1.0.1/INSTALL

@@ -0,0 +1,7 @@
+Instructions for installation are provided in Chapter 2 of the manual; see
+`doc/html` in the distributed tarball.
+
+An online version of the installation instructions for the most recent version
+can be found here:
+
+https://igraph.org/c/doc/igraph-Installation.html

references/igraph-1.0.1/NEWS

@@ -0,0 +1,5 @@
+News about each release of igraph from version 0.8 onwards can be found in
+CHANGELOG.md.
+
+Archived news items before version 0.7 are to be found in ONEWS -- these are
+most likely of historical interest only.

references/igraph-1.0.1/README.md

@@ -0,0 +1,30 @@
+[![Build Status on Azure Pipelines](https://dev.azure.com/igraph-team/igraph/_apis/build/status/igraph.igraph?branchName=main)](https://dev.azure.com/igraph-team/igraph/_build/latest?definitionId=1&branchName=main)
+![Build Status on Github Actions](https://github.com/igraph/igraph/workflows/MINGW/badge.svg?branch=main)
+[![codecov](https://codecov.io/gh/igraph/igraph/branch/main/graph/badge.svg?token=xGFabHJE2I)](https://codecov.io/gh/igraph/igraph)
+[![DOI](https://zenodo.org/badge/8546198.svg)](https://zenodo.org/badge/latestdoi/8546198)
+
+The igraph library
+------------------
+
+igraph is a C library for complex network analysis and graph theory, with
+emphasis on efficiency, portability and ease of use.
+
+See https://igraph.org for installation instructions and documentation.
+
+igraph can also be used from:
+
+ - R — https://github.com/igraph/rigraph
+ - Python — https://github.com/igraph/python-igraph
+ - Mathematica — https://github.com/szhorvat/IGraphM
+
+igraph is a collaborative work of many people from all around the world —
+see the [list of contributors here](./CONTRIBUTORS.md). If you would like
+to contribute yourself, [click here to see how you can
+help](./CONTRIBUTING.md).
+
+Citation
+--------
+
+If you use igraph in your research, please cite
+
+> Csardi, G., & Nepusz, T. (2006). The igraph software package for complex network research. InterJournal, Complex Systems, 1695.

references/igraph-1.0.1/SUPPORT.md

@@ -0,0 +1,13 @@
+# Need help with the igraph C library?
+
+_This repository is **only** about the C library of `igraph`. Do you use `igraph` from a different language? Then please see the repositories for the [R interface](https://github.com/igraph/rigraph/), the [Python interface](https://github.com/igraph/python-igraph/) or the [Mathematica interface](https://github.com/szhorvat/IGraphM)._
+
+Having problems with igraph?
+
+ - First, check our [documentation](https://igraph.org/c/html/latest/) for answers.
+    * Problems with installing `igraph`? Please check our [installation instructions](https://igraph.org/c/html/latest/igraph-Installation.html).
+    * Problems compiling your own code? Please check our [tutorial](https://igraph.org/c/html/latest/igraph-Tutorial.html) on writing your first `igraph` program.
+ - Do you have a question about `igraph`? Please post your question on our [support forum](https://igraph.discourse.group/).
+ - If you **found a bug**, please go ahead and [open a new issue](https://github.com/igraph/igraph/issues).
+
+ We use the [issue tracker](https://github.com/igraph/igraph/issues) for bug reports and feature requests, and the [support forum](https://igraph.discourse.group/) for questions.

references/igraph-1.0.1/VERSIONING.md

@@ -0,0 +1,58 @@
+# Versioning and stability
+
+This document is provided for informational purposes only, to help igraph users understand how igraph's programming interface is evolving, and what stability guaratees you can rely on.  It concerns the igraph C library only.  igraph's high level interfaces (R, Python, Mathematica) have their own separate versioning schemes and compatibility policies.
+
+## Versioning
+
+Starting with version 1.0, igraph follows the spirit of semantic versioning, with some differences, as described below.  The version number consists of three parts in the `MAJOR.MINOR.PATCH` format.
+
+- `MAJOR` is incremented after making _incompatible changes_ to the stable programming interface.  Major releases are intended to be infrequent, and are accompanied by release notes where we make the effort to provide detailed guidance on adapting to incompatible changes.
+- `MINOR` is incremented after making _additions_ to the stable programming interface.  Minor releases are issued regularly.
+- `PATCH` is incremented when making changes that do not affect compatibility (usually bug fixes, documentation improvements, or build systems changes).
+
+The three version parts are available at compile time as the macros `IGRAPH_VERSION_MAJOR`, `IGRAPH_VERSION_MINOR` and `IGRAPH_VERSION_PATCH`, or at runtime through the `igraph_version()` function.
+
+The majority of public, documented functions are considered to be part of the _stable programming interface_, but there are some notable exceptions:
+
+- **Experimental functions** may change at any time without notice.  These are clearly marked in their documentation ([example](https://igraph.org/c/html/0.10.13/igraph-Generators.html#igraph_chung_lu_game)).  They are also marked in igraph's header files with the `IGRAPH_EXPERIMENTAL` macro ([example](https://github.com/igraph/igraph/blob/3629c46b2784cb10fc27fc6e9fab4404a13d031c/include/igraph_cycles.h#L49-L53)).  Most newly added functions start out as _experimental_, and stay in this state until we are confident in their design, typically for one or two minor releases.  User feedback about experimental functions is particularly welcome.  We make the effort to avoid changes to experimental functions in patch releases, but do not guarantee this.
+- **Internal and undocumented functions** are not part of the stable programming interface, not even if they are present in public headers.  They may change at any time. The names of internal functions usually start with the prefix `igraph_i_` (capitalized for macros), while public functions start with `igraph_`.
+
+## Symbol lifecycle
+
+Most new symbols start out as _experimental_ in minor releases.  Eventually, their API is declared stable, and the experimental marker is removed from their declaration and documentation in an upcoming minor release.
+
+Symbols go through a deprecation phase before they are removed.  Deprecated symbols are marked in their documentation ([example](https://igraph.org/c/html/0.10.13/igraph-Structural.html#igraph_clusters)), and functions are prefixed with `IGRAPH_DEPRECATED` in the public headers ([example](https://github.com/igraph/igraph/blob/997f59ad742892fff199824a248fab382b40f526/include/igraph_components.h#L45-L47)). With GCC-compatible compilers, use the `-Wdeprecated` flag to get a warning for the use of deprecated functions, but keep in mind that deprecation warnings are not supported for all symbol types (e.g. macros) with all compilers.  The ultimate reference for deprecations is the [changelog][1].
+
+## Stability of behaviour
+
+Whether changes in function behaviour are considered breaking is somewhat subjective, and is decided on a case-by-case basis.  Expect some changes within minor releases.  For example, a function that ignored edge multiplicities may gain support for multigraphs in a new minor release.  Do not rely on details of behaviour that are not explicitly documented.
+
+A notable case is stochastic functions: we do not guarantee that the same output is returned across different releases (even patch releases) for the same random seed.  We only guarantee the same statistical properties.
+
+## Advice to users and package maintainers
+
+**Users:**
+
+For as long as you don't use _experimental_ functions, you can be confident that your code will continue to work with future releases having the same major version.  If you do use _experimental_ functions, it is your responsibility to check the [release notes][1] of each igraph release and adapt accordingly.  The use of _internal_ functions is completely unsupported: if you feel you need them, please talk to us.
+
+If you do use _experimental_ functions, make this clear in your README file for the benefit of package maintainers.
+
+While igraph comes with multiple header files, only `#include <igraph.h>` is supported. The rest of the headers exist for internal organizational purposes only, and may change without notice.
+
+**Package maintainers:**
+
+Software that does not use experimental functions from igraph can safely link to future igraph versions with the same major version.  Ask the developer of any software you are packaging if they are using experimental igraph functions.
+
+The high-level interfaces of igraph do use both experimental and internal functions. Each high-level interface release is only guaranteed to be compatible with one specific release of C/igraph. As of this writing, this is a concern only for the Python interface, as the other interfaces (R and Mathematica) cannot link dynamically to C/igraph.
+
+We provide the `IGRAPH_WARN_EXPERIMENTAL` compile-time macro to help maintainers in determining whether a piece of software uses experimental igraph functions or not. Compilers that support `__attribute__((__warning(...)))` clauses will issue a warning when `IGRAPH_WARN_EXPERIMENTAL` is defined to a non-zero value at compile-time and an experimental function is used somewhere in the code.
+
+## Notes
+
+For the purposes of this document, "API compatibility" means that the same sources can be compiled using headers from different igraph versions.  "ABI compatibility" means that a program that only uses stable API can be linked to a different version of the igraph shared library than what it was compiled with.
+
+We strive to maintain both API and ABI compatibility.
+
+However, it must be pointed out that we do not support manipulating the same in-memory igraph data structures with different igraph versions (for example, if two libraries that exchange data are each statically linked to different igraph versions).
+
+ [1]: https://github.com/igraph/igraph/blob/main/CHANGELOG.md

references/igraph-1.0.1/doc/CMakeLists.txt

@@ -0,0 +1,362 @@
+# Specify the list of .xml files that are used as-is
+set(
+  DOCBOOK_SOURCES
+  fdl.xml
+  gpl.xml
+  igraph-docs.xml
+  installation.xml
+  introduction.xml
+  licenses.xml
+  glossary.xml
+  pmt.xml
+  tutorial.xml
+)
+
+# Specify the list of .xxml files that have to be piped through doxrox to
+# obtain the final set of .xml files that serve as an input to DocBook
+set(
+  DOXROX_SOURCES
+  adjlist.xxml
+  attributes.xxml
+  basicigraph.xxml
+  bipartite.xxml
+  bitset.xxml
+  cliques.xxml
+  coloring.xxml
+  community.xxml
+  cycles.xxml
+  dqueue.xxml
+  embedding.xxml
+  error.xxml
+  flows.xxml
+  foreign.xxml
+  games.xxml
+  generators.xxml
+  graphlets.xxml
+  heap.xxml
+  hrg.xxml
+  isomorphism.xxml
+  iterators.xxml
+  layout.xxml
+  linalg.xxml
+  matrix.xxml
+  memory.xxml
+  motifs.xxml
+  nongraph.xxml
+  operators.xxml
+  progress.xxml
+  processes.xxml
+  psumtree.xxml
+  random.xxml
+  separators.xxml
+  sparsemat.xxml
+  spatial.xxml
+  stack.xxml
+  status.xxml
+  structural.xxml
+  strvector.xxml
+  threading.xxml
+  vector.xxml
+  vectorlist.xxml
+  visitors.xxml
+)
+
+# Specify the igraph source files that may contain documentation chunks
+file(
+  GLOB_RECURSE IGRAPH_SOURCES_FOR_DOXROX
+  LIST_DIRECTORIES FALSE
+  ${CMAKE_SOURCE_DIR}/include/*.h
+  ${CMAKE_BINARY_DIR}/include/*.h
+  ${CMAKE_SOURCE_DIR}/src/*.c
+  ${CMAKE_SOURCE_DIR}/src/*.cc
+  ${CMAKE_SOURCE_DIR}/src/*.cpp
+  ${CMAKE_SOURCE_DIR}/src/*.h
+  ${CMAKE_SOURCE_DIR}/src/*.pmt
+)
+
+# Specify the igraph source files that are used as examples in the
+# documentation
+file(
+  GLOB DOCBOOK_EXAMPLES
+  LIST_DIRECTORIES FALSE
+  RELATIVE ${CMAKE_SOURCE_DIR}
+  ${CMAKE_SOURCE_DIR}/examples/simple/*.c
+  ${CMAKE_SOURCE_DIR}/examples/tutorial/*.c
+)
+
+# You should not need to change anything below this line if you are simply
+# trying to add new files to produce documentation from
+
+# Documentation build requires Python and source-highlight
+find_package(Python3)
+find_program(SOURCE_HIGHLIGHT_COMMAND source-highlight)
+
+# HTML documentation additionally requires xmlto from DocBook
+find_program(XMLTO_COMMAND xmlto)
+
+# PDF documentation additionally requires xsltproc, xmllint and Apache FOP
+find_program(FOP_COMMAND fop)
+find_program(XMLLINT_COMMAND xmllint)
+find_program(XSLTPROC_COMMAND xsltproc)
+
+# GNU Texinfo documentation additionally requires the docbook2X package,
+# makeinfo (and xmllint as well). The docbook2texi command from docbook2X
+# is renamed to docbook2x-texi by many Linux distros to avoid conflict with
+# a command of the same name from the incompatible docbook-tools package.
+# We look for both command names, and prefer docbook2x-texi if found.
+# At the moment we do not validate that docbook2texi is from docbook2X
+# instead of docbook-tools. Such validation will be possible with CMake >= 3.25.
+find_program(DOCBOOK2XTEXI_COMMAND NAMES docbook2x-texi docbook2texi)
+find_program(MAKEINFO_COMMAND makeinfo)
+
+if(Python3_FOUND AND SOURCE_HIGHLIGHT_COMMAND)
+  set(DOC_BUILD_SUPPORTED TRUE)
+else()
+  set(DOC_BUILD_SUPPORTED FALSE)
+endif()
+
+if(DOC_BUILD_SUPPORTED AND XMLTO_COMMAND)
+  set(HTML_DOC_BUILD_SUPPORTED TRUE)
+else()
+  set(HTML_DOC_BUILD_SUPPORTED FALSE)
+endif()
+
+if(DOC_BUILD_SUPPORTED AND XMLLINT_COMMAND AND XSLTPROC_COMMAND AND FOP_COMMAND)
+  set(PDF_DOC_BUILD_SUPPORTED TRUE)
+else()
+  set(PDF_DOC_BUILD_SUPPORTED FALSE)
+endif()
+
+if(DOC_BUILD_SUPPORTED AND XMLLINT_COMMAND AND DOCBOOK2XTEXI_COMMAND AND MAKEINFO_COMMAND)
+  set(INFO_DOC_BUILD_SUPPORTED TRUE)
+else()
+  set(INFO_DOC_BUILD_SUPPORTED FALSE)
+endif()
+
+if(DOC_BUILD_SUPPORTED)
+  set(DOXROX_COMMAND ${Python3_EXECUTABLE} ${CMAKE_CURRENT_SOURCE_DIR}/doxrox.py)
+  set(DOXROX_RULES ${CMAKE_CURRENT_SOURCE_DIR}/c-docbook.re)
+  set(DOXROX_CHUNKS ${CMAKE_CURRENT_BINARY_DIR}/chunks.pickle)
+  set(DOXROX_CACHE ${CMAKE_CURRENT_BINARY_DIR}/doxrox.cache)
+
+  set(DOCBOOK_INPUTS "")
+  set(DOCBOOK_GENERATED_INPUTS "")
+
+  # Specify that each DocBook .xml file is to be copied to the build folder
+  # TODO(ntamas): currently this works with out-of-tree builds only
+  set(IGRAPH_VERSION ${PACKAGE_VERSION})   # for replacement in igraph-docs.xml
+  foreach(DOCBOOK_SOURCE ${DOCBOOK_SOURCES})
+    set(DOCBOOK_INPUT "${CMAKE_CURRENT_BINARY_DIR}/${DOCBOOK_SOURCE}")
+    list(APPEND DOCBOOK_INPUTS "${DOCBOOK_INPUT}")
+    configure_file(${DOCBOOK_SOURCE} ${DOCBOOK_INPUT})
+  endforeach()
+
+  # Specify that .xxml files should be piped through doxrox.py to get a
+  # DocBook-compatible .xml file. This step inserts the documentation chunks
+  # extracted from the igraph source to the DocBook sources
+  foreach(DOXROX_SOURCE ${DOXROX_SOURCES})
+    string(REGEX REPLACE "[.]xxml$" ".xml" DOXROX_OUTPUT ${DOXROX_SOURCE})
+    set(COMMENT "Generating ${DOXROX_OUTPUT} from ${DOXROX_SOURCE}")
+
+    string(PREPEND DOXROX_OUTPUT "${CMAKE_CURRENT_BINARY_DIR}/")
+    list(APPEND DOCBOOK_INPUTS "${DOXROX_OUTPUT}")
+    list(APPEND DOCBOOK_GENERATED_INPUTS "${DOXROX_OUTPUT}")
+
+    add_custom_command(
+      OUTPUT ${DOXROX_OUTPUT}
+      COMMAND ${DOXROX_COMMAND}
+      ARGS
+      -t ${CMAKE_CURRENT_SOURCE_DIR}/${DOXROX_SOURCE}
+      --chunks ${DOXROX_CHUNKS}
+      -o ${DOXROX_OUTPUT}
+      MAIN_DEPENDENCY ${CMAKE_CURRENT_SOURCE_DIR}/${DOXROX_SOURCE}
+      DEPENDS ${DOXROX_CHUNKS}
+      COMMENT ${COMMENT}
+    )
+  endforeach()
+
+  # When all .xxml and .xml files have been processed, we have to send them
+  # through a custom Python script that extracts the ID references and produces
+  # a ctags-compatible "tags" file. This will then be used later by
+  # source-highlight to cross-reference the known tokens from the source code
+  # of the examples
+  list(JOIN DOCBOOK_GENERATED_INPUTS ";" DOCBOOK_GENERATED_INPUTS_AS_STRING)
+  add_custom_command(
+    OUTPUT "${CMAKE_CURRENT_BINARY_DIR}/tags"
+    COMMAND ${CMAKE_COMMAND}
+    ARGS
+    -DINPUT_FILES="${DOCBOOK_GENERATED_INPUTS_AS_STRING}"
+    -DOUTPUT_FILE=${CMAKE_CURRENT_BINARY_DIR}/tags
+    -P ${CMAKE_SOURCE_DIR}/etc/cmake/generate_tags_file.cmake
+    DEPENDS ${DOCBOOK_GENERATED_INPUTS}
+    COMMENT "Creating tags file from DocBook xmls"
+  )
+
+  # Specify that each example source file is to be piped through source-higlight
+  # to produce an .xml representation that can be used in the DocBook
+  # documentation
+  foreach(DOCBOOK_EXAMPLE_SOURCE ${DOCBOOK_EXAMPLES})
+    string(REGEX REPLACE "[.]c$" ".c.xml" DOCBOOK_EXAMPLE_OUTPUT ${DOCBOOK_EXAMPLE_SOURCE})
+    set(COMMENT "Highlighting source code in ${DOCBOOK_EXAMPLE_SOURCE}")
+
+    set(DOCBOOK_EXAMPLE_OUTPUT "${CMAKE_BINARY_DIR}/${DOCBOOK_EXAMPLE_SOURCE}.xml")
+    list(APPEND DOCBOOK_INPUTS "${DOCBOOK_EXAMPLE_OUTPUT}")
+
+    get_filename_component(DOCBOOK_EXAMPLE_OUTPUT_DIR "${DOCBOOK_EXAMPLE_OUTPUT}" DIRECTORY)
+
+    add_custom_command(
+      OUTPUT ${DOCBOOK_EXAMPLE_OUTPUT}
+      COMMAND ${CMAKE_COMMAND} -E make_directory ${DOCBOOK_EXAMPLE_OUTPUT_DIR}
+      COMMAND ${Python3_EXECUTABLE}
+      ARGS
+      ${CMAKE_SOURCE_DIR}/tools/strip_licenses_from_examples.py
+      ${CMAKE_SOURCE_DIR}/${DOCBOOK_EXAMPLE_SOURCE}
+      ${CMAKE_BINARY_DIR}/${DOCBOOK_EXAMPLE_SOURCE}
+      COMMAND ${SOURCE_HIGHLIGHT_COMMAND}
+      ARGS
+      --src-lang c
+      --out-format docbook
+      --input ${CMAKE_BINARY_DIR}/${DOCBOOK_EXAMPLE_SOURCE}
+      --output ${DOCBOOK_EXAMPLE_OUTPUT}
+      --gen-references inline
+      --ctags=""
+      --outlang-def ${CMAKE_SOURCE_DIR}/doc/docbook.outlang
+      MAIN_DEPENDENCY ${CMAKE_SOURCE_DIR}/${DOCBOOK_EXAMPLE_SOURCE}
+      DEPENDS tags
+      COMMENT ${COMMENT}
+    )
+  endforeach()
+
+  add_custom_command(
+    OUTPUT ${DOXROX_CHUNKS} ${DOXROX_CACHE}
+    COMMAND ${DOXROX_COMMAND}
+    ARGS
+    -e ${DOXROX_RULES}
+    -o ${DOXROX_CHUNKS}
+    --cache ${DOXROX_CACHE}
+    ${IGRAPH_SOURCES_FOR_DOXROX}
+    MAIN_DEPENDENCY ${DOXROX_RULES}
+    DEPENDS ${IGRAPH_SOURCES_FOR_DOXROX}
+    COMMENT "Parsing documentation chunks from source code"
+  )
+
+  set(DOCXML_STAMP ${CMAKE_CURRENT_BINARY_DIR}/xmlstamp)
+  add_custom_command(
+    OUTPUT ${DOCXML_STAMP}
+    COMMAND ${CMAKE_COMMAND} -E touch ${DOCXML_STAMP}
+    MAIN_DEPENDENCY igraph-docs.xml
+    DEPENDS ${DOCBOOK_INPUTS}
+  )
+  add_custom_target(docxml DEPENDS ${DOCXML_STAMP})
+
+  if(HTML_DOC_BUILD_SUPPORTED)
+    set(HTML_STAMP ${CMAKE_CURRENT_BINARY_DIR}/html/stamp)
+
+    add_custom_command(
+      OUTPUT ${HTML_STAMP}
+      COMMAND ${XMLTO_COMMAND} -x ${CMAKE_CURRENT_SOURCE_DIR}/gtk-doc.xsl -o html xhtml igraph-docs.xml
+      COMMAND ${CMAKE_COMMAND} -E copy ${CMAKE_CURRENT_SOURCE_DIR}/html/*.css ${CMAKE_CURRENT_BINARY_DIR}/html
+      COMMAND ${CMAKE_COMMAND} -E copy ${CMAKE_CURRENT_SOURCE_DIR}/html/*.js ${CMAKE_CURRENT_BINARY_DIR}/html
+      COMMAND ${CMAKE_COMMAND} -E copy ${CMAKE_CURRENT_SOURCE_DIR}/html/*.png ${CMAKE_CURRENT_BINARY_DIR}/html
+      COMMAND ${CMAKE_COMMAND} -E touch ${HTML_STAMP}
+      MAIN_DEPENDENCY igraph-docs.xml
+      # The DEPENDS clause below needs to list both the xmlstamp file and the
+      # target that creates it. The former is needed to make Ninja rebuild the
+      # HTML files if the source is modified. The latter is needed to make the
+      # XCode build system happy.
+      DEPENDS ${DOCXML_STAMP} docxml
+      COMMENT "Generating HTML documentation with xmlto"
+    )
+
+    add_custom_target(html DEPENDS ${HTML_STAMP})
+    set(HTML_TARGET html)
+  endif()
+
+  add_custom_command(
+    OUTPUT igraph-docs-with-resolved-includes.xml
+    COMMAND ${XMLLINT_COMMAND}
+    ARGS
+    --xinclude
+    --output igraph-docs-with-resolved-includes-tmp.xml
+    igraph-docs.xml
+    COMMAND ${Python3_EXECUTABLE}
+    ARGS
+    ${CMAKE_SOURCE_DIR}/tools/removeexamples.py
+    igraph-docs-with-resolved-includes-tmp.xml
+    igraph-docs-with-resolved-includes.xml
+    COMMAND ${CMAKE_COMMAND}
+    ARGS
+    -E remove igraph-docs-with-resolved-includes-tmp.xml
+    MAIN_DEPENDENCY igraph-docs.xml
+    # The DEPENDS clause below needs to list both the xmlstamp file and the
+    # target that creates it. The former is needed to make Ninja rebuild the
+    # PDF file if the source is modified. The latter is needed to make the
+    # XCode build system happy.
+    DEPENDS ${DOCXML_STAMP} docxml
+  )
+
+  # Intermediate custom target because Xcode projects cannot have commands that
+  # depend on intermediate files from other commands
+  add_custom_target(
+    _generate-resolved-docbook-xml DEPENDS igraph-docs-with-resolved-includes.xml
+    COMMENT "Resolving includes in DocBook XML source"
+  )
+
+  if(PDF_DOC_BUILD_SUPPORTED)
+    add_custom_command(
+      OUTPUT igraph-docs.fo
+      COMMAND ${XSLTPROC_COMMAND}
+      ARGS
+      --output igraph-docs.fo
+      --stringparam paper.type A4
+      http://docbook.sourceforge.net/release/xsl/current/fo/docbook.xsl
+      igraph-docs-with-resolved-includes.xml
+      DEPENDS _generate-resolved-docbook-xml
+      COMMENT "Converting DocBook XML to Apache FOP format"
+    )
+
+    add_custom_command(
+      OUTPUT igraph-docs.pdf
+      COMMAND ${FOP_COMMAND}
+      ARGS -fo igraph-docs.fo -pdf igraph-docs.pdf
+      MAIN_DEPENDENCY igraph-docs.fo
+      COMMENT "Generating PDF documentation with Apache FOP"
+    )
+
+    add_custom_target(pdf DEPENDS igraph-docs.pdf)
+    set(PDF_TARGET pdf)
+  endif()
+
+  if(INFO_DOC_BUILD_SUPPORTED)
+    add_custom_command(
+      OUTPUT igraph-docs.texi
+      COMMAND ${DOCBOOK2XTEXI_COMMAND}
+      ARGS
+      --encoding=utf-8//TRANSLIT
+      --string-param output-file=igraph-docs
+      --string-param directory-category=Libraries
+      --string-param directory-description='A fast graph library \(C\)'
+      igraph-docs-with-resolved-includes.xml
+      DEPENDS _generate-resolved-docbook-xml
+      COMMENT "Converting DocBook XML to GNU Texinfo format"
+    )
+
+    add_custom_command(
+      OUTPUT igraph-docs.info
+      COMMAND ${MAKEINFO_COMMAND}
+      ARGS --no-split igraph-docs.texi
+      MAIN_DEPENDENCY igraph-docs.texi
+      COMMENT "Generating info documentation with GNU Makeinfo"
+    )
+
+    add_custom_target(info DEPENDS igraph-docs.info)
+    set(INFO_TARGET info)
+  endif()
+
+
+  add_custom_target(doc DEPENDS ${HTML_TARGET} ${PDF_TARGET} ${INFO_TARGET})
+endif()
+
+set(HTML_DOC_BUILD_SUPPORTED ${HTML_DOC_BUILD_SUPPORTED} PARENT_SCOPE)
+set(PDF_DOC_BUILD_SUPPORTED ${PDF_DOC_BUILD_SUPPORTED} PARENT_SCOPE)
+set(INFO_DOC_BUILD_SUPPORTED ${INFO_DOC_BUILD_SUPPORTED} PARENT_SCOPE)

references/igraph-1.0.1/doc/adjlist.xxml

@@ -0,0 +1,51 @@
+<?xml version="1.0"?>
+<!DOCTYPE section PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN"
+               "http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd" [
+<!ENTITY igraph "igraph">
+]>
+
+<section id="igraph-Adjlists">
+<title>Adjacency lists</title>
+
+<!-- doxrox-include about_adjlists -->
+
+<section id="adjacent-vertices"><title>Adjacent vertices</title>
+<!-- doxrox-include igraph_adjlist_init -->
+<!-- doxrox-include igraph_adjlist_init_empty -->
+<!-- doxrox-include igraph_adjlist_init_complementer -->
+<!-- doxrox-include igraph_adjlist_init_from_inclist -->
+<!-- doxrox-include igraph_adjlist_destroy -->
+<!-- doxrox-include igraph_adjlist_get -->
+<!-- doxrox-include igraph_adjlist_size -->
+<!-- doxrox-include igraph_adjlist_clear -->
+<!-- doxrox-include igraph_adjlist_sort -->
+<!-- doxrox-include igraph_adjlist_simplify -->
+</section>
+
+<section id="incident-edges"><title>Incident edges</title>
+<!-- doxrox-include igraph_inclist_init -->
+<!-- doxrox-include igraph_inclist_destroy -->
+<!-- doxrox-include igraph_inclist_get -->
+<!-- doxrox-include igraph_inclist_size -->
+<!-- doxrox-include igraph_inclist_clear -->
+</section>
+
+<section id="lazy-adjacency-list"><title>Lazy adjacency list for vertices</title>
+<!-- doxrox-include igraph_lazy_adjlist_init -->
+<!-- doxrox-include igraph_lazy_adjlist_destroy -->
+<!-- doxrox-include igraph_lazy_adjlist_get -->
+<!-- doxrox-include igraph_lazy_adjlist_has -->
+<!-- doxrox-include igraph_lazy_adjlist_size -->
+<!-- doxrox-include igraph_lazy_adjlist_clear -->
+</section>
+
+<section id="lazy-incidence-list"><title>Lazy incidence list for edges</title>
+<!-- doxrox-include igraph_lazy_inclist_init -->
+<!-- doxrox-include igraph_lazy_inclist_destroy -->
+<!-- doxrox-include igraph_lazy_inclist_get -->
+<!-- doxrox-include igraph_lazy_inclist_has -->
+<!-- doxrox-include igraph_lazy_inclist_size -->
+<!-- doxrox-include igraph_lazy_inclist_clear -->
+</section>
+
+</section>

references/igraph-1.0.1/doc/attributes.xxml

@@ -0,0 +1,143 @@
+<?xml version="1.0"?>
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN"
+               "http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd" [
+<!ENTITY igraph "igraph">
+]>
+
+<chapter id="igraph-Attributes">
+<title>Graph, vertex and edge attributes</title>
+
+<!-- doxrox-include about_attributes -->
+
+<section id="attribute-handler-interface">
+<title>The attribute handler interface</title>
+<!-- doxrox-include about_attribute_table -->
+<!-- doxrox-include igraph_attribute_table_t -->
+<!-- doxrox-include igraph_set_attribute_table -->
+<!-- doxrox-include igraph_attribute_type_t -->
+<!-- doxrox-include igraph_attribute_elemtype_t -->
+</section>
+
+<section id="attribute-records">
+<title>Attribute records</title>
+<!-- doxrox-include about_attribute_record -->
+<!-- doxrox-include igraph_attribute_record_t -->
+<!-- doxrox-include igraph_attribute_record_init -->
+<!-- doxrox-include igraph_attribute_record_init_copy -->
+<!-- doxrox-include igraph_attribute_record_size -->
+<!-- doxrox-include igraph_attribute_record_resize -->
+<!-- doxrox-include igraph_attribute_record_set_name -->
+<!-- doxrox-include igraph_attribute_record_set_type -->
+<!-- doxrox-include igraph_attribute_record_set_default_numeric -->
+<!-- doxrox-include igraph_attribute_record_set_default_string -->
+<!-- doxrox-include igraph_attribute_record_set_default_boolean -->
+<!-- doxrox-include igraph_attribute_record_destroy -->
+</section>
+
+<section id="attribute-combinations">
+<title>Handling attribute combination lists</title>
+<!-- doxrox-include about_attribute_combination -->
+<!-- doxrox-include igraph_attribute_combination_init -->
+<!-- doxrox-include igraph_attribute_combination_add -->
+<!-- doxrox-include igraph_attribute_combination_remove -->
+<!-- doxrox-include igraph_attribute_combination_destroy -->
+<!-- doxrox-include igraph_attribute_combination_type_t -->
+<!-- doxrox-include igraph_attribute_combination -->
+</section>
+
+<section id="accessing-attributes-from-c">
+<title>Accessing attributes from C</title>
+<!-- doxrox-include cattributes -->
+
+<section id="query-attributes"><title>Query attributes</title>
+<!-- doxrox-include igraph_cattribute_list -->
+<!-- doxrox-include igraph_cattribute_has_attr -->
+<!-- doxrox-include igraph_cattribute_GAN -->
+<!-- doxrox-include GAN -->
+<!-- doxrox-include igraph_cattribute_GAB -->
+<!-- doxrox-include GAB -->
+<!-- doxrox-include igraph_cattribute_GAS -->
+<!-- doxrox-include GAS -->
+<!-- doxrox-include igraph_cattribute_VAN -->
+<!-- doxrox-include VAN -->
+<!-- doxrox-include igraph_cattribute_VANV -->
+<!-- doxrox-include VANV -->
+<!-- doxrox-include igraph_cattribute_VAB -->
+<!-- doxrox-include VAB -->
+<!-- doxrox-include igraph_cattribute_VABV -->
+<!-- doxrox-include VABV -->
+<!-- doxrox-include igraph_cattribute_VAS -->
+<!-- doxrox-include VAS -->
+<!-- doxrox-include igraph_cattribute_VASV -->
+<!-- doxrox-include VASV -->
+<!-- doxrox-include igraph_cattribute_EAN -->
+<!-- doxrox-include EAN -->
+<!-- doxrox-include igraph_cattribute_EANV -->
+<!-- doxrox-include EANV -->
+<!-- doxrox-include igraph_cattribute_EAB -->
+<!-- doxrox-include EAB -->
+<!-- doxrox-include igraph_cattribute_EABV -->
+<!-- doxrox-include EABV -->
+<!-- doxrox-include igraph_cattribute_EAS -->
+<!-- doxrox-include EAS -->
+<!-- doxrox-include igraph_cattribute_EASV -->
+<!-- doxrox-include EASV -->
+</section>
+
+<section id="set-attributes">
+<title>Set attributes</title>
+<!-- doxrox-include igraph_cattribute_GAN_set -->
+<!-- doxrox-include SETGAN -->
+<!-- doxrox-include igraph_cattribute_GAB_set -->
+<!-- doxrox-include SETGAB -->
+<!-- doxrox-include igraph_cattribute_GAS_set -->
+<!-- doxrox-include SETGAS -->
+<!-- doxrox-include igraph_cattribute_VAN_set -->
+<!-- doxrox-include SETVAN -->
+<!-- doxrox-include igraph_cattribute_VAB_set -->
+<!-- doxrox-include SETVAB -->
+<!-- doxrox-include igraph_cattribute_VAS_set -->
+<!-- doxrox-include SETVAS -->
+<!-- doxrox-include igraph_cattribute_EAN_set -->
+<!-- doxrox-include SETEAN -->
+<!-- doxrox-include igraph_cattribute_EAB_set -->
+<!-- doxrox-include SETEAB -->
+<!-- doxrox-include igraph_cattribute_EAS_set -->
+<!-- doxrox-include SETEAS -->
+<!-- doxrox-include igraph_cattribute_VAN_setv -->
+<!-- doxrox-include SETVANV -->
+<!-- doxrox-include igraph_cattribute_VAB_setv -->
+<!-- doxrox-include SETVABV -->
+<!-- doxrox-include igraph_cattribute_VAS_setv -->
+<!-- doxrox-include SETVASV -->
+<!-- doxrox-include igraph_cattribute_EAN_setv -->
+<!-- doxrox-include SETEANV -->
+<!-- doxrox-include igraph_cattribute_EAB_setv -->
+<!-- doxrox-include SETEABV -->
+<!-- doxrox-include igraph_cattribute_EAS_setv -->
+<!-- doxrox-include SETEASV -->
+</section>
+
+<section id="remove-attributes"><title>Remove attributes</title>
+<!-- doxrox-include igraph_cattribute_remove_g -->
+<!-- doxrox-include DELGA -->
+<!-- doxrox-include igraph_cattribute_remove_v -->
+<!-- doxrox-include DELVA -->
+<!-- doxrox-include igraph_cattribute_remove_e -->
+<!-- doxrox-include DELEA -->
+<!-- doxrox-include igraph_cattribute_remove_all -->
+<!-- doxrox-include DELGAS -->
+<!-- doxrox-include DELVAS -->
+<!-- doxrox-include DELEAS -->
+<!-- doxrox-include DELALL -->
+</section>
+
+<section id="c-attribute-combination-functions"><title>Custom attribute combination functions</title>
+
+<!-- doxrox-include c_attribute_combination_functions -->
+
+</section>
+
+</section>
+
+</chapter>

references/igraph-1.0.1/doc/basicigraph.xxml

@@ -0,0 +1,241 @@
+<?xml version="1.0"?>
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN"
+               "http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd" [
+<!ENTITY igraph "igraph">
+]>
+
+<chapter id="igraph-Basic">
+<title>Basic data types and interface</title>
+
+<section id="igraph-data-model"><title>The &igraph; data model</title>
+<para>
+The &igraph; library can handle directed and
+undirected graphs. The &igraph; graphs are multisets
+of ordered (if directed) or unordered (if undirected) labeled pairs.
+The labels of the pairs plus the number of vertices always starts with
+zero and ends with the number of edges minus one. In addition to that,
+a table of metadata is also attached to every graph, its most
+important entries being the number of vertices in the graph and whether
+the graph is directed or undirected.
+</para>
+
+<para>
+Like the edges, the &igraph; vertices are also
+labeled by numbers between zero and the number of vertices minus one.
+So, to summarize, a directed graph can be imagined like this:
+<informalexample>
+<programlisting>
+  ( vertices: 6,
+    directed: yes,
+    {
+     (0,2),
+     (2,2),
+     (3,2),
+     (3,3),
+     (3,4),
+     (3,4),
+     (4,3),
+     (4,1)
+    }
+  )
+</programlisting>
+</informalexample>
+Here the edges are ordered pairs or vertex ids, and the graph is a multiset
+of edges plus some metadata.
+</para>
+
+<para>
+An undirected graph is like this:
+<informalexample>
+<programlisting>
+  ( vertices: 6,
+    directed: no,
+    {
+     (0,2),
+     (2,2),
+     (2,3),
+     (3,3),
+     (3,4),
+     (3,4),
+     (3,4),
+     (1,4)
+    }
+  )
+</programlisting>
+</informalexample>
+Here, an edge is an unordered pair of two vertex IDs. A graph is a multiset
+of edges plus metadata, just like in the directed case.
+</para>
+
+<para>It is possible to convert between directed and undirected graphs,
+see the <link linkend="igraph_to_directed">
+<function>igraph_to_directed()</function></link>
+and <link linkend="igraph_to_undirected">
+<function>igraph_to_undirected()</function></link> functions.
+</para>
+
+<para>&igraph; aims to robustly support multigraphs, i.e. graphs which
+have more than one edge between some pairs of vertices, as well as
+graphs with self-loops. Most functions which do not support such graphs
+will check their input and issue an error if it is not valid. Those
+rare functions which do not perform this check clearly indicate this
+in their documentation. To eliminate multiple edges from a graph, you can use
+<link linkend="igraph_simplify">
+  <function>igraph_simplify()</function></link>.
+</para>
+</section>
+
+<section id="igraph-functions"><title>General conventions of &igraph; functions</title>
+<para>
+&igraph; has a simple and consistent interface. Most functions check
+their input for validity and display an informative error message
+when something goes wrong. In order to support this, the majority of functions
+return an error code. In basic usage, this code can be ignored, as the
+default behaviour is to abort the program immediately upon error. See
+<link linkend="igraph-Error">the section on error handling</link> for
+more information on this topic.
+</para>
+
+<para>
+Results are typically returned through <emphasis>output arguments</emphasis>,
+i.e. pointers to a data structure into which the result will be written.
+In almost all cases, this data structure is expected to be pre-initialized.
+A few simple functions communicate their result directly through their return
+value—these functions can never encounter an error.
+</para>
+</section>
+
+<section id="basic-data-types"><title>Atomic data types</title>
+
+<indexterm><primary>igraph_int_t</primary></indexterm>
+
+<para>
+&igraph; introduces a few aliases to standard C data types that are then used
+throughout the library. The most important of these types is
+<type>igraph_int_t</type>, which is an alias to either a 32-bit or a 64-bit
+<emphasis>signed</emphasis> integer, depending on whether &igraph; was compiled
+in 32-bit or 64-bit mode. The size of <type>igraph_int_t</type> also
+influences the maximum number of vertices that an &igraph; graph can represent
+as the number of vertices is stored in a variable of type
+<type>igraph_int_t</type>.
+</para>
+
+<para>
+Before igraph 1.0, <type>igraph_int_t</type> was called <type>igraph_integer_t</type>.
+This is still available as an alias to <type>igraph_int_t</type> and will remain
+accessible until at least version 2.0 of the library.
+</para>
+
+<para>Since the size of a variable of type <type>igraph_int_t</type> may
+change depending on how &igraph; is compiled, you cannot simply use
+<code>%d</code> or <code>%ld</code> as a placeholder for &igraph; integers in
+<code>printf</code> format strings. &igraph; provides the
+<code>IGRAPH_PRId</code> macro, which maps to <code>d</code>, <code>ld</code>
+or <code>lld</code> depending on the size of <type>igraph_int_t</type>, and
+you must use this macro in <code>printf</code> format strings to avoid compiler
+warnings.
+</para>
+
+<indexterm><primary>igraph_uint_t</primary></indexterm>
+
+<para>Similarly to how <type>igraph_int_t</type> maps to the standard size
+signed integer in the library, <type>igraph_uint_t</type> maps to a 32-bit or
+a 64-bit <emphasis>unsigned</emphasis> integer. It is guaranteed that the size of
+<type>igraph_int_t</type> is the same as the size of <type>igraph_uint_t</type>.
+&igraph; provides <code>IGRAPH_PRIu</code> as a format string placeholder for
+variables of type <type>igraph_uint_t</type>.
+</para>
+
+<indexterm><primary>igraph_real_t</primary></indexterm>
+
+<para>Real numbers (i.e. quantities that can potentially be fractional or
+infinite) are represented with a type named <type>igraph_real_t</type>. Currently
+<type>igraph_real_t</type> is always aliased to <type>double</type>, but it is
+still good practice to use <type>igraph_real_t</type> in your own code for sake
+of consistency.</para>
+
+<indexterm><primary>igraph_bool_t</primary></indexterm>
+
+<para>Boolean values are represented with a type named <type>igraph_bool_t</type>.
+It tries to be as small as possible since it only needs to represent a truth
+value. For printing purposes, you can treat it as an integer and use
+<code>%d</code> in format strings as a placeholder for an <type>igraph_bool_t</type>.
+</para>
+
+<indexterm><primary>IGRAPH_INTEGER_MAX</primary></indexterm>
+<indexterm><primary>IGRAPH_INTEGER_MIN</primary></indexterm>
+<indexterm><primary>IGRAPH_UINT_MAX</primary></indexterm>
+<indexterm><primary>IGRAPH_UINT_MIN</primary></indexterm>
+<para>
+Upper and lower limits of <type>igraph_int_t</type> and
+<type>igraph_uint_t</type> are provided by the constants named
+<constant>IGRAPH_INTEGER_MIN</constant>, <constant>IGRAPH_INTEGER_MAX</constant>,
+<constant>IGRAPH_UINT_MIN</constant> and <constant>IGRAPH_UINT_MAX</constant>.
+</para>
+
+</section>
+
+<section><title>Setup and initialization</title>
+<para>
+Certain parts of &igraph; must be initialized before first use, which can be
+accomplished using the setup functions below. As of igraph 1.0, most functions
+will work correctly even if setup is not performed, as currently the only setup
+action is seeding the random number generator. That said, it is strongly
+recommended to call
+<link linkend="igraph_setup"><function>igraph_setup()</function></link>
+before using any other function, as future &igraph; versions may add critical
+initialization steps.
+</para>
+
+<!-- doxrox-include igraph_setup -->
+</section>
+
+<section id="basic-interface"><title>The basic interface</title>
+<!-- doxrox-include about_basic_interface -->
+
+<section id="graph-constructors-and-destructors"><title>Graph constructors and destructors</title>
+<!-- doxrox-include igraph_empty -->
+<!-- doxrox-include igraph_empty_attrs -->
+<!-- doxrox-include igraph_copy -->
+<!-- doxrox-include igraph_destroy -->
+</section>
+
+<section id="basic-query-operations"><title>Basic query operations</title>
+<!-- doxrox-include igraph_vcount -->
+<!-- doxrox-include igraph_ecount -->
+<!-- doxrox-include igraph_is_directed -->
+<!-- doxrox-include igraph_edge -->
+<!-- doxrox-include igraph_edges -->
+<!-- doxrox-include IGRAPH_FROM -->
+<!-- doxrox-include IGRAPH_TO -->
+<!-- doxrox-include IGRAPH_OTHER -->
+<!-- doxrox-include igraph_get_eid -->
+<!-- doxrox-include igraph_get_eids -->
+<!-- doxrox-include igraph_get_all_eids_between -->
+<!-- doxrox-include igraph_neighbors -->
+<!-- doxrox-include igraph_incident -->
+<!-- doxrox-include igraph_degree -->
+<!-- doxrox-include igraph_degree_1 -->
+</section>
+
+<section id="adding-and-deleting-vertices-and-edges"><title>Adding and deleting vertices and edges</title>
+<!-- doxrox-include igraph_add_edge -->
+<!-- doxrox-include igraph_add_edges -->
+<!-- doxrox-include igraph_add_vertices -->
+<!-- doxrox-include igraph_delete_edges -->
+<!-- doxrox-include igraph_delete_vertices -->
+<!-- doxrox-include igraph_delete_vertices_map -->
+</section>
+
+</section>
+
+<section id="misc-helper-functions"><title>Miscellaneous macros and helper functions</title>
+<!-- doxrox-include IGRAPH_VCOUNT_MAX -->
+<!-- doxrox-include IGRAPH_ECOUNT_MAX -->
+<!-- doxrox-include IGRAPH_UNLIMITED -->
+<!-- doxrox-include igraph_expand_path_to_pairs -->
+<!-- doxrox-include igraph_invalidate_cache -->
+<!-- doxrox-include igraph_is_same_graph -->
+</section>
+
+</chapter>

references/igraph-1.0.1/doc/bibdatabase.xml

@@ -0,0 +1,51 @@
+<?xml version="1.0"?>
+<!DOCTYPE bibliography PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN"
+               "http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd" [
+]>
+
+<bibliography>
+
+  <biblioentry id="bib:barabasi99a">
+    <authorgroup>
+      <author><firstname>Albert-László</firstname>
+      <surname>Barabási</surname></author>
+      <author><firstname>Réka</firstname><surname>Albert</surname></author>
+    </authorgroup>
+    <subtitle>Emergence of scaling in random networks</subtitle>
+    <title>Science</title>
+    <pubdate>1999</pubdate>
+    <volumenum>286</volumenum>
+    <pagenums>509-512</pagenums>
+  </biblioentry>
+
+  <biblioentry id="bib:zalanyi03">
+    <authorgroup>
+      <author><firstname>László</firstname><surname>Zalányi</surname></author>
+      <author><firstname>Gábor</firstname><surname>Csárdi</surname></author>
+      <author><firstname>Tamás</firstname><surname>Kiss</surname></author>
+      <author><firstname>Máté</firstname><surname>Lengyel</surname></author>
+      <author><firstname>Rebecca</firstname><surname>Warner</surname></author>
+      <author><firstname>Jan</firstname><surname>Tobochnik</surname></author>
+      <author><firstname>Péter</firstname><surname>Érdi</surname></author>
+    </authorgroup>
+    <subtitle>Properties of a random attachment growing network</subtitle>
+    <title>Phyisical Review E</title>
+    <pubdate>2003</pubdate>
+    <volumenum>68</volumenum>
+    <pagenums>066104</pagenums>
+  </biblioentry>
+
+  <biblioentry id="bib:ford56">
+    <authorgroup>
+      <author><firstname>L. R.</firstname><surname>Ford Jr.</surname></author>
+      <author><firstname>D. R.</firstname><surname>Fulkerson</surname></author>
+    </authorgroup>
+    <subtitle>Maximal ow through a network</subtitle>
+    <title>Canadian J. Math.</title>
+    <pubdate>1956</pubdate>
+    <volumenum>8</volumenum>
+    <pagenums>399--404</pagenums>
+  </biblioentry>
+
+
+</bibliography>

references/igraph-1.0.1/doc/bipartite.xxml

@@ -0,0 +1,37 @@
+<?xml version="1.0"?>
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN"
+               "http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd" [
+<!ENTITY igraph "igraph">
+]>
+
+<chapter id="igraph-Bipartite">
+<title>Bipartite, i.e. two-mode graphs</title>
+
+<section id="about-bipartite">
+<!-- doxrox-include about_bipartite -->
+</section>
+
+<section id="create-two-mode-networks"><title>Create two-mode networks</title>
+<!-- doxrox-include igraph_create_bipartite -->
+<!-- doxrox-include igraph_full_bipartite -->
+<!-- doxrox-include igraph_bipartite_game_gnm -->
+<!-- doxrox-include igraph_bipartite_game_gnp -->
+<!-- doxrox-include igraph_bipartite_iea_game -->
+</section>
+
+<section id="bipartite-adjacency-matrices"><title>Bipartite adjacency matrices</title>
+<!-- doxrox-include igraph_biadjacency -->
+<!-- doxrox-include igraph_weighted_biadjacency -->
+<!-- doxrox-include igraph_get_biadjacency -->
+</section>
+
+<section id="project-two-mode-graphs"><title>Project two-mode graphs</title>
+<!-- doxrox-include igraph_bipartite_projection_size -->
+<!-- doxrox-include igraph_bipartite_projection -->
+</section>
+
+<section id="other-operations-on-bipartite-graphs"><title>Other operations on bipartite graphs</title>
+<!-- doxrox-include igraph_is_bipartite -->
+</section>
+
+</chapter>

references/igraph-1.0.1/doc/bitset.xxml

@@ -0,0 +1,63 @@
+<?xml version="1.0"?>
+<!DOCTYPE section PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN"
+               "http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd" [
+<!ENTITY igraph "igraph">
+]>
+
+<section id="igraph-Bitsets">
+<title>Bitsets</title>
+
+<section id="igraph_bitset_t">
+<!-- doxrox-include about_igraph_bitset_t_objects -->
+</section>
+
+<section id="bitset-constructors-and-destructors">
+<!-- doxrox-include igraph_bitset_constructors_and_destructors -->
+<!-- doxrox-include igraph_bitset_init -->
+<!-- doxrox-include igraph_bitset_init_copy -->
+<!-- doxrox-include igraph_bitset_destroy -->
+</section>
+
+<section id="bitset-accessing-elements">
+<!-- doxrox-include igraph_bitset_accessing_elements -->
+<!-- doxrox-include IGRAPH_BIT_MASK -->
+<!-- doxrox-include IGRAPH_BIT_SLOT -->
+<!-- doxrox-include IGRAPH_BIT_SET -->
+<!-- doxrox-include IGRAPH_BIT_CLEAR -->
+<!-- doxrox-include IGRAPH_BIT_TEST -->
+<!-- doxrox-include IGRAPH_BIT_NSLOTS -->
+</section>
+
+<section id="bitset-operations"><title>Bitset operations</title>
+<!-- doxrox-include igraph_bitset_fill -->
+<!-- doxrox-include igraph_bitset_null -->
+<!-- doxrox-include igraph_bitset_or -->
+<!-- doxrox-include igraph_bitset_and -->
+<!-- doxrox-include igraph_bitset_xor -->
+<!-- doxrox-include igraph_bitset_not -->
+<!-- doxrox-include igraph_bitset_popcount -->
+<!-- doxrox-include igraph_bitset_countl_zero -->
+<!-- doxrox-include igraph_bitset_countl_one -->
+<!-- doxrox-include igraph_bitset_countr_zero -->
+<!-- doxrox-include igraph_bitset_countr_one -->
+<!-- doxrox-include igraph_bitset_is_all_zero -->
+<!-- doxrox-include igraph_bitset_is_all_one -->
+<!-- doxrox-include igraph_bitset_is_any_zero -->
+<!-- doxrox-include igraph_bitset_is_any_one -->
+</section>
+
+<section id="bitset-properties"><title>Bitset properties</title>
+<!-- doxrox-include igraph_bitset_size -->
+<!-- doxrox-include igraph_bitset_capacity -->
+</section>
+
+<section id="bitset-resizing-operations"><title>Resizing operations</title>
+<!-- doxrox-include igraph_bitset_reserve -->
+<!-- doxrox-include igraph_bitset_resize -->
+</section>
+
+<section id="bitset-copying"><title>Copying bitsets</title>
+<!-- doxrox-include igraph_bitset_update -->
+</section>
+
+</section>

references/igraph-1.0.1/doc/c-docbook.re

@@ -0,0 +1,735 @@
+REPLACE ----- remove the " * " prefix first -----------------*- mode:python -*-
+^[ ]\*[ ]
+WITH --------------------------------------------------------------------------
+REPLACE ----- remove the " *" lines -------------------------------------------
+^[ ]\*\s*\n
+WITH --------------------------------------------------------------------------
+\n
+REPLACE IN typed_list.pmt ----- for the typed list template functions ---------
+
+FUNCTION\(
+(?P<suffix>[^\)]*)
+\)\s*
+
+WITH
+
+igraph_vector_list_\g<suffix>
+
+REPLACE IN typed_list.pmt ----- typed list template item type -----------------
+
+ITEM_TYPE
+
+WITH
+
+igraph_vector_t
+
+REPLACE IN typed_list.pmt ----- typed list template type ----------------------
+
+TYPE
+
+WITH
+
+igraph_vector_list_t
+
+REPLACE IN *.pmt ----- for the template functions -----------------------------
+
+FUNCTION\(
+(?P<base>[^, \)]*)\s*,\s*
+(?P<suffix>[^\)]*)
+\)\s*
+
+WITH
+
+\g<base>_\g<suffix>
+
+REPLACE IN *.pmt ----- template type ------------------------------------------
+
+TYPE\(
+(?P<type>[^\)]*)
+\)
+
+WITH
+
+\g<type>_t
+
+REPLACE IN *.pmt ----- template base type, we cowardly assume real number -----
+
+BASE
+
+WITH
+
+igraph_real_t
+
+REPLACE ----- function object, extract its signature --------------------------
+
+(?P<before>\A.*?)                # head of the comment
+\\function\s+                    # \function keyword
+(?P<name>(?P<pre>(igraph_)|(IGRAPH_)|())(?P<tail>\w+)) # the keyword, remove igraph_ prefix
+[\s]*(?P<brief>[^\n]*?)\n        # brief description
+(?P<after>.*?)\*\/               # tail of the comment
+\s*
+(IGRAPH_EXPORT\s+)?              # strip IGRAPH_EXPORT from prototype
+(?P<def>.*?\))                   # function head
+(?=(\s*;)|(\s*\{))               # prototype ends with ; function head with {
+.*\Z                             # and the remainder
+
+WITH --------------------------------------------------------------------------
+
+<section id="\g<name>">
+<title><function>\g<name></function> &mdash; \g<brief></title>
+<indexterm><primary>\g<tail></primary></indexterm>
+<para>
+<informalexample><programlisting>
+\g<def>;
+</programlisting></informalexample>
+</para>
+<para>
+\g<before>
+\g<after>
+</para>
+</section>
+
+REPLACE ----- <paramdef> for functions (not used currently) -------------------
+
+<paramdef>(?P<params>[^<]*)</paramdef>\n
+
+RUN ---------------------------------------------------------------------------
+
+dr_params=string.split(matched.group("params"), ',')
+dr_out=""
+for dr_i in dr_params:
+    dr_i=string.strip(dr_i)
+    if dr_i=="...":
+        dr_out=dr_out+"<varargs/>"
+    else:
+        dr_words=re.match(r"([\w\*\&\s]+)(\b\w+)$", dr_i).groups()
+        dr_out=dr_out+"<paramdef>"+dr_words[0]+"<parameter>"+dr_words[1]+ \
+                "</parameter></paramdef>\n"
+actch=actch[0:matched.start()]+dr_out+actch[matched.end():]
+
+REPLACE ----- function parameter descriptions, head ---------------------------
+
+(?P<before>\A.*?)               # head of the comment
+\\param\b                       # first \param commant
+
+WITH --------------------------------------------------------------------------
+
+\g<before></para>
+<formalpara><title>Arguments:</title><para>
+<variablelist role="params">
+\\param
+
+REPLACE ----- function parameter descriptions, tail ---------------------------
+
+# the end of the params is either an empty line after the last \param
+# command or a \return or \sa statement (others might be added later)
+# or the end of the comment
+
+\\param\b                         # the last \param command
+(?P<paramtext>.*?)                # the text of the \param command
+(?P<endmark>                      # this marks the end of the \param text
+ (\\return\b)|(\\sa\b)|           # it is either a \return or \sa or
+ (\n\s*?\n)|                      # (at least) one empty line or
+ (\*\/))                          # the end of the comment
+(?P<after>.*?\Z)                  # remaining part
+
+WITH
+
+\\param\g<paramtext></variablelist></para></formalpara><para>
+\g<endmark>\g<after>
+
+REPLACE ----- function parameter descriptions ---------------------------------
+
+\\param\b\s*                      # \param command
+(?P<paramname>(\w+)|(...))\s+     # name of the parameter
+(?P<paramtext>.*?)                # text of the \param command
+(?=(\\param)|(</variablelist>)|
+ (\n\s*\n))
+
+
+WITH --------------------------------------------------------------------------
+
+  <varlistentry><term><parameter>\g<paramname></parameter>:</term>
+  <listitem><para>
+  \g<paramtext></para></listitem></varlistentry>
+
+REPLACE ----- \return command -------------------------------------------------
+
+# a return statement ends with an empty line or the end of the comment
+\\return\b\s*                     # \return command
+(?P<text>.*?)                     # the text
+(?=(\n\s*?\n)|                    # empty line or
+ (\*\/)|                          # the end of the comment or
+ (\\sa\b))                        # \sa command
+
+WITH ----------------------------------------------------------------------TODO
+
+</para><formalpara><title>Returns:</title><para><variablelist>
+  <varlistentry><term><parameter></parameter></term>
+  <listitem><para>
+  \g<text>
+  </para></listitem></varlistentry>
+</variablelist></para></formalpara><para>
+
+REPLACE ----- variables -------------------------------------------------------
+
+(?P<before>\A.*?)                 # head of the comment
+\\var\s+                          # \var keyword + argument
+(?P<name>(?P<pre>(igraph_)|(IGRAPH_)|())(?P<tail>\w+))
+[\s]*(?P<brief>[^\n]*?)\n         # brief description
+(?P<after>.*?)\*\/                # tail of the comment
+\s*
+(IGRAPH_EXPORT\s+)?               # strip IGRAPH_EXPORT
+(?P<def>[^;]*;)                   # the definition of the variable
+.*\Z                              # and the remainder
+
+WITH --------------------------------------------------------------------------
+
+<section id="\g<name>"><title><function>\g<name></function> &mdash; \g<brief></title>
+<indexterm><primary>\g<tail></primary></indexterm>
+<para>
+<programlisting>
+\g<def>
+</programlisting>
+</para><para>
+\g<before>\g<after>
+</para>
+</section>
+
+REPLACE ----- \define ---------------------------------------------------------
+
+(?P<before>\A.*?)                 # head of the comment
+\\define\s+                       # \define command
+(?P<name>(?P<pre>(igraph_)|(IGRAPH_)|())(?P<tail>\w+))
+[\s]*(?P<brief>[^\n]*?)\n         # brief description
+(?P<after>.*?)\*\/                # tail of the comment
+\s*                               # whitespace
+(?P<def>\#define\s+[\w0-9,]+\s*   # macro name
+(\([\w0-9,. ]+\))?)               # macro args (optional)
+.*\Z                              # drop the remainder
+
+WITH --------------------------------------------------------------------------
+
+<section id="\g<name>"><title><function>\g<name></function> &mdash; \g<brief></title>
+<indexterm><primary>\g<tail></primary></indexterm>
+<para>
+<programlisting>
+\g<def>
+</programlisting>
+</para><para>
+\g<before>\g<after>
+</para>
+</section>
+
+REPLACE ----- \section without title ------------------------------------------
+
+(?P<before>\A.*?)                 # head of the comment
+\\section\s+(?P<name>\w+)\s*$     # \section + argument
+(?P<after>.*?)\*\/                # tail of the comment
+.*\Z                              # and the remainder, this is dropped
+
+WITH
+
+\g<before>
+\g<after>
+
+REPLACE ----- \section with title ---------------------------------------------
+
+(?P<before>\A.*?)                 # head of the comment
+\\section\s+(?P<name>\w+)         # \section + argument
+(?P<title>.*?)                    # section title
+\n\s*?\n                          # empty line
+(?P<after>.*?)\*\/                # tail of the comment
+.*\Z                              # and the remainder, this is dropped
+
+WITH
+
+<title>\g<title></title>
+\g<before>
+\g<after>
+
+REPLACE ----- \section with title ---------------------------------------------
+
+(?P<before>\A.*?)                 # head of the comment
+\\section\s+(?P<name>\w+)         # \section + argument
+(?P<title>.*?)\s*\*\/             # section title
+.*\Z                              # and the remainder, this is dropped
+
+WITH
+
+<title>\g<title></title>
+\g<before>
+
+REPLACE ----- an enumeration typedef ------------------------------------------
+
+(?P<before>\A.*?)                 # head of the comment
+\\typedef\s+                      # \typedef command
+(?P<name>(?P<pre>(igraph_)|(IGRAPH_)|())(?P<tail>\w+))
+[\s]*(?P<brief>[^\n]*?)\n         # brief description
+(?P<after>.*?)                    # tail of the comment
+ \*\/\s*                          # closing the comment
+(?P<def>typedef\s*enum\s*\{       # typedef enum
+ [^\}]*\}\s*\w+\s*;)                  # rest of the definition
+.*\Z
+
+WITH --------------------------------------------------------------------------
+
+<section id="\g<name>"><title><function>\g<name></function> &mdash; \g<brief></title>
+<indexterm><primary>\g<tail></primary></indexterm>
+<para>
+<programlisting>
+\g<def>
+</programlisting>
+</para>
+<para>
+\g<before>\g<after>
+</para>
+</section>
+
+REPLACE ----- enumeration value descriptions, head ----------------------------
+
+(?P<before>\A.*?)               # head of the comment
+\\enumval\b                     # first \param commant
+
+WITH --------------------------------------------------------------------------
+
+\g<before></para>
+<formalpara><title>Values:</title><para>
+<variablelist role="params">
+\\enumval
+
+REPLACE ----- enumeration value descriptions, tail ----------------------------
+
+\\enumval\b                       # the last \enumval command
+(?P<paramtext>.*?)                # the text of the \enumval command
+(?P<endmark>                      # this marks the end of the \enumval text
+ (\\return\b)|(\\sa\b)|           # it is either a \return or \sa or
+ (\n\s*?\n)|                      # (at least) one empty line or
+ (\*\/))                          # the end of the comment
+(?P<after>.*?\Z)                  # remaining part
+
+WITH
+
+\\enumval\g<paramtext></variablelist></para></formalpara><para>
+\g<endmark>\g<after>
+
+REPLACE ----- enumeration value descriptions ----------------------------------
+
+\\enumval\b\s*                    # \enumval command
+(?P<paramname>(\w+)|(...))\s+     # name of the parameter
+(?P<paramtext>.*?)                # text of the \enumval command
+(?=(\\enumval)|(</variablelist>)|
+ (\n\s*\n))
+
+WITH --------------------------------------------------------------------------
+
+  <varlistentry><term><constant>\g<paramname></constant>:</term>
+  <listitem><para>
+  \g<paramtext></para></listitem></varlistentry>
+
+REPLACE ----- \struct ---------------------------------------------------------
+
+(?P<before>\A.*?)                 # head of the comment
+\\struct\s+                       # \struct command
+(?P<name>(?P<pre>(igraph_)|(IGRAPH_)|())(?P<tail>[\w_]+))
+[\s]*(?P<brief>[^\n]*?)(?=\n)     # brief description
+(?P<after>.*?)                    # tail of the command
+\*\/\s*                           # closing the comment
+(?P<def>typedef \s*struct\s*\w+\s*\{
+ .*\}\s*\w+\s*;)
+.*\Z
+
+WITH --------------------------------------------------------------------------
+
+<section id="\g<name>"><title><function>\g<name></function> &mdash; \g<brief></title>
+<indexterm><primary>\g<tail></primary></indexterm>
+<para>
+<programlisting>
+\g<def>
+</programlisting>
+</para>
+<para>
+\g<before>\g<after>
+</para>
+</section>
+
+REPLACE IN *.h ----- structure member descriptions, one block -----------------
+
+^[\s]*\n
+(?P<before2>.*?)                # empty line+text
+(?P<members>\\member\b.*?)      # member commands
+(?=                             # this marks the end of the \member text
+ (\\return\b)|(\\sa\b)|         # it is either a \return or \sa or
+ (^[\s]*\n)|                    # (at least) one empty line or
+ (\*\/))                        # the end of the comment
+
+WITH --------------------------------------------------------------------------
+
+</para>
+<para>\g<before2></para>
+<formalpara><title>Values:</title>
+<para><variablelist role="params">
+\g<members>
+</variablelist></para></formalpara><para>
+
+REPLACE IN *.h ----- structure member descriptions ----------------------------
+
+\\member\b\s*                     # \enumval command
+(?P<paramname>(\w+)|(...))\s+     # name of the parameter
+(?P<paramtext>.*?)                # text of the \enumval command
+(?=(\\member)|(</variablelist>)|
+ (\n\s*\n))
+
+WITH --------------------------------------------------------------------------
+
+  <varlistentry><term><constant>\g<paramname></constant>:</term>
+  <listitem><para>
+  \g<paramtext></para></listitem></varlistentry>
+
+REPLACE ----- \typedef function -----------------------------------------------
+
+(?P<before>\A.*?)                 # comment head
+\\typedef\s+                      # \typedef command
+(?P<name>(?P<pre>(igraph_)|(IGRAPH_)|())(?P<tail>\w+))
+[\s]*(?P<brief>[^\n]*?)\n         # brief description
+(?P<after>.*?)                    # comment tail
+\*\/                              # end of comment block
+\s*
+(?P<src>typedef\s+[^;]*;)         # the typedef definition
+.*\Z
+
+WITH --------------------------------------------------------------------------
+
+<section id="\g<name>"><title><function>\g<name></function> &mdash; \g<brief></title>
+<indexterm><primary>\g<tail></primary></indexterm>
+<para><programlisting>
+\g<src>
+</programlisting></para>
+<para>
+\g<before>\g<after>
+</para>
+</section>
+
+REPLACE ----- ignore doxygen \ingroup command ---------------------------------
+
+\\ingroup\s+\w+
+
+WITH --------------------------------------------------------------------------
+
+REPLACE ----- ignore doxygen \defgroup command --------------------------------
+
+\\defgroup\s+\w+
+
+WITH --------------------------------------------------------------------------
+
+REPLACE ----- add the contents of \brief to the description -------------------
+
+\\brief\b
+
+WITH --------------------------------------------------------------------------
+
+REPLACE ----- \varname command ------------------------------------------------
+
+\\varname\b\s*
+(?P<var>\w+\b)
+
+WITH
+
+<varname>\g<var></varname>
+
+REPLACE ----- references, \ref command, special case for igraph_vector_int ----
+
+\\ref\b\s*
+igraph_vector_int_(?P<what>\w+)(?P<paren>([\(][\)])?)
+
+WITH --------------------------------------------------------------------------
+
+<link linkend="igraph_vector_\g<what>"><function>igraph_vector_int_\g<what>\g<paren></function></link>
+
+REPLACE ----- references, \ref command ----------------------------------------
+
+\\ref\b\s*
+(?P<what>\w+)(?P<paren>([\(][\)])?)
+
+WITH --------------------------------------------------------------------------
+
+<link linkend="\g<what>"><function>\g<what>\g<paren></function></link>
+
+REPLACE ----- \sa command -----------------------------------------------------
+
+\\sa\b
+\s*
+(?P<text>.*?)
+(?=(\n\s*?\n)|(\*\/))
+
+WITH ----------------------------------------------------------------------TODO
+
+</para><formalpara><title>See also:</title><para><variablelist>
+  <varlistentry><term><parameter></parameter></term>
+  <listitem><para>
+  \g<text>
+  </para></listitem></varlistentry>
+</variablelist></para></formalpara><para>
+
+REPLACE ----- \em command -----------------------------------------------------
+
+\\em\b
+\s*
+(?P<text>[^\s]+)
+
+WITH
+
+<emphasis>\g<text></emphasis>
+
+REPLACE ----- \emb command ----------------------------------------------------
+
+\\emb\b
+
+WITH
+
+<emphasis>
+
+REPLACE ----- \eme command ----------------------------------------------------
+
+\\eme\b
+
+WITH
+
+</emphasis>
+
+REPLACE ----- \verbatim -------------------------------------------------------
+
+\\verbatim\b
+
+WITH
+
+<informalexample><programlisting>
+
+REPLACE ----- \endverbatim ----------------------------------------------------
+
+\\endverbatim\b
+
+WITH
+
+</programlisting></informalexample>
+
+REPLACE ----- \clist ----------------------------------------------------------
+
+\\clist\b
+
+WITH
+
+<variablelist>
+
+REPLACE ----- \cli ------------------------------------------------------------
+
+\\cli\s+(?P<term>.*?)$
+(?P<text>.*?)
+(?=(\\cli)|(\\endclist))
+
+WITH --------------------------------------------------------------------------
+
+<varlistentry><term><constant>\g<term></constant></term>
+<listitem><para>
+\g<text>
+</para></listitem></varlistentry>
+
+REPLACE ----- \endclist -------------------------------------------------------
+
+\\endclist\b
+
+WITH
+
+</variablelist>
+
+REPLACE ----- \olist ----------------------------------------------------------
+
+\\olist\b
+
+WITH
+
+<orderedlist>
+
+REPLACE ----- \oli ------------------------------------------------------------
+
+\\oli\s+(?P<text>.*?)
+(?=(\\oli)|(\\endolist))
+
+WITH
+
+<listitem><para>
+\g<text>
+</para></listitem>
+
+REPLACE ----- \endolist -------------------------------------------------------
+
+\\endolist\b
+
+WITH
+
+</orderedlist>
+
+REPLACE ----- \ilist ----------------------------------------------------------
+
+\\ilist\b
+
+WITH
+
+<itemizedlist>
+
+REPLACE ----- \ili ------------------------------------------------------------
+
+\\ili\s+(?P<text>.*?)
+(?=(\\ili)|(\\endilist))
+
+WITH
+
+<listitem><para>
+\g<text>
+</para></listitem>
+
+REPLACE ----- \endilist -------------------------------------------------------
+
+\\endilist\b
+
+WITH
+
+</itemizedlist>
+
+REPLACE ----- doxygen \c command is for <constant> ----------------------------
+
+\\c\s+(?P<word>[\w\-^\']+)\b
+
+WITH
+
+<constant>\g<word></constant>
+
+REPLACE ----- doxygen \p command is for <parameter> ---------------------------
+
+\\p\s+(?P<word>\w+)\b
+
+WITH
+
+<parameter>\g<word></parameter>
+
+REPLACE ----- doxygen \type command is for <type> -----------------------------
+
+\\type\s+(?P<word>\w+)\b
+
+WITH
+
+<type>\g<word></type>
+
+REPLACE ----- doxygen \a command is for <command> -----------------------------
+
+\\a\s+(?P<word>\w+)\b
+
+WITH
+
+<command>\g<word></command>
+
+REPLACE ----- doxygen \quote command is for <quote> ---------------------------
+
+\\quote\s+
+
+WITH
+
+<quote>
+
+REPLACE ----- doxygen \endquote command is for </quote> -----------------------
+
+\s*\\endquote\b
+
+WITH
+
+</quote>
+
+REPLACE ----- replace <code> with <literal> -----------------------------------
+
+<(?P<c>/?)code>
+
+WITH --------------------------------------------------------------------------
+
+<\g<c>literal>
+
+REPLACE ----- add http:// and https:// links ----------------------------------
+
+(?P<link>https?:\/\/[-\+=&;%@.:/~()?'\w_]*[-\+=&;%@/~'\w_])
+
+WITH --------------------------------------------------------------------------
+
+<ulink url="\g<link>">\g<link></ulink>
+
+REPLACE ----- blockquote ------------------------------------------------------
+
+\\blockquote
+
+WITH --------------------------------------------------------------------------
+
+<blockquote>
+
+REPLACE ----- blockquote ------------------------------------------------------
+
+\\endblockquote
+
+WITH --------------------------------------------------------------------------
+
+</blockquote>
+
+REPLACE ----- example file  ---------------------------------------------------
+
+\\example\b\s*
+(?P<filename>[^\n]*?)\n
+
+WITH --------------------------------------------------------------------------
+
+<example role="sourcefile">
+  <title> File <code>\g<filename></code></title>
+  <xi:include  href="../\g<filename>.xml"
+      xmlns:xi="http://www.w3.org/2001/XInclude"/>
+  <para></para>
+</example>
+
+REPLACE ----- \deprecated-by --------------------------------------------------
+
+\\deprecated-by\b\s*
+(?P<replacement>[^ \n]+)\s*
+(?P<version>[^\n]+)\n
+
+WITH --------------------------------------------------------------------------
+
+</para>
+<warning>
+<para>Deprecated since version \g<version>. Please do not use this function in new
+code; use <link linkend="\g<replacement>"><function>\g<replacement>()</function></link>
+instead.</para>
+</warning>
+<para>
+
+REPLACE ----- \deprecated -----------------------------------------------------
+
+\\deprecated\b\s*
+(?P<version>[^\n]*?)\n
+
+WITH --------------------------------------------------------------------------
+
+</para>
+<warning>
+<para>Deprecated since version \g<version>. Please do not use this function in new
+code.</para>
+</warning>
+<para>
+
+REPLACE ----- \experimental ---------------------------------------------------
+
+\\experimental\b\s*\n
+
+WITH --------------------------------------------------------------------------
+
+</para>
+<warning>
+<para>This function is experimental and its signature is not considered final yet.
+We reserve the right to change the function signature without changing the
+major version of igraph. Use it at your own risk.</para>
+</warning>
+<para>

references/igraph-1.0.1/doc/cliques.xxml

@@ -0,0 +1,45 @@
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN"
+               "http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd" [
+<!ENTITY igraph "igraph">
+]>
+
+<chapter id="igraph-Cliques">
+<title>Cliques and independent vertex sets</title>
+
+<para>
+These functions calculate various graph properties related
+to cliques and independent vertex sets.
+</para>
+
+<section id="cliques"><title>Cliques</title>
+<!-- doxrox-include igraph_is_complete -->
+<!-- doxrox-include igraph_is_clique -->
+<!-- doxrox-include igraph_cliques -->
+<!-- doxrox-include igraph_clique_size_hist -->
+<!-- doxrox-include igraph_cliques_callback -->
+<!-- doxrox-include igraph_clique_handler_t -->
+<!-- doxrox-include igraph_largest_cliques -->
+<!-- doxrox-include igraph_maximal_cliques -->
+<!-- doxrox-include igraph_maximal_cliques_count -->
+<!-- doxrox-include igraph_maximal_cliques_file -->
+<!-- doxrox-include igraph_maximal_cliques_subset -->
+<!-- doxrox-include igraph_maximal_cliques_hist -->
+<!-- doxrox-include igraph_maximal_cliques_callback -->
+<!-- doxrox-include igraph_clique_number -->
+</section>
+
+<section id="weighted-cliques"><title>Weighted cliques</title>
+<!-- doxrox-include igraph_weighted_cliques -->
+<!-- doxrox-include igraph_largest_weighted_cliques -->
+<!-- doxrox-include igraph_weighted_clique_number -->
+</section>
+
+<section id="independent-vertex-sets"><title>Independent vertex sets</title>
+<!-- doxrox-include igraph_is_independent_vertex_set -->
+<!-- doxrox-include igraph_independent_vertex_sets -->
+<!-- doxrox-include igraph_largest_independent_vertex_sets -->
+<!-- doxrox-include igraph_maximal_independent_vertex_sets -->
+<!-- doxrox-include igraph_independence_number -->
+</section>
+
+</chapter>

references/igraph-1.0.1/doc/coloring.xxml

@@ -0,0 +1,19 @@
+<?xml version="1.0"?>
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN"
+               "http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd" [
+<!ENTITY igraph "igraph">
+]>
+
+<chapter id="igraph-Coloring">
+<title>Graph coloring</title>
+
+<!-- doxrox-include igraph_vertex_coloring_greedy -->
+<!-- doxrox-include igraph_coloring_greedy_t -->
+
+<!-- doxrox-include igraph_is_vertex_coloring -->
+<!-- doxrox-include igraph_is_bipartite_coloring -->
+<!-- doxrox-include igraph_is_edge_coloring -->
+
+<!-- doxrox-include igraph_is_perfect -->
+
+</chapter>

references/igraph-1.0.1/doc/community.xxml

@@ -0,0 +1,66 @@
+<?xml version="1.0"?>
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN"
+               "http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd" [
+<!ENTITY igraph "igraph">
+]>
+
+<chapter id="igraph-Community">
+<title>Detecting community structure</title>
+
+<!-- doxrox-include about_community -->
+
+<section id="common-functions-related-to-community-detection"><title>Common functions related to community structure</title>
+<!-- doxrox-include igraph_modularity -->
+<!-- doxrox-include igraph_modularity_matrix -->
+<!-- doxrox-include igraph_community_optimal_modularity -->
+<!-- doxrox-include igraph_community_to_membership -->
+<!-- doxrox-include igraph_reindex_membership -->
+<!-- doxrox-include igraph_compare_communities -->
+<!-- doxrox-include igraph_split_join_distance -->
+</section>
+
+<section id="community-detection-based-on-statistical-mechanics"><title>Community structure based on statistical mechanics</title>
+<!-- doxrox-include igraph_community_spinglass -->
+<!-- doxrox-include igraph_community_spinglass_single -->
+</section>
+
+<section id="community-structure-based-on-eigenvectors-of-matrices"><title>Community structure based on eigenvectors of matrices</title>
+<!-- doxrox-include about_leading_eigenvector_methods -->
+<!-- doxrox-include igraph_community_leading_eigenvector -->
+<!-- doxrox-include igraph_community_leading_eigenvector_callback_t -->
+<!-- doxrox-include igraph_le_community_to_membership -->
+</section>
+
+<section id="walktrap-community-structure-based-on-random-walks"><title>Walktrap: Community structure based on random walks</title>
+<!-- doxrox-include igraph_community_walktrap -->
+</section>
+
+<section id="edge-betweenness-based-community-detection"><title>Edge betweenness based community detection</title>
+<!-- doxrox-include igraph_community_edge_betweenness -->
+<!-- doxrox-include igraph_community_eb_get_merges -->
+</section>
+
+<section id="community-structure-based-on-the-optimization-of-modularity"><title>Community structure based on the optimization of modularity</title>
+<!-- doxrox-include igraph_community_fastgreedy -->
+<!-- doxrox-include igraph_community_multilevel -->
+<!-- doxrox-include igraph_community_leiden -->
+<!-- doxrox-include igraph_community_leiden_simple -->
+</section>
+
+<section id="fluid-communities"><title>Fluid communities</title>
+<!-- doxrox-include igraph_community_fluid_communities -->
+</section>
+
+<section id="label-propagation"><title>Label propagation</title>
+<!-- doxrox-include igraph_community_label_propagation -->
+</section>
+
+<section id="infomap-algorithm"><title>The InfoMAP algorithm</title>
+<!-- doxrox-include igraph_community_infomap -->
+</section>
+
+<section id="voronoi-communities"><title>Voronoi communities</title>
+    <!-- doxrox-include igraph_community_voronoi -->
+</section>
+
+</chapter>

references/igraph-1.0.1/doc/cycles.xxml

@@ -0,0 +1,37 @@
+<?xml version="1.0"?>
+<!DOCTYPE section PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN"
+               "http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd" [
+<!ENTITY igraph "igraph">
+]>
+
+<chapter id="igraph-Cycles">
+<title>Graph cycles</title>
+
+<section id="finding-cycles"><title>Finding cycles</title>
+<!-- doxrox-include igraph_find_cycle -->
+<!-- doxrox-include igraph_simple_cycles -->
+<!-- doxrox-include igraph_simple_cycles_callback -->
+<!-- doxrox-include igraph_cycle_handler_t -->
+</section>
+
+<section id="acyclic-graphs-feedback-sets"><title>Acyclic graphs and feedback sets</title>
+<!-- doxrox-include igraph_is_dag -->
+<!-- doxrox-include igraph_is_acyclic -->
+<!-- doxrox-include igraph_topological_sorting -->
+<!-- doxrox-include igraph_feedback_arc_set -->
+<!-- doxrox-include igraph_feedback_vertex_set -->
+</section>
+
+<section id="eulerian-cycles"><title>Eulerian cycles and paths</title>
+<!-- doxrox-include about_eulerian -->
+<!-- doxrox-include igraph_is_eulerian -->
+<!-- doxrox-include igraph_eulerian_cycle -->
+<!-- doxrox-include igraph_eulerian_path -->
+</section>
+
+<section id="cycle-bases"><title>Cycle bases</title>
+<!-- doxrox-include igraph_fundamental_cycles -->
+<!-- doxrox-include igraph_minimum_cycle_basis -->
+</section>
+
+</chapter>

references/igraph-1.0.1/doc/docbook.outlang

@@ -0,0 +1,36 @@
+# by Stuart Rackham
+# http://www.methods.co.nz/asciidoc/source-highlight-filter.html
+
+extension "xml"
+
+bold "<emphasis role=\"strong\">$text</emphasis>"
+italics "<emphasis>$text</emphasis>"
+
+anchor "<anchor id=\"line$linenum\"/>$text"
+postline_reference "<link linkend='line$linenum'>$text -> $linenum</link>"
+postdoc_reference "<link linkend='line$linenum'>$text -> $linenum</link>"
+reference "<link linkend='$text'>$text</link>"
+
+doctemplate
+"<!DOCTYPE article PUBLIC \"-//OASIS//DTD DocBook//EN\">
+<article>
+<articleinfo>
+<title>$title</title>
+</articleinfo>
+<programlisting linenumbering=\"numbered\">"
+"</programlisting>
+</article>
+"
+end
+
+nodoctemplate
+"<programlisting linenumbering=\"numbered\">"
+"</programlisting>
+"
+end
+
+translations
+"&" "&amp;"
+"<" "&lt;"
+">" "&gt;"
+end

references/igraph-1.0.1/doc/doxrox.py

@@ -0,0 +1,567 @@
+#! /usr/bin/env python3
+
+#   igraph library
+#   Copyright (C) 2005-2021  The igraph development team
+#
+#   This program is free software; you can redistribute it and/or modify
+#   it under the terms of the GNU General Public License as published by
+#   the Free Software Foundation; either version 2 of the License, or
+#   (at your option) any later version.
+#
+#   This program is distributed in the hope that it will be useful,
+#   but WITHOUT ANY WARRANTY; without even the implied warranty of
+#   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+#   GNU General Public License for more details.
+#
+#   You should have received a copy of the GNU General Public License
+#   along with this program; if not, write to the Free Software
+#   Foundation, Inc.,  51 Franklin Street, Fifth Floor, Boston, MA
+#   02110-1301 USA
+#
+###################################################################
+
+"""DocBook XML generator for igraph.
+
+The generator parses one or more input files for documentation chunks
+(embedded in the source code as Doxygen-style comments), and processes
+them with a set of regex-based rules. The processed chunks are then
+substituted into a template file containing <!-- doxrox-include -->
+directives.
+
+When a template file is not provided, the generator will read the input
+files, process them with the ruleset and save a dictionary mapping chunk
+names to the corresponding processed chunks into a Python pickle. This
+can be used to speed up the processing of multiple input files as you can
+generate the chunks once and then re-use them for multiple input files.
+"""
+
+import os
+import re
+import sys
+
+from argparse import ArgumentParser
+from collections import defaultdict
+from contextlib import contextmanager
+from dataclasses import dataclass
+from enum import Enum
+from fnmatch import fnmatch
+from hashlib import sha1
+from operator import itemgetter
+from pathlib import Path
+from pickle import dump, load
+from time import time
+from typing import Any, Callable, Dict, Iterator, List, Optional, Pattern
+
+#: Constant indicating the start of a comment that doxrox.py will process
+DOXHEAD: str = r"/\*\*"
+
+#: Stores whether we want verbose output
+verbose: bool = False
+
+
+def fatal(message: str, code: int = 1):
+    """Prints an error message and exits the program with the given error code."""
+    print(message, file=sys.stderr)
+    sys.exit(code)
+
+
+#########################################################################
+# The main function
+#########################################################################
+
+
+def main():
+    """Main entry point of the script."""
+
+    global verbose
+
+    # get command line arguments
+    parser = create_argument_parser()
+    arguments = parser.parse_args()
+
+    outputfile: str = arguments.output_file
+    inputs: List[str] = arguments.inputs
+
+    verbose = arguments.verbose
+
+    if (
+        arguments.template_file in inputs
+        or arguments.rules_file in inputs
+        or outputfile in inputs
+    ):
+        fatal("Special file is also used as an input file", 2)
+
+    # open the cache file if needed
+    cache = ChunkCache(arguments.cache_file) if arguments.cache_file else None
+
+    # get all regular expressions
+    rules: List[Rule]
+    if arguments.rules_file:
+        with operation("Reading regular expressions...") as op:
+            rules = read_regex_rules_file(arguments.rules_file)
+            op("{0} rules read".format(len(rules)))
+    else:
+        rules = []
+
+    # parse all input files and extract chunks, apply rules
+    if arguments.chunk_file:
+        with operation("Reading pickled chunks...") as op:
+            try:
+                with open(arguments.chunk_file, "rb") as f:
+                    all_chunks = load(f)
+            except IOError:
+                fatal("Error reading chunk file: " + arguments.chunk_file, 9)
+            op("{0} chunks read".format(len(all_chunks)))
+    else:
+        all_chunks = {}
+
+    rule_timings = defaultdict(list)
+
+    for ifile in inputs:
+        with operation("Parsing input file {0}...".format(ifile)) as op:
+            try:
+                with open(ifile, "r") as f:
+                    contents = f.read()
+            except IOError:
+                fatal("Error reading input file: " + ifile, 3)
+
+            if cache:
+                key = cache.key_of(contents)
+                chunks = cache.get(key)
+            else:
+                key, chunks = None, None
+
+            if chunks is not None:
+                op("{0} chunks read from cache".format(len(chunks)))
+            else:
+                chunks = collect_chunks_from_input_file(
+                    ifile, contents, rules, rule_timings
+                )
+                op("{0} chunks parsed".format(len(chunks)))
+                if key and cache:
+                    cache.put(key, chunks)
+
+            for name, chunk in chunks.items():
+                if name in all_chunks:
+                    fatal(
+                        "Multiple files provide chunks for {0!r}".format(name), code=4
+                    )
+                all_chunks[name] = chunk
+
+    if arguments.timing_stats and rule_timings:
+        rule_timings = {name: sum(dts) / len(dts) for name, dts in rule_timings.items()}
+        for name, dt in sorted(rule_timings.items(), key=itemgetter(1), reverse=True):
+            print("{0}: {1:.3f}us".format(name, dt))
+        print("======")
+
+    if cache:
+        cache.close()
+
+    if arguments.template_file:
+        # substitute the template file
+        with operation("Reading template file..."):
+            try:
+                with open(arguments.template_file, "r") as tfile:
+                    tstring = tfile.read()
+            except IOError:
+                fatal("Error reading the template file: " + arguments.template_file, 7)
+
+        with operation("Substituting template file..."):
+            chunk_iterator = re.finditer(
+                r"<!--\s*doxrox-include\s+(\w+)\s*-->", tstring
+            )
+            outstring = []
+            last = 0
+            for match in chunk_iterator:
+                try:
+                    chunk = all_chunks[match.group(1)]
+                except KeyError:
+                    fatal("Chunk not found: {0}".format(match.group(1)), code=4)
+                outstring.append(tstring[last : match.start()])
+                outstring.append(chunk)
+                last = match.end()
+            outstring.append(tstring[last:])
+            outstring = "".join(outstring)
+
+        # write output file
+        with operation("Writing output file..."):
+            try:
+                with open(outputfile, "w") as ofile:
+                    ofile.write(outstring)
+            except IOError:
+                fatal("Error writing output file:" + outputfile, 8)
+    else:
+        # no template file given so just save the chunks as a pickle into the
+        # output file
+        with operation("Writing output file..."):
+            try:
+                with open(outputfile, "wb") as ofile:
+                    dump(all_chunks, ofile)
+            except IOError:
+                fatal("Error writing output file:" + outputfile, 5)
+
+
+#########################################################################
+# Argument parser
+#########################################################################
+
+
+def create_argument_parser() -> ArgumentParser:
+    """Creates the command line argument parser that the script uses."""
+    parser = ArgumentParser(description=(sys.modules[__name__].__doc__ or "").strip())
+
+    parser.add_argument(
+        "--cache",
+        metavar="FILE",
+        dest="cache_file",
+        help="optional cache file to store chunks from already processed files",
+    )
+    parser.add_argument(
+        "-t",
+        "--template",
+        metavar="FILE",
+        dest="template_file",
+        help="template file to process",
+    )
+    parser.add_argument(
+        "-e",
+        "--rules",
+        metavar="FILE",
+        dest="rules_file",
+        help="file containing matching and replacement rules",
+    )
+    parser.add_argument(
+        "-o",
+        "--output",
+        metavar="FILE",
+        dest="output_file",
+        required=True,
+        help="name of the output file",
+    )
+    parser.add_argument(
+        "-v",
+        "--verbose",
+        action="store_true",
+        default=False,
+        dest="verbose",
+        help="enable verbose output",
+    )
+    parser.add_argument(
+        "--chunks",
+        dest="chunk_file",
+        metavar="FILE",
+        help="name of a previously saved chunk file",
+    )
+    parser.add_argument(
+        "--timing-stats",
+        dest="timing_stats",
+        action="store_true",
+        default=False,
+        help="print the average time it takes to process regex rules from the rules file",
+    )
+    parser.add_argument(
+        "inputs", metavar="INPUT", nargs="*", help="input files to process"
+    )
+
+    return parser
+
+
+#################
+# classes and functions to read the regular expression rules
+#################
+
+
+class RuleType(Enum):
+    REPLACE = "replace"
+    RUN = "run"
+
+
+@dataclass
+class Rule:
+    regex: Pattern[str]
+    """The regular expression that the rule will attempt to match."""
+
+    replacement: str
+    """The replacement string for the match, or the code to execute on the
+    match.
+    """
+
+    type: RuleType
+    """Type of the rule"""
+
+    name: Optional[str]
+    """Name of the rule, for debugging purposes."""
+
+    glob: Optional[str] = None
+    """Optional glob pattern that specifies which input files the rule
+    applies to.
+    """
+
+    def applies_to_filename(self, filename: str) -> bool:
+        """Returns whether the rule applies to files with the given name."""
+        if self.glob:
+            return fnmatch(filename, self.glob)
+        else:
+            return True
+
+
+def read_regex_rules_file(filename) -> List[Rule]:
+    """Parses the file containing the regex-based rules that we use to chop
+    up the input source files into chunks that can later be fed into a
+    DocBook document.
+
+    Parameters:
+        filename: name of the input file
+
+    Returns:
+        the rules that were parsed from the input file
+    """
+
+    rules: List[Rule] = []
+
+    def parse_error(lineno):
+        """Helper function to indicate a parse error at the given line."""
+        fatal(
+            "Parse error in regex file ({0}), line {1}".format(filename, lineno), code=4
+        )
+
+    def store(
+        rule: List[str],
+        replacement: List[str],
+        rule_name: Optional[str],
+        rule_type: RuleType,
+        glob: Optional[str],
+    ) -> None:
+        """Helper function to append the current rule to the result."""
+        regex = re.compile("".join(rule), re.VERBOSE | re.MULTILINE | re.DOTALL)
+        replacement_str = "".join(replacement)[:-1]
+        rules.append(Rule(regex, replacement_str, rule_type, rule_name, glob))
+
+    mode = "empty"
+    regex, replacement = [], []
+    rule_name: Optional[str] = None
+    rule_type: Optional[RuleType] = None
+    glob: Optional[str] = None
+
+    try:
+        with open(filename, "r") as f:
+            for lineno, line in enumerate(f, 1):
+                if line.startswith("REPLACE"):
+                    # a new pattern block starts
+                    if mode not in ("empty", "with"):
+                        parse_error(lineno)
+                    else:
+                        if regex and rule_type:
+                            store(regex, replacement, rule_name, rule_type, glob)
+                        regex.clear()
+                        replacement.clear()
+                        mode = "replace"
+
+                        match = re.match(
+                            r"^REPLACE( IN (?P<glob>[^\s]+))?\s+-+\s+(?P<name>.*)\s+-",
+                            line,
+                        )
+                        rule_name = match.group("name") if match else None
+                        glob = match.group("glob") if match else None
+
+                elif line.startswith("WITH") or line.startswith("RUN"):
+                    # the second half of the pattern block starts
+                    if mode != "replace":
+                        parse_error(lineno)
+                    else:
+                        mode = "with"
+                    rule_type = (
+                        RuleType.REPLACE if line.startswith("WITH") else RuleType.RUN
+                    )
+
+                elif re.match(r"^\s*$", line):
+                    # empty line, do nothing
+                    pass
+
+                else:
+                    # normal line, append
+                    if mode == "replace":
+                        regex.append(line)
+                    elif mode == "with":
+                        replacement.append(line)
+                    else:
+                        parse_error(lineno)
+
+            if regex != "" and rule_type:
+                store(regex, replacement, rule_name, rule_type, glob)
+
+    except IOError:
+        fatal("Error reading regex file: " + filename, code=4)
+
+    return rules
+
+
+#################
+# parse an input file string
+#################
+def collect_chunks_from_input_file(
+    path: str, strinput: str, rules: List[Rule], rule_timings
+) -> Dict[str, str]:
+    result: Dict[str, str] = {}
+
+    # split the file
+    chunks = re.split(DOXHEAD, strinput)
+    chunks = chunks[1:]
+
+    # get the filename part of the path
+    filename = os.path.basename(path)
+
+    # apply all rules to the chunks
+    for chunk in chunks:
+        name: Optional[str] = None
+
+        for rule in rules:
+            start = time()
+
+            if not name and "name" in rule.regex.groupindex:
+                # The regex might provide us with a chunk name so try figuring
+                # out what the "name" group might match to
+                matched = rule.regex.search(chunk)
+                if matched:
+                    try:
+                        name = matched.group("name")
+                    except IndexError:
+                        name = ""
+
+            if rule.applies_to_filename(filename):
+                if rule.type is RuleType.REPLACE:
+                    # This is a simple regex replacement rule
+                    try:
+                        chunk = rule.regex.sub(rule.replacement, chunk)
+                    except IndexError:
+                        print("Index error:" + chunk[0:60] + "...")
+                        print("Pattern:\n" + rule.regex.pattern)
+                        print("Current state:" + chunk[0:60] + "...")
+                        fatal("Parsing error", code=6)
+                elif rule.type is RuleType.RUN:
+                    # This is a piece of Python code that has to be executed on
+                    # the part that matched
+                    matched = rule.regex.search(chunk)
+                    if matched:
+                        exec(rule.replacement)
+                else:
+                    fatal("Invalid rule type: {0!r}".format(rule.type), code=6)
+
+            rule_timings[rule.name].append((time() - start) * 1000000)
+
+        if not name:
+            # print("Chunk without a name ignored:" + ch[0:60] + "...")
+            continue
+
+        result[name] = chunk.strip()
+
+    return result
+
+
+@contextmanager
+def operation(message: str) -> Iterator[Callable[[Any], None]]:
+    """Helper function to show progress messages for a potentially long-running
+    operation in verbose mode.
+
+    Parameters:
+        message (str): the message to show
+    """
+    global verbose
+
+    if verbose:
+        print(message, end="")
+
+    result = [None]
+
+    def set_result(obj: Any) -> None:
+        result[0] = obj
+
+    success = False
+    try:
+        yield set_result
+        success = True
+    finally:
+        if verbose and success:
+            if result[0] is None:
+                print(" done.")
+            else:
+                print(" done, {0}.".format(result[0]))
+
+
+class ChunkCache:
+    """Simple on-disk cache that stores SHA256 hashes of files along with the
+    DocBook documentation chunks that were parsed from them.
+    """
+
+    _data: Optional[Dict[str, Dict[str, str]]]
+    _dirty: bool
+    _path: Path
+
+    def __init__(self, filename: str, hash=sha1):
+        """Constructor.
+
+        Parameters:
+            filename: name of the file on the disk where the cache resides
+            hash: the hash function to use
+        """
+        self._data = None
+        self._dirty = False
+        self._hash = hash
+        self._path = Path(filename)
+
+    def _load(self) -> None:
+        """Populates the in-memory copy of the cache from the disk."""
+        if self._path.exists():
+            try:
+                with self._path.open("rb") as fp:
+                    self._data = load(fp)
+            except (IOError, EOFError):
+                # cache corrupted
+                self._data = {}
+        else:
+            self._data = {}
+        self._dirty = False
+
+    def close(self) -> None:
+        """Closes the cache and flushes its contents back to the disk if it
+        changed recently.
+        """
+        if self._dirty:
+            self.flush()
+
+    def flush(self) -> None:
+        """Flushes the contents of the cache back to the disk."""
+        with self._path.open("wb") as fp:
+            dump(self._data, fp)
+        self._dirty = False
+
+    def get(self, key: str) -> Optional[Dict[str, str]]:
+        """Returns the chunks associated to the file with the given key, or
+        `None` if the key is not in the cache.
+        """
+        if self._data is None:
+            self._load()
+
+        assert self._data is not None
+        return self._data.get(key)
+
+    def key_of(self, contents, encoding: str = "utf-8") -> str:
+        """Returns the hash key corresponding to the file with the given
+        contents.
+        """
+        if not isinstance(contents, bytes):
+            contents = contents.encode(encoding)
+
+        key = self._hash()
+        key.update(contents)
+        return key.hexdigest()
+
+    def put(self, key: str, chunks: Dict[str, str]) -> None:
+        """Stores some chunks associated to the file with the given key."""
+        assert self._data is not None
+        self._data[key] = chunks
+        self._dirty = True
+
+
+if __name__ == "__main__":
+    main()

references/igraph-1.0.1/doc/dqueue.xxml

@@ -0,0 +1,24 @@
+<?xml version="1.0"?>
+<!DOCTYPE section PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN"
+               "http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd" [
+<!ENTITY igraph "igraph">
+]>
+
+<section id="igraph-Dqueues">
+<title id="double-ended-queues">Double-ended queues</title>
+
+<!-- doxrox-include igraph_dqueue -->
+<!-- doxrox-include igraph_dqueue_init -->
+<!-- doxrox-include igraph_dqueue_destroy -->
+<!-- doxrox-include igraph_dqueue_empty -->
+<!-- doxrox-include igraph_dqueue_full -->
+<!-- doxrox-include igraph_dqueue_clear -->
+<!-- doxrox-include igraph_dqueue_size -->
+<!-- doxrox-include igraph_dqueue_head -->
+<!-- doxrox-include igraph_dqueue_back -->
+<!-- doxrox-include igraph_dqueue_get -->
+<!-- doxrox-include igraph_dqueue_pop -->
+<!-- doxrox-include igraph_dqueue_pop_back -->
+<!-- doxrox-include igraph_dqueue_push -->
+
+</section>

references/igraph-1.0.1/doc/embedding.xxml

@@ -0,0 +1,16 @@
+<?xml version='1.0'?>
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN"
+                  "http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd" [
+<!ENTITY igraph "igraph">
+]>
+
+<chapter id="igraph-Embedding">
+<title>Embedding of graphs</title>
+
+<section id="spectral-embedding"><title>Spectral embedding</title>
+<!-- doxrox-include igraph_adjacency_spectral_embedding -->
+<!-- doxrox-include igraph_laplacian_spectral_embedding -->
+<!-- doxrox-include igraph_dim_select -->
+</section>
+
+</chapter>

references/igraph-1.0.1/doc/error.xxml

@@ -0,0 +1,88 @@
+<?xml version="1.0"?>
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN"
+               "http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd" [
+<!ENTITY igraph "igraph">
+]>
+
+<chapter id="igraph-Error">
+<title>Error handling</title>
+
+<section id="error-handling-basics">
+<!-- doxrox-include error_handling_basics -->
+</section>
+
+<section id="error-handlers">
+<!-- doxrox-include error_handlers -->
+<!-- doxrox-include igraph_error_handler_t -->
+<!-- doxrox-include igraph_error_handler_abort -->
+<!-- doxrox-include igraph_error_handler_ignore -->
+<!-- doxrox-include igraph_error_handler_printignore -->
+</section>
+
+<section id="error-codes">
+<!-- doxrox-include error_codes -->
+<!-- doxrox-include igraph_error_t -->
+<!-- doxrox-include igraph_error_type_t -->
+<!-- doxrox-include igraph_strerror -->
+</section>
+
+<section id="warnings">
+<!-- doxrox-include about_igraph_warnings -->
+<!-- doxrox-include igraph_warning_handler_t -->
+<!-- doxrox-include igraph_set_warning_handler -->
+<!-- doxrox-include IGRAPH_WARNING -->
+<!-- doxrox-include IGRAPH_WARNINGF -->
+<!-- doxrox-include igraph_warning -->
+<!-- doxrox-include igraph_warningf -->
+<!-- doxrox-include igraph_warning_handler_ignore -->
+<!-- doxrox-include igraph_warning_handler_print -->
+</section>
+
+<section id="error-advanced-topics">
+<title>Advanced topics</title>
+
+<section id="writing-error-handlers">
+<!-- doxrox-include writing_error_handlers -->
+<!-- doxrox-include igraph_set_error_handler -->
+</section>
+
+<section id="error-handling-internals">
+<!-- doxrox-include error_handling_internals -->
+<!-- doxrox-include IGRAPH_ERROR -->
+<!-- doxrox-include IGRAPH_ERRORF -->
+<!-- doxrox-include igraph_error -->
+<!-- doxrox-include igraph_errorf -->
+<!-- doxrox-include IGRAPH_CHECK -->
+<!-- doxrox-include IGRAPH_CHECK_CALLBACK -->
+</section>
+
+<section id="deallocating-memory">
+<!-- doxrox-include deallocating_memory -->
+<!-- doxrox-include IGRAPH_FINALLY -->
+<!-- doxrox-include IGRAPH_FINALLY_CLEAN -->
+<!-- doxrox-include IGRAPH_FINALLY_FREE -->
+</section>
+
+<section id="writing-igraph-functions-with-proper-error-handling">
+<!-- doxrox-include writing_functions_error_handling -->
+</section>
+
+<section id="fatal-error-handlers">
+<!-- doxrox-include fatal_error_handlers -->
+<!-- doxrox-include igraph_fatal_handler_t -->
+<!-- doxrox-include igraph_set_fatal_handler -->
+<!-- doxrox-include igraph_fatal_handler_abort -->
+<!-- doxrox-include IGRAPH_FATAL -->
+<!-- doxrox-include IGRAPH_FATALF -->
+<!-- doxrox-include IGRAPH_ASSERT -->
+<!-- doxrox-include igraph_fatal -->
+<!-- doxrox-include igraph_fatalf -->
+</section>
+
+<section id="error-handling-and-threads">
+<!-- doxrox-include error_handling_threads -->
+</section>
+
+</section>
+
+</chapter>

references/igraph-1.0.1/doc/fdl.xml

@@ -0,0 +1,420 @@
+<?xml version="1.0"?>
+<!DOCTYPE section PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN"
+               "http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd">
+<section id="igraph-fdl">
+  <sectioninfo>
+    <edition>Version 1.2, November 2002</edition>
+    <copyright><year>2000</year><year>2001</year><year>2002</year>
+    <holder>Free Software Foundation, Inc.
+      51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
+    </holder>
+    </copyright>
+    <legalnotice><para>
+     Everyone is permitted to copy and distribute verbatim copies
+     of this license document, but changing it is not allowed.
+    </para>
+    </legalnotice>
+  </sectioninfo>
+
+<title>The GNU Free Documentation License</title>
+
+<section><title>0. PREAMBLE</title>
+<para>
+The purpose of this License is to make a manual, textbook, or other
+functional and useful document "free" in the sense of freedom: to
+assure everyone the effective freedom to copy and redistribute it,
+with or without modifying it, either commercially or noncommercially.
+Secondarily, this License preserves for the author and publisher a way
+to get credit for their work, while not being considered responsible
+for modifications made by others.
+</para><para>
+This License is a kind of "copyleft", which means that derivative
+works of the document must themselves be free in the same sense.  It
+complements the GNU General Public License, which is a copyleft
+license designed for free software.
+</para><para>
+We have designed this License in order to use it for manuals for free
+software, because free software needs free documentation: a free
+program should come with manuals providing the same freedoms that the
+software does.  But this License is not limited to software manuals;
+it can be used for any textual work, regardless of subject matter or
+whether it is published as a printed book.  We recommend this License
+principally for works whose purpose is instruction or reference.
+</para>
+</section><section><title>1. APPLICABILITY AND DEFINITIONS</title>
+<para>
+This License applies to any manual or other work, in any medium, that
+contains a notice placed by the copyright holder saying it can be
+distributed under the terms of this License.  Such a notice grants a
+world-wide, royalty-free license, unlimited in duration, to use that
+work under the conditions stated herein.  The "Document", below,
+refers to any such manual or work.  Any member of the public is a
+licensee, and is addressed as "you".  You accept the license if you
+copy, modify or distribute the work in a way requiring permission
+under copyright law.
+</para><para>
+A "Modified Version" of the Document means any work containing the
+Document or a portion of it, either copied verbatim, or with
+modifications and/or translated into another language.
+</para><para>
+A "Secondary Section" is a named appendix or a front-matter section of
+the Document that deals exclusively with the relationship of the
+publishers or authors of the Document to the Document's overall subject
+(or to related matters) and contains nothing that could fall directly
+within that overall subject.  (Thus, if the Document is in part a
+textbook of mathematics, a Secondary Section may not explain any
+mathematics.)  The relationship could be a matter of historical
+connection with the subject or with related matters, or of legal,
+commercial, philosophical, ethical or political position regarding
+them.
+</para><para>
+The "Invariant Sections" are certain Secondary Sections whose titles
+are designated, as being those of Invariant Sections, in the notice
+that says that the Document is released under this License.  If a
+section does not fit the above definition of Secondary then it is not
+allowed to be designated as Invariant.  The Document may contain zero
+Invariant Sections.  If the Document does not identify any Invariant
+Sections then there are none.
+</para><para>
+The "Cover Texts" are certain short passages of text that are listed,
+as Front-Cover Texts or Back-Cover Texts, in the notice that says that
+the Document is released under this License.  A Front-Cover Text may
+be at most 5 words, and a Back-Cover Text may be at most 25 words.
+</para><para>
+A "Transparent" copy of the Document means a machine-readable copy,
+represented in a format whose specification is available to the
+general public, that is suitable for revising the document
+straightforwardly with generic text editors or (for images composed of
+pixels) generic paint programs or (for drawings) some widely available
+drawing editor, and that is suitable for input to text formatters or
+for automatic translation to a variety of formats suitable for input
+to text formatters.  A copy made in an otherwise Transparent file
+format whose markup, or absence of markup, has been arranged to thwart
+or discourage subsequent modification by readers is not Transparent.
+An image format is not Transparent if used for any substantial amount
+of text.  A copy that is not "Transparent" is called "Opaque".
+</para><para>
+Examples of suitable formats for Transparent copies include plain
+ASCII without markup, Texinfo input format, LaTeX input format, SGML
+or XML using a publicly available DTD, and standard-conforming simple
+HTML, PostScript or PDF designed for human modification.  Examples of
+transparent image formats include PNG, XCF and JPG.  Opaque formats
+include proprietary formats that can be read and edited only by
+proprietary word processors, SGML or XML for which the DTD and/or
+processing tools are not generally available, and the
+machine-generated HTML, PostScript or PDF produced by some word
+processors for output purposes only.
+</para><para>
+The "Title Page" means, for a printed book, the title page itself,
+plus such following pages as are needed to hold, legibly, the material
+this License requires to appear in the title page.  For works in
+formats which do not have any title page as such, "Title Page" means
+the text near the most prominent appearance of the work's title,
+preceding the beginning of the body of the text.
+</para><para>
+A section "Entitled XYZ" means a named subunit of the Document whose
+title either is precisely XYZ or contains XYZ in parentheses following
+text that translates XYZ in another language.  (Here XYZ stands for a
+specific section name mentioned below, such as "Acknowledgements",
+"Dedications", "Endorsements", or "History".)  To "Preserve the Title"
+of such a section when you modify the Document means that it remains a
+section "Entitled XYZ" according to this definition.
+</para><para>
+The Document may include Warranty Disclaimers next to the notice which
+states that this License applies to the Document.  These Warranty
+Disclaimers are considered to be included by reference in this
+License, but only as regards disclaiming warranties: any other
+implication that these Warranty Disclaimers may have is void and has
+no effect on the meaning of this License.
+</para>
+   </section><section><title>2. VERBATIM COPYING</title>
+<para>
+You may copy and distribute the Document in any medium, either
+commercially or noncommercially, provided that this License, the
+copyright notices, and the license notice saying this License applies
+to the Document are reproduced in all copies, and that you add no other
+conditions whatsoever to those of this License.  You may not use
+technical measures to obstruct or control the reading or further
+copying of the copies you make or distribute.  However, you may accept
+compensation in exchange for copies.  If you distribute a large enough
+number of copies you must also follow the conditions in section 3.
+</para><para>
+You may also lend copies, under the same conditions stated above, and
+you may publicly display copies.
+</para>
+   </section><section><title>3. COPYING IN QUANTITY</title>
+<para>
+If you publish printed copies (or copies in media that commonly have
+printed covers) of the Document, numbering more than 100, and the
+Document's license notice requires Cover Texts, you must enclose the
+copies in covers that carry, clearly and legibly, all these Cover
+Texts: Front-Cover Texts on the front cover, and Back-Cover Texts on
+the back cover.  Both covers must also clearly and legibly identify
+you as the publisher of these copies.  The front cover must present
+the full title with all words of the title equally prominent and
+visible.  You may add other material on the covers in addition.
+Copying with changes limited to the covers, as long as they preserve
+the title of the Document and satisfy these conditions, can be treated
+as verbatim copying in other respects.
+</para><para>
+If the required texts for either cover are too voluminous to fit
+legibly, you should put the first ones listed (as many as fit
+reasonably) on the actual cover, and continue the rest onto adjacent
+pages.
+</para><para>
+If you publish or distribute Opaque copies of the Document numbering
+more than 100, you must either include a machine-readable Transparent
+copy along with each Opaque copy, or state in or with each Opaque copy
+a computer-network location from which the general network-using
+public has access to download using public-standard network protocols
+a complete Transparent copy of the Document, free of added material.
+If you use the latter option, you must take reasonably prudent steps,
+when you begin distribution of Opaque copies in quantity, to ensure
+that this Transparent copy will remain thus accessible at the stated
+location until at least one year after the last time you distribute an
+Opaque copy (directly or through your agents or retailers) of that
+edition to the public.
+</para><para>
+It is requested, but not required, that you contact the authors of the
+Document well before redistributing any large number of copies, to give
+them a chance to provide you with an updated version of the Document.
+</para>
+   </section><section><title>4. MODIFICATIONS</title>
+<para>
+You may copy and distribute a Modified Version of the Document under
+the conditions of sections 2 and 3 above, provided that you release
+the Modified Version under precisely this License, with the Modified
+Version filling the role of the Document, thus licensing distribution
+and modification of the Modified Version to whoever possesses a copy
+of it.  In addition, you must do these things in the Modified Version:
+</para><para>
+     <orderedlist numeration="upperalpha">
+     <listitem><para>
+   Use in the Title Page (and on the covers, if any) a title distinct
+   from that of the Document, and from those of previous versions
+   (which should, if there were any, be listed in the History section
+   of the Document).  You may use the same title as a previous version
+   if the original publisher of that version gives permission.
+     </para></listitem><listitem><para>
+   List on the Title Page, as authors, one or more persons or entities
+   responsible for authorship of the modifications in the Modified
+   Version, together with at least five of the principal authors of the
+   Document (all of its principal authors, if it has fewer than five),
+   unless they release you from this requirement.
+     </para></listitem><listitem><para>
+   State on the Title page the name of the publisher of the
+   Modified Version, as the publisher.
+     </para></listitem><listitem><para>
+   Preserve all the copyright notices of the Document.
+     </para></listitem><listitem><para>
+   Add an appropriate copyright notice for your modifications
+   adjacent to the other copyright notices.
+     </para></listitem><listitem><para>
+   Include, immediately after the copyright notices, a license notice
+   giving the public permission to use the Modified Version under the
+   terms of this License, in the form shown in the Addendum below.
+     </para></listitem><listitem><para>
+   Preserve in that license notice the full lists of Invariant Sections
+   and required Cover Texts given in the Document's license notice.
+     </para></listitem><listitem><para>
+   Include an unaltered copy of this License.
+     </para></listitem><listitem><para>
+   Preserve the section Entitled "History", Preserve its Title, and add
+   to it an item stating at least the title, year, new authors, and
+   publisher of the Modified Version as given on the Title Page.  If
+   there is no section Entitled "History" in the Document, create one
+   stating the title, year, authors, and publisher of the Document as
+   given on its Title Page, then add an item describing the Modified
+   Version as stated in the previous sentence.
+     </para></listitem><listitem><para>
+   Preserve the network location, if any, given in the Document for
+   public access to a Transparent copy of the Document, and likewise
+   the network locations given in the Document for previous versions
+   it was based on.  These may be placed in the "History" section.
+   You may omit a network location for a work that was published at
+   least four years before the Document itself, or if the original
+   publisher of the version it refers to gives permission.
+     </para></listitem><listitem><para>
+   For any section Entitled "Acknowledgements" or "Dedications",
+   Preserve the Title of the section, and preserve in the section all
+   the substance and tone of each of the contributor acknowledgements
+   and/or dedications given therein.
+     </para></listitem><listitem><para>
+   Preserve all the Invariant Sections of the Document,
+   unaltered in their text and in their titles.  Section numbers
+   or the equivalent are not considered part of the section titles.
+     </para></listitem><listitem><para>
+   Delete any section Entitled "Endorsements".  Such a section
+   may not be included in the Modified Version.
+     </para></listitem><listitem><para>
+   Do not retitle any existing section to be Entitled "Endorsements"
+   or to conflict in title with any Invariant Section.
+     </para></listitem><listitem><para>
+   Preserve any Warranty Disclaimers.
+     </para></listitem></orderedlist>
+</para><para>
+If the Modified Version includes new front-matter sections or
+appendices that qualify as Secondary Sections and contain no material
+copied from the Document, you may at your option designate some or all
+of these sections as invariant.  To do this, add their titles to the
+list of Invariant Sections in the Modified Version's license notice.
+These titles must be distinct from any other section titles.
+</para><para>
+You may add a section Entitled "Endorsements", provided it contains
+nothing but endorsements of your Modified Version by various
+parties--for example, statements of peer review or that the text has
+been approved by an organization as the authoritative definition of a
+standard.
+</para><para>
+You may add a passage of up to five words as a Front-Cover Text, and a
+passage of up to 25 words as a Back-Cover Text, to the end of the list
+of Cover Texts in the Modified Version.  Only one passage of
+Front-Cover Text and one of Back-Cover Text may be added by (or
+through arrangements made by) any one entity.  If the Document already
+includes a cover text for the same cover, previously added by you or
+by arrangement made by the same entity you are acting on behalf of,
+you may not add another; but you may replace the old one, on explicit
+permission from the previous publisher that added the old one.
+</para><para>
+The author(s) and publisher(s) of the Document do not by this License
+give permission to use their names for publicity for or to assert or
+imply endorsement of any Modified Version.
+</para>
+   </section><section><title>5. COMBINING DOCUMENTS</title>
+<para>
+You may combine the Document with other documents released under this
+License, under the terms defined in section 4 above for modified
+versions, provided that you include in the combination all of the
+Invariant Sections of all of the original documents, unmodified, and
+list them all as Invariant Sections of your combined work in its
+license notice, and that you preserve all their Warranty Disclaimers.
+</para><para>
+The combined work need only contain one copy of this License, and
+multiple identical Invariant Sections may be replaced with a single
+copy.  If there are multiple Invariant Sections with the same name but
+different contents, make the title of each such section unique by
+adding at the end of it, in parentheses, the name of the original
+author or publisher of that section if known, or else a unique number.
+Make the same adjustment to the section titles in the list of
+Invariant Sections in the license notice of the combined work.
+</para><para>
+In the combination, you must combine any sections Entitled "History"
+in the various original documents, forming one section Entitled
+"History"; likewise combine any sections Entitled "Acknowledgements",
+and any sections Entitled "Dedications".  You must delete all sections
+Entitled "Endorsements".
+</para>
+   </section><section><title>6. COLLECTIONS OF DOCUMENTS</title>
+<para>
+You may make a collection consisting of the Document and other documents
+released under this License, and replace the individual copies of this
+License in the various documents with a single copy that is included in
+the collection, provided that you follow the rules of this License for
+verbatim copying of each of the documents in all other respects.
+</para><para>
+You may extract a single document from such a collection, and distribute
+it individually under this License, provided you insert a copy of this
+License into the extracted document, and follow this License in all
+other respects regarding verbatim copying of that document.
+</para>
+   </section><section><title>7. AGGREGATION WITH INDEPENDENT WORKS</title>
+<para>
+A compilation of the Document or its derivatives with other separate
+and independent documents or works, in or on a volume of a storage or
+distribution medium, is called an "aggregate" if the copyright
+resulting from the compilation is not used to limit the legal rights
+of the compilation's users beyond what the individual works permit.
+When the Document is included in an aggregate, this License does not
+apply to the other works in the aggregate which are not themselves
+derivative works of the Document.
+</para><para>
+If the Cover Text requirement of section 3 is applicable to these
+copies of the Document, then if the Document is less than one half of
+the entire aggregate, the Document's Cover Texts may be placed on
+covers that bracket the Document within the aggregate, or the
+electronic equivalent of covers if the Document is in electronic form.
+Otherwise they must appear on printed covers that bracket the whole
+aggregate.
+</para>
+   </section><section><title>8. TRANSLATION</title>
+<para>
+Translation is considered a kind of modification, so you may
+distribute translations of the Document under the terms of section 4.
+Replacing Invariant Sections with translations requires special
+permission from their copyright holders, but you may include
+translations of some or all Invariant Sections in addition to the
+original versions of these Invariant Sections.  You may include a
+translation of this License, and all the license notices in the
+Document, and any Warranty Disclaimers, provided that you also include
+the original English version of this License and the original versions
+of those notices and disclaimers.  In case of a disagreement between
+the translation and the original version of this License or a notice
+or disclaimer, the original version will prevail.
+</para><para>
+If a section in the Document is Entitled "Acknowledgements",
+"Dedications", or "History", the requirement (section 4) to Preserve
+its Title (section 1) will typically require changing the actual
+title.
+</para>
+   </section><section><title>9. TERMINATION</title>
+<para>
+You may not copy, modify, sublicense, or distribute the Document except
+as expressly provided for under this License.  Any other attempt to
+copy, modify, sublicense or distribute the Document is void, and will
+automatically terminate your rights under this License.  However,
+parties who have received copies, or rights, from you under this
+License will not have their licenses terminated so long as such
+parties remain in full compliance.
+</para>
+   </section><section><title>10. FUTURE REVISIONS OF THIS LICENSE</title>
+<para>
+The Free Software Foundation may publish new, revised versions
+of the GNU Free Documentation License from time to time.  Such new
+versions will be similar in spirit to the present version, but may
+differ in detail to address new problems or concerns.  See
+http://www.gnu.org/copyleft/.
+</para><para>
+Each version of the License is given a distinguishing version number.
+If the Document specifies that a particular numbered version of this
+License "or any later version" applies to it, you have the option of
+following the terms and conditions either of that specified version or
+of any later version that has been published (not as a draft) by the
+Free Software Foundation.  If the Document does not specify a version
+number of this License, you may choose any version ever published (not
+as a draft) by the Free Software Foundation.
+</para>
+   </section><section><title>G.1.1 ADDENDUM: How to use this License for your documents</title>
+<para>
+To use this License in a document you have written, include a copy of
+the License in the document and put the following copyright and
+license notices just after the title page:
+</para>
+<para><literallayout>
+    Copyright (c)  YEAR  YOUR NAME.
+    Permission is granted to copy, distribute and/or modify this document
+    under the terms of the GNU Free Documentation License, Version 1.2
+    or any later version published by the Free Software Foundation;
+    with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.
+    A copy of the license is included in the section entitled "GNU
+    Free Documentation License".
+</literallayout></para>
+<para>
+If you have Invariant Sections, Front-Cover Texts and Back-Cover Texts,
+replace the "with...Texts." line with this:
+</para>
+<para><literallayout>
+    with the Invariant Sections being LIST THEIR TITLES, with the
+    Front-Cover Texts being LIST, and with the Back-Cover Texts being LIST.
+</literallayout></para>
+<para>
+If you have Invariant Sections without Cover Texts, or some other
+combination of the three, merge those two alternatives to suit the
+situation.
+</para><para>
+If your document contains nontrivial examples of program code, we
+recommend releasing these examples in parallel under your choice of
+free software license, such as the GNU General Public License,
+to permit their use in free software.
+</para>
+</section>
+</section>

references/igraph-1.0.1/doc/flows.xxml

@@ -0,0 +1,48 @@
+<?xml version="1.0"?>
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN"
+               "http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd" [
+<!ENTITY igraph "igraph">
+]>
+
+<chapter id="igraph-Flows">
+<title>Maximum flows, minimum cuts and related measures</title>
+
+<section id="maximum-flows"><title>Maximum flows</title>
+<!-- doxrox-include igraph_maxflow -->
+<!-- doxrox-include igraph_maxflow_value -->
+<!-- doxrox-include igraph_dominator_tree -->
+<!-- doxrox-include igraph_maxflow_stats_t -->
+</section>
+
+<section id="cuts-and-minimum-cuts"><title>Cuts and minimum cuts</title>
+<!-- doxrox-include igraph_st_mincut -->
+<!-- doxrox-include igraph_st_mincut_value -->
+<!-- doxrox-include igraph_all_st_cuts -->
+<!-- doxrox-include igraph_all_st_mincuts -->
+<!-- doxrox-include igraph_mincut -->
+<!-- doxrox-include igraph_mincut_value -->
+<!-- doxrox-include igraph_gomory_hu_tree -->
+</section>
+
+<section id="connectivity"><title>Connectivity</title>
+<!-- doxrox-include igraph_st_edge_connectivity -->
+<!-- doxrox-include igraph_edge_connectivity -->
+<!-- doxrox-include igraph_st_vertex_connectivity -->
+<!-- doxrox-include igraph_vertex_connectivity -->
+</section>
+
+<section id="edge-and-vertex-disjoint-paths"><title>Edge- and vertex-disjoint paths</title>
+<!-- doxrox-include igraph_edge_disjoint_paths -->
+<!-- doxrox-include igraph_vertex_disjoint_paths -->
+</section>
+
+<section id="graph-adhesion-and-cohesion"><title>Graph adhesion and cohesion</title>
+<!-- doxrox-include igraph_adhesion -->
+<!-- doxrox-include igraph_cohesion -->
+</section>
+
+<section id="cohesive-blocks"><title>Cohesive blocks</title>
+<!-- doxrox-include igraph_cohesive_blocks -->
+</section>
+
+</chapter>

references/igraph-1.0.1/doc/foreign.xxml

@@ -0,0 +1,59 @@
+<?xml version="1.0"?>
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN"
+               "http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd" [
+<!ENTITY igraph "igraph">
+]>
+
+<chapter id="igraph-Foreign">
+<title>Reading and writing graphs from and to files</title>
+
+<!-- doxrox-include about_loadsave -->
+
+<section id="simple-edge-list-and-similar-formats"><title>Simple edge list and similar formats</title>
+<!-- doxrox-include igraph_read_graph_edgelist -->
+<!-- doxrox-include igraph_write_graph_edgelist -->
+<!-- doxrox-include igraph_read_graph_ncol -->
+<!-- doxrox-include igraph_write_graph_ncol -->
+<!-- doxrox-include igraph_read_graph_lgl -->
+<!-- doxrox-include igraph_write_graph_lgl -->
+<!-- doxrox-include igraph_read_graph_dimacs_flow -->
+<!-- doxrox-include igraph_write_graph_dimacs_flow -->
+</section>
+
+<section id="binary-formats"><title>Binary formats</title>
+<!-- doxrox-include igraph_read_graph_graphdb -->
+</section>
+
+<section id="graphml-format"><title>GraphML format</title>
+<!-- doxrox-include igraph_read_graph_graphml -->
+<!-- doxrox-include igraph_write_graph_graphml -->
+</section>
+
+<section id="gml-format"><title>GML format</title>
+<!-- doxrox-include igraph_read_graph_gml -->
+<!-- doxrox-include igraph_write_graph_gml -->
+</section>
+
+<section id="pajek-format"><title>Pajek format</title>
+<!-- doxrox-include igraph_read_graph_pajek -->
+<!-- doxrox-include igraph_write_graph_pajek -->
+</section>
+
+<section id="ucinets-dl-file-format"><title>UCINET's DL file format</title>
+<!-- doxrox-include igraph_read_graph_dl -->
+</section>
+
+<section id="graphviz-format"><title>Graphviz format</title>
+<!-- doxrox-include igraph_write_graph_dot -->
+</section>
+
+<section id="leda-format"><title>LEDA format</title>
+<!-- doxrox-include igraph_write_graph_leda -->
+</section>
+
+<section id="locale-helpers"><title>Convenience functions for locale change</title>
+<!-- doxrox-include igraph_enter_safelocale -->
+<!-- doxrox-include igraph_exit_safelocale -->
+</section>
+
+</chapter>

references/igraph-1.0.1/doc/games.xxml

@@ -0,0 +1,85 @@
+<?xml version="1.0"?>
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN"
+               "http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd" [
+<!ENTITY igraph "igraph">
+]>
+
+<chapter id="igraph-Games">
+<title>Stochastic graph generators ("games")</title>
+
+<para>"Games" are random graph generators, i.e. they generate a different
+graph every time they are called. igraph includes many such generators.
+Some implement stochastic graph construction processes inspired by real-world
+mechanics, such as preferential attachment, while others are designed to
+produce graphs with certain used properties (e.g. fixed number of edges,
+fixed degrees, etc.)</para>
+
+<section id="erdos-renyi-games"><title>The Erdős-Rényi and related models</title>
+<!-- doxrox-include about_erdos_renyi -->
+
+<!-- doxrox-include igraph_erdos_renyi_game_gnm -->
+<!-- doxrox-include igraph_erdos_renyi_game_gnp -->
+<!-- doxrox-include igraph_iea_game -->
+<!-- doxrox-include igraph_sbm_game -->
+<!-- doxrox-include igraph_hsbm_game -->
+<!-- doxrox-include igraph_hsbm_list_game -->
+<!-- doxrox-include igraph_preference_game -->
+<!-- doxrox-include igraph_asymmetric_preference_game -->
+<!-- doxrox-include igraph_correlated_game -->
+<!-- doxrox-include igraph_correlated_pair_game -->
+</section>
+
+<section id="preferential-attachment-games"><title>Preferential attachment and related models</title>
+<para>Preferential attachment models are growing random graphs where vertices are added iteratively,
+and connected to previously added vertices based on dynamically changing vertex properties, such as
+degree or time since the vertex was added.</para>
+
+<!-- doxrox-include igraph_barabasi_game -->
+<!-- doxrox-include igraph_barabasi_aging_game -->
+<!-- doxrox-include igraph_recent_degree_game -->
+<!-- doxrox-include igraph_recent_degree_aging_game -->
+<!-- doxrox-include igraph_lastcit_game -->
+</section>
+
+<section id="growing-random-games"><title>Growing random graph models</title>
+<para>In growing random graphs, vertices are added iteratively, and connected based on various rules.
+Preferential attachment models are documented <link linkend="preferential-attachment-games">in their
+own section</link>.
+</para>
+
+<!-- doxrox-include igraph_growing_random_game -->
+<!-- doxrox-include igraph_callaway_traits_game -->
+<!-- doxrox-include igraph_establishment_game -->
+<!-- doxrox-include igraph_cited_type_game -->
+<!-- doxrox-include igraph_citing_cited_type_game -->
+<!-- doxrox-include igraph_forest_fire_game -->
+</section>
+
+<section id="degree-constrained-games"><title>Degree-constrained models</title>
+<para>Random graph models with hard or soft degree constraints.</para>
+<!-- doxrox-include igraph_degree_sequence_game -->
+<!-- doxrox-include igraph_k_regular_game -->
+<!-- doxrox-include igraph_rewire -->
+<!-- doxrox-include igraph_chung_lu_game -->
+<!-- doxrox-include igraph_static_fitness_game -->
+<!-- doxrox-include igraph_static_power_law_game -->
+</section>
+
+<section id="edge-rewiring-games"><title>Edge rewiring models</title>
+<!-- doxrox-include igraph_watts_strogatz_game -->
+<!-- doxrox-include igraph_rewire_edges -->
+<!-- doxrox-include igraph_rewire_directed_edges -->
+</section>
+
+<section id="other-random-games"><title>Other random graphs</title>
+<!-- doxrox-include igraph_grg_game -->
+<!-- doxrox-include igraph_dot_product_game -->
+<!-- doxrox-include igraph_simple_interconnected_islands_game -->
+<!-- doxrox-include igraph_tree_game -->
+</section>
+
+<section id="generator-types-and-constants"><title>Common types and constants</title>
+<!-- doxrox-include igraph_edge_type_sw_t -->
+</section>
+
+</chapter>

references/igraph-1.0.1/doc/generators.xxml

@@ -0,0 +1,93 @@
+<?xml version="1.0"?>
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN"
+               "http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd" [
+<!ENTITY igraph "igraph">
+]>
+
+<chapter id="igraph-Generators">
+<title>Deterministic graph generators</title>
+
+<section id="about-generators"><title>About generators</title>
+<para>
+Most functions that create graphs in a deterministic manner are documented here. See also
+<link linkend="igraph-Games">stochastic generators</link>,
+<link linkend="spatial-generators">spatial graph generators</link>,
+<link linkend="create-two-mode-networks">bipartite graph generators</link>,
+and <link linkend="igraph-Operators">operators that transform graphs</link>.
+</para>
+</section>
+
+<section><title id="basic-generators">Basic graph creation</title>
+<!-- doxrox-include igraph_create -->
+<!-- doxrox-include igraph_small -->
+</section>
+
+<section id="adjacency-generators"><title>Graphs from adjacency matrices and adjacency lists</title>
+<para>These functions create graphs from weighted or unweighted adjacency matrices, or an adjacency list.</para>
+
+<!-- doxrox-include igraph_adjacency -->
+<!-- doxrox-include igraph_weighted_adjacency -->
+<!-- doxrox-include igraph_sparse_adjacency -->
+<!-- doxrox-include igraph_sparse_weighted_adjacency -->
+<!-- doxrox-include igraph_adjlist -->
+</section>
+
+<section id="regular-structre-generators"><title>Regular structures</title>
+<para>These functions produce various basic regular graph structures, such as paths, cycles or lattices.</para>
+
+<!-- doxrox-include igraph_star -->
+<!-- doxrox-include igraph_wheel -->
+<!-- doxrox-include igraph_hypercube -->
+<!-- doxrox-include igraph_square_lattice -->
+<!-- doxrox-include igraph_triangular_lattice -->
+<!-- doxrox-include igraph_hexagonal_lattice -->
+<!-- doxrox-include igraph_ring -->
+<!-- doxrox-include igraph_path_graph -->
+<!-- doxrox-include igraph_cycle_graph -->
+<!-- doxrox-include igraph_lcf -->
+<!-- doxrox-include igraph_lcf_small -->
+<!-- doxrox-include igraph_circulant -->
+<!-- doxrox-include igraph_extended_chordal_ring -->
+</section>
+
+<section id="tree-generators"><title>Tree generators</title>
+<para>These functions generate tree graphs.</para>
+
+<!-- doxrox-include igraph_kary_tree -->
+<!-- doxrox-include igraph_symmetric_tree -->
+<!-- doxrox-include igraph_regular_tree -->
+<!-- doxrox-include igraph_tree_from_parent_vector -->
+<!-- doxrox-include igraph_from_prufer -->
+</section>
+
+<section id="degree-graph-generators"><title>Graphs with given degrees</title>
+<para>These functions generate graphs with the specified degrees.</para>
+
+<!-- doxrox-include igraph_realize_degree_sequence -->
+<!-- doxrox-include igraph_realize_bipartite_degree_sequence -->
+</section>
+
+<section id="complete-graph-generators"><title>Complete graphs</title>
+<para>These functions produce single and multipartite complete graphs, as well as related graphs.</para>
+
+<!-- doxrox-include igraph_full -->
+<!-- doxrox-include igraph_full_citation -->
+<!-- doxrox-include igraph_full_multipartite -->
+<!-- doxrox-include igraph_turan -->
+</section>
+
+<section id="pre-defined-generators"><title>Pre-defined graphs</title>
+<para>These functions return graphs from various graph collections.</para>
+
+<!-- doxrox-include igraph_famous -->
+<!-- doxrox-include igraph_atlas -->
+</section>
+
+<section id="other-generators"><title>Other well-known graphs from graph theory</title>
+<!-- doxrox-include igraph_de_bruijn -->
+<!-- doxrox-include igraph_kautz -->
+<!-- doxrox-include igraph_generalized_petersen -->
+<!-- doxrox-include igraph_mycielski_graph -->
+</section>
+
+</chapter>

references/igraph-1.0.1/doc/glossary.md

@@ -0,0 +1,32 @@
+<!--
+  The glossary is generated from these Markdown sources using
+    pandoc glossary.md --to docbook > glossary.xml
+  and manually updated to fit into the documentation system.
+-->
+
+# Glossary
+
+This glossary defines common terms used throughout the igraph documentation.
+
+ - **attribute**: A piece of data associated with a vertex, an edge, or the graph itself. The igraph C library currently supports numeric, string and Boolean attribute values, and provides a means for implementing attribute handlers that support custom types.
+ - **adjacent**: Two vertices are called **adjacent** if there is an edge connecting them. This term describes a vertex-to-vertex relation.
+ - **adjacency list**: A data structure that associates a list of neighbours (i.e. adjacent vertices) to each vertex.
+ - **adjacency matrix**: A representation of a graph as a square matrix. `A_ij` gives the number of edge endpoints connecting from the `i`th vertex to the `j`th vertex. Conventionally, the diagonal of the adjacency matrix of an undirected graph contains _twice_ the number of self-loops. All igraph functions follow this convention unless noted otherwise.
+ - **biadjacency matrix**: Analogous to the adjacency matrix, but used for bipartite graphs. Element `B_ij` gives the number of edges from the `i`th vertex of the first group to the `j`th vertex of the second group.
+ - **bipartite graph**: A graph whose vertices can be partitioned into two groups in such a way that connections are present only between members of different groups.
+ - **complete graph**: Also called **full graph** within the context of igraph, a graph in which all pairs of vertices are connected to each other.
+ - **connected graph**: A connected graph consists of a single component, in which any vertex is reachable from any other. In igraph, the null graph is not considered connected, as it has not one, but zero components.
+ - **edge**: A **connection** between two vertices, also called a **link**. In igraph, edges are referred to by integer indices called **edge IDs**.
+ - **finalizer stack**: A global stack used internally by igraph to keep track of currently allocated objects and their destructors, so that they can be automatically destroyed in case of an error.
+ - **game**: Within igraph, this term is used for stochastic graph generators, i.e. functions that sample from random graph models.
+ - **graph** or **network**: A set of vertices with connections between them. In igraph, graphs may carry associated data in the form of vertex, edge or graph attributes.
+ - **incident**: An edge is called **incident** to the vertices that are its endpoints. This term describes a vertex-to-edge relation.
+ - **incidence list**: A data structure that associates a list of incident edges to each vertex.
+ - **incidence matrix**: A matrix describing the incidence relation between vertices (rows) and edges (columns).
+ - **membership vector**: Membership vectors are a means of encoding a partitioning of items, usually vertices, into several groups. The `i`th element of the vector gives an integer identifier of the group the `i`th vertex belongs to. Membership vectors are typically used to describe a vertex clustering obtained through community detection, or by identifying the connected components of a graph.
+ - **multi-edges** or **parallel edges**: More than one edge connecting the same two vertices. In a directed graph, `a -> b, a -> b` are considered parallel edges, but `a -> b, a <- b` are not.
+ - **null graph**: A graph with no vertices (and no edges).
+ - **self-loop**, **self-edge**, or simply **loop**: An edge that connects a vertex to itself.
+ - **simple graph**: A graph that does not have self-loops or multi-edges.
+ - **singleton graph**: A graph having a single vertex. This term usually refers to a single vertex with no edges, but note that self-loops may in principle be present.
+ - **vertex**: Graphs consist of vertices, also called **nodes**, that are connected to each other. In igraph, vertices are referred to by integer indices called **vertex IDs**.

references/igraph-1.0.1/doc/glossary.xml

@@ -0,0 +1,197 @@
+<?xml version="1.0"?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN"
+               "http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd" [
+]>
+
+<!-- Do not edit this file directly. Edit glossary.md and re-generate this file using pandoc. -->
+
+<chapter id="igraph-Glossary">
+  <title>Glossary</title>
+  <para>
+    This glossary defines common terms used throughout the igraph
+    documentation.
+  </para>
+  <itemizedlist spacing="compact">
+    <listitem>
+      <para>
+        <emphasis role="strong">attribute</emphasis>: A piece of data
+        associated with a vertex, an edge, or the graph itself. The
+        igraph C library currently supports numeric, string and Boolean
+        attribute values, and provides a means for implementing
+        attribute handlers that support custom types.
+      </para>
+    </listitem>
+    <listitem>
+      <para>
+        <emphasis role="strong">adjacent</emphasis>: Two vertices are
+        called <emphasis role="strong">adjacent</emphasis> if there is
+        an edge connecting them. This term describes a vertex-to-vertex
+        relation.
+      </para>
+    </listitem>
+    <listitem>
+      <para>
+        <emphasis role="strong">adjacency list</emphasis>: A data
+        structure that associates a list of neighbours (i.e. adjacent
+        vertices) to each vertex.
+      </para>
+    </listitem>
+    <listitem>
+      <para>
+        <emphasis role="strong">adjacency matrix</emphasis>: A
+        representation of a graph as a square matrix.
+        <literal>A_ij</literal> gives the number of edge endpoints
+        connecting from the <literal>i</literal>th vertex to the
+        <literal>j</literal>th vertex. Conventionally, the diagonal of
+        the adjacency matrix of an undirected graph contains
+        <emphasis>twice</emphasis> the number of self-loops. All igraph
+        functions follow this convention unless noted otherwise.
+      </para>
+    </listitem>
+    <listitem>
+      <para>
+        <emphasis role="strong">biadjacency matrix</emphasis>: Analogous
+        to the adjacency matrix, but used for bipartite graphs. Element
+        <literal>B_ij</literal> gives the number of edges from the
+        <literal>i</literal>th vertex of the first group to the
+        <literal>j</literal>th vertex of the second group.
+      </para>
+    </listitem>
+    <listitem>
+      <para>
+        <emphasis role="strong">bipartite graph</emphasis>: A graph
+        whose vertices can be partitioned into two groups in such a way
+        that connections are present only between members of different
+        groups.
+      </para>
+    </listitem>
+    <listitem>
+      <para>
+        <emphasis role="strong">complete graph</emphasis>: Also called
+        <emphasis role="strong">full graph</emphasis> within the context
+        of igraph, a graph in which all pairs of vertices are connected
+        to each other.
+      </para>
+    </listitem>
+    <listitem>
+      <para>
+        <emphasis role="strong">connected graph</emphasis>: A connected
+        graph consists of a single component, in which any vertex is
+        reachable from any other. In igraph, the null graph is not
+        considered connected, as it has not one, but zero components.
+      </para>
+    </listitem>
+    <listitem>
+      <para>
+        <emphasis role="strong">edge</emphasis>: A
+        <emphasis role="strong">connection</emphasis> between two
+        vertices, also called a <emphasis role="strong">link</emphasis>.
+        In igraph, edges are referred to by integer indices called
+        <emphasis role="strong">edge IDs</emphasis>.
+      </para>
+    </listitem>
+    <listitem>
+      <para>
+        <emphasis role="strong">finalizer stack</emphasis>: A global
+        stack used internally by igraph to keep track of currently
+        allocated objects and their destructors, so that they can be
+        automatically destroyed in case of an error.
+      </para>
+    </listitem>
+    <listitem>
+      <para>
+        <emphasis role="strong">game</emphasis>: Within igraph, this
+        term is used for stochastic graph generators, i.e. functions
+        that sample from random graph models.
+      </para>
+    </listitem>
+    <listitem>
+      <para>
+        <emphasis role="strong">graph</emphasis> or
+        <emphasis role="strong">network</emphasis>: A set of vertices
+        with connections between them. In igraph, graphs may carry
+        associated data in the form of vertex, edge or graph attributes.
+      </para>
+    </listitem>
+    <listitem>
+      <para>
+        <emphasis role="strong">incident</emphasis>: An edge is called
+        <emphasis role="strong">incident</emphasis> to the vertices that
+        are its endpoints. This term describes a vertex-to-edge
+        relation.
+      </para>
+    </listitem>
+    <listitem>
+      <para>
+        <emphasis role="strong">incidence list</emphasis>: A data
+        structure that associates a list of incident edges to each
+        vertex.
+      </para>
+    </listitem>
+    <listitem>
+      <para>
+        <emphasis role="strong">incidence matrix</emphasis>: A matrix
+        describing the incidence relation between vertices (rows) and
+        edges (columns).
+      </para>
+    </listitem>
+    <listitem>
+      <para>
+        <emphasis role="strong">membership vector</emphasis>: Membership
+        vectors are a means of encoding a partitioning of items, usually
+        vertices, into several groups. The <literal>i</literal>th
+        element of the vector gives an integer identifier of the group
+        the <literal>i</literal>th vertex belongs to. Membership vectors
+        are typically used to describe a vertex clustering obtained
+        through community detection, or by identifying the connected
+        components of a graph.
+      </para>
+    </listitem>
+    <listitem>
+      <para>
+        <emphasis role="strong">multi-edges</emphasis> or
+        <emphasis role="strong">parallel edges</emphasis>: More than one
+        edge connecting the same two vertices. In a directed graph,
+        <literal>a -&gt; b, a -&gt; b</literal> are considered parallel
+        edges, but <literal>a -&gt; b, a &lt;- b</literal> are not.
+      </para>
+    </listitem>
+    <listitem>
+      <para>
+        <emphasis role="strong">null graph</emphasis>: A graph with no
+        vertices (and no edges).
+      </para>
+    </listitem>
+    <listitem>
+      <para>
+        <emphasis role="strong">self-loop</emphasis>,
+        <emphasis role="strong">self-edge</emphasis>, or simply
+        <emphasis role="strong">loop</emphasis>: An edge that connects a
+        vertex to itself.
+      </para>
+    </listitem>
+    <listitem>
+      <para>
+        <emphasis role="strong">simple graph</emphasis>: A graph that
+        does not have self-loops or multi-edges.
+      </para>
+    </listitem>
+    <listitem>
+      <para>
+        <emphasis role="strong">singleton graph</emphasis>: A graph
+        having a single vertex. This term usually refers to a single
+        vertex with no edges, but note that self-loops may in principle
+        be present.
+      </para>
+    </listitem>
+    <listitem>
+      <para>
+        <emphasis role="strong">vertex</emphasis>: Graphs consist of
+        vertices, also called <emphasis role="strong">nodes</emphasis>,
+        that are connected to each other. In igraph, vertices are
+        referred to by integer indices called
+        <emphasis role="strong">vertex IDs</emphasis>.
+      </para>
+    </listitem>
+  </itemizedlist>
+</chapter>

references/igraph-1.0.1/doc/gpl.xml

@@ -0,0 +1,444 @@
+<?xml version="1.0"?>
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN"
+               "http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd">
+<section id="igraph-gpl">
+  <sectioninfo>
+    <edition>Version 2, June 1991</edition>
+    <copyright><year>1989</year><year>1991</year>
+    <holder> Free Software Foundation, Inc.
+       51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
+    </holder>
+    </copyright>
+    <legalnotice><para>
+    Everyone is permitted to copy and distribute verbatim copies
+    of this license document, but changing it is not allowed.
+    </para></legalnotice>
+  </sectioninfo>
+
+<title>THE GNU GENERAL PUBLIC LICENSE</title>
+<section><title>Preamble</title>
+
+<para>
+  The licenses for most software are designed to take away your
+freedom to share and change it.  By contrast, the GNU General Public
+License is intended to guarantee your freedom to share and change free
+software--to make sure the software is free for all its users.  This
+General Public License applies to most of the Free Software
+Foundation's software and to any other program whose authors commit to
+using it.  (Some other Free Software Foundation software is covered by
+the GNU Library General Public License instead.)  You can apply it to
+your programs, too.
+</para>
+
+<para>
+  When we speak of free software, we are referring to freedom, not
+price.  Our General Public Licenses are designed to make sure that you
+have the freedom to distribute copies of free software (and charge for
+this service if you wish), that you receive source code or can get it
+if you want it, that you can change the software or use pieces of it
+in new free programs; and that you know you can do these things.
+</para>
+
+<para>
+  To protect your rights, we need to make restrictions that forbid
+anyone to deny you these rights or to ask you to surrender the rights.
+These restrictions translate to certain responsibilities for you if you
+distribute copies of the software, or if you modify it.
+</para>
+
+<para>
+  For example, if you distribute copies of such a program, whether
+gratis or for a fee, you must give the recipients all the rights that
+you have.  You must make sure that they, too, receive or can get the
+source code.  And you must show them these terms so they know their
+rights.
+</para>
+
+<para>
+  We protect your rights with two steps: (1) copyright the software, and
+(2) offer you this license which gives you legal permission to copy,
+distribute and/or modify the software.
+</para>
+
+<para>
+  Also, for each author's protection and ours, we want to make certain
+that everyone understands that there is no warranty for this free
+software.  If the software is modified by someone else and passed on, we
+want its recipients to know that what they have is not the original, so
+that any problems introduced by others will not reflect on the original
+authors' reputations.
+</para>
+
+<para>
+  Finally, any free program is threatened constantly by software
+patents.  We wish to avoid the danger that redistributors of a free
+program will individually obtain patent licenses, in effect making the
+program proprietary.  To prevent this, we have made it clear that any
+patent must be licensed for everyone's free use or not licensed at all.
+</para>
+
+<para>
+  The precise terms and conditions for copying, distribution and
+modification follow.
+</para>
+
+</section>
+<section id="sectiongpl"><title>GNU GENERAL PUBLIC LICENSE</title>
+<subtitle>TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION</subtitle>
+
+<para>
+  0. This License applies to any program or other work which contains
+a notice placed by the copyright holder saying it may be distributed
+under the terms of this General Public License.  The "Program", below,
+refers to any such program or work, and a "work based on the Program"
+means either the Program or any derivative work under copyright law:
+that is to say, a work containing the Program or a portion of it,
+either verbatim or with modifications and/or translated into another
+language.  (Hereinafter, translation is included without limitation in
+the term "modification".)  Each licensee is addressed as "you".
+</para>
+
+<para>
+Activities other than copying, distribution and modification are not
+covered by this License; they are outside its scope.  The act of
+running the Program is not restricted, and the output from the Program
+is covered only if its contents constitute a work based on the
+Program (independent of having been made by running the Program).
+Whether that is true depends on what the Program does.
+</para>
+
+<para>
+  1. You may copy and distribute verbatim copies of the Program's
+source code as you receive it, in any medium, provided that you
+conspicuously and appropriately publish on each copy an appropriate
+copyright notice and disclaimer of warranty; keep intact all the
+notices that refer to this License and to the absence of any warranty;
+and give any other recipients of the Program a copy of this License
+along with the Program.
+</para>
+
+<para>
+You may charge a fee for the physical act of transferring a copy, and
+you may at your option offer warranty protection in exchange for a fee.
+</para>
+
+<para>
+  2. You may modify your copy or copies of the Program or any portion
+of it, thus forming a work based on the Program, and copy and
+distribute such modifications or work under the terms of Section 1
+above, provided that you also meet all of these conditions:
+</para>
+<orderedlist numeration="loweralpha"><listitem><para>
+    You must cause the modified files to carry prominent notices
+    stating that you changed the files and the date of any change.
+  </para></listitem><listitem><para>
+    You must cause any work that you distribute or publish, that in
+    whole or in part contains or is derived from the Program or any
+    part thereof, to be licensed as a whole at no charge to all third
+    parties under the terms of this License.
+  </para></listitem><listitem><para>
+    If the modified program normally reads commands interactively
+    when run, you must cause it, when started running for such
+    interactive use in the most ordinary way, to print or display an
+    announcement including an appropriate copyright notice and a
+    notice that there is no warranty (or else, saying that you provide
+    a warranty) and that users may redistribute the program under
+    these conditions, and telling the user how to view a copy of this
+    License.  (Exception: if the Program itself is interactive but
+    does not normally print such an announcement, your work based on
+    the Program is not required to print an announcement.)
+  </para></listitem></orderedlist>
+
+<para>
+These requirements apply to the modified work as a whole.  If
+identifiable sections of that work are not derived from the Program,
+and can be reasonably considered independent and separate works in
+themselves, then this License, and its terms, do not apply to those
+sections when you distribute them as separate works.  But when you
+distribute the same sections as part of a whole which is a work based
+on the Program, the distribution of the whole must be on the terms of
+this License, whose permissions for other licensees extend to the
+entire whole, and thus to each and every part regardless of who wrote it.
+</para>
+
+<para>
+Thus, it is not the intent of this section to claim rights or contest
+your rights to work written entirely by you; rather, the intent is to
+exercise the right to control the distribution of derivative or
+collective works based on the Program.
+</para>
+
+<para>
+In addition, mere aggregation of another work not based on the Program
+with the Program (or with a work based on the Program) on a volume of
+a storage or distribution medium does not bring the other work under
+the scope of this License.
+</para>
+
+<para>
+  3. You may copy and distribute the Program (or a work based on it,
+under Section 2) in object code or executable form under the terms of
+Sections 1 and 2 above provided that you also do one of the following:
+</para>
+
+<orderedlist numeration="loweralpha"><listitem><para>
+    Accompany it with the complete corresponding machine-readable
+    source code, which must be distributed under the terms of Sections
+    1 and 2 above on a medium customarily used for software interchange; or,
+</para></listitem><listitem><para>
+    Accompany it with a written offer, valid for at least three
+    years, to give any third party, for a charge no more than your
+    cost of physically performing source distribution, a complete
+    machine-readable copy of the corresponding source code, to be
+    distributed under the terms of Sections 1 and 2 above on a medium
+    customarily used for software interchange; or,
+</para></listitem><listitem><para>
+    Accompany it with the information you received as to the offer
+    to distribute corresponding source code.  (This alternative is
+    allowed only for noncommercial distribution and only if you
+    received the program in object code or executable form with such
+    an offer, in accord with Subsection b above.)
+</para></listitem></orderedlist>
+
+<para>
+The source code for a work means the preferred form of the work for
+making modifications to it.  For an executable work, complete source
+code means all the source code for all modules it contains, plus any
+associated interface definition files, plus the scripts used to
+control compilation and installation of the executable.  However, as a
+special exception, the source code distributed need not include
+anything that is normally distributed (in either source or binary
+form) with the major components (compiler, kernel, and so on) of the
+operating system on which the executable runs, unless that component
+itself accompanies the executable.
+</para>
+
+<para>
+If distribution of executable or object code is made by offering
+access to copy from a designated place, then offering equivalent
+access to copy the source code from the same place counts as
+distribution of the source code, even though third parties are not
+compelled to copy the source along with the object code.
+</para>
+
+<para>
+  4. You may not copy, modify, sublicense, or distribute the Program
+except as expressly provided under this License.  Any attempt
+otherwise to copy, modify, sublicense or distribute the Program is
+void, and will automatically terminate your rights under this License.
+However, parties who have received copies, or rights, from you under
+this License will not have their licenses terminated so long as such
+parties remain in full compliance.
+</para>
+
+<para>
+  5. You are not required to accept this License, since you have not
+signed it.  However, nothing else grants you permission to modify or
+distribute the Program or its derivative works.  These actions are
+prohibited by law if you do not accept this License.  Therefore, by
+modifying or distributing the Program (or any work based on the
+Program), you indicate your acceptance of this License to do so, and
+all its terms and conditions for copying, distributing or modifying
+the Program or works based on it.
+</para>
+
+<para>
+  6. Each time you redistribute the Program (or any work based on the
+Program), the recipient automatically receives a license from the
+original licensor to copy, distribute or modify the Program subject to
+these terms and conditions.  You may not impose any further
+restrictions on the recipients' exercise of the rights granted herein.
+You are not responsible for enforcing compliance by third parties to
+this License.
+</para>
+
+<para>
+  7. If, as a consequence of a court judgment or allegation of patent
+infringement or for any other reason (not limited to patent issues),
+conditions are imposed on you (whether by court order, agreement or
+otherwise) that contradict the conditions of this License, they do not
+excuse you from the conditions of this License.  If you cannot
+distribute so as to satisfy simultaneously your obligations under this
+License and any other pertinent obligations, then as a consequence you
+may not distribute the Program at all.  For example, if a patent
+license would not permit royalty-free redistribution of the Program by
+all those who receive copies directly or indirectly through you, then
+the only way you could satisfy both it and this License would be to
+refrain entirely from distribution of the Program.
+</para>
+
+<para>
+If any portion of this section is held invalid or unenforceable under
+any particular circumstance, the balance of the section is intended to
+apply and the section as a whole is intended to apply in other
+circumstances.
+</para>
+
+<para>
+It is not the purpose of this section to induce you to infringe any
+patents or other property right claims or to contest validity of any
+such claims; this section has the sole purpose of protecting the
+integrity of the free software distribution system, which is
+implemented by public license practices.  Many people have made
+generous contributions to the wide range of software distributed
+through that system in reliance on consistent application of that
+system; it is up to the author/donor to decide if he or she is willing
+to distribute software through any other system and a licensee cannot
+impose that choice.
+</para>
+
+<para>
+This section is intended to make thoroughly clear what is believed to
+be a consequence of the rest of this License.
+</para>
+
+<para>
+  8. If the distribution and/or use of the Program is restricted in
+certain countries either by patents or by copyrighted interfaces, the
+original copyright holder who places the Program under this License
+may add an explicit geographical distribution limitation excluding
+those countries, so that distribution is permitted only in or among
+countries not thus excluded.  In such case, this License incorporates
+the limitation as if written in the body of this License.
+</para>
+
+<para>
+  9. The Free Software Foundation may publish revised and/or new versions
+of the General Public License from time to time.  Such new versions will
+be similar in spirit to the present version, but may differ in detail to
+address new problems or concerns.
+</para>
+
+<para>
+Each version is given a distinguishing version number.  If the Program
+specifies a version number of this License which applies to it and "any
+later version", you have the option of following the terms and conditions
+either of that version or of any later version published by the Free
+Software Foundation.  If the Program does not specify a version number of
+this License, you may choose any version ever published by the Free Software
+Foundation.
+</para>
+
+<para>
+  10. If you wish to incorporate parts of the Program into other free
+programs whose distribution conditions are different, write to the author
+to ask for permission.  For software which is copyrighted by the Free
+Software Foundation, write to the Free Software Foundation; we sometimes
+make exceptions for this.  Our decision will be guided by the two goals
+of preserving the free status of all derivatives of our free software and
+of promoting the sharing and reuse of software generally.
+</para>
+<para>
+                            NO WARRANTY
+</para>
+
+<para>
+  11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY
+FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW.  EXCEPT WHEN
+OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES
+PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED
+OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.  THE ENTIRE RISK AS
+TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU.  SHOULD THE
+PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING,
+REPAIR OR CORRECTION.
+</para>
+
+<para>
+  12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
+WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR
+REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES,
+INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING
+OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED
+TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY
+YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER
+PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE
+POSSIBILITY OF SUCH DAMAGES.
+</para>
+
+<para>
+                     END OF TERMS AND CONDITIONS
+</para>
+
+</section>
+<section><title>How to Apply These Terms to Your New Programs</title>
+
+<para>
+  If you develop a new program, and you want it to be of the greatest
+possible use to the public, the best way to achieve this is to make it
+free software which everyone can redistribute and change under these terms.
+</para>
+
+<para>
+  To do so, attach the following notices to the program.  It is safest
+to attach them to the start of each source file to most effectively
+convey the exclusion of warranty; and each file should have at least
+the "copyright" line and a pointer to where the full notice is found.
+</para>
+
+<para><literallayout>
+    &lt;one line to give the program's name and a brief idea of what it does.>
+    Copyright (C) &lt;year>  &lt;name of author>
+
+    This program is free software; you can redistribute it and/or modify
+    it under the terms of the GNU General Public License as published by
+    the Free Software Foundation; either version 2 of the License, or
+    (at your option) any later version.
+
+    This program is distributed in the hope that it will be useful,
+    but WITHOUT ANY WARRANTY; without even the implied warranty of
+    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+    GNU General Public License for more details.
+
+    You should have received a copy of the GNU General Public License
+    along with this program; if not, write to the Free Software
+    Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+</literallayout></para>
+
+<para>
+Also add information on how to contact you by electronic and paper mail.
+</para>
+
+<para>
+If the program is interactive, make it output a short notice like this
+when it starts in an interactive mode:
+</para>
+
+<para><literallayout>
+    Gnomovision version 69, Copyright (C) year name of author
+    Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'.
+    This is free software, and you are welcome to redistribute it
+    under certain conditions; type `show c' for details.
+</literallayout></para>
+
+<para>
+The hypothetical commands `show w' and `show c' should show the appropriate
+parts of the General Public License.  Of course, the commands you use may
+be called something other than `show w' and `show c'; they could even be
+mouse-clicks or menu items--whatever suits your program.
+</para>
+
+<para>
+You should also get your employer (if you work as a programmer) or your
+school, if any, to sign a "copyright disclaimer" for the program, if
+necessary.  Here is a sample; alter the names:
+</para>
+
+<para><literallayout>
+  Yoyodyne, Inc., hereby disclaims all copyright interest in the program
+  `Gnomovision' (which makes passes at compilers) written by James Hacker.
+
+  &lt;signature of Ty Coon>, 1 April 1989
+  Ty Coon, President of Vice
+</literallayout></para>
+
+<para>
+This General Public License does not permit incorporating your program into
+proprietary programs.  If your program is a subroutine library, you may
+consider it more useful to permit linking proprietary applications with the
+library.  If this is what you want to do, use the GNU Library General
+Public License instead of this License.
+</para>
+
+</section>
+</section>

references/igraph-1.0.1/doc/graphlets.xxml

@@ -0,0 +1,20 @@
+<?xml version="1.0"?>
+<!DOCTYPE section PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN"
+               "http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd" [
+<!ENTITY igraph "igraph">
+]>
+
+<chapter id="igraph-Graphlets">
+<title>Graphlets</title>
+
+<section id="about-graphlets">
+<!-- doxrox-include graphlets_intro -->
+</section>
+
+<section id="performing-graphlet-decomposition"><title>Performing graphlet decomposition</title>
+<!-- doxrox-include igraph_graphlets -->
+<!-- doxrox-include igraph_graphlets_candidate_basis -->
+<!-- doxrox-include igraph_graphlets_project -->
+</section>
+
+</chapter>

references/igraph-1.0.1/doc/gtk-doc.xsl

@@ -0,0 +1,342 @@
+<?xml version='1.0'?> <!--*- mode: xml -*-->
+<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
+                version="1.0">
+
+  <!-- import the chunked XSL stylesheet -->
+  <xsl:import href="http://docbook.sourceforge.net/release/xsl/current/html/chunk.xsl"/>
+  <xsl:include href="version-greater-or-equal.xsl"/>
+
+  <!-- change some parameters -->
+  <xsl:param name="bibliography.collection">bibdatabase.xml</xsl:param>
+  <xsl:param name="bibliography.numbered">1</xsl:param>
+  <xsl:param name="toc.section.depth">0</xsl:param>
+  <xsl:param name="generate.section.toc.level">2</xsl:param>
+  <xsl:param name="generate.toc">
+    book        toc
+    chapter     toc
+    section     toc
+  </xsl:param>
+
+  <xsl:param name="default.encoding" select="'US-ASCII'"/>
+  <xsl:param name="chunker.output.encoding" select="'US-ASCII'"/>
+  <xsl:param name="chunker.output.indent" select="'yes'"/>
+  <xsl:param name="chunk.fast" select="1"/>
+  <xsl:param name="chunk.section.depth" select="0"/>
+  <xsl:param name="chunk.first.sections" select="0"/>
+  <xsl:param name="chapter.autolabel" select="1"/>
+  <xsl:param name="section.autolabel" select="1"/>
+  <xsl:param name="use.id.as.filename" select="1"/>
+  <xsl:param name="html.ext" select="'.html'"/>
+  <xsl:param name="refentry.generate.name" select="0"/>
+  <xsl:param name="refentry.generate.title" select="1"/>
+
+  <!-- use index filtering (if available) -->
+  <xsl:param name="index.on.role" select="1"/>
+
+  <!-- display variablelists as tables -->
+  <xsl:param name="variablelist.as.table" select="1"/>
+
+  <!-- this gets set on the command line ... -->
+  <xsl:param name="gtkdoc.version" select="''"/>
+  <xsl:param name="gtkdoc.bookname" select="''"/>
+
+  <!-- generate consistent IDs so permalinks and bookmarks stay useful when a
+       new igraph version is released -->
+  <xsl:param name="generate.consistent.ids" select="1"/>
+
+  <!-- ========================================================= -->
+  <!-- template to create the index.sgml anchor index -->
+
+  <xsl:template match="book|article">
+    <xsl:variable name="tooldver">
+      <xsl:call-template name="version-greater-or-equal">
+        <xsl:with-param name="ver1" select="$VERSION" />
+        <xsl:with-param name="ver2">1.36</xsl:with-param>
+      </xsl:call-template>
+    </xsl:variable>
+    <xsl:if test="$tooldver = 0">
+      <xsl:message terminate="yes">
+FATAL-ERROR: You need the DocBook XSL Stylesheets version 1.36 or higher
+to build the documentation.
+Get a newer version at http://docbook.sourceforge.net/projects/xsl/
+      </xsl:message>
+    </xsl:if>
+    <xsl:apply-imports/>
+
+  </xsl:template>
+
+  <!-- ========================================================= -->
+  <!-- template to output gtkdoclink elements for the unknown targets -->
+
+  <xsl:template match="link">
+    <xsl:choose>
+      <xsl:when test="id(@linkend)">
+        <xsl:apply-imports/>
+      </xsl:when>
+      <xsl:otherwise>
+        <GTKDOCLINK HREF="{@linkend}">
+          <xsl:apply-templates/>
+        </GTKDOCLINK>
+      </xsl:otherwise>
+    </xsl:choose>
+  </xsl:template>
+
+  <!-- ========================================================= -->
+  <!-- Below are the visual portions of the stylesheet.  They provide
+       the normal gtk-doc output style. -->
+
+  <xsl:param name="shade.verbatim" select="0"/>
+  <xsl:param name="refentry.separator" select="0"/>
+
+  <xsl:template match="refsection">
+    <xsl:if test="preceding-sibling::refsection">
+      <hr/>
+    </xsl:if>
+    <xsl:apply-imports/>
+  </xsl:template>
+
+  <xsl:template name="user.head.content">
+    <script type="text/javascript" src="toggle.js"></script>
+    <xsl:if test="$gtkdoc.version">
+      <meta name="generator"
+            content="GTK-Doc V{$gtkdoc.version} (XML mode)"/>
+    </xsl:if>
+    <link rel="stylesheet" href="style.css" type="text/css"/>
+	<link rel="stylesheet" href="https://stackpath.bootstrapcdn.com/font-awesome/4.7.0/css/font-awesome.min.css" type="text/css"/>
+
+      <!-- copied from the html.head template in the docbook stylesheets
+           we don't want links for all refentrys, thats just too much
+        -->
+      <xsl:variable name="this" select="."/>
+      <xsl:for-each select="//part
+                            |//reference
+                            |//preface
+                            |//chapter
+                            |//article
+                            |//appendix[not(parent::article)]|appendix
+                            |//glossary[not(parent::article)]|glossary
+                            |//index[not(parent::article)]|index">
+        <link rel="{local-name(.)}">
+          <xsl:attribute name="href">
+            <xsl:call-template name="href.target">
+              <xsl:with-param name="context" select="$this"/>
+              <xsl:with-param name="object" select="."/>
+            </xsl:call-template>
+          </xsl:attribute>
+          <xsl:attribute name="title">
+            <xsl:apply-templates select="." mode="object.title.markup.textonly"/>
+          </xsl:attribute>
+        </link>
+      </xsl:for-each>
+  </xsl:template>
+
+  <xsl:template match="title" mode="book.titlepage.recto.mode">
+  </xsl:template>
+
+  <xsl:template name="header.navigation">
+    <xsl:param name="prev" select="/foo"/>
+    <xsl:param name="next" select="/foo"/>
+    <xsl:variable name="home" select="/*[1]"/>
+    <xsl:variable name="up" select="parent::*"/>
+
+    <xsl:if test="$suppress.navigation = '0' and $home != .">
+      <div class="navigation-header mb-4" width="100%"
+           summary = "Navigation header">
+        <div class="btn-group">
+          <xsl:if test="count($prev) > 0">
+            <a accesskey="p" class="btn btn-light">
+              <xsl:attribute name="href">
+                <xsl:call-template name="href.target">
+                  <xsl:with-param name="object" select="$prev"/>
+                </xsl:call-template>
+              </xsl:attribute>
+              <i class="fa fa-chevron-left"></i>
+              Previous
+            </a>
+          </xsl:if>
+          <xsl:if test="count($up) > 0 and $up != $home">
+            <a accesskey="u" class="btn btn-light">
+              <xsl:attribute name="href">
+                <xsl:call-template name="href.target">
+                  <xsl:with-param name="object" select="$up"/>
+                </xsl:call-template>
+              </xsl:attribute>
+              <i class="fa fa-chevron-up"></i>
+              Up
+            </a>
+          </xsl:if>
+          <xsl:if test="$home != .">
+            <a accesskey="h" class="btn btn-light">
+              <xsl:attribute name="href">
+                <xsl:call-template name="href.target">
+                  <xsl:with-param name="object" select="$home"/>
+                </xsl:call-template>
+              </xsl:attribute>
+              <i class="fa fa-home"></i>
+              Home
+            </a>
+          </xsl:if>
+          <xsl:if test="count($next) > 0">
+            <a accesskey="n" class="btn btn-light">
+              <xsl:attribute name="href">
+                <xsl:call-template name="href.target">
+                  <xsl:with-param name="object" select="$next"/>
+                </xsl:call-template>
+              </xsl:attribute>
+              <i class="fa fa-chevron-right"></i>
+              Next
+            </a>
+          </xsl:if>
+        </div>
+      </div>
+    </xsl:if>
+  </xsl:template>
+
+  <xsl:template name="footer.navigation">
+    <xsl:param name="prev" select="/foo"/>
+    <xsl:param name="next" select="/foo"/>
+
+    <xsl:if test="$suppress.navigation = '0'">
+      <table class="navigation-footer" width="100%"
+             summary="Navigation footer" cellpadding="2" cellspacing="0">
+        <tr valign="middle">
+          <td align="left">
+            <xsl:if test="count($prev) > 0">
+              <a accesskey="p">
+                <xsl:attribute name="href">
+                  <xsl:call-template name="href.target">
+                    <xsl:with-param name="object" select="$prev"/>
+                  </xsl:call-template>
+                </xsl:attribute>
+                <b>
+                  <xsl:text>&#8592;&#160;</xsl:text>
+                  <xsl:apply-templates select="$prev"
+                                       mode="object.title.markup"/>
+                </b>
+              </a>
+            </xsl:if>
+          </td>
+          <td align="right">
+            <xsl:if test="count($next) > 0">
+              <a accesskey="n">
+                <xsl:attribute name="href">
+                  <xsl:call-template name="href.target">
+                    <xsl:with-param name="object" select="$next"/>
+                  </xsl:call-template>
+                </xsl:attribute>
+                <b>
+                  <xsl:apply-templates select="$next"
+                                       mode="object.title.markup"/>
+                  <xsl:text>&#160;&#8594;</xsl:text>
+                </b>
+              </a>
+            </xsl:if>
+          </td>
+        </tr>
+      </table>
+    </xsl:if>
+  </xsl:template>
+
+  <xsl:template name="user.footer.content">
+  </xsl:template>
+
+  <!-- avoid creating multiple identical indices
+       if the stylesheets don't support filtered indices
+    -->
+  <xsl:template match="index">
+    <xsl:variable name="has-filtered-index">
+      <xsl:call-template name="version-greater-or-equal">
+        <xsl:with-param name="ver1" select="$VERSION" />
+        <xsl:with-param name="ver2">1.66</xsl:with-param>
+      </xsl:call-template>
+    </xsl:variable>
+    <xsl:if test="($has-filtered-index = 1) or (count(@role) = 0)">
+      <xsl:apply-imports/>
+    </xsl:if>
+  </xsl:template>
+
+  <xsl:template match="index" mode="toc">
+    <xsl:variable name="has-filtered-index">
+      <xsl:call-template name="version-greater-or-equal">
+        <xsl:with-param name="ver1" select="$VERSION" />
+        <xsl:with-param name="ver2">1.66</xsl:with-param>
+      </xsl:call-template>
+    </xsl:variable>
+    <xsl:if test="($has-filtered-index = 1) or (count(@role) = 0)">
+      <xsl:apply-imports/>
+    </xsl:if>
+  </xsl:template>
+
+  <xsl:template match="para">
+    <xsl:choose>
+      <xsl:when test="@role = 'gallery'">
+         <div class="container">
+           <div class="gallery-spacer"> </div>
+           <xsl:apply-templates mode="gallery.mode"/>
+         <div class="gallery-spacer"> </div>
+         </div>
+      </xsl:when>
+      <xsl:otherwise>
+        <xsl:apply-imports/>
+      </xsl:otherwise>
+    </xsl:choose>
+  </xsl:template>
+
+  <xsl:template match="link" mode="gallery.mode">
+    <div class="gallery-float">
+       <xsl:apply-templates select="."/>
+    </div>
+  </xsl:template>
+
+  <!-- add gallery handling to refnamediv template -->
+  <xsl:template match="refnamediv">
+    <div class="{name(.)}">
+      <table width="100%">
+        <tr><td valign="top">
+         <xsl:call-template name="anchor"/>
+           <xsl:choose>
+             <xsl:when test="$refentry.generate.name != 0">
+               <h2>
+                <xsl:call-template name="gentext">
+                  <xsl:with-param name="key" select="'RefName'"/>
+                </xsl:call-template>
+              </h2>
+            </xsl:when>
+            <xsl:when test="$refentry.generate.title != 0">
+              <h2>
+                <xsl:choose>
+                  <xsl:when test="../refmeta/refentrytitle">
+                    <xsl:apply-templates select="../refmeta/refentrytitle"/>
+                  </xsl:when>
+                  <xsl:otherwise>
+                    <xsl:apply-templates select="refname[1]"/>
+                  </xsl:otherwise>
+                </xsl:choose>
+              </h2>
+            </xsl:when>
+          </xsl:choose>
+          <p>
+            <xsl:apply-templates/>
+          </p>
+        </td>
+        <td valign="top" align="right">
+           <!-- find the gallery image to use here
+                - determine the id of the enclosing refentry
+                - look for an inlinegraphic inside a link with linkend == refentryid inside a para with role == gallery
+                - use it here
+             -->
+           <xsl:variable name="refentryid" select="../@id"/>
+           <xsl:apply-templates select="//para[@role = 'gallery']/link[@linkend = $refentryid]/inlinegraphic"/>
+        </td></tr>
+       </table>
+     </div>
+  </xsl:template>
+
+  <xsl:template match="example">
+    <xsl:variable name="id" select="@id"/>
+    <div class="hideshow" onClick="toggle(this, event)">
+      <xsl:apply-imports />
+    </div>
+  </xsl:template>
+
+</xsl:stylesheet>

references/igraph-1.0.1/doc/heap.xxml

@@ -0,0 +1,21 @@
+<?xml version="1.0"?>
+<!DOCTYPE section PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN"
+               "http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd" [
+<!ENTITY igraph "igraph">
+]>
+
+<section id="igraph-Heaps">
+<title>Maximum and minimum heaps</title>
+
+<!-- doxrox-include igraph_heap_init -->
+<!-- doxrox-include igraph_heap_init_array -->
+<!-- doxrox-include igraph_heap_destroy -->
+<!-- doxrox-include igraph_heap_clear -->
+<!-- doxrox-include igraph_heap_empty -->
+<!-- doxrox-include igraph_heap_push -->
+<!-- doxrox-include igraph_heap_top -->
+<!-- doxrox-include igraph_heap_delete_top -->
+<!-- doxrox-include igraph_heap_size -->
+<!-- doxrox-include igraph_heap_reserve -->
+
+</section>

references/igraph-1.0.1/doc/hrg.xxml

@@ -0,0 +1,45 @@
+<?xml version="1.0"?>
+<!DOCTYPE section PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN"
+               "http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd" [
+<!ENTITY igraph "igraph">
+]>
+
+<chapter id="igraph-HRG">
+<title>Hierarchical random graphs</title>
+
+<section id="hrg-intro">
+<!-- doxrox-include hrg_intro -->
+</section>
+
+<section id="representing-hrgs"><title>Representing HRGs</title>
+<!-- doxrox-include igraph_hrg_t -->
+<!-- doxrox-include igraph_hrg_init -->
+<!-- doxrox-include igraph_hrg_destroy -->
+<!-- doxrox-include igraph_hrg_size -->
+<!-- doxrox-include igraph_hrg_resize -->
+</section>
+
+<section id="fitting-hrgs"><title>Fitting HRGs</title>
+<!-- doxrox-include igraph_hrg_fit -->
+<!-- doxrox-include igraph_hrg_consensus -->
+</section>
+
+<section id="hrg-sampling"><title>HRG sampling</title>
+<!-- doxrox-include igraph_hrg_sample -->
+<!-- doxrox-include igraph_hrg_game -->
+</section>
+
+<section id="conversion-to-and-from-igraph-graphs"><title>Conversion to and from igraph graphs</title>
+<!-- doxrox-include igraph_from_hrg_dendrogram -->
+<!-- doxrox-include igraph_hrg_create -->
+</section>
+
+<section id="predicting-missing-edges"><title>Predicting missing edges</title>
+<!-- doxrox-include igraph_hrg_predict -->
+</section>
+
+<section id="hrg-deprecated"><title>Deprecated functions</title>
+<!-- doxrox-include igraph_hrg_dendrogram -->
+</section>
+
+</chapter>

references/igraph-1.0.1/doc/html/igraph-Coloring.html

@@ -0,0 +1,627 @@
+<html>
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
+<title>Chapter 22. Graph coloring</title>
+<meta name="generator" content="DocBook XSL Stylesheets Vsnapshot">
+<link rel="home" href="index.html" title="igraph Reference Manual">
+<link rel="up" href="index.html" title="igraph Reference Manual">
+<link rel="prev" href="igraph-Isomorphism.html" title="Chapter 21. Graph isomorphism">
+<link rel="next" href="igraph-Flows.html" title="Chapter 23. Maximum flows, minimum cuts and related measures">
+<script type="text/javascript" src="toggle.js"></script><link rel="stylesheet" href="style.css" type="text/css">
+<link rel="stylesheet" href="https://stackpath.bootstrapcdn.com/font-awesome/4.7.0/css/font-awesome.min.css" type="text/css">
+<link rel="chapter" href="igraph-Introduction.html" title="Chapter 1. Introduction">
+<link rel="chapter" href="igraph-Installation.html" title="Chapter 2. Installation">
+<link rel="chapter" href="igraph-Tutorial.html" title="Chapter 3. Tutorial">
+<link rel="chapter" href="igraph-Basic.html" title="Chapter 4. Basic data types and interface">
+<link rel="chapter" href="igraph-Error.html" title="Chapter 5. Error handling">
+<link rel="chapter" href="igraph-Memory.html" title="Chapter 6. Memory (de)allocation">
+<link rel="chapter" href="igraph-Data-structures.html" title="Chapter 7. Data structure library: vector, matrix, other data types">
+<link rel="chapter" href="igraph-Random.html" title="Chapter 8. Random numbers">
+<link rel="chapter" href="igraph-Iterators.html" title="Chapter 9. Vertex and edge selectors and sequences, iterators">
+<link rel="chapter" href="igraph-Attributes.html" title="Chapter 10. Graph, vertex and edge attributes">
+<link rel="chapter" href="igraph-Generators.html" title="Chapter 11. Deterministic graph generators">
+<link rel="chapter" href="igraph-Games.html" title='Chapter 12. Stochastic graph generators ("games")'>
+<link rel="chapter" href="igraph-Bipartite.html" title="Chapter 13. Bipartite, i.e. two-mode graphs">
+<link rel="chapter" href="igraph-Spatial.html" title="Chapter 14. Spatial graphs">
+<link rel="chapter" href="igraph-Operators.html" title="Chapter 15. Graph operators">
+<link rel="chapter" href="igraph-Visitors.html" title="Chapter 16. Graph visitors">
+<link rel="chapter" href="igraph-Structural.html" title="Chapter 17. Structural properties of graphs">
+<link rel="chapter" href="igraph-Cycles.html" title="Chapter 18. Graph cycles">
+<link rel="chapter" href="igraph-Cliques.html" title="Chapter 19. Cliques and independent vertex sets">
+<link rel="chapter" href="igraph-Motifs.html" title="Chapter 20. Graph motifs, dyad census and triad census">
+<link rel="chapter" href="igraph-Isomorphism.html" title="Chapter 21. Graph isomorphism">
+<link rel="chapter" href="igraph-Coloring.html" title="Chapter 22. Graph coloring">
+<link rel="chapter" href="igraph-Flows.html" title="Chapter 23. Maximum flows, minimum cuts and related measures">
+<link rel="chapter" href="igraph-Separators.html" title="Chapter 24. Vertex separators">
+<link rel="chapter" href="igraph-Community.html" title="Chapter 25. Detecting community structure">
+<link rel="chapter" href="igraph-Graphlets.html" title="Chapter 26. Graphlets">
+<link rel="chapter" href="igraph-HRG.html" title="Chapter 27. Hierarchical random graphs">
+<link rel="chapter" href="igraph-Embedding.html" title="Chapter 28. Embedding of graphs">
+<link rel="chapter" href="igraph-Layout.html" title="Chapter 29. Generating layouts for graph drawing">
+<link rel="chapter" href="igraph-Processes.html" title="Chapter 30. Processes on graphs">
+<link rel="chapter" href="igraph-Foreign.html" title="Chapter 31. Reading and writing graphs from and to files">
+<link rel="chapter" href="igraph-Linalg.html" title="Chapter 32. Using BLAS, LAPACK and ARPACK for igraph matrices and graphs">
+<link rel="chapter" href="igraph-Nongraph.html" title="Chapter 33. Non-graph related functions">
+<link rel="chapter" href="igraph-Advanced.html" title="Chapter 34. Advanced igraph programming">
+<link rel="chapter" href="igraph-Glossary.html" title="Chapter 35. Glossary">
+<link rel="chapter" href="igraph-Licenses.html" title="Chapter 36. Licenses for igraph and this manual">
+<link rel="index" href="ix01.html" title="Index">
+</head>
+<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
+<div class="navigation-header mb-4" width="100%" summary="Navigation header"><div class="btn-group">
+<a accesskey="p" class="btn btn-light" href="igraph-Isomorphism.html"><i class="fa fa-chevron-left"></i>
+              Previous
+            </a><a accesskey="h" class="btn btn-light" href="index.html"><i class="fa fa-home"></i>
+              Home
+            </a><a accesskey="n" class="btn btn-light" href="igraph-Flows.html"><i class="fa fa-chevron-right"></i>
+              Next
+            </a>
+</div></div>
+<div class="chapter">
+<div class="titlepage"><div><div><h1 class="title">
+<a name="igraph-Coloring"></a>Chapter 22. Graph coloring</h1></div></div></div>
+<div class="toc"><dl class="toc">
+<dt><span class="section"><a href="igraph-Coloring.html#igraph_vertex_coloring_greedy">1. <code class="function">igraph_vertex_coloring_greedy</code> —  Computes a vertex coloring using a greedy algorithm.</a></span></dt>
+<dt><span class="section"><a href="igraph-Coloring.html#igraph_coloring_greedy_t">2. <code class="function">igraph_coloring_greedy_t</code> —  Ordering heuristics for greedy graph coloring.</a></span></dt>
+<dt><span class="section"><a href="igraph-Coloring.html#igraph_is_vertex_coloring">3. <code class="function">igraph_is_vertex_coloring</code> —  Checks whether a vertex coloring is valid.</a></span></dt>
+<dt><span class="section"><a href="igraph-Coloring.html#igraph_is_bipartite_coloring">4. <code class="function">igraph_is_bipartite_coloring</code> —  Checks whether a bipartite vertex coloring is valid.</a></span></dt>
+<dt><span class="section"><a href="igraph-Coloring.html#igraph_is_edge_coloring">5. <code class="function">igraph_is_edge_coloring</code> —  Checks whether an edge coloring is valid.</a></span></dt>
+<dt><span class="section"><a href="igraph-Coloring.html#igraph_is_perfect">6. <code class="function">igraph_is_perfect</code> —  Checks if the graph is perfect.</a></span></dt>
+</dl></div>
+<div class="section">
+<div class="titlepage"><div><div><h2 class="title" style="clear: both">
+<a name="igraph_vertex_coloring_greedy"></a>1. <code class="function">igraph_vertex_coloring_greedy</code> —  Computes a vertex coloring using a greedy algorithm.</h2></div></div></div>
+<a class="indexterm" name="id-1.23.2.2"></a><p>
+</p>
+<div class="informalexample"><pre class="programlisting">
+igraph_error_t igraph_vertex_coloring_greedy(const igraph_t *graph, igraph_vector_int_t *colors, igraph_coloring_greedy_t heuristic);
+</pre></div>
+<p>
+</p>
+<p>
+
+
+
+This function assigns a "color"—represented as a non-negative integer—to
+each vertex of the graph in such a way that neighboring vertices never have
+the same color. The obtained coloring is not necessarily minimal.
+
+</p>
+<p>
+Vertices are colored greedily, one by one, always choosing the smallest color
+index that differs from that of already colored neighbors. Vertices are picked
+in an order determined by the speified heuristic.
+Colors are represented by non-negative integers 0, 1, 2, ...
+
+</p>
+<p><b>Arguments: </b>
+</p>
+<div class="variablelist"><table border="0" class="variablelist">
+<colgroup>
+<col align="left" valign="top">
+<col>
+</colgroup>
+<tbody>
+<tr>
+<td><p><span class="term"><em class="parameter"><code>graph</code></em>:</span></p></td>
+<td><p>
+  The input graph.
+</p></td>
+</tr>
+<tr>
+<td><p><span class="term"><em class="parameter"><code>colors</code></em>:</span></p></td>
+<td><p>
+  Pointer to an initialized integer vector. The vertex colors will be stored here.
+</p></td>
+</tr>
+<tr>
+<td><p><span class="term"><em class="parameter"><code>heuristic</code></em>:</span></p></td>
+<td><p>
+  The vertex ordering heuristic to use during greedy coloring.
+   See <a class="link" href="igraph-Coloring.html#igraph_coloring_greedy_t" title="2. igraph_coloring_greedy_t — Ordering heuristics for greedy graph coloring."><code class="function">igraph_coloring_greedy_t</code></a> for more information.</p></td>
+</tr>
+</tbody>
+</table></div>
+<p>
+
+
+</p>
+<p><b>Returns: </b></p>
+<div class="variablelist"><table border="0" class="variablelist">
+<colgroup>
+<col align="left" valign="top">
+<col>
+</colgroup>
+<tbody><tr>
+<td><p><span class="term"><em class="parameter"><code></code></em></span></p></td>
+<td><p>
+  Error code.
+  </p></td>
+</tr></tbody>
+</table></div>
+<p>
+
+</p>
+<p><b>See also: </b></p>
+<div class="variablelist"><table border="0" class="variablelist">
+<colgroup>
+<col align="left" valign="top">
+<col>
+</colgroup>
+<tbody><tr>
+<td><p><span class="term"><em class="parameter"><code></code></em></span></p></td>
+<td><p>
+  igraph_is_vertex_coloring() to check if a coloring is valid, i.e. if all
+edges connect vertices of different colors.
+  </p></td>
+</tr></tbody>
+</table></div>
+<p>
+
+</p>
+<div class="hideshow" onClick="toggle(this, event)">
+<div class="example">
+<a name="id-1.23.2.11.1"></a><p class="title"><b>Example 22.1.  File <code class="code">examples/simple/coloring.c</code></b></p>
+<div class="example-contents">
+<pre class="programlisting"><span class="strong"><strong>#include</strong></span> &lt;igraph.h&gt;
+
+int <span class="strong"><strong>main</strong></span>(void) {
+    igraph_t graph;
+    igraph_vector_int_t colors;
+    igraph_bool_t valid_coloring;
+
+    <span class="emphasis"><em>/* Initialize the library. */</em></span>
+    <span class="strong"><strong><a class="link" href="igraph-Basic.html#igraph_setup" title="4.1. igraph_setup — Initializes the igraph library.">igraph_setup</a></strong></span>();
+
+    <span class="emphasis"><em>/* Setting a seed makes the result of erdos_renyi_game_gnm deterministic. */</em></span>
+    <span class="strong"><strong><a class="link" href="igraph-Random.html#igraph_rng_seed" title="3.3. igraph_rng_seed — Seeds a random number generator.">igraph_rng_seed</a></strong></span>(<span class="strong"><strong><a class="link" href="igraph-Random.html#igraph_rng_default" title="2.1. igraph_rng_default — Query the default random number generator.">igraph_rng_default</a></strong></span>(), 42);
+
+    <span class="emphasis"><em>/* IGRAPH_UNDIRECTED and IGRAPH_NO_LOOPS are both equivalent to 0/FALSE, but</em></span>
+<span class="emphasis"><em>       communicate intent better in this context. */</em></span>
+    <span class="strong"><strong><a class="link" href="igraph-Games.html#igraph_erdos_renyi_game_gnm" title="1.1. igraph_erdos_renyi_game_gnm — Generates a random (Erdős-Rényi) graph with a fixed number of edges.">igraph_erdos_renyi_game_gnm</a></strong></span>(&amp;graph, 1000, 10000, IGRAPH_UNDIRECTED, IGRAPH_SIMPLE_SW, IGRAPH_EDGE_UNLABELED);
+
+    <span class="emphasis"><em>/* As with all igraph functions, the vector in which the result is returned must</em></span>
+<span class="emphasis"><em>       be initialized in advance. */</em></span>
+    <span class="strong"><strong>igraph_vector_int_init</strong></span>(&amp;colors, 0);
+    <span class="strong"><strong><a class="link" href="igraph-Coloring.html#igraph_vertex_coloring_greedy" title="1. igraph_vertex_coloring_greedy — Computes a vertex coloring using a greedy algorithm.">igraph_vertex_coloring_greedy</a></strong></span>(&amp;graph, &amp;colors, IGRAPH_COLORING_GREEDY_COLORED_NEIGHBORS);
+
+    <span class="emphasis"><em>/* Verify that the colouring is valid, i.e. no two adjacent vertices have the same colour. */</em></span>
+    <span class="strong"><strong><a class="link" href="igraph-Coloring.html#igraph_is_vertex_coloring" title="3. igraph_is_vertex_coloring — Checks whether a vertex coloring is valid.">igraph_is_vertex_coloring</a></strong></span>(&amp;graph, &amp;colors, &amp;valid_coloring);
+    <span class="strong"><strong><a class="link" href="igraph-Error.html#IGRAPH_ASSERT" title="5.5.6. IGRAPH_ASSERT — igraph-specific replacement for assert().">IGRAPH_ASSERT</a></strong></span>(valid_coloring);
+
+    <span class="emphasis"><em>/* Destroy data structure when we are done. */</em></span>
+    <span class="strong"><strong>igraph_vector_int_destroy</strong></span>(&amp;colors);
+    <span class="strong"><strong><a class="link" href="igraph-Basic.html#igraph_destroy" title="5.1.4. igraph_destroy — Frees the memory allocated for a graph object.">igraph_destroy</a></strong></span>(&amp;graph);
+
+    <span class="strong"><strong>return</strong></span> 0;
+}
+</pre>
+<p></p>
+</div>
+</div>
+<br class="example-break">
+</div>
+<p> 
+</p>
+</div>
+<div class="section">
+<div class="titlepage"><div><div><h2 class="title" style="clear: both">
+<a name="igraph_coloring_greedy_t"></a>2. <code class="function">igraph_coloring_greedy_t</code> —  Ordering heuristics for greedy graph coloring.</h2></div></div></div>
+<a class="indexterm" name="id-1.23.3.2"></a><p>
+</p>
+<pre class="programlisting">
+typedef enum {
+    IGRAPH_COLORING_GREEDY_COLORED_NEIGHBORS = 0,
+    IGRAPH_COLORING_GREEDY_DSATUR = 1
+} igraph_coloring_greedy_t;
+</pre>
+<p>
+</p>
+<p>
+
+
+Ordering heuristics for <a class="link" href="igraph-Coloring.html#igraph_vertex_coloring_greedy" title="1. igraph_vertex_coloring_greedy — Computes a vertex coloring using a greedy algorithm."><code class="function">igraph_vertex_coloring_greedy()</code></a>.
+
+</p>
+<p><b>Values: </b>
+</p>
+<div class="variablelist"><table border="0" class="variablelist">
+<colgroup>
+<col align="left" valign="top">
+<col>
+</colgroup>
+<tbody>
+<tr>
+<td><p><span class="term"><code class="constant">IGRAPH_COLORING_GREEDY_COLORED_NEIGHBORS</code>:</span></p></td>
+<td><p>
+  Choose the vertex with largest number of already colored neighbors.
+</p></td>
+</tr>
+<tr>
+<td><p><span class="term"><code class="constant">IGRAPH_COLORING_GREEDY_DSATUR</code>:</span></p></td>
+<td><p>
+  Choose the vertex with largest number of unique colors in its neighborhood, i.e. its
+   "saturation degree". When multiple vertices have the same saturation degree, choose
+   the one with the most not yet colored neighbors. Added in igraph 0.10.4. This heuristic
+   is known as "DSatur", and was proposed in
+   Daniel Brélaz: New methods to color the vertices of a graph,
+   Commun. ACM 22, 4 (1979), 251–256. <a class="ulink" href="https://doi.org/10.1145/359094.359101" target="_top">https://doi.org/10.1145/359094.359101</a></p></td>
+</tr>
+</tbody>
+</table></div>
+<p>
+
+ 
+</p>
+</div>
+<div class="section">
+<div class="titlepage"><div><div><h2 class="title" style="clear: both">
+<a name="igraph_is_vertex_coloring"></a>3. <code class="function">igraph_is_vertex_coloring</code> —  Checks whether a vertex coloring is valid.</h2></div></div></div>
+<a class="indexterm" name="id-1.23.4.2"></a><p>
+</p>
+<div class="informalexample"><pre class="programlisting">
+igraph_error_t igraph_is_vertex_coloring(
+        const igraph_t *graph,
+        const igraph_vector_int_t *types,
+        igraph_bool_t *res);
+</pre></div>
+<p>
+</p>
+<p>
+
+
+
+This function checks whether the given vertex type/color assignment is a valid
+vertex coloring, i.e., no two adjacent vertices have the same color.
+Self-loops are ignored.
+
+</p>
+<p><b>Arguments: </b>
+</p>
+<div class="variablelist"><table border="0" class="variablelist">
+<colgroup>
+<col align="left" valign="top">
+<col>
+</colgroup>
+<tbody>
+<tr>
+<td><p><span class="term"><em class="parameter"><code>graph</code></em>:</span></p></td>
+<td><p>
+  The input graph.
+</p></td>
+</tr>
+<tr>
+<td><p><span class="term"><em class="parameter"><code>types</code></em>:</span></p></td>
+<td><p>
+  The vertex types/colors as an integer vector.
+</p></td>
+</tr>
+<tr>
+<td><p><span class="term"><em class="parameter"><code>res</code></em>:</span></p></td>
+<td><p>
+  Pointer to a boolean, the result is stored here.
+</p></td>
+</tr>
+</tbody>
+</table></div>
+<p>
+</p>
+<p><b>Returns: </b></p>
+<div class="variablelist"><table border="0" class="variablelist">
+<colgroup>
+<col align="left" valign="top">
+<col>
+</colgroup>
+<tbody><tr>
+<td><p><span class="term"><em class="parameter"><code></code></em></span></p></td>
+<td><p>
+  Error code.
+  </p></td>
+</tr></tbody>
+</table></div>
+<p>
+
+Time complexity: O(|E|), linear in the number of edges.
+
+</p>
+<div class="hideshow" onClick="toggle(this, event)">
+<div class="example">
+<a name="id-1.23.4.8.1"></a><p class="title"><b>Example 22.2.  File <code class="code">examples/simple/coloring.c</code></b></p>
+<div class="example-contents">
+<pre class="programlisting"><span class="strong"><strong>#include</strong></span> &lt;igraph.h&gt;
+
+int <span class="strong"><strong>main</strong></span>(void) {
+    igraph_t graph;
+    igraph_vector_int_t colors;
+    igraph_bool_t valid_coloring;
+
+    <span class="emphasis"><em>/* Initialize the library. */</em></span>
+    <span class="strong"><strong><a class="link" href="igraph-Basic.html#igraph_setup" title="4.1. igraph_setup — Initializes the igraph library.">igraph_setup</a></strong></span>();
+
+    <span class="emphasis"><em>/* Setting a seed makes the result of erdos_renyi_game_gnm deterministic. */</em></span>
+    <span class="strong"><strong><a class="link" href="igraph-Random.html#igraph_rng_seed" title="3.3. igraph_rng_seed — Seeds a random number generator.">igraph_rng_seed</a></strong></span>(<span class="strong"><strong><a class="link" href="igraph-Random.html#igraph_rng_default" title="2.1. igraph_rng_default — Query the default random number generator.">igraph_rng_default</a></strong></span>(), 42);
+
+    <span class="emphasis"><em>/* IGRAPH_UNDIRECTED and IGRAPH_NO_LOOPS are both equivalent to 0/FALSE, but</em></span>
+<span class="emphasis"><em>       communicate intent better in this context. */</em></span>
+    <span class="strong"><strong><a class="link" href="igraph-Games.html#igraph_erdos_renyi_game_gnm" title="1.1. igraph_erdos_renyi_game_gnm — Generates a random (Erdős-Rényi) graph with a fixed number of edges.">igraph_erdos_renyi_game_gnm</a></strong></span>(&amp;graph, 1000, 10000, IGRAPH_UNDIRECTED, IGRAPH_SIMPLE_SW, IGRAPH_EDGE_UNLABELED);
+
+    <span class="emphasis"><em>/* As with all igraph functions, the vector in which the result is returned must</em></span>
+<span class="emphasis"><em>       be initialized in advance. */</em></span>
+    <span class="strong"><strong>igraph_vector_int_init</strong></span>(&amp;colors, 0);
+    <span class="strong"><strong><a class="link" href="igraph-Coloring.html#igraph_vertex_coloring_greedy" title="1. igraph_vertex_coloring_greedy — Computes a vertex coloring using a greedy algorithm.">igraph_vertex_coloring_greedy</a></strong></span>(&amp;graph, &amp;colors, IGRAPH_COLORING_GREEDY_COLORED_NEIGHBORS);
+
+    <span class="emphasis"><em>/* Verify that the colouring is valid, i.e. no two adjacent vertices have the same colour. */</em></span>
+    <span class="strong"><strong><a class="link" href="igraph-Coloring.html#igraph_is_vertex_coloring" title="3. igraph_is_vertex_coloring — Checks whether a vertex coloring is valid.">igraph_is_vertex_coloring</a></strong></span>(&amp;graph, &amp;colors, &amp;valid_coloring);
+    <span class="strong"><strong><a class="link" href="igraph-Error.html#IGRAPH_ASSERT" title="5.5.6. IGRAPH_ASSERT — igraph-specific replacement for assert().">IGRAPH_ASSERT</a></strong></span>(valid_coloring);
+
+    <span class="emphasis"><em>/* Destroy data structure when we are done. */</em></span>
+    <span class="strong"><strong>igraph_vector_int_destroy</strong></span>(&amp;colors);
+    <span class="strong"><strong><a class="link" href="igraph-Basic.html#igraph_destroy" title="5.1.4. igraph_destroy — Frees the memory allocated for a graph object.">igraph_destroy</a></strong></span>(&amp;graph);
+
+    <span class="strong"><strong>return</strong></span> 0;
+}
+</pre>
+<p></p>
+</div>
+</div>
+<br class="example-break">
+</div>
+<p> 
+</p>
+</div>
+<div class="section">
+<div class="titlepage"><div><div><h2 class="title" style="clear: both">
+<a name="igraph_is_bipartite_coloring"></a>4. <code class="function">igraph_is_bipartite_coloring</code> —  Checks whether a bipartite vertex coloring is valid.</h2></div></div></div>
+<a class="indexterm" name="id-1.23.5.2"></a><p>
+</p>
+<div class="informalexample"><pre class="programlisting">
+igraph_error_t igraph_is_bipartite_coloring(
+        const igraph_t *graph,
+        const igraph_vector_bool_t *types,
+        igraph_bool_t *res,
+        igraph_neimode_t *mode);
+</pre></div>
+<p>
+</p>
+<p>
+
+
+
+This function checks whether the given vertex type assignment is a valid
+bipartite coloring, i.e., no two adjacent vertices have the same type.
+Additionally, for directed graphs, it determines the mode of edge directions.
+Self-loops are ignored.
+
+</p>
+<p><b>Arguments: </b>
+</p>
+<div class="variablelist"><table border="0" class="variablelist">
+<colgroup>
+<col align="left" valign="top">
+<col>
+</colgroup>
+<tbody>
+<tr>
+<td><p><span class="term"><em class="parameter"><code>graph</code></em>:</span></p></td>
+<td><p>
+  The input graph.
+</p></td>
+</tr>
+<tr>
+<td><p><span class="term"><em class="parameter"><code>types</code></em>:</span></p></td>
+<td><p>
+  The vertex types as a boolean vector.
+</p></td>
+</tr>
+<tr>
+<td><p><span class="term"><em class="parameter"><code>res</code></em>:</span></p></td>
+<td><p>
+  Pointer to a boolean, the result is stored here.
+</p></td>
+</tr>
+<tr>
+<td><p><span class="term"><em class="parameter"><code>mode</code></em>:</span></p></td>
+<td><p>
+  Pointer to store the edge direction mode. Can be <code class="constant">NULL</code> if not needed.
+  If all edges go from false to true vertices, <code class="constant">IGRAPH_OUT</code> is returned.
+  If all edges go from true to false vertices, <code class="constant">IGRAPH_IN</code> is returned.
+  If edges go in both directions or graph is undirected, <code class="constant">IGRAPH_ALL</code> is returned.
+</p></td>
+</tr>
+</tbody>
+</table></div>
+<p>
+</p>
+<p><b>Returns: </b></p>
+<div class="variablelist"><table border="0" class="variablelist">
+<colgroup>
+<col align="left" valign="top">
+<col>
+</colgroup>
+<tbody><tr>
+<td><p><span class="term"><em class="parameter"><code></code></em></span></p></td>
+<td><p>
+  Error code.
+  </p></td>
+</tr></tbody>
+</table></div>
+<p>
+
+Time complexity: O(|E|), linear in the number of edges.
+
+</p>
+<p><b>See also: </b></p>
+<div class="variablelist"><table border="0" class="variablelist">
+<colgroup>
+<col align="left" valign="top">
+<col>
+</colgroup>
+<tbody><tr>
+<td><p><span class="term"><em class="parameter"><code></code></em></span></p></td>
+<td><p>
+  igraph_is_bipartite() to determine whether a graph is bipartite,
+i.e. 2-colorable, and find such a coloring.
+  </p></td>
+</tr></tbody>
+</table></div>
+<p>
+ 
+</p>
+</div>
+<div class="section">
+<div class="titlepage"><div><div><h2 class="title" style="clear: both">
+<a name="igraph_is_edge_coloring"></a>5. <code class="function">igraph_is_edge_coloring</code> —  Checks whether an edge coloring is valid.</h2></div></div></div>
+<a class="indexterm" name="id-1.23.6.2"></a><p>
+</p>
+<div class="informalexample"><pre class="programlisting">
+igraph_error_t igraph_is_edge_coloring(
+        const igraph_t *graph,
+        const igraph_vector_int_t *types,
+        igraph_bool_t *res);
+</pre></div>
+<p>
+</p>
+<p>
+
+
+
+This function checks whether the given edge color assignment is a valid
+edge coloring, i.e., no two adjacent edges have the same color.
+
+Note that this function does not consider self-edges (loops) as being
+adjacent to themselves, so graphs with self-loops may still be considered
+to have a valid edge coloring.
+
+</p>
+<p><b>Arguments: </b>
+</p>
+<div class="variablelist"><table border="0" class="variablelist">
+<colgroup>
+<col align="left" valign="top">
+<col>
+</colgroup>
+<tbody>
+<tr>
+<td><p><span class="term"><em class="parameter"><code>graph</code></em>:</span></p></td>
+<td><p>
+  The input graph.
+</p></td>
+</tr>
+<tr>
+<td><p><span class="term"><em class="parameter"><code>types</code></em>:</span></p></td>
+<td><p>
+  The edge colors as an integer vector.
+</p></td>
+</tr>
+<tr>
+<td><p><span class="term"><em class="parameter"><code>res</code></em>:</span></p></td>
+<td><p>
+  Pointer to a boolean, the result is stored here.
+</p></td>
+</tr>
+</tbody>
+</table></div>
+<p>
+</p>
+<p><b>Returns: </b></p>
+<div class="variablelist"><table border="0" class="variablelist">
+<colgroup>
+<col align="left" valign="top">
+<col>
+</colgroup>
+<tbody><tr>
+<td><p><span class="term"><em class="parameter"><code></code></em></span></p></td>
+<td><p>
+  Error code.
+  </p></td>
+</tr></tbody>
+</table></div>
+<p>
+
+Time complexity: O(|V|*d*log(d)), where d is the maximum degree.
+ 
+</p>
+</div>
+<div class="section">
+<div class="titlepage"><div><div><h2 class="title" style="clear: both">
+<a name="igraph_is_perfect"></a>6. <code class="function">igraph_is_perfect</code> —  Checks if the graph is perfect.</h2></div></div></div>
+<a class="indexterm" name="id-1.23.7.2"></a><p>
+</p>
+<div class="informalexample"><pre class="programlisting">
+igraph_error_t igraph_is_perfect(const igraph_t *graph, igraph_bool_t *perfect);
+</pre></div>
+<p>
+</p>
+<p>
+
+
+
+A perfect graph is an undirected graph in which the chromatic number of every induced
+subgraph equals the order of the largest clique of that subgraph.
+The chromatic number of a graph G is the smallest number of colors needed to
+color the vertices of G so that no two adjacent vertices share the same color.
+
+</p>
+<p>
+Warning: This function may create the complement of the graph internally,
+which consumes a lot of memory. For moderately sized graphs, consider
+decomposing them into biconnected components and running the check separately
+on each component.
+
+</p>
+<p>
+This implementation is based on the strong perfect graph theorem which was
+conjectured by Claude Berge and proved by Maria Chudnovsky, Neil Robertson,
+Paul Seymour, and Robin Thomas.
+
+</p>
+<p><b>Arguments: </b>
+</p>
+<div class="variablelist"><table border="0" class="variablelist">
+<colgroup>
+<col align="left" valign="top">
+<col>
+</colgroup>
+<tbody>
+<tr>
+<td><p><span class="term"><em class="parameter"><code>graph</code></em>:</span></p></td>
+<td><p>
+  The input graph. It is expected to be undirected and simple.
+</p></td>
+</tr>
+<tr>
+<td><p><span class="term"><em class="parameter"><code>perfect</code></em>:</span></p></td>
+<td><p>
+  Pointer to an integer, the result will be stored here.
+</p></td>
+</tr>
+</tbody>
+</table></div>
+<p>
+</p>
+<p><b>Returns: </b></p>
+<div class="variablelist"><table border="0" class="variablelist">
+<colgroup>
+<col align="left" valign="top">
+<col>
+</colgroup>
+<tbody><tr>
+<td><p><span class="term"><em class="parameter"><code></code></em></span></p></td>
+<td><p>
+  Error code.
+  </p></td>
+</tr></tbody>
+</table></div>
+<p>
+
+Time complexity: worst case exponenital, often faster in practice.
+ 
+</p>
+</div>
+</div>
+<table class="navigation-footer" width="100%" summary="Navigation footer" cellpadding="2" cellspacing="0"><tr valign="middle">
+<td align="left"><a accesskey="p" href="igraph-Isomorphism.html"><b>← Chapter 21. Graph isomorphism</b></a></td>
+<td align="right"><a accesskey="n" href="igraph-Flows.html"><b>Chapter 23. Maximum flows, minimum cuts and related measures →</b></a></td>
+</tr></table>
+</body>
+</html>

references/igraph-1.0.1/doc/html/igraph-Embedding.html

@@ -0,0 +1,596 @@
+<html>
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
+<title>Chapter 28. Embedding of graphs</title>
+<meta name="generator" content="DocBook XSL Stylesheets Vsnapshot">
+<link rel="home" href="index.html" title="igraph Reference Manual">
+<link rel="up" href="index.html" title="igraph Reference Manual">
+<link rel="prev" href="igraph-HRG.html" title="Chapter 27. Hierarchical random graphs">
+<link rel="next" href="igraph-Layout.html" title="Chapter 29. Generating layouts for graph drawing">
+<script type="text/javascript" src="toggle.js"></script><link rel="stylesheet" href="style.css" type="text/css">
+<link rel="stylesheet" href="https://stackpath.bootstrapcdn.com/font-awesome/4.7.0/css/font-awesome.min.css" type="text/css">
+<link rel="chapter" href="igraph-Introduction.html" title="Chapter 1. Introduction">
+<link rel="chapter" href="igraph-Installation.html" title="Chapter 2. Installation">
+<link rel="chapter" href="igraph-Tutorial.html" title="Chapter 3. Tutorial">
+<link rel="chapter" href="igraph-Basic.html" title="Chapter 4. Basic data types and interface">
+<link rel="chapter" href="igraph-Error.html" title="Chapter 5. Error handling">
+<link rel="chapter" href="igraph-Memory.html" title="Chapter 6. Memory (de)allocation">
+<link rel="chapter" href="igraph-Data-structures.html" title="Chapter 7. Data structure library: vector, matrix, other data types">
+<link rel="chapter" href="igraph-Random.html" title="Chapter 8. Random numbers">
+<link rel="chapter" href="igraph-Iterators.html" title="Chapter 9. Vertex and edge selectors and sequences, iterators">
+<link rel="chapter" href="igraph-Attributes.html" title="Chapter 10. Graph, vertex and edge attributes">
+<link rel="chapter" href="igraph-Generators.html" title="Chapter 11. Deterministic graph generators">
+<link rel="chapter" href="igraph-Games.html" title='Chapter 12. Stochastic graph generators ("games")'>
+<link rel="chapter" href="igraph-Bipartite.html" title="Chapter 13. Bipartite, i.e. two-mode graphs">
+<link rel="chapter" href="igraph-Spatial.html" title="Chapter 14. Spatial graphs">
+<link rel="chapter" href="igraph-Operators.html" title="Chapter 15. Graph operators">
+<link rel="chapter" href="igraph-Visitors.html" title="Chapter 16. Graph visitors">
+<link rel="chapter" href="igraph-Structural.html" title="Chapter 17. Structural properties of graphs">
+<link rel="chapter" href="igraph-Cycles.html" title="Chapter 18. Graph cycles">
+<link rel="chapter" href="igraph-Cliques.html" title="Chapter 19. Cliques and independent vertex sets">
+<link rel="chapter" href="igraph-Motifs.html" title="Chapter 20. Graph motifs, dyad census and triad census">
+<link rel="chapter" href="igraph-Isomorphism.html" title="Chapter 21. Graph isomorphism">
+<link rel="chapter" href="igraph-Coloring.html" title="Chapter 22. Graph coloring">
+<link rel="chapter" href="igraph-Flows.html" title="Chapter 23. Maximum flows, minimum cuts and related measures">
+<link rel="chapter" href="igraph-Separators.html" title="Chapter 24. Vertex separators">
+<link rel="chapter" href="igraph-Community.html" title="Chapter 25. Detecting community structure">
+<link rel="chapter" href="igraph-Graphlets.html" title="Chapter 26. Graphlets">
+<link rel="chapter" href="igraph-HRG.html" title="Chapter 27. Hierarchical random graphs">
+<link rel="chapter" href="igraph-Embedding.html" title="Chapter 28. Embedding of graphs">
+<link rel="chapter" href="igraph-Layout.html" title="Chapter 29. Generating layouts for graph drawing">
+<link rel="chapter" href="igraph-Processes.html" title="Chapter 30. Processes on graphs">
+<link rel="chapter" href="igraph-Foreign.html" title="Chapter 31. Reading and writing graphs from and to files">
+<link rel="chapter" href="igraph-Linalg.html" title="Chapter 32. Using BLAS, LAPACK and ARPACK for igraph matrices and graphs">
+<link rel="chapter" href="igraph-Nongraph.html" title="Chapter 33. Non-graph related functions">
+<link rel="chapter" href="igraph-Advanced.html" title="Chapter 34. Advanced igraph programming">
+<link rel="chapter" href="igraph-Glossary.html" title="Chapter 35. Glossary">
+<link rel="chapter" href="igraph-Licenses.html" title="Chapter 36. Licenses for igraph and this manual">
+<link rel="index" href="ix01.html" title="Index">
+</head>
+<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
+<div class="navigation-header mb-4" width="100%" summary="Navigation header"><div class="btn-group">
+<a accesskey="p" class="btn btn-light" href="igraph-HRG.html"><i class="fa fa-chevron-left"></i>
+              Previous
+            </a><a accesskey="h" class="btn btn-light" href="index.html"><i class="fa fa-home"></i>
+              Home
+            </a><a accesskey="n" class="btn btn-light" href="igraph-Layout.html"><i class="fa fa-chevron-right"></i>
+              Next
+            </a>
+</div></div>
+<div class="chapter">
+<div class="titlepage"><div><div><h1 class="title">
+<a name="igraph-Embedding"></a>Chapter 28. Embedding of graphs</h1></div></div></div>
+<div class="toc"><dl class="toc"><dt><span class="section"><a href="igraph-Embedding.html#spectral-embedding">1. Spectral embedding</a></span></dt></dl></div>
+<div class="section">
+<div class="titlepage"><div><div><h2 class="title" style="clear: both">
+<a name="spectral-embedding"></a>1. Spectral embedding</h2></div></div></div>
+<div class="toc"><dl class="toc">
+<dt><span class="section"><a href="igraph-Embedding.html#igraph_adjacency_spectral_embedding">1.1. <code class="function">igraph_adjacency_spectral_embedding</code> — Adjacency spectral embedding</a></span></dt>
+<dt><span class="section"><a href="igraph-Embedding.html#igraph_laplacian_spectral_embedding">1.2. <code class="function">igraph_laplacian_spectral_embedding</code> — Spectral embedding of the Laplacian of a graph</a></span></dt>
+<dt><span class="section"><a href="igraph-Embedding.html#igraph_dim_select">1.3. <code class="function">igraph_dim_select</code> —  Dimensionality selection.</a></span></dt>
+</dl></div>
+<div class="section">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="igraph_adjacency_spectral_embedding"></a>1.1. <code class="function">igraph_adjacency_spectral_embedding</code> — Adjacency spectral embedding</h3></div></div></div>
+<a class="indexterm" name="id-1.29.2.2.2"></a><p>
+</p>
+<div class="informalexample"><pre class="programlisting">
+igraph_error_t igraph_adjacency_spectral_embedding(const igraph_t *graph,
+                                        igraph_int_t n,
+                                        const igraph_vector_t *weights,
+                                        igraph_eigen_which_position_t which,
+                                        igraph_bool_t scaled,
+                                        igraph_matrix_t *X,
+                                        igraph_matrix_t *Y,
+                                        igraph_vector_t *D,
+                                        const igraph_vector_t *cvec,
+                                        igraph_arpack_options_t *options);
+</pre></div>
+<p>
+</p>
+<p>
+
+
+
+Spectral decomposition of the adjacency matrices of graphs.
+This function computes an <code class="literal">n</code>-dimensional Euclidean
+representation of the graph based on its adjacency
+matrix, A. This representation is computed via the singular value
+decomposition of the adjacency matrix, A=U D V^T. In the case,
+where the graph is a random dot product graph generated using latent
+position vectors in R^n for each vertex, the embedding will
+provide an estimate of these latent vectors.
+
+</p>
+<p>
+For undirected graphs, the latent positions are calculated as
+X = U^n D^(1/2) where U^n equals to the first no columns of U, and
+D^(1/2) is a diagonal matrix containing the square root of the selected
+singular values on the diagonal.
+
+</p>
+<p>
+For directed graphs, the embedding is defined as the pair
+X = U^n D^(1/2), Y = V^n D^(1/2).
+(For undirected graphs U=V, so it is sufficient to keep one of them.)
+
+</p>
+<p><b>Arguments: </b>
+</p>
+<div class="variablelist"><table border="0" class="variablelist">
+<colgroup>
+<col align="left" valign="top">
+<col>
+</colgroup>
+<tbody>
+<tr>
+<td><p><span class="term"><em class="parameter"><code>graph</code></em>:</span></p></td>
+<td><p>
+  The input graph, can be directed or undirected.
+</p></td>
+</tr>
+<tr>
+<td><p><span class="term"><em class="parameter"><code>n</code></em>:</span></p></td>
+<td><p>
+  An integer scalar. This value is the embedding dimension of
+       the spectral embedding. Should be smaller than the number of
+       vertices. The largest n-dimensional non-zero
+       singular values are used for the spectral embedding.
+</p></td>
+</tr>
+<tr>
+<td><p><span class="term"><em class="parameter"><code>weights</code></em>:</span></p></td>
+<td><p>
+  Optional edge weights. Supply a null pointer for
+       unweighted graphs.
+</p></td>
+</tr>
+<tr>
+<td><p><span class="term"><em class="parameter"><code>which</code></em>:</span></p></td>
+<td>
+<p>
+  Which eigenvalues (or singular values, for directed
+       graphs) to use, possible values:
+       </p>
+<div class="variablelist"><table border="0" class="variablelist">
+<colgroup>
+<col align="left" valign="top">
+<col>
+</colgroup>
+<tbody>
+<tr>
+<td><p><span class="term"><code class="constant">IGRAPH_EIGEN_LM</code></span></p></td>
+<td><p>
+
+         the ones with the largest magnitude
+         
+</p></td>
+</tr>
+<tr>
+<td><p><span class="term"><code class="constant">IGRAPH_EIGEN_LA</code></span></p></td>
+<td><p>
+
+         the (algebraic) largest ones
+         
+</p></td>
+</tr>
+<tr>
+<td><p><span class="term"><code class="constant">IGRAPH_EIGEN_SA</code></span></p></td>
+<td><p>
+
+         the (algebraic) smallest ones.
+       
+</p></td>
+</tr>
+</tbody>
+</table></div>
+<p>
+       For directed graphs, <code class="literal">IGRAPH_EIGEN_LM</code> and
+       <code class="literal">IGRAPH_EIGEN_LA</code> are the same because singular
+       values are used for the ordering instead of eigenvalues.
+</p>
+</td>
+</tr>
+<tr>
+<td><p><span class="term"><em class="parameter"><code>scaled</code></em>:</span></p></td>
+<td><p>
+  Whether to return X and Y (if <code class="constant">scaled</code> is true), or
+       U and V.
+</p></td>
+</tr>
+<tr>
+<td><p><span class="term"><em class="parameter"><code>X</code></em>:</span></p></td>
+<td><p>
+  Initialized matrix, the estimated latent positions are
+       stored here.
+</p></td>
+</tr>
+<tr>
+<td><p><span class="term"><em class="parameter"><code>Y</code></em>:</span></p></td>
+<td><p>
+  Initialized matrix or a null pointer. If not a null
+       pointer, then the second half of the latent positions are
+       stored here. (For undirected graphs, this always equals X.)
+</p></td>
+</tr>
+<tr>
+<td><p><span class="term"><em class="parameter"><code>D</code></em>:</span></p></td>
+<td><p>
+  Initialized vector or a null pointer. If not a null
+       pointer, then the eigenvalues (for undirected graphs) or the
+       singular values (for directed graphs) are stored here.
+</p></td>
+</tr>
+<tr>
+<td><p><span class="term"><em class="parameter"><code>cvec</code></em>:</span></p></td>
+<td><p>
+  A numeric vector, its length is the number vertices in the
+       graph. This vector is added to the diagonal of the adjacency
+       matrix, before performing the SVD.
+</p></td>
+</tr>
+<tr>
+<td><p><span class="term"><em class="parameter"><code>options</code></em>:</span></p></td>
+<td><p>
+  Options to ARPACK. See <a class="link" href="igraph-Linalg.html#igraph_arpack_options_t" title="3.1.1. igraph_arpack_options_t — Options for ARPACK."><code class="function">igraph_arpack_options_t</code></a>
+       for details. Supply <code class="constant">NULL</code> to use the defaults. Note that the
+       function overwrites the <code class="literal">n</code> (number of vertices),
+       <code class="literal">nev</code> and <code class="literal">which</code> parameters and it always
+       starts the calculation from a random start vector.
+</p></td>
+</tr>
+</tbody>
+</table></div>
+<p>
+</p>
+<p><b>Returns: </b></p>
+<div class="variablelist"><table border="0" class="variablelist">
+<colgroup>
+<col align="left" valign="top">
+<col>
+</colgroup>
+<tbody><tr>
+<td><p><span class="term"><em class="parameter"><code></code></em></span></p></td>
+<td><p>
+  Error code.
+  </p></td>
+</tr></tbody>
+</table></div>
+<p>
+
+ 
+</p>
+</div>
+<div class="section">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="igraph_laplacian_spectral_embedding"></a>1.2. <code class="function">igraph_laplacian_spectral_embedding</code> — Spectral embedding of the Laplacian of a graph</h3></div></div></div>
+<a class="indexterm" name="id-1.29.2.3.2"></a><p>
+</p>
+<div class="informalexample"><pre class="programlisting">
+igraph_error_t igraph_laplacian_spectral_embedding(const igraph_t *graph,
+                                        igraph_int_t n,
+                                        const igraph_vector_t *weights,
+                                        igraph_eigen_which_position_t which,
+                                        igraph_laplacian_spectral_embedding_type_t type,
+                                        igraph_bool_t scaled,
+                                        igraph_matrix_t *X,
+                                        igraph_matrix_t *Y,
+                                        igraph_vector_t *D,
+                                        igraph_arpack_options_t *options);
+</pre></div>
+<p>
+</p>
+<p>
+
+
+
+This function essentially does the same as
+<a class="link" href="igraph-Embedding.html#igraph_adjacency_spectral_embedding" title="1.1. igraph_adjacency_spectral_embedding — Adjacency spectral embedding"><code class="function">igraph_adjacency_spectral_embedding</code></a>, but works on the Laplacian
+of the graph, instead of the adjacency matrix.
+</p>
+<p><b>Arguments: </b>
+</p>
+<div class="variablelist"><table border="0" class="variablelist">
+<colgroup>
+<col align="left" valign="top">
+<col>
+</colgroup>
+<tbody>
+<tr>
+<td><p><span class="term"><em class="parameter"><code>graph</code></em>:</span></p></td>
+<td><p>
+  The input graph.
+</p></td>
+</tr>
+<tr>
+<td><p><span class="term"><em class="parameter"><code>n</code></em>:</span></p></td>
+<td><p>
+  The number of eigenvectors (or singular vectors if the graph
+       is directed) to use for the embedding.
+</p></td>
+</tr>
+<tr>
+<td><p><span class="term"><em class="parameter"><code>weights</code></em>:</span></p></td>
+<td><p>
+  Optional edge weights. Supply a null pointer for
+       unweighted graphs.
+</p></td>
+</tr>
+<tr>
+<td><p><span class="term"><em class="parameter"><code>which</code></em>:</span></p></td>
+<td>
+<p>
+  Which eigenvalues (or singular values, for directed
+       graphs) to use, possible values:
+       </p>
+<div class="variablelist"><table border="0" class="variablelist">
+<colgroup>
+<col align="left" valign="top">
+<col>
+</colgroup>
+<tbody>
+<tr>
+<td><p><span class="term"><code class="constant">IGRAPH_EIGEN_LM</code></span></p></td>
+<td><p>
+
+         the ones with the largest magnitude
+         
+</p></td>
+</tr>
+<tr>
+<td><p><span class="term"><code class="constant">IGRAPH_EIGEN_LA</code></span></p></td>
+<td><p>
+
+         the (algebraic) largest ones
+         
+</p></td>
+</tr>
+<tr>
+<td><p><span class="term"><code class="constant">IGRAPH_EIGEN_SA</code></span></p></td>
+<td><p>
+
+         the (algebraic) smallest ones.
+       
+</p></td>
+</tr>
+</tbody>
+</table></div>
+<p>
+       For directed graphs, <code class="literal">IGRAPH_EIGEN_LM</code> and
+       <code class="literal">IGRAPH_EIGEN_LA</code> are the same because singular
+       values are used for the ordering instead of eigenvalues.
+</p>
+</td>
+</tr>
+<tr>
+<td><p><span class="term"><em class="parameter"><code>type</code></em>:</span></p></td>
+<td>
+<p>
+  The type of the Laplacian to use. Various definitions
+       exist for the Laplacian of a graph, and one can choose
+       between them with this argument. Possible values:
+       </p>
+<div class="variablelist"><table border="0" class="variablelist">
+<colgroup>
+<col align="left" valign="top">
+<col>
+</colgroup>
+<tbody>
+<tr>
+<td><p><span class="term"><code class="constant">IGRAPH_EMBEDDING_D_A</code></span></p></td>
+<td><p>
+
+          means D - A where D is the
+          degree matrix and A is the adjacency matrix
+         
+</p></td>
+</tr>
+<tr>
+<td><p><span class="term"><code class="constant">IGRAPH_EMBEDDING_DAD</code></span></p></td>
+<td><p>
+
+          means Di times A times Di,
+          where Di is the inverse of the square root of the degree matrix;
+         
+</p></td>
+</tr>
+<tr>
+<td><p><span class="term"><code class="constant">IGRAPH_EMBEDDING_I_DAD</code></span></p></td>
+<td><p>
+
+         means I - Di A Di, where I
+         is the identity matrix.
+       
+</p></td>
+</tr>
+</tbody>
+</table></div>
+<p>
+</p>
+</td>
+</tr>
+<tr>
+<td><p><span class="term"><em class="parameter"><code>scaled</code></em>:</span></p></td>
+<td><p>
+  Whether to return X and Y (if <code class="constant">scaled</code> is true), or
+       U and V.
+</p></td>
+</tr>
+<tr>
+<td><p><span class="term"><em class="parameter"><code>X</code></em>:</span></p></td>
+<td><p>
+  Initialized matrix, the estimated latent positions are
+       stored here.
+</p></td>
+</tr>
+<tr>
+<td><p><span class="term"><em class="parameter"><code>Y</code></em>:</span></p></td>
+<td><p>
+  Initialized matrix or a null pointer. If not a null
+       pointer, then the second half of the latent positions are
+       stored here. (For undirected graphs, this always equals X.)
+</p></td>
+</tr>
+<tr>
+<td><p><span class="term"><em class="parameter"><code>D</code></em>:</span></p></td>
+<td><p>
+  Initialized vector or a null pointer. If not a null
+       pointer, then the eigenvalues (for undirected graphs) or the
+       singular values (for directed graphs) are stored here.
+</p></td>
+</tr>
+<tr>
+<td><p><span class="term"><em class="parameter"><code>options</code></em>:</span></p></td>
+<td><p>
+  Options to ARPACK. See <a class="link" href="igraph-Linalg.html#igraph_arpack_options_t" title="3.1.1. igraph_arpack_options_t — Options for ARPACK."><code class="function">igraph_arpack_options_t</code></a>
+       for details. Supply <code class="constant">NULL</code> to use the defaults. Note that the
+       function overwrites the <code class="literal">n</code> (number of vertices),
+       <code class="literal">nev</code> and <code class="literal">which</code> parameters and it always
+       starts the calculation from a random start vector.
+</p></td>
+</tr>
+</tbody>
+</table></div>
+<p>
+</p>
+<p><b>Returns: </b></p>
+<div class="variablelist"><table border="0" class="variablelist">
+<colgroup>
+<col align="left" valign="top">
+<col>
+</colgroup>
+<tbody><tr>
+<td><p><span class="term"><em class="parameter"><code></code></em></span></p></td>
+<td><p>
+  Error code.
+  </p></td>
+</tr></tbody>
+</table></div>
+<p>
+
+</p>
+<p><b>See also: </b></p>
+<div class="variablelist"><table border="0" class="variablelist">
+<colgroup>
+<col align="left" valign="top">
+<col>
+</colgroup>
+<tbody><tr>
+<td><p><span class="term"><em class="parameter"><code></code></em></span></p></td>
+<td><p>
+  <a class="link" href="igraph-Embedding.html#igraph_adjacency_spectral_embedding" title="1.1. igraph_adjacency_spectral_embedding — Adjacency spectral embedding"><code class="function">igraph_adjacency_spectral_embedding</code></a> to embed the adjacency
+matrix.
+  </p></td>
+</tr></tbody>
+</table></div>
+<p>
+ 
+</p>
+</div>
+<div class="section">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="igraph_dim_select"></a>1.3. <code class="function">igraph_dim_select</code> —  Dimensionality selection.</h3></div></div></div>
+<a class="indexterm" name="id-1.29.2.4.2"></a><p>
+</p>
+<div class="informalexample"><pre class="programlisting">
+igraph_error_t igraph_dim_select(const igraph_vector_t *sv, igraph_int_t *dim);
+</pre></div>
+<p>
+</p>
+<p>
+
+
+
+Dimensionality selection for singular values using
+profile likelihood.
+
+</p>
+<p>
+The input of the function is a numeric vector which contains
+the measure of "importance" for each dimension.
+
+</p>
+<p>
+For spectral embedding, these are the singular values of the adjacency
+matrix. The singular values are assumed to be generated from a
+Gaussian mixture distribution with two components that have different
+means and same variance. The dimensionality d is chosen to
+maximize the likelihood when the d largest singular values are
+assigned to one component of the mixture and the rest of the singular
+values assigned to the other component.
+
+</p>
+<p>
+This function can also be used for the general separation problem,
+where we assume that the left and the right of the vector are coming
+from two normal distributions, with different means, and we want
+to know their border.
+
+</p>
+<p><b>Arguments: </b>
+</p>
+<div class="variablelist"><table border="0" class="variablelist">
+<colgroup>
+<col align="left" valign="top">
+<col>
+</colgroup>
+<tbody>
+<tr>
+<td><p><span class="term"><em class="parameter"><code>sv</code></em>:</span></p></td>
+<td><p>
+  A numeric vector, the ordered singular values.
+</p></td>
+</tr>
+<tr>
+<td><p><span class="term"><em class="parameter"><code>dim</code></em>:</span></p></td>
+<td><p>
+  The result is stored here.
+</p></td>
+</tr>
+</tbody>
+</table></div>
+<p>
+</p>
+<p><b>Returns: </b></p>
+<div class="variablelist"><table border="0" class="variablelist">
+<colgroup>
+<col align="left" valign="top">
+<col>
+</colgroup>
+<tbody><tr>
+<td><p><span class="term"><em class="parameter"><code></code></em></span></p></td>
+<td><p>
+  Error code.
+  </p></td>
+</tr></tbody>
+</table></div>
+<p>
+
+Time complexity: O(n), n is the number of values in sv.
+
+</p>
+<p><b>See also: </b></p>
+<div class="variablelist"><table border="0" class="variablelist">
+<colgroup>
+<col align="left" valign="top">
+<col>
+</colgroup>
+<tbody><tr>
+<td><p><span class="term"><em class="parameter"><code></code></em></span></p></td>
+<td><p>
+  <a class="link" href="igraph-Embedding.html#igraph_adjacency_spectral_embedding" title="1.1. igraph_adjacency_spectral_embedding — Adjacency spectral embedding"><code class="function">igraph_adjacency_spectral_embedding()</code></a>.
+  </p></td>
+</tr></tbody>
+</table></div>
+<p>
+ 
+</p>
+</div>
+</div>
+</div>
+<table class="navigation-footer" width="100%" summary="Navigation footer" cellpadding="2" cellspacing="0"><tr valign="middle">
+<td align="left"><a accesskey="p" href="igraph-HRG.html"><b>← Chapter 27. Hierarchical random graphs</b></a></td>
+<td align="right"><a accesskey="n" href="igraph-Layout.html"><b>Chapter 29. Generating layouts for graph drawing →</b></a></td>
+</tr></table>
+</body>
+</html>

references/igraph-1.0.1/doc/html/igraph-Glossary.html

@@ -0,0 +1,212 @@
+<html>
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
+<title>Chapter 35. Glossary</title>
+<meta name="generator" content="DocBook XSL Stylesheets Vsnapshot">
+<link rel="home" href="index.html" title="igraph Reference Manual">
+<link rel="up" href="index.html" title="igraph Reference Manual">
+<link rel="prev" href="igraph-Advanced.html" title="Chapter 34. Advanced igraph programming">
+<link rel="next" href="igraph-Licenses.html" title="Chapter 36. Licenses for igraph and this manual">
+<script type="text/javascript" src="toggle.js"></script><link rel="stylesheet" href="style.css" type="text/css">
+<link rel="stylesheet" href="https://stackpath.bootstrapcdn.com/font-awesome/4.7.0/css/font-awesome.min.css" type="text/css">
+<link rel="chapter" href="igraph-Introduction.html" title="Chapter 1. Introduction">
+<link rel="chapter" href="igraph-Installation.html" title="Chapter 2. Installation">
+<link rel="chapter" href="igraph-Tutorial.html" title="Chapter 3. Tutorial">
+<link rel="chapter" href="igraph-Basic.html" title="Chapter 4. Basic data types and interface">
+<link rel="chapter" href="igraph-Error.html" title="Chapter 5. Error handling">
+<link rel="chapter" href="igraph-Memory.html" title="Chapter 6. Memory (de)allocation">
+<link rel="chapter" href="igraph-Data-structures.html" title="Chapter 7. Data structure library: vector, matrix, other data types">
+<link rel="chapter" href="igraph-Random.html" title="Chapter 8. Random numbers">
+<link rel="chapter" href="igraph-Iterators.html" title="Chapter 9. Vertex and edge selectors and sequences, iterators">
+<link rel="chapter" href="igraph-Attributes.html" title="Chapter 10. Graph, vertex and edge attributes">
+<link rel="chapter" href="igraph-Generators.html" title="Chapter 11. Deterministic graph generators">
+<link rel="chapter" href="igraph-Games.html" title='Chapter 12. Stochastic graph generators ("games")'>
+<link rel="chapter" href="igraph-Bipartite.html" title="Chapter 13. Bipartite, i.e. two-mode graphs">
+<link rel="chapter" href="igraph-Spatial.html" title="Chapter 14. Spatial graphs">
+<link rel="chapter" href="igraph-Operators.html" title="Chapter 15. Graph operators">
+<link rel="chapter" href="igraph-Visitors.html" title="Chapter 16. Graph visitors">
+<link rel="chapter" href="igraph-Structural.html" title="Chapter 17. Structural properties of graphs">
+<link rel="chapter" href="igraph-Cycles.html" title="Chapter 18. Graph cycles">
+<link rel="chapter" href="igraph-Cliques.html" title="Chapter 19. Cliques and independent vertex sets">
+<link rel="chapter" href="igraph-Motifs.html" title="Chapter 20. Graph motifs, dyad census and triad census">
+<link rel="chapter" href="igraph-Isomorphism.html" title="Chapter 21. Graph isomorphism">
+<link rel="chapter" href="igraph-Coloring.html" title="Chapter 22. Graph coloring">
+<link rel="chapter" href="igraph-Flows.html" title="Chapter 23. Maximum flows, minimum cuts and related measures">
+<link rel="chapter" href="igraph-Separators.html" title="Chapter 24. Vertex separators">
+<link rel="chapter" href="igraph-Community.html" title="Chapter 25. Detecting community structure">
+<link rel="chapter" href="igraph-Graphlets.html" title="Chapter 26. Graphlets">
+<link rel="chapter" href="igraph-HRG.html" title="Chapter 27. Hierarchical random graphs">
+<link rel="chapter" href="igraph-Embedding.html" title="Chapter 28. Embedding of graphs">
+<link rel="chapter" href="igraph-Layout.html" title="Chapter 29. Generating layouts for graph drawing">
+<link rel="chapter" href="igraph-Processes.html" title="Chapter 30. Processes on graphs">
+<link rel="chapter" href="igraph-Foreign.html" title="Chapter 31. Reading and writing graphs from and to files">
+<link rel="chapter" href="igraph-Linalg.html" title="Chapter 32. Using BLAS, LAPACK and ARPACK for igraph matrices and graphs">
+<link rel="chapter" href="igraph-Nongraph.html" title="Chapter 33. Non-graph related functions">
+<link rel="chapter" href="igraph-Advanced.html" title="Chapter 34. Advanced igraph programming">
+<link rel="chapter" href="igraph-Glossary.html" title="Chapter 35. Glossary">
+<link rel="chapter" href="igraph-Licenses.html" title="Chapter 36. Licenses for igraph and this manual">
+<link rel="index" href="ix01.html" title="Index">
+</head>
+<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
+<div class="navigation-header mb-4" width="100%" summary="Navigation header"><div class="btn-group">
+<a accesskey="p" class="btn btn-light" href="igraph-Advanced.html"><i class="fa fa-chevron-left"></i>
+              Previous
+            </a><a accesskey="h" class="btn btn-light" href="index.html"><i class="fa fa-home"></i>
+              Home
+            </a><a accesskey="n" class="btn btn-light" href="igraph-Licenses.html"><i class="fa fa-chevron-right"></i>
+              Next
+            </a>
+</div></div>
+<div class="chapter">
+<div class="titlepage"><div><div><h1 class="title">
+<a name="igraph-Glossary"></a>Chapter 35. Glossary</h1></div></div></div>
+<p>
+    This glossary defines common terms used throughout the igraph
+    documentation.
+  </p>
+<div class="itemizedlist"><ul class="itemizedlist compact" style="list-style-type: disc; ">
+<li class="listitem"><p>
+        <span class="strong"><strong>attribute</strong></span>: A piece of data
+        associated with a vertex, an edge, or the graph itself. The
+        igraph C library currently supports numeric, string and Boolean
+        attribute values, and provides a means for implementing
+        attribute handlers that support custom types.
+      </p></li>
+<li class="listitem"><p>
+        <span class="strong"><strong>adjacent</strong></span>: Two vertices are
+        called <span class="strong"><strong>adjacent</strong></span> if there is
+        an edge connecting them. This term describes a vertex-to-vertex
+        relation.
+      </p></li>
+<li class="listitem"><p>
+        <span class="strong"><strong>adjacency list</strong></span>: A data
+        structure that associates a list of neighbours (i.e. adjacent
+        vertices) to each vertex.
+      </p></li>
+<li class="listitem"><p>
+        <span class="strong"><strong>adjacency matrix</strong></span>: A
+        representation of a graph as a square matrix.
+        <code class="literal">A_ij</code> gives the number of edge endpoints
+        connecting from the <code class="literal">i</code>th vertex to the
+        <code class="literal">j</code>th vertex. Conventionally, the diagonal of
+        the adjacency matrix of an undirected graph contains
+        <span class="emphasis"><em>twice</em></span> the number of self-loops. All igraph
+        functions follow this convention unless noted otherwise.
+      </p></li>
+<li class="listitem"><p>
+        <span class="strong"><strong>biadjacency matrix</strong></span>: Analogous
+        to the adjacency matrix, but used for bipartite graphs. Element
+        <code class="literal">B_ij</code> gives the number of edges from the
+        <code class="literal">i</code>th vertex of the first group to the
+        <code class="literal">j</code>th vertex of the second group.
+      </p></li>
+<li class="listitem"><p>
+        <span class="strong"><strong>bipartite graph</strong></span>: A graph
+        whose vertices can be partitioned into two groups in such a way
+        that connections are present only between members of different
+        groups.
+      </p></li>
+<li class="listitem"><p>
+        <span class="strong"><strong>complete graph</strong></span>: Also called
+        <span class="strong"><strong>full graph</strong></span> within the context
+        of igraph, a graph in which all pairs of vertices are connected
+        to each other.
+      </p></li>
+<li class="listitem"><p>
+        <span class="strong"><strong>connected graph</strong></span>: A connected
+        graph consists of a single component, in which any vertex is
+        reachable from any other. In igraph, the null graph is not
+        considered connected, as it has not one, but zero components.
+      </p></li>
+<li class="listitem"><p>
+        <span class="strong"><strong>edge</strong></span>: A
+        <span class="strong"><strong>connection</strong></span> between two
+        vertices, also called a <span class="strong"><strong>link</strong></span>.
+        In igraph, edges are referred to by integer indices called
+        <span class="strong"><strong>edge IDs</strong></span>.
+      </p></li>
+<li class="listitem"><p>
+        <span class="strong"><strong>finalizer stack</strong></span>: A global
+        stack used internally by igraph to keep track of currently
+        allocated objects and their destructors, so that they can be
+        automatically destroyed in case of an error.
+      </p></li>
+<li class="listitem"><p>
+        <span class="strong"><strong>game</strong></span>: Within igraph, this
+        term is used for stochastic graph generators, i.e. functions
+        that sample from random graph models.
+      </p></li>
+<li class="listitem"><p>
+        <span class="strong"><strong>graph</strong></span> or
+        <span class="strong"><strong>network</strong></span>: A set of vertices
+        with connections between them. In igraph, graphs may carry
+        associated data in the form of vertex, edge or graph attributes.
+      </p></li>
+<li class="listitem"><p>
+        <span class="strong"><strong>incident</strong></span>: An edge is called
+        <span class="strong"><strong>incident</strong></span> to the vertices that
+        are its endpoints. This term describes a vertex-to-edge
+        relation.
+      </p></li>
+<li class="listitem"><p>
+        <span class="strong"><strong>incidence list</strong></span>: A data
+        structure that associates a list of incident edges to each
+        vertex.
+      </p></li>
+<li class="listitem"><p>
+        <span class="strong"><strong>incidence matrix</strong></span>: A matrix
+        describing the incidence relation between vertices (rows) and
+        edges (columns).
+      </p></li>
+<li class="listitem"><p>
+        <span class="strong"><strong>membership vector</strong></span>: Membership
+        vectors are a means of encoding a partitioning of items, usually
+        vertices, into several groups. The <code class="literal">i</code>th
+        element of the vector gives an integer identifier of the group
+        the <code class="literal">i</code>th vertex belongs to. Membership vectors
+        are typically used to describe a vertex clustering obtained
+        through community detection, or by identifying the connected
+        components of a graph.
+      </p></li>
+<li class="listitem"><p>
+        <span class="strong"><strong>multi-edges</strong></span> or
+        <span class="strong"><strong>parallel edges</strong></span>: More than one
+        edge connecting the same two vertices. In a directed graph,
+        <code class="literal">a -&gt; b, a -&gt; b</code> are considered parallel
+        edges, but <code class="literal">a -&gt; b, a &lt;- b</code> are not.
+      </p></li>
+<li class="listitem"><p>
+        <span class="strong"><strong>null graph</strong></span>: A graph with no
+        vertices (and no edges).
+      </p></li>
+<li class="listitem"><p>
+        <span class="strong"><strong>self-loop</strong></span>,
+        <span class="strong"><strong>self-edge</strong></span>, or simply
+        <span class="strong"><strong>loop</strong></span>: An edge that connects a
+        vertex to itself.
+      </p></li>
+<li class="listitem"><p>
+        <span class="strong"><strong>simple graph</strong></span>: A graph that
+        does not have self-loops or multi-edges.
+      </p></li>
+<li class="listitem"><p>
+        <span class="strong"><strong>singleton graph</strong></span>: A graph
+        having a single vertex. This term usually refers to a single
+        vertex with no edges, but note that self-loops may in principle
+        be present.
+      </p></li>
+<li class="listitem"><p>
+        <span class="strong"><strong>vertex</strong></span>: Graphs consist of
+        vertices, also called <span class="strong"><strong>nodes</strong></span>,
+        that are connected to each other. In igraph, vertices are
+        referred to by integer indices called
+        <span class="strong"><strong>vertex IDs</strong></span>.
+      </p></li>
+</ul></div>
+</div>
+<table class="navigation-footer" width="100%" summary="Navigation footer" cellpadding="2" cellspacing="0"><tr valign="middle">
+<td align="left"><a accesskey="p" href="igraph-Advanced.html"><b>← Chapter 34. Advanced igraph programming</b></a></td>
+<td align="right"><a accesskey="n" href="igraph-Licenses.html"><b>Chapter 36. Licenses for igraph and this manual →</b></a></td>
+</tr></table>
+</body>
+</html>

references/igraph-1.0.1/doc/html/igraph-Graphlets.html

@@ -0,0 +1,383 @@
+<html>
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
+<title>Chapter 26. Graphlets</title>
+<meta name="generator" content="DocBook XSL Stylesheets Vsnapshot">
+<link rel="home" href="index.html" title="igraph Reference Manual">
+<link rel="up" href="index.html" title="igraph Reference Manual">
+<link rel="prev" href="igraph-Community.html" title="Chapter 25. Detecting community structure">
+<link rel="next" href="igraph-HRG.html" title="Chapter 27. Hierarchical random graphs">
+<script type="text/javascript" src="toggle.js"></script><link rel="stylesheet" href="style.css" type="text/css">
+<link rel="stylesheet" href="https://stackpath.bootstrapcdn.com/font-awesome/4.7.0/css/font-awesome.min.css" type="text/css">
+<link rel="chapter" href="igraph-Introduction.html" title="Chapter 1. Introduction">
+<link rel="chapter" href="igraph-Installation.html" title="Chapter 2. Installation">
+<link rel="chapter" href="igraph-Tutorial.html" title="Chapter 3. Tutorial">
+<link rel="chapter" href="igraph-Basic.html" title="Chapter 4. Basic data types and interface">
+<link rel="chapter" href="igraph-Error.html" title="Chapter 5. Error handling">
+<link rel="chapter" href="igraph-Memory.html" title="Chapter 6. Memory (de)allocation">
+<link rel="chapter" href="igraph-Data-structures.html" title="Chapter 7. Data structure library: vector, matrix, other data types">
+<link rel="chapter" href="igraph-Random.html" title="Chapter 8. Random numbers">
+<link rel="chapter" href="igraph-Iterators.html" title="Chapter 9. Vertex and edge selectors and sequences, iterators">
+<link rel="chapter" href="igraph-Attributes.html" title="Chapter 10. Graph, vertex and edge attributes">
+<link rel="chapter" href="igraph-Generators.html" title="Chapter 11. Deterministic graph generators">
+<link rel="chapter" href="igraph-Games.html" title='Chapter 12. Stochastic graph generators ("games")'>
+<link rel="chapter" href="igraph-Bipartite.html" title="Chapter 13. Bipartite, i.e. two-mode graphs">
+<link rel="chapter" href="igraph-Spatial.html" title="Chapter 14. Spatial graphs">
+<link rel="chapter" href="igraph-Operators.html" title="Chapter 15. Graph operators">
+<link rel="chapter" href="igraph-Visitors.html" title="Chapter 16. Graph visitors">
+<link rel="chapter" href="igraph-Structural.html" title="Chapter 17. Structural properties of graphs">
+<link rel="chapter" href="igraph-Cycles.html" title="Chapter 18. Graph cycles">
+<link rel="chapter" href="igraph-Cliques.html" title="Chapter 19. Cliques and independent vertex sets">
+<link rel="chapter" href="igraph-Motifs.html" title="Chapter 20. Graph motifs, dyad census and triad census">
+<link rel="chapter" href="igraph-Isomorphism.html" title="Chapter 21. Graph isomorphism">
+<link rel="chapter" href="igraph-Coloring.html" title="Chapter 22. Graph coloring">
+<link rel="chapter" href="igraph-Flows.html" title="Chapter 23. Maximum flows, minimum cuts and related measures">
+<link rel="chapter" href="igraph-Separators.html" title="Chapter 24. Vertex separators">
+<link rel="chapter" href="igraph-Community.html" title="Chapter 25. Detecting community structure">
+<link rel="chapter" href="igraph-Graphlets.html" title="Chapter 26. Graphlets">
+<link rel="chapter" href="igraph-HRG.html" title="Chapter 27. Hierarchical random graphs">
+<link rel="chapter" href="igraph-Embedding.html" title="Chapter 28. Embedding of graphs">
+<link rel="chapter" href="igraph-Layout.html" title="Chapter 29. Generating layouts for graph drawing">
+<link rel="chapter" href="igraph-Processes.html" title="Chapter 30. Processes on graphs">
+<link rel="chapter" href="igraph-Foreign.html" title="Chapter 31. Reading and writing graphs from and to files">
+<link rel="chapter" href="igraph-Linalg.html" title="Chapter 32. Using BLAS, LAPACK and ARPACK for igraph matrices and graphs">
+<link rel="chapter" href="igraph-Nongraph.html" title="Chapter 33. Non-graph related functions">
+<link rel="chapter" href="igraph-Advanced.html" title="Chapter 34. Advanced igraph programming">
+<link rel="chapter" href="igraph-Glossary.html" title="Chapter 35. Glossary">
+<link rel="chapter" href="igraph-Licenses.html" title="Chapter 36. Licenses for igraph and this manual">
+<link rel="index" href="ix01.html" title="Index">
+</head>
+<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
+<div class="navigation-header mb-4" width="100%" summary="Navigation header"><div class="btn-group">
+<a accesskey="p" class="btn btn-light" href="igraph-Community.html"><i class="fa fa-chevron-left"></i>
+              Previous
+            </a><a accesskey="h" class="btn btn-light" href="index.html"><i class="fa fa-home"></i>
+              Home
+            </a><a accesskey="n" class="btn btn-light" href="igraph-HRG.html"><i class="fa fa-chevron-right"></i>
+              Next
+            </a>
+</div></div>
+<div class="chapter">
+<div class="titlepage"><div><div><h1 class="title">
+<a name="igraph-Graphlets"></a>Chapter 26. Graphlets</h1></div></div></div>
+<div class="toc"><dl class="toc">
+<dt><span class="section"><a href="igraph-Graphlets.html#about-graphlets">1.  Introduction</a></span></dt>
+<dt><span class="section"><a href="igraph-Graphlets.html#performing-graphlet-decomposition">2. Performing graphlet decomposition</a></span></dt>
+</dl></div>
+<div class="section">
+<div class="titlepage"><div><div><h2 class="title" style="clear: both">
+<a name="about-graphlets"></a>1.  Introduction</h2></div></div></div>
+<p>
+Graphlet decomposition models a weighted undirected graph
+via the union of potentially overlapping dense social groups.
+This is done by a two-step algorithm. In the first step, a candidate
+set of groups (a candidate basis) is created by finding cliques
+in the thresholded input graph. In the second step,
+the graph is projected onto the candidate basis, resulting in a
+weight coefficient for each clique in the candidate basis.
+</p>
+<p>
+For more information on graphlet decomposition, see
+Hossein Azari Soufiani and Edoardo M Airoldi: "Graphlet decomposition of a weighted network",
+<a class="ulink" href="https://arxiv.org/abs/1203.2821" target="_top">https://arxiv.org/abs/1203.2821</a> and <a class="ulink" href="http://proceedings.mlr.press/v22/azari12/azari12.pdf" target="_top">http://proceedings.mlr.press/v22/azari12/azari12.pdf</a>
+</p>
+<p>
+igraph contains three functions for performing the graphlet
+decomponsition of a graph. The first is <a class="link" href="igraph-Graphlets.html#igraph_graphlets" title="2.1. igraph_graphlets — Calculate graphlets basis and project the graph on it."><code class="function">igraph_graphlets()</code></a>, which
+performs both steps of the method and returns a list of subgraphs
+with their corresponding weights. The other two functions
+correspond to the first and second steps of the algorithm, and they are
+useful if the user wishes to perform them individually:
+<a class="link" href="igraph-Graphlets.html#igraph_graphlets_candidate_basis" title="2.2. igraph_graphlets_candidate_basis — Calculate a candidate graphlets basis"><code class="function">igraph_graphlets_candidate_basis()</code></a> and
+<a class="link" href="igraph-Graphlets.html#igraph_graphlets_project" title="2.3. igraph_graphlets_project — Project a graph on a graphlets basis."><code class="function">igraph_graphlets_project()</code></a>.
+</p>
+<p>
+<em><span class="remark">
+Note: The term "graphlet" is used for several unrelated concepts
+in the literature. If you are looking to count induced subgraphs, see
+<a class="link" href="igraph-Motifs.html#igraph_motifs_randesu" title="4.1. igraph_motifs_randesu — Count the number of motifs in a graph."><code class="function">igraph_motifs_randesu()</code></a> and <a class="link" href="igraph-Isomorphism.html#igraph_subisomorphic_lad" title="4.1. igraph_subisomorphic_lad — Check subgraph isomorphism with the LAD algorithm"><code class="function">igraph_subisomorphic_lad()</code></a>.
+</span></em>
+</p>
+</div>
+<div class="section">
+<div class="titlepage"><div><div><h2 class="title" style="clear: both">
+<a name="performing-graphlet-decomposition"></a>2. Performing graphlet decomposition</h2></div></div></div>
+<div class="toc"><dl class="toc">
+<dt><span class="section"><a href="igraph-Graphlets.html#igraph_graphlets">2.1. <code class="function">igraph_graphlets</code> —  Calculate graphlets basis and project the graph on it.</a></span></dt>
+<dt><span class="section"><a href="igraph-Graphlets.html#igraph_graphlets_candidate_basis">2.2. <code class="function">igraph_graphlets_candidate_basis</code> — Calculate a candidate graphlets basis</a></span></dt>
+<dt><span class="section"><a href="igraph-Graphlets.html#igraph_graphlets_project">2.3. <code class="function">igraph_graphlets_project</code> —  Project a graph on a graphlets basis.</a></span></dt>
+</dl></div>
+<div class="section">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="igraph_graphlets"></a>2.1. <code class="function">igraph_graphlets</code> —  Calculate graphlets basis and project the graph on it.</h3></div></div></div>
+<a class="indexterm" name="id-1.27.3.2.2"></a><p>
+</p>
+<div class="informalexample"><pre class="programlisting">
+igraph_error_t igraph_graphlets(const igraph_t *graph,
+                     const igraph_vector_t *weights,
+                     igraph_vector_int_list_t *cliques,
+                     igraph_vector_t *Mu, igraph_int_t niter);
+</pre></div>
+<p>
+</p>
+<p>
+
+
+
+This function simply calls <a class="link" href="igraph-Graphlets.html#igraph_graphlets_candidate_basis" title="2.2. igraph_graphlets_candidate_basis — Calculate a candidate graphlets basis"><code class="function">igraph_graphlets_candidate_basis()</code></a>
+and <a class="link" href="igraph-Graphlets.html#igraph_graphlets_project" title="2.3. igraph_graphlets_project — Project a graph on a graphlets basis."><code class="function">igraph_graphlets_project()</code></a>, and then orders the graphlets
+according to decreasing weights.
+
+</p>
+<p><b>Arguments: </b>
+</p>
+<div class="variablelist"><table border="0" class="variablelist">
+<colgroup>
+<col align="left" valign="top">
+<col>
+</colgroup>
+<tbody>
+<tr>
+<td><p><span class="term"><em class="parameter"><code>graph</code></em>:</span></p></td>
+<td><p>
+  The input graph, it must be a simple graph, edge directions are
+       ignored.
+</p></td>
+</tr>
+<tr>
+<td><p><span class="term"><em class="parameter"><code>weights</code></em>:</span></p></td>
+<td><p>
+  Weights of the edges, a vector.
+</p></td>
+</tr>
+<tr>
+<td><p><span class="term"><em class="parameter"><code>cliques</code></em>:</span></p></td>
+<td><p>
+  An initialized list of integer vectors. The graphlet basis is
+       stored here. Each element of the list is an integer vector of
+       vertex IDs, encoding a single basis subgraph.
+</p></td>
+</tr>
+<tr>
+<td><p><span class="term"><em class="parameter"><code>Mu</code></em>:</span></p></td>
+<td><p>
+  An initialized vector, the weights of the graphlets will
+       be stored here.
+</p></td>
+</tr>
+<tr>
+<td><p><span class="term"><em class="parameter"><code>niter</code></em>:</span></p></td>
+<td><p>
+  The number of iterations to perform for the projection step.
+</p></td>
+</tr>
+</tbody>
+</table></div>
+<p>
+</p>
+<p><b>Returns: </b></p>
+<div class="variablelist"><table border="0" class="variablelist">
+<colgroup>
+<col align="left" valign="top">
+<col>
+</colgroup>
+<tbody><tr>
+<td><p><span class="term"><em class="parameter"><code></code></em></span></p></td>
+<td><p>
+  Error code.
+  </p></td>
+</tr></tbody>
+</table></div>
+<p>
+
+See also: <a class="link" href="igraph-Graphlets.html#igraph_graphlets_candidate_basis" title="2.2. igraph_graphlets_candidate_basis — Calculate a candidate graphlets basis"><code class="function">igraph_graphlets_candidate_basis()</code></a> and
+<a class="link" href="igraph-Graphlets.html#igraph_graphlets_project" title="2.3. igraph_graphlets_project — Project a graph on a graphlets basis."><code class="function">igraph_graphlets_project()</code></a>.
+ 
+</p>
+</div>
+<div class="section">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="igraph_graphlets_candidate_basis"></a>2.2. <code class="function">igraph_graphlets_candidate_basis</code> — Calculate a candidate graphlets basis</h3></div></div></div>
+<a class="indexterm" name="id-1.27.3.3.2"></a><p>
+</p>
+<div class="informalexample"><pre class="programlisting">
+igraph_error_t igraph_graphlets_candidate_basis(const igraph_t *graph,
+                                     const igraph_vector_t *weights,
+                                     igraph_vector_int_list_t *cliques,
+                                     igraph_vector_t *thresholds);
+</pre></div>
+<p>
+</p>
+<p>
+
+
+
+</p>
+<p><b>Arguments: </b>
+</p>
+<div class="variablelist"><table border="0" class="variablelist">
+<colgroup>
+<col align="left" valign="top">
+<col>
+</colgroup>
+<tbody>
+<tr>
+<td><p><span class="term"><em class="parameter"><code>graph</code></em>:</span></p></td>
+<td><p>
+  The input graph, it must be a simple graph, edge directions are
+       ignored.
+</p></td>
+</tr>
+<tr>
+<td><p><span class="term"><em class="parameter"><code>weights</code></em>:</span></p></td>
+<td><p>
+  Weights of the edges, a vector.
+</p></td>
+</tr>
+<tr>
+<td><p><span class="term"><em class="parameter"><code>cliques</code></em>:</span></p></td>
+<td><p>
+  An initialized list of integer vectors. The graphlet basis is
+       stored here. Each element of the list is an integer vector of
+       vertex IDs, encoding a single basis subgraph.
+</p></td>
+</tr>
+<tr>
+<td><p><span class="term"><em class="parameter"><code>thresholds</code></em>:</span></p></td>
+<td><p>
+  An initialized vector, the (highest possible)
+       weight thresholds for finding the basis subgraphs are stored
+       here.
+</p></td>
+</tr>
+</tbody>
+</table></div>
+<p>
+</p>
+<p><b>Returns: </b></p>
+<div class="variablelist"><table border="0" class="variablelist">
+<colgroup>
+<col align="left" valign="top">
+<col>
+</colgroup>
+<tbody><tr>
+<td><p><span class="term"><em class="parameter"><code></code></em></span></p></td>
+<td><p>
+  Error code.
+  </p></td>
+</tr></tbody>
+</table></div>
+<p>
+
+See also: <a class="link" href="igraph-Graphlets.html#igraph_graphlets" title="2.1. igraph_graphlets — Calculate graphlets basis and project the graph on it."><code class="function">igraph_graphlets()</code></a> and <a class="link" href="igraph-Graphlets.html#igraph_graphlets_project" title="2.3. igraph_graphlets_project — Project a graph on a graphlets basis."><code class="function">igraph_graphlets_project()</code></a>.
+ 
+</p>
+</div>
+<div class="section">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="igraph_graphlets_project"></a>2.3. <code class="function">igraph_graphlets_project</code> —  Project a graph on a graphlets basis.</h3></div></div></div>
+<a class="indexterm" name="id-1.27.3.4.2"></a><p>
+</p>
+<div class="informalexample"><pre class="programlisting">
+igraph_error_t igraph_graphlets_project(const igraph_t *graph,
+                             const igraph_vector_t *weights,
+                             const igraph_vector_int_list_t *cliques,
+                             igraph_vector_t *Mu, igraph_bool_t startMu,
+                             igraph_int_t niter);
+</pre></div>
+<p>
+</p>
+<p>
+
+
+
+Note that the graph projected does not have to be the same that
+was used to calculate the graphlet basis, but it is assumed that
+it has the same number of vertices, and the vertex IDs of the two
+graphs match.
+
+</p>
+<p><b>Arguments: </b>
+</p>
+<div class="variablelist"><table border="0" class="variablelist">
+<colgroup>
+<col align="left" valign="top">
+<col>
+</colgroup>
+<tbody>
+<tr>
+<td><p><span class="term"><em class="parameter"><code>graph</code></em>:</span></p></td>
+<td><p>
+  The input graph, it must be a simple graph, edge directions are
+       ignored.
+</p></td>
+</tr>
+<tr>
+<td><p><span class="term"><em class="parameter"><code>weights</code></em>:</span></p></td>
+<td><p>
+  Weights of the edges in the input graph, a vector.
+</p></td>
+</tr>
+<tr>
+<td><p><span class="term"><em class="parameter"><code>cliques</code></em>:</span></p></td>
+<td><p>
+  An initialized list of integer vectors. The graphlet basis is
+       stored here. Each element of the list is an integer vector of
+       vertex IDs, encoding a single basis subgraph.
+</p></td>
+</tr>
+<tr>
+<td><p><span class="term"><em class="parameter"><code>Mu</code></em>:</span></p></td>
+<td><p>
+  An initialized vector, the weights of the graphlets will
+       be stored here. This vector is also used to initialize the
+       the weight vector for the iterative algorithm, if the
+       <code class="constant">startMu</code> argument is true.
+</p></td>
+</tr>
+<tr>
+<td><p><span class="term"><em class="parameter"><code>startMu</code></em>:</span></p></td>
+<td><p>
+  If true, then the supplied Mu vector is
+       used as the starting point of the iteration. Otherwise a
+       constant 1 vector is used.
+</p></td>
+</tr>
+<tr>
+<td><p><span class="term"><em class="parameter"><code>niter</code></em>:</span></p></td>
+<td><p>
+  The number of iterations to perform.
+</p></td>
+</tr>
+</tbody>
+</table></div>
+<p>
+</p>
+<p><b>Returns: </b></p>
+<div class="variablelist"><table border="0" class="variablelist">
+<colgroup>
+<col align="left" valign="top">
+<col>
+</colgroup>
+<tbody><tr>
+<td><p><span class="term"><em class="parameter"><code></code></em></span></p></td>
+<td><p>
+  Error code.
+  </p></td>
+</tr></tbody>
+</table></div>
+<p>
+
+See also: <a class="link" href="igraph-Graphlets.html#igraph_graphlets" title="2.1. igraph_graphlets — Calculate graphlets basis and project the graph on it."><code class="function">igraph_graphlets()</code></a> and
+<a class="link" href="igraph-Graphlets.html#igraph_graphlets_candidate_basis" title="2.2. igraph_graphlets_candidate_basis — Calculate a candidate graphlets basis"><code class="function">igraph_graphlets_candidate_basis()</code></a>.
+ 
+</p>
+</div>
+</div>
+</div>
+<table class="navigation-footer" width="100%" summary="Navigation footer" cellpadding="2" cellspacing="0"><tr valign="middle">
+<td align="left"><a accesskey="p" href="igraph-Community.html"><b>← Chapter 25. Detecting community structure</b></a></td>
+<td align="right"><a accesskey="n" href="igraph-HRG.html"><b>Chapter 27. Hierarchical random graphs →</b></a></td>
+</tr></table>
+</body>
+</html>

references/igraph-1.0.1/doc/html/igraph-Installation.html

@@ -0,0 +1,661 @@
+<html>
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
+<title>Chapter 2. Installation</title>
+<meta name="generator" content="DocBook XSL Stylesheets Vsnapshot">
+<link rel="home" href="index.html" title="igraph Reference Manual">
+<link rel="up" href="index.html" title="igraph Reference Manual">
+<link rel="prev" href="igraph-Introduction.html" title="Chapter 1. Introduction">
+<link rel="next" href="igraph-Tutorial.html" title="Chapter 3. Tutorial">
+<script type="text/javascript" src="toggle.js"></script><link rel="stylesheet" href="style.css" type="text/css">
+<link rel="stylesheet" href="https://stackpath.bootstrapcdn.com/font-awesome/4.7.0/css/font-awesome.min.css" type="text/css">
+<link rel="chapter" href="igraph-Introduction.html" title="Chapter 1. Introduction">
+<link rel="chapter" href="igraph-Installation.html" title="Chapter 2. Installation">
+<link rel="chapter" href="igraph-Tutorial.html" title="Chapter 3. Tutorial">
+<link rel="chapter" href="igraph-Basic.html" title="Chapter 4. Basic data types and interface">
+<link rel="chapter" href="igraph-Error.html" title="Chapter 5. Error handling">
+<link rel="chapter" href="igraph-Memory.html" title="Chapter 6. Memory (de)allocation">
+<link rel="chapter" href="igraph-Data-structures.html" title="Chapter 7. Data structure library: vector, matrix, other data types">
+<link rel="chapter" href="igraph-Random.html" title="Chapter 8. Random numbers">
+<link rel="chapter" href="igraph-Iterators.html" title="Chapter 9. Vertex and edge selectors and sequences, iterators">
+<link rel="chapter" href="igraph-Attributes.html" title="Chapter 10. Graph, vertex and edge attributes">
+<link rel="chapter" href="igraph-Generators.html" title="Chapter 11. Deterministic graph generators">
+<link rel="chapter" href="igraph-Games.html" title='Chapter 12. Stochastic graph generators ("games")'>
+<link rel="chapter" href="igraph-Bipartite.html" title="Chapter 13. Bipartite, i.e. two-mode graphs">
+<link rel="chapter" href="igraph-Spatial.html" title="Chapter 14. Spatial graphs">
+<link rel="chapter" href="igraph-Operators.html" title="Chapter 15. Graph operators">
+<link rel="chapter" href="igraph-Visitors.html" title="Chapter 16. Graph visitors">
+<link rel="chapter" href="igraph-Structural.html" title="Chapter 17. Structural properties of graphs">
+<link rel="chapter" href="igraph-Cycles.html" title="Chapter 18. Graph cycles">
+<link rel="chapter" href="igraph-Cliques.html" title="Chapter 19. Cliques and independent vertex sets">
+<link rel="chapter" href="igraph-Motifs.html" title="Chapter 20. Graph motifs, dyad census and triad census">
+<link rel="chapter" href="igraph-Isomorphism.html" title="Chapter 21. Graph isomorphism">
+<link rel="chapter" href="igraph-Coloring.html" title="Chapter 22. Graph coloring">
+<link rel="chapter" href="igraph-Flows.html" title="Chapter 23. Maximum flows, minimum cuts and related measures">
+<link rel="chapter" href="igraph-Separators.html" title="Chapter 24. Vertex separators">
+<link rel="chapter" href="igraph-Community.html" title="Chapter 25. Detecting community structure">
+<link rel="chapter" href="igraph-Graphlets.html" title="Chapter 26. Graphlets">
+<link rel="chapter" href="igraph-HRG.html" title="Chapter 27. Hierarchical random graphs">
+<link rel="chapter" href="igraph-Embedding.html" title="Chapter 28. Embedding of graphs">
+<link rel="chapter" href="igraph-Layout.html" title="Chapter 29. Generating layouts for graph drawing">
+<link rel="chapter" href="igraph-Processes.html" title="Chapter 30. Processes on graphs">
+<link rel="chapter" href="igraph-Foreign.html" title="Chapter 31. Reading and writing graphs from and to files">
+<link rel="chapter" href="igraph-Linalg.html" title="Chapter 32. Using BLAS, LAPACK and ARPACK for igraph matrices and graphs">
+<link rel="chapter" href="igraph-Nongraph.html" title="Chapter 33. Non-graph related functions">
+<link rel="chapter" href="igraph-Advanced.html" title="Chapter 34. Advanced igraph programming">
+<link rel="chapter" href="igraph-Glossary.html" title="Chapter 35. Glossary">
+<link rel="chapter" href="igraph-Licenses.html" title="Chapter 36. Licenses for igraph and this manual">
+<link rel="index" href="ix01.html" title="Index">
+</head>
+<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
+<div class="navigation-header mb-4" width="100%" summary="Navigation header"><div class="btn-group">
+<a accesskey="p" class="btn btn-light" href="igraph-Introduction.html"><i class="fa fa-chevron-left"></i>
+              Previous
+            </a><a accesskey="h" class="btn btn-light" href="index.html"><i class="fa fa-home"></i>
+              Home
+            </a><a accesskey="n" class="btn btn-light" href="igraph-Tutorial.html"><i class="fa fa-chevron-right"></i>
+              Next
+            </a>
+</div></div>
+<div class="chapter">
+<div class="titlepage"><div><div><h1 class="title">
+<a name="igraph-Installation"></a>Chapter 2. Installation</h1></div></div></div>
+<div class="toc"><dl class="toc">
+<dt><span class="section"><a href="igraph-Installation.html#igraph-Installation-prerequisites">1. Prerequisites</a></span></dt>
+<dt><span class="section"><a href="igraph-Installation.html#igraph-Installation-installation">2. Installation</a></span></dt>
+<dt><span class="section"><a href="igraph-Installation.html#igraph-Installation-building-the-documentation">3. Building the documentation</a></span></dt>
+<dt><span class="section"><a href="igraph-Installation.html#igraph-Installation-notes-for-package-maintainers">4. Notes for package maintainers</a></span></dt>
+</dl></div>
+<p>
+  This chapter describes building igraph from source code and installing it.
+  The source archive of the latest stable release is always available
+  <a class="ulink" href="https://igraph.org/c/#downloads" target="_top">from the igraph website</a>.
+  igraph is also included in many Linux distributions, as well as several package
+  managers such as <a class="ulink" href="https://vcpkg.io/" target="_top">vcpkg</a> (convenient on Windows),
+  <a class="ulink" href="https://www.macports.org/" target="_top">MacPorts</a> (macOS) and
+  <a class="ulink" href="https://brew.sh/" target="_top">Homebrew</a> (macOS), which provide an easier
+  means of installation. If you decide to use them, please consult their documentation
+  on how to install packages.
+</p>
+<div class="section">
+<div class="titlepage"><div><div><h2 class="title" style="clear: both">
+<a name="igraph-Installation-prerequisites"></a>1. Prerequisites</h2></div></div></div>
+<p>
+    To build igraph from sources, you will need at least:
+  </p>
+<div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; ">
+<li class="listitem"><p>
+        <a class="ulink" href="https://cmake.org" target="_top">CMake</a> 3.18 or later
+      </p></li>
+<li class="listitem"><p>
+        C and C++ compilers
+      </p></li>
+</ul></div>
+<p>
+    Visual Studio 2015 and later are supported. Earlier Visual Studio
+    versions may or may not work.
+  </p>
+<p>
+    Certain features also require the following libraries:
+  </p>
+<div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p>
+        <a class="ulink" href="http://www.xmlsoft.org/" target="_top">libxml2</a>,
+        required for GraphML support
+      </p></li></ul></div>
+<p>
+    igraph bundles a number of libraries for convenience. However, it is
+    preferable to use external versions of these libraries, which may
+    improve performance. These are:
+  </p>
+<div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; ">
+<li class="listitem"><p>
+        <a class="ulink" href="https://gmplib.org/" target="_top">GMP</a> (the bundled
+        alternative is Mini-GMP)
+      </p></li>
+<li class="listitem"><p>
+        <a class="ulink" href="https://www.gnu.org/software/glpk/" target="_top">GLPK</a> (version 4.57 or later)
+      </p></li>
+<li class="listitem"><p>
+        <a class="ulink" href="https://github.com/opencollab/arpack-ng" target="_top">ARPACK</a>
+      </p></li>
+<li class="listitem"><p>
+        <a class="ulink" href="https://github.com/ntamas/plfit" target="_top">plfit</a>
+      </p></li>
+<li class="listitem"><p>
+        A library providing a
+        <a class="ulink" href="https://www.netlib.org/blas/" target="_top">BLAS</a> API
+        (available by default on macOS;
+        <a class="ulink" href="http://www.openmathlib.org/OpenBLAS/" target="_top">OpenBLAS</a> is one
+        option on other systems)
+      </p></li>
+<li class="listitem"><p>
+        A library providing a
+        <a class="ulink" href="https://www.netlib.org/lapack/" target="_top">LAPACK</a>
+        API (available by default on macOS;
+        <a class="ulink" href="http://www.openmathlib.org/OpenBLAS/" target="_top">OpenBLAS</a> is one
+        option on other systems)
+      </p></li>
+</ul></div>
+<p>
+    When building the development version of igraph,
+    <code class="literal">bison</code>, <code class="literal">flex</code> and
+    <code class="literal">git</code> are also required. Released versions do not
+    require these tools.
+  </p>
+<p>
+    To run the tests, <code class="literal">diff</code> is also required.
+  </p>
+</div>
+<div class="section">
+<div class="titlepage"><div><div><h2 class="title" style="clear: both">
+<a name="igraph-Installation-installation"></a>2. Installation</h2></div></div></div>
+<div class="toc"><dl class="toc">
+<dt><span class="section"><a href="igraph-Installation.html#igraph-Installation-general-build-instructions">2.1. General build instructions</a></span></dt>
+<dt><span class="section"><a href="igraph-Installation.html#igraph-Installation-specific-instructions-for-windows">2.2. Specific instructions for Windows</a></span></dt>
+<dt><span class="section"><a href="igraph-Installation.html#igraph-Installation-notable-configuration-options">2.3. Notable configuration options</a></span></dt>
+</dl></div>
+<div class="section">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="igraph-Installation-general-build-instructions"></a>2.1. General build instructions</h3></div></div></div>
+<p>
+      igraph uses a
+      <a class="ulink" href="https://cmake.org/cmake/help/latest/guide/user-interaction/index.html" target="_top">CMake-based
+      build system</a>. To compile it,
+    </p>
+<div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; ">
+<li class="listitem">
+<p>
+          Enter the directory where the igraph sources are:
+</p>
+<pre class="programlisting">
+$ cd igraph
+</pre>
+<p>
+        </p>
+</li>
+<li class="listitem">
+<p>
+          Create a new directory. This is where igraph will be built:
+</p>
+<pre class="programlisting">
+$ mkdir build
+$ cd build
+</pre>
+<p>
+        </p>
+</li>
+<li class="listitem">
+<p>
+          Run CMake, which will automatically configure igraph, and
+          report the configuration:
+</p>
+<pre class="programlisting">
+$ cmake ..
+</pre>
+<p>
+          To set a non-default installation location, such as
+          <code class="literal">/opt/local</code>, use:
+          </p>
+<pre class="programlisting">cmake .. -DCMAKE_INSTALL_PREFIX=/opt/local</pre>
+<p>
+        </p>
+</li>
+<li class="listitem"><p>
+          Check the output carefully, and ensure that all features you
+          need are enabled. If CMake could not find certain libraries,
+          some features such as GraphML support may have been
+          automatically disabled.
+        </p></li>
+<li class="listitem">
+<p>
+          There are several ways to adjust the configuration:
+        </p>
+<div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: circle; ">
+<li class="listitem"><p>
+              Run <code class="literal">ccmake .</code> on Unix-like systems or
+              <code class="literal">cmake-gui</code> on Windows for a convenient
+              interface.
+            </p></li>
+<li class="listitem"><p>
+              Simply edit the <code class="literal">CMakeCache.txt</code> file.
+              Some of the relevant options are listed below.
+            </p></li>
+</ul></div>
+</li>
+<li class="listitem"><p>
+          Once the configuration has been adjusted, run
+          <code class="literal">cmake ..</code> again.
+        </p></li>
+<li class="listitem">
+<p>
+          Once igraph has been successfully configured, it can be built,
+          tested and installed using:
+</p>
+<pre class="programlisting">
+$ cmake --build .
+$ cmake --build . --target check
+$ cmake --install .
+</pre>
+<p>
+        </p>
+</li>
+</ul></div>
+</div>
+<div class="section">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="igraph-Installation-specific-instructions-for-windows"></a>2.2. Specific instructions for Windows</h3></div></div></div>
+<div class="toc"><dl class="toc">
+<dt><span class="section"><a href="igraph-Installation.html#igraph-Installation-microsoft-visual-studio">2.2.1. Microsoft Visual Studio</a></span></dt>
+<dt><span class="section"><a href="igraph-Installation.html#igraph-Installation-msys2">2.2.2. MSYS2</a></span></dt>
+</dl></div>
+<div class="section">
+<div class="titlepage"><div><div><h4 class="title">
+<a name="igraph-Installation-microsoft-visual-studio"></a>2.2.1. Microsoft Visual Studio</h4></div></div></div>
+<p>
+        With Visual Studio, the steps to build igraph are generally the
+        same as above. However, since the Visual Studio CMake generator is
+        a multi-configuration one, we must specify the configuration
+        (typically Release or Debug) with each build command using the
+        <code class="literal">--config</code> option:
+      </p>
+<pre class="programlisting">
+mkdir build
+cd build
+cmake ..
+cmake --build . --config Release
+cmake --build . --target check --config Release
+</pre>
+<p>
+        When building the development version, <code class="literal">bison</code>
+        and <code class="literal">flex</code> must be available on the system.
+        <a class="ulink" href="https://github.com/lexxmark/winflexbison" target="_top"><code class="literal">winflexbison</code></a>
+        for Bison version 3.x can be useful for this purpose—make sure
+        that the executables are in the system <code class="literal">PATH</code>.
+        The easiest installation option is probably by installing
+        <code class="literal">winflexbison3</code> from the
+        <a class="ulink" href="https://chocolatey.org/packages/winflexbison3" target="_top">Chocolatey
+        package manager</a>.
+      </p>
+<div class="section">
+<div class="titlepage"><div><div><h5 class="title">
+<a name="igraph-Installation-vcpkg"></a>2.2.1.1. vcpkg</h5></div></div></div>
+<p>
+          Most external dependencies can be conveniently installed using
+          <a class="ulink" href="https://github.com/microsoft/vcpkg#quick-start-windows" target="_top"><code class="literal">vcpkg</code></a>.
+          Note that <code class="literal">igraph</code> bundles all dependencies
+          except <code class="literal">libxml2</code>, which is needed for GraphML
+          support.
+        </p>
+<p>
+          In order to use vcpkg integrate it in the build environment by executing
+          <code class="literal">vcpkg.exe integrate install</code> on the command line.
+          When configuring igraph, point CMake to the correct
+          <code class="literal">vcpkg.cmake</code> file using <code class="literal">-DCMAKE_TOOLCHAIN_FILE=...</code>,
+          as instructed.
+        </p>
+<p>
+          Additionally, it might be that you need to set the appropriate
+          so-called triplet using
+          <code class="literal">-DVCPKG_TARGET_TRIPLET</code> when running
+          <code class="literal">cmake</code>, for exampling, setting it to
+          <code class="literal">x64-windows</code> when using shared builds of packages or
+          <code class="literal">x64-windows-static</code> when using static builds.
+          Similarly, you also need to specify this target triplet when
+          installing packages. For example, to install
+          <code class="literal">libxml2</code> as a shared library, use
+          <code class="literal">vcpkg.exe install libxml2:x64-windows</code> and to
+          install <code class="literal">libxml2</code> as a static library, use
+          <code class="literal">vcpkg.exe install libxml2:x64-windows-static</code>.
+          In addition, there is the possibility to use a static library
+          with dynamic runtime linking using the
+          <code class="literal">x64-windows-static-md</code> triplet.
+        </p>
+</div>
+</div>
+<div class="section">
+<div class="titlepage"><div><div><h4 class="title">
+<a name="igraph-Installation-msys2"></a>2.2.2. MSYS2</h4></div></div></div>
+<p>
+        MSYS2 can be installed from <a class="ulink" href="https://www.msys2.org/" target="_top">msys2.org</a>. After installing MSYS2,
+        ensure that it is up to date by opening a terminal and running
+        <code class="literal">pacman -Syuu</code>.
+      </p>
+<p>
+        The instructions below assume that you want to compile for a 64-bit
+        target.
+      </p>
+<p>
+        Install the following packages using <code class="literal">pacman -S</code>.
+      </p>
+<div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; ">
+<li class="listitem"><p>
+            Minimal requirements:
+            <code class="literal">mingw-w64-x86_64-toolchain</code>,
+            <code class="literal">mingw-w64-x86_64-cmake</code>.
+          </p></li>
+<li class="listitem"><p>
+            Optional dependencies that enable certain features:
+            <code class="literal">mingw-w64-x86_64-gmp</code>,
+            <code class="literal">mingw-w64-x86_64-libxml2</code>
+          </p></li>
+<li class="listitem"><p>
+            Optional external libraries for better performance:
+            <code class="literal">mingw-w64-x86_64-openblas</code>,
+            <code class="literal">mingw-w64-x86_64-arpack</code>,
+            <code class="literal">mingw-w64-x86_64-glpk</code>
+          </p></li>
+<li class="listitem"><p>
+            Only needed for running the tests: <code class="literal">diffutils</code>
+          </p></li>
+<li class="listitem"><p>
+            Required only when building the development version:
+            <code class="literal">git</code>, <code class="literal">bison</code>,
+            <code class="literal">flex</code>
+          </p></li>
+</ul></div>
+<p>
+        The following command will install of these at once:
+      </p>
+<pre class="programlisting">
+pacman -S \
+  mingw-w64-x86_64-toolchain mingw-w64-x86_64-cmake \
+  mingw-w64-x86_64-gmp mingw-w64-x86_64-libxml2 \
+  mingw-w64-x86_64-openblas mingw-w64-x86_64-arpack \
+  mingw-w64-x86_64-glpk diffutils git bison flex
+</pre>
+<p>
+        In order to build igraph, follow the <span class="strong"><strong>General
+        build instructions</strong></span> above, paying attention to the
+        following:
+      </p>
+<div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; ">
+<li class="listitem"><p>
+            When using MSYS2, start the <span class="quote">“<span class="quote">MSYS2 MinGW 64-bit</span>”</span>
+            terminal, and <span class="emphasis"><em>not</em></span> the <span class="quote">“<span class="quote">MSYS2
+            MSYS</span>”</span> one.
+          </p></li>
+<li class="listitem"><p>
+            Be sure to install the <code class="literal">mingw-w64-x86_64-cmake</code>
+            package and not the <code class="literal">cmake</code> one. The latter
+            will not work.
+          </p></li>
+<li class="listitem"><p>
+            When running <code class="literal">cmake</code>, pass the option
+            <code class="literal">-G"MSYS Makefiles"</code>.
+          </p></li>
+<li class="listitem"><p>
+            Note that <code class="literal">ccmake</code> is not currently available.
+            <code class="literal">cmake-gui</code> can be used only if the
+            <code class="literal">mingw-w64-x86_64-qt5</code> package is installed.
+          </p></li>
+</ul></div>
+</div>
+</div>
+<div class="section">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="igraph-Installation-notable-configuration-options"></a>2.3. Notable configuration options</h3></div></div></div>
+<p>
+      The following options may be set to <code class="literal">ON</code> or
+      <code class="literal">OFF</code>. Some of them have an <code class="literal">AUTO</code>
+      setting, which chooses a reasonable default based on what libraries
+      are available on the current system.
+    </p>
+<div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; ">
+<li class="listitem"><p>
+          igraph bundles some of its dependencies for convenience. The
+          <code class="literal">IGRAPH_USE_INTERNAL_XXX</code> flags control whether
+          these should be used instead of external versions. Set them to
+          <code class="literal">ON</code> to use the bundled
+          (<span class="quote">“<span class="quote">vendored</span>”</span>) versions. Generally, external versions
+          are preferable as they may be newer and usually provide better
+          performance.
+        </p></li>
+<li class="listitem"><p>
+          <code class="literal">IGRAPH_GLPK_SUPPORT</code>: whether to make use of
+          the
+          <a class="ulink" href="https://www.gnu.org/software/glpk/" target="_top">GLPK</a>
+          library. Some features, such as finding a minimum feedback arc
+          set or finding communities through exact modularity
+          optimization, require this.
+        </p></li>
+<li class="listitem"><p>
+          <code class="literal">IGRAPH_GRAPHML_SUPPORT</code>: whether to enable
+          support for reading and writing
+          <a class="ulink" href="http://graphml.graphdrawing.org/" target="_top">GraphML</a>
+          files. Requires the
+          <a class="ulink" href="http://xmlsoft.org/" target="_top">libxml2</a> library.
+        </p></li>
+<li class="listitem"><p>
+          <code class="literal">IGRAPH_INFOMAP_SUPPORT</code>: whether to enable
+          the Infomap community detection algorithm. The Infomap library
+          is licensed under the GPLv3+. Compiling it into igraph causes
+          GPLv3+ to apply to the resulting binary, instead of igraph's
+          GPLv2+ license.
+        </p></li>
+<li class="listitem"><p>
+          <code class="literal">IGRAPH_OPENMP_SUPPORT</code>: whether to use OpenMP
+          parallelization to accelerate certain functions such as PageRank
+          calculation. Compiler support is required.
+        </p></li>
+<li class="listitem"><p>
+          <code class="literal">IGRAPH_ENABLE_LTO</code>: whether to build igraph
+          with link-time optimization, which improves performance. Not
+          supported with all compilers.
+        </p></li>
+<li class="listitem"><p>
+          <code class="literal">IGRAPH_ENABLE_TLS</code>: whether to enable
+          thread-local storage. Required when using igraph from multiple
+          threads.
+        </p></li>
+<li class="listitem"><p>
+          <code class="literal">IGRAPH_WARNINGS_AS_ERRORS</code>: whether to treat
+          compiler warnings as errors. We strive to eliminate all compiler
+          warnings during development so this switch is turned on by default.
+          If your compiler prints warnings for some parts of the code that we
+          did not anticipate, you can turn off this option to prevent the
+          warnings from stopping the compilation.
+        </p></li>
+<li class="listitem"><p>
+          <a class="ulink" href="https://cmake.org/cmake/help/latest/variable/BUILD_SHARED_LIBS.html" target="_top"><code class="literal">BUILD_SHARED_LIBS</code></a>:
+          whether to build a shared library instead of a static one.
+        </p></li>
+<li class="listitem"><p>
+          <code class="literal">BLA_VENDOR</code>: controls which library to use for
+          <a class="ulink" href="https://cmake.org/cmake/help/latest/module/FindBLAS.html" target="_top">BLAS</a>
+          and
+          <a class="ulink" href="https://cmake.org/cmake/help/latest/module/FindLAPACK.html" target="_top">LAPACK</a>
+          functionality.
+        </p></li>
+<li class="listitem"><p>
+          <a class="ulink" href="https://cmake.org/cmake/help/latest/variable/CMAKE_INSTALL_PREFIX.html" target="_top"><code class="literal">CMAKE_INSTALL_PREFIX</code></a>:
+          the location where igraph will be installed.
+        </p></li>
+</ul></div>
+</div>
+</div>
+<div class="section">
+<div class="titlepage"><div><div><h2 class="title" style="clear: both">
+<a name="igraph-Installation-building-the-documentation"></a>3. Building the documentation</h2></div></div></div>
+<p>
+    Most users will not need to build the documentation, as the release
+    tarball contains pre-built HTML documentation in the <code class="literal">doc</code>
+    directory.
+  </p>
+<p>
+    To build the documentation for the development version, simply build the
+    <code class="literal">html</code>, <code class="literal">pdf</code> or <code class="literal">info</code>
+    targets for the HTML, PDF and Info versions of the documentation,
+    respectively.
+  </p>
+<pre class="programlisting">
+$ cmake --build . --target html
+</pre>
+<p>
+    Building the HTML documentation requires Python 3, <code class="literal">xmlto</code>
+    and <code class="literal">source-highlight</code>. On some platforms, it is necessary
+    to explicitly install the docbook-xsl package as well. Building the PDF
+    documentation also requires <code class="literal">xsltproc</code>,
+    <code class="literal">xmllint</code> and <code class="literal">fop</code>. Building the Texinfo
+    documentation also requires the docbook2X package, <code class="literal">xmllint</code>
+    and <code class="literal">makeinfo</code>.
+  </p>
+</div>
+<div class="section">
+<div class="titlepage"><div><div><h2 class="title" style="clear: both">
+<a name="igraph-Installation-notes-for-package-maintainers"></a>4. Notes for package maintainers</h2></div></div></div>
+<div class="toc"><dl class="toc">
+<dt><span class="section"><a href="igraph-Installation.html#igraph-Installation-auto-detection-of-dependencies">4.1. Auto-detection of dependencies</a></span></dt>
+<dt><span class="section"><a href="igraph-Installation.html#igraph-Installation-shared-and-static-builds">4.2. Shared and static builds</a></span></dt>
+<dt><span class="section"><a href="igraph-Installation.html#igraph-Installation-cross-compiling">4.3. Cross-compiling</a></span></dt>
+<dt><span class="section"><a href="igraph-Installation.html#igraph-Installation-additional-notes">4.4. Additional notes</a></span></dt>
+</dl></div>
+<p>
+    This section is for people who package igraph for Linux distros or
+    other package managers. Please read it carefully before packaging
+    igraph.
+  </p>
+<div class="section">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="igraph-Installation-auto-detection-of-dependencies"></a>4.1. Auto-detection of dependencies</h3></div></div></div>
+<p>
+      igraph bundles several of its dependencies (or simplified versions
+      of its dependencies). During configuration time, it checks whether
+      each dependency is present on the system. If yes, it uses it.
+      Otherwise, it falls back to the bundled (<span class="quote">“<span class="quote">vendored</span>”</span>)
+      version. In order to make configuration as deterministic as
+      possible, you may want to disable this auto-detection. To do so, set
+      each of the <code class="literal">IGRAPH_USE_INTERNAL_XXX</code> options
+      described above. Additionally, set <code class="literal">BLA_VENDOR</code> to
+      use the BLAS and LAPACK implementations of your choice. This should
+      be the same BLAS and LAPACK library that igraph's other dependencies
+      (e.g., ARPACK) are linked against.
+    </p>
+<p>
+      For example, to force igraph to use external versions of all
+      dependencies except plfit, and to use OpenBLAS for BLAS/LAPACK, use
+    </p>
+<p>
+</p>
+<pre class="programlisting">
+$ cmake .. \
+    -DIGRAPH_USE_INTERNAL_BLAS=OFF \
+    -DIGRAPH_USE_INTERNAL_LAPACK=OFF \
+    -DIGRAPH_USE_INTERNAL_ARPACK=OFF \
+    -DIGRAPH_USE_INTERNAL_GLPK=OFF \
+    -DIGRAPH_USE_INTERNAL_GMP=OFF \
+    -DIGRAPH_USE_INTERNAL_PLFIT=ON \
+    -DBLA_VENDOR=OpenBLAS \
+    -DIGRAPH_GRAPHML_SUPPORT=ON
+</pre>
+<p>
+    </p>
+</div>
+<div class="section">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="igraph-Installation-shared-and-static-builds"></a>4.2. Shared and static builds</h3></div></div></div>
+<p>
+      On Windows, shared and static builds should not be installed in the same
+      location. If you decide to do so anyway, keep in mind the following:
+      Both builds contain an <code class="literal">igraph.lib</code> file. The static one
+      should be renamed to avoid conflict. The headers from the static build
+      are incompatible with the shared library. The headers from the shared build
+      may be used with the static library, but <code class="literal">IGRAPH_STATIC</code>
+      must be defined when compiling programs that will link to igraph statically.
+    </p>
+<p>
+      These issues do not affect Unix-like systems.
+    </p>
+</div>
+<div class="section">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="igraph-Installation-cross-compiling"></a>4.3. Cross-compiling</h3></div></div></div>
+<p>
+      When building igraph with an internal ARPACK, LAPACK or BLAS, it
+      makes use of f2c, which compiles and runs the <code class="literal">arithchk</code>
+      program at build time to detect the floating point characteristics of the
+      current system. It writes the results into the <code class="literal">arith.h</code>
+      header. However, running this program is not possible when cross-compiling
+      without providing a userspace emulator that can run executables of the
+      target platform on the host system. Therefore, when cross-compiling, you
+      either need to provide such an emulator with the
+      <code class="literal">CMAKE_CROSSCOMPILING_EMULATOR</code> option, or you need to
+      specify a pre-generated version of the <code class="literal">arith.h</code> header
+      file through the <code class="literal">F2C_EXTERNAL_ARITH_HEADER</code>
+      CMake option. An example version of this header follows for the
+      x86_64 and arm64 target architectures on macOS. Warning: Do not use this
+      version of <code class="literal">arith.h</code> on other systems or architectures.
+    </p>
+<p>
+</p>
+<pre class="programlisting">
+#define IEEE_8087
+#define Arith_Kind_ASL 1
+#define Long int
+#define Intcast (int)(long)
+#define Double_Align
+#define X64_bit_pointers
+#define NANCHECK
+#define QNaN0 0x0
+#define QNaN1 0x7ff80000
+</pre>
+<p>
+    </p>
+<p>
+      igraph also checks whether the endianness of <code class="literal">uint64_t</code>
+      matches the endianness of <code class="literal">double</code> on the platform
+      being compiled. This is needed to ensure that certain functions in igraph's
+      random number generator work properly. However, it is not possible to
+      execute this check when cross-compiling without an emulator, so in this
+      case igraph simply assumes that the endianness matches (which is the case
+      for the vast majority of platforms anyway). The only case where you might
+      run into problems is when you cross-compile for Apple Silicon
+      (<code class="literal">arm64</code>) from an Intel-based Mac, in which case CMake
+      might not realize that you are cross-compiling and will try to execute
+      the check anyway. You can work around this by setting
+      <code class="literal">IEEE754_DOUBLE_ENDIANNESS_MATCHES</code> to <code class="literal">ON</code>
+      explicitly before invoking CMake.
+    </p>
+<p>
+      Providing an emulator in <code class="literal">CMAKE_CROSSCOMPILING_EMULATOR</code>
+      has the added benefit that you can run the compiled unit tests on the
+      host platform. We have experimented with cross-compiling to 64-bit ARM
+      CPUs (<code class="literal">aarch64</code>) on 64-bit Intel CPUs (<code class="literal">amd64</code>),
+      and we can confirm that using <code class="literal">qemu-aarch64</code> works as a
+      cross-compiling emulator in this setup.
+    </p>
+</div>
+<div class="section">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="igraph-Installation-additional-notes"></a>4.4. Additional notes</h3></div></div></div>
+<div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; ">
+<li class="listitem"><p>
+          As of igraph 0.10, there is no tangible benefit to using an
+          external GMP, as igraph does not yet use GMP in any
+          performance-critical way. The bundled Mini-GMP is sufficient.
+        </p></li>
+<li class="listitem"><p>
+          Link-time optimization noticeably improves the performance of
+          some igraph functions. To enable it, use
+          <code class="literal">-DIGRAPH_ENABLE_LTO=ON</code>.
+          The <code class="literal">AUTO</code> setting is also supported, and will
+          enable link-time optimization only if the current compiler
+          supports it. Note that this is detected by CMake, and the
+          detection is not always accurate.
+        </p></li>
+<li class="listitem"><p>
+          We saw occasional hangs on Windows when igraph was built for a
+          32-bit target with MinGW and linked to OpenBLAS. We believe this
+          to be an issue with OpenBLAS, not igraph. On this platform, you
+          may want to opt for a different BLAS/LAPACK or the bundled
+          BLAS/LAPACK.
+        </p></li>
+</ul></div>
+</div>
+</div>
+</div>
+<table class="navigation-footer" width="100%" summary="Navigation footer" cellpadding="2" cellspacing="0"><tr valign="middle">
+<td align="left"><a accesskey="p" href="igraph-Introduction.html"><b>← Chapter 1. Introduction</b></a></td>
+<td align="right"><a accesskey="n" href="igraph-Tutorial.html"><b>Chapter 3. Tutorial →</b></a></td>
+</tr></table>
+</body>
+</html>