That solution works well for me, but as with the current state of dissect/jbyexample, the forum blows up with issues, where the best guess for a solution is "did you follow instructions to upgrade to latest"
If there was a programatic process to even check for minimum jqt version (even if restart necessary, or restart automated) and other addon versions. Specs would include (mostly because there exists at least one person uncomfortable with automatic installs): Recommend that your application has a "master file" that is intended to be a single load point. The application makes a single call to check all relevant package versions. If any files/packages in list are missing, then a version of the pacman gui is shown, with a list of package install/updates where the updates that are required are ticked, and updates where the version is adequate, but a newer package exists are listed but unticked. ideally, jqt updates are integrated into pacman, but a workaround is that the master file would launch the update batch file, and the update batch file is updated to call J with a file after the update, and so the master file could reload itself after jqt update, and do the pacman check on the next call. Another simple pacman integration would be "A newer version of Jqt library is available click here to install it and autoRESTART". Basically this is useful if we assume app publishers have the lastest jqt, but don't know if that version is actually required or not, unless they do the impossible backtest to every previous Jqt version. If install 'all' is always the best solution, then jqt could have an option on startup that automatically does so, or simpler, an extra batchfile called jqtwithupdate.cmd ----- Original Message ----- From: bill lam <[email protected]> To: General forum <[email protected]> Cc: Sent: Monday, July 6, 2015 11:08 AM Subject: Re: [Jgeneral] inconsistent package conventions 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 ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
