Nice idea, but the interface needs some polishing:
- In general, you are exposing too much of the internal object model to the user. E. g. nodes added by the user and nodes added during reconciliation might be same class internally, but the user don't care much about the latter.
- "Reconciliation" looks like a sure way to confuse everyone (e. g. made an equilateral triangle, why are my joints not exactly the same? Forgot to reconcile one).
- A button for automatically merging all attachments at a node into a joint would be nice (but that might require keeping a track on what got reconciled where).
- Would be nice to automatically adjust length ratio and reconciled offset for shallow connection angles.
- You have to tweak visibility settings to be able to select nodes, virtual links and attachments, that's a bit ugly. Would be nice e. g. to be able to select a virtual link behind currently selected physical link, or a node out of a list of nodes on the current link. Especially when adding a connection in the middle of a link - you have to select the link, then hide physical links. Perhaps only allow selecting valid/semantically meaningful elements in this modes, and highlight them so that they aren't occluded?
- Any way to exploit symmetry? That's a bit advanced, but if we are making a regular tetrahedron it's quite a chore to repeat every operation four times every time you have to readjust it. That's particularly desirable because when you one physically manufacturing the design, one'd like to know which parts are interchangeable.
- Make automatically assigned names shorter (i. e. J1 instead of "Joint 1") so that you could put them as labels on prints.
Thank you very much for the perfect kind of feedback !
And Indeed, UI is messy/complicated stuff, the whole thing was very "easy" while more or less the same functionality lived just inside code scripts :)
1. Regarding nodes which are "automatically" created during reconciliation, they are just "regular" vlink relative nodes, and you can place them (and attach physical links to them) just by manual actions, without any reconciliation needed. But you are right that the naming is confusing it it would be probably better to just hide them by default
2. Yes, that functionality (automatically merging neighboring attachments into connection) is planned and can work on simple geometric distance + some link based heuristic. Even if not ideal, it would solve 90% of the case and spare a lot of manual editing, you can always repair/tweak cases where it got it "wrong"
3. Also a very good idea, basically reconciliation is now explicit "one-shot" action, while we could expose "auto-reconcilation" flag which would automatically reconcile joints after every edit (using reconcilation spec like order, pairwise preference, that's already exposed for each eligible joint and working very well). The only problem are cycles, eq there are situations where this would result in infinite reconcilation loop in some cases, but we could easily detect that and just flag such cases
4. For the visibility, the way I usually work with it is to use global visibility toggles for each entity type (nodes/vlinks/plinks/plink-attachment/vlink-attachment/attachment-connection), so even model in advanced stage (already full of physical links/attachments) I simple hide all physical links with single click when I add to plan some new link relative nodes.
Other option is to select the entity and then pick the attached one (like node on a link) from the right hand html menu -> but you are right it's only exposing terminal nodes. Selected link higlights are related nodes with outline pass, but you can't select them directly when attachments are in place, since they capture the click and you select the attachment instead...
5. Best way to make sure repeated things stays in sync is with built-in reactive properties, one reactive property (simple literal or expression) can drive parameters of eny entity in the system (like physical link radius, or some attachment param, attachments are open, you can design and import your own in built-in CSG modeller).
But I think your question is different, it's more about whether it's possible to exploit geometric symmetry and just repeat the same joint configuration N times -> that's a good question, it would probably require some scripting capability/DSL, not a bad idea
6. Finally some 5min fix, thanks for the recommendation !
Neurodivergency, or whatever you might call it, sucks, at least during childhood. Ten times so in a family-centered society. I had a mild enough case to grow up functional and independent, but if not for that… I totally see how one might chose a risky treatment even when fully informed. The problem here, it looks like the consent was nowhere informed enough, and the research team chose not to publish the case after it turned out a failure.
- The girl had a really rare genetic disorder, traceable to a single-base mutation, that result in intellectual disability. Her case was quite mild, she was verbal and only had a learning disability, other cases are often far more severe.
- They went for using adeno-associated virus as vector to deliver a CRISPR payload. It caused kidney and liver damage (AFAIUK due to immune response, not the virus itself? So hard to predict from an animal model.) which turned out fatal.
- The family paid a significant share of the research funding and some off-record financial favors to the research team.
- The research team's recent publication in Nature didn't mention the case at all (they basically chose keep silent about failures).
The whole story has quite some Flowers for Algernon vibes except real life is way more cynical and sad. And I disliked the book back when I read it because it felt like a weepie just for the sake of weeping.
> with the caveat that there is NO private pay option
I don't think there is a society in the world that ever had that successfully executed in practice. I live in Norway, and even if the public heath system is probably as good as it gets here, I often use private providers for non-urgent things simply because waiting time can be up to six month otherwise.
And even if you somehow manage this on paper, you'll be very surprised on how markets work. They don't need legal recognition. They don't even need money. See: USSR. Health care was public and medics weren't even a particularly attractive profession because there were too much of them already. Still if you wanted to survive an appointment you'd better have a package of some deficit wares ready.
What denies public healthcare money isn't "wealthy trying to cut public spending down". It's bureaucrats wanting their share of the pork barrel.
> Corolary: submarine datacenters are much better than orbital datacenters
Yea, except datacenters also need connectivity. And submarine connectivity, while not particularly expensive, is quite vulnerable - even more so than on land.
People outside the US have a significant lack of Internet functionality when there are problems with submarine cables, but it hardly ever fails. Apart from when certain countries sabotage things.
If you only need 100M deep water then you don't need to go far offshore, there are places where it's only about 1KM out. 12M of water is used for storing spent nuclear fuel assemblies and less than half of that is needed for protection so 5M should be adequate for stopping cosmic rays and that depth is common in harbours for recreational boating, such harbours shouldn't have issues of cable breakage.
But the real issue for comparing submarine and orbital computers is cooling. Space is cold but doesn't allow easy transmission of heat.
> I'm starting to get the feeling that there is something fundamentally broken in the RISC-V specification that fundamentally limits performance.
RISC-V is an objectively bad ISA design (a resell of MIPS dropping some of the most ominous features, then trying fix the code density issue with billions of extensions), but x86 is way worse and it didn't prevent Intel from making performant implementations. And RISC-V is certainly not bad in the way that would limit performance (well, maybe code density, but it's not the major issue).
The reality is, ISA matters very little for CPU performance. What really matters a lot is the memory subsystem and interconnect. I. e. good DRAM controllers IP are pricey - way more pricey than ARM cores AFAIK. Not a problem unique to RISC-V - i. e. Altera memory controllers used to be shit as well, not sure if Intel changed anything.
And another issue - there doesn't seem to be all that much money in CPUs any more. Look at ARM's history with high-performance sector.
Because all other 64-bits were designed with no regard to density too. On 32-bit (and thats where density matters) it's sill worse then Thumb even with compression extension.
- In general, you are exposing too much of the internal object model to the user. E. g. nodes added by the user and nodes added during reconciliation might be same class internally, but the user don't care much about the latter.
- "Reconciliation" looks like a sure way to confuse everyone (e. g. made an equilateral triangle, why are my joints not exactly the same? Forgot to reconcile one).
- A button for automatically merging all attachments at a node into a joint would be nice (but that might require keeping a track on what got reconciled where).
- Would be nice to automatically adjust length ratio and reconciled offset for shallow connection angles.
- You have to tweak visibility settings to be able to select nodes, virtual links and attachments, that's a bit ugly. Would be nice e. g. to be able to select a virtual link behind currently selected physical link, or a node out of a list of nodes on the current link. Especially when adding a connection in the middle of a link - you have to select the link, then hide physical links. Perhaps only allow selecting valid/semantically meaningful elements in this modes, and highlight them so that they aren't occluded?
- Any way to exploit symmetry? That's a bit advanced, but if we are making a regular tetrahedron it's quite a chore to repeat every operation four times every time you have to readjust it. That's particularly desirable because when you one physically manufacturing the design, one'd like to know which parts are interchangeable.
- Make automatically assigned names shorter (i. e. J1 instead of "Joint 1") so that you could put them as labels on prints.