Coder Legion - Recent posts tagged debugger

Added a tagging system to my runtime debug panel — FludeX 1.2.0 (Unity UIToolkit)

Thu, 25 Jun 2026 21:10:46 +0000

Prefix any Debug.Log with [TAG]: and it shows as a colored chip right in the log list. Assign custom colors per tag via config. Timestamps too — game time or wall clock, toggleable per project.

Curious — what tags would you use in your project? And is there anything you wish runtime console tools did that they currently don't?

Top JSON Formatting & Validation Tools (Fast + Developer-Friendly)

Mon, 14 Jul 2025 07:43:29 +0000

Here are some fast, reliable tools for JSON formatting and validation — perfect for developers working with APIs, logs, or large JSON payloads.

1. jsonformatter.org

✅ Format, validate, minify, and view JSON
Has tree view and raw text view
Supports upload + clipboard copy
Also supports XML, YAML, JWT, CSV

Fastest and most comprehensive online tool.

⚡ 2. jsoneditoronline.org

Visual + code editor side-by-side
Detects and highlights syntax issues live
Offers "Transform", "Sort", and "Filter" tools
Supports collaboration with shareable links

Great for working with deeply nested JSON visually.

3. VS Code (Built-in or Plugin)

✨ Use built-in formatting: Right click → Format Document
Extensions:

Prettier (formatting)
JSON Tools (validation, sorting, filtering)
Works offline and with huge files

Ideal if you're already coding in VS Code.

4. quicktype.io

⚙️ Convert JSON → TypeScript, Python, Java, etc.
Also formats + validates input
Instant TypeScript interfaces for Angular/NestJS devs

Best for generating types/interfaces from real API responses.

5. CLI Tools (For local work)

If you want a fast terminal-based option:

✅ `jq` (lightweight and powerful)

jq '.' data.json  # Format
jq type data.json # Validate

Install:

brew install jq   # macOS
sudo apt install jq   # Ubuntu/Debian

Fastest tool for shell scripting and JSON pipelines.

Summary Table

Tool	Format	Validate	Extras
jsonformatter.org	✅	✅	Tree view, minify, export
jsoneditoronline.org	✅	✅	Visual editing, sharing
VS Code	✅	✅	Extensions, huge JSON
quicktype.io	✅	✅	Generate TS/Java classes
`jq` (CLI)	✅	✅	Scriptable, blazing fast

DevLog 20250708: Procedural Context Visual Debugger in Divooka

Tue, 08 Jul 2025 12:19:17 +0000

Overview

How difficult is it to achieve Unreal Engine-style procedural context debugging?

Turns out, it might be easier than expected.

In this dev log, we won't implement all the fancy animations or full-featured GUI yet, but we will derive a practical, functional debugger GUI. This interface allows users to step through a procedural program and observe its execution flow in real time.

The Debugging Problem

Procedural contexts are hard - not necessarily to implement (they're actually simpler than dataflow contexts in interpretative runtimes, where you just step over nodes), but hard for users.

The main issue is statefulness: once there's state, there's the potential for mistakes, side effects, and confusion.

From an implementation standpoint, the hard part is debugging. Without visibility into execution, it's difficult to guess what's happening. That's why programming languages without IDEs often fall back on Print statements to inspect runtime states. This approach quickly breaks down with larger programs or those involving intricate state transitions.

Even Python - often used without an IDE - includes a built-in debugger in IDLE (see tutorial). It's essential when working with complex logic.

Approach

Let's start by clarifying the setup: the current implementation of the Divooka graph editor (Neo) is done in WPF, using an interpretative runtime.

For drawing the GUI, we can use standard XAML data bindings and a few button states:

<StackPanel>
<!--Start-->
<Button Style="{StaticResource IconButtonStyle}" Click="ProceduralContextRunGraphWithoutDebugging_Clicked" ToolTip="Run and wait for the process to finish." Visibility="{Binding EvaluatingGraph, Converter={converters:BooleanToVisibilityConverter Negate=True}}"/>

<!--Continue-->
<Button Style="{StaticResource DebugButtonStyle}" Content="Continue" Click="ProceduralContextContinueWithoutStepping_Clicked" ToolTip="Skip debugging and continue the process to completion." Visibility="{Binding IsProceduralStepping, Converter={converters:BooleanToVisibilityConverter}}"/>

<!--Step-->
<StackPanel Visibility="{Binding EvaluatingGraph, Converter={converters:BooleanToVisibilityConverter Negate=True}}">
<Button Style="{StaticResource DebugButtonStyle}" Content="Step" Click="ProceduralContextStartDebuggingGraph_Clicked" ToolTip="Step into the process and observe each execution step." Visibility="{Binding IsProceduralStepping, Converter={converters:BooleanToVisibilityConverter Negate=True}}"/>
</StackPanel>

<!--Next Step-->
<Button Style="{StaticResource DebugButtonStyle}" Content="Next" Click="ProceduralContextContinueThroughGraph_Clicked" ToolTip="Execute (step over) the next step in the process."  Visibility="{Binding IsProceduralStepping, Converter={converters:BooleanToVisibilityConverter}}" IsEnabled="{Binding IsProceduralPaused}"/>

<Button Style="{StaticResource DebugButtonStyle}" Content="Finish" Click="ProceduralContextFinishDebuggingGraph_Clicked" ToolTip="Stop debugging the current process." Visibility="{Binding IsProceduralStepping, Converter={converters:BooleanToVisibilityConverter}}"/>

<Button Style="{StaticResource DebugButtonStyle}" Content="Pause" Click="ProceduralContextPauseExecution_Clicked" ToolTip="Pause execution of the current process." Visibility="{Binding EvaluatingGraph, Converter={converters:BooleanToVisibilityConverter}}" IsEnabled="{Binding IsProceduralPaused, Converter={StaticResource InvertBooleanConverter}}"/>
</StackPanel>

Stepping Through Execution

Initially, I thought we needed a dedicated execution runtime for stepping, due to the complexity of node interpretation. However, it turns out we can simply inject "breakpoints" during interpretation. The simplest way to achieve this in C# with multithreading is by using a ManualResetEventSlim:

// ── MainWindow.xaml.cs (WPF) ──
public partial class MainWindow : Window
{
// starts signaled (i.e. not paused)
    private readonly ManualResetEventSlim _pauseEvent = new ManualResetEventSlim(true);
    private readonly Executer _executer;

    public MainWindow()
    {
        InitializeComponent();
        _executer = new Executer(_pauseEvent);
    }

    private async void StartButton_Click(object sender, RoutedEventArgs e)
    {
// Run on thread-pool, but because we 'await', continuation
        // (Finish…) runs back on the UI thread.
        await Task.Run(() => _executer.ExecuteGraph());
        FinishProceduralContextDebuggingSession();
    }

    private void PauseButton_Click(object sender, RoutedEventArgs e)
    {
// next time the worker hits Wait(), it will block
        _pauseEvent.Reset();
    }

    private void ResumeButton_Click(object sender, RoutedEventArgs e)
    {
// unblocks the worker
        _pauseEvent.Set();
    }
}

// ── Executer.cs ──
public class Executer
{
    private readonly ManualResetEventSlim _pauseEvent;
    private readonly Random _random = new Random();

    public Executer(ManualResetEventSlim pauseEvent)
    {
        _pauseEvent = pauseEvent;
    }

    public void ExecuteGraph()
    {
        while (/* your long-running condition */)
        {
            DoWorkStep();  

// simulate a random pause point
            if (_random.NextDouble() < 0.05)
            {
                Debug.WriteLine("…pausing now");
// put event into non-signaled (i.e. paused)
                _pauseEvent.Reset();
                _pauseEvent.Wait();  // block until resumed
                Debug.WriteLine("…resumed!");
            }
        }
    }

    private void DoWorkStep()
    {
        Thread.Sleep(200);
    }
}

How It Works:

_pauseEvent starts in the signaled state, so .Wait() returns immediately.
Calling _pauseEvent.Reset() switches it to non-signaled, so .Wait() blocks the worker thread.
When the UI calls _pauseEvent.Set(), the blocked thread resumes execution.

Real-Time Visual Updates

A small challenge is real-time canvas updates - specifically, drawing a highlight box around the active node:

We can use an adorner for this:

/// <summary>
/// Show a red highlight around the specified FrameworkElement for a set duration.
/// </summary>
public static async void ShowSimpleHighlight(FrameworkElement target, double margin = 5, int duration = 3)
{
    if (target == null)
        return;

// Get the adorner layer for that target
    AdornerLayer adornerLayer = AdornerLayer.GetAdornerLayer(target);
    if (adornerLayer == null)
        return;

// Create and add adorner to the layer
    HighlightAdorner highlightAdorner = new(target, margin);
    adornerLayer.Add(highlightAdorner);

// Remove it after a few seconds
    await Task.Delay(TimeSpan.FromSeconds(duration));
    adornerLayer.Remove(highlightAdorner);
}

public class HighlightAdorner : Adorner
{
    private readonly Pen _pen;
    private readonly double _margin;

    public HighlightAdorner(UIElement adornedElement, double margin = 5)
        : base(adornedElement)
    {
        _pen = new Pen(Brushes.Red, 2);
        _pen.Freeze();
        _margin = margin;
        IsHitTestVisible = false;
    }

    protected override void OnRender(DrawingContext drawingContext)
    {
        Rect adornedElementRect = new(AdornedElement.RenderSize);
        adornedElementRect.Inflate(_margin, _margin);
        drawingContext.DrawRectangle(null, _pen, adornedElementRect);
    }
}

What's Next?

All that's left is a proper debug window!

Summary

A good framework truly goes a long way. I had confidence in bringing procedural debugging to Divooka from the moment procedural context was introduced, because it naturally fits into an interpretative execution model. All that's required is a bit of focused engineering.

The more challenging part is the GUI - but WPF offers solid isolation via MVVM, data binding, and adorners.

We're not dealing with setting actual breakpoints yet, but the current setup is flexible enough to support that when the time comes. Ultimately, a debug window will act as our lens into the runtime: inspecting node states, variable values, and control flow.

References

Procedural vs Dataflow context in Divooka on the Methodox Wiki.
Blueprint debugging in Unreal
Procedural debugging documentation on Methodox Wiki.

Debugging Shaders on macOS: Instruments vs. Gpumkat

Sat, 29 Mar 2025 20:34:03 +0000

Debugging Shaders on macOS: Instruments vs. Gpumkat

Debugging and optimizing Metal shaders on macOS has long been reliant on Apple's Instruments tool. However, a new alternative, gpumkat, has emerged, offering a different approach with enhanced debugging features. In this article, we will compare Instruments and gpumkat, highlighting their differences, strengths, and why gpumkat may be the superior choice for many developers.

Instruments: The Traditional Tool

Features:

Provides detailed profiling of GPU activity
Tracks memory usage and performance metrics
Offers GPU counters for in-depth analysis
Integrated with Xcode
Best suited for hardware-specific insights

Limitations:

No built-in shader debugging tools
Lacks robust breakpoint and step-through debugging for Metal shaders
Requires deep knowledge of GPU internals to interpret data
Limited support for timeline-based debugging and trace analysis

Introducing Gpumkat

Gpumkat is a GPU kernel analysis tool designed for Metal API debugging and performance analysis. Unlike Instruments, which is focused on hardware profiling, gpumkat offers a broader range of tools specifically for shader debugging and optimization.

Key Features:

Performance Analysis: Tracks execution time, cache hit rates, and memory usage.
Shader Debugging: Step-by-step debugging, variable printing, and breakpoints.
Energy Consumption Insights: Estimates GPU power draw and energy efficiency.
Interface Metrics: Monitors how buffers and pipelines interact.
GPU Software States: Tracks command execution flow.
Stack Tracing & Tracing Timelines: Logs and visualizes execution sequences.
Error Handling: Captures warnings, memory errors, and validation issues.
Low-End GPU Simulation: Tests shader performance under constrained hardware conditions.

Why Gpumkat is the Better Alternative

1. Superior Debugging Tools

While Instruments provides GPU counters and profiling, it lacks a dedicated shader debugger. Gpumkat allows developers to set breakpoints, inspect variables, and step through shader execution, making it far more effective for diagnosing shader issues.

2. Comprehensive Performance Analysis

Gpumkat offers in-depth insights into cache hit rates, memory bandwidth, and processing unit availability—data that is difficult to extract from Instruments alone.

3. Better Error Handling

With built-in error detection for memory leaks, shader validation failures, and runtime warnings, gpumkat prevents common pitfalls that are harder to catch using Instruments.

4. Simulated Low-End GPU Testing

Gpumkat allows developers to simulate lower-end GPUs to test how shaders perform under constrained conditions. This feature is crucial for ensuring compatibility with a range of hardware, something Instruments does not provide.

5. Enhanced Trace Logging and Timeline Recording

While Instruments provides time-based tracking, gpumkat offers a more detailed execution timeline, helping developers pinpoint slowdowns and inefficiencies in their shaders.

When to Use Instruments vs. Gpumkat

Use Case	Instruments	Gpumkat
Hardware-Specific Profiling	✅	❌
Shader Debugging	❌	✅
Breakpoints & Step Debugging	❌	✅
Memory & Cache Analysis	✅	✅
Error Detection	❌	✅
Low-End GPU Simulation	❌	✅
Timeline & Trace Recording	✅ (basic)	✅ (detailed)

Installing Gpumkat

Gpumkat is easy to install and requires minimal dependencies:

curl -L -o gpumkat.tar.gz https://github.com/MetalLikeCuda/gpumkat/releases/download/%s/gpumkat.tar.gz \
    && tar -xvzf gpumkat.tar.gz \
    && cd gpumkat \
    && sudo sh install.sh

Replace %s with the latest version number.

Conclusion

For developers focused on deep GPU performance profiling, Instruments remains the go-to tool. However, if you need shader debugging, error handling, and simulated performance testing, gpumkat is the clear winner. Its comprehensive feature set makes it an invaluable tool for Metal developers looking to optimize their shaders efficiently.

You can see the repository here

https://github.com/MetalLikeCuda/gpumkat

Coder Legion - Recent posts tagged debugger

Added a tagging system to my runtime debug panel — FludeX 1.2.0 (Unity UIToolkit)

Top JSON Formatting & Validation Tools (Fast + Developer-Friendly)

1. jsonformatter.org

⚡ 2. jsoneditoronline.org

3. VS Code (Built-in or Plugin)

4. quicktype.io

5. CLI Tools (For local work)

✅ jq (lightweight and powerful)

Summary Table

DevLog 20250708: Procedural Context Visual Debugger in Divooka

Overview

The Debugging Problem

Approach

Stepping Through Execution

Real-Time Visual Updates

What's Next?

Summary

References

Debugging Shaders on macOS: Instruments vs. Gpumkat

Debugging Shaders on macOS: Instruments vs. Gpumkat

Instruments: The Traditional Tool

Features:

Limitations:

Introducing Gpumkat

Key Features:

Why Gpumkat is the Better Alternative

1. Superior Debugging Tools

2. Comprehensive Performance Analysis

3. Better Error Handling

4. Simulated Low-End GPU Testing

5. Enhanced Trace Logging and Timeline Recording

When to Use Instruments vs. Gpumkat

Installing Gpumkat

Conclusion

You can see the repository here

✅ `jq` (lightweight and powerful)