- The current state/value of a widget should be obvious/visible.
- If the value doesn't fit the last digit should be faded to indicate that the value shown is only partial. A good heuristic would be to choose a size that is large enough to fit 3 digit numbers (e.g. selecting a value between 0-100)
- Expand the label when the user is interacting with the widget.
- The the widget's state/value should always be visible, move the location of the label if necessary (e.g. when pointer is interacting with the widget)
- A widget should optionally provide an indication of the min/max boundaries, where relevant.
- The slider should optionally provide an indication of intermediate values (e.g. axis ticks) between the min/max boundaries, where relevant.
- UI elements that are used for fine control (e.g. knobs) should be big enough to make them easy to grab.
- For widgets with a single functionality the entire widget's area should optionally be wired to trigger the widget's action.
fn gltf_node_spawner( | |
mut commands: Commands, | |
node_handles: Query<(Entity, &Handle<GltfNode>), Added<Handle<GltfNode>>>, | |
assets_gltf_nodes: Res<Assets<GltfNode>>, | |
assets_gltf_mesh: Res<Assets<GltfMesh>>, | |
) { | |
for (parent, handle) in &node_handles { | |
let Some(node) = assets_gltf_nodes.get(handle) else { | |
warn!("GltfNode not found: entity {:?}, {:?}", parent, handle); | |
continue; |
preface: Posting these online since it sounds like these notes are somewhat interesting based on a few folks I've shared with. These are semi-rough notes that I basically wrote for myself in case I ever needed to revisit this fix, so keep that in mind.
I recently bought an LG ULTRAGEAR monitor secondhand off of a coworker. I really love it and it's been great so far, but I ran into some minor issues with it in Linux. It works great on both Mac and Windows, but on Linux it displays just a black panel until I use the second monitor to go in and reduce the refresh rate down to 60 Hz.
This has worked decent so far but there's some issues:
- It doesn't work while linux is booting up. The motherboards boot sequence is visible just fine, but as soon as control is handed over to Linux and I'd normally see a splash screen while I'm waiting for my login window, I see nothing.
- It doesn't work on the login screen. This would be fine if login consistently worked on my second screen, but I need to manually switch
This worked on 14/May/23. The instructions will probably require updating in the future.
llama is a text prediction model similar to GPT-2, and the version of GPT-3 that has not been fine tuned yet. It is also possible to run fine tuned versions (like alpaca or vicuna with this. I think. Those versions are more focused on answering questions)
Note: I have been told that this does not support multiple GPUs. It can only use a single GPU.
It is possible to run LLama 13B with a 6GB graphics card now! (e.g. a RTX 2060). Thanks to the amazing work involved in llama.cpp. The latest change is CUDA/cuBLAS which allows you pick an arbitrary number of the transformer layers to be run on the GPU. This is perfect for low VRAM.
- Clone llama.cpp from git, I am on commit
08737ef720f0510c7ec2aa84d7f70c691073c35d
.
John Belmonte, 2022-Sep
I've started writing a toy structured concurrency implementation for the Lua programming language. Some motivations:
- use it as a simple introduction to structured concurrency from the perspective of Lua (this article)
- learn the fundamental properties of structured concurrency and how to implement them
- share code that could become the starting point for a real Lua library and framework
So what is structured concurrency? For now, I'll just say that it's a programming paradigm that makes managing concurrency (arguably the hardest problem of computer science) an order of magnitude easier in many contexts. It achieves this in ways that seem subtle to us—clearly so, since its utility didn't reach critical mass until around 2018[^sc_birth] (just as control structures like functions, if
, and while
weren't introduced to languages until long after the first compu
I have a Linux virtual machine inside a customer's private network. For security, this VM is reachable only via VPN + Citrix + Windows + a Windows SSH client (eg PuTTY). I am tasked to ensure this Citrix design is secure, and users can not access their Linux VM's or other resources on the internal private network in any way outside of using Citrix.
The VM can access the internet. This task should be easy. The VM's internet gateway allows it to connect anywhere on the internet to TCP ports 80, 443, and 8090 only. Connecting to an internet bastion box on one of these ports works and I can send and receive clear text data using netcat. I plan to use good old SSH, listening on tcp/8090 on the bastion, with a reverse port forward configured to expose sshd on the VM to the public, to show their Citrix gateway can be circumvented.
I hit an immediate snag. The moment I try to establish an SSH or SSL connection over o
Revision: 06.08.2023, https://compute.toys/view/398
fn sdCircle(p: vec2f, r: f32) -> f32 {
return length(p) - r;
}
Revision: 06.08.2023, https://compute.toys/view/407
fn sdSphere(p: vec3f, r: f32) -> f32 {
return length(p) - r;
}
// Author: Victor I. Afolabi | |
// Implementing the Fibonacci series using Rust's Iterator | |
#[derive(Debug, PartialEq, PartialOrd)] | |
pub struct Fib { | |
current: usize, | |
next: usize, | |
} | |
impl Fib { |
// Author: Victor I. Afolabi | |
// | |
// Exploring Iterator Traits in Rust to implement Flatten functionality of 2D-iterators. | |
// | |
pub trait IteratorExt: Iterator { | |
fn flatten_ext(self) -> Flatten<Self> | |
where | |
Self: Sized + std::fmt::Debug, | |
Self::Item: IntoIterator, |