# A New Era of Lysa

Some things have changed for Lysa over the last 3 weeks. I have been experimenting with a new direction, and I'm very happy with what I've settled on. Today, you'll get to see a quick and dirty demo of what Lysa can do. Check out the video:

What Has Changed?

Well, how about a little story time first?

About a year and a half ago, I started working on a Linux debugger from scratch. You may have seen Shawn McGrath's stream (sorry, I can't find it) where he slapped together some DWARF parsing code in what seemed like a matter of minutes. Well, it took me much longer to do something similar, and I eventually abandoned that endeavor and let the libdwarf library do all the DWARF lifting. Once I started using it, the real work began.

That library gave me some powerful tools so that I could start working on actual debugging features. Even though it was a bit of a slog, I really enjoyed it. Digging into man files and making Linux systems work for me is kinda cool. This would have been my first minor lesson on what libraries have to offer.

Fast forward a little over a year, and my family and I had to go through a pretty big move. We left Nebraska for the mountains and landed in Colorado, just outside Denver. My dreams had been filled with the rocky mountains and fresh powder on the slopes: I finally made it. It wasn't all unicorns and rainbows, though. We spent lots of money and dealt with tons of bull shit. Needless to say, Lysa took a back seat and the progress slowed down quite a lot.

Thankfully, we're pretty much all settled in now, and I'm pumped to be working on Lysa again. The last year or so taught me a lot about writing debuggers, even more about programming, and a smidgen about human relationships. One of the biggest things that I learned, and am still learning, is how I feel about making things from scratch. Resisting getting help from friends and using libraries has wasted quite a bit of my time. That, among other things, is why there will be two major changes with the development of Lysa

1. I will be joining forces with my good friend Jeroen.

With Our Powers Combined!

From the very beginning of time itself, Jeroen and I planned for Lysa to be a collaborative effort. Unfortunately, our respective work had kept us from actually starting work together, and my ego got in the way when I decided that Lysa would be my Opus Magnum (way better than a Magnum Opus). I won't bore you with the details, but we are back on track to start working together on Lysa, Soon™

Our ultimate goal for our work is to form a profitable business where we can provide quality development tools (maybe even a game or two) to the unwashed masses! The Handmade Network brought us together and it has been a great community for fostering great work. I'm pretty sure we're not the first group to collaborate as a result of the community, but I'm certain we won't be the last.

The LLDB Backend

Before I get too deep into the LLVM weeds, here are a few highlights of why I think the LLDB library-as-a-backend is the right choice:

• A huge community of developers making it work well
• Multiple supported languages
• Permissive licensing
Although the pace of development on Lysa has picked up, the rate at which it was being built was not acceptable for me. I'm a stay-at-home dad and I only get to work on my projects part-time, so using a robust library like LLDB, I can save a ton of time and get to a working version of Lysa much sooner. Plus, Jeroen and I have talked about it a fair bit and we also plan to see what we can do about minimizing the LLDB backend or removing it completely in the long-term. It just depends on what makes sense for the life of the project.

With regards to multiple languages and platforms, that is huge. If I was still working on the original version of Lysa, these features would have been many months away. Just getting a debugger working perfectly for C on Linux is a feat. C++ and Windows on the other hand...

There is one glaring downside to this: LLVM is a pain in the ass to build. That is the major driving force behind our discussions to minimize or remove LLDB in the long run. At the very least, we will be taking a look under the hood to find out how to streamline the build process. For the short-to-mid-term, we expect most users will dynamically link to the LLDB library on their respective platform. It's a band-aid for now, but it will get us far before we have to make large changes.

Now, for a few things that I think Lysa will do well and why you should use it:

1. Sane API
2. Documentation

The current iteration of the Lysa API is barely scratching the surface of what I have planned, and maybe it's not even any good yet, but the primary focus of the design and development going forward is to provide a quality, usable tool that gives you control over your debugging.

I apologize to any LLDB devs reading this, but the documentation is abysmal. The docs for Lysa will grow with the project and it only makes sense that a good API needs good documentation and tutorials. I wish more projects would spend time on these two things while they work on the code.

Last, but not remotely close to least, is your feedback. While we're in prerelease (maybe we should call it alpha instead?), it's extremely important that those of you using Lysa stay in contact with us and let us know where your pain points are. I want to make tools that help loads of programmers get more work done; not just me and Jeroen. We will be as open as possible with development and anyone who participates in prerelease of Lysa will have an equal voice on how it improves over time.

Whoo Boy, That's a Lot of Stuff

There is one last thing I want to mention. I'm working on two tools in order to guide the progress of Lysa: a standalone debugger and a game. I'm shooting for a core audience of game developers (because games are awesome, of course) and that means I'll need to be building the things you will be building with Lysa. This will give me a small head start on what the API needs to look like, but (I'll keep beating this dead horse) your feedback is critical.

The standalone debugger currently has a working prototype that uses the dear imgui library. The lib isn't really meant for standalone applications as much as it is for in-game tools, but it got me moving quickly towards a usable debugger. If you're reading this, then the prototype should be up for download on the repo for Lysa already. The game I'll be making to stretch out Lysa's capabilities hasn't been started yet, but more on that soon.

And that's all folks. I hope The New Era of Lysa hasn't scared you off, because I'm incredibly excited for what is to come. Working with a very good friend of mine and building something that the world desperately needs is pretty damn neat. Hang in there and keep in touch.

You stay classy.
CaptainKraft,

Can you explain the difference between using Lysa vs. using LLDB given that Lysa will now be using the LLDB debugger APIs (which are themselves exposed as a shared library)?

Thanks!
Mārtiņš Možeiko, Edited by Mārtiņš Možeiko on
I believe answer to that is written here: https://captainkraft.com/posts/a-new-era-of-lysa/
few things that I think Lysa will do well and why you should use it:

1. Sane API
2. Documentation

Btw, I strongly disagree with this:
LLVM is a pain in the ass to build
llvm/clang has one of the most straight forward CMake builds I have ever seen for large size of project llvm/clang is. You just run configure step and then the build. That's it. I've been working with/on clang/llvm for multiple years and I would take its build system over something like gcc without second thought.

So I went looking where can take a look at API, because
All I found is that I need to pay $25 to give feedback to you. I assume that's what I will be able to do with "Git repository access". And feedback is critical? That doesn't add up. If feedback is critical you should pay us to give it to you :) Jeremiah Goerdt, Btw, I strongly disagree with this: LLVM is a pain in the ass to build llvm/clang has one of the most straight forward CMake builds I have ever seen for large size of project llvm/clang is. You just run configure step and then the build. That's it. I've been working with/on clang/llvm for multiple years and I would take its build system over something like gcc without second thought. You're right. I should be more clear, it was a pain in the ass for me because it took all of my RAM, 30GB of my swapfile, and there was a lot of trial and error on my part. It also took hours because it kept failing due to memory or storage shortages. The system for building it is very simple, like you said. The problem for me was just resources and time. So I went looking where can take a look at API, because your feedback is critical All I found is that I need to pay$25 to give feedback to you. I assume that's what I will be able to do with "Git repository access". And feedback is critical? That doesn't add up. If feedback is critical you should pay us to give it to you :)

It seems like I should be a bit more clear on the Patreon as well. As a backer at \$5 you can use the library and provide feedback. My thought process on only letting backers in is to keep the pool small so that I can keep up on my part-time schedule and to make sure the people providing the feedback are serious about supporting us.

Maybe that's the wrong approach. However, it is the one I've chosen so far.

Even your feedback here is very helpful. Thanks for the replies :-)
Jeremiah Goerdt,
x13pixels
CaptainKraft,

Can you explain the difference between using Lysa vs. using LLDB given that Lysa will now be using the LLDB debugger APIs (which are themselves exposed as a shared library)?

Thanks!

Mārtiņš is right, there is a bit more on the post over at my website (see above). Lysa will wrangle the complexity of LLDB and give you something simpler and more targeted. Since LLDB is built for everyone to use, I think it would be nice to have a simpler, more targeted API with rich documentation (which is extremely difficult for such a large project like LLDB).