I use openscad vibe coding quite a bit. It tends to fall down beyond extremely simple examples, though. Error categories I've encountered if you want to build better rails: (1) forgetting axis orientations after multiple layers of rotate() (2) center=true presence ignored resulting in mistaken geometry (3) inconsistent naming (4) insufficiently verbose naming (5) 3D printing tolerances (6) lack of validation (7) shared faces causing rendering issues
I would suggest that every stage has the following basic checks: (A) If it's a 'substract' type operation, ensure the resulting shape has less volume than the original shape (B) Ensure no 'subtract' results in zero volume shape (C) Ensure no 'shared faces' exist (D) Ensure output is consistent with requisite axes (eg. render an elevation in orthographic and know which way is up/down in profile so that relative terms can be quantitatively verified in the rendering) (E) Name everything with a semantic tree that is updated properly instead of hacked upon until it becomes illogical and incoherent
This would go a huge way to fixing the main issues encountered so far.
Cool, can you provide some more info on how you got in to this, recommended dabbling strategy and what sort of ROI you're getting from time invested? I have been getting in to botany pretty heavily already.
I've always had a passion for carnivorous plants and it was inevitable that I would end up doing tissue culture by keeping on digging deeper in the obsession.
The biggest ROI is fulfilling my childhood dream of having a ton of my favourites rare plants. Then I sell my extra ones on my webshop, but it doesn't make that much money as I am not focusing on expensive varieties, just the ones I like.
You can check out plants in jars on YouTube, or use a LLM to get into it. Some LLMs might not want to answer you because they think you're trying to do something dangerous... Claude has been flagging a lot of my questions.
Ahh, succulents! Happened upon a succulent show around 2 years ago. Wow. Never imagined how many oddball shapes were out there, it's a real scene. Some of those combo monstrosities belong in sci-fi! I can see how people get in to it.
Both of my parents have benefited from access to early medical trials. One is currently very late stage IV cancer. Access to trials is usually proxied through respected doctors/oncologists affiliated with major hospitals rather than offered broadly. I assume for reasons of experimental protocol and integrity the overseeing doctors are typically not the same as the conceiving research team.
Hehe. Optimization ... it's a good way to learn. Earlier in my career I did a lot of PHP. Usually close to bare.
Other than the obvious point that writing an enormous JSON file is a dubious goal in the first place (really), while PHP can be very fast this is probably faster to implement in shell with sed/grep, or ... almost certainly better ... by loading to sqlite then dumping out from there. Your optimization path then likely becomes index specification and processing, and after the initial load potentially query or instance parallelization.
The page confirms sqlite is available.
If the judges whinge and shell_exec() is unavailable as a path, as a more acceptable path that's whinge-tolerant, use PHP's sqlite feature then dump to JSON.
If I wanted to achieve this for some reason in reality, I'd have the file on a memory-backed blockstore before processing, which would yield further gains.
Frankly, this is not much of a programming problem, it's more a system problem, but it's not being specced as such. This shows, in my view, immaturity of conception of the real problem domain (likely IO bound). Right tool for the job.
Personally I use loose leaf A4 pages, colored pens (massively useful!) and a padfolio with magnetic clip. When a bunch of notes are done, I'll staple them together and file them. I date stuff exactly or approximately or thematically group it. Then they go in boxed document folders (my context is insane, I work on mechanical/electrical/software/patents/random projects at the same time). Periodically, like changing countries, I scan stuff, digitize it, shred and purge.
Closed notebooks barely work because unless you're working on something highly sequential you wind up with 100 notebooks each of which have 5-15 pages used and are mostly wasted.
Occasionally, dated notes can be critical in IP litigation.
While indeed an army marches on its stomach, it's easy to miss the fact that the entire field of operations research which now runs such modern marvels as international air transport and major data centers grew out of the field of logistics, which itself grew out of increasing complexity in once primitive military food logistics.
Funding for https://infinite-food.com/ - seeking $100M - now finalizing four strong patents in the non-military drone space. Had a couple of false start time wasting lawyers, but now it's home run time. We've got what seems to be a few simultaneous nice technical edges over the multibillion dollar investments in civilian aerial delivery of food from major early stage players to date. Can't wait to close, itching to get to market and start generating some proper California lunch money.
Simultaneously, working on some technical demonstration materials, including novel fabrication and supply chain, plus some reduced BOM strategies for greater efficiency in mass manufacturing (once we get cash over the line). Bit of electronics in there, some mechanical. Keeps me interested so it's not 100% admin.
Also getting back in to badminton, super fun, losing weight nicely, feeling better every week.
New ideas? AI government will have its day in our lifetime.
I'm currently going about it the other way, specifying custom magnetics to suppliers. Suffice it to say there are a lot more variables when you get in to manufactured designs, which may involve multiple coils, thermals, various component type options (SMD, THT), disparate wire types per coil, various footprint options, multiple core options, load modulation, etc.
I don't envy you at all. I'd ship a working prototype and say 'like this one' :) My ability to spec this would surely become an exercise in finding all of the ways in which I could mess it up.
Learning at industrial scale is sometimes temporally cheaper because it allows you to conclusively exhaust a design path through efficient and spectacularly memorable failure. ;)
For discrete designs rather than integrated chip design there are some less formal type systems already build in to KiCad, for example using net classes, footprint categories, and pin counts to limit parameter selection. I suspect other design tools are similar.
Strong type systems require zero exception domains, but unfortunately physics isn't a zero exception domain in the way software is: there's always an oddball requirement which has to cater to differences in supply chain, production process or partner, final assembly, testing, operating environment, etc.
In my experience what you tend to see emerge in thornier domains are multiple overlapping systems of relaxed formality that get the job done while retaining a comprehensibility through reduced cognitive load. That is, "useful approximations". In discrete design we can view the standard set of formalisms (symbols, footprints, netlists, etc.) as relaxed type system examples.
Each have issues. Each differ somewhat over time and package. Yet they are still how things are usually designed after decades of evolution, and I don't see that changing for manual discrete designs beyond relative triviality any time soon.
In fact, on zeitgeist I'd wager the problems people are seeing trying to march beyond the status quo in to AI designed schematics, board layouts and firmware are analogous to those issues your prospective type system is going to have problems exhaustively formalizing.
I have no experience designing custom silicon, the apparently intended domain here, but I am skeptical enough to wager it isn't free of the thorny problems we see in discrete electronics: that is, physics doesn't let you select arbitrarily without vengeance, so treating your system as a simple system of lego bricks (albeit 'guaranteed type-compatibile') is never going to yield reliable results. Specific decisions probably require multi-disciplinary insights across thermal models, EMI/radiation, timing and power, not just "the plug fits". Further complicating change is social friction and time friction. I'd wager the stronger designers are deeply invested in current tooling (hell, they probably wrote it) and not time-rich enough to try something new because "academia". Their projects are expensive and often set to difficult schedules.
Good luck changing the world! Perhaps building enhanced type systems specifically targeting the AI design domain would be the best approach, because uptake will be quicker than humans? Maybe consider joining one of the AI-designs-my-board startups.
I would suggest that every stage has the following basic checks: (A) If it's a 'substract' type operation, ensure the resulting shape has less volume than the original shape (B) Ensure no 'subtract' results in zero volume shape (C) Ensure no 'shared faces' exist (D) Ensure output is consistent with requisite axes (eg. render an elevation in orthographic and know which way is up/down in profile so that relative terms can be quantitatively verified in the rendering) (E) Name everything with a semantic tree that is updated properly instead of hacked upon until it becomes illogical and incoherent
This would go a huge way to fixing the main issues encountered so far.
reply