Whoops

Had a small bug in the left arrow key in normal editing mode and popups weren’t resizing and re-positioning correctly, fixed all that :)

FINAL RELEASE BABYYYY (hopefully)

Finally, the debugger is working properly.

If you’ve tried a beta version, especially v1.1.0, you might have noticed the debugger being broken and kinda weird. I noticed that too, so I decided to rewrite it!
(technically, I rewrote it twice but oh well)

Why it needed a rewrite

Before, the debugger worked by executing the next step in-place and jumping in loops by moving the cursor to the matching bracket.
The problem was: to jump backwards when looping, you had to keep a history which could pretty quickly get filled if you were debugging enough and overall the system was too overengineered for what it was supposed to do.

The new architecture

The new debugger does almost the same that the live tape preview already does. The live tape preview has one caveat that doesn’t allow it to be directly used for the debugger though: we cannot track loop iterations on the cursor position alone, as we always just compute until the cursor. If we’re before a loop’s end, we’re only computing the first iteration. If we move past the loop, the whole loop gets computed in one move.Instead of the cursor pos, the debugger uses an instruction counter. It basically counts how many brainf*ck instructions it should run, which solves all problems here.

Why this works

Take this program:

++++++++[>++++[>++>+++>+++>+<<<<-]>+>+>->>+[<]<-]>>.>---.+++++++..+++.>>.<-.<.+++.------.--------.>>+.>++.

Say we wanna run 40 instructions. We first step over the initial ++++++++[>++++[>++>+++>+++>+<<<<- (33 instructions), and then we get to the first ].
When we do, the current cell is non-zero, meaning we jump back to the instruction after the highlighted bracket (++++++++[>++++ [ >++>+++>+++>+<<<<-).
The jump is one instruction. Then we run >++>++ and reach 40. Notice how we’re in the second iteration when it ends. If we now move the cursor forward by one, we tell the tape generator “execute 41 instructions”.
The same as before happens now (execute first bit, jump back, continue executing - but one instruction more than before this time) but we land in the second iteration again.

Popups are finished! (almost)

After a little bit of work, a popup system (which I gotta say is written kinda well compared to all the other code) is in place!

Currently, there are:

• Exit Confirmation Popup
• Save File Dialog
• Load File Dialog

One last thing is still missing though: The please press a button popup for inputs (,).

Technical Details

The popup system works by using a sub-struct inside of the global state struct (state.popup). It contains data such as whether a popup is active, if it accepts text input and handlers for drawing and the confirm button.
 
There’s a base func (create_popup_base()) that draws a new basic outline for the popup. After that, only the contents of the popup get refreshed via the custom handler set via setting a function pointer (state.popup.refresh_handler).
The popup also “captures” input. There’s a seperate if for state.popup.active before the main input validation which processes inputs and then skips the normal input processing.

The debugger works!!

After hours of work (mainly debugging and patching up code), it finally works! :DD

The power of the debugger

You can use the debugger to step forward and backward in your brainf*ck program. While stepping, a live program counter display (labelled “PC”) shows the current program counter index, while the tape in the bottom panel shows the current state of each cell, which cell is currently selected by the data pointer and what the cell contains, in both decimal and ASCII format.

The following is just for if you’re interested in the technical details ;)

Why I wanted to wipe my drive several times while making this (Problem 1)

The first main problem in writing the debugger was stepping backward. You’d think its just “do the instruction in reverse, like when you back-step a -, just do a + instead” but the problem arises when, for example, you read in something using , and the info got overwritten. How do you reverse to something that got destroyed? Well, you don’t.

The Solution to the Back-Stepping problem

I implemented backward stepping by just recomputing the entire tape from scratch on every backstep. Yes, it’s probably not the best way, but it works.

Problem 2

Loops. Once. Again.
The jumping around of loops in brainf*ck is not the simplest thing to correctly compute, especially when only partially executing a program.
When you land on a [ or a ], you also need to account for nested loops. You can probably imagine that that can definitely cause some headaches.

Live tape preview is done!

While writing or editing code or by literally just moving your cursor, you now get a live preview of the programs “tape” (basically it’s entire data it works with).

There is one big problem with the current system however. If you’re interested, feel free to read the following.

The big Issue

Loops. You see, in brainf*ck, loops work by using [ to jump to the matching ] if the current cell is zero and by using ] to jump to the matching [ if the cell is non-zero.
This behaviour is actually not that pleasant to simulate when you’re only executing to a specific point in the program, because the “simulator” (the thing that interprets the bit of brainf*ck code up until your cursor and then generates a tape from that) can’t see the matching closing ] as it comes after the cursor. This means the loop will never really execute. But, when you navigate past the entire loop block, the cells jump to a completely different state (as seen in the video at around 0:08).

How am I going to solve it then?

I’ve decided that I dont want to “solve” it by somehow making loops work in live preview. I’ve decided live preview should only be relatively basic. For serious loop-involved debugging, I wanna introduce a special “Debug Mode”. In this mode, you’ll be able to step through your code, have chars printed into the output panel live AND also have the cursor/program pointer correctly jump around.

Menubar Navigation, Code Running and Output Display works!! 🎉 :)

Today, the IDE ran its first program! (and yes, of course, it was a hello world program)

What changed?

As already mentioned in the last post, I’ve rewritten part of the menubar rendering and also implemented output field rendering. Also, I’ve refactored the run_brainfuck function to be compatible with the UI.

Changes in the run_brainfuck(...) function

Before, it just stubbornly printed to stdout and read from stdin which of course kinda conflicts with the UI. To solve this, I made it write into an output buffer and accept a function pointer for a function that needs to return an int of which char was read in. The actual reading in will be handled by the pointed to function, which will probably be a “Please press a button” popup.

What’s next

Looking forward to getting the tape reel and then popups (including file saving/loading, exit confirm and please press a button) to work!

Great News! The editor is now fully working!

I’ve managed to implement everything from syntax highlighting to special keys such as delete, home and end.

Nice! What now?

I’m also working on getting the menubar to work, which’ll require rewriting a little part of the menubar rendering, as currently, the text entries get printed in one go with the spaces. If I somehow wanna highlight the text only, I gotta draw it all seperately.

Typing works!! not

Another Memory Violation :)
Gonna debug that one too i guess

On the flip side, I got syntax highlighting working!

This was literally me after opening my code today

On a side note:

I’ve cleaned up the codebase a little and split stuff into separate files for readability, like moving the editor draw function along with all its helpers into a separate file.

I’m about to start working on finishing the editor panel now. :)

holy productivity spike

I got the editor fully working!!! :)

After wanting to throw my computer from a comically large height (multiple times), it finally runs: proper arrow-key navigation, a fully working cursor, soft wraps, line numbers, and so on. Vertical scrolling is now fully functional aswell.

Even some comfort features like using the Home and End keys work!

Fun stuff I found out in the process

In the process of getting this to work I also discovered things like the fact that the pdcurses getch() macro implicitly refreshes the stdscr and then… doesnt… flush it 😐

Anything still borked?

Some things also still don’t work fully, which kinda bothers me. The main example of this is navigating the cursor vertically into soft-wrapped lines; because of how I wrote the row up/down logic - which is to check in the editor buffer where the next or previous line feed is and then navigate based on that - I can’t just say “oh theres a soft line wrap lets just detect that instead of a \n” because the rendering (which does the soft line wrapping) and the I/O loop don’t communicate with each other

Sure, I could fix it by adding a shared data structure which contains all line wrappings, but for now, I just wanna get the more important stuff running.

Any plans now?

Anyways, I’m planning to finish the editor fully by adding writing text (wild concept, i know!) and syntax highlighting next.

Stay tuned to find out how much I continue to suffer! :’)

No more Access Violation! Also, I managed to get the editor drawing going! :)

The interesting thing about the access violation fix is: I have no clue what caused it - it just kinda went away?? But oh well, the error is not happening anymore :D

Whats working now?

I so far mainly implemented colored line numbers and soft wrapping. The implementation for vertical scrolling however isn’t written yet, that’s the plan next. Also, I’ll probably implement cursor navigation with that in one go.

I also made some small optimizations to the main loop plus a few fixes and adjustments here and there.

I managed to prove why C is the most memory safe language that exists!!

This gets triggered by literally just resizing the window and I have zero idea why :’)

On a side note though, I’ve been working on the editor panel a little and it’s slowly coming together.

Anyways, looking forward to debugging hell for that one overflow or nullpointer (or whatever the hell this is)!

Panel borders are done and working! :D

How annonying was it?

The tricky part was getting the layout constants to line up correctly (it gets pretty annoying if you’re trying to find where you accidentally forgot to add one to a value)
Got there in the end though.

Anything else?

Also cleaned up the repo. I also added a git submodule so that PDCurses actually gets cloned too if you pass the --recurse-submodules when cloning.
Now the foundation is solid and I can actually start on the editor itself next session. :)

I also included a lil preview of how it looks rn :)

Introducing: Brainf*ck IDE - a TUI-based IDE for writing and running brainf*ck, built in C using PDCurses.

The IDE has a panelized layout: code editor on the left, output on the right, and a live tape viewer along the bottom so you can actually watch memory change in real time while writing code!
The screenshot is mocked up manually for now, the code for drawing doesn’t exist yet 😅

Whats already started

So far I’ve got the interpreter written and a few basic rendering steps working, including the top menubar.

How it works

The brainf*ck interpreter is actually really simple: you need a loop to iterate through a program buffer, then check for any “special” chars like <, +, … and then just increment/decrement values or do some simple logic depending on which char it is.

Next, I’ll try to do the panel borders and some panel setup.

Looking forward to how much stuff will break! :)