[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: pkg.m status and question

From: Philip Nienhuis
Subject: Re: pkg.m status and question
Date: Tue, 7 Jan 2020 18:18:01 +0100
User-agent: Mozilla/5.0 (Windows NT 6.1; rv:52.0) Gecko/20100101 Firefox/52.0

Mike Miller wrote:
On Mon, Jan 06, 2020 at 23:44:24 +0100, Philip Nienhuis wrote:
We need a basic struct with all required fields that are of the same type
for all packages.
All fields that are heterogeneous (not required for each package and/or not
used by the package manager) go in substructs or cell arrays in a dedicated
field of the main struct. That way we move heterogeneity from the outside
wrapper into a much less prominent location inside, out of the way of
regular package manager operations.

This seems unnecessarily awkward for the task at hand. Are you
suggesting a package description struct might be accessed like this

     d = pkg ("list", "foo")

or like this

     for i = 1:length (d.optionalfields)

Does it really seem like a worthwhile tradeoff to introduce a new nested
struct or array of optional properties just to have a fixed base
structure definition that can be stored in an array? No, that seems even
more complicated to me. This is software, after all, not a packet
> I guess internally you can store it however you feel is best, but the
> user should have access to an easy flat structure that contains all of
> the package metadata, both required and optional, as it is now.

I suppose that you refer to the output of the pkg.m function, not so much the contents of the octave_packages files, right? AFAIU the latter aren't meant to be edited so can be v7 formats as well and their internal setup shouldn't matter to the average user.

Did you look at e.g., 'out = pkg ("describe")'?
The result is another seemingly (to me) needlessly complicated datastructure: a cell array of structs, each of such a struct again containing some fields comprising cell arrays of structs. E.g., a small part of the zeromq entry of above command's output in my mxe-octave installation:

  [1,48] =
    scalar structure containing the fields:
      name = zeromq
      version = 1.5.0
      description = ZeroMQ bindings for GNU Octave
      depends =
        [1,1] =
          scalar structure containing the fields:
            package = octave
            operator = >=
            version = 4.0.0
      provides =
        [1,1] =
          scalar structure containing the fields:
            category = ZeroMQ overview
            functions =
              [1,1] = zeromq

Your wish to keep a flat data structure triggers my curiosity: what is the use case of having a flat output structure? Why is that needed? IMO any user who needs to access pkg.m's output should be proficient enough to grasp nested data structure.

Anyway, no fear, I'm not planning to start hacking deeply into pkg.m soon. I'm just investigating, ATM just out of curiosity.

When and if the time comes it's easy to leave the output package info cellstructs as they are and add translation routines from a programmatically more manageable data struct.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]