Live data from Hacker News

Adventures in Advent of Code

davedelong.com

11–20 of 71 posts

Re: Adventures in Advent of Code

#11

I'll be doing AoC in C this year. And I've decided to do that every year as I enjoy doing it in C and trying to get the entire calendar, all 50 parts to run in less than one second on a single core, which it turns out is quite doable, but only with a much deeper understanding of the problems. I end up learning a lot more computer science this way. I also like it since I don't do any work or even side projects in C th…

Nice! I’m writing in C this year too, although I’m very much a beginner in C.

What kinds of optimisations have you had to do? Are you hosting your code anywhere?

Re: Adventures in Advent of Code

#12

I'll be doing AoC in C this year. And I've decided to do that every year as I enjoy doing it in C and trying to get the entire calendar, all 50 parts to run in less than one second on a single core, which it turns out is quite doable, but only with a much deeper understanding of the problems. I end up learning a lot more computer science this way. I also like it since I don't do any work or even side projects in C th…

Hat tip if you did 2021:14:2 under this constraint. I didn’t find the trick to allow that type of performance.

Re: Adventures in Advent of Code

#15
I'm confused. The post mentioned that this was fixed in Swift 5.7, but I have Swift 5.7.1 on my macOS Monterey and the bug is still present if I modify my AoC solution to exhibit the problem. Is Swift 5.7.1 on Monterey different from the 5.7.1 on Ventura?

    $ swift -v
    Apple Swift version 5.7.1 (swiftlang-5.7.1.135.3 clang-1400.0.29.51)
    Target: arm64-apple-macosx12.0
I love Swift as a language, but the lack of release notes for 5.7.1 (aside from a blog post for 5.7 as a whole), OS-specific releases (especially for SwiftUI), Xcode removing old toolchains when it upgrades (making me re-download tvOS 15.4 runtime for no reason), and all these other little things are starting to weigh on me.

Re: Adventures in Advent of Code

#16
> The bug is fixed in Swift 5.7, but my computer is running macOS Monterey (12.6) and thus using an earlier version of Swift. I have since confirmed that the code works as expected on macOS Ventura.

I guess the bug is apparently in the Swift runtime itself, and since Swift 5.0 and ABT stability, the runtime version is tied to the OS version.

https://www.swift.org/blog/abi-stability-and-apple/

But I think that only applies to deployments via the App Store. I think for local development you can run against the current runtime by setting the TOOLCHAINS environment variable (you may also need to set SDKROOT).

https://www.swift.org/getting-started/#on-macos

ETA. Apple does not make it easy to replace the runtime, but I got it to work like this:

    $ sw_vers
    ProductName: macOS
    ProductVersion: 12.6
    BuildVersion: 21G115
    
    $ cat foo.swift
    let a = "gnmCjzwnmCPTPhBwPjzBgqPjllJJSWlhfhQDSrpJRhDSlfJl"
    let b = "rLHNHrLHVNbVHMMctZFHsbcsDSDWpSDSGfSRsRWSRllfGSSG"
    let c = "NNtdMVrLNdZNvLvLZrzCndqBgwwPmwgjggBn"
    
    var s1 = Set(a)
    s1.formIntersection(b)
    s1.formIntersection(c)
    print(s1)
    
    var s2 = Set(a)
    s2.formIntersection(Set(b))
    s2.formIntersection(Set(c))
    print(s2)
    
    $ swiftc -version
    swift-driver version: 1.62.15 Apple Swift version 5.7.1 (swiftlang-5.7.1.135.3 clang-1400.0.29.51)
    Target: arm64-apple-macosx12.0
    
    $ swiftc foo.swift
    $ ./foo
    ["P", "r", "C", "z", "w", "m", "B", "q", "j", "g", "n"]
    ["r"]
    
    $ otool -L foo
    foo:
     /usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)
     /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1319.0.0)
     /usr/lib/swift/libswiftCore.dylib (compatibility version 1.0.0, current version 
    $ DYLD_LIBRARY_PATH=/Library/Developer/Toolchains/swift-5.7.1-RELEASE.xctoolchain/usr/lib/swift/macosx ./foo
    ["r"]
    ["r"]
Note that I had to download and install Swift 5.7.1 from swift.org. Trying to use libswiftCore.dylib from Xcode-14.1 is no bueno:

    $ /Applications/Xcode.app/Contents/Developer/usr/bin/xcodebuild -version
    Xcode 14.1
    Build version 14B47b
    $ DYLD_LIBRARY_PATH=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift/macosx ./foo
    ["B", "P", "q", "C", "r", "n", "j", "w", "m", "z", "g"]
    ["r"]
Oh, it's because /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift-5.0/macosx/libswiftCore.dylib is x86_64 only for some reason and I'm testing on an MBA M1.

The dylibs under /Library/Developer/Toolchains/swift-5.7.1-RELEASE.xctoolchain/usr/lib/swift/macosx are arm64 and x86_64.

WTF Apple?

Re: Adventures in Advent of Code

#17
post #15

I'm confused. The post mentioned that this was fixed in Swift 5.7, but I have Swift 5.7.1 on my macOS Monterey and the bug is still present if I modify my AoC solution to exhibit the problem. Is Swift 5.7.1 on Monterey different from the 5.7.1 on Ventura? $ swift -v Apple Swift version 5.7.1 (swiftlang-5.7.1.135.3 clang-1400.0.29.51) Target: arm64-apple-macosx12.0 I love Swift as a language, but the lack of release n…

Turns out the fix is only on Ventura. I was also on Monterey. I updated the blog post to include this.

Re: Adventures in Advent of Code

#18

I picked go for my language this year, which doesn't have good support for sets. May end up writing my own buggy implementation of this.

I hear you. That's part of the joy I seek with AoC.

Most years I choose a language I've never worked with commercially (e.g. Fennel in 2022) and rather than reach for prebuilt libs for timesaving fancy array or set or string ops, I'll invent those wheels myself without dependencies and I find a ton of satisfaction in it. Unwise commercially but ideal for learning and play. And, yeah, bugs!

IMO, when it's not a customer paying for my learning curve, there's a lot to be said for rewalking old paths with new boots (or no boots and funky coloured glasses). Also, a terrible way to get onto the leaderboard IME!

Re: Adventures in Advent of Code

#19

I'll be doing AoC in C this year. And I've decided to do that every year as I enjoy doing it in C and trying to get the entire calendar, all 50 parts to run in less than one second on a single core, which it turns out is quite doable, but only with a much deeper understanding of the problems. I end up learning a lot more computer science this way. I also like it since I don't do any work or even side projects in C th…

Hat tip if you did 2021:14:2 under this constraint. I didn’t find the trick to allow that type of performance.

I don't think I did the 2021 one, but I did do 2020.

Re: Adventures in Advent of Code

#20
post #15

I'm confused. The post mentioned that this was fixed in Swift 5.7, but I have Swift 5.7.1 on my macOS Monterey and the bug is still present if I modify my AoC solution to exhibit the problem. Is Swift 5.7.1 on Monterey different from the 5.7.1 on Ventura? $ swift -v Apple Swift version 5.7.1 (swiftlang-5.7.1.135.3 clang-1400.0.29.51) Target: arm64-apple-macosx12.0 I love Swift as a language, but the lack of release n…

Turns out the fix is only on Ventura. I was also on Monterey. I updated the blog post to include this.

But that's my question. Similar to the other comment at https://news.ycombinator.com/item?id=33848354, I have 5.7.1 on Monterey. 5.7 isn't restricted to Ventura. Is the problem that the fix in 5.7/5.7.1 didn't actually fix it?
Post reply on HN