I have not noticed any explosions. -- Raul
On Mon, Jul 6, 2015 at 11:49 AM, 'Pascal Jasmin' via General <[email protected]> wrote: > 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 ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
