Re: [Jgeneral] recursive load (and jpath)
On Fri, May 19, 2023 at 4:33 PM chris burke wrote:
> I again think you overstate the problem.
Perhaps.
Nevertheless, it's a problem which I have had to explain solutions for
a number of times.
And, it's a problem where I've seen people use unreliable approaches
(roughly: _1{::4!:3'') and not seem to understand what I was saying
when I tried to explain why that's a problem.
And, it's a problem which I have seen described as a problem with J:
https://blog.ibzan.co.uk/2023-05-15-thoughts-on-j (search for
Importing files).
--
Raul
--
For information about J forums see http://www.jsoftware.com/forums.htm
Re: [Jgeneral] recursive load (and jpath)
The ~dir/ takes some effort to type. IMO ~./ is easier to type and easier to understand its intention. On Sat, 20 May 2023 at 1:31 AM Raul Miller wrote: > My take here is that at least some of the time during development, > multiple instances of the petal project would need to exist on > developer machines. > > Probably each developer would set up a user key (perhaps > control-shift-P) to load the primary development copy of the > application. > > In messages, we typically refer to files using abbreviated paths > relative to the project root. > > The developers should not have to know the absolute path of the > project on other developer machines. That information is subject to > change and developers are likely to have multiple copies of the app > deployed (for testing and maintenance purposes). > > My plan was to support this by allowing the project to be stored > anywhere (including under ~addons/), with recursive loads able to use > the ~dir/ prefix which is agnostic to project location. > > So, for example, if there's a bug in the addon, the developer could > have a test instance of that version of the addon for debugging > purposes without having to give up any incomplete work on a potential > next major release. No special tooling or configuration needed here. > > (That said, perhaps it would be better to name this shortcut ~loading/ > rather than ~dir/ to better convey its role.) > > Anyways... the problem I see with ~Petal in UserFolders_j_ is that > that becomes a complication at deployment time. And that's going to be > a problem for anyone who wants to use J to develop software which > other people would use. > > Thanks, > > -- > Raul > > On Fri, May 19, 2023 at 9:57 AM chris burke wrote: > > > > If Petal is an addon, then it will be found in ~addons/alice/petal. > > > > More realistically, suppose Petal is a new app being developed that > > might eventually end up as an addon. At least for now, each > > collaborator will define ~Petal appropriately for their system layout. > > > > Normally, the collaborators will have no interest in where each stores > > their copy of the Petal source. But suppose that for whatever reason, > > they decide to tell each other. In what way would this information be > > of use? Note, I am not thinking of pathological examples, but rather > > of ordinary examples where knowing where Petal is stored on each > > machine might be of use. Are there non-trivial examples where such > > information would be helpful? Remember that the information is readily > > obtained from jpath '~Petal'. > > > > On Fri, May 19, 2023 at 8:55 AM Raul Miller > wrote: > > > > > > Let's say that this is an addon. In other words, this should work: > > > > > > install'github:alice/petal' > > > load'alice/petal' > > > > > > Except, load'alice/petal' doesn't work yet, because first the user > > > needs to update UserFolders_j_ > > > > > > Why? > > > > > > But, even before that, Alice needed to test that this install > > > procedure worked. So Alice could not have the code in > > > ~addons/alice/petal/ -- if the code was there, Alice could not test > > > how installation works. > > > > > > How does a fixed definition in UserFolders_j_ help here? > > > > > > Thanks, > > > > > > -- > > > Raul > > > > > > On Fri, May 19, 2023 at 7:48 AM chris burke > wrote: > > > > > > > > OK, suppose Alice, Bob and Chad work jointly on an app called Petal. > > > > > > > > Alice (a Mac user) installs the app in ~dev/petal. > > > > > > > > Bob (a windows user) installs the app in c:\users\bob\apps\petal > > > > > > > > Chad (a linux user) installs the app in ~/mywork/mydev/mypetal. > > > > > > > > Each user creates the path ~Petal to point to the source on their > machine. > > > > > > > > IMHO, this completely solves any problem with paths. > > > > > > > > For example, each user can load and run the application with an > expression like > > > > > > > >load '~Petal/run.ijs' > > > > > > > > Nothing else is needed. But if you really want to, you could get each > > > > source directory with an expression like: > > > > > > > >jpath '~Petal' > > > > > > > > On Fri, May 19, 2023 at 6:33 AM Raul Miller > wrote: > > > > > > > > > > Indeed. > > > > > > > > > > Perhaps I should better document my proposed approach: > > > > > > > > > > My modified 'load' verb adds a 'dir' entry to the top of > > > > > SystemFolders_j_ while each script is being loaded, and removes the > > > > > first 'dir' entry from SystemFolders_j_ when the script finishes > > > > > loading. > > > > > > > > > > Thus when a script is being loaded, it can use the "~dir/" prefix > to > > > > > load adjacent scripts. Without that prefix, scripts would be loaded > > > > > normally (which is to say, based on the working directory of the J > > > > > process or of course based on absolute path). Because the 'dir' > entry > > > > > is removed from SystemFolders_j_ after the load is finished, this > > > > > mechanism can only be used for recursive
Re: [Jgeneral] recursive load (and jpath)
I like Raul's proposal. will modify my load verb in my personal "structural utilitities scripts". Before I think of addons/project "symlink folder" steps, I think of "I should add code in some other file, because it could have strucural/practical reuse." Just putting it in same folder with no OS play is by far the best option. When it actually comes time to attempt to reuse the code, copying it into new "client" folder has the practical benefit of being able to edit the copy for "any imperfect generality" that won't break whatever code was working in original project. On Friday, May 19, 2023 at 07:33:05 p.m. EDT, chris burke wrote: I again think you overstate the problem. An addon goes into a well-defined folder, so we can forget about them. Userfolders allow more than one developer to work on the same source, even where the source may be stored in different locations on different machines - but this is a development issue. Once the app is developed, the usual way to distribute it is to agree on a deployment directory, then zip everything up and send out the zip. Userfolders are not relevant here. On Fri, May 19, 2023 at 10:30 AM Raul Miller wrote: > > My take here is that at least some of the time during development, > multiple instances of the petal project would need to exist on > developer machines. > > Probably each developer would set up a user key (perhaps > control-shift-P) to load the primary development copy of the > application. > > In messages, we typically refer to files using abbreviated paths > relative to the project root. > > The developers should not have to know the absolute path of the > project on other developer machines. That information is subject to > change and developers are likely to have multiple copies of the app > deployed (for testing and maintenance purposes). > > My plan was to support this by allowing the project to be stored > anywhere (including under ~addons/), with recursive loads able to use > the ~dir/ prefix which is agnostic to project location. > > So, for example, if there's a bug in the addon, the developer could > have a test instance of that version of the addon for debugging > purposes without having to give up any incomplete work on a potential > next major release. No special tooling or configuration needed here. > > (That said, perhaps it would be better to name this shortcut ~loading/ > rather than ~dir/ to better convey its role.) > > Anyways... the problem I see with ~Petal in UserFolders_j_ is that > that becomes a complication at deployment time. And that's going to be > a problem for anyone who wants to use J to develop software which > other people would use. > > Thanks, > > -- > Raul > > On Fri, May 19, 2023 at 9:57 AM chris burke wrote: > > > > If Petal is an addon, then it will be found in ~addons/alice/petal. > > > > More realistically, suppose Petal is a new app being developed that > > might eventually end up as an addon. At least for now, each > > collaborator will define ~Petal appropriately for their system layout. > > > > Normally, the collaborators will have no interest in where each stores > > their copy of the Petal source. But suppose that for whatever reason, > > they decide to tell each other. In what way would this information be > > of use? Note, I am not thinking of pathological examples, but rather > > of ordinary examples where knowing where Petal is stored on each > > machine might be of use. Are there non-trivial examples where such > > information would be helpful? Remember that the information is readily > > obtained from jpath '~Petal'. > > > > On Fri, May 19, 2023 at 8:55 AM Raul Miller wrote: > > > > > > Let's say that this is an addon. In other words, this should work: > > > > > > install'github:alice/petal' > > > load'alice/petal' > > > > > > Except, load'alice/petal' doesn't work yet, because first the user > > > needs to update UserFolders_j_ > > > > > > Why? > > > > > > But, even before that, Alice needed to test that this install > > > procedure worked. So Alice could not have the code in > > > ~addons/alice/petal/ -- if the code was there, Alice could not test > > > how installation works. > > > > > > How does a fixed definition in UserFolders_j_ help here? > > > > > > Thanks, > > > > > > -- > > > Raul > > > > > > On Fri, May 19, 2023 at 7:48 AM chris burke wrote: > > > > > > > > OK, suppose Alice, Bob and Chad work jointly on an app called Petal. > > > > > > > > Alice (a Mac user) installs the app in ~dev/petal. > > > > > > > > Bob (a windows user) installs the app in c:\users\bob\apps\petal > > > > > > > > Chad (a linux user) installs the app in ~/mywork/mydev/mypetal. > > > > > > > > Each user creates the path ~Petal to point to the source on their > > > > machine. > > > > > > > > IMHO, this completely solves any problem with paths. > > > > > > > > For example, each user can load and run the application with an > > > > expression like > > > > > > > > load '~Petal/run.ijs'
Re: [Jgeneral] recursive load (and jpath)
I again think you overstate the problem. An addon goes into a well-defined folder, so we can forget about them. Userfolders allow more than one developer to work on the same source, even where the source may be stored in different locations on different machines - but this is a development issue. Once the app is developed, the usual way to distribute it is to agree on a deployment directory, then zip everything up and send out the zip. Userfolders are not relevant here. On Fri, May 19, 2023 at 10:30 AM Raul Miller wrote: > > My take here is that at least some of the time during development, > multiple instances of the petal project would need to exist on > developer machines. > > Probably each developer would set up a user key (perhaps > control-shift-P) to load the primary development copy of the > application. > > In messages, we typically refer to files using abbreviated paths > relative to the project root. > > The developers should not have to know the absolute path of the > project on other developer machines. That information is subject to > change and developers are likely to have multiple copies of the app > deployed (for testing and maintenance purposes). > > My plan was to support this by allowing the project to be stored > anywhere (including under ~addons/), with recursive loads able to use > the ~dir/ prefix which is agnostic to project location. > > So, for example, if there's a bug in the addon, the developer could > have a test instance of that version of the addon for debugging > purposes without having to give up any incomplete work on a potential > next major release. No special tooling or configuration needed here. > > (That said, perhaps it would be better to name this shortcut ~loading/ > rather than ~dir/ to better convey its role.) > > Anyways... the problem I see with ~Petal in UserFolders_j_ is that > that becomes a complication at deployment time. And that's going to be > a problem for anyone who wants to use J to develop software which > other people would use. > > Thanks, > > -- > Raul > > On Fri, May 19, 2023 at 9:57 AM chris burke wrote: > > > > If Petal is an addon, then it will be found in ~addons/alice/petal. > > > > More realistically, suppose Petal is a new app being developed that > > might eventually end up as an addon. At least for now, each > > collaborator will define ~Petal appropriately for their system layout. > > > > Normally, the collaborators will have no interest in where each stores > > their copy of the Petal source. But suppose that for whatever reason, > > they decide to tell each other. In what way would this information be > > of use? Note, I am not thinking of pathological examples, but rather > > of ordinary examples where knowing where Petal is stored on each > > machine might be of use. Are there non-trivial examples where such > > information would be helpful? Remember that the information is readily > > obtained from jpath '~Petal'. > > > > On Fri, May 19, 2023 at 8:55 AM Raul Miller wrote: > > > > > > Let's say that this is an addon. In other words, this should work: > > > > > > install'github:alice/petal' > > > load'alice/petal' > > > > > > Except, load'alice/petal' doesn't work yet, because first the user > > > needs to update UserFolders_j_ > > > > > > Why? > > > > > > But, even before that, Alice needed to test that this install > > > procedure worked. So Alice could not have the code in > > > ~addons/alice/petal/ -- if the code was there, Alice could not test > > > how installation works. > > > > > > How does a fixed definition in UserFolders_j_ help here? > > > > > > Thanks, > > > > > > -- > > > Raul > > > > > > On Fri, May 19, 2023 at 7:48 AM chris burke wrote: > > > > > > > > OK, suppose Alice, Bob and Chad work jointly on an app called Petal. > > > > > > > > Alice (a Mac user) installs the app in ~dev/petal. > > > > > > > > Bob (a windows user) installs the app in c:\users\bob\apps\petal > > > > > > > > Chad (a linux user) installs the app in ~/mywork/mydev/mypetal. > > > > > > > > Each user creates the path ~Petal to point to the source on their > > > > machine. > > > > > > > > IMHO, this completely solves any problem with paths. > > > > > > > > For example, each user can load and run the application with an > > > > expression like > > > > > > > >load '~Petal/run.ijs' > > > > > > > > Nothing else is needed. But if you really want to, you could get each > > > > source directory with an expression like: > > > > > > > >jpath '~Petal' > > > > > > > > On Fri, May 19, 2023 at 6:33 AM Raul Miller > > > > wrote: > > > > > > > > > > Indeed. > > > > > > > > > > Perhaps I should better document my proposed approach: > > > > > > > > > > My modified 'load' verb adds a 'dir' entry to the top of > > > > > SystemFolders_j_ while each script is being loaded, and removes the > > > > > first 'dir' entry from SystemFolders_j_ when the script finishes > > > > > loading. > > > > > > > > > > Thus when a script is being loaded, it can
Re: [Jgeneral] recursive load (and jpath)
My take here is that at least some of the time during development, multiple instances of the petal project would need to exist on developer machines. Probably each developer would set up a user key (perhaps control-shift-P) to load the primary development copy of the application. In messages, we typically refer to files using abbreviated paths relative to the project root. The developers should not have to know the absolute path of the project on other developer machines. That information is subject to change and developers are likely to have multiple copies of the app deployed (for testing and maintenance purposes). My plan was to support this by allowing the project to be stored anywhere (including under ~addons/), with recursive loads able to use the ~dir/ prefix which is agnostic to project location. So, for example, if there's a bug in the addon, the developer could have a test instance of that version of the addon for debugging purposes without having to give up any incomplete work on a potential next major release. No special tooling or configuration needed here. (That said, perhaps it would be better to name this shortcut ~loading/ rather than ~dir/ to better convey its role.) Anyways... the problem I see with ~Petal in UserFolders_j_ is that that becomes a complication at deployment time. And that's going to be a problem for anyone who wants to use J to develop software which other people would use. Thanks, -- Raul On Fri, May 19, 2023 at 9:57 AM chris burke wrote: > > If Petal is an addon, then it will be found in ~addons/alice/petal. > > More realistically, suppose Petal is a new app being developed that > might eventually end up as an addon. At least for now, each > collaborator will define ~Petal appropriately for their system layout. > > Normally, the collaborators will have no interest in where each stores > their copy of the Petal source. But suppose that for whatever reason, > they decide to tell each other. In what way would this information be > of use? Note, I am not thinking of pathological examples, but rather > of ordinary examples where knowing where Petal is stored on each > machine might be of use. Are there non-trivial examples where such > information would be helpful? Remember that the information is readily > obtained from jpath '~Petal'. > > On Fri, May 19, 2023 at 8:55 AM Raul Miller wrote: > > > > Let's say that this is an addon. In other words, this should work: > > > > install'github:alice/petal' > > load'alice/petal' > > > > Except, load'alice/petal' doesn't work yet, because first the user > > needs to update UserFolders_j_ > > > > Why? > > > > But, even before that, Alice needed to test that this install > > procedure worked. So Alice could not have the code in > > ~addons/alice/petal/ -- if the code was there, Alice could not test > > how installation works. > > > > How does a fixed definition in UserFolders_j_ help here? > > > > Thanks, > > > > -- > > Raul > > > > On Fri, May 19, 2023 at 7:48 AM chris burke wrote: > > > > > > OK, suppose Alice, Bob and Chad work jointly on an app called Petal. > > > > > > Alice (a Mac user) installs the app in ~dev/petal. > > > > > > Bob (a windows user) installs the app in c:\users\bob\apps\petal > > > > > > Chad (a linux user) installs the app in ~/mywork/mydev/mypetal. > > > > > > Each user creates the path ~Petal to point to the source on their machine. > > > > > > IMHO, this completely solves any problem with paths. > > > > > > For example, each user can load and run the application with an > > > expression like > > > > > >load '~Petal/run.ijs' > > > > > > Nothing else is needed. But if you really want to, you could get each > > > source directory with an expression like: > > > > > >jpath '~Petal' > > > > > > On Fri, May 19, 2023 at 6:33 AM Raul Miller wrote: > > > > > > > > Indeed. > > > > > > > > Perhaps I should better document my proposed approach: > > > > > > > > My modified 'load' verb adds a 'dir' entry to the top of > > > > SystemFolders_j_ while each script is being loaded, and removes the > > > > first 'dir' entry from SystemFolders_j_ when the script finishes > > > > loading. > > > > > > > > Thus when a script is being loaded, it can use the "~dir/" prefix to > > > > load adjacent scripts. Without that prefix, scripts would be loaded > > > > normally (which is to say, based on the working directory of the J > > > > process or of course based on absolute path). Because the 'dir' entry > > > > is removed from SystemFolders_j_ after the load is finished, this > > > > mechanism can only be used for recursive loads. > > > > > > > > Because this entry is added to the top of SystemFolders_j_, each > > > > recursive load would override any invoking load in the rare cases > > > > where that could conflict. > > > > > > > > In other words: Only load / require arguments which use the "~dir/" > > > > prefix from inside a script would be affected by this change. > > > > > > > > (And, since this is still
Re: [Jgeneral] recursive load (and jpath)
If Petal is an addon, then it will be found in ~addons/alice/petal. More realistically, suppose Petal is a new app being developed that might eventually end up as an addon. At least for now, each collaborator will define ~Petal appropriately for their system layout. Normally, the collaborators will have no interest in where each stores their copy of the Petal source. But suppose that for whatever reason, they decide to tell each other. In what way would this information be of use? Note, I am not thinking of pathological examples, but rather of ordinary examples where knowing where Petal is stored on each machine might be of use. Are there non-trivial examples where such information would be helpful? Remember that the information is readily obtained from jpath '~Petal'. On Fri, May 19, 2023 at 8:55 AM Raul Miller wrote: > > Let's say that this is an addon. In other words, this should work: > > install'github:alice/petal' > load'alice/petal' > > Except, load'alice/petal' doesn't work yet, because first the user > needs to update UserFolders_j_ > > Why? > > But, even before that, Alice needed to test that this install > procedure worked. So Alice could not have the code in > ~addons/alice/petal/ -- if the code was there, Alice could not test > how installation works. > > How does a fixed definition in UserFolders_j_ help here? > > Thanks, > > -- > Raul > > On Fri, May 19, 2023 at 7:48 AM chris burke wrote: > > > > OK, suppose Alice, Bob and Chad work jointly on an app called Petal. > > > > Alice (a Mac user) installs the app in ~dev/petal. > > > > Bob (a windows user) installs the app in c:\users\bob\apps\petal > > > > Chad (a linux user) installs the app in ~/mywork/mydev/mypetal. > > > > Each user creates the path ~Petal to point to the source on their machine. > > > > IMHO, this completely solves any problem with paths. > > > > For example, each user can load and run the application with an expression > > like > > > >load '~Petal/run.ijs' > > > > Nothing else is needed. But if you really want to, you could get each > > source directory with an expression like: > > > >jpath '~Petal' > > > > On Fri, May 19, 2023 at 6:33 AM Raul Miller wrote: > > > > > > Indeed. > > > > > > Perhaps I should better document my proposed approach: > > > > > > My modified 'load' verb adds a 'dir' entry to the top of > > > SystemFolders_j_ while each script is being loaded, and removes the > > > first 'dir' entry from SystemFolders_j_ when the script finishes > > > loading. > > > > > > Thus when a script is being loaded, it can use the "~dir/" prefix to > > > load adjacent scripts. Without that prefix, scripts would be loaded > > > normally (which is to say, based on the working directory of the J > > > process or of course based on absolute path). Because the 'dir' entry > > > is removed from SystemFolders_j_ after the load is finished, this > > > mechanism can only be used for recursive loads. > > > > > > Because this entry is added to the top of SystemFolders_j_, each > > > recursive load would override any invoking load in the rare cases > > > where that could conflict. > > > > > > In other words: Only load / require arguments which use the "~dir/" > > > prefix from inside a script would be affected by this change. > > > > > > (And, since this is still just a proposal, 'dir' could be replaced > > > with some other name.) > > > > > > See http://www.jsoftware.com/pipermail/general/2023-May/039741.html > > > for the example implementation. > > > > > > Thanks, > > > > > > -- > > > Raul > > > > > > On Fri, May 19, 2023 at 12:01 AM bill lam wrote: > > > > > > > > On reflection, this can be quite complicated because a script can load > > > > other scripts recursively as mentioned in the subject line of the > > > > current > > > > email thread. > > > > > > > > On Fri, 19 May 2023 at 2:52 PM bill lam wrote: > > > > > > > > > Actually I quite like this idea that loading scripts relative to the > > > > > folder of current script loaded ( not current working directory). > > > > > > > > > > I can think of an alternative is saving the folder of the last 1!:x > > > > > and > > > > > then querying it using a foreign conjunction. > > > > > > > > > > On Fri, 19 May 2023 at 1:31 PM Raul Miller > > > > > wrote: > > > > > > > > > >> The problem that this would address is the complexity of figuring out > > > > >> where a project has been deployed. > > > > >> > > > > >> Yes, it's true that we can install from github. But to test that we > > > > >> have supported that we need the project installed in a different > > > > >> location. > > > > >> > > > > >> And, yes, this is entirely solvable. But it's not easily solvable, > > > > >> especially on the part of new users. > > > > >> > > > > >> Why should this be difficult? > > > > >> > > > > >> Thanks, > > > > >> > > > > >> -- > > > > >> Raul > > > > >> > > > > >> > > > > >> On Thu, May 18, 2023 at 6:59 PM chris burke > > > > >> wrote: > > > > >> > > > > > >> > Suggestions like
Re: [Jgeneral] recursive load (and jpath)
Let's say that this is an addon. In other words, this should work: install'github:alice/petal' load'alice/petal' Except, load'alice/petal' doesn't work yet, because first the user needs to update UserFolders_j_ Why? But, even before that, Alice needed to test that this install procedure worked. So Alice could not have the code in ~addons/alice/petal/ -- if the code was there, Alice could not test how installation works. How does a fixed definition in UserFolders_j_ help here? Thanks, -- Raul On Fri, May 19, 2023 at 7:48 AM chris burke wrote: > > OK, suppose Alice, Bob and Chad work jointly on an app called Petal. > > Alice (a Mac user) installs the app in ~dev/petal. > > Bob (a windows user) installs the app in c:\users\bob\apps\petal > > Chad (a linux user) installs the app in ~/mywork/mydev/mypetal. > > Each user creates the path ~Petal to point to the source on their machine. > > IMHO, this completely solves any problem with paths. > > For example, each user can load and run the application with an expression > like > >load '~Petal/run.ijs' > > Nothing else is needed. But if you really want to, you could get each > source directory with an expression like: > >jpath '~Petal' > > On Fri, May 19, 2023 at 6:33 AM Raul Miller wrote: > > > > Indeed. > > > > Perhaps I should better document my proposed approach: > > > > My modified 'load' verb adds a 'dir' entry to the top of > > SystemFolders_j_ while each script is being loaded, and removes the > > first 'dir' entry from SystemFolders_j_ when the script finishes > > loading. > > > > Thus when a script is being loaded, it can use the "~dir/" prefix to > > load adjacent scripts. Without that prefix, scripts would be loaded > > normally (which is to say, based on the working directory of the J > > process or of course based on absolute path). Because the 'dir' entry > > is removed from SystemFolders_j_ after the load is finished, this > > mechanism can only be used for recursive loads. > > > > Because this entry is added to the top of SystemFolders_j_, each > > recursive load would override any invoking load in the rare cases > > where that could conflict. > > > > In other words: Only load / require arguments which use the "~dir/" > > prefix from inside a script would be affected by this change. > > > > (And, since this is still just a proposal, 'dir' could be replaced > > with some other name.) > > > > See http://www.jsoftware.com/pipermail/general/2023-May/039741.html > > for the example implementation. > > > > Thanks, > > > > -- > > Raul > > > > On Fri, May 19, 2023 at 12:01 AM bill lam wrote: > > > > > > On reflection, this can be quite complicated because a script can load > > > other scripts recursively as mentioned in the subject line of the current > > > email thread. > > > > > > On Fri, 19 May 2023 at 2:52 PM bill lam wrote: > > > > > > > Actually I quite like this idea that loading scripts relative to the > > > > folder of current script loaded ( not current working directory). > > > > > > > > I can think of an alternative is saving the folder of the last 1!:x and > > > > then querying it using a foreign conjunction. > > > > > > > > On Fri, 19 May 2023 at 1:31 PM Raul Miller > > > > wrote: > > > > > > > >> The problem that this would address is the complexity of figuring out > > > >> where a project has been deployed. > > > >> > > > >> Yes, it's true that we can install from github. But to test that we > > > >> have supported that we need the project installed in a different > > > >> location. > > > >> > > > >> And, yes, this is entirely solvable. But it's not easily solvable, > > > >> especially on the part of new users. > > > >> > > > >> Why should this be difficult? > > > >> > > > >> Thanks, > > > >> > > > >> -- > > > >> Raul > > > >> > > > >> > > > >> On Thu, May 18, 2023 at 6:59 PM chris burke > > > >> wrote: > > > >> > > > > >> > Suggestions like this come up from time to time, but I think they are > > > >> > mistaken. We already have a mechanism for naming files outside > > > >> > standard J directories, see > > > >> > https://code.jsoftware.com/wiki/Guides/Folders_and_Projects . I don't > > > >> > think anything else is needed, rather any extra mechanism will add > > > >> > unnecessary complexity. > > > >> > > > > >> > I'd recommend becoming thoroughly familiar with what we already have. > > > >> Thanks! > > > >> > > > > >> > On Thu, May 18, 2023 at 8:59 AM Raul Miller > > > >> wrote: > > > >> > > > > > >> > > Quite often, we might want to work with collections of J scripts > > > >> > > which > > > >> > > are outside the standard J system and user directories. > > > >> > > > > > >> > > It's quite possible, though obscure, to use introspection (4!:4 and > > > >> > > 4!:3) to locate scripts relative to the currently executing script. > > > >> > > > > > >> > > It would probably be better to make this be an explicitly supported > > > >> > > feature of J's load verb. > > > >> > > > > > >> > > Specifically, I would like
Re: [Jgeneral] recursive load (and jpath)
> On reflection, this can be quite complicated because a script can load other > scripts recursively as mentioned in the subject line of the current email > thread. Right, but isn't this just a matter of giving the user enough rope to hang themselves? The definitions of folders and projects are as simple as you can get. Any increase in complexity suggests that the user does not appreciate what is already available. On Fri, May 19, 2023 at 7:48 AM chris burke wrote: > > OK, suppose Alice, Bob and Chad work jointly on an app called Petal. > > Alice (a Mac user) installs the app in ~dev/petal. > > Bob (a windows user) installs the app in c:\users\bob\apps\petal > > Chad (a linux user) installs the app in ~/mywork/mydev/mypetal. > > Each user creates the path ~Petal to point to the source on their machine. > > IMHO, this completely solves any problem with paths. > > For example, each user can load and run the application with an expression > like > >load '~Petal/run.ijs' > > Nothing else is needed. But if you really want to, you could get each > source directory with an expression like: > >jpath '~Petal' > > On Fri, May 19, 2023 at 6:33 AM Raul Miller wrote: > > > > Indeed. > > > > Perhaps I should better document my proposed approach: > > > > My modified 'load' verb adds a 'dir' entry to the top of > > SystemFolders_j_ while each script is being loaded, and removes the > > first 'dir' entry from SystemFolders_j_ when the script finishes > > loading. > > > > Thus when a script is being loaded, it can use the "~dir/" prefix to > > load adjacent scripts. Without that prefix, scripts would be loaded > > normally (which is to say, based on the working directory of the J > > process or of course based on absolute path). Because the 'dir' entry > > is removed from SystemFolders_j_ after the load is finished, this > > mechanism can only be used for recursive loads. > > > > Because this entry is added to the top of SystemFolders_j_, each > > recursive load would override any invoking load in the rare cases > > where that could conflict. > > > > In other words: Only load / require arguments which use the "~dir/" > > prefix from inside a script would be affected by this change. > > > > (And, since this is still just a proposal, 'dir' could be replaced > > with some other name.) > > > > See http://www.jsoftware.com/pipermail/general/2023-May/039741.html > > for the example implementation. > > > > Thanks, > > > > -- > > Raul > > > > On Fri, May 19, 2023 at 12:01 AM bill lam wrote: > > > > > > On reflection, this can be quite complicated because a script can load > > > other scripts recursively as mentioned in the subject line of the current > > > email thread. > > > > > > On Fri, 19 May 2023 at 2:52 PM bill lam wrote: > > > > > > > Actually I quite like this idea that loading scripts relative to the > > > > folder of current script loaded ( not current working directory). > > > > > > > > I can think of an alternative is saving the folder of the last 1!:x and > > > > then querying it using a foreign conjunction. > > > > > > > > On Fri, 19 May 2023 at 1:31 PM Raul Miller > > > > wrote: > > > > > > > >> The problem that this would address is the complexity of figuring out > > > >> where a project has been deployed. > > > >> > > > >> Yes, it's true that we can install from github. But to test that we > > > >> have supported that we need the project installed in a different > > > >> location. > > > >> > > > >> And, yes, this is entirely solvable. But it's not easily solvable, > > > >> especially on the part of new users. > > > >> > > > >> Why should this be difficult? > > > >> > > > >> Thanks, > > > >> > > > >> -- > > > >> Raul > > > >> > > > >> > > > >> On Thu, May 18, 2023 at 6:59 PM chris burke > > > >> wrote: > > > >> > > > > >> > Suggestions like this come up from time to time, but I think they are > > > >> > mistaken. We already have a mechanism for naming files outside > > > >> > standard J directories, see > > > >> > https://code.jsoftware.com/wiki/Guides/Folders_and_Projects . I don't > > > >> > think anything else is needed, rather any extra mechanism will add > > > >> > unnecessary complexity. > > > >> > > > > >> > I'd recommend becoming thoroughly familiar with what we already have. > > > >> Thanks! > > > >> > > > > >> > On Thu, May 18, 2023 at 8:59 AM Raul Miller > > > >> wrote: > > > >> > > > > > >> > > Quite often, we might want to work with collections of J scripts > > > >> > > which > > > >> > > are outside the standard J system and user directories. > > > >> > > > > > >> > > It's quite possible, though obscure, to use introspection (4!:4 and > > > >> > > 4!:3) to locate scripts relative to the currently executing script. > > > >> > > > > > >> > > It would probably be better to make this be an explicitly supported > > > >> > > feature of J's load verb. > > > >> > > > > > >> > > Specifically, I would like to propose that while load is executing, > > > >> > > jpath would expand ~dir/ to
Re: [Jgeneral] recursive load (and jpath)
OK, suppose Alice, Bob and Chad work jointly on an app called Petal.
Alice (a Mac user) installs the app in ~dev/petal.
Bob (a windows user) installs the app in c:\users\bob\apps\petal
Chad (a linux user) installs the app in ~/mywork/mydev/mypetal.
Each user creates the path ~Petal to point to the source on their machine.
IMHO, this completely solves any problem with paths.
For example, each user can load and run the application with an expression like
load '~Petal/run.ijs'
Nothing else is needed. But if you really want to, you could get each
source directory with an expression like:
jpath '~Petal'
On Fri, May 19, 2023 at 6:33 AM Raul Miller wrote:
>
> Indeed.
>
> Perhaps I should better document my proposed approach:
>
> My modified 'load' verb adds a 'dir' entry to the top of
> SystemFolders_j_ while each script is being loaded, and removes the
> first 'dir' entry from SystemFolders_j_ when the script finishes
> loading.
>
> Thus when a script is being loaded, it can use the "~dir/" prefix to
> load adjacent scripts. Without that prefix, scripts would be loaded
> normally (which is to say, based on the working directory of the J
> process or of course based on absolute path). Because the 'dir' entry
> is removed from SystemFolders_j_ after the load is finished, this
> mechanism can only be used for recursive loads.
>
> Because this entry is added to the top of SystemFolders_j_, each
> recursive load would override any invoking load in the rare cases
> where that could conflict.
>
> In other words: Only load / require arguments which use the "~dir/"
> prefix from inside a script would be affected by this change.
>
> (And, since this is still just a proposal, 'dir' could be replaced
> with some other name.)
>
> See http://www.jsoftware.com/pipermail/general/2023-May/039741.html
> for the example implementation.
>
> Thanks,
>
> --
> Raul
>
> On Fri, May 19, 2023 at 12:01 AM bill lam wrote:
> >
> > On reflection, this can be quite complicated because a script can load
> > other scripts recursively as mentioned in the subject line of the current
> > email thread.
> >
> > On Fri, 19 May 2023 at 2:52 PM bill lam wrote:
> >
> > > Actually I quite like this idea that loading scripts relative to the
> > > folder of current script loaded ( not current working directory).
> > >
> > > I can think of an alternative is saving the folder of the last 1!:x and
> > > then querying it using a foreign conjunction.
> > >
> > > On Fri, 19 May 2023 at 1:31 PM Raul Miller wrote:
> > >
> > >> The problem that this would address is the complexity of figuring out
> > >> where a project has been deployed.
> > >>
> > >> Yes, it's true that we can install from github. But to test that we
> > >> have supported that we need the project installed in a different
> > >> location.
> > >>
> > >> And, yes, this is entirely solvable. But it's not easily solvable,
> > >> especially on the part of new users.
> > >>
> > >> Why should this be difficult?
> > >>
> > >> Thanks,
> > >>
> > >> --
> > >> Raul
> > >>
> > >>
> > >> On Thu, May 18, 2023 at 6:59 PM chris burke wrote:
> > >> >
> > >> > Suggestions like this come up from time to time, but I think they are
> > >> > mistaken. We already have a mechanism for naming files outside
> > >> > standard J directories, see
> > >> > https://code.jsoftware.com/wiki/Guides/Folders_and_Projects . I don't
> > >> > think anything else is needed, rather any extra mechanism will add
> > >> > unnecessary complexity.
> > >> >
> > >> > I'd recommend becoming thoroughly familiar with what we already have.
> > >> Thanks!
> > >> >
> > >> > On Thu, May 18, 2023 at 8:59 AM Raul Miller
> > >> wrote:
> > >> > >
> > >> > > Quite often, we might want to work with collections of J scripts
> > >> > > which
> > >> > > are outside the standard J system and user directories.
> > >> > >
> > >> > > It's quite possible, though obscure, to use introspection (4!:4 and
> > >> > > 4!:3) to locate scripts relative to the currently executing script.
> > >> > >
> > >> > > It would probably be better to make this be an explicitly supported
> > >> > > feature of J's load verb.
> > >> > >
> > >> > > Specifically, I would like to propose that while load is executing,
> > >> > > jpath would expand ~dir/ to be the innermost referenced directory of
> > >> > > the currently executing load.
> > >> > >
> > >> > > In other words:something like
> > >> > >
> > >> > > load=: {{
> > >> > > 0 load y
> > >> > > :
> > >> > > fls=. getscripts_j_ y
> > >> > > fn=. ('script',x#'d')~
> > >> > > for_fl. fls do.
> > >> > > SystemFolders_j_=: SystemFolders_j_,~ 'dir';fpath_j_;fl
> > >> > > if. Displayload_j_ do. echo;fl end.
> > >> > > if. -. fexist fl do.
> > >> > > echo 'not found: ',;fl
> > >> > > end.
> > >> > > fn fl
> > >> > > SystemFolders_j_=: (<<<({."1 SystemFolders_j_)i.<'dir') {
> > >> SystemFolders_j_
> > >> > > Loaded_j_=: ~. Loaded_j_,fl
> > >> > > end.
> > >> > > EMPTY
> > >> >
Re: [Jgeneral] recursive load (and jpath)
Indeed.
Perhaps I should better document my proposed approach:
My modified 'load' verb adds a 'dir' entry to the top of
SystemFolders_j_ while each script is being loaded, and removes the
first 'dir' entry from SystemFolders_j_ when the script finishes
loading.
Thus when a script is being loaded, it can use the "~dir/" prefix to
load adjacent scripts. Without that prefix, scripts would be loaded
normally (which is to say, based on the working directory of the J
process or of course based on absolute path). Because the 'dir' entry
is removed from SystemFolders_j_ after the load is finished, this
mechanism can only be used for recursive loads.
Because this entry is added to the top of SystemFolders_j_, each
recursive load would override any invoking load in the rare cases
where that could conflict.
In other words: Only load / require arguments which use the "~dir/"
prefix from inside a script would be affected by this change.
(And, since this is still just a proposal, 'dir' could be replaced
with some other name.)
See http://www.jsoftware.com/pipermail/general/2023-May/039741.html
for the example implementation.
Thanks,
--
Raul
On Fri, May 19, 2023 at 12:01 AM bill lam wrote:
>
> On reflection, this can be quite complicated because a script can load
> other scripts recursively as mentioned in the subject line of the current
> email thread.
>
> On Fri, 19 May 2023 at 2:52 PM bill lam wrote:
>
> > Actually I quite like this idea that loading scripts relative to the
> > folder of current script loaded ( not current working directory).
> >
> > I can think of an alternative is saving the folder of the last 1!:x and
> > then querying it using a foreign conjunction.
> >
> > On Fri, 19 May 2023 at 1:31 PM Raul Miller wrote:
> >
> >> The problem that this would address is the complexity of figuring out
> >> where a project has been deployed.
> >>
> >> Yes, it's true that we can install from github. But to test that we
> >> have supported that we need the project installed in a different
> >> location.
> >>
> >> And, yes, this is entirely solvable. But it's not easily solvable,
> >> especially on the part of new users.
> >>
> >> Why should this be difficult?
> >>
> >> Thanks,
> >>
> >> --
> >> Raul
> >>
> >>
> >> On Thu, May 18, 2023 at 6:59 PM chris burke wrote:
> >> >
> >> > Suggestions like this come up from time to time, but I think they are
> >> > mistaken. We already have a mechanism for naming files outside
> >> > standard J directories, see
> >> > https://code.jsoftware.com/wiki/Guides/Folders_and_Projects . I don't
> >> > think anything else is needed, rather any extra mechanism will add
> >> > unnecessary complexity.
> >> >
> >> > I'd recommend becoming thoroughly familiar with what we already have.
> >> Thanks!
> >> >
> >> > On Thu, May 18, 2023 at 8:59 AM Raul Miller
> >> wrote:
> >> > >
> >> > > Quite often, we might want to work with collections of J scripts which
> >> > > are outside the standard J system and user directories.
> >> > >
> >> > > It's quite possible, though obscure, to use introspection (4!:4 and
> >> > > 4!:3) to locate scripts relative to the currently executing script.
> >> > >
> >> > > It would probably be better to make this be an explicitly supported
> >> > > feature of J's load verb.
> >> > >
> >> > > Specifically, I would like to propose that while load is executing,
> >> > > jpath would expand ~dir/ to be the innermost referenced directory of
> >> > > the currently executing load.
> >> > >
> >> > > In other words:something like
> >> > >
> >> > > load=: {{
> >> > > 0 load y
> >> > > :
> >> > > fls=. getscripts_j_ y
> >> > > fn=. ('script',x#'d')~
> >> > > for_fl. fls do.
> >> > > SystemFolders_j_=: SystemFolders_j_,~ 'dir';fpath_j_;fl
> >> > > if. Displayload_j_ do. echo;fl end.
> >> > > if. -. fexist fl do.
> >> > > echo 'not found: ',;fl
> >> > > end.
> >> > > fn fl
> >> > > SystemFolders_j_=: (<<<({."1 SystemFolders_j_)i.<'dir') {
> >> SystemFolders_j_
> >> > > Loaded_j_=: ~. Loaded_j_,fl
> >> > > end.
> >> > > EMPTY
> >> > > }}
> >> > >
> >> > > Thoughts? Objections? Improvements?
> >> > >
> >> > > Thanks,
> >> > >
> >> > > --
> >> > > Raul
> >> > > --
> >> > > 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
--
For information about J forums see http://www.jsoftware.com/forums.htm
Re: [Jgeneral] recursive load (and jpath)
On reflection, this can be quite complicated because a script can load
other scripts recursively as mentioned in the subject line of the current
email thread.
On Fri, 19 May 2023 at 2:52 PM bill lam wrote:
> Actually I quite like this idea that loading scripts relative to the
> folder of current script loaded ( not current working directory).
>
> I can think of an alternative is saving the folder of the last 1!:x and
> then querying it using a foreign conjunction.
>
> On Fri, 19 May 2023 at 1:31 PM Raul Miller wrote:
>
>> The problem that this would address is the complexity of figuring out
>> where a project has been deployed.
>>
>> Yes, it's true that we can install from github. But to test that we
>> have supported that we need the project installed in a different
>> location.
>>
>> And, yes, this is entirely solvable. But it's not easily solvable,
>> especially on the part of new users.
>>
>> Why should this be difficult?
>>
>> Thanks,
>>
>> --
>> Raul
>>
>>
>> On Thu, May 18, 2023 at 6:59 PM chris burke wrote:
>> >
>> > Suggestions like this come up from time to time, but I think they are
>> > mistaken. We already have a mechanism for naming files outside
>> > standard J directories, see
>> > https://code.jsoftware.com/wiki/Guides/Folders_and_Projects . I don't
>> > think anything else is needed, rather any extra mechanism will add
>> > unnecessary complexity.
>> >
>> > I'd recommend becoming thoroughly familiar with what we already have.
>> Thanks!
>> >
>> > On Thu, May 18, 2023 at 8:59 AM Raul Miller
>> wrote:
>> > >
>> > > Quite often, we might want to work with collections of J scripts which
>> > > are outside the standard J system and user directories.
>> > >
>> > > It's quite possible, though obscure, to use introspection (4!:4 and
>> > > 4!:3) to locate scripts relative to the currently executing script.
>> > >
>> > > It would probably be better to make this be an explicitly supported
>> > > feature of J's load verb.
>> > >
>> > > Specifically, I would like to propose that while load is executing,
>> > > jpath would expand ~dir/ to be the innermost referenced directory of
>> > > the currently executing load.
>> > >
>> > > In other words:something like
>> > >
>> > > load=: {{
>> > > 0 load y
>> > > :
>> > > fls=. getscripts_j_ y
>> > > fn=. ('script',x#'d')~
>> > > for_fl. fls do.
>> > > SystemFolders_j_=: SystemFolders_j_,~ 'dir';fpath_j_;fl
>> > > if. Displayload_j_ do. echo;fl end.
>> > > if. -. fexist fl do.
>> > > echo 'not found: ',;fl
>> > > end.
>> > > fn fl
>> > > SystemFolders_j_=: (<<<({."1 SystemFolders_j_)i.<'dir') {
>> SystemFolders_j_
>> > > Loaded_j_=: ~. Loaded_j_,fl
>> > > end.
>> > > EMPTY
>> > > }}
>> > >
>> > > Thoughts? Objections? Improvements?
>> > >
>> > > Thanks,
>> > >
>> > > --
>> > > Raul
>> > > --
>> > > 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
Re: [Jgeneral] recursive load (and jpath)
Actually I quite like this idea that loading scripts relative to the folder
of current script loaded ( not current working directory).
I can think of an alternative is saving the folder of the last 1!:x and
then querying it using a foreign conjunction.
On Fri, 19 May 2023 at 1:31 PM Raul Miller wrote:
> The problem that this would address is the complexity of figuring out
> where a project has been deployed.
>
> Yes, it's true that we can install from github. But to test that we
> have supported that we need the project installed in a different
> location.
>
> And, yes, this is entirely solvable. But it's not easily solvable,
> especially on the part of new users.
>
> Why should this be difficult?
>
> Thanks,
>
> --
> Raul
>
>
> On Thu, May 18, 2023 at 6:59 PM chris burke wrote:
> >
> > Suggestions like this come up from time to time, but I think they are
> > mistaken. We already have a mechanism for naming files outside
> > standard J directories, see
> > https://code.jsoftware.com/wiki/Guides/Folders_and_Projects . I don't
> > think anything else is needed, rather any extra mechanism will add
> > unnecessary complexity.
> >
> > I'd recommend becoming thoroughly familiar with what we already have.
> Thanks!
> >
> > On Thu, May 18, 2023 at 8:59 AM Raul Miller
> wrote:
> > >
> > > Quite often, we might want to work with collections of J scripts which
> > > are outside the standard J system and user directories.
> > >
> > > It's quite possible, though obscure, to use introspection (4!:4 and
> > > 4!:3) to locate scripts relative to the currently executing script.
> > >
> > > It would probably be better to make this be an explicitly supported
> > > feature of J's load verb.
> > >
> > > Specifically, I would like to propose that while load is executing,
> > > jpath would expand ~dir/ to be the innermost referenced directory of
> > > the currently executing load.
> > >
> > > In other words:something like
> > >
> > > load=: {{
> > > 0 load y
> > > :
> > > fls=. getscripts_j_ y
> > > fn=. ('script',x#'d')~
> > > for_fl. fls do.
> > > SystemFolders_j_=: SystemFolders_j_,~ 'dir';fpath_j_;fl
> > > if. Displayload_j_ do. echo;fl end.
> > > if. -. fexist fl do.
> > > echo 'not found: ',;fl
> > > end.
> > > fn fl
> > > SystemFolders_j_=: (<<<({."1 SystemFolders_j_)i.<'dir') {
> SystemFolders_j_
> > > Loaded_j_=: ~. Loaded_j_,fl
> > > end.
> > > EMPTY
> > > }}
> > >
> > > Thoughts? Objections? Improvements?
> > >
> > > Thanks,
> > >
> > > --
> > > Raul
> > > --
> > > 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
Re: [Jgeneral] recursive load (and jpath)
The problem that this would address is the complexity of figuring out
where a project has been deployed.
Yes, it's true that we can install from github. But to test that we
have supported that we need the project installed in a different
location.
And, yes, this is entirely solvable. But it's not easily solvable,
especially on the part of new users.
Why should this be difficult?
Thanks,
--
Raul
On Thu, May 18, 2023 at 6:59 PM chris burke wrote:
>
> Suggestions like this come up from time to time, but I think they are
> mistaken. We already have a mechanism for naming files outside
> standard J directories, see
> https://code.jsoftware.com/wiki/Guides/Folders_and_Projects . I don't
> think anything else is needed, rather any extra mechanism will add
> unnecessary complexity.
>
> I'd recommend becoming thoroughly familiar with what we already have. Thanks!
>
> On Thu, May 18, 2023 at 8:59 AM Raul Miller wrote:
> >
> > Quite often, we might want to work with collections of J scripts which
> > are outside the standard J system and user directories.
> >
> > It's quite possible, though obscure, to use introspection (4!:4 and
> > 4!:3) to locate scripts relative to the currently executing script.
> >
> > It would probably be better to make this be an explicitly supported
> > feature of J's load verb.
> >
> > Specifically, I would like to propose that while load is executing,
> > jpath would expand ~dir/ to be the innermost referenced directory of
> > the currently executing load.
> >
> > In other words:something like
> >
> > load=: {{
> > 0 load y
> > :
> > fls=. getscripts_j_ y
> > fn=. ('script',x#'d')~
> > for_fl. fls do.
> > SystemFolders_j_=: SystemFolders_j_,~ 'dir';fpath_j_;fl
> > if. Displayload_j_ do. echo;fl end.
> > if. -. fexist fl do.
> > echo 'not found: ',;fl
> > end.
> > fn fl
> > SystemFolders_j_=: (<<<({."1 SystemFolders_j_)i.<'dir') {
> > SystemFolders_j_
> > Loaded_j_=: ~. Loaded_j_,fl
> > end.
> > EMPTY
> > }}
> >
> > Thoughts? Objections? Improvements?
> >
> > Thanks,
> >
> > --
> > Raul
> > --
> > 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
Re: [Jgeneral] recursive load (and jpath)
Suggestions like this come up from time to time, but I think they are
mistaken. We already have a mechanism for naming files outside
standard J directories, see
https://code.jsoftware.com/wiki/Guides/Folders_and_Projects . I don't
think anything else is needed, rather any extra mechanism will add
unnecessary complexity.
I'd recommend becoming thoroughly familiar with what we already have. Thanks!
On Thu, May 18, 2023 at 8:59 AM Raul Miller wrote:
>
> Quite often, we might want to work with collections of J scripts which
> are outside the standard J system and user directories.
>
> It's quite possible, though obscure, to use introspection (4!:4 and
> 4!:3) to locate scripts relative to the currently executing script.
>
> It would probably be better to make this be an explicitly supported
> feature of J's load verb.
>
> Specifically, I would like to propose that while load is executing,
> jpath would expand ~dir/ to be the innermost referenced directory of
> the currently executing load.
>
> In other words:something like
>
> load=: {{
> 0 load y
> :
> fls=. getscripts_j_ y
> fn=. ('script',x#'d')~
> for_fl. fls do.
> SystemFolders_j_=: SystemFolders_j_,~ 'dir';fpath_j_;fl
> if. Displayload_j_ do. echo;fl end.
> if. -. fexist fl do.
> echo 'not found: ',;fl
> end.
> fn fl
> SystemFolders_j_=: (<<<({."1 SystemFolders_j_)i.<'dir') { SystemFolders_j_
> Loaded_j_=: ~. Loaded_j_,fl
> end.
> EMPTY
> }}
>
> Thoughts? Objections? Improvements?
>
> Thanks,
>
> --
> Raul
> --
> For information about J forums see http://www.jsoftware.com/forums.htm
--
For information about J forums see http://www.jsoftware.com/forums.htm
[Jgeneral] recursive load (and jpath)
Quite often, we might want to work with collections of J scripts which
are outside the standard J system and user directories.
It's quite possible, though obscure, to use introspection (4!:4 and
4!:3) to locate scripts relative to the currently executing script.
It would probably be better to make this be an explicitly supported
feature of J's load verb.
Specifically, I would like to propose that while load is executing,
jpath would expand ~dir/ to be the innermost referenced directory of
the currently executing load.
In other words:something like
load=: {{
0 load y
:
fls=. getscripts_j_ y
fn=. ('script',x#'d')~
for_fl. fls do.
SystemFolders_j_=: SystemFolders_j_,~ 'dir';fpath_j_;fl
if. Displayload_j_ do. echo;fl end.
if. -. fexist fl do.
echo 'not found: ',;fl
end.
fn fl
SystemFolders_j_=: (<<<({."1 SystemFolders_j_)i.<'dir') { SystemFolders_j_
Loaded_j_=: ~. Loaded_j_,fl
end.
EMPTY
}}
Thoughts? Objections? Improvements?
Thanks,
--
Raul
--
For information about J forums see http://www.jsoftware.com/forums.htm
