Rexicon226

// https://github.com/facebook/folly/blob/1c8bc50e88804e2a7361a57cd9b551dd10f6c5fd/folly/memcpy.S
export fn memcpy(maybe_dest: ?[*]u8, maybe_src: ?[*]const u8, len: usize) callconv(.C) ?[*]u8 {
    if (@expect(len == 0, false)) {
        return maybe_dest;
    }

    const dest = maybe_dest.?;
    const src = maybe_src.?;

    if (@expect(len < 8, false)) {

marler8997

Since people seem to enjoy making scripting languages so much (not meant to be a "dig", I like this)...here's a scripting language I'd be very interested in.

ZigScript

"A companion scripting language meant for Zig developers."

Zig is my language of choice, but I still reach for Python when I want to make something fast or "short lived". However, Python has downsides, it's hard to build the interpreter for it (especially a static executable), its packaging system is a mess and it's got some interesting syntax choices that would feel foreign to a native Zig developer, but overall I think the core of the language is brilliant. I imagine ZigScript as Python but in a "Zig Style" syntax with the problems fixed. Here are some features that come to mind:

kassane

A simple overview of Zig's std.log for Zig v0.12.0 or higher

Logging functionality that supports:

• If a log message should be printed is determined at comptime, meaning zero overhead for unprinted messages (so just leave the code peppered with debug logs, but when it makes sense scope them; so downstream users can filter them out)
• Scoped log messages
• Different log levels per scope
• Overrideable log output (write to file, database, etc.)
• All the standard std.fmt formatting magic

Basic Usage:

floooh

Tested on macOS:

1. Install the CodeLLDB VSCode extension. Unlike the debugger in the C/C++ extension, this allows to set breakpoints inside Zig "test" blocks (in the MS C/C++ extension debugger, breakpoints inside test blocks will be disabled once the debugger starts for unknown reasons.
2. When compiling the test, tell it to also emit a binary: zig test -femit-bin=zig-out/bin/my-test src/bla.zig, otherwise there will be no executable to debug.
3. The compiled test executable expects the path to the Zig executable as first command line argument, the launch.json file needs to be setup accordingly (note the args item):

christianparpart

Synchronized Output

Synchronized output is merely implementing the feature as inspired by iTerm2 synchronized output, except that it's not using the rare DCS but rather the well known SM ? and RM ?. iTerm2 has now also adopted to use the new syntax instead of using DCS.

Semantics

When rendering the screen of the terminal, the Emulator usually iterates through each visible grid cell and renders its current state. With applications updating the screen a at higher frequency this can cause tearing.

This mode attempts to mitigate that.

ctsrc

Guide: Run FreeBSD 13.1-RELEASE for ARM64 in QEMU on Apple Silicon Mac (MacBook Pro M1, etc) with HVF acceleration (Hypervisor.framework)

This guide was adapted from https://gist.github.com/niw/e4313b9c14e968764a52375da41b4278#running-ubuntu-server-for-arm64

Running FreeBSD 13.1-RELEASE for ARM64

1. Install Xcode from App Store or install Command Line Tools on your Mac running on Apple Silicon.

adrusi

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

const builtin = @import("builtin");
const TypeInfo = builtin.TypeInfo;
const TypeId = builtin.TypeId;  

/// Iterator based on async functions. Equivalent to generators in Python,
/// Javascript, etc.
///

chexxor

The Elm Architecture is the wrong abstraction for the web

In this article, I'd like to explain why I think The Elm Architecture is fine for small components, but quite harmful for websites based on pages.

Definition and Pros/Cons

First, let's clarify what I mean by "The Elm Architecture".

The Elm Architecture's webpage describes it pretty well.