Table of Contents
/** | |
* by @iagobelo | |
* Decoder in progress!!! | |
*/ | |
type STRING_TO_CONVERT = "xablau"; | |
type BitResult = Base64EncodeWithoutBa64Chars<STRING_TO_CONVERT>; // 011110-000110-000101-100010-011011-000110-000101-110101 | |
type Result = Base64Encode<STRING_TO_CONVERT>; // eGFibGF1 |
import { useCallback, useMemo } from 'react'; | |
import generateHash from './generateHash.js'; | |
export type Identify = (name: string) => string; | |
function useIdentify(): Identify { | |
const ids = useMemo(() => new Map<string, string>(), []); | |
return useCallback((name) => { | |
if (!ids.has(name)) { |
In my for ever long task of achieving Emacs and Org-mode configuration nirvana I
stumbled upon the problem of trying to reuse a couple of .tex
files I keep as
templates for my (La)TeX exports for Org-mode. As I started to collaborate
more and more in my TeX files, I realized that this setup would also need to
be TeX-wise independent, that is, the exported .tex
file should be self
contained and self sufficient, so that I can keep collaborating and other people
can see my work and (hopefully) reproduce whatever I have written without my
We've been deadlocked for a while on the pipeline operator proposal, for a few reasons. Partially it's just low implementor interest, as this is fundamentally just syntactic sugar, but also because there are three competing proposals and the proponents of each haven't been convinced by the others yet.
In this essay I hope to briefly outline the problem space, summarize the three proposals, and talk about what's gained/lost by each of them. (Spoiler: they're all nearly identical; we're arguing over very small potatoes.)
The package that linked you here is now pure ESM. It cannot be require()
'd from CommonJS.
This means you have the following choices:
- Use ESM yourself. (preferred)
Useimport foo from 'foo'
instead ofconst foo = require('foo')
to import the package. You also need to put"type": "module"
in your package.json and more. Follow the below guide. - If the package is used in an async context, you could use
await import(…)
from CommonJS instead ofrequire(…)
. - Stay on the existing version of the package until you can move to ESM.
// DONT FORGET TO `yarn add esbuild-loader` !!! | |
// config/webpacker/environment.js | |
const { environment } = require('@rails/webpacker') | |
const { ESBuildPlugin } = require('esbuild-loader') | |
const esBuildUse = [ | |
{ | |
loader: require.resolve('esbuild-loader'), | |
// What you want to compile to, in this case, ES7 |
import { | |
EffectCallback, | |
DependencyList, | |
useLayoutEffect, | |
useState, | |
useEffect, | |
useMemo, | |
} from 'react' | |
// lib/canUseDOM |
At the beginning of 2030, I found this essay in my archives. From what I know today, I think it was very insightful at the moment of writing. And I feel it should be published because it can teach us, Rust developers, how to prevent that sad story from happening again.
What killed Haskell, could kill Rust, too
What killed Haskell, could kill Rust, too. Why would I even mention Haskell in this context? Well, Haskell and Rust are deeply related. Not because Rust is Haskell without HKTs. (Some of you know what that means, and the rest of you will wonder for a very long time). Much of the style of Rust is similar in many ways to the style of Haskell. In some sense Rust is a reincarnation of Haskell, with a little bit of C-ish like syntax, a very small amount.
Is Haskell dead?