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
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
>
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
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
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
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
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
> 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
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
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
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
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
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
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
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
15 matches
Mail list logo
