{"payload":{"feedbackUrl":"https://github.com/orgs/community/discussions/53140","repo":{"id":681766481,"defaultBranch":"main","name":"gramble","ownerLogin":"nrc-cnrc","currentUserCanPush":false,"isFork":false,"isEmpty":false,"createdAt":"2023-08-22T18:00:42.000Z","ownerAvatar":"https://avatars.githubusercontent.com/u/2914613?v=4","public":true,"private":false,"isOrgOwned":true},"refInfo":{"name":"","listCacheKey":"v0:1723669844.0","currentOid":""},"activityList":{"items":[{"before":"7cde0208d3da0db6a61d92602f61b7ff2669f59c","after":"05dc4b7fb2fcbda9e85ba5f5fbf2a9d0a9739c86","ref":"refs/heads/main","pushedAt":"2024-08-15T14:32:18.000Z","pushType":"push","commitsCount":4,"pusher":{"login":"littell","name":"Pat Littell","path":"/littell","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/5376533?s=80&v=4"},"commit":{"message":"Cleanup from previous commits\n\nI had left a lot of console logging and similar changes in the previous commit, because I wanted to get the solution committed before changing anything further.  This cleans that up.","shortMessageHtmlLink":"Cleanup from previous commits"}},{"before":"44ab05526587a191b1a827ef4a482c4661fdaa23","after":"05dc4b7fb2fcbda9e85ba5f5fbf2a9d0a9739c86","ref":"refs/heads/tapeStalling","pushedAt":"2024-08-15T14:31:25.000Z","pushType":"push","commitsCount":2,"pusher":{"login":"littell","name":"Pat Littell","path":"/littell","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/5376533?s=80&v=4"},"commit":{"message":"Cleanup from previous commits\n\nI had left a lot of console logging and similar changes in the previous commit, because I wanted to get the solution committed before changing anything further.  This cleans that up.","shortMessageHtmlLink":"Cleanup from previous commits"}},{"before":"e496beca18e70ef9d25365b11cf11c8269288248","after":"44ab05526587a191b1a827ef4a482c4661fdaa23","ref":"refs/heads/tapeStalling","pushedAt":"2024-08-14T21:25:46.000Z","pushType":"push","commitsCount":2,"pusher":{"login":"littell","name":"Pat Littell","path":"/littell","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/5376533?s=80&v=4"},"commit":{"message":"Merge branch 'main' into tapeStalling","shortMessageHtmlLink":"Merge branch 'main' into tapeStalling"}},{"before":"ee1d7ca3b34ee45ddfbe5e7ad3b252ef4bb4b855","after":"7cde0208d3da0db6a61d92602f61b7ff2669f59c","ref":"refs/heads/main","pushedAt":"2024-08-14T21:25:14.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"littell","name":"Pat Littell","path":"/littell","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/5376533?s=80&v=4"},"commit":{"message":"Fix to testHasVocab and default symbols\n\nWhen the new implementation of testHasVocab was called with \"\" as its symbol, it was failing because it couldn't find any symbol by that name in interpreter.grammar.symbols.  (That symbol is actually named \"Default\".)  So this commit fixes that by replacing \"\" with \"Default\" in that situation.\n\nFor some reason these tests (and some others) weren't failing when I was running tests yesterday.  I'm thinking maybe I wasn't reloading -- that would cause THESE failed tests not to display in the interface, although it doesn't explain all the missing failed tests... In any case, now everything's passing.","shortMessageHtmlLink":"Fix to testHasVocab and default symbols"}},{"before":null,"after":"e496beca18e70ef9d25365b11cf11c8269288248","ref":"refs/heads/tapeStalling","pushedAt":"2024-08-14T21:10:44.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"littell","name":"Pat Littell","path":"/littell","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/5376533?s=80&v=4"},"commit":{"message":"Investigating reasons for tapecalc stalling\n\nDelaney's large grammar is stalling during loading, so I added some console logs to see what's up.  (Turns out you CAN view the logs from Google's servers, they're in the project space under Executions.)\n\nIt's a bit hard to debug this way (seems like Google occasionally loses log lines), but the problem seems to be during tapecalc, probably during getTapesQualified, and within that the getTapesDefault stage at the end.  This stage is, I think, ultimately semantically unnecessary, but if I remember correctly a few of our tests fail if you don't do this.  I'm going to dig into what's up with those tests next (maybe those tests are wrong or testing something inappropriate).\n\nBut for now, some other tests have failed, so I'm committing what I have and going back to main to see when exactly things started failing.","shortMessageHtmlLink":"Investigating reasons for tapecalc stalling"}},{"before":"4847903f566902d30192854c54da5ff8b9bc0444","after":"ee1d7ca3b34ee45ddfbe5e7ad3b252ef4bb4b855","ref":"refs/heads/main","pushedAt":"2024-08-14T21:01:14.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"littell","name":"Pat Littell","path":"/littell","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/5376533?s=80&v=4"},"commit":{"message":"Additional/fixed source tests","shortMessageHtmlLink":"Additional/fixed source tests"}},{"before":"5153da877d30b33a85d66d3186a6ab7071e6f37f","after":"4847903f566902d30192854c54da5ff8b9bc0444","ref":"refs/heads/main","pushedAt":"2024-08-13T21:03:12.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"littell","name":"Pat Littell","path":"/littell","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/5376533?s=80&v=4"},"commit":{"message":"Sorting tape names in interfaces\n\nNow when you call Interface.getTapeNames(), it returns them in sorted order (ascending, case-insensitive).  And since both the Sheets add-on and the CLI call this function, they'll be in the same order in both places.\n\nAlso fixed a miniscule \"bug\": the highlight color of tapes depended on the capitalization of the tape name, which means that if the programmer is inconsistent about tape capitalization (which they're allowed to be, tape names are not case-sensitive), the same tape could receieve different colors in different places.  Now the highlight color depends on the lowercased tape name.","shortMessageHtmlLink":"Sorting tape names in interfaces"}},{"before":"66b2a676fa13eebe1ad0d98a2409ddb2dc46dfa8","after":"5153da877d30b33a85d66d3186a6ab7071e6f37f","ref":"refs/heads/main","pushedAt":"2024-08-13T20:48:57.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"littell","name":"Pat Littell","path":"/littell","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/5376533?s=80&v=4"},"commit":{"message":"Separating CollectionGrammars further\n\nThe old CollectionGrammar had a complex lifecycle:\n\n    (a) Starts out as a potentially-nested hierarchy of itself\n    (b) Then is flattened into a non-nested collection where all symbols have fully-qualified names\n    (c) Finally, we select one symbol from it to be the \"meaning\" of the grammar as a whole.\n\nThe last commit split off (c) into SelectionGrammar; this commit splits off (a) and (b) into CollectionGrammar and QualifiedGrammar respectively.\n\nAgain this doesn't accomplish THAT much but it forces us to be specific about what this thing is and what's been done to it; if we're loosy-goosy about whether it's been flattened or selected we'll get type errors.  I think it helped me catch some tiny issues that might have been bugs or could become bugs later.\n\nThe trickiest bit here was reconciling this with how testHasVocab works, since that's patching a specific symbol within a collection.  For unclear reasons, splitting (a) and (b) caused several vocab tests to break in strange ways on nested collections -- I actually can't quite work out how these tests WEREN'T failing before, because it seems some of them would have been looking up fully-qualified names before flattening had occurred.\n\nIn any case, to get around this, we can flip the order of the symbol-patching and calling prepareInterpreter.  prepareInterpreter calls Interpreter.fromGrammar here, and that already has the mechanism to handle the three possible forms of grammars in testHasVocab (bare, Collection, and Dict<Grammar>) and also qualifies names as part of the process.  Then we can reach into the Interpreter and patch the relevant symbol.","shortMessageHtmlLink":"Separating CollectionGrammars further"}},{"before":"d6a652eec7f177a86f79088d7b9cd0a8c38e37bf","after":"66b2a676fa13eebe1ad0d98a2409ddb2dc46dfa8","ref":"refs/heads/main","pushedAt":"2024-08-12T23:13:54.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"littell","name":"Pat Littell","path":"/littell","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/5376533?s=80&v=4"},"commit":{"message":"Refactorings of symbols/names\n\nA bunch of small refactorings of how names are qualified and how clients request tapes, just to shore things up before changing .getTapeNames.\n\n(1) The tape name testing wasn't using Interpreter.getTapeNames; instead it was replicating this functionality by calling Interpreter.getSymbol and doing roughly the same things that Interpreter.getTapeNames did.  Now it uses Interpreter.getTapeNames.\n\n(2) Interpreter.getTapeNames then became the only place Interpreter.getSymbol is ever used, but Interpreter.getSymbol's functionality is now redundant as well.  Selecting a symbol and looking at its .tapeNames does the exact same sequence of operations.\n\n(3) SelectSymbol (and a few other places) call a method .getSymbol on CollectionGrammar/SelectionGrammar, but all this actually was was a case-insensitive dict lookup, so I factored this out into a util function.\n\n(4) Moved the SymbolQualifier type into Grammars to avoid some recursive imports, and grammarToQualifier into flattenCollections (because that's the only place it's used).\n\n(5) Some other small rearrangements of code for clarity.","shortMessageHtmlLink":"Refactorings of symbols/names"}},{"before":"902b693487837df3cc463402d62e5a51294baf75","after":"d6a652eec7f177a86f79088d7b9cd0a8c38e37bf","ref":"refs/heads/main","pushedAt":"2024-08-09T00:28:56.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"littell","name":"Pat Littell","path":"/littell","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/5376533?s=80&v=4"},"commit":{"message":"Separating out Collection and Selection\n\nOur old CollectionGrammar actually had a pretty complex lifecycle\n\n    (a) starting out as a semantics-less container for assignments,\n    (b) then being a flat structure (but retaining the logical structure of (a) for later name qualification)\n    (c) same as (b) except with one symbol selected to be the semantics of the whole project\n\nThis commit separates out (a/b) and (c) into two different objects.  The former is still called CollectionGrammar, but the latter is now a SelectionGrammar.\n\nThey're still similar grammars in most respects and I'm not sure this refactoring was worth it, but it *did* force me to address a bit of sloppiness.  E.g. there was one situation remaining where we used a CollectionGrammar *without* specifying any symbol, and that's when running tests; now that a SelectionGrammar is the only valid thing to execute from, we have to choose an appropriate symbol (in this case, ALL).","shortMessageHtmlLink":"Separating out Collection and Selection"}},{"before":"9ee550de6beb80917774a48633afcf61c7730e5b","after":"902b693487837df3cc463402d62e5a51294baf75","ref":"refs/heads/main","pushedAt":"2024-08-08T23:39:13.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"littell","name":"Pat Littell","path":"/littell","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/5376533?s=80&v=4"},"commit":{"message":"Small refactorings","shortMessageHtmlLink":"Small refactorings"}},{"before":"88ab6e1ed8fcd889c80e6af5b0f9bd8522d3f483","after":"9ee550de6beb80917774a48633afcf61c7730e5b","ref":"refs/heads/main","pushedAt":"2024-08-07T00:26:48.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"littell","name":"Pat Littell","path":"/littell","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/5376533?s=80&v=4"},"commit":{"message":"Fixing SingleTape bug\n\nWhen fixing the serious oversight Haokun found -- that programmers couldn't invoke a regex like `{VOWEL}n`, I introduced another bug.  It only affected erroneously-programmed grammars, so far as I can reckon, but even so it pointed to something being subtly incorrect in our semantics.\n\nI had said in a recent commit that we had incorrectly left a check in calculateTapes -- the check that the children of a SingleTape only had one tape.  We can't do that check/fix until handleSingleTapes happens, or else it forbids reasonable regexes like `{VOWEL}n`.  So I got rid of that check and moved it later to handleSingleTapes.\n\nBut it wasn't an incorrect check after all!  It turns out handleSingleTapes is too late to fix that, because the fix can change the tape structure of the whole grammar, and handleSingleTapes can only fix up tape problems in the scope of a SingleTape.  This caused a few of our tests to fail (some erroneous grammars got fixed up in incorrect ways).\n\nSo we can't do handleSingleTapes after calculateTapes.  However, in a chicken-and-egg problem, we also couldn't do handleSingleTapes BEFORE calculateTapes, because handleSingleTapes needed to make a Rename, and to do that it needs to know what tape to rename from.  But Embeds don't have that information until calculateTapes.\n\nBut I also didn't want to combine them into a single pass -- calculateTapes is already complex enough.\n\nSo I rewrote how handleSingleTapes and calculateTapes divided responsibility for handling SingleTape+Embeds.\n\n  (1) handleSingleTapes is only responsible for changing the scope of the SingleTape.  This whole sequence of bugs came down to the fact that SingleTapes scope over potentially complex grammars, but they don't actually mean \"My child grammar only has one tape\" (that would exclude {VOWEL}n), they mean \"My child grammar is composed only of single-tape terminals.\"  So this pass eliminates the original SingleTapeGrammar, and \"pushes\" it further into the tree to the level of those terminals, so that it scopes tightly around the rather than around the whole sub-grammar.\n\n    (1b) Actually, we just handle SingleTape(Literal) and SingleTape(Dot) right here, there's no reason to wait when they're literal tape names.  We really only put the new SingleTape around Embeds; that's the only one where we have to wait for future information.\n\n  (2) The actual checking for single-tape status, fixing-if-erroneous, and tape renaming now happens in calculateTapes.  Unlike previously, though, this check is now happening at the appropriate scope.  Instead of checking the whole of `SingleTape({VOWEL}n)` and rejecting it, we're only checking SingleTape({VOWEL}).","shortMessageHtmlLink":"Fixing SingleTape bug"}},{"before":"cc55a810a2eec58d8921d7be633c89b62979fb83","after":"88ab6e1ed8fcd889c80e6af5b0f9bd8522d3f483","ref":"refs/heads/main","pushedAt":"2024-08-06T22:31:11.000Z","pushType":"push","commitsCount":4,"pusher":{"login":"littell","name":"Pat Littell","path":"/littell","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/5376533?s=80&v=4"},"commit":{"message":"Perfomance tests for parsing","shortMessageHtmlLink":"Perfomance tests for parsing"}},{"before":"a9c5b63bfa0f0c4d191a9129440f95fc9df56e72","after":"88ab6e1ed8fcd889c80e6af5b0f9bd8522d3f483","ref":"refs/heads/greedyCursor","pushedAt":"2024-07-30T16:53:07.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"littell","name":"Pat Littell","path":"/littell","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/5376533?s=80&v=4"},"commit":{"message":"Perfomance tests for parsing","shortMessageHtmlLink":"Perfomance tests for parsing"}},{"before":"bc36394a6895844fb0ca7c3bf8c11cbe2405a079","after":"a9c5b63bfa0f0c4d191a9129440f95fc9df56e72","ref":"refs/heads/greedyCursor","pushedAt":"2024-07-29T21:13:32.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"littell","name":"Pat Littell","path":"/littell","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/5376533?s=80&v=4"},"commit":{"message":"Adding/adjusting tests\n\n(1) Added a few tests to observe the behavior of cursors vs. greedy cursors when joining to replace blocks.\n\n(2) Commented out the inverse-priority tests in testGrammarCorrespond and testGrammarReplaceEpsilon -- they're not just getting the wrong results, they cause evaluation to hang (because of the disagreement-about-finishing mentioned in the previous commit).\n\nIt's possible to test for this situation, like a mature greediness solution would simply say \"Okay, given that this is my child, I can't be greedy\", but for now I just want to see if this helps the efficiency problems.","shortMessageHtmlLink":"Adding/adjusting tests"}},{"before":"494ab91d8105fb766e337bd489f80c46b3fcf303","after":"bc36394a6895844fb0ca7c3bf8c11cbe2405a079","ref":"refs/heads/greedyCursor","pushedAt":"2024-07-29T20:41:58.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"littell","name":"Pat Littell","path":"/littell","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/5376533?s=80&v=4"},"commit":{"message":"First attempt at greedy cursors\n\nSeveral programmers have a problem with inefficient text parsing (e.g. querying {text: ninapenda} and getting back {tense: pres, subj:1sg, root:pend}).\n\nI think part of this issue is that the breadth-first tape \"search\" -- where we make a single query to EACH tape rather than keep making queries to the same tape -- requires the sampling processs to make decisions about the other tapes too early.  For example, consider \"ninapenda\" above -- we decide what the root is on the first \"loop\" through the tapes, but only confirm that once we get to \"p\".  If it happens that we're right about the loop, great.  If it happens we're wrong, we've got to back up all the way to the point we made that decision!\n\nA greedy Cursor -- depth-first on the text tape -- wouldn't have this problem.  We don't necessarily want to do EVERY tape like this, but when we can know that the tape isn't going to behave pathologically in the depth-first case, it should be possible.  Queries entered by the user can't exhibit pathological behavior -- they're literals -- and so joins of them should also be non-pathological.\n\nThis commit introduces a GreedyCursor.  It's quite simple: unlike a normal cursor, GreedyCursorExpr never calls forward on its child, it just does deltas/derivs on its own tape until it becomes a FinishedExpr, in which case it finally does call forward on its child.  (That's all a FinishedExpr does, after all.)\n\nThis commit puts GreedyCursors on all finite tapes (which is a rough approximation of non-pathological tapes... I hope).  I'll probably refine this later.\n\nThere are still a few snags, like this is fundamentally incompatible with evaluating a Correspond in the unexpected order.  (The GreedyCursor says \"I can't query on t2 until I'm finished with t1\", and the Correspond says \"You can't finish with t1 until you're finished with t2!\")  I'll think about that later, though; for now I want to commit what I have.","shortMessageHtmlLink":"First attempt at greedy cursors"}},{"before":null,"after":"494ab91d8105fb766e337bd489f80c46b3fcf303","ref":"refs/heads/greedyCursor","pushedAt":"2024-07-29T18:38:20.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"littell","name":"Pat Littell","path":"/littell","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/5376533?s=80&v=4"},"commit":{"message":"Factoring out finished Cursor into own Expr\n\nPerformance issues in the parse direction are suggesting to me that we need to experiment with a slightly different formulation of Cursor -- e.g. one that greedily consumes as many characters as it can -- and that we might have multiple kinds in the grammar depending on the execution plan.  (We already kinda have this with PreTape in any case.)\n\nBut before I get to that, I wanted to do a refactoring we had long considered: rather than having CursorExpr have a boolean member .finished and change its behavior based on that, to instead separate out that behavior into a FinishedExpr.  That behavior's not going to differ between different kinds of cursors, so they can all just become FinishedExprs when they're finished.","shortMessageHtmlLink":"Factoring out finished Cursor into own Expr"}},{"before":"322761e03f569092bdcae38e7ef03b3caa9e5cb7","after":"70e60dd529e9c52c7219be2f7d16ade5076fbee4","ref":"refs/heads/parallelReplace","pushedAt":"2024-07-23T19:29:34.000Z","pushType":"push","commitsCount":19,"pusher":{"login":"littell","name":"Pat Littell","path":"/littell","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/5376533?s=80&v=4"},"commit":{"message":"Merge branch 'main' into parallelReplace","shortMessageHtmlLink":"Merge branch 'main' into parallelReplace"}},{"before":"4403e02e867a61cfc1ef99259a4a2c1102918d22","after":"cc55a810a2eec58d8921d7be633c89b62979fb83","ref":"refs/heads/main","pushedAt":"2024-07-23T18:26:40.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"DarleneStewart","name":"Darlene Stewart","path":"/DarleneStewart","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/28654058?s=80&v=4"},"commit":{"message":"Corrected \"@gramble/interpreter\" imports in tests suites to \"../../interpreter\".","shortMessageHtmlLink":"Corrected \"@gramble/interpreter\" imports in tests suites to \"../../in…"}},{"before":"3e2fbebc06fd2f0382621fd2487981e9a09f11df","after":"4403e02e867a61cfc1ef99259a4a2c1102918d22","ref":"refs/heads/main","pushedAt":"2024-07-23T16:54:07.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"DarleneStewart","name":"Darlene Stewart","path":"/DarleneStewart","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/28654058?s=80&v=4"},"commit":{"message":"Added replace tests with negative context or with nullable context.\n\nTests with negative context are in a new file, testGrammarReplaceNegContext\n(48 tests in all: 1a-14b).\n\nTests with context that is nullable were added to testGrammarReplace (12 tests\nin all: 28a-30d).","shortMessageHtmlLink":"Added replace tests with negative context or with nullable context."}},{"before":"a9ccb102f091f0fb22edec442c33a206f5789dd2","after":"3e2fbebc06fd2f0382621fd2487981e9a09f11df","ref":"refs/heads/main","pushedAt":"2024-07-17T21:07:03.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"littell","name":"Pat Littell","path":"/littell","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/5376533?s=80&v=4"},"commit":{"message":"Documentation of symbols and single-sheets in CLI\n\nEven if single-sheeting had worked, we weren't sufficiently clear on how to use it from the command line -- we didn't really explain even how --symbol/-s options should look in the first place.  So I added some more prose and some concrete examples in the CLI readme.","shortMessageHtmlLink":"Documentation of symbols and single-sheets in CLI"}},{"before":"9da5b69ef230ab7ca808d3a8db4ebcd0326f0126","after":"a9ccb102f091f0fb22edec442c33a206f5789dd2","ref":"refs/heads/main","pushedAt":"2024-07-17T20:52:49.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"littell","name":"Pat Littell","path":"/littell","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/5376533?s=80&v=4"},"commit":{"message":"Fixes to single-sheet downloads\n\nThe single-sheet download capability hasn't been changed since we changed the assignment syntax!  (E.g. where `Verb:` became `Verb=`.)  Since assigning stuff to collections is basically what single-sheeting does, it wasn't managing to do anything it all!  So I've fixed that.\n\nAlso, we were assigning a \"Default\" symbol automatically, to refer to the main sheet, but this no longer works because of changes to how defaulting/All work.  So I changed this to an embed of <MainSheetName>.All.","shortMessageHtmlLink":"Fixes to single-sheet downloads"}},{"before":"42ee216e076a13664208fff5c0db46e5a762b7a0","after":"9da5b69ef230ab7ca808d3a8db4ebcd0326f0126","ref":"refs/heads/main","pushedAt":"2024-07-16T19:59:25.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"littell","name":"Pat Littell","path":"/littell","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/5376533?s=80&v=4"},"commit":{"message":"Tutorial on circumfixes\n\nThis is a frequently-asked question, so it deserves a little tutorial of its own.","shortMessageHtmlLink":"Tutorial on circumfixes"}},{"before":"4d7cc88ed1ee63a5d41038dcc45f1a4711308579","after":"42ee216e076a13664208fff5c0db46e5a762b7a0","ref":"refs/heads/main","pushedAt":"2024-07-09T20:31:20.000Z","pushType":"push","commitsCount":2,"pusher":{"login":"littell","name":"Pat Littell","path":"/littell","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/5376533?s=80&v=4"},"commit":{"message":"Tutorial for flat vs nested structure\n\nAdded another tutorial, illustrating how to do Swahili verbs in both styles.","shortMessageHtmlLink":"Tutorial for flat vs nested structure"}},{"before":"da3c575fce14d6368045d10a784ba29063c8f2a9","after":"4d7cc88ed1ee63a5d41038dcc45f1a4711308579","ref":"refs/heads/main","pushedAt":"2024-07-05T19:33:14.000Z","pushType":"push","commitsCount":3,"pusher":{"login":"littell","name":"Pat Littell","path":"/littell","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/5376533?s=80&v=4"},"commit":{"message":"More files for the previous commit\n\nNot sure why these didn't get committed with the last commit, but they belong to it.","shortMessageHtmlLink":"More files for the previous commit"}},{"before":"4dcbf97cc5669790342e00a666177531da024c61","after":"4d7cc88ed1ee63a5d41038dcc45f1a4711308579","ref":"refs/heads/singleTapeFix","pushedAt":"2024-07-05T19:32:25.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"littell","name":"Pat Littell","path":"/littell","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/5376533?s=80&v=4"},"commit":{"message":"More files for the previous commit\n\nNot sure why these didn't get committed with the last commit, but they belong to it.","shortMessageHtmlLink":"More files for the previous commit"}},{"before":"51b33cbc5bac1aec7367fd781deba9d1ce49a0c4","after":"4dcbf97cc5669790342e00a666177531da024c61","ref":"refs/heads/singleTapeFix","pushedAt":"2024-07-05T19:30:37.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"littell","name":"Pat Littell","path":"/littell","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/5376533?s=80&v=4"},"commit":{"message":"Fixing the alternation-singletape bug\n\nI should have checked the code more thoroughly before typing all that out last time -- what I said we needed to do was already done!  It turns out handleSingleTapes already worked that way.\n\nWhence the bug, then?  It was just an erroneous error check in tape-calc!  When rewriting tape-calc I just didn't foresee this edge case and put in a check that said \"If there's >1 tape in the child, throw an error.\"  I took this out, obviously, and everything worked.\n\nBut in the meantime I also made some changes.  Before this I hadn't thought too hard about what SingleTape means; I was testing for \"Does it work?\" rather than \"What does it mean?\" and so wasn't really testing its behavior thoroughly.  So:\n\n    * I added tests for various operations like seqs, alts, repeats, joins inside a SingleTape env.\n\n    * We treated Embeds and Lits/Dots differently.  Whatever tape Embeds had, we renamed that.  But we only renamed literals if they were on tape `$T`.  This was fine -- by the nature of the parser, SingleTapes should never encounter literals that aren't on that tape -- but it's actually a bit of a surprise when you're writing a grammar using convenience functions.  (\"Why is this working so differently than the should-be-equivalent version with embeds?\")  So now it will rename a literal no matter what the original tape was.\n\nAnyway I'm glad we had this bug because it made me think harder about what SingleTape means.  It's actually one of our stranger Grammars because SingleTape(G), where G denotes a language L, cannot be expressed as a function of L.  It actually changes the interpretation of the operators inside G.  We'll need to keep this in mind for proptesting, because otherwise meaning-preserving transformations to G won't be valid to perform inside SingleTape(G)!","shortMessageHtmlLink":"Fixing the alternation-singletape bug"}},{"before":null,"after":"51b33cbc5bac1aec7367fd781deba9d1ce49a0c4","ref":"refs/heads/singleTapeFix","pushedAt":"2024-07-05T17:17:40.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"littell","name":"Pat Littell","path":"/littell","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/5376533?s=80&v=4"},"commit":{"message":"Test for singletape alternation bug\n\nI added a test to illustrate the singletape alternation bug that Haokun found.  The issue is pretty simple although the fix raises some questions.\n\nBackground: SingleTape is basically a sort of Rename, just one that doesn't care what exactly the child's tape is named.  It says \"My child can only have one tape, and whatever that tape is, I'll rename it to my tapename.\"  This is a convenience feature for the programmer, especially for embeds.  The programmer can have a table like Vowels, and embed that in a regex like `{Vowels}`, without having to worry about what to name Vowels' single tape.  (After all, the programmer CAN'T name the tape the proper thing in the first place, it's `$i` internally.)  They can just name it `text` or whatever is convenient, and the singleTape handler pass will see this one tape and rename it to `$i`.\n\nHowever, what if we want a rule context that looks like this:\n\n    {Vowels}|n_\n\nThat seems like a completely reasonable thing to say -- give me a vowel or `n`.  But the referent of {Vowels} has one tape, let's say `text`, whereas `n` also has one tape but its name is `$T`.  So the alternation as a whole has TWO tapes, {text, $T}, and is thus invalid in this context.\n\nI had thought, much earlier, that the way SingleTape works is a bit hacky and we should probably have had the singleTape handler pass actually recurse through the tree and put a rename more tightly around the affected places.  E.g., instead of wrapping the whole grammar in a rename, put a Rename around each leaf like so:\n\n    Rename(text->$i,Embed(Vowels)) | Rename($T->$i,$T:n)\n\nThis example convinces me that we should do something like this.\n\nThis raises some questions about what we should be able to recurse through.  For example, we certainly want to allow something like this:\n\n    {Vowels}n_\n\nSo we should be able to recurse through SequenceGrammar, at least.\n\nOn the other hand, we don't want to recurse the singleTape handler all the way into the embedded symbols.  Our hypothesized recursive singleTape pass handler would effectively flatten any n-tape grammar into a 1-tape grammar, and this isn't what anyone would expect.","shortMessageHtmlLink":"Test for singletape alternation bug"}},{"before":"879306dcd9281a1d480169b11804fd82a8e6a764","after":"da3c575fce14d6368045d10a784ba29063c8f2a9","ref":"refs/heads/main","pushedAt":"2024-07-02T17:16:16.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"littell","name":"Pat Littell","path":"/littell","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/5376533?s=80&v=4"},"commit":{"message":"More tutorialization\n\nIncluding some tutorials that I forgot to save & commit last time.","shortMessageHtmlLink":"More tutorialization"}},{"before":"6cc236488dde1b7a983b5a257a1f035b8bf359a1","after":"879306dcd9281a1d480169b11804fd82a8e6a764","ref":"refs/heads/main","pushedAt":"2024-06-28T19:18:23.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"littell","name":"Pat Littell","path":"/littell","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/5376533?s=80&v=4"},"commit":{"message":"Tutorial sheets in the Add-on\n\nExpanded the tutorial somewhat, but we're still in the first few lessons.\n\nHowever, when working through the tutorial, the reader will be getting a lot of table-by-table explanation of things, in a way that's potentially difficult to copy/paste into the sheet for hands-on play.\n\nSo I've added a sub-menu to the Gramble menu that lets the user make a new sheet starting from the source code of one of the tutorial examples (e.g. go to Gramble -> Tutorial sheets -> Tutorial 1).  I think this will make using the tutorial a lot smoother, and also it gives additional examples to the programmer who dove right in without reading the tutorial.\n\nThis is still done manually, though -- there's nothing that makes sure the tutorial and these pages stay in sync, so we'll have to be careful to remember this.","shortMessageHtmlLink":"Tutorial sheets in the Add-on"}}],"hasNextPage":true,"hasPreviousPage":false,"activityType":"all","actor":null,"timePeriod":"all","sort":"DESC","perPage":30,"cursor":"djE6ks8AAAAEm0fnzAA","startCursor":null,"endCursor":null}},"title":"Activity · nrc-cnrc/gramble"}