Geoff the Medio wrote:Seems unnecessarily complicated to me... the existing parser could be used with some macros to accomplish the same thing.
That would be simplest, and accomplish
a lot of it, but it wouldn't do the same thing-- relying on macros would mean that if you wanted to add an extra in between two existing ones, you might have to renumber all the levels from that point on; i.e., you lose the flexible equivalency to floats.
Still, that simple implementation does have quite a bit of merit. For clarity/explicitness of the numbering scheme you could still put these macros into a separate file that gets included into shared_macros.txt or something. It seems to me that the more complex symbolic milestone label handling could always be added later if we want it enough; it would be pretty simple to do some automated processing of the content to do a one-time change of things like "priority = [[EARLY]]" to "priority = Early"
Vezzra wrote:Well, that approach wouldn't actually implement the "milestone" approach cami proposed... If I understand correctly, the "milestone" approach would implement a directed graph (is that the right term?), isn't that something different?
I reread that thread last night, and although it is a bit challenging to follow at times, I think you are right at least largely about his milestones, though the difference only really mattered for threading, it seems to me-- I think he was planning on building a DAG that would indicate things like "Milestone B requires A, Milestone C requires A, Milestone D requires B, Milestone E requires B and C" and then the processing would figure out that once it had done A it could start working on B and C in parallel, and then once B was done it could start on D even if C was not finished, and then once C was done it could start on E. To make the whole thing even more ambitious and challenging I think that we would not even directly set these milestones-- we would set some kind of symbolic priority along the lines of what BigJoe proposes above, and then cami's code would do some processing to build a dependency DAG to decide when it could safely *ignore* the priority ordering to process more things in parallel. And apparently that is as challenging as it sounds, and kept tripping him up, and then he ran out of time for us. I think that is why we didn't get this a year ago. At least, that's the take I got from it on my re-read.
So, I think that either of the symbolic label (indirectly numeric) priority or the more-directly numeric macro priority approaches would serve fine for the initial priority stage of cami's parallel effect processing framework, if he or anyone else wanted to try finishing it off. (The symbolic indirect one fits best, but the other could be converted quite easily.) In the meantime, without parallel effect execution, we simply have A is a prereq for B, which is a prereq for C, which is a prereq for D...., and we have no significant use for building a DAG at this time.
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0