It turns out the answer was a qualified yes, as there was a bug that would bite you in some cases. This is now addressed and fixed in Kaimon.jl 2.3.0, release is up on the registry. Please let me know if that’s working for you?
Hey everyone,
I just wanted the community to know that Kaimon.jl is apprently not gone for good. I managed to speak with @kahliburke yesterday and his hiding of his repos was not done as an act of spite or revenge, but as his way of protesting what happened in the last couple days here which he felt as censorship.
I would have preferred to post this on Why is Kaimon.jl no longer available? but that is now closed.
I am not trying to re-open the discussion or justify the actions of any of the parties involved, as that discussion already went on for too long.
I just thought it fair to also mention this in this forum as I think many here were genuinely happy users of the package. He told me he is working on moving all of his package outside of github and on separate git hosting.
I am not sure he’ll be even considering updating General on the new location, and while that will likely significantly reduce the adoption of his work, I am still happy that the work he is doing is not just disappearing. I do use Kaimon every day and I genuinely appreciate @kahliburke’s contribution to the ecosystem (and I believe many in the julia community do).
I’ve closed this thread to avoid reigniting the topic and discussing Kaimon.jl without its author. I’m glad to hear that Kaimon.jl development might continue! If/when Kahli would like to continue his updates here we can reopen the thread.
@kahliburke happy to see you back!
It seems that Kaimon.jl is back 
Yes back and being updated frequently, we’re now at version 2.4.1 with several bug fixes and lots of new features, many of them centered around supporting KaimonSlate.jl, but also useful outside of that context.
I’m about to publish 2.5.0 which will add the ability for extensions to specify environment variables. This is motivated by Slate wanting to customize Julia’s threading behavior in order to unlock greater performance. I’ve been running new benchmarks and Slate notebooks are now capable of streaming data from Julia to the browser at speeds (measured on my MacBook Pro M3 Max) of > 1 GBytes/sec with average latency of 2 ms, delivering 1000 frames / sec.
If you decrease the frame size you can achieve higher frame rates and sub millisecond p50/p95 latencies:
Hey @kahliburke ,
just stopping by to say that this is such an amazing package, totally love it. thanks for it!
Thank you for the kind words! Please let me know if there’s anything I can do to improve it, also check out KaimonSlate.jl 
.
Does KaimonSlate support computations on external clusters where, once you access the login node, you need to request resources using a scheduler (e.g., PBS or slurm).
With either of those, I need to explicitly request resources (CPU/GPU cores) for a limited duration. It’d be very convenient if I could do computations remotely and visualizations locally
Hi, I have not implemented integration with systems like SLURM. I think this could be an interesting use case, however. I’d be up for investigating how to enable something like this. Perhaps we could discuss a bit over DM and make sure my approach would cover your needs?
This would be amazing. If you need extra support or testing on a SLURM cluster please contact me.
Especially if it could support
Yes, cluster/scheduler support seems like one of those features that could make the whole workflow much more useful in practice, especially for people who already live in SLURM/PBS environments.
If you had a specific mode in mind, it’d be helpful to spell it out a bit: e.g. launching a Julia worker inside an allocation, attaching to an already running job, forwarding visualization data back to the local browser, handling GPUs, etc. Those details will probably matter a lot for designing something that works across different cluster setups.
How about all of the above? That’s what’s in progress.
I’ve now pushed cluster support for SLURM and PBS to the feature branch at GitHub - kahliburke/KaimonSlate.jl at feat/hpc-cluster · GitHub.
This needs some more testing from some brave lab ra^H^H^H^H^H^H beta testers so please get in touch if you match that description. I don’t have access to a real cluster at the moment so I’ve been running my tests against a docker environment running the real SLURM and PBS schedulers, but obviously in a much more constrained setting. I’m sure there will be a few snags along the way for those who would like to experiment with it, but I’ll be responsive and try to waste as little of your time as I can.
Docs are yet to be written, but will be in place soon. A sneak peak in some images below:
Do I really need to start the Kaimon server with the --revise option, if I simply run using Revise in the client REPL session before running KaimonGate.serve()?
No, that option is really more for internal development of Kaimon itself. I often use it when making code changes to the tool. Due to the way Kaimon is written, that flag allows the running system to pick up changes without restarting the TUI.
That’s the way it works for the projects you connect to via Kaimon. So either as you’ve stated it or what I do which is the code in my Julia startup file.