From 4bc3fc6022f5b7ba3150c7a677beb21d20635bc1 Mon Sep 17 00:00:00 2001 From: "Alex A. Naanou" Date: Mon, 12 Dec 2022 22:46:11 +0300 Subject: [PATCH] figured out one issue, not sure how to resole it yet (see notes) Signed-off-by: Alex A. Naanou --- pwiki/page.js | 3 +-- pwiki/parser.js | 6 ++++++ pwiki2.js | 20 ++++++++++++++++++++ 3 files changed, 27 insertions(+), 2 deletions(-) diff --git a/pwiki/page.js b/pwiki/page.js index 693c753..5e8536f 100755 --- a/pwiki/page.js +++ b/pwiki/page.js @@ -2198,8 +2198,7 @@ module.System = {

@source(./title/quote/!)

@include(.:$ARGS join="@source(file-separator)" recursive="") - - ` }, + ` }, // XXX add join... _raw: { text: '@quote(.)' }, diff --git a/pwiki/parser.js b/pwiki/parser.js index 5205de7..f2e3911 100755 --- a/pwiki/parser.js +++ b/pwiki/parser.js @@ -450,6 +450,12 @@ module.BaseParser = { ast : ast.iter() + // XXX this must execute sequentially for things that depend on + // lexical scope not to get lost in the mess... + // ...or it's a question of if we can maintain "slices" of + // state per macro call that is both containing all the state + // from previous macros, and is not affected by the changes + // done by next macros (unless needed)... return Promise.iter(ast, function(value){ // text block... diff --git a/pwiki2.js b/pwiki2.js index 3c68ddd..033d7c8 100755 --- a/pwiki2.js +++ b/pwiki2.js @@ -53,6 +53,26 @@ * .resolve(..) * .parse(..) * - not handling the return value correctly in one or more macros +* seems to be an issue with slots (content) not being filled... +* could this be an issue with sequencing, i.e. trying to fill +* the slot BEFORE it got a value??? +* ...but if this is the case, how could we have reached a point +* where we reached a point where something is needed after it +* is introduced but before it had a change to run??? +* (looks like the definition of what Promise.iter(..) is supposed +* to do -> we need a way to carefully wait for all the prior +* stuff to finish before filling slots) +* XXX this is an interesting question, we need to maintain +* the "illusion" lexical scope (i.e. code order) regardless +* of actual order of execution... +* ...this has to be done in both directions, i.e. we need to +* wait for what came before and what comes after must +* wait for us... +* ...one simple way out of this is to do a less general +* Promise.orderedIter(..) that will always execute in +* order... (seems the simplest, we'll try this first) +* ...this also feels a fundamental enough feature to +* be implemented in ig-types * XXX ASAP need to add error handling to .awaitOrRun(..) * ...might be even better to make it support the same interface as Promise... * XXX BUG: for some reason editing the root page ('/') hangs /tree...