philschmid

Begin by enclosing all thoughts within <thinking> tags, exploring multiple angles and approaches.
Break down the solution into clear steps within <step> tags. Start with a 20-step budget, requesting more for complex problems if needed.
Use <count> tags after each step to show the remaining budget. Stop when reaching 0.
Continuously adjust your reasoning based on intermediate results and reflections, adapting your strategy as you progress.
Regularly evaluate progress using <reflection> tags. Be critical and honest about your reasoning process.
Assign a quality score between 0.0 and 1.0 using <reward> tags after each reflection. Use this to guide your approach:

0.8+: Continue current approach
0.5-0.7: Consider minor adjustments
Below 0.5: Seriously consider backtracking and trying a different approach

unixzii

Introduction

Apple restricted the access to Xcode LLM (Predictive code completion) feature on China models of Mac. This guide provides a way to bypass that restriction. It's verified on macOS 15.0 Beta (24A5264n), but there is no guarentee that it will always work on later macOS versions.

Prerequisites

• Xcode is installed and run at least once.
• SIP debugging restrictions are disabled (via csrutil enable --without debug command in recovery mode).

Disclaimer

zhuowei

// Allows disabling Same-Origin Policy on iOS WKWebView.
// Tested on iOS 12.4.
// Uses private API; obviously can't be used on app store.

@import WebKit;
@import ObjectiveC;

void WKPreferencesSetWebSecurityEnabled(id, bool);

@interface WDBFakeWebKitPointer: NSObject

liuliu

#!/usr/bin/env python

import argparse
import subprocess
import plistlib
import os
import xml.etree.ElementTree as ET

TEAM = '___YOUR_TEAM_ID__'

lisawolderiksen

Using Git Commit Message Templates to Write Better Commit Messages

The always enthusiastic and knowledgeable mr. @jasaltvik shared with our team an article on writing (good) Git commit messages: How to Write a Git Commit Message. This excellent article explains why good Git commit messages are important, and explains what constitutes a good commit message. I wholeheartedly agree with what @cbeams writes in his article. (Have you read it yet? If not, go read it now. I'll wait.) It's sensible stuff. So I decided to start following the

pakLebah

{
  // Use IntelliSense to learn about possible attributes.
  // Hover to view descriptions of existing attributes.
  // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
  "version": "0.2.0",
  "configurations": [
    {
      "type": "lldb",
      "name": "LLDB",
      "cwd" : "${workspaceFolder}",

armadsen

michaeleisel

#import "fishhook.h" // from https://github.com/facebook/fishhook

// Replace write and writev, the two "chokepoint" functions that writes to stderr and stdout will probably pass through
static int (*originalWritev)(int fd, const struct iovec *v, int n);
static int (*originalWrite)(int fd, const void *buf, size_t size);

void checkForBadConstraintsMessage(int fd, const char *string, size_t size) {
    if (strnstr(string, "UIViewAlertForUnsatisfiableConstraints", size)) {
        // Write it to the console anyways before crashing
        originalWrite(fd, string, size);

kam800

# This snippet shows how to enable dyld `closured` and how to fix `read` implementation in dyld using lldb.
# Following text is a bash/lldb command mix and it contains the relevant stdout content and my comments.

// `DYLD_PRINT_WARNINGS=1` environment variable will print dyld logs
$ DYLD_PRINT_WARNINGS=1 lldb /Users/kamil.borzym/tmp/TestMacApp.app/Contents/MacOS/TestMacApp

(lldb) process launch --stop-at-entry

(lldb) image list
[  0] D355CCB5-8584-33E3-8DF7-7BA95BAD41AF 0x0000000100000000 /Users/kamil.borzym/tmp/TestMacApp.app/Contents/MacOS/TestMacApp

tclementdev

libdispatch efficiency tips

The libdispatch is one of the most misused API due to the way it was presented to us when it was introduced and for many years after that, and due to the confusing documentation and API. This page is a compilation of important things to know if you're going to use this library. Many references are available at the end of this document pointing to comments from Apple's very own libdispatch maintainer (Pierre Habouzit).

My take-aways are:

• You should create very few, long-lived, well-defined queues. These queues should be seen as execution contexts in your program (gui, background work, ...) that benefit from executing in parallel. An important thing to note is that if these queues are all active at once, you will get as many threads running. In most apps, you probably do not need to create more than 3 or 4 queues.

• Go serial first, and as you find performance bottle necks, measure why, and if concurrency helps, apply with care, always validating under system pressure. Reuse