On Mon, Mar 26, 2012 at 7:56 PM, Philip Nienhuis <pr.nienh...@hccnet.nl> wrote:
> Juan Pablo Carbajal wrote:
>>
>> 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
>
>
> I already made the pkg_info function I mentioned in an earlier post
> (attached); came in handy for my own purposes too. It doesn't accept cell
> args yet (to query multiple packages) but that might be added later.
>
> Using that, you can get the installation path to the arch-dependent folder
> (where the .oct files should live) using (for e.g., miscellaneous):
>
> p1 = pkg_info ("miscellaneous", "archprefix");
> p2 = octave_config_info ("canonical_host_type");
> p2 = octave_config_info ("api_version");
> arch_dep_fldr = [p1 filesep "-" p3];
>
> Philip
Hi,
Ok, that works fine for me. Can you push it into Octave?
We need it system wise available otherwise is not useful for the
installation of packages.
You can merge it with the function I sent around to accept cell arguments.
At any rate, we need to get it into Octave. Temporarily, we can use
the guts of your function to fix the PKG_ADD scripts in question.
Thanks
--
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
