Are there any IDE's that allow you to visually interleave the stack trace with debug output, so you get a picture of which frames the output occurred within?

Quoting myself from yesterday "Observable is written in a notebook style where its divided into cells. The cells are great because, even though this cell was evaluated a while ago, we can inspect in our leisure the last value, so the program leaves a trace of its execution. The state of the cells are remembered. The fact that it remembers makes it very powerful for development." Thanks to hot code reloading, in server programming, we can remember an incoming request in a cell THEN write the implementation AFTER we observe the schema in the external request. We can lazy code against reality, without waiting on fresh requests to arrive

@Steve Dekorte If I understand your description correctly, any Smalltalk system qualifies.

@Tom Larkworthy That's really interesting(!) but feels slightly different. A stream of time-ordered output with stack frame attached, as opposed to the most recent execution of every possible stack frame, without time-ordering information. If I understand you correctly. @Konrad Hinsen what form of debug output are you thinking of in a Smalltalk program? @Steve Dekorte it isn't an IDE, but I have this tiny framework for emitting logs with an associated stack depth, along with a tiny tool to zoom in and out of such logs. https://git.sr.ht/~akkartik/basic-whitebox-test/tree/main/item/browse_trace/Readme.md The basic idea is totally language agnostic. Debug by print on steroids.

@Kartik Agaram I don't usually do "debug output" in Smalltalk. I just set a breakpoint and get the stack trace plus access to an inspector on all the data from the debugger. If you want to do the traditional style of debug output, Smalltalk systems have the transcript tool for that. In older systems, it captures a character stream. In Pharo + Glamorous Toolkit, I can send arbitrary objects, including stack frames. There's also the Beacon system (https://github.com/pharo-project/pharo-beacon), a framework specifically made for logging events, with stack frames if desired. You can even open a debugger from each stored stack frame. The real message here is that Smalltalk provides (1) an extendable IDE and (2) full introspection on program execution. Capturing a stack frame is a pretty standard operation. The main barrier for newcomers is understanding what a stack frame is, not the technicalities of capturing it.

I'd say that images are the most surprising thing for people new to Smalltalk (and some Lisps). Instead of running a program, you think of having a long lived environment with a bunch of stuff in it. In practice, messy people like me end up ruining their image after a while. But this isn't an intrinsic limitation of the approach. Nothing prevents adding isolation, revision. sharing, and features to an image-based system. I'm mostly surprised it hasn't been explored more.

@wtaysom My impression is that what you describe is exactly how most Smalltalkers work today. It's certainly how I work today. My startup configuration file loads all my projects that are not already in the image. Which means that I can start up a fresh image with very little effort. And I end up doing that about once a week. Not necessarily because I messed up my image (though that happens), the main reason is staying up to date with Glamorous Toolkit development. From that point of view, the image is more like a cache than persistent system state. In line with that view, I don't back up my images, as they are not really valuable. The persistent version of my code resides in Git repositories, just like with code in any other language.

Wow, pointers appreciated on how to maintain the startup configuration. Are you doing double work for every mutation?

@Kartik Agaram This booklet on managing code with Iceberg may help: http://books.pharo.org/booklet-ManageCode/pdf/2020-05-12-ManageCode.pdf There's no double work really… You make your changes inside the image. If it's something you want to preserve, you commit it via Iceberg and associated tools, which automatically snapshot the modified modules as text files and commit those to Git. The image startup configuration is a list of module repos and commit IDs, which recreates the image state from the Git committed snapshots.

@Kartik Agaram Indeed, as @J. Ryan Stinnett said, there is no double work. The startup script constructs the image by loading packages. Here's a typical piece of code from my startup script:

(RPackageOrganizer default includesPackageNamed: 'BaselineOfZotero')
    ifFalse: [
        Metacello new
            baseline: 'Zotero';
            repository: '<github://khinsen/GT-Zotero:main/src>';
            onConflictUseLoaded;
            load ].

It's the same principles as in Common Lisp's "systems", the main difference being that nowadays, most people use Common Lisp images like compiled binaries, created once but then never modified. The difference is purely in usage patterns.

Thanks for the update @Konrad Hinsen. I haven't used Smalltalk in anger in 20 years and so fully expect that I don't know a thing about modern setups. (Except for having clicked around Glamorous Toolkit a bit. How could I not?)