DEV Community: Denis Sedchenko

ArchLinux Setup Guide For Intel MacBook Pro

Denis Sedchenko — Fri, 02 May 2025 04:53:31 +0000

Intro

This article is a collection of caveats necessary to get Arch Linux up and running on old Intel MacBooks with AMD GPUs.

In my case, it's old MacBookPro11,5

Steps here are based on various articles and hours of painful debugging.

Article skips full Arch setup process, focusing only on MacBook-specific steps.

This article assumes that you’re using:

PipeWire as audio server.
Wayland with Hyprland as a compositor.

Sources

Information in this article is based on following sources:

Bootloader
- rEFInd Installation
- Set Apple OS
- Extra Boot Arguments
- Setting rEFInd as default bootloader
Network
- Network Manager
- Broadcom
GPU Power Management
- Udev Rules
- Kernel Modules
- Use Integrated GPU On Boot Using gpu-switch
- Disable AMDGPU HDMI Audio
- Turn Off Discrete AMD GPU
- Disable dGPU On Boot
- Use iGPU for Hyprland
Power Efficiency
- Battery Monitoring
- iGPU Tweaks
- Pefrormance Power Profile
- Automatic Power Profiles
- Switch Power Profiles Manually

Bootloader

Apple introduces certain limitations for non-macOS systems, such as inability to use Intel GPU.

The most convenient way to bypass them is using rEFInd bootloader.
rEFInd handles MacOS version spoofing, SIP and other stuff out of the box.

rEFInd Installation

Install rEFInd by following instructions from ArchWiki.

⚠️ Important
Don’t forget to add Linux boot configuration into rEFInd config file `/boot/EFI/refind/refind.conf`

Set Apple OS

Apple blocks access to integrated Intel GPU for any non-macOS operating system.

rEFInd provides a way to workaround this with spoof_osx_version config parameter.

Open /boot/EFI/refind/refind.conf and add a following parameter:

spoof_osx_version 12.7

Extra Boot Arguments

Add following options to your Arch Linux menu entry in rEFInd config:

data=writeback libata.force=1:noncq acpi_mask_gpe=0x06 acpi_osi=Darwin i915.modeset=1 amdgpu.modeset=0 amdgpu.runpm=1

Setting rEFInd as default bootloader

Unlike Grub or systemd-boot, rEFInd places itself into a non-standard directory inside EFI partition.

Use efibootmgr to add rEFInd as boot entry:

efibootmgr -c -L 'rEFInd Boot Manager' -l '\EFI\refind\refind_x64.efi'

⚠️ Important
Remove old macOS boot entries using `efibootmgr` to avoid having long boot delays.

Network

Network Manager

NetworkManager won’t let you to connect to a WiFI without a proper dbus session and keychain provider.

The simplest and most reliable way is to use iwd instead:

pacman -S iwd
systemctl disable --now NetworkManager
systemctl enable --now systemd-resolved
systemctl enable --now systemd-networkd
systemctl enable --now iwd

💡 Tip
Check this ArchWiki page for instructions how to connect to a WiFi network.

Broadcom

You might encounter issues related to missing Broadcom firmware.

In that case, installing broadcom-wl might help:

paru broadcom-wl-dmks

Then, create /etc/modprobe.d/broadcom-wl-dkms.conf:

blacklist brcm80211

GPU Power Management

Unfortunately AMD Cape-Verde gGPUs don’t support dynamic power management. This means, dGPU has to be shut down manually in order to save battery.

Udev Rules

Create /etc/udev/rules.d/30-amdgpu-pm.rules

ACTION=="add", SUBSYSTEM=="drm", DRIVERS=="amdgpu", ATTR{device/power/control}="auto"
ACTION=="add", SUBSYSTEM=="drm", DRIVERS=="amdgpu", ATTR{device/power_dpm_force_performance_level}="low"

Kernel Modules

Go to /etc/modprobe.d and create a couple of files.

amdgpu.conf

options amdgpu modeset=0
options amdgpu enable_psr=1
options amdgpu si_support=1
options amdgpu cik_support=1
options amdgpu runpm=1

radeon.conf

options radeon si_support=0
options radeon cik_support=0
options radeon runpm=1

Then run sudo mkinitcpio -P to apply changes.

Use Integrated GPU On Boot Using gpu-switch

Install gpu-switch tool from AUR using Paru.

Then, use a following command to set iGPU as a primary GPU to drive display:

sudo gpu-switch -i

ℹ️ Note
Operation takes affect only after reboot.

Disable AMDGPU HDMI Audio

WirePlumber is using /dev/snd/controlC2 which is AMD GPU's HDMI Audio.

This prevents AMDGPU to put a device into D3 cold state.

Make ~/.config/wireplumber/wireplumber.conf.d/50-disable-dgpu-hdmi.conf:

# disable the HDA function on the Radeon R9 M370X (PCI 01:00.1)
monitor.alsa.rules = [
  {
    matches = [
      { "device.name" = "alsa_card.pci-0000_01_00.1" }
    ]
    actions = { update-props = { device.disabled = true } }
  }
]

After:

restart wireplumber: systemctl --user restart wireplumber
check if DIS-Audio is DynOff: sudo cat /sys/kernel/debug/vgaswitcheroo/switch

Turn Off Discrete AMD GPU

Both GPUs are controlled using Apple's GMUX. It is responsible for turning on and off discrete AMD GPU.

The vga-switcheroo kernel module is responsible for controlling a mux.

# set to integrated
sudo sh -c 'echo IDG > /sys/kernel/debug/vgaswitcheroo/switch'

# turn off dGPU
sudo sh -c 'echo OFF > /sys/kernel/debug/vgaswitcheroo/switch'

# print mux state.
# ensure that "DIS" is "OFF" and "DIS-Audio" is "DynOff"
sudo cat /sys/kernel/debug/vgaswitcheroo/switch

Output of /sys/kernel/vgaswitcheroo/switch should look like this:

0:IGD:+:Pwr:0000:00:02.0
1:DIS: :Off:0000:01:00.0
2:DIS-Audio: :DynOff:0000:01:00.1

Disable dGPU On Boot

Create oneshot systemd unit file /etc/systemd/system/dgpu-poweroff.service:

[Unit]
Description=Disable discrete GPU (vgaswitcheroo OFF)
Requires=sys-kernel-debug.mount
After=sys-kernel-debug.mount

[Service]
Type=oneshot
ExecStart=/bin/sh -c 'echo OFF > /sys/kernel/debug/vgaswitcheroo/switch'

[Install]
WantedBy=multi-user.target suspend.target   # run at boot *and* after resume

Then, start the service:

sudo systemctl daemon-reload
sudo systemctl enable --now dgpu-poweroff.service

Use iGPU for Hyprland

Find GPU PCI of integrated GPU:

$ lspci | grep VGA
00:02.0 VGA compatible controller: Intel Corporation Crystal Well Integrated Graphics Controller (rev 08)
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Venus XT [Radeon HD 8870M / R9 M270X/M370X] (rev 83)

Check what DRI card maps to PCI ID:

$ ls -l /dev/dri/by-path
total 0
lrwxrwxrwx 1 root root  8 Apr 23 03:14 pci-0000:00:02.0-card -> ../card1
lrwxrwxrwx 1 root root 13 Apr 23 03:14 pci-0000:00:02.0-render -> ../renderD128
lrwxrwxrwx 1 root root  8 Apr 23 03:14 pci-0000:01:00.0-card -> ../card0
lrwxrwxrwx 1 root root 13 Apr 23 03:14 pci-0000:01:00.0-render -> ../renderD129

In my case, card1 is Intel and card0 is AMD.

To make Intel GPU a preferred GPU for Hyprland, add following into a ~/.config/hypr/hyprland.conf:

# Prefer iGPU
env = AQ_DRM_DEVICES,/dev/dri/card1

Power Efficiency

Even with disabled AMD GPU, MacBook still consumes about 15–20 watts (which is a lot).

Although there are a lot of things that can be tweaked, the most basic thing to address is setting a correct CPU power profile.

Battery Monitoring

I recommend using battop tool to monitor power consumption during power optimization.

iGPU Tweaks

PSR (panel self-refresh) and FBC (frame-buffer compression) save ~0.3-0.5 W when the screen shows static content.

Create /etc/modprobe.d/i915.conf:

options i915 enable_psr=1
options i915 enable_fbc=1
options i915 enable_dc=1

Pefrormance Power Profile

Automatic Power Profiles

The auto-cpufreq daemon allows automatic CPU power profile configuration based on battery capacity and charging status.

Pros:

Automatic power profile management based on charging state.

Cons:

By default it will put CPU into a power save mode when not connected to a charger. This will cause a drastic performance decrease.
Written in Python and consumes 20MB of RAM which is quite a lot for a simple CPU frequency daemon.

Install auto-cpufreq daemon to automatically control CPU frequency:

paru auto-cpufreq
sudo systemctl enable --now auto-cpufreq

⚠️ Important
Don't install `auto-cpufreq-git` as it's broken.

Switch Power Profiles Manually

power-profiles-deamon package provides DBus service and a tool to switch CPU profiles.

sudo pacman -S power-profiles-daemon
sudo systemctl enable --now power-profiles-daemon.service

Later, you can change power profile to power saver, performance or balanced:

powerprofilesctl set power-saver
powerprofilesctl set balanced

Building Go packages for Windows on ARM

Denis Sedchenko — Sun, 16 Jun 2024 21:59:09 +0000

Intro

Recently, Qualcomm announced list of laptops that will have their new Snapdragon X Elite chip which claim to have the same performance as Apple's M3 processor.

This means that in a near future, market will see more and more Windows on ARM laptops and we as developers should be prepared to that.

This article is structured in Q&A sections to briefly explain the topic.

WoA can emulate x86, isn't it?
Doesn't Go already support cross compilation?
Okay, isn't MinGW already cover that?
So how do I build a program with CGO for WoA?
Is there a more convenient way to use llvm-mingw?
How to use it?
- Result
- How can I integrate this into my CI?

WoA can emulate x86, isn't it?

Although Windows on ARM (WoA) supports x86 and x86-64 emulation, some features like vector instructions (like AVX2) might be not supported, also emulation brings some performance penalty.

People who use libraries like simdjson might be at risk.

Doesn't Go already support cross compilation?

Go offers out-of-box cross compilation support, including ARM64 for Windows, but this doesn't cover CGO.

That means, any program that uses CGO libraries like sqlite3 will require C and/or C++ toolchain for cross-compilation.

Okay, isn't MinGW already cover that?

Most popular solution for cross-compilation from Windows and Linux is MinGW.

Unfortunately, MinGW doesn't support ARM64 target.

MSYS2 toolchain provide ARM support but available only for Windows.

That means that in order to build programs for Windows on ARM on a Linux machine, a different option should be considered as MinGW doesn't support arm64 target.

So how do I build a program with CGO for WoA?

Don't worry, this case is already covered.

There is a llvm-based alternative toolchain that supports WoA - llvm-mingw.

Unfortunately it's not available in most distros except Arch Linux, but you still can download prebuilt binaries from releases page.

Is there a more convenient way to use llvm-mingw?

Yes, sure!

There is a special Docker image with toolchain for all Windows architectures - amd64, x86 and arm64.

Image is called x1unix/go-mingw and offers arm64 target support since go 1.21.

Image uses MinGW for x86 and llvm-mingw for arm64 target.

How to use it?

It's quite simple, just pull the image and call go build command with GOARCH=arm64 environment variable.

For example, let's take a simple WinAPI CGO example from here and build it using Docker image:

Go code



package main

/*
#cgo LDFLAGS: -lkernel32
#include <windows.h>
#include <stdio.h>

// Function to show a MessageBox using WinAPI
void hello() {
  SYSTEM_INFO si;
  ZeroMemory( & si, sizeof(SYSTEM_INFO));
  GetSystemInfo( & si);
  char * arch;
  switch (si.wProcessorArchitecture) {
  case PROCESSOR_ARCHITECTURE_AMD64:
    arch = "AMD64";
    break;
  case PROCESSOR_ARCHITECTURE_INTEL:
    arch = "x86";
    break;
  case PROCESSOR_ARCHITECTURE_ARM:
    arch = "ARM";
    break;
  case PROCESSOR_ARCHITECTURE_ARM64:
    arch = "ARM64";
    break;
  case PROCESSOR_ARCHITECTURE_IA64:
    arch = "IA";
    break;
  default:
    arch = "Unknown";
    break;
  }

  char message[30];
  sprintf(message, "Hello from CGO on %s", arch);

  MessageBox(NULL, message, "Hello World", MB_OK);
}
*/
import "C"
import "fmt"

func main() {
    fmt.Println("Calling C function to open a MessageBox...")
    C.hello()
}



# Go version to use. WoA supported since Go 1.21.

export GO_VERSION=1.22

docker run --rm -it -e GOARCH=arm64 </span>

    -v .:/go/work -w /go/work </span>

    x1unix/go-mingw:$GO_VERSION </span>

    go build -o hello.exe .

Result

After building a program, let's try to run it inside any VM with Windows on Arm.

Parallels Workstation is used for this example.

How can I integrate this into my CI?

As this is a plain Docker image, it can be easily used both in GitHub Actions and Gitlab CI.

Please check CI templates here.

Go WebAssembly Internals - Part 2

Denis Sedchenko — Fri, 04 Nov 2022 06:52:34 +0000

In previous article we covered how to build a simple Go program, interact with host environment by wrapping Go functions as JavaScript functions and how JS-to-Go call magic works under the hood.

This article will cover how Go runtime access global JavaScript objects and helper functions from wasm_exec.js glue-code library and how this mechanism can be exploited to link external JavaScript functions directly to our programs.

WebAssembly Import Object

Although WebAssembly programs are isolated and have no direct access to a browser (or other host environment), each module can import symbols (usually functions) during instantiation that can be used to communicate with outside world.

All module dependencies to import have to be provided in a form of an object with a symbol name as key and function as a value.

On WASM program side, module should do an import with import statement.

(module
    (func $myFunction (;0;) (import "myFunction") (param i32))
)

Browser will link import object to a program during module instantiation process.

const importObject = {
  "myFunction": () => console.log("hello world")
}

WebAssembly.instantiate(/* wasm module binary */, importObject);

Go Runtime Dependencies

Go WebAssembly module imports

Each Go program import a couple of runtime dependencies from import object prepared by Go helper class provided from wasm_exec.js file.

Most of those functions are used for syscall/js package but also there are a few core Go runtime dependencies.

Import object in wasm_exec.js

Each imported function accepts current program stack pointer and may manipulate with go program memory inside this.mem field of Go helper class and return result.

We also see to what exact Go function is will be linked and what params it will return by function key name and comments left above function declarations.

Linking Imported Function

Lets have a look at declaration of syscall/js.stringVal function which present in import object:

//go:build js && wasm

package js

type ref uint64

func stringVal(x string) ref

The stringVal function doesn't have //go:linkname or other compiler directives, so how Go linker know that function implementation is defined in import object?

Function implementation is defined in a separate file js_js.s in the same folder. File is written in a Go assembler language and contains body for each syscall/js dependency.

#include "textflag.h"

TEXT ·stringVal(SB), NOSPLIT, $0
  CallImport
  RET

The CallImport instruction is used to declare and call function imports.
Under the hood, Go compiler will generate an import statement with a path that corresponds to a function (including package name).

There is a proposal to replace CallImport instruction with a more convenient //go:wasmimport compiler directive.

Importing Custom Functions

All information above allows to define and link custom functions directly to a Go program. Execution of such calls are much cheaper from performance standpoint and Go programs and don't require global namespace pollution (function shouldn't be present in window object).

The main downside of this approach is that we have to manually deal with Go program stack, manually read and write data into program memory.

Lets write and import a simple multiplication function. Function will accept 2 integers and will return a result.

Full example source code is available in this repo.

Go Program

Our program will consist of 2 files: a main Go file and accompanying Go assembly file with WASM import.

Program will import and call multiply function which is written in JavaScript.

main.go

package main

import "fmt"

func multiply(a, b int) int

package main() {
    fmt.Println("Multiply result:", multiply(3, 4))
}

main_js.s

#include "textflag.h"

TEXT ·multiply(SB), NOSPLIT, $0
  CallImport
  RET

The textflag.h file is available in $GOROOT/src/runtime directory.

Building Program

Set GOOS and GOARCH environment variables to build a program as WebAssembly module:

GOOS=js GOARCH=wasm go build -o main.wasm main.go

Writing Wrapper

Go SDK provides a wasm_exec.js file with Go helper class that implements Go WebAssembly ABI for browsers and contains an import object that needs to be modified.

Copy of the file is available in $GOROOT/misc/wasm/wasm_exec.js.

Lets extend Go class with a small wrapper which will allow exporting custom functions without touching original Go class implementation.

custom-go.mjs

// Copied from '$GOROOT/misc/wasm/wasm_exec.js'
import './wasm_exec.js';

export default class CustomGo extends global.Go {
  MAX_I32 = Math.pow(2, 32);

  // Copied from 'setInt64'
  setInt64(offset, value) {
    this.mem.setUint32(offset + 0, value, true);
    this.mem.setUint32(offset + 4, this.MAX_I32, true);
  }

  /**
   * Adds function to import object
   * @param name symbol name (package.functionName)
   * @param func function.
   */
  importFunction(name, func) {
    this.importObject.go[name] = func;
  }
}

Function Implementation

Create a main.mjs file that will import and run our WebAssembly program.

import Go from './custom-go.mjs';
import { promises as fs } from 'fs';

// Instantiate Go wrapper instance
const go = new Go();

// Add our function to import object
go.importFunction('main.multiply', sp => {
    sp >>>= 0;  
    const a1 = go.mem.getInt32(sp + 8, true);  // SP + sizeof(int64)  
    const a2 = go.mem.getInt32(sp + 16, true); // SP + sizeof(int64) * 2
    const result = a1 * a2;
    console.log('Got call from Go:', {a1, a2, result});
    go.setInt64(sp + 24, result);
});


// Run the program
const buff = await fs.readFile('./main.wasm');  
const {instance} = await WebAssembly.instantiate(buff, go.importObject);  
await go.run(instance);

Reading arguments

The sp argument is a stack pointer address which is passed to each imported function.
Values of first and second integers should be manually obtained from stack.

Go class has mem property which is an instance of DataView interface. As MDN documentation says:

DataView provides a low-level interface for reading and writing different number values into program memory without having to care about platform endianness.

The this.mem.getInt32 method accepts offset and boolean parameter to indicate that our value is stored in little endian format.

const a1 = go.mem.getInt32(sp + 8, true);  // Stack Pointer + sizeof(int64)
const a2 = go.mem.getInt32(sp + 16, true); // Stack Pointer + sizeof(int64) * 2

Returning result

Result of the function should be put in memory after the last argument on stack.

go.setInt64(sp + 24, result);

Final Result

Lets run our WebAssembly module with multiply function implementation inside Node.js.

Attention: for Node.js 18 and below, WebCrypto API polyfil is required.

$ node ./main.mjs

Got call from Go: { a1: 3, a2: 4, result: 12 }
Multiply result: 12

Full example source code with polyfill is available in this repo.

Go WebAssembly Internals - Part 1

Denis Sedchenko — Sat, 29 Oct 2022 17:56:11 +0000

In Go 1.11 was introduced WebAssembly support. WebAssembly is a binary executable format that was primary designed to run in web browsers but later started to become popular on other targets such as serverless and even Docker.

This series or articles will cover some Go internals that used to communicate with host JavaScript environment, its limitations and hacks that can be achieved by exploiting some undocumented features used for Go runtime internal purpose.

This first article will cover basics of syscall/js package and how Go code invocation from JS works.

Update: The next part of series is already available.

WebAssembly Communication Model

By default, WebAssembly doesn't have direct access to host system (JS world in our case), it can't directly access DOM, BOM (window object) and other JS APIs.

Each WebAssembly module has to declare a list of imported and exported symbols.

Imported symbols usually used to communicate with a browser (or other host environment) and and are linked by a browser during WebAssembly module instantiation. WebAssembly module caller on JS side should pass those symbols as import object.



WebAssembly.instantiate(<wasm module binary>, <import object>);

Exports are used to export module symbols (functions usually) to be executed from JavaScript.

Unlike Go, Emscripten or Rust provide convenient way to import or export symbols from our program.

Go uses imports and exports for it's internal purposes and out of box doesn't provide a convenient way to link Go program functions to exports. I will cover this topic more in depth in next series.

Code Sample

The only way to communicate with JavaScript world is to interact with global namespace (window or globalThis), attaching or obtaining values from it using syscall/js package.

Go provides way to wrap Go functions to JavaScript callable functions using js.FuncOf and assigning them to JS objects (usually global object like window) that can be used to call Go code from JS.

Let's create a simple Go program that will export a simple greeter function that will print a simple "hello world" message.



package main

import (
    "fmt"
    "syscall/js"
)

func main() {
    wait := make(chan struct{})

    // Wrap our Go function as JS function to make it callable.
    jsFunc := js.FuncOf(greeter)

    // Assign our function to window.greeter
    js.Global().Set("greeter", jsFunc)

    // Prevent the program from exit
    <-wait
}

// First argument is JS execution context (this)
// and list of arguments passed to the function.
func greeter(this js.Value, args []js.Value) any {
    if len(args) == 0 {
        // The only way to return an error is to panic.
        panic("Missing name")
    }

    name := args[0].String()
    fmt.Println("Hello", name)
    return name
}

Program should be compiled for WebAssembly architecture with this command:



GOOS=js GOARCH=wasm go build main.go

Run a program

Let's try to run this program. For demonstration purposes, I already created a snippet on Better Go Playground which allows executing Go programs in WASM environment - https://goplay.tools/snippet/sNWAb8yhHtu.

Open the snippet, and select WebAssembly environment as shown on a screenshot below:

Then, click ▶️ Run button. Our program will notify that it's running and expecting greeter function to be called.

Open browser DevTools by pressing F12 key and go to Console tab and call our greeter function.

As you see, our function is working, but how this magic actually works?

JavaScript Invocation Internals

To execute Go WebAssembly program, Go SDK provides a small glue-code file wasm_exec.js which is located in $GOROOT/misc/wasm/wasm_exec.js.

It provides a window.Go object helper which will manage all JS-to-Go communication and will provide access to all JS objects. The syscall/js.FuncOf function using this helper for wrapping Go functions and making them callable from JavaScript.

Exporting Go Function

The js.FuncOf method wraps function to make it callable from JS. Wrapped function is put in specific internal map and have ID assigned to them. When function will be called from JS, wrapper will create an event with call information which will be routed to destination function by ID.

All wrapped Go functions are registered in funcs map inside of syscall/js package. Map key is function ID which will be used to find target function.

Here is a very abstract explanation of how js.FuncOf is working:



var (
  nextFuncID int

  // Key-value pair of function ID and function
  funcs map[int]func

  // Pointer to `wasm_exec.js` Go object in Javascript
  jsGo = js.Global().Get('Go')
)

func js.FuncOf(fn) {
  funcId := nextFuncID
  nextFuncID++

  js.funcs[funcId] = fn
  // Ask Go wasm_exec.js bridge to create a function wrapper using last inserted index
  jsFuncWrapper := jsGo.Get('_makeFuncWrapper').Call(funcId)

  // js.Func is a wrapper between target Go function and JS mapping
  return js.Func{
    id: funcId,
    value: jsFuncWrapper,
  }
}

Go Function Wrapper Anatomy

Let's take a look, how our exported window.greeter function looks like. This function was created by go._makeFuncWrapper method which was called by Go at previous step.

JavaScript allows to get function's source code by calling window.greeter.toString().
Here is how our greeter function is actually look like:



function(){
  var event = {
    id:id,          // Target Go function ID
    this:this,      // JS function execution context
    args:arguments  // Passed arguments
  };
  Go._pendingEvent = event
  Go._resume();
  return event.result;
}

As you see, under the hood it will call Go wasm_exec.js helper object, register an event with Go function and it's arguments and will resume a program to handle the request.

Invoking Target Go Function

When Go function wrapper is called from JavaScript, under the hood wrapper takes passed index of a function, creates an event with passed arguments and stores it in go._pendingEvent.

After that, it will “awake” Go by calling internal Go function wasm_export_resume which is exported by every Go WebAssembly binary as resume function.

wasm_export_resume calls a global event handler function handleEvent() which is located at syscall/js package.

handleEvent reads target function ID and call arguments from _pendingEvent property of JS Go object where we put all function call information inside Go function wrapper.

Then, it gets target Go function from funcs map, calls it and writes call result back to go._pendingEvent.result property. Result of event is retuned by JS wrapper function.

Conclusion

As this article shows, it's easy to export and call Go functions from JavaScript but Go function invocation process quite complex and requires context switching which is an expensive procedure.

The next article will cover process of how Go communicates with JavaScript world under the hood and obtains values from JavaScript world.

Improving Go playground

Denis Sedchenko — Thu, 06 Aug 2020 13:54:11 +0000

Greetings, Go devs.

I often find myself thinking that I often encounter a situation when I need to do some small prototyping (playing with goroutines, etc) and Go's playground often is faster solution than a dedicated IDE window. Unfortunately play.golang.org is very primitive (goplay.space is better but not much), so I've decided to try to create something a bit better.

A few months ago decided to try to create a better version of Go playground that will have a small valuable set of features that make prototyping comfortable enough, such as basic code autocomplete (stdlib only supported), syntax check, snippets and examples. Also as Go in WebAssembly trend starts to grow, WebAssembly support was added.

In addition, user can customize the editor by enabling font ligatures, selecting editor font and some other small subset of options.

I would like to know your opinion and get some feedback.

URL: https://goplay.tools/
Source Code - https://github.com/x1unix/go-playground (contribution is appreciated)

DEV Community: Denis Sedchenko

ArchLinux Setup Guide For Intel MacBook Pro

Intro

Sources

Table Of Contents

Bootloader

rEFInd Installation

Set Apple OS

Extra Boot Arguments

Setting rEFInd as default bootloader

Network

Network Manager

Broadcom

GPU Power Management

Udev Rules

Kernel Modules

Use Integrated GPU On Boot Using gpu-switch

Disable AMDGPU HDMI Audio

Turn Off Discrete AMD GPU

Disable dGPU On Boot

Use iGPU for Hyprland

Power Efficiency

Battery Monitoring

iGPU Tweaks

Pefrormance Power Profile

Automatic Power Profiles

Switch Power Profiles Manually

Building Go packages for Windows on ARM

Intro

WoA can emulate x86, isn't it?

Doesn't Go already support cross compilation?

Okay, isn't MinGW already cover that?

So how do I build a program with CGO for WoA?

Is there a more convenient way to use llvm-mingw?

How to use it?

Result

How can I integrate this into my CI?

Go WebAssembly Internals - Part 2

WebAssembly Import Object

Go Runtime Dependencies

Linking Imported Function

Importing Custom Functions

Go Program

Building Program

Writing Wrapper

Function Implementation

Reading arguments

Returning result

Final Result

Go WebAssembly Internals - Part 1

WebAssembly Communication Model

Code Sample

Run a program

JavaScript Invocation Internals

Exporting Go Function

Go Function Wrapper Anatomy

Invoking Target Go Function

Conclusion

Improving Go playground