It seems like we are approaching a consistent set of naming
conventions for pacman addons.
However, there are still some inconsistencies - where one part of the
system uses a different set of conventions from other parts of the
system and/or where one part of the system uses data structures which
are inconsistent with other parts of the system.
For example, currently, the definition of require is:
3 : 0
fls=. Loaded_j_ -.~ getscripts_j_ y
if. # fls do. load fls else. empty'' end.
)
If I change this to:
require=: 3 :0
try.
fls=. Loaded_j_ -.~ getscripts_j_ y
if. # fls do. load fls else. empty'' end.
catch.
require'pacman'
'update' jpkg ''
'install' jpkg y
load y
end.
)
It sort of works, but not completely:
require'debug/dissect stats'
not found: /applications/j64-804/addons/debug/dissect/dissect.ijs
Updating server catalog...
Installing 2 packages
Downloading debug/dissect...
Installing debug/dissect...
Downloading graphics/gl2...
Installing graphics/gl2...
Done.
not found: /applications/j64-804/addons/stats/base/base.ijs
|file name error: script
| 0!:0 y[4!:55<'y'
Now... there are of course arguments against automatically installing
software. What if J isn't internet connected? What if the user or the
machine or the account doesn't have permission to install? So there
are arguments against this specific implementation.
But at the same time, it seems as if the shorthands used in one one
context (require or install) should be valid in the other context.
Maybe not in this J release, but at some point...
This suggests that fullname_j_ defined in system/main/stdlib.ijs and
install_addon_jpacman_ and install_console_jpacman_ defined in
system/util/pacman.ijs should converge.
It seems like the easiest way to accomplish this would be to modify
readlocal_jpacman_ by adding the following statement:
ZIPS_jpacman_=: (fullname_j_&.> {."1 ZIPS_jpacman_) 0}"_1 ZIPS_jpacman_
And then use fullname_j_ when indexing into that first column of ZIPS.
I have not fully investigated the implications of this kind of change.
Perhaps it would also be that the second column of PKGDATA_jpacman_
should also be changed in this way?
And, of course, keywords such as 'all' would still need to be respected.
Still, the overhead seems slight (compared to the overhead of
downloading and unpacking the packages), and the conceptualization
seems consistent.
But would this break anything? (Does anything rely on exporting ZIPS
or PKGDATA? Do we have an appropriate inverse for fullname_j_?
Thoughts?
Thanks,
--
Raul
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
