Cheeshian Chuah shian15810
| runner.dialect = scala3 | |
| runner.dialectOverride.allowSignificantIndentation = false | |
| # allows `if x then y` | |
| runner.dialectOverride.allowQuietSyntax = true |
Description for and list of popular special files like README/CHANGELOG/LICENSE and others.
The ReadMe is usually the first document people will see of your project. Depending on your project it should give a short introduction and usage/build examples. It should only contain the information you expect users to read. It is usually possible to link to other documentation files using the markdown syntax which gets rendered as html by popular repository hosting platforms.
Here's a comparison between how the same simple user definition would be defined using ArkType and Zod:
ArkType's definition syntax is more concise (definitions are about 50% shorter on average) as well as making it more visually obvious what the inferred TypeScript type will be. The ability to infer TypeScript definitions directly is the same, but ArkType's syntax is again more concise by allowing you to use typeof on a property of arkUser directly instead of using an extra "infer" helper.
In general, we also have taken significant steps to optimize and clarify our type hints when hovering over validators. For example, in the case above, this is what you see when you mouse over "zodUser":
For some reason, it is surprisingly hard to create a bootable Windows USB using macOS. These are my steps for doing so, which have worked for me in macOS Monterey (12.6.1) for Windows 10 and 11. After following these steps, you should have a bootable Windows USB drive.
You can download Windows 10 or Windows 11 directly from Microsoft.
After plugging the drive to your machine, identify the name of the USB device using diskutil list, which should return an output like the one below. In my case, the correct disk name is disk2.
This gist is designed to explain how to configure a project where you have your test code separated from your codebase. The project file structure looks a bit like this:
project
├─┬ lib # could be src
│ ├── globals.d.ts # source code specific type declarations
│ └── index.ts
├─┬ tests
Apparently my account is somehow shadow-banned on reddit (no one's fault, never really used it).
The thread this reply was posted to is: https://www.reddit.com/r/typescript/comments/o2sn3p/which_is_the_best_functional_programming_library/h40l3iu/?utm_source=share&utm_medium=web2x&context=3
Disclaimer: I am the author of effect-ts.
Effect-ts has been developed from the experience of having both used fp-ts in production and having extended fp-ts to support patterns inspired by zio in Scala.
this is a rough draft and may be updated with more examples
GitHub was kind enough to grant me swift access to the Copilot test phase despite me @'ing them several hundred times about ICE. I would like to examine it not in terms of productivity, but security. How risky is it to allow an AI to write some or all of your code?
Ultimately, a human being must take responsibility for every line of code that is committed. AI should not be used for "responsibility washing." However, Copilot is a tool, and workers need their tools to be reliable. A carpenter doesn't have to
| #!/bin/bash | |
| ## Change following to '0' for output to be like ls and '1' for eza features | |
| # Don't list implied . and .. by default with -a | |
| dot=0 | |
| # Show human readable file sizes by default | |
| hru=1 | |
| # Show file sizes in decimal (1KB=1000 bytes) as opposed to binary units (1KiB=1024 bytes) | |
| meb=0 | |
| # Don't show group column |