IMO it is better to instruct newbie users to install all addons. 'install' jpkg 'all' or install 'all' On Jul 6, 2015 10:58 PM, "'Pascal Jasmin' via General" < [email protected]> wrote:
> that is an interesting function. In picking a name for it, perhaps > requireJsoftware. > > I'd agree that the world would be a nicer place if conventions on this > were consistent. > > An issue though, afaiu, is that dpkg can download a whole folder, whereas > require is file based. > > Still a workaround, if dpkg can grab a single file, then having nested > requireJsoftware calls within files would let users just do 1 'require' > call to grab all dependent files. > > > ----- Original Message ----- > From: Raul Miller <[email protected]> > To: General forum <[email protected]> > Cc: > Sent: Monday, July 6, 2015 2:02 AM > Subject: [Jgeneral] inconsistent package conventions > > 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 > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
