2026/03/05

From Woozle Writes Code
Jump to navigation Jump to search
Thursday, March 5, 2026 (#64)
Wednesday Thursday Friday posts:prev <this> next

I seem to have screen-updates (Readout subsystem) working for Local/Proc::DoCommand(). There were a couple of irregularities that went away when I cleaned things up; the only problem left is the thing where it seems to silently buffer the entire output before starting to write it to the file (and the screen-updates start happening), but I feel like that's probably not a structural issue and can be fixed later.

Now I need to adapt the same methodologies to work in Remote/SSH2::DoCommand().

First problem: schema-listing no longer working on remote. The Readout does say 89 bytes were fetched (which is about right), but the list comes up empty -- so presumably the string is getting retrieved from the wrong object. ...actually, no: it works in Local/Proc, so it must be that Remote/SSH2 is putting the data in the wrong place.

It looks like NewSchema() (which is where the command is requested, and where the return data is parsed into a schema-list) expects the data to be in $oCmd's Listener stream:

#
        $oCSListen = new BufferClass;
        $oCmd->QOListener()->SetIt($oCSListen);
//...
        $oActCmd = $oServer->DoCommand($oCmd);
//...
        if ($oActCmd->GetOkay()) {

            $oOpData = $oCSListen->PullBytes();

The problem turned out to be that SSH2 wasn't setting the "okay" flag. Works now.

21:21

The problem now is this:

Got to line 39 in [WFe]/IO/Aspect/Connx/aux/A/Canals.php
 - id4686 of [WFe]\IO\Aspect\Connx\aux\A\cCanals->Open() : Opening Canal #0
Got to line 41 in [WFe]/IO/Aspect/Connx/aux/A/Canals.php
 - id4686 of [WFe]\IO\Aspect\Connx\aux\A\cCanals->Open() : Canal status:
> SRCE: (id4755) bytes: 0 -> 0 EoS:n [ssh2 stream]
> DEST: [buffer stream] bytes: 0 pulled, 0 pushed; length=0

Got to line 76 in [WFe]/IO/Aspect/Connx/Runner/Remote/SSH2.php
 - id4755 of [WFe]\IO\Aspect\Connx\Stream\Native\cSSH2->DoCommand() : LectureStream was opened: []
  • Where it says "EoS:n", that means the Stream object (id4755) was opened, which initializes the EoS flag.
  • Where it says "LectureStream was opened: []", the "[]" means that the Stream object (also id4755) was not opened because the EoS flag was not initialized.

The code which ultimately invokes those readouts is this:

#
            $oCanals->Open();
            $oProcLecture->AmHere('LectureStream was opened: ['.$oProcLecture->WasOpened().']'); die();

The Open() invokes code which loops through both of the configured Canal objects with the following code:

#
          $this->AmHere("Opening Canal #$ndx");
            $oCanal->Open();
          $this->AmHere('Canal status:'.CRLF.$oCanal->VIEW_AsBlock());

The question is: what is happening between that last line ('Canal status...') and the "was opened" line to cause the EoS flag to be reset?

21:54

Apparently the WasOpened() function just wasn't following the same logic as the status readout; EoS was not getting reset.

The problem now is that ConveyCheck() is being called repeatedly, even after all 89 bytes have been received.

  • Q1: Is EoS not being detected properly, or is the loop not checking for it properly?
    • A1: The loop checks [SSH2 process]->IsRunning()
  • Q2: How is IsRunning() being determined?
    • A2: It returns the value of !$this->LectureStream()->IsEoF().
  • Q3: Does [SSH2 stream]->IsEoF() work properly?
    • A3: It has to be set in the code, when no more bytes are retrieved.
  • Q4: What happens if I use feof() instead?
    • A4: Oh -- it works. I get a list of schemas.

Well. Okay, then.

...and then we end up with what looks like the same problem when exporting the data: receives all bytes, but loops infinitely waiting for more. Why is this different?

I need to add more info to the Readout, but having trouble finding where it's actually generated.