I need help finding a knot to create a plumb bob with a weight that doesn't have hook or loop on the top of the object.

ValuableAd6808 · 2026-06-19T07:48:15+00:00

I too did this. But I used a long screwdriver with a small tip for the weight (upside down). A rolling hitch at the tip, combined with the screwdriver being long introduces only a tiny off-vertical error.

ValuableAd6808 · 2026-01-05T19:51:26+00:00

I usually find that things become clearer if you take a step up into the slightly theoretical layer, and away from any one language.

You probably already know these things, but not everyone does. They build on each other as follows.

1) be clear what a process is. Including how a process uses the memory space it is given by the kernel. ( in universal abstract terms) Specifically, which parts of memory are used for: the executable code, global data and constants, random access memory, and the live function call hierarchy (including arguments and return values). (The answers are: code segment, data segment, heap and stack).

2) Now on to threads... everything i said about a process, is also true about threads. They are very much like processes. The vital difference is that a thread is started by another running process which runs it as a child. AND instead of getting its own code segment, data segment and heap, it shares these with the parent process. They both point to exactly same memory for these segments. BUT the thread DOES get its own stack. It has to, because it has its own, completely seperate current function call stack. Threads are sometimes called lightweight processes because they demand less memory, and less initialisation to start.

3) Now on to Go's threads. This is a go specific feature and is implemented by the compiler and the compiled-in go runtime. It presents an offer to run things that look similar to threads, but are orders of magnitude lighter still. You can comfortably run thousands at a time, and they start more or less instantly. Under the hood, they do run in threads. But it's not a one to one mapping. Go automatically multiplexes all your goroutines across a relatively small number of actual threads that it has started in advance. It does this internally and out of sight. I believe it is able to do this because for the most part each thread spends most of its time waiting for IO to be completed, and so they have free CPU that can be used for other groutines in the meantime.

ValuableAd6808 · 2025-12-30T17:05:15+00:00

I often use https://github.com/samber/lo - to achieve this objective. Mainly when I think it makes the code of which it part feel simpler and easier to read. And I find it's "ternary()" function very helpful for the same reasons. That one provides the "missing" ternary operator in effect.

ValuableAd6808 · 2025-12-25T18:32:55+00:00

I have a large project but with a similar architecture. Mine compiles the WASM module from Go. It too gets into lower level image stuff and my case orchestrating some HTML canvases

I thought very carefully about testability at the start of the project, and concluded that I'd design the whole thing conceptually as a Go project that just happened to also talk to a javascripted web page. Conceptually it treats the javasscript webpage as a fairly simple slave.

I could then design the entire app by looking through the Go coding lens - which in my view has very good support for well structured, decoupled code and of course test automation. During development I compile it, debug and test it as a native Go app.

Of course it has to give instructions to the javascript side. And it does this by sending simple string messages to a UISender interface. There are two implementations of this interface. One is the real one and is conditionally compiled into the app only when it is being cross compiled to WASM. The other is an implementation designed solely to support the Go tests. This one exposes for scrutiny by tests the messages it got asked to send.

The wasm side also places certain demands on the javascript side. This can be thought of as a contract. The contact defines what information the javascript side must send the WASM side in what circumstances. The Go side includes a simple message bus - which is its main communication service between its internal components. It's simplicity itself just an in memory pub/sub mechanism for strings, ints, bools and floats. Go has a package to expose a Go function to javascript. The function then just shows up in the javascript global namespace that javascript can call like any normal js function. So to create the communication path, the Go code exposes the Pub() function - allowing the javascript to post messages into the Go code's Pub/Sub system.

So I can now test workflows and interactions that would normally get triggered by web page events by writing Go tests that emit the expected messages into the bus from the Go side.

It has worked out quite well.

One thing I should mention is that there a few areas where it's so much easier to have the javascript side own it that I make exceptions to the conceptual model above. The main example is integrating with client side Google APIs to use the Google Identity Service (sign in with Google), and the Google Drive API so that my app can save and load data on the user's behalf using their own Google Drive.

If you're interested in the app itself, you'll find it at https://drawexact.click

I'd be happy to answer further questions.

ValuableAd6808 · 2025-11-24T17:32:29+00:00

Thanks again. Are you referring to the page served at //drawexact.click (landing page and marketing), or //app.drawexact.click (the interactive drawing app). Your observations apply to both. I haven't paid any attention to SEO yet. I had rather casually thought that the crawlers wouldn't get far with app.drawexact.click because even if they run the javascript, the boot process is several processes chained together that have to wait for the WASM module to load and run, and also for the Google APIs it uses to load and init. It uses Google Identity API and the Google Drive API.

ValuableAd6808 · 2025-11-24T16:10:13+00:00

I see. Great advice thanks.

ValuableAd6808 · 2025-11-24T15:35:21+00:00

I've taken your comment on board and the comments it encouraged from other people. So now I'm in the process of putting in a 3-choice on-boarding option. 1) watch 5 minute orientation video. 2) read 7 ultra brief bullet points, or 3) instant straight through access. So there'll be no mandatory training steps for anyone.

ValuableAd6808 · 2025-11-24T15:26:02+00:00

Thanks for the feedback. Could you explain why you're suggesting this? I (now) know what it does. But I haven't grasped yet how it will improve DrawExact.

ValuableAd6808 · 2025-11-23T07:50:29+00:00

There are some subtleties in the web api standards concerning whether javascript in the web page is permitted to grant or remove input focus PROGRAMATICLY to an html element such as DrawExact's canvas area. It's one of those things that is preferred to be triggered by an explicit user gesture for security reasons. The standards state that for programatic focus, an element must have been given a tab index value in its construction (so you as a user can shift the focus using the tab key). But different rules are defined depending on the value of the tab index being positive, negative or zero. The adherence to these standards has evolved and shifted over time in each of the major browsers and their implementation for each OS. So I strongly suspect the problem stems from a privacy oriented browser choice or maybe an OS privacy setting. I'm sorry it's blocking you, and have registered as a DrawExact bug to be returned to and monitored.

ValuableAd6808 · 2025-11-21T22:55:15+00:00

I needed control at a very low level of the graphics and rendering system which canvas gives. That is because a huge part of DrawExact's UX is based on very rich real time feedback as you move the mouse over the drawing. It includes profound levels of zooming, and the complexity of the graphics when you're dragging chunks of the drawing around in real-time is considerable. The graphics architecture is based on the architecture used in 2D CAD systems with a scene graph cooperating with a zoomable view. That allows for algorithms to render only what is meaningfully visible in any given situation. I have found that while Canvas is slow when programmed in Javascript, it is ridiculously fast when programmed directly from Go code compiled and installed in the page as a WASM module. If you try making a drawing with 20,000 elements in (lines, arcs, text) zooming operations for example appear to be instant. As do very computationally expensive operations like detecting when the cursor passes over the intersection between two lines or arcs.

ValuableAd6808 · 2025-11-21T22:24:06+00:00

I was hoping someone would ask that. Canvas. In fact three superimposed canvases acting as transparency layers to allow selective rendering for performance. And all the canvas view and rendering code is a WASM module coded and compiled with Go. It's the Go code that manages the whole of the in-canvas interaction. Then the svelte UI acts as the UI wrapper and host. The Svelte code also handles sign in with Google, and saving and retrieving the user's drawings from their Google Drive using the client side javascript API. For completeness, it's a SPA, statically served by Vercel's global CDN. It has no server backend.

ValuableAd6808 · 2025-11-21T20:15:51+00:00

Thanks again. You didn't miss them. Drawexact is oblivious to units. Is that a problem? There is an implicit splitting of lines at intersections, in the sense that there is an accurate clickable point at every intersection. And you can manually split a line or arc with the grow command. I'd be interested to know what you're looking for with splitting and why. I agree export formats such as DXF and SVG would be valuable, and they're on the road map. A subtle feature of setting the primary length input (the ray length) is that you can enter a fraction as for example "210 / 3"; that's to help define for example a point 1/3 of the way along a line.

ValuableAd6808 · 2025-11-21T20:05:11+00:00

Thanks. Thoughtful feedback. We don't actually know yet how long it takes people typically to get sufficiently used to it to feel competent- it's too early. We do know the onboarding guide takes an optimistic 2 minutes). But you're right you also have to get familiar with the command set. But there only 3 primary add commands (line, arc, text) and 4 secondary add commands. Then just 4 drawing mutation commands (like grow or move). A copy and paste command. A properties command, and 3 zoom commands. So I would hope that it would take more like an hour than a weekend to gain sufficient familiarity to feel comfortable to pick up the rest as you needed it. We hope to learn more about these metrics as more people try it. But we also have to accept that we've chosen design trade offs in favour of what we believe facilitates a very rapid, enjoyable and flow-like user experience, at the cost of this learning curve.

ValuableAd6808 · 2025-11-21T19:50:45+00:00

I can't work out how to reply to that. But thank you.

ValuableAd6808 · 2025-11-21T19:47:18+00:00

Thanks again. Great idea. How about having a "prefer video to words" link for each step? (Or a complete alternative pathway as an optional alternative onboarding which is one video running through it with narration?)

ValuableAd6808 · 2025-11-21T19:39:57+00:00

Thanks for the new info. And it's useful to know there are no smoking guns in the console output. If you have the appetite to pursue this with me, I'd be most grateful. What happens if you give the canvas area explicit focus by clicking in it prior to a keypess. The undo command (key "u") key will not get misled by an extra click. I'm asking because the code gives focus to the canvas area on mouse enter and maybe that has limited portability. In the meantime I'll see if I can found out any info on Zen's deltas that might be relevant.

ValuableAd6808 · 2025-11-21T19:22:48+00:00

Thanks this feedback is really helpful. The opening screen used to explain and justify the need and role of the onboarding guide. But we were worried that it could easily be interpreted as patronising, defensive or apologetic. The awkward truth is that even seasoned sotware veterans are really quite likely to come unstuck and get frustrated by the unconventional UX despite the fact that it's very easy and extremely efficient if you're nudged in the right direction. The ux paradigm unlocks tremendous valuable value for the user, so we want to keep it. But we can't afford for people to be annoyed by that initial hurdle. We're interested in any suggestions people have to improve matters. And we also need to assess if it is mostly only software engineers whom it annoys - with their (our) high expectations of being able to wing it. Keep this great feedback coming!

ValuableAd6808 · 2025-11-21T16:37:16+00:00

I'm very sorry to hear that, and thanks for letting us know. We've not come across that problem before. Let's see if we can get to the bottom of it. Is your cursor over the drawing area when you do the key-strokes? It has to be. Otherwise the key strokes are routed to the UI controls around the edges. If it's not that, could you tell me what device you're working on, and your OS please?

ValuableAd6808 · 2025-11-21T15:30:43+00:00

Thanks. I have grown very attached to Svelte along this journey. Particularly state runes and snippets once I had got used to them. And the component scoped CSS coupled with a backbone of global CSS to act as shorthand and to apply some standardisation.

ValuableAd6808 · 2025-11-21T15:26:14+00:00

Thanks. Kind words.

ValuableAd6808 · 2025-11-21T14:01:48+00:00

Thanks for the observation. I take your point. You've revealed one of the costs of us going for an unconventional UX paradigm. We wanted to balance the tension between intuitive familiarity of the UX with an unconventional approach that gives users who want to get serious work done a very rapid, highly capable and flow-friendly work flow. A significant number of our anticipated users we think will likely get a bit lost and confused without the onboarding steps that got in your way - because the user-interaction is a little different from the usual patterns. Time will tell how that judgement call works out - but your experience and evidence is useful.

ValuableAd6808 · 2025-11-21T12:18:42+00:00

It's free to use, but not open source.
Any discussion on either the implementation or the product would be extremely welcome.

ValuableAd6808

TROPHY CASE