TL;DR: Use var
for properties in struct
as long as it serves as a nominal tuple. In most cases, there is no obvious benefit to using let
for struct
properties.
Let's start with a simple example:
struct MyStruct {
// | |
// UUIDv7.swift | |
// UUIDv7 | |
// | |
// Created by Yoshimasa Niwa on 7/25/25. | |
// | |
import Foundation | |
import Security |
import Foundation | |
public enum ChunkedDataTaskError: Swift.Error { | |
case notSuccess(_ data: Data, _ httpResponse: HTTPURLResponse) | |
} | |
private extension Int { | |
var isSuccess: Bool { | |
(200 ..< 300).contains(self) |
import AppKit | |
import SwiftUI | |
public struct TextView: NSViewRepresentable { | |
@Binding | |
var text: String | |
var font: NSFont? | |
public init( | |
text: Binding<String> |
import Foundation | |
import Observation | |
func onChange<Value>( | |
of value: @autoclosure () -> Value, | |
initial: Bool = false, | |
perform: (_ oldValue: Value, _ newValue: Value) -> Void, | |
_: isolated Actor = #isolation | |
) async throws { | |
let (stream, continuation) = AsyncThrowingStream.makeStream(of: Void.self) |
#!/usr/bin/env bash | |
for i in {0..255}; do | |
printf "\x1b[48;5;%sm%3d\e[0m " "$i" "$i" | |
if (( i == 15 )) || (( i > 15 )) && (( (i-15) % 6 == 0 )); then | |
printf "\n" | |
fi | |
done |
diff --git a/comfy/ldm/genmo/vae/model.py b/comfy/ldm/genmo/vae/model.py | |
index b68d48a..694b33a 100644 | |
--- a/comfy/ldm/genmo/vae/model.py | |
+++ b/comfy/ldm/genmo/vae/model.py | |
@@ -78,7 +78,12 @@ class PConv3d(ops.Conv3d): | |
# Apply padding. | |
assert self.padding_mode == "replicate" # DEBUG | |
mode = "constant" if self.padding_mode == "zeros" else self.padding_mode | |
+ is_mps_device = x.device.type == "mps" | |
+ if is_mps_device: |
#!/usr/bin/env xcrun swift | |
import Foundation | |
import MetalPerformanceShaders | |
import MetalPerformanceShadersGraph | |
let device = MTLCreateSystemDefaultDevice()! | |
//let size = 256 * 256 - 1 // This size should work | |
let size = 256 * 256 // This size may not work |
#!/usr/bin/env ruby | |
require 'optparse' | |
require 'pathname' | |
def update_name(name, options) | |
pattern = /#{options[:rpath]}/ | |
if name =~ pattern | |
suffix = $' | |
if options[:path].join(suffix).exist? |
This is the tale of a long weekend spent uncovering a mysterious iOS 18 Neural Engine bug—a journey of problem-solving in a system where full visibility is elusive, especially in the locked-down world of Apple’s platforms. But the process I followed is a general approach you can use for any opaque system. It all began last week when I stumbled upon a strange behavior in my iOS app. The output generated from a CoreML model was completely broken—something I had never seen before. And after some digging, I realized this only happened when the model was running on the Neural Engine of iOS 18. The first step was triage. I implemented a quick workaround in the app: if the device is running iOS 18, switch from the Neural Engine to the GPU. This temporarily solved the issue, but I had no idea why it worked or whether other CoreML models in the app’s pipeline might also be affected. Without a deeper understanding of the root cause, I knew I cou