finos_init.q fails when loaded as command-line arg

adavies42 commented 2 years ago

Bug Report

Steps to Reproduce:

q finos_init.q

Expected Result:

include: loading file module/dep.q

Actual Result:

'type
  [3]  [REDACTED]/kdb/q/finos_init.q:21: .finos.dep.cutPath:
    path:"",path;
    match:path ss .finos.dep.pathSeparators;
               ^
    $[0<count match; [p:last match; (p#path;(p+1)_path)]; (enlist".";path)]}
q))

gyorokpeter commented 2 years ago

The reason this happens is that there is no \l on the call stack corresponding to the file load of the main script, which the .finos.dep.currentFile function relies on. Initially I deliberately made the function return a type that likely causes a type error down the line in case the function is called outside of \l, expecting that scenario being incorrect usage. Returning .z.f could work as a band aid but then it could introduce bugs from calling the function on the console/IPC. Not sure what is the best approach to this. Should we raise this to Kx? (If they fix it, it will only be for recent versions, in the worst case from 4.1 onwards if they consider it a too big break.) Can you think of a trick to still distinguish the two scenarios, or should we return .z.f and let the user know that calling it outside of a file load is undefined behavior™?

adavies42 commented 2 years ago

let's try to get kx to include the filename of the function, in the exact form requested (links and all) in the function metadata, as that seems the most general solution

finos / kdb