Drasil Team Meeting - Tuesday, Nov 4, 1:45 pm, ITB/112

[smiths]

Agenda

1. Blockers for @JoeZZG

• Define Standard Introduction Template for All Example SRSs #4409 Implemented the HGHC introduction template: added IntroTemplateParams with control parameters, implemented IntroSection.hs to use the template. If it works, I will apply it to all the examples.

3. Blockers for @B-rando1 - For Commented up some potential issues with GOOL #4404 I've been back at work trying to find the source of InternalGetSet. It's been very slow going, as the class and its methods have been moved and renamed multiple times. Yesterday I traced it back to the Finally Tagless GOOL #1435 PR, but before that the history seems to be in Brooks' fork, so I'll have to pick it up there. I feel like I'm losing sight of the big picture. Would it be better to switch my focus to Add LValues to Gool #4398 for a while? The path forward seems a bit clearer there, and it might even provide clues for the questions we're trying to answer.

• For Wiki Cleanup #4401, I've continued going through the pages. In Wiki: Discussion-Style Pages #4429 I highlighted a common pattern among some pages, where they summarize a discussion in a way that doesn't seem helpful to future contributors. I think we should reorganize them, either by rewriting them with future contributors in mind or by improving the clarity of who the intended audience is.

3. Blockers for @Xinlu-Y
   Fill chunk refs #4434: Concept and quantity chunks now automatically collect and expose their citation and dependency metadata, and the base chunk database has been reordered/de-duplicated so those entries register safely in dependency order. This let me knock down the missing-dependency errors one by one. However, the log diff still shows noise: basisConceptChunks injects mathcon, whose line and point definitions cite lineSource and pointSource, so the base DB seeds those citations for every case study even when none of the underlying math concepts are actually used.
4. Blockers for @sarrasoussia Type Checker Cannot Handle Vector Construction in ddENoRefs DataDefinitions #4411 : The problem was that when we created vectors like vect [x, y], the system thought they were just single numbers (scalars) instead of real vectors. Because of this, some parts of the double pendulum example didn’t pass the type checks and didn’t show up in the final generated documents.
   To fix it, I changed how the program understands vector types. Now it correctly looks at each part of the vector, makes sure all components match, and allows vectors with only some components written out, like [x, y] instead of needing every possible one. I also fixed how the “scale” operation works, so multiplying a number by a vector (like cScale (Number r) (vect [x, y])) is correctly accepted.
   After the fix, the double pendulum example works properly again, the missing data definitions (p_1 and p_2) are now included.

Regrets:

Virtual:

[B-rando1]

@smiths can you create this week's meeting? Thanks!

[smiths]

Thank you for the reminder @B-rando1. Issue is created (#4440).