🗣️ this is a useful guide to help you memorize + better understand how Jujutsu works, but it's not a replacement for learning the mental model or deeper strategies!
@ — a symbol pointing to the current working copy change (like HEAD, but for changes)@- — the parent of @
| # train_grpo.py | |
| # | |
| # See https://github.com/willccbb/verifiers for ongoing developments | |
| # | |
| """ | |
| citation: | |
| @misc{brown2025grpodemo, | |
| title={Granular Format Rewards for Eliciting Mathematical Reasoning Capabilities in Small Language Models}, | |
| author={Brown, William}, |
| import SwiftUI | |
| struct ContentView: View { | |
| @State private var animate: Bool = false | |
| @State private var color: Color = .myGray | |
| @State private var pattern: [[Int]] = [ | |
| [0, 1, 2, 3, 4, 5, 6, 7, 8,], | |
| [9, 10, 11, 12, 13, 14, 15, 16, 17,], | |
| [18, 19, 20, 21, 22, 23, 24, 24, 26,], |
| class BaseClient | |
| class APINotFound < StandardError; end | |
| attr_reader :auth_strategy | |
| def initialize(auth_strategy: :headers, headers: {}) | |
| @auth_strategy = auth_strategy | |
| @headers = headers | |
| end |
| // | |
| // ContentView.swift | |
| // MadeForYouCard | |
| // | |
| // Created by AppleDesignDev on 1/24/22. | |
| // | |
| import SwiftUI | |
| struct ContentView: View { |
| // | |
| // Clubhouse.swift | |
| // Playground | |
| // | |
| // Created by Nav Singh on 2/11/21. | |
| // | |
| import SwiftUI | |
| struct Clubhouse: View { |
| /// Withable is a simple protocol to make constructing | |
| /// and modifying objects with multiple properties | |
| /// more pleasant (functional, chainable, point-free) | |
| public protocol Withable { | |
| init() | |
| } | |
| public extension Withable { | |
| /// Construct a new instance, setting an arbitrary subset of properties | |
| init(with config: (inout Self) -> Void) { |
| # The trick is to link the DeviceSupport folder from the beta to the stable version. | |
| # sudo needed if you run the Mac App Store version. Always download the dmg instead... you'll thank me later :) | |
| # Support iOS 15 devices (Xcode 13.0) with Xcode 12.5: | |
| sudo ln -s /Applications/Xcode-beta.app/Contents/Developer/Platforms/iPhoneOS.platform/DeviceSupport/15.0 /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/DeviceSupport | |
| # Then restart Xcode and reconnect your devices. You will need to do that for every beta of future iOS versions | |
| # (A similar approach works for older versions too, just change the version number after DeviceSupport) |
tl:dr - the following is a long rant about the complexities of presentation layer development as it collides with the growing complexities of JavaScript front-end frameworks. This is a summary of my experiences, issues and proposed solutions to today's world of client-side application development.
It was a trend with the traditional model of app development that the app dev team would take a particular dominance over the presentation layer, as it was rightly so, their domain. The deign teams of the time resorted to non-code ways of communicating their intentions as to influence the design. The 'comp' and 'red-line' documents were the primary resource of communication. Practices that are not all that dead, people still do this stuff you know.
We all know by now that these processes don't really work. They are fraught with error and caused countless hours of frustration between designers and developers. Witness the rise of the 'designer - developer' or 'The Designer w
One of the many reasons I love working with Ruby is it has a rich vocabulary that allows you to accomplish your goals with a minimal amount of code. If there isn't a method that does exactly what you want, it's usually possible to build an elegant solution yourself.
Let's take the example of simulating the rolling of a die.
We can represent a die as an array of its faces.
die = [*?⚀..?⚅]
# => ["⚀", "⚁", "⚂", "⚃", "⚄", "⚅"]