2026/04/22
Jump to navigation
Jump to search
|
Wednesday, April 22, 2026 (#112)
|
|
References |
There are two reasons why I haven't been taking notes:
- Progress generally good and non-sticky: not a lot that needs documenting or sorting out
- 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.
Added notes from Signal here, later moved them to their own pages: 18 19 20 21
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]
->OSessionis 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?)
- The Schema object gets the dump-command object from