2026/03/15
|
Sunday, March 15, 2026 (#74)
|
|
References |
09:43
Thinking about that kluge idea, I came up with what might be a better "fake" way of doing enums:
real enum |
fake enum |
|---|---|
enum eExecMode {
case ONE_SHOT;
case START;
case FINISH;
}
|
interface iExecMode {
public const ONE_SHOT = cExecMode_OneShot::class;
public const START = cExecMode_StartOnly::class;
static function DoStart() : bool;
static function DoFinish() : bool;
}
abstract class caExecMode implements iExecMode {}
class cExecMode_OneShot extends caExecMode {
public static function DoStart() : bool { return TRUE; }
public static function DoFinish() : bool { return TRUE; }
}
class cExecMode_StartOnly extends caExecMode {
public static function DoStart() : bool { return TRUE; }
public static function DoFinish() : bool { return FALSE; }
}
class cExecMode_FinishOnly extends caExecMode {
public static function DoStart() : bool { return FALSE; }
public static function DoFinish() : bool { return TRUE; }
}
|
To indicate a particular enum value, you'd just use an object of the appropriate cExecMode_* class. IOW: the base abstract caExecMode class is like an enum pseudoclass, and the podling-classes are like enum cases/values. I've not yet thought of anything you can do with enums that you can't do with this methodology, or which becomes significantly more awkward -- and there are certainly many things you can do with this which are not allowed with enums. The only thing that's a little awkward is using a fake-enum as a constant (e.g. default or initial value).
I didn't get as far as implementing the DoStart() and DoFinish() methods on the real enum, but each one would have to have a conditional to check which enum is being invoked and return the proper flag-value. With the fake-enum, the PHP parser handles the switching in the background.
I ended up making the methods static, because then they can be used from either the class-name or an object.
I don't know if I'll use this as-is, because I was also thinking that something's not quite right about the logic overall -- but for now, I haven't been able to pin it down, so I may end up going with this (and either discovering that it works just fine or else finding out what the problem is).
11:58
I remember now! The problem – which is possibly me being a design-purist, but I do like for code to accurately model what it's doing – is that when you're in "START_ONLY" mode, there's no "echo <command>", which means that whatever data is in the Command object gets ignored. This seems like bad design.
...but then as I was writing this, I realized that there's no reason the Runner couldn't go ahead and send any "<command>" string after starting the process, and then return. So maybe it's fine after all. I was starting to go down a design-rabbit-hole of how maybe we need some kind of specialized Command object for each mode (dump, echo-one-shot, run-and-return) but that didn't seem to be clarifying things, so I hope this latest thought is actually a good solution.
12:21
New idea which both simplifies and limits:
- Get rid of
ExecMode()(fkaDoWait()) altogether. - Let the presence or absence of a command-string be the signal:
- Present: "
echo <command> |" and wait for process to finish before returning. - Absent: Just send the final command (what goes after the "|"), and don't wait.
- Present: "
I have to think about this...
15:42
I'm liking this new idea at least enough to implement it and thereby find out what's wrong with it.
20:38
I guess this represents progress -- actually trying to send data and getting a comm error:
Replacing schema [htyp_mw]... - Errors?: (id5464) bytes: EoS:Y [buffer stream] - Messages?: (id5369) bytes: EoS:Y [buffer stream] - Errors data: [] PHP Notice: fwrite(): Write of 983040 bytes failed with errno=32 Broken pipe in /home/woozle/Sync/dev/local/v0.6/ferreteria/src/IO/Aspect/Connx/Stream/Native/Generic.php on line 81 PHP Stack trace:
This is presumably because Local\Proc->DoCommand() closes the process before exiting -- which it shouldn't do if there was no final command, but I don't think there's any way for it to know that... so I think, maybe, what we have to do is explicitly open the process before calling DoCommand() so that there is at least one "stay open" request active when it exits, and it therefore won't actually close (ActualShut()) until we're ready.
20:55
Welp, that didn't fix it.
Now I have to figure out how to diagnose this. Gaaah.
21:54
The problem is not that the Listener Stream is being closed before the send-loop starts; the problem is that something is going wrong with it during the send-loop:
Got to line 91 in [WFe]/IO/Aspect/Connx/Stream/Native/Generic.php - id5333 of [WFe]\IO\Aspect\Connx\Stream\Native\cGeneric->PushBytes() : Wrote 4096 bytes (995328 remaining) Got to line 86 in [WFe]/IO/Aspect/Connx/Stream/Native/Generic.php - id5333 of [WFe]\IO\Aspect\Connx\Stream\Native\cGeneric->PushBytes() : Writing 4096 bytes (995328 remaining) Got to line 91 in [WFe]/IO/Aspect/Connx/Stream/Native/Generic.php - id5333 of [WFe]\IO\Aspect\Connx\Stream\Native\cGeneric->PushBytes() : Wrote 4096 bytes (991232 remaining) Got to line 86 in [WFe]/IO/Aspect/Connx/Stream/Native/Generic.php - id5333 of [WFe]\IO\Aspect\Connx\Stream\Native\cGeneric->PushBytes() : Writing 4096 bytes (991232 remaining) Got to line 91 in [WFe]/IO/Aspect/Connx/Stream/Native/Generic.php - id5333 of [WFe]\IO\Aspect\Connx\Stream\Native\cGeneric->PushBytes() : Wrote 4096 bytes (987136 remaining) Got to line 86 in [WFe]/IO/Aspect/Connx/Stream/Native/Generic.php - id5333 of [WFe]\IO\Aspect\Connx\Stream\Native\cGeneric->PushBytes() : Writing 4096 bytes (987136 remaining) PHP Notice: fwrite(): Write of 4096 bytes failed with errno=32 Broken pipe in /home/woozle/Sync/dev/local/v0.6/ferreteria/src/IO/Aspect/Connx/Stream/Native/Generic.php on line 87 PHP Stack trace: