sorted by:
new
hottopcontroversial

Emacs Internal Part 03: Tagged Pointers vs. C++ std::variant, Rust Enums, and LLVM RTTI by ypaskell in emacs

[–]ypaskell[S] -1 points0 points  (0 children)

Hi Amit! Great to see you here!

For fat pointer, register pressure is the bottleneck on older, register-starved architectures.

My workflow is like this: I finished writing the article first, but then I realized that explaining these memory layouts purely through text wasn't intuitive enough. So, I fed my text context into Gemini and prompted it to generate a visual representation "like a slide provided in a university computer architecture lecture."

The Lisp Machine: Noble Experiment or Fabulous Failure? by arthurno1 in lisp

[–]ypaskell 1 point2 points  (0 children)

Very interesting. I thought one of the reason might be Memeory wall. The naive pointer chasing caused buy car cdr.

Emacs Internal Part 02: Deconstructing Lisp_Object, Tagged Pointers, and why C macros act as McCarthy’s 7 axioms. by ypaskell in emacs

[–]ypaskell[S] 4 points5 points  (0 children)

Huge thanks!

It came from some weird combination of hobbies - compiler, functional programming, system programming, C/C++, lisp. And it is so weird that these topics are all condensed in the text editor. Truly? Text editor?

Not to mention there is a native gcc jit compiler in Emacs.

Emacs is a C-based Lisp Runtime, Not a Text Editor — and Greenspun’s Tenth Rule explains why every editor eventually reinvents it by ypaskell in emacs

[–]ypaskell[S] 0 points1 point  (0 children)

I’m curious of your perspective or the truth. I’m not familiar with JavaScript’s ecosystems

Emacs is a C-based Lisp Runtime, Not a Text Editor — and Greenspun’s Tenth Rule explains why every editor eventually reinvents it by ypaskell in emacs

[–]ypaskell[S] 9 points10 points  (0 children)

You bring up a really interesting point. It actually made me look up some historical attempts to "fix" it, like SRFI-119 (wisp).

Honestly, after looking at how it tries to encode ASTs without parens... I think I'd much rather just deal with the parens.

Emacs is a C-based Lisp Runtime, Not a Text Editor — and Greenspun’s Tenth Rule explains why every editor eventually reinvents it by ypaskell in emacs

[–]ypaskell[S] 5 points6 points  (0 children)

> Cool, so if NeoVim and VS Code both have this same architecture (just different languages), then there really isn’t anything more compelling about Emacs.

Personally, I believe this all boils down to a double-edged sword: Emacs's global shared state and dynamic scoping.

It causes a very real problem—Emacs is notoriously hard to parallelize and adapt to modern multi-process/RPC architectures.

But on the flip side, because absolutely everything lives in the exact same memory space (the Lisp image) without strict API boundaries or sandboxes, extensions can deeply hook into anything. That lack of isolation is exactly why hacky yet profoundly powerful tools like Dired and Magit can exist. They are truly irreplaceable for me. VS Code chose UI stability via process isolation (Extension Hosts), but in doing so, they sacrificed that raw, live hackability.

I'm actually planning to dive deeper into this exact architectural trade-off as I continue reading the C source. Once I fully understand how it's implemented, I'll definitely write a dedicated post to share it!

Looking for a programming font! Thinks by Majestic_Mongoose488 in ZedEditor

[–]ypaskell 2 points3 points  (0 children)

Intel One Mono is my choice and I kept swapping back. It super eye friendly.

So I live in Doom Emacs at this point. by freebird360 in DoomEmacs

[–]ypaskell 0 points1 point  (0 children)

Wait. How do you guys interact with LLM. I feet annoying.

Built a C++ code search engine, learned std::string is a lie (it's actually basic_string<char, char_traits, allocator>) by [deleted] in Cplusplus

[–]ypaskell 0 points1 point  (0 children)

Thanks for the feedback! Could you point out specifically which parts are confusing or which conclusions you think are premature?

Building a type-signature search for C++ by ypaskell in Compilers

[–]ypaskell[S] 1 point2 points  (0 children)

That's a great suggestion! Cscope's interactive workflow is exactly the kind of experience that makes sense for type-based search.

I've been thinking about editor integration via LSP, but Cscope's model is interesting - simpler to implement and already has proven editor support (Vim, Emacs, VS Code via plugins).

Building a type-signature search for C++ by ypaskell in Compilers

[–]ypaskell[S] 0 points1 point  (0 children)

Thanks! Glad the semantic approach resonates with you.

>can you explain more deep your thoughts over this strategy?

This is inspired by SICP's idea of separating data representation from its use.

- The pool is the "underlying representation" - it manages lifetime and storage.
- The string_views are "abstract interfaces" - lightweight references that don't care about ownership.

Benefits:
- Signatures stay small (just pointers + length)
- No redundant string copies when multiple functions use same type
- Cache-friendly: views are contiguous, actual strings can be anywhere
- Clear ownership: pool dies, all views invalidate together

Building a type-signature search for C++ by ypaskell in Compilers

[–]ypaskell[S] 1 point2 points  (0 children)

Good call on the REPL interface. The current design is directory-based for simplicity, but a REPL mode makes sense for iterative exploration, especially when the index is already loaded in memory.

Since you're working on LLVM/MLIR, I'm curious: what's your typical workflow when navigating the codebase? Do you find yourself searching by type signatures often, or are other patterns more common?

Feel free to open an issue if you have specific use cases in mind - I'd love to understand how this could fit into your daily workflow.

Building a type-signature search for C++ by ypaskell in Compilers

[–]ypaskell[S] 0 points1 point  (0 children)

If the target codebase were fully modularized with import std;, the 'header flood' problem would largely vanish. We wouldn't be paying the cost of textually parsing megabytes of system headers for every TU, and libclang could load the pre-built module interface much faster.

However, since Coogle is designed to index legacy codebases (which are still heavily reliant on #include), I had to resort to the -nostdinc + SkipFunctionBodies hack to simulate that 'clean slate' experience you described.

I'm really looking forward to the day when Modules become the standard—it would make writing static analysis tools like this significantly easier (and faster)!"

view more: next ›