2026/06/23

Tuesday, June 23, 2026 (#174)

Monday Tuesday Wednesday

References Ferreteria/v0.6/clade/Sys/FileSys/Aspect/Ident/spex/PSpec (← links) 2026/06/22 (← links) Kate (← links) 2026/06/24 (← links)

Main Work

• Ferreteria FileSys stuff in order to support sftp in FTM.

I'm now using "Core" to mean "clade-wrapper for native-API functions or clades, and which doesn't otherwise interact with structural Ferreteria classes". Having a wrapper-API under my control makes it easier to drop in alternative methods of providing the native functionality (such as, say, code lifted from #phpseclib).

• 10:31 I'm trying to get the existing code cleaned up to the point where everything is working properly until the crash happens, so it will be clear exactly which call is causing the crash and that it is happening in the ssh2 libarary – and I'm noticing that the crash only happens on exit, i.e. when ssh2 and sftp are being shut down.
  • Maybe I can get it to work anyway, but just crash at the end?
  • Maybe the crash is due to something not being closed properly, and this can be remedied?
• 11:36 While it may seem sensible, if we're setting Node->SUSpec during setup, to have $SUSpec::set() automatically update (or at least reset) $OPSpec, I think this is going to lead to infinite loops.
  • Tentative Rule: During Node initialization, $SUSpec must be set, and $OUSpec and $OPSpec must be set from it.
    • Caveat: $OUSpec is set from $SUSpec automatically, but the same mechanism doesn't work with $OPSpec because it needs to get its input-string from $OUSpec and that seems to result in problems.
• 14:47 I'm beginning to think that there's one significant issue with using hooked properties, which is that it can make diagnostics more difficult.
  • Maybe it's only a problem if you use a pattern like "if <underlying variable> is null, then {do these things which will set it} and then return the new value". What happens there is that there is no way for other code to check if the variable is currently NULL, because just checking it trips the "if null" check and makes it not-null, which makes it a lot harder to figure out what's actually going on.
  • If that is the case, then maybe for those situations where {we want to trip an "if null" under normal usage but not always} we'll want to have one or more accompanying functions as well. (I'm still thinking this through...)
• 22:46 I think the whole PSpec chaining system needs to be rethought, because it's not behaving as expected.