mitchellh

//! Renderer implementation for Metal.
//!
//! Open questions:
//!
pub const Metal = @This();

const std = @import("std");
const builtin = @import("builtin");
const glfw = @import("glfw");
const objc = @import("objc");

mitchellh

//! A zig builder step that runs "libtool" against a list of libraries
//! in order to create a single combined static library.
const LibtoolStep = @This();

const std = @import("std");
const Step = std.build.Step;
const RunStep = std.build.RunStep;
const FileSource = std.build.FileSource;

pub const Options = struct {

mitchellh

const std = @import("std");
const builtin = @import("builtin");
const assert = std.debug.assert;
const Allocator = std.mem.Allocator;
const ArenaAllocator = std.heap.ArenaAllocator;
const StreamingParser = std.json.StreamingParser;
const Token = std.json.Token;
const TokenTag = std.meta.FieldEnum(Token);

/// Field options are options that can be set per-field on a struct at

mitchellh

const std = @import("std");
const assert = std.debug.assert;
const Allocator = std.mem.Allocator;
const builtin = @import("builtin");

const log = std.log.scoped(.flatpak);

/// Returns true if we're running in a Flatpak environment.
pub fn isFlatpak() bool {
    return if (std.fs.accessAbsolute("/.flatpak-info", .{})) true else |_| false;

mitchellh

const std = @import("std");
const assert = std.debug.assert;

/// An intrusive heap implementation backed by a pairing heap[1] implementation.
///
/// Why? Intrusive data structures require the element type to hold the metadata
/// required for the structure, rather than an additional container structure.
/// There are numerous pros/cons that are documented well by Boost[2]. For Zig,
/// I think the primary benefits are making data structures allocation free
/// (rather, shifting allocation up to the consumer which can choose how they

mitchellh

let
  # Playdate distributes their SDK as precompiled x86_64 binaries
  # currently so we have to import cross-compiled packages for it
  # if we're not on an x86_64 system.
  pkgsIntel = import <nixpkgs> {
    crossSystem = {
      config = "x86_64-unknown-linux-gnu";
    };
  };
in

mitchellh

//! Implements a texture atlas (https://en.wikipedia.org/wiki/Texture_atlas).
//!
//! The implementation is based on "A Thousand Ways to Pack the Bin - A
//! Practical Approach to Two-Dimensional Rectangle Bin Packing" by Jukka
//! Jylänki. This specific implementation is based heavily on
//! Nicolas P. Rougier's freetype-gl project as well as Jukka's C++
//! implementation: https://github.com/juj/RectangleBinPack
//!
//! Limitations that are easy to fix, but I didn't need them:
//!

mitchellh

diff --git a/machines/vm-arch/aarch64-linux.nix b/machines/vm-arch/aarch64-linux.nix
index 7944fbc..932ce99 100644
--- a/machines/vm-arch/aarch64-linux.nix
+++ b/machines/vm-arch/aarch64-linux.nix
@@ -9,6 +9,13 @@
     '';
   }];
 
+  # Disable the default module and import our override. We have
+  # customizations to make this work on aarch64.

mitchellh

This module contains operations for working with radix trees. A radix tree
is a data structure for efficient storage and lookup of values that often
share prefixes, typically used with strings.

A common question when I show this to people is: how do I add to the tree?
delete? update? For these, grab the Range of the tree, use set logic to 
add/remove any elements, and construct a new tree with RadixTree.

For educational purposes, I've heavily commented all the operations. I 
recommend using the constant expression evaluator to try the building blocks

mitchellh

self: super: {
  consul-bin = self.callPackage ./hashicorp-generic.nix {
    name = "consul";
    version = "1.7.3";
    sha256 = "0k03n7h5h8miqhh3n3y47894vhwdcp8m611w55f826swmq9angl1";
  };
  
  # and so on...
}