On Mon, Mar 26, 2012 at 8:41 AM, Juan Pablo Carbajal
<carba...@ifi.uzh.ch> wrote:
> 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/
Bug corrected
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 = cell2struct (dir, {installed_names{idx(tf)}},2);
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
