gdb-dashboard VS clasp

Disclaimer: I'm making a competing build system.

I won't tell you specific build systems, but I will tell you what to look for.

Look for power. Unlimited power. [1]

Usually, this means a few things:

1. The build system uses a general-purpose language, even if the language needs features to be added.

2. The build system does not reduce the power of the general-purpose language. For example, say it starts with Python but prohibits recursion. In that case, you know it is not unlimited power. Looking at you, Starlark.

3. The build can be dynamically changed, i.e., the build is not statically determined before it even begins.

4. Each task has unlimited power. This means that the task can use a general-purpose language, not just run external processes.

5. And there has to be some thought put it in user experience.

Why are these important? Well, let's look at why with CMake, which fails all of them.

For #1, CMake's language started as a limited language for enumerating lists. (Hence, CMakeLists.txt is the file name.) And yet, it's grown to be as general-purpose as possible. Why? Because when you need an if statement, nothing else will do, and when you need a loop, nothing else will do.

And that brings us to #2: if CMake's language started limited, are there still places where it's limited? I argue yes, and I point to the article where it says that your couldn't dynamically call functions until recently. There are probably other places.

For #3, CMake's whole model precludes it. CMake generates the build upfront then expects another build system to actually execute it. There is no changing the build without regenerating it. (And even then, CMake did a poor job until the addition of `--fresh`.) A fully dynamic build should be able to add targets and make others targets depend on those new targets dynamically, among other things.

For #4, obviously CMake limits what tasks can do because Ninja and Make limit tasks to running commands.

As another example, to implement a LaTeX target, you technically need a while loop to iterate until a fixed point. To do that with Make and Ninja, you have to jump through hoops or use an external script that may not work on all platforms.

CMake obviously fails #5, and to see how much other build systems fail it, just look for comments pouring hate on those build systems. CMake fails the most, but I haven't seen one that passes yet.

As an example, CMake barely got a debugger. Wow! Cool! It's been 20 years! My build system will have a debugger in public release #2 (one after the MVP) that will be capable of outputting to multiple TTY's like gdb-dashboard. [2] They should have had this years ago!

Should other comments suggest specific build systems, like the one that suggested Bazel, judge them by this list. Some will be better than others. None will pass everything, IMO, which is why I'm making my own.

[1]: https://youtube.com/watch?v=Sg14jNbBb-8

[2]: https://github.com/cyrus-and/gdb-dashboard

To debug, termdebug is built in to vim and supports a front end to gdb. In combination with gdb-dashboard this gives a reasonably good debugging experience

https://github.com/cyrus-and/gdb-dashboard, https://github.com/cyrus-and/gdb-dashboard/wiki

You can use the Python API to GDB to get really fancy TUIs like this: https://github.com/cyrus-and/gdb-dashboard

Try GDB Dashboard, it makes gdb much easier to use:

https://github.com/cyrus-and/gdb-dashboard

There's also Voltron which works with both gdb and lldb (amongst others):

https://github.com/snare/voltron

I can't believe no one has mentioned `gdb-dashboard` [1] yet! I use it extensively. [2]

Beyond that, I have recently learned how to write custom pretty printers for GDB. This saves a lot of screen space. I should probably update [2] soon with those new techniques.

GDB is powerful, useful, and after getting my start in IDE debuggers, including Visual Studio, I struggle whenever I have to go back.

[1]: https://github.com/cyrus-and/gdb-dashboard

[2]: https://gavinhoward.com/2020/12/my-development-environment-a...

Debugging: Learn gdb. You can use it for assembly. You can use it for C on a MCU. You can use it for Go on a Linux system. It’s ubiquitous, versatile, and worth understanding. You can pretty-print the output with something like this to help you out at first. There are 2 things you need, however: on chip debugger and a debug probe (though you don’t need an expensive one). Effectively, you talk to GDB, GDB talks to the server exposed by OCD, OCD knows the debug probe protocol, and the debug probe can use the MCU debug peripheral via SWD or JTAG to get those details.

I use gdb because I'm usually in the terminal. I don't think terminal it's any faster though. This is a nice addition to boring old terminal gdb.

I accidentally a Common Lisp that interoperates with C++ (https://github.com/clasp-developers/clasp.git). We would also like to move beyond BDWGC and Whiffle looks interesting. I will reach out to you and maybe we can chat about it.

Clasp might be such a language, it seems.

https://github.com/clasp-developers/clasp

/u/jeaye are you aware of CLASP? https://github.com/clasp-developers/clasp https://www.youtube.com/watch?v=mbdXeRBbgDM

Sounds to me like CLASP; it automatically exports C++ objects to be used from Common Lisp also via llvm.

Now, the difference of compiling speed of SBCL and CCL is not so big. Look at cl-benchmark, LispWorks is really fast, CCL is on par with Allegro, SBCL is close to CCL. Or https://github.com/clasp-developers/clasp/wiki/Relative-Compile-Performance-of-clasp, it depends on specific project (SBCL sometimes faster, slower, alike), overall difference is not big.

So..

"Why do you want to make Lisp more popular? If you were sucessful, what would be different in the world, and why is that desirable to you?"

Normally at this point I'd listen to the response, and ask more questions based on that. That would wind up with a very, very deep thread, so I'll break a cardinal rule and pre-guess at some answers.

This kind of question comes up pretty frequently. In many cases, I suspect the motivation behind the question is "Wow! Here's this cool tool I've discovered. I want to make something really useful with it. I want to do it as part of a community effort; share my excitement with others, share in their excitement, and know that what I'm making is useful because others find it desirable and are excited by it." The field could be cooking, sports, old machine tools, tiny homes, or demo scene. Its the fundemental driver for most content on HN, YouTube, Instructables, and such. It is a Good Thing.

If that is your motivator, then my suggestion is to find something that bugs you and fix it. You've already decided you're only interested in code, not other aspects. You said you preferred vim, but the emacs ecosystem has a very rich set of sharp edges that need filing off, and a rich set of tools with which to attack them.

One example: even after 50 years there's no open IDE which allows you to easily globally rename a Lisp identifier. I don't know about LispWorks or other proprietary environments, but you can't in emacs or vim do a right-click on "foo" in "(defun foo ()...)" and select a command which automatically renames it in all invocations. [Queue lots of "but you can..." replies here.] I don't think vim is up to the task of doing this internally. It would be possible in emacs; but would require a huge effort with lots of help from other people. If you emerged alive from that rabbit warren you'd join the company of Certified "How Hard Could it Be?" Mad Scientists such as Dr. "I just want to draw molecules" Meister [1] and "Wouldn't an OS in Lisp be Cool" Froggey [2].

[1] https://github.com/clasp-developers/clasp

[2] Mezzano https://github.com/froggey/Mezzano

But also, there's a reason why most implementations readily make an effort to provide interoperability tools with a variety of runtimes. Clasp much like ABCL gives access to a whole library of other libraries trivially wrapped to interoperate with at little to no performance to cost (depending on how thin you make the wrappers, mainly).