2026/04/22

Wednesday, April 22, 2026 (#112)

Tuesday Wednesday Thursday posts: prev < this > next

References 2026/04/17 (← links)

There are two reasons why I haven't been taking notes:

1. Progress generally good and non-sticky: not a lot that needs documenting or sorting out
2. Wiki generally sluggish and often gives timeout instead of loading or saving pages, which makes documentation more of a hindrance than a help.

I'm resuming for now because I did finally run into something sticky, after getting really close to having usable local importing.

Notes from Signal

4/18

• I think I might have figured out a CLI way to do step-through debugging... crude, even if it works, but perhaps sufficient.
• YES. Shows location of current execution line, then waits for ENTER.
• I should be able to have it give me a lot more information than that; the trick is how to do it in a minimally-hard-coded kind of way...
• The trick, I think, is how to get the value of local variables from the execution context. Maybe the Reflection classes can do that...
• I don't see any obvious way to do it. There's also the possibility that if I run phpdbg from the command line, it might give me that information -- but the docs don't really make it clear.
• Kinda annoying that the Reflection classes will go from {code entity} to {filespec and line#}, but there's no way (as far as I can tell) to get any information about what's in a particular file, much less by line #.
• ...and phpdbg seems to execute in a web context (not CLI), and I don't see how to change that except by forcing it in code (which still leaves CLI arguments inaccessible).
• You *can* watch a variable in phpdbg-the-app, but there's no equivalent function in the library.

4/19

• Finally got the local schema-listing working again (message-parsing fixed, command-line-builder fixed), but still broken over ssh2 -- I *think* I was expecting that, but I don't remember why...
  • Something to do with Streams, I think.
  • <checks notes>
    • quite possibly related to EoS-detection...
• It seems to be important to pause execution in order to get any results back. 1/10 second was sufficient; 1/1000 second was not. I wonder if there's some "do background stuff" function I should be calling...
• Copilot 'splained it to me: there's a streams-function which basically turns the thread over to the I/O subsystem for a bit so it can process stuff.
• Now I just need to get exports working again, and I'll be back to the *original* rockface of "get imports working".
• ...and now I'm getting partial dumps from ssh2, which is something that has never been a problem before even though I was concerned about it, aggggghh.
• Solved, maybe? Suddenly feof() is working properly -- or I'm only using it in the contexts where it does work, or something...
• (Warning messages once again not displaying, but I'm just not gonna wade into that deathtrap again just now. It's *probably* a simple fix, but lemme get imports working, dagnabbit. ....unless there's a mysterious hangup and I need to know what the error was, I guess. 🙃)
• Memory-leak seems to be gone. Seems like a good omen...

4/20

• Today's fun code-problem is that the Updater is somehow trying to access a Buffer that has been closed, presumably meaning that it's the wrong Buffer (Gromit) and something isn't getting set or reset properly.
• Looks like something is creating a new Session (process) object instead of using the existing one (which is also necessary for other reasons, i.e. maintaining the executable's internal state).
• ...caused, apparently, by a redundant call that was the only way I could think of to get a thing started when it is a file (full of commands) instead of a string.
  • Okay. So I need a correct way to handle that.
• NTS: the Command-object *has* to be what creates the Session, because what the command executes is what *starts* the session (in proc, anyway, and therefore necessarily in the class-model).
• Currently (as of the last 20 minutes or so) dealing with a situation where the data *starts* getting written to the output stream, and then mysteriously stops. It makes my head get all slushy when I try to puzzle it out, but that's pretty much de rigeur (or perhaps de rigour mortis) these days 😵‍💫 .
• Oh, duhh -- is because the output stream got backed up, so zero bytes got written, but code misinterpreted that as an error. Ok. Onward...
• *Something* is working right, because it's actually creating some tables now!
• ...an' they gots data innem!
• Still erroring out at some point, tho.
• Timeout issue. ...and the screen updater seems to have gotten disconnected again. >.<
• Actually, no, updater is working -- it's just stopping because output is hanging. I bet I know what's happening: there's an error, which is closing the output stream, but it's not getting caught -- so code keeps trying to send to a dead stream.
• Huh, no! It's getting stuck *after* writing successfully.
• It's timing out even though stuff is being written to the screen...
• ...but also, the Updater isn't being called from inside the loop, so I'm just getting debugging output...
• The problem is that the Updater can't be accessed from there... or, at least, I don't *think* it can; guess I should double-check that.
• Actually, it's a class global, so yeah... and now the problem is that the Updater's Panel isn't getting initialized properly, and sorting *that* out means sorting out where it's declared and how it's accessed, which is looking like a Tomorrow Thing.

4/21

• 08:10 The Updater/Panel thing ended up being simpler than I thought (yay) but now I'm back to the "trying to access a buffer after it was closed" thing (boo).
• 08:15 ...even though I supposedly solved that 2 days ago. 😛
• 08:33 Ok. The "access" thing is just so I can check the content for EoS -- but if it's closed, then... I should be able to assume EoS = TRUE, or maybe just not do anything... I hate to resort to "try stuff and see what works", but I don't sufficiently {understand what's going on} to say "the right thing to do would be $X", so... FAFO seems the best option to start with.
• 08:37 ...and then we get stuck in a loop waiting for something... oh, wait: memory usage is going steadily downward. Apparently something got fully loaded into memory and is slowly being written to its intended destination?
  • ...and now there are *more* tables appearing in the imported schema...
• 08:48 Well.. *mostly* steadily decreasing; it jumps up and down a bit sporadically... seems to be happening more as we get closer to zero...
  • It's well on the way to populating the entire schema, though, so that's very encouraging.
• 09:16 ...but then after that one successful test, again nothing is getting written to the db again. (I did make some tweaks; there is experimenting to do.)
  • class cWhatAMessIveMade implements iDoNotUnderstandWhatIsGoingOn {}
• 09:28 Pretty sure this happened once, last year: import works partially ONCE, and then never again.
• 09:34 Okay, part of the problem may be that Beekeeper was lying to me.
• 09:35 After disconnecting and reconnecting the local db, I see stuff has been imported.
  • (1) I need better metrics in the onscreen update -- or, more specifically, metrics that are more task-specific -- because it's currently impossible to tell how far along it is; (2) seems to get stuck after it finishes importing (probably EoS-detection rearing its ugly head once again).

today

• 09:36 Yesterday I started a small restructuring in order to couple the Updater-object to the Command-object, so that the displayed information could be more appropriate for the operation (e.g. there are different things you want to look at when exporting than when importing), but I didn't get to finish it before it was Costco time and when I got back to working on it my brain was all fuzzy and I probably didn't do it right/completely and now the code is demanding access to a Session object which hasn't been set yet and I'm trying to sort out what's going on with that.
  • A Command sent to a Starter will create a Session, so that's simple enough (Starter will give the Commmand a pointer).
  • A Command sent to a Session should just get a copy of that Session -- also simple. What's the problem.
  • (Apparently this was not how I was doing things; changes made. To be tested...)
• 12:24 ...and now we're back to the problem of the Panel's OnLoop event being called before OnBefore gets called.
• 12:50 schema-list retrieval working again, yay!
• 14:29 Model modification: The Dump Starter class needs an Updater class, which sorta breaks the idea that "only Session classes need Updater classes". ...but the Main Starter does not, so I need to handle the possibility of there being an Updater for the Starter while gracefully moving along if there isn't one.
• 16:55 First schema seems to dump properly, but remainder are zero bytes. This seems to be because the process is not being restarted for each new schema. The process which needs modification is complicated...
  • The Schema object gets the dump-command object from $this->OEngine()->OServer()->DumpCommand() (and then sets the schema-name string).
  • DumpCommand() only makes a new Command-object if there isn't already one (which, after the first schema is dumped, there is).
  • The recycled Command will still have the Session object from last time, and won't automatically start running its executable.
  • We need a command to force-[re]start the executable.
    • Probably the best way to do this is to explicitly set it as stopped, and then have it re-run itself at some appropriate point if it's stopped.
    • ...but we're already doing this: the Schema code calls [Command]->OSessionZap() after finishing the dump. Why isn't that causing the Session to be restarted?
      • OSessionZap() unsets Command's copy of the Session object.
      • ...except, aha!, it was unsetting it the old way which we're not using anymore -- so nothing was happening.
      • Fixed, but no actual change in behavior... where does the Session get created the first time?
        • FromStartCmd() is called...
        • ...by [Starter]->StartSession()...
        • ...in NewSession()...
        • ...which is called when [Starter]->OSession is NULL, except that I typoed it as OSesssion (why didn't that generate an error??)
        • Fixing the spelling fixed the exports, whoo! (Me on Discord: «I am Officially Annoyed by the fact that PHP doesn't give an error when I attempt to read a nonexistent (missspellled) member-variable.»)
          • Weirdly, the ~40kb memory-leak is back. Maybe it never really went away, but was just obscured by other larger variations in memory-usage.
          • Two caveats: (1) only works for local, not ssh2; (2) updater still does not show current progress (hopefully this bit, at least, is trivial-ish to fix?)