EDIT: check out fix-python instead, make Python run "as usual" on NixOS!
- You are using NixOS
- You start working on a Python project
- You manage the dependencies in a classic Python virtual environment using pip or poetry
// A nano dependent type-checker featuring inductive types via self encodings. | |
// All computation rules are justified by interaction combinator semantics, | |
// resulting in major simplifications and improvements over old Kind-Core. | |
// Specifically, computable annotations (ANNs) and their counterpart (ANN | |
// binders) and a new self encoding based on equality (rather than dependent | |
// motives) greatly reduce code size. A more complete file, including | |
// superpositions (for optimal unification) is available on the | |
// Interaction-Type-Theory repository. | |
// Credits also to Franchu and T6 for insights. |
module Data.Json (Json(..), JsonValue(..)) where | |
import Prelude | |
import Data.String (joinWith) | |
import Data.Tuple (Tuple(..)) | |
data JsonValue | |
= JsonString String | |
| JsonNumber Number |
EDIT: check out fix-python instead, make Python run "as usual" on NixOS!
import asyncio | |
async def test(s, n): | |
print(f' {s} started') | |
await asyncio.sleep(n) | |
print(f' {s} ends') | |
async def main(): |
This is the final report for the GSoC 2021 project - Gradually Typed Hasktorch. Gradually Typed Hasktorch is a new tensor API for Hasktorch. It has been initiated by my mentor, Torsten Scholak, and as part of GSoC I helped with streamlining this new API.
Student: Julius Marozas Mentor: Torsten Scholak
As I come out as trans to people, most are supportive, but a few people remain skeptical and question my feelings and experiences. I try to field their concerns to the best of my ability, but one particular concern they raise is so common and so far off the mark that I feel compelled to share my thoughts on this. My intention is not to shame them, but rather to use this as an opportunity to share my own experiences.
Their concern typically goes like this: they believe that many people who transition do so because they are too easily suggestible and that they have been over-exposed to trans role models (either friends or people on social media).
This post was adapted from an earlier Twitter thread.
It's incredible how many collective developer hours have been wasted on pushing through the turd that is ES Modules (often mistakenly called "ES6 Modules"). Causing a big ecosystem divide and massive tooling support issues, for... well, no reason, really. There are no actual advantages to it. At all.
It looks shiny and new and some libraries use it in their documentation without any explanation, so people assume that it's the new thing that must be used. And then I end up having to explain to them why, unlike CommonJS, it doesn't actually work everywhere yet, and may never do so. For example, you can't import ESM modules from a CommonJS file! (Update: I've released a module that works around this issue.)
And then there's Rollup, which apparently requires ESM to be u
-- flatparse: hackage 0.1.1.1 | |
-- example: smaltt (demo for fast elaborator): switching from megaparsec to flatparse would speed up more than 2x overall | |
-- 1 year ago: | |
-- parsec : ridiculously slow, CPS implementation | |
-- attoparsec : (resumable, CPS), "high-performance" data parsing, binary parsing, not language parsing | |
-- fringe, modern: | |
-- parsnip: (unpublished on hackage) (by Kmett, on github) : really the high-performance raw data parsing (not language parsing) |
nix-shell -p yarn yarn2nix nodejs
package.nix
using yarn2nix