In that case, ARGV testing is the way to go. Ideally, I think you would pick a specific ARGV which gives you the command line behavior and test for that using an exact match. If your audience is multiple users who install J in different places, I guess you might first normalize ARGV, by eliminating irrelevant parent directories from file names, before testing. But the details of that would depend on your audience.
That said, a simpler approach would be to split the file into two pieces, one which gives you the command line behavior and another which gives you the module implementation. I prefer that myself. (And if you are running into portability issues, you can define a verb which uses 4!:3 and 4!:4 and finds the directory where its script was installed.) Thanks, -- Raul On Wed, Sep 8, 2021 at 12:27 PM Michal Wallace <[email protected]> wrote: > > Hrm. That's very handy, but in this case it's the opposite of what I want. > > The idea is that by default, `load 'whatever'` would just run the > definitions and whatever setup code is absolutely necessary, > but that there's some *extra* thing that runs if you run the file directly > from the command line. > > You shouldn't have to "opt out" of running the extra bit, because loading > and using the definitions is usually > the more common case, and you don't want to burden the user. > > > On Wed, Sep 8, 2021 at 12:20 PM Raul Miller <[email protected]> wrote: > > > The approach mentioned at > > https://rosettacode.org/wiki/Executable_library#J might interest you. > > > > Note that if you are importing it as a widget, you might also want to > > override the command line implementation, for example using 9!:29]0 > > > > Anyways, it depends on what you are trying to do. > > > > -- > > Raul > > > > On Wed, Sep 8, 2021 at 11:09 AM Michal Wallace <[email protected]> > > wrote: > > > > > > In python, you can use this `if __name__=="__main__":` line in a module, > > > and it will only execute the code in that block if you are running the > > > module directly. > > > > > > This allows you to treat the same file as both a standalone application, > > > and a library/module that can be imported into another program. (Or just > > as > > > often often, to run a test suite for just that module as the "standalone" > > > version.) > > > > > > I tried to make the same thing in J > > > > > > My first thought was to turn on the debugger and inspect the stack to see > > > whether or not we're inside of "load", but it turns out that load does > > not > > > appear in the stack trace unless you enabled the debugger *before* you > > > called load. > > > > > > So instead, I wound up with this: > > > > > > {{y > > > NB. standalone code goes here > > > }}^:('repl.ijs' {.@E.&.|. >{.}.ARGV)'' > > > > > > It works pretty well, assuming the file in question is named 'repl.ijs' > > ... > > > > > > Now I can run my repl as a standalone application, or import it as a > > widget. > > > (Yes, I could just make another file for the standalone code, but I > > really > > > like the python style.) > > > > > > Does anyone have a better approach? > > > > > > If load_j_ incremented and decremented a global counter, then you could > > do > > > this with: > > > > > > {{y > > > NB. standalone code goes here > > > }}^:(-.*load_depth)'' > > > > > > Thoughts? > > > ---------------------------------------------------------------------- > > > For information about J forums see http://www.jsoftware.com/forums.htm > > ---------------------------------------------------------------------- > > For information about J forums see http://www.jsoftware.com/forums.htm > > > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
