I recently switched over to neovim (see my screenshots at the bottom). Below is my updated config file.
It's currently synchronized with my .vimrc config except for a block of neovim-specific terminal key mappings.
This is still a work in progress (everyone's own config is always a labor of love), but I'm already extremely pleased with how well this is working for me with neovim. While terminal mode isn't enough to make me stop using tmux, it is quite good and I like having it since it simplifies my documentation workflow for yanking terminal output to paste in a markdown buffer.
These days I primarily develop in Go. I'm super thrilled and grateful for fatih/vim-go,
| // SPDX-License-Identifier: MIT | |
| pragma solidity ^0.8.3; | |
| import "@openzeppelin/contracts/utils/Counters.sol"; | |
| import "@openzeppelin/contracts/token/ERC721/extensions/ERC721URIStorage.sol"; | |
| import "@openzeppelin/contracts/token/ERC721/ERC721.sol"; | |
| import "hardhat/console.sol"; |
If you, like me, resent every dollar spent on commercial PDF tools,
you might want to know how to change the text content of a PDF without
having to pay for Adobe Acrobat or another PDF tool. I didn't see an
obvious open-source tool that lets you dig into PDF internals, but I
did discover a few useful facts about how PDFs are structured that
I think may prove useful to others (or myself) in the future. They
are recorded here. They are surely not universally applicable --
the PDF standard is truly Byzantine -- but they worked for my case.
I was at Amazon for about six and a half years, and now I've been at Google for that long. One thing that struck me immediately about the two companies -- an impression that has been reinforced almost daily -- is that Amazon does everything wrong, and Google does everything right. Sure, it's a sweeping generalization, but a surprisingly accurate one. It's pretty crazy. There are probably a hundred or even two hundred different ways you can compare the two companies, and Google is superior in all but three of them, if I recall correctly. I actually did a spreadsheet at one point but Legal wouldn't let me show it to anyone, even though recruiting loved it.
I mean, just to give you a very brief taste: Amazon's recruiting process is fundamentally flawed by having teams hire for themselves, so their hiring bar is incredibly inconsistent across teams, despite various efforts they've made to level it out. And their operations are a mess; they don't real
| # train_grpo.py | |
| import re | |
| import torch | |
| from datasets import load_dataset, Dataset | |
| from transformers import AutoTokenizer, AutoModelForCausalLM | |
| from peft import LoraConfig | |
| from trl import GRPOConfig, GRPOTrainer | |
| # Load and prep dataset |