2026/04/23

From WoozleCodes
< 2026 | 04
Jump to navigation Jump to search
Thursday, April 23, 2026 (#113)
Wednesday Thursday Friday posts:prev <this> next

References

transcribed retroactively from a Signal chat

  • 09:20 ...and now I have to figure out how to set the Updater from a place that isn't supposed to have to do that (now), but pretty sure it's really easy if I can just remember the details (!summon codevætter).
  • 11:20 Readout is now adequate, though there are behaviors I still don't quite understand. Running a test now to see if it detects EoF properly.
    • Apparently it did! Next test is to try importing to remote server over ssh. ...except it didn't actually get all of the tables. I suspect a logic bug.
  • 11:26 Maybe needs a post-loop buffer-flush...
    • ...or else defer the loop-exit until the output's bytes-written matches the input's bytes-read. I like that idea better.
  • 11:27 Maybe somewhere in this investigation, I'll figure out why it seems to be loading so much into RAM between writes.
  • 14:45 ...data not being fully imported. Source file 537.1 MB, re-exported data 315.6 MB. (I supposed it's remotely possible that the export is somehow encoded more efficiently than the original, but that seems unlikely. I guess to be sure, I should to a MariaDB-to-MariaDB comparison (source file is from MySQL, and rather an old version at that).
  • 16:30 Came up with a better EoT-detection method and am now... closer, but still encountering a lack of cigar-manifestation. 502.3 MB out of 537.1.
    • (End-of-Transmission is probably a better way to think of this: "when is the data done being transmitted", not "when have we read all the data".)
  • 16:41 kdiff3 refuses to show the actual contents of the files because "Line end style: Unknown" (which Kate does not seem to have a problem with)
  • 16:49 Maybe I just need, like, a command which will list all the tables and how many rows each one has.
    • It would make sense to tag that on to DBA's -l/list command.
  • 16:51 Maybe I should poke at import-over-ssh2, to see how broken that is.
  • 16:53 No overt error messages; gets set up nicely, goes into loop -- nothing gets sent, forever. Okay.
  • 20:56 So, now, looking at the ssh2 import: it does create the schema, so that's something. Then it apparently manages to send 80 bytes, and then it gets stuck.
  • 20:59 Trying to figure out a way to see what those 80 bytes are -- might be a clue.
  • 21:29 I wonder if it's having trouble switching directions. First it has to send an in-memory SQL string to the process and wait for some data, then it has to send SQL from a file to the process and keep looping until all of the file is sent.
    • Also, obviously there has to be some difference between the local-proc and ssh2 versions, so it's going to be code in those classes... probably/maybe...
  • 21:33 I wasn't resetting the streams after setup in ssh2 -- maybe that will make a difference?
  • 21:34 No apparent change. Moving on...
  • 22:03 Made a progress: the Stream for the source-data was not being set up properly in ssh2. Now getting actual errors! Time to stop, tho.