On Sun, Mar 25, 2012 at 10:11 PM, Philip Nienhuis <pr.nienh...@hccnet.nl> wrote:
> Juan Pablo Carbajal wrote:
>>
>> On Sun, Mar 25, 2012 at 5:16 PM, Philip Nienhuis<pr.nienh...@hccnet.nl>
>> wrote:
>>>
>>> Clemens Buchacher wrote:
>>>>
>>>>
>>>> On Sat, Mar 24, 2012 at 11:06:57PM +0100, Juan Pablo Carbajal wrote:
>>>>>
>>>>>
>>>>> On Sat, Mar 24, 2012 at 10:02 PM, Clemens Buchacher<dri...@aon.at>
>>>>> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> With svn r10045, I now get the following on load instead:
>>>>>>
>>>>>> warning: addpath: /home/drizzd/octave/geometry-1.4.2/geom2d: No such
>>>>>> file or directory
>>>>>> ...
>>>>>>
>>>>>> The problem is that the installation prefix is set only during
>>>>>> installation, but not during module load.
>>>>>>
>>>>>> The only way I can find to determine this path reliably is to create a
>>>>>> inst/geometry_module_path.m file which returns mfilename("fullpath").
>>>>>
>>>>>
>>>>>
>>>>> How does pkg knows the path to add in any other package when you use
>>>>> prefix?
>>>>
>>>>
>>>>
>>>> The path to the root package directory is added by octave. It is only
>>>> the subdirectories that are not accessible. I have the following other
>>>> packages, and none of those seem to add subdirectories to the
>>>> installation path:
>>>>
>>>> audio communications control data-smoothing general image io
>>>> linear-algebra
>>>> mechanics miscellaneous nan nnet octcdf optim plot queueing signal
>>>> specfun
>>>> splines statistics struct symbolic
>>>>
>>>> The io packages seems to parse the installation directory from
>>>> pkg('list')
>>>> output for different reasons, but I find this quite ugly:
>>>>
>>>> pkglist = pkg ("list");
>>>> javapkgind = find (cellfun(@(x) strcmp(x.name, "java"), pkglist), 1,
>>>> "first");
>>>
>>>
>>>
>>> (no offense taken) What is so ugly about it?
>>> (not that it's my code, yet to me it seems fairly succinct and AFAICS it
>>> works OK)
>>>
>>> FYI it doesn't parse package installation dirs at all. It simply handles
>>> a
>>> "suggested" dependency on another package, by checking if that other
>>> package
>>> is loaded. If so, the rest of PKG_ADD adds entries to the javaclasspath.
>>>
>>>
>>> Perhaps I missed the essentials from the discussion, but IMO somewhat
>>> analogous code could be invoked for adding pkg subdirs the "regular"
>>> search
>>> path in Octave, including arch-dependent ones. It would put the
>>> responsibility on developers/maintainers, but that's no big deal.
>>> If we let pkg maintainers setup PKG_ADD / PKG_DEL themselves along these
>>> lines, pkg.m could be kept simpler (it is already complicated enough).
>>> Some
>>> PKG_ADD/PKG_DEL example stanzas could be put on the OF developers page.
>>>
>>>
>>> I like the suggested pkg_ind() function, but I would rather have it more
>>> general along the lines of
>>>
>>> <info> = pkg_info (<package_name>, [<info_type>])
>>>
>>> which would return the entire info structure for just one arg (or [] if
>>> the
>>> package isn't found/installed/exist), and e.g.,
>>>
>>> <installation_dir> = pkg_info(<package_name>, "dir")
>>>
>>> for just one info field.
>>> That would help "de-uglify" the io pkg's PKG_ADD :-)
>>>
>>> Philip
>>
>>
>> Does this solves the problem with the arch dependent files? I think
>> like this you only get the path to the installation of the package but
>> not the compiled files, right?
>> We need to store this information somewhere at the time pkg("prefix")
>> is called. I think ~/.octave_packages could be used for this. It
>> already containts the installation folder, we need to add just one
>> field to the structure.
>
>
> For each package (with compiled functions at least) in the file
> octave_packages there is already the "archprefix" field, which points to the
> compiled functions. It only lacks the last bit to the actual .oct files
> (which AFAIU depend on the compiler version), but that can be gotten from
> octave_config_info() (I think we need to glue to fields from that together).
>
> Philip
So far we have the following function that works also with a query of
several packages as a cell, which can be handy. How do we get the
archpath? (the architecture dependent folder). Assuming that this
function will be called by PKG_ADD (and use mfilename to get it) could
be weak programming. *Note that the function uses cell2struct which is
in package struct, but it can be replaced with a cellfun call.
function [pkgpath archpath] = pkg_dir (pkgname)
[local_packages, global_packages] = pkg("list");
installed_pkgs_lst = {local_packages{:}, global_packages{:}};
installed_names = cellfun (@(x) x.name,
installed_pkgs_lst,'uniformoutput',false);
[tf idx] = ismember (pkgname,installed_names);
# Issue a warning with the unmatched pkgs ?
dir = cellfun (@(x) x.dir, {installed_pkgs_lst{idx(tf)}},'uniformoutput',false)
pkgpath = cell2fields (dir, {installed_names{idx(tf)}}, 1, struct ());
archpath = struct();
endfunction
--
M. Sc. Juan Pablo Carbajal
-----
PhD Student
University of Zürich
http://ailab.ifi.uzh.ch/carbajal/
------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
Octave-dev mailing list
Octave-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/octave-dev
