antoinevg

macOS Internals

Understand your Mac and iPhone more deeply by tracing the evolution of Mac OS X from prelease to Swift. John Siracusa delivers the details.

Starting Points

How to use this gist

You've got two main options:

Because cross-compiling binaries for Windows is easier than building natively

I want Microsoft to do better, want Windows to be a decent development platform-and yet, I constantly see Microsoft playing the open source game: advertising how open-source and developer friendly they are - only to crush developers under the heel of the corporate behemoth's boot.

The people who work at Microsoft are amazing, kind, talented individuals. This is aimed at the company's leadership, who I feel has on many occassions crushed myself and other developers under. It's a plea for help.

The source of truth for the 'open source' C#, C++, Rust, and other Windows SDKs is proprietary

You probably haven't heard of it before, but if you've ever used win32 API bindings in C#, C++, Rust, or other languages, odds are they were generated from a repository called microsoft/win32metadata.

At the beginning of 2030, I found this essay in my archives. From what I know today, I think it was very insightful at the moment of writing. And I feel it should be published because it can teach us, Rust developers, how to prevent that sad story from happening again.

What killed Haskell, could kill Rust, too

What killed Haskell, could kill Rust, too. Why would I even mention Haskell in this context? Well, Haskell and Rust are deeply related. Not because Rust is Haskell without HKTs. (Some of you know what that means, and the rest of you will wonder for a very long time). Much of the style of Rust is similar in many ways to the style of Haskell. In some sense Rust is a reincarnation of Haskell, with a little bit of C-ish like syntax, a very small amount.

Is Haskell dead?

Problem: Controlling a remote Mac desktop using a tool like Barrier or Synergy doesn't allow for trackpad gestures to be sent to the client machine.

Solution: Use Better Touch Tool on host machine to handle the gestures and send a remote command to the client machine.

Steps to setup:

[1] On the CLIENT machine in BTT setup these Named triggers:

Follow-up to Method on Emulating Higher-Kinded Types (HKTs) in Rust

First off, thanks for all the comments and kind words on the original writeup; I've been meaning to follow up on some of the suggestions and write about the different ways to represent monads (and functors, HKTs, etc) that now exist, but a month of being busy has kind of gotten in the way (mainly with three new kittens!).

And for sure, I do not expect (nor do I want) this to become the norm for production-level Rust: rather, I hope that this can contribute to the foundations of programming with higher-level abstractions in Rust, somewhat like how early template metaprogramming in C++ and typeclass-constraint-unification metaprogramming in Haskell have contributed, perhaps indirectly, to later innovations in their respective languages and ecosystems that were much more reasoned, sound and usable.

Changes, Edits, Refinements

One of the things suggested in the com

Method for Emulating Higher-Kinded Types in Rust

Intro

I've been fiddling about with an idea lately, looking at how higher-kinded types can be represented in such a way that we can reason with them in Rust here and now, without having to wait a couple years for what would be a significant change to the language and compiler.

There have been multiple discussions on introducing higher-ranked polymorphism into Rust, using Haskell-style Higher-Kinded Types (HKTs) or Scala-looking Generalised Associated Types (GATs). The benefit of higher-ranked polymorphism is to allow higher-level, richer abstractions and pattern expression than just the rank-1 polymorphism we have today.

As an example, currently we can express this type:

Bootstrapping Rust with xtensa support

Build xtensa llvm from here https://esp32.com/viewtopic.php?t=9226&p=38466

But add the X86 target like so

cmake ../llvm-xtensa -DLLVM_TARGETS_TO_BUILD="Xtensa;X86" -DCMAKE_BUILD_TYPE=Release -G "Ninja"

AES67 (an open standard for high quality audio over IP) is becoming mainstream in the world of broadcast and professional audio industries, however there is a very limited amount of open source software available to interoperate with it. As a result we are often just replacing XLRs with Ethernet, without taking advantage of the possibilites the software give. While Virtual Soundcards enable some of this, native network implementations would allow greater flexibility.

This is my wishlist of things that would help change that. Hopefully one day it can be turned into a AES67 Awesome List.

As open source has resulted in very rapid evolution of the web, I believe the same is possible for professional/broadcast audio.

It is possible that some of this already exists and I just havn't found it yet. Please add a comment below if you know of something!

	#!/usr/bin/env python3

	"""
	# STM32H7 SWO Output Solution
	Author: Brian Khuu 2020
	Main Copy: https://gist.github.com/mofosyne/178ad947fdff0f357eb0e03a42bcef5c

	This generates codes that enables SWO output for STM32H7 and was tested on NUCLEO-H743ZI2.
	This is required because stm32h7 changed the registers that OpenOCD expects for SWO output.
	Best to use 400Mhz, tried lower... but had issue with getting stable uart output

	// Tiny "Hello, World!" program in Rust.
	#![feature(no_core, lang_items)]
	#![no_std]
	#![no_core]
	#![no_main]

	#[lang = "panic_info"]
	struct PanicInfo {}
	#[panic_handler]
	fn panic(info: &PanicInfo) -> ! { loop {} }