I do think that there should only be at most one value because that might make some stuff a lot more elegant
- What one value would you want for referring to both a specific instruction and…
do you mean like "written down in code"? or am i misunderstanding?
No, you're correct. I'll update the docs to be more specific.
Technically, yes. However, since the edges directly below refer to the instruction IDs directly, I believe listing the IDs of the instructions explicitly is worth it, as otherwise one would keep…
u16 is quite small for a huge graph
The SocketIdx only refers to the sockets on one instruction. So one instruction could hold at most 2^16 - 1 = 65535 inputs and outputs each at…
The span is the ID. It allows the executor to refer back to the source in errors or warnings.
Personally I believe it's unlikely we'll have any kind of teams, rather just a few maintainers and contributors. In both cases, with or without teams, answering the same questions every single…
"ASAP" is definitely not necessary, lol. Do it anytime you want. And if you figure out that you don't, then we'll think of something else.
Hm. Thinking about it, Evaluation seems generic enough. I'll use that then.
They are not necessary. In fact, the whole file is not necessary.
However, it serves a different purpose: It tries to lend a helping hand to whatever contributor might come along, regardless of…
It does in some markdown viewers such as Obsidian or GitHub, but apparently not on Forgejo. I'll remove it then.
From @schrottkatze in #2:
This is why I proposed using lists, dictionaries etc. in #4, to make this easier/cleaner
We'd need a type system before we could implement this then.
Tbh then I'd rather completely remove the dots at the end, would that be fine, too?
(fwiw please don't merge if you happen to approve — need to rebase onto main first)
Fwiw for some reason the Conversation tab (this one) says that the broken commit is still contained in this PR. However, the Commits tab does not, which should be correct as I just force-pushed…