2026/04/01

From Woozle Writes Code
Jump to navigation Jump to search
Wednesday, April 1, 2026 (#91)
Tuesday Wednesday Thursday posts:prev <this> next

References

11:08

It turns out that MariaDB (which is what I'm using for local tests) has a subtle difference from MySQL in its behavior when interacted with headlessly (i.e. via process-pipes, no terminal) – a couple of subtle differences, actually, but only one of them was actually causing a problem. TLDR: you need to include an extra command-line option in order to get anything back before closing the process. (It took a long dialogue with Copilot[1] to figure this out.)

16:39

The current obstacle seems to be figuring out how to properly interrupt the I/O-checking loop. This has required some light restructuring of how the loop is managed.

Some future notes:

  • I think it probably makes sense in this context to have a single DoEvent() method which passes iEvent objects down the chain, instead of having multiple methods which each need to be chained.
    • I used this technique in the HTML-rendering stuff for VbzCart / Greenmine, years ago, and it got very complicated -- but I'm inclined to think that the reason it got so complicated is because it makes complexity easier to implement (i.e. the complexity was caused by something else, and the fact that this technique did not become an obstacle to that is evidence that it helps minimize technical debt in complex code-structures).
  • Right now, the output-checker just looks to make sure that we've received one or more a complete lines of text -- i.e. the string ends with a newline -- which is obviously not super-rigorous. I think what might be more rigorous is to send another SQL request, right after the first one, which would return text that would never appear in the data for the first one (e.g. line beginning with [TAB], maybe? [EOF] character? Two consecutive newlines?)

21:26

The design conflict:

  • The Updater is what calls CheckStream() so the Engine can look at the received data and determine if we can move on past the I/O loop.
  • The Updater needs to have OnIterate() called regularly, so the screen keeps updating while we wait for input and also to call CheckStream() when there is (or might be) new input.
  • When end-of-stream (EoS) is detected, we need to stop the I/O loop. This is done by calling the Session object's DoBreak().
  • The main loop was, apparently, happening inside Conveyer::ConveyCheck() which became a problem when we need the Session to be in control of it. That has now been fixed.
  • The loop is now exiting without ever calling CheckStream() -- so that's the current problem -- wait, it actually is calling it now...
  • ...and it's receiving the schema list, correctly detecting that it has been received, and calling Session::DoBreak().
  • So I guess now the problem is updating the parsing routine, since the list-format has changed slightly. Ok.

LLM thoughts

I was involved in a discussion[2] about whether LLMs are, in any sense, "thinking", "reasoning", "understanding", etc. I said that it would be wrong to say they are definitely not, but I agreed that they probably weren't doing it as fully or completely as humans can.

The question ended up, as many such things do, basically depending on the exact definition of "thinking". Others considered it significant that LLMs have an "inability to self-modify and [lack] an inherent moment-by-moment-interaction-by-interaction evolution" (where I'm pretty sure that by "self-modify" and "evolution" they meant something that persists outside the current session), which was apparently important to their definition of "thinking".

I think my own definition of "thinking" was clarified for me a bit by Copilot's answer[1] to this question:

The code we have now works for a different set of commands -- run proc_open() with "bash" and then send it "ls -al", and I get back the expected directory listing. When I run it with mysql as the executable, however, I get nothing back. I have MariaDB installed, so "mysql" is actually just an alias to that -- Is there any reason to think that MariaDB would be behaving differently here than MySQL would?

This certainly feels to me like "thinking": there are a lot of pieces in that question with which to build the mental model necessary in order to answer the question correctly, and it demonstrably did answer the question, as I meant it, correctly (so I guess I'd also add that it "understood" the question, too).

I think my default definition of "thinking" must then have more to do with "building a mental model and applying it to a desired goal" than with the question of whether the interaction has any persistent effects on the thinker. I can certainly "think" about something and "understand" it in the moment without being able to remember, later, what I thought or understood (or necessarily even remember the interaction). Does that mean I'm not thinking?

(I did catch it in one real mistake (some time after I saw what I thought was an error but which turned out to be me not reading the whole code-snippet): it forgot to include an argument to proc_get_status(). It admitted the mistake when I asked if that was correct.)

Footnotes

    1. 1.0 1.1 2026-03-30 - 04/01 Copilot dialogue: Using proc_open() to Interact with MySQL in PHP
    2. with other human beans (greetings, fellow humans!)