yeah MCP contains a provision for some blocktext for instructions. If your MCP has walls of text in those instructions, it will burn more tokens that a terse MCP.

I love the approach of this but "It has to not forget. A model that learns continually and overwrites itself is worse than one that does not learn at all."

Is highly misguided.

While the platonic ideal of Lt Commander Data is appealing, The parable of funes the memorious (Jorge Luis Borges) comes to mind.

The other problem with MCPs is that the harnesses don't auto-reconnect if you've enabled access. Connection status should be persistent

How do you think the LLM becomes aware of which mcps are available? Vibes?

It depends on the harness. But most use a tool_search tool.

yes and using that tool does what with tokens?

Chemiosmotic effect

What aspect of that is an unsolved problem, and one that feels more fundamental rather than engineering / in need of explanation ?

Its not unsolved. It's very solved. It was not an engineering question.

It seems that physics -> chemistry -> biology is a layering of abstractions and/or emergent phenomena, and any explanations of mechanics at these higher levels is more along the lines of "how was this built from these lego blocks" rather than being some more fundamental discovery.

You keep on making assertions - perhaps you could back it up with some explanation of why you regard this as a more fundamental discovery (or however you would like to characterize it)?

"how was this built from these lego blocks"

That is not engineering. Nobody would call astronomy or cosmology engineering and it is very much the study of "how the universe is built from some basic building blocks.

Don't assign a reductive meaning to engineering that is so encompassing that everything everywhere is engineering, else you render "engineering" a meaningless concept

These are almost all so stupid. Written by people who clearly don't know their chemistry

Reverse translatase and protein amplification in particular.

How the fuck do you plan on selectively priming protein amplification. If you know ANY protein chemistry, you will know "the juice is not worth the squeeze" -- how would I exponentially amplify a protein? I'd do mass spec proteomics, synthesize the DNA, and express it.

Simply amazing that electrofixation is not on the list.

Which ones are not stupid?

Cryopreservation, even though I don't care much for it.

The rubisco one is sort of not dumb, but if you actually care about carbon fixation you'd just not bother using rubisco at all instead.

Programmable Proteases is fine.

Somatic regeneration is fine.

I was going to comment to complain about those two as well!

Do you mean electrofixation of nitrogen? What level of biological involvement are you imagining? More like biology producing (some?) of the catalysts, or more like the entire reaction happening inside of cells?

Electrofixation of carbon. Build a bug with one of the alternate (non rubisco) pathways and pump electrons from the mains to turn CO2 into sugar

.map is definitely not low-level

> However, there's no global allocator in zig. You simply cannot call the language's equivalent of malloc() because it doesn't exist - at least not as a global symbol.

I mean std.heap.page_allocator is global, and there's only the one, and you can call it from wherever (just as you can malloc). Same with std.heap. c_allocator, which is... malloc! you can also create your own global allocator.

Don't do this in libraries ofc or the ghost of Andrew Kelly will haunt you in hour sleep.

Zig Comptime is softfloat