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 <[email protected]> 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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> > 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 <[email protected]> > 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 <[email protected]> > 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 <[email protected]> > 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 < > [email protected]> 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 < > [email protected]> 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 < > [email protected]> > > > > > > >> 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 > > > > > ---------------------------------------------------------------------- > > > > 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
