[Top][All Lists]

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

Re: File found by searching load path

From: Kai Torben Ohlhus
Subject: Re: File found by searching load path
Date: Fri, 7 Dec 2018 23:30:54 +0100

On Fri, Dec 7, 2018 at 9:21 PM Przemek Klosowski <address@hidden> wrote:
On 12/7/18 2:28 PM, Rik wrote:
> There is a new bug report #55173 which which shows, possibly, an irrelevant
> warning.
> octave:1> load penny.mat
> warning: load: '/usr/local/share/octave/5.0.0/data/penny.mat' found by
> searching load path
> I can see two approaches.  First, this warning has an ID,
> Octave:data-file-in-path, and we could change the default on Octave startup
> to disable this warning.  At that point, a user would have to actively turn
> on this warning to see it.
> Alternatively, I'm not sure why it is useful to know that the data file was
> found in the load path.  We could just remove the code entirely.
> Any votes one way or the other?

On the face of it, the warning is silly ("2+2 :  warning: addition:
result 4 found by applying the rules of arithmetic"). I think the intent
might have been to show the actual location of the file: I could see how
it might be useful to capture that, if 'load' allowed 2 return parameters :


where x is the dataset being read and f is the filename.

All output should be catchable : it's neat that you can do


for i=1:length(s)   printf("%s: %s\n",s{i}.name,s{i}.description)   end

I thought there were instances where this was not the case (I seem to
remember that pkg didn't always provide a way to capture the output),
but I can't recall where I ran into it.

BTW, is there a way to cut through a cell array without a loop, like

I vote for simply removing this warning (i.e. Riks second option).  The only useful scenario I can imagine is, when you misspell your data file in the current directory, say

octave:1> load penny.mat

instead of

octave:1> load Penny.mat

that the warning might be helpful to detect that a totally different file is loaded.  But this is not a convincing use case to me.  Neither in the repo, nor the changelogs I found a convincing reason why they exist.


Regarding the BTW.  In this case it seems harder, as the underlying structs are not sorted by the fieldnames.
You might try this (not really more beautiful than the loop):

s = pkg ("list");
cdata = [cellfun(@(x) getfield (x, "name"), s, "UniformOutput", false);
             cellfun(@(x) getfield (x, "description"), s, "UniformOutput", false)];
printf("%s: %s\n",cdata{:})

reply via email to

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