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
## Copyright (C) 2012 Philip Nienhuis <prnienh...@users.sf.net>
## 
## This program is free software; you can redistribute it and/or modify
## it under the terms of the GNU General Public License as published by
## the Free Software Foundation; either version 3 of the License, or
## (at your option) any later version.
## 
## This program is distributed in the hope that it will be useful,
## but WITHOUT ANY WARRANTY; without even the implied warranty of
## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
## GNU General Public License for more details.
## 
## You should have received a copy of the GNU General Public License
## along with Octave; see the file COPYING.  If not, see
## <http://www.gnu.org/licenses/>.

## Get information about a package

## Created: 2012-03-26

function [ retval ] = pkg_info (varargin)

    ## Get list of packages
    [local_packages, global_packages] = pkg ("list");
    inst_pkgs = {local_packages{:}, global_packages{:}};

    ## Get pointer to pkg info
    if (nargin > 0 && ischar (varargin{1}))
      pkg_ptr = find (cellfun(@(x) strcmp (x.name, varargin{1}), inst_pkgs), 1, "first");
      if (isempty (pkg_ptr)); 
        retval = [];
        return
      endif
    else
      error ("pkg_info: character string expected as first argument (package name)");
    endif

    ## See what is requested
    if (nargin == 1)
      ## Entire info struct expected
      retval = inst_pkgs{pkg_ptr};
    else
      ## Just one field expected
      if (ischar (varargin{2}))
        if (isfield (inst_pkgs{pkg_ptr}, varargin{2}));
          retval = getfield (inst_pkgs{pkg_ptr}, varargin{2});
        else
          error ("pkg_info: unknown field - %s", varargin{2});
        endif
      else
        error ("pkg_info: character string expected as second argument (info field)");
      endif
    endif

endfunction
------------------------------------------------------------------------------
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

Reply via email to