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
