ByFrost in Development —Three Steps Back and One Step Forward (Update Article)

Progress but also setbacks but mostly setbacks and a bit of progress.

A much easier experience

But first… progress update:

Dynamic “camera” movement.

NOTE: This article is just an update on Byfrost’s progress as opposed to the architectural stuff and changes I usually post about which I’ll post about soon. I just got a bit exciteable with this progress and couldn’t help but write about it 😶.

So, I’ve been coding Byfrost for a few months at this point and all these months later, I have to conclude that, wow… it’s kinda incredibly difficult. I initially started this project to build myself a tool that would make indexing any codebase I came across a UI dream but the further I get, the longer the road ahead to a V1 seems to get. Every time I add a new thing it seems to open up like nine more holes; adding dynamic camera movement when expanding a function introduced the need to go back up the callstack, that then introduced the need for a sort of helper nav bar that would have a display of everything so you could hop to it from anywhere, that now introduces the need to have that side panel navigation tied to backclicks as using the mouse gets exhausting on a trackpad and so on.

I guess the real problem is reaching a point where it’s comforably usable and I can get really productive with it. Right now, not being able to expand class methods and submethods (the this.that().another().before() I don’t know what these are called) hinders this a lot because Go projects are riddled with these. Starting with C would’ve probably been a safer bet but hindsight.

The thing that makes this so hard I think is that I find myself writing a huge chunk of Go’s compiler frontend and then having to represent it in a sort of “flat” structure as opposed to an AST while retaining its heirarchical structure. This idea’s ran rings around my brain.

Anyway, this is just a “road so far” to give an update on the progress of this project. Everything added to from the last article is mainly UI stuff and nothing particularly tied to indexing so I won’t really go into anything this post.

Okay… let’s try this again…

For now, there’s at least 4 things I wanna check off my list before feeling confident in a V1. I’m sure this time. I know, I know, I’ve said this before but this time I got it!

These are:

• 1 Degree struct/method dereferencing — the 1-degree part is really important. It turns out expanding one of these function.functionA().funcitonB() is kinda really hard and I haven’t come up with a comfortable way which might need a massive overhaul so for now, this’ll take a back seat. 1 degree specifically means something like os.File
• Function and Struct Info — You might’ve noticed that Function goes here (someday) placeholder. Well, that’s where info on things like a struct you’ve currently clicked on will go. No point in expanding out a struct in a graph as it isn’t necessarily part of control flow, but it’s a point of interest.
• (Nice to have) Expansion of system methods — currently only packages relative to the project’s root are dereferenced. Expanding fmt and os and log isn’t supported. This one’s not bad because all it entails is doing to Go’s native library directory what’s already being done ot the relative project directory. My only concern is the noise this might add. At the very least, I never need to expand out system methods and functions.
• Mapping — ah yes, these pesky mapping blocks I just can’t seem to get a grasp on no matter how hard I try. This still clearly needs to be addressed although this problem is more annoying than difficult and I’m happy to push it own the queue until the above is sorted.

I think that should be everything for now.

All that other stuff like making it an Electron app or a plugin is just too far off right now as the lexer/parser’s taken up all my energy and time and is giving me endless amounts of trouble.

The goal right now is to get to something that’s intuitively useful to use. Unfortunately that involves implementing a large part of the language itself. I’d find myself experimenting with it and just forgetting that some things aren’t clickable and it’d totally kill my immersion.

I also think that after Go, I’ll be in a better position to create a mandate of sorts for integrating new languages. The absence of an AST being generated after parsing is a pretty interesting problem I think only really needs to be solved once and then can be replicated.

If You’d Like to Try It Out

Also, I’m experimenting with testing this application I’m making and inviting others to sign up to try it out. There’s a few collaborative features I want to experiment with; things like causal analysis features to help with live debugging. I think this could be really valuable to overall workflow. If you’re keen to, it’d be great to have some early users to give this a go. The first version will just be a callstack visualizer. If that sounds like something you reckon would make your life a bit easier, feel free to drop your email in this Google form.

Alright, that’s all.

Till my next update sometime before the heat death of the universe.