[Jgeneral] Comments on J9.04 Reference Page 2
In "Modifier trains", 'N V1 V0' should yield 'N V1 (V0 y)'. [That 'N' could be
'x'.]
The absence of y, u, and v from the left column requires substantial study by a
new reader, in the absence of a footnote explaining the format.
In "Conjunctions", the second column should show 'x' and 'y' wherever they are
permitted, for uniformity of recognition and interpretation.
'].' ought to be in red.
For 'x u^:_ y', could say 'apply x& u til convergence'.
Footnotes in "Memory operations" are incomplete.
In "Mathematics", Footnote (a) is not clear, partly since neither u nor v
appear in the example.
The table for 'b.' is missing a bar between '33' and '34'.
The "Multithreading" table, and the NuVoc descriptions, need more detail for
this new type of control.
In "Objects and locatives", Footnote (b) mentions 'o', which has no reference.
I presume that 'x myverb__obj y' means 'run myverb, from locale obj, on y'.
That line should be moved three lines lower.
What effect do 'x' and 'y' have in the last line?
In "Control structures", the various blocks should all be numbered, since not
referring to a single footnoted value.
Footnote (a) could end '... result of [the] last sentence executed'.
Footnote (b) could read '... tests true: if ...'.
Footnote (d) could read 'Arbitrary local names var ...'.
The reference to Footnote (e) inserts a misleading space before 'case.'; it
would be better following 'case.'. The optionality and purpose of the 'f' need
explanation.
To avoid ambiguity, Footnote (h) should read 'Abort current iteration.'
Final line's shading ends short.
In "Explicit definition and assignment", first line could read '{{ text lines
}}' to emphasize structure. The comment could read 'direct explicit entity' to
aid in finding related pages.
In lines 3 and 4, 'verb' is accurate for the example, but 'object' would be
general.
In line 5, 'equivalent' should be 'verb'.
Footnote (i) could say '... a string of space- or comma-separated names.'.
That phrase should also be referenced two lines earlier.
--Art
--
For information about J forums see http://www.jsoftware.com/forums.htm
Re: [Jgeneral] i. into the middle of an array.
Note that by going to tacit you have repeated the first search.
It does make a good advert for virtual blocks.
Henry Rich
On 8/26/2022 5:27 PM, Devon McCormick wrote:
I get these timings on J 9.04:
A=. ?1e8#1e3
ts '100 find2 A'
2.4e_6 1536
ts '100 (1{I.@E.) A'
0.19722 8.39853e6
ts '100 ({.@}.@(I.@E.)) A'
0.200139 8.39866e6
(100 find2 A) -: 100 (1{I.@E.) A
1
find2
([: >: i.~) + [ i.~ ] }.~ [: >: i.~
On Fri, Aug 26, 2022 at 3:53 PM 'Mike Day' via General <
gene...@jsoftware.com> wrote:
Does that include drop, }. ? I suppose it can, since we only need to
move the pointer to the start... I’ll check on the laptop, once I’ve done
my Listener xwd.
(Last week’s was the quarterly numeric puzzle, an ingenious construction
including among all the digits a few decimal points and solidus ( / ) for
rationals!)
Cheers,
Mike
Sent from my iPad
On 26 Aug 2022, at 20:36, Raul Miller wrote:
Updating arrays without generating a new copy was introduce in J805 --
https://code.jsoftware.com/wiki/System/ReleaseNotes/J805
So in J701, that approach would indeed be slower (since it's creating
a complete copy of the array).
Also, virtual blocks (which speed up the }. approach) were introduced
in J807. I guess I need to roll up my sleeves and do some
benchmarking...
Thanks,
--
Raul
On Fri, Aug 26, 2022 at 3:20 PM 'Mike Day' via General
wrote:
These seem simpler and are possibly quicker, at least in J701 on this
oldish iPad:
100 (1{I.@E.) A NB. Fails if there’s no (second) 100 in A
719
100 ({.@}.@(I.@E.)) A NB. Returns 0 in that case
719
Easy to correct for such errors, of course.
I tried
A =. ?100#1000
find2 =: 13 : 'F + ((F=.>:y i. x) }. y) i. x' NB. No direct defs in
J701
ts'100 find2 A'
0.020555 8.39091e6
ts'100 (1{I.@E.) A'
0.011503 76160
ts'100 ({.@}.@(I.@E.)) A'
0.007626 84864
Speed a bit better, space quite a lot, if happy with time & space
tests.
Only you know if it’s wise to overwrite the first occurrence of V in A!
Cheers,
Mike
Sent from my iPad
On 26 Aug 2022, at 19:36, Raul Miller wrote:
i. returns the index of the first occurrence of a value within an
array.
So, when implementing an algorithm which needs the index of the second
occurrence of the value within a (large) array, we need to do some
additional work.
let's say that our array is A, the value is V
F=: A i. V NB. the index of the first occurrence of V
What's the most efficient way of finding the second occurrence?
One possibility is
S=: (1+F) + ((1+F) }. A) i. V
Another possibility, assuming that V is numeric and not zero, would be
S=: (0 F} A) i. V
But A is large, so perhaps a faster approach would be:
S=: {{ while. V~:y{A do. y=. y+1 end. y }} F
(Which has me wishing that S=: A i.!.F V would do the job, though I'm
not sure that that's completely appropriate...)
But, we can probably eliminate the need to generate a copy of A with a
little extra work:
A=: 0 F} A
S=: A i. V
A=: V F} A
It seems to me that this is probably going to be the fastest approach.
Can anyone think of a faster approach (or something with comparable
speed which isn't quite so unwieldy?)
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] i. into the middle of an array.
I get these timings on J 9.04:
A=. ?1e8#1e3
ts '100 find2 A'
2.4e_6 1536
ts '100 (1{I.@E.) A'
0.19722 8.39853e6
ts '100 ({.@}.@(I.@E.)) A'
0.200139 8.39866e6
(100 find2 A) -: 100 (1{I.@E.) A
1
find2
([: >: i.~) + [ i.~ ] }.~ [: >: i.~
On Fri, Aug 26, 2022 at 3:53 PM 'Mike Day' via General <
gene...@jsoftware.com> wrote:
> Does that include drop, }. ? I suppose it can, since we only need to
> move the pointer to the start... I’ll check on the laptop, once I’ve done
> my Listener xwd.
>
> (Last week’s was the quarterly numeric puzzle, an ingenious construction
> including among all the digits a few decimal points and solidus ( / ) for
> rationals!)
>
> Cheers,
> Mike
>
>
>
> Sent from my iPad
>
> > On 26 Aug 2022, at 20:36, Raul Miller wrote:
> >
> > Updating arrays without generating a new copy was introduce in J805 --
> > https://code.jsoftware.com/wiki/System/ReleaseNotes/J805
> >
> > So in J701, that approach would indeed be slower (since it's creating
> > a complete copy of the array).
> >
> > Also, virtual blocks (which speed up the }. approach) were introduced
> > in J807. I guess I need to roll up my sleeves and do some
> > benchmarking...
> >
> > Thanks,
> >
> > --
> > Raul
> >
> > On Fri, Aug 26, 2022 at 3:20 PM 'Mike Day' via General
> > wrote:
> >>
> >> These seem simpler and are possibly quicker, at least in J701 on this
> oldish iPad:
> >> 100 (1{I.@E.) A NB. Fails if there’s no (second) 100 in A
> >> 719
> >> 100 ({.@}.@(I.@E.)) A NB. Returns 0 in that case
> >> 719
> >> Easy to correct for such errors, of course.
> >>
> >> I tried
> >> A =. ?100#1000
> >> find2 =: 13 : 'F + ((F=.>:y i. x) }. y) i. x' NB. No direct defs in
> J701
> >> ts'100 find2 A'
> >> 0.020555 8.39091e6
> >> ts'100 (1{I.@E.) A'
> >> 0.011503 76160
> >> ts'100 ({.@}.@(I.@E.)) A'
> >> 0.007626 84864
> >>
> >> Speed a bit better, space quite a lot, if happy with time & space
> tests.
> >>
> >> Only you know if it’s wise to overwrite the first occurrence of V in A!
> >>
> >> Cheers,
> >>
> >> Mike
> >>
> >>
> >>
> >> Sent from my iPad
> >>
> >>> On 26 Aug 2022, at 19:36, Raul Miller wrote:
> >>>
> >>> i. returns the index of the first occurrence of a value within an
> array.
> >>>
> >>> So, when implementing an algorithm which needs the index of the second
> >>> occurrence of the value within a (large) array, we need to do some
> >>> additional work.
> >>>
> >>> let's say that our array is A, the value is V
> >>>
> >>> F=: A i. V NB. the index of the first occurrence of V
> >>>
> >>> What's the most efficient way of finding the second occurrence?
> >>>
> >>> One possibility is
> >>> S=: (1+F) + ((1+F) }. A) i. V
> >>>
> >>> Another possibility, assuming that V is numeric and not zero, would be
> >>> S=: (0 F} A) i. V
> >>>
> >>> But A is large, so perhaps a faster approach would be:
> >>> S=: {{ while. V~:y{A do. y=. y+1 end. y }} F
> >>>
> >>> (Which has me wishing that S=: A i.!.F V would do the job, though I'm
> >>> not sure that that's completely appropriate...)
> >>>
> >>> But, we can probably eliminate the need to generate a copy of A with a
> >>> little extra work:
> >>>
> >>> A=: 0 F} A
> >>> S=: A i. V
> >>> A=: V F} A
> >>>
> >>> It seems to me that this is probably going to be the fastest approach.
> >>>
> >>> Can anyone think of a faster approach (or something with comparable
> >>> speed which isn't quite so unwieldy?)
> >>>
> >>> 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
>
--
Devon McCormick, CFA
Quantitative Consultant
--
For information about J forums see http://www.jsoftware.com/forums.htm
Re: [Jgeneral] i. into the middle of an array.
Does that include drop, }. ? I suppose it can, since we only need to move the
pointer to the start... I’ll check on the laptop, once I’ve done my Listener
xwd.
(Last week’s was the quarterly numeric puzzle, an ingenious construction
including among all the digits a few decimal points and solidus ( / ) for
rationals!)
Cheers,
Mike
Sent from my iPad
> On 26 Aug 2022, at 20:36, Raul Miller wrote:
>
> Updating arrays without generating a new copy was introduce in J805 --
> https://code.jsoftware.com/wiki/System/ReleaseNotes/J805
>
> So in J701, that approach would indeed be slower (since it's creating
> a complete copy of the array).
>
> Also, virtual blocks (which speed up the }. approach) were introduced
> in J807. I guess I need to roll up my sleeves and do some
> benchmarking...
>
> Thanks,
>
> --
> Raul
>
> On Fri, Aug 26, 2022 at 3:20 PM 'Mike Day' via General
> wrote:
>>
>> These seem simpler and are possibly quicker, at least in J701 on this
>> oldish iPad:
>> 100 (1{I.@E.) A NB. Fails if there’s no (second) 100 in A
>> 719
>> 100 ({.@}.@(I.@E.)) A NB. Returns 0 in that case
>> 719
>> Easy to correct for such errors, of course.
>>
>> I tried
>> A =. ?100#1000
>> find2 =: 13 : 'F + ((F=.>:y i. x) }. y) i. x' NB. No direct defs in J701
>> ts'100 find2 A'
>> 0.020555 8.39091e6
>> ts'100 (1{I.@E.) A'
>> 0.011503 76160
>> ts'100 ({.@}.@(I.@E.)) A'
>> 0.007626 84864
>>
>> Speed a bit better, space quite a lot, if happy with time & space tests.
>>
>> Only you know if it’s wise to overwrite the first occurrence of V in A!
>>
>> Cheers,
>>
>> Mike
>>
>>
>>
>> Sent from my iPad
>>
>>> On 26 Aug 2022, at 19:36, Raul Miller wrote:
>>>
>>> i. returns the index of the first occurrence of a value within an array.
>>>
>>> So, when implementing an algorithm which needs the index of the second
>>> occurrence of the value within a (large) array, we need to do some
>>> additional work.
>>>
>>> let's say that our array is A, the value is V
>>>
>>> F=: A i. V NB. the index of the first occurrence of V
>>>
>>> What's the most efficient way of finding the second occurrence?
>>>
>>> One possibility is
>>> S=: (1+F) + ((1+F) }. A) i. V
>>>
>>> Another possibility, assuming that V is numeric and not zero, would be
>>> S=: (0 F} A) i. V
>>>
>>> But A is large, so perhaps a faster approach would be:
>>> S=: {{ while. V~:y{A do. y=. y+1 end. y }} F
>>>
>>> (Which has me wishing that S=: A i.!.F V would do the job, though I'm
>>> not sure that that's completely appropriate...)
>>>
>>> But, we can probably eliminate the need to generate a copy of A with a
>>> little extra work:
>>>
>>> A=: 0 F} A
>>> S=: A i. V
>>> A=: V F} A
>>>
>>> It seems to me that this is probably going to be the fastest approach.
>>>
>>> Can anyone think of a faster approach (or something with comparable
>>> speed which isn't quite so unwieldy?)
>>>
>>> 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] i. into the middle of an array.
Updating arrays without generating a new copy was introduce in J805 --
https://code.jsoftware.com/wiki/System/ReleaseNotes/J805
So in J701, that approach would indeed be slower (since it's creating
a complete copy of the array).
Also, virtual blocks (which speed up the }. approach) were introduced
in J807. I guess I need to roll up my sleeves and do some
benchmarking...
Thanks,
--
Raul
On Fri, Aug 26, 2022 at 3:20 PM 'Mike Day' via General
wrote:
>
> These seem simpler and are possibly quicker, at least in J701 on this oldish
> iPad:
>100 (1{I.@E.) A NB. Fails if there’s no (second) 100 in A
> 719
>100 ({.@}.@(I.@E.)) A NB. Returns 0 in that case
> 719
> Easy to correct for such errors, of course.
>
> I tried
>A =. ?100#1000
>find2 =: 13 : 'F + ((F=.>:y i. x) }. y) i. x' NB. No direct defs in J701
>ts'100 find2 A'
> 0.020555 8.39091e6
>ts'100 (1{I.@E.) A'
> 0.011503 76160
>ts'100 ({.@}.@(I.@E.)) A'
> 0.007626 84864
>
> Speed a bit better, space quite a lot, if happy with time & space tests.
>
> Only you know if it’s wise to overwrite the first occurrence of V in A!
>
> Cheers,
>
> Mike
>
>
>
> Sent from my iPad
>
> > On 26 Aug 2022, at 19:36, Raul Miller wrote:
> >
> > i. returns the index of the first occurrence of a value within an array.
> >
> > So, when implementing an algorithm which needs the index of the second
> > occurrence of the value within a (large) array, we need to do some
> > additional work.
> >
> > let's say that our array is A, the value is V
> >
> > F=: A i. V NB. the index of the first occurrence of V
> >
> > What's the most efficient way of finding the second occurrence?
> >
> > One possibility is
> > S=: (1+F) + ((1+F) }. A) i. V
> >
> > Another possibility, assuming that V is numeric and not zero, would be
> > S=: (0 F} A) i. V
> >
> > But A is large, so perhaps a faster approach would be:
> > S=: {{ while. V~:y{A do. y=. y+1 end. y }} F
> >
> > (Which has me wishing that S=: A i.!.F V would do the job, though I'm
> > not sure that that's completely appropriate...)
> >
> > But, we can probably eliminate the need to generate a copy of A with a
> > little extra work:
> >
> > A=: 0 F} A
> > S=: A i. V
> > A=: V F} A
> >
> > It seems to me that this is probably going to be the fastest approach.
> >
> > Can anyone think of a faster approach (or something with comparable
> > speed which isn't quite so unwieldy?)
> >
> > 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] i. into the middle of an array.
These seem simpler and are possibly quicker, at least in J701 on this oldish
iPad:
100 (1{I.@E.) A NB. Fails if there’s no (second) 100 in A
719
100 ({.@}.@(I.@E.)) A NB. Returns 0 in that case
719
Easy to correct for such errors, of course.
I tried
A =. ?100#1000
find2 =: 13 : 'F + ((F=.>:y i. x) }. y) i. x' NB. No direct defs in J701
ts'100 find2 A'
0.020555 8.39091e6
ts'100 (1{I.@E.) A'
0.011503 76160
ts'100 ({.@}.@(I.@E.)) A'
0.007626 84864
Speed a bit better, space quite a lot, if happy with time & space tests.
Only you know if it’s wise to overwrite the first occurrence of V in A!
Cheers,
Mike
Sent from my iPad
> On 26 Aug 2022, at 19:36, Raul Miller wrote:
>
> i. returns the index of the first occurrence of a value within an array.
>
> So, when implementing an algorithm which needs the index of the second
> occurrence of the value within a (large) array, we need to do some
> additional work.
>
> let's say that our array is A, the value is V
>
> F=: A i. V NB. the index of the first occurrence of V
>
> What's the most efficient way of finding the second occurrence?
>
> One possibility is
> S=: (1+F) + ((1+F) }. A) i. V
>
> Another possibility, assuming that V is numeric and not zero, would be
> S=: (0 F} A) i. V
>
> But A is large, so perhaps a faster approach would be:
> S=: {{ while. V~:y{A do. y=. y+1 end. y }} F
>
> (Which has me wishing that S=: A i.!.F V would do the job, though I'm
> not sure that that's completely appropriate...)
>
> But, we can probably eliminate the need to generate a copy of A with a
> little extra work:
>
> A=: 0 F} A
> S=: A i. V
> A=: V F} A
>
> It seems to me that this is probably going to be the fastest approach.
>
> Can anyone think of a faster approach (or something with comparable
> speed which isn't quite so unwieldy?)
>
> 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] i. into the middle of an array.
i. returns the index of the first occurrence of a value within an array.
So, when implementing an algorithm which needs the index of the second
occurrence of the value within a (large) array, we need to do some
additional work.
let's say that our array is A, the value is V
F=: A i. V NB. the index of the first occurrence of V
What's the most efficient way of finding the second occurrence?
One possibility is
S=: (1+F) + ((1+F) }. A) i. V
Another possibility, assuming that V is numeric and not zero, would be
S=: (0 F} A) i. V
But A is large, so perhaps a faster approach would be:
S=: {{ while. V~:y{A do. y=. y+1 end. y }} F
(Which has me wishing that S=: A i.!.F V would do the job, though I'm
not sure that that's completely appropriate...)
But, we can probably eliminate the need to generate a copy of A with a
little extra work:
A=: 0 F} A
S=: A i. V
A=: V F} A
It seems to me that this is probably going to be the fastest approach.
Can anyone think of a faster approach (or something with comparable
speed which isn't quite so unwieldy?)
Thanks,
--
Raul
--
For information about J forums see http://www.jsoftware.com/forums.htm
Re: [Jgeneral] Thought experiment -- pacman
On Fri, Aug 26, 2022 at 9:57 AM chris burke wrote: > I agree it makes sense to support more hosting repos. The relevant > pacman code is under https://github.com/jsoftware/base9, in particular > see gitrepo.ijs. > > Perhaps the info in the proposed ~user/config/user-addons.txt would be > better in ~addons/config, either as a new file or extra info in > addins.txt? Hmm... At the very least, I'd want to preserve the caption and description, because that's what's displayed in pacman's UI. But we do need the repo, also. It's probably not a problem to store the information in ~addons/config. Thanks, -- Raul -- For information about J forums see http://www.jsoftware.com/forums.htm
Re: [Jgeneral] Thought experiment -- pacman
I agree it makes sense to support more hosting repos. The relevant pacman code is under https://github.com/jsoftware/base9, in particular see gitrepo.ijs. Perhaps the info in the proposed ~user/config/user-addons.txt would be better in ~addons/config, either as a new file or extra info in addins.txt? On Fri, Aug 26, 2022 at 5:28 AM Raul Miller wrote: > > On Fri, Aug 26, 2022 at 1:22 AM 'Viktor Grigorov' via General > wrote: > > There's bitbucket.org, codeberg.org, gitlab.com, sr.ht, gitea.io, among > > others. (They don't also arguably illegaly feed your code to their > > commercial products.) There can't not exist some way to test whether or not > > a URI points to a repository. Most, if not all use have a suffix of > > 'username/repositoryname', you could make a fall-through case of github if > > no explicit domain is given. > > I'm not too worried about J addons "appearing illegally in commercial > products" as a risk model (at least, not this year, for a variety of > reasons). I'm far more concerned with the availability of at least one > J addon hosted publicly at the repository. > > (I guess adding support for private repositories might be worth > doing... But using the repository's shell tools should be adequate if > you're at that level of involvement with a project. And ironically > that would be a much bigger project than what I've proposed here.) > > > That said, one could easily manage updates with a short shell script: go to > > plugins dir, sequentially cd and pull --rebase. I don't use any myself, so > > I'm unfamilar with what pacman can do exclusively. My 2c. > > pacman uses the repository's web interface and the "raw" url structure > to retrieve the files (starting with manifest.ijs), bypassing git's > shell command tools entirely. > > An addon, in this context, is the repository identifier (which is, in > essence, the "protocol" because this defines the url structure), the > user's account name (which becomes the name of the containing > directory under J's addons directory), and the project name (which > becomes the directory name within that account name directory). The > addon must have a manifest.ijs at the top level of the project, and > this identifies all other files within the addon (which are the only > files retrieved by J -- so, no git history). See also: > https://code.jsoftware.com/wiki/Addons/Developers_Guide > > However, as you say, bypassing pacman altogether and installing the > archive outside of J -- including using git itself -- would be an > option for people inclined to work that way. This approach might be > convenient when *developing* an addon (though it has the minor > downside of requiring a second install of J if the J developer wants > to test that pacman installs the package properly -- that said... > personally, I like organizing my primary copies of hosted repositories > in a directory named for the repository hosting site). > > Anyways... I guess the focus I'm taking from all of this is that > perhaps my proposed user addons.txt should be named "user-addons.txt" > to make it independent from the repository name, in the event that > people are interested in hosting J addons in some other repository. > > Also, expanding the current pacman github support should be relatively > straightforward. Basically, it would be adding another repo with a > slightly different raw url structure. > > 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
Re: [Jgeneral] Thought experiment -- pacman
On Fri, Aug 26, 2022 at 1:22 AM 'Viktor Grigorov' via General wrote: > There's bitbucket.org, codeberg.org, gitlab.com, sr.ht, gitea.io, among > others. (They don't also arguably illegaly feed your code to their commercial > products.) There can't not exist some way to test whether or not a URI points > to a repository. Most, if not all use have a suffix of > 'username/repositoryname', you could make a fall-through case of github if no > explicit domain is given. I'm not too worried about J addons "appearing illegally in commercial products" as a risk model (at least, not this year, for a variety of reasons). I'm far more concerned with the availability of at least one J addon hosted publicly at the repository. (I guess adding support for private repositories might be worth doing... But using the repository's shell tools should be adequate if you're at that level of involvement with a project. And ironically that would be a much bigger project than what I've proposed here.) > That said, one could easily manage updates with a short shell script: go to > plugins dir, sequentially cd and pull --rebase. I don't use any myself, so > I'm unfamilar with what pacman can do exclusively. My 2c. pacman uses the repository's web interface and the "raw" url structure to retrieve the files (starting with manifest.ijs), bypassing git's shell command tools entirely. An addon, in this context, is the repository identifier (which is, in essence, the "protocol" because this defines the url structure), the user's account name (which becomes the name of the containing directory under J's addons directory), and the project name (which becomes the directory name within that account name directory). The addon must have a manifest.ijs at the top level of the project, and this identifies all other files within the addon (which are the only files retrieved by J -- so, no git history). See also: https://code.jsoftware.com/wiki/Addons/Developers_Guide However, as you say, bypassing pacman altogether and installing the archive outside of J -- including using git itself -- would be an option for people inclined to work that way. This approach might be convenient when *developing* an addon (though it has the minor downside of requiring a second install of J if the J developer wants to test that pacman installs the package properly -- that said... personally, I like organizing my primary copies of hosted repositories in a directory named for the repository hosting site). Anyways... I guess the focus I'm taking from all of this is that perhaps my proposed user addons.txt should be named "user-addons.txt" to make it independent from the repository name, in the event that people are interested in hosting J addons in some other repository. Also, expanding the current pacman github support should be relatively straightforward. Basically, it would be adding another repo with a slightly different raw url structure. Thanks, -- Raul -- For information about J forums see http://www.jsoftware.com/forums.htm
