Here's JavaScript code that will definitely trigger OOM in your deno_core setup:
// This will quickly consume memory by creating large arrays
const arrays = [];
let counter = 0;
while (true) {
=== Full Backtrace === | |
#0 0x0000563016f63c87 in v8::internal::MarkingBarrier::MarkValueLocal(v8::internal::Tagged<v8::internal::HeapObject>) () at ../../../../v8/src/heap/marking-barrier-inl.h:98 | |
#1 0x0000563016f633df in void v8::internal::MarkingBarrier::Write<v8::internal::FullHeapObjectSlot>(v8::internal::Tagged<v8::internal::HeapObject>, v8::internal::FullHeapObjectSlot, v8::internal::Tagged<v8::internal::HeapObject>) () at ../../../../v8/src/heap/marking-barrier-inl.h:25 | |
#2 0x000056301720e5f6 in v8::internal::Dictionary<v8::internal::NameDictionary, v8::internal::NameDictionaryShape>::SetEntry(v8::internal::InternalIndex, v8::internal::Tagged<v8::internal::Object>, v8::internal::Tagged<v8::internal::Object>, v8::internal::PropertyDetails) () at ../../../../v8/src/objects/dictionary-inl.h:202 | |
#3 0x000056301720e825 in v8::internal::Handle<v8::internal::NameDictionary> v8::internal::Dictionary<v8::internal::NameDictionary, v8::internal::NameDictionaryShape>::Add<v8::internal::Isolate, (v8::internal::All |
------------------------------------- | |
Translated Report (Full Report Below) | |
------------------------------------- | |
Process: VibeTunnel [94882] | |
Path: /Applications/VibeTunnel.app/Contents/MacOS/VibeTunnel | |
Identifier: sh.vibetunnel.vibetunnel | |
Version: 1.0.0-beta.4 (109) | |
Code Type: ARM-64 (Native) | |
Parent Process: launchd [1] |
This guide will walk you through creating a custom MCP (Model Context Protocol) server that integrates with Claude Code, allowing you to extend Claude's capabilities with external tools, APIs, or even other AI models.
MCP (Model Context Protocol) is a protocol that allows Claude to communicate with external servers to access tools and capabilities beyond its built-in features. Think of it as a plugin system for Claude.
# /etc/nixos/configuration.nix | |
{ config, pkgs, ... }: | |
{ | |
imports = | |
[ | |
./hardware-configuration.nix | |
]; | |
boot.loader.systemd-boot.enable = true; |
{ | |
config, | |
pkgs, | |
lib, | |
inputs, | |
... | |
}: let | |
ipu6-camera-bin = with pkgs; | |
stdenv.mkDerivation rec { | |
pname = "ipu6-camera-bin"; |
In a previous post
I explained how to manage Neovim plugins with Nix and Home Manager.
In this post I want to go further and show how to migrate Neovim configuration
from ~/.config/nvim
to ~/.config/home-manager
entirely. The end result will
be to split our Neovim setup into multiple modules that colocate plugin sourcing
and configuration.
If you haven't read the post linked above, do so now. We will assume the
Highly extensible software like Emacs, Vim, and Neovim tend to grow their own package managers. A software developer, for example, might want to install editor plugins that hook into a particular programming language's linter or language server. The programmer's text editor is therefore extended to support managing additional software to extend the text editor. If this loop continues for too long, the programmer's editor becomes more delicate and complex. The remedy for this problem is to manage software using dedicated tools apart
(defsrc | |
grv 1 2 3 4 5 6 7 8 9 0 - = bspc | |
tab q w e r t y u i o p [ ] \ | |
caps a s d f g h j k l ; ' ret | |
lsft z x c v b n m , . / rsft | |
lctl lmet lalt spc ralt rmet rctl | |
) | |
(deflayer qwerty | |
@gsc 1 2 3 4 5 6 7 8 9 0 - = bspc |
Section "Monitor" | |
Identifier "Virtual-1" | |
Modeline "2560x1600" 348.50 2560 2760 3032 3504 1600 1603 1609 1658 -hsync +vsync | |
Option "PreferredMode" "2560x1600" | |
EndSection | |
Section "Screen" | |
Identifier "Screen0" | |
Monitor "Virtual-1" | |
DefaultDepth 24 |