dotfiles VS lone

The colors are mostly from zenburn

https://github.com/fiddlerwoaroof/dotfiles/blob/master/emacs...

Yeah, that’s definitely where I’ve ended up: I have a lot of lisp code, but it’s more of a toolbox for my shell (REPL) than standalone programs.

However, I’ve settled on a pattern that works pretty well for the few small tools I write: https://github.com/fiddlerwoaroof/dotfiles/blob/18cecfc93bcf...

I use these keys every day for just about every sort of balanced delimiter manipulation I do in any language: https://github.com/fiddlerwoaroof/dotfiles/blob/eff889f0b749...

A little below I bind this key map to the “,” prefix and I’ve found my layout of paredit commands pretty ergonomic to use long-term.

What made a difference for me was figuring out the right keybindings. The default keybindings in emacs weren’t very ergonomic and so I came up with a more convenient set of keybindings (for evil-mode, since I prefer vim-style editing). They follow a nice pattern on the keyboard and made a huge difference.

I eventually adapted them so I could have relatively consistent keybindings across vim/emacs/VSCode/IntelliJ and the results are here:

https://github.com/fiddlerwoaroof/dotfiles/blob/b13240a42fa4...

If you understand the elisp keybinding notation, it’s possible to use the C-, ones in VSCode.

Yeah, I don’t have home-manager generate configurations for vim. I have home-manager generate a symlink to my version-controlled vimrc. This way I get the quick setup benefits of home-manager without the slow reload times.

Incidentally, I just polished my script for working around that issue: https://github.com/fiddlerwoaroof/dotfiles/blob/master/scrip...

https://github.com/fiddlerwoaroof/dotfiles/blob/master/emacs.d/lisp/configurations/evil-conf.el#L67-L143

I made something somewhat close to that: a freestanding lisp. It targets the Linux kernel directly. No libc.

https://github.com/lone-lang/lone

> register scanning isn't portable

Certainly not but it wasn't particularly hard to implement either. I just wrote some inline assembly for every architecture. Here's my programming language's x86_64 and aarch64 implementations:

https://github.com/lone-lang/lone/blob/master/architecture/x...

https://github.com/lone-lang/lone/blob/master/architecture/a...

Not too long ago, a project of mine was shared here on HN.

https://news.ycombinator.com/item?id=38126052

In that thread I wrote:

> I have this vision in my mind: embedding lone modules into sections of the lone ELF and shipping it out. Zero dependencies, self-contained.

I've been working on that since that day. Proud to say I've gotten it to work and thought I'd make it the subject of my first Show HN. Some free software projects gained features along the way too.

The link is to an article with a proper demonstration, technical details and what happened in the past few weeks.

The complete repository itself can be found here:

https://github.com/lone-lang/lone

I've completely reorganized it since the last thread. Would be very happy if you guys tried it out.

To test my programming language. It's a freestanding lisp interpreter that doesn't link to libc. I wrote the code that handles the environment variables and in order to test it I needed full control over the program's inputs including its environment. The env utility provides this control by emptying the environment and setting only the variables I specify, solving 90% of the problem. Only thing I still can't control is argv[0]. With this new feature upstreamed, my test suite will be complete.

Here's the code if you'd like to take a look:

https://github.com/lone-lang/lone#testing

https://github.com/lone-lang/lone/blob/master/scripts/test.b...

> only to be confronted with the notorious 'incompatible glibc version error'. It's super annoying.

I started making my own freestanding Linux Lisp because of this exact issue. It's nowhere near as performant as something like SBCL but it's small and once compiled has no dependencies and will literally run on any Linux.

https://github.com/lone-lang/lone

I'm taking a break from this project but I plan to add a feature where I can put a Lisp script into the ELF itself so I can just copy it with the scripts included.

The kernel just puts the data contiguously on the stack. Obtaining pointers to them can seem somewhat magical if you're writing a nolibc program but I wouldn't call it horrible.

I implemented it for my programming language with some rather simple assembly code:

https://github.com/lone-lang/lone/blob/master/arch/x86_64.c#...

https://github.com/lone-lang/lone/blob/master/arch/aarch64.c...