[FEATURE] Fastplotlib component cleanup

[shivam-singhal]

We have support for fastplotlib locally (not via browser yet).

Let's clean up the fastplotlib component so it doesn't cause preswald cli to display

objc[68434]: Class GLFWHelper is implemented in both /Users/shivam/miniconda3-arm/envs/preswald/lib/python3.11/site-packages/glfw/libglfw.3.dylib (0x104b2dbb8) and /Users/shivam/miniconda3-arm/envs/preswald/lib/python3.11/site-packages/imgui_bundle/libglfw.3.dylib (0x1052c5840). One of the two will be used. Which one is undefined.
objc[68434]: Class GLFWApplicationDelegate is implemented in both /Users/shivam/miniconda3-arm/envs/preswald/lib/python3.11/site-packages/glfw/libglfw.3.dylib (0x104b2dc08) and /Users/shivam/miniconda3-arm/envs/preswald/lib/python3.11/site-packages/imgui_bundle/libglfw.3.dylib (0x1052c5890). One of the two will be used. Which one is undefined.
objc[68434]: Class GLFWWindowDelegate is implemented in both /Users/shivam/miniconda3-arm/envs/preswald/lib/python3.11/site-packages/glfw/libglfw.3.dylib (0x104b2dc30) and /Users/shivam/miniconda3-arm/envs/preswald/lib/python3.11/site-packages/imgui_bundle/libglfw.3.dylib (0x1052c58b8). One of the two will be used. Which one is undefined.
objc[68434]: Class GLFWContentView is implemented in both /Users/shivam/miniconda3-arm/envs/preswald/lib/python3.11/site-packages/glfw/libglfw.3.dylib (0x104b2dc80) and /Users/shivam/miniconda3-arm/envs/preswald/lib/python3.11/site-packages/imgui_bundle/libglfw.3.dylib (0x1052c5908). One of the two will be used. Which one is undefined.
objc[68434]: Class GLFWWindow is implemented in both /Users/shivam/miniconda3-arm/envs/preswald/lib/python3.11/site-packages/glfw/libglfw.3.dylib (0x104b2dcf8) and /Users/shivam/miniconda3-arm/envs/preswald/lib/python3.11/site-packages/imgui_bundle/libglfw.3.dylib (0x1052c5980). One of the two will be used. Which one is undefined.

every time it's run

Additionally, to use the fastplotlib component, it seems you need to pass in the preswald service client id. Is there a way to avoid this dependency?

[shivam-singhal]

@BloggerBust you have the most context on this.

CC @bhavyagada @kushalkolar

[bhavyagada]

I see the script re-running because of state changes in fastplotlib plots. Notice that I'm on run '24,' and it doesn't stop!

I haven't looked into the latest changes but do you happen to know what might be causing this? @BloggerBust @shivam-singhal

[shivam-singhal]

not immediately sure, but will take a look

[bhavyagada]

I would also suggest keeping the examples self-contained.

For instance, I had created examples/fastplotlib for Fastplotlib-specific code. Similarly, Matplotlib, Chat, and Plotly should each have their own separate examples directory. If a new user tries running the Iris example, it shouldn't break for them due to unfinished features.

Maybe we can segregate them into working and partially-working directories!

[BloggerBust]

Thanks for flagging this!

I added logging to the fastplotlib component to check if rendering was being skipped based on a matching data_hash. From the logs and I can confirm that rendering is indeed being skipped consistently when the hash matches the stored state. So the render logic appears to be behaving as intended.

Despite that, the script is still rerunning endlessly, which suggests that set_component_state() may be causing reruns even when the value hasn’t changed. I’ll need to dig a little deeper into how state updates are triggering reruns internally.

I'm currently tied up with another project but will make an effort to investigate this today or tomorrow and I will keep you posted.

[BloggerBust]

I created a new issue to track the root cause of the infinite rerun behavior here: #565

I created a fix in PR #566, which ensures that component state updates are only processed if the values have actually changed. This prevents unnecessary reruns and resolves the infinite loop observed with Fastplotlib.

Feel free to chime in if you spot anything else!

[BloggerBust]

Hey @shivam-singhal

Those objc[...] logs you're seeing — like this:

objc[68434]: Class GLFWWindow is implemented in both ...

indicate that two different versions of the GLFW shared library (libglfw) are being loaded at the same time. I would expect this to happen when both glfw and imgui_bundle packages are installed and both include their own GLFW binaries. It's not a crash, but it is undefined behavior and can lead to flaky rendering issues.

I am unable to reproduce this since I am running on a Linux distro and those are objective-c errors ( mac specific ). I’d like you to test this with a clean environment and with the latest fix from both PR #599 and PR #566, so that your test is isolated from any unrelated frontend or websocket bugs.

Steps to Reproduce in Clean State
Please follow the steps below:

1. Fetch latest origin and create a clean test branch

git fetch origin
git checkout -b test_559 BloggerBust:fix_react_render_issues
git pull origin BloggerBust:fix/skip_rerun_unchanged_states

This will give you the latest React/WebSocket fix and the script rerun prevention logic from #566 in one branch.

2. Start with a clean virtualenv

deactivate  # If you're in one
rm -rf .venv
python3 -m venv .venv
source .venv/bin/activate

3. Install Preswald locally in editable mode

pip install -e .

4. Rebuild the frontend

python setup.py build_frontend

5. Run the iris example

cd examples/iris
preswald run

Then check whether you're still seeing any objc[...] logs in the terminal.

6. If the issue persists...
   Please run the following to see which shared libraries are being loaded:

DYLD_PRINT_LIBRARIES=1 preswald run examples/iris

Look for any duplicate libglfw.dylib entries and paste the output here so we can help resolve the root cause. Thanks for testing this! This will help us confirm whether the duplicate GLFW issue is still happening after the recent fixes.

[BloggerBust]

Additionally, to use the fastplotlib component, it seems you need to pass in the preswald service client id. Is there a way to avoid this dependency?

Hey @shivam-singhal,

That is a great question! I’ve created a new issue to address this exact concern and replace the current workaround with a more robust solution:

[FEATURE] Introduce ContextVar-based session metadata access (e.g., client_id) (#587)

The idea is to use a ContextVar during script execution so components can access session-level metadata (like client_id) without requiring user scripts to manually fetch or pass it in. This would cleanly remove the need to import PreswaldService in user code and keep everything declarative.

I also noted an alternative approach: implementing a full backend session service to manage per-client metadata. If you think that would be worth the investment at this stage, either for broader use cases or to future-proof things, I'm happy to pursue that route instead.

[kushalkolar]

Hey @shivam-singhal

Those objc[...] logs you're seeing — like this:

objc[68434]: Class GLFWWindow is implemented in both ...

indicate that two different versions of the GLFW shared library (libglfw) are being loaded at the same time. I would expect this to happen when both glfw and imgui_bundle packages are installed and both include their own GLFW binaries. It's not a crash, but it is undefined behavior and can lead to flaky rendering issues.

This is weird, imgui doesn't need glfw, we use wgpu to render it to any canvas. Might be worth posting an issue on the imgui-bundle repo.