What about labs?

Thanks,

-- 
Raul


On Mon, Jul 6, 2015 at 7:42 AM, chris burke <[email protected]> wrote:
>> Now... there are of course arguments against automatically installing
> software. What if J isn't internet connected?
>
> Each package manifest should include its dependencies in the DEPENDS noun,
> and these will be installed if necessary when the package is installed. It
> would be better that these were defined correctly than trying to install
> software automatically when a package is loaded.
>
> On 6 July 2015 at 02:02, Raul Miller <[email protected]> wrote:
>
>> 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

Reply via email to